Hierarchical
A hierarchical database model is a data model in which the data is organized into a tree-like structure. The structure allows
representing information using parent/child relationships: each parent can have
many children, but each child has only one parent (also known as a 1-to-many relationship). All
attributes of a specific record are listed under an entity type.
Example of
a hierarchical model
In a database an entity type is
the equivalent of a table. Each individual record is represented as a row, and
each attribute as a column. Entity types are related to each other using 1:N mappings, also known as one-to-many relationships. This model
is recognized as the first database model created by IBM in the 1960s.
Network model
The network
model is a database model conceived as a
flexible way of representing objects and their relationships. Its
distinguishing feature is that the schema, viewed as a graph in which object
types are nodes and relationship types are arcs, is not restricted to being a
hierarchy or lattice.
Difference between network and
hierarchical model
The hierarchical model we can identify that it
used a method for storing data in a database that looks like a family tree with
one root and a number of branches or subdivisions. That's why we can say that
record types are organized in the form of a rooted tree. But in network model
we can identify multiple branches emanating from one or more nodes. So
sometimes it is like a like several trees which share branches. In relational
model is that of a relation. Relation is a two-dimensional table. So the table
can be used to represent some entity information or some relationship between
them
In hierarchical model only one-to-many or
one-to-one relationships can be exist. But in network data model makes it
possible to map many to many relationships In relational each record can have
multiple parents and multiple child records. In effect, it supports many to
many relationships
Relational model
The relational model for database management
is a database model based on first-order
predicate logic, first formulated and proposed in 1969 byEdgar F. Codd.[1][2] In the
relational model of a database, all data is represented in terms of tuples, grouped
into relations. A database organized in terms
of the relational model is a relational database.
Diagram of
an example database according to the Relational model
In the
relational model, related records are linked together with a "key".
The purpose of the relational model is to provide a declarative method for specifying
data and queries: users directly state what information the database contains
and what information they want from it, and
let the database management
system software take care of describing data structures for storing the data
and retrieval procedures for answering queries.
Most relational databases use the SQL data definition and query language; these
systems implement what can be regarded as an engineering approximation to the
relational model. A table in
an SQL database schema corresponds to a predicate variable; the contents of a
table to a relation; key constraints, other constraints, and SQL queries
correspond to predicates. However, SQL databases, including DB2, deviate from the
relational model in many details, and Codd fiercely argued
against deviations that compromise the original principles.
Object database
An object
database (also object-oriented database management
system) is a database management
system in which information is represented in the form
of objects as used in object-oriented
programming. Object databases are different from relational databases which are table-oriented. Object-relational databases are a hybrid of
both approaches.
OODBMS Advantages
·
Enriched modeling capabilitiesƒ
·
Extensibility
·
Support for schema evolution.
·
Applicable for advanced database applications
·
Improved performance.
OODBMS Disadvantages
·
Lack of a universal data model?ƒ
·
Ad-hoc querying compromises encapsulation.
·
Locking at object-level impacts performanceƒ
·
Complexityƒ
·
Lack of support for viewsƒ
·
Lack of support for security
Semi-structured
The semi-structured model is a database model where
there is no separation between the data and the schema, and the
amount of structure used depends on the purpose.
The advantages of this model are
the following:
·
It can represent the information of some data sources that cannot
be constrained by schema.
·
It provides a flexible format for data exchange between different
types of databases.
·
It can be helpful to view structured data as semi-structured (for
browsing purposes).
·
The schema can easily be changed.
·
The data transfer format may be portable.
The primary trade-off being made
in using a semi-structured database model is that
queries cannot be made as efficient as in a more constrained structure, such as
in the relational model. Typically the records in a
semi-structured database are stored with unique IDs that are referenced with
pointers to their location on disk. This makes navigational or path-based
queries quite efficient, but for doing searches over many records (as is
typical in SQL), it is
not as efficient because it has to seek around the disk following pointers.
Data that resides in a fixed
field within a record or file is called structured data. This includes data
contained in relational databases and spreadsheets.
Structured data first depends on
creating a data model – a model of the types of business data that will be
recorded and how they will be stored, processed and accessed. This includes
defining what fields of data will be stored and how that data will be stored:
data type (numeric, currency, alphabetic, name, date, address) and any
restrictions on the data input (number of characters; restricted to certain
terms such as Mr., Ms. or Dr.; M or F).
Structured data has the advantage
of being easily entered, stored, queried and analyzed. At one time, because of
the high cost and performance limitations of storage, memory and processing,
relational databases and spreadsheets using structured data were the only way
to effectively manage data. Anything that couldn't fit into a tightly organized
structure would have to be stored on paper in a filing cabinet.
Types of Semi-structured data
XML
XML other
markup languages, email, and EDI are all forms of semi-structured
data. OEM (Object Exchange Model) was
created prior to XML as a means of self-describing a data structure. XML has
been popularized by web services that are developed utilizing SOAP principles.
Some types of data described here
as "semi-structured", especially XML, suffer from the impression that
they are incapable of structural rigor at the same functional level as
Relational Tables and Rows. Indeed, the view of XML as inherently
semi-structured (previously, it was referred to as "unstructured")
has handicapped its use for a widening range of data-centric applications. Even
documents, normally thought of as the epitome of semi-structure, can be
designed with virtually the same rigor as database schema, enforced by the XML
schema and processed by both commercial and custom software programs without
reducing their usability by human readers.
JSON
JSON or
JavaScript Object Notation, is an open standard format that uses human-readable
text to transmit data objects consisting of attribute–value pairs. It is used
primarily to transmit data between a server and web application, as an
alternative to XML. JSON has been popularized by web services developed
utilizing REST principles.
No comments:
Post a Comment