在关系数据库设计中,设计关系模式是( )阶段的任务

数据库管理员的任务。

设计关系模式是数据库管理员的任务，它的目的是将数据存储在一个有效的方式，以便用户可以容易地访问和检索它们，关系模式定义了数据库中不同表之间的关系，并指定了每个表中包含的字段，以及字段之间的关系。

关系数据库是一种数据库，它将数据存储在不同的表中，使用关系来表示数据之间的关系，允许用户跨多个表查询数据。

数据库 data base 为满足某一部门中多个用户多种应用的需要，按照一定的数据模型在计算机系统中组织、存储和使用的互相联系的数据集合。 带有数据库的计算机系统，除具备一般的硬件、软件外，必须有用以存储大量数据的直接存取存储设备、管理并控制数据库的软件——数据库管理系统(DBMS)、管理数据库的人员——数据库管理员 (DBA)。这样的数据、硬件、软件和管理人员的总体构成数据库系统。数据库仅是数据库系统的一个组成部分。 数据库系统的功能和特征 数据库系统由文卷系统发展而来。与文卷系统相比，这种系统具有数据、体系和控制三个方面的主要特征。 数据特征 在文卷系统中虽然程序与数据之间可用存取方法进行转换,但文卷还是与应用程序对应的,即数据仍面向应用。每一应用各自建立自己的一组文卷。不同的应用若涉及相同的数据，则这些数据分别纳入各自的文卷之中。文卷的各种记录之间没有建立联系，因而数据冗余度大。增加新的应用，必须同时增加新的文卷。因此，文卷系统中的文卷是无结构的、不易扩充的信息集合。数据库则不仅描述数据本身，而且描述数据之间的联系。它的数据结构反映了某一部门的整体信息结构，数据冗余度小、易于扩充新的应用，因而是面向数据总体结构的信息集合，可为多个用户共享。 体系特征 一切数据都有逻辑和物理两个侧面。在数据库系统中，数据逻辑结构的描述称为逻辑模式。逻辑模式又分为描述全局逻辑结构的全局模式(简称模式)和描述某些应用所涉及的局部逻辑结构的子模式。数据物理结构的描述称为存储模式。这两种模式总称为数据库模式。 数据库系统中，用户根据子模式编制程序。子模式与模式模式与存储模式之间有软件进行映射。因此,程序与数据之间具有两级独立性：物理独立性和逻辑独立性。数据的存储模式改变，而模式可以不改变，因而不必改写应用程序,这称为物理独立性。模式改变时,子模式可能不改变，也就不必改写应用程序，这称为逻辑独立性。由于数据库系统具备比较高的程序与数据的独立性，可以使程序员在编制应用程序时集中精力考虑算法逻辑，不必过问物理细节，而且可以大大减少应用程序维护的工作量。 控制特征 数据库数据数量庞大，结构复杂，又为多个用户所共享。因此，必须由数据库管理系统在定义、建立、运行以及维护时进行统一管理和控制，以保证数据库数据的安全性、完整性和并发操作的一致性。此外，还必须有数据库管理员专门负责对数据库的管理、控制监督和改进。 由于数据库系统具有上述特征，它的出现使信息系统的研制从围绕加工数据的程序为中心，转变到围绕共享的数据库来进行。这便于数据的集中管理，有利于应用程序的研制和维护。数据减少了冗余度和提高了相容性，从而提高了作出决策的相容性。因此，大型复杂的信息系统大多以数据库为核心，数据库系统在计算机应用中起着越来越重要的作用。 研究课题 数据库研究的课题，主要涉及三个领域。 数据库管理系统软件的研制 DBMS是数据库系统的基础。研制DBMS的基本目标，是扩大功能，提高性能和可用性，从而提高用户的生产率。70年代以来，研制的重点是探索关系数据库管理系统的设计，内容包括关系数据语言、查询优化、并发控制和系统性能等。另一类课题是对DBMS标准化的研究，即研究一个统一的DBMS体系结构的规范。 数据库设计 这是在计算机系统具有的数据库管理系统的基础上，按照应用要求以及计算机系统所提供的数据模型和功能，设计一个结构良好、使用方便、效率较高的，以数据库为核心的应用信息系统。这一领域主要的研究课题，是数据库设计方法学和设计工具的探索。例如，运用软件工程的方法和工具指导数据库设计；研究数据库设计各个阶段中完备的方法和工具；以关系数据库的规范化理论为指南进行数据库逻辑设计等。 数据库理论 主要研究关系数据库理论。关系数据库理论研究的意义，一方面在于它为数据库学科奠定了理论基础另一方面它为数据库设计提供了判别标准,从而成为数据库设计的有力指南。研究的主要内容是关系的规范化理论。关系规范化理论已应用于数据库设计的各个阶段。 发展 数据库技术是计算机科学中发展最快的领域之一，新的领域越来越多。 分布式数据库系统 随着70年代后期分布计算机系统的发展，相应地研究成功分布式数据库系统。分布式数据库系统是一个在逻辑上完整，而在物理上分散在若干台互相连接的结点机上的数据库系统。它既具有分布性又具有数据库

逻辑设计阶段。因为主要是满足客户需求并考虑数据的有效组织和储存。在设计关系模式之前，应先分析数据并进行逻辑设计，比如实体识别、关系识别、数据规划和数据抽取。设计关系模式，意味着需要定义应用系统中的各个实体以及这些实体之间使用的属性和约束条件。其它重要细节如主键、外键、复合键、联合实体、实体冗余、关系权重，以及表中的数据类型也必须定义。设计的关系模式最后必须满足表结构的正确性，数据完整性和一致性。此外，还需要考虑优化，以改善数据库性能并满足客户需求，所以在关系数据库设计中设计关系模式是逻辑设计阶段的任务。

在关系型数据库中，表的“列”称为“字段” ，每个字段包含某一题与对象或类关联的信息。就像“通讯录”数据库中，“姓名”、“联系电话”这些都是表中所有行共有的性，所以把这些列称为“姓名”字段和“联系电话”字段。

关系型数据库按照结构化的方法存储数据，每个数据表都必须对各个字段定义好，也就是先定义好表的结构，再根据表的结构存入数据。

扩展资料：

在进行关系型数据库的设计过程中，要遵循以下几个原则，借此可以提高数据库的存储效率、数据完整性和可扩展性。

1、命名规范化

在概念模型设计中，对于出现的实体、属性及相关表的结构要统一。例如在数据库设计中，指定学生Sstudent，专指本科生，相关的属性有：学号、姓名、性别、出生年月等，及每个属性的类型、长度、取值范围等都要进行确定，这样就能保证在命名时不会出现同名异义或异名同义、属性特征及结构冲突等问题。

2、数据的一致性和完整性

在关系型数据库中可以采用域完整性、实体完整性和参照完整性等约束条件来满足其数据的一致性和完整性，用check、default、null、主键和外键约束来实现。

3、数据冗余

数据库中的数据应尽可能地减少冗余，这就意味着重复数据应该减少到最少。例如：若一个部门职员的电话存储在不同的表中，假设该职员的电话号码发生变化时，冗余数据的存在就要求对多个表进行更新操作，若某个表不幸被忽略了，那么就会造成数据不一致的情况。所以在数据库设计中一定要尽可能存在少地冗余。

4、范式理论

在关系数据库设计时，一般是通过设计满足某一范式来获得一个好的数据库模式，通常认为3NF在性能、扩展性和数据完整性方面达到了最好的平衡，因此,一般数据库设计要求达到3NF，消除数据依赖中不合理的部分，最终实现使一个关系仅描述一个实体或者实体间一种联系的目的。

1，数据表与数据表之间有关联（Relationship）是肯定的，但是不一定要用外键（Foreign Key），为什么看外键本质是一种约束（Constraint），该约束决定了你在增删改查的时候都会有额外开销。【实际上数据库在处理外键的时候估计也是创建一个中间表根据中间表来做关联操作，完成后再删除】

2，逗对于 逗N对N地 的关系，两个 Model 之间肯定是需要一张中间表的，比如 Student、Class 之间选课关系，是多对多的，肯定需要一张 Enroll 的表来维持，记录两个表的主键（Primary Key），但是不需要在数据库层加外键约束，只需要加两个索引，或作为联合主键。

3，至于查询，尽量不用 JOIN。但是问题是我确确实实是需要知道多个表的信息。

比如我要知道某门课（Class，已知 ID）的信息，同时还有选上该课（Enrolled）的学生信息（Student）。

使用 JOIN 看没问题，我相信你可以写出一个很长的 JOIN 语句。

但是，可能有的地方大概这样实现的（伪代码）：

getClassInfo(@class_id)

{ SELECt class_col1, class_col2 FROM class WHERe class.id = @class_id }

getStudentInfo(@class_id)

{ SELECt student_col1, student_col2 FROM student WHERe student.id IN (SELECt enroll.student_id FROM enroll WHERe enroll.class_id = @class_id) }

两种方案各有优缺。

后者最大的一个优点是灵活，比如我们引入缓存（Caching）。

一般来说，一个学校 class 数量不多，并且经常被查询，系统可能会引入缓存层（如 memcached、redis）来存放 class 对象。

那么上面的 getClassInfo 其实会变为

{

if(memcached.has(@class_id) != null)

{

return memcached.get(@class_id)

}

//查询数据库（只有 class 表），和上面的 SQL 一样

memcached.set(@class_id, class_object)

return class_object

}