Проектирования базы данных для АСУТП-систем
-
- Сообщения: 66
- Зарегистрирован: 29 авг 2006, 10:00
Проектирования базы данных для АСУТП-систем
День добрый.
Прошу оказать помощь в проектировании базы данных.
Хочу с проектировать базу такой чтобы можно было бы написать приложения решающие следующие задачи:
1. Добавление значений по технологич. параметрам
2. Просмотр технологических параметров
3. Добавить возникший неполадок и то как его устранили, чтобы в будущем можно было просматривать недостаки и быстрее устранять, вновь возникающие
4. Добавить информацию о средствах автоматизации(датчики, контролллеры, ПО типа SCADA-системы) чтобы можно было специалистам иметь всю необходимую информацию
5. Добавить информацию о сотрудников, чтобы если параметр отклонился от нормы, то сразу вычислить виновных и выявить, что же они сделали не так, что им нужно было, чтобы исключить аварийные ситуации.
Из чего пришел к выводу, что в базе надо хранить:
Технологический параметр, Датчик, Контроллер, Компьютер, Программное обеспечение, Разработчик, Поставщик, Сотрудник, График работ, Объект автоматизации, Предприятие.
В чем трудности:
из-за того что некоторые параметры вычисляемые, допустим Суммарная мощность, то необходимо хранить еще и формулу, но как ее потом вычислять? На клиенте? Силами СУБД?
Вобщем прошу поделиться опытом или подсказать те или иные решения, возможно ктото видел где либо примеры готовых баз, прошу поделиться
Прошу оказать помощь в проектировании базы данных.
Хочу с проектировать базу такой чтобы можно было бы написать приложения решающие следующие задачи:
1. Добавление значений по технологич. параметрам
2. Просмотр технологических параметров
3. Добавить возникший неполадок и то как его устранили, чтобы в будущем можно было просматривать недостаки и быстрее устранять, вновь возникающие
4. Добавить информацию о средствах автоматизации(датчики, контролллеры, ПО типа SCADA-системы) чтобы можно было специалистам иметь всю необходимую информацию
5. Добавить информацию о сотрудников, чтобы если параметр отклонился от нормы, то сразу вычислить виновных и выявить, что же они сделали не так, что им нужно было, чтобы исключить аварийные ситуации.
Из чего пришел к выводу, что в базе надо хранить:
Технологический параметр, Датчик, Контроллер, Компьютер, Программное обеспечение, Разработчик, Поставщик, Сотрудник, График работ, Объект автоматизации, Предприятие.
В чем трудности:
из-за того что некоторые параметры вычисляемые, допустим Суммарная мощность, то необходимо хранить еще и формулу, но как ее потом вычислять? На клиенте? Силами СУБД?
Вобщем прошу поделиться опытом или подсказать те или иные решения, возможно ктото видел где либо примеры готовых баз, прошу поделиться
-
- Сообщения: 66
- Зарегистрирован: 29 авг 2006, 10:00
Дополнение к задаче
Ситуация "Как есть":
1) Нижний уровень АСУТП:
Технологический параметр измеряется датчиком, который опрашивается контроллером.
Программа установленная на компьютере может опрашивать один или несколько контрол-
леров. Одна и та же программа может быть установлена на один или несколько компью-
теров, для опроса контроллеров, в виду того что контроллеры могут располагаться на
довольно большом растоянии друг от друга и следовательно одним экземпляром обойтись
нет возможности. Также программа может выдавать обработанные ею данные другой прог-
рамме. После опроса программа может передать обработанные ею данные другой програм-
ме или добавить значения в базу данных. Совокупность программ и компьютеров объеди-
няются в системы, к примеру "автоматизированная система контоля и учета электоэнер-
гии".
Нюанс: Значения некоторых значений могут вноситься и в ручную.
2) Верхний уровень АСУТП:
Данные для просмотра оперативным персоналом отображаются на экране, в результате
получения выборки из базы данных. Персонал выполняет следующие действия:
- Просмотр\распечатка значений технологических параметров в виде цифр
- Просмотр\распечатка значений тех. параметров в виде графиков
Недостатки ситуации "Как есть":
- Нет возможности узнать производителя, серийный номер, контроллера
- Нет возможности занести информацию о возникшем дефекте, статус дефекта, лицо обна-
ружевшее дефект, лицо его устранившее и способ устраненения.
- Нет возможности выдать список возникавших ранее дефектов
- Нет возможности узнать кто поставил контроллер, компьютер
- Нет возможности узнать кто разработал программу
- Нет возможности узнать сотрудника который вел технологический режим в конкретный
момент времени.
- Нет возможности хранить документацию по установке использованию, настройке датчиков,
контроллеров, компьютеров.
- Нет возможности вывода значений по системе согласно вахтам, под вахтами следует по-
нимать график работы сотрудников.
1) Нижний уровень АСУТП:
Технологический параметр измеряется датчиком, который опрашивается контроллером.
Программа установленная на компьютере может опрашивать один или несколько контрол-
леров. Одна и та же программа может быть установлена на один или несколько компью-
теров, для опроса контроллеров, в виду того что контроллеры могут располагаться на
довольно большом растоянии друг от друга и следовательно одним экземпляром обойтись
нет возможности. Также программа может выдавать обработанные ею данные другой прог-
рамме. После опроса программа может передать обработанные ею данные другой програм-
ме или добавить значения в базу данных. Совокупность программ и компьютеров объеди-
няются в системы, к примеру "автоматизированная система контоля и учета электоэнер-
гии".
Нюанс: Значения некоторых значений могут вноситься и в ручную.
2) Верхний уровень АСУТП:
Данные для просмотра оперативным персоналом отображаются на экране, в результате
получения выборки из базы данных. Персонал выполняет следующие действия:
- Просмотр\распечатка значений технологических параметров в виде цифр
- Просмотр\распечатка значений тех. параметров в виде графиков
Недостатки ситуации "Как есть":
- Нет возможности узнать производителя, серийный номер, контроллера
- Нет возможности занести информацию о возникшем дефекте, статус дефекта, лицо обна-
ружевшее дефект, лицо его устранившее и способ устраненения.
- Нет возможности выдать список возникавших ранее дефектов
- Нет возможности узнать кто поставил контроллер, компьютер
- Нет возможности узнать кто разработал программу
- Нет возможности узнать сотрудника который вел технологический режим в конкретный
момент времени.
- Нет возможности хранить документацию по установке использованию, настройке датчиков,
контроллеров, компьютеров.
- Нет возможности вывода значений по системе согласно вахтам, под вахтами следует по-
нимать график работы сотрудников.
-
- Сообщения: 66
- Зарегистрирован: 29 авг 2006, 10:00
WildSery
Вы правы, это не простой вопрос. Но это и не слова: "ааа, че делать помогите, дайте мне нахаляву конфетку". Я просил совета, возможно я в данной ситуации чего-то не учел, чего стоило бы! Возможно уже есть хороший мануал, где его взять(мануал именно по этой специфике), вероятно уже где-то кто-то видел подобную задачу или обсуждение,тогда прошу привести напарвление или ссылку.
Вы правы, это не простой вопрос. Но это и не слова: "ааа, че делать помогите, дайте мне нахаляву конфетку". Я просил совета, возможно я в данной ситуации чего-то не учел, чего стоило бы! Возможно уже есть хороший мануал, где его взять(мануал именно по этой специфике), вероятно уже где-то кто-то видел подобную задачу или обсуждение,тогда прошу привести напарвление или ссылку.
Re: Проектирования базы данных для АСУТП-систем
Конкретно в этом вопросе я видел оба варианта, и оба рабочих и самодостаточных. (В случае БД это была UDF)EvilsInterrupt писал(а):В чем трудности:
из-за того что некоторые параметры вычисляемые, допустим Суммарная мощность, то необходимо хранить еще и формулу, но как ее потом вычислять? На клиенте? Силами СУБД?
На клиенте, думаю, реализация проще.
С другой стороны, если кусок бизнес-логики реализован в БД, то он может потребовать такой расчёт внутри базы.
Re: Проектирования базы данных для АСУТП-систем
Это полностью определяется прикладными факторами - где появляются эти параметры, кто и как их вводит, как они друг от друга зависят, нужен ли автоматический пересчёт при изменении одного из пар-ров и т.п.EvilsInterrupt писал(а):В чем трудности:
из-за того что некоторые параметры вычисляемые, допустим Суммарная мощность, то необходимо хранить еще и формулу, но как ее потом вычислять? На клиенте? Силами СУБД?
Могу только сразу сказать - делать из СУБД Ёксель не стоит. Хотя и это возможно
-
- Сообщения: 66
- Зарегистрирован: 29 авг 2006, 10:00
Да, есть такой фактор, что есть множество параметров, которые я бы назвал вычислимыми. Эти параметры не измеряются физически, но получаются в результате проведения математич. действий над измеренными физичискими величинами. Клиентских программ грубо говоря 30 делающих запросы очередные 180 сек. - отсюда вывод, что лучше задать процедуры, которые из значений в таблице делают вычисления. Таким образом получим тонкие клиенты к базе.
Теперь вопрос такой, как мне начать? Я почитал, что такое 1НФ, 2НФ, 3НФ - ее мне вполне хватит. Но как начать?
Выписать все на листочек, что я хочу хранить, после всего этого выделить сущности, задать меж ними связи и т.д. и т.п. Может где-то
есть конкретные примеры? А то я в манулах вижу только слова вида: "Сущностью называется ..." но вот как ее получить на реальных примерах нет или я плохо искал.
Теперь вопрос такой, как мне начать? Я почитал, что такое 1НФ, 2НФ, 3НФ - ее мне вполне хватит. Но как начать?
Выписать все на листочек, что я хочу хранить, после всего этого выделить сущности, задать меж ними связи и т.д. и т.п. Может где-то
есть конкретные примеры? А то я в манулах вижу только слова вида: "Сущностью называется ..." но вот как ее получить на реальных примерах нет или я плохо искал.
ты ООП пользуешься? классы моделировал? Тут примерно то же самое.Выписать все на листочек, что я хочу хранить, после всего этого выделить сущности, задать меж ними связи и т.д. и т.п.
кроме того, в моделировании есть обратный способ. Сначала надо описать все атрибуты объектов, кому бы они не принадлежали. Включая предполагаемые идентификаторы клиентов, товаров и прочей фигни. НО! Именовать атрибуты нужно качественно.
Например, "Наименование клиента" и "Наименование товара" - это разные атрибуты. Даже если их тип одинаков, то нельзя для обоих заводить просто "Наименование". ЭТО если и можно делать, то только как домен, для использования при указании типа реального атрибута.
Так вот, все атрибуты в кучу. В этой куче погибнут дубликаты атрибутов - например "ФИО клиента", или что-нибудь в этом роде, если оно фигурировало в нескольких "документах". Потом надо взять и назвать какую-нибудь сущность. Например, "компьютер". И наполнить ее атрибутами, только к ней относящимися.
При этом переносимые в сущность атрибуты надо из общего списка атрибутов исключать.
Дальше - следующая сущность, и т.п. Атрибутов будет оставаться все меньше, пока они не кончатся.
Потом нужно нарисовать связи между сущностями. Это будет концептуальная модель.
Потом концептуальную можно превратить в физическую, где сущности уже будут содержать столбцы ссылок на другие сущности (FK).
Примерно так.
-
- Сообщения: 66
- Зарегистрирован: 29 авг 2006, 10:00
kdv
Хорошо на заданную ниже ситуацию, как бы ты поступил:
Есть "Температура на трубопроводе №1" его измеряет термопара типа ХК, термопару опрашивает промышленный контроллер ADAM 4018, который в свою очередь опрашивается компьютером на котором установлена Программа с именем "Программа №1". Все это сводится в систему под названием "Система №1".
Я вижу что, тут надо задать сущности:
Параметр с атрибутами Наименование, минимум шкалы, максиум шкалы, единица измерения
Датчик с атрибутами Наименование, тип, минумум сигнала, максимум сигнала, опрашивающий контроллер
Компьютер с IP-адрес, ОЗУ, Процессор
Программа с Наименование, разработчик, наименование компьютера
Система с Наименование
Вот теперь возникает вопрос, как вытащить из этих сущностей все параметры относящиеся к системе? Ведь параметр может относиться и не к одной системе, а к нескольким!
Хорошо на заданную ниже ситуацию, как бы ты поступил:
Есть "Температура на трубопроводе №1" его измеряет термопара типа ХК, термопару опрашивает промышленный контроллер ADAM 4018, который в свою очередь опрашивается компьютером на котором установлена Программа с именем "Программа №1". Все это сводится в систему под названием "Система №1".
Я вижу что, тут надо задать сущности:
Параметр с атрибутами Наименование, минимум шкалы, максиум шкалы, единица измерения
Датчик с атрибутами Наименование, тип, минумум сигнала, максимум сигнала, опрашивающий контроллер
Компьютер с IP-адрес, ОЗУ, Процессор
Программа с Наименование, разработчик, наименование компьютера
Система с Наименование
Вот теперь возникает вопрос, как вытащить из этих сущностей все параметры относящиеся к системе? Ведь параметр может относиться и не к одной системе, а к нескольким!
поднимите мне веки! я ВИЖУ ТИПЫ ДАННЫХ! Надо в базе создать таблицу DATATYPES! И все валить в блобы!Я вижу что, тут надо задать сущности:
Параметр с атрибутами Наименование, минимум шкалы, максиум шкалы, единица измерения
гипербола, конечно, но я сущности "параметр" тут в упор не вижу.
пока я вижу атрибуты
номер термопары
температура с термопары
и, собственно, все. остальное - фантазии.
это вообще нонсенс, исходя из приведенной модели.Вот теперь возникает вопрос, как вытащить из этих сущностей все параметры относящиеся к системе? Ведь параметр может относиться и не к одной системе, а к нескольким!
я, с утра, не попивши кофе, попробую привести такой пример.
есть организация, у нее есть телефон.
есть клиент, у него есть телефон
есть отдел, у него есть телефон
вопрос - телефон это аппарат, или это номер телефона?
если номер телефона, то разве тут появляется сущность "телефон"?
можно сделать ДОМЕН "номер телефона", и повтыкать его как атрибут сущностей клиент, организация и отдел.
А сущность телефон - это когда есть конкретный аппарат, с номером модели, производителем, серийным номером и т.п.
так что не перебарщивай, а то дойдешь до того, что все данные будешь хранить в блобах в одной таблице.
-
- Сообщения: 66
- Зарегистрирован: 29 авг 2006, 10:00
У меня есть сущности Application, Computer , мне нужно задать такие атрибуты, с помощью которых можно получить ответы на вопросы:
1) Какие именно программы установлены на данном компьютере?
2) На каких именно компьютерах установлена эта программа?
Думаю это связь многие-ко-многим, Application_To_Computer, но что-то не пойму: А как будет использоваться ?
1) Какие именно программы установлены на данном компьютере?
2) На каких именно компьютерах установлена эта программа?
Думаю это связь многие-ко-многим, Application_To_Computer, но что-то не пойму: А как будет использоваться ?
экий ты дикий.
сначала ответь на вопрос - одна программа может быть установлена на одном компьютере в нескольких экземплярах?
если нет, то тогда таблица связи простая
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. это элементарщина, на уровне лабораторной или азов моделирования таблиц. Купи себе Дейта.
сначала ответь на вопрос - одна программа может быть установлена на одном компьютере в нескольких экземплярах?
если нет, то тогда таблица связи простая
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. это элементарщина, на уровне лабораторной или азов моделирования таблиц. Купи себе Дейта.