An abstraction of a database system
Introduction
When designing databases, Entity-Relationship diagrams (E-R diagrams) are one of the diagrams used to help database designers understand what is required. It is a classic example of an abstraction, giving a model of a future real system that shows only the certain details. Here is an example of a typical E-R diagram:
Why is this abstraction helpful?
If you think how powerful (and complicated) a program like Access is for a moment, and all of the details that might be part of a diagram such as the user interface, the metadata, the queries and SQL, macros, modules and lots of other things, then it might be surprising just how useful a simple diagram like this is. This abstraction of what the real database is going to look like gives you a great overview of the database. It tells you what tables you need in the database (Pupil, Copy_Of_Book, Book and Author) and the relationships between them (two one-to-many relationships and a many-to-many relationship, which needs resolving). It doesn't give any detail about the data in each table, or the data types, the validation rules, which pieces of data will be used for keys and so on. What it does do, however, is to allow someone to start the design of the database. They can also use it to start thinking about what they need to do next, which in this case is possibly to resolve the many-to-many relationship and then start completing data dictionaries, one for each table. If a new employee joins the project, or a modification has to be made in future years, the E-R diagram is probably the first diagram they will look at, to understand the overview.