Archive for October 18th, 2009
A relational database, as we all know from the previous article, stores relations between integers, strings and other simple types in a very plain way: it just enumerates all values related.
This model is extremely flexible, since other relations can be easily derived from existing ones using mathematical formulae, and the relational database takes care of that.
However, database should reflect the real world in some way to be really of use. Since the relational databases store relations between mathematical abstractions and not real world things, we should make some kind of a mapping of ones to the others.
This is what entity-relationship model is for.
An entity-relationship model, as one can easily guess from its name, models relationships between entities.
But since we know that databases do essentially the same, how does it differ from the database model?
- An entity-relationship model states which data and relations between them should be stored
- A database model states how these relations are stored
In other words, ER model is design and database model is one of the ways to implement it. ER model is said to be above the database model in the waterfall developement.
Note that in both cases I use the word stored above. The model says nothing of data and relations between them that may or should exist, only of those that should be stored. Every human being participates in thousands if not millions relationships, but an ER model should state which of them are to be stored, and a relational model should decide how to store them. Of course it would be nice to store them all (and police and insurance would be just happy), but the technology does not allow it yet. Don't know whether it is good or bad.
A typical entity-relationship diagram in Peter Chen's notation looks like this:
What does it mean?
Read the rest of this entry »