1 Lecture 04 Entity/Relationship Modelling. 2 Outline E/R model (Chapter 5) From E/R diagrams to relational schemas (Chapter 5) Constraints in SQL (Chapter.

Slides:



Advertisements
Similar presentations
Relational Database. Relational database: a set of relations Relation: made up of 2 parts: − Schema : specifies the name of relations, plus name and type.
Advertisements

CSE 544 Constraints Lecture #3 Friday, January 13, 2011 Dan Suciu , Winter
SQL Lecture 10 Inst: Haya Sammaneh. Example Instance of Students Relation  Cardinality = 3, degree = 5, all rows distinct.
Information Systems Chapter 4 Relational Databases Modelling.
Lecture 6: Design Constraints and Functional Dependencies January 21st, 2004.
1 Lecture 02: Conceptual Design Wednesday, October 6, 2010 Dan Suciu -- CSEP544 Fall 2010.
1 Relational Model and Translating ER into Relational.
Lecture #2 October 5 th, 2000 Conceptual Modeling Administration: –HW1 available –Details on projects –Exam date –XML comment.
1 Introduction to Database Systems CSE 444 Lecture 05: Views, Constraints April 9, 2008.
1 Lecture 06: SQL Friday, January 14, Outline Indexes Defining Views (6.7) Constraints (Chapter 7) We begin E/R diagrams (Chapter 2)
1 Lecture 05: SQL Wednesday, October 8, Outline Outer joins (6.3.8) Database Modifications (6.5) Defining Relation Schema in SQL (6.6) Indexes.
1 Lecture 3: Database Modeling (continued) April 5, 2002.
M.P. Johnson, DBMS, Stern/NYU, Spring C : Database Management Systems Lecture #15 M.P. Johnson Stern School of Business, NYU Spring, 2005.
1 Conceptual Design with ER Model Lecture #2. 2 Lecture Outline Logistics Steps in building a database application Conceptual design with ER model.
Lecture 9: Conceptual Database Design January 27 th, 2003.
Multiplicity in E/R Diagrams
The Relational Data Model Database Model (ODL, E/R) Relational Schema Physical storage ODL definitions Diagrams (E/R) Tables: row names: attributes rows:
1 Lecture 4: Database Modeling (end) The Relational Data Model April 8, 2002.
SQL Constraints & Triggers May 10 th, Agenda Big picture –what are constraints & triggers? –where do they appear? –why are they important? In SQL.
CS411 Database Systems Kazuhiro Minami
Database Design April 3, Projects, More Details Goal: build a DB application. (almost) anything goes. Groups of 3-4. End of week 2: groups formed.
Entity / Relationship Diagrams Objects entities Classes entity sets Attributes are like in ODL. Relationships: like in ODL except - not associated with.
CS411 Database Systems Kazuhiro Minami 02: The Entity-Relationship Model.
E/R Diagrams and Functional Dependencies. Modeling Subclasses The world is inherently hierarchical. Some entities are special cases of others We need.
Lecture 08: E/R Diagrams and Functional Dependencies.
Lecture 2: E/R Diagrams and the Relational Model Thursday, January 4, 2001.
1 Lecture 6: Views Friday, January 17th, Updating Views How can I insert a tuple into a table that doesn’t exist? Employee(ssn, name, department,
1 SQL Constraints and Programming. 2 Agenda Constraints in SQL Systems aspects of SQL.
Phase 2, Answering queries using views. February 2 nd, 2004.
Conceptual Database Design. Building an Application with a DBMS Requirements modeling (conceptual, pictures) –Decide what entities should be part of the.
1 Introduction to Database Systems CSE 444 Lecture 07 E/R Diagrams October 10, 2007.
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.
1 SQL Constraints and Programming. 2 Agenda Constraints in SQL Systems aspects of SQL.
Lecture 2: E/R Diagrams and the Relational Model Wednesday, April 3 rd, 2002.
Lecture 3: Conceptual Database Design and Schema Design April 12 th, 2004.
1 Introduction to Database Systems CSE 444 Lecture 04: SQL April 7, 2008.
1 Lecture 08: E/R Diagrams and Functional Dependencies Friday, January 21, 2005.
COMP 430 Intro. to Database Systems Entity-Relationship Diagram Basics Slides use ideas from Chris Ré.
Modeling Constraints Extracting constraints is what modeling is all about. But how do we express them? Examples: Keys: social security number uniquely.
COMP 430 Intro. to Database Systems ER Design Considerations Slides use ideas from Chris Ré.
1 Lecture 06 Data Modeling: E/R Diagrams Wednesday, January 18, 2006.
1 Lecture 05: SQL Wednesday, October 8, Outline Database Modifications (6.5) Defining Relation Schema in SQL (6.6) Indexes Defining Views (6.7)
1 CS122A: Introduction to Data Management Lecture #4 (E-R  Relational Translation) Instructor: Chen Li.
Lecture 4: The E/R Model Lecture 4 Today’s Lecture 1.E/R Basics: Entities & Relations ACTIVITY: Crayon time! 2.E/R Design considerations ACTIVITY: Crayon.
Lecture 5: Conceptual Database Design
Modeling Constraints Extracting constraints is what modeling is all about. But how do we express them? Examples: Keys: social security number uniquely.
COP4710 Database Systems E-R Model.
Database Design Oct. 3, 2001.
Database Design Why do we need it? Consider issues such as:
Lecture 4 Lecture 4: The E/R Model.
Conceptual Database Design
Cse 344 March 2nd – E/r diagrams.
Cse 344 May 14th – Entities.
From E/R Diagrams to Relational Schema
Lecture 4: Database Modeling (continued)
Cse 344 May 11th – Entities.
Lecture 2: Database Modeling (end) The Relational Data Model
Lecture 06 Data Modeling: E/R Diagrams
name category name price makes Company Product stockprice buys employs
Lecture 05 Views, Constraints
CMPT 354: Database System I
Lecture 9: The E/R Model II
Lecture 10: The E/R Model III
Lecture 5: The Relational Data Model
Lecture 06: SQL Monday, October 11, 2004.
CS4433 Database Systems E-R Model.
Lecture 05: SQL Wednesday, October 9, 2002.
Presentation transcript:

1 Lecture 04 Entity/Relationship Modelling

2 Outline E/R model (Chapter 5) From E/R diagrams to relational schemas (Chapter 5) Constraints in SQL (Chapter 4)

3 1. Database Design Modelling –Decide which part of reality is represented in a database –Agree on structure of the database before deciding on a particular implementation Conceptual Modelling –oriented towards application and users –independent of technology and implementation

4 Some Terminology Classes of similar objects (and their relationships) students Instances Student -name -firstname -birthdate -section -year Type (of table) Database Etudiant (relational) Schema Real world perceptionAbstraction / Description E/R Diagram Class

5 Conceptual Modelling Consider issues such as: –What entities to model –How entities are related –What constraints exist in the domain –How to achieve good designs

6 Database Design Formalisms 1. Entity/Relationship model (E/R): –More relational in nature. –Very widely used 2. Object Definition Language (ODL): –Closer in spirit to object-oriented models (e.g. Java) –Will not be covered Both can be translated (semi-automatically) to relational schemas

7 2. Entity / Relationship Diagrams Objects entities Classes entity sets Attributes are like in Java. Relationships: like object references in Java except - first class citizens (not associated with classes) - bidirectional Product address buys

8 address namessn Person buys makes employs Company Product namecategory stockprice name price

9 Keys in E/R Diagrams Every entity set must have a key –a key is an attribute that has a different value for every entity Product namecategory price

10 What is a Relation ? A mathematical definition: –if A, B are sets, then a relation R is a subset of A x B A={1,2,3}, B={a,b,c,d}, R = {(1,a), (1,c), (3,b)} - makes is a subset of Product x Company: a b c d A= B= makes Company Product

11 Multiplicity of E/R Relations one-one: many-one many-many abcdabcd abcdabcd abcdabcd

12 address namessn Person buys makes employs Company Product namecategory stockprice name price What does this say ?

13 Multi-way Relationships How do we model a purchase relationship between buyers, products and stores? Purchase Product Person Store Can still model as a mathematical set (how ?)

14 Q: what does the arrow mean ? A: if I know the store, person, invoice, I know the movie too Rental VideoStore Person Movie Invoice Arrows in Multiway Relationships

15 Q: what do these arrows mean ? A: store, person, invoice determines movie and store, invoice, movie determines person Rental VideoStore Person Movie Invoice Arrows in Multiway Relationships

16 Q: how do I say: “invoice determines store” ? A: no good way; best approximation: Rental VideoStore Person Movie Invoice Arrows in Multiway Relationships

17 Roles in Relationships Purchase What if we need an entity set twice in one relationship? Product Person Store salesperson buyer

18 Attributes on Relationships Purchase Product Person Store date

19 Converting Multi-way Relationships to Binary Purchase Person Store Product StoreOf ProductOf BuyerOf date

20 4. From E/R Diagrams to Relational Schema Entity set  relation Relationship  relation

21 Entity Set to Relation Product namecategory price Product(name, category, price) name category price gizmo gadgets $19.99

22 Relationships to Relations makes Company Product namecategory Stock price name Makes(product-name, product-category, company-name, year) Product-name Product-Category Company-name Starting-year gizmo gadgets gizmoWorks 1963 Start Year price (watch out for attribute name conflicts)

23 Relationships to Relations makes Company Product namecategory Stock price name No need for Makes. Modify Product: name category price StartYear companyName gizmo gadgets gizmoWorks Start Year price

24 Multi-way Relationships to Relations Purchase Product Person Store name price ssnname address Purchase(prodName,stName,ssn)

25 4. Design Principles Purchase Product Person What’s wrong? President PersonCountry Moral: be faithful!

26 Design Principles: What’s Wrong? Purchase Product Store date personName personAddr Moral: pick the right kind of entities.

27 Design Principles: What’s Wrong? Purchase Product Person Store date Dates Moral: don’t complicate life more than it already is.

28 Design Principles Purchase Product Person Store pricedate

29 Information Loss Sells Product Store price date BuysBuysAt Person Moral: avoid "navigation traps"

30 Modeling Subclasses Some objects in a class may be special define a new class better: define a subclass Products Software products Educational products So --- we define subclasses in E/R

31 Product namecategory price isa Educational ProductSoftware Product Age Groupplatforms Subclasses

32 Understanding Subclasses Think in terms of records: –Product –SoftwareProduct –EducationalProduct field1 field2 field1 field2 field1 field2 field3 field4 field5

33 Subclasses to Relations Product namecategory price isa Educational ProductSoftware Product Age Groupplatforms NamePriceCategory Gizmo99gadget Camera49photo Toy39gadget Nameplatforms Gizmounix NameAge Group Gizmotodler Toyretired Product Sw.Product Ed.Product

34 Modeling Subclass Structure Product Educational Product Software Product Educ-software Product isa Platforms required memory Educational-method ageGroup topic

35 Modeling UnionTypes With Subclasses FurniturePiece Person Company Say: each piece of furniture is owned either by a person, or by a company

36 Modeling Union Types with Subclasses Say: each piece of furniture is owned either by a person, or by a company Solution 1. Acceptable, imperfect (What’s wrong ?) FurniturePiecePerson Company ownedByPerson

37 Modeling Union Types with Subclasses Solution 2: better, more laborious isa FurniturePiece Person Company ownedBy Owner isa

38 5. Constraints in E/R Diagrams Finding constraints is part of the modeling process. Commonly used constraints: Keys: social security number uniquely identifies a person. Single-value constraints: a person can have only one father. Referential integrity constraints: if you work for a company, it must exist in the database. Other constraints: peoples’ ages are between 0 and 150.

39 Keys in E/R Diagrams address namessn Person Product namecategory price No formal way to specify multiple keys in E/R diagrams Underline:

40 Single Value Constraints makes v. s.

41 Referential Integrity Constraints CompanyProduct makes CompanyProduct makes Each product made by at most one company. Some products made by no company Each product made by exactly one company.

42 Other Constraints CompanyProduct makes <100 What does this mean ?

43 Weak Entity Sets Entity sets are weak when their key comes from other classes to which they are related. UniversityTeam affiliation numbersportname Notice: we encountered this when converting multiway relationships to binary relationships

44 Handling Weak Entity Sets UniversityTeam affiliation numbersportname Convert to a relational schema (in class) Team(number,sport,university-name)

45 6. Constraints in SQL A constraint = a property that we’d like our database to hold The system will enforce the constraint by taking some actions: –forbid an update –or perform compensating updates

46 Constraints in SQL Constraints in SQL: Keys, foreign keys Attribute-level constraints Tuple-level constraints Global constraints: assertions The more complex the constraint, the harder it is to check and to enforce simplest Most complex

47 Keys OR: CREATE TABLE Product ( name CHAR(30) PRIMARY KEY, category VARCHAR(20)) CREATE TABLE Product ( name CHAR(30) PRIMARY KEY, category VARCHAR(20)) CREATE TABLE Product ( name CHAR(30), category VARCHAR(20) PRIMARY KEY (name)) CREATE TABLE Product ( name CHAR(30), category VARCHAR(20) PRIMARY KEY (name))

48 Keys with Multiple Attributes CREATE TABLE Product ( name CHAR(30), category VARCHAR(20), price INT, PRIMARY KEY (name, category)) CREATE TABLE Product ( name CHAR(30), category VARCHAR(20), price INT, PRIMARY KEY (name, category)) NameCategoryPrice GizmoGadget10 CameraPhoto20 GizmoPhoto30 GizmoGadget40

49 Other Keys CREATE TABLE Product ( productID CHAR(10), name CHAR(30), category VARCHAR(20), price INT, PRIMARY KEY (productID), UNIQUE (name, category)) CREATE TABLE Product ( productID CHAR(10), name CHAR(30), category VARCHAR(20), price INT, PRIMARY KEY (productID), UNIQUE (name, category)) There is at most one PRIMARY KEY; there can be many UNIQUE

50 Foreign Key Constraints CREATE TABLE Purchase ( prodName CHAR(30) REFERENCES Product(name), date DATETIME) CREATE TABLE Purchase ( prodName CHAR(30) REFERENCES Product(name), date DATETIME) prodName is a foreign key to Product(name) name must be a key in Product Referential integrity constraints

51 NameCategory Gizmogadget CameraPhoto OneClickPhoto ProdNameStore GizmoWiz CameraRitz CameraWiz ProductPurchase

52 Foreign Key Constraints OR (name, category) must be a PRIMARY KEY CREATE TABLE Purchase ( prodName CHAR(30), category VARCHAR(20), date DATETIME, FOREIGN KEY (prodName, category) REFERENCES Product(name, category) CREATE TABLE Purchase ( prodName CHAR(30), category VARCHAR(20), date DATETIME, FOREIGN KEY (prodName, category) REFERENCES Product(name, category)

53 NameCategory Gizmogadget CameraPhoto OneClickPhoto ProdNameStore GizmoWiz CameraRitz CameraWiz ProductPurchase What happens during updates ? Types of updates: In Purchase: insert/update In Product: delete/update

54 What happens during updates ? SQL has three policies for maintaining referential integrity: Reject violating modifications (default) Cascade: after a delete/update do a delete/update Set-null set foreign-key field to NULL

55 Constraints on Attributes and Tuples Constraints on attributes: NOT NULL-- obvious meaning... CHECK condition-- any condition ! Constraints on tuples CHECK condition

56 CREATE TABLE Purchase ( prodName CHAR(30) CHECK (prodName IN SELECT Product.name FROM Product), date DATETIME NOT NULL) CREATE TABLE Purchase ( prodName CHAR(30) CHECK (prodName IN SELECT Product.name FROM Product), date DATETIME NOT NULL) What is the difference from Foreign-Key ?

57 General Assertions CREATE ASSERTION myAssert CHECK NOT EXISTS( SELECT Product.name FROM Product, Purchase WHERE Product.name = Purchase.prodName GROUP BY Product.name HAVING count(*) > 200) CREATE ASSERTION myAssert CHECK NOT EXISTS( SELECT Product.name FROM Product, Purchase WHERE Product.name = Purchase.prodName GROUP BY Product.name HAVING count(*) > 200)

58 Final Comments on Constraints Can give them names, and alter later We need to understand exactly when they are checked We need to understand exactly what actions are taken if they fail