MySQL - переход от 1-й нормальной формы к 2-й и 3-й нормальной формам

Question

Этот вопрос напрямую связан с предыдущей темой "MySQL - перейти от плоской таблицы к первой нормальной форме" (http://bit.ly/9pvS0Y) - и, как я сейчас задаю вопрос о переходе на вторую и третью нормальные формы Я решил, что лучше всего начать новую тему.

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

Я хотел бы знать, как перенести это во вторую и третью формы, любые указания относительно того, как на мои таблицы будут влиять правила 2NF и 3NF, были бы действительно полезны, спасибо.

Отношения

- Активность и местоположение отношение = один ко многим - у одного действия может быть одно местоположение, у местоположения может быть много действий (LocationID как FK в Activity)

- Активность и неделя отношение = один ко многим - у одной активности может быть одна неделя, у недели может быть много действий (WeekID как FK в Деятельности)

- Пользователь и действие = много ко многим - у одного пользователя может быть много действий, у одного действия может быть много пользователей

User Table - UserID PK
+------------+-----------+
| UserID     | Username  |
+------------+-----------+
|            |           |
+------------+-----------+


Activity Table - ActivityID PK / WeekID FK / LocationID FK
+------------+-----------+------------+-----------+------------+-------------+-----------+
| ActivityID | UserID    | WeekID     | Day       | Minutes    | LocationID  |   Miles   |
+------------+-----------+------------+-----------+------------+-------------+-----------+
|            |           |            |           |            |             |           | 
+------------+-----------+------------+-----------+------------+-------------+-----------+


Location Table - LocationID PK
+------------+---------------+
| LocationID | Location_Name |
+------------+---------------+
|            |               |
+------------+---------------+


Weeks Table - Week ID PK
+------------+-----------+
|WeekID      | Week_No   |             
+------------+-----------+
|            |           |
+------------+-----------+


User_Activity Table 
+------------+---------------+
| UserID     | ActivityID    |
+------------+---------------+
|            |               |
+------------+---------------+

Answer 1

Если это не академическое упражнение, я предлагаю вам не «переходить» через нормальные формы. Официальное название для этого процесса: Нормализация по разложению . Однако в большинстве случаев это не очень практично и, как правило, совершенно не нужно.

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

Answer 2

Не уверен, для какой цели вы используете таблицу User_Activity, поскольку в вашей таблице активности уже определены оба столбца. В противном случае - этот дизайн уже идет в 3-й нормальной форме.

Answer 3

Если «Week_no» означает «номер недели», переместите «Week_no» в «Activity» и удалите таблицу «Weeks».

Answer 4

Как говорит russjudge, я не вижу цели таблицы User_Activity.

При нормализации обычно рекомендуется использовать натуральные ключи везде, где это возможно. Таким образом, я также не вижу смысла таблицы Weeks - почему бы просто не использовать Week_No? (Возможное исключение здесь может быть, если вы хотите установить «недели» с разным количеством дней в них - в этом случае вы также можете включить даты начала и окончания в таблицу недель. не вижу смысла.)

На самом деле, я бы пошел дальше и заменил бы неделю и день в таблице «Активность» одним полем даты - это должно быть частью 1NF (удаление производных данных). Большинство версий SQL (включая MySQL) могут легко преобразовать поле даты в день или неделю, как требуется.

Я также хотел бы удалить поле ActivityID и вместо этого использовать комбинацию UserID, Date и LocationID в качестве составного первичного ключа в таблице Activity. Однако может потребоваться запись нескольких строк для одного и того же пользователя, даты и местоположения - в этом случае поле ActivityID должно оставаться первичным ключом таблицы.