Спирин Н.А., Лавров В.В. Информационные системы в металлургии

Подождите немного. Документ загружается.

Глава 3. Основы систем управления базами данных

3-19

мисты – стоимостные характеристики. Очевидно, что при вводе и корректировке

соответствующей информации возникают свои специфические требования. На-

пример:

• число, отражающее количество загружаемых шихтовых материалов, не

должно превышать определенную величину, соответствующую обще-

му количеству материалов в бункерах. Поэтому на следующий уровень

отправляется запрос о суммарном количестве шихтовых материалов в

бункерах;

• данные

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

определенным пользователем. На следующий уровень посылается за-

прос на проверку прав зарегистрировавшегося пользователя вводить

указанную информацию;

• данные о стоимости шихтовых материалов не должны превышать ве-

личины, указанной в приходном ордере для партии этих материалов.

На следующий уровень посылается запрос о проверке этого

ограниче-

ния.

В случае соответствия данных правилам целостности осуществляется

доступ к базе данных, который использует устройство доступа к файлам дан-

ных, управляемое средствами операционной системы. Среди функций, обеспе-

чиваемых этими уровнями, можно отметить следующие:

• разграничение прав доступа к базе данных пользователей (чтение, из-

менение или удаление данных);

• возможность одновременной

работы нескольких пользователей с базой

данных (многопользовательский доступ).

Отметим, что именно благодаря программному разделению системы на

несколько уровней, выполняющих свои специфические функции, появилась

возможность физической обработки данных на разных компьютерах (клиенте и

сервере), т.е. распределенной обработки. Эта возможность настолько важна, что

термин «клиент/сервер» стал применяться главным образом в

случае, если сер-

вер и клиент находятся на разных компьютерах.

3.5.2. Разделение клиента и сервера

Напомним, что если все уровни приложения выполняются на одном ком-

пьютере, значит, это однопользовательское приложение. Для создания архитек-

туры клиент/сервер необходимо определить сферы действия клиента и сервера

по границе любого из уровней приложения. Самое

простое разделение кли-

ент/сервер можно получить, выбрав ближайшую границу к любому концу дан-

ной архитектуры.

Выполнение основной работы на сервере

Один из простых способов разделения функций клиента и сервера – пору-

чить клиенту только интерфейс пользователя, а остальное предоставить серверу

(рис. 3.8).

Здесь в системе пользователя размещена часть приложения

, ответственная

Глава 3. Основы систем управления базами данных

3-20

за просмотр данных, ввод с клавиатуры или с помощью мыши. Остальная часть

выполняется на большой распределенной системе.

Иногда компьютер клиента представляет собой не более чем "интеллекту-

альный" терминал данных. В клиентской части приложения выполняется, как

максимум, проверка правильности ввода простых данных.

Компьютер

сервера БД

Доступ к файлам

Доступ к базе данных

Правила целостности данных

Бизнес-правила

Прикладные задачи

Интерфейс пользователя

Данные

Пользователь прило-

жения

(компьютер клиента)

Удаленный

доступ

Рис. 3.8. Размещение большей части задач на сервере

Такая архитектура подобна архитектуре большинства диалоговых сервис-

ных систем

. Компьютер пользователя осуществляет связь и обеспечивает обзор

программного обеспечения (например, систему навигации и просмотра инфор-

мации в сети Web), а основную работу выполняют компьютеры сети, с которы-

ми соединен пользователь. В этом случае, несмотря на то что клиент обеспечи-

вает только представление и перемещение данных, его компьютер должен быть

достаточно мощным,

чтобы быстро оперировать со сложными потоками графи-

ческих данных, идущими с сервера.

Большинство профессионалов в области компьютерной технологии пола-

гают, что такой тип простого разграничения не определяет правильность прило-

жения клиент/сервер. И все-таки, если программное обеспечение компьютера

или рабочей станции клиента выполняет важную работу по обеспечению поль-

зователя

усиленным графическим интерфейсом и по отправлению запросов на

сервер с помощью простого потока символьных данных, такой вид приложения

соответствует духу вычислений типа клиент/сервер.

Преимущество такой архитектуры – все данные и большинство приклад-

ных логических средств сосредоточены в одном месте. Большинство изменений

или усовершенствований приложения можно выполнить на центральном серве-

ре.

Недостаток – центральный сервер должен быть очень мощным, если доступ к

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

ду клиентом и сервером может потребовать работы с большими объемами гра-

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

может понадобиться очень дорогая высокоскоростная компьютерная сеть, свя-

зывающая клиента с сервером.

Глава 3. Основы систем управления базами данных

3-21

Выполнение основного объема работы у клиента

Противоположный описанному в предыдущем разделе вариант – разделе-

ние приложения таким образом, что сервер работает только как простое храни-

лище данных, или файловый сервер (рис. 3.9). Все представления данных и при-

кладные логические средства размещены на клиентском компьютере.

Компьютер

сервера БД

Доступ к файлам

Доступ к базе данных

Правила целостности данных

Бизнес-правила

Прикладные задачи

Интерфейс пользователя

Данные

Пользователь прило-

жения

(компьютер клиента)

Удаленный

доступ

Рис. 3.9. Размещение большей части задач на клиенте

Основное достоинство такой архитектуры – ее простота. Для

совместного

использования данных системой клиент/сервер достаточно переместить файлы

данных на сервер управления файлами. Однако эта архитектура требует доста-

точно сложного аппаратного обеспечения клиента, и, поскольку большинство

файловых серверов осуществляет только первичное распределение данных на

уровне файлов, она предусматривает только доступ к данным или относительно

малое число совместно работающих пользователей.

Достижение баланса

Для использования преимуществ архитектуры клиент/сервер в полной ме-

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

баланса рабочей загрузки компьютерных систем клиента и сервера (рис. 3.10).

Для этого в первую очередь следует реализовать сервер базы данных, который

Компьютер

сервера БД

Пользователь прило-

жения

(компьютер клиента)

Доступ к файлам

Доступ к базе данных

Правила целостности данных

Бизнес-правила

Прикладные задачи

Интерфейс пользователя

Данные

Удаленный

доступ

Рис. 3.10. Сбалансированная нагрузка клиента и сервера

Глава 3. Основы систем управления базами данных

3-22

способен на любую работу по выполнению запросов путем прямого доступа к

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

ходимые для выполнения конкретной задачи (это часто самый "медленный"

компонент архитектуры клиент/сервер).

Сервер базы данных может также централизованно реализовывать все

правила целостности и защиты данных. При этом

целостность данных обеспечи-

вается независимо от целостности данных клиентов.

Реализация сбалансированной архитектуры требует дополнительной рабо-

ты и планирования, но в результате достигаются высокая степень целостности

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

Недостаток ее в том, что ни клиент, ни сервер не являются простыми реализа-

циями.

3.5.3. Преимущества и

перспективы системы клиент/сервер

В настоящее время применение компьютерных приложений с архитекту-

рой клиент/сервер – лучший способ использования вычислительных ресурсов.

Эта архитектура дает следующие преимущества:

•

рабочая загрузка естественным образом распределена на множестве

компьютеров;

пользователи могут легко совместно пользоваться данными;

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

централизованном порядке;

использование нескольких малых компьютеров, предназначенных для

решения отдельных задач, улучшает показатель "стоимость / эффек-

тивность" по сравнению с применением одного мощного компьютера.

В то же время такая архитектура имеет некоторые неудобства, которые

приходится учитывать при проектировании и администрировании:

проектировщик должен определить, какие задачи следует выполнять

клиенту, а

какие – серверу;

проектировщик должен выбрать для решения каждого типа задач под-

ходящее аппаратное обеспечение;

переходы к новым версиям программного обеспечения клиента долж-

ны контролироваться очень строго;

изменения конструкции базы данных сервера могут повлиять на всех

клиентов;

сетевая топология часто очень сложна;

контроль производительности и необходимые

регулировки могут ока-

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

3.6. Общие понятия реляционного подхода к организации данных

Современная технология реализации баз данных, как правило, основана

на реляционной модели, которая, в свою очередь, является некоторой абстракт-

ной теорией данных. Принципы реляционной модели были изначально заложе-

ны в 1969 году доктором

Е.Ф.Коддом, в то время исследователем, работавшим в

Глава 3. Основы систем управления базами данных

3-23

корпорации IBM. В конце 1968 года Кодд, математик по образованию, впервые

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

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

ких качеств и не доставало этой области в то время. С того времени эти идеи

стали общепринятыми и оказали весьма существенное влияние на

все аспекты

технологии баз данных. Первые реляционные программные продукты начали

появляться в конце 70-х – начале 80-х годов. С тех пор почти все созданные

коммерческие СУБД основываются на реляционном подходе.

Что же понимается под реляционной системой? В самом широком смысле

реляционная система – это система, основанная на следующих принципах:

• данные воспринимаются

пользователем как таблицы;

• в распоряжении пользователя имеются операторы манипулирования

данными (например, для выборки данных), которые генерируют новые

таблицы из старых.

Причина, по которой такие системы называют реляционными, заключает-

ся в том, что английский термин «relation» (реляция, отношение), по существу,

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

стве

случаев термины «отношение» и «таблица» принято считать синонимами.

Определение «реляционные системы» требует, чтобы база данных воспринима-

лась пользователем только в виде таблиц. Таблицы в реляционной системе яв-

ляются логическими, а не физическими структурами. В действительности на фи-

зическом уровне система баз данных может использовать любую или все приме-

няемые структуры памяти

– последовательные файлы, индексирование, цепочки

указателей, сжатие хранимых данных и т.п. – лишь бы обеспечивалась возмож-

ность отображать эти структуры в таблицы на логическом уровне. Другими сло-

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

ных, в которой множество деталей на уровне памяти – размещение, последова-

тельность хранимых записей, кодировка хранимых данных,

хранимые структуры

доступа, такие как индексы, и т.д. – скрыто от пользователей.

На рис. 3.11 показан простой пример реляционной базы данных отделов и

сотрудников.

Среди операторов манипулирования данными есть как минимум следую-

щие:

• SELECT, предназначенный для извлечения определенных строк из

таблицы;

• PROJECT, предназначенный для извлечения определенных столбцов

из таблицы;

•

JOIN, предназначенный для соединения двух таблиц на основе общих

значений в общих столбцах.

Некоторые примеры использования операций SELECT, PROJECT И JOIN

показаны на рис. 3.12.

Необходимо отметить важный момент, очевидный из рис. 3.12: результат

каждой из трех операций – это еще одна таблица. Это реляционное свойство

замкнутости. Оно имеет очень большое значение главным образом потому, что

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

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

Глава 3. Основы систем управления базами данных

3-24

Отдел

Номер отдела Наименование Бюджет

1 Технический 200

2 Научный 250

3 Проектный 300

Сотрудники

Номер

сотрудника

Имя сотрудника Номер отдела Зарплата

14252 Королев 1 800

18453 Луценко 1 820

15265 Городинский 2 750

48452 Борисов 2 800

Рис. 3.11. Фрагмент базы данных отделов и сотрудников

SELECT (RESTRICT): Выборка строк из таблицы "Отделы", где бюджет более 230

Результат:

Номер отдела Наименование Бюджет

2 Научный 250

3 Проектный 300

PROJECT: Извлечение столбцов "Наименование" и "Бюджет" из таблицы "Отделы"

Результат:

Наименование Бюджет

Технический 200

Научный 250

Проектный 300

JOIN: соединение таблиц "Отделы" и "Сотрудники" на основе столбца "Номер отдела"

Результат:

Номер

отдела

Наименование Бюджет

Номер

сотрудника

Имя

сотрудника

Зарплата

1 Технический 200 14252 Королев 800

1 Технический 200 18453 Луценко 820

2 Научный 250 15265 Городинский 750

2 Научный 250 48452 Борисов 800

Рис. 3.12. Примеры операций SELECT, PROJECT и JOIN

Глава 3. Основы систем управления базами данных

3-25

результатом операции можно вновь проделать какую-либо другую операцию.

Например, можно выбрать столбцы из соединенной таблицы или соединить два

результата операции SELECT и т.д. Другими словами, можно использовать вло-

женные выражения, т.е. выражения, в которых операнды

представлены выра-

жениями, а не простыми именами таблиц.

Другой момент, который также проиллюстрирован на рис. 3.12, заключа-

ется в том, что операции применяются сразу ко всему множеству строк, а не к

отдельной строке за один раз, т.е. операндами и результатами являются не от-

дельные строки, а целые таблицы, которые

содержат множество строк. Такая

возможность обработки множества – главная отличительная характеристика ре-

ляционных систем; нереляционные системы, как правило, за одно обращение

выполняют обработку на уровне одной строки или записи.

3.6.1. Базовые понятия реляционных баз данных

Основными понятиями реляционных баз данных являются:

• тип данных;

• домен;

• атрибут;

• кортеж;

•

отношение;

• первичный ключ.

Покажем смысл этих понятий на примере отношения СОТРУДНИКИ, со-

держащего информацию о сотрудниках некоторой организации (рис. 3.13).

Тип данных

Понятие тип данных в реляционной модели данных полностью адекватно

понятию типа данных в языках программирования. Обычно в современных ре-

ляционных БД допускается хранение символьных, числовых данных,

битовых

строк, специализированных числовых данных (таких как «деньги»), а также спе-

циальных данных (дата, время, временной интервал). Достаточно активно разви-

вается подход к расширению возможностей реляционных систем абстрактными

типами данных. В нашем примере мы имеем дело с данными четырех типов: це-

лые числа, строковые переменные, «деньги» и переменные типа даты.

Домен

Понятие домена более специфично для баз данных, хотя и имеет некото-

рые аналогии с подтипами в некоторых языках программирования. В самом об-

щем виде домен определяется заданием некоторого базового типа данных, к ко-

торому относятся элементы домена, и произвольного логического выражения,

применяемого к элементу типа данных. Если вычисление этого

логического вы-

Операнд – часть выражения, над которой производится операция, аргумент операции.

Глава 3. Основы систем управления базами данных

3-26

ражения дает результат "истина", то элемент данных является элементом доме-

на.

Номер

сотрудника

Имя

сотрудника

Номер

отдела

Зарплата

Дата

рождения

Первичный

ключ

Номера

пропусков

Имена

сотрудников

Номера

отделов

Размеры

выплат

Даты

рождения

Целые

числа

Строковые

переменные

Деньги

Переменные

типа даты

Домены

Типы данных

Атрибуты

152 Веселов 2 580 12/05/65

563 Ступин 3 620 04/08/58

245 Кораблев 6 700 27/03/42

255 Нестеров 3 700 25/11/59

Рис. 3.13. К пояснению основных терминов реляционных баз данных

Кортежи

Наиболее правильной трактовкой понятия домена является понимание

домена как допустимого потенциального множества значений данного типа. На-

пример, домен "Имена сотрудников" в нашем примере определен на базовом ти-

пе строковых переменных, но в число его значений могут входить только те

строки, которые могут изображать имя (в частности, такие строки не могут на-

чинаться с мягкого знака).

Следует отметить также смысловую (семантическую) нагрузку понятия

домена: данные считаются сравнимыми только в том случае, когда они относят-

ся к одному домену. В этом и состоит основное назначение доменов: домены

ограничивают сравнения. Так, в

нашем примере значения доменов "Номера со-

трудников" и "Номера отделов" относятся к типу целых чисел, но не являются

сравнимыми.

Кортеж

Кортеж, соответствующий данной схеме отношения, – это множество

пар {имя атрибута; значение}, которое содержит одно вхождение каждого имени

атрибута, принадлежащего схеме отношения. Другими словами, кортеж – это

Глава 3. Основы систем управления базами данных

3-27

строка отношения (таблицы) реляционной модели данных, представляющая со-

бой последовательность значений атрибутов.

Схема отношения, схема базы данных

Схема отношения – это именованное множество пар {имя атрибута; имя

домена (или типа)}. Степень, или «арность», схемы отношения характеризует

мощность этого множества. Степень отношения СОТРУДНИКИ равна пяти, то

есть оно является 5-арным. Если

все атрибуты одного отношения определены на

разных доменах, разумно использовать для именования атрибутов имена соот-

ветствующих доменов (не забывая, конечно, о том, что это является всего лишь

удобным способом именования и не устраняет различия между понятиями доме-

на и атрибута).

Схема БД (в структурном смысле) – это набор именованных схем отноше-

ний.

Отношение

Отношение – это множество кортежей (строк таблицы), соответствую-

щих одной схеме отношения. Иногда схему отношения называют заголовком

отношения, а отношение как набор кортежей – телом отношения. На самом де-

ле, понятие схемы отношения ближе всего к понятию структурного типа данных

в языках программирования. Было бы вполне логично разрешать отдельно

опре-

делять схему отношения, а затем одно или несколько отношений с данной схе-

мой. Однако в реляционных базах данных это не принято. Имя схемы отношения

в таких базах данных всегда совпадает с именем соответствующего отношения-

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

мы базы данных изменяются только отношения-экземпляры

. В них могут появ-

ляться новые и удаляться или модифицироваться существующие кортежи. Одна-

ко во многих реализациях допускается и изменение схемы базы данных: опреде-

ление новых и изменение существующих схем отношения. Это принято назы-

вать эволюцией схемы базы данных.

Обычное житейское представление отношения – таблица, заголовком ко-

торой является схема отношения

, столбцами – атрибуты отношения, а строками

– кортежи отношения-экземпляра; в этом случае имена атрибутов именуют

столбцы этой таблицы. Поэтому иногда говорят «столбец таблицы», имея в виду

«атрибут отношения». Этой терминологии придерживаются в большинстве ком-

мерческих реляционных СУБД. В табл. 3.1 представлен обзор некоторых реля-

ционных терминов и даны неформальные эквиваленты (соответствия

) этим тер-

минам.

Как видно из табл. 3.1, основные структурные понятия реляционной мо-

дели данных (если не считать понятия домена) имеют очень простую интуитив-

ную интерпретацию, хотя в теории реляционных БД все они определяются абсо-

лютно формально и точно.

Глава 3. Основы систем управления базами данных

3-28

Таблица 3.1

Неформальные определения реляционных объектов данных

Формальный реляционный термин Неформальный эквивалент

Отношение Таблица

Кортеж Строка или запись таблицы

Кардинальное число Количество строк

Атрибут Столбец или поле

Степень (арность) Количество столбцов

Первичный ключ Уникальный идентификатор

Домен

Общая совокупность допустимых значе-

ний данных в столбце

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

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

двух или более отношений. База данных, не имеющая связей между отношениями, име-

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

из основных требований к организации

реляционной базы данных – это обеспечение

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

новить между ними связи. Существуют следующие основные виды связей:

1 1

В А

1 1

Табельный

номе

Работник

∞

В А

Технологический

агрегат

Цех

∞

В А

Технологическая

операция

Цех

∞

Рис. 3.

Примеры различных видов связей: а – один к одному;

б – один ко многим; в – многие ко многим