CMSC 424 Database design Lecture 3: Entity-Relationship Model. Book: Chap. 1 and 6. Mihai Pop

Size: px

Start display at page:

Download "CMSC 424 Database design Lecture 3: Entity-Relationship Model. Book: Chap. 1 and 6. Mihai Pop"

Nathan Cameron
6 years ago
Views:

1 CMSC 424 Database design Lecture 3: Entity-Relationship Model Book: Chap. 1 and 6 Mihai Pop

2 Database Design Steps Entity-relationship Model Typically used for conceptual database design info Conceptual DB design Three Levels of Modeling Conceptual Data Model Logical DB design Logical Data Model Relational Model Typically used for logical database design Physical DB design Physical Data Model

3 Problems in our First Design does not capture the fact that a library carries books of a specific author does not capture the fact that a library carries a specific book does not capture the fact that an author has written a specific book does not store which edition of the book the library has, how many copies, etc. SS# NAME TEL BDATE AUTHOR WROTE-ON SNAME SUBJECT INDEX BOOK ISBN TITLE CARRY LNAME LIBRARY

4 2 nd Attempt to the Library Design SS# NAME TEL BDATE AUTHOR WROTE ISBN TITLE BOOK INDEX SUBJECT SNAME IN-STOCK QUANTITY EDITION LNAME LIBRARY Much better

5 Next: Types of Attributes Simple vs Composite Single value per attribute? Single-valued vs Multi-valued E.g. Phone numbers are multi-valued Derived If date-of-birth is present, age can be derived Can help in avoiding redundancy, enforcing constraints etc

6 Types of Attributes cust-name access-date number cust-id customer has account cust-street cust-city balance

7 age Types of Attributes multi-valued (double ellipse) (one can have many phone numbers) access-date derived (dashed ellipse) number (age can be computed from birth date) cust-name cust-id date-of-birth customer has account cust-street cust-city phone no. balance

8 Types of Attributes age cust-name access-date number cust-id date-of-birth customer has account cust-street cust-city month day year phone no. balance Composite Attribute

9 Next: Keys Key = set of attributes that uniquely identifies an entity or a relationship

10 Entity Keys date-of-birth cust-id cust-name {cust-id} is a natural primary key Typically, SSN forms a good primary key Try to use a candidate key that rarely changes e.g. something involving address not a great idea age customer cust-street cust-city phone no.

11 Superkey Entity Keys any set of attributes that can distinguish entities Candidate key a minimal superkey Can t remove any attribute and preserve key-ness Primary key {cust-id, age} not a candidate key {cust-name, cust-city, cust-street} is assuming cust-name is not unique Candidate key chosen as the key by DBA Underlined in the ER Diagram

12 Entity Keys date-of-birth cust-id cust-name {cust-id} is a natural primary key Typically, SSN forms a good primary key Try to use a candidate key that rarely changes e.g. something involving address not a great idea age customer cust-street cust-city phone no.

13 Relationship Set Keys What attributes are needed to represent a relationship completely and uniquely? Union of primary keys of the entities involved, and relationship attributes cust-id access-date number customer has account {cust-id, access-date, account number} describes a relationship completely

14 Relationship Set Keys Is {cust-id, access-date, account number} a candidate key? No. Attribute access-date can be removed from this set without losing key-ness In fact, union of primary keys of associated entities is always a superkey cust-id access-date number customer has account

15 Relationship Set Keys Is {cust-id, account-number} a candidate key? Depends cust-id access-date number customer has account

16 Relationship Set Keys Is {cust-id, account-number} a candidate key? Depends cust-id access-date number customer has account If one-to-one relationship, either {cust-id} or {account-number} sufficient Since a given customer can only have one account, she can only participate in one relationship Ditto account

17 Relationship Set Keys Is {cust-id, account-number} a candidate key? Depends cust-id access-date number customer has account If one-to-many relationship (as shown), {account-number} is a candidate key A given customer can have many accounts, but at most one account holder per account allowed

18 Relationship Set Keys General rule for binary relationships one-to-one: primary key of either entity set one-to-many: primary key of the entity set on the many side many-to-many: union of primary keys of the associate entity sets n-ary relationships More complicated rules

19 What have we been doing Why? Understanding this is important Rest are details!! That s what books/manuals are for.

20 Next: Recursive Relationships Sometimes a relationship associates an entity set to itself

21 Recursive Relationships emp-name emp-id emp-street employee manager worker works-for emp-city Must be declared with roles

22 Next: Weak Entity Sets An entity set without enough attributes to have a primary key E.g. Transaction Entity Attributes: transaction-number, transaction-date, transaction-amount, transaction-type transaction-number: may not be unique across accounts

23 Weak Entity Sets A weak entity set must be associated with an identifying or owner entity set Account is the owner entity set for Transaction

24 Weak Entity Sets Still need to be able to distinguish between different weak entities associated with the same strong entity number trans-date trans-number account has Transaction trans-type balance trans-amt

25 Weak Entity Sets Discriminator: A set of attributes that can be used for that number trans-date trans-number account has Transaction trans-type balance trans-amt

26 Weak Entity Sets Primary key: Primary key of the associated strong entity + discriminator attribute set For Transaction: {account-number, transaction-number}

27 Example Design We will model a university database Main entities: Professor Projects Departments Graduate students etc

28 SSN proj-number name area professor project sponsor start rank budget dept-no SSN name dept grad name office age homepage degree

29 SSN proj-number name area professor project sponsor start rank budget dept-no SSN name office dept grad name age homepage degree

30 SSN name area rank professor PI project proj-number sponsor start Co-PI budget Chair Appt Supervises RA dept-no Time (%) SSN name office homepage dept Major advisee grad advisor name age degree Mentor

31 SSN name area rank professor PI project proj-number sponsor start Co-PI budget Chair Appt Supervises RA dept-no Time (%) SSN name office homepage dept Major advisee grad advisor name age degree Mentor

32 SSN name area rank professor PI project proj-number sponsor start Co-PI budget Chair Appt Supervises RA dept-no Time (%) SSN name office homepage dept Major advisee grad advisor name age degree Mentor

33 Thoughts Nothing about actual data How is it stored? No talk about the query languages How do we access the data? Semantic vs Syntactic Data Models Remember: E/R Model is used for conceptual modeling Many conceptual models have the same properties They are much more about representing the knowledge than about database storage/querying

34 Thoughts Basic design principles Faithful Must make sense Satisfies the application requirements Models the requisite domain knowledge If not modeled, lost afterwards Avoid redundancy Potential for inconsistencies Go for simplicity Typically an iterative process that goes back and forth

35 Design Issues Entity sets vs attributes Depends on the semantics of the application Consider telephone (entity: customer, attribute: telephone) or (entity: telephone, entity: customer, relationship: customer_phone) Entity sets vs Relationship sets Consider loan (entity or relationship between customer and bank?) N-ary vs binary relationships Possible to avoid n-ary relationships, but there are some cases where it is advantageous to use them It is not an exact science!!

CMSC 424 Database design Lecture 2: Design, Modeling, Entity-Relationship. Book: Chap. 1 and 6. Mihai Pop

CMSC 424 Database design Lecture 2: Design, Modeling, Entity-Relationship Book: Chap. 1 and 6 Mihai Pop Administrative issues TA: Sharath Srinivas TA office hours: Mon 10-11:30, Wed 3-4:30, AVW 1112 Glue