关系数据库设计
数据库设计中的关系型数据库规范方法
数据库设计中的关系型数据库规范方法关系型数据库是一种基于关系模型的数据库，它使用表格和键值对来组织和存储数据。
在数据库设计中，规范方法是非常重要的，它可以确保数据库的性能、稳定性和可靠性。
本文将介绍一些数据库设计中的关系型数据库规范方法，并探讨它们的优势和应用场景。
首先，我们将讨论数据库设计中的范式规范方法。
范式是一种数据结构的规范化方法，它用于消除数据库中的冗余数据，并改善数据的一致性和完整性。
常见的范式包括第一范式（1NF）、第二范式（2NF）、第三范式（3NF）等。
第一范式要求数据表中的每个字段都是原子的，也就是说它们不能再分解。
这样可以避免数据的冗余，并提高数据库的查询性能。
第二范式要求数据表中的非主键字段必须完全依赖于主键。
这意味着数据表中的每个非主键字段必须与主键相关联，而不是与其他非主键字段相关联。
这样可以保证数据的一致性，并减少数据的冗余。
第三范式要求数据表中的非主键字段不能相互依赖。
换句话说，数据表中的每个非主键字段应该只与主键相关联，而不是与其他非主键字段相关联。
这样可以确保数据的完整性，并减少数据之间的关联性。
其次，我们将探讨数据库设计中的索引规范方法。
索引是一种数据结构，它可以加快数据库的查询速度。
在设计数据库时，我们应该根据数据的特征选择适当的索引。
首先是主键索引，它将主键列的值与数据表中的物理位置相匹配，并确保每个键值对具有唯一性。
主键索引可以加速数据的检索和排序。
其次是唯一索引，它将非主键列的值与数据表中的物理位置相匹配，并确保每个键值对具有唯一性。
唯一索引可以加速数据的检索和去重操作。
还有聚簇索引，它根据表的主键将数据存储在物理上相邻的位置。
聚簇索引可以加速范围查询和排序操作。
另外还有非聚簇索引，它根据非主键列的值将数据存储在物理上相邻的位置。
非聚簇索引可以加速数据的检索和排序操作。
最后，我们将讨论数据库设计中的约束规范方法。
约束是一种规则，它用于限制和保护数据库的数据完整性。
数据库课件第6章 关系数据库设计
“学生”是该系统的一个核心数据结构，它可以描述如 下： 数据结构： 学生 含义说明： 是教学管理子系统的主体数据结构， 定义了一个学生的相关信息。 组成： 学号，姓名，性别，年龄，所在系，年级
2．分析得到系统的信息需求
例如: ⑴ 教学管理子系统的信息需求
管理学生、班级、教师、课程、专业和系等信息。 ①学生：学号、姓名、性别、年龄等。 ②班级：班级号、班级名、人数等。 ③教师：教师号、姓名、性别、职称、 电话号码和家 庭地址(城市、区、街道、邮政编码)等。 ④课程：课程号、课程名、学分、周学时、课程类型 (周数)等。 ⑤专业：专业号、专业名、选修门数等。 ⑥系：系号、系名等。
课程号 课程名 总课时
课程
请按键 ★
教授联系的合并
教 学 管 理 子 系 统
教师 m
教授 n 课程
教师 m 教授 n 课程
时间 教室号
合 并 后
时间 评教等级
教师 m
教授 n 课程 评教等级 时间 教室号
请按键 ★
工Hale Waihona Puke 资 及 福 利 子 系 统
合并后生成的全局E-R模型
教师 号
姓 名
性 别
⑵ 消除冗余数据和冗余联系 检查合并后的E-R模型中有无冗余数 据和冗余联系，如有则根据实际情况消 除之。
⑶ 例
教学管理与工资及福利管理子系统中，教 师的职工号存在命名冲突；教师实体存在 结构冲突。
教师 号
姓 名 教师 m 时间
性 别
职 称 电话号 码
n
工作
1
系 系号 系名
教授 教室号 n 课程名 n 课程 m n 学分 m
第4篇关系数据库设计理论
注意：如果R的候选关键字均为单属性，或R的全体 属性均为主属性，则R∈2NF。
4.2.6 第三范式
1．第三范式的定义 定义4.8 如果关系模式R∈2NF，R（U，F）中所有
非主属性对任何候选关键字都不存在传递函数依赖， 则称R是属于第三范式（Third Normal Form），简称 3NF，记作R∈3NF。 第三范式具有如下性质： (1)如果R∈3NF，则R也是2NF。 (2)如果R∈2NF，则R不一定是3NF。
4.2.1 函数依赖
（2）扩张性 若 X→Y 且 W→Z ， 则 （ X ， W ） → （ Y ， Z ） 。 例 如 ，
SNO→（SN，AGE），DEPT→MN，则有（SNO，DEPT）→ （SN，AGE，MN）。
说明：扩张性实现了两函数依赖决定因素与被决定 因素的分别合并作用。
(3) 合并性 若X→Y且X→Z则必有X→（Y，Z）。例如，在关系 SDC 中 ， SNO→ （ SN ， AGE ） ， SNO→DEPT ， 则 有 SNO→ （SN，AGE，DEPT）。 说明：决定因素相同的两函数依赖被决定因素的可 以合并。
4.2.2 码
已知关系模式R（U，F），如何来找出R的所有候 选键呢？方法的步骤为： 1、查看函数依赖集F中的每个形如Xi→Yi的（i=1,……,n） 函数依赖关系。看哪些属性在所有Yi（i=1,……,n） 中 没 有 出 现 过 ， 设 没 出 现 过 的 属 性 集 为 P （ P=U-Y1Y2……-Yn ） 。 则 当 P=φ （ 表 示 空 集 ） 时 ， 转 4 ； 当 P≠φ时，转2。
关系数据库的规范化设计
第二范式
确保每个非主键列完全依赖于主键，消除非主键列之间的传递依赖。
第三范式
确保每个列只与键直接相关，消除非键列之间的传递依赖。
规范化设计的优点
1 数据一致性
通过消除数据冗余和重 复，确保数据库中的数 据一致性。
2 查询效率
通过优化数据结构，提 高查询性能，减少数据 操作的时间。
3 存储优化
通过合理的数据分解和 组织，减少数据存储空 间的占用。
规范化设计的挑战
复杂性
规范化设计需要考虑多个表之间的关系和依赖，增加了设计的复杂性。
性能折衷
规范化设计可能导致性能折衷，某些查询可能需要多个表的连接操作。
更新操作
规范化设计可能导致更新操作的复杂性，特别是在涉及多个表的更新操作时。
最佳实践和常见错误
最佳实践
• 了解业务需求和数据关系 • 谨慎添加冗余数据 • 使用正确的数据类型和约束
常见错误
• 拆分过分，导致过多的连接操作 • 忽略实际查询需求，导致性能问题 • 不正确地处理关联关系，导致数据不一致
总结和重点
1 规范化设计是优化关系数据库结ቤተ መጻሕፍቲ ባይዱ
构的重要技术
3 规范化设计有优点和挑战，需要
权衡设计决策
2 三个范式规则用于确保数据的一
致性和查询效率
4 遵循最佳实践并避免常见错误是
实现成功的关键
关系数据库的规范化设计
在关系数据库设计中，规范化是一种重要的技术，它的目标是优化数据库结 构以提高数据的存储效率和查询性能。
规范化设计的概念和目的
规范化设计是一种组织和优化数据库结构的过程，通过将数据分解成更小的关系表，消除数据冗余和不 一致，以提高数据存储和查询效率。
关系型数据库设计原则与方法
关系型数据库设计原则与方法关系型数据库设计是一种常见的数据库设计方法，它的设计原则和方法可以用于设计和优化关系型数据库模式。
本文将介绍关系型数据库设计的五个基本原则和一些常用的方法，以帮助您更好地进行数据库设计和优化。
第一原则：数据分离原则数据分离原则是指将不同的数据类型分开存储，不混杂在同一个表中。
这个原则主要是考虑到数据的规范性和易维护性。
每个数据类型都应该有自己的表，通过相关字段建立关联，并通过外键实现关系。
这种设计方式使数据库的结构更清晰、规范，也方便日后对数据更新和查询。
第二原则：范式设计原则范式设计原则是关系型数据库设计中的核心概念。
它主要是通过分解数据，将重复的数据避免在表中出现，减少冗余和更新异常。
范式的级别分为一到五级，分别用1NF、2NF、3NF、BCNF、4NF和5NF表示。
一般来说，我们在设计数据库时应尽可能遵循更高级别的范式，以减少数据冗余和保证数据的一致性。
第三原则：主键设计原则主键是一种唯一标识数据记录的方式，它在关系型数据库中非常重要。
主键的设计要符合以下要求：1. 唯一性：每个记录的主键值是唯一的，确保数据的完整性和一致性。
2. 稳定性：主键的值应该是稳定不变的，不能频繁修改。
3. 简洁性：主键的值应该是简洁的，便于查询和索引。
常见的主键类型包括自增主键，UUID，日期时间等。
第四原则：索引设计原则索引在关系型数据库中起着加速查询和提高性能的作用。
但是过多或不恰当的索引设计可能会导致数据库性能下降。
索引的设计原则包括：1.覆盖索引：将索引包含需要查询的字段，减少数据库访问次数。
2.唯一性：非重复且唯一的字段适合设计索引。
3.选择性：选择那些频繁被查询的字段。
4.大小：索引的大小应控制在合理范围内，避免占用过多磁盘空间。
第五原则：范围控制原则通过范围控制可以将数据库的规模控制在一定的范围内，避免不必要的数据增长。
范围控制主要包括以下几方面：1.数据量估算：在设计数据库时要对数据量进行预估，合理规划存储空间。
关系数据库的数据模型设计方法
关系数据库的数据模型设计方法随着计算机技术的不断发展，我们正处于一个数据信息化的时代，数据的管理和处理已经成为企业、政府、个人等各个领域的重要问题。
而关系数据库（Relational Database）作为一种常见的数据存储方式，其数据模型设计方法也成为数据管理中的关键环节。
关系数据库的数据模型设计包括三个部分：实体(Entity)、属性(Attribute)和关系(Relationship)。
实体是指现实世界中可以独立、区分的事物或对象；属性是指实体的属性或特征；关系则是描述实体之间的联系或关联。
在进行关系数据库的数据模型设计时，需要进行以下几个步骤：第一步，确定需要存储的实体和属性。
这个步骤需要对用户需求进行分析，找出用户需求中涉及到的实体和属性，并进行分类归纳。
例如，在设计一个学生信息管理系统时，需要确定实体有“学生”、“教师”等，属性有“学生姓名”、“专业”等。
第二步，确定实体之间的关系。
这个步骤需要对实体之间的联系或关系进行分析，找出实体之间的联系或关系，并进行分类归纳。
例如，在设计一个学生信息管理系统时，需要确定学生与课程之间的关系，即“学生选修了某个课程”。
第三步，建立实体关系图（ER图）。
根据前两步的分析结果，将实体和关系以图形的形式表现出来，形成一个实体关系图。
ER图是关系数据库模型的基本设计工具，通过ER图可以清晰地把实体和关系之间的联系表达出来，是设计关系数据库的必要步骤。
第四步，建立数据库表结构。
根据ER图，将实体和关系转换为数据库中的表结构，包括表的名称、属性、主键等。
例如，在设计学生信息管理系统时，可以将“学生”实体转换为一个“学生信息”表，该表包括“学生姓名”、“专业”等属性，同时还需要确定一个主键，通常是一个唯一标识符，用于唯一标识每一个记录。
第五步，进行数据填充和查询操作。
在确定好数据库表结构之后，就可以进行数据填充和查询操作了。
数据填充是将现实世界中的数据转换为数据库中的数据，通常是通过应用程序实现；查询操作是通过SQL语句进行实现，以便用户对数据库中的数据进行操作和查询。
关系型数据库设计——E-R图
关系型数据库设计——E-R图⼀、数据管理技术的三个发展阶段：1）⼈⼯管理阶段（20世纪50年代中期）特点：数据不保存；应⽤程序管理数据；数据不共享；数据没有独⽴性；2）⽂件系统阶段（20世纪50年代后—60年代）特点：数据以⽂件形式长期保存；⽂件系统管理数据；数据共享性差、冗余度⼤；数据独⽴性差；3）数据库系统阶段（20世纪60年代—现在）特点：数据结构化；数据由DBMS统⼀管理与控制；数据共享性⾼、冗余度低；数据独⽴性⾼；⼆、数据库管理系统的功能：1）数据定义功能：由DBMS提供的数据定义语⾔（Data Definition Language,DDL）定义数据库中的数据对象。
2）数据操纵功能：由DBMS提供的数据操纵语⾔（Data Manipulation Language,DML）实现对数据库的查询、插⼊、删除和修改；3）数据控制功能：由DBMS提供的数据控制语⾔（Data Control Language,DCL）实现数据保护和事务管理的功能，包括完整性、安全性、并发控制和数据库恢复；4）数据库的建⽴与维护功能三、概念模型（也称信息模型）——E-R图（Entity-Relationship Diagram）概念结构设计即对现实世界进⾏抽象描述，在需求分析所得数据流图和数据字典的基础上，为计算机存储做准备；概念结构设计的内容即建⽴概念模型；描述概念模型最常⽤⽅法是E-R图或UML图⽅法。
主要概念：实体（Entity）：客观存在的各类事物；属性（Attribute）：实体所具有的特性；联系（Relationship）：不同实体集中实体之间的联系，也可以是同⼀实体集中实体间的联系；联系的种类：1：1联系；1：N联系；M：N联系⽤E-R图建⽴概念模型局部的E-R图⼜称为局部视图，将多个局部视图E-R图合并成⼀张完整的E-R图的过程称为视图集成。
视图集成过程中可以解决冲突和消除冗余；分E-R图之间的三类冲突：1）属性冲突2）命名冲突3）结构冲突：同⼀实体在不同的分E-R图中有不同的属性，同⼀对象在某⼀分E-R图中被抽象为实体⽽在另⼀分E-R图中⼜被抽象为属性，需要统⼀；四、逻辑结构设计——E-R图向关系模型的转换1）⼀个实体转换为⼀个关系模式；实体的属性——>关系的属性实体标识符——>关系的码2）联系的转换1：1联系——与任意⼀端对应的关系模式和并；1：n联系——与n端对应的关系模式合并；m：n联系——⼀个独⽴的关系模式五、关系模式的优化从以下⼏⽅⾯：1）关系模式规范化2）对关系模式进⾏必要的合并3）进⾏合理的分解，包括⽔平分解、垂直分解六、关系模式的存取⽅法选择DBMS常⽤存取⽅法：1）索引⽅法，⽬前主要是B+树索引⽅法2）聚簇（cluster）⽅法3）Hash⽅法七、SQL数据库的三级结构/两级映像三级模式体系结构：两级映像：外模式/模式映像模式/内模式映像1）数据的逻辑独⽴性应⽤程序（外模式）与数据库的逻辑结构（模式）是相互独⽴的，即数据的逻辑结构发⽣改变，应⽤程序不⽤变。
简述关系数据库的设计步骤
简述关系数据库的设计步骤关系数据库是一种常用的数据库模型，它使用表、关系和键设计来存储、组织和查询数据。
基于关系数据库的设计是现代信息系统的基础，为实现高效的数据管理、存储和查询提供了非常重要的基础。
本文将阐述关系数据库设计的基本步骤，介绍它们如何在现代信息管理系统中应用，最终为系统用户提供可靠、可操作的信息服务。
首先，关系数据库设计必须考虑业务要求，并将其转换为设计要求，以确定数据模型及数据库的功能。
在这一步中，需要分析业务要求，确定业务模型，收集和组织需要的数据，确定有效的数据存储结构，特别是确定以及识别出业务实体，并确定属于这些业务实体的属性。
接下来，在将数据模型及功能转换为关系数据库结构时，通常遵循经典的数据库设计步骤，包括实体识别、实体关系建模、属性决定、关系表建模、索引设计、视图建模等。
在实体识别阶段，要进行概念建模，涉及对实体及实体间关系的分析和建模；在实体关系建模阶段，要发现多个实体之间的联系，并通过概念建模实现；属性决定阶段，要根据业务要求，确定每个实体属性的类型及唯一性；关系表建模阶段，要根据实体、属性和关系，建立每个实体的关系表；索引设计阶段，要根据使用频率，选择合适的索引类型和索引结构；视图建模阶段，要根据访问视图和系统需求，建立逻辑视图，最终创建物理视图。
最后，在完成基本的设计步骤之后，需要进行质量测试，以确保数据库的正常运行，包括数据完整性检查、安全性测试、功能测试、性能测试等，可以根据实际情况选择不同的测试策略。
从上述步骤可以看出，基于关系数据库的设计是一个复杂的过程，它要求设计者充分考虑业务要求，转换为数据模型、实体识别、属性决定、关系表建模、视图建模等步骤，最终保证数据库的正确性和高效性。
在现代信息管理系统中，关系数据库的设计以及维护工作日益重要。
有效的关系数据库设计，可以帮助系统用户实现信息查询要求，并能较好地支持信息管理系统的正常运行。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
目录一Codd的RDBMS1２法则——RDBMＳ的起源二关系型数据库设计阶段三设计原则四命名规则数据库设计，一个软件项目成功的基石。
很多从业人员都认为,数据库设计其实不那么重要。
现实中的情景也相当雷同，开发人员的数量是数据库设计人员的数倍。
多数人使用数据库中的一部分,所以也会把数据库设计想的如此简单。
其实不然,数据库设计也是门学问。
从笔者的经历看来，笔者更赞成在项目早期由开发者进行数据库设计(后期调优需要DBA）。
根据笔者的项目经验，一个精通OOP和ＯRM的开发者,设计的数据库往往更为合理,更能适应需求的变化,如果追其原因，笔者个人猜测是因为数据库的规范化,与OO的部分思想雷同（如内聚）。
而ＤＢA,设计的数据库的优势是能将ＤBMS的能力发挥到极致,能够使用ＳＱL和DBMS实现很多程序实现的逻辑，与开发者相比，ＤＢA优化过的数据库更为高效和稳定。
如标题所示,本文旨在分享一名开发者的数据库设计经验,并不涉及复杂的SQＬ语句或DBMS使用,因此也不会局限到某种DBＭS产品上。
真切地希望这篇文章对开发者能有所帮助,也希望读者能帮助笔者查漏补缺。
一 Codd的RＤBMS12法则——ＲＤBMS的起源Eｄgａr Frank Cｏdd（埃德加·弗兰克·科德)被誉为“关系数据库之父”，并因为在数据库管理系统的理论和实践方面的杰出贡献于1981年获图灵奖。
在1985年，Ｃodd 博士发布了１2条规则，这些规则简明的定义出一个关系型数据库的理念，它们被作为所有关系数据库系统的设计指导性方针。
1. 信息法则关系数据库中的所有信息都用唯一的一种方式表示——表中的值。
2. 保证访问法则依靠表名、主键值和列名的组合,保证能访问每个数据项。
3. 空值的系统化处理支持空值(ＮULL）,以系统化的方式处理空值，空值不依赖于数据类型。
4. 基于关系模型的动态联机目录数据库的描述应该是自描述的，在逻辑级别上和普通数据采用同样的表示方式,即数据库必须含有描述该数据库结构的系统表或者数据库描述信息应该包含在用户可以访问的表中。
5. 统一的数据子语言法则一个关系数据库系统可以支持几种语言和多种终端使用方式,但必须至少有一种语言，它的语句能够一某种定义良好的语法表示为字符串,并能全面地支持以下所有规则：数据定义、视图定义、数据操作、约束、授权以及事务。
(这种语言就是ＳＱL)6. 视图更新法则所有理论上可以更新的视图也可以由系统更新。
7. 高级的插入、更新和删除操作把一个基础关系或派生关系作为单个操作对象处理的能力不仅适应于数据的检索,还适用于数据的插入、修改个删除，即在插入、修改和删除操作中数据行被视作集合。
8. 数据的物理独立性不管数据库的数据在存储表示或访问方式上怎么变化，应用程序和终端活动都保持着逻辑上的不变性。
9. 数据的逻辑独立性当对表做了理论上不会损害信息的改变时,应用程序和终端活动都会保持逻辑上的不变性。
10. 数据完整性的独立性专用于某个关系型数据库的完整性约束必须可以用关系数据库子语言定义，而且可以存储在数据目录中，而非程序中。
11. 分布独立性不管数据在物理是否分布式存储,或者任何时候改变分布策略，ＲDＢＭＳ的数据操纵子语言必须能使应用程序和终端活动保持逻辑上的不变性。
12. 非破坏性法则如果一个关系数据库系统支持某种低级（一次处理单个记录)语言，那么这个低级语言不能违反或绕过更高级语言（一次处理多个记录)规定的完整性法则或约束,即用户不能以任何方式违反数据库的约束。
二关系型数据库设计阶段（一)规划阶段规划阶段的主要工作是对数据库的必要性和可行性进行分析。
确定是否需要使用数据库，使用哪种类型的数据库,使用哪个数据库产品。
（二）概念阶段概念阶段的主要工作是收集并分析需求。
识别需求,主要是识别数据实体和业务规则。
对于一个系统来说，数据库的主要包括业务数据和非业务数据，而业务数据的定义，则依赖于在此阶段对用户需求的分析。
需要尽量识别业务实体和业务规则,对系统的整体有初步的认识,并理解数据的流动过程。
理论上,该阶段将参考或产出多种文档,比如“用例图”,“数据流图”以及其他一些项目文档。
如果能够在该阶段产出这些成果,无疑将会对后期进行莫大的帮助。
当然,很多文档已超出数据库设计者的考虑范围。
而且，如果你并不精通该领域以及用户的业务,那么请放弃自己独立完成用户需求分析的想法。
用户并不是技术专家,而当你自身不能扮演“业务顾问”的角色时,请你选择与项目组的相关人员合作，或者将其视为风险呈报给PM。
再次强调，大多数情况,用户只是行业从业者，而非职业技术人员,我们仅仅从用户那里收集需求,而非依赖于用户的知识。
记录用户需求时，可以使用一些技巧，当然这部分内容有些可能会超出数据库设计人员的职责:•努力维护一系列包含了系统设计和规格说明信息的文档，如会议记录、访谈记录、关键用户期望、功能规格、技术规格、测试规格等。
•频繁与干系人沟通并收集反馈。
•标记出你自己添加的,不属于客户要求的,未决内容。
•与所有关键干系人尽快确认项目范围,并力求冻结需求。
此外，必须严谨处理业务规则,并详细记录。
在之后的阶段，将会根据这些业务规则进行设计。
当该阶段结束时,你应该能够回答以下问题:•需要哪些数据?•数据该被怎样使用?•哪些规则控制着数据的使用？•谁会使用何种数据?•客户想在核心功能界面或者报表上看到哪些内容？•数据现在在哪里？•数据是否与其他系统有交互、集成或同步?•主题数据有哪些？•核心数据价值几何，对可靠性的要求程度?并且得到如下信息：•实体和关系•属性和域•可以在数据库中强制执行的业务规则•需要使用数据库的业务过程（三）逻辑阶段逻辑阶段的主要工作是绘制E-Ｒ图,或者说是建模。
建模工具很多，有不同的图形表示方法和软件。
这些工具和软件的使用并非关键,笔者也不建议读者花大量时间在建模方法的选择上。
对于大多数应用来说，E-R图足以描述实体间的关系。
建模关键是思想而不是工具,软件只是起到辅助作用,识别实体关系才是本阶段的重点。
除了实体关系，我们还应该考虑属性的域（值类型、范围、约束)(四）实现阶段实现阶段主要针对选择的ＲDＢMＳ定义Ｅ－R图对应的表,考虑属性类型和范围以及约束。
（五)物理阶段物理阶段是一个验证并调优的阶段，是在实际物理设备上部署数据库，并进行测试和调优。
三设计原则（一)降低对数据库功能的依赖功能应该由程序实现，而非DB实现。
原因在于,如果功能由DＢ实现时,一旦更换的ＤBMS不如之前的系统强大，不能实现某些功能,这时我们将不得不去修改代码。
所以，为了杜绝此类情况的发生,功能应该有程序实现，数据库仅仅负责数据的存储,以达到最低的耦合。
（二）定义实体关系的原则当定义一个实体与其他实体之间的关系时,需要考量如下:•牵涉到的实体识别出关系所涉及的所有实体。
•所有权考虑一个实体“拥有”另一个实体的情况。
•基数考量一个实体的实例和另一个实体实例关联的数量。
关系与表数量•描述1:１关系最少需要１张表。
•描述１:n关系最少需要2张表。
•描述n:n关系最少需要3张表。
(三)列意味着唯一的值如果表示坐标（0，0)，应该使用两列表示,而不是将“0，0”放在1个列中。
(四）列的顺序列的顺序对于表来说无关紧要，但是从习惯上来说,采用“主键+外键+实体数据+非实体数据”这样的顺序对列进行排序显然能得到比较好的可读性。
（五）定义主键和外键数据表必须定义主键和外键（如果有外键）。
定义主键和外键不仅是RＤBＭS的要求,同时也是开发的要求。
几乎所有的代码生成器都需要这些信息来生成常用方法的代码(包括SＱL文和引用),所以,定义主键和外键在开发阶段是必须的。
之所以说在开发阶段是必须的是因为,有不少团队出于性能考虑会在进行大量测试后，在保证参照完整性不会出现大的缺陷后，会删除掉ＤB的所有外键，以达到最优性能。
笔者认为,在性能没有出现问题时应该保留外键，而即便性能真的出现问题,也应该对SＱＬ文进行优化,而非放弃外键约束。
(六）选择键1 人工键与自然键人工健——实体的非自然属性,根据需要由人强加的,如GUID,其对实体毫无意义；自然健——实体的自然属性，如身份证编号。
人工键的好处：•键值永远不变•永远是单列存储人工键的缺点:•因为人工键是没有实际意义的唯一值，所以不能通过人工键来避免重复行。
笔者建议全部使用人工键。
原因如下:•在设计阶段我们无法预测到代码真正需要的值，所以干脆放弃猜测键,而使用人工键。
•人工键复杂处理实体关系,而不负责任何属性描述,这样的设计使得实体关系与实体内容得到高度解耦，这样做的设计思路更加清晰。
笔者的另一个建议是——每张表都需要有一个对用户而言有意义的自然键,在特殊情况下也许找不到这样一个项,此时可以使用复合键。
这个键我在程序中并不会使用其作为唯一标识,但是却可以在对数据库直接进行查询时使用。
使用人工键的另一根弊端,主要源自对查询性能的考量，因此选择人工键的形式（列的类型）很重要：•自增值类型由于类型轻巧查询效率更好,但取值有限。
•GＵID 查询效率不如值类型,但是取值无限,且对开发人员更加亲切。
２智能健与非智能键智能键——键值包含额外信息,其根据某种约定好的编码规范进行编码，从键值本身可以获取某些信息；非智能键，单纯的无意义键值,如自增的数字或GUID。
智能键是一把双刃剑,开发人员偏爱这种包含信息的键值,程序盼望着其中潜在的数据；数据库管理员或者设计者则讨厌这种智能键,原因也是很显然的,智能键对数据库是潜在的风险。
前面提到,数据库设计的原则之一是不要把具有独立意义的值的组合实现到一个单一的列中，应该使用多个独立的列。
数据库设计者,更希望开发人员通过拼接多个列来得到智能键,即以复合主键的形式给开发人员使用，而不是将一个列的值分解后使用。
开发人员应该接受这种数据库设计,但是很多开发者却想不明白两者的优略。
笔者认为，使用单一列实现智能键存在这样一个风险，就是我们可能在设计阶段无法预期到编码规则可能会在后期发生变化。
比如,构成智能键的局部键的值用完而引起规则变化或者长度变化,这种编码规则的变化对于程序的有效性验证与智能键解析是破坏性的，这是系统运维人员最不希望看到的。
所以笔者建议如果需要智能键,请在业务逻辑层封装（使用只读属性)，不要再持久化层实现,以避免上述问题。
(七)是否允许NULL关于NULL我们需要了解它的几个特性:•任何值和NＵLL拼接后都为ＮUＬL。
•所有与NＵLL进行的数学操作都返回NULＬ。
•引入NULＬ后,逻辑不易处理。
那么我们是否应该允许列为空呢?笔者认为这个问题的答案受到我们的开发语言的影响。
以C#为例，因为引入了可空类型来处理数据库值类型为NUＬL的情形，所以是否允许为空对开发者来说意义并不大。