Applicatio n Design (2) Database – IS 240 Lecture #23 – 2004-04-15 M. E. Kabay, PhD, CISSP Dept of Computer Information Systems Norwich University [email protected]
Mar 27, 2015
Application Design
(2)Database – IS 240Lecture #23 – 2004-04-15
M. E. Kabay, PhD, CISSPDept of Computer Information Systems
Norwich University [email protected]
2 Copyright © 2004 M. E. Kabay. All rights reserved.
TopicsWhere to Enforce Constraints?Types of ConstraintsSecurityControlHomework
3 Copyright © 2004 M. E. Kabay. All rights reserved.
Where to Enforce Constraints (1)?
DBMS / proCentral 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 -- fasterDBMS / con
Not all DBMS engines handle constraints fully or well
4 Copyright © 2004 M. E. Kabay. All rights reserved.
Where to Enforce Constraints (2)?
Application / proMay be easier to implement constraints in
appsSome constraints are application-
dependentSpecific business rulesSome 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 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 implementedIn the DBMS metadataIn an application program
6 Copyright © 2004 M. E. Kabay. All rights reserved.
Types of Constraints
DomainUniquenessRelationship
Referential integrityRelationship cardinality
Business rules
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 Copyright © 2004 M. E. Kabay. All rights reserved.
Domain Constraints (cont'd)Optional fields
Implies acceptance of null entriesIs 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 DBRequired / Mandatory fields
Can supply initial (default) valuesMany form designers on Web use * to mark
required fieldsCan signal (flag) missing data either on exit
from field or on completion of formDiscuss pro/con of each strategy
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 quicklyRoughly 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 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 DBHow is it possible to develop a breach of
referential integrity?
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 thatOnly one prescription must be defined for
any given patient?How?
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 aMandatory-to-mandatory (M-M) constraintMandatory-to-optional (M-O) constraintOptional-to-mandatory (O-M) constraintOptional-to-optional (O-O) constraint
13 Copyright © 2004 M. E. Kabay. All rights reserved.
Relationship Cardinality (2)
Examples from a hospital DBM-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 Copyright © 2004 M. E. Kabay. All rights reserved.
Preventing Fragments: Parent RecordsGive examples from the hospital DB of each
rule from Figure 10-19 (reproduced below):
Insert Modify key Delete
M-MCreate at least one
childChange matching key of all children
Delete all children OR reassign all
children
M-O OKChange matching keys of all children
Delete all children OR reassign all
children
O-MInsert new child OR appropriate
child exists
Change key of at least one child OR appropriate child
exists
OK
O-O OK OK OK
Typ
e o
f re
lati
on
ship
Proposed Action on Parent
15 Copyright © 2004 M. E. Kabay. All rights reserved.
Business Rules
Give examples of business rules in a hospital DB that would apply toSalary increases for nurses as a function
of last year’s profitsWhether a doctor could be entered into the
DOCTOR tableAcceptability of an insurance company as
a payerHow the head of a service (e.g., ICU, OR,
Internal Medicine, Dermatology) is selectedWould you implement these rules in the
DBMS metadata or in an application program?
16 Copyright © 2004 M. E. Kabay. All rights reserved.
Security Basics
Basic conceptsConfidentialityControl or possessionIntegrityAuthenticityAvailabilityUtility
MechanismsIdentification & AuthenticationUser-specific views
17 Copyright © 2004 M. E. Kabay. All rights reserved.
Confidentiality
Restricting access to dataProtecting against unauthorized disclosure of
existence of dataE.g., allowing industrial spy to deduce
nature of clientele by looking at directory names
Protecting against unauthorized disclosure of details of dataE.g., allowing 13-yr old girl to examine
HIV+ records in Florida clinic
18 Copyright © 2004 M. E. Kabay. All rights reserved.
Possession
Control over informationPreventing 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 propertyE.g., violations by software pirates
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 Copyright © 2004 M. E. Kabay. All rights reserved.
Integrity
Internal consistency, validity, fitness for useAvoiding physical corruption
E.g., database pointers trashed or data garbled
Avoiding logical corruptionE.g., inconsistencies between order header
total sale & sum of costs of details
21 Copyright © 2004 M. E. Kabay. All rights reserved.
Authenticity
Correspondence to intended meaningAvoiding nonsense
E.g., part number field actually contains cost
Avoiding fraudE.g., sender’s name on e-mail is changed
to someone else’s
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
MisrepresentationRepudiation (rejecting as untrue)Misuse or failure to use as required
23 Copyright © 2004 M. E. Kabay. All rights reserved.
Availability
Timely access to dataAvoid delays
E.g., prevent system crashes & arrange for recovery plans
Avoid inconvenienceE.g., prevent mislabeling of files
24 Copyright © 2004 M. E. Kabay. All rights reserved.
Utility
Usefulness for specific purposesAvoid conversion to less useful form
E.g., replacing dollar amounts by foreign currency equivalent
Prevent impenetrable codingE.g., employee encrypts source code and
"forgets" decryption key
25 Copyright © 2004 M. E. Kabay. All rights reserved.
Availability & Utility Losses
Destruction , damage, or contaminationDenial, prolongation, acceleration, or delay in
use or acquisitionMovement or misplacementConversion or obscuration
26 Copyright © 2004 M. E. Kabay. All rights reserved.
Security in DBMS
User-specific viewsVertical security: limit columns (fields)Horizontal security: limit rows (records)
ImplementationsIncorporate user-name or role in recordsUse different forms, reports for different
peopleGive examples of how a hospital application
might apply security restrictions to its DB
27 Copyright © 2004 M. E. Kabay. All rights reserved.
Control in DB Applications
Two types of controlLogic or flow: how to move from one
forms or report to anotherTransaction integrity – subject of later
lecturesLogic 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 Copyright © 2004 M. E. Kabay. All rights reserved.
Homework
Review all of chapter 10 carefully using SQ3RSurvey all of Kroenke’s Chapter 11 using the SQ
phases of SQ3R in preparation for Thursday’s class – Ch 11 covers very complex issues
REQUIRED: By Thursday the 22nd of April,Complete and hand in questions 10.24 to
10.48 for 50 pointsOPTIONAL: By Thursday the 29th
For 4 points of extra creditComplete the Group II questions on page 291
29 Copyright © 2004 M. E. Kabay. All rights reserved.
DISCUSSION