2.Database Arckoiukhitecture. and Transaction Management

8/12/2019 2.Database Arckoiukhitecture. and Transaction Management

1/37

DBMS 1

Junar A. Landicho

Faculty, Information Technology Department

Database Architecture andTransaction 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.


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.


4/37


5/37


6/37


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/37

The internal model separates the

physical requirements of the hardware

and the operating system from the datamodel.


9/37


10/37


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.


12/37


13/37


14/37


15/37


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


17/37

The ability to modify the physicalscheme without causing application

programs to be rewritten.Modifications at this level are

usually to improve performance.


18/37

The ability to modify theconceptual scheme without causing

application programs to berewritten.

Usually done when logicalstructure of database is altered.


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.


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.


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.


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).


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.


24/37

2. System Definition

Scope

Parameters

Application areas

User groupsDiscovery prototyping


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


26/37

3. Information Needs/Requirements Analysis Requirements Discovery Methods

Collecting facts from existing documentation

Research and site visits

Questionnaires

Interviews

Discovery prototyping


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.


28/37

5. Database Design

The process of creating a design for a

database that will support the enterprisesoperations and objectives.


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.


30/37

7. Stages of Implementation

Hardware/Software Acquisition if needed

ProgrammingTesting (program, subsystem, system tests)


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


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.


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.


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.


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.


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.


37/37

Giving the best what we have in making whatyou are and what you can be

Documents

2.Database Arckoiukhitecture. and Transaction Management