Presentation is loading. Please wait.

Presentation is loading. Please wait.

Data Modeling using ER- Diagram Indra Budi

Similar presentations


Presentation on theme: "Data Modeling using ER- Diagram Indra Budi"— Presentation transcript:

1 Data Modeling using ER- Diagram Indra Budi

2 Fakultas Ilmu Komputer UI 2 Data Modeling Process of creating a logical representation of the structure of the database The most important task in database development

3 Fakultas Ilmu Komputer UI 3 The ER Model and its extensions ER Diagrams-Notation Example Database Application (COMPANY) ER Model Concepts Entities and Attributes Entity Types, Value Sets, and Key Attributes Relationships and Relationship Types Weak Entity Types Roles and Attributes in Relationship Types Relationships of Higher Degree Notation 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 4 Summary of ER-Diagram Notation Meaning ENTITY TYPE WEAK ENTITY TYPE RELATIONSHIP TYPE IDENTIFYING RELATIONSHIP TYPE ATTRIBUTE KEY ATTRIBUTE MULTIVALUED ATTRIBUTE COMPOSITE ATTRIBUTE DERIVED ATTRIBUTE TOTAL PARTICIPATION OF E 2 IN R CARDINALITY RATIO 1:N FOR E 1 :E 2 IN R STRUCTURAL CONSTRAINT (min, max) ON PARTICIPATION OF E IN R Symbol E1E1 R E2E2 E1E1 R N E2E2 R (min,max) E N 1

5 Fakultas Ilmu Komputer UI 5 Example 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 6 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 7 ER Diagram for the Company Database

8 Fakultas Ilmu Komputer UI 8 ER Model Concepts: Entities and Attributes Entities - Specific Objects or Things in the Mini-world that are Represented in the Database EMPLOYEE John Smith Research DEPARTMENT Productx PROJECT Attributes are Properties Used to Describe an Entity e.g., an EMPLOYEE Entity may have a Name, SSN, Address, Sex, Birthdate A Specific Entity (Instance) has a Value for Each of its Attributes Specific Employee Entity May Have Name=‘John Smith’, SSN=‘ ’, Address=‘731 Fondren, Houston, TX’, Sex=‘m’, Birthdate=‘09-jan-55’

9 Fakultas Ilmu Komputer UI 9 Types 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 10 Types of Attributes (cont.) Stored vs Derived Attributes We 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 Values In 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 residences A special value created  Null

11 Fakultas Ilmu Komputer UI 11 Entities with Attribute Values

12 Fakultas Ilmu Komputer UI 12 Entity 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 Composite VehicleTagNumber is a key of the CAR entity type with components (Number, State). An Entity Type may have More than One Key CAR 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 13 car 1 ((ABC 123, TEXAS), TK629, Ford Mustang, convertible, 1989, (red, black)) car 2 ((ABC 123, NEW YORK), WP9872, Nissan Sentra, 2-door, 1992, (blue)) car 3 ((VSY 720, TEXAS), TD729, Chrysler LeBaron, 4-door, 1993, (white, blue)). CAR VehicleTagNumber(Number, State), VIN, Make, Model, Year, (Color) Entity Type CAR with Attributes

14 Fakultas Ilmu Komputer UI 14 Two Other Entity Types

15 Fakultas Ilmu Komputer UI 15 Relationships 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 DEPARTMENT Relationship - Instance Level Relationships of the Same Type are Grouped or Typed Into a Relationship Type WORKS_ON Relationship Type in Which Employees and Projects Participate MANAGES Relationship Type in Which Employees and Departments Participate Analogous to Reference or List in Programming

16 Fakultas Ilmu Komputer UI 16 The WORKS_ON Relationship

17 Fakultas Ilmu Komputer UI 17 Relationships and Relationship Types Degree of a Relationship Type is the Number of Participating Entity Types Both MANAGES and WORKS_ON are Binary Relationships What 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 Directional SUPPLIES: SUPPLIER to PARTS SUPPLIERS: PARTS to SUPPLIER

18 Fakultas Ilmu Komputer UI 18 E-R Diagrams EMPLOYEEPROJECT Responsibility Duration Budget Project Name Project NoEmployee No Employee Name SalaryTitle WORKS ON Address CityApt. # Street # NoEmp Location

19 Fakultas Ilmu Komputer UI 19 Weak Entity Types Entity that Does Not have a Key Attribute Weak Entity Must Participate in an Identifying Relationship Type with an Owner or Identifying Entity Type Entities are Identified by the Combination of: A Partial Key of the Weak Entity Type Particular 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 20 ER Model and Data Abstraction Abstraction Classification Aggregation Identification Generalization ER Model Concept Entity Type - a Grouping of Member Entities Relationship Type - a Grouping of Member Relationships Relationship Type is an Aggregation of (Over) Its Participating Entity Types Weak Entity Type and Attribute Key ????????

21 Fakultas Ilmu Komputer UI 21 Constraints on Aggregation Cardinality Constraints on Relationship Types AKA Ratio Constraints Maximum 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 22 e 1 e 2 e 3 e 4 e 5 e 6 e 7 EMPLOYEE r1r2r3r4r5r6r7r1r2r3r4r5r6r7 WORKS_FOR d 1 d 2 d 3 DEPARTMENT One-to-many(1:N) or Many-to-one (N:1)

23 Fakultas Ilmu Komputer UI 23 e 1 e 2 e 3 e 4 e 5 e 6 e 7 r1r2r3r4r5r6r7r1r2r3r4r5r6r7 d 1 d 2 d 3 r8r8 r9r9 MANY-TO-MANY(M:N)

24 Fakultas Ilmu Komputer UI 24 One-to-One WORKS_ON Relationship WORKS_ON Relationship Instances EMPLOYEE Set PROJECT Set

25 Fakultas Ilmu Komputer UI 25 EMPLOYEEPROJECT Responsibility Duration Budget Project Name Project NoEmployee No Employee Name SalaryTitle WORKS ON 1 1 One-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 26 One-to-Many WORKS_ON Relationship

27 Fakultas Ilmu Komputer UI 27 Project Name EMPLOYEEPROJECT Responsibility Duration Budget Project NoEmployee No Employee Name SalaryTitle WORKS ON 1 N Many-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 28 Many-to-Many WORKS_ON Relationship

29 Fakultas Ilmu Komputer UI 29 EMPLOYEEPROJECT Responsibility Duration Budget Project Name Project NoEmployee No Employee Name SalaryTitle WORKS ON N M Many-to-Many Relationship Each Instance of One Entity Class Can Be Associated with Many Instances of Another Entity Class, and vice versa Example: Each Employee Can Work in Many Projects Each Project Can Employ Many Employees

30 Fakultas Ilmu Komputer UI 30 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 Partial Shown By Double Lining The Link NOTE: Easy to Specify for Binary Relationship Types Do Not Be Misled by Obscure Notations to Specify Above Constraints for Higher Order Relationships

31 Fakultas Ilmu Komputer UI 31 Alternative (min, max) Notation Alternative (Min, Max) Notation for Relationship Structural Constraints Introduces Limits Specified on Each Participation of an Entity Type E in a Relationship Type R Specifies That Each Entity E in Participates in at Least Min and at Most Max Relationship Instances in R Default (no Constraint): Min = 0, Max = n Must Have Min  max, Min  0, Max  1 Derived From the Knowledge of Mini-World Constraints

32 Fakultas Ilmu Komputer UI 32 Examples: 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 MANAGES Specify (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_FOR Specify (0, n) for Participation of DEPARTMENT in WORKS_FOR

33 Fakultas Ilmu Komputer UI 33 Examples: 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 34 Relationships of Higher Degree Relationship Types of Degree 2 Are Called Binary Relationship Types of Degree 3 Are Called Ternary There is a Concrete Relationship Instance that Involves all Three Entity Types These are Not Separate Relationships! Relationship Types of Degree N Are Called N-ary Again - 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 35 Ternary Relationships

36 Fakultas Ilmu Komputer UI 36 Ternary Relationships

37 Fakultas Ilmu Komputer UI 37 Ternary vs. Binary Relationships

38 Fakultas Ilmu Komputer UI 38 Constraints 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? m n p

39 Fakultas Ilmu Komputer UI 39 Higher Order (min,max) Examples A Teacher can offer min 1 and max 2 Offerings A Course may have 1 to 3 Offerings A Student may enroll in from 1 to 5 Offerings (1,5) (1,3) (1,2)

40 Fakultas Ilmu Komputer UI 40 s 1 s 2 SUPPLIER p 1 p 2 p 3 PART r1r2r3r4r5r6r7r1r2r3r4r5r6r7 SUPPLY j 1 j 2 j 3 PROJECT Ternary Relationships - Instances

41 Fakultas Ilmu Komputer UI 41 Modified Earlier Example

42 Fakultas Ilmu Komputer UI 42 Another ER Diagram - Bank Example

43 Fakultas Ilmu Komputer UI 43 ER Data Modeling Tools Many Popular Existing Tools Advantages: Documentation of Application Requirements User 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 44 Data modeling, design and reengineering Visual Basic and Visual C++ Visio EnterpriseVisio Data modeling, business logic modelingEnterprise Application Suite Sybase Conceptual modeling up to code maintenanceXcaseResolution Ltd. Mapping from O-O to relational modelRW MetroRogue Ware Modeling in UML and generation in C++ and JAVA Together has support for limited ER Design Rational Rose Together Control Center Rational Together/Borlan d Mapping from O-O to relational modelPwertierPersistence Inc. Data, process, and business component modelingPlatinum 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 Tools

45 Fakultas Ilmu Komputer UI 45 Design 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 46 Avoiding 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 47 Example: Good BeersManfs ManfBy name This design gives the address of each manufacturer exactly once. nameaddr N 1

48 Fakultas Ilmu Komputer UI 48 Example: Bad BeersManfs ManfBy 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 49 Example: 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. manfmanfAddr

50 Fakultas Ilmu Komputer UI 50 Entity 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. or It is the “many” in a many-one or many-many relationship.

51 Fakultas Ilmu Komputer UI 51 Example: Good BeersManfs ManfBy 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. nameaddr N 1

52 Fakultas Ilmu Komputer UI 52 Example: Bad BeersManfs ManfBy 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 53 Example: 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 54 Don’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 55 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 56 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 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 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


Download ppt "Data Modeling using ER- Diagram Indra Budi"

Similar presentations


Ads by Google