我对於OO <-> E-R model的对应也蛮有兴趣的 不过我还是比较希望OODB能够早日成熟 有一个模型 是ER的加强版 叫做EER model 里面就已经有类别的概念了 而目前热门的资料库 都还是以ER model(SQL)为主 这让我觉得蛮头疼的 因为不管OO的分析多麽好 到最後都还是得对应回去ER model上面 也就是现在比较流行的SQL server or MySQL(关联式资料库) 我看您举的例子 似乎也会发生这种对映上的问题 例如FAQ跟News是两个不同的类别 而同样继承module这个类别 我之前曾做过ㄧ个EIP(企业入口网站) 就是这样设计的 而如果要对应回去SQL的话 一样要弄出FAQ table & News table 因为SQL没办法表现继承 所以最底层的那些类别还是都得帮助她们生出表格(关联) 然後在逻辑层跟资料存取上再加以处理 让SQL读出来的资料能够转成OO的方式 这是我的实作方式 应该跟您的概念大同小异 也欢迎大家一起参与讨论:) ※ 引述《razor (=_=)》之铭言： : 前阵子做个资料库分析设计,做了相当大胆的事. : 因学过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: 140.109.169.200