Книга
← К списку книгЗагрузка разделов…
активнаАктивные записи участвуют в каталоге и синках. Неактивная книга скрыта, но не удалена из базы.
Книга
ПРЕДИСЛОВИЕ РЕДАКТОРА ПЕРЕВОДА
Развитие технологий построения баз данных насчитывает уже четвертьвековую историю. В 1965 г. появились первые результаты в области управления базами данных (работы Чарлза Бахмана), и данной проблемой начал заниматься КОДАСИЛ1^. С той поры технологии баз данных прошли большой путь. Семидесятые годы ознаменовались разработкой трех основных моделей данных - иерархической, сетевой и реляционной, каждая из которых нашла своих активных сторонников и последователей. По мере развития вычислительной техники на базе этих трех подходов было построено большое число СУБД. В восьмидесятые годы с развитием микропроцессорной техники и широким распространением персональных компьютеров возникла новая волна интереса к базам данных, их проектированию и реализации.
В настоящее время, видимо, необходимо признать, что на рынке СУБД для персональных компьютеров победил реляционный подход, отличающийся простотой базисных понятий и строгостью математических основ. Вместе с тем, внедрение компьютеров в повседневную жизнь заставляет большое число пользователей заниматься проблемами организации баз данных. Готовая СУБД является лишь инструментом реализации спроектированной базы данных и работы с ней, в то время как принципиальные трудности начинаются с момента принятия решения о необходимости создания базы данных. Эта книга как раз и задумана автором как практическое руководство к проектированию баз данных на персональном компьютере на основе реляционной модели.
Задача, которую ставил перед собой автор, с успехом решена. В отличие от ранее изданных руководств книга охватывает все этапы проектирования баз данных - от построения концептуальной модели до реализации на основе широко известных СУБД dBASE III и R:BASE 5000. К несомненным достоинствам книги необходимо отнести сочетание строгого математического подхода к предлагаемым алгоритмам (с определением всех употребляемых терминов и понятий) с живым обсуждением и примерами конкретных процедур реализации. В ней удачно сопоставлены два алгоритма построения отношений в нормальной форме Бойса-Кодда - на основе понятия функциональной зависимости (удобного для небольших баз данных с малым количеством атрибутов) и на основе широко распространенной модели “сущность-связь". В отличие от большого числа известных аналитических методов предлагаемые автором правила сводят число необходимых отношений в базе к минимуму. Хорошо формализована процедура проверки полученного проекта.
Ориентация на конкретные СУБД позволила автору избежать обсуждения методов физической реализации хранения и поиска данных, что сделало книгу компактной по объему. Каждая глава книги снабжена продуманными задачами, существенно помогающими
^ Американская организация, занимающаяся разработкой стандартных средств для обработки экономических задач.
усвоению материала. Можно сказать, что в книге реализован принцип “примеры при изучении наук важнее правил“, поскольку значительный объем книги посвящен последовательному проектированию базы данных секретаря кегельной лиги. На этом примере продемонстрированы все алгоритмы и показаны все трудности проектирования. Пример доведен до физической реализации в рассматриваемых СУБД. Тексты распечаток полностью соответствуют синтаксису СУБД и, будучи реализованными на персональном компьютере, работают (в чем вслед за нами может убедиться любой желающий).
Все вышеизложенное позволяет считать книгу несомненным успехом автора. Она будет полезна всем пользователям персональных компьютеров и удачно дополнит фирменные руководства по конкретным СУБД.
Посвящаю моей женеМЭЙи нашим двум сыновьямАЛАНУ и МАРКУ
ПРЕДИСЛОВИЕ
Данная книга представляет собой введение в проектирование реляционных баз данных (БД). При этом в намерение автора не входило предложить читателю начальное руководство по использованию конкретной системы управления базами данных (СУБД) или же общее описание какого-либо специального языка запросов. Тематика книги дает представление о таких пакетах, как dBase II/III и R:base 5000, но главное - это изучение проблемы проектирования БД, использование которых предполагается со стандартной СУБД (например, dBase III)1). Цель книги - описание процесса проектирования баз данных на доступном для среднего пользователя микрокомпьютере.
Начинающему реляционная БД представляется как набор таблиц или файлов (в действительности отношений, как мы увидим позже). Если эти таблицы спроектированы некорректно, данные в БД могут быть ошибочно изменены или удалены при использовании СУБД. Здесь могут возникнуть следующие типичные проблемы.
Пользователю требуется удалить информацию о партиях товара от некоторого поставщика. Команда на удаление этой информации завершается также удалением имени и адреса поставщика (помимо информации о поставке).
Пользователь пытается исправить написание имени клиента. Однако он забывает, что имя хранится в трех различных местах. В результате только од-
^ 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 III-реализацию программного модуля, предназначенного для определения положения команд (гл. 9).
БАЗЫ ДАННЫХ, ОТНОШЕНИЯ И РЕЛЯЦИОННЫЕ БАЗЫ ДАННЫХ
Базовые концепции
Базу данных можно определить как унифицированную совокупность данных, совместно используемую всем персоналом предприятия, банка или учебного заведения. Задача БД состоит в хранении всех представляющих для некоторого предприятия интерес данных в одном месте, причем таким способом, который заведомо исключает их избыточность. Хранение множественных копий данных в различных местах предприятия чревато возникновением рассогласований между предположительно идентичными наборами данных. В хорошо спроектированной БД избыточность данных исключается, и вероятность сохранения противоречивых данных минимизируется.
В больших компьютерных системах к данным, хранящимся в БД, доступ может осуществляться одновременно сотней и более пользователей. БД в таких случаях может иметь сотни полей данных с миллионами единиц информации. Такие системы могут содержать буквально все данные, требующиеся для управления предприятием. БД на микрокомпьютерных системах имеют гораздо меньший масштаб. Здесь к конкретной БД в некоторый момент времени обычно осуществляет доступ один пользователь и каждая БД содержит только некоторое подмножество данных, требующихся предприятию. Одна БД разрабатывается^ скажем, для хранения финансовой информации, другая - данных о персонале. Будет ли разрабатываемая БД размещаться на большой ЭВМ или на микрокомпьютере - функции СУБД в обоих случаях одинаковы. СУБД представляет собой программно-аппаратный пакет, обеспечивающий пользователям простой доступ к БД. Программная часть СУБД, которую некоторые изготовители называют менеджером БД, выступает в качестве интерфейса между пользователем и БД (рис. 1.1). Менеджер БД обеспечивает программные средства, необходимые для создания, загрузки, запроса и обновления данных. Менеджер также контролирует все действия, связанные с управлением вводом-
выводом и памятью БД, а на больших ЭВМ на него возлагается и решение проблем безопасности и совместного использования данных. Короче говоря, хорошо спроектированная СУБД обеспечивает программное обеспечение, упрощающее для пользователя общение с БД.
Рис. 1.1. Основные компоненты архитектуры СУБД
Другое сходство между большими и малыми СУБД заключается в том, что в обоих случаях сама БД должна быть хорошо спроектирована, если мы хотим, чтобы система баз данных как единое целое функционировала должным образом. Цель книги состоит в выделении и описании некоторых базовых процедур проектирования для определенного типа БД, а именно
реляционных. Предполагается, что пользователь будет устанавливать БД на микрокомпьютерной системе; оДйа- ко, те же алгоритмы проектирования применимы к БД, проектируемым для больших компьютерных систем.
Определение отношения
Математически отношение определяется следующим образом.
Пусть даны “N“ множеств DI, D2, ...,DN, тогда R есть отношение над этими множествами, если R есть множество упорядоченных n-кортежей вида <dl, d2, ..., dn>, где dl - элемент из Dl, d2 - элемент из D2,... и dn - элемент из DN. Dl, D2, ..., DN называются доменами отношения R.
Домен D1Домен D1Домен D2Домен D3Домен D4Домен D2Домен D3Домен D4Рис. 1.2. Отношение с математической точки зренияРис. 1.2. Отношение с математической точки зрения
Домен D1
Домен D1
Домен D2Домен D3Домен D4
Домен D2Домен D3Домен D4
Рис. 1.2. Отношение с математической точки зрения
Рис. 1.2. Отношение с математической точки зрения
Смысл данного определения наиболее просто пояснить графически (рис. 1.2). Здесь показаны 4 домена. Домен D1 - это множество целых чисел; D2 - сим-
вольных строк, представляющих собой названия предметов; D3 - символьных строк, представляющих собой названия цветов; D4 - еще одно множество целых чисел. Отношение R состоит из б кортежей. Каждый кортеж - из 4 элементов, которые выбираются каждый из своего домена. Обратите внимание на порядок элементов в кортеже: первый элемент каждого кортежа выбран из домена D1, второй элемент - из домена D2 и т. д.
Сущность "реального мира" — (Имя файла)
ДЕТ/
Wb
— Атрибут сущности (Поле в записи)
Одна запись ►
дном
дназв
ЦЕ
шт
вес
101
102
103
болт
муфта
винт
черный синий красный
3
9
11
Файл —
104
гайка
зеленый
4
105
106
муфта болт
красный
оранжевый
13
21
Значение атрибута '
(Значение поля в записи)
Рис. 1.3. Отношение с точки зрения обработки данных
Взгляд на отношение с точки зрения обработки данных характеризует рис. 1.3. Четыре домена, представленные на рис. 1.2, соотносятся с четырьмя элементами реального мира: номером детали, ее названием, цветом и весом. Отношение принимает вид таблицы или файла, где кортежи - строки таблицы или записи в файле.
Имена столбцов (с точки зрения обработки данных - поля в записи) называются атрибутами, а индивидуальные значения, появляющиеся в отдельных корте-
жах, - значениями атрибутов. Таким образом, первый элемент первого кортежа имеет значение атрибута, равное 101 и взятое из домена дном. Следующие наборы терминов будут использоваться поочередно:
отношение, таблица и файл;
кортеж, строка и запись;
атрибут, столбец и поле;
так же как и в большей части документации по микрокомпьютерным БД..
Следует сделать одно замечание по поводу различия между математическим определением отношения и действительным хранением отношений в микрокомпьютерных системах БД. По определению отношение не может иметь два идентичных кортежа. Несмотря на то что большинство больших СУБД не допускают хранения идентичных кортежей (записей) в отношении (файле), многие микрокомпьютерные СУБД это допускают (если не используется специальная техника программирования, предотвращающая возникновение указанной ситуации).
Следует упомянуть два дополнительных термина, касающихся отношений. Число столбцов в отношении называют степенью. Текущее число кортежей в отношении называется мощностью. Степень отношения обычно не изменяется после создания отношения, но мощность будет колебаться по мерс добавления новых и удаления старых кортежей.
Определение реляционной БД
Реляционная БД представляет собой нс что иное, как совокупность отношений, содержащих всю информацию, которая должна храниться в БД. На рис. 1.4 приведен пример очень маленькой БД, названной Поставщик—Детали..
Эта база содержит три типа информации о строительной компании1):
^ БД Поставщик—Детали - хороший пример небольшой по объему реляционной БД, часто используемый в литературе.
Информация о поставщиках, поставляющих детали предприятию. Сюда относятся номер поставщика (предполагается уникальным), а также его фамилия, статус и город проживания, (не являются уникальными). Эта информация содержится в отношении ПОСТАВЩИК.
A^fMдназвцветвес101болтчерный3102муфтасиний9103винткрасный11104гайказеленый4105муфтакрасный13106болторанжевый21A^fMдназвцветвес101болтчерный3102муфтасиний9103винткрасный11104гайказеленый4105муфтакрасный13106болторанжевый21ДЕТАЛЬДЕТАЛЬпномпфамстатусгородП1Смит20ЛондонП2Джонс15ДетройтПЗЭллер10ЧикагоП4Хаус30ПарижП5Блейк20ПарижпномпфамстатусгородП1Смит20ЛондонП2Джонс15ДетройтПЗЭллер10ЧикагоП4Хаус30ПарижП5Блейк20ПарижПОСТАВЩИКПОСТАВЩИКпномдномштП11019П11024П11032П11063П21013П21028П210511П21069ПЗ1017ПЗ10213ПЗ1036ПЗ1041ПЗ1052ПЗ1065П41037П410613П51038П51049пномдномштП11019П11024П11032П11063П21013П21028П210511П21069ПЗ1017ПЗ10213ПЗ1036ПЗ1041ПЗ1052ПЗ1065П41037П410613П51038П51049ПДПД
A^fM
дназв
цвет
вес
101
болт
черный
3
102
муфта
синий
9
103
винт
красный
11
104
гайка
зеленый
4
105
муфта
красный
13
106
болт
оранжевый
21
A^fM
дназв
цвет
вес
101
болт
черный
3
102
муфта
синий
9
103
винт
красный
11
104
гайка
зеленый
4
105
муфта
красный
13
106
болт
оранжевый
21
ДЕТАЛЬ
ДЕТАЛЬ
пном
пфам
статус
город
П1
Смит
20
Лондон
П2
Джонс
15
Детройт
ПЗ
Эллер
10
Чикаго
П4
Хаус
30
Париж
П5
Блейк
20
Париж
пном
пфам
статус
город
П1
Смит
20
Лондон
П2
Джонс
15
Детройт
ПЗ
Эллер
10
Чикаго
П4
Хаус
30
Париж
П5
Блейк
20
Париж
ПОСТАВЩИК
ПОСТАВЩИК
пном
дном
шт
П1
101
9
П1
102
4
П1
103
2
П1
106
3
П2
101
3
П2
102
8
П2
105
11
П2
106
9
ПЗ
101
7
ПЗ
102
13
ПЗ
103
6
ПЗ
104
1
ПЗ
105
2
ПЗ
106
5
П4
103
7
П4
106
13
П5
103
8
П5
104
9
пном
дном
шт
П1
101
9
П1
102
4
П1
103
2
П1
106
3
П2
101
3
П2
102
8
П2
105
11
П2
106
9
ПЗ
101
7
ПЗ
102
13
ПЗ
103
6
ПЗ
104
1
ПЗ
105
2
ПЗ
106
5
П4
103
7
П4
106
13
П5
103
8
П5
104
9
ПД
ПД
Рис. 1.4. База данных Поставщик-Детали
Информация о деталях, используемых на предприятии. Сюда относятся номер детали, являющийся уникальным, название, цвет и вес, не являющиеся уникальными. Эта информация содержится в отношении ДЕТАЛЬ.
Информация о номерах и количестве деталей от каждого поставщика. Эта информация содержится в отношении ПД.
Каждое отношение в БД хранится в отдельном файле. Структура файла, используемого для хранения отношения, довольна проста, поскольку все записи имеют одинаковый формат. В больших СУБД каждое
отношение сохраняется в виде индексированного файла, где индекс представляет собой атрибут или набор атрибутов, специфицированный при конструировании отношения.
Набор атрибутов, используемый в качестве индекса, называется первичным ключом отношения. Первичный ключ определяется как такой атрибут, или набор атрибутов, который может быть использован для однозначной идентификации конкретного кортежа. Первичный ключ не должен иметь дополнительных атрибутов. Это значит, что если единичный произвольный атрибут исключить из первичного ключа, оставшихся атрибутов будет недостаточно для однозначной идентификации отдельных кортежей. В БД Поставщик—Детали первичными ключами являются <пном> для отношения ПОСТАВЩИК, <дном> для отношения ДЕТАЛЬ и пара атрибутов <пном, дном> для отношения ПД.
Читатель может убедиться, что каждый первичный ключ является достаточным для однозначной идентификации каждого кортежа в отношении. Например, в отношении ПД, если пном ■ Ш и дном = 101, можно найти не более одного кортежа с указанными значениями атрибутов. На рис. 1.4 данные значения содержит кортеж <П1,101,9>. Попытка сохранить другой кортеж с тем же первичным ключом, скажем, <П1,101,11>, приводит к возникновению конфликтной ситуации, поскольку становится неясным сколько деталей с номером 101 поставляет Ш - 9 или 11 (а может быть 20?). В полностью разработанной СУБД при попытке пользователя записать кортеж, имеющий первичный ключ, совпадающий с первичным ключом другого кортежа, уже включенного в отношение, генерируется сообщение об ошибке. Во многих реализациях СУБД, предназначенных для микрокомпьютеров, кортежи с. совпадающими первичными ключами и даже полностью идентичные кортежи могут быть занесены в отношение, и это не приводит к возникновению ошибки СУБД. В связи с этим могут возникнуть некоторые проблемы.
Во многих СУБД индекс файла, содержащего отношение, не создается автоматически, и пользователь должен выполнить команду INDEX для его создания. Индексирование файлов значительно ускоряет выпол-
нение некоторых команд. Возможно индексирование отношения с использованием атрибутов, отличных от первичного ключа. Данный тип индекса называется вторичным индексом и применяется в целях уменьшения времени доступа при нахождении данных в отношении. Простой пример индексного файла приведен на рис. 1.5. Обратите внимание, что если само отношение не упорядочено каким-либо образом и в нем могут присутствовать строки, оставшиеся после удаления некоторых кортежей, то индексный файл, напротив, отсортирован. Структура индексного файла может быть разной, но обычно используется некоторый вариант древовидной структуры, обеспечивающей быстрый поиск. Для пояснения выбрана структура индексного файла, показанного на рис. 1.5, но ее не следует воспринимать как образец практического проектирования.
Поставщикх (Индексный файл) Поставщик (Файл данных)
Номер записиФайл Поставщик пном Номер записи0001П1 00060002П2 00040003ПЗ 00030004П4 00010005П5 0002Номер записиФайл Поставщик пном Номер записи0001П1 00060002П2 00040003ПЗ 00030004П4 00010005П5 0002номер записипном пфам статус город0001П4 Хаус 30 Парих0002П5 Блейк 20 Парих0003ПЗ Зддер 10 Чикаго0004П2 Дхонс 15 Детройт0005Эта запись была удалена0006П1 Смит 20 Лондонномер записипном пфам статус город0001П4 Хаус 30 Парих0002П5 Блейк 20 Парих0003ПЗ Зддер 10 Чикаго0004П2 Дхонс 15 Детройт0005Эта запись была удалена0006П1 Смит 20 Лондон
Номер записи
Файл Поставщик пном Номер записи
0001
П1 0006
0002
П2 0004
0003
ПЗ 0003
0004
П4 0001
0005
П5 0002
Номер записи
Файл Поставщик пном Номер записи
0001
П1 0006
0002
П2 0004
0003
ПЗ 0003
0004
П4 0001
0005
П5 0002
номер записи
пном пфам статус город
0001
П4 Хаус 30 Парих
0002
П5 Блейк 20 Парих
0003
ПЗ Зддер 10 Чикаго
0004
П2 Дхонс 15 Детройт
0005
Эта запись была удалена
0006
П1 Смит 20 Лондон
номер записи
пном пфам статус город
0001
П4 Хаус 30 Парих
0002
П5 Блейк 20 Парих
0003
ПЗ Зддер 10 Чикаго
0004
П2 Дхонс 15 Детройт
0005
Эта запись была удалена
0006
П1 Смит 20 Лондон
Рис. 1.5. Простой пример индексного файла
Число отношений в БД и конкретные атрибуты, приписываемые каждому отношению, определяются в процессе проектирования. Собственно процесс проектирования может быть довольно продолжительным. Однако после завершения этапа проектирования создание БД средствами СУБД можно выполнить довольно быстро. В случае БД Поставщик—Детали структура ее полностью специфицируется коротким набором предложений, приведенным на рис. 1.6. Это сжатое описание называется концептуальной моделью БД и содержит всю информацию, необходимую для создания полной структуры БД вне зависимости от того, какая конкретно СУБД будет использована. На
рис. 1.7 приводится пример создания отношения ПОСТАВЩИК в dBase II вместе с индексным файлом для отношения ПОСТАВЩИК, в котором индекс перекрывает первичный ключ. Каждое из отношений в БД Поставщик-Детали будет создаваться аналогичным образом. Обратите внимание на то, что вся информация, необходимая для создания ПОСТАВЩИК, содержится в концептуальной модели.
Название БД: Поставщик_Детали
Атрибуты и тип: пном симв(З), пфам симв(6), статус целый, город симв(Ю), дном целый,.
дназвсимв(6),
цветсимв(6),
весцелый,
штцелый.
Отношения и <Первичные ключи>: Поставщик(пном, пфам, статус, город) <пном>, ПД(пном, дном, шт) <пном, дном>, Деталь(дном, дназв, цвет, вес) <дном>.
Рис. 1.6. Концептуальная модель БД Поставщик—Детали
. CREATE
ENTER FILENAME: В: Поставщик
ENTER RECORD STRUCTURE AS FOLLOWS:
FIELDNAME,TYPE,WIDTH,DECIMAL PLACES
001пном,с,3
002пфам,c,6
003статус,n,2
004город,c,10
005
INPUT DATA NOW? N . USE В Поставщик . INDEX ON пном TO В: Поставщикх
Рис. 1.7. Создание отношения и индексного файла для этого отношения в dBASE II
Построенное отношение является незаполненным, и его необходимо загрузить покортежно при помощи соответствующих команд записи.
Листинг содержимого отношения или всех отношений в БД, подобный тому, который приведен на рис. 1.4 для БД Поставщик-Детали, следует рассматривать как фотографию вида отношений в некоторый момент времени. Следует помнить, что содержимое всех отношений динамически изменяется, поскольку кортежи могут быть добавлены, удалены или модифицированы в течение жизненного цикла отношений. Отдельный листинг некоторого отношения в определенный момент времени называется экземпляром этого отношения.
Первичный ключ, определенный для отношения, настолько важен, что атрибуты или набор атрибутов, формирующих первичный ключ, обычно помечаются при математической форме записи отношений. В данной книге атрибуты, формирующие первичный ключ, подчеркиваются. Например, определенное на рис. 1.6 отношение ПД будет записано в виде ПД(пном,дном,шт). Это означает, что пара атрибутов <пном,дном> представляет собой первичный ключ для данного отношения.
НЕОБХОДИМОСТЬ ПРОЕКТИРОВАНИЯ БАЗ ДАННЫХ
Цели проектирования
Прежде чем приступать к рассмотрению специфических алгоритмов и проблем проектирования, имеет смысл наметить некоторые цели проектирования. В частности, в чем заключается желаемый конечный результат процесса проектирования реляционных БД? Среди множества целей, стоящих перед проектированием, следующие представляются наиболее важными:
Возможность хранения всех необходимых данных в БД.
Исключение избыточности данных.
Сведение числа хранимых в БД отношений к минимуму.
Нормализация отношений для упрощения решения проблем, связанных с обновлением и удалением данных.
Цель 1: Возможность хранения всех необходимых данных в БД
Эта цель кажется очевидной, тем не менее она очень важна. Предполагается, что БД должна содержать все данные, представляющие интерес для предприятия, так что при проектировании следует предусмотреть возможность размещения в БД всех необходимых данных. Первым шагом в процессе проектирования является определение всех атрибутов, которые впоследствии будут помещены в БД. После определения атрибутов проектировщик обдумывает, сколько отношений необходимо и какие атрибуты включать в какие отношения. В случае микрокомпьютерных БД дополнительно необходимо решить, следует ли предназначенные для хранения данные концептуализировать для построения одной базы или, возможно, двух и более.
Цель 2: Исключение избыточности данных
Сущность этой цели отнюдь не очевидна для начинающего проектировщика БД. Ключ к ее пониманию
заключается в уяснении четкого различия между дублированием данных и избыточным дублированием данных. Например, обратимся к отношению С—Н, приведенному на рис. 2.1(a). Отношение имеет два атрибута - Слж # (табельный номер служащего) и Начк (начальник). В отношении содержатся данные, указывающие непосредственного начальника каждого служащего предприятия. Фамилии начальников могут неоднократно появляться в отношении. В действительности фамилия начальника появляется один раз для каждого подчиненного ему служащего. Обратите внимание, однако, что хотя “Джоне" и “Смит“ появляются дважды в экземпляре С—Н, приведенном в на рис. 2.1(a), ни одна из дублируемых фамилий не является избыточной. Причина отсутствия избыточности заключается в том, что при удалении одной из фамилий из отношения будет утеряна информация. Например, на рис. 2.1(6) показан вид экземпляра отношения С—Н при удалении дублированных фамилий. В этом случае нет возможности узнать фамилии начальников служащих с номерами #195 и #200.
Сах#Начк125Дхонс138Смит195Смит200ДхонсСах#Начк125Дхонс138Смит195Смит200ДхонсС-н с-нС-н с-нСах#Начк125Джонс138Смит195-200-Сах#Начк125Джонс138Смит195-200-
Сах#
Начк
125
Дхонс
138
Смит
195
Смит
200
Дхонс
Сах#
Начк
125
Дхонс
138
Смит
195
Смит
200
Дхонс
С-н с-н
С-н с-н
Сах#
Начк
125
Джонс
138
Смит
195
-
200
-
Сах#
Начк
125
Джонс
138
Смит
195
-
200
-
аб
Рис. 2.L Дублированные данные, не являющиеся избыточными
На рис. 2.2(a) приведен пример отношения с избыточным дублированием данных. Отношение С—Н—Т похоже на отношение С—Н, но включает дополнительный атрибут Нтел, представляющий собой номер телефона начальника. Предполагается, что каждый начальник имеет только один телефонный номер. В этом экземпляре отношения номера телефонов Джонса и Смита появятся более чем один раз и дублирован-
ная информация о телефонных номерах является избыточной. Причина избыточности в том, что если, скажем, удалить один из номеров Джонса, эта информация может быть получена из других кортежей отношения. На рис. 2.2(6) приведен пример того, как будет выглядеть отношение С—Н—Т в случае замещения дублированных телефонных номеров “нулями44.
Слж#НачкНтел125Джонс3051138Смит2222195Смит2222200Джонс3051Слж#НачкНтел125Джонс3051138Смит2222195Смит2222200Джонс3051С-н-тС-н-тааСлж#НачкНтел125Джонс3051138Смит2222195Смит-200Джонс-Слж#НачкНтел125Джонс3051138Смит2222195Смит-200Джонс-С-н-тС-н-тбб
Слж#
Начк
Нтел
125
Джонс
3051
138
Смит
2222
195
Смит
2222
200
Джонс
3051
Слж#
Начк
Нтел
125
Джонс
3051
138
Смит
2222
195
Смит
2222
200
Джонс
3051
С-н-т
С-н-т
а
а
Слж#
Начк
Нтел
125
Джонс
3051
138
Смит
2222
195
Смит
-
200
Джонс
-
Слж#
Начк
Нтел
125
Джонс
3051
138
Смит
2222
195
Смит
-
200
Джонс
-
С-н-т
С-н-т
б
б
Слж#Начк125Джонс138Смит195Смит200ДжонсСлж#Начк125Джонс138Смит195Смит200Джонсс-нс-нНачкНтелДжонс3051Смит2222НачкНтелДжонс3051Смит2222н-тн-т
Слж#
Начк
125
Джонс
138
Смит
195
Смит
200
Джонс
Слж#
Начк
125
Джонс
138
Смит
195
Смит
200
Джонс
с-н
с-н
Начк
Нтел
Джонс
3051
Смит
2222
Начк
Нтел
Джонс
3051
Смит
2222
н-т
н-т
в
Рис. 2.2. Исключение избыточных данных
Понятно, что телефонные номера Джонса и Смита не утеряны, поскольку каждый из них обнаруживается в одном из кортежей отношения. Данный метод управления избыточностью неудовлетворителен по двум причинам. Во-первых, пустых полей в БД следует избегать, так как необходимы дополнительные усилия при программировании, направленные на определение реальных значений “нулей44. В рассматриваемом случае чтение третьего кортежа < 195,Смит,-> отношения не позволяет узнать телефонный номер Смита. Пользователь должен уметь находить в отно-
шении другой кортеж, для которого значением атрибута Начк является Смит, а значение атрибута Нтел не является нулевым. Во-вторых, что более важно, отношение, представленное на рис. 2.2(6), имеет структуру, чреватую возникновением серьезных проблем при удалении информации. Если служащий с номером Слж#=125 увольняется с предприятия и кортеж < 125,Джонс,3051 > будет удален из отношения при должной регистрации факта увольнения, произойдет утеря телефонного номера Джонса, поскольку нигде более в отношении он не представлен.
Рис. 2.2(b) показывает лучший способ исключения избыточности телефонных номеров. Здесь отношение С—Н—Т заменяется двумя отношениями, одно из которых содержит информацию о табельных номерах служащих и фамилиях руководителей, а другое - информацию о телефонных номерах начальников. В следующей главе будет показано, что разбиение отношений представляет собой стандартную процедуру проектирования, которая должна осуществляться при соблюдении определенных ограничений. Как следует из рис. 2.2(b), служащий с номером #125 теперь может быть удален из отношения С—Н без потери номера телефона бывшего начальника этого служащего, хранимого в отношении Н-Т.
Цель 3: Сведение числа хранимых в БД отношений к минимуму.
Эта цель обусловлена тем, что разбиение одного отношения на два или более меньших отношений желательно с точки зрения исключения определенных проблем, но это неудобно для пользователя. Таким образом, нельзя допускать неограниченный рост числа отношений.
Цель 4: Нормализация отношений
Для некоторых отношений очень важна проблема удаления и обновления (например, обсуждавшаяся выше в цели 2 потеря телефонного номера руководителя) . Проектировщик должен уметь обнаруживать эти потенциально опасные отношения и “нормализовать их“ посредством разбиения предписанным образом. Нормализация представляет собой разбиение одного отношения на два или более в соответствии со
специальной процедурой определения разбиения. Нормализация будет обсуждаться в гл. 3.
Цели 3 и 4 противоречат друг другу, поэтому здесь требуется взаимный компромисс. Это будет частью завершающего этапа проектирования.
Универсальное отношение
Предположим, что требуется разработать небольшую БД для консультанта университета. У консультанта имеется много консультируемых им студентов, живущих на территории университетского городка, причем все эти студенты учатся на основном факультете.
Первый шаг процесса проектирования состоит в определении как всех атрибутов, наличие которых в БД ожидает консультант, так и связей между атрибутами. Эта информация получается от консультанта в итоге ряда детальных обсуждений, не оставляющих сомнений в том, что он знает какие данные должны быть в БД, каким образом БД будет использоваться и какую информацию консультант ожидает получать от БД. После нескольких бесед с консультантом имена и условия, связанные с атрибутами, хранение которых предполагается, были определены следующим образом:
Сном: Номер студента. Целое значение, уникальное для каждого студента университета.
Сфам: Фамилия студента. Каждый студент имеет только одну фамилию, но возможно, что одну фамилию носят несколько студентов.
Кном: Номер комнаты в общежитии городка. Каждый студент живет на территории городка и имеет комнату. В одной комнате может проживать более одного студента.
Тном: Номер телефона студента. Каждая комната общежития имеет один телефон и им пользуются все студенты, проживающие в этой комнате.
Курс: Номер курса. Это идентификационный номер курса, посещаемого студентом. Примером может служить номер МТН122. Консультант будет сохранять данные только о курсах, завершенных студентом.
Семестр: Университетский семестр. Представляет собой семестр, в котором данный курс был завершен
студентом. Возможно, что студент изучал один и тот же курс в различных семестрах.
Оценка: Оценка за курс. Оценка, полученная студентом за определенный курс в данном семестре.
На рис. 2.3 представлен образец данных, концептуализированных консультантом для их хранения в БД. Хотя на рисунке приводится пример в виде таблицы данных, которые могут храниться в БД в некоторый момент времени, указанная таблица отношением не является.
КОНСУЛЬТАНТ
Сном
Сфам
Кном
Тном
КУРС
Семестр
Оценка
3215
ДхонсГ
120DH
2136
МТН122
F84
1.6
SCI120
F84
2.4
PHY230
W85
2.1
МТН122
W85
2.3
х 3462
СмитА
238VH
2344
МТН122
W84
2.3
МТН123
W85
3.5
PSY220
W85
3.7
3567
ХаузДх
120DH
2136
SCI239
W84
3.3
EGR171
F84
3.5
PHY141
F84
1.8
4756
АлексК
345VH
3321
MUS389
F83
4.0
Рис. 2.3. Данные, необходимые консультанту
3215
ДхонсГ
120DH
2136
МТН122
F84
1.6
SCI120
F84
2.4
PHY230
W85
2.1
МТН122
W85
2.3
Рис. 2.4. Одна “строка44 таблицы, приведенной на рис. 2.3
Для иллюстрации того, почему таблица на рис. 2.3 не является отношением, выделим одну “строку44 из таблицы (рис. 2.4). На этом рисунке значения четырех полей Сном, Сфам, Кном и Тном - атомар-
ные1^ в то время как значения в полях Курс, Семестр и Оценка - множественные. Данная “строка“ очевидным образом отличается по форме от кортежей, представленных в простых отношениях и рассмотренных выше. Отличие в том, что не все поля строки содержат атрибуты, значения которых атомарные. Для придания данным, приведенным на рис. 2.3, формы отношения необходимо реконструировать их таким образом, чтобы каждый элемент кортежа имел атомарное значение. Обычно это удается сделать с помощью простого процесса вставки (результат для данного случая показан на рис. 2.5). В результате этого процесса добавляется большой объем избыточных данных - исключение избыточности достигается на следующих этапах проектирования.
КОНСУЛЬТАНТ
Сном
Сфам
Кном
Тном
Курс
Семестр
Оценка
3215
ДхонсГ
120DH
2136
МТН122
F84
1.6
3215
ДхонсГ
120DH
2136
SCI120
F84
2.4
3215
ДхонсГ
120DH
2136
PHY230
W85
2.1
3215
ДхонсГ
120DH
2136
МТН122
W85
2.3
3462
СмитА
238VH
2344
МТН122
W84
2.3
3462
СмитА
238VH
2344
МТН123
W85
3.5
3462
СмитА
238VH
2344
PSY220
W85
3.7
3567
ХаузДх
120DH
2136
SCI239
W84
3.3
3567
ХаузДх
120DH
2136
EGR171
F84
3.5
3567
ХаузДх
120DH
2136
PHY141
F84
1.8
4756
АлексК
345VH
3321
MUS389
F83
4.0
Рис. 2.5. Данные из таблицы, приведенной на рис. 2.3, помещенные в корректное отношение
Таблица на рис. 2.5 представляет собой экземпляр корректного отношения. Его называют универсальным отношением проектируемой БД. В одно универсальное отношение включаются все представляющие интерес атрибуты, и оно может содержать все данные, кото-
^ Атомарным называется неделимое значение, а не множество, или кортеж, значений из некоторых доменов. - Прим. ред.
рые предполагается размещать в БД в будущем» Для малых БД (включающих не более 15 атрибутов) универсальное отношение может использоваться в качестве отправной точки при проектировании БД.
Проблемы, вызываемые использованием единственного отношения
Начинающий проектировщик будет использовать отношение КОНСУЛЬТАНТ (рис. 2.5) в качестве завершенной БД. Это выглядит достаточно последовательным. Зачем разбивать отношение КОНСУЛЬТАНТ на несколько более мелких отношений, если оно способно заключать в себе все данные? Существует несколько причин, почему не следует использовать данное отношение в качестве единственного в БД. Это обусловлено тем, как будет использоваться БД, и какое воздействие на данные в отношении КОНСУЛЬТАНТ будут оказывать определенные операции. Различаются три специфичные проблемы: проблема, связанная с обновлением (модификацией) данных в БД; проблема, обусловленная необходимостью ' удаления кортежей; проблема, обусловленная необходимостью включения новых кортежей. Выделенные проблемы обычно называют аномалиями вставки, удаления и обновления, понимая под аномалией отклонение от нормы.
Проблема вставки
Если у консультанта появляется новый консультируемый им студент, еще не закончивший курс, для него необходимо включить в БД кортеж с нулевыми (пустыми) значениями атрибутов Курс, Семестр и Оценка. Как уже не раз отмечалось, нулевых значений следует избегать. Следовательно, включение в БД нового студента невозможно вплоть до завершения им курса.
На рис. 2.6(a) показан пример того, как будет выглядеть отношение КОНСУЛЬТАНТ в случае принудительного включения в него информации о студенте, не завершившем ни одного курса (для случая использования dBASE II). Пустые символьные строки представляются пробельными полями (Курс и Семестр), в
то время как нулевое численное значение в поле Оценка интерпретируется dBASE II как 0.0. Рис. 2.6(6) иллюстрирует возможные последствия появления 0.0 при отсутствии информации. Получен ответ на запрос “Выдать список Сном и Сфам для всех студентов, получивших хотя бы одну оценку ниже 2.0“. В число таких студентов попал ХоумерХ, хотя он не закончил ни одного курса.
. use консультант . list
00001
3215
ДхонсГ
120DH
2136
МТН122
F84
1.6
00002
3215
ДхонсГ
120DH
2136
SCI120
F84
2.4
00003
3215
ДхонсГ
120DH
2136
PHY230
W85
2.1
00004
3215
ДхонсГ
120DH
2136
МТН122
W85
2.3
00005
3462
СмитА
238VH
2344
МТН122
W84
2.3
00006
3462
СмитА
238VH
2344
МТН123
W85
3.5
00007
3462
СмитА
238VH
2344
PSY220
W85
3.7
00008
3567
ХаузДх
120DH
2136
SCI239
W84
3.3
00009
3567
ХаузДх
120DH
2136
EGR171
F84
3.5
00010
3567
ХаузДх
120DH
2136
PHY141
F84
1.8
00011
4756
АлексК
345VH
3321
MUS389
F83
4.0
00012
7890
ХоумерХ
121VH
7619
0.0
а
. display off Сном, Сфам for Оценка <2.0
3215 ДхонсГ
3567 ХаузДх
7890 ХоумерХ
б
Рис. 2.6. а - результат вставки записи с пустыми полями; б - ошибочный результат выполнения запроса, вызванный наличием пустых полей
Проблема обновления
В отношении КОНСУЛЬТАНТ большое число избыточных данных. Избыточность данных всегда свидетельствует о возможности модификации только части требуемых данных с помощью операции обновления.
Отношение КОНСУЛЬТАНТ характеризуется как явной, так и неявной избыточностью. Явная избыточность заключается в том, что фамилия данного студента, номер комнаты и номер телефона могут появиться в отношении несколько раз. В экземпляре отношения КОНСУЛЬТАНТ, приведенном на рис. 2.5, номер комнаты ДжонсГ появляется четырежды. Если она обратится к своему консультанту и сообщит ему об изменении номера ее комнаты, то консультант будет вынужден проследить изменение этого номера во всех четырех кортежах во избежание противоречивости данных.
Неявная избыточность обнаруживается в том, что один и тот же номер телефона имеют все студенты, живущие в одной комнате. На рис. 2.5 телефонный номер для комнаты 120DH появляется в сочетании с именами ДжонсГ и ХаузДж. Допустим, ДжонсГ известит своего консультанта о том, что ее номер телефона изменен на 7777, забыв при этом сообщить о подруге по комнате. Если консультант изменит телефонный номер только в тех кортежах, которые содержат номер телефона ДжонсГ, то правильный номер телефона, расположенного в комнате 120DH,' будет фактически утерян, поскольку в отношении будут присутствовать два различных телефонных номера для одной комнаты.
Рис. 2.7 иллюстрирует последнюю аномалию обновления. На рис. 2.7 (а) телефонный номер для ДжонсГ изменяется на 7777. На рис. 2.7 (б) приводится ответ dBASE II на запрос “Вывести перечень номеров телефонов для комнаты 120DH“. В ответе на запрос содержатся два номера, что свидетельствует об ошибке, поскольку в каждой комнате имеется один телефон с одним телефонным номером. Обратите внимание, что dBASE II вывела на печать дублированные ответы на запрос. Каждый из телефонных номеров 2136 и 7777 содержится в трех различных кортежах экземпляра обсуждаемого отношения КОНСУЛЬТАНТ, и все шесть значений были распечатаны СУБД. При программировании некоторых СУБД в них закладывается функция подавления дублирования в ответах -на-запросыу-если необходимость дублирования не оговаривается специально.
. list off
3215
ДхонсГ
120DH
2136
МТН122
F84
1.6
3215
ДхонсГ
120DH
2136
SCI120
F84
2.4
3215
ДхонсГ
120DH
2136
PHY230
V85
2.1
3215
ДхонсГ
120DH
2136
МТН122
W85
2.3
3462
СмитА
238VH
2344
МТН122
W84
2.3
3462
СмитА
238VH
2344
МТН123
W85
3.5
3462
СмитА
238VH
2344
PSY220
W85
3.7
3567
ХаузДх
120DH
2136
SCI239
W84
3.3
3567
ХаузДх
120DH
2136
EGR171
F84
3.5
3567
ХаузДх
120DH
2136
PHY141
F84
1.8
4756
АлексК
345VH
3321
MUS389
F83
4.0
7890
ХоумерХ
121VH
7619
0.0
. replace Тном with 7777 for Сфам = ’ДхонсГ’ OOOKREPLACEMENT(S)
а
. display off Thom for Khom = ’120DH’
' 7777
7777
7777
7777
2136
2136
2136
6
Рис. 2.7. a - изменение номера телефона некоторого студента, б - ошибочный результат выполнения запроса, вызванный изменением номера телефона
Проблемы удаления
В экземпляре отношения КОНСУЛЬТАНТ (рис. 2.5) присутствует только один кортеж, в котором Сном=4756. Этот кортеж соответствует студенту с именем АлексК. Предположим, что консультант узнает, что этот студент не закончил курс MUS389, как это отмечено, и удаляет этот кортеж из отношения. Поскольку это единственный кортеж с информацией об этом студенте, его удаление приведет к исключе-
нию студента из БД. Если консультант вслед за данной операцией удаления запросит список содержащихся в отношении КОНСУЛЬТАНТ имен всех консультируемых, то имени АлексКвэтом списке он нс найдет.
Задачи к гл. 2
Найдите первичный ключ для отношения КОНСУЛЬТАНТ, приведенного на рис. 2.5.
Укажите примеры данных в отношении КОНСУЛЬТАНТ (рис. 2.5), являющиеся как дублированными, так и избыточными.
Указать примеры данных в отношении КОНСУЛЬТАНТ (рис. 2.5), являющиеся дублированными, но нсизбыточными.
Отношение ТЕЛНОМ предназначено для хранения информации о фамилиях служащих, номерах домашних и служебных телефонов. Каждый служащий имеет уникальную фамилию, один домашний номер телефона и может иметь несколько служебных телефонных номера. У нескольких служащих номер служебного телефона может быть общим. Типичный экземпляр отношения ТЕЛНОМ приведен на рис. 2.8:
укажите, какие данные в экземпляре отношения ТЕЛНОМ являются избыточными;
как следует изменить отношение ТЕЛНОМ, чтобы исключить избыточные данные;
приведите экземпляры отношений, которые Вы предлагаете использовать с целью исключения избыточности. Воспользуйтесь данными, приведенными на рис. 2.8.
ТЕЛНОМ
Фамилия
Дтелном
Слхтел
ДхонсКК
345-1121
3167
ДхонсКК
345-1121
3168
КрофтАД
345-9898
4000
МартцЛК
348-4512
3167
МартцЛК
348-4512
3168
РалстонТТ
345-7766
4001
РалстонТТ
345-7766
4002
Рис. 2.8. Экземпляр отношения ТЕЛНОМГ
ФУНКЦИОНАЛЬНЫЕ ЗАВИСИМОСТИ
. Первая нормальная форма (1НФ)
В гл. 2 уже было отмечено, что составной частью проектирования реляционной БД является процесс разбиения отношений с неудовлетворительными свойствами (с точки зрения аномалий) на новые отношения. В связи с этим процессом следует поставить несколько вопросов.
Из какого источника Вы получаете отношение (или отношения) перед началом процесса?
Каким образом Вы можете распознать отношения, нуждающиеся в разбиении?
Каким образом Вы будете осуществлять разбиение?
Что является признаком завершения процесса разбиения?
Ответы на эти вопросы будут даны в настоящей главе и более углубленно в гл. 4.
Для БД с числом атрибутов меньшим 20 начальной точкой указанной процедуры может служить универсальное отношение. Это отношение содержит все представляющие интерес атрибуты, и имеет структуру, в которой каждый кортеж состоит из атомарных элементов. Это означает, что все экземпляры отношений должны иметь форму, показанную на рис. 2.5, а нс подобную той, которая приведена на рис. 2.3.
Говорят, что отношение находится в первой нормальной форме (или 1НФ), если каждый его элемент имеет и всегда будет иметь атомарное значение. Отношение должно быть в 1НФ даже прежде постановки вопроса о его разбиении на два или более отношения.
Концепция функциональных зависимостей
Процесс разбиения отношения с целью уменьшения вероятности возникновения аномалий называется декомпозицией. Ключевой для осуществления декомпозиции логическим методическим путем является кон-
цепция функциональных зависимостей между атрибутами в рассматриваемом отношении.
функциональная зависимость (ФЗ) определяется следующим образом:
Если даны два атрибута А и В, то говорят, что В функционально зависит от А, если для каждого значения А существует ровно одно связанное с ним значение В (в любой момент времени). А и В могут быть составными, то есть они могут представлять собой не единичные атрибуты, а группы, состоящие из двух и более атрибутов.
С практической точки зрения смысл данного определения состоит в том, что если В функционально зависит от А, то каждый из кортежей, имеющих одно и то же значение А, должен иметь также одно и то же значение В. Значения А и В могут изменяться время от времени, но при этом они должны изменяться так, чтобы каждое уникальное значение А имело только одно значение В, связанное с ним. ФЗ описываются с помощью нескольких различных способов нотации. Два наиболее часто используемых способа показаны на рис. 3.1.
А -> В (Математическая форма записи)
(Диаграмма или графическая форма записи)*
Рис. 3.1. Два возможных способа записи того, что атрибут В функционально зависит от атрибута А
В конкретной ситуации ФЗ определяется путем детализации свойств всех атрибутов в отношении и выводе заключения о том, как атрибуты соотносятся между собой. ФЗ не могут быть доказаны путем простого просмотра отдельного экземпляра отношения и нахождения двух атрибутов, имеющих тс же значения в более чем одном кортеже. Это может служить ключом к тому, в каком направлении следует вести поиск ФЗ, но нс доказательством. ФЗ необходимо получить исходя из базовых свойств самих атрибутов.
В качестве примера вновь обратимся к атрибутам в отношении КОНСУЛЬТАНТ (рис. 2.5) и, в частности, к подробному объяснению того, как эти атрибуты связаны между собой (разд. 2.2). После изучения описаний атрибутов могут быть выведены зависимости, приведенные на рис. 3.2.
Сном -*► Сфам Сном -^- Кном Кном-^Тном "Гном-*- Кном Сном -э-Тном
Сном , Курс , Семестр —^ Оценка
Рис. 3.2. Различные способы представления ФЗ, существующих между атрибутами отношения КОНСУЛЬТАНТ
Соображения, приведшие к этим ФЗ, в деталях обсуждаются ниже.
Номера студентов являются уникальными. Каждому студенту назначается номер Сном, причем все номера различны. • Таким образом, если вы знаете Сном студента, вы знаете, что с ним может быть связана только одна фамилия Сфам: Сном -> Сфам, Обратное не является верным. Сфам -> Сном не является правильной ФЗ, поскольку несколько студентов могут иметь одну фамилию.
Каждый студент прикреплен к одной комнате общежития, но в одной комнате может проживать бо-
лее чем один студент. Таким образом, Сном -> Кном является верным, а Кном -> Сном - нет.
Поскольку в каждой комнате только один теле* фон и каждый телефон, в свою очередь, имеет уникальный номер, получаем Кном -> Тном и Тном *> Кном. Данная ситуация обычно обозначается в виде Сном <-> Тном, и говорят, что Сном и Тном взаимозависимы.
Поскольку в каждой комнате только один телефон и этот телефон имеет уникальный номер, следовательно только один телефонный номер может быть связан с данным студентом, или иначе Сном -> Тном,
Последняя ФЗ представляет собой пример сложного набора атрибутов, входящих в ФЗ. Зависимость Сном, Курс, Семестр -> Оценка означает, что оценка однозначно определяется только в том случае, если известен Сном студента, изучающего данный Курс в данном Семестре. (Необходимо помнить, что студент может повторить прохождение учебного курса и получить при этом другую оценку).
Читателю следует проверить отношение КОНСУЛЬТАНТ (рис. 2.5) и убедиться в том, что данные в этом отношении согласуются с функциональными зависимостями, представленными на рис. 3.2. Например, отметим, что Кном * 120DH и Тном * 2136 всегда располагаются парой (Кном <-> Тном); также Сном*3215 связан только с одной фамилией, именно “ДжонсГ“, как и должно быть, поскольку Сном -> Сфам. Другие ФЗ следует верифицировать аналогичным образом. Читателю следует также отметить, что в экземпляре отношения КОНСУЛЬТАНТ, показанном на рис. 2.5, только один номер Сном связан с каждым именем Сфам; однако это не доказывает Сфам - > Сном, что является ложным, Это говорит только о том, что в настоящее время нет двух консультируемых с одной фамилией, В будущем может случиться так, что два студента с одной фамилией будут включены в отношение КОНСУЛЬТАНТ.
3,3» Нормальная форма Бойса-Кодда (НФБК)
Опытному проектировщику БД достаточно беглого взгляда на диаграмму, приведенную на рис. 3.2(6),
чтобы сделать вывод о том, что отношение КОНСУЛЬТАНТ нельзя считать “хорошим". Проектировщик придет к такому выводу, глядя на ФЗ, полученные для отношения КОНСУЛЬТАНТ, и обращая внимание на некоторые их нежелательные свойства. Перед обсуждением этих свойств необходимо определить два термина, касающихся ФЗ.
Возможный ключ. Возможный ключ представляет собой атрибут или набор атрибутов, который может быть использован для данного отношения в качестве первичного ключа. Первичный ключ всегда является возможным ключом; однако не исключено наличие других возможных ключей, которые могли бы быть, но не были использованы в качестве первичного ключа.
Детерминант. Если А -> В есть ФЗ и В не за висит функционально от любого подмножества А, то говорят, что А представляет собой детерминант В.
Из рис. 3.2 можно заключить, что отношение КОНСУЛЬТАНТ имеет только один возможный ключ, а именно набор атрибутов <Сном,Курс,Семестр>. Этот вывод получен путем нахождения минимального набора значений атрибутов, которые, если они известны, определяют значения всех других атрибутов кортежа. С помощью ФЗ, представленных на рис. 3.2, легко видеть, что один номер Сном определяет Сфам, Кном и Тном и для определения Оценки должен быть известен весь набор Сном, Курс и Семестр. Таким образом, если известны значения атрибутов данного выше возможного ключа, то значения всех других атрибутов кортежа, содержащего указанный возможный ключ, будут однозначно специфицированы.
Детерминанты в отношении КОНСУЛЬТАНТ определить легко: ими являются левые части всех ФЗ в отношении. Детерминантами в КОНСУЛЬТАНТ являются <Сном,Курс,Семестр>, <Сном>, <Кном> и <Тном>. Детерминанты заключены в угловые скобки для того, чтобы в данном случае выделить четыре различных детерминанта. Следует заметить, что взаимные зависимости дают два детерминанта.
Одним из самых первых, но и одним из самых важных результатов в области реляционных БД стало
доказанное Коддом утверждение о том, что большинство потенциальных аномалий в БД будет устранено в случае должной декомпозиции каждого отношения в нормальную форму Бойса-Кодда (НФБК). Эта форма определяется следующим образом:
отношение находится в НФБК, если и только если каждый детерминант отношения является возможным ключом.
Хотя существуют нормальные формы более высокого уровня, которые накладывают даже более сильные ограничения на разрабатываемые отношения, на практике большинство проектировщиков стараются получить отношения в НФБК. Эта цель будет преследоваться и в предлагаемой книге.
Отношение КОНСУЛЬТАНТ не находится в НФБК. Это легко обнаружить, если расположить рядом перечень всех детерминантов и перечень всех возможных ключей и посмотреть, является ли каждый детерминант возможным ключом.
Возможные ключи от- Детерминанты отношени ношения КОНСУЛЬТАНТКОНСУЛЬТАНТ
<Сном,Курс,Семестр><Сном,Курс,Семестр>
<Сном>
<Тном>
<Кном>
Поскольку не каждый детерминант в отношении КОНСУЛЬТАНТ является возможным ключом, следовательно, КОНСУЛЬТАНТ не находится в НФБК и его необходимо подвергнуть декомпозиции.
Общий подход к декомпозиции
К этому моменту все готово для общего описания одного метода, определяющего, как следует осуществлять с помощью декомпозиции проектирование реляционных БД. Далее будет показано, что этот метод должен быть усовершенствован для преодоления некоторых последующих затруднений.
2» Определение всех ФЗ между атрибутами отношения.
Определение того» находится ли отношение в НФБК. Если да, проектирование завершается; если нет, отношение должно быть разложено на два отношения.
Повторение шагов 2 и 3 для каждого нового отношения, полученного в результате декомпозиции. Проектирование завершается, когда все отношения будут находиться в НФБК.
Предложенный выше метод не определяет, как осуществлять декомпозицию отношения, не приведенного к НФБК, на два отношения. Это осуществляется с помощью ФЗ следующим образом:
Пусть отношение 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 приведенного выше алгоритма проектирования.
В качестве примера использования метода выполним декомпозицию отношения КОНСУЛЬТАНТ. Обращаясь вновь к детерминантам и возможным ключам отношения КОНСУЛЬТАНТ, видим, что имеются три детерминанта, не являющихся возможными ключами:
<Сном>, <Тном>, и <Кном>.
Началом процесса служит следующее определение универсального отношения:
R1 (Сном, Курс, Семестр, Сфам, Кном, Оценка)R1 (Сном, Курс, Семестр, Сфам, Кном, Оценка)R2 (Тном, Кном)R2 (Тном, Кном)Возможные ключиВозможные ключи1, (Сном, Курс, Семестр )
R1 (Сном, Курс, Семестр, Сфам, Кном, Оценка)
R1 (Сном, Курс, Семестр, Сфам, Кном, Оценка)
R2 (Тном, Кном)
R2 (Тном, Кном)
Возможные ключи
Возможные ключи
ДетерминантыДетерминанты( Сном , Курс. Семестр)
Детерминанты
Детерминанты
(Сном)
Возможные ключи
1,(Кном)
(Тном)
Детерминанты
.(Кном)
.( Тном)
Рис, 3.3. Отношения R1 и R2, полученные в результате проекции Кном <-> Тном из отношения КОНСУЛЬТАНТ
КОНСУЛЬТАНТ (Сном, Курс, Семестр. Сфам, Кном, Тном, Оценка).
Кандидатами среди ФЗ для осуществления проекции являются
Сном -> Кном; Сном -> Тном; Кном -> Тном и Тном -> Кном.
На этом этапе должно быть принято решение, какую ФЗ следует выбрать для проведения первой проекции. Не исключено, что в итоге выбора той или иной начальной проекции будут получены различные БД. Если это именно так, то каждая из получивших-
ся БД, вообще говоря, должна быть подвергнута анализу с целью выбора наиболее полно отвечающей требованиям и условиям предприятия.
Простым правилом выбора ФЗ для проекции может служить поиск “цепочки Ф3“ вида
А -> В -> С
с последующим использованием для проекции крайней правой зависимости. В нашем случае такой “цепоч- кой“ является Сном -> Кном -> Тном и “конец цепочки “ Кном -> Тном порождает первую проекцию. Полученные в итоге отношения R1 и R2 приведены на рис. 3.3 вместе с каждой из связанных с ними ФЗ.
Отношение R2 (Кном, Тном) находится в НФБК, поскольку все его детерминанты являются возможными ключами. Отношение R2 нс нуждается более в декомпозиции. Однако отношение R1 (Сном, Курс, Се- местр,СФам,Кном,Оценка) нс находится в НФБК, так как детерминант <Сном> не является возможным ключом. Следовательно отношение R1 необходимо подвергнуть дальнейшему разложению. Детерминант <Сном>, из-за которого возникло затруднение, имеет два зависимых от него атрибута
Сном -> Сфам,Сном -> Кном,
что можно рассматривать в качестве единичной ФЗ с составной правой частью
Сном -> Сфам, Кном.
Проекция отношения R1, порождаемая этой ФЗ, приводит к получению отношений R3 и R4, показанных на рис. 3.4. Эти два отношения находятся в НФБК и вместе с отношением R2 могли бы использоваться при формировании БД для консультанта. На рис. 3.5 представлен окончательный вид отношений для такой БД (названной Коне), а также экземпляры каждого отношения с данными, совпадающими с использованными для исходного отношения КОНСУЛЬТАНТ. Заметим, в частности, что в процессе декомпозиции автоматически произошло разбиение исходного отношения КОНСУЛЬТАНТ на три логических
R3 (Сном, Курс, Семестр, Оценка)R3 (Сном, Курс, Семестр, Оценка)компонента: R2, в котором содержится информация о комнатах и телефонах; R3, в котором содержится информация об учебных курсах и полученных студентами оценках; R4, в котором содержится информация о студентах. Такое логическое разбиение является прямым результатом использования в процессе декомпозиции заложенной в ФЗ информации, детализирующей то, как различные атрибуты в исходном отношении соотносятся друг с другом.
R3 (Сном, Курс, Семестр, Оценка)
R3 (Сном, Курс, Семестр, Оценка)
Возможные ключи
(Сном, Курс, Семестр)
Детерминанты
R4 (Сном, Сфам, Кном)R4 (Сном, Сфам, Кном).(Сном, Курс, Семестр)
R4 (Сном, Сфам, Кном)
R4 (Сном, Сфам, Кном)
Возможные ключи
1. (Сном)
Детерминанты
(Сном)
Рис. 3.4. Отношения R3 и R4, полученные в результате проекции Сном -> Сфам,Кном из отношения R1
Обзор исходных аномалий
Сейчас самое время задаться вопросом: присутствуют ли в БД Коне те же аномалии, которые характеризо-
вали отношение КОНСУЛЬТАНТ, или декомпозиция автоматически привела к их устранению? Для того чтобы подтвердить устранение аномалий, - а именно эта цель ставилась в первую очередь при осуществлении декомпозиции, - рассмотрим, опираясь на приведенную на рис. 3.5 БД Коне, проблемы вставки, удаления и обновления из разд. 2.2.
СномКурсСеместрОценка3215МТН122F841.63215SCH20F842.43215PHY230W852.13215МТН122V852.33462МТН122W842.33462МТН123V853.53462PSY220V853.73567SCI239V843.33567EGR171F843.53567PHY141F841.84756MUS389F834.0СномКурсСеместрОценка3215МТН122F841.63215SCH20F842.43215PHY230W852.13215МТН122V852.33462МТН122W842.33462МТН123V853.53462PSY220V853.73567SCI239V843.33567EGR171F843.53567PHY141F841.84756MUS389F834.0R2(Khom,Thom) R3(Сном.Курс.Семестр.Оценка) R4(Сном.СФам.Кном) аR2(Khom,Thom) R3(Сном.Курс.Семестр.Оценка) R4(Сном.СФам.Кном) аR3R3КномТном120DH2136238VH2344345VH3321КномТном120DH2136238VH2344345VH3321R2R2СномСфамКном3215ДхонсГ120DH3262СмитА238VH3567ХауэДж120DH4756АлексК345VHСномСфамКном3215ДхонсГ120DH3262СмитА238VH3567ХауэДж120DH4756АлексК345VHR4R4
Сном
Курс
Семестр
Оценка
3215
МТН122
F84
1.6
3215
SCH20
F84
2.4
3215
PHY230
W85
2.1
3215
МТН122
V85
2.3
3462
МТН122
W84
2.3
3462
МТН123
V85
3.5
3462
PSY220
V85
3.7
3567
SCI239
V84
3.3
3567
EGR171
F84
3.5
3567
PHY141
F84
1.8
4756
MUS389
F83
4.0
Сном
Курс
Семестр
Оценка
3215
МТН122
F84
1.6
3215
SCH20
F84
2.4
3215
PHY230
W85
2.1
3215
МТН122
V85
2.3
3462
МТН122
W84
2.3
3462
МТН123
V85
3.5
3462
PSY220
V85
3.7
3567
SCI239
V84
3.3
3567
EGR171
F84
3.5
3567
PHY141
F84
1.8
4756
MUS389
F83
4.0
R2(Khom,Thom) R3(Сном.Курс.Семестр.Оценка) R4(Сном.СФам.Кном) а
R2(Khom,Thom) R3(Сном.Курс.Семестр.Оценка) R4(Сном.СФам.Кном) а
R3
R3
Кном
Тном
120DH
2136
238VH
2344
345VH
3321
Кном
Тном
120DH
2136
238VH
2344
345VH
3321
R2
R2
Сном
Сфам
Кном
3215
ДхонсГ
120DH
3262
СмитА
238VH
3567
ХауэДж
120DH
4756
АлексК
345VH
Сном
Сфам
Кном
3215
ДхонсГ
120DH
3262
СмитА
238VH
3567
ХауэДж
120DH
4756
АлексК
345VH
R4
R4
Рис. 3.5. а - база данных Коне; б - экземпляр БД, в котором используются данные, приведенные на рис. 2.5
Вставка. Когда отношение КОНСУЛЬТАНТ служило основой БД, новый студент не мог быть в нее включен до действительного завершения им какого- либо курса. В БД Коне информация общего характера о консультируемых студентах хранится в отношении R4. Как только новый студент принимается в университет и ему отводится комната, так этот сту-
дент может быть включен в БД (в R4). Студенту нет необходимости даже просто приступить к посещению учебного курса для того, чтобы быть включенным в БД. Таким образом, исходная аномалия вставки исключена с помощью декомпозиции.
Обновление. При использовании отношения КОНСУЛЬТАНТ проблема возникла на этапе изменения консультантом номера телефона миссис ДжонсГ на 7777. Результатом этого изменения явилось появление в БД двух различных телефонных номеров для телефона, установленного в комнате 120DH. В БД Коне телефонные номера располагаются в отношении R2, и каждая комната может иметь только один телефонный номер, назначенный расположенному в этой комнате телефонному аппарату. Следует помнить, что номер Кном является первичным ключом отношения R2, а значения первичного ключа по определению должны быть уникальными. Для модификации телефонного номера ДжонсГ следует в кортеже отношения R2, в котором Khom=120DH, изменить номер Тном на 7777. Обратите внимание на то обстоятельство, что это действие заключается в изменении телефонного номера для комнаты, так что для всех живущих в этой комнате студентов телефонный номер также будет изменен. Таким образом, исходная аномалия обновления устраняется с помощью НФБК-проектирования.
Необходимо еще раз подчеркнуть, что устранение аномалии обновления базируется на том предположении, что СУБД, в среде которой будет создаваться БД, не допускает дублирования значений первичных ключей. К сожалению, во многих СУБД, которыми оснащаются микрокомпьютеры, допускается дублирование ключевых значений, и пользователь сам вынужден следить за этим с помощью применения соответствующих программных методов. Это тот самый случай, когда удачное проектирование БД может быть разрушено недостатками используемой СУБД. Полностью реализованная СУБД не должна допускать дублирования значений первичных ключей.
Удаление. Когда отношение КОНСУЛЬТАНТ использовалось в качестве БД, удаление кортежа, включавшего значения Сном=4756 и Kypc*MUS389, привело к исчезновению из БД студента с номером 4756.
Этого не может произойти в случае БД Коне, поскольку информация об оценках и информация о студентах общего характера разнесена в два различных отношения (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 для случая БД
Коне более сложны по сравнению со случаем единичного отношения1).
. USE КОНСУЛЬТАНТ . DISPLAY THOM FOR СНОМ = 3567 OFF 2136 2136 2136 а"
. SELECT PRIMARY . USE R4 . SELECT SECONDARY . USE R2 . JOIN TO TEMPI FIELDS S.THOM FOR ; P.CHOM = 3567 .AND. P.KHOM = S.KHOM . USE TEMPI . LIST OFF 2136.
. USE . DELETE FILE TEMPI FILE HAS BEEN DELETED
6
Рис. 3.7. Запросы при использовании dBase II на получение номера телефона студента с номером 3567: а - для случая отношения КОНСУЛЬТАНТ; б - для случая БД Коне.
Другая декомпозиция отношения КОНСУЛЬТАНТ
В разд. 3.4 декомпозиция отношения КОНСУЛЬТАНТ на три отношения была начата проекцией, порождаемой ФЗ:
Кном -> Тном.
Указанная ФЗ была выбрана потому, что являлась последней в цепочке ФЗ, выявленных на рис. 3.2:
Сном -> Кном -> Тном.
^ Тем, кто не знаком с оператором Join, использованным на рис. 3.7, рекомендуется ознакомиться с соответствующим материалом, приведенным в прил. А.
Внимательное изучение представленных на рис. 3.2 ФЗ показывает, что на этом рисунке присутствует другая цепочка зависимостей с таким же их числом
Сном -> Тном -> Кном.
Здесь крайней правой ФЗ является Тном -> Кном. Если эта ФЗ выделяется первой из отношения КОНСУЛЬТАНТ, то в итоге будет получена следующая БД в НФБК:
R2 (Тном. Кном)
R3 (Сном.Курс.Семестр.Опенка) И4(Сном.СФам)
Эта БД столь же корректна, как и БД, приведенная на рис. 3.5. Единственное отличие состоит в том, что номер Тном стал выполнять роль более важную, нежели Кном. Тном в данной ситуации используется в качестве первичного ключа для отношения R2 (а не Кном) и атрибута, связывающего R4 и R2. Два различных решения одной проблемы являются прямым результатом взаимной зависимости, существующей между атрибутами Тном и Кном. Какое из двух решений является “лучшим “ определяется выбором проектировщика и зависит до некоторой степени от того, как консультант планирует использовать БД.
Некоторые комментарии к декомпозиционному алгоритму проектирования
В разд. 3.4 было сказано, что в процессе проектирования с помощью проекции декомпозицию следует осуществлять путем поиска цепочек ФЗ, а именно:
А -> В, В -> С
с последующим проецированием, порождаемым ФЗ, замыкающей цепочку. В данном случае первой ФЗ будет В -> С. Другой путь обоснования процедуры выбора состоит в утверждении, что всеми средствами следует избегать выбора ФЗ, зависимостная част которой сама - целиком или частично - являете: детерминантом другой ФЗ.
ИСХОДНЫЕ Данные
Отношение: R(A,B,C)
*3: А -> В
В -> С
(А -> С также должно быть справедливо)
ОЛИН ВОЗМОЖНЫЙ ПРОЕКТ
R1(A,C)R2(A,B)
А -> СА -> В
Корректные экземпляры R1 и R2
АС9843АС9843R1R1АВ9822АВ9822R2R2
А
С
9
8
4
3
А
С
9
8
4
3
R1
R1
А
В
9
8
2
2
А
В
9
8
2
2
R2
R2
Рис. 3.8. Экземпляры отношений, удовлетворяющие ФЗ отношений R1 и R2, но противоречащие ФЗ, представленной в исходных спецификацияхРис. 3.8. Экземпляры отношений, удовлетворяющие ФЗ отношений R1 и R2, но противоречащие ФЗ, представленной в исходных спецификациях
Рис. 3.8. Экземпляры отношений, удовлетворяющие ФЗ отношений R1 и R2, но противоречащие ФЗ, представленной в исходных спецификациях
Рис. 3.8. Экземпляры отношений, удовлетворяющие ФЗ отношений R1 и R2, но противоречащие ФЗ, представленной в исходных спецификациях
Если в вышеприведенном случае положить, что обсуждаемое отношение имеет вид R(A,B,C)иФЗ А->В выбрана для проекции в первую очередь, то полученные в результате отношения будут R1(A,C) и R2(A,B). Хотя оба эти отношения находятся в
НФБК, со всей отчетливостью обнаруживается следующая проблема:
Ни отношение R1(A,C), ни R2(A,B) автономно не содержат атрибуты, присутствующие в ФЗ В -> С, которая является ФЗ исходного отношения. Эта зависимость утеряна в процессе проектирования. С практической точки зрения это означает, что если приведенные выше отношения R1 и R2 будут использованы для создания БД, то нельзя будет утверждать, что некорректные связи между В и С не будут привнесены в БД. Рис. 3.8 иллюстрирует выявленную проблему. При соединении R1 и R2 по атрибуту А два значения С (3 и 4) могут быть соотнесены с В, что противоречит ФЗ, утерянной в процессе проектирования.
Проблема в данном примере возникает из-за проекции, порожденной ФЗ, зависимостная часть которой сама является детерминантом другой ФЗ. При использовании правила цепочки эта проблема не возникает.
Другим случаем возможной потери ФЗ в процессе проектирования является ситуация, в которой один атрибут зависит от двух различных детерминантов. Пусть для отношения R(A,B,C) определены зависимости, показанные на рис. 3.9.
Рис. 3.9. Два детерминанта с одним и тем же зависимым атрибутом
Это отношение не находится в НФБК, так как имеется только один возможный ключ <А,С>, в то время как детерминантами являются <А> и <С>. Правило цепочек здесь неприложимо по причине их отсутствия. Кроме того, если одна из ФЗ будет выделена обычным способом, то другая будет потеряна. Например, при выделении из R(A,B,C) зависимости А -> В будут получены отношения R1(A,C) и R2(A,B), ни одно из которых не будет содержать зависимости С -> В. Наоборот, при первоочередном выделении С -> В будет утеряна зависимость А -> В. Возникла ситуация, обязывающая проектировщика найти способ разбиения отношения R(A,B,C) на
R1 (А,В) и R2(C,B), не приводящий к утере ни одной ФЗ. Этот путь не соответствует стандартному методу декомпозиции, но может привести к лучшему результату. Единственное, что может сделать проектировщик, столкнувшись с указанной ситуацией, это проверить три возможных набора отношений и оценить, какой из трех наиболее соответствует нуждам предприятия. В частности, полученные в последнем случае отношения необходимо проверить на предмет возникновения проблем в случае соединения двух итоговых отношений при поиске данных на этапе эксплуатации окончательного варианта базы.
Второй метод разбиения отношения, обсуждение которого велось с привлечением рис. 3.9, хотя и основан на подходе к проектированию, отличном от декомпозиции, тем не менее используется многими проектировщиками. В основе подхода, называемого некоторыми методом синтеза, лежит утверждение (в своей простейшей форме), что необходимо все ФЗ с одинаковыми детерминатами выделять в группы и каждой группе отводить свое собственное отношение. Получаемые отношения проверяются на их соответствие НФБК. В последнем примере были две зависимости с различными детерминантами. Согласно методу синтеза каждой ФЗ следует выделить ее собственное отношение - R1(A,B) и R2(C,B). Метод синтеза может быть использован как самостоятельно, так и в сочетании с методом декомпозиции. В книге акцент делается на метод декомпозиции (также называемый методом проекции), а метод синтеза используется как альтернатива при поиске выхода из затруднительных ситуаций, подобных разобранной выше. Как будет показано в гл. 5, зависимости, сходные с той, которая приведена на рис. 3.9, могут возникнуть в жизненных ситуациях реального мира.
Тот факт, что существуют различные методы проектирования, которые могут быть использованы как порознь, так и до некоторой степени смешанным образом, свидетельствует о том, что проектирование БД является частично наукой, а частично искусством. Возможность развития нескольких вполне “законных“ проектов, имеющих общую исходную точку, является неотъемлемым фактором области проектирования БД. Часть процесса проектирования заключается в оценке
нескольких альтернатив с целью выявления наиболее отвечающей нуждам предприятия.
R<A,B,C,D)(а)R<A,B,C,D)(а)R(A,B)R(A,B)(д)(д)(е)(е)Рис. 3.10. Данные к задаче 1Рис. 3.10. Данные к задаче 1
R<A,B,C,D)
(а)
R<A,B,C,D)
(а)
R(A,B)
R(A,B)
(д)
(д)
(е)
(е)
Рис. 3.10. Данные к задаче 1
Рис. 3.10. Данные к задаче 1
Задачи к гл. 3
На рис. 3.10 приведены диаграммы функциональных зависимостей для нескольких отношений. Для
каждого отношения требуется определить все детерминанты и все возможные ключи. Определите те отношения, которые находятся в НФБК. Если отношение не в НФБК, приведите его к нормальной форме, используя алгоритм декомпозиции.
Определите функциональные зависимости между атрибутами отношения ТЕЛ НОМ, рассмотренного в задаче 4 в конце гл. 2.
Руководство супермаркета желает разработать БД, предназначенную для хранения информации о счетах покупателей. Информация, касающаяся каждого покупателя, должна включать в себя следующее: номер счета, фамилию, адрес, номер телефона, кредитоспособность (высокая, средняя, низкая, слабая) и сведения об уплате налогов. Изобразите диаграмму ФЗ, используя соответствующие атрибуты и выделяя сделанные предположения. Получите для БД отношения в НФБК.
Секретарь государственного учреждения проектирует БД, предназначенную для хранения информации обо всех автомобилях, зарегистрированных в штате. Информация, хранение которой предполагается, включает в себя регистрационный номер, номер лицензии, марку, адрес владельца, название страховой компании, номер страхового полиса, округ, в котором зарегистрирован автомобиль, и дату последней регистрации. Разработайте диаграммы ФЗ для соответствующих атрибутов.
НЕКОТОРЫЕ МОДИФИКАЦИИ АЛГОРИТМА ПРОЕКТИРОВАНИЯ
Избыточные функциональные зависимости
Алгоритм проектирования БД, описанный в общих чертах в разд. 3.4, кажется на первый взгляд довольно естественным, однако он не свободен от некоторых внутренних проблем. Одна проблема заключается в том, что процесс декомпозиции может осложниться в результате присутствия избыточных ФЗ.
Зависимость, не заключающая в себе такой информации, которая не могла бы быть получена на основе других зависимостей из числа использованных при проектировании БД, называется избыточной ФЗ. Поскольку избыточная ФЗ нс содержит уникальной информации, она может быть удалена из набора ФЗ без отрицательного воздействия на результаты. Избыточные ФЗ удаляются на начальном этапе проектирования до применения алгоритма декомпозиции.
Транзитивные зависимости
Одним из простейших путей появления в наборе ФЗ избыточных зависимостей является генерация ФЗ с помощью концепции транзитивной зависимости. Транзитивная зависимость определяется следующим образом
Если А -> В и В -> С, то А -> С - транзитивная зависимость.
Два момента следует подчеркнуть. Во-первых, транзитивная зависимость А -> С, приведенная в определении выше, является вполне корректной зависимостью. С ней не связано ничего сомнительного. Во-вторых, если А -> В, В -> С и А -> С входят в набор ФЗ, следовательно, А -> С является избыточной и ее использование в процессе проектирования не требуется. Действительно, транзитивная зависимость А -> С причинит больше вреда, чем пользы при проектировании, и ее следует исключить из набора перед началом проектирования.
На рис. 4.1 приведены примеры того, как может быть упрощен набор ФЗ при помощи исключения транзитивных зависимостей. На рис. 4.1(a) представлен исходный набор ФЗ до начала проектирования. На рис. 4.1 (г) показан набор неизбыточных ФЗ, выделенных путем удаления всех транзитивных зависимостей из исходного набора. На рис. 4.2 показана процедура декомпозиции и получения набора НФБК-отношений.
(а) Исходный набор ФЗ(а) Исходный набор ФЗ(б) А-> Е удалена, т. к. А-*С и С -> Е(б) А-> Е удалена, т. к. А-*С и С -> ЕА -> В А -> С А -> Е В -> С В -> Е С -> Е
(а) Исходный набор ФЗ
(а) Исходный набор ФЗ
(б) А-> Е удалена, т. к. А-*С и С -> Е
(б) А-> Е удалена, т. к. А-*С и С -> Е
А -> В А -> С В -> С В -> Е
С -> Е
А -> В А -> С В -> С С -> Е
(г) А->С удалена, т.к. А-> В и В-*С и в итоге получен неизбыточный набор ФЗ(г) А->С удалена, т.к. А-> В и В-*С и в итоге получен неизбыточный набор ФЗРис. 4.1. Удаление транзитивных зависимостейРис. 4.1. Удаление транзитивных зависимостейА -> В
(г) А->С удалена, т.к. А-> В и В-*С и в итоге получен неизбыточный набор ФЗ
(г) А->С удалена, т.к. А-> В и В-*С и в итоге получен неизбыточный набор ФЗ
Рис. 4.1. Удаление транзитивных зависимостей
Рис. 4.1. Удаление транзитивных зависимостей
В -> С С -> Е
1.Диаграмма ФЗ при отсутствии избыточности1.Диаграмма ФЗ при отсутствии избыточностиR(A,B,C,E)R(A,B,C,E)
1.Диаграмма ФЗ при отсутствии избыточности
1.Диаграмма ФЗ при отсутствии избыточности
R(A,B,C,E)
R(A,B,C,E)
.Извлечение зависимости С -^ Е, так как она является последней в цепочке
R1(С,Е>R2(A,B,C)R1(С,Е>R2(A,B,C)
R1(С,Е>
R2(A,B,C)
R1(С,Е>
R2(A,B,C)
.Извлечение В*С из R2 (А, В, С)
R1<С,Е)
R3(B,C)
R4(A,B)
Отношения R1, R3 и R4 находятся в НФБК. При небольшом навыке НФБК - отношения из части 3 могут быть непосредственно получены из части 1.
Рис. 4.2. Получение набора НФБК-отношений из отношения, приведенного на рис. 4.1
Добавление1) атрибутов в ФЗ
Второй путь возникновения избыточных ФЗ связан с концепцией добавления. Эта форма избыточности имеет несколько видов, из которых только два самые простые, но и крайне полезные, обсуждаются ниже.
Вид первый формулируется следующим образом (здесь А, В и Z - атрибуты, каждый из которых может быть составным):
Если А -> В, то A,Z -> В является корректной, но избыточной ФЗ. Атрибут Z был добавлен к детер-
1) Мы приняли перевод термина “augmentation11 как “добавление11. В отечественной литературе используется также термин “пополнение". - Прим. ред.
минанту А без привнесения какой-либо новой информации в процесс проектирования.
Второй вид возникает в случае добавления к обеим частям данной ФЗ одного и того же атрибута с целью формирования новой зависимости:
Если А -> В, то A,Z -> B,Z является корректной, но избыточной зависимостью.
На рис. 4.3 приведены примеры обеих форм добавления.
Добавление ФЗ (избыточная)Добавление ФЗ (избыточная)
Добавление ФЗ (избыточная)
Добавление ФЗ (избыточная)
Рис. 4.3. Примеры добавления
Правила вывода
Определения транзитивной зависимости и концепции добавления, данные выше, касаются двух правил вывода из имеющихся шести. Эти правила могут быть использованы для уменьшения, модификации исходно-
го набора ФЗ и получения другого, эквивалентного ему набора ФЗ. Еще три правила вкратце рассматриваются ниже. Полное описание всех правил можно найти в большинстве более фундаментальных книг1).
Два наиболее простых для понимания правила вывода связаны с объединением и декомпозицией ФЗ, которые определяются следующим образом:
Объединение ФЗ; если А->В и А->С, то А->В,С Декомозиция ФЗ; если А->В,С то А->В и А->С
На рис. 4.4 дается графическое представление каждого утверждения, рис. 4.5 иллюстрирует способы преобразования исходного набора ФЗ в менее сложный набор неизбыточных ФЗ с помощью процедур объединения, декомпозиции и добавления.
Последнее из обещанных правил вывода называется псевдотранзитивностью.
Если X -> Y и Y,W -> Z, то X,W -> Z является избыточной в силу псевдотранзитивности.
Графический пример на псевдотранзитивность приведен на рис.4.6. Этот тип избыточности возникает в тех случаях, когда в получаемых ФЗ обнаруживаются составные детерминанты. Конкретный пример, иллюстрирующий данную ситуацию, будет приведен в следующей главе при рассмотрении учебной БД.
Для большинства людей графические формы диаграмм зависимостей упрощают выявление избыточных ФЗ; однако в тех случаях, когда число атрибутов и ФЗ достаточно велико, графический подход может оказаться слишком громоздким. В этом случае можно воспользоваться каким-либо известным математическим алгоритмом поиска избыточных зависимостей. Эти алгоритмы не слишком сложны для применения.
^ Полное множество правил вывода состоит из трех аксиом Армстронга - рефлексивности (для любого множества атрибутов А и X АХ -> X) и уже обсуждавшихся транзитивности и дополнения, а также трех следующих из этих аксиом правил объединения, декомпозиции и псевдотранзитивности, которые автор обсуждает ниже. Более подробную информацию о свойствах правил вывода можно найти, например, в книге Дж. Ульмана “Основы систем баз дан- ных“ - M., Финансы и статистика, 1983, с. 156-164. Прим. ред.
(а)
Рис. 4.4. Примеры на объединение и декомпозицию
Минимальное покрытие
Набор неизбыточных ФЗ, полученный путем удаления всех избыточных ФЗ из исходного набора с помощью б правил вывода, называется минимальным покрытием.
А -> В,СА -> DА -> КК -> СВ -> DВ,С -> DА -> В,СА -> DА -> КК -> СВ -> DВ,С -> D(а) Исходный набор ФЗ(а) Исходный набор ФЗА -> В,С А -> DА -> К К -> СВ -> DА -> В,С А -> DА -> К К -> СВ -> D(б) В, С-^ D удалена (добавление B-*D).(б) В, С-^ D удалена (добавление B-*D).А -> ВА -> С А -> D А -> КК -> С В -> DА -> ВА -> С А -> D А -> КК -> С В -> D
А -> В,С
А -> DА -> КК -> СВ -> D
В,С -> D
А -> В,С
А -> DА -> КК -> СВ -> D
В,С -> D
(а) Исходный набор ФЗ
(а) Исходный набор ФЗ
А -> В,С А -> D
А -> К К -> С
В -> D
А -> В,С А -> D
А -> К К -> С
В -> D
(б) В, С-^ D удалена (добавление B-*D).
(б) В, С-^ D удалена (добавление B-*D).
А -> В
А -> С А -> D А -> К
К -> С В -> D
А -> В
А -> С А -> D А -> К
К -> С В -> D
А^В, С замещена А-> В & А^С (декомпозиция)
А -> В
А -> К К -> С
В -> D
А^>С и А -** О заменяется на А -^ К & К-^-С и А->В & В
->*0 (транзитивность)
Рис. 4.5. Упрощение диаграммы ФЗ с помощью правил вывода
К сожалению, минимальное покрытие не всегда является уникальным, поскольку порядок, в котором осуществляется процедура удаления избыточных ФЗ, мо-^
жет оказать влияние на полученное минимальное покрытие. Чтобы убедиться в этом, читателю достаточно обратиться к рис. 3.2 и проверить, что в представленном случае проектирования существуют два минимальных покрытия. Первое минимальное покрытие получается при удалении из исходного набора зависимости Сном -> Тном, а второе - при удалении Сном -> Кном. Использование этих двух минимальных покрытий ведет к построению тех же самых двух БД, проектирование которых обсуждалось выше. В заключение следует подчеркнуть один важный момент, связанный с удалением избыточных ФЗ из исходного набора: избыточные ФЗ следует удалять по одной, каждый раз заново анализируя новый набор на предмет присутствия в нем избыточных ФЗ.
Рис. 4.6. Графические примеры на псевдотранзитивность
Эта процедура завершается, как только не останется ни одной избыточной ФЗ, оставшийся набор является минимальным покрытием.
Пересмотренный алгоритм проектирования
Следующий обобщенный алгоритм декомпозиции будет использоваться до конца книги:
Построение универсального отношения для БД.
Определение всех ФЗ, существующих между атрибутами универсального отношения.
Удаление всех избыточных ФЗ из исходного набора ФЗ с целью получения минимального покрытия. Эта процедура проводится путем поочередного удаления избыточных ФЗ с последующей проверкой получаемого на каждом шаге набора ФЗ на наличие хотя бы одной избыточной ФЗ.
Использование ФЗ из минимального покрытия для декомпозиции универсального отношения в набор НФБК-отношений. Далее должен быть применен алгоритм декомпозиции, описанный в разд. 3.4.
Если может быть получено более чем одно минимальное покрытие, осуществляется сравнение результатов, полученных на основе различных минимальных покрытий, с целью определения варианта, лучше других отвечающего требованиям предприятия.
При использовании алгоритма декомпозиции (Шаг 4) следует помнить о нежелательности проекции, порождаемой ФЗ, у которой зависимостная часть является детерминантом другой ФЗ; также повышенное внимание требуется в тех случаях, когда зависимостная часть ФЗ зависит более чем от одного детерминанта. В любом из этих случаев может быть утеряна ФЗ из БД. Если в процессе декомпозиции достигнуто состояние, в котором проецирование, невлекущее за собой потерь ФЗ, становится невозможным, проектировщик должен будет сделать выбор из двух альтернатив: (1) выбор оставшихся ФЗ и создание одного отношения для каждых детерминанта и набора зависящих от него атрибутов; (2) изменение порядка ранее проведенных декомпозиций, ведь алгоритм проектирования не ведет к единственному решению.
Проверка отношений на завершающей фазе их проектирования
После завершения разработки НФБК-отношений, рассматриваемых уже в качестве окончательного проекта, полученный набор необходимо проконтролировать на предмет наличия невыявленных проблем.
Составляются списки ФЗ для каждого отношения. Эти списки проверяются по двум направлениям: во-первых, одна и та же ФЗ не должна появляться более чем в одном отношении; и во-вторых, набор ФЗ, полученный в результате проектирования, должен в точности совпадать с набором, присутствующим в минимальном покрытии, полученном перед началом проектирования. В противном случае, необходимо показать возможность получения итогового набора ФЗ из минимального покрытия с помощью правил вывода. Если хотя бы одна из этих проверок окажется недостоверной, следует проанализировать процесс проектирования для выявления ошибок и/или рассмотреть другие варианты проектирования.
Осуществляется проверка на присутствие избыточных отношений. Отношение является избыточным, если (а) все атрибуты в избыточном отношении могут быть найдены в одном другом отношении проектного набора; (б) все атрибуты в избыточном отношении могут быть найдены в отношении, которое может быть получено из других отношений предложенного проектного набора с помощью серии JOIN-операций над этими отношениями. Если устанавливается избыточность отношения, его следует исключить из проектного набора. Примеры обоих типов избыточных отношений приведены ниже.
Для примера, иллюстрирующего первый тип избыточности, полагаем, что набор проектных отношений имеет вид:
R1(A,B) R2(B,C,Y,Z) R3(A,B,K)
Отношение R1 является избыточным, так как все его атрибуты присутствуют в отношении R3.
Для иллюстрации избыточности второго типа положим, что предлагаемый проектный набор имеет вид:
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.
Рассмотрение отношений с практической точки зрения. Изучается характер использования отношений в конструируемой БД и определяется будут ли они поддерживать те типы запросов и операций обновления, которые предполагается использовать.
Задачи к гл. 4
Представьте каждую ФЗ, показанную на рис. 4.7, в математической форме так, как это сделано на рис. 4.1. Затем шаг за щагом редуцируйте диаграмму посредством удаления всех транзитивных зависимостей.
Рис. 4.7. Диаграмма ФЗ для задачи 1
На рис. 4.8 идентифицируйте все ФЗ, избыточность которых является следствием добавления.
Может ли диаграмма, представленная справа на рис. 4.9, быть получена из диаграммы, представленной в левой части того же рисунка, с помощью правил вывода, обсуждавшихся в настоящей главе?
Рис. 4.8. Диаграмма ФЗ для задачи 2Рис. 4.8. Диаграмма ФЗ для задачи 2Рис. 4.9. Диаграмма ФЗ для задачи 3Рис. 4.9. Диаграмма ФЗ для задачи 3
Рис. 4.8. Диаграмма ФЗ для задачи 2
Рис. 4.8. Диаграмма ФЗ для задачи 2
Рис. 4.9. Диаграмма ФЗ для задачи 3
Рис. 4.9. Диаграмма ФЗ для задачи 3
Предположим, что в результате проектирования были получены следующие четыре НФБК-отношения:
R1 (Слж-фам, С лж-адрес, Возраст, Пол, Начальник-фам) R2 (Начал ьник-фам, Отдел)
R3 (Слж-фам, Отдел)
R4 (Отдел, Отдел-Т ел-номер, Отдел-адрес)
Одно из этих отношений является избыточным. Укажите это отношение и поясните причину.
Если перечисленные в задаче 4 отношения находятся в НФБК, то какие из следующих утверждений являются истинными и какие ложными? Дайте обоснование сделанных выводов:
служащий может иметь более одного руководителя;
служащий может работать только в одном отделе;
в каждом отделе имеется только один телефон;
отделу выделяется только один телефонный номер;
у каждого руководителя имеется телефон;
служащие, не являющиеся руководителями, не имеют телефонов.
УЧЕБНЫЙ ПРИМЕР ПРОЕКТИРОВАНИЯ БД
Ставится задача спроектировать БД для секретаря кегельной лиги небольшого городка, расположенного на Среднем Западе. В ней секретарь будет хранить всю информацию, относящуюся к кегельной лиге, а средствами СУБД - формировать еженедельные отчеты о состоянии лиги. Специальный отчет предполагается формировать в конце сезона. БД будет реализована как в dBASE III, так и в R:base 5000. Полное описание данных, доступ к которым хочет иметь секретарь при формировании отчетов, дается в следующих разделах.
Постановка задачи
Секретарю понадобятся имена-и-фамилии, телефонные номера, и адреса всех игроков лиги. Так как в лигу могут входить только жители городка, нет необходимости хранения для каждого игрока названия города и ZIP-кода. Интерес представляют число набранных очков каждым игроком в еженедельной серии из трех встреч, в которых он принял участие, и его текущая результативность (среднее число набираемых очков в одной встрече). Секретарю необходимо знать для каждого игрока название команды, за которую он выступает, и имя-и-фамилию капитана каждой команды. Помимо названия секретарь планирует назначить каждой команде уникальный номер.
Исходные значения результативности каждого игрока необходимы как при определении в конце сезона игрока, достигшего наибольшего прогресса в лиге, так и при вычислении гандикапа для каждого игрока на первую неделю нового сезона. Лучшая игра каждого игрока и лучшие серии потребуются при распределении призов в конце сезона.
Секретарь планирует включать в еженедельные отчеты информацию об общем числе набранных очков и общем числе проведенных игр каждым игроком - эта информация используется при вычислении их текущей результативности и текущего гандикапа. Используемый в лиге гандикап составляет 75% от разности между 200 и результативностью игрока, при
5-1164
этом отрицательный гандикап не допускается. Если результатом вычисления гандикапа является дробная величина, то она усекается. Перерасчет гандикапа осуществляется каждую неделю.
На каждую неделю каждой команде требуется назначать площадку, на которой она будет выступать. Эту информацию не нужно хранить в БД (Соперники выступают на смежных площадках).
Наконец, в БД должна содержаться вся информация, необходимая для проведения вычислений по получению положения команд. Команде засчитывается одна победа за каждую игру, в которой ей удалось набрать больше очков (выбить больше кеглей) (с учетом гандикапа), чем команде соперников. Точно также команде засчитывается одно поражение за каждую встречу, в которой эта команда выбила меньшее число кеглей, чем команда соперников. Команде также засчитывается одна победа (поражение) в случае, если по сравнению с командой соперников ею набрано больше (меньше) очков за три встречи, состоявшиеся на неделе. Таким образом на каждой неделе разыгрывается 4 командных * очка (побед или поражений). В случае ничейного результата каждая команда получает 1/2 победы и 1/2 поражения. В случае неявки более чем двух членов команды, их команде автоматически засчитывается 4 поражения, а команде соперников - 4 победы. В общий результат команде, которой засчитана неявка, очки не прибавляются даже если явившиеся игроки в этой встрече выступили; однако в индивидуальные показатели - число набранных очков и проведенных встреч - будут внесены соответствующие изменения.
Определение атрибутов универсального отношения
В результате нескольких обсуждений с участием секретаря в качестве наиболее вероятных кандидатов на включение в универсальное отношение были определены перечисленные ниже атрибуты (а также накладываемые ограничения). Описание каждого атрибута сопровождается как коротким описательным именем, подходящим для использования при реализации БД, так и еще более короткой двухсимвольной мнемоникой, могущей быть использованной в диаграммах ФЗ.
Двухсимвольный формат выбран для того, чтобы излишне не перегружать ФЗ-диаграммы, сохраняя при этом до некоторой степени мнемонику источника возникновения атрибута.
Атрибут
Комментарий.
Nb: Tnumb
(НомКоманды) Номер команды. Команды нумеруются последовательно, начиная с номера 1.
Tn: Tname
(НазвКоманды) Название команды. Каждая команда лиги носит название, например, “PinBusters“. Названия уникальные.
Bn: Bname
(ФамИгрока) Фамилия-и-имя игрока. Так как лига маленькая, предполагается, что не может быть двух игроков с одинаковыми именем-и-фамилией.
Av: Bavg
Результативность данного игрока. Этот показатель вычисляется по формуле
число выбитых кеглей/число встреч, имевших место до настоящего момента. Полученное значение усекается до целого.
Hk: Hndk
Гандикап игрока перед каждой игрой. Это целое число, перерасчет которого осуществляется каждую неделю.
Bg: Bgame
Общее число встреч, в которых участвовал игрок к настоящему моменту, Обычно каждый игрок проводит три встречи за один вечер.
Wn: Wins
Общее число побед данной команды за сезон.
Ls: Loss
Общее число поражений данной команды за сезон.
Tp: Tpins
Общее число набранных данной командой очков за сезон.
Ln: Lane
(Площадка) Номер площадки, назначенной данной команде на данную не-
делю. Этот номер также определяет и соперника. Соперниками будут команды, которым назначены площадки с номерами 1 и 2, 3 и 4, и т.д.
Ср: Captn
(Капитан) Фамилия-и-имя капитана команды. В каждой команде только один капитан.
Ph: Phone
(ТелНомер) Номер телефона игрока. Несколько игроков могут иметь один номер телефона.
St: Stret
(Адрес) Улица, по которой проживает игрок. Все адреса относятся к одному небольшому городку. По одному адресу может проживать более чем один игрок.
Bp: Bpins
Общее число очков, набранных игроком за сезон.
Sa: Stavg
(Результативность) Результативность игрока на начало сезона. Может быть только целым числом.
Hg: Higam
Число набранных очков во встрече, лучшей в сезоне для данного игрока.
Hs: Hiser
Число набранных очков в серии из трех встреч, лучшей в сезоне для данного игрока.
Wk: Week
(Неделя) Порядковый номер недели в сезоне. Это значение вначале равно 1 и увеличивается на 1 каждую неделю.
Gl: Gamel
(Игра!) Число набранных игроком очков в первой встрече недели.
G2: Game2
(Игра2) Число набранных игроком очков во второй встрече недели.
G3: Game3
(ИграЗ) Число набранных игроком очков в третьей встрече недели.
После некоторых размышлений было решено, что некоторые из перечисленных выше атрибутов в БД
храниться не будут. Исключенными атрибутами являются: 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)
Диаграммы функциональных зависимостей
Шаг 2 пересмотренного алгоритма проектирования состоит в определении всех ФЗ между атрибутами универсального отношения. На рис. 5.1 показана диаграмма функциональных зависимостей (диаграмма ФЗ) универсального отношения, полученная на основании сформулированной проблемы.
Исходный Набор Проектных ФЗИсходный Набор Проектных ФЗТп <—> Nb Tn <--> Ср Ср <-> Nb Bn -> Nb,St,Ph,Sa Bn,Wk -> Gl,G2,G3,Ln Ln,Wk -> Nb Wk,Nb -> LnТп <—> Nb Tn <--> Ср Ср <-> Nb Bn -> Nb,St,Ph,Sa Bn,Wk -> Gl,G2,G3,Ln Ln,Wk -> Nb Wk,Nb -> LnУже ИсключенныеТранзитивные ЗависимостиУже ИсключенныеТранзитивные ЗависимостиBn -> TnBn -> Ср Ln,Wk -> Cp Ln,Wk -> TnBn -> TnBn -> Ср Ln,Wk -> Cp Ln,Wk -> Tn
Исходный Набор Проектных ФЗ
Исходный Набор Проектных ФЗ
Тп <—> Nb Tn <--> Ср Ср <-> Nb Bn -> Nb,St,Ph,Sa Bn,Wk -> Gl,G2,G3,Ln Ln,Wk -> Nb Wk,Nb -> Ln
Тп <—> Nb Tn <--> Ср Ср <-> Nb Bn -> Nb,St,Ph,Sa Bn,Wk -> Gl,G2,G3,Ln Ln,Wk -> Nb Wk,Nb -> Ln
Уже Исключенные
Транзитивные Зависимости
Уже Исключенные
Транзитивные Зависимости
Bn -> Tn
Bn -> Ср Ln,Wk -> Cp Ln,Wk -> Tn
Bn -> Tn
Bn -> Ср Ln,Wk -> Cp Ln,Wk -> Tn
Рис. 5.1. Исходная диаграмма ФЗ для БД секретаря кегельной лиги.
На шаге 3 алгоритма осуществляется исключение всех избыточных ФЗ из набора, определенного для универсального Отношения, с целью получения минимального покрытия. Представленные на диаграмме (рис. 5.1) ФЗ включают в свой состав несколько транзитивных зависимостей. Другие транзитивные зависимости могут быть легко получены из исходного набора ФЗ. Типичные транзитивные зависимости, которые могут появиться, перечислены на рис. 5.1 в
графе уже исключенных зависимостей. Они не были включены в ФЗ-диаграмму единственно по причине удобства представления. Удаление этих избыточных зависимостей возможно в любом порядке.
R(Nb,Bn,Ln,Cp,Ph,St,Sa,Wk,Gl,G2,G3)
ФЗ: Nb <—> Tn Nb <—> Ср Wk,Ln -> Nb Wk,Nb -> Ln Bn,Wk -> G1,G2,G3 Bn -> Nb,St,Ph,Sa
Рис. 5.2. Диаграмма ФЗ для минимального покрытия
К числу нестандартных ситуаций, касающихся транзитивных зависимостей, относится случай “циклического набора взаимных зависимостей" между тремя атрибутамиСр,Nbи Тп
Nb <->Ср
Ср <—>Тп
Тп <->Nb
При исключенииодной изэтих трех взаимных за
висимостей оставшиеся две перестают быть избыточ-
ными. В этом особом случае непринципиально, какая из трех зависимостей удаляется, так как вне зависимости от выбора, три атрибута Ср, Nb и Тп сохраняют свое место в том же отношении и все три будут для этого отношения возможными ключами. В нашем случае удаленной взаимной зависимостью является Ср <—> Тп.
Вторая избыточная ФЗ, отмеченная на рис. 5.1, обусловлена псевдотранзитивностью. Так как Bn -> Nb и Nb,Wk -> Ln, то согласно правилу псевдотранзитивности, Bn,Wk -> Ln. Это означает, что последняя ФЗ является избыточной и может быть удалена. Других избыточных ФЗ на рис. 5.1 нет. ФЗ-диаграмма для минимального покрытия приведена на рис. 5.2.
Получение путем редукции набора НФБКотношений
Шаг 4 процедуры проектирования включает в себя переход с помощью редукции от универсального отношения к набору НФБК-отношений. Универсальное отношение R, чья ФЗ-диаграмма приведена на рис. 5.2, не находится в НФБК. Сравнение возможных ключей и детерминантов отношения R показывает их несовпадение.
Возможные ключи в R Детерминанты в R
<Bn,Wk><Bn,Wk><Вп>
<Bn,Wk>
<Bn,Wk>
<Bn,Wk>
<Ln,Wk>
<Nb> <Tn> <Cp>
В начальной фазе редукции отношения R выполняется проецирование универсального отношения, порождаемое всеми ФЗ, содержащими атрибут Nb в качестве детерминанта. Такими ФЗ являются
Nb <-> СрNb <--> Тп
результатом операции является получение отношений R1 и R2, показанных на рис. 5.3.
Рис. 5.3. РезультатыРис. 5.3. РезультатыФЗ:Nb <--> TnNb <--> СрФЗ:Nb <--> TnNb <--> Ср(б) R2(Nb,Tn,Cp)проекции R2 из R
Рис. 5.3. Результаты
Рис. 5.3. Результаты
ФЗ:
Nb <--> Tn
Nb <--> Ср
ФЗ:
Nb <--> Tn
Nb <--> Ср
Отношение R2 находится в НФБК, так как Ср, Nb и Тп являются единственными детерминантами в R2 и каждый - возможный ключ. Таким образом, отношение R2 является частью окончательного набора. Отношение R1 не находится в НФБК, так как сравнение детерминантов и возможных ключей показывает их неидентичность
Возможные ключи в R1 Детерминанты в R1
<Bn,Wk><Bn,Wk><Вп>
<Bn,Wk>
<Bn,Wk>
<Bn,Wk>
<Nb,Wk>
<Ln,Wk>
R1 необходимо подвергнуть дальнейшему преобразованию. На этой стадии особое внимание необходимо уделять атрибуту Nb. Он является зависимым в R1, имеющим два различных детерминанта. Как было указано в разд. 3.7, при некорректно выполненной проекции возможна потеря ФЗ. В действительности, проекция без потери ФЗ может оказаться невозможной - это значит, что необходимо обратиться к другому методу проектирования, отличному от декомпозиции.
(a) R3(Bn, Wk,Nb,St,Ph,Sa,G 1,02,03)
(б) R4(Nb,Wk,Ln)
Рис. 5.4. Результаты проекции R4 из R1
Правильный способ преобразования R1 состоит в проецировании, порожденном ФЗ Nb,Wk -> Ln и формировании отношений R3 и R4 так, как показано на рис. 5.4.
(б) 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>
Декомпозиция отношения R3 может быть осуществлена путем проецирования, порождаемого всеми ФЗ, для которых Ви является детерминантом. Таким набором является Bn -> Nb,St,Pn,Sa. Проекция дает отношения R5 и R6, показанные на рис. 5.5. Нетрудно показать, что оба эти отношения находятся в НФБК. Таким образом, итоговым набором проектирования являются отношения R2, R4, R5 и R6.
Оценка спроектированных НФБК-отношений
Набор НФБК-отношений, полученный с помощью пересмотренного алгоритма декомпозиции с исходным отношением R (рис. 5.1), имеет вид
R2(Nb,Cp,Tn)
R4(Nb,Wk,Ln) R5(Bn,Wk,Gl,G2,G3) R6(Bn,Nb,St,Ph,Sa)
Первичный ключ каждого отношения подчеркнут. Отношения R2 и R4 имеют более, чем один возможный ключ. Этот набор необходимо проконтролировать с целью обнаружения вероятных проблем.
Если перечислить ФЗ, обнаруживаемые на ФЗ-ди- аграммах для каждого отдельного отношения
Отношение
Номер рисунка
ФЗ
R2
5.3
Тп <-> Nb
Ср <-> Nb
R4
5.4
Wk,Ln -> Nb Wk,Nb -> Ln
R5
5.5
Bn,Wk -> G1,G2,G3
R6
5.5
Bn -> Nb,St,Ph,Sa,
то можно заметить две вещи: (1) ни одна ФЗ не повторяется более одного раза; (2) этот набор ФЗ совпадает с тем, который был найден для минимального покрытия (рис. 5.2).
. Анализ четырех отношений показывает, что нельзя указать среди них ни одного, все атрибуты которого являлись бы подмножеством атрибутов другого отношения. Кроме того, невозможно соединить операцией JOIN какие-либо три отношения так, чтобы в итоге
были получены все атрибуты четвертого отношения. Следовательно, ни одно из четырех отношений не является избыточным.
Если заменить более длинными названиями атрибутов более короткие двухсимвольные мнемоники, то отношения примут вид
R2 (НомКоманды, Капитан,НазвКоманды)
R4(НомКоманды, Неделя, Площадка)
К5(ФамИгрока, Неделя, Игра1, Игра2, ИграЗ) И6(ФамИгрока, НомКоманды, ТелНомер, Адрес, Результативность)
Анализ атрибутов, содержащихся в каждом отношении, показывает, что в каждом отношении хранится связный набор данных
R2: Информация о команде
R4: Расписание проведения игр
R5: Информация об индивидуальных результатах игроков
R6: Информация об отдельных игроках, которая носит частный характер
С практической точки зрения отношения кажутся вполне разумными.
Хотя проблема в данном примере не вышла на поверхность, в процессе проектирования атрибуты могут сгруппироваться в отношения нелогичным образом. Результат проектирования требует обязательной проверки с этой точки зрения. Возникновение указанной ситуации наиболее вероятно в тех случаях, когда используемые для обозначения атрибутов сокращения были такими короткими, что проектировщик перестал понимать, что означают названия атрибутов. Хороший проектировщик просматривает атрибуты в процессе проецирования отношений и пытается осознать, насколько разумно они группируются друг с другом.
В главах 9 и 10 будут рассмотрены реализации БД секретаря с использованием dBASE III и R:base 5000, соответственно. Будут приведены образцы программных модулей, предназначенных для генерации некоторых из отчетов, необходимых секретарю лиги.
Задачи к гл. 5
Перепроектируйте БД секретаря лиги в предположении, что “вычисляемые" атрибуты (Bavg, Bgame, Wins, Losses, Tpins, Bpins, Hndk, Higam, и Hiser) должны храниться в БД.
Если БД из задачи 1 была бы реализована, то как можно предотвратить занесение секретарем данных, порождающих ошибочные состояния некоторых вычисляемых атрибутов?
ДРУГОЙ ПОДХОД К ПРОЕКТИРОВАНИЮ
Декомпозиционный подход к проектированию, которому посвящены первые пять глав этой книги, является вполне пригодным при условии небольшого числа задействованных атрибутов. Какое количество атрибутов и ФЗ следует считать чрезмерным - дело вкуса; однако большинство специалистов полагает, что, когда число атрибутов превышает 20, метод, основанный на декомпозиции, становится излишне громоздким. В тех случаях, когда число атрибутов переусложняет применение метода декомпозиции, следует обратить внимание на другие методы проектирования. Один из таких методов называется “сущность-связь". Он отличается от метода декомпозиции тем, что ФЗ привлекаются не на начальном, а на конечном этапе проектирования.
Сущности и связи
Представление о методе можно получить с помощью специально подобранного примера. Предположим, что проектируется БД, предназначенная для хранения информации о преподавателях университетского факультета и о тех курсах, которые они читают. Двумя главными объектами, или сущностями, представляющими в данном случае интерес, являются ПРЕПОДА* ВАТЕЛЬ и КУРС. Эти две сущности соотносятся с помощью связи ЧИТАЕТ, что позволяет нам сказать
ПРЕПОДАВАТЕЛЬ ЧИТАЕТ КУРС
Связь ЧИТАЕТ, существующая между двумя сущностями ПРЕПОДАВАТЕЛЬ и КУРС, может быть графически представлена несколькими способами; из них здесь обсуждаются только два. Рис. 6.1 иллюстрирует использование диаграммы ER-экземпляров с помощью примера, показывающего какой в точности курс читает каждый преподаватель. В этом примере каждый преподаватель идентифицируется номе- ром-преподавателя(нп), и каждый курс - номе- ром-курса(нк). Рис. 6.2 называется диаграммой ЕЯ- типа и содержит ту же общую информацию, которая
содержится на рис. 6.1. В то же время, хотя это может показаться неочевидным на данный момент, рис. 6.2 содержит всю информацию, необходимую для генерации отношений первого уровня проектирования ДЛЯ БД.
ПРЕПОДАВАТЕЛЬ ЧИТАЕТКУРС
Рис. 6.1. Пример диаграммы ER-экземпляров
нп,..нп,..НК,..НК,..Рис. 6.2. Пример диаграммы ER-типаРис. 6.2. Пример диаграммы ER-типа
нп,..
нп,..
НК,..
НК,..
Рис. 6.2. Пример диаграммы ER-типа
Рис. 6.2. Пример диаграммы ER-типа
Прежде чем двигаться дальше, необходимо пояснить некоторые термины, используемые в дальнейшем. К сожалению, термины, поясняющие использование ER-метода, не могут быть строго определены, что не снимает необходимости их определения.
СУЩНОСТЬ. Сущность определяется как некоторый объект, представляющий интерес для организации. Этот объект должен иметь экземпляры, отличающиеся друг от друга и допускающие однозначную идентификацию. Единственный определяющий признак, который может помочь в нахождении сущностей, состоит в том, что сущность - это, как правило, существительное. Примерами сущностей могут служить машины, банковские счета, колледжи, служащие и контракты. На рис. 6.1 и 6.2 сущностями являются КУРС И ПРЕПОДАВАТЕЛЬ, в то время как отдельные экземпляры каждой сущности идентифицируются с помощью номера—курса и номера-преподавателя соответственно.
СВЯЗЬ. Связь представляет собой соединение между двумя или более сущностями. При поиске связей в основном следу-
ет полагаться на то обстоятельство, что связь обычно выражается глаголом. Типичными примерами связей между двумя сущностями являются: служащие РАБОТАЮТ-В отделах, студенты ИЗУЧАЮТ учебные предметы, рабочие ОБСЛУЖИВАЮТ механизмы.
Тесно связано с предыдущими третье важное понятие, обсуждавшееся выше, а именно атрибут.
АТРИБУТ. Атрибут есть свойство сущности. Например, атрибутами, могущими быть свойствами сущности КУРС, являются: номер-курса, номер-секции, рубрика, семестр-в-кото- ром—преподавался и предыдущий—курс.
Определения сущности, связи и атрибута не отличаются особой конкретностью, однако являются приемлемыми для использования в тех целях, на которые они рассчитаны. В то же время несколько смущает определенная особенность в ER-методе, заключающаяся в том, что два проектировщика могут рассматривать одну и ту же проблему с разных точек зрения, получая в итоге различные наборы сущностей и связей. Определение лучшего из двух наборов может быть вопросом личного предпочтения.
Продолжая рассмотрение форм графического описания отметим, что на диаграмме ER-экземпляров (см. рис. 6.1) названия всех сущностей помещены над экземплярами этих сущностей и в них использованы прописные буквы, в то время как каждый экземпляр сущности идентифицируется значением атрибута. Так КУРС является сущностью, a CIS 130 - конкретным экземпляром сущности. Связь также именуется, и ее название, составленное из прописных букв, размещается над экземплярами связи, при этом экземпляр каждой отдельной связи специфицируется линией между теми двумя экземплярами сущностей, которые эта связь соединяет. Экземпляр связи между CIS 130 и ПЗ, например, означает, что преподаватель с номе- ром-преподавателя равным ПЗ читает курс с номе- ром-курса CIS130.
В некоторых случаях может понадобиться набор атрибутов для идентификации каждого экземпляра сущности. Атрибут, или набор атрибутов, используемый для идентификации экземпляра сущности, называется ключом сущности. Каждый экземпляр связи
однозначно определяется набором ключей сущностей, соединяемых этой связью. Таким образом, <ПЗ,С18130> является одним ключом связи. На данном этапе процесса проектирования единственными требуемыми атрибутами являются тс, которые необходимы для формирования ключей сущностей. Другие атрибуты вместе с определенными над ними ФЗ будут добавлены позднее в процессе проектирования.
На диаграммах ER-типа, подобных показанной на рис. 6.2, сущности представляются в виде прямоугольников, а связи - в виде ромбов. Ниже каждой сущности размещается атрибут, или набор атрибутов, являющийся ключом сущности для данной сущности. Значения цифры “Г на диаграмме (см. рис. 6.2) и маленьких сплошных кружков будут обсуждены в следующем разделе.
В большинстве случаев для определения набора отношений проектируемой БД используются диаграммы ER-типа, а не диаграммы экземпляров.
Степень связи
Важной характеристикой связи между двумя (и более) сущностями является степень связи. Это понятие будет рассмотрено на расширенном примере данных, приведенных на рис. 6.1. Рис. 6.3 иллюстрирует все возможные формы диаграммы ER-экземпляров, которые могли бы существовать между сущностями ПРЕПОДАВАТЕЛЬ и КУРС в том случае, когда степень связи равна 1:1. Каждая диаграмма представляет собственный набор возможных правил функционирования организации (в данном случае университета). Только одна из этих диаграмм может быть истинной для организации в каждый момент времени. Перечни правил, которых следует придерживаться для соответствия каждой диаграмме, представленной на рис. 6.3, формулируются следующим образом:
Рис. 6.3(a). Каждый преподаватель читает не более одного курса и каждый курс читается не более чем одним преподавателем, т.е. допускается наличие преподавателей, не читающих ни одного курса, а также курсов, не читаемых вовсе. Таким образом, ни один преподаватель не должен
читать более одного курса, и ни один курс не должен читаться более чем одним преподавателем.
ПРЕПОДАВАТЕЛЬЧИТАЕТКУРС
П1018130
П2 о° НТН234
ИЗ о--" PHY1O4
П4 о 'HRD348
Степень равна 1:1 и класс принадлежности ни одной из сущностей не является обязательным
ПРЕПОДАВАТЕЛЬЧИТАЕТКУРС
П1 о^^оCIS130
П2 о—омтн23*
ПЗ—"°Р”*10*
^^-о HRD348
Степень равна1:1 и класс принадлежности сущности ПРЕПОДАВАТЕЛЬ является обязательным
ПРЕПОДАВАТЕЛЬЧИТАЕТКУРС
П1_-° С18130
П2МТН234
ИЗ о-—"*"*-о PHY104
П4 о
Степень равна 1:1 и класс принадлежности сущности КУРС является обязательным
ПРЕПОДАВАТЕЛЬ ЧИТАЕТКУРС
П1 ск.018X30
П2МТН234
ПЗ^ PHY104
П4НР0348
Степень равна 1:1 и класс принадлежности Обеих сущностей является обязательным
Рис. 6.3. Различные классы принадлежности для случая степени связи 1:1
Рис. 6.3(6). Каждый преподаватель читает только один курс, а каждый курс читается не более чем одним преподавателем.
Рис. 6.3(b). Каждый преподаватель читает не более одного курса, а каждый курс читается только одним преподавателем.
Рис. 6.3(г). Каждый преподаватель читает только один курс и каждый курс читается только одним преподавателем.
Тот факт, что каждый экземпляр сущности, расположенный как в левой, так и в правой частях диаграммы, связывается максимально с одним экземпляром сущности, расположенным в противоположной части диаграммы, дает основание определить каждую из диаграмм экземпляров, приведенную на рис. 6.3, как имеющую степень 1:1.
Различия между диаграммами, показанными на рис. 6.3, являются следствием того, должны или не должны все экземпляры сущности участвовать в связи. На рис. 6.3(a) не выставляется требование участия всех экземпляров обеих сущностей в связи. На рис. 6.3(6) все экземпляры преподавателей обязательно должны участвовать в связи, а экземпляры курсов - необязательно. На рис. 6.3(b) требуется участие в связи каждого экземпляра курса и допускается неучастие некоторых экземпляров преподавателей. На рис. 6.3(г) требование обязательного участия в связи накладывается на все экземпляры обеих сущностей.
Рис. 6.4 иллюстрирует возможность более компактной формы представления информации, приведенной на рис. 6.3.
Если экземпляры данной сущности должны участвовать в связи, то участие называется обязательным и этот факт отмечается помещением маленького сплошного кружка в блок, смежный с блоком сущности. Если экземпляры данной сущности могут не участвовать в связи, то участие называется необязательным и кружок внутрь маленького блока не заносится. Класс принадлежности сущности должен быть либо обязательным, либо необязательным и определяться Правилами, регламентирующими деятельность организации. Единицы в обеих частях связей, показанных на рис. 6.4, говорят о том, что степени всех связей
относятся к типу 1:1. Возможны и отличные от 1:1 степени. Они будут обсуждены позже в этом разделе. В диаграммах ER-типа непосредственно под блоком каждой сущности выписывается и выделяется подчеркиванием ключ этой сущности: нп (номер—преподавателя) для сущности ПРЕПОДАВАТЕЛЬ и нк (номер-курса) для сущности КУРС. Точки, расположенные вслед за каждым из этих атрибутов, указывают на то, что никакие другие возможно имеющиеся атрибуты соответствующей сущности не могут быть частью ее ключа. Эти другие атрибуты будут добавлены после разработки отношений.
Рис. 6.4. Диаграммы ER-типа, соответствующие диаграммам экземпляров, приведенных на рис. 6.3
ГЦ П2 ПЗ П4 ПЗ П6 П7ГЦ П2 ПЗ П4 ПЗ П6 П7CIS130 МТН234 PHY109 HRD348 MUS333 МТН257 FHY456CIS130 МТН234 PHY109 HRD348 MUS333 МТН257 FHY456(б) Степень равна 1 :п и класс принадлежности сущности ПРЕПОДАВАТЕЛЬ является обязательным(б) Степень равна 1 :п и класс принадлежности сущности ПРЕПОДАВАТЕЛЬ является обязательным
ГЦ П2 ПЗ П4 ПЗ П6 П7
ГЦ П2 ПЗ П4 ПЗ П6 П7
CIS130 МТН234 PHY109 HRD348 MUS333 МТН257 FHY456
CIS130 МТН234 PHY109 HRD348 MUS333 МТН257 FHY456
(б) Степень равна 1 :п и класс принадлежности сущности ПРЕПОДАВАТЕЛЬ является обязательным
(б) Степень равна 1 :п и класс принадлежности сущности ПРЕПОДАВАТЕЛЬ является обязательным
ПРЕПОДАВАТЕЛЬ ЧИТАЕТКУРС
CIS130 МТН234 PHY109 HRD348 MU6333 МТН237 PHY456
(а) Степень равна 1: п и класс принадлежности ни одной из сущностей не является обязательным
ПРЕПОДАВАТЕЛЬ ЧИТАЕТКУРС
ПРЕПОДАВАТЕЛЬ ЧИТАЕТКУРС
ПРЕПОДАВАТЕЛЬ ЧИТАЕТПРЕПОДАВАТЕЛЬ ЧИТАЕТКУРСКУРС
ПРЕПОДАВАТЕЛЬ ЧИТАЕТ
ПРЕПОДАВАТЕЛЬ ЧИТАЕТ
КУРС
КУРС
пх
_о CIS13O
П2
о—__-о МТН234
пз
о*—о PHY109
П4
° ^ HRD348
пь
о——^о МТН257
П7
оо PHY456
(в) Степень равна 1: п и класс принадлежности сущности КУРС является обязательным
CIS13OМТН234 л PHY109CIS13OМТН234 л PHY109MUS333МТН257PHY456MUS333МТН257PHY456(г) Степень равна 1: п и класс принадлежности обеих сущностей является обязательным(г) Степень равна 1: п и класс принадлежности обеих сущностей является обязательнымРис. 6.5. Примеры диаграмм экземпляров для случая степени связи 1:пРис. 6.5. Примеры диаграмм экземпляров для случая степени связи 1:п
CIS13O
МТН234 л PHY109
CIS13O
МТН234 л PHY109
MUS333
МТН257
PHY456
MUS333
МТН257
PHY456
(г) Степень равна 1: п и класс принадлежности обеих сущностей является обязательным
(г) Степень равна 1: п и класс принадлежности обеих сущностей является обязательным
Рис. 6.5. Примеры диаграмм экземпляров для случая степени связи 1:п
Рис. 6.5. Примеры диаграмм экземпляров для случая степени связи 1:п
П1
П2 ПЗ
П4
Ни одно из правил, регламентирующих работу организации и используемых при составлении диаграмм.
представленных на рис. 6.1 - 6.4, не допускает чтения преподавателем более одного курса, а также чтение одного курса более чем одним преподавателем. Для большинства учебных заведений дело обстоит иначе. Ниже приводятся другие наборы правил, принятых во многих учебных заведениях.
Рис. 6.6. Диаграммы ER-типа, соответствующие диаграммам экземпляров, приведенных на рис. 6.5
СЛУЧАЙ 1. Каждый преподаватель может читать одновременно несколько курсов, но каждый курс читается не более чем одним преподавателем.
СЛУЧАЙ 2. Каждый преподаватель читает не более одного курса, но каждый курс может читаться сразу несколькими преподавателями.
СЛУЧАЙ 3. Каждый преподаватель может читать несколько курсов и каждый курс может читаться несколькими преподавателями.
ПРЕПОДАВАТЕЛЬЧИТАЕТКУРС
П1-° CIS130
П2 оо МТН234
ПЗ о''PHY109
П4 о— оHRD348
ПЗ о—оMUS333
П6 о оМТН257
П7 о оPHY456
Степень равна п : 1 и класс принадлежности ни одной из сущностей не является обязательным
ПРЕПОДАВАТЕЛЬЧИТАЕТКУРС
П1 оCIS130
П2°МТН234
ПЗ~^ PHY109
П4 о ^^HRD348
ПЗ о-^'———° MUS333
П6 о————
П7 о-
Степень равна п :1 и класс принадлежности сущности ПРЕПОДАВАТЕЛЬ является обязательным
ПРЕПОДАВАТЕЛЬЧИТАЕТКУРС
П1 о— _о С IS 130
П2 о-_ —-—~-о МТН234
пз о— "—PHY109
П4 о— — -о HRD348
ПЗ о
П6 о—1'
П7 о
Степень равна п : 1 и класс принадлежности сущности
КУРС является обязательным
ПРЕПОДАВАТЕЛЬЧИТАЕТКУРС
П1 о .^ri CIS130
П2МТН234
ПЗ о-PHY109
П4 о——HRD348 ПЗ П6 о—" П7 о—
Степень равна п : 1 и класс принадлежности обеих сущностей является обязательным
Рис. 6.7. Примеры диаграмм экземпляров для случая степени связи п:1
Рис. 6.8. Диаграммы ER-типа, соответствующие диаграммам экземпляров, приведенных на рис. 6.7
Каждый из этих случаев имеет несколько подвариантов, а именно класс принадлежности может быть обязательным или необязательным - для одной из двух, ни для одной или для обеих сущностей. Возможные формы для каждого случая будут обсуждаться отдельно. Отметим, что случаи 1 и 2 симметричны по форме.
На рис. 6.5 показаны различные диаграммы экземпляров для СЛУЧАЯ 1, а на рис. 6.6 - эквивалентные им диаграммы типа. В примерах (а) ни один из классов принадлежности не является обязательным.
ПРЕПОДАВАТЕЛЬЧИТАЕТ
ГНо ——о
П2оо
ПЗ
П4о°
П5о—- о
П6оо
П7оо
КУРС
CIS130 МТН234 PHY109 HRD348 MUS333 МТН257 PHY456
(а) Степень равна m : п и класс принадлежности ни одной из сущностей не является обязательным
ПРЕПОДАВАТЕЛЬЧИТАЕТ
КУРС
П1о
П2L-
ПЗ о
П4 о-о
ПЗ о—" ——
П6 о——■о
П7 о— - -о
CIS130 МТН234 PHY109 HRD348 MUS333
МТН257 PHY456
(б) Степень равна m:n и класс принадлежности сущности ПРЕПОДАВАТЕЛЬ является обязательным
ПРЕПОДАВАТЕЛЬЧИТАЕТ
КУРС
П1 о——п
Л2 о2''-о
ПЗ о^^Г ——мз
П4 О—-—^===^-е=::~
П5 о
П6 о——
П7 о—г"^о
CIS130 МТН234 PHY109 HRD348 MUS333 МТН257 PHY456
(в) Степень равна m : п и класс принадлежности сущности КУРС является обязательным
ПРЕПОДАВАТЕЛЬЧИТАЕТ
П1 о—
П2 о-—Г"
ПЗо
Л4—■——^7777—°
пз о^_7777717—-—77772772—
П7 о— о
КУРС
CIS130
МТН234
PHY109
HRD348
MUS333
МТН257
PHY456
(г) Степень равна m : л и класс принадлежности обеих сущностей является обязательным
Рис. 6.9. Примеры диаграмм экземпляров для случая степени связи m:n
В примерах (б) и (в) класс принадлежности является обязательным для одной из двух сущностей. В
примерах (г) класс принадлежности является обязательным для обеих сущностей, В каждом из этих рисунков степень связи имеет тип l:n (1 к п) вследствие того, что каждый экземпляр курса может быть связан не более чем с одним экземпляром преподавателя (отсюда 1), а каждый экземпляр преподавателя может быть связан с более чем одним экземпляром курса (отсюда получаем п).
нпг.(а)h^r-
Рис, 6.10. Диаграммы ER-типа, соответствующие диаграммам экземпляров, приведенных на рис. 6.9
На рис. 6.7 показаны различные диаграммы экземпляров для случая 2, на рис. 6.8 показаны эквивалентные им диаграммы типа. В примерах (а) класс принадлежности не является обязательным для сущ-
ностей как левой, так и правой частей. В примерах (б) и (в) класс принадлежности является обязательным для сущности либо левой, либо правой частей. В примерах (г) класс принадлежности является обязательным для обеих сущностей. Связи на этих рисунках имеют степень п:1 (п к 1), так как экземпляр курса может быть связан с более чем одним экземпляром преподавателя (получаем п), а каждый экземпляр преподавателя связывается с не более чем одним экземпляром курса (имеем 1).
На рис. 6.9 показаны различные диаграммы экземпляров для случая 3, а на рис. 6.10 показаны им эквивалентные диаграммы типа. В примерах (а) класс принадлежности не является обязательным ни для одной из сущностей. В примерах (б) и (в) класс принадлежности является обязательным для одной из сущностей. В примерах (г) класс принадлежности является обязательным для обеих сущностей. Связь в каждом из этих рисунков имеет степень ш:п (ш к п), так как каждый экземпляр курса может быть связан более чем с одним экземпляром преподавателя (отсюда ш) и каждый экземпляр преподавателя может быть связан более чем с одним экземпляром курса (получаем п).
Некоторые замечания по поводу графического представления
Единого общепризнанного формата для графического представления диаграмм сущность-связь не установлено. Хотя методы, предложенные разными авторами, схожи по существу, они имеют как мелкие, так и крупные различия. Выбранное в книге графическое представление и терминология предложены Хау). Фактически стандартный способ представления избран Ульманом), в то время как более сложный подход, основанный на использовании семантических сетей, был избран Хавришкевичем). Читателю рекомендуется
изучить также другие методы и применять тот, который в наибольшей степени его устраивает. Думается, что описанный в книге метод прост и удобен для использования.
Задачи к гл. 6
Начертите типичные диаграммы экземпляров сущностей для каждой из следующих ситуаций. Перечислите предположения, сделанные в каждом случае:
руководству сети бакалейных магазинов требуется хранить информацию об отдельных магазинах и поставщиках, у которых эти магазины покупают продукцию; каждый магазин покупает продукцию у нескольких поставщиков, и каждый поставщик обеспечивает продукцией несколько магазинов;
службе окраски домов необходимо быть в курсе дел маляров, входящих в союз, и знать конкретно те дома, окраску которых они осуществляют; каждый маляр красит только один дом в любой момент времени, но один дом могут красить несколько маляров одновременно; некоторые маляры могут быть без работы; дома, не подлежащие окраске, не учитываются;
в гараже работают механики по ремонту автомобилей; каждый механик занят ремонтом сразу несколько автомашин, при этом ремонт каждого автомобиля осуществляется только одним механиком.
Для каждой диаграммы экземпляров, полученной при решении задач из пункта 1, начертите диаграмму ER-типа. Укажите ключи сущностей в каждой диаграмме.
ПОЛУЧЕНИЕ ОТНОШЕНИЙ ИЗ ДИАГРАММ ER-ТИПА
Связь ЧИТАЕТ, существующая между сущностями ПРЕПОДАВАТЕЛЬ и КУРС (рассмотрены в предыдущей главе), называется бинарной, поскольку она связывает только две сущности. Связи более высокого порядка, существующие между тремя и более сущностями, будут обсуждаться в следующей главе. Бинарные связи встречаются наиболее часто. Эта глава посвящена тому, как с использованием диаграмм ER-типа можно получить отношения, служащие основой построения БД, причем рассмотрение ограничивается случаем бинарных связей.
Общий подход к построению БД с использованием ER-метода состоит прежде всего в построении диаграммы ER-типа, включающей в себя все сущности и связи, важные с точки зрения интересов организации. Как частный пример на рис. 7.1 показана версия полной ER-диаграммы для БД секретаря кегельной лиги.
ФамИгрока, Неделя,.,
Другие атрибуты: Тел Номер, Адрес, Результативность,Назв Команды, Капитан, Игра1, Игра2, ИграЗ.
Рис. 7.1. Диаграмма ER-типа для БД секретаря кегельной лиги
На этой диаграмме представлены четыре сущности и три бинарные связи. Второй шаг в процессе проектирования состоит в построении набора предваритель-
ных отношений и указании предполагаемого первичного ключа для каждого отношения. Последний шаг состоит в подготовке списка всех представляющих интерес атрибутов (тех из них, которые не были уже перечислены в диаграмме ER-типа в качестве ключей сущности) и назначении каждого из этих атрибутов одному из предварительных отношений с тем условием, чтобы эти отношения находились в НФБК. На этом последнем шаге для каждого отношения должны быть определены межатрибутные ФЗ, с помощью которых проверяется соответствие отношений НФБК. Если полученные в итоге отношения не находятся в НФБК или если некоторым атрибутам не находится логически обоснованных мест в предварительных отношениях, то в этих случаях необходимо пересмотреть ER-диаграммы на предмет устранения возникших затруднений.
Предварительные отношения для бинарных связей степени 1:1
Предварительные отношения для данной бинарной связи могут быть получены путем просмотра нескольких логических альтернатив и выбора среди них наиболее подходящей. Перечень общих правил генерации отношений из диаграмм ER-типа можно получить, опираясь на класс принадлежности и степень отношения как на определяющие факторы. С целью упрощения вывода этих правил будет использована ситуация ПРЕПОДАВАТЕЛЬ ЧИТАЕТ КУРС (обсуждавшаяся в гл. 6) вместе с приблизительными ссылками на диаграммы, приведенные там же. Обсуждение будет ограничено случаями, в которых степень бинарной связи равна 1:1.
При попытке определить, как много отношений необходимо для размещения информации, содержащейся в бинарных связях степени 1:1, подобных приведенным на диаграммах ER-типа (см. рис. 6.4), простейшим решением, на которое можно надеяться, является необходимость одного отношения. Пусть это отношение называется ПРЕПОДАВАТЕЛЬ и все атрибуты помещаются в это одно отношение. На рис. 7.2 приведен экземпляр такого отношения в том случае, когда класс принадлежности является обязательным
для обеих сущностей (см. рис. 6.3(г) и 6.4(г)). В этом отношении сущность ПРЕПОДАВАТЕЛЬ была пополнена двумя типичными атрибутами: имя—преподавателя (пфам) и телефон—преподавателя (птел). Один атрибут добавлен к сущности КУРС: предыдущий—курс (предкурс).
ПРЕПОДАВАТЕЛЬ(нп, пфам, птел, нк, предкурс)
ПРЕПОДАВАТЕЛЬ
нп
пфам
птел
нк
предкурс
П1
Смит
2345
HRD348
HRD1OO
П2
Джонс
2233
PHY109
NONE
ПЗ
Хопп
6543
CIS130
МТН12О
П4
Аппл
7766
МТН234
МТН150
Рис. 7.2. Экземпляр единичного отношения, в котором содержатся данные, приведенные на рис. 6.3 (г) и 6.4 (г)
В этом специальном случае одно отношение - это все, что требуется. Так как степень связи здесь 1:1 и класс принадлежности является обязательным как для сущности ПРЕПОДАВАТЕЛЬ, так и для сущности КУРС, гарантируется однократное появление каждого значения нп и каждого значения нк в любом экземпляре отношения. Это значит, что отношение никогда нс будет содержать ни пустой информации, ни повторяющихся групп избыточных данных. Ключ сущности ПРЕПОДАВАТЕЛЬ был избран в качестве первичного ключа для отношения, но также может быть использован ключ сущности КУРС.
Итак, можно сформулировать первое правило генерации отношений.
ПРАВИЛО 1. Если степень бинарной связи равна 1:1 и класс принадлежности обеих сущностей является обязательным, то требуется только одно отношение. Первичным ключом этого отношения может быть ключ любой из двух сущностей.
Если степень связи равна 1:1 и класс принадлежности одной сущности является обязательным, а дру-
гой - необязательным, то одного отношения недостаточно. На рис. 7.3 приведен экземпляр отношения в том случае, когда класс принадлежности сущности ПРЕПОДАВАТЕЛЬ является обязательным, а сущности КУРС - необязательным (см. рис. 6.3(6) и 6.4(6)). В этом случае пробелы появляются во всех кортежах, содержащих информацию о курсах, не читаемых ни одним из преподавателей. Пробелы обозначаются знаками “—“.
ПРЕПОДАВАТЕЛЬ(нп, пфам, отел, нк, предкурс)
ПРЕПОДАВАТЕЛЬ
нп
пфам
пте*
НК
предкурс
П1
Смит
2345
HRD348
HRD1OO
П2
Джонс
2233
PHY109
NONE
ПЗ
Хопп
6543
CIS130
МТН12О
—
-----
----
МТН234
НТН150
Рис. 7.3. Экземпляр единичного отношения, в котором содержатся данные, приведенные на рис. 6.3(6) и 6.4(6)
После некоторых раздумий можно заключить, что способ исключения пробелов состоит в использовании вместо одного отношения двух. Каждое отношение будет содержать информацию, касающуюся одной сущности. Кроме того, ключ сущности, класс принадлежности которой является необязательным, необходимо поместить в качестве атрибута в отношение, содержащее информацию о сущности, класс принадлежности которой является обязательным. Этот случай иллюстрируется рис. 7.4. Причиной отсутствия пробелов в отношении ПРЕПОДАВАТЕЛЬ, приведенном на рис. 7.4, является то обстоятельство, что каждый преподаватель должен вести только один курс. (Заметьте, что если бы преподаватель мог читать более одного курса, то в отношении появились бы повторяющиеся значения в полях пфам и птел для всех тех преподавателей, которые читают более одного курса). Важно подчеркнуть, что слово NONE, появляющееся в качестве значения поля предкурс (см. рис. 7.4), есть действительное значение, а не пробел.
нппфамптванкП1Смит2345HRD348П2Джонс2233PHY109ПЗХопп6543CIS130нппфамптванкП1Смит2345HRD348П2Джонс2233PHY109ПЗХопп6543CIS130ПРЕПОДАВАТЕЛЬ(нп, пфам, отел, нк, предкурс)КУРС(н&, предкурс) ПРЕПОДАВАТЕЛЬКУРСПРЕПОДАВАТЕЛЬ(нп, пфам, отел, нк, предкурс)КУРС(н&, предкурс) ПРЕПОДАВАТЕЛЬКУРСнкпредкурсHRD348HRD1OOPHY109NONECIS130МТН12ОМТН234НТН150нкпредкурсHRD348HRD1OOPHY109NONECIS130МТН12ОМТН234НТН150
нп
пфам
птва
нк
П1
Смит
2345
HRD348
П2
Джонс
2233
PHY109
ПЗ
Хопп
6543
CIS130
нп
пфам
птва
нк
П1
Смит
2345
HRD348
П2
Джонс
2233
PHY109
ПЗ
Хопп
6543
CIS130
ПРЕПОДАВАТЕЛЬ(нп, пфам, отел, нк, предкурс)
КУРС(н&, предкурс) ПРЕПОДАВАТЕЛЬКУРС
ПРЕПОДАВАТЕЛЬ(нп, пфам, отел, нк, предкурс)
КУРС(н&, предкурс) ПРЕПОДАВАТЕЛЬКУРС
нк
предкурс
HRD348
HRD1OO
PHY109
NONE
CIS130
МТН12О
МТН234
НТН150
нк
предкурс
HRD348
HRD1OO
PHY109
NONE
CIS130
МТН12О
МТН234
НТН150
Рис. 7.4. Экземпляры двух отношений, в которых содержатся данные, приведенные на рис. 6.3(6) и 6.4(6)
Настало время для формулирования второго правила генерации отношений.
ПРАВИЛО 2. Если степень бинарной связи равна 1:1 и класс принадлежности одной сущности является обязательным, а другой - необязательным, то необходимо построение двух отношений. Под каждую сущность необходимо выделение одного отношения, при этом ключ сущности должен служить первичным ключом для соответствующего отношения. Кроме того, ключ сущности, для которого класс принадлежности является необязательным, добавляется в качестве атрибута в отношение, выделенное для сущности с обязательным классом принадлежности.
Воспользовавшись этим правилом в ситуации, описанной на рис. 6.3(b) и 6.4(b), где класс принадлежности сущности КУРС является обязательным, а сущности ПРЕПОДАВАТЕЛЬ - необязательным, получаем следующие отношения:
ПРЕПОДАВАТЕЛЬ (нп, пфам, птел) КУРС(нк, предкурс, нп)
В том случае, когда степень бинарной связи равна 1:1 и класс принадлежности ни одной из сущностей не является обязательным, одного отношения недостаточно. При использовании только одного отношения возможны два пути возникновения пробелов. Также недостаточным является использование двух отношений, так как возникают проблемы в связи с внесением
ключа одной сущности в отношение, выделенное под другую сущность. Единственное решение заключается в выделении трех отношений: по одному для каждой сущности и одного для связи. На рис. 7.5 приведены типичные экземпляры отношений, получаемые при использовании одного, двух и трех отношений (см. рис. 6.3(a) и 6.4(a)). Пробелы возникают везде, за исключением случая использования трех отношений.
ПРЕПОДАВАТЕЛЬ
нп
пфам
птел
НК
предкурс
П1
Смит
2345
HRD348
HRD1OO
П2
Джоне
2233
—
—
ПЗ
Хопп
6543
CIS130
МТН12О
П4
Аппл
7766
PHY109
NONE
--
—
—
МТН234
НТН150
Использование одного отношения
ПРЕПОДАВАТЕЛЬКУРС
нппфамптелНКП1Смит2345HRD348П2Джонс2233—ПЗХопп6543CIS130П4Аппл7766PHY109нппфамптелНКП1Смит2345HRD348П2Джонс2233—ПЗХопп6543CIS130П4Аппл7766PHY109НКпредкурснпCIS130МТН12ОПЗHRD348HRD1OOП1МТН234МТН150—PHY109NONEП4НКпредкурснпCIS130МТН12ОПЗHRD348HRD1OOП1МТН234МТН150—PHY109NONEП4
нп
пфам
птел
НК
П1
Смит
2345
HRD348
П2
Джонс
2233
—
ПЗ
Хопп
6543
CIS130
П4
Аппл
7766
PHY109
нп
пфам
птел
НК
П1
Смит
2345
HRD348
П2
Джонс
2233
—
ПЗ
Хопп
6543
CIS130
П4
Аппл
7766
PHY109
НК
предкурс
нп
CIS130
МТН12О
ПЗ
HRD348
HRD1OO
П1
МТН234
МТН150
—
PHY109
NONE
П4
НК
предкурс
нп
CIS130
МТН12О
ПЗ
HRD348
HRD1OO
П1
МТН234
МТН150
—
PHY109
NONE
П4
Использование двух отношений
ПРЕПОДАВАТЕЛЬКУРСЧИТАЕТ
нппфамптелП1Смит2345П2Джонс2233ПЗХопп6543П4Аппл7766нппфамптелП1Смит2345П2Джонс2233ПЗХопп6543П4Аппл7766• НКпредкурсCIS130ИТН12ОHRD348HRD1OOНТН234МТН150PHY109NONE• НКпредкурсCIS130ИТН12ОHRD348HRD1OOНТН234МТН150PHY109NONEнпНКП1HRD348ПЗCIS130П4PHY109нпНКП1HRD348ПЗCIS130П4PHY109
нп
пфам
птел
П1
Смит
2345
П2
Джонс
2233
ПЗ
Хопп
6543
П4
Аппл
7766
нп
пфам
птел
П1
Смит
2345
П2
Джонс
2233
ПЗ
Хопп
6543
П4
Аппл
7766
• НК
предкурс
CIS130
ИТН12О
HRD348
HRD1OO
НТН234
МТН150
PHY109
NONE
• НК
предкурс
CIS130
ИТН12О
HRD348
HRD1OO
НТН234
МТН150
PHY109
NONE
нп
НК
П1
HRD348
ПЗ
CIS130
П4
PHY109
нп
НК
П1
HRD348
ПЗ
CIS130
П4
PHY109
Использование трех отношений
Рис. 7.5. Возможные реляционные формы для случая бинарной связи степени 1:1, когда ни один из классов принадлежности не является обязательным
В отношении ЧИТАЕТ на рис. 7.5(b) любые значения как номера—преподавателя, так и номера—курса могут появиться только однажды, так как степень равна 1:1. Кроме того, отношение ЧИТАЕТ содержит номера—курсов только тех, которые читаются, и номера-преподавателей только тех, которые читают курс. Отношение ПРЕПОДАВАТЕЛЬ содержит информацию о всех преподавателях и отношение КУРС содержит информацию обо всех курсах.
Теперь можно сформулировать третье правило генерации отношений.
ПРАВИЛО 3. Если степень бинарной связи равна 1:1 и класс принадлежности ни одной сущности не является обязательным, то необходимо использовать три отношения: по одному для каждой сущности, ключи которых служат в качестве первичных в соответствующих отношениях, и одного для связи. Среди своих атрибутов отношение, выделяемое связи, будет иметь по одному ключу сущности от каждой сущности. .
В обсуждаемом нами случае отношение ЧИТАЕТ, исходной точкой генерации которого послужила связь, не имеет других атрибутов, кроме тех, которые требует ключ. Так обстоит дело не всегда. Например, если бы каждому читаемому курсу придавался тьютор, фамилия последнего могла бы быть атрибутом отношения ЧИТАЕТ.
7«2, Первый пример ER-проектирования
Постановка задачи
Проектируется БД, предназначенная для хранения информации о профессиональных рыболовных проводниках Северной Миннесоты и озерах, которые ими обслуживаются. Международный союз рыболовных проводников разрешает закрепление не более одного проводника за одним озером, и по соглашению между проводниками каждый из них обслуживает только одно озеро. Представляющими интерес атрибутами являются: имя проводника (п—имя), номер телефона (тном), ежедневная оплата (плата), максимально допу-
стимое число людей в группе рыбаков (размер), название озера (о—назв), рыболовный рейтинг (рейтнг) и основной вид вылавливаемой в озере рыбы (вид).
Решение задачи
Сущностями в данном случае будут ПРОВОДНИК и ОЗЕРО и связью между ними ОБСЛУЖИВАЕТ. Типичные диаграммы ER-экземпляров и типа приведены на рис. 7.6. Предположениями, учитывавшимися при построении диаграмм, являются: все проводники имеют работу, имена проводников уникальны, названия озер уникальны, некоторые озера проводниками не обслуживаются.
ПРОВОДНИКОБСЛУЖИВАЕТОЗЕРО
п.имя,...,п.имя,...,о„назв,....о„назв,....(б)(б)Другие Атрибуты \ тном, плата, разм, рейтнг, видДругие Атрибуты \ тном, плата, разм, рейтнг, видРис. 7.6. Диаграммы ER-экземпляров (а) и ER-типа (б) для первого примера ER-проектированияРис. 7.6. Диаграммы ER-экземпляров (а) и ER-типа (б) для первого примера ER-проектирования
п.имя,...,
п.имя,...,
о„назв,....
о„назв,....
(б)
(б)
Другие Атрибуты \ тном, плата, разм, рейтнг, вид
Другие Атрибуты \ тном, плата, разм, рейтнг, вид
Рис. 7.6. Диаграммы ER-экземпляров (а) и ER-типа (б) для первого примера ER-проектирования
Рис. 7.6. Диаграммы ER-экземпляров (а) и ER-типа (б) для первого примера ER-проектирования
Так как степень отношения равна 1:1 и класс принадлежности одной сущности является обязательным, а другой - нет, то используется правило 2 при генерации предварительных отношений
ПРОВОДНИК (п-имя.,о-назв)
• ОЗЕРО (о-назв.)
Не составляет труда найти место атрибутам, не используемым в качестве ключей сущности: тном, размер и плата находят свое место в отношении ПРОВОДНИК, так как они содержат информацию о проводниках; рейтнг и вид помещаются в отношение ОЗЕРО, так как в них содержится информация об озерах. Таким образом, предлагаются следующие отношения:
ПРОВОДНИК (п—имя. тном, размер, плата, паше) ОЗЕРО (о-назв. рейтнг. вид)
На рис. 7.7 для обоих отношений помещены диаграммы ФЗ, позволяющие заключить, что каждое отношение находится в НФБК. На рис. 7.8 приводятся типичные экземпляры отношений, используемых при создании БД.
Рис. 7.7. Диаграммы ФЗ для отношений (а) ПРОВОДНИК и (б) ОЗЕРО в первом примере ER-проектированияРис. 7.7. Диаграммы ФЗ для отношений (а) ПРОВОДНИК и (б) ОЗЕРО в первом примере ER-проектирования
Рис. 7.7. Диаграммы ФЗ для отношений (а) ПРОВОДНИК и (б) ОЗЕРО в первом примере ER-проектирования
Рис. 7.7. Диаграммы ФЗ для отношений (а) ПРОВОДНИК и (б) ОЗЕРО в первом примере ER-проектирования
Эта же БД будет проанализирована при различных предположениях далее в данной главе.
ПРОВОДНИК
п_имя тномплата размер
о_назв
Джоне234-6789504
Мари234-8765453
Рэй234-8765554
Смит234-7766554
Мус Найф Уан Бэс
ОЗЕРО
о_назв
рейтнг
вид
Алиса Бэс Мус Найф Уан Пагани
высок выем
средн низк высок средн
лещ пучеглазик с_щука с_щука окунь карась
Рис. 7.8. Типичные экземпляры отношений ПРОВОДНИК и ОЗЕРО
Предварительные отношения для бинарных связей степени 1:N
Для случая бинарных связей степени 1:1 устанавливаются три отдельных правила генерации соответствующего набора предварительных отношений. Для случая бинарных связей степени 1:п требуется только два правила. Фактором, определяющим выбор и использование одного из этих двух правил, является класс принадлежности n-связной сущности; класс принадлежности 1-связной сущности не влияет на конечный результат в обоих случаях.
На рис. 7.9(6) показан экземпляр отношения КУРС, содержащего данные, приведенные на рис. 6.5(b) и 6.6(b). Диаграмма типа из рис. 6.6(b) здесь повторена для ясности. Это случай степени 1:п с необязательным классом принадлежности 1-связной сущности и обязательным - n-связной сущности. Отчетливо вырисовываются две проблемы, связанные с этим отношением. Пробелы обнаруживаются в тех
полях атрибутов курса, где преподаватель не читает курс; повторение полей данных о преподавателях наблюдается там, где преподаватель читает более одного курса. (В частности, трижды появляется информация о преподавателе П5.) Если бы класс принадлежности 1-связной сущности был обязательным, то исчезли бы пробелы, но повторяющиеся группы данных в полях атрибутов преподавателя сохранились.
НП,..НК
КУРС
НК
предкурс
нп
пфам
птел
CIS130
МТН120
ПЗ
Хопп
6543
МТН234
МТН150
П1
Смит
2345
PHY109
NONE
П2
Джонс
2233
HRD348
HRD100
П5
Скотт
4356
MUS333
MUS100
П5
Скотт
4356
МТН257
МТН234
П5
Скотт
4356
PHY456
PHY109
П7
Поппи
8122
------
------
П4
Аппл
7766
—
—
П6
Каин
5492
б
Рис. 7.9. Использование одного отношения для бинарной связи типа 1:п в том случае, когда класс принадлежности п-связной сущности является обязательным, а 1-связной - необязательным
Решить все эти проблемы, вне зависимости от класса принадлежности 1-связной сущности, можно согласно следующему правилу.
ПРАВИЛО 4. Если степень бинарной связи равна 1:п и класс принадлежности n-связной сущности является обязательным, то достаточным является использование двух отношений, по одному на каждую сущность, при условии, что ключ сущности каждой сущности служит в качестве первичного ключа для соответствующего отношения. Дополнительно ключ 1-связной сущности должен быть добавлен как атрибут в отношение, отводимое n-связной сущности.
На рис. 7.10 приведены примеры двух отношений, построенных с помощью этого правила и содержащие ту же информацию, которая представлена на рис. 7.9. Обратите внимание, что все пробелы и повторяющиеся группы данных исчезли.
КУРС ПРЕПОДАВАТЕЛЬ
НКпредкурснпCIS130МТН120ПЗМТН234НТН150П1PHY109NONEП2HRD348HRD100П5MUS333MUS100П5МТН257МТН234П5PHY456PHY109П7НКпредкурснпCIS130МТН120ПЗМТН234НТН150П1PHY109NONEП2HRD348HRD100П5MUS333MUS100П5МТН257МТН234П5PHY456PHY109П7нппфамптелП1Смит2345П2Джонс2233ПЗХопп6543П4Аппл7766П5Скотт4356П6Каин5492П7Поппи8122нппфамптелП1Смит2345П2Джонс2233ПЗХопп6543П4Аппл7766П5Скотт4356П6Каин5492П7Поппи8122
НК
предкурс
нп
CIS130
МТН120
ПЗ
МТН234
НТН150
П1
PHY109
NONE
П2
HRD348
HRD100
П5
MUS333
MUS100
П5
МТН257
МТН234
П5
PHY456
PHY109
П7
НК
предкурс
нп
CIS130
МТН120
ПЗ
МТН234
НТН150
П1
PHY109
NONE
П2
HRD348
HRD100
П5
MUS333
MUS100
П5
МТН257
МТН234
П5
PHY456
PHY109
П7
нп
пфам
птел
П1
Смит
2345
П2
Джонс
2233
ПЗ
Хопп
6543
П4
Аппл
7766
П5
Скотт
4356
П6
Каин
5492
П7
Поппи
8122
нп
пфам
птел
П1
Смит
2345
П2
Джонс
2233
ПЗ
Хопп
6543
П4
Аппл
7766
П5
Скотт
4356
П6
Каин
5492
П7
Поппи
8122
Рис. 7.10. Данные, приведенные на рис. 7.9, после их разнесения по двум отношениям с помощью ПРАВИЛА 4
На рис. 7.11(6) показан экземпляр отношения КУРС, содержащего данные из рисунков 6.5(a) и 6.6(a). Диаграмма типа из рис. 6.6(a) повторена для большей ясности. Это случай связи степени 1:п с необязательным классом принадлежности обеих сущностей. В связи с этим отношением отчетливо вырисовываются три проблемы. Пробелы возникают в полях атрибутов курса там, где преподаватель не читает курс, и в тех полях атрибутов преподавателя, где курс не читается ни одним из преподавателей. Кроме того, повторяются поля данных о преподавателях в тех случаях, когда преподаватель читает более одного курса. (В частности, информация о преподавателе П2 повторяется дважды, о преподавателе П5 - трижды.)
Если бы класс принадлежности 1-связной сущности был обязательным, тогда пробелы в полях атрибутов курса исчезли бы, однако пробелы и повторяющиеся группы данных в полях атрибутов преподавателей остались.
нп
КУРС
НК
предкурс
нп
пфам
птел
CIS130
МТН120
ПЗ
Хопп
6543
МТН234
МТН150
П2
Джонс
2233
PHY109
NONE
П2
Джонс
2233
HRD348
HRD100
П5
Скотт
4356
MUS333
MUS100
—
——
——
МТН257
МТН234
П5
Скотт
4356
PHY456
PHY109
П5
Скотт
4356
——
------
П1
Смит
2345
—
—
П4
Аппл
7766
—
—
П6
Поппи
8122
б
Рис. 7.11. Использование одного отношения для бинарной связи типа 1:п в случае, когда класс принадлежности обеих сущностей является необязательным
Если применить ПРАВИЛО 4 в этом случае и сформировать два отношения, подобные тем, которые приведены на рис. 7.10, то все проблемы будут решены за исключением одной: не исчезнут пробелы в полях номера—преподавателя в новом отношении КУРС во всех тех местах, где курс не читается. Соответствующий пример показан на рис. 7.12.
НКпредкурснпCIS130МТН120ПЗМТН234МТН150П2PHY109NONEП2HRD348HRD100П5MUS333MUS100——МТН257МТН234П5PHY456PHY109П5НКпредкурснпCIS130МТН120ПЗМТН234МТН150П2PHY109NONEП2HRD348HRD100П5MUS333MUS100——МТН257МТН234П5PHY456PHY109П5КУРСКУРСнппфамптелП1Смит2345П2Джонс2233ПЗХопп6543П4Аппл7766П5Скотт4356П6Каин5492П7Поппи8122нппфамптелП1Смит2345П2Джонс2233ПЗХопп6543П4Аппл7766П5Скотт4356П6Каин5492П7Поппи8122ПРЕПОДАВАТЕЛЬПРЕПОДАВАТЕЛЬ
НК
предкурс
нп
CIS130
МТН120
ПЗ
МТН234
МТН150
П2
PHY109
NONE
П2
HRD348
HRD100
П5
MUS333
MUS100
——
МТН257
МТН234
П5
PHY456
PHY109
П5
НК
предкурс
нп
CIS130
МТН120
ПЗ
МТН234
МТН150
П2
PHY109
NONE
П2
HRD348
HRD100
П5
MUS333
MUS100
——
МТН257
МТН234
П5
PHY456
PHY109
П5
КУРС
КУРС
нп
пфам
птел
П1
Смит
2345
П2
Джонс
2233
ПЗ
Хопп
6543
П4
Аппл
7766
П5
Скотт
4356
П6
Каин
5492
П7
Поппи
8122
нп
пфам
птел
П1
Смит
2345
П2
Джонс
2233
ПЗ
Хопп
6543
П4
Аппл
7766
П5
Скотт
4356
П6
Каин
5492
П7
Поппи
8122
ПРЕПОДАВАТЕЛЬ
ПРЕПОДАВАТЕЛЬ
Рис. 7.12. Данные, приведенные на рис. 7.11, после их разнесения по двум отношениям с помощью ПРАВИЛА 4
Решить все эти проблемы вне зависимости от класса принадлежности 1-связной сущности можно, следуя этому правилу.
ПРАВИЛО 5. Если степень бинарной связи равна 1:п и класс принадлежности n-связной сущности является необязательным, то необходимо формирование трех отношений: по одному для каждой сущности, причем ключ каждой сущности служит первичным ключом соответствующего отношения, и одного отношения для связи. Связь должна иметь среди своих атрибутов ключ сущности от каждой сущности.
На рис. 7.13 приводятся экземпляры трех отношений, построенных с помощью этого правила, содержащих ту же информацию, что представлена на рис. 7.11. Обратите внимание, что все пробелы и повторяющиеся группы данных исключены.
Предварительные отношения для бинарных связей степени M:N
Если степень бинарной связи равна ш:п, то для хранения данных требуются три отношения вне зависимости от класса принадлежности как первой, так и второй сущностей. При использовании одного или двух отношений неизбежно возникновение пробелов и/или повторяющихся групп данных в экземплярах этих отношений; какая из двух проблем возникнет
при использовании двух отношений зависит от классов принадлежности двух сущностей. Предлагается следующее правило генерации предварительных отношений для случая степени ш:п.
КУРС ПРЕПОДАВАТЕЛЬ
НКпредкурсCIS130МТН120МТН234МТН150PHY109NONEHRD348HRD100MUS333MUS100МТН257МТН234PHY456PHY109НКпредкурсCIS130МТН120МТН234МТН150PHY109NONEHRD348HRD100MUS333MUS100МТН257МТН234PHY456PHY109нппфамптелП1Смит2345П2Джонс2233ПЗХопп6543П4Аппл7766П5Скотт4356П6Каин5492П7Поппи8122нппфамптелП1Смит2345П2Джонс2233ПЗХопп6543П4Аппл7766П5Скотт4356П6Каин5492П7Поппи8122
НК
предкурс
CIS130
МТН120
МТН234
МТН150
PHY109
NONE
HRD348
HRD100
MUS333
MUS100
МТН257
МТН234
PHY456
PHY109
НК
предкурс
CIS130
МТН120
МТН234
МТН150
PHY109
NONE
HRD348
HRD100
MUS333
MUS100
МТН257
МТН234
PHY456
PHY109
нп
пфам
птел
П1
Смит
2345
П2
Джонс
2233
ПЗ
Хопп
6543
П4
Аппл
7766
П5
Скотт
4356
П6
Каин
5492
П7
Поппи
8122
нп
пфам
птел
П1
Смит
2345
П2
Джонс
2233
ПЗ
Хопп
6543
П4
Аппл
7766
П5
Скотт
4356
П6
Каин
5492
П7
Поппи
8122
ЧИТАЕТ
нп
НК
П2
МТН234
нк является первичным ключом в силу
П2
PHY109
существующей связи типа п:1 между
ПЗ
CIS130
нк и нп
П5
HRD348
П5
МТН257
П5
PHY456
Рис. 7.13. Размещение данных, приведенных на рис. 7.11, в трех отношениях с помощью ПРАВИЛА 5
ПРАВИЛО 6. Если степень бинарной связи равна m:n, то для хранения данных необходимо три отношения: по одному для каждой сущности, причем ключ каждой сущности используется в качестве первичного ключа соответствующего отношения, и одного отношения для связи. Последнее отношение должно иметь в числе своих атрибутов ключ сущности каждой сущности.
На рис. 7.14 приведены экземпляры отношений, содержащих данные из рис. 6.9(a) (степень равна ш:п, и ни один класс принадлежности не является обязательным). Обратите внимание, что в этих экземплярах отсутствуют как пробелы, так и повторяю-
щиеся группы данных. Аналогичными будут экземпляры отношений, содержащие те же данные в тех случаях, когда один или оба класса принадлежности являются обязательными. Читателю рекомендуется начертить экземпляры двух отношений, содержащих эти данные, с целью иллюстрации причин, обуславливающих необходимость использования трех отношений.
НКпредкурсCIS130МТН120МТН234МТН150PHY109NONEHRD348HRD100MUS333MUS100МТН257МТН234PHY456PHY109НКпредкурсCIS130МТН120МТН234МТН150PHY109NONEHRD348HRD100MUS333MUS100МТН257МТН234PHY456PHY109КУРСКУРСнппфамптеП1Смит2345П2Джоне2233ПЗХопп6543П4Аппа7766П5Скотт4356П6Каин5492П7Поппи8122нппфамптеП1Смит2345П2Джоне2233ПЗХопп6543П4Аппа7766П5Скотт4356П6Каин5492П7Поппи8122ПРЕПОДАВАТЕЛЬПРЕПОДАВАТЕЛЬ
НК
предкурс
CIS130
МТН120
МТН234
МТН150
PHY109
NONE
HRD348
HRD100
MUS333
MUS100
МТН257
МТН234
PHY456
PHY109
НК
предкурс
CIS130
МТН120
МТН234
МТН150
PHY109
NONE
HRD348
HRD100
MUS333
MUS100
МТН257
МТН234
PHY456
PHY109
КУРС
КУРС
нп
пфам
пте
П1
Смит
2345
П2
Джоне
2233
ПЗ
Хопп
6543
П4
Аппа
7766
П5
Скотт
4356
П6
Каин
5492
П7
Поппи
8122
нп
пфам
пте
П1
Смит
2345
П2
Джоне
2233
ПЗ
Хопп
6543
П4
Аппа
7766
П5
Скотт
4356
П6
Каин
5492
П7
Поппи
8122
ПРЕПОДАВАТЕЛЬ
ПРЕПОДАВАТЕЛЬ
ЧИТАЕТ
нп
НК
П1
PHY109
Это отношение целиком является ключом1)
ПЗ
CIS130
ПЗ
PHY109
ПЗ
MUS133
П5
PHY109
П6
МТН257
Рис. 7.14. Размещение данных, приведенных на рис. 6.9(а), в трех отношениях с помощью ПРАВИЛА б
Второй пример ER-проектирования
Постановка задачи
Здесь рассматривается расширение задачи о рыболовных проводниках, определение которой было дано
в разд. 7.2. Проектируется БД, предназначенная для хранения информации о профессиональных рыболовных проводниках Северной Миннесоты и обслуживаемых ими озерах. Международный союз рыболовных проводников не препятствет тому, чтобы сразу несколькими проводниками обслуживалось одно озеро, однако, соблюдая соглашение, каждый проводник обслуживает только одно озеро. Рыбаки, нанимающие проводников, интересуются видами рыб, которые водятся в озерах, самыми крупными экземплярами каждого вида, выловленными в регионе в текущем сезоне, и типом лучшей по мнению союза наживки для ловли каждого вида рыбы в регионе. Представляющими интерес атрибутами являются: имя проводника (п—имя), номер телефона (тном), оплата за день (плата), название озера, обслуживаемого проводником (о-назв), максимально допустимое число людей в группе рыбаков (размер), рыболовный рейтинг каждого озера (рейтнг), основные виды рыб, которые можно выловить в каждом озере (вид), по каждому виду рыб вес самого большого экземпляра, пойманного в регионе в текущем сезоне (вмакс), и лучшая наживка для каждого вида рыб (нажвка).
Решение задачи
Выделим сущности - ПРОВОДНИК, ОЗЕРО и РЫБА и связи - ОБСЛУЖИВАЕТ и ВОДИТСЯ, как показано на рис. 7.15, где приведены диаграммы типа и типичные диаграммы экземпляров.
Присутствуют две связи: одна степени п:1 и другая - m:n. Необходимо применить оба правила (4 и 6), с получением четырех предварительных отношений: по одному для каждой сущности и одно для связи ВОДИТСЯ. Кроме того, атрибут о-назв сущности ОЗЕРО необходимо добавить в отношение ПРОВОДНИК (согласно ПРАВИЛУ 4). В результате получаются следующие предварительные отношения:
ПРОВОДНИК (п—имя,,о-назв) ОЗЕРО (о-назв,......) ОЗР-РБ (о-назв.вид,) РЫБА(вид,)
Рис. 7.15. Диаграммы ER-экземпляров (а) и ER-типа (б) для второго примера ER-проектирования
где предварительное отношение, полученное на основании связи ВОДИТСЯ, названо ОЗР-РБ. Как и в случае первого примера ЕК-проектирования, не сложно найти место атрибутам, не являющимся частью ключей сущностей. Размещение их завершает формирование окончательных отношений и проводится следующим образом: тном, плата и размер - все представляют собой свойства сущности ПРОВОДНИК и помещаются в соответствующее отношение. Атрибут рейтнг является свойством сущности ОЗЕРО, в то время как нажвка и вмакс относятся к сущности РЫБА. Единственное предварительное отношение, не получающее дополнительных атрибутов, это ОЗР—РБ. Как оказалось, оно целиком является ключом.
ПРОВОДНИК (п—имя, тном, плата, размер, о-назв)
ОЗЕРО (о-назв, рейтнг)
ОЗР-РБ (о-назв,вид)
РЫБА (вид,вмакс,нажвка)
На рис. 7.16 показаны диаграммы ФЗ для всех отношений. Каждое из этих отношений уже находится в НФБК и никаких дополнительных преобразований не требуется. Типичные примеры каждого из отношений приведены на рис. 7.17.
Рис. 7.16. Диаграммы ФЗ для отношений (а) ПРОРис. 7.16. Диаграммы ФЗ для отношений (а) ПРОВОДНИК, (б) ОЗЕРО, (в) ОЗ—РЫБА представленных на рис. 7.1дВОДНИК, (б) ОЗЕРО, (в) ОЗ—РЫБА представленных на рис. 7.1ди (г) РЫБА,и (г) РЫБА,
Рис. 7.16. Диаграммы ФЗ для отношений (а) ПРО
Рис. 7.16. Диаграммы ФЗ для отношений (а) ПРО
ВОДНИК, (б) ОЗЕРО, (в) ОЗ—РЫБА представленных на рис. 7.1д
ВОДНИК, (б) ОЗЕРО, (в) ОЗ—РЫБА представленных на рис. 7.1д
и (г) РЫБА,
и (г) РЫБА,
Читателю предлагается определить, как скажется на решении только что обсуждавшейся задачи каждое из следующих изменений условий.
п_имятномплатаразмеро_назвДжонс234-6789504МусМари234-8765453НайфРэй234-8765554УанСмит234-7766554Бэсп_имятномплатаразмеро_назвДжонс234-6789504МусМари234-8765453НайфРэй234-8765554УанСмит234-7766554БэсПРОВОДНИКПРОВОДНИКо_назврейтнгАлисавысокБэсвысшМуссреднНайфнизкУанвысоко_назврейтнгАлисавысокБэсвысшМуссреднНайфнизкУанвысокОЗЕРООЗЕРО
п_имя
тном
плата
размер
о_назв
Джонс
234-6789
50
4
Мус
Мари
234-8765
45
3
Найф
Рэй
234-8765
55
4
Уан
Смит
234-7766
55
4
Бэс
п_имя
тном
плата
размер
о_назв
Джонс
234-6789
50
4
Мус
Мари
234-8765
45
3
Найф
Рэй
234-8765
55
4
Уан
Смит
234-7766
55
4
Бэс
ПРОВОДНИК
ПРОВОДНИК
о_назв
рейтнг
Алиса
высок
Бэс
высш
Мус
средн
Найф
низк
Уан
высок
о_назв
рейтнг
Алиса
высок
Бэс
высш
Мус
средн
Найф
низк
Уан
высок
ОЗЕРО
ОЗЕРО
о_назввидУанпучеглазикУансщукаУанокуньМуссцукаНайфс_щукаАлисалещАлисаокуньБэслещНайфкарасьо_назввидУанпучеглазикУансщукаУанокуньМуссцукаНайфс_щукаАлисалещАлисаокуньБэслещНайфкарась03Р_РБ03Р_РБВИАвмакснахвкалещ6.5мотыльсцука27.5блеснаокунь0.75червяккарась4.25чхлебпучеглазик12.8гусеницаВИАвмакснахвкалещ6.5мотыльсцука27.5блеснаокунь0.75червяккарась4.25чхлебпучеглазик12.8гусеницаРЫБАРЫБА
о_назв
вид
Уан
пучеглазик
Уан
сщука
Уан
окунь
Мус
сцука
Найф
с_щука
Алиса
лещ
Алиса
окунь
Бэс
лещ
Найф
карась
о_назв
вид
Уан
пучеглазик
Уан
сщука
Уан
окунь
Мус
сцука
Найф
с_щука
Алиса
лещ
Алиса
окунь
Бэс
лещ
Найф
карась
03Р_РБ
03Р_РБ
ВИА
вмакс
нахвка
лещ
6.5
мотыль
сцука
27.5
блесна
окунь
0.75
червяк
карась
4.25
чхлеб
пучеглазик
12.8
гусеница
ВИА
вмакс
нахвка
лещ
6.5
мотыль
сцука
27.5
блесна
окунь
0.75
червяк
карась
4.25
чхлеб
пучеглазик
12.8
гусеница
РЫБА
РЫБА
б
Рис. 7.17. Типичные экземпляры отношений, обсуждавшихся во втором примере ER-проектирования
Проводник может обслуживать несколько озер.
Требуется хранить информацию обо всех наживках (не только о “лучшей"), которые можно использовать для данного вида рыбы.
Пересмотр БД секретаря кегельной лиги
На рис. 7.18 показана первая попытка применения диаграмм ER-типа для БД секретаря кегельной лиги, детально рассмотренной в гл. 5.
Другие атрибуты*. ТелНомер, Адрес, Результативность, НазвКоманды, Капитан, Игра!, Игра2, ИграЗ.Другие атрибуты*. ТелНомер, Адрес, Результативность, НазвКоманды, Капитан, Игра!, Игра2, ИграЗ.Рис. 7.18. Возможная диаграмма ER-типа для БД секретаря кегельной лигиРис. 7.18. Возможная диаграмма ER-типа для БД секретаря кегельной лиги
Другие атрибуты*. ТелНомер, Адрес, Результативность, НазвКоманды, Капитан, Игра!, Игра2, ИграЗ.
Другие атрибуты*. ТелНомер, Адрес, Результативность, НазвКоманды, Капитан, Игра!, Игра2, ИграЗ.
Рис. 7.18. Возможная диаграмма ER-типа для БД секретаря кегельной лиги
Рис. 7.18. Возможная диаграмма ER-типа для БД секретаря кегельной лиги
Предполагается, что при моделировании информации достаточно использовать три сущности и две би-
парные связи. Использование этой диаграммы и рассмотренных выше в этой главе правил генерации отношений позволяет разработать три предварительных отношения. Каждая сущность ИГРОК (BOWLER), КОМАНДА (TEAM) и РАСПИСАНИЕ (SCHEDULE) порождает одно отношение. Кроме того, ключ сущности КОМАНДА (НомКоманды) должен быть помещен в качестве атрибута в другие два отношения, что является следствием существующей между сущностью КОМАНДА и другими двумя сущностями связи типа 1:п. Эти три отношения имеют вид:
ИГРОК (ФамИгрока....., НомКоманды) КОМ АН ДА (НомКоманды ) РАСПИСАНИЕ (Площадка.Неделя.НомКоманды)
Логичные места для других атрибутов, перечисленных на рис. 7.18, таковы: НазвКоманды и Капитан следует поместить в отношение КОМАНДА, так как эти атрибуты суть название команды и фамилия капитана; ТелНомер, Адрес и Результативность в отношении ИГРОК, так как эти атрибуты содержат информацию об игроках. Не находится удачного места для размещения атрибутов Игра1, Игра2 и ИграЗ. На первый взгляд их следует поместить в отношение ИГРОК, но результаты встреч несколько теряют значимость в случае, если становится неизвестной неделя, на которой состоялась встреча. Однако атрибут Неделя нельзя добавить в отношение ИГРОК, поскольку данный атрибут отсутствует в списке неназ- наченных атрибутов. Создавшаяся ситуация явно указывает на наличие ошибки в диаграмме ER-типа. Возможно, что изменение диаграммы ER-типа приведет к получению предварительных отношений, от которых возможен прямой переход к НФБК-отношени- ям. Диаграмма ER-типа, приведенная на рис. 7.1, является именно такой диаграммой. Результаты предшествующих обсуждений послужили руководством при ее разработке. Новой сущностью является ОЧКИ, и имеет составной ключ сущности <ФамИгрока,Неде- ля>.
На основании диаграммы, приведенной на рис. 7.1, получаем следующие предварительные отношения:
И ГРО К (ФамИгрока....., НомКоманды) КОМАНДА (НомКоманды ) РАСПИСАНИЕ (Площадка.Неделя. НомКоманды) ОЧКИ (ФамИгрока.Неделя. ,ФамИгрока).
Укажем на интересную особенность предварительного отношения ОЧКИ: в нем атрибут ФамИгрока появляется дважды; в первый раз в силу того, что он является ключом сущности ОЧКИ, и во второй раз - в связи с размещением ключа сущности из отношения ИГРОК в отношение ОЧКИ, что диктуется связью степени 1:п между сущностями ИГРОК и ОЧКИ. Эта ситуация иногда возникает в случае связи степени 1:п, в которой у n-связной сущности ключ является составным. Все, что требуется сделать, заключается в удалении одного из двух дублированных атрибутов во избежание избыточности. Черта, пересекающая последний атрибут ФамИгрока, указывает, что его следует удалить.
После добавления оставшегося атрибута в последний набор предварительных отношений, будут получены те же 4 НФБК-отношения, генерация которых была осуществлена в гл. 5. Этот пример иллюстрирует тот факт, что диаграмма ER-типа допускает развитие с помощью итерационного процесса.
Некоторые замечания, касающиеся числа отношений
Общие правила, приведенные в этой главе и лежащие в основе генерации предварительных отношений для данной ER-диаграммы несколько отличаются от тех, которые можно найти в соответствующей литературе. Некоторые авторы утверждают, что по одному предварительному отношению следует формировать для каждой сущности и также по одному для каждой связи,вне зависимости от степени и класса принадлежности. В большинстве случаев результатом такого подхода будет генерация большего числа отношений, чем это необходимо.
Задачи к гл. 7
Разработайте отношения для каждой диаграммы типа из задачи 2 гл. 6.
Видоизмените часть ИГРОК НАБРАНО ОЧКИ ER- диаграммы, приведенной на рис. 7.1, предполагая, что ключом сущности ИГРОК являются:
<Неделя,Игра1 ,Игра2,ИграЗ> и
<Игра1 ,Игра2,ИграЗ>
Нарисуйте типичную диаграмму экземпляров в каждом случае. Постройте предварительные отношения и обдумайте проблемы, связанные с размещением других атрибутов.
8. ДОПОЛНИТЕЛЬНЫЕ КОНСТРУКЦИИ, ИСПОЛЬЗУЕМЫЕ В ER-МЕТОДЕ
В гл. 6 и 7 был развит метод генерации отношений БД, основанный на использовании бинарных связей. Хотя с помощью бинарных связей могут быть описаны многие ситуации реального мира, тем не менее неизбежно возникновение и таких ситуаций, в которых построение разумной модели организации не представляется возможным без привлечения дополнительных конструкций. Эта глава знакомит читателя с двумя новыми констукциями ER-метода: связями более высокого порядка и ролями.
Необходимость связей более высокого порядка
В гл. 7 на двух примерах изучались возможности применения ER-метода. В основе этих примеров лежит необходимость хранения информации о рыболовных проводниках, озерах, обслуживаемых проводниками, видах рыбы, обитающей в этих озерах. Предположим, что люди, нанимающие проводника, хотят знать, какой вид рыбы предпочитает ловить проводник. Если посмотреть на диаграмму экземпляров, изображенную на рис. 7.15(a), то кому-то может показаться естественным заключение о том, что раз Смит обслуживает озеро Уан и водятся в этом озере пучеглазик, северная щука и карась, то, следовательно, Смит любит ловить пучеглазика, северную щуку и карася. Это может быть правдой, а может и не быть. Возможно Смит только сопровождает тех, кто хочет ловить пучеглазика. Если связь между сущностями ПРОВОДНИК и РЫБА существует, то эта связь, назовем ее ПРЕДПОЧИТАЕТ, должна быть представлена в обеих диаграммах - типа и экземпляров, как это показано на рис. 8.1.
Пунктирные линии использованы с целью выделения экземпляров связи ПРЕДПОЧИТАЕТ. Кроме того, во избежание путаницы приведены только несколько экземпляров. Из диаграммы экземпляров следует, что Смит обслуживает озеро Уан, что в озере Уан водятся три вида рыбы, а также то, что Смит предпочитает ловить пучеглазика. В силу того что
связь между сущностями ПРОВОДНИК и РЫБА имеет степень п:1, и, поскольку каждый проводник обслуживает только одно озеро, не возникает проблемы выбора проводника для данного озера, если вы собрались ловить определенный вид рыбы. Действительно, если вы строите отношения, отражающие ситуацию, приведенную на рис. 8.1, единственным изменением, которое требуется внести в отношения, приведенные на рис. 7.17, является добавление в отношение ПРОВОДНИК атрибута вида из отношения РЫБА. (Этот атрибут указывает вид рыбы, ловить который предпочитает данный проводник.) Таким образом, в этом расширенном примере бинарные связи также позволяют получать адекватную модель ситуации.
(б)
Рис. 8.1. Диаграммы ER-экземпляров (а) и ER-типа (б) в случае, когда проводники отдают предпочтение некоторым видам рыб
Если продолжить модификацию проблемы, то можно показать недостаточность бинарных связей для
корректного моделирования некоторой ситуации. Предположим, что проводники обслуживают более чем по одному озеру и каждый проводник может предпочитать ловить один вид рыбы в одном озере, а другой - в другом озере. Смит, например, предпочитает ловить пучеглазика в озере Уан и северную щуку в озере Мус. Джонс, в свою очередь, обслуживает только озеро Мус и предпочитает ловить северную щуку. Собрав вместе эти данные, получим следующий перечень утверждений:
Смит обслуживает оба озера - Уан и Мус.
Джонс обслуживает только озеро Мус.
Смит предпочитает ловить пучеглазика в озере Уан.
Смит предпочитает ловить с-щуку в озере Мус.
Джонс предпочитает ловить с—щуку в озере Мус.
На рис. 8.2 приведена диаграмма ER-экземпляров, в которой использованы бинарные связи, включающие только указанные 5 единиц информации.
(б)
Рис. 8.2. Диаграммы ER-экземпляров (а) и ER-типа (б) в случае, когда все связи имеют степень m:n
ОЗЕРО
Рис. 8.3. Диаграммы ER-экземпляров (а) и ER-типа (б) в случае трехсторонней связи П—О—Р
Важно заметить, что хотя из диаграммы можно вывести все характеризующие Смита и Джонса (см. выше) утверждения, также можно заключить, что Смит предпочитает ловить с—щуку в озере Уан, а это неверно. Проблема возникает из того факта, что в данном случае все связи имеют степень ш:п и, следовательно, отсутствует уникальный путь, соединяющий вместе все три экземпляра сущности единственным образом. Причину возникновения подобной проблемы можно понять, обратив внимание на то, что каждое из утверждений “Смит предпочитает ловить пучеглазика в озере Уан“ и “Смит предпочитает ловить
с—щуку в озере Мус“ связывает вместе три информационных единицы. Та же информация не может быть заключена в выражениях “Смит обслуживает озеро У ан и озеро Мус“; “В озере У ан и озере Мус водится пучеглазик, северная щука и окунь“; “Смит предпочитает ловить пучеглазика и северную щуку“. Суть в том, что информационные триплеты нельзя представить в виде набора из трех бинарных связей. Правильная модель приводится на рис. 8.3 и требует использования трехсторонних связей.
Предварительные отношения для трехсторонних связей
В случае трехсторонних связей предварительные отношения генерируются на основании следующего правила.
ПРАВИЛО 7. В случае трехсторонней связи необходимо использовать четыре предварительных отношения, по одному для каждой сущности, причем ключ каждой сущности должен служить в качестве первичного ключа для соответствующего отношения, и одно для связи. Отношение, порождаемое связью, будет иметь среди своих атрибутов ключи сущности от каждой сущности. (Аналогично, когда связь п-сторон- няя, требуется п+1 предварительное отношение.)
Если применить это правило к данным, приведенным на рис. 8.3, то будут получены отношения
ПРОВОДНИК (п-имя, ) ОЗЕРО (о-назв.)
РЫБА(вид,)
П—О—Р (п—имя ,о-назв, вид,...)
Первичный ключ для П—О—Р не может быть определен до тех пор, пока не будут распределены все другие атрибуты. Если воспользоваться всеми теми атрибутами, которые приведены на рис. 7.17, то атрибуты будут распределены следующим образом: отношению ПРОВОДНИК назначаются атрибуты тном, плата и размер; отношению ОЗЕРО будет назначен только один атрибут рейтнг, и отношению РЫБА назначаются вмакс и нажвка. Отношение П—О—Р не получит
никаких “других“ атрибутов. Первичный ключ для П—О—Р будет составным <п—имя,о-назв> в том случае, если каждый проводник предпочитает ловить в озере только один вид рыбы. Если число предпочитаемых проводником видов рыб равно двум или более для какого-либо озера, тогда все три атрибута отношения П—О—Р будут составлять ключ. На рис. 8.4 приведены экземпляры четырех отношений в предположении, что каждый проводник предпочитает ловить один вид рыбы в каждом озере, которое им обслуживается. Нетрудно показать, что каждое из рассмотренных отношений находится в НФБК.
П_ИМЯтномплатаразмерДжонс234-6789504Мари234-8765453Рэй234-8765554Смит234-7766554П_ИМЯтномплатаразмерДжонс234-6789504Мари234-8765453Рэй234-8765554Смит234-7766554ПРОВОДНИКПРОВОДНИКо_назврейтнгАлисавысокМуссреднНайфнизкУанвысоко_назврейтнгАлисавысокМуссреднНайфнизкУанвысокОЗЕРООЗЕРО
П_ИМЯ
тном
плата
размер
Джонс
234-6789
50
4
Мари
234-8765
45
3
Рэй
234-8765
55
4
Смит
234-7766
55
4
П_ИМЯ
тном
плата
размер
Джонс
234-6789
50
4
Мари
234-8765
45
3
Рэй
234-8765
55
4
Смит
234-7766
55
4
ПРОВОДНИК
ПРОВОДНИК
о_назв
рейтнг
Алиса
высок
Мус
средн
Найф
низк
Уан
высок
о_назв
рейтнг
Алиса
высок
Мус
средн
Найф
низк
Уан
высок
ОЗЕРО
ОЗЕРО
п_имяо_назввидДжонсМусс_щукаСмитМусс_щукаСмитУанпучеглазикРэйУанокуньРэйМусс_щукаМариНайфкарасьп_имяо_назввидДжонсМусс_щукаСмитМусс_щукаСмитУанпучеглазикРэйУанокуньРэйМусс_щукаМариНайфкарасьП_О_РП_О_Рвидвмакснажвкалещ6.5мотыльс_щука27.5блеснаокунь0.75червяккарась4.25чхлебпучеглазик12.8гусеницавидвмакснажвкалещ6.5мотыльс_щука27.5блеснаокунь0.75червяккарась4.25чхлебпучеглазик12.8гусеницаРЫБАРЫБА
п_имя
о_назв
вид
Джонс
Мус
с_щука
Смит
Мус
с_щука
Смит
Уан
пучеглазик
Рэй
Уан
окунь
Рэй
Мус
с_щука
Мари
Найф
карась
п_имя
о_назв
вид
Джонс
Мус
с_щука
Смит
Мус
с_щука
Смит
Уан
пучеглазик
Рэй
Уан
окунь
Рэй
Мус
с_щука
Мари
Найф
карась
П_О_Р
П_О_Р
вид
вмакс
нажвка
лещ
6.5
мотыль
с_щука
27.5
блесна
окунь
0.75
червяк
карась
4.25
чхлеб
пучеглазик
12.8
гусеница
вид
вмакс
нажвка
лещ
6.5
мотыль
с_щука
27.5
блесна
окунь
0.75
червяк
карась
4.25
чхлеб
пучеглазик
12.8
гусеница
РЫБА
РЫБА
Рис. 8.4. Экземпляры отношений, полученные на основании диаграмм, приведенных на рис. 8.3
Использование ролей
В некоторых ситуациях одних сущностей и связей может оказаться недостаточно для полноценного моделирования организации. Одна из таких ситуаций возникает тогда, когда экземпляры некоторой сущности должны играть разные роли в деятельности предприятия. В качестве примера положим, что для небольшого предприятия-поставщика автомобилей . необходимо
хранить информацию о производственном персонале. Различают две категории служащих: мастеров и сборщиков. Мастера получают фиксированный оклад, в то время как у сборщиков почасовая оплата.
Первая попытка построения ER-диаграммы показана на рис. 8.5. Ключом сущности для каждой сущности является номер страхового полиса каждого служащего. Предполагается, что ни один мастер не руководит другим мастером, ни один мастер не является сборщиком и ни один сборщик не является мастером.
Рис. 8.5. Возможный вариант ER-модели предприятия
Поскольку связь РУКОВОДИТ имеет степень 1:п и вхождение сущности для обеих сторон связи является обязательным, то в соответствии с общим правилом будут построены два предварительных отношения:
МАСТЕР (мастер#.)
СБОРЩИК (сборщик #.мастер#)
С этой моделью связана одна проблема, проявляющаяся при добавлении неключевых атрибутов в предварительные отношения. Предположим, что другими представляющими интерес атрибутами являются
слфам — фамилия (и имя) служащего
ртел — номер служебного телефона мастера.
Сборщик служебного телефона не имеет.
дтел — номер домашнего телефона служащего
сладрес — домашний адрес служащего
тставка — почасовая тарифная ставка сборщика
оклад — месячный оклад мастера
сбкод — рабочий код сборщика
сфкомп — сфера компетенции мастера
Не возникает особых проблем при размещении в одном из двух отношений следующих атрибутов: ртел, тставка, оклад, сбкод и сфкомп. После того как каждый из этих атрибутов будет логичным образом помещен в одно из двух отношений, предварительные отношения примут вид
МАСТЕР (мастер #.оклад.сфкомп.ртел) СБОРЩИК (сборщик #.тставка.сбкодмастер #)
Неразмещенными остались только атрибуты сфам, дтел и сладрес. Для полноты следовало бы эти три атрибута поместить в оба отношения. Однако в соответствии с общим правилом каждый неключевой атрибут следует размещать только в одном отношении.
Может возникнуть необходимость переопределить три оставшихся атрибута с целью получения из них следующих шести атрибутов:
мфам—фамилия (и имя) мастера
сбфам—фамилия (и имя) сборщика
мдтел—номер домашнего телефонамастера
мадрес—домашний адрес мастера
сбдтел—номер домашнего телефонасборщика
сбадрес—домашний адрес сборщика
Атрибуты мфам, мдтел и мадрес могут быть помещены в отношение МАСТЕР, а атрибуты сбфам, сбдтел и сбадрес - в отношение СБОРЩИК. Это неудачное решение, паллиатив, позволяющий уйти от проблемы отсутствия подходящего места для двух исходных атрибутов.
Если все же изменить предложенным образом названия атрибутов, то возникнет следующая проблема. Предположим, что требуется найти номер домашнего телефона, например служащего Джоан Джонс. Поскольку неизвестно, является Джоан Джонс мастером
или сборщиком, следовательно, предварительно необходимо просмотреть сначала одно отношение, затем другое с целью нахождения имени Джоан Джонс. Если существуют два служащих Джоан Джонс - один мастер, а другой - сборщик, результатом поиска, если выбрано не то отношение, будет неправильный номер телефона.
Лучшее решение достигается путем рассмотрения всей проблемы с иной точки зрения. Все мастера и служащие рассматриваются в качестве служащих, а мастер и сборщик - это те роли, которые данный служащий может играть: некоторые служащие являются мастерами, в то время как другие являются сборщиками. Графически это показано на рис. 8.6. На рисунке СЛУЖАЩИЙ представляет собой сущность, ключом которой является номер страхового полиса. Объекты данной сущности могут играть роль либо мастера, либо сборщика. Два ролевых набора - МАСТЕР и СБОРЩИК - соединяются связью РУКОВОДИТ. Стрелки, идущие от СЛУЖАЩИЙ как к сущности МАСТЕР, так и к сущности СБОРЩИК, указывают на то, что сущность СЛУЖАЩИЙ является исходной, а МАСТЕР и СБОРЩИК - ролями.
Рис. 8.6. Использование ролей в ER-модели
При генерации предварительных отношений, исходя из диаграммы, представленной на рис. 8.6, можно руководствоваться следующим правилом.
Исходная сущность служит источником генерации одного отношения, причем ключ сущности служит в качестве ключа отношения. Ролевые элементы и связи, их соединяющие, порождают такое число отношений, которое определяется ранее описанными правилами, причем каждая роль трактуется как обычная сущность.
С помощью предложеного правила получены следующие три предварительные отношения:
СЛУЖАЩИЙ (служ#,)
МАСТЕР (мастер#,)
СБОРЩИК (сборщик #,,мастер #)
При распределении всех других атрибутов между отношениями, входящими в данный набор, выясняется, что каждому атрибуту находится естественное место. Получаемый в результате окончательный набор отношений имеет вид
СЛУЖАЩИЙ (служ #.сфам.дтел.сладрес) МАСТЕР (мастер #,оклад.сфкомп.ртел) СБОРЩИК (сборщик #,тставка,сбкод,мастер #)
Отношение, полученное из исходной сущности (СЛУЖАЩИЙ), содержит информацию, общую для всех служащих. Отношения, полученные из ролей, содержат специфическую для исполняемой роли информацию. Каждое порождаемое ролью отношение связано с отношением, источником порождения которого послужила исходная сущность, через атрибут из общего домена (в данном примере - номер страхового полиса).
При рассмотрении диаграммы, показанной на рис. 8.6, следует обратить внимание на то обстоятельство, что связь РУКОВОДИТ соединяет две роли одной исходной сущности. Такой тип связи называется рекурсивным. Эта связь рекурсивна в том смысле, что с точки зрения исходной сущности служащие руководят служащими. Ничто не мешает также тому, чтобы роли одной исходной сущности соединялись связью с ролями других исходных сущностей. В этом случае связь уже не будет рекурсивной.
Для увеличения скорости доступа при запросах проектировщик может рассмотреть возможность добавления в отношение СЛУЖАЩИЙ атрибута, определяющего кем конкретно является служащий - мастером или сборщиком. Это позволит избежать необходимости организации поиска в отношениях МАСТЕР и СБОРЩИК, цель которого состоит в определении типа работы отдельного служащего, а возможность - обуславливается известным номером страхового полиса. Можно привести аргументы как за, так и против включения дополнительного атрибута.
Более крупный пример ER-проектирования
Постановка задачи
Предположим, что необходимо спроектировать БД для Топночской атлетической универсиады (ТАУ). Предполагается, что БД будет использоваться членами руководящего состава конторы ТАУ. Эти уполномоченные полностью контролируют деятельность лиги, включая такие вопросы, как составление календаря для всех спортивных мероприятий; приглашение на работу всех должностных лиц на все соревнования, проводимые в рамках лиги; проверка всех спортсменов на соответствие требованиям, предъявляемым лигой; хранение списков всех спортсменов, администраторов и тренеров всех колледжей, входящих в лигу.
Уполномоченный определил следующие параметры как имеющие наибольшее значение:
Для каждого учебного заведения, входящего в лигу:
официальное название колледжа число студентов
все виды спорта, культивируемые учебным заведением логограмма название стадиона и его вместимость название футбольного поля и его размеры фамилия, адрес, номер домашнего телефона и номер служебного телефона каждого из тех, кто перечислен ниже:
президент колледжа
спортивный директор заведующий отделом спортивной информации представитель от факультета по вопросам спорта главный тренер по каждому виду спорта
Список всех одобренных лигой судей, содержащий следующую информацию:
фамилия и номер страхового полиса
домашний адрес
номер домашнего телефона
вид спорта, который обслуживает судья рейтинг по результатам предыдущего сезона соревнования наступающего сезона, на которые назначается данный судья
Список всех студентов-спортсменов, содержащий следующую информацию:
фамилия и номер страхового полиса
домашний адрес
адрес колледжа
номер телефона колледжа
текущая профилирующая дисциплина
средняя оценка
число учебных часов, оставшихся до окончания колледжа
число соревновательных сезонов по всем видам спорта, которыми студент занимался
дата поступления в колледж число текущих зачетных часов число сданных зачетных часов за два последних семестра
Расписание лиги на текущий год, содержащее следующую информацию:
команда, в данной встрече выступающая в роли хозяина
команда, в данной встрече выступающая в роли гостя
дата и время каждой встречи•
назначенные судьи вид спорта, по которому предполагается проведение соревнований
По каждому виду спорта, культивируемому в лиге, имеется комитет по правилам и один главный тренер назначается лигой в качестве председателя этого комитета.
Сделаем следующие допущения: расписание составляется для наступающего сезона; главный тренер тренирует только по одному виду спорта; некоторые колледжи участвуют не во всех видах спорта, культивируемых лигой; некоторые люди имеют общие служебные телефоны; в лиге представлены как мужские, так и женские виды спорта.
ER-диаграмма
При построении ER-диаграммы главная проблема заключается в определении используемых сущностей; в большинстве случаев множество сущностей не уникально. Для рассматриваемой проблемы было решено, что представляющими интерес сущностями являются КОЛЛЕДЖ, ВИДСПОРТА, СТУДЕНТ, СУДЬЯ и СЛУЖАЩИЙ. Сущность СЛУЖАЩИЙ предназначалась для представления всех служащих из всех колледжей, которые имеют какие-либо официальные связи с лигой. Кроме того, сущность ГЛАВНЫЙ ТРЕНЕР нацелена на ее использование в качестве роли сущностью СЛУЖАЩИЙ, в то время как ролями сущности КОЛЛЕДЖ могут быть либо КОМАНДА ХОЗЯЕВ, либо КОМАНДА ГОСТЕЙ, когда речь пойдет о спортивных соревнованиях. Окончательный вид ER-диаграммы приведен на рис. 8.7. Обратите внимание на четырехстороннюю связь РАСПИСАНИЕ.
Предварительные отношения
Предварительные отношения, которые могут быть получены на основании рис. 8.7, имеют вид:
КОЛЛЕДЖ (НазвКолледжа,)
СЛУЖАЩИЙ (Служ #...”...., Назв Колледжа) ХОЗЯЕВА (Хозяева,)
ГОСТИ (Гости,)
СУДЬЯ (судья#,)
ТРЕНЕР (Тренер#,,Видспрт)
ВИДСПОРТА(Видспрт,) СТУДЕНТ (Студент # НазвКолледжа)
КУЛЬТИВИРУЕТ (НазвКолледжа,Видспрт,)
УЧАСТВУЕТ (Видспрт,Студент#, )
РАСПИСАНИЕ (Хозяева,Гости,судья #,Видспрт,...)
судьи # ,..
Рис. 8.7. ER-диаграмма для Топночской Атлетической Универсиады
После назначения остальных атрибутов были получены следующие отношения:
КОЛЛЕДЖ (НазвКолледжа,назв-стадиона, вмест—стадиона, назв-футб—пол я, размеры—футб—поля, список-студ)
СЛУЖАЩИЙ (Служ #,(Ьам-служ.адрес—служ, дтел-служ,ртел—служ, должность, НазвКолледжа)
ХОЗЯЕВА (Хозяева)
ГОСТИ (Гости)
СУДЬЯ (судья #.фам-суд,адрес-суд, дтел-суд, вид—спорта—в—котором—имеет—офиц-статус) ТРЕНЕР (Тренер#.Видспрт)
ВИДСПОРТА(Видспрт. #—предс-ком-по-правилам) СТУДЕНТ (Студент#.пол.воз раст.средн-оценка.
общее—числе-зач—часов, адрес-студ, НазвКолледжа,зач—часов—в—данном-семестре, зач—часов—поел—два-семестра)
КУЛЬТИВИРУЕТ (НазвКолледжа.Видспрт) УЧАСТВУЕТ (Видспрт.Студент #.соревн-сезоны) РАСПИСАНИЕ (Хозяева.Гости.судья #.Видспрт.дата. время—нач-соревн)^
Два отношения из последнего набора могут быть исключены. Отношения ХОЗЯЕВА и ГОСТИ являются унарными и не содержат полезной информации. То, что они не содержат полезной информации, является следствием отсутствия атрибутов, характерных только для команды хозяев и команды гостей, не относящихся к описанию колледжа в целом. Исключение указанных двух отношений позволяет получить так называемые пробные проектные отношения.
ПРОБНЫЕ ПРОЕКТНЫЕ ОТНОШЕНИЯ
КОЛЛ ЕД Ж (НазвКолледжа, назв-стадиона, вмест—стадиона, назв—футб—пол я,размеры—футб—пол я, список-студ)
СЛУЖАЩИЙ (Служ #.фам-служ. адрес—служ, дтел-служ,ртел—служ,должность,НазвКоллдежа)
СУДЬЯ (судья #.Фам-суд.адрес-суд .дтел-суд. вид—спорта—в—котором—имеет-офиц-статус) ТРЕНЕР(Тренер#.Видспрт)
ВИДСПОРТА (Видспрт. #—предс-ком-по-правилам) СТУДЕНТ (Студент#.пол.возраст.средн-оценка.
общее—число-зач—часов,адрес-студ,
НазвКолледж,зач—часов—в—данном-семестре, зач—часов—поел—два—семестра)
КУЛЬТИВИРУЕТ (НазвКолледжа.Видспрт) УЧАСТВУЕТ (Видспрт. Студент# ,соревн-сезоны) РАСПИСАНИЕ (Хозяева.Гости.судья#.Видспрт .дата.
время—нач—соревн)
Отношение РАСПИСАНИЕ в этом наборе является единственным, которое требует модификации. Если проанализировать несколько экземпляров этого отношения, то обнаружится присутствие наборов повторяющихся данных, что является следствием назначения более чем одного официального представителя на каждое соревнование, проводимое лигой. Один способ разрешения данной проблемы состоит в перепроектировании той части ER-диаграммы, которая относится к официальным представителям. Это необходимо сделать таким образом, чтобы в результате были получены НФБК-отношения. Другой способ решения той же проблемы заключается в декомпозиции отношения РАСПИСАНИЕ с помощью ФЗ. Эти подходы предлагаются в качестве упражнений в конце главы. Все отношения из пробного набора необходимо проверить на соответствие НФБК-форме, что также предлагается в качестве упражнения в конце главы.
Задачи к гл. 8
Следующие задачи касаются последнего набора проектных отношений из раздела 8.4:
начертите диаграмму ФЗ для каждого отношения и проверьте, находятся ли эти отношения в НФБК; если отношение не находится в НФБК, то попытайтесь применить два подхода к решению: (1) изменение ER-диаграммы способом, приводящим к генерации НФБК-отношений; (2) декомпозиция всех отношений, не находящихся в НФБК, с целью перехода к нормальной форме;
сформируйте экземпляры окончательных проектных отношений и покажите, как они будут использоваться при получении ответов на типичные запросы, поступающие со стороны руководящего состава лиги. 2. Обсудите в деталях, как следующие уточнения повлияют на ER-диаграмму, показанную на рис. 8.7, и окончательные проектные отношения:
судья может обслуживать несколько видов спорта;
тренер может быть главным тренером по более чем одному виду спорта;
некоторые колледжи не культивируют футбол и не имеют футбольных полей;
удалите бинарные связи КУЛЬТИВИРУЕТ, ОБУЧАЕТСЯ, УЧАСТВУЕТ и замените их одной трехсторонней связью;
по некоторым видам спорта, например гольфу, судьи не требуются;
3. Начертите ER-диаграмму и составьте отношения для БД торговца подержанными автомобилями. Торговец содержит штат служащих, в который входят агенты по продаже, секретари и механики. Агенты по продаже получают оклад плюс комиссионные, в то время как все остальные служащие получают почасовую оплату. Комиссионные составляют 5% для тех агентов по продаже, стаж работы которых менее трех лет, и 8% для тех, чей стаж составляет 3 и более лет. Информация об имеющихся в наличии автомобилях включает в себя дату покупки, оценочную стоимость, объем ремонтных работ, которые должны быть выполнены до выставления на продажу, приблизительную стоимость этих работ, марку, модель, год выпуска и основной цвет. Некоторые механики выполняют специальные виды работ, например, капитальный ремонт двигателя, исправление вмятин и др. Можно добавить любые уместные по вашему мнению атрибуты.
dBASE Ш-РЕАЛИЗАЦИЯ БД СЕКРЕТАРЯ КЕГЕЛЬНОЙ ЛИГИ
Эта глава подразделяется на три основные части: 1 - содержит примеры листингов четырех отношений, формирующих БД секретаря кегельной лиги, для случая их реализации в dBASE III; 2 - содержит примеры того, как команды dBASE III могут быть использованы при получении ответов на простые запросы; 3 - посвящена углубленному обсуждению набора управляемых с помощью меню программных модулей dBASE III, отвечающих на сложные запросы с помощью команд, встроенных в язык программирования СУБД. БД реализована на базе IBM PC с объемом оперативной памяти 256 Кбайт, двумя двухсторонними дисководами и монохромным монитором. Системный диск dBASE III всегда располагается на дисководе А, программным модулям и файлам БД отводится дисковод В.
Анализ отношений БД с помощью тестовых данных при использовании dBASE III
Прежде чем приступать к обсуждению специальных запросов и различных программных модулей необходимо проанализировать реальные отношения БД. Тестовые данные БД были подготовлены с учетом следующих предположений:
В кегельной лиге состоят 6 команд.
В каждой команде 4 игрока.
Продолжительность сезона - четыре недели.
Ввод данных, охватывающих эти 4 недели, был осуществлен с помощью стандартных команд dBASE III APPEND и EDIT.
Все игроки участвовали во всех встречах.
Возможные изменения в некоторых из этих предположений приводятся в качестве упражнений в конце главы в перечне задач.
На рис. 9.1 - 9.4 показана структура каждого отношения и соответствующие им тестовые данные. (Следует помнить, что в терминологии dBASE III
файлом базы данныхфайлом базы данныхкаждое отношение называется (.dbf).)
файлом базы данных
файлом базы данных
. list off THUMBWEEK LAKE
111
212
314
413
516
615
124
225
322
426
521
623
133
236
331
. list structure434
Structure for database : B:sched.dbf 535 Number of data records :24632
Date of last update : 05/09/86145
FieldField name Type Width Dec 241
THUMBNumeric1343
WEEKNumeric14 42
LANENumeric1544
** Total **4646
(6)
Рис. 9.1. Структура (а) и содержимое (б) отношения SCHED
. use team . list structure Structure for database : В-.team, dbf Number of data records :6
Date of last update : 05/10/86 FieldField name Type Width Dec
THUMBNumeric1
TNAMECharacter15
CAPTNCharacter15
** Total **32
list off
TNUMB
TNAME
CAPTN
1
AlleyCats
Энн Джонс
2
Ineonsistents
Билл Блак
3
TenPins
Лиза Мур
4
HiRollers
Джиа Миллер
5
Splitters
Рой Лейн
6
SandBaggers
Синди Фокс
(б)
Рис. 9.2. Структура (а) и содержимое (б) отношения TEAM
При изучении данных в отношении BOWLER) обращает на себя внимание большой объем дублирования информации, касающейся адресов и телефонных номеров. Является ли функциональной следующая зависимость
phone -> stret
. use bowler . 11st structure Structure for database : В:bowler.dbf Number of data records :24
Date of last update : 05/20/86
Field
Field name
Type
Width
Dec
1
BNAME
Character
15
2
TNUMB
Numeric
1
3
PHONE
Character
8
4
STRET
Character
20
5 STAVG ** Total **
Numeric
3
48
(a)
. list off
BNAME
TNUMB
PHONE
STRET
STAVG
Джин Адамс
5
689-1234
10
Robin St
111
Стив Адамс
5
689-1234
10
Robin St
130
Била Блак
2
689-2345
15
Bluebird Ln
149
Бонни Блак
2
689-2345
15
Bluebird Ln
120
Бо Блоу
2
NONE
12
Meadowbrook
Ln
143
Джо Блоу
2
NONE
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
Лиза Мур
3
689-8901
11
Lark Dr
115
Майк Мур
3
689-8901
11
Lark Dr
140
Джим Смит
1
689-9012
13
Finch Dr
152
Мари Смит
1
689-9012
13
Finch Dr
115
Рассел Тейлор
6
689-0123
20
Cardinal St
161
Руфь Тейлор
6
689-0123
20
Cardinal St
119
Дан Уайт
4
689-2143
16
Robin St
158
Джейн Уайт
4
689-2143
16
Robin St
121
Рис. 9.3. Структура (а) и содержимое (б) отношения BOWLER
. use scores . list structure Structure for database : В:scores.dbf
Number of data records :96
Date of last update : 05/20/86
Field
Field name
Type
Width
Dec
1
BNAME
Character
15
2
WEEK
Numeric
1
3
GAME1
Numeric
3
4
GAME2
Numeric
3
5 GAMES ** Total **
Numeric
3
26
.list off for week <= 2.list off for week >- 3
BHAME WEEK GAME 1 GAME2 GAMES BHAME WEEK GAME 1 GAME2 GAMES
Джин Адамс
1
119
120
94
Дхин Адамс
3
123
134
124
Стив Адамс
1
112
140
138
Стив Адамс
3
134
156
135
Вида Блак
1
137
155
155
Билл Блак
3
156
165
162
Бонни Блак
1
120
125
115
Бонни Блак
3
123
119
111
Бо Блоу
1
160
145
125
Бо Блоу
3
165
121
158
Дхо Блоу
1
101
91
93
Дхо Блоу
3
89
120
99
Ахим Смит
1
160
150
146
Ахим Смит
3
164
165
145
Мари Смит
1
120
110
115
Мари Смит
3
112
114
132
Энн Дхонс
1
98
110
107
Энн Дхонс
3
108
109
112
Дхон Дхонс
1
145
150
134
Дхон Дхонс
3
145
146
144
Дхо Браун
1
140
127
129
Дхо Браун
3
136
144
125
Сыо Браун
1
121
128
124
Сыо Браун
3
124
123
119
Синди Фокс
1
119
110
83
Синди Фокс
3
99
ПО
107
Рэнди Фокс
1
143
150
148
Рэнди Фокс
3
150
161
146
Рассел Тейлор
1
167
150
166
Рассел Тейлор
3
189
179
167
Руфь Тейлор
1
110
125
122
Руфь Тейлор
3
135
112
132
Дхой Лейн
1
126
127
122
Дхой Лейн
3
123
132
105
Рой Лейн
1
145
180
176
Рой Лейн
3
201
202
156
Дхил Миллер
1
111
101
112
Дхил Миллер
3
108
112
101
Поль Миллер
1
180
196
134
Поль Миллер
3
198
167
185
Дан Уайт
1
156
163
154
Дан Уайт
3
161
162
149
Дхейн Уайт
1
130
125
108
Дхейн Уайт
3
119
123
141
Лиза Мур
1
99
120
111
Лиза Мур
3
121
107
104
Майк Мур
1
150
149
121
Майк Мур
3
148
148
151
Дхин Адамс
2
120
125
100
Дхин Адамс
4
111
121
100
Стив Адамс
2
130
146
140
Стив Адамс
4
131
127
132
Билл Блак
2
154
149
148
Билл Блак
4
137
169
154
Бонни Блак
2
120
130
110
Бонни Блак
4
119
121
ИЗ
Бо Блоу
2
159
135
125
Бо Блоу
4
143
157
147
Дхо Блоу
2
105
91
90
Дхо Блоу
4
89
99
98
Ахим Смит
2
160
160
170
Ахим Смит
4
158
163
169
Мари Смит
2
120
ПО
90
Мари Смит
4
116
117
97
Энн Дхонс
2
100
по
ПО
Энн Дхонс
4
103
68
121
Дхон Дхонс
2
158
138
135
Дхон Дхонс
4
148
137
158
Дхо Браун
2
139
138
125
Дхо Браун
4
130
127
146
Сыо Браун
2
126
124
ПО
Сыо Браун
4
124
126
128
Синди Фокс
2
104
90
108
Синди Фокс
4
104
109
ПО
Рэнди Фокс
2
150
137
163
Рэнди Фокс
4
152
153
154
Рассел Тейлор
2
160
165
150
Рассел Тейлор
4
165
158
202
Руфь Тейлор
2
130
123
108
Руфь Тейлор
4
119
123
117
Дхой Лейн
2
130
115
120
Дхой Лейн
4
126
130
128
Рой Лейн
2
183
179
138
Рой Лейн
4
170
168
186
Дхил Миллер
2
ПО
98
103
Дхил Миллер
4
ПО
118
105
Поль Миллер
2
180
174
178
поль Миллер
4
176
202
181
Дан Уайт
2
161
155
156
Дан Уайт
4
156
149
157
Дхейн Уайт
2
124
119
130
Дхейн Уайт
4
124
121
115
Лиза Мур
2
120
102
100
Лиза Мур
4
ПО
126
106
Майк Мур
2
151
140
125
Майк Мур
4
145
148
162
(6)
Рис. 9.4. Структура (а) и содержимое (б) отношения
SCORES
Если да, то отношение bowler не находится в НФБК и исходное проектирование БД - некорректно. Однако
имеются две причины, по которым рассматриваемая зависимость не может быть признана корректной ФЗ.
Очевидна возможность отсутствия телефонов у двух людей, проживающих по разным адресам. В таких случаях может быть использовано слово NONE для номера телефона; однако адрес не будет функционально зависеть от номера телефона.
Возможно, что используемый в БД номер телефона является, скорее, номером, по которому с игроком можно связаться, а не номером домашнего телефона. Это также служит причиной некорректности предложенной ФЗ.
С учетом этих предположений некоторые названия улиц (адреса) и номера телефонов, представленные в отношении BOWLER, дублируются, но не являются избыточными.
9.2. Ответы на запросы секретаря лиги в dBASE III
Цель данного раздела состоит в иллюстрации того факта, что на простые запросы к БД секретаря можно получить ответы непосредственно с помощью команд dBASE III, не прибегая к использованию языка программирования БД. Все запросы данного раздела применяются к отношениям, представленным на рис. 9.1-9.4. В большинстве случаев ответ на запрос требует составления последовательности из двух или более базовых команд. Читателю рекомендуется создать БД и выполнять каждый из предлагаемых запросов по мере обсуждения. Если читателю предпочтительнее работать с R:base 5000, а не с dBASE III, ему следует просто прочитать приведенные в данном разделе запросы и реализовать БД, описанную в гл. 10.
В примерах, приводимых в настоящем разделе, полагается, что системная дискета с dBASE III установлена на устройстве А, а дискета с отношениями БД - на устройстве В. Прежде чем будет использована какая-либо команда dBASE III, необходимо назначить диск по умолчанию устройству В. Это выполняется с помощью одной команды
SET DEFAULT ТО В
ЗАПРОС #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Джо БраунbnameДжо Браунphone 689-4567phone 689-4567
bname
Джо Браун
bname
Джо Браун
phone 689-4567
phone 689-4567
Сью Браун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
Джин Адамс
Стив Адамс
Джил Миллер
Поль Миллер
Дан Уайт
Джейн Уайт
При использовании $-оператора, любого другого оператора или функции, предназначенной для извлечения подстроки из более длинной строки символов, пользователь должен быть уверен в том, что в дан-
ных отсутствуют строки, приводящие к получению ошибочных данных. Например, адрес “21 BlueRobin St“ появится в качестве ответа на последний запрос, хотя названием улицы и является “BlueRobin“, а не просто “Robin“. Один из простых путей контроля заключается в возврате полного названия улицы и адреса в выходных данных.
ЗАПРОС #6: “Сколько к настоящему времени проведено трехматчевых серий, в которых набрано в сумме более 550 очков?“.
Удовлетворить этот запрос можно с помощью команды COUNT. Ответ также требует проведения операции суммирования:
.USE scores
.COUNT FOR garnet 4- game2 4- game3 > 550
Ответ: 2 - записи. Ответ говорит о том, что к настоящему времени были проведены только две такие трехматчевые серии.
ЗАПРОС #7: “Кто является капитаном команды соперников команды с номером 5 на неделе с номером 3?“
Уровень квалификации, требующийся для ответа на этот запрос, существенно выше того уровня, который был необходим для ответа на предыдущие запросы; данные, получаемые из одного отношения, должны быть использованы во втором отношении для получения желаемого результата. Для ответа на запрос секретарь лиги должен, прежде всего, получить ответ на запрос #4 с целью определения площадки, назначенной команде с номером 5 на третьей неделе. Ответом в данном случае будет lane = 5. Так как оппонентам назначаются смежные площадки, секретарь вправе заключить, что противнику команды 5 будет назначена площадка 6. Отсюда следует, что номер команды (tnumb) соперников команды 5 на неделе 3 может быть получен с помощью последовательности команд
LIST OFF tnumb FOR lane = 6 .AND. week = 3
Ответом будет tnumb = 2. Становится возможным определение имени-и-фамилии капитана команды соперников и делается это следующим образом:
.USE team
.LIST OFF captn FOR tnumb - 2
Таким образом ответом на исходный запрос будет сар1п=Билл Блак.
Ответ на запрос #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-ошибки, которая может возникнуть при установке рабочих об-
ластей 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 * п кортежей.) Желаемый результат по запросу #9 может быть получен с помощью
.CLEAR ALL .SELECT 2
.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. Основное меню заранее подготовленных запросов
В предыдущем разделе были детально рассмотрены пути получения ответов на некоторые простые запросы. При этом предполагается, что секретарь кегельной лиги вводит команды непосредственно с терминального устройства. По мере усложнения запросов последо-
вательности команд, необходимые для получения ответов, становятся слишком длинными и сложными для их непосредственного ввода секретарем. В таких случаях список потенциально полезных запросов может быть помещен в меню, которое и выводится на экран терминала. Выбор секретарем одного из запросов приводит к исполнению программы, написанной на языке программирования dBASE III, реализующий ответ на этот запрос. В последующих разделах этой главы детально рассматривается такое меню. Запросы, помещенные в меню, признаны разумными, однако список их не является исчерпывающим и может быть расширен без излишних сложностей.
Образец меню, видимый секретарем во время исполнения программы, показан на рис. 9.5. Главный программный модуль, осуществляющий отображение указанного меню и принимающий выбор запроса, называется “sdbmain.prg“. Этот модуль показан на рис. 9.6. При выборе любой из первых пяти возможностей осуществляется исполнение некоторого другого программного модуля. Некоторые из этих модулей второго уровня осуществляют вызов других модулей, решающих более мелкие задачи. Все программные модули, относящиеся к главному меню, детально обсуждаются в следующих разделах этой главы.
МЕНЮ ЗАПРОСОВ ПО СОСТОЯНИЮ В НОЧЬ НА ПОНЕДЕЛЬНИК
2222222222222222222222222222222222222222222222222
- СТАТИСТИЧЕСКИЕ ДАННЫЕ ПО ОТДЕЛЬНОМУ ИГРОКУ
- ОБЩЕЕ ЧИСЛО ОЧКОВ КАЖДОЙ КОМАНДЫ
- ВЫВОД ПОЛОЖЕНИЯ КОМАНД
- ВЫВОД РАСПИСАНИЯ ВСТРЕЧ ДЛЯ ДАННОЙ НЕДЕЛИ
- ГЕНЕРАЦИЯ ОТЧЕТА О РЕЗУЛЬТАТАХ СЕЗОНА
- ВОЗВРАТ НА УРОВЕНЬ КОМАНД DBASE III
Выберите альтернативу из предложенного меню вариантов
. type sdbmain.prg
***********ПРОГРАММА ГЛАВНОГО МЕНЮ ДЛЯ БД СЕКРЕТАРЯ********** * Имя программы: ” sdbmain.prg"
* Автор Глен А.Джексон
* Оклендский университет, Рочестер, MI 48063 CLEAR
SET TALK OFF
CLOSE DATABASES SET DEFAULT TO В PUBLIC max_wk,bavg,hndkp,saveit * Вывод меню запросов для пользователя и выбор альтернативы DO WHILE Л.
CLEAR
0 5,10 SAY 'МЕНЮ ЗАПРОСОВ ПО СОСТОЯНИЮ В НОЧЬ НА ПОНЕДЕЛЬНИК' 0 6,10 SAY '-=========-=======-======—===-=-=-—««———' 0 9,10 SAY ' 1 - СТАТИСТИЧЕСКИЕ ДАННЫЕ ПО ОТДЕЛЬНОМУ ИГРОКУ' 011,10SAY'2-ОБЩЕЕ ЧИСЛО ОЧКОВ КАЖДОЙ КОМАНДЫ'
013,10SAY'3-ВЫВОД ПОЛОЖЕНИЯ КОМАНД'
015,10SAY'4-ВЫВОД РАСПИСАНИЯ ВСТРЕЧ ДЛЯ ДАННОЙ НЕДЕЛИ'
017,10SAY'5-ГЕНЕРАЦИЯ ОТЧЕТА О РЕЗУЛЬТАТАХ СЕЗОНА'
019,10SAY'6-ВОЗВРАТ НА УРОВЕНЬ КОМАНД DBASE IIГ
0 22,10 SAY 'Выберите альтернативу из меню вариантов' WAIT ' ' ТО choice
DO CASE
CASE choice = 'Г
STORE 'SDB' TO eos_check DO b:bwlrst
CASE choice * '2' DO b:teampns 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 'ВЫ ВВЕЛИ НЕПРАВИЛЬНЫЙ НОМЕР I!!!' DO b:delay
ENDCASE
CLOSE DATABASES
ENDDO■
Логику модуля sdbmain.prg отражает приведенная ниже последовательность действий, исполнение которой завершается при выборе возможности 6.
Отобразить основное меню.
Ждать ввода.
Если ввод корректен, то передать управление соответствующему программному модулю
Иначе
вывести сообщение об ошибке; выдержать приблизительно двухсекундную паузу; вернуться на шаг 2.
. type delay.prg
**************** модуль ДВУХСЕКУНДНОЙ ПАУЗЫ ********** *
*Имя модуля "delay.prg”.
*Автор Глен А.Джексон
*Оклендский университет, Рочестер, MI 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. Единственное действие этой программы состоит в выполнении цикла столько раз, сколько необходимо для истечения приблизительно двух секунд.
ЕСЛИ eos_check = rSDB' ПРИ ВЫПОЛНЕНИИ BWLRST.PRG:
Выполнение модуля findwk.prg с целью нахождения последней недели, для которой результаты встреч (scores) были занесены в отношение SCORES. Значение возвращается в "max_wk".
Ввод номера недели сезона, по которой требуются статистические данные, в переменную "wk" и проверка правильности введенного значения.
Ввод имени-и-фамилии игрока, о котором требуется получить статистическую информацию, в переменную "паше" и проверка правильности введенного значения.
Каждый кортеж в отношении SCORES, в котором значение атрибута bname совпадает со значением пате и значение атрибута week меньше или равно значению wk, подвергается следующим действиям:
проверка gamel, game2, датеЗ на предмет превышения каким-либо из содержащихся в них значений текущей величины hi_game; в случае подтверждения соответствующее значение сохраняется в hi_game;
проверка суммы gamel, game2, датеЗ на предмет превышения ею текущего значения hi_series; в случае подтверждения эта сумма сохраняется в hi_series;-
прибавление суммы gamel, game2 и датеЗ к величине tot_pins.
Вычисление результативности данного игрока, гандикапа и сохранение их в переменных bavg и hndkp соответственно.
Вывод результатов.
ЕСЛИ eos_check = 'EOS' ПРИ ВЫПОЛНЕНИИ BWLRST.PRG:
Блоки с номерами 1, 2, 3 и 6 опускаются. Выполняются только блоки с номерами 4 и 5.
Рис. 9.8. Логика модуля bwlrst.prg
Программный модуль BWLRST.PRG
Этот модуль вызывается из программы sdbmain.prg в том случае, когда осуществляется выбор возможности
“1 - СТАТИСТИЧЕСКИЕ ДАННЫЕ ПО ОТДЕЛЬНО МУ ИГРОКУ". Результатом выполнения этого модуля являются вычисления и вывод статистических данных, характеризующих конкретного игрока, на конец конкретной недели сезона. Модуль запрашивает порядковый номер недели, на конец которой требуются статистические данные, а также имя-и-фамилию игрока. Модуль проверяет достоверность как имени-и-фами- лии, так и номера недели. Общая логика модуля приведена на рис. 9.8, реализация в dBASE III - на рис. 9.9, а типичные выходные данные модуля - на рис. 9.10.
. type bwlrst.prg
**************************************************************
*Имя процедуры: "bwlrst.prg"
*Автор Глен А.Джексон
*Оклендский университет, Рочестер, MI 48063 *
*Данная процедура осуществляет вычисления и вывод следующих Статистических данных, касающихся отдельного игрока: High* Heries (лучшая серия),High-game (лучшая игра), Total pins *(общее число набранных очков),average (результативность) и Handicap (гандикап). Во всех статистических данных учтены все Состоявшиеся к тому времени встречи.
Процедура вызывается из sdbmain.prg *
CLEAR
*
Инициализация переменных текущего суммирования и переменных- Счетчиков
STORE 0 ТО hi_series,tot_pins,hi_game
STORE 1 TO ctr
SELECT 1■
USE b:scores
*
выполнение следующей части кода осуществляется только в слу- *чае вызова из главного меню
*
IF eos_check = 'SDB'
*
*Поиск последней недели, для которой были введены результаты, *через переменную maxwk.
DO b:findwk
STORE 1 1 TO wk DO WHILE .t.
0 7.15 SAY 'ЕСЛИ ВАМ ТРЕБУЮТСЯ ПОСЛЕДНИЕ СТАТ. ДАННЫЕ,' 0 8,15 SAY 'ВВЕДИТЕ ' + STR(max_wk,2)+ ;
' НОМЕР ПОСЛЕДНЕЙ НЕДЕЛИ, ПО КОТ. ВВОДИЛИСЬ ДАННЫЕ' 0 9,15 SAY 'ИНАЧЕ ВВЕДИТЕ НОМЕР ИНТЕРЕСУЮЩЕЙ ВАС НЕДЕЛИ' 0 11,15 GET wk READ IF VAL(wk) > max_wk .OR. VAL(wk) < 1
0 15,10 SAY 'НЕПРАВИЛЬНЫЙ ВВОД НОМЕРА НЕДЕЛИ !!!!' DO b:delay STORE ' ' TO wk CLEAR ELSE-
CLEAR EXIT.
ENDIF
ENDDO
*Ввод имени-и-фамилии игрока и проверка их корректности *
STORE '' ТО пате
*
DO WHILE .t.
0 7,20 SAY "УКАЖИТЕ ИМЯ И ФАМИЛИЮ ИГРОКА, напр. Джо Дхонси 0 8,20 GET пате READ COUNT FOR bname = name TO check IF check « 0
0 12,20 SAY 'УКАЗАННЫЕ ИМЯ И ФАМИЛИЯ В БД ОТСУТСТВУЮТ'
0 13,20 SAY 'ПРОВЕРЬТЕ ИХ И ПОВТОРИТЕ ВВОД' DO b:delay STORE '' ТО name
CLEAR ELSE
EXIT ENDIF ENDDO ENDIF *
GOTO TOP
DO WHILE ctr <« VAL(wk) LOCATE FOR bname « name .AND. week = ctr IF gamel > hi_game
STORE gamel TO hi_game ENDIF
IF game2 > hi_game
STORE game2 TO hi_game ENDIF
IF game3 > hi_game *
STORE game3 TO hi_game
ENDIF
STORE gamel + game2 + gameS TO totS
STORE tot_p1ns + totS TO tot_pins
IF totS > hi_series
STORE totS TO hi_series
ENDIF
STORE ctr + 1 TO ctr
ENDDO
STORE INT(tot_pins/(VAL(wk)*3)) TO bavg
IF bavg < 200
STORE INT((200 - bavg)* 0.75) TO hndkp
ELSE
STORE 0 TO hndkp
ENDIF.
*
*Эта часть программы выполняется только в случае вызова из *главного меню
*
IF eos_check = 'SDB'■
CLEAR
6 7,20SAY 'СТАТИСТИКА AAR'+TRIM(bname)+'HA КОНЕЦ НЕДЕЛИ '+wk
О 8,20 SAY '=========================================='
6 10,20 SAY 'СРЕДНЕЕ ЧИСЛО ОЧКОВ ЗА ИГРУ: '+ STR(bavg,3)
6 12,20 SAY 'ОБЩЕЕ ЧИСЛО ОЧКОВ - БЕЗ ГАНДИКАПА: '+; STR(tot_pins,4)
6 14,20 SAY 'ЛУЧШИЙ- РЕЗУЛЬТАТ ЗА ИГРУ НА СЕГОДНЯ: ' +; STR(hi_game,3)
6 16,20 SAY 'ЛУЧШАЯ СЕРИЯ НА СЕГОДНЯ: ' + STR(hi_series,3)
6 18,20 SAY 'ТЕКУЩИЙ ГАНДИКАП: ' + STR(hndkp,3)
6 22,20 SAY ' ' WAIT
CLEAR
ENDIF
RETURN •
Рис. 9.9. (Окончание)
Два момента, связанные с модулем bwlrst.prg, возможно, нуждаются в дополнительном освещении. Первый заключается в появлении двух предложений “IF eos—check='SDB'“ в теле модуля. Модуль bwlrst.prg вызывается из двух различных программных модулей: sdbmain.prg и eosrpt.prg. Когда bwlrst.prg вызывается
из eosrpt.prg, то большая часть логики модуля пропускается, так как в этом случае имя-и-фамилия игрока и порядковый номер недели уже известны. Перед вызовом bwlrst.prg из sdbmain.prg в eos-check заносится значение “SDB“, в то время как перед вызовом из eosrpt.prg в eos-check заносится значение 44EOS44.
Второй момент связан с вычислением величины гандикапа. Гандикап определяется как три четвертых от разности между текущим значением результативности игрока и числом 200, причем отрицательные значения для гандикапа не допускаются. Результативность игрока и его гандикап являются целочисленными величинами, полученными с помощью отбрасывания дробной части, но не округления. Если бы отбрасывание не использовалось в обоих случаях, то это в значительной степени изменило бы положение команд.
СТАТИСТИСТИКА ДЛЯ Джин Адамс НА КОНЕЦ НЕДЕЛИ 3
СРЕДНЕЕ ЧИСЛО ОЧКОВ ЗА ИГРУ: 117
ОБЩЕЕ ЧИСЛО ОЧКОВ - БЕЗ ГАНДИКАПА: 1059
ЛУЧШИЙ РЕЗУЛЬТАТ ЗА ИГРУ НА СЕГОДНЯ: 134
ЛУЧШАЯ СЕРИЯ НА СЕГОДНЯ: 381
ТЕКУЩИЙ ГАНДИКАП: 62
Рис. 9.10. Типичный результат, получаемый при выборе альтернативы “Г4 в главном меню
Программный модуль TEAMPNS.PRG
Этот модуль вызывается из sdbmain.prg в том случае, когда выбирается возможность “2 - ОБЩЕЕ ЧИСЛО ОЧКОВ КАЖДОЙ КОМАНДЫ4. Данный программный модуль обращается к findwk.prg с целью определения последней недели, по которой в отношение SCORES вносились данные, после чего определяет и выводит общее число 44чистых44 очков (без учета гандикапа), набранных каждой командой. Пример выходных данных модуля teampns.prg приведен на рис. 9.11. Логика модуля представлена на рис. 9.12, а собственно модуль показан на рис. 9.13.
ОБЩЕЕ ЧИСЛО ЧИСТЫХ ОЧКОВ НА КОНЕЦ НЕДЕЛИ 4
НОМЕР КОМАНДЫ НАЗВАНИЕ КОМАНДЫ ОБЩЕЕ ЧИСЛО ОЧКОВ
1
AlleyCats
6257
2
Ineonsistents
6172
3
TenPins
6147
4
HiRollers
6798
5
Splitters
6580
6
SandBaggers
6534
Рис. 9.11. Пример результатов выполнения модуля
teampns.prg
Выполнение модуля findwk.prg с целью определения последней недели, для которой в отношение SCORES были внесены данные о показанных результатах.
Вывод заголовка для данных, которые будут выведены ниже.
Для каждой команды (используя переменную ctr одновременно как номер команды и счетчик цикла) ВЫПОЛНИТЬ следующее:
соединить оператором JOIN отношения SCORES и BOWLER, где bowler->tnumb = номер выбранной команды и bowler- >bname = scores->bname, с целью формирования нового отношения ТЕМР2, содержащего только атрибуты (FIELDs-ПОЛЯ) gamel, game2 и датеЗ; ТЕМР2 будет содержать результаты всех встреч для одной команды по состоянию на текущую неделю (включительно);
определить название команды с помощью отношения TEAM, воспользовавшись идентифицирующим команду номером; сохранить название команды как "паше";
используя отношение ТЕМР2, вычислить сумму набранных данной командой очков и вывести общий командный результат;
удалить оператором ERASE временное отношение temp2.dbf из БД;
добавить приращение к номеру команды (ctr) с целью получения его следующего значения
. type teampns.prg **************************************************************
*Имя процедуры: "teampns.prg'
*Автор Глен А.Джексон *Оклендский университет, Рочестер, MI 48063 *Данная процедура предназначена для вывода общего числа очков, *набранных каждой командой на данный момент времени текущего *сезона
*Процедура вызывается из sdbmain.prg CLEAR
CLOSE DATABASES
SELECT 1 USE b:bowler SELECT 2 USE b:scores Нахождение последней недели, no которой данные о результатах *были введены в БД - возврат через переменную max wk DO b:findwk
*Вывод заголовка данных
0 5,20 SAY 'ОБЩЕЕ ЧИСЛО ЧИСТЫХ ОЧКОВ НА КОНЕЦ НЕДЕЛИ '+; STR(max_wk,3)
0 6 20 SAY ’s=3sssasssaa====s=sss^ss====s==ss=sa=a=====ss=axs' 0 7,’20 SAY 'НОМЕР КОМАНДЫ НАЗВАНИЕ КОМАНДЫ ОБЩЕЕ ЧИСЛО ОЧКОВ' 0 8,20 SAY ' '
*
К применению любого оператора JOIN в программах следует подходить осторожно, не допуская получения в результате таких применений отношений, слишком больших для хранения в том объеме памяти, который доступен на используемом диске. Генерируемое оператором JOIN, используемым в модуле teampns.prg, отношение ТЕМР2 всегда будет состоять из
(3 игры/в неделю) * (4 игрока/в команде) * (N недель)
кортежей. Например, для четвертой недели сезона (N - 4) каждое построенное отношение ТЕМР2 дает в итоге 48 кортежей.
. type findwk.prg
*************************** рл^оук PRG *********************** *Имя модуля: "findwk.prg"
*Автор Глен А.Джексон
*Оклендский университет, Рочестер, MI 48063 *
*Данный модуль предназначен для определения наибольшего *значения номера недели, занесенного в поле атрибута week, либо Отношения scores.dbf, либо отношения sched.dbf. Модуль *выполняется в предположении, что либо
*scores.dbf, либо sched.dbf находится в активном состоянии *
*Вызывается из следующих модулей:
* bwlrst.prg, teampns.prg, teamstd.prg, wkschdl.prg и *eosrpt.prg
*
*Наибольшее значение возвращается в виде целой переменной *max_wk
*
0 10,15 SAY 'ПРОИЗВОДЯТСЯ ВЫЧИСЛЕНИЯ — ПОДОЖДИТЕ НЕМНОГО !' maxwk - 0
GOTO TOP
DO WHILE .NOT. EOF()
IF week > max_wk
max_wk = week
ENDIF
SKIP
ENDDO *
CLEAR RETURN
Модуль teampns.prg вызывает findwk.prg с целью определения последней недели сезона, для которой набранные очки были внесены в отношение SCORES. Этот модуль приведен на рис. 9.14. Логика модуля требует одного пояснения. Цель модуля состоит в выявлении наибольшего значения атрибута week для текущего активного файла БД. Это значит, что отношение (.dbf), в котором будет осуществляться поиск, должно быть активировано до начала выполнения модуля findwk.prg. Так как в оба отношения SCORES и SCHED включено поле week в качестве атрибута, следовательно, одно из этих отношений может быть активировано до обращения к модулю findwk.prg. Если SCORES является активным, то значение week определяется как последняя неделя, для которой результаты встреч были занесены в БД; однако если активным является отношение SCHED, то значение week определяется как последняя неделя сезона. Модуль findwk.prg используется для определения обоих значений поля week.
РАСПИСАНИЕ НА НЕДЕЛЮ 2 СЕЗОНА
КОМАНДА НОМЕР ПЛОЩАДКИ
AlleyCats4
Ineonsistents5
TenPins2
HiRollers6
Splitters1
SandBaggers3
Рис. 9.15. Типичный результат выполнения модуля wkschdl.prg
Программный модуль wkschdl.prg
Этот программный модуль вызывается из sdbmain.prg в случае выбора в главном меню возможности “4 - ВЫВОД РАСПИСАНИЯ ВСТРЕЧ ДЛЯ ДАННОЙ НЕ- ДЕЛИ“. Результатом выполнения этого модуля является вывод таблицы названий команд и номеров назначаемых им площадок на данную неделю сезона. Модуль запрашивает на входе номер недели, заносит
это значение в переменную “inval“ и, прежде чем приступать к выполнению, верифицирует это значение. Типичные выходные данные, получаемые в результате выполнения этого модуля, приведены на рис. 9.15. Логика модуля отражена на рис. 9.16, а его текст - на рис. 9.17.
Выполнение модуля findwk.prg с целью нахождения последней недели сезона. Это значение возвращается через переменную ”max_wk”. (Обратите внимание, что отношение SCHED помещается в USE до вызова findwk.prg, и, таким образом, именно в отношении SCHED осуществляет поиск модуль findwk.prg.)
Ввод номера (переменная "inval”) той недели, для которой требуется вывести календарь, и верификация правильности этого номера. Повторение этой процедуры до тех пор, пока не будет введено корректное значение.
Соединение оператором JOIN отношений TEAM и SCHED с учетом выполнения условий sched->week = inval, sched->tnumb = team->tnumb с целью формирования нового отношения, TEMPI, которое содержит только атрибуты tname и lane.
Вывод заголовка.
Вывод значений tname и lane из TEMPI.
Удаление оператором ERASE отношения TEMPI из БД.
Рис. 9.16. Логика программного модуля wkschdl.prg
. type wkschdl.prg
**************************************************************
*Имя процедуры: ’’wkschdl.prg”
*Автор Глен А.Джексон
*Оклендский университет, Рочестер, MI 48063
*Данная процедура осуществляет вывод календаря на текущую *неделю
*На вход поступает номер недели, для которой требуется *календарь
*Результатом является календарь, содержащий названия команд и
*номера назначаемых им площадок
Процедура вызывается из sdbmain.prg
CLEAR
CLOSE DATABASES
SELECT 1
USE b:sched
STORE ' 1 TO inval
*Нахохдение последней недели сезона — значение возвращается в
*переменную max wk
DO b:findwk
DO WHILE .t.
8 7,10 SAY 'ВВЕДИТЕ НОМЕР НЕДЕЛИ, ДЛЯ КОТОРОЙ';
' ТРЕБУЕТСЯ КАЛЕНДАРЬ'■
8 9,10 SAY 'ТОЛЬКО ЗНАЧЕНИЯ В ДИАПАЗОНЕ ОТ 1 ДО ' +; STR(max_wk,2)
8 11,10 GET inval
READ
IF VAL(inval) > max_wk .OR. VAL(inval) < 1 8 15,10 SAY 'НЕКОРРЕКТНЫЙ НОМЕР НЕДЕЛИ !!!!!' DO b:delay STORE ' ' TO inval
EXIT ENDIF ENDDO
8 15,10 SAY 'ПОХАЛУЙСТА, ПОДОХДИТЕ - ВЫПОЛНЯЮТСЯ ВЫЧИСЛЕНИЯ !' SELECT 2.
USE team
SELECT sched
JOIN WITH team TO b:templ FOR week = VAL(inval) .AND. ; tnumb * team->tnumb FIELDS team->tname, lane
*Вывод календаря на экран CLEAR
8 5,10 SAY 'РАСПИСАНИЕ НА НЕДЕЛЮ ' + inval + ' СЕЗОНА'
8 6,10 SAY 'в^ам^е^те^^^^»»^^
8 7,10 SAY ' КОМАНДА НОМЕР ПЛОЩАДКИ'
8 8,10 SAY ' '
SELECT 3
USE b:tempi GOTO TOP STORE 9 TO lineno DO WHILE .NOT. EOF()
8 lineno,10 SAY '' + tname + ''+ STR(lane,2)
STORE lineno+1 TO lineno
SKIP ENDDO 8 22,10 SAY ' ' WAIT
CLEAR
CLOSE DATABASES ERASE b:tempi.dbf RETURN
Сердцевиной реализации вновь является оператор JOIN, с помощью которого создается временное отношение TEMPI. В этом случае отношения TEAM и SCHED соединяются по атрибуту tnumb, так что при формировании выходных данных будет возможно использовать название команды, а не номер.
Программный модуль EOSRPT.PRG
Этот программный модуль вызывается из sdbmain.prg в случае выбора в главном меню возможности "5 - ГЕНЕРАЦИЯ ОТЧЕТА О РЕЗУЛЬТАТАХ СЕЗОНА". Результатом выполнения модуля является определение и вывод имен-и-фамилий тех игроков, кто (1) набрал наибольшее число очков в одной игре сезона, (2) провел лучшую трехматчевую серию сезона, (3) закончил " сезон с наивысшей результативностью.
Пример выходных данных этого модуля при использовании им данных из БД показан на рис. 9.18. Логика модуля описана на рис. 9.19, сам модуль показан на рис. 9.20.
ОТЧЕТ 0 РЕЗУЛЬТАТАХ СЕЗОНА
ЛУЧШИЙ РЕЗУЛЬТАТ ЗА ОДНУ ИГРУ - 202 ОЧКА - ПОКАЗАН ИГРОКАМИ:
Рой Лейн Поль Миллер Рассел Тейлор
ЛУЧШИЕ СЕРИИ ИЗ ТРЕХ МАТЧЕЙ - 559 ОЧКОВ - ПРОВЕЛИ ИГРОКИ:
Рой Лейн Поль Миллер
ЛУЧШАЯ РЕЗУЛЬТАТИВНОСТЬ - 179 ОЧКОВ - ПОКАЗАНА ИГРОКАМИ: Поль Миллер
Рис. 9.18. Выходные данные модуля eosrpt.prg для рассматриваемой БД
Выполнение модуля findwk.prg с целью нахождения последней недели сезона. Это значение возвращается через переменную "max_wk".
Инициализация необходимых переменных.
ВЫПОЛНЕНИЕ следующей последовательности действий до исчерпания кортежей в отношении BOWLER:
сохранение значения bname из текущего кортежа игрока в ’’пате”
выполнение программного модуля bwlrst.prg (после присвоения переменной eoscheck значения 'EOS') с целью определения для данного игрока наилучшего результата, показанного в одной встрече, наилучшей трехматчевой серии и показанной в сезоне результативности; эти значения возвращаются с помощью соответствующих переменных "hi_game", "hi_series" и "bavg";
наибольшее число очков, набранных в одной встрече, среди всех игроков хранится в переменной "best_game"; поэтому если hi-game > best_game, то hi_game сохраняется в best_game и имя-и-фамилия соответствующего игрока сохраняются в HIGHGAME после удаления предыдущих имен-и-фамилий; если hi_game = best_game, то просто выполняется сохранение в HIGHGAME имени-и-фамилии игрока;
Результат наилучшей трехматчевой серии среди всех игроков хранится в переменной "best_series"; поэтому, если hi_series > bestseries, то hi series сохраняется в best_series, и имя-и-фамилия соответствующего игрока сохраняются в HIGHSER после удаления предыдущих имен-и-фами- лий. Если hi_series = best_series, то просто выполняется сохранение в HIGHSER имени-и-фамилии игрока.
Наивысшая результативность среди всех игроков хранится в переменной "best_avg"; поэтому если bavg > best_avg то bavg сохраняется в best_avg, и имя-и-фамилия соответствующего игрока сохраняются в HIGHAVG после удаления предыдущих имен-и-фамилий; если bavg = best-avg, то просто выполняется сохранение в HIGHAVG имени-и-фамилии игрока.
Вывод полученных результатов.
. type eosrpt.prg **************************************************************
*Имя процедуры: "eosrpt.prg”
*Автор Глен А.Джексон
*Оклендский университет, Рочестер, MI 48063 *
*Данная процедура выполняет необходимые при получении отчета о
*результатах сезона вычисления и осуществляет вывод этого *отчета
Процедура вызывается из sdbmain.prg.
*Из этой процедуры вызывается bwlrst.prg. *
CLEAR
*Некоторые данные будут получены из ”bwlrst,prg” с помощью
*PUBLIC-переменных
PUBLIC name, hi_series, h1_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_game, bestavg 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 > bestgame STORE hi_game TO best_game USE b:highgam ZAP APPEND BLANK REPLACE bname WITH name USE
ELSE
IF hi_game = bestgame
USE b:highgam
APPEND BLANK
REPLACE bname WITH name USE ENDIF ENDIF
*
IF hi_series > bestseries
STORE hi_series TO bestseries
USE b:h1ghser
ZAP
APPEND BLANK
REPLACE bname WITH name USE ELSE
IF K1_ser1es = best_ser1es
USE b:h1ghser
APPEND BLANK
REPLACE bname WITH name
USE
ENDIF
ENDIF *
IF bavg > best_avg
STORE bavg TO bestavg
USE b:h1ghavg
ZAP
APPEND BLANK
REPLACE bname WITH name USE ELSE
IF bavg = bestavg
USE b:highavg
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 "b:highgam" ТО fname
DO b:fileout *
в R0W()+2,20 SAY 'ЛУЧШИЕ СЕРИИ ИЗ ТРЕХ МАТЧЕЙ - ' +;
е R0W()+l,20 SAY 'ОЧКОВ - ПРОВЕЛИ ИГРОКИ: '
STORE "b:highser" ТО fname DO b:fileout
@ ROW()+2r20 SAY 'ЛУЧШАЯ РЕЗУЛЬТАТИВНОСТЬ - 4STR(best_avgr3) @ R0W()+l,20 SAY 'ОЧКОВ - ПОКАЗАНА ИГРОКАМИ: '
STORE "b:highavg" TO fname DO b:fileout *
6 24,20 SAY ' ' WAIT
SET SAFETY ON RETURN
B>
Рис. 9.20. (Окончание)
Несколько необычной особенностью eosrpt.prg является способ сохранения имен-и-фамилий игроков, набравших наибольшее равное число очков по данной категории. Фамилии таких игроков сохраняются в унарном отношении, связанном с этой категорией. Названия этих специально создаваемых отношений следующие: HIGHGAM, HIGHSER и HIGHAVG. Унарными эти отношения являются потому, что в каждое отношение входит только один атрибут - Ьпаше. Если во время проверки числа очков, набранных игроком, оказывается, что это число равно по некоторой категории наибольшему на данный момент, то имя-и-фамилия игрока добавляются (оператором APPEND) к соответствующему отношению. Если обнаруживается, что число набранных игроком очков превышает значение, считающееся на данный момент наибольшим, то выполняется команда ZAP с целью удаления старых значений из отношения, после чего к отношению добавляются (оператором APPEND) новые имя-и-фамилия. Все три указанные выше отношения необходимо создать до начала исполнения программы, но в момент начала исполнения модуля eosrpt.prg каждое из этих отношений должно быть
пустым. Все кортежи во всех трех отношениях уничтожаются (команда ERASE) перед завершением eosrpt.prg. Непосредственно перед уничтожением осуществляется вывод содержимого каждого из трех отношений с помощью короткого программного модуля, названного fileout.prg. Листинг этого модуля и точная структура каждого специального отношения приводятся в конце главы.
Программный модуль TEAMSTD.PRG
Этот модуль вызывается из sdbmain.prg в том случае, когда выбирается возможность “3 - ВЫВОД ПОЛОЖЕНИЯ КОМАНД". Результатом исполнения модуля является вывод таблицы побед-поражений всех команд на данную неделю сезона. В начале исполнения модуль запрашивает номер недели, для которой требуется выяснить положение команд. После проверки корректности введенного номера недели программа проводит необходимые для получения числа побед-поражений для каждой команды вычисления и осуществляет вывод положения команд в табличной форме. Также выводится общее число очков, набранных каждой командой.
МЕНЮ ЗАПРОСОВ ПО СОСТОЯНИЮ В НОЧЬ НА ПОНЕДЕЛЬНИК ПОАОХЕНИЕ КОМАНД НА КОНЕЦ НЕДЕЛИ 2
КОМАНДА
ПОБЕД
ПОРАЖЕНИЙ
ОБЩЕЕ ЧИСЛО ОЧКОВ
AlleyCats
5.0
3.0
3106
Inconsistents
2.0
6.0
3038
TenPins
1.0
7.0
3019
HiRollers
7.0
1.0
3358
Splitters
6.5
1.5
3225
SandBaggers
2.5
5.5
3181
Рис. 9.21. Положение команд на конец недели 2 (данные получены в результате выполнения модуля teamstd.prg)
Выполнение модуля findwk.prg с целью нахождения последней недели, для которой вводились данные о набранных очках в отношение SCORES. Это значение возвращается через переменную "maxwk".
Ввод номера недели, для которой требуется получить положение команд, с помощью переменной "in_wk" и проверка правильности введенного номера. Повторение данной процедуры до тех пор, пока не будет получено правильное значение.
Для каждой площадки (In) ВЫПОЛНЕНИЕ следующих действий для каждой недели (wk):
соединение оператором JOIN отношений SCHED и BOWLER с учетом выполнения условий sched->week = wk, sched->lane = In и sched->tnumb = bowler->tnumb с целью формирования нового отношения NAMES, содержащего только атрибуты bname, tnumb и stavg (отношение NAMES будет содержать имена-и-фа- милии всех игроков команды, которая выступала на данной площадке и на данной неделе сезона);
для каждого игрока, имя-и-фамилия которого появляются в отношении NAMES, выполнение следующих действий: нахождение кортежа в SCORES для этого игрока и этой недели;
определение гандикапа этого игрока на этой неделе;
сложение набранных этим игроком очков с общим числом очков, набранных командой в каждой встрече (с учетом гандикапа); при этом используются обозначения: G1A - общее число очков за игру! (game!) для команды, выступавшей на площадке с нечетным номером, a G1B - общее число очков за игру! (game!) для команды соперников, выступавшей на площадке с четным номером; смысл обозначений G2A, G3A, G2B и G3B ясен по аналогии;
замещение оператором REPLACE значения общего числа очков (totpins) в отношении T_STATS старым значением, увеличенным на число очков, набранных в этих трех встречах данным игроком (гандикап не включается);
корректировка записей побед-поражений, касающихся двух последних подвергнувшихся рассмотрению команд; здесь используется соглашение о том, что идентификатор команды, выступавшей на площадке с нечетным номером, оканчивается символом "А" или "а", команды, выступавшей на площадке с четным номером, оканчивается символом "В" или "Ь".
Соединение оператором JOIN отношений T_STATS и TEAM с учетом условий t_stats->tnumb = team->tnumb с целью формирования нового отношения STATS, содержащего только атрибуты wins, losses, tname и totpins.
Вывод положения команд (турнирной таблицы) из отношения STATS.
Удаление оператором ERASE отношения STATS и обнуление соответствующих атрибутов в T_STATS.
B>type teamstd.prg **************************************************************
♦Имя процедуры: "teamstd.prg”
♦Процедура составлена Барбарой А. МакНил ♦Модифицирована Гленом А. Джексоном ♦Оклендский университет, Рочестер, MI 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 b:sched
SELECT 5 USE b:team
♦Нахождение последней недели, по которой были введены ♦результаты - переменная max_wk
SELECT scores DO b:findwk *
♦Ввод номера недели, для которой требуется определить ♦положение
♦команд - переменная in_wk
STORE ' ’ ТО in_wk DO WHILE .t.
8 7,15 SAY 'ЕСЛИ ВАМ ТРЕБУЕТСЯ ПОЛУЧИТЬ ИНФОРМАЦИЮ +; '' О ТЕКУЩЕМ*
0 8,15 SAY 'ПОЛОЖЕНИИ КОМАНД, ВВЕДИТЕ '+STR(max_wk,2)+','
@ 9,15 SAY 'НОМЕР ПОСЛЕДНЕЙ НЕДЕЛИ, ПО КОТОРОЙ'*;
' ВНОСИЛИСЬ ДАННЫЕ'
@ 10,15 SAY 'В ПРОТИВНОМ СЛУЧАЕ ВВЕДИТЕ НОМЕР’*;
*' ТРЕБУЕМОЙ НЕДЕЛИ.'
12,5 GET in_wk
READ
IF VAL(in_wk) > max_wk .OR. VAL(in_wk) < 1 0 15,10 SAY 'НЕКОРРЕКТНЫЙ НОМЕР НЕДЕЛИ!!!!’ DO b:delay
STORE ' ' TO in_wk
CLEAR
ELSE
CLEAR
EXIT
ENDIF
ENDDO *
*Вычисление положения команд для недель, начиная с первой и *кончая той, номер которой содержится в inwk.
*
STORE О ТО G1A,G2A,G3A,G1B,G2B,G3B
STORE 1 ТО In,wk
DO WHILE wk <= VAL(in_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((200-names->stavg)*0.75) TO hndkp ELSE
STORE 0 TO hndkp
ENDIF
ELSE
STORE bname TO ha_name
STORE wk-1 TO haweek DO b:hndkp_avg
ENDIF
IF ln=l .OR. ln=3 .OR. ln=5
STORE gamel+hndkp+GlA TO GIA
STORE game2+hndkp+G2A TO G2A
STORE game3+hndkp+G3A TO G3A
ELSE
STORE gamel+hndkp+GIB TO GIB
STORE game2+hndkp+G2B TO G2B
STORE game3+hndkp+G3B TO G3B
ENDIF
SELECT t_stats
REPLACE totpins WITH ;
totpins+scores->game1+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 MG" + STR(count,1) + "A” TO gamea
STORE "G" + STR(count,1) + "B" 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
ENDIF ENDIF STORE О ТО G1A,G2A,G3A,G1B,G2B,G3B
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 0 5,10 SAY 'МЕНЮ ЗАПРОСОВ ПО СОСТОЯНИЮ В НОЧЬ НА ПОНЕДЕЛЬНИК' 0 6,10 SAY 'ПОЛОЖЕНИЕ КОМАНД НА КОНЕЦ НЕДЕЛИ ' + 1n_wk
9 7,10 SAY '=========================================='
0 9,10 SAY 'КОМАНДА ПОБЕД ПОРАЖЕНИЙ ОБЩЕЕ ЧИСЛО ОЧКОВ'
0 10,10 SAY ' '
DO WHILE .NOT. EOF()
0 R0W()+l,10 SAY tname +' '+STR(wins,4,1)+ ''+ ;
STR(losses,4,1)+''+ STR(totp1ns,5)
SKIP ENDDO SELECT stats USE ERASE b:stats.dbf SELECT t_stats REPLACE ALL wins WITH 0, losses WITH 0, totpins WITH 0 *
0 22,10 SAY ' ' WAIT
RETURN
B>
Рис. 9.23. (Окончание)
На рис. 9.21 показано положение команд на конец второй недели, полученное на основании данных, хранимых в предложенном примере БД. На рис. 9.22
описана общая логика модуля, а его текст - на рис. 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.
Структура временных отношений
Программными модулями eosrpt.prg и teamstd.prg используются несколько отношений, нс являющихся ча-
стью проектируемой БД. Это временные отношения, так как их содержимое является значащим только на время исполнения данного программного модуля. Содержимое этих отношений постоянно создастся и разрушается, и это содержимое перестает быть корректным, как только модуль, их использующий, завершает свою работу.
. 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 приведена структура отношения Т—STATS и его со-
держимое на начало и конец выполнения модуля teampns.prg. Листинг fileout.prg программного модуля, осуществляющего вывод содержимого отношений HIGHGAM, HIGHSER и HIGHAVG, приведен на рис. 9.26.
. use t_stats . list structure Стуктура дая БД: B:t_stats.dbf
Число записей:6
Дата последнего обновления: 11/03/86 ПолеИмя поляТип ДлинаДес
THUMBNumeric1
WINSNumeric41
LOSSESNumeric41
TOTPINSNumeric5
** Всего **15
a
. list offTHUMBWIHS LOSSES TOTPIHS
0.00.00
0.00.00
0.00.00
0.00.00
0.00.00
0.00.00
6
Рис. 9.25. Структура (а) и начальное содержимое (б) временного отношения Т—STATS.
Необходимость входного меню
Меню, предложенное на рис. 9.5, предназначено для извлечения данных из БД. Оно нс окажет никакой помощи секретарю в добавлении новых кортежей в БД. Типичная проблема, с которой придется столкнуться секретарю, заключается в добавлении в БД результатов всех игроков за пятую неделю. Как было указано ранее в этой главе, текущие данные в БД были внесены с помощью стандартных команд dBASE III APPEND и EDIT. Этим командам присущи внутренние проблемы с точки зрения целостности БД; в
частности, этими командами не контролируется существование дублированных первичных ключей. В исходном проекте БД предусматривалось отсутствие дублированных первичных ключей. Выполнение этого условия требует разработки пользовательского программного обеспечения, предназначенного для обнаружения среди заносимых в БД кортежей тех, которые могут послужить причиной дублирования первичных ключей. Программное обеспечение призвано нс допустить занесения в БД таких кортежей.
********************************************************
*Имя процедуры: "fileout.prg"
*Автор Глен А.Джексон
*Оклендский университет, Рочестер, MI 48063
*
*Данная процедура выводит имена-и-фамилии из не*скольких *временных отношений, создаваемых модулем eosrpt.prg.
*
Процедура вызывается из eosrpt.prg *
*Название отношения, содержимое которого требуется вывести, Содержится в переменной fname. Это отношение содержит только Сдин атрибут: bname.
USE &fname
GOTO TOP
DO WHILE .NOT. EOF()
eR0W()+l,30 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. Данный мо-
дуль запросит кортежные значения, ввод которых желает осуществить секретарь, и затем ПОДСЧИТАЕТ (COUNT) число кортежей в отношении, имеющих тот же, что и вводимый кортеж, первичный ключ. Если значение COUNT остается равным 0, то кортеж автоматически будет включен в БД. В противном случае кортеж в БД включаться не будет. Такой логический подход должен быть применен для всех отношений в БД. Набор программ, направленный на достижение этой цели, дан в конце главы в качестве задачи.
USE bowler
Ввод значений атрибутов bname,week, gamel, game2 и датеЗ с помощью переменных name, wk, gl, д2 и дЗ соответственно.
ПОДСЧЕТ (COUNT) числа кортежей, для которых справедливо bname = name и week = wk.
IF COUNT = 0, то APPEND (добавление) нового кортежа в отношение
ELSE
вывод сообщения об ошибке и запрос на получение нового кортежа.
Рис. 9.27. Алгоритм предотвращения хранения дублированных первичных ключей в отношении BOWLER
Задачи к гл. 9
Составить правильно следующие запросы, используя реализацию средствами dBASE III БД секретаря, кратко описанную на рис. 9.1-9.4. (Используйте последовательность команд dBASE III либо небольшой по размеру программный модуль, содержащий команды dBASE III. Следует отметить, что некоторые задачи являются трудными.)'
Получить список имен-и-фамилий и адресов всех членов команды HiRollers;
определить общее число очков (без учета гандикапа) для команды с номером 4 на конец недели 2 сезона;
определить общее число очков (без учета гандикапа) для команды SandBaggers на конец недели 3;
определить сколько игроков команды Splitters проживает на улице Robin St;
получить имена-и-фамилии капитанов всех команд, которые хотя бы в одной игре набрали более 160 очков;
с) получить имена-и-фамилии всех игроков, чьи фамилии начинаются с буквы “М“;
ж) получить имена-и-фамилии всех игроков, показавших в более чем одной серии из трех встреч результат, превышающий 450 очков (избегайте дублирования выводимой информации).
Реализация запросов в dBASE III, рассмотренная в этой главе, осуществляет вывод всех данных на терминальное устройство. Модифицируйте sdbmain.prg так, чтобы секретарю задавался вопрос о том, нужна ли ему также и твердая копия этих данных (вывод на принтер).
Модуль получения отчета о результатах сезона (eosrpt.prg) определяет последнюю неделю этого сезона посредством нахождения в отношении SCHED наибольшего номера недели. Программа никогда нс проверяет отношение BOWLER на предмет того, были ли действительно введены данные, касающиеся этой недели, в БД. Модифицируйте модуль eosrpt.prg так, чтобы эта проверка выполнялась перед проведением вычислений по формированию сезонного отчета.
Внесите в модуль eosrpt.prg изменения, обеспечивающие вывод имени-и-фамилии игрока, достигшего наибольшего прогресса. Таковым считается игрок, у которого разница между начальной результативностью и конечной является наибольшей.
В реализации не предусмотрена возможность учета пропусков игроком игры или игр во время тура. Измените реализацию так, чтобы пропуск игры (результатом которого является начисление 0 очков за игру) : (а) не влиял на показатель результативности или гандикап; (б) имел своим следствием замещение нуля значением результативности игрока за вычетом 10 очков, что вызывается необходимостью определения числа побед-поражений команды.
Внесите в модуль bwlrst.prg изменения, обеспечивающие вывод также ОБЩЕГО ЧИСЛА ОЧКОВ С УЧЕТОМ ГАНДИКАПА.
******************** HNDKP AVG prg **************
♦Имя модуля ”hndkp_avg.prg"
♦Составлен Барбарой А. МакНил
♦Модифицирован Гленом А.Джексоном
*Оклендский университет, Рочестер, MI 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 + game? + game3 + t_pins ctr = ctr + 1
ENDDO
*
bavg = INT(t_pins/(ha_week*3))
IF bavg < 200
hndkp = INT((200-bavg)*0.75)
ELSE
hndkp * 0
ENDIF
восстановление исходного номера записи файла scores.dbf.
GOTO saveit
*
RETURN
Рис. 9.28. Модуль hndkp-avg.prg, вызываемый из teamstd.prg.
Расчет положения команд с помощью модуля teamstd.prg требует тем больших затрат времени, чем больше времени прошло с начала сезона. Одна из причин этого заключается в том, что модуль
hndkp-^avg.prg при вызове его из teamstd.prg с целью вычисления текущего гандикапа выполняет вычисления по определению общего числа набранных очков, которые повторно выполняются при возврате управления в teamstd.prg. Модифицируйте алгоритм и добейтесь исключения дублируемых действий. Программный модуль hndkp-^avg.prg приведен на рис. 9.28.
В задаче 1 гл. 5 предлагалось спроектировать БД, в которой бы хранились некоторые из вычисляемых атрибутов (таких, как общее число набранных очков). Реализуйте указанную БД и сравните времена, затрачиваемые на вычисление положения команд в новой БД и предлагаемом в этой главе варианте. Обсудите некоторые проблемы обновления данных во вновь сконструированной БД, сравните их с реализацией БД, представленной в настоящей главе.
Напишите несколько программных модулей, выполнение которых инициируется с помощью меню, которые бы позволили секретарю присоединять новые, или модифицировать текущие кортежи для любого отношения в БД. Каждым модулем должны выявляться дублированные первичные ключи, а также все остальные ошибки, возникновения которых можно ожидать. (Обратите внимание, что при модификации атрибута, являющегося первичным ключом, следует вначале удалять “старый4* кортеж с последующей вставкой “нового44 кортежа.)
Еще раз просмотрите все программные модули, вызываемые из программы главного меню, на предмет того, нельзя ли достигнуть большей скорости их выполнения путем изменения в подходах, с помощью улучшенного программирования или усовершенствования технологических аспектов построения БД. Сравните текущие временные затраты на выполнение и те же затраты при пересмотренном методе с целью получения количественной оценки достигнутого (в скорости ответа) улучшения. Определите, оказывает ли использование индексированных файлов заметное влияние на время выполнения1).
9 Тестовые прогоны с использованием системы на жестком диске тех же програмнщх модулей, что приводятся в данной главе, показали ПО крайней мере трехкратное увеличение скорости выполнения.
R:base 5000-РЕАЛИЗАЦИЯ БД СЕКРЕТАРЯ КЕГЕЛЬНОЙ ЛИГИ
Эта глава подразделяется на три основные информационные части: 1 - содержит примеры листингов четырех отношений, формирующих БД секретаря кегельной лиги, для случая их реализации в СУБД R.base 5000; 2 - содержит примеры того, как команды R:base 5000 могут быть использованы при получении ответов на простые запросы; 3 - посвящена углубленному обсуждению набора управляемых с помощью меню программных модулей R:base 5000, отвечающих на сложные запросы с помощью команд языка программирования данной СУБД. Реализация БД была выполнена на IBM PC с объемом оперативной памяти 320 Кбайт, двумя двусторонними дисководами, а также монохромным монитором. Системный диск R:base 5000 всегда установлен на устройстве А; программным модулям и файлам БД отводится устройство В.
Анализ отношений БД с помощью тестовых данных при использовании R:base 5000
Прежде чем приступать к обсуждению специальных запросов и различных программных модулей необходимо изучить существующие отношения БД. Тестовые данные для БД были получены при тех же, что и в гл. 9, предположениях. Эти предположения состоят в следующем:
В кегельную лигу входят 6 команд.
В каждой команде 4 игрока.
Продолжительность сезона составляет четыре недели.
Ввод данных, охватывающих эти 4 недели, был осуществлен с помощью стандартных команд R:base 5000 LOAD и EDIT.
Все игроки участвовали во всех встречах.
Возможные изменения в некоторых из этих предположений приводятся в качестве упражнений в конце главы в перечне задач.
R>list sched
Table: sched Read Password: NO Modify Password: NO
Column definitions
Name Type LengthKey
tnumbINTEGER1value(s)yes
weekINTEGER1value(s)
laneINTEGER1value(s)
Current number of rows:24
R>
a
tnumbweeklane
1 2
3 4
5 6
1 2
3 4
5 6
1 2
3 4
5 6
1 2 tnumb
1 11 11 12 22 22 23 33 33 34 4 week1 11 11 12 22 22 23 33 33 34 4 week1 24 36 545 26 13 36 14 525 1 lane1 24 36 545 26 13 36 14 525 1 lane343
1 1
1 1
1 1
2 2
2 2
2 2
3 3
3 3
3 3
4 4 week
1 1
1 1
1 1
2 2
2 2
2 2
3 3
3 3
3 3
4 4 week
1 2
4 3
6 5
4
5 2
6 1
3 3
6 1
4 5
2
5 1 lane
1 2
4 3
6 5
4
5 2
6 1
3 3
6 1
4 5
2
5 1 lane
42
.44
646
6
На каждом из рис. 10.1-10.4 показаны как структура, так и тестовые данные для каждого отношения. В эти отношения занесены тс же данные, которые использовались в гл. 9, что даст при желании возможность сравнения результатов обеих реализаций. БД в СУБД R:base 5000 присвоено название SDB.
R>list team
Table: team Read Password: NO Modify Password: NO
Column definitions
NameType
1 tnumbINTEGER
tnameTEXT
captnTEXT
LengthKey
1 value(s)yes
15 characters
15 characters
Current R>
number of rows
a
6
tnumb
tname
captn
1 2 3
4 5
6
AlleyCats Ineons1 stents TenPins HighRollers Splitters SandBaggers
Энн Джонс Билл Блак Лиза Мур Джил Миллер Рой Лейн Синди Фокс
6
Рис. 10.2. Структура (а) и содержимое (б) отношения TEAM
Обзор данных в отношении BOWLER вновь (как и в гл. 9) показывает дублирование адресных данных и данных о телефонных номерах. Казалось бы, можно заключить, что зависимость phone -> stret является корректной ФЗ. Читателю настоятельно рекомендуется ознакомиться с перечисленными в разд. 9.1 причинами, объясняющими почему это нс так и почему ни адресные данные, ни данные о телефонных номерах нс являются избыточными.
R>list bowler
Table: bowler Read Password: NO Modify Password: NO
Column definitions
# Name
Туре
Length
Key
1 bname
TEXT
15 characters yes
2 tnumb
INTEGER
1 value(s)
3 phone
TEXT
8 characters
4 stret
TEXT
20 characters
5 stavg
INTEGER
1 value(s)
Текущее
число строк: 24
R>
a
bname
tnumb
phone
stret
stavg
Дхин Адамс
5
689-1234
10 Robin St
111
Стив Адамс
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
Лиза Мур
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
Руфь Тейлор
6
689’0123
20 Cardinal St
119
Дан Уайт
4
689’2143
16 Robin St
158
Джейн Уайт
4
689’2143
16 Robin St
121
Раосел Тейлор
6
689’0123
6
20 Cardinal St
161
R>list scores
Table: scores Read Password: NO Modify Password: NO
Column definitions
# Name Type LengthKey
bnameTEXT15characters yes
weekINTEGER1value(s)
gamelINTEGER1value(s)
game2INTEGER1value(s)
game3INTEGER1value(s)
Текущее число строк: 96
R>
a
bname
week
gamel
game2
game3
Джин Адамс
1
119
120
94
Стив Адамс
1
112
140
138
Билл Блак
1
137
155
155
Бонни Блак
1
120
125
115
Бо Блоу
1
160
145
125
Джо Блоу
1
101
91
93
Джим Смит
1
160
150
146
Мари Смит
1
120
110
115
Энн Джонс
1
98
no
107
Джон Джонс
1
145
150
134
Джо Браун
1
140
127
129
Сью Браун
1
121
128
124
Синди Фокс
1
119
no
83
Рэнди Фокс
1
143
150
148
Рассел Тейлор
1
167
150
166
Руфь Тейлор
1
110
125
122
Джой Лейн
1
126
127
122
Рой Лейн
1
145
180
176
Джил Миллер
1
111
101
112
Пол Миллер
1
180
196
134
bname
week
gamel
game2
game3
Дан Уайт
1
156
163
154
Джейн Уайт
1
130
125
108
Лиза Мур
1
99
120
111
Майк Мур
1
150
149
121
6
Рис. 10.4. Структура (а) и содержимое (б) SCORES» (Приведены результаты только для первой недели. Результаты для всех четырех недель приводятся на рис. 9.4.)
Ответы на запросы секретаря в R:base 5000
Цель данного раздела состоит в иллюстрации того факта, что на простые запросы к БД секретаря кегельной лиги можно получить ответы непосредственно с помощью команд R:base 5000, нс прибегая к использованию языка программирования БД. Все запросы данного раздела имеют своими объектами отношения, приведенные на рис. 10.1 - 10.4. Читателю рекомендуется создать БД, загрузить отношения тестовыми данными и проверить обсуждаемые запросы. Во многих случаях ответ даже на сравнительно простой запрос требует не одной команды, а последовательности, состоящей из двух или трех команд.
В приводимых ниже примерах полагается, что пользователь находится на командном уровне СУБД R:base 5000 и на экране отображается символ приглашения R>. Также предполагается, что БД секретаря лий! открыта с помощью команды
R> OPEN b:sdb
ЗАПРОС #1: “Перечислить названия всех команд лиги“.
Ответить на этот запрос легко по двум причинам: во-первых, вся информация, необходимая для ответа на этот запрос, находится в одном отношении; во- вторых, не требуется никаких уточнений (предложение WHERE). Решением служит команда
R> SELECT tname FROM team
или
R> SELECT tname + R> FROM team
Во втором случае единичная команда для удобства чтения размещена на двух строках с помощью символа продолжения “+“. В результате исполнения любого из двух различных вариантов команды будет получен список, состоящий из названий шести команд.
ЗАПРОС #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
В ответ будет получено
phonephone689-4567689-4567 689-8901 689-8901689-4567689-4567 689-8901 689-8901bname
phone
phone
689-4567
689-4567 689-8901 689-8901
689-4567
689-4567 689-8901 689-8901
Джо Браун Сью Браун Лиза Мур Майк Мур
ЗАПРОС #5: “На какой площадке проводит свои встречи команда 5 на неделе 3 сезона?“.
Для получения ответа на этот запрос необходимо воспользоваться предложением WHERE, которое должно сопровождаться несколькими условиями вместо одного:
R> SELECT lane +
R> FROM sched +-
R> WHERE tnumb = 5 AND week - 3
Ответом системы на этот запрос будет lane = 5.
ЗАПРОС #6: “Найти имена-и-фамилии всех игроков, проживающих по улице Robin St.“
Поскольку адреса в БД запоминаются в виде строк типа “21 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
Во всех трех случаях в качестве ответа будет получен один и тот же результат
bnamq
Джин Адамс Стив Адамс Джил Миллер Пол Миллер Дан Уайт Джейн Уайт
Различия между тремя решениями определяются способом задания строки “Robin St“. В первых двух случаях пользователь должен проследить за тем, чтобы строки “Robin“ и “St“ разделялись в точности одним пробелом, поскольку именно таким образом хранятся данные об адресах в БД. В последнем случае оператор “&“ однозначно определяет для системы наличие одного пробела между разделяемыми им строками. Одно преимущество последнего формата заключается в том, что при просмотре решения число пробелов нс может вызвать сомнений.
ЗАПРОС #7: “Сколько проведено к настоящему времени трехматчевых серий, в которых набрано в сумме более 550 очков?“.
Получение ответа на этот запрос несколько усложняется тем обстоятельством, что R:base 5000 допускает использование в выражении только одной арифметической операции. Например, выражения вида
varl + var2
можно включать в конструкции, допускаемые R:base 5000, в то время как выражения, в которых использованы два оператора, например вида
varl + var2 + var3
никоим образом не могут быть включены в одну команду. Что касается данного запроса, то следствием указанного ограничения является необходимость временного резервирования ячеек памяти для хранения промежуточных результатов. Один возможный способ такого резервирования заключается в добавлении
столбца к отношению, данные в котором анализируются. После получения ответа столбец из отношения удаляется. Общее решение состоит из серии шагов:
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 в результате добавления, а затем удаления нового столбца. Многие из тех, кто непосредственно работает с БД, являются противниками подхода, при котором допускаются запросы, изменяющие структуру отношений в БД после того, как создание БД было завершено. Они будут доказывать, что вместо создания нового столбца в одном из проектных отношений целесообразней строить временное отношение, состоящее из одного или более столбцов и предназначенное для хранения промежуточных данных при проведении
вычислений. В этом случае, если произойдет нечто незапланированное при выполнении запроса, исходная БД будет сохранена. Этот подход заслуживает внимания и читателю рекомендуется придумать метод разрешения последнего запроса способом, при котором исходная структура отношения SCORES не изменяется.
ЗАПРОС #8: “Кто является капитаном соперника команды 5 на неделе 3?“.
На этот запрос лучше ответить в два этапа. На первом этапе можно воспользоваться запросом #5, в результате выполнения которого будет получено, что команде 5 на неделе 3 отведена площадка lane * 5. Это значит, что команда соперников будет этим вечером выступать на площадке lane = 6. С помощью полученной информации можно найти и сохранить в переменной, скажем, tern, номер команды, выступающей на площадке б на третьей неделе сезона:
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 = Лет R> SHOW VAR ans
В качестве ответа будет получено ans = Билл Блак.
ЗАПРОС #9: “Перечислить имена-и-фамилии всех членов лиги, не являющихся игроками команды SandBaggers“.
Решение в этом случае, как и в предыдущем, требует перенесения информации, извлеченной из одного отношения, в другое с целью получения правильного ответа. В этом примере будет использован оператор реляционной алгебры JOIN:
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 имен-и-фамилий.
Предложенное решение выполняется следующим образом: (1) Новое отношение, названное TEMPR, проецируется из отношения TEAM. Отношение TEMPR имеет только один столбец tnumb. В нем содержатся номера всех команд за исключением SandBaggers. (2) Единственный столбец в TEMPR переименовывается в ttnumb, с тем чтобы отличить его от столбца с номерами команд в отношении BOWLER. Во время выполнения следующей команды JOIN R:base 5000 ожидает, что соединяемые (командой JOIN) столбцы имеют разные названия. (3) Отношения TEMPR и BOWLER соединяются (командой JOIN) и формируют третье отношение RESULT. В столбце bname отношения RESULT содержатся искомые имена-и-фамилии членов лиги. (4) С помощью команды SELECT осуществляется отображение ответа на запрос. (5) Два временных отношения 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 * “Билл Блак“
R> SET VAR tot TO .tot + .s2 R> SET VAR tot TO .tot + .s3 R> SHOW VAR tot
В результате будет получено tot = 1381.
В данном решении по первой команде COMPUTE суммируются показанные Биллом Блаком результаты во всех встречах gamel, состоявшихся в первые три недели сезона, а полученная сумма заносится в переменную tot. Следующие две команды COMPUTE повторяют эту процедуру суммирования, но уже для встреч game! и 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 = И.
В этом решении временное отношение TEMPR проецируется (с помощью команды PROJECT) из отношения SCORES. В отношении TEMPR имеется только один столбец bname. В этом отношении содержится по одному кортежу для каждого кортежа отношения SCORES, в котором результат хотя бы одной встречи превышает 150. Так как один и тот же игрок мог набрать более 150 очков в разные дни, возможно, что одни и те же имя-и-фамилия появятся в отношении TEMPR несколько раз. По команде DELETE DUPLICATES все дублированные имена-и- фамилии (кортежи) будут удалены из отношения
TEMPR. Число оставшихся имен-и-фамилий подсчитывается с помощью команды COMPUTE с целью получения искомого ответа.
Допустимость дублированных кортежей в отношении TEMP означает, что оператор PROJECT в СУБД R:base 5000 не является корректным оператором реляционной алгебры, a TEMPR не является изначально правильным отношением. Как уже отмечалось в предыдущих главах, никакая реляционная СУБД для микрокомпьютеров не является полностью реляционной, и пользователь должен принять этот факт во внимание при подготовке запросов. R:base 5000 в большей степени, чем другие СУБД для микрокомпьютеров, соответствует понятию полностью реляционной СУБД.
Относительно приведенных выше решений следует сказать, что они не являются единственно возможными. Обычно запрос может быть удовлетворен различными способами. Одни решения могут отличаться высокой скоростью исполнения, логика других может быть много проще для понимания. Лучший способ научиться составлять хорошие решения состоит в изучении решений, написанных другими, с последующим написанием многих собственных решений, используя несколько различных подходов к каждой проблеме.
Основное меню заранее подготовленных запросов
Запросы из разд. 10.2 относятся к типичным запросам секретаря лиги. Их решения в большинстве случаев достаточно прямолинейны и невелики по размеру, под которым понимается число предложений R:base 5000, необходимых для получения ответа. Предполагалось, что секретарь будет вводить эти решения вручную, хотя длина некоторых решений легко может привести к возникновению ошибки при их написании. Кроме того, секретарь лиги должен обладать определенными знаниями как в области теории БД, так и в синтаксисе R:base 5000, достаточными для составления решений, а не простого копирования их из предложенного перечня. Для того чтобы снять с секретаря обязанность регенерации решений всякий раз при встрече с одним и тем же запросом, можно прибегнуть к сохранению меню часто используемых
запросов, с исполнением заранее запрограммированного решения каждого запроса из меню при его выборе. В следующих разделах этой главы подробно описывается такое специальное меню и связанные с ним программы.
г МЕНЮ ЗАПРОСОВ ПО СОСТОЯНИЮ В НОЧЬ НА ПОНЕДЕЛЬНИК п (1) СТАТИСТИЧЕСКИЕ ДАННЫЕ ПО ОТДЕЛЬНОМУ ИГРОКУ (2) ОБЩЕЕ ЧИСЛО ОЧКОВ КАЖДОЙ КОМАНДЫ -
ВЫВОД ПОЛОЖЕНИЯ КОМАНД
ВЫВОД РАСПИСАНИЯ ВСТРЕЧ ДЛЯ ДАННОЙ НЕДЕЛИ
ГЕНЕРАЦИЯ ОТЧЕТА О РЕЗУЛЬТАТАХ СЕЗОНА
ВОЗВРАТ В 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. Некоторые из этих модулей, в свою очередь, могут вызывать другие подмодули. Все программные модули, вызываемые в ответ на сделанный выбор, подробно обсуждаются в следующих разделах этой главы. Реализации программ, использованные для получения результатов, приведенных в этой главе, представляют собой откомпилированные версии исходных программ, листинги которых будут представлены.
(COMMAND
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 EQ1 THEN
RUN bwlrst.com
GO TO STARTAPP
ENDIF
IF PICK1 EQ2 THEN
RUN teampns IN SECDB.APX
GO TO STARTAPP
ENDIF
IF PICK1 EQ3 THEN
RUN teamstd.com
GO TO STARTAPP
ENDIF
IF PICK1 EQ4 THEN
RUN wkschdl IN SECDB.APX
GO TO STARTAPP
ENDIF
IF PICK1 EQ5 THEN
RUN eosrpt.com
GO TO STARTAPP
ENDIF
IF PICK1 EQ6 THEN
GOTO ENDAPP
ENDIF
GOTO STARTAPP
LABEL ENDAPP
CLEAR PICK1
RETURN
(MENU sdbmain
МЕНЮ ЗАПРОСОВ ПО СОСТОЯНИЮ В НОЧЬ НА ПОНЕДЕЛЬНИК СТАТИСТИЧЕСКИЕ ДАННЫЕ ПО ОТДЕЛЬНОМУ ИГРОКУ ОБЩЕЕ ЧИСЛО ОЧКОВ КАЖДОЙ КОМАНДЫ
ВЫВОД ПОЛОЖЕНИЯ КОМАНД
ВЫВОД РАСПИСАНИЯ ВСТРЕЧ ДЛЯ ДАННОЙ НЕДЕЛИ ГЕНЕРАЦИЯ ОТЧЕТА О РЕЗУЛЬТАТАХ СЕЗОНА
ВОЗВРАТ В RBASE 5000
Рис. 10.6. Программный модуль основного меню secdb.app.
Модуль BWLRST.PRG в R:base 5000
Этот модуль вызывается из программы построения основного меню в том случае, когда выбирается возможность “СТАТИСТИЧЕСКИЕ ДАННЫЕ ПО ОТДЕЛЬНОМУ ИГРОКУ “. Модуль предназначен для вычисления некоторых статистических данных, касающихся определенного игрока, и вывода этих данных. Статистические данные могут быть получены для любой недели сезона, включая последнюю, для которой результаты были занесены в БД. Логика модуля представлена на рис. 10.7, его исходный текст приведен на рис. 10.8, типичные выходные данные модуля - на рис. 10.9.
Определить номер последней недели, для которой в отношение SCORES были внесены результаты. Сохранить его в max_wk.
Ввести номер недели, по которой необходимо получение статистических данных, в переменную wk и проверить правильность ввода.
Ввести имя-и-фамилию игрока, о котором требуется статистическая информация, в переменную паше и проверить их правильность.
Применяя команду SET POINTER в R:base 5000 идентифицировать все кортежи в SCORES, которые будут использоваться при вычислениях. (Условием является bname=name AND week<=wk.)
Для каждого кортежа в группе, выбранной с помощью SET POINTER, выполнить следующие действия:
проверить каждый показанный в игре индивидуальный результат с целью нахождения среди игр наилучшей для данного игрока с сохранением показанного в этой игре результата в переменной hi_game;
проверить сумму набранных очков в каждой трехматчевой серии с целью нахождения наилучшей серии с сохранением показанного в этой серии результата в переменной hi_series;
получить сумму всех индивидуальных результатов, показанных в отдельных играх, и сохранить общее число очков, набранных без учета гандикапа, в переменной totjpins.
Вычислить для данного игрока текущие результативность и гандикап и поместить их в переменных bavg и hndkp соответственно.
Вывести результаты.
*(Имя процедуры: bwlrst.prg
(Автор Глен А. Джексон
(Оклендский университет, Рочестер, MI 48063)
*(
(Эта процедура предназначена для вычисления и вывода )
( статистических данных, характеризующих отдельного игрока:
( Лучшая игра, Лучшая серия, Общее число набранных очков )
( и Гандикап. Во всех статистических данных учитываются все
(проведенные к настоящему моменту игры. )
()
( Эта процедура вызывается из sdbmain.)
( Эта процедура не вызывает другие модули.)
NEWPAGE.
SET VAR hi_game INTEGER
SET VAR hi_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
*0
*( Ввод через wk номера недели, на конец которой )
*(требуется статистика.)
SET VAR done ТО "false"
WHILE done EXISTS THEN
WRITE "ЕСЛИ ТРЕБУЮТСЯ ПОСЛЕДНИЕ СТАТ. ДАННЫЕ” АТ 7 15
WRITE "ВВЕДИТЕ" АТ 8 15
SHOW VAR max_wk=l AT 8 21
WRITE "НОМЕР ПОСЛ. НЕДЕЛИ, ПО КОТ. ВВОДИЛИСЬ ДАННЫЕ" АТ 8 23
FILLIN wk USING "ИНАЧЕ - НОМЕР ТРЕБУЕМОЙ НЕДЕЛИ: " АТ 9 15
IF wk GE 1 AND wk LE .max_wk THEN BREAK
ENDIF
WRITE "НЕПРАВИЛЬНЫЙ ВВОД НОМЕРА НЕДЕЛИ" AT 15 15
WRITE "Нажмите любую клавишу для продолжения.." АТ 17 15 PAUSE
NEWPAGE
*(Ввод имени-и-фамилии игрока и проверка правильности ввода. ) *0 NEWPAGE
WHILE done EXISTS THEN
FILLIN name USING -ВВЕДИТЕ ИМЯ И ФАМИЛИЮ:” AT 10 15
COMPUTE check AS COUNT bname FROM bowler WHERE bname=.name IF check GT 0 THEN BREAK ENDIF
WRITE ”УКАЗАННЫЕ ИМЯ И ФАМИЛИЯ В БД ОТСУТСТВУЮТ” АТ 12 15
WRITE "Нажмите любую клавишу и повторите ввод ” АТ 14 15 PAUSE NEWPAGE ENDWHILE NEWPAGE *0
*( Вычисление статистических данных, характеризующих этого)
*( игрока )
*0
SET VAR h1_name ТО О
SET VAR hi.ser TO 0
SET VAR totpins TO 0
SET POINTER #1 errl FOR scores WHERE bname EQ .name AND week LE .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
SET 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 .hi.ser THEN
SET VAR hi_ser TO .tot3
ENDIF
SET VAR totpins TO .totpins + .tot3
NEXT #1 errl
ENDWHILE
( Вычисление гандикапа для данного игрока. )
0
SET VAR totgam ТО .wk х 3
SET VAR bavg TO .totplns / .totgam
IF bavg LT 200 THEN
SETSET ELSESET ENDIFSETSET ELSESET ENDIFVAR hndkp TO 200 - .bavg
SET
SET ELSE
SET ENDIF
SET
SET ELSE
SET ENDIF
VAR hndkp TO .hndkp x 0.75
VAR hndkp TO 0
( Вывод результатов. )
*0
WRITE "СТАТИСТИКА АЛЯ " AT 7 20
SHOW VAR name=15 AT 7 36
WRITE " НА КОНЕЦ НЕДЕЛИ " AT 7 51
SHOW VAR wk=l AT 7 61
WRITE "H Ht-HH hi инн ьн *+-i Н1Н1Н1ншжи4" AT 8 20
WRITE "СРЕДНЕЕ ЧИСЛО ОЧКОВ ЗА ИГРУ:" АТ 10 20
SHOW VAR bavg=3 AT 10 43
WRITE "ОБЩЕЕ ЧИСЛО ОЧКОВ - БЕЗ ГАНДИКАПА:" АТ 12 20
SHOW VAR totp1ns-4 AT 12 50
WRITE "ЛУЧШИЙ РЕЗУЛЬТАТ ЗА ИГРУ НА СЕГОДНЯ:" АТ 14 20
SHOW VAR h1_game=3 AT 14 45
WRITE "ЛУЧШАЯ СЕРИЯ НА СЕГОДНЯ:" АТ 16 20
SHOW VAR h1_ser=3 AT 16 41
WRITE "ТЕКУЩИЙ ГАНДИКАП:" AT 18 20
SHOW VAR hndkp=2 AT 18 38
WRITE "Нажмите любую клавишу для продолжения" АТ 23 20; PAUSE CLEAR ALL VAR RETURN
Рис. 10.8. (Окончание)
СТАТИСТИКА ДЛЯ Билл Блак НА КОНЕЦ НЕДЕЛИ 3
СРЕДНЕЕ ЧИСЛО ОЧКОВ ЗА ИГРУ: 153„
ОБЩЕЕ ЧИСЛО ОЧКОВ - БЕЗ ГАНДИКАПА: 1381
ЛУЧШИЙ РЕЗУЛЬТАТ ЗА ИГРУ НА СЕГОДНЯ: 165
ЛУЧШАЯ СЕРИЯ НА СЕГОДНЯ: 483
ТЕКУЩИЙ ГАНДИКАП: 35
Рис. 10.9. Типичные выходные данные модуля bwirst.prg
Единственной частью модуля bwlrst.prg, которая нуждается в пояснении, является блок вычисления гандикапа, состоящий из двух предложений
SET VAR hndkp ТО 200 - .bavg SET VAR hndkp TO .hndkp x 0.75
Здесь hndkp - целая переменная, объявленная как INTEGER и предназначенная для хранения текущего значения гандикапа данного игрока. Еще одна целая переменная bavg содержит значение текущей результативности игрока. Эти два предложения решают уравнение
handicap * TRUNC((200 - current-average)*0.75), где TRUNC - функция усечения. Хотя hndkp является целочисленной переменной, ее умножение на 0.75 дает в результате вещественное значение. Это вещественное значение затем присваивается целочисленной переменной hndkp. R:base 5000 автоматически выполняет не округление, а усечение вещественного числа, присваиваемого целой переменной. Если бы вещественные величины не усекались, а округлялись при получении гандикапа, то это привело бы к заметному изменению статистических данных, касающихся как отдельных игроков, так и команд в целом.
10.5. Программный модуль TEAMPNS.PRG в R:base 5000
Этот модуль вызывается в случае выбора в главном меню возможности “ОБЩЕЕ ЧИСЛО ОЧКОВ КАЖДОЙ КОМАНДЫ44. Вычисленное общее число очков является “чистым44, т.е. без учета гандикапа. Модификация этого модуля таким образом, чтобы при подсчете общего числа очков учитывался гандикап, приводится в качестве упражнения в конце главы. Данный модуль разрабатывался в предположении, что подсчет очков должен производиться с учетом последней недели, для которой в БД были введены результаты встреч. Пример результатов выполнения этого программного модуля приведен на рис. 10.10, его логика представлена на рис. 10.11 и, наконец, исходный текст - на рис. 10.12.
ОБЩЕЕ ЧИСЛО ЧИСТЫХ ОЧКОВ НА КОНЕЦ НЕДЕЛИ 4
КОМАНДА НАЗВАНИЕ КОМАНДЫ ОБЩЕЕ ЧИСЛО ОЧКОВ
1
AlleyCats
6257
2
Inconsistents
6172
3
TenPins
6147
4
HighRollers
6798
5
Splitters
6580
6
SandBaggers
6534
Рис. 10.10. Типичный результат выполнения модуля teampns.prg
Определить номер последней недели, по которой были внесены результаты в отношение SCORES. Сохранить соответствующее значение в переменной max_wk.
Вывести заголовок таблицы данных, которые будут выведены позже.
Использовать внешний цикл WHILE - THEN (с переменной ctr в качестве счетчика) с целью перебора всех 6 команд лиги. По отношению к каждой команде воспользоваться директивой SET POINTER #1 с целью определения всех игроков этой команды:
с помощью внутреннего цикла WHILE-THEN определить общее число очков, набранных одной командой; сохранить полученное значение в переменной tot_pins;
просмотреть отношение TEAM с целью нахождения названия команды по ее номеру; сохранить это название в переменной name_t;
вывести данные, характеризующие эту команду, с одновременной настройкой счетчика строк.
Рис. 10.11. Алгоритм программного модуля teampns.prg
При сравнении логики модуля teampns.prg в случае R:base 5000 и логики того же самого модуля в случае dBase III (разд. 9.4) обращает на себя внимание использование во втором случае оператора JOIN с целью сбора всех результатов всех игроков одной команды в общем информационном блоке (временное отношение TEMPR2). Хотя оператор JOIN мог быть
использован тем же образом и в случае R:base 5000, было решено, что с программной точки зрения проще воспользоваться оператором SET POINTER для идентификации всех членов одной команды и затем просуммировать результаты всех встреч для данной команды с помощью цикла WHILE-LOOP. Вопрос о том, в каком случае обеспечивается более высокая скорость выполнения - при использовании SET POINTER или JOIN, - не рассматривался.
*(Имя процедуры: teampns.prg)
(Автор Глен А. Джексон)
(Оклендский университет, Рочестер, MI 48063)
()
(Эта процедура выводит общее число "чистых")
(очков, набранных каждой командой на данный)
(момент.)
()
(Эта процедура вызывается из sdbmain.)
(Эта процедура вызывает:)
()
(Процедура не имеет ни входных, ни выходных параметров. ) NEWPAGE
SET VAR max_wk INTEGER
COMPUTE max wk AS MAX week FROM scores
(Вывод заголовка для выходных данных.)
WRITE "ОБЩЕЕ ЧИСЛО ЧИСТЫХ ОЧКОВ НА КОНЕЦ НЕДЕЛИ" АТ 5 20
SHOW VAR max_wk«l AT 5 53
WRITE "4н инн и* u44 и w♦ 44+44444 ♦ 4441 4 444 it h i i 4" AT 6 20
WRITE "КОМАНДА НАЗВАНИЕ КОМАНДЫ ОБЩЕЕ ЧИСЛО ОЧКОВ" АТ 7 20
WRITE " "АТ820
*f)
*(Вычисление и вывод общего числа очков, набранных каждой )
*(командой. )
*()
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
*( Внешний цикл выбора команды.)
WHILE ctr LE 6 THEN
SET POINTER #1 errl FOR bowler WHERE tnumb EQ .ctr
*0
*( Внутренний цикл выбора игроков команды.)
*0
SET VAR totpins TO 0.
WHILE errl EQ 0 THEN
SET VAR name_b TO bname INfl
COMPUTE gsumlASSUMgamelFROMscoresWHEREbname».name_b
COMPUTE gsum2ASSUMgame2FROMscoresWHEREbname».name_b
COMPUTE gsum3ASSUMgame3FROMscoresWHEREbname».name_b
SET VARtotpinsTO.totpins+.gsuml
SET VARtotpinsTO.totpins+.gsum2
SET VARtotpinsTO.totpins+.gsum3
NEXT #1 errl
ENDWHILE
*0
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 "Нажмите любую клавишу для продолжения работы." АТ 20 20 PAUSE
CLEAR ALL VAR
RETURN
Рис. 10.12. (Окончание)
10.6. Программный модуль WKSCHDL.PRG в R:base 5000
Этот программный модуль вызывается из программы главного меню при выборе в последнем варианта “ВЫВОД РАСПИСАНИЯ ВСТРЕЧ ДЛЯ ДАННОЙ НЕДЕЛИ". Результатом выполнения модуля является вывод таблицы названий команд и площадок, которые назначены этим командам на данную неделю текущего сезона. Модуль запрашивает на входе номер недели, для которой требуется расписание, и перед проведением требуемых вычислений проверяет правильность введенного номера недели. Типичные результаты выполнения модуля приведены на рис. 10.13. Логика модуля отражена на рис. 10.14, исходный текст приводится на рис. 10.15.
РАСПИСАНИЕ НА НЕДЕЛЮ С НОМЕРОМ 3
4 НН И*** Н4-Н-К"Н+4+*Н-1*Н4Н-
КОМАНДАКОМАНДАНОМЕР ПЛОЩАДКИНОМЕР ПЛОЩАДКИ
КОМАНДА
КОМАНДА
НОМЕР ПЛОЩАДКИ
НОМЕР ПЛОЩАДКИ
3 6145 23 6145 2AlleyCats Ineonsistents TenPins HighRollers Splitters SandBaggers
3 6
1
4
5 2
3 6
1
4
5 2
Рис. 10.13. Типичный результат выполнения модуля wkschdl.prg
Определить номер последней недели сезона. Присвоить это значение переменной max wk.
Ввести номер недели сезона, для которой требуется получить календарь, в переменную in_val и проверить правильность введенного значения.
Вывести заголовок для таблицы данных, которые предполагается вывести.
С помощью применения команды SET POINTER к отношению SCHED идентифицировать все кортежи, в которых значение атрибута week совпадает со значением переменной in_val.
Использовать цикл WHILE - THEN для перебора всех команд, принадлежащих множеству команд, связанных между собой с помощью команды SET POINTER на шаге 4. Вывести названия команд (tname), найденных в отношении TEAM, и номера площадок (lane), полученных из отношения SCHED для каждой команды.
Рис. 10.14. Логика модуля wkschdl.prg.
Сердцевина логической схемы в модуле wkschdl.prg реализована с помощью команды SET POINTER и следующей за ней конструкции WHILE-THEN, что замещает возможную операцию JOIN. Применение в алгоритме операции JOIN предлагается в конце главы в качестве задачи.
(COMMAND wkschdl *(Имя процедуры: wkschdl)
(Автор Гленн А. Джексон)
*(Процедура выводит расписание встреч для данной недели. )
(Номер недели вводится с терминала ) *(3та процедура вызывается из sdbmain.)
(3та процедура вызывает модуль delay.)
NEVPAGE *(Нахождение последней недели и занесение ее в max_wk.) SET VAR max_wk INTEGER COMPUTE max_wk AS MAX week FROM sched *(Ввод номера требуемой недели и проверка значения. ) SET VAR done TEXT SET VAR done TO "false" SET VAR in_val INTEGER WHILE done EXISTS THEN
WRITE "ВВЕДИТЕ НОМЕР ТРЕБУЕМОЙ НЕДЕЛИ" AT 7 10
WRITE "ТОЛЬКО ЗНАЧЕНИЯ В ДИАПАЗОНЕ ОТ 1 ДО" АТ 8 10
SHOW VAR max_wk=l AT 8 36 FILLIN in_val USING "ЯВЛЯЮТСЯ ДОПУСТИМЫМИ" AT 8 38 IF in_val LE .max_wk AND in_val GE 1 THEN
BREAK ENDIF WRITE "ВВЕДЕННЫЙ НОМЕР НЕДЕЛИ НЕКОРРЕКТЕН" AT 15 10
WRITE "Нажмите любую клавишу для продолжения" АТ 16 10;PAUSE NEWPAGE1
ENDWHILE NEWPAGE WRITE " РАСПИСАНИЕ НА НЕДЕЛЮ С НОМЕРОМ" АТ 5 10
SHOW VAR in_val=l AT 5 46
WRITE "44 ♦ 4Ж444 ♦ 144 44-44 44 ♦ 4444-44-1 4 44 4" AT 6 10
WRITE " КОМАНДАНОМЕР ПЛОЩАДКИ" AT 7 10
WRITE " " AT 8 10
*(0пределение и вывод расписания.)
SET POINTER #1 errl FOR sched WHERE week EQ .in_val 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 "Нажмите любую клавишу для продолжения." АТ 20 17; PAUSE CLEAR ALL VAR
RETURN
Рис. 10.15. Программный модуль wkschdl.prg.
10.7. Программный модуль EOSRPT.PRG в R:base 5000
Этот модуль вызывается из программы главного меню в случае выбора альтернативы “ГЕНЕРАЦИЯ ОТЧЕТА О РЕЗУЛЬТАТАХ СЕЗОНА“. Результатом выполнения этого модуля является определение и вывод имен-и-фамилий тех игроков, которые в сезоне: 1 - показали наивысший индивидуальный результат в одной игре; 2 - показали наивысший результат в трехматчевой серии; 3 - закончили сезон с наивысшей результативностью (среднее число набираемых очков в одной игре).
Результаты выполнения этого модуля в случае, когда исходные данные были получены из приведенного примера БД, показаны на рис. 10.16. Логика модуля представлена на рис. 10.17, а его исходный текст - на рис. 10.18.
ОТЧЕТ 0 РЕЗУЛЬТАТАХ СЕЗОНА И ♦ ♦ *4 4 <1 I I I ♦*+++++++♦♦♦ 4 ♦ НАИЛУЧШИЙ РЕЗУЛЬТАТ ЗА ОДНУ ИГРУ - 202 ОЧКА - ПОКАЗАН СЛЕДУЮЩИМИ ИГРОКАМИ:
Рой Лейн Рассе* Тейлор По* Мидлер
ЛУЧШИЕ СЕРИИ ИЗ ТРЕХ МАТЧЕЙ - 559 ОЧКОВ - ПРОВЕЛИ СЛЕДУЮЩИЕ ИГРОКИ:
Рой Лейн Поа МиААер
ЛУЧШАЯ РЕЗУЛЬТАТИВНОСТЬ В СЕЗОНЕ - 179 ОЧКОВ - БЫЛА ПОКАЗАНА ИГРОКАМИ:
Поа Миллер
Рис. 10.16. Результат выполнения модуля eosrpt.prg
Определить последнюю неделю сезона по информации, содержащейся в отношении SCHED. Сохранить полученное значение в переменной max_wk.
Определить лучший индивидуальный результат сезона (наибольшее число очков, набранных за игру). Сохранить полученное значение в переменной best_gam.
Вывести информацию о лучшем результате, показанном в одной встрече:
получить с помощью оператора PROJECT унарное временное отношение TEMPR из отношения SCHED, содержащее имена-и-фа- милии (bnames) всех игроков, которые показали хотя бы в одной игре результат, равный лучшему;
вывести заголовок отчета о результатах сезона с последующим выводом имен-и-фамилий всех тех игроков, которые показали хотя бы в одной игре результат, равный лучшему;
с) удалить оператором REMOVE временное отношение TEMPR из БД.
Получить результат лучшей трехматчевой серии в переменной best_ser с помощью выполнения следующих действий:
добавить оператором EXPAND новый столбец с именем total к отношению SCORES;
заполнить поле total каждого кортежа суммой gamel+game2+game3 значений, полученных из этого кортежа;
найти значения переменной best_ser, применив команду COMPUTE - МАХ к полю total отношения SCORES;
выделить оператором PROJECT из отношения SCORES временное отношение TEMPR, содержащее имена-и-фамилии всех игроков, показавших лучший результат, хранимый в best_ser;
вывести информацию о лучших сериях.
Получить лучшую результативность, показанную в сезоне, в переменной best_avg с помощью выполнения следующих действий:
выделить оператором PROJECT из отношения BOWLER временное отношение ТЕМР2, содержащее имя-и-фамилию (Ьпаше) каждого игрока и его начальную результативность (stavg);
заменить название столбца stavg в отношении ТЕМР2 на avg;
вычислить результативность каждого игрока и занести полученное значение в поле avg отношения ТЕМР2;
вычислить с помощью команды COMPUTE - МАХ значение best_avg и вывести окончательные результаты;
вывести информацию о лучшей результативности.
Удалить столбец (REMOVE COLUMN) total из отношения SCORES.*
Удалить (REMOVE) отношение ТЕМР2 из БД.
*(Имя процедуры: eosrpt )
*(Автор Гленн А. Джексон )
*(0клендский университет, Рочестер, MI 48063)
0
(3та процедура готовит отчет о результатах сезона и )
(осуществляет его вывод)
0
(3та процедура вызывается из модуля sdbmain. )
(Эта процедура не вызывает другие модули. )
0
NEVPAGE
SET MESSAGE OFF
*0*(Нахождение последней недели сезона и занесение значения в)*0*(Нахождение последней недели сезона и занесение значения в)SET ERROR MESSAGE OFF
*0
*(Нахождение последней недели сезона и занесение значения в)
*0
*(Нахождение последней недели сезона и занесение значения в)
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_gam INTEGER SET VAR name TEXT
*(Нахождение лучшего результата сезона и сохранение его в)*( best_gam.)*0*(Нахождение лучшего результата сезона и сохранение его в)*( best_gam.)*0SET VAR hgl INTEGER SET VAR hg2 INTEGER SET VAR hg3 INTEGER SET VAR 1inect INTEGER
*(Нахождение лучшего результата сезона и сохранение его в)
*( best_gam.)
*0
*(Нахождение лучшего результата сезона и сохранение его в)
*( best_gam.)
*0
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.)
0
PROJECT tempr FROM scores USING bname +
WHERE gamel=.best_gam OR game2=.best_gam OR game3=.best_gam DELETE DUPLICATES FROM tempr
*0
(Вывод заголовка отчета и данных по лучшей игре. )
*()
WRITE "ОТЧЕТ О РЕЗУЛЬТАТАХ СЕЗОНА” АТ 1 26
WRITE "iiHiiHiiHiHiHHHHH" АТ 2 26
WRITE ”НАИЛУЧШИЙ РЕЗУЛЬТАТ ЗА ОДНУ ИГРУ - ”” АТ 4 20
SHOW VAR best_gam=3 AT 4 49
WRITE ”ОЧКОВ - ПОКАЗАН СЛЕДУЮЩИМИ ИГРОКАМИ:” АТ 5 20
SET VAR 11nest ТО 6
SET POINTER #1 errl FOR tempr
WHILE errl«0 THEN
SET VAR name TO bname IN #1
SHOW VAR name-15 AT .linect 30
SET VAR linect TO .linect + 1
NEXT #1 errl
ENDWHILE
(Нахождение результата лучшей серии с занесением его в)
( best_ser и вывод результатов. )
0
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 linect TO .linect + 2
WRITE “ЛУЧШИЕ СЕРИИ ИЗ ТРЕХ МАТЧЕЙ - ” AT .linect 20
SHOW VAR best_ser«3 AT .linect 55
SET VAR linect TO .linect + 1
WRITE “ОЧКОВ - ПРОВЕЛИ СЛЕДУЮЩИЕ ИГРОКИ:” AT .linect 20
SET VAR linect TO .linect + 1
SET POINTER #1 errl FOR tempr
WHILE errl»0 THEN
SET VAR name TO bname IN #1
SHOW VAR name=15 AT .linect 30
SET VAR linect TO .linect + 1
NEXT #1 errl
ENDWHILE
*(Нахохдение наивысшей результативности, показанной в сезоне,)
( с занесением ее в best_avg и вывод результатов. )
*0
SET VAR tgames INTEGER
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 linect TO .linect + 2
WRITE -ЛУЧШАЯ РЕЗУЛЬТАТИВНОСТЬ В СЕЗОНЕ” AT .linect 20
SHOW VAR best_avg=3 AT .linect 50
SET VAR linect TO .linect + 1
WRITE ”ОЧКОВ ЗА ИГРУ - БЫЛА ПОКАЗАНА ИГРОКАМИ:” AT.linect 20
SET VAR linect TO .linect + 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 .linect 30
SET VAR linect TO .linect + 1
NEXT #2 err2
ENDWHILE
REMOVE temp2
REMOVE COLUMN total FROM scores
SET MESSAGE ON
SET ERROR MESSAGE ON
WRITE "Нажмите любую клавишу для продолжения.” АТ 21 20; PAUSE RETURN
Рис. 10.18 (Окончание)
10.8. Программный модуль TEAMSTD.PRG в R:base 5000
Этот программный модуль вызывается из программы построения основного меню при выборе альтернативы “ВЫВОД ПОЛОЖЕНИЯ КОМАНД“. Результатом выполнения teamstd.prg является расчет и вывод таблицы положения всех команд лиги на конец данной недели сезона. Также выводится общее число “чистых“
очков, набранных каждой из команд на конец этой недели. В начале работы модуль запрашивает номер недели, на конец которой необходимо узнать положение команд. Убедившись в том, что номер введен правильно, программа приступает к необходимым для получения положения команд расчетам с последующим выводом результатов в табличной форме. На рис. 10.19 представлены типичные результаты выполнения программы. Логика модуля отражена на рис. 10.20, а его исходный текст - на рис. 10.21.
ПО СОСТОЯНИЮ В НОЧЬ НА ПОНЕДЕЛЬНИК ПОЛОЖЕНИЕ КОМАНД НА КОНЕЦ НЕДЕЛИ 1
tnumb wins lossestotpins
1 2
3 4
5 6
2.000002.000001545
2.000002.000001522
1.000003.000001519
3.000001.000001670
2.500001.500001599
1.500002.500001593
Рис. 10.19. teamstd.prg
Типичные выходные данные модуля
По сравнению с любым другим модулем данной реализации логика модуля tearnstd.prg является более сложной. В результате проектного решения, принятого в гл. 5, число побед, поражений и общее число очков, набранных каждой командой на конец каждой недели, в БД не сохраняются. Это было сделано для того, чтобы избежать возможной несогласованности данных в БД в тех случаях, когда кто-либо изменяет результат встречи без перерасчета эффекта этого изменения на число побед, поражений и общего числа очков. Один из результатов этого проектного решения заключается в том, что для вычисления положения команд для некоторой недели необходимо рассчитать турнирную таблицу для всех недель, предшествующих данной, начиная с первой. Это приводит не только к усложнению логики модуля teamstd.prg, но и резко
увеличивает время, необходимое для проведения расчетов и получения результатов. Временные затраты на получение положения команд увеличиваются линейно в зависимости от числа недель, для которых эти данные требуются. Именно, требуется приблизительно в три - раза больше времени на вычисление положения команд на конец третьей недели, чем на вычисление итогов первой недели.
Определить последнюю неделю, по которой были внесены результаты в отношение SCORES. Сохранить полученный номер в переменной max_wk.
Ввести в переменную in_wk номер недели, на конец которой требуется получить положение команд, и проверить правильность ввода.
Обнулить значения wins, losses, totpins во всех кортежах нового отношения TSTATS.
Для каждой площадки (обозначается как In) выполнить следующие действия применительно к каждой неделе (обозначается как wk):
используя комбинацию команд SET POINTER #2 и WHILE - THEN, провести вычисления по каждому игроку команды, выступавшей на данной площадке на данной неделе. Для каждого игрока: (1) вычислить текущий гандикап и занести в переменную "hndkp"; (2) каждый индивидуальный результат, показанный в игре, добавить к общему результату команды в данной игре (с учетом гандикапа); (3) значение totpins в отношении TSTATS для данной команды заместить текущим значением, увеличенным на число очков, набранных данным игроком в трехматчевой серии (без учета гандикапа); используются следующие обозначения: gla - общее число очков, набранных командой, выступающей на площадке с нечетным номером в игре 1 (gamel); gib - общее число очков, набранных командой, выступающей на площадке с четным номером в игре 1 (gamel). g2a, g3a, д2Ь, дЗЬ имеют аналогичный смысл;
настроить запись побед-поражений (в TSTATS), относящуюся к двум последним командам, подвергшимся анализу; здесь используется следующий способ кодировки: идентификатор команды, выступающей на площадке с нечетным номером, оканчивается символом "а”, а идентификатор команды, выступающей на площадке с четным номером, - символом "Ь".
Вывести положения команд путем выборки (оператором SELECT) всех данных, содержащихся в отношении TSTATS вслед за выводом нужного заголовка.
*(Имя процедуры: teamstd.prg )
*(Автор Гленн А. Джексон)
*(Оклендский университет, Рочестер, MI 48063 ) *(3та процедура рассчитывает и выводит таблицу положения) *( команд для любой недели. Номер требуемой недели вводится) *( с терминала.)
*(Процедура вызывается из sdbmain ) NEVPAGE
SET VAR max_wk INTEGER
SET VAR 1n_wk INTEGER SET VAR done TEXT *(0пределение последней недели, no которой были введены) *( результаты, и сохранение номера в переменной max_wk. ) COMPUTE max_wk AS MAX week FROM scores *(Ввод номера требуемой недели... и проверка ввода ) SET VAR done ТО "false" WHILE done EXISTS THEN
WRITE "ВВЕДИТЕ НОМЕР ТРЕБУЕМОЙ НЕДЕЛИ" AT 7 10
WRITE " ТОЛЬКО ЗНАЧЕНИЯ В ДИАПАЗОНЕ ОТ 1 ДО" АТ 8 10
SHOW var max_wk=l AT 8 36
FILLIN in_wk USING " ЯВЛЯЮТСЯ ДОПУСТИМЫМИ " AT 8 38
IF in_wk LE .max_wk AND in_wk GE 1 THEN BREAK
ENDIF
WRITE "НЕКОРРЕКТНЫЙ ВВОД НОМЕРА НЕДЕЛИ" AT 15 10
WRITE "Нажмите любую клавишу для продолжения" АТ 16 10; PAUSE NEWPAGE
ENDWHILE
*()
SET VAR errl INTEGER SET VAR err2 INTEGER SET VAR err3 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
*(До того как будет начат расчет нового положения команд, )
*( все значения атрибутов wins, losses и totpins обнуляются)
*(в отношении TSTATS.)
ASSIGN wins ТО 0.0 * 0.0 IN tstats
ASSIGN losses TO 0.0 + 0.0 IN tstats
ASSIGN totpins TO 0 + 0 IN tstats
*(Начало вычисления положения команд - вычисления выполняются)
*( с шагом, равным неделе, начиная с 1 и кончая max_wk.)
WHILE wk <= .1n_wk THEN
SET POINTER #1 errl FOR sched WHERE week - .wk AND lane -.In
SET VAR tnb TO tnumb IN #1
SET POINTER #2 err2 FOR bowler WHERE tnumb = .tnb
WHILE err2=0 THEN
SET VAR name TO bname IN #2
*0
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 VARglTOgamelIN#3
SET VARg2TOgame2IN#3
SET VARg3TOgame3IN#3
IF ln-1ORln=3’ OR ln=5 THEN
SET VAR gla TO .gla + .gl
SET VAR gla TO .gla + .hndkp
SET VAR g2a TO .g2a +.g2
SET VAR g2a TO .g2a + .hndkp
SET VAR g3a TO .g3a + .g3
SET VAR g3a TO .g3a * .hndkp
ELSE
SET VAR gib TO .gib + .gl
SET VAR gib TO .gib + .hndkp
SET VAR g2b TO .g2b + .g2
SET VAR g2b TO .g2b + .hndkp
SET VAR g3b TO .g3b + .g3
SET VAR g3b TO .g3b + .hndkp
ENDIF
SET VAR tot TO .gl + .g2
SET VAR tot TO .tot + .g3
ASSIGN totpins TO totpins*.tot IN tstats WHERE tnumb-.tnb
NEXT #2 егг2 ENDWHILE *0
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+1.0 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+1.0 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
*0
IF g2a > .g2b THEN
ASSIGN wins TO wins-ь 1.0 IN tstats WHERE tnumb=.teama
ASSIGN losses TO losses+1.0 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-ь!.0 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
*0
IF g3a > .g3b THEN
ASSIGN wins TO wins+1.0 IN tstats WHERE tnumb=.teama
ASSIGN losses TO losses+1.0 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+1.0 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
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+1.0 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+1.0 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
*0■
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 ENDWHILE *(Вывод положения команд для недели, номер которой был введен) *( выше.)
*()
NEWPAGE
WRITE ” ПО СОСТОЯНИЮ В НОЧЬ НА ПОНЕДЕЛЬНИК”
WRITE ” ПОЛОХЕНИЕ КОМАНД НА КОНЕЦ НЕДЕЛИ ” АТ 6 1 SHOW VAR in_wk=l AT 6 36 WRITE ” ”
SELECT ALL FROM tstats
WRITE "Нажмите любую клавишу для продолжения работы.” АТ 22 5; PAUSE-'
RETURN
R>l1st tstats
Table: tstats Read Password: NO Modify Password: NO
Column definitions
#
Name
Type
Length
Key
1
tnumb
INTEGER
1 value(s)
2
wins
REAL
1 value(s)
3
losses
REAL
1 value(s)
4
totpins
INTEGER
1 value(s)
Current number of rows:6
R>
(a)
R>select all from tstats tnumb wins losses totpins
1
0.00000
0.00000
2
0.00000
0.00000
3
0.00000
0.00000
4
0.00000
0.00000
5
0.00000
0.00000
6
0.00000
0.00000
R>
(6)
Рис. 10.22. Структура (а) и содержимое (б) отношения TSTATS в начальный момент выполнения модуля teamstd.prg.
Так как победы, поражения и общее число набранных очков не хранятся как часть базовых отношений в БД, было создано временное отношение для хранения указанных данных только в течение процесса вычислений, выполняемых при получении данных о положении команд. Это отношение имеет вид
TSTATS (tnumb, wins Josses .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. Символ “Ь“ подразумевает ту из рассматриваемых двух команд, которая выступает на площадке с четным номером. По завершении анализа индивидуальных результатов, показанных всеми игроками обеих команд, могут быть определены все победы и поражения рас-
сматриваемой недели. В этой точке та же процедура используется для команд, которым назначены следующие две площадки. Этот процесс будет продолжаться до тех пор, пока не будут исчерпаны все команды.
указательуказатель/ При week=l и 1апе=2 указатель #1 । устанавливается на tnumb=5./ При week=l и 1апе=2 указатель #1 । устанавливается на tnumb=5.
указатель
указатель
/ При week=l и 1апе=2 указатель #1 । устанавливается на tnumb=5.
/ При week=l и 1апе=2 указатель #1 । устанавливается на tnumb=5.
указательуказатель\ BOWLER\ BOWLER
указатель
указатель
\ BOWLER
\ BOWLER
I tnumb=5, на который настроен указатель #1, наст. раивает указатель #2 по tnumb=5 для получения , bname; единственная возможность - Джин Адамс.
SCORES
\ \
bname
week
gamel
game2
дашеЗ
\ ч
указатель #3-->
Джин Адамс
2
120
125
100
bname = Джин Адамс, получаемое по указателю #2, плюс значение week = 2 устанавливают указатель #3 на искомые результаты, показанные игроком
Рис. 10.23. Пример использования указателей в модуле teamstd.prg
*(Имя процедуры: getavg.prg )
*(Автор Гленн А.Джексон)
*(Оклендский университет, Рочестер, MI 48063)
*0
(Данная процедура предназначена для вычисления)
( результативности, используемой при определении гандикапа)
( для данного игрока на данную неделю сезона.)
( Ввод номера недели осуществляется через глобальную)
( переменную wk;)
( имени и фамилии игрока - через глобйльную переменную паше,)
( а вывод значения результативности - через глобальную)
( переменную avg. )
( Переменные ввода-вывода определяются как целые в вызывающей
( программе.)
(3тот модуль вызывается только тогда, когда номер вводимой)
*(Процедура вызывается из teamstd.prg. )
*0
SET VAR sum INTEGER
SET VAR si INTEGER
SET VAR s2 INTEGER
SET VAR s3 INTEGER
SET VAR numgams INTEGER
0
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. Это временное отношение в том смысле, что данные создаются, выводятся, а затем разруша-
ются. Значения, хранимые в этом отношении, не предполагается использовать при следующем выполнении модуля. В некоторые СУБД включены команды создания структуры временных отношений во время выполнения программы. Эти временные отношения существуют и могут быть использованы таким же образом, как и любые другие отношения, в то время, пока создавшая их программа находится в активном состоянии. По завершении выполнения этой программы временные отношения исчезают.
Модуль teamstd.prg вызывает одну процедуру: getavg.prg. Этот модуль, показанный на рис. 10.24, вычисляет значение average, необходимое для расчета величины гандикапа для данной недели и данного игрока. Например, если teamstd.prg вычисляет число побед и поражений для недели 4 сезона, то используемый при этом гандикап получается на основании значения average, вычисляемого для первых трех недель сезона. Процедура getavg.prg вычисляет значение average для каждого игрока.
Проблемы, возникающие при вводе в БД новых данных
Меню альтернатив, приведенное на рис. 10.5, касается получения данных из БД. Меню не способно оказать помощь секретарю при вводе новых кортежей в какое-либо отношение БД. Как было отмечено ранее в этой главе, данные, содержащиеся в настоящий момент в БД, были внесены в нее с помощью стандартных команд R:base 5000 LOAD и EDIT. Было бы полезно разработать и предоставить в распоряжение секретаря лиги меню, предназначенное для обеспечения ввода данных и служащего для него руководством при вводе часто встречающихся данных, как например, данных о всех индивидуальных результатах игрока на текущую неделю сезона. Эта проблема предлагается в качестве упражнения в конце главы.
Для обеспечения целостности данных в R:base 5000 существует встроенная команда RULES. Эта команда используется для определения условий, вынуждающих СУБД проверить соблюдение определенных ограничений, установленных пользователем для дан-
ных, хранимых в БД. Если правило определено для некоторого отношения, то система контролирует каждую операцию модификации данных и каждую операцию по добавлению данных в это отношение. Например, если пользователю необходима уверенность в том, что в отношении TEAM имеется не более одного кортежа с данным номером команды (номер tnumb является первичным ключом), то с помощью команды RULES может быть задано следующее правило, касающееся отношения TEAM:
"Дублированный ключ" tnumb IN team NEA tnumb IN team
“Дублированный ключ“ представляет собой сообщение об ошибке, которое будет выводиться всякий раз при попытке нарушить указанное условие, и NEA означает not equal to any (не равен ничему). Задача 10 в конце главы посвящена рассмотренной теме задания условий.
Комментарии к гл. 10
До тех пор пока запрос касается только извлечения информации из БД, его решение, вероятно, может быть получено на уровне команд R:base 5000. Некоторые из этих решений могут состоять из серий команд, составление которых требует довольно высокого уровня понимания идей, лежащих в основе БД. Эти решения не могут быть получены теми, кто не обладает соответствующими знаниями в данной области.
Если запрос подразумевает как извлечение данных, так и манипулирование ими, то решение обычно требует использования языка программирования БД. Эти решения могут быть весьма сложными и должны разрабатываться теми, кто знаком с идейной основой БД и обладает достаточными навыками в программировании.
Задачи к гл. 10
В той реализации меню в R:base 5000, которая была представлена в настоящей главе, все выходные данные пересылаются на терминальное устройство. Дополните меню альтернативой, которая бы позволи-
ла секретарю выбирать устройство вывода при каждом запуске. Разумным представляется решение о предоставлении возможности выбора одного из следующих вариантов вывода - только на терминальное устройство, только на печатающее устройство, как на терминальное, так и на печатающее устройства.
Расширьте меню, приведенное на рис. 10.5, с помощью добавления новых программных модулей, отвечающих некоторым из более сложных запросов, приведенных в разд. 10.2.
Решите задачу 1 из гл. 9, используя R:base 5000.
Решите задачу 3 из гл. 9, используя R:base 5000.
Измените teamstd.prg таким образом, чтобы формат вывода итогового положения команд в большей степени отвечал профессиональным стандартам. В текущей реализации вывод положения команд выполняется с использованием команды SELECT ALL
Измените bwlrst.prg так, чтобы обеспечивалось включение в выходные данные ОБЩЕГО ЧИСЛА НАБРАННЫХ ОЧКОВ С УЧЕТОМ ГАНДИКАПА.
Модуль teampns.prg выводит общее число “чистых" очков для каждой команды. Измените его таким образом, чтобы осуществлялся вывод также и ОБЩЕГО ЧИСЛА НАБРАННЫХ ОЧКОВ С УЧЕТОМ ГАНДИКАПА.
Основная часть алгоритма модуля wkschdl.prg реализована с помощью команды SET POINTER, за которой следует конструкция WHILE - THEN. Перепишите эту часть, используя команду JOIN, и определите, есть ли заметные изменения в скорости выполнения модуля. Какой из двух подходов удобнее?
Решите задачу 9 из гл. 9, используя R:base 5000.
Воспользуйтесь командой RULES для установления таких ограничений для каждого отношения, которыми для этих отношений обеспечивается уникальность первичных ключей.
Напишите несколько инициируемых с помощью меню программных модулей, позволяющих секретарю кегельной лиги, не обладающему глубокими знаниями в области БД, добавлять в БД результаты встреч для всех команд по любой неделе сезона. Этот модуль должен предоставлять секретарю разумный набор приглашений, а также шаблон для ввода корректных данных. Проследите, чтобы модуль выполнял все не-
обходимые проверки вводимых данных, которые не выполняются с помощью команды RULES из задачи 10. 12. Проанализируйте медленно выполняющиеся модули (например, teamstd.prg) и испробуйте различные методы уменьшения времени их выполнения. (Для группы студентов можно организовать полезный конкурс, цель которого состоит в создании программного модуля с наибольшей скоростью выполнения.)
Решите задачу 5 из гл. 9, используя R:base 5000.
НЕКОТОРЫЕ ДОПОЛНИТЕЛЬНЫЕ ЗАМЕЧАНИЯ
Приступая к написанию этой книги, автор не ставил перед собой задачу составления справочного руководства, которое бы включало в себя все достойные изучения знания, касающиеся проектирования реляционных БД и их реализации. Поэтому значительный по объему материал, являющийся частью всего комплекса знаний, называемого реляционными БД, не обсуждался. В этой главе высказываются некоторые соображения по поводу материала, изложенного в предыдущих главах, а также указываются некоторые другие области технологии БД из тех многих, которые не вошли в основную часть книги.
Другие нормальные формы
Методы проектирования, основанные на понятии ФЗ, рассматриваемые в гл. 3, 4 и 5, подробно описаны в литературе. Они использовались в различных приложениях и доказали свою эффективность в качестве средств проектирования. Вместе с тем, как и следует ожидать, ни одно отдельное средство не обеспечивает наилучшее решение всех проблем, с которыми может столкнуться проектировщик. Неизбежно возникают ситуации, в которых данные, предполагаемые к внесению в БД, связаны таким образом, что для получения наилучшего результата необходимо использовать специальные методы проектирования. Примером служат нормальные формы, накладывающие более сильные ограничения, чем НФБК, и развитые для устранения некоторых нежелательных характеристик, которые могут присутствовать даже в отношениях, находящихся в НФБК. Две из этих форм - четвертая нормальная форма (4НФ) и DK/НФ - рассмотрены в наиболее серьезных руководствах, посвященных проектированию БД. 4НФ касается отношений, в которых существуют наборы повторяющихся данных, и декомпозиция, основанная на использовании ФЗ, не приводит к исключению избыточности. Декомпозиция при переходе к 4НФ требует использования многозначных зависимостей, которые здесь не рассматрива-
ются. DK/НФ (domain-key normal form)1) можно рассматривать как предельную НФ, так как в отношениях, находящихся в этой форме, невозможны аномалии обновления. Однако пока не предложены никакие формализованные правила, способные помочь проектировщику преобразовать отношения в эту НФ.
Остались вне рассмотрения две НФ, накладывающие менее сильные ограничения, чем НФБК. Эти формы, известные как вторая нормальная форма (2НФ) и третья нормальная форма (ЗНФ), важны с точки зрения исторической перспективы. 2НФ была разработана для исключения аномалий, возникающих в отношениях, находящихся в 1НФ. ЗНФ была разработана для исключения аномалий, возникающих в отношениях, находящихся в 2НФ, и т. д. Крайне малое число БД было спроектировано для получения конечных отношений только в 2НФ или ЗНФ. Достаточно сказать, что если отношение находится в НФБК, то оно также находится как во 2НФ, так и в ЗНФ.
Понятием, прямо связанным с разложением отношений при переходе от одной НФ к другой (более высокого порядка), является понятие декомпозиции без потерь. Оно было упомянуто в главе 3 и детализировано в Приложении В.
Преимущества ER-метода
При начальном ознакомлении с ER-методом в гл. 6 было отмечено, что этот метод обладает несколькими преимуществами по сравнению с методами проектирования, основанными на понятии ФЗ:
Проектирование начинается с постепенно углубляющегося изучения всей полноты проблемы хранения данных. Такой подход дает проектировщику гораздо более отчетливое представление о решаемой проблеме, чем в том случае, когда проектирование начинается с анализа атрибутов и ФЗ.
^ Эта нормальная форма иногда называется “пятой*4 нормальной формой. Ее ввел в 1979 г. Фейгин (Fagin R.)» показав, что возможно осуществить декомпозицию отношений так, что остаются только ФЗ от атрибутов ключа и ограничения по размерам доменов для атрибутов. - Прим. ред.
Философия ER-проектирования может быть эффективно использована в задачах с большим числом атрибутов, в которых методы проектирования, основанные на ФЗ, становятся неуправляемыми.
Описание ER-метода, приведенное в книге, должно дать читателю основательный фундамент для развития своих аналитических возможностей, необходимых при решении многих проблем проектирования БД. Проектировщик должен помнить, что, даже когда проектирование базируется на ER-философии, нельзя упускать из виду ФЗ; результирующие проектные отношения всегда должны пройти проверку на нормализацию.
Цена нормализации
При первом обсуждении целей проектирования БД в гл. 2 было выдвинуто утверждение, что хорошим считается проектирование, при котором результатом декомпозиции одного или более исходных отношений является появление нескольких нормализованных отношений. Однако было отмечено, что в результате генерации новых отношений усложняется получение ответов на запросы к БД по сравнению со случаем БД, состоящей из меньшего числа отношений. Таким образом возникает проблема: следует ли проектировщику сохранять БД в НФБК или же ограничивать число отношений для упрощения пользования БД. Однозначного решения этой проблемы нет.
Некая крупная корпорация разработала большую БД, в которой все данные хранятся в одном отношении, не находящемся даже в первой нормальной форме. Сотрудники, ответственные за сопровождение БД, утверждают, что возникают затруднения из-за того, что в основу проектирования БД не были положены НФБК-спецификации, однако главными преследуемыми целями являются скорость доступа и простота форматов запросов. Аномалии могут возникнуть из-за того, что БД не находится в НФБК, но соблюдение осторожности служит достаточной от них защитой. Гарантией служит то обстоятельство, что пользователям предоставляется лишь ограниченный набор опций запросов и обновления; эти опции доступны пользователям через специально спроектированное программное обеспечение.
Вышеприведенный пример, в котором БД состоит из одного отношения, не находящегося в 1НФ, нетипичен. Большинство администраторов БД настаивают на необходимости проектирования всех БД таким образом, чтобы каждое отношение каждой БД находилось по крайней мере в НФБК. По их мнению, с которым нельзя не считаться, большинство пользователей не обладают в теории БД знаниями, достаточными для своевременного обнаружения всех подводных камней, присутствующих в БД в случае отсутствия нормализации в НФБК. Эти проектировщики готовы пойти на увеличение размеров запросов и усложнение операций обновления для гарантии целостности данных в БД.
На этапе завершения процесса проектирования вне зависимости от используемого метода необходимо оценить предложенный проект как с практической, так и с технической точек зрения. Два момента, на которые необходимо обратить внимание, иллюстрируются следующими вопросами:
Будет ли предполагаемая реализация БД обеспечивать достаточно быстрое выполнение запросов? Как велико то время, которое требуется СУБД для ответа при использовании данной БД?
Могут ли быть получены ответы на запросы “естественным“ образом, без привлечения для составления запросов профессиональных программистов? Если привлечение программистов необходимо, то насколько это соответствует нуждам предприятия?
В случае отрицательного ответа на какой-либо из этих вопросов необходим пересмотр проектного решения.
Существует несколько способов, следуя которым проектировщик может попытаться увеличить скорость ответа БД на запросы:
Индексация тех отношений, к которым регулярно применяется операция поиска, с тем же атрибутом, который служит ключом поиска.
Замена таких команд, как JOIN, выполнение которых требует значительного времени, на более простые, но и более быстрые конструкции.
Если решение запроса потребовало использования программы, написанной на языке высокого уровня, следует проверить, нет ли более простого, более прямого алгоритма решения проблемы.
Ревизия исходной философии проектирования, предпринимаемая с целью выявления ранее принятых решений, последствия которых сказываются отрицательно на конечном продукте. Хорошим примером в этой связи может служить решение, принятое в задаче построения БД секретаря (гл. 5), основанное на нежелании хранения каких-либо атрибутов, чьи значения могут быть вычислены на основании других атрибутов в БД. Компенсировало ли улучшение целостности, достигнутое в результате принятия этого решения, увеличение времени выполнения?
Совместное использование БД
Представленные в гл. 9 программы были написаны для СУБД, в среде которой только один пользователь может иметь доступ к соответствующей БД в каждый момент времени. Многие СУБД допускают возможность открытия БД несколькими, или, возможно, многими пользователями в одно и то же время. В этих условиях каждый пользователь должен дать точную информацию СУБД о тех отношениях, которые им будут использоваться, и способе использования каждого из этих отношений. Кроме того, каждый пользователь должен информировать СУБД об ограничениях, которыми обуславливается применение этих отношений другими пользователями БД. Например, пользователь может потребовать, чтобы в течение выполняемого им процесса извлечения информации из отношения R1 никакому другому пользователю не было разрешено удаление кортежей, принадлежащих отношению R1, их модификация или добавление в это отношение новых кортежей. В системах, предоставляющих такую возможность, предусматриваются специальные команды, используемые при организации управления совместной обработкой. Одной из первых реляционных СУБД, включающих в свой состав довольно полный набор команд управления процессом совместной обработки, является система MRSD
(Multics Relational Data Store)1), разработанная фирмой Honeywell Information Systems.
СУБД, обеспечивающие режим совместной обработки, ориентированы на их использование в сочетании с сетевыми структурами. В некоторых реализациях БД размещаются не в каком-либо одном месте, а распределяются между несколькими компьютерными системами, связанными между собой сетью. Как dBASE III, так и R:base 5000 оснащены сетевыми возможностями. С деталями читатель может ознакомиться в соответствующих справочных руководствах, выпущенных фирмами-изготовителями.
Администрирование БД
В этой книге не делалось попыток рассмотреть вопросы администрирования БД. Проблемы, связанные как с применением паспортов и шифрованием данных, что имеет своей целью обеспечение их секретности, так и с созданием резервных копий БД, обеспечивающих возможность восстановления информации, утерянной в результате проникновения в БД ошибок, не рассматриваются в данной книге.
Универсальная техника, используемая администраторами БД с целью обеспечения секретности и защиты данных, основана на использовании локальных представлений или подмоделей. При этом для конкретного пользователя доступной для использования является только часть всей БД. БД в действительности логически разделяется на части с целью ограничения возможностей доступа для каждого отдельного пользователя. Большинство из разработанных за последнее время СУБД обладает этой возможностью.
Ц Multics Relational Data Store Reference Manual, Order Number AW53-04A, Honeywell Informations Systems, 1983.
ПРИЛОЖЕНИЕ А
Реляционная алгебра
Реляционная алгебра состоит из множества операторов высокого уровня, применение которых к отношениям приводит к генерации новых отношений. Тремя наиболее часто используемыми операторами являются операторы ВЫБОРКА, ПРОЕКЦИЯ и СОЕДИНЕНИЕ. Языки запросов всех СУБД включают в свой состав команды, эквивалентные перечисленным выше. В приложении будут определены эти три оператора, показаны их базовые операторные характеристики, приведены примеры их конкретных реализаций как в dBASE III, так и в R:base 5000. Все примеры основаны на двух отношениях, показанных на рис. АЛ.
АВС
DEF
Name
Room
Rphone
Phone
Type
ДХИА
234
3256
1267
Dial
Джон
126
1267
3256
PshBtn
Зиппи
126
5298
3623
4311
Pay Dial
5298
PshBtn
Рис. АЛ. Примеры отношений АВС и DEF
В отношении АВС содержатся имена студентов (Name), номера комнат, которые им отводятся (Room), и номера телефонов (Rphone). Отношение DEF содержит информацию о типах телефонов (Туре), связанную с каждым телефонным номером (Phone). Атрибуты Rphone и Phone получают значения из одного домена телефонных номеров студенческого городка.
АЛ. Оператор реляционной алгебры ВЫБОРКА
Оператор ВЫБОРКА реляционной алгебры применяется к единичному, уже существующему, отношению и результатом этого применения является генерация но-
вого отношения. Новое отношение получается путем ВЫБОРКИ только тех кортежей из исходного отношения, которые удовлетворяют заданному условию.
Общая форма оператора ВЫБОРКА имеет вид
ВЫБОРКА ИЗ Имя—Отношения
ГДЕ Условие
ПОЛУЧАЯ Имя—Результата
В этом определении Имя—Отношения представляет собой имя исходного отношения, Условие есть условие, которое должно учитываться при выборе кортежей, и Имя—Результата - имя отношения, которое будет содержать результаты выполнения операции.
Для иллюстрации использования общей формы положим, что новое отношение необходимо получить из отношения DEF (Phone,Туре) путем выборки тех кортежей, в которых значением атрибута Туре является Dial. Общая форма команды примет вид
ВЫБОРКА ИЗ DEF
ГДЕ Туре = 'Dial'
ПОЛУЧАЯ RESULT
В результате выполнения этой команды будет получено отношение, приведенное на рис. А.2. На практике отношение RESULT либо размещается в памяти на диске в качестве временного отношения, либо просто выводится на терминал в зависимости от используемой СУБД. Если результат выводится на терминал, то заголовки, указывающие имена отношения и атрибутов, могут и не выводиться вместе с данными, также в зависимости от СУБД.
RESULT
Phone
Туре
1267
Dial
4311
Dial
Рис. А.2. Отношение, полученное с помощью операции ВЫБОРКА
Чтобы проиллюстрировать то, как будет выглядеть последний пример при использовании как dBASE III, так и R:base 5000, предположим, что были созданы отношения АВС и 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
1267 Dial
4311 Dial
Рис. А.З. Способы генерации операции ВЫБОРКА в dBASE III
Команда USE DEF переводит в активное состояние отношение, которое будет использоваться. Компонента OFF команд LIST и DISPLAY предотвращает СУБД от вывода номеров выбранных кортежей (помимо собственно содержимого кортежей).
.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, хотя и представляет собой символьную строку.
R>OPEN APPNDXA Database exists
R>SELECT ALL + R>FROM DEF + R>WHERE Type EQ Dial
Phone Type
1267 Dial
4311 Dial R>
Рис. A.4. Генерация операции ВЫБОРКА в R:base 5000.
А.2. Оператор реляционной алгебры ПРОЕКЦИЯ
Оператор реляционной алгебры ПРОЕКЦИЯ применяется к одному существующему отношению для получения нового отношения. Новое отношение получается путем выбора (ПРОЕЦИРОВАНИЯ) определенных столбцов из текущего отношения. Если результат выполнения операции ПРОЕКЦИЯ содержит повторяющиеся кортежи, то в новом отношении сохраняется только один кортеж из повторяющейся группы. (В большинстве микрокомпьютерных СУБД повторяющиеся кортежи автоматически не удаляются, это обязан делать пользователь. Следует помнить, что корректное отношение не может содержать повторяющихся кортежей.)
Общая форма оператора ПРОЕКЦИЯ имеет вид
ПРОЕКЦИЯ al,a2,...an ИЗ Имя—Отношения ПОЛУЧАЯ Имя—Результата
В данном определении al,a2,..,an - это список названий атрибутов (столбцов), выбираемых из отношения с именем Имя-Отношения. Результат операции будет записан в отношение с именем Имя—Результата. Для иллюстрации использования общей формы рассмотрим пример, в котором необходимо выбрать с помощью оператора ПРОЕКЦИЯ столбцы Name и Room из отношения АВС. Достигается это следующим образом:
ИЗ АВС
ПОЛУЧАЯ RESULT
Получаемое в результате отнршение показано на рис. А.5.
RESULT
Наше
Room
ДХИА
234
Джон
126
Зиппи
126
Рис. А.5. Результат применения операции ПРОЕКЦИЯ к отношению АВС
С целью показать способ удаления дублированных кортежей из отношения, полученного после выполнение оператора ПРОЕКЦИЯ, допустим, что из отношения DEF(Phone,Type) выбирается столбец Туре. Синтаксически соответствующая процедура выглядит так:
ПРОЕКЦИЯ Туре
ИЗ DEF
ПОЛУЧАЯ RESULT
RESULT
Type
Dial PshBtn Pay
Рис. A.6. Проекция с удалением дублированных кортежей
. 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 it? (Y/N) Yes
records copied
* USE RESULT . LIST ALL Record#NameRoom
1Джиа234
2Джон126
3Зиппи126
Рис. А.7. Генерация операции ПРОЕКЦИЯ в dBASE III
В результате выполнения операции будет получено отношение, показанное на рис. А.б, из которого удалены дублированные кортежи, содержащие Dial и PshBtn. (Такое отношение, как RESULT, в котором имеется только один столбец, называется унарным. Хотя унарные отношения можно получить с помощью операции ПРОЕКЦИЯ, они никогда , не сохраняются в БД, так как содержат минимум информации.)
Операция ПРОЕКЦИЯ в dBASE III реализуется с помощью комбинаций тех же команд, которые использовались при генерации команды ВЫБОР. Существуют три возможности выполнения операции ПРОЕКЦИЯ. Они будут проиллюстрированы на примере проецирования столбцов Name и Room отношения АВС:
.USE АВС
.LIST Name,Room
.DISPLAY ALL Name,Room
.COPY TO RESULT FIELDS Name,Room
Примеры использования каждой из этих команд в случае реальной БД приведены на рис. А.7. Обратите внимание, что команды LIST и DISPLAY посылают результаты на терминал. (Их можно передать и на печатающее устройство.) Команда COPY осуществляет пересылку результатов в отношение на диск. Номера записей в выходных данных могут быть исключены с помощью включения компоненты OFF в команды LIST и DISPLAY.
Последний пример на рис. А.7 представляет собой проекцию атрибута Туре из отношения DEF и иллюстрирует тот факт, что в dBASE III дублированные кортежи из отношений автоматически не удаляются.
Оператор ПРОЕКЦИЯ в СУБД R:base 5000 может быть реализован и в виде варианта команды ВЫБОРКА. Для выполнения рассмотренных выше двух операций проекции над отношениями DEF и АВС можно воспользоваться следующими командами:
R>OPEN APPNDXA R>SELECT Name Room + R>FROM ABC и
R>SELECT Type +
R>FROM DEF
R>SELECT Name Room + R>FROM ABC Name Room
Джиа234
Джон126
Зиппи126
R>
R>SELECT Type + R>FROM DEF
Type
Dial
PshBtn
Pay
Dial
PshBtn
R>
Результаты выполнения этих команд для случая реальной БД приведены на рис. А.8. (Обратите внимание, что здесь также присутствуют дублированные кортежи.) Если результаты применения проекции необходимо сохранить в БД, то следует использовать существующую в R:base 5000 команду PROJECT.
А.З. Оператор реляционной алгебры СОЕДИНЕНИЕ
Оператор СОЕДИНЕНИЕ предназначен для создания одного нового отношения из двух уже существующих отношений. Новое отношение получается путем конкатенации (соединения) кортежей первого отношения с кортежами второго отношения. Только те кортежи подвергаются конкатенации, в которых значение специфицированного атрибута в первом отношении совпадает со значением специфицированного атрибута второго отношения (значения оба атрибута должны получать из одного домена.) Если первое отношение, являющееся объектом операции СОЕДИНЕНИЕ, имеет N столбцов, а второе - М столбцов, то получаемое в результате отношение будет иметь М + N столбцов. В получаемом отношении в двух столбцах всегда будут содержаться одинаковые значения. Если один из этих столбцов удалить, то принято называть результат ЕСТЕСТВЕННЫМ СОЕДИНЕНИЕМ.
Общая форма оператора СОЕДИНЕНИЕ имеет вид
СОЕДИНЕНИЕ Отношение—1 И Отношение—2 ПО Атрибут-1 И Атрибут-2 ПОЛУЧАЯ Имя-Результата
Здесь Отношение—1 и Отношение—2 идентифицируют два отношения, над которыми осуществляется операция СОЕДИНЕНИЕ. Атрибут—1 (входит в Отношение—!) и Атрибут—2 (входит в Отношение—2) идентифицируют атрибуты, используемые при определении кортежей, включаемых в конечное отношение. (Эти два атрибута должны получать значения из одного домена.) Имя-Результата является именем отношения, в котором будут размещены результаты выполнения операции.
В качестве примера рассмотрим случай соединения отношений АВС и DEF (общим является домен телефонных номеров студенческого городка)
СОЕДИНЕНИЕ АВС И DEF ПО Rphone И Phone ПОЛУЧАЯ RESULT
Результатом выполнения данной операции будет отношение, приведенное на рис. А.9. Обратите внимание, что значения Rphone и Phone идентичны. После исключения одного из этих столбцов (с помощью операции СОЕДИНЕНИЕ) будет получено ЕСТЕСТВЕННОЕ СОЕДИНЕНИЕ.
RESULT
Name
Room
Rphone
Phone
Type
Д*ИА
234
3256
3256
PshBtn
Джон
126
1267
1267
Dial
Зиппи
126
5298
5298
PshBtn
Рис. А.9. Отношение, полученное с помощью операции СОЕДИНЕНИЕ
. SELECT 2
. USE DEF
. SELECT 1
. USE ABC
. JOIN WITH DEF TO RESULT FOR Rphone = DEF->Phone 3 records joined
. USE RESULT
LIST
OFF
NAME
ROOM
RPHONE
PHONE
TYPE
Джиа
234
3256
3256
PshBtn
Джон
126
1267
1267
Dial
Зиппи
126
5298
5298
PshBtn
Рис. A. 10. Генерация операции СОЕДИНЕНИЕ в dBASE III
REOPEN APPNDXA Database exists
R>JOIN ABC USING Rphone +
R>WITH DEF USING Phone +
R>FORMING RESULT
Successful join operation 3 rows generated R>SELECT ALL + R>FROM RESULT
Name
Room
Rphone
Phone
Type
Джиа
234
3256
3256
PshBtn
Джон
126
1267
1267
Dial
Зиппи
126
5298
5298
PshBtn
Рис. A.1L Генерация операции СОЕДИНЕНИЕ в R:base 5000
При выполнении соединения как в dBASE III, так и в R:base 5000 используется команда JOIN языка запросов. Точный синтаксис при этом различный. В dBASE III последний пример реализуется следующим образом:
.SELECT 2 .USE DEF .SELECT 1 .USE ABC JOIN WITH DEF TO RESULT FOR Rphone=DEF->Phone
Результат выполнения приведенной последовательности команд в случае реальной БД приведен на рис. АЛО.
Та же самая операция для случая 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" (успешное выполнение операции соединения) после того, как получаемое отношение было помещено в дисковую память. Для того чтобы просмот-
реть результаты, пользователю необходимо воспользоваться командой
R>SELECT ALL FROM RESULT
Приведенная последовательность команд иллюстрируется рис. А.11.
А.4. Комбинированные команды
Как dBASE III, так и R:base 5000 обеспечивают выполнение структурных команд запросов, позволяющих сочетать два типа операций в одной команде. Например, в случае R:base 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) к тому же результату, что и выполнение запроса в случае исходного отношения?44. Если нет, тогда алгоритм проектирования приведет к получению набора отношений, порождающих несогласующиеся данные.
Отношения, полученные с помощью декомпозиции, всегда будут приводить к получению согласующихся данных в том случае, когда декомпозиция была проведена способом, при котором естественное соединение отношений R1(X,Y) и R2(Y,Z) дает в итоге в точности исходное отношение R(X,Y,Z). Декомпозиция, характеризующаяся этим качеством, называется “декомпозицией без потерь при естественном соединении44. Если естественное соединение R1 и R2 приводит к появлению большего, чем в отношении R, числа кортежей, то декомпозиция называется декомпозицией с потерями. Отсутствие потерь при декомпозиции отношения R(X,Y,Z) на R1(X,Y) и R2(Y,Z) гарантируется при условии, если от общего атрибута двух получаемых отношений - в данном случае атрибута Y - зависит хотя бы один атрибут из двух оставшихся. В нашем случае, если Y -> X или Y -> Z, то декомпозиция осуществляется без потерь.
На рис/ ВЛ показан пример декомпозиции с потерями. В этом примере ни Y -> X, ни Y -> Z не являются корректными ФЗ и естественное соединение R1 и R2 порождает два новых кортежа. На рис. В.2 приведен пример декомпозиции без потерь. В этом примере предполагается, что Y -> Z является корректной ФЗ и значения экземпляра R(X,Y,Z) отражают этот факт. Естественное соединение R1 и R2 в
этом случае дает в результате в точности исходное отношение.
XYZ1 352243 62XYZ1 352243 62R(X,Y,Z)R(X,Y,Z)Декомпозиция I IДекомпозиция I IНи X, ни Y не зависят функционально от ZНи X, ни Y не зависят функционально от Z
X
Y
Z
1 3
5
2
2
4
3 6
2
X
Y
Z
1 3
5
2
2
4
3 6
2
R(X,Y,Z)
R(X,Y,Z)
Декомпозиция I I
Декомпозиция I I
Ни X, ни Y не зависят функционально от Z
Ни X, ни Y не зависят функционально от Z
XY1 3 5224XY1 3 5224R1(X,Y)R1(X,Y)YZ224362YZ224362R2(Y,Z)R2(Y,Z)
X
Y
1 3 5
2
2
4
X
Y
1 3 5
2
2
4
R1(X,Y)
R1(X,Y)
Y
Z
2
2
4
3
6
2
Y
Z
2
2
4
3
6
2
R2(Y,Z)
R2(Y,Z)
СОЕДИНЕНИЕ R1 и R2СОЕДИНЕНИЕ R1 и R2
СОЕДИНЕНИЕ R1 и R2
СОЕДИНЕНИЕ R1 и R2
Рис. ВЛ. Пример декомпозиции с потерями
Для иллюстрации тех проблем, причиной появления которых может послужить декомпозиция с потерями, рассмотрим запрос: “Какое значение атрибута Z связано со значением 1 атрибута Х?“. Если воспользоваться синтаксисом dBase III, то ответ на запрос можно получить с помощью следующих предложений:
XYZ1 3 52 243 32XYZ1 3 52 243 32R(X,Y,Z)R(X,Y,Z)ДекомпозицияДекомпозицияY -> Z является ФЗY -> Z является ФЗR1(X,Y)R2(Y,Z)R1(X,Y)R2(Y,Z)YZ2432YZ2432СОЕДИНЕНИЕСОЕДИНЕНИЕXYZ1 352 24332XYZ1 352 24332R(X,Y,Z)R(X,Y,Z)Те же кортежи, что и в отношении R(X,Y,Z)Те же кортежи, что и в отношении R(X,Y,Z)
X
Y
Z
1 3 5
2 2
4
3 3
2
X
Y
Z
1 3 5
2 2
4
3 3
2
R(X,Y,Z)
R(X,Y,Z)
Декомпозиция
Декомпозиция
Y -> Z является ФЗ
Y -> Z является ФЗ
R1(X,Y)R2(Y,Z)
R1(X,Y)R2(Y,Z)
Y
Z
2
4
3
2
Y
Z
2
4
3
2
СОЕДИНЕНИЕ
СОЕДИНЕНИЕ
X
Y
Z
1 3
5
2 2
4
3
3
2
X
Y
Z
1 3
5
2 2
4
3
3
2
R(X,Y,Z)
R(X,Y,Z)
Те же кортежи, что и в отношении R(X,Y,Z)
Те же кортежи, что и в отношении R(X,Y,Z)
Рис. В.2. Пример декомпозиции без потерь
.USE R
.LIST OFF Z FOR X = 1
Для экземпляров отношения R, приведенных на рис. В. 1 и В.2, будет получен ответ Z = 3. Если ответ на запрос должен быть получен исходя из отношений R1 и R2, то запрос следует сформировать следующим образом:
.SELECT 2
.USE R2 .SELECT 1 .USE RI JOIN WITH R2 TO RESULT;
FOR X = 1 .AND. Y = R2->Y FIELDS Z .USE RESULT .LIST OFF
Если воспользоваться отношениями RI и R2 из рис. ВЛ (декомпозиция с потерями), то выполнение запроса даст два значения Z (3 и 6). Если воспользоваться отношениями R1 и R2 из рис. В.2 (декомпозиция без потерь), то в результате выполнения запроса будет получено только правильное значение (Z = 3). Значение Z = б из первого случая не согласуется с исходными данными, что является прямым результатом проведения декомпозиции с потерями. Декомпозиция без потерь дает правильный результат.
Концепция, представленная в этом приложении, крайне простая, но в то же время очень важная. Проектировщик БД должен помнить, что если отношения в БД были получены с помощью декомпозиции с потерями, то выполнение некоторых запросов приведет к появлению побочных данных. Наоборот, если отношения в БД были получены с помощью декомпозиции без потерь, выполнение запросов будет приводить к получению тех значений, которые были бы получены из исходного отношения (отношений). Базовый алгоритм декомпозиции, приведенный в гл. 3, является алгоритмом декомпозиции без потерь.
В вышеприведенном обсуждении декомпозиции без потерь предполагалось, что атрибуты X, Y и Z являются простыми. В общем случае X, Y и Z могут быть как простыми, так и составными атрибутами.
ПЕРЕЧЕНЬ ФАЙЛОВ, ИСПОЛЬЗУЕМЫХ В
УЧЕБНЫХ ПРИМЕРАХ БД
На рис. С.1 приведен перечень файлов, используемых в реализации БД секретаря кегельной лиги для случая dBASE III (гл. 9).
На рис. С.2 приведен перечень файлов, используемых в реализации БД секретаря кегельной лиги для случая R:base 5000 (гл. 10).
Volume in drive В has no label
Directory of B:\
SDBMAIN
PRG
1602
11-03-86
l:17p
SCHED
DBF
231
5-09-86
l:31p
WKSCHDL
PRG
1676
6-08-86
8:57p
TEAM
DBF
323
5-10-86
4:27p
DELAY
PRG
418
6-01-86
10:01p
SCORES
DBF
2691
5-20-86
4:44p
BWLRST
PRG
2871
6-10-86
2:37p
TEAMPNS
PRG
1263
6-08-86
8:41p
BOWLER
DBF
1347
5-20-86
4:05p
EOSRPT
PRG
2432
11-11-86
6:20p
HIGHSER
DBF
99
11-03-86
l:43p
HIGHGAM
DBF
115
11-03-86
l:43p
HIGHAVG
DBF
99
11-03-86
l:44p
FILEOUT
PRG
531
5-19-86
7:51p
TEAMSTD
PRG
4736
11-11-86
6:39p
T.STATS
DBF
253
11-03-86
2:00p
NUMB
NDX
1024
5-21-86
9:25a
FINDWK
PRG
804
5-22-86
2:54p
HNDKP_AV
PRG
1023
5-28-86
l:23p
19 File(s) 328704 bytes free
Рис. C.l. Перечень файлов, используемых в реализации БД, приведенной в гл. 9
Volume in drive В has no label
Directory of B:\
SDB1
RBS
9600
2-10-87
10:20p
SDB2
RBS
10752
2-10-87
10:20p
SDB3
RBS
1024
2-10-87
10:20p
SECDB
API
12064
6-19-86
2:24p
SECDB
APX
13568
9-28-86
12:16p
EOSRPT
PRG
3840
9-28-86
11:13a
BWLRST
COM
4793
9-28-86
11:26a
BWLRST
CMD
3840
9-24-86
3:02p
SECDB
APP
5888
9-28-86
12:14p
EOSRPT
COM
5465
9-28-86
11:28a
TEAMSTD
COM
9653
9-28-86
11:32a
GETAVG
PRG
1154
9-10-86
6:56p
TEAMSTD
PRG
6528
9-12-86
l:52p
13 File(s) 268288 bytes free
Рис. С.2. Перечень файлов, используемых в реализации БД, приведенной в гл. 10
ЛИТЕРАТУРА
Chen, P.P.S.“The Entity-Relationship Model - Toward a Unified View of Data,“ACM Transactions on Database Systems, vol. 1, no. 1 (March, 1979), pp.9-36.
Date, C.J. An Introduction to Database Systems, vol. 1, (4th ed.).Reading, MA and Menlo Park, CA: Addison-Wesley Publishing Co., Inc., 1986.
Date, C.J. An Introduction to Database Systems, vol. 2. Reading, MA and Menlo Park, CA: Addison- Wesley Publishing Co., 1983.
Date, C.J. Database: Primer. Reading, MA and Menlo Park, CA: Addison-Wesley Publishing Co., 1983.
Hawryszkiewycz, LT. Database Analysis and Design. Chicago: Science Research Associates, Inc., 1984.
Howe, D.R. Data Analysis for Data Base Design. Baltimore, MD: Edward Arnold/University Park Press, 1983.
Kroenke, D.M., and D.E. Nilson. Database Processing for Microcomputers. Chicago: Science Research Associates, 1986.
Ullman, J.D. Principles of Database Systems (2nd ed.). Rockville, MD: Computer Science Press, 1982.
Vasta, J.A. Understanding Data Base Management Systems. Belmont, CA: Wadsworth Publishing Co., 1985.
СОДЕРХАНИЕ
ПРЕДИСЛОВИЕ РЕДАКТОРА ПЕРЕВОДА5
ПРЕДИСЛОВИЕ7
Базы данных, отношения и реляционные базыданных10
Базовые концепции10
Определение отношения12
Определение реляционнойБД14
Необходимость проектированиябаз данных20
Цели проектирования20
Универсальное отношение24
Проблемы, вызываемые использованием единственного отношения27
Задачи к гл. 231
Функциональные зависимости32
Первая нормальная форма(1НФ)32
Концепция функциональных зависимостей32
Нормальная форма Бойса-Кодда (НФБК)35
Общий подход к декомпозиции37
Обзор исходных аномалий41
Другая декомпозиция отношенияКОНСУЛЬТАНТ45
Некоторые комментарии к декомпозиционному алгоритму проектирования46
Задачи к гл. 350
Некоторые модификации алгоритма проектирования52
Избыточные функциональныезависимости52
Транзитивные зависимости52
Добавление атрибутов в ФЗ54
Правила вывода55
Минимальное покрытие57
Пересмотренный алгоритм проектирования60
Проверка отношений на завершающей фазе их проектирования61
Задачи к гл. 462
Учебный пример проектированияБД65
Постановка задачи65
Определение атрибутов универсальногоотношения66
Диаграммы функциональныхзависимостей69
Получение путем редукции набора НФБК-отношений72
Оценка спроектированных НФБК-отношений.,76
Задачи кгл. 578
Другой подходк проектированию79
Сущностии связи79
Степеньсвязи82
Некоторые замечания по поводу графического представления92
Задачи к гл. 693
Получение отношенийиздиаграммER-типа94
Предварительные отношения для бинарных связей степени 1:195
Первый пример ER-проектирования100
Предварительные отношения для бинарных связей степени 1:N103
Предварительные отношения для бинарных связей степени M:N107
Второй пример ER-проектирования109
Пересмотр БД секретаря кегельной лигиИЗ
Некоторые замечания, касающиеся числа отношений....115
Задачи к гл. 7115
Дополнительные конструкции, используемые в ER-методе....117
Необходимость связей более высокого порядка117
Предварительные отношения для трехсторонних связей.121
Использование ролей122
Более крупный пример ER-проектирования127
Задачи к гл. 8132
dBASE II1-реализация БД секретаря кегельной лиги134
Анализ отношений БД с помощью тестовых данных при использовании dBase III134
Ответы на запросы секретаря лиги в dBase III139
Основное меню заранее подготовленных запросов145
ПрограммныймодульBWLRST.PRG149
ПрограммныймодульTEAMPNS.PRG153
ПрограммныймодульWKSCHDL.PRG157
ПрограммныймодульEOSRPT.PRG160
ПрограммныймодульTEAMSTD.PRG165
Структура временных отношений171
Необходимость входного меню173
Задачи к гл. 9175
R:base 5000-реализация БД секретаря кегельной лиги179
Анализ отношений БД с помощью тестовых данных при использовании R:base 5000179
Ответы на запросы секретаря в R:base 5000184
Основное меню заранее подготовленных запросов....192
Модуль BWLRST.PRG в R:base 5000195
Программный модуль TEAMPNS.PRG в R:base 5000199
Программный модуль VKSCHDL.PRG в R:base 5000202
Программный модуль EOSRPT.PRG в R:base 5000205
Программный модуль TEAMSTD.PRG в R:base 5000209
Проблемы, возникающие при вводе в БД новых данных220
Комментарии к гл. 10221
Задачи к гл. 10221
Некоторые дополнительные замечания224
Другие нормальные формы224
Преимущества ER-метода225
Цена нормализации226
Совместное использование БД228
Администрирование БД229
ПРИЛОХЕНИЕ А
Реляционная алгебра230
А.1.ОператорреляционнойалгебрыВЫБОРКА230
А. 2.ОператорреляционнойалгебрыПРОЕКЦИЯ234
А.З.ОператорреляционнойалгебрыСОЕДИНЕНИЕ238
А.4.Комбинированные команды241
ПРИЛОХЕНИЕ В
Декомпозиция без потерь242
ПРИЛОХЕНИЕ С
Перечень файлов, используемых в учебных примерах БД....246
ЛИТЕРАТУРА248
В 1991 Г. ИЗДАТЕЛЬСТВО “МИР“ВЫПУСКАЕТ КНИГУ
Куправа Т.А. “Создание и программирование баз данных средствами СУБД dBase III Plus, FoxBase Plus, Clipper“, 10 л.,8 p.,75 000 экз.
В книге приведены необходимые на практике сведения по автоматизации и проектированию баз данных. Рассмотрены основные принципы работы и программирование в среде наиболее популярных СУБД типа dBase III Plus (Микро-РС-2, Ребус, Карат).
Книга предназначена для широкого круга пользователей персональных компьютеров IBM PC, PC ХТ/АТ или совместимых, студентов и программистов, желающих самостоятельно создавать базы данных, автоматизированные информационные системы.
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 041(01)-91д 2404090000-070 041(01)-91133-91133-91ББК 32.973ББК 32.973
д 2404090000-070 041(01)-91
д 2404090000-070 041(01)-91
133-91
133-91
ББК 32.973
ББК 32.973
Редакция литературы по информатике и робототехнике
Научное издание
Глен Джексон
Проектирование реляционных баз данных для использования с микроЭВМ
Заведующий редакцией д-р техн, наук А.Л. Щерс. Зам. заведующего редакцией Э.Н. Бадиков. Научный редактор С.В.Богдасаров.
Художник А.В. Захаров
Художественные редакторы Н.М. Иванов, О.Н. Адаскина
Оригинал-макет подготовлен на персональном компьютере и отпечатан на лазерном принтере в издательстве “Мир“
Подписано к печати 10.06.91. Формат 84х108Д2. Бумага офсетная N 1. Печать офсетная. Объем 4 бум.л. Усл.печ.л. 13,44. Усл.кр.- отт. 13,7 5. Уч.-изд.л. 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