Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Microsoft SQL Server wikipedia , lookup
Concurrency control wikipedia , lookup
Microsoft Jet Database Engine wikipedia , lookup
Relational algebra wikipedia , lookup
Entity–attribute–value model wikipedia , lookup
Open Database Connectivity wikipedia , lookup
Functional Database Model wikipedia , lookup
Clusterpoint wikipedia , lookup
Database Systems • • • • • • • • Lecture/Workshop: Mon; Wed 10 – 11:30 LIB 1308 Lab: Tue 10-12, ACC, additional help: Thu? Judy Cushing - [email protected] Office Hours: Thursdays 9-10, Lab I, 1003, 867-6652 Class web page: off the SOS web page Assignments due Wednesdays Project Parts due Mondays Lab Aid: Peter Keeler Winter 2006 Cushing Keller Ullman 1–1 Textbooks Required: • Database Systems: The Complete Book, by Garcia-Molina, Ullman, and Widom (first edition), Prentice Hall, 2002. Recommended: (one of these) • SQL in a Nutshell : A Desktop Quick Reference, Kevin E. Kline, Daniel Kline, O’Reilly. • A Guide to the SQL Standard. C. J. Date and H. Darwen, AddisonWesley, 1999. It is more succinct but perhaps a more useful summary, than the Melton-Simon book. • SQL3 Complete, A Guide to the SQL Standard: A User's Guide to the Standard Database Language SQL, (fourth edition), by C.J. Date and Hugh Darwen, Addison-Wesley, 2000. • SQL: 1999 - Understanding Relational Language Components, (first edition), by Melton and Simon, Morgan Kaufmann, 2002. If you are using PostgreSQL: Books on Unix, Perl, PHP, and CGI, PostgreSQL: Introduction and Concepts, Bruce Momjian, AddisonWesley, 2001. This might also be on the web. Winter 2006 Cushing Keller Ullman 1–2 Evaluations I will evaluate you on your ability to design and implement a database application, and on your understanding of database concepts. I will consider: Assignments and in class participation: about 30%. Project: about 35%. Exams: about 35%. Winter 2006 Cushing Keller Ullman 1–3 Project • Build an application using a relational database system (SQL Server or PostgreSQL) accessed via Java and the web. • The project has 8 parts (due Mondays or Thursdays), starting with design and ending with a complete application. • The early programming assignments should be written in SQL, Java. • Some students found it helpful to switch to JavaScript, HTML (PHP or Perl if Postgres) for the web-accessible part. Winter 2006 Cushing Keller Ullman 1–4 Project - tentative schedule 1. 2. 3. 4. 5. 6. 7. 8. Project Part 1 due Jan. 14 (Mon) Choose a project and design an E/R diagram. Project Part 2 due Jan. 24 (TH) Relational design. Project Part 3 due Jan. 31 (TH) Create database in SQLServer. Project Part 4 due Feb. 7 (TH) Queries, updates, and indexes. Project Part 5 due Feb. 21 (TH) Embedded SQL. Project Part 6 due Feb. 28 (TH) Views, constraints, and triggers. Project Part 7 due Mar. 6 (Wed) Entire database application, in Java. Project Part 8 due Mar. 11 (Mon) Database application, accessed via the web. Winter 2006 Cushing Keller Ullman 1–5 Typical Warning (for those taking this class elsewhere) • The database class is a lot of work. • But it is worth it. • Of all courses you take, it may be the one that gets you a job…. We know that SOS gets people jobs, but database expertise does help…. Data is key to many applications…. Winter 2006 Cushing Keller Ullman 1–6 Schedule • Today: Jan. 7 Intro, Entity-Relationship Model. Read Chapter 1 and Sections 2.1, 2.3. • Jan. 9 (W) Weak Entity Sets, Entity-Relationship Design. Read Sections 2.2, 2.4. • Jan. 14 (M) Relational Model, Functional Dependencies. Read Sections 3.1-3.5. Project 1 due. • Jan. 16 (W) Normal Forms, Multivalued Dependencies. Read Sections 3.6-3.7. Assignment 1 due. Winter 2006 Cushing Keller Ullman 1–7 Syllabus • The background and history of database management systems. • The fundamentals of using a database management systems. • Industry standards used for database management systems. • Theoretical background of the relational model. • Queries and Updates. • Logic databases? Constraints and Triggers. • Transactions and Security. • Object-oriented, object-relational, semi-structured and XML database systems. • Mediation and warehousing. Winter 2006 Cushing Keller Ullman 1–8 What is a Database Management System? 1. Manages very large amounts of data. 2. Supports efficient access to very large amounts of data. 3. Supports concurrent access to very large amounts of data. Example: bank and its ATM machines. 4. Supports secure, atomic access to very large amounts of data. Contrast two people editing the same UNIX file – last to write “wins” – with the problem if two people deduct money from the same account via ATM machines at the same time – new balance is wrong whichever writes last. Winter 2006 Cushing Keller Ullman 1–9 Relational Model • Based on tables, as: acct # 12345 34567 … name Sally Sue … balance 1000.21 285.48 … • Today used in most DBMS's. Winter 2006 Cushing Keller Ullman 1–10 The DBMS Marketplace • Relational DBMS companies – Oracle, Sybase – are among the largest software companies in the world. • IBM offers its relational DB2 system. With IMS, a nonrelational system, IBM is by some accounts the largest DBMS vendor in the world. • Microsoft offers SQL-Server, plus Microsoft Access for the cheap DBMS on the desktop, answered by “lite” systems from other competitors. • Relational companies also challenged by “object-oriented DB” companies, and XML data stores. • But countered with “object-relational” systems, which retain the relational core while allowing type extension as in OO systems. Winter 2006 Cushing Keller Ullman 1–11 Three Aspects to Studying DBMS's 1. Modeling and design of databases. Allows exploration of issues before committing to an implementation. 2. Programming: queries and DB operations like update. SQL = “intergalactic dataspeak.” 3. DBMS implementation. Consider DBMS system components, p. 11. Winter 2006 Cushing Keller Ullman 1–12 Query Languages Employee Name Department Dept Dept Manager SQL SELECT Manager FROM Employee, Department WHERE Employee.name = "Clark Kent” AND Employee.Dept = Department.Dept Query Language Data definition language (DDL) ~ like type defs in C or Pascal Data Manipulation Language (DML) Query (SELECT) UPDATE < relation name > SET <attribute> = < new-value> WHERE <condition> Winter 2006 Cushing Keller Ullman 1–13 Host Languages C, C++, Fortran, Lisp, COBOL Application prog. Calls to DB DBMS Local Vars (Memory) (Storage) Host language is completely general (Turing complete) but gives you no support Query language—less general "non procedural" and optimizable Winter 2006 Cushing Keller Ullman 1–14 Relational model is good for: Large amounts of data —> simple operations Navigate among small number of relations Difficult Applications for relational model: • VLSI Design (CAD in general) • CASE • Graphical Data ALU ADDER A FA CPU Adder ALU ADDER Bill of Materials or transitive closure Winter 2006 Cushing Keller Ullman 1–15 Where number of "relations" is large, relationships are complex • Object Data Model • Logic Data Model OBJECT DATA MODEL 1. 2. 3. 4. Complex Objects – Nested Structure (pointers or references) Encapsulation, set of Methods/Access functions Object Identity Inheritance – Defining new classes like old classes Object model: usually find objects via explicit navigation Also query language in some systems Winter 2006 Cushing Keller Ullman 1–16 LOGIC (Horn Clause) DATA MODEL • Prolog, Datalog if A1 and A2 then B prolog B:- A1 and A2 Functions s(5) = 6 (successor) Predicates with Arguments sum(X,Y,Z) X+Y=Z sum(X,0,X) means X + 0 = X (always true for all X) sum(X,s(Y),s(Z)):-sum(X,Y,Z) means X+(Y+1) = (Z+1) if X + Y = Z More power than relational Can Compute Transitive Closure edge(X,Y) path(X,Y) :- edge(X,Y) path(X,Z) :- path(X,Y) & edge(Y,Z) Winter 2006 Cushing Keller Ullman 1–17 60’s Hierarchical Network 70's 80's Choice for most new applications Relational 90’s Object Bases Knowledge Bases now Multi-tiered (web) Architectures Winter 2006 XML Data Transfers and Transformations Cushing Keller Ullman 1–18 Entity/Relationship Model Diagrams to represent designs. • Entity like object = “thing.” • Entity set like class = set of “similar” entities/objects. • Attribute = property of entities in an entity set, similar to fields of a struct. • In diagrams, entity set rectangle; attribute oval. ID name Students Winter 2006 Cushing Keller Ullman phone height 1–19 Relationships • Connect two or more entity sets. • Represented by diamonds. Students Winter 2006 Taking Cushing Keller Ullman Courses 1–20 Relationship Set Think of the “value” of a relationship set as a table. • One column for each of the connected entity sets. • One row for each list of entities, one from each set, that are connected by the relationship. Students Sally Sally Joe … Winter 2006 Courses CS180 CS111 CS180 … Cushing Keller Ullman 1–21 Multiway Relationships Usually binary relationships (connecting two E.S.) suffice. • However, there are some cases where three or more E.S. must be connected by one relationship. • Example: relationship among students, courses, Lab Aids. Student Taking Course Possibly, this E/R diagram is OK: Assisting Lab Aid Winter 2006 Cushing Keller Ullman 1–22 • Works in CS180, because each Lab Aid works for all students. Connection studentLabAid is only via the course. • But what if students were divided into sections, each headed by a LabAid? Then, a student in CS180 would be related to only one of the LabAids for CS180. Which one? • Need a 3-way relationship to tell. Winter 2006 Cushing Keller Ullman 1–23 Course Student Enrolls LabAid Student Ann Sue Bob … Winter 2006 Course CS180 CS180 CS180 … Cushing Keller Ullman LabAid Jan Pat Jan … 1–24 Beers-Bars-Drinkers Example • Our running example for the course. name license Serves Bar Frequents Beer Likes Drinker name Winter 2006 addr manf name Cushing Keller Ullman addr 1–25 Multiplicity of Relationships Many-many Many-one One-one Representation of Many-One • E/R: arrow pointing to “one.” Rounded Winter 2006 arrow = “exactly one.” Cushing Keller Ullman 1–26 Example: Drinkers Have Favorite Beers name Serves addr license Bar Frequents Likes Beer name Winter 2006 manf Drinker Favorite Cushing Keller Ullman name addr 1–27 One-One Relationships Put arrows in both directions. Manufacturer Bestseller Beer Design Issue: Is the rounded arrow justified? Design Issue: Here, manufacturer is an E.S. In earlier diagrams it is an attribute. Which is right? Winter 2006 Cushing Keller Ullman 1–28 Attributes on Relationships price Bar Sells Beer • Shorthand for 3-way relationship: price Price Bar Winter 2006 Sells Cushing Keller Ullman Beer 1–29 • A true 3-way relationship. Price depends jointly on beer and bar. • Notice arrow convention for multiway relationships: “all other E.S. determine one of these.” Not sufficiently general to express any possibility. However, if price, say, depended only on the beer, then we could use two 2-way relationships: price-beer and beer-bar. Or better: just make price an attribute of beer. Winter 2006 Cushing Keller Ullman 1–30 Converting Multiway to 2-Way • Baroque in E/R, but necessary in certain “object-oriented” models. • Create a new connecting E.S. to represent rows of a relationship set. E.g., (Joe's Bar, Bud, $2.50) for the Sells relationship. • Many-one relationships from the connecting E.S. to the others. BBP Winter 2006 TheBar TheBeer ThePrice Bar Beer Price Cushing Keller Ullman 1–31 Roles Sometimes an E.S. participates more than once in a relationship. • Label edges with roles to distinguish. Married husband wife Husband d1 d3 … Wife d2 d4 … Drinker Winter 2006 Cushing Keller Ullman 1–32 Buddies 1 2 Drinker Buddy1 d1 d1 d2 d2 … Buddy2 d2 d3 d1 d4 … • Notice Buddies is symmetric, Married not. No way to say “symmetric” in E/R. Design Question Should we replace husband and wife by one relationship spouse? Winter 2006 Cushing Keller Ullman 1–33 More Design Issues 1. Subclasses. 2. Keys. 3. Weak entity sets. (Next class.) Winter 2006 Cushing Keller Ullman 1–34 Subclasses Subclass = special case = fewer entities = more properties. • Example: Ales are a kind of beer. In addition to the properties (= attributes and relationships) of beers, there is a “color” attribute for ales. Winter 2006 Cushing Keller Ullman 1–35 E/R Subclasses • Assume subclasses form a tree (no multiple inheritance). • isa triangles indicate the subclass relation. name Beer manf isa color Winter 2006 Ale Cushing Keller Ullman 1–36 Different Subclass Viewpoints 1. E/R viewpoint: An entity has a component in each entity set to which it logically belongs. Its properties are the union of the properties of these E.S. 2. Contrasts with object-oriented viewpoint: An object (entity) belongs to exactly one class. It inherits properties of its superclasses. name Beer isa color Winter 2006 Cushing Keller Ullman manf Pete’s Ale Ale 1–37 Multiple Inheritance Theoretically, an E.S. could be a subclass of several other entity sets. name manf name manf Beers Wines isa isa Grape Beers Winter 2006 Cushing Keller Ullman 1–38 Problems How should conflicts be resolved? • Example: manf means vintner for wines, bottler for beers. What does manf mean for “grape beers”? • Need ad-hoc notation to resolve meanings. • In practice, we shall assume a tree of entity sets connected by isa, with all “isas” pointing from child to parent. Winter 2006 Cushing Keller Ullman 1–39 Keys A key is a set of attributes whose values can belong to at most one entity. • In E/R model, every E.S. must have a key. It could have more than one key, but one set of attributes is the “designated” key. • In E/R diagrams, you should underline all attributes of the designated key. Winter 2006 Cushing Keller Ullman 1–40 Example • Suppose name is key for Beers. name Beers manf isa color Ales • Beer name is also key for ales. In Winter 2006 general, key at root is key for all. Cushing Keller Ullman 1–41 Example: A Multiattribute Key number dept hours Courses room • Possibly, the combination of hours + room also forms a key, but we have not designated it as such. Winter 2006 Cushing Keller Ullman 1–42 In Class exercise (if time) or Assignment for Wednesday (for those who did SOS this Fall) Convert the UML for EU-Bid and EU-Lease to an ER diagram. Merge them into a design for one database. Winter 2006 Cushing Keller Ullman 1–43