1. Database Management Systems CSE 590DB Introduction March 30, 1998

2. Staff zInstructor: Alon Levy ySieg, Room 310, alon@cs.washington.edu yOffice hours: by appointment zTA: Rachel Pottinger ySieg 223, rap@cs.washington.edu yOffice hours: TBA zMailing list: cse590db@cs zWeb page: http://www.cs.washington.edu/education/courses/590db/98sp/

3. Purpose and Format zPurpose: yFoundations of database management systems. yIntroduction to current research issues in databases. zFormat: yLectures introducing the main topics yStudent presentations of selected research papers. yProjects (for 3-credit takers)

4. Textbooks (none required) zDatabase Management Systems (Ramakrishnan) zFoundations of Databases (Abiteboul, Hull & Vianu) zFundamentals of Database Systems (Elmasri and Navathe) zDatabase Systems (Silberschatz, Korth and Sudarshan) zData and Knowledge based Systems (volumes I, II) (Ullman) zReadings in Database Systems (Stonbraker) zProceedings of SIGMOD, VLDB, PODS confrences.

5. Prerequisites

6. Real Prerequisites zOperating systems zData structures and algorithms zDistributed systems zComplexity theory zMathematical Logic zKnowledge Representation z User interface design z Programming languages z Artificial Intelligence (Search) z Greek, Hebrew, French

7. Why Use a DBMS? Large amounts of data (Giga’s) Data is very structured Persistent data Valuable data Performance requirements Concurrent access to the data Restricted access to data All programs manipulate data, so why use a database?

8. Functionality of a DBMS zPersistent storage management zMultiple abstraction levels of the data (in particular, provides a logical view). zHigh level query and data manipulation language zEfficient query processing zTransaction management zResiliency: recovery from crashes. zInterface with programming languages

9. Persistent Storage zBecomes a hard problem because of the interaction with the other levels of the DBMS: yWhat are we storing? yEfficient indexing ySpecial issues due to resiliency requirements yExploit “semantic” knowledge zIssue: interaction with the operating system. Should we rely on the OS?

10. Levels of Abstraction External Schema1External Schema 2 Conceptual Schema Physical Schema Disk Conceptual schema: tables and their attributes Physical schema: files, indexes hash tables. External schema: views of the different applications, classes of users. System catalog: la The component of the database that manages the meta data about the different levels of abstraction.

11. The Relational Model Data is organized into tables with attributes. Rows in the tables are tuples. The power of simplicity!

12. Logical Model Issues zWhat data model should we use? yRelational, object-oriented, object-relational, deductive database model, semi-structured zHow do we design a good conceptual schema? (normal forms, index selection) zAre we really providing an abstraction? zHow does this abstraction interact with the programming language? (the impedance mismatch).

13. Querying a Database zFind all the students who have taken CSE444 in Winter, 1998. zS(tructured) Q(uery) L(anguage) yselect E.name yfrom Enroll E ywhere E.course=CSE444 and y E.quarter=“Winter, 1998” zSQL also provides an update facilities. zSQL: an acquired taste (try datalog first)

14. Issues in Query Languages zDoes it provide the appropriate functionality? ySQL books get thicker and thicker. zExpressive power of a query language. zEase of use (query by example) zDeclarativity zProvide guidance in writing “good” queries?

15. Query Optimization zA query is a declarative specification of “what” you want. zA query execution plan is an imperative program to produce the answer. zQuery optimization: produce an efficient query execution plan. zIssues: large search space of plans, cost estimation, semantic transformations zReal goal: avoid the bad plans.

16. Transaction Processing and Recovery zFor efficient use of resources, we want concurrent access to data. zSystems sometimes crash. ACID zA “real” database guarantees ACID: yAtomicity: all or nothing of a transaction. yConsistency: always leave the DB consistent. yIsolation: every transaction runs as if it’s the only one in the system. yDurability: if committed, then we really mean it.

17. Database Industry zRelational databases are a great success of theoretical ideas. z“Big 3” DBMS companies are among the largest software companies in the world. zIBM (with DB2) and Microsoft (SQL Server, Microsoft Access) are also important players. z$20B industry zMoving to warehousing, decision support.

18. Why Use a DBMS? zData independence and efficient access. zReduced application development time. zData integrity and security. zUniform data administration zConcurrent access and recovery from crashes.

19. DBMS Development zIssues in scaleup: yIndexing and storing large amounts of data. yAlgorithms: sorting, joins z“Novel” issues: yModeling data (models, constraints, schema design). yQuery languages yOptimization: from a declarative specification to an efficient program.

20. Course (Rough) Outline zData models and their associated query languages: yRelational: SQL, datalog, relational algebra yObject-oriented: OQL yObject-relational: novel features in SQL3. ySemi-structured: languages for querying graphs. zStorage (very briefly) zQuery optimization: foundations and current limitations.

21. Outline (continued) zSemantic analysis: query containment, using views. zDecision support, data warehousing: data warehouse design, maintainability issues. zData integration: querying heterogeneous sources in a uniform fashion. zData mining zSIGMOD/PODS