ГОСЫ / Proektirovanie_informatsionnykh_sistem_Logunova

5.Основные принципы нотации проектирования потоков данных DFD. Смысловые примитивы. Связи. Декомпозиция.

Нотация DFD как средство моделирования потоков данных

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

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

Всего DFD использует четыре важных элемента:

1.Работы. Работы в DFD обозначают функции или процессы, которые обрабатывают и изменяют информацию. Работы представлены на диаграммах в виде прямоугольников со скругленными углами.

2.Стрелки. Стрелки идут от объекта-источника к объекту-приемнику, обозначая информационные потоки в системе документооборота .

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

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

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

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

2.Передать список всех информационных потоков.

Для DFD также применяется принцип декомпозиции. На нижнем уровне для каждой работы составляется миниспецификация, представляющая собой алгоритм, записанный на специализированном естественном языке. Все миниспецификации соединяются в единую систему. Любая из работ IDEF0 м.б. декомпозирована в DFD.

11

Методология DFD. В этой методологии исследуемый процесс разбивается на подпроцессы и представляется в виде сети, связанной потоками данных. Чисто внешне DFD сходна с IDEF0, но отличается по набору используемых элементов. В их число входят процессы, потоки данных и хранилища. Хранилище позволяет в необходимых случаях определить данные, которые будут сохраняться в памяти между процессами. Диаграммы потоков данных (DFD) являются основным средством моделирования функциональных требований проектируемой системы. С их помощью эти требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. Главная цель таких средств продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами. Формально диаграмма информационных потоков есть направленный граф, нагруженный по дугам и узлам. Диаграмма информационных потоков описывает асинхронный процесс преобразования информации от ее ввода в систему до выдачи потребителю. Использование ограниченного числа символов позволяет нам построить изображение системы, не связывая себя размышлениями о ее возможной реализации.

12

6.Основные принципы нотации проектирования последовательности работ IDEF3. Смысловые примитивы. Связи. Декомпозиция. Перекрёстки.

Нотация IDEF3 как средство моделирования потоков работ

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

фокусируя внимание на течении этих процессов и на отношениях процессов и важных объектов,

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

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

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

Единицы работы (Unit of Work) - основной компонент диаграммы IDEF3 близкий по смыслу к работе IDEF0.

Связи (Links) - Связи, изображаемые стрелками, показывают взаимоотношения работ. В IDEF3 различают три типа связей:

o Связь предшествования (Precedence) - показывает, что прежде чем начнется работаприемник, должна завершиться работа-источник. Обозначается сплошной линией.

o Связь отношения (Relational) - показывает связь между двумя работами или между работой и объектом ссылки. Обозначается пунктирной линией.

o Поток объектов (Object Flow) - показывает участие некоторого объекта в двух или более работах, как, например, если объект производится в ходе выполнения одной работы и потребляется другой работой. Обозначается стрелкой с двумя наконечниками.

o Перекрестки (Junctions) - перекрестки используются в диаграммах IDEF3, чтобы показать ветвления логической схемы моделируемого процесса и альтернативные пути развития процесса могущие возникнуть во время его выполнения. Различают два типа перекрестков: синхронные и асинхронные. Синхронность отображает требования к одновременности протекания процессов. Также перекрестки делятся по виду логич. ф-ции, которую выполняют.

Типы перекрестков

Исключающий ИЛИ:

– запускается (завершается) только одна последующая (предшествующая) работа

И:

 Асинхронный:

– запускаются (завершаются) все последующие (предшествующие) работы

13

 Синхронный

– все последующие (предшествующие) работы запускаются (завершаются) одновременно

ИЛИ:

 Асинхронный:

– запускаются (завершаются) одна или несколько последующих (предшествующих) работ

 Синхронный

– одна или несколько последующих (предшествующих) работ запускаются (завершаются)

одновременно

Примеры неправильных перекрестков

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

1.Каждому перекрестку для слияния должен предшествовать перекресток для разветвления.

2.Перекресток для слияния "И" не может следовать за перекрестком для разветвления типа синхронного или асинхронного "ИЛИ". Действительно, после работы 1 может запускаться только одна работа - 2 или 3, а для запуска работы 4 требуется окончание обеих работ-2 и 3. Такой сценарий не может реализоваться.

Неверное размещение перекрестков. Перекресток для слияния "И" не может следовать за перекрестком для разветвления "ИЛИ"

3. Перекресток для слияния "И" не может следовать за перекрестком для разветвления типа исключающего "ИЛИ".

Неверное размещение перекрестков. Перекресток для слияния "И" не может следовать за перекрестком для разветвления типа исключающего "ИЛИ"

4. Перекресток для слияния типа исключающего "ИЛИ" не может следовать за перекрестком для разветвления типа "И" (рис. 1.4.14). Здесь после завершения работы 1 запускаются обе работы - 2 и 3, а для запуска работы 4 требуется, чтобы завершилась одна и только одна работа - или 2, или 3.

14

Неверное размещение перекрестков. Перекресток для слияния типа исключающего "ИЛИ" не может следовать

5. Перекресток, имеющий одну стрелку на одной стороне, должен иметь более одной стрелки на другой.

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

Предназначение IDEF3

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

В IDEF3 декомпозиция используется для детализации работ.

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

15

7.Основные принципы нотации информационного проектирования IDEF1X. Логическая и физическая модели данных. Смысловые примитивы. Сущности. Атрибуты. Связи.

Нотация IDEF1X как средство построения модели данных

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

IDEF1X

Метод моделирования, который поддерживает графическое описание:

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

физических конструкций данных специфицированных на применение в конкретной СУБД используя трансформацию сущностей в таблицы; атрибуты в свойства и характеристики; связи в таблицы и связи.

Документирование модели. Многие СУБД имеют ограничение на именование объектов (например, ограничение на длину имени таблицы или запрет использования специальных символов - пробела и т. п.). Зачастую разработчики ИС имеют дело с нелокализованными версиями СУБД. Это означает, что объекты базы данных могут называться короткими словами, только латинскими символами и без использования специальных символов (т. е. нельзя назвать таблицу предложением - только одним словом). Кроме того, проектировщики баз данных нередко злоупотребляют "техническими" наименованиями, в результате таблица и колонки получают наименования типа RTD_324 или CUST_A12 и т. д. Полученную в результате структуру могут понять только специалисты (а чаще всего только авторы модели), ее невозможно обсуждать с экспертами предметной области. Разделение модели на логический и физический уровни позволяет решить эту проблему. На физическом уровне объекты базы данных могут называться так, как того требуют ограничения СУБД. На логическом уровне можно этим объектам дать синонимы - имена более понятные неспециалистам, в том числе на кириллице и с использованием специальных символов. Например, таблице CUST_A12 может соответствовать сущность Постоянный клиент. Такое соответствие позволяет лучше задокументировать модель и дает возможность обсуждать структуру данных с экспертами предметной области.

Сущность(Entity) - это некоторый объект, идентифицируемый в рабочей среде пользователя, нечто такое, за чем пользователь хотел бы наблюдать. Сущность (Entity) - реальный либо воображаемый объект, имеющий существенное значение для рассматриваемой предметной области, информация о котором подлежит хранению. Экземпляр сущности (строки) (Entity instance) представляет конкретную сущность,; он описывается значениями атрибутов данной сущности. Сущности одного и того же типа группируются в классы сущностей (Entity classes). Класс сущностей - это совокупность сущностей, которая описывается структурой или форматом сущностей,

Атрибут (поле) - составная часть сущности (свойство сущности), которая описывает отдельную, атомарную смысловую область сущности с определением для нее:

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

типа данных;

назначения;

условий использования.

16

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

Экземпляр атрибута (строки) - это определенная характеристика отдельного элемента множества. Экземпляр атрибута определяется типом характеристики и ее значением, называемым значением атрибута. Атрибуты ассоциируются с конкретными сущностями. Таким образом, экземпляр сущности должен обладать единственным определенным значением для ассоциированного атрибута. Атрибут может быть либо обязательным, либо необязательным. Обязательность означает, что атрибут не может принимать неопределенных значений (null values).

Связь (Relationship) - поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Связь - это ассоциация между сущностями, при которой, как правило, каждый экземпляр одной сущности, называемой родительской сущностью, ассоциирован с произвольным (в том числе нулевым) количеством экземпляров второй сущности, называемой сущностью-потомком, а каждый экземпляр сущности-потомка ассоциирован с одним экземпляром сущности-родителя.

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

Связи отражают взаимоотношения между сущностями.

Существует несколько видов связи:

Идентифицирующая связь соединяет независимую родительскую сущность с зависимой дочерней, причем экземпляр дочерней сущности не существует и не имеет смысла без родителя. Уникальность обеспечивается двумя ключами. При такой связи null-значения запрещены.

Неидентифицирующая связь – проводится между двумя независимыми сущностями. При такой связи null-значения разрешены.

17

8.Принципы нормализации и денормализации модели данных. Аномалии. Основные нормальные формы.

Отношение – двумерная таблица, обладающая набором свойств:

Критерием правильности отношений может служить нормализация.

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

Отношения можно классифицировать по типам аномалий, которые ими ликвидируются. Типы, на которые подразделяются отношения в рамках этой классификации, называются нормальными формами. Нормализация – это процесс анализа отношений.

Первая нормальная форма (1НФ)

Любая таблица, являющаяся отношением, находится в первой нормальной форме. Виды нарушений атомарности:

1. в атрибут помещены разные по смыслу значения 2. присутствует скрытое групповое значение

Вторая нормальная форма (2НФ)

Таблица находится во второй нормальной форме, если она находится в 1НФ и каждый неключевой атрибут зависит от ключа целиком. Вторую нормальную форму имеет смысл рассматривать только с составным ключом.

Третья нормальная форма (3НФ)

Таблица находится в третьей нормальной форме, если она находится в 2НФ и в ней нет транзитивных функциональных зависимостей, т.е. все неключевые атрибуты взаимно независимы.

Нормальная форма Бойса-Кодда (НФБК)

Отношение находится в нормальной форме Бойса-Кодда, если оно находится в 3НФ и каждый детерминант является ключом-кандидатом. Если атрибут В функционально зависит от атрибута А, то атрибут А называют детерминантом, а атрибут В – зависимой частью. Если в отношении существует определенное количество атрибутов (один или более), однозначно определяющее каждую строку, то такой набор атрибутов является ключом-кандидатом в Primary key. Причем, по выбору, любой из них станет Primary key, остальные – Alternative key.

Четвертая нормальная форма (4НФ)

Отношение находится в четвертой нормальной форме, если оно находится в НФБК и в нем нет многозначных зависимостей.

Доменно-ключевая нормальная форма (ДКНФ)

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

В контексте ДКНФ под доменом подразумевается только физическое описание допустимых значений атрибута

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

одну тему.

18