Types of Data Modelling

Data Modelling is a foundational concept in the field of data management and analytics. It involves creating conceptual representations of data structures to support various business and technical requirements. Below are the primary types of data Modelling, along with examples to help understand each in a practical context.

1. Conceptual Data Modelling (CDM)

Provide a business-oriented, high-level view of data to identify core entities and relationships without worrying about technical details. Conceptual data modelling creates an abstract representation of business concepts. It focuses on what data means to the business rather than how it is stored. The model is typically expressed with entities and their relationships, offering a shared language for both business and IT.

Audience: Business stakeholders, analysts, data architects, project managers.

Nature

• High-level
• Technology-agnostic
• Simple, entity-relationship style

Examples

• Banking: Customers open Accounts; Accounts generate Transactions.
• Telco: Subscribers sign Contracts; Contracts include Plans.
• Oil & Gas: Wells produce Hydrocarbon Volumes; Volumes are reported in Production Reports.
• Healthcare: Patients receive Treatments; Treatments use Medications.

2. Fully Communication Oriented Information Modelling (FCO-IM)

Capture data exactly as communicated in natural language, ensuring models are both business-meaningful and formally precise. FCO-IM is a fact-oriented method where every piece of information is verbalized as a fact. These facts can then be transformed into multiple model types (ERD, UML, RDF, etc.). It ensures no gap between what businesspeople say and what gets modelled, making it particularly strong for semantic precision.

Audience: Business analysts, data modellers, semantic architects, enterprise data teams.

Nature

• Fact-oriented
• Extremely precise and transformation-friendly
• Strong bridge from business to technical artefacts

Examples

• Banking: “Account 4567 belongs to Customer A.”; “Transaction 123 was executed on 1-Mar-2025.”
• Telco: “Contract 001 includes Plan X.”; “Subscriber 789 activated Contract 001 on 2-Apr-2025.”
• Oil & Gas: “Well Alpha produces 500 barrels on 10-Jan-2025.”; “Well Alpha is located in Field Beta.”
• Healthcare: “Patient John received Treatment T123 on 1-Jul-2025.”; “Treatment T123 used Medication Z.”

3. Logical Data Modelling

Define a detailed, normalized structure of data entities, attributes, and relationships independent of any physical database technology. Logical models introduce attributes, primary keys, and normalization rules. They ensure data consistency and remove redundancy while staying database-agnostic. It’s a critical step before creating physical models.

Audience: Data architects, solution designers, developers.

Nature

• Technology-agnostic but detailed
• Structured with keys, attributes, constraints
• Based on normalization principles

Examples

• Banking: Table “Customer” with CustomerID, Name, Address; Table “Account” with AccountID, Balance, linked to CustomerID.
• Telco: Entity “Subscriber” with attributes (SubscriberID, PlanType); linked to “Usage Records.”
• Oil & Gas: “Well” with WellID, Location; linked to “ProductionRecord” with Date, Volume.
• Healthcare: “Patient” with PatientID, Name, DOB; linked to “Visit” with VisitDate, Diagnosis.

4. Physical Data Modelling

Translate logical models into database-specific implementations, including tables, columns, indexes, and partitions. Physical models account for database platform constraints. They include data types, indexing strategies, performance considerations, and storage optimizations. It’s where modelling meets actual implementation.

Audience: Database administrators (DBAs), data engineers, system architects.

Nature

• Technology-specific
• Includes storage, indexing, datatypes, constraints
• Optimized for performance and scalability

Examples

• Banking: Oracle DB with Customer table (VARCHAR2 for Name, NUMBER for Account Balance).
• Telco: PostgreSQL with partitioned Usage table indexed by SubscriberID.
• Oil & Gas: SQL Server table “ProductionRecord” partitioned by ProductionDate.
• Healthcare: Snowflake schema with Patient fact tables clustered on HospitalID.

5. Dimensional Data Modelling

Support analytics and reporting by structuring data into facts and dimensions. Dimensional modelling simplifies querying and reporting. Data is arranged into fact tables (measurable events) and dimension tables (descriptive attributes). Star and snowflake schemas are common.

Audience: BI developers, data warehouse teams, data analysts.

Nature

• Optimized for OLAP/BI
• Schema patterns: star, snowflake
• Denormalized for performance

Examples

• Banking: FactTransactions table linked to DimCustomer, DimAccount.
• Telco: FactUsage linked to DimSubscriber, DimPlan.
• Oil & Gas: FactProduction linked to DimWell, DimField.
• Healthcare: FactTreatment linked to DimPatient, DimDoctor.

6. Hierarchical Data Modelling

Organize data in a tree-like structure where each record has a single parent. This model represents one-to-many relationships as hierarchies. It is rigid but efficient for traversals along parent-child paths. Historically used in mainframes and directory systems.

Audience: Legacy system developers, mainframe teams, identity/directory services engineers.

Nature

• Parent-child relationships
• Rigid but fast for predictable queries
• Often XML/JSON aligned

Examples

• Banking: Branch → Account → Transaction.
• Telco: Network → Tower → Subscriber.
• Oil & Gas: Field → Well → ProductionRecord.
• Healthcare: Hospital → Department → Patient.

7. Network Data Modelling

Represent complex many-to-many relationships in a graph-like structure. Network models extend hierarchical by allowing entities to have multiple parent/child relationships. It was popular in CODASYL databases and is similar to graph databases.

Audience: Complex system modellers, graph DB specialists, legacy DB experts.

Nature

• Flexible many-to-many relationships
• Uses pointers/links between records
• Graph-oriented before modern graph DBs

Examples

• Banking: Customer ↔ Account (many-to-many with joint accounts).
• Telco: Subscriber ↔ ServicePackage (multiple services per subscriber).
• Oil & Gas: Equipment ↔ MaintenanceActivities.
• Healthcare: Doctor ↔ Patient (patients treated by multiple doctors).

8. Object-Oriented Data Modelling

Integrate object-oriented programming concepts (classes, inheritance, methods) into data modelling. This model combines data and behaviour. Entities are defined as objects with attributes and methods, mirroring OOP languages. Useful in complex systems requiring encapsulation.

Audience: Application developers, software engineers, data architects working in OOP ecosystems.

Nature

• Class-based (attributes + methods)
• Supports inheritance and polymorphism
• Bridges OOP with persistence

Examples

• Banking: Class “Account” with attributes (balance) and methods (deposit, withdraw).
• Telco: Class “Subscriber” with method “activatePlan.”
• Oil & Gas: Class “Well” with method “calculateDailyOutput.”
• Healthcare: Class “Patient” with method “calculateBMI.”

9. NoSQL Data Modelling

Model data for non-relational databases (document, key-value, columnar, graph) based on access patterns. NoSQL models prioritize scalability and performance. The schema is flexible, often denormalized, and shaped around query needs. Design varies depending on NoSQL type (document, wide-column, key-value, graph).

Audience: Data engineers, architects working with MongoDB, Cassandra, DynamoDB, Neo4j.

Nature

• Schema-less or schema-flexible
• Denormalized, query-driven
• Optimized for distributed systems

Examples

• Banking: MongoDB document for Customer with nested Accounts.
• Telco: Cassandra table storing usage records partitioned by SubscriberID.
• Oil & Gas: DynamoDB table storing sensor readings per WellID.
• Healthcare: DocumentDB storing Patient history as JSON documents.

10. Event-Driven Data Modelling

Model data around events and their payloads in real-time systems. In this approach, the central concept is an event (something that happened). Events include context, payload, and metadata, and can be consumed by multiple systems (event streams, event sourcing).

Audience: Streaming architects, event-driven system designers, data engineers.

Nature

• Event-centric
• Time-stamped, immutable
• Supports streaming, CQRS, event sourcing

Examples

• Banking: Event “TransactionCompleted” with account and amount.
• Telco: Event “CallStarted” with caller, callee, duration.
• Oil & Gas: Event “SensorReadingCaptured” with well, timestamp, pressure.
• Healthcare: Event “LabResultAvailable” with patient, test type, result.