Какими свойствами должны обладать реляционные базы данных

Базы данных всегда являлись краеугольным камнем любого цифрового бизнеса. Поэтому программная индустрия всегда уделяла так много внимания системам управления базами данных.

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

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

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

Используя внешние ключи (foreign keys), можно установить логическую связь между строками и ячейками разных таблиц.

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

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

Наша база данных будет состоять из двух таблиц: “Student” (студенты) и “Class” (предметы), и содержать в себе информацию, соответственно, о студентах и изучаемых ими предметах.

Каждый студент будет обозначен уникальным буквенно-цифровым идентификатором. Остальные данные, относящиеся к студенту – имя и фамилия, операционная система, предмет и преподаватель – могут повторяться. Один преподаватель может учить нескольким предметам.

С учётом этой информации нормализуем данные следующим образом:

1. Таблица студентов будет иметь следующие поля:

• идентификатор студента (Student ID);
• имя студента (Student Name);
• операционная система (Operating System);

2. Таблица предметов будет иметь следующие поля:

• идентификатор предмета (Class ID);
• название предмета (Class Name);
• преподаватель (Instructor).

Теперь заполним обе таблицы данными:

Теперь, используя имеющиеся данные, определим отношения и объекты этих отношений.

Объектами, очевидно, будут являться студенты и предметы. Отношения между ними заключаются в том, что каждый студент изучает один или несколько предметов.

Теперь, когда отношения между объектами ясны, определим атрибуты, которые мы будем использовать для сопоставления объектов друг другу.

Такими атрибутами должны выступать ячейки с уникальным содержимым. В наших таблицах как раз имеется по одному столбцу с уникальными данными.

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

Первичный ключ идентифицирует каждую строку в таблице.

Для установления отношения мы должны сопоставить каждому первичному ключу внешний ключ.

Внешний ключ должен представлять собой первичный ключ другой таблицы. В нашем случае внешний ключ может использоваться для составления особой таблицы – таблицы перекрёстных ссылок. Давайте назовём эту таблицу таблицей зачислений (enrollment).

Каждая строка этой таблицы зачислений будет связывать два внешних ключа между собой:

• идентификатор студента (Student ID) – внешний ключ, ссылающийся на идентификатор студента в таблице студентов;
• идентификатор предмета (Class ID) – внешний ключ, ссылающийся на идентификатор предмета в таблице предметов.

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

Каждая строка получившейся таблицы однозначно определяется собственным первичным ключом – идентификатором зачисления (Enrollment ID).

Кроме первичного ключа, таблица содержит ещё два поля:

• внешний ключ Student ID ссылается на первичный ключ Student ID в таблице студентов;
• внешний ключ Class ID ссылается на первичный ключ Class ID в таблице предметов.

В нашей сегодняшней статье мы изучили принципы организации реляционных баз данных. Слово «реляционные» можно определить как «характеризуемые отношениями», от латинского слова “relatio” – «отношение».

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

Разумеется, для этого можно использовать специальные программы, которые известны, как «Системы управления реляционными базами данных» (Relational database management systems, RDBMS). Но это – материал для другой статьи.

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

Данная публикация представляет собой перевод статьи «The Zen of Relational Database: Learn the Basics Here» , подготовленной дружной командой проекта Интернет-технологии.ру

Так как таблицы в реляционной СУБД являются отношениями реляционной мо­дели данных, то и свойства этих таблиц являются свойствами отношений, кото­рые мы уже рассмотрели выше. Кратко сформулируем эти свойства еще раз:

– каждая таблица состоит из однотипных строк и имеет уникальное имя;

– строки имеют фиксированное число полей (столбцов) и значений (множествен­ные поля и повторяющиеся группы недопустимы). Иначе говоря, в каждой по­зиции таблицы на пересечении строки и столбца всегда имеется в точности одно значение или NULL;

– строки таблицы обязательно отличаются друг от друга хотя бы единственным значением, что позволяет однозначно идентифицировать любую строку;

– столбцам таблицы присваиваются уникальные имена, и в каждом из них разме­щаются однородные значения данных (даты, фамилии, целые числа или денеж­ные суммы);

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

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

Индексы

Выше мы рассмотрели понятие ключей таблиц базы данных. В большинстве ре­ляционных СУБД ключи реализуются с помощью объектов, называемых индек­сами. Индекс представляет собой указатель на данные, размещенные в реляционной таб­лице. Можно провести аналогию индекса таблицы базы данных с указателем, обыч­но помещаемым в конце книги. Чтобы найти в книге страницы, относящиеся к некоторой теме, проще всего обратиться к указателю, в котором устанавливается соответствие между перечисленными в алфавитном порядке темами и номерами страниц, и сразу определить страницы, которые следует просмотреть. Чтобы без указателя найти все страницы, относящиеся к нужной теме, пришлось бы просмат­ривать всю книгу. Индекс базы данных предназначен для аналогичных целей – чтобы ускорить поиск информации в таблице базы данных. Индекс предоставляет информацию о точном физическом расположении данных в таблице.

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

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

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

Рассмотрим пример индекса. На рис. 4.1 показан фрагмент таблицы СТУДЕНТЫ и индекса, построенного по полю «Имя» данной таблицы. При выполнении поиска по имени студента, просматривая индекс, можно сразу определить порядковый Номер записи, содержащей необходимую информацию, и затем быстро найти в таблице сами данные. Если бы у таблицы отсутствовал индекс по полю «Имя», то выполнение поиска по имени студента потребовало бы просмотра всей таблицы.

Таким образом, использование индексов снижает время выборки данных.

Рисунок 4.1 – Поиск информации в таблице с помощью индекса

Различают несколько типов индексов. Наиболее часто выделяют три типа:

– простые;

– составные;

– уникальные.

Ускорение поиска информации при использовании индекса может показаться неоче­видным – ведь количество записей в индексе совпадает с количеством записей в таблице. Однако следует учитывать два обстоятельства:

– обращение к индексу выполняется быстрее, чем к таблице;

– в индексе записи хранятся в упорядоченном виде (в рассматриваемом примере – в алфавитном порядке) и поэтому при поиске информации в индексе нет необхо­димости просматривать все данные до конца индекса.

Простые индексыпредставляют собой простейший и вместе с тем наиболее рас­пространенный тип индекса. Простой индекс строится на основе только одного столбца реляционной таблицы (индекс, приведенный на рис. 4.1, является про­стым).

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

Последовательность столбцов в составном индексе указывается при его создании и никаким образом не связана с последовательностью столбцов в таблице.

Можно назвать два условия оптимальности следования столбцов в составном ин­дексе:

– первым следует помещать столбец, содержащий наиболее ограни­чивающее значение (то есть, содержащий меньшее количество повторов);

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

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

Следует серьезно относиться к планированию индексов. Неправильное применение индексов может привести к снижению производительности системы. Мы уже говори­ли о том, что физическое местоположение записей может изменяться в процессе редактирования данных пользователями, а также в результате манипуляций с фай­лами базы данных, проводимых самой СУБД (таких как сжатие данных, сборка «му­сора» и др.). Обычно при этом происходят соответствующие изменения и в индексе, а это увеличивает время, требующееся СУБД для проведения таких операций. Поэто­му обычно не следует индексировать:

– столбцы, данные в которых подвержены частому изменению;

– столбцы, содержащие большое количество пустых значений;

– столбцы, содержащие небольшое количество уникальных значений;

– небольшие таблицы;

– поля большого размера.

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

Нормализация данных

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

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

Цели нормализации

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

может привести к нарушению целостно­сти данных (противоречивости информации) в базе данных. Обычно различают сле­дующие проблемы, возникаю­щие при использовании ненормализованных таблиц:

– избыточность данных;

– аномалии обновления;

– аномалии удаления;

– аномалии ввода.

Чтобы проиллюстрировать проблемы, возникающие при работе с ненормализо­ванными базами данных, рассмотрим в качестве примера таблицу СОТРУДНИКИ, содержащую информа­цию о сотрудниках некой организации. Структура этой таблицы приведена на рис. 4.2.

Избыточность данных

Избыточность данных проявляется в том, что в нескольких записях таблицы базы данных повторяется одна и та же информация. Например, один человек может работать на двух (или даже более) должностях. Но в таблице, приведенной на рис. 4.2, каждой должности соответствует запись, и в этой записи содержится ин­формация о личных данных сотрудника, эту должность занимающего. Таким об­разом, если сотрудник работает на нескольких должностях, то его личные данные будут дублироваться несколько раз, что приведет к неоправданному увеличению занимаемого объема внешней памяти.

Аномалии обновления

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

Аномалии удаления

Аномалии удаления возникают при удалении записей из ненормализованной таб­лицы. Пусть, например, в организации проводится сокращение штатов и некото­рые должности аннулируются. При этом следует удалить соответствующие запи­си в рассматриваемой таблице. Однако удаление приведет к потере информации о сотруднике, занимавшем эту должность. Такая потеря информации и называется аномалией удаления. (Для нашего случая можно привести и другой пример – уда­ление записи при увольнении сотрудника приведет к потере информации о долж­ности, которую он занимал.)

Аномалии ввода

Аномалии ввода возникают при добавлении в таблицу новых записей и обычно возникают, когда для некоторых полей таблицы заданы ограничения NOT NULL. В таблице, рассматриваемой в качестве примера, имеется поле «Рейтинг», в кото­ром содержится информация об уровне квалификации сотрудника, устанавливае­мом по результатам его работы. При приеме на работу нового сотрудника устано­вить уровень его квалификации невозможно, так как он еще не выполнял никаких работ в организации. Если для этого поля задать ограничение NOT NULL, то в таблицу нельзя будет ввести информацию о новом сотруднике. Это и называется аномали­ей ввода.

Вывод

Очевидно, что аномалии обновления, удаления и ввода крайне нежелательны. Что­бы свести к минимуму возможность появления такого рода аномалий, и использу­ется нормализация.

Нормальные формы

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

В теории реляционных баз данных обычно выделяется следующая последователь­ность нормальных форм:

– первая нормальная форма (1NF);

– вторая нормальная форма (2NF);

– третья нормальная форма (3NF);

– нормальная форма Бойса–Кодда (BCNF);

– четвертая нормальная форма (4NF);

– пятая нормальная форма, или нормальная форма проекции-соединения (5NF или PJ/NF). Основные свойства нормальных форм:

– каждая следующая нормальная форма в некотором смысле лучше предыду­щей;

– при переходе к следующей нормальной форме свойства предыдущих нормаль­ных свойств сохраняются.

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

Наиболее важные на практике нормальные формы отношений основываются на фундаментальном в теории реляционных баз данных понятии функциональной зависимости. Функционально зависимым считается такой атрибут, значение ко­торого однозначно определяется значением другого атрибута. Функционально за­висимые атрибуты обозначаются следующим образом: X –> Y. Эта запись означа­ет, что если два кортежа в таблице имеют одно и то же значение атрибута X, то они имеют одно и то же значение атрибута Y. Атрибут, указываемый в левой части, называется детерминантом.

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

Date: 2016-05-25; view: 1738; Нарушение авторских прав