Реляциялық дерекқорлардағы түйін кілт: анықтама, түрлері (табиғи, жасалған), және деректерді бірегей анықтау мақсаты. Дерекқорыңызды тиімді басқарыңыз!
Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
Реляциялық деректер базасының түсінігі
Relational databases concept
Реляциялық деректер базасы моделінде, бастапқы кілт – қатынастағы (кестедегі) түйіннің (жолдың) бірегей түрде анықталуын қамтамасыз ететін минималды атрибуттар (бағандар) жиынтығының нақты таңдауы болып табылады. Жай тілмен айтқанда, бастапқы кілт – "қандай атрибуттар жазбаны анықтайды", ал қарапайым жағдайларда ол бір атрибуттан: бірегей идентификатордан тұрады. Бастапқы кілт – кандидат кілттің (минималды суперкілт) таңдауы; кез келген басқа кандидат кілт – балама кілт. Бастапқы кілт нақты әлемдегі деректерден құралуы мүмкін, мұндай жағдайда ол табиғи кілт деп аталады, ал кілт ретінде жұмыс істеу үшін жасалған және деректер базасының сыртында идентификация үшін қолданылмаған атрибут – жасалма кілт деп аталады. Мысалы, адамдар туралы деректер базасында (белгілі бір ұлтқа жататын) туған уақыты мен орны табиғи кілт бола алады. Ұлттық идентификациялық нөмір – табиғи кілт ретінде қолданылуы мүмкін атрибуттың тағы бір мысалы.
In the relational model of databases, a primary key is a specific choice of a minimal set of attributes (columns) that uniquely specify a tuple (row) in a relation (table). Informally, a primary key is "which attributes identify a record," and in simple cases constitute a single attribute: a unique ID. More formally, a primary key is a choice of candidate key (a minimal superkey); any other candidate key is an alternate key. A primary key may consist of real world observables, in which case it is called a natural key, while an attribute created to function as a key and not used for identification outside the database is called a surrogate key. For example, for a database of people (of a given nationality), time and location of birth could be a natural key. National identification number is another example of an attribute that may be used as a natural key.
Дизайн
Реляциялық деректер базасы терминдерінде негізгі кілт формасымен немесе функциясымен негізгі емес кілттен ешқандай айырмасы жоқ. Іс жүзінде, әртүрлі себептер кез келген кілтті басымдықпен таңдауға ықпал етуі мүмкін. Негізгі кілт тағайындамасы кестедегі деректер үшін "артықшылықты" идентификаторды көрсетуі мүмкін, немесе негізгі кілт басқа кестелерден сыртқы кілт сілтемелері үшін қолданылатынын, немесе кестедегі семантикалық емес, техникалық ерекшелікті білдіруі мүмкін. Кейбір тілдер мен бағдарламалық құралдарда негізгі кілтті анықтау үшін арнайы синтаксистік мүмкіндіктер бар (мысалы, SQL-дегі PRIMARY KEY шектеуі). Реляциялық модель, реляциялық есептеу және реляциялық алгебра арқылы көрініс тапқандай, негізгі кілттерді және басқа кілт түрлерін ажыратпайды. Негізгі кілттер SQL стандартына негізінен қолданба бағдарламашысы үшін қолайлы болу мақсатында қосылды. Негізгі кілттер өсуімен бірге саналған бүтін сан, әмбебап бірегей идентификатор (UUID) немесе Hi/Lo алгоритмін пайдаланып жасалуы мүмкін.
In relational database terms, a primary key does not differ in form or function from a key that isn't primary. In practice, various motivations may determine the choice of any one key as primary over another. The designation of a primary key may indicate the "preferred" identifier for data in the table, or that the primary key is to be used for foreign key references from other tables or it may indicate some other technical rather than semantic feature of the table. Some languages and software have special syntax features that can be used to identify a primary key as such (e. g. the PRIMARY KEY constraint in SQL). The relational model, as expressed through relational calculus and relational algebra, does not distinguish between primary keys and other kinds of keys. Primary keys were added to the SQL standard mainly as a convenience to the application programmer. Primary keys can be an integer that is incremented, a universally unique identifier (UUID) or can be generated using Hi/Lo algorithm.
Сурогат кілттер
Кейбір жағдайларда қатынастағы туплды бірегей анықтайтын табиғи кілтті бағдарламалық жасақтаманы әзірлеуде пайдалану қиын болуы мүмкін. Мысалы, ол бірнеше бағандарды немесе үлкен мәтіндік өрістерді қамтуы мүмкін. Мұндай жағдайларда, негізгі кілт ретінде суррогат кілтті пайдалануға болады. Басқа жағдайларда қатынас үшін бірнеше үміткер кілт болуы мүмкін, ал ешбір үміткер кілт анық артықшылыққа ие болмайды. Бір үміткер кілттің басқаларына қарағанда жасанды басымдығын беруді болдырмау үшін суррогат кілтті негізгі кілт ретінде қолдануға болады. Негізгі кілттер бағдарламашыға көбінесе ыңғайлы болу үшін ғана қажет болғандықтан, дерекқоры қолданбаларын жобалауда суррогат негізгі кілттер жиі, кейде тіпті толығымен қолданылады. Суррогат негізгі кілттердің танымалдылығына байланысты, көптеген әзірлеушілер, тіпті кейбір теоретиктер де суррогат негізгі кілттерді реляциялық деректер моделінің ажырамас бөлігі деп санайды. Бұл, көбінесе, принциптердің объектіге бағытталған бағдарламалау моделінен реляциялық модельге көшуіне байланысты, гибридті объекті-реляциялық модельді құруға әкелді. ORM-де, белсенді жазба үлгісі сияқты, негізгі кілттерге қосымша шектеулер қойылады:
In some circumstances the natural key that uniquely identifies a tuple in a relation may be cumbersome to use for software development. For example, it may involve multiple columns or large text fields. In such cases, a surrogate key can be used instead as the primary key. In other situations there may be more than one candidate key for a relation, and no candidate key is obviously preferred. A surrogate key may be used as the primary key to avoid giving one candidate key artificial primacy over the others. Since primary keys exist primarily as a convenience to the programmer, surrogate primary keys are often used, in many cases exclusively, in database application design. Due to the popularity of surrogate primary keys, many developers and in some cases even theoreticians have come to regard surrogate primary keys as an inalienable part of the relational data model. This is largely due to a migration of principles from the object oriented programming model to the relational model, creating the hybrid object–relational model. In the ORM like active record pattern, these additional restrictions are placed on primary keys:
Негізгі кілттер өзгермейтін болуы керек, яғни ешқашан өзгертілмеуі немесе қайта қолданылмауы керек; олар байланысты жазбамен бірге жойылуы керек. Негізгі кілттер анонимді бүтін сан немесе сандық идентификаторлар болуы тиіс. Алайда, бұл шектеулердің ешқайсысы реляциялық модельдің немесе кез келген SQL стандартының бөлігі емес. Дерекқоры мен қолданбаны жобалау кезінде негізгі кілт мәндерінің өзгермеуіне қатысты шешім қабылдағанда тиісті сақтық шараларын қолдану қажет. Кейбір дерекқоры жүйелері тіпті UPDATE SQL операторын пайдаланып негізгі кілт бағандарындағы мәндерді өзгертуге болмайды деп көрсетеді.
Primary keys should be immutable, that is, never changed or re used; they should be deleted along with the associated record. Primary keys should be anonymous integer or numeric identifiers. However, neither of these restrictions is part of the relational model or any SQL standard. Due diligence should be applied when deciding on the immutability of primary key values during database and application design. Some database systems even imply that values in primary key columns cannot be changed using the UPDATE SQL statement.
Қосалқы кілт
Көбінесе, бір кандидат кілт негізгі кілт ретінде таңдалады. Қалған кандидат кілттер балама кілттерге айналады, олардың әрқайсысына дубликаттарды болдырмау үшін UNIQUE шектеуі қойылуы мүмкін (бірегей бағандағы екіұстама жазба жарамсыз). Балама кілттер бір кестені таңдау кезінде немесе WHERE шарттарында сүзу кезінде негізгі кілт сияқты қолданылуы мүмкін, бірақ әдетте бірнеше кестені қосу үшін қолданылмайды.
Typically, one candidate key is chosen as the primary key. Other candidate keys become alternate keys, each of which may have a UNIQUE constraint assigned to it in order to prevent duplicates (a duplicate entry is not valid in a unique column). Alternate keys may be used like the primary key when doing a single table select or when filtering in a where clause, but are not typically used to join multiple tables.