database - entity relationship diagram (erd)

Mudasir Qazi - [email protected] 1

Entity Relationship Diagram

A complete guide to design ER Diagrams

19-Dec-14


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


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


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


ERD Representations

• There are three main notations to represent and ERD1. 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


Chen Notation Symbols

19-Dec-14


Crow’s Foot Notation Symbols

19-Dec-14


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


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


Types of Entities

• Existence DependentAn 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


Types of Attributes (1)

• RequiredA required attribute is an attribute that must have a value; in other words, it cannot be left empty.

• OptionalAn optional attribute is an attribute that does not require a value; therefore, it can be left empty.

• DomainsAttributes 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).

• IdentifiersThe 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


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.

• SimpleA simple attribute is an attribute that cannot be subdivided. For example, age, sex, and marital status would be classified as simple attributes.

• Single-ValuedA 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-ValuedMultivalued 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).

• DerivedA 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


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


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


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


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


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


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


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


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


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


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


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


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


Summary

• Following are main steps to create an ERD1. 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

database - entity relationship diagram (erd)

Engineering

entity relationship

entity rectangle

student entity

words entity

entity instance

word entity

single entity occurrence

attributes stu