19273

Средства структурного анализа. Метод функционального моделирования IDEF0. Метод моделирования процессов IDEF3

Лекция

Информатика, кибернетика и программирование

Лекция 5. Средства структурного анализа. Метод функционального моделирования IDEF0. Метод моделирования процессов IDEF3. Моделирование потоков данных Модели сущностьсвязь ERмодели. Графические нотации ERмодели 5.1. Метод функционального моделирования IDEF0 Метод IDEF0 с...

Русский

2013-07-11

255.24 KB

29 чел.

Лекция 5.

Средства структурного анализа. Метод функционального моделирования IDEF0. Метод моделирования процессов IDEF3. Моделирование потоков данных Модели сущность-связь (ER-модели). Графические нотации ER-модели

5.1. Метод функционального моделирования IDEF0

Метод IDEF0 считается классическим методом процессного подхода к управлению.

Метод IDEF0 представляет собой совокупность правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель IDEF0 отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Метод разработан Дугласом Россом (SoftTech, Inc.) в 1969 г. для моделирования искусственных систем средней сложности.

Состав функциональной модели

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

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

Правила построения моделей IDEF0

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

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

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

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

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

В IDEF0 требуются только пять типов взаимосвязей между блоками для описания их отношений (слайд 4): Управление, Вход, Управленческая Обратная Связь, Входная Обратная Связь, Выход - Исполнитель.

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

На IDEF0-диаграммах не указаны явно ни последовательность, ни время.

Стратегии декомпозиции

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

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

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

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

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

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

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

  •  полнота описания бизнес-процесса (управление, информационные и материальные потоки, обратные связи);
  •  комплексность декомпозиции;
  •  возможность агрегирования и детализации потоков данных и информации (разделение и слияние дуг);
  •  наличие жестких требований, обеспечивающих получение моделей стандартного вида;
  •  простота документирования процессов;
  •  соответствие подхода к описанию процессов стандарту ISO 9000:2000.

В то же время метод IDEF0 обладает рядом недостатков:

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

5.2. Метод моделирования процессов IDEF3

Метод моделирования IDEF3 был разработан в конце 1980-х годов для закрытого проекта ВВС США. Этот метод предназначен для моделирования последовательности выполнения действий и взаимозависимости между ними в рамках процессов. Хотя IDEF3 и не достиг статуса федерального стандарта США, он приобрел широкое распространение среди системных аналитиков как дополнение к методу функционального моделирования IDEF0 (модели IDEF3 могут использоваться для детализации функциональных блоков IDEF0, не имеющих диаграмм декомпозиции).

Существуют два типа диаграмм в стандарте IDEF3, представляющие описание одного и того же сценария технологического процесса в разных ракурсах. Диаграммы, относящиеся к первому типу называются диаграммами Описания Последовательности Этапов Процесса (Process Flow Description Diagrams, PFDD), а ко второму - диаграммами Состояния Объекта в и его Трансформаций Процессе (Object State Transition Network, OSTN).

Process Flow Description Diagrams

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

Основной единицей модели IDEF3 является диаграмма. Другой важный компонент модели —действие, или в терминах IDEF3 "единица работы" (Unit of Work). Каждому из действий присваивается уникальный идентификационный номер. Этот номер не используется вновь даже в том случае, если в процессе построения модели действие удаляется. В диаграммах IDEF3 номер действия обычно предваряется номером его родителя.

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

Перекрестки в PFDD

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

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

Соединения бывают синхронными и асинхронными (слайд 6).

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

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

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

Примеры соединений приведены на слайде 7.

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

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

Object State Transition Network. Состав модели (слайд 8)

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

Ключевыми понятиями OSTN диаграммы являются Состояния объекта  и Изменение состояния. Состояния объекта отображаются окружностями. Для изображения последовательностей переходов объектов из одного вида в другой и изображения перехода одного и того же объекта из одного состояния в другое в OSTN диаграммах используются связи переходов (Transition Links). Связи переходов могут быть слабыми (Weak Transition Link) и сильными (Strong Transition Link).

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

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

Узлы или перекрестки переходов в OSTN

Узлы переходов (Аналогично перекресткам в PFDD), изображаются кружками, внутри которых содержится условное обозначение логической функции, реализуемой узлом. Как и в PFDD диаграммах узлы могут быть узлами слияния и разветвления. В качестве логических функций могут использоваться И (&), ИЛИ (O) и ИСКЛЮЧАЮЩЕЕ ИЛИ (X).

Ссылки в IDEF3

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

Ссылки могут использоваться:

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

Использование ссылки «Вызвать и продолжить» (Call and Continue Referent) указывает, что элемент, указанный в ссылке, должен быть активизирован до завершения выполнения действия модулем, к которому относится ссылка. Использование ссылки «Вызвать и ждать» (Call and Wait Referent), указывает, что элемент, указанный в ссылке, должен начать и закончить выполнение  действия до завершения действия модулем, к которому относится ссылка.

Каждый из представленных видов ссылки может быть типа «UOB», «SCENARIO», «TS» или «GO TO». Cсылки типа UOB ссылаются на функциональный модуль «UOB», типа «SCENARIO» ссылаются на соответствующий сценарий, типа «TS» (Transition Schematic) –на соответствующую схему, типа «GO TO» - на любой из структурных элементов IDEF3: функциональный модуль, сценарий или узел. Cсылка типа «GO TO» используется только в диаграммах потоковых процессов PFDD.

В основном поле символа ссылки указывается её тип и через дробь уникальное наименование блока, сценария, схемы или функции узла. В поле «Locator» указывается уникальный номер идентификатор элемента, указанного в ссылке.

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

5.3. Моделирование потоков данных

Диаграммы потоков данных (Data Flow Diagrams —DFD) представляют собой иерархию функциональных процессов, связанных потоками данных. Цель такого представления —продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.

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

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

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

Состав диаграмм потоков данных

Основными компонентами диаграмм потоков данных являются (слайд 9):

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

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

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

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

Поток данных определяет информацию, передаваемую через некоторое соединение от источника к приемнику.

Рекомендации по построению иерархии диаграмм потоков данных

  •  Размещать на каждой диаграмме от 3 до 6-7 процессов (аналогично IDEF0).
  •  Не загромождать диаграммы несущественными на данном уровне деталями.
  •  Декомпозицию потоков данных осуществлять параллельно с декомпозицией процессов. Эти две работы должны выполняться одновременно, а не одна после завершения другой.
  •  Выбирать ясные, отражающие суть дела имена процессов и потоков, при этом стараться не использовать аббревиатуры.

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

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

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

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

Решение о завершении детализации процесса и использовании спецификации принимается аналитиком исходя из следующих критериев:

  •  наличия у процесса относительно небольшого количества входных и выходных потоков данных (2-3 потока);
  •  возможности описания преобразования данных процессов в виде последовательного алгоритма;
  •  выполнения процессом единственной логической функции преобразования входной информации в выходную;
  •  возможности описания логики процесса при помощи спецификации небольшого объема (не более 20-30 строк).

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

Декомпозиция данных и соответствующие расширения диаграмм потоков данных

Для обеспечения декомпозиции данных и некоторых других сервисных возможностей к DFD добавляются следующие типы объектов (слайд 10):

1) ГРУППОВОЙ УЗЕЛ. Предназначен для расщепления и объединения потоков. В некоторых случаях может отсутствовать (т.е. фактически вырождаться в точку слияния/расщепления потоков на диаграмме).

  1.  УЗЕЛ-ПРЕДОК. Позволяет увязывать входящие и выходящие потоки между детализируемым процессом и детализирующей DFD.
  2.  НЕИСПОЛЬЗУЕМЫЙ УЗЕЛ. Применяется в ситуации, когда декомпозиция данных производится в групповом узле, при этом требуются не все элементы входящего в узел потока.
  3.  УЗЕЛ ИЗМЕНЕНИЯ ИМЕНИ. Позволяет неоднозначно именовать потоки, при этом их содержимое эквивалентно. Например, если при проектировании разных частей системы один и тот же фрагмент данных получил различные имена, то эквивалентность соответствующих потоков данных обеспечивается узлом изменения имени. При этом один из потоков данных является входным для данного узла, а другой - выходным.

5) Текст в свободном формате в любом месте диаграммы.

5.4. Модели сущность-связь (ER-модели)

Наиболее распространенным средством моделирования предметной области систем в структурном анализе и проектировании  является модель «сущность-связь» (Entity-Relationship Model - ERМ), впервые предложенная Питером Пин-Шэн Ченом в 1976 г.

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

Сущности

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

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

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

И зависимые, и независимые сущности можно разделить на несколько типов (слайд 11):

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

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

Соглашения об именовании сущностей.

  •  Имя сущности должно быть достаточно описательным. Используйте имена из одного слова, только когда они являются названием широко распространенных концепций. Подумайте об использовании словосочетаний на основе существительных.
  •  Имя сущности должно быть существительным или словосочетанием на основе существительного в единственном числе. Используйте ПЕРСОНА вместо ПЕРСОНЫ или ЛЮДИ, и КОНТЕЙНЕР - вместо КОНТЕЙНЕРЫ.
  •  Имя сущности должно быть уникальным. Использование одинаковых имен для сущностей, содержащих различные данные, или разных имен для сущностей, содержащих одинаковые данные, будет без необходимости вводить в заблуждение разработчиков и конечных пользователей.
  •  Имя сущности должно указывать на данные, которые будут храниться в каждом из экземпляров.
  •  Имя сущности не должно содержать специальных символов (таких как !, @, #, $, %, &, * и тому подобных) или указывать на принадлежность (МОРОЖЕНОЕ ПЕРСОНЫ).
  •  Имя сущности не должно содержать акронимов или аббревиатур, если только они не являются частью принятых соглашений об именовании.

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

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

ТАБЛИЦА 5.3. Описания сущностей с пояснениями

Хорошее описание

Неудачное описание

Пояснение

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

Клиент или сотрудник.

Хорошее описание включает определение сущности и ее значение для корпорации.

  

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

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

  

Информация о клиентах
и сотрудниках.

Клиент и сотрудник являются примерами ролей, в которых может выступать ПЕРСОНА. Использование одних только примеров не объясняет, что сущность собой представляет и почему она важна для корпорации.

  

Сущность содержит символы и числовые данные, извлеченные
из POS (Point Of Sale - торговый терминал), хранящиеся с использованием стандартного сжатия и упакованных десятичных чисел.

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

Распространенные ошибки при моделировании сущностей и выборе ключей

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

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

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

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

. Нельзя использовать аббревиатуры или акронимы в качестве части имени.

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

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

. Не нужно перефразировать имя сущности и не использовать имя сущности в ее описании.

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

Атрибуты

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

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

Корректная модель атрибута обладает следующими признаками:

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

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

Атрибут должен присутствовать в er-модели в единственном экземпляре. "Один факт в одном месте" (Дейт, 1986).

Природа атрибутов может быть различной. (слайд 12)

Атрибут может быть множественным или единичным –т.е. атрибут, задающий свойство, может одновременно иметь несколько значений или, соответственно, только одно.

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

Атрибут может быть базовым или производным.

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

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

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

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

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

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

  •  Кандидатом в ключи является атрибут или группа атрибутов, идентифицирующих конкретный экземпляр сущности. Кандидат в ключи представляет механизм определения потенциальных первичных ключей для идентификации конкретных экземпляров сущности. Кандидат в ключи, который не выбран в качестве первичного ключа, еще называют альтернативным ключом. Альтернативный ключ - это атрибут или группа атрибутов, которые могут быть использованы при индексировании.
  •  Составной ключ. Для составных ключей каждая составляющая ключа должна иметь значение для каждого экземпляра. Ни одна часть ключа не должна быть неопределенной (NULL). Все части ключа являются обязательными и не могут быть опущены.
  •  Искусственные первичные ключи - это атрибуты, созданные с единственной целью идентификации конкретных экземпляров сущности. Искусственный первичный ключ часто формируется простой последовательной нумерацией каждого из экземпляров сущности. Искусственные первичные ключи, гарантированно обладают особенностями хороших первичных ключей.
  •  Внешние ключи. Когда первичный ключ одной сущности мигрирует в другую таблицу, он называется внешним ключом. Внешние ключи "связывают" сущности, представляя отношения между ними. Внешние ключи могут быть как идентифицирующими, так и неидентифицирующими. Идентифицирующие внешние ключи становятся частью первичного ключа в той сущности, в которую они мигрировали. Неидентифицирующие внешние ключи становятся не ключевыми атрибутами.

Распространенными ошибками, связанными с первичным ключом, являются:

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

2. Требуемое значение/неопределенность: первичный ключ не имеет значения для некоторых из экземпляров.

Хороший первичный ключ будет обладать следующими признаками:

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

Соглашения об именование атрибутов.

  •  Имя атрибута должно быть достаточно описательным. Желательно использовать словосочетания на основе существительных в форме объект/ модификатор/ класс. Форма объект/модификатор/класс - широко распространенное в отрасли соглашение об именовании атрибутов. Это соглашение побуждает использовать имена атрибутов, состоящие из трех частей. Часть объект иногда называют субъектом или основным словом. В качестве объекта обычно используется имя сущности.
  •  По возможности имя атрибута должно включать имя сущности. Используйте "Имя для персоны" вместо просто "Имя".
  •  Имя атрибута должно указывать на значения конкретных экземпляров атрибута. Использование одинаковых имен для атрибутов, содержащих различные данные, или разных имен для атрибутов, содержащих одинаковые данные, будет без необходимости вводить в заблуждение разработчиков и конечных пользователей.
  •  Имя атрибута должно использовать язык бизнеса вместо языка технических описаний.
  •  Имя атрибута не должно содержать специальных символов (таких как !, @, #, $, %, &, * и тому подобных) или указывать на принадлежность (Имя, принадлежащее персоне).
  •  Имя атрибута не должно содержать акронимов или аббревиатур, если только они не являются частью принятых соглашений именования.

ТАБЛИЦА 5.4. Имена атрибутов с пояснениями

Хорошее Имя

Неудачное имя

Пояснение

Person First Name
(
Имя персоны)

Name
(Имя)

Name (Имя) - название класса и нуждается в обозначении объекта Person (персона) и в модификаторе First (первое).

Ice Cream Sales Quantity
(Объем продаж мороженого)

The Quantity of Sales
(
Объем продаж)

Quantity (Количество) - название класса и должно быть на последнем месте (в английском варианте имени атрибута). "The" и "of" не привносят дополнительного смысла.

Item Cost Amount
(Величина стоимости позиции)

Cost of Item
(Стоимость позиции)

"of" не привносит дополнительного смысла. Название класса "Amount" (величина) указывает пользователю, что должно быть в атрибуте.

Product Identifier
(Идентификатор продукта)

Product Identifiers
(Идентификаторы продуктов)

"Identifiers" (Идентификаторы) - множественное число. Имя атрибута должно быть существительным в единственном числе.

Point of Sale Location Code
(Код местоположения точки продаж)

POS Code
(Код POS)

"POS" - аббревиатура. Использованное название класса "Code" (код) нуждается в модификаторе.

Person Birth Date
(Дата рождения персоны)

Birthday
(День рождения)

Birthday (День рождения) не содержит названия класса Date (Дата). Включение модификатора и имени объекта проясняет смысл имени атрибута.

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

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

Таблица 5.5. Имена и описания атрибутов с пояснениями.

Имя атрибута 

Хорошее описание 

Неудачное описание 

Пояснение 

Person First Name

(Имя персоны)

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

Поле с длиной в 40 символов.

Не используется язык бизнеса. Применены технические термины.

Ice Cream Sales Quantity

(Объем продаж мороженого)

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

Объем продаж.

Не добавляет нового смысла, а просто перефразирует имя атрибута в расплывчатых терминах.

Item Cost Amount

(Величина стоимости позиции)

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

Шестизначное десятичное число с двумя знаками после запятой.

Слишком техническое описание. Почти ничего не значит для пользователей элемента данных.

Product Identifier

(Идентификатор продукта)

Искусственный уникальный числовой идентификатор для конкретного продукта.

Идентификаторы продуктов.

Простая перефразировка имени атрибута.

Point of Sale Location Code

(Код местоположения точки продаж)

Уникальный код, идентифицирующий географическое положение точки продаж.

Код POS.

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

Person Birth Date

(Дата рождения персоны)

Дата рождения персоны.

День рождения персоны.

В описании опущено название класса “дата”.

Распространенные ошибки при работе с атрибутами

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

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

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

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

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

6. Не желательно использовать описаний атрибутов, заимствованных только из словаря. Не нужно использовать простое перефразирование имени атрибута. Не нужно использовать имена атрибута в его описании.

Отношения

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

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

Отношение обладает следующими свойствами (слайд 13):

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

Направленность отношения указывает на исходную сущность в отношении. Сущность, из которой отношение исходит, называется родительской сущностью. Сущность, в которой отношение заканчивается, называется подчиненной сущностью.

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

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

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

Типизирующими являются отношения между родительской и одной или более подчиненными сущностями.

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

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

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

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

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

  •  Один-к-одному (1:1) - один и только один экземпляр сущности связан с одним и только одним экземпляром другой сущности.
  •  Один-ко-многим (1:N) - один и только один экземпляр родительской сущности связан со многими экземплярами подчиненной сущности.
  •  Многие-ко-многим (M:N) - много экземпляров одной сущности связаны с многими экземплярами другой сущности (также называется неспецифическим отношением).

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

Распространенные ошибки, связанные с отношениями

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

. Как показывает опыт, реальные отношения один-к-одному очень редки и еще реже они реализуются на практике.

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

5.5. Графические нотации ER-модели

В ER-моделях наибольшее распространение получили следующие графические нотации: Чена (Chen), IDEF1x, Мартина (Martin), Баркера (Barker). Все перечисленные нотации оперируют понятиями: «сущность», «связь», «атрибут сущности». На слайдах 14 и 15. представлены графические элементы этих нотаций, а на слайде 16 –внешний вид диаграмм в этих нотациях.


 

А также другие работы, которые могут Вас заинтересовать

74540. HTTP. HyperText Transfer Protocol - протокол передачи гипертекста 17.41 KB
  HyperText Trnsfer Protocol протокол передачи гипертекста протокол прикладного уровня передачи данных. HTTP используется также в качестве транспорта для других протоколов прикладного уровня таких как SOP XMLRPCWebDV. Особенностью протокола HTTP является возможность указать в запросе и ответе способ представления одного и того же ресурса по различным параметрам: формату кодировке языку и т. Именно благодаря возможности указания способа кодирования сообщения клиент и сервер могут обмениваться двоичными данными хотя данный...
74541. WWW. World Wide Web 14.77 KB
  Годом рождения Всемирной паутины считается 1989 год. Именно в этом году Тим БернерсЛи предложил общий гипертекстовый проект который получил впоследствии название Всемирной паутины. Создатель паутины Тим БернесЛи работая в лаборатории физики элементарных частиц европейского центра ядерных исследований CERN В Женеве Швейцария совместно с партнером Робертом Кайо занимались проблемами применения идей гипертекста для построения информационной среды которая упростила бы обмен информацией между физиками. Итогом данной работы явился...
74546. Программирование. Языки программирования низкого и высокого уровней 25.55 KB
  Языки программирования низкого уровня Первым компьютерам приходилось программировать двоичными машинными кодами. Для упрощения этой задачи стали появляться языки программирования низкого уровня которые позволяли задавать машинные команды в более понятном для человека виде. Примером языка низкого уровня является ассемблер. Языки низкого уровня ориентированы на конкретный тип процессора и учитывают его особенности поэтому для переноса программы на ассемблере на другую аппаратную платформу ее нужно почти полностью переписать.
74547. Unix 16.31 KB
  Именно в 1969 году была создана первая Unix система компанией TT и торговая марка Unix по праву теперь принадлежит этой компании. Unix – это многопользовательская многотерминальная операционная система которая в силе выполнять множество задач как под Вашим чутким руководством так и без. Существует целое семейство так называемых Unix подобных систем которые в большинстве случаев могут быть совместимы друг с другом на уровне исходных текстов программ. Все пользователи операционной системы Linux а именно потому что имеем возможность...
74548. Linux 19.3 KB
  История Linux началась в 1991 году когда студент Хельсинского университета Линус Торвальдс выпустил первый релиз этой операционной системы. Именно идея расширить возможности этой операционной системы и послужила основным мотивом разработки Linux. Хотя идея новой операционной системы и первые ее релизы почти полностью принадлежат одному человеку дальнейшее развитие Linux происходило и происходит благодаря участию в этом проекте десятков тысяч программистов всего мира. Однако эта команда разработчиков Linux не имеет ни штабквартиры ни...