Intro to DB CHAPTER 6 - PDF Free Download

Intro to DB CHAPTER 6 DATABASE DESIGN &THEER E-R MODEL

Chapter 6. Entity Relationship Model Design Process Modeling Constraints E-R Diagram Design Issues Weak Entity Sets Extended E-R Features Design of the Bank Database Reduction to Relation Schemas Database Design UML Copyright 2006-2008 by S.-g. Lee Chap 6-2

Introduction Proposed by P. Chen in 1976 The Entity-Relationship Model: Toward a Unified View of Data, ACM Transactions On Database Systems, Jan.1976. A very powerful tool in the design of databases Simple model Effective means of communication between user, designer, and implementer E-R model is not an implementation model i.e., there is no DBMS whose internal structures are based on the E-R model Copyright 2006-2008 by S.-g. Lee Chap 6-3

Database Modeling A database can be modeled as: a collection of entities, relationship among entities. An entity is an object that exists and is distinguishable from other objects (entity instance). Example: specific person, company, event, plant Entities have attributes t Example: people have names and addresses An entity set is a set of entities i of the same type that share the same properties. Example: set of all persons, companies, trees, holidays Copyright 2006-2008 by S.-g. Lee Chap 6-4

Attributes The descriptive properties p of an entity An entity is represented by a set of attributes Student = (id, name, dept, address, ) Value set (domain) set of permitted values for an attribute Formally: Attribute is a mapping from the entity set to the value set Domain1 Entity Set1 e1 e2 e3 Domain2 A1 e4 A2 Copyright 2006-2008 by S.-g. Lee Chap 6-6

Types of Attributes Simple vs Composite attributes Simple attribute values cannot be divided into subparts firstname, lastname, phone# Composite attribute composed of multiple parts name = (lastnm, firstnm) Phone# = (number, extension) Null attributes null value: a special ilvalue meaning missing i or unknown some attributes are not allowed to have null values Copyright 2006-2008 by S.-g. Lee Chap 6-7

Types of Attributes (cont.) Single-valued vs multivalued : Single-valued attribute each attribute has a single value for an entity id, name, dept Multivalued attribute an attribute may have more than one value for an instance children = {john, tom}, phone#={5567, 5568} Derived attributes value can be derived from the values of other related attributes or entities duration, count, sum, Copyright 2006-2008 by S.-g. Lee Chap 6-8

Relationships Relationships are defined between entities Relationship set: R = { [e 1,..., e n ] e 1 E 1,,ee n E n } E i : entity set, [e 1,..., e n ] : relationship Entity Set1 e1 e2 e3 e4 Relationship Set Entity Set2 f1 f2 f3 f4 f5 Copyright 2006-2008 by S.-g. Lee Chap 6-9

Mapping Constraints Relationship cardinality Number of entities to which another entity can be associated via a relationship set Generic types 1 : 1 1 : m m:1 m : n Relationship eato pcardinality a can affect the placement pace e tof relationship eato attributes Copyright 2006-2008 by S.-g. Lee Chap 6-12

Mapping Cardinalities affect ER Design Can make access-date an attribute of account, instead of a relationship attribute, if each account can have only one customer Copyright 2006-2008 by S.-g. Lee Chap 6-15

E-R Diagrams Rectangles represent entity sets. Diamonds represent relationship sets. Lines link attributes to entity sets and entity sets to relationship sets. Ellipses represent attributes - Double ellipses represent multivalued li l attributes. - Dashed ellipses denote derived attributes. Underline indicates primary key attributes Copyright 2006-2008 by S.-g. Lee Chap 6-16

m-ary Relationships Most relationships are binary R = { [e 1, e 2 ] e 1 E 1, e 2 E 2 } You can define non-binary relationships R = { [e 1, e 2, e 3 ] e 1 E 1, e 2 E 2, e 3 E 3 } : ternary Copyright 2006-2008 by S.-g. Lee Chap 6-20

Many-To-Many yrelationship A customer is associated with several (possibly 0) loans via borrower A loan is associated with several (possibly 0) customers via borrower Copyright 2006-2008 by S.-g. Lee Chap 6-22

Participation in a Relationship Total participation p (indicated by double line): every entity in the entity set participates in at least one relationship in the relationship set Partial participation: some entities may not participate in any relationship in the relationship set Copyright 2006-2008 by S.-g. Lee Chap 6-23

Weak Entity Sets Strong entity Regular entity with its own primary key Weak entity An entity set that does not have sufficient attributes to form a primary key B# Bus Seat S# Time Type A weak entity set is dependent on a strong entity set Primary key of a weak entity set = primary key of its dominant entity set + its descriminator B# + S# Copyright 2006-2008 by S.-g. Lee Chap 6-25

Weak Entity Sets (Cont.) Depict a weak entity set by double rectangles. Underline the discriminator with a dashed line. Primary key for payment (loan-number, payment-number) Copyright 2006-2008 by S.-g. Lee Chap 6-26

Existence Dependencies If the existence of entity x depends on the existence of entity yy, then x is said to be existence dependent on y. y is a dominant entity (in example below, loan) ) x is a subordinate entity (in example below, payment) loan loan-payment payment If a loan entity is deleted, then all its associated payment entities must be deleted eted also. Copyright 2006-2008 by S.-g. Lee Chap 6-27

Extended E-R Features Specialization The process of designating i subgroupings within ihi an entity set (ex. account - savings-account, checking account) a subentity will share common attributes asubentitywill have its own specific attributes Generalization combine a number of entity sets that share the same features into a higher-level entity set opp: specialization - depends on where you start Inheritance The attributes and relationships of the higher-level entity sets are inherited by (applies to) the lower-level entity sets Types of generalization (super-sub entities) Disjoint vs Overlapping: whether an entity can belong to more than two sub entity set Total vs Partial: whether every higher level entity belong to a lower level entity set Copyright 2006-2008 by S.-g. Lee Chap 6-28

Design Issues Entity vs Attribute an employee s telephone as an attribute : simple as an entity : independent Decision should be based on whether the telephone must be treated as an independent entity the number of telephones an employee can have whether telephones are shared between employees Entity vs Relationship "customer having an account at a branch" account as relationship : simple but limited (cannot participate in other relationships) account as entity : account can act as separate entity Copyright 2006-2008 by S.-g. Lee Chap 6-34

Design Issues (cont.) Binary vs n-ary relationships all n-ary relationships can be represented by binary relationships by adding additional entities and corresponding relationships however, this is not always desirable => decision should be based on how the model best represents the real world situation i Strong or weak entity set Generalization and specialization Aggregation g Copyright 2006-2008 by S.-g. Lee Chap 6-35

Design Phases Requirement specification identify data needs of user Conceptual design translate into a conceptual schema Logical design map onto the implementation data model of the DBMS Physical design specify physical features of the database (issues pertaining to performance rather than information contents; index, sequential order, etc.) Copyright 2006-2008 by S.-g. Lee Chap 6-36

Reducing ER schema to tables Basic rule each entity set => unique table each relationship set => unique table Strong entity set E with attributes a 1,..., a n table E with n distinct columns each of which corresponds to a i D i : set of all values (domain) for a i table E will contain elements of D 1 X...X D n Copyright 2006-2008 by S.-g. Lee Chap 6-37

ER schema to tables (cont.) Relationship set R involving E 1,..., E k => table R with columns corresponding to PK(E 1 ) U... U PK(E k ) U attr(r) if one-to-many or one-to-one E 1 R E 2 => add columns representing PK(E 1 ) U attr(r) to table representing E 2 Copyright 2006-2008 by S.-g. Lee Chap 6-39

Representing Relationship Sets many-to-many yrelationship set: as a table with the primary keys of the two participating entity sets + any descriptive attributes Copyright 2006-2008 by S.-g. Lee Chap 6-41

Redundancy of Tables Many-to-one and one-to-many relationship sets that are total on the many-side can be represented by adding an extra attribute to the many side, containing the primary key of the one side Copyright 2006-2008 by S.-g. Lee Chap 6-42

Generalization Account <= savings, checking General case Create a table for the higher level entity set For each subentity, create a table that includes the attributes of that entity set plus the primary key of the higher level entity savings checking If disjoint and complete account For each subentity, create a table that includes the attributes of that entity plus the super entity savings checking Copyright 2006-2008 by S.-g. Lee Chap 6-43

END OF CHAPTER 6