※ 文章網址: https://www.ptt.cc/bbs/Examination/M.1372419803.A.0FB.html
推 ARCHERDEVIL:ship&port主鍵放進去就好不是嗎？ 06/28 20:18
→ ARCHERDEVIL:基本上多對多關係你就要成立一個關聯表 06/28 20:19
推 ARCHERDEVIL:我就知道你想問這個＝ ＝ ... 06/28 20:51
→ ARCHERDEVIL:post_visit是弱實體 06/28 20:51
→ ARCHERDEVIL:SHIT_AT_PORT一個表 內容是port&port的主鍵 06/28 20:52
→ ARCHERDEVIL:然後其主鍵是port主鍵跟ship主鍵的結合體 06/28 20:52
→ ARCHERDEVIL:該主鍵放到post_visit裡面當作限制 06/28 20:53
→ ARCHERDEVIL:於是弱實體也完成 06/28 20:53
→ ARCHERDEVIL:說得簡單一點就是{ship,port}→ship_at_port 06/28 20:54
→ ARCHERDEVIL:ship_at_port→port_visit 06/28 20:55
→ ARCHERDEVIL:關聯表之間的相依限制大概像這樣y 06/28 20:55
→ ARCHERDEVIL:然後post_visit... 一定是少了船或者港口都不行 06/28 20:56
推 ARCHERDEVIL:SHIT_AT_PORT一個表 內容是ship&port的主鍵 上面打錯 06/28 21:01
→ ARCHERDEVIL:順便說 一對多關係你用補習班教的方法去判斷很囧... 06/28 21:02
→ ARCHERDEVIL:一艘船可以停在多個港口 一個港口可以停很多船 06/28 21:02
→ ARCHERDEVIL:很直覺... 所以用直覺就好... 唸起來順的時候多半對 06/28 21:03
→ ARCHERDEVIL:別忘了資料庫往往都嘗試著表現真實世界的對應關係 06/28 21:03
→ malowda:PORT本身也是弱實体這樣做還是錯的也要吧用來決定PORT的另 06/28 21:03
→ malowda:外兩個KEY也拉進來 06/28 21:04
→ ARCHERDEVIL:post的弱實體關係與船無關 與國家、湖海那兩個有關系 06/28 21:05
→ ARCHERDEVIL:所以實際上拉去的鍵值應該是國家與湖海的主鍵 06/28 21:05
→ ARCHERDEVIL:但這樣他八成會亂掉XD 06/28 21:06
推 ARCHERDEVIL:我英文一直打錯是怎樣＝ ＝ 06/28 21:08
推 ARCHERDEVIL:是的，缺了，答案是錯的 06/28 21:43
→ ARCHERDEVIL:一般正常來說，資料結合是越簡單越好 06/28 21:43
→ ARCHERDEVIL:假設ship_at_port不建立表格 那船隻停靠港口的資料 06/28 21:44
推 asdd:答案應該是沒有錯的 你可以用兩個角度去看PORT_VISIT 06/28 21:44
→ ARCHERDEVIL:就會變得需要依靠port_visit來查詢 06/28 21:44
→ ARCHERDEVIL:當然你也可以這樣解決就是了... 06/28 21:45
→ asdd:一個是你說的 用三元關係 那麼轉出來就不是解答這樣 06/28 21:45
→ ARCHERDEVIL:只是這樣的結合會產生資料耦合過高問題XD 06/28 21:46
→ asdd:當然解答是用PORT_VISIT同時依附在SHIP跟PORT上面的角度去做 06/28 21:46
→ asdd:如同ARCHERDEVIL大所說的為了簡單所以解答不是用三元關係去解 06/28 21:47
推 asdd:拍謝 以上是針對PORT_VISIT 06/28 21:52
→ asdd:SHIP後面要再加上StateCountryName, PName 當作FK是沒錯的!! 06/28 21:52
推 ARCHERDEVIL:這種狀況不排除有，但應該不多。 06/28 22:13
→ ARCHERDEVIL:基本上port-visit裡的屬性可以放到ship_at_port裡面 06/28 22:14
→ ARCHERDEVIL:圖會這樣畫有兩個原因 06/28 22:14
→ ARCHERDEVIL:第一，降低資料耦合 提高資料安全 06/28 22:14
→ ARCHERDEVIL:第二 可能船待在港口的時間只能確定開始 結束不確定 06/28 22:15
→ ARCHERDEVIL:然後又不允許空值 06/28 22:15
→ ARCHERDEVIL:所以寫入的時候只好放到另外一個表裡面去維持完整性 06/28 22:16
→ ARCHERDEVIL:當然這是腦補就是了 06/28 22:16
→ ARCHERDEVIL:至於怎麼判斷... 我是靠腦補... 06/28 22:17
→ ARCHERDEVIL:或者是直接靠轉換規則... 06/28 22:17
→ ARCHERDEVIL:絕大部分的書應該都有寫 06/28 22:17
→ ARCHERDEVIL:多對多關係要轉一個表出來 弱實體一定相依於主實體 06/28 22:18
→ ARCHERDEVIL:然後加上一點想像力... 06/28 22:18
推 asdd:我想只能從語意上去判斷 SHIP_AT_PORT應該同時依附SHIP跟PORT 06/28 22:22
→ asdd:應該算合理 當然你這題可以用三元去解 解出來的主鍵也是一樣 06/28 22:23
→ ARCHERDEVIL:是說如果你不嫌麻煩 也可以用lossless join判斷 06/28 22:27
推 ARCHERDEVIL:就跟M N方式剛好相反。1:N關係應該是(0,*):(1,1) 06/28 22:56
→ ARCHERDEVIL:如果我沒記錯應該是這樣 06/28 22:56
推 caima:提外問一下 原po解答的SHIP表當中是否要再多一個Pname外鍵呢 06/28 22:57
→ caima:否則是不是就少了 判斷某船的home port關聯了 06/28 22:58
→ ARCHERDEVIL:賓果 06/28 22:58
推 caima:再藉這題問一下大家 1對多轉關聯有一種作法是跟多對多一樣 06/28 23:04
→ caima:就是直接把關係拉出來 成立一個關聯表 再放入1跟多方的主鍵 06/28 23:05
→ caima:你們寫這類題目時會這樣作嗎 06/28 23:05
→ lordfish62:我個人感覺，應該沒有必要這樣做吧，在原本的表加外鍵 06/28 23:17
→ lordfish62:跟多一個關聯表，感覺多一個表比較複雜 06/28 23:18
→ ARCHERDEVIL:這樣資料結構耦合就變高了 join起來效率很差 06/28 23:33
→ malowda:最好是把1方的KEY加入多方為外KEY就好，這樣反而會浪費空 06/28 23:58
→ malowda:間 06/28 23:58