Download Реляционная модель данных: основы и принципы and more Lecture notes Introduction to Database Management Systems in PDF only on Docsity!
Реляционная модель данных
Впервые термин "реляционная модель
данных" появился в статье сотрудника фирмы
IBM д-ра Кодда опубликованной 6
июня 1970г. Будучи математиком по
образованию Кодд предложил использовать
для обработки данных аппарат теории
множеств (объединение, пересечение,
разность, декартово произведение). Он
показал, что любое представление данных
может сводится к совокупности двумерных
таблиц, которые он назвал отношениями -
relation (англ.). Реляционной является БД, в
которой все данные доступные пользователю,
организованы в виде набора связанных
двумерных таблиц, а все операции над
данными сводятся к операциям реляционной
алгебры.
Реляционная модель
данных
Таблица в реляционной модели
Поле
ФИО
Запись о физ.
лице
Первичный
ключ
Физ_лиц
а
Связи между таблицами
Связи между таблицами
устанавливаются при помощи
специальных полей – ключей.
Первичный ключ – поле однозначно
идентифицирующее запись в таблице
(значение этого поля уникально в
столбце)
Внешний ключ – поле, в котором
содержится значение первичного
ключа другой таблицы, это поле
необходимо для создания связи между
записями таблиц.
Правильные связи в правильной базе
данных
Заполнение ключевых
полей
Родительская
таблица
Первичный ключ
Внешний
ключ
Внешний
ключ
Дочерние таблицы
Заполняется
СУБД при
добавлении
записи
Заполняется
приложением
путем
копирования
значения поля
первичного ключа
при создании или
изменении
Реализация связей «много – много»
Мужчин
ы
Женщин
ы
Семь
я
Член
семьи
Семья
1
Семья
1
Семья
1
Семья
1
Семья
1
…..
Семья
2
Список семьи
Реализация связей «много – много»
Авторы Книги
Автор Книга
Автор
1
Книга
1
Автор
1
Книга
2
Автор
1
Книга
3
Автор
2
Книга
3
Автор Книга
Библиография
Классический пример:
У каждой книги много
авторов
У каждого автора много
книг
Нужна ли нормализация?
Должны ли первичные ключи
быть осмысленными
атрибутами?
Так ли уж необходимо
значение NULL?
Должна ли реляционная СУБД
(язык SQL) полностью
удовлетворять требованиям
Холивары связанные с
БД
Нормализация базы
данных
Нормализация – это разбиение
таблицы на несколько, обладающих
лучшими свойствами при обновлении,
включении и удалении данных.
Нормальные формы – это
рекомендации по проектированию баз
данных.
Цель нормализации сводится к
получению такого проекта базы данных,
в котором исключена избыточность
информации. Это делается не столько с
целью экономии памяти, сколько для
исключения возможной
противоречивости хранимых данных и
предсказуемости поведения системы во
время эксплуатации.
Теория и практика
Операция Результат
NULL AND (TRUE или FALSE) NULL
NULL OR (TRUE или FALSE) (TRUE или
FALSE)
NOT NULL NULL
Гримасы атомарных
полей
Правила для ключей
Троичная логика
Вывод: Теория и практика – две
большие разницы
SQL и реляционная модель
В области информационной технологии
любой практически используемый
инструмент не может быть полностью
свободен от компромиссов.
Идеологически чистые решения
возможны только в научно-
экспериментальной работе. «Великий и
ужасный» язык SQL – это порождение
ряда компромиссов между теорией,
практикой и маркетинговой
деятельностью. Этот язык является
настолько реляционным, насколько это
понадобилось потребителям
коммерческих СУБД, прямо или косвенно
финансировавшим разработку языка.
12 правил Кодда
0 Реляционная СУБД должна быть способна полностью управлять базой данных,
используя связи между данными.
1 Информационное правило – вся информация в реляционной БД (включая имена
таблиц и столбцов) должна определяться строго как значения таблиц.
2 Гарантированный доступ – любое значение БД должно быть гарантированно
доступным через комбинацию имени таблицы, первичного ключа и имени столбца.
3 Поддержка пустых значений – СУБД должна уметь работать с пустыми
значениями. Пустое значение – это неизвестное, независимое, неприменимое
значение, в отличие от значений по умолчанию и обычных значений.
4 Активный, оперативный реляционный каталог – описание БД и его содержимое
должны быть определены на логическом уровне через таблицы, к которым можно
применять запросы, используя DML (язык манипулирования данными).
5 Исчерпывающее подмножество языка данных – по крайней мере, один из
поддерживаемых языков должен иметь четко определенный синтаксис и быть
самодостаточным. Он должен поддерживать определение данных и
манипулирование ими, правила целостности, авторизацию и транзакции.
6 Правило обновления представлений – все представления, теоретически
обновляемые, могут быть обновлены через систему.
7 Вставка, обновление и удаление – СУБД поддерживает не только запрос на отбор
данных, но и вставку, обновление и удаление.
8 Физическая независимость данных – логика программ-приложений остается
прежней при изменении физических методов доступа к данным и структур
хранения.
9 Логическая независимость данных – логика программ-приложений остается
прежней, в пределах разумного, при изменении структур таблиц.
10 Независимость целостности – язык БД должен быть способен определять
ограничения целостности. Они должны быть доступны из оперативного каталога, и
не должно быть способа их обойти.
11 Независимость распределения – запросы программ-приложений логически не
затрагиваются при первом и последующих распределениях данных.
12 Несмешиваемость (Nonsubversion) – невозможность обойти ограничения
целостности, используя языки низкого уровня.
Одно правило Фомина
СУБД является
реляционной если в ней
реализована полная
поддержка языка SQL
1
