Лекции и практики (1). Курс лекций и материалы для практических занятий

• Название: Курс лекций и материалы для практических занятий
• Дата: 17.03.2023
• Размер: 1.01 Mb.
• Имя файла: Лекции и практики (1).docx
• Тип: Курс лекций; #996812
• страница: 41 из 75

Этапы проектирования базы данных

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

1. 
   Предпроектная подготовка.
   
2. 
   Проектирование БД.
   
3. 
   Реализация (создание БД и ППО).
   

Общая схема жизненного цикла приложения баз данных приведена на рис. 9.1. Как видно из этого рисунка, проектирование носит итерационный ха- рактер. Например, если на каком-либо этапе выясняется, что ранее сформули- рованные требования или решения не могут быть реализованы, то разработчики должны вернуться на более ранний этап и внести соответствующие изменения. Эти изменения, естественно, могут потребовать корректировки ранее выпол- ненных этапов.

Рассмотрим основные задачи, которые решаются на каждом из этапов.

1. 
   Проектирование начинается обычно с планирования, что позволяет:
   

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

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

• 
  Аналитики. Это специалисты исследуемой предметной области, которые в идеале должны быть знакомы с основами создания баз данных. В их задачу входит постановка задачи проектирования: анализ ПрО, выявление бизнес- процессов и бизнес-правил, определение требований к БД.
  
• 
  Пользователи – те работники, для которых создаётся АИС. Именно они об- ладают знаниями о технологии работы с информацией.
  
• 
  Проектировщики. Это сотрудники, которые будут заниматься собственно разработкой проекта БД.
  

I.2. Определение общих требований к системе



III.2. Разработка и отладка приложений


III.3. Конвертирование и загрузка данных в БД


III.4. Тестирование БД и АИС в целом


III.5. Эксплуатация и сопровождение АИС




Рис. 9.1. Жизненный цикл приложения баз данных

• 
  Администраторы. В том случае, если система небольшая, администратор БД может быть один. Если же система большая и территориально распределен- ная, то помимо АБД потребуется ещё администратор системы, и, возможно, не один. АБД должен появиться не тогда, когда система уже спроектирова- на, а на этапе проектирования БД. Это необходимо хотя бы потому, что при проектировании для отладки и тестирования обязательно создаётся рабочий прототип БД, и желательно, чтобы за общее обеспечение функционирования этого прототипа отвечал отдельный специалист.
  
• 
  Разработчики программного обеспечения. Любая БД требует помимо СУБД создания некоторого прикладного программного обеспечения (ППО). Если сложность этого ППО невелика, то обычно его созданием занимаются сами проектировщики. В противном случае, необходимо набрать программистов (или выделить из имеющихся), которые будут этим заниматься.
  

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

2. 
   Определение общих требований к системе подразумевает:
   

1. 
   Предварительный анализ ПрО.
   

Включает в себя сбор документов, характеризующих ПрО, укрупнённое описание ПрО (не детализированное) и общую постановку задачи.

В процессе анализа и проектирования желательно ранжировать планиру- емые функции системы по степени важности. Один из возможных вариантов классификации – MoSCoW-анализ (терминология Клегга и Баркера, [7]):

Must have – необходимые функции; Should have – желательные функции; Could have – возможные функции; Won't have – отсутствующие функции.

Необходимые функции обеспечивают возможности, которые являются кри- тическими для успешной работы системы. Реализация желательных и воз-можныхфункций системы ограничена временными и/или финансовыми рамками. Отсутствующие функции – это те функции, которые реально су- ществуют, но не будут реализованы в этом проекте по различным причинам.

Примечание: если применяются средства автоматизации проектирования (CASE-средства), то задачу последовательного внесения изменений берёт на себя это CASE-средство.

2. 
   Рассмотрение и принятие результатов анализа.
   

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

3. 
   Определение критических факторов успеха.
   

В данном случае под термином критические факторы подразумеваются как "жизненно важные для приёмки и успешной реализации проекта", так и

"критические с точки зрения функционирования системы". Очевидно, что если не учесть хотя бы один из таких факторов, то существование и успеш- ное функционирование проекта будет поставлено под вопрос.

4. 
   Оценка системных ограничений.
   

В качестве часто встречающихся ограничений можно отметить следующие:

• 
  финансовые;
  
• 
  временные;
  
• 
  технические (например, использование определённой аппаратуры);
  
• 
  программные (например, выбор определённого программного обеспече- ния);
  
• 
  ограничения, определяемые наличием существующих систем, с которыми необходимо обеспечить совместимость.
  
1. 
   Определение целевой архитектуры.
   

Под целевой архитектурой в данном случае понимается архитектура с точки зрения СУБД (однозадачная или многозадачная, архитектура клиент-сервер, параллельный сервер). Выбор архитектуры повлияет в дальнейшем на пере- чень требуемых аппаратных и программных средств.

6. 
   Определение требований к производительности.
   

Необходимо примерно оценить количество транзакций в единицу времени и объём обрабатываемых этими транзакциями данных. Требования к произво- дительности зависят от режима, в котором будет функционировать система:

1. 
   Интерактивный режим. Для этого режима устанавливается время, в тече- ние которого пользователь должен получить ответ на свой запрос. Обыч- но время реакции системы не должно превышать нескольких секунд.
   
2. 
   Пакетный режим. Здесь требования к производительности обычно не та- кие жёсткие, как для интерактивного режима, и выражаются в минутах или часах, требующихся на получение конечного результата вычислений.
   
3. 
   Режим реального времени. Этот режим является самым сложно реализу- емым. В настоящее время (2009 г.) существует только одна СУБД, кото- рая в полной мере отвечает требованиям режима реального времени: СУБД ЛИНТЕР – единственная СУБД отечественного производства (компания РЕЛЭКС, г. Воронеж).
   

7. 
   Согласование стандартов проектирования, в частности:
   
   • 
     правил именования объектов;
     
   • 
     стандарта проектной документации;
     
   • 
     правил введения общих типов и т.п.
     
8. 
   Выбор программных средств для проектирования и реализации системы (имеются в виду вспомогательные средства типа CASE и др.).
   

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

Собственно процесс проектирования БД включает в себя следующие ос- новные этапы:

1. 
   Информационно-логическое (инфологическое) проектирование.
   
2. 
   Определение требований к операционной обстановке, в которой будет функционировать информационная система.
   
3. 
   Выбор СУБД и других инструментальных программных средств.
   
4. 
   Логическое проектирование БД. (Иногда этот этап называется даталоги- ческим проектированием).
   
5. 
   Физическое проектирование БД.
   

Эти этапы подробно рассмотрены в следующем разделе.

После того, как проект базы данных создан, наступает этап реализации проекта. Он разбивается на следующие шаги:

1. 
   Создание прототипа БД и его отладка. Отладка подразумевает проверку правильности функционирования процедурных объектов БД (триггеры, про- цедуры, функции). Прототип позволяет определить жизнеспособность про- екта БД и выявить его недостатки, что может потребовать внесения измене- ний в проект. Прототип также нужен как база для разработчиков приложе- ний. Для этого БД наполняется реальными или тестовыми данными.
   
2. 
   Разработка и отладка приложений. Выполняется разработчиками про- граммного обеспечения на основе функциональных требований, которые были выявлены на этапах I.2, I.3, и спецификации БД (схемы БД).
   
3. 
   Конвертирование и загрузка данных в БД. Этот этап выполняется в том случае, если данные в БД загружаются из ранее существовавшей системы.
   
4. 
   Тестирование работы базы данных и АИС в целом. Различают такие виды тестов, как:
   

• 
  автономные– тесты отдельных модулей;
  
• 
  тестысвязей– тесты между модулями;
  
• 
  регрессивные – тесты на проверку уже протестированных модулей в связи с подключением новых модулей (функций), которые могут нарушить ра- боту ранее созданных модулей;
  
• 
  нагрузочные – тесты на проверку времени реакции системы в рабочем режиме или определение производительности системы;
  
• 
  системные– тесты на проверку функционирования системы в целом;
  
• 
  приёмо-сдаточные– тесты, которые проводятся при сдаче системы (АИС) в эксплуатацию.
  

Этап III.4 включает нагрузочные, системные и приёмо-сдаточные тесты.

5. 
   Эксплуатация и сопровождение АИС. Здесь можно выделить ряд задач:
   
   • 
     В процессе эксплуатации АИС может возникнуть необходимость внесе- ния изменений в систему. Это может быть вызвано изменениями пред- метной области, появлением новых задач или выявлением существенных недостатков в АИС. Нельзя забывать о том, что все вносимые изменения должны быть документированы.
     
   • 
     Необходимо выполнять резервное копирование данных, чтобы предот- вратить их потерю в случае серьёзного сбоя или ошибки пользователя.
     
   • 
     Сопровождение АИС обычно включает периодические проверки выпол- нения системных ограничений (на объём данных и время реакции систе- мы). В результате этих проверок удаляются устаревшие данные (если не предусмотрено автоматическое архивирование данных). Улучшение по- казателей производительности системы может быть достигнуто за счёт настройки СУБД, которая выполняется администратором базы данных.
     

Теперь перейдём к более подробному обсуждению этапов проектирования БД.