Урок №31. Табличные (реляционные) базы данных.
В середине XX века программное обеспечение для работы с базами данных было жёстко «привязано» к внутреннему представлению данных во внешней памяти компьютера, т. е. к структуре файлов с данными. Это означало, что при изменении формата файлов нужно было переделывать все работающие с ними программы. Поэтому возникли следующие задачи:
- разработать строгое математическое описание баз данных, независимое от способа хранения данных;
- разработать методы управления этими данными (поиска, изменения, добавления и т. п.), основанные на использовании математических операций.
Эти задачи удалось решить в 1970 г. англичанину Эдгару Код-ду, который работал в фирме IBM. Он предложил новую модель данных, основанную на следующих идеях:
- все данные представляют собой свойства некоторых объектов;
- объекты делятся на классы (в теории баз данных они называются сущностями). Например, при описании данных о музыкальных группах можно использовать классы Группа, Альбом, Песня и т. п.;
- данные о некотором объекте — это набор свойств (атрибутов), в котором каждое свойство задаётся в виде пары «название — значение»; например, сведения о музыкальной группе «Кино» можно записать так: (Название: «Кино», Лидер: «В. Цой», Год создания: 1981).
Такой набор данных, описывающий свойства одного объекта, называется кортежем.
- Порядок перечисления свойств в кортеже не имеет значения.
- Все объекты одного класса имеют одинаковый набор свойств.
- Множество кортежей, описывающих объекты одного класса, называется отношением (англ, relation); например, отношение Группы можно записать в виде множества кортежей:(Название: «Машина времени», Лидер: «А. Макаревич», Год создания: 1969) (Название: «Кино», Лидер: «В. Цой», Год создания: 1981) (Название: «Аквариум», Лидер: «Б. Гребенщиков», Год создания: 1972)
- В отношении нет двух одинаковых кортежей.
- Порядок кортежей в отношении не определён.
«Кортеж» и «отношение» — это математические понятия, которые описывают связанные данные. Поэтому с ними можно работать, используя известные операции теории множеств и математической логики. Э. Кодд предложил набор операций с данными, представленными в виде отношений, который служит основой для работы большинства современных СУБД. Модель данных, введённая Коддом, получила название реляционной модели данных (от англ, relation — отношение).
Реляционная база данных — это база данных, которая основана на реляционной модели, т. е. представляет собой набор отношений.
Математическая теория Кодда никак не связана с тем, как именно хранятся данные. Однако несложно понять, что отношение удобно представлять в виде прямоугольной таблицы (рис. 3.17).
Эта таблица описывает отношение Группы. Здесь кортежи представлены в виде записей (строк), а атрибуты — это поля (столбцы) в таблице.
Идеи реляционной теории Кодда легко перевести на «табличный язык»:
- каждая таблица описывает один класс объектов;
- порядок расположения полей в таблице не имеет значения;
- все значения одного поля относятся к одному и тому же типу данных;
- в таблице нет двух одинаковых записей;
- порядок записей в таблице не определён.
Поэтому на практике часто используют ещё одно, более простое определение:
Реляционная база данных — это база данных, которую можно представить в виде набора таблиц.
Однако не любой набор таблиц можно считать реляционной базой данных. Как мы уже говорили, БД и СУБД неразрывно связаны, и для того чтобы отнести систему базы данных (БД + СУБД) к определённому типу, необходимо выяснить, какие методы управления данными используются в соответствующей СУБД.
Согласно реляционной теории, порядок перечисления свойств в кортеже (порядок столбцов в таблице) не определён, так же как и порядок кортежей в отношении (порядок строк в таблице). Поэтому методы работы с данными в реляционной БД не должны предполагать, что столбцы и строки таблиц расположены в каком-то порядке.
Для управления данными в большинстве современных информационных систем используется язык SQL, в который включены команды для:
- создания новых таблиц;
- добавления новых записей;
- изменения записей;
- удаления записей;
- выборки записей из одной или нескольких таблиц в соответствии с заданным условием и некоторые другие.
Команды языка SQL позволяют управлять данными, не «привязываясь» к формату их хранения, т. е. к порядку расположения столбцов и строк в таблицах. Для выполнения операций (выборки, вставки, удаления, изменения) используются только названия столбцов и таблиц. С помощью команд SQL можно выполнить все основные операции, введённые Коддом, поэтому СУБД (и соответствующие системы баз данных), которые используют язык SQL, традиционно называют реляционными.
Представим себе, что все данные о рейсах авиакомпании «ZX-Аэро» собраны в одной таблице:
Мы сразу видим, что в таблице есть избыточность (дублирование): многие данные (названия городов и типов самолётов) хранятся несколько раз. При этом для хранения данных-дубликатов расходуется дополнительное место на диске, что может привести к его преждевременному заполнению и выходу из строя всей информационной системы.
Есть и другая проблема: при вводе всех данных вручную оператор может сделать опечатку и, например, вместо «Санкт-Петербург» ввести «СанктПетербург». В этом случае нарушается целостность базы данных, потому что в ней хранится название несуществующего города.
Чтобы избежать этих проблем, при проектировании базы данных обычно выполняют её нормализацию.
Нормализация — это изменение структуры базы данных, которое устраняет избыточность и предотвращает возможные нарушения целостности.
В теории реляционных баз данных существует несколько уровней нормализации (так называемых нормальных форм). Мы покажем некоторые принципы нормализации на примерах.
1. Любое поле должно быть неделимым. Это значит, что таблицу вида, показанного на рис. 3.18, необходимо переделывать.
Здесь поле Сотрудник нужно разделить на три: Фамилия, Имя и Отчество. Поле Телефоны содержит два телефона: домашний и мобильный. Поэтому нужно изменить таблицу, по крайней мере, так (рис. 3.19).
2. Любое неключевое поле должно зависеть от ключа таблицы. Например, в таблице на рис. 3.20 ключ — это регистрационный номер автомобиля.
Понятно, что телефон зависит не от регистрационного номера, а от владельца. Поэтому его нужно выносить в другую таблицу (рис. 3.21).
Заметим, что здесь мы присвоили каждому владельцу уникальный числовой код и ввели в таблицу Владельцы суррогатный (искусственный) ключ.
3. Не должно быть одинаковых по смыслу полей. Например, фирма торгует бананами, апельсинами и яблоками и хранит данные о ежедневных продажах этих товаров (в килограммах) в такой таблице (рис. 3.22).
Недостаток этой таблицы в том, что поля Бананы, Апельсины и Яблоки — одинаковые по смыслу, это товары. Если фирма начнёт работать с новым видом товара, придется добавлять новый столбец, т. е. менять структуру таблицы (это делает уже не пользователь, а администратор базы данных). Поэтому нужно выделить все товары в отдельную таблицу (рис. 3.23).
С одной стороны, число строк в таблице увеличилось, но с другой — организация данных улучшилась. Теперь для добавления в базу нового товара достаточно добавить одну запись в таблицу Товары, структуру таблиц переделывать не нужно.
4. Не нужно хранить данные, которые могут быть вычислены. Предположим, что бухгалтер фирмы вводит в таблицу доходы и расходы фирмы за каждый месяц (в тысячах рублей), а также прибыль — разницу между доходом и расходом (рис. 3.24).
В самом деле, поле Прибыль нужно удалить из таблицы, поскольку это значение можно рассчитать как разность двух других. Во-первых, оно занимает лишнее место на диске, во-вторых, появляется возможность нарушения целостности — при ошибке ввода может оказаться, что прибыль не равна разности доходов и расходов, и данные станут противоречивыми. Позже вы узнаете, что все вычисления в базах данных можно делать с помощью запросов, которые СУБД выполняет по требованию пользователя, т. е. тогда, когда результаты этих вычислений действительно нужны.
Нужно понимать, что нормализация имеет свои недостатки. Например, выборка данных из нескольких таблиц может выполняться очень долго, и для ускорения работы иногда приходится применять денормализацию — специально вводить избыточность, нарушая требования нормализации. Например, в предельном случае можно все данные свести в одну таблицу. Однако при этом необходимо принимать меры для поддержки целостности базы данных.