Date post: | 13-Dec-2014 |
Category: |
Technology |
Upload: | zahid-soomro |
View: | 1,182 times |
Download: | 3 times |
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.
CHRACTRICITRCS OF EXTENDED RDBMS
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.
CHRACTRICITRCS OF EXTENDED RDBMS
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.
CHRACTRICITRCS OF EXTENDED RDBMS
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.
CHRACTRICITRCS OF EXTENDED RDBMS
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.
RISK OF EXTENDED RDBMS
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.
RISK OF EXTENDED RDBMS