9

т.н. реляционной алгебры, и поэтому хорошо формализована;

•имеется простой и единообразный способ представления данных

ввиде таблиц;

•осуществляется надежное обеспечение целостности и защиты данных и некоторые другие.

Важным достоинством реляционной модели данных является то, что на основе уже имеющихся схем отношений можно получать новые схемы, которые ранее в файле базы данных не были представлены. Таким способом соответствующая СУБД позволяет получать ответы на незапланированные прикладными программами информационные запросы.

Необходимо отметить, что РБД не лишены и определенных недостатков: медленность работы для больших БД, жесткость структуры данных и некоторые другие. Однако для персональных компьютеров и не очень больших БД в настоящее время используются исключительно реляционные модели БД.

Итак, перечислим исходные компоненты реляционной модели дан-

ных, основанной на совокупности отношений:

•все множество объектов (записей) предметной области, которую описывает БД, разделяется на несколько типов, каждый из которых представляется своей таблицей;

•каждому типу объектов соответствует определенный набор атрибутов, который определяет содержание соответствующей данному типу объектов таблице;

•каждый тип объектов имеет свои признаки или характеристики – атрибуты, значения которых содержатся в полях – в столбцах таблицы;

•каждому конкретному объекту данного типа соответствует определенный набор значений этих атрибутов, соответствующий строке в таблице;

•атрибут (или набор атрибутов), однозначно определяющий объект

втаблице (т.е. строку в таблице), называется первичным ключом объекта;

•в таблицах имеются также атрибуты, являющиеся первичными ключами в других таблицах, т.н. внешние ключи, которые обеспечивают связь между таблицами в РБД.

1.2.Нормализация отношений в РБД

Самым простым примером РБД является база данных, состоящая всего из одного отношения – одной таблицы. Однако в таком случае, как правило, не будут выполняться основные требования, предъявляемые к структуре БД из-за возникающих проблем избыточности информации, нарушения целостности данных, сложности редактирования данных, низкой скорости обработки информации и т.п. Убедимся в этом на конкретном

10

примере небольшой БД, основанной на одной таблице «Поставки товаров», в которой будем хранить сведения о товарах, их цене, количестве и стоимости, а также о поставщиках, их адресах и расчетных счетах. Предположим, что эти данные будут храниться в следующей таблице (здесь приведены только первые четыре записи и всего 7 полей, хотя в реальной БД их число будет неизмеримо большим):

Анализируя структуру таблицы, необходимо прежде всего отметить, что в ней имеется повторяющаяся информация о поставщике. Кроме того, стоимость товара является избыточной информацией, так как всегда может быть получена на основе цены товара и его количества. Далее, атрибуты «Адрес» и «Счет» характеризуют только поставщика и, вообще говоря, не связаны с поставляемым товаром. Существуют и другие более тонкие недостатки в структуре такой БД.

Таким образом, на первом этапе проектирования РБД важнейшим является вопрос, какую выбрать схему отношений для данной БД из множества альтернативных вариантов, т.е. какую систему таблиц и с каким набором столбцов в каждой таблице выбрать для данной БД. Как правило, БД содержат объекты разных типов и для каждого типа объектов создается своя таблица с соответствующим набором столбцов-атрибутов объекта.

Процесс создания оптимальной схемы отношений для РБД строго формализован и называется нормализацией БД. Нормализация – это формализованная процедура, в процессе выполнения которой атрибуты данных группируются в таблицы, а таблицы, в свою очередь, в БД.

Цели нормализации следующие:

•исключить дублирование информации;

•исключить избыточность информации;

•обеспечить возможность проведения непротиворечивых и корректных изменений данных в таблицах;

•упростить и ускорить поиск информации в БД.

Процесс нормализации состоит в приведении таблиц РБД к т.н. нормальным формам. Всего существует 5 нормальных форм, которые удовлетворяют соответствующим правилам нормализации. При этом в большинстве случаев оптимальная структура БД достигается при выполнении уже первых 3 правил нормализации, которые были сформулированы для РБД Э.Ф. Коддом в 1972 году.

Чтобы таблица, а вместе с ней и БД, соответствовала 1-й нормальной форме, необходимо, чтобы все значения ее полей были атомарными (неделимыми) и невычисляемыми, а все записи – уникальными (не должно быть

11

полностью совпадающих строк). Выполняя это правило, преобразуем первоначальную таблицу к виду

Чтобы таблица соответствовала 2-й нормальной форме, необходимо, чтобы она уже находилась в 1-й нормальной форме и все неключевые поля полностью зависели от ключевого. В данной таблице на роль ключевого поля может претендовать только поле (атрибут-признак) «Товар», значения которого в таблице не повторяются. Из других полей только поле «Поставщик» непосредственно связано с поставляемым товаром – полем «Товар», а поля «Индекс», «Область», «Город» и «Счет» характеризуют только самого поставщика. Поэтому, удовлетворяя 2-му правилу нормализации, необходимо разбить (или разложить) исходную таблицу на две – соответственно «Товары»

и «Поставщики»

Проведенное преобразование называется разложением, или проектированием, БД и является обратимой операцией. Причем проектирование исходной таблицы привело, с одной стороны, к уменьшению записей (строк) во второй таблице, однако, с другой стороны, для организации связей между отдельными таблицами и обеспечения таким образом целостности БД поле «Поставщик» появилось уже в обеих таблицах, привнося этим некоторую неизбежную избыточность информации в БД. Очевидно, что в больших БД, где реально существуют сотни и тысячи записей, эта избыточность во много раз будет перекрыта уменьшением общего размера таблиц, полученных из исходной таблицы при ее разложении.

Заметим, что на роль ключевого поля таблицы «Поставщики» подходит поле «Поставщик», значения которого в этой таблице уже не повторяются. Можно отметить, что на эту роль вполне подходит и поле «Счет», значения которого также не будут повторяться, а само поле, хотя и выгля-

12

дит как набор цифр, все же является не количественной, а качественной характеристикой объекта, т.е. является атрибутом-признаком, что необходимо для ключевого поля (см. выше).

Чтобы теперь перейти к 3-й нормальной форме, необходимо прежде всего обеспечить, чтобы все таблицы БД находились во 2-й нормальной форме и все неключевые поля в таблицах зависели только от ключа таблицы и не зависели непосредственно друг от друга. Анализируя таблицу «Поставщики», можно заметить, что поля «Область» и «Город» являются зависимыми от поля «Индекс», и поэтому эта таблица не находится в 3-й нормальной форме. В связи с этим, необходимо разбить таблицу на две: оставить в таблице «Поставщики» только два «Поставщик» и «Счет», а также поле «Индекс» для обеспечения связи между таблицами,

а остальные поля выделить в новую таблицу «Адреса»,

в которой поле «Индекс», естественно, будет ключевым, так как его значения в таблице не повторяются.

Приведение БД к 4-й и 5-й нормальным формам является необходимой операцией в специальных случаях, когда между элементами БД существуют связи типа многие-ко-многим (см. ниже) и при этом необходимо обеспечить возможность точного восстановления исходной таблицы из таблиц, на которые она была спроектирована. Как уже говорилось выше, этими правилами нормализации при проектировании БД в большинстве случаев можно пренебречь.

1.3. Типы связей и ключей в РБД

Как уже отмечалось, в БД все таблицы должны быть так или иначе связаны между собой, чтобы обеспечить целостность данных, создающих информационную модель некой предметной области. Если оказалось, что одна из таблиц в создаваемой БД не имеет связей ни с одной другой таблицей, то в этом случае необходимо создавать новую БД либо рассматривать более широкую предметную область, для которой создается БД.

Связи между таблицами организуются с помощью различных ключей. Связное отношение хранит ключи двух или более объектных отношений, по этим ключам устанавливаются связи между объектами. Связное

13

отношение кроме связываемых ключей может иметь и другие атрибуты, которые будут функционально зависеть от этой связи. Ключи в связных отношениях называются внешними ключами, поскольку они являются первичными ключами других отношений.

Каждому внешнему ключу должна соответствовать строка какоголибо объектного отношения. Невыполнение этого ограничения может привести к нарушению ссылочной целостности данных. Ключ должен ссылаться на объект, который существует.

Перечислим условия и ограничения, накладываемые на отношения реляционной моделью данных, которые позволяют таблицы считать отношениями:

1. Не может быть одинаковых значений для первичных ключей, т.е. все строки таблицы должны быть в целом уникальны и определяться значением первичного ключа однозначно.

2. Все строки таблицы должны иметь одну и ту же структуру, т.е. одно и то же количество атрибутов.

3. Имена столбцов таблицы должны быть различны, а значения столбцов должны быть однотипными.

4. Значения атрибутов должны быть простыми, следовательно, отношения не могут иметь в качестве компонент другие отношения.

5. Должна соблюдаться ссылочная целостность для внешних клю-

чей.

6. Порядок следования строк в таблице несущественен - он лишь влияет на скорость доступа к строке.

Хорошо организованная база данных обеспечивает удобный доступ к хранящейся в ней информации. При правильном проектировании базы данных будет меньше затрачиваться времени и усилий на ввод данных в базу, внесение изменений и извлечение данных из базы.

Этап установки связей между таблицами нужен для того, чтобы указать, какие действия надо предпринимать для объединения содержимого таблиц, составляющих РБД. После того как пользователь установит связи между таблицами, СУБД сможет использовать эти связи для поиска связанной информации в разных таблицах базы данных.

В теории РБД существует три типа межтабличных отношений или связей: один-ко-многим, многие-ко-многим и один-к-одному (четвертый возможный тип отношений - многие-к-одному фактически сводится к первому типу, так как является его «зеркальным отражением» и в СУБД Access просто совпадает со связью один-ко-многим).

Связь один-ко-многим является наиболее распространенной в реляционных базах данных. При таком типе отношений одной записи в первой таблице могут соответствовать несколько записей во второй таблице, однако каждой записи во второй таблице соответствует не более одной записи в первой таблице, что отражает в полной мере функциональную зави-

14

симость второй таблицы от первой.

Связь многие-ко-многим означает, что каждой записи в первой таблице могут соответствовать несколько записей во второй таблице, а каждой записи во второй таблице -- несколько записей в первой таблице. В СУБД Access такой тип отношений напрямую не допускается, и во избежание такой ситуации создается еще одна вспомогательная таблица, которая связывается с обеими исходными таблицами связью типа один-ко- многим.

При связи один-к-одному каждой записи в первой таблице может соответствовать не более одной записи во второй таблице, а каждой записи во второй таблице -- не более одной записи в первой таблице. Такой тип межтабличных отношений используется тогда, когда для удобства в работе очень широкую таблицу разбивают на две с повторением одного поля в каждой либо когда из таблицы необходимо выделить часть, к которой нужно обеспечить особый режим допуска (например, конфиденциальные сведения о сотрудниках, содержащиеся в одном или нескольких полях таблицы, к которым должны иметь доступ только определенные лица).

В любом случае наличие связей (отношений) между таблицами второго и третьего типов означает, что база данных спроектирована не совсем оптимально или же просто содержит ошибки. Хорошо спроектированная база данных обычно не содержит отношений между таблицами двух последних типов.

Как уже отмечалось выше, основным достоинством любой БД является способность быстро находить и объединять информацию, хранящуюся в разных таблицах. Для решения первой задачи каждая таблица в БД должна содержать поле или набор полей, значение которого или совокупность значений которых однозначно определяет каждую запись этой таблицы. На языке БД такое поле или совокупность полей называется ключом таблицы, а точнее, первичным ключом таблицы. При этом кандидатами на роль ключа таблицы могут быть любые поля, которые содержат уникальные (неповторяющиеся) значения для каждой записи, т.н. потенциальные ключи таблицы. Если в роли ключа выступают сразу несколько полей, когда в таблице просто нет одного поля с неповторяющимися значениями, то приходится подбирать такую комбинацию полей, значение которой будет уникальным. Такой ключ называется составным ключом.

Для решения второй из названных задач -- объединения информации и организации связей между таблицами -- используются поля таблиц, имеющие совпадающие значения. При этом связь один-ко-многим образуется между первичным ключом одной таблицы, которая называется главной, и т.н. внешним, или вторичным, ключом другой таблицы, которая называется подчиненной. Значения внешнего ключа в таблице могут повторяться (отсюда термин ко-многим в названии связи), а сам внешний ключ, например поле «Поставщик» в таблице «Товары» или поле «Ин-

15

декс» в таблице «Поставщики», получил такое название потому, что при проектировании (разложении) таблицы на составляющие такое поле специально вводится в вычленяемую таблицу именно для организации связей между таблицами и обеспечения целостности данных в БД.

Таким образом, в нашей БД «Поставки товаров», состоящей из таблиц «Товары», «Поставщики» и «Адреса», необходимо организовать следующие межтабличные связи (ниже мы используем схематичное изображение межтабличных связей, совпадающее с представлением схемы связей в СУБД Access, работа в которой будет рассматриваться в последующих разделах пособия, здесь символ ∞ соответствует термину ко-многим):

Заметим в заключение, что в БД для оптимизации связей между рассмотренными выше т.н. базовыми таблицами, каждая из которых обладает первичным ключом, могут создаваться и связующие таблицы. Такие таблицы содержат только ключевые поля, представляющие собой внешние ключи, связанные с первичным ключом главной таблицы, а сами не имеют первичного ключа. Это т.н. индексные таблицы, преобразующие межтаб-

личные связи типа многие-ко-многим в связи типа один-ко-многим.

После создания совокупности таблиц, удовлетворяющих правилам нормализации, и организации межтабличных связей процесс проектирования БД, проводимый «вручную», без компьютера, заканчивается. В дальнейшем создание БД проводится с использованием средств соответствующей СУБД.

Контрольные вопросы

1.Объектная модель БД.

2.Основные понятия и термины БД.

3.Типы БД и особенности их функционирования.

4.Исходные компоненты РБД.

5.Особенности и преимущества РБД.

6.Этапы проектирования РБД.

7.Правила нормализации РБД.

8.1-я нормальная форма.

9.2-я нормальная форма.

10.3-я нормальная форма.

11.Объектные и межтабличные связи в РБД.

12.Понятие отношения в РБД.

16

13.Типы отношений в РБД.

14.Типы ключей в РБД.

15.Использование составного первичного ключа.

16.Назначение внешних ключей.

17.Условия и ограничения, накладываемые на отношения в РБД. 18.Типы связей в РБД.

19.Использование связей один-к-одному.

20.Назначение индексных таблиц.

2. СОЗДАНИЕ ТАБЛИЦ И СВЯЗЕЙ В СУБД ACCESS 2.1. Создание БД в СУБД Access

После запуска СУБД Access на экране появляется начальное диалоговое окно, в котором пользователю предлагается создать новую базу данных, запустить программу мастера создания баз данных, работающую в диалоговом режиме, или открыть существующую базу данных.

Рис. 3. Начальное диалоговое окно СУБД Access

На начальном этапе работы с БД очень полезно познакомиться с уже функционирующей БД – такой учебной БД в Access является БД «Борей» (или в нерусифицированном варианте Nothwind – северный ветер, англ.). Для этого достаточно выбрать ее название в предлагаемом списке – в диалоговом окне на рис. 3 это последняя строка, где указан обычный маршрут размещения этой БД в среде Windows.

При загрузке существующей БД ее открывают как любой документ прикладной программы в среде Windows. Что касается создания новой БД, то здесь сразу проявляются особенности работы СУБД Access. Дело в том, что все модули БД Access хранятся в одном файле, который создается именно на первоначальном этапе ее создания. Поэтому необходимо сразу же определить местоположение файла вашей БД на диске компьютера и

17

задать файлу имя. Расширением имени такого файла в СУБД Access будет

.mbd. Все изменения в файле, проводимые в БД после этого, – создание таблиц БД, их заполнение, создание межтабличных связей, создание других модулей БД и т.д. – производится по ходу работы с БД средствами самой СУБД, а не непосредственно операционной системой компьютера, как это происходит для большинства прикладных программ. Следствием этого является то, что при выходе из БД вам не будет задаваться вопрос о сохранении файла БД – все необходимые сохранения в файле БД уже проведены самой СУБД Access в ходе редактирования. Таким образом, если вы хотите сохранить старый вариант БД, то необходимо перед предварительно сохранить файл БД под другим именем, так как после открытия файла БД в СУБД Access и его дальнейшего редактирования вернуться к старой БД будет уже невозможно.

Рис. 4. Главное диалоговое окно БД Access

Что касается создания БД с помощью Мастера (программа, которая выполняет определенную процедуру в автоматическом режиме в несколько шагов в ходе диалога с пользователем), то, выполнив соответствующую команду Запуск мастера (см. рис. 3) и последовательно отвечая на предлагаемые СУБД Access вопросы, можно очень просто и быстро создать простую БД по предлагаемой в определенном Мастером списке тематике. Однако заметим, что в данном пособии при работе с БД везде, где это целесообразно, мы будем избегать использования услуг Мастеров по созданию компонент БД, так как их использование не преследует целей обучения. Дело в том, что Мастера всегда предлагают ограниченный набор вариантов уже разработанных компонент БД, и если идти по этому пути, то