<<
>>

2.2.4 Доступ к реляционной базе данных

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

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

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

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

Обозначим через А - имя неключевого атрибута, v - одно нз его значений, е - соответствующее значение первичного ключа и @ - однн нз знаков сравнения =,#,<,>,<=,>=. Когда величины е илн v должны быть найдены, они обозначаются знаком "?". Мы приходим к трем классам запросов: 1.

А(е) = ? - найтн значение атрибута по известному значению ключа; 2.

А(?) @ v - найтн запнсн с заданным значением неключевого атрибута.

3. А(?) = ? - перечислять значения данного атрибута для каждой записи.

Условия запросов второго типа могут комбинироваться с помощью логических связок "не", "и", "илн".

Введем понятия оболочки и входа запроса. Оболочкой запроса называется множество имен атрибутов, упоминаемых в формулировке запроса. Входом запроса называется множество имен атрибутов, для которых заданы условия вида А(?) @ v.

Рассмотрим пример запроса: какие предприятия, расположенные в Киеве, поставляют свою продукцию на завод ММЗ по железной дороге.

Оболочку запроса составляют атрибуты Предприятие (постаь- щик). Город (поставщика), Продукция, Завод (потребитель), Вид транспорта. Входом запроса являются атрибуты Город, Завод, Вид ^транспорта. Допустим, что запрос реализуется на отношении ЇЦПредлриятне, Город, Продукция, Завод, Вид_транспорта) с ключом Предприятие, Предукция, Завод. Атрибут Завод служит частью первичного ключа, следовательно, данный запрос относится к типу 2.

В~нашем примере выход запреса - Предприятие.

Формально будем записывать запрос в виде:

Выбрать Q, где Т @ t.

Через Т обозначены имена атрибутов входа запроса, t - нх значения, Q - множество атрибутов на выходе запроса (часть оболочки).

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

В словесной формулировке запроси выделить нмсна атрибутов, составляющие оболочку, вход и выход запроса, а также условия выборки. 2. Зафиксировать множество атрибутов оболочки. Если все необходимые атрибуты находятся в каком-то одном отношении, то последующие операция выборкн и проекции проводятся только с ним. Если требуемые атрибуты распределены по нескольким отношениям, то этн отношения необходимо Т 99 соединить. Каждая пара отношений соединяется по условию равенства атрибутов с совпадающими именами (или определенных иа общем домене).После каждого соединения с помощью проекции можно отсечь ненужные для последующих операций атрибуты. 3.

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

Если запрос можно разделить на части (подзапросы), то его реализация также разделяется на части, где результатом каждого подзапроса является отдельное отношение. 5.

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

Рассмотрим свойства соединений в базе данных с ЗНФ и в ациклической БД.

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

Однако оболочка запроса обычно содержит небольшое число атрибутов, н такое большое отношение требуется крайне редко. Для соединения (по условию равенства атрибутов) двух произвольных отношений из базы данных в ЗНФ справедлива следующая закономерность:

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

Для двух произвольных отношений R1,R2 рассмотрим X- значения из R1 и Х-значения из R2, обозначив их RI.Xh R2.X соответственно. 100

Введем 4 ролевые зависимости: 1.

Равенство. Множество Х-значений из R1 и множество Х-значений из R2 совпадают в каждый момент времени. 2.

Включение. Все значения R1.X содержатся в множестве значений R2.X. 3.

Частичное включение. Множества значений R1 .X и R2.X содержат общие элементы. 4.

Непересечение. Множества R1.X и R2.X не содержат общих элементов.

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

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

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

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

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

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

Пример

Рассмотрим систему отношений:

Деталь (Кодлетали, Название, Вес),

Поставщик (Код_поставщика, Вид_транспорта, Город),

Перевозка (Код_поставщика, Код_потребителя, Код_детали, Дата, Количество).

Примерами запросов, иллюстрирующих названные выше правила, могут служить: 1.

Получить коды всех поставляемых деталей.

Атрибут Код_детали встречается в отношениях Деталь и Перевозка.

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

use Перевозка

copy to R1 field Код_детали

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

Выделить коды всех поставщиков из Киева, перевозящих детали автотранспортом.

Список атрибутов в формулировке запроса содержит Код_по- ставщика, Город и Вид_транспорта, находящихся в одном отношении Поставщик. Поэтому запрос реализуется следующими командами:

use Поставщик

copy to R2 for Город="Киев"^лд.Вид_транспорта="автотранаюрт"; field Код_поставщика 3.

Получить названия деталей, поставляемых заводом Динамо (код завода "174432").

Атрибуты запроса Название и Код_поставщика находятся в разных отношениях (Деталь и Перевозка), следовательно, потребуется их соединение по атрибуту Код_детвлн.

use Перевозка

set filter to Код_поставщика=" 174432" select 2 use Деталь

join with Перевозка to R4;

for Кодлетали = Перевозка-Жод_детали field Название 4.

Получить коды всех поставщиков, поставляющих детали с кодом "1425" или "7252".

Необходимые атрибуты Код_поставщика и Код_детали находятся в отношении Перевозка:

use Перевозка

copy to R3 for Код_детали="1425".ог.Код_детали="7252", field Код_поставщика

Если список деталей достаточно длинный, то целесообразно хранить его в некотором отношении, например, 21(Код_дстали) и применять команды:

select 1

use Перевозка select 2 useZl

join with Перевозка to R4;

for Кодлетали = Перевозка->Код_летали field Код_поставщиха 5.

Получить коды всех поставщиков, поставляющих детали с кодом "1425" и "7252" одновременно.

Примечательно, что команды:

use Перевозка

copy to R5 for Код_детали=" 1425".and.Код^детали="7252"; field Код_поставщика

не формируют ответ на запрос (R5 будет пустым отношением). Можно рекомендовать, например, такие команды: select 1

use Перевозка

copy to W1 for Код_летали="1425" Код_поставщика copy to W2 for Код_летали="7252" field Код_поставщика use W1 select 2 use W2

join with W1 to R5 for Код_поставідика = W1 ->Код_поставщика

Если коды деталей находятся в некотором отношении, например в Z1, определенном в предыдущем примере, то необходимо применить операцию деления:

use Перевозка

copy to W1 field Код_поставщика, Код_детали

filel = "W1"

file2 = "Zl"

ШеЗ = "Yl"

attr = "Код_детали"

do divide with filel, file2, file3, attr 6.

Получить коды поставщиков, поставляющих все детали. Запрос разделяется на две части - получить список всех деталей (это результат первого запроса R1) и получить коды поставщиков (требуется деление):

use Перевозка

copy to W1 field Код_поставщика, Код^детали

filel = "W1"

file2 = "Rl"

ГіІеЗ = "Y2"

attr = "Код_детали"

do divide with filel, file2, file3, attr 7.

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

Атрибуты запроса Название и Город находятся в отношениях Деталь и Поставщик. Соединить их невозможно (отсутствуют общие атрибуты), но при использовании отношения Перевозка задача решается:

select 1

use Перевозка select 2 use Деталь

join with Перевозха to R4 for Кодлетали = Перевозка->Код_ детали;

field Код_ поставщика, Код_детали, Название use Поставщик select I use R4

join with Поставщик to RIO for Код_поставщика = Поставщик

->Код_поставщика;

field Кодлетали, Название, Город

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

Пусть необходимо выделить фамилии программистов, не знающих языка Фортран (см. пример из п. 2.1). Попытка воспользоваться операцией выборки: Y3 ФИО ЯП Иванов Си Иванов Паскаль Петров Си Петров Паскаль Семин Си Яшин Паскаль use Y

copy to Y3 for ЯП # "Фортран"

приводят к отношению Y3, показанному выше,

т. е. в ответ попали все программисты. Задача решается путем разделения запроса на части - из списка всех программистов вычесть список программистов, знающих язык Фортран.

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

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

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

Пример

Обозначим в R1: первичный ключ X через 1, неключевые атрибуты - через 2, в R2: X через 3, первичный ключ как 3,4, неключевые атрибуты - 5. Для R1 *R2 будут справедливы функциональные зависимости

1 —> 2; 3,4 —>5;3—1 —>3, откуда следует 3,4 -* 2. Таким образом, атрибуты 3,4 являются первичным ключом в RJ*R2.

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

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

<< | >>
Источник: Мишенин А. И.. Теория экономических информационных систем: Учебник. - 4-е изд., доп. и перераб. - М.: Финансы и статистика. - 240 с. 2002

Еще по теме 2.2.4 Доступ к реляционной базе данных:

  1. Чтение и изучение документов
  2. Базы данных 1. Правовые базы khimuv
  3. 2.1 РЕЛЯЦИОННАЯ МОДЕЛЬ ДАННЫХ
  4. Ациклические базы данных
  5. 2.2.4 Доступ к реляционной базе данных
  6. 2.3 СЕТЕВАЯ И ИЕРАРХИЧЕСКАЯ МОДЕЛИ ДАННЫХ
  7. 1. ПРЕДСТАВЛЕНИЕ О БАЗАХ ДАННЫХ
  8. 1.2 Основные понятия и предпосылки появления баз данных
  9. 1.5. Проектирование схем реляционных баз данных
  10. 1.6. Реляционная алгебра
  11. 2. СИСТЕМА БАЗ ДАННЫХ ACCESS
  12. 7.Содержание базы данных архивов
  13. § 5. Право изготовителя базы данных (статьи 1333 - 1336)
  14. Субъект права изготовителя базы данных (пункт 1 статьи 1333, статья 1336)
  15. Исключительное право изготовителя базы данных (пункты 1 и 2 статьи 1334)
  16. Системы управления базами данных (СУБД)
  17. Программное обеспечение экспертно-информационной системы
  18. «Нелегальные» базы данных