Базы данных. Курс лекций. Учебное пособие
- -
- 100%
- +
Рис. 9. Преобразование связи «многие-ко-многим»
При связывании таблиц необходимо обеспечивать целостность данных, которая может быть нарушена при изменении полей связи.
Рассмотрим наиболее часто встречающуюся связь «один-ко-многим». Пример приведен на рис. 10.
Рис. 10. Пример связывания таблиц
Эти две таблицы связаны по общему полю «Товар». Таблица «Товары» является главной, таблица «Отпуск товаров» – подчиненной. Потеря связей возможна в двух случаях:
1. Изменяется значение в поле связей главной таблицы без изменения значений полей связи в соответствующих записях дочерней таблицы. Например, если вместо товара «Сахар» в таблице «Товары» написать «Песок», то все записи в дочерней таблице для «Сахар» потеряют связь и не будут иметь единицы измерения и цены;
2. Изменяется значение поля связи одной из записей дочерней таблицы без изменения значения поля связи в соответствующих записях главной таблицы. Например, если вместо товара «Сахар» в одной из записей таблицы «Отпуск товаров» написать «Песок», то будут недостоверными записи об отпуске товара «Сахар». Запись в дочерней таблице для «Песок» не будет иметь связи и, следовательно, единицы измерения и цены.
Таким образом, в обоих случаях возникает нарушение целостности БД.
Действия, нарушающие ссылочную целостность БД, должны блокироваться.
Для сохранения ссылочной целостности может использоваться также механизм каскадных изменений:
1. Синхронные изменения поля связи в дочерней таблице при внесении изменений в поле связи главной таблицы;
2. Синхронные удаления поля связи в дочерней таблице при удалении поля связи главной таблицы.
Разрешение или запрещение каскадных изменений реализуется при описании связей между таблицами БД.
Обычно в СУБД для реализации ссылочной целостности в дочерней таблице создают внешний ключ, ссылающийся на родительскую таблицу, и указывают вид каскадных воздействий.
Внешний ключ создается в дочерней таблице. В него входят поля связи дочерней таблицы. Для связей типа «один-ко-многим» внешний ключ должен совпадать по составу полей с первичным ключом главной таблицы или с частью первичного ключа (в этом случае нормализация таблиц БД выполнена не полностью).
При определении первичного и внешнего ключей СУБД автоматически строит индексы. Индекс, соответствующий внешнему ключу, строится для обеспечения связей родительской и дочерней таблиц [2].
Индексы обеспечивают механизм быстрого доступа к данным в таблицах. Индексы хранят значения индексных полей (по которым построен индекс) и указатель на запись в таблице.
Использование индексов позволяет использовать не просто последовательный, а индексно-последовательный доступ.
При последовательном доступе просматриваются все записи таблицы – от первой до последней, что неэффективно.
При индексно-последовательном доступе указатель в индексе устанавливается на первую строку, соответствующую условиям запроса (или его части), и считывается запись из таблицы по хранящемуся на нее в индексе указателю. Далее последовательно считываются остальные записи, удовлетворяющие условиям запроса.
Таким образом, во втором случае поиск ведется по индексу, а не по самой таблице. Таблица может быть неупорядоченна, а небольшой по объему индексный файл может быть легко отсортирован.
Например, рассмотрим табл. 1.
Таблица 1
Отпуск товара
Номер
Дата
Товар
Количество
1
06.01.14
Спички
2
2
02.01.14
Мыло
100
3
03.01.14
Мука
5000
4
08.01.14
Спички
10
Структура индексов по каждому из четырех полей показана в табл. 2.
Таблица 2
Индексированные поля таблицы
По дате прихода
По наименованию
По количеству
Дата
Номер записи
Товар
Номер записи
Количество
Номер записи
02.01.14
2
Мука
3
5000
3
03.01.14
3
Мыло
2
100
2
06.01.14
1
Спички
1
10
4
08.01.14
4
Спички
4
2
1
Если несколько товаров имеет одно и то же наименование, то достаточно найти в индексе, построенном по столбцу «Наименование», первую запись, а затем повторить чтение подряд для всех товаров с этим наименованием. То же самое касается даты и т. д.
Индексы наиболее выгодны для статичных таблиц, по которым часто выполняются запросы.
Лекция 5
Нормализация таблиц БД
При создании БД необходимо выполнить анализ предметной области, для которой разрабатывается БД. Процесс разработки БД является циклическим, т. е. на разных этапах происходят возвраты на более ранние этапы с целью коррекции. Субъективные взгляды разработчика всегда могут найти отражение в БД, но есть ряд объективных требований, соблюдение которых всегда может принести пользу. К таким требованиям относится нормализация БД. Процесс нормализации позволяет устранить избыточность данных и ускорить доступ к ним.
В основе нормализации лежит одна основная идея: поля таблицы должны зависеть только от ключа таблицы и ни от чего другого. Если это не так, то следует разбить таблицу на отдельные таблицы [1].
Общие требования нормализации формулируются в виде пяти нормальных форм (НФ), к которым последовательно приводятся таблицы БД. На практике наиболее часто применяются только первые три НФ [10].
Рассмотрим первую нормальную форму (1НФ).
Таблица в 1НФ должна удовлетворять следующим требованиям:
1. В таблице не должно быть повторяющихся записей;
2. Каждое поле таблицы должно быть неделимым (атомарным), т. е. на пересечении строки и столбца должен быть атомарный объект;
3. В таблице должны отсутствовать повторяющиеся группы полей.
Рассмотрим пример нормализации таблицы «Продажи», в которой содержится 21 поле (табл. 3).
Таблица 3
Продажи
Номер
Поле
Тип поля
1
Фамилия
Текст
2
Имя
Текст
3
Отчество
Текст
4
Телефон
Текст
5
Факс
Текст
6
Индекс
Текст
7
Страна
Текст
8
Город
Текст
9
Адрес
Текст
10
Название предприятия
Текст
11
Руководитель предприятия
Текст
12
Web-сайт предприятия
Текст
13
E-mail предприятия
Текст
14
Код товара
Числовой
15
Дата заказа
Дата/время
16
Заказано
Числовой
17
Дата продажи
Дата/время
18
Продано
Числовой
19
Цена
Денежный
20
Категория товара
Числовой
21
Наименование товара
Текстовый
В табл. 3 каждое поле неделимое, и никакое из полей не является уникальным.
Таблица с такой структурой может иметь повторяющиеся группы полей, в которых будут записаны данные об одном и том же покупателе (поля с 1-го по 13-е). Чтобы привести таблицу к 1НФ, она разбивается на две таблицы: «Клиенты» и «Заказы», находящиеся в отношении «один-ко-многим».
Поскольку ни одно из полей исходной таблицы не было уникальным, здесь в качестве первичного ключа таблицы «Клиенты» лучше ввести новое поле – «Код клиента». Это поле будет внешним ключом в таблице «Заказы» (рис. 11).
Рис. 11. Разбиение со связью «один-ко-многим»
В таблице «Заказы» ни одно из полей не является уникальным, поэтому в качестве первичного ключа можно добавить поле «Код заказа» или использовать комбинацию трех полей – «Код клиента», «Код заказа» и «Дата заказа» – в качестве составного ключа (если один клиент делает один заказ в день). Рассмотрим второй вариант – таблицу с составным первичным ключом. Такая таблица должна удовлетворять требованиям 2-й нормальной формы (2НФ).
Таблица находится во 2НФ, если удовлетворены два условия:
1. Таблица удовлетворяет условиям 1НФ;
2. Любое неключевое поле однозначно идентифицируется полным набором ключевых полей.
Очевидно, что в таблице «Заказы» второе условие не выполняется, поскольку поля «Категория» и «Наименование товара» зависят только от поля «Код товара». Чтобы привести таблицу к 2НФ, нужно выделить эти поля в отдельную таблицу с наименованием «Товар» (рис. 12).
Рис. 12. Разбиение со связью «один-к-одному»
Рассмотрим далее таблицу «Клиенты». Здесь нет составного ключа, поэтому требования 2НФ выполнены автоматически и требуется рассматривать третью нормальную форму (3НФ).
Таблица находится в 3НФ, если она удовлетворяет условиям 2НФ и ни одно из неключевых полей таблицы не идентифицируется с помощью другого неключевого поля.
Иначе говоря, все неключевые поля должны быть независимы. Если какие-то поля зависят не от ключа, а от другого неключевого поля, то такие поля должны быть выделены в отдельную таблицу.
В таблице «Клиенты» неключевые поля «Руководитель фирмы», «Web-сайт фирмы» и «E-mail фирмы» определяются неключевым полем «Название фирмы», поэтому необходимо создать новую таблицу с названием «Фирма» (рис. 13).
Таким образом, в рассмотренном примере из одной исходной таблицы в соответствии с требованиями нормализации было получено четыре таблицы.
В целом нормализация не только предоставляет преимущества, но и несет некоторые недостатки.
Рис. 13. Устранение зависимости неключевых полей
Главное достоинство состоит в том, что после нормализации в таблицах нет избыточных данных, поэтому экономится память ЭВМ (хотя появляются поля связи, присутствующие одновременно у главной и подчиненной таблиц).
В качестве недостатков могут быть названы следующие:
1. Чем шире предметная область, тем больше получается набор таблиц после нормализации. Для крупного предприятия БД может содержать сотни взаимосвязанных таблиц, что превышает возможности человеческого восприятия. Поэтому функционирование БД может стать труднообъяснимым;
2. При считывании связанных данных необходимо объединять записи в связанных таблицах, что приводит к необходимости выполнения поисковых операций. В сложных БД это может вызывать временные издержки.
Таким образом, нормализация является желательной, но в сложных БД могут появляться другие критерии, мешающие полной нормализации таблиц БД [9].
Вопросы для самопроверки
1. Каковы два основных направления использования вычислительной техники?
2. Что такое информационная система?
3. Когда появились первые информационные системы?
Конец ознакомительного фрагмента.
Текст предоставлен ООО «ЛитРес».
Прочитайте эту книгу целиком, купив полную легальную версию на ЛитРес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.