Базы данных

Дисциплина «Базы данных» МТУСИ (15.03.04 – заочники), 2016 – 2017 уч. год Номер 1-2 Лекции (тема) Введение История развития баз данных. Основные понятия и определения. Архитектура БД. Физическая и логическая независимость. Процесс прохождения пользовательского запроса. Классификация моделей данных. 3-4 Теоретико-графовые модели данных. Иерархическая модель данных. Язык описания данных иерархической модели. Внешние модели. Язык манипулирования данными в иерархических базах данных. Операторы поиска данных в т.ч. с возможностью модификации. Операторы модификации данных. 5-6 Сетевая модель данных. Язык описания данных в сетевой модели. Язык манипулирования данными в сетевой модели. 7 Реляционная модель данных. Основные определения. 8-9 Операции над отношениями. Реляционная алгебра. Теоретико-множественные операции реляционной алгебры. Специальные операции реляционной алгебры 10-11 Язык SQL. История развития SQL. Структура(блоки) SQL Типы данных. Оператор выбора SELECT. Применение агрегатных функций и вложенных запросов в операторе выбора. Вложенные запросы. Внешние объединения. Операторы манипулирования данными. Средства определения схемы базы данных. Системный анализ предметной области. Пример описания предметной области. Инфологическое моделирование. Модель «сущность—связь». Переход к реляционной модели данных Проектирование реляционных БД на основе принципов нормализации. Даталогическое проектирование. 12 13 14 15-16 17 18-20 22 Принципы поддержки целостности в реляционной модели данных. Общие понятия и определения целостности. . Командный SQL (PL/SQL) Классы СУБД. Модели архитектур СУБД. 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 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 FIO Домены РК Первичный ключ Термины описания структуры таблиц Формальный термин Неформальный эквивалент Отношение Кортеж Кардинальность Атрибут Степень Первичный ключ Домен Таблица Строка или запись Количество строк Столбец или поле Количество столбцов Уникальный идентиф. Мн-во доп. значений Атрибуты Степень Любое отношение является динамической моделью некоторого реального объекта внешнего мира. Поэтому вводится понятие экземпляра отношения, которое отражает состояние данного объекта в текущий момент времени, и понятие схемы отношения, которая определяет структуру отношения. Схемой отношения 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 }, не вошедших в В. Если В = {A1i , A2i ,…,Aki }, B’ = {А1j , А2j ,..., Аmj } и 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 при условии  это подмножество декартова произведения отношений RQ, кортежи которого удовлетворяют условию  . 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 определяет отношение, которое содержит кортежи из декартова произведения отношений RQ, удовлетворяющие предикату 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=((TT1)-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 Лекция 5 Проектирование РБД на основе принципов нормализации «Жизнь» БД как у любого ПО проходит через определенные этапы. Они аналогичны, в основном, развитию любой программной системы, однако в них есть определенная специфика, касающаяся только баз данных. Более подробно мы будем рассматривать этапы жизненного цикла БД дальше. Системный анализ ПрО Проектирование ИС Реализация ИС Отладка и тестирование ИС Ввод в действие и эксплуатация ИС Рис. 6.1. Этапы жизненного цикла ИС ЖЦ ИС (БД-как ее ядро) Проект - это схема, эскиз некоторого устройства, который в дальнейшем будет воплощен в реальность. Проект реляционной базы данных - это набор взаимосвязанных отношений, в которых определены все атрибуты, заданы первичные и внешние ключи отношений, а также дополнительные свойства отношений, которые относятся к принципам поддержки целостности. Процесс проектирования БД представляет собой последовательность переходов от неформального словесного описания информационной структуры предметной области к формализованному описанию объектов предметной области в терминах некоторой модели. В общем случае можно выделить следующие этапы проектирования: 1. Системный анализ и словесное описание информационных объектов предметной области. 2. Проектирование инфологической модели предметной области — частично формализованное описание объектов предметной области в терминах некоторой семантической модели, например, в терминах ER-модели. 3. Выбор модели данных(иерарх., сетев., …)+ СУБД 4. Даталогичеcкое или логическое проектирование БД, то есть описание БД в терминах принятой даталогической модели данных. 5. Физическое проектирование БД, то есть выбор эффективного размещения БД на внешних носителях для обеспечения наиболее эффективной работы приложений. Рис. 6.2. Этапы проектирования БД Рассмотрим более подробно этапы проектирования БД Системный анализ предметной области С точки зрения проектирования БД в рамках СА, необходимо провести подробное словесное описание объектов ПрО и реальных связей, которые присутствуют между ними.. В общем случае существуют два подхода к выбору состава и структуры предметной области:  Функциональный подход — он реализует принцип движения "от задач" и применяется тогда, когда заранее известны функции некоторой группы лиц и задачи, которые они будут решать с помощью БД. В этом случае можно четко выделить минимальный необходимый набор объектов предметной области, которые должны быть описаны. 43  Предметный подход - информационные потребности будущих пользователей БД жестко не фиксируются. В описание ПрО включаются наиболее существенные объекты и взаимосвязи. Конструируемая БД м.б. использована при решении заранее не определенных задач. Это кажется очень заманчивым, однако приведет к избыточно сложной схеме БД, которая для конкретных задач будет неэффективной. На практике рекомендуется использовать некоторый компромиссный вариант, который, ориентирован на конкретные задачи или функциональные потребности пользователей, НО учитывает возможность наращивания новых приложений. СА должен заканчиваться подробным описанием объектов предметной области которые должны храниться в БД, формулировкой конкретных задач, решаемых в БД с кратким описанием алгоритмов их решения, требований со стороны пользователя, описанием выходных документов, которые должны генерироваться в системе, описанием входных документов, которые служат основанием для заполнения данными БД. Пример описания предметной области объекта автоматизации(ОА) Постановка задачи: Необходимо разработать ИС для автоматизации учета получения и выдачи книг в библиотеке. 1. Строим организационно-функциональную модель ОА («дерево из орг-звеньев с должностями» 2. Словесно описываем бизнес-процессы протекающие в ОА (дать их перечень после описания) 3. Описываем информационную модель (основа будущей БД) На основании анализа предметной области выделены следующие объекты. Системный каталог. В нем содержится перечень областей знаний, по которым имеются книги в библиотеке. Области знаний в систематическом каталоге могут иметь уникальный внутренний номер и полное наименование. Книги. Каждая книга может содержать сведения из нескольких областей знаний. Каждая книга в библиотеке может присутствовать в нескольких экземплярах. Каждая книга, хранящаяся в библиотеке, характеризуется следующими параметрами:  уникальный шифр;        название; фамилии авторов (могут отсутствовать); место издания (город); издательство; год издания; количество страниц; стоимость книги; количество экземпляров книги в библиотеке. Книги могут иметь одинаковые названия, но они различаются по своему уникальному шифру (ISBN). В библиотеке ведется картотека читателей. На каждого читателя в картотеку заносятся следующие сведения:  фамилия, имя, отчество;  домашний адрес;  телефон (будем считать, что у нас два телефона - рабочий и домашний);  дата рождения. Экземпляры. Каждая книга в библиотеке может присутствовать в нескольких экземплярах. Каждый экземпляр имеет следующие характеристики:  уникальный инвентарный номер;  шифр книги, который совпадает с уникальным шифром из описания книг;  место размещения в библиотеке. 44 Вкладыш. В случае выдачи экземпляра книги читателю в библиотеке хранится специальный вкладыш, в котором должны быть записаны следующие сведения:  номер билета читателя, который взял книгу;  дата выдачи книги;  дата возврата. При работе библиотеки выполняются следующие правила (ограничения): 1. Книга может не иметь ни одного автора. 2. В библиотеке присутствуют книги, изданные начиная с 1990 по текущий год. 3. Каждому читателю присваивается уникальный номер читательского билета. 4. В библиотеке должны быть записаны читатели не моложе 17 лет. 5. Каждый читатель может держать на руках не более 5 книг. 6. Читатель не должен одновременно держать более одного экземпляра книги одного названия 7. Каждый читатель при регистрации в библиотеке должен дать телефон для связи 8. Каждая область знаний может содержать ссылки на множество книг, каждая книга может относиться к различным областям знаний. Предполагается, что с разрабатываемой информационной системой должны работать следующие группы пользователей:  библиотекари;  читатели;  администрация библиотеки. При работе с БД библиотекарь должен иметь возможность решать след. задачи: 1. Принимать новые книги и регистрировать их в библиотеке. 2. Проводить каталогизацию книг, то есть назначение новых инвентарных номеров вновь принятым книгам, и, помешан их на полки библиотеки, запоминать место размещения каждого экземпляра. 3. Проводить списание старых и не пользующихся спросом книг. Списание проводится по специальному акту списания, который утверждается администрацией библиотеки. 4. Вести учет выданных книг читателям, при этом предполагается два режима работы: выдача книг читателю и прием от него возвращаемых им книг обратно в библиотеку. 5. Проводить списание утерянных читателем книг по специальному акту списания или замены, подписанному администрацией библиотеки. 6. Проводить закрытие абонемента читателя. … Читатель должен иметь возможность решать следующие задачи: 1. Просматривать системный каталог, то есть перечень всех областей знаний, книги по которым есть в библиотеке. 2. По выбранной области знаний получить полный перечень книг, которые числятся в библиотеке. 3. Для выбранной книги получить инвентарный номер свободного экземпляра книги или сообщение о том, что свободных экземпляров книги нет. В случае отсутствия свободных экземпляров книги читатель должен иметь возможность узнать дату ближайшего предполагаемого возврата экземпляра данной книги. Читатель не может узнать данные о том, у кого в настоящий момент экземпляры данной книги находятся па руках (в целях обеспечения личной безопасности держателей требуемой книги). 4. Для выбранного автора получить список книг, которые числятся в библиотеке. Администрация библиотеки должна иметь возможность: 1 получать сведения о должниках — читателях библиотеки, которые не вернули вовремя взятые книги; сведения о книгах, которые не являются популярными; сведения о стоимости конкретной книги; сведения о наиболее популярных книгах. Этот совсем небольшой пример показывает, что перед началом разработки необходимо иметь точное представление о том, что же должно выполняться в системе (какова ее будущая функциональность), какие группы пользователей в ней будут работать, какие задачи будет решать каждый пользователь (требования пользователей к БД). 45 Лекция 7 Инфологическое моделирование Процесс проектирования длительный, он требует обсуждений с заказчиком, со специалистами в предметной области. При разработке КИС проект БД является фундаментом, на котором строится вся система в целом, и вопрос о возможном кредитовании часто решается экспертами банка на основании именно грамотно сделанного инфологического проекта БД. Инфологическая модель применяется на втором этапе проектирования БД, то есть после словесного описания предметной области. Инфологическая модель – это формализованное описание предметной области, которое легко "читается" и специалистами по БД и ПрО. ОНО должно быть достаточно емким, чтобы можно было оценить глубину и корректность проработки проекта БД. Инфол.проектирование прежде всего связано с попыткой представления семантики предметной области в модели БД. Проблема представления семантики давно интересовала разработчиков, и в семидесятых годах было предложено несколько моделей данных, названных семантическими моделями. К ним можно отнести семантическую модель данных, предложенную Хаммером (Hammer) и МакЛеоном (McLeon) в 1981 году, функциональную модель данных Шипмана (Shipman), также созданную в 1981 году, модель "сущность—связь", предложенную Ченом (Chen) в 1976 году, и ряд других моделей. У всех моделей были свои положительные и отрицательные стороны, но испытание временем выдержала только последняя. В настоящее время модель Чена "сущность—связь", или "Entity Relationship", стала фактическим стандартом при инфологическом моделировании баз данных. Общепринятым стало сокращенное название ER-модель, большинство современных CASE-средств содержат инструментальные средства для описания данных в формализме этой модели. Разработаны методы автоматического преобразования проекта БД из ER-модели в реляционную, при этом преобразование выполняется в даталогическую модель, соответствующую конкретной СУБД. Все CASE-системы имеют развитые средства документирования процесса разработки БД, автоматические генераторы отчетов позволяют подготовить отчет о текущем состоянии проекта БД с подробным о писанием объектов БД и их отношений как в графическом виде, так и в виде готовых стандартных печатных отчетов, что существенно облегчает ведение проекта. В настоящий момент не существует единой общепринятой системы обозначений для ERмодели и разные CASE-системы используют разные графические нотации, но разобравшись в одной, можно легко понять и другие нотации. Модель "сущность-связь" Эта модель согласуется с концепцией ОО-проектирования, которая в наст.время является базовой для разработки сложных программных систем. В основе ER-модели лежат следующие базовые понятия:  Сущность - моделирует класс однотипных объектов. Сущность имеет уникальное имя, в пределах моделируемой системы. Так как сущность соответствует некоторому классу однотипных объектов, то предполагается, что в системе существует множество экземпляров данной сущности.  Для сущностей различают ее тип и экземпляр. Тип характеризуется именем и списком свойств, а экземпляр - конкретными значениями свойств.  Сущность может иметь набор атрибутов — характеристик, определяющих свойства данного представителя класса. По ним можно различать конкретные экземпляры сущности. Набор атрибутов, однозначно идентифицирующий конкретный экземпляр сущности, называют ключевым. Одно из общепринятых графических обозначений сущности — прямоугольник, в верхней части которого записано имя сущности, а ниже перечисляются атрибуты, причем ключевые атрибуты помечаются, например, подчеркиванием или специальным шрифтом. (Есть и другие нотации!!!) 46 Между сущностями могут быть установлены связи — бинарные ассоциации, показывающие, каким образом сущности соотносятся или взаимодействуют между собой. Связь может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь). Она показывает, как связаны экземпляры сущностей между собой. Если связь устанавливается между двумя сущностями, то она определяет взаимосвязь между экземплярами одной и другой сущности. Например, существует связь между сущностью "Студент" и сущностью "Преподаватель". Эта связь — руководство дипломными проектами: каждый студент имеет только одного руководителя, но один и тот же преподаватель может руководить множеством студентовдипломников(1:М). Рис. 7.2. Пример отношения "один-ко-многим" при связывании сущностей "Студент" и "Преподаватель" В разных нотациях мощность связи изображается по-разному. В нашем примере мы используем нотацию CASE системы POWER DESIGNER, здесь множественность изображается путем разделения линии связи на 3. Связь имеет общее имя "Дипломное проектирование" и имеет имена ролей со стороны обеих сущностей. Со стороны студента эта роль называется "Пишет диплом под руководством", со стороны преподавателя эта связь называется "Руководит". Графическая интерпретация связи позволяет сразу прочитать смысл взаимосвязи между сущностями, она наглядна и легко интерпретируема. Связи делятся на три типа по множественности: один-к-одному (1:1), один-ко-многим (1:M), многие-ко-многим (M:M). Связь один-к-одному означает, что экземпляр одной сущности связан только с одним экземпляром другой сущности. Связь 1: M означает, что один экземпляр сущности, расположенный слева по связи, может быть связан с несколькими экземплярами сущности, расположенными справа по связи. Связь "один-к-одному" (1:1) означает, что один экземпляр одной сущности связан только с одним экземпляром другой сущности, а связь "многие-комногим" (M:M) означает, что один экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и наоборот, один экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности. Между двумя сущностями может быть задано сколько угодно связей с разными смысловыми нагрузками. Связь любого из этих типов может быть обязательной (перпендикулярная линия, перечеркивающая связь), если в данной связи должен участвовать каждый экземпляр сущности, необязательной(пустой кружок на конце связи) — если не каждый экземпляр сущности должен участвовать в данной связи. При этом связь может быть обязательной с одной стороны и необязательной с другой стороны. 47 В результате построения модели предметной области в виде набора сущностей и связей получаем связный граф. В полученном графе необходимо избегать циклических связей — они выявляют некорректность модели. В качестве примера спроектируем инфологическую модель системы, предназначенной для хранения информации о книгах и областях знаний, представленных в библиотеке. Описание предметной области было приведено ранее. Разработку модели начнем с выделения основных сущностей и их атрибутов, а затем построим связи. Рис. Инфологическая модель предметной области "Библиотека" Инфологическая модель "Библиотека" разработана нами под те задачи, которые были перечислены ранее. Атрибуты сущности бывают: 1. Идентифицирующие и описательные. Идентифицирующие атрибуты имеют уникальное значение для сущностей данного типа и являются потенциальными ключами. Они позволяют однозначно распознавать экземпляры сущности. Из потенциальных ключей выбирается один первичный ключ (ПК). Остальные атрибуты называются описательными. 2. Простые и составные. Простой атрибут состоит из одного компонента, его значение неделимо. Составной атрибут является комбинацией нескольких компонентов, возможно, принадлежащих разным типам данных (например, адрес). 3. Однозначные и многозначные - могут иметь соответственно одно или много значений для каждого экземпляра сущности. 4. Основные и производные. Значение основного атрибута не зависит от других атрибутов. Значение производного атрибута вычисляется на основе значений других атрибутов (например, возраст человека вычисляется на основе даты его рождения и текущей даты 48 Рис. 2.6. Диаграмма "сущности-связи" (Пример другой нотации) В дальнейшем многими авторами были разработаны свои варианты подобных моделей (нотация Мартина, нотация IDEF1X, нотация Баркера и др.). Кроме того, различные программные средства, реализующие одну и ту же нотацию, могут отличаться своими возможностями. По сути, все варианты диаграмм "сущность-связь" исходят из одной идеи рисунок всегда нагляднее текстового описания. Все такие диаграммы используют графическое изображение сущностей предметной области, их свойств (атрибутов), и взаимосвязей между сущностями .ПЕРЕХОД К РЕЛЯЦИОННОЙ МОДЕЛИ ДАННЫХ Для ER-модели существует алгоритм однозначного преобразования ее в реляционную модель данных., что позволило в дальнейшем разработать множество инструментальных систем, поддерживающих процесс разработки информационных систем, базирующихся на технологии баз данных. И во всех этих системах существуют средства описания инфологической модели разрабатываемой БД с возможностью автоматической генерации той даталогической модели, на которой будет реализовываться проект в дальнейшем. Рассмотрим правила преобразования ER-модели в реляционную. 1. Каждой сущности ставится в соответствие отношение реляционной модели данных. При этом имена сущности и отношения могут быть различными, потому что на имена сущностей могут не накладываться дополнительные синтаксические ограничения, кроме уникальности имени в рамках модели. Имена отношений могут быть ограничены требованиями конкретной СУБД, чаще всего эти имена являются идентификаторами в некотором базовом языке, они ограничены по длине и не должны содержать пробелов и некоторых специальных символов. Например, сущность может быть названа "Книжный каталог", а соответствующее ей отношение желательно назвать, например, BOOKS (без пробелов и латинскими буквами). 2. Каждый атрибут сущности становится атрибутом соответствующего отношения. Переименование атрибутов должно происходить в соответствии с теми же правилами, что и переименование отношений в п.1. Для каждого атрибута задается конкретный допустимый в СУБД тип данных и обязательность или необязательность данного атрибута (то есть допустимость или недопустимость NULL значений для него). 3. Первичный ключ сущности становится PRIMARY KEY соответствующего отношения. Атрибуты, входящие в первичный ключ отношения, автоматически получают свойство обязательности (NOT NULL). 49 4. В каждое отношение, соответствующее подчиненной сущности, добавляется набор атрибутов основной сущности, являющейся первичным ключом основной сущности. В отношении, соответствующем подчиненной сущности, этот набор атрибутов становится внешним ключом (FOREING KEY). 5. Для моделирования необязательного типа связи на физическом уровне у атрибутов, соответствующих внешнему ключу, устанавливается свойство допустимости неопределенных значений (признак NULL). При обязательном типе связи атрибуты получают свойство отсутствия неопределенных значений (признак NOT NULL). Разрешение связей типа "многие-ко-многим". Так как в реляционной модели данных поддерживаются между отношениями только связи типа "один-ко-многим", а в ER-модели допустимы связи "многие-ко-многим", то необходим специальный механизм преобразования, который позволит отразить множественные связи, неспецифические для реляционной модели, с помощью допустимых для нее категорий. Это делается введением специального дополнительного связующего отношения, которое связано с каждым исходным связью "одинко-многим", атрибутами этого отношения являются первичные ключи связываемых отношений. На лекциях рассматривали инфологическую модель "Библиотека". В ней присутствует связь такого типа между сущностью "Книги" и "Системный каталог". Для разрешения этой неспецифической связи при переходе к реляционной модели должно быть введено специальное дополнительное отношение, которое имеет всего два атрибута: ISBN (шифр книги) и KOD (код области знаний). При этом каждый из атрибутов нового отношения является внешним ключом (FOREING KEY), а вместе они образуют первичный ключ (PRIMARY KEY) новой связующей сущности. На рис. представлена реляционная модель(даталогическая), соответствующая представленной ранее на инфологической модели "Библиотека". Рис. 7.13. Даталогическая (реляционная) модель БД "Библиотека" 50 ПРОЕКТИРОВАНИЕ РЕЛЯЦИОННОЙ БД НА ОСНОВЕ ПРИНЦИПОВ НОРМАЛИЗАЦИИ Лекция посвящена вопросам проектирования БД. Рассматриваются базовые понятия функциональных и многозначных зависимостей между свойствами объектов, моделируемых в БД Даталогическое проектирование В реляционных БД даталогическое или логическое проектирование приводит к разработке схемы БД, то есть совокупности схем отношений, которые адекватно моделируют абстрактные объекты предметной области и семантические связи между этими объектами. Основой анализа корректности схемы являются так называемые функциональные зависимости между атрибутами БД. Некоторые зависимости между атрибутами отношений являются нежелательными из-за побочных эффектов и аномалий, которые они вызывают при модификации БД. При этом под процессом модификации БД мы понимаем внесение новых данных в БД или удаление некоторых данных из БД, а также обновление значений некоторых атрибутов. Этап даталогического проектирования включает:    Описание схемы БД в терминах выбранной СУБД. Описание декларативных правил поддержки целостности базы данных. Разработка процедур поддержки семантической целостности базы данных. Однако перед тем как описывать построенную схему в терминах выбранной СУБД, нам надо выстроить эту схему. Именно этому процессу и посвящен данный раздел. Мы должны построить корректную схему БД, ориентируясь на реляционную модель данных. ОПРЕДЕЛЕНИЕ Корректной назовем схему БД, в которой отсутствуют нежелательные зависимости между атрибутами отношений. Процесс разработки корректной схемы реляционной БД называется логическим проектированием БД. Проектирование схемы БД может быть выполнено двумя путями:   путем декомпозиции (разбиения), когда исходное множество отношений, входящих в схему БД заменяется другим множеством отношений (число их при этом возрастает), являющихся проекциями исходных отношений; путем синтеза, то есть путем компоновки из заданных исходных элементарных зависимостей между объектами предметной области схемы БД. Классическая технология проектирования реляционных баз данных связана с теорией нормализации, основанной на анализе функциональных зависимостей между атрибутами отношений. Понятие функциональной зависимости является фундаментальным в теории нормализации реляционных баз данных. Мы определим его далее, а пока коснемся смысла этого понятия. Функциональные зависимости определяют устойчивые отношения между объектами и их свойствами в рассматриваемой предметной области. Именно поэтому процесс поддержки функциональных зависимостей, характерных для данной предметной области, является базовым для процесса проектирования. Процесс проектирования с использованием декомпозиции представляет собой процесс последовательной нормализации схем отношений, при этом каждая последующая итерация соответствует нормальной форме более высокого уровня и обладает лучшими свойствами по сравнению с предыдущей. 51 Каждой нормальной форме соответствует некоторый определенный набор ограничений, и отношение находится в некоторой нормальной форме, если удовлетворяет свойственному ей набору ограничений. В теории реляционных БД выделяется следующая последовательность нормальных форм:       первая нормальная форма (1НФ / 1NF) ; вторая нормальная форма (2НФ / 2NF); третья нормальная форма (3НФ / 3NF); нормальная форма Бойса—Кодда (БКНФ / BCNF); четвертая нормальная форма (4НФ / 4NF); пятая нормальная форма/форма проекции-соединения (5НФ / 5NF/PJNF). Основные свойства нормальных форм:   каждая следующая HФ улучшает свойства предыдущей; при переходе к следующей НФ свойства предыдущих НФ сохраняются. В основе классического процесса проектирования лежит последовательность переходов от предыдущей нормальной формы к последующей. Однако в процессе декомпозиции мы сталкиваемся с проблемой обратимости, то есть возможности восстановления исходной схемы. Таким образом, декомпозиция должна сохранять эквивалентность схем БД при замене одной схемы на другую. ОПРЕДЕЛЕНИЕ Схемы БД называются эквивалентными, если содержание исходной БД может быть получено путем естественного соединения отношений, входящих в результирующую схему, и при этом не появляется новых кортежей в исходной БД. При выполнении эквивалентных преобразований сохраняется множество исходных фундаментальных функциональных зависимостей между атрибутами отношений. Функциональные зависимости определяют не текущее состояние БД, а все возможные ее состояния, то есть они отражают те связи между атрибутами, которые присущи реальному объекту, который моделируется с помощью БД. Поэтому определить функциональные зависимости по текущему состоянию БД невозможно, поэтому набор функциональных зависимостей задает разработчик/системный аналитик, исходя из глубокого системного анализа предметной области. Приведем ряд основных определений. Функциональной зависимостью набора атрибутов В отношения R от набора атрибутов A того же отношения, обозначаемой как R.A R.B или A B называется такое соотношение проекций R[A] и R[B], при котором в каждый момент времени любому элементу проекции R[A] соответствует только один элемент проекции R[B], входящий вместе с ним в к-либо кортеж отношения R. Функциональная зависимость R.A R.B называется полной, если набор атрибутов B функционально зависит от A и не зависит функционально от любого подмножества A, т.о. R.A R.B называется полной, если: A1 A R.A -/ R.B, что читается следующим образом: для любого A1, являющегося подмножеством А, R.B функционально не зависит от R.A, в противном случае зависимость R.A R.B называется неполной. 52 Функциональная зависимость R.A атрибутов С такой, что: 1. 2. 3. 4. 5. R.B называется транзитивной, если существует набор С не является подмножеством А. С не включает в себя B. Существует функциональная зависимость R.A R.C. Не существует функциональной зависимости R.C R.A. Существует функциональная зависимость R.C R.B. Возможным ключом отношения называется набор атрибутов отношения, который полностью и однозначно (функционально полно) определяет значения всех остальных атрибутов отношения, то есть возможный ключ — это набор атрибутов, однозначно определяющий кортеж отношения, и при этом при удалении любого атрибута из этого набора его свойство однозначной идентификации кортежа теряется. А может ли быть ситуация, когда отношение не имеет возможного ключа? Давайте вспомним определение отношения: отношение — это подмножество декартова произведения множества доменов. И в полном декартовом произведении все наборы значений различны, тем более в его подмножестве. Значит, обязательно для каждого отношения всегда существует набор атрибутов, по которому можно однозначно определить кортеж отношения. В вырожденном случае это просто полный набор атрибутов отношения, потому что если мы зададим для всех атрибутов конкретные значения, то, по определению отношения, мы получим только один кортеж. В общем случае в отношении может быть несколько возможных ключей. Среди всех возможных ключей отношения обычно выбирают один, который считается главным и который называют первичным ключом отношения. Неключевым атрибутом называется любой атрибут отношения, не входящий в состав ни одного возможного ключа отношения. Взаимно-независимые атрибуты — это такие атрибуты, которые не зависят функционально один от другого. Если в отношении существует несколько функциональных зависимостей, то каждый атрибут или набор атрибутов, от которого зависит другой атрибут, называется детерминантом отношения. Для функциональных зависимостей как фундаментальной основы проекта БД были проведены исследования, позволяющие избежать избыточного их представления. Ряд зависимостей могут быть выведены из других путем применения правил, названных аксиомами Армстронга, по имени исследователя, впервые сформулировавшего их. Это три основных аксиомы: 1. Рефлексивность: если В является подмножеством А, то А 2. Дополнение: если А B , то A.C B.C 3. Транзитивность: если A B и B C , то A C. B Доказано, что данные правила являются полными и исчерпывающими, то есть, применяя их, из заданного множества функциональных зависимостей можно вывести все возможные функциональные зависимости. Множество всех возможных функциональных зависимостей, выводимое из заданного набора исходных функциональных зависимостей, называется его замыканием. 53 ОПРЕДЕЛЕНИЕ Отношение находится в 1 НФ форме т.и т.т., когда на пересечении каждого столбца и каждой строки находятся только элементарные значения атрибутов. В некотором смысле это определение избыточно, потому что собственно оно определяет само отношение в теории реляционных баз данных. Однако в силу исторически сложившихся обстоятельств и для преемственности такое определение первой нормальной формы существует и мы должны с ним согласиться. Отношения, находящиеся в первой нормальной форме, часто называют просто нормализованными отношениями. Соответственно, ненормализованные отношения могут интерпретироваться как таблицы с неравномерным заполнением, например таблица "Расписание", которая имеет вид: Преподаватель День недели Петров В. И. Понед. Вторник Вторник Киров В. А. Понед. Вторник Вторник Серов А. А. Понед. Среда Четверг Номер пары 1 1 2 2 3 4 3 3 4 Название дисциплины Теор. выч. проц. Комп. графика Комп. графика Теор. информ. Пр-е на С++ Пр-е на С++ Защита инф. Пр-е на VB Пр-е на VB Тип занятий Лекция Лаб. раб.. Лаб. раб Лекция Лаб. раб. Лаб. раб. Лекция. Лаб. раб Лаб. раб. Группа 4906 4907 4906 4906 4907 4906 4944 4942 4922 Здесь на пересечении одной строки и одного столбца находится целый набор элементарных значений, соответствующих набору дней, перечню пар, набору дисциплин, по которым проводит занятия один преподаватель. Для приведения отношения "Расписание" к первой нормальной форме необходимо дополнить каждую строку фамилией преподавателя. ОПРЕДЕЛЕНИЕ Отношение находится в 2 НФ т.и т.т., когда оно находится в 1 НФ и не содержит неполных функциональных зависимостей непервичных атрибутов от атрибутов первичного ключа. Преподаватель Петров В. И. Петров В. И. Петров В. И. Киров В. А. Киров В. А. Киров В. А. Серов А. А. Серов А. А. Серов А. А. День недели Понед. Вторник Вторник Понед. Вторник Вторник Понед. Среда Четверг Номер пары 1 1 2 2 3 4 3 3 4 Название дисциплины Теор. выч. проц. Комп. графика Комп. графика Теор. информ. Пр-е на С++ Пр-е на С++ Защита инф. Пр-е на VB Пр-е на VB Тип занятий Лекция Лаб. раб.. Лаб. раб Лекция Лаб. раб. Лаб. раб. Лекция. Лаб. раб Лаб. раб. Группа 4906 4907 4906 4906 4907 4906 4944 4942 4922 54 Рассмотрим отношение, моделирующее сдачу студентами текущей сессии. Структура этого отношения определяется следующим набором атрибутов: (ФИО, Номер зач.кн., Группа, Дисциплина, Оценка) Так как каждый студент сдает целый набор дисциплин в процессе сессии, то первичным ключом отношения может быть (Номер. зач.кн., Дисциплина), который однозначно определяет каждую стоку отношения. С другой стороны, атрибуты ФИО и Группа зависят только от части первичного ключа — от значения атрибута Номер зач. кн., поэтому мы должны констатировать наличие неполных функциональных зависимостей в данном отношении. Для приведения данного отношения ко второй нормальной форме следует разбить его на проекции, при этом должно быть соблюдено условие восстановления исходного отношения без потерь. Такими проекциями могут быть два отношения: (ФИО, Номер.зач.кн., Группа) (Номер зач.кн., Дисциплина, Оценка) Этот набор отношений не содержит неполных функциональных зависимостей, и поэтому эти отношения находятся во второй нормальной форме. А почему надо приводить отношения ко второй нормальной форме? Иначе говоря, какие аномалии или неудобства могут возникнуть, если мы оставим исходное отношение и не будем его разбивать на два? Давайте рассмотрим ситуацию, когда студент переведен из одной группы в другую. Тогда в первом случае (если мы не разбивали исходное отношение на два) мы должны найти все записи с данным студентом и в них изменить значение атрибута Группа на новое. Во втором же случае меняется только один кортеж в первом отношении. И конечно, опасность нарушения корректности (непротиворечивости содержания) БД в первом случае выше. Может получиться так, что часть кортежей поменяет значения атрибута Группа, а часть по причине сбоя в работе аппаратуры останется в старом состоянии. И тогда наша БД будет содержать записи, которые относят одного студента одновременно к разным группам. Чтобы этого не произошло, мы должны принимать дополнительные непростые меры, например организовывать процесс согласованного изменения с использованием сложного механизма транзакций, который мы будем рассматривать в лекциях, посвященных вопросам распределенного доступа к БД. Если же мы перешли ко второй нормальной форме, то мы меняем только один кортеж. Кроме того, если у нас есть студенты, которые еще не сдавали экзамены, то в исходном отношении мы вообще не можем хранить о них информацию, а во второй схеме информация о студентах и их принадлежности к конкретной группе хранится отдельно от информации, которая связана со сдачей экзаменов, и поэтому мы можем в этом случае отдельно работать со студентами и отдельно хранить и обрабатывать информацию об успеваемости и сдаче экзаменов, что в действительности и происходит. ОПРЕДЕЛЕНИЕ Отношение находится в в 3 НФ форме т.и т.т., когда оно находится 2 НФ и не содержит транзитивных зависимостей. Рассмотрим отношение, связывающее студентов с группами, факультетами и специальностями, на которых он учится. (ФИО, Номер зач.кн., Группа, Факультет, Специальность, Выпускающая кафедра) Первичным ключом отношения является Номер зач.кн., однако рассмотрим остальные функциональные зависимости. Группа, в которой учится студент, однозначно определяет факультет, на котором он учится, а также специальность и выпускающую кафедру. Кроме того, выпускающая кафедра однозначно определяет факультет, на котором обучаются студенты, выпускаемые по данной кафедре. Но если мы предположим, что одну специальность могут выпускать несколько кафедр, то специальность не определяет выпускающую кафедру. В этом случае у нас есть следующие функциональные зависимости: 55 Номер зач.кн. ФИО Номер зач.кн. Группа Номер зач.кн. Факультет Номер зач.кн. Специальность Номер зач.кн. Выпускающая кафедра Группа Факультет Группа Специальность Группа Выпускающая кафедра Выпускающая кафедра Факультет И эти зависимости образуют транзитивные группы. Для того чтобы избежать этого, мы можем предложить следующий набор отношений: (Номер.зач.кн, ФИО, Специальность, Группа) (Группа, Выпускающая кафедра) (Выпускащая кафедра, Факультет) Первичные ключи отношений выделены. Теперь необходимо удостовериться, что при естественном соединении мы не потеряем ни одной строки и не получим лишних кортежей. И это упражнение я предлагаю выполнить вам самостоятельно. Полученный набор отношений находится в третьей нормальной форме. ОПРЕДЕЛЕНИЕ Отношение находится в нормальной форме Бойса—Кодда, если оно находится в 3НФ и каждый детерминант отношения является возможным ключом отношения. Рассмотрим отношение, моделирующее сдачу студентом текущих экзаменов. Предположим, что студент может сдавать экзамен по одной дисциплине несколько раз, если он получил неудовлетворительную оценку. Допустим, что во избежание возможных полных однофамильцев мы можем однозначно идентифицировать студента номером его зачетной книги, но, с другой стороны, у нас ведется электронный учет текущей успеваемости студентов, поэтому каждому студенту -присваивается в период его обучения в вузе уникальный номеридентификатор. Отношение, которое моделирует сдачу текущей сессии, имеет следующую структуру: (Номер зач.кн., Идентификатор_студента, Дисциплина, Дата, Оценка) Возможными ключами отношения являются Номер_зач.кн, Дисциплина, Дата и Идентификатор_студента, Дисциплина, Дата. Какие функциональные зависимости у нас имеются? Номер_зач.кн, Дисциплина, Дата Оценка; Идентификатор_студента, Дисциплина, Дата Оценка; Номер зач.кн. Идентификатор_студента; Идентификатор_студента Номер зач.кн. 56   Откуда взялись две последние функциональные зависимости? Но ведь мы предварительно описали, что каждому студенту ставится в соответствие один номер зачетной книжки и один Идентификатор_студента, поэтому по значению Номер зач.кн. можно однозначно определить Идентификатор_студента (это третья зависимость) и обратно (и это четвертая зависимость). Оценим это отношение. Это отношение находится в третьей нормальной форме, потому что неполных функциональных зависимостей непервичных атрибутов от атрибутов возможного ключа здесь не присутствует и нет транзитивных зависимостей. А как же третья и четвертая зависимости, разве они не являются неполными? Нет, потому что зависимым не является непервичный атрибут, то есть атрибут, не входящий ни в один возможный ключ. Поэтому придраться к этому мы не можем. Но вот под четвертую нормальную форму наше отношение не подходит, потому что у нас есть два детерминанта Номер зач.кн. и Идентификатор_студента, которые не являются возможными ключами отношения. Для приведения отношения к нормальной форме Бойса—Кодда надо разделить отношение, например, на два со следующими схемами: (Идентификатор_студента, Дисциплина, Дата, Оценка) (Номер зач.кн., Идентификатор_студента) или наоборот: (Номер зач.кн., Дисциплина, Дата, Оценка) (Номер зач.кн., Идентификатор_студента) Эти схемы равнозначны с точки зрения теории нормализации, поэтому выбирать проектировщикам следует исходя из некоторых дополнительных рассуждений. Ну, например, если учесть, что зачетные книжки могут теряться, то как они будут восстанавливаться: если с тем же самым номером, то нет разницы, но если с новым номером, то тогда первая схема предпочтительней. В большинстве случаев достижение третьей нормальной формы или даже формы Бойса—Кодда считается достаточным для реальных проектов баз данных, однако в теории нормализации существуют нормальные формы высших порядков, которые уже связаны не с функциональными зависимостями между атрибутами отношений, а отражают более тонкие вопросы семантики предметной области и связаны с другими видами зависимостей. Прежде чем перейти к рассмотрению нормальных форм высших порядков, дадим еще несколько определений. ОПРЕДЕЛЕНИЕ В отношении R (A, B, C) существует многозначная зависимость (multi valid dependence, MVD) R.A ->> R.B в том и только в том случае, если множество значений B, соответствующее паре значений A и C, зависит только от A и не зависит от С. Когда мы рассматривали функциональные зависимости, то каждому значению детерминанта соответствовало только одно значение зависимого от него атрибута. При рассмотрении многозначных зависимостей мы выделяем случаи, когда одному значению некоторого атрибута соответствует устойчиво постоянное множество значений другого атрибута. Когда это может быть? Рассмотрим конкретную ситуацию, понятную всем студентам. Пусть дано отношение, которое моделирует предстоящую сдачу экзаменов на сессии. Допустим, оно имеет вид: (Номер зач.кн., Группа, Дисциплина) Перечень дисциплин, которые должен сдавать студент, однозначно определяется не его фамилией, а номером группы (то есть специальностью, на которой он учится). 57 В данном отношении существуют следующие две многозначные зависимости: Группа ->> Дисциплина Группа ->> Номер зач.кн. Это означает, что каждой группе однозначно соответствует перечень дисциплин по учебному плану и номер группы определяет список студентов, которые в этой группе учатся. Если мы будем работать с исходным отношением, то мы не сможем хранить информацию о новой группе и ее учебном плане — перечне дисциплин, которые должна пройти группа до тех пор, пока в нее не будут зачислены студенты. При изменении перечня дисциплин по учебному плану, например при добавлении новой дисциплины, внести эти изменения в отношение для всех студентов, занимающихся в данной группе, весьма затруднительно. С другой стороны, если мы добавляем студента в уже существующую группу, то мы должны добавить множество кортежей, соответствующих перечню дисциплин для данной группы. Эти аномалии модификации отношения как раз и связаны с наличием двух многозначных зависимостей. В теории реляционных баз данных доказывается, что в общем случае в отношении R (A, B, C) существует многозначная зависимость R.A ->> R.B в том и только в том случае, когда существует многозначная зависимость R.A ->> R.C. Дальнейшая нормализация отношений, подобных нашему, основывается на теореме Фейджина. ТЕОРЕМА ФЕЙДЖИНА Отношение R (A, B, C) можно спроецировать без потерь в отношения R1 (A, B) и R2 (A, C) в том и только в том случае, когда существует MVD A ->> B | C ( что равнозначно наличию двух зависимостей A ->> B и A ->> C). Под проецированием без потерь понимается такой способ декомпозиции отношения путем применения операции проекции, при котором исходное отношение полностью и без избыточности восстанавливается путем естественного соединения полученных отношений. Практически теорема доказывает наличие эквивалентной схемы для отношения, в котором существует несколько многозначных зависимостей. ОПРЕДЕЛЕНИЕ Отношение R находится в четвертой нормальной форме (4NF) в том и только в том случае, если в случае существования многозначной зависимости A ->> B все остальные атрибуты R функционально зависят от A. В нашем примере можно произвести декомпозицию исходного отношения в два отношения: (Номер зач.кн., Группа) (Группа, Дисциплина) Оба эти отношения находятся в 4NF и свободны от отмеченных аномалий. Действительно, обе операции модификации теперь упрощаются: добавление нового студента связано с добавлением всего одного кортежа в первое отношение, а добавление новой дисциплины выливается в добавление одного кортежа во второе отношение, кроме того, во втором отношении мы можем хранить любое количество групп с определенным перечнем дисциплин, в которые пока еще не зачислены студенты. Последней нормальной формой является пятая нормальная форма 5NF, которая связана с анализом нового вида зависимостей, зависимостей "проекции соединения" (project-join зависимости, обозначаемые как PJ-зависимости). Этот вид зависимостей является в некотором роде обобщением многозначных зависимостей. 58 ОПРЕДЕЛЕНИЕ Отношение R (X, Y,…, Z) удовлетворяет зависимости соединения (X, Y,…, Z) в том и только в том случае, когда R восстанавливается без потерь путем соединения своих проекций на X, Y, …, Z. Здесь X, Y, …, Z — наборы атрибутов отношения R. Наличие PJ-зависимости в отношении делает его в некотором роде избыточным и затрудняет операции модификации. ОПРЕДЕЛЕНИЕ Отношение R находится в пятой нормальной форме (нормальной форме проекциисоединения — PJ/NF) в том и только в том случае, когда любая зависимость соединения в R следует из существования некоторого возможного ключа в R. Рассмотрим отношение R1: R1(Преподаватель, Кафедра, Дисциплина) Предположим, что каждый преподаватель может работать на нескольких кафедрах и на каждой кафедре может вести несколько дисциплин. В этом случае ключом отношения является полный набор из трех атрибутов. В отношении отсутствуют многозначные зависимости, и поэтому отношение находится в 4NF. Введем следующие обозначения наборов атрибутов: ПК (Преподаватель, Кафедра) ПД (Преподаватель, Дисциплина) КД (Кафедра, Дисциплина) Допустим, что отношение R1 удовлетворяет зависимости проекции соединения (ПК, ПД, КД). Тогда отношение R1 не находится в NF/PJ, потому что единственным ключом его является полный набор атрибутов, а наличие зависимости PJ связано с наборами атрибутов, которые не составляют возможные ключи отношения R1. Для того чтобы привести это отношение к NF/PJ, его надо представить в виде трех отношений: R2 (Преподаватель, Кафедра) R3 (Преподаватель, Дисциплина) R4 (Кафедра, Дисциплина) Пятая нормальная форма редко используется на практике. В большей степени она является теоретическим исследованием. Очень тяжело определить само наличие зависимостей "проекции—соединения", потому что утверждение о наличии такой зависимости делается для всех возможных состояний БД, а не только для текущего экземпляра отношения R1. Однако знание о возможном наличии подобных зависимостей, даже теоретическое, нам все же необходимо. 59