Re: [設計] 來談一下分析設計
※ 引述《seagal (會長繞跑了)》之銘言：
: 在OO的思維裡
: 每個物件是不需要PK的
理論與現實是有差別的
OID在RDBMS是類似那種額外附加的代理鍵
有時候代理鍵在應付資料庫的一致性是很弱的
: 你也可以說她們本身就有PK
: 因為每個物件都會自己產生獨一無二的ID
: 這也是現在的OODB實做的方式
: 而在上面我舉的例子裡面
: 我總是要透過News模組的PK (NewsID)來讀取每個tuple
: 最後一個問題
: 在傳統的結構化分析與設計
: 將每個階段都切的十分清楚
: 而如果用OOA/OOD的方式來開發的話
: 並不會產出ER Model的文件(上面提過這是結構化分析 設計的產物)
: 有些DBA也沒有學過UML(至少我們team的DBA沒有學過)
: 那分析階段產出的UML該由誰負責轉成ER Model呢
嚴格來說DBA是管理已經上線的DB
DB的設計是DB設計師的事情
除非這兩個角色重疊...
: 萬能的SA/SD嘛
: 或是像come網友講的
: 在分析階段就產出ER Model
: 後面的設計都繞著ER Model來做?
: 這也就是說
: 把OOA/OOD以資料導向的方式來開發?
難道OOA, OOD就不需要用到資料庫嗎?
應該說資料庫的部份是用資料導向在開發
其他部分不是
: 我的領域並不在OODB上面
: 我只是最近剛好有需要
: 將生物資訊的大量資料作處理
: 有必要的話可能還是得硬著頭皮弄出適合的一套檔案(or DBMS)系統
: 所以如果有任何高手能指正的話
: 也歡迎針對我說錯的地方指正
: : analysis階段的class diagram只是一個雛形而已
: : 到了design階段的class diagram還必須根據data base schema重新設計一次
: : 那你覺得這時候class diagram的設計是要遷就DB
: : 還是要回頭改DB設計?
: : spiral model的開發模型是可以這樣搞
: : 不過改到DB通常表示需求分析有問題
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.223.42.62
推
07/13 22:16, , 1F
07/13 22:16, 1F
討論串 (同標題文章)
Database 近期熱門文章
PTT數位生活區 即時熱門文章
