Кирюшин О.В. Управление техническими системами

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

В принципе, и клиентская, и серверная части СУБД могут находится на

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

сервер запускается на одном компьютере (сервере), а программа-клиент – на

рабочих компьютерах.

Технологические объекты

№_об Тип Наим. Год постр. Уст-ка

102

103

104

печь

колонна

П-2/1

П-2/2

К-35

1993

1994

1993

депарафинизация

крекинг

Датчики

№_дтч Тип Фирма Марка Год

уст-ки

№_об

10128

10129

10130

Метран

Метран 22ДД

Метран 22ДА

Метран 22ДД

1994

102

103

Измерения

№_дтч Дата Время Знач-е

10129

10128

01.05.03

02.05.03

19:00:00

19:10:00

12:00:00

3,4

3,5

20,8

Рисунок 3.12

На практике наибольшее распространение получили т.н. реляционные

БД, представляющие собой набор таблиц, связанных отношениями. При этом

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

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

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

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

записи. Например, первичными ключами могут служить номер

технологического объекта (уникальный), табельный номер оператора, номер

131

первичные

ключи

унаследованный

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

(поле №_об)

унаследованный

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

(поле №_дтч)

составной первичный ключ

содержат

производят

идентиф.

связь

неидентиф.

связь

паспорта работника и т.д. Фамилия работника, тип установки и т.д.

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

могут работать несколько работников с одинаковыми фамилиями или

функционировать несколько однотипных установок. Т.е. первичный ключ

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

ключ может состоять из нескольких полей (составной первичный ключ).

Связи между таблицами осуществляются посредством первичных

ключей. На рисунке 3.12 приведен пример БД, состоящей из трех таблиц

(«Технологические объекты», «Датчики» и «Измерения»).

Связи (отношения между таблицами) могут быть идентифицирующие и

неидентивицирующие. Если запись в таблице-потомке однозначно

определяется своей связью с таблицей-родителем, то отношение между этими

таблицами является идентифицирующим. В этом случае первичный ключ

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

ключа) таблицы-потомка. Например, отношение «производят» на рис. 14

является идентифицирующим для таблицы-родителя «Датчики» и таблицы-

потомка «Измерения», поэтому первичный ключ таблицы-родителя (поле

«№_дтч») становится частью составного ключа таблицы-потомка. Отношение

«содержат» является неидентифицирующим, поэтому первичный ключ

таблицы-родителя «Технологические объекты» (поле «№_об») становится

обычным полем таблицы-потомка «Датчики».

3.3.2 Обеспечение безопасности баз данных.

При работе СУБД возникает необходимость защиты БД от возможных

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

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

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

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

Транзакция – неделимая с точки зрения воздействия на БД

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

возможны два итога [41]:

- результаты транзакции отображаются в БД,

- воздействие транзакции на БД полностью отсутствует.

В СУБД транзакция начинается с оператора BEGIN. Если она завершена

оператором COMMIT, то результаты фиксируются в БД, если ROLLBACK –

отсутствуют.

Оператор COMMIT устанавливает т.н. точку фиксации, т.е. момент,

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

целостном состоянии как в начале, так и в конце транзакции.

Восстановление БД – процесс, подразумевающий возвращение БД в

правильное (целостное) состояние, если какой-либо процесс вызвал сбой

данных. Восстановление базируется на принципе избыточности БД, при этом

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

информации полностью.

132

Восстановление информации может быть осуществлено по журналу

транзакций, в который заносится информация о транзакциях, начавших свое

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

журнале будут встречены транзакции, начавшиеся до сбоя, но не

закончившиеся, то для них выполняется команда ROLLBACK.

3.3.3 Операторы языка SQL

Запрос к БД внутри транзакции пишется на языке SQL, с помощью

которого формируются предложения [41]:

- определения данных – создание/уничтожение новых таблиц;

- запросов на выборку данных;

- модификации БД (добавление, удаление, изменение);

- управления данными (управление транзакциями, привилегиями).

Кроме того SQL позволяет выполнять:

- арифметические вычисления,

- упорядочивание строк, столбцов при выводе на экран/принтер;

- интерпретацию данных;

- сохранение результатов запроса в других таблицах;

- группирование данных, суммирование, подсчет и т.д.

Достоинства языка SQL:

- стандартность (поддерживается стандартами ANSI и ISO);

- независимость от конкретных СУБД, т.е. БД можно переносить с одной

СУБД на другую без доработок;

- поддержка реляционных БД;

- немедленный доступ к данным без написания программ;

- обеспечение различного представления данных;

- возможность динамического изменения и расширения структуры БД;

- поддержка архитектуры «клиент-сервер».

У каждого объекта БД (сервер, таблица, поле таблицы) есть свое

уникальное имя (в SQL имя должно содержать до 18 символов английского

алфавита большими буквами).

Рассмотрим три таблицы:

OBJECTS – таблица «Технологические объекты»,

N_OBJ – номер объекта (поле «№_об»)

TIP – тип объекта

NAIM - наименование объекта

GOD - год постройки;

SENSORS – таблица «Датчики»,

N_SENS - инвентарный номер датчика (поле «№_дтч»)

TIP - тип датчика

FIRMA - фирма-производитель

MARKA - марка датчика

GOD_UST - год установки на объект

133

N_OBJ - номер объекта, на котором установлен датчик;

IZMER – таблица «Измерения»

N_SENS - инвентарный номер датчика

DATE - дата измерения

TIME - время измерения

MEAN - значение измеренной величины.

Например, если таблица OBJECTS находится на сервере SERV, то

полное имя таблицы будет

SERV.OBJECTS

Для доступа к конкретному полю этой таблицы:

SERV.OBJECTS.TIP

Для заполнения таблицы используются следующие типы данных:

DEC(точность) - десятичное число с дробной частью,

NUMERIC - десятичное число с определенной точностью,

INT или INTEGER – целое число,

SMALLINT – целое число,

FLOAT(точность) – экспоненциальная форма числа,

REAL – вещественное число с заданной точностью,

DOUBLE – эквивалент REAL с более высокой точностью,

CHAR(макс. количество символов) – строковая переменная,

TIME – время.

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

Например, команда

SELECT N_SENS, TIP, N_OBJ FROM SENSORS;

выедет таблицу с тремя колонками (№ датчика, тип и № объекта) с данными

из таблицы SENSORS. Признаком завершения команды является точка с

запятой.

SELECT * FROM SENSORS;

выводит все данные из таблицы SENSORS.

SELECT DISTINCT TIP, FIRMA, MARKA FROM SENSORS;

выведет все марки датчиков без дублирования (операнд DISTINCT).

Использование условий поиска:

SELECT N_SENS, TIP, MARKA FROM SENSORS

WHERE FIRMA=’Метран’;

выводит список всех датчиков, произведенных фирмой «Метран».

SELECT FIRMA, MARKA, TIP FROM SENSORS

WHERE GOD_UST>2000;

выводит список датчиков, установленных после 2000 года.

В операторе WHERE должны быть использованы логические операции:

>, <, =, >=, <=, AND, OR, NOT. Кроме того могут использоваться

специальные операнды IN, BETWEEN, LIKE, IS NULL.

Операнд IN определяет набор значений, в который данное значение

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

134

SELECT MARKA, GOD_UST FROM SENSORS

WHERE FIRMA IN (‘Метран’, ‘Siemens’, ‘Fisher’);

выводит только датчики указанных фирм;

SELECT MARKA, FIRMA FROM SENSORS

WHERE GOD_UST BETWEEN 1985 AND 1989;

выводит список датчиков, установленный в период с 1985 по 1989 год;

SELECT N_SENS FROM SENSORS WHERE MARKA IS NULL;

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

Для получения итоговых данных могут использоваться функции:

SUM – сумма значений,

COUNT – количество,

AVG – среднее значение,

MAX и MIN – максимальное и минимальное значения.

Для группирования данных используется операнд GROUP BY:

SELECT N_SENS, MAX(MEAN) FROM IZMER

WHERE (DATE > 01/05/03 AND DATE < 31/05/03)

GROUP BY N_SENS;

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

которое он дал за май 2003 года.

Упорядочивание таблиц по возрастанию производится операндом

ORDER BY <поле> ASC или убыванию ORDER BY <поле> DESC.

Для объединения нескольких запросов в одну транзакцию используется

оператор UNION:

SELECT … UNION SELECT … ;

Для многотабличных запросов используются полные имена полей:

SELECT SENSORS.TIP,IZMER.DATE,IZMER.TIME,IZMER.MEAN

FROM SENSORS, IZMER

WHERE SENSORS.N_SENS=IZMER.N_SENS;

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

изерения.

Внутри операнда WHERE может находиться самостоятельная команда

SELECT. В этом случае сначала выполняется вложенный запрос, затем из его

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

Добавление новых записей в таблицу производится оператором INSERT

INTO <таблица> VALUES, например

INSERT INTO SENSORS VALUES (10260, ‘FE’,

‘Grundfos’, ‘Flow’, 2003, 102);

INSERT INTO SENSORS(N_SENS, TIP, N_OBJ)

VALUES (10278, ‘LE’, 102);

добавляет в таблицу SENSORS запись о новом уровнемере с номером 10278,

установленном на объекте 102, без указания марки и фирмы-изготовителя.

Удаление записей:

DELETE FROM IZMER WHERE DATE=01/05/2003;

135

удалит все записи за 1 мая 2003 года.

Изменение записей производится командой UPDATE:

UPDATE SENSORS

SET FIRMA=’Теплоприбор’, MARKA=’ТХА-0515’

WHERE TIP=’TE’;

заменит все датчики температуры на термопары ТХА-0515 фиры

«Теплоприбор».

Создание новой таблицы

CREATE TABLE SENSORS

(N_SENS INTEGER, TIP CHAR(5), MARKA CHAR(20),

GOD_UST INTEGER, N_OBJ INTEGER);

создает пустую таблицу SENSORS с указанными полями. После каждого

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

Изменение структуры таблицы:

ALTER TABLE SENSORS ADD REMNT INTEGER;

добавление поля REMNT в таблицу SENSORS.

3.4. Методология IDEF

3.4.1. Модели систем

Методология IDEF используется преимущественно на верхних уровнях

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

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

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

управления [42, 43].

Согласно методологии, модель системы может быть представлена в

виде совокупности трех моделей:

- функциональной,

- информационной,

- динамической.

При этом под системой подразумевается как система взаимодействий

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

между людьми в процессе достижения ими определенной цели.

Функциональная модель строится по т.н. методологии IDEF0, более

известной как SADT (Structure Analysis and Design Technique). Она дает

представления о том, какие функции выполняются (должны выполняться) в

рассматриваемой системе, что является исходными данными для них, какой

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

следственные связи между ними.

Информационная модель соответствует методологии IDEF1X,

описывает структуру используемой в системе информации и по сути является

моделью реляционной базы данных. Методология IDEF1X фактически

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

Динамическая модель формируется путем преобразования

функциональной модели в вид раскрашенных сетей Петри. Используемая

136

методология носит название IDEF/CPN (Colored Petri Nets). Сети Петри

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

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

Анализ систем на сетях Петри позволяет сделать определенные выводы по

оптимизации структур моделируемых систем.

3.4.2. Методика построения функциональной модели.

Методология IDEF0 (более известная как методология SADT-Structure

Analysis and Design Technique) предназначена для представления функций

системы и анализа требований к системам и является одной из самых

известных и широко используемых методологий проектирования АСУ [29].

В терминах IDEF0 система представляется в виде комбинации блоков и

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

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

множества объектов (как физических, так и информационных) или действия,

которые образуют связи между функциональными блоками. Место

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

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

подписываются глаголами или их формами. Дуги же подписываются

существительными.

Рисунок 3.13 – Функциональный блок

Управляющие выполнением функции данные входят в блок сверху, в то

время как информация, которая подвергается воздействию функции, показана

с левой стороны блока; результаты выхода показаны с правой стороны.

Механизм (человек или автоматизированная система), который

осуществляет функцию, представляется дугой, входящей в блок снизу (рис.

3.13).

В основе методологии IDEF0 лежат следующие правила:

137

1. Функциональный блок (или Функция) преобразует Входы в Выходы (т.е.

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

это преобразование может или должно произойти Исполнители

непосредственно осуществляют это преобразование.

2. С дугами связаны надписи (или метки) на естественном языке (как

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

они представляют.

3. Дуги показывают, как функции между собой взаимосвязаны, как они

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

4. Выходы одной функции могут быть Входами, Управлением или

Исполнителями для другой.

5. Дуги могут разветвляться и соединяться.

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

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

блоков, соединенных между собой интерфейсными дугами.

7. Эти блоки представляют основные подфункции (подмодули) единого

исходного модуля.

8. Данная декомпозиция выявляет полный набор подмодулей, каждый из

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

интерфейсными дугами.

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

образом для более детального представления.

3.4.3. Методика построения информационной модели.

Важнейшая цель информационной модели заключается в выработке

непротиворчивой интерпретации данных и взаимодействий между ними с тем,

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

целостностью данных.

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

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

значений данных в контексте их взаимосвязей с другими данными.

Методология IDEF1X - один из подходов к семантическому

моделированию данных, основанный на концепции "Сущность - Отношение"

(Entity-Relationship ), это инструмент для анализа информационной структуры

систем различной природы. Информационная модель, построенная с

помощью IDEF1X-методологии, представляет логическую структуру

информации об объектах системы. Эта информация является необходимым

дополнением функциональной IDEF0-модели, детализирует объекты,

которыми манипулируют функции системы.

Концептуально IDEF1X-модель можно рассматривать как проект

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

Основными объектами информационной модели являются сущности и

отношения.

138

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

предметов (людей, объектов, мест, событий, состояний, идей, пар предметов и

т.д.), обладающих общими атрибутами или характеристиками. Отдельный

элемент этого множества называется "экземпляром сущности".

Сущность изображается в виде прямоугольного блока, внутри которого

перечислены ее атрибуты. Сущность обладает одним или несколькими

атрибутами. Правила атрибутов:

1. Каждый атрибут должен иметь уникальное имя, одному и тому же имени

должно соответствовать одно и то же значение. Одно и то же значение не

может соответствовать различным именам.

2. Сущность может обладать любым количеством атрибутов. Каждый

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

3. Сущность может обладать любым количеством наследуемых атрибутов, но

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

соответствующей сущности-родителя или общей сущности.

4. Для каждого экземпляра сущности должно существовать значение каждого

его атрибута (правило необращения в нуль).

5. Ни один из экземпляров сущности не может обладать более чем одним

значением для связанного с ней атрибута (правило неповторения).

Первичный ключ – это атрибут или группа атрибутов, которые

однозначно идентифицируют каждый экземпляр сущности. Зная значения

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

сущности. Каждая сущность может обладать любым количеством отношений

с другими сущностями.

Сущность является "независимой", если каждый экземпляр сущности

может быть однозначно идентифицирован без определения его отношений с

другими сущностями. Пример независимой сущности приведен на рис. 3.14.

Сущность OBJECTS имеет четыре атрибута: N_OBJ (номер объекта), TIP

(тип объекта), NAIM (наименование), GOD (год постройки). Первичным

ключом сущности является атрибут N_OBJ, который отделен от остальных

атрибутов чертой.

Сущность называется "зависимой", если однозначная идентификация

экземпляра сущности зависит от его отношения к другой сущности. Пример

зависимой сущности приведен на рис. 3.15. Здесь сущность IZMER

(измерение) зависит от сущности SENSORS (датчики), поскольку записи об

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

измерение. Сущность SENSORS – родительская сущность, IZMER – потомок.

Зависимость отражена наличием в числе атрибутов сущности IZMER

первичного ключа родительской сущности N_SENS.

139

N_OBJ

TIP

NAIM

GOD

OBJECTS

Рисунок 3.14 – Пример независимой сущности

Рисунок 3.15 – Идентифицирующее отношение

Рисунок 3.16 – Неидентифицирующее отношение

Сущность обладает одним или несколькими атрибутами, которые либо

принадлежат сущности, либо наследуются через отношение. Если внешний

ключ целиком используется в качестве первичного ключа сущности или его

части, то сущность является зависимой от идентификатора. И наоборот, если

используется только часть внешнего ключа или вообще не используются

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

Отношение связи, называемое также "отношение родитель-потомок", -

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

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

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

ассоциирован с произвольным (в том числе нулевым) количеством

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

экземпляр сущности-потомка ассоциирован в точности с одним экземпляром

сущности-родителя.

Если экземпляр сущности-потомка однозначно определяется своей

связью с сущностью-родителем, то отношение называется

"идентифицирующим отношением". В противном случае отношение

называется неидентифицирующим. Пример неидентифицирующего

отношения приведен на рис. 3.16.

140

N_SENS

TIP

FIRMA

MARKA

GOD_UST

N_OBJ

SENSORS

N_SENS (FK)

DATE

TIME

MEAN

IZMER

производят

N_OBJ

TIP

NAIM

GOD

OBJECTS

N_SENS

TIP

FIRMA

MARKA

GOD_UST

N_OBJ (FK)

SENSORS

содержат