Проектирования базы данных для АСУТП-систем

Модераторы: kdv, CyberMax

Ответить
EvilsInterrupt
Сообщения: 66
Зарегистрирован: 29 авг 2006, 10:00

Проектирования базы данных для АСУТП-систем

Сообщение EvilsInterrupt » 26 сен 2007, 09:21

День добрый.

Прошу оказать помощь в проектировании базы данных.

Хочу с проектировать базу такой чтобы можно было бы написать приложения решающие следующие задачи:
1. Добавление значений по технологич. параметрам
2. Просмотр технологических параметров
3. Добавить возникший неполадок и то как его устранили, чтобы в будущем можно было просматривать недостаки и быстрее устранять, вновь возникающие
4. Добавить информацию о средствах автоматизации(датчики, контролллеры, ПО типа SCADA-системы) чтобы можно было специалистам иметь всю необходимую информацию
5. Добавить информацию о сотрудников, чтобы если параметр отклонился от нормы, то сразу вычислить виновных и выявить, что же они сделали не так, что им нужно было, чтобы исключить аварийные ситуации.

Из чего пришел к выводу, что в базе надо хранить:
Технологический параметр, Датчик, Контроллер, Компьютер, Программное обеспечение, Разработчик, Поставщик, Сотрудник, График работ, Объект автоматизации, Предприятие.

В чем трудности:
из-за того что некоторые параметры вычисляемые, допустим Суммарная мощность, то необходимо хранить еще и формулу, но как ее потом вычислять? На клиенте? Силами СУБД?

Вобщем прошу поделиться опытом или подсказать те или иные решения, возможно ктото видел где либо примеры готовых баз, прошу поделиться ;)

EvilsInterrupt
Сообщения: 66
Зарегистрирован: 29 авг 2006, 10:00

Дополнение к задаче

Сообщение EvilsInterrupt » 26 сен 2007, 10:41

Ситуация "Как есть":

1) Нижний уровень АСУТП:
Технологический параметр измеряется датчиком, который опрашивается контроллером.
Программа установленная на компьютере может опрашивать один или несколько контрол-
леров. Одна и та же программа может быть установлена на один или несколько компью-
теров, для опроса контроллеров, в виду того что контроллеры могут располагаться на
довольно большом растоянии друг от друга и следовательно одним экземпляром обойтись
нет возможности. Также программа может выдавать обработанные ею данные другой прог-
рамме. После опроса программа может передать обработанные ею данные другой програм-
ме или добавить значения в базу данных. Совокупность программ и компьютеров объеди-
няются в системы, к примеру "автоматизированная система контоля и учета электоэнер-
гии".
Нюанс: Значения некоторых значений могут вноситься и в ручную.

2) Верхний уровень АСУТП:

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

Недостатки ситуации "Как есть":

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

WildSery
Заслуженный разработчик
Сообщения: 1738
Зарегистрирован: 05 июн 2006, 16:19

Сообщение WildSery » 26 сен 2007, 10:58

Сколько денег выделяешь?

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

EvilsInterrupt
Сообщения: 66
Зарегистрирован: 29 авг 2006, 10:00

Сообщение EvilsInterrupt » 26 сен 2007, 11:40

WildSery
Вы правы, это не простой вопрос. Но это и не слова: "ааа, че делать помогите, дайте мне нахаляву конфетку". Я просил совета, возможно я в данной ситуации чего-то не учел, чего стоило бы! Возможно уже есть хороший мануал, где его взять(мануал именно по этой специфике), вероятно уже где-то кто-то видел подобную задачу или обсуждение,тогда прошу привести напарвление или ссылку.

WildSery
Заслуженный разработчик
Сообщения: 1738
Зарегистрирован: 05 июн 2006, 16:19

Re: Проектирования базы данных для АСУТП-систем

Сообщение WildSery » 26 сен 2007, 12:22

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

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Re: Проектирования базы данных для АСУТП-систем

Сообщение hvlad » 26 сен 2007, 15:14

EvilsInterrupt писал(а):В чем трудности:
из-за того что некоторые параметры вычисляемые, допустим Суммарная мощность, то необходимо хранить еще и формулу, но как ее потом вычислять? На клиенте? Силами СУБД?
Это полностью определяется прикладными факторами - где появляются эти параметры, кто и как их вводит, как они друг от друга зависят, нужен ли автоматический пересчёт при изменении одного из пар-ров и т.п.

Могу только сразу сказать - делать из СУБД Ёксель не стоит. Хотя и это возможно :wink:

EvilsInterrupt
Сообщения: 66
Зарегистрирован: 29 авг 2006, 10:00

Сообщение EvilsInterrupt » 26 сен 2007, 15:32

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

Теперь вопрос такой, как мне начать? Я почитал, что такое 1НФ, 2НФ, 3НФ - ее мне вполне хватит. Но как начать? ;)

Выписать все на листочек, что я хочу хранить, после всего этого выделить сущности, задать меж ними связи и т.д. и т.п. Может где-то
есть конкретные примеры? А то я в манулах вижу только слова вида: "Сущностью называется ..." но вот как ее получить на реальных примерах нет или я плохо искал.

WildSery
Заслуженный разработчик
Сообщения: 1738
Зарегистрирован: 05 июн 2006, 16:19

Сообщение WildSery » 26 сен 2007, 18:02

EvilsInterrupt писал(а):Выписать все на листочек
Можно воспользоваться каким-нибудь дизайнером, например, в IBExpert встроен простой.

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 26 сен 2007, 21:07

Выписать все на листочек, что я хочу хранить, после всего этого выделить сущности, задать меж ними связи и т.д. и т.п.
ты ООП пользуешься? классы моделировал? Тут примерно то же самое.

кроме того, в моделировании есть обратный способ. Сначала надо описать все атрибуты объектов, кому бы они не принадлежали. Включая предполагаемые идентификаторы клиентов, товаров и прочей фигни. НО! Именовать атрибуты нужно качественно.
Например, "Наименование клиента" и "Наименование товара" - это разные атрибуты. Даже если их тип одинаков, то нельзя для обоих заводить просто "Наименование". ЭТО если и можно делать, то только как домен, для использования при указании типа реального атрибута.

Так вот, все атрибуты в кучу. В этой куче погибнут дубликаты атрибутов - например "ФИО клиента", или что-нибудь в этом роде, если оно фигурировало в нескольких "документах". Потом надо взять и назвать какую-нибудь сущность. Например, "компьютер". И наполнить ее атрибутами, только к ней относящимися.
При этом переносимые в сущность атрибуты надо из общего списка атрибутов исключать.

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

Примерно так.

EvilsInterrupt
Сообщения: 66
Зарегистрирован: 29 авг 2006, 10:00

Сообщение EvilsInterrupt » 27 сен 2007, 07:20

kdv
Хорошо на заданную ниже ситуацию, как бы ты поступил:

Есть "Температура на трубопроводе №1" его измеряет термопара типа ХК, термопару опрашивает промышленный контроллер ADAM 4018, который в свою очередь опрашивается компьютером на котором установлена Программа с именем "Программа №1". Все это сводится в систему под названием "Система №1".

Я вижу что, тут надо задать сущности:
Параметр с атрибутами Наименование, минимум шкалы, максиум шкалы, единица измерения

Датчик с атрибутами Наименование, тип, минумум сигнала, максимум сигнала, опрашивающий контроллер

Компьютер с IP-адрес, ОЗУ, Процессор

Программа с Наименование, разработчик, наименование компьютера

Система с Наименование

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

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 27 сен 2007, 09:38

Я вижу что, тут надо задать сущности:
Параметр с атрибутами Наименование, минимум шкалы, максиум шкалы, единица измерения
поднимите мне веки! я ВИЖУ ТИПЫ ДАННЫХ! Надо в базе создать таблицу DATATYPES! И все валить в блобы! :)

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

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

я, с утра, не попивши кофе, попробую привести такой пример.

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

вопрос - телефон это аппарат, или это номер телефона?
если номер телефона, то разве тут появляется сущность "телефон"?
можно сделать ДОМЕН "номер телефона", и повтыкать его как атрибут сущностей клиент, организация и отдел.

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

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

EvilsInterrupt
Сообщения: 66
Зарегистрирован: 29 авг 2006, 10:00

Сообщение EvilsInterrupt » 27 сен 2007, 16:14

У меня есть сущности Application, Computer , мне нужно задать такие атрибуты, с помощью которых можно получить ответы на вопросы:

1) Какие именно программы установлены на данном компьютере?
2) На каких именно компьютерах установлена эта программа?

Думаю это связь многие-ко-многим, Application_To_Computer, но что-то не пойму: А как будет использоваться ? ;)

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 27 сен 2007, 17:30

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

create table app_comp
(id_app int not null,
id_comp int not null,
constraint pk_app_comp primary key (id_app, id_comp))

потом добавить 2 FK
alter table app_comp add constraint ... foreign key...
с id_app на ПК id_app в приложениях,
и с id_comp на ПК id_comp в компьютерах.

если несколько экземпляров, добавится столбец cnt int (не входящий в ПК), и все.

Как объединять таблицы, и делать по ним поиск в похожих связях, написано тут
www.ibase.ru/devinfo/joins.htm

p.s. это элементарщина, на уровне лабораторной или азов моделирования таблиц. Купи себе Дейта.

Ответить