数据库结构设计
Date date = new date();
System.out.println(date);
//当前时间为:2020-04-05 21:00
一、约束
1.三大类约束
关系级别约束Primay Key,Foreign Key
列级约束Not null,unique
元组约束check
2.五大约束
1>—-主键约束(Primay Key Coustraint)
唯一性,非空性
2>—-唯一约束 (Unique Counstraint)
唯一性,可以空,但只能有一个
3>—-检查约束 (Check Counstraint)
对该列数据的范围、格式的限制(如:年龄、性别等)
4>—-默认约束 (Default Counstraint)
该数据的默认值
5.—-外键约束 (Foreign Key Counstraint)
需要建立两表间的关系并引用主表的列
3.五大约束的语法示例
1>添加主键约束(将stuNo作为主键)
alter table stuInfo
add constraint PK_stuNo primary key (stuNo)
2>添加唯一约束(身份证号唯一,因为每个人的都不一样)
alter table stuInfo
add constraint UQ_stuID unique(stuID)
3>添加默认约束(如果地址不填 默认为“地址不详”)
alter table stuInfo
add constraint DF_stuAddress default (‘地址不详’) for stuAddress
4>添加检查约束 (对年龄加以限定 15-40岁之间)
alter table stuInfo
add constraint CK_stuAge check (stuAge between 15 and 40)
5>添加外键约束 (主表stuInfo和从表stuMarks建立关系,关联字段stuNo)
alter table stuInfo
add constraint FK_stuNo foreign key(stuNo)references stuinfo(stuNo)
4.约束(Constraint)
Microsoft SQL Server 提供的自动保持数据库完整性的一种方法,定义了可输入表或表的单个列中的数据的限制条件(有关数据完整性的介绍请参见第9 章)。在SQL Server 中有5 种约束:主关键字约束(Primary Key Constraint)、外关键字约束(Foreign Key Constraint)、惟一性约束(Unique Constraint)、检查约束(Check Constraint)和缺省约束(Default Constraint)。
二、关系模式
1.关系的描述
关系模式(Relation Schema)它可以形式化地表示为:
R(U,D,dom,F)
其中R为关系名,U为组成该关系的属性名集合,D为属性组U中属性所来自的域,dom为属性向域的映象集合,F为属性间数据的依赖关系集合。
通常简记为:
R(U)或R(A1,A2,…,An)
其中R为关系名,U为属性名集合,A1,A2,…,An为各属性名。
2.关系模式转换
ER图向关系模式转换涉及到两方面:实体的转换和实体间联系的转换。
①实体的转换:在从ER图转换为关系模式时,一个实体就转换成一个关系模式, 实体的属性就是关系模式的属性,实体的键就是关系的主键。
②实体间联系的转换:实体间存在三种联系即1:1 (一对一)联系,1:m(一对多)联系,m:n(多对多)联系。
3.在从ER向关系模式转换规则如下:
1>1:1 (一对一)联系
方法一:联系转换为独立的关系模式;模式的属性由联系本身的属性及两个实体的键构成;主键由两个实体中的任意一一个键构成。
方法二:联系与一端的实体的关系模式合并,即将联系的属性加入到实体的关系模式内,主键不变。
2>1:m (一对多)联系
方法一:联系转换为独立的关系模式;模式的属性由联系本身的属性及两个实体的键构成;主键由n端实体的键组成。
方法二:与n端的实体的关系模式合并,即将联系的属性加入到实体的关系模式式内,主键不变。
3>m:n (多对多)联系
多对多联系转换成新的独立的模式时,模式的属性由联系本身的属性及两个实体的键构成,主键由两端实体的键组合而成。
三、E-R模型
1.分类
E-R模型的构成成分是实体集、属性和联系集
其表示方法如下:
(1) 实体集用矩形框表示,矩形框内写上实体名。
(2) 实体的属性用椭圆框表示,框内写上属性名,并用无向边与其实体集相连。
(3) 实体间的联系用菱形框表示,联系以适当的含义命名,名字写在菱形框中,用无向连线将参加联系的实体矩形框分别与菱形框相连,并在连线上标明联系的类型,即1—1、1—N或M—N。
因此,E-R模型也称为E-R图。
2.组成
E-R图模型的组成是由实体,属性和联系。其中实体是一个数据的使用者,其代表软件系统中客观存在的生活中的实物,如人、动物,物体、列表、部门、项目等.而同一类实体就构成了一个实体集。实体的内涵用实体类型来表示。实体类型是对实体集中实体的定义。实体中的所有特性称为属性.如用户有姓名、性别、住址、电话等. “实体标识符"是在一个实体中,能够唯一表示实体的属性和属性集的标示符.但针对于一个实体只能使用一个"实体标识符"来标明。实体标识符也就是实体的主键。在ER图中,实体所对应的属性用椭圆型的符号现况表示出来,添加了下划线的名字就是我们所说的标识符。在我们生活的世界中,实体不会是单独存在的,实体和其他的实体之间是有着千丝万缕的联系的。举例某一个人在公司的某个部门工作,其中的实体有"某个人"和"公司的某个部门”,他们之间的有着很多的联系联系。
3.原则
从数据需求分析中分析出系统的实体属性图,需要遵循三范式原则,对实体之间的依赖关系进行了整合,得出系统E-R图。
说明:菱形表示实体之间的关系,用矩形表示实体,用无向直线把菱形与有关实体连接,在直线上标明联系的类型。用椭圆表示实体的属性,并用无向直线把实体与属性联系起来。
四、依赖
1.定义
设R(U)是一个属性集U上的关系模式,X和Y是U的子集。
若对于R(U)的任意两个可能的关系r1、r2,若r1[x]=r2[x],则r1[y]=r2[y],或者若r1[y]不等于r2[y],则r1[x]不等于r2[x],称X决定Y,或者Y依赖X。
2.七类依赖
1>数据依赖
在计算机科学中,数据依赖是指一种状态,当程序结构导致数据引用之前处理过的数据时的状态。其中最重要的是函数依赖和多值依赖。
2>函数依赖
设X,Y是关系R的两个属性集合,当任何时刻R中的任意两个元组中的X属性值相同时,则它们的Y属性值也相同,则称X函数决定Y,或Y函数依赖于X。
3>平凡函数依赖
当关系中属性集合Y是属性集合X的子集时(Y⊆X),存在函数依赖X→Y,即一组属性函数决定它的所有子集,这种函数依赖称为平凡函数依赖。
4>非平凡函数依赖
当关系中属性集合Y不是属性集合X的子集时,存在函数依赖X→Y,则称这种函数依赖为非平凡函数依赖。
5>完全函数依赖
设X,Y是关系R的两个属性集合,X’是X的真子集,存在X→Y,但对每一个X’都有X’!→Y,则称Y完全函数依赖于X。
6>部分函数依赖
设X,Y是关系R的两个属性集合,存在X→Y,若X’是X的真子集,存在X’→Y,则称Y部分函数依赖于X。
7>传递函数依赖
设X,Y,Z是关系R中互不相同的属性集合,存在X→Y(Y !→X),Y→Z,则称Z传递函数依赖于X。
3.函数依赖概念
- 函数依赖不是指关系模式R的某个或某些关系实例满足的约束条件,而是指R的所有关系实例均要满足的约束条件。
- 函数依赖是语义范畴的概念。只能根据数据的语义来确定函数依赖。
例如“姓名→年龄”这个函数依赖只有在不允许有同名人的条件下成立 - 数据库设计者可以对现实世界作强制的规定。例如规定不允许同名人出现,函数依赖“姓名→年龄”成立。所插入的元组必须满足规定的函数依赖,若发现有同名人存在, 则拒绝装入该元组。
4.属性关系
属性之间有三种关系,但并不是每一种关系都存在函数依赖。设R(U)是属性集U上的关系模式,X、Y是U的子集:
● 如果X和Y之间是1:1关系(一对一关系),如学校和校长之间就是1:1关系,则存在函数依赖X → Y和Y →X。
● 如果X和Y之间是1:n关系(一对多关系),如年龄和姓名之间就是1:n关系,则存在函数依赖Y → X。
●如果X和Y之间是m:n关系(多对多关系),如学生和课程之间就是m:n关系,则X和Y之间不存在函数依赖。
五、E-R图转UML图
1.E-R
E-R图:实体-联系图(Entity-Relation Diagram)用来建立数据模型,在数据库系统概论中属于概念设计阶段,ER图提供了表示实体(即数据对象)、属性和联系的方法,用来描述现实世界的概念模型
构成E-R图的基本要素是实体、属性和联系,其表示方法为:
- 实体型:用矩形表示,矩形框内写明实体名;
- 属性:用椭圆形或圆角矩形表示,并用无向边将其与相应的实体连接起来;多值属性由双线连接;主属性名称下加下划线;
- 联系:用菱形表示,菱形框内写明联系名,并用无向边分别与有关实体连接起来,同时在无向边旁标上联系的类型
在E-R图中要明确表明1对多关系,1对1关系和多对多关系。
1对1关系在两个实体连线方向写1;
1对多关系在1的一方写1,多的一方写N;
多对多关系则是在两个实体连线方向各写N,M
2.UML
- 第一类用例图(use case diagram)
- 第二类是静态图 (Static diagram),包括类图、对象图和包图
- 第三类是行为图(Behavior diagram)
- 第四类是交互图(Interactive diagram)
- 第五类是实现图 ( Implementation diagram )。
用例图:由参与者(Actor)、用例(Use Case)以及它们之间的关系构成的用于描述系统功能的动态视图称为用例图
用例图由参与者(Actor)、用例(Use Case)、系统边界、箭头,作用组成,用画图的方法来完成
流程图:圆角矩形表示“开始”与“结束”。矩形表示行动方案、普通工作环节用,菱形表示问题判断或判定(审核/审批/评审)环节,用平行四边形表示输入输出,箭头代表工作流方向.
3.转换
以例题开始
将联系取消换为两个实体之间的关系
例如
n个职工被一个领导管理—>n下属,1领导
一个部门可有多个职工—>(1,n)
一个职工属于一个部门—>(1,1)
故此uml类图可以画成:
六、模式分解
1.模式分解
对于一个模式分解多种多样,但分解后产生模型应该与原模型等价,即保持函数依赖并且无损连接。
2.模式分解的注意事项:
如果一个分解具有无损连接性,则它能够保证不丢失信息,无损连接性不一定能解决插入异常、删除异常、修改复杂、数据冗余等问题
如果一个分解保持了函数依赖,则它可以减轻或解决各种异常情况
3.填表法
1)生成空表格:属性个数作为行,分解的模式个数作为列
2)填写空表格:若分解出的模式出现了某一属性则该行的该属性写下ai,若该分解出的模式不存在该属性填写bij。
3)修正表格:检查若有两行依赖关系前值存在后值有一分解模式存在,则将该后值不存在的分解模式的bij改为ai
4)检查表格:观察是否有一行皆为ai,若存在则数据不会丢失分解。
七、物理 设计
1.数据库物理设计阶段活动
①数据库逻辑模式调整;
②选择或配置基本关系表的文件组织形式,为基本关系表设计数据存取方法或存取路径;
③数据分布设计;
④安全模式设计;
⑤确定系统配置;
⑥物理模式评估。
2.数据库物理设计主要步骤
数据库逻辑模式调整;文件组织与存取设计;数据分布设计;安全模式设计;确定系统配置;物理模式评估。其中将关系模式和相关视图转换为特定数据库管理系统的可支持的表和视图不属于物理设计的范畴。
八、数据模型三个要素
①数据结构
数据结构是所研究的对象类型的集合。它从语法角度表述了客观世界中数据对象本身的结构和数据对象之间的关联关系,是
对系统静态特征的描述。
②数据操作
数据操作是对数据库中对象的实例允许执行的操作的集合,主要指检索和更新(插入、删除、修改)两类操作。数据模型必须定义这些操作的确切含义、操作符号、操作规则(如优先级)以及实现操作的语言。数据操作是对系统动态特性的描述。
③数据完整性约束
数据完整性约束是一组完整性规则的集合,规定数据库状态及状态变化所应满足的条件,以保证数据的正确性、有效性和相容性
九、索引
1.定义概念
索引是为了加速对表中数据行的检索而创建的一种分散的存储结构。索引是针对表而建立的,它是由数据页面以外的索引页面组成的,每个索引页面中的行都会含有逻辑指针,以便加速检索物理数据。在数据库关系图中,可以在选定表的“索引/键”属性页中创建、编辑或删除每个索引类型。当保存索引所附加到的表,或保存该表所在的关系图时,索引将保存在数据库中。
2.作用
在数据库系统中建立索引主要有以下作用:
(1)快速取数据;
(2)保证数据记录的唯一性;
(3)实现表与表之间的参照完整性;
(4)在使用ORDER by、group by子句进行数据检索时,利用索引可以减少排序和分组的时间。
3.优缺点
1>优点
1.大大加快数据的检索速度;
2.创建唯一性索引,保证数据库表中每一行数据的唯一性;
3.加速表和表之间的连接;
4.在使用分组和排序子句进行数据检索时,可以显著减少查询中分组和排序的时间。
2>缺点
1.索引需要占物理空间。
2.当对表中的数据进行增加、删除和修改的时候,索引也要动态的维护,降低了数据的维护速度。
4.索引类型
根据数据库的功能,可以在数据库设计器中创建四种索引:单列索引、唯一索引、主键索引和聚集索引。
1>普通索引
最基本的索引类型,没有唯一性之类的限制
2>唯一索引
唯一索引是不允许其中任何两行具有相同索引值的索引。
当现有数据中存在重复的键值时,大多数数据库不允许将新创建的唯一索引与表一起保存。数据库还可能防止添加将在表中创建重复键值的新数据。
3>主键索引
简称为主索引,数据库表中一列或列组合(字段)的值唯一标识表中的每一行。该列称为表的主键。
在数据库关系图中为表定义主键将自动创建主键索引,主键索引是唯一索引的特定类型。该索引要求主键中的每个值都唯一。当在查询中使用主键索引时,它还允许对数据的快速访问。
提示尽管唯一索引有助于定位信息,但为获得最佳性能结果,建议改用主键索引。
4>候选索引
与主索引一样要求字段值的唯一性,并决定了处理记录的顺序。在数据库和自由表中,可以为每个表建立多个候选索引。
5>聚集索引
也称为聚簇索引,在聚集索引中,表中行的物理顺序与键值的逻辑(索引)顺序相同。一个表只能包含一个聚集索引, 即如果存在聚集索引,就不能再指定CLUSTERED 关键字。
索引不是聚集索引,则表中行的物理顺序与键值的逻辑顺序不匹配。与非聚集索引相比,聚集索引通常提供更快的数据访问速度。聚集索引更适用于对很少对基表进行增删改操作的情况。
如果在表中创建了主键约束,SQL Server将自动为其产生唯一性约束。在创建主键约束时,指定了CLUSTERED关键字或干脆没有制定该关键字,SQL Sever将会自动为表生成唯一聚集索引。
6>非聚集索引
也叫非簇索引,在非聚集索引中,数据库表中记录的物理顺序与索引顺序可以不相同。一个表中只能有一个聚集索引,但表中的每一列都可以有自己的非聚集索引。如果在表中创建了主键约束,SQL Server将自动为其产生唯一性约束。在创建主键约束时,如果制定CLUSTERED关键字,则将为表产生唯一聚集索引。
十、文件结构
数据库文件结构分为:散列文件组织,堆文件组织,顺序文件组织,聚集文件组
1.散列文件
利用散列存储方式组织的文件,亦称为直接存取文件。散列文件的优点是:文件随机存放,记录不需进行排序;插入、删除方便;存取速度快;不需要索引区,节省存储空间。其缺点是:不能进行顺序存取,只能按关键字随机存取,且询问方式只限于简单询问,并且在经过多次插入、删除后,也可能造成文件结构不合理,需要重新组织文件。
2.堆文件
如果数据库中的一一个基本表的数据量很少,并且插入、删除、更新等操作非常频繁,该基本表可以采用堆文件组织形式。因为堆文件无需建立索引,维护代价非常低。虽然堆文件的数据访问效率较低,但在数据量很少时,定位文件记录的时间非常短。
3.顺序文件
文件信息存放在若干连续的物理块中。其优点是简单,支持顺序存取和随机存取,顺序存取速度相对较快。缺点是文件不能动态增长,不利于文件插入和删除。如果用户的查询条件定义在查找码上,则顺序文件是比较适合的文件结构。
4.聚集文件
将不同关系表中有关联关系的记录存储在一起。如果某些重要而频繁的用户查询经常需要进行多表连接操作,可以考虑聚集文件,来改善查询效率。
十一、分布式数据库
分布式数据要达到的目标是:本地自治、非集中式管理、高可用性、位置独立性、 数据分片独立性、数据复制独立性、分布式查询处理、分布式事务管理、硬件独立性、操作系统独立性、网络独立性、数据库管理系统独立性。并行数据库的目标是高性能和高可用性,通过多个处理节点并行执行数据库任务,提高整个数据库系统的性能和可用性。
十二、IDEFX1
1.独立实体(强实体)
独立实体:一个实体的实例都被唯一的标识而不决定于它与其他实体的联系(独立实体的关键字属性是自身拥有的属性)
AK表示候选键,若出现俩个AK1,AK1表示两个属性构成一个候选键
2.从属实体(弱实体)
一个实体的实例的唯一标识需要依赖于该实体与其他实体的联系(从属实体的关键字属性包含继承字其他实体的属性)
主关键字包含了外来属性的实体为从属实体
FK表示继承自其他实体的属性
1>两类实体的比较:
1:独立实体用直角的方形框表示,从属实体用圆角方形框表示
2:独立实体的主关键字没有外键,从属实体的主关键字含有外键
2>属性与关键字
属性: 表示一类现实或抽象事物的一种特征或性质
关键字: 能唯一确定实体每一个实例的属性或属性组,关键字也被区分为主关键字和次关键字
3>联系
联系: 是实体之间的一种连接关系
联系的三类: | |
---|---|
连接联系(又称父子联系,依存联系) | 标定联系,非标定联系(一对一,一对多) |
分类联系 | 完全分类,非完全分类 |
非确定联系 | 多对多 |
4>标定联系
子实体的实例都是由它与父实体的联系而确定的,父实体的主关键字是子实体主关键字的一部分,在多端加圆圈,是从属实体以及它所以来的实体之间的联系
5>非标定联系
子实体的实例能够被唯一标识而无需依赖与其他实体的联系。父实体的主关键字不是子实体的主关键字
关于标定联系和非标定联系的规则:工程化要求
- 标定联系用直线来表示,非标定联系用虚直线表示
- 在子实体一侧有圆圈,联系名标注在直线旁
6>分类联系
一个实体实例是由一个一般实体实例及多个分类实体实例构成的(不等于分类)
- 一个一般实体是若干具体实体的类
- 分类实体与一般实体具有相同的主关键字
- 不同分类实体除具有一般实体特征外,各自还可能具有不同的属性特征
7>完全分类联系与完全分类联系
完全分类:一圆圈带两横线
非完全分类:一圆圈带一横线
8>非确定联系
即实体之间多对多的联系
非确定联系必须分解为若干个一对多的联系来表达
非确定联系通过引入相交实体(相关实体)来分解为若干个一对多的联系来表达
相交实体的本质就是联系
————————————————
版权声明:本文为CSDN博主「@玉面小蛟龙」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/qq_43610614/article/details/104903147
十三、反规范化
在关系型数据库(relational database)中,反规范化(denormalization)是加速阅读性能(数据检索)的方法,管理员用这种方法有选择地在数据结构标准化后回加特定的冗余数据实例。
在关系型数据库(relational database)中,反规范化(denormalization)是加速阅读性能(数据检索)的方法,管理员用这种方法有选择地在数据结构标准化后回加特定的冗余数据实例。反规范化数据库不应该和从未进行过标准化的数据库(database)相混淆。
在标准化期间,数据库设计者在叫做关系的不同逻辑表中存储不同但类型相关的数据。
当一次查询将来自多个表格的数据结合到一个简单的结果列表中,这就叫做参与。多个表格参与到同一个查询可能对性能有不良影响。引导反规范化(denormalization)并回加少量冗余在减少参与量方面很有用。
在数据复制后,数据库设计者必须考虑数据的多个实例将如何维护。反规范化(denormalize)数据库的一个方式是允许数据库管理系统(DBMS)在磁盘上存储冗余信息。这对于确保冗余副本的一致性有附加好处。另一种方法是反规范化真实的逻辑数据设计,但这可能很快就导致不一致数据。叫做限制条件的规则可用来指定信息的冗余副本如何同步,但它们增加了数据库设计的复杂性,也有影响编写性能的风险。
数据库的反规范化是为了减少表间的连接,提高查询性能,但并非所有经反规范的数据库都是高效的,这与实际的应用有关,只有满足一定条件的数据库采用反规范方法才能提高性能。
Date date = new date();
System.out.println(date);
//当前时间为:2020-04-05 23:02