Database Management System (DBMS) DBMS contains information about a particular enterprise o Collection of interrelated data o Set of programs

s to access the data o An environment that is both convenient and efficient to use Database Applications: o Banking: all transactions o Airlines: reservations, schedules o Universities: registration, grades o Sales: customers, products, purchases o Online retailers: order tracking, customi ed recommendations o Manufacturing: production, inventor!, orders, suppl! chain o "uman resources: emplo!ee records, salaries, ta# deductions Databases touch all aspects of our lives

Purpose of Database Systems $n the earl! da!s, database applications %ere built directl! on top of file s!stems Dra%backs of using file s!stems to store data: o Data redundanc! and inconsistenc! Multiple file formats, duplication of information in different files o Difficult! in accessing data &eed to %rite a ne% program to carr! out each ne% task o Data isolation ' multiple files and formats o $ntegrit! problems $ntegrit! constraints (e)g) account balance * +, become -buried. in program code rather than being stated e#plicitl! "ard to add ne% constraints or change e#isting ones o Atomicit! of updates /ailures ma! leave database in an inconsistent state %ith partial updates carried out 0#ample: 1ransfer of funds from one account to another should either complete or not happen at all o Concurrent access b! multiple users Concurrent accessed needed for performance Uncontrolled concurrent accesses can lead to inconsistencies 0#ample: 1%o people reading a balance and updating it at the same time o Securit! problems "ard to provide user access to some, but not all, data Levels of Abstraction Physical level: describes ho% a record (e)g), customer, is stored) Logical level: describes data stored in database, and the relationships among the data) type customer 2 record customer_id : string3 customer_name : string3 customer4street : string3 customer_city : string3 end3 Vie level: application programs hide details of data t!pes) 5ie%s can also hide information (such as an emplo!ee6s salar!, for securit! purposes)

!nstances and Schemas Similar to t!pes and variables in programming languages Schema 7 the logical structure of the database o 0#ample: 1he database consists of information about a set of customers and accounts and the relationship bet%een them, o Analogous to t!pe information of a variable in a program o 8h!sical schema: database design at the ph!sical level o 9ogical schema: database design at the logical level $nstance 7 the actual content of the database at a particular point in time o Analogous to the value of a variable 8h!sical Data $ndependence 7 the abilit! to modif! the ph!sical schema %ithout changing the logical schema o Applications depend on the logical schema o $n general, the interfaces bet%een the various levels and components should be %ell defined so that changes in some parts do not seriousl! influence others) Data Models A collection of tools for describing o Data o Data relationships o Data semantics o Data constraints :elational model 0ntit!;:elationship data model (mainl! for database design, Ob<ect;based data models (Ob<ect;oriented and Ob<ect;relational, Semistructured data model (=M9, Other older models: o &et%ork model o "ierarchical model Data Manipulation Language (DML) 9anguage for accessing and manipulating the data organi ed b! the appropriate data model o DM9 also kno%n as >uer! language 1%o classes of languages o Procedural 7 user specifies %hat data is re>uired and ho% to get those data o Declarative (nonprocedural) 7 user specifies %hat data is re>uired %ithout specif!ing ho% to get those data S?9 is the most %idel! used >uer! language

Data Definition Language (DDL) Specification notation for defining the database schema 0#ample: create table account ( account_number char(@+,, branch_name char(@+,, balance integer, DD9 compiler generates a set of tables stored in a data dictionar! Data dictionar! contains metadata (i)e), data about data,

o o o

o S"L

Database schema Data storage and definition language Specifies the storage structure and access methods used $ntegrit! constraints Domain constraints :eferential integrit! (e)g) branch_name must correspond to a valid branch in the branch table, Authori ation

S"L: %idel! used non;procedural language l 0#ample: /ind the name of the customer %ith customer;id @AB;CD;EFGH select customer.customer_name from customer here customer.customer_id 2 I@AB;CD;EFGH6 l 0#ample: /ind the balances of all accounts held b! the customer %ith customer;id @AB; CD;EFGH select account.balance from depositor, account here depositor.customer_id 2 I@AB;CD;EFGH6 and depositor.account_number = account.account_number Application programs generall! access databases through one of o 9anguage e#tensions to allo% embedded S?9 o Application program interface (e)g), ODBCJKDBC, %hich allo% S?9 >ueries to be sent to a database Database Design 1he process of designing the general structure of the database: Logical Design 7 Deciding on the database schema) Database design re>uires that %e find a -good. collection of relation schemas) o Business decision 7 Lhat attributes should %e record in the databaseM o #omputer Science decision 7 Lhat relation schemas should %e have and ho% should the attributes be distributed among the various relation schemasM Physical Design 7 Deciding on the ph!sical la!out of the database $he %ntity&'elationship Model Models an enterprise as a collection of entities and relationships o %ntity( a -thing. or -ob<ect. in the enterprise that is distinguishable from other ob<ects Described b! a set of attributes o 'elationship: an association among several entities :epresented diagrammaticall! b! an entit!;relationship diagram:

)ther Data Models Ob<ect;oriented data model Ob<ect;relational data model Database Application Architectures

Database Management System !nternals Storage management ?uer! processing 1ransaction processing Storage Management Storage manager is a program module that provides the interface bet%een the lo%;level data stored in the database and the application programs and >ueries submitted to the s!stem) 1he storage manager is responsible to the follo%ing tasks: o $nteraction %ith the file manager o 0fficient storing, retrieving and updating of data $ssues: o Storage access o /ile organi ation o $nde#ing and hashing "uery Processing @) 8arsing and translate on B) Optimi ation D) 0valuation

Alternative %a!s of evaluating a given >uer! o 0>uivalent e#pressions o Different algorithms for each operation Cost difference bet%een a good and a bad %a! of evaluating a >uer! can be enormous &eed to estimate the cost of operations o Depends criticall! on statistical information about relations %hich the database must maintain o &eed to estimate statistics for intermediate results to compute cost of comple# e#pressions $ransaction Management

A transaction is a collection of operations that performs a single logical function in a database application $ransaction&management component ensures that the database remains in a consistent (correct, state despite s!stem failures (e)g), po%er failures and operating s!stem crashes, and transaction failures) #oncurrency&control manager controls the interaction among the concurrent transactions, to ensure the consistenc! of the database) *istory of Database Systems @AH+s and earl! @AG+s: o Data processing using magnetic tapes for storage 1apes provide onl! se>uential access o 8unched cards for input 9ate @AG+s and @AE+s: o "ard disks allo% direct access to data o &et%ork and hierarchical data models in %idespread use o 1ed Codd defines the relational data model Lould %in the ACM 1uring A%ard for this %ork $BM :esearch begins S!stem : protot!pe UC Berkele! begins $ngres protot!pe o "igh;performance (for the era, transaction processing @AC+s: o :esearch relational protot!pes evolve into commercial s!stems S?9 becomes industr! standard o 8arallel and distributed database s!stems o Ob<ect;oriented database s!stems @AA+s: o 9arge decision support and data;mining applications o 9arge multi;terab!te data %arehouses o 0mergence of Leb commerce B+++s: o =M9 and =?uer! standards o Automated database administration o $ncreasing use of highl! parallel database s!stems o Leb;scale distributed data storage s!stems Database +sers +sers are differentiated b! the %a! the! e#pect to interact %ith the s!stem Application programmers 7 interact %ith s!stem through DM9 calls Sophisticated users 7 form re>uests in a database >uer! language Speciali,ed users 7 %rite speciali ed database applications that do not fit into the traditional data processing frame%ork -a.ve users 7 invoke one of the permanent application programs that have been %ritten previousl! l 0#amples, people accessing database over the %eb, bank tellers, clerical staff Database Administrator Coordinates all the activities of the database s!stem o has a good understanding of the enterprise6s information resources and needs) Database administratorNs duties include: o Storage structure and access method definition o Schema and ph!sical organi ation modification o Oranting users authorit! to access the database o Backing up data o Monitoring performance and responding to changes Database tuning Database Architecture 1he architecture of a database s!stems is greatl! influenced b! the underl!ing computer s!stem on %hich the database is running:

Centrali ed Client;server 8arallel (multiple processors and disks, Distributed

)b/ect&'elational Data Models 0#tend the relational data model b! including ob<ect orientation and constructs to deal %ith added data t!pes) Allo% attributes of tuples to have comple# t!pes, including non;atomic values such as nested relations) 8reserve relational foundations, in particular the declarative access to data, %hile e#tending modeling po%er) 8rovide up%ard compatibilit! %ith e#isting relational languages) 0ML( %1tensible Mar2up Language Defined b! the LLL Consortium (LDC, Originall! intended as a document markup language not a database language 1he abilit! to specif! ne% tags, and to create nested tag structures made =M9 a great %a! to e#change data, not <ust documents =M9 has become the basis for all ne% generation data interchange formats) A %ide variet! of tools is available for parsing, bro%sing and >uer!ing =M9 documentsJdata #hapter 3( 'elational Model Structure of :elational Databases /undamental :elational;Algebra;Operations Additional :elational;Algebra;Operations 0#tended :elational;Algebra;Operations &ull 5alues Modification of the Database

%1ample of a 'elation

Attribute $ypes 0ach attribute of a relation has a name 1he set of allo%ed values for each attribute is called the domain of the attribute Attribute values are (normall!, re>uired to be atomic3 that is, indivisible o 0)g) the value of an attribute can be an account number, but cannot be a set of account numbers Domain is said to be atomic if all its members are atomic 1he special value null is a member of ever! domain 1he null value causes complications in the definition of man! operations o Le shall ignore the effect of null values in our main presentation and consider their effect later 'elation Schema /ormall!, given domains D@, DB, P) Dn a relation r is a subset of D@ # DB # P # Dn 1hus, a relation is a set of n;tuples (a@, aB, P, an, %here each ai Di

Schema of a relation consists of o attribute definitions name t!peJdomain o integrit! constraints 'elation !nstance 1he current values (relation instance, of a relation are specified b! a table An element t of r is a tuple, represented b! a row in a table Order of tuples is irrelevant (tuples ma! be stored in an arbitrar! order,

Database A database consists of multiple relations $nformation about an enterprise is broken up into parts, %ith each relation storing one part of the information 0)g) account : information about accounts depositor : %hich customer o%ns %hich account customer : information about customers $he customer 'elation $he depositor 'elation

4hy Split !nformation Across 'elations5 Storing all information as a single relation such as bank(account_number, balance, customer_name, )), results in o repetition of information e)g),if t%o customers o%n an account (Lhat gets repeatedM, o the need for null values e)g), to represent a customer %ithout an account &ormali ation theor! (Chapter E, deals %ith ho% to design relational schemas 6eys 9et Q : K is a super2ey of R if values for K are sufficient to identif! a uni>ue tuple of each possible relation r(R)

b! -possible r . %e mean a relation r that could e#ist in the enterprise %e are modeling) o 0#ample: Rcustomer_name, customer_streetS and Rcustomer_nameS are both superke!s of ustomer, if no t%o customers can possibl! have the same name $n real life, an attribute such as customer_id %ould be used instead of customer_name to uni>uel! identif! customers, but %e omit it to keep our e#amples small, and instead assume customer names are uni>ue) K is a candidate 2ey if K is minimal 0#ample: Rcustomer_nameS is a candidate ke! for ustomer, since it is a superke! and no subset of it is a superke!) Primary 2ey( a candidate ke! chosen as the principal means of identif!ing tuples %ithin a relation o Should choose an attribute %hose value never, or ver! rarel!, changes) o 0)g) email address is uni>ue, but ma! change 7oreign 6eys o A relation schema ma! have an attribute that corresponds to the primar! ke! of another relation) 1he attribute is called a foreign 2ey) o 0)g) customer_name and account_number attributes of depositor are foreign ke!s to customer and account respectivel!) o Onl! values occurring in the primar! ke! attribute of the referenced relation ma! occur in the foreign ke! attribute of the referencing relation8 Schema Diagram