数据库设计最重要的十一项法则
数据模型设计原则
数据模型设计原则数据模型设计原则是数据库设计的基础，它直接决定了数据库的稳定性、可靠性和性能。
在数据模型设计过程中，需要遵循以下原则：1. 数据库应该符合实际业务需求，而不是数据库技术本身的限制。
因此，在设计数据库之前应该认真分析业务需求和业务流程，了解业务数据的属性、关系及其使用规律。
2. 数据库表之间的关系要符合实际业务逻辑，保证数据的完整性和一致性。
在确定表间关系时，需要根据业务实际情况进行合理设计，如使用外键、触发器等技术手段保证数据一致性。
3. 数据库表结构要尽量简化，避免过于复杂的关系和字段。
一般来说，数据库表的设计应遵循最小化原则，字段尽量与业务相关联，避免冗余字段。
4. 数据库的设计应考虑数据量的估算和增长，保证数据库的扩展性和可维护性。
需要考虑定期维护和备份数据，以保证数据安全和可靠性。
5. 数据库设计中，应尽量避免使用模糊字段和模糊查询，避免数据冗余、不一致、重复等问题。
应该选择符合数据规范、数据类型、数据精度的字段，保证数据准确性和完整性。
6. 数据库表的设计应遵循规范，采用统一标准的表名、字段名、数据类型、索引等属性，避免重复名称、拼写错误、数据类型不一致等问题。
7. 在设计数据库时，应该避免过度设计，不过度使用技术手段。
数据库设计要符合业务需求和业务规模的实际情况，不应该因为技术而过度复杂，导致难以维护或系统性能下降。
总之，数据库设计是一项系统复杂的工作，需要遵循以上原则和经验，经过精心设计和提前测试，确保数据库的高效运行和数据的稳定性。
一位优秀的内容创作者，应该了解和掌握数据库设计原则，为读者提供高质量的有关数据库的内容。
数据库表结构设计3篇
数据库表结构设计第一篇：数据库表结构设计的基本原则在进行数据库表结构设计时，我们需要遵循一些基本的原则，以确保数据的存储、查询和维护都能够高效地进行。
1. 数据表的命名应该具有描述性数据表的命名应该具有描述性，能够清晰地表达其所存储的数据内容。
一般来说，我们可以采用名词或者名词短语进行命名。
2. 字段的命名应该具有描述性同样，字段的命名也应该具有描述性，能够清晰地表达其所存储的数据内容。
一般来说，我们可以采用名词或者名词短语进行命名。
3. 数据库表要符合规范化要求规范化是指将数据按照特定的规则进行分解和组织，以达到减少冗余、消除数据插入、删除和更新异常等目的。
在进行数据库表结构设计时，我们应该尽可能地符合规范化要求。
4. 尽量避免使用具有歧义的列名称在字段的命名中，我们应该尽量避免使用容易产生歧义的列名称，例如“state”，这个单词既可以表示州，也可以表示状态。
5. 尽量避免使用大量的空间占用数据类型选择合适的数据类型可以有效地优化数据库的性能。
在进行数据库表结构设计时，应该尽量避免使用大量的空间占用数据类型，例如“text”类型。
6. 尽量避免冗余数据冗余数据指的是相同的数据在不同的表中多次出现。
在进行数据库表结构设计时，应该尽量避免冗余数据，尽量采用关联表的方式进行数据存储。
7. 考虑表的扩展性在进行数据库表结构设计时，应该考虑表的扩展性。
我们可以在表中添加扩展字段，或者将不同的数据类型存储在不同的表中，以支持表的扩展。
以上就是数据库表结构设计的基本原则。
在进行数据库表结构设计时，我们应该尽量遵循这些原则，以为我们的数据库系统奠定坚实的基础。
数据库设计规范与命名规则
数据库设计规范、技巧与命名规范一、数据库设计过程数据库技术是信息资源管理最有效的手段。
数据库设计是指：对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。
数据库设计的各阶段：A、需求分析阶段：综合各个用户的应用需求(现实世界的需求)。
B、在概念设计阶段：形成独立于机器和各DBMS产品的概念模式(信息世界模型)，用E-R图来描述。
C、在逻辑设计阶段：将E-R图转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式。
然后根据用户处理的要求，安全性的考虑，在基本表的基础上再建立必要的视图(VIEW)形成数据的外模式。
D、在物理设计阶段：根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。
1. 需求分析阶段需求收集和分析，结果得到数据字典描述的数据需求(和数据流图描述的处理需求)。
需求分析的重点：调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。
需求分析的方法：调查组织机构情况、各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。
常用的调查方法有：跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。
分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。
自顶向下的结构化分析方法(Structured Analysis，简称SA方法)从最上层的系统组织机构入手，采用逐层分解的方式分析系统，并把每一层用数据流图和数据字典描述。
数据流图表达了数据和处理过程的关系。
系统中的数据则借助数据字典(Data Dictionary，简称DD)来描述。
2. 概念结构设计阶段通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型，可以用E-R图表示。
概念模型用于信息世界的建模。
概念模型不依赖于某一个DBMS支持的数据模型。
概念模型可以转换为计算机上某一DBMS 支持的特定数据模型。
Access数据库设计技巧
Access数据库设计技巧数据库设计是构建可靠、高效和可维护的数据库系统的关键步骤。
Microsoft Access作为一种常用的数据库管理系统，为用户提供了强大的工具和功能，以便设计和管理数据库。
本文将介绍一些Access数据库设计的技巧，帮助您更好地利用这个工具。
一、合理规划数据库结构1. 设计数据库之前先明确需求：在开始设计数据库之前，务必明确数据库的需求。
要了解系统中需要存储的数据类型、数据量、数据关系等，以便更准确地设计表和字段。
2. 分析实体和关系：根据需求，将系统中涉及的实体（例如客户、产品）和实体之间的关系进行分析。
了解实体的属性和关系将有助于确定数据库的表和表之间的连接方式。
3. 正规化数据库：正规化是一种设计技巧，旨在消除数据冗余并提高数据库的性能和可维护性。
根据关系数据库理论，将表分解为更小的、更规范的形式，以避免数据重复和逻辑混乱。
二、使用适当的数据类型1. 选择恰当的字段类型：Access提供了多种字段类型，包括文本、数字、日期/时间等。
在选择字段类型时，要根据实际需求进行评估，并选择最适合的字段类型以节省空间和提高性能。
2. 使用关联字段：如果多个表之间存在关联关系，可以使用关联字段来建立表之间的连接。
通过关联字段，可以轻松地进行表之间的查询和分析，提高数据的管理效率。
三、合理设计索引1. 了解索引类型：在Access中，可以创建多种类型的索引，包括主键索引、唯一索引和普通索引等。
了解不同类型的索引特点，有助于更好地设计和管理索引。
2. 创建适当的索引：索引可以提高数据库查询的速度和效率，但同时也会增加数据库的存储空间。
因此，应该根据查询需求和数据库的大小选择创建索引的字段，以权衡查询性能和存储需求。
四、使用查询和表关系1. 利用查询进行数据分析：通过使用查询功能，可以从数据库中提取特定条件的数据，并进行排序、过滤、计算等操作。
根据实际需求，使用查询可以帮助用户更方便地进行数据分析和处理。
access数据库设计原则
access数据库设计原则Access数据库设计原则Access数据库是一种常用的关系型数据库管理系统，广泛应用于数据存储和管理领域。
在进行Access数据库设计时，需要遵循一些基本原则，以确保数据库的高效性、可靠性和易用性。
本文将介绍几个重要的Access数据库设计原则，以帮助读者设计出优秀的数据库。
一、遵循规范化原则规范化是数据库设计的基本原则之一，它旨在消除数据冗余，提高数据存储效率。
在Access数据库设计中，通常采用三范式来进行规范化设计。
三范式包括：第一范式（1NF）要求数据表中的每一列都是不可分割的原子数据项；第二范式（2NF）要求数据表中的每一列都和主键相关，不存在部分依赖；第三范式（3NF）要求数据表中的每一列都和主键直接相关，不存在传递依赖。
遵循规范化原则可以确保数据库结构清晰、数据一致性高。
二、合理划分表和字段在设计Access数据库时，需要根据数据的逻辑关系将数据划分为不同的表，并为每个表确定适当的字段。
表的划分应该遵循单一职责原则，即每个表只存储与一个实体或一个关系有关的数据。
字段的确定应该考虑到数据的完整性和准确性，避免冗余字段和多余字段的存在。
同时，为字段选择适当的数据类型和长度，以节省存储空间和提高查询效率。
三、建立适当的索引索引是提高数据库查询效率的重要手段之一。
在Access数据库设计中，需要为经常用于查询的字段建立索引，以加快查询速度。
通常情况下，可以为主键字段自动创建索引，同时根据查询的需求，为其他字段创建适当的索引。
但是需要注意的是，过多的索引会增加数据库的存储空间和维护成本，同时会降低插入、删除和更新操作的性能。
四、设定合理的关系在多表关系的设计中，需要设定合理的关系类型和关系规则，以确保数据的完整性和一致性。
常见的关系类型包括一对一关系、一对多关系和多对多关系。
在设定关系时，需要考虑参照完整性和级联删除、级联更新等关系规则，以避免数据的不一致和错误。
数据库设计规范手册
数据库设计规范手册1. 简介数据库设计规范手册是为了统一数据库设计标准和提高数据库设计质量而编写的指南。
本手册将详细介绍数据库设计的基本原则、规范要求以及最佳实践，旨在帮助数据库设计人员更好地完成其工作。
2. 数据库设计原则在进行数据库设计时，应遵循以下原则：2.1 数据库规范化•利用规范化减少重复数据。
•使用主键、外键来确保数据完整性。
2.2 完整性约束•定义适当的唯一约束、非空约束等。
•使用触发器确保业务逻辑的执行。
2.3 性能优化•避免大量冗余字段，减少存储空间占用。
•根据查询需求创建必要的索引。
•注意合理使用分区技术来优化查询效率。
2.4 安全性考虑•对敏感数据进行加密存储。
•设置合适的权限和访问控制策略。
3. 数据库对象命名规范为了方便管理和沟通，应遵循一致的命名规范。
以下是常见对象的命名要求：3.1 表名•使用小写字母。
•使用下划线作为单词分隔符。
•采用名词复数形式。
3.2 列名•使用小写字母。
•使用下划线作为单词分隔符。
•避免使用保留关键字。
3.3 约束名•使用大写字母和下划线组合。
4. 数据库设计规范要求在进行数据库设计时，应满足以下要求：4.1 表设计•设计符合业务需求的表结构，避免冗余字段。
•定义适当的主键、外键关系。
•注意选择正确的数据类型和长度。
4.2 索引设计•基于查询需求创建索引，提高查询性能。
•注意索引不宜过多，避免对写操作产生过多影响。
4.3 视图和存储过程设计•合理使用视图简化复杂查询。
•利用存储过程实现业务逻辑的封装和复用。
5. 最佳实践5.1 数据库备份与恢复策略定期备份数据库，并确保可靠的恢复策略以应对突发情况。
5.2 日志管理与审计追踪监控数据库日志，及时发现和解决潜在问题，并实施安全审计追踪。
5.3 定期维护与性能优化定期进行数据库维护工作，包括索引重建、数据清理等，并优化数据库性能以满足业务需求。
结论数据库设计规范手册对于确保数据库设计的一致性和高质量至关重要。
数据库开发规范
数据库开发规范数据库开发规范指的是在进行数据库开发工作时，要遵循的一系列规范和准则，以确保数据库的设计合理性、效率和稳定性。
以下是一个包括约1000字的数据库开发规范：一、命名规范1. 表名、字段名、视图名、存储过程名、函数名、触发器名等应该使用有意义的英文单词或词组来命名，且使用下划线作为单词之间的分隔符。
例如，表名可以命名为“students”，字段名可以命名为“student_id”。
2. 表名应该使用单数形式，例如“student”而不是“students”。
二、数据类型规范1. 在选择数据类型时，应尽量使用最简单的数据类型，避免使用过于复杂的数据类型。
2. 需要存储精确浮点数时应使用 DECIMAL 或 NUMERIC 数据类型，避免使用浮点型数据类型，例如 FLOAT 或DOUBLE。
3. 需要存储日期和时间时应分别使用 DATE 和 TIMESTAMP数据类型。
三、主键规范1. 每个表都应该有一个主键，用于唯一标识每一条记录。
2. 主键应该是简单、稳定和不可更改的。
一般情况下，可以使用自增长的整数作为主键。
3. 主键的命名应该统一，并且在命名时应遵循表名加上“_id”的规则。
四、索引规范1. 对于经常被查询或用于连接的字段，应该添加索引，以提高查询性能。
2. 除非有特殊需要，不要在较小的表上创建索引，因为索引会增加查询和更新的开销。
3. 在创建索引时，应该根据具体的查询需求选择合适的索引类型，包括唯一索引、非唯一索引、聚集索引、非聚集索引等。
五、约束规范1. 应该使用外键约束来确保数据的完整性和一致性。
2. 外键约束应该定义在子表上，并且应该指向主表的主键。
3. 在删除或更新主表的数据时，应该采取合适的措施来处理与之相关的子表数据，例如设置级联删除或级联更新。
六、存储过程和函数规范1. 存储过程和函数应该使用有意义的名称，以描述其功能。
2. 存储过程和函数应该尽量简短，并且只处理一个具体的业务逻辑。
数据库设计规范
概述目的软件研发数据库设计规范作为数据库设计的操作规范，详细描述了数据库设计过程及结果，用于指导系统设计人员正确理解和开展数据库设计。
适用范围术语定义DBMS：数据库管理系统，常用的商业DBMS有Oracle, SQL Server, DB2等。
数据库设计：数据库设计是在给定的应用场景下，构造适用的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。
概念数据模型：概念数据模型以实体-关系(Entity-RelationShip,简称E-R)理论为基础，并对这一理论进行了扩充。
它从用户的观点出发对信息进行建模，主要用于数据库概念级别的设计，独立于机器和各DBMS产品。
可以用Sybase PowerDesigner工具来建立概念数据模型（CDM）。
逻辑数据模型：将概念数据模型转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式。
可以用Sybase PowerDesigner工具直接建立逻辑数据模型（LDM），或者通过CDM转换得到。
物理数据模型：在逻辑数据模型基础上，根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。
可以用Sybase PowerDesigner工具直接建立物理数据模型（PDM），或者通过CDM / LDM转换得到。
数据库设计原则按阶段实施并形成该阶段的成果物一般符合3NF范式要求；兼顾规范与效率使用公司规定的数据库设计软件工具命名符合公司标准和项目标准数据库设计目标规范性：一般符合3NF范式要求，减少冗余数据。
高效率：兼顾规范与效率，适当进行反范式化，满足应用系统的性能要求。
紧凑性：例如能用char(10)的就不要用char(20)，提高存储的利用率和系统性能，但同时也要兼顾扩展性和可移植性。
易用性：数据库设计清晰易用，用户和开发人员均能容易地理解。
设计过程规范数据库设计过程包括如下阶段：数据分析、概念设计、逻辑设计、物理设计、实施与运行维护。
数据库设计的基本要求
数据库设计的基本要求
数据库设计的基本要求包括以下几点：
1. 数据完整性：确保数据库中的数据完整、准确、一致，并满足业务需求。
可以通过定义各种约束、规则、触发器等手段来保证数据的完整性。
2. 数据一致性：数据库中的各个数据之间应该保持一致性，不同表之间的数据应该能够互相关联和匹配。
3. 数据冗余度最小化：避免在数据库中存储重复的数据，尽量减少冗余。
4. 数据库的高性能和高可用性：设计数据库时要考虑到数据的访问和查询速度，尽量减少查询时间，并确保数据库可靠地运行和持续可用。
5. 数据库的安全性：设计数据库时要考虑数据的安全性和保密性，包括访问控制、权限管理、数据加密等方面。
6. 数据库的灵活性和可扩展性：数据库设计应该具备适应需求变化和扩展的能力，能够支持新增业务和数据的快速扩展。
7. 数据库的易用性和维护性：数据库设计要简单易用，并且易于维护和管理，包括备份、恢复、性能优化等方面。
8. 规范化和归一化：数据库设计应该遵循规范化原则，通过分
解数据和表，将数据组织成合理的关系模型，以提高数据的存储效率和操作效率。
9. 可理解性和可扩展性：数据库设计要具备良好的文档和注释，以便后续的开发人员能够理解和维护数据库结构。
另外，数据库的结构和架构应该能够支持未来的扩展和迭代。
综上所述，数据库设计的基本要求包括数据完整性、一致性、冗余度最小化、高性能和高可用性、安全性、灵活性和可扩展性、易用性和维护性、规范化和归一化、可理解性和可扩展性等方面。
mysql数据表设计原则
mysql数据表设计原则Mysql是一种开源的关系型数据库管理系统，它广泛应用于各种网站和应用程序中。
在使用Mysql时，数据表设计是非常重要的一部分。
本文将介绍mysql数据表设计的原则。
一、概述1.1 数据库设计的重要性数据库设计是任何软件开发项目的关键步骤之一。
一个良好的数据库设计可以提高数据存储和检索效率，降低维护成本和风险，并使系统更加灵活和可扩展。
1.2 数据表设计原则在mysql中，数据表设计需要遵循一些基本原则。
这些原则包括：规范化、简洁性、可读性、可扩展性、可维护性等。
二、规范化2.1 什么是规范化？规范化是指将一个复杂的数据结构分解成多个简单的结构，并通过关系连接来实现对这些结构的访问。
规范化可以消除冗余信息，并确保每个数据项只在一个地方存储，从而提高了数据存储和检索效率。
2.2 规范化级别mysql支持三个规范化级别：第一范式（1NF）、第二范式（2NF）和第三范式（3NF）。
通常情况下，我们应该尽可能地满足第三范式。
2.3 规范化的优点规范化可以提高数据存储和检索效率，降低维护成本和风险，并使系统更加灵活和可扩展。
同时，规范化还可以减少数据冗余，提高数据的一致性和完整性。
三、简洁性3.1 什么是简洁性？简洁性是指数据表设计应该尽可能地简单明了，避免不必要的复杂性。
在mysql中，一个简单的数据表通常比一个复杂的数据表更易于维护和管理。
3.2 如何实现简洁性？实现简洁性需要注意以下几点：（1）避免过度设计。
只需创建必要的字段和索引即可。
（2）避免使用过多的触发器、存储过程等数据库对象。
（3）避免使用过多的外键关系。
外键关系可以增加数据一致性，但也会增加查询时间和写入时间。
四、可读性4.1 什么是可读性？可读性是指数据表设计应该易于理解和阅读。
在mysql中，一个易于理解和阅读的数据表可以提高开发效率，并降低出错率。
4.2 如何实现可读性？实现可读性需要注意以下几点：（1）使用有意义的字段名。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
11个数据库设计的重要规则
简介
在您开始阅读这篇文章之前，我得明确地告诉您，我并不是一个数据库设计领域的大师。以
下列出的11点是我对自己在平时项目实践和阅读中学习到的经验总结出来的个人见解。我
个人认为它们对我的数据库设计提供了很大的帮助。实属一家之言，欢迎拍砖 : )
我之所以写下这篇这么完整的文章是因为，很多开发者一参与到数据库设计，就会很自然地
把 “三范式” 当作银弹一样来使用。他们往往认为遵循这个规范就是数据库设计的唯一标
准。由于这种心态，他们往往尽管一路碰壁也会坚持把项目做下去。
如果你对 “三范式” 不清楚，请点击这里（FQ）一步一步的了解什么是“三范式”。
大家都说标准规范是重要的指导方针并且也这么做着，但是把它当作石头上的一块标记来记
着（死记硬背）还是会带来麻烦的。以下11点是我在数据库设计时最优先考虑的规则。
规则 1：弄清楚将要开发的应用程序是什么性质的（OLTP 还是 OPAP）？
当你要开始设计一个数据库的时候，你应该首先要分析出你为之设计的应用程序是什么类型
的，它是 “事务处理型”（Transactional） 的还是 “分析型” （Analytical）的？你会
发现许多开发人员采用标准化做法去设计数据库，而不考虑目标程序是什么类型的，这样做
出来的程序很快就会陷入性能、客户定制化的问题当中。正如前面所说的，这里有两种应用
程序类型， “基于事务处理” 和 “基于分析”，下面让我们来了解一下这两种类型究竟说的
是什么意思。
事务处理型：这种类型的应用程序，你的最终用户更关注数据的增查改删（CRUD，
Creating/Reading/Updating/Deleting）。这种类型更加官方的叫法是 “OLTP” 。
分析型：这种类型的应用程序，你的最终用户更关注数据分析、报表、趋势预测等等功能。
这一类的数据库的 “插入” 和 “更新” 操作相对来说是比较少的。它们主要的目的是更加快
速地查询、分析数据。这种类型更加官方的叫法是 “OLAP” 。
那么换句话说，如果你认为插入、更新、删除数据这些操作在你的程序中更为突出的话，那
就设计一个规范化的表否则的话就去创建一个扁平的、不规范化的数据库结构。
以下这个简单的图表显示了像左边Names和Address这样的简单规范化的表，怎么通过
应用不规范化结构来创建一个扁平的表结构。
规则 2：将你的数据按照逻辑意义分成不同的块，让事情做起来更简单
这个规则其实就是 “三范式” 中的第一范式。违反这条规则的一个标志就是，你的查询使用
了很多字符串解析函数
例如 substring、charindex等等。若真如此，那就需要应用这条规则了。
比如你看到的下面图片上有一个有学生名字的表，如果你想要查询学生名字中包含
“Koirala”，但不包含“Harisingh”的记录，你可以想象一下你将会得到什么样的结果。
所以更好的做法是将这个字段拆分为更深层次的逻辑分块，以便我们的表数据写起来更干
净，以及优化查询。
规则 3：不要过度使用 “规则 2”
开发者都是一群很可爱的生物。如果你告诉他们这是一条解决问题的正路，他们就会一直这
么做下去，做到过了头导致了一些不必要的后果。这也可以应用于我们刚刚在前面提到的规
则2。当你考虑字段分解时，先暂停一下，并且问问你自己是否真的需要这么做。正如所说
的，分解应该是要符合逻辑的。
例如，你可以看到电话号码这个字段，你很少会把电话号码的ISD代码单独分开来操作（除
非你的应用程序要求这么做）。所以一个很明智的决定就是让它保持原样，否则这会带来更
多的问题。
规则 4：把重复、不统一的数据当成你最大的敌人来对待
集中那些重复的数据然后重构它们。我个人更加担心的是这些重复数据带来的混乱而不是它
们占用了多少磁盘空间。
例如下面这个图表，你可以看到 "5th Standard" 和 "Fifth standard" 是一样的意思，
它们是重复数据。现在你可能会说是由于那些录入者录入了这些重复的数据或者是差劲的验
证程序没有拦住，让这些重复的数据进入到了你的系统。现在，如果你想导出一份将原本在
用户眼里十分困惑的数据显示为不同实体数据的报告，该怎么做呢？
解决方法之一是将这些数据完整地移到另外一个主表，然后通过外键引用过来。在下面这个
图表中你可以看到我们是如何创建一个名为 “Standards”（课程级别） 的主表，然后同样
地使用简单的外键连接过去。
规则 5：当心被分隔符分割的数据，它们违反了“字段不可再分”
前面的规则2即“第一范式”说的是避免 “重复组” 。下面这个图表作为其中的一个例子解释
了 “重复组”是什么样子的。如果你仔细的观察 syllabus（课程） 这个字段，会发现在这
一个字段里实在是填充了太多的数据了。像这些字段就被称为 “重复组” 了。如果我们又得
必须使用这些数据，那么这些查询将会十分复杂并且我也怀疑这些查询会有性能问题。
这些被塞满了分隔符的数据列需要特别注意，并且一个较好的办法是将这些字段移到另外一
个表中，使用外键连接过去，同样地以便于更好的管理。
那么，让我们现在就应用规则2（第一范式） “避免重复组” 吧。你可以看到上面这个图表，
我创建了一个单独的 syllabus（课程） 表，然后使用 “多对多” 关系将它与 subject（科
目） 表关联起来。
通过这个方法，主表（student表）的 syllabus（课程） 字段就不再有重复数据和分隔
符了。
规则 6：当心那些仅仅部分依赖主键的列
留心注意那些仅仅部分依赖主键的列。例如上面这个图表，我们可以看到这个表的主键是
Roll No.+Standard
。现在请仔细观察 syllabus 字段，可以看到 syllabus（课程） 字段仅仅关联（依赖）
Standard（课程级别） 字段而不是直接地关联（依赖）某个学生（Roll No. 字段）。
Syllabus（课程） 字段关联的是学生正在学习的哪个课程级别（Standard字段）而不是
直接关联到学生本身。那如果明天我们要更新教学大纲（课程）的话还要痛苦地为每个同学
也修改一下，这明显是不符合逻辑的（不正常的做法）。更有意义的做法是将这些字段从这
个表移到另外一个表，然后将它们与 Standard（课程级别）表关联起来。
你可以看到我们是如何移动 syllabus（课程）字段并且同样地附上 Standard 表。
这条规则只不过是 “三范式” 里的 “第二范式”：“所有字段都必须完整地依赖主键而不是部
分依赖”。
规则 7：仔细地选择派生列
如果你正在开发一个 OLTP 型的应用程序，那强制不去使用派生字段会是一个很好的思
路，除非有迫切的性能要求，比如经常需要求和、计算的 OLAP 程序，为了性能，这些派
生字段就有必要存在了。
通过上面的这个图表，你可以看到 Average 字段是如何依赖 Marks 和 Subjects 字段
的。这也是冗余的一种形式。因此对于这样的由其他字段得到的字段，需要思考一下它们是
否真的有必要存在。
这个规则也被称为 “三范式” 里的第三条：“不应该有依赖于非主键的列” 。 我的个人看法
是不要盲目地运用这条规则，应该要看实际情况，冗余数据并不总是坏的。如果冗余数据是
计算出来的，看看实际情况再来决定是否应用这第三范式。
规则 8：如果性能是关键，不要固执地去避免冗余
不要把 “避免冗余” 当作是一条绝对的规则去遵循。如果对性能有迫切的需求，考虑一下打
破常规。常规情况下你需要做多个表的连接操作，而在非常规的情况下这样的多表连接是会
大大地降低性能的。
规则 9：多维数据是各种不同数据的聚合
OLAP 项目主要是解决多维数据问题。比如你可以看看下面这个图表，你会想拿到每个国
家、每个顾客、每段时期的销售额情况。简单的说你正在看的销售额数据包含了三个维度的
交叉。
为这种情况做一个实际的设计是一个更好的办法。简单的说，你可以创建一个简单的主要销
售表，它包含了销售额字段，通过外键将其他所有不同维度的表连接起来。
规则 10：将那些具有“名值表”特点的表统一起来设计
很多次我都遇到过这种 “名值表” 。 “名值表” 意味着它有一些键，这些键被其他数据关联
着。比如下面这个图表，你可以看到我们有 Currency（货币型）和 Country（国家）这
两张表。如果你仔细观察你会发现实际上这些表都只有键和值。
对于这种表，创建一个主要的表，通过一个 Type（类型）字段来区分不同的数据将会更有
意义。
规则 11：无限分级结构的数据，引用自己的主键作为外键
我们会经常碰到一些无限父子分级结构的数据（树形结构？）。例如考虑一个多级销售方案
的情况，一个销售人员之下可以有多个销售人员。注意到都是 “销售人员” 。也就是说数据
本身都是一种。但是层级不同。这时候我们可以引用自己的主键作为外键来表达这种层级关
系，从而达成目的。
这篇文章的用意不是叫大家不要遵循范式，而是叫大家不要盲目地遵循范式。根据你的项目
性质和需要处理的数据类型来做出正确的选择。