Modelling Data in Organisation Entity-Relationship Model MGIS 641 Koç University

Learning objectives Define the terms business rule, entity type, attribute, relationship, cardinality,strong/weak entity, gerund ... Entity types, classification of attributes Distinguish between unary, binary & ternary relationships Model multi-valued attributes & repeating groups in an E-RD Convert many to many relationships to associative entities Model simple time-dependent data using time stamps in E-RD

Introduction E-R model remains the main stream approach for conceptual data modeling relative ease of use CASE tool support Entities-relationships natural modeling way in the real world E-R model used as a tool for communication between end-users & DB designers during analysis phase used to construct a conceptual data model - representation of the structure of DB independent of DBMS S/W. Introduced by Chen no standard notation - evolving

DB development process Planning Enterprise data model Analysis Conceptual data model Logical DB design Logical data model Physical DB design Technology model Implementation DB & repositories

Business Rules Statements that define or constrain some aspect of the business A Good Business Rule is: Declarative – what, not how Precise – clear, agreed-upon meaning Atomic – one statement Consistent – internally and externally Expressible – structured, natural language Distinct – non-redundant Business-oriented – understood by business people

Introduction to E-R model E-R model : A detailed, logical representation of the entities, associations & data elements for an organisation/business area An E-R model is normally expressed as an E-R diagram which is a graphical representation of an E-R model E-R model may also be used to represent enterprise data model a well as conceptual data model (detailed E-RD) Major constructs of E-R D are entities, relationships & associated attributes

E-R Model Constructs Entity instance - person, place, object, event, concept (often corresponds to a row in a table) Entity Type – collection of entities (often corresponds to a table) Attribute - property or characteristic of an entity type (often corresponds to a field in a table) Relationship– link between entities 2

Sample E-R Diagram 3

E-R notation Basic symbols : Entity Relationship Primary key Attribute Multivalued attribute Gerund Relationship degree : Ternary Unary Binary Mandatory 1 cardinality Many(M) cardinality (1,2,.. ,many) Optional 0 or 1 cardinality Relationship cardinality: Class-subclass relationship Exclusive relationship Optional zero-many cardinality (0,1,2, ..., many)

A special entity that is also a relationship Basic E-R Notation A special entity that is also a relationship Entity symbols Attribute symbols Relationship symbols 8

Entities Entity type (entity class): A collection of entities that share common properties or characteristics e.g. EMPLOYEE, STUDENT STATE, REGION, COUNTRY MACHINE, BUILDING SALE, REGISTRATION ACCOUNT, COURSE EMPLOYEE COURSE ACCOUNT Entity Instance : A single occurrence of an entity type Entity Type : EMPLOYEE Attributes :EMPLOYEE NUMBER NAME ADDRESS CITY STATE ZIP Instance of EMPLOYEE 00-56-7778 Ahmet Aslan RumeliFeneri Yolu. No.5 Sarıyer Istanbul 80860

What Should an Entity Be? SHOULD BE: An object that will have many instances in the database An object that will be composed of multiple attributes An object that we are trying to model SHOULD NOT BE: A user of the database system An output of the database system (e.g. a report)

Inappropriate entities System output System user Appropriate entities

Attributes Attribute : A named property or characteristic of an entity that is of interest to the organisation e.g. STUDENT : STUDENTNO., NAME, ADDRESS, PHONE NO. AUTOMOBILE : VEHICLE ID, COLOUR, WEIGHT EMPLOYEE : EMPLOYEE NO. , NAME, ADDRESS, SKILL Classifications of attributes: Simple versus Composite Attribute Single-Valued versus Multi-valued Attribute Stored versus Derived Attributes Identifier Attributes NAME SKILL COLOUR

Identifiers (Keys) Identifier (Key) - An attribute (or combination of attributes) that uniquely identifies individual instances of an entity type Simple Key versus Composite Key Candidate Key – an attribute that could be a key…satisfies the requirements for being a key 6

Characteristics of Identifiers Will not change in value Will not be null No intelligent identifiers (e.g. containing locations or people that might change) Substitute new, simple keys for long, composite keys 7

Candidate keys identifier selection Every entity type must have an attribute/set of attributes that uniquely identifies each instance & clearly distinguishes that instance from other instances of the same type Candidate key : an attribute/combination of attributes that uniquely identifies each instance of an entity type e.g. STUDENT NO Entity Type : GAME Entity Type : EMPLOYEE Attributes Then EMPLOYEE No, HOME TEAM NAME+ADDRESS => Candidate keys VISITING TEAM REFEREE DATE RESULT then HOME TEAM + VISTING TEAM =.> Candidate key Identifier-Primary Key : A candidate key selected as the identifier for an entity - may not be null

Primary key selection Choose a candidate key which will not change its value over the life of each instance of the entity type e.g. NAME+ADDRESS could change Choose a candidate key such that for each instance of the entity, the attribute/combinations of attributes is guaranteed to have valid values & not to be null e.g. GAME type DATE may be used but fixture may not be ready Avoid the use of intelligent keys, whose structure indicates classifications, locations ... e.g. first two digits may indicate warehouse location, but they may change as the conditions change => invalid primary key Consider substituting single-attribute keys for large composite keys e.g. HOME TEAM+VISITING TEAM => GAME NO NAME ADDRESS STUDENT NO PHONE NO STUDENT

An attribute broken into component parts A composite attribute An attribute broken into component parts 12

Simple key attribute The key is underlined 14

Composite key attribute The key is composed of two subparts 15

Entity with a multi-valued attribute (Skill) and derived attribute (Years_Employed) from date employed and current date Multivalued: an employee can have more than one skill 13

an attribute that is both multi-valued and composite This is an example of time-stamping 37

Multi-valued attributes Multi-valued attribute : An attribute that can have more than one value for each entity instance During conceptual design highlight them Subsequently normalise entity data - remove multi-valued attributes & place them in a separate entity type EMPLOYEE NO NAME ADDRESS SKILL EMPLOYEE

Relationships Relationship : An association between the instances of one or more entity types that is of interest to the organisation glue that holds the various E-R model components together e.g. Registrar interested in tracking who has completed what courses => relationship completes STUDENT Completes COURSE Many to many

Relationships STUDENT NO. COURSE TITLE DATE COMPLETED 4545-5656 MGIS 688 JUNE 04 5676-7888 MGIS 408 SEPT 05 MGIS 698 OCT 04 Date Completed is not an attribute of STUDENT entity type since Student with No. 4545-5656 has completed courses on different dates. It is not an attribute of COURSE entity type since MGIS 641 may be completed on different dates. It is a property of Completes relationship. DATE COMPLETED STUDENT COURSE Completes

Degree of relationship Degree of a relationship : Number of entities that participate in that relationship three common type of relationships Unary Binary Ternary e.g. Completes relationship between STUDENT & COURSE is a degree two relationship as it involves two entity types.

Unary relationship Unary (recursive) relationship : relationship between the instances of one entity type PERSON is married to One-to-One EMPLOYEE Manages Has ITEM Components One-to-many Many-to-many QUANTITY A V X Y U (1) (2) (3) B Z W

Binary relationship Binary relationship : Relationship between the instances of two entity classes. Most common type of relationship encountered Is EMPLOYEE PARKING PLACE Assigned One-to-One PRODUCT LINE Contains PRODUCT One-to-many STUDENT Registers COURSE for Many-to-many

Ternary relationship Ternary relationship : Simultaneous relationship among the entities of three entity types QUANTITY WAREHOUSE VENDOR Ships PART

Cardinalities in relationships Cardinality : The number of instances of an entity type that can (must) be associated with each instance of any other entity type MOVIE MOVIE COPY is stocked as One-to-many

Minimum & maximum cardinalities Minimum cardinality : Minimum no. of instances of an entity type that may be associated with each instance of any other entity type Maximum cardinality : Maximum no. of instances of an entity type that may be associated with each instance of any other entity type MOVIE MOVIE COPY is stocked as One-to-many max = one max = many minimum =0 minimum = one (mandatory) (optional)

examples of cardinalities PATIENT Has PATIENT HISTORY Mandatory cardinalities 3 EMPLOYEE Is Assigned to PROJECT One optional one mandatory Is PERSON married to Optional cardinalities

Associative Entity-Gerund Many-to-many relationships may have attributes => they may be entities in disguise Gerund (associative entity) : A many-to-many relationship that a data modeler chooses to model as an entity type with several associated one-to-many relationships with other entity types SHIPMENT NO QUANTITY WAREHOUSE VENDOR SHIPMENT PART

Associative Entities-Gerunds It’s an entity – it has attributes AND it’s a relationship – it links entities together

An associative entity (CERTIFICATE) Associative entity involves a rectangle with a diamond inside. Note that the many-to-many cardinality symbols face toward the associative entity and not toward the other entities 21

an associative entity – bill of materials structure This could just be a relationship with attributes…it’s a judgment call 27

Ternary relationship as an associative entity 36

Existence dependency Existence dependency : An instance of an entity type cannot exist without the existence of an instance some other (related) entity Existence dependency - result of mandatory one cardinality Weak entity : An entity type that has an existence dependency MOVIE Is Stocked as MOVIE COPY

Identifying relationship Identifying relationship : A relationship in which the primary key of the parent entity is used as part of the primary key of dependent (child) entity MOVIE NO MOVIE NAME MOVIE NO COPY NO MOVIE Is Stocked as MOVIE COPY Two benefits of an identifying relationship : 1) Data integrity. Existence dependencies are enforced since the primary keys is shared - a weak entity cannot exist unless the parent entity exists 2) Ease of access of dependent entity. e.g. if Movie No + Copy No known movie copy can be located.

Strong and weak entities Strong entity Weak entity Identifying relationship

Multiple relationships entities can be related to one another in more than one way Employees and departments 40

Another example multiple relationships -professors and courses Here,max cardinality constraint is 4 41

Modeling multi-valued attributes During later stages of conceptual design multi-valued attributes are removed from the entities - converted to a separate entity EMPLOYEE NO NAME ADDRESS SKILL EMPLOYEE SKILL NAME ADDRESS EMPLOYEE NO NAME SKILL EMPLOYEE Has

Repeating groups Repeating Group : A set of two or more multivalued attributes that are logically related. PATIENT CHART Date of Visit Physician Symptom 1/5/05 Orkun Cold 2/5/05 Utku Fever 3/5/05 Arzu Soar Throat Patient No : 554545 Patient Name : OAY Address :K.U. Sarıyer PATIENT NO NAME ADDRESS PATIENT DATE OF VISIT SYMPTOM PHYSICIAN

Repeating Group Removed NAME PATIENT NO ADDRESS PATIENT NO Has PATIENT PATIENT HISTORY PHYSICIAN SYMPTOM DATE OF VISIT

Modeling Time Dependent Data Time Stamp : A time value that is associated with any data value PRODUCT NO PRICE EFFECTIVE DATE PRODUCT PRICE EFFECTIVE DATE PRODUCT NO PRODUCT Has PRICE HISTORY PRODUCT NO

Detailed E-R diagram for Pine Valley Furniture