Conceptual Modeling

The conceptual layer represents the business view of your data - how stakeholders think about and discuss information.

Core Principles

1. Business-First Thinking

Conceptual models focus on what data represents, not how it's stored:

• Use business terminology, not technical jargon
• Model entities as business concepts (Customer, Order, Product)
• Describe relationships in business terms (Customer places Order)

2. Domain-Driven Design

Organize entities into domains (logical groupings):

• Group related business concepts together
• Each domain should have a clear purpose
• Domains align with business units or capabilities

3. Clarity Over Complexity

Keep models understandable:

• Start with core entities only
• Add detail progressively
• Document business logic and rules

Components

Domains

A domain is a logical grouping of related entities representing a business capability or area.

Purpose:

• Organize entities into meaningful categories
• Provide visual separation and color coding
• Align with business structure

Example Domains:

- Platform: Core application entities (Customer, User, Subscription)
- Sales: Revenue-related entities (Order, Payment, Invoice)
- Marketing: Campaign entities (Campaign, Lead, Attribution)
- Product: Product catalog entities (Product, Category, SKU)

MML Syntax:

domain "sales" {
  color = "#3498db"

  entity "order" {
    type = "fact"
    business_logic = "An order represents a customer purchase transaction"
  }
}

Entities

An entity is a business object or concept that needs to be tracked and analyzed.

Entity Types:

1. Entity (Dimension) - Reference/master data

   • Example: Customer, Product, Location
   • Characteristics: Slowly changing, descriptive attributes
   • Business value: "Who/What/Where" context

2. Fact - Transactional/event data

   • Example: Order, Event, Transaction
   • Characteristics: Immutable, time-stamped, measurable
   • Business value: "What happened" records

3. Metric - Calculated KPIs

   • Example: Revenue, Active Users, Conversion Rate
   • Characteristics: Derived, aggregated, time-based
   • Business value: Business performance indicators

4. Derivation - Derived/aggregated tables

   • Example: Customer 360, Product Catalog, Daily Summary
   • Characteristics: Pre-computed, denormalized
   • Business value: Optimized for specific use cases

MML Syntax:

entity "customer" {
  type = "entity"
  business_logic = "A customer is created when a user completes registration"
}

entity "order" {
  type = "fact"
  business_logic = "Orders are immutable records of purchase transactions"
}

entity "revenue" {
  type = "metric"
  business_logic = "Total revenue calculated from completed orders"
}

Relationships

Relationships define how entities connect and depend on each other.

Relationship Types:

1. belongs-to - Hierarchical ownership

   • Example: Order belongs-to Customer
   • Meaning: Each order is owned by one customer
   • Directionality: Many-to-one

2. contains - Composition relationship

   • Example: Order contains LineItem
   • Meaning: Parent entity has child entities
   • Directionality: One-to-many

3. derived-from - Data derivation

   • Example: Revenue derived-from Order
   • Meaning: Calculated from source entity
   • Directionality: Many-to-one (aggregation)

4. leads-to - Process flow

   • Example: Lead leads-to Customer
   • Meaning: Business process transformation
   • Directionality: One-to-one or one-to-many

MML Syntax:

domain "sales" {
  entity "order" {
    type = "fact"
    belongs-to "sales.customer"
  }

  entity "revenue" {
    type = "metric"
    derived-from ["sales.order", "sales.customer"]
  }
}

Best Practices

1. Start with Core Entities

Begin with the most important business concepts:

• What are the key objects your business tracks?
• What entities appear in most business conversations?
• Which entities drive business decisions?

2. Use Clear Naming

• Use singular nouns (Customer, not Customers)
• Use business terms, not technical names (Customer, not user_dim)
• Be consistent across your model

3. Document Business Logic

Use the business_logic attribute to capture:

• How/when entities are created
• Business rules and constraints
• Data quality expectations
• Important context for analysts

4. Group Logically

Organize entities into domains that make sense:

• By business capability (Sales, Marketing, Product)
• By data source (Platform, CRM, Warehouse)
• By ownership (Finance, Operations, Customer Success)

5. Model Relationships Explicitly

Don't assume relationships are obvious:

• Define all important connections
• Use the correct relationship type
• Document the business meaning

Example: E-commerce Platform

# Platform Domain - Core application entities
domain "platform" {
  color = "#3498db"

  entity "customer" {
    type = "entity"
    business_logic = "A customer is created when a user completes registration"
  }

  entity "subscription" {
    type = "entity"
    business_logic = "Active subscription to a service plan"
    belongs-to "platform.customer"
  }
}

# Sales Domain - Revenue and transactions
domain "sales" {
  color = "#2ecc71"

  entity "order" {
    type = "fact"
    business_logic = "Immutable record of a purchase transaction"
    belongs-to "platform.customer"
  }

  entity "revenue" {
    type = "metric"
    business_logic = "Total revenue from completed orders"
    derived-from ["sales.order", "platform.customer"]
  }
}

# Marketing Domain - Campaigns and attribution
domain "marketing" {
  color = "#e74c3c"

  entity "campaign" {
    type = "entity"
    business_logic = "Marketing campaign driving user acquisition"
  }

  entity "attribution" {
    type = "derivation"
    business_logic = "Links customers to their acquisition source"
    derived-from ["platform.customer", "marketing.campaign"]
  }
}

Common Patterns

Customer 360

Create a comprehensive customer view:

domain "customer" {
  entity "customer_360" {
    type = "derivation"
    business_logic = "Complete customer profile with transactions, behavior, and demographics"
    derived-from [
      "platform.customer",
      "sales.order",
      "marketing.attribution",
      "support.ticket"
    ]
  }
}

Product Hierarchy

Model product structures:

domain "product" {
  entity "category" {
    type = "entity"
  }

  entity "product" {
    type = "entity"
    belongs-to "product.category"
  }

  entity "sku" {
    type = "entity"
    business_logic = "Individual product variants"
    belongs-to "product.product"
  }
}

Event Tracking

Model behavioral events:

domain "analytics" {
  entity "event" {
    type = "fact"
    business_logic = "User interaction events"
  }

  entity "session" {
    type = "derivation"
    business_logic = "Aggregated user sessions"
    derived-from "analytics.event"
  }
}

Next Steps

• Logical Modeling - Map conceptual entities to data sources
• Data Product Modeling - Create consumption-ready data products
• MML Reference - Complete syntax documentation