Базы данных. Курс лекций

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

Обычно БД создается для хранения и доступа к данным, содержащим сведения о некоторой предметной области, т. е. некоторой области человеческой деятельности или области реального мира. Всякая БД должна представлять собой систему данных о предметной области. БД, относящиеся к одной и той же предметной области, в различных случаях содержат более или менее детализированную информацию о ней. Степень детализации определяется рядом факторов, прежде всего целью использования информации из базы данных и сложностью производственных (деловых) процессов, существующих в пределах предметной области в конкретных условиях.

3. Основные понятия реляционной модели данных

Реляционные системы далеко не сразу получили широкое распространение. В то время как основные теоретические результаты в этой области были получены еще в 1970-х годах и тогда же появились первые прототипы реляционных СУБД, долгое время считалось невозможным добиться эффективной реализации таких систем. Однако постепенное накопление методов и алгоритмов организации реляционных баз данных и управления ими привел к тому, что уже в середи-

20

не 80-х годов реляционные системы практически вытеснили с мирового рынка ранние СУБД.

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

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

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

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

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

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

21

Реляционная модель данных основывается на математических принципах, вытекающих непосредственно из теории множеств и логики предикатов. Эти принципы впервые были применены в области моделирования данных в конце 1960-х годов доктором Ф. Коддом.

Техническая статья «Реляционная модель данных для больших разделяемых банков данных» доктора Ф. Кодда, опубликованная в 1970 г., является родоначальницей современной теории реляционных БД. Доктор Кодд определил правила реляционной модели (которые называют двенадцатью правилами Кодда).

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

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

ТИПЫ ДАННЫХ

ДОМЕНЫ

Рис. 9. Основные понятия реляционных баз данных

22

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

Основными понятиями реляционных баз данных являются: тип данных,

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

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

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

3.1. Тип данных

Типы данных в реляционной модели необходимы для характеристики хранимых данных. В реляционных базах данных допускается хранение текстовых, числовых данных, битовых строк, специализированных числовых данных (таких как «деньги»), а также специальных «темпоральных» данных (дата/время), логических данных, гиперссылок, объектов OLE.

3.2. Домен

В самом общем виде домен определяется заданием некоторого базового типа данных, к которому относятся элементы домена. Домен понимается как допустимое потенциальное множество значений данного типа. На рис. 9 изображены пять доменов: «№ удостоверения», «ФИО», «Должность», «Номер отдела», «Год рождения», соответствующие двум базовым типам данных: целые числа, символьные строки. Например, домен «ФИО» в этом примере определен на базовом текстовом типе, но в число его значений могут входить только те строки, которые могут изображать фамилию, имя и отчество (в частности, такие строки не могут начинаться с мягкого знака).

23

Следует отметить также семантическую нагрузку понятия домена: данные считаются сравнимыми только в том случае, когда они относятся к одному домену. В нашем примере значения доменов «№ удостоверения», «Номер отдела» и «Год рождения» относятся к типу целых чисел, но не являются сравнимыми.

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

В каждой таблице БД существует первичный ключ.

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

Таблица «Сотрудники»

Рис. 10.

•ФИО – поскольку практически известно, что даже в одном отделе могут работать однофамильцы с одинаковыми инициалами или даже полные тезки;

•должность – поскольку, хотя для данного примера названия должностей и уникальны, в любом отделе наверняка найдутся сотрудники, занимающие одну и ту же должность;

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

24

В качестве первичного ключа может выступать номер пропуска, но при этом нужно сделать оговорку. Если номер пропуска недавно уволившегося сотрудника не может быть назначен сотруднику, впоследствии принятому на работу (т. е. является уникальным во времени), нет никаких ограничений на использование этого поля в качестве первичного ключа. Если же номер пропуска уволившегося сотрудника может быть назначен вновь поступившему сотруднику, следует изучить вопрос, удаляется ли информация об уволившемся сотруднике из базы данных. Если да, то поле может быть первичным ключом; если нет – не может быть первичным ключом, поскольку в базе данных могут присутствовать два сотрудника с одинаковым номером пропуска. В этом случае следует добавить в таблицу семантически незначащее поле (т. е. не имеющее иного смысла, кроме обеспечения уникальности записи), например числовое поле NN (рис. 11). Уникальность подобного поля обычно отслеживается или программно, или автоматически.

Таблица «Сотрудники»

Рис. 11.

В первом случае при добавлении нового сотрудника приложение, работающее с базой данных, отыскивает максимальный номер сотрудника, увеличивает на 1 и назначает вновь добавляемой записи. Во втором случае первичный ключ реализуется через автоинкрементное4 поле. Для него указанные действия выполняются автоматически системой управления базой данных. Существуют и иные способы обеспечения уникальности значений ключевого числового поля, они зависят от особенностей конкретной СУБД.

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

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

25

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

Приведем другие примеры первичных ключей:

•номер и серия паспорта;

•номер двигателя;

•фамилия и инициалы автора, название книги, год издания, издательство. В случае если принять во внимание, что в течение одного года книга может издаваться тем же издательством повторно, в первичный ключ следует добавить номер издания (2-е, 3-е и т. д.);

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

•номер лицевого счета в бухгалтерском балансе;

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

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

•почтовый адрес организации – с указанием номеров комнат, в случае если в одном здании располагается несколько организаций (например, офисное здание);

•банковские реквизиты;

•регистрационный номер банка, организации;

•дата, номер страхового полиса, специализация и (или) фамилия и инициалы

врача-специалиста – при обращении в поликлинику и т. д.

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

26

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

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

3.4. Реляционные отношения (связи) между таблицами базы дан-

ных

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

Существует три разновидности связей между таблицами базы данных: «один-ко-многим», «один-к-одному», «многие-ко-многим».

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

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

Как видно из рис. 12, одной записи из родительской таблицы «Товары» может соответствовать несколько записей в дочерней таблице «Отпуск товаров». Обратите внимание на глагол может: он означает, что такая возможность — по-

27

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

Поэтому различают две разновидности связи «один-ко-многим» — в первом случае выдвигается жесткое требование, согласно которому всякой записи в родительской таблице должны соответствовать записи в дочерней таблице. Во втором случае подобное требование не носит жесткого характера и подразумевается (как в описанном выше случае), что некоторые записи в родительской таблице могут не иметь связанных с ними записей в дочерней таблице. Связь «один-ко- многим» иногда называют связью «многие-к-одному». В этом случае подразумевается, что мы смотрим со стороны дочерней таблицы на родительскую. Когда упоминают название «один-ко-многим», имеется в виду, что следует смотреть со стороны родительской таблицы на дочернюю. И в том и в другом случае сущность связи между таблицами остается неизменной.

Рис. 12. Связь «один-ко-многим»

Связь «один-ко-многим» является самой распространенной для реляционных баз данных. Как можно заметить, она позволяет моделировать иерархии данных.

28

В широко распространенной нотации структуры баз данных IDEFIX5 отношение «один-ко-многим» изображается путем соединения таблиц линией, которая на стороне дочерней таблицы оканчивается стрелкой, кружком или иным символом. Поля, входящие в первичный ключ для данной ТБД, всегда расположены вверху и отчеркнуты от прочих полей линией (рис. 13).

Рис. 13. Связь «один-ко-многим» в нотации IDEFIX

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

Отношение «один-к-одному» имеет место, когда одной записи в родительской таблице соответствует одна запись в дочерней таблице (рис. 14).

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

Кроме того, базы данных, в состав которых входят таблицы со связью «один-к-одному», не могут считаться до конца нормализованными (о нормализации см. ниже).

Связь «один-к-одному» может быть жесткой и нежесткой. В первом случае для каждой записи в родительской таблице должна существовать запись в дочерней таблице. Во втором случае — запись в дочерней таблице может как существовать, таки отсутствовать.

5 Для изображения логической структуры данных используется несколько общепринятых способов, нота-

ций, а именно: IDEF1X - Integration DEFinition for Information Modeling, IE - Information Engineering) и DM - Dimensional Modeling.

29