Database Conceptual and Logical Design Pt. 1 Zachary G. Ives University of Pennsylvania CIS 550 – Database & Information Systems September 23, 2003 Some slide content courtesy of Susan Davidson & Raghu Ramakrishnan

2 Databases Anonymous: A 6-Step Program 1.Requirements Analysis: what data, apps, critical operations 2.Conceptual DB Design: high-level description of data and constraints – typically using ER model 3.Logical DB Design: conversion into a schema 4.Schema Refinement: normalization (eliminating redundancy) 5.Physical DB Design: consider workloads, indexes and clustering of data 6.Application/Security Design

3 Entity-Relationship Diagram (based on our running example) STUDENTS COURSES Takes name sid serno subj PROFESSORS Teaches cid fid name entity set relationship set exp-grade attributes (recall these have domains) Underlined attributes are keys semester

4 Conceptual Design Process  What are the entities being represented?  What are the relationships?  What info (attributes) do we store about each?  What keys & integrity constraints do we have? name STUDENTS Takes sid exp-grade

5 Translating Entity Sets to Logical Schemas & SQL DDL CREATE TABLE STUDENTS (sid INTEGER, name VARCHAR(15) PRIMARY KEY (sid) ) CREATE TABLE COURSES (serno INTEGER, subj VARCHAR(30), cid CHAR(15), PRIMARY KEY (serno) ) Fairly straightforward to generate a schema…

6 Translating Relationship Sets Generate schema with attributes consisting of:  Key(s) of each associated entity (foreign keys)  Descriptive attributes CREATE TABLE Takes (sid INTEGER, serno INTEGER, exp-grade CHAR(1), PRIMARY KEY (?), FOREIGN KEY (serno) REFERENCES COURSES, FOREIGN KEY (sid) REFERENCES STUDENTS)

7 … OK, But What about Connectivity in the E-R Diagram?  Attributes can only be connected to entities or relationships  Entities can only be connected via relationships  As for the edges, let’s consider kinds of relationships and integrity constraints… COURSES PROFESSORS Teaches (warning: the book has a slightly different notation here!)

8 Logical Schema Design  Roughly speaking, each entity set or relationship set becomes a table (not always be the case; see Thursday)  Attributes associated with each entity set or relationship set become attributes of the relation; the key is also copied (ditto with foreign keys in a relationship set)

9 Binary Relationships & Participation  Binary relationships can be classified as 1:1, 1:Many, or Many:Many, as in: 1:1 1:n m:n

10 1:Many (1:n) Relationships  Placing an arrow in the many  one direction, i.e. towards the entity that’s ref’d via a foreign key  Suppose profs teach multiple courses, but may not have taught yet:  Suppose profs must teach to be on the roster: COURSES PROFESSORS Teaches COURSES PROFESSORS Teaches Partial participation (0 or more…) Total participation (1 or more…)

11 Many-to-Many Relationships  Many-to-many relationships have no arrows on edges  The “relationship set” relation has a key that includes the foreign keys, plus any other attributes specified as key STUDENTS COURSES Takes

12 Examples  Suppose courses must be taught to be on the roster  Suppose students must have enrolled in at least one course

13 Representing 1:n Relationships in Tables CREATE TABLE Teaches( fid INTEGER, serno CHAR(15), semester CHAR(4), PRIMARY KEY (serno), FOREIGN KEY (fid) REFERENCES PROFESSORS, FOREIGN KEY (serno) REFERENCES Teaches) CREATE TABLE Teaches_Course( sernoINTEGER, subj VARCHAR(30), cid CHAR(15), fid CHAR(15), when CHAR(4), PRIMARY KEY (serno), FOREIGN KEY (fid) REFERENCES PROFESSORS) Key of relationship set: Or embed relationship in “many” entity set:

14 1:1 Relationships If you borrow money or have credit, you might get: What are the table options? CreditReport Borrower delinquent? ssn name debt Describes rid

15 Roles: Labeled Edges Sometimes a relationship connects the same entity, and the entity has more than one role: This often indicates the need for recursive queries name qty Parts id AssemblySubpart Includes

16 DDL for Role Example CREATE TABLE Parts (Id INTEGER, Name CHAR(15), … PRIMARY KEY (ID) ) CREATE TABLE Includes (Assembly INTEGER, Subpart INTEGER, Qty INTEGER, PRIMARY KEY (Assemb, Sub), FOREIGN KEY (Assemb) REFERENCES Parts, FOREIGN KEY (Sub) REFERENCES Parts)

17 Married Roles vs. Separate Entities HusbandWife id HusbandWife name What is the difference between these two representations? Married Person id name

18 ISA Relationships: Subclassing (Structurally)  Inheritance states that one entity is a “special kind” of another entity: “subclass” should be member of “base class” name ISA People id Employees salary

19 But How Does this Translate into the Relational Model? Compare these options:  Two tables, disjoint tuples  Two tables, disjoint attributes  One table with NULLs  Object-relational databases

20 Weak Entities A weak entity can only be identified uniquely using the primary key of another (owner) entity.  Owner and weak entity sets in a one-to-many relationship set, 1 owner : many weak entities  Weak entity set must have total participation People Feeds Pets ssn name weeklyCost name species

21 Translating Weak Entity Sets Weak entity set and identifying relationship set are translated into a single table; when the owner entity is deleted, all owned weak entities must also be deleted CREATE TABLE Feed_Pets ( name VARCHAR(20), species INTEGER, weeklyCost REAL, ssn CHAR(11) NOT NULL, PRIMARY KEY (pname, ssn), FOREIGN KEY (ssn) REFERENCES Employees, ON DELETE CASCADE)

22 N-ary Relationships  Relationship sets can relate an arbitrary number of entity sets: StudentProject Advisor Indep Study

23 Summary of ER Diagrams  One of the primary ways of designing logical schemas  CASE tools exist built around ER (e.g. ERWin, PowerBuilder, etc.)  Translate the design automatically into DDL, XML, UML, etc.  Use a slightly different notation that is better suited to graphical displays  Some tools support constraints beyond what ER diagrams can capture  Can you get different ER diagrams from the same data?

24 Schema Refinement & Design Theory  ER Diagrams give us a start in logical schema design  Sometimes need to refine our designs further  There’s a system and theory for this  Focus is on redundancy of data  Let’s briefly touch on one key concept in preparation for Thursday’s lecture on normalization…

25 Not All Designs are Equally Good Why is this a poor schema design? And why is this one better? Stuff(sid, name, cid, subj, grade) Student(sid, name) Course(cid, subj) Takes(sid, cid, exp-grade)

26 Focus on the Bad Design  Certain items (e.g., name) get repeated  Some information requires that a student be enrolled (e.g., courses) due to the key sidnamecidsubjexp-grade 1Sam570AIB 23Nitin550DBA 45Jill505OSA 1Sam505OSC

27 Functional Dependencies Describe “Key-Like” Relationships A key is a set of attributes where: If keys match, then the tuples match A functional dependency (FD) is a generalization: If an attribute set determines another, written A ! B then if two tuples agree on A, they must agree on B: sid ! Address What other FDs are there in this data?  FDs are independent of our schema design choice

28 Formal Definition of FD’s Def. Given a relation scheme R (a set of attributes) and subsets X,Y of R: An instance r of R satisfies FD X  Y if, for any two tuples t1, t2 2 r, t1[X ] = t2[X ] implies t1[Y] = t2[Y]  For an FD to hold for scheme R, it must hold for every possible instance of r  (Can a DBMS verify this? Can we determine this by looking at an instance?)

29 General Thoughts on Good Schemas We want all attributes in every tuple to be determined by the tuple’s key attributes What does this say about redundancy? But:  What about tuples that don’t have keys (other than the entire value)?  What about the fact that every attribute determines itself?  Stay tuned for Thursday!

30 Reminders  Homework 2 will be due Thursday  See the newsgroup for instructions on how to get around the problems with Oracle being out of extent space…