CS 325 Spring ‘09 Chapter 1 Goals: * database mindset (why is this important?) * jump into the terminology * introduce ideas that come later Read sections 1.1-1.13 Problems: 1.1, 1.2, 1.4, 1.5, 1.6, 1.7.

Database Management System (DBMS) Information about a particular enterprise Two components: Data Programs to access the data Goal: convenient and efficient Give an example of information that is interesting/useful to you What is the information? Is there an organization to it? What do you want to do with it? How could you use C++ to do this? What problems are associated with using this information effectively?

Purpose of a DBMS To handle problems of typical file-processing systems Data redundancy and inconsistency Difficulty in accessing data Data isolation — multiple files and formats Integrity — e.g. assuring that age ≥ 0 Concurrent access by multiple users Atomicity of updates — funds transfer from one account to another should be complete or not happen at all Security

Database System Architecture

Levels of Abstraction Physical level: how data is stored Logical level: What data is stored in database Relationships among the data (later) View level: Different users need different information; e.g. the system might hide salary information from some users Users do not need to know implementation details Analogy with C++: Physical: a list of 10 elements starts in location 1000 and each element takes 2 bytes; a record is stored .... Logical: int numbers[10]; struct{ } View: a menu-driven program How do C++ classes fit here?

Instances and Schemas Schema Instance The structure of the database; e.g., logical: customers and accounts and their relationship physical: how a customer record is stored in the database Instance The content of the database at a particular point in time (e.g. the particular customers and their accounts) Similar to types and variables in C++

Data Independence Ability to modify a schema definition in a level without affecting a schema definition in the next higher level Two levels of data independence Physical ability to modify the physical schema without rewriting logical schema or applications a database stores information differently on a Mac than on a PC Logical ability to modify the logical schema without rewriting applications one might want to add a field to a customer record Analogy: C++ classes Implementation (xx.cpp) can change without altering specification (xx.h) Both can be used in different applications and on different compilers

Data Models A collection of tools for describing data relationships data semantics data constraints Entity-relationship model Relational model Other models: Object-oriented Older: network model hierarchical model Emphasis on mathematical models has made the field less ad hoc

Entity-Relationship (ER) Model Example schema: Entities: customer, account Relationship: depositor Attributes: customer-id, customer-name, customer-street, customer-city, account-number, balance

Tabular Data in the Relational Model Attributes customer- name customer- street customer- city account- number Customer-id 192-83-7465 019-28-3746 321-12-3123 Johnson Smith Jones Alma North Main Palo Alto Rye Harrison A-101 A-215 A-201 A-217 customer entity set

Database Languages Database Definition Language (DDL) Notation for defining the database schema; e.g. create table account ( account-number char(10), balance integer) DDL compiler generates a set of tables stored in a data dictionary Data dictionary contains metadata (data about data) Data Manipulation Language (DML) For accessing and manipulating the data Two types: procedural – specifies what data is required and how to get it nonprocedural – describes the data but not how to get it Most widely used for both: SQL (nonprocedural) select account-number from account

Beyond the Relational Model The relational model used to be the gold standard Emerging models: Object-based Semistructured Extends ER with encapsulation, inheritance, information hiding, structured types... Allows an object to have different structures (an address structure might differ, based on country) Data is often packaged in XML

Overall System Structure

Application Architectures Two-tier architecture: E.g. client programs using ODBC/JDBC to communicate with a database Three-tier architecture: E.g. web-based applications, and applications built using “middleware”

Database Administrator versus User Database administrator duties: Schema definition Storage structure and access method definition Schema and physical organization modification Granting user authority to access the database Specifying integrity constraints Acting as liaison with users Monitoring performance Responding to changes in requirements Database users Application programmers – interact through DML calls Sophisticated users – requests in a query language Naïve users – invoke an application that someone else wrote

Some History First computers built for calculation. ENIAC at U Penn, 1946. http://www.library.upenn.edu/special/gallery/mauchly/jwm0-1.html Late 50's: Alphanumeric information began to be stored Business showed interest COBOL designed to handle large files for business applications File processing on sequential files (CS 131) 60's, 70's: Commercially available DBMS as opposed to programs written from scratch 70's, 80's: Relational model: a mathematical foundation, conceptually appealing; originally inefficient. Commercial DBMSs available on microcomputers Late 90's: web interfaces Today: DBMS integrated with most enterprises