Гайдамакин Н. А. 3 страница

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

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

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

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

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

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

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

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

 

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

• процессор описания и поддержания структуры базы дан­ных;

• процессор запросов к базе данных;

• монитор транзакций;*

• интерфейс ввода данных;

• интерфейс запросов;

• интерфейс выдачи сведений;

• генератор отчетов.

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

 

Схематично взаимодействие компонент СУБД представле­но на рис. 2.1.

 

Рис. 2.1. Структура и взаимодействие компонент СУБД

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

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

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

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

Процессор запросов интерпретирует сформированные зап­росы в терминах языка манипулирования данными и совмес­тно с процессором описания и поддержания структуры базы данных собственно и исполняет запросы. В реляционных СУБД основу процессора запросов составляет язык манипулирования данными, являющийся основной частью языка SQ L. Тем са­мым на базе процессора запросов и процессора описания и под­держания структуры базы данных образуется низший уровень оперирования данными в СУБД, который иногда называют машиной данных. Стандартные функции и возможности маши­ны данных используют компоненты СУБД более высокого по­рядка (см. рис. 2.1), что позволяет разделить и стандартизиро­вать компоненты СУБД и банка данных на три уровня —логи­ческий уровень, машина данных и собственно сами данные.

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

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

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

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

2.2. Модели организации данных

2.2.1. Иерархическая и сетевая модели организации данных

В иерархической модели объекты-сущности и отношения предметной области представляются наборами данных, кото­рые имеют строго древовидную структуру, т. е. допускают толь­ко иерархические (структурные) связи-отношения. Иерархичес­кая модель данных была исторически первой, на основе кото­рой в конце 60-х-начале 70-х годов были разработаны первые профессиональные СУБД-СУБД IMS (Information Management System) фирмы IBM, СУБД Total для компьютеров НР3000. К иерархическим СУБД также относятся отечественные промыш­ленные СУБД 70-80-х годов «ОКА» и «ИНЭС».

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

В приведенном примере информационный объект «Отде­лы» является предком информационного объекта «Подразде­ления», который, в свою очередь, является предком информа­ционного объекта «Сотрудники». Объект «Подразделения» яв­ляется потомком объекта «Отделы», а объект «Сотрудники» потомком объекта «Подразделения». Экземпляры потомка с об­щим предком называются близнецами.

Рис. 2.2. Пример иерархической организации данных

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

• найти указанное дерево (например, отдел № 3);

• перейти от одного дерева к другому;

• перейти от одной записи к другой (например, от отдела к первому подразделению);

• перейти от одной записи к другой в порядке обхода иерар­хии;

• удалить текущую запись.

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

Сетевая модель является расширением иерархической и широко применялась в 70-е годы в первых СУБД, использовав­шихся крупными корпорациями для создания информационных систем (СУБД IDMS — Integrated Database Management System компании Cullinet Software Inc., СУБД IDS, отечественные СУБД «СЕТЬ», «БАНК», «СЕТОР»). Одним из идеологов кон­цепции сетевой модели являлся Ч. Бахман. Эталонный вари­ант сетевой модели данных, разработанный с участием Бахмана, был описан в проекте «Рабочей группы по базам данных» КОДАСИЛ (DBTG CODASY L).

В отличие от иерархической, в сетевой модели объект-по­томок может иметь не одного, а вообще говоря, любое количе­ство объектов-предков. Тем самым допускаются любые связи-отношения, в том числе и одноуровневые. В результате сущно­сти и отношения предметной области АИС представляются графом любого (не только древовидного) типа. Пример такой организации данных приведен на рис. 2.3.

Рис. 2.3. Пример сетевой организации данных

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

Для данного типа связи L между типом записи предка Р и типом записи потомка С выполняются следующие условия:

• каждый экземпляр типа Р является предком только в од­ном экземпляре L,

• каждый экземпляр С является потомком не более чем в одном экземпляре L.

В рамках сетевой модели возможны следующие ситуации:

• тип записи потомка в одном типе связи L 1 может быть типом записи предка в другом типе связи L 2 (как в иерархичес­кой модели);

• данный тип записи Р может быть типом записи потомка в любом числе типов связи;

• может существовать любое число типов связи с одним и тем же типом записи предка и одним и тем же типом записи потомка;

• если L 1 и L 2 —два типа связи с одним и тем же типом записи предка Р и одним и тем же типом записи потомкаС, то правила, по которым образуется родство, в разных связях мо­гут различаться;

• типы записей Х и Y могут быть предком и потомком одной связи и потомком и предком в другой; предок и потомок могут быть одного типа записи (связь типа «петля»).

В сетевой модели устанавливаются следующие операции над данными:

• найти конкретную запись (экземпляр) в наборе однотип­ных записей;

• перейти от предка к первому потомку по некоторой связи;

• перейти к следующему потомку по некоторой связи;

• создать новую запись;

• уничтожить запись;

• модифицировать запись;

• включить в связь;

• исключить из связи;

• переставить в другую связь.

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

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

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

2.2.2. Реляционная модель организации данных

В реляционной модели объекты-сущности инфологической схемы предметной области АИС представляются плоски­ми таблицами данных. Столбцы таблицы, называемые полями базы данных, соответствуют атрибутам объектов-сущностей инфологической схемы предметной области. Множество атомар­ных значений атрибута называется доменом. Так доменом для поля «Имя» является множество всех возможных имен. Различ­ные атрибуты могут быть определены на одном и том же доме­не — например, атрибуты «Год поступления» (в вуз) и «Год окон­чания» определены на одном и том же домене, являющемся пе­речнем дат определенного диапазона.

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

Считается, что сильной стороной реляционных баз данных является развитая математическая теория, лежащая в их осно­ве—реляционная алгебра. Само слово «реляционная» проис­ходит от англ. relation — отношение. Но в случае реляционных баз слово «отношение» выражает не взаимосвязь между табли­цами-сущностями, а определение самой таблицы как матема­тического отношения доменов.*

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

Ключевому атрибуту объекта-сущности, который иденти­фицирует (определяет, отличает от других) конкретный экзем­пляр объекта, в таблице соответствует ключевое поле (так на­зываемый ключ таблицы). Примером ключа в таблице «Отде­лы» может быть поле «Номер отдела» или поле «Наименование отдела». В тех случаях, когда конкретную запись таблицы иден­тифицирует значение не одного поля, а совокупность значений нескольких полей, тогда все эти поля считаются ключевыми, а ключ таблицы является составным. Примером такой ситуации может служить таблица «Сотрудники», роль составного ключа в которой может играть совокупность полей «Фамилия», «Имя», «Отчество».*

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

 

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

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

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

Как уже отмечалось, таблица в реляционной модели отра­жает определенный объект-сущность из мифологической схе­мы предметной области АИС. Отношения-связи объектов-сущ­ностей в реляционной модели устанавливаются через введение в таблицах дополнительных полей, которые дублируют ключе­вые поля связанной таблицы. К примеру, связь между таблицей «Сотрудники» и таблицей «Отделы» устанавливается через введение копии ключевого поля «Номер отдела» из таблицы «От­делы» в таблицу «Сотрудники» — см. рис. 2.4. Такие поля, дуб­лирующие ключи связанной таблицы, называются внешними ключами.

Рис. 2.4. Пример связи в реляционных таблицах

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

Так как значения первичного ключа уникальны, т. е. не мо­гут повторяться (в таблице «Отделы» может быть только один кортеж по, к примеру, 710-му отделу), а значения других полей и, в частности, внешнего ключа могут повторяться (в таблице «Сотрудники» может быть несколько строк-кортежей сотруд­ников по 710-му отделу), то такой механизм автоматически обес­печивает связь типа «Один-ко-многим». Отсюда также можно заключить, что связи между таблицами типа «Один-к-одному» в реляционной модели автоматически обеспечиваются при оди­наковых первичных ключах, например между таблицей «Со­трудник» с ключом «Таб_№» и таблицей «Паспорт» с таким же ключом.

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

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

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

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

Отсюда вытекают следующие ограничения:

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

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

Требование целостности ссылок заключается в том, что для любого кортежа-записи с конкретным значением внешнего ключа (отсылки) должен обязательно существовать кортеж свя­занной таблицы-отношения с соответствующим значением пер­вичного ключа. Простым примером этого очевидного требова­ния является таблица-отношение «Сотрудники» с внешним клю­чом «№ отдела» и отсылаемая (связанная) таблица «Отделы» с первичным ключом «№ отдела» (см. рис. 2.4). Если существу­ет кортеж-запись «Иванов», работающий в отделе № 710, то в таблице «Отделы» обязательно должен быть кортеж-запись с соответствующим номером отдела (каждый сотрудник должен обязательно в каком-либо отделе хотя бы числиться).

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

Все операции над данными в реляционной модели (манипуляционная составляющая) можно разделить на две труппы — операции обновления таблиц-отношений и операции обработ­ки таблиц-отношений.

К операциям обновления относятся:

• операция ВКЛЮЧИТЬ —добавляет новый кортеж (стро­ку-запись) в таблицу-отношение. Требует задания имени таб­лицы и обязательного значения ключей. Выполняется при ус­ловии уникальности значения ключа. Добавить новую строку-запись со значением ключа, которое уже есть в таблице, невозможно;

• операция УДАЛИТЬ — удаляет одну или группу корте­жей (строк-записей). Требует задания имени таблицы, имени поля (группы полей) и параметров значений полей, кортежи с которыми должны быть удалены;

• операция ОБНОВИТЬ — изменяет значение не ключе­вых полей у одного или группы кортежей. Требует задания име­ни таблицы-отношения, имен полей и их значений для выбора кортежей и имен изменяемых полей.

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

• операция ОБЪЕДИНЕНИЕ — выполняется над двумя односхемными таблицами-отношениями. Результатом объеди­нения является построенная по той же схеме таблица-отноше­ние, содержащая все кортежи первой таблицы-отношения и все кортежи второй таблицы-отношения. При этом кортежи-дуб­ликаты в итоговой таблице устраняются;

• операция ПЕРЕСЕЧЕНИЕ — выполняется также над двумя односхемными таблицами-отношениями. Результатом яв­ляется таблица-отношение, построенная по той же схеме и со­держащая только те кортежи первой таблицы-отношения, ко­торые входят также в состав кортежей второй таблицы-отно­шения. Для примера рассмотрим таблицу «Сотрудники» со схемой (полями) «ФИО», «Год рождения», «Национальность» и таблицу «Вкладчики банка «НАДЕЖНЫЙ» с той же схемой. Результатом их пересечения будет новая таблица с той же схе­мой, содержащая кортежи только тех сотрудников, которые имеют вклады в банке «НАДЕЖНЫЙ», что иллюстрируется примером, приведенным на рис. 2.5;

• операция ВЫЧИТАНИЕ — выполняется также над дву­мя односхемными таблицами-отношениями. Результатом явля­ется таблица-отношение, построенная по той же схеме и со­держащая только те кортежи первой таблицы-отношения, ко­торых нет в составе кортежей второй таблицы-отношения. Результатом операции вычитания над таблицами в предыдущем примере будет новая таблица стой же схемой, содержащая кор­тежи только тех сотрудников, которые не имеют вкладов в бан­ке «НАДЕЖНЫЙ»;