DBS 2006: 1 st week. DBS 2006: Plan. DB Life-Cycle: Requirement analysis. Data modelling: Conceptual Design. Logical Schema Design

Size: px

Start display at page:

Download "DBS 2006: 1 st week. DBS 2006: Plan. DB Life-Cycle: Requirement analysis. Data modelling: Conceptual Design. Logical Schema Design"

Noah McDaniel
6 years ago
Views:

1 DBS 006: Plan DBS 006: 1 st week DB Life-Cycle: Data modelling: 1 systematic design of DB 3-3 weeks Physical Schema Design Database usage: access to the stored data using SQL interactively or via application program -3 weeks Database system implementation 6 weeks 5 4 Maintenance and Administration Physical Schema Design Administration Requirement Analysis : Problem analysis Conceptual Database Design Entity, attribute, relationship Integrity constraints Weak entities Temporal data Generalization 1 1

2 Example DBS 006: nd week [ ] We have [ ] video tapes that we need to keep track of. Since a few weeks, we also have DVDs. Each of our video tapes has a tape number. For each movie, we need to know its title and category, director and year. We do have multiple copies of many of our movies. We give each movie a specific id, and then track which movie a tape contains. A tape may be either Beta or VHS Format. We always have at least one tape for each movie we track, and each tape is always a copy of a single, specific movie. Our tapes are adapted to the movie lengths, so we don t have any movies which require multiple tapes. The movies are stored on shelf according to their category sorted by movie title. We are frequently asked for movies starring specific actors. [ ] Customers like to know each actor s real birth name and age. We track only actors who appear in the movies in our inventory. [ ] Rentals are for one or more days, each movie with an individual price per day. Furthermore we additionally charge 1 $ per beta format tape, $ for a DVD and another $ for movies longer than hours. [abbreviated] DB Life-Cycle: : Physical Schema Design Administration Relational data model Principles for mapping entities and relationships to relations 3 4

3 Example 1 Example Design the ER diagrams. Mark the keys and the cardinalities (min-max notation). Design the ER diagrams. Mark the keys and the cardinalities (min-max notation). a) Exhibitions are organised by museums. Each exhibition is organized by one museum and features one or more artists. A museum has a name and an address; exhibitions have a unique title, a start and an end date. For the artists, we store names and addresses. b) Exhibitions are shown in several museums, even in the same museum (again) at different times. For each showing, the start and an end date are recorded. Each exhibition features one or more artists. A museum has a name and an address; exhibitions have a title. For the artists, we store names and addresses. a) Employees work in departments. For the employees, we have to store the unique social security number, name, and income. Each department has its own building (and a unique address). Departments have numbers and a maximal number of employees. For each employee, we store the information about when they commenced working in the department. b) Employees work in departments. Each department has is spread over several buildings. Each building a unique address. For each employee, we store the building they are working in. Departments have numbers and a maximal number of employees per building

4 Example 3 Example 3 possible ER-Design This is a database about actors. For each actor, we store their name and address. Actors star in movies. For the movies we store the title, the year, the length, and the producing studio s name. Movies are produced in studios; for the studios we store the name and address. Actors are employed by one studio at a time. This studio does not have to be the studio that producers the movie the actors stars in. Each studio is owned by one or more actors. They own the studio since a given (first) purchase date, which does not have to be the same for all owners. Each studio is managed by a business manager. They are not actors. Each studio may have had several business managers over the years. In the database, the start and end date of each business managers employment is kept. qualification stagename (0,*) (1,*) own purchase date Manager Actor (1,*) play (0,*) Movie (1,1) produce (1,*) Studio (1,*) length year title SID Employee name birthday (1,1) pay (1,*) has (1,1) Employment startdate enddate 7 8 4

5 Example DBS006: 8th week charge Format director category year id Application & Database Design: name (0,*) title Price_per_day belong_to length id (1,1) Tape (1,1) (1,*) hold Movie (0,*) is_in (0,*) Application Design Phys. Schema Design from (1,1) Rental until Address First_name Last_name have Telephone Mem_no (1,1) (0,*) Customer play (1,*) Actor birthday stage_name real_name 9 Relational Algebra Union, Difference Selection, Projection Cartesian Product Joins Operator tree 10 5

6 Video Example Video Example Video DB Schema: Video DB Schema (part): Movie(id, title, category, year, director, price_per_day, length) Tape(id, format, movie_id) Format(name, charge) Movie(id, title, category, year, director, price_per_day, length) Tape(id, format, movie_id) Format(name, charge) Actor(stage_name, real_name, birthday) Actor(stage_name, real_name, birthday) Play(movie_id, actor_name) Play(movie_id, actor_name) Queries: Customer(mem_no, last_name, first_name, address, telephone) Rental(tape_id, member, from, until) 1. List of all DVDs (Tapes). Id and titel of all movies that are available on DVD 3. List of Actors of which movies are available on DVD 4. Movies that are available in all formats 5. Movies of which are at least two starring actors in the DB

7 Inhalt Mi, Applikation & Database Design: DBS 006: 4 th week Application & Database Design: Application Design Phys. Schema Design Application Design Phys. Schema Design Relationales Kalkül Tuple Kalkül Domain Kalkül Sichere Ausdrücke Equivalenz relationer Sprachen (DBMS specific): SQL as data definition language Definition of relations using SQL Definition of constraints

8 DBS 006: 5 th week Application & Database Design: Example: CREATE TABLE Movie ( id INTEGER PRIMARY KEY, title VARCHAR(60) NOT NULL, category CHAR(10), year DATE, director VARCHAR(30), pricepday DECIMAL(4,), length INTEGER, CONSTRAINT plausible_year CHECK ( ), CONSTRAINT allowedprice CHECK ( ) ); Application Design Phys. Schema Design SQL as DML: SQL-query structure Simple SQL queries Queries using Joins Nested queries CREATE TABLE Tape( id INTEGER PRIMARY KEY, format CHAR(5) NOT NULL, movie_id INTEGER NOT NULL, CONSTRAINT tapenotempty FOREIGN KEY (movie_id) REFERENCES Movie(id) ON DELETE CASCADE, CONSTRAINT formatcheck FOREIGN KEY (format) REFERENCES Format(name) ON DELETE SET NULL );

9 Example: Example: CREATE TABLE Format( Name CHAR(5) primary key, Charge DECIMAL (3,) ); CREATE TABLE Actor ( stage_name VARCHAR(30)NOT NULL UNIQUE, real_name VARCHAR(30), birthday DATE ); CREATE TABLE Customer ( mem_no INTEGER PRIMARY KEY, last_name VARCHAR (30) NOT NULL, first_name VARCHAR(0), address VARCHAR (60), telephone VARCHAR (15) ); CREATE TABLE Play ( movie_id INTEGER, actor_name VARCHAR(30), CONSTRAINT pkstarr PRIMARY KEY (movie_id, actor_name), CONSTRAINT foreignkeymovieid FOREIGN KEY (movie_id) REFERENCES Movie (id), CONSTRAINT foreignkeystagename FOREIGN KEY (actor_name) REFERENCES Actor(stage_name) ); CREATE TABLE Rental( tape_id INTEGER, mem_no INTEGER, from_date DATE NOT NULL, until_date DATE, PRIMARY KEY (tape_id, mem_no, from_date), CONSTRAINT fk_tape FOREIGN KEY (tape_id) REFERENCES Tape(id), CONSTRAINT fk_customer FOREIGN KEY (mem_no) REFERENCES Customer(mem_no) );

10 Example Video DB Schema : Inhalt Fr, Applikation & Database Design: Movie(id, title, category, year, director, pricepday, length) Tape(id, format, movie_id) Format(name, charge) Actor(stage_name, real_name, birthday) Play(movie_id, actor_name) Queries: Application Design Phys. Schema Design 1. Liste aller DVDs (Tapes). Id und Titel aller Filme, die auf DVD vorliegen 3. Schauspieler von denen Filme auf DVD vorliegen 4. Filme, die in allen Formaten vorliegen 5. Filme, zu denen mindestens Schauspieler in der DB sind SQL als DML: Anfragen mit Joins Geschachtelte Anfragen

11 DBS 006: 6 th week Application & Database Design: Example Video DB Schema: Application Design Phys. Schema Design Movie(id, title, category, year, director, pricepday, length) Tape(id, format, movie_id) Format(name, charge) Actor(stage_name, real_name, birthday) Play(movie_id, actor_name) More Queries: SQL as DML: Nested queries Aggregate functions Grouping Transitive closure 6. Movies for which there are 3 actors in the DB 7. Movies that have the most actors in the DB 8. Overall Charge of all the tapes in the DB Without extra charge With extra charge Views and temporary tables 1 11

12 Example Video DB Schema: DBS 006: 7 th week Application & Database Design: Movie(id, title, category, year, director, pricepday, length) Tape(id, format, movie_id) Format(name, charge) Actor(stage_name, real_name, birthday) Play(movie_id, actor_name) More Queries: Application Design Phys. Schema Design 9. Average number of movies per actor 10. Number of movies per actor 11. List of actors with more than the average number of movies Prerequisites for DB access with SQL System aspects of SQL SQL environment Access control 3 4 1

13 DBS 006: 7 th week Application & Database Design: DBS 006: 7 th week Application & Database Design: Application Design Phys. Schema Design Application Design Phys. Schema Design SQL in Programs Module Embedded SQL Cursor-Concept SQL in Programs SQL und Java SQLJ JDBC Introduction Transactions

14 DBS 006: 8 th week Example: Application & Database Design: Find all functional dependencies: From application semantics: Customer (C-Nr, company, ZIP, City, Street, no) Salesperson (Name, city, ZIP, firstname, sales) Application Design Phys. Schema Design From representative data: R Design Quality: Functional Dependencies A B 3 C Super keys? Candidate keys? D 3 5 E

15 Example: R(A,B,C,D,E) F:{C B C D D B E ABCD C BD D BC CD B CB D} (1) () (3) (4) (5) (6) (7) (8) Armstrong Axioms: Reflexivity rule: If Y X then X Y Augmentation rule: If X Y and set of attributes Z then X Z Y Z Transitivity rule: If X Y and Y Z then X Z Find closure of attributes A, B, C,... AB, BC,... ABC, ABCD Candidate keys? Super keys?

16 Example: R(A,B,C,D,E) F:{C B C D D B E ABCD C BD D BC CD B CB D} (1) () (3) (4) (5) (6) (7) (8) DBS 006 Application & Database Design: Application Design Phys. Schema Design Find transitive closure Find minimal cover Design Quality: Functional dependencies Transitive closure Minimal cover Normal forms Lossless join

17 Example: Example: Determine normal form Re-arrange tables using Synthesis R(A,B,C,D,E) Decomposition Min F:{C BD D C E AC} R(A,B,C,D,E) S(A,B,C,D,E) Min F:{C BD D C E AC} Min F:{AB CDE CD A E AB} S(A,B,C,D,E) Min F:{AB CDE CD A E AB}

18 Normal forms: First normal form (1NF) Basic property of relation All attributes have atomic domain DBS: weekly plan Application & Database Design: Second normal form (NF) non-key A R candidate keys X R : X {A} Third normal form (3NF) 1. A X, i.e. trivial FD. A candidate key 3. X superkey in R BCNF 1. A X, i.e. trivial FD. X superkey in R Application Design Phys. Schema Design Physical Schema Design: Storage Structures Disk Properties Disk Access DB Block Structure

19 DBS: this week and next Example Application & Database Design: Consider table course Application Design Phys. Schema Design - course(title, number, room, lecturer) - with n tuples - Structure: - char(0), - integer (= 4 Bytes), - integer, - char(0) - Assumption: - fits completely into main memory Physical Schema Design: Tree-based Indexes: ISAM B+ Tree B+ Tree with data leaves - Parameter: - Information flow: 5 MB/s - Block size 4 KB - PCTFREE=30% - Ignore block header size - Average access time main memory: 10ns Estimate the time to load the table

20 Example Estimate Number of Blocks B: - Tuple size: = 48 Bytes - Data per block: 4*104Bytes * 0,7 867 Bytes - Numver of tuples per block: Bytes / 48 Bytes 59 - # Blocks B: n/59 B n Example B+ Tree Insert Search Key 60: Estimate time to load table - Transfer time: T/if B * 4 * 104 Bytes / 5 * 104 * 104 Bytes*s -1 = 0.16 * B / 104 msec 0.16 * B ms - Worst case: 0.16 *n m - Best case: 0.16 *n/59 m * n ms - Average Access time to disk Seek time + Rotation time + T/if - Worst case: 6ms+3ms *n ms - Best case: 6ms+3ms *n ms Example: 1000 tuples - Worst case: 6ms+3ms+160 ms = 169ms - Best case: 6ms+3ms+3ms = 1ms

21 Example B+ Tree 41 Example B+ Tree 4 1 Insert Search Keys 10, 105, 30, 340, 400, 401: Delete 60:

22 DBS weekly plan Application & Database Design: Example Create an extensible Hash-Index: H(K)= k mod 11 Bucket size 4 Data keys: - Insert 1 - Insert 55 Application Design Phys. Schema Design Physical Schema Design: Simple and extensible Hash Bitmap Index Function-based Index - Insert 69 - Insert 7 - Insert 18 - Insert Insert Insert 4 - Delete 7 - Delete 55 Cluster (Table und Index) 43 44

23 DBS weekly plan Application & Database Design: DBS weekly plan Database management: Database System User / Programmer Application program Software to process queries Software to access stored data DBMS Software Application Design Phys. Schema Design Physical Schema Design: Query processing Query optimization Stored Data Stored DB definition (Meta-data) Database Transactions- Concurrency: Serializability theory Locking mechanisms Deadlock: wait-for-graph, timeout Timestamps

24 Example Example Test the following schedules for conflict-serializability Create the schedule of a strict PL (-phase-locking) scheduler for Give an equivalent serial schedule (if exists) 1. r1(a), w1(a), r(a), w(a), r1(b), w1(b), r(b), w(b), c,c1. r1(a), w1(a), r(a), w(a), r(b), w(b), c, r1(b), w1(b), c1 3. T1: R(X), T:W(X), T1:W(X), T: Commit, T1: Commit 4. r1(x), r1(y), w1(x), r(y), w3(y), w1(x), r(y), c1, c, c3 S: r1[y], r3[u], r[u], w1[y], w[x], w1[x], w[z], w3[x], c1, c, c

25 Example Create the schedule of a strict PL (-phase-locking) scheduler Show waiting-graph (wait-for-graph) Show deadlock resolving using wait/die wound/wait S: r1[y], r3[u], w[x], r[u], w1[y], w1[x], w[z], w3[x], c1, c, c3 49 5

Requirement Analysis & Conceptual Database Design

Requirement Analysis & Conceptual Database Design Problem analysis Entity Relationship notation Integrity constraints Generalization Introduction: Lifecycle Requirement analysis Conceptual Design Logical