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

1.8. Целостность данных

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

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

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

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

Рассмотрим отношения ссылочной целостности и ограничения NOT NULL, которые отражены в ER модели учебной БД.

Внешние ключи AccountCD и GazServiceCD таблиц PaySumma и NachislSumma ссылаются на первичные ключи таблиц Abonent и Services соответственно. Эти внешние ключи объявлены как NOT NULL (нет белого ромбика у линии связи, примыкающей к родительской таблице), т. е. в таблицах PaySumma и NachislSumma не могут существовать записи с пустыми значениями полей AccountCD и GazServiceCD. Записи в этих таблицах могут существовать только в том случае, если в справочнике абонентов (таблица Abonent) и в справочнике услуг газоснабжения (таблица Services) есть абонент и услуга газоснабжения, которые указаны в полях внешних ключей AccountCD и GazServiceCD. Для всех связей рассматриваемых в данный момент внешних ключей определены условия ссылочной целостности: D:R и U:C. Это, например, означает, что удаление абонента из справочника абонентов будет запрещено, если в таблице PaySumma или NachislSumma существуют записи,

связанные с этим абонентом через механизм внешних ключей, а при обновлении первичного ключа таблицы Abonent будет выполнено каскадное обновление соответствующих внешних ключей AccountCD в таблицах PaySumma и NachislSumma.

В справочнике абонентов может отсутствовать информация об улице, на которой проживает абонент, т.е. значение внешнего ключа StreetCD таблицы Abonent может быть NULL. Аналогично для ремонтной заявки (запись в таблице Request) в общем случае может быть неизвестно, от какого абонента она принята (внешний ключ AccountCD в этом случае содержит NULL значение), какая неисправность должна быть исправлена в этой ремонтной заявке (внешний ключ FailureCD имеет значение NULL) и кто должен ее выполнить (внешний ключ ExecutorCD имеет значение NULL).

Для рассмотренных связей внешних ключей установлены следующие правила ссылочной целостности: D:SN и U:C.

D:SN означает, что при удалении соответствующей записи в родительской таблице значение внешнего ключа будет установлено NULL.

Пример для правила U:C приведен при рассмотрении внешних ключей таблиц PaySumma и NachislSumma и означает каскадное обновление внешних ключей при обновлении соответствующих им первичных ключей в родительской таблице.

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

1.9. Архитектура клиент-сервер

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

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

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

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

Конкретный сервер определяется видом ресурса, которым он владеет. В качестве ресурса сервера применительно к технологии БД выступает сама БД.

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

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

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

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

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

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

Применительно к технологиям баз данных функции стандартного интерактивного приложения разделяются на четыре группы, имеющие различную природу [7]:

- функции ввода и отображения данных;

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

- фундаментальные функции хранения и управления информационными ресурсами;

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