Основные требования к СУБД.

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

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

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

2.Актуальность хранимых данных. В любой момент времени ин­формация, содержащаяся в БД, должна быть современной.

3.Многоаспектное использование данных — поступление ин­формации из различных источников в единую БД и возможность ее использования любым отделом предприятия в соответствии с пра­вами доступа и функциями.

4.Возможность модификации системы — возможность ее расши­рения и модификации данных, а также дополнение новыми функ­циями без ущерба для системы в целом.

5.Надежность — целостность БД не должна нарушаться при технических сбоях.

6.Скорость доступа — обеспечение быстрого доступа к требуе­мой информации.

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

СУБД обеспечивают надежное хранение больших объемов дан­ных сложной структуры во внешней памяти компьютера и эффек­тивный доступ к ним. К основным функциям СУБД относятся:

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

· поддержание целостности данных и управление транзак­циями;

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

· реализация поддержки языка описания данных и языка за­просов;

· обеспечение безопасности данных;

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

АРХИТЕКТУРА БАЗ ДАННЫХ

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

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

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

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

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

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

• обследование программного обеспечения.

На этапе реализации производится создание БД и разработка программ (приложений) в выбранной СУБД.

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

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

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

Цели и задачи системы определяют заказчики. Они предоставляют разработчику все сведения о бизнес-процессах и характеристики моделируемых объектов.

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

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

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

• контроль за непротиворечивостью и достоверностью данных;

• анализ эффективности использования ресурсов ИС;

• координация работы системных программистов по улучшению эксплуатационных характеристик системы;

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

ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ

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

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

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

На следующем шаге принимается решение о том, в какой конкретно СУБД будет реализована БД.

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

• удобство и простота использования;

• качество средств разработки, защиты и контроля БД;

• уровень коммуникационных средств (в случае применения ее в сетях);

• фирма-разработчик;

• стоимость.

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

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

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

ДОСТОИНСТВА РЕЛЯЦИОННОЙ МОДЕЛИ

• Простота и доступность для понимания конечным пользователем. Единственной информационной конструкцией является таблица.

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

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

• Для построения запросов и написания прикладных программ нет необходимости знания конкретной организации БД во внешней памяти.

НЕДОСТАТКИ РЕЛЯЦИОННОЙ МОДЕЛИ

• По сравнению с другими моделями реляционная модель имеет более низкую скорость доступа и требует большего объема внешней памяти.

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

• Не всегда предметную область можно представить в виде совокупности таблиц.

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

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

ПОНЯТИЕ ОБ ИНДЕКСИРОВАНИИ

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

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

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

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

РАЗДЕЛЕНИЕ ТАБЛИЦ

Разделение (разбиение) таблиц в целях ускорения работы системы может быть горизонтальным или вертикальным.

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

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

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