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

ОСНОВЫ  ПРОЕКТИРОВАНИЯ РЕЛЯЦИОННЫХ БАЗ  ДАННЫХ

Санкт-Петербургский Государственный  институт 
точной механики и оптики (технический университет)

Кафедра вычислительной техники

В.В. Кириллов

ОГЛАВЛЕНИЕ

Глава 1. Что такое базы данных и СУБД 
    1.1. Данные и ЭВМ 
    1.2. Концепция баз данных 
    1.3. Архитектура СУБД 
    1.4. Модели данных 
Глава 2. Инфологическая модель данных "Сущность-связь" 
    2.1. Основные понятия 
    2.2. Характеристика связей и язык моделирования 
    2.3. Классификация сущностей 
    2.4. О первичных и внешних ключах 
    2.5. Ограничения целостности 
    2.6. О построении инфологической модели 
Глава 3. Реляционный подход 
    3.1. Реляционная структура данных 
    3.2. Реляционная база данных 
    3.3. Манипулирование реляционными данными 
Глава 4. Введение в проектирование реляционных баз данных 
    4.1. Цели проектирования 
    4.2. Универсальное отношение 
    4.3. Почему проект БД может быть плохим? 
    4.4. О нормализации, функциональных и многозначных зависимостях 
    4.5. Нормальные формы 
    4.6. Процедура нормализации 
    4.7. Процедура проектирования 
    4.8. Различные советы и рекомендации 
Глава 5. Пример проектирования базы данных "Библиотека" 
    5.1. Назначение и предметная область 
    5.2. Построение инфологической модели 
    5.3. Проектирование базы данных 
Литература 
Предметный указатель

Глава 1. Что такое базы данных и  СУБД

1.1. Данные и ЭВМ

Восприятие реального мира можно  соотнести с последовательностью  разных, хотя иногда и взаимосвязанных, явлений. С давних времен люди пытались описать эти явления (даже тогда, когда не могли их понять). Такое описание называют данными.

Традиционно фиксация данных осуществляется с помощью конкретного средства общения (например, с помощью естественного языка или изображений) на конкретном носителе (например, камне или бумаге). Обычно данные (факты, явления, события, идеи или предметы) и их интерпретация (семантика) фиксируются совместно, так как естественный язык достаточно гибок для представления того и другого. Примером может служить утверждение "Стоимость авиабилета 128". Здесь "128" – данное, а "Стоимость авиабилета" – его семантика.

Нередко данные и интерпретация  разделены. Например, "Расписание движения самолетов" может быть представлено в виде таблицы (рис. 1.1), в верхней  части которой (отдельно от данных) приводится их интерпретация. Такое разделение затрудняет работу с данными (попробуйте быстро получить сведения из нижней части таблицы).

Интерпретация
Номер рейса	Дни недели	Пункт отправления	Время вылета	Пункт назначения	Время прибытия	Тип самолета	Стоимость билета
Данные
138	2_4_7	Баку	21.12	Москва	0.52	ИЛ-86	115.00
57	3_6	Ереван	7.20	Киев	9.25	ТУ-154	92.00
1234	2_6	Казань	22.40	Баку	23.50	ТУ-134	73.50
242	1 по 7	Киев	14.10	Москва	16.15	ТУ-154	57.00
86	2_3_5	Минск	10.50	Сочи	13.06	ИЛ-86	78.50
137	1_3_6	Москва	15.17	Баку	18.44	ИЛ-86	115.00
241	1 по 7	Москва	9.05	Киев	11.05	ТУ-154	57.00
577	1_3_5	Рига	21.53	Таллин	22.57	АН-24	21.50
78	3_6	Сочи	18.25	Баку	20.12	ТУ-134	44.00
578	2_4_6	Таллин	6.30	Рига	7.37	АН-24	21.50

Рис. 1.1. К разделению данных и их интерпретации

Применение ЭВМ для ведения* и обработки данных обычно приводит к еще большему разделению данных и интерпретации. ЭВМ имеет дело главным образом с данными как таковыми. Большая часть интерпретирующей информации вообще не фиксируется в явной форме (ЭВМ не "знает", является ли "21.50" стоимостью авиабилета или временем вылета). Почему же это произошло?

Существует по крайней мере две  исторические причины, по которым применение ЭВМ привело к отделению данных от интерпретации. Во-первых, ЭВМ не обладали достаточными возможностями для обработки текстов на естественном языке – основном языке интерпретации данных. Во-вторых, стоимость памяти ЭВМ была первоначально весьма велика. Память использовалась для хранения самих данных, а интерпретация традиционно возлагалась на пользователя. Пользователь закладывал интерпретацию данных в свою программу, которая "знала", например, что шестое вводимое значение связано с временем прибытия самолета, а четвертое – с временем его вылета. Это существенно повышало роль программы, так как вне интерпретации данные представляют собой не более чем совокупность битов на запоминающем устройстве.

Жесткая зависимость между данными и использующими их программами создает серьезные проблемы в ведении данных и делает использования их менее гибкими.

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

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

Для иллюстрации обратимся к  примеру, приведенному в книге: У.Девис, Операционные системы, М., Мир, 1980:

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

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

 

* Ведение (сопровождение,  поддержка) данных – термин  объединяющий действия по добавлению, удалению или изменению храни-мых данных.

1.2. Концепция баз данных

Активная деятельность по отысканию  приемлемых способов обобществления непрерывно растущего объема информации привела к созданию в начале 60-х годов специальных программных комплексов, называемых "Системы управления базами данных" (СУБД).

Основная особенность СУБД –  это наличие процедур для ввода  и хранения не только самих данных, но и описаний их структуры. Файлы, снабженные описанием хранимых в них данных и находящиеся под управлением СУБД, стали называть банки данных, а затем "Базы данных" (БД).

Пусть, например, требуется хранить  расписание движения самолетов (рис. 1.1) и ряд других данных, связанных с организацией работы аэропорта (БД "Аэропорт"). Используя для этого одну из современных "русифицированных" СУБД, можно подготовить следующее описание расписания:

СОЗДАТЬ ТАБЛИЦУ Расписание

  (Номер_рейса        Целое

   Дни_недели         Текст (8)

   Пункт_отправления  Текст  (24)

   Время_вылета       Время

   Пункт_назначения   Текст  (24)

   Время_прибытия     Время

   Тип_самолета       Текст (8)

   Стоимость_билета   Валюта);

и ввести его вместе с данными  в БД "Аэропорт".

Язык запросов СУБД позволяет обращаться за данными как из программ, так и с терминалов (рис. 1.2). Сформировав запрос

ВЫБРАТЬ  Номер_рейса, Дни_недели, Время_вылета

ИЗ  ТАБЛИЦЫ  Расписание

ГДЕ  Пункт_отправления = 'Москва'

  И  Пункт_назначения  = 'Киев'

  И  Время_вылета > 17;

получим расписание "Москва-Киев" на вечернее время, а по запросу

ВЫБРАТЬ  КОЛИЧЕСТВО(Номер_рейса)

ИЗ  ТАБЛИЦЫ  Расписание

ГДЕ  Пункт_отправления = 'Москва'

  И  Пункт_назначения  = 'Минск';

получим количество рейсов "Москва-Минск".

Рис. 1.2. Связь программ и данных при использовании СУБД

Эти запросы не потеряют актуальности и при расширении таблицы:

ДОБАВИТЬ В ТАБЛИЦУ Расписание

   Длительность_полета  Целое;

как это было с программами обработки почтовых адресов при введении почтового индекса (см. п. 1.1).

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

1.3. Архитектура СУБД

СУБД должна предоставлять доступ к данным любым пользователям, включая  и тех, которые практически не имеют и (или) не хотят иметь представления  о:

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

и множестве других функций СУБД.

При выполнении основных из этих функций  СУБД должна использовать различные  описания данных. А как создавать  эти описания?

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

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

Рис. 1.3. Уровни моделей данных

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

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

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

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