Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

УП СУБД ч1

.pdf
Скачиваний:
14
Добавлен:
11.06.2015
Размер:
1.05 Mб
Скачать

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

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

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

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

иподпрограмм), тогда как программные коды, написанные на языках баз данных, обычно короткие по объему и имеют простую линейную структуру. Наборы команд языка базы данных часто называются скриптом.

Врамках какого-либо приложения, соответственно, такие действия, как взаимодействие с пользователем, обработка данных, выполняются при помощи средств языков программирования (VisualBasic, C++ и т.д.). При обращении к базе данных используются средства языка базы данных (например, язык SQL), которые вызываются из среды языка программирования, называемого в этом случае включающим языком, при помощи специальной библиотеки (см. раздел 2).

31

Вместе с тем существует тенденция расширять языки баз данных средствами, характерными для языков программирования, с целью расширить возможности обработки данных внутри самой базы данных, а не в приложении. Более того, в настоящее время в основных используемых системах баз данных (Oracle, Microsoft SQL Server) присутствует возможность помещать в базу данных и использовать для обработки данных на сервере программные модули, написанные на языках программирования (Java для Oracle, C# и др. для MS SQL Server).

С другой стороны, существует и обратная тенденция – расширять функциональные возможности языков программирования средствами для обращения к БД без использования отдельного языка баз данных. В качестве примера можно привести среду FoxPro и технологию Microsoft LINQ.

Выводы

моделью данных называется набор средств для построения структур данных, или набор средств типообразования;

модель данных определяет структуры данных, которые можно образовывать для представления информации в БД, операции, предусмотренные для данных, помещенных в эти структуры, и ограничения, которые можно при необходимости наложить на данные;

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

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

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

32

ление и изменение существующих данных) и поиск и извлечение данных;

физической схемой базы данных называется описание структур данных, выполненное при помощи средств языка базы данных (модели данных БД);

логическая схема создается при помощи средств, в некоторой степени абстрагированных от конкретного языка баз данных;

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

Вопросы для контроля

1.Объясните, что такое средства типообразования.

2.Какие типы используются в традиционных языках программирования (на примере известных)?

3.Кратко опишите структуры данных, используемых в реляционной модели данных.

4.Какие операции используются в «реляционной алгеб­ ре» Э. Кодда?

5.Как называются три основные категории команд в языке баз данных?

6.Какая разница между моделью данных и схемой базы данных?

7.Объясните, чем различаются между собой физическая схема и логическая схема базы данных.

8.Для чего используются включающие языки?

33

Раздел 4. Жизненный цикл БД и приложений баз данных

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

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

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

Процесс разработки состоит из набора действий (видов деятельности). Следует отметить, что на ранних этапах развития информационных технологий (60–70-е гг.) к этим действиям ошибочно относили только действия, имеющие отношение к этапам программирования, и другие непосредственно связанные с ними действия. С 90-х годов для разработки ПО и ИС характерно применение комплексного подхода, соответствующего правилам современного менеджмента, поскольку данный вид деятельности рассматривается как одна из отраслей производства. Существуют стан-

34

дарты (IEEE 1074, ISO/IES 12207), которые предназначены для регламентации разработки, приобретения, внедрения и эксплуатации ИС.

Процесс подразделяется на этапы, которых традиционно выделяют четыре: начальный, подготовительный, реализация и внедрение. Применительно к АИС используется термин «жизненный цикл» системы (Software Life Circle), в который дополнительно помещаются этапы «эксплуатация» и «вывод из эксплуатации».

Этапы не следует путать с действиями, которые распределяются по различным этапам.

К основным действиям процесса разработки относятся следующие виды:

1.Исследование предметной области будущей системы

сцелью выявления основных функций системы, предварительной оценки сроков и трудозатрат, принятия решения о возможности реализации системы, и, наконец, разработки функциональных требований к системе. Эта деятельность, получившая историческое название «анализ», выполняется преимущественно на начальной стадии проекта. Ее основными результатами (называемыми в литературе артефактами) являются обычно контракт – юридический документ, в котором описаны обязательства сторон заказчика и исполнителя, и требования к системе, называемые техническим заданием.

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

2.Разработка проекта будущей системы, т.е. проектирование (здесь этот термин понимается в узком смысле, англ. «design» – проектирование). Основная цель проектирования состоит в том, чтобы объяснить, каким образом будущая система будет реализовывать функциональные требования, то есть, иными словами, каким образом она будет устроена. Основным результатом проектирования является описание набора компонент, из которых она будет состоять, и их связей между собой.

35

3.Создание или приобретение компонент в соответствии

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

Эти действия в основном образуют стадию реализации.

4.Сборка системы из компонент и выполнение итогового тестирования системы.

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

Перечисленные выше действия обычно относят к основным действиям, поскольку они направлены непосредственно на получение продукта (ПО или ИС). К ним примыкают многие дополнительные действия, классифицируемые как вспомогательные и управляющие; знакомство с ними является полезным, поскольку иллюстрирует современный подход в разработке.

6.Создание и поддержка инфрастуктуры, требуемой для работы исполнителя над проектом, включая закупку и развертывание аппаратного и программного обеспечения, привлечение и обучение персонала и т.д.

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

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

36

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

Первой моделью, описывающей жизненный цикл, является каскадная модель Б. Боэма, предложенная в 1970 г. Существуют также ее модификации, в том числе спиральная модель, представленная тем же автором в 90-х годах. Подробное рассмотрение этих моделей выходит за пределы данного пособия, однако следует отметить, что основное достоинство первоначальной каскадной модели состоит в четкой идентификации этапов разработки ПО, разделении действий по этапам и регламентации условий перехода от одного этапа к следующему. До введения каскадной модели технология создания программ основывалась на наивном подходе, получившем историческое определение как модель «code-and-fix circle» – «программируем и исправляем ошибки, пока не заработает».

Существуют альтернативные модели разработки, основанные на концепции прототипирования, например технология RAD (Rapid Application Development). При использовании этих подходов сначала разрабатывается прототип – существенно упрощенная версия будущей системы, однако приемлемым способом описывающая ее планируемые функциональные свойства, а затем на его основе создается полноценная система.

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

1.Неправильная предварительная оценка трудозатрат, поскольку на начальных этапах трудно точно оценить масштаб системы и предвидеть возможные технические проблемы.

37

2.Наличие большого объема ручного неавтоматизировованного труда (например, написание программного кода), что способствует увеличению бюджета и провоцирует возникновение ошибок (т.е. снижает качество).

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

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

5.Отсутствие финансирования проекта в должных объемах.

6.Отсутствие у заказчика заинтересованности в успешном завершении проекта и в успешной эксплуатации системы.

7.Растущая конкуренция среди разработчиков и поставщиков ПО, что провоцирует урезание бюджетов и сроков выполнения.

Управление рисками на различных этапах выполнения проекта (идентификация потенциальных рисков, оценка степени их проявления, разработка мер по минимизации влияния на проект и др.) является одним из важнейших действий при разработке ПО и АИС.

Теперь перейдем к обсуждению процесса разработки приложений баз данных. Данный процесс включает две основных подзадачи: разработку собственно приложений и проектирование и создание базы данных.

Разработка приложений в узком смысле подразумевает создание программных модулей, которые будут непосредственно использоваться пользователями системы в повседневной деятельности при эксплуатации системы. Разработка приложений включает такие этапы, как проектирование и создание экранных форм для ввода-вывода данных, программирование обработки информации, создание макетов отчетов для распечатки результатов, создание интерфейсов с другими компонентами системы (например, подключение к каким-либо специализированным устройствам ввода-вы- вода) и т.д. При создании приложений используются современные языки программирования (например, VisualВasic, C++, Java) и соответствующие инструментальные системы

38

поддержки разработки (например, Microsoft Visual Studio). Подобные системы обладают чрезвычайно развитыми возможностями для упрощения и автоматизации создания приложений, включая такие традиционно трудоемкие действия, как создание экранных форм и разработка макетов отчетов.

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

1. Выбор целевой системы баз данных, подходящей для данного проекта, из перечня доступных. Это решение принимается на раннем этапе создания системы, и на него оказывают влияние различные факторы (технические, юридические, экономические, административные), например:

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

стоимость СБД и соотношение цена/свойства в сравнении с другими СБД;

наличие у исполнителя опыта разработки приложений для этой СБД;

обеспечение сервисного обслуживания со стороны поставщика СБД;

соответствие СБД предполагаемым требованиям касательно производительности, наличия инструментальных возможностей и прочих технических характеристик;

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

совместимость с информационными системами и компонентами, которые уже эксплуатируются в организации заказчика;

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

39

формально и неформально выраженные предпочтения заказчика.

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

3.Разработка схемы базы данных. Этот этап, сложным

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

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

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

6.Выполнение с экземпляром БД заказчика различных вспомогательных действий, в частности создание требуемых

40