哪些数据模型

老实说，对数据模式进行分类相当复杂。
根据应用层次，主要分为三种类型。

概念模型是用户能够理解和使用的模型。
比如E-R模型，或者扩展的E-R模型，以及面向对象模型。
这些模型主要帮助人们理解数据是什么样的，与所使用的具体系统无关。
这是设计数据库的第一步。

逻辑模型更加真实。
它由数据库系统直接使用。
我们不仅要考虑用户想要什么，还要考虑系统如何实现它。
常见的包括网络模型、层次模型以及最重要的关系模型。
关系模型使用表来表示数据，这基本上就是现在使用的。
老实说，网格和分层模型现在已经很少使用了。

物理模型，我没有详细讲。
主要是数据如何存储，比如存储结构、索引等。
这取决于具体的硬件。

根据仓库数据，维度模型很常见。
例如，在星型模型中，事实表之间直接链接维度表；雪花图案以星形图案为基础，维度表还与其他维度表相链接；星座模型是星型模型的增强版本，多个事实表共享维度表。

还有一种范式模型，就是ER模型。
它是从公司整体的角度来设计的，并开发了3 NF模型来使用实体和关系来描述业务。
DataVault 模型是 ER 模型的变体。
主要从事数据集成，分为Hub、Link、Satellite三部分。
Anchor 模型，顾名思义，非常强大。
它在6 NF中被标准化，基本上成为一个键值对，但说实话，企业用得不多。

常见的数据库模型包括分层、网络、关系和面向对象。
关系模型是最流行的，用表来表示数据，做关系代数等。

数据库的类型有哪些？

分层数据库具有树形结构，只能查询特定路径，就像早期的IBM IMS系统一样。
网状数据库的根节点较多，实际中很少使用。
现在它们基本上已经过时了。
关系数据库使用SQL； ACCESS适合小公司，Oracle是大公司的选择。
MySQL 是免费且开源的，在网络上广泛使用。
称一下体重。

常见的三种数据库数据模型是什么

你好，这个数据库模型对于我刚入行的时候来说确实是个大问题。
给大家讲讲我曾经踩过的坑。

层次模型，说白了就是树形结构。
我记得当我刚开始工作时，我的公司使用旧系统来管理库存。
产品分类采用树状形式。
例如，“电子产品”分为“手机”和“电脑”，然后下面列出了具体型号。
如果要勾选“所有手机型号”，就得逐层查找，或者从叶到根查找，相当麻烦。
优点是结构清晰，但是如果要增加新的类别，就得改变整个树，扩展性其实很差。
而且你想一想，如果有好几种类型的“手机”，很多信息要重复输入，肯定会出现冗余。
当时感觉这个东西适合层次特别清晰、改动很少的数据。

网格模型听起来很复杂。
我从未见过它实际使用过。
一般的印象是一个节点可以连接很多节点形成一个网络。
感觉比层次模型更灵活，可以处理多对多，但是结构太乱，肯定会很难维护。
指针操作等听起来很容易出错。
这是我想用的一个项目，但最后发现太复杂而放弃了。

关系模型现在无处不在。
如果使用微信或者支付宝，后台必须是关系型数据库。
用户信息是一个表，订单信息是一个表，它们都与用户ID相关。
这个东西是最实用的。
你可以检查任何东西。
您可以通过输入SQL语句找到所需的信息。
该设计还考虑了标准化，减少冗余，易于扩展。
像 MySQL 和 Oracle 这样的东西都是关系型的。
当我学习SQL的时候，真是痛苦又欣慰。
现在想来，这次攀登还是值得的。
从性能上来说，真的要看索引设计得好，不然肯定会慢。

总的来说，现在应用最广泛的是关系模型，主要是因为它使用方便，逻辑清晰。
分层模型和网格模型现在主要由遗留系统或特定场景使用。
如果你现在正在找工作，你必须了解关系模型。
只有另外两人明白。
只是在面试时不要感到困惑。