数据模型和数据建模方法自开始以来就存在

好吧自从无论如何开始计算，数据需要结构以便理解它并为计算机提供一种处理其位和字节的方式，当然今天我们也处理非结构化和半结构化数据，但是对我而言，这仅意味着我们已发展到比计算机前辈所必须处理的更为复杂的范例，因此数据模型仍然存在，并为我们构建高度高级的业务应用程序提供了基础，我们必须认真对待数据模型和建模方法。

关于数据模型的简要历史课

在“计算黑暗时代”中，我们使用了平面记录布局或数组；所有保存到磁带或大磁盘驱动器上的数据，供以后检索。然而，在1958年，  JW Young和HK Kent  将建模信息系统描述为“ 一种指定数据处理问题的信息和时间特征的精确而抽象的方式 ”。1959年不久   ，明尼苏达大学的Charles Babbage研究所成立了CODASYL  或一个“ 数据系统语言会议/委员会 ”，该联盟  导致了COBOL和“ 集成数据存储 ”（IDS）等标准编程语言）; 一种早期的数据库技术，由Charles Bachman在1960年代在GE / Honeywell设计  。事实证明，IDS难以使用，因此它演变成 由Cullinane Database Systems（由美国航空航天公司，当时是今天的轮胎公司）在BF Goodrich开发的“ 集成数据库管理系统 ”（IDMS）。  现在由Computer Associates拥有）。在接下来的50年中，这两种分别称为“ 层次数据模型 ”和“ 网络数据模型 ”的数据建模方法在大型机计算中都非常普遍。您今天仍然可以找到它们。哇！

在1960年代后期，EF Codd  在IBM工作期间，  与  CJ Date  （《数据库系统概论》的作者）合作，绘制了Codd的创新数据建模理论，从而出版了《大型共享数据库的数据关系模型》。 1970年，科德（Codd）的确保供应商正确实施该方法的运动于1985年发表了他著名的  “关系模型的十二条规则 ”。实际上，十三个规则编号为零到十二；而十个规则编号为零。显然，科德是当时的计算机极客。 关系模型还引入了“ 规范化 ” 的概念，并定义了“ 五个范式”'。我们很多人谈“3NF”或“ 3 次  范式 ”，但你知道如何界定呢？阅读这两个链接，了解您是否真的知道自己的想法。会有一个测验！不……

下一个重要的数据建模方法学是Ralph Kimball  （已退休）在1996年提出的，该方法是  由Margy Ross合着的突破性著作《数据仓库工具包：维建模的完整指南》。Kimball广泛采用的“ Star Schema ”  数据模型应用了数据仓库范式中引入的概念，该概念于1970年代由WH（Bill）Inmon首次提出   （在2007年被Computerworld评选为计算机领域前40年影响力的十个人之一） 。Inmon的构建数据仓库”，1991年发布，已经成为所有数据仓库计算的事实上的标准。尽管Inmon和Kimball在采用正确的数据仓库实现方法方面存在分歧的历史，但Kimball Group的Margy Ross在她的文章“ 观点差异 ”中提出了一个公正而平衡的解释，值得您考虑。

近一种新的数据建模方法已经成为强有力的竞争者数据仓库！

数据的历史沿袭，并提供了高度适应性强，可审核且可扩展的范例，重大改进什么是“数据仓库”，为什么我们需要它？NoSQL，非结构化，半结构化数据集成以及SDLC关于如何使用它的实践。我会说是的时机。

数据模型摘要

历史上，各种数据建模方法的快速摘要包括：

1、平面模型  -  数据元素的二维二维数组

2、层次模型 -  包含定义父/子层次的字段和集的记录

3、网络模型  - 与分层模型相似，允许使用结点“链接”表映射进行一对多关系

4、关系模型 - 谓词集合的有限谓词集合，这些谓词变量受可能值和值组合的约束而定义

5、星型模式模型 - 归一化的事实和维度表删除了数据聚合的低基数属性

6、数据仓库模型  — 使用集线器，卫星和链接表记录来自多个数据源的长期历史数据

今天的对话似乎完全集中在复杂性和庞大的数据量上

很重要，可以肯定，但是我想再次提醒您，数据模型应该是讨论的重要组成部分，随着需求的发展，模式（数据模型）必须遵循或什至起步；无论如何，都需要对其进行管理，因此，我向您提交数据库开发生命周期！对于涉及数据的每个环境，开发人员都需要适应和适应代码以适应其不可避免的结构变异。与软件开发生命周期相似，数据库应包含适当的数据模型设计和实践。在我设计的众多数据模型中，出现了明确的戒律，其中包括：

1、适应性  —  创建可承受增强或纠正的架构

2、可扩展性  -  创建超出预期的架构

3、基本原理  - 创建可交付特征和功能的架构

4、可移植性 -  创建可在不同系统上托管的架构

5、开发 -  创建可化主机技术的架构

6、高效存储 - 创建优化的架构磁盘占用空间

7、高性能 -  创建出色的优化架构

这些设计规范融合了任何所选建模方法的本质，其中一些与其他方法矛盾

以我的经验，无论这些二分法如何，数据模型只有三个生命阶段，从摇篮到坟墓：

1、全新安装  - 基于架构的当前版本

2、应用升级 - 删除/创建/更改dB对象，将一个版本升级到下一个版本

3、数据迁移 — 发生破坏性的“升级”（如拆分表或平台）

4、设计数据模型可能是一件令人费解的工作，需要对繁琐的细节进行繁琐的关注，再加上模糊性的创造性抽象，我个人喜欢具有挑战性的方案，因此我寻找可以纠正的裂缝和缝隙，这些裂缝和缝隙常常以各种方式表现出来。例如：

1、χ复合主键可 避免使用，很少有效或不合适；根据数据模型有一些例外

2、χ错误的主键 通常不适合日期时间和/或字符串

3、χ错误索引 要么太少要么太多

4、χ列数据类型 仅在需要整数时不使用，尤其是在主键上

5、χ存储分配 不考虑数据大小和增长潜力

6、χ循环引用 ，其中表A与表B有关系，表B与表C有关系，表C与表A有关系-这简直是错误的设计

让我们考虑一下数据库设计的实践：数据模型的设计和发布过程。我认为，在制作数据模型时应遵循与以下类似的规定流程：

也许对于大多数人来说都是不言自明的，但让我强调采用这一过程的重要性。虽然不可避免要进行模式更改，但在任何软件开发项目中尽早获得可靠的数据模型至关重要。毫无疑问，对交付成功的软件项目而言，对应用程序代码的影响无疑是小的。模式更改可能是一个昂贵的提议，因此了解数据库生命周期及其作用变得非常重要。对数据库模型进行版本控制至关重要。使用图形图说明设计。创建一个“ 数据字典 ”或“ 词汇表 ”并跟踪沿袭历史变化。这是一门更高的学科；但是有效！

数据建模方法

了解数据模型的历史以及设计它们的过程只是一个起点，作为事务模型和分析模型的数据库架构师  ，我发现上述前三个步骤约占工作量的80％，因此让我们接下来考虑一下，有时由于简单和/或身材矮小，数据模型很容易，数据模型也可能非常困难，通常是由于数据的复杂性，多样性和/或巨大的大小和形状以及整个企业中使用数据的地方，我相信我们应该尽早了解数据的范围和位置，数据如何受到使用该数据的应用程序和系统的影响或影响，以及为什么它首先存在，挑战是谁需要什么以及如何交付它，映射它以确保可靠的数据模型是目标，选择正确的数据建模方法至关重要。

 客服热线：400-050-6600

商业联合会数据分析专业委员会