超级会员免费看
数据库设计指南与实践
1. 规则建立与关键元素
1.1 规则建立步骤
在数据库设计中，规则的建立至关重要。以下是建立规则的步骤：
1. 通过修改适当的关系特征来确立规则。
2. 确定用于测试规则的操作。
3. 将规则记录在业务规则规范表中。
1.2 关键元素特性
候选键（Candidate Key）
- 不能是多部分字段。
- 必须包含唯一值。
- 不能包含空值。
- 其值不能违反组织的安全或隐私规则。
- 其值整体或部分都不是可选的。
- 由定义唯一性所需的最少字段组成。
- 其值必须唯一且排他地标识表中的每条记录。
- 其值必须排他地标识给定记录中每个字段的值。
- 其值仅在极少数或极端情况下可以修改。
外键（Foreign Key）
- 与复制自的主键名称相同。
- 使用复制自的主键的字段规范副本。
- 其值来自所引用的主键。
主键（Primary Key）
主键的特性与候选键基本相同，同时每个表必须有且仅有一个主键，并且数据库中的每个主键必须是唯一的，除非其中一个表是子集表。
理想字段（Ideal Field）
- 代表表主题的独特特征。
- 仅包含单个值。
- 不能分解为更小的组件。
- 不包含计算或连接的值。
- 在整个数据库结构中是唯一的。
- 当出现在多个表中时，保留其大部分特征。
理想表（Ideal Table）
- 代表单个主题，可以是对象或事件。
- 有主键。
- 不包含多部分或多值字段。
- 不包含计算字段。
- 不包含不必要的重复字段。
- 仅包含绝对最少的冗余数据。
1.3 完整性保障
字段级完整性（Field-Level Integrity）
字段级完整性确保以下几点：
- 字段的身份和用途清晰，并且明确标识其出现的所有表。
- 字段定义在整个数据库中保持一致。
- 字段的值一致且有效。
- 明确标识可以应用于字段值的修改、比较和操作类型。
关系级完整性（Relationship-Level Integrity）
关系级完整性确保：
- 关系中两个表（或关键字段）之间的连接可靠。
- 可以以有意义的方式向每个表中插入新记录。
- 可以删除现有记录而不产生任何不利影响。
- 关系中相互关联的记录数量有合理的限制。
表级完整性（Table-Level Integrity）
表级完整性确保：
- 表中没有重复记录。
- 主键唯一地标识表中的每条记录。
- 每个主键值都是唯一的。
- 主键值不为空。
1.4 规范撰写
字段描述撰写指南
- 使用准确识别字段并明确说明其用途的语句。
- 撰写清晰简洁的语句。
- 避免重述或改写字段名称。
- 避免使用技术术语、首字母缩写词或缩写。
- 不要包含特定于实现的信息。
- 不要使此描述依赖于另一个字段的描述。
- 不要使用示例。
表描述撰写指南
- 包含准确定义表的语句。
- 包含解释该表对组织为何重要的语句。
- 撰写清晰简洁的描述。
- 表描述中不要包含特定于实现的信息，例如表的使用方式或位置。
- 不要使一个表的描述依赖于另一个表的描述。
- 表描述中不要使用示例。
1.5 命名准则
字段名称创建准则
- 创建一个对整个组织有意义的唯一、描述性名称。
- 创建一个准确、清晰且明确标识字段所代表特征的名称。
- 使用传达字段所代表特征含义所需的最少单词数。
- 不要使用缩略词，并谨慎使用缩写。
- 不要使用可能混淆字段名称含义的单词。
- 不要使用隐式或显式标识多个特征的名称。
- 使用名称的单数形式。
表名称创建准则
- 创建一个对整个组织有意义的唯一、描述性名称。
- 创建一个准确、清晰且明确标识表主题的名称。
- 使用传达表主题所需的最少单词数。
- 不要使用传达物理特征的单词。
- 不要使用缩略词和缩写。
- 不要使用专有名称或其他会过度限制可输入到表中的数据的单词。
- 不要使用隐式或显式标识多个主题的名称。
- 使用名称的复数形式。
1.6 关系识别与视图需求确定
关系识别
确定表矩阵中一对表之间的官方关系的步骤如下：
1. 选择一对表，并记录第一个表和第二个表交界处的条目。
2. 在正在处理的矩阵同一侧找到第二个表，并记录它与另一侧第一个表交界处的条目。
3. 对两个条目应用适当的公式（如下所示），并确定表之间的官方关系：
- 1:1 + 1:1 = 1:1
- 1:N + 1:1 = 1:N
- 1:N + 1:N = M:N
4. 以适当的方式绘制关系图。
5. 划掉矩阵上的两个条目。
视图需求确定
确定组织视图需求的步骤如下：
- 与用户/管理层代表小组一起审查笔记。
- 审查在设计过程早期收集的数据输入、报告和演示示例。
- 检查表格及其代表的主题。
- 分析表关系。
- 研究业务规则。
1.7 面试指南
参与者指南
- 让参与者了解你的意图。
- 让参与者知道你感谢他们参与面试，并且他们对面试问题的回答对整个设计项目很有价值。
- 确保每个人都明白，如果发生争议，你是官方仲裁者。
面试官指南
- 在光线充足、远离干扰噪音的房间进行面试，配备大桌子和舒适的椅子，并准备咖啡和小吃。
- 每次面试设定不超过10人的限制。
- 分别为用户和管理层进行面试。
- 当需要面试多个小组时，为每个小组指定一名组长。
- 面试前准备好问题。
- 如果你不擅长做笔记，可以为每次面试分配一名可靠的记录员，或者征得小组同意使用录音机记录面试。
- 给予每个人平等且专注的关注。
- 保持面试节奏。
- 始终控制面试局面。
1.8 使命陈述与目标
使命陈述（Mission Statements）
一份写得好的使命陈述具有以下属性：
- 简洁明了地表达观点。
- 避免不必要的陈述或细节，定义明确。
- 避免明确描述特定任务的短语或句子。
- 对你（数据库开发人员）和你为之设计数据库的人有意义。
使命目标（Mission Objectives）
一份写得好的使命目标具有以下属性：
- 由一个明确定义一般任务且无不必要细节的陈述句组成。
- 用简洁、切中要点且明确的通用术语表达。
- 对你和你为之设计数据库的人有意义。
1.9 多值字段处理
解决多值字段的通用过程如下：
1. 从表中移除该字段，并将其作为新表的基础。如有必要，根据之前学习的字段命名准则重命名字段。
2. 从原始表中获取主键，并将其合并到新表结构中。该字段在新表中将执行两个特定功能：作为表的复合主键的一部分，并作为帮助建立新表与原始表之间关系的外键。
3. 为新表分配适当的名称、类型和描述，并将其添加到最终表列表中。
1.10 文档表单
提供了字段规范表、业务规则规范表和视图规范表的空白副本，可用于数据库项目。
字段规范表（FIELD SPECIFICATIONS）
| 项目 | 详情 |
|---|---|
| 字段名称 | 具体字段名 |
| 标签 | 字段标签 |
| 父表 | 所属父表 |
| 共享者 | 共享该字段的相关信息 |
| 别名 | 字段别名 |
| 描述 | 字段描述 |
| 规范类型 | 副本、唯一、通用等 |
| 源规范 | 相关源规范信息 |
| 长度 | 字段长度 |
| 小数位数 | 小数位数 |
| 输入掩码 | 输入格式掩码 |
| 显示格式 | 显示格式 |
| 数据类型 | 数据类型 |
| 字符支持 | 支持的字符类型，如字母、数字等 |
| 键结构 | 非、未确定等 |
| 编辑规则 | 编辑规则说明 |
| 空值支持 | 允许空值、现在输入可编辑等多种情况 |
| 唯一性 | 非唯一、唯一 |
| 必需值 | 是、否 |
| 比较允许 | 允许的比较操作，如 <、> 等 |
| 取值范围 | 字段取值范围 |
| 默认值 | 默认值 |
| 值输入者 | 用户、系统 |
| 操作允许 | 允许的操作，如加、减等 |
| 键类型 | 复合、简单 |
业务规则规范表（BUSINESS RULE SPECIFICATIONS）
| 项目 | 详情 |
|---|---|
| 字段名称 | 涉及的字段名 |
| 表名称 | 涉及的表名 |
| 陈述 | 规则陈述 |
| 约束 | 规则约束条件 |
| 测试操作 | 插入、删除、更新 |
| 类别 | 字段特定、关系特定 |
| 类型 | 数据库导向、应用导向 |
| 逻辑元素 | 键结构、编辑规则等相关逻辑元素 |
| 物理元素 | 长度、输入掩码等物理相关元素 |
| 规则信息 | 规则的详细信息 |
| 字段元素影响 | 受影响的字段元素 |
| 关系特征影响 | 受影响的关系特征 |
视图规范表（VIEW SPECIFICATIONS）
| 项目 | 详情 |
|---|---|
| 基表 | 基础表信息 |
| 一般信息 | 描述等一般信息 |
| 计算字段表达式 | 计算字段的表达式 |
| 过滤器 | 字段名、条件、表达式 |
| 名称 | 视图名称 |
| 类型 | 数据、验证、聚合等类型 |
1.11 数据库设计图表符号
用于绘制数据结构、关系、关系特征和键指定的符号如下：
-
表和视图结构
：数据表、子集表、验证表、链接表、视图。
-
关系类型
：一对一、一对多、多对。
-
删除规则
：级联（C）、拒绝（D）、置空（N）、限制（R）、设置默认值（S）。
-
参与类型
：强制参与、可选参与。
-
参与度
：指定相关记录的最小和最大数量。
-
键指定
：主键（PK）、复合候选键（CCK）、候选键（CK）、备用键（AK）、外键（FK）、复合外键（CFK）、复合备用键（CAK）、复合主键（CPK）。
1.12 示例设计
提供了多个示例设计，包括娱乐机构数据库、学校数据库、销售订单数据库、办公库存数据库、保龄球联盟数据库和汽车租赁数据库。以下以娱乐机构数据库为例：
graph LR
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
Customers(Customers<br>Customer ID(PK)):::process --> Engagements(Engagements<br>Engagement ID(PK)<br>Customer ID(FK)):::process
Agents(Agents<br>Agent ID(PK)):::process --> Engagements
Entertainers(Entertainers<br>Entertainer ID(PK)):::process --> Engagements
Entertainers --> EntertainerMembers(Entertainer Members<br>Entertainer ID(CPK/FK)<br>Member ID(CPK/FK)):::process
Members(Members<br>Member ID(PK)):::process --> EntertainerMembers
Customers --> MusicalPreferences(Musical Preferences<br>Customer ID(CPK/FK)<br>Style ID(CPK/FK)):::process
MusicalStyles(Musical Styles<br>Style ID(PK)):::process --> MusicalPreferences
Entertainers --> EntertainerStyles(Entertainer Styles<br>Customer ID(CPK/FK)<br>Style ID(CPK/FK)):::process
MusicalStyles --> EntertainerStyles
| 表名 | 字段 | 键类型 |
|---|---|---|
| Customers | Customer ID | PK |
| Agents | Agent ID | PK |
| Members | Member ID | PK |
| Entertainer Members | Entertainer ID, Member ID | CPK/FK |
| Musical Preferences | Customer ID, Style ID | CPK/FK |
| Musical Styles | Style ID | PK |
| Entertainers | Entertainer ID | PK |
| Entertainer Styles | Customer ID, Style ID | CPK/FK |
| Engagements | Engagement ID, Customer ID, Agent ID, Entertainer ID | PK, FK |
这些示例设计可作为创建数据库的参考，但需根据实际需求进行调整，确保表、字段、关系和视图符合设计指南。
2. 推荐阅读与术语解释
2.1 推荐阅读书目
若想深入研究数据库技术，以下书籍值得一读。这些书籍历经时间考验，已成为数据库行业和学术机构的标准读物：
- Codd, E. F. (1990).
The Relational Model for Database Management: Version 2
. Reading, MA: Addison - Wesley. 这本书较难找到，但对于想成为专业数据库开发者的人来说，值得收藏。
- Connolly, Thomas, and Carolyn Begg. (2002).
Database Systems—A Practical Approach to Design, Implementation, and Management, Third Edition
. Boston, MA: Addison - Wesley.
- Date, C. J. (2000).
An Introduction to Database Systems, Seventh Edition
. Boston, MA: Addison - Wesley.
- Date, C. J. (2000).
The Database Relational Model—A Retrospective Review and Analysis
. Boston, MA: Addison - Wesley.
- Date, C. J., and Hugh Darwen. (2000).
Foundation for Future Database Systems—The Third Manifesto, Second Edition
. Boston, MA: Addison - Wesley.
- Fleming, Candace C., and Barbara von Halle. (1989).
Handbook of Relational Database Design
. Reading, MA: Addison - Wesley.
- Hoffer, Jefferey A., Mary B. Prescott, and Fred R. McFadden. (2002).
Modern Database Management, Sixth Edition
. Upper Saddle River, NJ: Prentice Hall.
- Kroenke, David M. (2000).
Database Processing—Fundamentals, Design, & Design, Seventh Edition
. Upper Saddle River, NJ: Prentice Hall.
此外，还可访问相关网站查看更多关于数据库设计与理论、数据建模、GUI设计、SQL、Visual Basic和.NET等主题的书籍推荐。
2.2 术语解释
| 术语 | 解释 |
|---|---|
| 聚合函数（Aggregate Function） | 一段编程代码，对一组数据执行特定类型的数学聚合操作，并返回单个值。 |
| 聚合视图（Aggregate View） | 用于以特定方式聚合一组数据并显示结果信息的视图。 |
| 备用键（Alternate Key） | 未被指定为主键的候选键。 |
| 分析型数据库（Analytical Database） | 一种存储静态数据的数据库，用于跟踪趋势、查看长期统计数据或进行战术或战略业务预测，通常与OLAP相关。 |
| 应用程序（Application） | 商业或定制的软件程序，通常用于为数据库提供用户友好的界面。 |
| 应用程序开发（Application Development） | 设计和创建将作为数据库用户界面的应用程序的过程。 |
| 应用程序（Application Program） | 作为数据库用户界面的商业或定制软件。 |
| 面向应用的业务规则（Application Oriented Business Rule） | 一种规则，对数据库的物理设计或数据库应用程序的设计施加约束。 |
2.3 不同数据库示例设计分析
除了前面提到的娱乐机构数据库，其他示例数据库也各有特点。
学校数据库
graph LR
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
Staff(Staff<br>Staff ID(PK)):::process --> Faculty(Faculty<br>Staff ID(PK)):::process
Faculty --> FacultyCategories(Faculty Categories<br>Staff ID(CPK/FK)<br>Category ID(CPK/FK)):::process
Categories(Categories<br>Category ID(PK)):::process --> FacultyCategories
Faculty --> FacultyClasses(Faculty Classes<br>Class ID(CPK/FK)<br>Staff ID(CPK/FK)):::process
Classes(Classes<br>Class ID(PK)):::process --> FacultyClasses
Faculty --> FacultySubjects(Faculty Subjects<br>Staff ID(CPK/FK)<br>Subject ID(CPK/FK)):::process
Subjects(Subjects<br>Subject ID(PK)):::process --> FacultySubjects
Departments(Departments<br>Department ID(PK)):::process --> Classes
Classroomes(Classroomes<br>ClassRoom ID(PK)):::process --> Classes
Buildings(Buildings<br>Building Code(PK)):::process --> Classroomes
Students(Students<br>Student ID(PK)):::process --> StudentSchedules(Student Schedules<br>Class ID(CPK/FK)<br>Student ID(CPK/FK)):::process
Classes --> StudentSchedules
StudentClassStatus(Student Class Status<br>Class Status(PK)<br>Building Code(FK)):::process --> StudentSchedules
| 表名 | 字段 | 键类型 |
|---|---|---|
| Staff | Staff ID | PK |
| Faculty | Staff ID | PK |
| Faculty Categories | Staff ID, Category ID | CPK/FK |
| Faculty Classes | Class ID, Staff ID | CPK/FK |
| Faculty Subjects | Staff ID, Subject ID | CPK/FK |
| Subjects | Subject ID | PK |
| Departments | Department ID | PK |
| Classroomes | ClassRoom ID | PK |
| Buildings | Building Code | PK |
| Students | Student ID | PK |
| Student Class Status | Class Status, Building Code | PK, FK |
| Categories | Category ID | PK |
| Classes | Class ID, Subject ID, Classroom ID | PK, FK |
| Student Schedules | Class ID, Student ID, Class Status | CPK/FK, FK |
学校数据库涵盖了教职工、学生、课程、科目、部门等多个方面的信息，通过各种关联关系将这些信息整合在一起。例如，教职工与课程、科目之间的关联，学生与课程表的关联等，方便学校进行教学管理和学生信息管理。
销售订单数据库
graph LR
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
Customers(Customers<br>Customer ID(PK)):::process --> Orders(Orders<br>Order ID(PK)<br>Customer ID(FK)):::process
Employees(Employees<br>Employee ID(PK)):::process --> Orders
Orders --> OrderDetails(Order Details<br>Order ID(CPK/FK)<br>Product Number(CPK/FK)):::process
Products(Products<br>Product Number(PK)<br>Category ID(FK)):::process --> OrderDetails
Categories(Categories<br>Category ID(PK)):::process --> Products
Products --> ProductVendors(Product Vendors<br>Product Number(CPK/FK)<br>Vendor ID(CPK/FK)):::process
Vendors(Vendors<br>Vendor ID(PK)):::process --> ProductVendors
| 表名 | 字段 | 键类型 |
|---|---|---|
| Customers | Customer ID | PK |
| Employees | Employee ID | PK |
| Orders | Order ID, Customer ID, Employee ID | PK, FK |
| Products | Product Number, Category ID | PK, FK |
| Order Details | Order ID, Product Number | CPK/FK |
| Categories | Category ID | PK |
| Product Vendors | Product Number, Vendor ID | CPK/FK |
| Vendors | Vendor ID | PK |
销售订单数据库主要围绕客户、员工、订单、产品和供应商等信息构建。通过订单将客户、员工和产品联系起来，同时产品与供应商也有对应关系，便于企业进行销售管理和供应链管理。
办公库存数据库
graph LR
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
Items(Items<br>Item ID(PK)):::process --> Software(Software<br>Item ID(PK)):::process
Items --> OfficeFurniture(Office Furniture<br>Item ID(PK)):::process
Items --> OfficeEquipment(Office Equipment<br>Item ID(PK)):::process
Items --> ContainerItems(Container Items<br>Container ID(CPK/FK)<br>Item ID(CPK/FK)):::process
Containers(Containers<br>Container ID(PK)<br>Storage Location ID(FK)):::process --> ContainerItems
StorageLocations(Storage Locations<br>Storage Location ID(PK)):::process --> Containers
| 表名 | 字段 | 键类型 |
|---|---|---|
| Software | Item ID | PK |
| Office Furniture | Item ID | PK |
| Office Equipment | Item ID | PK |
| Items | Item ID | PK |
| Container Items | Container ID, Item ID | CPK/FK |
| Containers | Container ID, Storage Location ID | PK, FK |
| Storage Locations | Storage Location ID | PK |
办公库存数据库用于管理办公物品的库存信息。将不同类型的物品（软件、办公家具、办公设备）统一通过物品表进行管理，同时通过容器和存储位置来定位物品，方便库存盘点和管理。
保龄球联盟数据库
graph LR
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
Tournaments(Tournaments<br>Tournament ID(PK)):::process --> Matches(Matches<br>Match ID(PK)<br>Tournament ID(FK)):::process
Teams(Teams<br>Team ID(PK)):::process --> Matches
Bowlers(Bowlers<br>Bowler ID(PK)):::process --> TeamMembers(Team Members<br>Team ID(CPK/FK)<br>Bowler ID(CPK/FK)):::process
Teams --> TeamMembers
Matches --> BowlerScores(Bowler Scores<br>Match ID(CPK)<br>Game Number(CPK)<br>Bowler ID(CPK)):::process
Bowlers --> BowlerScores
| 表名 | 字段 | 键类型 |
|---|---|---|
| Matches | Match ID, Tournament ID, Odd - lane Team ID, Even - lane Team ID | PK, FK |
| Tournaments | Tournament ID | PK |
| Teams | Team ID | PK |
| Bowlers | Bowler ID | PK |
| Team Members | Team ID, Bowler ID | CPK/FK |
| Bowler Scores | Match ID, Game Number, Bowler ID | CPK |
保龄球联盟数据库用于管理保龄球比赛相关信息，包括比赛、锦标赛、球队、球员以及球员得分等。通过比赛和球队、球员之间的关联，能够清晰记录比赛过程和球员表现。
汽车租赁数据库
graph LR
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
Customers(Customers<br>Customer ID(PK)):::process --> Rentals(Rentals<br>Rental ID(PK)<br>Customer ID(FK)):::process
Employees(Employees<br>Employee ID(PK)<br>Supervisor ID(FK)):::process --> Rentals
Vehicles(Vehicles<br>License Number(PK)):::process --> Rentals
Locations(Locations<br>Location ID(PK)):::process --> Rentals
Vehicles --> MaintenanceWorkorders(Maintenance Workorders<br>Workorder Number(PK)<br>License Number(FK)<br>Maintenance Type ID(FK)):::process
MaintenanceTypes(Maintenance Types<br>Maintenance Type ID(PK)):::process --> MaintenanceWorkorders
| 表名 | 字段 | 键类型 |
|---|---|---|
| Customers | Customer ID | PK |
| Vehicles | License Number | PK |
| Employees | Employee ID, Supervisor ID | PK, FK |
| Locations | Location ID | PK |
| Maintenance Types | Maintenance Type ID | PK |
| Maintenance Workorders | Workorder Number, License Number, Maintenance Type ID | PK, FK |
| Rentals | Rental ID, Customer ID, Employee ID, Location ID, License Number | PK, FK |
汽车租赁数据库涉及客户、员工、车辆、租赁地点、维护类型和租赁订单等信息。通过租赁订单将各个元素联系起来，同时车辆的维护信息也单独记录，便于汽车租赁公司进行业务管理和车辆维护管理。
2.4 总结与实际应用建议
在实际的数据库设计中，需要根据具体的业务需求选择合适的设计方案。首先，要明确数据库的使命陈述和目标，确保设计方向符合业务要求。然后，按照规则建立的步骤，确立数据库的各种规则，包括字段规则、业务规则等。在设计表和字段时，要遵循理想表和理想字段的特性，保证数据库的规范性和高效性。
在处理关系时，要准确识别表与表之间的关系，确保关系级完整性。对于多值字段，按照相应的处理流程进行处理，避免数据冗余和不一致。同时，在设计过程中要注重文档的记录，使用提供的各种规范表来整理和保存设计信息。
参考示例设计时，不能直接照搬，要根据实际业务场景进行调整和优化。例如，如果是一个小型的销售企业，可能不需要像示例销售订单数据库那样复杂的结构，可以简化一些不必要的表和字段。总之，数据库设计是一个需要综合考虑各种因素的过程，只有不断实践和优化，才能设计出满足业务需求的高质量数据库。
扫一扫
1574
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
