ER vs database schema diagrams
ER diagramming grew out of ER modeling.  ER models were intended to be application neutral, so that ER modeling could be applied to a given situation whether the ultimate implementation was to use relational databases or some other technology, such as the (then current) hierarchical databases or the CODASYL style network databases.  Since that time, hierarchical and network databases have been all but eclipsed by relational databases, at least as far as new work is concerned.  At the same time, various post relational data schemes have come up for fitting data management into an object oriented framework or an unstructured enviroment.  

ER diagrams were, initially, depictions of an ER model.  Eventually, this mode of diagramming became so widespread that it began to be used for diagramming schemas designed under a relational model as well.  ERD actually works quite well in this manner.  The only confusion that results is when a person builds a relational model, and expects the same benefits out of it that you get from an ER model, or vice versa.

A relational model and an ER model differ in a few important details.  The use of foreign keys and junction tables are peculiar to relational models, and do not appear in ER models.  Nevertheless, they do appear in most of the ER diagrams you will see today.  That is the best clue that what you are really looking at is an ERD picture of a relational schema.  

For years, I looked at ER models as though they were "relational lite".  It turns out that this is a misconception.  The two models are really looking at reality from different levels of abstraction.  Each model has its strengths and weaknesses.

As far as good references go, I would start with Wikipedia.  There are good articles in there about the ER model, the relational model, SQL, and some of the major DBMS products like Oracle, SQL Server, and many many others.  

Once you understand the models and their uses, you'll be in good shape to tackle the diagramming conventions.