September 2000C.Watters1 Data & Database Management Systems (DBMS) ECMM6010

September 2000C.Watters2 Objectives  See how DBMS work  Use use case diagrams to describe system use  Use E-R diagrams to describe data  Understand how to use data in DBMS on the Internet

September 2000C.Watters3 Role of DBMS and E-commerce Nearly 80% of all web accesses involve a database at the server 80% of web pages today are commercial in nature (Lee Giles, NEC) Most DBMS in use today are relational (SQL)

September 2000C.Watters4 So What is a Database Management System (DBMS)? General purpose software for processes of defining, creating, updating, querying, and manipulating data sets provides application-data independence

September 2000C.Watters5 But what is it??

September 2000C.Watters6 Why Bother? Separate application programs from data Provide multiple uses of data Provide a single copy of data –For concurrent use –Single updating enforce standards

September 2000C.Watters7 ANSI-SPARC Model logical & physical independence Physical indep Logical indep

September 2000C.Watters8 Design Process Functional Analysis & Use Cases Data modeling (E-R diagrams) Table design (Normalization)

September 2000C.Watters9 Defining Process: Use Case Users of the system are called actors Each business process that actors want is represented by a use case So the way the actors use the system is defined by a inter-related set of use case scenarios

September 2000C.Watters10 Use Case Sample Loan Manage Account Invest Customer Loan officer Teller

September 2000C.Watters11 Defining Data: Entity-Relationship (ER) Diagrams

September 2000C.Watters12 Attribute Variations

September 2000C.Watters13 Sample

September 2000C.Watters14 Constraints (N:M)

September 2000C.Watters15 Relational Model Based on sets a relation is a table with a schema

September 2000C.Watters16 Table Design Phase Rules of thumb –one table per entity –one table per relationship For sure Rule –each table has a unique identifier, called the primary key (1 or more attributes)

September 2000C.Watters17 Sample Schema Student(StNumber, StName, Major) Course(CNumber, CName, Professor) Takes(StNumber,Cnumber)

September 2000C.Watters18 Relation, Tuple, Attribute, Domain

September 2000C.Watters19 Relational Axioms There is no meaning to the order of tuples in a relation There is no meaning in the order of attributes in a relation Each tuple is unique in a relation Each attribute value is atomic Each tuple is an assertion

September 2000C.Watters20 Primary and Foreign keys Primary Key: attribute(s) that identify tuples

September 2000C.Watters21 IntraTable Connections Foreign Key: attribute(s) that link to primary key in another relation

September 2000C.Watters22 Relational Constraints Entity Integrity: no primary key is null Referential Integrity: –if a foreign key refers to a primary key in another relation then that key must exist

September 2000C.Watters23 Relational Operations (So what can you do with tables?) Choose one or more rows [SELECT] Choose one or more columns [PROJECT] Join 2 tables to make a new one [JOIN] set operations (union, intersection, minus) RESULT IS ALWAYS ANOTHER TABLE

September 2000C.Watters24 Querying with SQL Choose rows –Select * from students where name =“jones” Choose columns –Select name, number from students Combine tables –Select * from students, faculty where S.dept=F.dept Do any of the above with the new tables

September 2000C.Watters25 SELECT * from STUDENT Where Major=“CS” Choose rows from a table resulting table has same number of attributes

September 2000C.Watters26 picking columns SELECT SName from Student Choose one or columns from each row Resulting table has same number of rows

September 2000C.Watters27 Select * from STUDENT,BUILDING where STUDENT.Major = BUILDING.Major New table has all attributes from both New table has one row for every A’=A” pair

September 2000C.Watters28 USING SQL CREATE TABLE xyz INSERT into xyz (……,..,..,..) SELECT * FROM xyz SELECT a,c FROM xyz SELECT a,c FROM xyz WHERE a=“Joe” SELECT name,phone FROM A, B WHERE A.name=B.name UPDATE xyz WHERE ….

September 2000C.Watters29 Quality Design and Normalization Issues of quality –maintain semantics of the attributes and relations –reduction of redundant values –reduction of null values –elimination of spurious tuples

September 2000C.Watters30 1st Normal Form Attributes are single values i.e., no multivalued or composite attributes STUDENT(StNumber,Stname, {phone1,phone2}, HomeAddr) STUDENT(StNumber,Stname,HomeAddr) StPHONE(StNumber,phone)

September 2000C.Watters31 2nd Normal Form All attributes are fully Dependent on primary key COURSE(CNUMBER,SEC, Room,Cname) COURSE(CNUMBER,SEC,Room) CNAME(CNUMBER, Cname) Why do we care?? Updates!!

September 2000C.Watters32 3rd Normal Form No dependencies other than on primary key COURSE(CNUMBER,SEC,Prof,ProfOffice) COURSE(CNUMBER,SEC,Prof) PROFS(Prof, ProfOffice)

September 2000C.Watters33 And on and on… Most designs are 3NF (usually good-enough)

September 2000C.Watters34 Transaction Processing& concurrency control User AJoint AccountUser B read total: $100 take out $50 write total: $50 $50 write total: $50 Not good for business!!

September 2000C.Watters35 ACID Transaction Model  Atomic – transaction cannot be divided into sub- transactions  Consistent – transaction guarantees that data is consistent. Transaction is completed or undone. (Do no harm!)  Isolated – Transactions are not affected by concurrent transactions (locks on writes)  Durable – Effects of transactions persist (even after system crash).

September 2000C.Watters36 Recovery DBMS is responsible for guaranteeing either –a transactions is completed successfully –or –a transaction has no effect on the data or any other transaction

September 2000C.Watters37 Security and Authorization Protecting data against unauthorized access

September 2000C.Watters38 Recap E-commerce depends on DBMS Use case diagrams help define the processes E-R diagrams help define the data and relationships among data Database design must be done carefully Commercial DBMS provide backend features