Editing Data model (section)

== Topics ==

=== Data architecture ===
{{Main|Data architecture}}
Data architecture is the design of data for use in defining the target state and the subsequent planning needed to hit the target state. It is usually one of several [[architecture domain]]s that form the pillars of an [[enterprise architecture]] or [[solution architecture]].

A data architecture describes the data structures used by a business and/or its applications. There are descriptions of data in storage and data in motion; descriptions of data stores, data groups, and data items; and mappings of those data artifacts to data qualities, applications, locations, etc.

Essential to realizing the target state, Data architecture describes how data is processed, stored, and utilized in a given system. It provides criteria for data processing operations that make it possible to design data flows and also control the flow of data in the system.

=== Data modeling ===
{{Main|Data modeling}}
[[File:4-3 Data Modelling Today.svg|320px|thumb|The data modeling process]] 
Data modeling in [[software engineering]] is the process of creating a data model by applying formal data model descriptions using data modeling techniques. Data modeling is a technique for defining business [[requirement]]s for a database. It is sometimes called ''database modeling'' because a data model is eventually implemented in a database.<ref name="WBD04">[[Whitten, Jeffrey L.]]; [[Lonnie D. Bentley]], [[Kevin C. Dittman]]. (2004). ''Systems Analysis and Design Methods''. 6th edition. {{ISBN|0-256-19906-X}}.</ref>

The figure illustrates the way data models are developed and used today. A [[conceptual data model]] is developed based on the data [[requirements]] for the application that is being developed, perhaps in the context of an [[activity diagram|activity model]]. The data model will normally consist of entity types, attributes, relationships, integrity rules, and the definitions of those objects. This is then used as the start point for interface or [[database design]].<ref name="MW99"/>

=== Data properties ===
[[File:3-2 Properties of data.svg|thumb|320px|Some important properties of data<ref name="MW99"/>]]
Some important properties of data for which requirements need to be met are:
* definition-related properties<ref name="MW99"/>
** ''relevance'': the usefulness of the data in the context of your business.
** ''clarity'': the availability of a clear and shared definition for the data.
** ''consistency'': the compatibility of the same type of data from different sources.
* content-related properties
** ''timeliness'': the availability of data at the time required and how up-to-date that data is.
** ''accuracy'': how close to the truth the data is.
* properties related to both definition and content
** ''completeness'': how much of the required data is available.
** ''accessibility'': where, how, and to whom the data is available or not available (e.g. security).
** ''cost'': the cost incurred in obtaining the data, and making it available for use.

=== Data organization ===
Another kind of data model describes how to organize data using a [[database management system]] or other data management technology. It describes, for example, relational tables and columns or object-oriented classes and attributes. Such a data model is sometimes referred to as the ''[[physical data model]]'', but in the original ANSI three schema architecture, it is called "logical". In that architecture, the physical model describes the storage media (cylinders, tracks, and tablespaces). Ideally, this model is derived from the more conceptual data model described above. It may differ, however, to account for constraints like processing capacity and usage patterns.

While ''data analysis'' is a common term for data modeling, the activity actually has more in common with the ideas and methods of ''[[wiktionary:synthesis|synthesis]]'' (inferring general concepts from particular instances) than it does with ''[[wiktionary:Analysis|analysis]]'' (identifying component concepts from more general ones).  {''Presumably we call ourselves [[systems analyst]]s because no one can say [[systems analyst|systems synthesist]]s.''}  Data modeling strives to bring the data structures of interest together into a cohesive, inseparable, whole by eliminating unnecessary data redundancies and by relating data structures with [[Relational model|relationship]]s.

A different approach is to use [[adaptive system]]s such as [[artificial neural network]]s that can autonomously create implicit models of data.

=== Data structure ===
{{Main|Data structure}}
[[File:Binary tree.svg|thumb|240px|A [[binary tree]], a simple type of branching linked data structure]]
A data structure is a way of storing data in a computer so that it can be used efficiently. It is an organization of mathematical and logical concepts of data. Often a carefully chosen data structure will allow the most [[algorithmic efficiency|efficient]] [[algorithm]] to be used. The choice of the data structure often begins from the choice of an [[abstract data type]].

A data model describes the structure of the data within a given domain and, by implication, the underlying structure of that domain itself. This means that a data model in fact specifies a dedicated ''grammar'' for a dedicated artificial language for that domain. A data model represents classes of entities (kinds of things) about which a company wishes to hold information, the attributes of that information, and relationships among those entities and (often implicit) relationships among those attributes. The model describes the organization of the data to some extent irrespective of how data might be represented in a computer system.

The entities represented by a data model can be the tangible entities, but models that include such concrete entity classes tend to change over time. Robust data models often identify [[abstraction]]s of such entities. For example, a data model might include an entity class called "Person", representing all the people who interact with an organization. Such an [[abstract entity]] class is typically more appropriate than ones called "Vendor" or "Employee", which identify specific roles played by those people.

<gallery class="center">
Image:Array of array storage.svg|Array
Image:HASHTB08 en.svg|[[Hash table]]
Image:Singly linked list insert after.png|[[Linked list]]
Image:Data stack.svg|[[Stack (data structure)]]
</gallery>

=== Data model theory ===
The term data model can have two meanings:<ref name="Beynon-Davies P. 2004">Beynon-Davies P. (2004). Database Systems 3rd Edition. Palgrave, Basingstoke, UK. {{ISBN|1-4039-1601-2}}</ref>
# A data model ''theory'', i.e. a formal description of how data may be structured and accessed.
# A data model ''instance'', i.e. applying a data model ''theory'' to create a practical data model ''instance'' for some particular application.

A data model theory has three main components:<ref name="Beynon-Davies P. 2004"/>
* The structural part: a collection of data structures which are used to create databases representing the entities or objects modeled by the database.
* The integrity part: a collection of rules governing the constraints placed on these data structures to ensure structural integrity.
* The manipulation part: a collection of operators which can be applied to the data structures, to update and query the data contained in the database.

For example, in the [[relational model]], the structural part is based on a modified concept of the [[Relation (mathematics)|mathematical relation]]; the integrity part is expressed in [[first-order logic]] and the manipulation part is expressed using the [[relational algebra]], [[tuple calculus]] and [[domain calculus]].

A data model instance is created by applying a data model theory. This is typically done to solve some business enterprise requirement. Business requirements are normally captured by a semantic [[logical data model]]. This is transformed into a physical data model instance from which is generated a physical database. For example, a data modeler may use a data modeling tool to create an [[entity–relationship model]] of the corporate data repository of some business enterprise. This model is transformed into a [[relational model]], which in turn generates a [[relational database]].

=== Patterns ===
Patterns<ref name="LSPA08">"The Data Model Resource Book: Universal Patterns for Data Modeling"  Len Silverstone & Paul Agnew (2008).</ref> are common data modeling structures that occur in many data models.