Ключи обычно используют для дости- |
|
жения следующих целей: |
|
- исключение дублирования значений в |
|
ключевых атрибутах (остальные атрибу- |
|
ты в расчет не принимаются); |
|
- упорядочение кортежей. Возможно |
|
упорядочение по возрастанию или убы- |
|
ванию значений всех ключевых атри- |
|
бутов, а также смешанное упорядочение |
|
(по одним - |
возрастание, по другим – |
убывание); |
|
- ускорение работы с кортежами |
|
отношения; |
|
- организация связывания таблиц. |
|
2. 8. Отсутствие упорядоченности
кортежей
Свойство отсутствия упорядочен- ности кортежей отношения также является следствием определения отношения-экземпляра как множе- ства кортежей. Отсутствие требо- вания к поддержанию порядка на множестве кортежей отношения дает дополнительную гибкость СУБД при хранении баз данных во 
внешней памяти и при выполнении 
запросов к базе данных.
33
Это не противоречит тому, что при формулировании запроса к БД, например, на языке SQL можно потребовать сортировки результи- рующей таблицы в соответствии со значениями некоторых столбцов. Такой результат, вообще говоря, не отношение, а некоторый упорядо- ченный список кортежей.
34
2. 9. Отсутствие упорядоченности |
|||||
|
|
атрибутов |
|
|
|
Атрибуты отношений не упорядочены, |
|||||
поскольку |
по |
определению |
схема |
||
отношения есть множество пар {имя |
|||||
атрибута, имя домена}. Для ссылки на |
|||||
значение |
|
атрибута |
в |
кортеже |
|
отношения |
всегда используется имя |
||||
атрибута. Это |
свойство |
теоретически |
|||
позволяет, например, модифицировать |
|||||
схемы су-ществующих отношений не |
|||||
только |
путем |
добавления |
новых |
||
атрибутов, но и путем удаления |
|||||
существующих. |
|
|
35 |
||
|
|
|
|
|
|
Однако в большинстве существу- ющих систем такая возможность не допускается, и хотя упорядочен- ность набора атрибутов отношения явно не требуется, часто в качестве неявного порядка атрибутов ис- пользуется их порядок в линейной форме определения схемы отно- шения.
36
2. 10. |
Атомарность значений |
||
|
атрибутов |
|
|
Значения всех атрибутов явля- |
|||
ются атомарными. Это следует из |
|||
определения домена как потенци- |
|||
ального множества значений про- |
|||
стого типа данных, то есть среди |
|||
значений домена не могут содер- |
|||
жаться множества значений (отно- |
|||
шения). |
Принято говорить, что в |
||
реляционных |
базах |
данных |
|
допускаются |
только нормализованные |
||
отношения |
или |
отношения, |
|
представленные в первой нормальной |
|||
форме. |
|
|
|
|
|
|
37 |
Нормализованные отношения сос- |
тавляют основу классического реля- |
ционного подхода к организации баз |
данных. Они обладают некоторыми |
ограничениями (не любую информа- |
цию удобно представлять в виде |
плоских таблиц), но существенно |
упрощают манипулирование данны- |
ми. Проектирование БД на основе |
нормализации мы рассмотрим от- |
дельно на одной из очередных |
лекций. |
38 |
3. Реляционная модель данных |
Когда в предыдущих разделах |
мы говорили об основных понятиях |
реляционных баз данных, мы не |
опирались на какую-либо конкрет- |
ную реализацию. Эти рассуждения |
в равной степени относились к |
любой системе, при построении |
которой использовался реляцион- |
ный подход. Другими словами, мы |
использовали понятия так называ- |
емой реляционной модели данных. |
39 |
Модель |
данных |
описывает |
||
неко-торый набор родовых |
||||
понятий и признаков, которыми |
||||
должны |
|
обладать |
все |
|
конкретные |
СУБД |
и |
||
управляемые ими базы дан-ных, |
||||
если они основываются на этой |
||||
модели. |
|
Наличие |
модели |
|
данных |
позволяет |
сравнивать |
||
конкретные |
реализации, |
ис- |
||
пользуя один общий язык. |
|
|||
Хотя понятие |
модели данных |
является общим, и можно гово- |
|
рить о иерархической, сетевой, |
|
некоторой семантической и т.д. |
|
моделях данных, нужно отме- |
|
тить, что это понятие было вве- |
|
дено в обиход применительно к |
|
реляционным системам и наи- |
|
более |
эффективно |
используется |
именно в этом |
контексте. |
|