This action might not be possible to undo. Are you sure you want to continue?
Chapter 1: Introduction
• • • • • • • • • Purpose of Database Systems Database Languages Relational Databases Database Design Data Models Database Internals Database Users and dministrators !"erall Structure #istory of Database Systems
Database Management System $D%MS&
• D%MS contains information about a particular enterprise – Collection of interrelated data – Set of programs to access the data – • n en"ironment that is both convenient and efficient to use Database pplications: – %an'ing: all transactions – irlines: reser"ations( schedules – Uni"ersities: registration( grades – Sales: customers( products( purchases – !nline retailers: order trac'ing( customi)ed recommendations – Manufacturing: production( in"entory( orders( supply chain – #uman resources: employee records( salaries( ta* deductions • Databases touch all aspects of our li"es
eed to +rite a ne+ program to carry out each ne+ tas' – Data isolation .g.Purpose of Database Systems • • In the early days( database applications +ere built directly on top of file systems Dra+bac's of using file systems to store data: – Data redundancy and inconsistency • Multiple file formats( duplication of information in different files – Difficulty in accessing data • .multiple files and formats – Integrity problems • Integrity constraints $e. account balance / 0& become 1buried2 in program code rather than being stated e*plicitly • #ard to add ne+ constraints or change e*isting ones .
& • Dra+bac's of using file systems $cont.Purpose of Database Systems $Cont.& – tomicity of updates • 3ailures may lea"e database in an inconsistent state +ith partial updates carried out • 4*ample: 5ransfer of funds from one account to another should either complete or not happen at all – Concurrent access by multiple users • Concurrent accessed needed for performance • Uncontrolled concurrent accesses can lead to inconsistencies – 4*ample: 5+o people reading a balance and updating it at the same time – Security problems • #ard to pro"ide user access to some( but not all( data • Database systems offer solutions to all the abo"e problems .
( customer& is stored.Le"els of bstraction • • Physical level: describes ho+ a record $e.g. 9ie+s can also hide information $such as an employee:s salary& for security purposes. type customer 6 record customer_id : string7 customer_name : string7 customer8street : string7 customer_city : string7 • end7 View level: application programs hide details of data types. Logical level: describes data stored in database( and the relationships among the data. .
9ie+ of Data An architecture for a database system .
the actual content of the database at a particular point in time – • nalogous to the "alue of a "ariable Physical Data Independence . .Instances and Schemas • • Similar to types and "ariables in programming languages Schema . the ability to modify the physical schema +ithout changing the logical schema – pplications depend on the logical schema – In general( the interfaces bet+een the "arious le"els and components should be +ell defined so that changes in some parts do not seriously influence others. the logical structure of the database – 4*ample: 5he database consists of information about a set of customers and accounts and the relationship bet+een them& – nalogous to type information of a "ariable in a program – Physical schema: database design at the physical le"el – Logical schema: database design at the logical le"el • Instance .
et+or' model Relational model .Data Models #ierarchical model .
#I4R RC#IC L M!D4L • • • • • !ne of the oldest data model 5ree li'e structure !ne of the hierarchical database model is IMS !rgani)es the data in the tabular ro+s Different operation +ere:< – Insert – Update – Delete – Retrie"al of data .
d"antages • simlicity • Data integrity • 4fficiency .
Disad"antages • Implementation comple*ity • Lac' of structural independency • Implementation limitations • Program comple*ity .
et+or' model replaces the hierarchical tree +ith a graph ble to handle different relations !peration :< – Insert – Update – Dalete – Retrie"al ..et+or' • • • .
ad"antages • Capable to handle different relationships • 4ase in data access • Data integrity • Database standards • Data independence .
disad"antages • System comple*ity • !perational anomalies • bsence of structural independence .
Relational Model • 4*ample of tabular data in the relational model Attributes .
Sample Relational Database .
5he 4ntity<Relationship Model • Models an enterprise as a collection of entities and relationships – 4ntity: a 1thing2 or 1ob=ect2 in the enterprise that is distinguishable from other ob=ects • Described by a set of attributes – Relationship: an association among se"eral entities • Represented diagrammatically by an entity-relationship diagram: .
!ther Data Models • • !b=ect<oriented data model !b=ect<relational data model .
!b=ect<Relational Data Models • • • • 4*tend the relational data model by including ob=ect orientation and constructs to deal +ith added data types. . llo+ attributes of tuples to ha"e comple* types( including non<atomic "alues such as nested relations. Pro"ide up+ard compatibility +ith e*isting relational languages. Preser"e relational foundations( in particular the declarati"e access to data( +hile e*tending modeling po+er.
• DML<modify( insert(delete(retri"e • DCL<C!MMI5(R!LL % C> • DDL<Create(alter(drop(grant .
user specifies +hat data is re?uired +ithout specifying ho+ to get those data • S@L is the most +idely used ?uery language .Data Manipulation Language $DML& • Language for accessing and manipulating the data organi)ed by the appropriate data model – DML also 'no+n as ?uery language • 5+o classes of languages – Procedural . user specifies +hat data is re?uired and ho+ to get those data – Declarative (nonprocedural) .
account_number • pplication programs generally access databases through one of – Language e*tensions to allo+ embedded S@L – pplication program interface $e.balance from depositor( account where depositor.account_number = account.customer_name from customer where customer.g.customer_id 6 I1AB<CD<EFGH: – 4*ample: 3ind the balances of all accounts held by the customer +ith customer<id 1AB<CD<EFGH select account.( !D%CJKD%C& +hich allo+ S@L ?ueries to be sent to a database .customer_id 6 I1AB<CD<EFGH: and depositor.S@L • SQL: +idely used non<procedural language – 4*ample: 3ind the name of the customer +ith customer<id 1AB<CD<EFGH select customer.
+ide "ariety of tools is a"ailable for parsing( bro+sing and ?uerying LML documentsJdata .• • • • • LML: 4*tensible Mar'up Language Defined by the MMM Consortium $MDC& !riginally intended as a document mar'up language not a database language 5he ability to specify ne+ tags( and to create nested tag structures made LML a great +ay to e*change data( not =ust documents LML has become the basis for all ne+ generation data interchange formats.
Database design re?uires that +e find a 1good2 collection of relation schemas. Deciding on the physical layout of the database .Database Design 5he process of designing the general structure of the database: • Logical Design . Deciding on the database schema. – %usiness decision . Mhat relation schemas should +e ha"e and ho+ should the attributes be distributed among the "arious relation schemasN • Physical Design . Mhat attributes should +e record in the databaseN – Computer Science decision .
Data Independence • the ability to modify the schema +ithout changing the other schema – In general( the interfaces bet+een the "arious le"els and components should be +ell defined so that changes in some parts do not seriously influence others. • Logical data independence:<indicate that logical schema can be changed +ithout affecting the e*ternalJ"ie+ schema . 5he physical data independence is achie"ed by the mapping from logical to physical le"el. .this may re?uire a change in the "ie+Jlogical mapping as it lea"e the "ie+ schema unchanged.the logical data Independence also insulates application programs from operations such as combining t+o records into one or splitting an e*isting record into t+o or more records. • Physical data independence7<indicates that the physical storage structure or de"ice can be changed +ithout affecting logical schema.
Database pplication rchitectures (web browser) Old Modern .
Database Management System Internals • • • Storage management @uery processing 5ransaction processing .
Storage Management • Storage manager is a program module that pro"ides the interface bet+een the lo+<le"el data stored in the database and the application programs and ?ueries submitted to the system. 5he storage manager is responsible to the follo+ing tas's: – Interaction +ith the file manager – 4fficient storing( retrie"ing and updating of data • Issues: – Storage access – 3ile organi)ation – Inde*ing and hashing • .
Parsing and translation B. 4"aluation .@uery Processing 1. !ptimi)ation D.
"oncurrency!control manager controls the interaction among the concurrent transactions( to ensure the consistency of the database.( po+er failures and operating system crashes& and transaction failures.g.5ransaction Management • • 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 system failures $e. • .
!"erall System Structure .
et+or' and hierarchical data models in +idespread use – 5ed Codd defines the relational data model • Mould +in the CM 5uring +ard for this +or' • I%M Research begins System R prototype • UC %er'eley begins Ingres prototype – #igh<performance $for the era& transaction processing .#istory of Database Systems • 1AH0s and early 1AG0s: – Data processing using magnetic tapes for storage • 5apes pro"ide only se?uential access – Punched cards for input • Late 1AG0s and 1AE0s: – #ard dis's allo+ direct access to data – .
& • 1AC0s: – Research relational prototypes e"ol"e into commercial systems • S@L becomes industry standard – Parallel and distributed database systems – !b=ect<oriented database systems • 1AA0s: – Large decision support and data<mining applications – Large multi<terabyte data +arehouses – 4mergence of Meb commerce • B000s: – LML and L@uery standards – utomated database administration – Increasing use of highly parallel database systems .#istory $cont.
+rite speciali)ed database applications that do not fit into the traditional data processing frame+or' &a've users . interact +ith system through DML calls Sophisticated users . form re?uests in a database ?uery language Speciali%ed users .Database Users #sers are differentiated by the +ay they e*pect to interact +ith the system • • • • $pplication programmers . in"o'e one of the permanent application programs that ha"e been +ritten pre"iously – 4*amples( people accessing database o"er the +eb( ban' tellers( clerical staff .
• Database administratorOs duties include: – Storage structure and access method definition – Pranting users authority to access the database – %ac'ing up data – Monitoring performance and responding to changes • Database tuning .Database dministrator • Coordinates all the acti"ities of the database system – has a good understanding of the enterprise:s information resources and needs.
Database rchitecture 5he architecture of a database systems is greatly influenced by the underlying computer system on +hich the database is running: • • • • Centrali)ed Client<ser"er Parallel $multiple processors and dis's& Distributed .
F .3igure 1.
3igure 1.E .
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue listening from where you left off, or restart the preview.