Database

HISPTORY

1960s: Data collection, database creation, IMS

and network DBMS 1970s: Relational data model, relational DBMS

implementation 1980s: RDBMS, advanced data models

(extended-relational, OO, deductive, etc.) and

application-oriented DBMS (spatial, scientific,

engineering, etc.) 1990s—2000s: Data mining and data

warehousing, multimedia databases, and Web

databases

GIS Architecture Evolution

Student

Course

Faculty

StudentScheduling

Payroll

IndividualStudent

Class Lists

Pay Checks

File

Application

Output

Traditional File System

Database ApplicationOutput

Student Data

Course Data

Faculty Data

StudentScheduling

Payroll

IndividualStudent

Class Lists

Pay Checks

DBMS

Online User

DBMS

“A store of large amount of information especially in a

form that can be handled by computer.

OR

“The collection of data usually referred to as the

database, contain information about particular

enterprise.”

Database

“A shared collection of logically related data

designed to meet the information of the multiple

users in an organization.”

OR

“A database consist of some collection of Persistent

data that are used by the application program of

some given enterprise.”

Database

“A database management system is essentially

nothing more than a computerized record keeping

system.”

OR

“A database management system consist of

collection of interrelated data and the set of programs

to access the data.”

Database Management System

“All access to database is controlled by

sophisticated software package called the DBMS.”

OR

“A database management system provides a

centralized control of its operational data.”

Database Management System

Application Program

DBMSOperating System

Database

Database

DBMS

On-line QueriesPrewrittenPrograms

Programs in Various

Languages

App Prg DBA

Commandsfor Database

End User

Native Casual

“Any database management

system that follows relational model

that was proposed by Dr. E.F Codd in

1970 is said to be RDBMS.”

Relational DBMS

In a 1985 article, Codd published

rules or principles that a DBMS must

use to be considered “fully relational”

Continue

Criteria for a RDBMS

The relational database model is made

up of many tables, called RELATIONS,

in which related data elements are

stored. The data elements are in rows ,

called TUPLES and columns, called

ATTRIBUTES.

Terminology's Related to RDBMS

The main objective of the relational

database model is to allow complex

logical relationships between records

to be expressed in a simple fashion.

Main Objective

There is no standard definition of what

capabilities or attributes define either an

Extended Relational Database Management

System or an Object-Relational Database

Management System (ORDBMS). Here, both are

referred to as "Extended Relational."

EXTENDED RDBMS

ERDBMSs have characteristics of both an RDBMS

and an ODBMS (thus, the loose application of the

ORDBMS label). ERDBMS products provide a

relational data model and query language that have

been extended to include many of the features that

are typical of ODBMSs.

OVERVIEW OF EXTENDED RDBMS

Extending the query language allows for the integration

of well-understood query optimization techniques.

Typically, programming capabilities are embedded in

the query language. This capability is not to be

confused with stored procedures that are provided by a

number of relational vendors. With the ERDBMSs,

programmers are able to write functions in

conventional languages as well as in SQL. These

functions can then be embedded in standard SQL

statements in exactly the same manner as a DBMS

vendor function (e.g., the Sybase getdate() function).

FEATURE OF EXTENDED RDBMS

Most significantly, these DBMSs have been extended to handle:

complex data types, which include user defined abstract

data types,

non-tabular structures,

automatically generated, logical object identifiers,

tables within tables,

a type hierarchy,

multiple inheritance,

compound objects,

schema evolution,

transitive closure operations.

FEATURE OF EXTENDED RDBMS

In our experience, applications developed using the extended relational

database are far less difficult to build, and are easier to understand

conceptually than those built using a traditional RDBMS (cf. Rolodex™

card example). Typically, developers using the IBM U2 extended

RDBMS as the foundation of their application can easily transfer the

business model (banking transaction, point of sale, etc) directly into

extended relational table(s). This allows for rapid application

development, maintenance and customization. Traditional RDBMS

developers must first transform the business model into a normalized

set of tables. Using the IBM U2 extended relational database, the

developer is not required to have knowledge of SQL, and the more

complex C programming language. However, both styles of

development are supported, if required

CHRACTRICITRCS OF EXTENDED RDBMS

For server-based application logic, the IBM U2 extended

relational database uses BASIC for its stored procedure

language. Thus, adopting the use of the IBM U2 extended

relational database technology is straightforward and does

not require an Engineer level programmer to either

understand the database, or develop the applications. On

the client-side, the IBM U2 extended relational database

supports industry standard tools such as Microsoft® Visual

Studio, Studio and WebSphere® Application Developer,

via JDBC, ODBC, OLE DB provider, and native C, Java™

and .NET APIs. Most client tools today support one or

more of these technologies.


The extended relational database uses the predominant

standards associated with UNIX®, Linux™ and

Windows™-based systems for its networking layer. The

IBM U2 extended RDBMS provides homogeneous

distributed database capabilities. Additionally, using its

database gateway interface (BCI), it can update

heterogeneous databases such as Microsoft SQL Server,

Oracle, Sybase, etc. using standard ODBC interfaces. The

latest release of UniData provides a tightly coupled I/O

level interface to IBM DB2® UDB via its External Database

Access (EDA) technology.


IBM U2 supports row level locking facilities, either through

implicit SQL usage, or through explicit control from within

its stored procedure language. Page level locks, common

to other RDBMS products, do not hamper the IBM U2

extended RDBMS. It provides many levels of lock

granularity. Within this same environment, the IBM U2

extended RDBMS implements all ANSI 1992 Isolation

levels, for ACID-compliant transaction processing. Due to

its lock granularity, the IBM U2 extended relational

database can support very large database installations,

with high accessibility, data integrity, and large numbers of

concurrent users.


The extended RDBMS files (tables) have an automatic table space

allocation capability, which dynamically adjusts for optimal size, and

hence performance, without fragmentation. Each file can grow to a

size dictated by the available operating file system. Coupled with its

inherently self tuning architecture, and low memory requirement,

extended relational databases do not require intensive monitoring,

continual tuning and time consuming maintenance tasks.

The extended RDBMS provides all the industry standard capabilities

for database integrity, including transaction logging, warm-start

recovery and check pointing. These features prevent database

corruption from occurring in the event of a hardware failure. In

addition, the IBM U2 extended RDBMS works with all levels of RAID

disk arrays to provide additional database robustness.


The mapping of the object model can, in some

cases, be greatly simplified (e.g., indentured

parts list) with ERDBMS products. But, mapping

is still required at both the model and the

language level. This raises risk and

development cost considerations similar to those

of an RDBMS.

RISK OF EXTENDED RDBMS

The cost of having to actually implement the

mapping software can be mitigated through the

ODBC interface, which most of these products

support. However, some of the extended features

of the ERDBMS are not visible through an ODBC

interface. Thus, custom interface code is

frequently required to fully utilize the services

provided. Again, risk and development costs must

be considered.


Third party or vendor tools are available to handle the

processing of some of the more common complex data

types (e.g., time series, spatial, text, image, sound). But if

such software is not available for a required data type, the

good news is that it can be written. The bad news is that

this custom code is frequently non-trivial to write. Writing

complex custom code can add significant risk and

development costs to the project. Also consider the

question of the instability that can be introduced to the

ERDBMS through these custom software components.


Database

Technology

Transcript of Database