For example, your Relational Model introduction has a discussion of various data types. But arguably, whether your integer is implemented as BIGINT or TINYINT is an implementation decision which should be separate from the model discussion (dixit Date). In other words, that attribute has a type of integer and how that integer is stored is a separate issue, and your RDBMS ought to abstract it away (as, I think, Postgres is pretty good with, and MySQL quite annoying). The beauty of the latest RDBMS developments, particularly in Postgres world, is that the implementation has gotten so good that you don't need to really worry about it like you used to just a decade ago, at least in 95% of use cases.
Again as a non-"full time developer" it amazes me the number of "experienced" developers who are not aware of the relational model and who do not know what a foreign key is or why referential integrity might be important.
I think one can teach SQL (and the relational model) to a non-developer in about 2 hours, because it is so declarative and intuitive. One day I'll go write that tutorial, as many clients need it sorely...
 e.g. http://www.amazon.com/SQL-Relational-Theory-Write-Accurate/d...
 e.g. http://www.amazon.com/The-Relational-Model-Database-Manageme... or the original paper: http://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf
edit to add: on the E/RM vs the RM: http://www.dbdebunk.com/2013/09/entity-relatonship-model-not...
To understand the query planner is tantamount to making good schema's and requires insight in the underlying data-structures (B-tree) and join methods.
Then, for the student to get used to this way of thinking, I'd have them implement a simple project, e.g. a hotel-booking system.
For example: a "Write-Read Conflict" ist just that, a conflict, which a database in some appropriate isolation mode would handle by appropriate locking in order to avoid "reading uncommitted data" (if the transactions were to happen concurrently--per the definition given, operations don't need to happen in concurrent transactions for them to be in conflict). Or, an actual DBMS with MVCC with SSI, like a modern Postgres, would simply execute the read on its snapshot and thus force the reading transaction to precede the writing transaction in any equivalent serialized order (even though the read happened after the write in realtime), and only abort the transaction if that could lead to contradictions (cycles) in the dependency graph.
I agree that, at introduction, material should be made as accessible to students as possible. At the same time, we shouldn't dumb down the field for more advanced students.
blueatlas cited the bit on functional dependencies as "an example of what drives many students out of CS" but I'd say that more than anything it's an example of a tricky topic that ought to be presented by a highly engaging, smart instructor instead of a boring one who may or may not understand the material very well. (in retrospect, my feelings and his aren't mutually exclusive)
The term database can encompass pretty much everything from CSV files to in memory distributed grids.