Как ссылаться на группы записей в реляционных базах данных

Question

Как ссылаться на группы записей в реляционных базах данных

Предположим, у нас есть следующие структуры таблиц:

Люди

| HumanID | FirstName | Фамилия | Пол |
| --------- + ----------- + ---------- + -------- |
| 1 | Иссак | Ньютон | М |
| 2 | Мари | Кюри | F |
| 3 | Тим | Дункан | М |

животные

| AmimalID | Виды | Никнейм |
| ---------- + --------- + ---------- |
| 4 | Тигр | Ронни |
| 5 | Собака | Снупи |
| 6 | Собака | Медведь |
| 7 | Кот | Сонный |

Интересно, как ссылаться на группу записей в других таблицах.

Например, у меня есть таблица Foods и столбец EatenBy.

Продукты

| FoodID | FoodName | EatenBy |
|--------+----------+---------|
|      8 | Рис |???     |

Что я хочу хранить в EatenBy может быть

отдельная запись в таблицах людей, животных (например, Тим Дукан)
группа записей в таблице (например, все собаки, все мужчины, все женщины)
целый стол (например, все люди)

Простым решением является использование объединенной строки, которая включает первичные ключи из разных таблиц и специальные строки, такие как "Люди", "М". Приложение может проанализировать объединенную строку и сделать что-то соответственно.

Продукты

| FoodID | FoodName | EatenBy      |
|--------+----------+--------------|
|      8 | Рис | Люди, 6, 7 |

Я знаю, что использование объединенной строки - плохая идея с точки зрения проектирования реляционных баз данных.

Другой вариант - добавить еще одну таблицу и использовать внешний ключ.

Продукты

| FoodID | FoodName |
|--------+----------|
|      8 | Рис |

EatenBy

| FoodID | EatenBy |
| -------- + --------- |
| 8 | Люди |
|      8 |       6 |
|      8 |       7 |

Я думаю, что это лучше, чем первое решение. Проблема в том, что в поле EatenBy хранятся значения разных значений. Это проблема?

Как лучше всего смоделировать это требование? Как добиться 3NF в этом случае?

Таблицы примеров здесь немного надуманы, но я сталкиваюсь с такими ситуациями на работе.

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

Редактировать:

Я сделал несколько обновлений к вопросу, и вопрос становится раздутым и нечитаемым.

Поэтому я перенес обновления в отдельные ответы ниже.

Быстрый ответ

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

Связанные строки, CSV, повторяющиеся группы не должны использоваться в реляционной модели. Поэтому нам нужно нормализовать таблицу, исключив повторяющиеся группы.
В этой задаче объединенная строка содержит значения различных значений.
Реляционные базы данных хранят факты о реальном мире. Каждая таблица должна хранить факты об ОДНОМ предмете, и каждый столбец должен хранить ОДИН факт.
Таким образом, нам нужна одна ассоциативная таблица для каждого факта, чтобы исправить "EatenBy".
например
Food_Human (FoodID, HumanID)
Food_Animal (FoodID, AnimalID)
Food_Species (FoodID, SpeciesID)

Предостережение

Идеи для решения проблемы - это хорошо. Однако модель данных здесь ужасна.

Очевидные проблемы:

Люди животные
Использование суррогатов (идентификаторов) во время моделирования данных является плохой практикой

Для получения дополнительной информации вы можете прочитать ответы подробно.

3

relational-database normalization referential-integrity

Источник

user4826671 24 апр '15 в 02:50

2 ответа

Решение

Для каждой категории, которая ест еду, вы должны добавить одну таблицу. например, если один продукт может быть съеден каким-то конкретным полом, вы должны иметь:

  Food_Gender(FoodID,GenderID)

для людей вы бы имели:

 Food_Human(FoodID,HumanID)

для животных видов:

 Food_AnimalSpc(FoodID,Species)

для всей таблицы:

Food_Table(FoodID,TableID)

и так далее для других категорий

0

Источник

user1600305 11 май '15 в 05:01

Другие вопросы по тегам relational-database normalization referential-integrity

user484814 24 апр '15 в 16:08 2015-04-24 16:08 · Accepted Answer · 2015-04-24 16:08

Этот ответ изложен в хронологическом порядке. Вопрос прогрессировал в деталях, отмеченных как Обновления. Существует ряд подходящих ответов.
Переход от первоначального вопроса к окончательному ответу представляет собой опыт обучения, особенно для типов OO/ORM. Основные заголовки отмечают Ответы, второстепенные заголовки отмечают предметы.
Ответ превышает максимально допустимую длину. Я предоставляю их как ссылки, чтобы преодолеть это.

Ответ на начальный вопрос

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

Возможно, вы видели что-то подобное на работе, но это не значит, что это было правильно или приемлемо. CSVs перерыв 2NF. Вы не можете легко найти это поле. Вы не можете легко обновить это поле. Вы должны управлять контентом (например, избегать дублирования; заказывать) вручную, с помощью кода. У вас нет базы данных или чего-то похожего, у вас есть великолепная система регистрации записей, для которой вам нужно написать множество кода для "обработки". Как в старые добрые времена обработки данных ISAM 1970-х годов.

Проблема в том, что вы, похоже, хотите реляционную базу данных. Возможно, вы слышали о целостности данных, силе отношений (сила объединения для вас на данном этапе) и скорости. Система регистрации записей не имеет ничего из этого.
Если вам нужна реляционная база данных, то вам необходимо:
- думайте о данных реляционно и применяйте методы реляционной базы данных, такие как моделирование данных как данных и ничего, кроме данных (не как значений данных).
- Затем классификация данных (никакого отношения к классу ОО или концепции классификатора).
- Тогда относимся к секретным данным.
Вторая проблема заключается в том, что это типично для ОО-типов, которые концентрируются на значениях данных, а не на их значении; как это классифицируется; как это связано с другими данными; и т.п.
Без сомнения, вы не придумали эту концепцию сами, ваши "учителя" накормили ее для вас, я вижу это все время. И они любят системы регистрации записей. Заметьте, вместо того, чтобы давать определения таблиц, вы заявляете, что вы даете "структуру", но вместо этого вы перечисляете значения данных.
- Если вы не понимаете, что я говорю, позвольте мне заверить вас, что это классическая проблема в мире ОО, и решение будет простым, если вы будете применять принципы. Иначе это бесконечный беспорядок в стеке OO. Недавно я полностью исключил предложение ОО + решение, предложенное очень известным математиком, который поддерживает монолит ОО. Это известная газета.
- Я релялизовал данные (т.е. я просто поместил данные в реляционный контекст: смоделировал и нормализовал их, что заняло в общей сложности десять минут), и проблема исчезла, предложение + решение не требовалось. Прочитайте ответ Хиддера. Обратите внимание, я не пытался уничтожить статью, я пытался понять данные, которые были представлены в шизофренической форме, и самый простой способ сделать это - построить реляционную модель данных. Этот простой акт уничтожил бумагу.
- Обратите внимание, что ссылка является выдержкой из официального отчета о платном задании для клиента, крупного австралийского банка, который любезно предоставил мне разрешение на публикацию выписки с целью информирования общественности об опасностях игнорирования принципов реляционной базы данных. особенно сторонниками ОО.
- Точно такой же процесс произошел со второй, более известной газетой Kohler Response. Этот ответ намного меньше, менее формален, это не оплачиваемая работа для клиента. Этот идиот сплетничает о еще одной ненормальной "нормальной форме".

Поэтому я бы попросил вас:

забудьте о "табличных структурах" или определениях
забудьте о том, что вы хотите
забудьте о вариантах реализации
забывать ID колонны, полностью и полностью
забывать EatenBy
Подумайте о том, что у вас есть с точки зрения данных, значения данных, а не как значений данных или примеров данных, а не того, что вы хотите с ними делать
подумайте о том, как эти данные классифицируются, и как их можно классифицировать.
как данные связаны с другими данными. (Вы можете подумать, что ваш EatenBy это так, но это не так, потому что у данных еще нет организации, чтобы сформировать отношения.)

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

вещи
Группы вещей
Отношения между вещами и ThingGroups

Вещи являются существительными, предметами. В конце концов мы будем делать что-то между этими предметами, которые будут глаголами или действиями. Это сформирует Предикаты (Логика Первого Порядка). Но не сейчас, а сейчас мы хотим только Вещи.

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

Ответ на обновление 1 по иерархии

Идентификаторы записей: физические, нереляционные

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

Пожалуйста, прочитайте этот ответ.

Иерархии существуют в данных

Если вы хотите полный дискурс, пожалуйста, задайте новый вопрос. Вот краткое резюме.

Иерархии естественным образом встречаются в мире, они есть везде. Это приводит к тому, что иерархии реализуются во многих базах данных. Реляционная модель была основана и является прогрессом иерархической модели. Он блестяще поддерживает иерархии. К сожалению, известные авторы не понимают РМ, они преподают только системы регистрации записей до 1970-х годов, помеченные как "реляционные". Кроме того, они не понимают иерархии, не говоря уже об иерархиях, поддерживаемых в РМ, поэтому они подавляют их.

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

И наоборот, если иерархия, которая встречается в моделируемых данных, моделируется правильно и реализуется с использованием подлинных реляционных конструкций (реляционные ключи, нормализация и т. Д.), То результатом является простая в использовании и простая в кодировании база данных, а также лишенный дублирования данных (в любой форме) и чрезвычайно быстрый. Это в буквальном смысле Relational в лучшем виде.

Существует три типа иерархий, которые встречаются в данных.

Иерархия, сформированная в последовательности таблиц
Это требование, потребность в реляционных ключах, встречается в каждой базе данных, и, наоборот, его отсутствие наносит ущерб базе данных, и в результате создается система регистрации записей, не требующая целостности, мощности или скорости реляционной базы данных.
Иерархия отчетливо видна в форме реляционного ключа, который прогрессирует в составлении, в любой последовательности таблиц: отец, сын, внук и т. Д. Это важно для обычной целостности реляционных данных, такой как Хиддерс, и 95% Реализации базы данных не имеют.
В ответе Хиддера есть замечательный пример иерархии:
а. которые существуют естественно в данных
б. что ОО-типы слепы к [как, очевидно, Хиддерс]
с. они внедряют RFS без какой-либо целостности, а затем пытаются "исправить" проблему на объектных уровнях, добавляя еще большую сложность.
Тогда как я реализовал иерархию в классической реляционной форме, и проблема полностью исчезла, исключив предложенное "решение", документ. Отношения-отношения исключают теорию.
Две иерархии в этих четырех таблицах:
```
    Domain::Animal::Harvest

    Domain::Activity::Harvest
```
Обратите внимание, что Хиддерс не знает о том, что данные представляют собой иерархию; что его RFS не обладает целостностью именно потому, что он не является реляционным; что размещение данных в реляционном контексте обеспечивает ту целостность, которую он ищет вне этого; что реляционная модель устраняет все такие "проблемы" и делает все такие "решения" смехотворными.
Вот еще один пример, хотя моделирование еще не завершено. Пожалуйста, убедитесь, что изучили Предикаты, и на странице 2 указаны настоящие Ключи. Иерархии:
```
    Subject::CategorySubject::ExaminationResult

    Category::CategorySubject::ExaminationResult

    Person::Registrant::Candidate::ExaminationResult
```
Обратите внимание, что последний является прогрессом состояния бизнес-инструмента, поэтому ключ не является составным.
Иерархия строк в одной таблице
Обычно это какая-то древовидная структура, их буквально миллионы. Для любого данного узла это поддерживает одного предка или родителя и неограниченное количество детей. Если все сделано правильно, нет ограничений на количество уровней или высоту дерева (т. Е. Неограниченное количество поколений предков и потомков).
- Термины " предок" и " потомок" используются здесь как простые технические термины, они не имеют коннотаций и ограничений ОО.
Вам нужна рекурсия на сервере, чтобы обойти древовидную структуру, чтобы вы могли писать простые процессы и функции, которые являются рекурсивными.
Вот один для сообщений. Пожалуйста, прочитайте и вопрос, и ответ, и посетите связанную модель данных сообщения. Обратите внимание, что ищущий не упомянул Иерархию или дерево, потому что знание Иерархий в Реляционных БД подавлено, но (из комментариев), как только он увидел Ответ и Модель данных, он узнал это для иерархии, которая есть, и что это подходит ему идеально. Иерархия это:
```
    Message::Message[Message]::Message[::Message[Message]] ...
```
Иерархия строк в одной таблице через ассоциативную таблицу
Эта иерархия обеспечивает структуру предка / потомка для нескольких предков или родителей. Это требует двух отношений, поэтому требуется дополнительная ассоциативная таблица. Это широко известно как структура спецификаций. Неограниченная высота, рекурсивно пройденный.
Проблема спецификации материалов была ограничением иерархической СУБД, которую мы частично преодолели в сетевой СУБД. В то время это была насущная проблема, и одна из специфических проблем IBM, которую доктор Э.Ф. Кодд был явно призван преодолеть. Конечно, он достиг этих целей и превосходил их эффектно.
Вот иерархия спецификаций, смоделированная и реализованная правильно.
- Пожалуйста, извините преамбулу, это из статьи, пропустите два верхних ряда, посмотрите на нижний ряд.
- Персона:: Потомство также дано.
- Иерархии:
```
Part[Assembly]::Part[Component] ...

Part[Component]::Part[Assembly] ...

Person[Parent]::Person[Child] ...

Person[Child]::Person[Parent] ...
```

Незнание Иерархии

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

Список смежности
Подавители весело заявляют, что " реляционная модель не поддерживает иерархии", отрицая, что она основана на иерархической модели (каждая из которых предоставляет ясное свидетельство того, что они не знают основных понятий в РМ, которые, как они утверждают, являются постулат о). Поэтому они не могут использовать имя. Это глупое имя, которое они используют.
Как правило, реализация признает наличие иерархии в данных, но реализация будет очень плохой, ограниченной физическими идентификаторами записей и т. Д., Отсутствующей реляционной целостностью и т. Д.
И они не знают, как пройти по дереву, что нужно рекурсии.
Вложенные Наборы
Аборт, прямо из ада. Система регистрации записей в системе регистрации записей. Это не только создает массу дублирования и нарушает правила нормализации, но и фиксирует записи в системе хранения в конкретном виде.
Перемещение одного узла требует переписывания всей затронутой части дерева. Возлюбленные Даты, Дарвен и Селько.
МС HIERARCHYID Тип данных делает то же самое. Дает вам массу бетона, которую нужно забивать и заливать снова, каждый раз, когда меняется узел.

Хорошо, это не было так коротко.

Ответ на обновление 2

Ответ на обновление 2

Ответ на обновление 3

Ответ на обновление 3

Ответ на обновление 4

Ответ на обновление 4