数据库设计步骤及其设计过程中的注意事项是什么谢谢！

1、需求分析：了解用户的数据需求、处理需求、安全性及完整性要求；

2、概念设计：通过数据抽象，设计系统概念模型，一般为E-R模型；

3、逻辑结构设计：设计系统的模式和外模式，对于关系模型主要是基本表和视图；

4、物理结构设计：设计数据的存储结构和存取方法，如索引的设计；

5、系统实施：组织数据入库、编制应用程序、试运行；

6、运行维护：系统投入运行，长期的维护工作。设计时应注意的问题1、规范命名。所有的库名、表名、域名必须遵循统一的命名规则，并进行必要说明，以方便设计、维护、查询。 ２．控制字段的引用。在设计时，可以选择适当的数据库设计管理工具，以方便开发人员的分布式设计和数据小组的集中审核管理。

使用数据库文件组应注意以下问题:

我们可以出于分配和管理的目的将数据库文件分为多个组。在某些情况下，我们可以通过控制将数据和索引放置到专用磁盘上的专门文件组来改善性能。包含主数据文件的文件组被称为主文件组。只有一个主文件组，如果在创建数据库时不明确地指示将文件放到某个其他的文件组，所有的数据文件都会被放在主文件组中。

除了主文件组，数据库还可以有一个或多个用户定义的文件组。我们可以在CREATE DATABASE或ALTER DATABASE语句中使用FILEGROUP关键字来创建用户定义的文件组。

注意不要混淆主文件组和主文件。

主文件总是在创建数据库时第一个列出的文件，并且它的文件扩展名一般为mdf。主文件的一个特点就是它指向master数据库中的一张称为sysfiles1的表，该表包含属于这个数据库的所有文件的信息。

主文件组是包含主文件的文件组。该文件组包含主数据文件和所有没有放在其他专门文件组里的文件。系统表里的所有页面总是从主文件组里的文件中分配。

默认文件组

一个文件组总是会有一个DEFAULT属性。注意DEFAULT是文件组的一个属性而不是名字。在每个数据库中只有一个文件组是默认文件组。默认情况下，主文件组同时也是默认文件组。数据库所有者能够使用ALTER DATABASE语句改变默认文件组。默认文件组包含没有放在一个专门文件组里的全部的表和索引。

大多数SQL Server数据库只有一个单独的数据文件，该文件就在一个（默认的）文件组中。实际上，大多数用户都对SQL Server是如何工作的了解不够多，从而不知道文件组是什么。用户获得了对数据库更为精密的了解后，她也许会决定使用多个装置来将一个数据库的I/O分散开来。实现它最简单的方法就是在一个RAID装置上创建一个数据库文件。不过那样一来还是不需要使用文件组。随着用户对数据库的精密性和复杂度的了解达到更高的水平，她也许会发现非常需要使用多个文件——也许是为了创建一个单个装置不能提供足够空间的数据库。在这种情况下，她还是不需要使用文件组——她能够使用一个CREATE DATABASE语句来完成这个目标，该语句带的参数是一组位于不同驱动器上文件的列表。

更为资深的数据库管理员也许会决定将不同的表分配到不同的驱动器上，或者使用SQL Server 2005的表和索引分区特性，只有这时才会用到文件组。他们可以使用SQL Server Management Studio中的对象浏览器来创建位于多个文件组上的数据库。然后他们能够右击对象浏览器中的数据库名称并创建一个CREATE DATABASE命令脚本，该脚本包含所有文件组中的所有文件。它们能够保存该脚本并在需要重建这个数据库或创建一个类似的数据库时重用该脚本。

你也许想知道为什么会需要创建位于一个物理驱动器的多个文件之上的数据库。

通常这样做并不会对性能有所改善，但是它为我们在两个重要的方面增加了灵活性。

首先，如果我们需要在磁盘损坏时从备份还原一个数据库，那么新的数据库必须包

含与原来数据库同样数目的文件。例如，如果原来的数据库由一个12GB的大型文件

组成，我们就需要将它还原到有着同样大小文件的数据库中。如果这时没有另外一个

12GB的驱动器马上可供使用，那么我们就不能还原数据库！然而，如果最初创建的

数据库是在几个较小的文件上的，那么实际上我们就增加了还原期间的灵活性。我们

更可能找到几个4GB的可用驱动器而不是一个大型的12GB驱动器。

其次，将数据库分布到多个文件上，即使这些文件是在同一个驱动器上，也能够为

我们带来可以很方便地将数据库迁移到不同驱动器上的灵活性。如果我们在将来改

变硬件配置，就可能会有这种需要。

分配有空间的对象（也就是表和索引）被创建在一个特殊的文件组之上。如果没有指定文件组，它们会被创建在默认的文件组之上。当我们向存储在某个特定的文件组上的对象增加空间时，数据会以按比例填充（proportional fill）的方式被存储，这意味着如果在一个文件组中有一个文件的自由空间是另一个文件的两倍，那么每当从第二个文件分配一个区（extent）时，将会从第一个文件分配两个区。在本章后面部分会有对区的更多讨论。

我们也可以使用文件组来备份数据库的一些部分。因为一张表是被创建在单个的文件组之上的，所以可以通过备份放置了一些表的文件组来选择备份某一批关键表。我们也可以通过两种方式来还原单个的文件或文件组。首先，我们可以对数据库进行部分还原并且只是还原文件组的一个子集，该子集必须包括主文件组。一旦主文件组还原完毕，数据库就马上可用，但是只有在已还原的文件组上的对象才会可用。部分还原文件组的一个子集是对一个问题的解决方案。该问题就是如何允许非常大型的数据库（VLDB，very large database）在限定的时间窗口内可用。

需要注意的是：

1、 想好迁移上云后想达到的效果

即通过使用云数据库希望达到的目的，比如降低成本，更高的灵活性，更大的可扩展性，还是更高的可靠性。用户需要根据迁移目的来选择合适的服务类型。如果只是简单的随大流将服务迁移到云上，很可能导致未来的问题。

2、 选择有完善服务支持的云服务商

包括服务商的 SLA 承诺和数据安全承诺。很多情况下，将应用迁移到云数据库涉及数据迁移，应用适配等，云服务商有完善的支持服务，可以在遇到困难时起到事半功倍的效果。如果云服务商具备足够的经验，通常可以给出场景性的完整方案，对于提高迁移的成功率有直接的帮助。

3、 充分的迁移规划

1）维护和数据管理计划。IT人员提前了解公司所需的数据需求，选择合适的数据库引擎类型、付费方式；熟悉云数据库引擎提供的管理工具，基于预期的云数据管理需求，做好主动解决问题的准备。

2）账户控制计划。云数据库服务商一般都会提供丰富的账户控制能力，包括授权和再授权、审计，基于预先确定的安全设置，授权访问设置，审计计划，然后会发现云数据库服务真的是一个非常高效简洁的工具。

3）迁移和回退计划。一般来说，一个完备的迁移计划和演练， 有助于在事先发现迁移过程中可能遇到的问题， 制定有针对性的计划；万一迁移失败，回退计划可以保证业务在本地继续执行，从而减少迁移过程的压力，并保证业务的完整性。

4、 从容易的服务开始

云计算的环境和本地数据库存在一定的差异，考虑到业务的连续性，初次使用公有云数据库时，可以从简单的服务开始，如测试验证数据库、辅组性的资源索引数据库、新开发业务数据库等，通过这些服务先熟悉云数据库的基本特征和特性，评估其性能和可用性相关内容，管理工具的成熟度。比如，有些服务商的云数据库存在不同时段的性能波动，则可能不是好的选择。

加表字段 : 约束条件不能有noy null,primary key等

�8�4 修改表字段的数据类型: 数据类型为 text、image、ntext 的列，或者属于primary key的列不能修改。新的数据类型应与原数据类型兼容

删除数据表可使用DROP TABLE: （1）DROP TABLE 不能用于删除由 FOREIGN KEY 约束引用的表。必须先删除引用的 FOREIGN KEY 约束或引用的表。

（2）在系统表上不能使用 DROP TABLE 语句。

(3)数据、表上的索引都删除。表上的视图往往仍然保留，但无法引用

�6�1 使用INSERT语句一次只能为表插入一行数据。增加多行使用多条insert

�6�1 如果INSERT语句违反约束或规则，或者它有与列的数据类型不兼

�6�1 容的值，那么该语句就会失败，并且SQL Server 将显示错误信息。

�6�1 此时必须列出列名（因为提供的值的个数与表中列的个数不一致）。

�6�1 未列出的列中将自动填入缺省值，如果没有设置缺省值则填入NULL

�6�1 C_Info中的课程类别和课程说明列必须允许为NULL，因为系统实际插入的数据为：(‘9720045’,‘Web开发技术’,default,2,default)。

�6�1 学号、姓名字段的数据类型应与追加记录的字段author_id,au_fname数据类型一致或兼容

�6�1 学号、姓名字段的数据类型的长度应小于或者等于追加记录的字段author_id,au_fname数据类型的长度。

�6�1 Stu表中其他为追加的字段必须允许为NULL

一、熟悉MySQL的运行环境

MySQL数据库是在Linux环境下运行的，建议先熟练Linux系统。选定好架构模式之后就可以开始进入程序开发和数据处理的环节。

二、有扎实的数据库理论知识

MySQL作为关系型数据库，在实际的应用中也要学会分析存储数据的关系型数据结构，关系 *** 作集合等。只有对这些内容有一个明确的认识，在设计数据库字段、表与表的关系才能考虑周全，避免出现错误。

三、熟练的SQL语言运用

任何一种数据库的学习，包括MySQL，SQL语句都是位于核心部分的内容。需要注意的是SQL语言的使用要力求简明扼要，能用一个select搞定的问题并不需要写更多的union。所以在SQL语言的应用方面要注意高效。

如果希望设计出比较好的数据库，有一些专门的规则，称为数据库的设计范式。遵循这些规则，你将设计出良好的数据库。下面将逐一对其进行说明：

1第一范式：它的目标是确保每一列的原子性，如果每列（或属性）都是不可再分的最小数据单元，则满足第一范式。

2第二范式：第二范式则是在第一范式的基础上，更近一层，目标是确保表中的每一列都和主键相关。如果一个关系满足第一范式，并且除了主键意外的其他列，都依赖与该主键，则满足第二范式。例如：订单表（订单编号，产品编号，订购日期，价格，。。。）;该表主要用来表述订单，所以将订单设为主键，而“订购日期”，“价格”这两列与“订单编号”主键相关。但是“产品编号”并不依赖于“订单编号”，该列应当删除，放入产品表中。这样，该表就之描述一件事情：订单信息了。

3第三范式：第三范式在第二范式的基础上更近一层，目标是确保每列都和主键列直接相关，而不是间接相关，如果一个关系满足第二范式，并且除了主键之外的其他列都不依赖与主键列，则满足第三范式。

例如：订单表（订单编号，订购日期，顾客编号，顾客姓名，);初看该表没有问题，满足第二范式，单细看您会发现，“顾客姓名”和“顾客编号”又相关，最后经过传递依赖，“顾客姓名”和“订单编号”相关。为了满足第三范式，我们在设计数据库的时候应该去掉“顾客姓名”列。

以上就是关于数据库设计步骤及其设计过程中的注意事项是什么谢谢！全部的内容，包括:数据库设计步骤及其设计过程中的注意事项是什么谢谢！、使用数据文件和文件组应该注意哪些问题、将数据库迁移到云数据库需要注意什么等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！