базы данных

Лекция 1. Ведение в БД и СУБД. Модели данных
Основные термины и определения ..........................................................................1
Модели данных ..........................................................................................................2
2.1.
Инфологическая модель данных [1] ................................................................2
2.1.1. Семантические сети [2] ................................................................................2
2.2.
Даталогическая модель .....................................................................................4
2.2.1. Иерархическая модель .................................................................................4
2.2.2. Сетевая модель [3, 4] ....................................................................................4
2.2.3. СУБД на основе инвертированных файлов [5] ..........................................6
2.2.4. Реляционная модель .....................................................................................7
3. Физическая модель [3] ..........................................................................................7
4. Список литературы ........................................ Ошибка! Закладка не определена.
1.
2.
1. Основные термины и определения
Глобально можно выделить два основных направления ее применения.
Первое направление – численные расчеты. Оно появилось раньше и
способствовало развитию методов численного решения сложных математических задач,
развитию языков программирования, ориентированных на решение вычислительных
задач.
Второе направление – это хранение и обработка данных. Целью любой
информационной системы является хранение и обработка данных о каких-либо объектах
реального мира.
Рассмотрим понятия как «данные» и «информация».
Информация представляет собой сведения об окружающих человека предметах,
явлениях и процессах и является объектом таких операций как восприятие, передача,
преобразование, хранение и использование.
Когда используется термин «данные», то речь идет об информации,
представленной в формализованном виде, пригодной для автоматической обработки при
возможном участии человека.
Термин «база данных» (БД) – это совокупность сведений о конкретных объектах.
При создании БД в основном преследуется цель упорядочить данные по различным
признакам, чтобы иметь возможность извлекать из данных нужную информацию.
Создание БД, ее поддержка, управление, а также доступ пользователей к самим
данным осуществляется посредством специальных программных продуктов,
называемых системами управления базами данных (СУБД).
Основная особенность СУБД – это наличие процедур для ввода и хранения не
только самих данных, но и описаний их структуры.
Файлы, снабженные описанием хранимых в них данных и находящиеся под
управлением СУБД, стали называть БД.
Функции СУБД
Управление буферами оперативной памяти
Управление транзакциями
Защита от отказов и восстановление (журнализация)
Обеспечение различных уровней доступа к данным
2. Модели данных
Выделяют следующие модели данных:
­ инфологические,
­ даталогические,
­ физические.
2.1. Инфологическая модель данных [1]
Процесс проектирования БД начинается с создания инфологической модели.
Инфологическая модель данных - обобщенное неформальное описание
создаваемой базы данных, выполненное с использованием естественного языка,
математических формул, таблиц, графиков и других средств, понятных всем людям,
работающих над проектированием базы данных..
или по-другому
Инфологическая модель данных - обобщенное, непривязанное к каким-либо СУБД
описание предметной области.
Инфологическая модель отображает реальный мир в некоторые понятные человеку
концепции, полностью независимые от параметров среды хранения данных. Поэтому
инфологическая модель не должна изменяться до тех пор, пока какие-то изменения в
реальном мире не потребуют изменения в ней некоторого определения, чтобы эта модель
продолжала отражать предметную область.
Существует множество подходов к построению таких моделей: графовые модели,
семантические сети, модель «сущность-связь» и др.
2.1.1. Семантические сети [2]
Семантическая сеть (СС) – это граф, дуги которого есть отношения между
вершинами (значениями). Семантические сети появились при решении задач разбора и
понимания смысла естественного языка. Пример семантической сети для предложения
типа "Поставщик осуществил поставку изделий по заказу клиента до 1 июня 2004 года в
количестве 1000 штук" приведен на рис. 1.
Рис. 1. Пример семантической сети
На этом примере видно, что между объектами Поставщик и Поставка определено
отношение "агент", между объектами Изделие и Поставка определено отношение "объект"
и т.д.
Число отношений, используемых в конкретных семантических сетях, может быть
самое разное. Неполный список возможных отношений, используемых в семантических
сетях для разбора предложений, выглядит следующим образом.
Агент - это то, что (тот, кто) вызывает действие. Агент часто является подлежащим
в предложении, например, "Робби ударил мяч".
Объект - это то, на что (на кого) направлено действие. В предложении объект часто
выполняет роль прямого дополнения, например, "Робби взял желтую пирамиду ".
Инструмент - то средство, которое используется агентом для выполнения действия,
например, "Робби открыл дверь с помощью ключа".
Соагент служит как подчиненный партнер главному агенту, например, "Робби
собрал кубики с помощью Суззи".
Пункт отправления и пункт назначения - это отправная и конечная позиции при
перемещении агента или объекта: "Робби перешел из комнаты в библиотеку".
Траектория - перемещение от пункта отправления к пункту назначения: "Они
прошли через дверь по ступенькам на лестницу".
Средство доставки - то в чем или на чем происходит перемещение: "Он всегда едет
домой на метро".
Местоположение - то место, где произошло (происходит, будет происходить)
действие, например, "Он работал за столом".
Потребитель - то лицо, для которого выполняется действие: "Робби собрал кубики
для Суззи".
Сырье - это, как правило, материал, из которого что-то сделано или состоит.
Обычно сырье вводится предлогом из, например, "Робби собрал Суззи из интегральных
схем".
Время - указывает на момент совершения действия: "Он закончил свою работу
поздно вечером".
Еще один пример поиска в СС. Представим вопрос "какой объект находится на
желтом блоке?" в виде подсети, изображенной на рис. 3. Произведем сопоставление
вопроса с сетью, представленной на рис. 4. В результате сопоставления получается ответ "Пирамида".
Рис. 3. Вопрос в виде CC
Рис. 4. Процедура сопоставления в СС
2.2. Даталогическая модель
Инфологическая модель должна быть отображена в даталогическую модель,
«понятную» СУБД.
Даталогическая модель – описание на языке конкретной СУБД.
2.2.1. Иерархическая модель
Сначала стали использовать иерархические даталогические модели. Эта модель
представляет собой совокупность связанных элементов, образующих иерархическую
структуру. К основным понятиям иерархии относятся уровень, узел и связь. Узлом
называется совокупность атрибутов данных, описывающих некоторый объект. Каждый
узел связан с одним узлом более высокого уровня и с любым количеством узлов нижнего
уровня. Исключением является узел самого высокого уровня, который не связан ни с
одним узлом более высокого уровня.
Количество деревьев в БД определяется количеством корней деревьев. К каждой
записи БД существует единственный путь от корневой записи.
Примером иерархической модели данных может служить адрес. На первом уровне
(корне дерева) лежит наша планета – Земля. На втором – страна. На третьем – регион
(республика, край, район), затем – населенный пункт, улица, дом, квартира.
Еще один пример – это система доменных имен в Интернете.
Типичным представителем СУБД (наиболее известным и распространенным),
основанной на иерархической модели, является Information Management System (IMS)
фирмы IBM. Первая версия появилась в 1968 г.
Рис. 5 Пример иерархической модели
Здесь Отдел является предком для Начальник и Сотрудники, а Начальник и
Сотрудники - потомки Отдел. Между типами записи поддерживаются связи.
База данных с такой схемой могла бы выглядеть следующим образом (мы
показываем один экземпляр дерева):
Рис. 6 Пример иерархической модели
Все экземпляры данного типа потомка с общим экземпляром типа предка
называются близнецами. Для БД определен полный порядок обхода - сверху-вниз, слеванаправо.
2.2.2. Сетевая модель [3, 4]
В основе сетевой модели данных лежат те же понятия, что и в основе
иерархической модели – узел, уровень и связь. Однако существенным различием является
то, что в иерархических структурах запись-потомок должна иметь в точности одного
предка; в сетевой структуре данных потомок может иметь любое число предков.
Сетевой подход к организации данных является расширением иерархического.
В сетевой модели данных любой объект может быть одновременно и главным, и
подчиненным, и может участвовать в образовании любого числа взаимосвязей с другими
объектами. Сетевая БД состоит из набора записей и набора связей между этими записями,
(см. рис. 7).
Рис. 7. Схема сетевой модели
Сетевые модели также создавались для мало ресурсных ЭВМ. Это достаточно
сложные структуры, состоящие из "наборов" – поименованных двухуровневых деревьев.
"Наборы" соединяются с помощью "записей-связок", образуя цепочки и т.д. При
разработке сетевых моделей было выдумано множество "маленьких хитростей",
позволяющих увеличить производительность СУБД, но существенно усложнивших
последние. Прикладной программист должен знать массу терминов, изучить несколько
внутренних языков СУБД, детально представлять логическую структуру базы данных для
осуществления навигации среди различных экземпляров, наборов, записей и т.п.
СУБД на основе инвертированных файлов [5]
Сложность практического использования иерархических и сетевых СУБД
заставляла искать иные способы представления данных. В конце 60-х годов появились
СУБД на основе инвертированных файлов (Инвертированный файл состоит из трёх
физических файлов, два из которых содержат словарь поисковых терминов в структуре бинарного
дерева, а третий содержит списокиндексных ссылок, соответствующих каждому термину.
Инвертированный файл используется в качестве индекса базы данных), отличающиеся простотой
организации и наличием весьма удобных языков манипулирования данными.
Организация доступа к данным на основе инвертированных списков используется
практически во всех современных реляционных СУБД, но в этих системах пользователи
не имеют непосредственного доступа к инвертированным спискам (индексам).
База данных, организованная с помощью инвертированных списков, похожа на
реляционную БД, но с тем отличием, что хранимые таблицы и пути доступа к ним видны
пользователям. При этом:
1. Строки таблиц упорядочены системой в некоторой физической последовательности.
2. Физическая упорядоченность строк всех таблиц может определяться и для всей БД
(так делается, например, в Datacom/DB).
3. Для каждой таблицы можно определить произвольное число ключей поиска, для
которых строятся индексы. Эти индексы автоматически поддерживаются системой, но
явно видны пользователям.
Поддерживаются два класса операторов:
1. Операторы, устанавливающие адрес записи, среди которых:
1.1. прямые поисковые операторы (например, найти первую запись таблицы по
некоторому пути доступа);
1.2. операторы, находящие запись в терминах относительной позиции от предыдущей
записи по некоторому пути доступа.
2. Операторы над адресуемыми записями
Типичный набор операторов:
­ LOCATE FIRST - найти первую запись таблицы T в физическом порядке; возвращает
адрес записи;
­ LOCATE FIRST WITH SEARCH KEY EQUAL - найти первую запись таблицы T с
заданным значением ключа поиска K; возвращает адрес записи;
­ LOCATE NEXT - найти первую запись, следующую за записью с заданным адресом в
заданном пути доступа; возвращает адрес записи;
­ LOCATE NEXT WITH SEARCH KEY EQUAL - найти cледующую запись таблицы T в
порядке пути поиска с заданным значением K; должно быть соответствие между
используемым способом сканирования и ключом K; возвращает адрес записи;
­ LOCATE FIRST WITH SEARCH KEY GREATER - найти первую запись таблицы T в
порядке ключа поиска K cо значением ключевого поля, большим заданного значения
K; возвращает адрес записи;
­ RETRIVE - выбрать запись с указанным адресом;
­ UPDATE - обновить запись с указанным адресом;
­ DELETE - удалить запись с указанным адресом;
­ STORE - включить запись в указанную таблицу; операция генерирует адрес записи.
Общие правила определения целостности БД отсутствуют. В некоторых системах
поддерживаются ограничения уникальности значений некоторых полей, но в основном
все возлагается на прикладную программу.
Однако такие СУБД обладают рядом ограничений на количество файлов для
хранения данных, количество связей между ними, длину записи и количество ее полей.
2.2.3. Реляционная модель
Сегодня наиболее распространена реляционная модель. В ее основе лежит идея о
том, что любой набор данных можно представить в виде двумерной таблицы. Простейшая
реляционная БД может состоять из единственной таблицы, в которой будут храниться все
необходимые данные. На практике реляционная БД состоит из нескольких таблиц,
связанных между собой по определенным критериям.
Задание. Подготовить доклады на тему «Объектно-ориентированная модель
данных» и «документно-ориентированная модель данных».
Задание. Назовите примеры СУБД, построенных на основе иерархических,
сетевых, реляционных, документно-ориентированных, объектно-ориентированных
моделей данных.
3. Физическая модель [3]
На основе даталогической модели строится физическая модель.
Физическая организация данных оказывает основное влияние на эксплуатационные
характеристики БД. Разработчики СУБД пытаются создать наиболее производительные
физические модели данных, предлагая пользователям тот или иной инструментарий для
поднастройки модели под конкретную БД.
В частности для реляционной БД она уже учитывает:
1. физические аспекты хранения таблиц в определенных файлах,
2. создания индексов, оптимизирующих скорость выполнения операций над данными с
помощью приложения,
3. выполнения различных действий над данными при определенных событиях,
определяемых пользователем с помощью триггеров, хранимых процедур.
Архитектура БД
По принципам обработки данных БД классифицируются на централизованные и
распределенные.
Централизованная БД подразумевает, что работа с БД возможна только локально.
Если компьютер работает в сети, то доступ к информации может осуществляться
удаленно с других компьютеров сети. Централизованные БД наиболее распространены в
настоящее время. При этом возможны несколько вариантов обработки данных.
Файл-серверная архитектура предполагает наличие в сети сервера, на котором
хранятся файлы централизованной БД. В соответствии с запросами пользователей файлы
с файл-сервера передаются на рабочие станции пользователей, где и осуществляется
основная часть обработки данных. Центральный сервер выполняет в основном только
роль хранилища файлов, не участвуя в обработке самих данных. После завершения
работы пользователи копируют файлы с обработанными данными обратно на сервер,
откуда их могут взять и обработать другие пользователи. Недостатки такой организации
данных очевидны. При одновременном обращении множества пользователей к одним и
тем же данным производительность работы резко падает, т.к. необходимо дождаться пока
пользователь, работающий с данными завершит работу. В противном случае возможно
затирание исправлений сделанных одним пользователем, изменениями других
пользователей.
В основе концепции клиент-сервер лежит идея о том, что помимо хранения
файлов БД, центральный сервер должен выполнять основную часть обработки данных.
Пользователи обращаются к серверу с помощью специального языка структурированных
запросов (SQL, Structed Query Language), на которм описывается список задач,
выполняемых сервером. Запросы принимаются сервером и порождают процессы
обработки данных. В ответ пользователь получает уже отработанный набор данных.
Технология клиент-сервер позволяет избежать передачи по сети огромных объемов
информации, переложив всю обработку на центральный сервер. Такой подход также
позволяет избежать конфликтов при редактировании одних и тех же данных множеством
пользователей.
Трехуровневая архитектура («Тонкий клиент» - сервер приложений - сервер базы
данных)функционирует в Интранет- и Интернет-сетях..
Клиентская часть ("тонкий клиент"), взаимодействующая с пользователем,
представляет собой HTML-страницу в Web-браузере либо Windows-приложение,
взаимодействующее с Web-сервисами. Вся программная логика вынесена на сервер
приложений, который обеспечивает формирование запросов к базе данных, передаваемых
на выполнение серверу баз данных. Сервер приложений может быть Web-сервером или
специализированной программой (см. рис. 8).
Рис. 8. Схема работы с БД в трехуровневой архитектуре
Распределенная БД располагается на нескольких компьютерах. Информация на
этих компьютерах может пересекаться и даже дублироваться. Для управления такими БД
предназначена система управления распределенными БД. Система скрывает от
пользователей обращения к данным, расположенным на других компьютерах. Для
пользователя все выглядит так, как будто вся информация находится на одном сервере.
Лекция 2. Инфологическая модель «Сущность-связь»
Цель моделирования данных состоит в обеспечении разработчика ИС концептуальной
схемой базы данных в форме одной модели или нескольких локальных моделей, которые
относительно легко могут быть отображены в любую систему баз данных.
Наиболее распространенным средством моделирования данных являются диаграммы
"сущность-связь" (ERD). С их помощью определяются важные для предметной области
объекты (сущности), их свойства (атрибуты) и отношения друг с другом (связи). ERD
непосредственно используются для проектирования реляционных баз данных.
Нотация ERD была впервые введена П. Ченом (Chen) и получила дальнейшее развитие в
работах Баркера. Метод Баркера будет излагаться на примере моделирования
деятельности компании по торговле автомобилями. Ниже приведены выдержки из
интервью, проведенного с персоналом компании.
Главный менеджер: одна из основных обязанностей - содержание автомобильного
имущества. Он должен знать, сколько заплачено за машины и каковы накладные расходы.
Обладая этой информацией, он может установить нижнюю цену, за которую мог бы
продать данный экземпляр. Кроме того, он несет ответственность за продавцов и ему
нужно знать, кто что продает и сколько машин продал каждый из них.
Продавец: ему нужно знать, какую цену запрашивать и какова нижняя цена, за которую
можно совершить сделку. Кроме того, ему нужна основная информация о машинах: год
выпуска, марка, модель и т.п.
Администратор: его задача сводится к составлению контрактов, для чего нужна
информация о покупателе, автомашине и продавце, поскольку именно контракты
приносят продавцам вознаграждения за продажи.
Первый шаг моделирования - извлечение информации из интервью и выделение
сущностей.
Сущность (Entity) - реальный либо воображаемый объект, имеющий существенное
значение для рассматриваемой предметной области, информация о котором подлежит
хранению (рис. 1).
Рис. 1. Графическое изображение сущности
Каждая сущность должна обладать уникальным идентификатором. Каждый экземпляр
сущности должен однозначно идентифицироваться и отличаться от всех других
экземпляров данного типа сущности. Каждая сущность должна обладать некоторыми
свойствами:




каждая сущность должна иметь уникальное имя, и к одному и тому же имени
должна всегда применяться одна и та же интерпретация. Одна и та же
интерпретация не может применяться к различным именам, если только они не
являются псевдонимами;
сущность обладает одним или несколькими атрибутами, которые либо
принадлежат сущности, либо наследуются через связь;
сущность обладает одним или несколькими атрибутами, которые однозначно
идентифицируют каждый экземпляр сущности;
каждая сущность может обладать любым количеством связей с другими
сущностями модели.
Обращаясь к приведенным выше выдержкам из интервью, видно, что сущности, которые
могут быть идентифицированы с главным менеджером - это автомашины и продавцы.
Продавцу важны автомашины и связанные с их продажей данные. Для администратора
важны покупатели, автомашины, продавцы и контракты. Исходя из этого, выделяются 4
сущности (автомашина, продавец, покупатель, контракт), которые изображаются на
диаграмме следующим образом (рис. 2).
Рис. 2. Сущности.
Следующим шагом моделирования является идентификация связей.
Связь (Relationship) - поименованная ассоциация между двумя сущностями, значимая
для рассматриваемой предметной области. Связь - это ассоциация между сущностями, при
которой, как правило, каждый экземпляр одной сущности, называемой родительской
сущностью, ассоциирован с произвольным (в том числе нулевым) количеством
экземпляров второй сущности, называемой сущностью-потомком, а каждый экземпляр
сущности-потомка ассоциирован в точности с одним экземпляром сущности-родителя.
Таким образом, экземпляр сущности-потомка может существовать только при
существовании сущности родителя.
Связи может даваться имя, выражаемое грамматическим оборотом глагола и помещаемое
возле линии связи. Имя каждой связи между двумя данными сущностями должно быть
уникальным, но имена связей в модели не обязаны быть уникальными. Имя связи всегда
формируется с точки зрения родителя, так что предложение может быть образовано
соединением имени сущности-родителя, имени связи, выражения степени и имени
сущности-потомка.
Например, связь продавца с контрактом может быть выражена следующим образом:


продавец может получить вознаграждение за 1 или более контрактов;
контракт должен быть инициирован ровно одним продавцом.
Степень связи и обязательность графически изображаются следующим образом (рис. 3).
Рис. 3. Типы связей
Таким образом, 2 предложения, описывающие связь продавца с контрактом, графически
будут выражены следующим образом (рис. 4).
Рис. 4
Описав также связи остальных сущностей, получим следующую схему (рис. 5).
Рис. 5
Последним шагом моделирования является идентификация атрибутов.
Атрибут - любая характеристика сущности, значимая для рассматриваемой предметной
области и предназначенная для квалификации, идентификации, классификации,
количественной характеристики или выражения состояния сущности. Атрибут
представляет тип характеристик или свойств, ассоциированных со множеством реальных
или абстрактных объектов (людей, мест, событий, состояний, идей, пар предметов и т.д.).
Экземпляр атрибута - это определенная характеристика отдельного элемента множества.
Экземпляр атрибута определяется типом характеристики и ее значением, называемым
значением атрибута. В ER-модели атрибуты ассоциируются с конкретными сущностями.
Таким образом, экземпляр сущности должен обладать единственным определенным
значением для ассоциированного атрибута.
Атрибут может быть либо обязательным, либо необязательным. Обязательность означает,
что атрибут не может принимать неопределенных значений (null values). Атрибут может
быть либо описательным (т.е. обычным дескриптором сущности), либо входить в состав
уникального идентификатора (первичного ключа).
Уникальный идентификатор - это атрибут или совокупность атрибутов и/или связей,
предназначенная для уникальной идентификации каждого экземпляра данного типа
сущности. В случае полной идентификации каждый экземпляр данного типа сущности
полностью идентифицируется своими собственными ключевыми атрибутами, в
противном случае в его идентификации участвуют также атрибуты другой сущностиродителя (рис. 6).
Рис. 6 Обязательные и необязательные атрибуты
Рис. 7 Идентификация сущностей
Каждый атрибут идентифицируется уникальным именем, выражаемым грамматическим
оборотом существительного, описывающим представляемую атрибутом характеристику.
Атрибуты изображаются в виде списка имен внутри блока ассоциированной сущности,
причем каждый атрибут занимает отдельную строку. Атрибуты, определяющие
первичный ключ, размещаются наверху списка и выделяются знаком "#".
Каждая сущность должна обладать хотя бы одним возможным ключом. Возможный ключ
сущности - это один или несколько атрибутов, чьи значения однозначно определяют
каждый экземпляр сущности. При существовании нескольких возможных ключей один из
них обозначается в качестве первичного ключа, а остальные - как альтернативные ключи.
С учетом имеющейся информации дополним построенную ранее диаграмму (рис. 8).
Помимо перечисленных основных конструкций модель данных может содержать ряд
дополнительных.
Подтипы и супертипы: одна сущность является обобщающим понятием для группы
подобных сущностей (рис. 9).
Взаимно исключающие связи: каждый экземпляр сущности участвует только в одной
связи из группы взаимно исключающих связей (рис. 10).
Рис. 8
Рис. 9. Подтипы и супертипы
Рис. 10. Взаимно исключающие связи
Рекурсивная связь: сущность может быть связана сама с собой (рис. 11).
Рис. 11. Рекурсивная связь
Методология IDEF1
Метод IDEF1, разработанный Т.Рэмей (T.Ramey), также основан на подходе П.Чена и
позволяет построить модель данных, эквивалентную реляционной модели в третьей
нормальной форме. В настоящее время на основе совершенствования методологии IDEF1
создана ее новая версия - методология IDEF1X. IDEF1X разработана с учетом таких
требований, как простота изучения и возможность автоматизации. IDEF1X-диаграммы
используются рядом распространенных CASE-средств (в частности, ERwin, Design/IDEF).
Сущность в методологии IDEF1X является независимой от идентификаторов или просто
независимой, если каждый экземпляр сущности может быть однозначно идентифицирован
без определения его отношений с другими сущностями. Сущность называется зависимой
от идентификаторов или просто зависимой, если однозначная идентификация экземпляра
сущности зависит от его отношения к другой сущности (рис. 12).
Рис. 12. Сущности
Каждой сущности присваивается уникальное имя и номер, разделяемые косой чертой "/" и
помещаемые над блоком.
Связь может дополнительно определяться с помощью указания степени или мощности
(количества экземпляров сущности-потомка, которое может существовать для каждого
экземпляра сущности-родителя). В IDEF1X могут быть выражены следующие мощности
связей:




каждый экземпляр сущности-родителя может иметь ноль, один или более
связанных с ним экземпляров сущности-потомка;
каждый экземпляр сущности-родителя должен иметь не менее одного связанного с
ним экземпляра сущности-потомка;
каждый экземпляр сущности-родителя должен иметь не более одного связанного с
ним экземпляра сущности-потомка;
каждый экземпляр сущности-родителя связан с некоторым фиксированным числом
экземпляров сущности-потомка.
Если экземпляр сущности-потомка однозначно определяется своей связью с сущностьюродителем, то связь называется идентифицирующей, в противном случае неидентифицирующей.
Связь изображается линией, проводимой между сущностью-родителем и сущностьюпотомком с точкой на конце линии у сущности-потомка. Мощность связи обозначается
как показано на рис. 13 (мощность по умолчанию - N).
Рис. 13. Мощность связи
Идентифицирующая связь между сущностью-родителем и сущностью-потомком
изображается сплошной линией (рис. 14). Сущность-потомок в идентифицирующей связи
является зависимой от идентификатора сущностью. Сущность-родитель в
идентифицирующей связи может быть как независимой, так и зависимой от
идентификатора сущностью (это определяется ее связями с другими сущностями).
Рис. 14. Идентифицирующая связь
Пунктирная линия изображает неидентифицирующую связь (рис. 15). Сущность-потомок
в неидентифицирующей связи будет независимой от идентификатора, если она не
является также сущностью-потомком в какой-либо идентифицирующей связи.
Рис. 15. Неидентифицирующая связь
Атрибуты изображаются в виде списка имен внутри блока сущности. Атрибуты,
определяющие первичный ключ, размещаются наверху списка и отделяются от других
атрибутов горизонтальной чертой (рис. 16).
Рис. 16. Атрибуты и первичные ключи
Сущности могут иметь также внешние ключи (Foreign Key), которые могут
использоваться в качестве части или целого первичного ключа или неключевого атрибута.
Внешний ключ изображается с помощью помещения внутрь блока сущности имен
атрибутов, после которых следуют буквы FK в скобках (рис. 17).
Рис. 17. Примеры внешних ключей
ER-диаграмма должна подчиняться следующим правилам:









каждая сущность, каждый атрибут и каждая связь должны иметь имя (связь
супертипа или ассоциативная связь может не иметь имени);
имя сущности должно быть уникально в рамках модели данных;
имя атрибута должно быть уникально в рамках сущности;
имя связи должно быть уникально, если для нее генерируется таблица БД;
каждый атрибут должен иметь определение типа данных;
сущность в необязательной связи должна иметь ключевой атрибут. То же самое
относится к сильной сущности в слабой связи, супертипу в связи "супертипподтип" и необязательной сущности в обязательной (полной) связи;
подтип в связи "супертип-подтип" не может иметь ключевой атрибут;
в ассоциативной или слабой связи может быть только одна ассоциативная (слабая)
сущность;
связь не может быть одновременно обязательной, "супертип-подтип" или
ассоциативной.
Лекция 3. Реляционная модель данных
1.
2.
3.
4.
5.
6.
Пример построения инфологической модели базы данных «Питание» ............19
Реляционная структура данных .............................................................................20
Реляционная база данных .......................................................................................22
Манипулирование реляционными данными.........................................................23
Универсальное отношение .....................................................................................24
Почему проект БД может быть плохим? ...............................................................25
Пример построения инфологической модели базы данных
«Питание»
Рассмотрим пример построения инфологической модели базы данных «Питание»,
1.
где должна храниться информация о блюдах (рис. 3.1), их ежедневном потреблении,
продуктах, из которых приготавливаются эти блюда, и поставщиках этих продуктов.
Информация будет использоваться поваром и руководителем небольшого предприятия
общественного питания, а также его посетителями.
Лобио по-грузински
Ломаную очищенную фасоль, нашинкованный лук посолить, посыпать перцем и
припустить в масле с небольшим количеством бульона; добавить кинзу, зелень петрушки,
рейган (базилик) и довести до готовности. Затем запечь в духовке.
Фасоль стручковая (свежая или консервированная) 200 гр.,
Лук зеленый 40 гр., Масло сливочное 30 гр., Зелень 10 гр.
Выход 210 гр. Калорий 725.
Рис. 3.1. Пример кулинарного рецепта
С помощью указанных пользователей выделены следующие объекты и
характеристики проектируемой базы:
1. Блюда, для описания которых нужны данные, входящие в их кулинарные рецепты:
номер блюда (например, из книги кулинарных рецептов), название блюда, вид блюда
(закуска, суп, горячее и т.п.), рецепт (технология приготовления блюда), выход (вес
порции), а также название, калорийность и вес каждого продукта, входящего в блюдо;
2. Для каждого поставщика продуктов: наименование, город и страна, название
поставляемого продукта, дата поставки и цена на момент поставки.
3. Ежедневное потребление блюд (расход): блюдо, количество порций, дата.
Анализ позволяет выделить:
1. независимые сущности – Продукты, Блюда, Поставщики, Города;
2. зависимые сущности – Состав блюд, Поставки, Рецепты, Расход блюд.
Рис. 3.2. Модель базы данных «Питание»
В этих моделях Блюдо, Продукт и Поставщик – наименования, а БЛ, ПР и ПОС –
цифровые коды блюд, продуктов и поставщиков продуктов.
2. Реляционная структура данных
В конце 60-х годов появились работы, в которых обсуждались возможности
применения различных табличных даталогических моделей данных. Наиболее
значительной из них была статья сотрудника фирмы IBM д-ра Эдварда Кодда (Codd E.F.,
A Relational Model of Data for Large Shared Data Banks. CACM 13: 6, June 1970), где
впервые был применен термин «реляционная модель данных».
Будучи математиком по образованию, Э. Кодд предложил использовать для
обработки данных аппарат теории множеств (объединение, пересечение, разность,
декартово произведение). Он показал, что любое представление данных сводится к
совокупности двумерных таблиц особого вида, известного в математике как отношение –
relation.
Наименьшая единица данных реляционной модели – это отдельное атомарное
(неразложимое) для данной модели значение данных.
Так, в одной предметной области фамилия, имя и отчество могут рассматриваться
как единое значение, а в другой – как три различных значения.
Доменом называется множество атомарных значений одного и того же типа.
Так, на рис. 3.3 домен пунктов отправления (назначения) – множество названий
населенных пунктов, а домен номеров рейса – множество целых положительных чисел.
Номер Дни
Пункт
Время
Пункт
Время
Тип
Стоимость
рейса недели отправления вылета назначения прибытия самолета
билета
138
2_4_7
Баку
21.12
Москва
0.52
ИЛ-86
115.00
57
3_6
Ереван
7.20
Киев
9.25
ТУ-154
92.00
1234
2_6
Казань
22.40
Баку
23.50
ТУ-134
73.50
242
1 по 7
Киев
14.10
Москва
16.15
ТУ-154
57.00
86
2_3_5
Минск
10.50
Сочи
13.06
ИЛ-86
78.50
137
1_3_6
Москва
15.17
Баку
18.44
ИЛ-86
115.00
241
1 по 7
Москва
9.05
Киев
11.05
ТУ-154
57.00
577
1_3_5
Рига
21.53
Таллин
22.57
АН-24
21.50
78
3_6
Сочи
18.25
Баку
20.12
ТУ-134
44.00
578
2_4_6
Таллин
6.30
Рига
7.37
АН-24
21.50
Рис. 3.3. Таблица «Рейс»
Смысл доменов состоит в следующем. Если значения двух атрибутов берутся из
одного и того же домена, то, вероятно, имеют смысл сравнения, использующие эти два
атрибута (например, для организации транзитного рейса можно дать запрос «Выдать
рейсы, в которых время вылета из Москвы в Сочи больше времени прибытия из
Архангельска в Москву»). Если же значения двух атрибутов берутся из различных
доменов, то их сравнение, вероятно, лишено смысла: стоит ли сравнивать номер рейса со
стоимостью билета?
Отношение на доменах D1, D2, ..., Dn состоит из заголовка и тела. На рис. 3.4
приведен пример отношения для расписания движения самолетов (рис.3.2). Ai атрибуты, Vi - значения атрибутов.
Рис. 3.4. Отношение с математической точки зрения
Заголовок отношения состоит из такого фиксированного множества атрибутов
A1, A2, ..., An, что существует взаимно однозначное соответствие между этими
атрибутами Ai и определяющими их доменами Di (i=1,2,...,n).
Тело отношения состоит из меняющегося во времени множества кортежей, где
каждый кортеж состоит в свою очередь из множества пар атрибут-значение (Ai:Vi),
(i=1,2,...,n), по одной такой паре для каждого атрибута Ai в заголовке.
Для любой заданной пары атрибут-значение (Ai:Vi) Vi является значением из
единственного домена Di, который связан с атрибутом Ai.
Степень отношения – это число его атрибутов.
Отношение степени один называют унарным, степени два – бинарным, степени три
– тернарным, ..., а степени n – n-арным. Степень отношения «Рейс» (рис. 3.2) равна 8.
Кардинальное число или мощность отношения – это число его кортежей.
Мощность отношения «Рейс» равна 10. Кардинальное число отношения изменяется
во времени в отличие от его степени.
Поскольку отношение – это множество, а множества по определению не содержат
совпадающих элементов, то никакие два кортежа отношения не могут быть
дубликатами друг друга в любой произвольно заданный момент времени.
Пусть R – отношение с атрибутами A1, A2, ..., An. Говорят, что множество
атрибутов K=(Ai, Aj, ..., Ak) отношения R является возможным ключом R тогда и
только тогда, когда удовлетворяются два независимых от времени условия:
1. Уникальность: в произвольный заданный момент времени никакие два различных
кортежа R не имеют одного и того же значения для Ai, Aj, ..., Ak.
2. Минимальность: ни один из атрибутов Ai, Aj, ..., Ak не может быть исключен из K
без нарушения уникальности.
Каждое отношение обладает хотя бы одним возможным ключом, поскольку по
меньшей мере комбинация всех его атрибутов удовлетворяет условию уникальности.
Один из возможных ключей (выбранный произвольным образом) принимается за его
первичный ключ. Остальные возможные ключи, если они есть, называются
альтернативными ключами.
Вышеупомянутые и некоторые другие математические понятия явились
теоретической базой для создания реляционных СУБД, разработки соответствующих
языковых средств и программных систем, обеспечивающих их высокую
производительность, и создания основ теории проектирования баз данных.
Также на практике широко используются неформальные эквиваленты этих
понятий: Отношение – Таблица, Кортеж – Строка таблицы или Запись, Атрибут – Столбец
Таблицы или Поле.
При этом принимается, что «запись» означает «экземпляр записи», а «поле»
означает «имя и тип поля».
3. Реляционная база данных
Реляционная база данных – это совокупность отношений, содержащих всю
информацию, которая должна храниться в БД.
Однако пользователи могут воспринимать такую базу данных как совокупность
таблиц. Так на рис. 3.5 показаны таблицы базы данных, построенные по инфологической
модели базы данных «Питание» (рис. 3.2).
1. Каждая таблица состоит из однотипных строк и имеет уникальное имя.
2. Строки имеют фиксированное число полей (столбцов) и значений (множественные
поля и повторяющиеся группы недопустимы). Иначе говоря, в каждой позиции
таблицы на пересечении строки и столбца всегда имеется в точности одно значение
или ничего.
3. Строки таблицы обязательно отличаются друг от друга хотя бы единственным
значением, что позволяет однозначно идентифицировать любую строку такой
таблицы.
4. Столбцам таблицы однозначно присваиваются имена, и в каждом из них размещаются
однородные значения данных (даты, фамилии, целые числа или денежные суммы).
5. Полное информационное содержание базы данных представляется в виде явных
значений данных и такой метод представления является единственным. В частности,
не существует каких-либо специальных «связей» или указателей, соединяющих одну
таблицу с другой. Так, связи между строкой с БЛ=2 таблицы «Блюда» на рис. 3.5 и
строкой с ПР=7 таблицы «Продукты» (для приготовления «Харчо» нужен «Рис»),
представляется не с помощью указателей, а благодаря существованию в таблице
«Состав» строки, в которой номер блюда равен 2, а номер продукта равен 7.
6. При выполнении операций с таблицей ее строки и столбцы можно обрабатывать в
любом порядке безотносительно к их информационному содержанию. Этому
способствует наличие имен таблиц и их столбцов, а также возможность выделения
любой их строки или любого набора строк с указанными признаками (например,
рейсов с пунктом назначения "Париж" и временем прибытия до 12 часов).
Состав
БЛ ПР Веc (г)
Продукты
Блюда
БЛ
Блюдо
Вид
1
Лобио
Закуска
2
Харчо
Суп
ПР Продукт Калор.
1
Фасоль
3070
2
Лук
450
3
Масло
7420
4
Зелень
180
5
Мясо
1660
Расход
6
Томаты
240
БЛ Порций Дата_Р
7
Рис
3340
8
Кофе
2750
3
4
Шашлык Горячее
Кофе
Десерт
1
158
1/9/94
2
144
1/9/94
3
207
1/9/94
4
235
1/9/94
...
...
...
Рецепты
БЛ
Рецепт
1
Ломаную очищ
...
...
1
1
200
1
2
40
1
3
30
1
4
10
2
5
80
2
2
30
2
6
40
2
7
50
2
3
15
2
4
15
3
5
180
3
6
100
3
2
40
3
4
20
4
8
8
Поставки
Поставщики
ПОС Поставщик Город
ПОС ПР Вес (кг) Цена Дата_П
1
"Полесье"
Киев
1
6
120
0.45
27/8/94
2
"Наталка"
Киев
1
3
50
1.82
27/8/94
3
"Хуанхэ"
Пекин
1
2
50
0.61
27/8/94
4
"Лайма"
Рига
2
2
100
0.52
27/8/94
5
"Юрмала"
Рига
2
5
100
2.18
27/8/94
6
"Даугава"
Рига
2
4
10
0.88
27/8/94
3
1
250
0.37
24/8/94
3
7
75
0.44
24/8/94
3
8
40
2.87
24/8/94
4
3
70
1.56
30/8/94
5
5
200
2.05
30/8/94
6
6
15
0.99
30/8/94
Города
Город Страна
Киев Украина
Пекин
Китай
Рига
Латвия
Рис. 3.5. База данных «Питание»
4. Манипулирование реляционными данными
Стремление к минимизации числа таблиц для хранения данных может привести к
возникновению различных проблем при их обновлении и будут даны рекомендации по
разбиению некоторых больших таблиц на несколько маленьких. Но как сформировать
требуемый ответ, если нужные для него данные хранятся в разных таблицах?
Предложив реляционную модель данных, Э. Кодд создал и инструмент для
удобной работы с отношениями – реляционную алгебру. Каждая операция этой алгебры
использует одну или несколько таблиц (отношений) в качестве ее операндов и
продуцирует в результате новую таблицу, т.е. позволяет «разрезать» или «склеивать»
таблицы (рис. 3.6).
Рис. 3.6. Некоторые операции реляционной алгебры
Созданы языки манипулирования данными, позволяющие реализовать все
операции реляционной алгебры и практически любые их сочетания. Среди них наиболее
распространен SQL (Structured Query Language – структуризованный язык запросов).
С помощью единственного запроса на языке SQL можно соединить несколько
таблиц во временную таблицу и вырезать из нее требуемые строки и столбцы (селекция и
проекция).
Подробнее
Основная цель проектирования БД – это сокращение избыточности хранимых
данных, а следовательно, экономия объема используемой памяти, уменьшение затрат на
многократные операции обновления избыточных копий и устранение возможности
возникновения противоречий из-за хранения в разных местах сведений об одном и том же
объекте. Так называемый, «чистый» проект БД («Каждый факт в одном месте») можно
создать, используя методологию нормализации отношений. И хотя нормализация должна
использоваться на завершающей проверочной стадии проектирования БД, рассмотрим
причины, которые заставили Кодда создать основы теории нормализации.
5. Универсальное отношение
Предположим, что проектирование базы данных «Питание» начинается с
выявления атрибутов и подбора данных, образец которых показан на рис. 3.7.
Этот вариант таблицы «Питание» не является отношением, так как большинство ее
строк не атомарны. Атомарными являются лишь значения полей Блюдо, Вид, Рецепт (хотя
он и большой), Порций и Дата_Р остальные же поля таблицы рис. 3.7 – множественные.
Для придания таким данным формы отношения необходимо реконструировать таблицу.
Наиболее просто это сделать с помощью простого процесса вставки, результат которой
показан на рис. 3.8. Однако такое преобразование приводит к возникновению большого
объема избыточных данных.
Таблица на рис. 3.8 представляет собой экземпляр корректного отношения. Его
называют универсальным отношением проектируемой БД. В одно универсальное
отношение включаются все представляющие интерес атрибуты, и оно может содержать
все данные, которые предполагается размещать в БД в будущем. Для малых БД
(включающих не более 15 атрибутов) универсальное отношение может использоваться в
качестве отправной точки при проектировании БД.
Шашлык Горячее ...
Десерт
...
200 "Хуанхэ"
Дата П
Цена ($)
Вес (кг)
Страна
Город
Пекин Китай
250 0.37 24/8/94
Лук
450
40
"Наталка" Киев
Украина 100 0.52 27/8/94
Масло
7420
30
"Лайма"
Рига
Латвия
70
1.55 30/8/94
Зелень
180
10
"Даугава" Рига
Латвия
15
0.99 30/8/94
1660
180 "Юрмала" Рига
Латвия
200 2.05 30/8/94
450
40
207 1/9/94 Мясо
Лук
Кофе
Поставщ
ик
Закуска Лом. 158 1/9/94 Фасоль 3070
Вес (г)
Калорий
ность
Продукт
Дата Р
Порций
Вид
Рецепт
Блюдо
Лобио
"Полесье" Киев
Томаты 240
100 "Полесье" Киев
Зелень
180
20
"Даугава" Рига
2750
8
"Хуанхэ"
235 1/9/94 Кофе
Украина 50
0.61 27/8/94
Украина 120 0.45 27/8/94
Латвия
Пекин Китай
15
0.99 30/8/94
40
2.87 24/8/94
450
Лобио
Закуска Лом 108 1/9/94 Масло
Лобио
Закуска Лом 108 1/9/94 Зелень
Украина 100 0.52 27/8/94
7420 30
"Лайма"
Рига
Латвия
70
1.55 30/8/94
180
"Даугава" Рига
Латвия
15
0.99 30/8/94
Латвия
200 2.05 30/8/94
10
207 1/9/94 Мясо
1660 180 "Юрмала" Рига
Шашлык Горячее ...
207 1/9/94 Лук
450
Шашлык Горячее ...
207 1/9/94 Томаты 240
100 "Полесье" Киев
Шашлык Горячее ...
207 1/9/94 Зелень
180
20
Кофе
235 1/9/94 Кофе
2750 8
...
250 0.37 24/8/94
"Наталка" Киев
40
Шашлык Горячее ...
Десерт
Дата П
Закуска Лом 108 1/9/94 Лук
Цена ($)
Лобио
Пекин Китай
Вес (кг)
Закуска Лом. 158 1/9/94 Фасоль 3070 200 "Хуанхэ"
Страна
Лобио
Город
Поставщ
ик
Калорий
ность
Вес (г)
Продукт
Дата Р
Вид
Порций
Блюдо
Рецепт
Рис. 3.7. Данные, необходимые для создания базы данных «Питание»
40
"Полесье" Киев
"Даугава" Рига
"Хуанхэ"
Украина 50
0.61 27/8/94
Украина 120 0.45 27/8/94
Латвия
Пекин Китай
15
0.99 30/8/94
40
2.87 24/8/94
Рис. 3.8. Универсальное отношение «Питание»
6. Почему проект БД может быть плохим?
Начинающий проектировщик будет использовать отношение «Питание» (рис. 3.8)
в качестве завершенной БД. Действительно, зачем разбивать отношение «Питание» на
несколько более мелких отношений (см. например, рис. 3.5), если оно заключает в себе
все данные? А разбивать надо потому, что при использовании универсального отношения
возникает несколько проблем:
1. Избыточность. Данные практически всех столбцов многократно повторяются.
Повторяются и некоторые наборы данных (Блюдо-Вид-Рецепт, ПродуктКалорийность, Поставщик-Город-Страна). Нежелательно повторение рецептов,
некоторые из которых намного больше рецепта «Лобио». И уж совсем плохо, что все
данные о блюде (включая рецепт) повторяются каждый раз, когда это блюдо
включается в меню.
2. Потенциальная противоречивость (аномалии обновления). Вследствие избыточности
можно обновить адрес поставщика в одной строке, оставляя его неизменным в других.
Если поставщик кофе сообщил о своем переезде в Харбин и была обновлена строка с
продуктом кофе, то у поставщика «Хуанхэ» появляется два адреса, один из которых не
актуален. Следовательно, при обновлениях необходимо просматривать всю таблицу
для нахождения и изменения всех подходящих строк.
3. Аномалии включения. В БД не может быть записан новый поставщик («Няринга»,
Вильнюс, Литва), если поставляемый им продукт (Огурцы) не используется ни в
одном блюде. Можно, конечно, поместить неопределенные значения в столбцы
Блюдо, Вид, Порций и Вес (г) для этого поставщика. Но если появится блюдо, в
котором используется этот продукт, не забудем ли мы удалить строку с
неопределенными значениями?
По аналогичным причинам нельзя ввести и новый продукт (например,
Баклажаны), который предлагает существующий поставщик (например, «Полесье»). А
как ввести новое блюдо, если в нем используется новый продукт («Крабы»)?
4. Аномалии удаления. Обратная проблема возникает при необходимости удаления всех
продуктов, поставляемых данным поставщиком или всех блюд, использующих эти
продукты. При таких удалениях будут утрачены сведения о таком поставщике.
Многие проблемы этого примера исчезнут, если выделить в отдельные таблицы
сведения о блюдах, рецептах, расходе блюд, продуктах и их поставщиках, а также создать
связующие таблицы «Состав» и «Поставки» (рис. 3.9).
Блюда
Блюдо
Вид
Рецепты
Блюдо
Расход
Рецепт
Блюдо
Порций Дата_Р
Лобио
Закуска
Лобио Ломаную очищ
Лобио
158
1/9/94
Харчо
Суп
...
Харчо
144
1/9/94
Шашлык Горячее
Шашлык 207
1/9/94
Кофе
Десерт
Кофе
235
1/9/94
...
...
...
...
...
...
Продукты
Состав
Поставщики
Продукт Калор.
Блюдо Продукт Вес (г)
Поставщик Город Страна
Фасоль
3070
Лобио Фасоль
200
"Полесье"
Киев
Украина
Лук
450
Лобио Лук
40
"Наталка"
Киев
Украина
Масло
7420
Лобио Масло
30
"Хуанхэ"
Пекин Китай
Зелень
180
Лобио Зелень
10
"Лайма"
Рига
Латвия
Мясо
1660
Харчо Мясо
80
"Юрмала"
Рига
Латвия
...
...
...
...
...
...
...
...
Поставки
Поставщик Город Продукт Вес (кг) Цена ($) Дата_П
"Полесье"
Киев
Томаты
120
0.45
27/8/94
"Полесье"
Киев
Масло
50
1.62
27/8/94
"Полесье"
Киев
Лук
50
0.61
27/8/94
"Наталка"
Киев
Лук
100
0.52
27/8/94
...
...
...
...
...
...
Рис. 3.9. Преобразование универсального отношения «Питание» (первый вариант)
Включение. Простым добавлением строк (Поставщики; "Няринга", Вильнюс,
Литва) и (Поставки; "Няринга", Вильнюс, Огурцы, 40) можно ввести информацию о
новом поставщике. Аналогично можно ввести данные о новом продукте (Продукты;
Баклажаны, 240) и (Поставки; "Полесье", Киев, Баклажаны, 50).
Удаление. Удаление сведений о некоторых поставках или блюдах не приводит к
потере сведений о поставщиках.
Обновление. В таблицах рис. 3.9 все еще много повторяющихся данных,
находящихся в связующих таблицах (Состав и Поставки). Следовательно, в данном
варианте БД сохранилась потенциальная противоречивость: для изменения названия
поставщика с "Полесье" на "Днепро" придется изменять не только строку таблицы
Поставщики, но и множество строк таблицы Поставки. При этом не исключено, что в БД
будут одновременно храниться: "Полесье", "Палесье", "Днепро", "Днипро" и другие
варианты названий. Кроме того, повторяющиеся текстовые данные (такие как название
блюда "Рулет из телячей грудинки с сосисками и гарниром из разноцветного пюре" или
продукта "Колбаса московская сырокопченая") существенно увеличивают объем
хранимых данных.
Для исключения ссылок на длинные текстовые значения последние обычно
нумеруют: нумеруют блюда в больших кулинарных книгах, товары (продукты) в
каталогах и т.д. Воспользуемся этим приемом для исключения избыточного дублирования
данных и появления ошибок при копировании длинных текстовых значений (рис. 3.10).
Теперь при изменении названия поставщика "Полесье" на "Днепро" исправляется
единственное значение в таблице Поставщики. И даже если оно вводится с ошибкой
("Днипро"), то это не может повлиять на связь между поставщиками и продуктами (в
связующей таблице Поставки используются номера поставщиков и продуктов, а не их
названия).
Блюда
БЛ
Рецепты
Блюдо
Вид
Блюдо
Расход
Рецепт
Блюдо
Порций Дата_Р
1
Лобио
Закуска
Лобио Ломаную очищ
Лобио
158
1/9/94
2
Харчо
Суп
...
Харчо
144
1/9/94
3
Шашлык Горячее
Шашлык 207
1/9/94
4
Кофе
Десерт
Кофе
235
1/9/94
...
...
...
...
...
...
...
Продукты
Состав
Поставщики
ПР Продукт Калор.
БЛ ПР Вес (г)
ПОС Поставщик Город Страна
1
Фасоль
3070
1
1
200
1
"Полесье"
Киев
Украина
2
Лук
450
1
2
40
2
"Наталка"
Киев
Украина
3
Масло
7420
1
3
30
3
"Хуанхэ"
Пекин Китай
4
Зелень
180
1
4
10
4
"Лайма"
Рига
Латвия
5
Мясо
1660
2
5
80
5
"Юрмала"
Рига
Латвия
...
...
...
...
...
...
...
...
...
...
Поставки
ПОС ПР Вес (кг) Цена ($) Дата_П
1
6
120
0.45
27/8/94
1
3
50
1.62
27/8/94
1
2
50
0.61
27/8/94
2
2
100
0.52
27/8/94
...
...
...
...
...
Рис. 3.10. Преобразование универсального отношения «Питание» (второй вариант)
Лекция 4. Нормализация
1. Введение ...............................................................................................................................28
2. 1НФ (Первая Нормальная Форма) .....................................................................................29
2.1 Аномалии обновления
30
2.1.1.
Аномалии вставки (INSERT) ..............................................................................30
2.1.2.
Аномалии обновления (UPDATE) .....................................................................30
2.1.3.
Аномалии удаления (DELETE) ..........................................................................31
3. Функциональные зависимости ...........................................................................................31
3.1 Определение функциональной зависимости
31
3.2 Функциональные зависимости отношений и математическое понятие
функциональной зависимости 32
4. 2НФ (Вторая Нормальная Форма) .....................................................................................34
4.1 Определение 34
4.2 Анализ декомпозированных отношений 35
4.2.1.
Оставшиеся аномалии вставки (INSERT) .........................................................35
4.2.2.
Оставшиеся аномалии обновления (UPDATE).................................................36
4.2.3.
Оставшиеся аномалии удаления (DELETE) .....................................................36
5. 3НФ (Третья Нормальная Форма) ......................................................................................36
5.1 Алгоритм нормализации (приведение к 3НФ) 37
6. Сравнение нормализованных и ненормализованных моделей .......................................39
7. НФБК (Нормальная Форма Бойса-Кодда) .............. Ошибка! Закладка не определена.
8. 4НФ (Четвертая Нормальная Форма) ...................... Ошибка! Закладка не определена.
9. 5НФ (Пятая Нормальная Форма) ............................. Ошибка! Закладка не определена.
Список литературы ......................................................................................................................39
1. Введение
Нормализация – это разбиение таблицы на две или более, обладающих лучшими
свойствами при добавлении, изменении и удалении данных.
Окончательная цель нормализации сводится к получению такого проекта базы
данных, в котором каждый факт появляется лишь в одном месте, т.е. исключена
избыточность информации. Это делается не столько с целью экономии памяти, сколько
для исключения возможной противоречивости хранимых данных.
Пример
Рассмотрим в качестве предметной области некоторую организацию, выполняющую
некоторые проекты. Модель предметной области опишем следующим неформальным
текстом:
1. Сотрудники организации выполняют проекты.
2. Проекты состоят из нескольких заданий.
3. Каждый сотрудник может участвовать в одном или нескольких проектах, или
временно не участвовать ни в каких проектах.
4. Над каждым проектом может работать несколько сотрудников, или временно
проект может быть приостановлен, тогда над ним не работает ни один сотрудник.
5. Над каждым заданием в проекте работает ровно один сотрудник.
6. Каждый сотрудник числится в одном отделе.
7. Каждый сотрудник имеет телефон, находящийся в отделе сотрудника.
В ходе дополнительного уточнения того, какие данные необходимо учитывать,
выяснилось следующее:
1. О каждом сотруднике необходимо хранить табельный номер и фамилию.
Табельный номер является уникальным для каждого сотрудника.
2. Каждый отдел имеет уникальный номер.
3. Каждый проект имеет номер и наименование. Номер проекта является
уникальным.
4. Каждая работа из проекта имеет номер, уникальный в пределах проекта. Работы в
разных проектах могут иметь одинаковые номера.
2. 1НФ (Первая Нормальная Форма)
Первая нормальная форма (1НФ) - это обычное отношение. Свойства
отношений (это и будут свойства 1НФ):
­ В отношении нет одинаковых кортежей.
­ Кортежи не упорядочены.
­ Атрибуты не упорядочены и различаются по наименованию.
­ Все значения атрибутов атомарны.
В ходе логического моделирования на первом шаге предложено хранить данные в
одном отношении, имеющем следующие атрибуты:
СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ (Н_СОТР, ФАМ, Н_ОТД, ТЕЛ, Н_ПРО,
ПРОЕКТ, Н_ЗАДАН)
где
Н_СОТР - табельный номер сотрудника,
ФАМ - фамилия сотрудника,
Н_ОТД - номер отдела, в котором числится сотрудник,
ТЕЛ - телефон сотрудника,
Н_ПРО - номер проекта, над которым работает сотрудник,
ПРОЕКТ - наименование проекта, над которым работает сотрудник,
Н_ЗАДАН - номер задания, над которым работает сотрудник.
Т.к. каждый сотрудник в каждом проекте выполняет ровно одно задание, то в
качестве потенциального ключа отношения необходимо взять пару атрибутов (Н_СОТР,
Н_ПРО).
В текущий момент состояние предметной области отражается следующими
фактами:
­ Сотрудник Иванов, работающий в 1 отделе, выполняет в первом проекте "Космос"
задание 1 и во втором проекте "Климат" задание 1.
­ Сотрудник Петров, работающий в 1 отделе, выполняет в первом проекте "Космос"
задание 2.
­ Сотрудник Сидоров, работающий во 2 отделе, выполняет в первом проекте "Космос"
задание 3 и во втором проекте "Климат" задание 2.
Это состояние отражается в таблице 1 (курсивом выделены ключевые атрибуты):
Таблица 1. Отношение СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ
Н_ОТД
ТЕЛ
Н_ПРО ПРОЕКТ Н_ЗАДАН
Н_СОТР
ФАМ
1
Иванов
1
11-22-33
1
Космос
1
1
Иванов
1
11-22-33
2
Климат
1
2
Петров
1
11-22-33
1
Космос
2
3
Сидоров
2
33-22-11
1
Космос
3
3
Сидоров
2
33-22-11
2
Климат
2
2.1 Аномалии обновления
Из
таблицы
1
видно,
что
данные
отношения
СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ хранятся в ней с большой избыточностью. Во
многих строках повторяются фамилии сотрудников, номера телефонов, наименования
проектов. Кроме того, в данном отношении хранятся вместе независимые друг от друга
данные - и данные о сотрудниках, и об отделах, и о проектах, и о работах по проектам.
Пока никаких действий с отношением не производится, это не страшно. Но как только
состояние предметной области изменяется, то, при попытках соответствующим образом
изменить состояние базы данных, возникает большое количество проблем.
Исторически эти проблемы получили название аномалии обновления.
Под аномалией обновления в данном случае подразумевается противоречие
между моделью предметной области и физической моделью данных, поддерживаемых
средствами конкретной СУБД.
Под аномалией обновления будем понимать неадекватность модели данных
предметной области либо некоторые дополнительные трудности в реализации
ограничений предметной области средствами СУБД.
Неадекватность модели данных предметной области по сути означает, что
логическая модель данных попросту неверна или для реализации всех ограничений
определенных в предметной области необходим дополнительный программный код в виде
триггеров или хранимых процедур.
Т.к. аномалии проявляют себя при выполнении операций, изменяющих состояние
базы данных, то различают следующие виды аномалий:
­ аномалии вставки (INSERT),
­ аномалии обновления (UPDATE),
­ аномалии удаления (DELETE).
В отношении СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ можно привести примеры
следующих аномалий:
2.1.1. Аномалии вставки (INSERT)
В отношение СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ нельзя вставить данные о
сотруднике, который пока не участвует ни в одном проекте. Действительно, если,
например, во втором отделе появляется новый сотрудник, скажем, Пушников, и он пока
не участвует ни в одном проекте, то мы должны вставить в отношение кортеж (4,
Пушников, 2, 33-22-11, null, null, null). Это сделать невозможно, т.к. атрибут Н_ПРО
(номер проекта) входит в состав потенциального ключа, и, следовательно, не может
содержать null-значений.
Точно также нельзя вставить данные о проекте, над которым пока не работает ни
один сотрудник.
Причина аномалии - хранение в одном отношении разнородной информации (и о
сотрудниках, и о проектах, и о работах по проекту).
Вывод - логическая модель данных неадекватна модели предметной области. База
данных, основанная на такой модели, будет работать неправильно.
2.1.2. Аномалии обновления (UPDATE)
Фамилии сотрудников, наименования проектов, номера телефонов повторяются во
многих кортежах отношения. Поэтому если сотрудник меняет фамилию, или проект
меняет наименование, или меняется номер телефона, то такие изменения необходимо
одновременно выполнить во всех местах, где эта фамилия, наименование или номер
телефона встречаются, иначе отношение станет некорректным (например, один и тот же
проект в разных кортежах будет называться по-разному). Таким образом, обновление базы
данных одним действием реализовать невозможно. Для поддержания отношения в
целостном состоянии необходимо написать триггер, который при обновлении одной
записи корректно исправлял бы данные и в других местах.
Причина аномалии - избыточность данных, также порожденная тем, что в одном
отношении хранится разнородная информация.
Вывод - увеличивается сложность разработки базы данных. База данных,
основанная на такой модели, будет работать правильно только при наличии
дополнительного программного кода в виде триггеров.
2.1.3. Аномалии удаления (DELETE)
При удалении некоторых данных может произойти потеря другой информации.
Например, если закрыть проект "Космос" и удалить все строки, в которых он встречается,
то будут потеряны все данные о сотруднике Петрове. Если удалить сотрудника Сидорова,
то будет потеряна информация о том, что в отделе номер 2 находится телефон 33-22-11.
Если по проекту временно прекращены работы, то при удалении данных о работах по
этому проекту будут удалены и данные о самом проекте (наименование проекта). При
этом если был сотрудник, который работал только над этим проектом, то будут потеряны
и данные об этом сотруднике.
Причина аномалии - хранение в одном отношении разнородной информации (и о
сотрудниках, и о проектах, и о работах по проекту).
Вывод - логическая модель данных неадекватна модели предметной области. База
данных, основанная на такой модели, будет работать неправильно.
3. Функциональные зависимости
Отношение СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ находится в 1НФ, при этом,
как было показано выше, логическая модель данных не адекватна модели предметной
области. Таким образом, первой нормальной формы недостаточно для правильного
моделирования данных.
3.1 Определение функциональной зависимости
Для устранения указанных аномалий (а на самом деле для правильного
проектирования модели данных!) применяется метод нормализации отношений.
Нормализация основана на понятии функциональной зависимости атрибутов
отношения.
Пусть
- отношение. Множество атрибутов
функционально зависимо от
множества атрибутов
( функционально определяет ) тогда и только тогда, когда
для любого состояния отношения
для любых кортежей
из того, что
следует что
(т.е. во всех кортежах, имеющих одинаковые значения атрибутов
, значения атрибутов
также совпадают в любом состоянии отношения
).
Символически функциональная зависимость записывается
.
Множество атрибутов
называется детерминантом функциональной
зависимости, а множество атрибутов называется зависимой частью.
Замечание. Если атрибуты
составляют потенциальный ключ отношения , то
любой атрибут отношения функционально зависит от .
Пример 1. В отношении СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ можно
привести следующие примеры функциональных зависимостей:
Зависимость атрибутов, характеризующих сотрудника от табельного номера
сотрудника:
Н_СОТР ФАМ
Н_СОТР Н_ОТД
Н_СОТР ТЕЛ
Зависимость наименования проекта от номера проекта:
Н_ПРО ПРОЕКТ
Зависимость номера телефона от номера отдела:
Н_ОТД ТЕЛ
Зависимость атрибутов от ключа отношения:
{Н_СОТР, Н_ПРО} ФАМ
{Н_СОТР, Н_ПРО} Н_ОТД
{Н_СОТР, Н_ПРО} ТЕЛ
{Н_СОТР, Н_ПРО} ПРОЕКТ
{Н_СОТР, Н_ПРО} Н_ЗАДАН
Замечание. Приведенные функциональные зависимости не выведены из внешнего
вида отношения, приведенного в таблице 1. Эти зависимости отражают взаимосвязи,
обнаруженные между объектами предметной области и являются дополнительными
ограничениями, определяемыми предметной областью. Таким образом, функциональная
зависимость - семантическое понятие. Она возникает, когда по значениям одних данных
в предметной области можно определить значения других данных. Например, зная
табельный номер сотрудника, можно определить его фамилию, по номеру отдела можно
определить телефона. Функциональная зависимость задает дополнительные ограничения
на данные, которые могут храниться в отношениях. Для корректности базы данных
(адекватности предметной области) необходимо при выполнении операций модификации
базы данных проверять все ограничения, определенные функциональными
зависимостями.
3.2 Функциональные зависимости отношений и математическое понятие
функциональной зависимости
Функциональная зависимость атрибутов отношения напоминает понятие
функциональной зависимости в математике. Но это не одно и то же. Для сравнения
напомним математическое понятие функциональной зависимости.
Функциональная зависимость (функция) - это тройка объектов
- множество (область определения),
- множество (множество значений),
- правило, согласно которому каждому элементу
только один элемент
, где
ставится в соответствие один и
(правило функциональной зависимости).
Функциональная зависимость обычно обозначается как
или
.
Замечание. Правило
может быть задано любым способом - в виде формулы
(чаще всего), при помощи таблицы значений, при помощи графика, текстовым описанием
и т.д.
Функциональная зависимость атрибутов отношения тоже напоминает это
определение. Действительно:
­ В качестве области определения выступает домен, на котором определен атрибут
(или декартово произведение доменов, если является множеством атрибутов)
­ В качестве множества значений выступает домен, на котором определен атрибут
(или декартово произведение доменов)
­ Правило реализуется следующим алгоритмом - 1) по данному значению атрибута
найти любой кортеж отношения, содержащий это значение, 2) значение атрибута в
этом кортеже и будет значением функциональной зависимости, соответствующим
данному . Определение функциональной зависимости в отношении гарантирует, что
найденное значение не зависит от выбора кортежа, поэтому правило
определено корректно.
Отличие от математического понятия отношения состоит в том, что, если
рассматривать математическое понятие функции, то для фиксированного значения
соответствующее значение функции
всегда одно и то же. Например, если задана
функция
, то для значения
соответствующее значение всегда будет равно 4.
В противоположность этому в отношениях значение зависимого атрибута может
принимать различные значения в различных состояниях базы данных.
Например, атрибут ФАМ функционально зависит от атрибута Н_СОТР.
Предположим, что сейчас сотрудник с табельным номером 1 имеет фамилию Иванов, т.е.
при значении детерминанта равного 1, значение зависимого аргумента равно "Иванов". Но
сотрудник может сменить фамилию, например на "Сидоров". Теперь при том же
значении детерминанта, равного 1, значение зависимого аргумента равно "Сидоров".
Таким образом, понятие функциональной зависимости атрибутов нельзя считать
полностью эквивалентным математическому понятию функциональной зависимости, т.к.
значение этой зависимости различны при разных состояниях отношения, и, самое главное,
эти значения могут меняться непредсказуемо.
Функциональная зависимость атрибутов утверждает лишь то, что для каждого
конкретного состояния базы данных по значению одного атрибута (детерминанта) можно
однозначно определить значение другого атрибута (зависимой части). Но конкретные
значение зависимой части могут быть различны в различных состояниях базы данных.
4. 2НФ (Вторая Нормальная Форма)
4.1 Определение
Отношение находится во второй нормальной форме (2НФ) тогда и только
тогда, когда отношение находится в 1НФ и нет неключевых атрибутов, зависящих от
части сложного ключа. (Неключевой атрибут - это атрибут, не входящий в состав
никакого потенциального ключа).
Замечание. Если потенциальный ключ отношения является простым, то отношение
автоматически находится в 2НФ.
Отношение СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ не находится в 2НФ, т.к. есть
атрибуты, зависящие от части сложного ключа:
Зависимость атрибутов, характеризующих сотрудника от табельного номера
сотрудника является зависимостью от части сложного ключа:
Н_СОТР ФАМ
Н_СОТР Н_ОТД
Н_СОТР ТЕЛ
Зависимость наименования проекта от номера проекта является зависимостью от части
сложного ключа:
Н_ПРО ПРОЕКТ
Для того, чтобы устранить зависимость атрибутов от части сложного ключа, нужно
произвести декомпозицию отношения на несколько отношений. При этом те атрибуты,
которые зависят от части сложного ключа, выносятся в отдельное отношение.
Отношение СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ декомпозируем на три
отношения - СОТРУДНИКИ_ОТДЕЛЫ, ПРОЕКТЫ, ЗАДАНИЯ.
Отношение СОТРУДНИКИ_ОТДЕЛЫ (Н_СОТР, ФАМ, Н_ОТД, ТЕЛ):
Функциональные зависимости:
Зависимость атрибутов, характеризующих сотрудника от табельного номера
сотрудника:
Н_СОТР ФАМ
Н_СОТР Н_ОТД
Н_СОТР ТЕЛ
Зависимость номера телефона от номера отдела:
Н_ОТД ТЕЛ
Таблица 2. Отношение СОТРУДНИКИ_ОТДЕЛЫ
Н_СОТР ФАМ Н_ОТД ТЕЛ
1
Иванов
1
11-22-33
2
Петров
1
11-22-33
3
Сидоров
2
33-22-11
Отношение ПРОЕКТЫ (Н_ПРО, ПРОЕКТ):
Функциональные зависимости:
Н_ПРО ПРОЕКТ
Таблица 3. Отношение ПРОЕКТЫ
Н_ПРО ПРОЕКТ
1
Космос
2
Климат
Отношение ЗАДАНИЯ (Н_СОТР, Н_ПРО, Н_ЗАДАН):
Функциональные зависимости:
(Н_СОТР, Н_ПРО)
Н_ЗАДАН
Таблица 4. Отношения ЗАДАНИЯ
Н_СОТР Н_ПРО Н_ЗАДАН
1
1
1
1
2
1
2
1
2
3
1
3
3
2
2
4.2 Анализ декомпозированных отношений
Отношения, полученные в результате декомпозиции, находятся в 2НФ.
Действительно, отношения СОТРУДНИКИ_ОТДЕЛЫ и ПРОЕКТЫ имеют простые
ключи, следовательно, автоматически находятся в 2НФ, отношение ЗАДАНИЯ имеет
сложный ключ, но единственный неключевой атрибут Н_ЗАДАН функционально зависит
от всего ключа {Н_СОТР, Н_ПРО}.
Часть аномалий обновления устранена. Так, данные о сотрудниках и проектах
теперь хранятся в различных отношениях, поэтому при появлении сотрудников, не
участвующих ни в одном проекте просто добавляются кортежи в отношение
СОТРУДНИКИ_ОТДЕЛЫ. Точно также, при появлении проекта, над которым не
работает ни один сотрудник, просто вставляется кортеж в отношение ПРОЕКТЫ.
Фамилии сотрудников и наименования проектов теперь хранятся без
избыточности. Если сотрудник сменит фамилию или проект сменит наименование, то
такое обновление будет произведено в одном месте.
Если по проекту временно прекращены работы, но требуется, чтобы сам проект
сохранился, то для этого проекта удаляются соответствующие кортежи в отношении
ЗАДАНИЯ, а данные о самом проекте и данные о сотрудниках, участвовавших в проекте,
остаются в отношениях ПРОЕКТЫ и СОТРУДНИКИ_ОТДЕЛЫ.
Тем не менее, часть аномалий разрешить не удалось.
4.2.1. Оставшиеся аномалии вставки (INSERT)
В отношение СОТРУДНИКИ_ОТДЕЛЫ нельзя вставить кортеж (4, Пушников, 1,
33-22-11), т.к. при этом получится, что два сотрудника из 1-го отдела (Иванов и
Пушников) имеют разные номера телефонов, а это противоречит модели предметной
области. В этой ситуации можно предложить два решения, в зависимости от того, что
реально произошло в предметной области. Другой номер телефона может быть введен по
двум причинам - по ошибке человека, вводящего данные о новом сотруднике, или потому
что номер в отделе действительно изменился. Тогда можно написать триггер, который при
вставке записи о сотруднике проверяет, совпадает ли телефон с уже имеющимся
телефоном у другого сотрудника этого же отдела. Если номера отличаются, то система
должна задать вопрос, оставить ли старый номер в отделе или заменить его новым. Если
нужно оставить старый номер (новый номер введен ошибочно), то кортеж с данными о
новом сотруднике будет вставлен, но номер телефона будет у него будет тот, который уже
есть в отделе (в данном случае, 11-22-33). Если же номер в отделе действительно
изменился, то кортеж будет вставлен с новым номером, и одновременно будут изменены
номера телефонов у всех сотрудников этого же отдела. И в том и в другом случае не
обойтись без разработки громоздкого триггера.
Причина аномалии - избыточность данных, порожденная тем, что в одном
отношении хранится разнородная информация (о сотрудниках и об отделах).
Вывод - увеличивается сложность разработки базы данных. База данных,
основанная на такой модели, будет работать правильно только при наличии
дополнительного программного кода в виде триггеров.
4.2.2. Оставшиеся аномалии обновления (UPDATE)
Одни и те же номера телефонов повторяются во многих кортежах отношения.
Поэтому если в отделе меняется номер телефона, то такие изменения необходимо
одновременно выполнить во всех местах, где этот номер телефона встречаются, иначе
отношение станет некорректным. Таким образом, обновление базы данных одним
действием реализовать невозможно. Необходимо написать триггер, который при
обновлении одной записи корректно исправляет номера телефонов в других местах.
Причина аномалии - избыточность данных, также порожденная тем, что в одном
отношении хранится разнородная информация.
Вывод - увеличивается сложность разработки базы данных. База данных,
основанная на такой модели, будет работать правильно только при наличии
дополнительного программного кода в виде триггеров.
4.2.3. Оставшиеся аномалии удаления (DELETE)
При удалении некоторых данных по-прежнему может произойти потеря другой
информации. Например, если удалить сотрудника Сидорова, то будет потеряна
информация о том, что в отделе номер 2 находится телефон 33-22-11.
Причина аномалии - хранение в одном отношении разнородной информации (и о
сотрудниках, и об отделах).
Вывод - логическая модель данных неадекватна модели предметной области. База
данных, основанная на такой модели, будет работать неправильно.
Заметим, что при переходе ко второй нормальной форме отношения стали почти
адекватными предметной области. Остались также трудности в разработке базы данных,
связанные с необходимостью написания триггеров, поддерживающих целостность базы
данных. Эти трудности теперь связаны только с одним отношением
СОТРУДНИКИ_ОТДЕЛЫ.
5. 3НФ (Третья Нормальная Форма)
Атрибуты называются взаимно независимыми, если ни один из них не является
функционально зависимым от другого.
Отношение находится в третьей нормальной форме (3НФ) тогда и только
тогда, когда отношение находится в 2НФ и все неключевые атрибуты взаимно
независимы.
Отношение СОТРУДНИКИ_ОТДЕЛЫ не находится в 3НФ, т.к. имеется
функциональная зависимость неключевых атрибутов (зависимость номера телефона от
номера отдела):
Н_ОТД ТЕЛ
Для того, чтобы устранить зависимость неключевых атрибутов, нужно произвести
декомпозицию отношения на несколько отношений. При этом те неключевые атрибуты,
которые являются зависимыми, выносятся в отдельное отношение.
Отношение СОТРУДНИКИ_ОТДЕЛЫ декомпозируем на два отношения СОТРУДНИКИ, ОТДЕЛЫ.
Отношение СОТРУДНИКИ (Н_СОТР, ФАМ, Н_ОТД):
Функциональные зависимости:
Зависимость атрибутов, характеризующих сотрудника от табельного номера
сотрудника:
Н_СОТР
Н_СОТР
Н_СОТР
ФАМ
Н_ОТД
ТЕЛ
Таблица 5. Отношение СОТРУДНИКИ
Н_ОТД
Н_СОТР
ФАМ
1
Иванов
1
2
Петров
1
3
Сидоров
2
Отношение ОТДЕЛЫ (Н_ОТД, ТЕЛ):
Функциональные зависимости:
Зависимость номера телефона от номера отдела:
Н_ОТД ТЕЛ
Таблица 6. Отношение ОТДЕЛЫ
Н_ОТД
ТЕЛ
1
11-22-33
2
33-22-11
Обратим внимание на то, что атрибут Н_ОТД, не являвшийся ключевым в
отношении СОТРУДНИКИ_ОТДЕЛЫ, становится потенциальным ключом в
отношении ОТДЕЛЫ. Именно за счет этого устраняется избыточность, связанная с
многократным хранением одних и тех же номеров телефонов.
Вывод. Таким образом, все обнаруженные аномалии обновления устранены.
Реляционная модель, состоящая из четырех отношений СОТРУДНИКИ, ОТДЕЛЫ,
ПРОЕКТЫ, ЗАДАНИЯ, находящихся в третьей нормальной форме, является адекватной
описанной модели предметной области, и требует наличия только тех триггеров, которые
поддерживают ссылочную целостность. Такие триггеры являются стандартными и не
требуют больших усилий в разработке.
5.1 Алгоритм нормализации (приведение к 3НФ)
Итак, алгоритм нормализации (т.е. алгоритм приведения отношений к 3НФ)
описывается следующим образом.
Шаг 1 (Приведение к 1НФ). На первом шаге задается одно или несколько
отношений, отображающих понятия предметной области. По модели предметной области
(не по внешнему виду полученных отношений!) выписываются обнаруженные
функциональные зависимости. Все отношения автоматически находятся в 1НФ.
Шаг 2 (Приведение к 2НФ). Если в некоторых отношениях обнаружена
зависимость атрибутов от части сложного ключа, то проводим декомпозицию этих
отношений на несколько отношений следующим образом: те атрибуты, которые зависят
от части сложного ключа выносятся в отдельное отношение вместе с этой частью ключа.
В исходном отношении остаются все ключевые атрибуты:
Исходное отношение:
.
Ключ:
- сложный.
Функциональные зависимости:
- зависимость всех атрибутов от ключа отношения.
- зависимость некоторых атрибутов от части сложного ключа.
Декомпозированные отношения:
- остаток от исходного отношения. Ключ
.
- атрибуты, вынесенные из исходного отношения вместе с частью
сложного ключа. Ключ
.
Шаг 3 (Приведение к 3НФ). Если в некоторых отношениях обнаружена
зависимость некоторых неключевых атрибутов других неключевых атрибутов, то
проводим декомпозицию этих отношений следующим образом: те неключевые атрибуты,
которые зависят других неключевых атрибутов выносятся в отдельное отношение. В
новом отношении ключом становится детерминант функциональной зависимости:
Исходное отношение:
Ключ: .
Функциональные зависимости:
.
- зависимость всех атрибутов от ключа отношения.
- зависимость
неключевых атрибутов.
Декомпозированные отношения:
некоторых
неключевых
- остаток от исходного отношения. Ключ
атрибутов
других
.
- атрибуты, вынесенные из исходного отношения вместе с
детерминантом функциональной зависимости. Ключ
.
Замечание. На практике, при создании логической модели данных, как правило, не
следуют прямо приведенному алгоритму нормализации. Опытные разработчики обычно
сразу строят отношения в 3НФ. Кроме того, основным средством разработки логических
моделей данных являются различные варианты ER-диаграмм. Особенность этих диаграмм
в том, что они сразу позволяют создавать отношения в 3НФ. Тем не менее, приведенный
алгоритм важен по двум причинам. Во-первых, этот алгоритм показывает, какие проблемы
возникают при разработке слабо нормализованных отношений. Во-вторых, как правило,
модель предметной области никогда не бывает правильно разработана с первого шага.
Эксперты предметной области могут забыть о чем-либо упомянуть, разработчик может
неправильно понять эксперта, во время разработки могут измениться правила, принятые в
предметной области, и т.д. Все это может привести к появлению новых зависимостей,
которые отсутствовали в первоначальной модели предметной области. Тут как раз и
необходимо использовать алгоритм нормализации хотя бы для того, чтобы убедиться, что
отношения остались в 3НФ и логическая модель не ухудшилась.
6. Сравнение нормализованных и ненормализованных моделей
Соберем воедино результаты анализа критериев, по которым мы хотели оценить
влияние логического моделирования данных на качество физических моделей данных и
производительность базы данных:
Критерий
Отношения слабо
Отношения сильно
нормализованы
нормализованы
(1НФ, 2НФ)
(3НФ)
Адекватность базы данных
предметной области
Легкость разработки и
сопровождения базы данных
Скорость выполнения вставки,
обновления, удаления
ХУЖЕ (-)
ЛУЧШЕ (+)
СЛОЖНЕЕ (-)
ЛЕГЧЕ (+)
МЕДЛЕННЕЕ (-)
БЫСТРЕЕ (+)
Скорость выполнения выборки
БЫСТРЕЕ (+)
МЕДЛЕННЕЕ (-)
данных
Как видно из таблицы, более сильно нормализованные отношения оказываются
лучше спроектированы (три плюса, один минус). Они больше соответствуют предметной
области, легче в разработке, для них быстрее выполняются операции модификации базы
данных. Правда, это достигается ценой некоторого замедления выполнения операций
выборки данных.
У слабо нормализованных отношений единственное преимущество - если к базе
данных обращаться только с запросами на выборку данных, то для слабо
нормализованных отношений такие запросы выполняются быстрее. Это связано с тем, что
в таких отношениях уже как бы произведено соединение отношений и на это не тратится
время при выборке данных.
Таким образом, выбор степени нормализации отношений зависит от характера
запросов, с которыми чаще всего обращаются к базе данных.
Список литературы
1. Пушников А.Ю. Введение в системы управления базами данных. Часть 1. Реляционная
модель данных: Учебное пособие/Изд-е Башкирского ун-та. - Уфа, 1999. - 108 с. - ISBN
5-7477-0350-1.
2. Пушников А.Ю. Введение в системы управления базами данных. Часть 2. Нормальные
формы отношений и транзакции: Учебное пособие/Изд-е Башкирского ун-та. - Уфа,
1999.
138
с.
ISBN
5-7477-0351-X.
(http://www.citforum.ru/database/dblearn/dblearn00.shtml)
Лекция 5. Целостность реляционных данных
1.
2.
3.
4.
5.
6.
7.
Null-значения .........................................................................................................................40
Потенциальные ключи ..........................................................................................................41
Целостность сущностей ........................................................................................................41
Внешние ключи .....................................................................................................................41
Целостность внешних ключей .............................................................................................44
Замечания к правилам целостности сущностей и внешних ключей ................................44
Операции, которые могут нарушить ссылочную целостность .........................................45
7.1
Для родительского отношения .......................................................................45
7.2
Для дочернего отношения ..............................................................................45
8. Стратегии поддержания ссылочной целостности ..............................................................46
9. Выводы47
Список литературы ......................................................................................................................47
Для реляционной модели данных определяются два ограничения, которые должны
выполняться в любой реляционной базе данных:
­ целостность сущностей,
­ целостность внешних ключей.
Прежде, чем говорить о целостности сущностей, опишем использование nullзначений в реляционных базах данных.
1. Null-значения
Основное назначение баз данных состоит в том, чтобы хранить и предоставлять
информацию о реальном мире. Для представления этой информации в базе данных
используются привычные для программистов типы данных - строковые, численные,
логические и т.п. Однако в реальном мире часто встречается ситуация, когда данные
неизвестны или не полны. Например, место жительства или дата рождения человека могут
быть неизвестны (база данных разыскиваемых преступников). Если вместо неизвестного
адреса уместно было бы вводить пустую строку, то что вводить вместо неизвестной даты?
Ответ - пустую дату - не вполне удовлетворителен, т.к. простейший запрос "выдать
список людей в порядке возрастания дат рождения" даст заведомо неправильных ответ.
Для того чтобы обойти проблему неполных или неизвестных данных, в базах
данных могут использоваться типы данных, пополненные так называемым nullзначением. Null-значение - это, собственно, не значение, а некий маркер, показывающий,
что значение неизвестно.
Таким образом, в ситуации, когда возможно появление неизвестных или неполных
данных, разработчик имеет на выбор два варианта.
Первый вариант состоит в том, чтобы ограничиться использованием обычных
типов данных и не использовать null-значения, а вместо неизвестных данных вводить
либо нулевые значения, либо значения специального вида - например, договориться, что
строка "АДРЕС НЕИЗВЕСТЕН" и есть те данные, которые нужно вводить вместо
неизвестного адреса. В любом случае на пользователя (или на разработчика) ложится
ответственность на правильную трактовку таких данных. В частности, может
потребоваться написание специального программного кода, который в нужных случаях
"вылавливал" бы такие данные. Проблемы, возникающие при этом очевидны - не все
данные становятся равноправны, требуется дополнительный программный код,
"отслеживающий" эту неравноправность, в результате чего усложняется разработка и
сопровождение приложений.
Второй вариант состоит в использовании null-значений вместо неизвестных
данных. За кажущейся естественностью такого подхода скрываются менее очевидные и
более глубокие проблемы. В этом случае при неаккуратном формулировании запросов,
даже самые естественные запросы могут давать неправильные ответы. Есть более
фундаментальные проблемы, связанные с теоретическим обоснованием корректности
введения null-значений, например, непонятно вообще, входят ли null-значения в домены
или нет. Практически все реализации современных реляционных СУБД позволяют
использовать null-значения, несмотря на их недостаточную теоретическую
обоснованность.
2. Потенциальные ключи
По определению, тело отношения есть множество кортежей, поэтому отношения
не могут содержать одинаковые кортежи. Это значит, что каждый кортеж должен
обладать свойством уникальности. На самом деле, свойством уникальности в пределах
отношения могут обладать отдельные атрибуты кортежей или группы атрибутов. Такие
уникальные атрибуты удобно использовать для идентификации кортежей.
Пусть дано отношение
. Подмножество атрибутов
отношения
будем
называть потенциальным ключом, если
обладает следующими свойствами:
1. Свойством уникальности - в отношении не может быть двух различных кортежей,
с одинаковым значением .
2. Свойством неизбыточности - никакое подмножество в не обладает свойством
уникальности.
Любое отношение имеет по крайней мере один потенциальный ключ.
Действительно, если никакой атрибут или группа атрибутов не являются потенциальным
ключом, то, в силу уникальности кортежей, все атрибуты вместе образуют потенциальный
ключ.
Потенциальный ключ, состоящий из одного атрибута, называется простым.
Потенциальный ключ, состоящий из нескольких атрибутов, называется
составным.
Отношение может иметь несколько потенциальных ключей. Традиционно, один из
потенциальных ключей объявляется первичным, а остальные - альтернативными.
Различия между первичным и альтернативными ключами могут быть важны в конкретной
реализации реляционной СУБД, но с точки зрения реляционной модели данных, нет
оснований выделять таким образом один из потенциальных ключей.
Замечание 1. Потенциальные ключи служат средством идентификации объектов
предметной области, данные о которых хранятся в отношении. Объекты предметной
области должны быть различимы.
Замечание 2. Потенциальные ключи служат единственным средством адресации на
уровне кортежей в отношении. Точно указать какой-нибудь кортеж можно, только зная
значение его потенциального ключа.
3. Целостность сущностей
Т.к. потенциальные ключи фактически служат идентификаторами объектов
предметной области (т.е. предназначены для различения объектов), то значения этих
идентификаторов не могут содержать неизвестные значения. Действительно, если бы
идентификаторы могли содержать null-значения, то мы не могли бы дать ответ "да" или
"нет" на вопрос, совпадают или нет два идентификатора.
Это определяет следующее правило целостности сущностей - атрибуты,
входящие в состав некоторого потенциального ключа не могут принимать null-значений.
4. Внешние ключи
Различные объекты предметной области, информация о которых хранится в базе
данных, всегда взаимосвязаны друг с другом. Например, накладная на поставку товара
содержит список товаров с количествами и ценами, сотрудник предприятия имеет детей,
числится в подразделении и т.д. Термины "содержит", "имеет", "числится" отражают
взаимосвязи между понятиями "накладная" и "список товаров", "сотрудник" и "дети",
"сотрудник" и "подразделение". Такие взаимосвязи отражаются в реляционных базах
данных при помощи внешних ключей, связывающих несколько отношений.
Рассмотрим пример с поставщиками и поставками деталей. Предположим, что нам
требуется хранить информацию о наименовании поставщиков, наименовании и
количестве поставляемых ими деталей, причем каждый поставщик может поставлять
несколько деталей и каждая деталь может поставляться несколькими поставщиками.
Можно предложить хранить данные в следующем отношении.
Номер
поставщика
Таблица 5. Отношение "Поставщики и поставляемые детали"
Наименование
Номер
Наименование
Поставляемое
поставщика
детали
детали
количество
1
Иванов
1
Болт
100
1
Иванов
2
Гайка
200
1
Иванов
3
Винт
300
2
Петров
1
Болт
150
2
Петров
2
Гайка
250
3
Сидоров
3
Винт
1000
Потенциальным ключом этого отношения может выступать пара атрибутов
{"Номер поставщика", "Номер детали"} - в таблице они выделены курсивом.
Приведенный способ хранения данных обладает рядом недостатков.
Что произойдет, если изменилось наименование поставщика? Т.к. наименование
поставщика повторяется во многих кортежах отношения, то это наименование нужно
одновременно изменить во всех кортежах, где оно встречается, иначе данные станут
противоречивыми. То же самое с наименованиями деталей. Значит, данные хранятся в
нашем отношении с большой избыточностью.
Далее, как отразить факт, что некоторый поставщик, например Петров, временно
прекратил поставки деталей? Если мы удалим все кортежи, в которых хранится
информация о поставках этого поставщика, то мы потеряем данные о самом Петрове как
потенциальном поставщике. Выйти из этого положения, оставив в отношении кортеж
типа (2, Петров, NULL, NULL, NULL) мы не можем, т.к. атрибут "Номер детали" входит в
состав потенциального ключа и не может содержать null-значений. То же самое
произойдет, если некоторая деталь временно не поставляется никаким поставщиком.
Получается, что мы не можем хранить информацию о том, что есть некий поставщик, если
он не поставляет хотя бы одну деталь, и не можем хранить информацию о том, что есть
некоторая деталь, если она никем не поставляется.
Подобные проблемы возникают потому, что мы смешали в одном отношении
различные объекты предметной области - и данные о поставщиках, и данные о деталях, и
данные о поставках деталей. Говорят, что это отношение плохо нормализовано.
Разобъем данные по трем отношениям - "Поставщики", "Детали", "Поставки". Для
нас важно выяснить, каким образом данные, хранящиеся в этих отношениях
взаимосвязаны друг с другом. Эта связь определяется семантикой предметной области и
описывается фразами: "Поставщики выполняют Поставки", "Детали поставляются через
Поставки". Эти две взаимосвязи косвенно определяют новую взаимосвязь между
"Поставщиками" и "Деталями": "Детали поставляются Поставщиками".
Эти фразы отражают различные типы взаимосвязей. Чтобы более точно отразить
предметную область, можно иначе переформулировать фразы: "Один Поставщик может
выполнять несколько Поставок", "Одна Деталь может поставляться несколькими
Поставками". Это пример взаимосвязи типа "один-ко-многим".
Взаимосвязь между "Поставщиками" и "Деталями" можно переформулировать так:
"Несколько Деталей может поставляться несколькими Поставщиками". Это пример
взаимосвязи типа "много-ко-многим".
В реляционных базах данных основными являются взаимосвязи типа "один-комногим". Взаимосвязи типа "много-ко-многим" реализуются использованием нескольких
взаимосвязей типа "один-ко-многим". Отношение, входящее в связь со стороны "один"
(например, "Поставщики"), называют родительским отношением. Отношение, входящее
в связь со стороны "много" (например, "Поставки"), называется дочернем отношением.
Механизм реализации взаимосвязи "один-ко-многим" состоит в том, что в дочернее
отношение добавляются атрибуты, являющиеся ссылками на ключевые атрибуты
родительского отношения. Эти атрибуты и являются внешними ключами,
определяющими, с какими кортежами родительского отношения связаны кортежи
дочернего отношения. Такие атрибуты еще называют мигрирующими из родительского
отношения.
Таким образом, наш пример с поставщиками и поставляемыми деталями должен
выглядеть следующим образом:
Таблица 6. Отношение "Поставщики"
Номер
Наименование
поставщика
поставщика
1
Иванов
2
Петров
3
Сидоров
Таблица 7. Отношение "Детали"
Номер детали Наименование детали
1
Болт
2
Гайка
3
Винт
Таблица 8. Отношение "Поставки"
Номер поставщика Номер детали Поставляемое количество
1
1
100
1
2
200
1
3
300
2
1
150
2
2
250
3
3
1000
В отношении "Поставки" атрибуты "Номер поставщика" и "Номер детали"
являются ссылками на ключевые атрибуты отношений "Поставщики" и "Детали", и,
следовательно, являются внешними ключами. Заметим, что данные отношения свободны
от недостатков, описанных выше, когда все данные предлагалось хранить в одном
отношении. Действительно, при изменении наименования поставщика или детали, это
изменение происходит только в одном месте. Если поставщик прекратил поставки всех
деталей, то удаляются соответствующие кортежи в отношении "Поставки", данные же о
самом поставщике остаются без изменений.
Дадим точное определение.
Пусть дано отношение . Подмножество атрибутов
отношения
будем
называть внешним ключом, если:
1. Существует отношение
(
и не обязательно различны) с потенциальным
ключом .
2. Каждое значение
в отношении
всегда совпадает со значением
для
некоторого кортежа из , либо является null-значением.
Отношение называется родительским отношением, отношение называется
дочерним отношением.
Замечание 1. Внешний ключ, также как и потенциальный, может быть простым и
составным.
Замечание 2. Внешний ключ должен быть определен на тех же доменах, что и
соответствующий первичный ключ родительского отношения.
Замечание 3. Внешний ключ, как правило, не обладает свойством уникальности.
Так и должно быть, т.к. в дочернем отношении может быть несколько кортежей,
ссылающихся на один и тот же кортеж родительского отношения. Это, собственно, и дает
тип отношения "один-ко-многим".
Замечание 4. Если внешний ключ все-таки обладает свойством уникальности, то
связь между отношениями имеет тип "один-к-одному". Чаще всего такие отношения
объединяются в одно отношение, хотя это и не обязательно.
Замечание 5. Хотя каждое значение внешнего ключа обязано совпадать со
значениями потенциального ключа в некотором кортеже родительского отношения, то
обратное, вообще говоря, неверно. Например, могут существовать поставщики, не
поставляющие никаких деталей.
Замечание 6. Для внешнего ключа не требуется, чтобы он был компонентом
некоторого потенциального ключа (как получилось в примере с поставщиками и
деталями).
Замечание 7. Null-значения для атрибутов внешнего ключа допустимы только в том
случае, когда атрибуты внешнего ключа не входят в состав никакого потенциального
ключа.
5. Целостность внешних ключей
Т.к. внешние ключи фактически служат ссылками на кортежи в другом (или в том
же самом) отношении, то эти ссылки не должны указывать на несуществующие объекты.
Это определяет правило целостности внешних ключей - внешние ключи не
должны быть несогласованными, т.е. для каждого значения внешнего ключа должно
существовать соответствующее значение первичного ключа в родительском
отношении.
6. Замечания к правилам целостности сущностей и внешних ключей
На самом деле приведенные правила целостности сущностей и внешних ключей
прямо следуют из определений понятий "потенциальный ключ" и "внешний ключ".
Действительно, в определении потенциального ключа требуется, чтобы
потенциальный ключ обладал свойством уникальности. Это фактически означает, что мы
должны уметь различать значения потенциальных ключей, т.е. при сравнении двух
значений потенциального ключа мы всегда должны получать значения либо ИСТИНА,
либо ЛОЖЬ. Но любое сравнение, в которое входит null-значение, принимает значение U НЕИЗВЕСТНО, откуда следует, что атрибуты потенциального ключа не могут содержать
null-значений.
Для внешних ключей правило целостности фактически входит в определение (п. 2
определения).
Таким образом, с точки зрения реляционной теории, явная формулировка правил
целостности является излишней - они автоматически вытекают из определений понятий
ключа и внешнего ключа.
Тем не менее, явная формулировка правил целостности имеет определенный
практический смысл. В большинстве серьезных СУБД за выполнением этих ограничений
следит сама СУБД, если, конечно, пользователь явно объявил потенциальные и внешние
ключи. Но, во-первых, для некоторых систем можно допустить, чтобы эти ограничения не
выполнялись, а во-вторых, некоторые системы просто не поддерживают понятия
целостности, например, некоторые "настольные" СУБД типа FoxPro 2.5. В этих случаях за
целостностью данных должен следить сам пользователь, или программист,
разрабатывающий приложение для пользователя.
Явная формулировка правил целостности помогает четко понять, какие опасности
несет в себе пренебрежение этими правилами.
7. Операции, которые могут нарушить ссылочную целостность
Ссылочная целостность может нарушиться в результате операций, изменяющих
состояние базы данных. Таких операций три - вставка, обновление и удаление кортежей в
отношениях. Т.к. в определении ссылочной целостности участвуют два отношения родительское и дочернее, а в каждом из них возможны три операции - вставка,
обновление, удаление, то нужно рассмотреть шесть различных вариантов.
7.1
Для родительского отношения
1. Вставка кортежа в родительском отношении. При вставке кортежа в родительское
отношение возникает новое значение потенциального ключа. Т.к. допустимо
существование кортежей в родительском отношении, на которые нет ссылок из
дочернего отношения, то вставка кортежей в родительское отношение не нарушает
ссылочной целостности.
2. Обновление кортежа в родительском отношении. При обновлении кортежа в
родительском отношении может измениться значение потенциального ключа. Если
есть кортежи в дочернем отношении, ссылающиеся на обновляемый кортеж, то
значения их внешних ключей станут некорректными. Обновление кортежа в
родительском отношении может привести к нарушению ссылочной целостности,
если это обновление затрагивает значение потенциального ключа.
3. Удаление кортежа в родительском отношении. При удалении кортежа в
родительском отношении удаляется значение потенциального ключа. Если есть
кортежи в дочернем отношении, ссылающиеся на удаляемый кортеж, то значения их
внешних ключей станут некорректными. Удаление кортежей в родительском
отношении может привести к нарушению ссылочной целостности.
7.2 Для дочернего отношения
1. Вставка кортежа в дочернее отношение. Нельзя вставить кортеж в дочернее
отношение, если вставляемое значение внешнего ключа некорректно. Вставка кортежа
в дочернее отношение привести к нарушению ссылочной целостности.
2. Обновление кортежа в дочернем отношении. При обновлении кортежа в дочернем
отношении можно попытаться некорректно изменить значение внешнего ключа.
Обновление кортежа в дочернем отношении может привести к нарушению ссылочной
целостности.
3. Удаление кортежа в дочернем отношении. При удалении кортежа в дочернем
отношении ссылочная целостность не нарушается.
Таким образом, ссылочная целостность в принципе может быть нарушена при
выполнении одной из четырех операций:
 Обновление кортежа в родительском отношении.
 Удаление кортежа в родительском отношении.


Вставка кортежа в дочернее отношение.
Обновление кортежа в дочернем отношении.
8. Стратегии поддержания ссылочной целостности
Существуют две основные стратегии поддержания ссылочной целостности.
1. RESTRICT (ОГРАНИЧИТЬ) – не разрешать выполнение операции, приводящей к
нарушению ссылочной целостности. Это самая простая стратегия, требующая только
проверки, имеются ли кортежи в дочернем отношении, связанные с некоторым кортежем
в родительском отношении.
2. CASCADE (КАСКАДИРОВАТЬ) – разрешить выполнение требуемой операции, но
внести при этом необходимые поправки в других отношениях так, чтобы не допустить
нарушения ссылочной целостности и сохранить все имеющиеся связи. Изменение
начинается в родительском отношении и каскадно выполняется в дочернем отношении. В
реализации этой стратегии имеется одна тонкость, заключающаяся в том, что дочернее
отношение само может быть родительским для некоторого третьего отношения. При этом
может дополнительно потребоваться выполнение какой-либо стратегии и для этой связи и
т.д. Если при этом какая-либо из каскадных операций (любого уровня) не может быть
выполнена, то необходимо отказаться от первоначальной операции и вернуть базу данных
в исходное состояние. Это самая сложная стратегия, но она хороша тем, что при этом не
нарушается связь между кортежами родительского и дочернего отношений.
Эти стратегии являются стандартными и присутствуют во всех СУБД, в которых
имеется поддержка ссылочной целостности.
9. Выводы
1. Современные СУБД допускают использование null-значений, т.к. данные часто
бывают неполными или неизвестными. Споры о допустимости использования nullзначений ведутся до сих пор.
2. Средством, позволяющим однозначно идентифицировать кортежи отношения,
являются потенциальные ключи отношения.
3. Потенциальный ключ отношения - это набор атрибутов отношения, обладающий
свойствами уникальности и неизбыточности. Доступ к конкретному кортежу можно
получить, лишь зная значение потенциального ключа для этого кортежа.
4. Традиционно один из потенциальных ключей объявляется первичным ключом,
остальные - альтернативными ключами.
5. Потенциальный ключ, состоящий из одного атрибута, называется простым.
Потенциальный ключ, состоящий из нескольких атрибутов, называется составным.
6. Отношения связываются друг с другом при помощи внешних ключей. Внешний ключ
отношения - это набор атрибутов отношения, содержащий ссылки на потенциальный
ключ другого (или того же самого) отношения.
7. Отношение, содержащее потенциальный ключ, на который ссылается некоторый
внешний ключ, называется родительским отношением. Отношение, содержащее
внешний ключ, называется дочерним отношением.
8. Внешний ключ не обязан обладать свойством уникальности. Поэтому, одному кортежу
родительского отношения может соответствовать несколько кортежей дочернего
отношения. Такой тип связи между отношениями называется "один-ко-многим".
Связи типа "много-ко-многим" реализуются использованием нескольких отношений типа
"один-ко-многим".
9. В любой реляционной базе данных должны выполняться два ограничения:
 Целостность сущностей
 Целостность внешних ключей
Правило целостности сущностей состоит в том, что атрибуты, входящие в состав
некоторого потенциального ключа не могут принимать null-значений.
Правило целостности внешних ключей состоит в том, что внешние ключи не должны
ссылаться на отсутствующие в родительском отношении кортежи, т.е. внешние ключи
должны быть корректны.
10. Ссылочную целостность могут нарушить операции, изменяющие состояние базы
данных. Такими операциями являются операции вставки, обновления и удаления
кортежей. Для поддержания ссылочной целостности обычно используются две основные
стратегии:
 RESTRICT (ОГРАНИЧИТЬ) - не разрешать выполнение операции, приводящей к
нарушению ссылочной целостности.
 CASCADE (КАСКАДИРОВАТЬ) - разрешить выполнение требуемой операции, но
внести каскадные изменения в другие отношения так, чтобы не допустить
нарушения ссылочной целостности.
Список литературы
3. Пушников А.Ю. Введение в системы управления базами данных. Часть 1. Реляционная
модель данных: Учебное пособие/Изд-е Башкирского ун-та. - Уфа, 1999. - 108 с. - ISBN
5-7477-0350-1.
4. Пушников А.Ю. Введение в системы управления базами данных. Часть 2. Нормальные
формы отношений и транзакции: Учебное пособие/Изд-е Башкирского ун-та. - Уфа,
1999.
138
с.
ISBN
5-7477-0351-X.
(http://www.citforum.ru/database/dblearn/dblearn00.shtml)
Лекция 6. Элементы языка SQL. Транзакции и целостность данных
1. Элементы языка SQL ............................................................................................................48
1.1 Операторы DDL (Data Definition Language) - операторы определения объектов базы
данных
48
1.2 Операторы DML (Data Manipulation Language) - операторы манипулирования
данными
48
1.3 Операторы защиты и управления данными ..................................................................49
2. Транзакции и целостность баз данных ................................................................................49
2.1 Атомарность .....................................................................................................................49
2.2 Изоляция ...........................................................................................................................50
2.3 Согласованность ..............................................................................................................50
2.4 Долговечность ..................................................................................................................51
Список литературы ......................................................................................................................51
1. Элементы языка SQL
Фактически стандартным языком доступа к базам данных в настоящее время стал
язык SQL (Structured Query Language).
Язык SQL оперирует терминами, несколько отличающимися от терминов
реляционной теории, например, вместо "отношений" используются "таблицы", вместо
"кортежей" - "строки", вместо "атрибутов" - "колонки" или "столбцы".
Стандарт языка SQL, хотя и основан на реляционной теории, но во многих местах
отходит он нее.
Основу языка SQL составляют операторы, условно разбитые не несколько групп по
выполняемым функциям:
­ Операторы DDL (Data Definition Language) - операторы определения объектов базы
данных.
­ Операторы DML (Data Manipulation Language) - операторы манипулирования
данными.
­ Операторы защиты и управления данными, и др.
1.1 Операторы DDL (Data Definition Language) - операторы определения
объектов базы данных
­
­
­
­
­
­
­
­
­
­
­
­
CREATE SCHEMA - создать схему базы данных
DROP SHEMA - удалить схему базы данных
CREATE TABLE - создать таблицу
ALTER TABLE - изменить таблицу
DROP TABLE - удалить таблицу
CREATE DOMAIN - создать домен
ALTER DOMAIN - изменить домен
DROP DOMAIN - удалить домен
CREATE COLLATION - создать последовательность
DROP COLLATION - удалить последовательность
CREATE VIEW - создать представление
DROP VIEW - удалить представление
1.2 Операторы DML (Data Manipulation Language) - операторы
манипулирования данными
­ SELECT - отобрать строки из таблиц
­ INSERT - добавить строки в таблицу
­ UPDATE - изменить строки в таблице
­ DELETE - удалить строки в таблице
­ COMMIT - зафиксировать внесенные изменения
­ ROLLBACK - откатить внесенные изменения
1.3 Операторы защиты и управления данными
­ CREATE ASSERTION - создать ограничение
­ DROP ASSERTION - удалить ограничение
­ GRANT - предоставить привилегии пользователю или
манипулирование объектами
­ REVOKE - отменить привилегии пользователя или приложения
приложению
на
Кроме того, есть группы операторов установки параметров сеанса, получения
информации о базе данных, операторы статического SQL, операторы динамического SQL.
Наиболее важными для пользователя являются операторы манипулирования
данными (DML).
2. Транзакции и целостность баз данных
Понятие транзакции не входит в реляционную модель данных, т.к. транзакции
рассматриваются не только в реляционных СУБД, но и в СУБД других типов, а также и в
других типах информационных систем.
Транзакция - это неделимая, с точки зрения воздействия на СУБД,
последовательность операций манипулирования данными.
Для пользователя транзакция выполняется по принципу "все или ничего", т.е. либо
транзакция выполняется целиком и переводит базу данных из одного целостного
состояния в другое целостное состояние, либо, если по каким-либо причинам, одно из
действий транзакции невыполнимо, или произошло какое-либо нарушение работы
системы, база данных возвращается в исходное состояние, которое было до начала
транзакции (происходит откат транзакции).
Транзакция - это неделимая, с точки зрения воздействия на СУБД,
последовательность операций манипулирования данными, выполняющаяся по принципу
"все или ничего", и переводящая базу данных из одного целостного состояния в другое
целостное состояние.
Транзакция обладает четырьмя важными свойствами, известными как свойства
АСИД:
1. (А) Атомарность.
2. (С) Согласованность.
3. (И) Изоляция.
4. (Д) Долговечность.
2.1 Атомарность
Транзакции важны как в многопользовательских, так и в однопользовательских
системах. В однопользовательских системах транзакции - это логические единицы
работы, после выполнения которых база данных остается в целостном состоянии.
Транзакции также являются единицами восстановления данных после сбоев восстанавливаясь, система ликвидирует следы транзакций, не успевших успешно
завершиться в результате программного или аппаратного сбоя. Эти два свойства
транзакций определяют атомарность (неделимость) транзакции.
Атомарность. Транзакция выполняется как атомарная операция - либо
выполняется вся транзакция целиком, либо она целиком не выполняется.
2.2 Изоляция
В многопользовательских системах, кроме того, транзакции служат для
обеспечения изолированной работы отдельных пользователей - пользователям,
одновременно работающим с одной базой данных, кажется, что они работают как бы в
однопользовательской системе и не мешают друг другу.
Изоляция. Транзакции разных пользователей не должны мешать друг другу
(например, как если бы они выполнялись строго по очереди).
2.3 Согласованность
База данных находится в согласованном состоянии, если для этого состояния
выполнены все ограничения целостности.
Ограничение целостности - это некоторое утверждение, которое может быть
истинным или ложным в зависимости от состояния базы данных.
Ограничения целостности классифицируются несколькими способами:
1. По способам реализации.
1.1 Декларативную поддержку ограничений целостности - средствами языка
определения данных (DDL).
1.2 Процедурную поддержку ограничений целостности - посредством триггеров
и хранимых процедур.
2. По времени проверки.
2.1 Немедленно проверяемые ограничения.
2.2 Ограничения с отложенной проверкой.
3. По области действия.
3.1 Ограничения домена.
3.2 Ограничения атрибута.
3.3 Ограничения кортежа.
3.4 Ограничения отношения.
3.5 Ограничения базы данных.
Стандарт языка SQL поддерживает только декларативные ограничения
целостности, реализуемые как:
1. Ограничения домена.
2. Ограничения, входящие в определение таблицы.
3. Ограничения, хранящиеся в базе данных в виде независимых утверждений (assertion).
Проверка ограничений допускается как после выполнения каждого оператора,
могущего нарушить ограничение, так и в конце транзакции. Во время выполнения
транзакции можно изменить режим проверки ограничения.
Примерами ограничений целостности могут служить следующие утверждения:
Пример 2. Возраст сотрудника не может быть меньше 18 и больше 65 лет.
Пример 3. Каждый сотрудник имеет уникальный табельный номер.
Пример 4. Сотрудник обязан числиться в одном отделе.
Пример 5. Сумма накладной обязана равняться сумме произведений цен товаров
на количество товаров для всех товаров, входящих в накладную.
Пример 3 представляет ограничение, реализующее целостность сущности. Пример
4 представляет ограничение, реализующее ссылочную целостность. Другие ограничения
являются достаточно произвольными утверждениями (примеры 2 и 5). Любое
ограничение целостности является семантическим понятием, т.е. появляется как
следствие определенных свойств объектов предметной области и/или их взаимосвязей.
Согласованность. Транзакция переводит базу данных из одного согласованного
(целостного) состояния в другое согласованное (целостное) состояние. Внутри
транзакции согласованность базы данных может нарушаться.
2.4 Долговечность
Если транзакция выполнена, то результаты ее работы должны сохраниться в
базе данных, даже если в следующий момент произойдет сбой системы.
Список литературы
5. Пушников А.Ю. Введение в системы управления базами данных. Часть 1. Реляционная
модель данных: Учебное пособие/Изд-е Башкирского ун-та. - Уфа, 1999. - 108 с. - ISBN
5-7477-0350-1.
6. Пушников А.Ю. Введение в системы управления базами данных. Часть 2. Нормальные
формы отношений и транзакции: Учебное пособие/Изд-е Башкирского ун-та. - Уфа,
1999.
138
с.
ISBN
5-7477-0351-X.
(http://www.citforum.ru/database/dblearn/dblearn00.shtml)