Data Architecture and Data Modeling
Architecture
Enterprise architecture frameworks give structure: Zachman (interrogatives - what, how, where, who, when, why - across perspectives), TOGAF (Architecture Development Method), and FEAF. Data architecture is one domain among enterprise, business, application, and technology architecture.
Data architecture aligns data with business strategy and describes data assets, flows, and standards across the enterprise, not within a single system. Core artifacts: architecture principles and standards, current-state architecture, target-state architecture, gap analysis, and a roadmap.
Data modeling levels
- Conceptual - business entities and relationships, technology-independent, no attributes or keys.
- Logical - attributes, relationships, keys, normalized, still technology-independent.
- Physical - tables, columns, data types, indexes, partitioning, DBMS-specific.
Modeling schemes: relational/3NF; dimensional (star = fact table plus denormalized dimensions; snowflake = dimensions normalized into hierarchies); Data Vault (hubs, links, satellites); UML/object; NoSQL/document.
Normalization: 1NF atomic values; 2NF no partial dependency on part of a composite key; 3NF no transitive dependency. Denormalization is a deliberate performance trade-off, common in BI.
Traps
- Putting attributes, keys, or data types in a conceptual model.
- Skipping the grain declaration for a fact table, or answering a grain question with a dimension.
- Calling a snowflake schema a "normalized star" loosely, or mixing up hubs/links/satellites in Data Vault.
- Assuming architecture means a single-system diagram.
Rule of thumb
State the grain in one sentence before designing anything: "one row per customer per day." If you can say it, the fact table, keys, and dimension joins follow; if you cannot, the design is not ready.