0

我正在重建一个最初使用自然键的大型仓库数据库，现在我想切换到代理键。

因此，我正在考虑将数据库拆分为物理层和逻辑层。

在物理层，每个表基本上都有两个这样的字段：（简化情况）

tbl产品：

ProductKey bigint identity (1,1) not null primary key,
ProductID nvarchar(100) not null unique

tbl销售：

RowKey bigint identity (1,1) not null primary key,
ProductKey bigint not null references tblProducts(ProductKey),
DateSold date,
UnitsSold decimal,
UNIQUE (ProductKey, DateSold)
  • “Key”字段始终是主键，也用于所有外键关系。
  • “ID”字段是唯一的 nvarchar。用户将始终使用“ID”而永远不会看到“密钥”。

在逻辑层，想法是为每个表创建视图，这些视图将“隐藏”代理键并允许我使用 ID。即使是数据库管理员最终也应该只使用视图！例如：

查看大众销售：

select 
    prd.ProductID,
    sls.DateSold,
    sls.UnitsSold
from tblSales sls inner join tblProducts prd on sls.ProductKey = prd.ProductKey

现在，如果我想使用这个视图，我需要创建处理所有更新/删除/插入的触发器并将其“翻译”到物理层。创建所有这些视图需要大量工作。所以：

  • 有没有办法“自动”创建这样的视图？
  • 将数据库拆分为物理层和逻辑层是一种好方法吗？
4

1 回答 1

1

虽然有一种方法可以自动创建 DDL，但我可以根据经验告诉你，这不是你想要的方式。

是的，创建代理键是数据仓库中的最佳实践（我们这样做）。是的，您可以从视图或维度层（我们也这样做）中隐藏代理键，自动创建与基础数据（代理键除外）基本相同的视图会不必要地给您增加复杂性，我相信你最终会后悔的。

爱因斯坦有句名言：“一切都应该尽可能简单，但不能简单。”

最初构建我们的数据仓库的供应商放入了一个创建 DDL 的过程，该 DDL 为每个物理表创建一个视图。出于好意，这些视图几乎没有价值，成为维护问题，并且不必要地使组织良好的 DW 混乱。我们最终删除了所有这些视图。

您仍然可以获得拥有不同逻辑层的好处。我建议使用视图来构建您的维度层。我们只向希望使用 DW 数据的业务用户公开“逻辑”维度层视图。

我强烈建议您研究 ELT 相对于传统 ETL 流程的优势。它彻底改变了我们的 DW 方法，并实现了您可能在逻辑层中寻求的好处。

于 2020-02-12T21:27:12.500 回答