Class Information. Textbooks. Grading. Final Project. Grading. CS 440: Database Management Systems. Instructor:

Transcription

1 CS 440: Database Management Systems Class Information Instructor: Eugene Zhang 2 KEC Office hour: MWF 4:00 5:00 Class web site: Textbooks Grading Required Optional Homework 3x0=30 Midterm 30 Final project Final Project Grading A group of two students Project idea needs to be agreed upon between the students and the instructor otes: Late assignments Grading problems: please report within one week after the homework has been received.

2 Learning Objectives Learning Objectives Collect, analyze, and decompose system requirements. Create a data model diagram for a complex, realistic database system. Use advanced database tools such as application generators and form generators. Apply methods and tools for web-based database applications. Use advanced features of query languages. Design, implement and test database applications of realistic complexity. Convert data to/from various proprietary database formats. Participate effectively in team development of a marketable database application. Other Class-Related Issues Database Access Academic dishonesty Expectations Attend lectures Be on time Students with disabilities Visit Choose server mysql.cs.orst.edu and log in Database name: your OID User id: your OID Password: last four digits of your OSU ID Questions? s To Cover Relational algebra and calculus ormal forms Physical data storage and retrieval Indexes Query processing and optimization Transactions ew types of databases

3 What We Have Covered In 275 (for Prof. Minoura s and my classes) Review of Relational Databases Relational databases ER modeling Relational algebra SQL Database is a coherent collection of data with some inherent meaning and is designed, built, and populated with data for specific purpose. Review of Relational Databases Review of Relational Databases A database can be of any size and varying complexity, which requires the database to be well-organized and managed. Database management systems (DBMS) is a collection of programs that allows users to create and maintain a database, e.g., construction manipulation sharing protection maintenance Review of Relational Databases Review of Relational Databases Database management systems (DBMS) is a collection of programs that allows users to create and maintain a database. DBMS = database + DBMS software database Data definition Data Account information DBMS software Software for processing queries/programs Software to access stored data Characteristics of database approach: Insulation between programs and data, and data abstraction Support of multiple views of the same data Sharing of data and multiuser transaction processing Providing storage structures for efficient query processing

4 Review of Relational Databases Review of Relational Models Advantages: Controlling redundancy Restricting unauthorized access Providing persistent storage for program objects Data structure compatibility Providing backup and recovery Providing multiple user interfaces Representing complex relationship among data Enforcing integrity constraints Permitting inferencing and actions using rules Potential for enforcing standards Reduced application development time Flexibility Availability of up-to-date information Economies of scale A schema is the description of a database It is specified during design It is not expected to change frequently Review of Relational Models Review of Relational Models Three-schema architecture: Internal schema describes physical storage structure of a database and access paths Conceptual schema Describes the structure of a database for a community of users Hides the details of physical storage Concentrates on describing entities, relationship, and constraints External schema (views) Describes parts of the data that a user group is interested Hides the rest of the data from the user group Advantages of three-schema architecture: Data independence: Logical: change conceptual schema without changing external views Physical: change internal schema without changing conceptual schema Support of multiple views This architecture requires mapping between different levels For small databases, external level is often not supported Review of Relational Models Review of Relational Models A database state is a snapshot of the database The database state changes if we add a record remove a record update a record Schema versus State During design phase: Schema is available Empty state (no data) DBMS ensures every state is valid Schema evolution

5 Review of Relational Models Review of Database Design Process Database Languages DDL (data definition language) DML (data manipulation language) High-level (nonprocedural) Can be embedded in a general-purpose language Can also be used on its own (SQL) Low-level (procedural) Must be embedded in a general-purpose programming language Step: requirements collection and analysis data and functional requirements Step 2: conceptual database design detailed descriptions of entities, relationships, and constraints Step 3: high-level operation design basic data model operations based on functional requirements Step 4: database implementation using a commercial DBMS transforms the conceptual schema to an implementation schema Step 5: physical design: physical storage, indexes, access paths, file organization Review of Database Design Process Review of Entity-Relationship Model (ER Model) Step: requirements collection and analysis data and functional requirements Step 2: conceptual database design detailed descriptions of entities, relationships, and constraints Step 3: high-level operation design basic data model operations based on functional requirements Step 4: database implementation using a commercial DBMS transforms the conceptual schema to an implementation schema Step 5: physical design: physical storage, indexes, access paths, file organization ER Model is a popular high-level conceptual data model It is also frequently used for the conceptual design of database applications Many database design tools employ its concepts ER diagrams are diagrammatic notations associated with ER models Review of Entity-Relationship Model (ER Model) An entity is a thing in the real world with an independent existence Attributes of an entity describe its properties Simple and composite Single-valued and multi-valued Stored and derived ULL Key attributes (primary, secondary, candidate, foreign) Key Attributes An entity type is represented in ER diagrams as a rectangle box Attribute names are enclosed in ovals Key attributes are shown with underlines umber Employee Department Supervisor Locations

6 Review of Entity-Relationship Model (ER Model) Review of Entity-Relationship Model (ER Model) A relationship type R among n entity types E,, En defined a relationship set Each individual instance is a relationship instance Displayed as diamond-shaped boxes in ER diagrams The degree: number of participating entities Cardinality ratios for binary relationship: :, M: Employee Works for Department Roles names An entity type appears more than once in a relationship Participation constraints Total: every employee must work for a department (employee-department-work_for) Partial: not every employee manages a department (employee-department-manage) Employee Works for Department Review of Entity-Relationship Model (ER Model) ID Weak entity types Cannot be identified without an owner entity Has a partial key to identify a record once the owner s key is given Weak entity types can sometimes be represented as complex attributes (multi-valued, composite) SS Relation umber Employee Dependent ID ID umber umber

7 ID ID umber umber ID ID umber umber ID ID umber umber

8 Symbol Meaning ETITY TYPE ID WEAK ETITY TYPE RELATIOSHIP TYPE IDETIFYIG RELATIOSHIP TYPE ATTRIBUTE KEY ATTRIBUTE MULTIVALUED ATTRIBUTE COMPOSITE ATTRIBUTE DERIVED ATTRIBUTE umber E R E 2 E R E 2 TOTAL PARTICIPATIO OF E2 I R CARDIALITY RATIO : FOR E:E2 I R R (min,max) E STRUCTURAL COSTRAIT (min, max) O PARTICIPATIO OF E I R ER Modeling ID Another way of specifying cardinality and participation (min, max) umber ID Review of Relation Schemas (0, ) (, ) umber (, ) (,) A relationship is like a table A row is a collection of related data values A column represents an attribute in the relationship Domain A set of atomic (indivisible) values requires a name, a data type, and a format Tuple Attribute Relation

9 Review of Relation Schemas Review of Relation Schemas A relation schema R=R(A, An) Student(:string, SS:string, HomePhone:string, Address:string, OfficePhone:string, Age:integer, GPA:real) A relation r of the relation schema R(A, A2,, An) is a set of tuples r={t,.., tn} Each tuple t = (v,, vn) such that vi is in dom(ai) or vi is null The i-th component of t is t[i] Review of Relation Schemas Review of Relation Schemas A relation r(r) is a mathematical relation of degree n on the domains dom(a),, dom(an), which is a subset of the Cartesian product of the domains that define R r( R) dom(a ) dom(a 2 ) K dom(a n ) Constraints: Inherent model-based constraints Domain constraints Key attributes Schema-based constraints Application-based constraints Often very general Business rules eed to define and enforce in programs Review of Relation Schemas Keys Candidate keys Primary, secondary Foreign keys SQL statements Create tables Create views Define constraints Define links between tables

10 Example: CREATE SCHEMA company AUTHORIZATIO jsmith; CREATE TABLE company.employee CREATE TABLE employee CREATE TABLE employee ( F VARCHAR(5) OT ULL, MInit CHAR, L VARCHAR(5) OT ULL, SS CHAR(9) OT ULL, BDateDate, Address VARCHAR(30), Gender CHAR, DECIMAL(0.2), SuperSS VARCHAR(9), Do IT OT ULL, PRIMARY KEY (SS), FOREIG KEY (SuperRSS) REFERECES employee(ss), FOREIG KEY (Do) REFERECES department(dumber) ); Attributes Data Types and Domains CREATE DOMAI SS AS CHAR(9); Basic constraints: Key constraints Referential integrity constraints Domain constraints ULL Constraints on tuples within a relation Attribute constraints: Dumber IT OT ULL CHECK (Dumber>0 AD Dumber < 2); CREATE DOMAI Dumber AS ITEGER CHECK (Dumber>0 AD Dumber < 2); Attribute default: CREATE TABLE employee ( F VARCHAR(5) OT ULL, MInit CHAR, L VARCHAR(5) OT ULL, SS CHAR(9) OT ULL, BDate Date, AddressVARCHAR(30), Gender CHAR, DECIMAL(0.2), SuperSS VARCHAR(9), Do IT OT ULL DEFAULT, PRIMARY KEY (SS), FOREIG KEY (SuperRSS) REFERECES employee(ss), FOREIG KEY (Do) REFERECES department(dumber) );

11 Key and referential integrity constraints: CREATE TABLE employee ( F VARCHAR(5) OT ULL, MInit CHAR, L VARCHAR(5) OT ULL, SS CHAR(9) OT ULL, BDate Date, AddressVARCHAR(30), Gender CHAR, DECIMAL(0.2), SuperSS VARCHAR(9), Do IT OT ULL DEFAULT, COSTRAIT EMPPK PRIMARY KEY (SS), COSTRAIT EMPSUPERFK FOREIG KEY (SuperRSS) REFERECES employee(ss) O DELETE SET ULL O UPDATE CASCADE, COSTRAIT EMPDEPTFK FOREIG KEY (Do) REFERECES department(dumber) O DELETE SET DEFAULT O UPDATE CASCADE ); DROP Table View Constraints Triggers Assertions Stored procedures DROP TABLE Dependent; ALTER ALTER TABLE Dependent ALTER MGRSS DROP DEFAULT; DML: Read operations: Select (see what are currently there) Write operations: Insert (add new records) Delete (remove records that are currently in the database) Update (change certain attributes of records that are currently in the database)

12 Views are virtual tables create view works_on as select fname, lname, pname, hours from employee, project, works_on where ssn = essn and pno = pnumber; View realization: Query modification: map the view into a query statement. Can be slow when the same view is called multiple times in a short period of time View materialization: actually build a table Must be updated to reflect the changes in the base table Updating a view: A view with a single table Yes, if the view attributes contain the primary key of the base table, and all attributes with the OT ULL constraints that do not have the default values specified A view joining multiple table In general, no, because of the possible ambiguity