Editing Data model (section)

== Types ==

=== Database model ===
{{Main|Database model}}

A database model is a specification describing how a database is structured and used.

Several such models have been suggested. Common models include:
; [[Flat-file database|Flat model]]
: This may not strictly qualify as a data model.  The flat (or table) model consists of a single, two-dimensional array of data elements, where all members of a given column are assumed to be similar values, and all members of a row are assumed to be related to one another.
; [[Hierarchical model]]
: The hierarchical model is similar to the network model except that links in the hierarchical model form a tree structure, while the network model allows arbitrary graph.
; [[Network model]]
: This model organizes data using two fundamental constructs, called records and sets. Records contain fields, and sets define one-to-many relationships between records: one owner, many members. The network data model is an abstraction of the design concept used in the implementation of databases.
; [[Relational model]]
: is a database model based on first-order predicate logic. Its core idea is to describe a database as a collection of predicates over a finite set of predicate variables, describing constraints on the possible values and combinations of values. The power of the relational data model lies in its mathematical foundations and a simple user-level paradigm.
; [[Object–relational model]]
: Similar to a relational database model, but objects, classes, and inheritance are directly supported in [[database schema]]s and in the query language.
; [[Object–role modeling]]
: A method of data modeling that has been defined as "attribute free", and "fact-based". The result is a verifiably correct system, from which other common artifacts, such as ERD, UML, and semantic models may be derived. Associations between data objects are described during the database design procedure, such that normalization is an inevitable result of the process.
; [[Star schema]]
: The simplest style of data warehouse schema. The star schema consists of a few "fact tables" (possibly only one, justifying the name) referencing any number of "dimension tables". The star schema is considered an important special case of the [[snowflake schema]].

<gallery class="center">
Image:FigFileConvert000a.svg|[[Flat file database|Flat model]]
Image:Hierarchisches Datenbankmodell.svg|[[Hierarchical model]]
Image:Network DB model.svg|[[Network model]]
Image:Relational model concepts.png|[[Relational model]] 
Image:Company_codm.png|Concept-oriented model 
Image:Star-schema.png|[[Star schema]]
</gallery>

=== Data structure diagram ===
{{Main|Data structure diagram}}
[[File:Aggregate Data Structure Diagram.jpg|thumb|240px|Example of a Data Structure Diagram]]
A data structure diagram (DSD) is a [[diagram]] and data model used to describe [[Conceptual schema|conceptual data models]] by providing graphical notations which document [[entity class|entities]] and their [[Relational model|relationship]]s, and the [[Integrity constraints|constraint]]s that bind them. The basic graphic elements of DSDs are [[box]]es, representing entities, and [[arrow]]s, representing relationships. Data structure diagrams are most useful for documenting complex data entities.

Data structure diagrams are an extension of the [[entity–relationship model]] (ER model). In DSDs, [[Attribute (computing)|attribute]]s are specified inside the entity boxes rather than outside of them, while relationships are drawn as boxes composed of attributes which specify the constraints that bind entities together.  DSDs differ from the ER model in that the ER model focuses on the relationships between different entities, whereas DSDs focus on the relationships of the elements within an entity and enable users to fully see the links and relationships between each entity.

There are several styles for representing data structure diagrams, with the notable difference in the manner of defining [[Cardinality (data modeling)|cardinality]]. The choices are between arrow heads, inverted arrow heads ([[Entity–relationship model|crow's feet]]), or numerical representation of the cardinality.
[[File:B 5 1 IDEF1X Diagram.jpg|thumb|240px|left|Example of an [[IDEF1X]] entity–relationship diagrams used to model IDEF1X itself<ref name="FIPS184">[http://www.itl.nist.gov/fipspubs/idef1x.doc FIPS Publication 184] {{Webarchive|url=https://web.archive.org/web/20131203223034/http://www.itl.nist.gov/fipspubs/idef1x.doc |date=2013-12-03 }} released of IDEF1X by the Computer Systems Laboratory of the National Institute of Standards and Technology (NIST). 21 December 1993 (withdrawn in 2008).</ref>]]

=== Entity–relationship model ===
{{Main|Entity–relationship model}}
An entity–relationship model (ERM), sometimes referred to as an entity–relationship diagram (ERD), could be used to represent an abstract [[conceptual schema|conceptual data model]] (or [[semantic data model]] or physical data model) used in [[software engineering]] to represent structured data. There are several notations used for ERMs. Like DSD's, [[Attribute (computing)|attribute]]s are specified inside the entity boxes rather than outside of them, while relationships are drawn as lines, with the relationship constraints as descriptions on the line. The E-R model, while robust, can become visually cumbersome when representing entities with several attributes.

There are several styles for representing data structure diagrams, with a notable difference in the manner of defining cardinality. The choices are between arrow heads, inverted arrow heads (crow's feet), or numerical representation of the cardinality.

=== Geographic data model ===
{{Main|Data model (GIS)}}
A data model in [[Geographic information system]]s is a mathematical construct for representing geographic objects or surfaces as data. For example, 
* the [[vector graphics|vector]] data model represents geography as points, lines, and polygons
* the raster data model represents geography as cell matrixes that store numeric values;
* and the [[Triangulated irregular network]] (TIN) data model represents geography as sets of contiguous, nonoverlapping triangles.<ref>Wade, T. and Sommer, S. eds. ''[http://store.esri.com/esri/showdetl.cfm?SID=2&Product_ID=868&Category_ID=49 A to Z GIS]''</ref>

<gallery class="center">
Image:Groups relate to the process of making a map.jpg|Groups relate to process of making a map<ref name= "DRS03">David R. Soller1 and Thomas M. Berg (2003). [http://pubs.usgs.gov/of/2003/of03-471/soller1/index.html The National Geologic Map Database Project: Overview and Progress] U.S. Geological Survey Open-File Report 03–471.</ref>
Image:NGMDB data model application.jpg|NGMDB data model applications<ref name= "DRS03"/> 
Image:NGMDB databases linked together.jpg|NGMDB databases linked together<ref name= "DRS03"/> 
Image:Representing three-dimensional map information.jpg|Representing 3D map information<ref name= "DRS03"/> 
</gallery>

=== Generic data model ===
{{Main|Generic data model}}
Generic data models are generalizations of conventional data models. They define standardized general relation types, together with the kinds of things that may be related by such a relation type. Generic data models are developed as an approach to solving some shortcomings of conventional data models. For example, different modelers usually produce different conventional data models of the same domain. This can lead to difficulty in bringing the models of different people together and is an obstacle for data exchange and data integration. Invariably, however, this difference is attributable to different levels of abstraction in the models and differences in the kinds of facts that can be instantiated (the semantic expression capabilities of the models). The modelers need to communicate and agree on certain elements that are to be rendered more concretely, in order to make the differences less significant.

=== Semantic data model ===
{{Main|Semantic data model}}
[[File:A2 4 Semantic Data Models.svg|thumb|320px|Semantic data models<ref name="FIPS184"/>]]
A semantic data model in software engineering is a technique to define the meaning of data within the context of its interrelationships with other data. A semantic data model is an abstraction that defines how the stored symbols relate to the real world.<ref name="FIPS184"/> A semantic data model is sometimes called a [[conceptual data model]].

The logical data structure of a [[database management system]] (DBMS), whether [[Hierarchical model|hierarchical]], [[Network model|network]], or [[Relational model|relational]], cannot totally satisfy the [[Requirements analysis|requirements]] for a conceptual definition of data because it is limited in scope and biased toward the implementation strategy employed by the DBMS. Therefore, the need to define data from a [[Three schema approach|conceptual view]] has led to the development of semantic data modeling techniques. That is, techniques to define the meaning of data within the context of its interrelationships with other data. As illustrated in the figure. The real world, in terms of resources, ideas, events, etc., are symbolically defined within physical data stores. A semantic data model is an abstraction that defines how the stored symbols relate to the real world. Thus, the model must be a true representation of the real world.<ref name="FIPS184"/>