Стоит ли делать промежуточную таблицу для решения проблемы объединения 6 таблиц в запросе?

Question

Я пытаюсь создать базу данных, которая связывает производство и использование продукта. Производство включает в себя 3 различных этапа, и каждый этап дает номер партии. Я хочу иметь возможность посмотреть на конечный продукт и написать запрос для поиска enz_name (шаг 0) из шагов 4 и выше (шаги, на которых используется продукт).

Синий на этом рисунке как что-то с одинаковым enz_name и номерами партий для первых двух шагов можно рассматривать как два разных конечных продукта, потому что на последнем этапе производства оно разделяется на 2 разные партии.

My objective: to be able to look at data from steps 4 and above (data from using the final product) and be able to track down the enz_name of the relevant final products.

My problem: the way i have it set up now is I would have to join tables from step 4 to step 3, step 3 to step 2, step 2 to step 1, and finally step 1 to the construct (step 0). That many steps seems inconvenient. And i'd basically be asking Oracle to search through over half of my tables to get an answer. Is that bad practice and bad design?

Possible solutions i'm thinking of:

1. I'm thinking i could make an intermediary table with enz_name and construct_id. But that doesn't really solve the problem of looking at the CELL tables and wanting to know the enz_name because I's still have to go through CHAR_ENZ, PURIFIED_ENZ, PRODUCED, CONSTRUCT to get to the intermediary table. Should I make a second intermediary table then that contains construct_id, g_batch, p_batch, and char_id? Is that really stupid?

2. I could just add a FK construct_id column to the char_enz table (step 3 of production) that references the construct table (step 0). This seems like the most obvious solution, but is there a better way? Is this a good solution?

введите описание изображения здесь

Answer 1

Я мог бы просто добавить столбец FK construct_id в таблицу char_enz

Это называется «денормализация», как вы знаете. Это связано с несколькими проблемами.

1. Вы храните несколько копий одной и той же информации. То есть я могу заглянуть в CHAR_ENZ, чтобы найти имя фермента, или выполнить соединение 6 таблиц. Дополнительное хранилище является расточительным (но на самом деле, кого это волнует?), Но теперь также появляется возможность несоответствий. Как гласит старая пословица: «Человек с часами знает, который час; человек с двумя никогда не может точно сказать».

2. Это усложняет обновление. Если вы когда-либо хотели обновить имя фермента в партии, вместо того, чтобы просто обновить, скажем PRODUCED.CONSTRUCT_ID, теперь вам также нужно не забыть обновить все имена ферментов в CHAR_ENZ.

Денормализация не обязательно дьявол, но вы должны использовать ее только во избежание более серьезных проблем. Соединение с 6 таблицами, вероятно, не является "худшей" проблемой, достаточно плохой, чтобы ее оправдать (очевидно, на мой взгляд, с небольшими деталями). присоединиться. Вы можете рассмотреть возможность размещения таблиц PRODUCED, PURIFIED_ENZ и CHAR_ENZ в кластере во время проектирования физической базы данных. Это должно минимизировать влияние на производительность. Вы также можете создать представление для инкапсуляции логики соединения c.

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

PURIFIED_ENZ ==> первичный ключ (G_BATCH, P_BATCH) CHAR_ENZ ==> первичный ключ (G_BATCH, P_BATCH, CHAR_ID)

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

Последнее, что меня беспокоит в вашей модели данных, это то, что она, похоже, предполагает и требует, чтобы шаги 1 -3 добычи всегда будет прежней. Смена технологий; требования клиентов меняются. Я очень мало знаю о микробиологии, но, как правило, мне хотелось бы построить модель данных с меньшим количеством предположений. Вы могли бы сделать это, немного абстрагируя пакетные шаги.