Go homepage(回首页)
Upload pictures (上传图片)
Write articles (发文字帖)

The author:(作者)delv
published in(发表于) 2013/12/30 4:40:35
《数据模型资源手册》一二三卷：逻辑数据库设计的经典_mssql学习_编程技术

《数据模型资源手册》一二三卷：逻辑数据库设计的经典_mssql学习_编程技术-你的首页-uuhomepage.com
《数据模型资源手册》共出了三卷。一二卷英文版2001年出版，中文翻译版2004年出版。中文版销量很差，因此出版该书的机械工业出版社没有再版，目前市场上这两本书已经绝版。淘宝上还可以买到复印版。china-pub上可以按需印刷，不过比较贵。卷三是今年年初出版的，英文版，中文版估计过几年才能看多，或者就看不到了。好在现在有互联网和银联卡，大概是在今年3，4月份我直接用招行的信用卡在amazon.com上买了一本，10多天之后就到了。
这三本书在amazon.com上评价都很高。中文版的一二卷在当当和卓越上评价都不错，一些技术论坛上看过的人的评价也都很高。我也认为是非常值得看的一套书。
其中第一卷讲一些通用的数据模型，比如个人与组织，产品，订单，订单配送，发票，财务，人力资源等。卷二是一些特定行业的数据模型，在卷一的基础上会有所变化，比如制造业，电信，金融，保险，医疗，旅游业，电子商务等。卷三讲的有点类似于设计模式了，作者对数据模型的抽象程度做了分类，对卷一提到的各种数据模型在不同的抽象程度下设计出来的数据模型做详细的分析，据此比较容易看明白卷一和卷二中作者设计的思路。
看完这三卷之后我目前印象还比较深的有三个模块，一个是个人与组织，一个是联系方式，一个是业务规则。
个人与组织被抽象为party，这样的好处在我们公司的CRM中应该会比较明显，我们公司的会员中既有组织又有个人，我们公司的代理中也是既有组织又有个人。目前的逻辑是认为会员表中都是个人，代理表中都是组织，实际上有很多例外情况。
联系方式，卷一和卷二给出了抽象程度比较高的模型，把电话，手机，email，qq，通信地址等抽象为一种“通信机制”。抽象程度比较高的话，扩展性会好一些，与其他实体的关联会简单一些。比如party的联系机制，只需要一个表就可以了。我们公司的会员表中用的是抽象程度最低的做法，会员表中直接有一列叫BP机号码。新做的客史项目抽象程度高一些。
业务规则，可以把不同行业的不同的业务规则容纳进来。我看过这个模型之后发现我们公司酒店业务用的rateplan，机票系统用的运价，都可以用这个业务规则实体来表示。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/vincent_zuo/archive/2009/12/20/5044937.aspx


赞

If you have any requirements, please contact webmaster。(如果有什么要求，请联系站长)




QQ:154298438
QQ:417480759