Архитектура СУБД
СУБД должна предоставлять доступ к данным любым пользователям, включая и тех, которые практически не имеют и (или) не хотят иметь представления о:
физическом размещении в памяти данных и их описаний; механизмах поиска запрашиваемых данных; проблемах, возникающих при одновременном запросе одних и тех же данных многими пользователями (прикладными программами); способах обеспечения защиты данных от некорректных обновлений и (или) несанкционированного доступа; поддержании баз данных в актуальном состоянии
и множестве других функций СУБД.
При выполнении основных из этих функций СУБД должна использовать различные описания данных. А как создавать эти описания?
Естественно, что проект базы данных надо начинать с анализа предметной области и выявления требований к ней отдельных пользователей (сотрудников организации, для которых создается база данных). Подробнее этот процесс будет рассмотрен ниже, а здесь отметим, что проектирование обычно поручается человеку (группе лиц) – администратору базы данных (АБД). Им может быть как специально выделенный сотрудник организации, так и будущий пользователь базы данных, достаточно хорошо знакомый с машинной обработкой данных.
Объединяя частные представления о содержимом базы данных, полученные в результате опроса пользователей, и свои представления о данных, которые могут потребоваться в будущих приложениях, АБД сначала создает обобщенное неформальное описание создаваемой базы данных. Это описание, выполненное с использованием естественного языка, математических формул, таблиц, графиков и других средств, понятных всем людям, работающих над проектированием базы данных, называют инфологической моделью данных (рис. 1.3).
Рис. 1.3. Уровни моделей данных
Такая человеко-ориентированная модель полностью независима от физических параметров среды хранения данных. В конце концов этой средой может быть память человека, а не ЭВМ. Поэтому инфологическая модель не должна изменяться до тех пор, пока какие-то изменения в реальном мире не потребуют изменения в ней некоторого определения, чтобы эта модель продолжала отражать предметную область.
Остальные модели, показанные на рис. 1.3, являются компьютеро-ориентированными. С их помощью СУБД дает возможность программам и пользователям осуществлять доступ к хранимым данным лишь по их именам, не заботясь о физическом расположении этих данных. Нужные данные отыскиваются СУБД на внешних запоминающих устройствах по физической модели данных.
Так как указанный доступ осуществляется с помощью конкретной СУБД, то модели должны быть описаны на языке описания данных этой СУБД. Такое описание, создаваемое АБД по инфологической модели данных, называют даталогической моделью данных.
Трехуровневая архитектура (инфологический, даталогический и физический уровни) позволяет обеспечить независимость хранимых данных от использующих их программ. АБД может при необходимости переписать хранимые данные на другие носители информации и (или) реорганизовать их физическую структуру, изменив лишь физическую модель данных. АБД может подключить к системе любое число новых пользователей (новых приложений), дополнив, если надо, даталогическую модель. Указанные изменения физической и даталогической моделей не будут замечены существующими пользователями системы (окажутся "прозрачными" для них), так же как не будут замечены и новые пользователи. Следовательно, независимость данных обеспечивает возможность развития системы баз данных без разрушения существующих приложений.
[Назад] [Содержание] [Вперед]
Характеристика связей и язык моделирования
При построении инфологических моделей можно использовать язык ER-диаграмм (от англ. Entity-Relationship, т.е. сущность-связь). В них сущности изображаются помеченными прямоугольниками, ассоциации – помеченными ромбами или шестиугольниками, атрибуты – помеченными овалами, а связи между ними – ненаправленными ребрами, над которыми может проставляться степень связи (1 или буква, заменяющая слово "много") и необходимое пояснение.
Между двумя сущностям, например, А и В возможны четыре вида связей.
Первый тип – связь ОДИН-К-ОДНОМУ (1:1): в каждый момент времени каждому представителю (экземпляру) сущности А соответствует 1 или 0 представителей сущности В:
Студент может не "заработать" стипендию, получить обычную или одну из повышенных стипендий.
Второй тип – связь ОДИН-КО-МНОГИМ (1:М): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В.
Квартира может пустовать, в ней может жить один или несколько жильцов.
Так как между двумя сущностями возможны связи в обоих направлениях, то существует еще два типа связи МНОГИЕ-К-ОДНОМУ (М:1) и МНОГИЕ-КО-МНОГИМ (М:N).
Пример 2.1. Если связь между сущностями МУЖЧИНЫ и ЖЕНЩИНЫ называется БРАК, то существует четыре возможныхпредставления такой связи:
Характер связей между сущностями не ограничивается перечисленными. Существуют и более сложные связи:
множество связей между одними и теми же сущностями
(пациент, имея одного лечащего врача, может иметь также несколько врачей-консультантов; врач может быть лечащим врачом нескольких пациентов и может одновременно консультировать несколько других пациентов);
тренарные связи
(врач может назначить несколько пациентов на несколько анализов, анализ может быть назначен несколькими врачами нескольким пациентам и пациент может быть назначен на несколько анализов несколькими врачами);
связи более высоких порядков, семантика (смысл) которых иногда очень сложна.
В приведенных примерах для повышения иллюстративности рассматриваемых связей не показаны атрибуты сущностей и ассоциаций во всех ER-диаграммах.
Так, ввод лишь нескольких основных атрибутов в описание брачных связей значительно усложнит ER-диаграмму (рис. 2.1,а). В связи с этим язык ER-диаграмм используется для построении небольших моделей и иллюстрации отдельных фрагментов больших. Чаще же применяется менее наглядный, но более содержательный язык инфологического моделирования (ЯИМ), в котором сущности и ассоциации представляются предложениями вида:
СУЩНОСТЬ (атрибут 1, атрибут 2 , ..., атрибут n) АССОЦИАЦИЯ [СУЩНОСТЬ S1, СУЩНОСТЬ S2, ...] (атрибут 1, атрибут 2, ..., атрибут n)
где S – степень связи, а атрибуты, входящие в ключ, должны быть отмечены с помощью подчеркивания.
Так, рассмотренный выше пример множества связей между сущностями, может быть описан на ЯИМ следующим образом:
Врач (Номер_врача, Фамилия, Имя, Отчество, Специальность) Пациент (Регистрационный_номер, Номер койки, Фамилия, Имя, Отчество, Адрес, Дата рождения, Пол) Лечащий_врач [Врач 1, Пациент M] (Номер_врача, Регистрационный_номер) Консультант [Врач M,Пациент N] (Номер_врача, Регистрационный_номер).
Рис. 2.1. Примеры ER-диаграмм
Для выявления связей между сущностями необходимо, как минимум, определить сами сущности. Но это не простая задача, так как в разных предметных областях один и тот же объект может быть сущностью, атрибутом или ассоциацией. Проиллюстрируем такое утверждение на примерах, связанных с описанием брачных связей (см. пример 2.1).
Пример 2.2. Отдел записей актов гражданского состояния (ЗАГС) имеет дело не со всеми людьми, а только с теми, кто обратился с просьбой о регистрации брака, рождения или смерти. Поэтому в странах, где допускаются лишь традиционные браки, отделы ЗАГС могут размещать сведения о регистрируемых браках в единственной сущности:
Брак (Номер_свидетельства, Фамилия_мужа, Имя_мужа, Отчество_мужа, Дата_рождения_мужа, Фамилия_жены, ... , Дата_регистрации, Место_регистрации, ...),
ER-диаграмма которой приведена на рис. 2.1,б.
Пример 2.3. Теперь рассмотрим ситуацию, когда отдел ЗАГС расположен в стране, допускающей многоженство.
Если для регистрации браков использовать сущность "Брак" примера 2.2, то будут дублироваться сведения о мужьях, имеющих несколько жен (см. табл. 2.1).
Таблица 2.1
| 1-ЮБ 154745 | Петухов | ... | Курочкина | ... | 06/03/1991 |
| 1-ЮБ 163489 | Петухов | ... | Пеструшкина | ... | 11/08/1991 |
| 1-ЮБ 169887 | Петухов | ... | Рябова | ... | 12/12/1992 |
| 1-ЮБ 169878 | Селезнев | ... | Уточкина | ... | 12/12/1992 |
| 1-ЮБ 154746 | Парасюк | ... | Свинюшкина | ... | 06/03/1991 |
| 1-ЮБ 169879 | Парасюк | ... | Хаврония | ... | 12/12/1992 |
| ... | ... | ... | ... | ... | ... |
Мужья (Код_М, Фамилия, Имя, Отчество, Дата рождения, Место рождения)
и заменой сущности "Брак" характеристикой (см. п. 2.3) со ссылкой на соответствующее описание в сущности "Мужья".
Брак (Номер свидетельства, Код_М, Фамилия жены, ..., Дата регистрации, ...){Мужья}.
ER-диаграмма связи этих сущностей показана на рис. 2.1,в, а пример их экземпляров в табл. 2.2 и 2.3.
Таблица 2.2
| 111 | Петухов | Альфред | Остапович | 1971 | г. Цапелька |
| 112 | Селезнев | Вавила | Абрамович | 1973 | г. Гусев |
| 113 | Парасюк | Гораций | Федулович | 1972 | г. Свиньин |
| ... | ... | ... | ... | ... | ... |
| 1-ЮБ 154745 | 111 | Курочкина | Августина | 06/03/1991 | ... |
| 1-ЮБ 163489 | 111 | Пеструшкина | Мариана | 11/08/1991 | ... |
| 1-ЮБ 169877 | 111 | Рябова | Милана | 12/12/1992 | ... |
| 1-ЮБ 169878 | 112 | Уточкина | Вероника | 12/12/1992 | ... |
| 1-ЮБ 154746 | 113 | Свинюшкина | Эльвира | 06/03/1991 | ... |
| 1_ЮБ 169879 | 113 | Хаврония | Руфина | 12/12/1992 | ... |
| ... | ... | ... | ... | ... | ... |
Сотрудники (Табельный_номер, Фамилия, Имя, ...).
Использование, рассмотренной в примере 2.2, сущности "Брак" нецелесообразно: в "Сотрудники" уже есть фамилии, имена, отчества супругов. Поэтому создадим ассоциацию
Брак [Сотрудник 1, Сотрудник 1] (Табельный_номер_мужа, Табельный_номер_жены, ...),
связывающую между собой определенные экземпляры сущности "Сотрудники" (рис. 2.1,г).
В заключение отметим, что ER-диаграмма рис. 2.1,а описывает структуру размещения данных о браках в отделах ЗАГС стран, допускающих групповые браки, а ER-диаграммы примера 2.1, описания любых видов браков в организациях, где есть сущности "мужчины" и "женщины", включающие холостых и незамужних.
Что же такое "связь"? В ER-диаграммах это линия, соединяющая геометрические фигуры, изображающие сущности, атрибуты, ассоциации и другие информационные объекты. В тексте же этот термин используется для указания на взаимозависимость сущностей. Если эта взаимозависимость имеет атрибуты, то она называется ассоциацией.
[Назад] [Содержание] [Вперед]
Классификация сущностей
Настал момент разобраться в терминологии. К.Дейт [3] определяет три основные класса сущностей: стержневые, ассоциативные и характеристические, а также подкласс ассоциативных сущностей – обозначения.
Стержневая сущность (стержень) – это независимая сущность (несколько подробнее она будет определена ниже).
В рассмотренных ранее примерах стержни – это "Студент", "Квартира", "Мужчины", "Врач", "Брак" (из примера 2.2) и другие, названия которых помещены в прямоугольники.
Ассоциативная сущность (ассоциация) – это связь вида "многие-ко-многим" ("-ко-многим" и т.д.) между двумя или более сущностями или экземплярами сущности (как в примере 2.4). Ассоциации рассматриваются как полноправные сущности:
они могут участвовать в других ассоциациях и обозначениях точно так же, как стержневые сущности;
могут обладать свойствами, т.е. иметь не только набор ключевых атрибутов, необходимых для указания связей, но и любое число других атрибутов, характеризующих связь. Например, ассоциации "Брак" из примеров 2.1 и 2.4 содержат ключевые атрибуты "Код_М", "Код_Ж" и "Табельный номер мужа", "Табельный номер жены", а также уточняющие атрибуты "Номер свидетельства", "Дата регистрации", "Место_регистрации", "Номер записи в книгу ЗАГС" и т.д.
Характеристическая сущность (характеристика) – это связь вида "многие-к-одной" или "одна-к-одной" между двумя сущностями (частный случай ассоциации). Единственная цель характеристики в рамках рассматриваемой предметной области состоит в описании или уточнении некоторой другой сущности. Необходимость в них возникает в связи с тем, что сущности реального мира имеют иногда многозначные свойства. Муж может иметь несколько жен (пример 2.3), книга – несколько характеристик переиздания (исправленное, дополненное, переработанное, ...) и т.д.
Существование характеристики полностью зависит от характеризуемой сущности: женщины лишаются статуса жен, если умирает их муж.
Для описания характеристики используется новое предложение ЯИМ, имеющее в общем случае вид:
ХАРАКТЕРИСТИКА (атрибут 1, атрибут 2, ...) {СПИСОК ХАРАКТЕРИЗУЕМЫХ СУЩНОСТЕЙ}.
Расширим также язык ER-диаграмм, введя для изображения характеристики трапецию (рис. 2.2).
Рис. 2.2. Элементы расширенного языка ER-диаграмм
Обозначающая сущность или обозначение – это связь вида "многие-к-одной" или "одна-к-одной" между двумя сущностями и отличается от характеристики тем, что не зависит от обозначаемой сущности.
Рассмотрим пример, связанный с зачислением сотрудников в различные отделы организации.
При отсутствии жестких правил (сотрудник может одновременно зачисляться в несколько отделов или не зачисляться ни в один отдел) необходимо создать описание с ассоциацией Зачисление:
Отделы (Номер отдела, Название отдела, ...) Служащие (Табельный номер, Фамилия, ...) Зачисление [Отделы M, Служащие N] (Номер отдела, Табельный номер, Дата зачисления).
Однако, при условии, что каждый из сотрудников должен быть обязательно зачислен в один из отделов, можно создать описание с обозначением Служащие:
Отделы (Номер отдела, Название отдела, ...) Служащие (Табельный номер, Фамилия, ... , Номер отдела, Дата зачисления)[Отделы]
В данном примере служащие имеют независимое существование (если удаляется отдел, то из этого не следует, что также должны быть удалены служащие такого отдела). Поэтому они не могут быть характеристиками отделов и названы обозначениями.
Обозначения используют для хранения повторяющихся значений больших текстовых атрибутов: "кодификаторы" изучаемых студентами дисциплин, наименований организаций и их отделов, перечней товаров и т.п.
Описание обозначения внешне отличается от описания характеристики только тем, что обозначаемые сущности заключается не в фигурные скобки, а в квадратные:
ОБОЗНАЧЕНИЕ (атрибут 1, атрибут 2, ...)[СПИСОК ОБОЗНАЧАЕМЫХ СУЩНОСТЕЙ].
Как правило, обозначения не рассматриваются как полноправные сущности, хотя это не привело бы к какой-либо ошибке.
Обозначения и характеристики не являются полностью независимыми сущностями, поскольку они предполагают наличие некоторой другой сущности, которая будет "обозначаться" или "характеризоваться". Однако они все же представляют собой частные случаи сущности и могут, конечно, иметь свойства, могут участвовать в ассоциациях, обозначениях и иметь свои собственные (более низкого уровня) характеристики. Подчеркнем также, что все экземпляры характеристики должны быть обязательно связаны с каким-либо экземпляром характеризуемой сущности. Однако допускается, чтобы некоторые экземпляры характеризуемой сущности не имели связей. Правда, если это касается браков, то сущность "Мужья" должна быть заменена на сущность "Мужчины" (нет мужа без жены).
Переопределим теперь стержневую сущность как сущность, которая не является ни ассоциацией, ни обозначением, ни характеристикой. Такие сущности имеют независимое существование, хотя они и могут обозначать другие сущности, как, например, сотрудники обозначают отделы.
В заключение рассмотрим пример построения инфологической модели базы данных "Питание", где должна храниться информация о блюдах (рис. 2.3), их ежедневном потреблении, продуктах, из которых приготавливаются эти блюда, и поставщиках этих продуктов. Информация будет использоваться поваром и руководителем небольшого предприятия общественного питания, а также его посетителями.
|
1. Лобио по грузински Ломаную очищенную фасоль, нашинкованный лук посолить, посыпать перцем и припустить в масле с небольшим количеством бульона; добавить кинзу, зелень петрушки, рейган (базилик) и довести до готовности. Затем запечь в духовке. Фасоль стручковая (свежая или консервированная) 200, Лук зеленый 40, Масло сливочное 30, Зелень 10. Выход 210. Калорий 725. |
С помощью указанных пользователей выделены следующие объекты и характеристики проектируемой базы:
Блюда, для описания которых нужны данные, входящие в их кулинарные рецепты: номер блюда (например, из книги кулинарных рецептов), название блюда, вид блюда (закуска, суп, горячее и т.п.), рецепт (технология приготовления блюда), выход (вес порции), название, калорийность и вес каждого продукта, входящего в блюдо. Для каждого поставщика продуктов: наименование, адрес, название поставляемого продукта, дата поставки и цена на момент поставки. Ежедневное потребление блюд (расход): блюдо, количество порций, дата.
Анализ объектов позволяет выделить:
стержни Блюда, Продукты и Города; ассоциации Состав (связывает Блюда с Продуктами) и
Поставки (связывает Поставщиков с Продуктами);
обозначение Поставщики; характеристики Рецепты и Расход.
ER-диаграмма модели показана на рис. 2.4. а модель на языке ЯИМ имеет следующий вид:
Блюда (БЛ, Блюдо, Вид) Продукты (ПР, Продукт, Калорийность) Поставщики (ПОС, Город, Поставщик) [Город] Состав [Блюда M, Продукты N] (БЛ, ПР, Вес (г)) Поставки [Поставщики M, Продукты N] (ПОС, ПР, Дата_П, Цена, Вес (кг)) Города (Город, Страна) Рецепты (БЛ, Рецепт) {Блюда} Расход (БЛ, Дата_Р, Порций) {Блюда}
В этих моделях Блюдо, Продукт и Поставщик – наименования, а БЛ, ПР и ПОС – цифровые коды блюд, продуктов и организаций, поставляющих эти продукты.
Рис. 2.4. Инфологическая модель базы данных "Питание"
[Назад] [Содержание] [Вперед]
Концепция баз данных
Активная деятельность по отысканию приемлемых способов обобществления непрерывно растущего объема информации привела к созданию в начале 60-х годов специальных программных комплексов, называемых "Системы управления базами данных" (СУБД).
Основная особенность СУБД – это наличие процедур для ввода и хранения не только самих данных, но и описаний их структуры. Файлы, снабженные описанием хранимых в них данных и находящиеся под управлением СУБД, стали называть банки данных, а затем "Базы данных" (БД).
Пусть, например, требуется хранить расписание движения самолетов (рис. 1.1) и ряд других данных, связанных с организацией работы аэропорта (БД "Аэропорт"). Используя для этого одну из современных "русифицированных" СУБД, можно подготовить следующее описание расписания:
СОЗДАТЬ ТАБЛИЦУ Расписание (Номер_рейса Целое Дни_недели Текст (8) Пункт_отправления Текст (24) Время_вылета Время Пункт_назначения Текст (24) Время_прибытия Время Тип_самолета Текст (8) Стоимость_билета Валюта);
и ввести его вместе с данными в БД "Аэропорт".
Язык запросов СУБД позволяет обращаться за данными как из программ, так и с терминалов (рис. 1.2). Сформировав запрос
ВЫБРАТЬ Номер_рейса, Дни_недели, Время_вылета ИЗ ТАБЛИЦЫ Расписание ГДЕ Пункт_отправления = 'Москва' И Пункт_назначения = 'Киев' И Время_вылета > 17;
получим расписание "Москва-Киев" на вечернее время, а по запросу
ВЫБРАТЬ КОЛИЧЕСТВО(Номер_рейса) ИЗ ТАБЛИЦЫ Расписание ГДЕ Пункт_отправления = 'Москва' И Пункт_назначения = 'Минск';
получим количество рейсов "Москва-Минск".
Рис. 1.2. Связь программ и данных при использовании СУБД
Эти запросы не потеряют актуальности и при расширении таблицы:
ДОБАВИТЬ В ТАБЛИЦУ Расписание Длительность_полета Целое;
как это было с программами обработки почтовых адресов при введении почтового индекса (см. п. 1.1).
Однако, за все надо расплачиваться: на обмен данными через СУБД требуется большее время, чем на обмен аналогичными данными прямо из файлов, специально созданных для того или иного приложения.
[Назад] [Содержание] [Вперед]
Манипулирование реляционными данными
В главе 4 будет показано, что стремление к минимизации числа таблиц для хранения данных может привести к возникновению различных проблем при их обновлении и будут даны рекомендации по разбиению некоторых больших таблиц на несколько маленьких. Но как сформировать требуемый ответ, если нужные для него данные хранятся в разных таблицах?
Предложив реляционную модель данных, Э.Ф.Кодд создал и инструмент для удобной работы с отношениями – реляционную алгебру. Каждая операция этой алгебры использует одну или несколько таблиц (отношений) в качестве ее операндов и продуцирует в результате новую таблицу, т.е. позволяет "разрезать" или "склеивать" таблицы (рис. 3.3).
Рис. 3.3. Некоторые операции реляционной алгебры
Созданы языки манипулирования данными, позволяющие реализовать все операции реляционной алгебры и практически любые их сочетания. Среди них наиболее распространены SQL (Structured Query Language – структуризованный язык запросов) и QBE (Quere-By-Example – запросы по образцу) [3, 5]. Оба относятся к языкам очень высокого уровня, с помощью которых пользователь указывает, какие данные необходимо получить, не уточняя процедуру их получения.
С помощью единственного запроса на любом из этих языков можно соединить несколько таблиц во временную таблицу и вырезать из нее требуемые строки и столбцы (селекция и проекция).
[Назад] [Содержание] [Вперед]
О первичных и внешних ключах
Напомним, что ключ или возможный ключ – это минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся. Каждая сущность обладает хотя бы одним возможным ключом. Один из них принимается за первичный ключ. При выборе первичного ключа следует отдавать предпочтение несоставным ключам или ключам, составленным из минимального числа атрибутов. Нецелесообразно также использовать ключи с длинными текстовыми значениями (предпочтительнее использовать целочисленные атрибуты). Так, для идентификации студента можно использовать либо уникальный номер зачетной книжки, либо набор из фамилии, имени, отчества, номера группы и может быть дополнительных атрибутов, так как не исключено появление в группе двух студентов (а чаще студенток) с одинаковыми фамилиями, именами и отчествами. Плохо также использовать в качестве ключа не номер блюда, а его название, например, " Закуска из плавленых сырков "Дружба" с ветчиной и соленым огурцом" или "Заяц в сметане с картофельными крокетами и салатом из красной капусты".
Не допускается, чтобы первичный ключ стержневой сущности (любой атрибут, участвующий в первичном ключе) принимал неопределенное значение. Иначе возникнет противоречивая ситуация: появится не обладающий индивидуальностью, и, следовательно не существующий экземпляр стержневой сущности. По тем же причинам необходимо обеспечить уникальность первичного ключа.
Теперь о внешних ключах:
Если сущность С связывает сущности А и В, то она должна включать внешние ключи, соответствующие первичным ключам сущностей А и В. Если сущность В обозначает сущность А, то она должна включать внешний ключ, соответствующий первичному ключу сущности А.
В п. 2.3 рассматривался пример, где "Служащие" обозначали "Отделы" и включали внешний ключ "Номер отдела", соответствующий первичному ключу сущности "Отделы".
Связь между первичными и внешними ключами сущностей иллюстрируется рис. 2.5.
Рис. 2.5. Структуры: а - ассоциации; б - обозначения (характеристики)
Здесь для обозначения любой из ассоциируемых сущностей (стержней, характеристик, обозначений или даже ассоциаций) используется новый обобщающий термин "Цель" или "Целевая сущность".
Таким образом, при рассмотрении проблемы выбора способа представления ассоциаций и обозначений в базе данных основной вопрос, на который следует получить ответ: "Каковы внешние ключи?". И далее, для каждого внешнего ключа необходимо решить три вопроса:
1. Может ли данный внешний ключ принимать неопределенные значения (NULL-значения)? Иначе говоря, может ли существовать некоторый экземпляр сущности данного типа, для которого неизвестна целевая сущность, указываемая внешним ключом? В случае поставок это, вероятно, невозможно – поставка, осуществляемая неизвестным поставщиком, или поставка неизвестного продукта не имеют смысла. Но в случае с сотрудниками такая ситуация однако могла бы иметь смысл – вполне возможно, что какой-либо сотрудник в данный момент не зачислен вообще ни в какой отдел. Заметим, что ответ на данный вопрос не зависит от прихоти проектировщика базы данных, а определяется фактическим образом действий, принятым в той части реального мира, которая должна быть представлена в рассматриваемой базе данных. Подобные замечания имеют отношение и к вопросам, обсуждаемым ниже.
2. Что должно случиться при попытке УДАЛЕНИЯ целевой сущности, на которую ссылается внешний ключ? Например, при удалении поставщика, который осуществил по крайней мере одну поставку. Существует три возможности:
КАСКАДИРУЕТСЯ | Операция удаления "каскадируется" с тем, чтобы удалить также поставки этого поставщика. |
ОГРАНИЧИВАЕТСЯ | Удаляются лишь те поставщики, которые еще не осуществляли поставок. Иначе операция удаления отвергается. |
УСТАНАВЛИВАЕТСЯ | Для всех поставок удаляемого поставщика NULL-значение внешний ключ устанавливается в неопределенное значение, а затем этот поставщик удаляется. Такая возможность, конечно, неприменима, если данный внешний ключ не должен содержать NULL-значений. |
3. Что должно происходить при попытке ОБНОВЛЕНИЯ первичного ключа целевой сущности, на которую ссылается некоторый внешний ключ? Например, может быть предпринята попытка обновить номер такого поставщика, для которого имеется по крайней мере одна соответствующая поставка. Этот случай для определенности снова рассмотрим подробнее. Имеются те же три возможности, как и при удалении:
КАСКАДИРУЕТСЯ | Операция обновления "каскадируется" с тем, чтобы обновить также и внешний ключ впоставках этого поставщика. |
ОГРАНИЧИВАЕТСЯ | Обновляются первичные ключи лишь тех поставщиков, которые еще не осуществляли поставок. Иначе операция обновления отвергается. |
УСТАНАВЛИВАЕТСЯ | Для всех поставок такого поставщика NULL-значение внешний ключ устанавливается в неопределенное значение, а затем обновляется первичный ключ поставщика. Такая возможность, конечно, неприменима, если данный внешний ключ не должен содержать NULL-значений. |
Наконец, о характеристиках – обозначающих сущностях, существование которых зависит от типа обозначаемых сущностей. Обозначение представляется внешним ключом в таблице, соответствующей этой характеристике. Но три рассмотренные выше ограничения на внешний ключ для данного случая должны специфицироваться следующим образом:
NULL-значения не допустимы УДАЛЕНИЕ ИЗ (цель) КАСКАДИРУЕТСЯ ОБНОВЛЕНИЕ (первичный ключ цели) КАСКАДИРУЕТСЯ
Указанные спецификации представляют зависимость по существованию характеристических сущностей.
[Назад] [Содержание] [Вперед]
Построение инфологической модели
Анализ определенных выше объектов и атрибутов позволяет выделить сущности проектируемой базы данных и, приняв решение о создании реляционной базы данных, построить ее инфологическую модель на языке "Таблицы-связи" (рис. 5.2).
К стержневым сущностям можно отнести:
Создатели (Код создателя, Создатель).
Эта сущность отводится для хранения сведений об основных людях, принимавших участие в подготовке рукописи издания (авторах, составителях, титульных редакторах, переводчиках и художниках). Такое объединение допустимо, так как данные о разных создателях выбираются из одного домена (фамилия и имена) и исключает дублирование данных (один и тот же человек может играть разные роли в подготовке разных изданий). Например, С.Я.Маршак писал стихи (Сказка о глупом мышонке) и пьесы (Двенадцать месяцев), переводил Дж.Байрона, Р.Бернса, Г.Гейне и составлял сборники стихов.
Так как фамилия и имена (инициалы) создателя могут быть достаточно громоздкими (М.Е. Салтыков-Щедрин, Франсуа Рене де Шатобриан, Остен Жюль Жан-Батист Ипполит и т.п.) и будут многократно встречаться в разных изданиях, то их целесообразно нумеровать и ссылаться на эти номера. Для этого вводится целочисленный атрибут "Код_создателя", который будет автоматически наращиваться на единицу при вводе в базу данных нового автора, переводчика или другого создателя.
Аналогично создаются: Код_издательства, Код_заглавия, Вид_ издания, Код_характера, Код_языка, Номер_билета, Номер_пере- плета, Код_места и Код_издания, замещающие от одного до девяти атрибутов.
Издательства (Код_издательства, Название, Город). Заглавия (Код_заглавия, Заглавие).
Выделение этой сущности позволит сократить объем данных и снизить вероятность возникновения противоречивости (исключается необходимость ввода длинных текстовых названий для различных томов собраний сочинений, повторных изданий, учебников и т.п.).
Вид_издания (Вид_издания, Название_вида). Характеры (Код_характера, Характер_переиздания). Языки (Код_языка, Язык, Сокращение).
Кроме названия языка хранится его общепринятое сокращение (англ., исп., нем., фр.), если оно существует.
Места (Код_места, Номер_комнаты, Номер_стеллажа, Номер_ полки).
Один из кодов этой сущности (например, "-1") отведен для описания обобщенного места, находящегося за стенами хранилища книг (издание выдано читателю, временно передано другой библиотеке или организации).
Читатели (Номер_билета, Фамилия, Имя, Отчество, Адрес, Телефон).
Две ключевые сущности, описывающие издание и его конкретные экземпляры, оказываются зависимыми от других сущностей и попадают в класс обозначений:
Издание (Код_издания, Код_заглавия, Вид_издания, Номер_тома, Авторский_знак, Библиотечн_шифр, Повторность, Код_издательства, Год_издания, Аннотация) [Заглавия, Вид_издания, Издательства]; Переплеты (Номер_переплета, Код_издания, Цена, Дата_приобретения)[Издания];
Стержневые сущности и обозначения связаны между собой ассоциациями:
Авторы [Создатели M, Издание N] (Код_создателя, Код_издания). Составители [Создатели M, Издания N] (Код_создателя, Код_издания). Редакторы [Создатели M, Издания N] (Код_создателя, Код_издания). Художники [Создатели M, Издания N] (Код_создателя, Код_издания). Переводчики [Создатели M, Издания N] (Код_создателя, Код_издания, Язык). Переиздания [Характеры M, Издания N] (Код_характера, Код_издания). Размещение [Места M, Переплеты N] (Код_места, Номер_переплета, Дата_размещения, Дата_изъятия). Выдача [Читатели M, Переплеты N] (Номер_билета, Номер_переплета, Дата_выдачи, Срок, Дата_возврата).
И, наконец, для уменьшения объема часто используемого обозначения "Издания" из него выделена характеристика:
Аннотации (Код_издания, Аннотация) {Издание}.
Рис. 5.2. Инфологическая модель базы данных "Библиотека", построенная с помощью языка "Таблицы-связи"
[Назад] [Содержание] [Вперед]
Процедура проектирования
Процесс проектирования информационных систем является достаточно сложной задачей. Он начинается с построения инфологической модели данных (п. 2), т.е. идентификации сущностей. Затем необходимо выполнить следующие шаги процедуры проектирования даталогической модели.
1. Представить каждый стержень (независимую сущность) таблицей базы данных (базовой таблицей) и специфицировать первичный ключ этой базовой таблицы.
2. Представить каждую ассоциацию (связь вида "многие-ко-многим" или "многие-ко-многим-ко-многим" и т.д. между сущностями) как базовую таблицу. Использовать в этой таблице внешние ключи для идентификации участников ассоциации и специфицировать ограничения, связанные с каждым из этих внешних ключей.
3. Представить каждую характеристику как базовую таблицу с внешним ключом, идентифицирующим сущность, описываемую этой характеристикой. Специфицировать ограничения на внешний ключ этой таблицы и ее первичный ключ – по всей вероятности, комбинации этого внешнего ключа и свойства, которое гарантирует "уникальность в рамках описываемой сущности".
4. Представить каждое обозначение, которое не рассматривалось в предыдущем пункте, как базовую таблицу с внешним ключом, идентифицирующим обозначаемую сущность. Специфицировать связанные с каждым таким внешним ключом ограничения.
5. Представить каждое свойство как поле в базовой таблице, представляющей сущность, которая непосредственно описывается этим свойством.
6. Для того чтобы исключить в проекте непреднамеренные нарушения каких-либо принципов нормализации, выполнить описанную в п. 4.6 процедуру нормализации.
7. Если в процессе нормализации было произведено разделение каких-либо таблиц, то следует модифицировать инфологическую модель базы данных и повторить перечисленные шаги.
8. Указать ограничения целостности проектируемой базы данных и дать (если это необходимо) краткое описание полученных таблиц и их полей.
На рис. 4.6 показан синтаксис предложения, предлагаемого для регистрации принимаемых проектных решений.
Рис. 4.6. Синтаксис описания проектных решений
Для примера приведем описания таблиц "Блюда" и "Состав":
СОЗДАТЬ ТАБЛИЦУ Блюда *( Стержневая сущность ) ПЕРВИЧНЫЙ КЛЮЧ ( БЛ ) ПОЛЯ ( БЛ Целое, Блюдо Текст 60, Вид Текст 7 ) ОГРАНИЧЕНИЯ ( 1. Значения поля Блюдо должны быть уникальными; при нарушении вывод сообщения "Такое блюдо уже есть". 2. Значения поля Вид должны принадлежать набору: Закуска, Суп, Горячее, Десерт, Напиток; при нарушении вывод сообщения "Можно лишь Закуска, Суп, Горячее, Десерт, Напиток"); СОЗДАТЬ ТАБЛИЦУ Состав *( Связывает Блюда и Продукты ) ПЕРВИЧНЫЙ КЛЮЧ ( БЛ, ПР ) ВНЕШНИЙ КЛЮЧ ( БЛ ИЗ Блюда NULL-значения НЕ ДОПУСТИМЫ УДАЛЕНИЕ ИЗ Блюда КАСКАДИРУЕТСЯ ОБНОВЛЕНИЕ Блюда.БЛ КАСКАДИРУЕТСЯ) ВНЕШНИЙ КЛЮЧ ( ПР ИЗ Продукты NULL-значения НЕ ДОПУСТИМЫ УДАЛЕНИЕ ИЗ Продукты ОГРАНИЧИВАЕТСЯ ОБНОВЛЕНИЕ Продукты.ПР КАСКАДИРУЕТСЯ) ПОЛЯ ( БЛ Целое, ПР Целое, Вес Целое ) ОГРАНИЧЕНИЯ ( 1. Значения полей БЛ и ПР должны принадлежать набору значений из соответствующих полей таблиц Блюда и Продукты; при нарушении вывод сообщения "Такого блюда нет" или "Такого продукта нет". 2. Значение поля Вес должно лежать в пределах от 0.1 до 500 г. );
Рассмотренный язык описания данных, основанный на языке SQL [5], позволяет дать удобное и полное описание любой сущности и, следовательно, всей базы данных. Однако такое описание, как и любое подробное описание, не отличается наглядностью. Для достижения большей иллюстративности целесообразно дополнять проект инфологической моделью, но менее громоздкой, чем рассмотренная в главе 2.
Для наиболее распространенных реляционных баз данных можно предложить язык инфологического моделирования "Таблица-связь", пример использования которого приведен на рис. 4.7. В нем все сущности изображаются одностолбцовыми таблицами с заголовками, состоящими из имени и типа сущности. Строки таблицы – это перечень атрибутов сущности, а те из них, которые составляют первичный ключ, распологаются рядом и обводятся рамкой. Связи между сущностями указываются стрелками, направленными от первичных ключей или их составляющих.
Рис. 4.7. Инфологическая модель базы данных "Питание", построенная с помощью языка "Таблицы-связи"
[Назад] [Содержание] [Вперед]
Реляционная структура данных
В конце 60-х годов появились работы, в которых обсуждались возможности применения различных табличных даталогических моделей данных, т.е. возможности использования привычных и естественных способов представления данных. Наиболее значительной из них была статья сотрудника фирмы IBM д-ра Э.Кодда (Codd E.F., A Relational Model of Data for Large Shared Data Banks. CACM 13: 6, June 1970), где, вероятно, впервые был применен термин "реляционная модель данных".
Будучи математиком по образованию Э.Кодд предложил использовать для обработки данных аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Он показал, что любое представление данных сводится к совокупности двумерных таблиц особого вида, известного в математике как отношение – relation (англ.) [3, 7, 9].
Наименьшая единица данных реляционной модели – это отдельное атомарное (неразложимое) для данной модели значение данных. Так, в одной предметной области фамилия, имя и отчество могут рассматриваться как единое значение, а в другой – как три различных значения.
Доменом называется множество атомарных значений одного и того же типа. Так, на рис. 1.1 домен пунктов отправления (назначения) – множество названий населенных пунктов, а домен номеров рейса – множество целых положительных чисел.
Смысл доменов состоит в следующем. Если значения двух атрибутов берутся из одного и того же домена, то, вероятно, имеют смысл сравнения, использующие эти два атрибута (например, для организации транзитного рейса можно дать запрос "Выдать рейсы, в которых время вылета из Москвы в Сочи больше времени прибытия из Архангельска в Москву"). Если же значения двух атрибутов берутся из различных доменов, то их сравнение, вероятно, лишено смысла: стоит ли сравнивать номер рейса со стоимостью билета?
Отношение на доменах D1, D2, ..., Dn (не обязательно, чтобы все они были различны) состоит из заголовка и тела. На рис. 3.1 приведен пример отношения для расписания движения самолетов (рис. 1.1).
Заголовок (на рис. 1.1 он назывался интерпретацией) состоит из такого фиксированного множества атрибутов A1, A2, ..., An, что существует взаимно однозначное соответствие между этими атрибутами Ai и определяющими их доменами Di (i=1,2,...,n).
Рис. 3.1. Отношение с математической точки зрения (Ai - атрибуты, Vi - значения атрибутов)
Тело состоит из меняющегося во времени множества кортежей, где каждый кортеж состоит в свою очередь из множества пар атрибут-значение (Ai:Vi), (i=1,2,...,n), по одной такой паре для каждого атрибута Ai в заголовке. Для любой заданной пары атрибут-значение (Ai:Vi) Vi является значением из единственного домена Di, который связан с атрибутом Ai.
Степень отношения – это число его атрибутов. Отношение степени один называют унарным, степени два – бинарным, степени три – тернарным, ..., а степени n – n-арным. Степень отношения "Рейс" (рис. 1.1) – 8.
Кардинальное число или мощность отношения – это число его кортежей. Мощность отношения "Рейс" равна 10. Кардинальное число отношения изменяется во времени в отличие от его степени.
Поскольку отношение – это множество, а множества по определению не содержат совпадающих элементов, то никакие два кортежа отношения не могут быть дубликатами друг друга в любой произвольно-заданный момент времени. Пусть R – отношение с атрибутами A1, A2, ..., An. Говорят, что множество атрибутов K=(Ai, Aj, ..., Ak) отношения R является возможным ключом R тогда и только тогда, когда удовлетворяются два независимых от времени условия:
Уникальность: в произвольный заданный момент времени никакие два различных кортежа R не имеют одного и того же значения для Ai, Aj, ..., Ak. Минимальность: ни один из атрибутов Ai, Aj, ..., Ak не может быть исключен из K без нарушения уникальности.
Каждое отношение обладает хотя бы одним возможным ключом, поскольку по меньшей мере комбинация всех его атрибутов удовлетворяет условию уникальности. Один из возможных ключей (выбранный произвольным образом) принимается за его первичный ключ. Остальные возможные ключи, если они есть, называются альтернативными ключами.
Вышеупомянутые и некоторые другие математические понятия явились теоретической базой для создания реляционных СУБД, разработки соответствующих языковых средств и программных систем, обеспечивающих их высокую производительность, и создания основ теории проектирования баз данных. Однако для массового пользователя реляционных СУБД можно с успехом использовать неформальные эквиваленты этих понятий:
Отношение – Таблица (иногда Файл),
Кортеж – Строка (иногда Запись),
Атрибут – Столбец, Поле.
При этом принимается, что "запись" означает "экземпляр записи", а "поле" означает "имя и тип поля".
[Назад] [Содержание] [Вперед]
