Чи є колись час, коли використання відносин бази даних 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" або супертип / підтип або спадкові / класифікаційні відносини: Ця категорія - це коли одна сутність є певним типом іншої сутності. Наприклад, може бути організація «Працівник» з атрибутами, які застосовуються до всіх працівників, а потім різні суб'єкти для вказівки конкретних типів працівника з атрибутами, характерними для цього типу працівників, наприклад, лікарем, бухгалтером, пілотом тощо. Цей дизайн дозволяє уникнути кількох нулів, оскільки багато працівників не мали б спеціалізованих ознак конкретного підтипу. Іншими прикладами в цій категорії можуть бути Продукт як супертип, а ВиробництвоПродукт та ОбслуговуванняПостачання як підтипи; Тварина як супертип і Собака та Кішка як підтипи; Зауважте, що кожного разу, коли ви намагаєтеся зіставити об'єктно-орієнтовану ієрархію успадкування у реляційну базу даних (наприклад, в об'єктно-реляційній моделі), такий тип відносин представляє такі сценарії.

• "Бос" відносини , такі як керівник, голова, президент тощо, де в організаційному підрозділі може бути лише один начальник, а одна людина може бути начальником лише одного організаційного підрозділу. Якщо ці правила застосовуються, то у вас стосунки 1: 1, такі як один керівник департаменту, один генеральний директор компанії тощо. Стосунки "Бос" не стосуються лише людей. Такі ж відносини виникають, якщо є лише один магазин, де знаходиться штаб-квартира компанії, або якщо лише одне місто є столицею країни, наприклад.

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

• Шлюб (принаймні, в юридичних юрисдикціях, коли багатоженство є незаконним): одна людина може одночасно одружуватися лише з однією іншою особою. Цей приклад я отримав з підручника, який використав це як приклад одинакових відносин 1: 1, коли компанія фіксує шлюби між своїми працівниками.

• Відповідні застереження : коли зроблено унікальне бронювання, а потім виконується у вигляді двох окремих об'єктів. Наприклад, система прокату автомобілів може записувати бронювання в одному об'єкті, а потім фактичну оренду в окремому об'єкті. Хоча така ситуація може бути розроблена як одна організація, можливо, має сенс відокремити суб'єкти господарювання, оскільки не всі застереження виконані, і не всі оренди вимагають бронювання, і обидві ситуації є дуже поширеними.

Я повторюю застереження, яке я зробив раніше, що більшість із них є стосунками 1: 1, лише якщо не зафіксовано жодної історичної інформації. Отже, якщо працівник змінює свою роль в організації, або керівник приймає на себе відповідальність за інший відділ, або працівник перепризначає транспортний засіб, або хтось овдав і повторно вступає в шлюб, тоді учасники відносин можуть змінитися. Якщо база даних не зберігає жодної попередньої історії щодо цих відносин 1: 1, вони залишаються законними відносинами 1: 1. Але якщо база даних записує історичну інформацію (наприклад, додавання дати початку та кінця для кожного стосунку), то вони майже всі перетворюються на відносини M: M.

Є два помітні винятки з історичної примітки: По-перше, деякі відносини змінюються настільки рідко, що історична інформація зазвичай не зберігається. Наприклад, більшість відносин IS-A (наприклад, тип товару) незмінні; тобто вони ніколи не можуть змінитися. Таким чином, історична точка запису є суперечкою; вони завжди реалізовуватимуться як природні відносини 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 (це приклад, давайте збережемо дискусію щодо того, чи це хороший ключ чи ні для іншої нитки). Співробітники можуть бути різних типів, скажімо, тимчасовими чи постійними, і якщо вони є постійними, у них потрібно заповнити більше полів, як номер офісного телефону, який повинен бути недійсним лише тоді, коли тип = "Постійний". У 3-й базі даних звичайної форми стовпець повинен залежати лише від ключа, тобто працівника, але він фактично залежить від працівника та типу, тому відносини 1: 1 є цілком нормальними і бажаними в цьому випадку. Це також запобігає занадто розрідженим таблицям, якщо я маю 10 колонок, які зазвичай заповнюються,

Найпоширеніший сценарій, про який я можу придумати, - це у вас BLOB. Скажімо, ви хочете зберігати великі зображення в базі даних (як правило, це не найкращий спосіб їх зберігання, але іноді обмеження роблять це зручніше). Зазвичай ви хочете, щоб крап знаходився в окремій таблиці, щоб покращити пошуки даних, що не стосуються блобу.

З точки зору чистої науки, так, вони марні.

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

Замість того, щоб використовувати представлення для обмеження доступу до полів, іноді має сенс зберігати обмежені поля в окремій таблиці, до якої мають доступ лише певні користувачі.

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

Наприклад, у вас є клас «Птах і риба», який успадковується від Animal. У вашій БД ви можете мати таблицю "Тварини", яка містить загальні поля класу "Тварини", а таблиця "Тварини" має взаємовідносини один з одним із таблицею "Птах" та "Один на один" з Рибами. стіл.

У цьому випадку вам не потрібно мати одну таблицю тварин, яка містить безліч змінних стовпців, щоб містити властивості Bird and Fish, де всі стовпці, що містять дані про риби, встановлюються на NULL, коли запис представляє пташку.

Натомість у вас є запис у таблиці Птахів, який має відношення один до одного із записом у таблиці Тварини.

1-1 стосунки також необхідні, якщо у вас занадто багато інформації. Для кожного запису в таблиці є обмеження розміру запису. Іноді таблиці розбиваються на дві частини (з найчастіше запитуваною інформацією в головній таблиці) лише для того, щоб розмір запису був не надто великим. Бази даних також більш ефективні в запитах, якщо таблиці вузькі.

Це також спосіб розширити таблицю, яка вже виробляється з меншим (сприйнятим) ризиком, ніж "реальна" зміна бази даних. Бачити співвідношення 1: 1 у застарілій системі часто є хорошим показником того, що поля були додані після початкового проектування.

У SQL неможливо застосувати співвідношення 1: 1 між двома таблицями, яке є обов'язковим для обох сторін (якщо тільки таблиці не є для читання). Для більшості практичних цілей зв'язок "1: 1" у SQL насправді означає 1: 0 | 1.

Неможливість підтримувати обов'язкову кардинальність у референсних обмеженнях є одним із серйозних обмежень SQL. "Відкладені" обмеження насправді не враховуються, оскільки вони є лише способом сказати, що обмеження не застосовується деякий час.

Якщо ви використовуєте дані з одним із популярних ORM, ви можете розбити таблицю на кілька таблиць, щоб відповідати вашій Ієрархії об’єктів.

Я виявив, що коли я роблю відносини 1: 1, це повністю з системної причини, а не з реляційних причин.

Наприклад, я виявив, що помістити зарезервовані аспекти користувача в одну таблицю і помістити поле редагування користувача користувачем в іншу таблицю дозволяє набагато простіше логічно записати ці правила щодо дозволів на ці поля.

Але ви праві, теоретично, відносини 1: 1 повністю надумані і майже не явище. Однак логічно це дозволяє програмам та оптимізаціям легше вилучати базу даних.

У більшості випадків дизайни вважаються рівними 1: 1, поки хтось не запитає "ну чому ж не може бути 1: багато"? Передчасне розлучення понять одне з одним робиться в очікуванні цього загального сценарію. Особа та адреса не зв’язуються так щільно. Дуже багато людей мають кілька адрес. І так далі...

Зазвичай два окремих об'єктних простору означають, що один чи обидва можна множити (x: багато). Якщо два об'єкти були справді, справді 1: 1, навіть філософськи, то це більше стосунки. Ці два "об'єкти" насправді є частинами одного цілого об'єкта.

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

Найчастіше це більше фізична, ніж логічна побудова. Зазвичай використовується вертикальний розділ таблиці, щоб скористатися розбиттям вводу-виводу на фізичні пристрої або іншими оптимізаціями запитів, пов’язаними з відокремленням даних або даних, які часто отримують доступ, і які потрібно зберігати більш безпечно, ніж решта атрибутів на одному об’єкті (SSN, зарплата тощо).

Єдиний логічний розгляд, який призначає відношення 1-1, це коли певні атрибути стосуються лише деяких суб'єктів. Однак у більшості випадків існує кращий / більш нормалізований спосіб моделювання даних шляхом вилучення сутності.

Найкраща причина, яку я можу побачити у відносинах 1: 1, - це підтип типу SuperType дизайну баз даних. Я створив структуру даних MLS про нерухомість на основі цієї моделі. Було п'ять різних каналів даних; Житлові, комерційні, багатосімейні, готелі та земля.

Я створив властивість SuperType з назвою даних, які були загальними для кожного з п'яти окремих каналів даних. Це дозволило здійснити дуже швидкий "простий" пошук у всіх типах даних.

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

Якщо клієнт захотів детальний пошук, він повинен вибрати тип Super-Sub, наприклад PropertyResidential.

На мій погляд, відносини 1: 1 відображають спадкування класу на RDBMS. Існує таблиця A, яка містить загальні атрибути, тобто статус розбірливого класу. Кожен успадкований статус класу відображається на RDBMS із таблицею B зі співвідношенням 1: 1 до таблиці A, що містить спеціалізовані атрибути. Ім'я таблиці A містить також поле "type", яке представляє функцію "лиття"

До побачення Маріо

Ви можете створити таблицю відносин один на один, якщо є якась значна користь від продуктивності. Ви можете помістити рідко використовувані поля в окрему таблицю.

Відносини 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, тому це теж неправильно!)

людина <-> подружжя (його 1: 0 | 1, тому його здебільшого неправильно!)

EDIT: Так, це були досить погані приклади, особливо якщо я завжди шукав 1: 1, а не 0 або 1 з обох сторін. Я думаю, мій мозок помилився :-)

Отже, я спробую ще раз. Виявившись, подумавши, що єдиний спосіб, коли ви можете мати дві окремі сутності, які повинні (наскільки це програмне забезпечення) весь час бути разом, - це вони існувати разом у вищій категоризації. Тоді, якщо і лише якщо ви потрапляєте в нижчий розпад, речі є і повинні бути окремими, але на вищому рівні вони не можуть жити один без одного. Контекст, то є ключовим.

У медичній базі даних ви можете зберігати різну інформацію про конкретні ділянки тіла, зберігаючи їх як окрему сутність. У такому випадку у пацієнта є лише одна голова, і вони повинні мати її, або вони не є пацієнтом. (У них також є одне серце та ряд інших необхідних одиночних органів). Якщо ви, наприклад, зацікавлені в відстеженні операцій, то кожен регіон повинен бути унікальним окремим об'єктом.

Якщо у виробничій / інвентаризаційній системі ви відстежуєте складання транспортних засобів, то, безумовно, хочете спостерігати за тим, як двигун рухається по-різному від кузова автомобіля, але все-таки існує взаємозв'язок. Догляд повинен мати двигун, і лише один (або це вже не буде "машина"). Двигун належить лише одному автомобілю.

У кожному випадку ви можете створити окремі сутності як один великий запис, але враховуючи рівень розкладу, це було б неправильно. У цих конкретних контекстах вони є справді незалежними сутностями, хоча вони можуть не виявлятись так на більш високому рівні.

Пол.