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 回答