Database Management Systems CSE 590DB

1
Database Management SystemsCSE 590DB

• Introduction
• March 30, 1998

2
Staff

• Instructor Alon Levy
• Sieg, Room 310, alon_at_cs.washington.edu
• Office hours by appointment
• TA Rachel Pottinger
• Sieg 223, rap_at_cs.washington.edu
• Office hours TBA
• Mailing list cse590db_at_cs
• Web page http//www.cs.washington.edu/education/c
  ourses/590db/98sp/

3
Purpose and Format

• Purpose
• Foundations of database management systems.
• Introduction to current research issues in
  databases.
• Format
• Lectures introducing the main topics
• Student presentations of selected research
  papers.
• Projects (for 3-credit takers)

4
Textbooks (none required)

• Database Management Systems (Ramakrishnan)
• Foundations of Databases (Abiteboul, Hull
  Vianu)
• Fundamentals of Database Systems (Elmasri and
  Navathe)
• Database Systems (Silberschatz, Korth and
  Sudarshan)
• Data and Knowledge based Systems (volumes I, II)
  (Ullman)
• Readings in Database Systems (Stonbraker)
• Proceedings of SIGMOD, VLDB, PODS confrences.

5
Prerequisites
6
Real Prerequisites

• Operating systems
• Data structures and algorithms
• Distributed systems
• Complexity theory
• Mathematical Logic
• Knowledge Representation

• User interface design
• Programming languages
• Artificial Intelligence (Search)
• Greek, Hebrew, French

7
Why Use a DBMS?
All programs manipulate data, so why use a
database?

• Large amounts of data (Gigas)
• Data is very structured
• Persistent data
• Valuable data
• Performance requirements
• Concurrent access to the data
• Restricted access to data

8
Functionality of a DBMS

• Persistent storage management
• Multiple abstraction levels of the data (in
  particular, provides a logical view).
• High level query and data manipulation language
• Efficient query processing
• Transaction management
• Resiliency recovery from crashes.
• Interface with programming languages

9
Persistent Storage

• Becomes a hard problem because of the interaction
  with the other levels of the DBMS
• What are we storing?
• Efficient indexing
• Special issues due to resiliency requirements
• Exploit semantic knowledge
• Issue interaction with the operating system.
  Should we rely on the OS?

10
Levels of Abstraction
External Schema1
External Schema 2

• Conceptual schema tables and their
• attributes
• Physical schema files, indexes
• hash tables.
• External schema views of the different
• applications, classes of users.

Conceptual Schema
Physical Schema
System catalog la The component of the database
that manages the meta data about the different
levels of abstraction.
Disk
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

• What data model should we use?
• Relational, object-oriented, object-relational,
  deductive database model, semi-structured
• How do we design a good conceptual schema?
  (normal forms, index selection)
• Are we really providing an abstraction?
• How does this abstraction interact with the
  programming language? (the impedance mismatch).

13
Querying a Database

• Find all the students who have taken CSE444 in
  Winter, 1998.
• S(tructured) Q(uery) L(anguage)
• select E.name
• from Enroll E
• where E.courseCSE444 and
• E.quarterWinter, 1998
• SQL also provides an update facilities.
• SQL an acquired taste (try datalog first)

14
Issues in Query Languages

• Does it provide the appropriate functionality?
• SQL books get thicker and thicker.
• Expressive power of a query language.
• Ease of use (query by example)
• Declarativity
• Provide guidance in writing good queries?

15
Query Optimization

• A query is a declarative specification of what
  you want.
• A query execution plan is an imperative program
  to produce the answer.
• Query optimization produce an efficient query
  execution plan.
• Issues large search space of plans, cost
  estimation, semantic transformations
• Real goal avoid the bad plans.

16
Transaction Processing and Recovery

• For efficient use of resources, we want
  concurrent access to data.
• Systems sometimes crash.
• A real database guarantees ACID
• Atomicity all or nothing of a transaction.
• Consistency always leave the DB consistent.
• Isolation every transaction runs as if its the
  only one in the system.
• Durability if committed, then we really mean it.

17
Database Industry

• Relational databases are a great success of
  theoretical ideas.
• Big 3 DBMS companies are among the largest
  software companies in the world.
• IBM (with DB2) and Microsoft (SQL Server,
  Microsoft Access) are also important players.
• 20B industry
• Moving to warehousing, decision support.

18
Why Use a DBMS?

• Data independence and efficient access.
• Reduced application development time.
• Data integrity and security.
• Uniform data administration
• Concurrent access and recovery from crashes.

19
DBMS Development

• Issues in scaleup
• Indexing and storing large amounts of data.
• Algorithms sorting, joins
• Novel issues
• Modeling data (models, constraints, schema
  design).
• Query languages
• Optimization from a declarative specification to
  an efficient program.

20
Course (Rough) Outline

• Data models and their associated query languages
• Relational SQL, datalog, relational algebra
• Object-oriented OQL
• Object-relational novel features in SQL3.
• Semi-structured languages for querying graphs.
• Storage (very briefly)
• Query optimization foundations and current
  limitations.

21
Outline (continued)

• Semantic analysis query containment, using
  views.
• Decision support, data warehousing data
  warehouse design, maintainability issues.
• Data integration querying heterogeneous sources
  in a uniform fashion.
• Data mining
• SIGMOD/PODS