type
status
date
slug
summary
tags
category
icon
password
1 范围
略
2 引用文件
暂无
3 术语和定义
3.1概念数据模型
概念数据模型是通过业务对象及业务对象之间的关系，从宏观角度分析和设计的集团核心数据结构。
3.2逻辑数据模型
逻辑数据模型是利用逻辑数据实体及相互之间的关系，准确描述业务规则的逻辑实体关系图。
3.3物理数据模型
物理数据模型是按照一定规则和方法，将逻辑数据模型中所定义的逻辑数据实体、属性、属性约束、关系等内容，如实转换为数据库软件所能识别的物理数据模型关系图。
3.4实体
实体(Entity)是客观存在并可相互区别的事物或概念，一般是指描述某一特征的属性或字段的数据集合，逻辑数据模型中的实体称作逻辑数据实体，物理数据模型中的实体称为物理数据模型（表）。
3.5关系
关系(Relationship)是指业务对象、逻辑数据实体、物理数据模型(表)之间的关系，即描述业务对象、逻辑数据实体、物理数据模型是以何种形态关联在一起，或者描述一个业务对象、逻辑数据实体、物理数据模型本身的行为会对另外一个业务对象、逻辑数据实体、物理数据模型(表)产生何种影响。
3.6标识符
标识符(Identifier)是逻辑数据模型的逻辑数据实体中能唯一识别每一条实例的一个或一组属性。
3.7主键
主键(Primary Key)是指在物理数据模型的物理数据模型(表)中,唯一标识一条记录的一个或一组字段。
3.8外键
外键(Foreign Key)是一个或一组包含某种依赖性约束的属性或字段，用于实现两个逻辑数据实体或两个物理数据模型(表)之间的连接
3.9垂直拆分
垂直拆分也称为纵向拆分，是指将一个数据库表的列（字段）进行拆分，依据字段的使用频率和关联性，将表中不同的列分离到多个表中。这种方法有助于优化查询性能，减少不必要的磁盘I/O操作。例如，将一个包含大量字段的用户表拆分为两个表：一个存储常用字段（如用户ID、姓名、邮箱等），另一个存储不常用或大字段（如用户简介、头像等）。
3.10水平拆分
水平拆分也称为横向拆分，是指将一个数据库表的行（记录）进行拆分，按照某种规则（如ID范围、哈希值等）将数据分布到多个相同结构的表或数据库中。这种方法适用于单表数据量过大，导致查询和写入性能下降的情况。例如，将一个订单表按订单创建时间拆分为多个表，每个表存储特定时间段的订单数据。
3.11业务主键
业务主键(Natural key)是现实世界中已经存在的、能唯一识别每一条记录的一个或一组具有业务含义的字段。
3.12代理键
代理键(Surrogate key)是用来代替业务主键的、不具备业务含义的、能够唯一识别一条记录的字段。
3.13范式建模
范式建模是一种数据库设计方法，旨在通过减少数据冗余和提高数据完整性来优化关系数据库的结构。基于一系列规范化规则（范式），将数据分解为多个关联的表，每个表都专注于一个特定的实体或关系。范式建模用于SDI层和DWI层。
3.14维度建模
维度建模是一种用于数据仓库设计的建模方法，旨在优化数据的查询性能和分析能力。维度模型由事实表和维度表组成，事实表存储业务事实、度量值和维度外键信息，维度表存储描述性属性与场景信息。维度建模用于DWR层和DM层。
3.15星型模型
星型模型中维度表围绕事实表呈放射状排列，维度表之间无关联关系。星型模型通过增加冗余减少关联次数，性能更优，当多个事实表共享同一个维度表时，这种扩展的星型模型被称为星座模型。星座模型适用于复杂的业务场景，能够支持多主题的数据分析需求，为业务决策提供更全面的数据支持。
3.16雪花模型
雪花模型在星型模型的基础上，将维度表进一步规范化，分解为多个关联的子表，形成层次化结构。雪花模型通过规范化设计避免重复数据，节省存储，降低更新异常风险。
3.17DWS
DWS是基于基础架构和平台的在线数据分析处理数据库，提供即开即用、可扩展且完全托管的分析型数据库服务。
4 模型设计原则
（一）整合性。为确保数据模型的集成性和一致性，应对性质相似的内容进行合并整合，特别是在主数据和关键基础数据方面，从集团层面进行综合管理。
（二）分层解耦。参考现有的数据分类框架和应用系统架构，对数据模型进行分层设计。遵循高内聚、低耦合的设计原则，确保业务分类与业务流程、业务流程与业务结果之间的解耦。
（三）可扩展性。在设计数据模型时，应预见未来的业务变化，进行灵活的可扩展性设计，确保在业务变化时数据库层面无需修改或仅需最小化修改，保持数据模型的整体性和一致性。
（四）继承性。设计过程中必须遵循已有的数据架构和规范。新数据模型的设计应参考现有产品（包括自研系统和软件包），寻找可借鉴或可重用的内容。
（五）易读易用。数据模型设计应保持清晰的业务逻辑，易于阅读和理解，且在应用程序中易于实现。
（六）按需选用建模方法。根据业务需求和应用场景，灵活选择适当的建模方法。对于需要高效数据分析和快速响应的场景，维度建模可能更为适用；而在需要提升规范化数据管理能力的场景下，范式建模则更为合适。
5 概念数据模型设计规范
5.1概念模型设计方法
依据业务的价值链、流程等相关输入信息识别出业务对象，按照业务的流转和数据之间的相关性对各业务对象进行连接。在概念数据模型设计中根据具体业务场景的需求可使用子类或关键逻辑数据实体。
（一）业务对象识别。业务对象识别过程中，应基于业务场景深入分析业务流程，识别其中的每个业务活动。随后，初步确定候选业务对象。接着依据业务对象的识别原则，对这些候选对象进行评估和筛选，整合优化相同或相似的业务对象。通过不断的提炼和抽象，最终确定明确的业务对象。
原则 | 说明 |
业务对象指集团运作和管理中不可缺少的重要的人、事、物信息 | 1.可以基于商业设计、价值流识别业务对象，并和业务能力匹配。
2.针对业务对象，通常会建立相应的流程、组织、IT进行管理。
3.业务对象的责任人明确且边界清晰。 |
业务对象有唯一身份标识信息 | 业务对象必须有身份标识信息，通过身份标识能够区分业务对象。 |
业务对象相对独立并有属性描述 | 1.业务对象有描述自己某方面特征的属性。
2.业务对象可独立存在，可供获取、传输、使用，并发挥价值，可以与其他业务对象关联，但不是从属关系；而逻辑数据实体依赖于业务对象。
3.即便随时间推移状态发生变化，业务对象也不会发生本质变化(至少身份标识不变)。
4.有生命周期，有状态变化。
5.事务数据类业务对象可以根据管理责任主体差异进行拆分，主数据、基础数据和报告数据原则上不允许拆分。 |
业务对象可实例化 | 1.业务对象有具体实例存在，通常需要明确数据责任人、定义架构、标准、度量监控，才能有效管理。
2.基础数据、报告数据一般不视为业务对象。 |
（二）连接业务对象间关系。根据业务对象间的关联性用关系线进行连接，并根据业务的流转从上到下、从左到右进行布局。概念数据模型中可以只表示业务对象间的重要关系。
5.2概念数据模型设计规范
（一）业务对象定义：概念数据模型中，应包括业务对象的名称、含义，以及业务对象之间的相互关系，确保所有参与者对业务对象的理解一致。
（二）概念数据模型中业务对象之间可以使用一对一、一对多、多对多的关系表示，确保关系的准确表达。
（三）在引入超类和子类时，超类应抽象出一组实体的共性特征，避免包含过于具体的属性，以确保其适用于所有子类。同时，超类的定义应相对稳定，不因个别子类的变化而频繁修改，确保模型的可维护性。超类的命名应准确反映其涵盖的实体范围，避免模糊或过于宽泛的名称。子类的定义应涵盖超类的所有可能实例，确保分类的完整性，避免遗漏。此外，子类应遵循超类的约定，确保继承关系的一致性，避免属性或行为的冲突。
（四）定义子类时，应明确子类之间的关系是互斥（Exclusive）还是重叠（Inclusive）。一般情况下，子类大多是互斥的。此外，子类的命名应具体明确，避免使用“其他”等含义模糊的词语，确保模型的清晰性和可读性。
6 逻辑数据模型设计规范
逻辑数据模型与概念数据模型的主要区别在于：概念数据模型侧重于描述业务对象及其相互关系，而逻辑数据模型则在此基础上，进一步详细定义所有逻辑数据实体的属性、主键和外键等细节。
逻辑数据模型的设计应以数据为中心，深入理解业务需求，确保模型具备强大的可扩展性、高度一致性和强共享性。
6.1关系建模
6.1.1范式模型设计方法
（一）逐层设计E-R-A。先设计逻辑数据实体(E,Entity)以及标识符，再识别实体间关系(R,Relationship)，最后完成实体上的属性(A,Attribute)定义。
（二）先主后支。先识别业务主干上的逻辑数据实体及关系，如主数据、事务数据等，然后识别支干上的逻辑数据实体及关系，如基础数据等，最后完成实体、属性定义。
（三）先分再合。先识别完整的业务场景和关键业务活动，分别设计逻辑数据实体，再根据数据模型的设计原则权衡业务、数据和IT之间的相互影响，最终确定是否要对逻辑数据实体(或关系)进行整合。
6.1.2实体设计规范
（一）业务关联性
1．业务用途的逻辑数据实体不能脱离业务对象独立存在。
2．一个逻辑数据实体不能归属于多个业务对象，业务对象与逻辑数据实体的关系是一对一或一对多，不允许多对一归属关系。
（二）规范化设计
1．范式建模逻辑数据模型设计应遵循第三范式（3NF）以保证数据的完整性和最小化冗余。
2．在产品落地时，若因非功能性需求对逻辑数据实体进行拆分或整合，必须同步调整逻辑数据模型以保持与物理表的一致性。
（三）逻辑实体类型及设计原则
1．跨业务领域使用的基础数据，要单独设计逻辑数据实体。
2．记录两个业务对象间的关系逻辑数据实体，归属于业务发生时间中后出现的业务对象。
3．业务中需要管理的更改历史信息，可以设计为逻辑数据实体。
4．描述业务对象不同业务特征的属性集合，可以拆分为独立的逻辑数据实体。
5．逻辑数据实体中，在某特定场景下使用的属性，可以垂直(纵向)拆分成另一个逻辑数据实体。
6．逻辑数据实体设计时不考虑水平(横向)拆分，水平拆分在物理表设计中考虑。
7．企业信息系统中已有的软件包或外部系统通常已定义物理表结构，且可能未严格遵循企业的逻辑数据模型规范。为确保逻辑数据模型的完整性，并与软件包的物理结构保持一致，须基于软件包的物理表进行逆向建模，构建相应的逻辑数据实体，以并规范数据管理。
（四）命名规范
逻辑数据实体使用“主题词+后缀”的形式命名，后缀用于区分实体的不同用途，不以“表”为后缀结尾。例如：客户信用评级(主题词)+信息(后缀)。逻辑数据实体常用后缀：
分类 | 常用后缀 |
业务结果 | 头、行、基本信息、详细信息、明细、扩展、关系 |
业务过程 | 流水、变更信息、审批信息 |
业务规则 | 配置、参数、分类 |
业务归档 | 历史 |
6.1.3关系设计规范
（一）关系类型
1．创建逻辑数据实体时，必须以一对一或一对多的形式定义逻辑数据实体关系，禁止直接建立多对多关系。
2．对于业务场景中不可避免的多对多关系，应通过独立的关系实体（桥接表）进行拆解，以确保数据结构规范且具备良好的扩展性。当关系数量固定且明确时，也可采用在主表中增加固定数量的外键字段，将其转换为多个一对多关系，从而简化查询和管理。
（二）层级关系
1．若某个逻辑数据实体常常需要访问其上级实体的属性，而不需要中间层级的属性，则可将上级实体（如父级、祖父级等）的主键直接继承到当前实体中。以够简化结构，减少冗余数据存储。
2．对于表示层级或树形结构的数据，推荐使用递归关系来表示。每个数据实体应通过外键引用自身，从而建立父子关系，便于层级管理与数据查询。
（三）时间关系
逻辑数据实体之间的关系应清晰地反映事件的先后顺序。在设计时，要考虑业务流程的时间顺序，确保数据实体之间的依赖关系符合实际业务执行的逻辑一致，对于增加的逻辑字段，需要同步增加数据资产。
6.1.4属性设计规范
（一）一致性
1．含义相同的属性，应在不同实体中保持一致的名称、定义、类型、长度、取值范围等。
2．属性的数据类型和长度(或精度)，需要遵照业务规则，并适当考虑业务发展需求。不允许将数值类型设计为字符类型。存储文本属性时，应使用可变长度的字符类型，并设计合理充足的长度。
3．属性要明确定义属性名称，并根据需要填写属性说明。
（二）标识符
1．每个逻辑数据实体都必须设计唯一标识符，标识符可以使用具有业务含义的属性（通常称为业务主键），也可以使用没有实际业务含义的替代属性（如序列号）。
2．如果标识符由多个属性组成，并且该标识符被多个逻辑数据实体引用，可以通过简单拼接或哈希等方式，将多个属性生成一个替代属性（即代理键），作为统一的标识符。
（三）继承和引用
1．引用其它逻辑数据实体的属性，若属性值在本逻辑数据实体中可以更改，必须作为本逻辑数据实体的属性。
2．引用其它逻辑数据实体的属性，若属性值取自引用数值且后续不变更，必须作为本逻辑数据实体的属性。
3．引用其他外部机构系统生成的属性时，应该把该属性值回写到描述该业务对象的属性中，避免每次查询时实时调用外部API。
（四）命名规范
1．属性命名时使用“主题词+后缀”的形式命名，后缀用于识别属性的用途。例如：员工(主题词)+编号(后缀)。常用的后缀名如下：
大类 | 小类 | 常用后缀 |
编号类 | 编号 | 编号、号、号码、卡号、ID、编码、… |
代码类 | 代码 | 代码(例如：类型代码、方式代码、等级代码、性别代码…) |
内容类 | 金额 | 价格、金额、单价、余额、总价… |
内容类 | 日期 | 年度、年月、月份、月日、日期、时间… |
内容类 | 内容 | 概要、内容、描述、摘要、结果、目录、备注、注释、清单… |
内容类 | 顺序 | 序号 |
内容类 | 名称 | 姓名、名称、别名、缩写、地址、地点、路径、… |
内容类 | 数量 | 数、次数、数量、值、月数、件数、长度、宽度、高度、精度、角度… |
内容类 | 率 | 率、比率、比重、税率、汇率… |
内容类 | 标志 | 标志 |
2．逻辑数据模型要明确定义逻辑数据实体的名称和含义，并设计如下用户自定义属性(UDP，User Defined Property)：
UDP名称 | UDP值类型 | UDP列表可选值 | UDP定义 |
用途分类 | List | 业务用途,IT用途 | *业务用途*：业务结果表,业务过程表,业务规则表,业务报告明细表,业务报告汇总表,业务归档表；*IT用途*：接口表,日志表,备份表,临时表,IT配置表,冗余表，IT归档表 |
子用途分类 | Text | 业务用途,IT用途 | *业务用途*：业务结果表,业务过程表,业务规则表,业务报告明细表,业务报告汇总表,业务归档表；*IT用途*：接口表,日志表,备份表,临时表,IT配置表,冗余表，IT归档表 |
数据分类 | List | 事务数据,基础数据,报告数据,主数据,观测数据,规则数据 | *事务数据*：用于描述和记录各种业务活动的详细信息。
*基础数据*：研究、分析、决策或运营活动最依赖的最基本的数据。
*报告数据*：在报告中出现的各种数字、图表、统计数据等信息。
*主数据*：用来定义业务对象的、具有持续性、非交易类的数据。
*观测数据*：通过直接观察或测量获得的原始数据。
*规则数据*：定义与数据关联的特定测试、验证或约束的逻辑规则。 |
6.1.5范式建模应用
（一）SDI层无需单独设计逻辑模型，直接采用源系统的关系建模，在源模型结构基础上扩展记录来源、创建时间戳、创建更新时间戳、逻辑删除标记等字段。
（二）DWI层采用E-R关系建模，在现有模型无法满足需求或存在设计缺陷、性能问题时，需重新建模。在设计过程中，应明确E-R关系，确保数据结构的合理性和关联性。如果现有模型设计合理、符合业务需求且性能良好，则以优化或扩展为主，无需重建。
6.2维度建模
6.2.1维度模型设计方法
（一）逐层设计F-D-A。先设计事实表(F,Fact)，确定业务过程，度量值，数据粒度，并定义数据的主键。再设计维度表(D,Dimension)，识别核心维度，最后完成属性定义（A,Attribute），补充维度表的业务描述属性，并优化字段类型，以提升查询效率。
（二）先主后支：先定义核心事实表与关键分析维度，确保核心事实度量数据和关键分析维度能支持主要业务分析需求，后识别衍生事实表和辅助分析维度，以提供更丰富更高效的分析能力。
（三）先分再合：先拆分业务场景，识别不同分析主题，确保每个事实表的粒度清晰。再根据提升分析和存储效率的需求对数据模型进行整合，判断是否进行事实表合并、维度表结构优化等。
6.2.2事实表设计规范
（一）事实表设计原则
1．单一性：每个事实表只能描述一个业务过程，不得混合存储不同业务过程的事实数据，以确保数据的独立性和清晰性。例如，投标事实表应仅记录投标过程中的核心度量值，如投标金额、投标轮次，不得包含其他无关的业务数据，以防止数据混淆和查询复杂度增加。
2．原子性：应存储最细粒度的数据，不得对数据进行预先聚合或汇总，以确保数据的灵活性和查询的精确性。例如，投标事实表的每条记录必须对应一次具体的投标行为，而不得按天、按月或其他聚合级别存储，以防止数据粒度不一致影响分析的准确性。
3．可加性：所有可加度量值（如投标金额、交易金额、投标企业数量）应支持跨时间、跨维度的汇总分析，不得存储不可加度量值（如中标率、平均值）作为事实表的主要度量项，如确需保存指标，规范存储方式是将比率进行分子分母拆分、仅保存原始值在后续分层计算或只存储在特定业务场景下不需要做汇总的比率指标（如周期快照表事实表按天保存投诉率）。
4．一致性：所有关联的外键必须与维度表中的主键严格匹配，确保数据的完整性和可追溯性。例如，投标事实表中的投标企业ID必须与投标企业维度表中的企业ID保持一致，禁止出现未匹配的孤立数据，以防止数据关联错误影响业务分析的准确性。
（二）事实表类型
事实表有三种类型：事务事实表、周期快照事实表和累积快照事实表。
1．事务事实表必须用于描述业务过程，每条记录应严格对应一次具体的业务事务，确保数据的最小粒度，避免因数据合并或拆分导致事务一致性问题。事务事实表的数据应仅支持新增，不允许覆盖或删除，以保证数据的可追溯性，并且查询时应严格通过维度表关联获取详细业务信息，以保持数据的标准化和一致性。
2．周期快照事实表必须按照固定的时间间隔（如每天、每月、每年）进行数据记录，确保数据的时间序列稳定性和可预测性。该表应仅用于记录特定时间点的业务状态，避免对历史数据进行修改，以保障数据的完整性和趋势分析的准确性。时间维度必须作为该表的关键维度，以支持基于时间的趋势分析和预测建模。
3．累积快照事实表用来表述过程，开始和结束之间的关键步骤事件，覆盖过程的整个生命周期，通常具有多个日期字段来记录关键时间点，当过程随着生命周期不断变化时，记录也会随着过程的变化而被修改，适用于记录业务过程的全生命周期。
（三）单一事实与多个事实的选择
1．事实表中的多个事实必须具备相同的粒度和维度，确保每条记录代表相同层级的业务事件，避免因粒度不一致导致数据聚合和分析的复杂性。
2．多个事实必须具有业务相似性，仅限于相同业务过程或紧密相关的业务环节，避免将不同业务过程的数据混合存储，以防影响数据模型的清晰性和分析的准确性
3．事实表的构建应确保业务含义清晰，避免存储多个不相关的事实，以确保数据易于理解和使用，减少下游应用在数据查询、分析和报表生成时的混淆。
4．应综合考虑数据存储和计算成本，在满足业务需求的前提下，评估多个事实合并存储的实现难度，以及是否能够有效降低存储成本、计算复杂度和查询性能开销。
6.2.3维度表设计规范
（一）维度表设计原则
1．单一性原则强调每个维度只描述单一主题，每个事实表只表示单一的业务过程。这种设计能够避免数据混淆，提高模型的可理解性和可维护性。
以投标企业维度为例，其描述主题为投标企业的基本信息。维度字段有：企业ID（唯一标识）、企业名称、企业资质等级、注册资本、所属行业、成立日期。用于分析参与招投标的企业资质分布、中标成功率等。投标企业维度的单一性体现在该维度仅描述企业属性，与投标过程、项目属性等分离，确保职责单一。
2．单向性原则强调在维度模型中，数据的聚合与分析方向应保持一致，从细粒度数据汇总到高层级分析，避免双向依赖。
以时间维度为例，时间维度的层次关系为日期、月份、季度、年份。其单向性体现在数据查询始终从细粒度日期向上汇总到月、季度或年级别，避免从年级别回溯到细节数据，确保分析方向一致。
3．正交性原则强调不同维度之间相互独立，无重复或重叠的属性，每个维度可以自由组合进行分析。
以投标企业维度和地域维度为例，投标企业维度包含企业的行业分类、资质等级等信息；地域维度包含企业注册地、省份等信息。其正交性体现在两个维度相互独立，可在分析中自由组合。
（二）维度表设计规范
维度表是用于观察、分析和筛选业务数据的视角，支撑数据汇聚、钻取、切片分析，并提供业务上下文信息。维度数据可来源于基础数据、主数据、交易数据等，其设计规范需要确保数据的一致性、查询效率、可扩展性。
1．维度管理与治理
(1)每个维度必须设定专门的责任人，负责维度数据的业务定义、数据质量管理、数据更新机制，确保维度数据的准确性和一致性。
(2)维度数据需具备标准化定义，包括维度名称、维度主键、层级结构、数据来源，并在数据字典中进行统一维护，避免不同业务系统间维度定义不一致。
(3)维度表的数据必须定期更新和维护，采用数据血缘分析和数据质量监控，避免数据陈旧、字段缺失或错误导致分析偏差。
2．维度数据的存储和整合
(1)各类维度数据在DWI（整合层）进行数据整合后，在DWR（报告层）形成标准化维度表，以确保跨业务分析时维度的一致性。
(2)DWR层的维度表应整合所有与维度相关的码表，形成唯一的维值表（LookupTable），避免数据冗余和查询性能下降。
(3)维度数据应遵循主数据管理（MDM）原则，确保跨业务域、跨系统的维度值标准化，并采用维度版本管理机制，防止因数据变化导致历史数据失真。
3．维度表结构优化
(1)维度表应遵循扁平化设计，避免过度分层，以提高数据查询效率，减少数据库JOIN操作的计算开销。
(2)维度表的层级展开策略：维度表应预先展开各层级关系，避免查询时的递归关联计算。在层级展开赋值时，若低层级数据为空，应采用上一层级的数据补充，以确保数据完整性。例如，在组织架构维度中，若缺失部门信息，可用其上级部门信息填充。
4．维度表主键与外键管理
(1)每个维度表必须有唯一主键（PK），用于唯一标识该维度的每条记录，防止数据重复或错误关联。
(2)维度表的外键（FK）需与事实表严格关联，确保数据查询的一致性和完整性，事实表的维度外键（FK）必须能在对应的维度表中找到匹配的主键（PK）。
5．维度表的扩展性
(1)宽表设计，即尽可能在一个维度表中存储完整信息，减少与其他表的关联查询。
(2)根据具体业务、性能、扩展性、存储成本需求合理选择星型模型与雪花模型进行维度建模。
6．维度表的变更管理
(1)维度表变更需遵循版本管理机制，当维度字段结构发生变化时，必须进行影响分析。
(2)变更字段时应采用新增字段的方式（避免直接修改或删除原字段），确保历史数据兼容。
(3)维度字段变更后采用维度变更记录表，存储维度值的历史变更，以支持回溯分析。
6.2.4属性设计规范
事实表由粒度属性、维度属性、事务描述属性、度量属性组成。
（一）粒度属性
粒度属性是描述描述事实表数据粒度的属性，即每一条记录的最小业务单元，粒度越细，数据存储量越大，但查询灵活性更高。
（二）粒度属性规范
1．事务事实表：通常是最细粒度，例如单个订单、单笔交易。
2．周期快照事实表：通常是固定时间间隔的聚合数据，如每日销售额、月度审批总数。
3．累积快照事实表：通常是业务过程的唯一标识符，如投标项目ID、审批流程ID。
（三）维度属性
维度属性是从维度中继承的属性，用于描述事实数据的业务背景。维度属性是事实表与维度表的连接点，通常采用外键关联。维度可以提供分组、过滤、钻取等分析功能。
（四）维度属性规范
1．维度属性通常来自时间维度、地区维度、组织维度、业务维度等。
2．维度属性在事实表中存储外键（FK），关联到维度表的主键（PK）。
（五）度量属性
度量属性是可以对该粒度的事实进行定量属性，存储业务过程中的度量值，用于数值计算和分析，可加性、半可加性、不可加性。
（六）度量属性规范
1．可加度量：可用于总和、均值、最大/最小值计算（如订单金额、交易笔数）。
2．半可加度量：在部分维度可加（如账户余额，只能按时间维度查询，不可跨账户求和）。
3．不可加度量：只能用于计算比率、百分比（如中标率、投诉解决率）。
（七）事务描述属性
事务描述属性是除粒度属性、维度属性、度量属性以外对该事实表补充说明的属性，用于详细描述业务过程，常用于数据追踪、查询解释和业务审计。
（八）事务描述属性规范
事务描述属性通常是字符串或枚举类型，不会影响数值计算性能。
6.2.5维度建模应用
（一）报告层主要采用星型模型设计事实表与维度表，事实表直接关联对应维度。维度表需明确定义主键、业务属性及描述字段，并基于业务需求扩展属性，减少跨表关联查询，针对复杂层级维度或存储空间优先的场景下，可使用雪花模型进行报告层设计。
（二）集市层面向主题和业务分析进行建模，主要采用星型模型设计事实表与维度表，事实表直接关联对应维度。维度表需明确定义主键、业务属性及描述字段，并基于业务需求扩展属性，减少跨表关联查询，针对复杂层级维度或存储空间优先的场景下，可使用雪花模型进行报告层设计。
7 物理数据模型设计规范（以DWS为例）
物理数据模型与逻辑数据模型的主要区别在于，逻辑数据模型主要用来详细描述业务规则，而物理数据模型是将逻辑数据模型如实转换为数据库所能识别的物理结构。在物理数据模型设计时，建模人员或数据库设计人员需将逻辑数据模型按照关系型数据库的结构和特征，转换为关系型数据库所能支持的物理形式。
7.1物理模型设计方法
（一）创建数据库、模式等数据对象
集团数据中台在数据库建设过程中，应规范创建数据库、模式（Schema）及其他数据对象，确保数据组织结构清晰、权限管理合理、访问控制规范化。数据库命名应符合业务逻辑和数据分层管理要求，模式应按数据层次（如 SDI、DWI、DWR、DM 等）划分，保证数据隔离性和可维护性。
（二）确定表命名
集团数据中台应制定统一表命名规则，确保表名清晰、可读、易维护、便于管理和查询。
（三）确定字段属性类型
依据逻辑模型，结合湖仓一体化底座技术选型，严格遵循数据类型选取规范，确保字段类型与业务需求匹配，兼顾存储优化和计算性能。同时，避免不必要的高精度数据类型，合理控制字段长度，减少存储开销，提高查询效率。
（四）确定表存储结构
根据业务应用场景，遵循存储结构设计规范，合理选择行存、列存或混合存储模式，确保查询和存储效率最优。
（五）确定表属性配置
严格按照数据分区、存储模式、索引和压缩策略规范，依据数据量级和查询特性制定最优方案。合理设置分区策略，避免数据倾斜，提高查询效率；选择适合的存储模式，兼顾读取和写入性能；优化索引设计，防止冗余索引影响性能；配置合适的压缩方式，在节省存储的同时确保查询效率。
7.2数据库创建规范
（一）禁止直接使用系统内置数据库（如postgres、gaussdb等）进行业务开发。集团数据中台应统一使用xxggzy_dg 作为开发数据库。
（二）创建DATABASE时必须选择正确的数据库编码，建议建库时指定ENCODING为UTF-8编码。
（三）存在关联计算的对象创建在同一个DATABASE中，跨库访问无论使用哪种方案，性能均劣于同一DATABASE内的关联操作。
（四）一个集群内，用户自定义的DATABASE数量建议不超过3个。
7.3模式创建规范
（一）禁止在其他USER的私有模式SCHEMA下创建对象，如新增用户dataarts_link，会自动创建一个名为dataarts_link的私有模式SCHEMA，其他用户在这个私有SCHEMA下创建对象，对象权限不受创建者控制。
（二）模式应参照湖仓分仓规范中规定的SDI、DWI、DWR、DM进行划分。
（三）模式temp 、test、public为公共模式，存储历史表、测试表。
7.4表命名规范
7.4.1表命名通用规范
（一）所有数据库、表、字段命名采用26个英文小写字母和0－9这十个自然数，加上下划线_组成。不能出现大写字母以及其他字符（注释除外）。
（二）对象名尽量短，长度不能超过50个字符，采用简写或缩写，缩写要基本能表达原单词的意义。
（三）实际名字尽量描述实体的内容，由英文单词、单词组合或单词缩写组成，不能以数字和_开头。
（四）命名中禁止使用SQL关键字。
（五）除去前缀后缀，不建议超过三个单词。
（六）必须要有适当的表扩展属性以及注释comment。
（七）命名应该使用英文单词优先，英文单词使用对象本身意义相对或相近的单词。选择最简单或最通用的单词。不能使用毫不相干的单词来命名。
（八）当出现对象名重名时，加后缀以示区别。
（九）命名的各单词之间可以使用下划线进行分隔。
7.4.2贴源层SDI表命名
贴源层表命名需包含源系统的来源数据库及表名简写，并标识是否分区，确保命名规范统一、清晰可读。具体命名规范如下，需全程使用小写，以保持一致性和规范性。
sdi_{业务板块}{源系统简写}{源系统表名}_{p（是否分区）}
7.4.3整合层DWI表命名
整合层表命名应遵循统一的小写格式，命名规范如下：dwi_{mdm(是否主数据)}业务板块_{表名}{c(是否拉链)}/{p(是否分区)}。若涉及多个业务板块，需拼接全部简称以确保唯一性和可识别性。
dwi{mdm是否主数据}业务板块{表名}{c(是否拉链)}/{p(是否分区)}
字母对应的全称：mdm-master data management;c-chain；p-partition;
7.4.4报告层DWR表命名
在报告层，表按照功能划分为维度表和事实表，其中事实表根据数据粒度进一步细分为明细表和汇聚表。报告层表的命名应遵循统一的小写格式，具体命名规范如下：
维度表：dwr.dim{维度名}
报告明细表：dwr.fact_{表名}{p(是否分区)}
报告汇聚表：dwr.agg{表名}{聚合维度}{p(是否分区)}
7.4.5集市层DM表命名
在集市层，表按照数据类型划分为指标表和汇总表。指标表用于存储所有指标的明细数据，支持细粒度分析；汇总表用于存储特定指标的聚合数据，提升查询效率，满足统计分析需求。集市层表的命名应遵循统一的小写格式，具体命名规范如下：
集市指标表：dm.dmi_{业务板块}{业务主题}{表名}{聚合维度}
集市汇总表：dm.dms{业务板块}{业务主题}{表名}_{聚合维度}
7.4.6特殊情况表命名
（一）备份表命名规范
备份表的主要作用是在数据库变更、调试或特殊操作时，保留原始数据，确保数据的可回溯性和安全性，以便在变更失败或需要回滚时，能够迅速恢复。备份表命名为：原表名_ backup_{备份日期} ，其中备份日期的数据格式为“YYYYMMDD”。
（二）临时表命名规范
临时表适用于短期数据存储与计算，不涉及长期存储或数据血缘追溯的场景。临时表应统一存放于 temp 模式（schema），命名规范为 temp.{表名}_tmp。代码中必须显式包含创建 -> 使用 -> 删除的完整 SQL 语法逻辑，确保 temp模式下的临时表在任务执行过程中始终可用。
（三）待删除表命名规范
表删除前必须先重命名为 {表名}to_be_dropped{标记日期}，其中标记日期格式为“YYYYMMDD”，以确保可追溯性和规避误删风险。重命名后的表应保留并监控一段时间，确认无业务依赖且无异常后，方可执行正式删除，期间应禁止写入与调用，确保数据清理的安全性和可控性。
7.5表字段规范
7.5.1字段命名规范
（一）字段名称必须由字母开头，由字母、数字、下划线组成。
（二）采用有特征含义的单词或缩写，禁止使用数据库系统的保留字作为字段名。
（三）字段命名统一小写，且建表语句中不建议使用双引号包括字段名，创建大写字段名且添加双引号后，后续查询字段会区分大小写。
（四）字段设计需要保证各应用系统模块中的相同字段完全一致，包括但不限于定义、命名、长度、精度、取值范围等保持一致。
（五）字段命名样式基于逻辑数据实体的属性名称转换成常用英文单词或国际通用英文简写。不使用四个以上单词，不允许使用拼音。字段名长度不超过50个字符。
7.5.2字段类型规范
（一）优先选择最高效的类型存储数据，这可以提高数据库的有效容量及查询执行性能。选择数值类型时，在满足业务精度的情况下，选择数据类型的优先级从高到低依次为整数、浮点数、NUMERIC。
（二）考虑字段创建的可扩展性，使用满足需求的可能的最大数值类型。如INT或SMALLINT，可以统一使用BIGINT，减少源端字段变宽后的维护工作量。
（三）字符串类型除明确指定数据类型为固定长度字符串外，统一使用VARCHAR(N)类型，注意长度N指的是字符编码长度，以UTF8为例，一个汉字约等于3-4个编码长度。
（四）金额型字段的数值统计字段统一用DECIMAL(P,S)类型，避免使用浮点型（FLOAT或DOUBLE），以防浮点数精度误差影响计算结果。
（五）当多个表存在逻辑关系时，应保证相同业务含义的字段使用一致的数据类型，以提高数据兼容性、查询优化和维护便利性。
（六）尽量减少对TEXT字段的更新操作，频繁修改TEXT类型字段可能导致更多的写入放大和磁盘I/O操作，影响数据库整体性能。
7.5.3湖仓分层扩展字段
（一）物理数据模型都应添加记录来源、记录创建时间、记录更新时间、逻辑删除标识等扩展字段。
（二）记录来源字段记录上游系统或数据库表的信息
（三）记录创建时间与记录更新时间赋值为对应作业的执行时间。
（四）逻辑删除标识统一初始化为false，后根据业务场景需求配置源端校验作业，周期性识别物理删数情况，更新删除标识字段。
扩展字段 | 英文名 | 类型 | 适用分层 |
记录来源 | ext_source_db | string | SDI、DWI、DWR的非汇聚表 |
记录创建时间 | ext_created_ts | timestamp | SDI、DWI、DWR、DM |
记录更新时间 | ext_updated_ts | timestamp | SDI、DWI、DWR、DM |
删除标识 | ext_is_deleted | BOOLEAN | SDI、DWI、DWR的非汇聚表 |
（五）涉及需要记录历史变化的应用场景，缓慢变化维度表需要增加拉链字段：
扩展字段 | 英文名 | 类型 |
版本号 | row_version | integer |
有效起始日期 | valid_begin_date | date |
有效终止日期 | valid_end_date | date |
有效标识(是否当前版本) | is_valid | BOOLEAN |
7.6表设计规范
7.6.1行存、列存设计
（一）行存储按行组织数据，适用于字段数量较少且查询涉及大部分字段的场景，能够快速定位目标数据。行存建表参数WITH(ORIENTATION=row)。建议在点查询需求高且列存Hstore无法满足要求时配置，以及UPDATE/DELETE操作频繁的场景下使用行存表，应用行存表时禁止配置压缩。
（二）列存储按列组织数据，仅读取查询涉及的列，适用于字段较多但查询涉及列较少的场景，具备更高的数据压缩率。列存建表参数为WITH(ORIENTATION=column, enable_hstore_opt=on)，适用于 统计分析类查询（如GROUP、JOIN 操作较多）、即席查询（查询条件不确定，行存表索引难以利用）。
（三）集团数据中台建设中统一采用列存进行建表。
（四）不指定行列存参数后，默认为行存。建表语句中应显式指定表的行列存类型。
7.6.2表分布设计规范
（一）数据量在100万行以内的维度表或小表应定义为复制表（Distributed By Replication），每个存储节点存储全量数据，以空间换取时间，可避免JOIN时的节点间数据通信，降低网络开销，并减少线程启停开销。
（二）数据量较大的表或事实表应定义为哈希表（Distributed By Hash），必须指定合理的分布键，禁止使用默认分布键。优先选择主键作为分布键，无主键表应选择多个低重复度列作为组合分布键，以确保数据均匀分布。若JOIN条件未包含分布键，可能导致节点间数据通信增加，影响查询性能。
（三）对于数据倾斜严重且无合适分布键的大表或事实表，可定义为轮询分布表（Distributed By RoundRobin），数据可均匀分布，避免存储倾斜问题，但在基于分布键的关联查询或聚合时，性能可能低于哈希表。
（四）建表语句中应显式声明表的分布设计类型。
7.6.3表分区命名规范
（一）普通分区表：一律按时间维度分区，分区名前缀为p ，分区名命名规则：p+{日期值}
*时间分区* | *分区值格式* | *分区名举例* |
按日分区 | p{YYYYMMDD} | p20250310 |
按月分区 | p{YYYYMM} | p202503 |
按年分区 | p{YYYY} | p2025 |
（二）自动分区表：普通的分区表不会自动创建新的分区和删除过期的分区，所以维护人员需要定期创建新分区和删除过期分区，提高了运维成本。为解决上述问题，GaussDB(DWS)引入了分区自动管理特性。可通过设置表级参数period、ttl开启分区自动管理功能，使分区表可以自动创建新分区和删除过期分区，降低分区表的维护成本，改善查询性能，约束如下：
1．开启了分区自动管理功能的分区表，不需要手动维护分区，仅需要建表时指定period、ttl参数。
2．分区键唯一且指定数据类型为timestamp、timestamptz、date的字段。
7.6.4分区规范
（一）使用具有明显区间性的字段进行分区，比如在日期、区域等字段上建立分区。
（二）分区名称应当体现分区的数据特征。例如，关键字+区间特征。
（三）将分区上边界的分区值定义为MAXVALUE，以防止可能出现的数据溢出。
（四）2000万以上的大表需要设置分区，可根据数据量按日/按月/按年进行分区。
（五）1000万以上（或日增5万以上），且需频繁对一段时间内（几天内）进行删除或更新操作的表需要建分区表，一般按日进行分区。
（六）如果对数据有存储周期管理（如只保留一年或几年的数据，更久的数据删除或者归档），需要使用分区（一般按月）。
（七）100万以下的小表不需要设置分区。
（八）尽量跟源表的分区策略保持一致。
（九）对于列存储的表，慎用过多的分区。
（十）报告和指标按统计周期分区。
增加分区语法示例：
拆分分区语法参考：
7.6.5表索引规范
（一）在经常需要搜索查询、过滤、使用join操作的列上创建索引，可以加快SQL执行的速度。
（二）在作为主键的列上创建索引，强制该列的唯一性和组织表中数据的排列结构。
（三）在经常需要根据范围进行搜索的列上创建索引，因为索引已经排序，其指定的范围是连续的。
（四）索引字段的总长度不超过50字节。否则，索引大小会膨胀比较严重，带来较大的存储开销，同时索引性能也会下降
（五）索引列必须是DISTINCT值多的列，创建多列组合索引时，DISTINCT值多的列往前放。
（六）单表索引个数控制在5个以内，可通过组合索引控制索引的个数。
（七）对于存在过滤条件的字符串字段，可使用Bitmap索引以提高查询性能。Bitmap索引仅适用于字符串类型字段，不适用于非字符串字段。创建列存表时，可通过WITH(ORIENTATION=column,enable_hstore_opt=on,bitmap_columns='col1,col2')指定需要创建Bitmap索引的列，以优化查询效率。
7.6.6表压缩规范
（一）高压缩比适用于I/O读写量大、CPU资源富余的场景，建议选择高压缩比；反之，选择低压缩比。压缩比通过COMPRESSION参数指定，列存表支持YES/NO/LOW/MIDDLE/HIGH，默认值为MIDDLE。
（二）禁止对行存表配置压缩参数。
（三）非特殊场景下保持默认压缩参数。
7.6.7其他规范
（一）视图前缀为v_，按业务操作命名视图。
（二）存储过程前缀为sp_，按业务操作命名存储过程。
（三）函数前缀为func_。按业务操作命名函数，函数的名称要体现函数功能。
（四）序列前缀为seq_，按业务属性命名。
（五）普通变量前缀为v{类型}，存放字符、数字、日期型变量（变量前缀建议：字符vs，数字vi_，日期vd_，尽量简化）。
（六）游标变量前缀为cur_，存放游标记录集。
（七）记录型变量前缀为rec_，存放记录型数据。
（八）表类型变量前缀为tb_，存放表类型数据。
- 作者:tacjin
- 链接:http://jin.wiki/article/24ee55fd-4dcc-8092-af40-c1eb81233b50
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
