数据建模入门Beginner’sGuidetoDataModelling在本文中我们主要介绍7个主题，确定数据模型的范围（创建实体）、主键、外键、1对多关系、层级、继承与参考数据。先说明本文所用的建模工具软件“DezignDataModellingTool”。作者选择此工具的诱因很简单，工具挺好很强悍，灵活最重要的是付的起钱。非常说明DatabaseAnswers社区成员订购Dezign打75折。想打折的话与作者联系吧。记住一定要告诉他你的社区ID，不过我（译者）还是推荐PD（PowerDesigner）。在本文的最后，我们构建一个逻辑数据模型，一般我们称之为“实体关系图”，其实希望本文对你有点用。让我们开始吧。在本文中，我们将为麦当劳的一个简单的订单处理过程构建数据模型，。构建数据模型的步骤：确定数据模型的范围确定该范围中的实体定义实体之间的关系1.确定数据模型的范围走入麦当劳，我们会发觉她们为客户提供好多产品，我们的第一个任务就是确定我们的数据模型中须要包含什么产品。图1欢迎来到麦当劳目前，我们只对吃的与喝的东西有兴趣；椅子上的瓶子我们并不去理会它。
我们的数据模型中应当包括三类实体，客人、订单与产品2.字段：在这一过程中，我们不管实体的详尽信息，实体间的关系，仅指定字段和一个details域，下一步再来替换details域的内容字段域一般是第一个域如图所示，customers_version2的字段是Customer_id对面的’PK’表示该域是此表的字段字段十分重要，只有字段能够在表中区别实体数据数据库三范式：图2麦当劳里的实体1）数据库表的每一列都是不可分割的数据项，无重复列，也就是说一个数据项的属性不能是复合属性、不能是多值属性、也不能是重复属性2）每一行必须惟一分辨，行数据不重复（字段）3）无数据冗余，数据库表中不能包含其他表的非字段信息（字段）。4）BC范式，数据项属性不能依赖或传递依赖任一侯选关键字（一般是字段）。3.字段：为实体添加关系：当一个表的字段用于其他表时，称为这个其他表的主键。如图所示，当customer_id在表Orders_vision3表中出现时，为该表的主键一般在数据模型图中使用’FK’表示必选关键域字段一般是强制性的必选域，也就是说，一个表中的字段必须与另一个表的字段的实际数据对应，例如在我们的模型中，Customers_version2中的字段customer_id，在表Orders_vision3中是字段，这表示在表Orders_version3中customer_id的数据在表图3麦当劳实体有外键Customers_version2中一定会有对应的一条数据项。
在数据模型图中，这些关系在紧靠字段实体的两侧有一条短直线来表示，参考图4。4.一对多关系1）一对多关系一个客户可以下多个订单对表Orders来说，它这一方的关系是“多”，Customer表是“一”。在数据模型图中，这些关系在“多”的一端采用三条短线来表示，称之为“乌鸦脚”。2）可选关键域不是每一个顾客就会有订单，一般情况下客户可能我们也得准许这些情况，就是有人太多变，原本想买，如今不买了，原本要买披萨，现今改包子了。对于表Orders来说，这个关系在它这一方是“可任选的（optional）”这在数据模型图中在紧靠表Orders的两侧用一个大写的“o”来表示。参考图4。5.分层在这一步我们添加参考数据。图4有关系的麦当劳实体在图5中我们可以看见产品（Product）表与产品类型表（ProductType）之间的层级关系。RabbitsEars注意，在Product_Types_v1表有一条实线，从其右上角开始，至其两侧边。数据剖析中这被称为“自反关系”。
浅显来讲，我们说这个产品类型表与自己相连，也就是说该表中的一项可能与表中的另一项有关系。这些方式来实现每一种产品类型与另一种产品类型有关系，进而实现层级化。举例说明：产品Panini是产品泛型MiscelleneousSandwiches的一种，该基类又属于高层产品类ColdFood，这个ColdFood又属于Food类。上次去麦当劳的时侯，瞧瞧柜台旁边的报价表，试着定义数据模型。注意：实线的两端都有一个小’o’。这表示“产品类型的父类”是可选的，由于最高层的产品类型没有父类型。参考图5。图5麦当劳里的产品6.承继1）食物与啤酒是典型的产品2）她们承继产品的一些通用属性，同时也有专有属性。3）如：食物可以有坚果（Nuts），啤酒不可能有，但两者都要有名子。4）在数据模型图中（注意：本文的所有数据模型图都是由Dezign来世成的），我们可以用一个大圆圈下边两条线来表示承继，参考图6。5）承继是数据模型图中很重要的主题。6）浅显点来讲，“继承”表示了实体之间的“父子”关系。
7）要确定承继关系，是一个“是一个”的问题，在本例中，我们可以问“书是一个产品吗？”，当回答是“是”的时侯，“书”与“产品”之间就有承继关系。8）其实，每类产品都有其他产品没有的专用属性，例如，书有ISBN号，食物与啤酒不可能有。9）数据模型中确认所有承继关系是很重要的。10）其实，作为有着多年开发经验的DBA，我很负责的告诉你们，图6麦当劳里的产品承继这个“继承”关系在数据库中是很“模糊的”，由于实现上去太不灵活，太麻烦了。光是双字段就是大问题，例如说数据建模基础教程，假定产品只有食物和饮品数据建模基础教程，这么食物和饮品中的产品ID在产品表中都有，但是这个ID在三个表中都是字段，同时在食物和饮品表中还是字段。11）更好玩的是，有些时侯，逻辑数据模型图中的“继承”关系在设计数据库时没有了，消失了。参考图6。7.参考数据1）下边我们来瞧瞧以“地址类型”为例的参考数据。2）这一类的数据有几个特征：不怎样变化相对来说数据量小，通常也就是几十条，不超过百条。通常我们用一个代码（字段）来显示参考数据表中的数据一般在程序设计时用户在下拉框、多选框、列表中选择。
3）标准在“地址表”中有域“iso_country_codes”。Iso表示“InternationalStandardsOrganisation”。可能的情况下，一般使用国内或国际标准客户地址：我们的数据模型中灵活地处理地址信息。我们不把地址信息写在客户表中，而是单独构建一个“地址表”，这样的话一个客人就可以很容易的有多个地址了。其他益处：一个地址可以有多个客户，要晓得一个家庭的所有成员基本都在一个地址，她们上网买东西不一定使用一个账户。作为一个单独的表来说，我们很容易的就可以使用商业软件验证地址的有效性，这类图7麦当劳客户的地址表参考数据软件请自己到GOOGLE上搜索“AddressValidationSoftware”，本文的作者使用的QAS。这些技巧我们可以确保我们的地址表是百分百有效的。最后给出一个本文反例的逻辑数据模型图，如图8。图8麦当劳数据模型图8.联系我们希望本文对你有用，对我来说最有用的就是解决了如何在化学数据库中实现逻辑模型图中继承的问题，或则说我总算找到根据，承继对数据库来说就是一个字“扯”。
而且我们在面向对象的设计中，承继是一个关键的封装形式，最简单的办法应当是只有具体的类（不是具象类）才在数据库中有对应的表实现，其实，承继的中间层最好都是具象类或则插口，这个问题留出来更多的思索。有问题Mail作者，databaseanswers@gmail.com，本文原文来自，欢迎访问。其实也欢迎Mail我，kevin.d.j.white@gmail.com。我很菜，但我很执著，我很帅，但我从不说自己很帅。感谢你们。
暂无评论内容