Реляционные базы данных

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

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

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

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

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

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

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

- стоимость.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      4. Разработка баз  данных

      4.1. Постановка задачи. Требования к информационным системам (ИС)

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

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

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

     В реализации заказа принимает участие сотрудник туристического агентства.

     В функции ИС входит, например, получение  информации по следующим четырем пунктам.

     1. Клиенты:

• о клиентах агентства для реализации контактной деятельности;
• о постоянных клиентах агентства;
• о клиентах, дающих наибольший доход.

     2. Договор:

• о платежах по договору;
• о турах, пользующихся наибольшим спросом;
• о турах, приносящих наибольший доход.

     3. Контроль исполнения:

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

     4. Бизнес-анализ:

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

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

      4.2 Проектирование базы  данных

     КОНЦЕПТУАЛЬНАЯ  МОДЕЛЬ БАЗЫ ДАННЫХ. Первый этап проектирования заключается в описании объектов БД (сущностей), определении их атрибутов и в установлении связей между сущностями. Для БД туристического агентства можно задать такие атрибуты сущностей:

 

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

ЛОГИЧЕСКАЯ МОДЕЛЬ РЕЛЯЦИОННОЙ БАЗЫ ДАННЫХ. Логическая модель строится на основе концептуальной. Для реляционной модели данных каждая сущность преобразуется в набор отношений (таблиц), построенных по определенным строго заданным правилам. Таблица состоит из столбцов (полей) и строк (записей).

Для этого  требуется выполнить следующие  действия:

1. Создать по одной таблице для каждой сущности.
2. Для каждой сущности, выступающей во взаимоотношениях с другими сущностями как «один-ко-многим» или «один-к-одному», указать один столбец в качестве первичного ключа.
3. Задать первичный ключ для каждой сущности, выступающей во взаимоотношениях как «многие-к-одному».

      Проведем  это преобразование для нашего примера.

1. На основе концептуальной модели можно создать четыре таблицы: Сотрудники, Клиенты, Страны, Договоры.
2. Зададим первичные ключи для таблиц Договоры, Клиенты, Страны и Сотрудники, выступающих в связях как «один-ко-многим».

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

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

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