database - 如何将模式规范化为 BCNF

Question

我在规范化方面遇到了一些问题。我有一个架构 REPAYMENT，它看起来像这样:

现在，根据我收集到的，架构中的功能依赖项是

{borrower_id} --> {name, address, request_date, loan_amount}

{request_date} --> {repayment_date, loan_amount}

{loan_amount] --> {repayment_amount}

(如果我错了请纠正我？)

我应该将架构规范化为 BCNF，但我有点困惑。候选键是request_date和borrower_id吗？

可用于登记小额贷款还款信息。借款人及其姓名和地址由唯一的 borrower_id 标识。借款人可以同时拥有多笔贷款，但每笔贷款(由 loan_amount、repayment_date 和 repayment_amount 指定)都有不同的请求日期。因此，可以使用借款人 ID 和贷款请求日期来识别贷款。借款人可以在同一天偿还多笔(不同的)贷款，但每笔贷款只能偿还一次(一次、一笔金额)。有一个系统可以针对每个请求日期和贷款金额确定还款日期和要偿还的金额。申请的贷款金额和偿还的金额不同，因为有适用的利率。

Answer 1

根据候选键的定义:

In the relational model of databases, a candidate key of a relation is a minimal superkey for that relation; that is, a set of attributes such that:

1. The relation does not have two distinct tuples (i.e. rows or records in common database language) with the same values for these attributes (which means that the set of attributes is a superkey)

2. There is no proper subset of these attributes for which (1) holds (which means that the set is minimal).

现在你的问题:

Is the candidate key request_date and borrower_id?

它是一个 super key ，但不是最小的。以下是我们如何计算候选键。

哪个属性只出现在左侧，考虑所有的 F 。 D?

ITS borrower_id。这意味着它必须是此给定模式的每个键的一部分。现在让我们计算它的闭包。

因为 {borrower_id} --> {name, address, request_date, loan_amount}:

closure(borrower_id) = borrower_id, name, address, request_date, loan_amount.

因为 {request_date} --> {repayment_date, loan_amount} 和 closure(borrower_id) 有 request_date，这意味着

closure(borrower_id) = borrower_id, name, address, request_date, loan_amount, repayment_date

最后因为 {loan_amount] --> {repayment_amount} 和 closure(borrower_id) 有 loan_amount，这意味着

closure(borrower_id) = borrower_id, name, address, request_date, loan_amount, repayment_date, repayment_amount

因为 borrower_id 的闭包包含所有属性，borrower_id 是一个键，因为它是最小的，所以它确实是候选键并且唯一的。

现在让我们将模式分解为BCNF。算法是:

Given a schema R.

1. Compute keys for R.

2. Repeat until all relations are in BCNF.

   • Pick any R' having a F.D A --> B that violates BCNF.
   • Decompose R' into R1(A,B) and R2(A,Rest of attributes).
   • Compute F.D's for R1 and R2.
   • Compute keys for R1 and R2.

由于 {request_date} --> {repayment_date, loan_amount} 和 request_date 不是键，它违反了 BCNF，因此我们将模式拆分为两个关系:

1. R1(请求日期、还款日期、贷款金额)

2. R2(borrower_id,name,address,request_date,repayment_amount)

显然 R1 在 BCNF 中。但是 R2 在 BCNF 中是 NOT ，因为我们错过了下面的 F.D.这是:

address --> name

而且我们知道地址不是关键，所以我们将 R2 进一步拆分为:

1. R3(borrower_id,address,request_date,repayment_amount)

2. R4(地址,姓名)

现在，显然 R3 和 R4 都在 BCNF 中。如果我们不进一步拆分 R2，我们最终会为该人获得的每笔贷款存储相同的地址和姓名组合，这是冗余的。