推 come:請問你用哪一套ER model在設計的? 07/12 12:09
推 razor:... UML的Class Diagram 07/12 20:28
前陣子做個資料庫分析設計,做了相當大膽的事.
因學過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