Дерекқордағы жасалма кілттер туралы

Кіріспе

Модельделген әлемдегі нысанның немесе деректер базасындағы объектінің бірегей идентификаторы. Деректер базасындағы ауыстыру кілті (немесе синтетикалық кілт, псевдокілт, нысан идентификаторы, дерексіз кілт немесе техникалық кілт) – модельделген әлемдегі нысанның немесе деректер базасындағы объектінің бірегей идентификаторы. Ауыстыру кілті, табиғи (немесе бизнес) кілттен айырмашылығы, қолданба деректерінен туындамайды.

Тұрақтылық

Сурогат кілттер, әдетте, жол бар болған кезде өзгермейді. Бұл мынадай артықшылықтар береді:

Қолданбалар дерекқорындағы қатарға сілтемелерін жоғалта алмайды (өйткені идентификатор өзгермейді). Негізгі немесе табиғи кілт деректері әрқашан өзгертілуі мүмкін, тіпті байланысты сыртқы кілттерде каскадты жаңартуларды қолдамайтын дерекқорларда да.

Талаптардың өзгеруі

Жеке тұлғаны бірегей анықтайтын атрибуттар өзгеруі мүмкін, бұл табиғи кілттердің дұрыстығын жояды. Мысалы, қарастырайық:

Қызметкердің желідегі пайдаланушы аты табиғи кілт ретінде таңдалынса, екінші компаниямен біріккен кезде жаңа қызметкерлерді қосу қажет болады. Кейбір жаңа пайдаланушы аты қақтығыстар тудыруы мүмкін, себебі олардың аты компаниялар бөлек болған кезде тәуелсіз түрде жасалған. Мұндай жағдайларда, әдетте табиғи кілтке қосымша атрибут қосу қажет (мысалы, бастапқы компания туралы баған). Ал, жасалма кілтпен тек жасалма кілтті анықтайтын кесте ғана өзгертіледі. Табиғи кілттерді пайдаланғанда, табиғи кілтті қолданатын барлық кестелер (сондай-ақ, мүмкін, басқа да байланысты бағдарламалық құралдар) өзгертілуі керек. Кейбір салаларда қолайлы табиғи кілтті анықтау қиынға түседі. Жасалма кілттер, дұрыс емес болуы мүмкін табиғи кілтті таңдау қателігінен сақтайды.

Өнер көрсету

Сурогат кілттер көбінесе төрт байттық бүтін сан сияқты ықшам дерек типі болып табылады. Бұл дерекқорына бірнеше бағанға қарағанда бір кілт бағаны бойынша жылдам сұраныс жасауға мүмкіндік береді. Сонымен қатар, кілттердің қайталамасыз таралуы нәтижедегі B-ағаш индексінің толыққанды тепе-теңдігіне әкеледі. Сурогат кілттерді біріктіру (қосылу) құрама кілттерге қарағанда арзанға түседі, себебі салыстыру үшін азырақ баған қажет.

Бір-біріне үйлесімділік

Бірнеше деректер қорын қолдануды дамыту жүйелерін, драйверлерді және Ruby on Rails немесе Hibernate сияқты объекті-реляциялық карталау жүйелерін пайдаланғанда, деректер қоры жүйесіне тәуелсіз операцияларды қолдау және объектілерді қатарларға шамамен бейнелеу үшін әр кестеге табиғи кілттердің орнына бүтін сан немесе GUID түрдегі жасалма кілттерді пайдалану әлдеқайда ыңғайлы.

Біркелкілік

Барлық кестеде біркелкі түрде жасалған жалған кілт болғанда, кейбір жұмыстарды кестеге тәуелсіз код жазу арқылы автоматтандыру оңай болады.

Жақсылық тексеру

Белгілі бір үлгіге немесе құрылымға сәйкес келетін, автоматты түрде тексерілетін негізгі мәндерді жобалау мүмкін. Мысалы, кейбір кестелердің бір бағанында пайдаланылатын кілттер, басқа бағандарда немесе кестелерде пайдаланылатын кілттерден "ажыратылатын" етіп жасалуы мүмкін, осылайша кілттердің орны ауысқан қолданба қателерін анықтау оңайлатылады. Дегенмен, орнын алмастырушы кілттердің осы ерекшелігін ешқашан қолданбалардың логикасын басқару үшін пайдаланбау керек, себебі бұл деректер базасын қалыпқа келтіру принциптерін бұзады.

Қатысудан шығару

Шығарылған суррогат кілттердің мәндері қатардағы деректердің нақты мағынасына ешқандай қатысы жоқ. Басқа кестеге сілтеме жасайтын сыртқы кілт бар қатарды суррогат кілт арқылы тексергенде, суррогат кілтінің өзінен оның мағынасын анықтау мүмкін емес. Сыртқы кілтке байланысты дерек элементін көру үшін әр сыртқы кілттің сәйкес келуін тексеру қажет. Егер деректер базасының тиісті шектеулері орнатылмаса немесе референттік тұтастығы қолданылмаған ескі жүйеден деректер импортталса, бастапқы кілт мәніне сәйкес келмейтін, демек жарамсыз сыртқы кілт мәні болуы мүмкін. (Осы тұрғыда, C. J. Date суррогат кілттердің мәнсіздігін артықшылық деп есептейді.) Мұндай қателерді анықтау үшін сыртқы кілттері бар кесте мен негізгі кілттері бар кесте арасында сол жақтан сыртқы қосылыс (left outer join) қолданылатын сұраныс жасау керек, бұл жазбаны ажыратуға қажетті өрістерден басқа екі кілт өрісін де көрсетеді; барлық жарамсыз сыртқы кілт мәндері үшін негізгі кілт бағаны NULL болады. Мұндай тексеруді жүргізудің қажеттілігі соншалық, Microsoft Access тіпті "Сәйкессіз жазбаларды табу" (Find Unmatched Query) шеберімен жабдықталған, ол пайдаланушыны диалог арқылы өткізіп, тиісті SQL сұранысын автоматты түрде құрайды. (Дегенмен, мұндай сұраныстарды қолмен жасау да қиын емес.) "Сәйкессіз жазбаларды табу" сұраныстары көбінесе ескі деректерді мұра еткен кезде деректерді тазалау процесінің бір бөлігі ретінде қолданылады. Суррогат кілттер деректерді экспорттау және бөлісу үшін табиғи емес. Ерекше қиындық – екі толыққанды бірдей схемадан (мысалы, сынақ және дамыту схемалары) алынған кестелерде бизнес тұрғысынан теңдес жазбалардың болуы, бірақ әртүрлі кілттері болуы мүмкін. Бұл мәселені суррогат кілттерді экспорттамау арқылы шешуге болады, тек уақытша деректер ретінде (мысалы, деректер базасына «тікелей» қосылысы бар қолданбаларды іске қосу кезінде). Егер суррогат кілттер табиғи кілттерді ығыстырса, домендік референттік тұтастық бұзылады. Мысалы, клиенттердің бас кестесінде бір клиенттің әртүрлі клиент идентификаторларымен бірнеше жазбасы болуы мүмкін, тіпті табиғи кілт (клиент аты, туған күні және электрондық пошта мекенжайының комбинациясы) бірегей болса да. Мұндай жағдайды болдырмау үшін кестедегі табиғи кілт ығыстырылмауы керек: оны табиғи кілт өрістерінің комбинациясы бойынша құрылған бірегей индекс ретінде іске асырылатын бірегей шектеу ретінде сақтау қажет.

The values of generated surrogate keys have no relationship to the real world meaning of the data held in a row. When inspecting a row holding a foreign key reference to another table using a surrogate key, the meaning of the surrogate key's row cannot be discerned from the key itself. Every foreign key must be joined to see the related data item. If appropriate database constraints have not been set, or data imported from a legacy system where referential integrity was not employed, it is possible to have a foreign key value that does not correspond to a primary key value and is therefore invalid. (In this regard, C. J. Date regards the meaninglessness of surrogate keys as an advantage.) To discover such errors, one must perform a query that uses a left outer join between the table with the foreign key and the table with the primary key, showing both key fields in addition to any fields required to distinguish the record; all invalid foreign key values will have the primary key column as NULL. The need to perform such a check is so common that Microsoft Access actually provides a "Find Unmatched Query" wizard that generates the appropriate SQL after walking the user through a dialog. (It is, however, not too difficult to compose such queries manually.) "Find Unmatched" queries are typically employed as part of a data cleansing process when inheriting legacy data. Surrogate keys are unnatural for data that is exported and shared. A particular difficulty is that tables from two otherwise identical schemas (for example, a test schema and a development schema) can hold records that are equivalent in a business sense, but have different keys. This can be mitigated by not exporting surrogate keys, except as transient data (most obviously, in executing applications that have a "live" connection to the database). When surrogate keys supplant natural keys, then domain specific referential integrity will be compromised. For example, in a customer master table, the same customer may have multiple records under separate customer IDs, even though the natural key (a combination of customer name, date of birth, and e mail address) would be unique. To prevent compromise, the natural key of the table must not be supplanted: it must be preserved as a unique constraint, which is implemented as a unique index on the combination of natural key fields.

Сұранысты оңтайландыру

Реляциялық деректер қоры кестедегі бастапқы кілтке бірегей индекс қолданылады деп есептейді. Бірегей индекс екі мақсатқа қызмет етеді: (i) нысан тұтастығын сақтау, себебі бастапқы кілт деректері қатарлар бойынша бірегей болуы тиіс, және (ii) сұраныс кезінде қатарларды жылдам іздеу. Балама кілттер кестенің анықтамалық атрибуттарын – табиғи кілтті – алмастырады, ал анықтамалық атрибуттар сұранысқа түсуі мүмкін болғандықтан, сұранысты оңтайландырушы мүмкін сұраныстарды орындау кезінде толық кесте скандалауын жүргізуге мәжбүр болады. Толық кесте скандалау мәселесін шешу үшін анықтамалық атрибуттарға немесе олардың жиынтығына индекстер қолдану қажет. Егер мұндай жиынтықтар өзі кандидат кілт болса, индекс бірегей индекс болуы мүмкін. Алайда, бұл қосымша индекстер дискіде орын алып, жазбаларды қосу және жою операцияларын баяулатады.

Нормалдастыру

Сурогат кілттер табиғи кілттерде дубликат мәндердің пайда болуына мүмкіндік береді. Дубликаттануды болдырмау үшін, егер шектеулер кейін қосылса, SQL-дің CREATE TABLE немесе ALTER TABLE ADD CONSTRAINT операторларын пайдаланып кесте құрылған кезде табиғи кілттердің бірегейлік шектеулер ретіндегі қызметін сақтау қажет.

Бизнес-процестерді модельдеу

Серіктестік кілттер табиғи болмағандықтан, бизнес-талаптарды модельдеу кезінде қателер туындауы мүмкін. Бизнес-талаптар табиғи кілтке сүйенгендіктен, оларды серіктестік кілтке аудастыру қажет. Осыған орай, логикалық модельде (серіктестік кілттер қолданылмайды) және осы модельдің физикалық іске асырылуы арасында айқын шекара жүргізу стратегиясы қолданылады. Бұл логикалық модельдің дұрыс және лайықты нормализацияланғанын, ал физикалық модельдің логикалық модельді дұрыс іске асырғанын қамтамасыз етеді.

Қалайсыз болжамдар

Бірінен соң бірі жасалған алмастырушы кілттер, кілт мәні жоғарырақ оқиғалар, кілт мәні төменірек оқиғалардан кейін болғанын көрсете алады. Бірақ бұл міндетті түрде дұрыс емес, себебі мұндай мәндер уақыт реттілігін кепілдемейді. Өйткені, деректерді енгізу сәтте қателер болуы мүмкін, соның салдарынан аралықтар пайда болып, олар кейіннен толтырылуы мүмкін. Егер уақыт реттілігі маңызды болса, онда күні мен уақыты жеке жазылуы керек.