常用的数据模型包括哪些

这三个型号基本上已经不再使用了。

分层模型类似于树结构。
IMS是典型的。
快速访问和轻松设置。
但扩张是困难的。

网络模型是多对多的关系。
DBTG 是典型的。
这意味着关系良好但复杂。

关系模型使用表。
结构灵活，易于查询。
现在就用这个​​。

自己掂量一下。

什么是逻辑数据模型

数据库设计相当复杂。

逻辑数据建模，说白了，就是弄清楚数据是什么样的以及它们之间是如何关联的。
无论以后使用什么软件或者存储方式，都必须先纠正这个逻辑。

当我刚进入这个行业时，老板告诉我不要担心具体的事情，而是先把关系画清楚。
当时我很困惑，后来发现老大说得对，不然以后改起来就太麻烦了。

例如，在 2 02 2 年我们的项目将使用关系模型，它由表格表示。
公司在北京，我们项目的数据量不大，只有几万条记录，但是关系还是比较清晰的。
客户、订单和产品这三个表通过ID链接起来。
哪位顾客购买了哪款产品一目了然。

实体和属性是非常重要的概念。
例如，“客户”是具有“客户 ID”、“客户姓名”和“电话”等属性的实体。
客户 ID 是唯一的，这就是实体完整性。
如果你有两个客户具有相同的客户ID，那肯定不行，数据也会乱。

关系也是决定性的。
还是用客户、订单、产品的例子，“客户”和“订单”的关系是“一个客户可以下多个订单”。
这种关系必须在逻辑模型中清楚地表达出来。
例如，使用外键，“订单表”中有一个“客户ID”，它指向“客户表”。

限制是必不可少的。
参照完整性是“订单表”中的“客户ID”，对应的记录必须存在于“客户表”中。
如果在“订单表”中插入不存在的“客户ID”，数据库就会报错。
这保证了数据的一致性。

常见的模型有层次模型、网络模型、关系模型和面向对象模型。
2 02 2 年，我们的项目将使用关系模型。
层次模型就像一棵树，有点像组织结构图。
具有许多关系的网络模型，就像蜘蛛网一样。
面向对象的模型比较复杂，适合有继承、封装等概念的人。
我们的项目无法使用它。

关系模型，简单来说，就是一张表。
每行一条记录，每列一个属性。
现在大多数数据库都使用关系模型。
像MySQL、Oracle等。
优点是直观、易懂。
画个ER图，什么关系就一目了然了。

我对面向对象模型没有太多了解。
可能我比较极端，觉得太复杂，在一般业务场景下没有必要。

所以，逻辑数据模型就是先画一个蓝图，弄清楚数据是什么样的，有什么关系。
后面怎么实现，用哪个数据库就是另外一回事了。
您需要先纠正逻辑，然后才能进行下一步。
我们2 02 2 年在北京的项目使用了具有数万位数据的关系模型，并且效果非常好。