数据库
2025-06-10 15:39:44 0 举报AI智能生成
您的指令似乎不完整。数据库通常包含大量信息，但您并未指定具体的数据表、字段或者要生成描述的核心内容。如果您需要创建一个描述特定数据库文件的文本，请提供更多细节，例如所含数据的种类、格式、重要性以及任何需要特别强调的属性或修饰语。这样一来，我便能够为您精确地生成所需描述。
作者其他创作
大纲/内容
• 基本概念:
三级模式-两级映像
概念模式与内模式之间，还存在映像，即二级映像
外部层(ExternalLevel)
外模式(External Schema)、
概念层(Conceptual Level)
概念 模式(Conceptual Schema)：逻辑模式
内部层(Internal Level)
内模式(Internal Schema)：物理模式、存储模式
数据库系统
数据库关系
三种类型
基本表:实际存在的表，实际存储数据的逻辑表示。
查询表:查询结果对应的表
视图表:由基表或其他视图表导出的表，本身不独立存储，数据库只存放它的定义，常称为虚表。
视图的优点
视图能简化用户操作
视图使用户能以多种角度看待同一数据
视图对重构数据库提供了一定程度的逻辑独立性 视图可以对机密数据提供安全保护
分布式数据库
概念：指数据存储和处理在多台计算机上分布式管理的数据库系统
特点
数据分布
透明性
数据冗余和复制
数据一致性
常见的解决方案包括使用一致性协议(如两阶 段提交协议(2PC)或Paxos协议)，以及通过CAP定理来做出权衡:一致性、可用性和分区容忍性
可扩展性、高可用性和容错性
优点
高可用性:通过冗余和故障恢复机制，分布式数据库可以提供比传统集中式数据库更高的可用性。
可扩展性:随着数据量增长，能够通过增加节点进行水平扩展，轻松应对大规模数据存储和处理的需求。
容错性:系统能够容忍单点故障，保证数据的可靠性和系统的持续可用性。
缺点
一致性问题:分布式系统需要处理不同节点之间的数据一致性问题，特别是在存在网络延迟或节点故障时。解决方 案如分布式事务或一致性协议增加了系统的复杂性。
性能瓶颈:虽然可以水平扩展，但由于网络延迟、节点间的数据同步等因素，分布式数据库的性能可能不如单节点 的集中式数据库。
管理复杂性:分布式数据库的管理需要处理多个节点的协调、故障恢复、数据备份、负载均衡等问题，管理起来较 为复杂。
数据库设计
子主题 1
(1 )需求分析:即分析数据存储的要求
产出物有数据流图、数据字典、需求说明 书。
获得用户对系统的三个要求:信息要求、处理要求、系统要求。
(2)概念结构设计:设计E-R图，也即实体-联系图。工作步骤包括:选择局部 应用、逐一设计分E-R图、E-R图合并。分E-R图进行合并时，它们之间存在的冲 突主要有以下3类。
属性冲突。同一属性可能会存在于不同的分E-R图中。
命名冲突。相同意义的属性，在不同的分E-R图上有着不同的命名，或是名称相同的属性在不同的分E-R图中代表着不同的意义。
结构冲突。同一实体在不同的分E-R图中有不同的属性，同一对象在某一分E-R图中被抽
象为实体而在另一分E-R图中又被抽象为属性。 (3)逻辑结构设计:将E-R图，转换成关系模式。工作步骤包括:确定数据模型、
将E-R图转换成为指定的数据模型、确定完整性约束和确定用户视图。 (4)物理设计:步骤包括确定数据分布、存储结构和访问方式。
(5)数据库实施阶段:根据逻辑设计和物理设计阶段的结果建立数据库，编制与调 试应用程序，组织数据入库，并进行试运行。
(6)数据库运行和维护阶段:数据库应用系统经过试运行即可投入运行，但该阶段 需要不断地对系统进行评价、调整与修改。
数据模型四种分类
• 关系模型:是二维表的形式表示的实体-联系模型，是将实体-联系模型转换而来的，经过开发人员设计的;
• 概念模型:是从用户的角度进行建模的，是现实世界到信息世界的第一抽象，是真正的实体-联系模型。
• 网状模型:表示实体类型及其实体之间的联系，一个事物和另外几个都有联系，形成一张网。
• 面向对象模型:是采用面向对象的方法设计数据库，以对象为单位，每个对象包括属性和方法，具有类和继承等特点
数据模型三要素
• 数据结构:所研究的对象类型的集合
• 数据操作:对数据库中各种对象的实例允许执行的操作的集合
• 数据的约束条件:一组完整性规则的集合
• 数据库模型:
E-R模型
使用椭圆表示属性(一般没有)、长方形表示实体、菱形表示联系，联系的两端要填写联系类 型
关系模型
数据的逻辑结构是一张二维表，由行列组成
关系代数
并:结果是两张表中所有记录数合并，相同记录只显示一次。
交:结果是两张表中相同的记录。
差:S1 -S2，结果是S1 表中有而S2表中没有的那些记录。
笛卡尔积
S1 XS2，产生的结果包括S1 和S2的所有属性列，并且S1 中每条记录依次和S2中所有记录组合成一条记录，最终属性列为S1 +52属性列，记录数为S1 *52记录数。
投影(π):实际是按条件选择某关系模式中的某列，列也可以用数字表示。
选择(σ):实际是按条件选择某关系模式中的某条记录。
自然连接:显示全部的属性列，但是相同属性列只显示一次，显示两个关系模式中属性相同且值相同的记录。
SQL
• 规范化:
键与约束
超键:能唯一标识记录的属性集合(可能不止一个)
候选键:最小的超键，用于作为主键(通常只有一个)
主属性:除候选键外的具有代表意义的非重复且非衍生属性
主键:任选一个候选键，即可作为主键。
外键:其他表中的主键。
实体完整性约束:即主键约束，主键值不能为空，也不能重复。
参照完整性约束:即外键约束，外键必须是其他表中已经存在的主键的值，或者为空。
用户自定义完整性约束:自定义表达式约束，如设定年龄属性的值必须在0到1 80之间。
函数依赖
部分函数依赖
A、B->C，C对A部分函数依赖
传递函数依赖
A决定->B，B决定->C,C 对A传递函数依赖
函数依赖的公理系统(Armstrong阿姆斯特朗公理)
三条基本规则
• 自反律:若属性集Y是属性集X的子集(Y⊆X⊆U)，则X→Y成立。这表示如果一个属性集合Y是另一个属性集合X的子集，那么X可以决定Y。
• 增广律:若X→Y成立，且属性集Z是属性集U的子集(Z⊆U)，则XZ→YZ也成立。这表示如果X可以决定Y，那么在任何集合Z加入到X和Y两侧的情况下，依赖关系仍然成立。
• 传递律:若X→Y及Y→Z成立，则X→Z也成立。这表示如果X可以决定Y，且Y可以决定Z，那么X也可以决定Z。
范式(层层传递)
第一范式（1NF）：每个项都是原子项，不能再拆
第二范式（2NF）：不能存在部分函数依赖，不能看到联合主键
肯定满足第一范式，可以存在传递函数
第三范式(3NF )：不能存在传递函数依赖
肯定满足第二范式
BC范式(BCNF)
满足3NF，是3NF的增强版
在3NF基础上，增删数据不会产生异常
第四范式（4NF）
不允许存在多值依赖
反规范化（提高性能）
规范化设计后，数据库设计者希望牺牲部分规范化来提高性能
具体方式
增加冗余列
在多个表中保留相同的列，通过增加数据冗余减少或避免查询时的连接操作。
增加派生列
在表中增加可以由本表或其它表中数据计算生成的列，减少查询时的连接操作并避免计算或使用集合函数。
重新组表
如果许多用户需要查看两个表连接出来的结果数据，则把这两个表重新组成一个表来减少连接而提高性能。
水平分割表
垂直分割表
对表进行分割，将主键与部分列放到一个表中，主键与其它列放到另一个表中，在查询时减少l/0次数。
模式分解
满足数据规范化时需要拆表，过程中有2个判断标准
是否保持函数依赖分解:对于关系模式R，有依赖集F，若对R进行分解，分解出来的多个关系模式，保持原来的依赖集不变，则为保持函数依赖的分解。另外，注意要消除掉冗余依赖(如传递依赖)
有损无损分解:分解后的关系模式能够还原出原关系模式，就是无损分解，不能还原就是有损
• 事务并发:
并发三种问题、
三级封锁协议
• 数据库新技术:
数据库安全与备份、
反规范化、
分布式数据库、
缓存数据库
数据库集群
NoSqI
0 条评论
下一页
