星型模式命名约定

Question

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

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

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

感谢德怀特

Answer 1

表名：

• 我喜欢这个惯例：[type] [subject] [name]
• 其中type为'dim'或'fact'（或聚合的'fact'）
• 其中subject是仓库中的主题区域（'comm'表示常见，'fw'表示防火墙，'id'， 等）
• 其中name理想情况下是单个单词名称，或者是一个单词的缩写 聚合表
• ex：dim_comm_org，用于组织维度
• ex：scan_scan for scan fact table
• ex：facts_scan_org_sev_daily - 分组为的事实扫描摘要表 组织，sev＆amp;日级别

列名：

• 不要以整个表名为前缀 - 这太长了
• 只为其中一个有意义的部分添加前缀 - 这在撰写或阅读查询时非常有用。

仓库与OLTP命名：

• 两者非常不同。仓库桌＆amp;列名通常以元数据，报表结尾，由开发人员和用户读取。与OLTP不同。
• 我认为表格前缀在OLTP中仍然有用 - 但我认为最好是对模型的子集而不是事实/维度区别有意义。

Answer 2

tablename_column名称约定用于确保数据库中的所有字段都是唯一的，尽管它有点过多，可用于存在唯一命名的标准/要求（某些客户IT部门需要。）< / p>

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

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

我更愿意不使用prefex命名表（假设不破坏公司的本地标准），因为虽然它可能是今天的表，但它可以明天重新实现为视图或分区视图但是暴露相同的模式，然后我必须接受前缀不正确的对象或更新每个人对新名称的引用/创建同义词。

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

Answer 3

在DW中，通常使用“长名称”命名列，因为这些列最终会成为报表（查询结果）中的列标题，并且应该是业务用户友好的。因此，不要让Product.Name和Customer.Name显示为“名称”（除非使用别名），通常会使用Product.ProductName和Customer.CustomerName，以便它们显示出来通过联接将星号展平后，将“ProductName”和“CustomerName”作为报表（查询）的第一行中的“ProductName”和“CustomerName”。如果DB允许，经常使用下划线而不是驼峰和空白。当表在模式中的角色可能不明显时，建议在大型DW中使用前缀dim和fact;我其实很喜欢他们。

Answer 4

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