Data Modeling - Data Model

> (Data|State) Management and Processing > Data Modeling (Relational Database, Code, Graph, Text)

1 - About

A data model in software engineering is an abstract model that describes how data are represented and accessed. Data models formally define data elements and relationships among data elements for a domain of interest.

Synonym of schema.

A data model is a representation of:

A data model is a formal way to represent the business rules.

It is built and modified until it represents the business well enough to write a system. Data models must be built during requirements.

Data models are extended to become class diagrams in the Unified Modeling Language (UML) by adding the behaviours of each entity to the model.

You can find here several well-known data model: Data Modeling - Data Models

A Data Model as three components

    • Rows and columns (Matrix, Table)
    • Nodes and edges
    • key-value pairs
    • sequence of bytes
    • ….
    • Structure: All rows must have the same number of columns
    • Data domain: All value in a column must have the same type
    • Relationship: A child cannot have three parents
  • Operations supported on the structure
    • Find the values of the primary key
    • Get

3 - Without Data Model

4 - Data Modeling Process

4.1 - Conceptual data model

A conceptual DB schema is a high- level description of the database level description of the database, independent of the particular DBMS.

4.2 - Logical data model

A logical data model shows the organization of data without indicating how it is stored, created, or manipulated but describe the real world business data in table (relational) form.

It's a method to discover the data, relationships and rules of a business, collectively called the business rules.

Logical data models are the basis of:

  • Physical data models, or actual databases
  • Applications, parts of which can be automatically generated from the data model

Business needs to build logical data model so users and developers both understand business rules of company. Models enable users and developers to have single view of system

In an object model (class diagram) we not only model data, but also the methods (behaviours, procedures) that each entity has.


4.3 - Physical data model

Logical design is what you draw with a pen and paper or design with a data modeling tools before building your data warehouse database. Physical design is the creation :

During the physical design process, you convert the data gathered during the logical design phase into a description of the physical structure. Physical design decisions are mainly driven by:

  • query performance
  • and database maintenance aspects.

For example, choosing a partitioning strategy that meets common query requirements enables the Database to take advantage of partition pruning, a way of narrowing a search before performing it.

A Physical Data Model is the physical manifestation of the logical data model (relationships) into database tables and foreign key constraints.

A physical DB schema describes the storage structures and access methods used in order to effectively access and maintain data.

4.4 - Difference between logical and physical

Both, the logical and physical data model are presented as ER diagrams. A logical model is slightly more abstract than a physical model.

  • A physical model represents exactly what is implemented in a database (table, column names, schema, indexes, data types, contraints, tablespaces, partitions and all the other requirements to define the database.
  • A logical model shows entities, attributes, keys and relationships. Names are usually more free-form and descriptive.

5 - Data Model Fit-Gap Analysis

Fit-gap analysis is where you compare your information needs and business requirements with the actual data model structure.

6 - Visualisation Best Practice

A best practice is to draw the child table above the parent table.

7 - Documentation / Reference

  • Source: Batini, C., Ceri, S., and Navathe, S. B., Conceptual Database Design: An Entity-Relationship Approach, The Benjamin/Cummings Publishing Company, Inc., 1992.