2.1 Общее определение системы баз данных

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

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

Рисунок 2.1 - Упрощенная схема системы баз данных

Система управления базами данных (СУБД)

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

Аппаратное обеспечение системы имеет следующее разделение:

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

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

Между собственно физической базой данных (т.е. данными, которые реально хранятся на компьютере) и пользователями системы располагается уровень программного обеспечения, который можно называть по-разному: диспетчер базы данных (database manager), сервер базы данных (database server) или, что более привычно, система управления базами данных, СУБД (DataBase Management System DBMS). Все запросы пользователей на получение доступа к базе данных обрабатываются СУБД. Все имеющиеся средства добавления файлов (или таблиц), выборки и обновления данных в этих файлах или таблицах также предоставляет СУБД. Основная задача СУБД дать пользователю базы данных возможность работать с ней, не вникая во все подробности работы на уровне аппаратного обеспечения. (Пользователь СУБД более отстранен от этих подробностей, чем прикладной программист, применяющий языковую среду программирования.) Иными словами, СУБД позволяет конечному пользователю рассматривать базу данных как объект более высокого уровня по сравнению с аппаратным обеспечением, а также предоставляет в его распоряжение набор операций, выражаемых в терминах языка высокого уровня (например, набор операций, которые можно выполнять с помощью языка SQL.

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

Первая группа пользователей прикладные программисты, которые отвечают за написание прикладных программ, использующих базу данных. Для этих целей применимы такие языки, как COBOL, PL/I, C++, Java, PHP и другие. Прикладные программы получают доступ к базе данных посредством выдачи соответствующего запроса к СУБД (обычно это некоторый оператор SQL). Подобные программы могут быть простыми пакетными приложениями или же интерактивными приложениями, предназначенными для поддержки работы конечных пользователей. В последнем случае они предоставляют пользователям непосредственный оперативный доступ к базе данных через рабочую станцию, терминал или персональный компьютер. Большинство современных приложений относится именно к этой категории.

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

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

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

2.2 Назначение баз данных

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

Преимущества системы с БД по сравнению с традиционным «бумажным» методом ведения учета записей:

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

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

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

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

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

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

2.3 Преимущества подхода, предусматривающего использование базы данных

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

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

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

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

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

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

Обеспечение целостности данных - задача обеспечения целостности заключается в гарантированной поддержке правильности данных в базе (насколько это возможно). Противоречие между двумя записями, представляющими один "факт", является примером утраты целостности данных. Конечно, эта конкретная проблема может возникнуть лишь при наличии избыточности в хранимых данных. Но даже если избыточность отсутствует, база данных может содержать неправильную информацию. Например, в базе данных может быть указано, что сотрудник отработал 400 рабочих часов в неделю вместо 40, или зафиксирована его принадлежность к отделу, которого не существует. Централизованное управление базой данных позволяет избежать подобных проблем (насколько это вообще возможно). Для этого администратор данных определяет (а администратор базы данных реализует) ограничения целостности (integrity constraints), которые будут применяться при любой попытке внести какие-либо изменения в соответствующие данные.

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

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

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

2.4 Классификация СУБД

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

К основным функциям СУБД относится:

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

- управление данными в оперативной памяти;

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

- поддержка языков БД (язык определения данных, язык манипулирования данными).

Обычно современная СУБД содержит следующие компоненты:

- ядро, которое отвечает за управление данными во внешней и оперативной памяти и журнализацию;

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

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

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

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

По типу управляемой базы данных СУБД разделяются на:

- сетевые;

- иерархические;

- реляционные;

- объектно-реляционные;

- объектно-ориентированные.

К основным понятиям сетевой модели базы данных относятся: уровень, элемент (узел), связь.

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

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

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

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

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

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

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

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

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

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

Реляционная СУБД (РСУБД; иначе Система управления реляционными базами данных, СУРБД) СУБД, управляющая реляционными базами данных.

Понятие реляционный (англ. relation отношение) связано с разработками известного английского специалиста в области систем баз данных Эдгара Кодда (Edgar Codd).

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

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

- каждый элемент таблицы -- один элемент данных;

- все столбцы в таблице однородные, то есть все элементы в столбце имеют одинаковый тип (числовой, символьный и т. д.);

- каждый столбец имеет уникальное имя;

- одинаковые строки в таблице отсутствуют;

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

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

Объектно-реляционная СУБД (ОРСУБД) реляционная СУБД (РСУБД), поддерживающая некоторые технологии, реализующие объектно-ориентированный подход.

Разница между объектно-реляционными и объектными СУБД: первые являют собой надстройку над реляционной схемой, вторые же изначально объектно-ориентированы. Главная особенность и отличие объектно_реляционных, как и объектных, СУБД от реляционных заключается в том, что ОРСУБД интегрированы с объектно-ориентированным (OO) языком программирования, внутренним или внешним как C++, Java. Характерные свойства OРСУБД - комплексные данные, наследование типа, и объектное поведение.

Комплексные данные могут быть реализованы через постоянно-хранимые объекты (persistent objects). Создание комплексных данных в большинстве существующих ОРСУБД основано на предварительном определении схемы через определяемый пользователем тип (UDT ? user_defined type). Используются также встроенные конструкторы составных типов, например массив (ARRAY).

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

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

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

По архитектуре организации хранения данных СУБД делятся на:

- локальные СУБД (все части локальной СУБД размещаются на одном компьютере);

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

По способу доступа к БД СУБД подразделяются на:

- файл-серверные;

- клиент-серверные;

- встраиваемые.

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

Клиент-серверные СУБД состоят из клиентской части (которая входит в состав прикладной программы) и сервера. Клиент-серверные СУБД, в отличие от файл-серверных, обеспечивают разграничение доступа между пользователями и мало загружают сеть и клиентские машины. Сервер является внешней по отношению к клиенту программой, и по надобности его можно заменить другим. Недостаток клиент-серверных СУБД в самом факте существования сервера (что плохо для локальных программ в них удобнее встраиваемые СУБД) и больших вычислительных ресурсах, потребляемых сервером. Примерами данной СУБД являются такие системы, как Firebird, Interbase, MS SQL Server, Oracle, PostgreSQL, MySQL.

Встраиваемая СУБД библиотека, которая позволяет унифицированным образом хранить большие объёмы данных на локальной машине. Доступ к данным может происходить через SQL либо через особые функции СУБД. Встраиваемые СУБД быстрее обычных клиент-серверных и не требуют установки сервера, поэтому востребованы в локальном ПО, которое имеет дело с большими объёмами данных (например, геоинформационные системы). Примерами данной СУБД являются такие системы, как OpenEdge, SQLite, BerkeleyDB, один из вариантов Firebird, один из вариантов MySQL, Sav Zigzag [5].

2.5 Этапы проектирования систем реляционных баз данных

Разработка систем реляционных баз данных включает два основных этапа:

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

логическое проектирование.

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

Рассмотрим две важнейшие стадии этапа концептуального проектирования БД.

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

? имя объекта данных;

? имя элемента данных, источник, атрибуты;

? используемость, ограничения, показатель важности;

? взаимосвязи;

? продолжительность хранения и др.

Второй стадией является организация хранения данных. На этой стадии обычно разрабатывается графическая схема объектов и элементов данных:

? исходные данные;

? формирующие их подразделения или виды деятельности;

? результирующие данные;

? использующие их подразделения.

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

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

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

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

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

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

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

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

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

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

2.6 Выбор СУБД

При разработке сложных проектов неизбежно возникает необходимость использования базы данных, но на какой из существующих СУБД остановить свой выбор? Выбор не так уж и мал: mSQL, PostgreSQL, Oracle, MS SQL и другие. В разрабатываемом приложении в будущем планируется дополнения и усовершенствования. Вследствие чего, при охвате приложением всего предприятия, оно будет помещаться на хостинг. Практически любой приемлемый хостинг, который предоставляет стандартные услуги, включает в них несколько баз данных MySQL. Основанием для этого служит ряд немаловажных причин, и одной из них является то, что MySQL является продуктом класса Open Source (открытые исходные тексты), который можно получить бесплатно (для платформы Windows есть некоторые оговорки). Как правило, сервер и клиент MySQL входят в любой дистрибутив операционных систем семейства BSD (FreeBSD, NetBSD, OpenBSD) и Linux, которые используются на большинстве веб-серверов.

MySQL - это одна из самых популярных и самых распространенных СУБД (система управления базами данных) в интернете. Она не предназначена для работы с большими объемами информации, но ее применение идеально для интернет сайтов, как небольших, так и достаточно крупных. MySQL отличатся хорошей скоростью работы, надежностью, гибкостью. Работа с ней, как правило, не вызывает больших трудностей. Поддержка сервера MySQL автоматически включается в поставку PHP. Немаловажным фактором является ее бесплатность. MySQL распространяется на условиях общей лицензии GNU (GPL, GNU Public License) [6].

Другая немаловажная причина популярности MySQL заключается в том, что ее создатели с самого начала разработки этой СУБД поставили во главу угла ее быстродействие, пожертвовав при этом некоторыми удобствами для разработчиков. Связка PHP + MySQL обеспечивают очень высокое быстродействие, которого трудно достичь другими средствами. Очень хорошая связь MySQL с PHP стала еще одной причиной популярности этой СУБД. Поддержка MySQL входит в стандартную сборку PHP, и можно быть уверенным, что проблем обращения к серверу MySQL из PHP-скриптов не будет. Для обеспечения взаимодействия PHP с другими СУБД (PostgreSQL, Oracle и так далее) приходится компилировать его самостоятельно из исходных кодов с дополнительными опциями. Таким образом, можно считать, что дешевизна, легкодоступность, производительность и тесная взаимосвязь с PHP и обеспечивают такую популярность MySQL.

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