1. Application Design (2) Database – IS 240 Lecture #23 – 2004-04-15 M. E. Kabay, PhD, CISSP Dept of Computer Information Systems Norwich University mkabay@norwich.edu

2. 2 Copyright © 2004 M. E. Kabay. All rights reserved. Topics Where to Enforce Constraints? Types of Constraints Security Control Homework

3. 3 Copyright © 2004 M. E. Kabay. All rights reserved. Where to Enforce Constraints (1)? DBMS / pro Central control over data constraints: Define once, apply consistently to all applications Change for all applications by modifying one rule May need to examine all records -- faster DBMS / con Not all DBMS engines handle constraints fully or well

4. 4 Copyright © 2004 M. E. Kabay. All rights reserved. Where to Enforce Constraints (2)? Application / pro May be easier to implement constraints in apps Some constraints are application- dependent Specific business rules Some domain constraints such as assigning an input to a specific field (e.g., PATIENT.Name vs DOCTOR.Name) General principle: try to enforce constraints in DBMS first, then move to application.

5. 5 Copyright © 2004 M. E. Kabay. All rights reserved. Exercise: Constraint Implementation -- Hospital Consider the hospital DB we have been using in the last several lectures Suggest constraints that would be best implemented In the DBMS metadata In an application program

6. 6 Copyright © 2004 M. E. Kabay. All rights reserved. Types of Constraints Domain Uniqueness Relationship Referential integrity Relationship cardinality Business rules

7. 7 Copyright © 2004 M. E. Kabay. All rights reserved. Domain Constraints What type of data can be entered in a field? How can constraining data type help the user? How long can the input be? Why would you care about the length of a field? Are there masks (patterns) that reflect the way data are to be entered and/or stored? Give several examples of masks you might use in a hospital DB

8. 8 Copyright © 2004 M. E. Kabay. All rights reserved. Domain Constraints (cont'd) Optional fields Implies acceptance of null entries Is a null entry always the same as a blank or a zero? Give examples of optional and mandatory fields you might see in the hospital DB Required / Mandatory fields Can supply initial (default) values Many form designers on Web use * to mark required fields Can signal (flag) missing data either on exit from field or on completion of form Discuss pro/con of each strategy

9. 9 Copyright © 2004 M. E. Kabay. All rights reserved. Uniqueness Constraint Simple to define in DBMS as attribute of a specific field Usually define an item as an index to accomplish uniqueness checking very quickly Roughly how long does it take to read a record or a block of records from disk? Without an index, how would the DBMS enforce the uniqueness constraint? Why does creating an index speed up uniqueness checking?

10. 10 Copyright © 2004 M. E. Kabay. All rights reserved. Referential Integrity Referential integrity means... what? Discuss examples of failures of referential integrity that might occur in the hospital DB How is it possible to develop a breach of referential integrity?

11. 11 Copyright © 2004 M. E. Kabay. All rights reserved. Relationship Cardinality Consider the relationship between patient, doctor and prescription in a CURRENT_PRESCRIPTION table. Can a prescription exist without a patient? Without a doctor? What is the cardinality of prescription to patient? Prescription to doctor? Prescription to (Patient, Doctor)? Could the DBMS enforce a rule that Only one prescription must be defined for any given patient? How?

12. 12 Copyright © 2004 M. E. Kabay. All rights reserved. Relationship Cardinality (1) A row missing a required parent or a required child is called a fragment. A child missing a mandatory parent is called an orphan. Give examples from the hospital DB of a Mandatory-to-mandatory (M-M) constraint Mandatory-to-optional (M-O) constraint Optional-to-mandatory (O-M) constraint Optional-to-optional (O-O) constraint

13. 13 Copyright © 2004 M. E. Kabay. All rights reserved. Relationship Cardinality (2) Examples from a hospital DB M-M: A patient must have a bed and a bed must have a patient to be recorded in the current list of in-patients M-O: A doctor may have one or more patients but a patient must be assigned at least one doctor O-M:A prescription must have a patient but a patient does not necessarily have a prescription O-O: A session of grand rounds may be scheduled without knowing which doctor(s) will present; a doctor may or may not participate in grand rounds.

14. 14 Copyright © 2004 M. E. Kabay. All rights reserved. Preventing Fragments: Parent Records Give examples from the hospital DB of each rule from Figure 10-19 (reproduced below):

15. 15 Copyright © 2004 M. E. Kabay. All rights reserved. Business Rules Give examples of business rules in a hospital DB that would apply to Salary increases for nurses as a function of last years profits Whether a doctor could be entered into the DOCTOR table Acceptability of an insurance company as a payer How the head of a service (e.g., ICU, OR, Internal Medicine, Dermatology) is selected Would you implement these rules in the DBMS metadata or in an application program?

16. 16 Copyright © 2004 M. E. Kabay. All rights reserved. Security Basics Basic concepts Confidentiality Control or possession Integrity Authenticity Availability Utility Mechanisms Identification & Authentication User-specific views

17. 17 Copyright © 2004 M. E. Kabay. All rights reserved. Confidentiality Restricting access to data Protecting against unauthorized disclosure of existence of data E.g., allowing industrial spy to deduce nature of clientele by looking at directory names Protecting against unauthorized disclosure of details of data E.g., allowing 13-yr old girl to examine HIV+ records in Florida clinic

18. 18 Copyright © 2004 M. E. Kabay. All rights reserved. Possession Control over information Preventing physical contact with data E.g., case of thief who recorded ATM PINs by radio (but never looked at them) Preventing copying or unauthorized use of intellectual property E.g., violations by software pirates

19. 19 Copyright © 2004 M. E. Kabay. All rights reserved. Confidentiality & Possession Losses Locating Disclosing Observing, monitoring, and acquiring Copying Taking or controlling Claiming ownership or custodianship Inferring Exposing to all of the other losses Endangering by exposing to any of the other losses Failure to engage in or to allow any of the other losses to occur when instructed to do so

20. 20 Copyright © 2004 M. E. Kabay. All rights reserved. Integrity Internal consistency, validity, fitness for use Avoiding physical corruption E.g., database pointers trashed or data garbled Avoiding logical corruption E.g., inconsistencies between order header total sale & sum of costs of details

21. 21 Copyright © 2004 M. E. Kabay. All rights reserved. Authenticity Correspondence to intended meaning Avoiding nonsense E.g., part number field actually contains cost Avoiding fraud E.g., senders name on e-mail is changed to someone elses

22. 22 Copyright © 2004 M. E. Kabay. All rights reserved. Integrity & Authenticity Losses Insertion, use, or production of false or unacceptable data Modification, replacement, removal, appending, aggregating, separating, or reordering Misrepresentation Repudiation (rejecting as untrue) Misuse or failure to use as required

23. 23 Copyright © 2004 M. E. Kabay. All rights reserved. Availability Timely access to data Avoid delays E.g., prevent system crashes & arrange for recovery plans Avoid inconvenience E.g., prevent mislabeling of files

24. 24 Copyright © 2004 M. E. Kabay. All rights reserved. Utility Usefulness for specific purposes Avoid conversion to less useful form E.g., replacing dollar amounts by foreign currency equivalent Prevent impenetrable coding E.g., employee encrypts source code and "forgets" decryption key

25. 25 Copyright © 2004 M. E. Kabay. All rights reserved. Availability & Utility Losses Destruction, damage, or contamination Denial, prolongation, acceleration, or delay in use or acquisition Movement or misplacement Conversion or obscuration

26. 26 Copyright © 2004 M. E. Kabay. All rights reserved. Security in DBMS User-specific views Vertical security: limit columns (fields) Horizontal security: limit rows (records) Implementations Incorporate user-name or role in records Use different forms, reports for different people Give examples of how a hospital application might apply security restrictions to its DB

27. 27 Copyright © 2004 M. E. Kabay. All rights reserved. Control in DB Applications Two types of control Logic or flow: how to move from one forms or report to another Transaction integrity – subject of later lectures Logic flow can be controlled by menus An entire form can present a menu of choices Or in a GUI, pull-down menus can unfold into secondary menus to show options

28. 28 Copyright © 2004 M. E. Kabay. All rights reserved. Homework Review all of chapter 10 carefully using SQ3R Survey all of Kroenkes Chapter 11 using the SQ phases of SQ3R in preparation for Thursdays class – Ch 11 covers very complex issues REQUIRED: By Thursday the 22 nd of April, Complete and hand in questions 10.24 to 10.48 for 50 points OPTIONAL: By Thursday the 29 th For 4 points of extra credit Complete the Group II questions on page 291

29. 29 Copyright © 2004 M. E. Kabay. All rights reserved. DISCUSSION