wiki:Normalization

Context Navigation

Version 10 (modified by 211561, 2 weeks ago) ( diff )
--

Функционални зависности

Дадена е релационата шема за базата на податоци која ја креиравме, која може да се претстави во една релација со сите атрибути од сите релации споени заедно. Секако, дупликатите ќе бидат отстранети при тоа што ова не претставува проблем. Нека R биде релацијата опишана како што следи:

R(
  id, name, email, password, is_admin,
  country, registration_number, tax_code, contact_person, phone_number,
  billing_address, shipping_address, address, producer_id, description,
  hs_code, price, unit_of_measure, batch_code, production_date, expiration_date,
  net_weight, gross_weight, units_per_batch, transport_id, departure_point,
  arrival_point, estimated_departure_date, estimated_arrival_date, incoterm,
  insurance_conditions, status, estimated_delivery_date, buyer_id, receiver_id,
  amount, currency, due_date, exchange_rate, payment_date, payment_method,
  payment_status, quantity, price_per_unit, total_price, created_at, updated_at
)

Иницијални функционални зависности

id → name, email, password, is_admin

producer_id → address, country, phone_number, email

product_id → name, description, hs_code, price, unit_of_measure

batch_id → batch_code, production_date, expiration_date, net_weight, gross_weight, units_per_batch

transport_id → departure_point, arrival_point, estimated_departure_date, estimated_arrival_date, incoterm, insurance_conditions

order_id → date, status, estimated_delivery_date, buyer_id, receiver_id, transport_id

payment_id → amount, currency, due_date, exchange_rate, payment_date, payment_method, payment_status, order_id

order_batch_id → quantity, price_per_unit, total_price, created_at, updated_at, order_id, batch_id

Изведени функционални зависности кои не се присутни во иницијалниот список

Транзитивни

order_id → buyer_id, receiver_id, transport_id (од FD 6)

Изведено:

order_id → status, estimated_delivery_date

Анализа на функционални зависности користејќи LHS/RHS класификација

Ова е методот за анализа на функционалните зависности преку групирање на атрибутите во три категории

LHS — атрибути кои се појавуваат само на левата страна (како детерминанти) RHS — атрибути кои се појавуваат само на десната страна (како зависности) LHS + RHS — атрибути кои се појавуваат и на двете страни на зависностите

Оваа техника помага при разбирање на улогата на атрибутите во одредувањето на другите, и е корисна за нормализација и откривање на кандидатни клучеви.

Класификација на атрибути

Само LHS

Атрибути кои се појавуваат само како детерминанти:

id, producer_id, product_id, batch_id, transport_id, order_id, payment_id, order_batch_id

Овие атрибути се потенцијални кандидатни клучеви, бидејќи тие го одредуваат другите атрибути и самите не се одредени од ништо друго.

Само RHS

Атрибути кои се појавуваат само како зависности:

name, email, password, is_admin, country, registration_number, tax_code,
contact_person, phone_number, billing_address, shipping_address, description,
hs_code, price, unit_of_measure, batch_code, production_date, expiration_date,
net_weight, gross_weight, units_per_batch, departure_point, arrival_point,
estimated_departure_date, estimated_arrival_date, incoterm,
insurance_conditions, status, estimated_delivery_date, currency, due_date,
exchange_rate, payment_date, payment_method, payment_status, quantity,
price_per_unit, total_price, created_at, updated_at

Овие се неклучни атрибути, кои мора да бидат целосно и неконфузно зависни од кандидатните клучеви во повисоки нормални форми (2NF, 3NF).

LHS + RHS

Атрибути кои се појавуваат и на левата и на десната страна на функционалните зависности:

product_id, batch_id, transport_id, order_id

Овие атрибути можат да воведат некои транзитивни зависности и проблеми.

LHS Транзитивен closure

Нека X+ = {order_id, transport_id, payment_id}

Пресметување на атрибутната затвореност за сетот X ќе даде:

X+ = {
  order_id, transport_id, payment_id,
  name, email, password, is_admin, country, registration_number,
  tax_code, contact_person, phone_number, billing_address, shipping_address,
  description, hs_code, price, unit_of_measure, batch_code, production_date,
  expiration_date, net_weight, gross_weight, units_per_batch,
  departure_point, arrival_point, estimated_departure_date, estimated_arrival_date,
  incoterm, insurance_conditions, status, estimated_delivery_date, currency,
  due_date, exchange_rate, payment_date, payment_method, payment_status,
  quantity, price_per_unit, total_price, created_at, updated_at
}

Оваа релација не го прикажува сетот на атрибути X како кандидатен клуч, но ако додадеме product_id и batch_id за да формираме сет {{{Y = {order_id, transport_id, payment_id, product_id, batch_id}}}}, ќе добиеме следната атрибутна затвореност:

Y+ = {
  order_id, transport_id, payment_id, product_id, batch_id,
  name, email, password, is_admin, country, registration_number,
  tax_code, contact_person, phone_number, billing_address, shipping_address,
  description, hs_code, price, unit_of_measure, batch_code, production_date,
  expiration_date, net_weight, gross_weight, units_per_batch,
  departure_point, arrival_point, estimated_departure_date, estimated_arrival_date,
  incoterm, insurance_conditions, status, estimated_delivery_date, currency,
  due_date, exchange_rate, payment_date, payment_method, payment_status,
  quantity, price_per_unit, total_price, created_at, updated_at
}

Додавањето само на product_id или batch_id нема да даде кандидатен клуч, бидејќи ќе недостигаат информации за производот или партијата. Сето ова дава сите атрибути. Затоа, сетот на атрибути Y може да се третира како кандидатен клуч и се прогласува како примарен клуч овде.

Нормализирање

Тековна нормална форма

Дадени функционални зависности, релацијата R веќе е во 1NF согласно со дефиницијата, бидејќи нема мултивредносни атрибути.

Базата на податоци е имплементирана со SQL DDL, што значи дека релационата шема е внатрешно во 1NF

Заклучуваме дека R ја задоволува 1NF. Но според дефиницијата на 2NF, релација е во 2NF ако:

Таа веќе е во прва нормална форма 1NF
Нема парцијални зависности на никакви непријатни атрибути (определени атрибути) од стриктен подсет на било кој кандидатен клуч

Но релацијата не е во 2NF поради тоа што имаме јасни парцијални зависности. Контрапример е batch_id → batch_code, production_date - но има и повеќе.

Декомпозиција на `R` во нови релации за да се постигне `BCNF`

Започнуваме со раздвојување на R групирајќи ги детерминантите на ЛС со ДС, за да добиеме следниве релации:

`USER`

id → name, email, password, is_admin

R1(id, name, email, password, is_admin)

`CLIENT`

id → name, country, registration_number, tax_code, contact_person, phone_number, billing_address, shipping_address

R2(id, name, country, registration_number, tax_code, contact_person, phone_number, billing_address, shipping_address)

`PRODUCER`

producer_id → address, country, phone_number, email

R3(producer_id, address, country, phone_number, email)

`PRODUCT`

product_id → name, description, hs_code, price, unit_of_measure

R4(product_id, name, description, hs_code, price, unit_of_measure)

`BATCH`

batch_id → batch_code, production_date, expiration_date, net_weight, gross_weight, units_per_batch

R5(batch_id, batch_code, production_date, expiration_date, net_weight, gross_weight, units_per_batch)

`TRANSPORT`

transport_id → departure_point, arrival_point, estimated_departure_date, estimated_arrival_date, incoterm, insurance_conditions

R6(transport_id, departure_point, arrival_point, estimated_departure_date, estimated_arrival_date, incoterm, insurance_conditions)

`ORDER`

order_id → date, status, estimated_delivery_date, buyer_id, receiver_id, transport_id

R7(order_id, date, status, estimated_delivery_date, buyer_id, receiver_id, transport_id)

`PAYMENT`

payment_id → amount, currency, due_date, exchange_rate, payment_date, payment_method, payment_status, order_id

R8(payment_id, amount, currency, due_date, exchange_rate, payment_date, payment_method, payment_status, order_id)

`ORDER_BATCHES`

order_batch_id → quantity, price_per_unit, total_price, created_at, updated_at, order_id, batch_id

R9(order_batch_id, quantity, price_per_unit, total_price, created_at, updated_at, order_id, batch_id)

Проверка на нормалната форма после првата декомпозиција

`USER`

Атрибути

id, name, email, password, is_admin

Функционални зависности

id → name, email, password, is_admin

Кандидатен клуч: id

Оваа релација е во 2NF бидејќи не постојат парцијални зависности.

За постигнување 3NF, не се јавуваат транзитивни зависности, така да оваа релација е во 3NF.

Исто така, бидејќи id е кандидатен клуч, релацијата е и во BCNF.

`CLIENT`

Атрибути

id, name, country, registration_number, tax_code, contact_person, phone_number, billing_address, shipping_address

Функционални зависности

id → name, country, registration_number, tax_code, contact_person, phone_number, billing_address, shipping_address

Кандидатен клуч id

Оваа релација е во 2NF и не се појавуваат транзитивни зависности, така да е во 3NF и во BCNF.

`PRODUCER`

Атрибути

producer_id, address, country, phone_number, email

Функционални зависности

producer_id → address, country, phone_number, email

Кандидатен клуч producer_id

И оваа релација е во 2NF, 3NF и BCNF.

`PRODUCT`

Атрибути

product_id, name, description, hs_code, price, unit_of_measure

Функционални зависности

product_id → name, description, hs_code, price, unit_of_measure

Кандидатен клуч product_id

Оваа релација е во 2NF, 3NF и BCNF.

`BATCH`

Атрибути

batch_id, batch_code, production_date, expiration_date, net_weight, gross_weight, units_per_batch

Функционални зависности

batch_id → batch_code, production_date, expiration_date, net_weight, gross_weight, units_per_batch

Кандидатен клуч batch_id

Релацијата е во 2NF, 3NF и BCNF.

`TRANSPORT`

Атрибути

transport_id, departure_point, arrival_point, estimated_departure_date, estimated_arrival_date, incoterm, insurance_conditions

Функционални зависности

transport_id → departure_point, arrival_point, estimated_departure_date, estimated_arrival_date, incoterm, insurance_conditions

Кандидатен клуч transport_id

Оваа релација е во 2NF, 3NF и BCNF.

`ORDER`

Атрибути

order_id, date, status, estimated_delivery_date, buyer_id, receiver_id, transport_id

Функционални зависности

order_id → date, status, estimated_delivery_date, buyer_id, receiver_id, transport_id

Кандидатен клуч order_id

Релацијата е во 2NF, 3NF и BCNF.

`PAYMENT`

Атрибути

payment_id, amount, currency, due_date, exchange_rate, payment_date, payment_method, payment_status, order_id

Функционални зависности

payment_id → amount, currency, due_date, exchange_rate, payment_date, payment_method, payment_status, order_id

Кандидатен клуч payment_id

Релацијата е во 2NF, 3NF и BCNF.

`ORDER_BATCHES`

Атрибути

order_batch_id, quantity, price_per_unit, total_price, created_at, updated_at, order_id, batch_id

Функционални зависности

order_batch_id → quantity, price_per_unit, total_price, created_at, updated_at, order_id, batch_id

Кандидатен клуч order_batch_id

Релацијата е во 2NF, 3NF и BCNF.

Note: See TracWiki for help on using the wiki.

Download in other formats:

Plain Text

Context Navigation

Функционални зависности

Иницијални функционални зависности

Изведени функционални зависности кои не се присутни во иницијалниот список

Транзитивни

Анализа на функционални зависности користејќи LHS/RHS класификација

Класификација на атрибути

Само LHS

Само RHS

LHS + RHS

LHS Транзитивен closure

Нормализирање

Тековна нормална форма

Декомпозиција на R во нови релации за да се постигне BCNF

USER

CLIENT

PRODUCER

PRODUCT

BATCH

TRANSPORT

ORDER

PAYMENT

ORDER_BATCHES

Проверка на нормалната форма после првата декомпозиција

USER

CLIENT

PRODUCER

PRODUCT

BATCH

TRANSPORT

ORDER

PAYMENT

ORDER_BATCHES

Download in other formats:

Декомпозиција на `R` во нови релации за да се постигне `BCNF`

`USER`

`CLIENT`

`PRODUCER`

`PRODUCT`

`BATCH`

`TRANSPORT`

`ORDER`

`PAYMENT`

`ORDER_BATCHES`

`USER`

`CLIENT`

`PRODUCER`

`PRODUCT`

`BATCH`

`TRANSPORT`

`ORDER`

`PAYMENT`

`ORDER_BATCHES`