/
Автор: Джексон Г.
Теги: компьютерные технологии программирование микроэлектроника базы данных информационные технологии эвм
ISBN: 5-03-002006-3
Год: 1991
Текст
RELATIONAL
DATABASE DESIGN
WITH MICROCOMPUTER
APPLICATIONS
GLENN A. JACKSON
Oakland University
Prentice-Hall International, Inc.
Г.Джексон
ПРОЕКТИРОВАНИЕ
РЕЛЯЦИОННЫХ БАЗ ДАННЫХ
ДЛЯ ИСПОЛЬЗОВАНИЯ
С МИКРОЭВМ
Перевод с английского А.Н. Елькова
под редакцией
канд. физ.-мат. наук С.А. Платонова
Москва <<Мир>> 1991
ББК 32.973
Д40
УДК 681.3
Джексон Г.
Проектирование реляционных баз данных для
использования с микроЭВМ:
Д40 Пер. с англ. - М.: Мир, 1991. - 252 с, ил.
ISBN 5-03-002006-3
Книга американского специалиста является введением в
теорию проектирования реляционных баз данных (БД). В
ней изложены основные положения и методы проектирова-
проектирования реляционных БД. Подробно описаны реализации конк-
конкретной БД с помощью популярных СУБД dBASE III и
R:base 5000, выполненные с использованием предлагаемых ме-
методов проектирования. Приведены тексты программ с под-
подробным их описанием.
Для пользователей ЭВМ.
д 2404090000-070 133-91 ББК 32.973
041@1)-91
Редакция литературы по информатике и робототехнике
Научное издание
Глен Джексон
Проектирование реляционных баз данных для использования с
микроЭВМ
Заведующий редакцией д-р техн. наук А.Л. Щерс. Зам. заведую-
заведующего редакцией Э.Н. Бадиков. Научный редактор С.В.Богдасаров.
Художник А.В. Захаров
Художественные редакторы Н.М. Иванов, О.Н. Адаскина
Оригинал-макет подготовлен на персональном компьютере и отпеча-
отпечатан на лазерном принтере в издательстве "Мир"
Подписано к печати 10.06.91. Формат 84хЮ8/зг Бумага офсетная
N 1. Печать офсетная. Объем 4 бум.л. Усл.печ.л. 13,44. Усл.кр.-
отт. 13,75. Уч.-изд.л. 11,95. Изд N6/7837. Тираж 20000 экз. Зак.1
Цена 3 руб. 80 коп.
Издательство "Мир" В/О "Совэкспорткнига" Государственного ко-
комитета СССР по делам издательств, полиграфии и книжной тор-
торговли. 129820, Москва, 1-й Рижский пер., 2.
Ордена Трудового Красного Знамени Московская типография N7
"Искра революции" Государственного комитета СССР по печати,
103001, Москва, Трехпрудный пер.,9
ISBN 5-03-002006-3 (русск.) (с) Prentice-Hall, Inc.
ISBN 0-13-771835 (англ.) ©Перевод на русский язык
Ельков А.Н. 1991
ПРЕДИСЛОВИЕ РЕДАКТОРА ПЕРЕВОДА
Развитие технологий построения баз данных насчитывает уже чет-
четвертьвековую историю. В 1965 г. появились первые результаты в
области управления базами данных (работы Чарлза Бахмана), и
данной проблемой начал заниматься КОДАСИЛ1). С той поры тех-
технологии баз данных прошли большой путь. Семидесятые годы озна-
ознаменовались разработкой трех основных моделей данных - иерархи-
иерархической, сетевой и реляционной, каждая из которых нашла своих
активных сторонников и последователей. По мере развития вычис-
вычислительной техники на базе этих трех подходов было построено
большое число СУБД. В восьмидесятые годы с развитием микро-
микропроцессорной техники и широким распространением персональных
компьютеров возникла новая волна интереса к базам данных, их
проектированию и реализации.
В настоящее время, видимо, необходимо признать, что на рынке
СУБД для персональных компьютеров победил реляционный под-
подход, отличающийся простотой базисных понятий и строгостью мате-
математических основ. Вместе с тем, внедрение компьютеров в повсед-
повседневную жизнь заставляет большое число пользователей заниматься
проблемами организации баз данных. Готовая СУБД является лишь
инструментом реализации спроектированной базы данных и работы
с ней, в то время как принципиальные трудности начинаются с
момента принятия решения о необходимости создания базы данных.
Эта книга как раз и задумана автором как практическое руковод-
руководство к проектированию баз данных на персональном компьютере на
основе реляционной модели.
Задача, которую ставил перед собой автор, с успехом решена. В
отличие от ранее изданных руководств книга охватывает все этапы
проектирования баз данных - от построения концептуальной модели
до реализации на основе широко известных СУБД dBASE III и
R:BASE 5000. К несомненным достоинствам книги необходимо от-
отнести сочетание строгого математического подхода к предлагаемым
алгоритмам (с определением всех употребляемых терминов и поня-
понятий) с живым обсуждением и примерами конкретных процедур ре-
реализации. В ней удачно сопоставлены два алгоритма построения
отношений в нормальной форме Бойса-Кодда - на основе понятия
функциональной зависимости (удобного для небольших баз данных
с малым количеством атрибутов) и на основе широко распростра-
распространенной модели "сущность-связь". В отличие от большого числа из-
известных аналитических методов предлагаемые автором правила сво-
сводят число необходимых отношений в базе к минимуму. Хорошо
формализована процедура проверки полученного проекта.
Ориентация на конкретные СУБД позволила автору избежать об-
обсуждения методов физической реализации хранения и поиска дан-
данных, что сделало книгу компактной по объему. Каждая глава кни-
книги снабжена продуманными задачами, существенно помогающими
*' Американская организация, занимающаяся разработкой стандарт-
стандартных средств для обработки экономических задач.
Предисловие редактора перевода
усвоению материала. Можно сказать, что в книге реализован прин-
принцип "примеры при изучении наук важнее правил**, поскольку зна-
значительный объем книги посвящен последовательному проектирова-
проектированию базы данных секретаря кегельной лиги. На этом примере про-
продемонстрированы все алгоритмы и показаны все трудности проекти-
проектирования. Пример доведен до физической реализации в рассматри-
рассматриваемых СУБД. Тексты распечаток полностью соответствуют синтак-
синтаксису СУБД и, будучи реализованными на персональном компьюте-
компьютере, работают (в чем вслед за нами может убедиться любой желающий).
Все вышеизложенное позволяет считать книгу несомненным успе-
успехом автора. Она будет полезна всем пользователям персональных
компьютеров и удачно дополнит фирменные руководства по конк-
конкретным СУБД.
Посвящаю моей жене
МЭЙ
и нашим двум сыновьям
АЛАНУ и МАРКУ
ПРЕДИСЛОВИЕ
Данная книга представляет собой введение в проекти-
проектирование реляционных баз данных (БД). При этом в
намерение автора не входило предложить читателю
начальное руководство по использованию конкретной
системы управления базами данных (СУБД) или же
общее описание какого-либо специального языка за-
запросов. Тематика книги дает представление о таких
пакетах, как dBase II/III и R:base 5000, но главное -
это изучение проблемы проектирования БД, использо-
использование которых предполагается со стандартной СУБД
(например, dBase IIII). Цель книги - описание про-
процесса проектирования баз данных на доступном для
среднего пользователя микрокомпьютере.
Начинающему реляционная БД представляется как
набор таблиц или файлов (в действительности отно-
отношений, как мы увидим позже). Если эти таблицы
спроектированы некорректно, данные в БД могут
быть ошибочно изменены или удалены при использо-
использовании СУБД. Здесь могут возникнуть следующие ти-
типичные проблемы.
1. Пользователю требуется удалить информацию о
партиях товара от некоторого поставщика. Команда
на удаление этой информации завершается также
удалением имени и адреса поставщика (помимо ин-
информации о поставке).
2. Пользователь пытается исправить написание
имени клиента. Однако он забывает, что имя хранит-
хранится в трех различных местах. В результате только од-
^ dBase II и dBase III - зарегистрированные торговые марки фир-
фирмы Ashton-Tate. R:base 5000 - зарегистрированная торговая марка
фирмы Microrim, Inc.
Предисловие
но из трех имен изменяется, правильное написание
имени клиента вызывает сомнение.
Это только два простых примера типичных про-
проблем, которые могут возникнуть в случае непроду-
непродуманного проектирования отношений в БД. И наобо-
наоборот, именно эти проблемы будут исключены в случае
правильного проектирования БД.
Теория проектирования реляционных БД основыва-
основывается на математической теории отношений. Эта тео-
теория используется при разработке алгоритмических ме-
методов проектирования, что является одной из главных
причин широкого признания реляционного подхода к
проектированию БД. Поскольку большинство пользо-
пользователей микрокомпьютерных систем БД не являются
профессиональными математиками, в книге детально
рассмотрены принципы проектирования при минимуме
математического формализма. В этом состоит одна из
целей предлагаемой книги - некоторый математиче-
математический формализм в ней содержится, так как этого
практически невозможно избежать при обсуждении
отношений, однако он представлен в форме, понятной
для большинства читателей.
Книга делится на четыре логически связанные час-
части. В части первой (гл. 1 и 2) рассмотрены опреде-
определение и свойства отношений, определение реляцион-
реляционных БД, и проблемы, возникающие при неудовлетво-
неудовлетворительном проектировании БД. Часть вторая (гл. 3, 4
и 5) посвящена концепции функциональных зависи-
зависимостей и их использованию вместе с алгоритмами
проектирования на заключительном этапе разработки
БД. Эта часть включает в себя изучение типичных
проблем проектирования БД. Часть третья (гл. 6, 7 и
8) знакомит читателя со вторым методом проектиро-
проектирования, основанном на использовании модели "сущ-
"сущность-связь"; часть четвертая - с полными реализаци-
реализациями конкретной БД в средах dBase III (гл. 9) и
R:base 5000 (гл. 10). Здесь же поясняется, что неко-
некоторые запросы к БД требуют скорее использования
языков высокого уровня, нежели простого применения
команд БД. Образцы запросов для dBase II и dBase
III используются по всему тексту для выделения и
иллюстрации определенных аспектов представляемой
теории. Представленный в довольно сжатом объеме
Предисловие
материал будет полезен любому начинающему проек-
проектировщику БД, а также контролирующим их менед-
менеджерам. Книга может послужить идеальным справоч-
справочником для верхнего коммерческого управляющего со-
состава, прошедшего начальный курс изучения СУБД.
Личные имена и фамилии, названия организаций, ис-
использованные в примерах, и рассмотренные в книге
случаи являются безусловно вымышленными.
Благодарности
Многие студенты Оклендского Университета читали
различные части рукописи. Их комментарии, а также
конструктивная критика оценены по достоинству. Две
студентки заслуживают особого упоминания: мисс
Джудит Айрленд, разработавшая оригинальную вер-
версию БД секретаря кегельной лиги (гл. 5), и мисс
Барбара МакНил, разработавшая базовую логику и
осуществившая dBase Ill-реализацию программного мо-
модуля, предназначенного для определения положения
команд (гл. 9).
1. БАЗЫ ДАННЫХ, ОТНОШЕНИЯ И
РЕЛЯЦИОННЫЕ БАЗЫ ДАННЫХ
1.1. Базовые концепции
Базу данных можно определить как унифицирован-
унифицированную совокупность данных, совместно используемую
всем персоналом предприятия, банка или учебного
заведения. Задача БД состоит в хранении всех пред-
представляющих для некоторого предприятия интерес дан-
данных в одном месте, причем таким способом, который
заведомо исключает их избыточность. Хранение мно-
множественных копий данных в различных местах пред-
предприятия чревато возникновением рассогласований
между предположительно идентичными наборами дан-
данных. В хорошо спроектированной БД избыточность
данных исключается, и вероятность сохранения проти-
противоречивых данных минимизируется.
В больших компьютерных системах к данным,
хранящимся в БД, доступ может осуществляться од-
одновременно сотней и более пользователей. БД в та-
таких случаях может иметь сотни полей данных с мил-
миллионами единиц информации. Такие системы могут
содержать буквально все данные, требующиеся для
управления предприятием. БД на микрокомпьютерных
системах имеют гораздо меньший масштаб. Здесь к
конкретной БД в некоторый момент времени обычно
осуществляет доступ один пользователь и каждая БД
содержит только некоторое подмножество данных,
требующихся предприятию. Одна БД разрабатывается*
скажем, для хранения финансовой информации, дру-
другая - данных о персонале. Будет ли разрабатываемая
БД размещаться на большой ЭВМ или на микроком-
микрокомпьютере - функции СУБД в обоих случаях одинако-
одинаковы. СУБД представляет собой программно-аппаратный
пакет, обеспечивающий пользователям простой доступ
к БД. Программная часть СУБД, которую некоторые
изготовители называют менеджером БД, выступает в
качестве интерфейса между пользователем и БД
(рис. 1.1). Менеджер БД обеспечивает программные
средства, необходимые для создания, загрузки, запро-
запроса и обновления данных. Менеджер также контроли-
контролирует все действия, связанные с управлением вводом-
Глава 1
11
выводом и памятью БД, а на больших ЭВМ на него
возлагается и решение проблем безопасности и совме-
совместного использования данных. Короче говоря, хорошо
спроектированная СУБД обеспечивает программное обес-
обеспечение, упрощающее для пользователя общение с БД.
СУБД
Запросы от
пользователя № N
Запросы от
пользователя № 1
СУБД координирует
все действия,
относящиеся
к базе данных
Менеджер БД
Обрабатывает все
программные
обращения к БД
База данных
Рис. 1.1. Основные компоненты архитектуры СУБД
Другое сходство между большими и малыми СУБД
заключается в том, что в обоих случаях сама БД
должна быть хорошо спроектирована, если мы хотим,
чтобы система баз данных как единое целое функци-
функционировала должным образом. Цель книги состоит в
выделении и описании некоторых базовых процедур
проектирования для определенного типа БД, а именно
12 Базы данных, отношения и реляционные базы данных
реляционных. Предполагается, что пользователь будет
устанавливать БД на микрокомпьютерной системе; orffta-
ко, те же алгоритмы проектирования применимы к БД,
проектируемым для больших компьютерных систем.
1.2. Определение отношения
Математически отношение определяется следующим
образом.
Пусть даны "N" множеств Dl, D2, ...,DN, тогда R
есть отношение над этими множествами, если R есть
множество упорядоченных n-кортежей вида <dl, d2,
..., dn>, где dl - элемент из Dl, d2 - элемент из
D2,... и dn - элемент из DN. Dl, D2, ..., DN назы-
называются доменами отношения R.
Домен D1
Домен D2
Домен D3
Домен D4
Отношение -
Кортеж
101
102
103
104
L105
106
болт
муфта
винт
гайка
муфта
болт
черный
синий
красный
зеленый
красный
оранжевый
3
9
11
4
21
Рис. 1.2. Отношение с математической точки зрения
Смысл данного определения наиболее просто пояс-
пояснить графически (рис. 1.2). Здесь показаны 4 домена.
Домен D1 - это множество целых чисел; D2 - сим-
Глава 1
13
вольных строк, представляющих собой названия пред-
предметов; D3 - символьных строк, представляющих собой
названия цветов; D4 - еще одно множество целых
чисел. Отношение R состоит из 6 кортежей. Каждый
кортеж - из 4 элементов, которые выбираются каж-
каждый из своего домена. Обратите внимание на порядок
элементов в кортеже: первый элемент каждого корте-
кортежа выбран из домена D1, второй элемент - из доме-
домена D2 и т. д.
Сущность "реального мира
(Имя файла)
Одна запись
чира" —j
ДЕТАЛЬ
дном
101
102
103
104
105
106
дназв
болт
муфта
винт
гайка
муфта
болт
— Атрибут сущности
(Поле в записи)
цвет
черный
синий
красный
зеленый
красный
оранжевый
вес
3
9
И
4
13
21
Файл -~|
Значение атрибута '
(Значение поля в записи)
Рис. 1.3. Отношение с точки зрения обработки данных
Взгляд на отношение с точки зрения обработки
данных характеризует рис. 1.3. Четыре домена, пред-
представленные на рис. 1.2, соотносятся с четырьмя эле-
элементами реального мира: номером детали, ее назва-
названием, цветом и весом. Отношение принимает вид
таблицы или файла, где кортежи - строки таблицы
или записи в файле.
Имена столбцов (с точки зрения обработки данных
- поля в записи) называются атрибутами, а индиви-
индивидуальные значения, появляющиеся в отдельных корте-
14 Базы данных, отношения и реляционные базы данных
жах, - значениями атрибутов. Таким образом, пер-
первый элемент первого кортежа имеет значение атрибу-
атрибута, равное 101 и взятое из домена дном. Следующие
наборы терминов будут использоваться поочередно:
1. отношение, таблица и файл;
2. кортеж, строка и запись;
3. атрибут, столбец и поле;
так же как и в большей части документации по
микрокомпьютерным БД.
Следует сделать одно замечание по поводу разли-
различия между математическим определением отношения
и действительным хранением отношений в микроком-
микрокомпьютерных системах БД. По определению отношение
не может иметь два идентичных кортежа. Несмотря
на то что большинство больших СУБД не допускают
хранения идентичных кортежей (записей) в отноше-
отношении (файле), многие микрокомпьютерные СУБД это
допускают (если не используется специальная техника
программирования, предотвращающая возникновение
указанной ситуации).
Следует упомянуть два дополнительных термина,
касающихся отношений. Число столбцов в отношении
называют степенью. Текущее число кортежей в отно-
отношении называется мощностью. Степень отношения
обычно не изменяется после создания отношения, но
мощность будет колебаться по мере добавления новых
и удаления старых кортежей.
1.3. Определение реляционной БД
Реляционная БД представляет собой не что иное, как
совокупность отношений, содержащих всю информа-
информацию, которая должна храниться в БД. На рис. 1.4
приведен пример очень маленькой БД, названной По-
Поставщик—Детали.
Эта база содержит три типа информации о строи-
строительной компании1):
*) БД Поставщик—Детали - хороший пример небольшой по объему
реляционной БД, часто используемый в литературе.
Глава 1
15
1. Информация о поставщиках, поставляющих дета-
детали предприятию. Сюда относятся номер поставщика
(предполагается уникальным), а также его фамилия,
статус и город проживания, (не являются уникальны-
уникальными). Эта информация содержится в отношении ПО-
ПОСТАВЩИК.
ДЕТАЛЬ
АПфМ
101
102
103
104
105
106
дназв
болт
муфта
винт
гайка
муфта
болт
цвет
черный
синий
красный
зеленый
красный
оранжевый
вес
3
9
И
4
13
21
ПОСТАВЩИК
пном
П1
П2
ПЗ
П4
П5
пфам
Смит
Джонс
Эддер
Хаус
Блейк
статус
20
15
10
30
20
город
Лондон
Детройт
Чикаго
Париж
Париж
ПА
ПНОМ
П1
П1
П1
П1
П2
П2
П2
П2
ПЗ
ПЗ
ПЗ
ПЗ
ПЗ
ПЗ
П4
П4
П5
П5
дном
101
102
103
106
101
102
105
106
101
102
103
104
105
106
103
106
103
104
шт
9
4
2
3
3
8
11
9
7
13
6
1
2
5
7
13
8
9
Рис. 1.4. База данных Поставщик-Детали
2. Информация о деталях, используемых на пред-
предприятии. Сюда относятся номер детали, являющийся
уникальным, название, цвет и вес, не являющиеся
уникальными. Эта информация содержится в отноше-
отношении ДЕТАЛЬ.
3. Информация о номерах и количестве деталей от
каждого поставщика. Эта информация содержится в
отношении ПД.
Каждое отношение в БД хранится в отдельном
файле. Структура файла, используемого для хранения
отношения, довольна проста, поскольку все записи
имеют одинаковый формат. В больших СУБД каждое
16 Базы данных, отношения и реляционные базы данных
отношение сохраняется в виде индексированного фай-
файла, где индекс представляет собой атрибут или набор
атрибутов, специфицированный при конструировании
отношения.
Набор атрибутов, используемый в качестве индек-
индекса, называется первичным ключом отношения. Пер-
Первичный ключ определяется как такой атрибут, или
набор атрибутов, который может быть использован
для однозначной идентификации конкретного кортежа.
Первичный ключ не должен иметь дополнительных
атрибутов. Это значит, что если единичный произ-
произвольный атрибут исключить из первичного ключа, ос-
оставшихся атрибутов будет недостаточно для однознач-
однозначной идентификации отдельных кортежей. В БД По-
Поставщик-Детали первичными ключами являются
<пном> для отношения ПОСТАВЩИК, <дном> для
отношения ДЕТАЛЬ и пара атрибутов <пном, дном>
для отношения ПД.
Читатель может убедиться, что каждый первичный
ключ является достаточным для однозначной иденти-
идентификации каждого кортежа в отношении. Например, в
отношении ПД, если пном - Ш и дном = 101, мож-
можно найти не более одного кортежа с указанными зна-
значениями атрибутов. На рис. 1.4 данные значения со-
содержит кортеж <П1,101,9>. Попытка сохранить дру-
другой кортеж с тем же первичным ключом, скажем,
<П1,101,11>, приводит к возникновению конфликт-
конфликтной ситуации, поскольку становится неясным сколько
деталей с номером 101 поставляет П1 - 9 или 11 (а
может быть 20?). В полностью разработанной СУБД
при попытке пользователя записать кортеж, имеющий
первичный ключ, совпадающий с первичным ключом
другого кортежа, уже включенного в отношение, ге-
генерируется сообщение об ошибке. Во многих реализа-
реализациях СУБД, предназначенных для микрокомпьютеров,
кортежи с совпадающими первичными ключами и да-
даже полностью идентичные кортежи могут быть зане-
занесены в отношение, и это не приводит к возникнове-
возникновению ошибки СУБД. В связи с этим могут возникнуть
некоторые проблемы.
Во многих СУБД индекс файла, содержащего отно-
отношение, не создается автоматически, и пользователь
должен выполнить команду INDEX для его создания.
Индексирование файлов значительно ускоряет выпол-
Глава 1
17
нение некоторых команд. Возможно индексирование
отношения с использованием атрибутов, отличных от
первичного ключа. Данный тип индекса называется
вторичным индексом и применяется в целях умень-
уменьшения времени доступа при нахождении данных в
отношении. Простой пример индексного файла приве-
приведен на рис. 1.5. Обратите внимание, что если само
отношение не упорядочено каким-либо образом и в
нем могут присутствовать строки, оставшиеся после
удаления некоторых кортежей, то индексный файл,
напротив, отсортирован. Структура индексного файла
может быть разной, но обычно используется некото-
некоторый вариант древовидной структуры, обеспечивающей
быстрый поиск. Для пояснения выбрана структура ин-
индексного файла, показанного на рис. 1.5, но ее не
следует воспринимать как образец практического про-
проектирования.
Поставщикх (Индексный файл) Поставщик (Файл данных)
Номер
записи
0001
0002
0003
0004
0005
Файл
пном
П1
П2
ПЗ
П4
П5
Поставщик
Номер записи
0006
0004
0003
0001
0002
номер
записи
0001
0002
0003
0004
0005
0006
пном
П4
П5
ПЗ
П2
Эта
П1
пфам
Хаус
Блейк
Эддер
Джонс
запись
Смит
статус город
30
20
10
15
была
20
Париж
Париж
Чикаго
Детройт
удалена
Лондон
Рис. 1.5. Простой пример индексного файла
Число отношений в БД и конкретные атрибуты,
приписываемые каждому отношению, определяются в
процессе проектирования. Собственно процесс проек-
проектирования может быть довольно продолжительным.
Однако после завершения этапа проектирования со-
создание БД средствами СУБД можно выполнить до-
довольно быстро. В случае БД Поставщик—Детали
структура ее полностью специфицируется коротким
набором предложений, приведенным на рис. 1.6. Это
сжатое описание называется концептуальной моделью
БД и содержит всю информацию, необходимую для
создания полной структуры БД вне зависимости от
того, какая конкретно СУБД будет использована. На
18 Базы данных, отношения и реляционные базы данных
рис. 1.7 приводится пример создания отношения ПО-
ПОСТАВЩИК в dBase II вместе с индексным файлом
для отношения ПОСТАВЩИК, в котором индекс пе-
перекрывает первичный ключ. Каждое из отношений в
БД Поставщик-Детали будет создаваться аналогичным
образом. Обратите внимание на то, что вся информа-
информация, необходимая для создания ПОСТАВЩИК, содер-
содержится в концептуальной модели.
Название БД: Поставщик_Детали
Атрибуты и тип:
пном симв(З),
пфам симвF),
статус целый,
город симвA0),
дном целый,
дназв симвF),
цвет симвF),
вес целый,
шт целый.
Отношения и <Первичные ключи>:
Поставщик(пном, пфам, статус, город) <пном>,
ПД(пном, дном, шт) <пном, дном>,
Деталь(дном, дназв, цвет, вес) <дном>.
Рис. 1.6. Концептуальная модель БД Поставщик-Детали
. CREATE
ENTER FILENAME: В: Поставщик
ENTER RECORD STRUCTURE AS FOLLOWS:
FIELD NAME,TYPE,WIDTH,DECIMAL PLACES
001 пном,с,3
002 пфам,с,6
003 статус,п,2
004 город,с,10
005
INPUT DATA NOW? N
. USE В:Поставщик
. INDEX ON пном ТО В: Поставщикх
Рис. 1.7. Создание отношения и индексного файла
для этого отношения в dBASE II
Построенное отношение является незаполненным, и
его необходимо загрузить покортежно при помощи со-
соответствующих команд записи.
Глава 1 19
Листинг содержимого отношения или всех отноше-
отношений в БД, подобный тому, который приведен на рис. 1.4
для БД Поставщик-Детали, следует рассматривать
как фотографию вида отношений в некоторый момент
времени. Следует помнить, что содержимое всех отно-
отношений динамически изменяется, поскольку кортежи
могут быть добавлены, удалены или модифицированы
в течение жизненного цикла отношений. Отдельный
листинг некоторого отношения в определенный мо-
момент времени называется экземпляром этого отноше-
отношения.
Первичный ключ, определенный для отношения,
настолько важен, что атрибуты или набор атрибутов,
формирующих первичный ключ, обычно помечаются
при математической форме записи отношений. В дан-
данной книге атрибуты, формирующие первичный ключ,
подчеркиваются. Например, определенное на рис. 1.6
отношение ПД будет записано в виде
ПД (пном,дном,шт). Это означает, что пара атрибутов
<пном,дном> представляет собой первичный ключ
для данного отношения.
2. НЕОБХОДИМОСТЬ ПРОЕКТИРОВАНИЯ БАЗ
ДАННЫХ
2.1. Цели проектирования
Прежде чем приступать к рассмотрению специфиче-
специфических алгоритмов и проблем проектирования, имеет
смысл наметить некоторые цели проектирования. В
частности, в чем заключается желаемый конечный ре-
результат процесса проектирования реляционных БД?
Среди множества целей, стоящих перед проектирова-
проектированием, следующие представляются наиболее важными:
1. Возможность хранения всех необходимых
данных в БД.
2. Исключение избыточности данных.
3. Сведение числа хранимых в БД отношений к
минимуму.
4. Нормализация отношений для упрощения ре-
решения проблем, связанных с обновлением и удалени-
удалением данных.
Цель 1: Возможность хранения всех необходимых
данных в БД
Эта цель кажется очевидной, тем не менее она
очень важна. Предполагается, что БД должна содер-
содержать все данные, представляющие интерес для пред-
предприятия, так что при проектировании следует предус-
предусмотреть возможность размещения в БД всех необхо-
необходимых данных. Первым шагом в процессе проектиро-
проектирования является определение всех атрибутов, которые
впоследствии будут помещены в БД. После определе-
определения атрибутов проектировщик обдумывает, сколько
отношений необходимо и какие атрибуты включать в
какие отношения. В случае микрокомпьютерных БД
дополнительно необходимо решить, следует ли пред-
предназначенные для хранения данные концептуализиро-
концептуализировать для построения одной базы или, возможно, двух
и более.
Цель 2: Исключение избыточности данных
Сущность этой цели отнюдь не очевидна для начи-
начинающего проектировщика БД. Ключ к ее пониманию
Глава 2
21
заключается в уяснении четкого различия между дуб-
дублированием данных и избыточным дублированием
данных. Например, обратимся к отношению С—Н,
приведенному на рис. 2.1 (а). Отношение имеет два
атрибута - Слж# (табельный номер служащего) и
Начк (начальник). В отношении содержатся данные,
указывающие непосредственного начальника каждого
служащего предприятия. Фамилии начальников могут
неоднократно появляться в отношении. В действитель-
действительности фамилия начальника появляется один раз для
каждого подчиненного ему служащего. Обратите вни-
внимание, однако, что хотя "Джонс" и "Смит" появля-
появляются дважды в экземпляре С—Н, приведенном в на
рис. 2.1 (а), ни одна из дублируемых фамилий не яв-
является избыточной. Причина отсутствия избыточности
заключается в том, что при удалении одной из фа-
фамилий из отношения будет утеряна информация. На-
Например, на рис. 2.1F) показан вид экземпляра отно-
отношения С—Н при удалении дублированных фамилий. В
этом случае нет возможности узнать фамилии на-
начальников служащих с номерами #195 и #200.
с-н
с-н
Слж#
125
138
195
200
Начк
Джонс
Смит
Смит
Джонс
Слж#
125
138
195
200
Начк
Джонс
Смит
Рис. 2.L Дублированные данные, не являющиеся из-
избыточными
На рис. 2.2 (а) приведен пример отношения с из-
избыточным дублированием данных. Отношение С—Н—Т
похоже на отношение С—Н, но включает дополни-
дополнительный атрибут Нтел, представляющий собой номер
телефона начальника. Предполагается, что каждый
начальник имеет только один телефонный номер. В
этом экземпляре отношения номера телефонов Джонса
и Смита появятся более чем один раз и дублирован-
22
Необходимость проектирования баз данных
ная информация о телефонных номерах является из-
избыточной. Причина избыточности в том, что если,
скажем, удалить один из номеров Джонса, эта ин-
информация может быть получена из других кортежей
отношения. На рис. 2.2F) приведен пример того, как
будет выглядеть отношение С—Н—Т в случае замеще-
замещения дублированных телефонных номеров "нулями".
С-Н-1
Слж#
125
138
195
200
Начк
Джонс
Смит
Смит
Джонс
Нтел
3051
2222
2222
3051
С-Н-Т
Слж#
125
138
195
200
Начк
Джонс
Смит
Смит
Джонс
Нтел
3051
2222
с-н
Н-Т
Слж#
125
138
195
200
Начк
Джонс
Смит
Смит
Джонс
Начк
Джонс
Смит
Нтел
3051
2222
Рис. 2.2. Исключение избыточных данных
Понятно, что телефонные номера Джонса и Смита
не утеряны, поскольку каждый из них обнаруживает-
обнаруживается в одном из кортежей отношения. Данный метод
управления избыточностью неудовлетворителен по
двум причинам. Во-первых, пустых полей в БД сле-
следует избегать, так как необходимы дополнительные
усилия при программировании, направленные на оп-
определение реальных значений "нулей". В рассматри-
рассматриваемом случае чтение третьего кортежа <195,Смит,->
отношения не позволяет узнать телефонный номер
Смита. Пользователь должен уметь находить в отно-
Глава 2 23
шении другой кортеж, для которого значением атри-
атрибута Начк является Смит, а значение атрибута Нтел
не является нулевым. Во-вторых, что более важно,
отношение, представленное на рис. 2.2F), имеет
структуру, чреватую возникновением серьезных про-
проблем при удалении информации. Если служащий с
номером Слж#=125 увольняется с предприятия и
кортеж <125,Джонс,3051> будет удален из отноше-
отношения при должной регистрации факта увольнения, про-
произойдет утеря телефонного номера Джонса, поскольку
нигде более в отношении он не представлен.
Рис. 2.2 (в) показывает лучший способ исключения
избыточности телефонных номеров. Здесь отношение
С—Н—Т заменяется двумя отношениями, одно из кото-
которых содержит информацию о табельных номерах слу-
служащих и фамилиях руководителей, а другое - инфор-
информацию о телефонных номерах начальников. В следу-
следующей главе будет показано, что разбиение отношений
представляет собой стандартную процедуру проектиро-
проектирования, которая должна осуществляться при соблюде-
соблюдении определенных ограничений. Как следует из
рис. 2.2(в), служащий с номером #125 теперь может
быть удален из отношения С—Н без потери номера
телефона бывшего начальника этого служащего, хра-
хранимого в отношении Н—Т.
Цель 3: Сведение числа хранимых в БД отношений
к минимуму.
Эта цель обусловлена тем, что разбиение одного
отношения на два или более меньших отношений же-
желательно с точки зрения исключения определенных
проблем, но это неудобно для пользователя. Таким
образом, нельзя допускать неограниченный рост числа
отношений.
Цель 4: Нормализация отношений
Для некоторых отношений очень важна проблема
удаления и обновления (например, обсуждавшаяся
выше в цели 2 потеря телефонного номера руководи-
руководителя). Проектировщик должен уметь обнаруживать
эти потенциально опасные отношения и "нормализо-
"нормализовать их" посредством разбиения предписанным обра-
образом. Нормализация представляет собой разбиение од-
одного отношения на два или более в соответствии со
24 Необходимость проектирования баз данных
специальной процедурой определения разбиения. Нор-
Нормализация будет обсуждаться в гл. 3.
Цели 3 и 4 противоречат друг другу, поэтому
здесь требуется взаимный компромисс. Это будет час-
частью завершающего этапа проектирования.
2.2. Универсальное отношение
Предположим, что требуется разработать небольшую
БД для консультанта университета. У консультанта
имеется много консультируемых им студентов, живу-
живущих на территории университетского городка, причем
все эти студенты учатся на основном факультете.
Первый шаг процесса проектирования состоит в
определении как всех атрибутов, наличие которых в
БД ожидает консультант, так и связей между атрибу-
атрибутами. Эта информация получается от консультанта в
итоге ряда детальных обсуждений, не оставляющих
сомнений в том, что он знает какие данные должны
быть в БД, каким образом БД будет использоваться
и какую информацию консультант ожидает получать
от БД. После нескольких бесед с консультантом име-
имена и условия, связанные с атрибутами, хранение ко-
которых предполагается, были определены следующим
образом:
Сном: Номер студента. Целое значение, уникаль-
уникальное для каждого студента университета.
Сфам: Фамилия студента. Каждый студент имеет
только одну фамилию, но возможно, что одну фами-
фамилию носят несколько студентов.
Кном: Номер комнаты в общежитии городка.
Каждый студент живет на территории городка и име-
имеет комнату. В одной комнате может проживать более
одного студента.
Тном: Номер телефона студента. Каждая комната
общежития имеет один телефон и им пользуются все
студенты, проживающие в этой комнате.
Курс: Номер курса. Это идентификационный номер
курса, посещаемого студентом. Примером может слу-
служить номер МТН122. Консультант будет сохранять
данные только о курсах, завершенных студентом.
Семестр: Университетский семестр. Представляет
собой семестр, в котором данный курс был завершен
Глава 2
25
студентом. Возможно, что студент изучал один и тот
же курс в различных семестрах.
Оценка: Оценка за курс. Оценка, полученная сту-
студентом за определенный курс в данном семестре.
На рис. 2.3 представлен образец данных, концеп-
концептуализированных консультантом для их хранения в
БД. Хотя на рисунке приводится пример в виде таб-
таблицы данных, которые могут храниться в БД в неко-
некоторый момент времени, указанная таблица отношени-
отношением не является.
КОНСУЛЬТАНТ
Сном
3215
ч 3462
3567
4756
Сфам
ДжонсГ
СмитА
ХаузДж
АлексК
Кном
120DH
238VH
120DH
345VH
Тном
2136
2344
2136
3321
Курс
МТН122
SCI120
PHY230
МТН122
МТН122
МТН123
PSY220
SCI239
EGR171
PHY141
MUS389
Семестр
F84
F84
W85
W85
W84
W85
W85
W84
F84
F84
F83
Оценка
1.6
2.4
2.1
2.3
2.3
3.5
3.7
3.3
3.5
1.8
4.0
Рис. 2.3. Данные, необходимые консультанту
3215
ДжонсГ
120DH
2136
МТН122
SCI120
PHY230
МТН122
F84
F84
W85
W85
1.6
2.4
2.1
2.3
Рис. 2.4.
рис. 2.3
Одна "строка" таблицы, приведенной на
Для иллюстрации того, почему таблица на рис.
2.3 не является отношением, выделим одну "строку"
из таблицы (рис. 2.4). На этом рисунке значения че-
четырех полей Сном, Сфам, Кном и Тном - атомар-
26
Необходимость проектирования баз данных
ные1), в то время как значения в полях Курс, Се-
Семестр и Оценка - множественные. Данная "строка"
очевидным образом отличается по форме от кортежей,
представленных в простых отношениях и рассмотрен-
рассмотренных выше. Отличие в том, что не все поля строки
содержат атрибуты, значения которых атомарные. Для
придания данным, приведенным на рис. 2.3, формы
отношения необходимо реконструировать их таким об-
образом, чтобы каждый элемент кортежа имел атомар-
атомарное значение. Обычно это удается сделать с помощью
простого процесса вставки (результат для данного
случая показан на рис. 2.5). В результате этого про-
процесса добавляется большой объем избыточных данных
- исключение избыточности достигается на следующих
этапах проектирования.
КОНСУЛЬТАНТ
Сном
3215
3215
3215
3215
3462
3462
3462
3567
3567
3567
4756
Сфам
ДжонсГ
ДжонсГ
ДжонсГ
ДжонсГ
СмитА
СмитА
СмитА
ХаузДж
ХаузДж
ХаузДж
АлексК
Кном
120DH
120DH
120DH
120DH
238VH
238VH
238VH
120DH
120DH
120DH
345VH
Тном
2136
2136
2136
2136
2344
2344
2344
2136
2136
2136
3321
Курс
МТН122
SCI120
PHY230
МТН122
МТН122
МТН123
PSY220
SCI239
EGR171
PHY141
MUS389
Семестр
F84
F84
W85
W85
W84
W85
W85
W84
F84
F84
F83
Оценка
1.6
2.4
2.1
2.3
2.3
3.5
3.7
3.3
3.5
1.8
4.0
Рис. 2.5. Данные из таблицы, приведенной на рис. 2.3,
помещенные в корректное отношение
Таблица на рис. 2.5 представляет собой экземпляр
корректного отношения. Его называют универсальным
отношением проектируемой БД. В одно универсальное
отношение включаются все представляющие интерес
атрибуты, и оно может содержать все данные, кото-
*) Атомарным называется неделимое значение, а не множество, или
кортеж, значений из некоторых доменов. - Прим. ред.
Глава 2 27
рые предполагается размещать в БД в будущем» Для
малых БД (включающих не более 15 атрибутов) уни-
универсальное отношение может использоваться в качест-
качестве отправной точки при проектировании БД.
2.3. Проблемы, вызываемые использованием
единственного отношения
Начинающий проектировщик будет использовать отно-
отношение КОНСУЛЬТАНТ (рис. 2.5) в качестве завер-
завершенной БД. Это выглядит достаточно последователь-
последовательным. Зачем разбивать отношение КОНСУЛЬТАНТ на
несколько более мелких отношений, если оно способ-
способно заключать в себе все данные? Существует не-
несколько причин, почему не следует использовать дан-
данное отношение в качестве единственного в БД. Это
обусловлено тем, как будет использоваться БД, и ка-
какое воздействие на данные в отношении КОНСУЛЬ-
КОНСУЛЬТАНТ будут оказывать определенные операции. Раз-
Различаются три специфичные проблемы: проблема, свя-
связанная с обновлением (модификацией) данных в БД;
проблема, обусловленная необходимостью удаления
кортежей; проблема, обусловленная необходимостью
включения новых кортежей. Выделенные проблемы
обычно называют аномалиями вставки, удаления и
обновления, понимая под аномалией отклонение от
нормы.
Проблема вставки
Если у консультанта появляется новый консульти-
консультируемый им студент, еще не закончивший курс, для
него необходимо включить в БД кортеж с нулевыми
(пустыми) значениями атрибутов Курс, Семестр и
Оценка. Как уже не раз отмечалось, нулевых значе-
значений следует избегать. Следовательно, включение в БД
нового студента невозможно вплоть до завершения им
курса.
На рис. 2.6(а) показан пример того, как будет вы-
выглядеть отношение КОНСУЛЬТАНТ в случае прину-
принудительного включения в него информации о студенте,
не завершившем ни одного курса (для случая исполь-
использования dBASE II). Пустые символьные строки пред-
представляются пробельными полями (Курс и Семестр), в
28
Необходимость проектирования баз данных
то время как нулевое численное значение в поле
Оценка интерпретируется dBASE II как 0.0. Рис.
2.6F) иллюстрирует возможные последствия появле-
появления 0.0 при отсутствии информации. Получен ответ
на запрос "Выдать список Сном и Сфам для всех
студентов, получивших хотя бы одну оценку ниже
2.0". В число таких студентов попал ХоумерХ, хотя
он не закончил ни одного курса.
use
11st
00001
00002
00003
00004
00005
00006
00007
00008
00009
00010
00011
00012
консультант
3215
3215
3215
3215
3462
3462
3462
3567
3567
3567
4756
7890
ДжонсГ
ДхонсГ
ДжонсГ
ДжонсГ
СмитА
СмитА
СмитА
ХаузДж
ХаузДж
ХаузДж
АлексК
ХоумерХ
120DH
120DH
120DH
120DH
238VH
238VH
238VH
120DH
120DH
120DH
345VH
121VH
2136
2136
2136
2136
2344
2344
2344
2136
2136
2136
3321
7619
МТН122
SCI120
PHY230
МТН122
МТН122
МТН123
PSY220
SCI239
EGR171
PHY141
MUS389
F84
F84
W85
W85
W84
W85
W85
W84
F84
F84
F83
1.6
2.4
2.1
2.3
2.3
3.5
3.7
3.3
3.5
1.8
4.0
0.0
. display off Сном, Сфам for Оценка < 2.0
3215 ДжонсГ
3567 ХаузДж
7890 ХоумерХ
Рис. 2.6. а - результат вставки записи с пустыми по-
полями; б - ошибочный результат выполнения запроса,
вызванный наличием пустых полей
Проблема обновления
В отношении КОНСУЛЬТАНТ большое число из-
избыточных данных. Избыточность данных всегда свиде-
свидетельствует о возможности модификации только части
требуемых данных с помощью операции обновления.
Глава 2 29
Отношение КОНСУЛЬТАНТ характеризуется как яв-
явной, так и неявной избыточностью. Явная избыточ-
избыточность заключается в том, что фамилия данного сту-
студента, номер комнаты и номер телефона могут поя-
появиться в отношении несколько раз. В экземпляре от-
отношения КОНСУЛЬТАНТ, приведенном на рис. 2.5,
номер комнаты ДжонсГ появляется четырежды. Если
она обратится к своему консультанту и сообщит ему
об изменении номера ее комнаты, то консультант бу-
будет вынужден проследить изменение этого номера во
всех четырех кортежах во избежание противоречиво-
противоречивости данных.
Неявная избыточность обнаруживается в том, что
один и тот же номер телефона имеют все студенты,
живущие в одной комнате. На рис. 2.5 телефонный
номер для комнаты 120DH появляется в сочетании с
именами ДжонсГ и ХаузДж. Допустим, ДжонсГ изве-
известит своего консультанта о том, что ее номер теле-
телефона изменен на 7777, забыв при этом сообщить о
подруге по комнате. Если консультант изменит теле-
телефонный номер только в тех кортежах, которые содер-
содержат номер телефона ДжонсГ, то правильный номер
телефона, расположенного в комнате 120DH/ будет
фактически утерян, поскольку в отношении будут
присутствовать два различных телефонных номера для
одной комнаты.
Рис. 2.7 иллюстрирует последнюю аномалию обнов-
обновления. На рис. 2.7 (а) телефонный номер для
ДжонсГ изменяется на 7777. На рис. 2.7 (б) приво-
приводится ответ dBASE II на запрос "Вывести перечень
номеров телефонов для комнаты 120DH". В ответе на
запрос содержатся два номера, что свидетельствует об
ошибке, поскольку в каждой комнате имеется один
телефон с одним телефонным номером. Обратите вни-
внимание, что dBASE II вывела на печать дублирован-
дублированные ответы на запрос. Каждый из телефонных номе-
номеров 2136 и 7777 содержится в трех различных корте-
кортежах экземпляра обсуждаемого отношения КОНСУЛЬ-
КОНСУЛЬТАНТ, и все шесть значений были распечатаны
СУБД. При программировании некоторых СУБД в
них закладывается функция подавления дублирования
в ответах- -на-запросы» если необходимость дублирова-
дублирования не оговаривается специально.
30
Необходимость проектирования баз данных
. 11st off
3215 ДхонсГ
3215 ДжонсГ
3215 ДхонсГ
3215 ДжонсГ
3462 СмитА
3462 СмитА
3462 СмитА
3567 ХаузДж
3567 ХаузДх
3567 ХаузДх
4756 АлексК
7890 ХоумерХ
. replace Тном
120DH
120DH
120DH
120DH
238VH
238VH
238VH
120DH
120DH
120DH
345VH
121VH
with 7777
OOCWlREPLACEMENTlS)
2136
2136
2136
2136
2344
2344
2344
2136
2136
2136
3321
7619
МТН122
SCI120
PHY230
МТН122
МТН122
МТН123
PSY220
SCI239
EGR171
PHY141
MUS389
F84
F84
W85
W85
W84
W85
W85
W84
F84
F84
F83
for Сфам = 'ДхонсГ'
1.6
2.4
2.1
2.3
2.3
3.5
3.7
3.3
3.5
1.8
4.0
0.0
. display off Тном for Кном
7777
7777
7777
7777
2136
2136
2136
'120DH'
б
Рис. 2.7. а - изменение номера телефона некоторого
студента, б - ошибочный результат выполнения за-
запроса, вызванный изменением номера телефона
Проблемы удаления
В экземпляре отношения КОНСУЛЬТАНТ (рис. 2.5)
присутствует только один кортеж, в котором
Сном=4756. Этот кортеж соответствует студенту с
именем АлексК. Предположим, что консультант узна-
узнает, что этот студент не закончил курс MUS389, как
это отмечено, и удаляет этот кортеж из отношения.
Поскольку это единственный кортеж с информацией
об этом студенте, его удаление приведет к исключе-
Глава 2
31
нию студента из БД. Если консультант вслед за дан-
данной операцией удаления запросит список содержащих-
ся в отношении КОНСУЛЬТАНТ имен всех консульти-
консультируемых, то имени АлексК в этом списке он не найдет.
2.4. Задачи к гл. 2
1. Найдите первичный ключ для отношения КОН-
КОНСУЛЬТАНТ, приведенного на рис. 2.5.
2. Укажите примеры данных в отношении КОНСУЛЬ-
КОНСУЛЬТАНТ (рис. 2.5), являющиеся как дублированными,
так и избыточными.
3. Указать примеры данных в отношении КОНСУЛЬ-
КОНСУЛЬТАНТ (рис. 2.5), являющиеся дублированными, но
неизбыточными.
4. Отношение ТЕЛНОМ предназначено для хранения
информации о фамилиях служащих, номерах домаш-
домашних и служебных телефонов. Каждый служащий име-
имеет уникальную фамилию, один домашний номер теле-
телефона и может иметь несколько служебных телефон-
телефонных номера. У нескольких служащих номер служеб-
служебного телефона может быть общим. Типичный экземп-
экземпляр отношения ТЕЛНОМ приведен на рис. 2.8:
а) укажите, какие данные в экземпляре отношения
ТЕЛНОМ являются избыточными;
б) как следует изменить отношение ТЕЛНОМ, чтобы
исключить избыточные данные;
в) приведите экземпляры отношений, которые Вы
предлагаете использовать с целью исключения избы-
избыточности. Воспользуйтесь данными, приведенными на
рис. 2.8.
ТЕЛНОМ
Фамилия
ДжонсКК
ДжонсКК
КрофтАД
МартцЛК
МартцЛК
РалстонТТ
РалстонТТ
Дтелном
345-1121
345-1121
345-9898
348-4512
348-4512
345-7766
345-7766
Слж_тел
3167
3168
4000
3167
3168
4001
4002
Рис. 2.8. Экземпляр отношения ТЕЛНОМГ
3. ФУНКЦИОНАЛЬНЫЕ ЗАВИСИМОСТИ
3.1. Первая нормальная форма AНФ)
В гл. 2 уже было отмечено, что составной частью
проектирования реляционной БД является процесс
разбиения отношений с неудовлетворительными свой-
свойствами (с точки зрения аномалий) на новые отноше-
отношения. В связи с этим процессом следует поставить не-
несколько вопросов.
1. Из какого источника Вы получаете отношение
(или отношения) перед началом процесса?
2. Каким образом Вы можете распознать отноше-
отношения, нуждающиеся в разбиении?
3. Каким образом Вы будете осуществлять разби-
разбиение?
4. Что является признаком завершения процесса
разбиения?
Ответы на эти вопросы будут даны в настоящей
главе и более углубленно в гл. 4.
Для БД с числом атрибутов меньшим 20 началь-
начальной точкой указанной процедуры может служить уни-
универсальное отношение. Это отношение содержит все
представляющие интерес атрибуты, и имеет структу-
структуру, в которой каждый кортеж состоит из атомарных
элементов. Это означает, что все экземпляры отноше-
отношений должны иметь форму, показанную на рис. 2.5, а
не подобную той, которая приведена на рис. 2.3.
Говорят, что отношение находится в первой нор-
нормальной форме (или 1НФ), если каждый его элемент
имеет и всегда будет иметь атомарное значение. От-
Отношение должно быть в 1НФ даже прежде постанов-
постановки вопроса о его разбиении на два или более отно-
отношения.
3.2 Концепция функциональных зависимостей
Процесс разбиения отношения с целью уменьшения
вероятности возникновения аномалий называется де-
декомпозицией. Ключевой для осуществления декомпо-
декомпозиции логическим методическим путем является кон-
Глава 3 33
цепция функциональных зависимостей между атрибу-
атрибутами в рассматриваемом отношении.
функциональная зависимость (ФЗ) определяется
следующим образом:
Если даны два атрибута А и В, то говорят, что В фун-
функционально зависит от А, если для каждого значения А су-
существует ровно одно связанное с ним значение В (в любой
момент времени). А и В могут быть составными, то есть
они могут представлять собой не единичные атрибуты, а
группы, состоящие из двух и более атрибутов.
С практической точки зрения смысл данного опре-
определения состоит в том, что если В функционально
зависит от А, то каждый из кортежей, имеющих од-
одно и то же значение А, должен иметь также одно и
то же значение В. Значения А и В могут изменяться
время от времени, но при этом они должны изме-
изменяться так, чтобы каждое уникальное значение А
имело только одно значение В, связанное с ним. ФЗ
описываются с помощью нескольких различных спосо-
способов нотации. Два наиболее часто используемых спосо-
способа показаны на рис. 3.1.
A -> В (Математическая форма записи)
(Диаграмма или графическая форма за-
записи)
Рис. 3.1. Два возможных способа записи того, что
атрибут В функционально зависит от атрибута А
В конкретной ситуации ФЗ определяется путем де-
детализации свойств всех атрибутов в отношении и вы-
выводе заключения о том, как атрибуты соотносятся
между собой. ФЗ не могут быть доказаны путем про-
простого просмотра отдельного экземпляра отношения и
нахождения двух атрибутов, имеющих те же значе-
значения в более чем одном кортеже. Это может служить
ключом к тому, в каком направлении следует вести
поиск ФЗ, но не доказательством. ФЗ необходимо по-
получить исходя из базовых свойств самих атрибутов.
34
Функциональные зависимости
В качестве примера вновь обратимся к атрибутам
в отношении КОНСУЛЬТАНТ (рис. 2.J) и, в частно-
частности, к подробному объяснению того, как эти атрибу-
атрибуты связаны между собой (разд. 2.2), После изучения
описаний атрибутов могут быть выведены зависимо-
зависимости, приведенные на рис. 3.2,
Сном-1*- Сфам
Сном -*- Кном
Кном—а^Тном
Тном-^Кном
Сном -»-Тном
Сном , Курс f Семестр
(а)
Оценка
(б)
Рис. 3.2. Различные способы представления ФЗ, суще-
существующих между атрибутами отношения КОНСУЛЬТАНТ
Соображения, приведшие к этим ФЗ, в деталях
обсуждаются ниже.
1, Номера студентов являются уникальными. Каж-
Каждому студенту назначается номер Сном, причем ice
номера различны. Таким образом, если вы знаете
Сном студента, вы знаете, что с ним может быть
связана только одна фамилия Сфам: Сном -> Сфам.
Обратное не является верным. Сфам -> Сном не
является правильной ФЗ, поскольку несколько сту-
студентов могут иметь одну фамилию.
2. Каждый студент прикреплен к одной комнате об-
общежития, но в одной комнате может проживать бо-
Глава 3 35
лее чем один студент. Таким образом, Сном ->
Кном является верным, а Кном -> Сном - нет»
3. Поскольку в каждой комнате только один теле*
фон и каждый телефон, в свою очередь, имеет уни-
уникальный номер, получаем Кном -> Тном и Тном ->
Кном, Данная ситуация обычно обозначается в виде
Сном <-> Тном, и говорят, что Сном и Тном взаи-
взаимозависимы.
4. Поскольку в каждой комнате только один теле-
телефон и этот телефон имеет уникальный номер, следо^
вательно только один телефонный номер может быть
связан с данным студентом, или иначе Сном -> Тном,
5. Последняя ФЗ представляет собой пример сложно-
сложного набора атрибутов, входящих в ФЗ. Зависимость
Сном, Курс, Семестр -> Оценка означает, что оцен-
оценка однозначно определяется только в том случае, ес-
если известен Сном студента, изучающего данный Курс
в данном Семестре. (Необходимо помнить, что сту-
студент может повторить прохождение учебного курса и
получить при этом другую оценку).
Читателю следует проверить отношение КОНСУЛЬ-
КОНСУЛЬТАНТ (рис. 2.5) и убедиться в том, что данные в
этом отношении согласуются с функциональными за-
зависимостями, представленными на рис. 3.2. Например,
отметим, что Кном * 120DH и Тном * 2136 всегда
располагаются парой (Кном <-> Тном); также
Сном*«32!5 связан только с одной фамилией, именно
"ДжонеГ", как и должно быть, поскольку Сном ->
Сфам. Другие ФЗ следует верифицировать аналогич-
аналогичным образом. Читателю следует также отметить, что
в экземпляре отношения КОНСУЛЬТАНТ, показанном
на рис. 2.5, только один номер Сном связан с каж-
каждым именем Сфам; однако это не доказывает Сфам -
> Сном, что является ложным, Это говорит только о
том, что в настоящее время нет двух консультируе-
консультируемых с одной фамилией, В будущем может случиться
так, что два студента с одной фамилией будут вклю-
включены в отношение КОНСУЛЬТАНТ,
/
3,3« Нормальная форма Бойса-Кодда (НФБК)
Опытному проектировщику БД достаточно беглого
взгляда на диаграмму, приведенную на рис. 3.2F),
36 Функциональные зависимости
чтобы сделать вывод о том, что отношение КОН-
КОНСУЛЬТАНТ нельзя считать "хорошим". Проектиров-
Проектировщик придет к такому выводу, глядя на ФЗ, получен-
полученные для отношения КОНСУЛЬТАНТ, и обращая вни-
внимание на некоторые их нежелательные свойства. Пе-
Перед обсуждением этих свойств необходимо определить
два термина, касающихся ФЗ.
1. Возможный ключ. Возможный ключ представляет
собой атрибут или набор атрибутов, который может
быть использован для данного отношения в качестве
первичного ключа. Первичный ключ всегда является
возможным ключом; однако не исключено наличие
других возможных ключей, которые могли бы быть,
но не были использованы в качестве первичного клю-
ключа.
2. Детерминант. Если А -> В есть ФЗ и В не за
висит функционально от любого подмножества А, то
говорят, что А представляет собой детерминант В.
Из рис. 3.2 можно заключить, что отношение
КОНСУЛЬТАНТ имеет только один возможный ключ,
а именно набор атрибутов <Сном,Курс,Семестр>.
Этот вывод получен путем нахождения минимального
набора значений атрибутов, которые, если они изве-
известны, определяют значения всех других атрибутов
кортежа. С помощью ФЗ, представленных на рис.
3.2, легко видеть, что один номер Сном определяет
Сфам, Кном и Тном и для определения Оценки дол-
должен быть известен весь набор Сном, Курс и Семестр.
Таким образом, если известны значения атрибутов
данного выше возможного ключа, то значения всех
других атрибутов кортежа, содержащего указанный
возможный ключ, будут однозначно специфицированы.
Детерминанты в отношении КОНСУЛЬТАНТ опре-
определить легко: ими являются левые части всех ФЗ в
отношении. Детерминантами в КОНСУЛЬТАНТ явля-
являются <Сном,Курс,Семестр>, <Сном>, <Кном> и
<Тном>. Детерминанты заключены в угловые скобки
для того, чтобы в данном случае выделить четыре
различных детерминанта. Следует заметить, что вза-
взаимные зависимости дают два детерминанта.
Одним из самых первых, но и одним из самых
важных результатов в области реляционных БД стало
Глава 3 37
доказанное Коддом утверждение о том, что большин-
большинство потенциальных аномалий в БД будет устранено
в случае должной декомпозиции каждого отношения в
нормальную форму Бойса-Кодда (НФБК). Эта форма
определяется следующим образом:
отношение находится в НФБК, если и только если каждый
детерминант отношения является возможным ключом.
Хотя существуют нормальные формы более высоко-
высокого уровня, которые накладывают даже более сильные
ограничения на разрабатываемые отношения, на прак-
практике большинство проектировщиков стараются полу-
получить отношения в НФБК. Эта цель будет преследо-
преследоваться и в предлагаемой книге.
Отношение КОНСУЛЬТАНТ не находится в
НФБК. Это легко обнаружить, если расположить ря-
рядом перечень всех детерминантов и перечень всех
возможных ключей и посмотреть, является ли каж-
каждый детерминант возможным ключом.
Возможные ключи от- Детерминанты отношени
ношения КОНСУЛЬТАНТ КОНСУЛЬТАНТ
<Сном,Курс,Семестр> <Сном,Курс,Семестр>
<Сном>
<Тном>
<Кном>
Поскольку не каждый детерминант в отношении
КОНСУЛЬТАНТ является возможным ключом, следо-
следовательно, КОНСУЛЬТАНТ не находится в НФБК и
его необходимо подвергнуть декомпозиции.
3.4. Общий подход к декомпозиции
К этому моменту все готово для общего описания од-
одного метода, определяющего, как следует осуществ-
осуществлять с помощью декомпозиции проектирование реля-
реляционных БД. Далее будет показано, что этот метод
должен быть усовершенствован для преодоления неко-
некоторых последующих затруднений.
1. Разработка универсального отношения для БД.
38 Функциональные зависимости
2* Определение всех ФЗ между атрибутами отно-
отношения.
3. Определение того* находится ли отношение в
НФБК. Если да, проектирование завершается; если
нет, отношение должно быть разложено на два от-
отношения.
4. Повторение шагов 2 и 3 для каждого нового от-
ношения, полученного в результате декомпозиции.
П|юе1стирование завершается, когда все отношения
будут находиться в НФБК»
Предложенный выше метод не определяет, как
осуществлять декомпозицию отношения, не приведен-
приведенного к НФБК, на два отношения. Это осуществляется
с помощью ФЗ следующим образом:
Пусть отношение R(A,B,C»D,E,..) не приведено к НФБК.
Определяется ФЗ, например С -> D, про которую известно»
что она является причиной того, что отношение R не нахо-
находится в НФБК. (С является детерминатом» но не является
возможным ключом.) Создаются два новых отношения:
R1(A,B,C,E,..) и R2(C,D), где зависимостная часть ФЗ была
выделена из R и опущена при формировании отношения R1
и ФЗ была использована полиостью при формировании от-
отношения R2. Теперь необходимо проверить, находятся ли в
НФБК отношения R1 и R2. Про отношение R2(C,D) гово-
говорят, что оно является проекцией отношения R. Этот тип де-
декомпозиции называется декомпозицией без потерь при есте*
ственном соединении (см. прил. В* где обсуждается данный
тип декомпозиции). Указанный метод декомпозиции может
быть использован на шаге 3 приведенного выше алгоритма
проектирования.
В качестве примера использования метода выпол-
выполним декомпозицию отношения КОНСУЛЬТАНТ. Обра-
Обращаясь вновь к детерминантам и возможным ключам
отношения КОНСУЛЬТАНТ, видим, что имеются три
детерминанта, не являющихся возможными ключами:
<Сном>, <Тном>, и <Кном>.
Началом процесса служит следующее определение
универсального отношения:
Глава 3
39
R1 (Сном, Курс, Семестр, Сфам, Кном, Оценка)
Возможные ключи
1, (Сном, Курс, Семестр )
Детерминанты
1. ( Сном , Курс. Семестр)
?. (Сном)
R2 (Тном, Кном)
Возможные ключи
1(Кном)
2.(Тном)
Детерминанты
1(Кном)
2. (Тном)
Рис. 3.3. Отношения R1 и R2, полученные в резуль-
результате проекции Кном <-> Тном из отношения КОН-
КОНСУЛЬТАНТ
КОНСУЛЬТАНТ (Сном, Курс, Семестр, Сфам, Кном,
Тном, Оценка).
Кандидатами среди ФЗ для осуществления проек-
проекции являются
Сном -> Кном; Сном -> Тном; Кном -> Тном и
Тном -> Кном.
На этом этапе должно быть принято решение, ка-
какую ФЗ следует выбрать для проведения первой про-
проекции. Не исключено, что в итоге выбора той или
иной начальной проекции будут получены различные
БД. Если это именно так, то каждая из получивших-
40 Функциональные зависимости
ся БД, вообще говоря, должна быть подвергнута ана-
анализу с целью выбора наиболее полно отвечающей
требованиям и условиям предприятия.
Простым правилом выбора ФЗ для проекции мо-
может служить поиск "цепочки ФЗ" вида
А -> В -> С
с последующим использованием для проекции крайней
правой зависимости. В нашем случае такой "цепоч-
"цепочкой" является Сном -> Кном -> Тном и "конец це-
цепочки" Кном -> Тном порождает первую проекцию.
Полученные в итоге отношения R1 и R2 приведены
на рис. 3.3 вместе с каждой из связанных с ними ФЗ.
Отношение R2(Khom,Thom) находится в НФБК,
поскольку все его детерминанты являются возможны-
возможными ключами. Отношение R2 не нуждается более в
декомпозиции. Однако отношение R1 (Сном,Курс,Се-
месц),Сфам,Кном,Оценка) не находится в НФБК, так
как детерминант <Сном> не является возможным
ключом. Следовательно отношение R1 необходимо
подвергнуть дальнейшему разложению. Детерминант
<Сном>, из-за которого возникло затруднение, имеет
два зависимых от него атрибута
Сном -> Сфам,
Сном -> Кном,
что можно рассматривать в качестве единичной ФЗ с
составной правой частью
Сном -> Сфам, Кном.
Проекция отношения R1, порождаемая этой ФЗ,
приводит к получению отношений R3 и R4, показан-
показанных на рис. 3.4. Эти два отношения находятся в
НФБК и вместе с отношением R2 могли бы исполь-
использоваться при формировании БД для консультанта. На
рис. 3.5 представлен окончательный вид отношений
для такой БД (названной Коне), а также экземпляры
каждого отношения с данными, совпадающими с ис-
использованными для исходного отношения КОНСУЛЬ-
КОНСУЛЬТАНТ. Заметим, в частности, что в процессе деком-
декомпозиции автоматически произошло разбиение исходно-
исходного отношения КОНСУЛЬТАНТ на три логических
Глава 3
41
компонента: R2, в котором содержится информация о
комнатах и телефонах; R3, в котором содержится ин-
информация об учебных курсах и полученных студента-
студентами оценках; R4, в котором содержится информация о
студентах. Такое логическое разбиение является пря-
прямым результатом использования в процессе декомпо-
декомпозиции заложенной в ФЗ информации, детализирую-
детализирующей то, как различные атрибуты в исходном отноше-
отношении соотносятся друг с другом.
R3 (Сном, Курс, Семестр, Оценка)
Возможные ключи
1. (Сном, Курс, Семестр)
Детерминанты
1(Сном, Курс, Семестр)
R4 (Сном, Сфам, Кном)
,
Сфал
Возможные ключи
1(Сном)
Детерминанты
1.(Сном)
Рис. 3.4. Отношения R3 и R4, полученные в резуль-
результате проекции Сном -> Сфам,Кном из отношения R1
3.5. Обзор исходных аномалий
Сейчас самое время задаться вопросом: присутствуют
ли в БД Коне те же аномалии, которые характеризо-
42
Функциональные зависимости
вали отношение КОНСУЛЬТАНТ, или декомпозиция
автоматически привела к их устранению? Для того
чтобы подтвердить устранение аномалий, - а именно
эта цель ставилась в первую очередь при осуществле-
осуществлении декомпозиции, - рассмотрим, опираясь на приве-
приведенную на рис. 3.5 БД Коне, проблемы вставки, уда-
удаления и обновления из разд. 2.2.
R2(Khom.Thoh)
R3(Сном.Курс.Сеиестр.Оценка)
Ш(Сном.СФам.Кном)
R3
Сном
3215
3215
3215
3215
3462
3462
3462
3567
3567
3567
4756
Курс
МТН122
SCI120
PHY230
МТН122
МТН122
МТН123
PSY220
SCI239
EGR171
PHY141
MUS389
Семестр
F84
Г84
W85
W85
W84
W85
W85
W84
F84
F84
F83
Оценка
1.6
2.4
2.1
2.3
2.3
3.5
3.7
3.3
3.5
1.8
4.0
R2
Кном
120DH
238VH
345VH
Тном
2136
2344
3321
R4
Сном
3215
3262
3567
4756
Сфам
ДхонсГ
СмитА
ХауэДж
АлексК
Кном
120DH
238VH
120DH
345VH
б
Рис. 3.5. а - база данных Коне; б - экземпляр БД, в
котором используются данные, приведенные на рис. 2.5
Вставка. Когда отношение КОНСУЛЬТАНТ слу-
служило основой БД, новый студент не мог быть в нее
включен до действительного завершения им какого-
либо курса. В БД Коне информация общего характе-
характера о консультируемых студентах хранится в отноше-
отношении R4. Как только новый студент принимается в
университет и ему отводится комната, так этот сту-
Глава 3 43
дент может быть включен в БД (в R4). Студенту
нет необходимости даже просто приступить к посеще-
посещению учебного курса для того, чтобы быть включен-
включенным в БД. Таким образом, исходная аномалия встав-
вставки исключена с помощью декомпозиции.
Обновление. При использовании отношения КОН-
КОНСУЛЬТАНТ проблема возникла на этапе изменения
консультантом номера телефона миссис ДжонсГ на
7777. Результатом этого изменения явилось появление
в БД двух различных телефонных номеров для теле-
телефона, установленного в комнате 120DH. В БД Коне
телефонные номера располагаются в отношении R2, и
каждая комната может иметь только один телефон-
телефонный номер, назначенный расположенному в этой ком-
комнате телефонному аппарату. Следует помнить, что
номер Кном является первичным ключом отношения
R2, а значения первичного ключа по определению
должны быть уникальными. Для модификации теле-
телефонного номера ДжонсГ следует в кортеже отноше-
отношения R2, в котором Khom*120DH, изменить номер Тном
на 7777. Обратите внимание на то обстоятельство,
что это действие заключается в изменении телефон-
телефонного номера для комнаты, так что для всех живущих в
этой комнате студентов телефонный номер также бу-
будет изменен. Таким образом, исходная аномалия обнов-
обновления устраняется с помощью НФБК-проектирования.
Необходимо еще раз подчеркнуть, что устранение
аномалии обновления базируется на том предположе-
предположении, что СУБД, в среде которой будет создаваться
БД, не допускает дублирования значений первичных
ключей. К сожалению, во многих СУБД, которыми
оснащаются микрокомпьютеры, допускается дублирова-
дублирование ключевых значений, и пользователь сам вынуж-
вынужден следить за этим с помощью применения соответ-
соответствующих программных методов. Это тот самый слу-
случай, когда удачное проектирование БД может быть
разрушено недостатками используемой СУБД. Полно-
Полностью реализованная СУБД не должна допускать дуб-
дублирования значений первичных ключей.
Удаление. Когда отношение КОНСУЛЬТАНТ ис-
использовалось в качестве БД, удаление кортежа, вклю-
включавшего значения Сном«4756 и Kypc*MUS389, приве-
привело к исчезновению из БД студента с номером 4756.
44 Функциональные зависимости
Этого не может произойти в случае БД Коне, по-
поскольку информация об оценках и информация о
студентах общего характера разнесена в два различ-
различных отношения (R3 и R4). При исключении факта,
что студент с номером 4756 посещал курс MUS389 в
семестре F83, из отношения R3 будет удален кортеж
<4756,MUS389,F83,4.0>. Это действие никак не ска-
скажется на общей информации о студенте, хранимой в R4.
Итак, все три аномалии, присутствовавшие в БД,
состоящей из одного отношения, устраняются при та-
таком проектировании. Результат устранения аномалий -
появление вместо одного трех требующих хранения
отношений. Это означает, что запросы, которые дол-
должны быть составлены для получения информации из
БД, возможно, станут более сложными, поскольку они
должны поддерживать прохождение цепочки из двух
или трех отношений при поиске требуемых данных.
. USE КОНСУЛЬТАНТ
. DISPLAY КУРС, ОЦЕНКА FOR СНОМ = 3462 OFF
МТН122 2.3
МТН123 3.5
PSY22O 3.7
. USE R3
. DISPLAY КУРС, ОЦЕНКА FOR СНОМ * 3462 OFF
МТН122 2.3
МТН123 3.5
PHY22O 3.7
б
Рис. 3.6. Запросы при использовании dBase II на по-
получение перечня оценок, полученных студентом с но-
номером 3462 по всем курсам: а - для отношения
КОНСУЛЬТАНТ; б - для БД Коне
На рис. 3.6 и 3.7 приведены примеры типичных
запросов при использовании пакета dBASE II - как
для случая отношения КОНСУЛЬТАНТ, так и для
случая БД Коне. Запросы на рис. 3.7 для случая БД
46 Функциональные зависимости
Внимательное изучение представленных на рис. 3.2
ФЗ показывает, что на этом рисунке присутствует
другая цепочка зависимостей с таким же их числом
Сном -> Тном -> Кном.
Здесь крайней правой ФЗ является Тном -> Кном.
Если эта ФЗ выделяется первой из отношения КОН-
КОНСУЛЬТАНТ, то в итоге будет получена следующая
БД в НФБК:
R2(Thom,Khom)
R3 (Сном,Курс,Семестр,Оценка)
Я4(Сном,Сфам)
Эта БД столь же корректна, как и БД, приведен-
приведенная на рис. 3.5. Единственное отличие состоит в том,
что номер Тном стал выполнять роль более важную,
нежели Кном. Тном в данной ситуации используется
в качестве первичного ключа для отношения R2 (а
не Кном) и атрибута, связывающего R4 и R2. Два
различных решения одной проблемы являются пря-
прямым результатом взаимной зависимости, существую-
существующей между атрибутами Тном и Кном. Какое из двух
решений является "лучшим" определяется выбором
проектировщика и зависит до некоторой степени от
того, как консультант планирует использовать БД.
3.7. Некоторые комментарии к декомпозиционному
алгоритму проектирования
В разд. 3.4 было сказано, что в процессе проектиро-
проектирования с помощью проекции декомпозицию следует
осуществлять путем поиска цепочек ФЗ, а именно:
А -> В, В -> С
с последующим проецированием, порождаемым ФЗ,
замыкающей цепочку. В данном случае первой ФЗ
будет В -> С. Другой путь обоснования процедуры
выбора состоит в утверждении, что всеми средствами
следует избегать выбора ФЗ, зависимостная част
которой сама - целиком или частично - является
детерминантом другой ФЗ.
Глава 3
47
ИСХОАНЫЕ ААННЫЕ
Отношение; R(A,B,C)
ФЗ
: А -> В
В -> С
(А -> С также должно быть справедливо)
ОАИН ВОЗМОЖНЫЙ ПРОЕКТ
R1(A,C) R2(A,B)
А -> С А -> В
Корректные экземпляры R1 и R2
Rl R2
А
9
8
С
4
3
А
9
8
В
2
2
СОЕДИНЕНИЕ (JOIN) Rl и R2
А
9
8
В
2
2
С
4
3
Рис, 3.8, Экземпляры отношений, удовлетворяющие
ФЗ отношений R1 и R2, но противоречащие ФЗ,
представленной в исходных спецификациях
Если в вышеприведенном случае положить, что об-
обсуждаемое отношение имеет вид Я(А,В,С)иФЗ А->В
выбрана для проекции в первую очередь, то получен-
полученные в результате отношения будут R1(A,C) и
R2(A,B), Хотя оба эти отношения находятся в
48 Функциональные зависимости
НФБК, со всей отчетливостью обнаруживается следу-
следующая проблема:
Ни отношение R1(A,C), ни R2(A,B) автономно не содержат
атрибуты, присутствующие в ФЗ В -> С, которая является
ФЗ исходного отношения. Эта зависимость утеряна в процессе
проектирования. С практической точки зрения это означает,
что если приведенные выше отношения R1 и R2 будут исполь-
использованы для создания БД, то нельзя будет утверждать, что не-
некорректные связи между В и С не будут привнесены в БД.
Рис. 3.8 иллюстрирует выявленную проблему. При соединении
R1 и R2 по атрибуту А два значения С C и 4) могут быть
соотнесены с В, что противоречит ФЗ, утерянной в процессе
проектирования.
Проблема в данном примере возникает из-за про-
проекции, порожденной ФЗ, зависимостная часть которой
сама является детерминантом другой ФЗ. При исполь-
использовании правила цепочки эта проблема не возникает.
Другим случаем возможной потери ФЗ в процессе
проектирования является ситуация, в которой один
атрибут зависит от двух различных детерминантов.
Пусть для отношения R(A,B,C) определены зависимо-
зависимости, показанные на рис. 3.9.
Рис. 3.9. Два детерминанта с одним и тем же зави-
зависимым атрибутом
Это отношение не находится в НФБК, так как
имеется только один возможный ключ <А,С>, в то
время как детерминантами являются <А> и <С>.
Правило цепочек здесь неприложимо по причине их
отсутствия. Кроме того, если одна из ФЗ будет выде-
выделена обычным способом, то другая будет потеряна.
Например, при выделении из R(A,B,C) зависимости
А -> В будут получены отношения R1(A,C) и
R2(A,B), ни одно из которых не будет содержать за-
зависимости С -> В. Наоборот, при первоочередном
выделении С -> В будет утеряна зависимость А -> В.
Возникла ситуация, обязывающая проектировщика
найти способ разбиения отношения R(A,B,C) на
Глава 3 49
R1(A,B) и R2(C,B), не приводящий к утере ни одной
ФЗ. Этот путь не соответствует стандартному методу
декомпозиции, но может привести к лучшему резуль-
результату. Единственное, что может сделать проектиров-
проектировщик, столкнувшись с указанной ситуацией, это про-
проверить три возможных набора отношений и оценить,
какой из трех наиболее соответствует нуждам пред-
предприятия. В частности, полученные в последнем слу-
случае отношения необходимо проверить на предмет воз-
возникновения проблем в случае соединения двух итого-
итоговых отношений при поиске данных на этапе эксплуа-
эксплуатации окончательного варианта базы.
Второй метод разбиения отношения, обсуждение
которого велось с привлечением рис. 3.9, хотя и ос-
основан на подходе к проектированию, отличном от де-
декомпозиции, тем не менее используется многими про-
проектировщиками. В основе подхода, называемого неко-
некоторыми методом синтеза, лежит утверждение (в
своей простейшей форме), что необходимо все ФЗ с
одинаковыми детерминатами выделять в группы и
каждой группе отводить свое собственное отношение.
Получаемые отношения проверяются на их соответст-
соответствие НФБК. В последнем примере были две зависимо-
зависимости с различными детерминантами. Согласно методу
синтеза каждой ФЗ следует выделить ее собственное
отношение - R1(A,B) и R2(C,B). Метод синтеза мо-
может быть использован как самостоятельно, так и в
сочетании с методом декомпозиции. В книге акцент
делается на метод декомпозиции (также называемый
методом проекции), а метод синтеза используется как
альтернатива при поиске выхода из затруднительных
ситуаций, подобных разобранной выше. Как будет по-
показано в гл. 5, зависимости, сходные с той, которая
приведена на рис. 3.9, могут возникнуть в жизнен-
жизненных ситуациях реального мира.
Тот факт, что существуют различные методы про-
проектирования, которые могут быть использованы как
порознь, так и до некоторой степени смешанным об-
образом, свидетельствует о том, что проектирование БД
является частично наукой, а частично искусством.
Возможность развития нескольких вполне "законных"
проектов, имеющих общую исходную точку, является
неотъемлемым фактором области проектирования БД.
Часть процесса проектирования заключается в оценке
50
Функциональные зависимости
нескольких альтернатив с целью выявления наиболее
отвечающей нуждам предприятия.
0-R5
R<A,B,C,D)
(а)
R<A,B,C>
0
0
R(A,B,C>
(б)
R(K,X,Y,Z)
(Г)
0
-©
-0
R(A,B,C,D,E)
(е)
Рис. 3.10. Данные к задаче 1
3.8. Задачи к гл. 3
1. На рис. 3.10 приведены диаграммы функциональ-
функциональных зависимостей для нескольких отношений. Для
Глава 3 51
каждого отношения требуется определить все детерми-
детерминанты и все возможные ключи. Определите те отно-
отношения, которые находятся в НФБК. Если отношение
не в НФБК, приведите его к нормальной форме, ис-
используя алгоритм декомпозиции.
2. Определите функциональные зависимости между
атрибутами отношения ТЕЛ НОМ, рассмотренного в
задаче 4 в конце гл. 2.
3. Руководство супермаркета желает разработать БД,
предназначенную для хранения информации о счетах
покупателей. Информация, касающаяся каждого поку-
покупателя, должна включать в себя следующее: номер
счета, фамилию, адрес, номер телефона, кредитоспо-
кредитоспособность (высокая, средняя, низкая, слабая) и сведе-
сведения об уплате налогов. Изобразите диаграмму ФЗ,
используя соответствующие атрибуты и выделяя сде-
сделанные предположения. Получите для БД отношения
в НФБК.
4. Секретарь государственного учреждения проектиру-
проектирует БД, предназначенную для хранения информации
обо всех автомобилях, зарегистрированных в штате.
Информация, хранение которой предполагается, вклю-
включает в себя регистрационный номер, номер лицензии,
марку, адрес владельца, название страховой компа-
компании, номер страхового полиса, округ, в котором заре-
зарегистрирован автомобиль, и дату последней регистра-
регистрации. Разработайте диаграммы ФЗ для соответствую-
соответствующих атрибутов.
4. НЕКОТОРЫЕ МОДИФИКАЦИИ АЛГОРИТМА
ПРОЕКТИРОВАНИЯ
4Л. Избыточные функциональные зависимости
Алгоритм проектирования БД, описанный в общих
чертах в разд. 3.4, кажется на первый взгляд доволь-
довольно естественным, однако он не свободен от некоторых
внутренних проблем. Одна проблема заключается в
том, что процесс декомпозиции может осложниться в
результате присутствия избыточных ФЗ.
Зависимость, не заключающая в себе такой инфор-
информации, которая не могла бы быть получена на осно-
основе других зависимостей из числа использованных при
проектировании БД, называется избыточной ФЗ. По-
Поскольку избыточная ФЗ не содержит уникальной ин-
информации, она может быть удалена из набора ФЗ
без отрицательного воздействия на результаты. Избы-
Избыточные ФЗ удаляются на начальном этапе проектиро-
проектирования до применения алгоритма декомпозиции.
4.2. Транзитивные зависимости
Одним из простейших путей появления в наборе ФЗ
избыточных зависимостей является генерация ФЗ с
помощью концепции транзитивной зависимости. Транзи-
Транзитивная зависимость определяется следующим образом
Если А -> В и В -> С, то А -> С - транзитив-
транзитивная зависимость.
Два момента следует подчеркнуть. Во-первых, транзи-
транзитивная зависимость А -> С, приведенная в определе-
определении выше, является вполне корректной зависимостью.
С ней не связано ничего сомнительного. Во-вторых,
если А -> В, В -> С и А -> С входят в набор ФЗ,
следовательно, А -> С является избыточной и ее ис-
использование в процессе проектирования не требуется.
Действительно, транзитивная зависимость А -> С
причинит больше вреда, чем пользы при проектирова-
проектировании, и ее следует исключить из набора перед нача-
началом проектирования.
Глава 4
53
На рис. 4.1 приведены примеры того, как может
быть упрощен набор ФЗ при помощи исключения
транзитивных зависимостей. На рис. 4.1 (а) представ-
представлен исходный набор ФЗ до начала проектирования. На
рис. 4.Кг) показан набор неизбыточных ФЗ, выделен-
выделенных путем удаления всех транзитивных зависимостей
из исходного набора. На рис. 4.2 показана процедура
декомпозиции и получения набора НФБК-отношений.
(а) Исходный набор ФЗ
(б) А->> Е удалена, т. к. А-»С и С -»• Е
(в) В -*- Е удапена т. к. В-^С и С -»► Е
(г) А^С удалена, т.к. А-> В и В-*С и в
итоге получен неизбыточный набор ФЗ
A -> В
A -> С
A -> E
В -> С
В -> Е
С -> Е
А -> В
А -> С
В -> С
В -> Е
С -> Е
А -> В
А -> С
В -> С
С -> Е
А ->
В ->
С ->
Рис. 4.1. Удаление транзитивных зависимостей
54 Некоторые модификации алгоритма проектирования
1.Диаграмма ФЗ при отсутствии избыточности
R<A,B,C,E)
2.Извлечение зависимости С -*• Е, так как она является последней в цепочке
R1(С,Е>
R2tA,B,C>
З.Извлечение В^С из R2 (А, В, С)
RI(C,E)
R3 < В,С)
R4(A,B)
Отношения R1, R3 и R4 находятся в НФБК. При небольшом навыке НФБК
— отношения из части 3 могут быть непосредственно получены из части 1.
Рис. 4.2. Получение набора НФБК-отношений из от-
отношения, приведенного на рис. 4.1
4.3. Добавление1) атрибутов в ФЗ
Второй путь возникновения избыточных ФЗ связан с
концепцией добавления. Эта форма избыточности
имеет несколько видов, из которых только два самые
простые, но и крайне полезные, обсуждаются ниже.
Вид первый формулируется следующим образом
(здесь А, В и Z - атрибуты, каждый из которых мо-
может быть составным):
Если А -> В, то A,Z -> В является корректной,
но избыточной ФЗ. Атрибут Z был добавлен к детер-
^ Мы приняли перевод термина "augmentation" как "добавление".
В отечественной литературе используется также термин "пополне-
"пополнение*4. - Прим. ред.
Глава 4
55
минанту А без привнесения какой-либо новой инфор-
информации в процесс проектирования.
Второй вид возникает в случае добавления к обе-
обеим частям данной ФЗ одного и того же атрибута с
целью формирования новой зависимости:
Если А -> В, то A,Z -> B,Z является корректной,
но избыточной зависимостью.
На рис. 4.3 приведены примеры обеих форм до-
добавления.
(а)
Добавление ФЗ
(избыточная)
Добавление ФЗ
(избыточная)
(б!
Рис. 4.3. Примеры добавления
4.4. Правила вывода
Определения транзитивной зависимости и концепции
добавления, данные выше, касаются двух правил вы-
вывода из имеющихся шести. Эти правила могут быть
использованы для уменьшения, модификации исходно-
56 Некоторые модификации алгоритма проектирования
го набора ФЗ и получения другого, эквивалентного
ему набора ФЗ. Еще три правила вкратце рассматри-
рассматриваются ниже. Полное описание всех правил можно
найти в большинстве более фундаментальных книг1).
Два наиболее простых для понимания правила вы-
вывода связаны с объединением и декомпозицией ФЗ,
которые определяются следующим образом:
Объединение ФЗ: если А->В и А->С, то А->В,С
Декомозиция ФЗ: если А->В,С то А->В и А->С
На рис. 4.4 дается графическое представление
каждого утверждения, рис. 4.5 иллюстрирует способы
преобразования исходного набора ФЗ в менее слож-
сложный набор неизбыточных ФЗ с помощью процедур
объединения, декомпозиции и добавления.
Последнее из обещанных правил вывода называет-
называется псевдотранзитивностью.
Если X -> Y и Y,W -> Z, то X,W -> Z является
избыточной в силу псевдотранзитивности.
Графический пример на псевдотранзитивность при-
приведен на рис.4.6. Этот тип избыточности возникает в
тех случаях, когда в получаемых ФЗ обнаруживаются
составные детерминанты. Конкретный пример, иллюст-
иллюстрирующий данную ситуацию, будет приведен в следу-
следующей главе при рассмотрении учебной БД.
Для большинства людей графические формы диаг-
диаграмм зависимостей упрощают выявление избыточных
ФЗ; однако в тех случаях, когда число атрибутов и
ФЗ достаточно велико, графический подход может
оказаться слишком громоздким. В этом случае можно
воспользоваться каким-либо известным математиче-
математическим алгоритмом поиска избыточных зависимостей.
Эти алгоритмы не слишком сложны для применения.
^ Полное множество правил вывода состоит из трех аксиом Армст-
Армстронга - рефлексивности (для любого множества атрибутов А и X
АХ -> X) и уже обсуждавшихся транзитивности и дополнения, а
также трех следующих из этих аксиом правил объединения, деком-
декомпозиции и псевдотранзитивности, которые автор обсуждает ниже.
Более подробную информацию о свойствах правил вывода можно
найти, например, в книге Дж. Ульмана "Основы систем баз дан-
данных" - М., Финансы и статистика, 1983, с. 156-164. Прим. ред.
Глава 4
57
ЕСЛИ :
то:
С
Фамилия
потребителя
ЕСЛИ:
ТО:
F)
Рис. 4.4. Примеры на объединение и декомпозицию
4.S. Минимальное покрытие
Набор неизбыточных ФЗ, полученный путем удаления
всех избыточных ФЗ из исходного набора с помощью 6
правил вывода, называется минимальным покрытием.
58
Некоторые модификации алгоритма проектирования
А -> В,С
А -> D
А -> К
К -> С
В -> D
В,С -> D
(а) Исходный набор ФЗ
(б) В, C-s*D удалена (добавление
А -> В,С
А -> D
А -> К
К -> С
В -> D
А -> В
А -> С
А -> D
А -> К
К -> С
В -> D
(в) А->► В, С замещена А-> В & А->С (декомпозиция)
А -> В
А -> К
К -> С
В -> D
(г) А^-С иА->0 заменяется на А -» К &
-»D (транзитивность)
и А-*-В & В
Рис. 4.5. Упрощение диаграммы ФЗ с помощью пра-
правил вывода
К сожалению, минимальное покрытие не всегда явля-
является уникальным, поскольку порядок, в котором осу-
осуществляется процедура удаления избыточных ФЗ,
Глава 4
59
жет оказать влияние на полученное минимальное по-
покрытие. Чтобы убедиться в этом, читателю достаточ-
достаточно обратиться к рис. 3.2 и проверить, что в пред-
представленном случае проектирования существуют два
минимальных покрытия. Первое минимальное покры-
покрытие получается при удалении из исходного набора за-
зависимости Сном -> Тном, а второе - при удалении
Сном -> Кном. Использование этих двух минималь-
минимальных покрытий ведет к построению тех же самых
двух БД, проектирование которых обсуждалось выше.
В заключение следует подчеркнуть один важный мо-
момент, связанный с удалением избыточных ФЗ из ис-
исходного набора: избыточные ФЗ следует удалять по
одной, каждый раз заново анализируя новый набор
на предмет присутствия в нем избыточных ФЗ.
Псевдотрэнзитивная ФЗ
(избыточная)
(а)
Псевдотранзитивная ФЗ
(избыточная)
Рис. 4.6. Графические примеры на псевдотранзитивность
Эта процедура завершается, как только не останется
ни одной избыточной ФЗ, оставшийся набор является
минимальным покрытием.
60 Некоторые модификации алгоритма проектирования
4.6. Пересмотренный алгоритм проектирования
Следующий обобщенный алгоритм декомпозиции будет
использоваться до конца книги:
1. Построение универсального отношения для БД.
2. Определение всех ФЗ, существующих между ат-
атрибутами универсального отношения.
3. Удаление всех избыточных ФЗ из исходного на-
набора ФЗ с целью получения минимального покрытия.
Эта процедура проводится путем поочередного удале-
удаления избыточных ФЗ с последующей проверкой полу-
получаемого на каждом шаге набора ФЗ на наличие хотя
бы одной избыточной ФЗ.
4. Использование ФЗ из минимального покрытия
для декомпозиции универсального отношения в набор
НФБК-отношений. Далее должен быть применен алго-
алгоритм декомпозиции, описанный в разд. 3.4.
5. Если может быть получено более чем одно ми-
минимальное покрытие, осуществляется сравнение ре-
результатов, полученных на основе различных мини-
минимальных покрытий, с целью определения варианта,
лучше других отвечающего требованиям предприятия.
При использовании алгоритма декомпозиции (Шаг 4)
следует помнить о нежелательности проекции, порож-
порождаемой ФЗ, у которой зависимостная часть является
детерминантом другой ФЗ; также повышенное внима-
внимание требуется в тех случаях, когда зависимостная
часть ФЗ зависит более чем от одного детерминанта.
В любом из этих случаев может быть утеряна ФЗ из
БД. Если в процессе декомпозиции достигнуто состоя-
состояние, в котором проецирование, невлекущее за собой
потерь ФЗ, становится невозможным, проектировщик
должен будет сделать выбор из двух альтернатив: A)
выбор оставшихся ФЗ и создание одного отношения
для каждых детерминанта и набора зависящих от не-
него атрибутов; B) изменение порядка ранее проведен-
проведенных декомпозиций, ведь алгоритм проектирования не
ведет к единственному решению.
Глава 4 61
4.7. Проверка отношений на завершающей фазе их
проектирования
После завершения разработки НФБК-отношений, рас-
рассматриваемых уже в качестве окончательного проекта,
полученный набор необходимо проконтролировать на
предмет наличия невыявленных проблем.
1. Составляются списки ФЗ для каждого отноше-
отношения. Эти списки проверяются по двум направлениям:
во-первых, одна и та же ФЗ не должна появляться
более чем в одном отношении; и во-вторых, набор
ФЗ, полученный в результате проектирования, дол-
должен в точности совпадать с набором, присутствующим
в минимальном покрытии, полученном перед началом
проектирования. В противном случае, необходимо по-
показать возможность получения итогового набора ФЗ
из минимального покрытия с помощью правил выво-
вывода. Если хотя бы одна из этих проверок окажется
недостоверной, следует проанализировать процесс про-
проектирования для выявления ошибок и/или рассмот-
рассмотреть другие варианты проектирования.
2. Осуществляется проверка на присутствие избы-
избыточных отношений. Отношение является избыточным,
если (а) все атрибуты в избыточном отношении мо-
могут быть найдены в одном другом отношении проект-
проектного набора; (б) все атрибуты в избыточном отноше-
отношении могут быть найдены в отношении, которое может
быть получено из других отношений предложенного
проектного набора с помощью серии JOIN-операций
над этими отношениями. Если устанавливается избы-
избыточность отношения, его следует исключить из проект-
проектного набора. Примеры обоих типов избыточных отно-
отношений приведены ниже.
Для примера, иллюстрирующего первый тип из-
избыточности, полагаем, что набор проектных отноше-
отношений имеет вид:
R1(A,B)
R2(B,C,Y,Z)
R3(A,B,K)
Отношение R1 является избыточным, так как все его
атрибуты присутствуют в отношении R3.
62 Некоторые модификации алгоритма проектирования
Для иллюстрации избыточности второго типа поло-
положим, что предлагаемый проектный набор имеет вид:
R1(A,C,X)
R3(D,K,F)
R5(D,E,G,H)
R7(A,B,D)
R8(A,B,E,G)
Отношение R8 является избыточным, так как приме-
применение операции JOIN над R5 и R7 (общим атрибу-
атрибутом является D) дает в результате отношение
R9(A,B,D,E,G,H), которое содержит все атрибуты,
присутствующие в R8.
3. Рассмотрение отношений с практической точки
зрения. Изучается характер использования отношений
в конструируемой БД и определяется будут ли они
поддерживать те типы запросов и операций обновле-
обновления, которые предполагается использовать.
4.8. Задачи к гл. 4
1. Представьте каждую ФЗ, показанную на рис. 4.7, в
математической форме так, как это сделано на рис. 4.1.
Затем шаг за щагом редуцируйте диаграмму посредст-
посредством удаления всех транзитивных зависимостей.
Рис. 4.7. Диаграмма ФЗ для задачи 1
2. На рис. 4.8 идентифицируйте все ФЗ, избыточ-
избыточность которых является следствием добавления.
3. Может ли диаграмма, представленная справа на
рис. 4.9, быть получена из диаграммы, представлен-
представленной в левой части того же рисунка, с помощью пра-
правил вывода, обсуждавшихся в настоящей главе?
Глава 4
63
Рис. 4.8. Диаграмма ФЗ для задачи 2
Рис. 4.9. Диаграмма ФЗ для задачи 3
4. Предположим, что в результате проектирования
были получены следующие четыре НФБК-отношения:
К1(Слж-Фам,Слж-адрес,Возраст,Пол,Начальник-Фам)
1£2(Начальник-фам, Отдел)
R3 (Слж-фам, Отдел)
R4 (Отдел, Отдел-Тел-номер,Отдел-адрес)
Одно из этих отношений является избыточным.
Укажите это отношение и поясните причину.
5. Если перечисленные в задаче 4 отношения нахо-
находятся в НФБК, то какие из следующих утверждений
являются истинными и какие ложными? Дайте обос-
обоснование сделанных выводов:
64 Некоторые модификации алгоритма проектирования
а) служащий может иметь более одного руководителя;
б) служащий может работать только в одном отделе;
в) в каждом отделе имеется только один телефон;
г) отделу выделяется только один телефонный номер;
д) у каждого руководителя имеется телефон;
е) служащие, не являющиеся руководителями, не
имеют телефонов.
5, УЧЕБНЫЙ ПРИМЕР ПРОЕКТИРОВАНИЯ БД
Ставится задача спроектировать БД для секретаря ке-
кегельной лиги небольшого городка, расположенного на
Среднем Западе. В ней секретарь будет хранить всю
информацию, относящуюся к кегельной лиге, а сред-
средствами СУБД - формировать еженедельные отчеты о
состоянии лиги. Специальный отчет предполагается
формировать в конце сезона. БД будет реализована
как в dBASE III, так и в Rrbase 5000. Полное опи-
описание данных, доступ к которым хочет иметь секре-
секретарь при формировании отчетов, дается в следующих
разделах.
5.1. Постановка задачи
Секретарю понадобятся имена-и-фамилии, телефонные
номера, и адреса всех игроков лиги. Так как в лигу
могут входить только жители городка, нет необходи-
необходимости хранения для каждого игрока названия города
и ZIP-кода. Интерес представляют число набранных
очков каждым игроком в еженедельной серии из трех
встреч, в которых он принял участие, и его текущая
результативность (среднее число набираемых очков в
одной встрече). Секретарю необходимо знать для
каждого игрока название команды, за которую он вы-
выступает, и имя-и-фамилию капитана каждой команды.
Помимо названия секретарь планирует назначить
каждой команде уникальный номер.
Исходные значения результативности каждого иг-
игрока необходимы как при определении в конце сезо-
сезона игрока, достигшего наибольшего прогресса в лиге,
так и при вычислении гандикапа для каждого игрока
на первую неделю нового сезона. Лучшая игра каж-
каждого игрока и лучшие серии потребуются при распре-
распределении призов в конце сезона.
Секретарь планирует включать в еженедельные от-
отчеты информацию об общем числе набранных очков
и общем числе проведенных игр каждым игроком -
эта информация используется при вычислении их те-
текущей результативности и текущего гандикапа. Ис-
Используемый в лиге гандикап составляет 75% от раз-
разности между 200 и результативностью игрока, при
5-1164
66 Учебный пример проектирования БД
этом отрицательный гандикап не допускается. Если
результатом вычисления гандикапа является дробная
величина, то она усекается. Перерасчет гандикапа
осуществляется каждую неделю.
На каждую неделю каждой команде требуется на-
назначать площадку, на которой она будет выступать.
Эту информацию не нужно хранить в БД (Соперники
выступают на смежных площадках).
Наконец, в БД должна содержаться вся информация,
необходимая для проведения вычислений по получе-
получению положения команд. Команде засчитывается одна
победа за каждую игру, в которой ей удалось на-
набрать больше очков (выбить больше кеглей) (с уче-
учетом гандикапа), чем команде соперников. Точно так-
также команде засчитывается одно поражение за каждую
встречу, в которой эта команда выбила меньшее чис-
число кеглей, чем команда соперников. Команде также
засчитывается одна победа (поражение) в случае, ес-
если по сравнению с командой соперников ею набрано
больше (меньше) очков за три встречи, состоявшиеся
на неделе. Таким образом на каждой неделе разыгры-
разыгрывается 4 командных * очка (побед или поражений). В
случае ничейного результата каждая команда получа-
получает 1/2 победы и 1/2 поражения. В случае неявки бо-
более чем двух членов команды, их команде автомати-
автоматически засчитывается 4 поражения, а команде сопер-
соперников - 4 победы. В общий результат команде, кото-
которой засчитана неявка, очки не прибавляются даже
если явившиеся игроки в этой встрече выступили; од-
однако в индивидуальные показатели - число набран-
набранных очков и проведенных встреч - будут внесены со-
соответствующие изменения.
5Л, Определение атрибутов универсального отношения
В результате нескольких обсуждений с участием сек-
секретаря в качестве наиболее вероятных кандидатов на
включение в универсальное отношение были опреде-
определены перечисленные ниже атрибуты (а также накла-
накладываемые ограничения). Описание каждого атрибута
сопровождается как коротким описательным именем,
подходящим для использования при реализации БД,
так и еще более короткой двухсимвольнои мнемони-
мнемоникой, могущей быть использованной в диаграммах ФЗ.
Глава 5
Двухсимвольный формат выбран для того, чтобы из-
излишне не перегружать ФЗ-диаграммы, сохраняя при
этом до некоторой степени мнемонику источника воз-
возникновения атрибута.
Атрибут
Комментарий
Nb: Tnumb (НомКоманды) Номер команды. Коман-
Команды нумеруются последовательно, начи-
начиная с номера 1.
Tn: Tname (НазвКоманды) Название команды.
Каждая команда лиги носит название,
например, "PinBusters". Названия уни-
уникальные.
Bn: Bname (ФамИгрока) Фамилия-и-имя игрока.
Так как лига маленькая, предполагает-
предполагается, что не может быть двух игроков р
одинаковыми именем-и-фамилией.
Av: Bavg
Hk; Hndk
Bg: Bgame
Wn:
Ls:
Tp:
Ln:
Wins
Loss
Tpins
Lane
Результативность данного игрока. Этот
показатель вычисляется по формулу
число выбитых кеглей/число встреч,
имевших место до настоящего момента.
Полученное значение усекается до целого.
Гандикап игрока перед каждой игрой.
Это целое число, перерасчет которого
осуществляется каждую неделю.
Общее число встреч, в которых участ-
участвовал игрок к настоящему моменту,
Обычно каждый игрок проводит три
встречи за один вечер.
Общее число побед данной команды за
сезон.
Общее число поражений данной коман-
команды за сезон.
Общее число набранных данной коман-
командой очков за сезон.
(Площадка) Номер площадки, назна-
назначенной данной команде на данную не-
68
Учебный пример проектирования БД
Ср: Captn
Ph: Phone
St: Stret
делю. Этот номер также определяет и
соперника. Соперниками будут команды,
которым назначены площадки с номера-
номерами 1 и 2, 3 и 4, и т.д.
(Капитан) Фамилия-и-имя капитана
команды. В каждой команде только
один капитан.
(ТелНомер) Номер телефона игрока.
Несколько игроков могут иметь один
номер телефона.
(Адрес) Улица, по которой проживает
игрок. Все адреса относятся к одному
небольшому городку. По одному адресу
может проживать более чем один игрок.
Общее число очков, набранных игроком
за сезон.
(Результативность) Результативность
игрока на начало сезона. Может быть
только целым числом.
Число набранных очков во встрече,
лучшей в сезоне для данного игрока.
Число набранных очков в серии из
трех встреч, лучшей в сезоне для дан-
данного игрока.
(Неделя) Порядковый номер недели в
сезоне. Это значение вначале равно 1 и
увеличивается на 1 каждую неделю.
(Игра!) Число набранных игроком оч-
очков в первой встрече недели.
(Игра2) Число набранных игроком оч-
очков во второй встрече недели.
(ИграЗ) Число набранных игроком оч-
очков в третьей встрече недели.
После некоторых размышлений было решено, что
некоторые из перечисленных выше атрибутов в БД
Вр:
Sa:
Hg:
Hs:
Bpins
Stavg
Higam
Hiser
Wk: Week
Gl:
G2:
G3:
Gamel
Game2
Game3
Глава 5 69
храниться не будут. Исключенными атрибутами явля-
являются: Bavg, Bgame, Wins, Loss, Tpins, Bpins, Hndk,
Higam и Hiser. Хотя все эти элементы относятся к
тем, которые должны появляться как в еженедель-
еженедельных, так и в сезонных отчетах, их значения могут быть
вычислены на основе других атрибутов, хранимых в БД.
Если бы все предназначенные для исключения
элементы, перечисленные выше, были бы включены в
БД, то порождаемый ими вид избыточности информа-
информации привел бы к серьезным проблемам при обновле-
обновлении данных. Например, допустим, что все перечис-
перечисленные элементы, предназначенные для исключения,
действительно заносятся в БД и обнаруживается
ошибка в числе набранных очков в какой-либо встре-
встрече одним из игроков. Изменение этого числа потре-
потребует изменения как Bpins, так и Tpins, и возможно,
всех других элементов, предназначавшихся для иск-
исключения. Если эти изменения не будут сделаны, БД
потеряет непротиворечивость. По этой причине пред-
предназначенные для исключения элементы не будут хра-
храниться в БД, а будут вычисляться на основании име-
имеющихся в ней данных всякий раз при формировании
отчетов. Эти вычисления будут осуществляться с по-
помощью специальных прикладных программ, составлен-
составленных с использованием макроязыка СУБД. Обсуждают-
Обсуждаются эти макросы в главах 9 и 10.
Шаг 1 пересмотренного алгоритма проектирования,
приведенного в разделе 4.5, представляет собой опре-
определение универсального отношения проектируемой БД.
После сведения воедино окончательного списка атри-
атрибутов, использование которого предполагается в БД
секретаря лиги, универсальное отношение формально
может быть определено следующим образом:
R(Nb,Tn,Bn,Ln,Cp,Ph,St,Sa,Wk,Gl,G2,G3)
5.3. Диаграммы функциональных зависимостей
Шаг 2 пересмотренного алгоритма проектирования со-
состоит в определении всех ФЗ между атрибутами уни-
универсального отношения. На рис. 5.1 показана диаг-
диаграмма функциональных зависимостей (диаграмма ФЗ)
универсального отношения, полученная на основании
сформулированной проблемы.
Учебный пример проектирования БД
Уже Исключенные
Транзитивные Зависимости
Вп -> Тп
Вп -> Ср
Ln.Wk -> Ср
Ln.Wk -> Тп
Исходный Набор
Проектных ФЗ
Тп <—> Nb
Тп <--> Ср
Ср <--> Nb
Вп -> Nb.St.Ph.Sa
Bn.Wk -> Gl,G2,G3,Ln
Ln,Wk -> Nb
Wk.Nb -> Ln
Рис. 5.1. Исходная диаграмма ФЗ для БД секретаря
кегельной лиги,
На шаге 3 алгоритма осуществляется исключение
йсех избыточных ФЗ из набора, определенного для
универсального Отношения, с целью получения мини-
минимального покрытия. Представленные на диаграмме
<рис. 5Л) ФЗ включают в свой состав несколько
транзитивных зависимостей. Другие транзитивные за-
зависимости могут быть легко получены из исходйого
набора ФЗ. Типичные транзитивные зависимости, ко-
которые могут появиться, перечислены на рис. 5Л в
Глава 5
71
графе уже исключенных зависимостей. Они не были
включены в ФЗ-диаграмму единственно по причине
удобства представления. Удаление этих избыточных
зависимостей возможно в любом порядке.
R(Nbfin,Ln,Cp,PhrSt,Sa,Vk,Gl,G2,G3)
ФЗ: Nb <--> Тп
Nb <—> Ср
Wk.Ln -> Nb
Wk.Nb -> Ln
Bn.Wk -> G1,G2,G3
Bn -> Nb,St,Ph,Sa
Рис. 5.2. Диаграмма ФЗ для минимального покрытия
К числу нестандартных ситуаций, касающихся
транзитивных зависимостей, относится случай "цикли-
"циклического набора взаимных зависимостей" между тремя
атрибутами Ср, Nb и Тп
Nb <--> Ср
Ср <--> Тп
Тп <--> Nb
При исключении одной из этих трех взаимных за-
зависимостей оставшиеся две перестают быть избыточ-
72 Учебный пример проектирования БД
ными. В этом особом случае непринципиально, какая
из трех зависимостей удаляется, так как вне зависи-
зависимости от выбора, три атрибута Ср, Nb и Тп сохра-
сохраняют свое место в том же отношении и все три бу-
будут для этого отношения возможными ключами. В
нашем случае удаленной взаимной зависимостью яв-
является Ср <—> Тп.
Вторая избыточная ФЗ, отмеченная на рис. 5.1,
обусловлена псевдотранзитивностью. Так как Bn -> Nb
и Nb,Wk -> Ln, то согласно правилу псевдотранзи-
псевдотранзитивности, Bn,Wk -> Ln. Это означает, что последняя
ФЗ является избыточной и может быть удалена. Дру-
Других избыточных ФЗ на рис. 5.1 нет. ФЗ-диаграмма
для минимального покрытия приведена на рис. 5.2.
5,4, Получение путем редукции набора
НФБКотношений
Шаг 4 процедуры проектирования включает в себя
переход с помощью редукции от универсального отно-
отношения к набору НФБК-отношений. Универсальное от-
отношение R, чья ФЗ-диаграмма приведена на рис. 5.2,
не находится в НФБК. Сравнение возможных ключей
и детерминантов отношения R показывает их несов-
несовпадение.
Возможные ключи в R Детерминанты в R
<Bn,Wk> <Bn>
<Bn,Wk>
<Ln,Wk>
<Nb>
<Tn>
<Cp>
В начальной фазе редукции отношения R выпол-
выполняется проецирование универсального отношения, по-
порождаемое всеми ФЗ, содержащими атрибут Nb в ка-
качестве детерминанта. Такими ФЗ являются
Nb <--> Ср
Nb <-> Тп
результатом операции является получение отношений
R1 и R2, показанных на рис. 5.3.
Глава 5
73
(a)Rl(Bn,Wk,Ln,Nb,St,Ph,Sa,Gl,G2,G3)
ФЗ:
Nb <--> Tn
Nb <--> Cp
F) R2(Nb,Tn,Cp)
Рис. 5.3. Результаты проекции R2 из R
Отношение R2 находится в НФБК, так как Ср,
Nb и Тп являются единственными детерминантами в
R2 и каждый - возможный ключ. Таким образом, от-
отношение R2 является частью окончательного набора.
Отношение R1 не находится в НФБК, так как срав-
сравнение детерминантов и возможных ключей показыва-
показывает их неидентичность
Возможные ключи в R1 Детерминанты в R1
<Bn,Wk> <Bn>
<Bn,Wk>
<Nb,Wk>
<Ln,Wk>
74
Учебный пример проектирования БД
R1 необходимо подвергнуть дальнейшему преобразова-
преобразованию. На этой стадии особое внимание необходимо
уделять атрибуту Nb. Он является зависимым в R1,
имеющим два различных детерминанта. Как было
указано в разд. 3.7, при некорректно выполненной про-
проекции возможна потеря ФЗ. В действительности, про-
проекция без потери ФЗ может оказаться невозможной -
это значит, что необходимо обратиться к другому ме-
методу проектирования, отличному от декомпозиции.
(a)R3(Bn,Wk,Nb,St,Ph,Sa,Gl,G2,G3)
#3:
Wk,Ln -> Nb
Wk.Nb -> Ln
F) R4(Nb,Wk,Ln)
Рис. 5.4. Результаты проекции R4 из Rl
Глава 5
Правильный способ преобразования R1 состоит в
проецировании, порожденном ФЗ Nb,Wk -> Ln и
формировании отношений R3 и R4 так, как показано
на рис. 5.4.
VV
ФЗ:
Bk.Wk -> GlrG2,G3
(a)R5(Bn,Wk,Gl,G2»G3)
ФЗ:
Bn -> Nb.St.Ph.Sa
<б) R6(Bn,Nb,St,Ph,Sa)
Рис. 5.5. Результаты проекции R6 из R3
В этом случае для обеих зависимостей, содержа-
содержащих Nb, этот атрибут является зависимой компонен-
компонентой: Bn -> Nb в R3 и Ln,Wk -> Nb в R4. Отноше-
Отношение R4 находится в НФБК, а отношение R3 * нет.
Возможные ключи в R3 Детерминанты в R3
<Bn,Wk>
<Вп>
<Bn,Wk>
76 Учебный пример проектирования БД
Декомпозиция отношения R3 может быть осущест-
осуществлена путем проецирования, порождаемого всеми ФЗ,
для которых Вп является детерминантом. Таким на-
набором является Вп -> Nb,St,Pn,Sa. Проекция дает
отношения R5 и R6, показанные на рис. 5.5. Нетруд-
Нетрудно показать, что оба эти отношения находятся в
НФБК. Таким образом, итоговым набором проектиро-
проектирования являются отношения R2, R4, R5 и R6.
5.5. Оценка спроектированных НФБК-отношений
Набор НФБК-отношений, полученный с помощью пе-
пересмотренного алгоритма декомпозиции с исходным
отношением R (рис. 5.1), имеет вид
R2(Nb,Cp,Tn)
R4(Nb,Wk,Ln)
R5(Bn,Wk,Gl,G2,G3)
R6(Bn,Nb,Sl,Ph,Sa)
Первичный ключ каждого отношения подчеркнут. От-
Отношения R2 и R4 имеют более, чем один возможный
ключ. Этот набор необходимо проконтролировать с
целью обнаружения вероятных проблем.
Если перечислить ФЗ, обнаруживаемые на ФЗ-ди-
аграммах для каждого отдельного отношения
Отношение
R2
R4
R5
R6
Номер рисунка
5.3
5.4
5.5
5.5
Тп
Ср
Wk
Wk
Вп
Вп
ФЗ
<->
<->
.Ln
,Nb
,Wk
Nb
Nb
-> Nb
-> Ln
-> 61,62
Nb.St.Ph
,G3
.Sa,
то можно заметить две вещи: A) ни одна ФЗ не по-
повторяется более одного раза; B) этот набор ФЗ сов-
совпадает с тем, который был найден для минимального
покрытия (рис. 5.2).
Анализ четырех отношений показывает, что нельзя
указать среди них ни одного, все атрибуты которого
являлись бы подмножеством атрибутов другого отно-
отношения. Кроме того, невозможно соединить операцией
JOIN какие-либо три отношения так, чтобы в итоге
Глава 5 77
были получены все атрибуты четвертого отношения.
Следовательно, ни одно из четырех отношений не яв-
является избыточным.
Если заменить более длинными названиями атри-
атрибутов более короткие двухсимвольные мнемоники, то
отношения примут вид
К2(НомКоманды. Капитан,НазвКоманды)
R4(НомКоманды, Неделя, Площадка)
Я5(ФамИгрока, Неделя, Игра1, Игра2, ИграЗ)
1ШФамИгрока, НомКоманды, ТелНомер, Адрес, Ре-
Результативность)
Анализ атрибутов, содержащихся в каждом отноше-
отношении, показывает, что в каждом отношении хранится
связный набор данных
R2: Информация о команде
R4: Расписание проведения игр
R5: Информация об индивидуальных результатах иг-
игроков
R6: Информация об отдельных игроках, которая но-
носит частный характер
С практической точки зрения отношения кажутся
вполне разумными.
Хотя проблема в данном примере не вышла на
поверхность, в процессе проектирования атрибуты мо-
могут сгруппироваться в отношения нелогичным обра-
образом. Результат проектирования требует обязательной
проверки с этой точки зрения. Возникновение указан-
указанной ситуации наиболее вероятно в тех случаях, когда
используемые для обозначения атрибутов сокращения
были такими короткими, что проектировщик перестал
понимать, что означают названия атрибутов. Хороший
проектировщик просматривает атрибуты в процессе
проецирования отношений и пытается осознать, на-
насколько разумно они группируются друг с другом.
В главах 9 и 10 будут рассмотрены реализации
БД секретаря с использованием dBASE III и R:base
5000, соответственно. Будут приведены образцы про-
программных модулей, предназначенных для генерации
некоторых из отчетов, необходимых секретарю лиги.
78 Учебный пример проектирования БД
5,6. Задачи к гл. 5
1. Перепроектируйте БД секретаря лиги в предполо-
предположении, что "вычисляемые" атрибуты (Bavg, Bgame,
Wins, Losses, Tpins, Bpins, Hndk, Higam, и Hiser)
должны храниться в БД.
2. Если БД из задачи 1 была бы реализована, то
как можно предотвратить занесение секретарем дан-
данных, порождающих ошибочные состояния некоторых
вычисляемых атрибутов?
6. ДРУГОЙ ПОДХОД К ПРОЕКТИРОВАНИЮ
Декомпозиционный подход к проектированию, которо-
которому посвящены первые пять глав этой книги, является
вполне пригодным при условии небольшого числа за-
задействованных атрибутов. Какое количество атрибутов
и ФЗ следует считать чрезмерным - дело вкуса; од-
однако большинство специалистов полагает, что, когда
число атрибутов превышает 20, метод, основанный на
декомпозиции, становится излишне громоздким. В тех
случаях, когда число атрибутов переусложняет приме-
применение метода декомпозиции, следует обратить внима-
внимание на другие методы проектирования. Один из та-
таких методов называется "сущность-связь". Он отлича-
отличается от метода декомпозиции тем, что ФЗ привлека-
привлекаются не на начальном, а на конечном этапе проекти-
проектирования.
6.1. Сущности и связи
Представление о методе можно получить с помощью
специально подобранного примера. Предположим, что
проектируется БД, предназначенная для хранения ин-
информации о преподавателях университетского факуль-
факультета и о тех курсах, которые они читают. Двумя
главными объектами, или сущностями, представляю-
представляющими в данном случае интерес, являются ПРЕПОДА*
ВАТЕЛЬ и КУРС. Эти две сущности соотносятся с
помощью связи ЧИТАЕТ, что позволяет нам сказать
ПРЕПОДАВАТЕЛЬ ЧИТАЕТ КУРС
Связь ЧИТАЕТ, существующая между двумя сущ-
сущностями ПРЕПОДАВАТЕЛЬ и КУРС, может быть
графически представлена несколькими способами; из
них здесь обсуждаются только два. Рис. 6.1 иллюст-
иллюстрирует использование диаграммы ER-экземпляров с
помощью примера, показывающего какой в точности
курс читает каждый преподаватель. В этом примере
каждый преподаватель идентифицируется номе-
ром-преподавателя (нп), и каждый курс - номе-
ром-курса(нк), Рис. 6,2 называется диаграммой ER-
типа и содержит ту же общую информацию, которая
80
Другой подход к проектированию
содержится на рис. 6.1. В то же время, хотя это мо-
может показаться неочевидным на данный момент,
рис. 6.2 содержит всю информацию, необходимую для
генерации отношений первого уровня проектирования
для БД.
ЩАЬАТЕЛ!
П1 о^^
П2 о
ПЗ о*-^
П4 а-
з ЧИТАЕТ
——■
КУРС
^^-~о CIS130
о МТН234
__——о PHY109
^""^чэ HRD348
Рис. 6.1. Пример диаграммы ER-экземпляров
ПРЕПОДА-
ПРЕПОДАВАТЕЛЬ
нп,.. нк,..
Рис. 6.2. Пример диаграммы ER-типа
Прежде чем двигаться дальше, необходимо пояс-
пояснить некоторые термины, используемые в дальней-
дальнейшем. К сожалению, термины, поясняющие использо-
использование ER-метода, не могут быть строго определены,
что не снимает необходимости их определения.
СУЩНОСТЬ, Сущность определяется как некоторый объ-
объект, представляющий интерес для организации. Этот объект
должен иметь экземпляры, отличающиеся друг от друга и до-
допускающие однозначную идентификацию. Единственный опре-
определяющий признак, который может помочь в нахождении
сущностей, состоит в том, что сущность - это, как правило,
существительное. Примерами сущностей могут служить маши-
машины, банковские счета, колледжи, служащие и контракты. На
рис. 6.1 и 6.2 сущностями являются КУРС И ПРЕПОДАВА-
ПРЕПОДАВАТЕЛЬ, в то время как отдельные экземпляры каждой сущно-
сущности идентифицируются с помощью номера—курса и номе-
номера—преподавателя соответственно.
СВЯЗЬ, Связь представляет собой соединение между двумя
или более сущностями. При поиске связей в основном следу-
Глава 6 81
ет полагаться на то обстоятельство, что связь обычно выража-
выражается глаголом. Типичными примерами связей между двумя
сущностями являются: служащие РАБОТАЮТ-В отделах, сту-
студенты ИЗУЧАЮТ учебные предметы, рабочие ОБСЛУЖИВАЮТ
механизмы.
Тесно связано с предыдущими третье важное поня-
понятие, обсуждавшееся выше, а именно атрибут.
АТРИБУТ, Атрибут есть свойство сущности. Например, ат-
атрибутами, могущими быть свойствами сущности КУРС, явля-
являются: номер—курса, номер-секции, рубрика, семестр—в—кото-
семестр—в—котором—преподавался и предыдущий—курс.
Определения сущности, связи и атрибута не отли-
отличаются особой конкретностью, однако являются при-
приемлемыми для использования в тех целях, на кото-
которые они рассчитаны. В то же время несколько сму-
смущает определенная особенность в ER-методе, заклю-
заключающаяся в том, что два проектировщика могут рас-
рассматривать одну и ту же проблему с разных точек
зрения, получая в итоге различные наборы сущностей
и связей. Определение лучшего из двух наборов мо-
может быть вопросом личного предпочтения.
Продолжая рассмотрение форм графического описа-
описания отметим, что на диаграмме ER-экземпляров (см.
рис. 6.1) названия всех сущностей помещены над эк-
экземплярами этих сущностей и в них использованы
прописные буквы, в то время как каждый экземпляр
сущности идентифицируется значением атрибута. Так
КУРС является сущностью, a CIS 130 - конкретным
экземпляром сущности. Связь также именуется, и ее
название, составленное из прописных букв, размеща-
размещается над экземплярами связи, при этом экземпляр
каждой отдельной связи специфицируется линией
между теми двумя экземплярами сущностей, которые
эта связь соединяет. Экземпляр связи между CIS 130
и ПЗ, например, означает, что преподаватель с номе-
номером—преподавателя равным ПЗ читает курс с номе-
ром-курса CIS130.
В некоторых случаях может понадобиться набор
атрибутов для идентификации каждого экземпляра
сущности. Атрибут, или набор атрибутов, используе-
используемый для идентификации экземпляра сущности, назы-
называется ключом сущности. Каждый экземпляр связи
82 Другой подход к проектированию
однозначно определяется набором ключей сущностей,
соединяемых этой связью. Таким образом,
<II3,CIS130> является одним ключом связи. На дан-
данном этапе процесса проектирования единственными
требуемыми атрибутами являются те, которые необхо-
необходимы для формирования ключей сущностей. Другие
атрибуты вместе с определенными над ними ФЗ бу-
будут добавлены позднее в процессе проектирования.
На диаграммах ER-типа, подобных показанной на
рис. 6.2, сущности представляются в виде прямоуголь-
прямоугольников, а связи - в виде ромбов. Ниже каждой сущ-
сущности размещается атрибут, или набор атрибутов, яв-
являющийся ключом сущности для данной сущности.
Значения цифры " на диаграмме (см. рис. 6.2) и
маленьких сплошных кружков будут обсуждены в
следующем разделе.
В большинстве случаев для определения набора
отношений проектируемой БД используются диаграм-
диаграммы ER-типа, а не диаграммы экземпляров.
6.2. Степень связи
Важной характеристикой связи между двумя (и бо-
более) сущностями является степень связи. Это понятие
будет рассмотрено на расширенном примере данных,
приведенных на рис. 6.1. Рис. 6.3 иллюстрирует все
возможные формы диаграммы ER-экземпляров, кото-
которые могли бы существовать между сущностями ПРЕ-
ПРЕПОДАВАТЕЛЬ и КУРС в том случае, когда степень
связи равна 1:1. Каждая диаграмма представляет соб-
собственный набор возможных правил функционирования
организации (в данном случае университета). Только
одна из этих диаграмм может быть истинной для ор-
организации в каждый момент времени. Перечни пра-
правил, которых следует придерживаться для соответст-
соответствия каждой диаграмме, представленной на рис. 6.3,
формулируются следующим образом:
Рис. 6.3(а). Каждый преподаватель читает не бо-
более одного курса и каждый курс читается не бо-
более чем одним преподавателем, т.е. допускается
наличие преподавателей, не читающих ни одного
курса, а также курсов, не читаемых вовсе. Та-
Таким образом, ни один преподаватель не должен
Глава 6
читать более одного курса, и ни один курс не
должен читаться более чем одним преподавателем.
ПРЕПОДАВАТЕЛЬ
П1 о^^
П2 о ^"^
ПЗ о
П4 о——
ЧИТАЕТ
—.—■—
КУРС
о МТН234
^-~© PHY1O*
^^хз HR&34i
<а) Степень равна 1:1 и класс принадлежности ни одной
из сущностей не является обязательным
ПРЕПОДАВАТЕЛЬ ЧИТАЕТ КУРС
Л1
HRD348
(б) Степень равна1:1 и класс принадлежности сущности
ПРЕПОДАВАТЕЛЬ является обязательным
ПРЕПОДАВАТЕЛЬ
П1 о—-^___
П2 о^^___
ПЗ ъ**~^^*^
П4 о
ЧИТАЕТ
***=-——в—и
курс
^о CI8130
**-**-чэ НГН234
•*-© PHY109
(в) Степень равна 1:1 и класс принадлежности сущности
КУРС является обязательным
ПРЕПОДАВАТЕЛЬ
П1
ЧИТАЕТ
КУРС
П4
(г) Степень равна 1:1 и класс принадлежности Обеих
сущностей является обязательным
Рис. 6.3. Различные классы принадлежности для слу-
случая степени связи 1:1
84 Другой подход к проектированию
Рис. 6.3F). Каждый преподаватель читает только
один курс, а каждый курс читается не более чем
одним преподавателем.
Рис. 6.3(в). Каждый преподаватель читает не бо-
более одного курса, а каждый курс читается толь-
только одним преподавателем.
Рис. 6.3(г). Каждый преподаватель читает только
один курс и каждый курс читается только одним
преподавателем.
Тот факт, что каждый экземпляр сущности, распо-
расположенный как в левой, так и в правой частях диаг-
диаграммы, связывается максимально с одним экземпля-
экземпляром сущности, расположенным в противоположной ча-
части диаграммы, дает основание определить каждую из
диаграмм экземпляров, приведенную на рис. 6.3, как
имеющую степень 1:1.
Различия между диаграммами, показанными на
рис. 6.3, являются следствием того, должны или не
должны все экземпляры сущности участвовать в свя-
связи. На рис. 6.3(а) не выставляется требование уча-
участия всех экземпляров обеих сущностей в связи. На
рис. 6.3F) все экземпляры преподавателей обязатель-
обязательно должны участвовать в связи, а экземпляры курсов
- необязательно. На рис. 6.3 (в) требуется участие в
связи каждого экземпляра курса и допускается неуча-
неучастие некоторых экземпляров преподавателей. На
рис. 6.3(г) требование обязательного участия в связи
накладывается на все экземпляры обеих сущностей.
Рис. 6.4 иллюстрирует возможность более компакт-
компактной формы представления информации, приведенной
на рис. 6.3.
Если экземпляры данной сущности должны участ-
участвовать в связи, то участие называется обязательным
и этот факт отмечается помещением маленького
сплошного кружка в блок, смежный с блоком сущно-
сущности. Если экземпляры данной сущности могут не уча-
участвовать в связи, то участие называется необязатель-
необязательным и кружок внутрь маленького блока не заносится.
Класс принадлежности сущности должен быть либо
обязательным, либо необязательным и определяться
правилами, регламентирующими деятельность органи-
организации. Единицы в обеих частях связей, показанных
на рис. 6.4, говорят о том, что степени всех связей
Глава 6
85
относятся к типу 1:1. Возможны и отличные от 1:1
степени. Они будут обсуждены позже в этом разделе.
В диаграммах ER-типа непосредственно под блоком
каждой сущности выписывается и выделяется подчер-
подчеркиванием ключ этой сущности: нп (номер—преподава-
(номер—преподавателя) для сущности ПРЕПОДАВАТЕЛЬ и нк (но-
(номер-курса) для сущности КУРС. Точки, расположен-
расположенные вслед за каждым из этих атрибутов, указывают
на то, что никакие другие возможно имеющиеся ат-
атрибуты соответствующей сущности не могут быть час-
частью ее ключа. Эти другие атрибуты будут добавлены
после разработки отношений.
ПРЕПОДА-
ПРЕПОДАВАТЕЛЬ
нп,..
(а)
HJK,..
ПРЕПОДА-
ПРЕПОДАВАТЕЛЬ
нп...
(б)
нк,..
ПРЕПОДА-
ПРЕПОДАВАТЕЛЬ
нп,..
нк,..
ПРЕПОДА-
ПРЕПОДАВАТЕЛЬ
НП,..
(г)
нк,..
Рис. 6.4. Диаграммы ER-типа, соответствующие диаг-
диаграммам экземпляров, приведенных на рис. 6.3
86
Другой подход к проектированию
ПРЕПОДАВАТЕЛЬ
ЧИТАЕТ
КУРС
CIS130
МТИ234
PHY109
HRD348
MUS333
П4 Q ""—; ■—-—.^Z" ° MTH237
П7 о ^^" о PHY436
( Степени равна 1: n и класс принадлежности ни одной
из сущностей не является обязательным
ПРЕПОДАВАТЕЛЬ
ЧИТАЕТ
КУРС
F)Степень равна 1 :п и класс принадлежности сущности
ПРЕПОДАВАТЕЛЬ является обязательным
ПРЕПОДАВАТЕЛЬ ЧИТАЕТ
КУРС
CIS150
ИТН234
PHY109
Mf<D34&)
PHY456
Ы Степень равна 1: п и класс принадлежности сущности
КУРС является обязательным
ПРЕПОДАВАТЕЛЬ ЧИТАЕТ КУРС
C1S13O
МТИ234
РИУ109
RRD348
MUS333
МТН257
PHY436
(гУ Степень равна 1: пи класс принадлежности обеих
сущностей является обязательным
Рис, 6.5, Примеры диаграмм экземпляров для случая
степени связи 1:п
Ни одно из правил, регламентирующих работу ор-
организации и используемых при составлении диаграмм,
Глава 6
87
представленных на рис. 6.1 - 6.4, не допускает чте-
чтения преподавателем более одного курса, а также чте-
чтение одного курса более чем одним преподавателем.
Для большинства учебных заведений дело обстоит
иначе. Ниже приводятся другие наборы правил, при-
принятых во многих учебных заведениях.
ПРЕПОДА-
ПРЕПОДАВАТЕЛЬ
нп,..
нк...
ПРЕПОДА-
ПРЕПОДАВАТЕЛЬ
нп,..
нк,..
ПРЕПОДА-
ПРЕПОДАВАТЕЛЬ
нп,..
нк,..
ПРЕПОДА-
ПРЕПОДАВАТЕЛЬ
нп,.
нк,..
Рис. 6.6. Диаграммы ER-типа, соответствующие диаг-
диаграммам экземпляров, приведенных на рис. 6.5
СЛУЧАЙ 1. Каждый преподаватель может чи-
читать одновременно несколько курсов, но каждый курс
читается не более чем одним преподавателем.
СЛУЧАЙ 2. Каждый преподаватель читает не
более одного курса, но каждый курс может читаться
сразу несколькими преподавателями.
88
Другой подход к проектированию
СЛУЧАЙ 3. Каждый преподаватель может чи-
читать несколько курсов и каждый курс может читаться
несколькими преподавателями.
ПРЕПОДАВАТЕЛЬ
ЧИТАЕТ
КУРС
(а) Степень равна п: 1 и класс принадлежности ни одной
из сущностей не является обязательным
ПРЕПОДАВАТЕЛЬ
ЧИТАЕТ
КУРС
(б) Степень равна п :1 и класс принадлежности,сущности
ПРЕПОДАВАТЕЛЬ является обязательным
ПРЕПОДАВАТЕЛЬ
ЧИТАЕТ
КУРС
1 и класс принадлежности сущности
КУРС является обязательным
ПРЕПОДАВАТЕЛЬ
ЧИТАЕТ
КУРС
(г) Степень равна п : 1 и класс принадлежности обеих
сущностей является обязательным
Рис. 6.7. Примеры диаграмм экземпляров для случая
степени связи п:1
Глава 6
89
ПРЕПОДА-
ПРЕПОДАВАТЕЛЬ
нп,..
нк,..
ПРЕПОДА-
ПРЕПОДАВАТЕЛЬ
нп,..
нк,..
ПРЕПОДА-
ПРЕПОДАВАТЕЛЬ
нп,..
нк,..
ПРЕПОДА-
ПРЕПОДАВАТЕЛЬ
нп,..
нк,..
Рис. 6.8. Диаграммы ER-типа, соответствующие диаг-
диаграммам экземпляров, приведенных на рис. 6.7
Каждый из этих случаев имеет несколько подвариан-
тов, а именно класс принадлежности может быть обя-
обязательным или необязательным - для одной из двух,
ни для одной или для обеих сущностей. Возможные
формы для каждого случая будут обсуждаться отдель-
отдельно. Отметим, что случаи 1 и 2 симметричны по форме.
На рис. 6.5 показаны различные диаграммы экзем-
экземпляров для СЛУЧАЯ 1, а на рис. 6.6 - эквивалент-
эквивалентные им диаграммы типа. В примерах (а) ни один из
классов принадлежности не является обязательным.
Другой подход к проектированию
ЧИТАЕТ
КУРС
CIS130
(а) Степень равна m : n и класс принадлежности ни одной
из сущностей не является обязательным
ПРЕПОДАВАТЕЛЬ
ЧИТАЕТ
КУРС
(б) Степень равна т:п и класс принадлежности сущности
ПРЕПОДАВАТЕЛЬ является обязательным
ПРЕПОДАВАТЕЛЬ
ЧИТАЕТ
КУРС
(в) Степень равна m : n и класс принадлежности сущности
КУРС является обязательным
ЧИТАЕТ
КУРС
(г) Степень равна m : п и класс принадлежности обеих
сущностей является обязательным
Рис. 6.9. Примеры диаграмм экземпляров для случая
степени связи m:n
В примерах (б) и (в) класс принадлежности явля-
является обязательным для одной из двух сущностей. В
Глава 6
91
примерах (г) класс принадлежности является обяза-
обязательным для обеих сущностей. В каждом из этих ри-
рисунков степень связи имеет тип 1:п A к п) вследст-
вследствие того, что каждый экземпляр курса может быть
связан не более чем с одним экземпляром преподава-
преподавателя (отсюда 1), а каждый экземпляр преподавателя
может быть связан с более чем одним экземпляром
курса (отсюда получаем п).
ПРЕПОДА
ВАТЕЛЬ
нк .
ПРЕПОДА-
ПРЕПОДАВАТЕЛЬ
нп,..
ПРЕПОДА-
ПРЕПОДАВАТЕЛЬ
нп,..
нк,..
ПРЕПОДА-
ПРЕПОДАВАТЕЛЬ
нп,.
(г)
нк,..
Рис б. 10. Диаграммы ER-типа, соответствующие ди-
диаграммам экземпляров, приведенных на рис. 6.9
На рис. 6.7 показаны различные диаграммы экзем-
экземпляров для случая 2, на рис. 6.8 показаны эквива-
эквивалентные им диаграммы типа. В примерах (а) класс
принадлежности не является обязательным для сущ-
92 Другой подход к проектированию
ностей как левой, так и правой частей. В примерах
(б) и (в) класс принадлежности является обязатель-
обязательным для сущности либо левой, либо правой частей. В
примерах (г) класс принадлежности является обяза-
обязательным для обеих сущностей. Связи на этих рисун-
рисунках имеют степень п:1 (п к 1), так как экземпляр
курса может быть связан с более чем одним экземп-
экземпляром преподавателя (получаем п), а каждый экземп-
экземпляр преподавателя связывается с не более чем одним
экземпляром курса (имеем 1).
На рис. 6.9 показаны различные диаграммы экзем-
экземпляров для случая 3, а на рис. 6.10 показаны им эк-
эквивалентные диаграммы типа. В примерах (а) класс
принадлежности не является обязательным ни для од-
одной из сущностей. В примерах (б) и (в) класс при-
принадлежности является обязательным для одной из
сущностей. В примерах (г) класс принадлежности яв-
является обязательным для обеих сущностей. Связь в
каждом из этих рисунков имеет степень m:n (m к п),
так как каждый экземпляр курса может быть связан
более чем с одним экземпляром преподавателя (отсю-
(отсюда т) и каждый экземпляр преподавателя может
быть связан более чем с одним экземпляром курса
(получаем п).
6.3. Некоторые замечания по поводу графического
представления
Единого общепризнанного формата для графического
представления диаграмм сущность-связь не установле-
установлено. Хотя методы, предложенные разными авторами,
схожи по существу, они имеют как мелкие, так и
крупные различия. Выбранное в книге графическое
представление и терминология предложены Хау1).
Фактически стандартный способ представления избран
Ульманом2), в то время как более сложный подход,
основанный на использовании семантических сетей,
был избран Хавришкевичем3). Читателю рекомендуется
*) D.R. Howe, Data Analysis for Database Design (Baltimore, MD:
Edward Arnold/University Park Press, 1983).
2> J.D. Ullman, Principles of Database Systems, 2nd ed. (Rockville,
MD: Computer Science Press, 1984).
3) I.T. Hawryszkiewycz, Data Analysis and Design (Chicago: Science
Research Associates, Inc., 1984).
Глава 6 93
изучить также другие методы и применять тот, кото-
который в наибольшей степени его устраивает. Думается,
что описанный в книге метод прост и удобен для ис-
использования.
6.4. Задачи к гл. 6
1. Начертите типичные диаграммы экземпляров сущ-
сущностей для каждой из следующих ситуаций. Перечис-
Перечислите предположения, сделанные в каждом случае:
а) руководству сети бакалейных магазинов требу-
требуется хранить информацию об отдельных магазинах и
поставщиках, у которых эти магазины покупают про-
продукцию; каждый магазин покупает продукцию у не-
нескольких поставщиков, и каждый поставщик обеспе-
обеспечивает продукцией несколько магазинов;
б) службе окраски домов необходимо быть в курсе
дел маляров, входящих в союз, и знать конкретно те
дома, окраску которых они осуществляют; каждый
маляр красит только один дом в любой момент вре-
времени, но один дом могут красить несколько маляров
одновременно; некоторые маляры могут быть без ра-
работы; дома, не подлежащие окраске, не учитываются;
в) в гараже работают механики по ремонту авто-
автомобилей; каждый механик занят ремонтом сразу не-
несколько автомашин, при этом ремонт каждого автомо-
автомобиля осуществляется только одним механиком.
2. Для каждой диаграммы экземпляров, полученной
при решении задач из пункта 1, начертите диаграм-
диаграмму ER-типа. Укажите ключи сущностей в каждой
диаграмме.
7. ПОЛУЧЕНИЕ ОТНОШЕНИЙ ИЗ ДИАГРАММ
ER-ТИПА
Связь ЧИТАЕТ, существующая между сущностями
ПРЕПОДАВАТЕЛЬ и КУРС (рассмотрены в предыду-
предыдущей главе), называется бинарной, поскольку она свя-
связывает только две сущности. Связи более высокого
порядка, существующие между тремя и более сущно-
сущностями, будут обсуждаться в следующей главе. Бинар-
Бинарные связи встречаются наиболее часто. Эта глава по-
посвящена тому, как с использованием диаграмм ER-ти-
па можно получить отношения, служащие основой
построения БД, причем рассмотрение ограничивается
случаем бинарных связей.
Общий подход к построению БД с использованием
ER-метода состоит прежде всего в построении диаг-
диаграммы ER-типа, включающей в себя все сущности и
связи, важные с точки зрения интересов организации.
Как частный пример на рис. 7.1 показана версия
полной ER-диаграммы для БД секретаря кегельной
лиги.
■ р-1 т^^ \1 гт П1 s' ^^m П
ИГРОК |«[-<>1ГРАЕТ В^>)>|КОМАНДА |»|-<^МЕЕТ^>--^|РАСПИСАНИЕ
ФамИгрока, Неделя,.,
Другие атрибуты: Тел Номер, Адрес, РезультативностцНазв Команды,
Капитан, Игра1, Игра2, ИграЗ.
Рис. 7.1. Диаграмма ER-типа для БД секретаря ке-
кегельной лиги
На этой диаграмме представлены четыре сущности
и три бинарные связи. Второй шаг в процессе проек-
проектирования состоит в построении набора предваритель-
Глава 7 95
ных отношений и указании предполагаемого первич-
первичного ключа для каждого отношения. Последний шаг
состоит в подготовке списка всех представляющих ин-
интерес атрибутов (тех из них, которые не были уже
перечислены в диаграмме ER-типа в качестве ключей
сущности) и назначении каждого из этих атрибутов
одному из предварительных отношений с тем услови-
условием, чтобы эти отношения находились в НФБК. На
этом последнем шаге для каждого отношения должны
быть определены межатрибутные ФЗ, с помощью ко-
которых проверяется соответствие отношений НФБК.
Если полученные в итоге отношения не находятся в
НФБК или если некоторым атрибутам не находится
логически обоснованных мест в предварительных от-
отношениях, то в этих случаях необходимо пересмот-
пересмотреть ER-диаграммы на предмет устранения возникших
затруднений.
7.1. Предварительные отношения для бинарных
связей степени 1:1
Предварительные отношения для данной бинарной
связи могут быть получены путем просмотра несколь-
нескольких логических альтернатив и выбора среди них наи-
наиболее подходящей. Перечень общих правил генерации
отношений из диаграмм ER-типа можно получить,
опираясь на класс принадлежности и степень отноше-
отношения как на определяющие факторы. С целью упроще-
упрощения вывода этих правил будет использована ситуация
ПРЕПОДАВАТЕЛЬ ЧИТАЕТ КУРС (обсуждавшаяся в
гл. 6) вместе с приблизительными ссылками на диаг-
диаграммы, приведенные там же. Обсуждение будет огра-
ограничено случаями, в которых степень бинарной связи
равна 1:1.
При попытке определить, как много отношений
необходимо для размещения информации, содержа-
содержащейся в бинарных связях степени 1:1, подобных при-
приведенным на диаграммах ER-типа (см. рис. 6.4), про-
простейшим решением, на которое можно надеяться, яв-
является необходимость одного отношения. Пусть это
отношение называется ПРЕПОДАВАТЕЛЬ и все атри-
атрибуты помещаются в это одно отношение. На рис. 7.2
приведен экземпляр такого отношения в том случае,
когда класс принадлежности является обязательным
96
Получение отношений из диаграмм ER-типа
для обеих сущностей (см. рис. 6.3(г) и 6.4(г)). В
этом отношении сущность ПРЕПОДАВАТЕЛЬ была
пополнена двумя типичными атрибутами: имя—препо-
имя—преподавателя (пфам) и телефон—преподавателя (птел).
Один атрибут добавлен к сущности КУРС: предыду-
щий-курс (предкурс).
ПРЕПОДАВАТЕЛЬ(нпг пфам, птел, нкг предкурс)
ПРЕПОДАВАТЕЛЬ
нп
П1
П2
ПЗ
П4
пфам
Смит
Джонс
Хопп
Аппл
птел
2345
2233
6543
7766
нк
HRD348
PHY109
CIS130
МТН234
предкурс
HRD1OO
NONE
МТН12О
МТН150
Рис. 7.2. Экземпляр единичного отношения, в кото-
котором содержатся данные, приведенные на рис. 6.3 (г) и
6.4 (г)
В этом специальном случае одно отношение - это
все, что требуется. Так как степень связи здесь 1:1 и
класс принадлежности является обязательным как для
сущности ПРЕПОДАВАТЕЛЬ, так и для сущности
КУРС, гарантируется однократное появление каждого
значения нп и каждого значения нк в любом экземп-
экземпляре отношения. Это значит, что отношение никогда
не будет содержать ни пустой информации, ни повто-
повторяющихся групп избыточных данных. Ключ сущности
ПРЕПОДАВАТЕЛЬ был избран в качестве первичного
ключа для отношения, но также может быть исполь-
использован ключ сущности КУРС.
Итак, можно сформулировать первое правило гене-
генерации отношений.
ПРАВИЛО 1. Если степень бинарной связи
равна 1:1 и класс принадлежности обеих сущностей
является обязательным, то требуется только одно от-
отношение. Первичным ключом этого отношения может
быть ключ любой из двух сущностей.
Если степень связи равна 1:1 и класс принадлеж-
принадлежности одной сущности является обязательным, а дру-
Глава 7
97
гой - необязательным, то одного отношения недоста-
недостаточно. На рис. 7.3 приведен экземпляр отношения в
том случае, когда класс принадлежности сущности
ПРЕПОДАВАТЕЛЬ является обязательным, а сущно-
сущности КУРС - необязательным (см. рис. 6.3F) и
6.4F)). В этом случае пробелы появляются во всех
кортежах, содержащих информацию о курсах, не чи-
читаемых ни одним из преподавателей. Пробелы обоз-
ПРЕПОДАВАТЕЛЬ(нп, пфам, птел, нкг предеурс)
ПРЕПОДАВАТЕЛЬ
нп
П1
П2
ПЗ
пфаи
Смит
Джонс
Хопп
птел
2345
2233
6543
нк
HRD348
PHY109
CIS130
МТН234
предкурс
HRD1OO
NONE
МТН12О
МТН150
Рис. 7.3. Экземпляр единичного отношения, в кото-
котором содержатся данные, приведенные на рис. 6.3F) и
6.4F)
После некоторых раздумий можно заключить, что
способ исключения пробелов состоит в использовании
вместо одного отношения двух. Каждое отношение
будет содержать информацию, касающуюся одной
сущности. Кроме того, ключ сущности, класс принад-
принадлежности которой является необязательным, необходи-
необходимо поместить в качестве атрибута в отношение, со-
содержащее информацию о сущности, класс принадлеж-
принадлежности которой является обязательным. Этот случай
иллюстрируется рис. 7.4. Причиной отсутствия пробе-
пробелов в отношении ПРЕПОДАВАТЕЛЬ, приведенном на
рис. 7.4, является то обстоятельство, что каждый пре-
преподаватель должен вести только один курс. (Заметь-
(Заметьте, что если бы преподаватель мог читать более од-
одного курса, то в отношении появились бы повторяю-
повторяющиеся значения в полях пфам и птел для всех тех
преподавателей, которые читают более одного курса).
Важно подчеркнуть, что слово NONE, появляющееся
в качестве значения поля предкурс (см. рис. 7.4),
есть действительное значение, а не пробел.
98
Получение отношений из диаграмм ER-типа
ПРЕПОДАВАТЕЛЬ(нп, пфаиг птел, нкг предкурс)
КУРС(ик., предкурс)
ПРЕПОДАВАТЕЛЬ
нп
П1
П2
ПЗ
пфам
Смит
Джонс
Хопп
птел
2345
2233
6543
нк
HRD348
PHY109
CIS130
КУРС
нк
HRD348
PHY109
CIS130
МТН234
предкурс
HRD1OO
NONE
МТН12О
МТН150
Рис. 7.4. Экземпляры двух отношений, в которых со-
содержатся данные, приведенные на рис. 6.3F) и 6.4F)
Настало время для формулирования второго прави-
правила генерации отношений.
ПРАВИЛО 2. Если степень бинарной связи
равна 1:1 и класс принадлежности одной сущности
является обязательным, а другой - необязательным,
то необходимо построение двух отношений. Под каж-
каждую сущность необходимо выделение одного отноше-
отношения, при этом ключ сущности должен служить пер-
первичным ключом для соответствующего отношения.
Кроме того, ключ сущности, для которого класс при-
принадлежности является необязательным, добавляется в
качестве атрибута в отношение, выделенное для сущ-
сущности с обязательным классом принадлежности.
Воспользовавшись этим правилом в ситуации, опи-
описанной на рис. 6.3(в) и 6.4(в), где класс принадлеж-
принадлежности сущности КУРС является обязательным, а сущ-
сущности ПРЕПОДАВАТЕЛЬ - необязательным, получаем
следующие отношения:
ПРЕПОДАВАТЕЛЬ (нп, пфам, птел)
КУРС(нк, предкурс, нп)
В том случае, когда степень бинарной связи равна
1:1 и класс принадлежности ни одной из сущностей
не является обязательным, одного отношения недоста-
недостаточно. При использовании только одного отношения
возможны два пути возникновения пробелов. Также
недостаточным является использование двух отноше-
отношений, так как возникают проблемы в связи с внесением
Глава 7
99
ключа одной сущности в отношение, выделенное под
другую сущность. Единственное решение заключается в
выделении трех отношений: по одному для каждой
сущности и одного для связи. На рис. 7.5 приведены
типичные экземпляры отношений, получаемые при
использовании одного, двух и трех отношений (см.
рис. 6.3(а) и 6.4(а)). Пробелы возникают везде, за
исключением случая использования трех отношений.
ПРЕПОДАВАТЕЛЬ
нп
П1
П2
ПЗ
П4
пфам
Сиит
Джонс
Хопп
Ann л
птел
2345
2233
6543
7766
нк
HRD348
CIS130
PHY109
МТН234
предкурс
HRD1OO
МТН120
NONE
МТН150
(а) Использование одного отношения
ПРЕПОДАВАТЕЛЬ КУРС
нп
П1
П2
ПЗ
П4
пфам
Смит
Джонс
Хопп
Аппд
птел
2345
2233
6543
7766
нк
HRD348
CIS130
PHY109
нк
CIS130
HRD348
МТН234
PHY109
предкурс
ИТН12О
HRD1OO
КТН150
NONE
нп
ПЗ
П1
П4
(б) Использование двух отношений
ПРЕПОДАВАТЕЛЬ КУРС ЧИТАЕТ
нп
П1
П2
ПЗ
П4
пфам
Смит
Джонс
Хопп
Аппл
птел
2345
2233
6543
7766
нк
CIS130
HRD348
МТН234
PHY109
предкурс
МТН12О
HRD1OO
МТН150
NONE
нп
П1
ПЗ
П4
нк
HRD348
CIS130
PHY109
(в) Использование трех отношений
Рис. 7.5. Возможные реляционные формы для случая
бинарной связи степени 1:1, когда ни один из клас-
классов принадлежности не является обязательным
100 Получение отношений из диаграмм ER-типа
В отношении ЧИТАЕТ на рис. 7.5 (в) любые зна-
значения как номера-преподавателя, так и номера-курса
могут появиться только однажды, так как степень
равна 1:1. Кроме того, отношение ЧИТАЕТ содержит
номера—курсов только тех, которые читаются, и но-
номера—преподавателей только тех, которые читают
курс. Отношение ПРЕПОДАВАТЕЛЬ содержит инфор-
информацию о всех преподавателях и отношение КУРС со-
содержит информацию обо всех курсах.
Теперь можно сформулировать третье правило ге-
генерации отношений.
ПРАВИЛО 3. Если степень бинарной связи
равна 1:1 и класс принадлежности ни одной сущности
не является обязательным, то необходимо использо-
использовать три отношения: по одному для каждой сущно-
сущности, ключи которых служат в качестве первичных в
соответствующих отношениях, и одного для связи.
Среди своих атрибутов отношение, выделяемое связи,
будет иметь по одному ключу сущности от каждой
сущности.
В обсуждаемом нами случае отношение ЧИТАЕТ,
исходной точкой генерации которого послужила связь,
не имеет других атрибутов, кроме тех, которые тре-
требует ключ. Так обстоит дело не всегда. Например,
если бы каждому читаемому курсу придавался тью-
тьютор, фамилия последнего могла бы быть атрибутом
отношения ЧИТАЕТ.
7*2* Первый пример ER-проектирования
Постановка задачи
Проектируется БД, предназначенная для хранения
информации о профессиональных рыболовных провод-
проводниках Северной Миннесоты и озерах, которые ими
обслуживаются. Международный союз рыболовных
проводников разрешает закрепление не более одного
проводника за одним озером, и по соглашению между
проводниками каждый из них обслуживает только од-
одно озеро. Представляющими интерес атрибутами яв-
являются: имя проводника (п—имя), номер телефона
(тном), ежедневная оплата (плата), максимально допу-
Глава 7
101
стимое число людей в группе рыбаков (размер), на-
название озера (о-назв), рыболовный рейтинг (рейтнг)
и основной вид вылавливаемой в озере рыбы (вид).
Решение задачи
Сущностями в данном случае будут ПРОВОДНИК
и ОЗЕРО и связью между ними ОБСЛУЖИВАЕТ.
Типичные диаграммы ER-экземпляров и типа приве-
приведены на рис. 7.6. Предположениями, учитывавшимися
при построении диаграмм, являются: все проводники
имеют работу, имена проводников уникальны, назва-
названия озер уникальны, некоторые озера проводниками
не обслуживаются.
ПРОВОДНИК
Смит
ОБСЛУЖИВАЕТ
ПРОВОД-
ПРОВОДНИК
П.ИМЯ,..., о,назв,....
Другие Атрибуты • тном, плата, разм, рейтнг, вид
(б)
Рис. 7.6. Диаграммы ER-экземпляров (а) и ER-типа
(б) для первого примера ER-проектирования
Так как степень отношения равна 1:1 и класс
принадлежности одной сущности является обязатель-
обязательным, а другой - нет, то используется правило 2 при
генерации предварительных отношений
102
Получение отношений из диаграмм ER-типа
ПРОВОДНИК (г^имя, ,о-назв)
ОЗЕРО (о-назв. )
Не составляет труда найти место атрибутам, не ис-
используемым в качестве ключей сущности: тном, раз-
размер и плата находят свое место в отношении ПРО-
ПРОВОДНИК, так как они содержат информацию о про-
проводниках; рейтнг и вид помещаются в отношение
ОЗЕРО, так как в них содержится информация об
озерах. Таким образом, предлагаются следующие от-
отношения:
ПРОВОДНИК(п—имя,тном,размер,плата,name)
ОЗЕРО (о-назв, рейтнг, вид)
На рис. 7.7 для обоих отношений помещены диаграм-
диаграммы ФЗ, позволяющие заключить, что каждое отноше-
отношение находится в НФБК. На рис. 7.8 приводятся ти-
типичные экземпляры отношений, используемых при со-
создании БД.
(а)
(б)
Рис. 7.7. Диаграммы ФЗ для отношений (а) ПРО-
ПРОВОДНИК и (б) ОЗЕРО в первом примере ER-проек-
тирования
Эта же БД будет проанализирована при различ-
различных предположениях далее в данной главе.
Глава 7
103
ПРОВОДНИК
п_имя
Джонс
Нари
Рэй
Смит
тнон
234-6789
234-8765
234-8765
234-7766
плата
50
45
55
55
размер
4
3
4
4
оназв
Кус
Найф
Уан
Бэс
ОЗЕРО
оназв
Алиса
Бэс
Мус
Найф
Уан
Пагами
рейтнг
высок
выем
среди
низк
высок
среди
вид
лещ
пучеглазик
с_щука
с_щука
окунь
карась
Рис. 7.8. Типичные экземпляры отношений ПРОВОД-
ПРОВОДНИК и ОЗЕРО
7.3. Предварительные отношения для бинарных
связей степени 1:N
Для случая бинарных связей степени 1:1 устанавли-
устанавливаются три отдельных правила генерации соответству-
соответствующего набора предварительных отношений. Для слу-
случая бинарных связей степени 1:п требуется только
два правила. Фактором, определяющим выбор и ис-
использование одного из этих двух правил, является
класс принадлежности n-связной сущности; класс при-
принадлежности 1-связной сущности не влияет на конеч-
конечный результат в обоих случаях.
На рис. 7.9F) показан экземпляр отношения
КУРС, содержащего данные, приведенные на
рис. 6.5(в) и 6.6(в). Диаграмма типа из рис. 6.6(в)
здесь повторена для ясности. Это случай степени 1:п
с необязательным классом принадлежности 1-связной
сущности и обязательным - n-связной сущности. От-
Отчетливо вырисовываются две проблемы, связанные с
этим отношением. Пробелы обнаруживаются в тех
104
Получение отношений из диаграмм ER-типа
полях атрибутов курса, где преподаватель не читает
курс; повторение полей данных о преподавателях на-
наблюдается там, где преподаватель читает более одного
курса. (В частности, трижды появляется информация
о преподавателе П5.) Если бы класс принадлежности
1-связной сущности был обязательным, то исчезли бы
пробелы, но повторяющиеся группы данных в полях
атрибутов преподавателя сохранились.
ПРЕПОДА-
ПРЕПОДАВАТЕЛЬ
нп...
КУРС
нк
CIS130
МТН234
PHY109
HRD348
MUS333
МТН257
PHY456
предкурс
МТН120
МТН150
NONE
HRD100
MUS100
МТН234
PHY109
нп
ПЗ
П1
П2
П5
П5
П5
П7
П4
П6
пфам
Хопп
Смит
Джонс
Скотт
Скотт
Скотт
Поппи
Ann а
Каин
птел
6543
2345
2233
4356
4356
4356
8122
7766
5492
Рис. 7.9. Использование одного отношения для бинар-
бинарной связи типа 1:п в том случае, когда класс при-
принадлежности п-связной сущности является обязатель-
обязательным, а 1-связной - необязательным
Решить все эти проблемы, вне зависимости от
класса принадлежности 1-связной сущности, можно
согласно следующему правилу.
Глава 7
105
ПРАВИЛО 4. Если степень бинарной связи
равна 1:п и класс принадлежности n-связной сущно-
сущности является обязательным, то достаточным является
использование двух отношений, по одному на каждую
сущность, при условии, что ключ сущности каждой
сущности служит в качестве первичного ключа для
соответствующего отношения. Дополнительно ключ
1-связной сущности должен быть добавлен как атри-
атрибут в отношение, отводимое n-связной сущности.
На рис. 7.10 приведены примеры двух отношений,
построенных с помощью этого правила и содержащие
ту же информацию, которая представлена на рис.
7.9. Обратите внимание, что все пробелы и повторя-
повторяющиеся группы данных исчезли.
КУРС
нк
CIS130
НТН234
PHY109
HRD348
HUS333
МТН257
PHY456
предкурс
МТН120
МТН150
NONE
HRD100
HUS100
МТН234
PHY109
нп
ПЗ
П1
П2
П5
П5
П5
П7
ПРЕПОДАВАТЕЛЬ
нп
П1
П2
ПЗ
П4
П5
П6
П7
пфам
Смит
Джонс
Хопп
Аппа
Скотт
Каин
Поппи
птел
2345
2233
6543
7766
4356
5492
8122
Рис. 7.10. Данные, приведенные на рис. 7.9, после их раз-
разнесения по двум отношениям с помощью ПРАВИЛА 4
На рис. 7.11F) показан экземпляр отношения
КУРС, содержащего данные из рисунков 6.5(а) и
6.6(а). Диаграмма типа из рис. 6.6(а) повторена для
большей ясности. Это случай связи степени 1:п с не-
необязательным классом принадлежности обеих сущно-
сущностей. В связи с этим отношением отчетливо вырисо-
вырисовываются три проблемы. Пробелы возникают в полях
атрибутов курса там, где преподаватель не читает
курс, и в тех полях атрибутов преподавателя, где
курс не читается ни одним из преподавателей. Кроме
того, повторяются поля данных о преподавателях в
тех случаях, когда преподаватель читает более одного
курса. (В частности, информация о преподавателе П2
повторяется дважды, о преподавателе П5 - трижды.)
106
Получение отношений из диаграмм ER-типа
Если бы класс принадлежности 1-связной сущности
был обязательным, тогда пробелы в полях атрибутов
курса исчезли бы, однако пробелы и повторяющиеся
группы данных в полях атрибутов преподавателей ос-
остались.
ПРЕПОДА-
ПРЕПОДАВАТЕЛЬ
нп,..
нк„.
КУРС
нк
CIS130
МТН234
PHY109
HRD348
MUS333
МТН257
PHY456
предкурс
МТН120
МТН150
NONE
HRDIOO
MUSlOO
МТН234
PHY109
нп
ПЗ
П2
П2
П5
П5
П5
П1
П4
П6
пфам
Хопп
Джонс
Джонс
Скотт
Скотт
Скотт
Смит
Аппл
Поппи
птел
6543
2233
2233
4356
4356
4356
2345
7766
8122
Рис. 7.11. Использование одного отношения для би-
бинарной связи типа 1:п в случае, когда класс принад-
принадлежности обеих сущностей является необязательным
Если применить ПРАВИЛО 4 в этом случае и
сформировать два отношения, подобные тем, которые
приведены на рис. 7.10, то все проблемы будут ре-
решены за исключением одной: не исчезнут пробелы в
полях номера—преподавателя в новом отношении
КУРС во всех тех местах, где курс не читается. Со-
Соответствующий пример показан на рис. 7.12.
Глава 7
107
КУРС
нк
CIS130
МТН234
PHY109
HRD348
HUS333
МТН257
PHY456
предкурс
МТН120
МТН150
NONE
HRD100
HUS100
МТН234
PHY109
нп
ПЗ
П2
П2
П5
—
П5
П5
ПРЕПОДАВАТЕЛЬ
нп
П1
П2
ПЗ
П4
П5
П6
П7
пфам
Смит
Джонс
Хопп
Ann а
Скотт
Каин
Поп пи
птел
2345
2233
6543
7766
4356
5492
8122
Рис. 7.12. Данные, приведенные на рис. 7.11, после
их разнесения по двум отношениям с помощью ПРА-
ПРАВИЛА 4
Решить все эти проблемы вне зависимости от
класса принадлежности 1-связной сущности можно,
следуя этому правилу.
ПРАВИЛО 5. Если степень бинарной связи
равна 1:п и класс принадлежности n-связной сущно-
сущности является необязательным, то необходимо форми-
формирование трех отношений: по одному для каждой сущ-
сущности, причем ключ каждой сущности служит первич-
первичным ключом соответствующего отношения, и одного
отношения для связи. Связь должна иметь среди сво-
своих атрибутов ключ сущности от каждой сущности.
На рис. 7.13 приводятся экземпляры трех отноше-
отношений, построенных с помощью этого правила, содержа-
содержащих ту же информацию, что представлена на рис.
7.11. Обратите внимание, что все пробелы и повторя-
повторяющиеся группы данных исключены.
7.4. Предварительные отношения для бинарных
связей степени M:N
Если степень бинарной связи равна m:n, то для хра-
хранения данных требуются три отношения вне зависи-
зависимости от класса принадлежности как первой, так и
второй сущностей. При использовании одного или
двух отношений неизбежно возникновение пробелов
и/или повторяющихся групп данных в экземплярах
этих отношений; какая из двух проблем возникнет
108
Получение отношений из диаграмм ER-типа
при использовании двух отношений зависит от клас-
классов принадлежности двух сущностей. Предлагается
следующее правило генерации предварительных отно-
отношений для случая степени m:n.
КУРС
нк
CIS130
МТН234
PHY109
HRD348
MUS333
МТН257
PHY456
предкурс
МТН120
МТН150
NONE
HRD100
MUS100
МТН234
PHY109
ПРЕПОДАВАТЕЛЬ
нп
П1
П2
ПЗ
П4
П5
П6
П7
пфам
Смит
Джонс
Хопп
Аппа
Скотт
Каин
Поппи
птел
2345
2233
6543
7766
4356
5492
8122
ЧИТАЕТ
нп
П2
П2
ПЗ
П5
П5
П5
нк
МТН234
PHY109
CIS130
HRD348
МТН257
PHY456
нк является первичным ключом в силу
существующей связи типа п:1 между
нк и нп
Рис. 7.13. Размещение данных, приведенных на рис.
7.11, в трех отношениях с помощью ПРАВИЛА 5
ПРАВИЛО 6. Если степень бинарной связи
равна m:n, то для хранения данных необходимо три
отношения: по одному для каждой сущности, причем
ключ каждой сущности используется в качестве пер-
первичного ключа соответствующего отношения, и одного
отношения для связи. Последнее отношение должно
иметь в числе своих атрибутов ключ сущности каж-
каждой сущности.
На рис. 7.14 приведены экземпляры отношений,
содержащих данные из рис. 6.9 (а) (степень равна
m:n, и ни один класс принадлежности не является
обязательным). Обратите внимание, что в этих эк-
экземплярах отсутствуют как пробелы, так и повторяю-
Глава 7
109
щиеся группы данных. Аналогичными будут экземп-
экземпляры отношений, содержащие те же данные в тех
случаях, когда один или оба класса принадлежности
являются обязательными. Читателю рекомендуется на-
начертить экземпляры двух отношений, содержащих эти
данные, с целью иллюстрации причин, обуславливаю-
обуславливающих необходимость использования трех отношений.
КУРС
нк
CIS130
МТН234
PHY109
HRD348
HUS333
МТН257
PHY456
предкурс
МТН120
НТН150
NONE
HRD100
HUS100
МТН234
PHY109
ПРЕПОДАВАТЕЛЬ
нп
П1
П2
ПЗ
П4
П5
П6
П7
пфам
Смит
Джонс
Хопп
Аппа
Скотт
Каин
Поппи
птел
2345
2233
6543
7766
4356
5492
8122
ЧИТАЕТ
нп
П1
ПЗ
ПЗ
ПЗ
П5
П6
нк
PHY109
CIS130
PHY109
HUS133
PHY109
МТН257
Это отношение целиком является ключом1)
Рис. 7.14. Размещение данных, приведенных на
рис.6.9(а),в трех отношениях с помощью ПРАВИЛА6
7.5. Второй пример ER-проектирования
Постановка задачи
Здесь рассматривается расширение задачи о рыбо-
рыболовных проводниках, определение которой было дано
*) В случае отсутствия ФЗ, связывающих атрибуты отношения,
первичный ключ этого отношения требует использования всех его
атрибутов. Первичным ключом отношения ЧИТАЕТ является
>нп,нк<. Об отношении этого типа говорят, что оно целиком яв-
является ключом (оно всегда находится в НФБК).
110 Получение отношений из диаграмм ER-типа
в разд. 7.2. Проектируется БД, предназначенная для
хранения информации о профессиональных рыболов-
рыболовных проводниках Северной Миннесоты и обслуживае-
обслуживаемых ими озерах. Международный союз рыболовных
проводников не препятствет тому, чтобы сразу не-
несколькими проводниками обслуживалось одно озеро,
однако, соблюдая соглашение, каждый проводник об-
обслуживает только одно озеро. Рыбаки, нанимающие
проводников, интересуются видами рыб, которые во-
водятся в озерах, самыми крупными экземплярами каж-
каждого вида, выловленными в регионе в текущем сезо-
сезоне, и типом лучшей по мнению союза наживки для
ловли каждого вида рыбы в регионе. Представляющи-
Представляющими интерес атрибутами являются: имя проводника
(п—имя), номер телефона (тном), оплата за день
(плата), название озера, обслуживаемого проводником
(о—назв), максимально допустимое число людей в
группе рыбаков (размер), рыболовный рейтинг каждо-
каждого озера (рейтнг), основные виды рыб, которые мож-
можно выловить в каждом озере (вид), по каждому виду
рыб вес самого большого экземпляра, пойманного в
регионе в текущем сезоне (вмакс), и лучшая нажив-
наживка для каждого вида рыб (нажвка).
Решение задачи
Выделим сущности - ПРОВОДНИК, ОЗЕРО и РЫ-
РЫБА и связи - ОБСЛУЖИВАЕТ и ВОДИТСЯ, как по-
показано на рис. 7.15, где приведены диаграммы типа и
типичные диаграммы экземпляров.
Присутствуют две связи: одна степени п:1 и дру-
другая - m:n. Необходимо применить оба правила D и 6),
с получением четырех предварительных отношений:
по одному для каждой сущности и одно для связи
ВОДИТСЯ. Кроме того, атрибут о-назв сущности
ОЗЕРО необходимо добавить в отношение ПРОВОД-
ПРОВОДНИК (согласно ПРАВИЛУ 4). В результате получа-
получаются следующие предварительные отношения:
ПРОВОДНИК (п-имя, ,о-назв)
ОЗЕРО (о-назв, )
ОЗР-РБ(о-назв,вид, )
РЫБА(вид, )
Глава 7
111
ПРОВОДНИК
Смит
ОБСЛУЖИВАЕТ ОЗЕРО
Уан
ВОДИТСЯ
РЫБА
пучеглази
с„щука
окунь
(б)
Рис. 7.15. Диаграммы ER-экземпляров (а) и ER-типа
(б) для второго примера ER-проектирования
где предварительное отношение, полученное на осно-
основании связи ВОДИТСЯ, названо ОЗР-РБ. Как и в слу-
случае первого примера ЕК-проектирования, не сложно
найти место атрибутам, не являющимся частью клю-
ключей сущностей. Размещение их завершает формирова-
формирование окончательных отношений и проводится следую-
следующим образом: тном, плата и размер - все представля-
представляют собой свойства сущности ПРОВОДНИК и помеща-
помещаются в соответствующее отношение. Атрибут рейтнг
является свойством сущности ОЗЕРО, в то время как
нажвка и вмакс относятся к сущности РЫБА. Един-
Единственное предварительное отношение, не получающее
дополнительных атрибутов, это ОЗР-РБ. Как оказа-
оказалось, оно целиком является ключом.
ПРОВОДНИК(п==имя,тном,плата,размер,о-назв)
ОЗЕРО (о-назв,рейтнг)
ОЗР-РБ (о-назв,вид)
РЫБА (вид,вмакс,нажвка)
112
Получение отношений из диаграмм ER-типа
На рис. 7.16 показаны диаграммы ФЗ для всех отно-
отношений. Каждое из этих отношений уже находится в
НФБК и никаких дополнительных преобразований не
требуется. Типичные примеры каждого из отношений
приведены на рис. 7.17.
(а)
(в)
(г)
Рис. 7.16. Диаграммы ФЗ для отношений (а) ПРО-
ПРОВОДНИК, (б) ОЗЕРО, (в) ОЗ-РЫБА и (г) РЫБА,
представленных на рис. 7.1£
Читателю предлагается определить, как скажется
на решении только что обсуждавшейся задачи каждое
из следующих изменений условий.
ПРОВОДНИК
п_имя
Джонс
Мари
Рэй
Смит
тнон
234-6789
234-8765
234-8765
234-7766
плата
50
45
55
55
размер
4
3
4
4
о_назв
Мус
Найф
Уан
Бэс
ОЗЕРО
оназв
Алиса
Бэс
Мус
Найф
Уан
рейтнг
высок
вьюн
среди
низк
высок
Глава 7
113
ОЗР РБ
РЫБА
о_назв
Уан
Уан
Уан
Мус
Найф
Алиса
Алиса
Бэс
Найф
вид
пучеглазик
с щука
окунь
с_цука
с_цука
лещ
окунь
лещ
карась
вид
лещ
с_щука
окунь
карась
пучеглазик
вмакс
6.5
27.5
0.75
4.25
12.8
нажвка
мотыль
блесна
червяк
ч хлеб
гусеница
Рис. 7.17. Типичные экземпляры отношений, обсуж-
обсуждавшихся во втором примере ER-проектирования
1. Проводник может обслуживать несколько озер.
2. Требуется хранить информацию обо всех нажив-
наживках (не только о "лучшей"), которые можно исполь-
использовать для данного вида рыбы.
7.6. Пересмотр БД секретаря кегельной лиги
На рис. 7.18 показана первая попытка применения
диаграмм ER-типа для БД секретаря кегельной лиги,
детально рассмотренной в гл. 5.
ФамИгрока^.
Ном Команды,..
играет в>^Нкоманда|»|-<имеет>-^(#|расписание|
Площадка , Неделя
Другие атрибуты'. ТелНомер, Адрес, Результативность,
НазвКоманды, Капитан, Игра1, Игра2, ИграЗ.
Рис. 7.18. Возможная диаграмма ER-типа для БД
секретаря кегельной лиги
Предполагается, что при моделировании информа-
информации достаточно использовать три сущности и две би-
114 Получение отношений из диаграмм ER-типа
нарные связи. Использование этой диаграммы и рас-
рассмотренных выше в этой главе правил генерации от-
отношений позволяет разработать три предварительных
отношения. Каждая сущность ИГРОК (BOWLER),
КОМАНДА (TEAM) и РАСПИСАНИЕ (SCHEDULE)
порождает одно отношение. Кроме того, ключ сущно-
сущности КОМАНДА (НомКоманды) должен быть помещен
в качестве атрибута в другие два отношения, что яв-
является следствием существующей между сущностью
КОМАНДА и другими двумя сущностями связи типа
1:п. Эти три отношения имеют вид:
ИГРОК (ФамИгрока,...., НомКоманды)
КОМАНДА (НомКоманды )
РАСПИСАНИЕ(Площадка,Неделя,НомКоманды)
Логичные места для других атрибутов, перечислен-
перечисленных на рис. 7.18, таковы: НазвКоманды и Капитан
следует поместить в отношение КОМАНДА, так как
эти атрибуты суть название команды и фамилия ка-
капитана; ТелНомер, Адрес и Результативность в отно-
отношении ИГРОК, так как эти атрибуты содержат ин-
информацию об игроках. Не находится удачного места
для размещения атрибутов Игра1, Игра2 и ИграЗ. На
первый взгляд их следует поместить в отношение
ИГРОК, но результаты встреч несколько теряют зна-
значимость в случае, если становится неизвестной неде-
неделя, на которой состоялась встреча. Однако атрибут
Неделя нельзя добавить в отношение ИГРОК, по-
поскольку данный атрибут отсутствует в списке неназ-
наченных атрибутов. Создавшаяся ситуация явно ука-
указывает на наличие ошибки в диаграмме ER-типа.
Возможно, что изменение диаграммы ER-типа приве-
приведет к получению предварительных отношений, от ко-
которых возможен прямой переход к НФБК-отношени-
ям. Диаграмма ER-типа, приведенная на рис. 7.1, яв-
является именно такой диаграммой. Результаты предше-
предшествующих обсуждений послужили руководством при
ее разработке. Новой сущностью является ОЧКИ, и
имеет составной ключ сущности <ФамИгрока,Неде-
ля>.
На основании диаграммы, приведенной на рис. 7.1,
получаем следующие предварительные отношения:
Глава 7
115
ИГРОК (ФамИпюка НомКоманды)
КОМАНДА (НомКоманды )
РАСПИСАНИЕ(Площадка,Неделя,НомКоманды)
ОЧКИ (ФамИпхжа.Неделя, ,ФемИррока).
Укажем на интересную особенность предварительного
отношения ОЧКИ: в нем атрибут ФамИгрока появля-
появляется дважды; в первый раз в силу того, что он явля-
является ключом сущности ОЧКИ, и во второй раз - в
связи с размещением ключа сущности из отношения
ИГРОК в отношение ОЧКИ, что диктуется связью
степени 1:п между сущностями ИГРОК и ОЧКИ. Эта
ситуация иногда возникает в случае связи степени
1:п, в которой у п-связной сущности ключ является
составным. Все, что требуется сделать, заключается в
удалении одного из двух дублированных атрибутов во
избежание избыточности. Черта, пересекающая по-
последний атрибут ФамИгрока, указывает, что его сле-
следует удалить.
После добавления оставшегося атрибута в послед-
последний набор предварительных отношений, будут получе-
получены те же 4 НФБК-отношения, генерация которых
была осуществлена в гл. 5. Этот пример иллюстриру-
иллюстрирует тот факт, что диаграмма ER-типа допускает раз-
развитие с помощью итерационного процесса.
7.7. Некоторые замечания, касающиеся числа
отношений
Общие правила, приведенные в этой главе и лежа-
лежащие в основе генерации предварительных отношений
для данной ER-диаграммы несколько отличаются от
тех, которые можно найти в соответствующей литера-
литературе. Некоторые авторы утверждают, что по одному
предварительному отношению следует формировать
для каждой сущности и также по одному для каждой
связи,вне зависимости от степени и класса принад-
принадлежности. В большинстве случаев результатом такого
подхода будет генерация большего числа отношений,
чем это необходимо.
7.8. Задачи к гл. 7
1. Разработайте отношения для каждой диаграммы
типа из задачи 2 гл. 6.
116 Получение отношений из диаграмм ER-типа
2. Видоизмените часть ИГРОК НАБРАНО ОЧКИ ER-
диаграммы, приведенной на рис. 7.1, предполагая, что
ключом сущности ИГРОК являются:
а) <Неделя,Игра1,Игра2,ИграЗ>
и
б) <Игра1,Игра2,ИграЗ>
Нарисуйте типичную диаграмму экземпляров в каж-
каждом случае. Постройте предварительные отношения и
обдумайте проблемы, связанные с размещением дру-
других атрибутов.
8- ДОПОЛНИТЕЛЬНЫЕ КОНСТРУКЦИИ,
ИСПОЛЬЗУЕМЫЕ В ER-МЕТОДЕ
В гл. 6 и 7 был развит метод генерации отношений
БД, основанный на использовании бинарных связей.
Хотя с помощью бинарных связей могут быть описа-
описаны многие ситуации реального мира, тем не менее
неизбежно возникновение и таких ситуаций, в кото-
которых построение разумной модели организации не
представляется возможным без привлечения дополни-
дополнительных конструкций. Эта глава знакомит читателя с
двумя новыми констукциями ER-метода: связями бо-
более высокого порядка и ролями.
8.1. Необходимость связей более высокого порядка
В гл. 7 на двух примерах изучались возможности
применения ER-метода. В основе этих примеров ле-
лежит необходимость хранения информации о рыболов-
рыболовных проводниках, озерах, обслуживаемых проводника-
проводниками, видах рыбы, обитающей в этих озерах. Предпо-
Предположим, что люди, нанимающие проводника, хотят
знать, какой вид рыбы предпочитает ловить провод-
проводник. Если посмотреть на диаграмму экземпляров,
изображенную на рис. 7.15(а), то кому-то может по-
показаться естественным заключение о том, что раз
Смит обслуживает озеро Уан и водятся в этом озере
пучеглазик, северная щука и карась, то, следователь-
следовательно, Смит любит ловить пучеглазика, северную щуку
и карася. Это может быть правдой, а может и не
быть. Возможно Смит только сопровождает тех, кто
хочет ловить пучеглазика. Если связь между сущно-
сущностями ПРОВОДНИК и РЫБА существует, то эта
связь, назовем ее ПРЕДПОЧИТАЕТ, должна быть
представлена в обеих диаграммах - типа и экземпля-
экземпляров, как это показано на рис. 8.1.
Пунктирные линии использованы с целью выделе-
выделения экземпляров связи ПРЕДПОЧИТАЕТ. Кроме то-
того, во избежание путаницы приведены только не-
несколько экземпляров. Из диаграммы экземпляров сле-
следует, что Смит обслуживает озеро Уан, что в озере
Уан водятся три вида рыбы, а также то, что Смит
предпочитает ловить пучеглазика. В силу того что
118 Дополнительные конструкции, используемые в ER-методе
связь между сущностями ПРОВОДНИК и РЫБА име-
имеет степень п:1, и, поскольку каждый проводник об-
обслуживает только одно озеро, не возникает проблемы
выбора проводника для данного озера, если вы собра-
собрались ловить определенный вид рыбы. Действительно,
если вы строите отношения, отражающие ситуацию,
приведенную на рис. 8.1, единственным изменением,
которое требуется внести в отношения, приведенные
на рис. 7.17, является добавление в отношение ПРО-
ПРОВОДНИК атрибута вида из отношения РЫБА. (Этот
атрибут указывает вид рыбы, ловить который предпо-
предпочитает данный проводник.) Таким образом, в этом
расширенном примере бинарные связи также позволя-
позволяют получать адекватную модель ситуации.
ПРОВОДНИК
Смит
ОЗЕРО ^-.
Уан
-^=—--—■
Алиса
^ РЫБА
^*"^>" пучеглазик
2Г '—^-"fi mvKa
^^*n окунь
Рис. 8.1. Диаграммы ER-экземпляров (а) и ER-типа
(б) в случае, когда проводники отдают предпочтение
некоторым видам рыб
Если продолжить модификацию проблемы, то мож-
можно показать недостаточность бинарных связей для
Глава 8
119
корректного моделирования некоторой ситуации.
Предположим, что проводники обслуживают более
чем по одному озеру и каждый проводник может
предпочитать ловить один вид рыбы в одном озере, а
другой - в другом озере. Смит, например, предпочи-
предпочитает ловить пучеглазика в озере Уан и северную щу-
щуку в озере Мус. Джонс, в свою очередь, обслуживает
только озеро Мус и предпочитает ловить северную
щуку. Собрав вместе эти данные, получим следую-
следующий перечень утверждений:
Смит обслуживает оба озера - Уан и Мус.
Джонс обслуживает только озеро Мус.
Смит предпочитает ловить пучеглазика в озере Уан.
Смит предпочитает ловить с-щуку в озере Мус.
Джонс предпочитает ловить с—щуку в озере Мус.
На рис. 8.2 приведена диаграмма ER-экземпляров,
в которой использованы бинарные связи, включающие
только указанные 5 единиц информации.
ПРОВОДНИК
Смит
Джонс
ОЗЕРО
П.ИМЯ,..
о.назв,..
(б)
вид,..
Рис. 8.2. Диаграммы ER-экземпляров (а) и ER-типа
(б) в случае, когда все связи имеют степень m:n
120 Дополнительные конструкции, используемые в ER-методе
ОЗЕРО
о_назв
ПРО-
ПРОВОДНИК
РЫБА
п_имя,..
вид,..
(б)
Рис. 8.3. Диаграммы ER-экземпляров (а) и ER-типа
(б) в случае трехсторонней связи EUO-P
Важно заметить, что хотя из диаграммы можно
вывести все характеризующие Смита и Джонса (см.
выше) утверждения, также можно заключить, что
Смит предпочитает ловить с-щуку в озере Уан, а это
неверно. Проблема возникает из того факта, что в
данном случае все связи имеют степень m:n и, следо-
следовательно, отсутствует уникальный путь, соединяющий
вместе все три экземпляра сущности единственным
образом. Причину возникновения подобной проблемы
можно понять, обратив внимание на то, что каждое
из утверждений "Смит предпочитает ловить пучегла-
пучеглазика в озере Уан" и "Смит предпочитает ловить
Глава 8 121
с-щуку в озере Мус" связывает вместе три информа-
информационных единицы. Та же информация не может быть
заключена в выражениях "Смит обслуживает озеро
Уан и озеро Мус"; "В озере Уан и озере Мус водит-
водится пучеглазик, северная щука и окунь"; "Смит пред-
предпочитает ловить пучеглазика и северную щуку". Суть
в том, что информационные триплеты нельзя пред-
представить в виде набора из трех бинарных связей. Пра-
Правильная модель приводится на рис. 8.3 и требует ис-
использования трехсторонних связей.
8.2. Предварительные отношения для трехсторонних
связей
В случае трехсторонних связей предварительные отно-
отношения генерируются на основании следующего правила.
ПРАВИЛО 7. В случае трехсторонней связи
необходимо использовать четыре предварительных от-
отношения, по одному для каждой сущности, причем
ключ каждой сущности должен служить в качестве
первичного ключа для соответствующего отношения, и
одно для связи. Отношение, порождаемое связью, бу-
будет иметь среди своих атрибутов ключи сущности от
каждой сущности. (Аналогично, когда связь п-сторон-
няя, требуется п+1 предварительное отношение.)
Если применить это правило к данным, приведен-
приведенным на рис. 8.3, то будут получены отношения
ПРОВОДНИК (гь^мя, )
ОЗЕРО (о-назв. )
П—О—Р(п—имя,о-назв,вид,...)
Первичный ключ для П—О—Р не может быть опреде-
определен до тех пор, пока не будут распределены все дру-
другие атрибуты. Если воспользоваться всеми теми атри-
атрибутами, которые приведены на рис. 7.17, то атрибуты
будут распределены следующим образом: отношению
ПРОВОДНИК назначаются атрибуты тном, плата и
размер; отношению ОЗЕРО будет назначен только
один атрибут рейтнг, и отношению РЫБА назначают-
назначаются вмакс и нажвка. Отношение П—О—Р не получит
122 Дополнительные конструкции, используемые в ER-методе
никаких "других" атрибутов. Первичный ключ для
П—О—Р будет составным <п—имя,о-назв> в том слу-
случае, если каждый проводник предпочитает ловить в
озере только один вид рыбы. Если число предпочита-
предпочитаемых проводником видов рыб равно двум или более
для какого-либо озера, тогда все три атрибута отно-
отношения П-О-Р будут составлять ключ. На рис. 8.4
приведены экземпляры четырех отношений в предпо-
предположении, что каждый проводник предпочитает ловить
один вид рыбы в каждом озере, которое им обслужи-
обслуживается. Нетрудно показать, что каждое из рассмот-
рассмотренных отношений находится в НФБК.
ПРОВОДНИК
п_имя
Джонс
Мари
Рэй
Смит
тном
234-6789
234-8765
234-8765
234-7766
плата
50
45
55
55
размер
4
3
4
4
ОЗЕРО
о_назв
Алиса
Мус
Найф
Уан
рейтнг
высок
среди
низк
высок
ПОР
РЫБА
п_имя
Джонс
Смит
Смит
Рэй
Рэй
Мари
о_назв
Мус
Мус
Уан
Уан
Мус
Найф
вид
с_щука
с_щука
пучеглазик
окунь
с_дука
карась
вид
лещ
с_щука
окунь
карась
пучеглазик
внакс
6.5
27.5
0.75
4.25
12.8
нажвка
нотыль
блесна
червяк
ч_хлеб
гусеница
Рис. 8.4. Экземпляры отношений, полученные на ос-
основании диаграмм, приведенных на рис. 8.3
8.3. Использование ролей
В некоторых ситуациях одних сущностей и связей
может оказаться недостаточно для полноценного моде-
моделирования организации. Одна из таких ситуаций воз-
возникает тогда, когда экземпляры некоторой сущности
должны играть разные роли в деятельности предприя-
предприятия. В качестве примера положим, что для небольшо-
небольшого предприятия-поставщика автомобилей необходимо
Глава 8
123
хранить информацию о производственном персонале.
Различают две категории служащих: мастеров и сбор-
сборщиков. Мастера получают фиксированный оклад, в то
время как у сборщиков почасовая оплата.
Первая попытка построения ER-диаграммы показа-
показана на рис. 8.5. Ключом сущности для каждой сущно-
сущности является номер страхового полиса каждого служа-
служащего. Предполагается, что ни один мастер не руково-
руководит другим мастером, ни один мастер не является
сборщиком и ни один сборщик не является мастером.
Рис. 8.5. Возможный вариант ER-модели предприятия
Поскольку связь РУКОВОДИТ имеет степень 1:п и
вхождение сущности для обеих сторон связи является
обязательным, то в соответствии с общим правилом
будут построены два предварительных отношения:
МАСТЕР (мастер #. )
СБОРЩИК (сборщик #. ,мастер#)
С этой моделью связана одна проблема, проявляю-
проявляющаяся при добавлении неключевых атрибутов в пред-
предварительные отношения. Предположим, что другими
представляющими интерес атрибутами являются
слфам — фамилия (и имя) служащего
ртел — номер служебного телефона мастера.
Сборщик служебного телефона не имеет.
дтел — номер домашнего телефона служащего
сладрес — домашний адрес служащего
тставка — почасовая тарифная ставка сборщика
оклад — месячный оклад мастера
124 Дополнительные конструкции, используемые в ER-методе
сбкод — рабочий код сборщика
сфкомп — сфера компетенции мастера
Не возникает особых проблем при размещении в
одном из двух отношений следующих атрибутов:
ртел, тставка, оклад, сбкод и сфкомп. После того как
каждый из этих атрибутов будет логичным образом
помещен в одно из двух отношений, предварительные
отношения примут вид
МАСТЕР (мастер #,оклад.сФкомп,ртел )
СБОРЩИК(сборщик#,тставка,сбкод мастер #)
Неразмещенными остались только атрибуты сфам,
дтел и сладрес. Для полноты следовало бы эти три
атрибута поместить в оба отношения. Однако в соот-
соответствии с общим правилом каждый неключевой ат-
атрибут следует размещать только в одном отношении.
Может возникнуть необходимость переопределить
три оставшихся атрибута с целью получения из них
следующих шести атрибутов:
мфам — фамилия (и имя) мастера
сбфам — фамилия (и имя) сборщика
мдтел — номер домашнего телефона мастера
мадрес — домашний адрес мастера
сбдтел — номер домашнего телефона сборщика
сбадрес — домашний адрес сборщика
Атрибуты мфам, мдтел и мадрес могут быть поме-
помещены в отношение МАСТЕР, а атрибуты сбфам,
сбдтел и сбадрес - в отношение СБОРЩИК. Это неу-
неудачное решение, паллиатив, позволяющий уйти от
проблемы отсутствия подходящего места для двух ис-
исходных атрибутов.
Если все же изменить предложенным образом на-
названия атрибутов, то возникнет следующая проблема.
Предположим, что требуется найти номер домашнего
телефона, например служащего Джоан Джонс, По-
Поскольку неизвестно, является Джоан Джонс мастером
Глава 8
125
или сборщиком, следовательно, предварительно необ-
необходимо просмотреть сначала одно отношение, затем
другое с целью нахождения имени Джоан Джонс. Ес-
Если существуют два служащих Джоан Джонс - один
мастер, а другой - сборщик, результатом поиска, если
выбрано не то отношение, будет неправильный номер
телефона.
Лучшее решение достигается путем рассмотрения
всей проблемы с иной точки зрения. Все мастера и
служащие рассматриваются в качестве служащих, а
мастер и сборщик - это те роли, которые данный
служащий может играть: некоторые служащие явля-
являются мастерами, в то время как другие являются
сборщиками. Графически это показано на рис. 8.6.
На рисунке СЛУЖАЩИЙ представляет собой сущ-
сущность, ключом которой является номер страхового
полиса. Объекты данной сущности могут играть роль
либо мастера, либо сборщика. Два ролевых набора -
МАСТЕР и СБОРЩИК - соединяются связью РУКО-
РУКОВОДИТ. Стрелки, идущие от СЛУЖАЩИЙ как к
сущности МАСТЕР, так и к сущности СБОРЩИК,
указывают на то, что сущность СЛУЖАЩИЙ являет-
является исходной, а МАСТЕР и СБОРЩИК - ролями.
Рис. 8.6. Использование ролей в ER-модели
При генерации предварительных отношений, исходя
из диаграммы, представленной на рис. 8.6, можно ру-
руководствоваться следующим правилом.
126 Дополнительные конструкции, используемые в ER-методе
Исходная сущность служит источником генерации одного
отношения, причем ключ сущности служит в качестве клю-
ключа отношения. Ролевые элементы и связи, их соединяющие,
порождают такое число отношений, которое определяется
ранее описанными правилами, причем каждая роль тракту-
трактуется как обычная сущность.
С помощью предложеного правила получены следу-
следующие три предварительные отношения:
СЛУЖАЩИЙ (служ#, )
МАСТЕР (мастер #. )
СБОРЩИК (сборщик #, ,мастер#)
При распределении всех других атрибутов между
отношениями, входящими в данный набор, выясняет-
выясняется, что каждому атрибуту находится естественное ме-
место. Получаемый в результате окончательный набор
отношений имеет вид
СЛУЖАЩИЙ (служ #,сФам,дтел,сладрес)
МАСТЕР (мастер #,оклад,сфкомп,ртел)
СБОРЩИК (сбощцик#^,тставка,сбкод,мастер #)
Отношение, полученное из исходной сущности
(СЛУЖАЩИЙ), содержит информацию, общую для
всех служащих. Отношения, полученные из ролей,
содержат специфическую для исполняемой роли ин-
информацию. Каждое порождаемое ролью отношение
связано с отношением, источником порождения кото-
которого послужила исходная сущность, через атрибут из
общего домена (в данном примере - номер страхового
полиса).
При рассмотрении диаграммы, показанной на рис.
8.6, следует обратить внимание на то обстоятельство,
что связь РУКОВОДИТ соединяет две роли одной ис-
исходной сущности. Такой тип связи называется рекур-
рекурсивным. Эта связь рекурсивна в том смысле, что с
точки зрения исходной сущности служащие руководят
служащими. Ничто не мешает также тому, чтобы ро-
роли одной исходной сущности соединялись связью с
ролями других исходных сущностей. В этом случае
связь уже не будет рекурсивной.
Глава 8 127
Для увеличения скорости доступа при запросах
проектировщик может рассмотреть возможность добав-
добавления в отношение СЛУЖАЩИЙ атрибута, определя-
определяющего кем конкретно является служащий - мастером
или сборщиком. Это позволит избежать необходимо-
необходимости организации поиска в отношениях МАСТЕР и
СБОРЩИК, цель которого состоит в определении ти-
типа работы отдельного служащего, а возможность -
обуславливается известным номером страхового поли-
полиса. Можно привести аргументы как за, так и против
включения дополнительного атрибута.
8.4. Более крупный пример ER-проектирования
Постановка задачи
Предположим, что необходимо спроектировать БД
для Топночской атлетической универсиады (ТАУ).
Предполагается, что БД будет использоваться члена-
членами руководящего состава конторы ТАУ. Эти уполно-
уполномоченные полностью контролируют деятельность лиги,
включая такие вопросы, как составление календаря
для всех спортивных мероприятий; приглашение на
работу всех должностных лиц на все соревнования,
проводимые в рамках лиги; проверка всех спортсме-
спортсменов на соответствие требованиям, предъявляемым ли-
лигой; хранение списков всех спортсменов, администра-
администраторов и тренеров всех колледжей, входящих в лигу.
Уполномоченный определил следующие параметры
как имеющие наибольшее значение:
1. Для каждого учебного заведения, входящего в
лигу:
официальное название колледжа
число студентов
все виды спорта, культивируемые учебным заве-
заведением
логограмма
название стадиона и его вместимость
название футбольного поля и его размеры
фамилия, адрес, номер домашнего телефона и
номер служебного телефона каждого из тех, кто
перечислен ниже:
президент колледжа
128 Дополнительные конструкции, используемые в ER-методе
спортивный директор
заведующий отделом спортивной информации
представитель от факультета по вопросам спор-
спорта
главный тренер по каждому виду спорта
2. Список всех одобренных лигой судей, содержа-
содержащий следующую информацию:
фамилия и номер страхового полиса
домашний адрес
номер домашнего телефона
вид спорта, который обслуживает судья
рейтинг по результатам предыдущего сезона
соревнования наступающего сезона, на которые
назначается данный судья
3. Список всех студентов-спортсменов, содержащий
следующую информацию:
фамилия и номер страхового полиса
домашний адрес
адрес колледжа
номер телефона колледжа
текущая профилирующая дисциплина
средняя оценка
число учебных часов, оставшихся до окончания
колледжа
число соревновательных сезонов по всем видам
спорта, которыми студент занимался
дата поступления в колледж
число текущих зачетных часов
число сданных зачетных часов за два последних
семестра
4. Расписание лиги на текущий год, содержащее
следующую информацию:
команда, в данной встрече выступающая в роли
хозяина
команда, в данной встрече выступающая в роли
гостя
дата и время каждой встречи
назначенные судьи
вид спорта, по которому предполагается проведе-
проведение соревнований
5. По каждому виду спорта, культивируемому в ли-
лиге, имеется комитет по правилам и один главный
тренер назначается лигой в качестве председателя
этого комитета.
Глава 8 129
Сделаем следующие допущения: расписание состав-
составляется для наступающего сезона; главный тренер тре-
тренирует только по одному виду спорта; некоторые
колледжи участвуют не во всех видах спорта, куль-
культивируемых лигой; некоторые люди имеют общие
служебные телефоны; в лиге представлены как муж-
мужские, так и женские виды спорта.
ER-диаграмма
При построении ER-диаграммы главная проблема
заключается в определении используемых сущностей;
в большинстве случаев множество сущностей не уни-
уникально. Для рассматриваемой проблемы было решено,
что представляющими интерес сущностями являются
КОЛЛЕДЖ, ВИДСПОРТА, СТУДЕНТ, СУДЬЯ и
СЛУЖАЩИЙ. Сущность СЛУЖАЩИЙ предназнача-
предназначалась для представления всех служащих из всех кол-
колледжей, которые имеют какие-либо официальные свя-
связи с лигой. Кроме того, сущность ГЛАВНЫЙ ТРЕ-
ТРЕНЕР нацелена на ее использование в качестве роли
сущностью СЛУЖАЩИЙ, в то время как ролями
сущности КОЛЛЕДЖ могут быть либо КОМАНДА
ХОЗЯЕВ, либо КОМАНДА ГОСТЕЙ, когда речь пой-
пойдет о спортивных соревнованиях. Окончательный вид
ER-диаграммы приведен на рис. 8.7. Обратите внима-
внимание на четырехстороннюю связь РАСПИСАНИЕ.
Предварительные отношения
Предварительные отношения, которые могут быть
получены на основании рис. 8.7, имеют вид:
КОЛЛЕДЖ (НазвКолледжа, )
СЛУЖАЩИЙ (Служ#, НазвКолледжа)
ХОЗЯЕВА (Хозяева, )
ГОСТИ (Гости, )
СУДЬЯ(судья#, )
ТРЕНЕР(Тренер#, ,Видспрт)
ВИДСПОРТА(Видспрт, )
СТУДЕНТ (Студент*, , НазвКолледжа)
КУЛЬТИВИРУЕТ(НазвКолледжа,Видспрт, )
УЧАСТВУЕТ(Видспрт,Студент#, )
РАСПИСАНИЕ(Хозяева,Гости,судья#,Видспрт,...)
130 Дополнительные конструкции, используемые в ER-методе
СЛУЖАЩИЙ
-*
ГЛАВНЫЙ
ТРЕНЕР
Назв Колледжа.. <ОБУЧАЕТСЯ
судьи#,..
Рис. 8.7. ER-диаграмма для Топночской Атлетической
Универсиады
После назначения остальных атрибутов были получе-
получены следующие отношения:
КОЛЛЕДЖ (НазвКолледжа,назв-сгадиона,
вмест—стадиона, назв-футб—пол я ,размеры-футб—поля,
список—студ)
СЛУЖАЩИЙ (Служ #,Фам-служ,адрес-служ,
дтел-служ,ртел-служ,должность,НазвКолледжа)
ХОЗЯЕВА(Хозяева)
ГОСТИ (Гости)
Глава 8 131
СУДЬЯ (сщья_# ,фам-суд,адрес-суд ,дтел-суд,
вид—спорта—в—котором—имеет—офиц-статус)
ТРЕНЕР (Тренер #,Видспрт)
ВИДСПОРТА(Видс1Щг,#-предс-ком-по-правилам)
СТУДЕНТ (Студент #,пол,возрастхредн-оценка,
общее-числв-зач-часов,адрес-студ,
НазвКолледжа,зач—часов—в—данном-семестре,
зач-часов-посл-два-семестра)
КУЛЬТИВИРУЕТ (НазвКолледжа,Видспрт)
УЧАСТВУЕТ (Видспрт,Студент #,соревн-<:езоны)
РАСПИСАНИЕ(ХозяеваХости,судья#,Видспрт,дата,
время—нач—сорёвнТ
Два отношения из последнего набора могут быть
исключены. Отношения ХОЗЯЕВА и ГОСТИ являются
унарными и не содержат полезной информации. То,
что они не содержат полезной информации, является
следствием отсутствия атрибутов, характерных только
для команды хозяев и команды гостей, не относящих-
относящихся к описанию колледжа в целом. Исключение ука-
указанных двух отношений позволяет получить так на-
называемые пробные проектные отношения.
ПРОБНЫЕ ПРОЕКТНЫЕ ОТНОШЕНИЯ
КОЛЛЕДЖ (НазвКолледжа,назв-стадиона,
вмест—стадиона, назв—футб—пол я,размеры—футб—пол я,
список-студ)
СЛУЖАЩИЙ (Служ #,фам-служ,адрес-служ,
дтел-слу ж, ртел-сл у ж должность, НазвКоллдежа)
СУДЬЯ (схаья_#,фам-суд,адрес-суд ,дтел-суд,
вид-спорта-в-котором-имеет-офиц-статус)
ТРЕНЕР(Тренер#,Видспрт)
ВИД СПОРТ А (Видспрт, #—преде—ком—по—правилам)
СТУДЕНТ (Студент #,пол,возраст,средн-оценка,
общее—число-зач—часов, адрес—студ,
НазвКолледж,зач—часов—в—данном-семестре,
зач—часов—поел—два—семестра)
КУЛЬТИВИРУЕТ(НазвКолледжа,Видспрт)
УЧАСТВУЕТ (Видспрт,Студент # ,соревн-сезоны)
РАСПИСАНИЕ(Хозяева,Гости,судья#,Видспрт,дата,
время—нач—соревн)
132 Дополнительные конструкции, используемые в ER-методе
Отношение РАСПИСАНИЕ в этом наборе является
единственным, которое требует модификации. Если
проанализировать несколько экземпляров этого отно-
отношения, то обнаружится присутствие наборов повторя-
повторяющихся данных, что является следствием назначения
более чем одного официального представителя на
каждое соревнование, проводимое лигой. Один способ
разрешения данной проблемы состоит в перепроекти-
перепроектировании той части ER-диаграммы, которая относится
к официальным представителям. Это необходимо сде-
сделать таким образом, чтобы в результате были полу-
получены НФБК-отношения. Другой способ решения той
же проблемы заключается в декомпозиции отношения
РАСПИСАНИЕ с помощью ФЗ. Эти подходы предла-
предлагаются в качестве упражнений в конце главы. Все
отношения из пробного набора необходимо проверить
на соответствие НФБК-форме, что также предлагается
в качестве упражнения в конце главы.
8.5. Задачи к гл. 8
1. Следующие задачи касаются последнего набора
проектных отношений из раздела 8.4:
а) начертите диаграмму ФЗ для каждого отноше-
отношения и проверьте, находятся ли эти отношения в
НФБК; если отношение не находится в НФБК, то
попытайтесь применить два подхода к решению: A)
изменение ER-диаграммы способом, приводящим к ге-
генерации НФБК-отношений; B) декомпозиция всех от-
отношений, не находящихся в НФБК, с целью перехо-
перехода к нормальной форме;
б) сформируйте экземпляры окончательных проект-
проектных отношений и покажите, как они будут использо-
использоваться при получении ответов на типичные запросы,
поступающие со стороны руководящего состава лиги.
2. Обсудите в деталях, как следующие уточнения по-
повлияют на ER-диаграмму, показанную на рис. 8.7, и
окончательные проектные отношения:
а) судья может обслуживать несколько видов спорта;
б) тренер может быть главным тренером по более
чем одному виду спорта;
в) некоторые колледжи не культивируют футбол и
не имеют футбольных полей;
Глава 8 133
г) удалите бинарные связи КУЛЬТИВИРУЕТ,
ОБУЧАЕТСЯ, УЧАСТВУЕТ и замените их одной
трехсторонней связью;
д) по некоторым видам спорта, например гольфу,
судьи не требуются;
3. Начертите ER-диаграмму и составьте отношения
для БД торговца подержанными автомобилями. Торго-
Торговец содержит штат служащих, в который входят
агенты по продаже, секретари и механики. Агенты по
продаже получают оклад плюс комиссионные, в то
время как все остальные служащие получают почасо-
почасовую оплату. Комиссионные составляют 5% для тех
агентов по продаже, стаж работы которых менее трех
лет, и 8% для тех, чей стаж составляет 3 и более
лет. Информация об имеющихся в наличии автомоби-
автомобилях включает в себя дату покупки, оценочную сто-
стоимость, объем ремонтных работ, которые должны
быть выполнены до выставления на продажу, прибли-
приблизительную стоимость этих работ, марку, модель, год
выпуска и основной цвет. Некоторые механики вы-
выполняют специальные виды работ, например, капи-
капитальный ремонт двигателя, исправление вмятин и др.
Можно добавить любые уместные по вашему мнению
атрибуты.
9- dBASE Ш-РЕАЛИЗАЦИЯ БД СЕКРЕТАРЯ
КЕГЕЛЬНОЙ ЛИГИ
Эта глава подразделяется на три основные части: 1 -
содержит примеры листингов четырех отношений,
формирующих БД секретаря кегельной лиги, для слу-
случая их реализации в dBASE III; 2 - содержит приме-
примеры того, как команды dBASE III могут быть исполь-
использованы при получении ответов на простые запросы; 3 -
посвящена углубленному обсуждению набора управля-
управляемых с помощью меню программных модулей dBASE
III, отвечающих на сложные запросы с помощью ко-
команд, встроенных в язык программирования СУБД.
БД реализована на базе IBM PC с объемом опера-
оперативной памяти 256 Кбайт, двумя двухсторонними ди-
дисководами и монохромным монитором. Системный
диск dBASE III всегда располагается на дисководе А,
программным модулям и файлам БД отводится диско-
дисковод В.
9.1. Анализ отношений БД с помощью тестовых
данных при использовании dBASE III
Прежде чем приступать к обсуждению специальных
запросов и различных программных модулей необхо-
необходимо проанализировать реальные отношения БД. Тес-
Тестовые данные БД были подготовлены с учетом следу-
следующих предположений:
1. В кегельной лиге состоят 6 команд.
2. В каждой команде 4 игрока.
3. Продолжительность сезона - четыре недели.
4. Ввод данных, охватывающих эти 4 недели, был
осуществлен с помощью стандартных команд dBASE III
APPEND и EDIT.
5. Все игроки участвовали во всех встречах.
Возможные изменения в некоторых из этих пред-
предположений приводятся в качестве упражнений в кон-
конце главы в перечне задач.
На рис. 9.1 - 9.4 показана структура каждого от-
отношения и соответствующие им тестовые данные.
(Следует помнить, что в терминологии dBASE III
Глава 9
135
каждое отношение называется файлом базы данных
(.dbf).)
. list structure
Structure for database : B:sched.dbf
Number of data records :
24
Date of last update : 05/09/86
Field Field name Type
1 TNUMB Numeric
2 WEEK Numeric
3 LANE Numeric
** Total **
Width
1
1
1
4
. list
TNUMB
1
2
3
4
5
6
1
2
3
4
5
6
1
CsJ
3
4
5
6
1
Dec 2
3
4
5
6
off
WEEK
1
1
1
1
1
1
2
2
2
2
CsJ
2
3
3
3
3
3
3
4
4
4
4
4
4
LANE
1
2
4
3
6
5
4
5
2
6
1
3
3
6
1
4
5
2
5
1
3
CsJ
4
6
(a)
F)
Рис. 9.1. Структура (а) и содержимое (б) отношения
SCHED
. use team
. list structure
Structure for database
Number of data records
Date of last update
Field Field name Type
В:team.dbf
6
05/10/86
Width
1 TNUMB
2 TNAME
3 CAPTN
** Total **
Numeric
Character
Character
1
15
15
32
Dec
(a)
136 dBASE Ill-реализация БД секретаря кегельной лиги
list
TNUMB
1
2
3
4
5
6
off
TNAME
AlleyCats
Ineons1stents
TenPins
HiRollers
Splitters
SandBaggers
CAPTN
Энн Джонс
Била Блак
Лиза Мур
Джил Миллер
Рой Лейн
Синди Фокс
(б)
Рис. 9.2. Структура (а) и содержимое (б) отношения
TEAM
При изучении данных в отношении BOWLER1) об-
обращает на себя внимание большой объем дублирова-
дублирования информации, касающейся адресов и телефонных
номеров. Является ли функциональной следующая за-
зависимость
phone -> stret
. use 1
. list
aowler
structure
Structure for
Number
* database : В:bowler.dbf
of data records :
Date of last
Field
1
2
3
4
5
Field
BNAME
TNUMB
PHONE
STRET
STAV6
** Total **
24
update : 05/20/86
name Type
Character
Numeric
Character
Character
Numeric
Width
15
1
8
20
3
48
(a)
Dec
^ Названия отношений пишутся прописными буквами, кроме тех
случаев, когда используется принятый в dBASE III способ записи
при указании принадлежности атрибутов отношений. Например, за-
запись bowler->bname означает, что в отношении BOWLER содержит-
содержится атрибут bname.
Глава 9
137
. list off
BNAME
Джин Адане
Стив Адане
Била Блак
Бонни Блак
Бо Блоу
Джо Блоу
Джо Браун
Сью Браун
Синди Фокс
Рэнди Фокс
Энн Джонс
Джон Джонс
Джой Лейн
Рой Лейн
Джил Миллер
Поль Миллер
Лиза Мур
Майк Мур
Джим Смит
Мари Смит
Рассел Тейлор
Руфь Тейлор
Дан Уайт
Джейн Уайт
TNUMB
5
5
2
2
2
2
3
3
6
6
1
1
5
5
4
4
3
3
1
1
6
6
4
4
PHONE
689-1234
689-1234
689-2345
689-2345
NONE
NONE
689-4567
689-4567
689-5678
689-5678
689-4365
689-4365
689-6789
689-6789
689-7890
689-7890
689-8901
689-8901
689-9012
689-9012
689-0123
689-0123
689-2143
689-2143
STRET
10 Robin St
10 Robin St
15 Bluebird Ln
15 Bluebird Ln
12 Meadowbrook Ln
12 Meadowbrook Ln
18 Bluebird Ln
18 Bluebird Ln
19 Cardinal St
19 Cardinal St
12 Finch Dr
12 Finch Dr
21 Sparrow Ct
21 Sparrow Ct
12 Robin St
12 Robin St
11 Lark Dr
11 Lark Dr
13 Finch Dr
13 Finch Dr
20 Cardinal St
20 Cardinal St
16 Robin St
16 Robin St
STAV6
HI
130
149
120
143
95
132
124
103
147
105
143
125
167
108
170
115
140
152
115
161
119
158
121
Рис. 9.З. Структура
BOWLER
F)
(а) и содержимое (б) отношения
. use 2
. list
scores
structure
Structure for
Number
Date oi
Field
1
2
3
4
5
* database : В:scores
of data records : 96
: last
Field
BNAME
WEEK
GAME1
GAME2
GAME3
** Total **
update : 05/20/86
.dbf
name Type Width
Character
Numeric
Numeric
Numeric
Numeric
15
1
3
3
3
26
Dec
(a)
g.
3
3
n
^CncOO)OJLn^OJ^LnO^OJOOOOOvnHOCO
со
л
с
11
ЭК «-1 cn^C
ш c\jro
000OrrCsinC7)CDOOCDCDrOO
<
О О
:
< Q.
О ОСЕ О
*£0)<
< Q. Q.Q.
U О ОСЕ О О) О) I- О О
t-t-OXXX**0)<X << СЕ Z Z
>)Sszo>)>)OOhaaz<<h«aaididi
)OZiOK«id»» ua)axsa>t>i>i<<
<оои«*о.о. <h-< ozx «о хх<<ш о<иии<ао. <(<uzzm
s <иэ •<: иэиэ s s о) < >» x s <иэ «t in in x s a) < >• x
X CD < XU3 ZS X <<UJ1CE <Л СЕ «3 ^ X CO < XUD XX X < < О Jt CE < -0 CE <0 *
X X < X OXQ.XOOfiXXU-e-OCEX<X0)<n)SXX<X OXQ.XOOfiXXU-e-OCES<X(U(nCE
>)OziO
о<иии
<иэ «t
u
<
E
vo
^•Hrbcsjr-tocomoesimbrsinrooevi
^^ tf* ^^ ^^ ^O ^^ ^^ O) ^^ ^^^^ ^} ^^ OJ^^ ^} ^} ^^ ^^ 00 C2 О) Ю ^^ ^^ ^^ ^^ ^^ ^^ CO CO O) CO »"H ^*H CO CO ^^ O) CO CO ^^ ^"^ ^^ O) ^^ ID ^"^ СЭ ^^
^^^ ^^^ ^^^ ^^^ ^^^ ^^^ ^^^ ^^^ ^^^ ^^^ ^^^ ^^^ ^^^ ^^^ ^^^ ^^^ ^^^ ^^^ ^^^ ^^^ ^^^ ^^^ ^^^ ^^^ ^^^ ^^^ ^^^ ^^^ ^^^ ^^^ ^^^ ^^^ ^^^ ^^4 ^^4 ^^^ ^^^ ^^^ ^^^ ^^^ ^^^ ^^^ ^^4 ^^^
">cororoo6«-iGOcbc\jc\jLn
JC\JC\iC\iC\iC\iC\iC\iC\i(\JC\iC\iC\iC\iC\iC\i
LU
t- LU Q. Q.
О 7 О О
Ч- < О. Q.Q. < Q. Q.Q.
ОО ^ U О ОСЕ О 0H) Н- ОО ^ U О ОСЕ О 0H) Н-
ч- zz^<o н-н-оххх^^ш<х << ее zz^<o н-н-оххх^^ш<х << се
Ч- <0 <0 <0 < >»Х X X О >»>»О Oh-CECE X < < I- «О О.О.Ю <0 «О < >»Х X X О >»>»О Oh-CECE X < < h- <0 Q.Q.
о <<<иэ >io z z о и «о юе-е- ш шсе х хсе>» >»>»<<<иэ >»о z z о и «о «»» о) о)се х хсе>» >»>»
<<lq о<оии<аа <н<шххю zx:<<lq о<оим<аа <н<а)ххю zz
4-» ш х <иэ -=1 иэиэ х х 0) < >» х х <иэ «с иэиэ х х 0) < >» х
COS X в < XU3 ZX X <<ОЛСЕ <Л СЕ «О * X в < XU3 ZX X <<иЛСЕ <Л XS «О *
о х о.х о о а х х и-е-оа х < х о) тсс х х < х о х о.х о о fi х х и-е-осЕ х < х о) «чсе
I
vo
I
S
S.
6
С/5
gs
О
II
X О
4
J2 en
о w
&
as
о и;
с
о ^
о
^
Глава 9 139
имеются две причины, по которым рассматриваемая
зависимость не может быть признана корректной ФЗ.
1. Очевидна возможность отсутствия телефонов у
двух людей, проживающих по разным адресам. В та-
таких случаях может быть использовано слово NONE
для номера телефона; однако адрес не будет функци-
функционально зависеть от номера телефона.
2. Возможно, что используемый в БД номер теле-
телефона является, скорее, номером, по которому с игро-
игроком можно связаться, а не номером домашнего теле-
телефона. Это также служит причиной некорректности
предложенной ФЗ.
С учетом этих предположений некоторые названия
улиц (адреса) и номера телефонов, представленные в
отношении BOWLER, дублируются, но не являются
избыточными.
9.2. Ответы на запросы секретаря лиги в dBASEIII
Цель данного раздела состоит в иллюстрации того
факта, что на простые запросы к БД секретаря мож-
можно получить ответы непосредственно с помощью ко-
команд dBASE III, не прибегая к использованию языка
программирования БД. Все запросы данного раздела
применяются к отношениям, представленным на рис.
9.1-9.4. В большинстве случаев ответ на запрос тре-
требует составления последовательности из двух или бо-
более базовых команд. Читателю рекомендуется создать
БД и выполнять каждый из предлагаемых запросов
по мере обсуждения. Если читателю предпочтительнее
работать с R:base 5000, а не с dBASE III, ему сле-
следует просто прочитать приведенные в данном разделе
запросы и реализовать БД, описанную в гл. 10.
В примерах, приводимых в настоящем разделе, по-
полагается, что системная дискета с dBASE III установ-
установлена на устройстве А, а дискета с отношениями БД
- на устройстве В. Прежде чем будет использована
какая-либо команда dBASE III, необходимо назначить
диск по умолчанию устройству В. Это выполняется с
помощью одной команды
SET DEFAULT TO В
140 dBASE III-реализация БД секретаря кегельной лиги
ЗАПРОС #1: "Найти имя-и-фамилию капитана ко-
команды с номером 4".
Это простейший из запросов, так как вся инфор-
информация, необходимая для его выполнения, содержится
в одном кортеже одного отношения. Кроме того, в
запросе содержится только одно условие: tnumb - 4.
Ответ на запрос будет получен в результате исполь-
использования следующих команд:
.USE team
.LIST OFF captn FOR tnumb = 4
В качестве ответа будет получено captn - Джил
Миллер.
ЗАПРОС #2: "Найти имена-и-фамилии всех игроков
с начальной результативностью, меньшей 100".
Этот запрос близок по существу к запросу #1 и
ответ на него может быть получен с помощью после-
последовательности команд
.USE bowler
.LIST OFF bname FOR stavg < 100
В качестве ответа будет получено bname = Джо
Блоу.
ЗАПРОС #3: "Найти имена-и-фамилии и номера те-
телефонов всех игроков команды с номером 3".
Этот запрос близок по характеру запросам #1 и
#2 в том, что требуемая информация расположена в
одном отношении; однако ответ на запрос занимает
несколько строк вывода, а не представляет собой еди-
единичное значение.
.USE bowler
.LIST OFF bname,phone FOR tnumb = 3
В качестве ответа будет получено
bname phone
Джо Браун 689-4567
Глава 9 141
Сью Браун 689-4567
Лиза Мур 689-8901
Майк Мур 689-8901
ЗАПРОС #4: "На какой площадке проводит свои
встречи команда с номером 5 в течение третьей не-
недели сезона?".
На этот запрос ответить ненамного сложнее, чем
на те, которые были приведены выше. Дополнитель-
Дополнительная сложность связана с тем, что при поиске данных
требуется учет двух условий. Ответ на запрос будет
получен с помощью последовательности команд
.USE sched
.LIST OFF lane FOR tnumb « 5 .AND. week = 3
Ответом на запрос будет lane = 5.
ЗАПРОС #5: "Найти имена-и-фамилии всех игроков,
живущих на улице Robin St."
Этот запрос требует просмотра поля stret каждой
записи отношения BOWLER с целью обнаружения в
нем символьной последовательности "Robin St". Это
может быть достигнуто с помощью $-оператора
.USE bowler
.LIST OFF bname FOR 'Robin St' $ (stret)
В ответ будет получено несколько имен-и-фамилий
bname
Джин Адаме
Стив Адаме
Джил Миллер
Поль Миллер
Дан Уайт
Джейн Уайт
При использовании $-оператора, любого другого опе-
оператора или функции, предназначенной для извлече-
извлечения подстроки из более длинной строки символов,
пользователь должен быть уверен в том, что в дан-
142 dBASE Ill-реализация БД секретаря кегельной лиги
ных отсутствуют строки, приводящие к получению
ошибочных данных. Например, адрес 1 BlueRobin
St" появится в качестве ответа на последний запрос,
хотя названием улицы и является "BlueRobin", а не
просто "Robin". Один из простых путей контроля за-
заключается в возврате полного названия улицы и ад-
адреса в выходных данных.
ЗАПРОС #6: "Сколько к настоящему времени прове-
проведено трехматчевых серий, в которых набрано в сумме
более 550 очков?".
Удовлетворить этот запрос можно с помощью ко-
команды COUNT. Ответ также требует проведения опе-
операции суммирования:
.USE scores
.COUNT FOR gamel + game2 + game3 > 550
Ответ: 2 - записи. Ответ говорит о том, что к на-
настоящему времени были проведены только две такие
трехматчевые серии.
ЗАПРОС #7: "Кто является капитаном команды со-
соперников команды с номером 5 на неделе с номером 3?"
Уровень квалификации, требующийся для ответа
на этот запрос, существенно выше того уровня, кото-
который был необходим для ответа на предыдущие запро-
запросы; данные, получаемые из одного отношения, долж-
должны быть использованы во втором отношении для по-
получения желаемого результата. Для ответа на запрос
секретарь лиги должен, прежде всего, получить ответ
на запрос #4 с целью определения площадки, назна-
назначенной команде с номером 5 на третьей неделе. От-
Ответом в данном случае будет lane - 5. Так как оп-
оппонентам назначаются смежные площадки, секретарь
вправе заключить, что противнику команды 5 будет
назначена площадка 6. Отсюда следует, что номер
команды (tnumb) соперников команды 5 на неделе 3
может быть получен с помощью последовательности
команд
LIST OFF tnumb FOR lane - 6 .AND. week = 3
Глава 9 143
Ответом будет tnumb = 2. Становится возможным
определение имени-и-фамилии капитана команды со-
соперников и делается это следующим образом:
.USE team
.LIST OFF captn FOR tnumb - 2
Таким образом ответом на исходный запрос будет
сарШ=Билл Блак.
Ответ на запрос #7 может быть получен различ-
различными путями. Предложенное выше решение является,
по всей видимости, наиболее прямолинейным и про-
простым для понимания начинающим пользователем
dBASE III. Второе решение базируется на использова-
использовании реляционного оператора JOIN (См. прил.А).
Первая часть второго решения совпадает с тем,
что было предложено выше: должна быть определена
площадка, назначаемая команде 5 на неделе 3 (lane = 5).
Отсюда также делается заключение, что команде со-
соперников назначена площадка 6. Далее, должна быть
выполнена последовательность команд
.CLEAR ALL
.SELECT 2
.USE team
.SELECT 1
.USE sched
JOIN WITH team TO result;
FOR lane = 6 .AND. week = 3 .AND.;
tnumb » team -> tnumb;
FIELDS team -> captn
.USE result
.LIST OFF
.USE
.ERASE result
Основное различие между двумя путями получения
ответа на запрос #7, заключается в явном использо-
использовании во второй версии оператора JOIN, в то время
как в первой версии соответствующие этому операто-
оператору действия проделаны секретарем мысленно.
Во втором решении команда CLEAR ALL была ис-
использована с целью предотвращения ALIAS-ошибки,
которая может возникнуть при установке рабочих об-
144 dBASE Ill-реализация БД секретаря кегельной лиги
ластей 1 и 2 с помощью команды SELECT. (Возника-
(Возникает эта ошибка в случае, если TEAM или SCHED бы-
были использованы в команде USE в предыдущих за-
запросах.) Команда USE без параметров в предпослед-
предпоследнем предложении закрывает только что созданный
файл result.dbf с тем, чтобы он мог быть уничтожен
с помощью следующей команды ERASE без возникно-
возникновения ошибки. Файл .dbf не может быть уничтожен
в открытом состоянии командой ERASE.
ЗАПРОС #8: "Какое общее число очков (без учета
гандикапа) набрал Билл Блак на конец недели 3?"
Вся информация, необходимая для ответа на этот
запрос, может быть найдена в отношении SCORES;
однако решение не выглядит простым, поскольку не-
необходимо выполнение как внутри-, так и межкортеж-
межкортежных арифметических операций. Упрощение решения
достигается с помощью функции SUM:
.USE scores
.SUM gamel + game2 + game3 TO total;
FOR bnamc - Билл Блак' .AND. week <= 3
.? total
Ответом будет: total = 1381.
ЗАПРОС #9: "Перечислить имена-и-фамилии всех
членов лиги, не являющихся членами команды
SandBaggers".
Наиболее просто ответ на этот запрос может быть
получен с помощью команды JOIN. (Пользователи
должны всегда внимательно следить за тем, чтобы
использование JOIN не приводило к генерации чрез-
чрезмерно большого числа кортежей. В предельно плохом
случае при выполнении операции JOIN над отноше-
отношениями, одно из которых содержит "т" кортежей, а
другое - "п" кортежей, в результате может быть по-
получено m * n кортежей.) Желаемый результат по за-
запросу #9 может быть получен с помощью
.CLEAR ALL
.SELECT 2
Глава 9 145
.USE team
.SELECT 1
.USE bowler
JOIN WITH team TO result FOR;
team -> tname; = 'SandBaggers' .AND.;
tnumb <> team->tnumb FIELDS bowler -> bname
.USE result
.LIST OFF
.USE
.ERASE result
В результате будет получено 20 имен-и-фамилий.
ЗАПРОС #10: "Какие игроки на неделе 3 провели
лучшие, чем Лиза Мур, трехматчевые серии (без
учета гандикапа)?"
Ответ на этот запрос может быть получен в два
этапа: на первом этапе определяется число набранных
Лиза Мур очков в трехматчевой серии на неделе 3,
на втором этапе выявляются имена-и-фамилии игро-
игроков, достигших лучшего результата. Одно из решений
следующее:
.CLEAR ALL
.USE scores
LIST OFF gamel + game2 + game3 FOR;
bname - 'Лиза Мур' .AND. week ■ 3
Результат трехматчевой серии 332 очка.
LIST OFF bname FOR gamel + game2 + game3 > 332;
.AND. week = 3
В окончательном ответе дается перечень из 19
имен-и-фамилий.
9.3. Основное меню заранее подготовленных запросов
В предыдущем разделе были детально рассмотрены
пути получения ответов на некоторые простые запро-
запросы. При этом предполагается, что секретарь кегельной
лиги вводит команды непосредственно с терминально-
терминального устройства. По мере усложнения запросов последо-
146 dBASE Ill-реализация БД секретаря кегельной лиги
вателыюсти команд, необходимые для получения от-
ответов, становятся слишком длинными и сложными
для их непосредственного ввода секретарем. В таких
случаях список потенциально полезных запросов мо-
может быть помещен в меню, которое и выводится на
экран терминала. Выбор секретарем одного из запро-
запросов приводит к исполнению программы, написанной
на языке программирования dBASE III, реализующий
ответ на этот запрос. В последующих разделах этой
главы детально рассматривается такое меню. Запросы,
помещенные в меню, признаны разумными, однако
список их не является исчерпывающим и может быть
расширен без излишних сложностей.
Образец меню, видимый секретарем во время ис-
исполнения программы, показан на рис. 9.5. Главный
программный модуль, осуществляющий отображение
указанного меню и принимающий выбор запроса, на-
называется "sdbmain.prg". Этот модуль показан на
рис. 9.6. При выборе любой из первых пяти возмож-
возможностей осуществляется исполнение некоторого другого
программного модуля. Некоторые из этих модулей
второго уровня осуществляют вызов других модулей,
решающих более мелкие задачи. Все программные
модули, относящиеся к главному меню, детально об-
обсуждаются в следующих разделах этой главы.
МЕНЮ ЗАПРОСОВ ПО СОСТОЯНИЮ В НОЧЬ НА ПОНЕДЕЛЬНИК
1 - СТАТИСТИЧЕСКИЕ ДАННЫЕ ПО ОТДЕЛЬНОМУ ИГРЕКУ
2 - ОБЩЕЕ ЧИСЛО ОЧКОВ КАЖДОЙ КОМАНДЫ
3 - ВЫВОД ПОЛОЖЕНИЯ КОМАНД
4 - ВЫВОД РАСПИСАНИЯ ВСТРЕЧ ДЛЯ ДАННОЙ НЕДЕЛИ
5 - ГЕНЕРАЦИЯ ОТЧЕТА О РЕЗУЛЬТАТАХ СЕЗОНА
6 - ВОЗВРАТ НА УРОВЕНЬ КОМАНД DBASE III
Выберите альтернативу из предложенного меню вариантов
Рис. 9.5. Главное меню БД секретаря кегельной лиги
Глава 9 147
. type sdbmain.prg
***********ПРОГРАММА ГЛАВНОГО МЕНЮ ДЛЯ БД СЕКРЕТАРЯ**********
* Имя программы: " sdbmain.prg"
* Автор Глен А.Джексон
* Оклендский университет, Рочестер, Ml 48063
CLEAR
SET TALK OFF
CLOSE DATABASES
SET DEFAULT TO В
PUBLIC max_wk,bavg,hndkp,saveit
* Вывод меню запросов для пользователя и выбор альтернативы
DO WHILE .t.
CLEAR
0 5,10 SAY 'МЕНЮ ЗАПРОСОВ ПО СОСТОЯНИЮ В НОЧЬ НА ПОНЕДЕЛЬНИК*
в С 1 Л QAY 'в—я— ——~ —_s—_——— ——— ——ш «в— — — к ккк хкк '
в э!10 SAY ' 1 - СТАТИСТИЧЕСКИЕ ДАННЫЕ ПО ОТДЕЛЬНОМУ ИГРОКУ'
0 11,10 SAY f 2 - ОБЩЕЕ ЧИСЛО ОЧКОВ КАЖДОЙ КОМАНДЫ'
0 13,10 SAY ' 3 - ВЫВОД ПОЛОЖЕНИЯ КОМАНД'
0 15,10 SAY ' 4 - ВЫВОД РАСПИСАНИЯ ВСТРЕЧ ДЛЯ ДАННОЙ НЕДЕЛИ'
0 17,10 SAY ' 5 - ГЕНЕРАЦИЯ ОТЧЕТА О РЕЗУЛЬТАТАХ СЕЗОНА'
0 19,10 SAY ' 6 - ВОЗВРАТ НА УРОВЕНЬ КОМАНД DBASE III'
@ 22,10 SAY 'Выберите альтернативу из пеню вариантов'
WAIT ' ' ТО choice
DO CASE
CASE choice * 'Г
STORE 'SDB' TO eos_check
DO brbwlrst
CASE choice » '2'
DO btteampns
CASE choice « '3'
DO b:teamstd
CASE choice * '4'
DO b:wkschdl
CASE choice * '5'
DO b:eosrpt
CASE choice = '6'
CLEAR
CLOSE DATABASES
0 5,10 SAY "БД СЕКРЕТАРЯ ЗАКРЫТА"
0 6,10 SAY 'ВОЗВРАТ НА КОМАНДНЫЙ УРОВЕНЬ DBASE III'
SET DEFAULT TO A
SET TALK ON
RETURN
OTHERWISE
0 22,10 SAY 'ВЫ ВВЕЛИ НЕПРАВИЛЬНЫЙ НОМЕР !!!!'
DO b:delay
ENDCASE
CLOSE DATABASES
ENDDO
Рис. 9.6. Главный модуль БД секретаря: sdbmain.prg
148 dBASE Ill-реализация БД секретаря кегельной лиги
Логику модуля sdbmain.prg отражает приведенная
ниже последовательность действий, исполнение кото-
которой завершается при выборе возможности 6.
1. Отобразить основное меню.
2. Ждать ввода.
3. Если ввод корректен, то
передать управление соответствующему про-
программному модулю
Иначе
вывести сообщение об ошибке; выдержать
приблизительно двухсекундную паузу; вер-
вернуться на шаг 2.
. type delay.ргд
**************** М0ДУЛЬ ДВУХСЕКУНДНОЙ ПАУЗЫ **********
*
*Имя модуля "delay.ргд"
*Автор Глен А.Джексон
*Оклендский университет, Рочестер, Ml 48063
*Этот модуль обеспечивает приблизительно двухсекундную паузу
*перед возвратом управления в вызывающую программу
*
*Модуль вызывается из sdbmain.prg
*
STORE 0 ТО delay_ctr
DO WHILE delay_ctr < 50
STORE delay_ctr + 1 TO delay_ctr
ENDDO
RETURN
Рис. 9.7. Модуль, обеспечивающий двухсекундную па-
паузу: delay.prg
Программный модуль delay.prg незначителен по
объему и его вызов осуществляется из sdbmain.prg в
случае необходимости двухсекундной задержки. Текст
модуля delay.prg приведен на рис. 9.7. Единственное
действие этой программы состоит в выполнении цикла
столько раз, сколько необходимо для истечения при-
приблизительно двух секунд.
Глава 9 149
ЕСЛИ eos check = 'SDB' ПРИ ВЫПОЛНЕНИИ BWLRST.PR6:
1. Выполнение модуля findwk.prg с целью нахождения последней
недели, для которой результаты встреч (scores) были занесены в
отношение SCORES. Значение возвращается в "max_wk".
2. Ввод номера недели сезона, по которой требуются статистиче-
статистические данные, в переменную "wk" и проверка правильности введен-
введенного значения.
3. Ввод имени-и-фамилии игрока, о котором требуется получить
статистическую информацию, в переменную "паше" и проверка пра-
правильности введенного значения.
4. Каждый кортеж в отношении SCORES, в котором значение атри-
атрибута bname совпадает со значением паше и значение атрибута
week меньше или равно значению wk, подвергается следующим дей-
действиям:
a) проверка gamel, game2, датеЗ на предмет превышения ка-
каким-либо из содержащихся в них значений текущей величины
hi_game; в случае подтверждения соответствующее значение
сохраняется в h1_game;
b) проверка суммы gamel, game2, датеЗ на предмет превышения
ею текущего значения hi_series; в случае подтверждения эта
сумма сохраняется в hi_series;
c) прибавление суммы gamel, game2 и датеЗ к величине
tot_pins.
5. Вычисление результативности данного игрока, гандикапа и со-
сохранение их в переменных bavg и hndkp соответственно.
6. Вывод результатов.
ЕСЛИ eos_check = 'EOS' ПРИ ВЫПОЛНЕНИИ BWLRST.PRG:
Блоки с номерами 1, 2, 3 и 6 опускаются. Выполняются только
блоки с номерами 4 и 5.
Рис. 9.8. Логика модуля bwlrst.prg
9.4. Программный модуль BWLRST.PRG
Этот модуль вызывается из программы sdbmain.prg в
том случае, когда осуществляется выбор возможности
150 dBASE Ill-реализация БД секретаря кегельной лиги
- СТАТИСТИЧЕСКИЕ ДАННЫЕ ПО ОТДЕЛЬНО-
ОТДЕЛЬНОМУ ИГРОКУ". Результатом выполнения этого модуля
являются вычисления и вывод статистических данных,
характеризующих конкретного игрока, на конец конк-
конкретной недели сезона. Модуль запрашивает порядко-
порядковый номер недели, на конец которой требуются ста-
статистические данные, а также имя-и-фамилию игрока,
Модуль проверяет достоверность как имени-и-фами-
лии, так и номера недели. Общая логика модуля
приведена на рис. 9.8, реализация в dBASE III - на
рис. 9.9, а типичные выходные данные модуля - на
рис. 9.10.
. type bwlrst.prg
******************
*Имя процедуры: "bwlrst.prg"
*Автор Глен А.Джексон
*Оклендский университет, Рочестер, Ml 48063
*
*Данная процедура осуществляет вычисления и вывод следующих
^статистических данных, касающихся отдельного игрока: High*
*series (лучшая серия),High-game (лучшая игра), Total pins
*(общее число набранных очков),average (результативность) и
^handicap (гандикап). Во всех статистических данных учтены все
^состоявшиеся к тому времени встречи.
*
^Процедура вызывается из sdbmain.prg
CLEAR
*
^Инициализация переменных текущего суммирования и переменных-
*счетчиков
STORE 0 ТО h1_ser1es,tot_p1ns,h1_game
STORE I TO ctr
SELECT 1
USE b:scores
*
^Выполнение следующей части кода осуществляется только в слу-
*чае вызова из главного меню
*
IF eos_check = 'SDB'
*
*Поиск последней недели, для которой были введены результаты,
*через переменную maxwk.
Рис. 9.9. Модуль bwlrst.prg
Глава 9 151
DO b:findwk
<*
STORE ' ' TO wk
DO WHILE .t.
9 7.15 SAY 'ЕСЛИ ВАМ ТРЕБУЮТСЯ ПОСЛЕДНИЕ СТАТ. ДАННЫЕ/
9 8.15 SAY 'ВВЕДИТЕ ' + STR(max_wk.2)+ ;
' НОМЕР ПОСЛЕДНЕЙ НЕДЕЛИ. ПО КОТ. ВВОДИЛИСЬ ДАННЫЕ'
9 9,15 SAY 'ИНАЧЕ ВВЕДИТЕ НОМЕР ИНТЕРЕСУЮЩЕЙ ВАС НЕДЕЛИ'
9 11.15 GET wk
READ
IF VAL(wk) > max_wk .OR. VAL(wk) < 1
9 15,10 SAY 'НЕПРАВИЛЬНЫЙ ВВОД НОМЕРА НЕДЕЛИ !!!!'
DO b:delay
STORE ' ' TO wk
CLEAR
ELSE
CLEAR
EXIT
ENDIF
ENDDO
*Ввод имени-и-фамилии игрока и проверка их корректности
*
STORE '
*
DO WHILE
9 7.20
9 8.20
READ
.t.
SAY
GET
COUNT FOR
IF check -
9 12.
9 13.
DO b:
STORE
CLEAR
ELSE
EXIT
ENDIF
ENDDO
ENDIF
20
20
' TO
-УКАЖИТЕ ИМЯ И
name
bname = name TO
0
SAY 'УКАЗАННЫЕ
SAY 'ПРОВЕРЬТЕ
delay
»
name
ФАМИЛИЮ ИГРОКА, напр. Джо Джонс
check
ИМЯ И ФАМИЛИЯ В БД ОТСУТСТВУЮТ'
ИХ И ПОВТОРИТЕ ВВОД'
ТО name
GOTO TOP
DO WHILE ctr <* VAL(wk)
LOCATE FOR bname « name .AND. week = ctr
IF gamel > hi_game
STORE gamel TO hi_game
ENDIF
Рис. 9.9. (Продолжение)
152 dBASE III-реализация БД секретаря кегельной лиги
IF game2 > hi_game
STORE game2 TO hi_game
ENDIF
IF game3 > hi_game
STORE датеЗ ТО hi_game
ENDIF
STORE gamel + game2 + датеЗ ТО tot3
STORE tot_p1ns + tot3 TO tot_pins
IF tot3 > hi_series
STORE tot3 TO hi_series
ENDIF
STORE ctr + 1 TO ctr
ENDDO
STORE INT(tot_p1ns/(VAL(wk)*3)) TO bavg
IF bavg < 200
STORE INT(B00 - bavg)* 0.75) TO hndkp
ELSE
STORE 0 TO hndkp
ENDIF
*Эта часть программы выполняется только в случае вызова из
^главного меню
IF eos_check = 'SDB'
CLEAR
0 7,20 SAY 'СТАТИСТИКА AAfl'+TRIM(bname)+'HA КОНЕЦ НЕДЕЛИ '+wk
9 8,20 SAY '=========================================='
0 10,20 SAY 'СРЕДНЕЕ ЧИСЛО ОЧКОВ ЗА ИГРУ: '+ STR(bavg,3)
0 12,20 SAY 'ОБЩЕЕ ЧИСЛО ОЧКОВ - БЕЗ ГАНДИКАПА: '+;
STR(tot_p1ns,4)
0 14,20 SAY 'ЛУЧШИЙ РЕЗУЛЬТАТ ЗА ИГРУ НА СЕГОДНЯ: ' +;
STR(h1_game,3)
0 16,20 SAY 'ЛУЧШАЯ СЕРИЯ НА СЕГОДНЯ: ' + STR(h1_ser1es,3)
0 18,20 SAY 'ТЕКУЩИЙ ГАНДИКАП: ' + STR(hndkp,3)
0 22,20 SAY ' '
WAIT
CLEAR
ENDIF
RETURN
Рис. 9.9. (Окончание)
Два момента, связанные с модулем bwlrst.prg, воз-
возможно, нуждаются в дополнительном освещении. Пер-
Первый заключается в появлении двух предложений "IF
eos-check='SDB" в теле модуля. Модуль bwlrst.prg
вызывается из двух различных программных модулей:
sdbmain.prg и eosrpt.prg. Когда bwlrst.prg вызывается
Глава 9 153
из eosrpt.prg, то большая часть логики модуля пропу-
пропускается, так как в этом случае имя-и-фамилия игро-
игрока и порядковый номер недели уже известны. Перед
вызовом bwlrst.prg из sdbmain.prg в eos-check зано-
заносится значение "SDB", в то время как перед вызовом
из eosrpt.prg в eos-check заносится значение "EOS".
Второй момент связан с вычислением величины
гандикапа. Гандикап определяется как три четвертых
от разности между текущим значением результатив-
результативности игрока и числом 200, причем отрицательные
значения для гандикапа не допускаются. Результатив-
Результативность игрока и его гандикап являются целочисленны-
целочисленными величинами, полученными с помощью отбрасыва-
отбрасывания дробной части, но не округления. Если бы от-
отбрасывание не использовалось в обоих случаях, то
это в значительной степени изменило бы положение
команд.
СТАТИСТИСТИКА ДЛЯ Джин Адаме НА КОНЕЦ НЕДЕЛИ 3
СРЕДНЕЕ ЧИСЛО ОЧКОВ ЗА ИГРУ: 117
ОБЩЕЕ ЧИСЛО ОЧКОВ - БЕЗ ГАНДИКАПА: 1059
ЛУЧШИЙ РЕЗУЛЬТАТ ЗА ИГРУ НА СЕГОДНЯ: 134
ЛУЧШАЯ СЕРИЯ НА СЕГОДНЯ: 381
ТЕКУЩИЙ ГАНДИКАП: 62
Рис. 9.10. Типичный результат, получаемый при вы-
выборе альтернативы " в главном меню
9.5. Программный модуль TEAMPNS.PRG
Этот модуль вызывается из sdbmain.prg в том случае,
когда выбирается возможность - ОБЩЕЕ ЧИСЛО
ОЧКОВ КАЖДОЙ КОМАНДЫ". Данный программ-
программный модуль обращается к findwk.prg с целью опреде-
определения последней недели, по которой в отношение
SCORES вносились данные, после чего определяет и
выводит общее число "чистых" очков (без учета ган-
гандикапа), набранных каждой командой. Пример выход-
выходных данных модуля teampns.prg приведен на рис.
9.11. Логика модуля представлена на рис. 9.12, а
собственно модуль показан на рис. 9.13.
1
2
3
4
5
6
AlleyCats
Inconsistents
TenPins
HiRollers
Splitters
SandBaggers
154 dBASE Ш-реализация БД секретаря кегельной лиги
ОБЩЕЕ ЧИСЛО ЧИСТЫХ ОЧКОВ НА КОНЕЦ НЕДЕЛИ 4
НОМЕР КОМАНДЫ НАЗВАНИЕ КОМАНДЫ ОБЩЕЕ ЧИСЛО ОЧКОВ
6257
6172
6147
6798
6580
6534
Рис. 9.11. Пример результатов выполнения модуля
teampns.prg
1. Выполнение модуля findwk.prg с целью определения послед-
последней недели, для которой в отношение SCORES были внесены
данные о показанных результатах.
2. Вывод заголовка для данных, которые будут выведены ниже.
3. Для каждой команды (используя переменную ctr одновремен-
одновременно как номер команды и счетчик цикла) ВЫПОЛНИТЬ следующее:
а) соединить оператором JOIN отношения SCORES и BOWLER,
где bow1er->tnumb = номер выбранной команды и bowler-
>bname = scores->bname, с целью формирования нового отно-
отношения ТЕМР2, содержащего только атрибуты (FIELDs-ПОЛЯ)
gamel, game2 и датеЗ; ТЕМР2 будет содержать результаты
всех встреч для одной команды по состоянию на текущую не-
неделю (включительно);
б) определить название команды с помощью отношения TEAM,
воспользовавшись идентифицирующим команду номером; сохра-
сохранить название команды как "name";
в) используя отношение ТЕМР2, вычислить сумму набранных
данной командой очков и вывести общий командный результат;
г) удалить оператором ERASE временное отношение temp2.dbf
из БД;
д) добавить приращение к номеру команды (ctr) с целью по-
получения его следующего значения
Рис. 9.12. Логика программного модуля teampns.prg
Глава 9 155
*******************************************
. type teampns.prg
*******************
*Имя процедуры: "teampns.prg"
*Автор Глен А.Джексон
*Оклендский университет, Рочестер, Ml 48063
*Данная процедура предназначена для вывода общего числа очков,
^набранных каждой командой на данный момент времени текущего
*сезона
^Процедура вызывается из sdbmain.prg
CLEAR
CLOSE DATABASES
SELECT 1
USE b:bowler
SELECT 2
USE b:scores
^Нахождение последней недели, по которой данные о результатах
*были введены в БД - возврат через переменную maxwk
00 b:findwk
*
*Вывод заголовка данных
в 5,20 SAY 'ОБЩЕЕ ЧИСЛО ЧИСТЫХ ОЧКОВ НА КОНЕЦ НЕДЕЛИ Ч;
STR(max_wk,3)
D,cU ЬАТ в== а—«аа —в—а— s_3_s-s-3=sss_r в ass
в 7,20 SAY 'НОМЕР КОМАНДЫ НАЗВАНИЕ КОМАНДЫ ОБЩЕЕ ЧИСЛО ОЧКОВ1
в 8,20 SAY ' '
*
^Вычисление и вывод данных
*
STORE I TO ctr
DO WHILE ctr <= 6
SELECT bowler
JOIN WITH scores TO b:temp2 FOR tnumb « ctr .AND. ;
bname - scores->bname FIELDS gamel,game2,game3
SELECT 3
USE b:team
LOCATE FOR tnumb = ctr
STORE tname TO name
SELECT 4
USE b:temp2
SUM gamel,game2,game3 TO gml,gm2,gm3
9 &*ctr,20 SAY STR(ctr,4) + ' '+name+' ' +STR(gml+gm2+gm3)
USE
ERASE b:temp2.dbf
STORE ctr+1 to ctr
ENDDO
0 22,10 SAY ' '
WAIT
RETURN
Рис. 9.13. Программный модуль teampns.prg
156 dBASE Ill-реализация БД секретаря кегельной лиги
К применению любого оператора JOIN в програм-
программах следует подходить осторожно, не допуская полу-
получения в результате таких применений отношений,
слишком больыих для хранения в том объеме памя-
памяти, который доступен на используемом диске. Генери-
Генерируемое оператором JOIN, используемым в модуле
teampns.prg, отношение ТЕМР2 всегда будет состоять
из
C игры/в неделю) * D игрока/в команде) * (N недель)
кортежей. Например, для четвертой недели сезона (N - 4)
каждое построенное отношение ТЕМР2 дает в итоге
48 кортежей.
. type findwk.prg
*************************** FINDWK PRG
*Имя модуля: "findwk.prg"
*Автор Глен А.Джексон
*Оклендский университет, Рочестер, Ml 48063
*
*Данный модуль предназначен для определения наибольшего
^значения номера недели, занесенного в поле атрибута week, ли-
либо ^отношения scores.dbf, либо отношения sched.dbf. Модуль
*выполняется в предположении, что либо
*scores.dbf, либо sched.dbf находится в активном состоянии
*
^Вызывается из следующих модулей:
* bwlrst.prg, teampns.prg, teamstd.prg, wkschdl.prg и
*eosrpt.prg
^Наибольшее значение возвращается в виде целой переменной
*max_wk
*
9 10,15 SAY 'ПРОИЗВОДЯТСЯ ВЫЧИСЛЕНИЯ — ПОДОЖДИТЕ НЕМНОГО !'
maxwk ■ 0
GOTO TOP
DO WHILE .NOT. EOF()
IF week > max_wk
max_wk = week
ENDIF
SKIP
ENDDO
*
CLEAR
RETURN
Рис. 9.14. Программный модуль findwk.prg
Глава 9 157
Модуль teampns.prg вызывает findwk.prg с целью
определения последней недели сезона, для которой
набранные очки были внесены в отношение SCORES.
Этот модуль приведен на рис. 9.14. Логика модуля
требует одного пояснения. Цель модуля состоит в вы-
выявлении наибольшего значения атрибута week для те-
текущего активного файла БД. Это значит, что отно-
отношение (.dbf), в котором будет осуществляться поиск,
должно быть активировано до начала выполнения мо-
модуля findwk.prg. Так как в оба отношения SCORES и
SCHED включено поле week в качестве атрибута,
следовательно, одно из этих отношений может быть
активировано до обращения к модулю findwk.prg. Ес-
Если SCORES является активным, то значение week оп-
определяется как последняя неделя, для которой резуль-
результаты встреч были занесены в БД; однако если актив-
активным является отношение SCHED, то значение week
определяется как последняя неделя сезона. Модуль
findwk.prg используется для определения обоих значе-
значений поля week.
РАСПИСАНИЕ НА НЕДЕЛЮ 2 СЕЗОНА
КОМАНДА НОМЕР ПЛОЩАДКИ
AlleyCats 4
Ineonsistents 5
TenPins 2
HiRollers 6
Splitters 1
SandBaggers 3
Рис. 9.15. Типичный результат выполнения модуля
wkschdl.prg
9.6. Программный модуль wkschdl.prg
Этот программный модуль вызывается из sdbmain.prg
в случае выбора в главном меню возможности -
ВЫВОД РАСПИСАНИЯ ВСТРЕЧ ДЛЯ ДАННОЙ НЕ-
НЕДЕЛИ". Результатом выполнения этого модуля явля-
является вывод таблицы названий команд и номеров на-
назначаемых им площадок на данную неделю сезона.
Модуль запрашивает на входе номер недели, заносит
158 dBASE Ill-реализация БД секретаря кегельной лиги
это значение в переменную "invar и, прежде чем
приступать к выполнению, верифицирует это значе-
значение. Типичные выходные данные, получаемые в ре-
результате выполнения этого модуля, приведены на
рис. 9.15. Логика модуля отражена на рис. 9.16, а
его текст - на рис. 9.17.
1. Выполнение модуля findwk.prg с целью нахождения послед-
последней недели сезона. Это значение возвращается через перемен-
переменную "max_wk". (Обратите внимание, что отношение SCHED поме-
помещается в USE до вызова findwk.prg, и, таким образом, именно
в отношении SCHED осуществляет поиск модуль findwk.prg.)
2. Ввод номера (переменная "Inval") той недели, для которой
требуется вывести календарь, и верификация правильности
этого номера. Повторение этой процедуры до тех пор, пока не
будет введено корректное значение.
3. Соединение оператором JOIN отношений TEAM и SCHED с уче-
учетом выполнения условий sched->week = Inval, sched->tnumb =
team->tnumb с целью формирования нового отношения, TEMPI,
которое содержит только атрибуты tname и lane.
4. Вывод заголовка.
5. Вывод значений tname и lane из TEMPI.
6. Удаление оператором ERASE отношения TEMPI из БД.
Рис. 9.16. Логика программного модуля wkschdl.prg
. type wkschdl.prg
*Имя процедуры: "wkschdl.prg"
*Автор Глен А.Джексон
*Оклендский университет, Рочестер, Ml 48063
*Данная процедура осуществляет вывод календаря на текущую
*неделю
*На вход поступает номер недели, для которой требуется
^календарь
^Результатом является календарь, содержащий названия команд и
*номера назначаемых им площадок
^Процедура вызывается из sdbmain.prg
CLEAR
CLOSE DATABASES
Рис. 9.17. Программный модуль wkschdl.prg
Глава 9 159
SELECT 1
USE b:sched
STORE ' ' TO inval
*Нахождение последней недели сезона — значение возвращается в
'переменную max_wk
DO b:findMk
DO WHILE .t.
0 7,10 SAY 'ВВЕДИТЕ НОМЕР НЕДЕЛИ, ДЛЯ КОТОРОЙ';
' ТРЕБУЕТСЯ КАЛЕНДАРЬ'
в 9,10 SAY 'ТОЛЬКО ЗНАЧЕНИЯ В ДИАПАЗОНЕ ОТ 1 ДО ' +;
STR(max_wk,2)
0 11,10 GET Inval
READ
IF VALAnval) > max_wk .OR. VAL(inval) < 1
в 15,10 SAY 'НЕКОРРЕКТНЫЙ НОМЕР НЕДЕЛИ !!!!!'
DO b:de1ay
STORE • ' TO Inval
CLEAR
ELSE
EXIT
ENDIF
ENDDO
0 15,10 SAY 'ПОЖАЛУЙСТА, ПОДОЖДИТЕ - ВЫПОЛНЯЮТСЯ ВЫЧИСЛЕНИЯ !'
SELECT 2
USE team
SELECT sched
JOIN WITH team TO b:tempi FOR week = VAL(inval) .AND. ;
tnumb * team->tnumb FIELDS team->tname, lane
*Вывод календаря на экран
CLEAR
0 5,10 SAY ' РАСПИСАНИЕ НА НЕДЕЛЮ ' + inval + ' СЕЗОНА'
0 6,10 SAY ' e===M==s=====e=====5S===ss===ss'
в 7,10 SAY ' КОМАНДА НОМЕР ПЛОЩАДКИ'
0 8,10 SAY ' '
SELECT 3
USE b:tempi
GOTO TOP
STORE 9 TO lineno
DO WHILE .NOT. EOF()
в lineno,10 SAY ' ' + tname + ' '+ STR(lane,2)
STORE 11neno+l TO lineno
SKIP
ENDDO
0 22,10 SAY ' '
WAIT
CLEAR
CLOSE DATABASES
ERASE b:tempi.dbf
RETURN
Рис. 9.17. (Окончание)
160 dBASE Ill-реализация БД секретаря кегельной лиги
Сердцевиной реализации вновь является оператор
JOIN, с помощью которого создается временное отно-
отношение TEMPI. В этом случае отношения TEAM и
SCHED соединяются по атрибуту tnumb, так что при
формировании выходных данных будет возможно ис-
использовать название команды, а не номер.
9Л- Программный модуль EOSRPT.PRG
Этот программный модуль вызывается из sdbmain.prg
в случае выбора в главном меню возможности -
ГЕНЕРАЦИЯ ОТЧЕТА О РЕЗУЛЬТАТАХ СЕЗОНА".
Результатом выполнения модуля является определение
и вывод имен-и-фамилий тех игроков, кто A) набрал
наибольшее число очков в одной игре сезона, B)
провел лучшую трехматчевую серию сезона, C) за-
закончил сезон с наивысшей результативностью.
Пример выходных данных этого модуля при ис-
использовании им данных из БД показан на рис. 9.18.
Логика модуля описана на рис. 9.19, сам модуль по-
показан на рис. 9.20.
ОТЧЕТ 0 РЕЗУЛЬТАТАХ СЕЗОНА
ЛУЧШИЙ РЕЗУЛЬТАТ ЗА ОДНУ ИГРУ - 202 ОЧКА - ПОКАЗАН ИГРОКАМИ:
Рой Лейн
Поль Миллер
Рассел Тейлор
ЛУЧШИЕ СЕРИИ ИЗ ТРЕХ МАТЧЕЙ - 559 ОЧКОВ - ПРОВЕЛИ ИГРОКИ:
Рой Лейн
Поль Миллер
ЛУЧШАЯ РЕЗУЛЬТАТИВНОСТЬ - 179 ОЧКОВ - ПОКАЗАНА ИГРОКАМИ:
Поль Миллер
Рис. 9.18. Выходные данные модуля eosrpt.prg для
рассматриваемой БД
Глава 9 161
1. Выполнение модуля findwk.prg с целью нахождения послед-
последней недели сезона. Это значение возвращается через перемен-
переменную "maxwk".
2. Инициализация необходимых переменных.
3. ВЫПОЛНЕНИЕ следующей последовательности действий до ис-
исчерпания кортежей в отношений BOWLER:
а) сохранение значения bname из текущего кортежа игрока в
"name"
б) выполнение программного модуля bwlrst.prg (после при-
присвоения переменной eoscheck значения 'EOS') с целью опре-
определения для данного игрока наилучшего результата, показан-
показанного в одной встрече, наилучшей трехматчевой серии и пока-
показанной в сезоне результативности; эти значения возвращают-
возвращаются с помощью соответствующих переменных "hi_game",
"h1_ser1es" и "bavg";
в) наибольшее число очков, набранных в одной встрече, сре-
среди всех игроков хранится в переменной "best_game"; поэтому
если hi_game > best_game, то hi_game сохраняется в
best_garoe и имя-и-фамилия соответствующего игрока сохраня-
сохраняются в HI6HGAME после удалений предыдущих имен-и-фамилий;
если h1_game = best_game, то просто выполняется сохранение
в HIGHGAME имени-и-фамилии игрока;
Результат наилучшей трехматчевой серии среди всех игроков
хранится в переменной "bestseries"; поэтому, если
h1_series > bestseries, то hi series сохраняется в
best_ser1es, и имя-и-фамилия соответствующего игрока со-
сохраняются в HIGHSER после удаления предыдущих имен-и-фами-
имен-и-фамилий. Если hi_series = best_series, то просто выполняется
сохранение в HIGHSER имени-и-фамилии игрока.
Наивысшая результативность среди всех игроков хранится в
переменной "best_avg"; поэтому если bavg > best_avg то
bavg сохраняется в bestavg, и имя-и-фамилия соответствую-
соответствующего игрока сохраняются в HIGHAVG после удаления предыду-
предыдущих имен-и-фамилий; если bavg = bestavg, то просто выпол-
выполняется сохранение в HIGHAVG имени-и-фамилии игрока.
4. Вывод полученных результатов.
Рис. 9.19. Логика программного модуля eosrpt.prg
162 dBASE Ill-реализация БД секретаря кегельной лиги
. type eosrpt.prg
**********************************************************
*Имя процедуры: "eosrpt.prg"
*Автор Глен А.Дхексон
*Оклендский университет, Рочестер, Ml 48063
*Данная процедура выполняет необходимые при получении отчета о
^результатах сезона вычисления и осуществляет вывод этого
*отчета
^Процедура вызывается из sdbmain.prg.
*Из этой процедуры вызывается bwirst.prg.
CLEAR
*Некоторые данные будут получены из "bwlrst,prgM с помощью
*PUBLIC-переменных
PUBLIC name, hi_series, hi_game, bavg, eos_check, fname, wk
*
9 5,10 SAY 'ПОДОЖДИТЕ — ЭТО ЗАЙМЕТ НЕКОТОРОЕ ВРЕМЯ !!!!!'
*
SELECT 2
USE b:sched
*
*Поиск последней недели сезона -- значение возвращается в
*max_wk
*
DO b:findwk
*
SELECT 3
USE b:bowler
GOTO TOP
STORE 0 TO best_series, best_gamer best_avg
SET SAFETY OFF
DO WHILE .NOT. EOF()
STORE bname TO name
STORE STR(max_wk,2) TO wk
STORE 'EOS' TO eos_check
DO b:bwlrst
SELECT 4
*
IF hi_game > best_game
STORE hi_game TO best_game
USE b:highgam
ZAP
APPEND BLANK
REPLACE bname WITH name
USE
ELSE
IF hi_game = best_game
USE brhighgam
Рис. 9.20. Модуль eosrpt.prg
Глава 9 163
APPEND BLANK
REPLACE bname WITH name
USE
ENDIF
ENDIF
•
IF hi_series > best^series
STORE hi_series TO best_series
USE b:highser
ZAP
APPEND BLANK
REPLACE bname WITH name
USE
ELSE
IF hi_series = best_series
USE b:h1ghser
APPEND BLANK
REPLACE bname WITH name
USE
ENDIF
ENDIF
*
IF bavg > best_avg
STORE bavg TO best_avg
USE b:h1ghavg
ZAP
APPEND BLANK
REPLACE bname WITH name
USE
ELSE
IF bavg = best_avg
USE b:h1ghavg
APPEND BLANK
REPLACE bname WITH name
USE
ENDIF
ENDIF
SELECT bowler
SKIP
ENDDO
*Вывод заголовка отчета о результатах сезона
9 5,25 SAY 'ОТЧЕТ О РЕЗУЛЬТАТАХ СЕЗОНА'
9 6,25 SAY '=========================='
9 8,20 SAY 'ЛУЧШИЙ РЕЗУЛЬТАТ ЗА ИГРУ ' + STR(best_game,3)
9 9,20 SAY 'ОЧКА - ПОКАЗАН ИГРОКАМИ: '
STORE "brhighgam" TO fname
Рис. 9.20. (Продолжение)
164 dBASE Ill-реализация БД секретаря кегельной лиги
DO brfileout
*
в R0W()+2,20 SAY 'ЛУЧШИЕ СЕРИИ ИЗ ТРЕХ МАТЧЕЙ - ' +;
STR(best_series,3)
в R0W()+l,20 SAY 'ОЧКОВ - ПРОВЕЛИ ИГРОКИ: '
STORE "b:highser" TO fname
DO b:fileout
*
@ R0W()+2r20 SAY 'ЛУЧШАЯ РЕЗУЛЬТАТИВНОСТЬ - r+STR(best_avg,3)
@ ROWO+1,20 SAY 'ОЧКОВ - ПОКАЗАНА ИГРОКАМИ: '
STORE "b:highavg" TO fname
DO b:fileout
в 24f20 SAY ' '
WAIT
SET SAFETY ON
RETURN
B>
Рис. 9.20. (Окончание)
Несколько необычной особенностью eosrpt.prg явля-
является способ сохранения имен-и-фамилий игроков, на-
набравших наибольшее равное число очков по данной
категории. Фамилии таких игроков сохраняются в
унарном отношении, связанном с этой категорией.
Названия этих специально создаваемых отношений
следующие: HIGHGAM, HIGHSER и HIGHAVG.
Унарными эти отношения являются потому, что в
каждое отношение входит только один атрибут -
bname. Если во время проверки числа очков, набран-
набранных игроком, оказывается, что это число равно по
некоторой категории наибольшему на данный момент,
то имя-и-фамилия игрока добавляются (оператором
APPEND) к соответствующему отношению. Если об-
обнаруживается, что число набранных игроком очков
превышает значение, считающееся на данный момент
наибольшим, то выполняется команда ZAP с целью
удаления старых значений из отношения, после чего
к отношению добавляются (оператором APPEND) но-
новые имя-и-фамилия. Все три указанные выше отно-
отношения необходимо создать до начала исполнения про-
программы, но в момент начала исполнения модуля
eosrpt.prg каждое из этих отношений должно быть
Глава 9 165
пустым. Все кортежи во всех трех отношениях унич-
уничтожаются (команда ERASE) перед завершением
eosrpt.prg. Непосредственно перед уничтожением осу-
осуществляется вывод содержимого каждого из трех от-
отношений с помощью короткого программного модуля,
названного fileout.prg. Листинг этого модуля и точная
структура каждого специального отношения приводят-
приводятся в конце главы.
9.8. Программный модуль TEAMSTD.PRG
Этот модуль вызывается из sdbmain.prg в том случае,
когда выбирается возможность - ВЫВОД ПОЛО-
ПОЛОЖЕНИЯ КОМАНД". Результатом исполнения модуля
является вывод таблицы побед-поражений всех команд
на данную неделю сезона. В начале исполнения мо-
модуль запрашивает номер недели, для которой требует-
требуется выяснить положение команд. После проверки кор-
корректности введенного номера недели программа прово-
проводит необходимые для получения числа побед-пораже-
побед-поражений для каждой команды вычисления и осуществляет
вывод положения команд в табличной форме. Также
выводится общее число очков, набранных каждой ко-
командой.
МЕНЮ ЗАПРОСОВ ПО СОСТОЯНИЮ В НОЧЬ НА ПОНЕДЕЛЬНИК
ПОЛОЖЕНИЕ КОМАНД НА КОНЕЦ НЕДЕЛИ 2
КОМАНДА
AlleyCats
Inconsistents
TenPins
HiRollers
Splitters
SandBaqqers
ПОБЕД
5.0
2.0
1.0
7.0
6.5
2.5
ПОРАЖЕНИЙ
3.0
6.0
7.0
1.0
1.5
5.5
ОБЩЕЕ ЧИСЛО ОЧКОВ
3106
3038
3019
3358
3225
3181
Рис. 9.21. Положение команд на конец недели 2
(данные получены в результате выполнения модуля
teamstd.prg)
166 dBASE Ill-реализация БД секретаря кегельной лиги
1. Выполнение модуля findwk.prg с целью нахождения послед-
последней недели, для которой вводились данные о набранных очках
в отношение SCORES. Это значение возвращается через пере-
переменную "max_wk".
2. Ввод номера недели, для которой требуется получить поло-
положение команд, с помощью переменной n_wkN и проверка пра-
правильности введенного номера. Повторение данной процедуры до
тех пор, пока не будет получено правильное значение.
3. Для каждой площадки (In) ВЫПОЛНЕНИЕ следующих действий
для каждой недели (wk):
а) соединение оператором JOIN отношений SCHED и BOWLER с
учетом выполнения условий sched->week = wk, sched->lane =
In и sched->tnumb = bowler->tnumb с целью формирования но-
нового отношения NAMES, содержащего только атрибуты bname,
tnumb и stavg (отношение NAMES будет содержать имена-и-фа-
милии всех игроков команды, которая выступала на данной
площадке и на данной неделе сезона);
б) для каждого игрока, имя-и-фамилия которого появляются в
отношении NAMES, выполнение следующих действий:
нахождение кортежа в SCORES для этого игрока и этой неде-
недели;
определение гандикапа этого игрока на этой неделе;
сложение набранных этим игроком очков с общим числом оч-
очков, набранных командой в каждой встрече (с учетом ганди-
гандикапа); при этом используются обозначения: G1A - общее чис-
число очков за игру1 (gamel) для команды, выступавшей на пло-
площадке с нечетным номером, a G1B - общее число очков за иг-
игру 1 (gamel) для команды соперников, выступавшей на площад-
площадке с четным номером; смысл обозначений G2A, G3A, G2B и G3B
ясен по аналогии;
замещение оператором REPLACE значения общего числа очков
(totpins) в отношении T_STATS старым значением, увеличен-
увеличенным на число очков, набранных в этих трех встречах данным
игроком (гандикап не включается);
корректировка записей побед-поражений, касающихся двух по-
последних подвергнувшихся рассмотрению команд; здесь исполь-
используется соглашение о том, что идентификатор команды, высту-
выступавшей на площадке с нечетным номером, оканчивается симво-
символом "А" или "а", команды, выступавшей на площадке с четным
номером, оканчивается символом "В" или "Ь".
4. Соединение оператором JOIN отношений TSTATS и TEAM с
учетом условий t_stats->tnumb = team->tnumb с целью форми-
формирования нового отношения STATS, содержащего только атрибуты
wins, losses, tname и totpins.
5. Вывод положения команд (турнирной таблицы) из отношения
STATS.
6. Удаление оператором ERASE отношения STATS и обнуление
соответствующих атрибутов в T_STATS.
Рис. 9.22. Логика программного модуля teamstd.prg
Глава 9 167
B>type tearnstd.prg
**************************************************************
*
*Имя процедуры: "teamstd.prg11
"Процедура составлена Барбарой А. МакНил
"Модифицирована Гленом А. Джексоном
"Оклендский университет, Рочестер, Ml 48063
*
"Процедура проводит необходимые вычисления для определения
"положения команд и осуществляет вывод полученных
"для каждой недели результатов. Номер недели вводится с
"терминального устройства.
*
*
"Процедура вызывается из sdbmain.prg
*
"Процедура использует несколько временных отношений для
"хранения промежуточных данных, требуемых при вычислениях. Эти
"отношения обсуждаются далее.
*
"Данная процедура вызывает b:hndkpavg.prg
*
CLEAR
SELECT 1
USE b:scores
SELECT 2
USE b:bowler
SELECT 3
USE b:t_stats INDEX b:numb
SELECT 4
USE tr.sched
SELECT 5
USE tr.team
*
"Нахождение последней недели, по которой были введены
"результаты - переменная maxwk
SELECT scores
DO b:findwk
*
"Ввод номера недели, для которой требуется определить
"положение
*команд - переменная inwk
STORE ' ' ТО 1n_wk
DO WHILE .t.
8 7 15 SAY 'ЕСЛИ ВАМ ТРЕБУЕТСЯ ПОЛУЧИТЬ ИНФОРМАЦИЮ +;
' О ТЕКУЩЕМ'
в 8,15 SAY 'ПОЛОЖЕНИИ КОМАНД, ВВЕДИТЕ '+STR(max_wk,2)+','
Рис. 9.23. Модуль teamstd,prg
168 dBASE III-реализация БД секретаря кегельной лиги
@ 9,15 SAY 'НОМЕР ПОСЛЕДНЕЙ НЕДЕЛИ, ПО КОТОРОЙ'+;
' ВНОСИЛИСЬ ДАННЫЕ'
@ 10,15 SAY 'В ПРОТИВНОМ СЛУЧАЕ ВВЕДИТЕ НОМЕР'+;
' ТРЕБУЕМОЙ НЕДЕЛИ.'
12,5 GET 1n_wk
READ
IF VALAn_wk) > max_wk .OR. VALAn_wk) < 1
0 15,10 SAY 'НЕКОРРЕКТНЫЙ НОМЕР НЕДЕЛИ!!!!'
DO b:de1ay
STORE ' ' TO in_wk
CLEAR
ELSE
CLEAR
EXIT
ENDIF
ENDDO
*
^Вычисление положения команд для недель, начиная с первой и
*кончая той, номер которой содержится в in_wk.
STORE О ТО G1A,G2A,G3A,G1B,G2B,G3B
STORE I TO ln,wk
DO WHILE wk <= VALAn_wk)
SELECT sched
JOIN WITH bowler TO b:names FOR week=wk. AND. lane = In .AND.
tnumb=bowler->tnumb FIELDS bowler->bname, tnumb, stavg
*
SELECT 6
USE b:names
SELECT t_stats
SEEK names->tnumb
SELECT names
DO WHILE .NOT. EOF()
SELECT scores
LOCATE FOR bname=names->bname .AND. week=wk
IF wk=l
IF names->stavg < 200
STORE INT(B00-names->stavg)*0.75) TO hndkp
ELSE
STORE 0 TO hndkp
ENDIF
ELSE
STORE bname TO hajiame
STORE wk-1 TO ha_week
DO b:hndkp_avg
Рис. 9.23. (Продолжение)
Глава 9 169
ENDIF
IF ln=l .OR. ln=3 .OR. ln=5
STORE gamel+hndkp+GIA TO GIA
STORE game2+hndkp+G2A TO G2A
STORE game3+hndkp+G3A TO G3A
ELSE
STORE gamel+hndkp+GlB TO GIB
STORE game2+hndkp+G2B TO G2B
STORE game3+hndkp+G3B TO G3B
ENDIF
SELECT t_stats
REPLACE totpins WITH ;
totp1ns+scores->gamel+scores->game2+scores->game3
SELECT names
SKIP
ENDDO
*
IF ln-2 .OR. ln=4 .OR. ln=6
GOTO TOP
STORE tnumb TO teamb
SELECT t_stats
STORE 1 TO count
DO WHILE count < 4
STORE "G" + STR(count.l) + "A" TO gamea
STORE "G" + STR(countrl) + "BM TO gameb
IF &gamea < &gameb
REPLACE wins WITH wins+1 FOR tnumb=teamb
REPLACE losses WITH losses+1 FOR tnumb=teama
ELSE
IF &gamea > &gameb
REPLACE wins WITH wins+1 FOR tnumb=teama
REPLACE losses WITH losses+1 FOR tnumb=teamb
ELSE
REPLACE wins WITH wins+0.5, losses WITH ;
losses + 0.5 FOR tnumb=teama .OR. tnumb=teamb
ENDIF
ENDIF
STORE count + 1 TO count
ENDDO
IF GIA + G2A + G3A < GIB + G2B + G3B
REPLACE wins WITH wins + 1 FOR tnumb=teamb
REPLACE losses WITH losses + 1 FOR tnumb=teama
ELSE
IF GIA + G2A + G3A > GIB + G2B + G3B
REPLACE wins WITH wins + 1 FOR tnumb=teama
REPLACE losses WITH losses + 1 FOR tnumb=teamb
ELSE
REPLACE wins WITH wins+0.5, losses WITH ;
losses + 0.5 FOR tnumb=teama .OR. tnumb=teamb
Рис. 9.23. (Продолжение)
170 dBASE Ill-реализация БД секретаря кегельной лиги
ENDIF
ENDIF
STORE О ТО GlA,G2ArG3A,GlB,G2BrG3B
ELSE
GOTO TOP
STORE tnumb TO teama
ENDIF
IF In = 6
STORE 1 TO In
STORE wk + 1 TO wk
ELSE
STORE In + 1 TO In
ENDIF
SELECT names
USE
ERASE b:names.dbf
ENDDO
SELECT t_stats
JOIN WITH team TO b:stats FOR tnumb=team->tnumb ;
FIELDS wins,losses,tname,totpins
SELECT 7
USE b:stats
в 5,10 SAY 'МЕНЮ ЗАПРОСОВ ПО СОСТОЯНИЮ В НОЧЬ НА ПОНЕДЕЛЬНИК'
0 6,10 SAY 'ПОЛОЖЕНИЕ КОМАНД НА КОНЕЦ НЕДЕЛИ ' + 1n_wk
в 9,'10 SAY 'КОМАНДА ПОБЕД ПОРАЖЕНИЙ ОБЩЕЕ ЧИСЛО ОЧКОВ'
в 10,10 SAY ' '
*
DO WHILE .NOT. EOF()
в R0W()+l,10 SAY tname +' '+STR(wins,4,l)+ ' '+ ;
STR(losses,4,l)+' 4 STR(totpins,5)
SKIP
ENDDO
SELECT stats
USE
ERASE b:stats.dbf
SELECT t_stats
REPLACE ALL wins WITH 0, losses WITH 0, totpins WITH 0
в 22,10 SAY ' '
WAIT
RETURN
B>
Рис. 9.23. (Окончание)
На рис. 9.21 показано положение команд на конец
второй недели, полученное на основании данных,
хранимых в предложенном примере БД. На рис. 9.22
Глава 9 171
описана общая логика модуля, а его текст - на
рис. 9.23. Это самый (и значительно более других)
сложный модуль в реализации, и его исполнение тре-
требует значительного времени. Приблизительное время,
необходимое для определения положения команд на
конец первой недели, составляет 4 мин, а на конец
четвертой недели оно составляет 12 мин. Причина
нежелательного возрастания временных затрат при
переходе от первой недели к четвертой заключается в
том, что промежуточные данные не сохраняются и
при вычислении положения команд на конец четвер-
четвертой недели требуется перерасчет положений для пер-
первой, второй и третьей недель. Этот факт является
прямым следствием проектного решения, принятого в
гл. 5, о несохранении в БД тех данных, которые мо-
могут быть получены с помощью вычислений из других
атрибутов в БД. В свете больших временных затрат
это решение безусловно должно быть пересмотрено.
(Около часа требует расчет положения команд на ко-
конец 15-й недели сезона.) Некоторые предложения, на-
направленные на сокращение времени исполнения, со-
содержатся в задачах, предложенных в конце настоя-
настоящей главы.
Модуль teamstd.prg использует другое постоянное
экстраотношение Т—STATS, не являющееся частью
исходного проекта БД. В это отношение включены 4
атрибута: tnumb, wns, losses и totpins. При создании
этого отношения значения tnumb задаются в диапазо-
диапазоне от 1 до 6 по числу команд в лиге, а все другие
атрибуты устанавливаются в 0. Значения всех атри-
атрибутов, за исключением атрибутов tnumb, вновь обну-
обнуляются перед завершением выполнения модуля
teamstd.prg. Отношение Т—STATS состоит всегда толь-
только из 6 кортежей, по одному на каждую команду
лиги, причем первичным ключом является tnumb. По
мере постепенного исполнения модуля teamstd.prg, во
время которого вычисления осуществляются по каж-
каждой неделе и каждой команде, соответствующим обра-
образом заполняется отношение T-STATS.
9.9. Структура временных отношений
Программными модулями eosrpt.prg и teamstd.prg ис-
используются несколько отношений, не являющихся ча-
172 dBASE Ill-реализация БД секретаря кегельной лиги
стыо проектируемой БД. Это временные отношения,
так как их содержимое является значащим только на
время исполнения данного программного модуля. Со-
Содержимое этих отношений постоянно создается и раз-
разрушается, и это содержимое перестает быть коррект-
корректным, как только модуль, их использующий, заверша-
завершает свою работу.
. use highgam
. list structure
Стуктура для БД : В:highgam.dbf
Число записей : О
Дата последнего обновления: 11/03/86
Поле Имя поля Тип Длина Дес
1 BNAME Character 15
** Всего ** 16
. use highser
. list structure
Стуктура для БД : В:highser.dbf
Число записей : 0
Дата последнего обновления: 11/03/86
Поле Имя поля Тип Длина Дес
1 BNAME Character 15
** Всего ** 16
. use highser
. list structure
Стуктура для БД : B:highavg.dbf
Число записей : 0
Дата последнего обновления: 11/03/86
Поле Имя поля Тип Длина Дес
1 BNAME Character 15
** Всего ** 16
в
Рис. 9.24 Структура первоначально незаполненных
трех временных отношений.
На рис. 9.24 показана структура трех временных
отношений, незаполненных всегда, за исключением
времени использования модуля eosrpt.prg. На рис. 9.25
приведена структура отношения T—STATS и его со-
Глава 9 173
держимое на начало и конец выполнения модуля
teampns.prg. Листинг fileout.prg программного модуля,
осуществляющего вывод содержимого отношений
HIGHGAM, HIGHSER и HIGHAVG, приведен на
рис. 9.26.
. use
. I1s1
t_stats
: structure
Стуктура для БД
Число
Дата г
Поле
1
см
3
4
записей
юследнего
Имя поля
TNUMB
WINS
LOSSES
TOTPINS
** Всего **
: B:t_
:
stats.dbf
6
обновления: 11/03/86
Тип
Numeric
Numeric
Numeric
Numeric
а
. list off
TNUMB WINS LOSSES
1
2
3
4
5
6
0.0 0,
0.0 0,
0.0 0.
0.0 0.
0.0 0.
0.0 0,
.0
.0
.0
.0
.0
.0
Длина
1
4
4
5
15
Aec
1
1
TOTPINS
0
0
0
0
0
0
Рис. 9.25. Структура (а) и начальное содержимое (б)
временного отношения Т—STATS.
9.10. Необходимость входного меню
Меню, предложенное на рис. 9.5, предназначено для
извлечения данных из БД. Оно не окажет никакой
помощи секретарю в добавлении новых кортежей в
БД. Типичная проблема, с которой придется столк-
столкнуться секретарю, заключается в добавлении в БД
результатов всех игроков за пятую неделю. Как было
указано ранее в этой главе, текущие данные в БД
были внесены с помощью стандартных команд dBASE
III APPEND и EDIT. Этим командам присущи внут-
внутренние проблемы с точки зрения целостности БД; в
174 dBASE III-реализация БД секретаря кегельной лиги
частности, этими командами не контролируется суще-
существование дублированных первичных ключей. В ис-
исходном проекте БД предусматривалось отсутствие
дублированных первичных ключей. Выполнение этого
условия требует разработки пользовательского про-
программного обеспечения, предназначенного для обнару-
обнаружения среди заносимых в БД кортежей тех, которые
могут послужить причиной дублирования первичных
ключей. Программное обеспечение призвано не допу-
допустить занесения в БД таких кортежей.
••••••••••••••••••••••••••••*••••••••••••••*•••*••••••••
*Имя процедуры: "fileout.prg"
*Автор Глен А.Джексон
*Оклендский университет, Рочестер, Ml 48063
*Данная процедура выводит имена-и-фамилии из нескольких
^временных отношений, создаваемых модулем eosrpt.prg.
*
^Процедура вызывается из eosrpt.prg
•
^Название отношения, содержимое которого требуется вывести,
^содержится в переменной fname. Это отношение содержит только
*один атрибут: bname.
USE &fname
GOTO TOP
DO WHILE .NOT. EOF()
0ROW()+1,3O SAY bname
SKIP
ENDDO
ZAP
RETURN
Рис. 9.26. Программный модуль fileout.prg, вызывае-
вызываемый из модуля eosrpt.prg.
Рис. 9.27 иллюстрирует один метод предотвраще-
предотвращения занесения в отношения дублированных первичных
ключей. В качестве примера используется отношение
BOWLER. Атрибутами этого отношения являются
bname, week, gamel, game2 и game3, первичный
ключ состоит из пары атрибутов <bname,week>. Вме-
Вместо использования команды APPEND прямого занесе-
занесения нового кортежа в отношение BOWLER секретарю
будет предложено воспользоваться программным моду-
модулем, логика которого дана на рис. 9.27. Данный мо-
Глава 9 \ys
дуль запросит кортежные значения, ввод которых же-
желает осуществить секретарь, и затем ПОДСЧИТАЕТ
(COUNT) число кортежей в отношении, имеющих тот
же, что и вводимый кортеж, первичный ключ. Если
значение COUNT остается равным 0, то кортеж ав-
автоматически будет включен в БД. В противном слу-
случае кортеж в БД включаться не будет. Такой логиче-
логический подход должен быть применен для всех отноше-
отношений в БД. Набор программ, направленный на дости-
достижение этой цели, дан в конце главы в качестве за-
задачи.
1. USE bowler
2. Ввод значений атрибутов bnamerweekr gamel, game2 и датеЗ
с помощью переменных name, wkr glr g2 и дЗ соответственно.
3. ПОДСЧЕТ (COUNT) числа кортежей, для которых справедливо
bname = name и week = wk.
4. IF COUNT = 0r то APPEND (добавление) нового кортежа в
отношение
ELSE
вывод сообщения об ошибке и запрос на получение нового
кортежа.
Рис. 9.27. Алгоритм предотвращения хранения дубли-
дублированных первичных ключей в отношении BOWLER
9.11. Задачи к гл. 9
1. Составить правильно следующие запросы, исполь-
используя реализацию средствами dBASE III БД секретаря,
кратко описанную на рис. 9.1-9.4. (Используйте по-
последовательность команд dBASE III либо небольшой
по размеру программный модуль, содержащий коман-
команды dBASE III. Следует отметить, что некоторые зада-
задачи являются трудными.)
а) Получить список имен-и-фамилий и адресов
всех членов команды HiRollers;
б) определить общее число очков (без учета гандикапа)
для команды с номером 4 на конец недели 2 сезона;
в) определить общее число очков (без учета ганди-
гандикапа) для команды SandBaggers на конец недели 3;
176 dBASE Ill-реализация БД секретаря кегельной лиги
г) определить сколько игроков команды Splitters
проживает на улице Robin St;
% д) получить имена-и-фамилии капитанов всех ко-
команд, которые хотя бы в одной игре набрали более
160 очков;
е) получить имена-и-фамилии всех игроков, чьи
фамилии начинаются с буквы "М";
ж) получить имена-и-фамилии всех игроков, пока-
показавших в более чем одной серии из трех встреч
результат, превышающий 450 очков (избегайте дуб-
дублирования выводимой информации).
2. Реализация запросов в dBASE III, рассмотренная в
этой главе, осуществляет вывод всех данных на тер-
терминальное устройство. Модифицируйте sdbmain.prg
так, чтобы секретарю задавался вопрос о том, нужна
ли ему также и твердая копия этих данных (вывод
на принтер).
3. Модуль получения отчета о результатах сезона
(eosrpt.prg) определяет последнюю неделю этого сезо-
сезона посредством нахождения в отношении SCHED наи-
наибольшего номера недели. Программа никогда не про-
проверяет отношение BOWLER на предмет того, были ли
действительно введены данные, касающиеся этой не-
недели, в БД. Модифицируйте модуль eosrpt.prg так,
чтобы эта проверка выполнялась перед проведением
вычислений по формированию сезонного отчета.
4. Внесите в модуль eosrpt.prg изменения, обеспечи-
обеспечивающие вывод имени-и-фамилии игрока, достигшего
наибольшего прогресса. Таковым считается игрок, у
которого разница между начальной результативностью
и конечной является наибольшей.
5. В реализации не предусмотрена возможность учета
пропусков игроком игры или игр во время тура. Из-
Измените реализацию так, чтобы пропуск игры (резуль-
(результатом которого является начисление 0 очков за иг-
игру): (а) не влиял на показатель результативности
или гандикап; (б) имел своим следствием замещение
нуля значением результативности игрока за вычетом
10 очков, что вызывается необходимостью определе-
определения числа побед-поражений команды.
6. Внесите в модуль bwlrst.prg изменения, обеспечи-
обеспечивающие вывод также ОБЩЕГО ЧИСЛА ОЧКОВ С
УЧЕТОМ ГАНДИКАПА.
Глава 9 177
******************** HNDKP AVG.PRG **************
*Имя модуля "hndkp_avg.prg"
♦Составлен Барбарой А. МакНил
♦Модифицирован Гленом А.Джексоном
*Оклендский университет, Рочестер, Ml 48063
*
*Модуль предназначен для вычисления результативности и
*гандикапа для данного игрока - по состоянию на конец данной
* недели сезона.
*Имя-и-фамилия игрока вводятся с помощью bname (атрибут).
*Номер недели передается через переменную ha_week.
^Текущая результативность игрока возвращается через
♦переменную bavg.
♦Текущий гандикап игрока возвращается через hndkp.
*Данный модуль вызывается из: teamstd.prg.
*
ctr = 1
t_pins * 0
SELECT scores
*
^Сохранение номера текущей записи файла scores.dbf.
saveit = RECNO()
*
DO WHILE ctr <= ha_week
LOCATE FOR bname=ha_name .AND. week=ctr
t_pins = gamel + game2 + game3 + t_pins
ctr - ctr + 1
ENDDO
*
bavg = INT(t_pins/(ha_week*3))
IF bavg < 200
hndkp = INT(B00-bavg)*0.75)
ELSE
hndkp - 0
ENDIF
^Восстановление исходного номера записи файла scores.dbf.
GOTO saveit
*
RETURN
Рис. 9.28. Модуль hndkp-avg.prg, вызываемый из
teamstd.prg.
7- Расчет положения команд с помощью модуля
teamstd.prg требует тем больших затрат времени, чем
больше времени прошло с начала сезона. Одна из
причин этого заключается в том, что модуль
178 dBASE Ill-реализация БД секретаря кегельной лиги
hndkp-^avg.prg при вызове его из teamstd.prg с целью
вычисления текущего гандикапа выполняет вычисле-
вычисления по определению общего числа набранных очков,
которые повторно выполняются при возврате управле-
управления в teamstd.prg. Модифицируйте алгоритм и добей-
добейтесь исключения дублируемых действий. Программный
модуль hndkp-^avg.prg приведен на рис. 9.28.
8. В задаче 1 гл. 5 предлагалось спроектировать БД,
в которой бы хранились некоторые из вычисляемых
атрибутов (таких, как общее число набранных оч-
очков). Реализуйте указанную БД и сравните времена,
затрачиваемые на вычисление положения команд в
новой БД и предлагаемом в этой главе варианте. Об-
Обсудите некоторые проблемы обновления данных во
вновь сконструированной БД, сравните их с реализа-
реализацией БД, представленной в настоящей главе.
9. Напишите несколько программных модулей, выпол-
выполнение которых инициируется с помощью меню, кото-
которые бы позволили секретарю присоединять новые,
или модифицировать текущие кортежи для любого
отношения в БД. Каждым модулем должны выявлять-
выявляться дублированные первичные ключи, а также все ос-
остальные ошибки, возникновения которых можно ожи-
ожидать. (Обратите внимание, что при модификации ат-
атрибута, являющегося первичным ключом, следует
вначале удалять "старый" кортеж с последующей
вставкой "нового" кортежа.)
10. Еще раз просмотрите все программные модули,
вызываемые из программы главного меню, на предмет
того, нельзя ли достигнуть большей скорости их вы-
выполнения путем изменения в подходах, с помощью
улучшенного программирования или усовершенствова-
усовершенствования технологических аспектов построения БД. Срав-
Сравните текущие временные затраты на выполнение и те
же затраты при пересмотренном методе с целью по-
получения количественной оценки достигнутого (в ско-
скорости ответа) улучшения. Определите, оказывает ли
использование индексированных файлов заметное вли-
влияние на время выполнения1).
*) Тестовые прогоны с использованием системы на жестком диске
для тех же програмных модулей, что приводятся в данной главе,
показали по крайней мере трехкратное увеличение скорости выпол-
выполнения.
10. R:base 5000-РЕАЛИЗАЦИЯ БД СЕКРЕТАРЯ
КЕГЕЛЬНОЙ ЛИГИ
Эта глава подразделяется на три основные информа-
информационные части: 1 - содержит примеры листингов че-
четырех отношений, формирующих БД секретаря ке-
кегельной лиги, для случая их реализации в СУБД
R.base 5000; 2 - содержит примеры того, как коман-
команды R-.base 5000 могут быть использованы при полу-
получении ответов на простые запросы; 3 - посвящена уг-
углубленному обсуждению набора управляемых с по-
помощью меню программных модулей R:base 5000, от-
отвечающих на сложные запросы с помощью команд
языка программирования данной СУБД. Реализация
БД была выполнена на IBM PC с объемом оператив-
оперативной памяти 320 Кбайт, двумя двусторонними диско-
дисководами, а также монохромным монитором. Системный
диск R:base 5000 всегда установлен на устройстве А;
программным модулям и файлам БД отводится уст-
устройство В.
10.1. Анализ отношений БД с помощью тестовых
данных при использовании R:base 5000
Прежде чем приступать к обсуждению специальных
запросов и различных программных модулей необхо-
необходимо изучить существующие отношения БД. Тестовые
данные для БД были получены при тех же, что и в
гл. 9, предположениях. Эти предположения состоят в
следующем:
1. В кегельную лигу входят 6 команд.
2. В каждой команде 4 игрока.
3. Продолжительность сезона составляет четыре не-
недели.
4. Ввод данных, охватывающих эти 4 недели, был
осуществлен с помощью стандартных команд R:base
5000 LOAD и EDIT.
5. Все игроки участвовали во всех встречах.
Возможные изменения в некоторых из этих пред-
предположений приводятся в качестве упражнений в кон-
конце главы в перечне задач.
180 R:base 5000-реализация БД секретаря кегельной лиги
R>11st sched
Table: sched
Read Password: NO
Modify Password: NO
Column definitions
# Name Type
1 tnumb INTEGER
2 week INTEGER
3 lane INTEGER
Length
1 vaiue(s)
1 vaiue(s)
1 value(s)
Current number of rows:
R>
Key
yes
24
tnumb
tnumb
1
2
3
4
5
6
1
2
3
4
5
6
1
2
3
4
5
6
1
2
3
4
5
6
a
weeK
1
1
1
1
1
1
2
2
2
2
2
2
3
3
3
3
3
3
4
4
weeK
4
4
. 4
4
lane
1
2
4
3
6
5
4
5
2
6
1
3
3
6
1
4
5
2
5
1
lane
3
2
4
6
>ис. 10.1. Структура (а) и содержимое(б) отношения
Глава 10
181
На каждом из рис. 10.1-10.4 показаны как струк-
структура, так и тестовые данные для каждого отношения.
В эти отношения занесены те же данные, которые
использовались в гл. 9, что дает при желании воз-
возможность сравнения результатов обеих реализаций.
БД в СУБД R-.base 5000 присвоено название SDB.
R>11st team
R>
Table: team
Read Password: N0
Modify Password: N0
Column definitions
# Name Type
1 tnumb INTEGER
2 tname TEXT
3 captn TEXT
Length Key
1 vaiue(s) yes
15 characters
15 characters
Current number of rows:
6
tnumb
tname
captn
1 AlleyCats
2 Ineons 1stents
3 TenPins
4 HighRollers
5 Splitters
6 SandBaggers
Энн Джонс
Билл Блак
Лиза Мур
Джил Миллер
Рой Лейн
Синди Фокс
Рис. 10.2. Структура (а) и содержимое (б) отношения
TEAM
Обзор данных в отношении BOWLER вновь (как и
в гл. 9) показывает дублирование адресных данных и
данных о телефонных номерах. Казалось бы, можно
заключить, что зависимость phone -> stret является
корректной ФЗ. Читателю настоятельно рекомендуется
ознакомиться с перечисленными в разд. 9.1 причина-
причинами, объясняющими почему это не так и почему ни
адресные данные, ни данные о телефонных номерах
не являются избыточными.
182 R'.base 5000-реализация БД секретаря кегельной лиги
R>11st bowler
Table: bowler
Read Password: NO
Modify Password: NO
Column
# Name
1 bname
2 tnumb
3 phone
4 stret
5 stavg
definitions
Type
TEXT
INTEGER
TEXT
TEXT
INTEGER
Length
15 characters
1 value(s)
8 characters
20 characters
1 value(s)
Key
yes
Текущее число строк: 24
R>
bname
tnumb phone
stret
stavg
Джин Адаме 5 689-1234 10 Robin St HI
Стив Адаме 5 689-1234 10 Robin St 130
Билл Блак 2 689-2345 15 Bluebird Ln 149
Бонни Блак 2 689-2345 15 Bluebird Ln 120
Бо Блоу 2 689-3456 12 Meadowbrook Ln 143
Джо Блоу 2 689-3456 12 Meadowbrook Ln 95
Джо Браун 3 689-4567 18 Bluebird Ln 132
Сью Браун 3 689-4567 18 Bluebird Ln 124
Синдй Фокс 6 689-5678 19 Cardinal St 103
Рэнди Фокс 6 689-5678 19 Cardinal St 147
Энн Джонс 1 689-4365 12 Finch Dr 105
Джон Джонс 1 689-4365 12 Finch Dr 143
Джой Лейн 5 689-6789 21 Sparrow Ct 125
РОЙ Лейн 5 689-6789 21 Sparrow Ct 167
Джил Миллер 4 689-7890 12 Robin St 108
Пол Миллер 4 689-7890 12 Robin St 170
Лиза Hyp 3 689-8901 11 Lark Dr 110
Майк Мур 3 689-8901 11 Lark Dr 140
Джим Смит 1 689-9012 13 Finch Dr 152
Мари Смит 1 689-9012 13 Finch Dr 115
bname tnumb phone stret stavg
Руфь Тейлор
Дам Уайт
Джейн Уайт
Рассел Тейлор
689-0123
689-2143
689-2143
689-0123
20 Cardinal St
16 Robin St
16 Robin St
20 Cardinal St
119
158
121
161
Рис. 10.3. Структура (а) и содержимое F) BOWLER
Глава 10
183
R>Hst
Table: scores
Read Password: N0
Modify Password: N0
Column definitions
# Name
1 bname
2 week
3 gamel
4 game2
5 game3
Type
TEXT
INTEGER
INTEGER
INTEGER
INTEGER
R>
Текущее число строк: 96
Length
15 characters
1 vaiue(s)
1 value(s)
1 value(s)
1 value(s)
Key
yes
bname
week
gamel
game2
датеЗ
Джин Адаме
Стив Адаме
Билл Блак
Бонни Блак
Бо Блоу
Джо Блоу
Джим Смит
Мари Смит
Энн Джонс
Джон Джонс
Джо Браун
Сью Браун
Синди Фокс
Рэнди Фокс
Рассел Тейлор
Руфь Тейлор
Джой Лейн
Рой Лейн
Джил Миллер
Пол Миллер
bname
Дан Уайт
Джейн Уайт
Лиза Мур
Майк Мур
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
W66K
1
1
1
1
119
112
137
120
160
101
160
120
98
145
140
121
119
143
167
НО
126
145
111
180
gamel
156
130
99
150
120
140
155
125
145
91
150
НО
ПО
150
127
128
110
150
150
125
127
180
101
196
game2
163
125
120
149
94
138
155
115
125
93
146
115
107
134
129
124
83
148
166
122
122
176
112
134
датеЗ
154
108
111
121
б
Рис. 10.4. Структура (а) и содержимое (б) SCORES* (При-
(Приведены результаты только для первой йедели. Резуль-
Результаты для всех четырех недель приводятся на рис. 9.4.)
184 R:base 5000-реализация БД секретаря кегельной лиги
10.2. Ответы на запросы секретаря в R:base 5000
Цель данного раздела состоит в иллюстрации того
факта, что на простые запросы к БД секретаря ке-
кегельной лиги можно получить ответы непосредственно
с помощью команд Rrbase 5000, не прибегая к ис-
использованию языка программирования БД. Все запро-
запросы данного раздела имеют своими объектами отноше-
отношения, приведенные на рис. 10.1 - 10.4. Читателю ре-
рекомендуется создать БД, загрузить отношения тесто-
тестовыми данными и проверить обсуждаемые запросы. Во
многих случаях ответ даже на сравнительно простой
запрос требует не одной команды, а последовательно-
последовательности, состоящей из двух или трех команд.
В приводимых ниже примерах полагается, что
пользователь находится на командном уровне СУБД
Rrbase 5000 и на экране отображается символ при-
приглашения R>. Также предполагается, что БД секре-
секретаря лиги открыта с помощью команды
R> OPEN brsdb
ЗАПРОС #1: "Перечислить названия всех команд лиги".
Ответить на этот запрос легко по двум причинам:
во-первых, вся информация, необходимая для ответа
на этот запрос, находится в одном отношении; во-
вторых, не требуется никаких уточнений (предложе-
(предложение WHERE). Решением служит команда
R> SELECT tname FROM team
или
R> SELECT tname +
R> FROM team
Во втором случае единичная команда для удобства
чтения размещена на двух строках с помощью симво-
символа продолжения "+". В результате исполнения любого
из двух различных вариантов команды будет получен
список, состоящий из названий шести команд.
Глава 10 185
ЗАПРОС #2: "Найти имя-и-фамилию капитана ко-
команды с номером 4й.
Получить ответ на этот запрос лишь ненамного
сложнее, чем на запрос #1. Дополнительная сложно-
сложность обусловлена необходимостью использования пред-
предложения WHERE:
R> SELECT captn +
R> FROM team +
R> WHERE tnumb = 4
Ответом СУБД будет строка captn»Джил Миллер.
ЗАПРОС #3: "Найти имена-и-фамилии всех игроков
с начальной результативностью меньшей 100".
Форма решения будет близка той, которая была
принята при получении ответа на предыдущий запрос:
R> SELECT bname +
R> FROM bowler +
R> WHERE stavg < 100
В ответ будут получены имя-и-фамилия одного игро-
игрока Джо Блоу.
ЗАПРОС #4: "Найти имена-и-фамилии и номера те-
телефонов всех игроков команды с номером 3".
Решение
R> SELECT bname,phone +
R> FROM bowler +
R> WHERE tnumb - 3
В ответ будет получено
bname phone
Джо Браун 689-4567
Сью Браун 689-4567
Лиза Мур 689-8901
Майк Мур 689-8901
186 R:base 5000-реализация БД секретаря кегельной лиги
ЗАПРОС #5: "На какой площадке проводит свой
встречи команда 5 на неделе 3 сезона?".
Для получения ответа на этот запрос необходимо
воспользоваться предложением WHERE, которое должно
сопровождаться несколькими условиями вместо одного:
R> SELECT lane +
R> FROM sched +
R> WHERE tnumb = 5 AND week = 3
Ответом системы на этот запрос будет lane = 5.
ЗАПРОС #6: "Найти имена-и-фамилии всех игроков,
проживающих по улице Robin St."
Поскольку адреса в БД запоминаются в виде строк
типа 1 Robin St", получение ответа на запрос тре-
требует осуществления процедуры поиска по содержимо-
содержимому поля stret с целью обнаружения символьной стро-
строки "Robin St". Реализовать процедуру поиска можно
с помощью включения оператора CONTAINS в пред-
предложение WHERE. Получить ответ на запрос можно
разными способами:
R> SELECT bname +
R> FROM bowler +
R> WHERE stret CONTAINS Robin St
или
R> SELECT bname +
R> FROM bowler +
R> WHERE stret CONTAINS "Robin St"
или
R>SET VAR substr TO Robin & St
R> SELECT bname +
R> FROM bowler +
R> WHERE stret CONTAINS .substr
Во всех трех случаях в качестве ответа будет полу-
получен один и тот же результат
Глава 10 187
bnamq
Джин Адаме
Стив Адаме
Джил Миллер
Пол Миллер
Дан Уайт
Джейн Уайт
Различия между тремя решениями определяются спо-
способом задания строки "Robin St". В первых двух
случаях пользователь должен проследить за тем, что-
чтобы строки "Robin" и "St" разделялись в точности од-
одним пробелом, поскольку именно таким образом хра-
хранятся данные об адресах в БД. В последнем случае
оператор "&" однозначно определяет для системы на-
наличие одного пробела между разделяемыми им стро-
строками. Одно преимущество последнего формата заклю-
заключается в том, что при просмотре решения число про-
пробелов не может вызвать сомнений.
ЗАПРОС #7: "Сколько проведено к настоящему вре-
времени трехматчевых серий, в которых набрано в сум-
сумме более 550 очков?".
Получение ответа на этот запрос несколько услож-
усложняется тем обстоятельством, что R:base 5000 допуска-
допускает использование в выражении только одной арифме-
арифметической операции. Например, выражения вида
varl + var2
можно включать в конструкции, допускаемые R:base
5000, в то время как выражения, в которых исполь-
использованы два оператора, например вида
varl + var2 + var3
никоим образом не могут быть включены в одну ко-
команду. Что касается данного запроса, то следствием
указанного ограничения является необходимость вре-
временного резервирования ячеек памяти для хранения
промежуточных результатов. Один возможный способ
такого резервирования заключается в добавлении
188
R:base 5000-реализация БД секретаря кегельной лиги
столбца к отношению, данные в котором анализиру-
анализируются. После получения ответа столбец из отношения
удаляется. Общее решение состоит из серии шагов:
R> EXPAND scores WITH total INTEGER
R> ASSIGN total TO gamel + game2 IN scores
R> ASSIGN total TO total + game3 IN scores
R> COMPUTE number AS COUNT total +
R> FROM scores +
R> WHERE total > 550
R> SHOW VAR number
R> REMOVE COLUMN total FROM scores
По команде EXPAND к отношению SCORES до-
добавляется новый столбец; ему присваивается название
total и назначается тип integer. Две команды ASSIGN
задают вычисление суммы (gamel + game2 + game3)
для каждого кортежа отношения SCORES и помеща-
помещают каждую вычисленную сумму в соответствующее
поле total. В данный момент поле total каждого кор-
кортежа содержит сумму очков трех отдельных игр этого
кортежа. В следующих трех строках предлагаемого
решения записана одна команда: конструкция
COMPUTE-FROM-WHERE. Эта команда обеспечивает
подсчет числа кортежей, для которых значение total
превышает 550 и помещает это число в переменную
number. Это значение затем выводится с помощью
команды SHOW VAR. В заключение столбец, добав-
добавленный к отношению SCORES, удаляется с помощью
команды REMOVE COLUMN. Окончательным ответом
на запрос будет number - 2.
Решение, предложенное для запроса #7, имеет
один серьезный недостаток: в процессе выполнения
запроса изменяется базовая структура отношения
SCORES в результате добавления, а затем удаления
нового столбца. Многие из тех, кто непосредственно
работает с БД, являются противниками подхода, при
котором допускаются запросы, изменяющие структуру
отношений в БД после того, как создание БД было
завершено. Они будут доказывать, что вместо созда-
создания нового столбца в одном из проектных отношений
целесообразней строить временное отношение, состоя-
состоящее из одного или более столбцов и предназначенное
для хранения промежуточных данных при проведении
Глава 10 189
вычислений. В этом случае, если произойдет нечто
незапланированное при выполнении запроса, исходная
БД будет сохранена. Этот подход заслуживает внима-
внимания и читателю рекомендуется придумать метод раз-
разрешения последнего запроса способом, при котором
исходная структура отношения SCORES не изменяет-
изменяется.
ЗАПРОС #8: "Кто является капитаном соперника ко-
команды 5 на неделе 3?".
На этот запрос лучше ответить в два этапа. На
первом этапе можно воспользоваться запросом #5, в
результате выполнения которого будет получено, что
команде 5 на неделе 3 отведена площадка lane « 5.
Это значит, что команда соперников будет этим ве-
вечером выступать на площадке lane « 6. С помощью
полученной информации можно найти и сохранить в
переменной, скажем, tern, номер команды, выступаю-
выступающей на площадке 6 на третьей неделе сезона:
R> SET VAR tern TO tnumb IN sched +
R> WHERE lane = 6 AND week = 3
Значение, занесенное в переменную tern, теперь (вто-
(второй этап) может быть использовано при определении
имени-и-фамилии капитана
R> SET VAR ans TO captn IN team+
R> WHERE tnumb = .tern
R> SHOW VAR ans
В качестве ответа будет получено ans ■ Билл Блак.
ЗАПРОС #9: "Перечислить имена-и-фамилии всех
членов лиги, не являющихся игроками команды
SandBaggers".
Решение в этом случае, как и в предыдущем, тре-
требует перенесения информации, извлеченной из одного
отношения, в другое с целью получения правильного
ответа. В этом примере будет использован оператор
реляционной алгебры JOIN:
190 R:base 5000-реализация БД секретаря кегельной лиги
R> PROJECT tempr FROM team USING tnumb +
R> WHERE tname <> SandBaggers
R> RENAME COLUMN tnumb TO ttnumb IN tempr
R> JOIN tempr USING ttnumb +
R> WITH bowler USING tnemb +
R> FORMING result
R> SELECT bname +
R> FROM result
R> REMOVE result
R> REMOVE tempr
В результате будет получен список, состоящий из
20 имен-и-фамилий.
Предложенное решение выполняется следующим
образом: A) Новое отношение, названное TEMPR,
проецируется из отношения TEAM. Отношение
TEMPR имеет только один столбец tnumb. В нем со-
содержатся номера всех команд за исключением
SandBaggers. B) Единственный столбец в TEMPR пе-
переименовывается в ttnumb, с тем чтобы отличить его
от столбца с номерами команд в отношении
BOWLER. Во время выполнения следующей команды
JOIN R:base 5000 ожидает, что соединяемые (коман-
(командой JOIN) столбцы имеют разные названия. C) От-
Отношения TEMPR и BOWLER соединяются (командой
JOIN) и формируют третье отношение RESULT. В
столбце bname отношения RESULT содержатся иско-
искомые имена-и-фамилии членов лиги. D) С помощью
команды SELECT осуществляется отображение ответа
на запрос. E) Два временных отношения RESULT и
TEMPR удаляются из БД.
ЗАПРОС #10: "Каково общее число очков (без уче-
учета гандикапа), набранных Биллом Блаком на конец
третьей недели сезона?".
Возможно следующее решение:
R> COMPUTE tot AS SUM gamel FROM scores +
R> WHERE week <- 3 AND bname - "Билл Блак"
R> COMPUTE s2 AS SUM game2 FROM scores +
R> WHERE week <= 3 AND bname = "Билл Блак"
R> COMPUTE s3 AS SUM game3 FROM scores +
R> WHERE week <» 3 AND bname - "Билл Блак"
Глава 10 191
R> SET VAR tot TO .tot + .s2
R> SET VAR tot TO .tot + .s3
R> SHOW VAR tot
В результате будет получено tot - 1381.
В данном решении по первой команде COMPUTE
суммируются показанные Биллом Блаком результаты
во всех встречах gamel, состоявшихся в первые три
недели сезона, а полученная сумма заносится в пере-
переменную tot. Следующие две команды COMPUTE по-
повторяют эту процедуру суммирования, но уже для
встреч game2 и game3, сохраняя соответствующие
суммы в переменных s2 и s3. Команды SET VAR
выполняют сложение значений указанных трех пере-
переменных с целью получения окончательного результа-
результата. Команда SHOW VAR осуществляет вывод резуль-
результата.
ЗАПРОС #11: "Сколько членов лиги набрали хотя
бы в одной игре более 150 очков?"
Возможно следующее решение
R> PROJECT tempr FROM scores USING bname +
R>WHERE gamel>150 OR game2>150 OR +
R> game3> 150
R> DELETE DUPLICATES FROM tempr
R> COMPUTE ans AS ROWS FROM tempr
R> SHOW VAR ans
R> REMOVE tempr
Будет получен ответ ans - 11.
В этом решении временное отношение TEMPR
проецируется (с помощью команды PROJECT) из от-
отношения SCORES. В отношении TEMPR имеется
только один столбец bname. В этом отношении содер-
содержится по одному кортежу для каждого кортежа отно-
отношения SCORES, в котором результат хотя бы одной
встречи превышает 150. Так как один и тот же иг-
игрок мог набрать более 150 очков в разные дни, воз-
возможно, что одни и те же имя-и-фамилия появятся в
отношении TEMPR несколько раз. По команде
DELETE DUPLICATES все дублированные именами-
фамилии (кортежи) будут удалены из отношения
192 R:base 5000-реализация БД секретаря кегельной лиги
TEMPR. Число оставшихся имен-и-фамилий подсчи-
подсчитываете* с помощью команды COMPUTE с целью по-
получения искомого ответа.
Допустимость дублированных кортежей в отноше-
отношении TEMP означает, что оператор PROJECT в СУБД
R:base 5000 не является корректным оператором ре-
реляционной алгебры, a TEMPR не является изначаль-
изначально правильным отношением. Как уже отмечалось в
предыдущих главах, никакая реляционная СУБД для
микрокомпьютеров не является полностью реляцион-
реляционной, и пользователь должен принять этот факт во
внимание при подготовке запросов. R:base 5000 в
большей степени, чем другие СУБД для микрокомпь-
микрокомпьютеров, соответствует понятию полностью реляцион-
реляционной СУБД.
Относительно приведенных выше решений следует
сказать, что они не являются единственно возможны-
возможными. Обычно запрос может быть удовлетворен различ-
различными способами. Одни решения могут отличаться вы-
высокой скоростью исполнения, логика других может
быть много проще для понимания. Лучший способ
научиться составлять хорошие решения состоит в изу-
изучении решений, написанных другими, с последующим
написанием многих собственных решений, используя
несколько различных подходов к каждой проблеме.
10.3. Основное меню заранее подготовленных запросов
Запросы из разд. 10.2 относятся к типичным запро-
запросам секретаря лиги. Их решения в большинстве слу-
случаев достаточно прямолинейны и невелики по разме-
размеру, под которым понимается число предложений
R:base 5000, необходимых для получения ответа.
Предполагалось, что секретарь будет вводить эти ре-
решения вручную, хотя длина некоторых решений лег-
легко может привести к возникновению ошибки при их
написании. Кроме того, секретарь лиги должен обла-
обладать определенными знаниями как в области теории
БД, так и в синтаксисе R:base 5000, достаточными
для составления решений, а не простого копирования
их из предложенного перечня. Для того чтобы снять
с секретаря обязанность регенерации решений всякий
раз при встрече с одним и тем же запросом, можно
прибегнуть к сохранению меню часто используемых
Глава 10 193
запросов, с исполнением заранее запрограммированно-
запрограммированного решения каждого запроса из меню при его выборе.
В следующих разделах этой главы подробно описыва-
описывается такое специальное меню и связанные с ним про-
программы.
г МЕНЮ ЗАПРОСОВ ПО СОСТОЯНИЮ В НОЧЬ НА ПОНЕДЕЛЬНИК п
A) СТАТИСТИЧЕСКИЕ ДАННЫЕ ПО ОТДЕЛЬНОМУ ИГРОКУ
B) ОБЩЕЕ ЧИСЛО ОЧКОВ КАХДОЙ КОМАНДЫ
C) ВЫВОД ПОЛОЖЕНИЯ КОМАНД
D) ВЫВОД РАСПИСАНИЯ ВСТРЕЧ ДЛЯ ДАННОЙ НЕДЕЛИ
E) ГЕНЕРАЦИЯ ОТЧЕТА О РЕЗУЛЬТАТАХ СЕЗОНА
F) ВОЗВРАТ В RBASE 5000
Рис. 10.5. Главное меню, порождаемое модулем secdb.apx.
Меню в том виде, каким его видит секретарь, пока-
показано на рис. 10.5. Программный модуль, порождаю-
порождающий это меню, воспринимает сделанный выбор, после
чего управление передается другим программным мо-
модулям (так, как это показано на рис. 10.6). Этот мо-
модуль назван secdb.app. Модуль secdb.app был разрабо-
разработан с помощью пакета-утилиты APPLICATION
EXPRESS, представляющего собой часть пакета про-
программного обеспечения R:base 5000. С целью увели-
увеличения скорости исполнения была проведена компиля-
компиляция модуля secdb.app и получен исполняемый модуль
secdb.apx. На командном уровне R:base 5000 про-
программа, отвечающая за меню, выполняется при вводе
последовательности команд
R> В:
R> RUN secdb IN secdb.apx
В случае выбора любой из пяти возможностей,
предложенных в меню, выполняется программный мо-
модуль, написанный на языке программирования R:base
5000. Некоторые из этих модулей, в свою очередь,
могут вызывать другие подмодули. Все программные
модули, вызываемые в ответ на сделанный выбор,
подробно обсуждаются в следующих разделах этой
главы. Реализации программ, использованные для по-
получения результатов, приведенных в этой главе,
представляют собой откомпилированные версии исход-
исходных программ, листинги которых будут представлены.
194 R:base 5000-реализация БД секретаря кегельной лиги
SCOHMAND
SECDB
SET MESSAGE OFF
OPEN SDB
SET ERROR MESSAGE OFF
SET VAR PICK1 INT
LABEL STARTAPP
NEWPAGE
CHOOSE PICK1 FROM sdbmain IN SECDB.APX
IF PICK1 EQ 1 THEN
RUN bwirst.com
GO TO STARTAPP
ENDIF
IF PICK1 EQ 2 THEN
RUN teampns IN SECDB.APX
GO TO STARTAPP
ENDIF
IF PICK1 EQ 3 THEN
RUN teamstd.com
GO TO STARTAPP
ENDIF
IF PICK1 EQ 4 THEN
RUN wkschdi IN SECDB.APX
GO TO STARTAPP
ENDIF
IF PICK1 EQ 5 THEN
RUN eosrpt.com
GO TO STARTAPP
ENDIF
IF PICK1 EQ 6 THEN
GOTO ENDAPP
ENDIF
GOTO STARTAPP
LABEL ENDAPP
CLEAR PICK1
RETURN
$MENU
sdbmain
МЕНЮ ЗАПРОСОВ ПО СОСТОЯНИЮ В НОЧЬ НА ПОНЕДЕЛЬНИК
СТАТИСТИЧЕСКИЕ ДАННЫЕ ПО ОТДЕЛЬНОМУ ИГРОКУ
ОБЩЕЕ ЧИСЛО ОЧКОВ КАЖДОЙ КОМАНДЫ
ВЫВОД ПОЛОЖЕНИЯ КОМАНД
ВЫВОД РАСПИСАНИЯ ВСТРЕЧ ДЛЯ ДАННОЙ НЕДЕЛИ
ГЕНЕРАЦИЯ ОТЧЕТА О РЕЗУЛЬТАТАХ СЕЗОНА
ВОЗВРАТ В RBASE 5000
Рис. 10.6. Программный модуль основного меню
secdb.app.
Глава 10 195
10.4. Модуль BWLRST.PRG в R-.base 5000
Этот модуль вызывается из программы построения ос-
основного меню в том случае, когда выбирается воз-
возможность "СТАТИСТИЧЕСКИЕ ДАННЫЕ ПО ОТ-
ОТДЕЛЬНОМУ ИГРОКУ". Модуль предназначен для
вычисления некоторых статистических данных, касаю-
касающихся определенного игрока, и вывода этих данных.
Статистические данные могут быть получены для лю-
любой недели сезона, включая последнюю, для которой
результаты были занесены в БД. Логика модуля
представлена на рис. 10.7, его исходный текст приве-
приведен на рис. 10.8, типичные выходные данные модуля
- на рис. 10.9.
1. Определить номер последней недели, для которой в отноше-
отношение SCORES были внесены результаты. Сохранить его в max_wk.
2. Ввести номер недели, по которой необходимо получение
статистических данных, в переменную wk и проверить правиль-
правильность ввода.
3. Ввести имя-и-фамилию игрока, о котором требуется стати-
статистическая информация, в переменную name и проверить их пра-
правильность.
4. Применяя команду SET POINTER в R:base 5000 идентифициро-
идентифицировать все кортежи в SCORES, которые будут использоваться при
вычислениях. (Условием является bname=name AND week<=wk.)
5. Для каждого кортежа в группе, выбранной с помощью SET
POINTER, выполнить следующие действия:
а) проверить каждый показанный в игре индивидуальный ре-
результат с целью нахождения среди игр наилучшей для данного
игрока с сохранением показанного в этой игре результата в
переменной h1_game;
б) проверить сумму набранных очков в каждой трехматчевой
серии с целью нахождения наилучшей серии с сохранением по-
показанного в этой серии результата в переменной hi_series;
в) получить сумму всех индивидуальных результатов, пока-
показанных в отдельных играх, и сохранить общее число очков,
набранных без учета гандикапа, в переменной totjpins.
6. Вычислить для данного игрока текущие результативность и
гандикап и поместить их в переменных bavg и hndkp соответ-
соответственно.
7. Вывести результаты.
Рис. 10.7. Общий алгоритм модуля bwlrst.prg
196 R:base 5000-реализация БД секретаря кегельной лиги
*(Имя процедуры: bwlrst.prg )
*(Автор Глен А. Джексон )
*(Оклендский университет, Рочестер, Ml 48063 )
*( )
*(Эта процедура предназначена для вычисления и вывода )
*( статистических данных, характеризующих отдельного игрока:)
*( Лучшая игра, Лучшая серия, Общее число набранных очков )
*( и Гандикап. Во всех статистических данных учитываются все )
*(проведенные к настоящему моменту игры. )
*( )
*( Эта процедура вызывается из sdbmain. )
*( Эта процедура не вызывает другие модули. )
NEWPAGE
SET VAR h1_game INTEGER
SET VAR h1_ser INTEGER
SET VAR bavg INTEGER
SET VAR hndkp INTEGER
SET VAR max_wk INTEGER
SET VAR wk INTEGER
SET VAR temp INTEGER
SET VAR totpins INTEGER
SET VAR name TEXT
SET VAR done TEXT
SET VAR check INTEGER
SET VAR tot3 INTEGER
SET VAR totgam INTEGER
*()
*( Получение через max_wk номера последней)
*(недели, по которой были введены результаты. )
COMPUTE max_wk AS MAX week FROM scores
*()
*( Ввод через wk номера недели, на конец которой )
*(требуется статистика.)
SET VAR done TO "false"
WHILE done EXISTS THEN
WRITE "ЕСЛИ ТРЕБУЮТСЯ ПОСЛЕДНИЕ СТАТ. ДАННЫЕ" AT 7 15
WRITE "ВВЕДИТЕ" AT 8 15
SHOW VAR max_wk*l AT 8 21
WRITE "НОМЕР ПХЛ. НЕДЕЛИ, ПО КОТ. ВВОДИЛИСЬ ДАННЫЕ" AT 8 23
FILLIN wk USING "ИНАЧЕ - НОМЕР ТРЕБУЕМОЙ НЕДЕЛИ: " AT 9 15
IF wk GE 1 AND wk LE .max_wk THEN
BREAK
ENDIF
WRITE "НЕПРАВИЛЬНЫЙ ВВОД НОМЕРА НЕДЕЛИ" AT 15 15
WRITE "Нажмите любую клавишу для продолжения.." AT 17 15
PAUSE
Рис. 10.8. Модуль bwlrst.prg
Глава 10 197
NEWPAGE
ENDWHILE
*()
*(Ввод имени-и-фамилии игрока и проверка правильности ввода. )
*()
NEWPAGE
WHILE done EXISTS THEN
FILLIN name USING "ВВЕДИТЕ ИМЯ И ФАМИЛИЮ:1' AT 10 15
COMPUTE check AS COUNT bname FROM bowler WHERE bname=.name
IF check GT 0 THEN
BREAK
ENDIF
WRITE "УКАЗАННЫЕ ИМЯ И ФАМИЛИЯ В БД ОТСУТСТВУЮТ" AT 12 15
WRITE "Нажмите любую клавишу и повторите ввод " AT 14 15
PAUSE
NEWPAGE
ENDWHILE
NEWPAGE
*()
*( Вычисление статистических данных, характеризующих этого)
*( игрока )
*()
SET VAR h1_name TO 0
SET VAR h1_ser TO 0
SET VAR totpins TO 0
SET POINTER #1 errl FOR scores WHERE bname EQ .name AND
weeK Lt •wk
WHILE errl EQ 0 THEN
SET VAR temp TO gamel IN #1
IF temp GT .h1_game THEN
SET VAR h1_game TO .temp
ENDIF
SET VAR tot3 TO .temp
SET VAR temp TO game2 IN #1
IF temp GT .h1_game THEN
SET VAR h1_game TO .temp
ENDIF
SET VAR tot3 TO .temp + .tot3
SEJ VAR temp TO game3 IN #1
IF temp GT .h1_game THEN
SET var h1_game TO .temp
ENDIF
SET VAR tot3 TO .temp + .tot3
IF tot3 GT .h1_ser THEN
SET VAR h1_ser TO .tot3
ENDIF
SET VAR totpins TO .totpins + .tot3
NEXT #1 errl
Рис. 10.8. (Продолжение)
198 R-base 5000-реализация БД секретаря кегельной лиги
ENDWHILE
*( Вычисление гандикапа для данного игрока. )
*()
SET VAR totgam TO .wk x 3
SET VAR bavg TO .totpins / .totgam
IF bavg LT 200 THEN
SET VAR hndkp TO 200 - .bavg
SET VAR hndkp TO .hndkp x 0.75
ELSE
SET VAR hndkp TO 0
ENDIF
*()
*( Вывод результатов. )
*()
WRITE "СТАТИСТИКА ДЛЯ и AT 7 20
SHOW VAR name=15 AT 7 36
WRITE и НА КОНЕЦ НЕДЕЛИ " AT 7 51
SHOW VAR wk=l AT 7 61
WRITE "hihihiiihiiiiuhiiiiihiihiihihhih" AT 8 20
WRITE "СРЕДНЕЕ ЧИСЛО ОЧКОВ ЗА ИГРУ:" AT 10 20
SHOW VAR bavg=3 AT 10 43
WRITE "ОБЩЕЕ ЧИСЛО ОЧКОВ - БЕЗ ГАНДИКАПА:" AT 12 20
SHOW VAR totp1ns«4 AT 12 50
WRITE "ЛУЧШИЙ РЕЗУЛЬТАТ ЗА ИГРУ НА СЕГОДНЯ:" AT 14 20
SHOW VAR M_game=3 AT 14 45
WRITE "ЛУЧШАЯ СЕРИЯ НА СЕГОДНЯ:" AT 16 20
SHOW VAR h1_ser«3 AT 16 41
WRITE "ТЕКУЩИЙ ГАНДИКАП:" AT 18 20
SHOW VAR hndkp=2 AT 18 38
WRITE "Нажмите любую клавишу для продолжения" AT 23 20; PAUSE
CLEAR ALL VAR
RETURN
Рис. 10.8. (Окончание)
СТАТИСТИКА ДЛЯ Билл Блак НА КОНЕЦ НЕДЕЛИ 3
iinmniiHiimimiiHiHiiiHHHinm
СРЕДНЕЕ ЧИСЛО ОЧКОВ ЗА ИГРУ: 153
ОБЩЕЕ ЧИСЛО ОЧКОВ - БЕЗ ГАНДИКАПА: 1381
ЛУЧШИЙ РЕЗУЛЬТАТ ЗА ИГРУ НА СЕГОДНЯ: 165
ЛУЧШАЯ СЕРИЯ НА СЕГОДНЯ: 483
ТЕКУЩИЙ ГАНДИКАП: 35
Рис. 10.9. Типичные выходные данные модуля
bwlrst.prg
Глава 10 199
Единственной частью модуля bwlrst.prg, которая
нуждается в пояснении, является блок вычисления
гандикапа, состоящий из двух предложений
SET VAR hndkp TO 200 - .bavg
SET VAR hndkp TO .hndkp x 0.75
Здесь hndkp - целая переменная, объявленная как
INTEGER и предназначенная для хранения текущего
значения гандикапа данного игрока. Еще одна целая
переменная bavg содержит значение текущей резуль-
результативности игрока. Эти два предложения решают
уравнение
handicap - TRUNC(B00 - current-average)*0.75),
где TRUNC - функция усечения. Хотя hndkp являет-
является целочисленной переменной, ее умножение на 0.75
дает в результате вещественное значение. Это веще-
вещественное значение затем присваивается целочисленной
переменной hndkp. R:base 5000 автоматически выпол-
выполняет не округление, а усечение вещественного числа,
присваиваемого целой переменной. Если бы вещест-
вещественные величины не усекались, а округлялись при
получении гандикапа, то это привело бы к заметному
изменению статистических данных, касающихся как
отдельных игроков, так и команд в целом.
10.5. Программный модуль TEAMPNS.PRG в R:base 5000
Этот модуль вызывается в случае выбора в главном
меню возможности "ОБЩЕЕ ЧИСЛО ОЧКОВ КАЖ-
КАЖДОЙ КОМАНДЫ". Вычисленное общее число очков
является "чистым", т.е. без учета гандикапа. Моди-
Модификация этого модуля таким образом, чтобы при
подсчете общего числа очков учитывался гандикап,
приводится в качестве упражнения в конце главы.
Данный модуль разрабатывался в предположении, что
подсчет очков должен производиться с учетом послед-
последней недели, для которой в БД были введены резуль-
результаты встреч. Пример результатов выполнения этого
программного модуля приведен на рис. 10.10, его ло-
логика представлена на рис. 10.11 и, наконец, исход-
исходный текст - на рис. 10.12.
200 R:base 5000-реализация БД секретаря кегельной лиги
ОБЩЕЕ ЧИСЛО ЧИСТЫХ ОЧКОВ НА КОНЕЦ НЕДЕЛИ 4
I I I IJ I t I II И Н И I I II I I I I 1 I I I I I I I I I I I I 1 I I II И I I I I И
КОМАНДА НАЗВАНИЕ КОМАНДЫ ОБЩЕЕ ЧИСЛО ОЧКОВ
1 AlleyCats 6257
2 Inconsistents 6172
3 TenPins 6147
4 HighRollers 6798
5 Splitters 6580
6 SandBaggers 6534
Рис. 10.10. Типичный результат выполнения модуля
teampns.prg
1. Определить номер последней недели, по которой были вне-
сены результаты в отношение SCORES. Сохранить соответствую-
щее значение в переменной max_wk.
2. Вывести заголовок таблицы данных, которые будут выведены
позже.
3. Использовать внешний цикл WHILE - THEN (с переменной ctr
в качестве счетчика) с целью перебора всех 6 команд лиги.
По отношению к каждой команде воспользоваться директивой
SET POINTER #1 с целью определения всех игроков этой коман-
команды:
а) с помощью внутреннего цикла WHILE-THEN определить общее
число очков, набранных одной командой; сохранить получен-
полученное значение в переменной tot_p1ns;
б) просмотреть отношение TEAM с целью нахождения названия
команды по ее номеру; сохранить это название в переменной
name_t;
в) вывести данные, характеризующие эту команду, с одновре-
одновременной настройкой счетчика строк.
Рис. 10.11. Алгоритм программного модуля
teampns.prg
При сравнении логики модуля teampns.prg в слу-
случае R:base 5000 и логики того же самого модуля в
случае dBase III (разд. 9.4) обращает на себя внима-
внимание использование во втором случае оператора JOIN
с целью сбора всех результатов всех игроков одной
команды в общем информационном блоке (временное
отношение TEMPR2). Хотя оператор JOIN мог быть
Глава 10 201
использован тем же образом и в случае R:base 5000,
было решено, что с программной точки зрения проще
воспользоваться оператором SET POINTER для иден-
идентификации всех членов одной команды и затем про-
просуммировать результаты всех встреч для данной ко-
команды с помощью цикла WHILE-LOOP. Вопрос о
том, в каком случае обеспечивается более высокая
скорость выполнения - при использовании SET
POINTER или JOIN, - не рассматривался.
*(Имя процедуры: teampns.prg )
*(Автор Глен А. Джексон )
*(Оклендский университет, Рочестер, Ml 48063 )
*( )
*(Эта процедура выводит общее число "чистых")
*(очков, набранных каждой командой на данный)
*(момент.)
*( )
*(Эта процедура вызывается из sdbmain. )
*(Эта процедура вызывает: )
ч )
*(Процедура не имеет ни входных, ни выходных параметров. )
NEWPAGE
SET VAR max_wk INTEGER
COMPUTE max_wk AS MAX week FROM scores
*(Вывод заголовка для выходных данных. )
WRITE "ОБЩЕЕ ЧИСЛО ЧИСТЫХ ОЧКОВ НА КОНЕЦ НЕДЕЛИ" AT 5 20
SHOW VAR max_wk-l AT 5 53
WRITE "iiiiiiiiihiihiihiiiiihhuiihihhiiihh" AT 6 20
WRITE "КОМАНДА НАЗВАНИЕ КОМАНДЫ ОБЩЕЕ ЧИСЛО ОЧКОВ" AT 7 20
WRITE и " AT 8 20
*( )
*(Вычисление и вывод общего числа очков, набранных каждой )
*(командой. )
*( )
SET VAR ctr INTEGER
SET VAR lyne INTEGER
SET VAR gsuml INTEGER
SET VAR gsum2 INTEGER
SET VAR gsum3 INTEGER
SET VAR name_t TEXT
SET VAR name_b TEXT
SET VAR errl INTEGER
SET VAR ctr TO 1
Рис. 10.12. Модуль teampns.prg
202 R:base 5000-реализация БД секретаря кегельной лиги
*( Внешний цикл выбора команды.
*()
WHILE ctr LE 6 THEN
SET POINTER #1 errl FOR bowler WHERE tnumb EQ .ctr
*
Внутренний цикл выбора игроков команды. )
SET VAR totpins TO 0
WHILE errl EQ 0 THEN
SET VAR namej) TO bname IN #1
COMPUTE gsuml AS SUM gamel FROM scores WHERE bname=.name_b
COMPUTE gsum2 AS SUM game2 FROM scores WHERE bnarae«.name_b
COMPUTE gsun3 AS SUM game3 FROM scores WHERE bname>.name_b
SET VAR totpins TO .totpins + .gsuml
SET VAR totpins TO .totpins + .gsum2
SET VAR totpins TO .totpins + .gsuw3
NEXT #1 errl
ENDWHILE
*()
SET VAR name_t TO tname IN team WHERE tnumb=.ctr
SET VAR lyne TO .ctr + 8
SHOW VAR ctr«l AT .lyne 23
SHOW VAR name t=15 AT .lyne 30
SHOW VAR totpTns«5 AT .lyne 49
SET VAR ctr TO .ctr + 1
ENDWHILE
WRITE "Нажмите любую клавишу для продолжения работы." AT 20 20
PAUSE
CLEAR ALL VAR
RETURN
Рис 10.12. (Окончание)
10.6. Программный модуль WKSCHDL.PRG в R:base 5000
Этот программный модуль вызывается из программы
главного меню при выборе в последнем варианта
"ВЫВОД РАСПИСАНИЯ ВСТРЕЧ ДЛЯ ДАННОЙ
НЕДЕЛИ". Результатом выполнения модуля является
вывод таблицы названий команд и площадок, которые
назначены этим командам на данную неделю текуще-
текущего сезона. Модуль запрашивает на входе номер неде-
недели, для которой требуется расписание, и перед прове-
проведением требуемых вычислений проверяет правильность
введенного номера недели. Типичные результаты вы-
выполнения модуля приведены на рис. 10.13. Логика
модуля отражена на рис. 10.14, исходный текст при-
приводится на рис. 10.15.
Глава 10 203
РАСПИСАНИЕ НА НЕДЕЛЮ С НОМЕРОМ 3
imiiiiinmiHiHHHiHiHH
КОМАНДА НОМЕР ПЛОЩАДКИ
AiieyCats 3
Ineons 1stents б
TenPins 1
HighRollers 4
Splitters 5
SandBaggers 2
Рис. 10.13. Типичный результат выполнения модуля
wkschdl.prg
1. Определить номер последней недели сезона. Присвоить это
значение переменной maxwk.
2. Ввести номер недели сезона, для которой требуется полу-
получить календарь, в переменную in_val и проверить правиль-
правильность введенного значения.
3. Вывести заголовок для таблицы данных, которые предпола-
предполагается вывести.
4. С помощью применения команды SET POINTER к отношению
SCHED идентифицировать все кортежи, в которых значение ат-
атрибута week совпадает со значением переменной in_val.
5. Использовать цикл WHILE - THEN для перебора всех команд,
принадлежащих множеству команд, связанных между собой с по-
помощью команды SET POINTER на шаге 4. Вывести названия ко-
команд (tname), найденных в отношении TEAM, и номера площадок
(lane), полученных из отношения SCHED для каждой команды.
Рис. 10.14. Логика модуля wkschdl.prg.
Сердцевина логической схемы в модуле wkschdl.prg
реализована с помощью команды SET POINTER и
следующей за ней конструкции WHILE-THEN, что
замещает возможную операцию JOIN. Применение в
алгоритме операции JOIN предлагается в конце главы
в качестве задачи.
204 R:base 5000-реализация БД секретаря кегельной лиги
$COMMAND
wkschdl
*(Имя процедуры: wkschdl )
*(Автор Гленн А. Джексон )
*(Процедура выводит расписание встреч для данной недели. )
*(Номер недели вводится с терминала )
*(Эта процедура вызывается из sdbmain. )
*(Эта процедура вызывает модуль delay. )
NEVPAGE
*( Нахождение последней недели и занесение ее в maxwk.)
SET VAR max_wk INTEGER
COMPUTE max_wk AS MAX week FROM sched
*(Ввод номера требуемой недели и проверка значения. )
SET VAR done TEXT
SET VAR done TO "false"
SET VAR 1n_val INTEGER
WHILE done EXISTS THEN
WRITE "ВВЕДИТЕ НОМЕР ТРЕБУЕМОЙ НЕДЕЛИ" AT 7 10
WRITE "ТОЛЬКО ЗНАЧЕНИЯ В ДИАПАЗОНЕ ОТ 1 ДО" AT 8 10
SHOW VAR max_wk=l AT 8 36
FILLIN 1n_val USING "ЯВЛЯЮТСЯ ДОПУСТИМЫМИ" AT 8 38
IF 1n_val LE .maxjrfc AND 1n_val GE 1 THEN
BREAK
ENDIF
WRITE "ВВЕДЕННЫЙ НОМЕР НЕДЕЛИ НЕКОРРЕКТЕН" AT 15 10
WRITE "Нажмите любую клавишу для продолжения" AT 16 10;PAUSE
NEWPAGE
ENDWHILE
NEWPAGE
WRITE " РАСПИСАНИЕ НА НЕДЕЛЮ С НОМЕРОМ" AT 5 10
SHOW VAR 1n_val=l AT 5 46
WRITE " niiHiimiiiniHiniinmm" AT 6 10
WRITE " КОМАНДА НОМЕР ПЛОЩАДКИ" AT 7 10
WRITE " --" AT 8 10
*(Определение и вывод расписания. )
SET POINTER #1 errl FOR sched WHERE week EQ .1n_va1
SET VAR In INTEGER; SET VAR lyne INTEGER; SET VAR lyne TO 9
WHILE errl EQ 0 THEN
SET VAR numb TO tnumb IN #1
SET VAR name TO tname IN team WHERE tnumb EQ .numb
SET VAR In TO lane IN #1
SHOW VAR name=15 AT .lyne 17
SHOW VAR ln=l AT .lyne 41
SHOW VAR lyne TO .lyne + 1
NEXT #1 errl
ENDWHILE
WRITE "Нажмите любую клавишу для продолжения." AT 20 17; PAUSE
CLEAR ALL VAR
RETURN
Рис. 10Л5. Программный модуль wkschdl.prg.
Глава 10 205
10.7. Программный модуль EOSRPT.PRG в R:base
5000
Этот модуль вызывается из программы главного меню
в случае выбора альтернативы "ГЕНЕРАЦИЯ ОТЧЕ-
ОТЧЕТА О РЕЗУЛЬТАТАХ СЕЗОНА". Результатом выпол-
выполнения этого модуля является определение и вывод
имен-и-фамилий тех игроков, которые в сезоне: 1 -
показали наивысший индивидуальный результат в од-
одной игре; 2 - показали наивысший результат в трех-
матчевой серии; 3 - закончили сезон с наивысшей
результативностью (среднее число набираемых очков
в одной игре).
Результаты выполнения этого модуля в случае,
когда исходные данные были получены из приведен-
приведенного примера БД, показаны на рис. 10.16. Логика
модуля представлена на рис. 10.17, а его исходный
текст - на рис. 10.18.
ОТЧЕТ 0 РЕЗУЛЬТАТАХ СЕЗОНА
IIIHIIIIIIIHHIIIIIIIHI
НАИЛУЧШИЙ РЕЗУЛЬТАТ ЗА ОДНУ ИГРУ - 202
ОЧКА - ПОКАЗАН СЛЕДУЮЩИМИ ИГРОКАМИ:
Рой Лейн
Рассел Тейлор
Пол Миллер
ЛУЧШИЕ СЕРИИ ИЗ ТРЕХ МАТЧЕЙ - 559
ОЧКОВ - ПРОВЕЛИ СЛЕДУЮЩИЕ ИГРОКИ:
Рой Лейн
Пол Миллер
ЛУЧШАЯ РЕЗУЛЬТАТИВНОСТЬ В СЕЗОНЕ - 179
ОЧКОВ - БЫЛА ПОКАЗАНА ИГРОКАМИ:
Пол Миллер
Рис. 10.16. Результат выполнения модуля eosrpt.prg
206 R:base 5000-реализация БД секретаря кегельной лиги
1. Определить последнюю неделю сезона по информации, содер-
содержащейся в отношении SCHED. Сохранить полученное значение в
переменной max_wk.
2. Определить лучший индивидуальный результат сезона (наи-
(наибольшее число очков, набранных за игру). Сохранить получен-
полученное значение в переменной bestjjaw.
3. Вывести информацию о лучшем результате, показанном в од-
одной встрече:
а) получить с помощью оператора PROJECT унарное временное
отношение TEHPR из отношения SCHED, содержащее имена-и-фа-
милии (bnames) всех игроков, которые показали хотя бы в
одной игре результат, равный лучшему;
б) вывести заголовок отчета о результатах сезона с после-
последующим выводом имен-и-фамилий всех тех игроков, которые
показали хотя бы в одной игре результат, равный лучшему;
с) удалить оператором REMOVE временное отношение TEHPR из
БД.
4. Получить результат лучшей трехматчевой серии в перемен-
переменной bestser с помощью выполнения следующих действий:
а) добавить оператором EXPAND новый столбец с именем
total к отношению SCORES;
б) заполнить поле total каждого кортежа суммой
gamel+game2+game3 значений, полученных из этого кортежа;
в) найти значения переменной best_ser, применив команду
COMPUTE - МАХ к полю total отношения SCORES;
г) выделить оператором PROJECT из отношения SCORES вре-
временное отношение TEMPR, содержащее имена-и-фамилии всех
игроков, показавших лучший результат, хранимый в best_ser;
д) вывести информацию о лучших сериях.
5. Получить лучшую результативность, показанную в сезоне, в
переменной best_avg с помощью выполнения следующих дейст-
действий:
а) выделить оператором PROJECT из отношения BOWLER вре-
временное отношение ТЕМР2, содержащее имя-и-фамилию (bname)
каждого игрока и его начальную результативность (stavg);
б) заменить название столбца stavg в отношении ТЕМР2 на
avg;
в) вычислить результативность каждого игрока и занести
полученное значение в поле avg отношения ТЕМР2;
г) вычислить с помощью команды COMPUTE - МАХ значение
best_avg и вывести окончательные результаты;
д) вывести информацию о лучшей результативности.
6. Удалить столбец (REMOVE COLUMN) total из отношения
SCORES.
7. Удалить (REMOVE) отношение ТЕМР2 из БД.
Рис. 10.17. Логика программного модуля eosrpt.prg
Глава 10 207
*(Имя процедуры: eosrpt )
*(Автор Гленн А. Джексон )
*@клендский университет, Рочестер, HI 48063)
*о
*(Эта процедура готовит отчет о результатах сезона и )
*(осуществляет его вывод )
*()
*(Эта процедура вызывается из модуля sdbmain. )
*(Эта процедура не вызывает другие модули. )
NEVPAGE
SET MESSAGE OFF
SET ERROR MESSAGE OFF
*()
*(Нахождение последней недели сезона и занесение значения в)
*( max_wk.)
*()
SET VAR max_wk INTEGER
COMPUTE max_wk AS MAX week FROM sched
*(Инициализация переменных, необходимых при подготовке)
*( отчета. )
SET VAR best_ser INTEGER
SET VAR best_avg INTEGER
SET VAR best_gan INTEGER
SET VAR name TEXT
SET VAR hgl INTEGER
SET VAR hg2 INTEGER
SET VAR hg3 INTEGER
SET VAR Unect INTEGER
*()
*(Нахождение лучшего результата сезона и сохранение его в)
*( best gam.)
*() "
COMPUTE hgl AS MAX gamel FROM scores
COMPUTE hg2 AS MAX game2 FROM scores
COMPUTE hg3 AS MAX game3 FROM scores
IF hgl >« .hg2 THEN
SET VAR best_gam TO .hgl
ELSE
SET VAR best_gam TO .hg2
ENDIF
IF hg3 >« .best_gam THEN
SET VAR best_gam TO .best_gam + .hg3
ENDIF
*()
*(Занесение имен и фамилий всех, показавших лучший результат,)
*( в TEMPR.)
*()
PROJECT tempr FROM scores USING bname +
Рис. 10.18 Модуль eosrpt.prg
208 R:base 5000-реализация БД секретаря кегельной лиги
WHERE gamel-.best_gam OR game2-.best_gam OR game3«.best_gam
DELETE DUPLICATES FROM tempr
*()
*(Вывод заголовка отчета и данных по лучшей игре. )
*()
WRITE "ОТЧЕТ О РЕЗУЛЬТАТАХ СЕЗОНА" AT 1 26
WRITE " AT 2 26
WRITE "НАИЛУЧШИЙ РЕЗУЛЬТАТ ЗА ОДНУ ИГРУ - "" AT 4 20
SHOW VAR best_gam=3 AT 4 49
WRITE "ОЧКОВ - ПОКАЗАН СЛЕДУЮЩИМИ ИГРОКАМИ:" AT 5 20
SET VAR 11nest TO 6
SET POINTER #1 errl FOR tempr
WHILE errl«0 THEN
SET VAR name TO bnaine IN #1
SHOW VAR name=15 AT .linect 30
SET VAR linect TO .linect + 1
NEXT #1 errl
ENDWHILE
REMOVE tempr
*()
*(Нахождение результата лучшей серии с занесением его в)
*( best ser и вывод результатов. )
*() "
EXPAND scores WITH total INTEGER
ASSIGN total TO gamel + game2 IN scores
ASSIGN total TO total + game3 IN scores
COMPUTE best_ser AS MAX total FROM scores
PROJECT tempr FROM scores USING bname +
WHERE total».best_ser
DELETE DUPLICATES FROM tempr
SET VAR Unect TO .linect + 2
WRITE "ЛУЧШИЕ СЕРИИ ИЗ ТРЕХ МАТЧЕЙ - " AT .Unect 20
SHOW VAR best_ser«3 AT .Unect 55
SET VAR Unect TO .Unect + 1
WRITE "ОЧКОВ - ПРОВЕЛИ СЛЕДУЮЩИЕ ИГРОКИ:" AT .Unect 20
SET VAR Unect TO .Unect + 1
SET POINTER #1 errl FOR tempr
WHILE errl=0 THEN
SET VAR name TO bname IN #1
SHOW VAR name=15 AT .Unect 30
SET VAR Unect TO .Unect + 1
NEXT #1 errl
ENDWHILE
REMOVE tempr
*()
*(Нахождение наивысшей результативности, показанной в сезоне,)
*( с занесением ее в best_avg и вывод результатов. )
SET VAR tgames INTEGER
Рис. 10.18 (Продолжение)
Глава 10 209
SET VAR totpins INTEGER
SET VAR tgames INTEGER
SET VAR errl INTEGER
SET VAR err2 INTEGER
PROJECT temp2 FROM bowler USING bname stavg
CHANGE COLUMN stavg IN temp2 TO avg
SET VAR tgames TO .max_wk x 3
SET POINTER #1 errl FOR temp2
WHILE errl«0 THEN
SET VAR name TO bname IN #1
COMPUTE totpins AS SUM total FROM scores +
WHERE bname-.name
ASSIGN avg TO .totpins / .tgames IN temp2 WHERE bname».name
NEXT #1 errl
ENDWHILE
COMPUTE best avg AS MAX avg FROM temp2
*()
SET VAR Unect TO .Unect + 2
WRITE -ЛУЧШАЯ РЕЗУЛЬТАТИВНОСТЬ В СЕЗОНЕ" AT .Unect 20
SHOW VAR best_avg=3 AT .Unect 50
SET VAR Unect TO .Unect + 1
WRITE "ОЧКОВ ЗА ИГРУ - БЫЛА ПОКАЗАНА ИГРОКАМИ:" AT.Unect 20
SET VAR Unect TO .Unect + 1
SET POINTER #2 err2 FOR temp2 +
WHERE avg=.best_avg
WHILE err2=0 THEN
SET VAR name TO bname IN #2
SHOW VAR name-15 AT .Unect 30
SET VAR Unect TO .Unect + 1
NEXT #2 err2
ENDWHILE
REMOVE temp2
REMOVE COLUMN total FROM scores
SET MESSAGE ON
SET ERROR MESSAGE ON
WRITE "Нажмите любую клавишу для продолжения." AT 21 20; PAUSE
RETURN
Рис. 10.18 (Окончание)
10.8. Программный модуль TEAMSTD.PRG в R:base
5000
Этот программный модуль вызывается из программы
построения основного меню при выборе альтернативы
"ВЫВОД ПОЛОЖЕНИЯ КОМАНД". Результатом вы-
выполнения teamstd.prg является расчет и вывод табли-
таблицы положения всех команд лиги на конец данной не-
недели сезона. Также выводится общее число "чистых"
210 R:base 5000-реализация БД секретаря кегельной лиги
очков, набранных каждой из команд на конец этой
недели. В начале работы модуль запрашивает номер
недели, на конец которой необходимо узнать положе-
положение команд. Убедившись в том, что номер введен
правильно, программа приступает к необходимым для
получения положения команд расчетам с последую-
последующим выводом результатов в табличной форме. На
рис. 10.19 представлены типичные результаты выпол-
выполнения программы. Логика модуля отражена на рис.
10.20, а его исходный текст - на рис. 10.21.
ПО СОСТОЯНИЮ В НОЧЬ НА ПОНЕДЕЛЬНИК
ПОЛОЖЕНИЕ КОМАНД НА КОНЕЦ НЕДЕЛИ 1
tnumb wins losses totpins
1
2
3
4
5
6
2.00000
2.00000
1.00000
3.00000
2.50000
1.50000
2.00000
2.00000
3.00000
1.00000
1.50000
2.50000
1545
1522
1519
1670
1599
1593
Рис. 10.19. Типичные выходные данные модуля
teamstd.prg
По сравнению с любым другим модулем данной
реализации логика модуля teamstd.prg является более
сложной. В результате проектного решения, принятого
в гл. 5, число побед, поражений и общее число оч-
очков, набранных каждой командой на конец каждой
недели, в БД не сохраняются. Это было сделано для
того, чтобы избежать возможной несогласованности
данных в БД в тех случаях, когда кто-либо изменяет
результат встречи без перерасчета эффекта этого из-
изменения на число побед, поражений я общего числа
очков. Один из результатов этого проектного решения
заключается в том, что для вычисления положения
команд для некоторой недели необходимо рассчитать
турнирную таблицу для всех недель, предшествующих
данной, начиная с первой. Это приводит не только к
усложнению логики модуля teamstd.prg, но и резко
Глава 10 211
увеличивает время, необходимое для проведения рас-
расчетов и получения результатов. Временные затраты
на получение положения команд увеличиваются ли-
линейно в зависимости от числа недель, для которых
эти данные требуются. Именно, требуется приблизи-
приблизительно в три раза больше времени на вычисление
положения команд на конец третьей недели, чем на
вычисление итогов первой недели.
1. Определить последнюю неделю, по которой были внесены ре-
результаты в отношение SCORES. Сохранить полученный номер в
переменной max_wk.
2. Ввести в переменную in_wk номер недели, на конец которой
требуется получить положение команд, и проверить правиль-
правильность ввода.
3. Обнулить значения wins, losses, totpins во всех кортехах
нового отношения TSTATS.
4. Для каждой площадки (обозначается как In) выполнить сле-
следующие действия применительно к каждой неделе (обозначается
как wk):
а) используя комбинацию команд SET POINTER #2 и WHILE -
THEN, провести вычисления по каждому игроку команды, вы-
ступавшей на данной площадке на данной неделе. Для каждого
игрока: A) вычислить текущий гандикап и занести в пере-
переменную "hndkp"; B) каждый индивидуальный результат, пока-
показанный в игре, добавить к общему результату команды в дан-
данной игре (с учетом гандикапа); C) значение totpins в от-
отношении TSTATS для данной команды заместить текущим значе-
значением, увеличенным на число очков, набранных данным игроком
в трехматчевой серии (без учета гандикапа); используются
следующие обозначения: gla - общее число очков, набранных
командой, выступающей на площадке с нечетным номером в иг-
игре 1 (gamel); gib - общее число очков, набранных командой,
выступающей на площадке с четным номером в игре 1 (gamel).
g2a, g3a, g2b, дЗЬ имеют аналогичный смысл;
б) настроить запись побед-поражений (в TSTATS), относящую-
относящуюся к двум последним командам, подвергшимся анализу; здесь
используется следующий способ кодировки: идентификатор ко-
команды, выступающей на площадке с нечетным номером, оканчи-
оканчивается символом "а", а идентификатор команды, выступающей
на площадке с четным номером, - символом "Ь".
5. Вывести положения команд путем выборки (оператором
SELECT) всех данных, содержащихся в отношении TSTATS вслед
за выводом нужного заголовка.
Рис. 10.20. Логика модуля teamstd.prg
212 R:base 5000-реализация БД секретаря кегельной лиги
*(Имя процедуры: teamstd.prg )
*(Автор Гленн А. Джексон )
*(Оклендский университет, Рочестер, HI 48063 )
*(Эта процедура рассчитывает и выводит таблицу положения)
*( команд для любой недели. Номер требуемой недели вводится)
*( с терминала.)
*(Процедура вызывается из sdbmain )
NEVPAGE
SET VAR max_wk INTEGER
SET VAR 1n_wk INTEGER
SET VAR done TEXT
*@пределение последней недели, по которой были введены)
*( результаты, и сохранение номера в переменной max_wk. )
COMPUTE max_wk AS MAX week FROM scores
*(Ввод номера требуемой недели... и проверка ввода )
SET VAR done TO "false"
WHILE done EXISTS THEN
WRITE "ВВЕДИТЕ НОМЕР ТРЕБУЕМОЙ НЕДЕЛИ" AT 7 10
WRITE " ТОЛЬКО ЗНАЧЕНИЯ В ДИАПАЗОНЕ ОТ 1 ДО" AT 8 10
SHOW var max_wk=l AT 8 36
FILLIN 1n_wk USING " ЯВЛЯЮТСЯ ДОПУСТИМЫМИ " AT 8 38
IF 1n_wk LE .max_wk AND 1n_wk GE 1 THEN
BREAK
ENDIF
WRITE "НЕКОРРЕКТНЫЙ ВВОД НОМЕРА НЕДЕЛИ" AT 15 10
WRITE "Нажмите любую клавишу для продолжения" AT 16 10; PAUSE
NEWPAGE
ENDWHILE
*()
SET VAR errl INTEGER
SET VAR err2 INTEGER
SET VAR еггЗ INTEGER
SET VAR tot INTEGER
SET VAR avg INTEGER
SET VAR tnb INTEGER
SET VAR hndkp INTEGER
SET VAR teama INTEGER
SET VAR teamb INTEGER
SET VAR tota INTEGER
SET VAR totb INTEGER
SET VAR name TEXT
SET VAR gla TO 0
SET VAR g2a TO 0
SET VAR g3a TO 0
SET VAR gib TO 0
SET VAR g2b TO 0
SET VAR g3b TO 0
SET VAR In TO 1
SET VAR wk TO 1
Рис. 10.21. Модуль teamstd.prg
Глава 10 213
*(До того как будет начат расчет нового положения команд, )
*( все значения атрибутов wins, losses и totpins обнуляются)
*(в отношении TSTATS.)
ASSIGN wins TO 0.0 + 0.0 IN tstats
ASSIGN losses TO 0.0 + 0.0 IN tstats
ASSIGN totpins TO 0 + 0 IN tstats
*(Начало вычисления положения команд - вычисления выполняются)
*( с шагом, равным неделе, начиная с 1 и кончая maxwk.)
WHILE wk <= .1n_wk THEN
SET POINTER #1 errl FOR sched WHERE week = .wk AND lane «.In
SET VAR tnb TO tnunb IN #1
SET POINTER #2 err2 FOR bowler WHERE tnumb =.tnb
WHILE err2=0 THEN
SET VAR name TO bname IN #2
*()
IF wk=l THEN
SET VAR avg TO stavg IN #2
ELSE
RUN getavg.prg *(НАЙТИ avg ДЛЯ ДАННОЙ НЕДЕЛИ)
ENDIF
IF avg < 200 THEN
SET VAR hndkp TO 200 - .avg
SET VAR hndkp TO .hndkp x 0.75
ELSE
SET VAR hndkp TO 0
ENDIF
*()
SET POINTER #3 FOR scores WHERE bname».name AND week=.wk
SET VAR gl TO gamel IN #3
SET VAR g2 TO game2 IN #3
SET VAR g3 TO game3 IN #3
IF ln»l OR ln=*3' OR ln«5 THEN
SET VAR gla TO .gla + .gl
SET
SET
SET
SET
SET
ELSE
SET
SET
SET
SET
SET
SET
ENDIF
VAR
VAR
VAR
VAR
VAR
VAR
VAR
VAR
VAR
VAR
VAR
gla
g2a
g2a
g3a
g3a
gib
gib
g2b
g2b
g3b
g3b
TO
TO
TO
TO
TO
TO
TO
TO
TO
TO
TO
SET VAR tot TO .
SET VAR tot TO .
.gla
.g2a
.g2a
.g3a
.g3a
.gib
.gib
.g2b
.g2b
.g3b
.g3b
gl +
tot +
+ .hndkp
+.g2
+ .hndkp
+ .g3
+ .hndkp
+ .gl
+ .hndkp
+ .g2
+ .hndkp
+ .g3
+ .hndkp
•g2
.93
ASSIGN totpins TO totpins+.tot IN tstats WHERE tnumb=.tnb
Рис. 10.21. (Продолжение)
214 R:base 5000-реализация БД секретаря кегельной лиги
NEXT #2 егг2
ENDWHILE
*()
IF ln«2 OR ln«4 OR ln«6 THEN
SET VAR teamb TO .tnb
IF gla > .gib THEN
ASSIGN wins TO wins+1.0 IN tstats WHERE tnumb».teama
ASSIGN losses TO losses+l.O IN tstats WHERE tnumb».teamb
ELSE
IF gib > .gla THEN
ASSIGN wins TO wins+1.0 IN tstats WHERE tnumb».teamb
ASSIGN losses TO losses+l.O IN tstats WHERE tnumb*.teama
ELSE
ASSIGN wins TO wins+0.5 IN tstats +
WHERE tnumb*.teama OR tnumb».teamb
ASSIGN losses TO 1osses+0.5 IN tstats +
WHERE tnumb=.teama OR tnumb=.teamb
ENDIF
ENDIF
*()
IF g2a > .g2b THEN
ASSIGN wins TO wins+1.0 IN tstats WHERE tnumb=.teama
ASSIGN losses TO losses+l.O IN tstats WHERE tnumb=.teamb
ELSE
IF g2b > .g2a THEN
ASSIGN wins TO wins+1.0 IN tstats WHERE tnumb=.teamb
ASSIGN losses TO losses+l.O IN tstats WHERE tnumb=.teama
ELSE
ASSIGN wins TO wins+0.5 IN tstats +
WHERE tnumb=.teama OR tnumb=.teamb
ASSIGN losses TO 1osses+0.5 IN tstats +
WHERE tnumb=.teama OR tnumb=.teamb
ENDIF
ENDIF
*()
IF g3a > .g3b THEN
ASSIGN wins TO wins+1.0 IN tstats WHERE tnumb».teama
ASSIGN losses TO losses+l.O IN tstats WHERE tnumb».teamb
ELSE
IF g3b > .g3a THEN
ASSIGN wins TO wins+1.0 IN tstats WHERE tnumb=.teamb
ASSIGN losses TO losses+l.O IN tstats WHERE tnumb=.teama
ELSE
ASSIGN wins TO wins+0.5 IN tstats +
WHERE tnumb=.teama OR tnumb=.teamb
ASSIGN losses TO 1osses+0.5 IN tstats +
WHERE tnumb=.teama OR tnumb=.teamb
ENDIF
Рис. 10.21. (Продолжение)
Глава 10 215
ENDIF
SET VAR tota TO .gla + .g2a
SET VAR tota TO .tota + .g3a
SET VAR totb TO .gib + .g2b
SET VAR totb TO .totb + .g3b
IF tota > .totb THEN
ASSIGN wins TO wins+1.0 IN tstats WHERE tnumb».teama
ASSIGN losses TO losses+l.O IN tstats WHERE tnumb«teamb
ELSE
IF totb > .tota THEN
ASSIGN wins TO wins+1.0 IN tstats WHERE tnumb « .teamb
ASSIGN losses TO losses+l.O IN tstats WHERE tnumb».teama
ELSE
ASSIGN wins TO wins + 0.5 IN tstats +
WHERE tnumb = .teama OR tnumb = .teamb
ASSIGN losses TO losses + 0.5 IN tstats +
WHERE tnumb = .teama OR tnumb = .teamb
ENDIF
ENDIF
*()
SET VAR gla TO 0
SET VAR g2a TO 0
SET VAR g3a TO 0
SET VAR gib TO 0
SET VAR g2b TO 0
SET VAR g3b TO 0
ELSE
SET VAR teama TO .tnb
ENDIF
IF In = 6 THEN
SET VAR In TO 1
SET VAR wk TO .wk + 1
ELSE
SET VAR In TO .In + 1
ENDIF
ENDVHILE
*(Вывод положения команд для недели, номер которой был введен)
*( выше.)
*()
NEWPAGE
WRITE " ПО СОСТОЯНИЮ В НОЧЬ НА ПОНЕДЕЛЬНИК"
WRITE " ПОЛОХЕНИЕ КОМАНД НА КОНЕЦ НЕДЕЛИ " AT 6 1
SHOW VAR 1n_wk=l AT 6 36
WRITE w и
SELECT ALL FROM tstats
WRITE "Нажмите любую клавишу для продолжения работы." AT 22 5;
PAUSE
RETURN
Рис. 10.21. (Окончание)
216 Rtbase 5000-реализация БД секретаря кегельной лиги
R>11st tstats
Table: tstats
Read Password: NO
Modify Password: NO
Column definitions
# Name Type
1 tnumb INTEGER
2 wins REAL
3 losses REAL
4 totpins INTEGER
Length
1 vaiue(s)
1 vaiue(s)
1 vaiue(s)
1 vaiue(s)
Key
Current number of rows:
R>
(a)
R>se1ect all from tstats
tnumb wins losses totpins
1
2
3
4
5
6
0.00000
0.00000
0.00000
0.00000
0.00000
0.00000
0.00000
0.00000
0.00000
0.00000
0.00000
0.00000
R>
F)
Рис. 10.22. Структура (а) и содержимое (б) отноше-
отношения TSTATS в начальный момент выполнения модуля
teamstd.prg.
Так как победы, поражения и общее число на-
набранных очков не хранятся как часть базовых отно-
отношений в БД, было создано временное отношение для
хранения указанных данных только в течение процес-
процесса вычислений, выполняемых при получении данных
о положении команд. Это отношение имеет вид
Глава 10 217
TSTATS(tnumb,wins,losses,totpins),
а его содержимое в момент начала вычислений дан-
данных о положении команд представлено на рис. 10.22.
Гарантией того, что отношение не содержит данных,
оставшихся от предыдущих вычислений, служит уста-
установка в ноль значений wins, losses и totpins в начале
выполнения модуля teamstd.prg. (Возможный способ
повышения скорости выполнения модуля заключается
в сохранении данных в этом отношении с недельной
периодичностью. Однако в основе этого способа лежит по-
попытка обойти решение, принятое при проектировании, со-
согласно которому эти данные не должны храниться в БД.)
Основное затруднение, с которым может столк-
столкнуться читатель при рассмотрении логики модуля
teamstd.prg, заключено в методе образования пар (раз-
(разбиения по парам) команд, выступающих на соседних
площадках. Согласно алгоритму, вначале определяется
номер tnumb команды, которой назначается на данной
неделе площадка с номером 1 (с помощью примене-
применения команды SET POINTER #1 к отношению
SCHED (рис. 10.23)). Номер tnumb, получаемый че-
через pointer #1, используется с целью нахождения
всех игроков этой команды с помощью применения
SET POINTER #2 к отношению BOWLER. Индиви-
Индивидуальные результаты, показанные игроком, найденным
с помощью pointer #2 для команды, номер которой
получен через pointer #1, получаются с помощью
применения SET POINTER #3 к отношению SCORES.
Результаты, показанные всеми игроками команды,
выступающей на площадке 1, хранятся в переменных,
оканчивающихся символом "а", таких как, например,
gla. Символ "а" подразумевает ту из рассматривае-
рассматриваемых двух команд, которая выступает на площадке с
нечетным номером. При переключении переменной
площадки (In) на площадку 2 индивидуальные ре-
результаты всех членов соответствующей команды со-
сохраняются в переменных, оканчивающихся на символ
"Ь", таких, как, например, переменная gib. Символ
"Ь" подразумевает ту из рассматриваемых двух ко-
команд, которая выступает на площадке с четным но-
номером. По завершении анализа индивидуальных ре-
результатов, показанных всеми игроками обеих команд,
могут быть определены все победы и поражения рас-
218 R:base 5000-реализация БД секретаря кегельной лиги
сматриваемой недели. В этой точке та же процедура
используется для команд, которым назначены следую-
следующие две площадки. Этот процесс будет продолжаться
до тех пор, пока не будут исчерпаны все команды.
SCHED
указатель #!-->
/ При week=l и 1апе-2 указатель #1
\ устанавливается на tnumb=5.
v BOWLER
tnumb
week
2
lane
1
ч bname
указатель #2-->
Джин Адаме*
tnumb
-О
I tnumb=5, на который настроен указатель #1, наст-
• раивает указатель #2 по tnumb=5 для получения
. bname; единственная возможность - Джин Адаме.
\
\
\
указатель #3-->
SCORES
bname
\
\
л
Джин Адаме
week
2
gamel
120
да me 2
125
датеЗ
100
bname ■ Джин Адаме, получаемое по указателю
#2, плюс значение week = 2 устанавливают
указатель #3 на искомые результаты,
показанные игроком
Рис. 10.23. Пример использования указателей в моду-
модуле teamstd.prg
Глава 10 219
*(Имя процедуры: getavg.prg )
*(Автор Гленн А.Джексон )
*(Оклендский университет, Рочестер, Ml 48063)
*(Данная процедура предназначена для вычисления)
*( результативности, используемой при определении гандикапа)
*( для данного игрока на данную неделю сезона.)
*( Ввод номера недели осуществляется через глобальную)
переменную wk;)
имени и фамилии игрока - через глйбёльную переменную пате,)
ж[ а вывод значения результативности - через глобальную)
*( переменную avg. )
*( Переменные ввода-вывода определяются как целые в вызывающей
*( программе.)
*(Этот модуль вызывается только тогда, когда номер вводимой)
*( недели превышает 1.)
*()
*(Процедура вызывается из teamstd.prg. )
SET VAR sum INTEGER
SET VAR si INTEGER
SET VAR s2 INTEGER
SET VAR s3 INTEGER
SET VAR numgams INTEGER
*()
COMPUTE si AS SUM gamel FROM scores +
WHERE bname * .name AND week < .wk
COMPUTE s2 AS SUM game2 FROM scores +
WHERE bname ■ .name AND week < .wk
COMPUTE s3 AS SUM game3 FROM scores +
WHERE bname * .name AND week < .wk
SET VAR sum TO .si + .s2
SET VAR sum TO .sum + .s3
SET VAR numgams TO .wk - 1
SET VAR numgams TO .numgams x 3
SET VAR avg TO .sum / .numgams
RETURN
Рис. 10.24. Программный модуль getavg.prg
Отношение TSTATS должно быть создано до нача-
начала использования модуля teamstd.prg. Хотя это отно-
отношение и сохраняется в БД от выполнения к выпол-
выполнению, оно не принадлежит к числу регулярных от-
отношений, так как его содержимое считается некор-
некорректным перед началом каждого выполнения модуля
teamstd.prg. Это временное отношение в том смысле,
что данные создаются, выводятся, а затем разруша-
220 R:base 5000-реализация БД секретаря кегельной лиги
ются. Значения, хранимые в этом отношении, не
предполагается использовать при следующем выполне-
выполнении модуля. В некоторые СУБД включены команды
создания структуры временных отношений во время
выполнения программы. Эти временные отношения
существуют и могут быть использованы таким же об-
образом, как и любые другие отношения, в то время,
пока создавшая их программа находится в активном
состоянии. По завершении выполнения этой програм-
программы временные отношения исчезают.
Модуль teams td.prg вызывает одну процедуру:
getavg.prg. Этот модуль, показанный на рис. 10.24,
вычисляет значение average, необходимое для расчета
величины гандикапа для данной недели и данного иг-
игрока. Например, если teamstd.prg вычисляет число
побед и поражений для недели 4 сезона, то исполь-
используемый при этом гандикап получается на основании
значения average, вычисляемого для первых трех не-
недель сезона. Процедура getavg.prg вычисляет значение
average для каждого игрока.
10.9. Проблемы, возникающие при вводе в БД новых
данных
Меню альтернатив, приведенное на рис. 10.5, касает-
касается получения данных из БД. Меню не способно ока-
оказать помощь секретарю при вводе новых кортежей в
какое-либо отношение БД. Как было отмечено ранее
в этой главе, данные, содержащиеся в настоящий мо-
момент в БД, были внесены в нее с помощью стандар-
стандартных команд R:base 5000 LOAD и EDIT. Было бы
полезно разработать и предоставить в распоряжение
секретаря лиги меню, предназначенное для обеспече-
обеспечения ввода данных и служащего для него руководст-
руководством при вводе часто встречающихся данных, как на-
например, данных о всех индивидуальных результатах
игрока на текущую неделю сезона. Эта проблема
предлагается в качестве упражнения в конце главы.
Для обеспечения целостности данных в R:base
5000 существует встроенная команда RULES. Эта ко-
команда используется для определения условий, вынуж-
вынуждающих СУБД проверить соблюдение определенных
ограничений, установленных пользователем для дан-
Глава 10 221
ных, хранимых в БД. Если правило определено для
некоторого отношения, то система контролирует каж-
каждую операцию модификации данных и каждую опера-
операцию по добавлению данных в это отношение. Напри-
Например, если пользователю необходима уверенность в
том, что в отношении TEAM имеется не более одно-
одного кортежа с данным номером команды (номер tnumb
является первичным ключом), то с помощью команды
RULES может быть задано следующее правило, каса-
касающееся отношения TEAM:
"Дублированный ключ" tnumb IN team NEA tnumb IN team
"Дублированный ключ" представляет собой сообщение
об ошибке, которое будет выводиться всякий раз при
попытке нарушить указанное условие, и NEA означа-
означает not equal to any (не равен ничему). Задача 10 в
конце главы посвящена рассмотренной теме задания
условий.
10.10. Комментарии к гл. 10
До тех пор пока запрос касается только извлечения
информации из БД, его решение, вероятно, может
быть получено на уровне команд R:base 5000. Неко-
Некоторые из этих решений могут состоять из серий ко-
команд, составление которых требует довольно высокого
уровня понимания идей, лежащих в основе БД. Эти
решения не могут быть получены теми, кто не обла-
обладает соответствующими знаниями в данной области.
Если запрос подразумевает как извлечение данных,
так и манипулирование ими, то решение обычно тре-
требует использования языка программирования БД. Эти
решения могут быть весьма сложными и должны раз-
разрабатываться теми, кто знаком с идейной основой БД
и обладает достаточными навыками в программирова-
программировании.
10.11. Задачи к гл. 10
1. В той реализации меню в R:base 5000, которая
была представлена в настоящей главе, все выходные
данные пересылаются на терминальное устройство.
Дополните меню альтернативой, которая бы позволи-
222 R:base 5000-реализация БД секретаря кегельной лиги
ла секретарю выбирать устройство вывода при каж-
каждом запуске. Разумным представляется решение о
предоставлении возможности выбора одного из следу-
следующих вариантов вывода - только на терминальное
устройство, только на печатающее устройство, как на
терминальное, так и на печатающее устройства.
2. Расширьте меню, приведенное на рис. 10.5, с по-
помощью добавления новых программных модулей, от-
отвечающих некоторым из более сложных запросов,
приведенных в разд. 10.2.
3. Решите задачу 1 из гл. 9, используя R:base 5000.
4. Решите задачу 3 из гл. 9, используя R:base 5000.
5. Измените teamstd.prg таким образом, чтобы фор-
формат вывода итогового положения команд в большей
степени отвечал профессиональным стандартам. В те-
текущей реализации вывод положения команд выполня-
выполняется с использованием команды SELECT ALL
6. Измените bwlrst.prg так, чтобы обеспечивалось
включение в выходные данные ОБЩЕГО ЧИСЛА
НАБРАННЫХ ОЧКОВ С УЧЕТОМ ГАНДИКАПА.
7. Модуль teampns.prg выводит общее число "чистых"
очков для каждой команды. Измените его таким об-
образом, чтобы осуществлялся вывод также и ОБЩЕГО
ЧИСЛА НАБРАННЫХ ОЧКОВ С УЧЕТОМ ГАНДИ-
ГАНДИКАПА.
8. Основная часть алгоритма модуля wkschdl.prg реа-
реализована с помощью команды SET POINTER, за ко-
которой следует конструкция WHILE - THEN. Перепи-
Перепишите эту часть, используя команду JOIN, и опреде-
определите, есть ли заметные изменения в скорости выпол-
выполнения модуля. Какой из двух подходов удобнее?
9. Решите задачу 9 из гл. 9, используя R:base 5000.
10. Воспользуйтесь командой RULES для установле-
установления таких ограничений для каждого отношения, кото-
которыми для этих отношений обеспечивается уникаль-
уникальность первичных ключей.
11. Напишите несколько инициируемых с помощью
меню программных модулей, позволяющих секретарю
кегельной лиги, не обладающему глубокими знаниями
в области БД, добавлять в БД результаты встреч для
всех команд по любой неделе сезона. Этот модуль
должен предоставлять секретарю разумный набор при-
приглашений, а также шаблон для ввода корректных
данных. Проследите, чтобы модуль выполнял все не-
Глава 10 223
обходимые проверки вводимых данных, которые не
выполняются с помощью команды RULES из задачи 10.
12. Проанализируйте медленно выполняющиеся моду-
модули (например, teamstd.prg) и испробуйте различные
методы уменьшения времени их выполнения. (Для
группы студентов можно организовать полезный кон-
конкурс, цель которого состоит в создании программного
модуля с наибольшей скоростью выполнения.)
13. Решите задачу 5 из гл. 9, используя R:base
5000,
11. НЕКОТОРЫЕ ДОПОЛНИТЕЛЬНЫЕ ЗАМЕЧАНИЯ
Приступая к написанию этой книги, автор не ставил
перед собой задачу составления справочного руковод-
руководства, которое бы включало в себя все достойные изу-
изучения знания, касающиеся проектирования реляцион-
реляционных БД и их реализации. Поэтому значительный по
объему материал, являющийся частью всего комплек-
комплекса знаний, называемого реляционными БД, не обсуж-
обсуждался. В этой главе высказываются некоторые сообра-
соображения по поводу материала, изложенного в предыду-
предыдущих главах, а также указываются некоторые другие
области технологии БД из тех многих, которые не
вошли в основную часть книги.
11.1. Другие нормальные формы
Методы проектирования, основанные на понятии ФЗ,
рассматриваемые в гл. 3, 4 и 5, подробно описаны в
литературе. Они использовались в различных прило-
приложениях и доказали свою эффективность в качестве
средств проектирования. Вместе с тем, как и следует
ожидать, ни одно отдельное средство не обеспечивает
наилучшее решение всех проблем, с которыми может
столкнуться проектировщик. Неизбежно возникают си-
ситуации, в которых данные, предполагаемые к внесе-
внесению в БД, связаны таким образом, что для получе-
получения наилучшего результата необходимо использовать
специальные методы проектирования. Примером слу-
служат нормальные формы, накладывающие более силь-
сильные ограничения, чем НФБК, и развитые для устра-
устранения некоторых нежелательных характеристик, кото-
которые могут присутствовать даже в отношениях, нахо-
находящихся в НФБК. Две из этих форм - четвертая
нормальная форма DНФ) и DK/НФ - рассмотрены в
наиболее серьезных руководствах, посвященных про-
проектированию БД. 4НФ касается отношений, в кото-
которых существуют наборы повторяющихся данных, и
декомпозиция, основанная на использовании ФЗ, не
приводит к исключению избыточности. Декомпозиция
при переходе к 4НФ требует использования много-
многозначных зависимостей, которые здесь не рассматрива-
Глава 11 225
ются. DK/НФ (domain-key normal formI) можно рас-
рассматривать как предельную НФ, так как в отношени-
отношениях, находящихся в этой форме, невозможны аномалии
обновления. Однако пока не предложены никакие
формализованные правила, способные помочь проекти-
проектировщику преобразовать отношения в эту НФ.
Остались вне рассмотрения две НФ, накладываю-
накладывающие менее сильные ограничения, чем НФБК. Эти
формы, известные как вторая нормальная форма
BНФ) и третья нормальная форма (ЗНФ), важны с
точки зрения исторической перспективы. 2НФ была
разработана для исключения аномалий, возникающих
в отношениях, находящихся в 1НФ. ЗНФ была раз-
разработана для исключения аномалий, возникающих в
отношениях, находящихся в 2НФ, и т. д. Крайне ма-
малое число БД было спроектировано для получения
конечных отношений только в 2НФ или ЗНФ. Доста-
Достаточно сказать, что если отношение находится в
НФБК, то оно также находится как во 2НФ, так и
в ЗНФ.
Понятием, прямо связанным с разложением отно-
отношений при переходе от одной НФ к другой (более
высокого порядка), является понятие декомпозиции
без потерь. Оно было упомянуто в главе 3 и детали-
детализировано в Приложении В.
11.2. Преимущества ER-метода
При начальном ознакомлении с ER-методом в гл. 6
было отмечено, что этот метод обладает несколькими
преимуществами по сравнению с методами проектиро-
проектирования, основанными на понятии ФЗ:
1. Проектирование начинается с постепенно
углубляющегося изучения всей полноты проблемы
хранения данных. Такой подход дает проектировщику
гораздо более отчетливое представление о решаемой
проблеме, чем в том случае, когда проектирование
начинается с анализа атрибутов и ФЗ.
*) Эта нормальная форма иногда называется "пятой" нормальной
формой. Ее ввел в 1979 г. Фейгин (Fagin R.), показав, что воз-
возможно осуществить декомпозицию отношений так, что остаются
только ФЗ от атрибутов ключа и ограничения по размерам доме-
доменов для атрибутов. - Прим. ред.
226 Некоторые дополнительные замечания
2. Философия ER-проектирования может быть
эффективно использована в задачах с большим чис-
числом атрибутов, в которых методы проектирования,
основанные на ФЗ, становятся неуправляемыми.
Описание ER-метода, приведенное в книге, должно
дать читателю основательный фундамент для развития
своих аналитических возможностей, необходимых при
решении многих проблем проектирования БД. Проек-
Проектировщик должен помнить, что, даже когда проекти-
проектирование базируется на ER-философии, нельзя упу-
упускать из виду ФЗ; результирующие проектные отно-
отношения всегда должны пройти проверку на нормализацию.
11.3. Цена нормализации
При первом обсуждении целей проектирования БД в
гл. 2 было выдвинуто утверждение, что хорошим счи-
считается проектирование, при котором результатом де-
декомпозиции одного или более исходных отношений
является появление нескольких нормализованных от-
отношений. Однако было отмечено, что в результате
генерации новых отношений усложняется получение
ответов на запросы к БД по сравнению со случаем
БД, состоящей из меньшего числа отношений. Таким
образом возникает проблема: следует ли проектиров-
проектировщику сохранять БД в НФБК или же ограничивать
число отношений для упрощения пользования БД.
Однозначного решения этой проблемы нет.
Некая крупная корпорация разработала большую
БД, в которой все данные хранятся в одном отноше-
отношении, не находящемся даже в первой нормальной фор-
форме. Сотрудники, ответственные за сопровождение БД,
утверждают, что возникают затруднения из-за того,
что в основу проектирования БД не были положены
НФБК-спецификации, однако главными преследуемы-
преследуемыми целями являются скорость доступа и простота
форматов запросов. Аномалии могут возникнуть из-за
того, что БД не находится в НФБК, но соблюдение
осторожности служит достаточной от них защитой.
Гарантией служит то обстоятельство, что пользовате-
пользователям предоставляется лишь ограниченный набор опций
запросов и обновления; эти опции доступны пользова-
пользователям через специально спроектированное программ-
программное обеспечение.
Глава 11 227
Вышеприведенный пример, в котором БД состоит
из одного отношения, не находящегося в 1НФ, нети-
нетипичен. Большинство администраторов БД настаивают
на необходимости проектирования всех БД таким об-
образом, чтобы каждое отношение каждой БД находи-
находилось по крайней мере в НФБК. По их мнению, с
которым нельзя не считаться, большинство пользова-
пользователей не обладают в теории БД знаниями, достаточ-
достаточными для своевременного обнаружения всех подвод-
подводных камней, присутствующих в БД в случае отсутст-
отсутствия нормализации в НФБК. Эти проектировщики го-
готовы пойти на увеличение размеров запросов и ус-
усложнение операций обновления для гарантии целост-
целостности данных в БД.
На этапе завершения процесса проектирования вне
зависимости от используемого метода необходимо оце-
оценить предложенный проект как с практической, так и
с технической точек зрения. Два момента, на кото-
которые необходимо обратить внимание, иллюстрируются
следующими вопросами:
1. Будет ли предполагаемая реализация БД обес-
обеспечивать достаточно быстрое выполнение запросов?
Как велико то время, которое требуется СУБД для
ответа при использовании данной БД?
2. Могут ли быть получены ответы на запросы
"естественным" образом, без привлечения для состав-
составления запросов профессиональных программистов? Ес-
Если привлечение программистов необходимо, то на-
насколько это соответствует нуждам предприятия?
В случае отрицательного ответа на какой-либо из
этих вопросов необходим пересмотр проектного решения.
Существует несколько способов, следуя которым
проектировщик может попытаться увеличить скорость
ответа БД на запросы:
1. Индексация тех отношений, к которым регу-
регулярно применяется операция поиска, с тем же атри-
атрибутом, который служит ключом поиска.
2. Замена таких команд, как JOIN, выполнение
которых требует значительного времени, на более
простые, но и более быстрые конструкции.
228 Некоторые дополнительные замечания
3. Если решение запроса потребовало использова-
использования программы, написанной на языке высокого уров-
уровня, следует проверить, нет ли более простого, более
прямого алгоритма решения проблемы.
4. Ревизия исходной философии проектирования,
предпринимаемая с целью выявления ранее принятых
решений, последствия которых сказываются отрица-
отрицательно на конечном продукте. Хорошим примером в
этой связи может служить решение, принятое в зада-
задаче построения БД секретаря (гл. 5), основанное на
нежелании хранения каких-либо атрибутов, чьи зна-
значения могут быть вычислены на основании других
атрибутов в БД. Компенсировало ли улучшение цело-
целостности, достигнутое в результате принятия этого ре-
решения, увеличение времени выполнения?
11.4. Совместное использование БД
Представленные в гл. 9 программы были написаны
для СУБД, в среде которой только один пользователь
может иметь доступ к соответствующей БД в каждый
момент времени. Многие СУБД допускают возмож-
возможность открытия БД несколькими, или, возможно,
многими пользователями в одно и то же время. В
этих условиях каждый пользователь должен дать точ-
точную информацию СУБД о тех отношениях, которые
им будут использоваться, и способе использования
каждого из этих отношений. Кроме того, каждый
пользователь должен информировать СУБД об ограни-
ограничениях, которыми обуславливается применение этих
отношений другими пользователями БД. Например,
пользователь может потребовать, чтобы в течение вы-
выполняемого им процесса извлечения информации из
отношения R1 никакому другому пользователю не
было разрешено удаление кортежей, принадлежащих
отношению R1, их модификация или добавление в
это отношение новых кортежей. В системах, предо-
предоставляющих такую возможность, предусматриваются
специальные команды, используемые при организации
управления совместной обработкой. Одной из первых
реляционных СУБД, включающих в свой состав до-
довольно полный набор команд управления процессом
совместной обработки, является система MRSD
Глава 11 229
(Multics Relational Data StoreI), разработанная фир-
фирмой Honeywell Information Systems.
СУБД, обеспечивающие режим совместной обработ-
обработки, ориентированы на их использование в сочетании
с сетевыми структурами. В некоторых реализациях
БД размещаются не в каком-либо одном месте, а
распределяются между несколькими компьютерными
системами, связанными между собой сетью. Как
dBASE III, так и R:base 5000 оснащены сетевыми
возможностями. С деталями читатель может ознако-
ознакомиться в соответствующих справочных руководствах,
выпущенных фирмами-изготовителями.
11.5. Администрирование БД
В этой книге не делалось попыток рассмотреть вопро-
вопросы администрирования БД. Проблемы, связанные как
с применением паспортов и шифрованием данных,
что имеет своей целью обеспечение их секретности,
так и с созданием резервных копий БД, обеспечиваю-
обеспечивающих возможность восстановления информации, уте-
утерянной в результате проникновения в БД ошибок, не
рассматриваются в данной книге.
Универсальная техника, используемая администра-
администраторами БД с целью обеспечения секретности и защи-
защиты данных, основана на использовании локальных
представлений или подмоделей. При этом для конк-
конкретного пользователя доступной для использования
является только часть всей БД. БД в действительно-
действительности логически разделяется на части с целью ограни-
ограничения возможностей доступа для каждого отдельного
пользователя. Большинство из разработанных за по-
последнее время СУБД обладает этой возможностью.
J) Multics Relational Data Store Reference Manual, Order Number
AW53-04A, Honeywell Informations Systems, 1983.
ПРИЛОЖЕНИЕ А
Реляционная алгебра
Реляционная алгебра состоит из множества операто-
операторов высокого уровня, применение которых к отноше-
отношениям приводит к генерации новых отношений. Тремя
наиболее часто используемыми операторами являются
операторы ВЫБОРКА, ПРОЕКЦИЯ и СОЕДИНЕНИЕ.
Языки запросов всех СУБД включают в свой состав
команды, эквивалентные перечисленным выше. В при-
приложении будут определены эти три оператора, пока-
показаны их базовые операторные характеристики, приве-
приведены примеры их конкретных реализаций как в
dBASE III, так и в R:base 5000. Все примеры осно-
основаны на двух отношениях, показанных на рис. АЛ.
ABC
Name
Джил
Джон
Зиппи
Room
234
126
126
Rphone
3256
1267
5298
DEF
Phone
1267
3256
3623
4311
5298
Type
Dial
PshBtn
Pay
Dial
PshBtn
Рис. A.I. Примеры отношений ABC и DEF
В отношении ABC содержатся имена студентов
(Name), номера комнат, которые им отводятся
(Room), и номера телефонов (Rphone). Отношение
DEF содержит информацию о типах телефонов
(Туре), связанную с каждым телефонным номером
(Phone). Атрибуты Rphone и Phone получают значе-
значения из одного домена телефонных номеров студенче-
студенческого городка.
АЛ. Оператор реляционной алгебры ВЫБОРКА
Оператор ВЫБОРКА реляционной алгебры применяет-
применяется к единичному, уже существующему, отношению и
результатом этого применения является генерация но-
Приложение А 231
вого отношения. Новое отношение получается путем
ВЫБОРКИ только тех кортежей из исходного отно-
отношения, которые удовлетворяют заданному условию.
Общая форма оператора ВЫБОРКА имеет вид
ВЫБОРКА ИЗ Имя-Отношения
ГДЕ Условие
ПОЛУЧАЯ Имя-Результата
В этом определении Имя-Отношения представляет со-
собой имя исходного отношения, Условие есть условие,
которое должно учитываться при выборе кортежей, и
Имя—Результата - имя отношения, которое будет со-
содержать результаты выполнения операции.
Для иллюстрации использования общей формы по-
положим, что новое отношение необходимо получить из
отношения DEF(Phone,Type) путем выборки тех кор-
кортежей, в которых значением атрибута Туре является
Dial. Общая форма команды примет вид
ВЫБОРКА ИЗ DEF
ГДЕ Туре = Dial'
ПОЛУЧАЯ RESULT
В результате выполнения этой команды будет по-
получено отношение, приведенное на рис. А.2. На
практике отношение RESULT либо размещается в па-
памяти на диске в качестве временного отношения, ли-
либо просто выводится на терминал в зависимости от
используемой СУБД. Если результат выводится на
терминал, то заголовки, указывающие имена отноше-
отношения и атрибутов, могут и не выводиться вместе с
данными, также в зависимости от СУБД.
RESULT
Phone
1267
4311
Type
Dial
Dial
Рис. А.2. Отношение, полученное с помощью опера-
операции ВЫБОРКА
232 Реляционная алгебра
Чтобы проиллюстрировать то, как будет выглядеть
последний пример при использовании как dBASE III,
так и Rrbase 5000, предположим, что были созданы
отношения ABC и DEF и сохранены в БД с именем
APPNDXA.
В dBASE III допускаются три способа генерации
операции ВЫБОРКА: с помощью команд LIST,
DISPLAY или COPY. Команды LIST и DISPLAY по-
посылают результаты на терминал, в то время как
COPY помещает информацию в новом отношении на
диске. Примеры каждой из этих команд приведены
ниже вместе с результатами их реального выполне-
выполнения, показанными на рис. А.З.
. USE DEF
. LIST OFF FOR Type = 'Dial'
PHONE TYPE
1267 Dial
4311 Dial
! DISPLAY OFF FOR Type = 'Dial'
PHONE TYPE
1267 Dial
4311 Dial
! COPY TO RESULT FOR Type = 'Dial'
2 records copied
. USE RESULT
. LIST ALL
Record! PHONE TYPE
1 1267 Dial
2 4311 Dial
Рис. А.З. Способы генерации операции ВЫБОРКА в
dBASE III
Команда USE DEF переводит в активное состояние
отношение, которое будет использоваться. Компонента
OFF команд LIST и DISPLAY предотвращает СУБД
от вывода номеров выбранных кортежей (помимо соб-
собственно содержимого кортежей).
Приложение А 233
.USE DEF
.LIST OFF FOR Type = Dial'
.DISPLAY OFF FOR Type = Dial'
.COPY TO RESULT FOR Type = Dial'
Результаты выполнения команд LIST и DISPLAY по-
посылаются для вывода на экран, при этом выводятся
только кортежи, удовлетворяющие условию ГДЕ. При
необходимости нумерации выводимых кортежей следу-
следует в команде опустить слово OFF. Соответствующий
пример приведен на рис. А.З.
Команда COPY создает новый файл с именем
RESULT и сохраняет новое отношение в этом файле.
Просмотр содержимого RESULT пользователь может
осуществить путем ВЫБОРКИ всего отношения, по-
поместив после команды COPY следующие строки:
.USE RESULT
.LIST ALL
Этот случай представлен на рис. А.З.
Операция ВЫБОРКА в R:base 5000 реализована в
виде, очень близком к описанному выше. Выборка с
помощью команды SELECT всех кортежей в отноше-
отношении DEF со значением Dial атрибута type в соответ-
соответствии с синтаксисом R:base 5000, реализуется следу-
следующим образом:
R>OPEN APPNDXA
Database exists
R>SELECT ALL +
R>FROM DEF +
R>WHERE Type EQ Dial
Здесь R> представляет собой символ приглашения си-
системы управления R:base 5000; выражение Database
exists выводится самой R:base 5000 и указывает на
то, что БД открыта. Использованные в команде сим-
символы "+" указывают на продолжение команды в сле-
следующей строке. Процесс реального выполнения этого
примера показан на рис. А.4. Обратите внимание на
то, что слово Dial не заключается в кавычки в
R:base 5000, хотя и представляет собой символьную
строку.
234 Реляционная алгебра
R>OPEN APPNDXA
Database exists
R>SELECT ALL +
R>FROM DEF +
R>WHERE Type EQ Dial
Phone Type
1267 Dial
4311 Dial
R>
Рис. А.4. Генерация операции ВЫБОРКА в R:base
5000.
А.2. Оператор реляционной алгебры ПРОЕКЦИЯ
Оператор реляционной алгебры ПРОЕКЦИЯ применя-
применяется к одному существующему отношению для полу-
получения нового отношения. Новое отношение получается
путем выбора (ПРОЕЦИРОВАНИЯ) определенных
столбцов из текущего отношения. Если результат вы-
выполнения операции ПРОЕКЦИЯ содержит повторяю-
повторяющиеся кортежи, то в новом отношении сохраняется
только один кортеж из повторяющейся группы. (В
большинстве микрокомпьютерных СУБД повторяющие-
повторяющиеся кортежи автоматически не удаляются, это обязан
делать пользователь. Следует помнить, что корректное
отношение не может содержать повторяющихся корте-
кортежей.)
Общая форма оператора ПРОЕКЦИЯ имеет вид
ПРОЕКЦИЯ al,a2,...an
ИЗ Имя—Отношения
ПОЛУЧАЯ Имя-Результата
В данном определении al,a2,..,an - это список назва-
названий атрибутов (столбцов), выбираемых из отношения
с именем Имя-Отношения. Результат операции будет
записан в отношение с именем Имя—Результата. Для
иллюстрации использования общей формы рассмотрим
пример, в котором необходимо выбрать с помощью
оператора ПРОЕКЦИЯ столбцы Name и Room из от-
отношения ABC. Достигается это следующим образом:
ПРОЕКЦИЯ Name,Room
Приложение А
235
ИЗ ABC
ПОЛУЧАЯ RESULT
Получаемое в результате отношение показано на
рис. А.5.
RESULT
Name
Джил
Джон
Зиппи
Room
234
126
126
Рис. А.5. Результат применения операции ПРОЕК-
ПРОЕКЦИЯ к отношению ABC
С целью показать способ удаления дублированных
кортежей из отношения, полученного после выполне-
выполнение оператора ПРОЕКЦИЯ, допустим, что из отно-
отношения DEF(Phone,Type) выбирается столбец Туре.
Синтаксически соответствующая процедура выглядит
так:
ПРОЕКЦИЯ Туре
ИЗ DEF
ПОЛУЧАЯ RESULT
RESULT
Рис. А.6. Проекция с удалением дублированных кор-
кортежей
236 Реляционная алгебра
. USE ABC
.LIST Name, Room
Record! Name Room
1 Джиа 234
2 Джон 126
3 Зиппи 126
! DISPLAY ALL Name,Room
Record! Name Room
1 Джиа 234
2 Джон 126
3 Зиппи 126
! COPY TO RESULT FIELDS Name,Room
RESULT.dbf already exists, overwrite 1t? (Y/N) Yes
3 records copied
! USE RESULT
. LIST ALL
Record! Name Room
1 Джиа 234
2 Джон 126
3 Зиппи 126
Рис. А.7. Генерация операции ПРОЕКЦИЯ в dBASEIII
В результате выполнения операции будет получено
отношение, показанное на рис. А.6, из которого уда-
удалены дублированные кортежи, содержащие Dial и
PshBtn. (Такое отношение, как RESULT, в котором
имеется только один столбец, называется унарным.
Хотя унарные отношения можно получить с помощью
операции ПРОЕКЦИЯ, они никогда.не сохраняются в
БД, так как содержат минимум информации.)
Операция ПРОЕКЦИЯ в dBASE III реализуется с
помощью комбинаций тех же команд, которые ис-
использовались при генерации команды ВЫБОР. Суще-
Существуют три возможности выполнения операции ПРО-
ПРОЕКЦИЯ. Они будут проиллюстрированы на примере
проецирования столбцов Name и Room отношения
ABC:
.USE ABC
.LIST Name,Room
.DISPLAY ALL Name,Room
.COPY TO RESULT FIELDS Name,Room
Приложение А 237
Примеры использования каждой из этих команд в
случае реальной БД приведены на рис. А.7. Обратите
внимание, что команды LIST и DISPLAY посылают
результаты на терминал. (Их можно передать и на
печатающее устройство.) Команда COPY осуществляет
пересылку результатов в отношение на диск. Номера
записей в выходных данных могут быть исключены с
помощью включения компоненты OFF в команды
LIST и DISPLAY.
Последний пример на рис. А.7 представляет собой
проекцию атрибута Туре из отношения DEF и иллю-
иллюстрирует тот факт, что в dBASE III дублированные
кортежи из отношений автоматически не удаляются.
Оператор ПРОЕКЦИЯ в СУБД Rrbase 5000 может
быть реализован и в виде варианта команды ВЫБОР-
ВЫБОРКА. Для выполнения рассмотренных выше двух опе-
операций проекции над отношениями DEF и ABC можно
воспользоваться следующими командами:
R>OPEN APPNDXA
R>SELECT Name Room +
R>FROM ABC
и
R>SELECT Type +
R>FROM DEF
R>SELECT Name Room +
R>FROH ABC
Name Room
Дхиа 234
Джон 126
Зиппи 126
R>
R>SELECT Type +
R>FROM DEF
Type
Dial
PshBtn
Pay
Dial
PshBtn
R>
Рис. А.8. Операция ПРОЕКЦИЯ в R:base 5000
238 Реляционная алгебра
Результаты выполнения этих команд для случая
реальной БД приведены на рис. А.8. (Обратите вни-
внимание, что здесь также присутствуют дублированные
кортежи.) Если результаты применения проекции не-
необходимо сохранить в БД, то следует использовать
существующую в R:base 5000 команду PROJECT.
А.З. Оператор реляционной алгебры СОЕДИНЕНИЕ
Оператор СОЕДИНЕНИЕ предназначен для создания
одного нового отношения из двух уже существующих
отношений. Новое отношение получается путем кон-
конкатенации (соединения) кортежей первого отношения
с кортежами второго отношения. Только те кортежи
подвергаются конкатенации, в которых значение спе-
специфицированного атрибута в первом отношении сов-
совпадает со значением специфицированного атрибута
второго отношения (значения оба атрибута должны
получать из одного домена.) Если первое отношение,
являющееся объектом операции СОЕДИНЕНИЕ, име-
имеет N столбцов, а второе - М столбцов, то получае-
получаемое в результате отношение будет иметь М + N
столбцов. В получаемом отношении в двух столбцах
всегда будут содержаться одинаковые значения. Если
один из этих столбцов удалить, то принято называть
результат ЕСТЕСТВЕННЫМ СОЕДИНЕНИЕМ.
Общая форма оператора СОЕДИНЕНИЕ имеет вид
СОЕДИНЕНИЕ Отношение-Л И Отношение-2
ПО Атрибут-1 И Атрибут-2
ПОЛУЧАЯ Имя-Результата
Здесь Отношение—1 и Отношение—2 идентифицируют
два отношения, над которыми осуществляется опера-
операция СОЕДИНЕНИЕ. Атрибут-1 (входит в Отноше-
Отношение—1) и Атрибут—2 (входит в Отношение—2) иденти-
идентифицируют атрибуты, используемые при определении
кортежей, включаемых в конечное отношение. (Эти
два атрибута должны получать значения из одного
домена.) Имя-Результата является именем отношения,
в котором будут размещены результаты выполнения
операции.
Приложение А
239
В качестве примера рассмотрим случай соединения
отношений ABC и DEF (общим является домен теле-
телефонных номеров студенческого городка)
СОЕДИНЕНИЕ ABC И DEF
ПО Rphone И Phone
ПОЛУЧАЯ RESULT
Результатом выполнения данной операции будет отно-
отношение, приведенное на рис. А.9. Обратите внимание,
что значения Rphone и Phone идентичны. После иск-
исключения одного из этих столбцов (с помощью опера-
операции СОЕДИНЕНИЕ) будет получено ЕСТЕСТВЕН-
ЕСТЕСТВЕННОЕ СОЕДИНЕНИЕ.
RESULT
Name
Джиа
Джон
Зиппи
Room
234
126
126
Rphone
3256
1267
5298
Phone
3256
1267
5298
Type
PshBtn
Dial
PshBtn
Рис. А.9. Отношение, полученное с помощью опера-
операции СОЕДИНЕНИЕ
. SELECT 2
. USE DEF
. SELECT 1
. USE ABC
. JOIN WITH DEF TO RESULT FOR Rphone
3 records joined
. USE RESULT
. LIST OFF
NAME ROOM RPHONE PHONE TYPE
Джиа 234 3256 3256 PshBtn
Джон 126 1267 1267 Dial
Зиппи 126 5298 5298 PshBtn
DEF->Phone
Рис. АЛО.
dBASE III
Генерация операции СОЕДИНЕНИЕ в
240 Реляционная алгебра
R>OPEN APPNDXA
Database exists
R>JOIN ABC USING Rphone +
R>WITH DEF USING Phone +
R>FORMING RESULT
Successful join operation
R>SELECT ALL +
R>FROM RESULT
Name Room Rphone
Джил 234 3256
Джон 126 1267
Зиппи 126 5298
3 rows
Phone
3256
1267
5298
generated
Type
PshBtn
Dial
PshBtn
Рис. A. It. Генерация операции СОЕДИНЕНИЕ в
Rrbase 5000
При выполнении соединения как в dBASE III, так
и в Rrbase 5000 используется команда JOIN языка
запросов. Точный синтаксис при этом различный. В
dBASE III последний пример реализуется следующим
образом:
.SELECT 2
.USE DEF
.SELECT 1
USE ABC
'.JOIN WITH DEF TO RESULT FOR Rphone=DEF->Phone
Результат выполнения приведенной последовательности
команд в случае реальной БД приведен на рис. А. 10.
Та же самая операция для случая R:base 5000
выглядит следующим образом:
R>OPEN APPNDXA
Database exists
R>JOIN ABC USING Rphone +
R>WITH DEF USING Phone +
R>FORMING RESULT
Successful join operation
СУБД R:base 5000 выводит сообщение "Successful join
operation" (успешное выполнение операции соедине-
соединения) после того, как получаемое отношение было по-
помещено в дисковую память. Для того чтобы просмот-
Приложение А 241
реть результаты, пользователю необходимо воспользо-
воспользоваться командой
R>SELECT ALL FROM RESULT
Приведенная последовательность команд иллюстри-
иллюстрируется рис. А.11.
А.4. Комбинированные команды
Как dBASE III, так и R:base 5000 обеспечивают вы-
выполнение структурных команд запросов, позволяющих
сочетать два типа операций в одной команде. Напри-
Например, в случае Rrbase 5000 для выполнения операто-
операторов ВЫБОРКА и ПРОЕКЦИЯ в одной команде, по-
последняя примет вид:
R>OPEN APPNDXA
R>SELECT Name,Rphone +
R>FROM ABC +
R>WHERE Name EQ Джон
В этой команде проецируемые столбцы специфици-
специфицируются SELECT-частью команды, а условия выбора
определяются WHERE-частью команды. Читателю сле-
следует обратиться к имеющимся руководствам по
СУБД, поставляемым фирмами-изготовителями, для
ознакомления с другими примерами.
ПРИЛОЖЕНИЕ В
Декомпозиция без потерь
Алгоритм проектирования с использованием декомпо-
декомпозиции, обсуждавшийся в гл. 3, выполняет разложение
одного отношения, например R(X,Y,Z), на два новых
отношения R1(X,Y) и R2(Y,Z). Один вопрос, на кото-
который необходимо ответить в связи с этой процедурой,
заключается в следующем: "Приведет ли выполнение
запроса в случае отношений R1(X,Y) и R2(Y,Z) к
тому же результату, что и выполнение запроса в
случае исходного отношения?". Если нет, тогда алго-
алгоритм проектирования приведет к получению набора
отношений, порождающих несогласующиеся данные.
Отношения, полученные с помощью декомпозиции,
всегда будут приводить к получению согласующихся
данных в том случае, когда декомпозиция была про-
проведена способом, при котором естественное соедине-
соединение отношений R1(X,Y) и R2(Y,Z) дает в итоге в
точности исходное отношение R(X,Y,Z). Декомпози-
Декомпозиция, характеризующаяся этим качеством, называется
"декомпозицией без потерь при естественном соедине-
соединении". Если естественное соединение R1 и R2 приво-
приводит к появлению большего, чем в отношении R, чис-
числа кортежей, то декомпозиция называется декомпози-
декомпозицией с потерями. Отсутствие потерь при декомпози-
декомпозиции отношения R(X,Y,Z) на R1(X,Y) и R2(Y,Z) га-
гарантируется при условии, если от общего атрибута
двух получаемых отношений - в данном случае атри-
атрибута Y - зависит хотя бы один атрибут из двух ос-
оставшихся. В нашем случае, если Y -> X или Y ->
Z, то декомпозиция осуществляется без потерь.
На рис/ В.1 показан пример декомпозиции с поте-
потерями. В этом примере ни Y -> X, ни Y -> Z не
являются корректными ФЗ и естественное соединение
R1 и R2 порождает два новых кортежа. На рис. В.2
приведен пример декомпозиции без потерь. В этом
примере предполагается, что Y -> Z является кор-
корректной ФЗ и значения экземпляра R(X,Y,Z) отража-
отражают этот факт. Естественное соединение R1 и R2 в
Приложение В
243
этом случае дает в результате в точности исходное
отношение.
Ни X, ни Y не зависят
функционально от Z
R(X
X
1
3
5
Y,Z)
Y
2
2
4
Z
3
6
2
R1(X,
X
1
3
5
t
Y)
Y
2
2
4
Декомпозиция
R2(Y,
Y
2
2
4
Z)
Z
3
6
2
СОЕДИНЕНИЕ Rl и R2
R(X,Y,Z)
X
1
1
3
3
5
Y
2
2
2
2
4
Z
3
6
3
6
2
<
<
Новые кортежи
Рис. B.I. Пример декомпозиции с потерями
Для иллюстрации тех проблем, причиной появле-
появления которых может послужить декомпозиция с поте-
потерями, рассмотрим запрос: "Какое значение атрибута Z
связано со значением 1 атрибута X?". Если восполь-
воспользоваться синтаксисом dBase III, то ответ на запрос
можно получить с помощью следующих предложений:
244
декомпозиция оез потерь
RKX,
X
1
3
5
R(X,
X
«- ro m
Аек(
Y)
Y
2
2
4
Y.Z)
Y
2
2
4
>мпоз*
z
3
3
2
Y
ЩИЯ
R2CY,
Y
2
4
-> Z
Z)
Z
3
2
СОЕДИНЕНИЕ Rl и R2
RCX,
X
1
3
5
Y,Z)
Y
2
2
4
Z
3
3
2
Те же кортежи, что и в
отношении R(X,Y,Z)
Рис. В.2. Пример декомпозиции без потерь
.USE R
.LIST OFF Z FOR X
1
Для экземпляров отношения R, приведенных на рис. В. 1 и
В.2, будет получен ответ Z * 3. Если ответ на запрос
должен быть получен исходя из отношений R1 и R2,
то запрос следует сформировать следующим образом:
Приложение В 245
.SELECT 2
.USE R2
.SELECT 1
.USE Rl
JOIN WITH R2 TO RESULT;
FOR X - 1 .AND. Y - R2->Y FIELDS Z
.USE RESULT
.LIST OFF
Если воспользоваться отношениями Rl и R2 из рис. B.I
(декомпозиция с потерями), то выполнение запроса
даст два значения Z C и 6). Если воспользоваться
отношениями R1 и R2 из рис. В.2 (декомпозиция без
потерь), то в результате выполнения запроса будет
получено только правильное значение (Z * 3). Значе-
Значение Z - 6 из первого случая не согласуется с исход-
исходными данными, что является прямым результатом
проведения декомпозиции с потерями. Декомпозиция
без потерь дает правильный результат.
Концепция, представленная в этом приложении,
крайне простая, но в то же время очень важная.
Проектировщик БД должен помнить, что если отно-
отношения в БД были получены с помощью декомпози-
декомпозиции с потерями, то выполнение некоторых запросов
приведет к появлению побочных данных. Наоборот,
если отношения в БД были получены с помощью де-
декомпозиции без потерь, выполнение запросов будет
приводить к получению тех значений, которые были
бы получены из исходного отношения (отношений).
Базовый алгоритм декомпозиции, приведенный в гл. 3,
является алгоритмом декомпозиции без потерь.
В вышеприведенном обсуждении декомпозиции без
потерь предполагалось, что атрибуты X, Y и Z явля-
являются простыми. В общем случае X, Y и Z могут
быть как простыми, так и составными атрибутами.
ПРИЛОЖЕНИЕ С
ПЕРЕЧЕНЬ ФАЙЛОВ, ИСПОЛЬЗУЕМЫХ В
УЧЕБНЫХ ПРИМЕРАХ БД
На рис. С.1 приведен перечень файлов, используемых
в реализации БД секретаря кегельной лиги для слу-
случая dBASE III (гл. 9).
На рис. С.2 приведен перечень файлов, используе-
используемых в реализации БД секретаря кегельной лиги для
случая R:base 5000 (гл. 10).
Volume in
Directory
SDBMAIN
SCHED
WKSCHDL
TEAM
DELAY
SCORES
BWLRST
TEAMPNS
BOWLER
EOSRPT
HIGHSER
HIGHGAM
HIGHAVG
FILEOUT
TEAMSTD
"LSTATS
NUHB
FINDWK
HNDKPJW
drive В has
of B:\
PRG
DBF
PRG
DBF
PRG
DBF
PRG
PRG
DBF
PRG
DBF
DBF
DBF
PRG
PRG
DBF
NDX
PRG
PRG
no label
1602
231
1676
323
418
2691
2871
1263
1347
2432
99
115
99
531
4736
253
1024
804
1023
19 File(s) 328704 bytes
11-03-86
5-09-86
6-08-86
5-10-86
6-01-86
5-20-86
6-10-86
6-08-86
5-20-86
11-11-86
11-03-86
11-03-86
11-03-86
5-19-86
11-11-86
11-03-86
5-21-86
5-22-86
5-28-86
free
l:17p
l:31p
8:57p
4:27p
10:01p
4:44p
2:37p
8:41p
4:05p
6:20p
l:43p
l:43p
l:44p
7:51p
6:39p
2:00p
9:25a
2:54p
l:23p
Рис. C.I. Перечень файлов, используемых в реализа-
реализации БД, приведенной в гл. 9
Приложение С 247
Volume in
Directory
SDB1
SDB2
SDB3
SECDB
SECDB
EOSRPT
BWLRST
BWLRST
SECDB
EOSRPT
TEAMSTD
GETAVG
TEAMSTD
13
drive В has i
of B:\
RBS
RBS
RBS
API
APX
PRG
СОН
CMD
APP
СОН
СОН
PRG
PRG
io label
9600
10752
1024
12064
13568
3840
4793
3840
5888
5465
9653
1154
6528
File(s) 268288 bytes
2-10-87
2-10-87
2-10-87
6-19-86
9-28-86
9-28-86
9-28-86
9-24-86
9-28-86
9-28-86
9-28-86
9-10-86
9-12-86
free
10:20p
10:20p
10:20p
2:24p
12:16p
11:13a
11:26a
3:02p
12:14p
11:28a
11:32a
6:56p
l:52p
Рис. С.2. Перечень файлов, используемых в реализа-
реализации БД, приведенной в гл< 10
ЛИТЕРАТУРА
1. Chen, P.P.S.uThe Entity-Relationship Model -
Toward a Unified View of Data,"ACM Transactions on
Database Systems, vol. 1, no. 1 (March, 1979), pp.9-36.
2. Date, C.J. An Introduction to Database Systems,
vol.1, Dth ed.).Reading, MA and Menlo Park, CA:
Addison-Wesley Publishing Co., Inc., 1986.
3. Date, C.J. An Introduction to Database Systems,
vol. 2. Reading, MA and Menlo Park, CA: Addison-
Wesley Publishing Co., 1983.
4. Date, C.J. Database: Primer. Reading, MA and
Menlo Park, CA: Addison-Wesley Publishing Co., 1983.
5. Hawryszkiewycz, I.T. Database Analysis and Design.
Chicago: Science Research Associates, Inc., 1984.
6. Howe, D.R. Data Analysis for Data Base Design.
Baltimore, MD: Edward Arnold/University Park Press,
1983.
7. Kroenke, D.M., and D.E. Nilson. Database
Processing for Microcomputers. Chicago: Science
Research Associates, 1986.
8. Ullman, J.D. Principles of Database Systems Bnd
ed.). Rockville, MD: Computer Science Press, 1982.
9. Vasta, J.A. Understanding Data Base Management
Systems. Belmont, CA: Wadsworth Publishing Co., 1985.
СОДЕРЖАНИЕ
ПРЕДИСЛОВИЕ РЕДАКТОРА ПЕРЕВОДА 5
ПРЕДИСЛОВИЕ 7
1. Базы данных, отношения и реляционные базы данных 10
1.1. Базовые концепции 10
1.2. Определение отношения 12
1.3. Определение реляционной БД 14
2. Необходимость проектирования баз данных 20
2.1. Цели проектирования 20
2.2. Универсальное отношение 24
2.3. Проблемы, вызываемые использованием единственного
отношения 27
2.4. Задачи к гл. 2 31
3. Функциональные зависимости 32
3.1. Первая нормальная форма AНФ) 32
3.2. Концепция функциональных зависимостей 32
3.3. Нормальная форма Бойса-Кодда (НФБК) 35
3.4. Общий подход к декомпозиции 37
3.5. Обзор исходных аномалий 41
3.6. Другая декомпозиция отношения КОНСУЛЬТАНТ 45
3.7. Некоторые комментарии к декомпозиционному алгоритму
проектирования 46
3.8. Задачи к гл. 3 50
4. Некоторые модификации алгоритма проектирования 52
4.1. Избыточные функциональные зависимости 52
4.2. Транзитивные зависимости 52
4.3. Добавление атрибутов в ФЗ 54
4.4. Правила вывода 55
4.5. Минимальное покрытие 57
4.6. Пересмотренный алгоритм проектирования 60
4.7. Проверка отношений на завершающей фазе их
проектирования 61
4.8. Задачи к гл. 4 62
250 Содержание
5. Учебный пример проектирования БД 65
5.1. Постановка задачи 65
5.2. Определение атрибутов универсального отношения 66
5.3. Диаграммы функциональных зависимостей 69
5.4. Получение путем редукции набора НФБК-отношений 72
5.5. Оценка спроектированных НФБК-отношений , 76
5.6. Задачи к гл. 5 78
6. Другой подход к проектированию 79
6.1. Сущности и связи 79
6.2. Степень связи 82
6.3. Некоторые замечания по поводу графического
представления 92
6.4. Задачи к гл. 6 93
7. Получение отношений из диаграмм ER-типа 94
7.1. Предварительные отношения для бинарных связей
степени 1:1 95
7.2. Первый пример ER-проектирования 100
7.3. Предварительные отношения для бинарных связей
степени 1: N 103
7.4. Предварительные отношения для бинарных связей
степени M:N 107
7.5. Второй пример ER-проектирования 109
7.6. Пересмотр БД секретаря кегельной лиги 113
7.7. Некоторые замечания, касающиеся числа отношений 115
7.8. Задачи к гл. 7 115
8. Дополнительные конструкции, используемые в ER-методе 117
8.1. Необходимость связей более высокого порядка 117
8.2. Предварительные отношения для трехсторонних связей.121
8.3. Использование ролей 122
8.4. Более крупный пример ER-проектирования 127
8.5. Задачи к гл. 8 132
9. dBASE Ill-реализация БД секретаря кегельной лиги 134
9.1. Анализ отношений БД с помощью тестовых данных при
использовании dBase III 134
Содержание 251
9.2. Ответы на запросы секретаря лиги в dBase III 139
9.3. Основное меню заранее подготовленных запросов 145
9.4. Программный модуль BWLRST.PRG 149
9.5. Программный модуль TEAMPNS.PRG 153
9.6. Программный модуль WKSCHDL.PRG 157
9.7. Программный модуль EOSRPT.PRG 160
9.8. Программный модуль TEAMSTD.PRG 165
9.9. Структура временных отношений 171
9.10. Необходимость входного меню 173
9.11. Задачи к гл. 9 175
10. R:base 5000-реализация БД секретаря кегельной лиги 179
10.1. Анализ отношений БД с помощью тестовых данных при
использовании R:base 5000 179
10.2. Ответы на запросы секретаря в R:base 5000 184
10.3. Основное меню заранее подготовленных запросов 192
10.4. Модуль BWLRST.PRG в R:base 5000 195
10.5. Программный модуль TEAMPNS.PRG в R:base 5000 199
10.6. Программный модуль WKSCHDL.PRG в R:base 5000 202
10.7. Программный модуль EOSRPT.PRG в R:base 5000 205
10.8. Программный модуль TEAMSTD.PRG в R:base 5000 209
10.9. Проблемы, возникающие при вводе в БД новых
данных 220
10.10. Комментарии к гл. 10 221
10.11. Задачи к гл. 10 221
11. Некоторые дополнительные замечания 224
11.1. Другие нормальные формы 224
11.2. Преимущества ER-метода 225
11.3. Цена нормализации 226
11.4. Совместное использование БД 228
11.5. Администрирование БД 229
ПРИЛОЖЕНИЕ А
Реляционная алгебра 230
А. 1. Оператор реляционной алгебры ВЫБОРКА 230
А.2. Оператор реляционной алгебры ПРОЕКЦИЯ 234
А.З. Оператор реляционной алгебры СОЕДИНЕНИЕ 238
А.4. Комбинированные команды 241
252 Содержание
ПРИЛОЖЕНИЕ В
Декомпозиция без потерь 242
ПРИЛОЖЕНИЕ С
Перечень файлов, используемых в учебных примерах БД...,246
ЛИТЕРАТУРА 248
В 1991 Г. ИЗДАТЕЛЬСТВО "МИР"
ВЫПУСКАЕТ КНИГУ
Куправа Т.А. "Создание и программирование баз данных средства-
средствами СУБД dBase III Plus, FoxBase Plus, Clipper", 10 л.,8 p.,75 000
экз.
В книге приведены необходимые на практике сведения по авто-
автоматизации и проектированию баз данных. Рассмотрены основные
принципы работы и программирование в среде наиболее популярных
СУБД типа dBase III Plus (Микро-РС-2, Ребус, Карат).
Книга предназначена для широкого круга пользователей персо-
персональных компьютеров IBM PC, PC XT/AT или совместимых, сту-
студентов и программистов, желающих самостоятельно создавать базы
данных, автоматизированные информационные системы.