Intro to DB CHAPTER 6

Size: px

Start display at page:

Download "Intro to DB CHAPTER 6"

Hannah Walker
5 years ago
Views:

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

2 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 by S.-g. Lee Chap 6-2

3 Introduction Proposed by P. Chen in 1976 The Entity-Relationship Model: Toward a Unified View of Data, ACM Transactions On Database Systems, Jan 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 by S.-g. Lee Chap 6-3

4 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 by S.-g. Lee Chap 6-4

5 Entity & Entity Sets - examples customer-id customer- customer- customer- loan- amount name street city number Copyright by S.-g. Lee Chap 6-5

6 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 by S.-g. Lee Chap 6-6

7 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 by S.-g. Lee Chap 6-7

8 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 by S.-g. Lee Chap 6-8

9 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 by S.-g. Lee Chap 6-9

10 Relationship Set borrower Copyright by S.-g. Lee Chap 6-10

11 Attribute of Relationship Relationships can have attributes An attribute can also be property of a relationship set. Copyright by S.-g. Lee Chap 6-11

12 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 by S.-g. Lee Chap 6-12

13 Mapping Cardinalities One to one One to many Note: Some elements in A and B may not be mapped to any elements in the other set Copyright by S.-g. Lee Chap 6-13

14 Mapping Cardinalities (cont.) Many to one Many to many Note: Some elements e e in A and B may not be mapped to any elements e e in the other set Copyright by S.-g. Lee Chap 6-14

15 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 by S.-g. Lee Chap 6-15

Ellipses represent attributes - Double ellipses represent multivalued li l attributes.

16 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 by S.-g. Lee Chap 6-16

17 Attributes Copyright by S.-g. Lee Chap 6-17

18 Relationship Sets with Attributes Copyright by S.-g. Lee Chap 6-18

19 Roles Entity sets of a relationship need not be distinct Role labels are optional, and are used to clarify semantics of the relationship Copyright by S.-g. Lee Chap 6-19

20 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 by S.-g. Lee Chap 6-20

21 Cardinality Constraints Express cardinality constraints by a directed line ( ): signifying one an undirected line ( ): signifying many Copyright by S.-g. Lee Chap 6-21

is associated with several (possibly 0) customers

22 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 by S.-g. Lee Chap 6-22

in the relationship set Partial participation: some entities may not participate

23 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 by S.-g. Lee Chap 6-23

24 Alternative Notation for Cardinality Cardinality limits can also express participation p constraints min.. max Copyright by S.-g. Lee Chap 6-24

25 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 by S.-g. Lee Chap 6-25

26 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 by S.-g. Lee Chap 6-26

27 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 by S.-g. Lee Chap 6-27

28 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 by S.-g. Lee Chap 6-28

29 Copyright by S.-g. Lee Chap 6-29

30 E-R Notations Copyright by S.-g. Lee Chap 6-30

31 Alternative E-R Notations Copyright by S.-g. Lee Chap 6-31

32 UML Class Diagram Notation Copyright by S.-g. Lee Chap 6-32

33 UML Class Diagram Notation (cont.) *Note reversal of position in cardinality constraint depiction Copyright by S.-g. Lee Chap 6-33

34 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 by S.-g. Lee Chap 6-34

35 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 by S.-g. Lee Chap 6-35

36 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 by S.-g. Lee Chap 6-36

37 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 by S.-g. Lee Chap 6-37

38 ER schema to tables (cont.) A strong entity set reduces to a table with the same attributes. Copyright by S.-g. Lee Chap 6-38

39 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 by S.-g. Lee Chap 6-39

40 Representing Weak Entity Sets A weak entity set becomes a table that includes a column for the primary key of the identifying strong entity set Copyright by S.-g. Lee Chap 6-40

41 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 by S.-g. Lee Chap 6-41

adding an extra attribute to the many side, containing the

42 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 by S.-g. Lee Chap 6-42

43 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 by S.-g. Lee Chap 6-43

44 END OF CHAPTER 6

Chapter 2: Entity-Relationship Model

Chapter 2: Entity-Relationship Model! Entity Sets! Relationship Sets! Design Issues! Mapping Constraints! Keys! E-R Diagram! Extended E-R Features! Design of an E-R Database Schema! Reduction of an E-R