Database Management System
Database Management System
Relational Model
Its central idea was to describe a database as a collection of predicates over a finite set of predicate variables,
describing constraints on the possible values and combinations of values. The content of the database at any given time is a
finite (logical) model of the database, i.e. a set of relations, one per predicate variable, such that all predicates are satisfied.
A request for information from the database (a database query) is also a predicate.
The purpose of the relational model is to provide a declarative method for specifying data and queries: we directly state what
information the database contains and what information we want from it, and let the database management system software
take care of describing data structures for storing the data and retrieval procedures for getting queries answered
The diagrams and documentation generated during logical modeling is used to determine whether the requirements of the
business have been completely gathered. Management, developers, and end users alike review these diagrams and
documentation to determine if more work is required before physical modeling commences.
Typical deliverables of logical modeling include
Entity relationship diagrams: An Entity Relationship Diagram is also referred to as an analysis ERD. The point of the
initial ERD is to provide the development team with a picture of the different categories of data for the business, as well
as how these categories of data are related to one another.
Business process diagrams: The process model illustrates all the parent and child processes that are performed by
individuals within a company. The process model gives the development team an idea of how data moves within the
organization. Because process models illustrate the activities of individuals in the company, the process model can be
used to determine how a database application interface is design.
User feedback documentation
Physical Modeling
Physical modeling involves the actual design of a database according to the requirements that were established during
logical modeling. Logical modeling mainly involves gathering the requirements of the business, with the latter part of logical
modeling directed toward the goals and requirements of the database. Physical modeling deals with the conversion of the
logical, or business model, into a relational database model. When physical modeling occurs, objects are being defined at the
schema level. A schema is a group of related objects in a database. A database design effort is normally associated with one
schema.
During physical modeling, objects such as tables and columns are created based on entities and attributes that were defined
during logical modeling. Constraints are also defined, including primary keys, foreign keys, other unique keys, and check
constraints. Views can be created from database tables to summarize data or to simply provide the user with another
perspective of certain data. Other objects such as indexes and snapshots can also be defined during physical modeling.
Physical modeling is when all the pieces come together to complete the process of defining a database for a business.
Physical modeling is database software specific, meaning that the objects defined during physical modeling can vary
depending on the relational database software being used. For example, most relational database systems have variations
with the way data types are represented and the way data is stored, although basic data types are conceptually the same
among different implementations. Additionally, some database systems have objects that are not available in other database
systems.
Typical deliverables of physical modeling include the following:
Server model diagrams
The server model diagram shows tables, columns, and relationships within a database.
User feedback documentation
Database design documentation
The implementation of the physical model is dependent on the hardware and software being used by the company. The
hardware can determine what type of software can be used because software is normally developed according to common
hardware and operating system platforms. Some database software might only be available for Windows NT systems,
whereas other software products such as Oracle are available on a wider range of operating system platforms, such as UNIX.
The available hardware is also important during the implementation of the physical model because data is physically
distributed onto one or more physical disk drives. Normally, the more physical drives available, the better the performance of
the database after the implementation. Some software products now are Java-based and can run on virtually any platform.
Typically, the decisions to use particular hardware, operating system platforms, and database software are made in
conjunction with one another.
UNIVERSE OF DISCOURSE
A database is a model of some aspect of the reality of an organization (Kent, 1978). It is conventional to call this reality a
universe of discourse (UoD), or sometimes a domain of discourse. A UoD will be made up of classes and relationships
between classes. The classes in a UoD will be defined in terms of their properties or attributes.
A database of whatever form, electronic or otherwise, must be designed. The process of database design is the activity of representing classes,
attributes and relationships in a database.
PERSISTENCE
Data in a database is described as being persistent. By persistent we mean that the data is held for some duration. The
duration may not actually be very long. The term persistence is used to distinguish more permanent data from data which is
more transient in nature. Hence, product data, account data, patient data and student data would all normally be regarded
as examples of persistent data. In contrast, data input at a personal computer, held for manipulation within a program, or
printed out on a report, would not be regarded as persistent, as once it has been used it is no longer required.
INTENSIONAL AND EXTENSIONAL PARTS
A database is made up of two parts: an intentional part and an extensional part. The intension of a database is a set of
definitions which describe the structure or organization of a given database. The extension of a database is the total set of
data in the database. The intension of a database is also referred to as its schema. The activity of developing a schema for a
database system is referred to as database design.
INTEGRITY
When we say that a database displays integrity we mean that it is an accurate reflection of its UoD. The process of ensuring
integrity is a major feature of modern information systems. The process of designing for integrity is a much neglected aspect
of database development.
Integrity is an important issue because most databases are designed, once in use, to change. In other words, the data in a
database will change over a period of time. If a database does not change, i.e. it is only used for reference purposes, then
integrity is not an issue of concern.
INTEGRITY CONSTRAINTS
Database integrity is ensured through integrity constraints. An integrity constraint is a rule which establishes how a database is to remain an
accurate reflection of its UoD.
Constraints may be divided into two major types: static constraints and transition constraints (see Figure 1.4). A static constraint, sometimes
known as a ‘state invariant’, is used to check that an incoming transaction will not change a database into an invalid state. A static constraint
is a restriction defined on states.
TRANSACTIONS
The events that cause a change of state are called transactions in database terms. A transaction changes a database from
one state to another. A new state is brought into being by asserting the facts that become true and/or denying the facts that
cease to be true. Hence, in our example we might want to enrol Peter Jones in the module relational database design. This is
an example of a transaction. Transactions of a similar form are called transaction types.
The Object-Oriented Data Model
1. A data model is a logic organization of the real world objects (entities), constraints on them, and the relationships among
objects. A DB language is a concrete syntax for a data model. A DB system implements a data model.
2. A core object-oriented data model consists of the following basic object-oriented concepts:
(1) object and object identifier: Any real world entity is uniformly modeled as an object (associated with a unique id:
used to pinpoint an object to retrieve).
(2) attributes and methods: every object has a state (the set of values for the attributes of the object) and a behavior
(the set of methods - program code - which operate on the state of the object). The state and behavior encapsulated in an
object are accessed or invoked from outside the object only through explicit message passing.
[ An attribute is an instance variable, whose domain may be any class: user-defined or primitive. A class composition
hierarchy (aggregation relationship) is orthogonal to the concept of a class hierarchy. The link in a class composition
hierarchy may form cycles. ]
(3) class: a means of grouping all the objects which share the same set of attributes and methods. An object must belong to
only one class as an instance of that class (instance-of relationship). A class is similar to an abstract data type. A class may
also be primitive (no attributes), e.g., integer, string, Boolean.
(4) Class hierarchy and inheritance: derive a new class (subclass) from an existing class (superclass). The subclass
inherits all the attributes and methods of the existing class and may have additional attributes and methods. single
inheritance (class hierarchy) vs. multiple inheritance (class lattice).
What are the disadvantages of object oriented data model?
Unfamiliarity (causing an added training cost for developers), Inability to work with existing systems (a major benefit of C+
+), Data and operations are separated, No data abstraction or info hiding, Not responsive to changes in problem space
Inadequate for concurrent problems