intro to db chapter 6 database designdatabase...

CHAPTER 6Intro to DB

CHAPTER 6DATABASE DESIGNDATABASE DESIGN& THE E R MODEL& THE E-R MODEL

Chapter 6. Entity Relationship Modelp y p

Design ProcessgModelingConstraintsConstraintsE-R Diagram Design Issues Weak Entity Sets yExtended E-R FeaturesDesign of the Bank DatabaseDesign of the Bank DatabaseReduction to Relation SchemasDatabase DesignUML

Original Slides:© Silberschatz, Korth and Sudarshan

Intro to DB (2008-1)Copyright © 2006 - 2008 by S.-g. Lee Chap 6 - 2

Introduction

Proposed by P. Chen in 1976p y“The Entity-Relationship Model: Toward a Unified View of Data”, ACM Transactions On Database Systems, Jan.1976.Data , ACM Transactions On Database Systems, Jan.1976.

A very powerful tool in the design of databasesA very powerful tool in the design of databasesSimple modelEffective means of communication between user designer andEffective means of communication between user, designer, and implementer

E-R model is not an implementation modeli.e., there is no DBMS whose internal structures are based on the E-Ri.e., there is no DBMS whose internal structures are based on the E R model



Database Modelingg

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).j ( y )

Example: specific person, company, event, plantEntiti s h tt ib tEntities have attributes

Example: people have names and addressesA i i f i i f h h h hAn entity set is a set of entities of the same type that share the same properties.Example: set of all persons, companies, trees, holidays



Entity & Entity Sets - examplesy y pcustomer-id customer- customer- customer- loan- amount

name street city number



Attributes

The descriptive properties of an entityp p p yAn entity is represented by a set of attributes

Student = (id, name, dept, address, …)Student (id, name, dept, address, …)

Value set (domain)set of permitted values for an attributeset of permitted values for an attributeFormally: Attribute is a mapping from the entity set to the value set

Entity Set1Domain1e1

Domain2e1

e2e3

e4

A1 A2



Types of Attributesyp

Simple vs Composite attributesp pSimple attribute

values cannot be divided into subpartsfirstname, lastname, phone#

Composite attributecomposed of multiple partsname = (lastnm, firstnm)Phone# = (number extension)Phone# = (number, extension)

Null attributesll l i l l i “ i i ” “ k ”null value: a special value meaning “missing” or “unknown”

some attributes are not allowed to have null values



Types of Attributes (cont.)yp ( )

Single-valued vs multivalued :gSingle-valued attribute

each attribute has a single value for an entityid, name, dept

Multivalued attributean attribute may have more than one value for an instancechildren = {john, tom}, phone#={5567, 5568}

D i d ibDerived attributesvalue can be derived from the values of other related attributes or entitiesd iduration, count, sum, …



Relationshipsp

Relationships are defined between entitiespRelationship set:

R = { [e1 e ] | e1∈E1 e∈E }R { [e1, ..., en] | e1∈E1, …, en∈En}Ei : entity set,[e1 e ] : relationship[e1,..., en] : relationship

Entity Set1 Entity Set2Entity Set1e1

e2e3

yf1

f2f3e3

e4

f3

f4f5

Relationship Set



Relationship Set borrowerp



Attribute of Relationshipp

Relationships can have attributespAn attribute can also be property of a relationship set.



Mapping Constraintspp g

Relationship cardinalityp d yNumber of entities to which another entity can be associated via a relationship setrelationship set

Generic types1 : 11 : mm : 1m : 1m : n

Relationship cardinality can affect the placement of relationshipe at o s p ca d a ty ca a ect t e p ace e t o e at o s pattributes



Mapping Cardinalitiespp g

One to one One to many



Note: Some elements in A and B may not be mapped to any elements in the other set

Mapping Cardinalities (cont.)pp g ( )

Many to one Many to many

Note: Some elements in A and B may not be mapped to any elements in the other set



Note: So e e e e ts a d ay ot be apped to a y e e e ts the othe set

Mapping Cardinalities affect ER Designpp g g

Can make access-date an attribute of account, instead of a relationship pattribute, if each account can have only one customer



E-R Diagramsg

Rectangles represent entity sets.Diamonds represent relationship sets.Lines link attributes to entity sets and entity sets to relationship sets.Ellipses represent attributes

D bl lli l i l d ib- Double ellipses represent multivalued attributes.- Dashed ellipses denote derived attributes.

Underline indicates primary key attributes



p y y

Attributes



Relationship Sets with Attributesp



Roles

Entity sets of a relationship need not be distincty pRole labels are optional, and are used to clarify semantics of the relationshiprelationship



m-ary Relationshipsy p

Most relationships are binaryp yR = { [e1, e2] | e1∈E1, e2∈E2 }

You can define non-binary relationshipsYou can define non binary relationshipsR = { [e1, e2 , e3] | e1∈E1, e2∈E2, e3∈E3 } : ternary



Cardinality Constraintsy

Express cardinality constraints by p y ya directed line (→): signifying “one” an undirected line (—): signifying “many”



Many-To-Many Relationshipy y p

A customer is associated with several (possibly 0) loans via (p y )borrowerA loan is associated with several (possibly 0) customers viaA loan is associated with several (possibly 0) customers via borrower



Participation in a Relationshipp p

Total participation (indicated by double line): every entity in the p p ( y ) y yentity set participates in at least one relationship in the relationship setPartial participation: some entities may not participate in any relationship in the relationship setp p



Alternative Notation for Cardinality

Cardinality limits can also express participation constraints

y

y p p pmin .. max



Weak Entity Sets

Strong entity

y

g yRegular entity with its own primary key

Weak entityWeak entityAn 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 setPrimary key of a weak entity set = primary key of its dominantPrimary key of a weak entity set = primary key of its dominantentity set + its descriminator

B# + S#B# + S#



Weak Entity Sets (Cont.)y ( )

Depict a weak entity set by double rectangles.p y y gUnderline the discriminator with a dashed line.Primary key for paymentPrimary key for payment

(loan-number, payment-number)



Existence Dependenciesp

If the existence of entity x depends on the existence of entity y, y p y ythen x is said to be existence dependent on y.

y is a dominant entity (in example below, loan)y y ( p )x is a subordinate entity (in example below, payment)

l loan-payment paymentloan

If a loan entity is deleted, then all its associated payment entities must be deleted also.ust be de eted a so.



Extended E-R Features

SpecializationTh f d i i b i i hi iThe process of designating subgroupings within an entity set

(ex. account - savings-account, checking account)a subentity will share common attributesa subentity will have its own specific attributes

Generalizationcombine a number of entity sets that share the same features into a higher-levelcombine a number of entity sets that share the same features into a higher levelentity setopp: specialization - depends on where you start

InheritanceInheritanceThe attributes and relationships of the higher-level entity sets are inherited by (applies to) the lower-level entity sets

T f li i ( b i i )Types of generalization (super-sub entities)Disjoint vs Overlapping:

whether an entity can belong to more than two sub entity sety g yTotal vs Partial:

whether every higher level entity belong to a lower level entity set



E-R Notations



Alternative E-R Notations



UML Class Diagram Notationg



UML Class Diagram Notation (cont.)g ( )

*Note reversal of position in cardinality constraint depiction



p y p

Design Issuesg

Entity vs Attributeyan employee’s telephone

as an attribute : simpleas an entity : independent

Decision should be based onwhether the telephone must be treated as an independent entity the number of telephones an employee can havewhether telephones are shared between employeeswhether telephones are shared between employees

Entity vs Relationship" t h i t t b h""customer having an account at a branch"account as relationship : simple but limited (cannot participate in other relationships)relationships)account as entity : account can act as separate entity



Design Issues (cont.)

Binary vs n-ary relationships

g ( )

y y pall n-ary relationships can be represented by binary relationships by adding additional entities and corresponding relationshipshowever, this is not always desirable => decision should be based on how the model best represents the real world i isituation

Strong or weak entity setGeneralization and specializationAggregationgg g



Design Phases

Requirement specificationRequirement specification

g

q p fq p fidentify data needs of user

Conceptual designConceptual designConceptual designConceptual designtranslate into a conceptual schema

Logical designLogical designLogical designLogical designmap onto the implementation data model of the DBMS

Ph i l d i nPh i l d i nPhysical designPhysical designspecify physical features of the database (issues pertaining to performance rather than information contents; index sequential order etc )rather than information contents; index, sequential order, etc.)



Reducing ER schema to tables

Basic rule

g

each entity set => unique tableeach relationship set => unique table

Strong entity set E with attributes a1, ..., antable E with n distinct columns each of which corresponds to aip iDi : set of all values (domain) for aitable E will contain elements of

D1 X . . . X Dn



ER schema to tables (cont.)( )

A strong entity set reduces to a table with the same attributes.g y



ER schema to tables (cont.)

Relationship set R

( )

pinvolving E1, ..., Ek=> table R with columns corresponding to=> table R with columns corresponding to

PK(E1) U ... U PK(Ek) U attr(R)

if one-to-many or one-to-one

E1 R E2

> dd l i PK(E ) U tt (R) bl i E=> add columns representing PK(E1) U attr(R) to table representing E2



Representing Weak Entity Setsp g y

A weak entity set becomes a table that includes a column for the yprimary key of the identifying strong entity set



Representing Relationship Setsp g p

many-to-many relationship set:y y pas a table with the primary keys of the two participating entity sets + any descriptive attributessets any descriptive attributes



Redundancy of Tablesy

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



Generalization

Account

END OF CHAPTER 6END OF CHAPTER 6

intro to db chapter 6 database designdatabase...

Documents