Friday, 4 April 2014

Database Model

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.
There is a new breed of databases such as MongoDB and Couchbase that store data natively in JSON format, leveraging the pros of semi-structured data architecture