10

在星型模式中将表名作为维度表或事实表的前缀是常见的做法吗？以表名作为前缀的列名也是常见的做法吗？

在我的普通 OLTP 数据库中，我不这样做，但我在星型模式中看到了这种类型的命名示例。

为数据仓库模式和 OLTP 模式设置不同的命名标准是否有意义？

谢谢德怀特

4

4 回答 4

14

表名：

  • 我喜欢这个约定：[type] [subject] [name]
  • 其中 type 是“dim”或“fact”（或聚合的“facts”）
  • 其中 subject 是仓库内的主题区域（'comm' 为 common，'fw' 为防火墙，'ids' 等）
  • 其中 name 理想情况下是单个单词名称，或者在聚合表的情况下是维度的缩写
  • 例如：组织维度的 dim_comm_org
  • 例如：fact_scan 用于扫描事实表
  • 例如：facts_scan_org_sev_daily - 按组织、严重性和日级别分组的事实扫描汇总表

列名：

  • 不要以整个表名作为前缀 - 这太长了
  • 只用有意义的部分做前缀——这在编写或读取查询时非常有帮助。

仓库与 OLTP 命名：

  • 两者非常不同。仓库表和列名通常出现在元数据中，在报告中，由开发人员和用户阅读。OLTP 并没有那么多。
  • 我认为表前缀在 OLTP 中仍然有用 - 但我认为最好是对模型的该子集有意义而不是事实/维度区别。
于 2009-12-02T05:47:25.400 回答
2

tablename_column 名称约定用于确保数据库中的所有字段都是唯一的，尽管它可以用于当有唯一命名的标准/要求时（一些客户 IT 部门要求）。

Product.Name => Product.Product_Name
Part.Name => Part.Part_Name

它消除了 Name 来自何处的任何歧义。

我根本不喜欢用前缀来命名表（假设这不会违反公司的本地标准），因为虽然它今天可能是一个表，但它可以在明天重新实现为视图或分区视图，但会暴露相同的模式，然后我将不得不接受前缀不正确的对象或更新每个人对新名称的引用/创建同义词。

虽然保持一致性往往是赢家，但如果每个 DBA / Dev 都实现自己的版本，那将是混乱的，所以我倾向于找到公司标准并应用它们。

于 2009-11-11T19:27:33.843 回答
2

在 DW 中，用“长名称”命名列是很常见的，因为这些列最终会作为报告（查询结果）中的列标题，并且应该是业务用户友好的。因此，不是拥有Product.Nameand Customer.Namewhich 都会显示为“Name”（除非使用别名），而是通常使用Product.ProductName，Customer.CustomerName因此一旦星号，它们就会在报告（查询）的第一行显示为“ProductName”和“CustomerName”通过连接展平。如果数据库允许，经常使用下划线代替驼峰式和空格。当表在模式中的作用可能不明显时，建议在大型 DW 中使用前缀 dim 和 fact；我其实很喜欢他们。

于 2009-11-12T03:23:27.950 回答
0

Ken，我喜欢您的 [type] [subject] [name] 约定，其中 type 是“dim”或“fact”（或聚合的“facts”）问题是在 Oracle 商业智能存储库中创建星型模式模型时，最佳实践建议我们应该使用 DIM_（或 dim）为维度和事实表创建别名，并为维度和事实表创建FACT（或 fact_）前缀。为了避免别名维度表和事实表读取 dim_dim[table name] 或 fact_fact_fact_[table_name)，最好使用 _DM（或 _dm）后缀命名维度表，并使用 _FT（或 _ft ） 后缀。

于 2015-07-31T14:09:32.587 回答