数据库技术 课件 项目3　数据库设计

数据库技术3.1数据库设计概述3.1数据库设计概述

数据库设计是信息系统开发过程中不可或缺的环节，其目标是构建一个高效、稳定且易维护的数据库结构，以满足业务需求并支持未来扩展。优秀的数据库设计不仅能提升系统性能，还能降低维护成本，减少数据错误及冗余。数据库设计的目的与重要性3.1.13.1.1数据库设计的目的与重要性1.数据库设计的目的

满足业务需求：数据库设计的首要目的是根据业务需求定义数据存储和处理方式，确保数据库能够支持核心业务功能。

优化存储和性能：通过科学的设计减少数据冗余、提升数据存储效率，并确保高效的数据读取和写入性能。

支持数据完整性和一致性：通过设计合理的表结构和约束规则，确保数据之间的关联性、完整性和一致性。

提升系统可扩展性：为应对未来的业务扩展或需求变化，设计时需考虑数据库的灵活性和扩展性。3.1.1数据库设计的目的与重要性2.数据库设计的重要性

影响系统性能：不合理的设计可能导致数据查询和操作效率低下，严重影响系统的整体性能。

保障数据安全：科学的设计能通过权限控制和数据隔离等方式减少安全风险，保护用户隐私。

减少维护成本：良好的设计能降低系统的复杂性，方便后期维护、数据迁移及功能扩展，节约时间和成本。

避免数据冗余与冲突：通过规范化理论和合理的结构设计，避免数据重复存储和可能的冲突问题。

支持科学决策：数据库是数据分析和决策的基础，合理的设计能提供准确、全面的决策支持数据。3.1.1数据库设计的目的与重要性

通过本节内容的学习，大家将认识到数据库设计在整个系统开发中的核心地位，并理解合理设计对于系统高效运行和长期发展的重要意义，为后续深入学习数据库设计流程和技术奠定基础。数据库设计的基本流程3.1.23.1.2数据库设计的基本流程数据库设计是信息系统开发中至关重要的一环，其流程体现了系统性和科学性。以下为数据库设计的主要步骤及其具体内容：3.1.2数据库设计的基本流程1.需求分析目标：深入理解用户的业务需求，明确系统的数据存储和管理目标。具体内容：

收集业务信息：通过访谈、问卷和观察，获取用户对数据的需求描述。

确定数据范围：分析用户业务中的数据对象及其功能需求。

输出成果：需求说明书，包含数据项列表、关系描述及操作要求。3.1.2数据库设计的基本流程2.概念模型设计目标：从业务需求出发，构建清晰的概念模型，准确描述数据与业务的关系。具体内容：

使用实体-关系模型（E-R模型）抽象描述数据结构，包括实体、属性和实体间的关系。

绘制E-R图，直观反映系统中的数据流和逻辑结构。

输出成果：概念模型图，作为后续逻辑设计的基础。3.1.2数据库设计的基本流程3.逻辑模型设计目标：将概念模型转化为关系模型，使其符合具体数据库管理系统（DBMS）的逻辑规范。具体内容：

将实体及其关系转换为关系表的形式。

应用规范化理论对关系模型进行优化，减少冗余数据并确保数据一致性。

输出成果：逻辑模型，包括关系表定义、字段设计和约束说明。3.1.2数据库设计的基本流程4.物理模型设计目标：在具体数据库管理系统的框架下，设计物理结构以优化性能和存储效率。具体内容：

根据实际需求选择存储引擎和文件组织方式。

设计索引方案，确定字段的存储类型和长度。

输出成果：物理模型，包括数据库存储细节和优化方案。3.1.2数据库设计的基本流程5数据库实施与测试目标：在数据库管理系统中实现物理设计，并验证其准确性和稳定性。具体内容：

按照设计方案创建数据库对象（如表、索引、视图等）。

通过插入测试数据验证数据完整性和业务逻辑正确性。

输出成果：实现的数据库系统及测试报告。3.1.2数据库设计的基本流程6.数据库维护与优化目标：确保数据库系统在运行过程中的高效性和可靠性，并适应业务变化需求。具体内容：

定期备份数据并检查系统运行状态。

监控性能指标，优化查询语句和索引结构。

根据新增需求调整数据库设计。

输出成果：更新的数据库系统及维护文档。3.1.2数据库设计的基本流程数据库设计流程图如图3.1所示为数据库设计流程的图示，直观体现各阶段之间的逻辑关系：图3.1数据库设计流程图通过以上流程，数据库设计能够逐步从用户需求转化为高效、可靠的数据库系统。本节提供了理论框架，后续将结合实例深入探讨各阶段的实际应用方法。谢谢数据库技术3.2需求分析3.2需求分析

需求分析是数据库设计过程中的核心步骤，其主要目标是明确数据库需要支持的业务场景、操作功能和性能要求。通过有效的需求分析，可以为后续的概念模型设计、逻辑模型优化及数据库实现提供明确的方向和依据。需求分析是数据库设计的起点，贯穿整个设计与开发过程。准确、全面的需求分析能够为设计奠定坚实基础，同时帮助开发团队和客户之间达成一致，降低沟通成本与开发风险。

需求收集方法3.2.13.2.1需求收集方法

在数据库设计的初始阶段，需求收集是一个至关重要的步骤，其目的是全面了解系统的业务需求和数据需求，为后续的设计提供可靠依据。以下是几种常用的需求收集方法：3.2.1需求收集方法1.访谈法通过与系统的相关人员（如客户、业务负责人、实际用户等）进行面对面或远程的沟通，深入了解业务流程和需求。适用场景：业务流程复杂、需求不明确的情况下。关键点：

准备好问题清单，涵盖系统功能、性能和数据要求。

注意倾听并记录用户的真实需求，同时挖掘隐含需求。3.2.1需求收集方法2.问卷调查法设计标准化的问卷，通过发放问卷来收集用户需求和意见。适用场景：用户群体庞大且分布广泛。关键点：

问题设计要简单明了，避免歧义。

收集反馈后进行统计和分析，归纳出共性需求。3.2.1需求收集方法3.观察法通过观察用户的实际操作过程和业务流程，了解系统需要支持的功能和操作习惯。适用场景：需求不易通过语言描述的业务场景。关键点：

记录用户在实际操作中遇到的问题和需求。

关注业务的细节操作，挖掘潜在的改进空间。3.2.1需求收集方法4.文档分析法通过查阅和分析已有的业务文档、系统手册、流程图等资料，提取与系统设计相关的信息。适用场景：已有类似系统或业务有完善文档记录的场合。关键点：

重点关注文档中涉及的数据结构、操作流程和约束规则。

结合实际情况，分析文档中可能存在的过时或不完整的信息。3.2.1需求收集方法5.头脑风暴法通过组织团队成员、用户代表等开展讨论，集思广益，共同探索系统需求。适用场景：需求不明确或需创新功能设计的情况。关键点：

鼓励参与者充分表达意见，避免过早否定。

讨论结果需整理并进一步确认。3.2.1需求收集方法

不同的方法各有优缺点，应根据项目实际情况选择合适的需求收集方法，甚至综合运用多种方法。需求收集是一个动态过程，随着项目推进可能需要不断补充和修正，为后续的设计和开发奠定坚实的基础。

需求分析的伦理考量3.2.23.2.2需求分析的伦理考量

在数据库设计过程中，需求分析不仅是技术环节的重要一环，还需要重视其中的伦理考量。合理的伦理框架能够有效避免设计偏差，保障系统的公平性、可靠性和用户权益。以下是需求分析阶段需要关注的几项伦理问题：3.2.2需求分析的伦理考量信息透明与沟通是确保需求分析准确性的重要环节。在整个需求分析过程中，开发团队应与客户和用户保持紧密沟通，明确需求内容、技术限制和潜在风险。通过及时的交流，避免需求理解上的偏差，并让利益相关方对设计目标和预期成果有清晰的认知，从而减少可能的争议。2.信息透明与沟通公平性和无歧视是需求分析中不可忽视的问题。在面对不同用户群体的需求时，设计者应充分考虑功能实现的公平性，确保系统不会对某些群体产生歧视或偏见。同时，对于特殊用户（如需要无障碍服务的用户），应特别关注其需求，以实现系统功能的全面包容性。3.公平性和无歧视隐私保护是需求分析中的首要伦理考量。在收集用户需求时，可能涉及到个人信息或敏感数据。分析人员需要严格控制数据的收集范围，确保仅获取实现系统功能所需的必要信息。同时，必须事先取得用户的明确授权，并将数据的用途和处理方式告知相关方，以避免数据滥用或泄露，保障用户隐私权。1.隐私保护利益冲突的平衡在需求分析阶段也经常出现。面对多个利益相关方的不同需求，分析人员需要科学评估需求的优先级，尽量找到兼顾各方利益的解决方案。对于一些无法满足的需求，应与相关方充分沟通，合理解释原因，并记录在案，确保决策过程的公开透明。4.利益冲突的平衡5.长期责任与可持续性长期责任与可持续性是高质量需求分析的重要体现。设计者在定义需求时，应关注系统的长期影响，避免仅为满足短期目标而忽略了系统的维护性和扩展性。这不仅有助于降低后续的修改成本，还能使系统设计更具稳定性和适应性，为业务发展提供支持。伦理问题3.2.2需求分析的伦理考量

通过综合考虑这些伦理因素，需求分析可以在技术实现的基础上，兼顾用户权益和社会价值，为后续的数据库设计提供扎实的保障。需求分析不仅是技术过程，也是伦理问题的重要聚焦点。分析人员应以专业态度和高度的责任感对待需求，确保在技术实现的同时兼顾用户权益、社会价值和系统的公平性。通过科学严谨的需求分析和伦理考量，能够为后续的数据库设计奠定可靠的基础，同时推动技术与社会的和谐发展。谢谢数据库技术3.3概念模型设计3.3概念模型设计

概念模型设计是数据库设计的起点，是关键步骤，用于将现实世界中的数据需求抽象为数据模型，直观地表达数据及其之间的关系。通过概念模型设计，可以为后续的逻辑模型设计打下坚实的基础，确保数据库结构合理、功能完备且易于维护。概念模型能帮助开发人员和需求方达成一致，为后续设计提供明确的指引。实体-关系模型(E-R模型)3.3.13.3.1实体-关系模型(E-R模型)

实体-关系模型（Entity-RelationshipModel，简称E-R模型）是用于构建概念模型的一种方法。它通过对数据及其关系的直观表达，为数据库的逻辑设计提供基础。E-R模型使用图形化符号（E-R图）表示实体、属性和关系，便于开发人员与需求方对系统数据结构的理解和沟通。3.3.1实体-关系模型(E-R模型)（1）实体（Entity）

实体是数据库中需要管理的对象，代表现实世界中可以独立存在的物品或概念。它通常是系统的核心对象，包含一些特定的属性来描述其特征。例如，在一个图书管理系统中，读者、图书和借阅记录都可以作为实体。实体可具体指人、物品、事件等，可以区分为以下两类：

强实体（StrongEntity）：

独立存在且有独立标识的对象。例如，“用户”是一个强实体，可以通过用户ID唯一标识。

弱实体（WeakEntity）：

无法独立存在，必须依赖于强实体。例如，“订单明细”依赖于“订单”才能存在。弱实体通常通过外键和强实体关联，并使用组合主键来标识自身。3.3.1实体-关系模型(E-R模型)（2）属性（Attribute）

属性是用来描述实体或关系的特征的要素。例如“用户”的属性包括“用户名”、“密码”、“邮箱地址”等。根据属性的特性，可以分为以下几种类型，如表3.1所示。表3.1属性的类型3.3.1实体-关系模型(E-R模型)（3）关系（Relationship）

在实体-关系模型（E-R模型）中，关系是指不同实体之间的联系。关系描述了实体如何相互作用，体现了实体之间的业务逻辑和依赖性。每个关系通常会包含参与其中的实体以及与这些实体相关联的属性。关系是描述实体之间关联的结构，主要包括以下三种类型：1.一对一关系（1:1）定义：在一对一关系中，一个实体的每个实例只能与另一个实体的一个实例关联。示例：在一个公司管理系统中，每个员工有一个唯一的办公桌，并且每个办公桌只能分配给一个员工，这就是一对一关系。2.一对多关系（1:N）定义：在一对多关系中，一个实体的每个实例可以与多个实体实例关联，但反过来，每个多方实体只能与一个一方实体实例关联。示例：在学生与课程的关系中，每个学生可以选修多门课程，但每门课程只能由多个学生共同选修。这是典型的一对多关系。3.多对多关系（M:N）定义：在多对多关系中，一个实体的每个实例可以与另一个实体的多个实例关联，反之亦然。示例：在图书馆管理系统中，一本书（Book）可以被多个读者（Reader）借阅，同时每个读者也可以借阅多本书，这就是典型的多对多关系。3.3.1实体-关系模型(E-R模型)(4)键（Key）

在E-R模型中，键（Key）

是用于唯一标识实体或关系中每个实例的一个或多个属性。键的使用确保了实体实例在数据库中的唯一性，并且避免了数据冗余和不一致的情况。常见的键包括主键（PrimaryKey）、外键（ForeignKey）、候选键（CandidateKey）①主键（PrimaryKey,PK）：是一个实体或关系中的一个或多个属性，它唯一地标识实体中的每个实例。每个实体必须有一个主键，且主键值不能重复，也不能为NULL。主键的主要作用是确保每个实例可以唯一识别。在学生实体中，可以使用student_id作为主键来唯一标识每个学生，确保每个学生实例都是唯一的。②外键（ForeignKey,FK）：是指在一个实体中的属性，它引用了另一个实体的主键。外键通过建立实体之间的关系来确保数据的完整性，并且通过外键约束来管理实体间的关联。假设有一个“学生”实体（Student）和一个“课程”实体（Course）。为了表示学生选修课程的关系，可以在一个“选课”关系实体中定义外键student_id，它引用Student实体中的student_id，从而建立学生与课程之间的联系。③候选键（CandidateKey）：是一个实体中的一个或多个属性，它们可以唯一标识实体中的每一个实例。候选键类似于主键，但它们不是唯一的。每个实体可以有多个候选键，其中一个将被选为主键，其余的候选键则称为备用主键。在Student实体中，除了student_id可以作为主键外，email也可以唯一标识一个学生，因此email是一个候选键。虽然student_id被选为主键，但email也是唯一的，可以作为备用主键使用。3.3.1实体-关系模型(E-R模型)E-R模型是概念模型设计中的核心工具。通过定义实体、属性和关系，E-R模型直观展现了系统的数据结构和关联。借助E-R图，开发人员能清晰理解数据需求，为后续逻辑模型设计提供精准支持，同时降低设计过程中的沟通障碍。

概念模型的绘制与解读3.3.23.3.2概念模型的绘制与解读

概念模型是数据库设计的一个重要阶段，旨在通过抽象的方式描述系统中的实体、属性以及它们之间的关系。在此阶段，数据库设计师无需考虑具体的数据库实现细节，而是关注系统的业务逻辑和数据需求。概念模型的主要工具是实体-关系模型（E-R模型），它通过图形化表示实体、属性及其之间的关系，为后续的逻辑模型设计和实际数据库实现提供基础。常见的E-R图绘制符号如表3.2所示。表3.2E-R图的基本元素

在上表中，E-R图使用不同的符号来表示实体、属性和关系，从而为数据库结构的建立提供了直观的可视化框架。3.3.2概念模型的绘制与解读1.E-R图的基本元素（1）实体（Entity）：

实体是指现实世界中能够独立存在的事物，它通常用矩形来表示。在E-R图中，实体代表了数据库中的一个表（例如，学生、课程、员工等）。实体可以包含多个属性，描述其具体的特征。（2）属性（Attribute）：

属性是描述实体特征的变量，用椭圆形表示。属性可以分为简单属性、复合属性、派生属性等。在数据库中，属性通常对应于表中的字段。（3）关系（Relationship）：

关系描述了实体之间的联系，通常用菱形表示。关系可以是多对多（M:N）、一对多（1:N）或一对一（1:1）。关系帮助我们理解实体之间是如何交互的，并且能帮助在数据库中正确地建表。（4）键（Key）：

键是用于唯一标识实体的属性。主键（PrimaryKey）和外键（ForeignKey）是常见的键类型。主键用于唯一标识实体，而外键用于连接不同的实体。键的设计在数据库的完整性和查询效率方面起着至关重要的作用。3.3.2概念模型的绘制与解读2.E-R图绘制方法E-R图的绘制需要遵循一些基本规则和步骤，以确保图形能够清晰、准确地表达数据结构。以下是绘制E-R图的常见方法：（1）确定实体：根据系统需求文档或业务逻辑，识别出所有涉及的实体。每个实体代表一个系统中的独立对象或业务概念。（2）绘制实体和属性：使用矩形表示实体，并在矩形内注明实体名称。每个实体下方列出其属性，使用椭圆形表示，并通过直线与实体矩形连接。（3）识别实体间的关系：根据业务需求，确定实体之间的关系。例如，学生与课程之间的“选修”关系，客户与订单之间的“下单”关系。使用菱形表示关系，并用直线连接涉及的实体。（4）标识主键：每个实体应包含一个主键，主键是该实体的唯一标识。在E-R图中，用下划线表示主键。（5）设置基数约束在关系的两端注明基数约束，表示一个实体实例参与另一个实体关系的次数。例如，“一个学生可以选修多门课程，但每门课程可以由多个学生选修”是多对多的关系。（6）检查完整性与一致性：确保所有业务需求都被准确地映射到实体、属性和关系上，检查E-R图的完整性和一致性，避免遗漏或重复的设计。3.3.2概念模型的绘制与解读3.绘制E-R图的基本步骤（1）识别实体：

在需求分析阶段，首先识别出数据库中所涉及的实体。实体可以是具体的物体（例如学生、员工等），也可以是抽象的概念（例如课程、订单等）。每个实体都应有明确的定义和边界。（2）定义实体的属性：

每个实体都需要描述其特征的属性。在确定实体时，要同时确定其相关的属性，并标明这些属性属于哪个实体。（3）确定实体间的关系：

通过分析实体之间的联系，识别出它们之间的关系。根据关系的类型，可以是“一对多”、“多对多”或“一对一”。确保关系的连贯性和符合需求。（4）确定键和约束：

为每个实体定义主键，并根据实体之间的关系定义外键。同时，考虑数据库中的完整性约束，如非空约束、唯一性约束等。（5）绘制E-R图：

将实体、属性和关系用标准符号表示，并用连接线将它们连接起来，形成E-R图。3.3.2概念模型的绘制与解读4.E-R图设计实例任务1：绘制一对一关系E-R图在实际生活中，“居民”与“身份证”是一种典型的一对一关系。每个居民都有唯一的身份证，而每张身份证也只对应一个居民。下面，我们以“居民信息管理系统”为例，来分析并设计对应的E-R图。需求分析：在居民与身份证管理系统中，我们需要处理以下信息和需求：（1）每个居民都拥有一张身份证，身份证信息包括身份证号、签发日期、到期日期等。（2）每张身份证只能对应一个居民，居民信息包括姓名、性别、出生日期和地址等。（3）系统需要保存居民与身份证的对应关系，确保一一匹配。实体与关系识别：（1）实体：

居民（Resident）：描述居民的基本信息。

身份证（IDCard）：描述身份证的基本信息。（2）属性居民（Resident）：

居民编号（resident_id，主键）。

姓名（name）。

性别（gender）。

出生日期（birth_date）。

地址（address）。身份证（IDCard）：

身份证号（id_card_number，主键）。

签发日期（issue_date）。

到期日期（expiry_date）。（3）关系居民与身份证之间是一对一的关系，一个居民只能拥有一张身份证，一张身份证只能对应一个居民。3.3.2概念模型的绘制与解读E-R图绘制根据以上分析，绘制出居民信息管理系统E-R图，如图3.2所示：解读：1.居民实体：包含居民编号、姓名、性别、出生日期和地址等属性，用于描述居民的个人信息。2.身份证实体：包含身份证号、签发日期和到期日期等属性，用于描述身份证的相关信息。3.关系：拥有，表示居民与身份证之间的一对一关系。每个居民编号都唯一对应一张身份证，保证了一一匹配的关系约束。图3.2居民信息管理系统E-R图3.3.2概念模型的绘制与解读4.E-R图设计实例任务2：绘制一对多关系E-R图“班级”与“学生”是一种典型的一对多关系。一个班级包含多个学生，而每个学生只能属于一个班级。下面，我们以“班级管理系统”为例，分析并设计对应的E-R图。需求分析：在班级管理系统中，我们需要处理以下信息和需求：1.班级信息：记录每个班级的基本信息，例如班级编号、班级名称和班主任。2.学生信息：记录每个学生的基本信息，例如学号、姓名、性别和出生日期。3.班级与学生关系：每个班级可以包含多个学生，但每个学生只能属于一个班级。实体与关系识别：（1）实体：

班级（Class）：描述班级的基本信息。

学生（Student）：描述学生的基本信息。（2）属性：班级（Class）：

班级编号（class_id，主键）。

班级名称（class_name）。

班主任（teacher）。学生（Student）：

学号（student_id，主键）。

姓名（name）。

性别（gender）。

出生日期（birth_date）。（3）关系：包含：班级与学生之间是一对多的关系，一个班级可以包含多个学生，但每个学生只能属于一个班级。3.3.2概念模型的绘制与解读E-R图绘制根据以上分析，绘制出班级管理系统E-R图，如图3.3所示：解读：1.班级实体：包含班级编号、班级名称和班主任等属性，用于描述班级的基本信息。2.学生实体：包含学号、姓名、性别和出生日期等属性，用于描述学生的个人信息。关系：包含：表示班级与学生之间的包含关系，即一个班级可以包含多个学生，而每个学生只能属于一个班级。图3.3班级管理系统E-R图3.3.2概念模型的绘制与解读4.E-R图设计实例任务3：绘制多对多关系E-R图“学生”与“课程”是一种典型的多对多关系。一个学生可以选修多门课程，而一门课程也可以被多个学生选修。下面，我们以“课程管理系统”为例，分析并设计对应的E-R图。需求分析：在课程管理系统中，我们需要处理以下信息和需求：（1）学生信息：记录每个学生的基本信息，例如学号、姓名和年级。（2）课程信息：记录每门课程的基本信息，例如课程编号、课程名称和学分。（3）选课关系：记录学生与课程之间的选修关系，包括选课时间和成绩。实体与关系识别：（1）实体：

学生（Student）：描述学生的基本信息。

课程（Course）：描述课程的基本信息。（2）属性：学生（Student）：

学号（student_id，主键）。

姓名（name）。

年级（grade）。课程（Course）：

课程编号（course_id，主键）。

课程名称（course_name）。

学分（credits）。（3）关系：选修：学生与课程之间是一种多对多的关系。一个学生可以选修多门课程，而一门课程可以被多个学生选修。关系属性：

选课时间（enrollment_date）。

成绩（grade）。3.3.2概念模型的绘制与解读E-R图绘制根据以上分析，绘制出课程管理系统E-R图，如图3.4所示：解读：1.学生实体：包含学号、姓名和年级等属性，用于描述学生的基本信息。2.课程实体：包含课程编号、课程名称和学分等属性，用于描述课程的基本信息。关系：选修：表示学生与课程之间的多对多关系。关系属性：选课时间：用于记录学生选修某门课程的时间。成绩：用于记录学生在该课程中的成绩。图3.4学生选课系统E-R图3.3.2概念模型的绘制与解读

概念模型是数据库设计的核心步骤，其通过直观的E-R图表达现实世界中的实体及其关系，帮助设计者与用户在早期阶段明确需求并达成共识。在绘制概念模型时，需要正确识别实体、属性和关系，并清晰地表达它们之间的联系和约束。通过合理使用矩形、椭圆和菱形等图形符号，结合一对一、一对多、多对多等实际场景设计E-R图，可以有效提升模型的可读性和准确性。在解读概念模型时，应关注实体的关键属性、关系的类型及其约束条件，以确保模型能够完整、准确地反映业务需求。谢谢数据库技术3.4逻辑模型设计3.4逻辑模型设计

逻辑模型设计是数据库设计的关键阶段，其目标是将概念模型转换为关系模型，为数据库的实际实现提供清晰的结构和规范。逻辑模型的设计不仅需要映射实体和关系，还需要充分考虑数据完整性约束和存储效率，为后续物理实现奠定基础。转换为关系模型3.4.13.4.1转换为关系模型

将概念模型（E-R图）转换为关系模型是数据库设计中将抽象设计具体化的重要步骤。关系模型由一组二维表（关系）组成，每个表描述某类实体或关系的属性和结构。以下将详细介绍将概念模型转换为关系模型的具体方法和步骤。3.4.1转换为关系模型1.将实体转换为关系在E-R图中，每个实体都会映射为关系模型中的一个表（关系）。实体的属性成为关系中的列，实体的主键直接映射为关系的主键。规则：

每个实体类型对应一个关系。

实体的普通属性直接转化为关系的列。

实体的主键在关系中保留，作为唯一标识。【例3-1】：假设“学生”实体具有以下属性：学号（主键）、姓名、性别、出生日期，转换为关系模型后，生成的表为：学生(学号,姓名,性别,出生日期)。其中，学号是关系的主键。3.4.1转换为关系模型2.将一对一关系转换为关系一对一关系通常表示两类实体之间的唯一映射，转换为关系时有以下两种方式：

合并方式：将两个实体的属性和主键合并为一个关系。

外键方式：在其中一方增加一个外键，指向另一方的主键。【例3-2】：假设“学生”和“学生档案”实体之间是一对一关系，学生档案包含身高和体重等信息。合并方式：学生(学号,姓名,性别,出生日期,身高,体重)外键方式：学生(学号,姓名,性别,出生日期)学生档案(档案号,学号（外键）,身高,体重)其中，学生档案的“学号”是外键，指向学生的主键。3.4.1转换为关系模型3.将一对多关系转换为关系一对多关系常见于层级结构中，比如一个班级有多个学生。转换时，需要在“多”的一方增加外键，指向“一”的一方的主键。规则：“多”的一方增加外键，外键值为“一”的一方的主键。【例3-3】：“班级”和“学生”之间是一对多关系：班级具有以下属性：班级号、班级名称。学生具有以下属性：学号、姓名、性别、班级号（外键）。转换为关系模型后，生成的表为：班级(班级号,班级名称)学生(学号,姓名,性别,班级号)其中，“班级号”是学生表的外键，指向班级表的主键。3.4.1转换为关系模型4.将多对多关系转换为关系多对多关系需要通过一个中间表（关系）来表示，该表存储两个实体的主键，并可以包含关系的其他属性。规则：

创建一个中间表，该表包含两方实体的主键，并联合作为中间表的主键。

如果关系具有属性，关系的属性也作为中间表的列。【例3-3】：“学生”和“课程”之间是多对多关系：

学生具有以下属性：学号（主键）、姓名、性别。

课程具有以下属性：课程号（主键）、课程名称。

学生选修课程的关系具有以下属性：成绩。转换为关系模型后，生成的表为：学生(学号,姓名,性别)课程(课程号,课程名称)学生课程(学号,课程号,成绩)其中，“学号”和“课程号”是学生课程表的联合主键。3.4.1转换为关系模型5.处理多值属性和复合属性多值属性：将多值属性分离到单独的表中，主表通过外键与分离表关联。复合属性：将复合属性分解为多个简单属性。【例3-4】：假设“员工”实体的多值属性为电话号码：员工(员工号,姓名,部门)电话号码(员工号,电话)其中，“员工号”是电话号码表的外键，指向员工表的主键。3.4.1转换为关系模型

将概念模型转换为关系模型需要遵循清晰的映射规则，确保实体、关系、以及属性的准确表示。同时，合理设置主键和外键，定义完整性约束，为后续数据库的物理实现和操作提供坚实的基础。

规范化理论3.4.23.4.2规范化理论

数据库规范化理论是关系数据库设计的重要理论基础，其主要目标是通过对关系模型的优化，减少数据冗余、消除数据异常，确保数据的一致性和完整性。规范化的过程通常表现为将关系分解为更小、更合理的表结构，同时保持数据的逻辑完整性。规范化理论以范式（NormalForm,NF）为核心，指导设计者逐步改进数据库结构。3.4.2规范化理论1、规范化的目标规范化的主要目标是改进数据库设计质量，具体体现在以下几个方面：（1）减少数据冗余：通过合理分解表结构，避免不必要的重复数据存储，从而节省存

储空间。（2）消除数据异常：

插入异常：因为缺少某些字段的信息，导致无法插入合法记录。

更新异常：某些数据需要更新多次，可能引发不一致。

删除异常：删除某些数据时可能同时丢失有用信息。（3）提高数据一致性：通过设计更规范的表结构，确保数据库中同一信息只有一个来

源，减少数据不一致的可能性。3.4.2规范化理论2、主要范式及其要求（1）第一范式（1NF）第一范式是关系模型的基本要求，表示关系中每一列的值必须是原子值，即不可再分的最小单位。要求：每列只能存储单一值，不允许出现集合、数组或嵌套记录。【例3-5】：第一范式（1NF）转换未满足1NF的关系：课程(课程号,学生名单)其中“学生名单”可能包含多个学生的名字，违反原子性。转换后满足1NF：课程(课程号,学生姓名)3.4.2规范化理论2、主要范式及其要求（2）第二范式（2NF）第二范式要求在满足1NF的基础上，关系中的非主属性必须完全依赖于主键。问题：如果非主属性依赖于主键的一部分，会导致数据冗余。要求：消除部分函数依赖。【例3-6】：第二范式（2NF）转换未满足2NF的关系：成绩(学生号,课程号,学生姓名,分数)其中“学生姓名”仅依赖于“学生号”，与“课程号”无关，导致冗余。转换后满足2NF：学生(学生号,学生姓名)成绩(学生号,课程号,分数)3.4.2规范化理论2、主要范式及其要求（3）第三范式（3NF）第三范式在满足2NF的基础上，要求消除非主属性之间的传递依赖。问题：非主属性通过其他非主属性间接依赖主键，可能导致冗余。要求：消除传递函数依赖。【例3-7】：第三范式（3NF）转换未满足3NF的关系：学生(学生号,班级号,班级名称)其中“班级名称”依赖于“班级号”，“班级号”依赖于主键“学生号”。转换后满足3NF：学生(学生号,班级号)班级(班级号,班级名称)3.4.2规范化理论2、主要范式及其要求（4）BC范式（BCNF）BC范式是第三范式的加强形式，要求每个决定因素都必须是候选键。问题：即使满足3NF，仍可能存在主属性依赖于非主属性的情况。要求：消除候选键的部分依赖。【例3-8】：BC范式（BCNF）转换未满足BCNF的关系：教师(教师号,课程号,课程名称)其中“课程名称”仅依赖于“课程号”，而“课程号”不一定是候选键。转换后满足BCNF：教师(教师号,课程号)课程(课程号,课程名称)3.4.2规范化理论3、规范化的实际应用与权衡在实际应用中，规范化过程虽然能显著提高数据库的设计质量，但也可能引发以下问题：

查询性能下降：规范化后的表通常需要多表连接查询，可能降低执行效率。

设计复杂性增加：在复杂系统中，过度规范化可能使设计、实现和维护变得困难。

因此，实际设计中需要结合应用场景，在规范化和性能之间找到合理的平衡。例如，对于OLTP（在线事务处理系统）系统，比如银行的转账、超市的收银、购物网站的订单处理等，数据操作频繁，主要以增、删、改为主，对数据一致性和实时性要求高，数据一致性和规范化更为重要；而对于OLAP（在线分析处理系统）系统，主要用于分析历史数据，为决策提供支持，比如销售趋势分析、客户行为预测等，数据操作以读取为主，很少修改，可能更倾向于适当反规范化以提高查询性能。

规范化理论提供了一套系统的方法，用于优化数据库设计。通过合理应用规范化原则，设计者可以构建高效、健壮且便于维护的数据库结构。但在实践中，需根据实际需求灵活选择范式级别，以在性能和规范性之间实现平衡。谢谢数据库技术3.5数据库设计的职业责任3.5数据库设计的职业责任

在数据库设计过程中，设计者不仅需要具备专业技能，还需要有高度的职业责任感。数据库的合理设计直接影响系统的安全性、可靠性和数据的有效利用。同时，设计者也需要在伦理方面做出充分考虑，以保障数据使用的合法性和道德性。设计评审与伦理3.5.13.5.1设计评审与伦理

在数据库设计中，设计评审是保障数据库结构合理性、功能完整性和安全性的关键环节，同时也是确保设计方案符合伦理规范的重要步骤。通过系统化的评审，可以有效发现并解决潜在问题，从而提高数据库的质量与可靠性。3.5.1设计评审与伦理2.符合法律合规性设计评审应确保数据库的功能与数据用途符合法律法规的要求，避免超范围收集数据或非法使用数据。例如，不应在用户不知情的情况下将其数据用于商业用途。例如：在一个电子商务系统中，只允许存储用户为交易提供的必要信息，如地址和支付信息，不得擅自采集额外数据。4.数据生命周期管理数据库设计应明确数据的存储时间、更新频率以及过期数据的处理方式，避免不必要的长期数据积累。数据生命周期管理不仅可以提升系统性能，还能减少隐私泄露的风险。例如：在客户关系管理系统中，用户的交互记录可以在超出保留期限后自动删除，以符合数据最小化原则。6.引入伦理审查机制在设计评审中，加入伦理审查流程，可以从数据隐私、使用合法性和社会影响等多个维度进行评估，发现潜在的伦理问题并提出改进方案。这种机制有助于提升设计的社会责任感。数据库设计的评审不仅是技术层面的优化，更是对社会责任的体现。通过严谨的设计评审与伦理规范的引入，可以在实现数据库功能需求的同时，保障用户权益，构建更加安全、可信赖的数据管理系统。5.数据共享的透明性评审需关注数据共享的合法性和透明性，确保用户对其数据共享有充分的知情权与选择权。例如，用户需要明确了解其数据将与哪些第三方共享，并能够选择拒绝共享。例如：在设计社交网络平台时，用户需明确看到隐私设置选项，并能够自主控制个人数据的可见范围。3.避免设计中的偏见数据库结构和字段设计需避免对特定群体产生歧视或偏见。例如，字段设置应以业务需求为导向，不应要求用户填写性别、种族、宗教等无关信息，以避免不必要的隐私侵犯或歧视。例如：在一个招聘系统中，求职者的基本信息表单不应要求填写与职位申请无关的种族或宗教信息。1.确保数据隐私与安全数据库设计评审需重点关注用户隐私保护和数据安全性。设计者需遵守相关法律法规，如《个人信息保护