Data model: Difference between revisions

Revision as of 16:45, 13 October 2024

Latest revision as of 11:53, 21 August 2025

(4 intermediate revisions by 3 users not shown)

Line 27:

* "Business rules, specific to how things are done in a particular place, are often fixed in the structure of a data model. This means that small changes in the way business is conducted lead to large changes in computer systems and interfaces".<ref name="MW99"/>

* "Entity types are often not identified, or incorrectly identified. This can lead to replication of data, data structure, and functionality, together with the attendant costs of that duplication in development and maintenance".<ref name="MW99"/>

* "Data models for different systems are arbitrarily different. The result of this is that complex interfaces are required between systems that share data. These interfaces can account for between 25-7025–70% of the cost of current systems".<ref name="MW99"/>

* "Data cannot be shared electronically with customers and suppliers, because the structure and meaning of data has not been standardized. For example, engineering design data and drawings for process plant are still sometimes exchanged on paper".<ref name="MW99"/>

The reason for these problems is a lack of standards that will ensure that data models will both meet business needs and be consistent.<ref name="MW99"/>

Line 43:

== History ==

One of the earliest pioneering works in modeling information systems was done by Young and Kent (1958),<ref>Young, J. W., and Kent, H. K. (1958). "Abstract Formulation of Data Processing Problems". In: ''Journal of Industrial Engineering''. Nov-Dec 1958. 9(6), pp. 471-479471–479</ref><ref name="JAB07">[[Janis A. Bubenko jr]] (2007) "From Information Algebra to Enterprise Modelling and Ontologies - a Historical Perspective on Modelling for Information Systems". In: ''Conceptual Modelling in Information Systems Engineering''. [[:w:John Krogstie|John Krogstie]] et al. eds. pp 1-181–18</ref> who argued for "a precise and abstract way of specifying the informational and time characteristics of a [[data processing]] problem". They wanted to create "a notation that should enable the [[Systems analyst|analyst]] to organize the problem around any piece of [[computer hardware|hardware]]". Their work was the first effort to create an abstract specification and invariant basis for designing different alternative implementations using different hardware components. The next step in IS modeling was taken by [[CODASYL]], an IT industry consortium formed in 1959, who essentially aimed at the same thing as Young and Kent: the development of "a proper structure for machine-independent problem definition language, at the system level of data processing". This led to the development of a specific IS [[information algebra]].<ref name="JAB07"/>

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>

Line 53:

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.

In the 1980s, according to Jan L. Harrington (2000), "the development of the [[Object-oriented programming|object-oriented]] paradigm brought about a fundamental change in the way we look at data and the procedures that operate on data. Traditionally, data and procedures have been stored separately: the data and their relationship in a database, the procedures in an application program. Object orientation, however, combined an entity's procedure with its data."<ref name="JLH00">Jan L. Harrington (2000). ''Object-oriented Database Design Clearly Explained''. p.4</ref>

During the early 1990s, three Dutch mathematicians Guido Bakema, Harm van der Lek, and JanPieter Zwart, continued the development on the work of [[G.M. Nijssen]]. They focused more on the communication part of the semantics. In 1997 they formalized the method Fully Communication Oriented Information Modeling [[FCO-IM]].

Line 70:

: 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]]

: ThisThe [[network model]], also [[graph model]], organizes data using two fundamental constructs, called records and sets. Records (or nodes) contain fields (i.e. attributes), and sets (or edges) define one-to-many, many-to-many and many-to-one relationships between records: one owner, many members. The network data model is an abstraction of the design concept used in the implementation of databases. Network models emphasise interconnectedness, making them ideal for applications where relationships are crucial, like social networks or recommendation systems. This structure allows for efficient querying of relationships without expensive joins.

; [[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.

Line 208:

[[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>]]

A data-flow diagram (DFD) is a graphical representation of the "flow" of data through an [[information system]]. It differs from the [[flowchart]] as it shows the ''data'' flow instead of the ''control'' flow of the program. A data-flow diagram can also be used for the [[Data visualization|visualization]] of [[data processing]] (structured design). Data-flow diagrams were invented by [[Larry Constantine]], the original developer of structured design,<ref>W. Stevens, G. Myers, L. Constantine, "Structured Design", IBM Systems Journal, 13 (2), 115-139115–139, 1974.</ref> based on Martin and Estrin's "data-flow graph" model of computation.

It is common practice to draw a [[System context diagram|context-level data-flow diagram]] first which shows the interaction between the system and outside entities. The '''DFD''' is designed to show how a system is divided into smaller portions and to highlight the flow of data between those parts. This context-level data-flow diagram is then "exploded" to show more detail of the system being modeled