Database Design and Modelling

7/28/2019 Database Design and Modelling

1/62

Database Design andModelling

KRISNA ADIYARTA

PASCA SARJANA (MAGISTER KOMPUTER)

UNIVERSITAS BUDI LUHUR

JAKARTA

1. Jeffrey A. Hoffer, Mary B. Prescott, Fred R. McFadden. Modern Database Management. 4th

Edition. Upper Saddle River, New Jersey:Prentice Hall (Pearson Educational, Inc), 2005

2. A. Silberschatz, H.F. Korth, S. Sudarshan. "Database System Concepts (4th Edition). McGraw-Hill, 2002.


2/62

Objectives Definition of terms Importance of data modeling Write good names and definitions for entities, relationships,

and attributes Distinguish unary, binary, and ternary relationships Model different types of attributes, entities, relationships, and

cardinalities Draw E-R diagrams for common business situations Convert many-to-many relationships to associative entities Model time-dependent data using time stamps Enhanced ER- Model


3/62


4/62

Data Definitions Explanation of a term or fact

Termword or phrase with specific meaningFactassociation between two or more terms

Guidelines for good data definition

Gathered in conjunction with systemsrequirements

Accompanied by diagrams

Iteratively created and refinedAchieved by consensus


5/62

E-R Model Constructs Entities: Entity instanceperson, place, object, event, concept

(often corresponds to a row in a table) Entity Typecollection of entities (often corresponds to a

table)

Relationships: Relationship instancelink between entities

(corresponds to primary key-foreign key equivalencies

in related tables) Relationship typecategory of relationshiplink

between entity types

Attributeproperty or characteristic of an entity orrelationship type (often corresponds to a field in a table)


6/62

Sample E-R Diagram


7/62

Basic E-R notation

Relationshipdegrees specifynumber ofentity typesinvolved

Entitysymbols

A special entity

that is also arelationship

Relationshipcardinalitiesspecify howmany of each

entity type isallowed

Attribute

symbols


8/62

What Should an Entity Be? SHOULD BE:

An object that will have many instancesin the database

An object that will be composed of

multiple attributesAn object that we are trying to model

SHOULD NOT BE:

A user of the database system

An output of the database system (e.g.,

a report)


9/62

Example of inappropriate entities

Inappropriateentities

SystemSystemuseruser

SystemSystem

outputoutput

Appropriateentities


10/62

Attributes Attributeproperty or characteristic of an

entity or relationahip type Classifications of attributes:

Required versus Optional Attributes

Simple versus Composite Attribute

Single-Valued versus Multivalued Attribute

Stored versus Derived AttributesIdentifier Attributes


11/62

Identifiers (Keys) Identifier (Key)An attribute (or combination of

attributes) that uniquely identifies individualinstances of an entity type

Simple versus Composite Identifier

Candidate Identifieran attribute that could be a key.It satisfies the requirements for being an identifier


12/62

Characteristics of Identifiers Will not change in value

Will not be null No intelligent identifiers (e.g., containing locations or

people that might change)

Substitute new, simple keys for long, compositekeys


13/62

A composite attribute

An attributebroken intocomponent parts

Entity withmultivalued attribute (Skill) andderivedattribute (Years_Employed)

Multivalued

an employee can havemore than one skill

Derived

from dateemployed andcurrent date


14/62

Simple and composite identifier attributes

The identifier is boldfaced and underlined


15/62

Simple example of time-stamping

This attributethat is bothmultivalued andcomposite


16/62

More on Relationships Relationship Types vs. Relationship Instances

The relationship type is modeled as lines between

entity types.

Relationships can have attributes

These describe features pertaining to the

association between the entities in the relationship

Two entities can have more than one type ofrelationship between them (multiple

relationships)

Associative Entitycombination of relationshipand entity


17/62

Relationship types and instances

a) Relationship type

b) Relationship

instances


18/62

Degree of Relationships Degree of a relationship is the number of entity

types that participate in it

Unary Relationship

Binary Relationship

Ternary Relationship


19/62

Degree of relationships

Entities of threedifferent types

related to eachother

Entities oftwo differenttypes related

to each other

One entityrelated toanother ofthe sameentity type


20/62

Cardinality of Relationships One-to-One

Each entity in the relationship will have exactlyone related entity

One-to-Many

An entity on one side of the relationship can havemany related entities, but an entity on the otherside will have a maximum of one related entity

Many-to-ManyEntities on both sides of the relationship can have

many related entities on the other side


21/62

Cardinality Constraints Cardinality Constraints - the number of instances of

one entity that can or must be associated with eachinstance of another entity

Minimum Cardinality

If zero, then optional If one or more, then mandatory

Maximum Cardinality

The maximum number


22/62

Examples of relationships of different degrees

a) Unary relationships


23/62


b) Binary relationships


24/62

c) Ternary relationship

Note: a relationship can have attributes of its own



25/62

Examples of cardinality constraints

A patient must have recorded

at least one history, and canhave many

A patient history is

recorded for one andonly one patient

a) Mandatory cardinalities


26/62


An employee can be assignedto any number of projects, ormay not be assigned to any

at all

A project must beassigned to at least oneemployee, and may beassigned to many

b) One optional, one mandatory


27/62


A person is ismarried to at most

one other person,or may not bemarried at all

b) Optional cardinalities


28/62

Examples of multiple relationships

Entities can be related to one another in more than one way

a) Employees and departments


29/62

Examples of multiple relationships

Here, mincardinality

constraint is 2

b) Professors and courses (fixed lower limit constraint)


30/62

Multivalued attributes can be represented as relationships

simple

composite


31/62

Strong vs. Weak Entities, and Identifying Relationships

Strong entities

exist independently of other types of entities

has its own unique identifier

identifier underlined with single-line

Weak entity

dependent on a strong entity (identifying owner)cannotexist on its own

does not have a unique identifier (only a partial identifier)

Partial identifier underlined with double-line

Entity box has double line

Identifying relationship links strong entities to weak entities


32/62

Title

Strong entity Weak entity

Identifying relationship


33/62

Associative Entities

An entityhas attributes

A relationshiplinks entities together

When should a relationship with attributes instead bean associative entity?

All relationships for the associative entity should be many

The associative entity could have meaning independent ofthe other entities

The associative entity preferably has a unique identifier,

and should also have other attributesThe associative entity may participate in other relationships

other than the entities of the associated relationship

Ternary relationships should be converted to associativeentities


34/62

A binary relationship with an attribute

Here, the date completed attribute pertains specifically to theemployees completion of a courseit is an attribute of the

relationship


35/62

Title

Associative entity is like a relationship with an attribute, but it is

also considered to be an entity in its own right.

Note that the many-to-many cardinality between entities could bereplaced by two one-to-many relationships with the associative

entity.

An associative entity (CERTIFICATE)


36/62

Title

An associative entity bill of materials structure

This could just be a relationship withattributesits a judgment call


37/62

Title

Ternary relationship as an associative entity


38/62

Title

Different modelingsoftware tools may havedifferent notation for thesame constructs


39/62

Supertypes and Subtypes

Subtype: A subgrouping of the entities in anentity type that has attributes distinct from those

in other subgroupings Supertype: A generic entity type that has a

relationship with one or more subtypes

Attribute Inheritance:Subtype entities inherit values of all attributes

of the supertypeAn instance of a subtype is also an instance of

the supertype


40/62

Basic notation for supertype/subtype notation

a) EERnotation


41/62

Basic notation for supertype/subtype notation

Different modeling tools may have different notation for the same

modeling constructs

b) MicrosoftVisio

Notation


42/62

Employee supertype with three subtypes

All employee subtypeswill have empnbr, name,address, and date-hired

Each employee subtypewill also have its ownattributes


43/62

Relationships and Subtypes

Relationships at the supertype level indicate that all

subtypes will participate in the relationship

The instances of a subtype may participate in arelationship unique to that subtype. In this situation,the relationship is shown at the subtype level


44/62

Supertype/subtype relationships in a hospital

Bothoutpatientsand resident

patients arecared for bya responsiblephysician

Only resident patients areassigned to a bed


45/62

Generalization and Specialization

Generalization:The process of defining a moregeneral entity type from a set of more specialized

entity types. BOTTOM-UP

Specialization:The process of defining one ormore subtypes of the supertype and forming

supertype/subtype relationships. TOP-DOWN

l f li i


46/62

Example of generalization

a) Three entity types: CAR, TRUCK, and MOTORCYCLE

All these types of vehicles have common attributes

E l f li i


47/62

Example of generalization

So we putthe shared

attributes ina supertype

Note: no subtype for motorcycle, since it has no unique attributes

b) Generalization to VEHICLE supertype

E l f i li ti


48/62

Example of specialization

a) Entity type PART

Only applies tomanufactured parts

Applies only to purchased parts

E l f i li ti


49/62

Example of specializationb) Specialization to MANUFACTURED PART and PURCHASED PART

Note: multivaluedattribute was replaced by anassociative entity relationship to another entity

Created 2subtypes

C i i S / C l C i


50/62

Constraints in Supertype/ Completeness Constraint

Completeness Constraints: Whether an instance of asupertype must also be a member of at least one

subtype

Total Specialization Rule: Yes (double line)

Partial Specialization Rule: No (single line)

E l f l t t i t


51/62

Examples of completeness constraints

a) Total specialization rule

A patient must be eitheran outpatient or aresident patient

E l f l t t i t


52/62

Examples of completeness constraints

b) Partial specialization rule

A vehiclecould be a

car, atruck, orneither

Constraints in Supert pe/ Disjointness constraint


53/62

Constraints in Supertype/ Disjointness constraint

Disjointness Constraints: Whether an instance ofa supertype may simultaneously be a member of

two (or more) subtypes

Disjoint Rule: An instance of the supertype canbe only ONE of the subtypes

Overlap Rule: An instance of the supertype couldbe more than one of the subtypes

Examples of disjointness constraints


54/62


a) Disjoint rule

A patient can either be outpatientor resident, but not both



55/62


b) Overlap rule

A part may beboth purchasedand manufactured

Constraints in Supertype/ Subtype Discriminators


56/62

Constraints in Supertype/ Subtype Discriminators

Subtype Discriminator: An attribute of the

supertype whose values determine the targetsubtype(s)

Disjoint a simple attribute with alternative

values to indicate the possible subtypesOverlapping a composite attribute whose

subparts pertain to different subtypes. Each

subpart contains a boolean value to indicatewhether or not the instance belongs to theassociated subtype

Introducing a subtype discriminator (disjoint rule)


57/62

Introducing a subtype discriminator (disjoint rule)

A simple attribute withdifferent possible valuesindicating the subtype

Subtype discriminator (overlap rule)


58/62

Subtype discriminator (overlap rule)

A compositeattribute withsub-attributesindicating yesor no todeterminewhether it is ofeach subtype

Example of supertype/subtype hierarchy


59/62

Example of supertype/subtype hierarchy

Entity Clusters


60/62

Entity Clusters

EER diagrams are difficult to read when there are

too many entities and relationships

Solution: Group entities and relationships into entityclusters

Entity cluster: Set of one or more entity types andassociated relationships grouped into a singleabstract entity type

Title


61/62

Relatedgroups of

entities couldbecomeclusters

Title


62/62

Packaged data

models providegeneric modelsthat can becustomized for a

particularorganizationsbusiness rules

Documents

Database Design and Modelling