为目标DBMS转换全局逻辑数据模型

在数据库设计方法学的第二个阶段，也就是物理数据库设计阶段，必须确定如何将逻辑数据结构转换为目标 DBMS 可以实现的物理数据库设计，因为物理数据库设计的许多方面都高度依赖于目标 DBMS ，你可能会发现不只一种方法可以实现数据库中指定的部分，因此为了正确的完成这项工作，需要具有对目标 DBMS 功能的全面认识，并且需要理解特定实现细节的每个可供选择的方案的优点和缺点。对某些系统来说，考虑到数据库的使用目的，可能还需要选择合适的存储策略。

       逻辑与物理数据库设计有明显的区别，逻辑数据库设计极大的独立于实现细节，逻辑数据库设计关心的是什么，而物理数据库设计关心的是怎么，特别是作为物理数据库设计者必须知道支持 DBMS 的计算机系统怎样运行，并且必须要有对目标 DBMS 的功能的整体认识，因为当前系统所提供的功能变化范围很大，因此物理设计必须依赖于具体的 DBMS 的功能。物理数据库设计的目标是在辅存上产生数据库的实现的过程，它描述了基本表，文件组织方式和用于实现数据有效访问的索引以及任何相关的完整性和安全限制。为目标 DBMS 转换全局逻辑数据模型的目标是从数据模型产生基本的工作关系数据库。物理数据库设计第一步包括从逻辑数据模型产生的表转换为在目标关系 DBMS 中可以实现的形式，这一步的第一部分要比较在逻辑数据库设计阶段收集的信息和在数据字典中存档的信息，这步的第一部分要比较在逻辑数据库阶段收集的信息和在数据字典中存档的信息。第二部分要使用这些信息进行基本表的设计，这个过程需要具有非常了解目标 DBMS 所提供的有关功能的知识。本步骤中包括三个任务，分别是

1.         设计基本表。目标是确定如何在目标 DBMS 中描述在逻辑数据模型表示的基本表。要开始物理设计过程，首先要比较和吸收在逻辑数据库设计阶段创建的表的信息。这些必要的信息可以从数据字典中获得，并且使用数据库设计语言来定义表，对于每个在逻辑数据模型中标示的表，应该有如下的定义，表名，括在括号内的简单列名表，主键以及在适当的地方的备用键，任何表示出的外键的参照完整性约束，任何标识出的外键的参照完整性约束。对于每个列有如下的定义，它的域，包括数据类型，长度和域上的约束。每个列设置可选的默认值，该列是否可以为空，该列是否是派生列，如果是怎样计算。创建的基本表最好使用 SQL 语句创建。基本表的设计应该完全记录在文档中，这样可以选择设计目标，特别是当有很多选择时，记录下选择其中的一种方法的原因。

2.         设计派生数据的表示，目标是设计派生数据在数据库中的表示。如果一个列的值可以从其它列得到，则此列就成为派生列或者计算列，例如，一个公司的全部人数可以通过统计查询来做，派生列经常不出现在 ER 模型中，但作为文档出现在数据字典中，如果某个派生列显示在 ER 模型中，则在这个名字的前面使用 / 来表明这个列式派生的，第一个步骤是检测逻辑数据模型的并产生一个包含所有派生列的列表。从物理数据库设计的角度看，将派生列存储在数据库中还是每当需要时再进行计算，需要进行一下权衡，为了确定哪个更好，应该考虑：存储数据的代价以及区维护它与派生数据的一致性代价，每次计算它需要的代价。根据性能的约束来选择一种代价低的方式。当系统的查询语言不能很方便的使用算术运算来计算派生列时，存储派生列是个不错的方法，表达派生列数据的设计应该完全记录在文档中，并且要记下选择某个设计的原因，特别是当有很多方法可以选择时，尤其要记下选择某个方法的原因。

3.         设计其它业务规则。对表的更改可能会受到更改所表达的控制现实世界的事物业务规则的约束，因此必须设计域约束以及关系完整性约束，这个步骤地目标是设计应用到数据上的其它的业务规则，这些规则的设计同样不依赖于所选的 DBMS ，有些系统比其它的系统提供了更多的业务规则。而在一些系统中，可以使用触发器来加强约束，不要过多地考虑触发器的问题，创建业务规则需要注意以下的几个规则，确认字段规则，确认记录规则。确认字段规则可以保证输入到字段中的数据是正确的，字段规则用来检查用户放置到该字段的数据是否正确，如果输入的值违反了确认规则，将会显示所定义的提示消息。当保存一条完整的记录的时候，记录确认规则将起作用，与字段确认规则不同，记录确认规则可以引用其它字段，当你想比较表中的不同字段的值时，这是很有用的。例如记录一个还书日期的信息，其还书的日期不能比借书的日期更早。业务规则的设计应该全部存档，尤其是当有多种选择存在时，将选择其中的一种方法的原因记录下来。