版本：V1.0
 
最后修改日期：2021/03/17
 
本文首发微信公众号：码上观世界

 
1. 数据模型设计目标

 
    为使下游数据使用方低成本获取一致性的可靠数据服务，数据模型设计方需要达到如下目标：
 
成本：模型设计者要平衡性能和成本要素对数据模型的影响，现有海量大数据情况下，以保障业务和性能为前提，合理使用数据模型方案和存储策略，尽量消除不必要的数据复制与冗余。
性能：模型设计者需要兼顾模型刷新性能开销、产出时间和访问性能。
数据一致性及数据互通：各个数据模型或者数据表之间必须保障数据输出的一致性，相同粒度的相同数据项（指标、维度）应具有相同的字段名称和业务描述，不同算法的业务指标应显性化区分。
数据质量：数据公共层模型需要屏蔽上游垃圾数据源，一方面要保障数据本身的高质量，减少数据缺失、错误、异常等情况的发生；另一方面要保障其对应的业务元数据的高质量，数据有明确的业务含义，为数据提使用者供正确的指引。
易用：在保障以上目标的前提下，数据用户能从业务角度出发快速找到所需数据；能较快的掌握模型的适用场景和使用方法；能相对便捷获取数据。
 
2. 数据模型设计指导思想
 
    数据模型设计以ER模型、维度模型和宽表模型理论为指导以及阿里巴巴数据仓库建设实践为经验参考。
 
2.1 ER模型
 
    数据仓库之父Bill lnmon 提出的建模方法是从全企业的高度设计一个3NF 模型，用实体关系（ Entity Relationship, ER ）模型描述企业业务，在范式理论上符合3NF 。数据仓库中的3NF 与OLTP 系统中的3NF的区别在于，它是站在企业角度面向主题的抽象，而不是针对某个具体业务流程的实体对象关系的抽象。其具有以下几个特点：
 
需要全面了解企业业务和数据。
实施周期非常长。
对建模人员的能力要求非常高。
 
2.2 维度模型
 
    

 
    数据仓库领域的Ralph Kimball 大师所倡导的，维度建模从分析决策的需求出发构建模型，为分析需求服务，因此它重点关注用户如何更快速地完成需求分析，同时具有较好的大规模复杂查询的响应性能。其典型的代表是星形模型，以及在一些特殊场景下使用的雪花模型。维度模型的维度退化即是宽表模型。
 
    ER模型是一种范式模型，ER模型和维度模型虽然建模工具类似，比如都使用实体关系来表示，主要区别在于：
 
1. 着眼点不同：维度建模着眼点在产生事实的业务过程，ER模型着眼点在实体和实体的关系，ER模型的关系更为一般化。
 
2. ER模型的实体通常是具有业务价值的业务对象，比如商品，客户等，维度模型的维度更着重业务检索需求，如日期、地域、商品等，如下图示例:
 

 

 
3. 数据模型设计基本原则
 
高内聚和低耦合：软件设计方法论中的高内聚和低耦合原则同样适用于数据建模，这主要从数据业务特性和访问特性两个角度来考虑：将业务相近或者相关的数据、粒度相同数据设计为一个逻辑或者模型；将高概率同时访问的数据放一起，将低概率同时访问的数据分开存储。
核心模型与扩展模型分离：建立核心模型与扩 展模型体系，核心模型包括的字段支持常用核心的业务，扩展模型包括的字段支持个性化或是少量应用的需要，必要时让核心模型与扩展模型做关联，不能让扩展字段过度侵入核心模型，破坏了核心模型的架构简洁性与可维护性。
公共处理逻辑下沉及单一：越是底层公用的处理逻辑更应该在数据调度依赖的底层进行封装与实现，不要让公共的处理逻辑暴露给应用层实现，不要让公共逻辑在多处同时存在。
成本与性能平衡：适当的数据冗余换取查询和刷新性能，不宜过度冗余与数据复制。
数据可回滚（数据生成支持幂等性）：处理逻辑不变，在不同时间多次运行数据结果确定不变。
一致性：相同的字段在不同表字段名相同，字段值相同。
命名清晰可理解：表命名规范需清晰、一致，表名需易于下游理解和使用。
 
4. 数据模型设计步骤总览
 
4.1 数据模型设计总体步骤
 
业务建模：生成业务模型，主要解决业务层面的分解和程序化，常用工具如流程图、时序图、用例图等。
领域建模：生成领域模型，主要是对业务模型进行抽象处理， 生成领域概念模型，这一步中会涉及到概念的分组(主题)，比如Teradata FS-LDM模型将金融业的领域概念划分成10大主题:当事人、产品、协议、事件、资产、财务、机构、地域、营销、渠道。
逻辑建模：生成逻辑模型，主要是将领域模型的概念实体以及实体之间的关系进行数据库层次的逻辑化。
物理建模：生成物理模型，主要解决逻辑模型针对不同关系数据库的物理化以及性能等一些具体的技术问题。
 
上述步骤是模型从抽象化到具体落地的过程，也反应了模型的不同抽象层次。每个层次内部还可以继续按照层次具体分解，比如业务模型还可以分为顶层模型，业务域，业务流程，业务环节。
 
4.2 数据模型设计实施流程
 
    各步骤按照实施过程涉及到的内容见下图：
 

 
业务调研和需求分析是数据仓库建设的基石。在代码开发之前，数据架构设计主要是根据数据域对数据进行划分；按照维度建模理论，构建总线矩阵、抽象出业务过程和维度。再次，根据需求抽象整理出相关指标体系。数仓建模主要关注从业务建模领域建模到逻辑建模的过程，其中业务建模和领域建模是基础，逻辑建模是核心。本文将上述实施步骤通过流程梳理如下：
 

 
5. 数据模型设计术语名词解释
 
术语
                                                   解释
主题（域）
主题（Subject）是在较高层次上将企业信息系统中的数据进行综合、归类和分析利用的一个抽象概念，每一个主题基本对应一个宏观的分析领域。在逻辑意义上，它是对应企业中某一宏观分析领域所涉及的分析对象。例如“销售分析”就是一个分析领域，因此这个数据仓库应用的主题就是“销售分析”。主题域是对某个主题进行分析后确定的主题的边界。
数据域
指面向业务分析，将业务过程或者维度进行抽象的集合。其中， 业务过程可以概括为一个个不可拆分的行为事件， 在业务过程之下， 可以定义指标；维度是指度量的环境，如买家下单事件，买家是维度。为保障整个体系的生命力， 数据域是需要抽象提炼，并且长期维护和更新的， 但不轻易变动。在划分数据域时， 既能涵盖当前所有的业务需求，又能在新业务进入时无影响地被包含进已有的数据域中和扩展新的数据域。
业务板块
业务板块定义了数据仓库的多种命名空间，是一种系统级的概念对象。当数据的业务含义存在较大差异时，您可以创建不同的业务板块，让各成员独立管理不同的业务，后续数据仓库的建设将按照业务板块进行划分。
业务过程
指企业的业务活动事件，如下单、支付、退款都是业务过程。请注意，业务过程是一个不可拆分的行为事件， 通俗地讲，业务过程就是企业活动中的事件
业务限定
统计的业务范围，用于筛选出符合业务规则的记录（类似于SQL中where后的条件，不包括时间区间）。原子指标是计算逻辑的标准化定义，业务限定则是条件限制的标准化定义。
时间周期
用来明确数据统计的时间范围或者时间点，如最近30 天、自然周、截至当日等
修饰类型
是对修饰词的一种抽象划分。修饰类型从属于某个业务域，如日志域的访问终端类型涵盖无线端、PC 端等修饰词
修饰词
指除了统计维度以外指标的业务场景限定抽象。修饰词隶属于一种修饰类型，如
在日志域的访问终端类型下， 有修饰词PC 端、无线端等
统计粒度
统计分析的对象或视角，定义数据需要汇总的程度，可以理解为聚合运算时的分组条件（类似于SQL中group by的对象）。粒度是维度的一个组合，指明您的统计范围。例如，某个指标是某个卖家在某个省份的成交额，则粒度就是卖家、省份这两个维度的组合。如果您需要统计全表的数据，则粒度为全表。在指定粒度时，您需要充分考虑到业务和维度的关系。统计粒度也被称为粒度，是维度或维度组合，一般用于派生指标构建，是汇总表的唯一性识别方式。
指标
指标分为原子指标和派生指标。派生指标是以原子指标为基准，组装统计粒度、统计周期及业务限定而生成的。
原子指标是对指标统计口径、具体算法的一个抽象。根据计算逻辑复杂性，Dataphin将原子指标分为两种：
原生的原子指标：例如支付金额。
衍生原子指标：基于原子指标组合构建。例如，客单价通过支付金额除以买家数组合而来。
派生指标是业务中常用的统计指标。为保证统计指标标准、规范、无二义性地生成，OneData方法论将派生指标抽象为四部分：派生指标=原子指标+业务限定+统计周期+统计粒度。
维度
维度是度量的环境，用来反映业务的一类属性， 这类属性的集合构成一个维度，
维度也可以称为实体对象。维度属于一个数据域，如地理维度（其中包挤罔家、地区、
省以及城市等级别的内容）、时间维度（其中包括年、季、月、周、日等级别的内容）
维度属性
维度属性隶属于一个维度， 如地理维度里面的国家名称、同家ID 、省份名称等都属于维度属性
派生指标
派生指标＝一个原子指标＋多个修饰词（可选）＋时间周期。可以理解为对原子指派生指标标业务统计范罔的圈定。如原子指标：支付金额，最近l天海外买家支付金额则为派生指标（最近l 天为时间周期， 海外为修饰词， 买家作为维度，而不作为修饰词）
 
注意：
 
这里有两个概念：主题域和数据域，两者概念一致，虽然都是从业务上划分，只是角度不同。主题从高层业务视角来划分，面向业务。数据域从系统数据打通的角度来划分，面向数据。数据域可能涉及到多主题域，主题域也可能涉及到多数据域。
 
6. 数据模型设计实施过程
 
6.1 数据调研
 
    
 
    通过跟业务分析师或者运营人员了解数据需求，借助各种分析工具对涉及到的业务流程进行梳理和业务领域划分。这一步骤输出的文档包括业务流程图、时序图、活动图、用例图等。
 
6.2 数据域划分
 
    数据仓库是面向主题的应用，主要功能是将数据综合、归类并进行分析利用。数据仓库模型设计除横向的分层外，通常还需要根据业务情况纵向划分数据域。数据域是联系较为紧密的数据主题的集合，是业务对象高度概括的概念层次归类，目的是便于数据的管理和应用。
 
通常您需要阅读各源系统的设计文档、数据字典和数据模型设计文档，研究逆向导出的物理数据模型。然后进行跨源的主题域合并，梳理出整个企业的数据域。划分数据域，需要分析各个业务模块中有哪些业务活动。数据域，可以按照用户企业的部门划分，也可以按照业务过程或者业务板块中的功能模块划分。例如，A公司电商营销业务板块可以划分为如下表所示的数据域。数据域中的每一部分，都是根据实际业务过程进行归纳、抽象得出的。
 
输出文档：数据域和业务过程分类关系，格式可以是类似下面的图例：
 

 
6.3 指标规范定义
 

 

 

 
指标规范定义输出文档格式为：

 
数据域
业务过程
指标
指标类型
名称
说明
维度
交易域
支付
金额
原子指标
order_amt

区域
时间
渠道
笔数
原子指标
order_cnt




售后域
退款
笔数
原子指标
refund_cnt





 
6.4 ER模型梳理
 
    这一步骤是按照自下向上快速构建数仓的方式，对业务需要的业务过程建模。细化领域模型中得出的实体及其属性、维度及其属性、业务过程及其维度和度量、指标，输出ER图文档。
 

 
6.5 数据域映射
 
    该步骤将ER图中每个业务过程涉及到的业务表及其数据来源维度、指标等信息列举出来,输出数据源映射文档。
 
数据域
业务过程
数据源
数据源类型
业务表
表类型
名称
维度、度量、属性
交易域
支付
交易
mysql
order_table
事实表
订单表
区域id
时间id
金额
prod_table
维度表
商品表
类目
cust_table
维度表
客户表
年龄
售后域
退款
售后
oracle
refund_table
事实表
退款表
区域id
时间id
金额
 
6.6 数仓分层
 

 
操作数据层（ ODS ）：把操作系统数据几乎无处理地存放在数据仓库系统中。包括全量和增量同步的结构化数据、经过处理后的非结构化数据以及根据数据业务需求及稽核和审计要求保存历史数据、清洗数据。
数据公共层CDM（Common Data Model，又称通用数据模型层），包括DIM维度表、DWD和DWS，由ODS层数据加工而成。主要完成数据加工与整合，建立一致性的维度，构建可复用的面向分析和统计的明细事实表，以及汇总公共粒度的指标。
公共维度层（DIM）：基于维度建模理念思想，建立整个企业的一致性维度。降低数据计算口径和算法不统一风险。
公共维度层的表通常也被称为逻辑维度表，维度和维度逻辑表通常一一对应。公共汇总粒度事实层（DWS）：以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表，以宽表化手段物理化模型。构建命名规范、口径一致的统计指标，为上层提供公共指标，建立汇总宽表、明细事实表。
公共汇总粒度事实层的表通常也被称为汇总逻辑表，用于存放派生指标数据。明细粒度事实层（DWD）：以业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细层事实表。可以结合企业的数据使用特点，将明细事实表的某些重要维度属性字段做适当冗余，即宽表化处理。明细粒度事实层的表通常也被称为逻辑事实表。
数据应用层ADS（Application Data Service）：存放数据产品个性化的统计指标数据。根据CDM与ODS层加工生成。
 
7. 数据模型设计开发规范
 
完整文档关注公众号：码上观世界，回复“数据模型设计开发规范”下载。
 

    模型是现实世界特征的模拟和抽象。在数据库技术中，用数据模型的概念描述数据库的结构和语义，是对现实世界的数据抽象。数据模型是研究数据库技术的核心和基础。
 


 
文章目录
 
1.概念数据模型（CDM）
2.逻辑数据模型（LDM）
3.物理数据模型（PDM）
     
    
   
  
 

 

 

 
1.概念数据模型（CDM）
 
    现实世界主要涉及以下一些概念：
     （1）实体（Entity）
     客观存在并可相互区别的事物称为实体。
     可以是具体的人、事、物或抽象的概念。
     （2）属性（Attribute）
     实体所具有的某一特性称为属性。
     一个实体可以由若干个属性来刻画。
     （3）码（Key）
     唯一标识实体的属性集称为码。
     （4）实体型（Entity Type）
     用实体名及其属性名集合来抽象和刻画同类实体称为
 实体型
     （5）实体集（Entity Set）
     同一类型实体的集合称为实体集
     （6）联系（Relationship）
     现实世界中事物内部以及事物之间的联系在信息世界中反映为实体（型）内部的联系和实体（型）之间的联系。
     实体内部的联系通常是指组成实体的各属性之间的联系
     实体之间的联系通常是指不同实体集之间的联系
     实体之间的联系有一对一、一对多和多对多等多种类型
 
    概念数据模型是现实世界到信息世界的第一层抽象，主要是在高水平和面向业务的角度对信息的一种描述，通常作为业务人员和技术人员之间沟通的桥梁。作为现实世界的概念化结构，这种数据模型使得数据库的设计人员在最初的数据库设计阶段将精力集中在数据之间的联系上，而不用同时关注数据的底层细节（如所用的计算机系统的特性以及数据库管理系统—DBMS的特性）。
 
    概念数据模型主要的贡献在于分析数据之间的联系，它是用户对数据存储的一种高度抽象，反应的是用户的一种业务层面的综合信息需求。
 
    在这个阶段一般会形成整个数据模型或者是软件系统中的实体的概念以及实体之间的联系，为构建逻辑数据模型奠定基础。下图中描述了现实世界和信息世界以及最终转换成计算机世界信息的转换流程。
 

 
 
    设计概念数据模型的主要工具是E-R图，扩展的E-R图。
     概念模型的表示方法最常用的是P.P.Chen于1976年提出的"实体-联系图方法（Entity-Relationship Approach），简称E-R模型"。E-R实体联系图是直观表示概念模型的工具，其中包含了实体、联系、属性三个成分，联系的方法为一对一（1:1）、一对多（1:N）、多对多（M:N）三种方式，联系属于哪种方式取决于客观实际本身。
     E-R模型图，既表示实体，也表示实体之间的联系，是现实世界的抽象，与计算机系统没有关系，是可以被用户理解的数据描述方式。通过E-R模型图可以使用户了解系统设计者对现实世界的抽象是否符合实际情况，从某种程度上说E-R模型图也是用户与系统设计者进行交流的工具，E-R模型图已成为概念模型设计的一个重要设计方法。
 　　
 
 

 
 
2.逻辑数据模型（LDM）
 
数据模型由三部分组成：数据结构、数据操作和数据约束。
 　　(1)数据结构：数据结构主要描述数据的类型、内容、性质、以及数据之间的联系，是整个数据模型的基础，而针对数据的操作和数据之间的约束都是建立在数据结构的基础上的；
 　　(2)数据操作：主要定义了在相应的数据结构上的操作类型和操作方式（数据库中的增删改查等）；
 　　(3)数据约束：数据约束主要用来描述数据库中数据结构之间的语法、词义联系以及彼此之间的相互约束和制约关系（如MySQL中使用外键保证数据之间的数据完整性）
 
逻辑数据模型是对概念数据模型进一步具体化，在概念数据模型定义实体的基础上定义了各个实体的属性，是用户从数据库的角度能够看到的数据的模型，是所使用的数据库管理系统（Database Management System，DBMS）所支持的数据类型（网状数据模型、层次数据模型、关系数据模型）。这种数据模型架起了用户和系统之间的桥梁，既要面向用户，同时也考虑到了所用的DBMS所支持的特性。
 
逻辑数据模型反映了系统分析设计人员针对数据在特定的存储系统（如MySQL）的观点，是对概念数据模型的进一步细化和划分。逻辑数据模型是根据业务之间的规则产生的，是关于业务对象、业务对象数据以及业务对象彼此之间关系的蓝图。
 
逻辑数据模型的内容包括所有的实体、实体的属性、实体之间的关系以及每个实体的主键、实体的外键（用于维护数据完整性）。其主要目标是尽可能详细的描述数据，但是并不涉及这些数据的具体物理实现。逻辑数据模型不仅会最终影响数据库的设计方向，并最终会影响到数据库的性能（如主键设计、外键等都会最终影响数据库的查询性能）。
 
逻辑数据模型是开发物理数据库的完整文档，逻辑数据模型主要采用的是层次模型、网状模型、关系模型，其中最常用的是关系模型，对应的数据库称之为关系型数据库，如MySQL。
 　　常用的结构数据模型是关系模型和面向对象模型，关系模型的理论基础是数学理论，数据的操作通过关系运算实现。在关系模型中用二维表表示实体及实体之间的联系，关系模型的实例称为关系。从数学的观点上看，关系是集合，其元素是元组（记录）。遵循一定的规则后，可以将E-R模型图转换成关系模型。
 

     将E-R模型图转换成关系模型的规则：
 E-R模型图中的主要成分是实体及实体之间的联系，对于实体的转换方式是：
 　　1) 将一个实体转换成一个关系模型。实体的属性为关系模型的属性，实体的标识符为关系模型的关键字，如上图所示的E-R模式中有两个实体：学生、课程，可以分别转换学生模型和课程模型：
     学生模型（学号,姓名,性别,年龄），学号是学生模型的关键字
     课程模型（课程号，课程名，学时数），课程号是课程模型的关键字
     2) 联系转换为关系模型。联系转换成关系模型时，要根据联系方式的不同采用不同的转换方式：
     若联系的方式是一对一的(1:1)，可以在两个实体关系模型中的任意一个关系模型中加入另一个关系模型的关键字和联系类型的属性。
     若联系方式是一对多的(1:N)，则在N端（为多的一端）实体的关系模型中加入1端实体关系模型的关键字和联系类型的属性
     若联系方式是多对多的（M:N），则将联系也转换成关系模型，其属性是互为联系的两个实体的关键字和联系的属性
 
 

 

 
3.物理数据模型（PDM）
 
物理数据模型，又称为物理模型，是概念数据模型和逻辑数据模型在计算机中的具体表示。该模型描述了数据在物理存储介质上的具体组织结构，不但与具体的数据库管理系统相关，同时还与具体的操作系统以及硬件有关，但是很多工作都是由DBMS自动完成的，用户所要做的工作其实就是添加自己的索引等结构即可。
 
物理数据模型是在逻辑数据模型的基础上，综合考虑各种存储条件的限制，进行数据库的设计，从而真正实现数据在数据库中的存放。其主要的工作是根据逻辑数据模型中的实体、属性、联系转换成对应的物理模型中的元素，包括定义所有的表和列，定义外键以维持表之间的联系等，具体例子如下：
 

数仓模型设计的整体流程涉及需求调研、模型设计、开发测试、模型上线四个主要环节，且规范设计了每个阶段的输出与输入文档。
 
 
 
 
需求调研：收集和理解业务方需求，就特定需求的口径达成统一，在对需求中涉及到的业务系统或系统模块所承担的功能进行梳理后进行表字段级分析，并对数据进行验证，确保现有数据能够支持业务需求。
模型设计：根据需求和业务调研结果对模型进行初步归类，选择合适的主题域进行模型存放；确定主题后进入数据模型的设计阶段，逻辑模型设计过程要考虑总线结构构建、模型规范定义等关键问题；物理模型设计以逻辑模型为基础，兼顾存储性能等因素对逻辑模型做的物理化的过程，是逻辑模型的最终物理实现.物理模型在一般情况下与逻辑模型保持一致，模型设计完成后需要进入评审与 Mapping 设计。
模型开发：就是对模型计算脚本的代码实现过程，其中包含了数据映射、脚本实现、测试验证等开发过程。单元测试完成后需要通知业务方一起对模型数据进行业务验证，对验证问题做收集，返回验证模型设计的合理性。
模型上线：完成验证后的模型就可以在线上生产环境进行部署。上线后需要为模型配置监控，及时掌握为业务提供数据服务的状况。我们还将模型的实体和属性说明文档发布给仓库数据的使用者，使模型得到更好地应用。

上一篇文章简单介绍了概念数据模型、逻辑数据模型、物理数据模型的基本概念、特性以及三者所对应的数据库的开发阶段。现在针对逻辑数据模型中所用到的三种数据模型---层次数据模型、网状数据模型以及关系数据模型做一个相信的介绍与对比分析。
　　一、层次数据模型
　　定义：层次数据模型是用树状<层次>结构来表示实体类型和实体间联系的数据模型。(来自百度百科)
　　其实层次数据模型就是的图形表示就是一个倒立生长的树，由基本数据结构中的树（或者二叉树）的定义可知，每棵树都有且仅有一个根节点，其余的节点都是非根节点。每个节点表示一个记录类型对应与实体的概念，记录类型的各个字段对应实体的各个属性。各个记录类型及其字段都必须记录。
　　特征:树的性质决定了树状数据模型的特征
　　　　 1. 整个模型中有且仅有一个节点没有父节点，其余的节点必须有且仅有一个父节点，但是所有的节点都可以不存在子节点；
　　　　 2. 所有的子节点不能脱离父节点而单独存在，也就是说如果要删除父节点，那么父节点下面的所有子节点都要同时删除，但是可以单独删除一些叶子节点；
　　　　 3. 每个记录类型有且仅有一条从父节点通向自身的路径；
　　实例：
　　　　 如图1，以学校某个系的组织结构为例，说明层次数据模型的结构。
　　　　 1.  记录类型系是根节点，其属性为系编号和系名；
　　　　 2.  记录类型教研室和学生分别构成了记录类型系的子节点，教研室的属性有教研室编号和教研室姓名，学生的属性分别是学号、姓名和成绩；
            3.  记录类型教师是教研室这一实体的子节点，其属性由教师的编号，教师的姓名，教师的研究方向。
　　优点：
 　　　   1. 层次数据模型的结构简单、清晰、明朗，很容易看到各个实体之间的联系；
　　　　 2. 操作层次数据类型的数据库语句比较简单，只需要几条语句就可以完成数据库的操作；（百度百科）
　　　　 3. 查询效率较高，在层次数据模型中，节点的有向边表示了节点之间的联系，在DBMS中如果有向边借助指针实现，那么依据路径很容易找到待查的记录；
　　　　 4. 层次数据模型提供了较好的数据完整性支持，正如上所说，如果要删除父节点，那么其下的所有子节点都要同时删除；如图1，如果想要删除教研室，则其下的所有教师都要删除；
　　缺点：
　　       1. 层次数据模型只能表示实体之间的1:n的关系，不能表示m:n的复杂关系，因此现实世界中的很多模型不能通过该模型方便的表示；
　　       2. 查询节点的时候必须知道其双亲节点的，因此限制了对数据库存取路径的控制；

图 1. 院系人员组成结构图
　　二、网状数据模型
　　定义：用有向图表示实体和实体之间的联系的数据结构模型称为网状数据模型。

　　其实，网状数据模型可以看做是放松层次数据模型的约束性的一种扩展。网状数据模型中所有的节点允许脱离父节点而存在，也就是说说在整个模型中允许存在两个或多个没有根节点的节点，同时也允许一个节点存在一个或者多个的父节点，成为一种网状的有向图。因此节点之间的对应关系不再是1:n，而是一种m:n的关系，从而克服了层次状数据模型的缺点。
　　特征：
　　　　 1. 可以存在两个或者多个节点没有父节点；
　　　　 2. 允许单个节点存在多于一个父节点；
　　网状数据模型中的，每个节点表示一个实体，节点之间的有向线段表示实体之间的联系。网状数据模型中需要为每个联系指定对应的名称。
　　实例：　　
　　　　 同样是以教务管理系统为例，下面说明了院系的组成中，教师、学生、课程之间的关系。

图 2. 院系的教务管理系统
　　　　由上图中可以看出课程（实体）的父节点由专业、教研室、学生。以课程和学生之间的关系来说，他们是一种m:n的关系，也就是说一个学生能够选修多门课程，一门课程也可以被多个学生同时选修。
　　优点：
　　　　 1. 网状数据模型可以很方便的表示现实世界中的很多复杂的关系；
　　　　 2. 修改网状数据模型时，没有层次状数据模型的那么多的严格限制，可以删除一个节点的父节点而依旧保留该节点；也允许插入一个没有任何父节点的节点，这样的插入在层次状数据模型中是不被允许的，除非是首先插入的是根节点；
　　　　 3. 实体之间的关系在底层中可以借由指针指针实现，因此在这种数据库中的执行操作的效率较高；
　　缺点：
　　　　 1. 网状数据模型的结构复杂，使用不易；
　　　　 2. 网状数据模型数据之间的彼此关联比较大，该模型其实一种导航式的数据模型结构，不仅要说明要对数据做些什么，还说明操作的记录的路径；
 　　三、关系型数据模型
　　关系型数据模型对应的数据库自然就是关系型数据库了，这是是目前笔者最熟悉的数据库。
　　定义：使用表格表示实体和实体之间关系的数据模型称之为关系数据模型。
　　关系型数据库是目前最流行的数据库，同时也是被普遍使用的数据库，如MySQL就是一种流行的数据库。支持关系数据模型的数据库管理系统称为关系型数据库管理系统。
　　特征：
　　　　 1. 关系数据模型中，无论是是实体、还是实体之间的联系都是被映射成统一的关系---一张二维表，在关系模型中，操作的对象和结果都是一张二维表；
　　　　 2. 关系型数据库可用于表示实体之间的多对多的关系，只是此时要借助第三个关系---表，来实现多对多的关系，如下例子中的学生选课系统中学生和课程之间表现出一种多对多的关系，那么需要借助第三个表，也就是选课表将二者联系起来；
　　　　 3. 关系必须是规范化的关系，即每个属性是不可分割的实体，不允许表中表的存在；
　　实例：
　　　　 下面以学生选课系统为例进行说明。学生选课系统的实体包括：学生、教师、课程；其联系一般为学生与课程之间是一种多对多的关系，教师与课程之间是多对多的关系。学生可以同时选择多门课程，一门课程也可以同时被多个学生同时选择；一位教师可以教授多门课程，一门可能可以由多个教师教授。因此他们之间的联系如下：

 
图 3 学生选课系统示意图
　　将该图映射为关系数据模型中的表格为图4。从中可以看到学生与课程之间的联系以及教师和课程之间的多对多联系都被映射成了表格。其中选课表中的sut_id和cour_id分别是引用学生表和课程表的cour_id的外键；教课表也是如此。

 图 4 关系数据模型的表格
　　优点：
　　　　 1. 结构简单，关系数据模型是一些表格的框架，实体的属性是表格中列的条目，实体之间的关系也是通过表格的公共属性表示，结构简单明了；
　　　　 2. 关系数据模型中的存取路径对用户而言是完全隐蔽的，是程序和数据具有高度的独立性，其数据语言的非过程化程度较高；
　　　　 3. 操作方便，在关系数据模型中操作的基本对象是集合而不是某一个元祖；
　　　　 4. 有坚实的数学理论做基础，包括逻辑计算、数学计算等；
　　缺点：
　　　　 1. 查询效率低，关系数据模型提供了较高的数据独立性和非过程化的查询功能（查询的时候只需指明数据存在的表和需要的数据所在的列，不用指明具体的查找路径），因此加大了系统的负担；
　　　　 2. 由于查询效率较低，因此需要数据库管理系统对查询进行优化，加大了DBMS的负担；
　　关系数据模型的三种约束完整性：
　　关系数据模型定义了三种约束完整性：实体完整性、参照完整性以及用户定义完整性。
　　实体完整性：实体完整性是指实体的主属性不能取空值。实体完整性规则规定实体的所有主属性都不能为空。实体完整性针对基本关系而言的，一个基本关系对应着现实世界中的一个主题，例如上例中的学生表对应着学生这个实体。现实世界中的实体是可以区分的，他们具有某种唯一性标志，这种标志在关系模型中称之为主码，主码的属性也就是主属性不能为空。
　　参照完整性：在关系数据库中主要是值得外键参照的完整性。若A关系中的某个或者某些属性参照B或其他几个关系中的属性，那么在关系A中该属性要么为空，要么必须出现B或者其他的关系的对应属性中。如上表中的选课关系的stu_id和cour_id分别是参考学生和课程的外键，那么对于现实的系统而言，stu_id和cour_id必须分别出现在学生和课程关系中，这就是外键参考的完整性，同时删除的时候根据设置的不同有不同的处理方式。
　　用户定义完整性：用户定义完整性是针对某一个具体关系的约束条件。它反映的某一个具体应用所对应的数据必须满足一定的约束条件。例如，某些属性必须取唯一值，某些值的范围为0-100等。