ЛЕКЦИЯ 4

· ОСНОВНЫЕ ПОНЯТИЯ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ

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

Для начала покажем смысл этих понятий на примере отношения СЛУЖАЩИЕ, содержащего информацию о служащих некоторого предприятия (рис. 1).

Рис. 2.1.

· Тип данных

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

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

В примере на рис. 1 мы имеем дело с данными трех типов : строки символов, целые числа и «деньги».

· Домен

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

Наиболее правильной интуитивной трактовкой понятия домена является его восприятие как допустимого потенциального, ограниченного подмножества значений данного типа. Например, домен ИМЕНА в нашем примере определен на базовом типе символьных строк, но в число его значений могут входить только те строки, которые могут представлять имена (в частности, для возможности представления русских имен такие строки не могут начинаться с мягкого или твердого знака и не могут быть длиннее, например, 20 символов). Если некоторый атрибут отношения определяется на некотором домене (как, например, на рис. 1 атрибут СЛУ_ИМЯ определяется на домене ИМЕНА ), то в дальнейшем ограничение домена играет роль ограничения целостности , накладываемого на значения этого атрибута .

Следует отметить также семантическую нагрузку понятия домена : данные считаются сравнимыми только в том случае, когда они относятся к одному домену . В нашем примере значения доменов НОМЕРА ПРОПУСКОВ и НОМЕРА ОТДЕЛОВ относятся к типу целых чисел, но не являются сравнимыми (допускать их сравнение было бы бессмысленно).

· Элементы отношения

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

Итак, заголовком (или схемой) отношения r (Hr ) называется конечное множество упорядоченных пар вида , где A называется именем атрибута , а T обозначает имя некоторого базового типа или ранее определенного домена . По определению требуется, чтобы все имена атрибутов в заголовке отношения были различны. В примере на рис. 2.1 заголовком отношения СЛУЖАЩИЕ является множество пар {<слу_номер, номера_пропусков>, <слу_имя, имена>, <слу_зарп, размеры_выплат>, <слу_отд_номер, номера_отделов>} .

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

Кортежем tr , соответствующим заголовку Hr , называется множество упорядоченных триплетов вида , по одному такому триплету для каждого атрибута в Hr . Третий элемент – v – триплета должен являться допустимым значением типа данных или домена T . Заголовку отношения СЛУЖАЩИЕ соответствуют, например, следующие кортежи : {<слу_номер, номера_пропусков, 2934>, <слу_имя, имена, Иванов>, <слу_зарп, размеры_выплат, 22.000>, <слу_отд_номер, номера_отделов, 310>} , {<слу_номер, номера_пропусков, 2940>, <слу_имя, имена, Кузнецов>, <слу_зарп, размеры_выплат, 35.000>, <слу_отд_номер, номера_отделов, 320>} .

Телом Br отношения r называется произвольное множество кортежей tr . Одно из возможных тел отношения СЛУЖАЩИЕ показано на рис. 2.1. Заметим, что в общем случае, как это демонстрируют, в частности, рис. 2.1 и пример предыдущего абзаца, могут существовать такие кортежи tr , которые соответствуют Hr , но не входят в Br .

Значением Vr отношения r называется пара множеств Hr и Br . Одно из допустимых значений отношения СЛУЖАЩИЕ показано на рис. 2.1.

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

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

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

По определению, степенью, или «арностью» , заголовка отношения , кортежа , соответствующего этому заголовку , тела отношения , значения отношения и переменной отношения является мощность заголовка отношения . Например, степень отношения СЛУЖАЩИЕ равна четырем, т. е. оно является 4-арным (кватернарным ).

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

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

· Первичный ключ

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

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

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

· Фундаментальные свойства отношений

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

Отсутствие кортежей-дубликатов,
первичный и возможные ключи отношений

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

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

Конечно, могут существовать значения отношения с несколькими несовпадающими минимальными наборами атрибутов , обладающими свойствами уникальности. Например, если вернуться к предположениям лекции 1 об уникальности значений атрибутов СЛУ_НОМЕР и СЛУ_ИМЯ отношения СЛУЖАЩИЕ , то для каждого значения этого отношения мы имеем два множества атрибутов , претендующих на звание первичного ключа – {СЛУ_НОМЕР} и {СЛУ_ИМЯ} . В этом случае проектировщик базы данных должен решить, какое из альтернативных множеств атрибутов назвать первичным ключом , а остальные минимальные наборы атрибутов , обладающие свойством уникальности, называются возможными ключами 1) .

Понятие первичного ключа является исключительно важным в связи с понятием целостности баз данных . Заметим, что хотя формально существование первичного ключа значения отношения является следствием того, что тело отношения – это множество, на практике первичные (и возможные ) ключи переменных отношений появляются в результате явных указаний проектировщика отношения . Определяя переменную отношения , проектировщик моделирует часть предметной области, данные из которой будет содержать база данных . И конечно, проектировщик должен знать природу этих данных. Например, ему должно быть известно, что никакие два служащих ни в какой момент времени не могут иметь удостоверение с одним и тем же номером. Поэтому он может (и даже должен, как будет показано немного позже) явно объявить {СЛУ_НОМЕР} возможным ключом . Если на предприятии установлено, что у всех служащих должны быть разные полные имена, то проектировщик может (и опять же должен) объявить возможным ключом и {СЛУ_ИМЯ} . Затем проектировщик должен оценить, какой из возможных ключей является более надежным (свойство его уникальности никогда не будет отменено) и выбрать наиболее надежный возможный ключ в качестве первичного (в нашем случае естественным выбором был бы ключ {СЛУ_НОМЕР} , потому что решение об уникальности полных имен служащих выглядит искусственным и может быть легко отменено руководством предприятия).

Теперь поясним, почему проектировщику следует явно объявлять первичный и возможные ключи переменных отношений 2) . Дело в том, что в результате этого объявления СУБД получает информацию, которая в дальнейшем будет использоваться как ограничения целостности 3) . СУБД никогда не допустит появления в переменной отношения значения-отношения , содержащего два кортежа с одинаковым значением атрибута СЛУ_НОМЕР (определение первичного ключа для данной переменной отношения отменить нельзя). Появление двух кортежей с одинаковым значением атрибута СЛУ_ИМЯ будет также невозможно до тех пор, пока остается в силе определение {СЛУ_ИМЯ} как возможного ключа . Тем самым объявления первичного и возможных ключей дают СУБД возможность поддерживать целостность базы данных даже в случае попыток занесения в нее некорректных данных.

Наконец, вернемся к свойству минимальности первичного и возможных ключей . Как отмечалось выше, это свойство является критически важным, и важность проявляется именно при трактовке первичного и возможных ключей как ограничений целостности . В нашем примере с отношением СЛУЖАЩИЕ свойством уникальности будет обладать не только множество атрибутов {СЛУ_НОМЕР} , но и, например, множество {СЛУ_НОМЕР, СЛУ_ОТД_НОМЕР} . Но если бы мы выставили в качестве ограничения целостности требование уникальности {СЛУ_НОМЕР, СЛУ_ОТД_НОМЕР} , то СУБД гарантировала бы отсутствие кортежей с одинаковым значением атрибута СЛУ_НОМЕР не во всем значении отношения СЛУЖАЩИЕ , а только в группах кортежей с одним и тем же значением атрибута СЛУ_ОТД_НОМЕР . Понятно, что это не соответствует смыслу моделируемой предметной области.

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

Отсутствие упорядоченности кортежей

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

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

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

Отсутствие упорядоченности атрибутов

Атрибуты отношений не упорядочены, поскольку по определению заголовок отношения есть множество пар <имя атрибута, имя домена> . Для ссылки на значение атрибута в кортеже отношения всегда используется имя атрибута . Легко заметить явную аналогию между заголовками отношений и структурными типами в языках программирования. Даже в языке программирования C с его практически неограниченными возможностями работы с указателями настойчиво рекомендуется обращаться к полям структур только по их именам. Если, например, на языке C определена структурная переменная

struct {int a; char b; int c} d;

то в стандарте языка решительно не рекомендуется использовать для доступа к символьному полю b конструкцию *(&d + sizeof(int)) (взять адрес структурной переменной d , прибавить к нему число байтов в целом числе и взять значение байта по полученному адресу). Это объясняется тем, что при реальном расположении в памяти полей такой структурной переменной в том порядке, как они определены, во многих компьютерах потребуется выровнять поле c по байту с четным адресом. Поэтому один байт просто пропадет. При расположении структурной переменной в памяти экономный компилятор (вернее, оптимизатор) переставит местами поля b и c , и указанная выше конструкция не обеспечит доступа к полю b . Для корректного обращения к полю b переменной d нужно использовать конструкции d.b или &d->b , т. е. явно указывать имя поля.

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

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

Атомарность значений атрибутов
Первая нормальная форма отношения

Значения всех атрибутов являются атомарными (вернее, скалярными). Это следует из определения домена как потенциального множества значений скалярного типа данных , т. е. среди значений домена не могут содержаться значения с видимой структурой, в том числе множества значений (отношения ). Заметим, что это не противоречит тому, что говорилось в разделе «Основные понятия реляционных баз данных» о потенциальной возможности использования при спецификации атрибутов типов данных , определяемых пользователями. Например, можно было бы добавить в схему отношения СЛУЖАЩИЕ атрибут СЛУ_ФОТО , определенный на домене (или типе данных ) ФОТОГРАФИИ . Главное в атомарности значений атрибутов состоит в том, что реляционная СУБД не должна обеспечивать пользователям явной видимости внутренней структуры значения. Со всеми значениями можно обращаться только с помощью операций, определенных в соответствующем типе данных .

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

Пример ненормализованного отношения показан на рис. 2.2. Можно сказать, что здесь мы имеем бинарное отношение , в котором значениями атрибута ОТДЕЛЫ являются отношения . Заметим, что исходное отношение СЛУЖАЩИЕ является нормализованным вариантом отношения ОТДЕЛЫ-СЛУЖАЩИЕ . Нормализованный вариант показан на рис. 2.3.

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

n зачислить служащего Кузнецова (пропуск номер 3000, зарплата 25000.00) в отдел номер 320;

n зачислить служащего Кузнецова (пропуск номер 3000, зарплата 25000.00) в отдел номер 310.

Рис. 2.

Рис. 3. Отношение СЛУЖАЩИЕ: нормализованный вариант
отношения ОТДЕЛЫ-СЛУЖАЩИЕ

Если информация о служащих представлена в виде отношения СЛУЖАЩИЕ , оба оператора будут выполняться одинаково (вставить кортеж в отношение СЛУЖАЩИЕ ). Если же работать с ненормализованным отношением ОТДЕЛЫ-СЛУЖАЩИЕ , то первый оператор приведет к простой вставке кортежа , а второй – к добавлению кортежа в значение-отношение атрибута ОТДЕЛ кортежа с первичным ключом 310 .

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

· Реляционная модель данных

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

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

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

Общая характеристика

Хотя понятие реляционной модели данных первым ввел основоположник реляционного подхода Эдгар Кодд, наиболее распространенная трактовка реляционной модели данных , по-видимому, принадлежит известному популяризатору идей Кодда Кристоферу Дейту, который воспроизводит ее (с различными уточнениями) практически во всех своих книгах (см., например, К. Дейт. Введение в системы баз данных. 6-е изд., М.; СПб.: Вильямс.– 2000). Согласно трактовке Дейта, реляционная модель состоит из трех частей, описывающих разные аспекты реляционного подхода : структурной части, манипуляционной части и целостной части.

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

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

Целостность сущности и ссылок

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

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

Конечно, теоретически любой кортеж , заносимый в сохраняемое отношение , должен содержать все характеристики моделируемой им сущности реального мира, которые мы хотим сохранить в базе данных . Однако на практике не все эти характеристики могут быть известны к тому моменту, когда требуется зафиксировать сущность в базе данных . Простым примером может быть процедура принятия на работу человека, размер заработной платы которого еще не определен. В этом случае служащий отдела кадров, который заносит в отношение СЛУЖАЩИЕ кортеж , описывающий нового служащего, просто не может обеспечить значение атрибута СЛУ_ЗАРП (любое значение домена РАЗМЕРЫ_ВЫПЛАТ будет неверно характеризовать зарплату нового служащего).

Эдгар Кодд предложил использовать в таких случаях неопределенные значения . Неопределенное значение не принадлежит никакому типу данных и может присутствовать среди значений любого атрибута , определенного на любом типе данных (если это явно не запрещено при определении атрибута ). Если a – это значение некоторого типа данных или NULL , op – любая двуместная «арифметическая» операция этого типа данных (например, + ), а lop – операция сравнения значений этого типа (например, = ), то по определению:

a op NULL = NULL

NULL op a = NULL

a lop NULL = unknown

NULL lop a = unknown

Здесь unknown – это третье значение логического, или булевского, типа, обладающее следующими свойствами:

NOT unknown = unknown

true AND unknown = unknown

true OR unknown = true

false AND unknown = false

false OR unknown = unknown

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

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

Второе требование, которое называется требованием целостности по ссылкам (referential integrity) , является более сложным. Очевидно, что при соблюдении нормализованности отношений сложные сущности реального мира представляются в реляционной БД в виде нескольких кортежей нескольких отношений . Например, представим, что требуется представить в реляционной базе данных сущность ОТДЕЛ с атрибутами ОТД_НОМЕР (номер отдела), ОТД_РАЗМ (количество служащих) и ОТД_СЛУ (множество служащих отдела). Для каждого служащего нужно хранить СЛУ_НОМЕР (номер служащего), СЛУ_ИМЯ (имя служащего) и СЛУ_ЗАРП (заработная плата служащего). Как мы увидим в лекции 7, при правильном проектировании соответствующей БД в ней появятся два отношения : ОТДЕЛЫ {ОТД_НОМЕР, ОТД_РАЗМ} (первичный ключ – {ОТД_НОМЕР} ) и СОТРУДНИКИ {СЛУ_НОМЕР, СЛУ_ИМЯ, СЛУ_ЗАРП, СЛУ_ОТД_НОМ} (первичный ключ – {СЛУ_НОМЕР} ).

Как видно, атрибут СЛУ_ОТД_НОМ вводится в отношение СЛУЖАЩИЕ не потому, что номер отдела является собственным свойством служащего, а лишь для того, чтобы иметь возможность при необходимости восстановить полную сущность ОТДЕЛ . Значение атрибута СЛУ_ОТД_НОМ в любом кортеже отношения СЛУЖАЩИЕ должно соответствовать значению атрибута ОТД_НОМ в некотором кортеже отношения ОТДЕЛЫ . Атрибут такого рода (возможно, составной) называется внешним ключом (foreign key) , поскольку его значения однозначно характеризуют сущности, представленные кортежами некоторого другого отношения (т. е. задают значения их первичного ключа ). Конечно, внешний ключ может быть составным, т. е. состоять из нескольких атрибутов . Говорят, что отношение , в котором определен внешний ключ , ссылается на соответствующее отношение , в котором такой же атрибут является первичным ключом .

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

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

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

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

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

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

· Заключение

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

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

Поддержка языков базы данных

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

В первых базах данных существовало 2 языка:

1. Язык определœения схемы базы SDL.

2. язык манипулирования данных DML.

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

На сегодняшний день наиболее распространённым языком является

S tructured

L anguage

Этот язык и поддерживает, и создаёт схему базы данных и позволяет этими данными манипулировать. Он содержит всœе необходимые средства для обеспечения целостности базы данных. Эти ограничения целостности содержатся в специальных каталогах, что позволяет на языковом уровне контролировать целостное состояние базы данных. Специальные операторы языка SQL определяют так называемые представления базы данных. Представление - ϶ᴛᴏ запросы, которые хранятся в базе. Для пользователя представление - ϶ᴛᴏ таблица с помощью, которой можно ограничить или расширить видимость базы данных для конкретного пользователя данных. Язык SQL содержит так специальные операнды, которые обеспечивают авторизацию доступа к объектам базы данных. Поскольку разные пользователи имеют разные полномочия для работы с данными, то эти полномочия описываются в специальных таблицах – каталогах, которые поддерживаются на языковом уровне.

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

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

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

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

Схема отношения - ϶ᴛᴏ поименованное множество пар элементов. А в

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

Отношение - ϶ᴛᴏ множество кортежей соответствующей некоторой одной схеме, то есть реляционная база данных - ϶ᴛᴏ набор отношений, имена которых совпадают с именами схем отношений в структуре базы данных.

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

1. Тип данных

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

2. Домен

Понятие домена более специфично для баз данных, хотя и имеет некоторые аналогии с подтипами в некоторых языках программирования. В самом общем виде домен определяется заданием некоторого базового типа данных, к которому относятся элементы домена, и произвольного логического выражения, применяемого к элементу типа данных. Если вычисление этого логического выражения дает результат "истина", то элемент данных является элементом домена. Наиболее правильной интуитивной трактовкой понятия домена является понимание домена как допустимого потенциального множества значений данного типа. Например, домен "Имена" в нашем примере определен на базовом типе строк символов, но в число его значений могут входить только те строки, которые могут изображать имя (в частности, такие строки не могут начинаться с мягкого знака). Следует отметить также семантическую нагрузку понятия домена: данные считаются сравнимыми только в том случае, когда они относятся к одному домену. В нашем примере значения доменов "Номера пропусков" и "Номера групп" относятся к типу целых чисел, но не являются сравнимыми. Заметим, что в большинстве реляционных СУБД понятие домена не используется, хотя в Oracle V.7 оно уже поддерживается.

3. Схема отношения, схема базы данных

Схема отношения - это именованное множество пар {имя атрибута, имя домена (или типа, если понятие домена не поддерживается)}. Степень или "арность" схемы отношения - мощность этого множества. Степень отношения СОТРУДНИКИ равна четырем, то есть оно является 4-арным. Если все атрибуты одного отношения определены на разных доменах, осмысленно использовать для именования атрибутов имена соответствующих доменов (не забывая, конечно, о том, что это является всего лишь удобным способом именования и не устраняет различия между понятиями домена и атрибута). Схема БД (в структурном смысле) - это набор именованных схем отношений.

4. Кортеж, отношение

Кортеж, соответствующий данной схеме отношения, - это множество пар {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения. "Значение" является допустимым значением домена данного атрибута (или типа данных, если понятие домена не поддерживается). Тем самым, степень или "арность" кортежа, т.е. число элементов в нем, совпадает с "арностью" соответствующей схемы отношения. Попросту говоря, кортеж - это набор именованных значений заданного типа.
Отношение - это множество кортежей, соответствующих одной схеме отношения. Иногда, чтобы не путаться, говорят "отношение-схема" и "отношение-экземпляр", иногда схему отношения называют заголовком отношения, а отношение как набор кортежей - телом отношения. На самом деле, понятие схемы отношения ближе всего к понятию структурного типа данных в языках программирования. Было бы вполне логично разрешать отдельно определять схему отношения, а затем одно или несколько отношений с данной схемой.
Обычным житейским представлением отношения является таблица, заголовком которой является схема отношения, а строками - кортежи отношения-экземпляра; в этом случае имена атрибутов именуют столбцы этой таблицы. Поэтому иногда говорят "столбец таблицы", имея в виду "атрибут отношения". Реляционная база данных - это набор отношений, имена которых совпадают с именами схем отношений в схеме БД.

Фундаментальные свойства отношений

1.Отсутствие кортежей-дубликатов

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

2. Отсутствие упорядоченности кортежей

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

3. Отсутствие упорядоченности атрибутов

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

4. Атомарность значений атрибутов .

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

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

Реляционные операции и счисление.

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

Рис. 3.3. Некоторые операции реляционной алгебры
Созданы языки манипулирования данными, позволяющие реализовать все операции реляционной алгебры и практически любые их сочетания. Среди них наиболее распространены SQL (Structured Query Language – структуризованный язык запросов) и QBE (Quere-By-Example – запросы по образцу) [ , ]. Оба относятся к языкам очень высокого уровня, с помощью которых пользователь указывает, какие данные необходимо получить, не уточняя процедуру их получения. С помощью единственного запроса на любом из этих языков можно соединить несколько таблиц во временную таблицу и вырезать из нее требуемые строки и столбцы (селекция и проекция).

Которая является приложением к задачам обработки данных таких разделов математики как теории множеств и логика первого порядка .

На реляционной модели данных строятся реляционные базы данных .

Реляционная модель данных включает следующие компоненты:

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

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

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

Отношение является важнейшим понятием и представляет собой двумерную таблицу, содержащую некоторые данные.

Сущность – некоторый обособленный объект или событие, информацию о котором необходимо сохранять в базе данных и который имеет определенный набор свойств – атрибутов. Сущностями могут быть как физические (реально существующие) объекты, например СТУДЕНТ (атрибуты – Номер зачетной книжки, Фамилия, Имя, Отчество, Специальность, Номер группы и т.д.), так и абстрактные, например ЭКЗАМЕН (атрибуты – Дисциплина, Дата, Преподаватель, Аудитория и пр.). Для сущностей различают тип и экземпляр. Тип характеризуется именем и списком свойств, а экземпляр – конкретными значениями свойств.

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

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

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

3) однозначные и многозначные. Атрибуты могут иметь соответственно одно или много значений для каждого экземпляра сущности;

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

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

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

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

Кортеж, соответствующий данной схеме отношения, представляет собой множество пар (имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута. Аргумент “значение” является допустимым значением домена данного атрибута.

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

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

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

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

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

Элементы реляционной модели данных и форма их представления

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

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

1. Базы данных и информационные системы.
2. Системы управления БД.
3. Реляционная модель данных.
4. Этапы проектирования реляционных БД.
5. Нормализация отношений.
6. Операции над отношениями.

4.1. Базы данных и информационные системы.

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

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

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

Особый тип ИС – экспертные системы, которые имитируют поведение специалиста (эксперта) в какой-либо предметной области. Экспертная система может генерировать новую информацию в этой области – прогнозировать.

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

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

По способу доступа к данным БД разделяются на БД с локальным и БД с сетевым (удаленным) доступом. Системы централизованных БД с сетевым доступом предполагают две основные архитектуры: Файл-сервер, Клиент-сервер.

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

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

При проектировании и эксплуатации БД к ней предъявляются следующие требования:

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

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

1. Анализ предметной области, ее описание, формулировка ограничений целостности.
2. Проектирование структуры БД: состава и структуры файлов БД, связей между ними.
3. Задание ограничений целостности при описании структуры БД и процедур обработки данных.
4. Защита данных: обеспечение порядка входа в систему; определение прав доступа пользователей к данным; выбор и создание программно-технических средств защиты данных; тестирование средств защиты данных; сбор статистики об использовании данных; обеспечение восстановления БД.
5. Анализ обращений пользователей к БД.
6. Работа над совершенствованием и динамическим развитием БД.

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

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

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

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

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

4.2. Системы управления БД.

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

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

1. Надежное хранение больших объемов данных сложной структуры во внешней памяти вычислительной системы.
2. Непосредственное управление данными во внешней и оперативной памяти и обеспечение эффективного доступа к ним в процессе решения задачи.
3. Поддержание целостности данных и управление транзакциями.
4. Обеспечение восстановления БД после технического или программного сбоя.
5. Поддержка языка описания данных и языка запросов.
6. Обеспечение безопасности данных.
7. Обеспечение параллельного доступа к данным нескольких пользователей.

Требования к СУБД :

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

4.3. Реляционная модель данных.

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

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

Отношение задается своим именем и списком атрибутов – элементов, связанных этим отношением: <имя отношения>(<список атрибутов>).

Имя отношения выбирается таким образом, чтобы оно поясняло смысл связи между элементами отношения (семантику отношения).

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

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

Значение атрибута – величина, характеризующая некоторое свойство объекта и связи. Список имен атрибутов отношения и их характеристик называют схемой отношения.

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

Кортеж – один экземпляр отношения.

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

Деталь (< номер детали >, <название детали>, <цвет>, <вес>).

Поставщик (< код поставщика >, <фамилия>, <город>).

Поставка деталей (< код поставщика >, < номер детали >, <количество>).

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

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

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

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

4.4. Этапы проектирования реляционной БД.

Проектирование реляционной БД состоит из трех этапов: концептуального, логического и физического проектирования

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

Пример.

Имя отношения: Деталь
Поле		Признак ключа	Формат поля
Имя поля	Наименование			Тип	Длина	Точность
Номер детали	Номер детали		Числовой	Целое
Название детали	Название детали		Символьный
Цвет	Цвет детали		Символьный
Вес	Вес детали, г		Числовой	С плавающей точкой

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

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

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

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

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

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

4.5. Нормализация отношений.

В реляционной БД на каждое отношение накладывается такое ограничение – они должны быть нормализованы.

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

Основателем реляционной модели данных Е. Коддом выделены три нормальные формы отношений. Этот набор в дальнейшем был дополнен нормальной формой Бойса-Кодда, и далее четвертой и пятой нормальными формами.

Первая нормальная форма.

Ее суть состоит в требовании атомарности (неделимости) полей и единственности значений по полям в реляционной модели данных.

Пример: СПИСОК

Студент			Номер зачетной книжки	Дисциплина	Семестр	Оценка
Фамилия	Номер комнаты	Номер телефона
Иванов		29-07-64		Математика		Хорошо
Кузнецов		29-07-64		Информатика		Отлично
Горбунова		29-08-15		Психология		Хорошо

Данное отношение не нормализовано, так как содержит сложный атрибут Студент. Чтобы привести отношение к нормализованному виду, надо от него избавиться. Полученное соотношение СПИСОК (Фамилия, Номер_комнаты, Номер_телефона

Операции над отношениями.

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

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

Е.Коддом выделены три нормальные формы отношений и предложен механизм, позволяющий любое отношение преобразовать к третьей (самой совершенной) нормальной форме.

Первая нормальная форма

Пример: приведенное ниже отношение СТУДЕНТ не нормализовано, поскольку содержит сложный атрибут "Спорт".

СТУДЕНТ

Фамилия	Курс	Специальность	Спорт
						Вид	Разряд
Иванов Савинов Петров		Бух.учет ФИК Статистика	Плавание Шахматы Теннис	м.с. к.м.с.

Чтобы привести это отношение к нормализованному виду, надо избавиться от сложного атрибута "Спорт". Тогда полученное отношение СТУДЕНТ(Фамилия, Вид_спорта, Курс, Специальность, Спорт_разряд) является нормализованным. Ключ в нем является составным, состоящим из атрибутов "Фамилия" и "Вид_спорта".

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

Например, отношение СТУДЕНТ(Номер, Фамилия, Имя, Отчество, Дата, Группа) находится в первой нормальной форме.

Вторая нормальная форма

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

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

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

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

Пример графического изображения функциональных зависимостей реквизитов СТУДЕНТ показан на рис. 19, на котором ключевой реквизит указан *.

Рис. 19. Графическое изображение функциональной зависимости реквизитов

В случае составного ключа вводится понятие функционально полной зависимости.

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

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

Пример : Отношение СТУДЕНТ(Номер, Фамилия, Имя, Отчество, Дата, Группа) находится в первой и во второй нормальной форме одновременно, так как описательные реквизиты однозначно определены и функционально зависят от ключа Номер. Отношение УСПЕВАЕМОСТЬ(Номер, Фамилия, Имя, Отчество, Дисциплина, оценка) находится в первой нормальной форме и имеет составной ключ Номер+Дисциплина. Это отношение не находится во второй нормальной форме, так как атрибуты Фамилия, Имя, Отчество не находятся в полной функциональной зависимости с составным ключом отношения.

Третья нормальная форма

Понятие третьей нормальной формы основывается на понятии нетранзитивной зависимости.

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

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

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

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

"Расщепление" информационного объекта, содержащего транзитивную зависимость описательных реквизитов, показано на рис. 20. Как видно из рис. 19, исходный информационный объект СТУДЕНТ ГРУППЫ представляется в виде совокупности правильно структурированных информационных объектов (СТУДЕНТ и ГРУППА), реквизитный состав которых тождественен исходному объекту. Отношение СТУДЕНТ (Номер, Фамилия, Имя, Отчество, Дата, Группа) находится одновременно в первой, второй и третьей нормальной форме.

Рис. 20. Пример "расщепления" структуры информационного объекта

Требования нормализации. В один информационный объект реквизиты включаются в соответствии с требованиями третьей нормальной формы реляционной модели. Рассмотрим эти требования применительно к информационному объекту.

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

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

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

Операции над отношениями

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

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

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

Основными операциями над отношениями в реляционной БД являются следующие восемь:

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

Совокупность этих операций образует полную алгебру отношений.

1. Объединение. Операция выполняется над двумя совместимыми отношениями: R 1 , R 2 . В результате операции объединения строится новое отношение R = R 1 U R 2 . Отношение R имеет тот же состав атрибутов и совокупность кортежей исходных отношений. Причем в эту совокупность не включаются дубликаты.

R 1 «Клиенты банка А»

	Город	Фамилия
К11	Москва	Петров
К12	Санкт-Петербург	Смирнов
К13	Воронеж	Соколов

R 2 «Клиенты банка В»

	Город	Фамилия
К21	Самара	Петров
	Москва	Петров
	Тверь	Семенов

R «Клиенты»

	Город	Фамилия
К11	Москва	Петров
К12	Санкт-Петербург	Смирнов
К13	Воронеж	Соколов
К21	Самара	Петров
К23	Тверь	Семенов

В новое отношение R не вошел кортеж К22, так как он дублирует кортеж К11. Результат объединения включает все кортежи 1-ого отношения и недостающие кортежи из 2-ого отношения. Отношения R 1 и R 2 – операнды, а отношение R – результат.

1. Пересечение – R 1 , R 2 . Результирующее отношение RP = R 1 3 R 2 , содержит одинаковые кортежи, которые есть в каждом из двух исходных, т.е. результат пересечения содержит только те кортежи 1-ого отношения, которые есть во 2-ом. Результат пересечения имеет тот же состав атрибутов, как и в исходных.

Действие происходит над теми же операндами. Пересечение двух отношений R 1 «Клиенты банка А» и R 2 «Клиенты банка В» дает одно отношение RP «Клиент», которое будет являться результатом.

RP «Клиент»

Пересечение отношений

R – клиент	Город	Фамилия
	Москва	Петров	К11 (К22)

1. Вычитание – операция выполняется над двумя совместимыми отношениями R 1 , R 2 с идентичным набором атрибутов. В результате операции вычитания строится новое отношение RV = R 1 – R 2 с идентичным набором атрибутов, содержащее только те кортежи первого отношения R 1 , которые не повторяются в другом отношении R 2 . Вычитание отношения R 2 «Клиенты банка В» из отношения R 1 «Клиенты банка А», поскольку К11 = К22, дает отношение RV «Клиент»:

RV = R 1 – R 2 = {К11, К12, К13} – {К21, К22, К23} = {К12, К13}

RV «Клиент»

Разность отношений

	Город	Фамилия
К12	Санкт-Петербург	Смирнов
К13	Воронеж	Соколов

Отношение RV «Клиент» является результатом разности отношений при выполнении действий над теми же операндами ( R 1 и R 2 ).

1. Декартово произведение выполняется над двумя отношениями R 1 , R 2 с разными схемами. В результате операции декартова произведения образуется новое отношение RD = R 1 * R 2 , которое включает все атрибуты исходных отношений. Результирующее отношение состоит из всевозможных сочетаний кортежей исходных отношений R 1 , R 2 . Число кортежей декартова произведения равно произведению количеств кортежей в исходных отношениях, т.е. степень результирующего отношения равна сумме степеней отношений-операндов, а мощность - произведению их мощностей.

Пример: Декартово произведение двух отношений R 1 «Студент» и R 2 «Предмет» дает новое отношение RD «Экзаменационная ведомость», которое содержит все атрибуты исходных отношений. Отношения R 1 и R 2 – операнды, а отношение RD – результат.

R 1 «Студент»

	Номер	Фамилия
К11		Иванов
К12		Петров
К13		Сидоров

R 2 «Предмет»

	КОД	Наименование
К21		Математика
К22		Информатика

RD «Экзаменационная ведомость»

		Номер	Фамилия	Код	Наименование	Оценка
К11	К21		Иванов		Математика
К11	К22		Петров		Математика
К12	К21		Сидоров		Математика
К12	К22		Иванов		Информатика
К13	К21		Петров		Информатика
	К22		Сидоров		Информатика

Заметим, что в полученное отношение целесообразно добавить атрибут «Оценка» для записи результатов экзамена.

1. Деление – операция выполняется над двумя отношениями R 1 , R 2 , имеющими в общем случае разные структуры и некоторые одинаковые атрибуты. В результате операции образуется новое отношение, структура которого получается исключением из множества атрибутов отношения R 1 , множества атрибутов отношения R 2 . Отношение-делитель должно содержать подмножество атрибутов отношения-делимого. Результирующее отношение содержит только те атрибуты делимого, которых нет в делителе. В него включают только те кортежи, декартовы произведения которых с делителем содержатся в делимом. Результирующие строки не должны содержать дубликаты.

R 1 «Экз_ведомость» R 2 «Результаты» R «Студенты»

Фамилия	Предмет	Оценка		Предмет			Оценка				Фамилия
Антонов	Информатика			Информатика							Антонов
Антонов	Экономика			Экономика							Павлов
Павлов	Информатика										Павлов
Павлов	Экономика
Селезнев	Информатика
Селезнев	Экономика

1. Проекция. Эта операция выполняется над одним отношением R на некоторые атрибуты. Результирующее отношение ( RPR ) включает часть атрибутов исходного отношения R , на которые выполняется проекция. Оно может содержать меньше кортежей, так как после отбрасывания в исходном отношении R части атрибутов (возможного исключения первичного ключа) могут образоваться кортежи, дублирующие друг друга. Дублирующие кортежи из результирующего отношения исключаются. Проекция позволяет переупорядочить домены в отношении.

Ниже приведен пример исходного отношения R «Служащий» и результат проекции ( RPR ) этого отношения на два его атрибута – «должность» и «номер отдела».

R «Служащий»

Служащий	Номер отдела	Должность
Иванов		инженер
Петров		инженер
Нестеров		инженер
Никитин		лаборант

Отношение RPR

Номер отдела	Должность
	инженер
	инженер
	лаборант

1. Соединение выполняется для заданного условия соединения над двумя логически связанными отношениями. Исходные отношения R 1 и R 2 имеют разные структуры, в которых есть одинаковые атрибуты – внешние ключи (ключи связи). Операция соединения формирует новое отношение, структура которого является совокупностью всех атрибутов исходных отношений. Результирующие кортежи формируются объединением каждого кортежа из R 1 с теми кортежами R 2 , для которых выполняется условие. При этом условием, как правило, являются одинаковые значения внешнего ключа в исходных отношениях.

В качестве примера осуществим соединение над отношением R 1 «Группы» и R 2 «Студенты», которые будут являться операндами.

R 1 «Группы» R 2 «Студенты»

Специальность	Код_студента		Код_студента	Фамилия	Курс
Математика				Давыдов
Физика				Холодная
Бух.учет				Некрасов
				Пушкин
				Невзоров

В качестве атрибута для соединения можно выбрать ключ "Код_студента". Результирующее отношение включает все атрибуты 1-ого и 2-ого отношений и кортежи с одинаковым значением ключа. Результатом будет являться отношение R «Старосты групп».

R «Старосты групп»

Специальность	Код_студента	Фамилия	Курс
Математика		Давыдов
Физика		Пушкин
Бух.учет		Невзоров

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

Пример: Из отношения R «Клиент» осуществить выборку кортежей по условию «Возраст > 30 лет».

R «Клиент» Результат

Фамилия	Возраст			Фамилия	Возраст
Панфилов				Панфилов
Королев				Ломов
Михайлов
Ломов

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

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