数据建模大数据就业挑战月薪30K，建模挑战月薪30k

数据建模大数据就业挑战月薪30K，建模挑战月薪30k

本文大概
10624
字
读完共需
30
分钟
 
Tips 
参与文末话题讨论，即有机会获得异步图书一本。
 


数据建模是对现实世界各类数据进行抽象组织、界定数据库需管辖的范围、确定数据的组织形式等直至转化成现实数据库的过程。而数据模型是构建应用系统的核心，是尽可能精准地表示业务运转的概念性框架。
数据建模的过程是界定、分析、发现数据需求，再用可视化的形式（“模型”）表示这种数据需求的过程。数据模型是用于精确表示信息领域沟通的一套符号和文字。任何景观的模型都会包含某些内容（例如地图就是地理景观的模型），同时为了方便理解又排除某些内容。
“发现”是确定业务过程或应用中业务需要什么信息，例如了解到客户和账号是个重要的概念。“分析”是明确需求的过程，例如对客户和账户逐步有了清楚的定义，理解了客户与他们的账户之间的关系。“界定范围”涉及与业务合作来决定什么对于特定的业务阶段是最重要的。例如，第一阶段是否同时需要“保存”和“检查账号”，还是只要“检查账号”就行了。“表示”是指要用清晰明确的语言展现出信息景观看上去是什么样的，例如可以用以下数据模型表示：


一个客户可以有一个或多个账号。
一个账号必须由一个或多个客户拥有。
一旦我们将这些需求写成了数据模型文档，就可以跟应用开发所涉及的业务和信息技术（Information Technology，IT）人员进行沟通了，如业务用户、业务分析师、数据建模人员、数据架构师、数据库管理员、开发者、测试人员以及管理人员。
数据模型是用于从业务到IT，IT内部从系统分析员、建模人员、架构师到数据库设计人员和开发人员之间沟通的主要媒介。无论要用的数据库技术是关系数据库管理系统（Relational Database Management System，RDBMS）（如ORACLE、Teradata），还是像MongoDB或Hadoop这样的非关系型数据库（Not Only SQL，NoSQL），都需要有种方式能用来沟通数据需求。因此，我们需要数据模型。
数据模型应该是高质量的，要能支持目前的需求同时又要能满足未来的需要。数据模型记分卡是一个可以用来改进数据模型质量的工具。
许多我正在为他们提供咨询服务的客户都决定将数据记分卡应用到客户的数据模型中，他们也推荐用数据模型记分卡来改进设计。
 
大数据就业挑战月薪30K,本文将简要介绍数据模型的组成，并教你如何看懂数据模型。
1.1　实体 实体表示与业务有关的重要且有价值的事务的信息集合。每个实体由一个名词或名词词组来表示，一般适用于以下6种问题之一：谁、什么、何时、哪里、为什么、如何。表1-1是这些实体类的定义并举例说明。
表1-1　实体类的定义
分类
定义
举例
谁
（Who）
能为企业带来好处的个人或组织。“谁对业务很重要？”常常与角色有关，例如客户或供应商
员工、病人、演员、嫌疑人、客户、供应商、学生、旅客、参赛者、作者
什么（What）
对企业有利的产品或服务。常常指能使组织保持业务运转的产出物。“什么是对业务至关重要的？”
产品、服务、原材料、货物清单、课程、歌曲、照片、图书
何时（When）
企业所关心的日历或时间周期。“何时业务在运作？”
时间、日期、月份、季度、年、学期、会计期间、分钟
哪里（Where）
企业关心的位置。位置可以指实际的地理位置，也可以指虚拟的位置。“业务在哪里开展？”
邮件地址、分布地点、网站的URL及IP地址
为什么（Why）
企业所关心的事件或事务。事件会让业务具有不确定性。“业务为什么可以运转？”
订单、盈利、投诉、取钱、存钱、褒扬、问询、交易、索赔
如何
（How）
将企业关心的事件记录下来。可以用文档记录事件，如采购订单用于记录一个订单事件。这就是”业务是如何跟踪事件的？”
发票、合同、协议、购买订单、收据、发票、装箱清单、交易确认单
实体的实例是指特定实体的发生或实体的值。例如，表单就是一个实体，它的表头的每个字段表示每个实体要记录的信息。每个有实际值的表单行表示一个实体实例。“客户”实体可能会有多个有不同名字的客户实例，如Bob、Joe、Jane等。“账号”实体有Bob的支票账户实例、Bob的存款账户实例、Joe的佣金账户实例等。
实体可以从概念层、逻辑层、物理层进行描述。概念层是对一个业务过程或应用系统定义其范围和重要术语。逻辑层是对一个业务过程或应用系统的业务解决方案进行详细描述，物理层则是对一个应用系统的技术解决方案进行详细描述。
一个与概念层相关的实体一定是对业务基本且关键的。至于什么是“基本且关键的”主要因范围不同而不同。在通用层面，某些概念是大多数公司都共有的，例如，客户、产品和员工。稍微收窄这个范围，特定的行业可能会有某个特定的概念。例如，广告役，这在广告行业是有个有效的概念，但在其他行业中却不适用。在出版行业，作者（Author）、书（Title）和订单（Order）是概念实体，如图1-1矩形框中的名字。


图1-1　用矩形框中的名字表示概念实体
逻辑层的实体比概念层更加详细地表示了业务。经常会用一个概念实体表示多个逻辑实体。逻辑实体包含一些特性，我们叫作“属性”，下一节会讨论。前面的概念实体可以由3个逻辑实体表示，如图1-2所示。


图1-2　逻辑实体
在物理层，实体与技术特定的对象有关，例如关系数据库管理系统（Relational Database Management System，RDBMS）中的数据库表或者非关系型数据库（Not Only SQL，Nosgl）MongoDB中的集合。物理层与逻辑层相似，但可以包括弥补技术缺陷所需要的折中方案，一般是与性能或存储有关的。
以下是前述逻辑实体的物理实体，如图1-3所示。物理实体包含数据库特定的信息，例如，属性的格式和长度（作者的姓氏，即Author Last Name是50个字符长度），该属性是否必须有值（作者的税号标识，即Author Tax Identifier不能为空因而必须有值，作者的出生日期，即Author Birth Date是可空的，所以不要求一定有值）。


图1-3　物理实体
在关系数据库管理系统（Relational Database Management System，RDBMS）中，这些物理实体是数据库表或视图。在非关系型数据库（Not Only SQL，NoSQL）中，这些物理实体根据所用的技术不同而不同。例如，在MongoDB这样的文档数据库中，这些实体是集合。常用的术语“结构”是指数据库组件，无论这种数据库是RDBMS还是NoSQL类型。
1.2　属性 属性是用来识别、描述或度量实体实例的单个信息单元。货运单号（Claim Number）属性标识每个货运单。学生姓氏（Student Last Name）属性描述每个学生。订单金额（Gross Sales Amount）属性度量每笔交易的金额。
像实体一样，属性也可以在概念、逻辑和物理层描述。概念层的属性必须是对业务基本且关键的。通常我们并不从概念层描述属性，当然根据业务需求的不同，也可以作为概念层的属性。我在一家通讯公司工作时，电话号码是对业务非常重要的属性，所以多个概念模型中都有电话号码属性。
逻辑模型的属性表示业务特性。每个属性显示出它对业务解决方案的贡献，并且独立于任何软硬件技术。例如，作者的姓氏（Author Last Name）就是一个属性，因为它有重要的业务意义，无论这些记录是保存在纸质文件里还是能快速检索的数据库里。物理模型的属性代表数据库的一列。作者的姓氏（Author Last Name）属性可能在关系数据库的AUTH表里用AUTH_LAST_NM列表示，或者在MongoDB集合LibraryCardCatalog中用AuthorLastName表示。
1.3　域 一个属性所有可能赋值的全部集合叫作域。域包括一套可应用于不止一个属性的验证标准。例如，日期（Date）域含有可给以下这些属性赋值的所有可能的有效日期。
员工雇用日期
下单日期
交货日期
课程开始日期
一个属性一定不能包含其赋值域以外的值。域值由特定的实际列表值定义或者由一套规则定义。例如，员工性别代码，其值域限制为（男和女），员工雇用日期可能有默认的规则，这个域值只能是有效的日期。因此，可能会有以下值，如：
2005-02-15
1910-01-25
20150410
2050-03-10
员工雇用日期必须是有效日期，例如不能是2月30号。还可以用附加的规则来限制属性的域值。例如，将员工雇用日期域限制为必须早于今天的日期，这样就能排除类似2050年3月10日这样的日期。限制员工雇佣日期为YYYYMMDD格式（年、月、日连接），就能排除所有不符合日期格式的值，例如20152410就会违规。另外一种限制域值的方式是规定员工雇用日期只能是周一、周二、周三、周四、周五的日期（即只能是工作日）。
有3种基本的域类型。
格式化域：设定数据库中可用的标准数据类型。如Character(30)和date，这些都是格式化域。
列表域：类似于下拉列表，列出几个值可供选择。列表域是格式化域的改良。订单状态代码的格式化域可能是 Character(10)，这个域可以从列表域可能的值（打开，已运送，已关闭，已退回）中进行选择。
范围域：规定该域所允许的值在最小值和最大值之间。例如，订单交付日期必须在今天和未来的几个月之间。与列表域类似，范围域也是格式化域的改良。
1.4　关系 实体间的关系是指这些实体的实例可能以某种有意思的方式相关。每个关系都可以定义规则，包括何时相关以及有多少实例相关。关系可以用两个实体间的一条线来描述。有些建模还可以有两个以上的关系，它们会有不同的描述。如果这两个实体是员工和部门，他们之间的关系可以描述为“每个员工必须为一个部门工作”“每个部门可以有一个或多个员工”。
在两个实体关系中，基数能记录有多少实例从一个实体参与到与另一个实体实例的关系中，它由出现在关系线两端的符号表示。基数指定一种可强制的数据规则。如果没有基数，我们最多可以说关系是两个实体以某种方式通过一个规则相互关联。例如，员工和部门有某种关系，但我们知道的仅限于这点。注意，相同的两个实体可以有不止一种相关方式；例如每个部门可以有一个或多个员工，但是可能还会有一个单独的关系记录着某个员工管理某个部门。
关于基数，我们可以选择0、1或多（m）的组合。多（m）表示任何大于0的数。0或1可以记录一个实体实例在一个关系中是否是必需的。1或多（m）可以表示有多少个特定的实例参与这个关系。
因为我们的图标仅有3种基数符号，所以无法指定一个准确的数字[1]（除非通过文档），如“一辆车有4个轮胎”。我们只能说“一辆车可以有多个轮胎”，以作者和书为例，每种基数符号如图1-4所示。


图1-4　基数的符号表示
这个例子中的业务规则是：
每个作者（Author）可以写一本或多本书（Title）。
每本书（Title）必须只能由一个作者（Author）写。
短竖线表示1（看上去像个1，是吧），圆圈表示0（看上去也像个0），0表示可选，但并不排除值1，所以在上面的例子中，一个作者（Author）只能写一本书（Title）。三角形中间有一根线意思是多个（m）。有人把m符号叫作鱼尾纹（crow’s foot）。
关系线上通常有标签用来说明关系和关系所表示的规则。数据模型是一种通信工具，如果你还记得实体是个名词，关系标签就是一个现在时态动词。因此，让我们读下面这句话。
在这里相信有许多想要学习大数据的同学，大家可以+下大数据学习裙： 740041381，即可免费领取套系统的大数据学习教程
每个作者可以写一本或多本书。
每个关系都有一个父实体和一个子实体。父实体出现在关系的1那边，子实体出现在关系的多（m）那边。这个例子中，父实体是作者（Author），子实体是书（Title）。当我读一个关系的时候，我会从关系1那边的实体（父实体）开始。“每个作者可以写一本或多本书。”然后再从关系中多的那端读“每本书必须由一个作者写。”
在读关系的时候，我也总是使用“每个”从父实体那边开始。使用“每个”这个单词的原因是你想要指定一个实体平均有多少个实例与另一个实体的实例相关。
有两种类型的关系：依赖型（identifying）和不依赖型（non-identifying）。依赖型（identifying）关系用实线表示，意思是m一侧的实体（子）总是1一侧的实体（父）的依赖型实体。虚线的意思是m一侧的实体（子）不依赖于1一侧的实体（父）。图1-5是这两种类型的关系。


图1-5　两种类型的关系
不依赖型实体以尖角矩形表示。依赖型实体以圆角矩形表示，如“书”在依赖型关系中的例子。不依赖型的实体是实体的每个实例都只用它自己的属性。例如在不依赖型关系中“书”的例子，可以由ISBN（国际标准书号）找到，ISBN是属于“书”的一个属性。依赖型实体只能通过使用至少一个不同实体的属性找到，如依赖型关系中的书和作者的税号。我们可以改变基数试试，现在允许一本书可以由多个作者写，如图1-6所示。


图1-6　一本书可以由多个作者写
与前面一对多的例子相比，这是一个多对多关系的例子。这里的业务规则是：
每个作者可以写一本或多本书；
每本书必须由一个或多个作者写。
“写”在这两个例子中，都可以当成关系标签。有时候，反向标签也会出现在关系线中，例如由X写。我倾向于只显示一个关系标签以减少模型中的混乱，同时也由于大多数情况我们能用相同的单词结构做反向标签：写，由X写。
有 3 种层级的粒度（概念、逻辑和物理）可应用于实体和属性，也可用于连接实体的关系。概念关系是高层规则或连接概念的检索路径。逻辑关系是详细的业务规则或逻辑实体间的强制规则的检索路径。物理关系则是详细的技术依赖规则或有关系连接的物理结构间的检索路径。这些物理关系可能最终会变成关系数据库管理系统中的数据库约束，或文档数据库（如MongoDB）中的参照关系。
1.5　键 如果数据量很大，如何才能快速找到你要找的数据呢？这就是为什么需要键了。键可以用来创建强制规则，还能高效地检索数据的一个或多个属性，此外可以用来从一个实体检索另一个实体。这一节解释了候选键（主键、替代键）、代理键、外键和第二键。
候选键（主键、替代键）
候选键是一个或多个能唯一识别一个实体实例的属性。例如，给每本书分配一个国际标准书号（International Standard Book Number，ISBN）。ISBN唯一地识别每本书，因此可以作为书的候选键。当把本书的ISBM编号“9781634620826”输入到多种搜索引擎或数据库系统时，结果就返回了本书的实体实例《数据模型记分卡》（你可以试试）。税号可以是一些国家的组织机构候选键，如美国。账号代码可以是账号实体的候选键。车辆标识号（Vehicle Identification Number，VIN）可以识别一辆车。有时候只用一个属性就能识别一个实体实例，例如用ISBN识别书名。有时候却需要多个属性来唯一识别一个实体实例。例如：必须通过促销类型代码和促销开始日期一起来唯一识别一个促销。当多个属性组成一个键时，我们用术语“组合键”表示这种键。因此，促销类型代码和促销开始日期一起构成促销的组合候选键。候选键有以下4个主要的特征。
唯一的。一个候选键一定不能识别出多于一个实体实例（一个真实世界的物品）。
强制的。候选键不能为空，每个实体实例必须由一个候选键标识。所以，候选键的所有不同值的数目总是等于全部不同实体的数目。例如用ISBN作为书的候选键，如果有500个书的实例，那么就有500个唯一的ISBN。
不变的。实体实例上的候选键应该永远不变。
最短的。候选键应该只包含那些可以唯一识别的实体实例的属性。如果有4个属性列出来作为一个实体的组合候选键，但只有3个是标识唯一性所必需的，那么就只需要由这3个属性组成候选键。
例如，每个学生可以学习一门或多门课程，每门课程可以有一个或多个学生。表1-2～表1-4是两个实体的一些简单实例。
表1-2　学生表
学生编号
学生名
学生姓氏
出生日期
SM385932
Steve
Martin
1/25/1958
EM584926
Eddie
Murphy
3/15/1971
HW742615
Henry
Winkler
2/14/1984
MM481526
Mickey
Mouse
5/10/1982
DD857111
Donald
Duck
5/10/1982
MM573483
Minnie
Mouse
4/1/1986
LR731511
Lone
Ranger
10/21/1949
EM876253
Eddie
Murphy
7/1/1992
表1-3　出勤表
出勤日期
5/10/2015
6/10/2015
7/10/2015
表1-4　课程表
课程全称
课程简称
课程描述
数据建模基础
数据建模101
一门介绍性课程，介绍数据建模的基本概念和原则
数据建模进阶
数据建模301
一门技术类的进阶课程，如高级范式和不规则层次结构
网球基础
网球
教网球初学者学习这个游戏的关键方面
杂技
  学习如何能同时保持让3个球在空中
根据我们对候选键的定义（候选键的特征是唯一的、稳定的和最小的），应该选择什么字段作为这些实体的候选键呢？
对于学生实体，学生编号看上去是个有效的候选键。有 8 个学生和 8个唯一的学生编号值。不像学生名和学生姓氏有重复值，如名字 Eddie Murphy就有重复。而学生编号 Student Number 是唯一的。出生日期也有重复值，如5/10/1982，Mickey Mouse和Donald Duck的出生日期都有这个值。学生名、学生姓氏和出生日期这3个字段的组合也像一个有效的组合候选键，但请注意我们不推荐使用这样的键，因为这在某些系统中可能会有问题。
出勤实体，现在缺少了候选键。在这个简单的数据表中尽管出勤日期是唯一的，我们可能需要知道在特定的日期里哪个学生上了哪门课程，所以这个出勤实体的定义是不完全的。
课程实体，初看似乎任何属性都是唯一的，都可以做候选键。然而，杂技这门课程没有课程简称，因此，鉴于课程简称可以为空所以不能当做候选键。此外，候选键的另一个特征是不变性。根据我的教学经验，描述可能会变。因此，课程描述也需要从候选键中排除，只有课程全称才是候选键的最好选择。
尽管一个实体可能有多个候选键，但对于一个实体我们也只能选择一个候选键做主键。主键是从候选键中首选的能唯一标识实体的候选键。替代键是候选的，尽管也有唯一性、稳定性和最小的特点，却不能作为主键，尽管替代键也可以用来查找特定的实体实例。
在课程实体中只有一个候选键，所以课程全称就变成主键。而学生实体需要做个选择，因为它有两个候选键。应该用哪个候选键作主键呢？
选择哪个候选键作为主键，需要考虑简洁和私密性。简洁意味着如果有几个候选键，要选那个属性最少和长度最短的。而私密性，有可能候选键中的一个或多个属性含有敏感数据，查看这样的数据会受限。需要避免实体主键中含有敏感数据，因为主键可能繁衍成外键，因此会将这个敏感数据传播到整个数据库范围。
在我们的例子中如果考虑简洁性和安全性，我会选择学生编号，而不是学生名、学生姓氏和出生日期。因为前者更简洁且含有更少的敏感信息。
这是我们的主键和替代键的数据模型，如图1-7所示。


图1-7　主键和替代键的数据模型
主键属性在矩形框中的横线之上。你会注意到有两个数字跟在键的缩写名“AK”之后，第一个数是替代键的一组数字，第二个数表示替代键中的属性顺序。所以学生实体属性的替代键有3个属性。
学生名、学生姓氏和出生日期。这也是将要创建的替代键索引的顺序，因为学生名在冒号之后有个“1”，学生姓氏是“2”，出生日期是“3”。
出勤实体的主键是学生编号和课程全称，这两个字段看上去可以组成一个有效的主键。注意出勤实体的两个主键属性跟着一个“FK”，这是外键，后面很快会讲到。
所以，简单地说，一个候选键由一个或多个属性组成，能唯一地识别一个实体实例。可以选择能最好地识别实体中每个记录的候选键作主键，其他的候选键则作为替代键。由多个属性组成的键叫作组合键。在物理层，候选键常常转换成唯一索引。
1.6　代理键 代理键是表的唯一标识符，常用来计数，通常具有固定长度，一般由系统自动生成，没有含义。所以代理键没有任何业务含义。（换句话说，不能看到一个月份标识符为1，就认为它代表月份实体的实例值一月）。代理键应该对业务是不可见的，但应该保留在后台以允许更高效的检索，也方便应用之间的集成。
代理键也是高效的。你已经见过主键可能是多个实体属性的组合。相对于必须指定3～4个（或5～6个）属性来定位你要查找的一条记录，使用单个代理键更高效。代理键有利于集成，集成的目的是为了创建一个唯一一致的数据版本。像数据仓库这样的应用常常要保存不止一个应用或系统的数据。一个实体实例在每个源系统中都有不同的标识，这些实体实例的相关性从公共的标识符看起来不太明显，这时用代理键可以记录同一个实体实例的信息之间的相互关系。
使用代理键时，总是先确定自然键。自然键是能唯一识别实体的方式，这是业务要考虑的，然后将自然键定义为替代键。例如，如表1-5所示，假定一个代理键是比课程全称更高效的主键，我们可以为课程实体创建课程编号代理键，在自然键课程全称上定义一个替代键，如图1-8所示课程的值。


图1-8　在自然键课程全称上定义一个替代键
表1-5　课程实体中的课程
课程编号
课程全称
课程简称
课程描述
1
数据建模基础
数据建模101
一门介绍性课程，介绍数据建模的基本概念和原则
2
数据建模进阶
数据建模301
一门技术类的进阶课程，如高级范式和不规则层次结构
3
网球基础
网球
教网球初学者学习这个游戏的关键
4
杂技
  学习如何能同时保持让3个球在空中
1.7　外键 在实体的“1”那侧的关系我们叫作父实体，在“多（m）”那侧的关系叫作子实体。当我们创建一个从父实体到子实体的关系时，父实体的主键就被复制为子实体的外键。外键是一个或多个属性，提供到另外一个实体的链接（也有种递归关系的情况，同一个实体的两个实例是相关的，一个链接连到同一个实体）。在物理层面，外键允许关系数据库管理系统从一个表到另外一个表进行检索。例如，如果我们需要知道一个有账号的客户，我们就想把客户编号放在账号实体中。账号实体中的客户编号就是客户实体的主键。使用外键返回到账号表可以让数据库管理系统从特定的账户检索或者从账号到客户进行检索，再或者找到每个有账号的客户。类似地，数据库可以从特定的客户到账号检索以找到某个客户的所有账号。当两个实体间的关系确定了之后，数据库建模工具就自动地创建了外键。
在学生/课程模型中，出勤实体中有两个外键，学生编号外键指向学生实体中特定的学生，课程编号外键指向课程实体中特定的课程，如表 1-6所示。
表1-6　课程编号外键指向课程实体中特定的课程
学生编号
课程编号
出勤日期
SM385932
1
5/10/2015
EM584926
1
5/10/2015
EM584926
2
6/10/2015
MM481526
2
6/10/2015
MM573483
2
6/10/2015
LR731511
3
7/10/2015
通过查看这些值，回忆起表1-6中的样例数据，我们了解到Steve Martin和Eddie Murphy两人在2015年10月5号都听了数据建模基础这门课。Eddie Murphy还和Mickey Mouse、Minnie Mouse一起听了2015年10月6日的高级数据建模这门课。Lone Ranger在2015年10月7日上的是网球基础（跟往常一样，还是他一个人）。
另外，注意出勤表（Attendance）当前的主键是假定一个学生只能参加一门课程一次。如果业务规则说明一个学生能参加一门课程一次或多次，我们就需要修改出勤表的主键，增加出勤日期（Attendance Date）字段。
1.8　次键 有时候需要从表中快速检索数据来回答业务的问题或满足响应时间的要求。次键是需要频繁访问和快速检索的一个或多个属性（如果有多个属性，就叫作组合次键）。次键也就是众所周知的非唯一索引或反向条目（inversion entry，IE）。次键不必唯一、稳定，也不必非空。例如，我们可以给学生表（Student）增加学生姓氏（Student Last Name）字段作为从键，以允许无论何时需要查询学生姓氏（Student Last Name）都能快速检索，如图1-9所示。


图1-9　给学生表（Student）增加学生姓氏（Student Last Name）字段作为从键
学生姓氏（Student Last Name）不唯一，因为可能有两个人都叫Murphys；它是不稳定的，会随着时间变更；尽管很少发生，但也可能会有我们不知道某人名字的时候，所以，它可能为空。
1.9　子类型 子类型允许将公用属性、相似的关系或相关的实体分组。某些概念非常相似或者为了展示一些例子往往可以用子类型。在出版行业，一个作者可能会写多部纸质版（PrintVersion）的书和多本电子版图书（eBooks），如图1-10所示。


图1-10　一个作者可以写多部纸质版和多部电子版图书的模型
每个作者（Author）可以写一本或多本纸质版（PrintVersion）的书。
每个纸质版（PrintVersion）的书必须由一个作者（Author）写。
每个作者（Author）可以写一本或多本电子书（eBook）。
每本电子书（eBooks）必须由一个作者（Author）写。
接下来，让我们来介绍子类型，如图1-11所示。


图1-11　子类型
每个作者（Author）可以写一本或多本书（Title）。
每本书（Title）必须由一个作者（Author）写。
每本书（Title）可以是纸质版（PrintVersion）或电子版（eBook）。
每个纸质版（PrintVersion）的书都有一个书名（Title）。
每个电子书（eBook）有一个书名（Title）。
子类型关系隐含了一个规则，即超类型的所有关系和属性也应用到每个子类型。因此，从作者（Author）到电子书（eBook）有一种隐性的关系，从作者（Author）到纸质版（PrintVersion）也是如此。titleName、subtitleName和titleRetailPrice属于纸质版（PrintVersion），也属于电子书（eBook）。注意每个子类型的主键是到超类型的外键，所以它们有相同的属性。在这个例子中，titleISBN是一本书的标识符。
子类型不仅减少了数据模型上的冗余，也能透过表面上唯一的和独立的概念从而更容易沟通它们的相似性。
在某些情况下，一个子类型可以有多个子类型集合；例如，一个人可能是一个孩子、青少年或成年人，独立于这些分类，一个人还可能是男性或女性。
在某些情况下，超类型可以没有任何子类型也能存在，而在另一些情况下，却不可以。每个超类型必须有一个子类型实例。
例如，一个人可能是一个司机，或者不是；无论哪种情况他仍然是一个人。但一个银行账号就必须总是某种特定子类型的账号。
[1]　注意：如果使用统一建模语言（Unified Modeling Language，UML）中的类图，就可以指定准确的基数。