企业中的结构化数据存储在数据库中，数据库中的数据按照一定的数据模型进行存储。首先对数据领域所包含的“模型”概念进行辨析，包括数据分析模型、统计分析模型、数据挖掘模型、算法模型、数据模型。
以上各类“模型”中，数据挖掘模型和算法模型最容易混淆。数据挖掘模型是针对具体的业务问题而建立的模型，直接服务于业务决策，如：针对市场营销的精准营销模型，针对用户流失的流失预警模型，针对信用风险评估的风险预测模型等。构建数据挖掘模型的过程包括业务理解、特征体系、算法模型等内容。算法模型仅关注于算法本身，这个是纯技术层面的，如决策树、神经网络、支持向量机、朴素贝叶斯等算法，强调的是确定函数关系和其中的各类参数。而数据挖掘模型中往往也会使用一些统计分析模型和算法模型的技术，例如在针对用户营销的精准营销模型中会使用逻辑回归、随机森林、XGBoost等来预测用户购买的概率。
数据模型是利用图形方式（E-R图），描述数据在数据库中有序组织、存放方式的“地图”与规划“蓝图” 。数据模型是理解数据库中的表、字段和表关系的重要工具。
关系数据模型
关系数据模型是一种基于关系代数和关系演算理论的数据模型，它通过实体-关系图（E-R，Entity-Relationship Diagram）的形式来表示实体以及实体之间的联系。关系模型的数据被组织成一个或多个表，每个表由若干行（元组）和列（属性）组成，每一列代表一个属性，每一行代表一个记录。关系模型是对业务流程中的实体和关系进行精确的结构化描述，在OLTP系统中或数据仓库底层中使用，也被称为基础数据的数据模型。
上图右侧是一个信贷审批流程的示例，左侧是关系数据模型的示例。在流程中可以识别出参与者（客户、员工）、业务事项（业务事项、申请、通知）、协议（合约、子合约）、物品（证件、押品）等实体，实体之间存在父子关系（业务事项与申请和通知之间是父子关系）和基数关系（客户拥有证件是基数关系）。
实体
实体通常是名词，人、事的抽象化对象。比如：员工、公司等等。
关系
父子关系
父子关系是一种常见且重要的数据组织方式，它用于表示实体之间的层次或包含关系。在关系模型中通过表之间的关联（如外键）来表示这种关系。例如，一个部门表可以包含部门ID和部门名称等属性，而一个员工表则可以包含员工ID、姓名、所属部门ID等属性。通过部门ID作为外键与部门表进行关联，就可以实现员工与部门之间的父子关系。
父子关系可以帮助我们更好地理解和组织数据，提高数据查询和分析的效率。例如，在组织结构管理中，我们可以使用父子关系来表示部门之间的层级关系；在商品分类中，我们可以使用父子关系来表示商品类别之间的包含关系。
基数关系
基数（Cardinality）在数据模型中通常指的是一个实体可以关联到的另一个实体的实例数量。在关系数据库中，这通常用于描述表之间的关系，如一对一、一对多或多对多等。
- 一对一（1:1）关系：在这种关系中，一个实体或记录只能与另一个实体或记录的一个实例相关联。例如，一个人只有一个唯一的身份证号码（假设不考虑重复或错误情况）。
- 一对多（1:N）关系：在这种关系中，一个实体或记录可以与多个其他实体或记录的实例相关联。例如，一个班级可以有多名学生，但每个学生只能属于一个班级。
- 多对多（N:M）关系：在这种关系中，两个实体或记录集之间的关联是双向的，且每个实体或记录可以与对方集合中的多个实例相关联。例如，学生和课程之间的关系就是多对多的，一个学生可以选修多门课程，而一门课程也可以被多个学生选修。
在数据建模中，基数关系由多种表示方法。在ER图（实体-关系图）中，基数关系可以通过在关系线上添加符号来表示，如“1”、“N”或“*”等，以指明关联的数量。常用的表示方法有IE（Information Engineering）风格，用小竖线代表“1”，用两条小斜线代表“N”。另外一种是IDEF1X风格，用“*”或小圆点代表“N”，在PowerBI中就采用的这种表示风格。
在确定实体之间的基数时，可以借助动词来判断基数的数量，比如一个客户可以买多辆车，而一辆车只能被一个客户买，则客户与车辆之间是“1：N”的关系。
基数关系在数据模型设计中起着至关重要的作用，它影响了数据的完整性、查询效率以及系统的可扩展性。正确地定义基数关系有助于减少数据冗余、保持数据一致性，并提高数据处理的效率和准确性。
在E-R图中，两个表是“N：1”的关系，“销售人员表”是一表，“订单表”是多表。“销售员ID”是“销售人员表”表的主键，在“订单表”中是外键。在分析销售人员的业绩时（比如月销售额），可以通过基数关系确认一个销售员ID对应多个订单ID，以“销售人员表”作为主表，以“订单表”作为从表，通过“销售员ID”进行关联，并对“销售金额”字段进行汇总。
属性和主外键
属性（Attribute） 是指实体（Entity）所具有的某一特性。比如“开户日期（date）”是“账户表（Accounts）”的一个属性。
主键（Primary Key） 是用来唯一标识表中每一行的字段（或字段组合）。主键可以是单个字段，也可以是多个字段的组合（称为复合主键）。它必须满足两个条件：1）唯一性：表中的每一行都必须有一个唯一的主键值，不能有两行具有相同的主键值。2）非空性：主键字段中的值不允许为空（NULL）。主键一般和表名一致，并加上ID作为后缀，比如”account_id”就是“账户表（Accounts）”表的主键。不过也有例外，比如“人口地区统计表（Distict）”表的主键是“A1”。
外键（Foreign Key） 是用来在两个表之间建立关系的字段。它是指一个表中的字段，该字段是另一个表的主键。外键的作用是保持数据的一致性、完整性和实现表之间的关联查询。通过外键，一个表（称为子表或从表）中的记录可以与另一个表（称为父表或主表）中的记录相关联。比如”account_id”在“交易表（Trans）”中是外键。通过E-R图中的基数关系，再结合主外键，就可以清晰的知道如何提取数据，比如“账户表（Accounts）”和“交易表（Trans）”连接时，应该使用”account_id”作为连接变量。
维度数据模型
维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能。该模型用在OLAP系统中，往往在数据仓库的上层、数据集市、多维分析工具、报表工具中使用。根据数据模型对三范式（3NF）的遵从程度和模型的复杂度，分为星形模型、雪花模型和星座模型。
事实表 ：主要用于存储实际的业务度量数据，例如销售记录、订单详情等。它们记录了业务系统发生的事实行为数据，数据量庞大且实时变化。
维度表 ：提供对事实表的上下文和描述性信息，帮助用户更好地理解数据。维度表的数据相对静态，不易发生变化，例如客户信息、产品信息等。
星型模型
星型模型由一个中心的事实表（Fact Table）和多个维度表（Dimension Tables）构成。事实表包含了可度量的数据，如销售额或利润，而维度表则包含了描述这些数据的属性，如时间、地点或产品类型。星型模型中只有一张事实表，事实表与维度表通过主键外键相关联，维度表之间不存在关联关系，当所有维度表都关联到事实表时，整个图形非常像一种星型的结构，所以称之为“星型模型”。
雪花模型
当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。雪花模型是为了满足三范式（3NF）要求而对星型模型的扩展，比如在星形模式中“地域维表”包含了从国家到城市所有的分类信息，这样信息会冗余，则拆分出了国家表、省份表和城市表。雪花模型的优点是通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能，避免了数据冗余。其缺点是增加了主键-外键关联的几率，导致查询效率低于星型模型，并且不利于开发。
星座模型
星座模型中存在多张事实表，不同事实表之间共享维表信息，事实表之间不直接相连，而是通过维度表相连形成一个星座状结构，故称星座模型，常用于数据关系更复杂的场景。
虽然星座模型的结构非常灵活，能够更好地支持复杂的数据分析需求。然而，这种模型的构建和维护非常困难，需要谨慎使用。
在企业IT系统中，涉及到基数数据的系统采用关系数据模型，比如订单系统、交易系统等“在线事务（OLTP）”系统。涉及到数据分析的系统多采用维度数据模型，比如财务分析集市等“在线分析（OLAP）”系统。
数据建模的层次
建立数据模型需要由粗到细，从重点关注顶层业务实体和关系，到关注对象的属性。因此，数据模型的层次可以分为概念模型、逻辑模型和物理模型三个层次。概念模型（CDM）描述预设范围内的业务需求，逻辑模型（LDM）详细业务解决方案，物理模型（PDM）详细技术解决方案。在数据建模之前，还有一个必要环节，那就是对数据按照业务属性进行分类，即主题域分类。
主题域模型
主题域模型处于企业数据模型的顶层，是针对企业关键业务领域业务概念的分类方法和框架。主题域模型主要的参与者是企业中的管理者或是高级数据管理者。
主题域分类是从业务角度对数据进行划分，不同行业的主题域是不一样的，甚至每个企业的主题域也不是一样的。传统行业如银行、制造业、电信、零售等行业中，都有比较成熟的主题划分，如BDWM、FS-LDM、MLDM等等。
概念模型
概念模型以实体—关系（Entity-Relationship，简称E-R）理论为基础，通过主题域形式描述概念化的结构。概念模型是对某个主题域内容的细化。
概念模型描述企业内主要业务的实体以及实体间的业务关系，概念模型主要面向业务管理人员，通常需要借助ER图来实现。概念模型最关心实体之间的关系，尽可能地凝聚出实体和关系。在概念模型阶段并不需要对实体中的属性进行具体化。
逻辑模型
逻辑模型是对概念模型的进一步细化，通过关键数据属性描述更多业务细节。逻辑模型描述实体、属性以及实体关系，只包含关键数据属性，而不是全部实体和全部属性。逻辑模型独立于具体技术，是IT人员和业务人员沟通的工具，主要面向架构师使用。
物理模型
模型的落地还需要建立物理模型，一般情况下物理模型是由数据库管理员、数据库工程师具体实施，主要是将逻辑模型转化成数据库的设计表达，所涉及到的有数据库中的表、数据类型、字段长度等信息。
