1, я определил все функциональные зависимости здесь:
Вы не идентифицировали все FD (функциональные зависимости), которые хранятся. Первое: FD находятся между наборами атрибутов. Хотя бывает, что если мы ограничимся FD из набора атрибутов набором, содержащим один атрибут, то мы можем вывести, что хранятся в других FD. Таким образом, мы можем ограничить то, что мы подразумеваем под «всем», но вы должны знать, что вы говорите. Далее: вы определили некоторые FD, которые хранятся. Но все те, которые они подразумевают под аксиомами Армстронга, также верны. Это всегда означает некоторые тривиальные FD, например, {Sport Centre} -> Sport Center & {} -> {}. Хотя бывает, что мы можем вывести тривиальные FD, просто зная атрибуты. Итак, снова мы можем ограничить то, что мы подразумеваем под «всем», но вы должны знать, что вы говорите. Случается, что вы идентифицировали все нетривиальные FD с одним атрибутом в RHS. Но вы не оправдали, что те, кого вы нашли, держат или что вы нашли все те, которые держат.
Вам необходимо изучить алгоритмы и соответствующие определения для генерации описания набора всех имеющихся FD. Включая аксиомы Армстронга, понятие транзитивного замыкания FD и понятие канонического покрытия FD для краткой характеристики замыкания.
2, я идентифицировал все ключи-кандидаты:
Если предположить, что {{Sport Centre} -> Sport} является каноническим прикрытием, единственным CK является {Name, Sport Center}.
Вам необходимо изучить алгоритмы и соответствующие определения для нахождения всех CK.
Я думал, что в BCNF таблица должна иметь более 1 ключа-кандидата
Это неправильно. Похоже, вы пытаетесь вспомнить что-то вроде «3NF & not BCNF подразумевает более 1 CK» или «3NF & 1 CK подразумевает BCNF», что соответствует действительности. Но это не означает, что BCNF подразумевает более 1 CK или, что эквивалентно, 1 CK подразумевает не BCNF.
Вам необходимо изучить определение BCNF и другие соответствующие определения.
Я не уверен, как передать это в BCNF.
Мы всегда можем разложить до конструкции BCNF. Большинство определений BCNF говорят, что это когда не существует FD определенной формы. Бывает, что мы можем добраться до BCNF путем многократного разложения без потерь, чтобы устранить проблему FD. Тем не менее, это может излишне не "сохранять" FDs. Таким образом, мы обычно сначала разлагаем с сохранением до 3NF / EKNF, что всегда может сохранить FD. Несмотря на то, что при переходе на BCNF может не сохраниться FD, даже несмотря на то, что была прямая декомпозиция с сохранением FD.
Вам необходимо выучить алгоритмы и соответствующие определения для разложения на данную NF. Включая понятия разложения без потерь и сохранения FD.
Но я также понимаю, что в 3NF (до BCNF) каждый атрибут должен зависеть от полного первичного ключа, и мое разбиение нарушает это правило.
Для нормализации до данной НФ необязательно проходить более низкие НФ. В общем, это может исключить возникновение хороших окончательных проектов NF.
Также «быть в 3NF [...] каждый атрибут должен зависеть от полного первичного ключа» не правильно. Вам нужно запомнить определения - необходимые и достаточные условия. И PK (первичные ключи) не имеют значения для нормализации, CK делают. Хотя мы можем исследовать особый случай только одного CK, который мы могли бы затем назвать PK. Также «мое разделение нарушает это правило» не имеет смысла. Необходимым условием для нахождения таблицы в некоторой NF не является правило о том, как разложить ее на какую-либо другую NF.
Вам нужно найти (хороший) учебник и изучить его определения и алгоритмы нормализации. (Десятки учебников бесплатны в режиме онлайн, а также слайды и курсы.) Если вы застряли после него, сделайте ссылку и процитируйте его, покажите свою работу после нее и объясните, как вы застряли.