1. Fall 2008, INFS614 1 Database Management Systems INFS 614-001 Fall 08 Instructor: Carlotta Domeniconi carlotta@cs.gmu.edu@cs.gmu.edu http://www.cs.gmu.edu/~carlotta/teaching/INFS-614- s08/info.html Lecture One - Introduction

2. Fall 2008, INFS614 2 Outline v Course syllabus –Course Schedule –Homeworks & exams v Satisfaction of prerequisites –Strictly enforced: GMU HONOR CODE applies! v Introduction to DB & DBMS –Outline of the entire course material

3. Fall 2008, INFS614 3 Front matters v To communicate with me: –Email: carlotta@cs.gmu.edu, I will try to reply promptly.@cs.gmu.edu –Office hours: by appointment. v Sign up for your Mason account. You may forward all your Mason emails to your favorite email address.

4. Fall 2008, INFS614 4 Front matters (cont.) v GTA: –Huaming Liu and Chun-Kit Ngan –Email: hliu5@gmu.edu@gmu.edu –Office hours: Tuesday, 4-6pm (Huaming) –Room: 330 -ST2.

5. Fall 2008, INFS614 5 Front matters (cont.) v Required textbooks: –Database Management Systems, 3rd ed. by Raghu Ramakrishnan & Johannes Gehrke, McGraw-Hill. –Oracle 9i Programming: a Primer, by Rajshkhar Sunderraman, Addison Wesley, ISBN 0-321- 19498-5 v On-Line Course Resources: http://www.cs.gmu.edu/~carlotta/teaching/INFS- 614-f08/info.html –You are required to read all the material there. The content will be updated frequently. So check the web site periodically, at least once every week, and every time before class!

6. Fall 2008, INFS614 6 DateTopic (chapter/section)HW assignmentHW due Aug 28Introduction (chapter 1) Sep 4ER model (chapter 2)1 Sep 11Relational Model (chapter 3) Sep 18Relational Algebra (sections 4.1-4.2)21 Sep 25Relational Algebra (continued) Oct 2SQL (sections 3.4, 5.1-5.5)32 Oct 9Review 3 Oct 16Midterm Exam Oct 23SQL (sections 5.6-5.15)4 Oct 30Functional Dependencies Nov 6Functional Dependencies (continued) 54 Nov 13Decomposition and Normal Forms Nov 20Advanced topics (or catch up) 5 Dec 4Review Dec 11Final Exam

7. Fall 2008, INFS614 7 Submission and Grading v Late submissions are not accepted: no exceptions! v No make-up exams! v On-time: within 5 minutes after the class begins. v Important: your homeworks must run properly under the Oracle system in the labs. v Final grades: –homework assignments (20%) –Project (15%) –midterm exam (25%) –final exam (40%)

8. Fall 2008, INFS614 8 Honor Code System v GMU honor Code http://honorcode.gmu.edu/ http://honorcode.gmu.edu/ v For this class –Homeworks & exams require individual work. Study groups are encouraged, but homeworks’ solutions and write up must be individual. –Exams: individual effort, closed books v Satisfaction of prerequisites: –Honor code invoked.

9. Fall 2008, INFS614 9 Satisfaction of prerequisites v Prerequisites (strictly enforced) –INFS-501 (Discrete mathematics) –INFS-515 (Computer architecture/organization) –INFS-590 (Program Design and data structures) Specifically: –Good background in discrete mathematics (e.g., set theory, mathematical logic, relations and functions); –Programming (good knowledge of either C, C++ or Java); –Data structures and algorithms, Computer architecture, and Operating systems.

10. Fall 2008, INFS614 10 Satisfaction of prerequisites For INFS/SWE/ISA students: v Consult your letter of acceptance. It specifies your status with respect to these foundation courses. For each course, it must be that either –You were waved from the course (the evidence should be either in the acceptance letter or in a subsequent official document). –You took the course and received a grade of B or better.

11. Fall 2008, INFS614 11 Satisfaction of prerequisites v For non-IS/SWE/ISA students, MUST DO THE FOLLOWING (by next week): –Consult the description of each of the prerequisite courses in the university catalog.description of each of the prerequisite courses –For each course, provide a list of one or more courses taken, that cover the subjects of that course, as follows: course-number, course-title, institution, year, final-grade; –Syllabus of each course taken; –Copy of transcripts that shows equivalent classes taken (with grade B or better); –Current status;

12. Fall 2008, INFS614 12 Useful links for your computing needs  http://labs.ite.gmu.edu/ (click on FAQ’s) for IT&E computing labs, IT&E cluster account, and Oracle DBMS information.  http://cs.gmu.edu/~ami/teaching/infs614/current/oracl e.html for information on our particular computing environment.

13. Fall 2008, INFS614 13 Introduction to DB and DBMS

14. Fall 2008, INFS614 14 What is a Database? v Database : A very large, integrated collection of data. v Data : Known facts about the real-world that can be recorded and have implicit meaning; v A database models real-world scenarios : –Entities –Relationships between entities

15. Fall 2008, INFS614 15 University Database v Information about university environment Relationships : Students’ enrollment course Faculty teaching courses Use of classroom for course Prerequisite courses Entities : Students Faculty Courses Classrooms

16. Fall 2008, INFS614 16 What is a DBMS? v A Database Management System (DBMS) is a software package designed to store, provide access and manage databases –One DBMS, many databases; v Database System: A database and a DBMS. v Why use a DBMS?

17. Fall 2008, INFS614 17 A simple problem: address list v Solution 1 v Solution 1: a blank notebook, entries recorded with a pen, in time order. v Advantages: simple, private, reliable, space efficient. v Disadvantages: –Hard to search; –Hard to add information (e.g., e-mail); –Hard to update information; –Hard to extract information (print Christmas cards); –Integrity and consistency (Mary Jones: see P. Jones address, P. Jones-Smith entry); –Loosing it is a catastrophe!

18. Fall 2008, INFS614 18 Solution 2: a loose-leaf notebook with n entries per page v Better: –Can keep it sorted by key; –Insertions & deletions can be done; v Same as Sol. 1 in other aspects: –No search by other keys (e.g., phone number).

19. Fall 2008, INFS614 19 Solution 3: Text format,managed by text editor v Advantages: –Free format; –“Unlimited” size; –Easily copied (for backup); –Easily shared; –Sub-string searchable; –Easy Update. v Disadvantages: –Change requirements?

20. Fall 2008, INFS614 20 Complications with Solution 3 v File gets very large –Search gets slow and possibly imprecise. (E.g., search for “Elm Street” may yield “Wilhelm Street”) v Solution v Solution: structure entries into records with fields and add indexes over fields. Database Concepts: Record Organization, Keys, Indexes

21. Fall 2008, INFS614 21 Complication 2: need to separate families from addresses v Why? –People move; –Might forget to update addresses; –Want space economy: single point of update; –Important to separate for applications: 1 Christmas card per residence! v Solution v Solution: two files (one: people, one: addresses). How do we link them? How many residences a person can have? Database Concepts: Consistency, Normalization, Foreign Keys

22. Fall 2008, INFS614 22 Complication 3: multiple association v People own, rent, manage residences v May want to impose constraints in the number of residences per person or vice versa. v Examples: Many to many (rich people); Many to one (single family); One to many (Builder); One to one (legal residence) Database Concepts: Relationships; Cardinality

23. Fall 2008, INFS614 23 Complication 4: dynamic nature of the data v Add new information: –Cards sent and received –Zip+4 v Requirements: –Adding fields –Summarizing Database Concepts: Data Abstraction; Data Evolution

24. Fall 2008, INFS614 24 Complication 5: Ad hoc analysis and retrieval v Example: –Find who sent me cards over the past 5 years, but received less than 3 cards from me. v Requirements: –A language –An implementation of retrieval functions (correct and efficient). Database Concepts: Query languages; Query optimization

25. Fall 2008, INFS614 25 Complication 6: Sharing v Different users, different organizations –Other family members want to see names and addresses together –You don’t want to give update access over your business contacts to anybody. v Solutions: –Use stored queries as ”windows” or “views” over the database. –Ability to “reunite” data from different files. –Data not selected by the query is “not there” –Permissions Database Concepts: Joins; Views; Security

26. Fall 2008, INFS614 26 Complication 7: Required existence of associated data v Examples: –Can’t send Christmas card to somebody without an address –Names are not unique; only when associated with residence. v Solution: –Don’t insert a name if there is no address and vice versa –Or tolerate multiple non-unique names Database Concepts: Referential Integrity; Weak entity sets

27. Fall 2008, INFS614 27 Complication 8: Multiple updates in an all or none basis v Examples –Two households merge (marriage) –Need to change residences (or other data) for a group of people –Computer crashes in the middle of updates v Solution –Illusion of updates being done simultaneously –Commit or rollback an entire chunk of work Database Concepts: Transactions; ACID properties; Recovery

28. Fall 2008, INFS614 28 Complication 9: computer crashes v Will I have my data after the crash? –Uncorrupted? –Consistent? v Solution: –Make sure data is available uncorrupted at a point in the past (checkpoint) Database Concepts: Durability; Consistency (ACID); Recovery

29. Fall 2008, INFS614 29 Complication 10: multimedia v Pictures, Audio, Text, … v Requirements: –Ability to store new data types –Content search –Integration with text and numeric data Database Concepts: Multimedia databases; Query by content

30. Fall 2008, INFS614 30 Complication 11: You become President! … v Of something …(US, Corporation, Local chapter of charity, your household) –Your address list grows exponentially –You realize some of the information is useful! v Examples: –zip codes in states where there are less than 5% difference in Rep./Dem. Votes in 2004? –Which combinations of products sold best last year? Database Concepts: Data Warehousing; Data Mining

31. Fall 2008, INFS614 31 Files vs. DBMS v Application must store large datasets between main memory and secondary storage (e.g., buffering, page-oriented access, etc.); v Special code to answer different queries; v Must protect data from inconsistency due to multiple concurrent users; v Crash recovery; v Security and access control.

32. Fall 2008, INFS614 32 Why Use a DBMS? Easier and More Efficient v Data independence and efficient access; v Reduced application development time; v Data integrity and security; v Uniform data administration; v Concurrent access, recovery from crashes.

33. Fall 2008, INFS614 33 Data Models v A data model is a collection of concepts for describing data. v A schema is a description of a particular collection of data, using a given data model. v The relational model of data is the most widely used model today. – Main concept: relation, basically a table with rows and columns. – Every relation has a schema, which describes the columns, or fields.

34. Fall 2008, INFS614 34 Relational Model v The main concept is a relation: –A table with rows and columns v Each row in the table is called a tuple

35. Fall 2008, INFS614 35 Relational Model (cont.) v The relation schema specifies: –name of the relation, –name of each attribute (column,field) and its type. Every attribute has an atomic type. Relation Name Student(sid:string, login:string, age:integer, gpa:real); Attribute Name v A Relation (Relation instance): a set of tuples.

36. Fall 2008, INFS614 36 Levels of Abstraction v Many views, single conceptual (logical) schema and physical schema. – Views describe how users see the data. – Conceptual schema defines logical structure – Physical schema describes the files and indexes used.  Schemas are defined using DDL (Data Definition Language); *Data is modified/queried using DML (Data Manipulation Language). Physical Schema Conceptual Schema View 1View 2View 3

37. Fall 2008, INFS614 37 Levels of Abstraction * Conceptual Schema : the data is described through the data model. It describes structure and constraints for the whole database. * External Schema : how the users see and use the data. Many views of the data. * Physical schema : describes the physical structure of the DB * Mappings among schema levels are also needed. Programs and applications refer to an external schema, and are mapped by the DBMS to the conceptual schema for execution. Conceptual, External Schemas are defined using Data Definition Language (DDL) : specification for defining the database schema

38. Fall 2008, INFS614 38 Example: University Database v Conceptual schema: –Student (sid: string, name: string, login: string, age: integer, gpa: real) –Courses (cid: string, cname: string, credits: integer) –Enrolled (sid: string, cid: string, grade: string) v Physical schema: –Relations stored as unordered files. –Index on first column of Students… v External schema (View): –Course_info (cid: string, enrollment: integer)

39. Fall 2008, INFS614 39 Data Independence v Applications insulated from how data is structured and stored. v Logical data independence: Protection from changes in logical structure of data. v Physical data independence: Protection from changes in physical structure of data.  One of the most important benefits of using a DBMS!

40. Fall 2008, INFS614 40 Easy Manipulation & Access of the Information v A DBMS enables users to create, update and query the data through Data Languages v Data Definition Language (DDL) –Specification notation to create the Database schema v Data Manipulation Language (DML) –A language for manipulating the data : updating the data and accessing the data –The portion of a DML that allows to access the information through formulating queries is called the Query Language Query : Request for retrieving data stored in a DBMS.

41. Fall 2008, INFS614 41 Concurrency Control v Concurrent execution of user programs is essential for good DBMS performance –Because disk accesses are frequent, and relatively slow, it is important to keep the cpu not idle by working on several user programs concurrently. v Interleaving actions of different user programs can lead to inconsistency: e.g., check is cleared while account balance is being computed. v DBMS ensures such problems don’t arise: users can pretend they are using a single- user system.

42. Fall 2008, INFS614 42 Concurrency Control (cont.) Example: v One course still has space for one more student. v Two students are trying to enroll in that course at the same time. v The DBMS executes the two requests in a serial order. v Thus, only one student will be enrolled.

43. Fall 2008, INFS614 43 Transaction v An execution of a DB program v Key concept is transaction, which is an atomic sequence of database actions (reads/writes). v ACID properties –A – Atomicity –C – Consistency –I – Isolation –D – Durability v How: log and concurrency control sub-system

44. Fall 2008, INFS614 44 Scheduling Concurrent Transactions v DBMS ensures that execution of {T1,…, Tn} is equivalent to some serial execution T1’…Tn’. –Before reading/writing an object, a transaction requests a lock on the object, and waits till the DBMS gives it the lock. All locks are released at the end of the transaction. (Strict 2PL locking protocol.) –Idea: If an action of Ti (say, writing X) affects Tj (e.g., reads X), one of them, say Ti, will obtain the lock on X first and Tj is forced to wait until Ti completes; this effectively orders the transactions.

45. Fall 2008, INFS614 45 Ensuring Atomicity v DBMS ensures atomicity (all-or-nothing property) even if system crashes in the middle of a transaction. v Idea: Keep a log (history) of all actions carried out by the DBMS while executing a set of transactions: –Before a change is made to the database, the corresponding log entry is forced to a safe location. (WAL – Write-Ahead Log – protocol); –After a crash, the effects of partially executed transactions are undone using the log.

46. Fall 2008, INFS614 46 The Log v The following actions are recorded in the log: –Ti writes an object: the old and new value. u Log record must go to disk before the changed page! –Ti commits/aborts: a log record indicating this action. v Log records chained together by the transaction id, so it’s easy to undo a specific transaction (e.g., resolve a deadlock) v All log related activities are handled transparently by the DBMS.

47. Fall 2008, INFS614 47 Structure of a DBMS v A typical DBMS has a layered architecture v Each layer is composed of several modules v The architecture varies from vendor to vendor

48. Fall 2008, INFS614 48 High initial investment and possible need for additional hardware. Overhead for providing generality, security, recovery, integrity and concurrency control. Main cost of using a DBMS If the Database and application are simple, well-defined and not expected to change. If there are stringent real-time requirements, that may not be met due to DBMS overhead. If access to data by multiple users is not required. When a DBMS may be unnecessary

49. Fall 2008, INFS614 49 Database Users v End users (or DB application users) v DB application programmers (more precisely, they are DBMS users) – E.g. smart webmasters – This course is mostly to learn how to (start to) be a DB application programmer. v Database administrator (DBA) – Designs logical /physical schemas – Handles security and authorization – Data availability, crash recovery – Database tuning as needs evolve Must understand how a DBMS works!

50. Fall 2008, INFS614 50 Summary v DBMS used to maintain, query large datasets. v Benefits include recovery from system crashes, concurrent access, quick application development, data integrity and security. v Levels of abstraction give data independence. v We will learn how to –Set up a database u Design (ERD and Relational Model), and refine (Relational Normalization Theory) –Use to query the database u Relational Algebra and SQL