函数依赖和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关系

回答

相关问题