Какво е връзката едно към едно в моделирането на данни? Как реализирате тази връзка в база данни? Примерите в тази статия ще отговорят на тези въпроси.
Има три типа връзки между обекти (таблици) в моделирането на данни:
- Връзки едно към много (означени също като 1:M).
- Връзки много към много (M:N).
- Връзки едно към едно (1:1).
Най-често срещаният тип връзка е връзка един към много, при която запис в един обект може да бъде препратен от множество записи в друг обект. Друг често срещан тип е връзката много към много. Този тип връзка се използва само в логически модели на данни. Във физическа база данни тя трябва да бъде реализирана чрез използване на релации един към много и таблица на свързване.
В тази статия ще обсъдим третия тип връзки:отношенията един към един . Това е най-рядко срещаният тип връзка в модел на данни. Ще дадем примери за връзки едно към едно, ще покажем нотацията за връзките едно към едно в диаграма на ER и ще обсъдим връзките едно към едно на практика.
Примери за връзки един към един
Първо, какво е връзка един към един? Това е връзка, при която запис в един обект (таблица) е свързан точно с един запис в друг обект (таблица).
Нека видим някои примери от реалния живот за връзки един към един:
- Държава - столица :Всяка държава има точно една столица. Всяка столица е столица точно на една държава.
- Човек – неговите пръстови отпечатъци . Всеки човек има уникален набор от пръстови отпечатъци. Всеки набор от пръстови отпечатъци идентифицира точно един човек.
- Имейл – потребителски акаунт . За много уебсайтове един имейл адрес е свързан точно с един потребителски акаунт и всеки потребителски акаунт се идентифицира със своя имейл адрес.
- Съпруг – съпруг :В моногамен брак всеки човек има точно един съпруг.
- Потребителски профил - потребителски настройки . Един потребител има един набор от потребителски настройки. Един набор от потребителски настройки е свързан точно с един потребител.
За по-голяма яснота, нека сравним тези примери с връзки, които не са едно към едно:
- Държава - град: Всеки град е точно в една държава, но повечето държави имат много градове.
- Родител - дете :Всяко дете има двама родители, но всеки родител може да има много деца.
- Служител - мениджър :Всеки служител има точно един пряк ръководител или мениджър, но всеки мениджър обикновено контролира много служители.
Означаване на връзка едно към едно в диаграма на ER
Връзката едно към едно в диаграмата на ER се обозначава, както всички връзки, с линия, свързваща двете единици. „Едината“ мощност се обозначава с една права линия. (Кардиналността на „много“ се обозначава със символа пачи крак.)
Връзката едно към едно между държава и столица може да се обозначи така:
Перпендикулярните прави линии означават „задължително “. Тази диаграма показва, че е задължително една столица да има държава и е задължително държавата да има столица.
Друга възможност е едната или двете страни на връзката да бъдат по избор . Незадължителна страна се обозначава с отворен кръг. Тази диаграма показва, че има връзка едно към едно между човек и неговите пръстови отпечатъци. Лице е задължително (пръстовите отпечатъци трябва да бъдат присвоени на човек), но пръстовите отпечатъци не са задължителни (човек може да няма присвоени пръстови отпечатъци в базата данни).
Връзки едно към едно във физическа база данни
Има няколко начина за внедряване на връзка едно към едно във физическа база данни.
Първичен ключ като външен ключ
Един от начините за реализиране на връзка едно към едно в база данни е да се използва един и същ първичен ключ в двете таблици. Редове със същата стойност в първичния ключ са свързани. В този пример Франция е country
с id
1 и столицата му е в таблицата capital
под id
1.
country
id | име |
---|---|
1 | Франция |
2 | Германия |
3 | Испания |
capital
Технически един от първичните ключове трябва да бъде маркиран като външен ключ, както в този модел на данни:
Първичният ключ в таблица capital
също е външен ключ, който препраща към колоната с идентификатор в таблицата country . Тъй като capital.id
е първичен ключ, всяка стойност в колоната е уникална, така че капиталът може да се отнася за най-много една държава. Също така трябва препращане към държава – това е първичен ключ, така че не може да бъде оставен празен.
Допълнителен външен ключ с уникално ограничение
Друг начин, по който можете да внедрите връзка едно към едно в база данни, е да добавите нова колона и да я направите външен ключ.
В този пример добавяме колоната country_id
в таблицата capital
. Столицата с id
1, Мадрид, се свързва с държава 3, Испания.
country
id | име |
---|---|
1 | Франция |
2 | Германия |
3 | Испания |
capital
id | име | country_id |
---|---|---|
1 | Мадрид | 3 |
2 | Берлин | 2 |
3 | Париж | 1 |
Технически, колоната country_id
трябва да бъде външен ключ, препращащ id
колона в таблицата country
. Тъй като искате всяка столица да бъде свързана точно с една държава, трябва да направите колоната с външен ключ country_id
единствен по рода си.
Отношения един към един на практика
Последни няколко връзки едно към едно
Връзките един към един са най-рядко срещаният тип връзка. Една от причините за това е, че много малко връзки едно към едно съществуват в реалния живот. Освен това повечето връзки един към един са едно към едно само за определен период от време. Ако вашият модел включва времеви компонент и улавя историята на промените, както много често се случва, ще имате много малко връзки едно към едно.
Една моногамна връзка може да се раздели или един от партньорите да умре. Ако моделирате реалността на моногамните отношения (като бракове или граждански съюзи) с течение на времето, вероятно ще трябва да моделирате факта, че те продължават само за определен период.
Бихте си помислили, че човек и неговите пръстови отпечатъци никога не се променят. Но какво ще стане, ако човекът загуби пръст или пръстът е силно изгорен? Пръстовите им отпечатъци може да се променят. Това не е много често срещан сценарий; все пак при някои модели може да се наложи да вземете това предвид.
Дори нещо привидно толкова стабилно, колкото страните и техните столици се променят с времето. Например, Бон е бил столица на Западна Германия (Bundesrepublik Deutschland) след Втората световна война, когато Берлин е бил част от Източна Германия. Това се промени след обединението на Германия; столицата на Германия (Bundesrepublik Deutschland) сега е Берлин. Дали трябва или не трябва да вземете това под внимание зависи от вашата бизнес реалност и приложението, върху което работите.
Осъществим сценарий 1:1:Допълнителни части от таблицата
Мога да се сетя за един осъществим сценарий за истинска връзка един към един:незадължителни части от таблица. Представете си, че имате потребител на таблицата с потребителски данни. Таблицата съдържа обща потребителска информация, като имена на потребители, имейл адреси и дати на регистрация. Той също така съдържа потребителски настройки, като цветна тема или автоматично влизане за това приложение. Повечето потребители обаче нямат никакви потребителски настройки; те използват настройките по подразбиране.
user
id | име | имейл | дата_ на регистрация | тема | автоматично влизане |
---|---|---|---|---|---|
1 | Натанаел Талбот | [email protected] | 12.12.2020 | тъмно | вярно |
2 | Талита Йейтс | [email protected] | 14.12.2020 | ||
3 | Маркъс Уиър | [email protected] | 15.12.2020 | светлина | невярно |
4 | Натали Хейс | [email protected] | 18.12.2020 | ||
5 | Църква Морис | [email protected] | 20.12.2020 | ||
6 | Арва Валдес | [email protected] | 21.12.2020 |
В тази таблица има много празни полета. Можете да разделите user
таблица на две таблици:user
и user_settings
, която съдържа информация за потребителските настройки за тези, които са избрали да ги изберат.
user
id | име | имейл | дата_ на регистрация | тема | автоматично влизане |
---|---|---|---|---|---|
1 | Натанаел Талбот | [email protected] | 12.12.2020 | тъмно | вярно |
2 | Талита Йейтс | [email protected] | 14.12.2020 | ||
3 | Маркъс Уиър | [email protected] | 15.12.2020 | светлина | невярно |
4 | Натали Хейс | [email protected] | 18.12.2020 | ||
5 | Църква Морис | [email protected] | 20.12.2020 | ||
6 | Арва Валдес | [email protected] | 21.12.2020 |
user_settings
user_id | тема | автоматично влизане |
---|---|---|
1 | тъмно | вярно |
3 | светлина | невярно |
Разделянето на данни в две таблици прави заявките за таблици по-сложни:трябва да обедините данни от двете таблици. От друга страна, основният потребител таблицата е по-лесна за управление.
Научете повече за връзките с базата данни
Връзката едно към едно е връзка, при която запис в една таблица е свързан точно с един запис в друга таблица. Този тип връзка рядко се среща в реалния живот. Ако включите време във вашия модел на данни, много връзки едно към едно се превръщат в релации едно към много или много към много. Най-често срещаният сценарий за използване на връзка едно към едно в база данни е разделянето на една таблица на две:едната със задължителни колони, другата с колони по избор.
Ако тази статия ви е харесала, разгледайте други статии за връзките „едно към много“ и „много към много“ в нашия блог.
Ако сте студент, който посещава уроци по база данни, не забравяйте да създадете безплатен академичен акаунт във Vertabelo, нашия онлайн инструмент за рисуване на диаграма на ER. Vertabelo ви позволява да рисувате логически и физически ER диаграми директно във вашия браузър. Той поддържа PostgreSQL, SQL Server, Oracle, MySQL, Google BigQuery, Amazon Redshift и други релационни бази данни. Изпробвайте го и вижте колко лесно е да започнете!