Я думал на днях о нормализации, и мне пришло в голову, я не могу думать о времени, когда в базе данных должно быть соотношение 1:1.
Имя: SSN? Я бы их в одной таблице PersonID: AddressID? Опять же, та же таблица.
Я могу придумать миллионы примеров 1: многих или многих: много (с соответствующими промежуточными таблицами), но никогда не 1:1.
Я пропустил что-то очевидное?
Отношения 1:1 обычно указывают на то, что по какой-то причине вы разделили более крупный объект. Часто это связано с соображениями производительности в физической схеме, но это может произойти и в логической части, если ожидается, что большая часть данных будет "неизвестной" одновременно (в этом случае у вас есть 1: 0 или 1:1, но не более).
В качестве примера логического раздела: у вас есть данные о сотруднике, но есть больший набор данных, которые необходимо собрать, если и только если они выбирают, чтобы иметь покрытие для здоровья. Я бы сохранил демографические данные о страховании здоровья в другой таблице, чтобы обеспечить более легкое разделение безопасности и избежать перемещения этих данных вокруг запросов, не связанных со страхованием.
Примером физического раздела могут быть те же данные, которые размещаются на нескольких серверах. Я могу сохранить демографические данные о состоянии здоровья в другом государстве (где, например, офис HR), и первичная база данных может ссылаться на него только через связанный сервер... избегая тиражирования конфиденциальных данных в другие местоположения, тем не менее, делая это доступным для (предполагая здесь редкие) запросы, которые в ней нуждаются.
Физическое разбиение может быть полезным , когда у вас есть запросы, которые требуют согласованных подмножеств более крупного объекта.
Одной из причин является эффективность базы данных. Наличие отношения 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" или отношения супертипа/подтипа или отношения наследования/классификации. Эта категория - это когда один объект является конкретным типом другого объекта. Например, может существовать объект Employee с атрибутами, которые применяются ко всем сотрудникам, а затем к различным сущностям для указания конкретных типов сотрудников с атрибутами, уникальными для этого типа сотрудника, например. Doctor, Accountant, Pilot и т.д. Этот дизайн позволяет избежать множества нулей, поскольку многие сотрудники не будут иметь специализированные атрибуты определенного подтипа. Другими примерами в этой категории могут быть Продукт как супертип, а 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 (это пример, дайте возможность сохранить дискуссию о том, является ли это хорошим ключом или нет для другого потока). Сотрудники могут быть разных типов, например, временные или постоянные, и если они постоянны, у них есть больше полей для заполнения, например номер офисного телефона, который должен быть не равен нулю, если тип = 'Постоянный'. В третьей базе данных нормальной формы столбец должен зависеть только от ключа, то есть от сотрудника, но на самом деле это зависит от сотрудника и типа, поэтому соотношение 1:1 совершенно нормально и желательно в этом случае. Он также предотвращает чрезмерно разреженные таблицы, если у меня есть 10 столбцов, которые обычно заполняются, но 20 дополнительных столбцов только для определенных типов.
Самый распространенный сценарий, о котором я могу думать, - это когда у вас есть BLOB. Скажем, вы хотите хранить большие изображения в базе данных (как правило, это не лучший способ их хранения, но иногда ограничения делают его более удобным). Обычно вам нужно, чтобы blob находился в отдельной таблице, чтобы улучшить поиск не-blob-данных.
В терминах чистой науки, да, они бесполезны.
В реальных базах данных иногда полезно использовать редко используемое поле в отдельной таблице: ускорить запросы, используя это и только это поле; чтобы избежать блокировок и т.д.
Вместо того, чтобы использовать представления для ограничения доступа к полям, иногда имеет смысл хранить ограниченные поля в отдельной таблице, к которой имеют доступ только определенные пользователи.
Я также могу думать о ситуациях, когда у вас есть модель OO, в которой вы используете наследование, а дерево наследования должно сохраняться в БД.
Например, у вас есть класс Bird and Fish, который наследуется от Animal. В вашей БД вы можете иметь таблицу "Животное" , в которой содержатся общие поля класса "Животное" , а таблица "Животное" имеет отношение "один к одному" с таблицей "Птица" и отношения "один к одному" с рыбой таблица.
В этом случае вам не нужно иметь одну таблицу Animal, которая содержит много столбцов с нулевым значением для хранения свойств Bird и Fish, где все столбцы, содержащие данные Fish, устанавливаются в NULL, когда запись представляет собой птица.
Вместо этого у вас есть запись в таблице Birds, которая имеет отношение "один к одному" с записью в таблице "Животные".
1-1 отношения также необходимы, если у вас слишком много информации. В каждой записи таблицы есть ограничение размера записи. Иногда таблицы разделяются на две части (с наиболее часто запрашиваемой информацией в основной таблице), так что размер записи не будет слишком большим. Базы данных также более эффективны при запросе, если таблицы узкие.
Это также способ расширить таблицу, которая уже работает с меньшим (воспринимаемым) риском, чем "реальное" изменение базы данных. Наблюдение отношения 1:1 в унаследованной системе часто является хорошим индикатором того, что поля были добавлены после первоначальной разработки.
В SQL невозможно обеспечить связь 1:1 между двумя таблицами, которая является обязательной с обеих сторон (если только таблицы не доступны только для чтения). Для большинства практических целей отношение "1:1" в SQL действительно означает 1: 0 | 1.
Неспособность поддерживать обязательную мощность в ссылочных ограничениях является одним из серьезных ограничений SQL. Ограничения "Отложенные" на самом деле не учитываются, потому что они всего лишь способ сказать, что ограничение не применяется некоторое время.
Если вы используете данные с одним из популярных ORM, вы можете разбить таблицу на несколько таблиц в соответствии с иерархией объектов.
Я обнаружил, что, когда я делаю соотношение 1:1, это полностью для системной причины, а не для реляционной причины.
Например, я обнаружил, что включение зарезервированных аспектов пользователя в 1 таблицу и размещение пользователем редактируемых полей пользователя в другой таблице позволяет логически правильно писать эти правила о разрешениях для этих полей.
Но вы правы, теоретически отношения 1:1 полностью надуманны и являются почти феноменом. Однако логически это позволяет программам и оптимизациям абстрагировать базу данных.
В большинстве случаев дизайн считается равным 1:1, пока кто-то не спросит "ну, почему он не может быть 1: многие"? Преждевременно разводя концепции друг с другом, в ожидании этого общего сценария. Человек и адрес не привязываются так сильно. У многих людей много адресов. И так далее...
Обычно два отдельных пространства объектов подразумевают, что один или оба могут быть умножены (x: много). Если бы два объекта были действительно, истинно 1:1, даже философски, то это скорее отношение отношения. Эти два "объекта" фактически являются частями одного целого объекта.
расширенная информация, которая необходима только в определенных сценариях. в устаревших приложениях и языках программирования (таких как RPG), где программы скомпилированы по таблицам (поэтому, если таблица меняется, вам нужно перекомпилировать программу (ы)). Теги вдоль файлов также могут быть полезны в случаях, когда вам нужно беспокоиться о размере таблицы.
Чаще всего это скорее физическая, чем логическая конструкция. Он обычно используется для вертикальной разбивки таблицы, чтобы использовать преимущества разделения операций ввода-вывода на физических устройствах или других оптимизаций запросов, связанных с разделением менее часто используемых данных или данных, которые должны быть более безопасными, чем остальные атрибуты на одном и том же объекте (SSN, Зарплата и т.д.).
Единственное логическое соображение, которое предписывает отношения 1-1, - это когда определенные атрибуты применяются только к некоторым объектам. Однако в большинстве случаев существует более/более нормализованный способ моделирования данных путем извлечения сущности.
Лучшая причина, по которой я могу видеть соотношение 1:1, - это SuperType SubType дизайна базы данных. Я создал структуру данных MLS Real Estate на основе этой модели. Было пять различных каналов данных; Жилая, коммерческая, многоквартирная, гостиница и земля.
Я создал свойство SuperType, которое содержало данные, общие для каждого из пяти отдельных каналов данных. Это позволило очень быстрым "простым" поискам по всем типам данных.
Я создаю пять отдельных субтипов, которые хранят уникальные элементы данных для каждого из пяти каналов данных. Каждая запись SuperType имела отношение 1:1 к соответствующей записи SubType.
Если заказчику нужен подробный поиск, ему нужно было выбрать тип Super-Sub, например PropertyResidential.
По моему мнению, соотношение 1:1 отображает наследование класса на РСУБД. Существует таблица A, которая содержит общие атрибуты, то есть статус класса участника Каждый статус унаследованного класса отображается на РСУБД с таблицей В с соотношением 1:1 к таблице, содержащей специализированные атрибуты. В таблице namend A также содержится поле типа, которое представляет функциональность "casting"
Bye Марио
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 с их данными
В любом месте были две совершенно независимые организации, которые разделяют отношения "один-к-одному". Там должно быть много примеров:
person ↔ dentist (его 1: N, так что это неправильно!)
person ↔ doctor (его 1: N, так что это также неправильно!)
person ↔ супруг (его 1: 0 | 1, поэтому он в основном неправильный!)
EDIT: Да, это были довольно плохие примеры, особенно если я всегда искал 1:1, а не 0 или 1 с обеих сторон. Думаю, мой мозг не срабатывал: -)
Итак, я попробую еще раз. Оказывается, после некоторого раздумья, что единственный способ, которым вы можете иметь два отдельных объекта, которые должны (в отношении программного обеспечения) быть вместе, все время состоит в том, чтобы они существовали вместе в более высокой категоризации. Тогда, если и только если вы попадете в более низкое разложение, вещи будут и должны быть отдельными, но на более высоком уровне они не могут жить друг без друга. Контекст, тогда это ключ.
Для медицинской базы данных вы можете хранить различную информацию о конкретных регионах тела, сохраняя их как отдельный объект. В этом случае у пациента есть только одна голова, и им нужно это иметь, или они не пациенты. (У них также есть одно сердце и ряд других необходимых единичных органов). Если вы заинтересованы в том, чтобы отслеживать операции, например, каждый регион должен быть уникальным отдельным объектом.
В системе производства/инвентаризации, если вы отслеживаете сборку транспортных средств, вы, безусловно, хотите следить за ходом двигателя по-другому от кузова автомобиля, но между ними есть отношения один к одному. У ухода должен быть двигатель, и только один (или он больше не будет "автомобилем" ). Двигатель принадлежит только одному автомобилю.
В каждом случае вы могли бы создавать отдельные объекты как одну большую запись, но с учетом уровня декомпозиции это было бы неправильно. Они в этих конкретных контекстах действительно независимые сущности, хотя они могут и не появляться на более высоком уровне.
Павел.