3.5.2 ER Diagrams

Entity relationship diagrams (ERDs) have been used for years for modeling the data aspects of a system. An ERD can be used to model the data in the system and how the data items relate to each other, but does not cover how the data is to be processed or how the data is actually manipulated and changed in the system. It is used often by database designers to represent the structure of the database and is a useful tool for analyzing software systems which employ databases. ER models form the logical database design and can be easily converted into initial table structure for a relational database.

ER diagrams have two main concepts and notations to representing them. These are entities and relationships. Entities are the main information holders or concepts in a system. Entities can be viewed as types which describe all elements of some type which have common properties. Entities are represented as boxes in an ER diagram, with a box representing all instances of the concept or type the entity is representing. An entity is essentially equivalent to a table in a database or a sheet in a spreadsheet, with each row representing an instance of this entity. Entities may have attributes, which are properties of the concept being represented. Attributes can be viewed as the columns of the database table and are represented as ellipses attached to the entity. To avoid cluttering, attributes are sometimes not shown in an ER diagram.

If all identities are identified and represented, we will have a set of labeled boxes in the diagram, each box representing some entity. Entities, of course, do not exist in isolation. They have relationships between them and that is the reason why they exist together in the same system.

Relationships between two entities are represented by a line connecting the boxes representing the entities. Having a line between two boxes means that each element of one entity is related to elements of the other entity, and vice versa. This relationship can also be given a name by labeling the line. In some notations, the name of the relationship is mentioned inside a diamond. Some examples of relationships are: studies-in (between students and college), worksfor (between employees and companies), and owner (between people and cars). Note that the relationships need not be between two distinct entities. There can be a relationship between elements of the same entity. For example, for an entity type Employee, there can be a relationship Supervisor, which is between elements of the entity Employee.

An ER diagram specifies some properties of the relationship also. In particular, it can specify if the relationship is optional (or necessary), and with how many elements an element of an entity is related to. This leads to many forms of relationships. The common ones are one-to-one (that one element of an entity is related to exactly one element of the other entity), one-to-many or many-to-one (that one element is related to many elements of the other entity), and many-to-many (that one element of entity A is related to many elements of entity B and one element of entity B is related to many elements of entity A). There are various notations to express the nature of relationships; a common one is to put “0”, “1”, or “M” on the two sides of the relationship line to represent the cardinality of the relationship. Thus, for a one-to-many relationship, a “1” will be put on one end and “N” will be put on the other end of the line. Relationships reflect some properties of the problem domain. For example, a course has many students and a student is taking many courses, leading to many-to-many relationship between courses and students. But a student studies in exactly one college though the college has many students, leading to manyto- one relationship between students and college. A department in a college has exactly one head, and one person can be Head of only one department, leading
to one-to-one relationship.

Let us draw the ER diagram for the university auction system, some use cases of which were discussed earlier. From the use cases described, we can easily identify some entities—users, categories, items, and bids. The relationships between them are also clear. A user can sell many items, but each item has only one seller, so there is a one-to-many relationship “Sell” between the user and items. Similarly, there is a one-to-many relationship between items and bids, between users and bids, and between categories and items. The ER diagram of this is shown in Figure 3.7.

Figure 3.7: ER diagram for an auction system

From the ER diagram, it is easy to determine the initial logical structure of the tables. Each entity represents a table, and relationships determine what fields a table must have to support the relationship, in addition to having fields for each of the attributes. For example, from the ER diagram for the auction system, we can say that there will be four tables for users, categories, items, and bids. As user is related to item by one-to-many, the item table should have a user-ID field to uniquely identify the user who is selling the item. Similarly, the bid table must have a user-ID to identify the user who placed the bid, and an item-ID to identify the item for which the bid has been made.

As we can see, an ER diagram is complementary to methods like use cases. Whereas use cases focus on the nature of interaction and functionality, ER diagrams focus on the structure of the entities being used in the use cases. Due to their complementary nature, both use cases and ER diagrams can be used while analyzing the requirements of a system and both may be contained in an SRS.