Сурогатний ключ (також штучний ключ, ідентифікатор сутності, згенерований ключ, послідовний номер, непідтверджений ключ, технічний ключ або довільний унікальний ідентифікатор) у базах даних — унікальний ідентифікатор сутності модельованого світу чи об'єкта бази даних. Сурогатний ключ не отримується з даних застосунку, на відміну від природного (чи бізнес) ключа.
Визначення
Існують принаймні два визначення сурогату:
- Сурогат (1) — Галл, Оулетт і Тодд (1976)
- Сурогат представляє сутність у зовнішньому світі. Сурогат генерується всередині системи, але все ж є видимим для користувача чи застосунку.
- Сурогат (2) — Вайрінга та Де Йонге (1991)
- Сурогат представляє об'єкт у базі даних, яким він є. Сурогат генерується всередині системи і не є видимим для користувача чи застосунку.
Визначення сурогата (1) стосується радше моделі даних, а ніж [en] і використовується далі в цій статті.
Важлива різниця між сурогатним і первинним ключем залежить від того, якою є база даних: поточною чи хронологічною. Оскільки поточна база даних зберігає лише на даний момент валідні дані, то в ній наявна точна відповідність між сурогатом у модельованому світі та первинним ключем бази даних. У цьому випадку сурогат може бути використано як первинний ключ, породжуючи термін сурогатний ключ. У хронологічній базі даних, однак, існує відношення багато-до-одного між первинними ключами та сурогатом. Оскільки кожному сурогату можуть відповідати декілька об'єктів бази даних, то він не може використовуватися як первинний ключ; а отже, необхідний інший атрибут, який би разом із сурогатом унікально ідентифікував би кожний об'єкт.
Хоча Галл та ін. (1976) нічого про це не каже, решта стверджують, що сурогати повинні мати такі характеристики:
- значення є унікальним у всій системі, а отже, не використовується повторно
- значення генерується системою
- значенням не маніпулюють ані користувач, ані застосунок
- значення не містить семантичного змісту
- значення невидиме користувачеві чи застосунку
- значення не складається з інших значень різних доменів.
Сурогати на практиці
У поточній базі даних сурогатний ключ може бути первинним, що згенерований системою керування базами даних і не отримується з будь-яких даних застосунку в базі. Єдиним призначенням сурогатного ключа є діяти як первинний. Також є можливим існування сурогатного ключа на додачу до згенерованого базою даних UUID (наприклад, HR-номер кожного працівника, що відрізняється від його UUID).
Сурогатний ключ часто є послідовним числом (наприклад, у [en] чи SQL Server — «стовпчик-ідентифікатор», у PostgreSQL чи Informix — serial
, в Oracle чи SQL Server — SEQUENCE
, чи стовпчик, визначений з AUTO_INCREMENT
у MySQL). Деякі бази даних надають UUID/GUID як можливий тип даних для сурогатних ключів (наприклад, UUID
у PostgreSQL або UNIQUEIDENTIFIER
в SQL Server).
Існування ключа, незалежного від усіх інших стовпчиків, ізолює відношення бази даних від змін значень або проектування (робить базу даних гнучкішою) та гарантує унікальність.
У хронологічній базі даних важливо розрізняти сурогатні та бізнес-ключі. Кожен рядок матиме і бізнес-ключ, і сурогатний ключ. Сурогатний ключ ідентифікує один унікальний рядок у базі даних, а бізнес-ключ — одну унікальну сутність модельованого світу. Один рядок таблиці подає частку часу, що має всі атрибути сутності у визначений проміжок часу. Ці частки зображують увесь проміжок часу однієї бізнес-сутності. Наприклад, таблиця EmployeeContracts може мати хронологічну інформацію для відстеження контрактних робочих годин. Бізнес-ключ для одного контракту буде ідентичним (неунікальним) в обох рядках, але сурогатний ключ для кожного рядка унікальний.
SurrogateKey | BusinessKey | EmployeeName | WorkingHoursPerWeek | RowValidFrom | RowValidTo |
---|---|---|---|---|---|
1 | BOS0120 | Джон Сміт | 40 | 2000-01-01 | 2000-12-31 |
56 | P0000123 | Боб Браун | 25 | 1999-01-01 | 2011-12-31 |
234 | BOS0120 | Джон Сміт | 35 | 2001-01-01 | 2009-12-31 |
Деякі проектувальники баз даних систематично використовують сурогатні ключі незалежно від придатності інших потенційних ключів, тоді як інші за наявності використовуватимуть ключ, уже присутній у даних.
Деякі альтернативні назви («згенерований системою ключ») описують радше спосіб генерації нових сурогатних значень, а не природу сурогатного концепту.
Підходи до генерації сурогатів включають:
- Universally Unique Identifiers (UUID)
- Globally Unique Identifiers (GUID)
- Ідентифікатори об'єкта (OID)
- Стовпчик-ідентифікатор в [en] чи SQL Server
IDENTITY
чиIDENTITY(n, n)
SEQUENCE
чиGENERATED AS IDENTITY
в Oracle, починаючи з версії 12.1SEQUENCE
в SQL Server, починаючи з версії 2012SERIAL
у PostgreSQL або IBM InformixAUTO_INCREMENT
у MySQLAUTOINCREMENT
у SQLite- Тип даних «Лічильник» (англ. AutoNumber, рос. Счётчик) у Microsoft Access
AS IDENTITY GENERATED BY DEFAULT
в IBM DB2- Стовпчик-ідентифікатор (реалізований у DDL) у Teradata
- Послідовність таблиці, коли послідовність обчислюється процедурою та таблицею послідовності з полями:
id, sequenceName, sequenceValue та incrementValue
Переваги
Незмінність
Сурогатні ключі не змінюються, поки існує рядок. Це має наступні переваги:
- Застосунки не можуть втратити посилання на рядки бази даних (адже ідентифікатор ніколи не змінюється).
- Дані первинного чи природного ключа завжди можуть бути змінені, навіть якщо база даних не підтримує каскадні оновлення зв'язаних зовнішніх ключів.
Зміни вимог
Атрибути, що унікально ідентифікують сутність, можуть змінюватися, що може анулювати придатність природних ключів. Розглянемо наступний приклад:
Мережне ім'я працівника обрано як природний ключ. Після злиття з іншою компанією необхідно додати нових працівників. Деякі нові мережні імена породжують конфлікти, оскільки вони генерувалися незалежно (коли компанії існували окремо).
Зазвичай у таких випадках до природного ключа повинен додаватися новий атрибут (наприклад, стовпчик original_company). З сурогатним ключем лише таблиця, що визначає сурогатний ключ, має зазнати змін. З природними ключами всі таблиці (а можливо й інше, суміжне програмне забезпечення), що їх використовують, зазнають змін.
Деякі проблемні галузі нечітко ідентифікують придатний природний ключ. Сурогатні ключі уникають вибору природного ключа, який може бути некоректним.
Продуктивність
Сурогатні ключі прагнуть бути компактного типу даних, як-от чотирибайтні цілі числа. Це дозволяє базі даних запитувати один ключовий стовпчик швидше за декілька. Більше того, ненадлишкове поширення ключів призводить до цілковитого балансу результатного б-дерева індексу. Сурогатні ключі є також дешевшими для з'єднань (порівнюються менше стовпчиків) за складені ключі.
Сумісність
При використанні деяких систем розробки застосунків баз даних, драйверів і систем об'єктно-реляційного відображення, як-от Ruby on Rails або Hibernate, набагато легше використовувати цілі числа чи GUID як сурогатні ключі для кожної таблиці замість природних ключів задля підтримки агностичних операцій над системою бази даних і відображення об'єкта в рядок.
Однорідність
Коли кожна таблиця має однорідний сурогатний ключ, деякі завдання можуть бути легко автоматизовані шляхом написання коду незалежним від таблиць способом.
Валідація
Можливо спроектувати ключі-значення, що відповідають загальновідомим шаблонам чи структурам, які можуть бути автоматично верифіковані. Наприклад, ключі, призначені для використання у деяких стовпчиках деяких таблиць, може бути спроектовано «інакше, ніж» ті, які призначені для іншого стовпчика чи таблиці, таким чином спрощуючи виявлення помилок застосунку, за яких ключі можуть бути переплутані. Проте, ця характеристика сурогатних ключів ніколи не має використовуватися для керування будь-якою логікою застосунку, адже вона порушує принципи нормалізації баз даних.
Недоліки
Дизасоціація
Значення згенерованих сурогатних ключів не стосуються реального сенсу даних у рядку. При перевірці рядка з зовнішнім ключем на іншу таблицю за допомогою сурогатного ключа значення останнього не може бути розрізнене на основі самого ключа. Кожен зовнішній ключ повинен бути з'єднаний для отримання пов'язаного елементу даних. Це також ускладнює аудит[] через неочевидність некоректних даних.
Сурогатні ключі неприродні для експортованих і спільних даних. Особливо складним є те, що таблиці з двох в іншому випадку однакових схем (наприклад, тестова та схема розробки) можуть мати записи, еквівалентні у бізнес-розумінні, але з різними ключами. Це можна пом'якшити, експортуючи не сурогатні ключі, а лише перехідні дані (найочевидніше, у виконуваних застосунках, що мають «живе» підключення до бази).
Оптимізація запитів
Реляційні бази даних припускають застосування унікального індексу як первинного ключа таблиці. Унікальний індекс слугує двом цілям: (1) забезпеченню цілісності сутностей, оскільки дані первинного ключа повинні бути унікальними по рядках, та (2) швидкому пошуку рядків при запитах. Оскільки сурогатні ключі замінюють атрибути-ідентифікатори таблиці — природні ключі — які є найзапитуванішими, то оптимізатор запитів змушений сканувати всю таблицю при задоволенні подібних запитів. Засобом повного сканування таблиці є застосування індексів на атрибути-ідентифікатори чи їх множини. Коли такі множини є потенційними ключами, індекс може бути унікальним.
Ці додаткові індекси, однак, займають дисковий простір і сповільнюють вставки та вилучення.
Нормалізація
Сурогатні ключі можуть призвести до повторюваних значень у будь-яких природних ключах. Унеможливлення таких дублікатів є частиною реалізації системи баз даних.
Моделювання бізнес-процесів
Оскільки сурогатні ключі неприродні, то під час моделювання бізнес-вимог можуть з'являтися вади. Бізнес-вимоги, покладаючись на природний ключ, згодом потребують трансляції в сурогатний. Однією зі стратегій є чітке розмежування логічної моделі (в якій немає сурогатних ключів) та її фізичної реалізації для забезпечення того, що логічна модель коректна та достатньо нормалізована, а також того, що фізична модель є коректною реалізацією логічної.
Випадкове розкриття
Власницька інформація може витікати у разі використання генераторів послідовних ключів. Шляхом віднімання попередньо та нещодавно згенерованих послідовних ключів можна з'ясувати кількість вставлених рядків за деякий період часу. Це може викрити, наприклад, кількість транзакцій або нових акаунтів за період. Існують кілька способів подолання цієї проблеми:
- збільшення послідовного числа на довільне значення
- генерування випадкового ключа на кшталт UUID
Випадкові припущення
Послідовно згенеровані сурогатні ключі можуть припускати, що події з більшим значенням сталися після подій з меншим. Це не обов'язково так, оскільки такі значення не гарантують часову послідовність, адже можливі відмови у вставках і залишення розривів, які можуть бути заповнені пізніше. Якщо хронологія є важливою, то дата й час повинні записуватися окремо.
Див. також
Примітки
- https://elib.lntu.edu.ua/sites/default/files/elib_upload/ЕНП_Саварин_Лепкий/teoretic/lec5.html
- Галл, П. А. В.; Оулетт, Дж.; Тодд, С. Дж. П. (1976). Relations and Entities. У Ніжссен, Джерард Марія (ред.). Modelling in Data Base Management Systems. Північна Голландія.
- Дейт (1998)
- UUID. PostgreSQL (англійською) .
{{}}
: Обслуговування CS1: Сторінки з параметром url-status, але без параметра archive-url () - UNIQUEIDENTIFIER. MSDN (англійською) .
{{}}
: Обслуговування CS1: Сторінки з параметром url-status, але без параметра archive-url () - Create Table. Oracle Database (англійською) . Oracle Corporation.
{{}}
: Обслуговування CS1: Сторінки з параметром url-status, але без параметра archive-url () - Create Sequence (Transact-SQL). MSDN (англійською) .
{{}}
: Обслуговування CS1: Сторінки з параметром url-status, але без параметра archive-url ()
Вікіпедія, Українська, Україна, книга, книги, бібліотека, стаття, читати, завантажити, безкоштовно, безкоштовно завантажити, mp3, відео, mp4, 3gp, jpg, jpeg, gif, png, малюнок, музика, пісня, фільм, книга, гра, ігри, мобільний, телефон, android, ios, apple, мобільний телефон, samsung, iphone, xiomi, xiaomi, redmi, honor, oppo, nokia, sonya, mi, ПК, web, Інтернет
Surogatnij klyuch takozh shtuchnij klyuch identifikator sutnosti zgenerovanij klyuch poslidovnij nomer nepidtverdzhenij klyuch tehnichnij klyuch abo dovilnij unikalnij identifikator u bazah danih unikalnij identifikator sutnosti modelovanogo svitu chi ob yekta bazi danih Surogatnij klyuch ne otrimuyetsya z danih zastosunku na vidminu vid prirodnogo chi biznes klyucha ViznachennyaIsnuyut prinajmni dva viznachennya surogatu Surogat 1 Gall Oulett i Todd 1976 Surogat predstavlyaye sutnist u zovnishnomu sviti Surogat generuyetsya vseredini sistemi ale vse zh ye vidimim dlya koristuvacha chi zastosunku Surogat 2 Vajringa ta De Jonge 1991 Surogat predstavlyaye ob yekt u bazi danih yakim vin ye Surogat generuyetsya vseredini sistemi i ne ye vidimim dlya koristuvacha chi zastosunku Viznachennya surogata 1 stosuyetsya radshe modeli danih a nizh en i vikoristovuyetsya dali v cij statti Vazhliva riznicya mizh surogatnim i pervinnim klyuchem zalezhit vid togo yakoyu ye baza danih potochnoyu chi hronologichnoyu Oskilki potochna baza danih zberigaye lishe na danij moment validni dani to v nij nayavna tochna vidpovidnist mizh surogatom u modelovanomu sviti ta pervinnim klyuchem bazi danih U comu vipadku surogat mozhe buti vikoristano yak pervinnij klyuch porodzhuyuchi termin surogatnij klyuch U hronologichnij bazi danih odnak isnuye vidnoshennya bagato do odnogo mizh pervinnimi klyuchami ta surogatom Oskilki kozhnomu surogatu mozhut vidpovidati dekilka ob yektiv bazi danih to vin ne mozhe vikoristovuvatisya yak pervinnij klyuch a otzhe neobhidnij inshij atribut yakij bi razom iz surogatom unikalno identifikuvav bi kozhnij ob yekt Hocha Gall ta in 1976 nichogo pro ce ne kazhe reshta stverdzhuyut sho surogati povinni mati taki harakteristiki znachennya ye unikalnim u vsij sistemi a otzhe ne vikoristovuyetsya povtorno znachennya generuyetsya sistemoyu znachennyam ne manipulyuyut ani koristuvach ani zastosunok znachennya ne mistit semantichnogo zmistu znachennya nevidime koristuvachevi chi zastosunku znachennya ne skladayetsya z inshih znachen riznih domeniv Surogati na prakticiU potochnij bazi danih surogatnij klyuch mozhe buti pervinnim sho zgenerovanij sistemoyu keruvannya bazami danih i ne otrimuyetsya z bud yakih danih zastosunku v bazi Yedinim priznachennyam surogatnogo klyucha ye diyati yak pervinnij Takozh ye mozhlivim isnuvannya surogatnogo klyucha na dodachu do zgenerovanogo bazoyu danih UUID napriklad HR nomer kozhnogo pracivnika sho vidriznyayetsya vid jogo UUID Surogatnij klyuch chasto ye poslidovnim chislom napriklad u en chi SQL Server stovpchik identifikator u PostgreSQL chi Informix serial v Oracle chi SQL Server SEQUENCE chi stovpchik viznachenij z AUTO INCREMENT u MySQL Deyaki bazi danih nadayut UUID GUID yak mozhlivij tip danih dlya surogatnih klyuchiv napriklad UUID u PostgreSQL abo UNIQUEIDENTIFIER v SQL Server Isnuvannya klyucha nezalezhnogo vid usih inshih stovpchikiv izolyuye vidnoshennya bazi danih vid zmin znachen abo proektuvannya robit bazu danih gnuchkishoyu ta garantuye unikalnist U hronologichnij bazi danih vazhlivo rozriznyati surogatni ta biznes klyuchi Kozhen ryadok matime i biznes klyuch i surogatnij klyuch Surogatnij klyuch identifikuye odin unikalnij ryadok u bazi danih a biznes klyuch odnu unikalnu sutnist modelovanogo svitu Odin ryadok tablici podaye chastku chasu sho maye vsi atributi sutnosti u viznachenij promizhok chasu Ci chastki zobrazhuyut uves promizhok chasu odniyeyi biznes sutnosti Napriklad tablicya EmployeeContracts mozhe mati hronologichnu informaciyu dlya vidstezhennya kontraktnih robochih godin Biznes klyuch dlya odnogo kontraktu bude identichnim neunikalnim v oboh ryadkah ale surogatnij klyuch dlya kozhnogo ryadka unikalnij SurrogateKey BusinessKey EmployeeName WorkingHoursPerWeek RowValidFrom RowValidTo1 BOS0120 Dzhon Smit 40 2000 01 01 2000 12 3156 P0000123 Bob Braun 25 1999 01 01 2011 12 31234 BOS0120 Dzhon Smit 35 2001 01 01 2009 12 31 Deyaki proektuvalniki baz danih sistematichno vikoristovuyut surogatni klyuchi nezalezhno vid pridatnosti inshih potencijnih klyuchiv todi yak inshi za nayavnosti vikoristovuvatimut klyuch uzhe prisutnij u danih Deyaki alternativni nazvi zgenerovanij sistemoyu klyuch opisuyut radshe sposib generaciyi novih surogatnih znachen a ne prirodu surogatnogo konceptu Pidhodi do generaciyi surogativ vklyuchayut Universally Unique Identifiers UUID Globally Unique Identifiers GUID Identifikatori ob yekta OID Stovpchik identifikator v en chi SQL Server IDENTITY chi IDENTITY n n SEQUENCE chi GENERATED AS IDENTITY v Oracle pochinayuchi z versiyi 12 1 SEQUENCE v SQL Server pochinayuchi z versiyi 2012 SERIAL u PostgreSQL abo IBM Informix AUTO INCREMENT u MySQL AUTOINCREMENT u SQLite Tip danih Lichilnik angl AutoNumber ros Schyotchik u Microsoft Access AS IDENTITY GENERATED BY DEFAULT v IBM DB2 Stovpchik identifikator realizovanij u DDL u Teradata Poslidovnist tablici koli poslidovnist obchislyuyetsya proceduroyu ta tabliceyu poslidovnosti z polyami id sequenceName sequenceValue ta incrementValuePerevagiNezminnist Surogatni klyuchi ne zminyuyutsya poki isnuye ryadok Ce maye nastupni perevagi Zastosunki ne mozhut vtratiti posilannya na ryadki bazi danih adzhe identifikator nikoli ne zminyuyetsya Dani pervinnogo chi prirodnogo klyucha zavzhdi mozhut buti zmineni navit yaksho baza danih ne pidtrimuye kaskadni onovlennya zv yazanih zovnishnih klyuchiv Zmini vimog Atributi sho unikalno identifikuyut sutnist mozhut zminyuvatisya sho mozhe anulyuvati pridatnist prirodnih klyuchiv Rozglyanemo nastupnij priklad Merezhne im ya pracivnika obrano yak prirodnij klyuch Pislya zlittya z inshoyu kompaniyeyu neobhidno dodati novih pracivnikiv Deyaki novi merezhni imena porodzhuyut konflikti oskilki voni generuvalisya nezalezhno koli kompaniyi isnuvali okremo Zazvichaj u takih vipadkah do prirodnogo klyucha povinen dodavatisya novij atribut napriklad stovpchik original company Z surogatnim klyuchem lishe tablicya sho viznachaye surogatnij klyuch maye zaznati zmin Z prirodnimi klyuchami vsi tablici a mozhlivo j inshe sumizhne programne zabezpechennya sho yih vikoristovuyut zaznayut zmin Deyaki problemni galuzi nechitko identifikuyut pridatnij prirodnij klyuch Surogatni klyuchi unikayut viboru prirodnogo klyucha yakij mozhe buti nekorektnim Produktivnist Surogatni klyuchi pragnut buti kompaktnogo tipu danih yak ot chotiribajtni cili chisla Ce dozvolyaye bazi danih zapituvati odin klyuchovij stovpchik shvidshe za dekilka Bilshe togo nenadlishkove poshirennya klyuchiv prizvodit do cilkovitogo balansu rezultatnogo b dereva indeksu Surogatni klyuchi ye takozh deshevshimi dlya z yednan porivnyuyutsya menshe stovpchikiv za skladeni klyuchi Sumisnist Pri vikoristanni deyakih sistem rozrobki zastosunkiv baz danih drajveriv i sistem ob yektno relyacijnogo vidobrazhennya yak ot Ruby on Rails abo Hibernate nabagato legshe vikoristovuvati cili chisla chi GUID yak surogatni klyuchi dlya kozhnoyi tablici zamist prirodnih klyuchiv zadlya pidtrimki agnostichnih operacij nad sistemoyu bazi danih i vidobrazhennya ob yekta v ryadok Odnoridnist Koli kozhna tablicya maye odnoridnij surogatnij klyuch deyaki zavdannya mozhut buti legko avtomatizovani shlyahom napisannya kodu nezalezhnim vid tablic sposobom Validaciya Mozhlivo sproektuvati klyuchi znachennya sho vidpovidayut zagalnovidomim shablonam chi strukturam yaki mozhut buti avtomatichno verifikovani Napriklad klyuchi priznacheni dlya vikoristannya u deyakih stovpchikah deyakih tablic mozhe buti sproektovano inakshe nizh ti yaki priznacheni dlya inshogo stovpchika chi tablici takim chinom sproshuyuchi viyavlennya pomilok zastosunku za yakih klyuchi mozhut buti pereplutani Prote cya harakteristika surogatnih klyuchiv nikoli ne maye vikoristovuvatisya dlya keruvannya bud yakoyu logikoyu zastosunku adzhe vona porushuye principi normalizaciyi baz danih NedolikiDizasociaciya Znachennya zgenerovanih surogatnih klyuchiv ne stosuyutsya realnogo sensu danih u ryadku Pri perevirci ryadka z zovnishnim klyuchem na inshu tablicyu za dopomogoyu surogatnogo klyucha znachennya ostannogo ne mozhe buti rozriznene na osnovi samogo klyucha Kozhen zovnishnij klyuch povinen buti z yednanij dlya otrimannya pov yazanogo elementu danih Ce takozh uskladnyuye audit dzherelo cherez neochevidnist nekorektnih danih Surogatni klyuchi neprirodni dlya eksportovanih i spilnih danih Osoblivo skladnim ye te sho tablici z dvoh v inshomu vipadku odnakovih shem napriklad testova ta shema rozrobki mozhut mati zapisi ekvivalentni u biznes rozuminni ale z riznimi klyuchami Ce mozhna pom yakshiti eksportuyuchi ne surogatni klyuchi a lishe perehidni dani najochevidnishe u vikonuvanih zastosunkah sho mayut zhive pidklyuchennya do bazi Optimizaciya zapitiv Relyacijni bazi danih pripuskayut zastosuvannya unikalnogo indeksu yak pervinnogo klyucha tablici Unikalnij indeks sluguye dvom cilyam 1 zabezpechennyu cilisnosti sutnostej oskilki dani pervinnogo klyucha povinni buti unikalnimi po ryadkah ta 2 shvidkomu poshuku ryadkiv pri zapitah Oskilki surogatni klyuchi zaminyuyut atributi identifikatori tablici prirodni klyuchi yaki ye najzapituvanishimi to optimizator zapitiv zmushenij skanuvati vsyu tablicyu pri zadovolenni podibnih zapitiv Zasobom povnogo skanuvannya tablici ye zastosuvannya indeksiv na atributi identifikatori chi yih mnozhini Koli taki mnozhini ye potencijnimi klyuchami indeks mozhe buti unikalnim Ci dodatkovi indeksi odnak zajmayut diskovij prostir i spovilnyuyut vstavki ta viluchennya Normalizaciya Surogatni klyuchi mozhut prizvesti do povtoryuvanih znachen u bud yakih prirodnih klyuchah Unemozhlivlennya takih dublikativ ye chastinoyu realizaciyi sistemi baz danih Modelyuvannya biznes procesiv Oskilki surogatni klyuchi neprirodni to pid chas modelyuvannya biznes vimog mozhut z yavlyatisya vadi Biznes vimogi pokladayuchis na prirodnij klyuch zgodom potrebuyut translyaciyi v surogatnij Odniyeyu zi strategij ye chitke rozmezhuvannya logichnoyi modeli v yakij nemaye surogatnih klyuchiv ta yiyi fizichnoyi realizaciyi dlya zabezpechennya togo sho logichna model korektna ta dostatno normalizovana a takozh togo sho fizichna model ye korektnoyu realizaciyeyu logichnoyi Vipadkove rozkrittya Vlasnicka informaciya mozhe vitikati u razi vikoristannya generatoriv poslidovnih klyuchiv Shlyahom vidnimannya poperedno ta neshodavno zgenerovanih poslidovnih klyuchiv mozhna z yasuvati kilkist vstavlenih ryadkiv za deyakij period chasu Ce mozhe vikriti napriklad kilkist tranzakcij abo novih akauntiv za period Isnuyut kilka sposobiv podolannya ciyeyi problemi zbilshennya poslidovnogo chisla na dovilne znachennya generuvannya vipadkovogo klyucha na kshtalt UUIDVipadkovi pripushennya Poslidovno zgenerovani surogatni klyuchi mozhut pripuskati sho podiyi z bilshim znachennyam stalisya pislya podij z menshim Ce ne obov yazkovo tak oskilki taki znachennya ne garantuyut chasovu poslidovnist adzhe mozhlivi vidmovi u vstavkah i zalishennya rozriviv yaki mozhut buti zapovneni piznishe Yaksho hronologiya ye vazhlivoyu to data j chas povinni zapisuvatisya okremo Div takozhIdentifikator ob yekta en Prirodnij klyuchPrimitkihttps elib lntu edu ua sites default files elib upload ENP Savarin Lepkij teoretic lec5 html Gall P A V Oulett Dzh Todd S Dzh P 1976 Relations and Entities U Nizhssen Dzherard Mariya red Modelling in Data Base Management Systems Pivnichna Gollandiya Dejt 1998 UUID PostgreSQL anglijskoyu a href wiki D0 A8 D0 B0 D0 B1 D0 BB D0 BE D0 BD Cite web title Shablon Cite web cite web a Obslugovuvannya CS1 Storinki z parametrom url status ale bez parametra archive url posilannya UNIQUEIDENTIFIER MSDN anglijskoyu a href wiki D0 A8 D0 B0 D0 B1 D0 BB D0 BE D0 BD Cite web title Shablon Cite web cite web a Obslugovuvannya CS1 Storinki z parametrom url status ale bez parametra archive url posilannya Create Table Oracle Database anglijskoyu Oracle Corporation a href wiki D0 A8 D0 B0 D0 B1 D0 BB D0 BE D0 BD Cite web title Shablon Cite web cite web a Obslugovuvannya CS1 Storinki z parametrom url status ale bez parametra archive url posilannya Create Sequence Transact SQL MSDN anglijskoyu a href wiki D0 A8 D0 B0 D0 B1 D0 BB D0 BE D0 BD Cite web title Shablon Cite web cite web a Obslugovuvannya CS1 Storinki z parametrom url status ale bez parametra archive url posilannya