-
8/12/2019 2.Database Arckoiukhitecture. and Transaction Management
1/37
DBMS 1
Junar A. Landicho
Faculty, Information Technology Department
Database Architecture andTransaction Management
-
8/12/2019 2.Database Arckoiukhitecture. and Transaction Management
2/37
A schemais quite simply a group ofrelated objects in a database.
Within a schema, objects that arerelated have relationships to one
another, as discussed earlier.
-
8/12/2019 2.Database Arckoiukhitecture. and Transaction Management
3/37
There is one owner of a schema,who has access to manipulate the
structure of any object in theschema.
A schema does not represent a
person, although the schema isassociated with a user account thatresides in the database.
-
8/12/2019 2.Database Arckoiukhitecture. and Transaction Management
4/37
-
8/12/2019 2.Database Arckoiukhitecture. and Transaction Management
5/37
-
8/12/2019 2.Database Arckoiukhitecture. and Transaction Management
6/37
-
8/12/2019 2.Database Arckoiukhitecture. and Transaction Management
7/37
2. The internalmodel, also called the
physicalmodel, deals with the physical
storage of the database, as well asaccess to the data, such as through data
storage in tables and the use of indexes
to expedite data access.
-
8/12/2019 2.Database Arckoiukhitecture. and Transaction Management
8/37
The internal model separates the
physical requirements of the hardware
and the operating system from the datamodel.
-
8/12/2019 2.Database Arckoiukhitecture. and Transaction Management
9/37
-
8/12/2019 2.Database Arckoiukhitecture. and Transaction Management
10/37
-
8/12/2019 2.Database Arckoiukhitecture. and Transaction Management
11/37
3. The externalmodel, or application
interface, deals with methods through
which users may access the schema, suchas through the use of a data input form.
The external model allows relationships
to be created between the userapplication and the data model.
-
8/12/2019 2.Database Arckoiukhitecture. and Transaction Management
12/37
-
8/12/2019 2.Database Arckoiukhitecture. and Transaction Management
13/37
-
8/12/2019 2.Database Arckoiukhitecture. and Transaction Management
14/37
-
8/12/2019 2.Database Arckoiukhitecture. and Transaction Management
15/37
-
8/12/2019 2.Database Arckoiukhitecture. and Transaction Management
16/37
The ability to modify a scheme definition inone level without affecting a scheme
definition in a higher level is called dataindependence . There are two kinds.
1.Physical data independence
2. Logical data independence
-
8/12/2019 2.Database Arckoiukhitecture. and Transaction Management
17/37
The ability to modify the physicalscheme without causing application
programs to be rewritten.Modifications at this level are
usually to improve performance.
-
8/12/2019 2.Database Arckoiukhitecture. and Transaction Management
18/37
The ability to modify theconceptual scheme without causing
application programs to berewritten.
Usually done when logicalstructure of database is altered.
-
8/12/2019 2.Database Arckoiukhitecture. and Transaction Management
19/37
Logical data independence isharder to achieve as the
application programs are usuallyheavily dependent on the logical
structure of the data. An analogy ismade to abstract data types inprogramming languages.
-
8/12/2019 2.Database Arckoiukhitecture. and Transaction Management
20/37
1. Database planning The first step in the planning process is to
decide what data to collect and how to organize
it. The planning data will be stored in the CASEtool repository, and the project team mustdefine the objects (or entries), and therelationships among those objects. The CASE
tools provide a database management system(DBMS) for defining, storing and retrieving thedata in the planning database.
-
8/12/2019 2.Database Arckoiukhitecture. and Transaction Management
21/37
There are six entries. Each entity in turn isbroken down into several levels, as
appropriate. The entities shown in this figureare the following:1. Organization: information on
organizational positions as the corporate,division, department and group level.
-
8/12/2019 2.Database Arckoiukhitecture. and Transaction Management
22/37
2. Function: information on organizationalfunctions, processes, and activities (we
define these terms in the next section).3. Critical success factors (CSFs): information
on those areas where things must go rightfor the company to succeed.
4. Data: information on data requirementsthroughout the organization (subcategoriesare entries, records, and elements).
-
8/12/2019 2.Database Arckoiukhitecture. and Transaction Management
23/37
5. System: information on the organizations
automated information systems (present andproposed).
6. Project: information about candidate projects thatwill be considered by the organization.
-
8/12/2019 2.Database Arckoiukhitecture. and Transaction Management
24/37
2. System Definition
Scope
Parameters
Application areas
User groupsDiscovery prototyping
-
8/12/2019 2.Database Arckoiukhitecture. and Transaction Management
25/37
3. Information Needs/Requirements AnalysisGoal:to communicate information in ways that are
relevant to the recipient group
A process of :
Discovery
Refinement
Modeling
Specifications
-
8/12/2019 2.Database Arckoiukhitecture. and Transaction Management
26/37
3. Information Needs/Requirements Analysis Requirements Discovery Methods
Collecting facts from existing documentation
Research and site visits
Questionnaires
Interviews
Discovery prototyping
-
8/12/2019 2.Database Arckoiukhitecture. and Transaction Management
27/37
4. Goals of Requirements Analysis To determine the data requirements of the
database in terms of primitive objects.
To classify and describe the information about theseobjects.
To identify and classify the relationships among theobjects.
To determine the types of transactions that will beexecuted on the database and the interactionsbetween the data and the transactions.
To identify rules governing the integrity of the data.
-
8/12/2019 2.Database Arckoiukhitecture. and Transaction Management
28/37
5. Database Design
The process of creating a design for a
database that will support the enterprisesoperations and objectives.
-
8/12/2019 2.Database Arckoiukhitecture. and Transaction Management
29/37
6. Database Design Framework
Determine the information requirements.
Analyze the real-world objects that you want tomodel in the database.
Determine primary key attributes.
Develop a set of rules that govern how each
table is accessed, populated and updated.
Identify relationship between the entities.
Plan database security.
-
8/12/2019 2.Database Arckoiukhitecture. and Transaction Management
30/37
7. Stages of Implementation
Hardware/Software Acquisition if needed
ProgrammingTesting (program, subsystem, system tests)
-
8/12/2019 2.Database Arckoiukhitecture. and Transaction Management
31/37
7. Stages of Implementation
Training ( lead users, train the trainer)
Conversion (in order of increasingcomplexity and risk)Parallel (old and new systems)
Pilot ( small scale, small scope)
Phased ( most critical functions first)
Direct Cutover( with manual parallel operations
-
8/12/2019 2.Database Arckoiukhitecture. and Transaction Management
32/37
8. Database Maintenance Objectives:Fix bugs (incorrect program specs or
code) in software, add enhanced functions, cycle
back through SDLC phases as needed for small-scale projects
End Result:Fully Functional Robust System
Methods:As needed for phases above; audit thesystem
How to Avoid Risk:Watch changing businessrequirements, set priorities.
-
8/12/2019 2.Database Arckoiukhitecture. and Transaction Management
33/37
A transaction (xact) is the DBMSs abstract view of a user
program (or activity):
- A sequence of reads and writes of database objects.
- Unit of work that must commit or abort as an atomic unit.
A users program may carry out many operations on the dataretrieved from the database, but the DBMS is only concernedabout what data is read/written from/to thedatabase.
Transaction Manager controls the execution of transactions.
-
8/12/2019 2.Database Arckoiukhitecture. and Transaction Management
34/37
Atomicity: All actions in the Xact happen, or nonehappen.
Consistency: If each Xact is consistent, and the DB
starts consistent, it ends up consistent.
Isolation: Execution of one Xact is isolated from thatof other Xacts.
Durability: If a Xact commits, its effects persist.
-
8/12/2019 2.Database Arckoiukhitecture. and Transaction Management
35/37
A very important property guaranteed by the DBMS
for all transactions is that they are atomic. That is, auser can think of a Xact as always executing all itsactions in one step, or not executing any actions at all.
A transaction ends in one of two ways:
- commit after completing all actions
- abortafter executing some actions
- system crashwhile the Xact is in progress; treat asabort.
-
8/12/2019 2.Database Arckoiukhitecture. and Transaction Management
36/37
DBMS ensures the above by logging all actions:
- Undothe actions of aborted/failed transactions- Redoactions of committed transactions not yetpropagated to disk when system crashes.
-
8/12/2019 2.Database Arckoiukhitecture. and Transaction Management
37/37
Giving the best what we have in making whatyou are and what you can be