Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Содержание

Введение

Глава 1. Описание методологии функционального моделирования.

1.1 Модель IDEF0.

1.2 Модель IDEF3.

1.3 Модель DFD.

1.4 Инфологическая модель.

1.5 Логическая модель.

1.6 Физическая модель.

Глава 2. Информационная подсистема автоматизированной системы оперативно-диспетчерского управления и учета энергоснабжением.

2.1 Модель IDEF0.

2.1.1 Контекстная диаграмма АСОДУЭ.

2.1.2 Декомпозиция функции «Выполнить управление АСОДУЭ».

2.1.3 Декомпозиция А2 функции «Выполнить управление системой АСОДУЭ».

2.1.4 Дерево узлов.

2.2.1 Декомпозиция функции А2.3 «Подготовить рабочее место».

2.3 Модель DFD.

2.3.1 Модель DFD для подсистемы «Контролировать качество выполнения».

2.4 Инфологическая модель.

Глава 3. Создание базы данных АSODUE.

Заключение

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

Приложение

Введение

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

Глава 1. Описание методологии функционального моделирования

1.1 Модель IDEF0

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

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

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

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

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

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

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

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

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

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

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

Однако в системном анализе вместо термина «объекты» часто употребляют термин «данные».

Так как дуги изображают объекты, они описываются (помечаются) существительными или существительными с определениями, располагающимися достаточно близко к линии дуги. Рекомендуется размещать описания, дуг, называемые метками, как можно ближе к линиям дуг, не нарушая, однако, читабельность диаграмм. Это устраняет неопределенность в том, к какой дуге относится метка, и исключается необходимость в дополнительных графических связях.

Между объектами и функциями возможны четыре отношения: вход управление, выход механизма. Каждое из этих отношений изображается дугой, связанной с определенной стороной блока. Дуги кодируются код состоит из латинской буквы I, С, Q, М и числа. По соглашение левая сторона блока предназначена для входных дуг, верхняя сторона - для управленческих дуг; правая сторона - для выходных дуг, нижняя сторона - для дуг механизмов. Таким образом, стороны блока чисто графически сортируют объекты, отображаемые касающимися блока дугами.

Выходные дуги отображают объекты, используемые и преобразуемые входы функциями. Управленческие дуги представляют информацию, управляющую действиями функций. Обычно управляющие дуги несут информацию, которая указывает, что должна выполнять функция.

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

В методологии IDEFO требуется только пять типов взаимосвязей между

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

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

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

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

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

· непомеченные ветви содержат все объекты, указанные в метке дуги перед разветвлением (т.е. все объекты принадлежат этим ветвям);

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

Слияние дуг в SADT, изображаемое как сходящиеся вместе линии указывает, что содержимое каждой ветви идет на формирование метки для дуги, являющейся результатом слияния исходных дуг. После слияния результирующая дуга всегда помечается для указания нового набора объектов, возникшего после объединения.

Кроме того, каждая ветвь перед слиянием может помечаться или не помечаться в соответствии со следующими правилами:

· непомеченные ветви содержат все объекты указанные в общей метке дуги после слияния (т.е. все объекты исходят из всех ветвей);

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

1.2 Модель IDEF3

Основой модели IDEF3 служит сценарий (алгоритм) процесса, который выделяет последовательность действий анализируемой системы, с одновременным описанием объектов, имеющих непосредственное отношение к процессу. Диаграмма является основной единицей описания в IDEF3.

IDEF 3 модель органично дополняет модели IDEF0 и может являться описанием некоторого процесса анализируемой системы ПО. В этом случае IDEF3 модель может быть получена на основе декомпозиции некоторой функции модели IDEF0. IDEF3 модель может быть также использована как метод создания процессов.

Единицы работы (Unit of Work или UOW), также называемые работами,
являются центральными компонентами модели. В IDEF3 работы изображаются прямоугольниками с прямыми углами и имеют имя, выраженное отглагольным существительные обозначающим процесс действия, одиночным или в составе фразы и номер (идентификатор); другое имя существительное в составе той же фразы обычно отображает основной выход (результат) работы.

В IDEF3 декомпозиция используется для детализации работ. Методология IEEF3 позволяет декомпозировать работу многократно, т. е. работа может иметь множество дочерних работ. Это позволяет в одной модели описать альтернативные потоки. Возможность множественной декомпозиции предъявляет дополнительные требования к нумерации, работ. Так номер работы А3. 2 5 состоит из номера родительской работы - 1, версии декомпозиции - 2 и собственного номера работы на текущей диаграмме - 5.

Связи показывают взаимоотношения работ. Все связи в IDEF3 однонаправлены и могут быть направлены куда угодно, но обычно диаграммы IDEF3 стараются построить так, чтобы связи были направлены слева направо. В IDEF3 различают три типа стрелок, изображающих связи:

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

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

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

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

Различают перекрестки для слияния и разветвления стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления.

Все перекрестки на диаграмме нумеруются, каждый номер имеет префикс J.

Диаграммы IDEF3 могут содержать указатели, которые предназначены для привлечения внимания читателя к каким-либо важным аспектам модели. Указатели изображаются на диаграмме в виде прямоугольника, похожего на изображение работы. Имя указателя включает его тип. Среди указателей различают типы объект, ссылка, заметка, уточнение.

1.3 Модель DFD

Диаграммы потоков данные (DFD) обесточивают удобный способ описания передаваемой информации, как между частями системы, так и между системой и внешним миром. Потому они используются, для создания, моделей информационного обмена организации, например документооборота. DFD модель органично дополняет модели IDEF0 и IDEF3 и является описанием информационного обмена некоторой подсистемы анализируемой системы ПО. Таким образом модель может быть получена на основе декомпозиции некоторой функции модели IDEF0.

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

Контекстная диаграмма, как правило, состоит из одного функционального блока и нескольких внешних сущностей. Функциональный блок имеет при этом имя, совпадающее с именем всей системы.

В DFD работы представляют собой функции системы, преобразующие входы и выходы. Хотя работы изображаются прямоугольниками со скругленными углами, смысл их совпадает со смыслом работ IDEF0 и IDEF3. Также как работы IDEF3, они имеют входы и выходы, но не поддерживают управления и механизмы, как IDEF0.

Внешние сущности изображают входы в систему и/или выходы из системы. Внешние сущности изображаются в виде прямоугольника с тенью и обычно располагаются по краям диаграммы. Одна внешняя сущность может быть использована многократно на одной или нескольких диаграммах. Обычно такой прием используют, чтобы не рисовать слишком длинных и запутанных стрелок.

Стрелки описывают движение объектов из одной части системы в другую. Поскольку в DFD каждая сторона работы не имеет четкого назначения, как в IDEF0, стрелки могут подходить и выходить из любой грани прямоугольника работы. В DFD также применяются двунаправленные стрелки для описания диалогов типа «команда-ответ» между работами, между работой и внешней сущностью и между внешними сущностями.

В DFD стрелки могут сливаться и разветвляться, что позволяет описать декомпозицию стрелок. Каждый новый сегмент сливающейся или разветвляющейся стрелки может иметь собственное имя.

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

В DFD номер каждой работы может включать префикс, номер родительской работы (А) и номер объекта. Номер объекта - это уникальный номер работы на диаграмме. Например, работа может иметь номер А.12.4 . Уникальный номер и имеют хранилища данных и внешние сущности независимо от их расположения на диаграмме. Каждое хранилище данных имеет префикс D и уникальный номер, например D6. Каждая внешняя сущность имеет префикс Е и уникальный номер, например Е5.

1.4 Инфологическая модель

Инфологическая модель должна быть разработана на основе представленной DFD модели. Таким образом, это будет модель некоторой подсистемы рассматриваемой системы ПО.

Модель может быть описана на языке ЕR - диаграмм при этом допускается гибридная нотация с разъяснением обозначений. Атрибуты сущности должны удовлетворять требованиям третьей нормальной формы реляционной модели.

Процесс проведения нормализации.

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

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

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

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

1.5 Логическая модель

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

Логическая модель должна быть описана средствами языка SQL, а именно SQL-DDL.

· Создание базы данных

CREATE DATABASE <имя базы данных>;

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

CREATE TABLE <имя таблицы>(<имя столбца>, <тип столбца>)

[NOT NULL] [UN QUE] [PRIMARI KEY] [REFERENCES <имя таблицы>) [<имя столбца>];

· Создание индекса CREATE [UN QUE] INDEX <имя индекса>,

ON <имя таблицы>, (<имя столбца>).

1.6 Физическая модель

Модель должна включать:

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

· 4-5 записей для каждого отношения;

· 2-3 представления для различных таблиц данных;

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

· триггер для одной из таблиц контролирующий операцию добавления новых записей в таблицу;

· описание запросов к таблицам следующего характера:

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

2. Запрос на выборку записей, удовлетворяющих некоторому условию с использованием логической операции проверки на вхождение в список;
3. Запрос на выборку записей из таблиц являющийся результатом слияния двух других таблиц по некоторому условию;

4. Запрос с использованием агрегатных функций;

5. Запрос на выборку записей с условием сортировки;

6. вложенный запрос на выборку записей с использованием предиката EXI STS.

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

Глава 2. Информационная подсистема автоматизированной системы оперативно-диспетчерского управления и учета энергоснабжением (АСОДУЭ)

2.1 Модель IDEF0

Название функции проектируемой системы А0 - выполнить управление АСОДУЭ.

Целью модели IDEF0 АСОДУЭ является разработка информационной подсистемы автоматизированной системы оперативно-диспетчерского управления и учета энергоснабжением на основе анализа и моделирования предметной области.

Функция первого уровня А1 - управление выполнением задания.

Функция первого уровня А2 - выполнить управление системой АСОДУЭ.

Функция второго уровня А2.1 - определить степень выполнения задания.

Функция второго уровня А2.2 - выбрать оборудование.

Функция второго уровня А2.3 - подготовить рабочее место.

Функция второго уровня А2.4 - учесть и передать электроэнергию.

Функция первого уровня А3 - произвести учет и передачу электроэнергии.

Функция первого уровня А4 - контролировать качество выполнения.

2.1.1 Контекстная диаграмма АСОДУЭ

Контекстная модель АСОДУЭ (приложение 1) рассматривается с точки зрения передачи электроэнергии потребителю без потерь, перебоев, при использовании персоналом электроцеха оборудования контроля и учета электроэнергии и, основываясь на справочниках, стандартах и утвержденных документах в которых указаны потребители, сроки и количество киловатт часов.

2.1.2 Декомпозиция функции «Выполнить управление АСОДУЭ»

Целью декомпозиции функции «Выполнить управление АСОДУЭ » является создание информационной подсистемы, которая показывает, какие функции первого уровня необходимы для успешного выполнения поставленного задания.

Диаграмма декомпозиции А0 «Выполнить управление АСОДУЭ» (приложение 2) включает в себя четыре функции первого уровня, а именно:

Функция первого уровня А1 - управление выполнением задания.

Функция первого уровня А2 - выполнить управление системой АСОДУЭ.

Функция первого уровня А3 - произвести учет и передачу электроэнергии.

Функция первого уровня А4 - контролировать качество выполнения.

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

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

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

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

2.1.3 Декомпозиция А2 функции «Выполнить управление системой АСОДУЭ»

Целью декомпозиции функции «Выполнить управление системой АСОДУЭ » является создание информационной подсистемы, которая показывает, какие функции второго уровня необходимы для выполнения данного вида работ.

Диаграмма декомпозиции А2 «Выполнить управление системой АСОДУЭ» (приложение 3) включает в себя четыре функции второго уровня, а именно:

Функция второго уровня А2.1 - определить степень выполнения задания.

Функция второго уровня А2.2 - выбрать оборудование.

Функция второго уровня А2.3 - подготовить рабочее место.

Функция второго уровня А2.4 - учесть и передать электроэнергию.

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

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

2.1.4 Дерево узлов

Дерево узлов это обзорная диаграмма, показывающая структуру всей модели. Обычно структура соответствует контекстному блоку, под вершинами выстраивается вся иерархия функциональных блоков модели (приложение 4).

2.2 Модель IDEF3

2.2.1 Декомпозиция функции А2.3 «Подготовить рабочее место»

Цель данной декомпозиции - это по шагам показать, как необходимо подготовить рабочее место перед началом работы.

В диаграмму декомпозиции функции А2.3. «Подготовить рабочее место» входят (приложение 5):

1. Работы:

· Изучить данные по потреблению электроэнергии и тарифам (необходимо получить у начальника отделения утвержденные планы и тарифы по электроэнергии);

· включить ПЭВМ;

· запустить программу;

· ввести данные в программу;

· проверить состояние заземления (программное обеспечение позволяет удаленно с ПЭВМ проверить наличие заземления);

· проверить связь ПЭВМ с контроллером (программное обеспечение постоянно отслеживает состояние контроллеров);

· отключить заземление (при подаче напряжения, необходимо отключить заземление соединительных линий);

· подать управляющее напряжение (с ПЭВМ через контроллер управляющее напряжение подается на исполнительное устройство).

2. Объекты:

· Электрощит (распределительный пункт, в котором подключается заземление);

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

2.3 Модель DFD

Цель модели DFD - показать движение информационного обмена (документации) организации.

Контекстная диаграмма модели DFD АСОДУЭ (приложение 6) показывает взаимосвязь системы с отделами предприятия и сторонними организациями, например в нашем случае это - научно-исследовательская лаборатория, отдел главного энергетика, отдел стандартизации и сертификации. К сторонним организациям можно отнести поставщиков оборудования и потребителей электроэнергии, а также внутренние цеха предприятия.

2.3.1 Модель DFD для подсистемы «Контролировать качество выполнения»

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

На диаграмме DFD для подсистемы «контролировать качество выполнения» (приложение 7) показаны:

1. Хранилища данных - это справочники D3 и утвержденный план D1.

2. Внешние сущности - это научно-исследовательская лаборатория Е1, отдел стандартизации и сертификации Е2 и отдел главного энергетика Е3.

3. Работа - это Создание отчета по отпуску электроэнергии А1 и сверить с утвержденными данными А2.

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

2.4 Инфологическая модель

Цель инфологической модели рассмотреть хранилище данных нашем случае это «Отчет по отпуску электроэнергии».

Рис. 2 Инфологическая модель хранилища данных «Отчет по отпуску электроэнергии» подсистемы «Контролировать качество выполнения» системы «Выполнить управление АСОДУЭ».

Глава 3. Создание базы данных АSODUE

CREATE DATABASE АSODUE.

3.1 Создание таблицы «Распределительные подстанции»

CREATE TABLE RASPPOD

(PNUM CHAR (255) NOT NULL PRIMARY KEY ,

TYHET NUMERIC (9) NOT NULL,

NFID NUMERIC (9) NOT NULL ,

NCHEX NUMERIC (9) NOT NULL,

TARIF CHAR (255) NOT NULL,

LIMIT NUMERIC (9) NOT NULL,

OPISANIE CHAR (255) NOT NULL)

3.2 Создание таблицы «Параметры»

CREATE TABLE PARAMETR

(PNUM CHAR (255) NOT NULL PRIMARY KEY,

TYHET NUMERIC (9) NOT NULL REFERENCES RASPPOD,

NFID NUMERIC (9) NOT NULL,

KODXAR CHAR (255) NOT NULL,

TAMEZAM CHAR (255) NOT NULL,

EDIZM CHAR (255) NOT NULL,

OTMSOOTV CHAR (255) NOT NULL)

3.3 Создание таблицы «Характеристики»

CREATE TABLE XARAKTERISTIKI

(PNUM CHAR (255) NOT NULL PRIMARY KEY,

TYHET NUMERIC (9) NOT NULL REFERENCES RASPPOD,

NFID NUMERIC (9) NOT NULL,

U CHAR (255) NOT NULL,

I CHAR (255) NOT NULL,

P CHAR (255) NOT NULL)

Создание индекса.

CREATE INDEX IDPNUM ON RASPPOD (PNUM)

3.4 Заполнение таблицы «Распределительные подстанции»

INSERT INTO RASPPOD

VALUES (1,'ГПП-11', '1',24, 0.96, 1000, 'ПОТРЕБИТЕЛЬ ЦЕХ № 22')

3.5 Заполнение таблицы «Параметры»

INSERT INTO PARAMETR

VALUES (1, 'ГПП-11', 1, 01, '12.01.2005', 'Вт', 'СООТВЕТСТВУЕТ')

3.6 Заполнение таблицы «Характеристики»

INSERT INTO XARAKTERISTIKI

VALUES (1,'ГПП-11', 1, 220 , 1, 100)

3.7 Создание представления

CREATE VIEW ACOD1

AS SELECT RASPPOD. PNUM, RASPPOD. TYHET, RASPPOD. NFID,

OPISANIE, OTMSOOTV, TAMEZAM

FROM RASPPOD, PARAMETR, XARAKTERISTIKI

SELECT * FROM ACOD1

3.8 Создание представления

CREATE VIEW ACOD

AS SELECT RASPPOD. PNUM, RASPPOD. TYHET, RASPPOD. NFID, OTMSOOTV, OPISANIE, TAMEZAM, U, I, P

FROM RASPPOD, PARAMETR, XARAKTERISTIKI

SELECT PNUM, TYHET, NFID, OPISANIE, TAMEZAM, U, I, P, OTMSOOTV FROM ACOD

WHERE OTMSOOTV IN ('НЕСООТВЕТСТВУЕТ')

3.9 Добавление столбца в таблицу

ALTER TABLE RASPPOD

ADD POSTAVHIC SMALLMONEY

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

CREATE PROCEDURE NEWTARIF (@TARIF real) AS

UPDATE RASPPOD

SET TARIF=TARIF+@TARIF WHERE LIMIT >3000

EXEC NEWTARIF @TARIF =3000

3.11 Запрос на выборку записей удовлетворяющих некоторому условию с использованием логической операции проверки на вхождение в интервал

SELECT * FROM RASPPOD

WHERE LIMIT > 950 AND LIMIT < 5000

SELECT * FROM RASPPOD

WHERE LIMIT BETWEEN 950 AND 5000

3.12 Запрос на выборку записей удовлетворяющих некоторому условию с использованием логической операции проверки на вхождение в список

SELECT * FROM RASPPOD

WHERE TYHET IN ('ГПП-11','ГПП-3')



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

SELECT RASPPOD.TYHET, RASPPOD.NFID,PARAMETR.TAMEZAM,XARAKTERISTIKI. U, I, P

FROM RASPPOD, PARAMETR, XARAKTERISTIKI

WHERE LIMIT > 3000

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

SELECT MAX (LIMIT) FROM RASPPOD

3.15 Запрос на выборку записей с условием сортировки

SELECT LIMIT FROM RASPPOD ORDER BY LIMIT ASC

3.16 Вложенный запрос на выборку записей с использованием предиката EXISTS

SELECT TYHET, NFID

FROM RASPPOD WHERE EXISTS

(SELECT * FROM RASPPOD WHERE LIMIT=5000)

Заключение

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

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

1. Р. 50.1.028-2001. Методология функционального моделирования, - М.: Госстандарт России, 2001.

2. Базы данных, модели, разработка, реализация/ Под. Ред. Карповой Т. С. - СПб.:Питер, 2004.

Вендров A.M Проектирование программного обеспечения экономических информационных систем. Учебник - М.: Финансы и статистика, 2002.

Волкова В.Н. Денисов А.А. Основы теории систем и системного анализа. Учеб. для студентов вузов обучающихся по специальности «Системный анализ и управление»- 2-е изд., перераб. и доп. - СПб: Изд-во С - Петерб. ГТУ, 2001.

5. Глушаков С. В., Ломотько Д.В. Базы данных - Харьков Фолио, M: OOO Издательство АСТ, 2002.

6. Годин В. В., Корнеев И.В. Информационное обеспечение управленческой деятельности. Учебник - М: Мастерства, Высшая школа, 2001.

7. Диго С.М., Проектирование баз данных. - М: Финансы и статистика, 1988 .

8. Евдокимов В. В. и др. Экономическая информатика: Учеб для вузов/ Под ред.В.В. Евдокимова - СПб., Питер, 1997.

9. Информатика, Учебник для ВУЗов/ Под ред. Н.В. Макаровой - М: Финансы и статистика, 2003.

10. Черемных С. В. и др. Моделирование и анализ систем IDEF - технологии: Практикум - М: Финансы и статистика, 2003.

Размещено на Allbest.ru

...