Формулирование и анализ требований 1 Определение требований к системе 2 Пользовательские представления
| Вид материала | Лекция |
СодержаниеЭтапы проектирования базы данных Концептуальное проектирование базы данных Логическое проектирование базы данных Физическое проектирование базы данных |
- Анализ требований к аис 04-Процесс анализа требований, 89.95kb.
- Наблюдаемое количество требований, которое, как мы предполагаем, представляет собой, 18.87kb.
- Содержание: Раздел I, 307.2kb.
- Принято требований отказ от требований всего Абдрафигов Ахмет Киямович, 560.42kb.
- Материалы олимпиадных заданий, 305.85kb.
- Лекция: Этапы проектирования ис с применением uml: Основные типы uml-диаграмм, используемые, 209.83kb.
- Обобщение судебной практики по проблемным вопросам рассмотрения заявлений о включении, 1073.87kb.
- Анализ требований, предъявляемых к системе Разработка технического задания, 30.95kb.
- Анализ примерной программы (попоп). Анализ буп: вариативная часть; практики; курсовые;, 11.83kb.
- Анализ примерной программы (попоп). Анализ буп: вариативная часть; практики; курсовые;, 11kb.
| Этапы проектирования базы данных Процесс проектирования базы данных состоит из трех основных этапов: концептуальное, логическое и физическое проектирование. Концептуальное проектирование базы данных Концептуальное проектирование базы данных. Процесс создания модели используемой на предприятии информации, не зависящей от любых физических аспектов ее представления. Первый этап процесса проектирования базы данных называется концептуальным проектированием базы данных. Он заключается в создании концептуальной модели данных для анализируемой части предприятия. Эта модель данных создается на основе информации, записанной в спецификациях требований пользователей. Концептуальное проектирование базы данных абсолютно не зависит от таких подробностей ее реализации, как тип выбранной целевой СУБД, набор создаваемых прикладных программ, используемые языки программирования, тип выбранной вычислительной платформы, а также от любых других особенностей физической реализации. При разработке концептуальная модель данных постоянно подвергается тестированию и проверке на соответствие требованиям пользователей. Созданная концептуальная модель данных предприятия является источником информации для этапа логического проектирования базы данных. Логическое проектирование базы данных Логическое проектирование базы данных. Процесс создания модели используемой на предприятии информации на основе выбранной модели организации данных, но без учета типа целевой СУБД и других физических аспектов реализации. Второй этап проектирования базы данных называется логическим проектированием базы данных. Его цель состоит в создании логической модели данных для исследуемой части предприятия. Концептуальная модель данных, созданная на предыдущем этапе, уточняется и преобразуется в логическую модель данных.Логическая модель данных учитывает особенности выбранной модели организации данных в целевой СУБД (например, реляционная модель). Если концептуальная модель данных не зависит от любых физических аспектов реализации, то логическая модель данных создается на основе выбранной модели организации данных целевой СУБД. Иначе говоря, на этом этапе уже должно быть известно, какая СУБД будет использоваться в качестве целевой - реляционная, сетевая, иерархическая или объектно-ориентированная. Однако на этом этапе игнорируются все остальные характеристики выбранной СУБД, например, любые особенности физической организации ее структур хранения данных и построения индексов. В процессе разработки логическая модель данных постоянно тестируется и проверяется на соответствие требованиям пользователей. Для проверки правильносги логической модели данных используется метод нормализации. Нормализация гарантирует, что отношения, выведенные из существующей модели данных, не будут обладать избыточностью данных, способной вызвать нарушения в процессе обновления данных после их физической реализации. Помимо всего прочего, логическая модель данных должна обеспечивать поддержку всех необходимых пользователям транзакций. Созданная логическая модель данных является источником информации для этапа физического проектирования и обеспечивает разработчика физической базы данных средствами поиска компромиссов, необходимых для достижения поставленных целей, что очень важно для эффективного проектирования. Логическая модель данных играет также важную роль на этапе эксплуатации и сопровождения уже готовой системы. При правильно организованном сопровождении поддерживаемая в актуальном состоянии модель данных позволяет точно и наглядно представить любые вносимые в базу данных изменения, а также оценить их влияние на прикладные программы и использование данных, уже имеющихся в базе. Физическое проектирование базы данных Физическое проектирование базы данных. Процесс подготовки описания реализации базы данных на вторичных запоминающих устройствах; на этом этапе рассматриваются основные отношения, организация файлов и индексов, предназначенных для обеспечения эффективного доступа к данным, а также все связанные с этим ограничения целостности и средства защиты. Физическое проектирование является третьим и последним этапом создания проекта базы данных, при выполнении которого проектировщик принимает решения о способах реализации разрабатываемой базы данных. Во время предыдущего этапа проектирования была определена логическая структура базы данных (которая описывает отношения и ограничения в рассматриваемой прикладной области). Хотя эта структура не зависит от конкретной целевой СУБД, она создается с учетом выбранной модели хранения данных, например реляционной, сетевой или иерархической. Однако, приступая к физическому проектированию базы данных, прежде всего необходимо выбрать конкретную целевую СУБД. Поэтому физическое проектирование неразрывно связано с конкретной СУБД. Между логическим и физическим проектированием существует постоянная обратная связь, так как решения, принимаемые на этапе физического проектирования с целью повышения производительности системы, способны повлиять на структуру логической модели данных. Как правило, основной целью физического проектирования базы данных является описание способа физической реализации логического проекта базы данных. В случае реляционной модели данных под этим подразумевается следующее:
Этапы концептуального и логического проектирования больших систем следует отделять от этапов физического проектирования. На это есть несколько причин.
Проектирование базы данных — это итерационный процесс, который имеет свое начало, но не имеет конца и состоит из бесконечного ряда уточнений. Его следует рассматривать прежде всего как процесс познания. Как только проектировщик приходит к пониманию работы предприятия и смысла обрабатываемых данных, а также выражает это понимание средствами выбранной модели данных, приобретенные знания могут показать, что требуется уточнение и в других частях проекта. Особо важную роль в общем процессе успешного создания системы играет концептуальное и логическое проектирование базы данных. Если на этих этапах не удастся получить полное представление о деятельности предприятия, то задача определения всех необходимых пользовательских представлений или обеспечения защиты базы данных становится чрезмерно сложной или даже неосуществимой. К тому же может оказаться затруднительным определение способов физической реализации или достижения приемлемой производительности системы. С другой стороны, способность адаптироваться к изменениям является одним из признаков удачного проекта базы данных. Поэтому вполне имеет смысл затратить время и энергию, необходимые для подготовки наилучшего возможного проекта. На рисунке показана взаимосвязь между этой архитектурой и проектированием баз данных — концептуальным, логическим и физическим. ссылка скрыта ссылка скрыта Соответствие этапов моделирования данных и элементов архитектуры ANSI-SPARC (Рисунок не нужен) Формулирование и анализ требований Планирование разработки базы данных должно быть неразрывно связано с общей стратегией построения информационной системы организации. При выработке такой стратегии необходимо решить следующие основные задачи:
Первым важным шагом в планировании базы данных является четкое определение технического задания для проекта базы данных. В техническом задании должны быть определены основные цели приложения базы данных. В разработке технического задания, как правило, участвуют те представители предприятия, которые стали инициаторами разработки проекта базы данных (например, директор или владелец предприятия). Техническое задание позволяет уточнить назначение проекта базы данных и наметить пути к созданию эффективного приложения базы данных. После подготовки технического задания необходимо определить технические требования. Технические требования должны содержать перечень конкретных задач, реализуемых с использованием базы данных. При этом следует исходить из того, что цели, поставленные в техническом задании, будут достигнуты, если база данных обеспечивает выполнение задач, которые определены в технических требованиях. Для обоснования технического задания и технических требований должна быть подготовлена определенная дополнительная информация, позволяющая охарактеризовать в общих чертах, какая работа должна быть выполнена и какие ресурсы, в том числе финансовые, необходимо на это выделить. Планирование разработки баз данных должно также включать разработку стандартов, которые определяют, как будет осуществляться сбор данных, каким будет их формат, какая потребуется документация и как будет выполняться проектирование и реализация приложений. Разработка и сопровождение стандартов могут быть связаны с немалыми затратами времени, причем на их первоначальное внедрение и последующее сопровождение могут потребоваться значительные ресурсы. Однако четко определенный набор стандартов позволяет создать хорошую основу для последующего обучения персонала и организации контроля качества, а также гарантировать выполнение работ по строго определенным образцам, независимо от навыков и опыта. Например, специальные правила могут определять, как присваиваются имена элементам данных, описываемых в словаре данных, что, в свою очередь, позволит предотвратить их избыточность и противоречивость. Кроме того, необходимо тщательно документировать любые существующие юридические или технические требования к данным (например, строгое соблюдение их конфиденциальности и т.п.). Определение требований к системе Прежде чем перейти к проектированию приложения базы данных, важно установить задачи исследуемой системы и способы взаимодействия приложения с другими частями информационной системы организации. Эти задачи должны учитывать не только работу текущих пользователей и области применения разрабатываемой системы, но и будущих пользователей и другие возможные области применения. На рисунке приведена схема, которая определяет состав задач и область применения приложения базы данных для фирмы по продаже недвижимости. Кроме описания области применения приложения базы данных, необходимо определить основные пользовательские представления, которые поддерживаются базой данных. ссылка скрыта ссылка скрыта Задачи системы для приложения базы данных Пользовательские представления В приложении базы данных может быть предусмотрено одно или несколько пользовательских представлений. Определение пользовательских представлений является существенной составляющей разработки приложения базы данных, поскольку позволяет гарантировать, чтобы ни одна важная категория пользователей базы данных не была исключена из рассмотрения при разработке требований к новому приложению. Пользовательские представления являются особенно полезными при создании относительно сложных приложений базы данных, поскольку позволяют разделить всю совокупность требований к базе данных на легко анализируемые группы. Любое пользовательское представление определяет требования к приложению базы данных в части хранимых в ней данных и транзакций, выполняемых над данными (т.е. оно определяет, какие действия и над какими данными должен выполнять тот или иной пользователь). Требования пользовательского представления могут относиться только к данному представлению или частично совпадать с требованиями других представлений. На рисунке схематически изображена предметная область приложения базы данных с несколькими пользовательскими представлениями (которые обозначены цифрами 1-6). Обратите внимание, что требования некоторых пользовательских представлений (1—3, а также 5 и 6) частично перекрываются (это показано штриховкой), а требования пользовательского представления 4 являются индивидуальными. ссылка скрыта ссылка скрыта Схематическое изображение предметной области приложения базы данных с несколькими пользовательскими представлениями Сбор и анализ требований пользователей Проектирование базы данных основано на сборе и анализе информации о той части организации, которая будет обслуживаться базой данных. Сбор информации осуществляется для последующего создания основных пользовательских представлений (к ним относятся пользовательские представления для основных категорий пользователей или направлений деятельности предприятия). Ниже перечислена информация, которая требуется для решения указанной задачи.
Эта информация затем анализируется для определения требований (или средств), которые должны быть реализованы в разрабатываемом приложении базы данных. Эти требования описываются в документах, известных под общим названием спецификации требований к новому приложению базы данных. Сбор и анализ требований является предварительным этапом концептуального проектирования базы данных, в ходе которого спецификации требований пользователей анализируются с целью выяснения всех необходимых сведений. Объем собранных данных зависит от сути проблемы и действующих бизнес-правил предприятия. Слишком тщательный анализ легко может привести к параличу сверханализа (paralysis by analysis), а слишком поверхностный — к пустой трате времени и денежных средств на проведение работ по реализации решения, которое окажется ошибочным в результате неправильной формулировки проблемы. Собранная на этом этапе информация может быть плохо структурирована и включать некоторые неформальные заявления пользователей, которые впоследствии потребуется преобразовать и представить в виде более четко сформулированных требований. Эта цель достигается с помощью методов составления спецификаций требований, к числу которых относятся, например, технология структурного анализа и проектирования (Structured Analysis and Design — SAD), диаграммы потоков данных (Data Flow Diagrams — DFD) и графики "вход-процесс-выход" (Hierarchical Input Process Output — HIPO), дополненные соответствующей документацией. Как будет показано ниже, для получения гарантий того, что составленный набор требований является полным и непротиворечивым, могут использоваться CASE-инструменты, предназначенные для автоматизированного проектирования и создания программ. Определение набора требуемых функциональных возможностей приложения базы данных является важным направлением проектирования, поскольку системы с неадекватным или неполным перечнем функциональных средств будут лишь раздражать пользователей, что может привести к отказу от работы в системе или лишь к частичному ее использованию. Однако чрезмерно расширенный набор функциональных возможностей также может стать источником проблем, поскольку может вызвать существенное усложнение системы и, как следствие, дополнительные затруднения в ее реализации, сопровождении, использовании и обучении персонала.
|