История развития баз данных.Язык SQL.
Выбери формат для чтения
Загружаем конспект в формате pdf
Это займет всего пару минут! А пока ты можешь прочитать работу в формате Word 👇
Дисциплина «Базы данных» МТУСИ
Номер
1-2
Лекции (тема)
Введение История развития баз данных. Основные понятия и определения.
Архитектура БД. Физическая и логическая независимость. Процесс прохождения
пользовательского запроса. Классификация моделей данных.
3-4
Теоретико-графовые модели данных. Иерархическая модель данных. Язык
описания данных иерархической модели. Внешние модели.
Язык манипулирования данными в иерархических базах данных. Операторы поиска
данных в т.ч. с возможностью модификации. Операторы модификации данных.
5-6
Сетевая модель данных. Язык описания данных в сетевой модели. Язык
манипулирования данными в сетевой модели.
7
Реляционная модель данных. Основные определения.
8-9
Операции над отношениями. Реляционная алгебра. Теоретико-множественные
операции реляционной алгебры. Специальные операции реляционной алгебры
10-11
Язык SQL. История развития SQL. Структура(блоки) SQL Типы данных. Оператор
выбора SELECT. Применение агрегатных функций и вложенных запросов в
операторе выбора. Вложенные запросы. Внешние объединения. Операторы
манипулирования данными.
Операторы DDL с заданием ограничений целостности.
Средства определения схемы базы данных.
Операции создания представлений. Горизонтальные, вертикальные,
сгруппированные, объединенные представления.
12
13
14
15-16
Системный анализ предметной области. Пример описания предметной области.
Инфологическое моделирование. Модель «сущность—связь».
Переход к реляционной модели данных
Проектирование реляционных БД на основе принципов нормализации.
Даталогическое проектирование.
17
Принципы поддержки целостности в реляционной модели данных. Общие понятия
и определения целостности. .
Командный SQL (PL/SQL)
Классы СУБД. Модели архитектур СУБД.
18-20
22
1
Учебно-методическое и информационное обеспечение дисциплины
Обязательная литература
1. Карпова Т.С. Базы данных. Модели, разработка, реализация. СПб: Питер, 2008.
2. Кренке Д. Теория и практика построения баз данных. С.-Пб.: Питер, 2006, 800 с.
3. Советов Б.Я., Цехановский В.В., Чертовский В.Д. Базы данных. Теория и практика. М.:
Высшая школа, 2005, 464 с.
4. Диго С.М. Базы данных. М.: Финансы, 2005, 590с.
5. Кузнецов С.Д. Основы баз данных. Курс лекций. М.: ИНТУИТ.РУ, 2005, 488 с.
6. Гарсиа-Молина Г., Ульман Дж., Уидом Дж. Системы баз данных. Полный курс. М.:
Вильямс, 2003, 1088 с.
7. Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных. С.-Пб.: Корона-принт, 2004,
736 с.
Дополнительная литература
8. Мартин Дж. Организация баз данных в вычислительных системах. М.:1999.
9. Дунаев С. Б. Доступ к базам данных и техника работы в сети. Практические приемы
современного программирования. М.: Диалог-МИФИ, 1999.
10. Арсеньев Б.П., Яковлев С.А. Интеграция распределенных баз данных. С-Пб.: Лань, 2001.
11. Полякова Л.Н. Основы SQL. Курс лекций. М.: ИНТУИТ.РУ, 2004, 368 с.
12. Харрингтон Джен Л. Проектирование реляционных баз данных. М.: Лори, 2006, 230 с.
13. Ролланд Ф.Д. Основные концепции баз данных. М.: Вильямс, 2002, 256 с.
Интернет-источники
14.
Портал
дистанционного
обученияwww.intuit.ru:
С.Кузнецов
Введение
в
реляционные базы данных http://www.intuit.ru/studies/courses/74/74/info
15. IT-портал CITForum http://citforum.ru
16. Русскоязычный сайт поддержки MySQL http://www.mysql.ru
17. Официальный сайт СУБД: www.mysql.com
18. Сообщество российских программистов http://www.rsdn.ru
2
Лекция 1. Введение
История развития баз данных
В истории вычислительной техники можно проследить развитие двух основных
областей ее использования.
1. Первая область — применение вычислительной техники для выполнения
численных расчетов, которые слишком долго или вообще невозможно
производить вручную.
Развитие этой области способствовало интенсификации методов численного
решения сложных математических задач, появлению языков программирования,
ориентированных на удобную запись численных алгоритмов, становлению
обратной связи с разработчиками новых архитектур ЭВМ. Характерная
особенность области - наличие сложных алгоритмов обработки, которые
применяются к простым по структуре данным небольших объемов.
2. Вторая область - использование средств вычислительной техники в
автоматизированных ИС.
ИС – это программно-аппаратный комплекс, обеспечивающий функциональность:
▬ надежное хранение данных в памяти компьютера;
▬ выполнение специфических для данного приложения преобразований информации
и вычислений;
▬ предоставление пользователям удобного и легко осваиваемого интерфейса
Обычно такие системы имеют дело с большими объемами информации, имеющей
достаточно сложную структуру.
Классические примеры ИС: ИБС(банковские системы),
АСУП(автоматизир.системы упр-я предприятиями), системы резервирования (авиац. или ж/д
билетов, мест в гостиницах) и т. д.
Вторая область использования вычислительной техники возникла позже первой, т.к.
возможности компьютеров по хранению информации были очень ограниченными. В
первых компьютерах использовались два вида устройств внешней памяти — магнитные
ленты и барабаны. Емкость магнитных лент была достаточно велика, но они
обеспечивали только последовательный доступ к данным. Магнитные барабаны (они
ближе всего к современным магнитным дискам с фиксированными головками) давали
возможность произвольного доступа к данным, но имели ограниченный объем хранимой
информации.
Эти ограничения не являлись слишком существенными для чисто численных
расчетов. Однако в ИС совокупность взаимосвязанных информационных объектов
фактически отражает сложную модель объектов реальной ПрО, что требует быстрой
реакции системы на запросы пользователей.
Стали нужны быстрые(!) устройства хранения данных. Т.е. магнитные ленты и
барабаны(сравнительно медленные УХД) -было недостаточным.
Именно требования нечисловых приложений вызвали появление съемных
магнитных дисков с подвижными головками, что явилось революцией в истории
выч.техники. Эти устройства внеш.памяти обладали существенно большей емкостью, чем
магн.барабаны, обеспечивали удовл.скорость доступа к данным в режиме произвольной
выборки, а возможность смены дискового пакета на устройстве позволяла иметь
практически неограниченный архив данных.
3
С появлением магнитных дисков началась история систем управления данными во
внешней памяти. До этого каждая прикладная программа, которой требовалось хранить
данные во внешней памяти, сама определяла расположение каждой порции данных на
магнитной ленте или барабане и выполняла обмены между оперативной памятью и
устройствами внешней памяти с помощью программно-аппаратных средств низкого
уровня (машинных команд или вызовов соответствующих программ операционной
системы). Такой режим работы не позволяет или очень затрудняет поддержание на одном
внешнем носителе нескольких архивов долговременно хранимой информации. Кроме
того, каждой прикладной программе приходилось решать проблемы именования частей
данных и структуризации данных во внешней памяти.
Файлы и файловые системы
Важный шаг в развитии ИС - переход к использованию централизованных систем
управления файлами (СУФ). С точки зрения прикладной программы, файл — это
именованная область внешней памяти, в которую можно записывать и из которой
можно считывать данные.
От СУФ зависят: правила именования файлов, способ доступа к данным,
хранящимся в файле, и структура этих данных (и, возможно, от типа файла). СУФ берет
на себя распределение внешней памяти, отображение имен файлов в соответствующие
адреса во внешней памяти и обеспечение доступа к данным. Пользователи видят файл как
линейную последовательность записей и могут выполнить над ним ряд стандартных
операций:
▬ создать файл (требуемого типа и размера);
▬ открыть ранее созданный файл;
▬ прочитать из файла некоторую запись (текущую, следующую, предыдущую
первую, последнюю);
▬ записать в файл на место текущей записи новую, добавить новую запись в конец
файла.
Проблемы использования файлов для хранения данных
1) зависимость программ от данных
Структура записи файла была известна только программе, которая с ним работала,
СУФ ее не знала ее. И поэтому для того, чтобы извлечь некоторую информацию из файла,
необходимо было точно знать структур записи файла с точностью до бита. Каждая
программа, работающая с файлом, должна была иметь у себя внутри структуру данных,
соответствующую структуре этого файла. Поэтому при изменении структуры файла
требовалось изменять структуру программы, а это требовало новой компиляции, то
есть процесса перевода программы в исполняемые машинные коды. Такая ситуации
характеризовалась как зависимость программ от данных.
Для ИС характерно наличие большого числа пользователей (программ со
специфическими алгоритмами), обращающихся к информации в одних и тех же файлах.
Изменение структуры файла, необходимое для одной программы, требовало исправления
перекомпиляции и дополнительной отладки всех остальных программ, работающих с
этим же файлом. Это было первым существенным недостатком файловых систем,
который явился толчком к созданию новых систем хранения и управления информацией.
4
2) Децентрализованное администрирование режимов доступа к файлу
Поскольку файловые системы являются общим хранилищем файлов, принадлежащих,
вообще говоря, разным пользователям, СУФ должны обеспечивать авторизацию
доступа к файлам. В общем виде подход состоит в том, что по отношению к каждому
зарегистрированному пользователю данной вычислительной системы для каждого
существующего файла указываются действия, которые разрешены или запрещены
данному пользователю. Администрирование режимов доступа к файлу выполняет
создатель-владелец. Такой децентрализованный принцип управления создает трудности.
Отсутствие централизованных методов управления доступом к информации послужило
еще одной причиной разработки СУБД.
3) Низкая эффективность параллельной работы с одним файлом
Следующая причина - необходимость обеспечения эффективной параллельной
работы многих пользователей с одними и теми же файлами. В общем СУФ обеспечивали
режим многопользовательского доступа. Если ОС поддерживает многопользовательский
режим, то реальна ситуация, когда несколько пользователей одновр. пытаются работать с
одним файлом. Если все пользователи собираются только читать файл, ничего страшного
не произойдет. Но если хотя бы один из них будет изменять файл, для корректной работы
этих пользователей нужна синхронизация их действий по отношению к файлу.
Одновременная работа нескольких пользователей, связанная с модификацией
данных в файле, либо вообще не реализовывалась, либо была очень замедлена.
Эти недостатки послужили тем толчком, который заставил разработчиков
информационных систем предложить новый подход к управлению информацией. Этот
подход был реализован в рамках новых программных систем, названных впоследствии
Системами Управления Базами Данных (СУБД), а сами хранилища информации, которые
работали под управлением данных систем, назывались базами данных (БД).
I этап — БД на больших ЭВМ
История развития СУБД насчитывает более 40 лет. В 1968 году была введена в
эксплуатацию первая промышленная СУБД система IMS фирмы IBM. В 1975 году
появился первый стандарт ассоциации по языкам систем обработки данных — Conference
of Data System Languages (CODASYL), который определил ряд фундаментальных
понятий в теории систем баз данных, которые и до сих пор являются основополагающими
для сетевой модели данных.
В дальнейшее развитие теории баз данных большой вклад был сделан американским
математиком Э. Ф. Коддом, который является создателем реляционной модели данных. В
1981 году Э. Ф. Кодд получил за создание реляц.модели и реляц.алгебры престижную
премию Тьюринга Американской ассоциации по вычислительной технике.
Стремительное развитие выч.техники, изменение ее принципиальной роли в жизни
общества, обрушившийся бум ПЭВМ и, наконец, появление мощных рабочих станций и
сетей ЭВМ повлияло также и на развитие технологии баз данных. Можно выделить
четыре этапа в развитии обработки данных. Однако нет жестких временных
ограничений в этих этапах: они плавно переходят один в другой и даже сосуществуют
параллельно, но выделение этих этапов позволит более четко охарактеризовать отдельные
стадии развития технологии БД, подчеркнуть особенности, специфичные для конкретного
этапа.
5
Первый этап развития СУБД связан с организацией баз данных на больших машинах
типа IBM 360/370, ЕС-ЭВМ и мини-ЭВМ типа PDP11 (фирмы Digital Equipment
Corporation — DEC), разных моделях HP (фирмы Hewlett Packard).
Базы данных хранились во внешней памяти центральной ЭВМ, пользователями
этих БД были задачи, запускаемые в основном в пакетном режиме. Интерактивный режим
доступа обеспечивался с помощью консольных терминалов, которые не обладали
собственными вычис.ресурсами (процессором, внешней памятью) и служили только
устройствами ввода-вывода для центральной ЭВМ. Программы доступа к БД писались на
различных языках и запускались как обычные числовые программы. Мощные ОС
обеспечивали возможность условно параллельного выполнения всего множества задач.
Эти системы можно было отнести к системам распределенного доступа, потому что БД
была централизованной, хранилась на устройствах внешней памяти одной центральной
ЭВМ, а доступ к ней поддерживался от многих пользователей(задач).
Особенности этапа:
▬ Все СУБД базируются на мощных мультипрограммных операционных системах
(MVS, SVM, RTE, OSRV, RSX, UNIX), поэтому в основном поддерживается работа
с централизованной базой данных в режиме распределенного доступа.
▬ Функции управления распределением ресурсов в основном осуществляются
операционной системой (ОС).
▬ Используются
языки
низкого
уровня
манипулирования
ориентированные на навигационные методы доступа к данным.
данными,
▬ Значительная роль отводится администрированию данных.
▬ Идет обоснование и формализация реляционной модели данных (создана первая
система (System R), реализующая реляционную модель данных.
▬ Проводятся теоретические работы по оптимизации запросов и управлению
распределенным доступом к централизованной БД, введено понятие транзакции.
▬ Результаты научных исследований открыто обсуждаются в печати, идет мощный
поток общедоступных публикаций, касающихся всех аспектов теории и практики
баз данных, и результаты теоретических исследований активно внедряются в
коммерческие СУБД.
Появляются первые языки высокого уровня для работы с реляционной моделью данных,
но стандартов еще нет.
II этап - Эпоха персональных компьютеров
ПК стремительно ворвались в нашу жизнь и буквально перевернули наше
представление о месте и роли вычислительной техники в жизни общества. Теперь
компьютеры стали ближе и доступнее каждому пользователю. Исчез благоговейный страх
рядовых пользователей перед непонятными и сложными языками программирования.
Появилось множество программ, предназначенных для работы неподготовленных
пользователей. Эти программы были просты в использовании и интуитивно понятны: это
прежде всего различные редакторы текстов, электронные таблицы и другие.
Простыми и понятными стали операции копирования файлов и перенос информации с
одного компьютера на другой, распечатка текстов, таблиц и других документов.
Системные программисты были отодвинуты на второй план и пользователи
самостоятельно пытались автоматизировать работу с данными.
6
Появились программы, которые назывались системами управления базами данных и
позволяли хранить значительные объемы информации, они имели удобный интерфейс для
заполнения данных, встроенные средства для генерации различных отчетов. Эти
программы позволяли автоматизировать многие учетные функции, которые раньше
велись вручную. Постоянное снижение цен на ПК сделало их доступными не только для
организаций и фирм, но и для отдельных пользователей. Компьютеры стали
инструментом для ведения документации и собственных учетных функций. Это все
сыграло как положительную, так и отрицательную роль в области развития баз
данных. Кажущаяся простота и доступность персональных компьютеров и их
программного обеспечения породила множество дилетантов. Эти разработчики, считая
себя знатоками, стали проектировать недолговечные базы данных, которые не учитывали
многих особенностей объектов реального мира. Много было создано систем-однодневок,
которые не отвечали законам развития и взаимосвязи реальных объектов. Однако
доступность персональных компьютеров заставила пользователей из многих областей
знаний, которые ранее не применяли вычислительную технику в своей деятельности,
обратиться к ним. И спрос на развитые удобные программы обработки данных заставлял
поставщиков программного обеспечения поставлять все новые системы, которые принято
называть настольными (desktop) СУБД.
Но и в этот период появлялись любители, которые вопреки здравому смыслу
разрабатывали собственные СУБД, используя стандартные языки программирования. Это
был тупиковый вариант, потому что дальнейшее развитие показало, что перенести данные
из нестандартных форматов в новые СУБД было гораздо труднее, а в некоторых случаях
требовало таких трудозатрат, что легче было бы все разработать заново, но данные все
равно надо было переносить на новую более перспективную СУБД. И это тоже было
результатом недооценки тех функций, которые должна была выполнять СУБД.
Особенности этого этапа следующие:
▬ Все СУБД были рассчитаны на создание БД в основном с монопольным
доступом. И это понятно. Компьютер персональный, он не был подсоединен к
сети, и база данных на нем создавалась для работы одного пользователя. В редких
случаях предполагалась последовательная работа нескольких пользователей,
например, сначала оператор, который вводил бухгалтерские документы, а потом
главбух, который определял проводки, соответствующие первичным документам.
▬ Большинство СУБД имели развитый и удобный пользовательский интерфейс. В
большинстве существовал интерактивный режим работы с БД как в рамках
описания БД, так и в рамках проектирования запросов. Кроме того, большинство
СУБД предлагали развитый и удобный инструментарий для разработки готовых
приложений без программирования. Инструментальная среда состояла из готовых
элементов приложения в виде шаблонов экранных форм, отчетов, этикеток
(Labels), графических конструкторов запросов, которые достаточно просто могли
быть собраны в единый комплекс.
▬ Во всех настольных СУБД поддерживался только внешний уровень представления
реляционной модели, то есть только внешний табличный вид структур данных.
▬ При наличии высокоуровневых языков манипулирования данными типа
реляционной алгебры и SQL в настольных СУБД поддерживались низкоуровневые
языки манипулирования данными на уровне отдельных строк таблиц.
▬ В настольных СУБД отсутствовали средства поддержки ссылочной и
структурной целостности базы данных. Эти функции должны были выполнять
приложения, однако скудость средств разработки приложений иногда не позволяла
это сделать, и в этом случае эти функции должны были выполняться
7
пользователем, требуя от него дополнительного контроля при вводе и изменении
информации, хранящейся в БД.
▬ Наличие монопольного режима работы фактически привело к вырождению
функций администрирования БД и в связи с этим — к отсутствию
инструментальных средств администрирования БД.
▬ И, наконец, последняя и в настоящий момент весьма положительная особенность
— это сравнительно скромные требования к аппаратному обеспечению со стороны
настольных СУБД. Вполне работоспособные приложения, разработанные,
например, на Clipper, работали на PC 286.
▬ В принципе, их даже трудно назвать полноценными СУБД. Яркие представители
этого семейства — очень широко использовавшиеся до недавнего времени СУБД
Dbase (DbaseIII+, DbaseIV), FoxPro, Clipper, Paradox.
III этап - Распределенные базы данных
Хорошо известно, что история развивается по спирали, поэтому после процесса
«персонализации» начался обратный процесс — интеграция. Множится количество
локальных сетей, все больше информации передается между компьютерами, остро встает
задача согласованности данных, хранящихся и обрабатывающихся в разных местах, но
логически друг с другом связанных, возникают задачи, связанные с параллельной
обработкой транзакций — последовательностей операций над БД, переводящих ее из
одного непротиворечивого состояния в другое непротиворечивое состояние. Успешное
решение этих задач приводит к появлению распределенных баз данных, сохраняющих все
преимущества настольных СУБД и в то же время позволяющих организовать
параллельную обработку информации и поддержку целостности БД. Особенности
данного этапа:
▬ Практически все современные СУБД обеспечивают поддержку полной реляционной
модели, куда входит:
- структурная целостность — допустимы только данные, представленные в виде
отношений реляционной модели;
- языковая целостность, то есть используются языки манипулирования данными
высокого уровня (в основном SQL);
- ссылочная целостность, т.е контроль за соблюдением ссылочной целостности в
течение всего времени функционирования системы, и гарантий невозможности со
стороны СУБД нарушить эти ограничения.
▬ Большинство современных СУБД рассчитаны на многоплатформенную архитектуру,
то есть они могут работать на компьютерах с разной архитектурой и под разными
операционными системами, при этом для пользователей доступ к данным,
управляемым СУБД на разных платформах, практически неразличим.
▬ Появились развитые средства администрирования БД на основе общей концепции
средств защиты данных (для поддержки многопользовательской работы с БД и
возможности децентрализованного хранения данных) потребовали.
▬ Создаются серьезные теор.труды по оптимизации распределенных БД и работе с
распред.транзакциями и запросами с внедрением полученных результатов в
коммерческие СУБД.
▬ в современных СУБД существуют средства подключения клиентских приложений,
разработанных с использованием настольных СУБД и средства экспорта данных из
форматов настольных СУБД (чтобы не потерять клиентов, которые ранее работали на
8
настольных СУБД)
▬ разработан ряд стандартов в рамках языков описания и манипулирования данными
начиная с SQL89, SQL92, SQL99 и технологий по обмену данными между
различными СУБД, к которым можно отнести и протокол ODBC (Open DataBase
Connectivity), предложенный фирмой Microsoft.
▬ Начаты работы, связанные с концепцией объектно-ориентированных БД — ООБД.
Представителями СУБД, относящимся ко второму этапу, можно считать MS Access 97
и все современные серверы баз данных Oracle, MS SQL, Informix, DB2, МуSQL и
другие современные серверы БД, которых в настоящий момент насчитывается
несколько десятков.
IV этап - Перспективы развития систем управления базами данных
Этот этап характеризуется появлением новой технологии доступа к данным —
интранет. Основное отличие этого подхода от технологии клиент-сервер состоит в том,
что отпадает необходимость использования специализированного клиентского
программного обеспечения. Для работы с удаленной базой данных используется
стандартный броузер Интернета, например Microsoft Internet Explorer или Netscape
Navigator, и для конечного пользователя процесс обращения к данным происходит
аналогично скольжению по Всемирной Паутине (см. рис. 1.1). При этом встроенный в
загружаемые пользователем HTML-страницы код, написанный обычно на языке Java,
Java-script, Perl и других, отслеживает все действия пользователя и транслирует их в
низкоуровневые SQL-запросы к базе данных, выполняя, таким образом, ту работу,
которой в технологии клиент-сервер занимается клиентская программа. Удобство данного
подхода привело к тому, что он стал использоваться не только для удаленного доступа к
базам данных, но и для пользователей локальной сети предприятия. Простые задачи
обработки данных, не связанные со сложными алгоритмами, требующими согласованного
изменения данных во многих взаимосвязанных объектах, достаточно просто и эффективно
могут быть построены по данной архитектуре. В этом случае для подключения нового
пользователя к возможности использовать данную задачу не требуется установка
дополнительного клиентского программного обеспечения. Однако алгоритмически
сложные задачи рекомендуется реализовывать в архитектуре «клиент-сервер» с
разработкой специального клиентского программного обеспечения.
У каждого из вышеперечисленных подходов к работе с данными есть свои достоинства и
свои недостатки, которые и определяют область применения того или иного метода, и в
настоящее время все подходы широко используются.
+ OLAP http://ru.wikipedia.org/wiki/OLAP
+ Сравнение OLAP-серверов :
+ OLTP http://ru.wikipedia.org/wiki/OLTP
9
Лекция 2.
Основные понятия и определения
До недавнего времени использовался устаревший термин «банк данных» (иногда как
синоним «база данных». В материалах Государственного комитета по науке и технике
(ГКНТ), изданных в 1982 г., эти понятия различаются. В наст.время термин БнД уже не
используется.
База данных (БД) — именованная совокупность структурированных данных,
отражающая состояние объектов и их отношений в рассматриваемой предметной области.
Система управления базами данных (СУБД) — совокупность языковых и
программных средств, предназначенных для создания, ведения и совместного
использования БД многими пользователями.
Программы, с помощью которых пользователи работают с базой данных,
называются приложениями. В общем случае с одной базой данных могут работать
множество различных приложений..
Архитектура базы данных. Физическая и логическая независимость
Терминология в СУБД, да и сами термины «база данных» и «банк данных»
частично заимствованы из финансовой деятельности.
В процессе научных исследований, посвященных тому, как именно должна быть
устроена СУБД, предлагались различные способы реализации. Самым жизнеспособным
из них оказалась предложенная американским комитетом по стандартизации ANSI
(American National Standards Institute) трехуровневая система организации БД,
изображенная на рис. 2.1:
Рис. 2.1. Трехуровневая модель СУБД,
предложенная ANSI
1. Уровень внешних моделей — самый
верхний уровень, где каждая модель имеет
свое «видение» данных. Этот уровень
определяет точку зрения на БД отдельных
приложений. Каждое приложение видит и
обрабатывает только те данные, которые
необходимы именно ему. Например, система
распределения работ использует сведения о
квалификации сотрудника, но ее не
интересуют сведения об окладе, домашнем адресе и телефоне сотрудника, и наоборот,
именно эти сведения используются в подсистеме отдела кадров.
2. Концептуальный уровень — центральное управляющее звено, здесь база данных
представлена в наиболее общем виде, объединяет данные, используемые всеми
приложениями, работающими с БД. Фактически концептуальный уровень отражает
обобщенную модель предметной области (объектов реального мира), для которой
создавалась БД. Как любая модель, концептуальная модель отражает только
существенные, с точки зрения обработки, особенности объектов реального мира.
3. Физический уровень — собственно данные, расположенные в файлах или в
страничных структурах, расположенных на внешних носителях информации.
Эта архитектура позволяет обеспечить логическую (между уровнями 1 и 2) и
физическую (между уровнями 2 и 3) независимость при работе с данными.
10
Логическая независимость предполагает возможность изменения одного приложения
без корректировки других приложений, работающих с этой же базой данных.
Физическая независимость предполагает возможность переноса хранимой информации
с одних носителей на другие при сохранении работоспособности всех приложений,
работающих с данной базой данных.
Это именно то, чего не хватало при использовании файловых систем.
Выделение
концептуального
уровня
позволило
централизованного управления базой данных.
разработать
аппарат
Пользователи баз данных
Как любой программно-организационно-технический комплекс, БД существует во
времени и в пространстве. Она имеет определенные стадии своего развития:
1. Анализ предметной области.
2. Проектирование.
3. Реализация.
4. Эксплуатация;
5. Модернизация и развитие. 6. Полная реорганизация.
На каждом этапе своего существования с БД связаны разные категории пользователей.
Основные категории пользователей и их роль в функционировании БД:
Конечные пользователи. Это основная категория пользователей, в интересах
которых и создается банк данных. В зависимости от особенностей создаваемого банка
данных круг его конечных пользователей может существенно различаться. Это могут
быть случайные пользователи, обращающиеся к БД время от времени за получением
некоторой информации, а могут быть регулярные пользователи. Главный принцип - от
конечных пользователей не должно требоваться каких-либо специальных знаний в
области вычислительной техники и языковых средств.
Администраторы базы данных. Это группа пользователей, которая на начальной
стадии разработки базы данных отвечает за его оптимальную организацию с точки
зрения одновременной работы множества конечных пользователей, на стадии
эксплуатации отвечает за корректность работы данной базы в многопользовательском
режиме. На стадии развития и реорганизации эта группа пользователей отвечает за
возможность корректной реорганизации базы без изменения или прекращения его
текущей эксплуатации.
Разработчики и администраторы приложений. Это группа пользователей, которая
функционирует во время проектирования, создания и реорганизации базы данных.
Администраторы приложений координируют работу разработчиков при разработке
конкретного приложения или группы приложений, объединенных в функциональную
подсистему. Разработчики конкретных приложений работают с той частью информации
из базы данных, которая требуется для конкретного приложения.
Не в каждой БД могут быть выделены все типы пользователей. Однако при построении
современных сложных корпоративных БД, которые используются для автоматизации всех
или большей части бизнес-процессов в крупной фирме или корпорации, могут
существовать и группы администраторов приложений, и отделы разработчиков. Наиболее
сложные обязанности возложены на группу администратора БД.
11
Рассмотрим их более подробно. В составе группы администратора
БД должны быть:
системные аналитики;
проектировщики структур данных и внешнего по отношению к базе данных
информационного обеспечения;
проектировщики технологических процессов обработки данных;
системные и прикладные программисты;
операторы и специалисты по техническому обслуживанию.
Основные функции группы администратора БД
1. Анализ предметной области: описание предметной области, выявление ограничений
целостности, определение статуса (доступности, секретности) информации,
определение потребностей пользователей, определение соответствия «данные—
пользователь», определение объемно-временных характеристик обработки данных.
2. Проектирование структуры БД: определение состава и структуры файлов БД и
связей между ними, выбор методов упорядочения данных и методов доступа к
информации, описание БД на языке описания данных (ЯОД).
3. Задание ограничений целостности при описании структуры БД и процедур
обработки БД:
задание декларативных ограничений целостности, присущих предметной области;
определение динамических ограничений целостности, присущих предметной
области в процессе изменения информации, хранящейся в БД;
определение ограничений целостности, вызванных структурой БД;
разработка процедур обеспечения целостности БД при вводе и корректировке
данных;
определение ограничений целостности при параллельной работе пользователей в
многопользовательском режиме.
4
Первоначальная загрузка и ведение БД:
разработка технологии первоначальной загрузки БД, которая будет отличаться от
процедуры модификации и дополнения данными при штатном использовании базы
данных;
разработка технологии проверки соответствия введенных данных реальному
состоянию предметной области. База данных моделирует реальные объекты
некоторой предметной области и взаимосвязи между ними, и на момент начала
штатной эксплуатации эта модель должна полностью соответствовать состоянию
объектов предметной области на данный момент времени;
в соответствии с разработанной технологией первоначальной загрузки может
понадобиться проектирование системы первоначального ввода данных.
5
Защита данных:
определение системы паролей, принципов регистрации пользователей, создание
групп пользователей, обладающих одинаковыми правами доступа к данным;
разработка принципов защиты конкретных данных и объектов проектирования;
разработка специализированных методов кодирования информации при ее
циркуляции в локальной и глобальной информационных сетях;
разработка средств фиксации доступа к данным и попыток нарушения системы
защиты;
12
тестирование системы защиты;
исследование случаев нарушения системы защиты и развитие динамических
методов защиты информации в БД.
6. Обеспечение восстановления БД:
разработка организационных средств архивирования и принципов восстановления
БД;
разработка дополнительных программных средств и технологических процессов
восстановления БД после сбоев.
7. Анализ обращений пользователей БД: сбор статистики по характеру запросов, по
времени их выполнения, по требуемым выходным документам
8. Анализ эффективности функционирования БД:
анализ показателей функционирования БД;
планирование реструктуризации (изменение структуры) БД и реорганизации БнД.
9. Работа с конечными пользователями:
Сбор информации об изменении предметной области;
сбор информации об оценке работы бд;
обучение пользователей, консультирование пользователей;
разработке необходимой методической и учебной документации по работе конечных
пользователей.
10. Подготовка и поддержание системных средств:
анализ существующих на рынке программных средств и анализ возможности и
необходимости их использования в рамках БД;
разработка требуемых организационных и программно-технических приятий по
развитию БД;
проверка работоспособности закупаемых программных средств перед
подключением их к БД;
курирование подключения новых программных средств к БД.
11. Организационно-методическая работа по проектированию БД:
выбор или создание методики проектирования БД;
определение целей и направления развития системы в целом;
планирование этапов развития БД;
разработка общих словарей-справочников проекта БД и концептуальной
модели;
стыковка внешних моделей разрабатываемых приложений;
курирование подключения нового приложения к действующей БД;
обеспечение возможности комплексной отладки множества приложений,
взаимодействующих с одной БД.
13
Процесс прохождения пользовательского запроса
Рисунок иллюстрирует взаимодействие пользователя, СУБД и ОС при обработке
запроса на получение данных. Цифрами помечена последовательность взаимодействий:
1.Пользователь посылает СУБД запрос на получение данных из БД.
2 -3. Анализ прав пользователя и внешней модели данных, соответствующей данному
пользователю, подтверждает или запрещает доступ пользователя к запрошенным данным.
12. В случае запрета на доступ к данным СУБД сообщает пользователю об этом
(стрелка 12) и прекращает дальнейший процесс обработки данных
4. СУБД определяет часть концептуальной модели, которая затрагивается запросом
пользователя,
5. СУБД получает информацию о запрошенной части концептуальной модели.
6. СУБД запрашивает информацию о местоположении данных на физическом уровне
(файлы или физические адреса).
7. В СУБД возвращается информация о местоположении данных в терминах Опер.Системы.
8. СУБД просит ОС предоставить необходимые данные, используя средства ОС.
9. Операционная система осуществляет перекачку информации из устройств хранения и
пересылает ее в системный буфер.
10. Операционная система оповещает СУБД об окончании пересылки.
11. СУБД выбирает из доставленной информации, находящейся в системном буфере,
только то, что нужно пользователю, и пересылает эти данные в рабочую область
пользователя.
БМД — это База Метаданных, здесь хранится вся информация об используемых
структурах данных, логической организации данных, правах доступа пользователей и
физическом расположении данных. Для управления БМД существует специальное ПО
администрирования БД, для корректного использования единого информационного
пространства многими пользователями.
Запрос проходит полный цикл далеко не всегда! СУБД обладает достаточно развитым
интеллектом и не повторяет бессмысленных действий.
Разумеется, механизм прохождения запроса в реальных СУБД гораздо сложнее, но и эта
упрощенная схема показывает, насколько серьезными и сложными должны быть
механизмы обработки запросов, поддерживаемые реальными СУБД.
14
Классификация моделей данных
Одними из основополагающих в концепции баз данных являются обобщенные
категории «данные» и «модель данных».
Понятие «данные» в концепции баз данных — это набор конкретных значений,
параметров, характеризующих объект, условие, ситуацию или любые другие факторы.
Модель данных — это некоторая абстракция, которая, будучи приложима к
конкретным данным, позволяет пользователям и разработчикам трактовать их уже как
информацию, то есть сведения, содержащие не только данные, но и взаимосвязь между
ними.
В соответствии с трехуровневой архитектурой понятие модели данных применяется
к каждому уровню.
Рис. 2.3. Классификация моделей данных
Физическая модель данных оперирует категориями, касающимися организации
внешней памяти и структур хранения, используемых в данной операционной среде. В
настоящий момент в качестве физических моделей используются различные методы
размещения данных, основанные на файловых структурах: это организация файлов
прямого и последовательного доступа, индексных файлов и инвертированных файлов,
файлов, использующих различные методы хэширования, взаимосвязанных файлов. Кроме
того, современные СУБД широко используют страничную организацию данных.
Физические модели данных, основанные на страничной организации, являются наиболее
перспективными.
Инфологические, или семантические модели выражают информацию о предметной
области в виде, независимом от используемой СУБД. Они отражают в естественной и
удобной для разработчиков и заказчиков форме информационно-логический уровень
абстрагирования, связанный с фиксацией и описанием объектов предметной области, их
свойств и их взаимосвязей.
Инфологические модели данных используются на ранних стадиях проектирования
для описания структур данных в процессе разработки приложения, а даталогические
модели уже поддерживаются конкретной СУБД.
15
Документальные
модели
данных
соответствуют
представлению
о
слабоструктурированной информации, ориентированной в основном на свободные
форматы документов, текстов на естественном языке.
Модели, основанные на языках разметки документов, связаны прежде всего
стандартным общим языком разметки — SGML (Standart Generalised Markup Language),
который был утвержден ISO в качестве стандарта еще в 80-х годах. Этот язык
предназначен для создания других языков разметки, он определяет допустимый набор
тегов (ссылок), их атрибуты и внутреннюю структуру документа. Контроль за
правильностью использования тегов осуществляется при помощи специального набора
правил, называемых DTD-описаниями, которые используются программой клиента при
разборе документа. Для каждого класса документов определяется свой набор правил,
описывающих грамматику соответствующего языка разметки. Но ввиду своей сложности
SGML использовался в основном для описания синтаксиса других языков (наиболее
известным из которых является HTML), и немногие приложения работали с SGMLдокументами напрямую.
Гораздо более простой и удобный, чем SGML, язык HTML позволяет определять
оформление элементов документа и имеет некий ограниченный набор инструкций —
тегов, при помощи которых осуществляется процесс разметки. Инструкции HTML в
первую очередь предназначены для управления процессом вывода содержимого
документа на экране программы-клиента и определяют этим самым способ представления
документа, но не его структуру. В качестве элемента гипертекстовой базы данных,
описываемой HTML, используется текстовый файл, который может легко передаваться
по сети с использованием протокола HTTP. Эта особенность, а также то, что HTML
является открытым стандартом и огромное количество пользователей имеет возможность
применять возможности этого языка для оформления своих документов, безусловно,
повлияли на рост популярности HTML и сделали его сегодня главным механизмом
представления информации в Интернете.
Однако HTML сегодня уже не удовлетворяет в полной мере требованиям,
предъявляемым современными разработчиками к языкам подобного рода. И ему на смену
был предложен новый язык гипертекстовой разметки, мощный, гибкий и, одновременно с
этим, удобный язык XML. В чем же заключаются его достоинства?
XML (Extensible Markup Language) — это язык разметки, описывающий целый класс
объектов данных, называемых XML-документами. Он используется в качестве средства
для описания грамматики других языков и контроля за правильностью составления
документов. То есть сам по себе XML не содержит никаких тегов, предназначенных для
разметки, он просто определяет порядок их создания.
Тезаурусные модели основаны на принципе организации словарей, содержат
определенные языковые конструкции и принципы их взаимодействия в заданной
грамматике. Эти модели эффективно используются в системах-переводчиках, особенно
многоязыковых переводчиках. Принцип хранения информации в этих системах и
подчиняется тезаурусным моделям.
Дескрипторные модели — самые простые из документальных моделей, они широко
использовались на ранних стадиях использования документальных баз данных. В этих
моделях каждому документу соответствовал дескриптор — описатель. Этот дескриптор
имел жесткую структуру и описывал документ в соответствии с теми характеристиками,
которые требуются для работы с документами в разрабатываемой документальной БД.
Например, для БД, содержащей описание патентов, дескриптор содержал название
области, к которой относился патент, номер патента, дату выдачи патента и еще ряд
ключевых параметров, которые заполнялись для каждого патента. Обработка информации
в таких базах данных велась исключительно по дескрипторам, то есть по тем параметрам,
которые характеризовали патент, а не по самому тексту патента.
16
Лекция 3. Теоретико-графовые модели данных
Как уже упоминалось ранее, эти модели отражают совокупность объектов реального
мира в виде графа взаимосвязанных информационных объектов. В зависимости от типа
графа выделяют иерархическую или сетевую модели. Исторически эти модели появились
раньше, и в настоящий момент они используются реже, чем более современная
реляционная модель данных. Однако до сих пор существуют системы, работающие на
основе этих моделей, а одна из концепций развития объектно-ориентированных баз
данных предполагает объединение принципов сетевой модели с концепцией реляционной.
Иерархическая модель данных
Иерархическая модель данных является наиболее простой среди всех даталогических
моделей. Исторически она появилась первой среди всех даталогических моделей: именно
эту модель поддерживает первая из зарегистрированных промышленных СУБД IMS
фирмы IBM.
Появление иерархической модели связано с тем, что в реальном мире очень многие
связи соответствуют иерархии, когда один объект выступает как родительский, а с ним
может быть связано множество подчиненных объектов. Иерархия проста и естественна в
отображении взаимосвязи между классами объектов. Основными информационными
единицами в иерархической модели являются: база данных (БД), сегмент и поле, Поле
данных определяется как минимальная, неделимая единица данных, доступная
пользователю с помощью СУБД. Например, если в задачах требуется печатать в
документах адрес клиента, но не требуется дополнительного анализа полного адреса, то
есть города, улицы, дома, квартиры, то мы можем принять весь адрес за элемент данных,
и он будет храниться полностью, а пользователь сможет получить его только как полную
строку символов из БД. Если же в наших задачах существует анализ частей,
составляющих адрес, например города, где расположен клиент, то нам необходимо
выделить город как отдельный элемент данных, только в этом случае пользователь может
получить к нему доступ и выполнить, например, запрос на поиск всех клиентов, которые
проживают в конкретном городе, например в Париже. Однако если пользователю
понадобится и полный адрес клиента, то остальную информацию по адресу также
необходимо хранить в отдельном поле, которое может быть названо, например,
Сокращенный адрес. В этом случае для каждого клиента в БД хранится как Город, так и
Сокращенный адрес.
Сегмент в терминологии Американской Ассоциации по базам данных DBTG (Data
Base Task Group) называется записью, при этом в рамках иерархической модели
определяются два понятия: тип сегмента или тип записи и экземпляр сегмента или
экземпляр записи.
Тип сегмента — это поименованная совокупность типов элементов данных, в него
входящих. Экземпляр сегмента образуется из конкретных значений полей или элементов
данных, в него входящих. Каждый тип сегмента в рамках иерархической модели образует
некоторый набор однородных записей. Для возможности различия отдельных записей в
данном наборе каждый тип сегмента должен иметь ключ или набор ключевых атрибутов
(полей, элементов данных). Ключом называется набор элементов данных, однозначно
идентифицирующих экземпляр сегмента. Например, рассматривая тип сегмента,
описывающий сотрудника организации, мы должны выделить те характеристики
сотрудника, которые могут его однозначно идентифицировать в рамках БД предприятия.
Если предположить, что на предприятии могут работать однофамильцы, то, вероятно,
наиболее надежным будет идентифицировать сотрудника по его табельному номеру.
Однако если мы будем строить БД, содержащую описание множества граждан, например
17
нашей страны, то, скорее всего, нам придется в качестве ключа выбрать совокупность
полей, отражающих его паспортные данные.
В иерархической модели сегменты объединяются в ориентированный древовидный
граф. При этом полагают, что направленные ребра графа отражают иерархические связи
между сегментами: каждому экземпляру сегмента, стоящему выше по иерархии и
соединенному с данным типом сегмента, соответствует несколько (множество)
экземпляров данного (подчиненного) тина сегмента. Тип сегмента, находящийся на более
высоком уровне иерархии, называется логически исходным по отношению к типам
сегментов, соединенным с данным направленными иерархическими ребрами, которые в
свою очередь называются логически подчиненными по отношению к этому типу
сегмента. Иногда исходные сегменты называют сегментами-предками, а подчиненные
сегменты называют сегментами-потомками.
Рис.3.1. Пример иерархических связей между сегментами
Определяется понятие схемы БД в терминологии иерархической модели.
Схема иерархической БД представляет собой совокупность отдельных деревьев,
каждое дерево в рамках модели называется физической базой данных. Каждая физическая
БД удовлетворяет следующим иерархическим ограничениям:
□ в каждой физической БД существует один корневой сегмент, то есть сегмент, у
которого пет логически исходного (родительского) типа сегмента;
□ каждый логически исходный сегмент может быть связан с произвольным числом
логически подчиненных сегментов;
□ каждый логически подчиненный сегмент может быть связан только с одним логически
исходным (родительским ) сегментом.
Очень важно понимать различие между сегментом и типом сегмента — оно такое же, как
между типом переменной и самой переменной: сегмент является экземпляром типа
сегмента. Например, у нас может быть тип сегмента Группа (Номер, Староста) и сегменты
этого типа, такие как (4305, Петров Ф. И.) или (383, Кустова Т. С).
Между экземплярами сегментов также существуют иерархические связи. Рассмотрим,
например, иерархический граф, представленный на рис. 3.2.
Рис.3.2. Пример структуры иерархического дерева
Каждый тип сегмента может иметь множество
соответствующих
ему
экземпляров.
Между
экземплярами
сегментов
также
существуют
иерархические связи.
На рис. 3.3 представлены 2 экземпляра иерархического дерева соответствующей
структуры.
18
Рис.3.3. Пример
данного дерева
двух
экземпляров
Экземпляры-потомки
одного
типа,
связанные
с
одним
экземпляром
сегмента-предка,
называют
«близнецами». Так, для нашего примера
экземпляры b1, b2 и b3 являются
«близнецами», но экземпляр b4 подчинен
другому
экземпляру
родительского
сегмента, и он не является «близнецом»
по отношению к экземплярам b1, b2 и b3.
Набор всех экземпляров сегментов,
подчиненных одному экземпляру корневого сегмента, называется физической записью.
Количество экземпляров-потомков может быть разным для разных экземпляров
родительских сегментов, поэтому в общем случае физические записи имеют разную
длину. Так, используя принцип линейной записи иерархических графов, пример на рис.
3.3 можно представить в виде двух записей:
Как видно из нашего примера,
физические записи в иерархической
модели различаются по длине и
структуре.
Язык описания данных иерархической модели
В рамках иерархической модели выделяют языковые средства описания данных
(DDL) и средства манипулирования данными (DML).
Каждая физическая база описывается набором операторов, определяющих как ее
логическую структуру, так и структуру хранения БД. Описание начинается с оператора
DBD (Data Base Definition):
DBD Name = < имя БД>, ACCESS = < способ доступа>
Способ доступа определяет способ организации взаимосвязи физических записей.
Определено 5 способов доступа: HSAM — hierarchical sequential access method
(иерархически последовательный метод), HIS AM — hierarchical index sequential access
method (иерархически индексно-последовательный метод), HDAM — hierarchical direct
access method (иерархически прямой метод), HIDAM — hierarchical index direct access
method (иерархически индексно-прямой метод), INDEX — индексный метод.
Далее идет описание наборов данных, предназначенных для хранения БД:
DATA SET DD1 = < имя оператора, определяющего хранимый набор данных>.
DEVICE =< устройство хранения БД>.
[OVFLW = < имя области переполнения>]
Так как, физические записи имеют разную длину, то при модификации данных
запись может увеличиться и превысит исходную длину записи до модификации. В этом
случае при определенных методах храпения может понадобиться дополнительное
пространство хранения, где и будут размещены дополнительные данные. Это
пространство и называется областью переполнения.
После описания всей физической БД идет описание типов сегментов, ее
составляющих, в соответствии с иерархией. Описание сегментов всегда начинается с
описания корневого сегмента. Общая схема описания типа сегмента такова:
19
SEGM NAME = < имя сегмента>. BYTES =< размер в байтах>.
FREQ = <средняя частота реализаций сегмента под одним исходным>
PARENT = <имя родительского сегмента>
Параметр FREQ определяет среднее количество экземпляров данного сегмента,
связанных с одним экземпляром родительского сегмента. Для корневого сегмента это
число возможных экземпляров корневого сегмента.
Для корневого сегмента параметр PARENT равен 0 (нулю). Далее для каждого сегмента
дается описание полей:
FIELD NAME = {(<имя поля> [. SEQ].{U | М}) | <имя поля> },
START = < номер байта, с которого начинается значения поля >,
BYTES = <размер поля в
байтах>,
TYPE = {X | Р | С}
Признак SEQ — задается для ключевого поля, если экземпляры данного сегмента
физически упорядочены в соответствии со значениями данного поля.
Параметр U задается, если значения ключевого ноля уникальны для всех
экземпляров данного сегмента, М — в противном случае. Если поле является ключевым,
то его описание задается в круглых скобках, в противном случае имя поля задается без
скобок. Параметр TYPE определяет тип данных. Для ранних иерархических моделей были
определены только три типа данных: X — шестнадцатеричный, Р —упакованный
десятичный, С — символьный.
Заканчивается описание схемы вызовом процедуры генерации:
□ DBDGEN — указывает на конец последовательности управляющих операторов
описания БД;
□ FINISH — устанавливает ненулевой код завершения при обнаружении ошибки;
□ END - конец.
В системе может быть несколько физических БД (ФБД), но каждая из них описывается
отдельно своим DBD и ей присваивается уникальное имя. Каждая ФБД содержит только
один корневой сегмент. Совокупность ФБД образует концептуальную модель данных.
Внешние модели
При работе с иерархической моделью каждая программа, пользователь или
приложение определяет свою внешнюю модель. Внешняя модель представляет, собой
совокупность поддеревьев для ФБД, с которыми работает данный пользователь. Каждый
подграф внешней модели в обязательном порядке должен содержать корневой тип
сегмента соответствующей ФБД иерархической концептуальной модели.
Представление внешней модели называется логической базой данных и определяется
совокупностью блоков связи данного приложения с физическими БД, входящими в
концептуальную схему БД. Блок связи — РСВ, program communication bloc — описывает
связь с одной физической БД по следующим правилам:
DBD NAME - < имя логической БД (подсхемы)> . ACCESS = LOGICAL
DATA SET = LOGICAL.
SEGM NAME = <имя сегмента в подсхеме>, PARENT =<имя родительского сегмента в
подсхеме>. SOURSE =(Имя соответствующего сегмента ФБД, имя ФБД)
…….
DBDGEN
FINISH
END
20
Совокупность блоков РСВ образует полное внешнее представление данного
приложения, называемое «блоком спецификации программ» (PSB, program specification
block).
Рассмотрим пример иерархической БД.
Организация занимается производством и продажей компьютеров, в рамках
производства комплектуют компьютеры из готовых деталей по индивидуальным заказам.
Существует несколько базовых моделей, которые продают без предварительных заказов
по наличию на складе. В организации существуют несколько филиалов (рис. 3.4) и
несколько складов, на которых хранятся комплектующие. Необходимо вести учет
продаваемой продукции.
Рис.3.4. Физическая БД «Филиалы»
Какие задачи нам надо решать в ходе разработки приложения?
□ При приеме заказа мы должны выяснить, какую модель заказывает заказчик: типичную
или индивидуальную комплектацию.
□ Если заказывается типичная модель, то выясняется, какая модель и есть ли она в
наличии, если модель есть, то надо уменьшить количество компьютеров данной
модели в данном филиале на покупаемое количество. На этом будем считать заказ
выполненным, однако при оформлении заказа
может
потребоваться
задание
полной
спецификации покупаемого изделия.
□ Если заказывается индивидуальная модель,
то требуется описать весь состав новой модели.
Для того чтобы можно было бы принимать
заказы на индивидуальные модели, нам
понадобится информация о наличие конкретных
деталей на складе, в этом случае нам
необходимо второе дерево — Склады (см. рис.
3.5).
Рис.3.5. Физическая модель
«Склады»
21
Язык манипулирования данными в иерархических базах данных
Для доступа к базе данных у пользователя должна быть сформирована специальная
среда окружения, поддерживающая в явном виде имеющиеся навигационные операции.
Для этого в ней должны храниться:
шаблоны всех записей логических баз данных, доступных пользователю;
указатели на текущий экземпляр сегмента данного типа — для всех типов сегментов.
ЯМД в иерархической модели поддерживает в явном виде навигационные операции.
Эти операции связаны с перемещением указателя, который определяет текущий
экземпляр конкретного сегмента. Все операторы в языке манипулирования данными
можно разделить на 3 группы. Первую группу составляют операторы поиска данных.
Операторы поиска данных
1.
GET UNIQUE <имя сегмента> WHERE <список поиска>:
список поиска состоит из последовательности условий вида:
<имя сегмента>.<имя поля> ОС :
ОС — операция сравнения;
условия могут быть соединены логическими операциями И и ИЛИ {& , V}.
Назначение: Получить единственное значение.
Пример: Найти типовую модель стоимостью не более $600, которая существует не менее
чем в 10 экземплярах.
GET UNIQUE ТИПОВЫЕ МОДЕЛИ WHERE Типовые модели.Стоимость <= $600
AND Типовые модели.Количество на складе >= 10
Данная команда всегда ищет с начала БД и останавливается, найдя первый экземпляр
сегмента, удовлетворяющий условиям поиска.
2. GET NEXT <имя сегмента> WHERE <список аргументов поиска>
Назначение: Получить следующий экземпляр сегмента для тех же условий.
Пример: Напечатать полный список заказов стоимостью не менее $500.
GET UNIQUE ИНДИВИДУАЛЬНЫЕ МОДЕЛИ WHERE Индивидуальные
модели.Стоимость >= $500 WHILE NOT FAIL (пока не конец поиска) DO
PRINT № заказа. Стоимость, Количество
GET
NEXT
ИНДИВИДУАЛЬНЫЕ
МОДЕЛИ END
3. GET NEXT <имя сегмента> WITHIN PARENT [ where <дополн.условия>]
Назначение: Получить следующий для того же исходного.
Пример: Получить перечень винчестеров, имеющихся на
складе номер 1, в количестве не менее 10 с объемом 10 Гбайт.
GET UNIQUE СКЛАД WHERE Склад.Номер = 1
GET NEXT ИЗДЕЛИЕ WITHIN PARENT
WHERE Изделие.Наименование = "Винчестер"
GET NEXT ХАРАКТЕРИСТИКИ WITHIN PARENT
WHERE ХАРАКТЕРИСТИКИ.Параметр = 10 AND
ХАРАКТЕРИСТИКИ.Единицы Измерения = Гб AND
ХАРАКТЕРИСТИКИ.Величина > 10
While Not Fail (пока поиск не завершен) DО
Get Next Within Parent
End
22
Операторы поиска данных с возможностью модификации
1 Найти и удержать единственный экземпляр сегмента. Эта операция подобна первой
операции поиска GET UNIQUE, единственным отличием этой операции является то,
что после выполнения этой операции над найденным экземпляром сегмента допустимы
операции модификации (изменения) данных.
GET HOLD UNIQUE <имя сегмента> WHERE <список поиска>
2 Найти и удержать следующий экземпляр сегмента. с теми же условиями поиска.
Аналогично операции 4 эта операция дублирует вторую операции поиска GET NEXT с
возможностью выполнения последующей модификации данных.
GET HOLD NEXT [WHERE дополнительные условия>]
3. Получить и удержать следующий экземпляр сегмента для того же родителя. (аналогом
операции поиска 3, но разрешает выполнение операций модификации данных после
себя).
GET HOLD NEXT WITHIN PARENT [ where <дополн.условия>]
Операторы модификации данных
1. Удалить: DELETE
Эта команда не имеет параметров. Почему? Потому что операции модификации
действуют на экземпляр сегмента, найденный командами поиска с удержанием. А он
всегда единственный текущий найденный и удерживаемый для модификации
экземпляр конкретного сегмента. Поэтому при выполнении команды удаления будет
удален именно этот экземпляр сегмента.
2. Обновить: UPDATE
Как же происходит обновление, если мы и в этой команде не задаем никаких
параметров. СУБД берет данные из рабочей области пользователя, где в шаблонах
записей соответствующих внутренних переменных находятся значения полей каждого
сегмента внешней модели, с которой работает данный пользователь. Именно этими
значениями и обновляется текущий экземпляр сегмента. Значит, перед тем как
выполнить операции модификации UPDATE, необходимо присвоить соответствующим
переменным новые значения.
3. Ввести новый экземпляр сегмента. INSERT <имя сегмента>
Эта команда позволяет ввести новый экземпляр сегмента, имя которого определено в
параметре команды. Если мы вводим данные в сегмент, который является
подчиненным некоторому родительскому экземпляру сегмента, то он будет внесен в
БД и физически подключен к тому экземпляру родительского сегмента, который в
данный момент является текущим.
Набор операций поиска и манипулирования данными в иерархической БД невелик, но он
вполне достаточен для получения доступа к любому экземпляру любого сегмента БД.
Однако следует отметить, что способ доступа, который применяется в данной модели,
связан с последовательным перемещением от одного экземпляра сегмента к другому.
Такой способ напоминает движение летательного аппарата или корабля по заданным
координатам и называется навигационным.
23
Сетевая модель данных
Стандарт сетевой модели впервые был определен в 1975 году организацией
CODASYL (Conference of Data System Languages), которая определила базовые понятия
модели и формальный язык описания.
Базовыми объектами модели являются:
элемент данных;
агрегат данных;
запись;
набор данных.
Элемент данных — то же, что и в иерархической модели, то есть минимальная
информационная единица, доступная пользователю с использованием СУБД.
Агрегат данных соответствует следующему уровню обобщения в модели. В модели
определены агрегаты двух типов: агрегат типа вектор и агрегат типа повторяющаяся
группа.
Агрегат данных имеет имя, и в системе допустимо обращение к агрегату по имени.
Агрегат типа вектор соответствует линейному набору элементов данных. Например,
агрегат Адрес может быть представлен следующим образом:
Адрес
Город
Улица
дом
квартира
Агрегат типа повторяющаяся группа соответствует совокупности векторов
данных. Например, агрегат Зарплата соответствует типу повторяющаяся группа с
числом повторений 12.
Зарплата
Месяц
Сумма
Записью называется совокупность агрегатов или элементов данных, моделирующая
некоторый класс объектов реального мира. Понятие записи соответствует понятию
«сегмент» в иерархической модели. Для записи, так же как и для сегмента, вводятся
понятия типа записи и экземпляра записи. Следующим базовым понятием в сетевой
модели является понятие «Набор». Набором называется двухуровневый граф,
связывающий отношением «один-ко-многим» два типа записи
Набор фактически отражает иерархическую связь
между двумя типами записей. Родительский тип
записи в данном наборе называется владельцем
набора, а дочерний тип записи — членом того же
набора.
Для любых двух типов записей может быть задано любое количество наборов, которые их
связывают. Фактически наличие подобных возможностей позволяет промоделировать
отношение «многие-ко-многим» между двумя объектами реального мира, что выгодно
отличает сетевую модель от иерархической. В рамках набора возможен
последовательный просмотр экземпляров членов набора, связанных с одним экземпляром
владельца набора.
24
Между двумя типами записей может быть определено любое количество наборов:
например, можно построить два взаимосвязанных набора. Существенным ограничением
набора является то, что один и тот же тип записи не может быть одновременно
владельцем и членом набора.
В качестве примера рассмотрим таблицу, на основе которой организуем два набора
и определим связь между ними:
Преподавател
ь
Иванов
Иванов
Карпова
Карпова
Карпова
Смирнов
Смирнов
Группа
4306
4307
4307
4309
84305
4306
4309
День недели
Понедельник
Понедельник
Вторник
Вторник
Вторник
Вторник
Вторник
№ пары
1
2
2
4
1
3
4
Аудитория
22-13
22-13
22-14
22-14
22-14
23-07
23-07
Дисциплина
КИД
КИД
БЗ и ЭС
БЗ и ЭС
БД
ГВП
ГВП
Преподаватель
Ведет занятия
в
группа
Занимается
y
Экземпляров набора Ведет занятия будет 3 (по числу преподавателей) экземпляров
набора Занимается у будет 4 (по числу групп). На рис. 3.6 представлен пример
взаимосвязи экземпляров двух данных наборов.
Среди всех наборов выделяют специальный тип набора, называемый
«Сингулярным набором», владельцем которого формально определена вся система.
Сингулярный набор изображается в виде входящей стрелки, которая имеет собственно
имя набора и имя члена набора, но у которой не определен тин записи «Владелец
набора». Например, сингулярный набор М.
Сингулярные наборы позволяют обеспечить доступ к экземплярам
отдельных типов данных, поэтому если в задаче алгоритм обработки
информации предполагает обеспечение произвольного доступа к
некоторому типу записи, то для поддержки этой возможности
необходимо ввести соответствующий сингулярный набор.
В общем случае сетевая БД представляет совокупность взаимосвязанных наборов, которые образуют на концептуальном уровне некоторый граф.
25
Язык описания данных в сетевой модели
Язык описания данных в сетевой модели имеет несколько разделов:
описание базы данных — области размещения;
описания записей — элементов и агрегатов (каждого в отдельности);
описания наборов (каждого в отдельности).
SCHEMA IS <Имя БД>.
AREA NAME IS <Имя физической области>.
RECORD NAME IS <Имя записи (уникальное)>
Для каждой записи определяется способ размещения экземпляров записи данного типа:
LOCATION MODE IS {DIRECT (напрямую) |
CALC <Имя программы> USING <[Список пер.>]
DUPLICATE ARE [NOT.] ALLOWED
VIA <Имя набора> SET (рядом с записями владельца) SYSTEM
(решать будет система)}
Каждый тип записи должен быть приписан к некоторой физической области размещения:
WITHIN <Имя области размещения-» AREA
После описания записи в целом идет описание внутренней структуры:
<Имя уровня> <Имя данного» <Шаблон> <Тип>
Номер уровня определяет уровень вложенности при описании элементов и агрегатов данных.
Первый уровень — сама запись. Поэтому элементы пли агрегаты данных имеют уровень
начиная со второго. Если данное соответствует агрегату, то любая его составляющая добавляет
один уровень вложенности. Если агрегат является вектором, то он описывается как
<Номер уровня> <Имя агрегата>.<Номер уровня> <Имя 1-й сост.> а если —
повторяющейся группой, то следующим образом:
<Номер уровня> <Имя агрегата>.OCCURS TIMES
где N — среднее количество элементов в группе.
Описание набора и порядка включения членов в него выглядит следующим образом :
SET NAME IS <Имя набора>;
OWNER IS (<Имя владельца> | SYSTEM).
Далее указывается порядок включения новых экземпляров члена данного набора в экземпляр
набора:
ORDER PERMANENT INSERTION IS {SORTED | NEXT | PREV | LAST | FIRST}
После этого описывается член набора с указанием способа включения и способа исключения
экземпляра — члена набора из экземпляра набора.
MEMBER IS <Имя члена набора> {AUTOMATIC I MANUAL) {MANDATORY
OPTIONAL} KEY IS (ACCENDING | DESCENDING) <Имя элемента данных>
|
При автоматическом включении каждый новый экземпляр члена набора автоматически
попадает в текущий экземпляр набора в соответствии с заданным ранее порядком включения.
При ручном способе экземпляр члена набора сначала попадает в БД, а только потом командой
CONNECT может быть включен в конкретный экземпляр набора.
Если задан способ исключения MANDATORY, то экземпляр записи, исключаемый из набора,
автоматически исключается и из базы данных. Иначе просто разрываются связи.
Внешняя модель при сетевой организации данных поддерживается путем описания части
общего связного графа.
26
Язык манипулирования данными в сетевой модели
Все операции манипулирования данными в сетевой модели делятся на навигационные операции
и операции модификации.
Навигационные операции осуществляют перемещение по БД путем прохождения по связям,
которые поддерживаются в схеме БД. В этом случае результатом является новый единичный
объект, который получает статус текущего объекта. Операции модификации осуществляют
как добавление новых экземпляров отдельных типов записей, так и экземпляров новых
наборов, удаление экземпляров записей и наборов, модификацию отдельных составляющих
внутри конкретных экземпляров записей. Средства модификации данных сведены в табл. 3.1:
Таблица 3.1. Операторы манипулирования данными в сетевой модели
Операция
READY
Назначение
Обеспечение доступа данного процесса пли
пользователя к БД (сходна по смыслу с операцией
FINISH
Окончание
работы с БД
открытия файла)
FIND
Группа операций, устанавливающих указатель
наиденного объекта па текущий объект
GET
Передача найденного объекта в рабочую область.
Допустима только после FIND
STORE
Помещение в БД записи, сформированной в рабочей
CONNECT области
Включение текущей записи в текущий экземпляр
DISCONNE набора
Исключение текущей записи из текущего экземпляра
CT
набора
MODIFY
Обновление
текущей записи данными из
рабочей области пользователя
ERASE
\Удаление экземпляра текущей записи
В рабочей области пользователя хранятся шаблоны записей, программные переменные и три
типа указателей текущего состояния:
текущая запись процесса (код или ключ последней записи, с которой работала данная
программа);
текущая запись типа записи (для каждого типа записи ключ последней записи, с которой
работала программа);
текущая запись типа набор (для
каждого набора с владельцем Т1 и членом
Т2 указывается, Т1 или Т2 были последней
обрабатываемой записью).
На рис. 3.7 представлена концептуальная
модель торгово-посреднической
организации.
Рис 3.7. Схема БД «Торговая фирма»
27
При необходимости возможно описание элементов данных, которые не принадлежат
непосредственно данной записи, но при ее обработке часто используются. Для этого
используется тип VIRTUAL с обязательным указанием источника данного элемента данных.
RECORD Цены 02 Цена TYPE REAL 02
Товар VIRTUAL
SOURCE IS Товары.НаименованиеТовара OF OWNER
OF Товар-Цены SET
Наиболее интересна операция поиска (FIND), так как именно она отражает суть навигационных
методов, применяемых в сетевой модели. Всего существует семь типов операций поиска:
1- По ключу (запись должна быть описана через CALC USING ...): .
FIND <Имя записи> RECORD BY CALC KEY <Имя параметра>
2- Последовательный просмотр записей данного типа:
FIND DUPLICATE <Имя записи> RECORD BY CALC KEY
3- Найти владельца текущего экземпляра набора:
FIND OWNER OF CURRENT <Имя набора> SET
Последовательный просмотр записей—членов текущего экземпляра набора:
FIND (FIRST j NEXT) <Имя записи> RECORD IN CURRENT <Имя набора> SET
5.
Просмотр записей—членов экземпляра набора, специфицированных рядом полей:
FIND [DUPLICATE] <Имя записи> RECORD IN CURRENT <Имя набора> SET USING
<Список полей>
6. Сделать текущей записью процесса текущий экземпляр набора:
FIND CURRENT OF <Имя набора> SET
7. Установить текущую запись процесса: FIND
CURRENT OF <Имя записи> RECORD
Например, алгоритм и программа печати заказов,
сделанных Петровым, будут выглядеть так:
ФИО = "Петров"
FIND Люди RECORD BY CALC KEY
FIND FIRST Заказы RECORD IN
CURRENT Люди-Заказы SET WHILE NOT FAIL DO
FIND OWNER OF CURRENT
Товары-Заказы SET GET Товары PRINT НаимТовара
FIND NEXT Заказы RECORD IN
CURRENT Люди-Заказы SET END
28
Реляционная модель данных
Основные определения
Теоретической основой этой модели стала теория отношений, основу которой
заложили два логика — американец Чарльз Содерс Пирс (1839-1914) и немец Эрнст Шредер
(1841-1902).
Известно, что множество отношений замкнуто относительно некоторых специальных
операций, то есть образует вместе с этими операциями абстрактную алгебру.
Это было использовано в реляционной модели для разработки языка манипулирования
данными, связанного с исходной алгеброй.
Американский математик Э. Ф. Кодд в 1970 году впервые сформулировал основные
понятия и ограничения реляционной модели, ограничив набор операции в ней семью
основными и одной дополнительной операцией. (за эту модель он был удостоен престижной
премии Тьюринга в области теоретических основ вычислительной техники).
Основной структурой данных в модели является отношение, именно поэтому модель
получила название реляционной (от английского relation — отношение).
N-арным отношением R называют подмножество декартова произведения D1*D2*…*Dn
множеств D1, D2, Dn (n ≥ 1), необязательно различных. Исходные множества D1, D2, Dn
называют доменами.
R D1*D2*...*Dn,
где D1*D2*…*Dn — полное декартово произведение.
Полное декартово произведение — это набор всевозможных сочетаний из n элементов
каждое, где каждый элемент берется из своего домена.
Например, три домена:
D1= {Иванов, Крылов, Степанов};
D2 = {ТА, БД};
D3 = {3, 4, 5}
Тогда полное декартово произведение содержит набор из 18 троек, где первый элемент —
это одна из фамилий, второй — это название одной из учебных дисциплин, а третий — одна из
оценок:
<Иванов,ТА,3>; ……… <Степанов, БД,5>;
R моделирует реальную ситуацию может содержать, только некоторые строки.
Графическая интерпретация отношения - таблица, столбцы которой соответствуют
вхождениям доменов в отношение, а строки — наборам из n значений, взятых из исходных
доменов, которые расположены в строго определенном порядке в соответствии с заголовком.
Такие наборы из n значений часто называют n-ками.
R
Фамилия
Иванов
…..
Степанов
Дисциплина
ТА
…..
БД
Оценка
4
…..
5
Свойства таблицы:
1. В табл. нет двух одинаковых строк.
2. Табл.имеет столбцы, соответствующие атрибутам отношения.
3. Каждый атрибут в отношении имеет уникальное имя.
4. Порядок строк в таблице произвольный.
29
Вхождение домена в отношение принято называть атрибутом. Строки отношения
называются кортежами.
Количество атрибутов в отношении называется степенью, или рангом, отношения.
в отношении не может быть одинаковых кортежей: отношение — это множество!
Структура данных
Первичный
ключ
FIO
FIO
Job
Year
Job
Chair
Chair
Иванов И.И.
1948
Зав. каф.
22
2
Сидоров С.С.
1953
Проф.
22
3
Гиацинтова Г.Г.
1945
Проф.
22
4
Цветкова С.С.
1960
Доцент
22
5
Козлов К.К.
1959
Доцент
23
6
Петров П.П.
1960
Ст.преп.
23
Кортежи
1
Кардинальность
О
т
н
о
ш
е
н
и
е
PK
Year
Домены
РК
Термины описания структуры таблиц
Формальный термин
Неформальный эквивалент
Отношение
Кортеж
Кардинальность
Атрибут
Степень
Первичный ключ
Домен
Таблица
Строка или запись
Количество строк
Столбец или поле
Количество столбцов
Уникальный идентиф.
Мн-во доп. значений
Атрибуты
Степень
Любое отношение является динамической моделью некоторого реального объекта
внешнего мира. Поэтому вводится понятие экземпляра отношения, которое отражает состояние
данного объекта в текущий момент времени, и понятие схемы отношения, которая определяет
структуру отношения.
Схемой отношения R называется перечень имен атрибутов данного отношения с указанием
домена, к которому они относятся:
SR = (А1, А2, …, Аn), Аi : Di.
Если атрибуты принимают значения из одного и того же домена, то они называются сравнимыми, где — множество допустимых операций сравнения, заданных для данного
домена. Например, если домен содержит числовые данные, то для него допустимы все
операции сравнения, тогда = {=, <>,>=,<=,<,>}. Однако и для доменов, содержащих
символьные данные, могут быть заданы не только операции сравнения по равенству и
неравенству значений. Если для данного Домена задано лексикографическое упорядочение, то
он имеет также полный спектр операций сравнения.
Схемы двух отношений называются эквивалентными, если они имеют одинаковую
степень и возможно такое упорядочение имен атрибутов в схемах, что на одинаковых местах
будут находиться сравнимые атрибуты, то есть атрибуты, принимающие значения из одного
домена.
SR1 = (A1, A2, .... An) — схема отношения R1
SR2 = (Bi1, Bi2, …, Bin) — схема отношения R2 после упорядочения имен атрибутов.
Как уже говорилось ранее, реляционная модель представляет базу данных в виде
множества взаимосвязанных отношений. В отличие от теоретико-графовых моделей в
реляционной модели связи между отношениями поддерживаются неявным образом. В каждой
связи одно отношение может выступать как основное, а другое отношение выступает в
роли подчиненного. Оба отношения должны содержать наборы атрибутов, по которым они
связаны. В основном отношении это первичный ключ отношения PRIMARY KEY однозначно определяет кортеж основного отношения. В подчиненном отношении – внешний
ключ FOREIGN KEY (набор атрибутов, соответствующий первичному ключу основного
отношения).
30
Операции над отношениями. Реляционная алгебра
Алгеброй называется множество объектов с заданной на нем совокупностью
операций, замкнутых относительно этого множества, называемого основным
множеством.
Основной объект реляционной алгебры - отношение. Всего Э. Ф. Коддом было
предложено 8 операций. (множество избыточное, одни операции могут быть представлены
через другие, но!!! максимально удобное при реализации произвольных запросов к БД.
Множество операций делят на две группы: теоретико-множественные операции(4) и
специальные операции(4).
Теоретико-множественные операции реляционной алгебры
Объединением двух отношений называется отношение, содержащее множество
кортежей, принадлежащих либо первому, либо второму исходным отношениям, либо обоим
отношениям одновременно.
Пусть заданы два отношения R1 = { r1 } , R2 = { r2 }, где r1 и r2 — их соответственные
кортежи, то объединение R1 U R2 = { r | r R1 r R2 }. Здесь r — кортеж нового отношения,
— операция логического сложения «ИЛИ».
Пересечением отношений называется отношение, которое содержит множество
кортежей, принадлежащих одновременно и первому и второму отношениям R1 и R2:
R3 = R1 R2 ={ r | r R1 r R2 },
здесь — операция логического умножения (логическое «И»).
Разностью отношений R1 и R2называется отношение, содержащее множество кортежей,
принадлежащих R1и не принадлежащих R2:
R5 = R1 \ R2 = { r | r R1 r R2 }
Следует отметить, что первые две операции, объединение и пересечение, являются
коммутативными операциями, то есть результат операции не зависит от порядка аргументов
в операции.
Операция же разности является принципиально несимметричной операцией, то есть
результат операции будет различным для разного порядка аргументов.
Демонстрацию возможностей трех первых операций реляционной алгебры рассмотрим на
практике.
Операции объединения, пересечения и разности применимы только к отношениям с
эквивалентными схемами.
Кроме перечисленных трех теоретико-множественных операций в рамках реляционной
алгебры определена еще одна теоретико-множественная операция — расширенное декартово
произведение. Эта операция не накладывает никаких дополнительных условий на схемы
исходных отношений, поэтому операция расширенного декартова произведения, обозначаемая
R1 R2, допустима для любых двух отношений. Но прежде чем определить саму операцию,
введем дополнительно понятие конкатенации, или сцепления, кортежей.
Сцеплением, или конкатенацией, кортежей с = и q =
называется кортеж, полученный добавлением значений второго в конец первого. Сцепление
кортежей с и q обозначается как (с , q).
(с, q) = <с1 с2, ... , cn, q1, q2, ... qm>,
Здесь n — число элементов в первом кортеже с, m — число элементов во втором кортеже q.
Все предыдущие операции не меняли степени или арности отношений — это следует из
определения эквивалентности схем отношений. Операция декартова произведения меняет
степень результирующего отношения.
31
Расширенным декартовым произведением
отношения R1 = { r } степени n со схемой SR1 = (А1, А2, ... , Аn) и
отношения R2 = { q } степени m со схемой SR2 = (В1, В2, ... , Вn)
называется отношение R3 степени n+m со схемой
SR3 = (А1 А2, ... , Аn, В1 В2, ..., Вn),
содержащее кортежи, полученные сцеплением каждого кортежа r отношения R1 с каждым
кортежем q отношения R2.
То есть R1 R2 = {(r, q) | r R1 ^ q R2}
Операцию декартова произведения с учетом возможности перестановки атрибутов в
отношении можно считать симметричной. Она используется для получения универсума —
отношения, которое характеризует все возможные комбинации между элементами отдельных
множеств. Однако самостоятельного значения этот результат обычно не имеет, он участвует в
дальнейшей обработке. Получаются очень «большие» отношения. Используют для ситуации,
которая х-ся словом «все».
Группа теоретико-множественных операций избыточна, практически все сложные операции
можно записать разными способами.
Специальные операции реляционной алгебры
Горизонтальный выбор, или операция фильтрации, или операция ограничения
отношений. Для ее определения необходимо ввести дополнительные обозначения.
Пусть α — булевское выражение, составленное из термов сравнения с помощью связок
И (), ИЛИ (), НЕ (-) и, возможно, скобок. В качестве термов допускаются:
а) терм А ос а,
где А — имя некоторого атрибута, принимающего значения из домена D;
а — константа, взятая из того же домена D, a D;
ос — одна из допустимых для данного домена D операций сравнения;
б) терм А ос В,
где А, В — имена некоторых -сравнимых атрибутов,
то есть атрибутов, принимающих значения из
одного и то же домена D.
Тогда результатом операции фильтрации, заданной на отношении R в виде булевского
выражения, определенного на атрибутах отношения R, называется отношение R[α (r)],
включающее те кортежи из исходного отношения, для которых истинно условие выбора или
фильтрации:
R[α (r)] = {r|r R α (r) = "true"}
Условие α может быть сколь угодно сложным.
Операция проецирования.
Проекцией отношения R на набор атрибутов В, называется отношение со схемой,
соответствующей набору атрибутов В SR[B] = В, содержащему кортежи, получаемые из
кортежей исходного отношения R путем удаления из них значений, не принадлежащих
атрибутам из набора В.
R[B] = {r[B]}
Пусть R = { r } — отношение, со схемой SR = (A1 … , An),
Пусть В подмножество { Ai }; В { Ai }.
При этом пусть В’ — множество атрибутов из { Аi }, не вошедших в В.
1
2
k
’
1
2
m
Если В = {A i , A i ,…,A i }, B = {А j , А j ,..., А j } и
s = ; aki Aki ; q = < a1j, a2j, ... , amj > ; amj Amj
то r[B] = s, причем r=(s,q)
По определению все дублирующие кортежи удаляются из результирующего отношения.
32
Операция условного соединения (бинарная операция)
В отличие от рассмотренных специальных операций реляционной алгебры:
фильтрации и проектирования, которые являются унарными, то есть производятся над
одним отношением, операция условного соединения является бинарной, то есть исходными
для нее являются два отношения, а результатом — одно.
Это одна из важных операций рел.алгебры. Она имеет большое практическое значение. На
самом деле выделяют несколько ее разновидностей, которые мы рассмотри дальше.
Операцию соединения можно рассматривать как декартово произведение с последующей
операцией выборки.
Общий подход:
Пусть R = {r}, Q = {q} — исходные отношения, со схемами SR, SQ.
SR=(A1, A2, … ,Am); SQ = (B1 B2, ... , Bn), где Аi , Bj — имена атрибутов .
Заданы наборы -сравнимых атрибутов А и В A { Ai }; B { Bj }, i,j=1,k (!!!)
Соединение отношений R и Q при условии это подмножество декартова произведения
отношений RQ, кортежи которого удовлетворяют условию .
R[ ]Q = { (r,q) | r.Ai q.Bi = «Истина», i=1,k}
Существуют различные типы операций соединения:
тета-соединение R►◄FQ;
соединение по эквивалентности R►◄=Q;
естественное соединение R►◄Q;
внешнее соединение R ◄Q; R► Q;
полусоединение R►FQ.
Операция тета-соединения R►◄FQ определяет отношение, которое содержит кортежи из
декартова произведения отношений RQ, удовлетворяющие предикату F. Предикат F имеет
вид R.ai Θ Q.bj, где вместо Θ может быть указан один из операторов сравнения (>, >=, <, <=, =,
<>).
Если предикат F содержит только оператор равенства (=), то соединение называется
соединением по эквивалентности
Соединение A1 B1 B1 C1 A1 B1 C1 R►◄=Q.
FIO
Job
Chair
Иванов И.И.
Зав. каф.
22
Сидоров С.С.
A2
B1
B2
C1
A2
B1
C1
A3
B3
B3
C3
A3
B2
C2
Проф.
22
ГиацинтоваГ. Проф.
Г
22
Цветкова С.С. Доцент
23
Иванов И.И.
Зав. каф.
22
3000
Козлов К.К.
Доцент
23
Сидоров С.С.
Проф.
22
2500
Петров П.П.
Ст.преп.
24
22
2500
Лютикова
Л.Л.
Ассистент 24
ГиацинтоваГ. Проф.
Г
Цветкова С.С. Доцент
23
2000
3000
Козлов К.К.
Доцент
23
2000
2500
Петров П.П.
Ст.преп.
24
1500
Доцент
2000
Ассистент 24
1200
Ст.преп.
1500
Лютикова
Л.Л.
Job
Зав. каф.
Проф.
FIO
Pay
Ассистент 1200
Job
Chair
Pay
Естественным соединением R►◄Q
называется
соединение
по
эквивалентности двух отношений R
и Q, выполненное по всем общим
атрибутам, из результатов которого
исключается по одному экземпляру
каждого общего атрибута
Левым внешним соединением R
◄Q называется соединение, при
котором кортежи отношения R, не
имеющие совпадающих значений в
общих столбцах отношения Q, также
включаются в результирующее
отношение.
Правое внешнее соединение R► Q, в результирующем отношении содержатся все кортежи
правого отношения Q.
33
Имеется и полное внешнее соединение R ◄Q; R► Q;, в его результирующее отношение
помещаются все кортежи из обоих отношений, а для обозначения несовпадающих значений
кортежей в нем используются определители NULL.
Операция полусоединения определяет отношение, содержащее те кортежи отношения R,
которые входят в соединение отношений R и Q.
Последней операцией, включаемой в набор операций РА, является операция деления.
Для ее определения рассмотрим сначала понятие множества образов.
Пусть R — отношение со схемой SR = (А1 А2 ,..., Аk);
А —набор атрибутов А { Ai } i=1,k;
A1 — набор атрибутов, не входящих в множество А,
причем, АА1 = ;: AА1 = SR.
Тогда множеством образов у элемента х проекции R[A] называется множество таких элементов
у проекции R[A1], для которых сцепление (x, у) является кортежами отношения R, то есть
Q R[A1] = {у | у R[A1] ^ (х, у) R} - множество образов.
Дадим теперь определение операции деления.
Пусть даны два отношения R(делимое) и Т(делитель) соответственно со схемами:
SR = (А1 А2, ... , Ak); ST = (В2 В2, ... , Вm);
А и В — наборы атрибутов этих отношений, одинаковой длины (без повторений);
А SR ; В ST.
Атрибуты А1 — это атрибуты из R, не вошедшие в множество А.
АА1 = и AА1 = SR. Проекции R[A] и Т[В] совместимы по объединению, то есть имеют
эквивалентные схемы: SR[A] ST[B]
Операция деления ставит в соответствие отношениям R и Т отношение Q = R[А:В]Т, кортежи
которого являются теми элементами проекции R[A1], для которых Т[В] входит в построенные
для них множество образов:
R[A:B]T = {r | r R[A1] ^T[B] {у | у R [А1] (x, у) R } }.
Операция деления удобна тогда, когда требуется сравнить некоторое множество характеристик
отдельных атрибутов.
Другими словами!!!
R (делимое)
(A1)Job
(A2)Chair
Зав.каф. 22
Проф.
22
Доц.
22
Зав.каф. 23
Доц.
23
Ст.преп. 24
ассист
24
T (делитель)
(B)Chair
22
Частное
(C)Job
Зав.каф.
Проф.
Доц.
22
23
Зав.каф.
Доц
Результат операции деления R:T - набор кортежей отношения R, определенных на множестве
атрибутов C, которые соответствуют комбинации всех кортежей отношения T.
R определено на множестве атрибутов A, а отношение T - на множестве атрибутов B,
причем B A и C=A – B.
T1=R[C]; (Зав.каф.,Проф.,Доц.,Ст.преп.,ассист)
T2=((TT1)-R)[C]; (Ст.преп. 22,ассист 22)
R[А:В]Т = T1 - T2. (Зав.каф.,Проф.,Доц)
34
Язык SQL.
История развития SQL
SQL {Structured Query Language) — Структурированный Язык Запросов — стандартный
язык запросов по работе с реляционными БД. Язык SQL появился после реляционной алгебры,
и его прототип был разработан в конце 70-х годов в компании IBM Research. Он был
реализован в первом прототипе реляционной СУБД фирмы IBM System R. В дальнейшем этот
язык применялся во многих коммерческих СУБД и в силу своего широкого распространения
постепенно стал стандартом «де-факто» для языков манипулирования данными в реляционных
СУБД.
Первый международный стандарт языка SQL был принят в 1989 г. (SQL/89 или
SQL1). Иногда стандарт SQL1 также называют стандартом ANSI/ISO, и подавляющее
большинство доступных на рынке СУБД поддерживают этот стандарт полностью. Однако
развитие информационных технологий, связанных с базами данных, и необходимость реализации переносимых
приложений потребовали в скором времени доработки и расширения первого стандарта SQL.
В конце 1992 г. был принят новый международный стандарт языка SQL, который в
дальнейшим будем называть SQL/92 или SQL2. И он не лишен недостатков, но в то же время
является существенно более точным и полным, чем SQL/89. В настоящий момент большинство
производителей СУБД внесли изменения в свои продукты так, чтобы они в большей степени
удовлетворяли стандарту SQL2.
В 1999 г. появился новый стандарт, названный SQL3. Имеет серьезные качественные
преобразования. (Введены новые структурированные типы данных, соответств.объектной
ориентации. Добавлен стандарт на события и триггеры. В рамках управления транзакциями
произошел возврат к старой модели транзакций, допускающей точки сохранения (savepoints), и
возможность указания в операторе отката ROOLBACK точек возврата позволит откатывать транзакцию не в
начало, а в промежуточную ранее сохраненную точку.
SQL нельзя, в полной мере, отнести к традиционным языкам программирования. Он не
содержит традиционные операторы, управляющие ходом выполнения программы, операторы
описания типов и многое другое. Он содержит только набор стандартных операторов доступа к
данным, хранящимся в базе данных. Операторы SQL встраиваются в базовый язык программирования,
которым может быть любой стандартный язык типа C++, PL, COBOL и т. д. Кроме того, операторы SQL могут
выполняться непосредственно в интерактивном режиме .
Основные объекты реляционной базы данных
Рассмотрим основные объекты РБД
Tables Отношения (таблицы) базы данных, в которых хранятся собственно данные. Имеют
структуру, ограничения на типы данных и связи между таблицами.
Views Просмотры (виртуальные таблицы) для отображения данных из таблиц, содержимое
которых определяется запросом. Информация, которую видит пользователь через представление, не
сохраняется в базе данных как самостоятельный объект.
Indexes Индексы – дополнительные структуры(таблицы), создаваемые для повышения
производительности работы с данными.
Индекс определяется для одного или нескольких
столбцов(индексированные столбцы). Он содержит отсортированные значения индексированных
столбцов со ссылками на соответствующую строку исходной таблицы или представления. Повышение
производительности достигается за счет сортировки данных. Использование индексов может существенно
повысить производительность поиска, однако для хранения индексов необходимо дополнительное пространство в
базе данных.
Constraints
Ограничение целостности – объекты для обеспечения логической целостности
данных – механизм, обеспечивающий автоматический контроль соответствия данных установленным
условиям (или ограничениям). Ограничения целостности имеют приоритет над триггерами, правилами и
значениями по умолчанию. К ограничениям целостности относятся: ограничение на значение NULL,
35
проверочные ограничения, ограничение уникальности (уникальный ключ), ограничение первичного
ключа и ограничение внешнего ключа. Последние три ограничения тесно связаны с понятием ключей
Keys
Ключи – один из видов ограничений целостности данных
Stored Procedures
Хранимые процедуры представляют собой группу команд SQL,
объединенных в один модуль. Такая группа команд компилируется и выполняется как единое целое.
Triggers Триггеры – специальные хранимые процедуры, вызываемые автоматически при
изменении данных в таблице(при добавлении, изменении или удалении данных из таблицы)
Sequence – генераторы последовательностей чисел
User Defined function Создаваемые пользователем функции. Функции в языках
программирования – это конструкции, содержащие часто исполняемый код. Функция выполняет какиелибо действия над данными и возвращает некоторое значение.
User Defined Data Types
Пользовательские типы данных - это типы данных, которые
создает пользователь на основе системных типов данных, когда в нескольких таблицах необходимо
хранить однотипные значения; причем нужно гарантировать, что столбцы в таблице будут иметь
одинаковый размер, тип данных и чувствительность к значениям NULL.
Users
Пользователи, обладающие доступом к базе данных
Roles
Роли, позволяющие объединять пользователей в группы
Rules
Правила базы данных, позволяющие контролировать логическую целостность данных.
Правила используются для ограничения значений, хранимых в столбце таблицы или в пользовательском
типе данных. Они существуют как самостоятельные объекты базы данных, которые связываются со
столбцами таблиц и пользовательскими типами данных. Контроль значений данных может быть
реализован и с помощью ограничений целостности
Defaults Умолчания или стандартные установки базы данных - самостоятельный объект базы
данных, представляющий значение, которое будет присвоено элементу таблицы при вставке строки,
если в команде вставки явно не указано значение для этого столбца
Структура SQL
В отличие от реляционной алгебры, где были представлены только операции запросов к
БД, SQL является полным языком, в нем присутствуют не только операции запросов, но и
операторы, соответствующие языку описания данных. Кроме того, язык содержит операторы,
предназначенные для управления (администрирования) БД.
1. Операторы определения данных -Data Definition Language- DDL
CREATE, ALTER, DROP
Например
Оператор
Смысл
Действие
CREATE VIEW
Создать представление
ALTER TABLE
Изменить таблицу
DROP INDEX
Удалить индекс
Создает виртуальную таблицу, соответствующую
некоторому SQL-запросу
Изменяет структуру существующей таблицы или
ограничения целостности, задаваемые для данной таблицы
Удаляет ранее созданный индекс
2. Операторы манипулирования данными- Data Manipulation Language –DML
DELETE, INSERT, UPDATE
Оператор Смысл Действие
DELETE Удалить Удаляет одну или несколько строк, соответствующих условиям фильтрации, из
строки
INSERT
UPDATE
базовой таблицы. Применение оператора согласуется с принципами поддержки
целостности, поэтому этот оператор не всегда может быть выполнен корректно,
даже если синтаксически он записан правильно
Вставить Вставляет одну строку в базовую таблицу. Допустимы модификации оператора,
строку
при которых сразу несколько строк могут быть перенесены из одной таблицы или
запроса в базовую таблицу
Обновить Обновляет значения одного или нескольких столбцов в одной или нескольких
строку
строках, соответствующих условиям фильтрации
36
3. Язык запросов Data Query Language (DQL)
Оператор
SELECT
Смысл
Действие
Выбрать строки
Оператор, заменяющий все операторы реляц.алгебры и позволяющий сформировать результ.отношение, соответств.запросу
4. Средства управления транзакциями
Оператор
COMMIT
Смысл
ROLLBACK
SAVEPOINT
Действие
Завершить
Завершить комплексную взаимосвязанную обработку
транзакцию
информации, объединенную в транзакцию
Откатить транзакцию Отменить изменения, проведенные в ходе выполнения
транзакции
Сохранить промеж.
Сохранить промежуточное состояние БД, пометить его для
тчк.. вып-я транзакции того, чтобы можно было в дальнейшем к нему вернуться
5. Средства администрирования данных
Оператор
Смысл
ALTER DATABASE Изменить БД
Действие
Изменить область
хранения БД
ALTER PASSWORD Изменить пароль
ALTER DBAREA
CREATE
DATABASE
CREATE DBAREA
DROP DATABASE
Создать БД
Создать область
хранения
Удалить БД
Изменить набор основных объектов в базе
данных, ограничений, касающихся всей базы
данных
Изменить ранее созданную область хранения
Изменить пароль для всей базы данных
Создать новую базу данных, определив
основные параметры для нее
Создать новую область хранения и сделать ее
доступной для размещения данных
Удалить существующую базу
GRANT
Удалить область
хранения БД
Предоставить права
Удалить существующую область хранения (если
в ней на наст.момент нет активных данные)
Предоставить права доступа на ряд действий
над некоторым объектом БД
REVOKE
Лишить прав
Лишить прав доступа к некоторому объекту или
некоторым действиям над объектом
DROP DBAREA
6.
Программный SQL
Оператор Смысл
DECLARE Определяет курсор для
запроса
OPEN
Открыть курсор
FETCH
Считать строку из мн-ва
строк, опред. курсором
Действие
Задает имя и определяет связанный с ним запрос к БД,
который соответствует виртуал. набору данных (ВНД)
Формирует ВНД, соответствующий описанию
указанного курсора и текущему состоянию БД
Считывает очередную строку, заданную параметром
команды из ВНД, соответствующего открытому курсору
Прекращает доступ к ВНД, соотв.указанному курсору
CLOSE
Закрыть курсор
PREPARE Подготовить оператор Сгенерировать план выполнения запроса,
SQL к динамическому соответствующего заданному оператору SQL
выполнению
EXECUTE Выполнить оператор SQL, ранее подгот. к Выполняет ранее подготовленный
динамическому выполнению
план запроса
В коммерческих СУБД набор основных операторов расширен. В большинство СУБД включены
операторы определения и запуска хранимых процедур и операторы определения триггеров.
37
Типы данных
В языке SQL/89 поддерживаются следующие основные типы данных:
CHARACTER(n) или CHAR(n) — символьные строки постоянной длины в n символов.
При задании данного типа под каждое значение всегда отводится n символов, и если реальное
значение занимает менее, чем n символов, то СУБД автоматически дополняет недостающие
символы пробелами.
NUMERIC[(n,m)] — точные числа, здесь n — общее количество цифр в числе, m —
количество цифр слева от десятичной точки.
DECIMAL[(n,m)] или DEC[(n,m)] — точные числа, здесь n — общее количество цифр в
числе, m — количество цифр слева от десятичной точки.
INTEGER или INT — целые числа.
REAL — вещественный тип чисел, который соответствует числам с плавающей точкой
DOUBLE PRECISION специфицирует тип данных с определенной в реализации
точностью большей, чем определенная в реализации, точность для REAL.
В стандарте SQL92 добавлены следующие типы данных:
VARCHAR(n) — строки символов переменной длины.
NCHAR(N) — строки локализованных символов постоянной длины.
NCHAR VARYING(n) — строки локализованных символов переменной длины.
ВIТ(n) — строка битов постоянной длины.
BIT VARYING(n) — строка битов переменной длины.
DATE — календарная дата.
ТIМЕSTАМР (точность) — дата и время.
INTERVAL — временной интервал.
Большинство коммерческих СУБД поддерживают еще дополнительные типы данных,
которые
не
специфицированы
в
стандарте.
Например,
для
представления
неструктурированного текста большого объема (аналогичен типу MEMO в настольных СУБД).
Могут использоваться константы заданных типов.
Для числовых типов данных:
213-314
612.716,
+ 551.702,
2.9Е-4
-134.235Е7
0.54267Е18
Строковые константы в одинарных кавычках: 'Крылов Ю.Д.’ 'Санкт-Петербург'
Константы даты, времени и временного интервала в реляционных СУБД
представляются в виде строковых констант. Форматы констант отличаются в различных СУБД
В стандарте SQL1 не были определены встроенные функции, однако в большинстве
коммерческих СУБД такие функции были реализованы, и в стандарт SQL2 уже введен ряд
стандартных встроенных функций (приведены только некоторые!)
CURRENT_DATE - текущая дата;
CURRENT_TIME(точность) — текущее время с указанной точностью;
LOWER(строкa) — строка, преобразованная к нижнему регистру;
SUBSTRING(строка FROM n FOR длина) — часть строки, начинающаяся с n-го символа и
имеющая указанную длину;
TRANSLАТЕ(строка USING функция) — строка, преобразованная с использованием,
указанной функции;
UPPER(строка) — строка, преобразованная к верхнему регистру.
И т.д. – самостоятельно в документации
38
Оператор выбора SELECT
Язык запросов (Data Query Language) в SQL состоит из единственного оператора SELECT. Этот
единственный оператор поиска реализует все операции реляционной алгебры.
Синтаксис оператора SELECT имеет следующий вид:
SELECT [ALL | DISTINCT ]
*|имя_столбца [AS
новое_имя] [,...n]
FROM имя_таблицы [[AS] псевдоним] [,...n]
[WHERE <условие_поиска>]
[GROUP BY имя_столбца [,...n]]
[HAVING <критерии выбора групп>]
[ORDER BY имя_столбца [,...n]]
Здесь ключевое слово ALL означает, что в результирующий набор строк включаются все
строки, удовлетворяющие условиям запроса.
Ключевое слово DISTINCT означает, что в результирующий набор включаются только
различные строки, то есть дубликаты строк результата не включаются в набор.
Символ *. (звездочка) означает, что в результирующий набор включаются все столбцы из
исходных таблиц запроса.
В разделе FROM задается перечень исходных отношений (таблиц) запроса.
В разделе WHERE задаются условия отбора строк результата или условия
соединения кортежей исходных таблиц, подобно операции условного соединения в
реляционной алгебре.
В разделе GROUP BY задается список полей группировки.
В разделе HAVING задаются предикаты-условия, накладываемое на каждую группу.
В части ORDER BY задается список полей упорядочения результата.
В выражении условий раздела WHERE м.быть использованы следующие предикаты:
Предикаты сравнения {
=, <>, >,<, >=,<=}, которые имеют традиционный смысл.
Предикат Between A and В — принимает значения между А и В. Предикат истинен,
когда сравниваемое значение попадает в заданный диапазон, включая границы
диапазона. В стандарте задан и противоположный предикат Not Between A and В,
который истинен тогда, когда сравниваемое значение не попадает в заданный интервал,
включая его границы.
Предикат вхождения в множество IN (множество) истинен тогда, когда сравниваемое
значение входит в множество заданных значений. При этом множество значений может
быть задано простым перечислением или встроенным подзапросом. Существует
противоположный предикат NOT IN (множество).
Предикаты сравнения с образцом LIKE и NOT LIKE. Предикат LIKE требует задания
шаблона, с которым сравнивается заданное значение, предикат истинен, если
сравниваемое значение соответствует шаблону, и ложен в противном случае. Предикат
NOT LIKE имеет противоположный смысл.
По стандарту в шаблон могут быть включены специальные символы:
символ подчеркивания (_) — для обозначения любого одиночного символа;
символ процента (%) — для обозначения любой произвольной последовательности
символов;
остальные символы, заданные в шаблоне, обозначают самих себя.
39
□ Предикат сравнения с неопределенным значением IS NULL. Понятие неопределенного
значения было внесено в концепции баз данных позднее. Неопределенное значение
интерпретируется в реляционной модели как значение, неизвестное на данный момент
времени.. При сравнении неопределенных значений не действуют стандартные правила
сравнения: одно неопределенное значение никогда не считается равным другому
неопределенному значению. Для выявления равенства значения некоторого атрибута
неопределенному применяют специальные стандартные предикаты:
<имя атрибута>IS NULL и
<имя атрибута> IS NOT NULL.
Если в данной строке указанный атрибут имеет неопределенное значение, то предикат
IS NULL принимает значение «Истина» (TRUE), а предикат IS NOT NULL — «Ложь» (FALSE),
в противном случае предикат IS NULL принимает значение «Ложь», а предикат IS NOT NULL
принимает значение «Истина».
Введение Null-значений вызвало необходимость модификации классической двузначной
логики и превращения ее в трехзначную. Все логические операции, производимые с
неопределенными значениями, подчиняются этой логике в соответствии с заданной таблицей
истинности:
Таблица истинности
А
В
Not A
А^В
AvB
TRUE
TRUE
FALSE
TRUE
TRUE
TRUE
FALSE
FALSE
FALSE
TRUE
TRUE
Null
FALSE
Null
TRUE
FALSE
TRUE
TRUE
FALSE
TRUE
FALSE
FALSE
TRUE
FALSE
FALSE
FALSE
Null
TRUE
FALSE
Null
Null
TRUE
Null
Null
TRUE
Null
FALSE
Null
FALSE
Null
Null
Null
Null
Null
Null
□ Предикаты существования EXIST и несуществования NOT EXIST. Эти предикаты относятся
к встроенным подзапросам, и подробнее мы рассмотрим их, когда коснемся вложенных
подзапросов.
Применение агрегатных функций и вложенных запросов в SELECT
В SQL добавлены дополнительные функции, которые позволяют вычислять
обобщенные групповые значения. Для применения агрегатных функций предполагается
предварительная операция группировки. При группировке все множество кортежей отношения
разбивается на группы, в которых собираются кортежи, имеющие одинаковые значения
атрибутов, которые заданы в списке группировки.
Агрегатные функции вычисляют одиночное значение для всей группы таблицы!!!
Агрегатные функции
Таблица
Функция
Результат
COUNT
Кол-во строк пли непустых значений полей, которые выбрал запрос
SUM
Сумма всех выбранных значений данного поля
AVG
Среднеарифм.-е значение всех выбранных значений данного поля
MIN
Наименьшее из всех выбранных значений данного поля
MAX
Наибольшее из всех выбранных значений данного поля
40
Агрегатные функции используются подобно именам полей в операторе SELECT, но с
одним исключением: они берут имя поля как аргумент. С функциями SUM и AVG могут
использоваться только числовые поля. С функциями COUNT, MAX и MIN могут
использоваться как числовые, так и символьные поля.
!!!
Нельзя использовать агрегатные функции в предложении WHERE, потому что
предикаты оцениваются в терминах одиночной строки, а агрегатные функции — в терминах
групп строк.
Предложение GROUP BY позволяет определять подмножество значений в особом поле в
терминах другого поля и применять функцию агрегата к подмножеству. Это дает возможность
объединять поля и агрегатные функции в едином предложении SELECT. Агрегатные функции
могут применяться как в выражении вывода результатов строки SELECT, так и в выражении
условия обработки сформированных групп HAVING. В этом случае каждая агрегатная
функция вычисляется для каждой выделенной группы.
Вложенные запросы
С помощью SQL можно вкладывать запросы внутрь друг друга. Обычно внутренний
запрос генерирует значение, которое проверяется в предикате внешнего запроса (в
предложении WHERE или HAVING), определяющего, верно оно или нет. Совместно с
подзапросом можно использовать предикат EXISTS, который возвращает истину, если вывод
подзапроса не пуст.
Предикат EXISTS (SubQuery) истинен, когда подзапрос SubQuery не пуст, то есть
содержит хотя бы один кортеж, в противном случае предикат EXISTS ложен.
Предикат NOT EXISTS обратно — истинен только тогда, когда подзапрос SubQuery пуст.
В стандарте SQL92 операторы сравнения расширены до многократных сравнений с
использованием ключевых слов ANY и ALL. Это расширение используется при сравнении
значения определенного столбца со столбцом данных, возвращаемым вложенным запросом.
ANY в любом предикате сравнения, означает, что предикат будет истинен, если хотя бы
для одного значения из подзапроса предикат сравнения истинен.
ALL требует, чтобы
предикат сравнения был бы истинен при сравнении со всеми строками подзапроса.
Внешние соединения
Стандарт SQL2 расширил понятие условного соединения. В SQL1 при соединении
отношений использовались только условия, задаваемые в части WHERE оператора SELECT, и
в этом случае в результирующее отношение попадали только сцепленные по заданным
условиям кортежи исходных отношений, для которых эти условия были определены и
истинны. Однако часто необходимо содинять таблицы таким образом, чтобы в результат
попали все строки из первой таблицы, а вместо тех строк второй таблицы, для которых не
выполнено условие соединения, в результат попадали бы неопределенные значения. Или
наоборот.
Такие объединения были названы внешними в противоположность соединениям,
определенным стандартом SQL1, которые стали называться внутренними.
В общем случае синтаксис части FROM в стандарте SQL2 выглядит следующим образом:
FROM <список исходных табл> |
< выражение естественного соединения > | выражение соединения > |
< выражение перекрестного соединения > | выражение запроса на соединение>
<выражение естественного соединения:: =
<имя_табл1> NATURAL {INNER | FULL [OUTER] |
LEFT [OUTER] | RIGHT [OUTER]} JOIN <имя_табл_2>
<выражение перекрестного объединения>:: =
<имя табл_1>CROSS JOIN <имя табл_2>
41
<выражение запроса на соединение>::=
<имя_табл_1> UNION JOIN <имя_табл_2>
<выражение соединения>::= <имя_табл_1>
{INNER |FULL [OUTER] | LEFT [OUTER] | RIGHT [OUTER]}
JOIN (ON условие | [USING (список столбцов)]} <имя_табл_2>
В этих определениях INNER — означает внутреннее объединение, LEFT — левое
объединение, то есть в результат входят все строки таблицы 1, а части результирующих
кортежей, для которых не было соответствующих значений в таблице 2, дополняются
значениями NULL (не определено). Ключевое слово RIGHT означает правое внешнее
объединение, и в отличие от левого объединения в этом случае в результирующее отношение
включаются все строки таблицы 2, а недостающие части из таблицы 1 дополняются
неопределенными значениями, Ключевое слово FULL определяет полное внешнее
объединение: и левое и правое. При полном внешнем объединении выполняются и правое и
левое внешние объединения ив результирующее отношение включаются все строки из таблицы
1, дополненные неопределенными значениями, и все строки из таблицы 2, также дополненные
неопределенными значениями.
Ключевое слово OUTER означает внешнее, но если заданы ключевые слова FULL, LEFT,
RIGHT, то объединение всегда считается внешним.
Операторы манипулирования данными
Все операторы манипулирования данными позволяют изменить данные только в одной табл.
Оператор ввода данных INSERT имеет следующий синтаксис:.
INSERT INTO имя_таблицы [(<список столбцов>) ] VALUES (<список значений>)
Подобный синтаксис позволяет ввести только одну строку в таблицу. Задание списка
столбцов необязательно тогда, когда мы вводим строку с заданием значений всех столбцов.
В набор значений могут быть включены специальные функции и выражения.
Ограничением здесь является то, что значения этих функций должны быть определены на
момент ввода данных.
Оператор удаления данных позволяет удалить одну или несколько строк из таблицы в
соответствии с условиями, которые задаются для удаляемых строк. Синтаксис DELETE:
DELETE FROM имя_таблицы [WHERE условия_отбора]
Если условия отбора не задаются, то из таблицы удаляются все строки, однако это не
означает, что удаляется вся таблица. Исходная таблица остается, но она остается пустой,
незаполненной.
Условия отбора в части WHERE имеют тот же вид, что и условия фильтрации в
операторе SELECT. Эти условия определяют, какие строки из исходного отношения будут
удалены.
В части WHERE может находиться встроенный запрос.
Операции манипулирования данными не всегда выполнимы, даже если синтаксически они
написаны правильно. (Ограничения целостности!!!)
Операция обновления данных UPDATE требуется тогда, когда происходят изменения во
внешнем мире и их надо адекватно отразить в базе данных
UPDATE имя_табл SET имя_столбца= <выражение>[,...n]
[WHERE <услов_отбора>]
Операция модификации, так же как и операция удаления, может использовать сложные
подзапросы.
……………………………………………………………….
ВСЕ ОСТАЛЬНЫЕ ОПЕРАТОРЫ РАССМАТРИВАЮТСЯ
НА ПРАКТИЧЕСКИХ ХАНЯТИЯХ
42
43