Skip to main content

πŸ—‚οΈ Minor Entities

Minor Entities are reference tables used in data transformation and classification (such as customer types πŸ§‘β€πŸ€β€πŸ§‘, status codes 🏷️, or product categories πŸ“¦).
Their accuracy and quality are critical for implementing correct business logic 🧠, classification πŸ“Š, and reporting πŸ“‘.

Minor Entities


✨ Why?​

  • βœ… Ensure supporting tables (like lookups and mappings) are consistent, complete, and unambiguous, allowing facts and transactions to be classified and processed correctly.
  • ⚠️ Errors or gaps here may result in wrong groupings, misclassifications, missed business logic, or reporting errors that are hard to trace.

πŸ“ Where?​

  • πŸ—„οΈ Primarily in the Staging layer (when mapping raw source values)
  • πŸ”„ Sometimes also in Core for advanced transformations or harmonization.

πŸ” Methods​

1. πŸ”‘ Table Uniqueness​

Checks that no duplicate key values exist in the reference table.
πŸ“ Description: Ensures each value in the minor entity table (e.g., each customer type code or status) is unique.
Duplicates can cause mapping conflicts, lead to facts being mapped incorrectly, or result in double-counting in groupings and aggregations.

πŸ’‘ Why is this important? Without uniqueness, facts may be grouped or reported incorrectlyβ€”sometimes without visible errors, just silent data quality issues that undermine trust in reporting.

πŸ–₯ Example:

SELECT code, COUNT(*) 
FROM ref_customer_type
GROUP BY code
HAVING COUNT(*) > 1

2. πŸ“‹ Table Completeness​

Verifies that all required reference values are present (e.g., every customer type exists).
πŸ“ Description: Checks that every business-required value (like each type of customer or all valid status codes) is present in the table, so facts and transactions can always be categorized or mapped.

πŸ’‘ Why is this important? If even one reference value is missing, related records might not be mapped, causing them to disappear from reports πŸ“‰, get defaulted to 'Unknown ❓', or be excluded from key business logic.

πŸ–₯ Example:

SELECT expected.code
FROM (VALUES ('PRIVATE'), ('CORPORATE')) AS expected(code)
LEFT JOIN ref_customer_type rct ON expected.code = rct.code
WHERE rct.code IS NULL

3. βœ… Check​

Any extra validation specific to the table (e.g., non-empty descriptions πŸ–ŠοΈ).
πŸ“ Description: Supports custom business rules, such as ensuring every code has a description or no deprecated values 🚫 are present.
These flexible checks help maintain high data quality in minor entities with unique requirements.

πŸ’‘ Why is this important? Missing or empty descriptions (or other special requirements) can result in poor-quality reports πŸ“Š, failed integration πŸ”— with other systems, or business rule violations.

πŸ–₯ Example:

SELECT * 
FROM ref_status
WHERE description IS NULL
OR TRIM(description) = ''