1 System Analysis And Design Methods ENTITY RELATIONSHIP DIAGRAM (ERD) Prof. Ali Khaleghi Eng. Hadi Haedar
Overview DATABASE ARCHITECTURE 2 External level concerned with the way individual users see the data PROJECT 1 Conceptual level can be regarded as a community user view a formal description of data of interest to the organization Internal level concerned with the way in which the data is actually stored
Overview 3 Level Database Design 3 PROJECT 1 Conceptual Design Creating an Entity Relationship Diagram (ERD) and associated data dictionary to represent the reality and capture business data requirements Logical Design Transforming ERD to relational model: tables, keys (constraints), etc. Physical Design Creating the database and other supporting structures based on a specific DBMS
Overview General These tools are not specific to either structured analysis or OO analysis. Use-cases Use-case diagrams 4 Activity diagrams Data object diagrams Swimlane diagrams analysis model tools Structured Analysis ERD diagrams Data flow diagrams Class diagrams Process specifications (Process narrative) Packages CRC cards OO Analysis Sequence Diagrams
Overview 5 Modeling Tools: Structured Analysis: Data object diagrams Models data elements ERD diagrams Attributes Relationships Structured Analysis Data flow diagrams Models processes that Process specifications transform data (Process narrative)
6 Entity-Relationship Diagram Proposed by Dr. Peter Chen in 1970s A conceptual model A pictorial representation of the information that can be captured by a database Allows database professionals to describe an overall design concisely yet accurately Major elements : i. Entity (with attributes and identifier) ii. Relationship * Most of Entity-Relationship Diagram can be easily transformed into the relational schema
ERD An Example Of Entity-Relationship Diagram 7
ERD An Example Of Entity-Relationship Diagram 8 Attributes : نام دانشجو شماره دانشجوئي نام استاد مدرک Entity : دانشجو استاد گروه درسی درس تاريخ تولد نيمسال شماره گروه شماره درس نام درس Relationship : ارائه دارد تعداد واحد شماره درس
ERD 9
10
ERD i.entity 11 It is a real world item / concept that can exist on it s own It may be an object with physical existence ( person, house) or it may be an object with conceptual existence (company,job, university course) Entity class (entity set) is a structural description of things that share common attributes Entity instance is the occurrence of a particular entity
ERD (Entity) Entity set 12 Collection of entities of a particular entity type in a database at any point of time is called entity set An entity set is a set of entities with common attributes Entity set is usually referred to by same name as the entity type Entity type is represented as rectangle enclosing the type name which is singular noun. Entity type
ERD (Entity) Entity type (Attribute) 13 defines collection of entities that have same attribute Describes an entity class All entity instances of a given entity class have the same attributes, but vary in the values Entity type in a database is defined by it s name and attribute. Entity instance is a single occurrence of an entity type.
ERD (Entity) Weak entity and strong entity 14 1. strong entity Regular entity types that have key value is called strong entities 2. weak entity Entity type that doesn t have a key attribute on it s own
ERD (Entity) 2.Weak entity 15 Entity belonging to weak entity type is identified by being related to specific entities from another entity type in combination with one of their attribute value The relationship that connects owner entity type to weak entity is called Identifying relationship. The weak entities are also called as child entity type or subordinate entity type can sometimes be represented as complex attributes (composite and multivalued attributes)
ERD (Entity) 2.Weak entity 16 Weak entity type normally has partial key(descriminator) o Partial key are set of attributes that can uniquely identify weak entities that are related to some owner entity o Partial key attribute is denoted with underlined or dotted line Weak entities have always a total participating constraint because they cannot be identified without an owner entity, But converse is not true Example : Driver license entity can t exist without person entity though it has it s own key (license number) => There is total participation but not weak entity
ERD (Entity) 2.Weak entity 17 شماره وابسته شماره دانشجويي شماره دانشجو وابستگان کمک هزينه دانشجو
ERD (Entity) Attribute 18 Attributes are the properties that describe the entities Attribute names are enclosed by ovals and connected to their entities by single line Set of attribute values of a given attribute is the value set or domain
ERD (Entity) Attribute 19 SIMPLE ATTRIBUTE COMPOSITE ATTRIBUTE Cannot be split in to further attributes(indivisible) Also known as Atomic attribute Example: Ssn(Social Security Number) Can be divided in to smaller subparts which represent more basic attributes with independent meaning Even form hierarchy Value of the composite attribute is the composition of the constituent simple attributes Example: Address
ERD (Entity) Attribute 20 SINGLE VALUED ATTRIBUTE Attributes having single value for particular entity. Example : Age MULTI VALUED ATTRIBUTE Attribute having set of values Denoted by double circled oval Example: Phone-number, Collegedegree DERIVED ATTRIBUTE STORED ATTRIBUTE Attribute values are derived from another attribute. Denoted by dotted oval Example: Age Attributes from which the values of other attributes are derived Example: Bdate
ERD (Entity) Entity and Attribute 21 Identifier Identifies an entity instance The value of the identifier attribute is unique for each entity instance
ERD (Entity) Iidentifier attribute or key attribute 22 Key Superkey Candidate key Primary key Data item that allows us to uniquely identify individual occurrences or an entity type. Attribute or set of attributes that uniquely identify a tuple. Minimal super key with the property of irredusability and uniqueness An entity type may have one or more possible candidate keys, the one which is selected as primary key. Composite key candidate key that consisting of two or more attributes Foreign key An attribute or set of attribute that matches the candidate key or other or same relation
ERD (Entity) key attributes 23 An attribute, or a group of attributes, that assumes a unique value for each entity instance. It is sometimes called an identifier.
ERD (Entity) key attributes 24 Simple key attribute Composite key attribute
ERD (Entity) Example 25
ERD (Entity) Example 26 Composite-hierarchy Primary-key Multi valued derived stored
ERD (Entity) Other Attribute Types 27 Composite attribute An attribute that can be further divided into more attributes o Example: Name, Address, etc Multi-Value Attribute An attribute that allow multiple values o Example: skills, phone numbers, etc Derived attribute Attributes that can be calculated (derived) from other attributes o Example: age, total, interest, due date, etc. *Unlike the relational model, these attribute are allowed in conceptual models
ERD (Entity) Complex attribute 28 Composite and multi valued attribute can also be nested arbitrarily to form complex key
ERD (Entity) Complex and composite attribute 29 Composite attributes are useful to model situations in which user refers to the composite attribute as a unit but other times refer specifically to it s components. If the composite attribute is to be referenced only as a whole then there is no need to represent it in to component attributes. Example: if there is no need to refer to the individual components of an address ( ZIP, code, street etc) then the whole address can be designated as a simple attribute.
ERD (Entity) Criteria for selecting identifiers 30 Choose identifier that will not change in value over the life of each instance of the entity type Choose identifier that is guaranteed to have valid values and will not be null (or unknown). If composite, make sure all parts will have valid values Avoid the use of intelligent identifiers whose structure indicates classifications, locations or people that might change. e.g. the first two digits of an identifier may indicate a warehouse location, but such codes are often changed as conditions change, which renders them invalid. * Some entities have more than one candidate identifier
ERD ii.relationship 31 When attribute of an entity refers to another entity type there exists relationship Describes how many entity instance can be in the relationship The relationship is often denoted by diamond symbol and are usually verbs. Example: Relationship WORKS-FOR between EMPLOYEE and DEPARTMENT associates each employee with the department for he works.
ERD (Relationship) Relationship features 32 1. Cardinality: Entity instance s participation count 2. Degree of relationship: How many entities are involved in a relationship? 3. Participation constraint: participate of an entity in relationship
ERD (Relationship features ) 1.Cardinality 33 Describes how many entity instance can be in the relationship A. Maximum cardinality (type of relationship) Describes the maximum number of entity instances that participate in a relationship 1.A.1 : One-to-one 1.A.2 : One-to-many 1.A.3 : Many-to-many B. Minimum cardinality Describes the minimum number of entity instances that must participate in a relationship
ERD (Relationship features.cardinality : Maximum cardinality ) 1.A.1 : One-to-One (1:1) 34 A single entity instance in one entity class is related to a single entity instance in another entity class ERD Notation (Crow s foot) Governor Governs / Has State *A governor governs (only) one state; a state has (only) one governor
ERD (Relationship features.cardinality : Maximum cardinality ) 1.A.2 : One-to-Many (1:N) 35 A single entity instance in one entity class (parent) is related to multiple entity instances in another entity class (child) ERD Notation (Crow s foot) books Publish / Published by Publishers *A book is published by (only) one publisher; a publisher can publish many (multiple) books
ERD (Relationship features.cardinality : Maximum cardinality ) 1.A.3 : Many-to-Many (N:N) 36 Each entity instance in one entity class is related to multiple entity instances in another entity class; and vice versa. ERD Notation (Crow s foot) books Write / Written by Authors * A book can be written by many (multiple) authors; an author can write many (multiple) books
ERD (Relationship features.cardinality : Maximum cardinality ) Example of Cardinality 37 One to one 1 1 one to many N 1 Many to many M N
ERD (Relationship features.cardinality : Minimum cardinality) 1.B : Minimum cardinality 38 Minimum cardinality describes the minimum number of instances that must participate in a relationship for any one instance Minimums are generally stated as either zero or one: 0 (optional): participation in the relationship by the entity is optional. 1 (mandatory): participation in the relationship by the entity is mandatory.
ERD (Relationship features.cardinality : Minimum cardinality) 1.B : Minimum cardinality 39 ERD Notation (Crow s foot) One to many maximum cardinality: a programmer can have many certificates; a certificate is issued to only one programmer. Write / Certificates 0 1 Written by Programmers A certificate is optional in the relationship (optional for a programmer) ; or a programmer may not have any certificates. A programmer instance is required in the relationship (a programmer is mandatory for a certificate); or a certificate has to be issued to someone.
ERD Relationship Modeling Considerations 40 I. Multiple relationships II. Transitive relationship III. Attributes of relationships IV. Promoting relationship to entity
ERD (Relationship Modeling Considerations ) I. Multiple relationships 41 Multiple relationships can exists between entities, as long as they are independent or different Supervise Faculty Teach Student Advise
ERD (Relationship Modeling Considerations ) II. Transitive relationship 42 Entities can be related indirectly by two relationship. A relationship is redundant if it can be completely represented by alternate transitive relationships Is this relationship redundant? Can Department and Student be related indirectly through these two relationships?
ERD (Relationship Modeling Considerations) III. Attributes of relationships 43 A relationship can have attributes Employee_ID Employee_Name Date_Completed Course_ID Course_Title EMPLOYEE Completes COURSE
ERD (Relationship Modeling Considerations) III. Attributes of relationships 44
ERD (Relationship Modeling Considerations) III. Attributes of relationships (part 1) 45 Attributes of 1:1 or 1:N relationship can be migrated to one of the participating entity types. Example : Start-date attributes of MANAGES can be attribute of either DEPARTMENT or EMPLOYEE though conceptually it belongs to manages each EMPLOYEE MANAGES is a 1:1 relationship every DEPARTMENT /EMPLOYEE entity participate in atmost one relationship instance value of the Start-date can be determined separately either by participating DEPARTMENT entity or participating EMPLOYEE entity
ERD (Relationship Modeling Considerations) III. Attributes of relationships (part 2) 46 For 1:N relationship a relationship attribute can be migrated only to entity type on N- side of relationship Example : Start-date attribute here can added only to employee
ERD (Relationship Modeling Considerations) III. Attributes of relationships (part 3) 47 For M:N relationship types some attribute are determined by the combination of the participating entities, not by a single enitity. Such attribute must be specified as the relationship attributes Example : No.of hours an employee works on is department is determent is determined by the EMPLOYEE-PROJECT combination.
ERD (Relationship Modeling Considerations) IV. relationship to entity 48 Relationships can be modeled as entities, particularly when they have attributes Notice the change of cardinality notations (direction)
ERD (Relationship features ) 2. Degree Of relationship 49 Describes the number of entities involved in a relationship 2.1 Unary (one entity type involved in a relationship / the same entity participates more than once in different roles ) most common 2.2 Binary (two entity types involved in a relationship ) 2.3 Ternary (three entity types involved in a relationship ) 2.4 N ary (more than 3 entity types involved in a relationship )
ERD (Relationship features. Degree Of relationship) 2.1 : Unary relationship 50 only 1 entity required in this relationship Custome r 0 0 Refer / Referred Example o A customer can refer multiple other customers, and it s optional for them to refer other customers (he/she does not have to refer anyone). o A customer can be referred by only one other customer, and his/her referee is optional (he/she does not have to be referred by anyone).
ERD (Relationship features. Degree Of relationship ) 2.1 : Example of Unary relationship 51
ERD (Relationship features. Degree Of relationship ) 2.2 : Example of Binary relationship 52
ERD (Relationship features. Degree Of relationship) 2.3 : Ternary (three entities) 53 3 entities are required in this relationship Technician Project 1 1 Example o A technician uses a notebook in a project o Notebook and project as a combination always stay together Usernotebook 1 Notebook o Any of these 3 entities has to participate the relationship
ERD (Relationship features. Degree Of relationship) 2.4 : N ary (four entities) 54 More than 3 entities are required in this relationship (four entities) Physician Example Patient operates Nurses o A physician operates on a patient, with certain nurses and supplies participating in this operation at the same time Supplies
ERD (Relationship features) 3. Participation constraint 55 Specifies if existence of an entity depends on it being related to another entity via relationship Specifies minimum number of relationship instances each entity can participate in This is called minimum cardinality constraint Participation constraint: Total (double line in diagram) Partial (existence dependencies / single line in diagram )
ERD (Relationship features) 3. Example of Participation constraint 56 if company policy says that every employee must work for the department then participation of employee in work-for is total. Every entity in total set of employee must be related to a department via WORKS-FOR * The participation of A is total (mandatory) if every entity of A must participate in at least one relationship in R. Otherwise, the participation of A is partial (optional).
ERD (Relationship features) 3. Example of Participation constraint 57
ERD (Relationship features. Participation constraint ) Alternative notations 58 associating pair of integer (min,max) with each participation of entity type in a relationship type (structural constraints) 0<=min<=max and max>=1 Min>0 == total participation Min=0 == partial participation
ERD Crow s foot Notation Summary 59
ERD Refining ER Diagrams (part 1) 60 Concept may be first modeled as an attribute and then refined in to a relationship because it is determined that an attribute is reference to another attribute A pair of such attribute that are inverses of one another are refined to as binary relationship
ERD Refining ER Diagrams (part 2) 61 An attribute that exists in several entity types may be elevated or promoted to an independent entity
ERD Refining ER Diagrams (part 3.1) 62 Choosing between binary and ternary relationship : including the ternary relationship plus one or more of the binary relationship if they represent different meaning and all are needed by the application ( i ) ( ii )
ERD Refining ER Diagrams (part 3.2) 63 Choosing between binary and ternary relationship : ternary relationship supply can be represented as the weak entity type with three identifying relationship ( ii ) ( iii )
ERD Refining ER Diagrams (part 4) 64 Dealing with ternary relationship : replacing the ternary relations hip with an entity type and a set of binary relationships
ERD Refining ER Diagrams (part 5) 65 redundant relationship : Entities can be related indirectly by two relationships * A relationship is redundant if it can be completely represented by alternate transitive relationships
ERD Refining ER Diagrams (part 6.1) 66 Confirming optionality and cardinality of relationship : using an entity set diagram" to show entity examples graphically 1.Use the diagram to show all possible relationship scenarios. 2.Go back to the requirements specification and check to see if they are allowed. 3.If not, then put a cross through the forbidden relationships This allows you to show the cardinality and optionality of the relationship
ERD Refining ER Diagrams (part 6.2) 67 Confirming optionality and cardinality of relationship
ERD Refining ER Diagrams (part 7) 68 Dividing the relationship parameters : To check we have the correct parameters (sometimes also known as the degree) of a relationship, ask two questions: 1. One course is studied by how many students? Answer = `zero or more => the degree at the `student' end The answer `zero or more' needs to be split into two parts. The `more' part means that the cardinality is `many'. The `zero' part means that the relationship is `optional'. If the answer was `one or more', then the relationship would be `mandatory'.
ERD CONSTRUCTING AN ER MODEL 69 1) Identify entities 2) Remove duplicate entities 3) List the attributes of each entity 4) Mark the primary keys 5) Define the relationships 6) Describe the cardinality and optionality of the relationships 7) Remove redundant relationships