Entity Relationship (ER) Modeling

ERDs
 

A diagram of the end-user view of a DB Primary goal is to model
  

Attributes Relationships Entities (duh)

They look like this!

The Types  Chen  Emphasis on modeling   Crow s !oot "#$  Both of these fo%us more on design and implementation  &n reality you %an implement your DB from either .

uired or optional (but optional %an be bad if implemented wrong-)   Attributes ' entity %hara%teristi%s   .Review  Entities ' %orresponds real-world ob(e%ts    Entity and object are used inter%hangeably Entity )et ' %olle%tion of entities Entity &nstan%e or *%%urren%e ' a parti%ular entity+ basi%ally a row in a table Represented by a named re%tangle in ERDs Conne%ted ovals in Chen and listed in the re%tangle in Crow s Can be re.

Attributes Examples .

Review  Attributes   .ave domains/ rules about what values are valid Can be simple or omposite (%omposite %an be a bit sti%0y as to whether they should be bro0en down) Can be based on a single attribute or multiple ( omposite) 1hen using %omposites you must be %areful about ma0ing sure they will be uni.ue  !denti"iers (a0a primary 0eys)   .

or multi-valued  Be %areful+ there is not ne%essarily a relationship between single-valued and being a simple attribute 1e don t implement multi-valued though.(pg 234)   Derived Attributes ' values that %an be %al%ulated or reasoned from other attributes   5hese may or may not be stored in the database 1hy6 .More on Attributes  Can be single.

Derived Attributes in ERDs .

#tored vs$ %al ulated .

%onne tivity and %ardinality .

Existen e Dependen e  An entity is existen e dependent when its only reason for being in the database is to be asso%iated with another entity  &t has a mandatory foreign 0ey attribute+ meaning it %annot be null &n terms of the %ollege database+ an Emergen%y Conta%t entity is e7isten%e dependent upon a )tudent   )omething may also be existen e independent  An e7ample might be in-state transfer %redits .

Relationship #trength  &eak or 'on(identi"ying ) the !8 and only the !8 of the related table is the P8 of another   )ales had the Agent s &D (the Agent P8) as a !8 Pretty mu%h the standard type of !8 relationship we ve been tal0ing about in our e7amples so far Drawn as a dashed line in a Crow s !oot ERD   #trong or !denti"ying ' the !8 of the related table is also involved in its P8+ along with being the P8 of another table (solid line in Crow s)  &f )ales no longer has a numeri% P8 but a %omposite of sales date+ agent &D+ and 9&: then the relationship be%omes strong .

.*ot ha  1hen %reating tables+ you must %reate the 2 side of a 2/# relationship first. why6 Also note that the way a relationship is determined is by loo0ing at the table that %ontains the foreign 0ey (the related table)  ..

Entities an be weak too!  &f a related entity is both e7isten%e-dependent and has a strong relationship with its parent+ it is a weak entity  &n Crow s foot these are represented by the %ombination of the solid line of a strong relationship and the the P8<!8 designation  5hese are not very %ommon and are up to the database designer .

&eak Entity Example .

+arti ipation  Entity relationships %an be of two types in relation to whether there is a related entity for every parent 5o determine relationship parti%ipation you have to loo0 at it both ways and determine its %ategori=ation for each direction 5he easiest way to determine these is to e7amine %ardinality   .

uired on ea%h end for the relationship to ma0e sense   &n Crow s !oot no %ir%le is assumed mandatory 5he %ardinality %an also help+ there %an be no 3 in a mandatory relationship .uire a %hild to be present  &n Crow s !oot a %ir%le is added to the related entity s end  Mandatory ' 5here is an entity re.ptional ' 1hen the parent does not re.+arti ipation Types  .

read. the diagram   !ig. >.2? Professor tea%hes 3 to @ %lasses is the relationship  5o get the part%ipation you read ba%0wards/ Class is optional to professor  A %lass is taught by 2 professor is the relationship  Professor is mandatory to %lass .-ow to .

s /oot Diagrams .%row.

*ot ha  Parti%ipation and )trength do not determine ea%h other A mandatory relationship does not imply a strong relationship (or vi%e versa) nor the same for optional<wea0 Relationship strength is determined by the %omposition of the related table s P8 Relationship participation are based on business rules (whi%h may %ontradi%t) )ee the previous diagrams     .

Things to be are"ul about  Relationships help determine the order in whi%h you %reate tables and their rows  &f you %reate a %lass entity with no asso%iated %ourse+ a temporary %ourse would have to be %reated until the offi%ial %ourse is approved  #a0e sure you understand the semanti%s of the relationship des%ription !or our e7amples+ 0eeping %ourse and %lass straight is important as well as getting the %ardinality %orre%t .

%row.s /eet %lari"i ation .

Asso iative Entities  !irst heard about these when tal0ing about #/: relationships and how a typi%al DB model does not allow them 5o over%ome the problem+ an asso%iative entity is %reate as a bridge between the two 5he idea is to turn the #/: into two 2/# relationships 5he asso%iative entity will have the P8s from ea%h table as !8s and its own P8 :o spe%ial ERD notation+ loo0 at the 0eys and strong<identifying relationships     .

ERD "or #tudent(%lass   1hat would it be6 5hin0 about the relationship between the two+ we won t worry about %ardinality  *ptional or mandatory6 .

The ERD .

ow the relationships %hangeA the optionalities get moved to the new relationships 1hat are the 0eys6 1hat else needs to be in the new table6   .Making the asso iative entity  5hings to thin0 about/  .

The new ERD .

? B Pg 2?C A highly re%ommended read .Developing an ER Diagram )e%tion >.

-omework!   Review Duestions ' ?+ @+ >+ E+ F+ 4+ 23+ 2E Problems ' 2+ ?+ E+ C .

Sign up to vote on this title
UsefulNot useful