Hubbry Logo
Data modelData modelMain
Open search
Data model
Community hub
Data model
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Data model
Data model
Data model
View on Wikipedia
from Wikipedia
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 process and data models.[1]

A data model is an abstract model that organizes elements of data and standardizes how they relate to one another and to the properties of real-world entities.[2][3] 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 corresponding professional activity is called generally data modeling or, more specifically, database design. Data models are typically specified by a data expert, data specialist, data scientist, data librarian, or a data scholar. A data modeling language and notation are often represented in graphical form as diagrams.[4]

A data model can sometimes be referred to as a data structure, especially in the context of programming languages. Data models are often complemented by function models, especially in the context of enterprise models.

A data model explicitly determines the structure of data; conversely, structured data is data organized according to an explicit data model or data structure. Structured data is in contrast to unstructured data and semi-structured data.

Overview

[edit]

The term data model can refer to two distinct but closely related concepts. Sometimes it refers to an abstract formalization of the 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–relationship "data model". This article uses the term in both senses.

Managing large quantities of structured and unstructured data is a primary function of information systems. Data models describe the structure, manipulation, and integrity aspects of the data stored in data management systems such as relational databases. They may also describe data with a looser structure, such as word processing documents, email messages, pictures, digital audio, and video: XDM, for example, provides a data model for XML documents.

The role of data models

[edit]
How data models deliver benefit[5]

The main aim of data models is to support the development of information systems by providing the definition and format of data. According to West and Fowler (1999) "if this is done consistently across systems then compatibility of data can be achieved. If the same data structures are used to store and access data then different applications can share data. The results of this are indicated above. However, systems and interfaces often cost more than they should, to build, operate, and maintain. They may also constrain the business rather than support it. A major cause is that the quality of the data models implemented in systems and interfaces is poor".[5]

  • "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".[5]
  • "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".[5]
  • "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–70% of the cost of current systems".[5]
  • "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".[5]

The reason for these problems is a lack of standards that will ensure that data models will both meet business needs and be consistent.[5]

A data model explicitly determines the structure of data. Typical applications of data models include database models, design of information systems, and enabling exchange of data. Usually, data models are specified in a data modeling language.[3]

Three perspectives

[edit]
The ANSI/SPARC 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.[5]

A data model instance may be one of three kinds according to ANSI in 1975:[6]

  1. 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.
  2. 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.
  3. Physical data model: describes the physical means by which data are stored. This is concerned with partitions, CPUs, tablespaces, and the like.

The significance of this approach, according to ANSI, is that it allows the three perspectives to be relatively independent of each other. Storage technology can change without affecting either the logical or the conceptual model. The table/column structure can change without (necessarily) affecting the conceptual model. In each case, of course, the structures must remain consistent with the other model. The table/column structure may be different from a direct translation of the entity classes and attributes, but it must ultimately carry out the objectives of the conceptual entity class structure. Early phases of many software development projects emphasize the design of a conceptual data model. Such a design can be detailed into a logical data model. In later stages, this model may be translated into physical data model. However, it is also possible to implement a conceptual model directly.

History

[edit]

One of the earliest pioneering works in modeling information systems was done by Young and Kent (1958),[7][8] 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 analyst to organize the problem around any piece of 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.[8]

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".[9] 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 predicate logic.[10]

In the 1970s entity–relationship modeling 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, i.e., an overview and classification of concepts and their relationships, for a certain 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.

Bill Kent, in his 1978 book Data and Reality,[11] 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 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."[12]

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.

Types

[edit]

Database model

[edit]
Main article: 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 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
The 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.
Object–relational model
Similar to a relational database model, but objects, classes, and inheritance are directly supported in database schemas 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.

Data structure diagram

[edit]
Main article: Data structure diagram
Example of a Data Structure Diagram

A data structure diagram (DSD) is a diagram and data model used to describe conceptual data models by providing graphical notations which document entities and their relationships, and the constraints that bind them. The basic graphic elements of DSDs are boxes, representing entities, and arrows, 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, attributes 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. The choices are between arrow heads, inverted arrow heads (crow's feet), or numerical representation of the cardinality.

Example of an IDEF1X entity–relationship diagrams used to model IDEF1X itself[13]

Entity–relationship model

[edit]
Main article: 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 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, attributes 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

[edit]
Main article: Data model (GIS)

A data model in Geographic information systems is a mathematical construct for representing geographic objects or surfaces as data. For example,

  • the 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.[14]
  • Groups relate to process of making a map[15]
    Groups relate to process of making a map[15]
  • NGMDB data model applications[15]
    NGMDB data model applications[15]
  • NGMDB databases linked together[15]
    NGMDB databases linked together[15]
  • Representing 3D map information[15]
    Representing 3D map information[15]

Generic data model

[edit]
Main article: 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

[edit]
Main article: Semantic data model
Semantic data models[13]

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.[13] A semantic data model is sometimes called a conceptual data model.

The logical data structure of a database management system (DBMS), whether hierarchical, network, or relational, cannot totally satisfy the 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 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.[13]

Topics

[edit]

Data architecture

[edit]
Main article: 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 domains 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

[edit]
Main article: Data modeling
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 requirements for a database. It is sometimes called database modeling because a data model is eventually implemented in a database.[16]

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

Data properties

[edit]
Some important properties of data[5]

Some important properties of data for which requirements need to be met are:

  • definition-related properties[5]
    • relevance: the usefulness of the data in relation to its intended purpose or application.
    • 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

[edit]

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 synthesis (inferring general concepts from particular instances) than it does with analysis (identifying component concepts from more general ones). {Presumably we call ourselves systems analysts because no one can say systems synthesists.} 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 relationships.

A different approach is to use adaptive systems such as artificial neural networks that can autonomously create implicit models of data.

Data structure

[edit]
Main article: Data structure
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 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 abstractions 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.

Data model theory

[edit]

The term data model can have two meanings:[17]

  1. A data model theory, i.e. a formal description of how data may be structured and accessed.
  2. 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:[17]

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

[edit]

Patterns[18] are common data modeling structures that occur in many data models.

[edit]

Data-flow diagram

[edit]
Main article: Data-flow diagram
Data-Flow Diagram example[19]

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 visualization of data processing (structured design). Data-flow diagrams were invented by Larry Constantine, the original developer of structured design,[20] based on Martin and Estrin's "data-flow graph" model of computation.

It is common practice to draw a 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

Information model

[edit]
Main article: Information model
Example of an EXPRESS G information 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)[21] an information model is a representation of concepts, relationships, constraints, rules, and operations to specify data semantics for a chosen domain of discourse. It can provide sharable, stable, and organized structure of information requirements for the domain context.[21] 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 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 models (e.g. using UML), entity–relationship models or XML schemas.

Document Object Model, a standard object model for representing HTML or XML

Object model

[edit]
Main article: 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 (DOM) [1] is a collection of objects that represent a page in a web browser, used by script programs to examine and dynamically change the page. There is a Microsoft Excel object model[22] for controlling Microsoft Excel from another program, and the ASCOM Telescope Driver[23] 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 objects in a specific computer programming language, technology, notation or methodology that uses them. For example, the Java object model, the COM object model, or the object model of OMT. Such object models are usually defined using concepts such as class, message, inheritance, polymorphism, and encapsulation. There is an extensive literature on formalized object models as a subset of the formal semantics of programming languages.

Object–role modeling

[edit]
Main article: Object–role modeling
Example of the application of Object–Role Modeling in a "Schema for Geologic Surface", Stephen M. Richard (1999)[24]

Object–Role Modeling (ORM) is a method for conceptual modeling, and can be used as a tool for information and rules analysis.[25]

Object–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.).[26]

Unified Modeling Language models

[edit]
Main article: Unified Modeling Language

The Unified Modeling Language (UML) is a standardized general-purpose modeling language in the field of software engineering. It is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system. The Unified Modeling Language offers a standard way to write a system's blueprints, including:[27]

UML offers a mix of functional models, data models, and database models.

See also

[edit]

References

[edit]

Further reading

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Data model

View on Grokipedia
from Grokipedia
A data model is an abstract framework that organizes data elements and standardizes the relationships among them, providing a structured representation of real-world entities, attributes, and processes within an . It defines the logical structure of data, including how data is stored, accessed, and manipulated, serving as a foundational blueprint for and system development. Data modeling, the process of creating a data model, typically progresses through three levels: the conceptual data model, which offers a high-level overview of business entities and relationships without technical details; the logical data model, which specifies data attributes, keys, and constraints in a database-independent manner; and the physical data model, which details the implementation in a specific database management system, including storage schemas and access paths. This structured approach ensures alignment with requirements and facilitates scalability across various database types, such as relational, hierarchical, and systems. The origins of modern data models trace back to the 1960s, with the introduction of the hierarchical model in IBM's Information Management System (IMS), developed in 1966 to manage complex data for NASA's . A pivotal advancement occurred in 1970 when E. F. Codd proposed the in his seminal paper, emphasizing , normalization, and query efficiency through mathematical relations, which revolutionized database technology and became the basis for SQL-based systems. Data models play a critical role in enhancing , reducing development errors, and improving communication between stakeholders by providing a common visual and conceptual for data flows and dependencies. They support key applications in , , and , evolving iteratively to adapt to changing business needs and technological advancements like and .

Introduction

Definition and Purpose

A data model is an abstract framework that defines the structure, organization, and relationships of within a system, serving as a blueprint for how information is represented and manipulated. According to E.F. Codd, a foundational figure in , a data model consists of three core components: a collection of types that form the building blocks of the database, a set of operators or inferencing rules for retrieving and deriving , and a collection of integrity rules to ensure consistent states and valid changes. This conceptualization bridges the gap between real-world entities and their digital counterparts, providing a conceptual toolset for describing entities, attributes, and interrelationships in a standardized manner. The primary purposes of a data model include facilitating clear communication among diverse stakeholders—such as analysts, developers, and end-users—by offering a shared and visual representation of requirements during system . It ensures by enforcing constraints and rules that maintain accuracy, consistency, and reliability across the , while supporting through adaptable structures that accommodate growth and with minimal disruption to existing applications. Additionally, data models enable efficient querying and by defining operations that optimize access and manipulation, laying the groundwork for high-level languages and database management system architectures. In practice, data models abstract complex real-world phenomena into manageable formats, finding broad applications in databases for persistent storage, for system design, and for deriving insights from structured information. For instance, they help translate organizational needs into technical specifications, such as modeling customer interactions in a retail system or inventory relationships in software. Originating from mathematical and adapted for computational environments, data models provide levels of abstraction akin to the three-schema architecture, which separates user views from physical storage.

Three-Schema Architecture

The three-schema architecture, proposed by the ANSI/X3/SPARC Study Group on Database Management Systems, organizes database systems into three distinct levels of abstraction to manage representation and access efficiently. This framework separates user interactions from the underlying , promoting and maintainability in . At the external level, also known as the view level, the architecture defines user-specific schemas that present customized subsets of the tailored to individual applications or user groups. These external schemas hide irrelevant details and provide a simplified, application-oriented perspective, such as predefined queries or reports, without exposing the full database structure. The conceptual level, or logical level, describes the overall logical structure of the entire database in a storage-independent manner, including entities, relationships, constraints, and types that represent the community's view of the . It serves as a unified model for the database content, independent of physical implementation. Finally, the internal level, or physical level, specifies the physical storage details, such as file organizations, indexing strategies, access paths, and data compression methods, optimizing on specific hardware. The architecture facilitates two key mappings to ensure consistency across levels: the external/conceptual mapping, which translates user views into the , and the conceptual/internal mapping, which defines how the logical structure is implemented physically. These mappings allow transformations, such as view derivations or storage optimizations, to maintain without redundant storage or direct user exposure to changes in other levels. By decoupling these layers, the framework achieves —changes to the do not affect external views—and physical data independence—modifications to internal storage do not impact the conceptual or external levels. This separation reduces , enhances by limiting user access to necessary views, and supports in multi-user environments. Originally outlined in interim report, the three-schema architecture remains a foundational standard influencing modern database management systems (DBMS), where principles of layered abstraction underpin features like views in relational databases and schema evolution in distributed systems.

Historical Development

Early Mathematical Foundations

The foundations of trace back to 19th-century mathematical developments, particularly , which provided the abstract framework for organizing and relating elements without reference to physical implementation. , in his pioneering work starting in 1872, formalized sets as collections of distinct objects, introducing concepts such as to compare sizes of infinite collections and equivalence relations to partition sets into subsets with shared properties. These abstractions laid the groundwork for viewing data as structured collections, where relations could be defined as subsets of Cartesian products of sets, enabling the representation of dependencies and mappings between entities. Cantor's 1883 publication Grundlagen einer allgemeinen Mannigfaltigkeitslehre further developed transfinite ordinals and power sets, emphasizing hierarchical and relational structures that would later inform data organization. Parallel advancements in logic provided precursors to , beginning with George Boole's 1847 treatise The Mathematical Analysis of Logic, which applied algebraic operations to logical classes. Boole represented classes as variables and defined operations like (multiplication xyxy) and union (addition x+yx + y) under laws of commutativity and distributivity, allowing equational expressions for propositions such as "All X is Y" as x=xyx = xy. This Boolean algebra enabled the manipulation of relations between classes as abstract descriptors, forming a basis for querying and transforming data sets through logical operations. Building on this, Giuseppe Peano in the late 19th century contributed to predicate logic by standardizing notation for quantification and logical connectives in his 1889 Arithmetices principia, facilitating precise expressions of properties and relations over mathematical objects. Early 20th-century logicians extended these ideas by formalizing relations and entities more rigorously. Gottlob Frege's 1879 Begriffsschrift introduced predicate calculus, treating relations as functions that map arguments to truth values—for instance, a binary relation like "loves" as a function from pairs of entities to the truth value "The True." This approach distinguished concepts (unsaturated functions) from objects (saturated entities), providing a blueprint for entity-relationship modeling where data elements are linked via functional dependencies. Bertrand Russell advanced this in The Principles of Mathematics (1903), analyzing relations as fundamental to mathematical structures and developing type theory to handle relational orders without paradoxes, emphasizing that mathematics concerns relational patterns rather than isolated objects. Mathematical abstractions of graphs and trees, emerging in the 19th century, offered additional tools for representing hierarchical and networked . Leonhard Euler's 1736 solution to the bridge problem implicitly used graph-like structures to model connectivity, but systematic development came with Cayley's 1857 enumeration of trees as rooted, acyclic graphs with nn−2n^{n-2} labeled instances for nn vertices. Gustav Kirchhoff's 1847 work on electrical networks formalized trees as spanning subgraphs minimizing connections, highlighting their role in describing minimal relational paths. These concepts treated as nodes and edges without computational context, focusing on topological properties like paths and cycles. Abstract descriptors such as tuples, relations, and functions crystallized in 19th-century as tools for precise specification. Tuples, as ordered sequences of elements, emerged from Cantor's work on mappings. Relations were codified as subsets of product sets, as in De Morgan's 1860 calculus of relations, which treated binary relations as compositions of functions between classes. Functions, formalized by Dirichlet in 1837 as arbitrary mappings from one set to another, provided a unidirectional , independent of analytic expressions. These elements—tuples for bundling attributes, relations for associations, and functions for transformations—served as purely theoretical constructs for describing structures. In the 1940s and 1950s, these mathematical ideas began informing initial data representation in computing, as abstractions like sets for memory collections and graphs for data flows influenced designs such as Alan Turing's 1945 Automatic Computing Engine, which used structured addressing akin to tree hierarchies for organizing binary data. This transition marked the shift from pure theory to practical abstraction, where logical relations and set operations guided early conceptualizations of data storage and retrieval.

Evolution in Computing and Databases

In the 1950s and early 1960s, data management in relied primarily on file-based systems, where was stored in sequential or indexed files on magnetic tapes or disks, often customized for specific applications without standardized structures for sharing across programs. These systems, prevalent in early mainframes like the , lacked efficient querying and required programmers to navigate manually via application , leading to and challenges. A pivotal advancement came in 1966 with IBM's Information Management System (IMS), developed for NASA's to handle hierarchical data structures resembling organizational charts or bill-of-materials. IMS organized data into tree-like hierarchies with parent-child relationships, enabling faster access for transactional processing but limiting flexibility for complex many-to-many associations. This hierarchical model influenced early database management systems (DBMS) by introducing segmented storage and navigational access methods. By the late , the limitations of hierarchical models prompted the development of network models. In 1971, the Conference on Data Systems Languages () Database Task Group (DBTG) released specifications for a network data model, allowing records to participate in multiple parent-child sets for more general graph-like structures. Implemented in systems like Integrated Data Store (IDS), this model supported pointer-based navigation but required complex schema definitions and low-level programming, complicating maintenance. The marked a revolutionary shift in the . In , published "A Relational Model of Data for Large Shared Data Banks," proposing organization into tables (relations) with rows and columns, using keys for integrity and —building on mathematical —for declarative querying independent of physical storage. This abstraction from navigational access to set-based operations addressed , reducing application dependencies on storage details. To operationalize relational concepts, query languages emerged. In 1974, and developed (later SQL) as part of IBM's System R prototype, providing a structured English-like syntax for data manipulation and retrieval in relational databases. SQL's declarative nature allowed users to specify what data they wanted without how to retrieve it, facilitating broader adoption. Conceptual modeling also advanced with Peter Pin-Shan Chen's 1976 entity-relationship (ER) model, which formalized diagrams for entities, attributes, and relationships to bridge user requirements and . Widely used for planning, the ER model complemented relational implementations by emphasizing semantics. The saw commercialization and . SQL was formalized as ANSI X3.135 in 1986, establishing a portable query standard across vendors and enabling interoperability. released DB2 in 1983 as a production relational DBMS for mainframes, supporting SQL and transactions for enterprise workloads. followed in 1979 with Version 2, the first commercial SQL relational DBMS, emphasizing portability across hardware. The 1990s extended relational paradigms to object-oriented needs. In 1993, the Object Data Management Group (ODMG) published ODMG-93, standardizing object-oriented DBMS with Object Definition Language (ODL) for schemas, Object Query Language (OQL) for queries, and bindings to languages like C++. This addressed complex data like by integrating objects with relational persistence. Overall, this era transitioned from rigid, navigational file and hierarchical/network systems to flexible, declarative relational models, underpinning modern DBMS through and standardization.

Types of Data Models

Hierarchical and Network Models

The hierarchical data model organizes data in a tree-like structure, where each record, known as a segment in systems like IBM's Information Management System (IMS), has a single parent but can have multiple children, establishing one-to-many relationships. In IMS, the root segment serves as the top-level parent with one occurrence per database record, while child segments—such as those representing illnesses or treatments under a record—can occur multiply based on non-unique keys like dates, enabling ordered storage in ascending sequence for efficient . This structure excels in representing naturally ordered data, such as file systems or organizational charts, where predefined paths facilitate straightforward navigation from parent to child. However, the hierarchical model is limited in supporting many-to-many relationships, as it enforces strict one-to-many links without native mechanisms for multiple parents, often requiring redundant segments as workarounds that increase storage inefficiency. Access relies on procedural , traversing fixed hierarchical paths sequentially, which suits simple queries but becomes cumbersome for complex retrievals involving non-linear paths. The network data model, standardized by the Conference on Data Systems Languages () in the early 1970s, extends this by representing data as records connected through sets, allowing more flexible graph-like topologies. A set defines a named relationship between one owner record type and one or more member record types, where the owner acts as a to multiple members, and members can belong to multiple sets, supporting many-to-one or many-to-many links via pointer chains or rings. For instance, a material record might serve as a member in sets owned by different components like cams or gears, enabling complex interlinks; implementation typically uses forward and backward pointers to traverse these relations efficiently within a set. Access in systems, such as through (DML) commands like FIND NEXT or FIND OWNER, remains procedural, navigating via these links. While the network model overcomes the hierarchical model's restriction to single-parentage by permitting records to have multiple owners, both approaches share reliance on procedural navigation, requiring explicit path traversal that leads to query inefficiencies, such as sequential pointer following for ad-hoc retrievals across multiple sets. These models dominated database systems on mainframes during the 1960s and 1970s, with IMS developed by IBM in 1966 for Apollo program inventory tracking and CODASYL specifications emerging from 1969 reports to standardize network structures. Widely adopted in industries like manufacturing and aerospace for their performance in structured, high-volume transactions, they persist as legacy systems in some enterprises but have influenced modern hierarchical representations in formats like XML and JSON, which adopt tree-based nesting for semi-structured data.

Relational Model

The relational model, introduced by in 1970, represents data as a collection of relations, each consisting of organized into attributes, providing a declarative framework for that emphasizes logical structure over physical implementation. A relation is mathematically equivalent to a set of , where each is an ordered list of values corresponding to the relation's attributes, ensuring no duplicate exist to maintain set semantics. Attributes define the domains of possible values, typically atomic to adhere to , while primary keys uniquely identify each within a relation, and foreign keys enforce by linking across relations through shared values. Relational algebra serves as the formal query foundation of the model, comprising a set of operations on relations that produce new relations, enabling precise data manipulation without specifying access paths. Key operations include selection (σ\sigma), which filters tuples satisfying a condition, expressed as σcondition(R)\sigma_{condition}(R) where RR is a relation and conditioncondition is a predicate on attributes; for example, σage>30(Employees)\sigma_{age > 30}(Employees) retrieves all employee tuples where age exceeds 30. Projection (π\pi) extracts specified attributes, eliminating duplicates, as in πname,salary(Employees)\pi_{name, salary}(Employees) to obtain unique names and salaries. Join (⋈\bowtie) combines relations based on a condition, such as R⋈R.id=S.idSR \bowtie_{R.id = S.id} S to match related tuples from RR and SS on a shared identifier. Other fundamental operations are union (∪\cup), merging compatible relations while removing duplicates, and difference (−-), yielding tuples in one relation but not another, both preserving relational structure. These operations are closed, compositional, and form a complete query language when including rename (ρ\rho) for attribute relabeling. Normalization theory addresses redundancy and anomaly prevention by decomposing relations into smaller, dependency-preserving forms based on functional dependencies (FDs), where an FD X→YX \rightarrow Y indicates that attribute set XX uniquely determines YY. (1NF) requires atomic attribute values and no repeating groups, ensuring each holds indivisible entries. (2NF) builds on 1NF by eliminating partial dependencies, where non-prime attributes depend fully on the entire , not subsets. (3NF) further removes transitive dependencies, mandating that non-prime attributes depend only on s. Boyce-Codd normal form (BCNF) strengthens 3NF by requiring every determinant to be a , resolving certain irreducibility issues while aiming to preserve all FDs without lossy joins. The model's advantages include data independence, separating logical schema from physical storage to allow modifications without application changes, and support for ACID properties—atomicity, consistency, isolation, durability—in transaction processing to ensure reliable concurrent access. SQL (Structured Query Language), developed as a practical interface, translates relational algebra into user-friendly declarative statements for querying and manipulation. However, the model faces limitations in natively representing complex, nested objects like multimedia or hierarchical structures, often requiring denormalization or extensions that compromise purity.

Object-Oriented and NoSQL Models

The object-oriented data model extends traditional by incorporating principles, such as classes, , and polymorphism, to represent both data and behavior within a unified structure. In this model, data is stored as objects that encapsulate attributes and methods, allowing for complex relationships like inheritance hierarchies where subclasses inherit properties from parent classes, and polymorphism enables objects of different classes to be treated uniformly through common interfaces. The Object Data Management Group (ODMG) standard, particularly ODMG 3.0, formalized these concepts by defining a core object model, object definition language (ODL), and bindings for languages like C++ and , ensuring portability across systems. This integration facilitates seamless persistence of objects from object-oriented languages, such as , where developers can store and retrieve class instances directly without manual mapping to relational tables, reducing impedance mismatch in applications involving complex entities like or CAD designs. For instance, Java objects adhering to ODMG can be persisted using standard APIs that abstract underlying storage, supporting operations like traversal of trees and dynamic method invocation. NoSQL models emerged in the to address relational models' limitations in and schema rigidity for unstructured or in distributed environments, prioritizing horizontal scaling over strict compliance. These models encompass several variants, including document stores, key-value stores, column-family stores, and graph databases, each optimized for specific data access patterns in scenarios. Document-oriented NoSQL databases store data as self-contained, schema-flexible documents, often in JSON-like formats, enabling nested structures and varying fields per document to handle diverse, evolving data without predefined schemas. exemplifies this approach, using (Binary JSON) documents that support indexing on embedded fields and aggregation pipelines for querying hierarchical data, making it suitable for and real-time analytics. Key-value stores provide simple, high-performance access to data via unique keys mapping to opaque values, ideal for caching and session management where fast lookups predominate over complex joins. , a prominent key-value system, supports structures like strings, hashes, and lists as values, with in-memory storage for sub-millisecond latencies and persistence options for . Column-family (or wide-column) stores organize into rows with dynamic columns grouped into families, allowing sparse, variable schemas across large-scale distributed tables to manage high-velocity writes and reads. , for example, uses a sorted of column families per row key, enabling tunable consistency and linear across clusters for time-series and IoT applications. Graph models within represent data as nodes (entities), edges (relationships), and properties (attributes on nodes or edges), excelling in scenarios requiring traversal of interconnected data like recommendations or fraud detection. implements the property graph model, where nodes and directed edges carry key-value properties, and supports the Cypher for , such as finding shortest paths in social networks via declarative syntax like MATCH (a:Person)-[:FRIENDS_WITH*1..3]-(b:Person) RETURN a, b. A key trade-off in models, particularly in distributed systems, is balancing scalability against consistency, as articulated by the , which posits that a system can only guarantee two of three properties: Consistency (all nodes see the same data), (every request receives a response), and Partition tolerance (the system continues operating despite network partitions). Many databases, like , favor availability and partition tolerance (AP systems) with , using mechanisms such as reads to reconcile updates, while graph stores like often prioritize consistency for accurate traversals at the cost of availability during partitions.

Semantic and Specialized Models

The entity-relationship (ER) model is a conceptual data model that represents data in terms of entities, attributes, and relationships to capture the semantics of an information system. Entities are objects or things in the real world with independent existence, such as "Employee" or "Department," each described by attributes like name or ID. Relationships define associations between entities, such as "works in," with cardinality constraints specifying participation ratios: one-to-one (1:1), one-to-many (1:N), or many-to-many (N:M). This model facilitates the design of relational databases by mapping entities to tables, attributes to columns, and relationships to foreign keys or junction tables. Semantic models extend data representation by emphasizing meaning and logical inference, enabling knowledge sharing across systems. The (RDF) structures data as consisting of a subject (resource), predicate (property), and object (value or resource), forming directed graphs for . RDF supports interoperability on the web by allowing statements like " (subject) isCapitalOf (predicate) (object)." Ontologies built on RDF, such as those using the (OWL), define classes, properties, and axioms for reasoning, including subclass relationships and equivalence classes to infer new knowledge. OWL enables automated inference, such as deducing that if "" is a subclass of "" and "" has property "breathes air," then instances of "" inherit that property. Geographic data models specialize in representing spatial information for geographic information systems (GIS). The vector model uses discrete geometric primitives—points for locations, lines for paths, and polygons for areas—to depict features like cities or rivers, with coordinates defining their positions. In contrast, the raster model organizes data into a grid of cells (pixels), each holding a value for continuous phenomena like or , suitable for analysis over large areas. Spatial relationships, such as , capture connectivity and adjacency (e.g., shared boundaries between polygons) in systems like , enabling operations like overlay analysis. Generic models provide abstraction for diverse domains, often serving as bridges to implementation. (UML) class diagrams model static structures with classes (entities), attributes, and associations, offering a visual notation for object-oriented design across software systems. For , XML Schema defines document structures, elements, types, and constraints using XML syntax, ensuring validation of hierarchical formats. Similarly, specifies the structure of JSON documents through keywords like "type," "properties," and "required," supporting validation for web APIs and configuration files. These models uniquely incorporate inference rules and domain-specific constraints to enforce semantics beyond basic structure. In semantic models, OWL's allows rule-based deduction, such as transitive properties for "partOf" relations. Geographic models apply constraints like topological consistency (e.g., no overlapping polygons without intersection) and operations such as spatial joins, which combine datasets based on proximity or containment to derive new insights, like aggregating population within flood zones. In , they link high-level semantics to the three-schema architecture by refining user views into logical schemas.

Core Concepts

Data Modeling Process

The data modeling process is a structured workflow that transforms business requirements into a blueprint for data storage and management, ensuring alignment with organizational needs and system efficiency. It typically unfolds in sequential yet iterative phases, beginning with understanding the domain and culminating in a deployable database schema. This methodology supports forward engineering, where models are built from abstract concepts to concrete implementations, and backward engineering, where existing databases are analyzed to generate or refine models. Tools such as ER/Studio or erwin Data Modeler facilitate these techniques by automating diagram generation, schema validation, and iterative refinements through visual interfaces and scripting capabilities. The initial phase, , involves gathering and documenting business rules, user needs, and data flows through interviews, workshops, and documentation review. Stakeholders, including business analysts and end-users, play a critical role in this stage to capture accurate and resolve early ambiguities, such as unclear entity definitions or conflicting rules, preventing downstream rework. This phase establishes the foundation for subsequent modeling by identifying key entities, processes, and constraints without delving into technical details. Following , conceptual modeling creates a high-level of the , often using entity-relationship diagrams to depict entities, attributes, and relationships in terms. This phase focuses on clarity and completeness, avoiding implementation specifics to communicate effectively with non-technical audiences. It serves as a bridge to more detailed designs, emphasizing iterative feedback to refine the model based on stakeholder validation. In the logical design phase, the is refined into a detailed that specifies data types, keys, and relationships while applying techniques like normalization to eliminate redundancies and ensure . Normalization, a core aspect of development, organizes data into tables to minimize anomalies during operations. This step produces a technology-agnostic model ready for physical , with tools enabling automated checks for consistency. The physical design phase translates the logical model into a database-specific , incorporating elements like indexing for query optimization, partitioning for large-scale data distribution, and storage parameters tailored to the chosen database management system. Considerations for performance, such as in read-heavy scenarios, ensure as volumes grow, balancing query speed against maintenance complexity. Iterative refinement here involves prototyping and testing to validate against real-world loads. Best practices throughout the process emphasize continuous stakeholder involvement to maintain alignment with evolving business needs and to handle ambiguities through prototyping or sample . Ensuring involves anticipating growth by designing flexible structures, such as modular entities that support future extensions without major overhauls. Model can be assessed using metrics like cohesion, which measures how well entities capture cohesive business concepts, and , which evaluates the degree of inter-entity dependencies to promote . Common pitfalls include overlooking constraints like rules, which can lead to inconsistencies, or ignoring projected volume growth, resulting in bottlenecks. To mitigate these, practitioners recommend regular validation cycles and documentation of assumptions, fostering robust models that support long-term system reliability.

Key Properties and Patterns

models incorporate several core properties to ensure reliability and robustness in representing and managing information. integrity requires that each row in a table can be uniquely identified by its , preventing duplicate or null values in key fields to maintain distinct entities. enforces that values in one table match values in another or are null, preserving valid relationships across tables. Consistency is achieved through properties in transactional systems, where atomicity ensures operations complete fully or not at all, isolation prevents interference between concurrent transactions, and guarantees committed changes persist despite failures. in models involves access controls, such as role-based mechanisms that restrict user permissions to read, write, or modify specific elements based on predefined policies. Extensibility allows models to accommodate new attributes or structures without disrupting existing functionality, often through modular designs that support future enhancements. Data organization within models relies on foundational structures to optimize storage and retrieval. Arrays provide for ordered collections, trees enable hierarchical relationships for nested data like organizational charts, and hashes facilitate fast lookups via key-value pairs in associative storage. These structures underpin properties like atomicity, which treats data operations as indivisible units, and , which ensures data survives system failures through mechanisms like or replication. Common in promote reusability and efficiency. The ensures a single instance for unique , such as a global configuration table, avoiding . Factory patterns create complex objects, like generating instances based on type specifications in object-oriented models. Adapter patterns integrate legacy systems by wrapping incompatible interfaces, enabling seamless data exchange without overhaul. Anti-patterns, such as god objects—overly centralized handling multiple responsibilities—can lead to maintenance issues and reduced scalability by violating . Evaluation of data models focuses on criteria like completeness, which assesses whether all necessary elements are represented without omissions; minimality, ensuring no redundant or extraneous components; and understandability, measuring how intuitively the model conveys structure and relationships to stakeholders. Tools like Data Vault 2.0 apply these patterns through hubs for core business keys, links for relationships, and satellites for descriptive attributes, facilitating scalable and auditable designs. Normalization forms serve as a tool to enforce properties like minimality by reducing redundancy in relational models.

Theoretical Foundations

The theoretical foundations of data models rest on mathematical structures from , logic, and , providing a rigorous basis for defining, querying, and constraining data representations. In the relational paradigm, the formal theory distinguishes between and . consists of a procedural set of operations—such as selection (σ\sigma), projection (π\pi), union (∪\cup), set difference (−-), Cartesian product (×\times), and rename (ρ\rho)—applied to relations as sets of tuples. , in contrast, is declarative: (TRC) uses formulas of the form {t∣ϕ(t)}\{ t \mid \phi(t) \}, where tt is a tuple variable and ϕ\phi is a formula, while domain relational calculus (DRC) quantifies over domain variables, such as {⟨x1,…,xn⟩∣ϕ(x1,…,xn)}\{ \langle x_1, \dots, x_n \rangle \mid \phi(x_1, \dots, x_n) \}. Codd's proves the computational equivalence of and safe , asserting that they possess identical expressive power for querying relational databases; specifically, for any query expressible in one, there exists an equivalent formulation in the other, ensuring that declarative specifications can always be translated into procedural executions without loss of capability. Dependency theory further solidifies these foundations by formalizing integrity constraints through functional dependencies (FDs), which capture semantic relationships in data. An FD X→YX \to Y on a relation RR means that the values of attributes in YY are uniquely determined by those in XX; formally, for any two tuples t1,t2∈Rt_1, t_2 \in R, if t1[X]=t2[X]t_1[X] = t_2[X], then t1[Y]=t2[Y]t_1[Y] = t_2[Y]. The Armstrong axioms form a sound and complete axiomatization for inferring all FDs from a given set:
  • Reflexivity: If Y⊆XY \subseteq X, then X→YX \to Y.
  • Augmentation: If X→YX \to Y, then XZ→YZXZ \to YZ for any set ZZ.
  • Transitivity: If X→YX \to Y and Y→ZY \to Z, then X→ZX \to Z.
    These axioms, derivable from set inclusion properties, enable the computation of dependency closures and are essential for normalization and constraint enforcement, as they guarantee that all implied FDs can be systematically derived.
Complexity analysis in data models addresses the computational resources required for operations like querying and optimization, highlighting inherent limitations. Query optimization often focuses on join algorithms, where the naive nested-loop join exhibits O(∣R∣×∣S∣)O(|R| \times |S|) for relations RR and SS, degenerating to O(n2)O(n^2) when ∣R∣≈∣S∣=n|R| \approx |S| = n, due to exhaustive pairwise comparisons. More advanced techniques, such as sort-merge or hash joins, reduce this to O(nlog⁡n)O(n \log n) or O(n)O(n) in the average case, but worst-case bounds remain tied to input size and estimates. In semantic data models, decidability concerns whether queries or entailments can be algorithmically resolved; for instance, in description logic-based models like ALC (attributive language with complement), is decidable via tableau methods with exponential , but more expressive extensions like ALCQIO introduce undecidability by allowing nominals alongside inverse roles and qualified number restrictions, which can encode undecidable problems. Advanced theoretical constructs extend these foundations to broader contexts. in the provides a logical framework for ontologies, where types classify resources in RDF triples (subject-predicate-object) and ensure type-safe inferences in ; for example, RDFS defines class hierarchies and range restrictions, grounding in to prevent type errors during reasoning. offers an abstract algebraic lens for data model transformations, modeling schemas as categories (with objects as entity types and morphisms as relationships) and transformations as functors that preserve structure; a between functors then composes model mappings, enabling verifiable conversions between heterogeneous models like relational to graph without loss. These concepts, building briefly on the relational origins introduced by Codd, unify disparate data paradigms under rigorous mathematical equivalence.

Applications and Extensions

In Database Design and Architecture

In database design, the workflow begins with mapping conceptual data models to physical implementations, transforming high-level entity-relationship diagrams into database-specific structures optimized for storage and retrieval. This process involves selecting appropriate indexing strategies, such as or hash indexes, to accelerate query performance by reducing disk I/O operations during data access. For instance, in , the storage engine facilitates this mapping by providing row-level locking, crash recovery, and support for constraints, ensuring compliance in physical layouts. The three-schema guides this workflow by separating external user views, conceptual schemas, and internal physical details to maintain . Data models integrate into broader architecture, particularly in data warehouses where and schemas organize facts and dimensions for efficient analytical processing, as outlined in Ralph Kimball's approach. These schemas denormalize data to minimize joins, supporting high-volume queries in systems. ETL processes further embed data models by extracting raw data from disparate sources, applying transformations to align with schema definitions, and loading refined datasets into the warehouse for consistent architecture. Database management systems (DBMS) incorporate tools and standards to support robust data modeling, with PostgreSQL offering extensions like pg_trgm for trigram-based similarity searches and hstore for key-value storage, enabling flexible schema adaptations. Compliance with ANSI SQL standards ensures portability across DBMS, as PostgreSQL implements core features like SQL-92 and SQL:2011 for declarative query handling and integrity constraints. Challenges in this domain include performance tuning, where inefficient indexes or suboptimal query plans can lead to high latency; mitigation involves continuous monitoring of execution metrics and workload analysis to refine physical designs. Migrating between models, such as from relational to NoSQL, demands schema redesign to shift from normalized tables to document or key-value stores, often requiring application refactoring to handle denormalization and eventual consistency.

In Domain-Specific Contexts

In geographic information systems (GIS), spatial data models emphasize vector representations of features like points, lines, and polygons, incorporating topological relationships to maintain spatial accuracy and enable complex analyses. The Open Geospatial Consortium (OGC) standards, particularly the Access specification, define these geometry types and support operations such as and union, which are foundational for GIS across software platforms. Topology rules within these models enforce constraints like non-overlapping polygons and complete boundary coverage, preventing errors in spatial relationships such as adjacency and connectivity. These rules are essential for overlay analysis, where multiple layers are superimposed to generate derived datasets, such as mapping flood-prone areas by combining elevation and river boundary data, thereby enhancing in and environmental management. In the , ontologies leverage RDF for data serialization and for expressive reasoning, establishing shared vocabularies that promote among heterogeneous datasets. For example, DBpedia integrates content using an -based to structure entities and relations, enabling SPARQL-based queries that link knowledge across domains like and for enhanced discovery. This approach facilitates large-scale integration, as ontologies provide a logic-based framework for inferring implicit relationships, supporting applications from to automated knowledge aggregation. Biomedical data modeling relies on standards like HL7 FHIR, which organizes health information into modular resources—such as for demographics and for clinical measurements—to ensure consistent exchange across electronic health systems. This resource-based structure incorporates terminologies like and LOINC, covering approximately 51% of data elements needed for multi-site , thus streamlining eSource data collection and reducing integration challenges in studies involving diverse registries. In finance, XBRL schemas employ taxonomies to tag financial concepts (e.g., "ifrs:") within reports, allowing machine-readable structuring of balance sheets and income statements for regulatory filings. Adopted in over 2 million UK annual reports and mandatory for EU IFRS disclosures since 2021, XBRL enables automated validation and analysis, improving transparency and efficiency in global financial reporting. Entity-relationship (ER) models adapt to supply chains by diagramming core entities like suppliers, items, and production orders, with cardinalities defining flows such as one-to-many supplier-to-part relationships. In a of e-supply chain management for a crispy manufacturer, ER diagrams integrated , production, and distribution processes, incorporating for waste tracking to optimize and reduce delays. Such adaptations yield benefits like enhanced query optimization in spatial joins for GIS applications, where filter-and-refine techniques using minimum bounding rectangles cut I/O costs by approximating geometries, enabling scalable analysis of networks with performance gains up to orders of magnitude on large datasets. In recent years, has increasingly automated aspects of , particularly through techniques for entity extraction and schema generation. For instance, ML-based tools analyze to infer entities, relationships, and attributes, enabling automated creation of initial data schemas in complex environments. Tools like dbt further enhance this by providing semantic layers that define reusable metrics and as code, ensuring consistency across , dashboards, and AI applications while integrating with cloud warehouses for scalable . Data mesh architectures represent a shift toward decentralized data ownership, treating data as products managed by domain-specific teams rather than centralized IT, which addresses scalability bottlenecks in traditional monolithic models. This approach contrasts with established warehousing methods like Kimball's dimensional modeling, which focuses on denormalized star schemas for business intelligence queries, whereas Data Vault 2.0 emphasizes agile, auditable structures using hubs for core business keys, links for relationships, and satellites for descriptive attributes, supporting incremental loading and historical tracking in enterprise-scale warehouses. Data Vault 2.0 integrates well with data mesh by enabling domain-owned data products in lakehouse architectures, such as Databricks' medallion layers, where raw data flows into silver-layer vaults before refinement. Real-time and hybrid data modeling trends emphasize streaming integrations and cross-platform compatibility to handle dynamic workloads. serves as a foundational streaming platform, enabling event-driven models that process continuous data flows in real time, often combined with processing engines like for agentic AI applications that support autonomous decision-making on live inputs. Multi-cloud strategies enhance this by allowing data models to span providers like AWS, Azure, and Google Cloud, optimizing for cost, resilience, and compliance through federated architectures that avoid , with adoption projected to rise as 70% of enterprises pursue hybrid deployments by late 2025. Graph analytics further bolsters these trends in AI knowledge graphs, where interconnected nodes and edges model complex relationships for enhanced reasoning and , as seen in GraphRAG systems that improve LLM accuracy by grounding responses in structured data. As of 2025, vector databases have surged in prominence for storing embeddings—numerical representations of semantics—facilitating efficient similarity searches in generative AI applications, with the market expected to grow from $276 million to $526 million driven by Retrieval-Augmented needs. Ethical considerations in AI-driven models increasingly focus on , as persistent racial and gender disparities in LLMs (e.g., up to 69% higher criminal rates for certain demographics) underscore the need for diverse training datasets, post-hoc debiasing techniques, and fairness audits, supported by rising investments like the NIH's $276 million in AI research. These practices ensure models promote equity, with global frameworks from organizations like the emphasizing transparency in and algorithmic .

Diagram-Based Techniques

Diagram-based techniques utilize graphical notations to represent data models, enhancing comprehension, , and validation among developers, analysts, and stakeholders in the design process. These methods transform abstract data concepts into visual formats that highlight structures, relationships, and flows, thereby supporting iterative refinement and error detection early in modeling. Unlike textual descriptions, diagrams leverage spatial arrangement and symbols to convey complexity intuitively, making them indispensable for bridging technical and non-technical perspectives in data system development. Data structure diagrams form a foundational category, with tree diagrams employed to depict hierarchical data arrangements, such as tree-like parent-child relationships in early database designs. In these diagrams, nodes represent data elements, and directed arrows or branches illustrate or dependency flows, enabling clear visualization of top-down organizational structures. For object-oriented data modeling, (UML) class diagrams illustrate static data structures by showing classes as rectangles with compartments for attributes, operations, and associations like or aggregation. These diagrams emphasize data encapsulation and inter-class relationships, providing a blueprint for object persistence in databases. UML sequence diagrams complement this by capturing dynamic data exchanges, portraying objects as lifelines with timed messages to model interaction sequences and state changes during . Data-flow diagrams (DFD) offer a process-centric view, mapping how enters, transforms, and exits a through interconnected components. Key elements include processes (transformative functions), stores (persistent repositories), external entities (sources or sinks), and flows (directional movements), all labeled to ensure . The Gane-Sarson notation standardizes this representation, using rounded rectangles for processes, parallel open rectangles for stores, squares for external entities, and labeled arrows for flows, which contrasts with circle-based alternatives for clarity in complex . DFDs employ hierarchical decomposition: the context diagram (Level 0) encapsulates the entire as a single process interacting with externals, while Level 1 and beyond progressively detail subprocesses, balancing with to avoid overload. Additional specialized diagrams address specific model paradigms, such as Bachman diagrams for network data models, which graph record types as boxes connected by arrows denoting owner-member sets and navigational chains. These diagrams encode many-to-many relationships explicitly, facilitating pointer-based access in pre-relational systems like databases. diagrams, tailored for relational modeling, use rectangular entity boxes divided by lines to separate keys and attributes, with solid or dashed connecting lines indicating identifying or non-identifying relationships, complete with symbols (e.g., one-to-many) and notations. This syntax enforces semantic integrity, supporting conceptual-to-logical schema transitions in structured environments. In practice, these diagram-based techniques aid by visually eliciting and validating stakeholder inputs through iterative sketching and walkthroughs, reducing miscommunication in diverse teams. They also support , where existing code or are analyzed to generate diagrams that reconstruct and document legacy data architectures. Tools such as streamline this by providing drag-and-drop interfaces, shape libraries, and collaboration features for creating and exporting , UML diagrams, and similar visuals. Entity-relationship diagrams, as a semantic visualization tool, briefly intersect here by graphically outlining entity attributes and associations in conceptual phases.

Conceptual and Information Models

Conceptual models in emphasize abstract representations that align closely with business domains, prioritizing semantic clarity over implementation details. Object-role modeling (ORM), a fact-based approach, represents through elementary facts where entities play specific roles in relationships, such as an representing a country. This notation avoids complex attributes by expressing facts in sentences, enabling intuitive communication with stakeholders. Business rules in ORM are articulated graphically or textually in , for instance, prohibiting an employee from directing and assessing the same project, which supports validation without technical jargon. ORM models facilitate transformation into entity-relationship (ER) diagrams or relational schemas by mapping roles to attributes and constraints to database rules, such as converting frequency constraints into equality checks. A key distinction lies in its emphasis on business rules through population checks, where sample data instances are populated to verify constraints, like ensuring unique room usage by testing counterexamples. This validation process involves clients in reviewing fact populations, confirming model accuracy against real-world scenarios and reducing errors in . Information models extend conceptual paradigms by standardizing metadata for across systems, particularly in IT . The Common Information Model (CIM), developed by the (DMTF), provides an object-oriented framework to represent managed elements like devices and networks uniformly. CIM focuses on metadata through classes, , associations, and qualifiers, enabling the exchange of independent of underlying technologies. Its structure includes a core model for general concepts and common models for specific domains, promoting consistent in heterogeneous environments. Object models, often realized in the (UML), integrate data with behavior through encapsulation, differing from pure data models that focus solely on structural relationships. In UML, classes encapsulate attributes (data) and methods (operations), such as a class with a getName() method, allowing objects to manage their internal state privately. This contrasts with traditional data models by incorporating dynamic aspects, though UML's design-level details can limit broader conceptual analysis compared to fact-oriented approaches like ORM. UML supports brief integrations with data models via class diagrams that extend static views into behavioral ones, such as diagrams.

References

  1. https://cedar.princeton.edu/understanding-data/what-data-model
  2. https://www.ibm.com/think/topics/data-modeling
  3. https://www.techtarget.com/searchdatamanagement/definition/data-modeling
  4. https://www.techtarget.com/searchdatacenter/definition/IMS-Information-Management-System
  5. https://dl.acm.org/doi/10.1145/362384.362685
  6. http://courses.washington.edu/geog482/resource/Codd_1981_Data_Model.pdf
  7. https://codex.cs.yale.edu/avi/home-page/publication-dir/Journals/acm-survey-96a.pdf
  8. https://www.umsl.edu/~sauterv/analysis/F2015/DataModeling.html.htm
  9. https://www.ewsolutions.com/origins-of-logical-and-physical-data-modeling/
  10. https://plato.stanford.edu/entries/settheory-early/
  11. https://mathshistory.st-andrews.ac.uk/HistTopics/Beginnings_of_set_theory/
  12. https://plato.stanford.edu/entries/boole/
  13. https://mathshistory.st-andrews.ac.uk/Biographies/Peano/
  14. https://plato.stanford.edu/entries/logic-firstorder-emergence/
  15. https://plato.stanford.edu/entries/frege/
  16. https://iep.utm.edu/russ-log/
  17. https://www.ams.org/books/spec/108/spec108-endmatter.pdf
  18. https://link.springer.com/article/10.1007/BF00370681
  19. https://plato.stanford.edu/entries/computing-history/
  20. https://www.dataversity.net/articles/brief-history-data-modeling/
  21. https://jimgray.azurewebsites.net/db_history.htm
  22. https://www.ibm.com/docs/en/zos-basic-skills?topic=now-history-ims-beginnings-nasa
  23. https://ptgmedia.pearsoncmg.com/images/0131856715/samplechapter/0131856715_ch01.pdf
  24. https://www.db-book.com/db6/appendices-dir/d.pdf
  25. https://www.cockroachlabs.com/blog/history-of-databases-distributed-sql/
  26. https://www.ibm.com/history/relational-database
  27. https://dl.acm.org/doi/10.1145/800296.811515
  28. https://www.historyofinformation.com/detail.php?id=910
  29. https://dl.acm.org/doi/10.1145/320434.320440
  30. https://dspace.mit.edu/bitstream/handle/1721.1/47432/entityrelationshx00chen.pdf
  31. https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub127.pdf
  32. https://www.ibm.com/new/announcements/celebrating-30-years-of-db2-running-the-worlds-mission-critical-workloads
  33. https://www.oracle.com/database/50-years-relational-database/
  34. https://dl.acm.org/doi/10.1145/191843.191937
  35. https://www.mgt.ncu.edu.tw/~ylchen/database/odmg-3.pdf
  36. https://www.ibm.com/docs/en/ims/15.4.0?topic=database-hierarchy-examples
  37. https://www.ibm.com/docs/en/ims/15.4.0?topic=ims-comparison-hierarchical-relational-databases
  38. https://dl.acm.org/doi/pdf/10.1145/1408800.1408829
  39. https://www.mcobject.com/docs/Content/Fundamental_Concepts/Database_Models.htm
  40. https://www.ibm.com/history/information-management-system
  41. https://twobithistory.org/2017/10/07/the-most-important-database.html
  42. https://www.dremio.com/wiki/hierarchical-database/
  43. https://forum.thethirdmanifesto.com/wp-content/uploads/asgarosforum/987737/00-efc-further-normalization.pdf
  44. https://jimgray.azurewebsites.net/papers/theTransactionConcept.pdf
  45. https://dl.acm.org/doi/pdf/10.1145/6012.15404
  46. https://www.odbms.org/odmg-standard/reading-room/odmg-2-0-a-standard-for-object-storage/
  47. https://cs.ulb.ac.be/public/_media/teaching/odmg.pdf
  48. https://www.odbms.org/odmg-standard/odmg-book/odmg-2-0-book-extract/
  49. https://www.odbms.org/odmg-standard/reading-room/odmg-the-industry-standard-for-java-object-storage/
  50. https://www.odbms.org/odmg-standard/reading-room/theres-an-odmg-database-in-your-future/
  51. https://www.mongodb.com/resources/basics/databases/nosql-explained
  52. https://www.altexsoft.com/blog/nosql-databases/
  53. https://neo4j.com/docs/getting-started/graph-database/
  54. https://neo4j.com/docs/cypher-manual/current/queries/basic/
  55. https://dl.acm.org/doi/10.1145/1835698.1835701
  56. https://cacm.acm.org/blogcacm/errors-in-database-systems-eventual-consistency-and-the-cap-theorem/
  57. https://www.w3.org/RDF/
  58. https://www.w3.org/TR/owl2-overview/
  59. https://saylordotorg.github.io/text_essentials-of-geographic-information-systems/s08-data-models-for-gis.html
  60. https://www.omg.org/spec/UML/2.5.1/About-UML
  61. https://www.w3.org/TR/xmlschema-1/
  62. https://json-schema.org/specification
  63. https://postgis.net/workshops/postgis-intro/joins.html
  64. https://www.quest.com/products/erwin-data-modeler
  65. https://www.castordoc.com/ai-strategy/creating-a-robust-logical-data-model
  66. https://www.semanticscholar.org/paper/Dependency-Structures-of-Data-Base-Relationships-Armstrong/0d21a989f1ae615553fc79c4eea199852452b80f
  67. https://arxiv.org/abs/2201.04905
  68. https://learn.microsoft.com/en-us/sql/relational-databases/sql-server-index-design-guide?view=sql-server-ver17
  69. https://dev.mysql.com/doc/refman/8.4/en/innodb-storage-engine.html
  70. https://www.cs.purdue.edu/homes/bb/cs448_Fall2017/lpdf/Chapter02.pdf
  71. https://www.databricks.com/glossary/star-schema
  72. https://www.ibm.com/think/topics/etl
  73. https://learn.microsoft.com/en-us/sql/relational-databases/performance/monitor-and-tune-for-performance?view=sql-server-ver17
  74. https://aws.amazon.com/blogs/database/sql-to-nosql-planning-your-application-migration-to-amazon-dynamodb/
  75. https://www.ogc.org/standards/
  76. https://pubs.usgs.gov/of/2004/1451/pdf/wahl.pdf
  77. http://www.w3.org/TR/owl2-primer/
  78. https://pmc.ncbi.nlm.nih.gov/articles/PMC7586462/
  79. https://cacm.acm.org/research/a-review-of-the-semantic-web-field/
  80. https://pmc.ncbi.nlm.nih.gov/articles/PMC8075534/
  81. https://www.xbrl.org/the-standard/what/ixbrl/
  82. https://ijpsat.org/index.php/ijpsat/article/view/4806
  83. https://www.cs.umd.edu/~hjs/pubs/jacoxtrjoin07.pdf
  84. https://www.integrate.io/blog/mastering-data-warehouse-modeling/
  85. https://www.getdbt.com/blog/data-integration
  86. https://www.databricks.com/glossary/data-vault
  87. https://www.kai-waehner.de/blog/2025/04/14/how-apache-kafka-and-flink-power-event-driven-agentic-ai-in-real-time/
  88. https://www.dataversity.net/articles/cloud-computing-trends-in-2025/
  89. https://www.sciencedirect.com/science/article/pii/S1570826825000083
  90. https://www.datainsightsmarket.com/reports/vector-databases-for-generative-ai-applications-504441
  91. https://hai.stanford.edu/assets/files/hai_ai_index_report_2025.pdf
  92. https://www.lucidchart.com/pages/data-flow-diagram
  93. https://www.geeksforgeeks.org/dbms/hierarchical-model-in-dbms/
  94. https://cacm.acm.org/opinion/how-charles-bachman-invented-the-dbms-a-foundation-of-our-digital-world/
  95. https://www.idef.com/idef1x-data-modeling-method/
  96. https://kilthub.cmu.edu/articles/Lecture_Notes_on_Requirements_Elicitation/6575060/files/12061622.pdf
  97. https://vtechworks.lib.vt.edu/bitstream/handle/10919/34174/etd.pdf?sequence=1&isAllowed=y
  98. https://www.lucidchart.com/pages
  99. https://www.ibm.com/think/topics/entity-relationship-diagram
  100. https://www.orm.net/pdf/dppd.pdf
  101. https://courses.washington.edu/css475/orm.pdf
  102. https://www.dmtf.org/sites/default/files/standards/documents/DSP0004V2.3_final.pdf
  103. https://arxiv.org/pdf/2106.00267
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.