标签：电话 范式 数据库 依赖于 供销商 规范化 设计 主键
规范化数据库设计
1、为什么需要数据库设计
当数据库比较复杂时我们需要设计数据库
糟糕的数据库设计 :
- 数据冗余,存储空间浪费 - 数据更新和插入的异常 - 程序性能差
良好的数据库设计 :
- 节省数据的存储空间 - 能够保证数据的完整性 - 方便进行数据库应用系统的开发
软件项目开发周期中数据库设计 :
- 需求分析阶段: 分析客户的业务和数据处理需求 - 概要设计阶段:设计数据库的E-R模型图 , 确认需求信息的正确和完整.
设计数据库步骤
- 收集信息 - 与该系统有关人员进行交流 , 座谈 , 充分了解用户需求 , 理解数据库需要完成的任务. - 标识实体[Entity] - 标识数据库要管理的关键对象或实体,实体一般是名词 - 标识每个实体需要存储的详细信息[Attribute] - 标识实体之间的关系[Relationship]
2、三大范式
问题 : 为什么需要数据规范化?
不合规范的表设计会导致的问题： - 信息重复 - 更新异常 - 插入异常 - 无法正确表示信息 - 删除异常 - 丢失有效信息
?>三大范式
第一范式 (1st NF)
第一范式的目标是确保每列的原子性,如果每列都是不可再分的最小数据单元,则满足第一范式。
原子性：强调的是列的原子性，即数据库中每一列的字段都是单一属性，不可再分的。并且这个单一属性必须是由基本的数据类型所构成的，如整数、字符串等。下面给大家举个例子：
这是一张员工表：
| 员工ID | 姓名 | 性别 | 部门 | 联系电话 |
|---|---|---|---|---|
| 101 | 周星星 | 女 | 销售部 | 15015246623 |
现在我们来分析上表，这张员工表是不符合第一范式标准的，每个员工只有一个员工ID，也确实只有一个姓名，一个性别，只属于一个部门，但是在我们的实际生活中，每个人真的只有一个联系电话吗？这里我们就假设最少的情况，每个人都有个人电话和家庭电话，那么联系电话这一字段就是可再分的。这张表的结构设计就没有达到第一范式。
解决方案：我们只需要把联系电话这一字段分为个人电话字段和家庭电话字段，就完全符合了第一范式（如下表）。
| 员工ID | 姓名 | 性别 | 部门 | 个人电话 | 家庭电话 |
|---|---|---|---|---|---|
| 1 | 周星星 | 女 | 销售部 | 15015246623 | 663323 |
第二范式(2nd NF)
?>第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式要求每个表只描述一件事情
依赖性：在满足1NF的基础上再满足依赖性的两个约束：一张表必须有一个主键；非主键类必须完全依赖于主键，而不能只依赖主键的一部分。 这是一张商品供销信息表：
| 商品 | 供销商 | 价格 | 重量 | 分类 | 供销商电话 |
|---|---|---|---|---|---|
| 啤酒 | 饮品1厂 | 3 | 300ml | 液体 | 18016253155 |
| 啤酒 | 饮品2厂 | 5 | 300ml | 液体 | 18055231233 |
| 可乐 | 饮品2厂 | 5 | 250ml | 液体 | 18055231233 |
需要清楚几点：
商品与供销商是多对多的关系
该表中关键字是一组组合关键字<商品，供销商>，只有商品和供销商两个字段结合才可标识出一件商品
存在以下部分依赖的关系
商品---->价格，重量，分类 供销商---->供销商电话
由以上存在的部分依赖关系就可知道该商品表不符合第二范式了，价格，重量，分类只依赖于商品这个主键，而供销商电话也只依赖于供销商这个主键，已经完全违背了第二范式非主键列必须完全依赖于主键而不能只依赖于主键的一部分这一原则了。
解决方案：把上表商品表拆分为商品表和供销商表两张表，既满足了非主键字段必须完全依赖主键这一条件又减少了供销商电话重复这一冗余。
商品 供销商 价格 重量 分类 啤酒 饮品1厂 3 300ml 液体 啤酒 饮品2厂 5 300ml 液体 可乐 饮品2厂 3 250ml 液体
供销商 供销商电话 饮品1厂 18016253155 饮品2厂 18055231233
第三范式(3rd NF)
?>如果一个关系满足第二范式,并且除了主键以外的其他列都不传递依赖于主键列,则满足第三范式。第三范式需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。
在满足2NF的基础上，另外再满足一个条件：非主键列必须直接依赖于主键，不能存在传递依赖。 这是一张学生课表：
| 课程编号 | 课程名字 | 上课时间 | 任课老师 | 老师电话 | 老师职位 |
|---|---|---|---|---|---|
| 101 | 马克思理论基础 | 8:00 | Lily | 18016253155 | 讲师 |
| 102 | 经济学 | 14:00 | Lucy | 18055231233 | 教授 |
主键：课程编号 大致一看，上表中的非主键列确实完全是依赖于主键（课程编号）的，符合第二范式2NF。但是问题是：老师电话，老师职位直接依赖的是任课老师（非主键列），而不是直接依赖于主键，它是通过传递才依赖于主键，所以不符合 3NF。
解决方案：依然是通过拆分，把上述学生课表拆分为课程表和教师表。
课程表：
| 课程编号 | 课程名字 | 上课时间 | 任课老师 |
|---|---|---|---|
| 101 | 马克思理论基础 | 8:00 | Lily |
| 102 | 经济学 | 14:00 | Lucy |
教师表：
| 任课老师 | 老师电话 | 老师职位 |
|---|---|---|
| Lily | 18016253155 | 讲师 |
| Lucy | 18055231233 | 教授 |
3、五大约束
经常有听到三大范式五大约束这种说法，上面我们已经详细说明了三大范式，这里我们就来简单说明一下大家常说的五大约束，到底是哪五个约束呢？
-
PRIMARY KEY(primary key):设置主键约束；
-
UNIQUE(unique)：设置唯一性约束，不能有重复值；
-
DEFAULT(default)：默认值约束，height DOUBLE(3,2) height不输入是默认为(1,2)。
-
NOT NULL(not null)：设置非空约束，该字段不能为空；
-
FOREIGN KEY (foreign key):设置外键约束。
4、关于范式的一些其他了解
范式（Normal Form）是英国人在上个世纪70年代提出关系数据库模型后总结出来的，范式是关系数据库理论的基础，也是我们在设计数据库结构过程中必须要遵循的规则和指导方法。目前有迹可寻的共有8种范式，依次是：1NF，2NF，3NF，BCNF，4NF，5NF，DKNF，6NF，但是我们只要理解前三个范式就完全够用了，其他范式只是简单了解一下。
标签：电话,范式,数据库,依赖于,供销商,规范化,设计,主键 来源： https://www.cnblogs.com/mmdz/p/15406702.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。