2013-04-04 104 views
0

將單個表拆分爲多個時,通常情況下外鍵引用的是來自不同行的主鍵?
例如
源表中的數據是
跨行的fk pk關係

id1 id2 name1 name2 
10 1 a10  b1 
9 8 a11  b2 
8 3 a12  b3 
3 9 a14  b4 
1 10 a15  b5 

所以,當我創建主鍵表作爲

create table pk_table (id1 integer primary key , name1 varchar2(20)) 

create table fk_table (id2 integer, name2 varchar2(20) foreign key(id2) references pk_table(id1)) 

所以,當我分裂數據外鍵表按表格:

pk_table數據是:

id1 name1 
10 a10 
9 a11 
8 a12 
3 a14 
1 a15 

鍵和外鍵數據是

id2 name2 
1 b1 
8 b2 
3 b3 
9 b4 
10 b5 

所以,你見過這些情況下,我們沒有FK指同一行PK源表格?

編輯:更新表中的數據,使之更加有效。

+1

請仔細閱讀Korth的書「數據庫系統概念」。還可以在接下來的幾天閱讀您在數據庫中發現和理解的任何內容。這不是一個真正的問題。請確定你的問題是什麼。 – Rachcha 2013-04-04 13:36:57

+0

'1,b1'絕對**應該存在於'fk_table'中。如果原始表中的記錄不存在,您還沒有正確轉換記錄。如果沒有,10,a10連接到了什麼?另外,在創建表'fk_table'時,您仍然應該將'id2'識別爲主鍵,因爲它是該表的主鍵。 – mcalex 2013-04-04 13:39:24

+0

如果FK沒有引用任何PK,那麼它不是FK本身。 – Santhosh 2013-04-04 13:42:57

回答

0

分割表格的方式不符合標準化標準。源表中的字段之間沒有(可見的)函數依賴關係。其次,你的表甚至不共享一個PK-FK關係。你的問題是沒有意義的,因爲你假設你用PK-FK分割表是不正確的。

+0

我不正常我的表。我從一個現有的表格創建多個表格。所以問題是有效的 – peeyush 2013-04-04 13:58:52

+0

我的回答是正確的。顯然你不瞭解PK-FK概念,這本身不是問題,但你的思想是封閉的,以修改你的(破碎的)假設。如果你聲稱你沒有正常化,那麼你不應該問關於丟失的PK-FK行。如果您想進步,請在每張表中爲初學者確定PK。 – koriander 2013-04-04 14:06:31

+0

@ koriander +1是正確的(並且敲除那些不應該的downvote),但是我可能會輕輕地帶着一些諷刺的意味,顯然你不明白對於明顯入門級別的問題的高級答案可能不會導致滿意querent的觀點? – mcalex 2013-04-04 16:57:44

2

首先回答你問的問題:

是的,你看到在不同的行數據時,你分手了一個表分成兩個(或更多)。這是事情應該如何成爲™。表中原始數據中的哪一行或新數據是無關緊要的。行號有什麼也沒有與您的數據,這就是它如何顯示自己。例如,你可以創建新的pk_table這樣的:

id1 name1 
1 a15 
3 a14 
8 a12 
9 a11 
10 a10 

,它不會有任何區別。

其次,這與其他人試圖告訴你交易。您將原始表格轉換爲兩個輔助表格的方式不會爲您提供數據庫。您爲創建fk_table提供的語法a)沒有意義,並且b)不起作用。

分割表格時需要做的事情是在fk_table中創建一個新列,其中包含pk_table的主鍵。該額外的列是告知數據庫fk_table中的哪條記錄匹配pk_table中的哪條記錄的鏈接。回到原來的問題,這個鏈接就是爲什麼舊的記錄或新記錄存在哪一行沒有區別的原因。重要的是fk_table中的外鍵列。

本作的實際意義上說,新表應該多一點這樣的:

pk_table - id1是主鍵:

id1 name1 
10 a10 
9 a11 
8 a12 
3 a14 
1 a15 

fk_table - id2是主鍵,fk_id1是外鍵pk_table

id2 name2 fk_id1 
1 b1  10 
8 b2  9 
3 b3  8 
9 b4  3 
10 b5  1 

採用這種結構可以運行日查詢at將正確鏈接每個pk_table記錄到正確的fk_table記錄