Your SlideShare is downloading. ×
0
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Bro_Ch09.ppt
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Bro_Ch09.ppt

1,486

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,486
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
23
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. C H A P T E R 9 Database Structures
  • 2. 9.1 General Issues
    • Database – data collection
    • – “multidimensional”  internal links between entries so info is accessible from number of different perspectives
    • Traditional file system – flat file
    • – one dimensional  presents data from only one perspective
  • 3. Integrating data storage systems
    • Organization – number of different departments
    • – payroll – accounting – production – sales – purchasing – personnel – etc.
    • Each with own purpose or agenda – “silo”
    • Each with own file systems
    • Imagine – updating an employee’s address
  • 4. Integrating data storage systems
    • payroll – production / sales / purchasing – personnel
    • Update employee’s address – each department’s file
    • Each department has own file containing addresses
    • Duplication of data
    • Entry errors
    • Conflicting data
    • For a single organization want integrated information stored and maintained in a “single” location
  • 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. 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. 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. More database concepts Schema for university
    • Student
    • - name
    • - addr
    • academic data
    • faculty advisor
    • Faculty member
    • - name
    • - addr
    • employment history
    • Payroll
    • - employee name
    • pay rate
    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. Problems
    • Great amounts of info can be gathered and reviewed from large
    • geographical area
    • Misinformation and misapplications
    • Injustices
      • - inaccurate credit reports
      • faulty criminal records
      • discrimination due to unauthorized / unethical access to personal info
        • - insurance or hiring companies – medical records , etc.
    • Who has rights to collect and maintain data?
      • Insurance companies - claims - restrict future coverage
      • Government – voting records
      • Credit card companies – selling customer info to marketing firms
  • 10. Questions – pg 372
  • 11. 9.2 Layered Approach to Database Implementation
    • The Database Management System
    • Two software layers
    • - application layer
    • - database management layer
  • 12. Fig. 9.2: The conceptual layers of a database external view logical view physical view application layer database management layer
  • 13. The Database Management System
    • Application layer
    • Application software communicates with user
    • (person or another computer)
    • - determines system’s external characteristics
    • ( dialog scenario - GUI or text based)
    • Application does not directly access database
  • 14. The Database Management System
    • Database management layer
    • Database management system (DBMS)
    • - manipulates the database
    • - application SW determines what’s needed and
    • requests DBMS to accommodate need
    • - if add or delete data – DBMS does work
    • - if retrieve data – DBMS performs search
    • DBMS – abstract tool used by application
  • 15. The Database Management System
    • Benefits of division of application SW and DBMS
    • 1. Simplifies application programming with construction and use of abstract tools
    • - abstracting  major simplifying SW design concept - application does not have to handle details of file processing
    • – no index manipulation, no overflow concern, no pointer updating –
    • – no tracking of locations of distributed database data segments –
    • all handled by DBMS
    • APPLICATION SOFTWARE DESIGN GREATLY SIMPLIFIED
  • 16. The Database Management System
    • More benefits of separating application SW and DBMS
    • #2 - Provides means for controlling access to the database
    • - DBMS controls all access – enforces restrictions of schemas
    • #3 – separating user interface from actual data manipulation gives
    • data independence
    • - ability to change database organization without having to
    • change application program
    • Old flat file example – employee file layout change requires changing application program and file conversion
    • DBMS now handles schema and subschema changes
  • 17. Database models
    • Remember off-the-shelf abstracted stack with push and pop
    • DBMS similar concept – has routines to translate application program’s conceptual view commands into data manipulating physical view commands
    • Conceptual view  database model
    • Application software can be written as if data stored as conceptual view rather than the actual physical storage implementation.
  • 18. Several models
    • Relational database model
    • Object-oriented database model
  • 19. One model
    • Relational database model
      • Conceptual view – data stored as collection of tables with rows and columns
      • Company employees viewed as a table
        • One row for each employee
        • Columns – employee attributes – labeled name, addr, SSNum, etc.
      • DBMS routines – abstract tools used by application program
      • – select specific entries from a row
      • Application programs provide algorithms - BUT
      • – DO NOT have operations for manipulating database
      • DBMS routines extend capability of original programming language
      • – the host language
      • Host language (via DBMS) allowed to manipulate database according to the conceptual database model !!!
  • 20. Questions – page 375
  • 21. 9.3 The Relational Model
    • Most popular
    • Due to simplicity
    • Data stored in rectangular tables  relations
    • See fig. 9.3
  • 22. Fig.9.3: Relation containing employee information unique attribute ? attributes (columns) tuples (rows)
  • 23. Issues of Relational Design
    • Original design of relational database
    • involves design of the relations.
    • To employee relation consider adding
    • job history
    • job identification code
    • skill code
    • department of each job
  • 24. Problems induced
    • #1 – lack of efficiency due to redundancy
    • #2 - deleting info that causes other info to also be removed
    • See Fig. 9.4
  • 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. 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. 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. Fig. 9.6a: Finding the departments in which employee 23Y34 has worked
  • 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. 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. Fig. 9.8: The SELECT operation find all info about a specific employee SELECT gets rows (tuples)
  • 32. Fig. 9.9: The PROJECT operation get only specific info (attributes) about all employees PROJECT gets specific columns (attributes)
  • 33. Operation returns a relation
    • NEW1  SELECT from JOB where JobId = “S25X”
    • NEW2  PROJECT JobTitle from NEW1
    • See JOB relation (Fig. 9.5, pg. 378) – what do we get?
    • NEW1 and NEW2 relations are created
    • What does NEW1 “look” like?
    • What’s in NEW2?
  • 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. 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. 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. 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. Implementation Issues – relational DBMS
    • Details of manipulating files handled by DBSM
    • Application software written in terms of relational model
    • DBMS accepts commands from host program & converts to manipulate data as it’s physically stored
    • Application programs written as if data stored as tables
  • 39. Implementation Issues
    • Application programs written as if data stored as tables
    • and
    • DBMS relates to each tuple as a logical record
    • SELECT operation implies sequential search but
    • – DBMS does indexing or hashing
    • Data structures and file structures fundamentals are building blocks of DBMS
  • 40. SQL – Structured Query Language
    • SQL – application programmers use to create, access, modify relational database
    • Standardized – by ANSI
    • SQL actually declarative statements  describe information desired (not sequence of commands)
    • So how are relational operations SELECT, PROJECT, & JOIN performed in SQL?
  • 41. From relational operation to SQL statements
    • How are relational operations SELECT, PROJECT, & JOIN performed in SQL?
    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. 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. 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. More SQL select EMPLOYEE.Name, ASSIGNMENT.StartDate  PROJECTing from EMPLOYEE, ASSIGNMENT  JOINing where EMPLOYEE.EmplId = ASSIGNMENT.EmplId  SELECTing
  • 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. Questions – page 387
  • 47. 9.4 Object-Oriented Databases
    • O-O databases – objects linked together to reflect their relationship
    All assignments of an employee can be found by following links from object representing that employee.
  • 48. Object-Oriented Databases tasks:
      • provide links via pointers
      • provide permanent storage
      • (Remember object persistence via file storage?)
  • 49. Object-Oriented Databases advantages:
      • Allows application and database to use the same OO paradigm
      • (clash between imperative and relational paradigm - source of software errors)
      • OO allows methods to be stored with data
      • (consider names not in first-name, middle-name, last-name configuration -- extract as needed.)
      • Data types permeate entire system – host app. and database – (actually now one system  OO database)
      • OO allows storing intelligent data types (data with methods)
  • 50. 9.5 Maintaining Database Integrity
    • Small database on PC vs HUMONGOUS database on WHOPPER systems
    • cost of losing data – small vs huge
    • major role of DBMS  maintain database’s integrity
      • operation partially completed
      • different operations interact detrimentally
  • 51. Database Integrity
    • maintain database’s integrity
      • operation partially completed
      • different operations interact detrimentally
      • Example – transfer of funds from one bank account to another
    • SAV1
    • $5000
    • ____
    • $5000
    $1000 SAV2 $2000 + 1000 $3000 woops!
  • 52. More on Database Integrity
    • Maintain database’s integrity with:
      • Commit points – after a commit point, log what is to be done in non-volatile storage (on disk)
      • Roll back to commit point to correct errors
      • Cascading roll back – correct all other adversely affected transactions that occurred since last commit point
      • Locking – locking protocols  shared locks – exclusive locks
        • incorrect summary problem – our bank money transfer
        • lost update problem – two transactions update same account -- trans#1 updates then trans#2 writes over #1’s update
    • SAV1
    • $5000
    • ____
    • $5000
    $1000 SAV2 $2000 + 1000 $3000
  • 53. Data Mining
    • Statistics and probability – to “mine” information from the tremendous piles of data
    • Management of grocery chain – valuable to know that buyers of snack food also buy frozen dinners
    • Non-obvious, valuable info may be discovered
  • 54. 9.6 Social Impact of Database Technology
    • Data collections now not dormant, passive entities
      • manual library check-out system
      • automated, database related check-out system
      • Who knows about what you read? How may they use the info?
      • Otherwise obscure data now able to be related!
      • What can be divulged about you?
      • Data readily shared.
      • Privacy issues serious regarding accurate data – what about when information contains errors?
  • 55. Questions – page 396
  • 56. See social issues - page 366 - page 400

×