精华内容
下载资源
问答
  • ,An} 是关系的一个或多个属性的集合,该集合函数决定了关系的其它所有属性并且是最小的,那么该集合就称为键码。 对于 A->B,如果能找到 A 的真子集 A',使得 A'-> B,那么 A->B 就是部分函数依赖,否则...

    函数依赖

    记 A->B 表示 A 函数决定 B,也可以说 B 函数依赖于 A。

    如果 {A1,A2,... ,An} 是关系的一个或多个属性的集合,该集合函数决定了关系的其它所有属性并且是最小的,那么该集合就称为键码。

    对于 A->B,如果能找到 A 的真子集 A',使得 A'-> B,那么 A->B 就是部分函数依赖,否则就是完全函数依赖。

    对于 A->B,B->C,则 A->C 是一个传递函数依赖。

    异常

    以下的学生课程关系的函数依赖为 {Sno, Cname} -> {Sname, Sdept, Mname, Grade},键码为 {Sno, Cname}。也就是说,确定学生和课程之后,就能确定其它信息。

    Sno Sname Sdept Mname Cname Grade
    1 学生-1 学院-1 院长-1 课程-1 90
    2 学生-2 学院-2 院长-2 课程-2 80
    2 学生-2 学院-2 院长-2 课程-1 100
    3 学生-3 学院-2 院长-2 课程-2 95

    不符合范式的关系,会产生很多异常,主要有以下四种异常:

    • 冗余数据:例如 学生-2 出现了两次。
    • 修改异常:修改了一个记录中的信息,但是另一个记录中相同的信息却没有被修改。
    • 删除异常:删除一个信息,那么也会丢失其它信息。例如删除了 课程-1 需要删除第一行和第三行,那么 学生-1 的信息就会丢失。
    • 插入异常:例如想要插入一个学生的信息,如果这个学生还没选课,那么就无法插入。

    范式

    范式理论是为了解决以上提到四种异常。

    高级别范式的依赖于低级别的范式,1NF 是最低级别的范式。

    1. 第一范式 (1NF)

    属性不可分。

    2. 第二范式 (2NF)

    每个非主属性完全函数依赖于键码。

    可以通过分解来满足。

    分解前 

    Sno Sname Sdept Mname Cname Grade
    1 学生-1 学院-1 院长-1 课程-1 90
    2 学生-2 学院-2 院长-2 课程-2 80
    2 学生-2 学院-2 院长-2 课程-1 100
    3 学生-3 学院-2 院长-2 课程-2 95

    以上学生课程关系中,{Sno, Cname} 为键码,有如下函数依赖:

    • Sno -> Sname, Sdept
    • Sdept -> Mname
    • Sno, Cname-> Grade

    Grade 完全函数依赖于键码,它没有任何冗余数据,每个学生的每门课都有特定的成绩。

    Sname, Sdept 和 Mname 都部分依赖于键码,当一个学生选修了多门课时,这些数据就会出现多次,造成大量冗余数据。

    分解后 

    关系-1

    Sno Sname Sdept Mname
    1 学生-1 学院-1 院长-1
    2 学生-2 学院-2 院长-2
    3 学生-3 学院-2 院长-2

    有以下函数依赖:

    • Sno -> Sname, Sdept
    • Sdept -> Mname

    关系-2

    Sno Cname Grade
    1 课程-1 90
    2 课程-2 80
    2 课程-1 100
    3 课程-2 95

    有以下函数依赖:

    • Sno, Cname -> Grade

    3. 第三范式 (3NF)

    非主属性不传递函数依赖于键码。

    上面的 关系-1 中存在以下传递函数依赖:

    • Sno -> Sdept -> Mname

    可以进行以下分解:

    关系-11

    Sno Sname Sdept
    1 学生-1 学院-1
    2 学生-2 学院-2
    3 学生-3 学院-2

    关系-12

    Sdept Mname
    学院-1 院长-1
    学院-2 院长-2
    展开全文
  • 关系型数据库理论

    千次阅读 2020-08-19 10:15:06
    文章目录目录关系型数据库科德十三准则(RDBMS 十三准则)ACID 原则主流的 RDBMS关系型数据库设计的原则关系型数据库设计的步骤关系数据结构关系完整性约束关系操作集合 关系型数据库 关系型数据库,是指采用了关系...

    目录

    关系型数据库

    关系型数据库,是指采用了关系模型来组织数据的数据库,借助集合代数等数学概念和方法来处理数据库中的数据。其中,关系模型,即:实体(Entity)之间的关系(Relationship),所以也称为 E-R 模型(Entity-Relationship Model),现实世界中的各种实体以及实体之间的各种联系均用关系模型来表示。而集合代数则描述了集合的基本性质和规律,如:并集、交集、补集,以及集合的关系,如:等于、包含、被包含。

    • 关系模型和 “科德十二定律” 由 E.F.Codd 于 1970 年首先提出的,关系模型由关系数据结构、关系操作集合、关系完整性约束三部分组成,作为关系型数据库的基石。

    • E-R 模型由陈品山(Peter P.S Chen)博士于 1976 年提出的一套数据库的设计工具,运用了显式世界中的事物与关系的观念,来解释数据库中的抽象的数据架构。E-R 模型利用图形的方式(E-R 图)来表示数据库的概念设计,有助于设计过程中的构思及沟通讨论。

    • SQL(Structured Query Language,结构化查询语言)由 Boyce 和 Chamberlin 于 1974 年提出,作为关系型数据库语言的标准,是一种介于关系代数与关系演算之间的结构化查询语言(具有关系代数和关系演算双重特征),执行对关系型数据库中数据的检索和操作。

    关系型数据库以行(Row)和列(Column)的形式存储数据,这一系列的行和列被称为表(Table),包括基础表、派生表(查询结果)和虚拟表(视图),一组表再组成了数据库。从这个角度来看,“实体” 可以理解为二维表格模型,而 “关系” 则是这些二维表及其之间的组织方式。简而言之,关系型数据库是由多张能互相联接的二维行列表格组成的数据库。

    关系型数据库的特点:

    1. 基于模型的储存方式,也称为结构化存储,储存结构化数据:关系型数据库采用行列二维表格的方式进行存储。并且每个数据表的表项(列)都必须预先定义好该字段的属性(例如:类型、长度),然后再严格按照数据表的结构存入数据。结构化存储的好处在于数据的结构在存入之前就已经定义好了,所以整个数据表的可靠性和稳定性都比较高;相对的,结构化存储的灵活性就会很差,一旦存入数据后再要修改数据表的结构就会十分困难。这就要求了关系型数据库应用系统必须要考虑数据库灰度升级的方案(注:这里不是指 RDBMS 软件的升级)。

    2. 存储规范:关系型数据库为了避免储存冗余数据以及充分利用好存储空间,要求数据按照最小关系表的形式进行储存,根据合理的范式进行分表。

    3. 扩展方式:关系型数据库数据操作的瓶颈主要有两个方面:1)运行环境的硬件性能;2)数据库表设计的合理性。关系型数据库多表之间可能存在复杂的关联关系(例如:多表级联查询),而且数据表越多这个问题越严重。也由于多表间所具有的关联关系,导致关系型数据库不具备分布式运行的条件。关系型数据库大多采用主备高可用方案,只能纵向扩展,无法很好地实现原生的分布式集群方案。相对的大多数非关系型数据库都支持集群模式。

    4. 查询方式:关系型数据库采用结构化查询语言(即 SQL)来对数据库进行查询,SQL 支持 CRUD(增加,查询,更新,删除)操作,还可以采用类似索引的方法来加快查询操作。

    5. 事务性:即 ACID 规则,原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)。

    6. 读写性能:关系型数据库十分强调数据的一致性,并为此付出了降低读写性能的代价。因此相对于非关系型数据库,关系型数据库具有非常不错的数据处理可靠性,但高并发读写性能欠佳。

    科德十三准则(RDBMS 十三准则)

    全关系系统应该完全支持关系模型的所有特征。关系模型的奠基人埃德加·科德具体地给出了全关系系统应遵循的基本准则。

    1. 一个关系型的关系数据库管理系统必须能完全通过它的关系能力来管理数据库。
    2. 信息准则:关系数据库管理系统的所有信息都应该在逻辑一级上用表中的值这一种方法显式的表示。
    3. 保证访问准则:依靠表名、主键和列名的组合,保证能以逻辑方式访问关系数据库中的每个数据项。
    4. 空值的系统化处理:全关系的关系数据库管理系统支持空值的概念,并用系统化的方法处理空值。
    5. 基于关系模型的动态的级联数据字典数据库的描述在逻辑级上和普通数据采用同样的表述方式。
    6. 统一的数据子语言:一个关系数据库管理系统可以具有几种语言和多种终端访问方式,但必须有一种语言,它的语句可以表示为严格语法规定的字符串,并能全面的支持各种规则。
    7. 视图更新准则:所有理论上可更新的视图也应该允许由系统更新。
    8. 高级的插入、修改和删除操作:系统应该对各种操作进行查询优化。
    9. 数据的物理独立性:无论数据库的数据在存储表示或访问方法上作任何变化,应用程序和终端活动都保持逻辑上的不变性。
    10. 数据逻辑独立性:当对基本关系进行理论上信息不受损害的任何改变时,应用程序和终端活动都保持逻辑上的不变性。
    11. 数据完整的独立性:关系数据库的完整性约束条件必须是用数据库语言定义并存储在数据字典中的。
    12. 分布独立性:关系数据库管理系统在引入分布数据或数据重新分布时保持逻辑不变。
    13. 无破坏准则:如果一个关系数据库管理系统具有一个低级语言,那么这个低级语言不能违背或绕过完整性准则。

    ACID 原则

    • 原子性(Atomicity):指事务是一个不可分割的工作单位,事务中的操作要么都发生,要么都不发生。

    • 一致性(Consistency):指一个事务执行之前和执行之后数据库都必须处于一致性状态。如果事务成功地完成,那么系统中所有变化将正确地应用,系统处于有效状态。如果在事务中出现错误,那么系统中的所有变化将自动地回滚,系统返回到原始状态,即:从一个一致性状态变换到另外一个一致性状态。

    • 隔离性(Isolation):指在并发环境中,当不同的事务同时操纵相同的数据时,每个事务都有各自的完整数据空间。由并发事务所做的修改必须与任何其他并发事务所做的修改隔离。事务查看数据更新时,数据所处的状态要么是另一事务修改它之前的状态,要么是另一事务修改它之后的状态,事务不会查看到中间状态的数据。

    • 持久性(Durability):指一个事务一旦被提交,它对数据库中数据的改变就是永久性的,接下来即使数据库发生故障也不应该对其有任何影响。

    事务的 ACID 特性是由 RDBMS 来实现的。RDBMS 通常会采用日志机制来保证事务的 ACID。日志记录了事务对数据库所做的更新,如果某个事务在执行过程中发生错误,就可以根据日志,撤销事务对数据库已做的更新,使数据库退回到执行事务前的初始状态。简单来说:

    • 原子性:要么全有,要么全无;
    • 一致性:每次读取的都必须是最新数据;
    • 隔离性:多并发事务互相隔离,对共享数据加锁;
    • 持久性:数据最终的落盘变更是持久而不变的。

    数据结构

    数学建模

    • 域(Domain):是一组具有相同数据类型的值的集合。例如:整数、实数、介于某个取值范围的整数、指定长度的字符串集合、{‘男’,‘女’}。

    • 笛卡尔积(Cartesian Product):表示为 X × Y,第一个对象是 X 的成员而第二个对象是 Y 的所有可能有序对的其中一个成员。假设集合 X={a, b},集合 Y={0, 1, 2},则两个集合的笛卡尔积为 {(a, 0), (a, 1), (a, 2), (b, 0), (b, 1), (b, 2)}。在关系数据结构中,运算因子为一组域,例如:D1,D2,…,Dn。

    在这里插入图片描述

    • 元组(Tuple):笛卡尔积中每一个元素(d1,d2,…,dn)叫作一个 n 元组(n-tuple)。

    • 分量(Component):笛卡尔积元素(d1,d2,…,dn)中的每一个值 d[i] 叫作一个分量。

    • 基数(Cardinal number):若 di(i=1,2,…,n)为有限集,其基数为 mi(i=1,2,…,n)。简而言之,基数就是笛卡尔积中所包含的元组的数量。例如:D1×D2×…×Dn 的基数 M 为:
      在这里插入图片描述
      下面看一个示例。

    给出 3 个域:

    1. D1 = 导师集合 SUPERVISOR ={张清玫,刘逸}
    2. D2 = 专业集合 SPECIALITY ={计算机专业,信息专业}
    3. D3 = 研究生集合 POSTGRADUATE ={李勇,刘晨,王敏}

    D1,D2,D3 的笛卡尔积为:

    D1×D2×D3={
    (张清玫,计算机专业,李勇),(张清玫,计算机专业,刘晨),
    (张清玫,计算机专业,王敏),(张清玫,信息专业,李勇),
    (张清玫,信息专业,刘晨),(张清玫,信息专业,王敏),
    (刘逸,计算机专业,李勇),(刘逸,计算机专业,刘晨),
    (刘逸,计算机专业,王敏),(刘逸,信息专业,李勇),
    (刘逸,信息专业,刘晨),(刘逸,信息专业,王敏)

    基数为:2 × 2 × 3=12。

    实现表征

    回头再看关系数据结构在关系型数据库中的应用,当我们要查询的数据被存放在 n 张表时,RDBMS 首先需要对 n 张表求得笛卡尔积,然后在根据过滤条件返回其中的 m 个元组(记录)。

    • 笛卡尔积 R(D1×D2×…×Dn) 的子集叫作在域 D1,D2,…,Dn 上的一个关系(R:关系名;n:关系的目)。对于关系型数据库而言,笛卡尔积的某个子集才有实际含义。
    • 关系表现为一张二维表,每行对应一个元组,每列或多列对应一个域。
    • 关系中不同列可以对应一个相同的域,为了加以区分,必须对每列起一个名字,称为属性(Attribute), n 目关系必有 n 个属性。
    • 码(键):
      • 候选码(Candidate key):若关系中的某一属性组的值能唯一地标识一个元组,则称该属性组为候选码。
      • 全码(All-key):极端的情况,关系中的所有属性组都是这个关系的候选码,称为全码。
      • 主码(Primary key):若一个关系有多个候选码,则选定其中一个为主码。
      • 主属性:候选码的主属性(Prime attribute),不包含在任何侯选码中的属性称为非主属性(Non-Prime attribute)或非码属性(Non-key attribute)

    关系的性质:

    • 列是同质的(Homogeneous)。
    • 不同的列可以出自同一个域,其中的每一列称为一个属性,不同的属性要给予不同的属性名。
    • 行或列的顺序无所谓。
    • 任意两个元组的候选码不能相同。
    • 分量必须取原子值。

    完整性约束

    完整性约束用于维护数据的完整性或者满足业务约束的需求。实体完整性、参照完整性是关系模型必须满足的完整性约束条件,称为关系的两个不变性,应该由 RDBMS 支持。而用户定义的完整性,是应用领域需要遵循的约束条件,体现了具体领域中的语义约束 。

    实体完整性(主键约束)

    规则:

    1. 若属性 A 是基本关系 R 的主属性,则属性 A 不能取空值。
    2. 空值就是 “不知道” 或 “不存在” 或 “无意义” 的值。

    规则说明:

    • 实体完整性规则是针对基本关系而言的,一个基本表通常对应现实世界的一个实体集。
    • 现实世界中的实体是可区分的,即它们具有某种唯一性标识。
    • 关系模型中以主码作为唯一性标识。
    • 主码中的属性即主属性不能取空值。主属性取空值,就说明存在某个不可标识的实体,即存在不可区分的实体,这与第(2)点相矛盾,因此这个规则称为实体完整性。

    参照完整性(外键约束)

    注:参照,Reference 也翻为 “引用”。

    规则:若属性(或属性组)F 是基本关系 R 的外码,它与基本关系 S 的主码 Ks 相对应(基本关系 R 和 S 不一定是不同的关系),则对于 R 中每个元组在 F 上的值必须为:

    • 或者取空值(F 的每个属性值均为空值)。
    • 或者等于 S 中某个元组的主码值。

    关系间的引用

    在关系模型中实体及实体间的联系都是用关系来描述的,自然存在着关系与关系间的引用。

    如下例:

    • “学号” 是主码,“班长” 是外码,它引用了本关系的 “学号”。
    • “班长” 必须是确实存在的学生的学号。

    在这里插入图片描述

    外码(键)

    设 F 是基本关系 R 的一个或一组属性,但不是关系 R 的码。如果 F 与基本关系 S 的主码 Ks 相对应,则称 F 是 R 的外码。

    • 基本关系 R 称为参照关系(Referencing Relation)
    • 基本关系 S 称为被参照关系(Referenced Relation)或目标关系(Target Relation)

    规则:

    • 关系 R 和 S 不一定是不同的关系。
    • 目标关系 S 的主码 Ks 和参照关系的外码 F 必须定义在同一个(或一组)域上。
    • 外码并不一定要与相应的主码同名,当外码与相应的主码属于不同关系时,往往取相同的名字,以便于识别。

    例如:

    • 学生关系的 “专业号” 与专业关系的主码 “专业号” 相对应。
    • “专业号” 属性是学生关系的外码。
    • 专业关系是被参照关系,学生关系为参照关系。

    在这里插入图片描述

    用户定义完整性(非空约束、唯一约束、检查约束和默认值)

    用户定义完整性是针对某一具体关系数据库的约束条件,反映某一具体数据库应用程序所涉及的数据必须满足的语义要求。RDBMS 应提供定义和检验这类完整性的机制,以便用统一的系统的方法处理它们,而不需由应用程序承担这一功能。

    例如:课程(课程号,课程名,学分)

    • “课程号” 属性必须取唯一值。
    • 非主属性 “课程名” 也不能取空值。
    • “学分” 属性只能取值 {1,2,3,4}。

    操作集合

    关系操作的本质就是集合的操作,操作的对象和结果都是集合,一次一集合的方式。

    • 数据查询操作:选择(Selection)、投影(Projection)、连接(Join)、并集(Union)、差集(Exception)、交集(Intersection)、笛卡尔积(Cartesian product)、除。其中,选择、投影、并、差、笛卡尔基是 5 种基本操作。
    • 数据更新操作:插入、删除、修改。

    关系代数运算

    关系代数是一种抽象的查询语言,它用对关系的运算来表达查询。运算对象是关系、运算结果亦为关系、关系代数的运算符有两类:集合运算符和专门的关系运算符。

    • 传统的集合运算是从关系的 “水平” 方向即行的角度进行。
    • 专门的关系运算不仅涉及行而且涉及列。

    关系代数运算符:
    在这里插入图片描述

    传统的集合运算

    • R:
      在这里插入图片描述

    • S:
      在这里插入图片描述

    R 和 S:

    • 具有相同的 n 目(即两个关系都有 n 个属性)
    • 相同的属性取自同一个域。

    并集运算

    R ∪ S:仍为 n 目关系,由属于 R 或属于 S 的元组组成。

    在这里插入图片描述

    差集运算

    R - S:仍为 n 目关系,由属于 R 而不属于 S 的所有元组组成。

    在这里插入图片描述

    交集运算

    R ∩ S:仍为 n 目关系,由既属于 R 又属于 S 的元组组成。

    在这里插入图片描述

    笛卡尔积

    R × S:

    • 列:(n + m)列元组的集合,元组的前 n 列是关系 R 的一个元组,后 m 列是关系 S 的一个元组。
    • 行:k1 × k2 个元组。

    在这里插入图片描述

    专门的关系运算

    在这里插入图片描述

    • Student
      在这里插入图片描述

    • Course
      在这里插入图片描述

    • S-C:
      在这里插入图片描述

    选择运算(WHERE 根据条件过滤行)

    选择运算又称为限制(Restriction):在关系中选择满足给定条件的元组。选择条件是一个逻辑表达式,例如:>,≥,<,≤,= 或 <>,结果为 “真” 或 “假”。选择运算主要是从列的角度进行运算。

    例如:查询 IS 系(信息系)全体学生。

    在这里插入图片描述

    投影运算(SELETE 显式选取列)

    从关系 R 中选择出若干属性列组成新的关系 S。投影运算主要是从列的角度进行运算。投影之后不仅取消了原关系中的某些列,而且还可能取消某些元组(避免重复行)。

    在这里插入图片描述

    例如:查询学生的姓名和所在系。即:求 Student 关系上学生姓名和所在系两个属性上的投影。

    在这里插入图片描述

    连接运算(JOIN 多表级联)

    在这里插入图片描述

    连接运算有以下类型:

    • 等值连接:是条件连接(或称 θ 连接)在连接运算符为 “=” 号时。例如:select * from A, B where A.学号=B.学号

    • 非等值连接:对比等值连接,例如:select * from B, B mm where B.成绩>mm.成绩

    • 自连接:自己和自己做笛卡尔积,例如:select * from A mm, A tt where mm.姓名=tt.姓名

    • 自然连接:自然连接是一种特殊的等值连接,它要求两个关系中进行比较的分量必须是相同的属性组,并且在结果中把重复的属性列去掉。即:自然连接使用多表中所有相同字段(不但值相同,名字也要相同)进行连接(两表中有几个相同,就连接合并几个相同字段)。例如:select * from A natural join B

    • 外连接(Outer Join):将两个表等值连接了起来,次结果会将 A 表或 B 表中不符合的行删除。此时保留不合格的次行信息,便有了左外连接和右外连接和全连接。

      • 左外连接(LEFT OUTER JOIN 或 LEFT JOIN),左表 A 的记录将会全部表示出来,而右表 B 只会显示符合搜索条件的记录。右表记录不足的地方均为 NULL。例如:select * from A left outer join B on A.成绩=B.成绩 order by A.学号
      • 右外连接(RIGHT OUTER JOIN 或 RIGHT JOIN),与左外连接实现效果相反。
      • 全连接(FULL OUTER JOIN 或 FULL JOIN):同时实现了左外和右外连接的效果。

    除运算

    除运算是同时从行和列角度进行运算。

    • 给定关系 R (X,Y) 和 S (Y,Z),其中 X,Y,Z 为属性组。
    • R 中的 Y 与 S 中的 Y 可以有不同的属性名,但必须出自相同的域集。
    • R 与 S 的除运算得到一个新的关系 P(X),P 是 R 中满足下列条件的元组在 X 属性列上的投影:元组在 X 上分量值 x 的象集 Yx 包含 S 在 Y 上投影的集合,记作:
      在这里插入图片描述

    在这里插入图片描述

    示例:设关系 R、S 分别为下图。

    • R
      在这里插入图片描述

    • S
      在这里插入图片描述

    • R / S
      在这里插入图片描述

    在关系 R 中,A 可以取四个值 {a1,a2,a3,a4}

    • a1 的象集为 {(b1,c2),(b2,c3),(b2,c1)}
    • a2 的象集为 {(b3,c7),(b2,c3)}
    • a3 的象集为 {(b4,c6)}
    • a4 的象集为 {(b6,c6)}

    关系 S 在 (B,C) 上的投影为:{(b1,c2),(b2,c1),(b2,c3) }

    只有 a1 的象集包含了 S 在 (B,C) 属性组上的投影,所以 R / S = {a1}。

    主流的 RDBMS

    下面列举笔者使用过的几个主流 RDBMS:

    • Oracle:Oracle 公司前身叫 SDL,由 Larry Ellison 和另两个编程人员在 1977 创办,是最早的 RDBMS 厂商之一。1983 年,Oracle 公司发布了世界上第一个商业化 RDBMS。

    • MySQL:是一个轻量级的开源 RDBMS,开发者为瑞典 MySQL AB公司。MySQL 是最流行的关系型数据库管理系统之一,在 2008 年被 Sun 公司收购,然后又被 Oracle 收购并闭源。在社区切出了开源分支 MariaDB,所以 MySQL 常被诟病为不纯粹的开源软件。

    • PostgreSQL:是以加州大学伯克利分校计算机系开发的 ORDBMS(对象关系型数据库管理系统),完全开源并由社区驱动,具有可以说是目前世界上最丰富的数据类型的支持。另外,PostgreSQL 是目前唯一一个同时支持事务、子查询、多版本并行控制系统、数据完整性检查等特性的开源数据库管理系统。

    参考文档

    https://blog.csdn.net/sjjsaaaa/article/details/106781879

    展开全文
  • 关系数据库设计理论

    2021-04-10 21:43:27
    理论层面讨论关系型数据库设计。本文主要讨论如何化简BC范式。 关系型数据库最重要的就是 关系二字,而关系常常要存在约束,函数依赖就是一个最常见的约束。 函数依赖(FD) 定义 定义:若关系R的两个元组在属性A1...

    从理论层面讨论关系型数据库的设计。本文主要讨论如何化简BC范式。

    关系型数据库最重要的就是 关系二字,而关系常常要存在约束,函数依赖就是一个最常见的约束。

    函数依赖(FD)

    定义

    定义:若关系R的两个元组在属性A1,A2,…,An上一致(即对应分量值相等),那么它们必定在其他属性B1,B2,…,Bm上也一致。

    记为A1,A2,…,An一>B1,B2,…,Bm,称为A1,A2,…,An 函数决定 B1,B2,…,Bm

    等价于

    A1,A2,…,An一>B1

    A1,A2,…,An一>B2

    A1,A2,…,An一>Bm

    若关系R上的每个实例都能使一个给定的FD为真,则称R满足 函数依赖f

    关系的键

    若满足下列条件,则认为一个/多个属性集{ A1,A2,…,An}是关系R的

    • 这些属性 函数决定 关系的所有其他属性。<==> R中不可能有两个不同元组具有相同的 A1,A2,…,An值。
    • 在{ A1,A2,…,An}的真子集中,没有一个能函数决定R的所有其他属性。键必须是最小的!

    当键只有一个属性A时,称A为键

    一个关系可能有多个键,通常需要设置一个主键。(primary key)

    超键

    键的超集,因此每个键都是超键.

    函数依赖的规则

    即假设已知道关系满足一些FD集合,如何通过已知FD推导出其他存在的FD。

    对FD集合S和T,若关系实例集合满足S于其满足T的情况一样,就认为S和T等价

    若满足T中所有FD的每个关系实例也满足S中所有的FD,则认为S是从T中推断而来的

    分解/结合规则

    分解规则:

    使用FD集合: A1,A2,…,An一>Bi(i=1,2,…,m)替换FD集合:A1,A2,…,An一>B1,B2,…,Bm

    组合规则:

    使用FD集合:A1,A2,…,An一>B1,B2,…,Bm替换FD集合: A1,A2,…,An一>Bi(i=1,2,…,m)。

    平凡函数依赖规则

    若关系上的一个约束对所有关系实例都成立,且与其他约束无关,则称其为平凡的

    即平凡FD右边是左边的子集

    平凡函数依赖规则:

    A1,A2,…,An一>B1,B2,…,Bm等价于A1,A2,…,An一>C1,C2,…,Ck

    C是在集合B中而不在A中的属性

    传递规则

    若关系R中有FD:A1,A2,…,An一>B1,B2,…,Bm 和B1,B2,…,Bm 一>C1,C2,…,Ck 都成立,那么A1,A2,…,An一>C1,C2,…,Ck 在R中也成立。

    可以使用闭包来验证

    属性的闭包

    算法 3.7

    Input: 属性集合{A1,A2,...,An},FD集合S
    Output: 闭包{A1,A2,...,An}+
    
    1. 如果必要,分解S中的FD,使每个FD右边只有一个属性
    2. 设X为最后输出(闭包)。初始化为{A1,A2,...,An}
    3. 反复寻找FD:B1B2...Bm —> C, s.t B1B2...Bm在X中且C不在X中;
       若找到,则将C加入X,并重复该步骤。
       当最终X不能再加入任何元素后,本步骤结束
    4. 得到结果X
    

    很像Dijkstra算法

    应用:

    • 使用闭包算法可以用来判断任一给定的FDA1,A2,…,An一>B是否可以由FD集合推导出来。

      只要计算FD集合计算闭包,若B在闭包中,则可以根据FD集合推导出来。

    • 使用闭包算法判断属性集合是否是键,只有当A1,A2,…,An 是超键时,其闭包才会包括所有属性。

      若要验证A1,A2,…,An是否是键,则先求闭包,看是否包含了所有属性,再检查最小性

    FD的闭包

    有些情况下,需要使用FD集合来表示一个关系的完全FD集合。但因为FD集合中等价的集合太多(基本集太多)。为了避免基本集激增,只考虑右边为单一属性的基本集。

    最小化基本集

    • B中所有FD的右边均为单一属性
    • 从B中删除任何一个FD后,该集合不再是基本集
    • 对B中任何一个FD,若从其左边删除一个或多个属性,B将不是基本集

    无平凡FD

    Armstrong公理

    判断FD能否从已知FD集合推断出了,除了闭包算法,也可以使用该公理

    • 自反律

      若{B1,B2,…,Bm}⊆{A1,A2,…,An} 则 A1,A2,…,An一>B1,B2,…,Bm

      即平凡FD

    • 增广律

      若A1,A2,…,An一>B1,B2,…,Bm

      则A1,A2,…,AnC1,C2,…,Ck 一>B1,B2,…,BmC1,C2,…,Ck对于任何属性集合C1,C2,…,Ck 都成立

    • 传递律

      若有A1,A2,…,An一>B1,B2,…,Bm 和B1,B2,…,Bm 一>C1,C2,…,Ck 都成立,那么A1,A2,…,An一>C1,C2,…,Ck 也成立

    投影函数依赖

    如何根据已有的关系R和他的FD集合S, 得到R的投影 R1L®的FD集合?

    原则上可以通过集合S进行推断,找到只包含R1的属性,但这样emmm未免太麻烦。

    算法3.12

    Input: 关系R和投影得到的R1,以及在R中成立的FD集合S
    Output: 在R1中成立的FD集合S
    
    1. 设T为最终输出,T初始化为∅
    2. 对于R1属性的每一个子集X,根据FD集合S计算X+。
       对所有在X+中且属于R1的属性A,将非平凡FD: X—>A添加到T中
    3. 现在T为在R1成立的FD基本集,但不是最小化基本集。用下列方法构造最小化基本集
       a. 若T中某FD F可通过其他FD推断出来,则从T中删除F
       b. 若Y—>B在T中,且Y至少有两个属性,从Y中删除一个属性改为Z.
       	  若Z->B可以被推断出来,则用Z->B替换Y->B
       C. 以各种方式执行ab直到T不再变化。
    

    emmm,这算法就挺麻烦的。

    BC范式

    啊,前面说了那么多就是为了引出BC范式。

    首先来看为什么要有BC范式

    因为我们在设计数据库时,当你试图在一个关系中包含过多信息是,就会产生 异常,例如:

    • 冗余
    • 更新异常
    • 删除异常

    而我们一般使用 分解关系的方法来消除异常,BC范式就是一个确保异常不存在的条件!

    定义

    BC范式,即BCNF

    关系R属于BCNF iff 如果R中非平凡FD A1,A2,…,An一>B1,B2,…,Bm成立则{A1,A2,…,An} 是关系R的键

    也就是说,每个非平凡FD的左边都必须是超键

    二元关系一定是BCNF

    分解为BCNF

    策略:

    1. 找到违反BCNF的非平凡FD A1,A2,…,An一>B1,B2,…,Bm.

    2. 尽可能地向FD右边增加由A1,A2,…,An决定的属性(可以减少工作量)

    3. 将属性集合分为两个关系模式。

      一个包含了上述FD的所有属性,另一个包含该FD左边属性和不属于该FD的所有属性

    4. 再找到这两个关系模式的FD集合,判断是否为BCNF,若是则结束。若不是则对该FD再1执行上述操作。

    算法3.20

    BCNF分解算法

    Input: 关系R0和其FD集合 S0
    Output: 由R0分解出的关系集合,旗帜每个关系集合都属于BCNF
    
    1. 检验R是否属于BCNF,若是,则直接返回{R}
    2. 若存在BCNF违例,假设为X->Y。
       使用算法3.7计算X+,选择R1=X+为一个关系列表。
       使用另一个关系列表R2包含X及不在X+中的属性
    3. 使用算法3.12计算R1和R2的FD集合,分别即为S1,S2
    4. 使用本算法递归地分解R1,R2.最后返回分解的集合
    

    Example

    R(A,B,C,D) FD: AB->C、C->D、D->A

    对{A,B,C,D}各个子集求闭包

    {A}+={A}, {B}+={B}, {C}+={C,D,A}, {D}+={D,A}

    {A,B}+={A,B,C,D}, {A,C}+={A,C}, {A,D}+={A,D},{B,C}+={A,B,C,D}, {B,D}+={A,B,C,D}

    可以得到 AB, BC, BD 都是键,所以无需继续求闭包了(都是超键)

    FD集合中:C->D, D->A不是BCNF

    选择C->D

    将属性划分为(A,D,C) 和(B,C)

    可知(B,C)一定属于BCNF(二元关系一定是)

    现在求(A,D,C)的FD集合,使用算法3.12

    FD为: C->D, D->A

    且(A,D,C)中C为键,

    所以D->A违反BCNF,所以(A,D,C)不属于BCNF

    将(A,D,C)分为

    (A,D), (C,D)为BCNF(二元关系一定是)

    所以分解为:(B,C) (A,D) (C,D)

    展开全文
  • 关系型数据库设计

    2013-10-20 22:40:38
    一 Codd的RDBMS12法则——...在1985年,Codd 博士发布了12条规则,这些规则简明的定义出一个关系型数据库的理念,它们被作为所有关系数据库系统的设计指导性方针。 信息法则 关系数据库中的所有信息都用唯一的一

    一 Codd的RDBMS12法则——RDBMS的起源

      Edgar Frank Codd(埃德加·弗兰克·科德)被誉为“关系数据库之父”,并因为在数据库管理系统的理论和实践方面的杰出贡献于1981年获图灵奖。在1985年,Codd 博士发布了12条规则,这些规则简明的定义出一个关系型数据库的理念,它们被作为所有关系数据库系统的设计指导性方针。

    1. 信息法则 关系数据库中的所有信息都用唯一的一种方式表示——表中的值。
    2. 保证访问法则 依靠表名、主键值和列名的组合,保证能访问每个数据项。
    3. 空值的系统化处理 支持空值(NULL),以系统化的方式处理空值,空值不依赖于数据类型。
    4. 基于关系模型的动态联机目录 数据库的描述应该是自描述的,在逻辑级别上和普通数据采用同样的表示方式,即数据库必须含有描述该数据库结构的系统表或者数据库描述信息应该包含在用户可以访问的表中。
    5. 统一的数据子语言法则 一个关系数据库系统可以支持几种语言和多种终端使用方式,但必须至少有一种语言,它的语句能够一某种定义良好的语法表示为字符串,并能全面地支持以下所有规则:数据定义、视图定义、数据操作、约束、授权以及事务。(这种语言就是SQL)
    6. 视图更新法则 所有理论上可以更新的视图也可以由系统更新。
    7. 高级的插入、更新和删除操作 把一个基础关系或派生关系作为单个操作对象处理的能力不仅适应于数据的检索,还适用于数据的插入、修改个删除,即在插入、修改和删除操作中数据行被视作集合。
    8. 数据的物理独立性 不管数据库的数据在存储表示或访问方式上怎么变化,应用程序和终端活动都保持着逻辑上的不变性。
    9. 数据的逻辑独立性 当对表做了理论上不会损害信息的改变时,应用程序和终端活动都会保持逻辑上的不变性。
    10. 数据完整性的独立性 专用于某个关系型数据库的完整性约束必须可以用关系数据库子语言定义,而且可以存储在数据目录中,而非程序中。
    11. 分布独立性 不管数据在物理是否分布式存储,或者任何时候改变分布策略,RDBMS的数据操纵子语言必须能使应用程序和终端活动保持逻辑上的不变性。
    12. 非破坏性法则 如果一个关系数据库系统支持某种低级(一次处理单个记录)语言,那么这个低级语言不能违反或绕过更高级语言(一次处理多个记录)规定的完整性法则或约束,即用户不能以任何方式违反数据库的约束。

      二 关系型数据库设计阶段

      (一)规划阶段

      规划阶段的主要工作是对数据库的必要性和可行性进行分析。确定是否需要使用数据库,使用哪种类型的数据库,使用哪个数据库产品。

      (二)概念阶段

      概念阶段的主要工作是收集并分析需求。识别需求,主要是识别数据实体和业务规则。对于一个系统来说,数据库的主要包括业务数据和非业务数据,而业务数据的定义,则依赖于在此阶段对用户需求的分析。需要尽量识别业务实体和业务规则,对系统的整体有初步的认识,并理解数据的流动过程。理论上,该阶段将参考或产出多种文档,比如“用例图”,“数据流图”以及其他一些项目文档。如果能够在该阶段产出这些成果,无疑将会对后期进行莫大的帮助。当然,很多文档已超出数据库设计者的考虑范围。而且,如果你并不精通该领域以及用户的业务,那么请放弃自己独立完成用户需求分析的想法。用户并不是技术专家,而当你自身不能扮演“业务顾问”的角色时,请你选择与项目组的相关人员合作,或者将其视为风险呈报给PM。再次强调,大多数情况,用户只是行业从业者,而非职业技术人员,我们仅仅从用户那里收集需求,而非依赖于用户的知识。

      记录用户需求时,可以使用一些技巧,当然这部分内容有些可能会超出数据库设计人员的职责:

    • 努力维护一系列包含了系统设计和规格说明信息的文档,如会议记录、访谈记录、关键用户期望、功能规格、技术规格、测试规格等。
    • 频繁与干系人沟通并收集反馈。
    • 标记出你自己添加的,不属于客户要求的,未决内容。
    • 与所有关键干系人尽快确认项目范围,并力求冻结需求。

      此外,必须严谨处理业务规则,并详细记录。在之后的阶段,将会根据这些业务规则进行设计。

      当该阶段结束时,你应该能够回答以下问题:

    • 需要哪些数据?
    • 数据该被怎样使用?
    • 哪些规则控制着数据的使用?
    • 谁会使用何种数据?
    • 客户想在核心功能界面或者报表上看到哪些内容?
    • 数据现在在哪里?
    • 数据是否与其他系统有交互、集成或同步?
    • 主题数据有哪些?
    • 核心数据价值几何,对可靠性的要求程度?

      并且得到如下信息:

    • 实体和关系
    • 属性和域
    • 可以在数据库中强制执行的业务规则
    • 需要使用数据库的业务过程

      (三)逻辑阶段

      逻辑阶段的主要工作是绘制E-R图,或者说是建模。建模工具很多,有不同的图形表示方法和软件。这些工具和软件的使用并非关键,笔者也不建议读者花大量时间在建模方法的选择上。对于大多数应用来说,E-R图足以描述实体间的关系。建模关键是思想而不是工具,软件只是起到辅助作用,识别实体关系才是本阶段的重点。

      除了实体关系,我们还应该考虑属性的域(值类型、范围、约束)

      (四)实现阶段

      实现阶段主要针对选择的RDBMS定义E-R图对应的表,考虑属性类型和范围以及约束。

      (五)物理阶段

      物理阶段是一个验证并调优的阶段,是在实际物理设备上部署数据库,并进行测试和调优。

      三 设计原则

      (一)降低对数据库功能的依赖

      功能应该由程序实现,而非DB实现。原因在于,如果功能由DB实现时,一旦更换的DBMS不如之前的系统强大,不能实现某些功能,这时我们将不得不去修改代码。所以,为了杜绝此类情况的发生,功能应该有程序实现,数据库仅仅负责数据的存储,以达到最低的耦合。

      (二)定义实体关系的原则

      当定义一个实体与其他实体之间的关系时,需要考量如下:

    • 牵涉到的实体 识别出关系所涉及的所有实体。
    • 所有权 考虑一个实体“拥有”另一个实体的情况。
    • 基数 考量一个实体的实例和另一个实体实例关联的数量。

      关系与表数量

    • 描述1:1关系最少需要1张表。
    • 描述1:n关系最少需要2张表。
    • 描述n:n关系最少需要3张表。

      (三)列意味着唯一的值

      如果表示坐标(0,0),应该使用两列表示,而不是将“0,0”放在1个列中。

      (四)列的顺序

      列的顺序对于表来说无关紧要,但是从习惯上来说,采用“主键+外键+实体数据+非实体数据”这样的顺序对列进行排序显然能得到比较好的可读性。

      (五)定义主键和外键

      数据表必须定义主键和外键(如果有外键)。定义主键和外键不仅是RDBMS的要求,同时也是开发的要求。几乎所有的代码生成器都需要这些信息来生成常用方法的代码(包括SQL文和引用),所以,定义主键和外键在开发阶段是必须的。之所以说在开发阶段是必须的是因为,有不少团队出于性能考虑会在进行大量测试后,在保证参照完整性不会出现大的缺陷后,会删除掉DB的所有外键,以达到最优性能。笔者认为,在性能没有出现问题时应该保留外键,而即便性能真的出现问题,也应该对SQL文进行优化,而非放弃外键约束。

      (六)选择键

      1 人工键与自然键

      人工健——实体的非自然属性,根据需要由人强加的,如GUID,其对实体毫无意义;自然健——实体的自然属性,如身份证编号。

      人工键的好处:

    • 键值永远不变
    • 永远是单列存储

      人工键的缺点:

    • 因为人工键是没有实际意义的唯一值,所以不能通过人工键来避免重复行。

      笔者建议全部使用人工键。原因如下:

    • 在设计阶段我们无法预测到代码真正需要的值,所以干脆放弃猜测键,而使用人工键。
    • 人工键复杂处理实体关系,而不负责任何属性描述,这样的设计使得实体关系与实体内容得到高度解耦,这样做的设计思路更加清晰。

      笔者的另一个建议是——每张表都需要有一个对用户而言有意义的自然键,在特殊情况下也许找不到这样一个项,此时可以使用复合键。这个键我在程序中并不会使用其作为唯一标识,但是却可以在对数据库直接进行查询时使用。

      使用人工键的另一根弊端,主要源自对查询性能的考量,因此选择人工键的形式(列的类型)很重要:

    • 自增值类型 由于类型轻巧查询效率更好,但取值有限。
    • GUID 查询效率不如值类型,但是取值无限,且对开发人员更加亲切。

      2 智能健与非智能键

      智能键——键值包含额外信息,其根据某种约定好的编码规范进行编码,从键值本身可以获取某些信息;非智能键,单纯的无意义键值,如自增的数字或GUID。

      智能键是一把双刃剑,开发人员偏爱这种包含信息的键值,程序盼望着其中潜在的数据;数据库管理员或者设计者则讨厌这种智能键,原因也是很显然的,智能键对数据库是潜在的风险。前面提到,数据库设计的原则之一是不要把具有独立意义的值的组合实现到一个单一的列中,应该使用多个独立的列。数据库设计者,更希望开发人员通过拼接多个列来得到智能键,即以复合主键的形式给开发人员使用,而不是将一个列的值分解后使用。开发人员应该接受这种数据库设计,但是很多开发者却想不明白两者的优略。笔者认为,使用单一列实现智能键存在这样一个风险,就是我们可能在设计阶段无法预期到编码规则可能会在后期发生变化。比如,构成智能键的局部键的值用完而引起规则变化或者长度变化,这种编码规则的变化对于程序的有效性验证与智能键解析是破坏性的,这是系统运维人员最不希望看到的。所以笔者建议如果需要智能键,请在业务逻辑层封装(使用只读属性),不要再持久化层实现,以避免上述问题。

      (七)是否允许NULL

      关于NULL我们需要了解它的几个特性:

    • 任何值和NULL拼接后都为NULL。
    • 所有与NULL进行的数学操作都返回NULL。
    • 引入NULL后,逻辑不易处理。

      那么我们是否应该允许列为空呢?笔者认为这个问题的答案受到我们的开发语言的影响。以C#为例,因为引入了可空类型来处理数据库值类型为NULL的情形,所以是否允许为空对开发者来说意义并不大。但有一点必须注意,就是验证非空必须要在程序集进行处理,而不该依赖于DBMS的非空约束,必须确保完整数据(所有必须的属性均被赋值)到达DB(所谓的“安全区”,我们必须定义在多层系统中那些区域得到的数据是安全而纯净的)。

      (八)属性切割

      一种错误想法是,属性与列是1:1的关系。对于开发者,我们公开属性而非字段。举个例子来说,对于实体“员工”有“名字”这一属性,“名字”可以再被分解为“姓”和“名”,对于开发人员来说,显然第二种数据结构更受青睐(“姓”和“名”作为两个字段)。所以,在设计时我们也应该根据需要考虑是否切割属性。

      (九)规范化——范式

      当笔者还在大学时,范式是学习关系型数据库时最头疼的问题。我想也许会有读者仍然不理解范式的价值,简单来说——范式将帮助我们来保证数据的有效性和完整性。规范化的目的如下:

    • 消灭重复数据。
    • 避免编写不必要的,用来使重复数据同步的代码。
    • 保持表的瘦身,以及减从一张表中读取数据时需要进行的读操作数量。
    • 最大化聚集索引的使用,从而可以进行更优化的数据访问和联结。
    • 减少每张表使用的索引数量,因为维护索引的成本很高。

      规范化旨在——挑出复杂的实体,从中抽取出简单的实体。这个过程一直持续下去,直到数据库中每个表都只代表一件事物,并且表中每个描述的都是这件事物为止。

      1 规范化实体和属性(去除冗余)

      1NF:每个属性都只应表示一个单一的值,而非多个值。

      需要考虑几点:

    • 属性是原子性的 需要考虑熟悉是否分解的足够彻底,使得每个属性都表示一个单一的值。(和“(三)列意味着唯一的值”描述的原则相同。)分解原则为——当你需要分开处理每个部分时才分解值,并且分解到足够用就行。(即使当前不需要彻底分解属性,也应该考虑未来可能的需求变更。)
    • 属性的所有实例必须包含相同数量的值 实体有固定数量的属性(表有固定数量的列)。设计实体时,要让每个属性只有固定数量的值与其相关联。
    • 实体中出现的所有实体类型都必须不同

      当前设计不符合1NF的“臭味”:

    • 包含分隔符类字符的字符串数据。
    • 名字尾端有数字的属性。
    • 没有定义键或键定义不好的表。

      2 属性间的关系(去除冗余)

      2NF-实体必须符合1NF,每个属性描述的东西都必须针对整个键(可以理解为oop中类型属性的内聚性)。

      当前设计不符合2NF的“臭味”:

    • 重复的键属性名字前缀(设计之外的数据冗余) 表明这些值可能描述了某些额外的实体。
    • 有重复的数据组(设计之外的数据冗余) 这标志着属性间有函数依赖型。
    • 没有外键的复合主键 这标志着键中的键值可能标识了多种事物,而不是一种事物。

      3NF-实体必须符合2NF,非键属性不能描述其他非键属性。(与2NF不同,3NF处理的是非键属性和非键属性之间的关系,而不是和键属性之间的关系。

      当前设计不符合3NF的“臭味”:

    • 多个属性有同样的前缀。
    • 重复的数据组。
    • 汇总的数据,所引用的数据在一个完全不同的实体中。(有些人倾向于使用视图,我更倾向于使用对象集合,即由程序来完成。)

      BCNF-实体满足第一范式,所有属性完全依赖于某个键,如果所有的判定都是一个键,则实体满足BCNF。(BCNF简单地扩展了以前的范式,它说的是:一个实体可能有若干个键,所有属性都必须依赖于这些键中的一个,也可以理解为“每个键必须唯一标识实体,每个非键熟悉必须描述实体。”

      3 去除实体组合键中的冗余

      4NF-实体必须满足BCNF,在一个属性与实体的键之间,多值依赖(一条记录在整个表的唯一性由多个值组合起来决定的)不能超过一个。

      当前设计不符合4NF的“臭味”:

    • 三元关系(实体:实体:实体)。
    • 潜伏的多值属性。(如多个手机号。)
    • 临时数据或历史值。(需要将历史数据的主体提出,否则将存在大量冗余。)

      4 尽量将所有关系分解为二元关系 

      5NF-实体必须满足4NF,当分解的信息无损的时候,确保所有关系都被分解为二元关系。

      5NF保证在第四范式中存在的任何可以分解为实体的三元关系都被分解。有的三元关系可以在不丢失信息的前提下被分解为二元关系,当分解为两个二元关系的过程要丢失信息时,关系被宣称为处于第四范式中。所以,第五范式建议是,最好把现有的三元关系都分解为3个二元关系。

      需要注意的是,规范化的结果可能是更多的表,更复杂的查询。因此,处理到何种程度,取决于性能和数据架构的多方考量。建议规范化到第四范式,原因是5NF的判断太过隐晦。例如:表X(老师,学生,课程)是一个三元关系,可以分解为表A(老师,学生),表B(学生,课程),表C(老师,课程)。表X表示某个老师是上某个学生的某个课程的老师;表A表示老师教学生;表B表示学生上课;表C表示老师教课。单独看是无法发现问题的,但是从数据出发,"表X=表A+表B+表C"并不一定成立,即不能通过连接构建分解前的数据。因为可能有多种组合,丧失了表X反馈出的业务规则。这种现象,容易在设计阶段被忽略,但好在在开放阶段会被显现,而且并不经常发生。

      推荐做法:

    • 尽可能地遵守上述规范化原则。
    • 所有属性描述的都应该是体现被建模实体的本质的内容。
    • 至少必须有一个键,它唯一地标识和描述了所建实体的本质。
    • 主键要谨慎选择。
    • 在逻辑阶段能做多少规范化就做多少(性能不是逻辑阶段考虑的范畴)。

      (十)选择数据类型(MS SQL 2008)

      MS SQL的常用类型:

     

    精确数字 不会发生精度损失 bit tinyint smallint int bigint decimal
    近似数字 对于极值可能发生精度损失 float(N) real
    日期和时间   date time smalldatetime datetime datetime2 datetimeoffset
    二进制数据   bingary(N) varbinary(N) varbinary(max)
    字符(串)数据   char(N) varchar(N) varchar(max) nchar(N) nvarchar(N) nvarchar(max)
    存储任意数据   sql_variant
    时间戳   timestamp
    GUID   uniqueidentifier
    XML 不要试图使用该类型规避1NF xml
    空间数据   geometry geography
    层次数据   heirarchyid

      MS SQL中不在支持的或糟糕的类型选择

    • image:被varbinary(max)取代。
    • text和ntext:被varchar(max)和nvarchar(max)取代。
    • money和smallmoney:开发过程中不好用,建议使用decimal。

      常用类型选择:

      类型选择的最基本规则是选择满足需要的最轻的类型,因为这样查询更快。

     

    bool 建议使用bit而非char(1),因为开发语言对其支持觉好,可以直接映射为bool或bool?。
    大值数据 使用所有备选类型中最小的那种,类型越大,查询越慢,当字节大于8000时,应使用max。
    主键 自增主键根据预期范围选择int或bigint,GUID使用uniqueidentifier而非varchar(N)。

      (十一)优化并行

      设计DB时就应该考虑到对并行进行优化,比如,MS SQL中的timestamp类型就是极好的选择。

      四 命名规则

    • 表——“模块名_表名”。表名最好不要用复数,原因是在使用ORM框架开发时,代码生成器根据DB生成类定义,表生成了某个实例的类型定义,而不是实例集合。表名不要太长。原因之一,某些软件对表名最大长度有限制;原因之二,使用代码生成器往往会根据表名生产类型名称,之后懒人会直接使用这一名称,如果将太长的名称跨网络边界显然不是明智之举。
    • 字段——bool类型用“Is”、“Can”、“Has”等表示;日期类型命名必须包含“Date”;时间类型必须包含“Time”。
    • 存储过程——使用“proc_”前缀。
    • 视图——使用“view_”前缀。
    • 触发器——使用“trig_”前缀。
    展开全文
  • 数据库是按照数据结构来组织,存储和管理数据的仓库,我们用关系型数据库(RDBMS)来存储和管理大数据量。 关系数据库是指采用了关系模型来组织数据的数据库,其以行和列的形式存储数据,以便于用户理解,关系型...
  • 文章目录异常函数依赖范式 异常 数据冗余大:某个属性的值重复次数过多 ...数据依赖: 同一个关系中,属性间的相互依赖和相互制约。包括函数依赖、多值依赖、连接依赖。 函数依赖: 指属性或属性之间一一对...
  • CAP理论设计分布式web系统的一个很关键的定律,其主要内容是(非官方定义): When designing distributed web services, there are three properties that are commonly desired: consistency, availability, ...
  • 为什么使用数据库 许多人会问为什么软件存储数据会使用数据库?记得当时有一位做Flash开发的朋友说,你们做后端开发的一旦牵涉到存储数据就会想用...关系型数据库理论依据是笛卡尔的关系数学理论,但是实际上,大
  • 一、数据库设计的目标(从合理组织数据加以存储的角度): 1).数据的冗余度小; 2).共享性高; 解决方法: 对模式进行分解,分解成一组关系模式,每一关系模式对应一个基本表;使用时,将多个关系模式进行自然...
  • 数据库基础(一)——设计一个关系型数据库 在好几个面试官跟我说数据库是Java程序员的必备技能之后,我终于也开始了我的数据库学习之路,但愿不晚,但愿还来得及。 数据库考点:架构、索引、锁、语法、理论范式。 ...
  • 关系型数据库 范式

    2021-05-26 22:05:57
    关系型数据库 采用关系模型来组织数据 以行和列的形式存储数据 行和列被称为表 一组表组成了数据库 Oracle,SQLServer,DB2,Mysql等 范式 (Normal Form) 范式是关系数据库理论的基础 凡是能够通过关系寻找出来...
  • 关系数据库设计

    2019-06-27 10:30:41
    参考博文: 关系数据库设计理论:...关系型数据库设计:三大范式的通俗理解:https://www.cnblogs.com/wsg25/p/9615100.html 一、数据库设计简介 按照规范设计,将数...
  • 答:ACID理论关系型数据库的基石,它保证了关系型数据库的内在特性1.Atomicity原子性:事务原子性,一件事是一个独立单元,要么完整完成,要么完整回滚,中间不可断2.Consistent 一致性:数据一致性,数据状态...
  • 关系型数据库范式

    2021-03-22 14:20:02
    范式是设计数据库的时候,遵循的一种规范 范式分类 1. 第一范式(1NF) 每一项都是不可以分割的原子项数据, 不能存在合并项 2. 第二范式(2NF) 抽取了核心直接依赖关系, 其他间接关系放在一边 3. 第三范式(3NF) ...
  • MySQL关系型数据库基础 主要内容: 数据库的相关概念 MySQL安装、配置 库管理 表管理 结构化查询语言(SQL) 数据约束:数据要遵循的规则 数据导入、导出 权限管理 数据库事务 10.存储引擎 11.E-R概念模型(设计...
  • 引入问题:如何设计一个关系型数据库? 首先会有一个文件系统进行存储,存储到机械硬盘或者固态硬盘上。 还有程序实例模块把数据的逻辑结构映射出物理结构,接下来细分程序模块 索引模块 几个常见问题: 为...
  • 浅谈关系数据库理论

    2019-07-08 19:10:20
    设计一个适合的关系型数据库的关键是设计关系型数据库的模式,具体包括,数据库中应该包含多少个关系模式,每个关系模式应该包含哪些属性,以及如何将这些相互关联的关系模式组建成一个完整的关系型数据库。...
  • 大型数据库设计

    2011-03-03 13:38:00
    因此在软件系统开发中,数据库设计应遵循必要的数据库范式理论,以减少冗余、保证数据的完整性与正确性。只有在合适的数据库产品上设计出合理的数据库模型,才能降低整个系统的编程和维护难度,提高系统的实际运行...
  • 关系型数据库中数据完整性指的是什么?实体完整性: 每条记录都是独一无二的没有重复的 (主键/唯一约束/唯一索引)参照完整性: 表中的数据要参照其他表已有的数据(外键)域完整性: 数据是有效的 (满足建表的约束 - 数据...
  • 一、非关系型数据库的概念 随着近些年技术方向的不断拓展,大量的NoSql数据库如MongoDB、Redis、Memcache出于简化数据库结构、避免冗余、影响性能的表连接、摒弃复杂分布式的目的被设计。 NoSQL数据库指的是分布式的...
  • 大型数据库设计准则

    2011-07-15 15:47:04
    目前,计算机技术已经广泛地应用于国民经济的各个领域当中,在计算机硬件不断微型化的同时,应用系统也逐渐向着复杂化、大型化的...因此在软件系统开发中,数据库设计应遵循必要的数据库范式理论,以减少冗余、保证数据
  • 文章结合实例研究UML应用于GIS空间数据库的面向对象设计中的理论和技术,解决了系统从对象模型到关系模型的转换和空间矢量数据的关系化的面向对象描述和实现.在此基础上,通过对系统对象的设计来不断完善数据库的结构...
  • 数据库规范化理论数据库逻辑设计理论依据,关系数据库的规范化理论最早是由关系数据库的创始人E.F.Codd于1970提出的。在该理论出现之前,层次和网状数据模型只是遵循其模型本身的故由原则,相关的数据设计和...
  • MySQL | 数据库基础理论、六大设计范式详解

    千次阅读 多人点赞 2019-05-09 04:16:34
    MySQL基础 、关系型数据库与非关系型数据库 、从技术层面了解MySQL 、数据库的范式设计

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 557
精华内容 222
关键字:

关系型数据库设计理论