Presentation is loading. Please wait.

Presentation is loading. Please wait.

Department of Computer Science, HKUST 1 Comp 231 Database Management Systems Comp 231 Database Management Systems 2. Entity Relationship (ER) Model.

Similar presentations


Presentation on theme: "Department of Computer Science, HKUST 1 Comp 231 Database Management Systems Comp 231 Database Management Systems 2. Entity Relationship (ER) Model."— Presentation transcript:

1

2 Department of Computer Science, HKUST 1 Comp 231 Database Management Systems Comp 231 Database Management Systems 2. Entity Relationship (ER) Model

3 Department of Computer Science, HKUST 2 Basic Concepts  A database can be modeled as  a collection of entities  relationship among entities  An entity is an object that exists independently and is distinguishable from other objects.  an employee, a company, a car, etc.  color, age, etc. are not entities Simplicity is Beauty A Picture is Worth a Million Words

4 Department of Computer Science, HKUST 3 An entity set is a set of entities of the same type. E.g., a set of employees, a set of departments  also called entity types Employee Entity Type : e1e1 e2e2 e3e3 Entity set: … The actual employees A general specification

5 Department of Computer Science, HKUST 4 Attributes Properties of an entity or a relationship –name, address, weight, height are properties of a Person entity. date of marriage is a property of the relationship Marriage.

6 Department of Computer Science, HKUST 5 Types of Attributes Simple attribute: contains a single value. Employee EmpNo Name Address

7 Department of Computer Science, HKUST 6 Composite attribute: consists of several components Country Employee Address Street City EmpNo Name

8 Department of Computer Science, HKUST 7 Multivalue attribute: contains more than one value Employee Phone

9 Department of Computer Science, HKUST 8 Derived attribute: computed from other attributes Employee Age Bonus

10 Department of Computer Science, HKUST 9 Key Attributes A set of attributes that can uniquely identify an entity Employee EmpNo Name ERD tabular

11 Department of Computer Science, HKUST 10 Key Attributes Composite key: Name or Address alone cannot uniquely identify an employee, but together they can! Employee Name Address

12 Department of Computer Science, HKUST 11 Key Attributes An entity may have more than one key –e.g., EmpNo, (Name, Address) –only one is selected as the key. (sometimes called the Primary key) Employee EmpNo Name Address In many cases, a key is artificially introduced (e.g., EmpNo) to make applications more efficient. Question: does a desk has a key?

13 Department of Computer Science, HKUST 12 Relationship A relationship is an association between one or more entities. –Given a customer and an account, the relationship depositor between them indicates that the customer deposits money into the account.

14 Department of Computer Science, HKUST 13 A relationship may have attributes A relationship type or relationship set identifies relationships of the same properties Customer depositor Account Amount CusNo Name AccNo Name Question: Could Amount be an attribute of Customer? Or an attribute of Account? What does Amount mean? How many values you want to keep?

15 Department of Computer Science, HKUST 14 Tabular: Representation of Relationship A B A-101 A-201 A Graph : Depositor Note: this is NOT an ERD The amount in each deposit. CustomerNo A B AccountNo A-101 A-201 A-302 Amount

16 Department of Computer Science, HKUST 15 Represent Amount as an attribute of Account Try an Alternative AccountNo A-101 A-201 A-302 Name Current Saving Current Amount Consider Amount as the balance of an account (I.e., one value per account) or as the last deposit amount. “Multivalue” attribute, though allowed in ER model, is difficult to implement

17 Department of Computer Science, HKUST 16 Cardinality of Relationships Number of entities that can be associated together in a relationship set. 1 : 1 CustomerLoan Borrows + A customer can borrow 1 loan and vice versa

18 Department of Computer Science, HKUST 17 1:N Customer Loan Customer Borrow Loan + A Customer can borrow more than 1 loan, whereas a loan has only one borrower.

19 Department of Computer Science, HKUST 18 N : M Relationships Customer Borrow loan * A customer can borrow more than one loan * A loan can have more than one borrower.

20 Department of Computer Science, HKUST 19 Notes Cardinality specifies the maximum condition. 1 : 1 N : M 1 : N +The minimum is specified by existence constraints (explained later) +Conditions must be satisfied at all times

21 Department of Computer Science, HKUST 20 Degrees of a Relationship Set Number of entity sets participating in a relationship set. Customer Loan Borrow - Binary +Relationships with degree >3 is very rare. +Hint: translate a ternary relationship into one sentence. +Can you break it up into two or more sentences? +A customer borrows a loan from a branch. +A customer borrows a loan. A loan is made at a branch. CustomerLoan Borrow Branch - Ternary

22 Department of Computer Science, HKUST 21 Recursive Relationship A relationship relating entitles of the same type Employees play different roles: manager or worker –Without role names, you can’t tell whether 1 employee manages n other employees or n employees manages 1 employee You can “unfold” a recursive relationship to understand it: managerworker Employee work-for Employee manager worker Employee work-for

23 Department of Computer Science, HKUST 22 Tabular Representation of Recursive Relationships Without Role Names With Role Names +Where ManagerNo and WorkerNo are Valid EmployeeNo ManagerNoWorkerNo A1234A6543 A1234A8734 EmployeeNo A1234A8734 A1234A6543

24 Department of Computer Science, HKUST 23 Existence Dependence The existence of an entity depends on the existence of another entity Customer Loan loan borrow CusNo LoanNo A loan cannot exist if there is no borrower.

25 Department of Computer Science, HKUST 24 Weak Entities A weak entity cannot be identified with its own attributes  no key A weak entity implies existence dependency but NOT vice versa

26 Department of Computer Science, HKUST 25 LoanNoAmountDate_payPaymentNo Payment A loan may have 240 payments, each identified by a payment no The PaymentNo is unique given a particular loan but not unique globally PaymentNo is called partial key The primary key of Payment is the combination of LoanNo and PaymentNo. Loan payment Question: Why not combine loan and payment into one entity type? Amount Loan

27 Department of Computer Science, HKUST 26 Weak Entity vs Existence Constraint In the existence constraint example, LoanNo can uniquely identify a Loan in the database so it is not a weak entity. The existence constraint means that you cannot create a Loan record without first knowing who borrowed the loan.

28 Department of Computer Science, HKUST 27 A child may not be old enough to have a HKID number Even if he/she has a HKID number, the company may not be interested in keeping it in the database. EmpNoName Dependent Another example of weak entity type Emp_Dep Age Employee

29 Department of Computer Science, HKUST 28 What does a DB Design do? Individual tools are easy to use, but using them together to solve a problem is difficult. Let’s examine a few problems...

30 Department of Computer Science, HKUST 29 Ternary Relationship CustomerLoan Borrow Branch A customer borrows a loan from a branch. CustomerLoan Borrow Branch Issue A customer borrows a loan. A loan is issued from a branch. Note: these are all N:M relationships.

31 Department of Computer Science, HKUST 30 What are the Differences? A customer borrows a loan from a branch. A customer borrows a loan. A loan is issued from a branch.

32 Department of Computer Science, HKUST 31 Imagine a bank allows borrowers of the same loan to go to difference branches for signing documents, deposit payments, etc. The two schemes are not the same. The binary relationships capture less information. Adding a third relationship won’t help. CustomerLoan Borrow Branch Issue Cus_Br

33 Department of Computer Science, HKUST 32 Why? Customer, Loan and Branch have a N:M:P relationship Why? A12345 B56789 Central Wanchai L-001 John borrows a loan which is issued from Wanchai branch N:N:1 relationship can be decomposed (A loan is issued by ONE BRANCH ONLY) L-002 C54321

34 Department of Computer Science, HKUST 33 In general, any non-binary relationship can be represented using binary relationships by creating an artificial entity set. –Replace R between entity sets A, B and C by an entity set E, and three relationship sets: 1. R A relating E and A 2. R B relating E and B 3. R C relating E and C –Create a special identifying attribute for E –Add any attributes of R to E –For each relationship (a i, b i, c i ) in R, create 1. a new entity e i in the entity set E 2. add (e i, a i ) to R A 3. add (e i, b i ) to R B 4. add (e i, c i ) to R C Converting Non-Binary Relationships to Binary Form

35 Department of Computer Science, HKUST 34 L-001 CustomerDummy A12345x001 B56789x002 B56789x003 C54321x004 Example A12345 B56789 Central Wanchai L-002 C54321 DummyLoan x001L-001 x002L-001 x003L-002 x004L-002 DummyBranch x001Wanchai x002Central x003Wanchai x004Wanchai Loan Issue CustomerDummy Borrow Cus_Br Branch

36 Department of Computer Science, HKUST 35 Binary relationships may have different meanings so that they can’t be combined into ternary relationships. Binary relationships to Ternary? CustomerLoan Borrow Branch Issue Buy_stock You may have a ternary relationship Customer-Loan-Branch and other binary relationships between Customer, Loan and Branch

37 Department of Computer Science, HKUST 36 A case Study A primary school student writes a composition about a picnic: Today is Sep 9, the weather is fine. My classmates, John, Mary and I go to a picnic in Sai Kung. Our teacher is Ms Wong Picnic weather destination date Students Name Teacher Name My Initial Design:

38 Department of Computer Science, HKUST 37 Questions ? Why “John”, “Mary”, “Miss Wong” are not in the ER diagram ? What do these names tell us ? What are the keys of Student, Picnic & Teacher ? What are the cardinalities of the relationships ?

39 Department of Computer Science, HKUST 38 Every student has an ID number, it is better to keep it in the database and use it as a key I bet that there won’t be teachers with the same name; otherwise, I’ll add employee number and use it as a key goes is N:M, why ? A picnic has more than one student participating; also, a student can go to more than 1 picnic. However, this N:M relationship allows a student to go to more than one picnic on the same date leading is N:1, why? Depends on your assumptions –I assume a teacher can only lead 1 picnic on a certain date, so given the teacher name and the date, I can identify a picnic Picnic is made a weak entity. I could have added a PicnicNo, but it would be very awkward. My solution Student StudentNo Nameweather date destination Picnic goes leading Teacher Name Question: How to record number of students in a picnic?

40 Department of Computer Science, HKUST 39 E-R Design Decisions The use of an attribute or entity set to represent an object. –Should an address be an attribute or entity? Whether a real-world concept is best expressed by an entity set or a relation set. –Should marriage be an entity or relationship? –Should picnic be an entity or relationship? The use of a ternary relationship versus a pair of binary relationships. –See the borrow-loan-branch example The use of a strong or weak entity set. –See the employee-dependent example

41 Department of Computer Science, HKUST 40 E-R Diagram for Company Database EMPLOYEE WORKS_FOR MANAGES CONTROLS Startdate DEPARTMENT WORKS_ON PROJECT Hours DEPENDENTS_OF DEPENDENT SUPERVISION supervisee supervisor FnameMinitLname Name Sex Address Salary Ssn Bdate Number Of Employees Name Number Locations Name Number Location RelationshipBirthdateSexName Can you translate it back into English?

42 Department of Computer Science, HKUST 41 Consider representing Part-time and Full-time employees in the company database: –Either you have two entity types will lots of similarity –Or you have a single entity type with redundancy for most of the entities within it ER model is extended to support other features such as generalization (but it won’t be covered in this course!) Limitations of ER model

43 Department of Computer Science, HKUST 42 Reduction of an E-R Schema to tables Primary keys allow entity sets and relationship sets to be expressed uniformly as tables which represent the contents of the database. A database which conforms to an E-R diagram can be represented by a collection of tables. Always! Converting an E-R diagram to a table format is the basis for deriving a relational database design from an E-R diagram.

44 Department of Computer Science, HKUST 43 Translating ERDs into Tables Translating ERDs into Tables

45 Department of Computer Science, HKUST 44 Representing Entity Sets as Tables A strong/regular entity set reduces to a table with the same attributes. customer customer-name customer-streetcustomer-id Jones Hayes Smith Main North customer-city Harrison Rye Harrison customer borrow loan loan-no cust-id share% date cust-name cust-no cust-city

46 Department of Computer Science, HKUST 45 Composite key Representing Weak Entity Sets as Tables A weak entity set becomes a table that includes a column for the primary key of the identifying strong entity set payment loan-no payment-datepayment-nopayment-amount L-17 L-15 L May May May loan Loan- payment payment-no Loan-no date Amount

47 Department of Computer Science, HKUST 46 Representing Relationship Sets as Tables A many-to-many relationship set is represented as table with columns for the primary keys of the two participating entity sets, and any descriptive attributes of the relationship set. customer borrow loan loan-no cust-no share% date cust-name borrower cust-noshareloan-no A12345 B45678 L-17 L-15 L May May May 1999

48 Department of Computer Science, HKUST 47 +For 1:N and 1:1 relationships, you can create a table for each relationship customer cust-no cust-name A12345 B56789 Peter Wong Mary Cheung loan loan-no L-001 L-002 date Sep 2000 Aug 2001 customer borrow loan cust-no cust-name date loan-no cust-no A12345 B56789 indicates who borrowed the loan loan-record Cust-no A12345 B56789 Loan-no L-001 L-002 +But it is more concise to merge the relationship-table with the entity-table on the “N” side

49 Department of Computer Science, HKUST 48 +In a 1:N relationship, can we include the key from the “N” side in the table representing the entity in the “1” side? I.e., include Loan_no into the Customer table. Why and Why not? Questions to Think About +How can we express existence constraints on table?

50 Department of Computer Science, HKUST 49 Questions to Think About (Cont.) +In a 1:1 relationship, we can include the key from either entity into the table representing the other entity. Suppose the Loan-Customer relationship is 1:1, would you include the Customer_no into Loan or Loan_no into Customer? customer borrow loan cust-no cust-name date loan-no loan loan-no L-001 L-002 date Sep 2000 Aug 2001 cust-no A12345 B56789 customer cust-no cust-name A12345 B56789 Peter Wong Mary Cheung loan-no L-001 L-002 Which one is better?

51 Department of Computer Science, HKUST 50 Questions to Think About (Cont.) +How can we express existence constraints on table? customer borrow loan cust-no cust-name date loan-no loan loan-no L-001 L-002 date Sep 2000 Aug 2001 cust-no A12345 Not allowed; must be enforced by DBMS

52 Department of Computer Science, HKUST 51 Weak Entities +Since a weak entity has to include the primary key of the identifying entity, the 1:N relationship is already captured. E.g., The payment table already contains information about the Loan (I.e., loan_no) Already indicates the 1:N relationship between loan-no and payment-no payment loan-no payment-datepayment-nopayment-amount L May May May

53 Department of Computer Science, HKUST 52 Questions to Think about: Relationship or attribute? Customer depositor Account Amount CusNo Name AccNo Name +We have seen this example before. +Questions: Can I put every attribute on an entity type?


Download ppt "Department of Computer Science, HKUST 1 Comp 231 Database Management Systems Comp 231 Database Management Systems 2. Entity Relationship (ER) Model."

Similar presentations


Ads by Google