Data Modeling using ER- Diagram Indra Budi [email protected].

Data Modeling using ER-Diagram

Indra [email protected]

2 Fakultas Ilmu Komputer UI

Data ModelingData Modeling

Process of creating a logical representation of the structure of the databaseThe most important task in database development


The ER Model and its extensionsThe ER Model and its extensions

ER Diagrams-NotationExample Database Application (COMPANY)ER Model Concepts

Entities and AttributesEntity Types, Value Sets, and Key AttributesRelationships and Relationship TypesWeak Entity TypesRoles and Attributes in Relationship Types

Relationships of Higher DegreeNotation is based on :

R. Elmasri and S.B. Navathe, “ Fundamentals of Database Systems,” Ed. 3., Addison Wesley, 2000, Chapters 3 and 4.


Summary of ER-Diagram NotationMeaning

ENTITY TYPE

WEAK ENTITY TYPE

RELATIONSHIP TYPE

IDENTIFYING RELATIONSHIP TYPE

ATTRIBUTE

KEY ATTRIBUTE

MULTIVALUED ATTRIBUTE

COMPOSITE ATTRIBUTE

DERIVED ATTRIBUTE

TOTAL PARTICIPATION OF E2 IN R

CARDINALITY RATIO 1:N FOR E1:E2 IN R

STRUCTURAL CONSTRAINT (min, max) ON PARTICIPATION OF E IN R

Symbol

E1 R E2

E1 RN E2

R(min,max)

E

N1


Example COMPANY DatabaseExample COMPANY Database

Requirements of the Company (Oversimplified for Illustrative Purposes)

Company is Organized into Departments• Each Department has a Name, Number and an Employee

Who Manages the Department• We Track of the Start Date of the Department Manager

Each Department Controls a Number of Projects • Each Project has a Name, Number and is Located at a Single

Location


Example COMPANY Database (Cont.)Example COMPANY Database (Cont.)

Store Each Employee’s Social Security Number, Address, Salary, Sex, and Birthdate

• Each Employee Works for One Department but May Work on Several Projects

• We Track of the Number of Hours Per Week that an Employee Currently Works on Each Project

• We Track of the Direct Supervisor of Each Employee

Each Employee May have a Number of Dependents• For Each Dependent, We Track of their Name, Sex,

Birthdate, and Relationship to Employee


ER Diagram for the Company DatabaseER Diagram for the Company Database


ER Model Concepts: Entities and AttributesER Model Concepts: Entities and Attributes

Entities - Specific Objects or Things in the Mini-world that are Represented in the Database

EMPLOYEE John SmithResearch DEPARTMENTProductx PROJECT

Attributes are Properties Used to Describe an Entitye.g., an EMPLOYEE Entity may have a Name, SSN, Address, Sex, BirthdateA Specific Entity (Instance) has a Value for Each of its Attributes

Specific Employee Entity May Have Name=‘John Smith’, SSN=‘123456789’, Address=‘731 Fondren, Houston, TX’, Sex=‘m’, Birthdate=‘09-jan-55’


Types of AttributesTypes of Attributes

Simple: Single Atomic Value for the Attribute SSN or Sex or State or Salary or ...

Composite: Attribute Composed of Many Components

Address (Apt#, House#, Street, City, State, Zipcode, Country) or Name(Fname, MI, Lname)Composition May form a Hierarchy where Some Components are Themselves Composite

Multi-Valued: Entity may have Multiple Values for That Attribute - Like an Set Type

CAR {Color} or STUDENT {Previousdegrees}

Composite and Multi-valued Attributes may be Nested Arbitrarily to any Number of Levels (Rare)

Previousdegrees of a STUDENT is a Composite Multi-valued Attribute Denoted by {Previousdegrees(college, Year, Degree, Field)}


Types of Attributes (cont.)Types of Attributes (cont.)

Stored vs Derived AttributesWe can know Age attribute (derived) from BirthDate attribute (stored)NumberOfEmployee of a department can be derived from counting the number of employees related to (working for) that department

Null ValuesIn some cases, a particular entity may not have an applicable value for an attribute.ApartmentNumber only applies to address of Apartment and not to other residencesA special value created Null


Entities with Attribute ValuesEntities with Attribute Values


Entity Types and Key AttributesEntity Types and Key Attributes

Entities with the Same Basic Attributes Are Grouped or Typed into an Entity Type

EMPLOYEE Entity Type or PROJECT Type

Attribute of Entity Type for which Each Entity Must Have a Unique Value is Called a Key Attribute

SSN of EMPLOYEE, ISBN of BOOK

A Key Attribute may be CompositeVehicleTagNumber is a key of the CAR entity type with components (Number, State).

An Entity Type may have More than One KeyCAR Entity Type May Have Two Keys:

• VehicleIdentificationNumber (popularly called VIN) and• VehicleTagNumber (Number, State), also known as license_plate

number.


car1((ABC 123, TEXAS), TK629, Ford Mustang, convertible, 1989, (red, black))

car2

((ABC 123, NEW YORK), WP9872, Nissan Sentra, 2-door, 1992, (blue))car3

((VSY 720, TEXAS), TD729, Chrysler LeBaron, 4-door, 1993, (white, blue))

.

.

.

CARVehicleTagNumber(Number, State), VIN, Make, Model, Year, (Color)

Entity Type CAR with AttributesEntity Type CAR with Attributes


Two Other Entity TypesTwo Other Entity Types


Relationships and Relationship TypesRelationships and Relationship Types

A Relationship Relates Two or More Distinct Entities With a Specific Meaning

EMPLOYEE John Smith Works on the Productx PROJECT EMPLOYEE Franklin Wong Manages the Research DEPARTMENTRelationship - Instance Level

Relationships of the Same Type are Grouped or Typed Into a Relationship Type

WORKS_ON Relationship Type in Which Employees and Projects ParticipateMANAGES Relationship Type in Which Employees and Departments ParticipateAnalogous to Reference or List in Programming


The WORKS_ON RelationshipThe WORKS_ON Relationship


Relationships and Relationship TypesRelationships and Relationship Types

Degree of a Relationship Type is the Number of Participating Entity Types

Both MANAGES and WORKS_ON are Binary RelationshipsWhat is a possible Ternary Relationship?

More Than One Relationship Type Can Exist With the Same Participating Entity Types

MANAGES and WORKS_FOR are Distinct Relationships Between EMPLOYEE and DEPARTMENT Entity Types

Relationships are DirectionalSUPPLIES: SUPPLIER to PARTSSUPPLIERS: PARTS to SUPPLIER


E-R Diagrams

EMPLOYEE PROJECT

Responsibility

Duration

Budget

ProjectName

Project NoEmployee No EmployeeName

SalaryTitle

WORKS ON

Address

CityApt. #

Street #

NoEmp

Location


Weak Entity TypesWeak Entity Types

Entity that Does Not have a Key AttributeWeak Entity Must Participate in an Identifying Relationship Type with an Owner or Identifying Entity TypeEntities are Identified by the Combination of:

A Partial Key of the Weak Entity TypeParticular Entity they Are Related to in the Identifying Entity Type

Example: A DEPENDENT Entity is Identified by Dependent’s First Name and Birthdate, and the EMPLOYEE That the Dependent is Related to DEPENDENT is a Weak Entity Type With EMPLOYEE as its Identifying Entity Type Via the Identifying Relationship Type DEPENDENT_OF


ER Model and Data AbstractionER Model and Data Abstraction

AbstractionClassification

Aggregation

IdentificationGeneralization

ER Model ConceptEntity Type - a Grouping of Member EntitiesRelationship Type - a Grouping of Member RelationshipsRelationship Type is an Aggregation of (Over) Its Participating Entity TypesWeak Entity Type and Attribute Key????????


Constraints on AggregationConstraints on Aggregation

Cardinality Constraints on Relationship Types

AKA Ratio ConstraintsMaximum Cardinality

• One-to-One• One-to-Many• Many-to-Many

Minimum Cardinality (AKA Participation or Existence Dependency Constraints)

• Zero (Optional Participation, Not Existence-Dependent)• One or More (Mandatory, Existence-Dependent)


e1

e2

e3

e4

e5

e6

e7

EMPLOYEE

r1

r2

r3

r4

r5

r6

r7

WORKS_FOR

d1

d2

d3

DEPARTMENT

One-to-many(1:N) or Many-to-one (N:1)One-to-many(1:N) or Many-to-one (N:1)


e1

e2

e3

e4

e5

e6

e7

r1

r2

r3

r4

r5

r6

r7

d1

d2

d3

r8

r9

MANY-TO-MANY(M:N)MANY-TO-MANY(M:N)


One-to-One WORKS_ON RelationshipOne-to-One WORKS_ON Relationship

WORKS_ONRelationship

Instances

EMPLOYEE Set PROJECT Set


EMPLOYEE PROJECT

Responsibility

Duration

Budget

ProjectName


SalaryTitle

WORKS ON1 1

One-to-One RelationshipOne-to-One Relationship

Each Instance of One Entity Class E1 Can Be Associated with Exactly One Instance of Another Entity Class E2 and Vice Versa.Example:

Each Employee Can Work in Exactly One Project and Each Project Employs Exactly One Employee


One-to-Many WORKS_ON RelationshipOne-to-Many WORKS_ON Relationship


ProjectName

EMPLOYEE PROJECT

Responsibility

Duration

Budget


SalaryTitle

WORKS ON1N

Many-to-One RelationshipMany-to-One Relationship

Each Instance of One Entity Class E1 can be Associated with Zero or More Instances of Another Entity Class E2, but Each Instance of E2 can be Associated With at Most 1 Instance of E1

Example :Each Employee Can Work in Exactly One Project Each Project Can Employ Many Engineers


Many-to-Many WORKS_ON RelationshipMany-to-Many WORKS_ON Relationship


EMPLOYEE PROJECT

Responsibility

Duration

Budget

ProjectName


SalaryTitle

WORKS ONN M

Many-to-Many RelationshipMany-to-Many Relationship

Each Instance of One Entity Class Can Be Associated with Many Instances of Another Entity Class, and vice versaExample:

Each Employee Can Work in Many ProjectsEach Project Can Employ Many Employees


Structural Constraints Structural Constraints

Structural Constraints on a Relationship are One Way to Express the Semantics of a Relationship Cardinality Ratio (of a Binary Relationship): 1:1, 1:N, N:1, or M:N

Shown by Placing Apropos Number on the Link

Participation Constraint (on Each Entity Type): Total (Called Existence Dependency) or PartialShown By Double Lining The Link

NOTE: Easy to Specify for Binary Relationship TypesDo Not Be Misled by Obscure Notations to Specify Above Constraints for Higher Order Relationships


Alternative (min, max) Notation Alternative (min, max) Notation

Alternative (Min, Max) Notation for Relationship Structural Constraints Introduces LimitsSpecified on Each Participation of an Entity Type E in a Relationship Type RSpecifies That Each Entity E in Participates in at Least Min and at Most Max Relationship Instances in R

Default (no Constraint): Min = 0, Max = nMust Have Min max, Min 0, Max 1

Derived From the Knowledge of Mini-World Constraints


Examples: Alternative (min, max) NotationExamples: Alternative (min, max) Notation

A Department has Exactly One Manager and an Employee Can Manage at most One Department.

Specify (0, 1) for Participation of EMPLOYEE in MANAGESSpecify (1, 1) for Participation of DEPARTMENT in MANAGES

An Employee can Work for Exactly One Department but a Dept. can have any Number of Employees

Specify (1, 1) for Participation of EMPLOYEE in WORKS_FORSpecify (0, n) for Participation of DEPARTMENT in WORKS_FOR


Examples: Alternative (min, max) NotationExamples: Alternative (min, max) Notation

What does it mean to put m:n:p on the three arms of the relationship? It is essentially meaningless. The (min,max) notation “looking away” from the entity is the best to use.

(1,1)(0,1)

(1,N)(1,1)


Relationships of Higher DegreeRelationships of Higher Degree

Relationship Types of Degree 2 Are Called BinaryRelationship Types of Degree 3 Are Called Ternary

There is a Concrete Relationship Instance that Involves all Three Entity TypesThese are Not Separate Relationships!

Relationship Types of Degree N Are Called N-aryAgain - Concrete n-Participation Relationship

In General, an N-ary Relationship is Not Equivalent to N Binary Relationships

Rather - it is more Analogous to the Grouping of N-Binary Relationships into a N-ary Relationship


Ternary RelationshipsTernary Relationships


Ternary vs. Binary RelationshipsTernary vs. Binary Relationships


Constraints on Higher Order RelationshipsConstraints on Higher Order Relationships

What does it mean to put m:n:p on the three arms of the relationship ?

How do you set up the instance level diagram between actual suppliers, projects, and parts?

mn

p


Higher Order (min,max) ExamplesHigher Order (min,max) Examples

A Teacher can offer min 1 and max 2 OfferingsA Course may have 1 to 3 OfferingsA Student may enroll in from 1 to 5 Offerings

(1,5)

(1,3)(1,2)


s1

s2

SUPPLIER

p1

p2

p3

PART

r1

r2

r3

r4

r5

r6

r7

SUPPLY

j1

j2

j3

PROJECT

Ternary Relationships - InstancesTernary Relationships - Instances


Modified Earlier ExampleModified Earlier Example


Another ER Diagram - Bank ExampleAnother ER Diagram - Bank Example


ER Data Modeling ToolsER Data Modeling Tools

Many Popular Existing ToolsAdvantages:

Documentation of Application RequirementsUser Interface - Mostly Graphics Editor Support

Disadvantages:Poor Diagramming

• To Avoid Layout Algorithms and Aesthetics of Diagrams, They Prefer Boxes and Lines and Typically Only Represent (Primary-foreign Key) Relationships Among Resulting Tables

Lack of Built-in Methodology Support• Poor Tradeoff Analysis/User-driven Design Preferences• Poor Design Verification/Suggestions for Improvement


Data modeling, design and reengineering Visual Basic and Visual C++

Visio EnterpriseVisio

Data modeling, business logic modelingEnterprise Application SuiteSybase

Conceptual modeling up to code maintenanceXcaseResolution Ltd.

Mapping from O-O to relational modelRW MetroRogue Ware

Modeling in UML and generation in C++ and JAVATogether has support for limited ER Design

Rational RoseTogether Control Center

RationalTogether/Borland

Mapping from O-O to relational modelPwertierPersistence Inc.

Data, process, and business component modeling

Platinum Enterprice Modeling Suite: Erwin, BPWin, Paradigm Plus

Platinum Technology

Data modeling, object modeling, process modeling, structured analysis/design

System Architect 2001Popkin Software

Database modeling, application developmentDeveloper 2000 and Designer 2000

Oracle

Database administration and space and security management

DB Artisan

Database Modeling in ER and IDEF1XER StudioEmbarcadero Technologies

FUNCTIONALITYTOOLCOMPANY

Current ER Modeling ToolsCurrent ER Modeling Tools


Design TechniquesDesign Techniques

1. Avoid redundancy.2. Limit the use of weak entity sets.3. Don’t use an entity set when an attribute

will do.


Avoiding RedundancyAvoiding Redundancy

Redundancy occurs when we say the same thing in two different ways.Redundancy wastes space and (more importantly) encourages inconsistency.

The two instances of the same fact may become inconsistent if we change one and forget to change the other, related version.


Example: GoodExample: Good

Beers ManfsManfBy

name

This design gives the address of each manufacturer exactly once.

name addr

N 1


Example: BadExample: Bad

Beers ManfsManfBy

name

This design states the manufacturer of a beer twice: as an attribute and as a related entity.

name

manf

addr

N 1



Beers

name

This design repeats the manufacturer’s address once for each beer; loses the address if there are temporarily no beers for a manufacturer.

manf manfAddr


Entity Sets Versus AttributesEntity Sets Versus Attributes

An entity set should satisfy at least one of the following conditions:

It is more than the name of something; it has at least one nonkey attribute.

orIt is the “many” in a many-one or many-many relationship.



Beers ManfsManfBy

name

•Manfs deserves to be an entity set because of the nonkey attribute addr.•Beers deserves to be an entity set because it is the “many” of the many-one relationship ManfBy.

name addr

N 1



Beers ManfsManfBy

name

Since the manufacturer is nothing but a name, and is not at the “many” end of any relationship, it should not be an entity set.

name

N 1



Beers

name

There is no need to make the manufacturer an entity set, because we record nothing about manufacturers besides their name.

manf


Don’t Overuse Weak Entity SetsDon’t Overuse Weak Entity Sets

Beginning database designers often doubt that anything could be a key by itself.

They make all entity sets weak, supported by all other entity sets to which they are linked.

In reality, we usually create unique ID’s for entity sets.

Examples include social-security numbers, automobile VIN’s etc.


When Do We Need Weak Entity Sets?When Do We Need Weak Entity Sets?

The usual reason is that there is no global authority capable of creating unique ID’s.Example: it is unlikely that there could be an agreement to assign unique player numbers across all football teams in the world.


What are Problems with ER Notation?What are Problems with ER Notation?

Historically, ER Model 1st Proposed in 1976• P. Chen, ''The Entity-Relationship Model - Toward a Unified View of

Data,'' ACM Trans. on Database Systems, Vol. 1, No. 1, March 1976.

However, ER Model in this Original Form Did Not Support the Generalization Abstraction (Inheritance)In Databases, Inheritance 1st Proposed in 1977

• J. Smith and D. Smith, ''Database Abstractions: Aggregation and Generalization,'' ACM Trans. on Database Systems, Vol. 2, No. 2, June 1977.

Thus, Extended ER Evolved through 1980s with the Focus on “Semantic Data Models”

• M. Hammer and D. McLeod, ''Database Descriptions with SDM: A Semantic Data Model,'' ACM Trans. on Database Systems, Vol. 6, No. 3, Sept. 1981.

Data Modeling using ER- Diagram Indra Budi [email protected].

Documents

Transcript of Data Modeling using ER- Diagram Indra Budi [email protected].