Кириллов В.В., Громов Г.Ю. - Введение в реляционные базы данных. Литература для вузов isbn 9785941577705 в книге рассматриваются основные понятия баз данных и систем управления ими
 Скачать 11.62 Mb.
|
|
Глава 1. Зачем нужны базы данных Глава 2. Инфологическая модель данных "сущность - связь" Глава 3. Реляционный подход Глава 1 Зачем нужны базы данных 1.1. Данные и ЭВМ Восприятие реального мира можно соотнести с последовательностью разных, хотя иногда и взаимосвязанных, явлений. С давних времен люди пытались описать эти явления (даже тогда, когда не могли их понять). Такое описание называют данными. Традиционно фиксация данных осуществляется с помощью конкретного средства общения (например, с помощью естественного языка или изображе- ний) на конкретном носителе (например, камне или бумаге). Обычно данные (факты, явления, события, идеи или предметы) и их интерпретация (семанти- ка) фиксируются совместно, так как естественный язык достаточно гибок для представления того и другого. Примером может служить утверждение "Стоимость авиабилета 115". Здесь "115" — данное, а "Стоимость авиабиле- та" — его семантика. Нередко данные и интерпретация разделены. Например, "Расписание движе- ния самолетов" может быть представлено в виде таблицы (рис. 1.1), в верх- ней части которой (отдельно от данных) приводится их интерпретация. Такое разделение затрудняет работу с данными (попробуйте быстро получить све- дения из нижней части таблицы, если в ней будет намного больше строк). Применение ЭВМ для ведения и обработки данных обычно приводит к еще большему разделению данных и интерпретации. ЭВМ имеет дело главным обра- зом с данными как таковыми. Большая часть интерпретирующей информации вообще не фиксируется в явной форме (ЭВМ не "знает", является ли "21.50" стоимостью авиабилета или временем вылета). Почему же это произошло? Ведение (сопровождение, поддержка) данных — термин, объединяющий действия по добавлению, удалению или изменению хранимых данных. Часть I. Что такое база данных и СУБД 8 Рис. 1.1. К разделению данных и их интерпретации Существует, по крайней мере, две исторические причины, по которым при- менение ЭВМ привело к отделению данных от интерпретации. Во-первых, ЭВМ не обладали достаточными возможностями для обработки текстов на естественном языке — основном языке интерпретации данных. Во-вторых, стоимость памяти ЭВМ была первоначально весьма велика. Память исполь- зовалась для хранения самих данных, а интерпретация традиционно возла- галась на пользователя. Пользователь закладывал интерпретацию данных в свою программу, которая "знала", например, что шестое вводимое значение связано со временем прибытия самолета, а четвертое — со временем его вы- лета. Это существенно повышало роль программы, так как вне интерпрета- ции данные представляют собой не более чем совокупность битов на запо- минающем устройстве. Жесткая зависимость между данными и использующими их программами создает серьезные проблемы в ведении данных и делает их использование менее гибким. Нередки случаи, когда пользователи одной и той же ЭВМ создают и исполь- зуют в своих программах разные наборы данных, содержащие сходную ин- формацию. Иногда это связано с тем, что пользователь не знает (либо не за- хотел узнать), что в соседней комнате или за соседним столом сидит сотрудник, который уже давно ввел в ЭВМ нужные данные. Чаще же потому, Глава 1. Зачем нужны базы данных 9 что при совместном использовании одних и тех же данных возникает масса проблем. Разработчики прикладных программ (написанных, например, на Бейсике, Паскале или Си) размещают нужные им данные в файлах, организуя их наи- более удобным для себя образом. При этом одни и те же данные могут иметь в разных приложениях совершенно разную организацию (разную последова- тельность размещения в записи, разные форматы одних и тех же полей и т. п.). Обобществить такие данные чрезвычайно трудно: например, любое изменение структуры записи файла, производимое одним из разработчиков, приводит к необходимости изменения другими разработчиками тех про- грамм, которые используют записи этого файла. Для иллюстрации обратимся к примеру, приведенному в книге У. Девиса "Операционные системы" (М., Мир, 1980): "Несколько лет назад почтовое ведомство (из лучших побуждений) пришло к решению, что все адреса должны обязательно включать почтовый индекс. Во многих вычислительных центрах это, казалось бы, незначительное из- менение привело к ужасным последствиям. Добавление к адресу нового поля, содержащего шесть символов, означало необходимость внесения изменений в каждую программу, использующую данные этой задачи в соот- ветствии с изменившейся суммарной длиной полей. Тот факт, что какой - то программе для выполнения ее функций не требуется знания почтового ин- декса, во внимание не принимался: если в некоторой программе содержа- лось обращение к новой, более длинной записи, то в такую программу вно- сились изменения, обеспечивающие дополнительное место в памяти. В условиях автоматизированного управления централизованной базой данных все такие изменения связаны с функциями управляющей програм- мы базы данных. Программы, не использующие значения почтового индек- са, не нуждаются в модификации — в них, как и прежде, в соответствии с запросами посылаются те же элементы данных. В таких случаях внесенное изменение неощутимо. Модифицировать необходимо только те программы, которые пользуются новым элементом данных". 1.2. Концепция баз данных Активная деятельность по отысканию приемлемых способов обобществления непрерывно растущего объема информации привела к созданию в начале 60-х годов ХХ в. специальных программных комплексов, называемых сис- темами управления базами данных (СУБД). Часть I. Что такое база данных и СУБД 10 Основная особенность СУБД — это наличие процедур для ввода и хранения не только самих данных, но и описаний их структуры. Файлы, снабженные описанием хранимых в них данных и находящиеся под управлением СУБД, стали называть банки данных, а затем базы данных (БД). Пусть, например, требуется сохранить расписание движения самолетов (см. рис. 1.1) и ряд других данных, связанных с организацией работы аэропорта (БД "Аэропорт"). Используя для этого одну из "русифицированных" реляци- онных СУБД, можно подготовить следующее описание расписания: СОЗДАТЬ ТАБЛИЦУ Расписание (Номер_рейса Целое Дни_недели Текст (8) Пункт_отправления Текст (24) Время_вылета Время Пункт_назначения Текст (24) Время_прибытия Время Тип_самолета Текст (8) Стоимость_билета Валюта); и ввести его вместе с данными в БД "Аэропорт". Язык запросов СУБД позволяет обращаться за данными как из программ, так и с терминалов (рис. 1.2). Сформировав запрос: ВЫБРАТЬ Номер_рейса, Дни_недели, Время_вылета ИЗ ТАБЛИЦЫ Расписание ГДЕ Пункт_отправления = 'Москва' И Пункт_назначения = 'Киев' И Время_вылета > 17; получим расписание "Москва—Киев" на вечернее время, а по запросу: ВЫБРАТЬ КОЛИЧЕСТВО(Номер_рейса) ИЗ ТАБЛИЦЫ Расписание ГДЕ Пункт_отправления = 'Москва' И Пункт_назначения = 'Минск'; получим количество рейсов "Москва—Минск". Эти запросы не потеряют актуальности и при расширении таблицы: ДОБАВИТЬ В ТАБЛИЦУ Расписание Длительность_полета Целое; как это было с программами обработки почтовых адресов при введении поч- тового индекса. Глава 1. Зачем нужны базы данных 11 При выполнении запроса на чтение данных, выданного прикладной программой или непосредственно с терминала (другого компьютера), СУБД выполняет ряд действий, включающих: 1. Интерпретацию запроса. 2. Поиск всех описаний данных, на которые выдан запрос. 3. Формирование команд, по которым операционная система пересылает из запоминающих устройств в буферы СУБД содержимое всех физических записей с требуемыми данными. 4. Выделение из этих записей нужных данных, их форматирование (если это необходимо), создание заданного вида и последовательности вывода, а также пересылку этих данных на терминал или в рабочую область прикладной программы. Аналогичные действия выполняются при обновлении или вводе данных. Основная программа СУБД Программа 1-го поль- зователя СУБД Программа 2-го поль- зователя СУБД Программа N-го поль- зователя СУБД Операцион- ная система и другие служебные программы . . . Другие модули СУБД ДАННЫЕ Описание хранимых данных БАЗА ДАННЫХ . . . Рис. 1.2. Связь программ и данных при использовании СУБД Однако за все надо расплачиваться: на обмен данными через СУБД требуется большее время, чем на обмен аналогичными данными прямо из файлов, спе- циально созданных для того или иного приложения. Часть I. Что такое база данных и СУБД 12 1.3. Архитектура СУБД СУБД должна предоставлять доступ к данным любым пользователям, вклю- чая и тех, кто практически не имеет и (или) не хочет иметь представления о: физическом размещении в памяти компьютера данных и их описаний; механизмах поиска запрашиваемых данных; проблемах, возникающих при одновременном запросе одних и тех же данных многими пользователями (прикладными программами); способах обеспечения защиты данных от некорректных обновлений и (или) несанкционированного доступа; поддержании баз данных в актуальном состоянии и множестве других функций современных СУБД. При выполнении основных из этих функций СУБД должна использовать раз- личные описания данных. А что это за описания? В 1975 году подкомитет SPARC (Standards Planning and Requirements Com- mittee) американского национального института стандартов (American National Standards Institute, ANSI) выдвинул проект трехуровневой архитек- туры СУБД (рис. 1.3): 1. Внешний (пользовательский). 2. Промежуточный (концептуальный). 3. Внутренний (физический). В основе архитектуры ANSI/SPARC лежит концептуальный уровень. Этот уровень описывает данные и их взаимосвязи с наиболее общей точки зре- ния — концепции архитекторов (разработчиков) базы данных. Внутренний уровень позволяет скрыть подробности физического хранения данных (носители, файлы ...) от концептуального уровня. Отделение внут- реннего уровня от концептуального уровня обеспечивает, так называемую, физическую независимость данных. На внешнем уровне описываются различные подмножества элементов кон- цептуального уровня для представления данных различными пользователями и (или) их программами. Каждый пользователь получает в свое распоряже- ние часть представлений о данных, но полная концепция скрыта. Отделение внешнего уровня от концептуального уровня обеспечивает логическую неза- висимость данных. Глава 1. Зачем нужны базы данных 13 Предметная область часть реального мира, данные о которой необходимо разместить в базе данных (например, кулинария, библиотека, учебный процесс в университете, магазин, гостиница, банк, предприятие, корпорация и т.п.) - Внешний (пользовательский) уровень Индивидуальные представления предметной области отдельными пользователями базы данных, выполненные с помощью текста, графики и других, понятных всем средств Концептуальный (инфологический) уровень Обобщенное представление всех пользователей и приложений базы данных, как правило, выполненное с использованием ER-модели "сущность-связь" (Entity-Relationship) Внутренний уровень Описание желаемого способа организации базы данных в среде хранения выбранной СУБД - описание физической реализации, позволяющей добиться оптимальной производительности СУБД и обеспечения экономного использования запоминающих устройств Среда хранения данных и их описаний Рис. 1.3. Уровни моделей данных В дальнейшем эта архитектура была включена в стандарты международной организации по стандартизации (International Organization for Standardization, ISO), членом которой с момента ее основания является Россия. Естественно, что проект базы данных надо начинать с выбора предметной области (той части реального мира, данные о которой надо отразить в базе Часть I. Что такое база данных и СУБД 14 данных) и выявления требований к ней отдельных пользователей (сотрудни- ков организации, для которых создается база данных). Подробнее этот про- цесс будет рассмотрен далее, а здесь отметим, что проектирование обычно поручается человеку (группе лиц) — администратору данных (АД). Объеди- няя частные представления о содержимом базы данных, полученные в ре- зультате опроса пользователей и (или) анализа их технических заданий, и свои представления о данных, которые могут потребоваться в будущих приложениях, АД сначала создает обобщенное неформальное описание соз- даваемой базы данных. Это описание, выполненное с использованием текста (на естественном языке), образцов входных и выходных документов, матема- тических формул, таблиц, графики и других средств, понятных потенциаль- ным пользователям и всем людям, работающим над проектированием базы данных, и есть концептуальная модель данных, которую часто называют ло- гической или информационно-логической (инфологической) моделью. Такая человеко-ориентированная модель полностью независима от физиче- ских параметров среды хранения данных и от той СУБД, которая будет ис- пользоваться для построения и ведения базы данных. В конце концов, этой средой может быть память человека, а не ЭВМ. Поэтому концептуальная мо- дель не должна изменяться до тех пор, пока какие-то изменения в реальном мире не потребуют изменения в ней некоторых определений, чтобы эта мо- дель продолжала отражать предметную область. Если АД — это человек, отвечающий за стратегию и политику принятия ре- шений, связанных с данными базы данных, то человек, обеспечивающий не- обходимую техническую поддержку для реализации принятых решений, на- зывается администратором базы данных (АБД). АБД выбирает конкретную СУБД и решает, как данные будут представлены в хранимой базе данных, т. е. осуществляет физическое проектирование базы данных — преобразование концептуальной модели в физическую модель. Трехуровневая архитектура позволяет обеспечить независимость хранимых данных от использующих их программ. АБД может при необходимости пе- реписать хранимые данные на другие носители информации и (или) реорга- низовать их физическую структуру, изменив лишь физическую модель дан- ных. АД может подключить к системе любое число новых пользователей (новых приложений), дополнив, если надо, концептуальную модель. Указан- ные изменения физической и концептуальной моделей не будут замечены существующими пользователями системы (окажутся "прозрачными" для них), так же как не будут замечены и новые пользователи. Следовательно, незави- симость данных обеспечивает возможность развития системы баз данных без разрушения существующих приложений. Глава 2 Инфологическая модель данных "сущность - связь" 2.1. Основные понятия Цель инфологического моделирования — обеспечение наиболее естествен- ных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Поэтому инфологиче- скую модель данных пытаются строить по аналогии с естественным языком (последний не может быть использован в чистом виде из-за сложности ком- пьютерной обработки текстов и неоднозначности любого естественного язы- ка). Основными конструктивными элементами инфологических моделей яв- ляются сущности, связи между ними и их свойства (атрибуты). Сущность — любой различимый объект, факт, явление, событие, идея или предмет, информацию о котором необходимо хранить в базе данных. Сущно- стями могут быть люди, места, самолеты, рейсы, вкус, цвет, женитьба, гроза, изобретение, боль и т. п. Необходимо различать такие понятия, как тип сущ- ности и экземпляр сущности. Понятие тип сущности относится к набору од- нородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, ти- пом сущности может быть ГОРОД , а экземпляром — Москва , Киев и т. д. Атрибут — поименованная характеристика (свойство) сущности. Это любая деталь, которая служит для уточнения, идентификации, классификации, чи- словой характеристики или выражения состояния сущности. Наименование атрибута должно быть уникальным для конкретного типа сущности, но мо- жет быть одинаковым для различного типа сущностей, например, ЦВЕТ может быть определен для многих сущностей: СОБАКА , АВТОМОБИЛЬ , ДЫМ и т. д. Атри- буты используются для определения того, какая информация должна быть собрана о сущности. Примерами атрибутов для сущности АВТОМОБИЛЬ явля- ются ТИП , МАРКА , НОМЕРНОЙ ЗНАК , ЦВЕТ и т. д. Здесь также существует различие Часть I. Что такое база данных и СУБД 16 между типом и экземпляром. Тип атрибута ЦВЕТ имеет много экземпляров или значений ( Красный , Синий , Банановый , Белая ночь и т. д.), однако каждо- му экземпляру сущности присваивается только одно значение атрибута. Абсолютное различие между типами сущностей и атрибутами отсутствует. Атрибут является таковым только в связи с типом сущности. В другом кон- тексте атрибут может выступать как самостоятельная сущность. Например, в расписании движения самолетов (см. рис. 1.1) город — это атрибут распи- сания, а в кодификаторе адресов город — тип сущности. Ключ — минимальный набор атрибутов, по значениям которых можно одно- значно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся. Для сущности Расписание (см. разд. 1.2) ключом является атрибут Номер_рейса или набор: Пункт_отправления , Время_вылета и Пункт_назначения (при условии, что из пункта в пункт вылетает в каждый момент времени один самолет). Связь — ассоциирование двух или более сущностей. Абсолютное различие между типами сущностей и связями отсутствует. Один и тот же факт может совершенно обоснованно рассматриваться или как сущность, или как связь. Например, в запросе — "с кем вступила в брак Алла Пугачева" брак — связь, а в запросе — "сколько браков было зарегистрировано в этом ЗАГСе в про- шлом году" брак — сущность. Если бы назначением базы данных было только хранение отдельных, не свя- занных между собой данных, то ее структура могла бы быть очень простой. Однако одно из основных требований к организации базы данных — это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определенные связи. А так как в реальных базах данных нередко содержатся сотни или даже тысячи сущно- стей, то теоретически между ними может быть установлено более миллиона связей. Наличие такого множества связей и определяет сложность инфологи- ческих моделей. 2.2. Характеристика связей и язык моделирования При построении инфологических моделей можно использовать язык ER- диаграмм — от англ. Entity-Relationship, т. е. сущность-связь. Этот язык был предложен в 1976 году сотрудником корпорации IBM Питером Ченом [7]. Глава 2. Инфологическая модель данных "сущность - связь" 17 В нем предлагалось изображать сущности помеченными прямоугольника- ми, связи — помеченными ромбами, атрибуты — помеченными овалами. Над линиями, соединяющими прямоугольники, может проставляться сте- пень связи (1 или буква М, заменяющая слово "много") и необходимое по- яснение (рис. 2.1). Связь Сущность 1 1 или М 1 или М Атрибут 1 . . . Атрибут N Сущность 2 Атрибут 1 . . . Атрибут N Рис. 2.1. Элементы ER- диаграмм языка, предложенного Ченом Так, между двумя сущностями, например, А и Б возможны четыре вида связей. Первый тип — связь "один-к-одному" (1:1): в каждый момент времени каж- дому представителю (экземпляру) сущности А соответствует 1 или 0 пред- ставителей сущности Б. Например, студент может не "заработать" стипен- дию, получить обычную или одну из повышенных стипендий (рис. 2.2, а). АБ А Б 1 1 Назна- чение Студент Вид сти- пендии 1 1 АБ А Б 1 М Прожи- вание Квартира Жилец 1 М а) б) Рис. 2.2. Примеры простейших ER- моделей Второй тип — связь "один-ко-многим" (1:М): одному представителю сущно- сти А соответствуют 0, 1 или несколько представителей сущности Б. Напри- Часть I. Что такое база данных и СУБД 18 мер, квартира может пустовать, в ней может жить один или несколько жиль- цов (рис. 2.2, б). Так как между двумя сущностями возможны связи в обоих направлениях, то существует еще два типа связи "многие-к-одному" (М:1) и "многие-ко- многим" (М:М). Пример 2.1. Если связь между сущностями МУЖЧИНЫ и ЖЕНЩИНЫ называется БРАК , то существует четыре возможных представления такой связи (рис. 2.3). Брак Мужчина Женщина 1 1 Традиционный брак Брак Мужчина Женщина 1 М Многоженство Брак Мужчина Женщина 1 М Брак Мужчина Женщина М 1 Многомужие Брак Мужчина Женщина М М Групповой брак Рис. 2.3. Возможные связи между двумя сущностями Характер связей между сущностями не ограничивается перечисленными. Существуют и более сложные связи: множество связей между одними и теми же сущностями (рис. 2.4, а): па- циент, имея одного лечащего врача, может иметь также несколько врачей- консультантов; врач может быть лечащим врачом нескольких пациентов и может одновременно консультировать несколько других пациентов; тренарные связи (рис. 2.4, б): врач может назначить несколько пациентов на несколько анализов, анализ может быть назначен несколькими врачами нескольким пациентам и пациент может быть назначен на несколько ана- лизов несколькими врачами; связи более высоких порядков, семантика (смысл) которых иногда очень сложна. Глава 2. Инфологическая модель данных "сущность - связь" 19 Консуль- тант Врач Пациент М М Лечащий врач М 1 Назначенный анализ Врач Анализ М М М Пациент а) б) Рис. 2.4. Примеры сложных связей между сущностями В приведенных примерах для повышения иллюстративности рассматривае- мых связей не показаны атрибуты сущностей ER-диаграмм. Так, ввод атри- бутов в описание брачных связей: фамилии, имена и отчества мужа и жены; даты и места рождения мужа и жены; даты и места регистрации брака; фамилий, присвоенных мужу и жене после регистрации; даты выдачи и номера свидетельства о браке значительно усложнит ER-диаграмму и затруднит ее понимание. Поэтому к настоящему времени появилось множество более удобных графи- ческих нотаций описания ER-диаграмм, поддержанных CASE-средствами (от Computer Aided Software/System Engineering) разработки информационных систем и редакторами деловой графики. В данной книге мы будем пользо- ваться нотациями системы построения диаграмм Microsoft Visio. В этих нотациях сущность изображается в виде прямоугольника, в верхней части которого располагается имя сущности (рис. 2.5, а). В прямоугольнике перечислены атрибуты сущности. Атрибуты, расположенные сверху и отде- ленные от остальных горизонтальной линией, являются ключевыми. Часть I. Что такое база данных и СУБД 20 РАСПИСАНИЕ НОМЕР_РЕЙСА ДНИ_НЕДЕЛИ ПУНКТ_ОТПРАВЛЕНИЯ ВРЕМЯ_ВЫЛЕТА ПУНКТ_НАЗНАЧЕНИЯ ВРЕМЯ_ПРИБЫТИЯ ТИП_САМОЛЕТА СТОИМОСТЬ_БИЛЕТА Один или ноль Только один Много или ноль Много или один а) б) РАСПИСАНИЕ НОМЕР_РЕЙСА ДНИ_НЕДЕЛИ ПУНКТ_ОТПРАВЛЕНИЯ ВРЕМЯ_ВЫЛЕТА ПУНКТ_НАЗНАЧЕНИЯ ВРЕМЯ_ПРИБЫТИЯ ТИП_САМОЛЕТА СТОИМОСТЬ_БИЛЕТА АЭРОПОРТЫ КОД_АЭРОПОРТА ИМЯ_АЭРОПОРТА МЕСТОРАСПОЛОЖЕНИЕ в) Рис. 2.5. Сущность (а), виды связей (б) и пример ER- диаграммы (в ) а) СВИДЕТЕЛЬСТВО_О_БРАКЕ КОД_МУЖЧИНЫ КОД_ЖЕНЩИНЫ ДАТА_РЕГИСТРАЦИИ МЕСТО_РЕГИСТРАЦИИ НОМЕР_СВИДЕТЕЛЬСТВА ДАТА_СВИДЕТЕЛЬСТВА ФАМИЛИЯ_МУЖА ФАМИЛИЯ_ЖЕНЫ МУЖЧИНА КОД_МУЖЧИНЫ ФАМИЛИЯ ИМЯ ОТЧЕСТВО ДАТА_РОЖДЕНИЯ МЕСТО_РОЖДЕНИЯ ЖЕНЩИНА КОД_ЖЕНЩИНЫ ФАМИЛИЯ ИМЯ ОТЧЕСТВО ДАТА_РОЖДЕНИЯ МЕСТО_РОЖДЕНИЯ б) Н_ОТДЕЛЫ ИД КОРОТКОЕ_ИМЯ ИМЯ_В_ИМИН_ПАДЕЖЕ ИМЯ_В_РОД_ПАДЕЖЕ ИМЯ_В_ДАТ_ПАДЕЖЕ ИМЯ_В_ВИН_ПАДЕЖЕ ИМЯ_В_ТВОР_ПАДЕЖЕ ИМЯ_В_ПРЕД_ПАДЕЖЕ ОТД_ИД ДАТА_СОЗДАНИЯ ДАТА_ЛИКВИДАЦИИ КТО_СОЗДАЛ КОГДА_СОЗДАЛ КТО_ИЗМЕНИЛ КОГДА_ИЗМЕНИЛ Рис. 2.6. Примеры связей в ER- диаграммах Глава 2. Инфологическая модель данных "сущность - связь" 21 Связь изображается пунктирной линией между двумя сущностями (рис. 2.5, б). На концах линий проставляются условные графические обозначения: верти- кальная черта (один), кружок (ноль или "необязательно"), "воронья лапа" (много). Если в ключ какой-либо сущности входит ключ другой сущности, то связь между такими сущностями изображается не пунктирной, а сплошной линией (рис. 2.6, а). Достаточно часто встречается еще один специфический вид связи: рекурсив- ная связь между атрибутами одной сущности "Один-ко-многим" ("Сви- ное ухо"), используемая для описания иерархий с любым числом уровней. На рис. 2.6, б приведено изображение такой связи для сущности ОТДЕЛЫ (см. разд. 20.3). Иллюстрацию такой связи легко проследить по табл. 2.1, где представлены некоторые столбцы и строки таблицы Н_ОТДЕЛЫ Таблица 2.1. Идентификаторы, подчиненность и названия ряда отделов СПбГУ ИТМО ИД ОТД_ИД ИМЯ_В_ИМИН_ПАДЕЖЕ 101 703 кафедра систем управления и информатики 102 703 кафедра вычислительной техники 103 705 кафедра измерительных технологии и компьютерной томо- графии 105 705 кафедра мехатроники 106 704 кафедра теоретической и прикладной механики 107 705 кафедра инженерной и компьютерной графики 108 703 кафедра проектирования компьютерных систем 109 703 кафедра информационно - навигационных систем 110 706 кафедра иностранных языков 111 703 кафедра информатики и прикладной математики … 701 777 факультет оптико - информационных систем и технологий 702 777 факультет инженерно - физический 703 777 факультет компьютерных технологий и управления Часть I. Что такое база данных и СУБД 22 Таблица 2.1 ( окончание) ИД ОТД_ИД ИМЯ_В_ИМИН_ПАДЕЖЕ 704 777 факультет естественнонаучный 705 777 факультет точной механики и технологий 706 777 факультет гуманитарный 707 777 факультет послевузовского профессионального обучения … 777 Санкт - Петербургский государственный университет инфор- мационных технологий, механики и оптики В строке табл. 2.1 кроме идентификатора ( ИД ) и имени ( ИМЯ_В_ИМИН_ПАДЕЖЕ ) отдела хранится идентификатор "начальника" ( ОТД_ИД ), т. е. того подразделе- ния, в состав которого он входит. Так кафедра вычислительной техники ( ИД=102 ) входит в состав факультета компьютерных технологий и управления ( ИД=703 ), который, в свою очередь, входит в состав университета ( ИД=777 ). В данном случае рассмотрен пример с тремя уровнями иерархии, но ясно, что при использовании этого описания количество этих уровней ограничивается только предметной областью (здесь можно было бы представить, например, любые секции кафедры, подсекции и т. п.). Об организации иерархических запросов рассказано в разд. 5.6. 2.3. Классификация сущностей Настал момент разобраться в терминологии. Основоположник реляционной модели баз данных Эдгар Кодд [8] определяет три основных класса сущно- стей: стержневые, ассоциативные и характеристические. Стержневая сущность (стержень) — это независимая сущность, которая не является ни характеристикой, ни ассоциацией (см. далее). В рассмотренных ранее примерах стержни — это Студент , Квартира , Мужчи- ны , Врач и другие, названия которых помещены в прямоугольники. Ассоциативная сущность (ассоциация) — это связь вида "многие-ко- многим" ("*-ко-многим" и т. д.) между двумя или более сущностями или эк- Глава 2. Инфологическая модель данных "сущность - связь" 23 земплярами сущности. Ассоциации рассматриваются как полноправные сущности: они могут участвовать в других ассоциациях точно так же, как стержне- вые сущности; могут обладать свойствами, т. е. иметь не только набор ключевых атрибу- тов, необходимых для указания связей, но и любое число других атрибутов, характеризующих связь. Например, ассоциация СВИДЕТЕЛЬСТВО_О_БРАКЕ (см. рис. 2.6) содержит ключевые атрибуты КОД_МУЖЧИНЫ и КОД_ЖЕНЩИНЫ , а также уточняющие атрибуты ДАТА_РЕГИСТРАЦИИ , МЕСТО_РЕГИСТРАЦИИ , НОМЕР_СВИДЕТЕЛЬСТВА и т. д. Характеристическая сущность (характеристика) — это связь вида "мно- гие-к-одной" или "одна-к-одной" между двумя сущностями (частный случай ассоциации). Единственная цель характеристики в рамках рассматриваемой предметной области состоит в описании или уточнении некоторой другой сущности. Необходимость в них возникает в связи с тем, что сущности ре- ального мира имеют иногда многозначные свойства. Муж может иметь несколько жен; книга — несколько характеристик переиздания (исправлен- ное, дополненное, переработанное и пр.) и т. д. Существование характери- стики полностью зависит от характеризуемой сущности: женщины лишаются статуса жен, если умирает их муж. Пример 2.2. В заключение рассмотрим пример построения инфологической модели базы данных "COOK", предназначенной для использования в пансио- натах, санаториях и других организациях, предоставляющих услуги по обес- печению отдыха. Информация из такой базы данных будет использоваться шеф-поваром пан- сионата для составления меню, учитывающего примерную стоимость и необ- ходимую калорийности суточного рациона отдыхающих. В меню предлага- ется по несколько альтернативных блюд каждого вида (закуска, горячее, суп и т. п.) для каждой трапезы (завтрак, обед, ужин). Перед завтраком каждый отдыхающий выбирает в информационной систе- ме номер закрепленного за ним места в столовой пансионата и желаемый набор блюд для каждой из трапез следующего дня (желаемый набор строк меню). Это позволяет определить, сколько порций того или иного блюда надо приготовить для каждой трапезы, а также набор и количество необхо- димых продуктов. Завхоз, связанный с поставщиками продуктов, определяет, что необходимо заказать для обеспечения работы столовой. Часть I. Что такое база данных и СУБД 24 При составлении меню шеф-повар использует кулинарную книгу, где разме- щена информация о рецептах (рис. 2.7) и таблицы с химическим составом и пищевой ценностью различных продуктов. 127 Лобио по грузински (закуска) Ломаную очищенную фасоль, нашинкованный лук посолить, посыпать перцем и припустить в масле с небольшим количеством бульона; добавить кинзу, зелень петрушки, реган (базилик) и довести до готовности. Затем запечь в духовке. Фасоль стручковая (свежая или консервированная) 200, Лук зеленый 40, Масло сливочное 30, Зелень 10. Выход 210. Калорий 725. Рис. 2.7. Пример кулинарного рецепта Исходя из потребностей указанных ранее лиц, можно определить объекты, необходимые для выявления сущностей и атрибутов проектируемой базы: 1. Блюда, для описания которых нужны данные, входящие в их кулинарные рецепты: код (номер) блюда (например, из книги кулинарных рецептов); название блюда; вид блюда (закуска, суп, горячее и т. п.); рецепт (технология приготовления блюда); выход (вес порции); калорийность блюда; название, вес и основные вещества (белки, жиры, углеводы, витамины и др.) каждого продукта, входящего в блюдо; приведенная стоимость приготовления одной порции блюда (трудоем- кость). 2. Для каждого поставщика продуктов: код (номер) поставщика продукта; название поставщика и его статус (рынок, ферма, универсам и т. п.); данные о поставщике (город, адрес, телефон); название поставляемого продукта; дата поставки и цена на момент поставки. Глава 2. Инфологическая модель данных "сущность - связь" 25 3. Ежедневное потребление блюд (расход): блюдо, количество порций, дата. 4. Меню на следующий день, где на каждую из трапез (завтрак, обед, ужин) для каждого из видов блюд приводится несколько различных блюд. 5. Выбор каждым из отдыхающих конкретных блюд из меню (для упроще- ния схемы опущены сведения об отдыхающих и, следовательно, привязка их к местам в столовой пансионата). Анализ объектов позволяет выделить: Стержни: ВИДЫ_БЛЮД , ТРАПЕЗЫ , ПРОДУКТЫ и ПОСТАВЩИКИ ; ПОСТАВЩИКИ КОД_ПОСТАВЩИКА НАЗВАНИЕ СТАТУС ГОРОД АДРЕС ТЕЛЕФОН ПРОДУКТЫ КОД_ПРОДУКТА ПРОДУКТ БЕЛКИ ЖИРЫ УГЛЕВ K CA NA B2 PP C БЛЮДА КОД_БЛЮДА БЛЮДО КОД_ВИДА ОСНОВА ВЫХОД ТРУД ВИДЫ_БЛЮД КОД_ВИДА ВИД ВЫБОР МЕСТО СТРОКА РЕЦЕПТЫ КОД _ БЛЮДА РЕЦЕПТ ВАРИАНТ МЕНЮ СТРОКА КОД_ТРАПЕЗЫ КОД_БЛЮДА ДАТА СОСТАВ КОД_БЛЮДА КОД_ПРОДУКТА ВЕС ПОСТАВКИ КОД_ПОСТАВЩИКА КОД_ПРОДУКТА ДАТА ЦЕНА К_ВО ТРАПЕЗЫ КОД_ТРАПЕЗЫ ТРАПЕЗА Рис. 2.8. Инфологическая модель базы данных "COOK" Часть I. Что такое база данных и СУБД 26 Ассоциации: СОСТАВ (связывает БЛЮДА с ПРОДУКТАМИ ), ПОСТАВКИ (связывает ПОСТАВЩИКОВ с ПРОДУКТАМИ ), МЕНЮ (связывает ТРАПЕЗЫ с БЛЮДАМИ ) и ВЫБОР (связывает МЕНЮ с МЕСТОМ в столовой) и, наконец, частный случай ассоциа- ции — БЛЮДА , зависящие от единственной стержневой сущности ВИДЫ_БЛЮД ; Характеристика: РЕЦЕПТЫ (характеризует БЛЮДА ). ER-диаграмма модели показана на рис. 2.8. 2.4. О первичных и внешних ключах Напомним, что ключ или возможный ключ — это минимальный набор атри- бутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атри- бута не позволяет идентифицировать сущность по оставшимся. Каждая сущ- ность должна обладать хотя бы одним возможным ключом. Если же возника- ет ситуация, когда из состава атрибутов сущности не удается создать возможного ключа (естественного ключа), то создают, так называемый, сур- рогатный ключ — автоматически сгенерированное значение, никак не свя- занное с информационным содержанием сущности. Один из возможных естественных ключей или суррогатный ключ принима- ется за первичный ключ. При выборе первичного ключа следует отдавать предпочтение несоставным ключам или ключам, составленным из ми- нимального числа атрибутов. Нецелесообразно также использовать ключи с длинными текстовыми значениями (предпочтительнее использовать цело- численные атрибуты). Так, для идентификации студента можно использовать либо уникальный номер зачетной книжки, либо набор из фамилии, имени, отчества, номера группы и может быть дополнительных атрибутов, так как не исключено появление в группе двух студентов (а чаще студенток) с оди- наковыми фамилиями, именами и отчествами. Плохо также использовать в качестве ключа не номер блюда, а его название, например, "Закуска из плавленых сырков "Дружба" с ветчиной и соленым огурцом" или "Заяц в сметане с картофельными крокетами и салатом из красной капусты". Не допускается, чтобы первичный ключ стержневой сущности (любой атри- бут, участвующий в первичном ключе) принимал неопределенное значение. Иначе возникнет противоречивая ситуация: появится не обладающий инди- видуальностью и, следовательно, не существующий экземпляр стержневой сущности. По тем же причинам необходимо обеспечить уникальность пер- вичного ключа. Глава 2. Инфологическая модель данных "сущность - связь" 27 Следует также обсудить ситуацию, когда по тем или иным причинам прихо- дится или целесообразнее использовать суррогатный ключ. Например, на рис. 2.8, в сущности РЕЦЕПТ в качестве возможных первичных ключей можно было бы использовать пары атрибутов: ( КОД_БЛЮДА , РЕЦЕПТ ) или ( КОД_БЛЮДА , ВАРИАНТ ), где вариант — номер технологии приготовления блюда, например, кофе черного или салата "Оливье". Однако значение первого из этих ключей: ( КОД_БЛЮДА , РЕЦЕПТ ) — чересчур громоздко, а второго: ( КОД_БЛЮДА , ВАРИАНТ ) — требует обязательного ввода номера варианта, даже в том случае, когда су- ществует всего один вариант рецепта. Поэтому введем в состав атрибутов сущности РЕЦЕПТ атрибут ИД (рис. 2.9), который будет автоматически генери- роваться СУБД во время ввода рецептов и использоваться в качестве сурро- гатного первичного ключа. БЛЮДА КОД_БЛЮДА БЛЮДО КОД_ВИДА ОСНОВА ВЫХОД ТРУД РЕЦЕПТЫ ИД КОД_БЛЮДА РЕЦЕПТ ВАРИАНТ Рис. 2.9. Ввод суррогатного ключа ИД в сущность РЕЦЕПТЫ Теперь о внешних ключах: Если сущность В связывает сущности А и Б, то она должна включать внешние ключи, соответствующие первичным ключам сущностей А и Б. Например, ассоциативная сущность СОСТАВ (см. рис. 2.8) включает внеш- ние ключи КОД_БЛЮДА и КОД_ПРОДУКТА , соответствующие первичным клю- чам связываемых стержневых сущностей БЛЮДА и ПРОДУКТЫ Если сущность Б характеризует сущность А, то она должна включать внешний ключ, соответствующий первичному ключу сущности А. Напри- мер, характеристическая сущность РЕЦЕПТ (см. рис. 2.8 или 2.9) включает внешний ключ КОД_БЛЮДА , соответствующий первичному ключу характе- ризуемой сущности БЛЮДА Таким образом, при рассмотрении выбора способа представления ассоциаций и характеристик в базе данных основной вопрос, на который следует полу- чить ответ: "Каковы внешние ключи?" И далее, для каждого внешнего ключа необходимо решить три вопроса. Часть I. Что такое база данных и СУБД 28 Первый вопрос — может ли данный внешний ключ принимать неопреде- ленные значения ( NULL -значения)? Иначе говоря, может ли существовать не- который экземпляр сущности данного типа, для которого неизвестна целевая сущность, указываемая внешним ключом? Ответ на данный вопрос не зависит от прихоти проектировщика базы дан- ных, а определяется фактическим образом действий, принятым в той части реального мира, которая должна быть представлена в рассматриваемой базе данных. Подобные замечания имеют отношение и к вопросам (пунктам), об- суждаемым далее. Так, в случае поставок это, вероятно, невозможно — поставка, осуществляе- мая неизвестным поставщиком, или поставка неизвестного продукта не име- ют смысла. Но вполне возможно существование блюда с неизвестным значе- нием его вида (суп, горячее и пр.). Второй вопрос — что должно случиться при попытке УДАЛЕНИЯ экземп- ляра сущности, на первичный ключ которой ссылается внешний ключ? На- пример, при удалении поставщика, который осуществил, по крайней мере, одну поставку. Для данной операции существует три возможности, она: КАСКАДИРУЕТСЯ — операция удаления "каскадируется" с тем, чтобы удалить также все поставки удаляемого поставщика; ОГРАНИЧИВАЕТСЯ — удаляются лишь те поставщики, которые еще не осуществляли поставок. Иначе операция удаления отвергается; УСТАНАВЛИВАЕТСЯ — для всех поставок удаляемого поставщика внешний ключ устанавливается в неопределенное ( NULL ) значение, а затем этот поставщик удаляется. Такая возможность, конечно, неприменима, ес- ли данный внешний ключ не должен содержать NULL -значений. Третий вопрос — что должно происходить при попытке ОБНОВЛЕНИЯ первичного ключа сущности, на которую ссылается некоторый внешний ключ? Например, может быть предпринята попытка обновить номер такого поставщика, для которого имеется, по крайней мере, одна соответствующая поставка. Этот случай для определенности снова рассмотрим подробнее. Имеются те же три возможности, как и при удалении: КАСКАДИРУЕТСЯ — операция обновления "каскадируется" с тем, чтобы обновить также и внешний ключ в поставках этого поставщика; ОГРАНИЧИВАЕТСЯ — обновляются первичные ключи лишь тех по- ставщиков, которые еще не осуществляли поставок. Иначе операция об- новления отвергается; УСТАНАВЛИВАЕТСЯ — для всех поставок обновляемого поставщика внешний ключ устанавливается в неопределенное значение, а затем об- Глава 2. Инфологическая модель данных "сущность - связь" 29 новляется первичный ключ поставщика. Такая возможность, конечно, не- применима, если данный внешний ключ не должен содержать NULL - значений. Таким образом, для каждого внешнего ключа в проекте проектировщик базы данных должен специфицировать не только поле или комбинацию полей, составляющих этот внешний ключ и сущность, которая идентифицируется этим ключом, но также и ответы на указанные ранее вопросы (три ограниче- ния, которые относятся к этому внешнему ключу). Теперь о характеристиках, существование которых зависит от характеризуе- мых сущностей. Для них три рассмотренные ранее ограничения на внешний ключ должны специфицироваться следующим образом: NULL -значения не допустимы, УДАЛЕНИЕ ИЗ (характеризуемой сущности) КАСКАДИРУЕТСЯ, ОБНОВЛЕНИЕ (первичный ключ характеризуемой сущности) КАСКАДИРУЕТСЯ. Указанные спецификации представляют зависимость по существованию ха- рактеристических сущностей. 2.5. Ограничения целостности Целостность (от англ. integrity — нетронутость, неприкосновенность, со- хранность, целостность) — понимается как правильность данных в любой момент времени. Но эта цель может быть достигнута лишь в определенных пределах: СУБД не может контролировать правильность каждого отдельного значения, вводимого в базу данных (хотя каждое значение можно проверить на правдоподобность). Например, нельзя обнаружить, что вводимое значение 5 (представляющее номер дня недели) в действительности должно быть рав- но 3. С другой стороны, значение 9 явно будет ошибочным и СУБД должна его отвергнуть. Однако для этого ей следует сообщить, что номера дней не- дели должны принадлежать набору (1,2,3,4,5,6,7). Поддержание целостности базы данных может рассматриваться как защита данных от неверных изменений или разрушений (не путать с незаконными изменениями и разрушениями, являющимися проблемой безопасности). Со- временные СУБД имеют ряд средств для обеспечения поддержания целост- ности (так же, как и средств обеспечения поддержания безопасности). Часть I. Что такое база данных и СУБД 30 Выделяют три группы правил целостности. Целостность по сущностям. Не допускается, чтобы какой-либо атрибут, участвующий в первичном ключе, принимал неопределенное значение. Целостность по ссылкам. Значение внешнего ключа должно либо: быть равным значению первичного ключа ассоциируемой (характери- зуемой) сущности; быть полностью неопределенным, т. е. каждое значение атрибута, уча- ствующего во внешнем ключе, должно быть неопределенным. Целостность, определяемая пользователем. Для любой конкретной базы данных существует ряд дополнительных спе- цифических правил, которые относятся к ней одной и определяются раз- работчиком. Чаще всего контролируется: уникальность тех или иных атрибутов; диапазон значений (экзаменационная оценка от 2 до 5); принадлежность набору значений (пол "М" или "Ж"). 2.6. О построении инфологической модели Читатель, познакомившийся лишь с материалом данной главы, не сможет правильно воспринять и оценить тех советов и рекомендаций по построению хорошей инфологической модели, которые десятилетиями формировались крупнейшими специалистами в области обработки данных. Для этого надо, по крайней мере, изучить последующие материалы. В идеале же необходимо, чтобы читатель предварительно реализовал хотя бы один проект информаци- онной системы, предложил его реальным пользователям и побыл админист- ратором базы данных и приложений столь долго, чтобы осознать хотя бы не- большую толику проблем, возникающих из-за недостаточно продуманного проекта. Опыт авторов и всех знакомых им специалистов по информацион- ным системам показывает, что любые теоретические рекомендации воспри- нимаются всерьез лишь после нескольких безрезультатных попыток оживле- ния неудачно спроектированных систем. (Хотя есть и такие проектировщики, которые продолжают верить, что смогут реанимировать умирающий проект с помощью изменения программ, а не инфологической модели базы данных.) Глава 2. Инфологическая модель данных "сущность - связь" 31 Основная сложность восприятия рекомендаций, приведенных в последую- щих главах, чисто психологического плана. Действительно, для определения перечня и структуры хранимых данных на- до собрать информацию о реальных и потенциальных приложениях, а также о пользователях базы данных, а при построении инфологической модели следует заботиться лишь о надежности хранения этих данных, напрочь забы- вая о приложениях и пользователях, для которых создается база данных. Это связано с абсолютно различающимися требованиями к базе данных при- кладных программистов и администратора базы данных. Первые хотели бы иметь в одном месте (например, в одной таблице) все данные, необходимые им для реализации запроса из прикладной программы или с терминала. Вто- рые же заботятся об исключении возможных искажений хранимых данных при вводе в базу данных новой информации и обновлении или удалении су- ществующей. Для этого они удаляют из базы данных дубликаты и нежела- тельные функциональные связи между атрибутами, разбивая базу данных на множество маленьких таблиц. Так как многолетний мировой опыт использо- вания информационных систем, построенных на основе баз данных, показы- вает, что недостатки проекта невозможно устранить любыми ухищрениями в программах приложений, то опытные проектировщики не позволяют себе идти навстречу прикладным программистам (даже тогда, когда они сами яв- ляются таковыми). И хотя авторы осознают, что большинство людей предпочитает учиться на собственных ошибках, они все же еще раз советуют неопытным проекти- ровщикам баз данных: четко разграничивать такие понятия как запрос на данные и ведение дан- ных (ввод, изменение и удаление); помнить, что, как правило, база данных является информационной осно- вой не одного, а нескольких приложений, часть из которых появится в бу- дущем; плохой проект базы данных не может быть исправлен с помощью любых (даже самых изощренных) приложений. |