1. © 2002 by Prentice Hall 1 SI 654 Database Application Design Winter 2003 Dragomir R. Radev

2. © 2002 by Prentice Hall 2 David M. Kroenke Database Processing Eighth Edition Chapter 10 Database Application Design

3. © 2002 by Prentice Hall 3 Functions of a Database Application

4. © 2002 by Prentice Hall 4 Four Basic Functions of Database Applications The four basic functions are common to all database applications These basic functions are –Create –Read –Update –Delete The (unfortunate) acronym for these functions is CRUD

5. © 2002 by Prentice Hall 5 Format/Materialize Function of a Database Application The format/materialize function of a database application involves designing the appearance of the database application

6. © 2002 by Prentice Hall 6 Enforce Constraints Function of a Database Application Database application constraints typically involve validating the format, structure, and/or values of data.

7. © 2002 by Prentice Hall 7 Provide Security and Control Function of a Database Application In that database applications provide access to many people for many purposes, the application must provide security and control functions. This helps protects the data from being seen and/or modified by unauthorized persons.

8. © 2002 by Prentice Hall 8 Execute Application Logic Function of a Database Application Database applications satisfy one or more business function. As such, the business logic must be embedded into the database application. These logic rules and procedures constitute the execute application logic function of a database application.

9. © 2002 by Prentice Hall 9 A View A view is a structured list of data attributes from the entities or semantic objects defined in the data model A view can be materialized or formatted as an on-line form or a hard-copy report

10. © 2002 by Prentice Hall 10 A View CRUD Functions – Create Create INSERT INTO CUSTOMER (CUSTOMER.Name, CUSTOMER.City) VALUES (NewCust.CUSTOMER.Name, NewCust.CUSTOMER.City)

11. © 2002 by Prentice Hall 11 A View CRUD Functions – Read Read SELECT CUSTOMER.CustomerID, CUSTOMER.Name FROM CUSTOMER, WORK WHERE CUSTOMER.CustomerID = WORK.CustomerID

12. © 2002 by Prentice Hall 12 A View CRUD Functions – Update Update INSERT INTO CUSTOMER (CUSTOMER.Name, CUSTOMER.City) VALUES (NewCust.CUSTOMER.Name, NewCust.CUSTOMER.City)

13. © 2002 by Prentice Hall 13 A View CRUD Functions – Delete Delete Cascading deletions depend on relationship cardinality

14. © 2002 by Prentice Hall 14 Form Design A form should... –Reflect the underlying structure of the view –Make data associations graphically evident –Encourage/Guide appropriate user action/response

15. © 2002 by Prentice Hall 15 Graphical User Interface (GUI) Controls Drop-down list box –A drop-down list box provides a list of items from which the user may choose Option (or radio) button –A set of option buttons allow the user to select one of a set of alternatives

16. © 2002 by Prentice Hall 16 Graphical User Interface (GUI) Controls Check box –A check box allows the user to select or deselect the option. Cursor movement/Pervasive Keys –Cursor movement defines the behavior of the cursor. The cursor should move naturally through the form.

17. © 2002 by Prentice Hall 17 GUI Example

18. © 2002 by Prentice Hall 18 Report Design The report should... –Reflect the underlying structure of the view –Handle implied objects The implied objects are those real- world objects that provide meaning and purpose to the report and to the database application

19. © 2002 by Prentice Hall 19 Enforcing Constraints within a Database Application Domain constraints Uniqueness Referential integrity constraints Relationship cardinality Business rule –Triggers

20. © 2002 by Prentice Hall 20 Uniqueness Constraint The uniqueness constraint determines if the value within the attribute must be unique for every tuple in the relation. Uniqueness is referred to as “no duplicates” within Microsoft Access

21. © 2002 by Prentice Hall 21 Referential Integrity Constraint Referential integrity defines the role and treatment of the foreign keys. For a foreign key to exist, the value of the foreign key must appear as a value in the primary key of the associated relation.

22. © 2002 by Prentice Hall 22 Relationship Cardinality Constraint Minimum relationship cardinality constraint Maximum relationship cardinality constraint

23. © 2002 by Prentice Hall 23 Minimum Relationship Cardinality Constraint The minimum relationship cardinality constraint defines whether participation in a relationship is mandatory or optional 0 = optional 1 = manditory –A fragment is a parent that does not have a required child –An orphan is a child that does not have a required parent

24. © 2002 by Prentice Hall 24 Maximum Relationship Cardinality Constraint The maximum relationship cardinality constraint defines the maximum level of participation in a relationship 1 = at most one N = zero or more

25. © 2002 by Prentice Hall 25 The Relationship Between the Minimum and Maximum Relationship Cardinality Constraints If the minimum cardinality constraint is optional (0), the maximum relationship cardinality constraint would mean: 1 = zero or one N = zero, one, or more

26. © 2002 by Prentice Hall 26 The Relationship between the Minimum and Maximum Relationship Cardinality Constraints If the minimum cardinality constraint is mandatory (1), the maximum relationship cardinality constraint would mean: 1 = one N = one or more

27. © 2002 by Prentice Hall 27 Business Rule Constraints Business rule constraints are those conditions that must be satisfied based on the rules, practices, and operating procedures of the organization.

28. © 2002 by Prentice Hall 28 Triggers Triggers are stored procedures that are invoked based on an action. –For instance a stored procedure may be invoked every time a record is added to the system.

29. © 2002 by Prentice Hall 29 Security Functions within a Database Application Typically, security exists on several levels within a database application –To log into the system, the user needs an operating system (e.g., the Windows username/password) –To log into the database, the user must supply a username and password –To execute the database application, the user must be granted access to the appropriate application files

30. © 2002 by Prentice Hall 30 Horizontal versus Vertical Security Schemes Horizontal security refers to the practice of restricting access to certain tuples in the database. –E.g., you may only see sales data in the NorthEast Vertical security refers to the practice of restricting access to certain columns in the database. –E.g., you may only see the name and address fields

31. © 2002 by Prentice Hall 31 Control Functions within a Database Application Typically control functions are introduced into database applications through menus and by defining transaction boundaries. –Using menus, the developer may control the access for a particular user. This access may change throughout a user’s session. –Transaction boundaries are defined to coordinate user actions in a multi-user environment.

32. © 2002 by Prentice Hall 32 David M. Kroenke Database Processing Eighth Edition Chapter 11 Managing Multi-User Databases

33. © 2002 by Prentice Hall 33 Multi-User Databases Serving the needs of multiple users and multiple applications adds complexity in… –design, –development, and –migration (future updates)

34. © 2002 by Prentice Hall 34 Multi-User Database Issues include… Interdependency –Changes required by one user may impact others Concurrency –People or applications may try to update the same information at the same time

35. © 2002 by Prentice Hall 35 Multi-User Database Issues include… (continued) Record Retention –When information should be discarded Backup/Recovery –How to protect yourself from losing critical information

36. © 2002 by Prentice Hall 36 Common Multi-User DBMS Windows 2000 –Access 2000 –SQL Server –ORACLE UNIX –ORACLE –Sybase –Informix

37. © 2002 by Prentice Hall 37 Role of the Database Administrator Organizations typically hire a database administrator (DBA) to handle the issues and complexities associated with multi-user databases. A DBA facilitates the development and use of one or more databases.

38. © 2002 by Prentice Hall 38 Data Administrator versus Database Administrator Data Administrator –Handle the database functions and responsibilities for the entire organization. –Data administrator responsibilities are discussed in Chapter 17. Database Administrator (DBA) –Handle the functions associated with a specific database, including those applications served by the database. –This chapter describes the responsibilities of the DBA.

39. © 2002 by Prentice Hall 39 The Characteristics of a DBA Technical –The DBA is responsible for the performance and maintenance of one or more databases. Diplomatic –The DBA must coordinate the efforts, requirements, and sometimes conflicting goals of various user groups to develop community-wide solutions.

40. © 2002 by Prentice Hall 40 Technical Skills of the DBA Managing the database structure Controlling concurrent processing Managing processing rights and responsibilities Developing database security Providing database recovery Managing the database management system (DBMS) Maintaining the data repository

41. © 2002 by Prentice Hall 41 Managing the Database Structure Managing the database structure includes configuration control and documentation regarding: –The allocation of space –Table creation –Indices creation –Storage procedures –Trigger creation

42. © 2002 by Prentice Hall 42 Configuration Control The database configuration must reflect changes in organizational and user requirements Structural changes to the database often effect most, if not all, applications and users Sometimes configuration changes have unanticipated consequences Consequently, broad perspectives, careful analysis, and effective communication are essential. As well, the DBA must be prepared to debug and repair unforeseen issues.

43. © 2002 by Prentice Hall 43 The Need for Documentation When altering a databases structure, unanticipated issues are inevitable In recording the specific changes, dates, and times, it is easier to determine the root cause of issues and to resolve the issues When historical data is restored, it must be reformatted with all the changes in the database structure since the data was originally saved.

44. © 2002 by Prentice Hall 44 Documentation All structural changes must be carefully documented with the following: –Reason for change –Who made the changes –Specifically what was changed –How and when the changes were implemented –How were the changes tested and what were the results

45. © 2002 by Prentice Hall 45 Documentation Aids Version Control and Computer Assisted Software Engineering (CASE) tools automate and/or manage many tedious documentation tasks. Printing the data dictionaries after structural changes also helps eliminate many tedious documentation tasks

46. © 2002 by Prentice Hall 46 Controlling Concurrency Processing Concurrency control ensures that one user’s actions do not adversely impact another user’s actions At the core of concurrency is accessibility. In one extreme, data becomes inaccessible once a user touches the data. This ensures that data that is being considered for update is not shown. In the other extreme, data is always readable. The data is even readable when it is locked for update.

47. © 2002 by Prentice Hall 47 Aspects of Concurrency Control Rollback/Commit: Ensuring all actions are successful before posting to the database Multitasking: Simultaneously serving multiple users Lost Updates: When one user’s action overwrites another user’s request

48. © 2002 by Prentice Hall 48 Rollback/Commit A database operation typically involves several transactions. These transactions are atomic and are sometimes called logical units of work (LUW). Before an operation is committed to the database, all LUWs must be successfully completed. If one or more LUW is unsuccessful, a rollback is performed and no changes are saved to the database.

49. © 2002 by Prentice Hall 49 Lost Update Problem If two or more users are attempting to update the same piece of data at the same time, it is possible that one update may overwrite another update. Resource locking scenarios are designed to address this problem

50. © 2002 by Prentice Hall 50 Resource Locking A resource lock prevents a user from reading and/or writing to a piece of data The size of the piece of data (e.g., database, table, field) is termed the lock granularity

51. © 2002 by Prentice Hall 51 Types of Resource Locks Implicit versus Explicit –Implicit locks are issued automatically by the DBMS based on an activity –Explicit locks are issued by users requesting exclusive rights to the data Exclusive versus Shared –An exclusive lock lock prevents others from reading or updating the data –A shared lock allows others to read, but not update the data

52. © 2002 by Prentice Hall 52 Two-Phased Resource Locking Two-phased locking, whereby locks are obtained as they are needed –A growing phase, whereby the transaction continues to request additional locks –A shrinking phase, whereby the transaction begins to release the locks

53. © 2002 by Prentice Hall 53 Deadlocks As a transaction begins to lock resources, it may have to wait for a particular resource to be released by another transaction. On occasions, two transactions maybe indefinitely waiting on one another to release resources. This condition is known as a deadlock or a deadly embrace.

54. © 2002 by Prentice Hall 54 Avoiding Deadlocks Strategy 1: –Wait until all resources are available, then lock them all before beginning Strategy 2: –Establish and use clear locking orders/sequences Strategy 3: –Once detected, the DBMS will rollback one transaction

55. © 2002 by Prentice Hall 55 Resource Locking Strategies Optimistic Locking –Read data –Process transaction –Issue update –Look for conflict –If conflict occurred, rollback and repeat or else commit Pessimistic Locking –Lock required resources –Read data –Process transaction –Issue update –Release locks

56. © 2002 by Prentice Hall 56 Consistent Transactions Consistent transactions are often referred to by the acronym ACID –Atomic –Consistent –Isolated –Durable

57. © 2002 by Prentice Hall 57 ACID: Atomic A transaction consists of a series of steps. Each step must be successful for the transaction to be saved. This ensures that the transaction completes everything it intended to do before saving the changes.

58. © 2002 by Prentice Hall 58 ACID: Consistent No other transactions are permitted on the records until the current transaction finishes This ensures that the transaction integrity has statement level consistence among all records

59. © 2002 by Prentice Hall 59 ACID: Isolation Within multi-user environments, different transactions may be operating on the same data. As such, the sequencing of uncommitted updates, rollbacks, and commits continuously change the data content. The 1992 ANSI SQL standards define four isolation levels and specify respective issues.

60. © 2002 by Prentice Hall 60 Summary of Isolation Levels

61. © 2002 by Prentice Hall 61 ACID: Durable Durable transactions are saved to the data permanently Interim calculations, views, and sub- queries are temporal rather than durable; that is to say that these temporal results are not saved

62. © 2002 by Prentice Hall 62 Set-at-a-Time Versus Row-at-a-Time SQL statements act as filters for the entire data set. A cursor may be defined within a SQL statement to point to a particular record. Several types of cursors have been defined. The cursor type defines how the cursor behaves.

63. © 2002 by Prentice Hall 63 Types of Cursors

64. © 2002 by Prentice Hall 64 Database Security Database security strives to ensure… –Only authorized users perform authorized activities at authorized times

65. © 2002 by Prentice Hall 65 Managing Processing Rights and Responsibilities Processing rights define who is permitted to do what, when The individuals performing these activities have full responsibility for the implications of their actions Individuals are identified by a username and a password

66. © 2002 by Prentice Hall 66 Granting of Processing Rights Database users are known as an individual and as a member of one or more role Access and processing rights/privileges may be granted to an individual and/or a role Users possess the compilation of rights granted to the individual and all the roles for which they are members

67. © 2002 by Prentice Hall 67 Granting Privileges

68. © 2002 by Prentice Hall 68 Providing Database Recovery Common causes of database failures… –Hardware failures –Programming bugs –Human errors/mistakes –Malicious actions Since these issues are impossible to completely avoid, recovery procedures are essential

69. © 2002 by Prentice Hall 69 Database Recovery Characteristics Continuing business operations (Fall- back procedures/Continuity planning) Restore from backup Replay database activities since backup was originally made

70. © 2002 by Prentice Hall 70 Fall-back Procedures/ Continuity Planning The business will continue to operate even when the database is inaccessible The fall-back procedure defines how the organization will continue operations Careful attention must be paid to… –saving essential data –continuing to provide quality service

71. © 2002 by Prentice Hall 71 Restoring from Backup In the event that the system must be rebuilt or reloaded, the database is restored from the last full backup. Since it is inevitable that activities occurred since the last full backup was made, subsequent activities must be replayed/restored.

72. © 2002 by Prentice Hall 72 Recovery via Reprocessing This is a brunt-force technique. Simply re-type all activities since the backup was performed. This procedure is costly because of the effort involved in re-entering the data. This procedure is risky in that human error is likely and in that paper record-keeping may not be accurate.

73. © 2002 by Prentice Hall 73 Recovery via Rollback/Rollforward Most database management systems provide a mechanism to record activities into a log file.

74. © 2002 by Prentice Hall 74 Rollforward Activities recorded in the log files may be replayed. In doing so, all activities are re- applied to the database. This procedure is used to resynchronize restored database data. This procedure is termed a Rollforward.

75. © 2002 by Prentice Hall 75 Rollback Since log files save activities in sequence order, it is possible to undo activities in reserve order that they were originally executed. This is performed to correct/undo erroneous or malicious transaction(s). This procedure is known as a Rollback.

76. © 2002 by Prentice Hall 76 Managing the Database Management System (DBMS) In addition to controlling and maintaining the users and the data, the DBA must also maintain and monitor the DBMS itself. –Performance statistics (performance tuning/optimizing) –System and data integrity –Establishing, configuring, and maintaining database features and utilities

77. © 2002 by Prentice Hall 77 Maintaining the Data Repository The data repository contains metadata. Metadata is data about data. The data repository specifies the name, type, size, format, structure, definitions, and relationships among the data. They also contain the details about applications, users, add-on products, etc.

78. © 2002 by Prentice Hall 78 Types of Data Repositories Active data repository –The development and management tools automatically maintain and upkeep the metadata. Passive data repository –People manually maintain and upkeep the metadata