Database Models
The common models include
Network Model
The popularity of the network
data model coincided with the popularity of the hierarchical data model. Some
data were more naturally modeled with more than one parent per child. So, the
network model permitted the modeling of many-to-many relationships in data. In
1971, the Conference on Data Systems Languages (CODASYL) formally defined the
network model. The basic data modeling construct in the network model is the set
construct. A set consists of an owner record type, a set name, and a member
record type. A member record type can have that role in more than one set, hence
the multiparent concept is supported. An owner record type can also be a member
or owner in another set. The data model is a simple network, and link and
intersection record types (called junction records by IDMS) may exist, as well
as sets between them . Thus, the complete network of relationships is
represented by several pairwise sets; in each set some (one) record type is
owner (at the tail of the network arrow) and one or more record types are
members (at the head of the relationship arrow). Usually, a set defines a 1:M
relationship, although 1:1 is permitted. The CODASYL network model is based on
mathematical set theory.
Hierarchical Model
The hierarchical data
model organizes data in a tree structure. There is a hierarchy of parent and
child data segments. This structure implies that a record can have repeating
information, generally in the child data segments. Data in a series of records,
which have a set of field values attached to it. It collects all the instances
of a specific record together as a record type. These record types are the
equivalent of tables in the relational model, and with the individual records
being the equivalent of rows. To create links between these record types, the
hierarchical model uses Parent Child Relationships. These are a 1:N mapping
between record types. This is done by using trees, like set theory used in the
relational model, "borrowed" from maths. For example, an organization might
store information about an employee, such as name, employee number, department,
salary. The organization might also store information about an employee's
children, such as name and date of birth. The employee and children data forms a
hierarchy, where the employee data represents the parent segment and the
children data represents the child segment. If an employee has three children,
then there would be three child segments associated with one employee segment.
In a hierarchical database the parent-child relationship is one to many. This
restricts a child segment to having only one parent segment. Hierarchical DBMSs
were popular from the late 1960s, with the introduction of IBM's Information
Management System (IMS) DBMS, through the 1970s.
Relational Model
(RDBMS - relational database
management system) A database based on the relational model developed by E.F. Codd. A relational database allows the definition of data structures, storage and retrieval operations and integrity constraints. In such a database the data and relations between them are organised in tables. A table is a collection of records and each record in a table contains the same fields.
Properties of Relational Tables:
# Values Are
Atomic
# Each Row is Unique
# Column Values Are of the Same Kind
# The
Sequence of Columns is Insignificant
# The Sequence of Rows is
Insignificant
# Each Column Has a Unique Name
Certain fields may be designated as keys,
which means that searches for specific values of that field will use indexing to
speed them up. Where fields in two different tables take values from the same
set, a join operation can be performed to select related records in the two
tables by matching values in those fields. Often, but not always, the fields
will have the same name in both tables. For example, an "orders" table might
contain (customer-ID, product-code) pairs and a "products" table might contain
(product-code, price) pairs so to calculate a given customer's bill you would
sum the prices of all products ordered by that customer by joining on the
product-code fields of the two tables. This can be extended to joining multiple
tables on multiple fields. Because these relationships are only specified at
retreival time, relational databases are classed as dynamic database management
system. The RELATIONAL database model is based on the Relational Algebra.
Object-Oriented Model
Object
DBMSs add database functionality to object programming languages. They bring
much more than persistent storage of programming language objects. Object DBMSs
extend the semantics of the C++, Smalltalk and Java object programming languages
to provide full-featured database programming capability, while retaining native
language compatibility. A major benefit of this approach is the unification of the application and database development into a seamless data model and language environment. As a result, applications require less code, use more natural data modeling, and code bases are easier to maintain. Object developers can write complete database applications with a modest amount of additional effort.
According to Rao (1994), "The
object-oriented database (OODB) paradigm is the combination of object-oriented
programming language (OOPL) systems and persistent systems. The power of the
OODB comes from the seamless treatment of both persistent data, as found in
databases, and transient data, as found in executing programs." In contrast to a
relational DBMS where a complex data structure must be flattened out to fit into
tables or joined together from those tables to form the in-memory structure,
object DBMSs have no performance overhead to store or retrieve a web or
hierarchy of interrelated objects. This one-to-one mapping of object programming
language objects to database objects has two benefits over other storage
approaches: it provides higher performance management of objects, and it enables
better management of the complex interrelationships between objects. This makes
object DBMSs better suited to support applications such as financial portfolio
risk analysis systems, telecommunications service applications, world wide web
document structures, design and manufacturing systems, and hospital patient
record systems, which have complex relationships between data.
Next