УДК 681.3.06 Ш73

Рецензенты:

д-р техн. наук, проф. С.В. Бочкарев (Пермский государственный технический университет),

канд. техн. наук В.П. Казанцев (Пермский государственный технический университет)

Шмидт И.А.

Ш73 Информационное обеспечение систем управления: Конспект лек­ ций / Перм. гос. техн. ун-т. - Пермь, 2005. - 53 с.

Рассмотрены вопросы обработки данных в системах управления, архи­ тектуры подсистем обработки и хранения данных, способы организации и описания данных, процедура нормализации и язык SQL.

Предназначен для обучающихся на дневном и заочном отделениях на­ правления 654500 «Электротехника, электромеханика и электротехнологии» по специальности 180400 «Электропривод и автоматика промышленных ус­ тановок и технологических комплексов».

Рекомендуется для студентов, изучающих курс «Информационное обеспечение систем управления» специальности 210200 «Автоматизация технологических процессов и производств».

УДК 681.3.06

© Пермский государственный технический университет, 2005

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

1)хост/терминал;

2)файл/сервер;

3)клиент/сервер;

4)многозвенная архитектура.

1.1. Архитектура хост/терминал

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

РисЛ. Архитектура хост/терминал

Преимущества: дешевые терминалы, невысокая загрузка сети (тра­ фик), эффективнее решается проблема целостности.

Недостатки: мощность ограничена хостом, если в качестве терми­ нала используются персональные компьютеры, то их ресурсы не исполь­ зуются.

Данная архитектура применима для больших и очень больших корпо­ ративных сетей, построенных, как правило, на базе ОС Unix.

1.2. Архитектура файл/серввр

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

Файл/сервер

Рис. 2. Архитектура файл/сервер

Преимущества: простота, малая стоимость.

Недостатки: низкая надежность и малое количество клиентов, во­ просы целостности возлагаются на клиентские приложения.

Данная архитектура применяется в простых коробчатых вариантах программного обеспечения (например, 1 :С).

В настоящее время на рынке наиболее популярными СУБД, которые применяют данную архитектуру, являются такие продукты, как Fox Pro, D Base, Paradox, Access.

При архитектуре клиент/сервер персональные компьютеры объедине­ ны в локальную сеть, в которой имеется сервер, содержащий общие базы данных (рис. 3). В этой архитектуре мы имеем дело с сервером баз данных. Функции СУБД разделены на две части. Пользователь формирует запрос к БД. При помощи клиентской части СУБД запрос передается к серверу БД (ядро СУБД). Сервер БД выполняет запрос и при необходимости возвра­ щает результат запроса клиенту. Пользовательские запросы объединяются в транзакции. Транзакция - логически связанная последовательность трансляции данных (запросов). Средством написания запросов является язык SQL, который является стандартным языком, обеспечивающим взаи­ модействие между клиентскими приложениями. Синтаксис и правила вы­ полнения запросов SQL стандартизированы. В настоящее время этим за­ нимается американский национальный институт стандартизации ANSI. Помимо стандартных возможностей каждый производитель СУБД может расширять свою версию SQL дополнительными возможностями, которые впоследствии могут стать частью стандарта.

Рис. 3. Архитектура клиент/сервер

Преимущества: использование ресурса, как клиента, так и сервера. Недостатки: при очень большой загрузке (при высоком трафике) па­

дает производительность.

Данная архитектура применяется в масштабе предприятия.

В настоящее время на рынке имеется огромное количество СУБД, применяющих данную архитектуру. Наиболее популярные из них ORA­ CLE, SyBase, MS SQL, InterBase.

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

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

Рис. 4. Многозвенная архитектура

Данная архитектура является гибридной. Тонкий клиент позволяет в стандартном формате работать с любыми данными. Сервер приложений является инструментом для отображения данных в формате HTML. Эта архитектура применяется в таких сетях, как Internet (всемирная сеть), Intranet (внутренняя сеть). В сервере приложений запускается столько ко­ пий приложений, сколько пользователей требует информацию. Широко применяется программное обеспечение для серверов приложений, назы­ ваемое Apache.

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

Недостатки: ограничение возможностей, тонкий клиент имеет огра­ ниченные возможности.