ποΈ 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 π.

β¨ 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) = ''