Re: [設計] 來談一下分析設計
我對於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
討論串 (同標題文章)
Database 近期熱門文章
PTT數位生活區 即時熱門文章
