The database model is a data model type that determines the logical structure of a database and basically determines where data can be stored, organized and manipulated. The most popular example of a database model is the relational model, which uses a table-based format.
Video Database model
Example
Common logical data models for databases include:
- Hierarchical database model
This is the oldest form of the database model. It was developed by IBM for IMS (Information Management System). This is a set of data organized in a tree structure. The DB record is a tree consisting of many groups called segments. It uses one to many relationships. Data access is also predictable.
- Network model
- Relational model
- Entity relationship model
- Enhanced entity-relationship model
- Object model
- Document model
- The attribute value model
- Star scheme
The object-relational database combines two related structures.
Physical data models include:
- Reverse Index
- Flat files
Other models include:
- Associative model
- Correlational model
- Multidimensional models
- Multivalue model
- Semantic model
- XML databases
- Graphic named
- Triplestore
Maps Database model
Relationships and functions
A given database management system can provide one or more models. The optimal structure depends on the natural organization of the application data, and on the application requirements, which include transaction rate (speed), reliability, maintenance, scalability, and cost. Most database management systems are built around one particular data model, although it is possible for the product to offer support for more than one model.
Various physical data models can implement any given logical model. Most database software will offer users some level of control in physical implementation settings, since the choices made have a significant effect on performance.
The model is not just a way of structuring data: it also defines a series of operations that can be performed on the data. The relational model, for example, defines operations such as selecting (project) and joining. While these operations may not be explicit in a given query language, they provide the foundation upon which the query language is created.
Flat model
The flat model (or table) consists of one, two dimensional array of data elements, where all members of a given column are assumed to be the same value, and all line members are assumed to be related to each other. For example, a column for names and passwords that can be used as part of a system security database. Each row will have a special password associated with individual users. Table columns often have a type associated with them, defines them as character data, date or time information, integers, or floating point numbers. This tabular format is the precursor to the relational model.
Initial data model
These models were popular in the 1960s, 1970s, but today can be found primarily in old legacy systems. They are characterized primarily by being navigated with a strong connection between their logical and physical representation, and a lack in data independence.
Hierarchical model
In a hierarchical model, the data is organized into a tree-like structure, implying a single parent for each record. Such fields store sibling data in a particular order. Hierarchical structures are widely used in early mainframe database management systems, such as the Information Management System (IMS) by IBM, and now describe the structure of XML documents. This structure allows one to many links between two types of data. This structure is very efficient to describe many relationships in the real world; recipes, table of contents, ordering paragraphs/verses, nested and sorted information.
This hierarchy is used as a physical sequence of records in storage. Record access is done by navigating down through the data structure using a pointer combined with sequential access. Because of this, the hierarchical structure is inefficient for certain database operations when the complete path (as opposed to the upward link and the sorting field) is not also included for each record. Such limitations have been compensated in later IMS versions by additional logical hierarchies imposed on the basic physical hierarchy.
Network model
The network model expands the hierarchical structure, allowing many-to-many relationships in tree-like structures that allow many parents. It's most popular before being replaced by a relational model, and is defined by the CODASYL specification.
The network model organizes data using two basic concepts, called record and set . Notes contain fields (which can be arranged hierarchically, as in COBOL programming language). Set (not to be confused with a mathematical set) specify a one-to-many relationship between records: one owner, multiple members. A record can be an owner in a set number, and a member in a set number.
A set consists of a circular linked list in which a single type of record, owner or parent is set, appears once in each circle, and a second, subordinate or child record type can appear multiple times in each circle. In this way, a hierarchy can be created between two types of records, for example, type A is the owner of B. At the same time, another set can be specified where B is the owner A. So all sets consist of generally directed graphs (Ownership determine direction), or build a network . Access to recordings is sequential (usually in any type of recording) or by navigation in a circular linked list.
Network models are able to represent redundancy in data more efficiently than hierarchical models, and there is more than one path from the ancestral to the genetic knot. Network model operation is navigation: a program maintains its current position, and navigates from one record to another by following the relationship in which the note participates. Records can also be found by providing key values.
Although it is not an important feature of the model, network databases generally implement relationships that are set up by way of a pointer that directly handles the location of records on the disk. It provides excellent retrieval performance, at the expense of operations such as database loading and reorganization.
Popular DBMS products that use it are IDMS Total and Cullinet from Cincom Systems. IDMS gained a sizable customer base; in the 1980s, he adopted relational and SQL models in addition to the original tools and languages.
Most database objects (created in the 1990s) use the concept of navigation to provide fast navigation across the network of objects, generally using object identifiers as "smart" pointers to related objects. Objectivity/DB, for example, implements the names of one-to-one, one-to-many, many-to-one, and many-to-many relationships that can traverse the database. Many database objects also support SQL, combining the strengths of both models.
Inverted file model
In the inverted or inverted index file, the data content is used as the key in the lookup table, and the values ​​in the table are pointers to the location of each instance of the given content. It is also a logical structure of the contemporary database index, which may only use the content of a particular column in the lookup table. The reverse file data model can place an index in the second set of files alongside an existing flat file database, to efficiently directly access the required records in these files.
Notable for using this data model is ADABAS DBMS Software AG, introduced in 1970. ADABAS has gained a substantial and existing subscriber base and is supported to date. In the 1980s it has adopted relational and SQL models in addition to the original tools and languages.
Document-oriented database Clusterpoint uses an inverted indexing model to provide fast, full text search for XML or JSON data objects and to provide scale capability for Big data. Clusterpoint has a built-in computing engine that enables the combined execution of SQL queries, free text search and JavaScript code right inside a distributed database. Both reversed data and index via sharding and replication that can be changed can be distributed to a large number of servers to support billions of data objects in the same Clusterpoint database. The Clusterpoint JS/SQL query language integrates SQL and JavaScript syntax with full-text search, where inverted index is used to generate search performance of the millisecond distance text and relevant pagination in web and mobile applications. In the Clusterpoint database architecture index also supports a programmable relevance ranking that allows to customize search output without extra coding effort. Similarly for relational databases, Clusterpoint supports distributed ACID-compliant database transactions for consistent strong document databases, where reversed index data is immediately updated as long as XML document or JSON document content updates. The upside index is also used to support near Big-time real-time data reporting, analytics, drill-down and data mining over the REST API in the Clusterpoint database.
Relational model
Relational model introduced by E.F. Codd in 1970 as a way to make database management systems more independent of specific applications. This is a mathematical model defined in terms of predicate logic and established theory, and the system that implements it has been used by mainframe, midrange and microcomputer systems.
The product generally referred to as a relational database in fact implements a model that is merely an approximation to a mathematical model defined by Codd. The three main terms are used extensively in relational database models: relationships , attributes , and domains . Relation is a table with columns and rows. The named relation column is called an attribute, and the domain is the set of attribute values ​​that are allowed to be retrieved.
The basic data structure of the relational model is the table, where information about a particular entity (eg, an employee) is represented in rows (also called tuples) and columns. Thus, "relation" in "relational database" refers to the various tables in the database; the relation is a set of tuples. Columns mention various entity attributes (employee name, address or phone number, for example), and rows are real examples of entities (certain employees) represented by their relations. As a result, each employee table tuple represents the various attributes of an employee.
All relations (and, thus, tables) in a relational database must adhere to some ground rules to qualify as relations. First, sorting a column is not material in a table. Secondly, there can be no identical tuples or rows in a table. And thirdly, each tuple will contain a single value for each of its attributes.
Relational databases contain multiple tables, each similar to those in the "flat" database model. One of the strengths of the relational model is that, in principle, any value that occurs in two different records (belonging to the same table or different table), implies the relationship between the two records. However, to enforce explicit integrity constraints, the relationship between records in the table can also be defined explicitly, by identifying or not identifying parent-child relationships characterized by establishing cardinality (1: 1, (0) 1: M, M: M). Tables can also have a single set attribute or set of attributes that can act as "keys", which can be used to identify each tuple uniquely in the table.
A key that can be used to identify rows uniquely in a table is called a primary key. A key is usually used to merge or aggregate data from two or more tables. For example, the Employee table may contain a column named Location that contains a value that matches the Location table key. Keys are also important in index creation, which facilitate quick retrieval of data from large tables. Any column can be a key, or multiple columns can be grouped together into compound keys. There is no need to define all the keys first; columns can be used as keys even if originally not meant to be one.
Keys that have an external meaning, the real world (such as a person's name, a book ISBN, or car serial number) are sometimes called "natural" keys. If no natural key matches (think many people named Brown ), an arbitrary or alternate key can be set (such as by assigning an employee ID number). In practice, most databases have generated and natural keys, since the generated keys can be used internally to create links between rows that can not be damaged, while natural keys can be used, less trustworthy, for search and for integration with other databases. (For example, records in two independently developed databases can be matched with social security numbers, except when social security numbers are wrong, lost, or changed.)
The most commonly used query language with a relational model is Structured Query Language (SQL).
Dimension model
The dimension model is a special adaptation of the relational model used to represent data in a data warehouse in a way that data can be easily summarized using online analytic processes, or OLAP questions. In dimension models, the database schema consists of a large table of facts described using dimensions and sizes. Dimensions provide the context of facts (such as who participates, when and where they occur, and type) and are used in questions to group related facts together. Dimensions tend to be discrete and often hierarchical; for example, locations may include buildings, states, and countries. Size is a quantity that describes facts, such as income. It is important that steps can be interpreted meaningfully - for example, revenue from different locations can be added together.
In OLAP queries, dimensions are selected and facts are grouped and combined together to create a summary.
The dimensional model is often implemented on top of a relational model using a star schema, which consists of a highly normalized table containing facts, and a surrounding denormalization table containing each dimension. An alternative physical implementation, called the snowflake scheme, normalizes the multi-level hierarchy in a dimension into multiple tables.
A data warehouse can contain multiple dimension schemes that share dimension tables, allowing them to be shared. Coming up with a set of standard dimensions is an important part of dimensional modeling.
Its high performance has made the most popular database structure dimension model for OLAP.
Post-relational database model
Products that offer a more general data model than a relational model are sometimes classified as post-relational . Alternative terms include "database hybrid", "Object-enhanced RDBMS" and others. The data model in these products combines relationships but is not limited by E.F. Codd's Information Principle, which requires it
all the information in the database must be thrown explicitly in terms of values ​​in the relationship and no other way
Some extensions to the relational model integrate the concepts of technology that pre-date the relational model. For example, they allow representation of directed graphs with trees in nodes. The German company sone implements this concept in its GraphDB.
Some post-relational products extend relational systems with non-relational features. Others arrive at the same place by adding relational features to the pre-relational system. Paradoxically, this allows historically pre-relational products, such as SELECT and MUMPS, to make sensible claims to be post-relational.
Resource space model (RSM) is a non-relational data model based on multi-dimensional classification.
Graphical model
Graphical databases allow more general structure than network databases; any node can be connected to another node.
Multivalue model
Multivalue databases are "condensed" data, because they can store in exactly the same way as relational databases, but they also allow a depth level that a relational model can only predict using sub-tables. It's almost identical to the way XML expresses data, where certain fields/attributes can have multiple answers right at the same time. Multivalue can be considered as a form of compression from XML.
Examples are invoices, which either in the multivalue or relational values ​​can be seen as (A) Invoice Header Table - one entry per invoice, and (B) Invoice Details Table - one entry per line item. In the multivalue model, we have the option to store data as in the table, with the embedded table to represent the details: (A) Invoice Table - one entry per invoice, no other tables required.
The advantage is that the atomicity of the Invoice (conceptual) and Invoice (data representation) are one-to-one. It also results in fewer readings, less referential integrity issues, and a dramatic decrease in the hardware required to support the volume of transactions provided.
Object-oriented database model
In the 1990s, object-oriented programming paradigms were applied to database technology, creating a new database model known as object databases. It aims to avoid object-relational impedance mismatches - the overhead of converting information between representations in a database (eg as a row in a table) and its representation in the application program (usually as an object). Furthermore, the type system used in a particular application can be defined directly in the database, allowing the database to enforce the same data integrity invariants. The object database also introduces key ideas of object programming, such as encapsulation and polymorphism, into the world of databases.
Various ways have been tried to store objects in the database. Some products have approached the problem from the end of application programming, by making objects manipulated by fixed programs. This usually requires the addition of some kind of query language, since conventional programming languages ​​do not have the ability to find objects based on their information content. Others have attacked the problem from the end of the database, by defining object-oriented data models for databases, and defining database programming languages ​​that enable complete programming capabilities as well as traditional request facilities.
Database objects suffer from lack of standardization: although standards are defined by ODMG, they have never been implemented well enough to ensure interoperability between products. Nevertheless, database objects have been successfully used in many applications: typically specialized applications such as engineering databases or molecular biology databases rather than primary commercial data processing. However, the object database ideas are taken by relational vendors and affect the extensions made to these products and indeed to the SQL language.
The alternative to translating between relational objects and databases is by using the object-relational mapping library (ORM).
References
Source of the article : Wikipedia
0 Comments