Data model: Difference between revisions

Revision as of 01:13, 11 August 2023

Revision as of 21:12, 23 September 2023

Line 35:

[[File:4-2 ANSI-SPARC three level architecture.svg|thumb|320px|The ANSI/SPARC [[Three schema approach|three level architecture]]. This shows that a data model can be an external model (or view), a conceptual model, or a physical model. This is not the only way to look at data models, but it is a useful way, particularly when comparing models.<ref name="MW99"/>]]

A data model ''instance'' may be one of three kinds according to [[ANSI]] in 1975:<ref>American National Standards Institute. 1975. ''ANSI/X3/SPARC Study Group on Data Base Management Systems; Interim Report''. FDT (Bulletin of ACM SIGMOD) 7:2.</ref>

# [[Conceptual data model]]: describes the semantics of a ___domain, being the scope of the model. For example, it may be a model of the interest area of an organization or industry. This consists of entity classes, representing kinds of things of significance in the ___domain, and relationship assertions about associations between pairs of entity classes. A conceptual schema specifies the kinds of facts or propositions that can be expressed using the model. In that sense, it defines the allowed expressions in an artificial 'language' with a scope that is limited by the scope of the model.

# [[Logical data model]]: describes the semantics, as represented by a particular data manipulation technology. This consists of descriptions of tables and columns, object oriented classes, and XML tags, among other things.

# [[Physical data model]]: describes the physical means by which data are stored. This is concerned with partitions, CPUs, tablespaces, and the like.

Line 48:

In the 1970s [[entity–relationship model]]ing emerged as a new type of conceptual data modeling, originally formalized in 1976 by [[Peter Chen]]. Entity–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-RoleObject–Role Modeling]] (ORM). However, it was Terry Halpin's 1989 PhD thesis that created the formal foundation on which Object-RoleObject–Role Modeling is based.

Bill Kent, in his 1978 book ''Data and Reality,''<ref>{{citation|title=Data and Reality |url=http://www.bkent.net/Doc/darxrp.htm}}</ref> compared a data model to a map of a territory, emphasizing that in the real world, "highways are not painted red, rivers don't have county lines running down the middle, and you can't see contour lines on a mountain". In contrast to other researchers who tried to create models that were mathematically clean and elegant, Kent emphasized the essential messiness of the real world, and the task of the data modeler to create order out of chaos without excessively distorting the truth.

Line 59:

=== Database model ===

{{mainMain|Database model}}

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

Line 89:

=== Data structure diagram ===

{{mainMain|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.

Line 99:

=== Entity–relationship model ===

{{mainMain|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.

Line 105:

=== Geographic data model ===

{{mainMain|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

Line 115:

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

{{mainMain|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 ===

{{mainMain|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]].

Line 132:

=== Data architecture ===

{{mainMain|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]].

Line 169:

=== Data structure ===

{{mainMain|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]].

Line 204:

=== Data-flow diagram ===

{{mainMain|Data-flow diagram}}

[[File:Data Flow Diagram Example.jpg|thumb|240px|Data-Flow Diagram example<ref>John Azzolini (2000). [http://ses.gsfc.nasa.gov/ses_data_2000/000712_Azzolini.ppt Introduction to Systems Engineering Practices]. July 2000.</ref>]]

Line 212:

=== Information model ===

{{mainMain|Information model}}

[[File:A 01 Audio compact disc collection.svg|thumb|320px|Example of an [[EXPRESS (data modeling language)|EXPRESS G]] [[Informationinformation model]] ]]

An Information model is not a type of data model, but more or less an alternative model. Within the field of software engineering, both a data model and an information model can be abstract, formal representations of entity types that include their properties, relationships and the operations that can be performed on them. The entity types in the model may be kinds of real-world objects, such as devices in a network, or they may themselves be abstract, such as for the entities used in a billing system. Typically, they are used to model a constrained ___domain that can be described by a closed set of entity types, properties, relationships and operations.

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]]s or [[XML schema]]s.

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

=== Object model ===

{{mainMain|Object model}}

An object model in computer science is a collection of objects or classes through which a program can examine and manipulate some specific parts of its world. In other words, the object-oriented interface to some service or system. Such an interface is said to be the ''object model of'' the represented service or system. For example, the [[Document Object Model|Document Object Model (DOM)]] [http://www.w3.org/DOM/] is a collection of objects that represent a [[web page|page]] in a [[web browser]], used by [[scripting language|script]] programs to examine and dynamically change the page. There is a [[Microsoft Excel]] object model<ref>[http://msdn2.microsoft.com/en-us/library/wss56bz7.aspx Excel Object Model Overview<!-- Bot generated title -->]</ref> for controlling Microsoft Excel from another program, and the [[ASCOM (standard)|ASCOM]] Telescope Driver<ref>{{cite web|url=http://ascom-standards.org/Standards/Requirements.htm |title=ASCOM General Requirements|date=2011-05-13 |access-date=2014-09-25}}</ref> is an object model for controlling an astronomical telescope.

In [[computing]] the term ''object model'' has a distinct second meaning of the general properties of [[object (computer science)|objects]] in a specific computer [[programming language]], technology, notation or [[methodology]] that uses them. For example, the ''[[Java (programming language)|Java]] object model'', the ''[[Component Object Model|COM]] object model'', or ''the object model of [[object-modeling technique|OMT]]''. Such object models are usually defined using concepts such as [[class (computer science)|class]], [[message (computer science)|message]], [[inheritance (object-oriented programming)|inheritance]], [[polymorphism in object-oriented programming|polymorphism]], and [[information hiding|encapsulation]]. There is an extensive literature on formalized object models as a subset of the [[formal semantics of programming languages]].

=== Object-RoleObject–role Modelmodeling ===

{{Main|Object–role modeling}}

{{main|Object-Role Modeling}}

[[File:Schema for Geologic Surface.svg|thumb|320px|Example of the application of Object-RoleObject–Role Modeling in a "Schema for Geologic Surface", Stephen M. Richard (1999)<ref name="SMR99">Stephen M. Richard (1999). [http://pubs.usgs.gov/of/1999/of99-386/richard.html Geologic Concept Modeling]. U.S. Geological Survey Open-File Report 99-38699–386.</ref>]]

Object-RoleObject–Role Modeling (ORM) is a method for [[conceptual modeling]], and can be used as a tool for information and rules analysis.<ref>Joachim Rossberg and Rickard Redler (2005). ''Pro Scalable .NET 2.0 Application Designs.''. Page 27.</ref>

Object-RoleObject–Role Modeling is a fact-oriented method for performing [[systems analysis]] at the conceptual level. The quality of a database application depends critically on its design. To help ensure correctness, clarity, adaptability and productivity, information systems are best specified first at the conceptual level, using concepts and language that people can readily understand.

The conceptual design may include data, process and behavioral perspectives, and the actual DBMS used to implement the design might be based on one of many logical data models (relational, hierarchic, network, object-oriented, etc.).<ref name = "msd">[http://msdn2.microsoft.com/en-us/library/aa290383(VS.71).aspx Object Role Modeling: An Overview (msdn.microsoft.com)]. Retrieved 19 September 2008.</ref>