Проектирование БД, жизненный цикл БД

10-04-96                 ЛЕКЦИЯ 4

Проектирование БД, жизненный цикл БД

                       операционная система

                   комплекс технических устройств

1 фаза - проектирование системы

2 фаза-  что идет после проектирования : заполнение системы информацией, расширение БД

Жизненный цикл БД делится на эти 2 фазы

С точки зрения проектировщика систем БД проектирование системы - объединение системы БД, ППО, программного обеспечения СУБД,ОС и комплексы технических средств в единую систему информации сервиса пользователя При анализе проблем жизненного цикла приложения целесообразно искать ответы на следующие 3 вопроса:

1- что представляет собой требования пользователя и в какой форме они выражаются

Рекомендуемые материалы

2- какая структура БД ( смотри рисунок выше) позволит удовлетворить требования пользователя

3- каким образом структура БД должна перестраиваться в соответствии  с новыми или изменившимися требованиями

Проблемы проектирования системы БД -нечто более широкое, чем проектирование логической структуры Необходимо анализировать и в той или иной мере оговаривать или обосновывать выбор средств, которые представлены на рисунке При обосновании целесообразно ссылаться на требования пользователей, которые формируются в ТЗ Как правило, при анализе всплывают 2 класса проблем:

1- заключается в максимальном снижении себестоимости проекта при условии отсутствия “обиженных” пользователей ( система БД -многопользуемая система и необходимо избежать низкого качества обслуживания отдельных пользователей)

2- при проектировании системы БД необходимо обеспечить ее гибкость: ориентировать ее на последующую ее модификацию и расширение

Жизненный цикл системы БД

Концепция жизненного цикла системы БД позволяет наукообразно писать развитие системы БД во времени

Жизненный цикла системы БД состоит из 2 фаз:

1- анализы и проектирования системы БД

2- эксплуатация

В рамках каждой фазы удалось сформировать отдельные этапы:

Первая фаза (анализа и проектирования систем) включает следующими этапы:

1- формирование, анализ требований пользователей (ТЗ)

2- концептуальное проектирование

3- проектирование и реализация

4- физическое проектирование системы, которое не отображено в дипломе

Вторая фаза (эксплуатации) включает этапы:

1- реализация БД

2- поддержка функционирования

3- модификация и адаптация системы

Детальное обсуждение этапов жизненных циклов системы БД

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

Цель этапа - выделить “ откуда берется информация” , каким образом обрабатываются данные , требования к данным ( секретность и т д) и куда они в дальнейшем передаются В рамках этого этапа остро стоят 2 проблемы:

1- как корректно собирать информацию от пользователя

2- как ее согласовать в рамках вышеформируемой задачи

Помощь и оказание -метод экспертных оценок, которые разработаны

социологами

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

Проектирование и реализация - состоит из 2 компонентов :

1- проектирование логической структуры БД

2- проектирование прикладных программ при помощи инструментальных средств, генерации программного обеспечения, которая встроена в СУБД

( в рамках vizual технологии vizual basic ): экране формы, командные кнопки, макросы, запросы, мастера и т д

или при помощи языковых средств, которые обязательно входят в состав СУБД ( Acess Basic, X- Base-язык) или при помощи вставок, программ на языке С, Паскаль, Asm

Физическое проектирование - включает 2 компонента

1- определение физической структуры БД в рамках комплекса технических средств

2- отладка программных модулей в рамках физической структуры Итогом этого этапа является полностью готовая к внедрению структура БД

Фаза реализации и функции БД -

Первый этап: реализация БД включает в себя заполнение спроектированной системы БД информации После загрузки в БД информации ( при помощи конверторов) неизбежно следует фаза проверки как содержимого БД так  и работоспособности прикладной ПО в рамках генерированной системы

Второй этап: поддержка функционирования работы СУБД включает в себя 2 комплекса проблем :

1- а) обеспечение целостности БД  б) борьба со сбоями, несанкционированным доступом к информации

2- выделение  “узких мест “ проекта в целом и выработка комплекса мер по их преодолению

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

Модернизация и адаптация системы- предусматривает  внесение в реализованный проект изменения

Различают 2 причины

1- изменение требований пользователя

2- “узкие места” проекта

Цель этого этапа жизненного цикла- улучшить функционирование систем

изменение             узкие

требований            места

пользователя          проекта

 

        реорганизация

реформатирование   реструктурирование

Реформирование- изменение физической структуры БД, то есть

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

Реструктурирование- изменение логической структуры, форматов полей, ведение новых таблиц (если это реляционная модель)

Изменение ПО, кроме этих 2 причин (смотри выше) возможно потребуется вносить после реструктурирования

Процесс проектирования БД

1- составление ТЗ

2- концептуальное проектирование

3- проектирование и реализации

4- физическое проектирование

Процесс проектирования сколь-угодно сложной системы  четко не формированы, а только их основные этапы Совмещение шагов формирования не удается Это позволяет охарактеризовать процесс проектирования в целом как творческий Отдельные шаги проектирования ( этапы, алгоритмы синтеза системы ) характеризуются свойством гетерогенности, то есть элементы множества шагов имеют разнородную природу Процесс проектирования описывается структурой Элементом структуры являются шаги проектирования Например -проектная операция или проектные процедуры Структура многообразна, связи как правило динамический характер При движении от  ТЗ к готовому изделию ( нашем случае это система БД) возможен возврат к предыдущим этапам, что позволяет охарактеризовать процесс проектирования как иттерационные Цена каждой иттерации, те возврата к предыдущему этапу может оказаться непомерно высока Эффективным средством борьбы с такими иттерациями является метод интеллектуального штурма Он основан на специфике проектирования системы БД, в частности каждый этап определяется и завершается четко сформулированным пакетом документов, которые описывают модель

Метод интеллектуального штурма ( экспертной оценки )  

преследует цель обнаружить ошибки, “узкие места” проекта на ранних этапах жизненного цикла БД (чем раньше может быть выявлено “ узкое место”, тем меньше придется платить за ее преодоление) Соответственно для проведения экспертизы формируются бригады экспертов, которые включают ведущих специалистов из групп : администраторов БД, разработки ПО, системных программистов, обслуживающего персонала, ведущих специалистов предметных областей создания БД Соответственно назначается руководитель бригады экспертов ( как правило администратор БД ) Заседание экспертов целесообразно проводить не менее 4 раз в течении жизненного цикла БД Во-первых после этапа концептуального проектирования, во- вторых после реализации, в третьих перед началом эксплуатации системы, в четвертых в процессе эксплуатации системы когда обнаружены “узкие места “ проекта

Схема проведения экспертизы -

1- председатель курирует оформление документации по обсуждаемой проблеме, которая распространяется среди экспертов за несколько дней до экспертизы ( 8-12 дней )

2- при заседании делается сообщение по обсуждаемым проблемам и возможных пути преодоления

3- все замечания экспертов в устной и письменной форме протоколируются

4- заседания ведет председатель, который наделен большими полномочиями , в частности в случае возникновения “базара” он прерывает заседания экспертной бригады

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

           Концептуальное Проектирование

Цель этапа: необходимо представить информацию о предметной области

в форме, которая позволяет реализовать БД несколькими альтернативными

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

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

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

“красиво перейти” к этапу проектирования и описанию логической структуры БД.

Выделяют несколько способов описания концептуальной модели:

1. Диаграмма сущность-связь

2. Словесное описание

3. Отношение при помощи таблиц или системы Фрейма

4. При помощи специализированных языков

Сравним эти способы описания:

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

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

Описание концептуальной модели специализированными языками ориентируется на процесс проектирования и позволяет гибко перейти от концептуальной модели к проектированию логической структуры БД с использованием средств автоматизации ( САПР , и так далее ).

          Диаграмма сущность-связь

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

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

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

1 вариант.

  сущность                    назначение (связь)

                                                       сущность

2 вариант:                                                        проект (атрибут)

 

                                                                         служащий (атрибут)

3 вариант:                 сущность

              назначенный             назначение на

               служащий                   проект    

               (атрибут)                (атрибут)

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

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

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

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

Подходы к концептуальному проектированию

требования

                                                                Высокоуровневое

     Традиционный                                          ( абстрактное )              

         Подход                                               Представление

      Моделирование                                                                                             Объектное    

          Сущностей                                                                                                  Представление    

Объектное (высокоуровневое или абстрактное ) представление процессов в предметной области

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

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

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

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

1- как выделять абстрактный объект

2- как синтезировать их атрибуты ( свойства)

3- как их объединять в иерархию

Выделяют 2 подхода к построению абстрактных объектов:

1) обобщение                  2)  агрегация

Агрегация

Примеры агрегации: 

           объекты в предметной области     агрегатный объект

1- человек бронирует номер                     бронирование

    в гостинице на дату

2- машина перевозит груз

    от пункта загрузки до                       перевозка (рейс)

    места назначения

то есть АГРЕГАТНЫЙ ОБЪЕКТ охватывает несколько более мелких

теоретических объектов , причем он своим появлением в концептуальной модели отображает деление

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

Каждый компанент не является подмножеством какогото сложного объекта , а на уровне концепции рассматривается как простой Генерированный абстрактный объект описывает взаимосвязи между простыми объектами и отображает смысл процесса в предметной обдласти

Обобщение

класс объекта                            родовой объект

собака , кошка , слон                   животное

повозка ,тягач , велосипед              дорожное средство

классы объектов обобщены категорией

Родовой объект подчеркивает общую природу класса объектов , при этом игнорируются отличия

Говорят , что класс объектов обобщается категорией , ччто эдлемент класса относится категории

Соотношение между агрегацией и обобщением

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

Иерархия абстракции -  если несколько раз последовательно применить операции обобщения или агрегации , таким образом получится иерархия объекта

Велосипед                     Тягач                     Лайнер                         Самолет                             Планер

  

                      МАЗ               ГАЗ

в структуре иерархии обобщения отметим следующие особенности:

1- иерархия может содержать несколько корней ( если средства передвижения удалить , таким образом получим 3 корня)

2- некоторые категории могут одновременно принадлежать нескольким объектам ( например- самолет)

пример иерархии агрегации

              

           Обслуживание                                                                                                  Перевозка

                                                                                                 1-n

   Механик                     Дата                                                                Пункт назначения               Груз     

Имя            Мастерская                                                                                            Изготовитель   

                                                        Идент. №                       Стоимость

                                                                                                                   Название

                                                                                                                     Фирмы                Расположение

Между агрегатными объектами и его компонентами существует соотношение 1 : n Анализ 2-х диаграмм позволяет выделить общий абстрактный объект - моторное средство передвиижения Это позволяет объединить 2 концепцуальные схемы в одну

стратегия

                                          тягач                           лайнер                               самолет  

                     

обобщение

   

         Идентифицирующий №                        Стоимость                      Изготовитель

                                                                                                Название фирмы              Расположение

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

Моделирование сущностей

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

Пример: личность , вещь , документ- все это сущность

Выделяют категории:

1- тип сущностей- набор однородных предметов или вещей , которые на уровне концепции выступают как одно целое ( аналогично категория множества)

2- экземпляр сущности - конкретная вещь  в наборе типа сущностей (аналогично элементам множества)

3- атрибуты - средства определения сущности , или именованная характеристика сущности

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

4- связи - отображают ассоциации между сущностями Связи бывают:

1 :1, 1 : многим , многие ко многим  Эта характеристика называется степенью ассоциативности

Суть подхода моделирования сущности при построениии концепции модели (метод штыковой атаки)

1- при анализе предметной области выделяют различные типы сущностей

2- для каждого типа формируется множество атрибутов , которые должны выполнять функции:

а) идентифицировать сущности

б) описывать их свойства ( характеристики)

в) организовывать взаимосвязи ( ассоциации ) между различными типами сущностей

3- строятся связи ( через атрибуты или напрямую) При этом выделяют следующие ситуации:

а) возможна обязательная связь , то есть существование обоих сущностей жестко зависит от связи При удалении одной сущности , удаляется сущность взаимосвязанная с ней

б) необязательная связь: существование обоих сущностей не зависит от связи

в) условная связь , когда существование подчиненной сущности зависит от связи и от логического условия , которые ему приписывается

пример- связь 1 : многим , клиент : заказы