(Лекция 6)
Нисходящее проектирование БД
При «нисходящем» проектировании осуществляется структурное проектирование сверху—вниз («нисходящее» проектирование).
Такое проектирование называют анализом - происходит изучение целого (описания предметной области), затем разделение целого на составные части и затем следует последовательное изучение этих частей.
Этапы проектирования БД методом «нисходящего» проектирования представлены на рисунке.
Пр Обл - предметная область; ИЛМ - информационно—логическая модель предметной области; ДЛМ - даталогическая модель; НФ - нормальная форма; ФМ - физическая модель БД.
Рисунок — Этапы проектирования БД методом «нисходящего» проектирования
Для отображения метода использованы следующие обозначения: в кругах описаны названия этапов проектирования, в прямоугольниках - результаты.
Проектирование начинается с анализа предметной области и формирования описания внешнего уровня БД, объединяющего представления всех пользователей разрабатываемой БД, выявления классов объектов (сущностей) предметной области, связей между ними.
На основе описания внешнего уровня строится концептуальная
информационно—логическая модель предметной области (ИЛМ), затем на её основе получают даталогическую модель (ДЛМ) базы данных. ДЛМ является основой для следующего этапа проектирования БД - этапа формирования физической модели базы данных.
Такой подход к проектированию БД называют также концептуальным или концептуальным проектированием.
В концептуальном подходе к проектированию БД выделяют следующие три
сферы:
— реальный мир или объектную систему;
— информационную сферу;
— даталогическую сферу.
1. Основными составляющими объектной системы являются: объект (экземпляр сущности), свойство (атрибут), отношение (связь) (предметная область определена, если известны существующие в ней объекты, их свойства и отношения между ними)
Объект в концептуальном подходе - это то, о чем в информационной системе должна накапливаться информация.
Объекты объеденены в классы объектов (экземпляры сущностей в сущность, или ещё говорят - тип сущности). Класс объектов может состоять из одного или более объектов.
Например, класс объектов ФИЗИЧЕСКОЕ ЛИЦО, отдельные объекты -Иванов, Петров, Сидоров.
Каждый класс объектов должен обладать уникальным идентификатором, который однозначно идентифицирует каждый отдельный объект (экземпляр сущности) в классе объектов. Каждый класс объектов должен обладать некоторыми свойствами (атрибутами), количество которых одинаково для каждого объекта в классе объектов, значение же каждого свойства может быть различным в разных объектах. Каждый класс объектов может обладать любым количеством связей с другими классами объектов.
2. Информационная (инфологическая) сфера представляется понятиями, с помощью которых можно формально описать и проанализировать информацию об объектной системе.
3. В даталогической сфере рассматриваются вопросы представления предметной области (описанной в информационной сфере) с помощью структур данных, определяемых выбором СУБД. В настоящее время наиболее широко для формирования даталогической сферы используются реляционные СУБД.
В основе концептуального подхода лежит идея установления последовательного соответствия между объектной системой, информационной и далее даталогической сферами.
Происходит последовательное преобразование понимания объектов предметной области и связей между ними в формализованное описание логики информации предметной области и дальнейшее преобразование логики информации
предметной области в описание структуры базы данных в терминах выбранных структур данных - построение логики данных.
Такое последовательное преобразование позволяет понятным и простым образом осуществлять правильное отображение смысла реального мира в базе данных. Таким образом, концептуальное проектирование БД состоит из следующих последовательных этапов:
- анализ предметной области, выявление классов объектов и связей между ними (формирование внешнего уровня БД) - описание объектной сферы;
- концептуальное инфологическое проектирование. Строится концептуальная информационно—логическая модель (ИЛМ) предметной области, формально (в терминах выбранной методологии построения ИЛМ) описывающая классы объектов и связи между ними (формирование концептуального уровня БД) -описание информационной сферы;
- концептуальное даталогическое проектирование. На основе ИЛМ в терминах выбранной модели данных строится концептуальная даталогическая модель (ДЛМ) БД (формирование концептуального уровня БД) - описание даталогической сферы;
- преобразование ДЛМ в физическую модель БД, полученную на ЯОД выбранной СУБД (формирование внутреннего уровня БД).
Эамечание: на втором этапе проектирования ИЛМ можно преобразовать в любую даталогичскую модель - иерархическую, сетевую, реляционную, традиционные файлы.
Метод «нисходящего» проектирования достаточно формализован и используется в CASE (Computer Aided System/Software Engineering — компьютерное проектирование программного обеспечения и систем) средствах.
Змечания по использованию CASE - средств:
- особенно эффективно их использование при создании крупных корпоративных АИС большим коллективом разработчиков;
- современные CASE - средства позволяют поддерживать как начальные этапы разработки АИС, так и проектирование, и генерацию баз данных и пользовательских интерфейсов;
- CASE - средства обеспечивают качество принимаемых технических решений и подготовку проектной документации;
CASE—средства классифицируются по:
- поддерживаемым методологиям проектирования (структурно— ориентированные, объектно—ориентированные, комплексно—ориентированные);
- поддерживаемым графическим нотациям построения диаграмм$
- степени интегрированности (отдельные локальные средства, набор интегрированных средств, охватывающих большинство этапов разработки АИС)$
- по режиму коллективной разработки проекта (режим реального времени, режим объединения проектов) и ряду других.
Современный рынок программных средств насчитывает около 300 различных CASE - средств.
Многие из этих продуктов предназначены не только для проектирования баз данных, но и для решения других задач, например, для моделирования потоков данных или бизнес—процессов, функционального моделирования, документирования, управления проектами и т.д.
Наиболее популярные приведены в таблице.
Таблица - CASE - средства, используемые для проектирования БД.
|
Название CASE— средства |
Фирма— производитель |
URL |
|
Erwin |
Computer Associates |
|
|
Designer 2000/ Designer 6i |
Oracle |
|
|
Power Designer |
Sybase |
|
|
ER/Studio |
Embarcadero Technologies |
|
|
Visio Enterprise |
Microsoft |
Сравнение методов проектирования (приведено в таблице)
(для реляционной модели данных)
Таблица - Сравнение методов проектирования БД
|
Критерии |
«Восходящее» проектирование (Метод нормализации) |
«Нисходящее» проектирование (Концептуальный подход) |
|
Степень описания семантики (смысла) предметной области |
Высокая |
Низкая (начальная модель -ДЛМ РБД, термины РМД не предусматривают возможность описания полного смысла предметной области.) |
|
Вероятность появления ошибок в последующей работе АИС |
Низкая (при условии качественного проектирования) |
Высокая |
|
Степень формализации процесса (возможность автоматизации |
Высокая |
Отсутствует |
|
процесса) |
|
|
|
Объем трудозатрат при приведении ДЛМ БД к заданной НФ |
Небольшой |
Очень большой |
Проектирование БД. Формирование внешнего уровня БД
Внешний уровень проектируемой БД представляет собой обобщенное представление всех будущих пользователей БД. Это обобщенное представление может быть оформлено в виде технической документации (технического задания), различных схем, рисунков, таблиц, словесного описания.
Для того чтобы сформировать внешний уровень БД необходимо провести анализ предметной области,
( сбор потребностей предприятия в рамках решения задачи автоматизации, определить размер разрабатываемой АИС, который может изменяться от потребностей отдела до потребностей всего предприятия), и также увидеть возможную тенденцию функционального развития АИС.
Рассмотрим основные результаты, отображающие внешний уровень базы данных и которые могут быть получены в ходе анализа предметной области.
Характеристика задачи
Прежде чем начать разработку необходимо определить характеристику задачи. В состав характеристики задачи входят следующие компоненты:
- описание цели;
- назначение решения конкретной задачи,
- перечень процессов, реализуемых решаемой задачей;
- обоснование целесообразности автоматизации решения задачи; указание перечня объектов автоматизации.
Под целью автоматизации решения задачи подразумевается получение определенных значений экономического эффекта в сфере управления какими—либо процессами в системе предприятия или снижение стоимостных и трудовых затрат на обработку информации, повышение оперативности её обработки т.д., то есть получение эффекта от внедрения данной задачи.
В рамках получения характеристики задачи необходимо также провести обзор и анализ аналогов подобных, существующих на огромном современном рынке программных продуктов, систем, предназначенных для автоматизации функций предприятия. Анализ должен дать вывод о необходимости данной разработки.
Структура предприятия. Информационные потоки
Одна из важных задач при обследовании предприятия - увидеть организационно—кадровую структуру предприятия, информационные потоки, существующие между структурными единицами предприятия, выделить те, которые будут подлежать автоматизации. Пример структуры предприятия и информационных потоков, выявленных в ходе анализа предметной области, отраженной в подсистеме «Управление персоналом» представлен на рисунке.
1 - штатное расписание подразделения; 2 - заявление о приеме/увольнении и пр.;
3 - трудовой договор; 4 - приказ о перемещении; 5 - отчет о количественном составе контингента сотрудников; 6 - внешний отчет; 7 - отчет об исполнении штатного расписания
Рисунок 4 — Организационная структура предприятия. Информационные потоки
Кроме внутренних необходимо также выявить и внешние для предприятия информационные потоки. Это, как правило, нормативно - правовая информация, создаваемая государственными учреждениями в части законодательств, поток информации о конъюнктуре рынка, нормативные документы вышестоящих организаций и т.п. Поступающая на предприятие информация может влиять на обработку данных в АИС. Например, выявлено требование, что в БД необходимо учитывать постоянно обновляющийся перечень стандартов формирования того или иного документа. На каждом предприятии существуют также информационные потоки, направленные от предприятия во внешние органы. Это отчеты в вышестоящие организации, данные для налоговых и пенсионных органов и т.п.
Описание входных и выходных документов
С форм входных документов осуществляется ввод информации в БД, формы выходных документов формируются на основе БД. При этом ввод информации может осуществляться механическим способом (ввод с клавиатуры), полуавтоматическим или автоматическим способом (с магнитных носителей, из оперативной памяти).
Например, для задачи «Приказы по перемещению сотрудников» (функции учета приема, перевода, увольнения сотрудников) входными являются заявление сотрудника, трудовой договор, штатное расписание подразделения. Выходными -кадровый приказ, отчет по исполнению штатного расписания.
Входные документы, как правило, отображаются в проектируемой модели данных, выходные документы получают на основе содержимого БД.
В идеальном варианте автоматизация дорлжна привести к сокращению информационных потоков на предприятии, переходу на электронный документооборот - см. рисунок.
Рисунок - информационные потоки, формируемые из БД
Функциональная структура АИС
Одной из важных задач в ходе анализа предметной области является определение масштаба разработки, выделение функций, объединение их в задачи, задач — в функциональные подсистемы. Состав функциональных подсистем разрабатываемой автоматизированной системы, во многом, определяется характером деятельности предприятия, формой собственности, размером.
Например, функциональная подсистема «Управление персоналом» автоматизированной информационной системы предприятия может иметь деление на задачи и функции, представленное в таблице 3.
В таблице приведены примеры названия комплексов задач и задач, входящих в эти комплексы. Такая (по объему задач) подсистема может появиться на крупном предприятии. Возможно, на небольшом предприятии количество задач этой подсистемы может уменьшиться, так как, автоматизировать, например, функцию формирования и активизации в БД кадровых приказов будет не совсем целесообразно.
Таблица 3 - Состав функциональной подсистемы «Управление персоналом»
Для каждой отдельной задачи должна быть определен состав входящих в неё функций, так как зачастую фрагмент БД разрабатывается для решения отдельной конкретной задачи и далее либо существует отдельно в виде локальной БД, либо интегрируется с другими фрагментами БД в рамках базы данных корпоративной информационной системы предприятия.
В рамках одной задачи основная часть функций использует одни и те же данные или фрагменты данных, либо данные преобразуются функциями по следовательно.
Удобно представлять перечень выявленных в составе задачи автоматизации функции в виде рисунка иерархии функций. Иерархия функций позволяет отобразить функциональные зависимости автоматизируемых процессов. Пример
функциональной иерархии задачи «Личная карточка сотрудника» приведен на рисунке 5.
На рисунке 5 все функции пронумерованы, эта нумерация может понадобиться в дальнейшем при проверке соответствия выявленной иерархии функций структуре полученной модели данных.
Скачать лекцию:
Пароль на архив: privetstudent.com