SAnta Clara UniversityHolliday – COEN 1782–1 Today’s Topic Today: u Constraints, Weak Entity Sets, Entity- Relationship Design. u Read Sections 2.3-2.4.

Slides:



Advertisements
Similar presentations
Constraints in Entity-Relationship Models Zaki Malik September 18, 2008.
Advertisements

1–1 Students Entity/Relationship Model Diagrams to represent designs. Entity like object, = “thing.” Entity set like class = set of “similar” entities/objects.
ENTITY RELATIONSHIP MODELLING
1 Entity-Relationship Model Diagrams Class hierarchies Weak entity sets.
Chapter 4 Notes. Entity-Relationship Model E/R Diagrams Weak Entity Sets Converting E/R Diagrams to Relations.
Design Principles: Faithfulness
Weak Entity Sets. Occasionally, entities of an entity set need “help” to identify them uniquely. Example. Crews might have a number and some description,
Weak Entity Sets. Occasionally, entities of an entity set need “help” to identify them uniquely. Entity set E is weak if in order to identify entities.
Design Principles: Faithfulness
Database Design and the E-R Model Chapter 7 [1 of 2]
DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)
From ER Diagrams to the Relational Model Rose-Hulman Institute of Technology Curt Clifton.
A four-way Relationship
Fall 2001Arthur Keller – CS 1802–1 Schedule Today Sep. 25 (T) u More Entity-Relationship Model. u Read Sections Note: Sep. 27 (TH) Class cancelled.
The Entity-Relationship Data Model
Fall 2001Arthur Keller – CS 1803–1 Schedule Today Oct. 2 (T) Relational Model. u Read Sections Assignment 1 due. Personal Letter of Introduction.
Database Design Concepts INFO1408 Term 2 week 1 Data validation and Referential integrity.
Winter 2002Arthur Keller – CS 1802–1 Schedule Today: Jan. 8 (T) u Weak Entity Sets, Entity-Relationship Design. u Read Sections Jan. 10 (TH) u.
Chapter 2: Entity-Relationship Model (Continued)
CS411 Database Systems Kazuhiro Minami
Database Management System Lecture 6 The Relational Database Model – Keys, Integrity Rules.
Introduction to Database Systems Conceptual Modeling
Database Management COP4540, SCS, FIU Relational Model Chapter 7.
CPSC 603 Database Systems Lecturer: Laurie Webster II, M.S.S.E., M.S.E.E., M.S.BME, Ph.D., P.E. Lecture 3 Introduction to a First Course in Database Systems.
Databases : Entity-Relationship Model 2007, Fall Pusan National University Ki-Joune Li These slides are made from the materials that Prof. Jeffrey D. Ullman.
Dale Roberts 1 Department of Computer and Information Science, School of Science, IUPUI Dale Roberts, Lecturer Computer Science, IUPUI
ER Data Models Ctd. CSET 3300.
©Silberschatz, Korth and Sudarshan2.1Database System Concepts Chapter 2: Entity-Relationship Model Entity Sets Relationship Sets Design Issues Mapping.
1 Session 2 Welcome: The fifth learning sequence “ Entity-Relationship Model -2“ E-R Model Recap : In the previous learning sequence, we discussed the.
Database Management COP4540, SCS, FIU Database Modeling Using the Entity-Relationship Model (Continued)
Tallahassee, Florida, 2015 COP4710 Database Systems E-R Model Fall 2015.
© D. Wong Ch. 2 Entity-Relationship Data Model (continue)  Data models  Entity-Relationship diagrams  Design Principles  Modeling of constraints.
Entity-Relationship Model
Winter 2006Cushing Keller UllmanJudy Cushing2–1 Weak Entity Sets Sometimes an E.S. E ’s key comes not (completely) from its own attributes, but from the.
CPSC 603 Database Systems Lecturer: Laurie Webster II, M.S.S.E., M.S.E.E., M.S.BME, Ph.D., P.E. Lecture 2 Introduction to a First Course in Database Systems.
UNIT_2 1 DATABASE MANAGEMENT SYSTEM[DBMS] [Unit: 2] Prepared By Lavlesh Pandit SPCE MCA, Visnagar.
Database System Concepts, 6 th Ed. ©Silberschatz, Korth and Sudarshan Lecture-03 Introduction –Data Models Lectured by, Jesmin Akhter.
ICOM 5016 – Introduction to Database Systems Lecture 5 Dr. Manuel Rodriguez Department of Electrical and Computer Engineering University of Puerto Rico,
Home Work. Design Principles and Weak Entity Sets.
Databases 1 Fifth lecture. Entity-Relationship Model Diagrams Class hierarchies Weak entity sets From E/R diagrams to Relations 2.
Instructor: Jinze Liu Fall Phases of Database Design u Conceptual design begins with the collection of requirements and results needed from the.
CPSC 603 Database Systems Lecturer: Laurie Webster II, M.S.S.E., M.S.E.E., M.S.BME, Ph.D., P.E. Lecture 4 Introduction to a First Course in Database Systems.
Entity-Relationship Model E/R Diagrams Converting E/R Diagrams to Relations.
Entity Relationship Diagram (ERD). Objectives Define terms related to entity relationship modeling, including entity, entity instance, attribute, relationship.
Winter 2002Arthur Keller – CS 1802–1 Weak Entity Sets Sometimes an E.S. E ’s key comes not (completely) from its own attributes, but from the keys of one.
Database Management COP4540, SCS, FIU Database Modeling Using the Entity- Relationship Model (Continued)
CS 405G Introduction to Database Systems Lecture 3: ER Model Instructor: Chen Qian.
High-level Database Models Prof. Yin-Fu Huang CSIE, NYUST Chapter 4.
IT 5433 LM3 Relational Data Model. Learning Objectives: List the 5 properties of relations List the properties of a candidate key, primary key and foreign.
Database Design and Programming Jan Baumbach Adopted from previous slides of Peter Schneider-Kamp.
CS422 Principles of Database Systems Entity-Relationship Model Chengyu Sun California State University, Los Angeles Adapted from Jeffrey Ullman’s lecture.
Introduction to Database Systems, CS420
Let try to identify the conectivity of these entity relationship
Entity-Relationship Model
COP4710 Database Systems E-R Model.
Entity-Relationship Model
Weak Entity Sets Sometimes an E.S. E ’s key comes not (completely) from its own attributes, but from the keys of one or more E.S.’s to which E is linked.
Constraints in Entity-Relationship Models
CPSC-310 Database Systems
Entity/Relationship Model
Instructor: Zhe He Department of Computer Science
Session 2 Welcome: The fifth learning sequence
Database Modeling using Entity Relationship Model (E-R Model)
Chapter 7: Entity-Relationship Model
CS4433 Database Systems E-R Model.
CS 505: Intermediate Topics to Database Systems
Database Management system
Database Management system
CS 405G: Introduction to Database Systems
Session 5: Weak Entity Sets and ER Model to Relational ( )
Presentation transcript:

SAnta Clara UniversityHolliday – COEN 1782–1 Today’s Topic Today: u Constraints, Weak Entity Sets, Entity- Relationship Design. u Read Sections Next time u Relational Model, Functional Dependencies. u Read Sections

SAnta Clara UniversityHolliday – COEN 1782–2 Keys A super key of an ES is a set of one or more attributes whose values uniquely determine each entity. A candidate key of an ES is a minimal super key. There may be several candidate keys for an entity set. One of the candidate keys is selected to be the primary key. The candidate key of a relationship set is a combination of the primary keys of the related entity sets. Primary keys are underlined in an ER diagram.

SAnta Clara UniversityHolliday – COEN 1782–3 More keys The primary key of the customer entity is: The primary key of the account entity is: The primary key of the depositor relationship is: What are all the super keys of customer?

SAnta Clara UniversityHolliday – COEN 1782–4 Referential Integrity Constraints A value or entity referred to by some entity must actually exist in the database instance. There must exist a customer in the database who is the primary owner of the account. AccountCustomer Depositor

SAnta Clara UniversityHolliday – COEN 1782–5 Weak Entity Sets Sometimes an E.S. ’s key comes not (completely) from its own attributes, but from the keys of one or more E.S.’s to which E is linked by a supporting many-one relationship. Called a weak E.S. Represented by putting double rectangle around E and a double diamond around each supporting relationship. Many-one-ness of supporting relationship (includes 1-1) essential. u With many-many, we wouldn't know which entity provided the key value. “Exactly one” also essential, or else we might not be able to extract key attributes by following the supporting relationship.

SAnta Clara UniversityHolliday – COEN 1782–6 Example: Logins ( Addresses) Login name = user name + host name, e.g., A “login” entity corresponds to a user name on a particular host, but the passwd table doesn’t record the host, just the user name, e.g., ark. Key for a login = the user name at the host (which is unique for that host only) + the IP address of the host (which is unique globally). Design issue: Under what circumstances could we simply make login-name and host-name be attributes of logins, and dispense with the weak name

SAnta Clara UniversityHolliday – COEN 1782–7 Example: Chain of “Weakness” Consider IP addresses consisting of a primary domain (e.g., edu ), subdomain (e.g., ucsc ), and host (e.g., soe ). Key for primary domain = its name. Key for secondary domain = its name + name of primary domain. Key for host = its name + key of secondary domain = its name + name of secondary domain + name of primary domain. 2ndary Domains Primary In1 name In2 name

SAnta Clara UniversityHolliday – COEN 1782–8 Design Principles Setting: client has (possibly vague) idea of what he/she wants. You must design a database that represents these thoughts and only these thoughts. Avoid redundancy = saying the same thing more than once. Wastes space and encourages inconsistency. Example Good: BeersManfs ManfBy nameaddrname

SAnta Clara UniversityHolliday – COEN 1782–9 Example Bad: repeats manufacturer address for each beer they manufacture. Bad: manufacturer’s name said twice. BeersManfs ManfBy nameaddrnamemanf Beers namemanf Manf addr

SAnta Clara UniversityHolliday – COEN 1782–10 The design schema should enforce as many constraints as possible. u Don't rely on future data to follow assumptions. Example If registrar wants to associate only one instructor with a course, don't allow sets of instructors and count on departments to enter only one instructor per course. Use Schema to Enforce Constraints

SAnta Clara UniversityHolliday – COEN 1782–11 Entity Sets Vs. Attributes You may be unsure which concepts are worthy of being entity sets, and which are handled more simply as attributes. Tricky since there is a temptation to create needless entity sets. If the only info about a manufacturer is its name: Wrong: Right: BeersManfs ManfBy name Beers namemanf

SAnta Clara UniversityHolliday – COEN 1782–12 Intuitive Rule for E.S. Vs. Attribute Make an entity set only if it either: 1.Is more than a name of something; i.e., it has nonkey attributes or relationships with a number of different entity sets, or 2.Is the “many” in a many-one relationship. AccountCustomer Depositor

SAnta Clara UniversityHolliday – COEN 1782–13 Example The following design illustrates both points: Manfs deserves to be an E.S. because we record addr, a nonkey attribute. Beers deserves to be an E.S. because it is at the “many” end. u If not, we would have to make “set of beers” an attribute of Manfs – something we avoid doing, although some may tell you it is OK in E/R model. BeersManfs ManfBy nameaddrname

SAnta Clara UniversityHolliday – COEN 1782–14 Don't Overuse Weak E.S. There is a tendency to feel that no E.S. has its entities uniquely determined without following some relationships. However, in practice, we almost always create unique ID's to compensate: social-security numbers, VIN's, etc. Times weak E.S.'s seem necessary are when: a) We can't easily create such ID's; e.g., no one is going to accept a “species ID” as part of the standard nomenclature (species is a weak E.S. supported by membership in a genus). b) There is no global authority to create them, e.g., local logins.

SAnta Clara UniversityHolliday – COEN 1782–15 What can you tell from the ERD?

SAnta Clara UniversityHolliday – COEN 1782–16 Classroom Design Exercise Imagine we are creating a database for a dorm, which includes a cooperative kitchen. We want to record certain information about each resident. What? Not all residents belong to the kitchen coop. Those that do interact in various ways: 1. They take turns at various jobs: preparer, cleanup, buyer (for supplies). No one should have two jobs on one day. 2. They may or may not be vegetarian. Each meal must have at least one vegetarian entreé. 3. They pay fees to the coop. For each meal, there is a menu. Each menu item requires certain ingredients, which must be on hand.

SAnta Clara UniversityHolliday – COEN 1782–17 If There's Time… Suppose we only need to have a vegetarian choice for a given meal if there is at least one vegetarian taking that meal. How would we modify the database schema?