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

Что такое реляционная база данных?

Amazon RDS

Amazon Aurora

AWS Database Migration Service

Блог Database

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

Важные аспекты реляционных БД

SQL (Structured Query Language) – основной интерфейс работы с реляционными базами данных. SQL стал стандартом Национального института стандартов США (ANSI) в 1986 году. Стандарт ANSI SQL поддерживается всеми популярными ядрами реляционных БД. Некоторые из ядер также включают расширения стандарта ANSI SQL, поддерживающие специфичный для этих ядер функционал. SQL используется для добавления, обновления и удаления строк данных, извлечения наборов данных для обработки транзакций и аналитических приложений, а также для управления всеми аспектами работы базы данных.

Целостность данных – это полнота, точность и единообразие данных. Для поддержания целостности данных в реляционных БД используется ряд инструментов. В их число входят первичные ключи, внешние ключи, ограничения «Not NULL», «Unique», «Default» и «Check». Эти ограничения целостности позволяют применять практические правила к данным в таблицах и гарантировать точность и надежность данных. Большинство ядер БД также поддерживает интеграцию пользовательского кода, который выполняется в ответ на определенные операции в БД.

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

Соответствие требованиям ACID

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

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

Источник

Как организована информация в реляционной базе данных

Структура реляционных баз данных

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

Файлы реляционной базы данных имеют свои особенности:

Организация информации в реляционной базе данных

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

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

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

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

Источник

Особенности реляционных БД

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

Реляционная БД чаще всего не ограничивается одной таблицей. Обычно создаются несколько таблиц со связанной информацией. Это позволяет исполнять более сложные операции над данными. Таблицы реляционной БД обязаны соответствовать требованиям понятия нормализации отношений, то есть ограничениям на формирование, которые позволят избежать дублирования и обеспечат непротиворечивость хранимой информации. Пусть создана таблица «Прокат», содержащая следующие поля: Шифр Клиента, Ф. И. О., Вид устройства, Дата выдачи, Оплата, Срок возврата. Эта организация хранения информации имеет несколько недостатков:

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

Связывание таблиц

Для любой таблицы реляционной БД задаётся первичный ключ (primary key) — поле или сочетание полей, которые определяют каждую запись. Внешний или вторичный ключ (foreign key) — это одно или несколько полей, ссылающихся на поле primary key другой таблицы.

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

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

Связи «один к одному» встречаются довольно редко. «Один ко многим» применяются чаще, например, кассир продаёт много билетов. «Многие ко многим» тоже встречаются часто. Например, студент изучает много предметов. Связи «многие ко многим» нельзя организовывать непосредственно. Для установления отношения необходимо сопоставить каждому primary key внешний ключ, который представляет собой primary key другой таблицы. Реляционные системы базируются на теории реляционной модели, которая включает в себя три аспекта:

Управление созданием и использованием БД осуществляется системами управления базами данных (СУБД).

Под их руководством:

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

Стадии и пример проектирования хранилища

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

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

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

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

Атрибутами для сопоставления объектов друг другу должны выступать ячейки с уникальным содержимым. В таблицах есть по одному полю с уникальными данными. В № 1 «Клиент» — это шифр клиента, а в № 3 «Склад» — шифр устройства. Это и будут primary keys. Каждая строка таблицы «Прокат» будет связывать два внешних ключа между собой:

Проблемы модели

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

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

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

Источник

Реляционные базы данных: объяснение понятий, вводный обзор

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

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

Ранние модели данных

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

Системы управления файлами

До появления СУБД все данные, которые содержались в компьютерной системе постоянно, хранились в виде отдельных файлов. Система управления файлами, ко­торая обычно являлась частью операционной системы, следила за именами фай­лов и их размещением. Системы управления файлами широко используются и се­годня — вероятно, вы знакомы со структурой папок и файлов, предоставляемой файловыми системами операционных систем Microsoft Windows или Macintosh компании Apple. Аналогичные файловые системы используются и в UNIX- серверах и всех коммерческих вычислительных системах.

В системах управления файлами модели данных, как правило, отсутствуют; эти системы ничего не знают о внутреннем содержимом файлов. В лучшем случае фай­ловая система поддерживает информацию о «типе файла» наряду с его именем, по­зволяя отличить документ текстового редактора от файла, содержащего данные о начисленной зарплате. Знание о содержимом файла — какие данные в нем хранятся и как они организованы — удел прикладных программ, использующих этот файл, как показано на рис. 1. В этом приложении начисления зарплаты каждая из про­грамм на языке программирования COBOL, работающая с основным файлом с ин­формацией о сотрудниках, содержит описание файла (file description, FD), в котором указана схема размещения данных в файле. Если структура данных изменяется — например, при решении хранить некоторую дополнительную информацию о каж­дом сотруднике— должны быть соответствующим образом модифицированы все программы, работающие с данным файлом. Это не слишком большая проблема в случае файла с документом текстового редактора или электронных таблиц, кото­рые обычно обрабатываются одной программой. Но при корпоративной работе с данными файлы зачастую совместно используются десятками, а то и сотнями про­грамм (см. рис. 1). При увеличении количества файлов и программ отделу обра­ботки данных придется тратить больше усилий на поддержание работоспособности старых программ, чем на разработку новых.

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

Рис. 1. Приложение для начисления зарплаты, исполь­зующее систему управления файлами

Иерархические базы данных

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

Список составных частей изделия по своей природе является иерархической структурой. Для хранения данных, имеющих такую структуру, была разработана иерархическая модель данных, которую иллюстрирует рис. 2. В этой модели каж­дая запись базы данных представляла конкретную деталь. Между записями суще­ствовали отношения предок-потомок, связывающие каждую часть с деталями, вхо­дящими в нее.

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

Рис. 2. Иерархическая база данных, содержащая информацию о составных частях

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

Одной из наиболее популярных иерархических СУБД была Information Management System (IMS) компании IBM, появившаяся в 1968 году. Ниже пере­числены преимущества IMS и реализованной в ней иерархической модели.

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

Сетевые базы данных

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

Рис. 3. Множественные отношения “предок-потомок”

В связи с этим для таких приложений, как обработка заказов, была разработана новая, сетевая, модель данных. Она расширила иерархическую модель, позволяя одной записи участвовать в нескольких отношениях «предок-потомок», именуе­мых множествами (set) (рис. 4). В 1971 году на конференции по языкам обработки данных (Conference on Data Systems Languages, CODASYL) был опубликован офи­циальный стандарт сетевых баз данных, который известен как модель CODASYL. Компания IBM не стала разрабатывать собственную сетевую СУБД, но в 1970-х го­дах независимые производители программного обеспечения реализовали сетевую модель в таких продуктах, как IDMS компании Cullinet, Total компании Cincom и СУБД Adabas, которые приобрели большую популярность. Однако IBM усовер­шенствовала IMS, обеспечив путь обхода правила единственного предка в класси­ческих иерархических структурах, в котором дополнительные предки рассматри­ваются как логические. Эта модель данных, ставшая известной как расширенная иерархическая модель, сделала базу данных IMS конкурентом сетевых СУБД.

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

Рис. 4. Сетевая (CODASYL) база данных для работы с заказами

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

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

Конечно, у сетевых баз данных имелись недостатки. Подобно своим иерархиче­ским предкам, сетевые базы данных были очень «жесткими». Наборы отношений и структура записей должны были быть заданы наперед. Изменение структуры ба­зы данных обычно означало полную перестройку последней.

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

Недостатки иерархической и сетевой моделей привели к повышенному инте­ресу к новой реляционной модели данных, впервые описанной доктором Коддом в 1970 году. Поначалу она представляла лишь академический интерес. Сетевые ба­зы данных продолжали оставаться важной технологией на протяжении 1970-х и в начале 1980-х годов, особенно в мини-компьютерных системах, переживавших пик популярности. Однако в середине 1980-х годов начался взлет реляционной моде­ли. В начале 1990-х годов сетевые базы данных утратили популярность и сегодня не играют значительной роли на рынке баз данных.

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

Реляционная модель данных, предложенная Коддом, была попыткой упростить структуру базы данных. В ней отсутствовала явная структура «предок-потомок», а все данные были представлены в виде простых таблиц, разбитых на строки и столбцы. На рис. 5 показана реляционная версия рассмотренной выше сетевой базы данных, содержащей информацию о заказах (рис. 4).

Рис. 5. Реляционная база данных для работы с заказами

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

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

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

Учебная база данных

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

Рис. 6. Учебная база данных (представлена частично)

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

Таблицы

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

Рис. 7. Структура реляционной таблицы

Каждый вертикальный столбец таблицы OFFICES представляет один элемент данных для каждого из офисов. Например, в столбце CITY содержатся названия городов, в которых расположены офисы. В столбце SALES содержатся объемы продаж, обеспечиваемые офисами. В столбце MGR содержатся идентификаторы управляющих офисами.

Все значения, содержащиеся в одном и том же столбце, являются данными од­ного типа. Например, в столбце CITY содержатся только слова, в столбце SALES — денежные суммы, а в столбце MGR — целые числа, представляющие идентификаторы служащих. Множество значений, которые могут содержаться в столбце, на­зывается доменом этого столбца. Доменом столбца CITY является множество всех названий городов. Домен столбца SALES — это любая денежная сумма. Домен столбца region состоит всего из двух значений, «Eastern» и «Western», поскольку у компании всего два торговых региона.

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

Столбцы таблицы упорядочены слева направо, и их порядок определяется при создании таблицы. В любой таблице всегда есть как минимум один столбец. В стандарте ANSI/ISO максимально допустимое число столбцов в таблице не ука­зывается; однако почти во всех коммерческих СУБД такой предел существует, но он редко бывает меньше 255 столбцов.

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

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

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

Поскольку строки в реляционной таблице не упорядочены, нельзя выбрать строку по ее номеру в таблице. В таблице нет «первой», «последней» или «тринадцатой» строки. Тогда каким же образом можно выбрать в таблице кон­кретную строку, например строку для офиса, расположенного в Денвере?

Рис. 8. Таблица с составным первичным ключом

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

Хотя первичные ключи являются важной частью реляционной модели данных, в первых реляционных СУБД (System/R, DB2, Oracle и других) явная их поддерж­ка обеспечена не была. Как правило, проектировщики базы данных сами следили за тем, чтобы у всех таблиц были первичные ключи; в самих СУБД не было воз­можности задать для таблицы первичный ключ. И только СУБД DB2 Version 2, появившаяся в апреле 1988 года, была первым коммерческим SQL-продуктом с поддержкой первичных ключей. После этого подобная поддержка была добав­лена в стандарт ANSI/ISO, и сегодня практически все СУРБД предоставляют та­кую возможность.

Взаимоотношения

Одним из отличий реляционной модели от ранних моделей представления данных было то, что в ней отсутствовали явные указатели, такие как использовав­шиеся для реализации отношений «предок-потомок» в иерархической модели данных. Однако вполне очевидно, что такие отношения существуют и в реляци­онных базах данных. Например, в нашей учебной базе данных каждый из служа­щих закреплен за конкретным офисом, поэтому ясно, что между строками табли­цы OFFICES и таблицы SALES REPS существует отношение. Не приводит ли отсут­ствие явных указателей в реляционной модели к потере информации?

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

Рис. 9. Отношение “предок-потомок” в реляционной базе данных

Внешние ключи

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

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

Рис. 10. Множественные отношения “предок-потомок” в реляционной базе данных

Внешние ключи являются фундаментальной частью реляционной модели, по­скольку реализуют отношения между таблицами базы данных. К сожалению, как и в случае с первичными ключами, поддержка внешних ключей отсутствовала в первых реляционных СУБД. Она была реализована в DB2 Version 2, а затем добавлена в стандарт ANSI/ISO и теперь имеется во всех основных коммерческих СУБД.

Двенадцать правил Кодда для реляционных баз данных

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

В 1985 году Тед Кодл (чья статья 15-летней давности определила реляционную модель данных) задался этим вопросом и ответил на него в журнале Compu­terworld (Is Your DBMS Really Relational? (Действительно ли ваша СУБД реляционная?, 14.10.1985) и Does Your DBMS Run By the Rules? (Работает ли ваша СУБД по правилам?, 21.10.1985)). Здесь он изложил двенадцать правил, которым должна соответствовать настоящая реляционная база данных.

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

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

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

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

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

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

Правила 8 и 9 изолируют пользователей и прикладные программы от низко­уровневой реализации базы данных и даже от изменений в структуре таблиц.

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

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

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

Заключение

SQL основан на реляционной модели данных, в которой данные организованы в виде коллекции таблиц.

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

Источник