※ 引述《come ()》之铭言： : 我是说先有资料库才有程式喔 : 你完全误会了 : ※ 引述《razor (=_=)》之铭言： : : 针对这一点,我摇头. : : 你意思就好像是说,程式都是比UML图型先做出来吗? : : 但回想UML是用来干嘛的? 塑模啊! : : 没错,资料库可能是先比模型图先弄出来,不过那又怎样? : : 这就好比未经过构思胡乱做出一个成品一样, : : 是啊,是有东西没错,但是没设计过! : : 更不用说什麽生命周期了. : : 语意丰富的Class Diagram迁就语意较少的E-R model? 可笑! : 这跟class diagram的语意一点都没关系 : 这是跟资料库的设计和整个软体开发流程的先後顺序有关 : 资料库是在analysis阶段就完成 这样说也是有道理 的确ER Model是在分析阶段就会产出的文件 不过这也是我最主要觉得的问题 硬把传统的结构化分析与设计 跟物件导向分析与设计串在一起 产生的很多问题 都让我觉得很吊诡 结构化的分析与设计 起源於1960年代末期 最初的结构化的分析与设计 并没有包含ER Model 到新一代的结构化分析与设计 才将ER Model加入 我门看陈品山是在1976年提出这个模型就可以得知了 直到1986年 Grady Booch率先发表物件导向的系统开发方法 以开启物件导向在软体工程上应用的新页 在这几十年之间 关联式资料模型的变化似乎不大 看看现在最流行的两种OO语言 Java and .NET 在支援OOA/OOD上可以说是配合的很好 例如简单的struts, EJB, servlet概念 让架构在OO上的MVC观念得以完全发挥 唯一我觉得有很多疑问的地方 就是在关联式资料库的部份 我这边举ASP.NET + SQL Server的例子 当我以三层式架构 完成我的ASP.NET网站的时候 每一层的类别都经过良好的分析与设计 配合的天衣无缝 却在资料处理层要与SQL Server沟通时 让我做了很多dirty work 也就是O/R mapping要处理的议题 例如 今天我要将新闻模组(News)从资料库读出来 或写入资料库 News类别里面的method我该怎麽实做在呢SQL Server呢? 为了简化例子 我只需要简单的两个方法 getInstance, putInstance 这样子就好 没错 SQL Server可以提供sprocs 可是光是sprocs命名 我就得取名作 News_getInstance(NewsID) News_putInstance(NewsID) 这两支 如果我每个类别有二十个方法呢 如果我有二十个类别呢? 我的sprocs就会有400个 事实上有些method是应该被封装起来的 所以也不应该被其他method存取到 从sprocs拿出来的资料 交给ASP.NET处理的时候 ASP.NET是利用一种ADO.NET的技术 简单来说就是将资料变成一个table 你必须要再去读取每个table里面的值 转换成你自己的物件 Oh my god 我只是要用个OO而已 怎麽多出来这麽多个步骤了 虽然我还是乖乖做完了:( 这只是一个小问题而已 我再举出另外两个问题 在OO的思维里 每个物件是不需要PK的 你也可以说她们本身就有PK 因为每个物件都会自己产生独一无二的ID 这也是现在的OODB实做的方式 而在上面我举的例子里面 我总是要透过News模组的PK (NewsID)来读取每个tuple 最後一个问题 在传统的结构化分析与设计 将每个阶段都切的十分清楚 而如果用OOA/OOD的方式来开发的话 并不会产出ER Model的文件(上面提过这是结构化分析 设计的产物) 有些DBA也没有学过UML(至少我们team的DBA没有学过) 那分析阶段产出的UML该由谁负责转成ER Model呢 万能的SA/SD嘛 或是像come网友讲的 在分析阶段就产出ER Model 後面的设计都绕着ER Model来做? 这也就是说 把OOA/OOD以资料导向的方式来开发? 我的领域并不在OODB上面 我只是最近刚好有需要 将生物资讯的大量资料作处理 有必要的话可能还是得硬着头皮弄出适合的一套档案(or DBMS)系统 所以如果有任何高手能指正的话 也欢迎针对我说错的地方指正 : analysis阶段的class diagram只是一个雏形而已 : 到了design阶段的class diagram还必须根据data base schema重新设计一次 : 那你觉得这时候class diagram的设计是要迁就DB : 还是要回头改DB设计? : spiral model的开发模型是可以这样搞 : 不过改到DB通常表示需求分析有问题 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 140.109.169.200 ※ 编辑: seagal 来自: 140.109.169.200 (07/13 19:42)