Проектирование АИС. С аратовский госуниверситет м еханико математический факультет проектирование информационных систем Составил
 Скачать 3.17 Mb.
|
|
8.3 Проектирование хранилищ данных В хранилища данных помещают данные, которые редко меняются. Хранилища ориентированы на выполнение аналитических запросов, обеспечивающих поддержку принятия решений для руково- дителей и менеджеров. При проектировании хранилищ данных необходимо выполнять следующие требования: • хранилище должно иметь понятную для пользователей структуру данных; • должны быть выделены статические данные, которые модифицируются по расписанию (еже- дневно, еженедельно, ежеквартально); • должны быть упрощены требования к запросам для исключения запросов, требующих множе- ственных утверждений SQL в традиционных реляционных СУБД; • должна обеспечиваться поддержка сложных запросов SQL, требующих обработки миллионов записей. Как видно из этих требований, по своей структуре реляционные СУБД существенно отличаются от хранилищ данных. Нормализация данных в реляционных СУБД приводит к созданию множества связанных между собой таблиц. Выполнение сложных запросов неизбежно приводит к объединению многих таблиц, что значительно увеличивает время отклика. Проектирование хранилища данных подразумевает создание денормализованной структуры данных, ориентированных в первую очередь на высокую производительность при выполнении аналитических запросов. Нормализация делает модель хранилища слишком сложной, затрудняет ее понимание и снижает скорость выполнения запроса. Для эффективного проектирования хранилищ данных ERwin использует размерную модель – методологию проектирования, предназначенную специально для разработки хранилищ данных. Размерное моделирование сходно с моделированием связей и сущностей для реляционной модели, но имеет другую цель. Реляционная модель акцентируется на целостности и эффективности ввода данных. Размерная модель ориентирована в первую очередь на выполнение сложных запросов В размерном моделировании принят стандарт модели, называемый схемой "звезда которая обеспе- чивает высокую скорость выполнения запроса посредством денормализации и разделения данных. Невозможно создать универсальную структуру данных, обеспечивающую высокую скорость обработ- ки любого запроса, поэтому схема "звезда"строится для обеспечения наивысшей производительности при выполнении самого важного запроса (или группы запросов). Схема "звезда"обычно содержит одну большую таблицу, называемую таблицей факта, помещенную в центре. Ее окружают меньшие таблицы, называемые таблицами размерности, которые связаны с таблицей факта радиальными связями. Для создания БД со схемой "звезда"необходимо проанализировать бизнес-правила предметной области для выяснения центрального запроса. Данные, обеспечивающие выполнение этого запроса, должны быть помещены в центральную таблицу. При проектировании хранилища важно определить источник данных, метод, которым данные извлекаются, преобразуются и фильтруются, прежде чем они импортируются в хранилище. Знания об источнике данных позволяют поддерживать регулярное обновление и проверку качества данных. Вычисление размера БД ERwin позволяет рассчитать приблизительный размер БД в целом, а также таблиц, индексов и дру- гих объектов через определенный период времени после начала эксплуатации ИС. Расчет строится на основе следующих параметров: начальное количество строк; максимальное количество строк; прирост количества строк в месяц. Результаты расчетов сводятся в отчет. Прямое и обратное проектирование Прямым проектированием называется процесс генерации физической схемы БД из логической моде- ли. При генерации физической схемы ERwin включает триггеры ссылочной целостности, хранимые процедуры, индексы, ограничения и другие возможности, доступные при определении таблиц в вы- бранной СУБД. Обратным проектированием называется процесс генерации логической модели из физической БД. Обратное проектирование позволяет конвертировать БД из одной СУБД в другую. После создания логической модели БД путем обратного проектирования можно переключиться на другой сервер и произвести прямое проектирование. Кроме режима прямого и обратного проектирования программа обеспечивает синхронизацию меж- ду логической моделью и системным каталогом СУБД на протяжении всего жизненного цикла со- здания ИС. Контрольные вопросы 1. Укажите, к какому уровню детализации относится модель данных, основанная на ключах Модель данных среднего уровня (более подробное представление данных) Модель данных верхнего уровня (слабо детализирована) Модель данных нижнего уровня (детальное представление структуры данных 2. Укажите, к какому уровню детализации относится диаграмма сущность-связь Модель данных нижнего уровня (детальное представление структуры данных) Модель данных верхнего уровня (слабо детализирована) Модель данных среднего уровня (более подробное представление данных) 3. Укажите, к какому уровню детализации относится полная атрибутивная модель Модель данных верхнего уровня (слабо детализирована) Модель данных среднего уровня (более подробное представление данных) Модель данных нижнего уровня (детальное представление структуры данных) 4. Укажите, что задает правило валидации: Список допустимых значений для конкретной колонки Правила проверки допустимых значений Значение, которое нужно ввести в колонку, если никакое другое значение не задано явным образом во время ввода данных 5. Укажите базовые понятия ERD-диаграммы Сущности Связи Атрибуты Идентификатор 6. Укажите, что позволяют осуществить диаграммы ERD Документация информационных аспектов бизнес-системы Детализация бизнес-процессов Детализация накопителей данных 7. Укажите, какая модель данных представляет данные в третьей нормальной форме Полная атрибутивная модель Диаграмма сущность – связь Модель данных, основанная на ключах 8. Укажите, какая модель данных включает описание всех сущностей и первичных ключей Полная атрибутивная модель Диаграмма сущность – связь Модель данных, основанная на ключах 9. Укажите, какие уровни отображения диаграммы имеет ERwin Уровень сущностей Уровень первичных ключей Уровень определений Уровень атрибутов Уровень иконок Набрано баллов 9 Унифицированный язык визуального моделирования (UML) Существует множество технологий и инструментальных средств, с помощью которых можно реализо- вать в некотором смысле оптимальный проект ИС, начиная с этапа анализа и заканчивая созданием программного кода системы. В большинстве случаев эти технологии предъявляют весьма жесткие требования к процессу разработки и используемым ресурсам, а попытки трансформировать их под конкретные проекты оказываются безуспешными. Эти технологии представлены CASE-средствами верхнего уровня или CASE-средствами полного жизненного цикла (upper CASE tools или full life- cycle CASE tools). Они не позволяют оптимизировать деятельность на уровне отдельных элементов проекта, и, как следствие, многие разработчики перешли на так называемые CASE-средства нижнего уровня (lower CASE tools). Однако они столкнулись с новой проблемой — проблемой организации взаимодействия между различными командами, реализующими проект. Унифицированный язык объектно-ориентированного моделирования Unified Modeling Language (UML) явился средством достижения компромисса между этими подходами. Существует достаточ- ное количество инструментальных средств, поддерживающих с помощью UML жизненный цикл информационных систем, и, одновременно, UML является достаточно гибким для настройки и под- держки специфики деятельности различных команд разработчиков. В настоящее время консорциум пользователей UML Partners включает в себя представителей 3 таких грандов информационных технологий, как Rational Software, Microsoft, IBM, Hewlett-Packard, Oracle, DEC, Unisys, IntelliCorp, Platinum Technology. UML представляет собой объектно-ориентированный язык моделирования, обладающий следую- щими основными характеристиками: • является языком визуального моделирования, который обеспечивает разработку репрезентатив- ных моделей для организации взаимодействия заказчика и разработчика ИС, различных групп разработчиков ИС; • содержит механизмы расширения и специализации базовых концепций языка. UML — это стандартная нотация визуального моделирования программных систем, принятая кон- сорциумом Object Managing Group (OMG) осенью 1997 г., и на сегодняшний день она поддержива- ется многими объектно-ориентированными CASE-продуктами. UML включает внутренний набор средств моделирования (модулей?) («ядро»), которые сейчас приняты во многих методах и средствах моделирования. Эти концепции необходимы в большинстве прикладных задач, хотя не каждая концепция необходима в каждой части каждого приложения. Пользователям языка предоставлены возможности: • строить модели на основе средств ядра, без использования механизмов расширения для боль- шинства типовых приложений; • добавлять при необходимости новые элементы и условные обозначения, если они не входят в ядро, или специализировать компоненты, систему условных обозначений (нотацию) и ограни- чения для конкретных предметных областей. 9.1 Синтаксис и семантика основных объектов UML Классы Классы — это базовые элементы любой объектно-ориентированной системы. Классы представляют собой описание совокупностей однородных объектов с присущими им свойствами — атрибутами, операциями, отношениями и семантикой. В рамках модели каждому классу присваивается уникальное имя, отличающее его от других классов. Если используется составное имя (в начале имени добавляется имя пакета, куда входит класс), то имя класса должно быть уникальным в пакете. Атрибут — это свойство класса, которое может принимать множество значений. Множество до- пустимых значений атрибута образует домен. Атрибут имеет имя и отражает некоторое свойство моделируемой сущности, общее для всех объектов данного класса. Класс может иметь произвольное количество атрибутов. Операция — реализация функции, которую можно запросить у любого объекта класса. Операция показывает, что можно сделать с объектом. Исполнение операции часто связано с обработкой и изменением значений атрибутов объекта, а также изменением состояния объекта. На рис. 9.1 приведено графическое изображение класса «Заказ» в нотации UML. Синтаксис UML для свойств классов (в отдельных программных средствах, например, в IBM UML Modeler, порядок записи параметров может быть иным): <признак видимости> <имя атрибута> : <тип данных> = <значение по умолчанию> <признак видимости> <имя операции> <(список аргументов)> Видимость свойства указывает на возможность его использования другими классами. Один класс может «видеть» другой, если тот находится в области действия первого и между ними существует явное или неявное отношение. В языке UML определены три уровня видимости: Рис. 9.1: Изображение класса в UML • public (общий) — любой внешний класс, который «видит» данный, может пользоваться его общими свойствами. Обозначаются знаком «+» перед именем атрибута или операции; • protected (защищенный) — только любой потомок данного класса может пользоваться его защищнными свойствами. Обозначаются знаком «#»; • private (закрытый) — только данный класс может пользоваться этими свойствами. Обознача- ются символом «-» . Еще одной важной характеристикой атрибутов и операций классов является область действия. Область действия свойства указывает, будет ли оно проявлять себя по-разному в каждом экземпляре класса, или одно и то же значение свойства будет совместно использоваться всеми экземплярами: • instance (экземпляр) — у каждого экземпляра класса есть собственное значение данного свой- ства; • classifier (классификатор) — все экземпляры совместно используют общее значение данного свойства (выделяется на диаграммах подчеркиванием). Возможное количество экземпляров класса называется его кратностью. В UML можно определять следующие разновидности классов: • не содержащие ни одного экземпляра — тогда класс становится служебным (Abstract); • содержащие ровно один экземпляр (Singleton); • содержащие заданное число экземпляров; • содержащие произвольное число экземпляров. Принципиальное назначение классов характеризуют стереотипы. Это, фактически, классифика- ция объектов на высоком уровне, позволяющая определить некоторые основные свойства объекта (пример стереотипа — класс «действующее лицо»). Механизм стереотипов является также сред- ством расширения словаря UML за счет создания на основе существующих блоков языка новых, специфичных для решения конкретной проблемы. Диаграммы классов Классы в UML изображаются на диаграммах классов, которые позволяют описать систему в стати- ческом состоянии — определить типы объектов системы и различного рода статические связи между ними. Классы отображают типы объектов системы. Между классами возможны различные отношения, представленные на рис. 9.2 : • зависимости, которые описывают существующие между классами отношения использования; • обобщения, связывающие обобщенные классы со специализированными; • ассоциации, отражающие структурные отношения между объектами классов. Зависимостью называется отношение использования, согласно которому изменение в специфика- ции одного элемента (например, класса «товар») может повлиять на использующий его элемент (класс «строка заказа»). Часто зависимости показывают, что один класс использует другой в каче- стве аргумента. Обобщение — это отношение между общей сущностью (родителем — класс «клиент») и ее конкрет- ным воплощением (потомком — классы «корпоративный клиент» или «частный клиент»). Объекты класса-потомка могут использоваться всюду, где встречаются объекты класса-родителя, но не на- оборот. При этом он наследует свойства родителя (его атрибуты и операции). Операция потомка с той же сигнатурой, что и у(?) родителя, замещает(?) операцию родителя; это свойство называют полиморфизмом. Класс, у которого нет родителей, но есть потомки, называется корневым. Класс, у которого нет потомков, называется листовым. Ассоциация — это отношение, показывающее, что объекты одного типа неким образом связаны с объектами другого типа («клиент» может сделать «заказ»). Если между двумя классами опре- делена ассоциация, то можно перемещаться от объектов одного класса к объектам другого. При необходимости направление навигации может задаваться стрелкой. Допускается задание ассоциа- ций на одном классе. В этом случае оба конца ассоциации относятся к одному и тому же классу. Это означает, что с объектом некоторого класса можно связать другие объекты из того же класса. Ассоциации может быть присвоено имя, описывающее семантику отношений. Каждая ассоциация имеет две роли, которые могут быть отражены на диаграмме (рис. 9.3 ). Роль ассоциации обладает свойством множественности, которое показывает, сколько соответствующих объектов может участ- вовать в данной связи. рис. 9.3 иллюстрирует модель формирования заказа. Каждый заказ может Рис. 9.2: Отображение связей между классами Рис. 9.3: Свойства ассоциации быть создан единственным клиентом (множественность роли 1.1). Каждый клиент может создать один и более заказов (множественность роли 1..*). Направление навигации показывает, что каждый заказ должен быть «привязан» к определенному клиенту. Такого рода ассоциация является простой и отражает отношение между равноправными сущно- стями, когда оба класса находятся на одном концептуальном уровне и ни один не является более важным, чем другой. Если приходится моделировать отношение типа «часть-целое», то используется специальный тип ассоциации — агрегирование. В такой ассоциации один из классов имеет более высокий ранг (целое — класс «заказ», рис. 9.2 ) и состоит из нескольких меньших по рангу классов (частей — класс «строка заказа»). В UML используется и более сильная разновидность агрегации — композиция, в которой объект-часть может принадлежать только единственному целому. В компо- зиции жизненный цикл частей и целого совпадают, любое удаление целого обязательно захватывает и его части. Для ассоциаций можно задавать атрибуты и операции, создавая по обычным правилам UML классы ассоциаций. Диаграммы использования Диаграммы использования описывают функциональность ИС, которая будет видна пользователям системы. «Каждая функциональность» изображается в виде «прецедентов использования» (use case) или просто прецедентов. Прецедент — это типичное взаимодействие пользователя с системой, кото- рое при этом: • описывает видимую пользователем функцию, • может представлять различные уровни детализации, • обеспечивает достижение конкретной цели, важной для пользователя. Прецедент обозначается на диаграмме овалом, связанным с пользователями, которых принято на- зывать действующими лицами (актерами, actors). Действующие лица используют систему (или ис- пользуются системой) в данном прецеденте. Действующее лицо выполняет некоторую роль в данном прецеденте. На диаграмме изображается только одно действующее лицо, однако реальных пользова- телей, выступающих в данной роли по отношению к ИС, может быть много. Список всех прецедентов фактически определяет функциональные требования к ИС, которые лежат в основе разработки тех- нического задания на создание системы. На диаграммах прецедентов, кроме связей между действующими лицами и прецедентами, воз- можно использование еще двух видов связей между прецедентами: «использование» и «расширение» (рис. 9.4 ). Связь типа «расширение» применяется, когда один прецедент подобен другому, но несет несколько большую функциональную нагрузку. Ее следует применять при описании изменений в нормальном поведении системы. Связь типа «использование» позволяет выделить некий фрагмент поведения системы и включать его в различные прецеденты без повторного описания. На рис. 9.4 показано, что при исполнении прецедента «формирование заказа» возможно использо- вание информации из предыдущего заказа, что позволит не вводить все необходимые данные. А при исполнении прецедентов «оценить риск сделки» и «согласовать цену» необходимо выполнить одно и то же действие — рассчитать стоимость заказа. Динамические аспекты поведения системы отражаются приведенными ниже диаграммами. В отличие от некоторых подходов объектного моделирования, когда и состояние, и поведение системы отображаются на диаграммах классов, UML отделяет описание поведения в диаграммы взаимодействия. В UML диаграммы классов не содержат сообщений, которые усложняют их чтение. Поток сообщений между объектами выносится на диаграммы взаимодействия. Как правило, диа- грамма взаимодействия охватывает поведение объектов в рамках одного варианта использования. Прямоугольники на диаграмме представляют различные объекты и роли, которые они имеют в системе, а линии между классами отображают отношения (или ассоциации) между ними. Сообщения обозначаются ярлыками возле стрелок, они могут иметь нумерацию и показывать возвращаемые значения. Существуют два вида диаграмм взаимодействия: диаграммы последовательностей и кооперативные диаграммы. |