ОСНОВЫ ПОСТРОЕНИЯ БАЗ ДАННЫХ Что такое база данных

Под базой данных (БД) понимается хранилище данных, принадлежащих некоторой об­ласти. Хранение этих данных должно быть некоторым образом организовано (структури­ровано), при этом хранящиеся данные должны быть непротиворечивы, минимально из­быточны и целостны. Что под этим понимается, будет рассмотрено ниже. В самом общем смысле (техническом) база данных - это набор записей и файлов, органи­зованных специальным образом. Например, можно хранить фамилии, имена, адреса и те­лефоны своих сотрудников или клиентов.

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

Модели баз данных

В своем развитии структуры (формы организации хранения данных), прошли несколько этапов:

• иерархическая структура;

• сетевая структура;

• реляционная структура.

Основной идеей иерархических структур является наличие указателей, определяющих взаимоотношение уровней иерархии. Рассмотрим пример.

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

Пусть программистом разработана программа «Склад». Эта программа ведет учет това­ров и клиентов. То есть мы имеем некоторый программный продукт, организованный по уровням иерархической структуры: Склад — Клиенты — Товары.

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

К недостаткам следует отнести чрезмерную жесткость структуры: элементы нижнего уровня иерархии жестко привязаны к одному конкретному элементу верхнего уровня. Клиенты привязаны только к одному складу, количество клиентов ограничено, клиенты выбирают только ограниченное число конкретных товаров. Для изменения или расшире­ния иерархической БД приходилось каждый раз переписывать код программы. Для придания БД большей гибкости были разработаны сетевые структуры, основным преимуществом которых явилась множественность, т.е. возможность принадлежности элементов нижнего уровня различным элементам верхнего уровня иерархии (Рис. 2). Конечно, у сетевых БД были недостатки. Как и иерархические БД, сетевые базы данных были очень жесткими. Структуру приходилось задавать наперёд. Изменение же структу­ры базы данных обычно означало перестройку всей базы данных.

Как иерархическая, так и сетевая базы данных были инструментами программистов. Что­бы получить ответ на вопрос типа «Какой товар наиболее часто заказывается», програм­мисту приходилось писать программу для навигации по базе данных. Реализация пользо­вательских запросов часто затягивалась на недели и месяцы, и к моменту появления про­граммы информация, которую она предоставляла, часто оказывалась бесполезной.

Реляционная модель данных

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

Первые реляционные программные продукты стали появляться в конце 1970-х - начале 1980-х годов. Сегодня таких продуктов более 200. Среди них такие как:

1. DB2 корпорации ШМ;

2. ORACLE корпорации Oracle;

3. INGRES компании Ingres Division of The ASK Group Inc.;

4. SYBASE компании Sybase Inc.;

5. Ш Database компании Borland и многие другие.

Реляционная модель была попыткой упростить структуру базы данных. В ней отсутство­вали явные указатели на элементы уровней, а все данные были представлены в виде про­стых таблиц, разбитых на строки и столбцы.

Определение реляционной бд:

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

Приведенное определение не оставляет места встроенным указателям, имеющимся в ие­рархических и сетевых БД. Несмотря на это. реляционная БД также способна реализовать иерархические отношения, (термин «реляционная!» происходит от английского слова rela­tion - отношение), однако принцип этих отношений совершенно иной. Эти отношения представлены исключительно значениями данных, содержащихся в таблицах.

Таблицы и сущности

Таблицы

В реляционной базе данных информация организована в виде таблиц. Таблицы в реляционной базе данных разделены на строки {записи, кортежи) и столб­цы {поля, атрибуты), на пересечении которых содержатся значения данных. У каждой таблицы имеется уникальное имя, описывающее ее содержимое. Строки ни имени, ни номера не имеют. Столбцы таблицы обязаны иметь имена (Рис. 3).

Факультет
ЭФ	Колесов
ММ	Лупанов
вмк	Моисеев
фф
фф

Фамилия	Имя	Год
Шаров	Михаил	1985
Корнетов	Алексей	1986
Алисов	Николай	1985
Никитин	Михаил	1984
Федоров	Юрий	1986

Рис. 3 Рис. 4

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

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

Все значения, содержащиеся в одном и том же столбце, являются данными одного типа (текст, число, дата,...)

На пересечении каждой строки с каждым столбцом таблицы содержится в точно­сти одно значение данных.

Пересечение строки и столбца образует элементарное значение данных, которое является наименьшей единицей данных в РБД. Такие значения рассматриваются как атомарные, т.е. они неразложимы.

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

В стандарте ANSI/ISO не указывается максимально допустимое число столбцов в таблице, однако почти во всех коммерческих БД этот предел существует и обычно со­ставляет примерно 255 столбцов.

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

В таблице может содержаться любое количество строк. Допускается существование таблицы с нулевым количеством строк. Такая таблица называется пустой. Пустая табли­ца сохраняет структуру, определенную ее столбцами, просто в ней не содержатся данные. Стандарт ANSI/ISO не накладывает ограничений на количество строк в таблице, и во многих БД размер таблиц ограничен лишь свободным дисковым пространством компью­тера. В других БД имеется максимальный предел, однако он весьма высок - около двух миллиардов строк, а иногда и больше.

51

С ущности

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

Таблица является хранилищем информационной сущности. Правила хранения информа­ции рассматриваются ниже в разделе «Целостность реляционных данных».

Сущности подразделяют на три основных класса:

1. стержни - это независимые сущности. Например, таблица «Факультеты».

2. ассоциации - это связи между двумя и более сущностями. Например, таблицы «Факультеты» и «Студенты».

3. характеристики - это сущности, цель которых описание или уточнение других сущностей.

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

Правила отношений сущностей рассматриваются в разделе «Реляционные отношения между таблицами (сущностями)».

Целостность реляционных данных

Ключи

Понятие первичного ключа

По математическому определению, множество не может содержать одинаковых эле­ментов. Так как таблица является множеством (строк), то она не может содержать одина­ковые строки. Поэтому каждая таблица реляционной БД должна содержать один или не­сколько столбцов, все значения или комбинации значений которых различны.

Определение первичного ключа

С толбец, или совокупность столбцов, называется первичным ключом (primary key, обозначается pk), если все его значения, или комбинации значений, различны. .

Например:

В таблице представленной на Рис. 5 первичным ключом является поле Код. В этом поле ни одно из значений не повторяется, т.е. содержит множество различных значений. В то же время поле Факультет не может быть первичным ключом, так как содержит по­вторяющиеся значения (ФФ, ФФ).

Код	Факультет	Декан
1	ЭФ	Колесов
2	BMK	Моисеев
3	ФФ	Смирнов
4	ФФ	Михайлов

Рис.5

Требования, предъявляемые к первичному ключу

Первичный ключ должен отвечать двум требованиям: уникальность и минималь­ность.

Пусть имеется таблица со столбцами А\, А2 .... А_п.

Уникальность предполагает, что в произвольный момент времени никакие две различные строки таблицы не имеют одни и те же значения для А/, А/,..., А&.

52

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

Пример: На Рис. 6 первичными ключами для Таблицы 1 предполагаются поля Код и Но­мер. Тогда для левой таблицы Правила уникальности и минимальности нарушены, а для правой соблюдены.

Таблица 1 Таблица 1

Понятие внешнего ключа

Для объяснения понятия - внешний ключ, наша БД должна состоять как минимум из двух таблиц Рис. 7.

Определение внешнего ключа

Внешний ключ (foreign key, обозначается fk) - это столбец таблицы Т2, любое значение которого должно обязательно совпадать с одним из значений первичного ключа некоторой другой таблицы Т1.

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

Т1

Рисунок 7

Все значения поля «Код Факультета» Т2 соответствуют значениям поля «Код Факульте­та» Т1.

Первичный и внешний ключи необходимы для установления отношений между таблица­ми их содержащими. Об этом смотри далее.

Реляционные отношения между таблицами

Между двумя и более таблицами могут существовать отношения подчиненности.

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

Соответствие записей определяется первичным и внешним ключом

Существует три разновидности связи между таблицами БД:

• один к одному;

• один ко многим;

• многие ко многим.

Отношение «один к одному»

Отношение «один к одному» это когда одной записи таблицы Т1 (родительской) соответ­ствует одна запись таблицы Т2 (дочерней) (Рис. 8).

Рис. 8

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

Для жесткой связи одной записи в родительской таблице должна существовать одна за­пись в дочерней таблице. Для нежесткой связи, запись в дочерней таблице может отсут­ствовать. Данный вид отношений («один к одному») применяется редко.

Отношение «один ко многим»

Отношение «один ко многим» имеет место, когда одной записи таблицы Т1 (родитель­ской) соответствует несколько записей таблицы Т2 (дочерней) (Рис. 9). На рис. 9 представлена БД, состоящая из двух таблиц «Факультеты» - родительская и «Студенты» - дочерняя.

В родительской таблице поле Код_Факультета является первичным ключом, а в дочер­ней одноименное поле является внешним ключом. Между этими таблицами должны быть соблюдены правила целостности (смотри ниже).

Как видим, одной записи родительской таблицы соответствует несколько записей до­черней таблицы (Рис. 9). Не исключено, что в дочерней таблице может и не быть записей соответствующих записи в родительской таблице (например: нет студентов на химиче­ском факультете (ХФ)).

5-

Рис. 9

Различают две разновидности отношений «один ко многим»:

1. любой записи в родительской таблице соответствует одна или несколько записей в дочерней таблице,

2. записи в родительской таблице может несколько записей в дочерней таблице или не найтись ни одой.

Связь «один ко многим» является самой распространенной и позволяет создавать иерар­хическую структуру данных.

Отношение «многие ко многим»

Отношение «многие ко многим» имеет место, когда:

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

2. записи в дочерней таблице могут соответствовать несколько записей в родитель­ ской таблице.

Рис. 10

Как показано на Рис. 10 каждой учебной группе соответствует несколько преподавателей. Каждый из них может преподавать в разных группах и разные предметы. Считается, что связь «многие ко многим» может быть заменена на несколько связей «один ко многим». Не все БД поддерживают данный вид отношений.

55

Правила целостности

Два правила целостности для РБД .

1. Целостность по сущностям: не допускается, чтобы столбец первичного ключа ка­ кой-либо таблицы содержал неопределенное значение (null).

2. Целостность по ссылкам: если таблица Т2 содержит внешний ключ fk, соответст­ вующий первичному ключу рк другой таблицы Т1, то каждое значение fk в Т2 долж­ но:

• либо быть равным значению рк для некоторой строки таблицы Т1,

• либо быть неопределенным (иметь значение null).

На Рис. 11 и Рис. 12 представлены две одинаковых БД, для каждой из которых: 1. первичным ключом является поле Код_Факультета таблицы Факультеты, 2. вешним ключом, поле Код_Факультета таблицы Студенты.

На Рис. 11 правила целостности соблюдены.

На Рис. 12 правила целостности нарушены (рк имеет null и значения fk 7 и 13, не соот­ветствуют ни одному значениям рк).

Правила целостности соблюдены.

Правила целостности нарушены.

56