Entity Relationship (E-R) Modeling Hachim Haddouti Chapter 3 Entity Relationship (E-R) Modeling Hachim Haddouti

In this chapter, you will learn: What a conceptual model is and what its purpose is The difference between internal and external models How internal and external models serve the database design process How relationships between entities are defined and refined, and how such relationships are incorporated into the database design process How ERD components affect database design and implementation How to interpret the modeling symbols for the four most popular E-R modeling tools That real-world database design often requires you to reconcile conflicting goals Hachim Haddouti, CH3, see also Rob & Coronel

Hachim Haddouti, CH3, see also Rob & Coronel Why Data Modeling Database designers, programmers and end users have different views of the data Data modeling abstracts real-world complexities to facilitate communication between designers, programmers and end users A data model is a relatively simple, usually graphic representation of real-world data structures, their characteristics, constraints, relations and transformations It is necessary for good database design and, hence, good applications Hachim Haddouti, CH3, see also Rob & Coronel

Data Models: Degrees of Data Abstraction Hachim Haddouti, CH3, see also Rob & Coronel

Degrees of Abstraction Conceptual Global view of data Basis for identification and description of main data items ERD used to represent conceptual data model Hardware and software independent Internal Representation of database as seen by DBMS Adapts conceptual model to specific DBMS Software dependent Hachim Haddouti, CH3, see also Rob & Coronel

Degrees of Abstraction (con’t.) External Users’ views of data environment (functional modules) Provides subsets of internal view (student registration, class scheduling) Makes application program development easier Facilitates designers’ tasks Ensures adequacy of conceptual model Ensures security constraints in design Physical Lowest level of abstraction Software and hardware dependent Requires definition of physical storage devices and access methods Hachim Haddouti, CH3, see also Rob & Coronel

The Entity Relationship (E-R) Model E-R Model: graphical data representation Represents conceptual view Main Components Entities (real world objects) Corresponds to entire table, not row Represented by rectangle E.g. PERSON, PLACE, BOOK, CAR, EMPLOYEE An entity set is a set of entities of the same type that share the same properties. E.g: set of all persons, companies, trees, holidays Attributes Relationships Complementary of Relational Model ( an entity corresponds to a relational table, an entity occurrence to a row) Hachim Haddouti, CH3, see also Rob & Coronel

Hachim Haddouti, CH3, see also Rob & Coronel Attributes Characteristics of entities Domain is set of possible values, e.g. GPA(0,4) Primary keys underlined Hachim Haddouti, CH3, see also Rob & Coronel

Hachim Haddouti, CH3, see also Rob & Coronel Attributes (con’t.) Simple Cannot be subdivided Age, sex, marital status Composite Can be subdivided into additional attributes Address into street, city, zip Single-valued Can have only a single value Person has one social security number Multi-valued Can have many values Person may have several college degrees, phone numbers Implementation!!! Derived Can be derived with algorithm Age can be derived from date of birth Hachim Haddouti, CH3, see also Rob & Coronel

Hachim Haddouti, CH3, see also Rob & Coronel Relationships Association between entities Connected entities are called participants Operate in both directions Connectivity describes relationship classification 1:1, 1:M, M:N Cardinality Expresses number of entity occurrences/instances associated with one occurrence of related entity Hachim Haddouti, CH3, see also Rob & Coronel

Connectivity and Cardinality in an ERD (business rules) Hachim Haddouti, CH3, see also Rob & Coronel

Relationship Strength Existence dependence Entity’s existence depends on existence of related entities EMPLOYEE claims DEPENDENT Weak relationship (non-identifying) One entity is existence-independent on another PK of related entity doesn’t contain PK component of parent entity Strong relationship (identifying) One entity is existence-dependent on another PK of related entity contains PK component of parent entity Hachim Haddouti, CH3, see also Rob & Coronel

Relationship Participation Optional Entity occurrence does not require a corresponding occurrence in related entity Shown by drawing a small circle on side of optional entity on ERD E.g. INVOICE is optional to CUSTOMER, or INVOICE and PRODUCT Mandatory Entity occurrence requires corresponding occurrence in related entity If no optionality symbol is shown on ERD, it is mandatory Hachim Haddouti, CH3, see also Rob & Coronel

Example of Optional Entitites Hachim Haddouti, CH3, see also Rob & Coronel

Hachim Haddouti, CH3, see also Rob & Coronel Weak Entity Existence-dependent on another entity Has primary key that is partially or totally derived from parent entity Hachim Haddouti, CH3, see also Rob & Coronel

Hachim Haddouti, CH3, see also Rob & Coronel Relationship Degree Indicates number of associated entities Unary Single entity Recursive Exists between occurrences of same entity set Binary Two entities associated Ternary Three entities associated Hachim Haddouti, CH3, see also Rob & Coronel

Three Types of Relationships Hachim Haddouti, CH3, see also Rob & Coronel

Hachim Haddouti, CH3, see also Rob & Coronel Composite Entities Used to ‘bridge’ between M:N relationships Bridge entities composed of primary keys of each entity needing connection Hachim Haddouti, CH3, see also Rob & Coronel

Hachim Haddouti, CH3, see also Rob & Coronel Bridge Entity Hachim Haddouti, CH3, see also Rob & Coronel

Entity Supertypes and Subtypes Generalization hierarchy Depicts relationships between higher-level supertype and lower-level subtype entities Supertype has shared attributes Subtypes have unique attributes Disjoint relationships Unique subtypes Non-overlapping Indicated with a ‘G’ Overlapping subtypes use ‘Gs’ Symbol Hachim Haddouti, CH3, see also Rob & Coronel

Generalization Hierarchy with Overlapping Subtypes Hachim Haddouti, CH3, see also Rob & Coronel

Comparison of E-R Modeling Symbols Alternate styles developed to enable easier use of CASE tools Chen Moved conceptual design into practical database design arena Crow’s Foot Cannot detail all cardinalities Rein85 Similar to Crow’s Foot Operates at higher level of abstraction IDEF1X Derivative of ICAM studies in the late 1970’s Uses fewer symbols Hachim Haddouti, CH3, see also Rob & Coronel

Comparison of E-R Modeling Symbols Hachim Haddouti, CH3, see also Rob & Coronel

Challenge of Database Design: Conflicting Goals Database must be designed to conform to design standards High-speed processing may require design compromises Quest for timely information may be the focus of database design Other concerns Security Performance Shared access Integrity Hachim Haddouti, CH3, see also Rob & Coronel

Entity-Relationship Model Example of schema in the entity-relationship model Hachim Haddouti, CH3, see also Rob & Coronel

A Sample Relational Database Hachim Haddouti, CH3, see also Rob & Coronel

E-R Diagram for Insurance Hachim Haddouti, CH3, see also Rob & Coronel

Draw ERD for Ifrane School The Ifrane School (IS) has contacted you to create a conceptual model whose application will meet the expected database requirements for its training program. Those are their business rules: IS has 12 instructors and can handle up to 30 trainees per class. IS offers five "advanced technology" courses, each of which may generate several classes. If a class has fewer than 10 trainees in it, it will be canceled. It is, therefore, possible for a course not to generate any classes during a session. Each class is taught by one instructor. Each instructor may teach up to two classes or may be assigned to do research. Each trainee may take up to two classes per session. Hachim Haddouti, CH3, see also Rob & Coronel

Interpretation of IS biz Rules Basically, 3 sets of relationships exist: A COURSE may generate one or more CLASSes, an INSTRUCTOR teaches up to two CLASSes, and a TRAINEE may enroll in up to two CLASSes. A trainee can take more than one class, and each class contains many (10 or more) trainees, so there is a M:N relationship between TRAINEE and CLASS. A class is taught by only one instructor, but an instructor can teach up to two classes. Therefore, there is a 1:M relationship between INSTRUCTOR and CLASS. Finally, a COURSE may generate more than one CLASS, while each CLASS is based on one COURSE, so there is a 1:M relationship between COURSE and CLASS. Note the optional and mandatory relationships: a CLASS must have TRAINEEs enrolled in it, but TRAINEEs do not necessarily take CLASSes. (Some may take "on the job training.") An INSTRUCTOR may not be teaching any CLASSes, doing research instead, but each CLASS must have an INSTRUCTOR. If not enough people sign up for a CLASS, a COURSE may not generate any CLASSes, but each CLASS must represent a COURSE. Hachim Haddouti, CH3, see also Rob & Coronel

Hachim Haddouti, CH3, see also Rob & Coronel ERD for Ifrane School Hachim Haddouti, CH3, see also Rob & Coronel