函數依賴和many-to-many關係

-1

A book_id 
B book_title 
C book_isbn 
D book_year 
G reader_id 
H reader_name 
I reader_birthday 
L reader_phone 
M reader_email 
N reader_registration_date 
O loan_id 
P loan_date_issued 
S loan_date_for_return 
T loan_date_returned 
U author_id 
V author_name 
W category_id 
X category_name

與這些相關：

A->BCD 
G->HILMN 
O->AGPST 
U->AV 
W->AX

所有的計算後，我得到這個：

R1 = ABCD  k1 = {A} Books 
R2 = GHILMN  k2 = {G} Readers 
R3 = AGOPST  k3 = {O} Loans 
R4 = AUV  k4 = {U} Authors 
R5 = AWX  k5 = {W} Category 
R6 = OUW  k6 = {OUW} {Don’t know}

但這並不好，因爲table Book與表類有多對多的關係，書和作者表也是如此。我被卡住了。我想我從一開始就做錯了什麼，之後一切都出錯了。也許你有這樣的例子。

來源

2017-06-08 Umanet Alex

我認爲函數依賴關係（FD）W-> AX是不好的;它表示類別ID控制書籍ID和類別名稱。這是沒有意義的。 W-> X是完全理智的函數依賴。 A-> W是有意義的;書籍處於由類別ID標識的特定類別中。類似地，U-> AV FD是不好的; U-> V是完全理智的函數依賴，但是A-> U更接近合理。請注意，一本書可能有多個作者，因此您不會將A-> U依賴與A-> BCD相結合。一本書也可能有多個類別;你不會把A-> W與A-> BCD結合起來。 –

R6（OUW）沒有任何意義：爲什麼貸款ID，作者ID和類別ID會識別出有用的東西？我注意到書籍ID（A）是一個含糊的術語。目前還不清楚它是否描述了特定書籍的特定副本，或者是出版商創建的書籍的所有副本。一個圖書館可能有特定書籍的特定版本的多個副本（現在，這本書的副本將有一個由圖書館指定的唯一編號，以便它可以被跟蹤），但是不清楚該圖表有這個想法（書桌會有很多重複）。 –

所以，我認爲你需要檢查依賴關係。他們是你創造的，還是他們被老師強加給你的？如果他們被強加給你，你應該和你的老師討論爲什麼W-> AX和U-AV依賴關係是由問題中關係模式建模的現實的準確表示。您可能需要考慮一本書的真實含義 - Book ID是否真的是一個ISBN（每個版本的每個副本共享相同的ISBN），還是它是一個「圖書館編號」，每本書的編號都不相同它可以被單獨追蹤。 –

讓我們將「類別」視爲「書籍」的「封面」 - 作爲對象或「書籍」的「副本」 - 爲文本，其中「書籍」與其獨特的一些O值相關聯。那麼W - > A更直觀。（其它函數依賴似乎不直觀了。）

通用關係

每個表格（基本或查詢結果）具有謂詞（報表模板），該行使得要麼成爲真正的陳述（和雲在表）或虛假陳述（並保留）。我們說這個表格表示以謂詞爲特徵的商業關係/關聯。這裏猜測一個謂詞是：

book A titled B with isbn C published in year D 
    was borrowed by a reader G named H born on date I 
     with phone# L and email address M registered on date N 
    in loan O issued on date P due on date S 
    and either it was returned on date T or it is not yet returned and T=NULL 
    and it was written by author U named V 
    and the library has A in cover/copy W named X

您似乎在使用「通用關係」分解設計/規範化技術。但是這隻適用於你的一個表格滿足「普遍關係假設」的情況。這就是說，你所有的情況都可以通過一個謂詞和一個表來描述。

例如：假設您可以擁有尚未借用的圖書或尚未借閱的用戶。然後上面的示例謂詞/表格無法記錄它們。所以分解將無法記錄它們。所以你會從一個不同的謂詞/表開始。（通常爲多個）。

例如：如果最後一行是and A was borrowed in cover/copy W named X那麼表格在給定情況下可以保存與以前不同的值。但取決於借貸政策，該表可以滿足同一組FD。

什麼是該表的謂詞？如果這不是你猜到的，你的期望可能不會被滿足。

你分解

讓我們忽略了實體的屬性。

-- O is G borrowing A by U with W 

A book_id 
G reader_id 
O loan_id 
U author_id 
W cover/copy_id 

O->AG 
U->A 
W->A

唯一的CK是OUW。這是對BCNF的明顯分解。它同意你的版本。

-- O is G borrowing A by someone with some cover/copy 
-- O is G borrowing A 
Loan(O,G,A) 

-- some loan is somebody borrowing A by U with some cover/copy 
-- the book of U is A 
The_book_of_author(U,A) 

-- some loan is somebody borrowing A by someone with W 
-- the book of W is A 
The_book_of_cover/copy(W,A) 

-- O is somebody borrowing some book by U with W 
-- O is the borrowing of the book of U and W 
Author_and_cover/copy(O,U,W)

原始關係的組件的連接：

--  O is G borrowing A 
    and the book of U is A 
    and the book of W is A 
    and O is the borrowing of the book of U and W 
-- O is G borrowing A by U with W 
Loan JOIN The_book_of_author JOIN The_book_of_cover/copy JOIN Author_and_cover/copy

因爲桌上的書有很多與表類別一對多的關係，這是不好的，所以做圖書和作者表

不幸的是，這是無法理解的。所以我不能說出你的意思是說錯了。

數據庫設計

如果產生這樣的設計你自己，你應該使用一些參考信息建模方法。這將指導您確定合理的謂詞/表格，以記錄根據業務規則可能出現的所有情況。

適用於可能出現什麼情況的謂詞決定了可能出現的狀態。那些有效的狀態通過約束條件來描述 - FD（功能依賴性），JD（聯合依賴性），CK（候選鍵），FK（外鍵）（也就是與上述不同的意義上的「關係」）等。

方法的一部分是將臨時表正常化爲其他方法。這使用FDsDDDJ通過適當的算法分解成適當的NF（正常形式）。一個好的方法總是歸一化爲5NF。（即使你爲了實現的原因而將其非規範化。）

來源

2017-06-09 06:39:22 philipxy

函數依賴和many-to-many關係

回答

相關問題