Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. - Базы данных. Учебник для высших учебных заведений (6-е изд.) - 2009

4. Информационные	системы в сетях		143
	Мэйнфрейм	Обработка, подготовка к выдаче
		и управление терминалом
Соединительные кабели
		Отображение
		информации
]	[
Рис. 4.14. Централизованная многопользовательская			система

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

2. Исторически следующим решением в области информационных систем была архитектура клиент-сервер (рис. 4.15).

Потребление

информации

Рис. 4.15. Системы типа клиент-сервер

В этих системах место терминала заняла ПЭВМ, а мэйнфрейма — компь- ютер-сервер. Ранее мы рассматривали спектр моделей подобных систем с различным распределением функций между компонентами. Если не брать во внимание модель «распределенного представления» (по сути повторяет модель централизованной многопользовательской системы), то можно заключить, что системы типа клиент-сервер имеют следующие достоинства: высокая живучесть и надежность, легкость масштабирования, качественный пользовательский интерфейс, возможность одновременной работы с несколькими приложениями, высокие характеристики оперативности обработки информации.

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

144 Часть 1. Основы построения баз данных

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

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

Еще один недостаток заключается в сложности администрирования системы и ее уязвимости при непредсказуемых или злонамеренных действиях пользователя или компьютерных вирусов.

3. Корпоративные системы интранет, в отличие от систем клиентсервер, ориентированы не на данные, а на информацию в ее окончательном и пригодном для использования неквалифицированным пользователем виде (рис. 4.16).

Рис. 4.16. Системы, поставляющие информацию

Новые системы объединяют в себе преимущества централизованных многопользовательских систем и систем типа клиент-сервер. Им присущи следующие черты:

•на сервере порождается информация, пригодная для использования, а не данные (например, в случае СУБД — записи БД);

•при обмене между клиентской и серверной частями используется протокол открытого стандарта, а не какой-то конкретной фирмы;

•прикладная система находится на сервере, и поэтому для работы пользователя на компьютере-клиенте достаточно иметь программу-навигатор (могут быть и другие решения, когда часть обработки производится на компьютере-клиенте).

4. Информационные

системы в сетях

145

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

ии Web-клиент

Web-cepeep

SQL запросы

с

Сервер БД

б)

Рис. 4.17. Модели доступа к базе данных в Интернете

При доступе к БД на стороне клиента основным средством реализации механизмов взаимодействия Wcb-клиента и сервера БД является язык Java. Кроме того, могут использоваться элементы управления ActiveX. В качестве вспомогательных средств обработки информации на клиентской стороне (но не для взаимодействия с базами данных) часто используются языки сценариев JavaScript, JScript и VBScript, разработанные для расширения возможностей декларативного языка HTML (в HTML нет операторов присваивания, сравнения, математических функций и пр.) на основе добавления процедурных средств. Программы-сценарии выполняются на компьютере Web-броу- зером в режиме интерпретации.

Для обращений к серверам БД изJava-nporpaMM разработан стандар^ОВС (Java DataBase Connectivity - совместимость баз данных для Java), основан-

146	Часть 1. Основы построения баз данных

ный на концепции ODBC. Стандарт JDBC разработан фирмами Sun/JavaSoft

иобеспечивает универсальный доступ к различным базам данных на языке Java.

Вмодели доступа к БД на стороне сервера обращение к серверу БД обычно производится путем вызова программами Web-сервера внешних по отношению к ним программ в соответствии с соглашениями одного из интерфейсов: CGI (Common Gateway Interface - общий шлюзовый интерфейс), FastCGI или API (Application Program Interface - интерфейс прикладного программирования).

Внешние программы взаимодействуют каким-либо образом с сервером БД на языке SQL, например, непосредственно обращаясь к конкретному серверу или используя драйвер ODBC (см. подраздел 9.3).

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

сценариями.

Кроме того, для организации доступа серверных программ к информации из БД могут использоваться технологии динамического построения Web-стра- ниц (ASP, РНР и IDC/HTX-страницы) на основе информации БД.

Доступе к БД на стороне сервера приложений обычно применяется при использовании серверов приложений. Основным языком разработки распределенных приложений в этом случае можно считать язык Java, а также технологии CORBA и Enterprise JavaBeans

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

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

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

ке на Web-cepeep и нехватке его мощности.

В третьей схеме предпринята попытка преодолеть недостатки второй схемы в том случае, когда планируется большая нагрузка на \УеЬ-сервер.

Подробно методы и средства организации работы с базами данных в Интернете рассмотрены в части 4.

4. Информационные

системы в сетях

147

Контрольные вопросы и задания

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

2.Охарактеризуйте модель удаленного доступа к данным.

3.Назовите достоинства и недостатки модели сервера баз данных.

4.Изобразите структурную схему трехзвенной модели сервера приложений.

5.Каково назначение мониторов транзакций?

6.Изобразите схему и охарактеризуйте модель монитора транзакций.

7.Назовите основные технологии децентрализованного управления БД.

8.Опишите динамику функционирования модели распределенной БД.

9.Укажите достоинства и недостатки модели распределенной БД.

10.Опишите протокол двухфазной фиксации транзакций.

11.Опишите модель тиражирования данных.

12.Опишите протокол трехфазной фиксации транзакций.

13.Назовите основные методы доступа к данным и укажите случаи предпочтительного их использования.

14.Приведите пример типичного набора блокировок объектов БД.

15.Укажите правила совмещения блокировок.

16.Назовите основные разновидности тупиков.

17.Приведите пример взаимного тупика в распределенной БД.

18.Укажите основные варианты создания информационной системы в локальной сети.

19.Опишите схему функционирования информационной системы типа файл-сервер с несетевой СУБД.

20.Как организуется обработка в информационных системах типа файлсервер с сетевой СУБД?

21.Опишите схему функционирования информационной системы типа клиент-сервер.

22.Каково назначение хранимых процедур и триггеров?

23.Дайте понятия хранимых команд и курсора.

24.Как организуется доступ к данным с помощью интерфейса ODBC?

25.Дайте общую характеристику сети Internet.

26.Укажите основные модели доступа к БД в сети Internet.

27.Какие языки программирования используются для доступа к БД в Internet?

28.Каково назначение CGI-сценариев?

29.Охарактеризуйте технологию intranet.

148

Литература

1. ВейдА. Стандарты объектных запросов / / Системы Управления Базами Данных, № 4, 1996.-С. 89-97.

2.Дейт К.Дж. Введение в системы баз данных / Пер. с англ. - 6-е изд. - К.: Диалектика, 1998. - 784 с.

3.Елисеев В, Ладыженский Г. Введение в Интранет / / Системы Управления Базами Данных, № 5-6, 1996. - С. 19-43.

4.Калиниченко Л. Стандарт систем управления объектными базами данных ODMG: краткий обзор и оценка состояния / / Системы Управления Базами Данных, № 1, 1996. - С. 102-109.

5.Конноли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика / Пер. с англ. — 3-е издание. - М.: Издательский дом «Вильяме», 2003. - 1440 с.

6. Кузнецов С. Доступ к базам данных с использованием технологии W W W / / Системы Управления Базами Данных, № 5-6, 1996. - С. 4-9.

7.Ладыженский Г. Системы управления базами данных - коротко о главном / / Системы Управления Базами Данных, № 4, 1995. - С. 123-141.

8.Олейников А.Я. Открытые системы: концепция и реальность / / Открытые системы, № 4, 1993. - С. 53-58.

9.Орлик С.В. Borland Delphi как средство разработки масштабируемых приложений / / Системы Управления Базами Данных, № 4, 1995. - С. 50-56.

10.Основы современных компьютерных технологий: Учебник / Под ред. проф. Хомоненко А. Д. Авторы: Брякалов Г. А., Войцеховский С. В., Воробьев Б. Г., Гофман В. Э., Гридин В. В., Дрюков Ю. П., Замула А. А., Захаров А. И., Компа-

нией Р. И., Липецких А. Г., Рыжиков Ю. И., Хомоненко А. Д., Цыганков В. М. - СПб: КОРОНА принт, 2005. - 672 с.

11. Роберт Сигнор, Михаэль О. Стегман. Использование ODBC для доступа к базам данных / Пер. с англ. - М.: БИНОМ; НАУЧНАЯ КНИГА. - 384 с.

12.Системы управления базами данных и знаний: Справ, изд. / Наумов А.П., Вендров A.M., Иванов В.К. и др.; Под ред. Наумова А.Н. - М.: Финансы и статистика, 1991. - 352 с.

13. Советов Б. Я., Цехановский В. В., Чертовский В. Д. Базы данных. Теория и практика. - М.: Высшая школа, 2005.

ПРОЕКТИРОВАНИЕ И ИСПОЛЬЗОВАНИЕ БАЗ ДАННЫХ

5.Проектирование баз данных

Внастоящем разделе рассматриваются вопросы проектирования реляционных баз данных. Дается характеристика проблем проектирования и подходов к их решению.

5.1. Проблемы проектирования

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

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

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

При проектировании структур данных для автоматизированных систем можно выделить три основных подхода:

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

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

3.Структурирование информации для использования в информационной системе в процессе проведения системного анализа на основе совокупности правил и рекомендаций.

150	Часть 2. Проектирование и использование БД

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

Избыточное дублирование данных и аномалии

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

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

С_Т Сотрудник Телефон

Иванов И.М. 3721 Петров М.И. 4328 Сидоров Н.Г. 4328 Егоров В.В. 4328

Рис. 5.1. Неизбыточное дублирование

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

На рис. 5.26 приведен пример неудачного отношения С_Т_Н, в котором вместо телефонов Сидорова и Егорова поставлены прочерки (неопределенные значения). Неудачность подобного способа исключения избыточности заключается в следующем. Во-первых, при программировании придется потратить дополнительные усилия на создание механизма поиска информации

5. Проектирование баз данных

151

с_т_н			б) С_Т_Н
Сотрудник	Телефон	Н_комн	Сотрудник	Телефон	Н_комн
Иванов И.М.	3721	109	Иванов И.М.	3721	109
Петров М.И.	4328	111	Петров М.И.	4328	111
Сидоров Н.Г.	4328	111	Сидоров Н.Г.	—	111
Егоров В.В.	4328	111	Егоров В.В.	—	111

Рис. 5.2. Избыточное дублирование

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

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

Т_Н		С_Н
Телефон	Н_комн	Сотрудник	Н_комн
3721	109	Иванов И.М.	109
4328	111	Петров М.И.	111
		Сидоров Н.Г.	111
		Егоров В.В.	111

Рис. 5.3. Исключение избыточного дублирования

Процедура декомпозиции отношения С_Т_Н на два отношения С_Н и Н_Т является основной процедурой нормализации отношений.

Избыточное дублирование данных создает проблемы при обработке кортежей отношения, названные Э. Коддом «аномалиями обновления отношения». Он показал, что для некоторых отношений проблемы возникают при попытке удаления, добавления или редактирования их кортежей.

152 Часть 2. Проектирование и использование БД

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

Выделяют три основные вида аномалий: аномалии модификации (или редактирования), аномалии удаления ^аномалии добавления.

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

Так, например, изменение номера телефона в комнате 111 (рис. 5.2а), что представляет собой один единственный факт, потребует просмотра всей таблицы С_Т_Н и изменения поля Н_комн согласно текущему содержимому таблицы в записях, относящихся к Петрову, Сидорову и Егорову.

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

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

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

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

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

Формирование исходного отношения

Проектирование БД начинается с определения всех объектов, сведения о которых будут включены в базу, и определения их атрибутов. Затем атрибуты сводятся в одну таблицу - исходное отношение.

Пример. Формирование исходного отношения.

Предположим, что для учебной части факультета создается БД о преподавателях. На первом этапе проектирования БД в результате общения с за-