逻辑数据模型到物理数据模型的转变

• 
  　　逻辑模型通过定义必要的数据表、表间关系及其元组数目而澄清了应用程序的实现领域。在逻辑设计阶段要定义每一表列的属性，比如是否接受空值、默认值、规则以及各类检查和约束等。然后就可以把设计应用到特定的关系数据库管理系统 (RDBMS)——就像在地面的圆坑中打上方木桩。
  　　
  　　
  　　
  　　在前面的文章 里我曾经提出过一个旅行社的例子，这个旅行社要面对4类客户：
  　　接受佣金的其他旅行社
  　　享受打折优惠、拥有一些旅行者的企业客户
  　　特权组织或者俱乐部，它们接受佣金其客户享受打折服务。
  　　零售服务的客户
  　　我们考虑针对各个类型的客户分别创建客户表，但是这种方法会产生若干问题。更好的解决方案是建立唯一客户表，通过类型字段区分每一客户，这样就需要第2个数据表来定义客户的类型。这样，我们的逻辑模型就如图A所示。当然，真正的应用程序会复杂得多，不过我们在这里宁肯让有关的问题和程序来得简单一些。
  　　
  　　图A
  　　　
  　　逻辑数据模型的简单视图
  　　
  　　在结合客户表之后，我们的设计就包含了定义客户类型的一个新表。
  　　解决规范化问题
  　　
  　　
  　　给出客户表并没有完全终止规范化过程，我们还要考虑以下问题：
  　　
  　　企业旅行者的姓名字段还没有成为最小的可能单元，从而破坏了1NF（First Normal Form）原则。这些旅行者可以是单独的游客而非公司。不过解决这个问题也很简单，我们可以创建两个字段：FirstName和LastName，然后做出些有关定义。
  　　新的客户表也有个性质比较严重的问题：接受零售服务的客户很可能是需要FirstName和LastName字段的个人。为了简化示例，我们不妨规定以下一条商务规则：所有的客户都是公司，所以在目前阶段还不需要解决这个问题。出于简单的目的，我们只引入了这一条商务规则，把客户限定为企业而非个人，这样就不再需要进一步地设计了。
  　　地址信息破坏了2NF（Second Normal Form）规则。地址字段和其他完整说明客户的所有字段而非地址字段都存在依附性。所以，某些开发人员可能会取消新表中的地址字段。不过那样做的话，如果数据表按照BCNF规则规范化（Boyce-Codd Normal Form）则可能引入额外的数据表。在这种起来下，你可以引入地址、城市和州等数据表来遵守以上规则。此外，客户还可能具有多个地址，比如说，一个地址专门用来通邮；一个地址专门用来寄送票据和日程表信息等等。
  　　客户表中的打折和佣金字段也有问题，它们倒没有违反什么规范化规则，但是这类字段很多往往会是空白。空字段虽然也没什么坏处，但最好还是尽量避免出现这样的情况。事实上，太多的空白往往是出现规范化错误的信号。所以，就我们的例子来说，两个字段都完全说明了主键而且不会与其他非键字段形成明显的依附关系。不过，由于可能出现空白字段的缘故，我们还是把这些字段移到一个新表，通过客户标识每条记录，然后给佣金或者折扣标记百分比。
  　　客户只会有一个电话号码吗？如果不是这样，客户表内当前的电话号码字段就破坏了1NF规则：禁止出现多值字段。那就是说，一个字段内不允许输入多个电话号码。所以电话号码字段也必须移到一个新表中来，这样就需要一个电话号码表。解决的办法是从客户表中删除电话号码字段然后创建一个只有电话号码的新表。
  　　规范化还是不规范化
  　　如果我们的目标是老实遵守BCNF原则，那么地址表的规范化（Normalizing）就是必须考虑的问题，我们需要按照客户类型来标识每一地址：商务、服务交付等等。第1步是从客户表中删除地址字段，然后根据图B所显示的初始列表创建新的地址表。但我们还必须接着解决州和城市字段之间的依附性问题。
  　　
  　　图B
  　　　
  　　新地址表按照以上初始列表创建
  　　
  　　这样又引入了两个问题。首先，图B中的条目没有实现完全的规范化。该表破坏了3NF规则，因为非键字段之间存在依附性：城市和州字段互相依附。为了对该表实现规范化：
  　　
  　　从地址列表中删除邮政编码（ZIP代码）、城市、州和国家字段。
  　　创建邮政编码表，把刚才删除的字段移到该新表。
  　　在地址表中作为外键插入邮政编码主键。
  　　某些开发人员可能会争辩说让数据表遵守BCNF可能太过分了。有些人则认为数据库设计的规范化总是一种简单又低廉的设计方式。事实上，某些开发者还可能更进一步创建城市、州甚至国家表来避免出现重复性的组。但是，就现在来看，我们主要关注的是解决依附性问题。资源和需求之间的平衡还谈不上对与错。
  　　
  　　第2个问题刚才我们已经提到过了，但这个问题不打算在本文中得到解决。一个用在某特定小地区的应用程序也许并不需要采用一个大型的数据表来保存城市、州、ZIP代码和国家等信息。另一方面，如果将来有可能扩大业务，你就应当考虑相关设计来谋取成功。你要确定应用程序是否需要大型的、耗费资源和降低性能的数据表来保存城市、州、ZIP代码和国家值等客户可能永远都用不着的信息。在做了以上修改之后我们的设计蓝图中又冒出了一些新表，如图C所示。
  　　
  　　图C
  　　　 点击查看大图
  　　采用若干新表对地址信息实现完全的规范化
  　　从逻辑模型迁移到物理模型
  　　
  　　
  　　数据表实现规范化之后，下面我们就应该着手选择目标数据库，把逻辑模型转变为物理模型。
  
• [1] [2] [3] 下一页 
• 复制本页网址和标题，发送给你QQ/Msn的好友一起分享
  
  
• 逻辑数据模型到物理数据模型的转变 相关文章：
• ·逻辑数据模型到物理数据模型的转变
• 逻辑数据模型到物理数据模型的转变 相关软件

上一篇:正确的数据库设计确保了数据完整性

下一篇:多系统共存的方法

• 特别声明：本站除部分特别声明禁止转载的专稿外的其他文章可以自由转载，但请务必注明出处和原始作
• 者.文章版权归文章原始作者所有.对于被本站转载文章的个人和网站，我们表示深深的谢意。如果本站转
• 载的文章有版权问题请联系编辑人员,我们尽快予以更正. 转载请注明来源：http://www.hackhome.com

精品推荐

热点TOP10

特别推荐