59

базы данных. Для открытия защищенной паролем базы данных пользователь должен будет вводить этот пароль.

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

При установке защиты данных для каждого пользователя после выполнения команд Сервис/Защита/Пользователи и группы создается учетная запись, при необходимости – пароль. После установки защиты пользователь может запустить MS Access только в том случае, если укажет свое имя (и пароль).

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

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

База данных MS Access может быть защищена от несанкционированного доступа с помощью шифрования. Для этого предварительно следует выполнить команды Сервис/Защита/Шифровать/дешифровать, затем выбрать базу дан-

ных для шифрования. После шифрования база данных будет недоступна для чтения другим приложениям.

7.Основы проектирования реляционных баз данных

7.1.Этапы проектирования

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

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

Этап 1. Построение концептуальной модели предметной области.

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

60

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

Этап 2. Логическое проектирование – преобразование созданной концептуальной модели в концептуальную схему, реализуемую конкретной СУБД.

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

Этап 3. Физическое проектирование базы данных.

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

7.2.Построение концептуальной модели предметной области

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

Рассмотрим некоторые средства концептуального моделирования. ER-модель

ER-модель (Entity-Relationship – сущность-связь) была предложена П. Ченом

в1976 г. [ 12 ]. Информация о содержании предметной области в рамках модели изображается в структурированном графическом виде (ER-диаграмма).

Основными конструкциями модели являются сущности и связи.

61

Для ER-модели не существует единой стандартизованной системы обозначений, поэтому приводимые далее характеристики ER-диаграмм могут несколько отличаться от опубликованных в различных книгах [ 3, 4 ].

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

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

Атрибуты, однозначно идентифицирующие сущность, называются ключевыми атрибутами. Например, для сущности Накладная ключевым атрибутом будет ее номер. Ключевые атрибуты на ER-диаграмме выделяются подчеркиванием. В некоторых ситуациях из нескольких простых атрибутов может формироваться составной ключ (для сущности Поставки товаров это могут быть ат-

рибуты Артикул товара и Дата поставки).

С помощью связей на ER-диаграмме отображается взаимодействие между сущностями. Связь изображается ромбом, соединяющим связываемые сущности, внутри которого указывается вид связи (обычно выражается глаголом). Например, сущности Директор и Сотрудник могут быть соединены связью Руководит. Между двумя сущностями может быть установлено несколько связей: Про-

давец – Продает – Товар, Продавец – Фасует – Товар, Продавец – Учитывает – Товар. Количество сущностей, участвующих в связи, определяет ее степень. Связь Руководит между сущностями Директор и Сотрудник имеет степень, равную двум.

Связи могут иметь разный характер:

«один к одному» (1 : 1) – один экземпляр сущности Директор связан с одним экземпляром сущности Магазин;

«один ко многим» (1 : М) – один экземпляр сущности Директор связан со многими экземплярами сущности Продавец;

62

«многие ко многим» (М : М) – многие экземпляры сущности Продавец связаны со многими экземплярами сущности Товар.

Символы, указывающие на характер связи (1 или М), отображаются на ERдиаграммах рядом со связанными сущностями.

Связь любого из перечисленных видов может иметь обязательный и необязательный классы принадлежности. Класс принадлежности связи для некоторой сущности является обязательным, если в данной связи должен участвовать каждый экземпляр сущности (все продавцы продают товары), и необязательным, если некоторые экземпляры сущности не участвуют в связи (не все товары доставлены железнодорожным транспортом). При этом связь может быть обязательной с одной стороны и необязательной с другой стороны. На ER-диаграммах обязательный класс принадлежности может быть обозначен перпендикулярной линией, перечеркивающей линию связи вблизи сущности, необязательный класс принадлежности – пустым кружком на линии связи [ 4 ].

При построении ER-диаграмм могут использоваться генерализация, агрегация и группировка сущностей [ 3, 12 ].

На рис. 15 представлен фрагмент ER-диаграммы, отображающей работу магазина.

Сущность Работник имеет два подтипа – Директор и Продавец. Между сущностями Магазин и Работник связь имеет характер «один ко многим» (один магазин обслуживается многими работниками), между сущностями Директор и Продавец – «один ко многим» (один директор руководит многими продавцами), между сущностями Продавец и Товар – «многие ко многим» (несколько продавцов продает множество разных товаров). Класс принадлежности большинства связей является обязательным. Он является необязательным для связи Фасует между сущностями Продавец и Товар со стороны сущности Продавец (не каждый продавец фасует товары) (см. рис. 15).

Функциональная модель данных Эта модель была предложена Шипмэном в 1981 г. [ 12 ].

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