Присоединиться к таблице в архитектуре базы данных?

Я работаю над приложением базы данных (Access 2007) и у меня есть пара вопросов по архитектуре. Это, безусловно, самое сложное приложение, которое я когда-либо писал.

В настоящее время у меня есть 5 таблиц, каждая со своим уникальным полем идентификатора:

  • платформы
  • транспортные средства
  • руководства
  • процедуры
  • недостатки

Одна и та же ошибка может появиться в нескольких процедурах, а одна и та же процедура может появиться в нескольких руководствах. Я хотел бы предоставить пользователям возможность копировать и удалять записи, а также сшивать записи между таблицами.

В настоящее время у меня есть таблицы соединений между каждой из перечисленных выше таблиц,

  • платформы_транспортные средства
  • Vehicles_manuals
  • руководства_процедуры
  • процедуры_ошибки

Редактирование отношений между основными таблицами (путем редактирования содержимого таблиц соединения) стало довольно сложным, поскольку действия копирования и удаления имеют каскадный эффект на другие таблицы. На мой взгляд, это можно было бы эффективно выполнить с помощью рекурсии, но на самом деле заставить его работать — это совсем другая история.

Вопрос № 1: Является ли описанная мной архитектура «хорошим» способом организации этих данных или она излишне сложна? (У меня есть привычка так делать.)

Вопрос № 2: Есть ли «предпочтительный» способ сделать это?

Вопрос № 3: Не лучше ли организовать таблицы по-другому, например так:

Всего 5 столов,

  • платформы
  • транспортные средства
  • руководства
  • процедуры
  • недостатки

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

  • платформы
  • идентификатор платформы, имя_платформы
  • транспортные средства
  • идентификатор платформы, идентификатор транспортного средства, имя транспортного средства
  • руководства
  • VehicleID, manualID, manualName
  • ...

Это кажется мне более простым и, конечно, менее сложным. Если бы вы все хотели предоставить некоторые профессиональные отзывы, я был бы очень признателен.

Спасибо!


sql database-design ms-access-2007 jointable
person Scott Christensen    schedule 01.08.2012    source источник
comment
Если ваши таблицы являются «один ко многим», например, каждое транспортное средство находится только на одной платформе, я бы пропустил таблицы соединения для этих отношений. Просто добавьте идентификатор платформы в таблицу транспортных средств и идентификатор транспортного средства в таблицу руководства. Вам нужны таблицы соединения для нижних таблиц, где существует связь "многие ко многим" Each manual can have many procedures, and each procedure can appear in many manuals   -  person Ghost    schedule 01.08.2012
comment
Спасибо, Призрак. Это имеет смысл для меня. Настройка процедур обслуживания таблицы стала довольно рутинной. Знаете ли вы о каких-либо предварительно написанных модулях класса навигации, которые я мог бы добавить в свое приложение? :)   -  person Scott Christensen    schedule 01.08.2012

Ответы (1)


arrow_upward
0
arrow_downward

Вам необходимо использовать инструмент MS Access Relationship для настройки правил ссылочной целостности. Таким образом, вы можете автоматически каскадировать удаление и обновление. Я бы избегал «объединения таблиц», поскольку они не нужны, пока родительский ключ находится в таблице (который будет называться внешним ключом).

person Holger Brandt    schedule 01.08.2012
comment
Таблицы соединений здесь не являются ненужными для таблиц более низкого уровня, поскольку возможно for the same procedure to appear in multiple manuals и предположительно для одного руководства содержать много процедур. - person Ghost; 01.08.2012
comment
Хольгер. У меня установлены правила ссылочной целостности, как вы описали. Если бы каждая таблица (кроме первой) имела ключ, состоящий из поля родительского ключа и поля ключа отдельной записи, было бы этого достаточно, чтобы сделать то, что будет делать таблица соединения? - person Scott Christensen; 01.08.2012
comment
@ScottChristensen, да, так и должно быть. Однако обратите внимание на комментарий Ghost. Например, если в руководстве есть несколько процедур, вам нужна дочерняя таблица (или таблица соединений, как вы ее называете) для отношения «один ко многим». - person Holger Brandt; 01.08.2012