ER Modeling Data Modeling and the Entity-Relationship (ER) Diagram Pg 1 Data Modeling and the Entity-Relationship (ER) Diagram Ray Lockwood Points: The Entity-Relationship (ER) Diagram is seen by various authors as a design methodology, a conceptual model, or a logical data model. The ER Diagram is a graphical way to build a Data Model. The ER Diagram organizes data into entities and relationships that will later become tables and foreign keys. The ER Diagram is very simple and intuitive. But because a big deal is made of it, you d think it was complicated. It s just a drawing of how your data is laid out. How do you draw a database? Before you can put your database into a computer you have to design it. If we could make a graphical diagram of the database, it d be easer for us to see the layout of the data and describe it to others. The simplest ideas are the most profound. Dr. Chen is a living legend for his invention of the ER Diagram. An MIT researcher (who is now on the faculty at Carnegie Mellon University), Peter Chen 1, wrote a paper in 1976 titled The Entity-Relationship Model Toward a Unified View of Data. Chen described a simple way to draw data which fit right in with the new Relational Database. Peter Chen Entity-Relationship Diagram A Design Methodology, or a Conceptual or Logical Model? Some textbooks refer to the Entity-Relationship Diagram as a Conceptual Model. Other authors call it a specific type of conceptual model, a Logical Data Model. Some authors don't use the term ER Diagram but call it the ER Model instead. Chen himself said To model the world correctly is the first and most important step! 2 He means we should design our database before we build it. The authors of our textbook say the ER Diagram is not a model at all but a visually oriented design methodology ; and since the ER Diagram can be applied to many things other than databases, this may be true in the larger sense. However, when applied to databases, most authors have decided that the Entity-Relationship Diagram is a logical data model. These distinctions don t make any difference when you re trying to get a picture of your data. My view is that the ER Diagram looks like a model of data. It shows us a graphical picture of our database, and we use it as a database model. 1 Photo from http://csc.lsu.edu/~chen/ 2 http://drpeterchen.com/ is a model of the problem domain. lays out the fundamental structure of a is a Logical Data Model. is our most important tool for designing a
ER Modeling Data Modeling and the Entity-Relationship (ER) Diagram Pg 2 The ER Diagram is a Logical Data Model because it shows our data at a higher level of abstraction than the relational model. Examples of this abstraction are: The ER Diagram can graphically show relationships between entities without using foreign keys. The ER Diagram can show a many-to-many relationship, which can t be directly implemented in the relational model. In the relational model we use two one-tomany relationships (with a special table in between). The ER Diagram can show types of minimum cardinalities that are difficult to enforce in a relational Still, the ER Diagram is a close mirror of the tables and relationships in a relational Designing a Database Application Most textbooks approach the study of database systems from the point of view of a database designer who is creating a database application for a business organization. In this context, a database is a model of the objects and their relationships in an organization. The database designer observes the organization and interviews the employees. He identifies data objects that reflect the real objects (entities), and determines how these objects are related to each other. These entities, and the relationships between them, are drawn in an Entity-Relationship Diagram. Definition: The Entity-Relationship Diagram (we ll call it the ER Diagram) is a graphical way to depict the objects (entities) in an organization and the relationships between them. The ER Diagram is a conceptual model like the Relational Model, but it's simpler than the relational model, and is a logical data model. And because it s graphical it s indispensably helpful. is at a higher level of abstraction than the relational model. Results of higher abstraction: 1. Doesn t need foreign keys. 2. Directly shows M:M relationships. 3. Easily shows minimum cardinalities. A database is a model of an organization. A database captures not just objects, but also their relationships to each other. An ER diagram is a graphical way to capture those objects and relationships. Build an ER Diagram An Example Let s say there's an HR department that keeps track of employees and their family members. From this, we realize that there's a real-world entity called, who might have one or more family members, which are another entity,. An entity is something we want to keep track of. This is how we could model employees and family members in an ER Diagram: 1 0..M Entities are named in the singular because they define a class of thing rather than individuals It's easy to see that an ER diagram contains objects, but remember, it also contains relationships. Chen's Original Notation Crow's Foot Notation (preferred)
ER Modeling Data Modeling and the Entity-Relationship (ER) Diagram Pg 3 This diagram has several types of elements: 1. The rectangular boxes are entities, or in ER language entity classes. 2. The connection between the boxes is a relationship: a. The diamond with a label names the relationship between the two entities. b. The lines (called edges) connect the entities having the relationship. c. The 1 and the M are cardinality constraints, which tell the minimum and maximum number of entity instances that can participate in a relationship. Entity Classes Our diagram shows the entity class and the entity class. An entity class is analogous to a database table or a class in object oriented software design. An entity instance is like an instance of an object oriented class or a row in a table. When we convert our ER Diagram to a relational database, entity classes will become tables. We'll build relationships by using foreign keys. Relationships The entity has a relationship with the entity. The company needs to know who an employee s family members are to include them in health benefits. This relationship connects the to the so we can tell who belongs to whom. Maximum Cardinality Constraints (We'll talk about Minimum Cardinality later). Cardinality means count ; literally, it's the number of elements in a set. Maximum Cardinality means the maximum number of entity instances (rows) that can participate in a relationship. There are three maximum cardinalities that we care about: 1. Zero 2. One 3. Many Cardinality Ratios We can look at the cardinality of both sides of a relationship at the same time by using a ratio. There are three cardinality ratios that we care about: 1. 1:1 One-to-One 2. 1:M One-to-Many 3. M:M Many-to-Many One-to-Many Our example has a One-to-Many relationship: one employee may have many family members. Reading the other way, a family member may belong to only one employee. This is a one-to-many relationship. This tells the maximum number of instances (rows) of one entity (table) that may be related to instances of the other entity. ER diagrams have Entities with Instances. Databases have Tables with Rows. Relationships are as important as Entities. Cardinality tells how many instances of one entity can be related to an instance of another entity. Maximum Cardinality is the most important characteristic of a relationship. The 1:M relationship is the Parent-Child relationship. This is the most common cardinality.
ER Modeling Data Modeling and the Entity-Relationship (ER) Diagram Pg 4 The one-to-many relationship is called a parent-child relationship, with the parent on the one side and multiple children on the many side. One-to-One If we made an ER Diagram showing the relationship between and Spouse, we would have a one-to-one relationship. One employee may have, at most, one spouse. Remember, cardinality ratio tells the maximum number of entity instances (rows in a table) that may be connected by the relationship. Many-to-Many If we want to show the relationship between employees and the work skills they possess, we would use a many-to-many relationship. One employee may possess many work skills, and a particular work skill may be possessed by many employees. Useful Points. Maximum cardinality constraints are easy to enforce in a relational The relational model cannot directly implement the many-to-many relationship; it has to be broken into two one-to-many relationships. But it s acceptable to use the manyto-many relationship in an ER Diagram because it s a higher level of abstraction. Entity Attributes Just as we do in a table, we can show the attributes that an entity has. You might see two ways to show attributes: Data modeling software lists attributes in the entity rectangle. The old way is to place them in ovals around the entity, but this is an obsolete, hand drawn technique: 1:1 relationships are the least common. We need to use a special technique to implement the M:M relationship in a relational Attributes in an Entity are the same as Columns in a Table. Tip: We often omit the attributes because they clutter the diagram. Entity Name Key Attribute Attribute Attribute Key Attribute Attribute Attribute Entity Name The new style entity notation is easier for modeling software to draw and fits into diagrams better. New Style (Used by data modeling software) Old Style (Before data modeling software) Identifier (Key) Attribute Identifier attributes in an ER diagram correspond to key columns in the Relational Model. Entities have Identifiers Tables have Keys Most people probably use the term key for both models. Identifier attributes are shown underlined in the ER Diagram. An Identifier is the same as a key and is underlined.
ER Modeling Data Modeling and the Entity-Relationship (ER) Diagram Pg 5 What s the Difference between an ER Diagram and a Relational Model? It looks like the ER Diagram and the Relational Database Model are the same thing. What s the big deal about an ER Diagram? The biggest difference between the two is the ER Diagram doesn t use foreign keys to make relationships. We're free to think how the entities are related without having to use keys or constraints. We can work with maximum and minimum cardinalities graphically, and implement many-to-many relationships directly. After you work with ER Diagrams and Relational Databases for just a short while, the distinction between the two will begin to blur. It's easier to work with relationships in an ER diagram than in the relational model. You'll begin to think of an ER diagram as being the same as a Variations of the ER Diagram There are many ways to draw an ER Diagram. Here s an older way they're drawn: 1:M There's great variation in the way people draw ER diagrams. Modeling software is lessening the variation. Data modeling software omits the diamond which symbolizes the relationship, using just the line and its label. They ll also place the maximum cardinality next the entities: 1 M Some modeling tools don t name the relationship, but that s not a good idea: 1 M Some designers express the minimum cardinality along with the maximum cardinality (more about minimum cardinality later): 1..1 0..M Required relationship (one and only one) Optional relationship (zero, many, and anything in between)
ER Modeling Data Modeling and the Entity-Relationship (ER) Diagram Pg 6 Crow s Foot Notation The most common notation used by data modeling tools is the crow s-foot style. The following was made with an open-source data modeling tool named Power*Architect from SQL Power Group Inc. (www.sqlpower.ca): Just about all data modeling software makes diagrams like this. Required relationship (one and only one) Optional relationship (zero, one, or many) The symbols on the ends of the line are the cardinality constraints: 1. Maximum cardinality a. To-many (crow s foot) b. To-one (lack of crow s foot) 2. Minimum Cardinality a. At least one (tic) b. Can be zero (circle) This diagram tells us that on the left side ( ), each family member must be associated with no fewer than one (min cardinality) and no more than one (max cardinality) employee. The minimum cardinality of one makes this a required relationship. On the right side ( ), each employee can have zero (min cardinality), one, or many (max cardinality) family members. The minimum cardinality of zero makes this an optional relationship. Crow s Foot notation used by modeling software.. Required relationship means minimum cardinality is non-zero Optional relationship means minimum cardinality is zero Conclusion The most important thing to remember is Maximum Cardinality (to-one or to-many) and Cardinality Ratio (1:1, 1:M, M:M). This gives you the character of the relationships between the entities. We ll fill in the details later. The Maximum Cardinality captures the essence of the relationships between entities.