侧边栏壁纸
博主头像
coydone博主等级

记录学习,分享生活的个人站点

  • 累计撰写 306 篇文章
  • 累计创建 51 个标签
  • 累计收到 0 条评论

目 录CONTENT

文章目录

数据库设计

coydone
2022-01-06 / 0 评论 / 0 点赞 / 304 阅读 / 3,232 字 / 正在检测是否收录...
温馨提示:
本文最后更新于 2022-04-06,若内容或图片失效,请留言反馈。部分素材来自网络,若不小心影响到您的利益,请联系我们删除。

关系型数据库设计规则

关系型数据库的典型数据结构就是数据表,这些数据表的组成都是结构化的(Structured)。

将数据放到表中,表再放到库中。

一个数据库中可以有多个表,每个表都有一个名字,用来标识自己。表名具有唯一性。

表具有一些特性,这些特性定义了数据在表中如何存储,类似Java和Python中 “类”的设计。

表、记录、字段

E-R(entity-relationship,实体-联系)模型中有三个主要概念是: 实体集 、 属性 、 联系集 。一个实体集(class)对应于数据库中的一个表(table),一个实体(instance)则对应于数据库表中的一行(row),也称为一条记录(record)。一个属性(attribute)对应于数据库表中的一列(column),也称为一个字段(field)。

ORM思想(Object Relational Mapping)体现:

数据库中的一个表 <----> 一个类
表中的一条数据 <----> 类中的一个对象(或实体)
表中的一个列 <----> 类中的一个字段、属性(field)

表的关联关系

表与表之间的数据记录有关系(relationship)。现实世界中的各种实体以及实体之间的各种联系均用关系模型来表示。四种:一对一关联、一对多关联、多对多关联、自我引用。

分类

一对一关联(one-to-one)

在实际的开发中应用不多,因为一对一可以创建成一张表。

举例:设计学生表(学号、姓名、手机号码、班级、系别、身份证号码、家庭住址、籍贯、紧急联系人)拆为两个表:两个表的记录是一一对应关系。

基础信息表 (常用信息):学号、姓名、手机号码、班级、系别。

档案信息表 (不常用信息):学号、身份证号码、家庭住址、籍贯、紧急联系人。

两种建表原则:

  • 外键唯一:主表的主键和从表的外键(唯一),形成主外键关系,外键唯一。

  • 外键是主键:主表的主键和从表的主键,形成主外键关系。

  • 一对一(了解):如:人和身份证分析:一个人只有一个身份证,一个身份证只能对应一个人

  • 一对多(多对一):如:部门和员工分析:一个部门有多个员工,一个员工只能对应一个部门

  • 多对多:如:学生和课程分析:一个学生可以选择很多门课程,一个课程也可以被很多学生选择

实现关系

  • 一对多(多对一):如:部门和员工实现方式:在多的一方建立外键,指向一的一方的主键。

  • 多对多:如:学生和课程实现方式:多对多关系实现需要借助第三张中间表。中间表至少包含两个字段,这两个字段作为第三张表的外键,分别指向两张表的主键。

  • 一对一(了解):如:人和身份证实现方式:一对一关系实现,可以在任意一方添加唯一外键指向另一方的主键。

案例

以旅游网站为例,可能存在着旅游线路分类表、旅游线路表、用户表。其中,在旅游线路分类中会有多个旅游线路,一个用户可以收藏多个旅游线路,一个旅游线路可以被多个用户收藏。

 -- 创建旅游线路分类表 tab_category
 -- cid 旅游线路分类主键,自动增长
 -- cname 旅游线路分类名称非空,唯一,字符串 100
 CREATE TABLE tab_category (
     cid INT PRIMARY KEY AUTO_INCREMENT,
     cname VARCHAR(100) NOT NULL UNIQUE
 );

 -- 创建旅游线路表 tab_route
 /*
 rid 旅游线路主键,自动增长
 rname 旅游线路名称非空,唯一,字符串 100
 price 价格
 rdate 上架时间,日期类型
 cid 外键,所属分类
 */
 CREATE TABLE tab_route(
     rid INT PRIMARY KEY AUTO_INCREMENT,
     rname VARCHAR(100) NOT NULL UNIQUE,
     price DOUBLE,
     rdate DATE,
     cid INT,
     FOREIGN KEY (cid) REFERENCES tab_category(cid)
 );
         
 /*创建用户表 tab_user
 uid 用户主键,自增长
 username 用户名长度 100,唯一,非空
 password 密码长度 30,非空
 name 真实姓名长度 100
 birthday 生日
 sex 性别,定长字符串 1
 telephone 手机号,字符串 11
 email 邮箱,字符串长度 100
 */
 CREATE TABLE tab_user (
     uid INT PRIMARY KEY AUTO_INCREMENT,
     username VARCHAR(100) UNIQUE NOT NULL,
     PASSWORD VARCHAR(30) NOT NULL,
     NAME VARCHAR(100),
     birthday DATE,
     sex CHAR(1) DEFAULT '男',
     telephone VARCHAR(11),
     email VARCHAR(100)
 );
         
 /*
 创建收藏表 tab_favorite
 rid 旅游线路 id,外键
 date 收藏时间
 uid 用户 id,外键
 rid 和 uid 不能重复,设置复合主键,同一个用户不能收藏同一个线路两次
 */
 CREATE TABLE tab_favorite (
     rid INT, -- 线路id
     DATE DATETIME,
     uid INT, -- 用户id
     -- 创建复合主键
     PRIMARY KEY(rid,uid), -- 联合主键
     FOREIGN KEY (rid) REFERENCES tab_route(rid),
     FOREIGN KEY(uid) REFERENCES tab_user(uid)
 );

数据库设计的范式

概念

设计数据库时,需要遵循的一些规范。要遵循后边的范式要求,必须先遵循前边的所有范式要求。

设计关系数据库时,遵从不同的规范要求,设计出合理的关系型数据库,这些不同的规范要求被称为不同的范式,各种范式呈递次规范,越高的范式数据库冗余越小。

目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF,又称完美范式)。

分类

  • 第一范式(1NF):每一列都是不可分割的原子数据项。

  • 第二范式(2NF):在1NF的基础上,非码属性必须完全依赖于码(在1NF基础上消除非主属性对主码的部分函数依赖)。

  • 第三范式(3NF):在2NF基础上,任何非主属性不依赖于其它非主属性(在2NF基础上消除传递依赖)。

几个概念

  • 函数依赖:A→B,如果通过A属性(属性组)的值,可以确定唯一B属性的值。则称B依赖于A例如:学号–>姓名。 (学号,课程名称) → 分数

  • 完全函数依赖:A→B, 如果A是一个属性组,则B属性值的确定需要依赖于A属性组中所有的属性值。例如:(学号,课程名称)→分数

  • 部分函数依赖:A–>B, 如果A是一个属性组,则B属性值的确定只需要依赖于A属性组中某一些值即可。例如:(学号,课程名称)→姓名

  • 传递函数依赖:A→B, B→C,如果通过A属性(属性组)的值,可以确定唯一B属性的值,在通过B属性(属性组)的值可以确定唯一C属性的值,则称 C 传递函数依赖于A。例如:学号→系名,系名→系主任

  • 码:如果在一张表中,一个属性或属性组,被其他所有属性所完全依赖,则称这个属性(属性组)为该表的码。例如:该表中码为:(学号,课程名称)

  • 主属性:码属性组中的所有属性。

  • 非主属性:除过码属性组的属性。

如在下表中,系可以分为系名和系主任两个子项,则系这列不是一个原子列。

此时将系这列拆分便可以满足第一范式。

此时存在的问题:

  • 存在非常严重的数据冗余(重复):姓名、系名、系主任。

  • 数据添加存在问题:添加新开设的系和系主任时,数据不合法。

  • 数据删除存在问题:张无忌同学毕业了,删除数据,会将系的数据一起删除。

学号在部分函数依赖的属性有:姓名、系名、系主任。我们将其拆分。

此时学生表中存在传递依赖。系名依赖于学号,系主任依赖于系名。我们将学生表进行拆分。

0

评论区