Re: [設計] 來談一下分析設計

看板Database (資料庫)作者seagal (會長繞跑了)時間18年前 (2006/07/13 18:41)推噓1(1推 0噓 0→)

留言1則, 1人參與討論串17/27 (看更多)

※ 引述《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)