Download - Data Modeling using ER-Diagram
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
3 Fakultas Ilmu Komputer UI
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.
4 Fakultas Ilmu Komputer UI
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
5 Fakultas Ilmu Komputer UI
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
6 Fakultas Ilmu Komputer UI
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
7 Fakultas Ilmu Komputer UI
ER Diagram for the Company DatabaseER Diagram for the Company Database
8 Fakultas Ilmu Komputer UI
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’
9 Fakultas Ilmu Komputer UI
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)}
10 Fakultas Ilmu Komputer UI
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
11 Fakultas Ilmu Komputer UI
Entities with Attribute ValuesEntities with Attribute Values
12 Fakultas Ilmu Komputer UI
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.
13 Fakultas Ilmu Komputer UI
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
14 Fakultas Ilmu Komputer UI
Two Other Entity TypesTwo Other Entity Types
15 Fakultas Ilmu Komputer UI
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
16 Fakultas Ilmu Komputer UI
The WORKS_ON RelationshipThe WORKS_ON Relationship
17 Fakultas Ilmu Komputer UI
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
18 Fakultas Ilmu Komputer UI
E-R Diagrams
EMPLOYEE PROJECT
Responsibility
Duration
Budget
ProjectName
Project NoEmployee No EmployeeName
SalaryTitle
WORKS ON
Address
CityApt. #
Street #
NoEmp
Location
19 Fakultas Ilmu Komputer UI
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
20 Fakultas Ilmu Komputer UI
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????????
21 Fakultas Ilmu Komputer UI
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)
22 Fakultas Ilmu Komputer UI
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)
23 Fakultas Ilmu Komputer UI
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)
24 Fakultas Ilmu Komputer UI
One-to-One WORKS_ON RelationshipOne-to-One WORKS_ON Relationship
WORKS_ONRelationship
Instances
EMPLOYEE Set PROJECT Set
25 Fakultas Ilmu Komputer UI
EMPLOYEE PROJECT
Responsibility
Duration
Budget
ProjectName
Project NoEmployee No EmployeeName
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
26 Fakultas Ilmu Komputer UI
One-to-Many WORKS_ON RelationshipOne-to-Many WORKS_ON Relationship
27 Fakultas Ilmu Komputer UI
ProjectName
EMPLOYEE PROJECT
Responsibility
Duration
Budget
Project NoEmployee No EmployeeName
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
28 Fakultas Ilmu Komputer UI
Many-to-Many WORKS_ON RelationshipMany-to-Many WORKS_ON Relationship
29 Fakultas Ilmu Komputer UI
EMPLOYEE PROJECT
Responsibility
Duration
Budget
ProjectName
Project NoEmployee No EmployeeName
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
30 Fakultas Ilmu Komputer UI
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
31 Fakultas Ilmu Komputer UI
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
32 Fakultas Ilmu Komputer UI
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
33 Fakultas Ilmu Komputer UI
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)
34 Fakultas Ilmu Komputer UI
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
35 Fakultas Ilmu Komputer UI
Ternary RelationshipsTernary Relationships
36 Fakultas Ilmu Komputer UI
Ternary RelationshipsTernary Relationships
37 Fakultas Ilmu Komputer UI
Ternary vs. Binary RelationshipsTernary vs. Binary Relationships
38 Fakultas Ilmu Komputer UI
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
39 Fakultas Ilmu Komputer UI
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)
40 Fakultas Ilmu Komputer UI
s1
s2
SUPPLIER
p1
p2
p3
PART
r1
r2
r3
r4
r5
r6
r7
SUPPLY
j1
j2
j3
PROJECT
Ternary Relationships - InstancesTernary Relationships - Instances
41 Fakultas Ilmu Komputer UI
Modified Earlier ExampleModified Earlier Example
42 Fakultas Ilmu Komputer UI
Another ER Diagram - Bank ExampleAnother ER Diagram - Bank Example
43 Fakultas Ilmu Komputer UI
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
44 Fakultas Ilmu Komputer UI
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
45 Fakultas Ilmu Komputer UI
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.
46 Fakultas Ilmu Komputer UI
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.
47 Fakultas Ilmu Komputer UI
Example: GoodExample: Good
Beers ManfsManfBy
name
This design gives the address of each manufacturer exactly once.
name addr
N 1
48 Fakultas Ilmu Komputer UI
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
49 Fakultas Ilmu Komputer UI
Example: BadExample: Bad
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
50 Fakultas Ilmu Komputer UI
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.
51 Fakultas Ilmu Komputer UI
Example: GoodExample: Good
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
52 Fakultas Ilmu Komputer UI
Example: BadExample: Bad
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
53 Fakultas Ilmu Komputer UI
Example: GoodExample: Good
Beers
name
There is no need to make the manufacturer an entity set, because we record nothing about manufacturers besides their name.
manf
54 Fakultas Ilmu Komputer UI
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.
55 Fakultas Ilmu Komputer UI
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.
56 Fakultas Ilmu Komputer UI
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.