数据库第一章-基础知识学习

数据库基础知识和概念

1、数据：在数据库的学习中，数据与其语义是不可分的。如果脱离了语义（含义），那么数据就没有任何意义。

例一：数据库存储的某个二维表格中，有这样一行数据：

12001，马应龙，25,4500，500

单独看这样一行，你完全不知道这些信息什么意思。12001是学号？还是登录公司系统的员工账号？还是奖金工资？马应龙是某个人的真实姓名？还是某个作家的笔名？还是那个知名的痔疮膏的商品名？25是岁数？还是考勤打卡次数？还是商品的今日销量呢？4500和500也是如此，一个单独的数据有几乎无数种解释方式，单看它我们完全一头雾水。因此，我们必须知道这条信息中每个数据对应的背景信息，才能知道它代表什么。这里的背景信息，专业术语叫做语义描述。

以下是XX公司2月员工工资明细表（节选）。表头给出了语义信息。我们现在知道了12001是员工编号，马应龙是人名，25是年龄，4500是工资，500是奖金。

员工编号 (Employee_ID)	姓名 (Name)	年龄 (Age)	基本工资 (Base_Salary)	绩效奖金 (Bonus)
12001	马应龙	25	4500	500
12002	李小力	32	6000	1200
12003	张景	28	5500	800

因此：数据是用于承载的肉体，语义是它的灵魂。两者缺一不可。

2、相关的专业术语引入：

表table：一张二维表，有行有列。

属性Attribute：表中某一列的名字（即列标题/表头），描述了该列数据的含义。

域Domain：属性允许的取值范围。

元组tuple：表中除了表头之外的某一行。

关系relation：表中的所有元组（即属性行之外）的集合。

1、例一的XX公司2月员工工资明细表（节选），这个表（table）为什么这里要强调二维表呢？难道还有三维甚至n维的表？有的。在"关系型数据库"（如 MySQL, Oracle, SQL Server）理论中，没有"三维表"，只有"二维表"。但是，在"多维数据库"（用于数据分析的 OLAP 系统）以及某些特定的业务场景中，确实存在"三维"甚至"N维"的数据结构。我们这里学习的是关系型数据库，因此后续表格全部都默认二维，不再强调。

2、属性：例一的属性就是第一行的表头。属性Attribute在 SQL 或日常口语中，通常也直接称为 Column 或 Field

3、域：如实数域，正整数域，长度不超过20的字符串域，年龄域（0~150）等。他们都规定了严格的取值范围。

4、元组：表中的某一行所有的数据。如例一中的：12001，马应龙，25,4500，500是一个元组。这5个信息一个也不能少。在严格的关系模型理论中，元组的每个分量都必须有值（不允许为空/NULL）。但在实际的工程数据库（如 MySQL）中，允许使用 NULL 来表示某个属性值缺失或未知。

5、关系：表中的所有元祖（即所有行）的集合。上述列出的XX公司2月员工工资明细表（节选）并非一个完整的表，因此只是关系的一个子集。

3、数据库，数据库系统，数据库管理系统，数据库管理员：

举一个大型现代化图书馆的例子说明：

（1）数据库 (DB) = 书架上摆放的实体书籍。它是核心资产，是真正存东西的地方。如果指单个的数据集合，用 database ；如果是指多个数据集合，就用 databases 。

（2）数据库管理系统 (DBMS) = 图书馆的自动化检索与借阅系统（软件）。书不能乱拿，你需要一套软件系统来帮你查书在哪、办理借还、登记谁借了什么。

（3）数据库管理员 (DBA) = 图书馆馆长。他是人。负责决定买什么书、怎么分类、给谁办借书证、系统坏了怎么修。

（4）数据库系统 (DBS) = 整个图书馆大楼及其运转体系。它不仅包含书（DB）和软件系统（DBMS），还包含馆长（DBA）、读者、大楼建筑、电脑硬件等。它是一个最宏观的整体。

上述例子虽然便于理解，但是在进行定义和描述中需要更精确且清晰的描述：
1、数据库DB：长期存储在计算机内、有组织的、可共享的大量数据的集合。它本质是数据的"仓库"。如你在SQLserver里创建的一个名为 school_db 的库，里面存着学生信息、成绩等，这个库本身以及里面的数据就是 DB。
注意：数据库DB可以简单理解为存储数据的"仓库"，但它和数据仓库DW（Data Warehouse）这个独特的术语不是一码事：
DB：支撑日常业务运转（如：淘宝下单、微信发消息、银行转账）。关注"把当前的事情做好"。高频的"增删改查"。每次操作涉及的数据量很小（比如修改某一个人的密码）。要求响应时间在毫秒级。数据直接来源于用户的实时输入（如键盘敲击、扫码枪）。
DW：辅助管理层决策分析（如：分析用户画像、预测明年销量、生成年度财报）。极少修改和删除，主要是"海量查询"。每次查询可能涉及几千万行数据的聚合计算（如求全国总销售额）。关注"从历史数据中找出规律"。数据来源于各个分散的数据库 (DB)，经过清洗、转换后搬运过来。因此DW和DB就像是上下游的"供应链"关系。

"我电脑里装了个 MySQL，建了个数据库。" ------ 这指的就是 Database (DB)。
"我们公司建了个数据仓库。" ------ 这意味着公司搭建了一个庞大的大数据平台（如 Hadoop, Hive, ClickHouse, Snowflake），用来做商业分析。

2、数据库管理系统 (Database Management System)：是位于操作系统和用户之间的一层数据管理软件。

DBMS 提供了SQL 语言，并能科学地组织存储数据、提取数据、以及保证数据安全的手段。没有它，用户只能用代码直接去读写硬盘上的数据文件，极其危险且低效（每个用户都可能读到或者损坏非他本身权限的数据）。DBMS
通过"事前防范、事中控制、事后审计"的机制来保护数据安全：

一、 密码制度：保障身份真实性与数据机密性
（1）最外层的安全保护措施：用户标识与鉴别（身份认证）。当用户尝试访问数据库时，系统会通过口令或强身份认证技术（如结合数字证书、智能卡、指纹或多因素认证MFA等）来验证用户的真实身份，防止非法用户入侵。
（2）中间层：在客户端与数据库交互的过程中，DBMS支持通过传输层安全协议（TLS/SSL）对数据进行加密传输，防止密码和敏感信息在网络传输过程中被窃听或篡改
（3）内层：密码加密与安全存储。现代 DBMS 默认情况下，绝大多数数据依然是以"明文"（或可逆的编码/压缩格式）存储的。但是其中的"用户密码"这类非常重要的数据的存储，使用哈希算法加随机盐值（Hash + Salt）的单向存储方式，或者使用对称/非对称加密技术处理。这确保了即使数据库被攻击，数据被窃取，攻击者也无法轻易还原出原始密码，尽最大程度保护了用户的重要信息。

二、 权限制度：管控操作边界与最小化风险
权限制度的核心是解决"你能做什么"，确保经过身份认证的用户只能在规定的范围内操作数据。
DBMS通过数据控制语言（DCL）实施严格的授权管理。管理员可以为用户分配不同的角色和权限，控制粒度可以从大到小分为数据库级、表级、行级甚至列级2。例如，普通员工可能只有特定表的只读权限，而开发人员可能需要读写权限。
遵循最小权限原则：这是一种核心的安全策略，即仅赋予用户完成其工作所需的最低限度权限。这不仅减少了越权操作的风险，也限制了潜在的攻击面。
视图机制的保护：除了直接的权限授予，DBMS还允许通过创建视图来进行授权。视图是一个虚拟表，可以将用户限定在特定的属性（列）上，使其只能看到被允许的数据，从而隐藏底层的敏感信息。

三、 审计跟踪：提供事后监督与异常检测
密码和权限制度属于事前的防范措施，而审计则是重要的事后监督手段。
行为记录与监控：DBMS会自动将用户对数据库的所有操作（包括成功或不成功的登录企图、数据查询、修改或删除等）详细记录在审计日志中。通过分析这些审计日志，管理员可以追踪凭据的使用情况，及时发现并响应潜在的违规操作或恶意攻击行为（如短时间内大量访问敏感数据），为事后追责和安全漏洞修复提供确凿证据。

注意：有人说审计跟踪是为了在某人删库跑路之后能快速回滚恢复数据，这是不准确的。审计不能直接恢复数据，它只是成功恢复数据的关键辅助。审计跟踪的主要功能是监控、记录和追溯，而不是直接用来恢复数据。它就像是数据库里的"全天候监控录像"，负责事后追责与取证：详细记录谁在什么时间、从哪个IP地址执行了什么操作（如删表、改数据）。当发生"删库跑路"等安全事件时，管理员可以通过分析审计日志精准锁定肇事者及操作行为。

面对误删数据或"删库"危机，用来快速恢复数据的是以下几种底层技术与备份策略：
1、时间点恢复（PITR）：这是一种基于事务日志（如WAL日志）的细粒度恢复功能。如果发生了误删，只要该操作发生在备份窗口内，系统就可以将数据库状态精确还原到误删前的一秒钟（例如恢复到删除前两分钟的状态），从而最大限度减少业务中断和数据丢失。
2、Flashback（闪回）技术：通过解析二进制日志（如MySQL的Binlog），利用"镜像反转"原理生成逆向SQL语句。例如，把误执行的 DELETE 语句反转为 INSERT 语句重新插回去，实现秒级或分钟级的数据找回。
3、快照克隆技术：部分企业级灾备平台利用CopyOnWrite（写时复制）技术创建历史快照卷，无需繁琐的环境准备，即可在短时间内拉起一个指定时间点的只读数据库供验证或数据导出。

我们之前的第2点提到了：DBMS用于管理和访问不同类型的数据库。以 SQL Server 为例，它虽然是一个独立的 DBMS，但提供了多种机制来实现对其他异构数据库（如 MySQL、Oracle、MongoDB 等）的跨平台查询和管理：使用 ODBC 驱动程序或创建链接服务器连接 Oracle 数据库；通过配置"链接服务器"访问 MySQL 数据库；利用其 PolyBase 功能进行数据虚拟化访问MongoDB等非关系型数据库。这样我们用一个DBMS就能像访问本地数据库一样访问多种不同类型的DB。

问：什么是关系型数据库和非关系型数据库呢？这里的关系relation怎么理解？它在数学逻辑上说得通吗？
答："关系"在数学逻辑上不仅完全说得通，而且它是整个关系型数据库最严密、最优雅的基石。E.F.Codd 借用了集合论（Set Theory） 里的概念提出关系模型。"关系"被严格定义为：多个集合的"笛卡尔积"的一个"子集"。
数学推演（以"员工表"为例）：
假设我们有两个集合（在数据库中叫"域 Domain"）：
集合 A（姓名域） = {张三, 李四}
集合 B（部门域） = {研发部, 销售部}
（1）求笛卡尔积（Cartesian Product）
把 A 和 B 的所有可能组合全部列出来，这就是笛卡尔积A×B：
(张三, 研发部)	(张三, 销售部)	(李四, 研发部)	(李四, 销售部)
共 2 × 2 = 4 种可能。

（2）提取"关系"（Relation）
在现实公司中，并不是所有组合都存在。假设实际情况只有：张三在研发部，李四在销售部。那么上面的 4 种可能中实际存在的组合，形成一个子集：关系 R = { (张三, 研发部), (李四, 销售部) }
结论：在数学上，这个子集 R 就被称为一个 "关系 (Relation)"。
映射到数据库中：
集合 A 和 B = 域 (Domain)
(张三, 研发部) = 元组 (Tuple) / 行
姓名、部门 = 属性 (Attribute) / 列
关系 R = 整张二维表 (Table)

所以，"关系型数据库"的名字由来，是因为它的数据结构严格遵循了数学上"关系（笛卡尔积的子集）"的定义，而不是因为数据之间有"人际关联"。基于上述严密的数学模型构建的数据库，就是关系型数据库。
它的数据结构：严格的二维表（行和列）。操作语言：SQL（结构化查询语言），其底层就是"关系代数"（选择、投影、连接等数学运算）。
它的数据完整性：支持主键、外键、唯一约束，保证数据绝对不乱（ACID 事务特性）。适用场景：银行转账、电商订单、财务系统等要求数据绝对准确、不能丢失、逻辑复杂的核心业务。代表产品：MySQL, PostgreSQL, Oracle, SQL Server。


三、 非关系型数据库 (NoSQL)
随着互联网的发展（如淘宝双11、微博热搜），关系型数据库遇到了瓶颈：扩展难：单机性能有上限，很难通过加机器来横向扩展（分布式困难）。不够灵活：如果突然要在表里加一个新字段，或者存一段格式不固定的 JSON 数据，修改表结构（Schema）成本很高。特定场景慢：比如社交网络中"查找张三的三度好友"，用 SQL 的多次 JOIN 查询会慢到崩溃。
于是，非关系型数据库（NoSQL，原意是 Not Only SQL，不仅仅是 SQL） 诞生了。
"非关系"的意思是：它放弃了"二维表"和"关系代数"这种数学模型，采用了其他数据结构来存储数据，以换取极高的性能或灵活性。NoSQL 主要有四大流派：键值型 (Key-Value)、文档型 (Document)、列族型 (Column)、图数据库 (Graph)。

总结与比喻
1、关系型数据库 (RDBMS) 就像一个 严谨的政府档案局。每一份文件（数据）都必须填在标准格式的表格里（二维表）。
办事流程严格（事务 ACID），绝不出错。数学逻辑（关系代数）严密，适合处理复杂、核心的业务。
2、非关系型数据库 (NoSQL) 就像一个 灵活的现代物流仓储中心。不管你是箱子、包裹还是不规则的大件（JSON/键值），怎么方便怎么放（Schema-less）。追求的是吞吐量极大、存取极快（高性能、易扩展）。它放弃了档案局那种严密的数学表格约束，换取了极致的速度和灵活性。
因此，"关系"这个词代表 "笛卡尔积的子集（即二维表的集合）。

维度	关系型数据库 (SQL)	非关系型数据库 (NoSQL)
数据模型	严格的结构化表格，固定字段和类型	灵活的数据模型，无需预定义模式，支持嵌套与动态增减字段
事务与一致性	遵循 ACID 原则（原子性、一致性、隔离性、持久性），保证强一致性和完整的事务处理	遵循 BASE 理论（基本可用、软状态、最终一致性），牺牲部分强一致性换取高性能和高可用性
扩展性	传统上依赖垂直扩展（升级单机CPU、内存等硬件），成本高且存在上限	天生支持水平扩展（分布式集群分片），可通过增加节点轻松应对海量数据
查询语言	使用标准化的 SQL 语言，擅长多表关联（JOIN）、聚合和复杂子查询	缺乏统一标准，采用多样化查询方式（如 BSON 查询、特定 API 等），简单查询高效但复杂关联较弱
性能表现	复杂关联查询快，但在高并发读写或超大规模数据下易成为瓶颈	针对特定场景优化，高并发读写极快，适合海量数据的低延迟访问

4、文件系统与数据库系统的区别：

文件系统是"面向特定应用程序"的，数据是零散、孤立的；而数据库系统是"面向整个组织/业务"的，数据是高度结构化、集中共享的。数据库系统是"面向整个组织/业务"的，数据是高度结构化、集中共享的。

5、关系模式Relation Schema和关系实例Relation Instance的区别：

关系模式 (即表结构)是不变的；关系实例 (即某一时刻表中数据的快照)是随着时间不断变化的。

6、什么是概念模型？

答：概念模型是现实世界到机器世界之间的一个中间层次。

7、层次模型、网状模型、

8、什么是数据库系统三级模式结构？这种结构的优点是什么？

答：数据库系统的三级模式又外模式、模式、内模式组成。

外模式 (External Schema) ------ 用户级/视图级：也称为子模式或用户模式。它是数据库用户（包括应用程序员和最终用户）能够看见和使用的局部数据的逻辑结构和特征的描述。是数据库用户的数据视图。可将外模式简单理解为：不同用户看到的"定制化视图"。

模式 (Schema)------ 概念级/全局级：也称为逻辑模式。它是数据库中全体数据的全局逻辑结构和特征的描述，是所有用户的公共数据视图。可将它理解为：数据库的"总设计师图纸"。

内模式(Internal Schema) ------ 物理级：也称存储模式 。它是数据在数据库系统内部的物理存储结构和存取方法的描述。

为了实现这三层，必须有"两级映射"将它们连起来：（核心考点）

1. 外模式 / 模式 映射：定义了某个外模式和全局模式之间的对应关系。（决定了用户看到的局部数据，是如何从全局数据中提取或变形而来的）。 它保证了逻辑数据独立性 (Logical Data Independence)。当数据库的全局逻辑结构（模式） 发生改变时（例如：在员工表中新增了一个"籍贯"字段，或者拆分了某个表），只要调整"外模式/模式映射"，就可以保持外模式不变。基于外模式编写的应用程序一行代码都不用改。

2. 模式 / 内模式 映射：定义了全局逻辑结构和物理存储结构之间的对应关系。（决定了逻辑上的"表"，在物理硬盘上对应哪个文件、哪个索引）。它保证了物理数据独立性 (Physical Data Independence)。当数据库的物理存储结构（内模式） 发生改变时（例如：为了提升查询速度，DBA 给某个字段加了索引；或者更换了存储引擎；甚至把数据从机械硬盘迁移到了 SSD），只要调整"模式/内模式映射"，就可以保持模式不变。既然模式没变，外模式自然也不变，应用程序更不需要做任何修改。

   其他附加优点：简化用户接口：用户只需关心自己看到的外模式，无需了解复杂的底层物理细节。有利于数据安全：通过外模式，可以严格控制不同用户只能访问其权限内的数据（如前面提到的隐藏工资字段）。

   注意：绝对错误的说法是：外模式包含模式，模式包含内模式。这是典型的望文生义，被表面意思误导了。它不是同心圆那种外圈包含内圈，内圈包含更内圈的套娃。他们是不同视角的抽象关系。外模式是模式的视图,内模式是模式的物理实现。

   三级模式 + 两级映射 = 数据独立性。

9、数据库管理系统有哪些模型呢？

答：

①层次模型 (Hierarchical Model)：（如早期的 IBM IMS (Information Management System)）。这是数据库发展史上最早被广泛使用的模型（20世纪60年代）。树状结构 (Tree)。数据被组织成有向树，有且仅有一个根节点，每个子节点有且仅有一个父节点（严格的 1:N 一对多关系）。例如：在唐朝，宰相（根节点）管理吏户礼兵刑工这六部（子节点），每个部再有各自的官吏（孙子节点）将工作落到实处。假设张三属于吏部，李四属于兵部，他俩只负责自己部门的事务，不用管其它部门是如何运作的。直到今天，IBM 的大型机上仍有部分核心银行系统在使用 IMS，因为它在处理极其稳定的、层次分明的海量交易时依然非常可靠。

优点：结构简单清晰，对于已知的、自上而下的查询路径，速度极快。提供了良好的数据完整性支持（父节点删除，子节点自动级联删除）。

缺点：无法表示多对多 (M:N) 关系：如果一个员工同时属于研发部和销售部，层次模型就无法直接表示，必须引入冗余数据或虚拟节点，极其麻烦。插入/删除异常：如果没有父节点（比如新建一个还没有员工的"新部门"），子节点就无法插入。

②网状模型(Network Model)：（如 CODASYL）。它解决了层次模型"无法表示多对多关系"的痛点（20世纪70年代）。有向图结构 (Graph)。允许一个节点有多个父节点 ，打破了树的限制，可以自然地表示多对多 (M:N) 关系。例如：早期的社交网络。节点 A（张三）可以同时连接到节点 B（办公室职员）和节点 C（父亲）、节点D（儿子）、节点E（丈夫）、节点F（商场重点客户）等。代表例子**：**CODASYL (数据系统语言会议) 标准下的数据库，如 IDMS (Integrated Database Management System)。

优点：能够直接、高效地描述现实世界中复杂的实体联系。存取效率较高，因为数据之间的连接是通过物理指针直接实现的。

缺点：结构极其复杂：随着数据量增加，网状结构会变得像蜘蛛网一样难以理解和维护。导航式查询：用户必须清楚地知道数据在网中的"物理路径"。要查询数据，必须用代码一步步地"顺藤摸瓜"（先找A，再顺着指针找B，再找C）。一旦业务逻辑改变，代码必须重写。

③关系模型(Relational Model)：（如 MySQL）。1970年，IBM 研究员 E.F. Codd 提出了关系模型。他用数学的严谨性彻底击败了层次和网状模型的"物理指针"混乱，成为今天绝对的主流。这也是本门课程我们重点学习和研究的。

其核心结构：二维表 (Table)。基于集合论和关系代数。数据被表示为关系的集合（即二维表），表与表之间通过公共属性（外键） 进行逻辑关联，而不是物理指针。例如：一套相互关联的 Excel 表格。你不需要知道数据存在硬盘的哪个磁道上，你只需要说："请把 员工表 和 部门表 中 部门ID 相同的行拼起来给我看"。

优点：坚实的数学基础：关系代数保证了数据操作的严密性和正确性。
数据独立性极高：用户只需关心逻辑上的表，完全不需要知道底层的物理存储路径（解决了网状模型的痛点）。
声明式语言 (SQL)：用户只需告诉数据库"我要什么 (What)"，数据库自己决定"怎么找 (How)"，极大降低了开发门槛。

缺点：在处理极其复杂的多表关联（如深度 JOIN）或海量非结构化数据时，性能会遇到瓶颈。
代表例子：MySQL, PostgreSQL, Oracle, SQL Server。

④面向对象模型 (Object-Oriented Model, OODBMS)：核心结构：对象 (Object)。（如 ObjectStore）20世纪80年代末到90年代，面向对象编程（OOP，如 C++, Java）成为主流。但程序员发现了一个巨大痛点：阻抗失配 (Impedance Mismatch)。在 Java 代码里，数据是"对象"（包含属性和方法）；但在数据库里，数据是"二维表"。每次保存或读取，都要写大量繁琐的代码把"对象"拆解成"表行"，或者把"表行"组装成"对象"。为了解决这个问题，面向对象数据库诞生了：数据以对象的形式存储，对象不仅包含属性 (数据)，还包含方法 (行为/代码)。支持面向对象的三大特性：封装、继承、多态。

例如：智能乐高积木。每个积木（对象）不仅有自己的颜色和形状（属性），还内置了"如何与红色积木拼接"的指令（方法）。程序可以直接操作这些智能积木，无需拆解。代表：ObjectStore, Versant, db4o。

优点：与面向对象编程语言无缝衔接，消除了"阻抗失配"，开发复杂应用（如 CAD 计算机辅助设计、GIS 地理信息系统、多媒体系统）效率极高。能够直接存储和处理复杂数据类型（如图像、音频、自定义类）。

缺点：缺乏统一的标准查询语言：没有像 SQL 那样通用、强大的语言，各家厂商自成一体。事务处理和并发控制较弱：在面对高并发、需要严格 ACID 特性的传统商业应用（如银行、电商）时，表现不如关系型数据库成熟。

⑤对象-关系模型 (Object-Relational Model)：由于纯面向对象数据库未能撼动关系型数据库的统治地位，后来的演进方向变成了 "对象-关系模型 (ORDBMS)"，即在关系型数据库中引入面向对象特性，支持 JSON、数组、自定义类型，成为了目前的最佳折中方案。它保留了关系型数据库的 SQL 接口和 ACID 事务特性，但引入了面向对象的特性（如支持自定义数据类型、继承、数组、JSON 等复杂结构）。例子**：**PostgreSQL（目前世界上最先进的开源对象-关系型数据库）、Oracle。就像带分类标签的档案袋，试图让代码和数据结构更贴合现实世界。

⑥ 非关系型 (NoSQL) 数据模型：（当前的主流）它放弃了严格的二维表和关系代数，采用了更灵活的数据结构来换取极高的性能或扩展性。像现代化的智能物流仓储，什么货物用什么容器（KV、JSON、图），怎么快怎么来。包含四大经典模型：

键值模型 (Key-Value Model)：结构极其简单，就像一个巨大的哈希表（Hash Map）。通过唯一的 Key（键）瞬间查找对应的 Value（值）。Value 对数据库来说是不透明的黑盒（可以是字符串、图片、甚至序列化对象）如Redis（内存键值数据库的王者）、Memcached。

文档模型 (Document Model)：数据以类似 JSON 或 XML 的"文档"形式存储。它不需要预先定义严格的表结构（Schema-less），同一个集合里的不同文档可以有不同的字段。非常适合存储结构多变、嵌套层级深的数据。如MongoDB（最流行的文档数据库）、CouchDB。

列族模型 (Column-Family / Wide-Column Model)：它不是按"行"存储，而是按"列族"存储。它将同一列的数据物理上存放在一起。这种模型极度擅长对海量数据中的某几列进行聚合分析，且压缩率极高，非常适合分布式存储。如Apache HBase（Hadoop 生态的核心）、Apache Cassandra（去中心化，高可用）。

图模型 (Graph Model)：如基于图论，数据被抽象为"节点 (Node)"、"边 (Edge)"和"属性 (Property)"。它不关心表怎么 JOIN，而是直接沿着"关系（边）"进行遍历，查询复杂关联（如"朋友的朋友的朋友"）的速度比关系型数据库快成千上万倍。如Neo4j（图数据库的开创者和标杆）、NebulaGraph（国产开源分布式图数据库）。

⑦ 特定业务场景的专用模型：像高度专业化的流水线（如专门处理流水线计件、或专门处理地图坐标），在特定领域做到极致性能。

时序模型 (Time-Series Model)：专为带有"时间戳"的连续数据流设计。数据结构通常是 `(时间戳, 指标名, 标签, 数值)`。它在数据写入（高频追加）和按时间范围聚合查询上做了极致优化，且支持数据自动过期淘汰。如InfluxDB、TDengine（国产开源物联网时序数据库）。

多维模型 (Multidimensional Model)：主要用于数据仓库和 OLAP（联机分析处理）。数据被组织成"数据立方体 (Data Cube)"，围绕"事实 (Fact)"和多个"维度 (Dimension，如时间、地区、产品)"构建，支持极速的切片、切块、钻取等分析操作。如ClickHouse（虽然是列式存储，但极度优化了多维分析）、Apache Kylin（预计算多维 Cube 的代表）。

今天的我们在做普通业务时首选 MySQL（关系型），而在做缓存时选 Redis（键值型），做复杂关联分析时选 Neo4j（图模型）------针对特定痛点的最佳工具。