视图无法真正解决数据冗余和更新异常，但可为BI、API等提供逻辑3NF接口；错误做法是用LEFT JOIN“假拆分”宽表，正确做法是用DISTINCT+哈希为各实体建独立逻辑维度视图，并在事实视图中直接计算键值。
直接用视图“假装”规范化，解决不了数据冗余和更新异常；但对BI消费、API输出或下游ETL来说，视图能快速提供逻辑上符合3NF的接口，而无需重构物理表结构。
为什么不能在视图里用 JOIN 拼出“假规范化”模型？
常见错误是写一个视图把宽表字段拆成多张逻辑子表，再用 LEFT JOIN 模拟外键关系——比如从 orders_wide 中 SELECT 出 customer_id、customer_name、product_id、product_name，再 JOIN 回自己“去重”。这会导致：
- 重复行爆炸：每条原始订单行都带全量客户/商品信息，JOIN 后仍是笛卡尔积式膨胀，不是真正的实体分离
- NULL 语义混乱：当某字段在宽表中为空，视图无法区分是“暂无值”还是“该实体不存在”
- BI 工具识别失败：Power BI 或 Tableau 会把这种视图当作普通宽表，无法建立正确的维度关系
正确做法：用 UNION ALL + 标识字段构造逻辑维度视图
核心思路是放弃“一张视图模拟多张表”，改为为每个逻辑实体单独建视图，并用固定字段标明来源与粒度。例如，原始宽表 sales_flat 包含 order_id、cust_name、cust_city、prod_sku、prod_category 等混杂字段：
先建客户逻辑视图：
CREATE VIEW dim_customer AS SELECT DISTINCT MD5(cust_name, cust_city) AS customer_key, cust_name AS customer_name, cust_city AS city, 'sales_flat' AS source_system, CURRENT_TIMESTAMP AS loaded_at FROM sales_flat WHERE cust_name IS NOT NULL;
再建商品逻辑视图：
CREATE VIEW dim_product AS SELECT DISTINCT MD5(prod_sku) AS product_key, prod_sku, prod_category, 'sales_flat' AS source_system, CURRENT_TIMESTAMP AS loaded_at FROM sales_flat WHERE prod_sku IS NOT NULL;
关键点：
- 必须用
DISTINCT+ 确定性哈希（如MD5()）生成稳定主键，避免后续变更导致键漂移 - 显式添加
source_system和loaded_at字段，让下游知道这是派生逻辑表，非真实源系统 - WHERE 过滤掉空值，防止 NULL 参与哈希或污染维度唯一性
明细事实视图如何关联这些逻辑维度？
不要在事实视图里写 JOIN dim_customer ON ... —— 那会让视图依赖外部对象，破坏可移植性。应直接在宽表中反查并映射：
CREATE VIEW fact_sales AS SELECT order_id, MD5(cust_name, cust_city) AS customer_key, MD5(prod_sku) AS product_key, sale_amount, order_date, 'sales_flat' AS source_system FROM sales_flat WHERE cust_name IS NOT NULL AND prod_sku IS NOT NULL;
这样做的好处：
- 所有逻辑都在单条 SQL 内完成，不依赖其他视图或函数（除非数据库支持内联标量函数）
- BI 工具导入时，
customer_key和product_key被识别为字符串型维度字段，可直接拖拽建模 - 若未来物理表结构变化（如新增
cust_region），只需扩展dim_customer视图，fact_sales不受影响
字段类型与 NULL 处理最容易被忽略的细节
宽表里常有混合类型字段（如 status 是 TINYINT 但实际存 0/1/NULL），直接暴露给 BI 会引发筛选失效：
- 数值型 ID 字段（如
cust_id）若原为DECIMAL(18,0)，BI 可能自动归为“度量”，需在视图中写成CAST(cust_id AS CHAR) - 布尔类字段必须显式转义：
CASE WHEN is_active = 1 THEN 'Y' ELSE 'N' END AS is_active_flag，不能留TINYINT(1) - 所有用于 JOIN 的逻辑键字段（如
customer_key）必须定义为NOT NULL，否则 Power BI 会跳过关系自动检测
真正难的不是写出这些视图，而是让团队接受：它们只是过渡层，不是替代规范化设计的方案。一旦业务稳定、读写比例转向分析侧，就得把逻辑视图沉淀为物理维度表——否则每次查询都在重复计算哈希、去重和类型转换。
