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

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

• Name:SSN? Я бы взял их в одной таблице.
• PersonID:AddressID? Опять та же таблица.

Я могу привести миллионы примеров 1: много или много: много (с соответствующими промежуточными таблицами), но никогда не 1: 1.

Я что-то упускаю из виду?

Соотношение 1: 1 обычно указывает на то, что по какой-то причине вы разбили более крупную сущность. Часто это происходит из-за соображений производительности в физической схеме, но это может произойти и на стороне логики, если ожидается, что большой кусок данных будет «неизвестен» в одно и то же время (в этом случае у вас есть 1: 0 или 1: 1, но не более).

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

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

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

Одной из причин является эффективность базы данных. Наличие отношения 1: 1 позволяет разделить поля, которые будут затронуты во время блокировки строки / таблицы. Если в таблице A содержится масса обновлений, а в таблице b - тонна операций чтения (или имеется масса обновлений из другого приложения), то блокировка таблицы A не повлияет на то, что происходит в таблице B.

Другие поднимают хорошую мысль. Безопасность также может быть хорошей причиной в зависимости от того, как приложения и т. Д. Поражают систему. Я бы предпочел использовать другой подход, но это может быть простым способом ограничения доступа к определенным данным. Это действительно легко просто запретить доступ к определенной таблице в крайнем случае.

Моя запись в блоге об этом.

Ограниченность. Технически отношение данных может быть 1: 1, но соответствующие строки не обязательно должны существовать для каждой строки. Таким образом, если у вас есть двадцать миллионов строк и существует некоторый набор значений, который существует только для 0,5% из них, экономия пространства будет огромной, если вы вытолкнете эти столбцы в таблицу, которая может быть заполнена редко.

Большинство высокопоставленных ответов дают очень полезные причины для настройки и оптимизации базы данных для отношений 1: 1, но я хочу сосредоточиться только на «диких» примерах, где естественно возникают отношения 1: 1.

Обратите внимание на одну важную характеристику реализации базы данных большинства этих примеров: историческая информация об отношении 1: 1 не сохраняется. То есть эти отношения 1: 1 в любой данный момент времени. Если разработчик базы данных хочет записывать изменения участников отношений с течением времени, то отношения становятся 1: M или M: M; они теряют свою природу 1: 1. С этим понял, здесь идет:

• «Is-A» или отношения супертип / подтип или наследование / классификация: Эта категория относится к тем случаям, когда один объект представляет собой определенный тип другого объекта. Например, может существовать сущность «Сотрудник» с атрибутами, которые применяются ко всем сотрудникам, а затем - разные сущности для указания конкретных типов сотрудников с атрибутами, уникальными для этого типа сотрудника, например, «Доктор», «Бухгалтер», «Пилот» и т. Д. В этой схеме избегается нескольких нулей, поскольку у многих сотрудников не было бы специализированных атрибутов определенного подтипа. Другими примерами в этой категории могут быть Product как супертип, и ManufacturingProduct и MaintenanceSupply как подтипы; Животное как супертип и Собака и Кошка как подтипы; и т.д. Обратите внимание, что всякий раз, когда вы пытаетесь отобразить объектно-ориентированную иерархию наследования в реляционную базу данных (например, в объектно-реляционной модели), это тот тип отношений, который представляет такие сценарии.

• Отношения «босс» , такие как менеджер, председатель, президент и т. Д., Где организационная единица может иметь только одного начальника, а один человек может быть боссом только одной организационной единицы. Если эти правила применяются, то у вас отношения 1: 1, например, один руководитель отдела, один генеральный директор компании и т. Д. Отношения типа «босс» относятся не только к людям. Такие же отношения возникают, если в качестве штаб-квартиры компании существует только один магазин, или, например, только один город является столицей страны.

• Некоторые виды ограниченного распределения ресурсов , например, одному сотруднику может быть назначен только один служебный автомобиль за раз (например, один грузовик на водителя грузовика, одно такси на водителя такси и т. Д.). Коллега недавно привел мне этот пример.

• Брак (по крайней мере, в правовых юрисдикциях, где многоженство является незаконным): один человек может состоять в браке только с одним другим человеком одновременно. Я получил этот пример из учебника, который использовал это как пример унарных отношений 1: 1, когда компания регистрирует браки между своими сотрудниками.

• Соответствующие резервирования : когда выполняется уникальное резервирование, а затем выполняется как два отдельных объекта. Например, система проката автомобилей может записывать резервирование в одном объекте, а затем фактическую аренду в отдельном объекте. Хотя такую ​​ситуацию можно альтернативно спроектировать как один объект, возможно, имеет смысл разделить объекты, поскольку не все резервирования выполнены, и не все виды аренды требуют резервирования, и обе ситуации очень распространены.

Я повторяю оговорку, которую я сделал ранее, что большинство из них являются отношениями 1: 1, только если историческая информация не записана. Таким образом, если сотрудник меняет свою роль в организации, или менеджер берет на себя ответственность за другой отдел, или сотрудник переназначается на транспортное средство, или кто-то овдовев и вступает в повторный брак, тогда участники отношений могут измениться. Если в базе данных не хранится предыдущая история об этих отношениях 1: 1, то они остаются законными отношениями 1: 1. Но если база данных записывает историческую информацию (например, добавляя даты начала и окончания для каждого отношения), то они почти все превращаются в отношения M: M.

Есть два заметных исключения из исторической заметки: во-первых, некоторые отношения изменяются настолько редко, что историческая информация обычно не сохраняется. Например, большинство отношений IS-A (например, тип продукта) являются неизменяемыми; то есть они никогда не могут измениться. Таким образом, исторический рекорд является спорным; они всегда будут реализованы как естественные отношения 1: 1. Во-вторых, магазин отношений резервирование-аренда датируется отдельно, поскольку резервирование и аренда являются независимыми событиями, каждое из которых имеет свои даты. Поскольку у сущностей есть свои собственные даты, а не сами отношения 1: 1, имеющие дату начала, они останутся как отношения 1: 1, даже если сохранена историческая информация.

Ваш вопрос может быть истолкован несколькими способами, из-за того, как вы его сформулировали. Ответы показывают это.

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

Но я думаю, что вы на самом деле спрашиваете ... когда существуют отношения 1: 1, должны ли таблицы когда-либо делиться? Другими словами, должны ли вы когда-нибудь иметь две таблицы, которые содержат одинаковые ключи? На практике большинство из нас анализируют только первичные ключи, а не другие ключи-кандидаты, но этот вопрос немного отличается.

Правила нормализации для 1NF, 2NF и 3NF никогда не требуют разложения (разбиения) таблицы на две таблицы с одинаковым первичным ключом. Я не выяснил, может ли когда-либо поместить схему в BCNF, 4NF или 5NF две таблицы с одинаковыми ключами. Вдобавок ко всему, я собираюсь догадаться, что ответ - нет.

Существует уровень нормализации, называемый 6NF. Правило нормализации для 6NF может определенно привести к двум таблицам с одинаковым первичным ключом. Преимущество 6NF перед 5NF в том, что NULLS можно полностью избежать. Это важно для некоторых, но не для всех разработчиков баз данных. Я никогда не удосужился поместить схему в 6NF.

В 6NF отсутствующие данные могут быть представлены пропущенной строкой, а не строкой со значением NULL в некотором столбце.

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

Я использую их в основном по нескольким причинам. Одним из них является существенная разница в скорости изменения данных. В некоторых из моих таблиц могут быть контрольные журналы, в которых я отслеживаю предыдущие версии записей, если мне нужно только отслеживать предыдущие версии 5 из 10 столбцов, разделение этих 5 столбцов на отдельную таблицу с механизмом контрольного журнала более эффективно. Кроме того, у меня могут быть записи (скажем, для бухгалтерского приложения), которые предназначены только для записи. Вы не можете изменить суммы в долларах или счет, для которого они были. Если вы допустили ошибку, вам нужно создать соответствующую запись, чтобы записать корректировку неверной записи, а затем создать корректирующую запись. У меня есть ограничения на таблицу, обеспечивающие тот факт, что они не могут быть обновлены или удалены, но у меня может быть несколько атрибутов для этого объекта, которые являются податливыми, они хранятся в отдельной таблице без ограничений на модификацию. В другой раз я делаю это в приложениях для медицинских карт. Существуют данные, относящиеся к посещению, которые нельзя изменить после его подписания, и другие данные, относящиеся к посещению, которые могут быть изменены после выхода из системы. В этом случае я разделю данные и поставлю триггер на заблокированную таблицу, отклоняя обновления закрытой таблицы при выходе из системы, но разрешая обновления данных, на которые врач не подписывает подписку.

Другой автор прокомментировал, что 1: 1 не нормализуется, я бы не согласился с этим в некоторых ситуациях, особенно подтипов. Скажем, у меня есть таблица сотрудников, и первичным ключом является их SSN (это пример, давайте сохраним дискуссию о том, является ли это хорошим ключом или нет для другого потока). Сотрудники могут быть разных типов, скажем, временными или постоянными, и если они являются постоянными, им нужно заполнить больше полей, например, номер телефона офиса, который должен быть не нулевым, если type = 'Permanent'. В базе данных третьей нормальной формы столбец должен зависеть только от ключа, то есть сотрудника, но на самом деле он зависит от сотрудника и его типа, поэтому соотношение 1: 1 совершенно нормально и желательно в этом случае. Это также предотвращает чрезмерно разреженные таблицы, если у меня есть 10 столбцов, которые обычно заполнены,

Наиболее распространенный сценарий, о котором я могу думать, это когда у вас есть BLOB. Допустим, вы хотите хранить большие изображения в базе данных (обычно это не лучший способ их хранения, но иногда ограничения делают его более удобным). Как правило, вы хотите, чтобы большой двоичный объект находился в отдельной таблице, чтобы улучшить поиск данных без больших двоичных объектов.

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

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

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

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

Например, у вас есть класс Bird и Fish, которые оба наследуются от Animal. В вашей БД у вас может быть таблица Animal, которая содержит общие поля класса Animal, а таблица Animal имеет отношение один к одному с таблицей Bird и отношение один к одному с рыбой. стол.

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

Вместо этого у вас есть запись в таблице Birds, которая имеет отношение один к одному с записью в таблице Animal.

1-1 отношения также необходимы, если у вас слишком много информации. Существует ограничение на размер записи для каждой записи в таблице. Иногда таблицы делятся на две части (с наиболее часто запрашиваемой информацией в основной таблице) только для того, чтобы размер записи не был слишком большим. Базы данных также более эффективны при запросах, если таблицы узкие.

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

В SQL невозможно обеспечить соотношение 1: 1 между двумя таблицами, которое является обязательным для обеих сторон (если только таблицы доступны только для чтения). Для большинства практических целей отношение «1: 1» в SQL действительно означает 1: 0 | 1.

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

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

Я обнаружил, что когда я делаю отношения 1: 1, это полностью по системной причине, а не по реляционной причине.

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

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

В большинстве случаев дизайны считаются 1: 1, пока кто-то не спросит: «Ну, почему не может быть 1: много»? Отделение понятий друг от друга преждевременно делается в ожидании этого общего сценария. Персона и Адрес не связывают так тесно. У многих людей есть несколько адресов. И так далее...

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

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

Чаще всего это скорее физическая, чем логическая конструкция. Он обычно используется для вертикального разделения таблицы, чтобы воспользоваться преимуществами разделения ввода-вывода по физическим устройствам или других оптимизаций запросов, связанных с выделением менее часто используемых данных или данных, которые необходимо хранить более защищенными, чем остальные атрибуты того же объекта (SSN, Зарплата и т. Д.).

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

Лучшая причина, которую я вижу для отношения 1: 1 - это подтип SuperType для проектирования баз данных. Я создал структуру данных Real Estate MLS на основе этой модели. Было пять разных каналов данных; Жилой, Коммерческий, Многосемейный, Отели и Земля.

Я создал свойство SuperType с именем, которое содержало данные, общие для каждого из пяти отдельных каналов данных. Это позволило очень быстро выполнять «простой» поиск по всем типам данных.

Я создаю пять отдельных подтипов, в которых хранятся уникальные элементы данных для каждого из пяти каналов данных. Каждая запись SuperType имела отношение 1: 1 к соответствующей записи SubType.

Если клиент хотел подробного поиска, ему нужно было выбрать тип Super-Sub, например PropertyResidential.

По моему мнению, отношение 1: 1 отображает наследование классов в СУБД. Существует таблица A, которая содержит общие атрибуты, то есть статус класса участника. Каждое унаследованное состояние класса отображается в СУБД с таблицей B с отношением 1: 1 к таблице A, содержащей специализированные атрибуты. Имя таблицы А также содержит поле типа, которое представляет функциональность приведения.

Пока Марио

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

Отношения 1: 1 не имеют смысла, если вы занимаетесь нормализацией, поскольку все, что будет 1: 1, будет храниться в одной таблице.

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

Возможно, если у вас есть какие-то типизированные объекты в вашей базе данных.

Скажем, в таблице T1 у вас есть столбцы C1, C2, C3… с отношением один к одному. Все нормально, нормализовано. Теперь, скажем, в таблице T2 у вас есть столбцы C1, C2, C3,… (имена могут отличаться, но говорят, что типы и роль одинаковы) с отношением один к одному. Это нормально для T2 по тем же причинам, что и для T1.

В этом случае, однако, я вижу соответствие для отдельной таблицы T3, содержащей C1, C2, C3… и отношение один к одному от T1 до T3 и от T2 до T3. Я даже больше подхожу, если существует другая таблица, с которой уже существует от одного до нескольких C1, C2, C3… скажем, из таблицы A в несколько строк в таблице B. Тогда вместо T3 вы используете B и отношение один к одному от T1 до B, то же самое для от T2 до B, и все еще то же самое отношение к множеству от A до B.

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

Это не очень удобно в целях безопасности, но есть более эффективные способы проверки безопасности. Представьте, вы создаете ключ, который может открыть только одну дверь. Если ключ может открыть любую другую дверь, вы должны позвонить в будильник. По сути, вы можете иметь «CitizenTable» и «VotingTable». Гражданин Один голосует за Кандидата Один, который хранится в таблице для голосования. Если гражданин один снова появится в таблице для голосования, то это должно быть тревогой. Будьте советом, это отношение один к одному, потому что мы не ссылаемся на поле кандидата, мы обращаемся к таблице голосования и таблице граждан.

Пример:

 Citizen Table
 id = 1, citizen_name = "EvryBod"
 id = 2, citizen_name = "Lesly"
 id = 3, citizen_name = "Wasserman"

 Candidate Table
 id = 1, citizen_id = 1, candidate_name = "Bern Nie"
 id = 2, citizen_id = 2, candidate_name = "Bern Nie"
 id = 3, citizen_id = 3, candidate_name = "Hill Arry"

Тогда, если мы увидим таблицу голосования так:

 Voting Table
 id = 1, citizen_id = 1, candidate_name = "Bern Nie"
 id = 2, citizen_id = 2, candidate_name = "Bern Nie"
 id = 3, citizen_id = 3, candidate_name = "Hill Arry"
 id = 4, citizen_id = 3, candidate_name = "Hill Arry"
 id = 5, citizen_id = 3, candidate_name = "Hill Arry"

Можно сказать, что гражданин № 3 - лжец в огненных штанах, который обманул Берна Не. Просто пример.

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

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

человек <-> стоматолог (его 1: N, так что это неправильно!)

человек <-> доктор (его 1: N, так что это тоже неправильно!)

person <-> супруга (его 1: 0 | 1, так что в основном это неправильно!)

РЕДАКТИРОВАТЬ: Да, это были довольно плохие примеры, особенно если я всегда искал 1: 1, а не 0 или 1 с обеих сторон. Я предполагаю, что мой мозг был неправильно запущен :-)

Итак, я попробую еще раз. После недолгого размышления выясняется, что единственный способ, которым вы можете иметь две отдельные сущности, которые должны (насколько позволяет программное обеспечение) быть вместе все время, - это чтобы они существовали вместе в более высокой категоризации. Тогда, если и только если вы впадаете в более низкое разложение, вещи должны и должны быть отделены друг от друга, но на более высоком уровне они не могут жить друг без друга. Контекст, то это ключ.

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

В системе производства / инвентаря, если вы отслеживаете сборку транспортных средств, вы, безусловно, хотите наблюдать, как двигатель движется не так, как кузов автомобиля, но между ними есть отношения один к одному. У заботы должен быть двигатель и только один (иначе это не будет «машина»). Двигатель принадлежит только одному автомобилю.

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

Павел.