Data model: Difference between revisions

Revision as of 01:36, 15 March 2023

Revision as of 01:33, 3 April 2023

Line 1:

{{Short description|Model that organizes elements of data and how they relate to one another and to real-world entities.}}

{{For|the professional activity|data modeling|database design}}

A '''data model''' <ref>{{cite web|title= UML Domain Modeling - Stack Overflow|url= https://stackoverflow.com/a/3835214|website= Stack Overflow|publisher= Stack Exchange Inc.|access-date= 4 February 2017}}</ref><ref name="w3cxpath">{{cite web|title= XQuery and XPath Data Model 3.1|url= https://www.w3.org/TR/xpath-datamodel-3/|website= World Wide Web Consortium (W3C)|publisher= W3C|access-date= 4 February 2017}}</ref><ref name="npmdatamodel">{{cite web|title= DataModel|url= https://www.npmjs.com/package/datamodel|website= npm|publisher= npm, Inc.|access-date= 4 February 2017}}</ref><ref>{{cite web|title= DataModel (Java EE 6)|url= http://docs.oracle.com/javaee/6/api/javax/faces/model/DataModel.html|website= Java Documentation|publisher= Oracle|access-date= 4 February 2017}}</ref><ref>{{cite web|last1= Ostrovskiy|first1= Stan|title= iOS: Three ways to pass data from Model to Controller|url= https://medium.com/ios-os-x-development/ios-three-ways-to-pass-data-from-model-to-controller-b47cc72a4336#.ma7pr7no7|website= Medium|publisher= A Medium Corporation|access-date= 4 February 2017}}</ref> is an [[abstract model]] that organizes elements of [[data]] and [[Standardization|standardizes]] how they relate to one another and to the properties of real-world [[Entity|entities]]. For instance, a data model may specify that the data element representing a car be composed of a number of other elements which, in turn, represent the color and size of the car and define its owner.

The term '''data model''' can refer to two distinct but closely related concepts. Sometimes it refers to an abstract formalization of the [[Object (philosophy)|objects]] and relationships found in a particular application ___domain: for example the customers, products, and orders found in a manufacturing organization. At other times it refers to the set of concepts used in defining such formalizations: for example concepts such as entities, attributes, relations, or tables. So the "data model" of a banking application may be defined using the entity-relationshipentity–relationship "data model". This article uses the term in both senses.

[[File:Data modeling context.svg|thumb|360px| Overview of a data-modeling context: Data model is based on Data, Data relationship, Data semantic and Data constraint. A data model provides the details of [[information]] to be stored, and is of primary use when the final product is the generation of computer [[software code]] for an application or the preparation of a [[functional specification]] to aid a [[computer software]] make-or-buy decision. The figure is an example of the interaction between [[business process modeling|process]] and data models.<ref name="SS93">Paul R. Smith & Richard Sarfaty Publications, LLC 2009</ref>]]

Line 43:

In the 1960s data modeling gained more significance with the initiation of the [[management information system]] (MIS) concept. According to Leondes (2002), "during that time, the information system provided the data and information for management purposes. The first generation [[database system]], called [[Integrated Data Store]] (IDS), was designed by [[Charles Bachman]] at General Electric. Two famous database models, the [[network data model]] and the [[hierarchical data model]], were proposed during this period of time".<ref>Cornelius T. Leondes (2002). ''Database and Data Communication Network Systems: Techniques and Applications''. Page 7</ref> Towards the end of the 1960s, [[Edgar F. Codd]] worked out his theories of data arrangement, and proposed the [[relational model]] for database management based on [[first-order logic|first-order predicate logic]].<ref>''"Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks"'', E.F. Codd, IBM Research Report, 1969</ref>

In the 1970s [[entity relationshipentity–relationship model]]ing emerged as a new type of conceptual data modeling, originally formalized in 1976 by [[Peter Chen]]. Entity-relationshipEntity–relationship models were being used in the first stage of [[information system]] design during the [[requirements analysis]] to describe information needs or the type of [[information]] that is to be stored in a [[database]]. This technique can describe any [[ontology (computer science)|ontology]], i.e., an overview and classification of concepts and their relationships, for a certain [[universe of discourse|area of interest]].

In the 1970s [[G.M. Nijssen]] developed "Natural Language Information Analysis Method" (NIAM) method, and developed this in the 1980s in cooperation with [[Terry Halpin]] into [[Object-Role Modeling]] (ORM). However, it was Terry Halpin's 1989 PhD thesis that created the formal foundation on which Object-Role Modeling is based.

Line 69:

; [[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-relationalObject–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-roleObject–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]]

Line 90:

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-relationshipentity–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-relationshipEntity–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 relationshipentity–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-relationshipEntity–relationship model ===

{{main|Entity-relationshipEntity–relationship model}}

An entity-relationshipentity–relationship model (ERM), sometimes referred to as an entity-relationshipentity–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.

Line 105:

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>

Line 158:

** ''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.

Line 193:

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-relationshipentity–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 ===

Line 215:

According to Lee (1999)<ref name="Lee99"/> an information model is a representation of concepts, relationships, constraints, rules, and [[Operation (mathematics)|operations]] to specify [[Semantic data model|data semantics]] for a chosen ___domain of discourse. It can provide sharable, stable, and organized structure of information requirements for the ___domain context.<ref name="Lee99">Y. Tina Lee (1999). [http://www.mel.nist.gov/msidlibrary/doc/tina99im.pdf "Information modeling from design to implementation"] National Institute of Standards and Technology.</ref> More in general the term ''information model'' is used for models of individual things, such as facilities, buildings, process plants, etc. In those cases the concept is specialised to [[Facility Information Model]], [[Building information modeling|Building Information Model]], Plant Information Model, etc. Such an information model is an integration of a model of the facility with the data and documents about the facility.

An information model provides formalism to the description of a problem ___domain without constraining how that description is mapped to an actual implementation in software. There may be many mappings of the information model. Such mappings are called data models, irrespective of whether they are [[object model]]s (e.g. using [[Unified Modeling Language|UML]]), [[Entity-relationship model|entity relationshipentity–relationship model]]s or [[XML schema]]s.

[[File:JKDOM.SVG|thumb|180px|left|[[Document Object Model]], a standard [[object model]] for representing [[HTML]] or [[XML]]]]