2010-11-23 31 views
0

並感謝您的閱讀。數據庫設計 - 如何從不同的表中發佈2個主鍵

我正在做一個小狗店的DB。我有一張小狗桌子和一張桌子個人業主和公司所有者(公司擁有小狗)。一隻小狗可以有一個主人,主人可以擁有多隻小狗。處理這種情況的好方法是什麼?

  1. 我是否在小狗表中使用2只FK,其中一隻小狗由個體所有者擁有或者小狗爲公司所有。
  2. 你可以在boyce-codd常規表單中使用null外鍵嗎?

非常感謝

回答

0

你的模式是不明確的。難道這...

Tables: 
Puppies 
Individuals 
Corporations 

或本...

Tables: 
Puppies 
Owners 

我建議,第二個方案是一個更好的設計,讓您指定Owner.Type,而不是單獨的表每種類型的所有者。

0

創建表所有者和使用用戶PK的FK到小狗 創建2個表Individual_OwnerCorporate_Owner和使用用戶PK的PK以及FK到這兩個的。

它是澄清,爲不同類型的,將使用吸一個PK列這是所映射的條目[FK]爲所有者表所有者的

地方的任何類型的所有者的共同的元件所有者

+0

KM正在使用組合並且我正在使用實現。如果您使用的是DataWareHouse,那麼選擇Composition [因爲它使用星形/雪花模式,所以數據訪問/大小相關的優化不是一個難題],否則請去實現,這將減少數據的大小,但複雜的查詢可能是一個缺點。 – 2010-11-23 18:55:55

1

做這樣的事情:

Puppies 
PuppyID 
PuppyName 
PuppyType 
... 

Owners 
OwnerID 
OwnerName 
OwnerType 'I'=individual, 'C'=corporate 
.... 

PuppyOwners 
OwnerID 
PuppyID 
+0

您的模型對問題中提出的建議有什麼價值?你能詳細說明一下嗎? – 2010-11-23 19:07:13

0

看看在Party Data Model爲您的具體情況的模板。

您可以使用null外鍵在 BC範式

號3NF,BCNF,5NF等所有關係零點專門處理。因此,通過簡單地忽略空位出現的可能性,對普通形式進行一些近似或假設是一種普遍的做法(雖然非常值得懷疑)。

SQL中的可爲空的外鍵導致了一些問題和複雜性。進一步分解表格總是比較好,而不是使外鍵可以爲空。

0

你需要考慮你想用規範化實現什麼。不要爲了它而正常化。如果你讓你的fk爲空,那麼db將不會幫助你保持數據的一致性。
Think:

  • 如果兩個fk均爲空,該怎麼辦? (沒有店主?)
  • 如果兩個fk都有價值會怎麼樣? (兩個所有者?)

另一方面,@Puspendu建議的解決方案具有非常相同的問題,即使您沒有可爲空的外鍵。事實上,這種情況稍微複雜一些,因爲它允許多個所有者使用,而且使用起來更加複雜。

因此,我只想爲您建議的模型,它很簡單,做的工作,並且很容易被您的程序員理解。

0

個體所有者和企業主是gen-spec設計模式的經典案例。

在「泛化專業化關係建模」上進行搜索。你會看到一些關於如何設置三張表的文章。一個是業主,一個是個人業主,另一個是公司業主。所有三個使用相同的密鑰。專用表中的PK作爲FK加倍,引用所有者表中的相應行。

如果您習慣於對象建模,那麼gen-spec模式對您來說很熟悉。它由繼承來處理。乍一看,關係建模處理相同模式的方式可能看起來很愚蠢。但它非常好。

最後一個問題是,你想讓小狗和所有者之間的關係是多對一還是多對多。在許多情況下。你需要一張單獨的桌子來保持小狗 - 所有者的關係。否則,您可以將一個ownerID FK放入小狗表中,將一隻或多隻小狗連接到一個擁有者。

相關問題