如何设计数据库表
数据库表设计与规范化技巧与经验
数据库表设计与规范化技巧与经验在设计和规范化数据库表时，有一些技巧和经验可以帮助我们创建高效、易于维护的数据库结构。
下面，我将分享一些关键的技巧和经验：1. 深入了解业务需求在设计数据库表之前，必须充分了解业务需求。
与业务相关的主要实体和其属性应该成为数据库表的主要组成部分。
了解业务需求还可以帮助我们预测将来可能出现的需求变化，并相应地进行设计，以避免不必要的结构修改和数据迁移。
2. 单一职责原则每个数据库表应该遵循单一职责原则，即一个表应该只负责管理一个实体类型的数据。
这样做可以确保数据库结构的清晰性和可维护性。
避免将多个实体类型存储在同一个表中，这样会导致数据冗余和性能问题。
3. 数据类型的选择正确选择适当的数据类型对于数据库性能和数据一致性至关重要。
尽量使用最小的合适数据类型来节省存储空间和提高查询性能。
同时，还要确保数据类型的一致性，例如使用日期时间类型来存储日期和时间数据，而不仅仅是字符串。
4. 主键和外键在设计数据库表时，明确主键和外键是很重要的。
主键是唯一标识表中每个记录的列，而外键用于实现不同表之间的关系。
正确使用主键和外键可以确保数据的完整性和一致性，并且可以帮助我们进行高效的数据查询和关联。
5. 正规化规范化是数据库设计中的重要概念，它有助于减少数据冗余、提高数据一致性和数据更新性能。
在规范化过程中，将数据库分解成更小、更专注的部分，并将其各自关联起来。
这样做可以避免数据的重复和不一致，并提供更好的查询性能。
6. 命名规范为数据库表、列和约束等命名时，应遵循一致的命名规范。
命名应该具有描述性，以便他人能够理解和使用数据库结构。
尽量避免使用过长或过于简单的命名，以免造成混淆或歧义。
另外，还要注意使用可读性强的命名风格，例如采用下划线分隔的命名方式。
7. 索引的使用合理使用索引可以大大加快查询和数据检索的速度。
在设计表时，可以针对常用的查询条件和排序字段添加适当的索引。
但是请注意过多的索引会降低数据的写入性能，因此需要根据实际需求进行权衡。
数据库表结构设计3篇
数据库表结构设计第一篇：数据库表结构设计的基本原则在进行数据库表结构设计时，我们需要遵循一些基本的原则，以确保数据的存储、查询和维护都能够高效地进行。
1. 数据表的命名应该具有描述性数据表的命名应该具有描述性，能够清晰地表达其所存储的数据内容。
一般来说，我们可以采用名词或者名词短语进行命名。
2. 字段的命名应该具有描述性同样，字段的命名也应该具有描述性，能够清晰地表达其所存储的数据内容。
一般来说，我们可以采用名词或者名词短语进行命名。
3. 数据库表要符合规范化要求规范化是指将数据按照特定的规则进行分解和组织，以达到减少冗余、消除数据插入、删除和更新异常等目的。
在进行数据库表结构设计时，我们应该尽可能地符合规范化要求。
4. 尽量避免使用具有歧义的列名称在字段的命名中，我们应该尽量避免使用容易产生歧义的列名称，例如“state”，这个单词既可以表示州，也可以表示状态。
5. 尽量避免使用大量的空间占用数据类型选择合适的数据类型可以有效地优化数据库的性能。
在进行数据库表结构设计时，应该尽量避免使用大量的空间占用数据类型，例如“text”类型。
6. 尽量避免冗余数据冗余数据指的是相同的数据在不同的表中多次出现。
在进行数据库表结构设计时，应该尽量避免冗余数据，尽量采用关联表的方式进行数据存储。
7. 考虑表的扩展性在进行数据库表结构设计时，应该考虑表的扩展性。
我们可以在表中添加扩展字段，或者将不同的数据类型存储在不同的表中，以支持表的扩展。
以上就是数据库表结构设计的基本原则。
在进行数据库表结构设计时，我们应该尽量遵循这些原则，以为我们的数据库系统奠定坚实的基础。
数据库表设计思路
数据库表设计思路随着信息化时代的到来，数据库已经成为了各个领域中不可或缺的一部分。
而数据库表的设计则是构建和管理数据库的基础。
合理的数据库表设计能够提高数据存储和检索的效率，保证数据的安全性和一致性。
本文将围绕数据库表设计思路展开讨论，包括表的结构设计、字段设计、数据类型选择等方面。
一、表的结构设计在进行数据库表的设计时，首先需要确定表的结构。
表的结构定义了表中存储的数据的组织形式。
一个合理的表结构应该能够满足查询和分析的需求，并且具备良好的扩展性。
表的结构设计可以从以下几个方面考虑：1. 表的命名：表的命名应该具备一定的描述性，能够清晰地表达表的含义。
命名应该使用英文单词，避免使用中文或拼音。
2. 表的主键：每个表都应该有一个主键，用来唯一标识表中的每一行数据。
主键可以是一个或多个字段的组合。
3. 表的关系：如果存在多个表之间的关系，需要考虑使用外键来建立表与表之间的关联关系。
二、字段设计在进行字段设计时，需要考虑字段的数据类型、长度等方面。
字段的设计直接影响到数据的存储和检索效率。
字段设计可以从以下几个方面考虑：1. 数据类型选择：根据字段存储的数据类型选择合适的数据类型，以减少存储空间的占用和提高查询效率。
例如，对于整数类型，可以选择int或bigint，对于字符串类型，可以选择varchar或text。
2. 字段长度：根据字段存储的数据的长度选择合适的字段长度。
过长的字段长度会浪费存储空间，而过短的字段长度可能导致数据丢失。
3. 约束条件：根据字段的要求添加合适的约束条件，例如唯一约束、非空约束等，以保证数据的完整性和一致性。
三、数据类型选择在进行数据类型选择时，需要考虑字段存储的数据类型、数据长度、数据范围等方面。
数据类型选择可以从以下几个方面考虑：1. 整数类型：根据数据的范围选择合适的整数类型，例如tinyint、smallint、int、bigint等。
2. 浮点数类型：根据数据的精度要求选择合适的浮点数类型，例如float、double等。
数据库表结构设计
数据库表结构设计数据库表结构设计是数据库设计的重要环节之一。
一个好的数据库表结构设计可以提高数据存储和查询效率，保证数据的准确性和一致性，同时也方便扩展和维护数据库系统。
在进行数据库表结构设计之前，需要明确数据库系统的需求和目标。
对于不同的应用场景和业务需求，数据库表结构设计可能会有所不同。
下面将以一个电商网站为例，介绍如何进行数据库表结构设计。
一、需求分析在电商网站中，我们需要存储商品、用户、订单等相关信息。
首先，我们需要明确需要存储哪些信息，这些信息之间是否存在关联关系。
例如，商品和订单之间存在关联关系，订单和用户之间也存在关联关系。
其次，我们需要确定每个信息对象的属性，即每个表中的字段。
二、实体-关系图设计根据需求分析的结果，我们可以根据实体-关系模型进行数据库表结构设计。
在这个电商网站中，我们可以根据实体-关系图设计出商品表、用户表和订单表三个基本表。
1. 商品表商品表用于存储商品的相关信息，可以包括商品ID、名称、描述、价格、库存等字段。
其中，商品ID作为主键，可以用于唯一标识每个商品。
另外，可以根据实际需求添加其他字段，如商品分类、销量等。
2. 用户表用户表用于存储用户的相关信息，可以包括用户ID、用户名、密码、手机号、邮箱等字段。
其中，用户ID作为主键，可以用于唯一标识每个用户。
另外，可以根据实际需求添加其他字段，如用户等级、积分等。
3. 订单表订单表用于存储订单的相关信息，可以包括订单ID、用户ID、商品ID、数量、金额、下单时间等字段。
其中，订单ID作为主键，可以用于唯一标识每个订单。
用户ID和商品ID可以作为外键，用于关联用户表和商品表。
另外，可以根据实际需求添加其他字段，如订单状态、收货地址等。
三、表关系设计在实体-关系图设计的基础上，我们需要确定表之间的关系。
在这个电商网站中，商品和订单之间存在一对多的关系，即一个订单可以包含多个商品；订单和用户之间也存在一对多的关系，即一个用户可以有多个订单。
数据库表设计的说明书
数据库表设计的说明书一、背景介绍随着信息技术的快速发展，数据库的使用越来越广泛，成为组织和企业管理数据的重要工具。
而数据库表的设计是数据库系统的核心，直接关系到数据存储、查询和管理的效率和准确性。
本文将对数据库表设计进行详细说明，以确保设计的准确性和合理性。
二、数据需求分析在进行数据库表设计之前，首先需要对数据需求进行分析。
根据实际情况和应用要求，确定需要存储的数据类型、数据量以及数据之间的关系。
根据需求分析的结果，确定数据库的实体、属性和关系，为后续的表设计提供基础。
三、表设计原则1. 准确性：表设计应准确地反映出实体之间的关系和属性的含义，避免冗余和错误数据的存储。
2. 效率性：表设计要考虑数据的存储、查询和管理的效率，合理利用索引、主键和外键等关系，在满足需求的同时提高系统性能。
3. 一致性：表设计应符合统一的命名规范和约定，保持各个表之间的一致性和整体性。
4. 扩展性：表设计要具备良好的扩展性，能够适应未来需求的变化和扩展。
四、表设计步骤1. 确定主要实体和属性：根据需求分析的结果，确定主要的实体和相应的属性。
实体可以是具体的对象、人员，也可以是某个事件、业务等。
2. 定义实体和属性之间的关系：根据实际情况，确定主实体与其他实体之间的关系。
例如，一对一关系、一对多关系或多对多关系。
3. 设计表结构：根据确定的实体和属性，设计表的结构。
包括表的名称、字段名称、数据类型、长度、约束等。
4. 确定主键和外键：根据表的关系，确定主键和外键。
主键用于唯一标识表中的每条记录，外键用于建立表之间的关联。
5. 设计索引：根据数据库的查询需求，设计索引以提高查询效率。
索引可以根据需要建立在一个或多个字段上。
6. 完善约束和触发器：根据具体情况，为表添加约束和触发器，保证数据的完整性和一致性。
五、表设计示例以学生成绩管理系统为例，设计学生表、课程表和成绩表。
1. 学生表：字段包括学生ID、姓名、性别、年龄等。
设计数据库表
一、设计数据库表1.创建一个新的数据库法1：法2：左大圆按钮2. 输入数据库名称导航窗格：3. 创建按钮：创建数据库表法1：单击“表”按钮：创建数据库表法2：单击“表设计”，我们选用的。
输入表的字段及属性。
保存表：保存前应先定义主键。
出错提示右击学号字段，选为主键。
添加字段，鼠标在一个字段上，右击，选择插入列。
在这里也可以选择删除列，即删除字段。
在“创建”-“表设计”—右击表名—“设计视图”格式可以调整字段顺序。
二、向数据库表中添加记录1. 添加记录很简单，只需在数据库容器中选择表名称，然后双击该名称即可进入数据表视图中的表。
打开表后就可在每个字段中输入值。
2. 向数据库表中添加记录。
在数据表视图情况下。
注意保存。
保存为*.mdb格式的数据库文件保存。
第三部分创建ODBC数据源1. 设置/控制面板/性能和维护/管理工具/数据源（ODBC）2. 用户DSN----添加3. 选择Microsoft Access Driver(*.mdb)4. 为数据源起名5. 选择数据库。
6. 数据库设定好以后结果。
7. 看到刚刚添加的用户数据源“CTI”。
确定后退出。
第四部分VC数据库编程1. VC++中新建File/New/Database Project2. 选择数据源。
3. 选择数据表。
双击表名“table”。
表内容出现如下所示。
4. 点击“Query”中的“SQL”，出现输入SQL语句的窗口。
5. 输入SQL语言，并点感叹号运行，即可看到运行结果。
数据库操作练习建立数据库student.mdb，包含两个表：student_info，和student_score。
VC++6.0中操作。
①无条件查询:SELECT * FROM student_scoreSELECT 姓名, 学号FROM student_score②查询满足要求的内容SELECT 学号, 姓名FROM student_info WHERE 性别 = '男'③创建表格CREATE TABLE student1 (st_class CHAR(8),st_no CHAR(10) NOT NULL,st_name CHAR(8) NOT NULL,st_sex CHAR(2),st_age SMALLINT,PRIMARY KEY (st_no)) ④创建字段ALTER TABLE student ADD stborn DATE NOT NULL⑤删除字段alter TABLE student1 DROP st_sex⑥删除表格drop table student1⑦删除记录delete from student_info where 学号='B04020003'⑧插入记录INSERT INTO student_info (学号, 姓名, 性别) VALUES ('B04020003', '张楠楠', '女')insert into student_score (学号,姓名,数学,语文,英语) values ('B04020003','张楠楠',89,90,98)insert into student_score (学号,姓名,数学,语文,英语) values ('B04020004','张小甜',89,69,95)⑨删除记录delete from student_score where 语文=69⑩修改记录UPDATE 表名 SET 列名=列改变值［WHERE 条件表达式］update student_score set 姓名='张小楠' where 数学=89。
用户数据库表设计
用户数据库表设计全文共四篇示例，供读者参考第一篇示例：用户数据库表设计是数据库设计中的一个关键部分，它负责存储和管理用户的信息，包括用户的基本信息、登录信息、权限信息等。
一个良好的用户数据库表设计能够有效地支持系统的用户管理功能，提升系统的安全性和性能。
在设计用户数据库表时，需要考虑以下几个方面：1. 用户基本信息表：这是用户数据库表的核心部分，包括用户的基本信息，如用户名、密码、邮箱、电话号码等。
在设计用户基本信息表时，需要确保数据的准确性和安全性，可以使用加密技术对用户密码进行加密存储，保护用户的隐私信息。
2. 用户权限表：用户权限表用于存储用户的权限信息，包括用户的角色、权限等。
通过用户权限表，系统可以方便地对用户的权限进行管理，设置不同用户的权限级别，确保系统的安全性和稳定性。
3. 用户登录日志表：用户登录日志表用于记录用户的登录信息，包括用户的登录时间、登录IP地址等。
通过用户登录日志表，系统可以追踪用户的登录行为，及时发现异常登录行为，保护系统的安全性。
5. 用户关联表：用户关联表用于建立用户与其他数据表之间的关联关系，如用户与角色之间的关联关系。
通过用户关联表，系统可以方便地查询用户的相关信息，确保系统的数据一致性和完整性。
在设计用户数据库表时，需要遵循一些设计原则，如数据规范化、数据安全性、数据一致性等。
需要根据实际业务需求和系统性能要求，灵活地设计用户数据库表结构，确保系统的高效性和可扩展性。
第二篇示例：用户数据库表设计是在一个系统中管理用户信息的重要部分。
一个用户数据库表设计需要考虑到用户的基本信息、安全性需求、权限管理和数据一致性等方面。
在一个系统中，用户数据库表设计的合理性将直接影响到用户信息的管理和系统的运行效率。
在进行用户数据库表设计时，首先需要确定用户表的基本结构，包括用户ID、用户名、密码、邮件地址、电话号码等基本信息。
这些信息将用于用户的身份认证和基本信息管理。
数据库表设计的注意事项与规范
数据库表设计的注意事项与规范在进行数据库表设计时，注意事项与规范起着关键的作用。
一个合理的数据库表设计可以提高数据库的性能，减少数据冗余以及确保数据的完整性和一致性。
下面是数据库表设计的一些注意事项与规范，帮助您设计出高效、可靠的数据库表。
1. 选择合适的数据类型：在设计表时，选择合适的数据类型是非常重要的。
不仅要满足数据的实际需求，还要考虑数据存储的效率和性能。
对于字符型数据，使用合适的长度，并使用字符集和校对规则。
对于数字型数据，选择合适的整数或小数类型。
2. 设计主键和唯一键：每个表都需要一个主键来唯一标识每一行数据。
设计主键时，可以选择自增主键，也可以选择主键由业务逻辑生成。
此外，对于需要保证数据唯一性的列，也可以设计唯一键来加强数据完整性。
3. 设置外键关联：在多个表之间建立关联是数据库设计的重要方面。
使用外键可以确保数据的一致性和完整性。
在设计外键时，需要考虑引用完整性，避免删除或修改被引用表中的数据时产生冲突。
4. 避免数据冗余：数据冗余会影响数据库的性能和占用存储空间。
在设计表结构时，要尽量避免数据冗余。
可以通过合理拆分数据表、使用关联查询等方式减少冗余数据，并通过索引优化查询性能。
5. 正确使用索引：索引可以加快数据库的查询速度，但过多或错误的使用索引也会影响性能。
在设计表时，需要根据查询需求选择合适的索引字段。
常用的索引类型包括主键索引、唯一索引和普通索引等。
6. 规范字段命名：在设计数据库表时，需要规范字段命名，以方便理解和维护。
字段名应该具有描述性，并且尽量避免使用缩写和特殊字符。
此外，字段名不应该与数据库关键字冲突。
7. 设计适当的表关系：在建立表之间的关系时，需要设计适当的表关系来满足业务需求。
常用的表关系包括一对一、一对多和多对多关系。
根据业务需求，选择合适的关系类型，并使用外键建立关系。
8. 设计复合索引：当多个字段联合查询时，可以考虑设计复合索引。
复合索引可以提高联合查询的性能，减少扫描数据的次数。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
关系型数据库理论可能是20世纪60年代和70年代存储系统先锋的救星，但是从那是开始它就成了许多数据开发人员的毒药，就是因为现代数据库系统发展得如此之好，以至于它将其关系型支柱对开发人员隐藏了。
设计良好的关系型数据库很容易使用、很灵活，并且能够保护数据的有效性。
而设计不良的数据相反仍然能够发挥相当的作用，但是最终可能会导致数据的无效、错误或者丢失。
开发人员有一些专用的规则，叫做范式（normal forms），他们根据这些规则来创建设计良好的数据库。
在这里，我将通过创建一个用于保存书籍信息的简单数据库来探讨一下范式。
确定实体和元素设计数据库的第一步是做你的家庭作业并确定你所需要的实体。
实体是数据一种类型的概念集。
通常只从一两个实体开始，再随着你数据的规范化而增加列表。
对于我们的示例数据库，它看上去就好像我们只需要一个实体——书。
在确定了所需要实体的清单之后，你下一步就需要为每个实体创建数据元素（也就是说，你需要保存的信息）的清单。
收集这样的信息有多种途径，但是最有效的可能就是依赖你的用户了。
向你的用户询问他们日常工作的情况，要求查看当前完成他们工作所需要的各种表格和报告。
例如，订单上可能会列出你创建销售应用程序所需要的许多数据元素。
我们的书籍实体没有书面表格和报告可用，但是下列元素清单将有助于我们开始设计这个数据库：{Title, Author, ISBN, Price, Publisher, Category}很重要的一点是，要注意，把我们这里要用的实体移动到元素的过程并不能适用于所有状况。
你所需要的实体不会总是像我们书籍示例那样清楚，所以你可能要从数据元素的一长串清单开始，在后面你会根据实体来划分元素。
正规化的头几步一旦有了实体清单（表格）和数据元素（字段），你就准备好让关系型数据库理论运作了。
这个理论的主要推动力是规范化——删除任何重复的组和冗余的数据，并把它们放到两个或者更多相关表里的过程。
你并不是一定需要拥有一个以上的表格，但是你的数据简单到只需要一个表格的机会并不多。
你应该小心地检查数据（这些数据会出现在多条记录里）和依赖性错误的实体和元素清单，并把已损坏的字段移动到不同的表格里。
例如，你可能列出同一个作者的多本书，并在数据库里重复了作者的名字。
当你认为会一次又一次地看到相同的数据值时，你就应该考虑把这个字段移动到另一个表格里了。
要记住，在这一点上，你只是在操作潜在表格的列表，而不应该真正地创建这个表格：现在还是要用笔和纸来列表。
范式简介数据库规范化的过程非常著名，所以有正式的规则来保证规范化数据库的建设。
这些规则有七条，叫做范式，而在大多数情况下头四条就够用了：第一范式（1NF）——这条规则有几个要求，包括：无多值项目（multivalued item）和重复组（repeating group）；每个字段都是原子型的（atomic），也就是说每个字段必须包含可能的最小数据元素；以及表格含有关键字（key）。
第二范式（2NF）——表格必须按照1NF来规范化。
所有的字段必须引用（或者描述）主键值。
如果主键基于一个以上的字段，那么每个nonkey字段必须取决于复杂键（complex key），而不仅仅是一个没有键的字段。
不支持主键的nonkey字段应该被移动到另一个表格里去。
第三范式（3NF）——表格必须符合1NF和2NF的要求。
所有的字段都必须相互独立。
任何描述nonkey字段的字段都必须被移动到另一个表格里。
Boyce-Codd范式（BCNF）——一定不能存在依赖于nonkey的字段。
这条规则实际上是3NF的一个子规则，用于捕捉可能会通过进程的依赖性。
这一点相当的抽象，一开始是很难应用的。
以上的规则很精确，但是技术定义以及规范化的规则能够被简化成下面几点：每个字段必须尽量小。
每个字段只能包含一个数据项目。
每条记录都必须是唯一的。
注意重复的条目。
每个字段都必须完全支持主键，而且只支持主键。
下一步该做什么？应用这些规范化规则，尤其是1NF的几个要求，将会是个很需要技巧的过程。
正如你会在下面内容里看到的，我会开始真正地把范式应用到实力数据库上，在进行了其他规范化的步骤之后，你就会重新回到1NF。
关系型数据库的理论最早可以追溯到E. F. Codd博士1970年的论文《大型共享数据库的数据关系模型》，在这篇文章里，他总结出了七条抽象的规则，叫做范式（normal form），用来帮助创建设计良好的数据库。
这七条规则的前四条——第一范式（First Normal Form，1NF）、第二范式（2NF）、第三范式（3NF）和Boyce-Codd范式（BCNF）——在大多数情况下已经够用了。
这些范式是非常抽象的，以至于有些开发人员在如何应用它们上存在问题。
也许理解范式最好的方式是开始将它们应用于数据，因为规则在你确实有数据要划分的时候才更有作用。
在本文中，我会对一个书目示例数据库应用1NF的规则，这些规则在一开始应用的时候是最复杂的。
你会回忆起，1NF的要求是：多值字段（multivalued field）必须要被移动到另一个表格里。
每个字段必须是原子型的（atomic），或者说要尽量地小。
每个字段都必须有一个关键字（key）.重复的值必须要被移动到另一个表格里。
我将要使用的简单表格是用来保存一些书目信息的。
到目前为止，这个Books表格有下面这些字段：{Title, Author, ISBN, Price, Publisher, Category}将多值字段移动到另一个表格应用1NF的第一步是确保表格没有包含多值字段，从定义可知它能够保存一个以上可能的条目。
我们最开始的清单有两个可能会违反这一规则的地方：Author（作者）和Category（分类）。
许多书都有多个作者，所以Author字段就会出问题。
类似的，一本书可以被归入多个类别。
例如《金银岛（Treasure Island）》可以被归为儿童读物、冒险类、经典类，以及其他类等等。
更正这个问题的唯一方法是把这些违反规则的字段转移到另一个表格里。
你可能会发现字段在另一个已存在表格里工作得会更好，但是这样的情况非常少见。
在大多数情况下，你需要为你所移动的每个字段都创建新的表格。
为了满足1NF的要求，我为Author和Category这两个字段创建了两个新的表格，其他的字段都留在Books表格里没有动：{Title, ISBN, Price, Publisher}每个字段都必须是原子型的1NF的下一项要求是说，每个字段都必须是原子型的，这就表示每个字段必须保存可能会有的最小数据元素。
这条规则有助于搜索和排序。
Author字段在这里再一次出现了问题，因为一个名字可以被分成多条信息。
我们需要一个字段用于姓，另一个字段用于名，这会让搜索作者姓名变得容易得多。
在这一点上，我会更进一步把Authors表格分成至少两个字段：FirstName（名）LastName（姓），那么我数据库的布局就是下面这样的：Books: {Title, ISBN, Price, Publisher}Authors: {FirstName, LastName}Categories: {Category}每个字段都必须有一个关键字搜索有重复记录（duplicate record）的表格是很难的；事实上，关系模型不允许表格包含有重复记录。
所以，一个表格里字段或者列的值必须是唯一的。
唯一性可以通过检查key（关键字）来确定，关键字可以由一个单列或者列的组合构成，这样的列叫做composite key（复合关键字）。
关键字有很多不同的类型：超关键字（Super key）：唯一辨别表格里记录的一个列或者一组列。
备选关键字（Candidate key）：包含有确定唯一性所需要的最少列的超关键字。
主关键字（Primary key）：用来唯一辨别表格里记录的备选关键字。
备用关键字（Alternate key）：没有被选为主关键字的备选键。
外来关键字（Foreign key）：表格内匹配同一表格或者另一表格里备选关键字的一个列或者一组列。
外来键允许你将一个表格里的记录和另一个表格里的数据相关联。
这里列出来的关键字的类型并不是相互排斥的；一个关键字可以同时被归入多个类。
从定义上说，每个表格必须至少有一个主关键字。
要确定我们示例表格的主关键字，就让我们从找到超关键字开始。
Authors和Categories表格的超关键字很容易找到，因为它们的字段非常少，但是Books表格的会稍稍困难一点。
尽管两本书有同一个名字的机会几乎没有，但是这不是不可能的，所以我不能把Title（书名）作为Books表格的关键字。
两本书来自同一个出版社具有同一个名字或者具有同一个ISBN的机会应该更小，所以我可以从这些可能性中创建一些超关键字。
表A列出了这三个表格的所有超关键字：表A示例数据库的超关键字Books表格事实上有更多的超关键字，例如Title、ISBN和Publisher，但是要包含所有这些关键字就又太多了。
找到备选关键字现在是缩短超关键字列表来找到备选关键字的时候了，这些备选关键字包含有一个字段里满足唯一性所需的最少列。
Categories表格在这一点上不存在问题，因为它只有一个字段。
Authors表格只有一个超关键字，所以很明显它就是备选关键字。
但是，Books表格有点麻烦，但是在最终的分析里，ISBN字段是备选关键字的最好选择。
ISBN字段应该是唯一的，但是由于这些数字是由出版商来指定的，所以还是可能出现使用同一ISBN的两本书。
实际情况是，只使用ISBN可能永远也不会碰到问题，但是一旦出现这样的小错误，你的整个数据库可能都会崩溃。
因此，我决定把Title和ISBN这两个复合超关键字作为Books表格的备选关键字。
确定主关键字主关键字只不过是你最后用来唯一辨别表格里每条记录的备选关键字。
在做完这些事之后，为每个表格分配主关键字就很容易了。
现在我为每个示例数据库定义了下列表格（星号表示主关键字字段）：Books: {*Title, *ISBN, Price, Publisher}Authors: {*FirstName, *LastName}Categories: {*Category, Description}要注意，Categories包含有一个新的字段——Description。
单字段的表格是可以接受的，但是加入了描述文本的字段将有助于更加完全地解释每个分类。
将计数字段（counter field）作为主关键字大多数关系型数据库管理系统（RDBMS）都会提供一类计数或者自动编号的数据类型，它会为每条记录分配一个连续的数值。
尽管这些计数字段会保证你得到一个备选关键字，但是这个关键字对于搜索是毫无疑义的。