前阵子做个资料库分析设计,做了相当大胆的事. 因学过UML Class Diagram不久,从现有网站资料反推资料库模型的事, 就使用Class Diagram处理,觉得构思相当顺畅且合理,比E-R model顺多了. (其实E-R model是Class Diagram的子集) 但是做了过度抽象化,譬如原网站资料分为好几个区块,各区块有各自的主题诉求, 譬如A区块发布新闻,B区块展示商品,C区块提供FAQ... 在这里就看到所有的区块都属於一个Class类别, 而所有区块内容每一条目,都属於一个Object类别, 由於有些新闻会以合集式刊登,类似於报纸副刊连载小说,同一篇小说分为数回, 所以必须提供一个丛集类别,命名为Cluster. 以连载小说为例,各回的文章都是Object类别实体, 它们归属於一个名为novel的Class类别实体, 而同一小说主题的各回篇章,归属於一个以该小说主题为名的Cluster类别实例. 同学们听到这里有没有问题? 好,没有问题,那我们继续下去. 这样做完之後,思考这个模型的好坏, 我觉得它有个好处是资料库的表格少,对写程式来讲,比较好记. 不过因为表格少,每个表格资料累积就会大,资料多一点就会慢...吧? 另外,应用程式的view与资料库的view差异相当大, (不像一般写程式的人建资料库是客户面要看到什麽表格,资料库就会建立什麽表格.) 这些差异的地方,就是要靠程式设计才能够达成的应用程式功能. 其实这样的差异并不特别, 一般来说,资料库较底层会有一些程序负责维护实体完整性及参考完整性, 而较高层则会有另一些程序来实现像商业规则(business rule)这样的应用规则. 关於以上所说明的事,网友们有没有什麽反方/正方的看法? 请多指教. --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 61.231.16.89