Выявление функциональных зависимостей - PullRequest
Новая
       14

Выявление функциональных зависимостей

1 голос
/ 25 апреля 2011

У меня есть следующая схема в первой нормальной форме (1NF), то есть все ячейки содержат атомарные значения: 

ClientRental (clientNo, propertyNo, clientName, propertyAddress, rent, 
              rentStart, rentFinish, ownerNo, ownerName)

Общая схема такова, что клиенты могут арендовать многие свойства у разрешающих агентов.У каждой собственности есть один владелец.Для тех, кто знаком с книгой, это пример, извлеченный из систем баз данных Коннолли и Беггом.

Я пытаюсь определить функциональные зависимости -> ключи-кандидаты, частичные зависимости и транзитивные зависимости и т. Д.

Я слежу за учебником, но там некоторые предложения плохо объяснены.Может ли кто-нибудь объяснить мне, верны ли мои предложения: 

FD1 -> clientNo -> clientName
FD2 -> propertyNo -> propertyAddress, rent, ownerNo, ownerName
FD3 -> ownerNo -> ownerName

Определенно есть и другие функциональные зависимости, которые я пропустил, но отсутствие опыта не позволяет мне их идентифицировать.Очевидно, что я не могу определить частичные зависимости, потому что я еще не выделил первичный ключ для вышеуказанного отношения / схемы.

Может ли кто-нибудь помочь мне определить другие функциональные зависимости ... Мне не ясно, что также определяет что-то как транзитивную зависимость ...

Пожалуйста, дайте мне знать, если что-то требует большего разъяснения..

РЕДАКТИРОВАТЬ Для 3NF:

Мои отношения 3NF: 

Client {clientNo(PK), clientName}
Owner {ownerNo(PK), ownerName}
Property {propertyNo (PK), propertyAddress, rent}
ClientRental {clientNo(PK), propertyNo(PK), rentStart, rentFinish, ownerNo(FK)}

Ответы [ 2 ]

5 голосов
/ 25 апреля 2011

Чтобы повысить до 2NF, определите неключевые атрибуты, которые зависят только от части ключа-кандидата, а не от всех. Начните с определения того, зависят ли какие-либо атрибуты из набора {clientName, propertyAddress, rent, rentStart, rentFinish, ownerNo, ownerName} только от clientNo или propertyNo.

Теперь одна из проблем, с которыми вы столкнетесь в сети, заключается в том, что функциональные зависимости на самом деле определяются значениями, а не именами столбцов. Без репрезентативных значений выборки мы должны немного угадать Но, вероятно, 

clientNo -> clientName
propertyNo -> propertyAddress, ownerNo, ownerName

Таким образом, мы можем разложить ClientRental таким образом. 

Relation "clients"         { (clientNo), clientName}
Relation "properties"      { (propertyNo), propertyAddress, ownerNo, ownerName}
Relation "ClientRental"    { (clientNo, propertyNo), rent, rentStart, rentFinish}

В США неправда, что недвижимость -> аренда. (Ваш FD2. Если вы не имеете в виду арендная плата , вы имеете в виду запрашиваемую цену.) В США арендная плата определяет арендную плату, и юридически в аренду должны быть включены адрес и арендатор. (На самом деле все жильцы. Но это другая проблема.)

Поскольку "client" и "properties" имеют только один столбец в ключах-кандидатах, они должны быть в 2NF. Я думаю, что все эти три отношения находятся в 2NF.

Можете ли вы справиться с улучшением до 3NF (без учета транзитивных зависимостей) самостоятельно?

Позже. , .

Да, здесь есть как минимум одна транзитивная зависимость: propertyNo -> ownerNo -> ownerName. Удалите эту переходную зависимость, введя отношение владельцев. 

Relation "clients"         { (clientNo), clientName}
Relation "properties"      { (propertyNo), propertyAddress, ownerNo}
Relation "owners"          { (ownerNo), ownerName}
Relation "ClientRental"    { (clientNo, propertyNo), rent, rentStart, rentFinish}

Отношения "клиенты", "свойства" и "владельцы" находятся в 3NF. В реальном мире свойства часто принадлежат нескольким людям или предприятиям, а также часто сдаются в аренду нескольким людям или предприятиям. Но такого рода проблемы не имеют ничего общего с нормализацией. (Пока вы не решите поддержать эту реальную ситуацию).

Что-нибудь еще?

2 голосов
/ 25 апреля 2011

Вероятно, следует выделить 4 отношения:

  • Клиент
  • Владелец
  • Недвижимость
  • аренда

Тогда, учитывая атрибуты в ClientRental, мы можем рассуждать:

  • Клиент: {clientNo} ⟶ {clientName}
  • Владелец: {ownerNo} ⟶ {ownerName}
  • Свойство: {propertyNo} ⟶ {propertyAddress, ownerNo}
  • Аренда: {rentStart, propertyNo} ⟶ {clientNo, propertyNo, rentFinish, аренда}

Для данного свойства дата начала уникальна, поэтому комбинация может предоставить ключ (определитель); Вы также можете утверждать, что rentFinish и propertyNo предоставят ключ.

Рента, вероятно, может быть атрибутом как имущества, так и аренды; в первом - запрашиваемая рента, во втором - полученная рента. Более реалистичная запрашиваемая арендная плата вполне может варьироваться в зависимости от времени года - недвижимость может быть более ценной в летние месяцы, чем в зимние месяцы.

Для переходных зависимостей рассмотрите исходное отношение ClientRental. PropertyNo идентифицирует ownerNo (и ownerName), поэтому там скрывается транзитивная зависимость.

...