Copyright © 2003 Addison-Wesley Jesper Rosholm Tørresø.

Copyright © 2003 Addison-Wesley

Jesper Rosholm Tørresø


Data Modeling with ER Diagrams

• What is an Entity-Relationship Model?• How is an E-R model represented as an E-R diagram?• How can BigHit Video be modeled as an E-R diagram?• What is a role in a relationship type?• How can we record the history of video rentals?• How are cardinalities and related to roles?• How can we represent purchase orders?• How can we represent time cards and pay statements?• What is an object-oriented data model?


Entity-Relationship Modeling *

• An E-R model is a data model that includes– Entity classes– Attributes of each class– Relationship types between classes– Constraints

• Types of attributes• Designation of key attributes• Cardinalities of relationship types

• An E-R Model is typically represented graphically– E-R diagram, the technique we use (“We” is the book)– UML diagram, an emerging standard for specifying E-R models

and software design (!! The one we/I4DAB1 also will use/jrt !!)


Entity Relationship Diagrams *

• Sample diagram for entity class Customer

lastName accountIdfirstName

numberRentals

balance

otherUsers

AttributeKey

Attribute

DerivedAttribute

Multi-valued

Attribute

Customer

address

zipcode

statecity

street

CompositeAttribute

ComponentAttribute

EntityClass


UML and ER diagrams *

• Simple class diagram (no method or properties shown)

• Class diagram with relationship.

navnadressepostnr

by

VAREKUNDE

BeskrivelsePris

navnadressepostnr

by

KUNDE ORDRE

afgiver


E-R Diagram for Class Video *

• Sample diagram for entity class Video

EntityClass

Attribute

KeyAttribute

Video

videotapeId title genre

length

dateAcquired

rating


For a short, a comment.. *

• Every object in a object system (i.e. the object oriented code performing an application) has a unique reference to it, otherwise it is lost, that means object data, attributes, are lost an can not be accessed.

• In a database, it is something similar, every piece of data (i.e. tuples/records/rows or posts) may* have a unique identifier, a key, to ensure access to data. *”may have” not necessarily “must have”

• In both case when we are modeling the system we do think about the reference/key constraint. But not at the beginning of process (Iterative development)


Relationship Types *

• Example of representing relationship type Owns between classes Store and Video

RelationshipType

EntityClass

RelationshipAttribute

Store VideoOwns

costpurchase

Date

EntityClass

IsOwnedBy

AlternateRelationship

Name


Constraints on Relationship Types *

• Example of cardinality and participation constraints

to-manyrelationship

role

Store VideoOwns

costpurchase

DateTo-one

relationshiprole

OptionalparticipationConstraint

MandatoryparticipationConstraint

1 M

IsOwnedBy


Modeling Video Rentals *

• Examples of current rentals and previous rentals• Differences are in cardinalities and attribute names

MCustomer

MVideoPreviously

Rented

dateRented

costdate

Returned

1Customer

MVideoRents

dateRented

costdateDue

How do we ensure no data/information are missed/lost ?

Putting it into an object/entity

Jesper Rosholm Tørresø

How do we ensure no data/information are missed/lost "Putting it into an object/entity


Modeling Video Rentals as an Entity Class *

• Diagram shows entity class Rental and its relationship types with Customer and Video

• Note cardinalities and participation constraints– A Rental entity cannot exist without being related to both a

customer and a video

• Problem occurs because Rental has no key attribute

Video1

Customer1

Has Rental1

MHas

costdateDue dateRented

“BOX IN”


Weak Entity Classes *

• A weak entity class is – An entity class with no key of its own– An entity class whose entities cannot exist without being related

to other entities

• An identifying relationship type is– A relationship type that determines the keys of the weak entities

Video1

Customer1

Has Rental1

MHas

IdentifyingRelationship

Type

Weak EntityClass


Owner EntityClass


Roles in Relationship Types *

• Each entity in a relationship plays a specific role in it• Roles are particularly important in relationship types that

relate an entity class to itself– Each person in an IsChildOf relationship is either a parent or a

child

PersonIs

ChildOf

M

1..2

parent

child

ssn

IsMarried

To

1

1

wife

husband

IsParentOf

RoleName

MIn/maxCardinalityConstraint


Employee Roles and Cardinalities *

• Is this an accurate model of the relationships between employees and stores?

• For example, does this diagram answer these questions correctly?– Does a store have to have a manager?– Can an employee be the manager of more than one store?– What other questions can you ask about roles and cardinalities?

StoreEmployee

M

11

M

1

1

M

M M

1

worker

manager

Has

PayStatement

Has

amountdatePaid

Manages

WorksIn

endTimestartTime

TimeCard

PaidTo


Purchase Orders *

• What does the diagram below mean?– How do we buy many copies of a single movie?

– Does each video have its own videoId before it is received?

– What does it mean for an order of a video to have a quantity?

• The problem with the diagram is with class Video• The diagram fails to distinguish between a movie and a copy of a

movie (a video)• We need to revise the diagram to show Movie as an entity class

VideoSupplierM1 1

M

PurchaseOrderHas Orders

id

quantity


Modeling Videos and Movies *

• This diagram more accurately specifies the true nature of Video and Movie– It also has an accurate specification of PurchaseOrder

movieId

Supplier

1PurchaseOrder quantity

M

purchaseDate

Id

title Movie

Orders

M

1

BuysFrom

PurchaseOrderDetailHas

M

1

unitCost

addressname

lineNumber

VideoIs

CopyOf

dateAcquired

1 M

genre

videoId

length rating


Time Cards and Pay Statements *

• Classes TimeCard and PayStatement are weak • Does this diagram show the correct identifying

relationships and discriminators?– For example, can an employee have 2 time cards that begin at

the same time but are at different stores?

Store1

EmployeeM M

1HasHas TimeCard

endTimestartTime

1

PaidTo

M

PayStatement

amountdatePaid

Discriminator

Discriminator


Adding DVD and Videotape *• How can we add DVD and videotape to our model?

– Do DVD and videotape have different attributes?• These diagrams show 2 different models

– An entity of class Video can be either a DVD or a videotape (upper diagram)– DVD and Videotape are different entity classes (lower diagram)

Videosoundtrack

format

Videotapeattributes

DVDattributes shared

attributes

dvd videotapelanguages

videoFormat

captioning

compositeattribute

dateAcquired

videoId media

compositeattribute

DVD

dateAcquired

videoId media

languages

videoFormat

captioning

Videotape

dateAcquired

videoId media

soundtrack

format

duplication ofrelationship

types

duplication ofattributes


Adding Relationship Types *

• Problems occur when we add relationship types of the data model with separate classes for DVD and Videotape– Relationship types must be duplicated

– We cannot enforce constraints

1HasRental1


Movieis

CopyOf 1

M

movieId

DVD

dateAcquired

videoId media

languages

videoFormat

captioning

Videotape

dateAcquired

videoId media

soundtrack

format

1

1Has is

CopyOf

1

M

1


types


types


types


types


Modeling with Inheritance *• Class Video is a common superclass of both DVD and Videotape

– Attributes of Video (videoId and dateAcquired) are shared– Relationship types with Rental and Movie are shared– An entity of class Video must be either a DVD or a videotape

d

Video

Videotape

soundtrackformat

DVD

InheritanceCircle

SuperclassConnector with

mandatory participation

SubclassConnector

Inheritance(cup)

Symbol

1Rental

1Has


Movieis

CopyOf

1M

movieId

captioninglanguagesvideo

Format

media

"dvd" "videotape"

DefiningAttribute

DefiningAttribute

Value

dateAcquired

videoId


Case in Point

• E-R Model for Video Sales for BigHit Online• Process

– Evaluate statement of goals for information system– Evaluate entity classes, attributes and relationship types from

Chapter 3– Draw preliminary E-R diagram with entity classes and their

attributes– Add relationship types to E-R diagram– Define cardinality and participation constraints– Add any appropriate inheritance– Evaluate diagram for clarity, accuracy and completeness


Evaluate Statement of Goals

• BigHit Video Inc. wants to create an information system for online sales of movies in both DVD and videotape format. People will be allowed to register as customers of the online site and to update their stored information. Information must be maintained about customers’ shipping addresses, e-mail addresses and credit cards. In a single sale, customers will be allowed to purchase any quantity of videos. The items in a single sale will be shipped to a single address and will have a single credit card charge.

• A customer will be provided with a virtual shopping cart to store items to be purchased. As each item is selected, it is added to the shopping cart. When the customer finishes shopping, he will be directed to a checkout area where payment and shipping information is entered. Once the sale is complete, the customer will be sent a receipt by e-mail.


Evaluate Entity Classes and Attributes


Evaluate Relationship Types

Relationship Type Entity Class Entity Class Cardinality Ratio Attibutes

Purchases Customer Sale one-to-many

Includes Sale Movie many-to-many quantity

Selects Customer ShoppingCart one-to-many

Includes ShoppingCart Movie many-to-many quantity


Resulting E-R Diagram for BigHit Online

Sale1

Includes

MPurchases

1

Customer

ShoppingCart

Selects

Includes

1

M M

M

M

creditCards

expirationaccountNumber

type

quantity

quantity

creditCard

totalCost saleIddateSold

cartIddate

Created

zipcode

statecity

street zipcode

statecity

street

shippingAddresses

lastName

accountId

firstName expiration

accountNumber

type

Movie

o

costquantitycostquantity

VideotapeDVD

genre

movieId

title

videoFormat

languages

captioning

format

soundtrack

Copyright © 2003 Addison-Wesley Jesper Rosholm Tørresø.

Documents

Transcript of Copyright © 2003 Addison-Wesley Jesper Rosholm Tørresø.