    Предисловие 

    Область системного программирования развивается главным образом благодаря 
усилиям программистов и менеджеров, чья творческая энергия направлена на 
создание необходимых для стремительно возрастающей компьютерной индустрии 
утилитарных системных программ. Раньше программирование можно было сравнить с 
творческим процессом, каждый участник которого — программист — изобретал свое 
решение задачи, не опираясь на чье-либо руководство и не зная методов решения 
этой задачи коллегами. В 1968 году Ашер Оплер (Ascher Opier), а вслед за ним и 
фирма IBM осознали необходимость накопления опыта программирования в форме, 
доступной всем системным программистам. Изучая область программирования, он 
пришел к выводу, что существует достаточно материала, способного оправдать 
затраченные им усилия. По его рекомендации фирма IBM приняла решение выступить 
спонсором издания книг серии "Системное программирование" как долговременного 
проекта, цель которого — накопление и широкое распространения принципов и 
технологий, имеющих большое значение для компьютерной индустрии. 
    Книги серии "Системное программирование" представляют собой справочные 
руководства по конкретным областям. В каждой книге представлены собственные 
взгляды автора на предмет и не всегда отражаются взгляды корпорации IBM. 
Каждая книга организована как курс изучения данного предмета и в то же время 
достаточно детализирована для использования в качестве справочника. 
    Серия охватывает такие области, как системы баз данных, коммуникационные 
системы, графические системы, экспертные системы, управление программным 
процессом. В дальнейшем в серии будут освещены области, которые сейчас 
находятся еще на стадии развития. 
    Настоящее издание наиболее тщательно проработано по сравнению с 
предыдущими. Здесь заложен базис для фундаментального образования в области 
основ технологии построения систем баз данных, а также отражены самые 
последние исследования в этой области. 
    Редакционная коллегия 
    
    6 

    Об авторе 
    К. Дж. Дейт (C.J. Date) — независимый автор, лектор и консультант, 
специализирующийся на системах реляционных баз данных. Он живет в Хилдсбурге, 
шт. Калифорния. 
    Начиная с 1967 года он несколько лет работал математиком-программистом и 
инструктором по программированию в компании Leo Computers Ltd. (Лондон, 
Великобритания). После этого Дейт работал в лаборатории IBM (UK) Development 
Laboratories над интеграцией функций баз данных в язык PL/I. В 1974 году он 
перешел в калифорнийский центр IBM Systems Development Center, где отвечал за 
разработку языка баз данных, известного как Unified Database Language, UDL. 
Впоследствии принимал участие в техническом планировании и внешних проектах 
корпорации IBM для продуктов реляционных баз данных SQL/DS (анонсирован в 1981 
году для VSE и в 1983 году для VM) и DB2 (анонсирован в 1983 году для MVS). В 
мае 1983 года он покидает IBM. 
    Дейт работает в области баз данных более 25 лет. Он одним из первых 
осознал основополагающее значение первой работы по реляционной модели Э.Ф. 
Кодда (E.F. Codd). Дейт читал лекции по техническим вопросам (преимущественно 
по тематике баз данных и особенно по реляционным базам данных) во всей 
Северной Америке, а также в Европе, Австралии, Латинской Америке и на Дальнем 
Востоке. Кроме этой книги, он является автором и соавтором многих изданий: An 
Introduction to Database Systems: Volume II (1983), в котором описаны 
дополнительные аспекты данной области; Database: A Primer (1983), где базы 
данных рассматриваются с точки зрения неспециалиста; Relational Database: 
Selected Writings (1986), Relational Database Writings, 1985-1989 (1990) и 
Relational Database Writings, 1989-1991 (1992), в которых глубоко 
рассматриваются избранные вопросы реляционной технологии; серии книг по 
отдельным системам и языкам: A Guide to DB2 (4th edition, 1993), А Guide to 
SYBASE and SQL Server (1992), A Guide to SQL/DS (1988), A Guide to INGRES 
(1987), A Guide to the SQL Standard, (3th edition, 1993) и др. Его книги 
переведены на многие языки, в том числе на китайский, датский, французский, 
итальянский, японский, польский, португальский, русский, испанский и др. 
    Дейт опубликовал более 100 технических документов и статей и внес 
значительный вклад в теорию баз данных. Его работы постоянно публикуются в 
журнале Database Programming & Design, а его профессиональные семинары по 
технологии баз данных (проводимые как в Северной Америке, так и за рубежом) 
признаны непревзойденными по качеству представленного материала и ясности изложения. 

    7 


    Предисловие к шестому изданию 

    Область технологии построения систем баз данных страдает от чрезмерного 
количества информации, хотя в ее функции как раз и входит изучение обработки 
информации. Вот лишь неполный список регулярных специализированных изданий, 
выходящих в США: 
    • АСМ Transactions on Database Systems (TODS), издается ежеквартально — 
около 700 страниц в год; 
    • АСМ SIGMOD Record, издается ежеквартально — около 250 страниц в год; 
    • Материалы ежегодной конференции Annual АСМ SIGMOD International 
Conference on Management of Data— около 450 страниц в год; 
    • Материалы ежегодного симпозиума Annual АСМ S1GACT-SIGMOD Symposium on 
Principles of Database Systems— около 350 страниц в год; 
    • Материалы ежегодной конференции Annual International Conference on Very 
Large Data Bases (VLDB) — около 650 страниц в год; 
    • The VLDB Journal, издается ежеквартально — около 450 страниц в год. 
    Добавьте к этому многочисленные узкоспециализированные конференции по 
распределенным базам данных, базам данных CAD/CAM, экспертным системам баз 
данных, системам клиент/сервер, объектно-ориентированным системам и т.д. — 
предположим, восемь или десять конференций в год, приблизительно 300-350 
страниц материала... добавьте огромное количество технических отчетов 
университетов и промышленных исследовательских лабораторий... добавьте статьи, 
которые появляются время от времени в изданиях, посвященных смежной тематике 
(автоматизация офисов, искусственный интеллект и языки программирования)... 
добавьте отраслевые журналы, такие как Data Base Newsletter, Database Review, 
InfoDB, Database Programming & Design и т.д., и т.п. Все эти журналы 
составляют многие тысячи страниц в год... добавьте отраслевые выставки, такие 
как Database World и DB/Expo, каждая со своим многотомным набором 
материалов... добавьте торговые справочники и другую документацию, описывающую 
различные коммерческие продукты, которая обновляется, как минимум, каждые 18 
месяцев... добавьте многочисленные учебники, у которых в названии есть слова 
"база данных" — и вам станет ясно, что по самым скромным подсчетам каждый год 
издается около 100 тысяч страниц. Поэтому быть в курсе всего, что происходит в 
области баз данных просто невозможно. 

    8                                           Предисловие к шестому изданию 

    Учитывая все сказанное, настоящая книга, несмотря на ее большой объем, за 
который я приношу свои глубокие извинения, может быть, как гласит ее название, 
лишь введением в предмет и никоим образом не претендует на исчерпывающее его 
описание. Поскольку область разрастается стремительными темпами, то даже 
"хорошее введение" в течение короткого времени претерпевает большие изменения; 
поэтому последнее (шестое) издание настолько отличается от предыдущего, что 
его по всем параметрам можно считать повой книгой. Однако общая задача книги 
осталась прежней — создать базис для фундаментального образования в области 
основ технологии баз данных и, в частности, указать направления, по которым 
область развивается сегодня и, вероятно, будет развиваться в будущем. Книга 
задумывалась как учебник, а не как справочник, но я надеюсь, что ее вполне 
можно использовать и в качестве справочного руководства. В книге делается 
акцент на понимании материала, а не просто на алгоритмах решения каких-либо задач. 
    Необходимые условия. Предполагается, что читатель профессионально 
интересуется каким-либо аспектом обработки данных; например, он может быть 
системным аналитиком или разработчиком, прикладным программистом, студентом, 
проходящим курс по сходной тематике, или преподавателем такого курса. 
Предполагается также, что читатель 
    • имеет достаточно ясное представление о возможностях современных 
компьютерных систем, в особенности о возможностях систем работы с файлами 
(несмотря на то что в книге есть обучающее обзорное приложение для этой темы); 
    • знаком по крайней мере с одним языком программирования высокого уровня. 
    Поскольку эти требования не очень высоки, я надеюсь, что эта книга 
подойдет в качестве введения тем, кто имеет дело с использованием или 
реализацией систем баз данных либо просто желает расширить свои знания в 
области информатики. 
    Книга разделена на шесть частей. 
    I. Основные понятия. 
    II. Реляционная модель. 
    III. Проектирование базы данных. 
    IV. Защита данных. 
    V. Дополнительные аспекты. 
    VI. Объектно-ориентированные системы. Каждая часть, в свою очередь, 
делится на несколько глав. 
    • Часть I (три главы) — обширное введение в понятия системы баз данных 
вообще и реляционной системы баз данных в частности. 
    • Часть II (пять глав) — это самая большая часть книги: почти что книга в 
книге. Она представляет детальное, весьма основательное исследование 
реляционной модели, которая является теоретической основой не только 
сегодняшних реляционных продуктов, но и всей области баз данных. Одна из глав 
посвящена основным понятиям стандартного реляционного языка SQL. 
    • Часть III (четыре главы) — обсуждение общего вопроса проектирования баз данных. 

    Предисловие к шестому изданию 9 

    • Часть IV (четыре главы) — исследование различных аспектов проблемы 
защиты данных. В частности, обсуждаются понятия восстановления, параллелизма, 
безопасности и целостности базы данных. 
    • Часть V (пять глав) — описание идей реляционной модели в применении к 
различным аспектам технологии баз данных: оптимизации, распределенной 
обработке баз данных и т.д. 
    • Часть VI (четыре главы) — изложение весьма важного нового 
объектно-ориентированного подхода для систем баз данных. В частности, 
рассматривается возможность  взаимодействия  между объектно-ориентированной и 
реляционной технологиями. 
    Кроме того, в книге есть три приложения, в которых предлагаются 
разнообразные материалы об управлении файлами и физическими структурами 
хранения информации, о коммерческой реляционной системе (продукт DB2 фирмы 
IBM) и о сравнительно новой области систем, основанных на логике. 
    В каждой главе используется множество терминов, приведенных в предыдущих 
главах, а также вводится много новых понятий, поэтому в целом книга рассчитана 
на последовательное чтение. В конце книги приводится подробный предметный 
указатель, благодаря которому можно быстро найти и повторить необходимый 
материал. Каждая глава начинается введением и заканчивается заключением 
(резюме), кроме того, в большинстве глав приводятся упражнения, обычно с 
ответами. Также в большинстве глав вы найдете обширные списки литературы с 
комментариями. Рекомендуется просматривать ответы к упражнениям и комментарии 
к литературе, так как там часто дается дополнительная полезная информация по 
теме данной главы. Такая структура позволяет усваивать материал на нескольких 
уровнях: наиболее важные понятия и результаты приведены в основном тексте, 
дополнительные вопросы и более сложные аспекты исследования вынесены в 
соответствующие упражнения, ответы на них и комментарии к литературе. 

    Замечания. 
    • Синтаксис различных инструкций и команд часто приводится так же, как и в 
другой литературе, а рядом даются соответствующие пояснения. 
    • Ссылки обозначаются в тексте двойным номером в квадратных скобках. 
Например, ссылка [4.1] означает первый пункт в списке литературы к главе 4. 

    Свои вступительные замечания хотелось бы закончить следующей 
отредактированной выдержкой из предисловия Бертрана Расселла (Bertrand 
Russell) к его словарю The Bertrand Russell Dictionary of Mind, Matter and 
Morals (ed. Lester E. Denonn), Citadel Press, 1993 (публикуемой здесь с 
любезного разрешения автора): 
    Меня обвинили в привычке менять свои суждения... Но я нисколько не 
пристыжен этой привычкой. Разве мог бы физик, работающий с 1900 года, 
гордиться тем, что его суждения не изменились за последние полстолетия?.. 
Философия, которую я ценю и которой стараюсь следовать, научна в том смысле, 
что существуют точные знания, которые необходимо получить, а новые открытия 
могут выявить старые ошибки, неизбежные для любого беспристрастного разума. 
Когда бы и что бы я ни говорил — я не претендую на полную истину так, как на 
нее претендуют теологи в своем учении. Я претендую только на то, что тогда 
было благоразумно придерживаться высказанного мнения... 

    10 Предисловие к шестому изданию 

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

    Предисловие к шестому изданию 11 


    Благодарности 

    Хочу исполнить приятный долг и поблагодарить всех, кто прямо или косвенно 
принимал участие в работе над этой книгой. В первую очередь, текст был 
значительно улучшен благодаря замечаниям слушателей на проводимых последние 
несколько лет семинарах. Кроме того, положительное влияние на текст оказали 
комментарии многих друзей и рецензентов и мои дискуссии с ними. Вот далеко не 
полный их список: Наградж Алур (Nagraj Alur), Мерилин Боль (Marilyn Bohl), 
Чарли Бонтемпо (Charley Bontempo), Дэниел Куки (Daniel Cooke), Хью Дарвен 
(Hugh Darwen) (псевдоним Эндрю Варден (Andrew Warden)), Дэвид Эмбли (David 
Embley), Генри Этлингер (Henry Etiinger), Билл Гроски (Bill Grosky), Тим 
Хартли (Tim Hartley), Себастьян Холст (Sebastian Hoist), Том Джонстон (Torn 
Johnston), Вон Ким (Won Kirn), Роджер Кинг (Roger King), Эдриан Ларнер (Adrian 
Lamer), Тим Мартин (Tim Martyn), Нельсон Маттос (Nelson Mattos), Дэвид 
Мак-Говерэн (David McGoveran), Джим Панттая (Jim Panttaja), Фабиан Паскаль 
(Fabian Pascal), Эрни Розенталь (Amie Rosenthal), Шэрон Салветр (Sharon 
Salveter), Мартин Соломон (Martin Solomon), Алан Тэрп (Alan Tharp), Колин Вайт 
(Colin White), Пол Винсберг (Paul Winsberg) и Салих Юрттас (Salih Yurttas). 
Каждый из них просмотрел, по крайней мере, часть рукописи этого издания, 
предоставил технический материал или как-то иначе помог мне найти ответы на 
многие технические вопросы. Я весьма признателен им за это. Особой 
благодарности заслуживают мои друзья Хью Дарвен (Hugh Darwen) и Дэвид 
Мак-Говерэн (David McGoveran) за многочисленные плодотворные обсуждения и 
полезную корреспонденцию. Также хотелось поблагодарить мою жену Линди (Lindy) 
за помощь в оформлении книги. И наконец, я как всегда благодарен всем в 
издательстве Addison-Wesley — особенно Линн Доран Кот (Lynne Doran Cote) и 
Кэтрин Харутуниан (Katherine Harutunian) за их поощрение и поддержку во время 
работы над проектом, а также моему редактору Элидии Дэвис (Elydia Davis) за ее 
безукоризненную работу. 

    К. Дж. Дейт Хилдсбург, Калифорния 


    ЧАСТЬ I 

    Основные понятия 

    Часть I состоит из трех глав. 
    • В первой главе объясняются основные понятия: что такое база данных и 
зачем вообще нужны системы баз данных. Также в ней кратко излагаются различия 
между реляционными и другими системами баз данных. 
    • Во второй главе в общих чертах представляется архитектура систем баз 
данных — так называемая архитектура ANSI/SPARC. На основе этого материала 
строятся все последующие главы книги. 
    • В третьей главе приводится широкий обзор реляционных систем для 
основательной подготовки читателя к более детальному обсуждению этих тем в 
следующих частях книги. Здесь также дается краткое введение в стандартный 
реляционный язык SQL и рассматривается реальный пример. 

    13 


    Глава 1 

    Управление базами данных 

    1.1. Вводный пример 

    Система баз данных (database system) — это, по сути, не что иное, как 
компьютеризированная система хранения записей. Саму же базу данных можно 
рассматривать как подобие электронной картотеки, т.е. хранилище для некоторого 
набора занесенных в компьютер файлов данных (под термином "файл" 
подразумевается абстрактный набор данных, который на практике может не 
совпадать с физическим дисковым файлом). Пользователю этой системы 
предоставляется возможность выполнять множество различных операций над такими 
файлами, например: 
    • добавлять новые пустые файлы в базу данных; 
    • добавлять новые данные в существующие файлы; 
    • вести поиск данных в существующих файлах; 
    • изменять данные в существующих файлах; 
    • удалять данные из существующих файлов; 
    • удалять существующие файлы из базы данных, т.е. избавляться от их содержимого. 
    В качестве иллюстрации на рис. 1.1 приведена небольшая база данных, 
состоящая всего из одного файла под названием CELLAR (погреб). В этом файле 
хранятся данные о содержимом винного погреба. На рис. 1.2 показан пример 
операции выборки и данные этой выборки (точнее, результат операции; но когда 
речь идет о базах данных, то результат часто называют просто данными). 

    BIN	WINE			PRODUCER		YEAR	BOTTLES	READY 

    2		Chardonnay		Buena Vista		92	1		94 
    3		Chardonnay		Geyser Peak		92	5		94 
    6		Chardonnay		Stonestreet		91	4		93 
    12	Jo. Riesling	Jekel			93	1		94 
    21	Fume Blanc		Ch. St. Jean	92	4		94 
    22	Fume Blanc		Robt. Mondavi	91	2		93 
    30	Gewurztraminer	Ch. St. Jean	93	3		94 
    43	Cab. Sauvignon	Windsor		86	12		95 
    45	Cab. Sauvignon	Geyser Peak		89	12		97 
    48	Cab. Sauvignon	Robt. Mondavi	88	12		99 
    50	Pinot Noir		Gary Farrell	91	3		94 
    51	Pinot Noir		Sterrroler		88	3		95 
    52	Pinot Noir		Dehlinger		90	2		93 
    58	Merlot		Clos du Bois	89	9		95 
    64	Zinfandel		Lytton Spring	89	9		98 
    72	Zinfandel		Rafanelli		90	2		98 
    
    Рис. 1.1. База данных (файл CELLAR) 


    Замечание. Операции над базами данных и другие операции (см. рис. 1.2) в 
этой книге пишутся прописными буквами, хотя на практике часто удобней 
использовать строчные. Большинство систем допускает оба варианта. 


    14 Часть I. Основные понятия 

    На рис. 1.3 приведены примеры операций вставки (INSERT), обновления 
(UPDATE) и удаления (DELETE) для базы данных винного погреба. Эти примеры 
почти не требуют пояснений. Далее, в главах 3 и 4, будут приведены примеры 
добавления и удаления файлов. 
    Выборка: 

    SELECT WINE, BIN, PRODUCER 
    FROM  CELLAR 
    WHERE READY = 95 ;

    Результат (выданный, например, на экран дисплея):____________ 

    | WINE                   | BIN            | PRODUCER              | 
    Cab. Sauvignon           43               Windsor 
    Pinot Noir               51               Sternrnler 
    Merlot____________ 58_________ Clos du Bois_______ 

    Рис. 1.2. Пример выборки из базы данных 


    Вставка новых данных: 

    INSERT 
    INTO   CELLAR ( BIN, WINE, PRODUCER, YEAR, BOTTLES, READY ) 
    _____VALUES ( 53, 'Pinot Noir', ' Saintsbury', 92, 1, 96 ) ; 

    Обновление существующих данных: 

    UPDATE CELLAR 
    SET    BOTTLES = 4 
    WHERE BIN = 3 ; 

    Удаление существующих данных: 

    DELETE 
    FROM  CELLAR 
    WHERE BIN = 2 ; 

    Рис. 1.3. Примеры операций вставки, обновления и удаления 


    В завершение вводного раздела несколько замечаний. 
    • Во-первых, по очевидным причинам компьютерные файлы, такие как CELLAR в 
приведенном примере, часто называют таблицами, а не файлами (точнее, они 
являются реляционными таблицами, о чем речь идет далее в этой главе). 
    • Во-вторых, строки таблиц называют записями (record) файла (иногда для 
ясности их называют логическими записями в отличие от других видов записей, 
которые будут обсуждаться далее). Столбцы таблиц идентифицируют поля (field) 
этих логических записей. В дальнейшем будем придерживаться терминов "запись" и 
"поле", когда будут рассматриваться базы данных вообще, и терминов "строка" и 
"столбец" при рассмотрении реляционной системы. (Фактически, когда мы перейдем 
к более формальному рассмотрению реляционной модели в последующих частях 
книги, нам так или иначе придется использовать более формальные термины.) 
    • В-третьих, операции выборки, вставки, обновления и удаления, показанные 
на рис. 1.2 и 1.3, выполнены с помощью операторов SELECT, INSERT, UPDATE и 
DELETE специального языка баз данных, называемого SQL. SQL — это язык, который 
поддерживается в настоящее время большинством коммерческих продуктов 
разработки систем баз данных; более того, этот язык является официальным 
стандартом языка для работы с реляционными системами (об этом речь идет ниже в 
этой главе). Название SQL вначале было аббревиатурой, образованной от 
Structured Query Language (язык структурированных запросов), и его было 
принято произносить "сиквел". Сейчас, когда язык стал стандартом, SQL — это 
уже не аббревиатура, а название, которое произносится как "эс-кью-эль". В 
дальнейшем в этой книге предполагается именно такой вариант произношения. 

    Глава 1. Управление базами данных                                        15 


    1.2. Что такое система баз данных 

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

    Система управления базами данных (СУБД) 


    Рис. 1.4. Упрощенная схема системы баз данных 


    Данные 

    Системы баз данных существуют как на малых компьютерах (даже переносных 
ПК), так и на больших машинах. Нет необходимости говорить, что средства, 
предоставляемые каждой конкретной системой, в некоторой мере зависят от 
мощности и возможностей базовой машины. В частности, системы на больших 
машинах ("большие системы") в основном многопользовательские, тогда как 
системы на малых машинах ("малые системы"), как правило, однопользовательские. 
Однопользовательская система (single-user system) — это система, в которой в 
одно и то же время к базе данных может получить доступ не бо

    16 Часть I. Основные понятия 

    лее одного пользователя; многопользовательская система (multi-user 
system)— это система, в которой к базе данных могут получить доступ сразу 
несколько пользователей. Как и в схеме на рис. 1.4, мы для общности будем 
подразумевать, как правило, второй вид систем, хотя на самом деле, с точки 
зрения пользователей, между этими системами не существует большого различия. 
Основная задача большинства многопользовательских систем — позволить каждому 
отдельному пользователю работать с системой как с однопользовательской. 
Различия между многопользовательской и однопользовательской системами 
проявляются в их внутренней структуре и потому практически не видны конечному 
пользователю (это будет описано далее в книге). 
    Обычно для упрощения предполагают, что все данные в системе хранятся в 
одной базе данных; мы будем придерживаться этого предположения, поскольку оно 
существенно не влияет на все дальнейшие рассуждения. Однако на практике даже 
при использовании малых систем могут быть серьезные причины распределять 
информацию по нескольким отдельным базам данных. Эта тема еще будет затронута 
далее в этой книге. 
    В общем случае данные в базе данных (по крайней мере в больших системах) 
являются интегрированными и общими. Эти два аспекта, интеграция и разрешение 
общего доступа, представляют собой наиболее важное преимущество использования 
систем баз данных на "большом" оборудовании; и по меньшей мере один из них — 
интеграция — является преимуществом их использования на "малом" оборудовании. 
Конечно, есть множество других преимуществ (даже на "малом" оборудовании), но 
о них речь пойдет позже. Сначала следует объяснить, что понимается под 
терминами "интегрированные" и "общие". 
    • Под понятием интегрированные данные подразумевается возможность 
представить базу данных как объединение нескольких отдельных файлов данных, 
полностью или частично не перекрывающихся. Например, база данных может 
содержать файл EMPLOYEE, включающий имена сотрудников, адреса, отделы, 
зарплату и т.д., и файл ENROLLMENT, представляющий регистрацию сотрудников на 
курсах обучения (рис. 1.5). Допустим, что для контроля процесса обучения 
необходимо знать отдел каждого зачисленного на курсы студента. Совершенно 
очевидно, что нет необходимости включать такую информацию в файл ENROLLMENT, 
поскольку ее всегда можно получить путем обращения к файлу EMPLOYEE. 

    EMPLOYEE ENROLMENT 
    NAME | ADDRESS	DEPABMENT	SALARY 
    NAME | COURSE 
    
    Рис. 1.5. Файлы EMPLOYEE и ENROLLMENT 


    • Под понятием общие данные подразумевается возможность использования 
отдельных областей данных в базе данных несколькими различными пользователями, 
т.е. каждый из этих пользователей может иметь доступ к одной и той же области 
данных (причем различные пользователи могут использовать эти данные для разных 
целей). Как уже упоминалось, различные пользователи могут иметь доступ даже к 
одной и той же области данных в одно и то же время (одновременный доступ). В 
приведенном выше примере информация об отделе в файле EMPLOYEE может 
разделяться (совместно использоваться) пользователями отдела кадров и отдела 
обучения; причем, как подчеркивалось выше, эти две группы пользователей могут 
использовать такую информацию для разных целей, как обычно и происходит. 
    Одним из следствий интегрированности базы данных является то, что любой 
конкретный пользователь обычно имеет отношение к какой-то небольшой части всей 
базы данных (кроме того, эти части, связанные с различными пользователями, 
могут перекрываться многими способами). Иначе говоря, такая база данных может 
воспри

    Глава 1. Управление базами данных                                         17 

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

    Аппаратное обеспечение 

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

    Программное обеспечение 

    Между собственно физической базой данных (т.е. данными, которые в 
действительности сохранены) и пользователями системы располагается уровень 
программного обеспечения— диспетчер базы данных (database manager) или, что 
более привычно, система управления базами данных, СУБД (database management 
system (DBMS)). Все запросы пользователей на доступ к базе данных 
обрабатываются СУБД; возможности добавления файлов (или таблиц), выборки и 
обновления данных в этих файлах или таблицах также обеспечивает СУБД. Основная 
функция, выполняемая СУБД,— это предоставление пользователю базы данных 
возможности работать с ней, не вникая в детали на уровне аппаратного 
обеспечения (пользователь более отстранен от этих деталей, чем прикладной 
программист, использующий среду программирования). Иными словами, СУБД 
позволяет пользователю рассматривать базу данных как объект более высокого 
уровня по сравнению с аппаратным обеспечением, а также поддерживает выражаемые 
в терминах высокого уровня пользовательские операции (например, операции, 
которые можно выполнять с помощью языка SQL, упомянутого ранее). Далее в книге 
будут обсуждаться эта и другие функции СУБД. 
    Замечание. СУБД — наиболее важный, но не единственный программный 
компонент системы. Среди других — утилиты, средства разработки приложений, 
средства проектирования, генераторы отчетов и др. Обсуждение данного вопроса 
приводится далее в этой книге. 

    Пользователи 

    Пользователей можно разделить на три большие группы. 
    • Первая— прикладные программисты, которые отвечают за написание 
прикладных программ, использующих базу данных. Для этих целей применимы языки 
COBOL, PL/I или более современные, такие как С или Pascal. Прикладные 
программы выполняют над данными все стандартные операции: выборку существующей 
информации, вставку новой информации, удаление или обновление существующей 
информации. Все эти функции выполняются через соответствующий запрос к СУБД. 
Эти программы могут быть простыми программами пакетной обработки или 
оперативными приложениями, функция которых — поддержка работы конечного 
пользователя (см. ниже), имеющего непосредственный оперативный доступ к базе 
данных через рабочую станцию или терминал. Большинство современных приложений 
относится к оперативным. 

    18                                                 Часть I. Основные понятия 

    • Вторая — конечные пользователи, которые работают с системами баз данных 
непосредственно через рабочую станцию или терминал. Конечный пользователь 
может получить доступ к базе данных, используя одно из оперативных приложений, 
упомянутых выше, или же воспользоваться интегрированным интерфейсом 
программного обеспечения самой системы баз данных. Такой интерфейс также 
поддерживается оперативным приложением, но это приложение не создается 
пользователем, оно является встроенным в систему баз данных. В большинстве 
систем есть, по крайней мере, одно такое встроенное приложение, а именно: 
процессор языка запросов, который позволяет пользователю указывать команды или 
выражения высокого уровня (такие как SELECT или INSERT) для данной СУБД. Язык 
SQL, упомянутый выше, — типичный пример языка запросов для базы данных. 

    Замечание. Общепринятый термин "язык запросов" не совсем точно отражает 
рассматриваемое понятие, поскольку слово "запрос" подразумевает лишь выборку, 
в то время как с помощью этого языка выполняются также операции обновления, 
вставки и удаления (а возможно, и многие другие). 

    Кроме языка запросов, в большинстве систем также предоставляются 
дополнительные встроенные интерфейсы, в которых пользователь в явном виде не 
использует команд, таких как SELECT. Для работы с базой данной пользователь, 
например, выбирает необходимые команды меню или заполняет поля в формах. Такие 
интерфейсы, основанные на меню и формах, облегчают работу с базами данных тем, 
кто не имеет опыта работы с информационными технологиями (ИТ; часто 
употребляется также сокращение ИС — информационные системы, эти понятия 
практически эквивалентны). Командный интерфейс, т.е. язык запросов, напротив, 
требует некоторого опыта работы с ИТ (возможно, не очень большого). Однако 
командный интерфейс обычно более гибок, чем основанный на меню и формах; кроме 
того, в языках запросов обычно есть определенные функции, которые не 
поддерживаются интерфейсами, основанными на меню и формах. 
    • Третья группа (не показана на рис. 1.4) — администраторы базы данных, 
или АБД. Функции администраторов мы будем обсуждать далее в этой и следующей главе. 
    На этом закончим предварительное описание основных аспектов систем баз 
данных и приступим к более детальному изучению идей. 

    1.3. Что такое база данных 

    Постоянные данные 

    Обычно данные в базе данных называют "постоянными" (хотя на самом деле они 
могут недолго оставаться таковыми!). Под словом "постоянные" подразумеваются 
данные, которые отличаются от других, более изменчивых данных, таких как 
промежуточные результаты, входные и выходные данные, управляющие операторы, 
рабочие очереди, программные управляющие блоки и вообще все транзитные данные. 
Давайте кратко уточним, что мы понимаем под понятиями "входные данные" и 
"выходные данные": 
    • Входные данные — это информация, передаваемая системе (обычно с 
терминала или рабочей станции). Такая информация может стать причиной 
изменений в постоянных данных (она может стать частью постоянных данных), но 
не является частью базы данных как таковой. 
    • Точно так же выходные данные — это сообщения и результаты, выдаваемые 
системой (обычно выдаются на печать или отображаются на экране). И опять же 
эту информацию можно брать из постоянных данных, но ее нельзя рассматривать 
как часть базы данных. 
    Конечно, различие между постоянными и транзитными данными нельзя назвать 
четким — оно в некоторой мере зависит от контекста (например, от того, как 
используются данные). Однако предполагая, что это различие доступно по крайней 
мере на интуитивном уровне, можно дать более точное определение термина "база данных": 

    Глава 1. Управление базами данных 19 

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

    Объекты и отношения 

    Рассмотрим пример промышленной компании более детально. Обычно такому 
предприятию требуется записывать информацию об имеющихся проектах, деталях, 
поставщиках деталей, складах, на которых хранятся детали, служащих, работающих 
над проектами, и т.д. Проекты, детали, поставщики и т.д. составляют основные 
объекты, о которых компании необходимо хранить информацию (под термином 
"объект" понимают все, что может быть представлено в базе данных). 
    Важно понимать, что кроме самих основных объектов существуют еще и 
отношения между ними, которые связывают их вместе. На рис. 1.6 отношения 
представлены ромбами с соединительными линиями. Например, существует отношение 
SP между поставщиками и деталями: каждый поставщик поставляет определенные 
детали и, наоборот, каждая деталь поставляется определенными поставщиками 
(или, точнее, каждый поставщик поставляет определенные виды деталей и каждый 
вид деталей поставляется определенными поставщиками). Аналогично: детали 
используются в проектах, а для проектов требуются детали (отношение PJ); 
детали хранятся на складах, а склады хранят детали (отношение WP) и т.д. 
Обратите внимание, что эти отношения двусторонние, т.е. их можно рассматривать 
в обоих направлениях. Например, используя отношение SP между поставщиками и 
деталями можно ответить на следующие вопросы: 
    • Задан поставщик, найти детали, поставляемые этим поставщиком. 
    • Задана деталь, найти поставщиков, поставляющих такую деталь. 
    Важное значение имеет то, что это отношение, как и другие отношения, 
показанные на рис. 1.6, подобно основным объектам является частью данных. 
Поэтому вместе с основными объектами отношения тоже должны быть представлены в 
базе данных. Далее в книге рассматриваются способы, которыми это можно сделать. 

    20                                                 Часть I. Основные понятия 

    Схема, представленная на рис. 1.6, называется (по очевидным причинам) 
схемой объект/отношение (также ее называют диаграммой объект/отношение). Такие 
схемы более подробно рассматриваются далее в этой книге. 

    Рис. 1.6, Пример схемы объект/отношение 


    Отметим еще несколько важных моментов, показанных на схеме. 
    1. Хотя большинство отношений в схеме связывают два типа объектов (т.е. 
они являются бинарными), это вовсе не означает, что все отношения должны быть 
бинарными. В примере есть одно отношение (SPJ), связывающее три типа объектов 
(поставщики, детали и проекты) — тройное отношение. Интерпретация этого 
отношения такова: определенные поставщики поставляют определенные детали для 
определенных проектов. Обратите внимание, что это тройное отношение вообще не 
эквивалентно комбинации трех бинарных отношений: "поставщики поставляют 
детали", "детали используются в проектах" и "проекты снабжаются поставщиками". 
Например, выражение 
    а) "Смит поставляет гаечные ключи для Манхэттенского проекта" говорит нам 
больше, чем следующие три: 
    б) "Смит поставляет гаечные ключи"; 
    в) "Гаечные ключи используются в Манхэттенском проекте"; 
    г) "Манхэтеннский проект снабжается Смитом". Мы не можем наверняка 
утверждать (а), зная только (б), (в) и (г). Точнее, если мы знаем (б), (в) и 
(г), то мы можем утверждать, что Смит поставляет гаечные ключи для какого-то 
проекта (скажем, проекта J), что какой-то поставщик (скажем поставщик S) 
поставляет гаечные ключи для Манхэттенского проекта и что Смит поставляет 
какую-то деталь (скажем, деталь Р) для Манхэттенского проекта, но мы не можем 
точно утверждать, что S — это Смит, Р — это гаечные ключи, а J — Манхэттенский 
проект. Такие ложные выводы называют ловушкой при соединении выражений. 
    2. На схеме есть одно отношение (РР), которое связывает один тип объектов 
(детали). Это отношение означает, что некоторые детали содержат другие 
компоненты (так называемое отношение спецификации материалов). Например, винт 
— это компонент шарнира, который тоже рассматривается как деталь и может быть, 
в свою очередь, компонентом какой-либо более сложной детали, например колпака. 
Обратите внимание, что это отношение тоже бинарное, просто оно связывает два 
совпадающих типа объектов — детали. 

    Глава 1. Управление базами данных 21 

    3. Вообще говоря, в наборе типов объектов может быть любое количество 
отношений. На схеме есть два отношения между проектами и служащими: одно (EJ) 
представляет тот факт, что служащие заняты в проектах, а другое (MJ) — что 
служащие управляют проектами. 
    Обратите особое внимание на то, что отношение тоже можно в некотором 
смысле считать объектом. Если определить объект как "нечто, о чем необходимо 
записать информацию", то отношение вполне подходит под такое определение. 
Например, отношение "деталь Р4 хранится на складе W8" — это объект, о котором 
нам может понадобиться записать информацию, например соответствующее 
количество деталей. Более того, существуют некоторые преимущества (их описание 
выходит за рамки этой главы) в том, что мы не делаем излишних различий между 
объектами и отношениями. Поэтому в данной книге отношения будут 
рассматриваться как специальный тип объектов. 

    Свойства 

    Как мы только что отметили, объект — это то, о чем нам необходимо записать 
информацию. Иначе говоря, объекты (а значит, и отношения) имеют некоторые 
свойства. Например, у поставщиков есть место расположения, у деталей — вес, у 
проектов — порядок очередности и т.д. Эти свойства тоже необходимо сохранять в 
базе данных. Например, в базе данных может быть тип записи S, представляющий 
тип объектов "поставщики", а в этом типе записи — тип поля CITY (город), 
представляющий свойство "место расположения". 
    Свойства по своей внутренней структуре также могут быть любой степени 
сложности. Например, свойство "место расположения поставщика" относительно 
простое: оно состоит только из названия города и может быть описано как 
простая символьная строка. Свойство объекта "план", напротив, имеет довольно 
сложную структуру: оно может состоять из графика с дополнительным текстом 
описания. Большинство современных продуктов баз данных плохо развито с точки 
зрения описания сложных свойств, таких как графика или текст. Более подробно 
данная тема обсуждается далее в этой книге, а пока в основном будем 
предполагать, что все свойства "простые" и их можно представить простыми 
типами данных: число, строка, дата, время и т.п. 

    1.4. Почему база данных 

    Какие преимущества получает пользователь при работе с системой баз данных? 
В некоторой степени ответ зависит от того, о какой системе идет речь — 
однопользовательской или многопользовательской (точнее, о многочисленных 
дополнительных преимуществах многопользовательской системы). Рассмотрим 
сначала случай однопользовательской системы. 
    Вернемся к нашей базе данных винного погреба (см. рис. 1.1), ее можно 
рассматривать как типичную однопользовательскую базу данных. Эта база не 
настолько велика и сложна, чтобы на ее примере сразу увидеть все преимущества. 
Но представьте себе такую базу данных для большого ресторана, имеющего запас, 
возможно, из тысяч бутылок, который постоянно обновляется; или, скажем, для 
винного магазина, опять же с большим запасом, который находится в постоянном 
обороте. (Хотя такие базы данных больше, но они тоже однопользовательские.) 
Преимущества системы баз данных по сравнению с традиционным бумажным методом 
содержания записей для этих примеров весьма очевидны. Отметим некоторые из них. 
    • Компактность. Нет необходимости в многотомных бумажных картотеках. 
    • Скорость. Компьютер может вести поиск и изменять данные гораздо быстрее 
человека. В частности, на специальные вопросы, возникающие в процессе работы 
(например: "Какого вина у нас сейчас больше — Zinfandel или Pinot Noir?"), 
можно получить ответ быстро, не затрачивая времени на визуальный поиск. 

    22                                                 Часть I. Основные понятия 

    • Низкие трудозатраты. Нет необходимости в утомительной ручной работе над 
картотекой. Механическую работу машины всегда выполняют лучше. 
    • Применимость. Точная, свежая информация в любой момент под рукой. 
    Эти преимущества приобретают еще большее значение в многопользовательской 
среде, где база данных, вероятно, больше и сложнее однопользовательской. Кроме 
того, многопользовательская среда имеет дополнительное преимущество: система 
баз данных предоставляет предприятию централизованное управление его данными 
(а такое управление является наиболее ценным свойством базы данных). 
Представьте себе противоположную ситуацию — предприятие, не использующее 
систему баз данных: для каждого отдельного приложения создаются свои файлы, 
чаще всего размещаемые на отдельных магнитных лентах или дисках, в результате 
чего данные оказываются разрозненными. Систематически управлять такими данными 
очень сложно. 

    Администрирование данных и администрирование баз данных 

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

    Преимущества централизованного подхода в управлении данными 

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

    Глава 1, Управление базами данных                                       23 

    объединить с устранением избыточности (одинаковой информации) при условии, 
если администратор данных знает о том, какие данные нужны для каждого 
приложения, т.е. если на предприятии осуществляется необходимое общее управление. 
    В данном случае мы не имеем в виду, что избыточность данных может или 
должна быть полностью устранена. Иногда веские практические или технические 
причины требуют наличия нескольких копий хранимых данных. Однако такая 
избыточность должна строго контролироваться, т.е. учитываться в СУБД; также 
должна быть предусмотрена возможность "множественного обновления" (см. 
следующий пункт). 
    • Возможность устранения (до некоторой степени) противоречивости. 
    В действительности это следствие предыдущего пункта. Возьмем пример из 
жизни— пусть служащий ЕЗ, работающий в отделе D8, представлен двумя различными 
записями в базе данных. Предположим, что в СУБД не учтено это раздвоение (т.е. 
избыточность не контролируется). Тогда рано или поздно обязательно возникнет 
ситуация, при которой эти две записи перестанут согласовываться, а именно: 
одна из них будет изменена, а вторая — нет. В этом случае база данных станет 
противоречивой. Ясно, что противоречивая база данных может выдавать 
пользователю неправильную, противоречивую информацию. 
    Также очевидно, что если какой-либо факт представлен одной записью (т.е. 
при отсутствии избыточности), то противоречий возникнуть не может. 
Противоречий можно также избежать, если не удалять избыточность, а 
контролировать ее (предусмотрев это соответствующим образом в СУБД), тогда, с 
точки зрения пользователя, база данных никогда не будет противоречивой. Это 
обеспечивается тем, что если обновление вносится в одну запись, то оно 
автоматически должно распространяться на все остальные. Этот процесс 
называется множественным обновлением, где под обновлением понимаются любые 
операции вставки, удаления или обновления. Обратите внимание, что далеко не 
все сегодняшние коммерческие продукты поддерживают множественное обновление в 
этом понимании; т.е. большинство сегодняшних продуктов не поддерживает 
контроль избыточности, за исключением некоторых специальных ситуаций. 
    • Возможность общего доступа к данным. 
    Этот вопрос уже обсуждался в данной главе, но для полноты затронем его еще 
раз. Общий доступ к данным означает возможность доступа к ним нескольких 
существующих приложений базы данных и разработки новых приложений для работы с 
этими же данными. Другими словами, новые приложения могут получить доступ к 
тем же данным, и при этом нет необходимости в создании новых данных. 
    • Возможность соблюдения стандартов. 
    Благодаря централизованному управлению АБД (под управлением администратора 
данных) может обеспечивать представление данных в определенных стандартах. 
Стандарты могут быть корпоративными, установочными, ведомственными, 
промышленными, национальными и интернациональными. Стандартизация 
представления данных наиболее важна для обмена и перенесения данных между 
системами. Кроме того, стандарты идентификации данных и документации важны и 
для совместного использования данных, и для их понимания. 
    • Возможность введения ограничений для обеспечения безопасности. 
    Благодаря полному контролю над базой данных АБД может обеспечить доступ к 
базе данных через определенные каналы, а следовательно, может определить 
правила безопасности, которые будут проверяться при попытке доступа к уязвимым 
данным (опять же под руководством администратора данных). Для разных типов 
доступа (выборки, вставки, удаления и т.д.) и разных частей базы данных можно 
установить различные правила. Однако заметьте, что при отсутствии таких правил 
безопасность данных подвергается большему риску, чем в обычной (разрозненной) 
файловой системе; т.е. централизованная природа системы баз данных в некотором 
смысле требует наличия хорошей системы безопасности. 

    24                                                 Часть I. Основные понятия 

    • Возможность обеспечения целостности данных. 
    Задача целостности заключается в обеспечении правильности и точности 
данных в базе данных. Противоречие между двумя записями, представляющими один 
"факт", является примером недостатка целостности (см. обсуждение этого вопроса 
выше); конечно, эта проблема может возникнуть лишь при наличии избыточности в 
хранимых данных. Но даже если избыточность отсутствует, база данных может 
содержать неправильную информацию. Например, сотрудник может иметь в 
соответствии с базой данных 400 рабочих часов вместо 40 или принадлежать к 
несуществующему отделу D9. Централизованное управление базой данных позволяет 
избежать подобных проблем — насколько их вообще возможно избежать. Для этого 
администратор данных определяет (а АБД реализует) правила целостности, которые 
применяются при любой попытке проделать какую-либо операцию обновления. (Как и 
ранее, термин "обновление" используется для общего обозначения операций 
вставки, удаления и обновления.) 
    Отметим также, что интеграция данных для многопользовательских систем баз 
данных даже более важна, чем для "частных файлов", как раз потому, что к такой 
базе данных есть общий доступ. При отсутствии должного контроля один 
пользователь может некорректно обновить данные, и от этого пострадают другие 
ни в чем не повинные пользователи. Следует также сказать, что в большинстве 
продуктов баз данных поддержка контроля целостности развита слабо, хотя в 
настоящее время в этом направлении наблюдаются некоторые улучшения. 
    • Возможность сбалансировать противоречивые требования. 
    Зная общие требования всего предприятия (а не требования каждого 
отдельного пользователя), АБД (конечно, под управлением администратора данных) 
может структурировать базу данных таким образом, чтобы обслуживание в целом 
для предприятия было наилучшим. Например, он может выбрать такое представление 
данных в памяти, которое обеспечит быстрый доступ к файлам для наиболее важных 
приложений (возможно, с потерями производительности для некоторых других приложений). 
    Перечисленные выше преимущества достаточно очевидны. Однако есть еще одно 
преимущество, которое необходимо добавить к этому списку и которое не так 
очевидно (хотя косвенно и охватывает все преимущества). Речь идет об 
обеспечении независимости данных. (Строго говоря, это скорее цель, а не 
преимущество.) Концепция независимости настолько важна, что ей посвящен целый 
раздел, представленный ниже. 

    1.5. Независимость данных 

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

    Глава 1. Управление базами данных                                       25 

    не изменив самого приложения (возможно, радикально). Например, невозможно 
заменить индексированный файл в нашем примере на котированный файл без 
внесения значительных изменений в приложение. Более того, изменению в таком 
случае подлежат те части приложения, которые взаимодействуют с программами 
управления данными, и трудности, возникающие при этом, не имеют никакого 
отношения к проблеме, для решения которой было написано приложение; это 
трудности, вызванные структурой интерфейса управления данными. 
    Однако для системы баз данных крайне нежелательно, чтобы приложение 
зависело от данных, и тому есть, по меньшей мере, две причины. 
    1. Для разных приложений требуются разные представления одних и тех же 
данных. Например, предположим, что до перехода к интегрированной базе данных 
предприятие имеет два приложения, А и В. Каждое из них имеет свой файл, 
содержащий поле "баланс заказчика". Предположим также, что приложение А 
записывает значение этого поля в десятичном формате, а приложение В — в 
двоичном формате. Эти два файла все еще можно интегрировать, а существующую 
избыточность устранить, если в СУБД есть возможность выполнить все необходимые 
преобразования между форматом представления данных (формат представления может 
быть десятичным, двоичным или любым другим) и форматом, необходимым для 
приложения. Например, если принято решение сохранять значения поля в 
десятичном формате, то каждое обращение к приложению В потребует 
преобразования значений в двоичный формат или из двоичного формата. 
    Это довольно простой пример тех различий, которые могут существовать в 
системе баз данных между формой представления данных в приложении и формой их 
физического хранения. Многие другие возможные различия мы рассмотрим позднее. 
    2. Администратор базы данных должен иметь возможность при изменившихся 
требованиях изменять структуру хранения или метод доступа к данным без 
изменения существующих приложений. Например, к базе данных могут быть 
добавлены новые виды данных; на предприятии могут быть приняты новые 
стандарты; могут быть изменены приоритеты приложений (а следовательно, и 
связанные с ними требования к производительности); могут появиться новые типы 
запоминающих устройств и т.д. Если приложения зависят от данных, то 
перечисленные изменения потребуют изменения программ и усилий программистов, 
которые можно было бы направить на создание новых приложений. До сих пор эта 
проблема не редкость; и сегодня случается, что 25% рабочего времени 
программистов (или даже больше) тратится на подобную работу, а это, конечно, 
бесполезная трата дефицитных и ценных ресурсов. 
    Таким образом, обеспечение независимости данных — основная цель систем баз 
данных. Независимость данных можно определить как иммунитет приложений к 
изменениям в структуре хранения данных и в методах доступа к данным, а это 
означает, что рассматриваемые приложения не зависят от любой конкретной 
структуры хранения и конкретных методов доступа. Далее в книге будет описана 
архитектура систем баз данных, обеспечивающая основу для достижения этой цели. 
Но прежде рассмотрим более детально некоторые примеры тех изменений, в 
выполнении которых может возникнуть необходимость у АБД и к которым, 
следовательно, должны быть невосприимчивы приложения. 
    Начнем с определения трех новых терминов: хранимое поле, хранимая запись и 
хранимый файл (рис. 1.7). 
    • Хранимое поле — это наименьшая единица хранимых данных. Вообще, база 
данных содержит много экземпляров каждого из нескольких типов хранимых полей. 
Например, база данных, содержащая информацию о деталях, может содержать тип 
хранимых полей с именем "номер детали", и для каждого вида детали (винт, 
шарнир, колпак и т.д.) предусмотрен один экземпляр этого хранимого поля. 

    26                                                 Часть I. Основные понятия 

    Хранимая запись — это набор связанных хранимых полей. И снова мы различаем 
тип и экземпляр. В данном случае экземпляр хранимой записи состоит из группы 
связанных экземпляров хранимых полей. Например, экземпляр хранимой записи в 
базе данных деталей состоит из экземпляров каждого из хранимых полей: номер 
детали, название детали, цвет детали и вес детали. Мы говорим, что база данных 
содержит множество экземпляров хранимой записи типа "деталь" (один экземпляр 
для каждой определенной детали). 

    Рис. 1.7. Хранимые поля, записи и файлы 

    Заметим, что слова "тип" и "экземпляр" часто опускают, а что имеется в 
виду, следует выяснять по контексту. Хотя эта практика иногда может привести к 
недоразумению, она удобна и мы по ходу изложения будем время от времени 
прибегать к ней. 
    • И наконец, хранимый файл — это набор всех экземпляров хранимых записей 
одного типа. 
    Замечание. Здесь умышленно не рассматривается предположение, что в 
хранимом файле может быть несколько типов хранимых записей. Это еще одно 
упрощающее предположение, которое не окажет существенного влияния на 
последующие рассуждения. 
    В системах, отличных от баз данных, обычно логическая запись совпадает с 
соответствующей хранимой записью. Как было показано выше, в базах данных это 
вовсе не обязательно, так как АБД может понадобиться внести изменения в 
структуру хранения данных (т.е. в хранимые поля, записи, файлы), в то время 
как логическая структура останется неизменной. Например, упомянутое выше поле 
"вес детали" может быть сохра

    Глава 1. Управление базами данных 27 

    нено в двоичном формате для экономии памяти, тогда как какое-либо 
приложение, написанное на языке COBOL, может рассматривать это поле как 
символьную строку. А позже может понадобиться изменить форму с двоичной на 
десятичную, позволяя приложению по-прежнему рассматривать поле в символьном формате. 
    Как установлено ранее, разница, подобная этой, требующая преобразования 
данных определенного поля при каждом обращении к ним, сравнительно 
незначительна; однако в принципе разница между тем, что "видит" приложение и 
что сохраняется на самом деле, может быть довольно значительна. Развивая это 
замечание, перечислим аспекты структуры хранения баз данных, которые можно 
подвергнуть изменениям. Читателю предлагается подумать над тем, что должна 
сделать СУБД для защиты приложения от таких изменений (и всегда ли такую 
защиту можно обеспечить). 
    • Представление числовых данных. 
    Числовое поле может храниться во внутренней арифметической форме 
(например, в упакованном десятичном формате) или в виде символьной строки. В 
каждом случае АБД должен определить подходящее основание системы счисления 
(например, он может выбрать двоичную или десятичную систему счисления), 
масштаб (число с фиксированной или плавающей запятой), тип (действительное 
число или комплексное) и точность (количество цифр). Каждый из этих параметров 
может быть изменен для повышения производительности, при введении нового 
стандарта или по другим причинам. 
    • Представление символьных данных. 
    Поле в форме символьной строки может сохраняться с помощью нескольких 
разных наборов кодирования символов (например, таких как ASCII, EBCDIC). 
    • Единицы для числовых данных. 
    Единицы числовых полей могут быть изменены, например, с дюймов на 
сантиметры, если приложение связано с процессами измерения. 
    • Кодирование данных. 
    В некоторых ситуациях может понадобиться представлять данные кодированными 
значениями. Например, поле "цвет детали", которое представлено в приложении 
как символьная строка ("Красный", "Голубой", "Зеленый"), может храниться в 
виде десятичной цифры в соответствии с таблицей перекодировки: 1 = "Красный", 
2 = "Голубой" и т.д. 
    • Материализация данных. 
    Обычно логическое поле, используемое приложением, соответствует некоторому 
определенному хранимому полю (хотя, как мы видели ранее, могут существовать 
различия в типе данных, единицах и т.д.). В этом случае процесс 
материализации, т.е. построение экземпляра логического поля из 
соответствующего экземпляра хранимого поля и передача его приложению, можно 
назвать прямым. Однако иногда логическое поле может не иметь соответствующего 
эквивалентного хранимого поля, а его значение "материализуется" с помощью 
некоторых вычислений, выполняемых над набором из нескольких экземпляров 
хранимых полей. Например, значения логического поля "общее количество" можно 
определить путем суммирования нескольких хранимых значений поля "количество". 
"Общее количество" — это пример виртуального поля, процесс определения его 
значения называют непрямым. Однако обратите внимание, что пользователь может 
отличить реальное поле от виртуального, так как экземпляр виртуального поля 
нельзя вставить или изменить (напрямую). 
    • Структура хранимых записей. 
    Два существующих типа хранимых записей можно объединить в один. Например, 
типы хранимых записей 

    |Номер детали 1   Цвет детали     ^  Г Номер детали      Вес детали   | 

    28                                                 Часть I. Основные понятия 

    можно представить в форме 

    ( Номер детали   \ Цвет детали    ( Вес детали 

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

    | Номер детали   | Цвет детали    [ Вес деталиj можно разбить на два 
    ]  Номер детали      Цвет детали     и  [  Номер деталиj    Вес детали 

    Такое разделение позволяет редко используемые части исходной записи 
поместить, например, на более медленное устройство. При этом неявно 
предполагается, что логическая запись приложения может содержать поля из 
нескольких отдельных хранимых записей, т.е. логическая запись является 
расширением любой из этих хранимых записей. 
    • Структура хранимых файлов. 
    Хранимый файл может физически храниться в памяти разными способами. 
Например, его можно разместить на одном томе памяти (например, на одном диске) 
или распределить на нескольких томах разных типов устройств; он может быть 
физически упорядочен в соответствии со значениями некоторого хранимого поля; 
    он может быть упорядочен какими-либо другими способами, например с помощью 
одного или нескольких индексов или встроенных цепочек указателей; к нему может 
быть обеспечен доступ методом хеш-адресации; хранимые записи могут быть 
физически объединены в блоки (несколько в одной физической записи). Но ни один 
из этих факторов не должен влиять каким-либо образом на приложение (за 
исключением, конечно, эффективности приложения). 
    Этим ограничиваются аспекты структуры хранения, которые можно подвергнуть 
изменениям. Здесь среди прочего предполагается, что база данных может 
развиваться, не оказывая влияния на приложения. В действительности возможность 
развития базы данных без логического ущерба для существующих приложений 
является единственным наиболее важным мотивом обеспечения независимости 
данных. Например, можно было бы расширить существующий тип хранимой записи 
добавлением новых хранимых полей, представляющих обычно дополнительную 
информацию о некоторых существующих типах объектов (например, поле "цена" 
можно добавить к хранимой записи "деталь"). Такие новые поля будут "невидимы" 
для существующих приложений. Точно так же можно добавить новые типы хранимых 
записей (а следовательно, новые хранимые файлы), не изменяя существующих 
приложений; такие записи обычно представляют собой новые типы объектов 
(например, тип записи "поставщик" можно добавить к базе данных "детали"). 
Такие добавления также будут незаметны для приложений. 
    В заключение заметим, что независимость данных — понятие относительное, 
различные системы обеспечивают ее в разной мере или не обеспечивают вообще. В 
целом современные системы более развиты в этом направлении, чем старые, 
однако, как будет показано в последующих главах, и они имеют свои недостатки. 

    1.6. Реляционные и другие системы 

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

    Глава 1. Управление базами данных                                       29 

    лось (возможно, косвенно) в этом направлении. На самом деле, реляционный 
подход представляет собой основную тенденцию сегодняшнего рынка, и реляционная 
модель— единственная наиболее существенная разработка в истории развития баз 
данных. По этим причинам, а также учитывая, что реляционная модель основана на 
некоторых математических аспектах и, следовательно, идеально подходит для 
изложения концепций и принципов систем баз данных, основное внимание в этой 
книге уделяется реляционным системам и реляционному подходу. 
    Что мы подразумеваем под реляционной системой? К сожалению, на этом этапе 
обсуждения невозможно дать полный ответ на этот вопрос; однако можно (и 
нужно!) дать грубый приблизительный ответ, который в дальнейшем будет 
существенно уточнен. Итак, вкратце, реляционная система — это система, 
основанная на следующих принципах: 
    1) данные для пользователя передаются в виде таблиц (и никак иначе); 
    2) пользователю предоставляются операторы (например, для выборки данных), 
генерирующие новые таблицы из старых. Например, в системе будет оператор 
получения подмножества строк в данной таблице и оператор получения 
подмножества столбцов — а подмножество строк и подмножество столбцов, конечно, 
можно рассматривать как новые таблицы. 
    Причина, по которой такие системы называют реляционными, в том, что 
английский термин "relation" (отношение), по существу, просто математическое 
название для таблицы. Поэтому на практике в большинстве случаев термины 
"отношение" и "таблица" можно считать синонимами. Обсуждение этого вопроса 
будет продолжено далее в этой книге. 
    Как уже отмечалось, в дальнейшем будет дано более точное определение, а 
сейчас мы будем использовать данное. Рис. 1.8 иллюстрирует вышесказанное. 
Данные на рис. 1.8,а состоят из одной таблицы под названием CELLAR (на самом 
деле это версия таблицы CELLAR с рис. 1.1, уменьшенная для того, чтобы с ней 
легче было работать). Два примера выборки — один с получением подмножества 
строк и второй с получением подмножества столбцов — показаны на рис. 1.8,6. 
    а) Дана таблица: CELLAR 

    WINE	YEAR	BOTTLES 

    Chardonnay Fume Blanc Pinet Noir Zinfandel	91 91 88 89	4 2 3 9 

    б) Примеры применения операторов:1. Подмножество строк: Результат: SELECT 
WINE, YEAR, BOTTLES FRCM CELLAR WHERE YEAR > 90 ;2. Подмножество столбцов: 
Результат: SELECT WINE, BOTTLES FRCM CELLAR ; 

    WINE	YEAR	BOTTLES 

    Chardonnay Fume Blanc	91 91	4 2 

    WINE	BOTTLES 

    Chardonnay Fume Blanc Pinet Noir Zinfandel	4 2 3 9 
    

    Рис. 1.8. Структура данных и операторы в реляционной системе (примеры) 


    Замечание. Эти выборки выполнены с помощью оператора SELECT языка SQL, 
упомянутого выше в этой главе. 

    30 Часть I. Основные понятия 

    Теперь можно различать реляционные и нереляционные системы по следующим 
признакам. Как уже отмечалось, пользователь реляционной системы видит данные, 
представленные в таблицах и никак иначе. Пользователь нереляционной системы, 
напротив, видит данные, представленные в других структурах вместо таблиц 
реляционной системы или наряду с ними. И для работы с этими другими 
структурами применяются другие операции. Например, в иерархической системе 
данные представлены пользователю в форме набора древовидных структур 
(иерархий), а среди операций работы с иерархическими структурами есть операции 
перемещения по иерархическим путями вниз и вверх по деревьям. 
    Рассмотрим этот вопрос немного подробнее. На практике системы баз данных 
могут быть легко распределены по категориям в соответствии со структурами 
данных и операторами, которые они предоставляют пользователю. Прежде всего, 
старые (дореляционные) системы можно разделить на три большие категории, а 
именно: системы инвертированных списков, иерархические и сетевые. Приведем 
примеры коммерческих продуктов, которые можно отнести к перечисленным категориям. 
    Системы инвертированных списков: CA-DATACOM/DB компании Computer 
Associates International Inc. (ранее был известен как DATACOM/DB компании 
Applied Data Research). 
    Иерархические системы: IMS корпорации IBM. 
    Сетевые: CA-IDMS/DB компании Computer Associates International Inc. (ранее 
был известен как IDMS компании Cullinet Software Inc.). 
    Первые реляционные продукты начали появляться в конце 1970-х— начале 
1980-х годов. Во время написания этой книги (1993 год) существовало более 100, 
а возможно более 200 коммерческих реляционных продуктов, предназначенных для 
работы с любым программным и аппаратным обеспечением, которое можно себе 
представить. Среди них DB2 корпорации IBM; Rdb/VMS корпорации Digital 
Equipment; ORACLE корпорации Oracle; INGRES компании Ingres Division of The 
ASK Group Inc.; SYBASE компании Sybase Inc. и многие другие. 
    Несколько позже исследования велись в направлении так называемых 
"постреляционных" систем, некоторые из них основаны на совместимых снизу вверх 
расширениях оригинального реляционного подхода, другие представляют собой 
попытки сделать что-то совершенно отличное. Мы перечислим лишь некоторые 
наиболее поздние из них, дав их названия и даже не пытаясь выяснить, что эти 
названия означают или чего хотели достичь исследователи. 
    • Дедуктивные СУБД. 
    • Экспертные СУБД. 
    • Расширяемые СУБД. 
    • Объектно-ориентированные СУБД. 
    • Семантические СУБД. 
    • Универсальные реляционные СУБД. 
    Начали появляться отдельные продукты, которые можно отнести к категории 
объектно-ориентированных систем; сюда можно отнести GemStone корпорации 
Servio, ObjectStore корпорации Object Design и OpenODB корпорации Hewlett-Packard. 
    В последующих частях книги мы рассмотрим некоторые из этих новых 
направлений, особенно объектно-ориентированные системы. 

    1.7. Резюме 

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

    Глава 1. Управление базами данных 31 

    сохраняемые в базе данных), аппаратное обеспечение, программное 
обеспечение (называемое системой управления базами данных, или СУБД), а также 
пользователей (что наиболее важно). Пользователи, в свою очередь, 
подразделяются на прикладных программистов, конечных пользователей, а также на 
администраторов баз данных, или АБД. Последние отвечают за администрирование 
базы данных и системы баз данных в соответствии с требованиями, 
устанавливаемыми администратором данных. 
    Базы данных являются интегрированными и (чаще всего) совместно 
используемыми. Они применяются для хранения постоянных данных. Можно считать 
(хотя это и не совсем точно), что эти данные представляют собой объекты и 
отношения между этими объектами, а сами отношения — это просто специальный вид объектов. 
    Система баз данных имеет ряд преимуществ, наиболее важным из которых 
является независимость данных (иммунитет приложений к изменениям способа 
хранения данных и метода доступа). 
    И наконец, система баз данных может быть основана на нескольких различных 
подходах, среди которых есть реляционный подход. И с экономической, и с 
теоретической точки зрения можно сказать, что реляционный подход наиболее 
важный (и это положение дел, по-видимому, не изменится в обозримом будущем). В 
реляционных системах данные рассматриваются пользователями как таблицы, а 
операторы, доступные каждому пользователю для работы с данными, — как 
операторы обработки таблиц. Мы рассмотрели несколько примеров использования 
языка SQL — стандартного языка для работы с реляционными системами. Эта книга 
будет в значительной мере базироваться на реляционном подходе, а точнее, 
непосредственно на SQL. 

    Упражнения 

    1.1. Дайте определения следующим терминам: бинарное отношение; интерфейс, 
основанный на меню; командный интерфейс; многопользовательская система; 
одновременный доступ; оперативное приложение; администрирование данных; 
постоянные данные; база данных; свойство; система баз данных; язык запросов; 
независимость данных; избыточность; АБД; отношение; 
    СУБД; безопасность; объект; общее использование данных; схема 
объект/отношение; хранимое поле; интерфейс, основанный на форме; хранимый 
файл; интеграция; хранимая запись; целостность. 
    1.2. Каковы преимущества использования системы баз данных? 
    1.3. Каковы недостатки использования системы баз данных? 
    1.4. Как вы понимаете термин "реляционная система"? Назовите различия 
между реляционной и нереляционными системами. 
    1.5. Укажите результат следующих SQL-операторов выборки из базы данных, 
приведенной на рис. 1.1: 
    a)         SELECT   WINE, PRODUCER 
    FRCM     CELLAR 
    WHERE   BIN = 72 ; 
    6)        SELECT   WINE, PRODUCER 
    FRCM     CELLAR 
    WHERE   YEAR > 91 ; 
    В)         SELECT   BIN, WINE, YEAR 
    FRCM    CELLAR 
    WHERE    READY < 94 ; 
    32 Часть I. Основные понятия 

    Г)         SELECT   BIN, WINE, YEAR 
    FRCM     CELLAR 
    WHERE    PRODUCER = 'Robt. Mondavi' 
    AND      BOTTLES > 6 ; 
    1.6. Укажите результат следующих SQL-операторов изменения в базе данных, 
приведенной на рис. 1.1: 
    a)         INSERT 
    INTO     CELLAR (BIN, WINE, PRODUCER, YEAR, BOTTLES, READY ) 
    VALUES (80, 'Syrah', 'Meridian', 89, 12, 94 ); 
    6)        DELETE 
    FROM    CELLAR 
    WHERE    READY > 95 ; 
    В)        UPDATE   CELLAR 
    SET      BOTTLES = 5 
    WHERE    BIN = 50 ; 
    Г)         UPDATE   CELLAR 
    SET      BOTTLES = BOTTLES + 2 
    WHERE    BIN = 50 ; 
    1.7. Напишите оператор SQL для выполнения следующих операций в базе данных 
винного погреба: 
    а) выберите номер отсека (BIN), наименование вина и количество бутылок для 
всех вин Geyser Peak; 
    б) выберите номер отсека (BIN), наименование вина для всех вин, запас 
которых составляет более пяти бутылок; 
    в) выберите номер отсека (BIN) для всех красных вин; 
    г) добавьте три бутылки (BOTTLES) в отсек (BIN) с номером 30; 
    д) удалите все вина Chardonnay из всего запаса; 
    е) добавьте данные нового поступления (12 бутылок) Gary Farrell Merlot: 
отсек номер 55, год 91, готово в 96. 
    1.8. Предположим, что у вас есть коллекция классической музыки, 
содержащаяся на компакт-дисках, пластинках и/или аудиокассетах, и вы хотите 
построить базу данных, которая позволит находить записи определенного 
композитора (например, Сибелиуса), дирижера (например, Симона Ратла), солиста 
(например, Артура Грюмикса), произведения (например. Пятая симфония 
Бетховена), оркестра (например, NYPO), вида произведения (например, концерт 
для виолончели) или камерной группы (например, квартет Кронус). Начертите 
схему объект/отношение для этой базы данных по образцу рис. 1.6. 

    Ответы к некоторым упражнениям 

    1.1. Здесь мы сделаем одно замечание: ведомственные издания, рекламные 
брошюры и т.д. очень часто используют термин "база данных", имея в виду СУБД 
(например, "поставщик базы данных Х делает это лучше поставщика базы данных Y 
в два раза"). Такое употребление термина небрежное, вызывает осуждение, но 
очень часто используется. (Предостережение автора.) 
    1.3. Перечислим некоторые недостатки. 
    • Без надлежащего контроля безопасность может быть подвергнута риску. 

    Глава 1. Управление базами данных 33 
    2 Введение в системы баз данных 

    • Целостность может быть подвергнута риску (без надлежащего контроля). " 
Может потребоваться дополнительное аппаратное обеспечение. 
    " Накладные расходы для повышения производительности могут быть значительными. 
    • Успешное выполнение операции является критическим (предприятие может 
быть весьма уязвимым по отношению к сбоям). 
    • Система, вероятно, будет сложной (хотя такие сложности должны быть 
скрыты от пользователя). 
    1.5. а) 
    WINE| PRODUCER 
    Zinfandel                Rafanelli 
    б) 
    WINE                      PRODUCER 
    Chardormay               Buena Vista 
    Chardonnay               Geyser Peak 
    Jo. Riesling              Jekel 
    Fume Blanc                Ch. St. Jean 
    Gewurztraminer            Ch. St. Jean 
    B) 
    BIN:| WINEYEAR 
    6                         Chardonnay        91 
    22                        rune Blanc         91 
    52                        Pinot Noir        90 
    Г) 
    WINE| BIN| YEAR 
    Cab. Sauvigon             48                88 
    1.6. а) добавление в таблицу CELLAR строки со значением 80 в поле BIN; 
    б) удаление из таблицы CELLAR строк со значениями 45, 48, 64 и 72 в поле BIN; 
    в) количество бутылок (поле BOTTLES) устанавливается равным пяти для 
строки со значением 50 в поле BIN; 
    г) то же, что и (в). 
    1.7. a)         SELECT   BIN, WINE, BOTTLES 
    FRCM    CELLAR 
    WHERE    PRODUCER -- 'Geyser Peak' ; 
    6)         SELECT   BIN, WINE 
    FRCM    CELLAR 
    WHERE   BOTTLES > 5 ; 
    В)         SELECT   BIN 
    FRCM    CELLAR 
    WHERE   WINE = 'Cab. Sauvignon' 
    OR      WINE = 'Pinot Noir' 
    OR      WINE = 'Zinfandel' 
    OR      WINE = 'Syrah'; 
    OR       .......; 


    34                                                 Часть I. Основные понятия 


    Г')         UPDATE   CELLAR 
    SET      BOTTLES = BOTTLES + 3 
    WHERE    BIN = 30 ; 
    д)         DELETE 
    FRCM     CELLAR 
    WHERE   WINE = 'Chardonnay' ; 
    e)         INSERT 
    INTO     CELLAR (BIN, WINE, PRODUCER, YEAR, BOTTLES, READY ) 
    VALUES (55, 'Merlot', 'Gary FarrelL', 91, 12, 96 ); 


    Глава 1, Управление базами данных 35 
