Successfully reported this slideshow.

Bro_Ch09.ppt

1,721 views

Published on

  • Be the first to comment

Bro_Ch09.ppt

  1. 1. C H A P T E R 9 Database Structures
  2. 2. 9.1 General Issues <ul><li>Database – data collection </li></ul><ul><li>– “multidimensional”  internal links between entries so info is accessible from number of different perspectives </li></ul><ul><li>Traditional file system – flat file </li></ul><ul><li> – one dimensional  presents data from only one perspective </li></ul>
  3. 3. Integrating data storage systems <ul><li>Organization – number of different departments </li></ul><ul><li>– payroll – accounting – production – sales – purchasing – personnel – etc. </li></ul><ul><li>Each with own purpose or agenda – “silo” </li></ul><ul><li>Each with own file systems </li></ul><ul><li>Imagine – updating an employee’s address </li></ul>
  4. 4. Integrating data storage systems <ul><li>payroll – production / sales / purchasing – personnel </li></ul><ul><li>Update employee’s address – each department’s file </li></ul><ul><li>Each department has own file containing addresses </li></ul><ul><li>Duplication of data </li></ul><ul><li>Entry errors </li></ul><ul><li>Conflicting data </li></ul><ul><li>For a single organization want integrated information stored and maintained in a “single” location </li></ul>
  5. 5. Fig. 9.1: A file versus a database organization Data in “single” location. All access single location. Data now stored for good of company – not for benefit of department only.
  6. 6. Database concepts database administrator (DBA) – administrator (not an executive) - knows data available - knows data organization - accommodates needs of organization and then departments With benefits of data integration comes problems - access to sensitive data News letter editor – has no need to see payroll info Payroll people – have no need to see financial records Personnel – has no need to see strategic plans, etc. Must control access to data
  7. 7. Database concepts Must control access to data – so we develop schemas schema – description of entire database – used by database software to maintain database subschema – description of only a part of database that is pertinent to particular user’s or department’s needs Soooo - subschema definition includes who has access to this part and issue of security is addressed
  8. 8. More database concepts Schema for university <ul><li>Student </li></ul><ul><li>- name </li></ul><ul><li>- addr </li></ul><ul><li>academic data </li></ul><ul><li>faculty advisor </li></ul><ul><li>Faculty member </li></ul><ul><li>- name </li></ul><ul><li>- addr </li></ul><ul><li>employment history </li></ul><ul><li>Payroll </li></ul><ul><li>- employee name </li></ul><ul><li>pay rate </li></ul>Registrar can see student’s advisor but not faculty member’s pay rate Payroll can see faculty member’s pay rate but not students academic data Payroll subschema includes
  9. 9. Problems <ul><li>Great amounts of info can be gathered and reviewed from large </li></ul><ul><li>geographical area </li></ul><ul><li>Misinformation and misapplications </li></ul><ul><li>Injustices </li></ul><ul><ul><li>- inaccurate credit reports </li></ul></ul><ul><ul><li>faulty criminal records </li></ul></ul><ul><ul><li>discrimination due to unauthorized / unethical access to personal info </li></ul></ul><ul><ul><ul><li>- insurance or hiring companies – medical records , etc. </li></ul></ul></ul><ul><li>Who has rights to collect and maintain data? </li></ul><ul><ul><li>Insurance companies - claims - restrict future coverage </li></ul></ul><ul><ul><li>Government – voting records </li></ul></ul><ul><ul><li>Credit card companies – selling customer info to marketing firms </li></ul></ul>
  10. 10. Questions – pg 372
  11. 11. 9.2 Layered Approach to Database Implementation <ul><li>The Database Management System </li></ul><ul><li>Two software layers </li></ul><ul><li>- application layer </li></ul><ul><li>- database management layer </li></ul>
  12. 12. Fig. 9.2: The conceptual layers of a database external view logical view physical view application layer database management layer
  13. 13. The Database Management System <ul><li>Application layer </li></ul><ul><li>Application software communicates with user </li></ul><ul><li> (person or another computer) </li></ul><ul><li>- determines system’s external characteristics </li></ul><ul><li> ( dialog scenario - GUI or text based) </li></ul><ul><li>Application does not directly access database </li></ul>
  14. 14. The Database Management System <ul><li>Database management layer </li></ul><ul><li>Database management system (DBMS) </li></ul><ul><li>- manipulates the database </li></ul><ul><li>- application SW determines what’s needed and </li></ul><ul><li> requests DBMS to accommodate need </li></ul><ul><li>- if add or delete data – DBMS does work </li></ul><ul><li>- if retrieve data – DBMS performs search </li></ul><ul><li>DBMS – abstract tool used by application </li></ul>
  15. 15. The Database Management System <ul><li>Benefits of division of application SW and DBMS </li></ul><ul><li>1. Simplifies application programming with construction and use of abstract tools </li></ul><ul><li>- abstracting  major simplifying SW design concept - application does not have to handle details of file processing </li></ul><ul><li>– no index manipulation, no overflow concern, no pointer updating – </li></ul><ul><li>– no tracking of locations of distributed database data segments – </li></ul><ul><li> all handled by DBMS </li></ul><ul><li>APPLICATION SOFTWARE DESIGN GREATLY SIMPLIFIED </li></ul>
  16. 16. The Database Management System <ul><li>More benefits of separating application SW and DBMS </li></ul><ul><li>#2 - Provides means for controlling access to the database </li></ul><ul><li> - DBMS controls all access – enforces restrictions of schemas </li></ul><ul><li>#3 – separating user interface from actual data manipulation gives </li></ul><ul><li>data independence </li></ul><ul><li>- ability to change database organization without having to </li></ul><ul><li>change application program </li></ul><ul><li>Old flat file example – employee file layout change requires changing application program and file conversion </li></ul><ul><li>DBMS now handles schema and subschema changes </li></ul>
  17. 17. Database models <ul><li>Remember off-the-shelf abstracted stack with push and pop </li></ul><ul><li>DBMS similar concept – has routines to translate application program’s conceptual view commands into data manipulating physical view commands </li></ul><ul><li>Conceptual view  database model </li></ul><ul><li>Application software can be written as if data stored as conceptual view rather than the actual physical storage implementation. </li></ul>
  18. 18. Several models <ul><li>Relational database model </li></ul><ul><li>Object-oriented database model </li></ul>
  19. 19. One model <ul><li>Relational database model </li></ul><ul><ul><li>Conceptual view – data stored as collection of tables with rows and columns </li></ul></ul><ul><ul><li>Company employees viewed as a table </li></ul></ul><ul><ul><ul><li>One row for each employee </li></ul></ul></ul><ul><ul><ul><li>Columns – employee attributes – labeled name, addr, SSNum, etc. </li></ul></ul></ul><ul><ul><li>DBMS routines – abstract tools used by application program </li></ul></ul><ul><ul><li> – select specific entries from a row </li></ul></ul><ul><ul><li>Application programs provide algorithms - BUT </li></ul></ul><ul><ul><li>– DO NOT have operations for manipulating database </li></ul></ul><ul><ul><li>DBMS routines extend capability of original programming language </li></ul></ul><ul><ul><li>– the host language </li></ul></ul><ul><ul><li>Host language (via DBMS) allowed to manipulate database according to the conceptual database model !!! </li></ul></ul>
  20. 20. Questions – page 375
  21. 21. 9.3 The Relational Model <ul><li>Most popular </li></ul><ul><li>Due to simplicity </li></ul><ul><li>Data stored in rectangular tables  relations </li></ul><ul><li>See fig. 9.3 </li></ul>
  22. 22. Fig.9.3: Relation containing employee information unique attribute ? attributes (columns) tuples (rows)
  23. 23. Issues of Relational Design <ul><li>Original design of relational database </li></ul><ul><li>involves design of the relations. </li></ul><ul><li>To employee relation consider adding </li></ul><ul><li>job history </li></ul><ul><li>job identification code </li></ul><ul><li>skill code </li></ul><ul><li>department of each job </li></ul>
  24. 24. Problems induced <ul><li>#1 – lack of efficiency due to redundancy </li></ul><ul><li>#2 - deleting info that causes other info to also be removed </li></ul><ul><li>See Fig. 9.4 </li></ul>
  25. 25. Fig. 9.4a: A relation containing redundancy #1 – lack of efficiency due to redundancy #2 - deleting a tuple may cause other info to be lost Delete Joe E. Baker – what happens to info for job D7? added to employee relation
  26. 26. Fig. 9.4b: A relation containing redundancy Problems all caused by combining more than one concept into a single relation. - Employee info (name, ID, address, SS Num) - Job info (start date, end date) - Info on relationship between employees and jobs added to employee relation
  27. 27. Fig. 9.5: Employee database made with 3 relations ASSIGNMENT relation Empl ID Job ID Start Date Term Date 23Y34 S25X 3-1-1999 4-30-2001 34Y70 F5 10-1-2001 * 23Y34 S25Z 5-1-2001 * - - - - - - - - - - - - Now – only one concept per relation
  28. 28. Fig. 9.6a: Finding the departments in which employee 23Y34 has worked
  29. 29. Fig. 9.6b: Finding the departments in which employee 23Y34 has worked Info available in the one large relation accessible via three small relations without the problems discussed.
  30. 30. Fig. 9.7: A relation and a proposed decomposition May lose data – How would we find employee’s department if more than one department had a job with same title? A decomposition into smaller relations that does NOT lose information is a loss-less decomposition or nonloss decomposition. 25X1 programmer accounting 33Z2 programmer finance 25X1 programmer programmer accounting 33Z2 programmer programmer finance
  31. 31. Fig. 9.8: The SELECT operation find all info about a specific employee SELECT gets rows (tuples)
  32. 32. Fig. 9.9: The PROJECT operation get only specific info (attributes) about all employees PROJECT gets specific columns (attributes)
  33. 33. Operation returns a relation <ul><li>NEW1  SELECT from JOB where JobId = “S25X” </li></ul><ul><li>NEW2  PROJECT JobTitle from NEW1 </li></ul><ul><li>See JOB relation (Fig. 9.5, pg. 378) – what do we get? </li></ul><ul><li>NEW1 and NEW2 relations are created </li></ul><ul><li>What does NEW1 “look” like? </li></ul><ul><li>What’s in NEW2? </li></ul>
  34. 34. Fig. 9.10: The JOIN operation JOIN combines two relations into one new relation Attributes of new relation C are all attributes from relations A & B where A.W = B.X
  35. 35. Fig. 9.11: Another example of the JOIN operation Attributes of new relation C are all attributes from relations A & B where A.W < B.X
  36. 36. Fig. 9.12a: An application of the JOIN operation List all employee Id with departments where they work NEW1  JOIN ASSIGNMENT and JOB where ASSIGNMENT.JobId = JOB.JobId
  37. 37. Fig. 9.12b: An application of the JOIN operation NEW2  SELECT from NEW1 where ASSIGNMENT.TermDate = “ * ” ASSIGNMENT EmplID JobID StartDate TermDate JobId JobTitle SkillCode Dept 34Y70 F5 10-1-2001 * F5 Floor manager FM3 Sales 25X15 S26Z 5-1-2001 * S26Z Secretary T6 Accounting ASSIGNMENT ASSIGNMENT ASSIGNMENT JOB JOB JOB JOB LIST  PROJECT ASSIGNMENT.EmplId, JOB.Dept from NEW2 List all employee Id with departments where they work ASSIGNMENT EmplID Dept 34Y70 Sales 25X15 Accounting JOB LIST relation NEW2 relation
  38. 38. Implementation Issues – relational DBMS <ul><li>Details of manipulating files handled by DBSM </li></ul><ul><li>Application software written in terms of relational model </li></ul><ul><li>DBMS accepts commands from host program & converts to manipulate data as it’s physically stored </li></ul><ul><li>Application programs written as if data stored as tables </li></ul>
  39. 39. Implementation Issues <ul><li>Application programs written as if data stored as tables </li></ul><ul><li>and </li></ul><ul><li>DBMS relates to each tuple as a logical record </li></ul><ul><li>SELECT operation implies sequential search but </li></ul><ul><li>– DBMS does indexing or hashing </li></ul><ul><li>Data structures and file structures fundamentals are building blocks of DBMS </li></ul>
  40. 40. SQL – Structured Query Language <ul><li>SQL – application programmers use to create, access, modify relational database </li></ul><ul><li>Standardized – by ANSI </li></ul><ul><li>SQL actually declarative statements  describe information desired (not sequence of commands) </li></ul><ul><li>So how are relational operations SELECT, PROJECT, & JOIN performed in SQL? </li></ul>
  41. 41. From relational operation to SQL statements <ul><li>How are relational operations SELECT, PROJECT, & JOIN performed in SQL? </li></ul>NEW1  JOIN ASSIGNMENT and JOB where ASSIGNMENT.JobId = JOB.JobId NEW2  SELECT from NEW1 where ASSIGNMENT.TermDate = “ * ” LIST  PROJECT ASSIGNMENT.EmplId, JOB.Dept from NEW2 SQL statements select EmplId, Dept from ASSIGNMENT, JOB where ASSIGNMENT.JobId = JOB.JobId and ASSIGNMENT.TermDate = ‘*’
  42. 42. Relational operation – SQL statements select EmplId, Dept select clause  PROJECT operation from ASSIGNMENT, JOB from clause  JOIN operation where ASSIGNMENT.JobId = JOB.JobId where clause  and ASSIGNMENT.TermDate = ‘*’ SELECT operation NEW1  JOIN ASSIGNMENT and JOB where ASSIGNMENT.JobId = JOB.JobId NEW2  SELECT from NEW1 where ASSIGNMENT.TermDate = “ * ” LIST  PROJECT ASSIGNMENT.EmplId, JOB.Dept from NEW2
  43. 43. More SQL examples select EmplId, Name, Address, SSNum SELECT operation from EMPLOYEE where Name = ‘Cheryl H. Clark’ select Name, Address PROJECT operation from EMPLOYEE select Name, Address combined from EMPLOYEE SELECT and where Name = ‘Cheryl H. Clark’ PROJECT operation
  44. 44. More SQL select EMPLOYEE.Name, ASSIGNMENT.StartDate  PROJECTing from EMPLOYEE, ASSIGNMENT  JOINing where EMPLOYEE.EmplId = ASSIGNMENT.EmplId  SELECTing
  45. 45. SQL statement provide SQL statements for - defining relational structures - creating relations - modifying relations - querying (as we have seen) insert into EMPLOYEE  adds a tuple values (’42Z12’, ‘Sue A. Burt’, ’33 Fair St.’, ‘444661111’) delete from EMPLOYEE  removes a tuple where Name = ‘G. Jerry Smith’ update EMPLOYEE  modify tuple’s attributes set Address = ‘1812 Napoleon Ave.’ where Name = ‘Joe E. Baker’
  46. 46. Questions – page 387
  47. 47. 9.4 Object-Oriented Databases <ul><li>O-O databases – objects linked together to reflect their relationship </li></ul>All assignments of an employee can be found by following links from object representing that employee.
  48. 48. Object-Oriented Databases tasks: <ul><ul><li>provide links via pointers </li></ul></ul><ul><ul><li>provide permanent storage </li></ul></ul><ul><ul><li>(Remember object persistence via file storage?) </li></ul></ul>
  49. 49. Object-Oriented Databases advantages: <ul><ul><li>Allows application and database to use the same OO paradigm </li></ul></ul><ul><ul><li>(clash between imperative and relational paradigm - source of software errors) </li></ul></ul><ul><ul><li>OO allows methods to be stored with data </li></ul></ul><ul><ul><li>(consider names not in first-name, middle-name, last-name configuration -- extract as needed.) </li></ul></ul><ul><ul><li>Data types permeate entire system – host app. and database – (actually now one system  OO database) </li></ul></ul><ul><ul><li>OO allows storing intelligent data types (data with methods) </li></ul></ul>
  50. 50. 9.5 Maintaining Database Integrity <ul><li>Small database on PC vs HUMONGOUS database on WHOPPER systems </li></ul><ul><li>cost of losing data – small vs huge </li></ul><ul><li>major role of DBMS  maintain database’s integrity </li></ul><ul><ul><li>operation partially completed </li></ul></ul><ul><ul><li>different operations interact detrimentally </li></ul></ul>
  51. 51. Database Integrity <ul><li>maintain database’s integrity </li></ul><ul><ul><li>operation partially completed </li></ul></ul><ul><ul><li>different operations interact detrimentally </li></ul></ul><ul><ul><li>Example – transfer of funds from one bank account to another </li></ul></ul><ul><li>SAV1 </li></ul><ul><li>$5000 </li></ul><ul><li>____ </li></ul><ul><li>$5000 </li></ul>$1000 SAV2 $2000 + 1000 $3000 woops!
  52. 52. More on Database Integrity <ul><li>Maintain database’s integrity with: </li></ul><ul><ul><li>Commit points – after a commit point, log what is to be done in non-volatile storage (on disk) </li></ul></ul><ul><ul><li>Roll back to commit point to correct errors </li></ul></ul><ul><ul><li>Cascading roll back – correct all other adversely affected transactions that occurred since last commit point </li></ul></ul><ul><ul><li>Locking – locking protocols  shared locks – exclusive locks </li></ul></ul><ul><ul><ul><li>incorrect summary problem – our bank money transfer </li></ul></ul></ul><ul><ul><ul><li>lost update problem – two transactions update same account -- trans#1 updates then trans#2 writes over #1’s update </li></ul></ul></ul><ul><li>SAV1 </li></ul><ul><li>$5000 </li></ul><ul><li>____ </li></ul><ul><li>$5000 </li></ul>$1000 SAV2 $2000 + 1000 $3000
  53. 53. Data Mining <ul><li>Statistics and probability – to “mine” information from the tremendous piles of data </li></ul><ul><li>Management of grocery chain – valuable to know that buyers of snack food also buy frozen dinners </li></ul><ul><li>Non-obvious, valuable info may be discovered </li></ul>
  54. 54. 9.6 Social Impact of Database Technology <ul><li>Data collections now not dormant, passive entities </li></ul><ul><ul><li>manual library check-out system </li></ul></ul><ul><ul><li>automated, database related check-out system </li></ul></ul><ul><ul><li>Who knows about what you read? How may they use the info? </li></ul></ul><ul><ul><li>Otherwise obscure data now able to be related! </li></ul></ul><ul><ul><li>What can be divulged about you? </li></ul></ul><ul><ul><li>Data readily shared. </li></ul></ul><ul><ul><li>Privacy issues serious regarding accurate data – what about when information contains errors? </li></ul></ul>
  55. 55. Questions – page 396
  56. 56. See social issues - page 366 - page 400

×