星型模式命名约定

Posted 2023-03-29

【中文标题】星型模式命名约定

【英文标题】：Star-schema naming conventions

【发布时间】：2009-11-11 16:11:19

【问题描述】：

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

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

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

感谢德怀特

【参考方案1】：

表名：

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

列名：

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

仓库与 OLTP 命名：

两者有很大不同。仓库表和列名通常出现在元数据中，在报告中，由开发人员和用户阅读。 OLTP 并没有那么多。 我认为表前缀在 OLTP 中仍然有用 - 但我认为最好是对模型的该子集有意义而不是事实/维度区分。

【讨论】：

可爱，简洁的答案。

您能否详细说明您个人如何为列添加前缀？

@pimbrouwers - 假设您有表：fact_security_vuln、dim_comm_org 和 dim_comm_asset。如果您在这些表中的任何一个中有一个列“名称”，并在复杂查询（如 CTE）中使用它们，那么跟踪它的来源很快就会成为负担。因此，与其依赖表别名，不如设置列名，例如：'vuln_'、'org_'、'asset_*'。这些前缀需要简短——所以它们可能不是防弹的限定符。

【参考方案2】：

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

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

它消除了名称来源的任何歧义。

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

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

【参考方案3】：

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

【参考方案4】：

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