Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Database - Entity Relationship Diagram (ERD)

in these slides i have explained how to create and ERD for your database starting from nothing.

  • Be the first to comment

Database - Entity Relationship Diagram (ERD)

  1. 1. Entity Relationship Diagram A complete guide to design ER Diagrams 19-Dec-14 Mudasir Qazi - 1
  2. 2. Contents / Agenda • Definition • Basic Components • ERD Representations • Chen’s Notation Symbols • Crow’s foot Notation Symbols • UML Notation Symbols • Type of Entities • Types of Attributes • How to solve multivalued attributes • Types of Relationships • Implementation of 1:1 • Implementation of 1:M • Implementation of M:M • Connectivity and Cardinalities • Summary 19-Dec-14 Mudasir Qazi - 2
  3. 3. Definition • The Relational Database Model (ERM-database containing tables) forms on the basis of an ERD. The ERD represents the conceptual database as viewed by the end user. • ERDs depict the database’s main components: entities, attributes, and relationships. Because an entity represents a real-world object, the words entity and object are often used interchangeably. Thus, the entities (objects) of the Tiny College database design (mostly discussed in these slides) include students, classes, teachers and classrooms. 19-Dec-14 Mudasir Qazi - 3
  4. 4. Basic Components of ERD • Entities: • An entity is an object of interest to the end user. At the ER modeling level, an entity actually refers to the entity set and not to a single entity occurrence. In other words, the word entity in the ERM corresponds to a table—not to a row—in the relational environment. The ERM refers to a table row as an entity instance or entity occurrence. • In both the Chen and Crow’s Foot notations, an entity is represented by a rectangle containing the entity’s name. The entity name, a noun, is usually written in all capital letters. • Attributes: • Attributes are characteristics of entities. For example, the STUDENT entity includes, among many others, the attributes STU_LNAME, STU_FNAME, and STU_INITIAL. In the original Chen notation, attributes are represented by ovals and are connected to the entity rectangle with a line. Each oval contains the name of the attribute it represents. • In the Crow’s Foot notation, the attributes are written in the attribute box below the entity rectangle. Because the Chen representation is rather space-consuming, software vendors have adopted the Crow’s Foot style attribute display. • Relationships: • A relationship is an association between entities. The entities that participate in a relationship are also known as participants, and each relationship is identified by a name that describes the relationship. The relationship name is an active or passive verb; for example, a STUDENT takes a CLASS, a PROFESSOR teaches a CLASS and an AIRCRAFT is flown by a CREW. • Relationships between entities always operate in both directions. That is, to define the relationship between the entities named CUSTOMER and INVOICE, you would specify that: 1. A CUSTOMER may generate many INVOICEs. 2. Each INVOICE is generated by one CUSTOMER. 19-Dec-14 Mudasir Qazi - 4
  5. 5. ERD Representations • There are three main notations to represent and ERD 1. The Chen notation favors conceptual modeling. 2. The Crow’s Foot notation favors a more implementation-oriented approach. 3. The UML notation can be used for both conceptual and implementation modeling. • Because of its implementation emphasis, the Crow’s Foot notation can represent only what could be implemented. • We will also be using a new Short Hand notation that is easy to understand and takes less place. 19-Dec-14 Mudasir Qazi - 5
  6. 6. Chen Notation Symbols 19-Dec-14 Mudasir Qazi - 6
  7. 7. Crow’s Foot Notation Symbols 19-Dec-14 Mudasir Qazi - 7
  8. 8. UML Notation Symbols Primary Keys are followed by [PK] Foreign Keys are followed by [FK] Relationships: Cardinality 1 for ‘One’. Cardinality * for ‘Many’. 19-Dec-14 Mudasir Qazi - 8
  9. 9. Advantages and Usage • Advantages: 1. ERD tells us that how many tables you need and what would be the relationship between them (you also have to do Normalization to know finally how many tables would be in your database but still first step is ERD). 2. ERD is simple and understandable representation of a database. It helps a lot to understand the whole database. • Usage: 1. An ERD leads to ERM, means when ever you need to build a database with tables, firstly, you need to create an ERD. 2. Crow’s foot notation is used most of all because its easy to understand in implementation point of view. 19-Dec-14 Mudasir Qazi - 9
  10. 10. Types of Entities • Existence Dependent An entity is said to be existence-dependent if it can exist in the database only when it is associated with another related entity occurrence. In implementation terms, an entity is existence-dependent if it has a mandatory foreign key—that is, a foreign key attribute that cannot be null. • Existence Independent. If an entity can exist apart from one or more related entities, it is said to be existence-independent (Sometimes designers refer to such an entity as a strong or regular entity). Here foreign key attribute can be null. 19-Dec-14 Mudasir Qazi - 10
  11. 11. Types of Attributes (1) • Required A required attribute is an attribute that must have a value; in other words, it cannot be left empty. • Optional An optional attribute is an attribute that does not require a value; therefore, it can be left empty. • Domains Attributes have a domain, a domain is the set of possible values for a given attribute. For example, the domain for the grade point average (GPA) attribute is written (0,4) because the lowest possible GPA value is 0 and the highest possible value is 4. The domain for the gender attribute consists of only two possibilities: M or F (or some other equivalent code). • Identifiers The ERM uses identifiers, that is, one or more attributes that uniquely identify each entity instance. In the relational model, such identifiers are mapped to primary keys (PKs) in tables. There are Simple(Primary Key) and Composite (Composite Key) identifiers. 19-Dec-14 Mudasir Qazi - 11
  12. 12. Types of Attributes (2) • Composite A composite attribute, not to be confused with a composite key, is an attribute that can be further subdivided to yield additional attributes. For example, the attribute ADDRESS can be subdivided into street, city, state, and zip code. • Simple A simple attribute is an attribute that cannot be subdivided. For example, age, sex, and marital status would be classified as simple attributes. • Single-Valued A single-valued attribute is an attribute that can have only a single value. For example, a person can have only one Social Security number, and a manufactured part can have only one serial number. Keep in mind that a single-valued attribute is not necessarily a simple attribute. For instance, a part’s serial number, such as SE-08-02-189935, is single-valued, but it is a composite attribute because it can be subdivided into the region in which the part was produced (SE), the plant within that region (08), the shift within the plant (02), and the part number (189935). • Multi-Valued Multivalued attributes are attributes that can have many values. For instance, a person may have several college degrees, and a household may have several different phones, each with its own number. Similarly, a car’s color may be subdivided into many colors (that is, colors for the roof, body, and trim). • Derived A derived attribute is an attribute whose value is calculated (derived) from other attributes. The derived attribute need not be physically stored within the database; instead, it can be derived by using an algorithm. For example, an employee’s age, EMP_AGE, may be found by computing the integer value of the difference between the current date and the EMP_DOB. 19-Dec-14 Mudasir Qazi - 12
  13. 13. How to Solve Multi-Valued attributes (1) • Although the conceptual model can handle M:N relationships and multivalued attributes, you should not implement them in the RDBMS. Because in the relational table, each column/row intersection represents a single data value. So if multivalued attributes exist, the designer must decide on one of two possible courses of action: 1. Within the original entity, create several new attributes, one for each of the original multivalued attribute’s components. For example, the CAR entity’s attribute CAR_COLOR can be split to create the new attributes CAR_TOPCOLOR, CAR_BODYCOLOR, and CAR_TRIMCOLOR, which are then assigned to the CAR entity. (Not good). 2. Create a new entity composed of the original multivalued attribute’s components. The new (independent) CAR_COLOR entity is then related to the original CAR entity in a 1:M relationship. Note that such a change allows the designer to define color for different sections of the car like top, body, interior etc. (Best solution). 19-Dec-14 Mudasir Qazi - 13
  14. 14. How to Solve Multi-Valued attributes (2) Entity CAR contains a multivalued attribute CAR_COLOR. Solution 1: (Not good) Solution to Multi-Valued attribute by adding new attributes to CAR entity. Solution 2: (Best) Solution to Multi-Valued attribute by adding new entity with 1:M relation to CAR entity. 19-Dec-14 Mudasir Qazi - 14
  15. 15. Relationships • Ways of Classifying Relationships Types A relationship type can be classified by the number of entity types involved, and by the degree of the relationship type. Following is a brief picture showing all types of relationships. 19-Dec-14 Mudasir Qazi - 15
  16. 16. Types of Relationships (1) • One-to-One • When both participants can have only one instance of each other. (less used but stable). • For Example, HUSBAND can have only one WIFE and WIFE can have only one HUSBAND. This is 1:1 relationship between HUSBAND and WIFE participants. • One-to-Many • When one participant can have multiple instances of other participants but other participant can have only one instance of first participants. (mostly used and stable). • For Example, CUSTOMER may generate many ORDERs but each ORDER is generated by one CUSTOMER. This is 1:M relation between CUSTOMER and ORDER. • Many-to-Many • When both participants can have multiple instances of each other. (not practice). • For Example, STUDENT can be enrolled in many SUBJECTs and one SUBJECT can be chosen by many STUDENTs. This is M:M relation between STUDENT and SUBJECT. 19-Dec-14 Mudasir Qazi - 16
  17. 17. Types of Relationships (2) • Weak relationship Also known as a non-identifying relationship, exists if the PK of the related entity does not contain a PK component of the parent entity. By default, relationships are established by having the PK of the parent entity appear as an FK on the related entity (implemented in right picture). • Strong relationship Also known as an identifying relationship, exists when the PK of the related entity contains a PK component of the parent entity (implemented in left picture). • Recursive relationship • A recursive relationship is one in which a relationship can exist between occurrences of the same entity set (Naturally, such a condition is found within a unary relationship). 19-Dec-14 Mudasir Qazi - 17
  18. 18. Relationships (1:1) – Implementation (1) • An example of a one-one relationship type is a person and his or her birth certificate. We assume that everyone has one and that a certificate registers the birth of one person only. • Where there is a one-one relationship type we have the option of merging the two entity types. The birth certificate attributes may be considered as attributes of the person and placed in the person entity type. The birth certificate entity type would then be removed. • There are two reasons for not merging them: 1. The majority of processing involving PERSON records might not involve any or many of the BIRTH_CERTIFICATE attributes. The BIRTH_CERTIFICATE attributes might only be subject to very specific processes which are rarely executed. 2. the BIRTH_CERTIFICATE entity type has relationship types to other entity types that the PERSON entity type does not have. The two entity types have different relationship types to other entity types. • Merging is not very harmful practically. so, its just a matter of choice which implementation you want. 19-Dec-14 Mudasir Qazi - 18
  19. 19. Relationships (1:1) – Implementation (2) • Following is implementations for 1:1 relationship. One table has PK and other table must have same PK as well as FK. Department Table has Department_ID as PK. And Manager Table must have Department_ID as PK as well as FK (You can change the name of column but it should have same data). 19-Dec-14 Mudasir Qazi - 19
  20. 20. Relationships (1:M) - Implementation • The common column is DEPARTMENT_ID (which is the primary key in the DEPARTMENT table) should be as a foreign key in the EMPLOYEE table. One individual DEPARTMENT_ID can relate to many rows in the EMPLOYEE table. Business Rule for this is: “one department can relate to one or many employees (or even no employees) and that an employee is associated with only one department (or, in some cases, no department).” 19-Dec-14 Mudasir Qazi - 20
  21. 21. Relationships (M:N) – Implementation (1) • Consider the EMPLOYEE and PROJECT tables. The business rule is as follows: One employee can be assigned to multiple projects, and one project can be supported by multiple employees. Therefore, it is necessary to create an M:M relationship to link these two tables. • In the relational database we don’t implement the M:N relation by just giving FKs to each other and the reason is we don’t want two sided links (circles). So, we create a new entity called Bridge Entity and its PK is a composite key made up with PKs of both tables. It may or may not have any other attributes but composite key is must. • After doing this, there becomes two 1:M relations. 1. One between Bridge and EMPLOYEE table (1:M). 2. One between Bridge and PROJECT table (1:M). 19-Dec-14 Mudasir Qazi - 21
  22. 22. Relationships (M:N) – Implementation (2) In this example we made Bridge Table under name EMPLOYEE_PROJECT containing PKs of both above tables. It has one more attribute for some extra information. Now, it becomes like this and we have three tables now. 19-Dec-14 Mudasir Qazi - 22
  23. 23. Removing Ternary and Hire order relations • It is advantageous (but not necessary) to remove ternary and higher order relationship types. One reason is that it might be considered more `natural' to think of entity types having attributes than relationship types having them. It is in fact always possible to remove these high-order relationship types and replace them with an entity type. A ternary relationship type is then replaced by an entity type and three binary relationship types linking it to the entity types which were originally linked by the ternary. A quaternary relationship type would be replaced by an entity type and four relationship types and so on. Ternary Relation Ternary Relation Solved into binary relations 19-Dec-14 Mudasir Qazi - 23
  24. 24. Connectivity and Cardinalities • Connectivity: The term connectivity is used to describe the relationship classification. Just to show the relation existence and type of relation between entities. • Cardinalities: Cardinality expresses the minimum and maximum number of entity occurrences associated with one occurrence of the related entity. In the ERD, cardinality is indicated by placing the appropriate numbers beside the entities, using the format (min , max). 1. Cardinality / mandatory: maximum cardinality. 2. Modality / optional: minimum cardinality or optionality. Picture says, one PROFESSOR can teach one (min 1) or more (max 4) CLASSes but each single (min 1) CLASS can be taught by one (max 1) PROFESSOR at time. 19-Dec-14 Mudasir Qazi - 24
  25. 25. Summary • Following are main steps to create an ERD 1. Decide what are the entitles in your database. 2. Decide attributes for each entity. 3. Describe relationships between entities. 1. If there is any M:N relation, solve it into 1:M relationships. • Note: ERD will not output a complete blue print to your database until you do its Normalization. But, ERD + Normalization will give you complete set of tables, attributes and relationships you need in your database. 19-Dec-14 Mudasir Qazi - 25

    Be the first to comment

    Login to see the comments

  • hajarmaseeh

    Nov. 9, 2017
  • milaaulia9828

    Dec. 5, 2017
  • Shihabyaqob

    Dec. 19, 2017
  • hanzalacheeMa

    Dec. 29, 2017
  • gregorynicholas

    Feb. 6, 2018
  • arifulshuvo1

    Mar. 5, 2018
  • BobbyMartin16

    May. 9, 2018
  • ZakaryaRkaa

    Jun. 11, 2018
  • pukhtoon001

    Sep. 6, 2018
  • MohammedAbdallah59

    Oct. 28, 2018
  • AndrewOjulong

    Nov. 8, 2018
  • ChristineAHodges

    Feb. 25, 2019
  • EstibalizCerveroSimo

    Oct. 17, 2019
  • RumpaChowdhury2

    Nov. 26, 2019
  • AshleeCalderCST

    Dec. 8, 2019
  • AndyLaura

    Jan. 27, 2020
  • AllisonBrueckner

    Feb. 18, 2020

    Apr. 19, 2020
  • EireneClaudiaHutasoi

    Jul. 9, 2020
  • IrfanKhan1038

    Oct. 14, 2020

in these slides i have explained how to create and ERD for your database starting from nothing.


Total views


On Slideshare


From embeds


Number of embeds