Проектирование базы данных: несколько таблиц против одной таблицы для элементов, связанных с исследованиями - PullRequest
Новая
       46

Проектирование базы данных: несколько таблиц против одной таблицы для элементов, связанных с исследованиями

0 голосов
/ 20 марта 2020

Я создаю исследовательский репозиторий, в котором есть различные типы исследовательских предметов, таких как конференции, публикации, патенты, основные положения и т. Д. c. Данные будут вставлены после получения из соответствующих источников, обработки, а затем вставки в пакет из листа Excel. Основной операцией будет запрос данных в соответствии с зарегистрированным пользователем, например информация, относящаяся к исследователю для отдельного лица, информация, относящаяся к отделу / подразделению (в основном суммирование строк) для председателя и так далее. Теперь, когда я подхожу к этому, я вижу два варианта: 

    Make two tables, one for the research item type and the other for the actual item 
    Make individual tables for all type of objects

Проблема с 1-й структурой состоит в том, что я получу огромную основную таблицу с пустыми / пустыми столбцами. Но это позволит мне легко добавить еще один элемент исследования в будущем, поскольку я могу просто добавить новый элемент в таблицу «type» и затем добавить фактические данные в общую таблицу.

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

Если я могу спросить, какую из двух стратегий вы бы порекомендовали и почему? 

The 1st one entails multiple database queries, and the second one entails a large single table.

Если это поможет, я использую сервер MS SQL.

1 Ответ

1 голос
/ 21 марта 2020

Проблема, с которой вы сталкиваетесь, заключается в разрешении иерархии в модели ER. У вас есть родительский объект или обобщение (RESEARCH_ITEM), которое может быть создано различными способами (ваши дочерние объекты, такие как PUBLICATION, PATENT и т. Д.).

Для реализации этой иерархии на физическом уровне (т.е. создание таблицы) вы должны рассмотреть, какие свойства имеет эта иерархия. В частности, вы должны спросить себя:

  • Ограничение перекрытия : может ли экземпляр родительской сущности принадлежать более чем одной дочерней сущности?
  • Покрывающее ограничение : охватывают ли дочерние объекты все возможные экземпляры родительского объекта?

Объединяя эти два критерия, мы имеем четыре возможных варианта:

  1. Полное непересекающееся: дочерние сущности охватывают все возможные экземпляры без перекрытия;
  2. Частичное непересекающееся: дочерние сущности не покрывают все возможные экземпляры и нет перекрытия;
  3. Общее перекрытие: дочерние объекты сущности охватывают все возможные экземпляры с потенциальным перекрытием;
  4. частичное перекрытие: дочерние сущности не покрывают все возможные экземпляры и возможное перекрытие.

Разрешение иерархии зависит по сценарию. Если ваша иерархия является полностью непересекающейся, лучше всего было бы исключить родительскую сущность и включить ее атрибуты в дочерние сущности (более быстрые запросы, более чистые таблицы). С другой стороны, если есть перекрытия, это решение не является оптимальным, потому что у вас будет дублирование данных (одна и та же строка в двух дочерних таблицах). В этом случае вы можете выбрать включение дочерних элементов в родительский элемент с возможными NULL-полями для атрибутов child-Speci c.

Более того, чтобы разработать лучшую реализацию, вам потребуется подумайте, как осуществляется доступ к данным (есть ли ребенок, к которому, как я знаю, очень часто будут обращаться с запросами? В этом случае будет полезна отдельная таблица).

...