Системы управления базами данных. Основные этапы проектирования базы данных

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

Классифицируют СУБД по различным признакам, основные из которых

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

Универсальность, в соответствии с которой СУБД делят на два класса:

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

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

Уровень использования. К этому классу относятся:

1. Профессиональные (промышленные) СУБД, представляющие собой программную основу для разработки автоматизированных систем управления крупными предприятиями, на базе которых создаются комплексы управления и обработки информации. Главными условиями, которым должны удовлетворять профессиональные СУБД, являются:

- возможность организации совместной параллельной работы большого количества пользователей;

- масштабируемость, т.е. возможность роста системы пропорционально расширению управляемого объекта;

- переносимость на различные аппаратные и программные платформы;

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

- обеспечение безопасности хранимых данных и развитой структурированной системы доступа к ним.

2. Персональные (настольные) СУБД – программное обеспечение, ориентированное на решение задач локального пользователя или компактной группы пользователей, и предназначенное для использования на ПК. Определяющими характеристиками настольных систем являются:

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

- относительно ограниченные требования к аппаратным ресурсам.

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

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

- наличие инструментов создания объектов базы данных в режиме диалога;

- наличие развитого инструментария создания программных расширений в рамках единой среды СУБД;

- встроенная поддержка универсальных языков управления данными и т.д.

К основным функциям, которые реализуются СУБД относятся – управление данными во внешней памяти, управление буферами оперативной памяти, управление транзакциями, журнализация, поддержка языков БД.

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

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

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

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

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

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

Обычно рассматриваются два возможных вида аппаратных сбоев:

- «мягкие» сбои, которые можно трактовать как внезапную остановку работы ПК. Например, аварийное выключение питания, аварийное завершение работы СУБД или пользовательской программы из-за ошибки в ПО или аппаратного сбоя, что влечет за собой незавершенность какой-либо транзакции;

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

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

Во всех случаях СУБД используют стратегию «упреждающей» записи в журнал (протокол Write Ahead Log – WAL), которая заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно восстановить БД после любого сбоя.

Поддержка языков БД. Для работы с БД используются специальные языки, в целом называемые языками баз данных. В ранних СУБД поддерживалось несколько специализированных по своим функциям языков. Чаще всего выделялись два языка – язык определения схемы БД (SDL – Schema Definition Language) и язык манипулирования данными (DML - Data Manipulation Language).

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

Язык манипулирования данными (ЯМД, DML) содержал набор операторов манипулирования данными, т.е. операторов, позволяющих заносить данные в БД, удалять, модифицировать или выбирать существующие данные.

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

- Стандартность. Использование языка SQL в программах стандартизировано международными организациями.

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

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

- Реляционная основа языка привела к широкому распространению SQL в связи с большой распространенностью реляционных БД.

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

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

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

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

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

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

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

До начал 90-х годов существовало несколько разных поставщиков БД, каждый из которых имел собственный интерфейс. Если приложению было необходимо обмениваться данными с несколькими источниками данных, для взаимодействия с каждой из БД было необходимо написать отдельный код. С целью решения этой проблемы Microsoft и ряд других компаний создали стандартный интерфейс для получения и отправки данных источникам данных различных типов. Этот интерфейс получил название Open Data Base Connectivity (ODBC). С помощью ODBC специалисты смогли разрабатывать приложения с использованием единого интерфейса доступа к данным, не учитывая тонкости взаимодействия с различными источниками данных.

К основным интерфейсам СУБД можно отнести – интерфейс прямого доступа, языки баз данных, интерфейсы уровня обращения и объектные интерфейсы.

Интерфейс прямого доступа обеспечивает прямой доступ к СУБД – или через дополнительные библиотеки того языка, на котором написана СУБД, или через специальный язык программирования (компилятор и/или интерпретатор которого поставляется разработчиками СУБД).

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

Рисунок 7.21 – Пример обобщенной структуры СУБД

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

Интерфейсы уровня обращения. Чаще всего языки БД используются в так называемых интерфейсах уровня обращения (CLI – Call Level Interface). Для современных языков программирования существуют библиотеки, которые позволяют обращаться через эти интерфейсы к СУБД, пересылая туда инструкции языков БД и получая результаты некоторых запросов в виде специальных структур языка программирования. Производители СУБД поставляют свои библиотеки CLI, оптимизированные для собственных продукта, однако в последнее время наметилась тенденция к стандартизации этих библиотек. Если программисты используют стандартный интерфейс уровня обращения и придерживаются стандарта языка БД, то их приложение сможет работать с разными СУБД.

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

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

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

Web-интерфейсы используются при разработки некоторых приложений Internet. СУБД в этом случае имеет средства взаимодействия с Internet, которые предоставляют результаты запросов к ней вместе с атрибутами их визуального представления, а программисту остаётся задать правила для формирования этих атрибутов. На практике эти результаты отображаются Web-браузером в виде страницы на одном из языков разметки (HTML или XML).

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

Ядро СУБД отвечает за управление данными во внешней памяти, управление буферами оперативной памяти, управление транзакциями и журнализацией. Соответственно, можно выделить такие компоненты ядра, как менеджер данных, менеджер буферов, менеджер транзакций и менеджер журнала. Функции этих компонентов взаимосвязаны, и для обеспечения корректной работы СУБД они должны взаимодействовать по соответствующим протоколам. Ядро СУБД обладает собственным интерфейсом, не доступным пользователям напрямую и используемым в программах, производимых компилятором SQL (или в подсистеме поддержки выполнения таких программ) и утилитах БД. Ядро СУБД является основной резидентной частью СУБД. При использовании архитектуры «клиент-сервер» ядро является основной составляющей серверной части системы.

3. Компилятор. Основной функцией компилятора языка БД является преобразование (перевод) операторов языка БД в выполняемую программу.

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

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

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

5. Словари-справочники данных (ССД) – это совокупность информационных средств, предназначенная для централизованного хранения и использования описания объектов БД (метаданных – информации о данных).

Словари-справочники данных содержат сведения:

- о составе и структуре базы данных;

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

- об ограничениях целостности;

- о вспомогательных объектах и компонентах ИТ.

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

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

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

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

Этапы проектирования БД связаны с многоуровневой организацией данных, которые включают внешний, инфологический, логический (даталогический) и внутренний (см. рис. 7.22).

Рисунок 7.22 – Многоуровневая организация данных БД

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

- формы документирования и представления данных;

- функционирование объекта управления, для которого проектируется БД;

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

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

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

Как правило, внешний уровень – это словесное описание входных и выходных сообщений, а также данных, которые целесообразно сохранять в БД.

Существуют два подхода к проектированию баз данных на внешнем уровне: «от предметной области» и «от запроса».

• «От предметной области» состоит в том, что формируется внешнее информационное обеспечение всей предметной области без учета потребностей пользователей и прикладных программ. Иногда этот подход называют еще объектным или непроцессным. Преимуществами такого подхода являются объективность, системность при отображении ПО и стойкость информационной модели, возможность реализации большого количества прикладных программ и запросов, в том числе незапланированных при создании БД. Недостатком этого подхода является значительный объем работ, которые необходимо выполнить при определении информации подлежащей хранению в БД, что, соответственно, усложняет и увеличивает срок разработки проекта.

• «От запроса» включает изучение запросов пользователей и потребностей прикладных программ. Этот подход также называется процессным или функциональным. При его использовании БД проектируется для выполнения текущих задач управления без учета возможности расширения ИТ и возникновения новых задач управление. К недостаткам подхода можно отнести возникновение сложностей в агрегации требований разных пользователей и прикладных программ. Тем не менее, следует отметить, значительное уменьшение трудоемкости проектирования, и возможность создания системы с высокими эксплуатационными характеристиками.

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

Описание внешнего уровня не исключает наличия элементов дублирования, избыточности и несогласованности данных. Поэтому для устранения этих противоречий внешнего описания данных выполняется инфологическое проектирование.

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

Существует три основных подхода к инфологическому проектированию:

анализ объектов, синтез атрибутов и смешанная стратегия проектирования.

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

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

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

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

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

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

Внутренний уровень связан с физическим размещением данных в памяти вычислительной машины. На этом уровне формируется физическая модель БД, которая включает структуры сохранения данных в памяти ЭВМ, в т.ч. описание форматов записей, последовательность их логического или физического приведения в порядок, размещение по типам устройств, а также характеристики и пути доступа к данным. От параметров физической модели зависят такие характеристики функционирования БД, как объем памяти и время реакции системы. Физические параметры БД можно изменять в процессе ее эксплуатации с целью повышения эффективности функционирование СУБД. При этом изменение физических параметров не требует изменения инфологической и даталогической моделей.

Процесс проектирования БД ориентирован на все уровни организации данных и должен включать следующие этапы, представленные на рис. 7.23.

Рисунок 7.23 – Этапы проектирования баз данных

1. Инфологическое (концептуальное) проектирование, т.е. определение предметной области системы, позволяющее изучить информационные потребности будущих пользователей. На этом этапе формируется задание по созданию БД. В нем подробно описывается состав базы, назначение и цели ее создания, а также перечисляется, какие виды работ предполагается осуществлять в этой базе данных (отбор, дополнение, изменение данных, печать или вывод отчета и т. д.). Кроме того, на этапе инфологического проектирования (для многопользовательских БД) необходимо также определить приемлемый вариант декомпозиции единой базы данных на «логические» фрагменты, которые будут размещаться в различных узлах сети с учетом требований специалистов и менеджеров.

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

3. Выбор СУБД и других инструментальных программных средств ее реализации. Этот этап является одним из важнейших моментов в разработке

проекта БД, так как он принципиальным образом влияет на весь процесс проектирования БД и реализацию информационной системы. При выборе СУБД нужно принимать во внимание:

- тип модели данных, которую поддерживает СУБД, её адекватность потребностям рассматриваемой предметной области;

- характеристики производительности СУБД;

- запас функциональных возможностей для дальнейшего развития ИТ в менеджменте;

- степень оснащённости системы инструментарием для персонала администрирования данными;

- удобство и надежность СУБД в эксплуатации;

- стоимость СУБД и дополнительного программного обеспечения.

4. Логическое проектирование базы данных заключается в разработке ее «логической» структуры в соответствии с инфологической моделью предметной области. Результатом выполнения этого этапа являются схемы БД концептуального и внешнего уровней архитектуры, составленные на языках определения данных, поддерживаемых выбранной СУБД

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

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

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

Жизненный цикл базы данных – это совокупность этапов, которые проходит база данных на своём пути от создания до окончания использования.

Жизненный цикл БД обычно состоит из нескольких этапов – планирование, сбор и анализ требований, проектирование, создание прототипа, реализация, тестирование, преобразование данных и сопровождение. Проектирование БД в этом случае становится одним из этапов всего жизненного цикла базы данных (см. рис. 7 24).

Рисунок 7.24 – Жизненный цикл базы данных

Следует отметить, что этапы, представленные на рис. 7.24, не являются строго последовательными, а предусматривают в некоторых случаях возврат к предыдущим с помощью обратных связей (feedback loops), которые могут возникать почти между всеми этапами, но на рисунке показаны только наиболее важные из них. Основные характеристики этапов жизненного цикла БД, приведены в табл. 7.2.

Таблица 7.2 – Характеристики этапов жизненного цикла БД

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

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

Дата добавления: 2014-01-11