1.Hierarchical Model
A hierarchical data model is a data model in which the data is organized into a tree-like structure. The structure allows repeating information using parent/child relationships: each parent can have many children but each child only has one parent. All attributes of a specific record are listed under an entity type.
2.Network Model
The popularity of the Network data Model coincided with the popularity of the hierachical data model.Some data were more naturally modeled with more than one parent per child.
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.
3.Relational Model
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.
The model organize all the data into the tables.The rows indicate data records, while the columns indicate the fields of the records.The whole table describe the information of an entity in real word.
4.Object/Relational Model
Object/relational database management systems (ORDBMSs) add new object storage capabilities to the relational systems at the core of modern information systems. These new facilities integrate management of traditional fielded data, complex objects such as time-series and geospatial data and diverse binary media such as audio, video, images, and applets. By encapsulating methods with data structures, an ORDBMS server can execute comple x analytical and data manipulation operations to search and transform multimedia and other complex objects.
As an evolutionary technology, the object/relational (OR) approach has inherited the robust transaction- and performance-management features of it s relational ancestor and the flexibility of its object-oriented cousin.
5.Object-Oriented Model
The object-oriented approach is based on the integration of database development and application into a seamless language environment and data model. In comparison to the relational approach, object DBMSs have no performance management overhead to store or retrieve a hierarchy of objects that are interrelated. With the help of this approach software development service require less code to build applications. Developers can easily maintain code bases and use more natural data modeling. Thus, application developers can write complex database applications with a minimum effort.
6.Semistructured Model
In semistructured data model, the information that is normally associated with a schema is contained within the data, which is sometimes called ``self-describing''. In such database there is no clear separation between the data and the schema, and the degree to which it is structured depends on the application. In some forms of semistructured data there is no separate schema, in others it exists but only places loose constraints on the data. Semi-structured data is naturally modelled in terms of graphs which contain labels which give semantics to its underlying structure. Such databases subsume the modelling power of recent extensions of flat relational databases, to nested databases which allow the nesting (or encapsulation) of entities, and to object databases which, in addition, allow cyclic references between objects.
Semistructured data has recently emerged as an important topic of study for a variety of reasons. First, there are data sources such as the Web, which we would like to treat as databases but which cannot be constrained by a schema. Second, it may be desirable to have an extremely flexible format for data exchange between disparate databases. Third, even when dealing with structured data, it may be helpful to view it as semistructured for the purposes of browsing.
xml is an efficient way to store the semistructured data.
7.Associative Model
The associative model divides the real-world things about which data is to be recorded into two sorts:
Entities are things that have discrete, independent existence. An entity’s existence does not depend on any other thing. Associations are things whose existence depends on one or more other things, such that if any of those things ceases to exist, then the thing itself ceases to exist or becomes meaningless.
An associative database comprises two data structures:
1. A set of items, each of which has a unique identifier, a name and a type.
2. A set of links, each of which has a unique identifier, together with the unique identifiers of three other things, that represent the source source, verb and target of a fact that is recorded about the source in the database. Each of the three things identified by the source, verb and target may be either a link or an item.
Here's how the associative model would use these two structures to store the piece of information Flight BA1234 arrived at London Heathrow on 12-Dec-05 at 10:25am. There are seven items: the four nouns Flight BA1234, London Heathrow, 12-Dec-05 and 10:25am, and the three verbs arrived at, on and at. We need three links to store the data. They are:
Flight BA1234 arrived at Heathrow Airport
... on 12-Dec-05
... at 10:25am
The first link has Flight BA1234 as its source, arrived at as its verb and Heathrow Airport as its target. The second link has the first link as its source, on as its verb and the item 12-Dec-05 as its target. (A link that begins with an ellipsis "..." has the previous link as its source.) The third link has the second link as its source, at as its verb and 10:25am as its target.
Here's an alternative way to write the same thing using parentheses:
((Flight BA1234 arrived at Heathrow Airport) on 12-Dec-05) at 10:25am
An associative database may be regarded as comprising two tables: one for items and one for links. Each item and each link has an abitrary number (called a surrogate) as an identifier
|
Items |
|
Identifier |
Name |
|
77 |
Flight BA1234 |
|
08 |
London Heathrow |
|
32 |
12-Dec-05 |
|
48 |
10:25am |
|
12 |
arrived at |
|
67 |
on |
|
09 |
at |
|
Links |
|
Identifier |
Source |
Verb |
Target |
|
74 |
77 |
12 |
08 |
|
03 |
74 |
67 |
32 |
|
64 |
03 |
09 |
48 |
8.Entity-Attribute-Value(EAV)data Model
Entity-Attribute-Value model (EAV), also known as object-attribute-value model and open schema is a data model that is used in circumstances where the number of attributes (properties, parameters) that can be used to describe a thing (an "entity" or "object") is potentially vast, but the number that will actually apply to a given entity is relatively modest. In mathematics, this model is known as a sparse matrix.
The most well-known example of EAV modeling in production databases is seen with the clinical findings (past history, present complaints, physical examination, lab tests, special investigations, diagnoses) that can apply to a patient. Across all specialties of medicine, these can range in the hundreds of thousands (with new tests being developed every month). The majority of individuals who visit a doctor, however, have relatively few findings.
9.Context Model
The context data model combines features of all the above models. It can be considered as a collection of object-oriented, network and semistructured models or as some kind of object database. In other words this is a flexible model, you can use any type of database structure depending on task. Such data model has been implemented in DBMS ConteXt.
The fundamental unit of information storage of ConteXt is a CLASS. Class contains METHODS and describes OBJECT. The Object contains FIELDS and PROPERTY. The field may be composite, in this case the field contains SubFields etc. The property is a set of fields that belongs to particular Object. (similar to AVL database). In other words, fields are permanent part of Object but Property is its variable part.
The header of Class contains the definition of the internal structure of the Object, which includes the description of each field, such as their type, length, attributes and name. Context data model has a set of predefined types as well as user defined types. The predefined types include not only character strings, texts and digits but also pointers (references) and aggregate types (structures).
![]()
A context model comprises three main data types: REGULAR, VIRTUAL and REFERENCE. A regular (local) field can be ATOMIC or COMPOSITE. The atomic field has no inner structure. In contrast, a composite field may have a complex structure, and its type is described in the header of Class. The composite fields are divided into STATIC and DYNAMIC. The type of a static composite field is stored in the header and is permanent. Description of the type of a dynamic composite field is stored within the Object and can vary from Object to Object.
Like a NETWORK database, apart from the fields containing the information directly, context database has fields storing a place where this information can be found(parent), i.e. POINTER (link, reference) which can point to an Object in this or another Class. Because main addressed unit of context database is an Object, the pointer is made to Object instead of a field of this Object. The pointers are divided on STATIC and DYNAMIC. All pointers that belong to a particular static pointer type point to the same Class (albeit, possibly, to different Object). In this case, the Class name is an integral part of the that pointer type. A dynamic pointer type describes pointers that may refer to different Classes. The Class, which may be linked through a pointer, can reside on the same or any other computer on the local area network. There is no hierarchy between Classes and the pointer can link to any Class, including its own.
In contrast to pure object-oriented databases, context databases is not so coupled to the programming language and doesn't support methods directly. Instead, method invocation is partially supported through the concept of VIRTUAL fields.
A VIRTUAL field is like a regular field: it can be read or written into. However, this field is not physically stored in the database, and in it does not have a type described in the scheme. A read operation on a virtual field is intercepted by the DBMS, which invokes a method associated with the field and the result produced by that method is returned. If no method is defined for the virtual field, the field will be blank. The METHODS is a subroutine written in C++ by an application programmer. Similarly, a write operation on a virtual field invokes an appropriate method, which can changes the value of the field. The current value of virtual fields is maintained by a run-time process; it is not preserved between sessions. In object-oriented terms, virtual fields represent just two public methods: reading and writing. Experience shows, however, that this is often enough in practical applications. From the DBMS point of view, virtual fields provide transparent interface to such methods via an aplication written by application programer.
A context database that does not have composite or pointer fields and property（flat） is essentially RELATIONAL. With static composite and pointer fields, context database become OBJECT-ORIENTED. If the context database has only Property in this case it is an ENTITY-ATTRIBUTE-VALUE database. With dynamic composite fields, a context database becomes what is now known as a SEMISTRUCTURED database. If the database has all available types... in this case it is ConteXt database!
