Проектирование системы. Проектирование систем. Проектирование информационных систем ( на примере методов структурного системного анализа)
 Скачать 1.64 Mb.
|
|
Проектирование модели данных Существует два типа проектирования модели данных: прямое и обрат- ное. 210 Прямое проектирование (Forward Engineering) – процесс генерации физической схемы БД из логической модели, состоящий из следующих этапов: 1) разработка логической модели; 2) выбор СУБД и автоматическое создание физической модели на основе логической; 3) генерация системного каталога СУБД или соответствующего SQL- скрипта на основе физической модели. ERwin при генерации физической схемы включает триггеры ссылочной целостности, хранимые процедуры, индексы, ограничения и другие возможно- сти, доступные при определении таблиц в выбранной СУБД. Прямое проектирование обеспечивает масштабируемость – создав одну логическую модель данных, можно сгенерировать физические модели под лю- бые СУБД. Обратное проектирование (Reverse Engineering)– процесс генерации логической модели из физической БД. Обратное проектирование решает задачу позволяет конвертировать БД из одной СУБД в другую. После создания логи- ческой модели БД путем обратного проектирования можно переключиться на другой сервер и произвести прямое проектирование. 1) по содержимому системного каталога или SQL-скрипту воссоздается ло- гическая модель данных; 2) на основе полученной логической модели данных генерируется физиче- ская модель для другой СУБД; 3) создается системный каталог этой СУБД. Обратное проектирование решает задачу по переносу структуры данных с одного сервера на другой. Создание логической модели данных Информационное (концептуальное) моделирование 211 Цель информационного моделирования – обеспечение разработчиков ИС концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей данных, которые относительно легко могут быть отображе- ны в любую систему баз данных. Концептуальная схема представляет собой карту понятий и отношений между ними, т.е. семантику организации (а не дизайн базы данных) и может существовать на различных уровнях абстракции. Если функциональная схема представляет собой определенную точку зрения на мир и не является гибкой ( меняется мир – должна поменяться схема), то концептуальная схема объединя- ет в себе все точки зрения и дает более абстрактное представление об объекте, описывая фундаментальные понятия, лишь с экземплярами которых человек имеет дело. В инженерии ПО, моделирование «сущность-связь» (Entity-Relationship Model, ERM) – это пример абстрактного и концептуального представление дан- ных; это метод моделирования БД, используемый для создания концептуальной схемы или семантической модели данных системы (часто реляционной БД), а также требований к системе в форме «сверху-вниз». Диаграммы, созданные та- ким способом, называются диаграммами «сущность-связь» (entity-relationship diagrams ) или ER-диаграммами, или кратко ERD. ERD является наиболее распространенным средством документирования данных. С их помощью определяются важные для предметной области объекты ( сущности), их свойства (атрибуты) и отношения друг с другом (связи). ERD непосредственно используются для проектирования реляционных баз данных. На уровне физической модели сущности соответствует таблица; экземпляру сущности – строка в таблице; атрибуту – колонка таблицы. Различают три уровня логической модели, отличающихся по глубине представления информации о данных: диаграмма сущность-связь, модель дан- ных, основанная на ключах и полная атрибутивная модель. 212 1. Диаграмма сущность-связь (Entity Relationship Diagram, ERD) представля- ет собой модель данных верхнего уровня. Она включает сущности и взаимо- связи, отражающие основные правила предметной области. Такая диаграмма не слишком детализирована, в нее включаются основные сущности и связи между ними, которые удовлетворяют основным требованиям, предъявляе- мым к ИС. Диаграмма сущность-связь может включать связи «многие-ко- многим» и не включать описание ключей. Как правило, ERD используется для презентаций и обсуждения структуры данных с экспертами предметной области. 2. Модель данных, основанная на ключах (Key Based model, KB) – более по- дробное представление данных. Она включает описание всех сущностей и первичных ключей и предназначена для представления структуры данных и ключей, которые соответствуют предметной области. 3. Полная атрибутивная модель (Fully Attributed model, FA) – наиболее де- тальное представление структуры данных: представляет данные в третьей нормальной форме и включает все сущности, атрибуты и связи. Существует несколько соглашений для ERD. Классическая нотация свя- зана, главным образом, с концептуальным моделированием. При этом суще- ствует ряд нотаций, применяемых для логического и физического проектирова- ния БД, например IDEF1X. Диаграмма структуры данных DSD(data structure diagram) – это модель данных для описания концептуальных моделей данных с помощью графических нотаций, которые документируют сущности и связи между ними, а также условия по ограничению связей (и the constraints that binds them). Диаграммы структуры данных DSD являются расширением E-R-модели (entity-relationship model, E-R model). Case- метод Баркера Нотация ERD была впервые введена П. Ченом (Chen) и получила даль- нейшее развитие в работах Баркера. 213 Первый этап моделирования – выделение сущностей. Сущность (Entity) – реальный либо воображаемый объект, имеющий существенное значение для рассматриваемой предметной области, информация о котором подлежит хране- нию. Графическое изображение сущности показано на рис. 4.17. Рис. 4.17. Графическое изображение сущности Следующим шагом моделирования является идентификация связей. Изображение связей, их степени и обязательности показано на рис. 4.18. Рис. 4.18. Графическое изображение связей Последним шагом моделирования является идентификация атрибутов. Атрибут – любая характеристика сущности, значимая для рассматриваемой предметной области и предназначенная для квалификации, идентификации, классификации, количественной характеристики или выражения состояния сущности. Экземпляр атрибута – это определенная характеристика отдельно- го элемента множества. Экземпляр атрибута определяется типом характеристи- ки и ее значением, называемым значением атрибута. В ER-модели атрибуты ас- социируются с конкретными сущностями. Таким образом, экземпляр сущности должен обладать единственным определенным значением для ассоциированно- го атрибута. Атрибут может быть либо обязательным, либо необязательным (рис. 4.19). Обязательность означает, что атрибут не может принимать неопреде- ленных значений (null values). Рис. 4.19. Обязательные и необязательные атрибуты 214 Атрибут может быть либо описательным (т.е. обычным дескриптором сущно- сти), либо входить в состав уникального идентификатора (первичного ключа). Уникальный идентификатор – это атрибут или совокупность атрибутов и/или связей, предназначенная для уникальной идентификации каждого экземпляра данного типа сущности. В случае полной идентификации каждый экземпляр данного типа сущности полностью идентифицируется своими собственными ключевыми атрибутами, в противном случае в его идентификации участвуют также атрибуты другой сущности-родителя (рис. 4.20). Рис. 4.20. Идентификация атрибутов Каждый атрибут идентифицируется уникальным именем, выражаемым грамматическим оборотом существительного, описывающим представляемую атрибутом характеристику. Атрибуты изображаются в виде списка имен внутри блока ассоциированной сущности, причем каждый атрибут занимает отдельную строку. Атрибуты, определяющие первичный ключ, размещаются наверху списка и выделяются знаком «#». Каждая сущность должна обладать хотя бы одним возможным ключом. Возможный ключ сущности – это один или несколько атрибутов, чьи значе- ния однозначно определяют каждый экземпляр сущности. При существовании нескольких возможных ключей один из них обозначается в качестве первично- го ключа, а остальные – как альтернативные ключи. Помимо перечисленных основных конструкций модель данных может содержать ряд дополнительных. 215 Подтипы и супертипы: одна сущность является обобщающим понятием для группы подобных сущностей (рис. 4.21). Рис. 4.21. Подтипы и супертипы Взаимно исключающие связи: каждый экземпляр сущности участвует только в одной связи из группы взаимно исключающих связей (рис. 4.22). Рис. 4.22. Взаимно исключающие связи Рекурсивная связь: сущность может быть связана сама с собой (рис. 4.23). Рис. 4.23. Рекурсивная связь Неперемещаемые (non-transferrable) связи: экземпляр сущности не может быть перенесен из одного экземпляра связи в другой (рис. 4.24). Рис. 4.24. Неперемещаемая связь 216 Методология IDEF1X Метод IDEF1, разработанный Т.Рэмей (T.Ramey), также основан на под- ходе П.Чена и позволяет построить модель данных, эквивалентную реляцион- ной модели в третьей нормальной форме. В настоящее время на основе совер- шенствования методологии IDEF1 создана ее новая версия – методология IDEF1X. IDEF1X разработана с учетом таких требований, как простота изуче- ния и возможность автоматизации. IDEF1X-диаграммы используются рядом распространенных CASE-средств (в частности, ERwin, Design/IDEF). Сущность в методологии IDEF1X является независимой от идентифи- каторов или просто независимой, если каждый экземпляр сущности может быть однозначно идентифицирован без определения его отношений с другими сущностями. Сущность называется зависимой от идентификаторов или про- сто зависимой, если однозначная идентификация экземпляра сущности зависит от его отношения к другой сущности (рис. 4.25 ). Рис. 4.25. Независимые и зависимые сущности Каждой сущности присваивается уникальное имя и номер, разделяемые косой чертой "/" и помещаемые над блоком. Связь является логическим соотношением между сущностями. Каждая связь должна именоваться глаголом или глагольной фразой (рис. 4.26. ). 217 Рис. 4.26. Связь Связь может дополнительно определяться с помощью указания степени или мощности (количества экземпляров сущности-потомка, которое может су- ществовать для каждого экземпляра сущности-родителя). В IDEF1X могут быть выражены следующие мощности связей: • каждый экземпляр сущности-родителя может иметь ноль, один или более связанных с ним экземпляров сущности-потомка; • каждый экземпляр сущности-родителя должен иметь не менее одного связанного с ним экземпляра сущности-потомка; • каждый экземпляр сущности-родителя должен иметь не более одного связанного с ним экземпляра сущности-потомка; • каждый экземпляр сущности-родителя связан с некоторым фиксирован- ным числом экземпляров сущности-потомка. Если экземпляр сущности-потомка однозначно определяется своей свя- зью с сущностью-родителем, то связь называется идентифицирующей, в про- тивном случае – неидентифицирующей. Связь изображается линией, проводимой между сущностью-родителем и сущностью-потомком с точкой на конце линии у сущности-потомка. Мощность связи обозначается как показано на рис. 4.27 (мощность по умолчанию – N). Рис. 4.27. Мощность связи 218 Идентифицирующая связь между сущностью-родителем и сущностью- потомком изображается сплошной линией (рис. 4.28. ). Рис. 4.28. Идентифицирующая связь Сущность-потомок в идентифицирующей связи является зависимой от идентификатора сущностью. Сущность-родитель в идентифицирующей связи может быть как независимой, так и зависимой от идентификатора сущностью (это определяется ее связями с другими сущностями). Пунктирная линия изображает неидентифицирующую связь (рис. 4.29 ). Сущность-потомок в неидентифицирующей связи будет независимой от иден- тификатора, если она не является также сущностью-потомком в какой-либо идентифицирующей связи. Рис. 4.29. Неидентифицирующая связь 219 Атрибуты изображаются в виде списка имен внутри блока сущности. Атрибуты, определяющие первичный ключ, размещаются наверху списка и от- деляются от других атрибутов горизонтальной чертой (рис. 4.30). Рис. 4.30. Атрибуты Сущности могут иметь также внешние ключи (Foreign Key), которые мо- гут использоваться в качестве части или целого первичного ключа или неклю- чевого атрибута. Внешний ключ изображается с помощью помещения внутрь блока сущности имен атрибутов, после которых следуют буквы FK в скобках (рис. 4.31). Рис. 4.31. Примеры внешних ключей Когда рисуется идентифицирующая связь, ERwin автоматически преобра- зует дочернюю сущность в зависимую. Зависимая сущность изображается пря- моугольником со скругленными углами (рис. 4.32). Рис. 4.32. Изображение зависимой сущности 220 Экземпляр зависимой сущности определяется только через отношение к родительской сущности. При установлении идентифицирующей связи атрибу- ты первичного ключа родительской сущности автоматически переносятся в со- став первичного ключа дочерней сущности. Эта операция дополнения атрибу- тов дочерней сущности при создании связи называется миграцией атрибутов. В дочерней сущности новые атрибуты помечаются как внешний ключ – (FK). В дальнейшем, при генерации схемы БД, атрибуты первичного ключа по- лучат признак NOT NULL, что означает невозможность внесения записи в таб- лицу заказов без информации о номере клиента. При установлении неидентифицирующей связи дочерняя сущность оста- ется независимой, а атрибуты первичного ключа родительской сущности ми- грируют в состав неключевых компонентов родительской сущности. Неиден- тифицирующая связь (рис. 4.33) служит для связывания независимых сущно- стей. Рис. 4.33 Неидентифицирующая связь Связь многие-ко-многим возможна только на уровне логической модели данных. Такая связь обозначается сплошной линией с двумя точками на концах (рис. 4.34). Рис. 4.34. Связь «многие-ко-многим» 221 Связь многие-ко-многим должна именоваться двумя фразами – в обе сто- роны. Это облегчает чтение диаграммы. При переходе к физическому уровню ERwin автоматически преобразует связь многие-ко-многим, добавляя новую таблицу и устанавливая две новые связи один-ко-многим от старых к новой таблице. При этом имя новой таблице автоматически присваивается как «Имя1_Имя2». Типы сущностей и иерархия наследования Как уже было сказано, связи определяют, является ли сущность незави- симой или зависимой. Различают несколько типов зависимых сущностей: • характеристическая – зависимая дочерняя сущность, которая связана только с одной родительской и по смыслу хранит информацию о характе- ристиках родительской сущности. • ассоциативная – сущность, связанная с несколькими родительскими сущностями. Такая сущность содержит информацию о связях сущностей. • именующая – частный случай ассоциативной сущности, не имеющей соб- ственных атрибутов (только атрибуты родительских сущностей, мигри- ровавших в качестве внешнего ключа). • категориальная – дочерняя сущность в иерархии наследования. Иерархия наследования (или иерархия категорий) представляет собой особый тип объединения сущностей, которые разделяют общие характеристи- ки. Обычно иерархию наследования создают, когда несколько сущностей име- ют общие по смыслу атрибуты, либо когда сущности имеют общие по смыслу связи, либо когда это диктуется бизнес-правилами. Для каждой категории можно указать дискриминатор – атрибут родово- го предка, который показывает, как отличить одну категориальную сущность от другой. Иерархии категорий делятся на два типа – полные и неполные. В полной категории одному экземпляру родового предка обязательно соответствует эк- 222 земпляр в каком-либо потомке. Если категория еще не выстроена полностью и в родовом предке могут существовать экземпляры, которые не имеют соответ- ствующих экземпляров в потомках, то такая категория будет неполной. Полная категория помечается кружком с двумя горизонтальными чертами, неполная – кружком с одной чертой. Возможна комбинация полной и неполной категорий (рис. 4.35). Рис. 4.35. Комбинация полной и неполной категорий Моделирование потоков данных Методологию моделирования потоков данных (Data Flow Modeling) используют при анализе ИС – проектируемых или реально существующих. По- лучаемая в результате модель потоков данных DFDs (Data-flow diagrams) явля- ется графическим представлением «потоков данных» через ИС, а также одним из трех основных ракурсов методологии SSADM. В соответствии с методоло- гией DFD модель системы представляется в виде иерархии диаграмм потоков данных (ДПД, DFD), описывающих асинхронный процесс преобразования ин- формации от ее ввода в систему до выдачи пользователю. Основные объекты нотации: • работы (Activities) – отображают процессы обработки и изменения ин- формации; • стрелки (Arrows) – отображают информационные потоки; 223 • хранилища (накопители) данных (Data Store) – отображают данные, к ко- торым осуществляется доступ, эти данные используются, создаются или изменяются работами; • внешниесущности (External References) – отображают объекты, с кото- рыми происходит взаимодействие. Работы (процессы) представляют собой функции системы по преобразо- ванию входных потоков данных в выходные в соответствии с определенным алгоритмом. Работы DFD соответствуют процессам IDEF0. Так же как IDEF0, DFD отображает входы и выходы процессов, но не показывают стрелки управления и механизма. Физически процесс может быть реализован различными способами: это может быть подразделение организации (отдел), выполняющее обработку входных документов и выпуск отчетов, программа, аппаратно реализованное логическое устройство и т.д. Процесс на диаграмме потоков данных изображается прямоугольниками со скругленными углами, как показано на рис. 4.36. Рис. 4.36. Процесс Номер процесса служит для его идентификации. Каждый процесс имеет уникальный номер для ссылок на него внутри диаграммы, который может ис- пользоваться совместно с номером диаграммы для получения уникального ин- декса процесса во всей модели. В поле имени вводится наименование процесса в виде предложения с ак- тивным недвусмысленным глаголом в неопределенной форме (вычислить, рас- считать, проверить, определить, создать, получить), за которым следуют суще- ствительные в винительном падеже, обозначающие объект преобразования, например: 224 • «ввести сведения о клиентах»; • «выдать информацию о текущих расходах»; • «проверить кредитоспособность клиента»; • «получить документы по отгрузке продукции». Назначение процесса (работы) состоит в продуцировании выходных по- токов из входных в соответствии с действием, задаваемым именем процесса. Информация в поле физической реализации показывает, какое подразде- ление организации, программа или аппаратное устройство выполняет данный процесс. |