Личные инструменты

БД:Лекции/Реляционная модель

| |

Материал из WikiTory

Перейти к: навигация, поиск

Содержание

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

Реляционная модель впервые была предложена Э. Ф. Коддом (Е. F. Codd) в 1970 году в его основополагающей статье "Реляционная модель данных для больших совместно используемых банков данных". В настоящее время публикацию этой статьи принято считать поворотным пунктом в истории развития систем баз данных, хотя следует заметить, что еще раньше была предложена модель, основанная на множествах.

Цели создания реляционной модели формулировались следующим образом.

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

Хотя интерес к реляционной модели обусловлен несколькими разными причинами, все же наиболее значительные исследования были проведены в рамках трех проектов с очень разной судьбой. Первый из них разрабатывался в конце 1970-х годов в исследовательской лаборатории корпорации IBM в городе Сан-Хосе, штат Калифорния, под руководством Астрахана (Astrahan), результатом чего стало создание системы под названием "System R", являвшейся прототипом истинной реляционной СУБД. Этот проект был задуман с целью получения реальных доказательств практической применимости реляционной модели посредством реализации предусматриваемых ею структур данных и операций. Этот проект также зарекомендовал себя как важнейший источник информации о таких проблемах реализации, как управление транзакциями, управление параллельной работой, технология восстановления, оптимизация запросов, обеспечение безопасности и целостности данных, учет человеческого фактора и разработка пользовательского интерфейса. Выполнение проекта стимулировало публикацию многих научно-исследовательских статей и создание других прототипов реляционных СУБД. В частности, работа над проектом System R дала толчок проведению следующих важнейших разработок:

  • создание языка структурированных запросов SQL (это название произносят либо по буквам "S-Q-L", либо (иногда) с помощью мнемонического имени "See-Quel"), который с тех пор приобрел статус формального стандарта ISO (International Organization for Standardization) и в настоящее время является фактическим стандартом языка реляционных СУБД;
  • создание различных коммерческих реляционных СУБД, которые впервые появились на рынке в конце 1970-х и начале 1980-х годов, таких как DB2 и SQL/DS корпорации IBM, а также Oracle корпорации Oracle Corporation.

Вторым проектом, который сыграл заметную роль в разработке реляционной модели данных, был проект INGRES (Interactive GRaphics REtrieval System), работа над которым проводилась в Калифорнийском университете (город Беркли) почти в то же самое время, что и над проектом System R. Проект INGRES включал разработку прототипа реляционной СУБД с концентрацией основного внимания на тех же общих целях, что и проект System R. Эти исследования привели к появлению академической версии INGRES, которая внесла существенный вклад в общее признание реляционной модели данных. Позже от данного проекта отпочковались коммерческие продукты INGRES фирмы Relational Technology Inc. (теперь INGRES II фирмы Computer Associates) и Intelligent Database Machine фирмы Britton Lee Inc.

Третьим проектом была система Peterlee Relational Test Vehicle научного центра корпорации IBM, расположенного в городе Петерли, Великобритания. Этот проект был более теоретическим, чем проекты System R и INGRES. Его результаты имели очень большое и даже принципиальное значение, особенно в таких областях, как обработка запросов и оптимизация, а также функциональные расширения системы.

Коммерческие системы на основе реляционной модели данных начали появляться в конце 1970-х - начале 1980-х годов. В настоящее время существует несколько сотен типов различных реляционных СУБД, как для мэйнфреймов, так и для персональных компьютеров, хотя многие из них не полностью соответствуют точному определению реляционной модели данных. Примерами реляционных СУБД для персональных компьютеров являются СУБД Access и FoxPro фирмы Microsoft, Paradox фирмы Corel Corporation, InterBase и BDE фирмы Borland, а также R:Base фирмы R:Base Technologies.

Благодаря популярности реляционной модели многие нереляционные системы теперь обеспечиваются реляционным пользовательским интерфейсом, независимо от используемой базовой модели. Основная сетевая СУБД, система IDMS фирмы Computer Associates, теперь называется CA-IDMS/SQL и поддерживает реляционное представление данных. Другими СУБД для мэйнфреймов, в которых поддерживаются некоторые реляционные компоненты, являются Model 204 фирмы Computer Corporation of America и ADABAS фирмы Software AG.

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



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

Отношение. Плоская таблица, состоящая из столбцов и строк.

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

Атрибут. Именованный столбец отношения.

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

Структура отношений Branch и Staff

Например, информация об отделениях компании может быть представлена отношением Branch, включающим столбцы с атрибутами faranchNo (Номер отделения), street (Улица), city (Город) и postcode (Почтовый индекс). Информация о работниках компании может быть представлена отношением Staff (Персонал), включающим столбцы с атрибутами staffNo (Табельный номер сотрудника), fName (Имя), IName (Фамилия), position (Должность), sex (Пол), DOB (Дата рождения), salary (Зарплата), branchNo (Номер отделения). На рисунке показаны примеры отношений Branch и Staff. Как видно из этого примера, каждый столбец содержит значения одного и того же атрибута — например, столбец branchNo содержит только номера существующих отделений компании.

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

Домены некоторых атрибутов отношений Branch и Staff

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

Кортеж. Строка отношения.

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

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

Степень. Степень отношения определяется количеством атрибутов, которое оно содержит.

Отношение Branch, показанное на рисунке, имеет четыре атрибута, и, следовательно, его степень равна четырем. Это значит, что каждая строка таблицы является четырехэлементным кортежем, т.е. кортежем, содержащим четыре значения. Отношение только с одним атрибутом имеет степень 1 и называется унарным (unary) отношением (дара одноэлементным кортежем). Отношение с двумя атрибутами называется бинарным (binary), отношение с тремя атрибутами — тернарным (ternary), а для отношений с большим количеством атрибутов используется термин п-арное (п-агу). Определение степени отношения является частью заголовка отношения.

Кардинальность. Количество кортежей, которое содержится в отношении.

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

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

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


Реляционная целостность

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

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

Пустые значения

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

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

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

Целостность сущностей

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

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

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

Ссылочная целостность

Второе ограничение целостности касается внешних ключей.

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

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

Корпоративные ограничения целостности

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

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

Преимущества реляционной БД(в историческом аспекте)

На сегодняшний день реляционные СУБД стали доминирующим типом программного обеспечения для обработки данных. Ежегодный объем продаж в этом секторе рынка оценивается в 15-20 миллиардов долларов (или 50 миллиардов долларов вместе с инструментами разработки), причем ежегодный прирост этого объема составляет 25%. Данное программное обеспечение представляет собой второе поколение СУБД, основанное на использовании реляционной модели данных, предложенной Э. Ф. Коддом (Е. F. Codd) в 1970 году. В реляционной модели все данные логически структурированы внутри отношений (таблиц). Каждое отношение имеет имя и состоит из именованных атрибутов (столбцов) данных. Каждый кортеж (строка) данных содержит по одному значению каждого из атрибутов. Большое преимущество реляционной модели заключается именно в этой простоте логической структуры. Хотя, конечно же, за этой простотой скрывается серьезный теоретический фундамент, которого не было у первого поколения СУБД (т.е. у сетевых и иерархических СУБД).

Язык манипулирования данными для реляционной модели

Введение в язык SQL

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

Назначение языка SQL

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

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

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

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

  • язык DDL (Data Definition Language), предназначенный для определения структур базы данных и управления доступом к данным;
  • язык DML (Data Manipulation Language), предназначенный для выборки и обновления данных.

До появления стандарта SQL3 язык SQL включал только команды определения и манипулирования данными; в нем отсутствовали какие-либо команды управления ходом вычислений. Другими словами, в этом языке не было команд IF ... THEN ... ELSE, GO TO, DO ... WHILE и любых других, предназначенных для управления ходом вычислительного процесса. Подобные задачи должны были решаться программным путем (с помощью языков программирования или управления заданиями) либо интерактивно (в результате действий, выполняемых самим пользователем). По причине подобной незавершенности (с точки зрения организации вычислительного процесса) язык SQL мог использоваться двумя способами. Первый предусматривал интерактивную работу, заключающуюся во вводе пользователем с терминала отдельных операторов SQL. Второй состоял во внедрении операторов SQL в программы на процедурных языках.

Язык SQL относительно прост в изучении.

  • Это непроцедурный язык, поэтому в нем необходимо указывать, какая информация должна быть получена, а не как ее можно получить. Иначе говоря, язык SQL не требует указания методов доступа к данным,
  • Как и большинство современных языков, SQL поддерживает свободный формат записи операторов. Это означает, что при вводе отдельные элементы операторов не связаны с фиксированными позициями на экране.
  • Структура команд задается набором ключевых слов, представляющих собой обычные слова английского языка, такие как CREATE TABLE (Создать таблицу), INSERT (Вставить), SELECT (Выбрать).

Например:

CREATE TABLE Staff (staffNo VARCHAR(S), IName VARCHAR(15), salary DECIMAL(7,2));
INSERT INTO Staff VALUES ('SG16', 'Brown', 8300);
SELECT staffNo, IName, salary
FROM Staff
WHERE salary > 10000;

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

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


Используемая терминология

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

Запись операторов SQL

Здесь кратко описана структура операторов SQL и представлена система обозначений, которая используется для определения формата различных конструкций языка SQL. Оператор SQL состоит из зарезервированных слов, а также из слов, определяемых пользователем. Зарезервированные слова являются постоянной частью языка SQL и имеют определенное значение. Их следует записывать именно так, как указано в стандарте, и нельзя разбивать на части для переноса из одной строки в другую. Слова, определяемые пользователем, задаются самим пользователем (в соответствии с определенными синтаксическими правилами) и представляют собой имена различных объектов базы данных — таблиц, столбцов, представлений, индексов и т.д. Слова в операторе размещаются в соответствии с установленными синтаксическими правилами. Хотя в стандарте это не указано, многие диалекты языка SQL требуют задания в конце оператора некоторого символа, обозначающего окончание его текста; как правило, с этой целью используется точка с запятой (;).

Большинство компонентов операторов SQL не чувствительно к регистру. Это означает, что могут использоваться любые буквы — как строчные, так и прописные. Одним важным исключением из этого правила являются символьные литералы — данные, которые должны вводиться точно так же, как были введены соответствующие им значения, хранящиеся в базе данных. Например, если в базе данных хранится значение фамилии 'SMITH1' , а в условии поиска указан символьный литерал 'Smith1' , то эта запись не будет найдена.

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

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

Для определения формата операторов SQL мы будем применять следующую расширенную форму системы обозначений BNF (Backus Naur Form — форма Бэкуса-Наура).

  • Прописные буквы будут использоваться для записи зарезервированных слов и должны указываться в операторах точно так же, как это будет показано.
  • Строчные буквы будут использоваться для записи слов, определяемых пользователем.
  • Вертикальная черта ( ) указывает на необходимость выбора одного из нескольких приведенных значений, например a | b | с.
  • Фигурные скобки определяют обязательный элемент, например {а}.
  • Квадратные скобки определяют необязательный элемент, например [а].
  • Многоточие (...) используется для указания необязательной возможности повторения конструкции от нуля до нескольких раз, например {а b}, [с...]. Эта запись означает, что после а или b может следовать от нуля до нескольких повторений с, разделенных запятыми.

На практике для определения структуры базы данных (в основном ее таблиц) используются операторы DDL, а для заполнения этих таблиц данными и выборки из них информации с помощью запросов — операторы DML.

Основные операторы языка SQL DML:

  • SELECT — выборка данных из базы;
  • INSERT — вставка данных в таблицу;
  • UPDATE — обновление данных в таблице;
  • DELETE — удаление данных из таблицы.


Источники

Сообщить об ошибке на сайте/предложить улучшение!