如前篇所述，无论古今，在当前数字化转型的大潮中，航空公司无论如何具有行业特色和深度，必然需要将技术牢牢融合到行业业务特色建设中。

数字化变革是一个概念，也是结果。

它需要通过IT手段、IT理念、IT技术、IT应用投入等，将自己的传统构建转化为灵活、敏捷、有活力、有弹性、稳健的“构建块”新生态系统。

同时，用与数字转换最相关的概念，面向C方，需要融合大数据、人工智能等尖端的IT技术。

真正的基础其实是【数据】。 大小、SQL、NoSQL、甚至是Hadoop等。

但是，将数据真正转化为价值，不仅仅是洞察和应用落地方案，还需要数据模型，是最基础的。

业务APP应用、数据集成、主数据管理、数据仓库、大数据、数据湖、机器学习； 这些有共同的基本要素。 是数据模型。

不能忘记，不能无视它！ 数据模型几乎是所有高价值的任务关键型业务解决方案的支柱，从电子商务和销售点，到财务、产品、客户管理、商务智能和物联网。

如果没有合适的数据模型，业务数据在哪里？ 大概： LOST！

数据模型请参照以下公开的说明。 数据模型如下。

业务系统数据的结构定义用于构筑业务数据的图形显示业务解决方案的数据基础https://en.Wikipedia.org/wiki/data _ model

https://en.wikipedia.org/wiki/Data_modeling

https://baike.baidu.com/item/%E6%95%B0%E6%8D%AE%E6%A8%A1%E5%9E%8B/1305623

个人的解释

数据模型是结构的基础，表示为商务信息系统的明确定义的图形特征。

该定义将所有要素包括在一个目的中； 这是一种从结构上识别业务用例相关信息的方法，不仅仅是数据。

今天，大多数企业都使用数据模型来帮助验证需求。 这是真正的商业价值，但我想仔细了解他们是否了解如何正确执行它。

在许多情况下，持久数据模型的假象仅通过假设有这样的事实，而不知道或不确认其是否正确。

作为数据架构和数据库设计的实践者，我看到了很多不好的数据模型。 我必须提出，大多数数据模型可能在某种程度上是错误的。

我看过很多好模型，但我怎么知道数据模型是好是坏？ 为什么我们要在意？ 只要有数据出入，这还不够吗？ 答案很大，不！ 数据模型必须是好的或者好的

确保执行和/或合作的业务系统取得成功。

数据模型是业务的本质，因此必须全面、无可非议、灵活。

因此，拥有良好数据模型的动机很明显。

我认为数据模型是任何软件项目的三个基本技术要素之一。

另两个是APP应用程序代码和用户界面。

数据模型分类

平面模型/平面模型-数据元素的一维或二维阵列

Hierarchical Model /层次结构模型-包含定义父代/子代层次结构的字段和集合的记录

网络模型/网络模型-类似于分层模型，可以使用连接“链接”表映射的一对多关系

Relational Model /关系模型-有限谓词变量集中的一组谓词，用于定义对可能的值和值组合的约束

Star Schema Model /星型模式模型-规范化数值和维表删除数据聚合的低基数属性

使用data vault模型/数据仓库模型Hub、Satellite和link表记录来自多个数据源的长期历史数据

数据模型的商业价值

为什么需要数据模型？ 那个有什么作用？ 不能简单地处理并完成那个吗？ 从技术角度来看，我们依赖数据模型提供操作数据流的结构。

数据模型的生命周期直接影响工作设计、性能和可扩展性。

从技术上讲，这只是冰山的一角。

商业观点可能更抽象。

首先，数据模型验证业务需求。

它为系统集成和业务中使用的数据结构控制提供了重要的定义，并保证了各种功能和操作原则。

如果没有数据模型，业务就会完全没有效率。

数据建模简史

将50年的数据建模历史汇总为约4个短段落：

“计算黑暗时代”用平面记录布局或阵列。 所有数据都存储在磁带或大型磁盘驱动器上，以备以后检索。

但是，在1958年，J.W.Young和H.K.Kent将建模信息系统描述为“用于说明数据处理问题的信息和时间特性的正确且抽象的方法”。

1959年后不久，明尼苏达大学的查尔斯巴贝奇研究所成立了产生标准编程语言的联盟“数据系统语言会议/委员会”。

例如，COBOL和“统一数据库存储”这是20世纪60年代由通用电气/霍尼韦尔设计的早期数据库技术。

查尔斯巴赫曼

由于IDS被证实难以使用，发展为B.F.Goodrich开发的“统一数据库管理系统”，由Cullinane数据库系统销售。

这两种数据建模方法分别称为“分层数据模型”和“网络数据模型”，在未来的50年里，它们在大型机计算中已经很普遍，现在也在使用。

20世纪70年代末，E.F.Codd在IBM与C.J.Date合作时，提出了Codd创新的数据建模理论，并于1970年出版了《大型共享数据银行数据的关系模型》。

Codd于1985年发起的旨在帮助供应商正确实施该方法的运动，发表了他有名的“关系模式的12条规则”。

事实上，13条规则从0到12条；很明显，Codd是他那个时代的电脑怪胎。

关系模型还引入了“规范化”的概念，并定义了“五种正常形式”。

我们中的许多人都在谈论“3nf”或“threerd normal form”，但你知道如何定义它吗？下一个重要的数据建模方法是1996年，

由拉尔夫金博尔在他的开创性著作《数据仓库工具包：维度建模的完整指南》 中提出的。

Kimball广泛采用的“星型模式”数据模型应用了20世纪70年代由W.H.Inmon首次提出的数据仓库范式中引入的概念。

1991年出版的Inmon的“构建数据仓库”已经成为所有数据仓库计算的默认标准。

虽然Inmon和Kimball在数据仓库实现的正确方法上存在一些分歧，但Kimball Group的Margy Ross在其文章“意见分歧”中为您提供了一个公平、平衡的解释，供您考虑。

最近，一种新的数据建模方法已经成为强有力的竞争者。

数据仓库！其作者和发明家丹林斯德特于1990年首次构思了数据仓库，并于2001年向公共领域发布了一份出版物。

数据保险库模型解决了许多相互竞争的inmon和kimball论点，结合了数据的历史沿袭，并提供了一个高度适应性、可审计和可扩展的范例。

一个关键性的改进；linstedt的数据库在国防部、国家安全局和企业项目中被证明是无价的。

2013年，Linsdet发布了面向大数据、NoSQL、非结构化、半结构化数据集成的数据保险库2.0，以及如何使用它的SDLC最佳实践。

行业数据模型将数据模型和建模落地到特定行业，并用行业多年的经验进行提炼和沉淀，变为放诸四海而皆准的行业标准。

例如：

Oracle Retail Data Model

https://www.oracle.com/technetwork/cn/database/options/retail-data-model/index-092719-zhs.html

Oracle Airline Data Model

IATA - Airline Industry Data Model

'Airline Data+’ Airline Industry Enterprise Data Modeling 101

数据库开发生命周期/DDLC一般人们往往将精力完全集中在复杂性和纯粹的数据量上，这很重要。

但是数据模型应该是最重要的部分。

随着需求的发展，模式必须遵循，甚至是领导；无论如何，它需要被管理。

这就需要数据库开发生命周期。

对于每个涉及数据的环境，开发人员都需要适应和调整代码以适应其不可避免的结构变化。

与软件开发生命周期类似，数据库应该包含适当的数据模型设计和最佳实践。

在设计数据模型中，出现了清晰的规则，其中包括：

Adaptability/适应性：创建能够承受增强或修正的schemaExpandability/可扩展性：创建超出预期的schemaFundamentality/基础性：创建提供特性和功能的schemaPortability/可移植性：创建可以托管在不同系统上的schemaExploitation/利用：创建最大化宿主机技术的schemaEfficient Storage/高效存储：创建优化的模式磁盘占用空间High Performance/高性能：创建卓越的优化schema这些设计原则包含了任何选定建模方法的本质，

但是不管如何，个人认为数据模型只有三个生命阶段：从摇篮到坟墓：

A Fresh INSTALL/全新安装： 基于当前schema的版本Apply an UPGRADE/应用升级：将数据库对象从一个版本升级到下一个版本Data MIIGRATION/数据迁移：发生破坏性的“升级”时设计数据模型可能是一项“需要兴趣”的劳动，

其具有挑战性的模式，寻找裂缝和裂缝来纠正，这些裂缝通常以各种方式呈现。

例如：

复合主键：尽量避免它们，很少有效或合适；根据数据模型，有一些例外坏的主键：通常是日期时间和/或字符串不合适坏的索引：要么太少要么太多列的数据类型：当只需要一个整数时，不使用长整型，尤其是在主键上。

存储分配：不考虑数据大小和增长潜力循环引用：当表A与表B有关系，表B与表C有关系，表C与表A有关系时，这是最简单的坏设计考虑一个数据库设计最佳实践：数据模型的设计和发布过程。

在构建数据模型时，应该遵循与此类似的规定流程：

很明显，虽然schema更改是不可避免的，但是在任何软件开发项目中尽早获得可靠的数据模型是必不可少的。

毫无疑问，将对应用程序代码的影响最小化对于交付成功的软件项目是可取的。

Schema更改可能是一项昂贵的工作，因此了解数据库的生命周期及其作用变得非常重要。

对数据库模型进行版本控制至关重要。

使用图表说明设计。

创建“数据字典”或“词汇表”，并跟踪历史更改的沿袭。

这是一个需要严格执行的纪律，但它是有效的！

数据建模方法论了解数据模型的历史和设计它们的最佳过程只是起点。

作为事务性和分析性模型的数据库架构师，前面的三个步骤代表了大约80%的工作。

有时数据模型很简单，通常是因为简单和/或身材小。

数据模型也可能非常困难，通常是由于数据的复杂性、多样性和/或纯粹的大小和形状，以及在整个企业中使用数据的许多地方。

应该尽早了解数据是什么和在哪里，它是如何受到影响的，或者是如何影响使用它的应用程序和系统的，以及为什么它首先存在。

让头脑围绕着谁需要什么以及如何实现它是一个挑战。

将其映射出来以确保一个可靠的数据模型是目标。

选择正确的数据建模方法至关重要。

数据建模最佳实践许多数据模型都是使用一个流程设计的，在这个流程中，建模者创建一个逻辑模型，然后创建一个物理模型。

通常，逻辑模型描述实体和属性以及绑定它们的关系，从而提供数据的业务目的的清晰表示。

然后，物理模型将逻辑模型实现为表、列、数据类型和索引，以及简洁的数据完整性规则。

这些规则定义主键和外键以及默认值。

此外，还可以根据需要定义视图、触发器和存储过程来支持实现。

物理模型还根据大多数主机系统提供的特定配置选项定义磁盘上的存储分配。

然而，我曾多次就逻辑模型和概念模型之间的区别展开激烈的辩论。

许多人向我建议它们是相同的，既表示业务数据的实体又表示业务数据的属性。

概念模型旨在提供有关数据的业务理解的上下文，而不是技术性的上下文。

所有利益相关者都可以理解概念模型，并与实体和属性进行许多斗争。

我相信概念模型，做得对，是最好的工具沟通有关业务数据的每个人参与。

我更喜欢使用统一建模语言的各个方面作为我绘制概念模型的方法，并保持其简单，而不是陷入细节的泥潭中。

我将把它留给逻辑和物理模型，在这些模型中，这些细节是必要的和精确的。

企业业务通常具有大量的应用程序系统，在建模数据时引入了更高级别的关注。

即使是概念模型、逻辑模型和物理模型也远远不够。

这里引入【整体数据模型/The Holistic Data Model】：整体数据模型的目的是识别和抽象整个企业中的数据仓库，

从而描述存在的或需要的内容、它们之间的关系以及如何在最高级别组织它们以最有效地使用它们。

4个数据建模的过程层次如果未一个企业建设4种不同类型的数据模型，遵循如下从顶到下的数据建模过程，以层次化的方式来实现。

同时每个层次涉及不同的关键角色和资源。

整体数据模型/Holistic Data Model

整体层表示整个企业中数据仓库的抽象布局。

此数据模型创造了建立广泛业务数据治理的机会，从而能够更好地理解企业固有的所有数据关系。

它们旨在合并来自任何应用程序的数据。

可以使用气泡图来绘制整体数据模型：

气泡图-Data Silos

气泡图是简单的气泡组成，代表独特的数据仓库。

连接两个气泡的线表示它们之间存在某种关系。

从根本上讲，每个气泡集合都体现了一组特定的跨企业识别的数据孤岛；不多也不少。

以下是一些规格详细信息：

蓝色的链接表示两个数据仓库之间的直接关系。

红色虚线链接表示两个数据仓库之间的间接关系。

点绿色链接表示两个数据仓库之间的扩展关系。

主观地使用这些链接，因为它们可能表示多个关系。

简单地说，它们定义了一种关系的存在。

有时气泡被较大的气泡包围。

这些较大的气泡表示存在一个本体组织一个特定于该数据竖井的分类。

本体及其分类元数据提供到它所环绕的思洛存储器的有意义的映射。

这对于使数据高度可搜索非常有用，应该在这个层中进行标识。

气泡图定义特定的业务信息集合。

其目标是识别、简化和合并可能支持的任何应用程序、实现或技术细节中没有的信息。

整体数据模型的优势在于，所有受众都可以从一个全面而简单的角度了解企业数据环境，为识别和插入任何新数据提供了灵活的起点，并且对基础数据模型的干扰有限或可能没有影响。

下面是一个完全定义的整体数据模型的示例。

把它们印在大打印机上，然后贴在墙上。

许多富有成效的对话都可以用来检查这些内容，并成为企业的一项有效、有价值的资产。

概念数据模型/Conceptual Data Model

概念层表示业务数据元素及其关系的抽象定义。

该数据模型从应用程序的角度定义了企业数据环境的语义，从而能够更好地理解底层业务信息。

UML提供了设计这个模型的图形化方法。

概念数据模型由元素对象组成，定义了一个从整体模型中的数据仓库派生的信息类。

从本质上来说，可以把它看作一个信息模型。

UML信息架构

每个元素对象封装数据竖井的特定部分和连接线，这些连接线定义两个元素之间的特定关系。

特定的元素项被定义为进一步帮助理解和目标。

它们可以是：

受保护/Protected公共/Public司有/Private直接相互连接的元素对象被视为具有某种“关联”，用一个坚实的灰色链接和有目的的标签表示。

这些关联使用父元素上的菱形符号表示以下关系：

简单共享复合材料子元素也可以是“可导航”的，由进一步用关系基数标识的箭头符号表示。

元素对象也可以具有“归纳”，也就是说，对象的实例可能具有某些特定或唯一的特征和/或关系。

在这种表示中，对象更像是一个父元素的子类，包括它的所有特征以及所涉及的任何其他独特特征。

子类元素在其名称和表示形式上都进行了改进，以对抽象的整体数据竖井提供可理解的改进。

与元素对象相关的一般化用纯蓝色链接表示，该链接具有一个附加到父对象的闭合箭头，不需要标签。

子类之间的连接进一步定义了在理解它所表示的概念数据模型时有用的关系。

与同一父对象的其他广义子类相连的广义子类被视为具有用实心绿色链接和有目的的标签表示的“关联”。

这些关系可以选择是“可导航”的，由一个开放箭头符号表示，然后用关系基数进一步标识。

完成UML图后，元素可以有自连接的关联，这些关联是扩展父对象定义的特定特征，和/或特定特征之间的“关联”。

特定的扩展并不表示类或泛化，而是标识为更好地理解抽象数据竖井而调用的相关特性。

特定特征与元素之间的连接用一个实心的红色链接和一个有目的的标签表示。

此外，元素特征可以连接到同一父对象的其他元素特征，用类似于相关归纳的绿色链接表示。

这些关系也可以是“可导航”的，用可选的开放箭头符号表示，然后用关系基数进一步标识。

概念数据模型使用基于类的隐喻来描述特定的数据元素，最好使用UML来绘制图表，这进一步解释了抽象的整体数据仓库。

此目标是定义、优化和减轻业务信息，这些信息对任何应用程序、实现规则或技术细节仍然不可知，并且还封装整体模型中遗漏的细节。

同样，把它打印出来，注意这个模型代表了一个公共接口，在这个接口上，不需要遵循逻辑或物理数据模型就可以编写应用程序代码。

这一优势还可以提供一个验证点，在这个验证点之前，这些后续的数据模型是精心设计的。

利用软件工程和涉众验证UML模型是数据建模过程中的一个关键里程碑。

下面是一个示例，说明一个概念数据模型的选择可能是什么样子的。

请注意，该模型具有“子元素”，它定义了“主元素”的特定方面，阐明了独特和重复出现的特征。

逻辑数据模型/Logical Data Model

逻辑层表示一种抽象的语义信息结构，按照域实体、它们的属性以及它们之间的特定关系进行组织。

此数据模型源自概念模型的元素对象，定义相关的细节以及实体之间的关系，而不考虑任何特定的主机存储技术。

实体可以表示单个元素、元素的一部分或多个元素，以封装合适的数据结构。

逻辑数据模型封装了概念模型中标识的结构实体和记录集，添加了特定的属性，从而能够更好地理解所涉及的数据。

ERD/实体关系图

实体关系图或ERD描述了能够独立存在的唯一可识别实体，而独立存在又需要一组称为主键的最小唯一识别属性。

如果子实体链接到某个父实体，则可以并且应该通过在子实体中使用与父主键属性）匹配的标识属性来强制引用数据完整性。

但你们都知道这些。

在适当的情况下，实体可以链接在一起，说明记录集的性质，或者两个或多个实体之间的基数关系。

具有链接的实体可以使用广泛用于实体关系图的Crow's Foot表示技术。

由纯蓝色链接表示，两侧适当的Crow's Foot符号还应包括一个有目的的标签来描述它所代表的记录集。

这些实体链接呈现特定的基数，解释了记录集的允许记录计数。

这些符号可以指定：零行、一行或多行或某些强制组合。

基数只有两条规则：可以参与关系的每个实体的最小和最大行数，其中最接近该实体的符号是最大计数。

为记录集指定基数还表明关系是可选的或强制的，这有助于物理数据模型的设计。

ERD可以支持到多个实体的链接，包括自连接链接。

实体也不应混淆为表，但通常可以直接映射到物理数据模型中的表。

相反，逻辑实体是关注概念数据模型的简化表示的结构抽象。

逻辑数据模型呈现了概念数据模型的语义抽象，提供了可以从中设计物理数据模型的细节。

这一优势还可以帮助应用服务工程师和数据库工程师了解抽象的数据结构以及数据事务的需求。

下面是一个逻辑数据模型选择的示例。

注意这里的一些事情。

我使用颜色来表示不同的功能区域，这些功能区域可以映射到概念模型和整体模型。

我还整合了实体D和实体C之间的“虚拟”关系。

这表明存在逻辑关系，但是这两个实体之间的结构加上实体_B表示一个“循环引用”，这是物理模型中完全避免的一个问题。

还要注意，有一些属性定义了一个值数组。

在逻辑模型中，这是可以的，因为它简化和简化了模型；只需确保在物理模型中规范化它们。

物理数据模型/Physical Data Model

物理层表示从逻辑数据模型派生的主机系统工件及其所需的存储配置的组合。

此数据模型包含表、列、数据类型、键、约束、权限、索引、视图以及有关数据存储区上可用分配参数的详细信息。

这些主机构件表示构建软件应用程序所依据的实际数据模型。

物理数据模型封装了逻辑数据模式中定义的实体和属性中的所有这些工件，最终使应用程序能够访问存储和检索实际数据。

SDM/Schema Design Model

物理设计模式或SDM定义了数据库信息系统中涉及的特定对象。

我更喜欢称它为SDM，这样它就不会被更广泛使用的术语ERD混淆，后者不是物理数据模型。

相反，SDM提供了一个工程参考，通常用图形图和数据字典文档记录。

为SDM中实现的每个数据库对象提供关键的、详细的引用，本文档应包含它们的目的、引用完整性规则以及有关任何预期行为的其他重要信息。

这里有一个好的结构：

Object Name Definition (Tables/Views)SQL object creation/modification filenameBusiness Domain Functional UtilizationVersion/Integrity LevelColumns/Datatypes/SizeNullabilityDefault ValuesPrimary KeysForeign KeysNatural Business KeysUnique ConstraintsCheck ConstraintsUnique Non-Unique Indexes (Clustered Non-Clustered)Control Flows (when extra complexity design/use is involved)Useful CommentsChange History为了便于使用，

由于大多数物理数据模型都是高度规范化的，所以应该为每个表调用引用完整性规则。

基于实际经验，许多处理这些规则的方法，特别是在对现有模式执行SQL对象脚本时。

只需关闭完整性检查，运行脚本，然后重新启动Works；但这种方法容易出错。

相反，花时间理解对所有表的特定引用，并为每个表分配一个完整性级别。

表“完整性级别”标识父/子表关系的层次顺序。

简言之，表的“完整性级别”基于对父表的任何外键引用。

例如：

没有父表的表：是l0-或0级具有至少一个父表的表：是一级或一级具有至少一个父表但该父表具有l0父表的表：是二级或二级表具有多个父表且父表具有不同级别的父表的表，使用的是最低级别+1即：父表A是l0，

父表B是l1，因此子表是l2。

或者：父表A是一个l1，父表B是一个l4，所以子表是一个l5等等注：L0是最高级别，因为没有父表；最低级别由物理数据模型确定。

这种方法还消除了创建循环引用的可能性。

物理数据模型是实际实现的模型。

我更喜欢使用SQL对象创建脚本或SOC来实现这一功能。

使用这种方法，我发现任何物理数据模型的DDLC都可以作为一个独立的过程进行解耦，这是非常理想和难以实现的。

其思想是为一个主数据库对象创建一个SOCS文件。

这些脚本包含智能检查，以确定要应用哪些SQL语句，并且可以通过在我以前的博客中讨论的生命周期中传递的开关和参数来确定，这些参数包括：

基于架构的当前版本的新安装应用升级drop/create/alter db对象将一个版本升级到下一个版本发生破坏性“升级”的数据迁移这些SOCS文件也包含最佳实践，其中包括：

一致的命名约定表名全部大写列名称全部小写查看名称所有驼色大小写SOCS文件名包含对象名使用适当大小的整数的单列主键消除冗余/重复数据消除所有循环键引用每个对象一个SOCS文件SOCS文件包含与此数据字典匹配的一致的头/目的/历史节SQL格式化提供可读性和可维护性数据模型是艺术创造对这些层的简要总结有助于理解它们的目的、它们在建模过程中如何支持和区别。

看一下这张表：

数据模型及建模来自于生活，来自于生活的抽象和提炼，更将最美的艺术呈现给生活！