Data and Data Administration


Published on

1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Need top management support for data administrator function. Will also develop standards of operation and determine performance measures. Job is more managerial than technical. DB planning organizing and staffing communicating with managers and end-users
  • Annual losses for computer abuse at $500 million in US
  • Mechanisms for restoring a DB quickly and accurately after loss or damage Backups made at least once a day. Stored offsite Journalizing: transaction log which contains record of data processed in transaction and change log which contains before and after images of records Checkpoint: prefer automatic checkpointing (each hour) Recovery mgr: different recovery and restart procedures
  • Forward Recovery over Restore Do not have to rerun each transaction which takes time Only the most recent afterimages have to be applied Don’t have out of sequencing problems
  • Locking level: extent (granularity) to which the database resource is included within a lock Block/page: Not used because a page may contain records of multiple types Record: Imposes overhead when multiple records must be updated. Also leaves most of DB available to other users. Field: appropriate when an update only affects one or two fields. Require considerable overhead to locate and lock fields and therefore, are rarely used.
  • Example: Lock record X Lock record Y Request record Y (denied) Request record X (denied) Wait for Y Wait for X Prevention: all records must be locked prior to transaction beginning. Typically not practical to know/access those records. Resolution: Deadlocks occur but DBMS detects and breaks
  • Versioning improves performance over locking as read only transactions can run concurrently with updating transactions.
  • Data and Data Administration

    1. 1. Chapter 13 Data and Database Administration
    2. 2. SDLC and the database development process SDLC Database Deliverable Project ID Project init Analysis Logical design Physical design Implementation Maintenance Enterprise model Conceptual Model Logical model Data structures and storage plan Management Working system
    3. 3. <ul><li>Proper delivery of information not only depends on the capabilities of the computer hardware and software but also on the organization’s ability to manage data as an important resource </li></ul>
    4. 4. How Does IS Manage Data? <ul><li>Data Administrators : A high-level function that is responsible for the overall management of data resources in an organization, including maintaining corporate-wide definitions and standards. </li></ul><ul><li>Database Administrators : A technical function that is responsible for physical database design and for dealing with technical issues such as security enforcement, database performance, and backup and recovery. </li></ul><ul><li>Data Stewardship: Manages a specific logical data resource for all business functions. Distribute data admin. to those most knowledgeable about specific data </li></ul>
    5. 5. Data Administration Functions <ul><li>Data policies, procedures, standards </li></ul><ul><li>Planning </li></ul><ul><li>Data conflict (ownership) resolution </li></ul><ul><li>Internal marketing of DA concepts </li></ul><ul><li>Managing the data repository </li></ul>
    6. 6. Database Administration Functions <ul><li>Selection of hardware and software </li></ul><ul><li>Managing data security, privacy, and integrity </li></ul><ul><li>Data backup and recovery </li></ul><ul><li>Fig. 13-1 is a list of DA and DBA functions </li></ul>
    7. 7. Threats to Data Security <ul><li>Accidental losses attributable to: </li></ul><ul><ul><li>Human error. </li></ul></ul><ul><ul><li>Software failure. </li></ul></ul><ul><ul><li>Hardware failure. </li></ul></ul><ul><li>Theft and fraud. </li></ul><ul><li>Improper data access: </li></ul><ul><ul><li>Loss of privacy (personal data). </li></ul></ul><ul><ul><li>Loss of confidentiality (corporate data). </li></ul></ul><ul><li>Loss of data integrity. </li></ul><ul><li>Loss of availability (through, e.g. sabotage). </li></ul>
    8. 8. Possible locations of data security threats
    9. 9. Database Security Features <ul><li>Protection of the database against accidental or intentional loss, destruction or misuse </li></ul><ul><ul><li>Views </li></ul></ul><ul><ul><li>Authorization rules </li></ul></ul><ul><ul><li>User-defined procedures </li></ul></ul><ul><ul><li>Encryption procedures </li></ul></ul><ul><ul><li>Authentication schemes </li></ul></ul>
    10. 10. Database Security Features <ul><li>Views </li></ul><ul><ul><li>Restrict user access to data </li></ul></ul><ul><ul><li>Various ways to get around so not sufficient measure </li></ul></ul><ul><li>Authorization Rules </li></ul><ul><ul><li>Controls embedded in DBMS that restrict user access to data and user actions that can be enacted on data </li></ul></ul><ul><ul><ul><li>Who can update? Insert? Read? </li></ul></ul></ul>
    11. 11. Authorization matrix
    12. 12. Database Security Features <ul><li>User-Defined Procedures </li></ul><ul><ul><li>Allows system designers to add other security features </li></ul></ul><ul><ul><ul><li>Passwords </li></ul></ul></ul><ul><ul><ul><li>Valid procedure name </li></ul></ul></ul><ul><li>Encryption </li></ul><ul><ul><li>Coding of data so that it cannot be read by humans </li></ul></ul><ul><ul><ul><li>Financial and military data </li></ul></ul></ul><ul><ul><ul><li>WWW issues </li></ul></ul></ul><ul><ul><ul><li>Government ability to decode all encryption schemes </li></ul></ul></ul>
    13. 13. Database Security Features <ul><li>Authentication Schemes </li></ul><ul><ul><li>How to positively identify that person trying to gain access to a computer resource is “that” person </li></ul></ul><ul><ul><ul><li>Biometric devices--measure fingerprints, voice prints, retina prints </li></ul></ul></ul><ul><ul><ul><li>Smart card would have biometric data embedded </li></ul></ul></ul>
    14. 14. Database Failures <ul><li>Aborted Transactions </li></ul><ul><ul><li>A transaction is not completed </li></ul></ul><ul><li>Incorrect Data </li></ul><ul><ul><li>data entry error, calculation error, coding error </li></ul></ul><ul><li>System Failure </li></ul><ul><ul><li>Component failure, power failure </li></ul></ul><ul><li>Database Destruction </li></ul><ul><ul><li>drive failure, disaster recovery </li></ul></ul>
    15. 15. Database Recovery and Basic Recovery Facilities <ul><li>Backup facilities </li></ul><ul><ul><ul><li>Periodic backup copies of entire DB </li></ul></ul></ul><ul><li>Journalizing facilities </li></ul><ul><ul><ul><li>Maintain an audit trail of transactions and DB changes </li></ul></ul></ul><ul><li>Checkpoint facilities </li></ul><ul><ul><ul><li>DBMS suspends all processing and synchronizes files and journals </li></ul></ul></ul><ul><li>Recovery manager </li></ul><ul><ul><ul><li>Allows the DBMS to restore the DB to correct condition and restart </li></ul></ul></ul>
    16. 16. Recovery and Restart Procedures <ul><li>Restore/Rerun </li></ul><ul><ul><li>Reprocess the day’s transactions up to the point of failure against a backup copy of the database </li></ul></ul><ul><ul><li>Simple </li></ul></ul><ul><ul><li>Time to reprocess may be prohibitive </li></ul></ul><ul><ul><li>Sequencing of transactions may be different than when originally run </li></ul></ul><ul><ul><ul><li>withdrawal posted prior to deposit </li></ul></ul></ul>
    17. 17. Recovery and Restart Procedures <ul><li>Transaction Integrity </li></ul><ul><ul><li>Transaction changes are not made to the DB until the entire transaction has been completed and the changes are committed </li></ul></ul><ul><ul><li>If transaction fails at any point, the transaction is aborted </li></ul></ul>
    18. 18. Recovery and Restart Procedures <ul><li>Backward Recovery (Rollback) </li></ul><ul><ul><li>Back out of unwanted changes to the database </li></ul></ul><ul><ul><li>Used to reverse the changes that have been made to transactions that have been aborted </li></ul></ul><ul><li>Forward Recovery (Rollforward) </li></ul><ul><ul><li>Use an earlier copy of the DB and apply after images of good transactions </li></ul></ul><ul><ul><li>More accurate and faster than restore/rerun </li></ul></ul>
    19. 19. Basic recovery techniques (a) Rollback
    20. 20. (b) Rollforward
    21. 21. Concurrency Control <ul><li>Concerns with preventing loss of data integrity due to interference between users in a multi-user environment </li></ul><ul><ul><li>Pessimistic approach: interference will always occur so we LOCK records </li></ul></ul><ul><ul><li>Optimistic approach: interference will rarely occur so we VERSION records </li></ul></ul><ul><li>Multiple concurrent updates to a database can lead to lost updates and therefore to errors </li></ul>
    22. 22. Lost Update Example Time John Read account Balance (balance = $1,000) . . . Withdraw $200 (balance = $800 . . . Write account balance (balance = $800) Marsha Read account balance (balance = $1,000) . . . Withdraw $300 (balance = $700) . . . Write account balance (balance = $700) ERROR
    23. 23. Locking <ul><li>Deny access of data to other users while an update is underway </li></ul><ul><li>Locking level (granularity) </li></ul><ul><ul><li>Database - during backups </li></ul></ul><ul><ul><li>Table - during batch updates </li></ul></ul><ul><ul><li>Block or page - generally not used </li></ul></ul><ul><ul><li>Record - Often used </li></ul></ul><ul><ul><li>Field - Useful when only one field is likely to change </li></ul></ul>
    24. 24. Types of Locks <ul><li>Shared </li></ul><ul><ul><li>Allows others to read, but not write </li></ul></ul><ul><ul><li>Prevents others from putting Exclusive lock on the record </li></ul></ul><ul><li>Exclusive </li></ul><ul><ul><li>Denies other access to the record (even read) </li></ul></ul><ul><ul><li>Necessary when updating the record </li></ul></ul>
    25. 25. Deadlock (aka: Deadly Embrace) <ul><li>Two or more transactions have placed locks on record(s) that the others need. </li></ul><ul><li>Each waits for the other(s) to release </li></ul><ul><li>Requires DBMS intervention </li></ul><ul><ul><li>Prevention, often not practical </li></ul></ul><ul><ul><li>Resolution, common solution </li></ul></ul><ul><ul><ul><li>Detects deadlock and backs one or more transactions out, lets one finish, then restarts next transaction. </li></ul></ul></ul>
    26. 26. Versioning <ul><li>Each transaction is restricted to a view of the database as of the transaction start time. </li></ul><ul><li>When transaction modifies a record, the DBMS creates a new version of record instead of overwriting old record </li></ul><ul><li>Changes to 2 identical views simultaneously </li></ul><ul><ul><li>First change (according to time stamp) is enacted </li></ul></ul><ul><ul><li>Second change is informed of conflict and transaction must be performed again </li></ul></ul>
    27. 27. Versioning John Read account Balance (balance = $1,000) . . . Withdraw $200 (balance = $800 . . . Commit Marsha Read account balance (balance = $1,000) . . . Attempt to withdraw $300 (Denied - balance update conflict) . . Rollback Restart transaction
    28. 28. Managing Data Quality <ul><li>Security policy and disaster recovery </li></ul><ul><li>Personnel controls </li></ul><ul><li>Physical access controls </li></ul><ul><li>Maintenance controls (hardware & software) </li></ul><ul><li>Data protection and privacy </li></ul>
    29. 29. The case... <ul><li>What value did ISBH obtain from the data architecture project? </li></ul><ul><li>What should the next step be in order for ISBH to get the most out of the project? </li></ul><ul><li>What would you have done differently in conducting this project? </li></ul><ul><li>What was Darrell Fisher’s role? Dan Gurney’s? Were these appropriate? </li></ul><ul><li>What suggestions would you make to ensure that ISBH does a better job with Data Management in the future? </li></ul>