Transcript l7 - CLAIR

SI 654
Database Application Design
Winter 2003
Dragomir R. Radev
1
© 2002 by Prentice Hall
Database Processing
Eighth Edition
Database
Application
Design
2
Chapter 10
David M. Kroenke
© 2002 by Prentice Hall
Functions of a Database
Application
3
© 2002 by Prentice Hall
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
4
© 2002 by Prentice Hall
Format/Materialize Function
of a Database Application
• The format/materialize function of a
database application involves
designing the appearance of the
database application
5
© 2002 by Prentice Hall
Enforce Constraints
Function of a Database
Application
• Database application constraints
typically involve validating the
format, structure, and/or values of
data.
6
© 2002 by Prentice Hall
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.
7
© 2002 by Prentice Hall
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.
8
© 2002 by Prentice Hall
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
9
© 2002 by Prentice Hall
A View CRUD Functions –
Create
• Create
INSERT INTO CUSTOMER
(CUSTOMER.Name, CUSTOMER.City)
VALUES (NewCust.CUSTOMER.Name,
NewCust.CUSTOMER.City)
10
© 2002 by Prentice Hall
A View CRUD Functions –
Read
• Read
SELECT CUSTOMER.CustomerID,
CUSTOMER.Name
FROM CUSTOMER, WORK
WHERE CUSTOMER.CustomerID =
WORK.CustomerID
11
© 2002 by Prentice Hall
A View CRUD Functions –
Update
• Update
INSERT INTO CUSTOMER
(CUSTOMER.Name, CUSTOMER.City)
VALUES (NewCust.CUSTOMER.Name,
NewCust.CUSTOMER.City)
12
© 2002 by Prentice Hall
A View CRUD Functions –
Delete
• Delete
Cascading
deletions
depend on
relationship
cardinality
13
© 2002 by Prentice Hall
Form Design
• A form should...
– Reflect the underlying structure of
the view
– Make data associations graphically
evident
– Encourage/Guide appropriate user
action/response
14
© 2002 by Prentice Hall
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
15
© 2002 by Prentice Hall
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.
16
© 2002 by Prentice Hall
GUI Example
17
© 2002 by Prentice Hall
Report Design
• The report should...
– Reflect the underlying structure of the
view
– Handle implied objects
• The implied objects are those realworld objects that provide meaning
and purpose to the report and to the
database application
18
© 2002 by Prentice Hall
Enforcing Constraints within
a Database Application
• Domain constraints
• Uniqueness
• Referential
integrity
constraints
19
• Relationship
cardinality
• Business rule
– Triggers
© 2002 by Prentice Hall
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
20
© 2002 by Prentice Hall
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.
21
© 2002 by Prentice Hall
Relationship Cardinality
Constraint
• Minimum relationship cardinality
constraint
• Maximum relationship cardinality
constraint
22
© 2002 by Prentice Hall
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
23
© 2002 by Prentice Hall
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
24
© 2002 by Prentice Hall
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
25
© 2002 by Prentice Hall
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
26
© 2002 by Prentice Hall
Business Rule Constraints
• Business rule constraints are those
conditions that must be satisfied
based on the rules, practices, and
operating procedures of the
organization.
27
© 2002 by Prentice Hall
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.
28
© 2002 by Prentice Hall
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
29
© 2002 by Prentice Hall
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
30
© 2002 by Prentice Hall
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.
31
© 2002 by Prentice Hall
Database Processing
Eighth Edition
Managing
Multi-User
Databases
32
Chapter 11
David M. Kroenke
© 2002 by Prentice Hall
Multi-User Databases
• Serving the needs of multiple users
and multiple applications adds
complexity in…
– design,
– development, and
– migration (future updates)
33
© 2002 by Prentice Hall
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
34
© 2002 by Prentice Hall
Multi-User Database Issues
include… (continued)
• Record Retention
– When information should be
discarded
• Backup/Recovery
– How to protect yourself from losing
critical information
35
© 2002 by Prentice Hall
Common Multi-User DBMS
• Windows 2000
– Access 2000
– SQL Server
– ORACLE
36
• UNIX
– ORACLE
– Sybase
– Informix
© 2002 by Prentice Hall
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.
37
© 2002 by Prentice Hall
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.
38
• 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.
© 2002 by Prentice Hall
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.
39
© 2002 by Prentice Hall
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
40
© 2002 by Prentice Hall
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
41
© 2002 by Prentice Hall
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.
42
© 2002 by Prentice Hall
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.
43
© 2002 by Prentice Hall
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
44
© 2002 by Prentice Hall
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
45
© 2002 by Prentice Hall
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.
46
© 2002 by Prentice Hall
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
47
© 2002 by Prentice Hall
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.
48
© 2002 by Prentice Hall
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
49
© 2002 by Prentice Hall
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
50
© 2002 by Prentice Hall
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
51
• 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
© 2002 by Prentice Hall
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
52
© 2002 by Prentice Hall
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.
53
© 2002 by Prentice Hall
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
54
© 2002 by Prentice Hall
Resource Locking Strategies
• Optimistic Locking
– Read data
– Process transaction
– Issue update
– Look for conflict
– If conflict
occurred, rollback
and repeat or else
commit
55
• Pessimistic Locking
– Lock required
resources
– Read data
– Process
transaction
– Issue update
– Release locks
© 2002 by Prentice Hall
Consistent Transactions
• Consistent transactions are often
referred to by the acronym ACID
– Atomic
– Consistent
– Isolated
– Durable
56
© 2002 by Prentice Hall
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.
57
© 2002 by Prentice Hall
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
58
© 2002 by Prentice Hall
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.
59
© 2002 by Prentice Hall
Summary of Isolation Levels
60
© 2002 by Prentice Hall
ACID: Durable
• Durable transactions are saved to the
data permanently
• Interim calculations, views, and subqueries are temporal rather than
durable; that is to say that these
temporal results are not saved
61
© 2002 by Prentice Hall
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.
62
© 2002 by Prentice Hall
Types of Cursors
63
© 2002 by Prentice Hall
Database Security
• Database security strives to ensure…
– Only authorized users perform
authorized activities at authorized
times
64
© 2002 by Prentice Hall
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
65
© 2002 by Prentice Hall
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
66
© 2002 by Prentice Hall
Granting Privileges
67
© 2002 by Prentice Hall
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
68
© 2002 by Prentice Hall
Database Recovery
Characteristics
• Continuing business operations (Fallback procedures/Continuity planning)
• Restore from backup
• Replay database activities since
backup was originally made
69
© 2002 by Prentice Hall
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
70
© 2002 by Prentice Hall
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.
71
© 2002 by Prentice Hall
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.
72
© 2002 by Prentice Hall
Recovery via
Rollback/Rollforward
• Most database management systems
provide a mechanism to record
activities into a log file.
73
© 2002 by Prentice Hall
Rollforward
• Activities recorded in the log files may be
replayed. In doing so, all activities are reapplied to the database.
• This procedure is used to resynchronize
restored database data.
• This procedure is termed a Rollforward.
74
© 2002 by Prentice Hall
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.
75
© 2002 by Prentice Hall
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
76
© 2002 by Prentice Hall
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.
77
© 2002 by Prentice Hall
Types of Data Repositories
• Active data
repository
– The development
and management
tools
automatically
maintain and
upkeep the
metadata.
78
• Passive data
repository
– People manually
maintain and
upkeep the
metadata
© 2002 by Prentice Hall