КОНСПЕКТ ЛЕКЦИЙ профессионального модуля ПМ.02 Разработка и администрирование баз данных МДК 02.03 «Удалённые базы данных» по специальности 09.02.03 « Программирование в компьютерных системах»


МИНИСТЕРСТВО ЭНЕРГЕТИКИ, ПРОМЫШЛЕННОСТИ И СВЯЗИ СТАВРОПОЛЬСКОГО КРАЯ
Государственное бюджетное профессиональное образовательное учреждение «Ставропольский колледж связи имени Героя Советского Союза В.А. Петрова»
Цикловая комиссия вычислительной техники
УТВЕРЖДАЮ
Заместитель директора
по учебной работе
________ / Г.А. Белоусова /
«___» _________ 20___ г.
КОНСПЕКТ ЛЕКЦИЙ
профессионального модуля ПМ.02 Разработка и администрирование баз данных
МДК 02.03 «Удалённые базы данных»
по специальности 09.02.03 « Программирование в компьютерных системах»
Согласовано
Методист
_____________И.В. Черкасова
«___»_____________ 201_г.
Разработчик: преподаватель Буценко Е.В.
Обсуждено на заседании цикловой комиссии «Вычислительная техника»
Протокол №___
«___»_______________20__г.
Председатель цикловой комиссии
____________ / И.В. Ерёмина/
Ставрополь, 2016
УДК___________
Буценко Е.В.
ПМ.02 Разработка и администрирование баз данных: МДК 02.03. «Удалённые базы данных». Конспект лекций. – Ставрополь, Государственное бюджетное профессиональное образовательное учреждение «Ставропольский колледж связи имени Героя Советского Союза В.А. Петрова». – 283с.
Конспект лекций составлен в соответствии с рабочей программой ПМ.02. Разработка и администрирование баз данных: МДК 02.03. «Удалённые базы данных» для студентов специальности 09.02.03 « Программирование в компьютерных системах». В конспекте лекций рассмотрены теоретические сведения распределенной обработки данных, основные технологии доступа к данным, принципы построения концептуальной, логической и физической моделей данных. На конкретных примерах рассматривается проектирование клиентской и серверной части в СУБД MySQL 5.1.
Конспект лекций может также использоваться студентами других направлений, осваивающих проектирование удаленных баз данных.
Рецензент: Болгак Л.П., преподаватель государственного бюджетного профессионального образовательного учреждения «Ставропольский колледж связи имени Героя Советского Союза В.А. Петрова».
СОДЕРЖАНИЕ
TOC \o "1-3" \h \z \u ВВЕДЕНИЕ PAGEREF _Toc409081531 \h 3РАЗДЕЛ 4. РАЗРАБОТКА И АДМИНИСТРИРОВАНИЕ УДАЛЕННЫХ БАЗ ДАННЫХ PAGEREF _Toc409081532 \h 3Тема 4.1. Основные понятия и технологии доступа PAGEREF _Toc409081533 \h 31.Основные понятия удаленных баз данных PAGEREF _Toc409081534 \h 32.Распределенная обработка данных PAGEREF _Toc409081535 \h 33.Базовые архитектуры распределенной обработки данных PAGEREF _Toc409081536 \h 34. Основные технологии доступа к данным и типовые элементы доступа PAGEREF _Toc409081537 \h 35. Средства доступа к удаленным базам данных PAGEREF _Toc409081538 \h 36. Виды механизмов доступа к данным PAGEREF _Toc409081539 \h 3Выводы PAGEREF _Toc409081540 \h 3Теоретические вопросы для самоконтроля PAGEREF _Toc409081541 \h 3Выводы по теме PAGEREF _Toc409081542 \h 3Тема 4.2. Принципы и средства проектирования баз данных PAGEREF _Toc409081543 \h 31.Серверные системы управления базами данных PAGEREF _Toc409081544 \h 32.Разработка и организация систем управления базами данных PAGEREF _Toc409081545 \h 33. Средства проектирования данных PAGEREF _Toc409081546 \h 34.Структурное моделирование PAGEREF _Toc409081547 \h 35. Моделирование данных PAGEREF _Toc409081548 \h 36. Инструментальные средства автоматизации проектирования PAGEREF _Toc409081549 \h 3Задание для самостоятельной работы PAGEREF _Toc409081550 \h 3Тема 4.3. Разработка и эксплуатация удаленных баз данных PAGEREF _Toc409081551 \h 31.Основы проектирования серверной части приложения PAGEREF _Toc409081552 \h 32.Технологии разработки и управления базами данных средствами языка SQL PAGEREF _Toc409081553 \h 33. Разработка и эксплуатация серверной части PAGEREF _Toc409081554 \h 34 Планирование и реализация индексов PAGEREF _Toc409081555 \h 35 Внешние ключи и ссылочная целостность PAGEREF _Toc409081556 \h 36 Серверные объекты базы данных PAGEREF _Toc409081557 \h 37 Принципы проектирования клиентской части баз данных PAGEREF _Toc409081558 \h 38 Построение запросов к базе данных с помощью языка SQL. PAGEREF _Toc409081559 \h 39. Обработка данных с помощью языка SQL. PAGEREF _Toc409081560 \h 310. Разработка и эксплуатация клиентской части PAGEREF _Toc409081561 \h 311. Программы управления удаленными базами данных PAGEREF _Toc409081562 \h 312. Публикация баз данных PAGEREF _Toc409081563 \h 3Выводы по теме PAGEREF _Toc409081564 \h 3Теоретические вопросы для самоконтроля по теме PAGEREF _Toc409081565 \h 3Тема 4.4. Администрирование баз данных PAGEREF _Toc409081566 \h 31 Основные понятия и определения администрирования баз данных. PAGEREF _Toc409081567 \h 32. Управление учетными записями, назначение привилегий пользователям БД PAGEREF _Toc409081568 \h 3Выводы PAGEREF _Toc409081569 \h 3Теоретические вопросы PAGEREF _Toc409081570 \h 33 Ресурсы администрирования PAGEREF _Toc409081571 \h 3Выводы PAGEREF _Toc409081572 \h 3Теоретические вопросы для самоконтроля: PAGEREF _Toc409081573 \h 3
ВВЕДЕНИЕРАЗДЕЛ 4. РАЗРАБОТКА И АДМИНИСТРИРОВАНИЕ УДАЛЕННЫХ БАЗ ДАННЫХТема 4.1. Основные понятия и технологии доступа
Основные понятия удаленных баз данных.
Распределенная обработка данных.
Базовые архитектуры распределенной обработки данных.
Основные технологии доступа к данным и типовые элементы доступа.
Средства доступа к удаленным базам данных.
Виды механизмов доступа к данным.
Основные понятия удаленных баз данныхАббревиатура ЛВС (она же LAN - Local Area Network) расшифровывается как локальная вычислительная сеть. Первые сети появились в 50 годы. Бурное развитие началось с появлением ПК (персонального компьютера).
Локальная вычислительная сеть - это группа компьютеров, которые соединены между собой при помощи специальной аппаратуры, обеспечивающей обмен данными. Компьютеры могут соединяться друг с другом непосредственно либо через узлы связи. Внутри здания или в пределах небольшой территории ЛВС позволяет соединить между собой группу ПК для совместного использования информации.
ЛВС предоставляет пользователям возможность разделять ресурсы компьютера и информацию, находясь далеко друг от друга, они могут совместно работать над проектами и задачами, которые требуют тесной координации и взаимодействия. К тому же, даже если компьютерная сеть выйдет из строя, вы все же сможете продолжить работу на вашем ПК. Ниже перечислены семь задач, которые решаются с помощью ПК, работающего в составе ЛВС, и которые достаточно трудно решить с помощью отдельного ПК.
Разделение файлов. ЛВС позволяет многим пользователям одновременно работать с одним файлом, хранящимся на центральном файл-сервере. К примеру, в офисе адвоката может иметься набор документов, к которому необходим одновременный доступ нескольких секретарей.
Передача файлов. ЛВС позволяет быстро копировать файлы любого размера с одной машины на другую без использования дискет.
Доступ к информации и файлам. ЛВС позволяет запускать прикладные программы с любой из рабочих станций, где бы она ни была расположена.
Разделение прикладных программ. ЛВС позволяет двум пользователям использовать одну и ту же копию программы, например, текстового процессора MS Word. При этом, конечно, два пользователя не могут одновременно редактировать один и тот же документ.
Одновременный ввод данных в прикладные программы. Сетевые прикладные программы позволяют нескольким пользователям одновременно вводить данные, необходимые для работы этих программ. Например, вести записи в бухгалтерской книге так, что они не будут мешать друг другу. Однако только специальные сетевые версии программ позволяют одновременный ввод информации. Обычные компьютерные программы позволяют работать с набором файлов только одному пользователю.
Разделение принтера. ЛВС позволяет нескольким пользователям на различных рабочих станциях совместно использовать один или несколько дорогостоящих лазерных принтеров.
Электронная почта и Интернет. Вы можете использовать ЛВС как почтовую службу и рассылать служебные записки, доклады, сообщения другим пользователям. Телефон, конечно, быстрее и более удобен, но электронная почта передаст ваше сообщение даже в том случае, если в данный момент абонент отсутствует на своем рабочем месте, и для этого ей не требуется бумаги.
Основное назначение любой компьютерной сети - предоставление информационных и вычислительных ресурсов подключенным к ней пользователям. С этой точки зрения локальную вычислительную сеть можно рассматривать как совокупность серверов и рабочих станций.
Сервер - компьютер, подключенный к сети и обеспечивающий ее пользователей определенными услугами. Серверы могут осуществлять хранение данных, управление базами данных, доступ к всемирной сети Интернет, удаленную обработку заданий, печать заданий и ряд других функций, потребность в которых может возникнуть у пользователей сети. Сервер - источник ресурсов сети.
Рабочая станция - персональный компьютер, подключенный к сети, через который пользователь получает доступ к ее ресурсам. Рабочая станция сети функционирует как в сетевом, так и в локальном режиме. Она оснащена собственной операционной системой (Windows, Unix, MAC OS и т.д.), обеспечивает пользователя всеми необходимыми инструментами для решения прикладных задач.
Клиент - Рабочая станция для одного пользователя, обеспечивающая режим регистрации и др. необходимые на его рабочем месте функции вычисления, коммуникацию, доступ к базам данных и др.
Обработка Клиент - Сервер - среда, в которой обработка приложений распределена между клиентом и сервером. Нередко в обработке участвуют машины разных типов, причем клиент и сервер общаются между собой с помощью фиксированного множества стандартных протоколов обмена и процедур обращения к удаленным платформам.
Одноранговая сеть. В такой сети нет единого центра управления взаимодействием рабочих станций и нет единого устройства для хранения данных. Сетевая операционная система распределена по всем рабочим станциям. Каждая станция сети может выполнять функции, как клиента, так и сервера. Она может обслуживать запросы от других рабочих станций и направлять свои запросы на обслуживание в сеть.
Достоинства одноранговых сетей : низкая стоимость и высокая надежность.
Недостатки одноранговых сетей:
- зависимость эффективности работы сети от количества станций;
- сложность управления сетью;
- сложность обеспечения защиты информации;
- трудности обновления и изменения программного обеспечения станций.
Сеть с выделенным сервером. В сети с выделенным сервером один из компьютеров выполняет функции хранения данных, предназначенных для использования всеми рабочими станциями, управления взаимодействием между рабочими станциями и ряд сервисных функций.
Взаимодействие между рабочими станциями в сети, как правило, осуществляется через сервер. Логическая организация такой сети может быть представлена топологией звезда. Роль центрального устройства выполняет сервер.
Достоинства сети с выделенным сервером:
- надежная система защиты информации;
- высокое быстродействие;
- отсутствие ограничений на число рабочих станций;
- простота управления по сравнению с одноранговыми сетями,
Недостатки сети:
- высокая стоимость из-за выделения одного компьютера под сервер;
- зависимость быстродействия и надежности сети от сервера;
- меньшая гибкость по сравнению с одноранговой сетью.
В подавляющем большинстве случаев локальная сеть используется для коллективного доступа к базам данных.
Основные тенденции развития средств удаленного управления
Общие положения. Удаленный доступ — очень широкое понятие, которое включает в себя различные типы и варианты взаимодействия компьютеров, сетей и приложений. Существует огромное количество схем взаимодействия, которые можно назвать удаленным доступом, но их объединяет использование глобальных каналов или глобальных сетей при взаимодействии. Кроме того, для удаленного доступа, как правило, характерна несимметричность взаимодействия, то есть с одной стороны имеется центральная крупная сеть или центральный компьютер, а с другой — отдельный удаленный терминал, компьютер или небольшая сеть, которые должны получить доступ к информационным ресурсам центральной сети. За последние год-два количество предприятий, имеющих территориально распределенные корпоративные сети, значительно возросло.
Поэтому для современных средств удаленного доступа очень важны хорошая масштабируемость и поддержка большого количества удаленных клиентов.
Отличия между удаленным доступом и удаленным управлением
Существует два типа удаленных вычислений; вы должны выбрать то, что более подходит к вашим требованиям.
Удаленное управление
ПО удаленного управления используется уже давно. Начиная с небольших пакетов, типа PCAnywhere, и заканчивая большими приложениями масштаба предприятия, как SMS. Оно дает пользователям или администратору возможность управлять удаленной машиной и выполнять разнообразные функции. При использовании удаленного управления, от удаленной машины на локальную машину посылаются коды нажатых клавиш. Локальная машина посылает на удаленную изменения экрана. Обработка и передача файлов, как правило, делаются на локальной машине. На рисунке 1.1 показана схема сеанса удаленного управления:

Рисунок 1.1. Схема сеанса УУ
Преимущества удаленного управления
ПО удаленного управления стало очень популярным. Используя централизованные инструменты, персонал службы поддержки может решать проблемы, возникающие на удаленном компьютере. Это улучшает поддержку пользователей. Кроме того, администратор может собирать информацию с большого числа машин и вести записи о их конфигурации и установленном программном обеспечении. Это помогает следить за использованием лицензий.
Удаленное управление может использоваться и как средство дистанционного обучения. Администратор может работать за другим ПК, подключенным к ПК пользователя, видеть экран пользователя, и помогать пользователю освоить программу в режиме демонстрации.
Программы удаленного управления, как правило, предусматривают защиту. В компаниях, хранящих важную информацию, часто запрещается хранить на своих ПК секретную информацию, чтобы удаленные пользователи не могли получить к ней доступ. При удаленном доступе администратор может ограничить пользователя в загрузке информации на свой домашний ПК.
Недостатки удаленного управления
Программы удаленного управления имеют ряд ограничений. Большинство пакетов ограничены разрешением экрана, которое они могут воспроизвести. Клиенты Terminal Services поддерживают максимум 256 цветов. Кроме того, программы, использующие графику, сильно загружают каналы связи и могут свести на нет все преимущества удаленного управления. Citrix MetaFrame недавно выпустила Feature Release 1, дополнительный пакет для MetaFrame 1.8, который позволяет пользователям использовать 24-битный цвет.
Еще одна потенциальная опасность удаленного управления состоит в том, что возникает опасность несанкционированного доступа в сеть. Если некто за пределами сети получает доступ к локальному ПК, он может выполнять на нем любые команды, как если бы он находился в локальной сети. Поэтому многие администраторы предпочитают не оставлять постоянно включенными компьютеры с установленными на них программами удаленного доступа, и тщательно настраивают механизмы аутентификации и ограничения прав пользователей.
Последний недостаток удаленного управления состоит в том, что скорость передачи файлов между локальным и удаленным ПК ограничена скоростью соединения.
Удаленный узел
Удаленный ПК, оборудованный модемом или сетевой платой, выполняет соединение через глобальную сеть к локальному серверу. Этот удаленный ПК теперь рассматривается как локальный узел сети, способный получать доступ к сетевым ресурсам, например, к другим ПК. Сервер отвечает за предоставление всей сетевой информации, за передачу файлов, и даже за некоторые приложения на удаленном узле.
Удаленный узел отвечает за обработку, выполнение, изменение информации, с которой он работает. Все это выполняется с той скоростью, с которой может работать клиент.
Из-за этих ограничений вычисления на удаленном узле предъявляют высокие требования к пропускной способности канала связи. Это следует учитывать при проектировании. Как видно на рисунке, между клиентом на локальном ПК и клиентом удаленного узла есть небольшое различие. Сервер будет одинаково обрабатывать запросы от любой машины. Но если локальный клиент запрашивает 2Мб данных, сервер передаст их по локальной сети. Для удаленного клиента, по каналу 56К эта передача займет около 6 минут. Кроме того, после внесения изменений клиент должен отправить эти 2Мб обратно.
Зачем использовать удаленный доступ?
Почему же компании предпочитают использовать удаленный доступ, а не удаленное управление, несмотря на все эти проблемы, вытекающие из скорости соединения? Для начинающих удаленный доступ проще настроить. Все, что требуется - это способ подключиться к серверу. Для этого обычно используется соединение через Интернет.
Другая важная особенность состоит в том, что для соединения с центральным сервером можно использовать разные операционные системы. Это может быть важно для компаний, использующих различные платформы. Сервисы могут отличаться в разных ОС, но пользователи могут получать доступ к сетевым ресурсам, по крайней мере, на базовом уровне.
Удаленный доступ более безопасен, чем удаленное управление. Для клиентов, использующих Интернет, существуют много программ, реализующих защищенное соединение между клиентом и сервером. В последнее время стали очень популярны виртуальные частные сети (VPN).
Сеансы удаленного доступа не ограничены в графике. Однако, самым большим преимуществом удаленного доступа над удаленным управлением является требование к аппаратному обеспечению. При удаленном доступе, небольшое число локальных машин могут обрабатывать большое число пользовательских сеансов. Следовательно, нет необходимости держать для каждого пользователя отдельный ПК. Пользователи могут работать на удаленных компьютерах, а потом подключаться к локальной сети и выгружать свои изменения. Это также локализует источники ошибок и облегчает их поиск и устранение.
Недостатки вычисления на удаленном узле
Как было сказано выше, скорость является ключевым аспектом, поскольку передается намного больше данных, чем при удаленном управлении. Поскольку удаленный доступ требует, чтобы удаленный ПК мог осуществлять обработку информации, требования к его аппаратному обеспечению также могут стать важным фактором. Это может означать частую замену ПК, модернизацию программного обеспечения. Удаленный ПК также более уязвим для вирусных атак, чем при удаленном управлении. Еще один недостаток удаленного доступа - это выдача клиенту лицензии. Если клиенту запрещено индивидуально устанавливать на своем ПК копию программы, слежение за лицензиями становится еще одной головной болью системных администраторов.
И последнее замечание по поводу удаленного доступа касается совместимости аппаратных платформ. Заранее не зная конфигурации ПК клиента, часто приходится строго ограничивать список поддерживаемых конфигураций. Это часто ограничивает пользователя
Архитектуры прикладных систем
В составе прикладной системы удобно выделить прикладное программное обеспечение и платформу. Формирующие (наряду с аппаратурой) платформу операционную систему, СУБД и программное обеспечение промежуточного слоя вместе называют системным ПО.
Большинство прикладных программ можно разделить на три части: логику (алгоритмы) представления, бизнес-логику (расчетные алгоритмы и правила) и логику (алгоритмы) доступа к данным. Каждая часть вовсе не должна полностью соответствовать отдельному модулю, типу отдельной программы, нити, функции или процедуре — такое разделение весьма полезно, но не необходимо. Очень простые приложения часто способны собрать все три части в единственную программу, и подобное разделение соответствует функциональным границам.
Пользователи взаимодействуют с частью, называемой логикой представления, которая управляет доступом к приложению. Независимо от конкретных характеристик этой части системы (интерфейс командной строки, сложные графические пользовательские интерфейсы, интерфейсы через посредника) ее задача состоит в том, чтобы обеспечить средства для наиболее эффективного обмена информацией между пользователем и системой. Вот почему на стадии проектирования приложения так много внимания уделяют этому компоненту, видимому со стороны внешнего мира.
Бизнес-логика определяет, для чего, собственно, предназначено приложение. В зависимости от конкретных функциональных требований и сложности задач может быть полезным подразделить эту часть на несколько компонентов. В этом случае конкретная реализация каждого компонента может быть представлена в виде набора процедур (библиотеки), класса или классов объектов, отдельных программ. Разделение приложения по границам между программами обеспечивает естественную основу для распределения приложения на нескольких компьютерах.
Алгоритмы доступа к данным исторически рассматривались как специфический для конкретного приложения интерфейс к механизму постоянного хранения данных наподобие файловой системы или СУБД. Так, при помощи этой части программы приложение управляет соединениями с базой данных и запросами к ней (перевод специфических для конкретного приложения запросов на язык SQL, получение результатов и перевод этих результатов обратно в специфические для конкретного приложения структуры данных). К этой части относят только специфический для приложения интерфейс к СУБД, но не ее саму.
Иногда три указанные части называют слоями — от теоретической модели, которая рассматривает каждую часть приложения в терминах ее положения относительно пользователя, от «переднего слоя» (front-end, логика представления) до «заднего слоя» — (back-end, логика доступа к данным). Одна из функций «среднего слоя» (бизнес-логика) состоит в обеспечении двунаправленного преобразования между структурами данных высокого уровня переднего слоя и низкоуровневыми структурами заднего слоя. В этой модели положение каждого слоя (относительно пользователя) непосредственно связано с различными уровнями абстракции.
Рассмотрим приложение, которое производит поиск в базе данных согласно определенным пользователем критериям (рисунок1.1 ). Пользователь заполняет формы и нажимает кнопку «Поиск». Эта информация передается блоку бизнес-логики для формирования одного или более запросов. Эти запросы один за другим передаются блоку логики доступа к данным, который преобразует данные и запросы в формат, совместимый с СУБД, выполняет каждый запрос, получает результат и преобразует его в формат приложения. Наконец, он возвращает результат блоку бизнес-логики, который объединяет результаты нескольких запросов в порцию информации, передаваемую блоку логики представления; тот помещает эти данные в удобочитаемую форму и показывает ее пользователю.
Как правило, преобразования данных выполняются несколько раз. В некоторых приложениях избегают этого, используя структуры, подобные структурам СУБД, в качестве внутреннего формата представления данных. Тогда в рассматриваемом примере блок бизнес-логики может сразу же брать данные пользователя по мере получения их от блока логики представления и преобразовывать в SQL-запросы. После этого блок бизнес-логики может обращаться к базе данных непосредственно, без вовлечения специфической для приложения логики доступа к данным.
Проблема такого подхода состоит в том, что он привязывает приложение к определенному формату данных. Если приложение необходимо перенести на другую СУБД, внутренние структуры данных придется изменить. (Эта зависимость находится вне связи со специфической моделью базы данных, например, с различиями между иерархической и реляционной базами.)
Проблема обостряется еще, когда используется несколько различных по структуре представлений. В этом случае блок бизнес-логики вынужден поддерживать несколько внутренних представлений для, возможно, одних и тех же данных. Поэтому разумнее иметь один «родной» для приложения формат внутреннего представления данных. Преобразование в другой формат может выполняться, когда оно становится неизбежным (в блоке логики доступа к данным при взаимодействии с конкретной базой данных, в слое представления при взаимодействии с пользователем и т.д.).
Разделение функциональных алгоритмов на логику представления, бизнес-логику и логику доступа к данным предполагает разные уровни абстракции в различных частях приложения. Разложение же приложения на части согласно различным уровням абстракции представляет иерархию, которую можно использовать, чтобы разделить одну программу на несколько одновременно исполняемых модулей. Процесс, реализующий один или несколько уровней в этой иерархии, не должен ничего знать об уровнях, расположенных выше или ниже. Поэтому за исключением обмена информацией между процессами в различных слоях (рисунок 1.1) каждый процесс независим и самодостаточен. Процесс на одном уровне не нуждается в прямом доступе к структурам данных, расположенным на другом уровне; следовательно, он может быть легко выделен в отдельно исполняемую программу.
Такое разделение минимизирует взаимодействие между составными элементами, уменьшая объем передаваемой информации и упрощая алгоритмы, отвечающие за связь между процессами, и потому служит основой для выделения компонентов, которые могут быть распределены на нескольких компьютерах.
Архитектуры прикладных систем
Как можно заметить, самая «древняя», централизованная архитектура обеспечивает намного более масштабируемое решение, чем две следующих. Потребовалось три поколения, прежде чем эти распределенные архитектуры смогли эффективно конкурировать с решением, ориентированным на универсальный компьютер: построить распределенную систему гораздо труднее.
Централизованная архитектура
Одна мощная универсальная ЭВМ была единственной платформой, выполняющей все алгоритмы логики приложения (рис. 2). У централизованной архитектуры множество достоинств: простая разработка приложений, легкость обслуживания и управления. Именно они и обеспечили столь долгую жизнь «унаследованных» систем.
Разделение файлов
Особое внимание следует уделить одному из типов серверов - файловому серверу (File Server). В распространенной терминологии для него принято сокращенное название - файл-сервер .
Файл-сервер хранит данные пользователей сети и обеспечивает им доступ к этим данным. Это компьютер с большой емкостью оперативной памяти, жесткими дисками большой емкости и дополнительными накопителями.
Он работает под управлением специальной операционной системы, которая обеспечивает одновременный доступ пользователей сети к расположенным на нем данным.
Файл-сервер выполняет следующие функции: хранение данных, архивирование данных, синхронизацию изменений данных различными пользователями, передачу данных.
Едва появившись, ПК принесли ожидание того, что большое число маленьких машин может заменить, а, в некоторых случаях, и превзойти по производительности универсальную ЭВМ. Архитектура разделения файлов, ставшая первым шагом к реализации этого притязания, включает множество настольных ПК и файловый сервер, связанных сетью (рис. 3). Файловый сервер загружает файлы из разделяемого местоположения, а прикладные программы исполняются полностью на настольных ПК.
Подобная архитектура была особенно популярна при использовании продуктов наподобие dBASE, FoxPro и Clipper. Первоначально сети персональных компьютеров были основаны на метафоре совместного использования файлов, потому что это было просто. Однако она хорошо работала лишь в некоторых случаях. Во-первых, все приложения должны вписаться в единственный ПК. Во-вторых, совместное использование и конфликты обновления чрезвычайно снижают производительность. Наконец, учитывая пропускную способность сети, объем данных, которые могут передаваться, также невелик. Все эти факторы крайне ограничивают число параллельных пользователей, которое способна поддерживать архитектура разделения файлов.
Клиент-сервер
Стремление исправить архитектуру разделения файлов привело к замене файлового сервера сервером баз данных (рис. 4). Вместо передачи файлов целиком он пересылает только ответы на запросы клиентов, уменьшая нагрузку на сеть. Эта стратегия вызвала появление архитектуры клиент-сервер. Появившись в 80-х годах, она ввела понятие «клиента» (сторона, запрашивающая функции/обслуживание) и «сервера» (сторона, предоставляющая функции/обслуживание). На уровне программного обеспечения разделение на клиента и сервер является логическим: процессы клиента и сервера могут физически размещаться как на одной, так и на разных машинах. Под общим концептуальным названием скрываются три варианта архитектуры: двухзвенная, трехзвенная и многозвенная.
Самая старая — двухзвенная. Она разделяет приложение на две части, клиентскую и серверную. Сторона клиента содержит логику представления, а логика доступа к данным, СУБД и сама база находятся на стороне сервера.
Остаются алгоритмы бизнес-логики, которые могут быть размещены как на машине клиента вместе с логикой представления (конфигурация «толстый клиент»), так и на стороне сервера (конфигурация «тонкий клиент»), или даже могут быть разделены между ними. Конфигурация «толстый клиент» более распространена: суммарная вычислительная мощность клиентов, по крайней мере, в теории, предполагается большей, чем мощность единственного сервера. Подобный ход рассуждений привел некоторых из разработчиков к созданию приложений, где даже логика доступа к данным размещается на клиенте, оставляя серверу только поддержание самой базы данных.
Двухзвенная архитектура, особенно конфигурация «толстый клиент», имеет ряд недостатков. Например, как и в архитектуре разделения файлов, — это ограничение, вытекающее из вычислительной мощности отдельных машин клиентов.
Но еще хуже имеющее фундаментальный характер ограничения на число одновременных соединений с сервером. Сервер поддерживает открытое соединение со всеми активными клиентами, даже если никакой работы нет. Хорошим примером возникновения подобной проблемы может служить работа прокси-сервера.
В некоторых прикладных системах бизнес-логику пытаются реализовать, используя хранимые процедуры. Идея состоит в том, чтобы в соответствии с «тонкой» конфигурацией клиента переместить алгоритмы бизнес-логики на серверную машину, ближе к данным, которые требуются им постоянно. Это выглядит как хорошая идея, однако только усугубляет главную проблему. Так как осуществляющие бизнес-правила процессы теперь управляются СУБД, число пользователей, которых может поддерживать такая система, ограничено максимумом возможных активных соединений с СУБД. Кроме того, от СУБД к СУБД механизмы хранимых процедур разнятся. Тем не менее, двухзвенная архитектура хорошо работает в маленьких рабочих группах. С начала 90-х годов появилась масса инструментальных средств, упрощающих создание систем в такой архитектуре, в том числе Delphi и PowerBuilder.
Сервер приложений

Рисунок 1.2. Трехзвенная архитектура с сервером приложений
Клиенты (рисунок 1.2) содержат только слой логики представления прикладного ПО, а алгоритмы бизнес-логики и логики доступа к данным перемещены в среднее звено. В этом случае сервер приложений обеспечивает «общее хранилище» бизнес-правил и процедур. Клиенты соединяются с сервером приложений и предоставляют ему данные для обработки. Совместное использование алгоритмов бизнес-логики, общих для всего приложения, обладает важными достоинствами. Помимо «утоньшения» клиента, эта стратегия ведет к созданию системы, в которой будущие обновления прикладного ПО будут производиться, главным образом, на сервере приложений, что упрощает процесс модификаций.
Обычно сервер приложений поддерживает пул ограниченного числа открытых подключений к базам данных и вместо того чтобы делать каждое подключение к базе данных выделенным для определенного клиента (как в двухзвенной архитектуре), подключения многократно используются для выполнения запросов различных клиентов.
Есть и другие преимущества. Во-первых, так как вся «важная» часть прикладной логики теперь централизована в среднем звене, нет необходимости поддерживать сложные механизмы аутентификации на стороне клиентов.
Во-вторых, аппаратная платформа, на которой выполняется сервер приложений, может быть достаточно мощной; это дает дополнительную степень масштабируемости всей прикладной системы.
В-третьих, централизованный доступ к данным в серверах приложений делает всю прикладную систему менее зависящей от конкретной СУБД.
Наконец, сервер приложений обеспечивает эффективную стратегию для интеграции. Придерживаясь того же протокола коммуникации, что и клиент, другое «внешнее» приложение может легко взаимодействовать с «чужим» сервером приложений. Эта конфигурация допускает интеграцию приложений не только на уровне данных, но и на уровне правил бизнес-логики. Это чрезвычайно важно, потому что совместное использование данных разными прикладными программами может вести к логическим противоречиям в базе данных. Типичное решение состоит в том, чтобы копировать одни и те же правила и алгоритмы в несколько прикладных программ. Но тогда очень затрудняются их поддержка и обновление — любое изменение кода должно проводиться во всех прикладных программах, которые его используют. Если же бизнес-правила сосредоточены на сервере приложений и используются совместно, то такой проблемы нет.
Отличие «многозвенной» архитектуры от «двухзвенной». Довольно распространена модель работы, когда клиент обращается не непосредственно к серверу БД, а к промежуточной программе . Эта программа обычно называется сервером приложений . Такую архитектуру называют «трехзвенной» , в отличие от «двухзвенной» архитектуры клиент-сервер.
Мониторы обработки транзакций. Мониторы обработки транзакций (transaction processing monitor, TPM) — самый старый тип технологии распределенных систем, которая появилась в 70-х годах в среде больших универсальных ЭВМ . Одной из первых прикладных систем была интерактивная среда поддержки, созданная компанией Atlantic Power and Light для совместного использования прикладных служб и информационных ресурсов в режимах пакетной обработки и с применением среды с разделением времени. TPM (например, IBM CICS) стали главным инструментом построения высоко масштабируемых решений для сетевых прикладных систем. Однако в начале 90-х популярность TPM начала падать; причиной стало появление продуктов категории TPM «Lite» — мониторов обработки транзакций внутри СУБД. Их функциональные возможности были близки к обычным TPM, и с возрастающей тогда популярностью двухзвенной архитектуры они первоначально обеспечили хорошее решение для создания распределенных прикладных систем.
К концу десятилетия ситуация изменилась. Оказалось, что в то время как обычный монитор транзакций может легко поддерживать тысячи пользователей, их производительность становится недопустимо низкой, когда совокупность пользователей превышает 100. Сегодня TPM снова вернулись, но теперь это технология, которая воплощает среднее звено в трехзвенной архитектуре.
Клиенты связываются с мониторами, посылая запросы на транзакции. Так как коммуникации асинхронны, после того, как запрос послан, клиент может выполнять другие задачи. Каждый запрос ставится в очередь, и монитор может обработать его позднее. Поддерживая различные схемы приоритетов, можно определить, в каком порядке запросы принимаются из очереди на обработку. Мониторы постоянно поддерживают установленное число подключений к базам данных, поэтому непосредственного соответствия между клиентами и подключениями к базе данных нет. Вместо этого мониторы мультиплексируют запросы от различных клиентов по одному и тому же подключению — точно так же, как и серверы приложений.
Одно из достоинств процессора транзакций — способность обращаться к гетерогенным источникам данных (реляционные и сетевые базы данных, плоские файлы и т.д.). Поэтому каждый TPM содержит логику доступа к данным, которая выполняет соответствующее преобразование, связанное с различными источниками.

Рисунок 1.3. Трехзвенная архитектура с монитором обработки транзакций
Самая простая конфигурация — клиент-A взаимодействует только с одним монитором TPM-A (рисунок 1.3), который обеспечивает доступ к данным, расположенным на одном компьютере (Сервер Данных A). При помощи двухфазного протокола фиксации монитор может обеспечивать семантику транзакций и с несколькими базами данных. Таким образом, транзакция одного клиента будет фактически разбита между несколькими базами данных; эта ситуация показана в случае с TPM-B, который взаимодействует с источниками данных на нескольких машинах (Сервер Данных A, Сервер Данных B и Сервер Данных C). В этом случае, если подтранзакция терпит неудачу на одном из серверов, все другие подтранзакции также откатываются назад, а Клиент-B получает сообщение о таком событии.
Отношения между клиентами и мониторами, так же как и между мониторами и источниками данных, фактически являются отношениями «многие-ко-многим». Эта конфигурация часто используется, чтобы обеспечить балансировку нагрузки. Когда число пользователей увеличивается, система может запускать дополнительные экземпляры мониторов, обеспечивающих доступ к одним и тем же источникам данных.
В этой конфигурации мониторы могут также обеспечить инфраструктуру для разработки систем, способных обрабатывать ошибки. Например, как видно из рисунке 1.3 , Клиент-C и Клиент-D могут обращаться к одним и тем же источникам данных (Сервер Данных C и Сервер Данных D) либо через TPM-C, либо через TPM-D, причем каждый монитор выполняется на своем собственном компьютере. Если один из мониторов выходит из строя, то все клиенты могут переключаться на все еще работающий монитор. Система в этом случае замедлится, но будет способна обеспечить исходный набор функций.
Сервер сообщений
Вместо монитора транзакций приложение может использовать сервер сообщений. Он обладает большинством существенных преимуществ монитора транзакций. Клиенты взаимодействуют с сервером сообщения асинхронно, помещая в очередь сообщения, которые обрабатываются позднее. В свою очередь, сервер сообщений поддерживает пул доступных подключений к базе данных, которые он может использовать многократно. Но вместо предопределенных запросов, с которыми должен работать монитор, само сообщение содержит достаточно информации относительно того, что нужно с ним делать.
У каждого сообщения есть заголовок и тело. Заголовок определяет, что должно быть сделано с сообщением (скажем, выполнить бизнес-правило или хранимую процедуру, послать его в базу данных или передать его другому серверу сообщений). Последнее позволяет осуществлять коммуникации не только между клиентом и базой данных, но и между клиентами или между клиентом и базами данных, доступными через различные серверы сообщений (рисунок 1.4).

Рисунок 1.4. Трехзвенная архитектура с сервером сообщений
Используя механизмы передачи с промежуточным хранением, сообщения могут обходить точки отказов по альтернативным маршрутам и дополнительным серверам сообщений.
Это похоже на использование нескольких мониторов, обслуживающих одних и тех же клиентов и связанных с одними и теми же источниками данных. Но в отличие от мониторов, сообщение может быть пропущено через несколько серверов сообщений прежде чем оно, наконец, достигнет своего адресата.
Более того, «интеллект», который направляет сообщение по дополнительному пути, находится не на клиенте, а на сервере сообщений. Таким образом, отказы могут оставаться полностью скрытыми от клиента.
Большинство серверов сообщений поддерживает несколько протоколов связи и выполняется на различных платформах.
В результате прикладная система, построенная с серверами сообщений, может охватывать весьма сложные гетерогенные среды, состоящие из компьютеров разных платформ, различных операционных систем, сетей и протоколов коммуникаций.
Ясно, что помимо создания таких переносимых приложений, серверы сообщений играют очень важную роль в интеграции, позволяя совместно использовать сообщения, данные и бизнес-правила.
Брокер объектных запросов
Брокер объектных запросов (object request broker, ORB) обеспечивает инфраструктуру, поддерживающую распределенные объекты, которыми можно управлять, как и объектами, расположенными «рядом» с процессом, работающим с ними. По вызову метода (в смысле объектно-ориентированного программирования) на одном компьютере может фактически выполняться некоторый программный код другого, притом, что доступ к данным в пределах распределенного объекта может потребовать получения соответствующей информации из удаленной базы данных. Все эти детали остаются скрытыми от прикладной программы.
Использование брокера объектных запросов в трехзвенной архитектуре очень похоже на использование сервера сообщений. Единственное различие состоит в том, что взаимодействие осуществляется на объектном уровне, а не на уровне отдельных сообщений. Эта парадигма, объединенная с мощью объектно-ориентированного программирования, делает распределенные объекты очень привлекательной стратегией для разработки распределенных систем.

Рисунок 1.5. Трехзвенная архитектура с брокером объектных запросов
Пример использования двух брокеров объектных запросов показан на рисунке 1.5. Как и в случае сервера сообщения, бизнес-логика разделена между клиентами и ORB. Однако доступ к процедурам, физически расположенным на брокере, остается скрытым от клиентов при помощи распределенных объектов. Через конкретное выполнение распределенных объектов в среднем звене можно мультиплексировать запросы клиентов на одном и том же пуле подключений к базам данных. В качестве источника данных можно использовать объектно-ориентированную СУБД, однако разного рода «упаковщики» могут обеспечивать доступ к другим источникам (базы данных других типов, плоские файлы и т. п.).
Точно так же распределенные объекты могут «упаковывать» другие прикладные программы. Поэтому интеграция приложений может осуществляться не просто на уровне бизнес-правил, но на уровне объектов. Эти два подхода, однако, очень похожи. Так как бизнес-правила скрыты в методах объекта, совместное использование объекта подразумевает совместное использование бизнес-правил. Но объект также содержит информацию о состоянии, поэтому он допускает интеграцию и на уровне данных.
Выводы
1. С самого начала в развитии программного обеспечения всегда можно было выделить два основных направления: выполнение вычислений и, с другой стороной, накопление и обработка информации. В настоящее время доминирующим является второе направление.
2. Современные информационные системы, удовлетворяя информационные потребности различных групп пользователей (конечные пользователи, администрация БД, прикладные программисты и др.), содержат необходимое оборудование (сетевое, компьютеры и др.) и включают ПО (СУБД и прикладное ПО) для работы с данными, сосредоточенными в базах данных (информационная компонента ИС).
3. Интегрированность и общность данных, профессиональное управление ними, некоторая независимость приложений пользователя от изменений на уровне хранения данных, − все это немалые преимущества фактографических баз данных.
Теоретические вопросы для самоконтроля
Назначение сервера, рабочей станции
Технология передачи данных по локальной сети
Функции, распределяемые между клиентской и серверной частью приложения
Преимущества и недостатки двухзвенной архитектуры удаленных баз данных;
Преимущества и недостатки трехзвенной архитектуры удаленных баз данных.
Распределенная обработка данныхОсновные понятия распределенной обработки. Основные условия и требования к распределенной обработке данных. Модели клиент-сервер в технологии распределенных баз данных.
Создание и применение информационных систем в сетях компьютеров, с одной стороны, дает заметные преимущества, с другой стороны, вызывает ряд проблем. В частности, возникают проблемы администрирования и защиты информации.
Основные понятия распределенной обработки.
При размещении СУБД на персональном компьютере, который не находится в сети, БД всегда используется в монопольном режиме. Даже если с ней работают несколько пользователей, они могут работать только последовательно.
Однако, как показала практика применения локальных баз данных, в большинстве случаев информация, которая в них содержится, носит многопользовательский характер, поэтому возникает необходимость разработки таких СУБД, которые обеспечили бы возможность одновременной работы пользователей с базами данных.
Системы управления базами данных, обеспечивающие возможность одновременного доступа к информации различным пользователям называют системами управления распределенными базами данных. В общем случае режимы использования БД имеют вид, представленный на рисунке 2.1.

Рисунок 2.1. Режимы работы с базами данных
Основные понятия, применяемые в системах управления распределенными базами данных.
Пользователь БД - программа или человек, обращающийся к базе данных.
Запрос - процесс обращения пользователя к БД с целью ввода, получения или изменения информации в БД.
Транзакция - последовательность операций модификации данных в БД, переводящая БД из одного непротиворечивого состояния в другое непротиворечивое состояние.
Логическая структура БД - определение БД на физически независимом уровне; ближе всего соответствует концептуальной модели БД.
Топология БД, или структура распределенной БД - схема распределения физической организации базы данных в сети.
Локальная автономность означает, что информация локальной БД и связанные с ней определения данных принадлежат локальному владельцу и им управляются.
Удаленный запрос - запрос, который выполняется с использованием модемной связи.
Возможность реализации удаленной транзакции — обработка одной транзакции, состоящей из множества SQL -запросов, на одном удаленном узле.
Поддержка распределенной транзакции допускает обработку транзакции, состоящей из нескольких запросов SQL, которые выполняются на нескольких узлах сети (удаленных или локальных), но каждый запрос в этом случае обрабатывается только на одном узле.
Распределенный запрос -запрос, при обработке которого используются данные из БД, расположенные в разных узлах сети.
Системы распределенной обработки данных в основном связаны с первым поколением БД, которые строились на мультипрограммных операционных системах и использовали централизованное хранение БД на устройствах внешней памяти центральной ЭВМ и терминальный многопользовательский режим доступа. При этом пользовательские терминалы не имели собственных ресурсов, т.е. процессоров и памяти, которые могли бы использоваться для хранения и обработки данных. Первой полностью реляционной системой, работающей в многопользовательском режиме, была СУБД SYSTEM R фирмы IBM. Именно в ней были реализованы как язык манипулирования данными SQL, так и основные принципы синхронизации, применяемые при распределенной обработке данных, которые до сих пор являются базисными практически во всех коммерческих СУБД.
Основные условия и требования к распределенной обработке данных.
Такая отличительная особенность БД, как многоцелевое параллельное использование данных, предопределяет наличие средств, обеспечивающих практически одновременный и независимый доступ к одним и тем же данным. Причем сама база может быть размещена на одном или нескольких компьютерах, сформулированные ведущими поставщиками СУБД, свойства "идеальной" системы управления распределенными базами данных:
прозрачность относительно расположения данных: СУБД должна представлять все данные так, как если бы они были локальными;
прозрачность относительно сети: СУБД должна одинаково работать в условиях разнородных сетей;
гетерогенность системы: СУБД должна работать с данными, которые хранятся в системах с различной архитектурой и производительностью (независимость от СУБД);
поддержка распределенных запросов: пользователь должен иметь возможность объединять данные из любых баз, даже если они размещены в разных системах;
поддержка распределенных изменений: пользователь должен иметь возможность изменять данные в любых базах, на доступ к которым у него есть права, даже если эти базы размещены в разных системах;
поддержка распределенных транзакций: СУБД должна выполнять транзакции, выходящие за рамки одной вычислительной системы, и поддерживать целостность распределенной БД даже при возникновении отказов как в отдельных системах, так и в сети;
безопасность: СУБД должна обеспечивать защиту всей распределенной БД от несанкционированного доступа;
универсальность доступа: СУБД должна обеспечивать единую методику доступа ко всем данным.
Однако ни одна из существующих СУБД не достигает этого идеала вследствие следующих практических проблем:
низкая и несбалансированная производительность сетей передачи данных, что в распределенных транзакциях сильно снижает общую производительность обработки;
обеспечение целостности данных в распределенных транзакциях базируется на принципе "все или ничего", и требует специального протокола двухфазного завершения транзакций, что приводит к длительной блокировке изменяемых данных;
необходимо обеспечить совместимость данных стандартного типа, для хранения которых в разных системах используются разные физические форматы и кодировки;
выбор схемы размещения системных каталогов. Если каталог будет храниться в одной системе, то удаленный доступ будет замедлен. Если будет размножен - изменения придется распространять и синхронизировать;
необходимо обеспечить совместимость СУБД разных типов и поставщиков;
увеличение потребностей в ресурсах для координации работы приложений с целью обнаружения и устранения тупиковых ситуаций в распределенных транзакциях.
Именно указанные причины определили на практике частичность и "этапность" введения в СУБД тех или иных возможностей распределенной обработки данных. В простейшем случае пользователь имеет возможность обращаться по сети к записям в БД, размещенным на других компьютерах. В других случаях СУБД сама производит аутентификацию удаленного клиента и устанавливает сетевые соединения.
В общем случае режимы работы с БД можно классифицировать по следующим признакам
многозадачность - однопользовательский или многопользовательский;
правило обслуживания запросов - последовательное или параллельное;
схема размещение данных - централизованная или распределенная БД.
Следует отметить, что общая тенденция развития технологий обработки данных вполне соответствует этапам развития средств вычислительной техники и информационных технологий, и в первую очередь, - сетевых. В этом смысле следует выделить два класса: системы распределенной обработки данных и системы распределенных баз данных.
Системы распределенной обработки данных в основном отражают структуру и свойства многопользовательских операционных систем с базой данных, размещенной на большом центральном компьютере (мэйнфрейме). Еще до недавнего времени это был единственно возможный вариант вычислительной среды для реализации больших баз данных Клиентские места в этом случае реализовались в виде терминалов или мини-ЭВМ, обеспечивающих в основном ввод-вывод данных и не имеющих собственных вычислительных ресурсов для функционально-ориентированной обработки получаемых данных.
Развитие сетевых технологий в сочетании с широким распространением персональных ЭВМ и внедрением стандартов открытых систем привело к появлению систем баз данных, размещенных в сети разнотипных компьютеров. Такие системы распределенных баз данных обеспечивают обработку распределенных запросов, когда при обработке одного запроса используются ресурсы базы, размещенные на различных ЭВМ сети. Система распределенных баз данных состоит из узлов, каждый из которых является СУБД, а узлы взаимодействуют между собой так, что база данных любого узла будет доступна пользователю, как если бы она была локальной.
Соответственно, программы, обеспечивающие целевую (функциональную) обработку данных, могут быть организованы таким образом, чтобы обеспечить более эффективное использование совокупных вычислительных ресурсов за счет специализированного разделения функций обработки между центральным процессом СУБД и клиентскими функционально-ориентированными процедурами.
Для "типового" приложения обработки данных можно выделить следующие группы (уровни) функций:
ввод и отображение данных: внешний (пользовательский) уровень реализации целевой функциональной обработки и представления (Presentation logic);
функциональная обработка, реализующая алгоритм решения задач пользователя соответствующие "бизнес-правила" реализуются обычно средствами высокоуровневого языка программирования или расширенного языка манипулирования данными типа ADABAS Natural или 4-GL (Business logic);
манипулирование данными БД в рамках приложения, которое обычно реализуется средствами SQL (Database logic);
управление данными и другими ресурсами БД, реализуемое специализированными (внутренними) средствами конкретной СУБД обычно в рамках файловой системы ОС;
управление процессами обработки: связывание и синхронизация процессов обработки данных разного уровня.
Модели клиент-сервер в технологии распределенных баз данных
Вычислительная модель клиент—сервер связана с появлением в 1990-х гг. открытых систем. Термин «клиент—сервер» применялся к архитектуре программного обеспечения, которое состояло из двух процессов обработки информации: клиентской и серверной. Клиентский процесс запрашивал некоторые услуги, а серверный процесс обеспечивал их выполнение. При этом предполагалось, что один серверный процесс может обслужить множество клиентских процессов. Учитывая что аппаратная реализация этой моде ли управления базами данных связана с созданием локальных вычислительных сетей предприятия, такую организацию процесса обработки информации называют архитектурой клиент—сервер. Основной принцип технологии клиент—сервер применительно к технологии управления базами данных заключается в разделении функций стандартного интерактивного приложения на пять групп, имеющих различную природу:
функции ввода и отображения данных (Presentation Logic);
прикладные функции, определяющие основные алгоритмы решения задач приложения (Business Logic);
функции обработки данных внутри приложения (Database Logic);
функции управления информационными ресурсами (Database Manager System);
служебные функции, играющие роль связок между функциями первых четырех групп.
Структура типового приложения, работающего с базой данных в архитектуре клиент—сервер, приведена рисунке 2.2.

Рисунок 2.2 Структура типового приложения, работающего с базой данных
Презентационная логика (Presentation Logic) как часть приложения определяется тем, что пользователь видит на своем экране, когда работает приложение. Сюда относятся все интерфейсные экранные формы, которые пользователь видит или заполняет в ходе работы приложения. К этой же части относится все то, что выводится пользователю на экран как результаты решения некоторых промежуточных задач либо как справочная информация.
Поэтому основными задачами презентационной логики являются:
формирование экранных изображений;
чтение и запись информации в экранные формы;
управление экраном;
обработка движений мыши и нажатие клавиш клавиатуры.
Бизнес-логика, или логика собственно приложений (Business processing Logic), — это часть кода приложения, которая определяет собственно алгоритмы решения конкретных задач приложения. Обычно этот код пишется с использованием различных языков программирования, таких как С, C++, Visual-Basic и др.
Логика обработки данных (Data manipulation Logic) — это часть кода приложения, которая непосредственно связана с обработкой данных внутри приложения. Данными управляет собственно СУБД. Для обеспечения доступа к данным используется язык SQL.
Процессор управления данными (Database Manager System Processing) — это собственно СУБД. В идеале функции СУБД должны быть скрыты от бизнес-логики приложения, однако для рассмотрения архитектуры приложения их надо выделить в отдельную часть приложения.
В централизованной архитектуре (Host-based processing) эти части приложения располагаются в единой среде и комбинируются внутри одной исполняемой программы.
В децентрализованной архитектуре эти задачи могут быть по-разному распределены между серверным и клиентским процессами.
В зависимости от характера распределения можно выделить следующие модели распределений:
распределенная презентация (DP — Distribution Presentation);
удаленная презентация (RP — Remote Presentation);
распределенная бизнес-логика (RBL — Remote business logic);
распределенное управление данными (DDM — Distributed data management);
удаленное управление данными (RDM — Remote data management).
Эта условная классификации показывает, как могут быть распределены отдельные задачи между серверным и клиентскими процессами. В этой классификации отсутствует реализация удаленной бизнес-логики. Считается, что она не может быть удалена сама по себе полностью, а может быть лишь распределена между разными процессами, которые могут взаимодействовать друг с другом.
Двухуровневые модели. Двухуровневая модель фактически является результатом распределения пяти указанных выше функций между двумя процессами, которые выполняются на двух платформах: на клиенте и на сервере. В чистом виде почти никакая модель не существует, однако рассмотрим наиболее характерные особенности каждой двух уровневой модели: модели удаленного управления данными и модели удаленного доступа к данным.
Модель удаленного управления данными. Она также называется моделью файлового сервера (FS — File Server). В этой модели презентационная логика и бизнес-логика располагаются на клиентской части. На сервере располагаются файлы с данными, и поддерживается доступ к файлам. Функции управления информационными ресурсами в этой модели находятся на клиентской части.

Рисунок 2.3. Модель файлового сервера
Распределение функций в этой модели представлено на рисунке 2.3.
В этой модели файлы базы данных хранятся на сервере, клиент обращается к серверу с файловыми командами, а механизм управления всеми информационными ресурсами, собственно база метаданных, находится на клиенте.
Достоинство этой модели заключается в том, что приложение разделено на два взаимодействующих процесса. При этом сервер (серверный процесс) может обслуживать множество клиентов, которые обращаются к нему с запросами. Собственно СУБД должна находиться в этой модели на клиентском компьютере.
Алгоритм выполнения клиентского запроса сводится к следующему.
Запрос формулируется в командах ЯМД. СУБД переводит этот запрос в последовательность файловых команд.
Каждая файловая команда вызывает перекачку блока информации на компьютер клиента, а СУБД анализирует полученную информацию; если в полученном блоке не содержится ответ на запрос, то принимается решение о перекачке следующего блока информации, и т.д.
Перекачка информации с сервера на клиентский компьютер производится до тех пор, пока не будет получен ответ на запрос клиента.
Данная модель имеет следующие недостатки:
высокий сетевой трафик, который связан с передачей по сети множества блоков и файлов, необходимых приложению;
узкий спектр операций манипулирования с данными, который определяется только файловыми командами;
отсутствие адекватных средств безопасности доступа к данным (защита только на уровне файловой системы).
Модель удаленного доступа к данным. В модели удаленного доступа (RDA — Remote Data Access ) база данных хранится на сервере. На сервере же находится и ядро СУБД. На компьютере клиента располагается презентационная логика и бизнес-логика приложения.

Рис. 4. Структура модели удаленного доступа к данным
Клиент обращается к серверу с запросами на языке SQL. Структура модели удаленного доступа приведена на рис. 4.
Преимущества данной модели заключаются в следующем:
перенос компонента представления и прикладного компонента на клиентский компьютер существенно разгружает сервер БД, сводя к минимуму общее число выполняемых процессов в операционной системе;
сервер БД освобождается от несвойственных ему функций; процессор или процессоры сервера целиком загружаются операциями обработки данных запросов и транзакций;
резко уменьшается загрузка сети, так как по ней от клиентов к серверу передаются не запросы на ввод-вывод в файловой терминологии, а запросы на SQL, а их объем существенно меньше. В ответ на запросы клиент получает только данные, соответствующие запросу, а не блоки файлов.
Основное достоинство RDA -модели — унификация интерфейса клиент—сервер (стандартом при общении приложения-клиента и сервера становится язык SQL).
Данная модель имеет следующие недостатки:
запросы на языке SQL при интенсивной работе клиентской части приложения могут существенно загрузить сеть;
так как в этой модели на клиенте располагается и презентационная логика, и бизнес-логика приложения, то при повторении аналогичных функций в разных приложениях код соответствующей бизнес-логики должен быть повторен для каждого клиентского приложения. Это вызывает излишнее дублирование приложения;
сервер в этой модели играет пассивную роль, поэтому функции управления информационными ресурсами должны выполняться на клиенте.
Выводы:
1. При разработке ИС приходится решать две основные задачи: задачу разработки базы данных, предназначенной для хранения информации и задачу разработки графического интерфейса пользователя клиентских приложений.
2. Тип используемой СУБД обычно определяется масштабом информационной системы − малые информационные системы могут использовать локальные СУБД, в КИС потребуется мощная клиент-серверная СУБД, поддерживающая многопользовательскую работу.
3. По технологии обработки данных информационные системы подразделяются на централизованные и распределенные.
4. При удаленном (сетевом) доступе к данным возможны альтернативные технологии: файл-сервер и клиент-сервер.
5. Основными преимуществами клиент-серверной технологии является уменьшение загрузки сети и облегчение организации многопользовательского доступа.
6. В настоящее время наиболее популярными являются реляционные базы данных.
7. Традиционным методом организации информационных систем является двухзвенная архитектура клиент-сервер.
9. Средства разработки приложений делят на специализированные и универсальные.
Теоретические вопросы для самоконтроля:
Сформулируйте основные требования к системам управления распределенными базами данных.
Перечислите основные условия и предпосылки появления систем управления распределенными базами данных.
Перечислите основные различия системы распределенной обработки данных и системы распределенных баз данных.
Обоснуйте целесообразность разделения «клиентских» и «серверных» функций .
Дайте определения следующих понятий:
топология БД, или структура распределенной БД;
локальная автономность;
удаленный запрос;
поддержка распределенной транзакции;
презентационная логика;
бизнес-логика.
Какие двухуровневые модели вы знаете? Назовите их достоинства и недостатки.
Базовые архитектуры распределенной обработки данныхНедостатки настольных СУБД обычно проявляются не сразу, а лишь в процессе длительной эксплуатации, когда объем хранимых данных и число пользователей становятся достаточно большими - это приводит к снижению производительности приложений, использующих такие СУБД.
Поскольку настольные СУБД не содержат специальных приложений и сервисов, управляющих данными, а используют для этой цели файловые сервисы операционной системы, вся реальная обработка данных в таких СУБД осуществляется в клиентском приложении и любые библиотеки доступа к данным в этом случае также находятся в адресном пространстве клиентского приложения. Это означает, что при выполнении запросов данные, которыми манипулирует такой запрос (это может быть одна или несколько таблиц целиком, либо, если повезет, один или несколько индексов и выбранные с их помощью части таблиц), должны быть доставлены в то же самое адресное пространство клиентского приложения. Это и приводит к перегрузке сети при увеличении числа пользователей и объема данных.
Известно много случаев, когда для решения подобных проблем, с целью увеличения пропускной способности сети, закупалось дорогое сетевое оборудование, а также применялись иные "ухищрения" наподобие хранения метаданных или наиболее часто используемых данных в клиентских приложениях или просто на локальных жестких дисках. Нередко также применялся подход, приводящий к децентрализации хранения данных.
Типичный пример подобного подхода - создание нескольких однотипных локальных баз данных, например для различных подразделений компании или для разных временных периодов (лет, кварталов, месяцев), что облегчало работу, связанную с вводом данных, но повышало стоимость их статистической обработки и анализа - в этом случае нужно было обрабатывать данные из разных источников. Однако все эти меры позволяли лишь отложить на время решение проблемы снижения производительности, но не устраняли главного недостатка информационных систем, основанных на применении настольных СУБД, - обработка данных по-прежнему осуществлялась в клиентском приложении.
Радикальным решением проблемы сетевого трафика и иных проблем, возникающих при увеличении объема данных и числа пользователей, стал переход к архитектуре "клиент-сервер", позаимствовавшей многие достоинства старой "мэйнфреймовой" модели вычислений, в частности - централизацию хранения и обработки данных.
Архитектура "клиент-сервер". Почти все модели организации взаимодействия пользователя с базой данных построены на основе модели "клиент - сервер". То есть предполагается, что каждое такое приложение отличается способом распределения функций обработки данных между, как минимум, двумя частями:
клиентской, которая отвечает за целевую обработку данных и организацию взаимодействия с пользователем;
серверной, которая обеспечивает хранение данных, обрабатывает запросы и посылает результаты клиенту для специальной обработки.
В общем случае предполагается, что эти части приложения функционируют на отдельных компьютерах, т. е. к серверу БД с помощью сети подключены компьютеры пользователей (клиенты).
Сервер - это программа, реализующая функции собственно СУБД: определение данных, запись - чтение данных, поддержка схем внешнего, концептуального и внутреннего уровней, диспетчеризация и оптимизация выполнения запросов, защита данных.
Клиент - это различные программы, написанные как пользователями, так и поставщиками СУБД, внешние или "встроенные" по отношению к СУБД. Программа-клиент организована в виде приложения, работающего "поверх" СУБД, и обращающегося для выполнения операций над данными к компонентам СУБД через интерфейс внешнего уровня.
Разделение процесса выполнения запроса на "клиентскую" и "серверную" компоненту позволяет:
различным прикладным (клиентским) программам одновременно использовать общую базу данных;
централизовать функции управления, такие, как защита информации, обеспечение целостности данных, управление совместным использованием ресурсов;
обеспечивать параллельную обработку запроса в случае распределенных БД;
высвобождать ресурсы рабочих станций и сети;
повышать эффективность управления данными за счет использования ЭВМ, специально разработанных для работы СУБД (серверы баз данных и машины баз данных).
Преимущества архитектуры "клиент-сервер"
Информационные системы, использующие архитектуру "клиент-сервер", обладают серьезными преимуществами по сравнению с их аналогами, созданными на основе сетевых версий настольных СУБД.
Ниже мы рассмотрим наиболее важные из них.
Одним из главных преимуществ архитектуры "клиент-сервер" является снижение сетевого трафика при выполнении запросов.
Например, при необходимости выбора пяти записей из таблицы, содержащей миллион записей, клиентское приложение посылает серверу запрос, который сервером анализируется на корректность и, если запрос корректен, компилируется, оптимизируется и выполняется. После этого результат запроса (те самые пять записей, а не вся таблица) передается обратно клиенту. При этом, формулируя запрос, можно не задумываться о том, есть ли в базе данных индексы, способные облегчить поиск нужных записей, - если они есть, то они будут использованы сервером, а если нет, запрос все равно будет выполнен, хотя, возможно, это займет больше времени, чем при использовании индексов. Но в любом случае - есть индексы, или нет - в клиентское приложение передается только результат запроса, и в этом случае сетевой трафик не зависит ни от их наличия, ни от числа записей в таблицах, к которым произведен запрос.
Вторым преимуществом архитектуры "клиент-сервер"- является возможность хранения бизнес-правил (например, правил ссылочной целостности или ограничений на значения данных) на сервере, что позволяет избежать дублирования кода в различных клиентских приложениях, использующих общую базу данных. Кроме того, в этом случае любое редактирование данных, в том числе и редактирование средствами, не предусмотренными разработчиками информационной системы (например, различными утилитами администрирования сервера), может быть произведено только с учетом этих правил. Если последние версии некоторых настольных СУБД и способны хранить ограничения на значения данных либо тексты SQL-запросов, то триггеры и хранимые процедуры в них, как правило, отсутствуют - их просто некому выполнять. Исключением здесь, пожалуй, является только Microsoft Data Engine, но отнести к настольным эту СУБД можно весьма условно - фактически MSDE представляет собой локальный сервер баз данных, обладающий всеми характерными для серверной СУБД атрибутами, включая отдельный серверный процесс.
Для описания серверных бизнес-правил в наиболее типичных ситуациях (например, при реализации связей "один ко многим") и для создания диаграмм "сущность-связь" нередко используются так называемые CASE-средства. Эти инструменты позволяют описать бизнес - правила на уровне логической и физической моделей данных без какого бы то ни было программирования, а затем сгенерировать код соответствующих серверных объектов - триггеров, хранимых процедур, представлений, серверных ограничений. В этом случае клиентские приложения будут избавлены от значительной части кода, связанного с реализацией бизнес - правил непосредственно в приложении. Отметим также, что часть кода, связанного с обработкой данных, также может быть реализована в виде хранимых процедур сервера, что позволяет еще больше "облегчить" клиентское приложение. В этом случае снижаются требования к рабочим местам пользователей, что в конечном итоге снижает стоимость всей информационной системы даже при использовании дорогостоящих серверной СУБД и аппаратного обеспечения.
Помимо перечисленных выше трех преимуществ следует также отметить, что современные серверные СУБД обладают широкими возможностями управления пользовательскими привилегиями и правами доступа к различным объектам базы данных. Как правило, в базе данных хранятся сведения о ее пользователях, их паролях и привилегиях, а каждый объект базы данных принадлежит какому-либо пользователю. Владелец объекта может предоставить другим пользователям право использовать его тем или иным способом (например, позволить читать из него данные какому-либо другому пользователю). Большинство серверных СУБД поддерживает так называемые роли, представляющие собой совокупность прав на доступ к тем или иным объектам базы данных. В этом случае каждый пользователь может иметь одну или несколько ролей и, соответственно, определенные в этих ролях привилегии.
Выше мы рассмотрели преимущества архитектуры "клиент-сервер" и убедились, что эта технология решает многие проблемы, возникающие при использовании настольных СУБД.
Базовые архитектуры распределенной обработки данных.
Учитывая, что одним из основных показателей эффективности сетевой обработки данных является время обслуживания запроса, рассмотрим различные модели архитектуры распределенной обработки на примере, когда прикладная программа работы с базой данных, расположенной на сервере, загружена на рабочую станцию, и пользователю необходимо получить все записи, удовлетворяющие некоторым поисковым условиям.

Рисунок 3.1. Архитектура "файл - сервер"
В архитектуре "файл - сервер", схема которой представлена на рис. 3, средства организации и управления базой данных (в том числе и СУБД) целиком располагаются на машине клиента, а база данных, представляющая собой обычно набор специализированных структурированных файлов, на машине-сервере. В этом случае серверная компонента представлена даже не средствами СУБД, а сетевыми составляющими операционной системы, обеспечивающими удаленный разделяемый доступ к файлам Таким образом, "файл-сервер" представляет собой вырожденный случай клиент-серверной архитектуры.
Взаимодействие между клиентом и сервером происходит на уровне команд ввода-вывода файловой системы, которая возвращает запись или блок данных. Запрос к базе, сформулированный на языке манипулирования данными, преобразуется самой СУБД в последовательность команд ввода-вывода, которые обрабатываются операционной системой машины-сервера.
Достоинство: возможность обслуживания запросов нескольких клиентов.
Недостатки:
высокая загрузка сети и машин-клиентов, так как обмен идет на уровне единиц информации файловой системы - физических записей, блоков или даже файлов, из которых на машине клиента будут выбраны и представлены необходимые для приложения элементы данных;
низкий уровень защиты данных, так как доступ к файлам БД управляется общими средствами ОС-сервера;
низкий уровень управления целостностью и непротиворечивостью информации, так как бизнес-правила функциональной обработки, сосредоточенные на клиентской части, могут быть противоречивыми и несинхронизированными.
В среде файлового сервера программа управления данными, которая выполняется на машине-клиенте, должна осуществить запрос каждой записи базы, после чего она может определить, удовлетворяет ли запись поисковым условиям, лишь после этого передать запись для функциональной обработки. Очевидно, что для этой схемы характерно наибольшее суммарное время обработки информации.
Архитектура "выделенный сервер базы данных". В архитектуре сервера базы данных, схема которой представлена на рисунке 3.2, средства управления базой данных и база данных размещены на машине-сервере.
Взаимодействие между клиентом и сервером происходит на уровне команд языка манипулирования данными СУБД (обычно SQL), которые обрабатываются СУБД на машине-сервере. Сервер базы данных осуществляет поиск записей и анализирует их. Записи, удовлетворяющие условиям, могут накапливаться на сервере и после того, как запрос будет целиком обработан, пользователю на клиентскую машину передаются все логические записи (запрашиваемые элементы данных), удовлетворяющие поисковым условиям.

Рисунок 3.2. Архитектура с выделенным сервером базы данных
Достоинства:
возможность обслуживания запросов нескольких клиентов;
снижение нагрузки на сеть и машины сервера и клиентов;
защита данных осуществляется средствами СУБД, что позволяет блокировать не разрешенные пользователю действия;
сервер реализует управление транзакциями и может блокировать попытки одновременного изменения одних и тех же записей.
Недостатки:
бизнес-логика функциональной обработки и представление данных могут быть одинаковыми для нескольких клиентских приложений и это увеличит совокупные потребности в ресурсах при исполнении вследствие повторения части кода программ и запросов;
низкий уровень управления непротиворечивостью информации, так как бизнес-правила функциональной обработки, сосредоточенные на клиентской части, могут быть противоречивыми.
Данная технология позволяет снизить сетевой трафик и повысить общую эффективность обработки за счет оптимизации и буферизации ввода-вывода. Таким образом, сервер может осуществлять поиск и обрабатывать запросы даже быстрее, чем если бы они обрабатывались на рабочей станции.
Архитектура "активный сервер баз данных". Для того, чтобы устранить недостатки, свойственные архитектуре сервера базы данных, необходимо, чтобы непротиворечивость бизнес-логики и изменения базы данных контролировались на стороне сервера. Причем некоторые заранее специфицированные состояния могли бы изменять последовательность взаимодействия приложения с базой данных.
Для этого функции бизнес-логики разделяются между клиентской и серверной частями. Общие или критически значимые функции оформляются в виде хранимых процедур, включаемых в состав базы данных. Кроме этого вводится механизм отслеживания событий БД - триггеров, также включаемых в состав базы. При возникновении соответствующего события (обычно изменения данных), СУБД вызывает для выполнения хранимую процедуру, связанную с триггером, что позволяет эффективно контролировать изменение базы данных.
Хранимые процедуры и триггеры могут быть использованы любыми клиентскими приложениями, работающими с базой данных. Это снижает дублирование программных кодов и исключает необходимость компиляции каждого запроса (рисунок 3.3

Рисунок 3.3. Архитектура "активный сервер баз данных"
Недостатком такой архитектуры становится существенно возрастающая загрузка сервера за счет необходимости отслеживания событий и выполнения части бизнес-правил.
Такую архитектуру организации взаимодействия (а также рассматриваемый далее сервер приложений) иногда называют моделью с "тонким клиентом", в отличие от предыдущих архитектур, называемых моделью с "толстым клиентом", где на стороне клиента выполняется большинство функций.
Архитектура "сервер приложений". Рассмотренные выше архитектуры являются двухзвенными: здесь все функции доступа и обработки распределены между программой клиента и сервером БД. Дальнейшее снижение уровня требований к ресурсам клиента достигается за счет введения промежуточного звена - сервера приложений, на который переносится значительная часть программных компонентов управления данными и большая часть бизнес-логики. При этом серверы баз данных обеспечивают исключительно функции СУБД по ведению и обслуживанию базы данных. Схема трехзвенной архитектуры сервера приложений приведена на рисунок 3.4..

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

Рисунок 3.5. Архитектура сервера "один к одному"
Таким образом, даже если от клиентов поступят совершенно одинаковые запросы, для обработки каждого из них будут запущены отдельные процессы, каждый из которых будет выполнять одинаковые действия и использовать одни и те же ресурсы.
Многопотоковая односерверная архитектура
Обработку всех клиентских запросов выполняет один серверный процесс (использующий один процессор), взаимодействующий со всеми клиентами и монопольно управляющий ресурсами (рисунок 3.6). При этом для отдельного клиентского процесса создается поток (thread), в рамках которого локализуется обработка запроса.

Рисунок 3.6. Многопотоковая односерверная архитектура
Мультисерверная архитектура
В том случае, когда для работы СУБД используются многопроцессорные платформы, обслуживание запросов может быть физически распределено для параллельной обработки между процессорами (рисунок 3.7.). Такое решение требует введения дополнительного звена, в задачи которого входит диспетчеризация запросов для обеспечения сбалансированной загрузки процессоров.

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

Теоретические вопросы для самоконтроля:
Между какими частями приложения, построенного на модели "клиент-сервер" распределяются функции обработки данных.
Укажите преимущества архитектуры "клиент-сервер".
Опишите схему функционирования информационной системы типа файл-сервер с несетевой СУБД.
Перечислите достоинства и недостатки каждой их базовых архитектур ("файл-сервер", "выделенный сервер базы данных", "активный сервер баз данных", "сервер приложений" )
Дайте понятия хранимых процедур, триггеров, представлений.
Перечислите базовые архитектуры распределенной обработки.
Задание для самоконтроля:
Опишите схему функционирования модели обработки клиентских запросов архитектуры "один к одному", многопотоковая односерверная архитектура, мультисерверная архитектура, параллельная обработка запроса.
4. Основные технологии доступа к данным и типовые элементы доступаРазработка приложений на основе COM. Назначение и основные характеристики технологий ADO, MIDAS, MTS, CORBA. Многоуровневые приложения.
Во все времена одной из актуальнейших задач, стоящих перед разработчиками ПО, было обеспечение взаимодействия между отдельными программами. Для ее решения используется целый арсенал различных способов и приемов.
На заре существования Windows были внедрены разделяемые файлы, буфер обмена и технология динамического обмена данными (DynamicDataExchange, DDE).
Для обеспечения обмена данными и предоставления служб был разработан первый вариант технологии связывания и внедрения объектов (ObjectLinkingandEmbedding – OLE 1). она предназначалась для создания составных документов – того, к чему мы все уже давно привыкли. Эта технология была во многом несовершенной, и на смену ей пришла технология OLE 2. Она представляет способ решения более общей проблемы – как научить разные программы предоставлять друг другу собственные функции (службы) и как научить их правильно использовать эти функции.
Для решения этой проблемы помимо OLE был разработан целый ряд технологий. В основе этих разработок лежит базовая технология ComponentObjectModel (COM) - Многокомпонентная Модель Объектов. Она часть ПО предоставляет для использования собственные службы, а другая получает к ним доступ. При этом совершенно не важно, где расположены эти части – в одном процессе, в разных процессах на одном компьютере или на разных компьютерах.
Дополнительные возможности разработчикам распределенных приложений на основе COM дает модификация базовой технологии – распределенная модель COM (DistributedCOM, DCOM).
В настоящее время COM используется в самых различных областях разработки ПО. На основе COM разработаны технологии автоматизации (Automation),ActiveX, ActiveFormMicrosoftTransactionServer. На базе COM создано большинство новейших продуктов (MS Office, MTS, …) и технологий Windows (Automation, Drag & Drop, ...).
В составе DELPHI работают две динамические библиотеки OLE32.DLLOLEAUT32.DLL, которые содержат базовые интерфейсы и общие функции COM.
Разработка приложений на основе COM. Во все времена одной из актуальнейших задач, стоящих перед разработчиками ПО, было обеспечение взаимодействия между отдельными программами. Для ее решения используется целый арсенал различных способов и приемов.
На заре существования Windows были внедрены разделяемые файлы, буфер обмена и технология динамического обмена данными (DynamicDataExchange, DDE).
Для обеспечения обмена данными и предоставления служб был разработан первый вариант технологии связывания и внедрения объектов ObjectLinkingandEmbedding – OLE 1. она предназначалась для создания составных документов – того, к чему мы все уже давно привыкли. Эта технология была во многом несовершенной, и на смену ей пришла технология OLE 2. Она предоставляет способ решения более общей проблемы – как научить разные программы предоставлять друг другу собственные функции (службы) и как научить их правильно использовать эти функции.
Для решения этой проблемы помимо OLE был разработан целый ряд технологий. В основе этих разработок лежит базовая технология ComponentObjectModel(COM) – Многокомпонентная Модель Объектов. Она описывает способ взаимодействия программ любого типа. Одна часть ПО предоставляет для использования собственные службы, а другая получает к ним доступ. При этом совершенно не важно, где расположены эти части – в одном процессе, в разных процессах на одном компьютере или на разных компьютерах.
Для созданных на основе спецификаций COM приложений также неважно, какой язык программирования использовался при их разработке – если стандарт COM соблюден, взаимодействие осуществляется без помех.
В настоящее время COM используется в самых различных областях разработки ПО. На основе COM разработаны технологии Автоматизации (Automation), ActiveX, ActiveFormMicrosoftTransactionServer.
В составе Delphi работают две динамические библиотеки OLE32.dllOLEAUT32.dll, которые содержат базовые интерфейсы и общие функции COM.
COM – это технология, позволяющая объектам взаимодействовать, несмотря на границы процесса или машины, так же легко, как и объектам внутри одного процесса. COM обеспечивает такое взаимодействие, определяя, что единственный путь управления данными, ассоциированными с объектом, лежит через интерфейс объекта. Термин «интерфейс», о котором речь пойдет чуть ниже, означает реализацию в коде COM-совместимого двоичного интерфейса, ассоциированного с объектом.
СОМ – общая технология взаимодействия объектов стандартизующая как сами объекты, так и методы их взаимодействия. Это спецификация, строящаяся на базе эталонных реализаций. COM является платформно-независимой, объектно-ориентированной технологией, позволяющей создавать бинарные компоненты. Эти компоненты можно использовать как локально, так и в распределенном сетевом окружении. COM служит основой для: OLE (технология составных документов), ActiveX-объектов и элементов управления ActiveX, DCOM, COM+.
DCOM (Distributed COM) – это расширение COM, делающее эту модель распределенной, то есть позволяющей вызывать COM-объекты, находящиеся на другом компьютере в сети.
COM+ – это эволюция COM и MTS. COM+ полностью встроен в Windows 2000. Он существенно расширяет возможности своих предшественников. COM+ обратно совместим с DCOM, MTS и COM, и позволяет создавать распределенные приложения, клиентские части которых можно запускать на старых ОС (Windows 9x и Windows NT).
Напомним, что в модели COM все основано на интерфейсах. Интерфейс - это контракт между реализующим данный интерфейс компонентом и клиентом, представленный набором определений методов (ничего кроме определений методов в интерфейс включать нельзя). Один и тот же интерфейс могут реализовать различные компоненты, написанные на разных языках, но любой компонент, реализующий данный интерфейс, гарантирует полную реализацию его семантики, т.е. определенный набор методов.
COM-объект. В технологии COM приложение предоставляет для использования свои службы, применяя для этого объекты COM. Одно приложение содержит как минимум один объект. Каждый объект имеет один или несколько интерфейсов . Каждый интерфейс объединяет методы объекта, которые обеспечивают доступ к свойствам (данным) и выполнение операций. Обычно в интерфейсе объединяются все методы, выполняющие операции одного типа или работающие с однородными свойствами.
Клиент получает доступ к службам объекта только через интерфейс и его методы. Этот механизм является ключевым. Клиенту достаточно знать несколько базовых интерфейсов, чтобы получить исчерпывающую информацию о составе свойств и методов объекта. Поэтому любой клиент может работать с любым объектом, независимо от их среды разработки. Согласно спецификации COM, уже созданный интерфейс не может быть изменен ни при каких обстоятельствах. Это гарантирует постоянную работоспособность приложений на основе COM, невзирая на любые модернизации.
Объект всегда работает в составе сервера COM. Сервер может быть динамической библиотекой или исполняемым файлом. Объект может иметь собственные свойства и методы или использовать данные и службы сервера.
Для доступа к методам объекта клиент должен получить указатель на соответствующий интерфейс. Для каждого интерфейса существует собственный указатель. После чего клиент может использовать службы объекта, просто вызывая его методы. Доступ к свойствам объектов осуществляется только через его методы.
Предположим, что объект COM встроен в электронную таблицу и обеспечивает доступ к математическим операциям. Будет логично разделить математические функции на группы по типам и создать для каждой группы собственный интерфейс. Например, можно выделить линейные, тригонометрические, агрегатные функции и т.д. На рис. 1. объект расположен внутри сервера – электронной таблицы. Интерфейсы обозначены кружками, связанными с объектом. Пусть интерфейс линейных функций называется ILinear, а интерфейс агрегатных функций –IAggregate.
Объект СОМ – это некоторая сущность, имеющая состояние и методы доступа, позволяющие изменять это состояние. СОМ-объекты можно создавать прямым вызовом специальных функций, но напрямую уничтожить его невозможно. Вместо прямого уничтожения используется механизм самоуничтожения, основанный на подсчете ссылок. Самым близким аналогом в объектно-ориентированных языках программирования является понятие объекта в языке Java
Так, в COM присутствует понятие класса. Класс в COM носит название CoClass.
Взаимодействие между клиентом и объектом обеспечивается базовыми механизмами COM. При этом от клиента скрыто, где именно расположен объект: в адресном пространстве того же процесса, в другом процессе или на другом компьютере. Поэтому с точки зрения разработчика клиентского ПО использование функций электронной таблицы выглядит как обычное обращение к методу объекта. Механизм обеспечения взаимодействия между удаленными элементами COM называется маршалингом (marshalling).
Любой объект COM является обычным экземпляром некоторого класса, описывающего его свойства и методы. Информация обо всех зарегистрированных и доступных в данной ОС классах COM собрана в специальной библиотеке COM, которая используется для запуска экземпляра класса – объекта.
Сначала объект обращается к библиотеке COM, передавая ей имя требуемого класса и необходимого в первую очередь интерфейса. Библиотека находит нужный класс и сначала запускает сервер, который затем создает объект – экземпляр класса. После этого библиотека возвращает клиенту указатели на объект и интерфейс. В последующей работе клиент может обращаться непосредственно к объекту и его интерфейсам.
После создания наступает очередь инициализации – объект должен загрузить необходимые данные, считать настройки из системного реестра и т.д. за это отвечают специальные объекты COM, которые называются моникерами (monikers). Они работают скрытно от клиента. Обычно моникер создается вместе с классом.
Довольно реальной представляется ситуация, когда одновременно несколько клиентов обращаются к одному объекту. При соответствующих настройках для каждого клиента создается отдельный экземпляр класса. За выполнение этой операции отвечает специальный объект COM, который называется фабрикой класса.
Наконец, остался не рассмотренным последний вопрос – как клиент может получить информацию об объекте. Например, разработчик клиентского ПО знает, что электронная таблица создана в соответствии со спецификацией COM, но не имеет понятия об объектах COM, которые предоставляют клиентам ее службы. Для разрешения подобных ситуаций разработчик объекта COM может распространять вместе с объектом информацию о типе. Она включает сведения об интерфейсах, их свойствах и методах, параметрах методов.
Эта информация содержится в библиотеке типов, которая создается при помощи специального языка описания интерфейса (InterfaceDefinitionLanguage, IDL).
Объект. Центральным элементом COM является объект. Приложения, поддерживающие COM, имеют в своем составе один или несколько объектов COM. Каждый объект представляет собой экземпляр соответствующего класса и содержит один или несколько интерфейсов. Что же такое объект COM?
Любой объект является экземпляром некоторого класса, т.е. представляет собой переменную объектного типа. Поэтому объект обладает набором свойств и методов, которые работают с этими свойствами. К объектам применимы три основные характеристики: инкапсуляция, наследование и полиморфизм. Объекты COM всем этим требованиям удовлетворяют
Применительно к объектам вообще понятие интерфейса объекта, как он был определен выше, не используется. В первом приближении можно считать, что все методы объекта составляют его единственный интерфейс, а указателем интерфейса является указатель на объект.
Объект COM может иметь любое число интерфейсов (если это число больше нуля), причем каждый интерфейс обладает собственным указателем. Это первое отличие объектов COM от обычных.
У объектов COM имеется особенность еще в одном объектом механизме – наследовании. Вообще различают два способа наследования. Наследование реализации подразумевает передачу родителем потомку всего программного кода. Наследование интерфейса означает передачу только объявления методов, их программный код потомок должен предоставить самостоятельно.
Объекты COM поддерживают только наследование интерфейса, избегая тем самым возможного нарушения инкапсуляции родителя. Тем не менее, просто так выбросить наследование реализации нельзя. Вместо нее объекты COM используют механизм включения, т.е. при необходимости потомок вызывает нужный метод родителя. Также применяется механизм агрегирования, когда один или несколько интерфейсов одного объекта на время включаются в другой объект путем передачи указателей.
Интерфейс
Если объект COM является ключевым элементом реализации COM, то интерфейсы являются центральным звеном идеологии COM. Как двум принципиально разным объектам обеспечить взаимодействие друг с другом? Ответ прост: им необходимо заранее договорится о том, как они будут общаться.
Интерфейс как раз является тем средством, которое позволяет клиенту правильно обратиться к объекту COM, а объекту ответить так, чтобы клиент его понял.
Рассмотрим небольшой пример. На улице случайно встретились два человека: местный житель (объект COM) и заблудившийся иностранец (клиент). Предусмотрительный иностранец взял с собой словарь (библиотека типов или интерфейс IUnknown). Иностранцу нужны знания местного жителя о городе. Он достал ручку и бумагу и, заглянув в словарь, составил фразу и старательно перерисовал незнакомые слова на бумагу. Местный житель оказался не промах. Он прочитал фразу, отобрал у иностранца словарь, составил по нему собственную фразу и тоже написал ее на бумаге. И все закончилось хорошо: довольный клиент (иностранец) получил от объекта COM (местного жителя) результат работы службы (информацию о дороге), а местный житель ушел вместе со словарем.
Как вы уже догадались, в этом примере интерфейсом является бумага и ручка: иностранец не знает чужого языка, зато знает, как правильно спросить, чтобы ему ответили.
Для идентификации каждый интерфейс имеет два атрибута. Во-первых, это его имя, составленное из символов в соответствии с правилами используемого языка программирования. Каждое имя должно начинаться с символа «I». Это имя используется в программном коде. Во-вторых, это глобальный уникальный идентификатор (GloballyUniqueIDentifer, GUID), который представляет собой гарантированно уникальное сочетание символов, практически не повторяемое ни на одном компьютере в мире. Для интерфейсов такой идентификатор носит название IID (Interface Identifier).
В общем случае клиент может не знать, какие интерфейсы имеются у объекта. Для получения их перечня используется базовый интерфейс IUnknown., который есть у любого объекта COM.
Затем клиенту необходимо знать, какие методы имеет выбранный им интерфейс. Для этого разработчик должен распространять описание методов интерфейсов вместе с объектом. Эту задачу помогает решать язык IDL (он также используется в библиотеках типов).
Теперь осталось сделать самое важное – правильно вызвать сам метод. Для этого в COM описана реализация интерфейса на основе стандартного двоичного формата. Это обеспечивает независимость от языка программирования.
Доступный клиенту указатель интерфейса ссылается на внутренний указатель объекта и, через него, на специальную виртуальную таблицу. Эта таблица содержит указатели на все методы интерфейса.
В результате, вызов метода клиентом проходит по цепочке указателей и получает указатель на конкретный метод, а затем исполняется соответствующий программный код.
Реализация интерфейса (interface implementation) – это код, который программист создает для выполнения действий, оговоренных в определении интерфейса. Реализации интерфейсов, помещенные в COM-библиотеки или exe-модули, могут использоваться при создании объектно-ориентированных приложений. Разумеется, программист может игнорировать эти реализации и создать собственные. Интерфейсы ассоциируются с CoClass’ами. Чтобы воспользоваться реализацией функциональности интерфейса, нужно создать экземпляр объекта соответствующего класса, и запросить у этого объекта ссылку на соответствующий интерфейс.
CoClass CoClass – это класс, поддерживающий набор методов и свойств (один или более), с помощью которых можно взаимодействовать с объектами этого класса. Такой набор методов и свойств называется интерфейсом (Interface).
Каждый CoClass имеет два идентификатора – один из них, текстовый, называется ProgID и предназначен для человека, а второй, бинарный, называется CLSID.
Программист никогда не взаимодействует с объектом и его данными напрямую. Для этого используются интерфейсы объектов.
Интерфейс IUnknown
Каждый объект COM обязательно имеет интерфейс IUnknown. Этот интерфейс имеет всего три метода, но они играют ключевую роль в функционировании объекта.
Метод QueryInterface возвращает указатель на интерфейс объекта, идентификатор IID которого передается в параметре метода. Если такого интерфейса объект не имеет, метод возвращает null.
Обычно при первом обращении к объекту клиент получает указатель на интерфейс. Так как любой интерфейс является потомком IUnknown, то любой интерфейс имеет и метод QueryInterface. Поэтому в общем случае не важно, какой именно интерфейс может использовать клиент. При помощи метода QueryInterface он может получить доступ к любому интерфейсу объекта.
Интерфейс IUnknown обеспечивает работу еще одного важного механизма объекта COM – механизма учета ссылок. Объект должен существовать до тех пор, пока его использует хотя бы один клиент. При этом клиент не может самостоятельно уничтожить объект, ведь с ним могут работать и другие клиенты.
Поэтому при передаче наружу очередного указателя на интерфейс объект увеличивает специальный счетчик ссылок на единицу. Если один клиент передает другому указатель на интерфейс этого объекта, то клиент, получающий указатель, обязан еще раз инкрементировать счетчик ссылок. Для этого используется метод AddRef интерфейса IUnknown.
При завершении работы с интерфейсом клиент обязан вызвать метод Release интерфейса IUnknown. Этот метод уменьшает счетчик ссылок на единицу. После обнуления счетчика объект уничтожает себя.
Сервер. Сервер COM представляет собой исполняемый файл приложения или динамическую библиотеку, который содержит один или несколько объектов одного или разных классов. Различают три типа Сервер.
Внутренний сервер (inprocessserver) реализуется динамическими библиотеками, которые подключаются к клиенту и работают в одном адресном пространстве.
Локальный сервер (localserver) создается отдельным процессом, который работает на одном компьютере с клиентом.
Удаленный сервер (remoteserver) создается процессом, который работает на друго компьютере по отношению к клиенту.
Рассмотрим локальный сервер. Получаемый клиентом указатель интерфейса в этом случае ссылается на специальный proxy -объект COM (назовем его заместителем , который функционирует внутри клиентского процесса). Заместитель предоставляет клиенту те же интерфейсы, что и вызываемый объект COM на локальном сервере. Получив вызов от клиента, заместитель упаковывает его параметры и при помощи служб ОС передает вызов в процесс сервера. В локальном сервере вызов передается еще одному специализированному объекту – заглушке (stub), который распаковывает вызов и передает его требуемому объекту COM. Результат вызова возвращается клиенту в обратном порядке.
Рассмотрим удаленный сервер. Он функционирует так же, как и локальный сервер. Однако передача вызовов между двумя компьютерами осуществляется средствами DCOM – с помощью механизма вызова удаленных процедур (RemoteProcedureCall, RPC).
Для обеспечения работы локальных и удаленных серверов используется механизм маршалинга и демершалинга. Маршалинг реализует единый в рамках COM формат упаковки параметров запроса, демаршалинг отвечает за распаковку. В описанных выше реализациях серверов за выполнение этих операций отвечают заместитель и заглушка. Эти типы объектов создаются совместно с основным объектом COM. Для этого применяется IDL.
Библиотека COM. Для обеспечения выполнения общих функций и базовых интерфейсов в ОС устанавливается специальная библиотека COM (конкретная реализация может быть различной). Доступ к функциям библиотеки осуществляется стандартным способом, а не через интерфейс.
Согласно спецификации, имена всех библиотечных функций начинаются с приставки «Со».
При установке использующего COM приложения в системный реестр записывается информация обо всех используемых им объектах COM:
Идентификатор класса (ClassIdentifier, CLSID), который однозначно определяет класс объекта;
Тип сервера объекта – внутренний, локальный или удаленный;
Для локальных и внутренних серверов сохраняется полное имя динамической библиотеки или исполняемого файла;
Для удаленных серверов записывается полный сетевой адрес.
Предположим, что клиент пытается использовать некоторый объект COM, который до этого момента не использовался.
Следовательно, клиент не может получить указатели на объект и интерфейс. В этом случае он обращается к библиотеке COM и вызывает метод CoCreateInstance, передавая ей в качестве параметра CLSID нужного класса, IID интерфейса и требуемый тип сервера.
Библиотека при помощи диспетчера управления службами (ServiceControlManager, SCM) обращается к системному реестру, по идентификатору класса – объект, и возвращает библиотеке указатель на запрошенный интерфейс.
Для неявной инициализации созданного объекта (установки значений свойств) может использоваться специальный объект самостоятельно, применив специальные интерфейсы (IPersistFile, IPersistStorage, IPersistStream).
Фабрика класса. Для запуска экземпляра класса используется специальный объект –фабрика класса. С его помощью можно создать как один объект, так и несколько его экземпляров. Для каждого класса должна существовать собственная фабрика класса.
Объект COM имеет право называться фабрикой класса, если он поддерживает интерфейс IClassFactory. В нем реализованы всего два метода:
- CoCreateInstance – создает новый экземпляр класса. Все необходимые параметры, кроме IID, метод получает от фабрики класса. В этом его отличие от одноименного общего метода библиотеки.
- LockServer –оставляет сервер функционировать после создания объекта.
Для вызова фабрики класса существует специальный общий метод CoClassObject. В качестве параметра ему передается CLSID нужного класса и IID интерфейса (IClassFactory). Метод ищет требуемую фабрику и возвращает указатель на интерфейс. С его помощью и используя метод CoCreateInstance, клиент заставляет фабрику класса создать объект.
Библиотека типов. Чтобы документировать интерфейсы объекта для пользователей, разработчик создает информацию о типах объекта. Для этого используется язык IDL.
Вся информация объединяется в специальной библиотеке типов. Она может описывать свойства и методы (а также их параметры) интерфейсов и содержать сведения о необходимых заглушках и заместителях. Информация об отдельном интерфейсе оформляется в виде отдельного объекта внутри библиотеки.
Для создания библиотеки типов, описанной при помощи операторов IDL, используются специальные компиляторы. Доступ к библиотеке осуществляется по CLSID класса объекта. Кроме того, библиотека имеет собственный GUID, который сохраняется в системном реестре при регистрации объекта.
Каждая библиотека типов имеет интерфейс ItypeLib, который работает с ней, как с единым объектом. Для доступа к информации об отдельном интерфейсе используется интерфейс ItypeInfo.
Для доступа к библиотеке по GUID используется общий метод LoadRegTypeLib. Если клиенту известно имя файла библиотеки, то можно воспользоваться методом LoadTypeLib.
Назначение и основные характеристики технологий ADO, MIDAS, MTS, CORBA
Общие понятия. Отличие «тонкого» клиента от «толстого». «Тонким» клиентом обычно называют пользовательское приложение, не содержащее никакой функциональности, и предназначенное только для ввода/вывода информации. Вся обработка данных производится на сервере БД, либо на сервере приложений. Зачастую, такой клиент изначально не содержит вообще никаких возможностей, а подгружает дополнительные модули с сервера, по мере необходимости. Обычно, в качестве «тонкого» клиента, выступают Web броузер + HTML/ASP/Java. «Толстый» клиент содержит всю функциональность и интерфейсную часть в себе, и при любом изменении, требует замены у всех пользователей.
Технология ADO. ADO (Microsoft ActiveX Data Objects) это технология стандартного обращения к реляционным данным от Microsoft. ADO представляет собой высокоуровневый программный интерфейс для доступа к OLE DB-интерфейсам. Он позволяет манипулировать данными с помощью любых OLE DB-провайдеров, как входящих в состав MDAC(Microsoft Data Access Components) некоторых других продуктов Microsoft, так и произведенных сторонними производителями. ADO содержит набор объектов, используемых для соединения с источником данных, для чтения, добавления, удаления и модификации данных.
DAO, ADO, RDO... Все это похоже на какую-то игру слов, где присутствует два ключевых понятия: данные и объекты. (Data Access Objects — объекты доступа к данным, ActiveX Data Objects — ActiveX-объекты работы с данными, Remote Data Objects — объекты удаленных данных.) На самом же деле речь здесь идет о разных технологиях доступа к данным (см. врезку «Сравнение ADO, DAO и RDO»), которые имеют не только разные внутренние механизмы, но и, что, может быть, гораздо важнее для прикладного программиста, разные перспективы на будущее.
DAO и RDO известны уже достаточно давно, и появление двух разных механизмов было связано с необходимостью оптимизации решения двух отдельных задач: доступа к локальным и удаленным базам данных соответственно. Однако естественное развитие вычислительных систем привело к необходимости создания единого механизма, который обеспечил бы единый подход при работе с БД различных классов.
В результате несколько лет назад Microsoft предложила в качестве единого интерфейса для доступа к локальным и удаленным данным новую технологию ADO, которая сегодня является частью архитектуры Microsoft Universal Data Access (MUDA).
ADO Extension for DDL and Security (ADOX) применяется для решения различных задач, недоступных с помощью обычных объектов ADO. Например, используя объекты ADOX, можно извлекать метаданные из баз данных и, следовательно, переносить структуру данных из одной базы данных в другую (в том числе и иного типа). Вторая возможность, предоставляемая этим расширением, — манипулирование сведениями о безопасности. Например, с помощью ADOX можно получать информацию о пользователях базы данных и группах пользователей, а также создавать новых пользователей и группы. ADOX расширяет объектную модель ADO десятью новыми объектами, которые можно использовать как отдельно, так и вместе с другими объектами ADO, в частности можно применять объект ADO Connection для соединения с источником данных и извлекать метаданные из него.
Прежде чем углубляться в детали объектов ADOX, поговорим о том, что такое метаданные. В общем случае метаданные представляют собой описания объектов базы данных (таблиц, полей, индексов, ключей, представлений, хранимых процедур и прочих объектов). В подавляющем большинстве современных СУБД метаданные определяются с помощью языка SQL (Structured Query Language) . До появления ADOX единственным программным способом извлечения метаданных из источников данных с помощью ADO был метод OpenSchema объекта ADO Connection . Для создания новых объектов в базе данных применялся язык Data Definition Language (DDL) — подмножество языка SQL, а также объект ADO Command .
Многоуровневые приложения
Разработка распределенных корпоративных систем доступа к данным – одна из наиболее высокотехнологических и динамично развивающихся областей современной индустрии ПО. Именно здесь сосредоточены усилия разработчиков прикладного ПО.
Мощные серверы должны обеспечивать бесперебойный доступ к данным сотен клиентов одновременно. При этом клиентское ПО установлено на разных аппаратных платформах и работает под управлением разных ОС. Пользователи могут находится в корпоративной сети, обращаться к серверу через Internet, intranet или по радиоканалу.
Для создания распределенных систем разработаны подходы на основе ряда технологических решений. Используютсятехнологии COM, OLEnterprise, сокеты TCP\IP, Microsoft Transaction Server, CORBA.
Для работы с корпоративными БД используются многоуровневые приложения, т.к. эффективное взаимодействие с БД многих пользователей может обеспечить только ПО промежуточного уровня. Серверы приложений решают задачи управления запросами клиентов и результатами запросов, разграничения доступа, сохранения целостности данных т.д. Причем и в этой сфере существуют готовые решения на основе вышеперечисленных технологий.
Создание средств разработки корпоративных систем доступа к данным является основным направлением деятельности фирмы Inprise.
В Delphi можно создавать приложения для распределстренных систем на основе всех перечисленных подходов. Для этого предназначена специальная технология MIDAS (Multi-tiredDistributedApplicationService) – Службы многоуровневых распределенных приложений. Она обеспечивает создание приложений для распределенных систем баз данных на основе единого подхода.
Многоуровневые приложения представляют собой распределенные системы удаленного доступа к данным, которые состоят как минимум их трех логических уровней.
1. Сервер БД , который обеспечивает функционирование используемой приложением БД и непосредственную обработку запросов пользователей. Для создания серверов БД имеются готовые решения, предоставляемые целым рядом компаний. В зависимости от назначения БД, объема, решаемых задач всегда можно подобрать наиболее подходящий вариант.
2. сервер приложений, который составляет так называемое ПО промежуточного слоя. Обычно это специально разработанная программа, которая обеспечивает взаимодействие клиентов с сервером БД. В этой области всегда найдутся проблемы, которые необходимо решать: конфликты доступа к данным, регистрация, управление транзакциями и т.д.поэтому сервер приложений предоставляет минимально необходимый промежуточный уровень. Обычно он называется брокером данных. Серьезные многоуровневые приложения имеют несколько уровней ПО промежуточного слоя. Из наиболее распространенных решаемых задач можно выделить регистрацию пользователей и разграничение доступа, защита от несанкционированного доступа, управление блокировками. Часто промежуточный уровень должен обеспечить доступ к БД клиентов с разными программными и аппаратными платформами.
3. Совокупность клиентских программ или клиентский уровень приложения . В рассматриваемом случае используются «тонкие » (или «слабые») клиенты, которые, в отличие от аналогичных программ в архитектуре клиент/сервер, выполняют только минимальные функции по отображению данных и передаче запросов серверу, а результатов – обратно.
Технология MIDAS позволила вынести BDE в отдельный уровень – сервер приложений, который обеспечивает взаимодействие множества клиентов с сервером БД. Это стало возможным за счет применения удаленных модулей данных.
Технология MIDAS
Таким образом, мы подошли к важнейшей особенности настоящих многоуровневых приложений – ПО, обеспечивающее взаимодействие клиентов с БД (в нашем случае это BDE), которое требует установки только на одном компьютере – компьютере сервера приложений (рис. 5). В результате клиентские программы избавляются от лишнего программного кода и становятся чрезвычайно простыми в установке (появился даже новый термин – нуль-конфигурация «тонкого» клиента).
MIDAS - это технология Borland для создания многоуровневых приложений баз данных. Применение данной архитектуры позволяет быстро разрабатывать простые в сопровождении и установке, надежные, распределенные БД. Трехуровневое приложение баз данных содержит несколько компонентов (слоев):
а) Слой БД. Хранит данные. Выполняет функции хранения информации, обеспечения целостности и непротиворечивости данных. Пример -локальные (dBase, Paradox) и серверные БД (Oracle, Sybase, MS SQL), текстовые файлы и т.д.
б) Слой бизнес логики (сервер приложений) - это программа, обеспечивающая доступ клиентов к информации. На этом слое вводится понятие сервиса, как некоей услуги, поставляемой клиенту (например, получение данных об остатке денег на счете, как частный случай из реляционной БД). В этом слое реализуются правила и алгоритмы обработки информации, отражающие поведение реального моделируемого объекта (бизнес правила). Например, проверка остатка денег на не отрицательность, перевод денег со счета на счет.
в) Презентационный слой (тонкий клиент). Задача этого слоя, используя сервисы слоя бизнес логики, предоставлять пользователям запрошенную информацию в форме удобной и приятной во всех отношениях. Может быть выполнен в виде традиционного exe файла или в качестве тонкого клиента можно использовать Web броузер.
Применение данной схемы позволяет создать клиентское приложение, которое практически не требует настройки и сопровождения, вся логика работы с БД сосредоточена в среднем слое (сервере приложений). Соответственно при доработке алгоритмов доступа к БД необходимо лишь переустановить сервер приложений.
MIDAS предназначен для обеспечения связи между слоем бизнес логики и презентационным слоем. Он позволяет организовать взаимодействие тонкого клиента с сервером приложений. При этом сервер приложений взаимодействует с реляционной БД (чаще всего данные хранятся именно в этой форме) как и обычные приложения работы с БД, разработанные в Delphi.
Тонкий клиент для конечного пользователя ничем не отличается от обычного (толстого) клиента БД. Разница в том, что толстый клиент через BDE, ADO, компоненты прямого доступа к серверам БД и другие библиотеки работает с БД, а тонкий клиент взаимодействует с сервером приложений, используя MIDAS. Сервер приложений скрывает от клиента детали доступа и обработки БД. На компьютере с тонким клиентом не нужно устанавливать и настраивать BDE, ADO, клиентскую часть сервера БД. Необходимо лишь иметь небольшие по объему dll, которые легко переносить вместе с exe файлом тонкого клиента. В качестве тонкого клиента может использоваться и Web браузер.
В основе MIDAS лежит использование использование объектной модели COM. MIDAS обеспечивает функционирование в рамках единой службы нескольких технологий удаленного доступа к данным, предоставляя единый стандарт обмена данными между сервером и клиентами.
DCOM – распределенный COM расширение базовой технологии COM, позволяющей клиенту использовать свойства и методы удаленных объектов на сервере. Элементы COM установлены в WindowsNT, Windows 98, Windows 95 требует специальной интсалляции допаолнительного ПО.
Microsoft Transaction Server ( MTS ) – надстройка над базовой технологией COM, обеспечивающая дополнительные функции при взаимодействии клиента и сервера.
Сокеты являются популярным программным интерфейсом доступа к стеку сетевых протоколов и позволяют создавать распределенные приложения для большинства современных систем, включая соединение через Internet.
OLEnterprise – разработанное фирмой Borlandрасширение объектной модели COM, обеспечивающее ряд дополнительных возможностей. С его помощью можно связывать объекты, созданные на разных языках программирования. Соответствующее ПО устанавливается на сервере и клиенте.
CORBA (CommonObjectRequestBrokerArhitecture – Архитектура Брокера Общих Объектных Запросов) представляет собой специально разработанный стандарт и ПО, обеспечивающее взаимодествие объектов, манипулирующих данными в разных ОС. Основу архитектура составляет ORB (ObjectRequestBroker – Брокер Объектных Запросов), обеспечивающий взаимодействие сервера приложений и клиентов.
В соответствии с технологией MIDAS, многоуровневое приложение должно иметь три составные части:
Сервер приложений, который должен содержать в качестве основы удаленный модуль данных;
Клиент, взаимодествие которого с сервером обеспечено спецмальными компонентами и динамической библиотекой DBClient.DLL.
Брокер данных, который обеспечивает передачу пакетов данных на основе интерфейса IProvider.
Технология MTS
Создавая в Delphi многоуровневые приложения на основе DCOM, разработчики могут расширить их возможности за счет использования дополнительных функций, предоставляемых специализированной системной службой MicrosoftTransactionServer (MTS).
MTS может работать с ОС WindowsNT, Windows 98. MTS позволяет достаточно гибко управлять режимами выполнения транзакций в системе и поддерживает двухфазное завершение транзакций. Одним из существенных недостатков схемы управления транзакциями СОМ является необходимость явной передачи контекста транзакции в качестве -аргумента при вызове удаленных методов. Такая схема не является ни эффективной, ни гарантирующей от ошибок, особенно при вовлечении в транзакцию большого количества объектов.
Использование MTS дает серверу ряд дополнительных полезных функций:
При выполнении запросов поддерживаются транзакции;
Работая с сервером, несколько клиентов могут использовать для доступа к данным одно соединение. Так реализуется совместное использованиеи ресурсов БД.
Обеспечивая дополнительное разграничение доступа клиентов к интерфейсам.
Для использования возможностей MTS необходимо только иметь установленные динамические библиотеки этой службы на компьютере сервера приложений.
COM+ является слиянием COM- и MTS- моделей программирования, таким образом справедлива формула:
COM + MTS = COM+
Базовая программная модель и того, и другого являются идентичными: разрабатываются компоненты "в процессе", в них выставляются интерфейсы, для обеспечения автоматизации реализуется IDispatch, реализуется код для регистрации, т.е. в рамках новой парадигмы нужно делать то же, что делалось и ранее.
Однако в дополнение к этому появились новые сервисы, значительно расширяющие возможности приложений.
COM был создан как компонентная технология уровня изолированной рабочей станции.
Потом, с реализацией распределенного COM в NT4 (DCOM), эта технология получила развитие в направлении поддержки удаленных обращений к компонентам. MTS создавался для обеспечения работы серверных компонент и устранения некоторых недостатков DCOM. COM+ появился для унификации и объединения COM, DCOM и MTS в согласованную технологию, понятную и удобную для реализации приложений корпоративного уровня.
Технология CORBA. CORBA (Common Request Broker Architecture) — архитектура для построения распределенных объектных приложений. Была предложена некоммерческой организацией — консорциумом OMG (Object Management Group), состоящей из нескольких сотен ведущих компаний из отрасли разработки программного обеспечения (включая таких гигантов, как Microsoft и Borland/Inprise). Первая спецификация CORBA появилась еще в далеком 1991 году.
Целью разработчиков CORBA было создание механизмов межплатформенного взаимодействия приложений в распределенных системах. Можно поразиться дальновидности OMG — ведь в середине — конце 80-х годов XX века распределенные системы не играли той впечатляющей роли в компьютерной индустрии, как сейчас. Кроме того, расширение экспансии Intel и Microsoft ставило под угрозу само наличие разнообразия аппаратно-программных платформ. Тем не менее, в сложившейся обстановке работы были продолжены, причем результаты были настолько успешны, что даже всемогущий Microsoft счел нужным присоединиться к консорциуму разработчиков, чтобы держать руку на пульсе развития новой перспективной технологии.
Как и DCOM, CORBA основывается на коммуникации типа клиент-сервер. Запрашивая сервис, клиент вызывает метод, реализуемый удаленным объектом, действующим в роли сервера. Сервис, предоставляемый объектом, инкапсулируется с помощью интерфейса, определенного на языке IDL. Именно собственный язык IDL является одной из изюминок CORBA. Вообще, существуют три различных языка описаний под одним и тем же названием: OMG IDL (очевидно, используется в CORBA), Microsoft IDL (разработан для технологии DCOM, но в силу двоичного представления объектов не играет в этой технологии ключевой роли) и OSF IDL. Однако, по сравнению с DCOM, CORBA имеет ряд существенных отличий.
Технология CORBA изначально проектировалась для создания распределенных систем. В силу этого сервер объектов и клиентские программы, в отличие от COM/DCOM, в технологии CORBA, как правило, располагаются на разных машинах. Взаимодействие между клиентом и сервером происходит следующим образом. В процессе клиента имеется объект-посредник, именуемый stub (или Client-Side Stab). Он является полномочным представителем сервера и исполняет функции, во многом сходные с функциями объекта Proxy в технологии DCOM. Именно к stub при помощи интерфейса объекта обращается программа-клиент так, как будто stub и являет собой объект. Далее stub перенаправляет запрос клиента к особому объекту, который действует также на машине клиента. Этот объект называется ORB (Object Required Broker, брокер объектных запросов). Получив запрос, ORB формирует широковещательное сообщение во внешнюю сеть. На это сообщение откликается один из объектов Smart Agent, который функционирует на одном из компьютеров сетевого окружения (локальная сеть или Интернет). Smart Agent знает, где расположены соответствующие серверы объектов (фактически это как бы виртуальный сетевой каталог, где зарегистрированы некоторые серверы), и перенаправляет запрос на нужный сервер. На сервере пакет запроса принимает еще один объект ORB, который дешифрует запрос и пересылает его следующему объекту — BOA (Basic Object Adapter, базовый адаптер объектов). Роль объекта BOA заключается в фильтрации, кэшировании запросов и, соответственно, разграничении доступа к объекту сервера. Если запрос пропущен BOA, то он попадает в объект сервера skeleton. При этом в адресном пространстве сервера создается требуемый объект, skeleton помещает аргументы вызова в стек объекта и реализует собственно вызов. Используя объект BOA, skeleton также регистрирует созданный серверный CORBA-объект с помощью Smart Agent, а также сообщает о доступности, факте создания и о готовности объекта принимать запросы клиента. Далее следует обратная связь по описанной цепочке объектов.
Как видно из описания, CORBA реализует собой типичную многозвенную (здесь — трехзвенную) архитектуру. В роли Middleware — программного обеспечения промежуточного слоя — здесь выступает объект Smart Agent. Обычно при практической реализации программа, выполняющая Действия Smart Agent, устанавливается на выделенную машину в корпоративной сети или на несколько машин в сети Интернет. При создании серверов они регистрируются на ДОСТУПНЫХ Smart Agent.
Выводы
Касательно экономии клиентских мест (может кто и считает плюсом) на самом деле это минус (каждый коннект порождает отдельный процесс, или псевдопроцесс в разных СУБД по разному, который в свою очередь обслуживает каждого клиента в отдельности, поэтому при экономии лицензий один коннект может обслужить сколь угодно много клиентов выстроенных в одну общую очередь, вывод...).
Использовать Socket или DCOM, принципиального значения не имеет, если все написано аккуратно работает и то и другое устойчиво, по скорости так же одинаково. если использовать DCOM то это только Microsoft, со всеми вытекающими как отрицательными так и положительными выводами. DCOM трубует дополнительного администрирования.
Технология позволяет установить и успешно работать удаленным клиентским местам без использования технологии репликации БД. Удаленные места могут связываться с центральным сервером по модему хоть со скоростью 2400, ГРАМОТНО составлять SQL запросы, при скорости модемной линии 19200 от 400-600 записей/сек получает удаленный клиент).
Технология MIDAS позволяет резко понизить ресурсные требования как к клиентам, сети, так и к самим серверам.
DCOM, CORBA, MIDAS, все это "обвертки" и в конечном итоге сводиться к COM сейчас появился COM++, который интегрирован с Win2000.
Технология CORBA носит существенно более общий и универсальный характер, чем COM, что заложено в ее фундаменте. С другой стороны, при разработке реального проекта нужно предварительно убедиться, что высококачественная реализация того или иного сервиса CORBA.
В настоящий момент COM более законченная система, но на более низком уровне и при существенно большем количестве ограничений, определяемых самой концепцией системы.
Теоретические вопросы для самоконтроля:
Назначение технологии MIDAS.
Основные компоненты технологии CORBA.
Особенности и назначение технологий доступа к данным ADO, MIDAS, MTS и CORBA.
5. Средства доступа к удаленным базам данныхПрограммное обеспечение распределенных приложений. Доступ к базам данных в двухзвенных моделях "клиент - сервер". Спецификация вызова удаленных процедур. Корпоративные серверы приложений.
Программное обеспечение распределенных приложений.
Распределенные корпоративные приложения все более усложняются, интегрируя унаследованные приложения, разрабатываемые и вновь приобретаемые готовые программные средства. Кроме того, разные подсистемы решают разные бизнес - задачи, однако одна из главных целей создания корпоративной системы - получить "единый образ" общего состояния системы, что обеспечит пользователям доступ к нужным операциям и ресурсам.
Основа такой инфраструктуры - так называемое промежуточное программное обеспечение, позволяющее, не вникая в тонкости сетевых реализаций, создавать и эксплуатировать взаимодействующие приложения с разными требованиями к межмодульным коммуникациям.
Промежуточное ПО эволюционировало вместе с архитектурой "клиент - сервер". Ранние, но достаточно эффективные как с точки зрения разработки, так и эксплуатации, частные решения предназначались для упрощения доступа к базам данных в двухзвенной модели, где "толстый" клиент реализует всю логику обработки информации, предоставляемой сервером базы данных. Такие системы вполне удовлетворяли потребностям небольших корпоративных подразделений с ограниченным числом пользователей и невысокой интенсивностью обмена.
Однако по мере того, как клиент-серверная архитектура стала проникать в сферу высококритичных корпоративных приложений, обслуживающих уже не десятки, а сотни пользователей, и работающих со значительными массивами данных, стали очевидны недостатки двухзвенного подхода. Этот способ реализации клиент-серверной схемы доступа ограничивал возможности масштабирования, поскольку увеличение числа обращений к одной базе данных непомерно увеличивало нагрузку на сервер и делало доступ к данным "узким местом" в общей производительности системы. Кроме того, всякая модификация логики приложения требовала внесения изменений во все экземпляры клиентских приложений.
Чтобы избежать таких проблем, для разработки корпоративных приложений используют трехзвенную модель, которая переносит логику приложения на отдельный уровень сервера приложений. В результате клиентская часть приложения становится "тоньше" и в основном отвечает за предоставление удобного пользовательского интерфейса. Как правило, сервер баз данных также освобождается от необходимости поддерживать бизнес-логику, которая в двухзвенной модели реализуется с помощью специальных расширений СУБД, например, хранимых процедур. Перенос основных операций приложения на отдельный уровень позволяет с максимальной эффективностью распределить нагрузку на аппаратные средства (трехзвенная модель на самом деле может быть многозвенной с разделением нагрузки на несколько серверов приложений) и обеспечивает безболезненное наращивание как функциональности приложения, так и числа обслуживаемых пользователей.
Развитие этого среднего звена клиент-серверной модели идет в сторону усложнения. Ограничиваясь вначале построением более высокого уровня абстракции для взаимодействия приложения с ресурсами данных, разработчик приложения получал возможность использовать общие API (Application Program Interface), которые скрывали различия специфических интерфейсов коммуникационных протоколов более низкого уровня, например, TCP/IP, Sockets или DECNet. Однако теперь этого уже явно недостаточно для построения сложных распределенных приложений. Современные решения не только обеспечивают межпрограммное взаимодействие, но и являются платформой для реализации сервера приложений, обеспечивая обширный набор необходимых служб: управления транзакциями, именования, защиты и т. д.
Вычислительная среда распределенных приложений может включать в себя различные операционные системы, аппаратные платформы, коммуникационные протоколы и разнообразные средства разработки. Соответственно, формат представления данных в различных узлах будет различаться.
Таким образом, в распределенной неоднородной среде программное обеспечение промежуточного уровня играет роль "информационной шины", надстроенной над сетевым уровнем и обеспечивающей доступ приложения к разнородным ресурсам, а также независимую от платформ взаимосвязь различных прикладных компонентов, изолирующую логику приложений от уровня сетевого взаимодействия и ОС.
ПО промежуточного уровня можно разделить на две категории.
ПО доступа к базам данных (например, ODBC-интерфейсы и SQL-шлюзы).
ПО межмодульного взаимодействия - системы, реализующие вызов удаленных процедур (RFC - Remote Procedure Call); мониторы обработки транзакций (ТР-мониторы); средства интеграции распределенных объектов.
При этом следует отметить, что различия прикладных задач не позволяют построить универсальное ПО, реализовав в одном продукте все необходимые возможности.
Доступ к базам данных в двухзвенных моделях "клиент - сервер"
В простых двухзвенных моделях "клиент - сервер", где несколько баз данных обслуживают ограниченное число пользователей настольных ПК, в роли встроенного ПО доступа к данным могут выступать обычные ODBC-драйверы.
Необходимость в более сложных решениях возникает в больших, разнородных многозвенных системах, где множество приложений в параллельном режиме осуществляют доступ к разнообразным источникам данных, включая разнотипные СУБД и хранилища данных. В таких системах между клиентами и серверами баз данных размещается промежуточное звено - SQL-шлюз, который представляет собой набор общих API, позволяющих разработчику строить унифицированные запросы к разнородным данным (в формате SQL или с помощью ODBC-интерфейса). SQL-шлюз выполняет синтаксический разбор такого запроса, анализирует и оптимизирует его и в конце концов выполняет преобразование в SQL-диалект нужной СУБД. ПО этого типа реализует синхронный механизм связи, когда выполнение приложения, сделавшего запрос, блокируется до момента получения данных.
Примером такого приложения может быть система анализа статистических данных о деятельности компаний, которая отбирает соответствующую информацию из расположенных в различных регионах баз данных с разными СУБД. Подобные решения достаточно просты, не требуют сложных механизмов управления транзакциями и способны обеспечить постепенную миграцию важных приложений с унаследованных платформ в архитектуру "клиент - сервер".
В общем случае предполагается, что эти части приложения функционируют на отдельных компьютерах, т. е. к выделенному серверу БД с помощью сети подключены узлы - компьютеры пользователей (клиенты). При этом узел-клиент сам может быть СУБД.
Создается такое приложение обычно с использованием средств языков высокого уровня (например, C++, Pascal, Visual Basic), позволяющих реализовать эффективную целевую обработку данных и дружественный пользовательский интерфейс. В исходный текст программы включаются SQL-выражения, специфицирующие условия выборки или изменения данных в базе. Во время исполнения приложения эти выражения передаются серверу, который, собственно, и манипулирует данными. Данные, полученные в результате выполнения сервером SQL-запросов, возвращаются прикладной программе и размещаются в заранее определенных структурах для дальнейшей обработки, в том числе корректировки записей.
Рассмотрим различные способы организации доступа прикладной программы к серверу базы данных в двухзвенной архитектуре.
Использование библиотек доступа и встраиваемого SQL
Каждая СУБД помимо интерактивной SQL-утилиты обязательно имеет библиотеку процедур доступа и набор драйверов СУБД для различных операционных систем. Схема взаимодействия клиентского приложения с сервером базы данных в этом случае представлена на рис. 2.
Библиотека доступа содержит набор функций, позволяющих клиентскому приложению соединяться с базой данных, передавать запросы серверу, и получать данные - результаты обработки запроса.
Типичный набор функций такой библиотеки включает:
соединение с базой данных;
запрос к базе данных на выполнение SQL-выражения;
запрос на извлечение данных;
запрос на изменение данных;
закрытие соединения с базой данных.
Обычно в библиотеке присутствуют также функции, позволяющие определить характеристики структуры набора результата (число, порядок и имена столбцов, число строк, номер текущей строки), передвигаться по этой структуре не только вперед, но и назад и т. д.
Библиотечные вызовы преобразуются драйвером базы данных в сетевые вызовы и передаются сетевым программным обеспечением на сервер. На сервере происходит обратный процесс преобразования сетевых пакетов в SQL-запросы, которые обрабатываются СУБД. Результаты обработки передаются клиенту.
Такой способ создания приложений достаточно гибок и позволяет реализовать практически любое приложение, однако имеет и недостатки:
разработка клиентской программы возможна только для той операционной системы и на том языке программирования, в которых поддерживается библиотека;
драйвер базы данных определяет допустимые типы сетевых интерфейсов;
библиотечные функции обычно не унифицированы.
Некоторой модификацией данного способа является использование "встроенного" языка SQL. В этом случае текст программы на языке третьего поколения вместо вызовов функций библиотеки включает непосредственно предложения SQL, которые предваряются выражением "EXEC SQL". Перед компиляцией в машинный код такая программа обрабатывается препроцессором, который транслирует смесь операторов "собственного" языка СУБД и SQL-предложений в промежуточный "чистый" исходный код, а затем коды SQL замещаются вызовами соответствующих процедур из библиотек, поддерживающих конкретную СУБД. Такой подход позволяет несколько снизить степень привязанности к СУБД, например, при переключении прикладной программы на работу с другим сервером базы данных - достаточно указать новый сервер и заново перекомпилировать программу.
Программный интерфейс уровня вызовов. Стандарт SQL2 определил интерфейс уровня вызова (CLI - Call Level Interface), в котором стандартизирован общий набор рабочих процедур, обеспечивающий совместимость со всеми основными типами серверов баз данных.
Технологическая основа CLI - размещаемая на компьютере клиента специальная библиотека, в которой хранятся вызовы процедур и сетевых компонентов для организации связи с сервером. Это программное обеспечение поставляется обычно в составе среды разработки и поддерживает разнообразные сетевые протоколы.
Использование программных вызовов позволяет свести к минимуму операции на компьютере-клиенте. В общем случае клиент формирует оператор языка SQL в виде строки и пересылает ее на сервер посредством процедуры исполнения (execute). Когда же сервер в качестве ответа возвращает несколько строк данных, клиент считывает результат последовательным вызовом процедуры выборки данных. Далее данные из столбцов полученной таблицы могут быть связаны с соответствующими переменными приложения. Вызов специальной процедуры позволяет клиенту определить число полученных строк, столбцов и типы данных в каждом столбце.
Открытый интерфейс доступа к базам данных
Спецификация открытого интерфейса баз данных (ODBC - Open Database Connectivity), предназначена для унификации доступа к данным, размещенным на удаленных серверах. ODBC опирается на спецификации CLI.
ODBC представляет собой программный слой, унифицирующий интерфейс взаимодействия приложений с базами данных. За реализацию особенностей доступа к каждой отдельной СУБД отвечает соответствующий специальный ODBC-драйвер.
Пользовательское приложение этих особенностей не видит, так как взаимодействует с универсальным программным слоем более высокого уровня. Таким образом, приложение становится в значительной степени независимым от СУБД. Вместо создания в каждом отдельном случае СУБД-приложения с обращениями через "родной", но быстро устаревающий интерфейс, можно использовать один общий стандартизированный программный интерфейс.
В архитектуре ODBC используется один ODBC Driver Manager и несколько ODBC-драйверов, обеспечивающих доступ к конкретным СУБД. Driver Manager связывает приложение и интерфейсные объекты, которые выполняют обработку SQL-запросов к конкретной СУБД.
Такой подход является достаточно универсальным, стандартизируемым, что и позволяет использовать ODBC-механизмы для работы практически с любой системой.
Однако этот способ также не лишен недостатков:
увеличивается время обработки запросов (как следствие введения дополнительного программного слоя);
необходимы предварительная инсталляция и настройка ODBC-драйвера (указание драйвера СУБД, сетевого пути к серверу, базы данных и т. д.) на каждом рабочем месте. Параметры этой настройки являются статическими, т. е. приложение их изменить самостоятельно не может.
Мобильный интерфейс к базам данных на платформе Java
JDBC (Java Data Base Connectivity) - это интерфейс прикладного программирования (API) для выполнения SQL-запросов к базам данных из программ, написанных на платформенно - независимом языке Java, позволяющем создавать как самостоятельные приложения (standalone application), так и апплеты, встраиваемые в web-страницы.
JDBC во многом подобен ODBC, он также построен на основе спецификации CLI, однако имеет ряд следующих отличий:
приложение загружает JDBC-драйвер динамически, следовательно, администрирование клиентов упрощается, более того, появляется возможность переключаться на работу с другой СУБД без перенастройки клиентского рабочего места;
JDBC, как и Java в целом, не привязан к конкретной аппаратной платформе, следовательно проблемы с переносимостью приложений практически снимаются;
использование Java-приложений и связанной с ними идеологии "тонких клиентов" обещает снизить требования к оборудованию клиентских рабочих мест.
Прикладные интерфейсы OLE DB и ADO
Встраивание и связывание объектов в базах данных - OLE DB (Object Linking and Embedding Data Base), как и ODBC - прикладные интерфейсы доступа к данным с использованием SQL.
OLE DB специфицирует взаимодействие, обеспечивая единый интерфейс доступа к данным через провайдеров - поставщиков данных не только из реляционных БД. В отличие от ODBC, OLE DB предоставляет общее решение обеспечения СОМ-приложениям доступа к информации независимо от типа источника данных.
OLE DB включает два базовых компонента: провайдер данных и потребитель данных. Потребитель (клиент) - это приложение или СОМ-компонент, обращающийся посредством API-вызовов к OLE DB. Провайдер (сервер) - это приложение отвечающее на вызовы OLE DB и возвращающее запрашиваемый объект - обычно это данные в табличном виде.
ADO (Active Data Object) - это универсальный интерфейс высокого уровня к OLE DB. Модель объекта ADO не содержит таблиц, среды или машины БД. Здесь основными объектами являются следующие: объект Соединение, создающий связь с провайдером данных; объект Набор данных и объект Команда - выполнение процедуры, SQL-строки.
В общем случае ADO можно рассматривать как язык программирования с БД, позволяющий выбирать, модифицировать и удалять записи. И поскольку он опирается на универсальный OLE DB, то может использоваться практически в любых приложения Microsoft.
Спецификация вызова удаленных процедур
Мониторы обработки транзакций
Средства вызова удаленных процедур (RPC) поддерживает синхронный режим коммуникаций между двумя прикладными модулями (клиентом и сервером).
Для установки связи, передачи вызова и возврата результата клиентский и серверный процессы обращаются к специальным процедурам - клиентскому и серверному суррогатам (client stub и server stub). Эти процедуры не реализуют никакой прикладной логики и предназначены только для организации взаимодействия удаленных прикладных модулей.
Каждая функция на сервере, которая может быть вызвана удаленным клиентом, должна иметь такой суррогатный процесс. Если клиент вызывает удаленную процедуру, вызов вместе с параметрами передается клиентскому суррогату. Он упаковывает эти данные в сетевое сообщение и передает его серверному суррогату. Тот, в свою очередь, распаковывает полученные данные и передает их реальной функции сервера и затем проделывает обратную процедуру с результатами. Таким образом прикладные модули клиента и сервера изолируются от уровня сетевых коммуникаций.
По существу, RPC реализует в распределенной среде принципы традиционного структурного программирования. Клиент обращается к процессу-суррогату так, как будто он и есть реальный серверный процесс, и этот вызов ничем не отличается от вызова локальной функции. Как и в случае нераспределенной программы, вызов процедуры на удаленном компьютере влечет за собой передачу управления этой процедуре, то есть блокирует выполнение клиентской программы на время обработки вызова.
В общем случае механизм RPC создает статические отношения между компонентами распределенного приложения - привязка клиентского процесса к конкретным серверным суррогатам происходит на этапе компиляции и не может быть изменена во время выполнения. Этим RPC отличается от таких более выгодных решений, как ТР-мониторы, которые поддерживают возможности оптимального распределения нагрузки на серверы и средства восстановления при сбоях.
Ключевым компонентом RPC является язык описания интерфейсов (Interface Definition Language - IDL), предназначенный для определения интерфейсов, которые задают контрактные отношения между клиентом и сервером. Интерфейс содержит определение имени функции и полное описание передаваемых параметров и результатов выполнения.
Язык IDL обеспечивает независимость механизма RPC от языков программирования - вызывая удаленную процедуру, клиент может использовать свои языковые конструкции, которые IDL-компилятор преобразует в свои описания. На сервере IDL-описания обратно преобразуются в конструкции языка программирования, на котором реализован серверный процесс.
Мониторы обработки транзакций
Первоначально основной задачей мониторов обработки транзакций (ТР-мониторов) в среде "клиент - сервер" было сокращение числа соединений клиентских систем с базами данных. При непосредственном обращении клиента к серверу базы данных для каждого клиента устанавливается соединение с СУБД, которое порождает запуск отдельного процесса в рамках операционной системы. ТР-мониторы брали на себя роль концентратора таких соединений, становясь посредниками между клиентом и сервером базы данных.
Постепенно, с развитием трехзвенной архитектуры "клиент - сервер" функции ТР-мониторов расширились, и они превратились в платформу для транзакционных приложений в распределенной среде с множеством баз данных под различными СУБД.
ТР-мониторы представляют собой одну из самых сложных и многофункциональных технологий в мире промежуточного ПО. Основное их назначение - автоматизированная поддержка приложений, оформленных в виде последовательности транзакций. Каждая транзакция - это законченный блок обращений к ресурсу (как правило, базе данных) и некоторых действий над ним, для которого гарантируется выполнение четырех условий:
атомарность - операции транзакции образуют неразделимый, атомарный блок с определенным началом и концом. Этот блок либо выполняется от начала до конца, либо не выполняется вообще. Если в процессе выполнения транзакции произошел сбой, происходит откат (возврат) к исходному состоянию;
согласованность - по завершении транзакции все задействованные ресурсы находятся в согласованном состоянии;
изолированность - одновременный доступ транзакций различных приложений к разделяемым ресурсам координируется таким образом, чтобы эти транзакции не влияли друг на друга;
долговременность - все изменения данных (ресурсов), осуществленные в процессе выполнения транзакции, не могут быть потеряны.
В системе без ТР-монитора обеспечение этих свойств берут на себя серверы распределенной базы данных, использующие двухфазный протокол (2PC-two-phase commit). Протокол 2РС описывает двухфазный процесс, в котором перед началом распределенной транзакции все системы опрашиваются о готовности выполнить необходимые действия. Если каждый из серверов баз данных дает утвердительный ответ, транзакция выполняется на всех задействованных источниках данных. Если хотя бы в одном месте происходит какой-либо сбой, будет выполнен откат для всех частей транзакции.
Однако в системе с распределенными базами данных выполнение протокола 2РС можно гарантировать только в том случае, если все источники данных принадлежат одному поставщику. Поэтому для сложной распределенной среды, которая обслуживает тысячи клиентских мест и работает с десятками разнородных источников данных, без монитора транзакций не обойтись. ТР-мониторы способны координировать и управлять транзакциями, которые обращаются к серверам баз данных от различных поставщиков благодаря тому, что большинство этих продуктов помимо протокола 2РС поддерживают транзакционную архитектуру (ХА), которая определяет интерфейс для взаимодействия ТР-монитора с менеджером ресурсов, например, СУБД Oracle или Sybase. Спецификация ХА является частью общего стандарта распределенной обработки транзакций (distributed transaction processing - DTP), разработанного X/Open.
Функции современных ТР-мониторов не ограничиваются поддержкой целостности прикладных транзакций. Большинство продуктов этой категории способны распределять, планировать и выделять приоритеты запросам нескольких приложений одновременно, тем самым сокращая процессорную нагрузку и время отклика системы. Обработка запросов организуется в виде "нитей" ОС, а не полновесных процессов, тем самым значительно снижая загруженность системы.
Таким образом, снимается одно из серьезных ограничений производительности и масштабируемости клиент-серверной среды - необходимость поддержки отдельного соединения с базой данных для каждого клиента.
Выводы
Рассмотренные технологии построения приложения ориентированы на извлечение данных непосредственно из статического источника (хранилища данных) и не могут обращаться за данными к другому прикладному модулю.
Функции современных ТР-мониторов не ограничиваются поддержкой целостности прикладных транзакций. Большинство продуктов этой категории способны распределять, планировать и выделять приоритеты запросам нескольких приложений одновременно, тем самым сокращая процессорную нагрузку и время отклика системы.
Таким образом, в распределенной неоднородной среде программное обеспечение промежуточного уровня играет роль "информационной шины", надстроенной над сетевым уровнем и обеспечивающей доступ приложения к разнородным ресурсам, а также независимую от платформ взаимосвязь различных прикладных компонентов, изолирующую логику приложений от уровня сетевого взаимодействия и ОС.
Теоретические вопросы для самоконтроля:
Сформулируйте основные требования к системам управления распределенными базами данных.
Перечислите основные условия и предпосылки появления систем управления распределенными базами данных.
Перечислите основные различия системы распределенной обработки данных и системы распределенных баз данных.
Обоснуйте целесообразность разделения "клиентских" и "серверных" функций.
Проведите сравнительный анализ распределения функций для различных базовых архитектур.
Определите основные принципы и примерные структурные схемы сервера распределенной обработки.
Перечислите основные решения распределенной обработки на основе межмодульного взаимодействия.
6. Виды механизмов доступа к даннымДоступ к базам данных в двухзвенных моделях "клиент - сервер". Универсальная стратегия доступа
Существует несколько способов доступа к данным из средств разработки и клиентских приложений.
Подавляющее большинство систем управления базами данных содержат в своем составе библиотеки, предоставляющие специальный прикладной программный интерфейс (Application Programming Interface, API) для доступа к данным и сервисам этой СУБД. Обычно такой интерфейс представляет собой набор функций, вызываемых из клиентского приложения. В случае настольных СУБД эти функции обеспечивают чтение/запись файлов базы данных, а в случае серверных СУБД - инициируют передачу запросов серверу баз данных и получение от сервера результатов выполнения запросов или кодов ошибок, интерпретируемых клиентским приложением. Библиотеки, содержащие API для доступа к данным серверной СУБД, обычно входят в состав ее клиентского программного обеспечения, устанавливаемого на компьютерах, где функционируют клиентские приложения.
В последнее время Windows-версии клиентского программного обеспечения наиболее популярных серверных СУБД, в частности Microsoft SQL Server, а также СУБД фирм Oracle, IBM и Informix, содержат также СОМ-серверы, предоставляющие объекты для доступа к данным и метаданным.
Использование клиентского API (или клиентских СОМ-объектов) является наиболее очевидным (и нередко самым эффективным с точки зрения производительности) способом манипуляции данными в приложении. Однако в этом случае созданное приложение сможет использовать данные только СУБД этого производителя, а замена ее на другую (например, с целью расширения хранилища данных или перехода в архитектуру "клиент-сервер") повлечет за собой переписывание значительной части кода клиентского приложения - клиентские API и объектные модели не подчиняются никаким стандартам и различны для разных СУБД.
Другой способ манипуляции данными в приложении базируется на применении универсальных механизмов доступа к данным. Универсальный механизм доступа к данным обычно реализован в виде библиотек и дополнительных модулей, называемых драйверами или провайдерами. Библиотеки содержат некий стандартный набор функций или классов, нередко подчиняющийся определенной спецификации. Дополнительные модули, специфичные для той или иной СУБД, реализуют непосредственное обращение к функциям клиентского API конкретных СУБД.
Отметим, что достоинством универсальных механизмов доступа к данным является возможность применения одного и того же абстрактного API, а во многих случаях - СОМ-серверов, компонентов, классов для доступа к разным типам СУБД. Поэтому приложения, использующие универсальные механизмы доступа к данным, легко модифицировать, если необходима смена СУБД. При этом нередко модификация затрагивает не код приложения как таковой, а настройки доступа к данным, содержащиеся в реестре или внешних файлах. Однако за подобную универсальность порой приходится платить невозможностью доступа к уникальной функциональности, специфичной для конкретной СУБД, снижением производительности приложений, а также усложнением процедуры поставки приложения - ведь в его состав нужно включать библиотеки, ответственные за реализацию универсальных механизмов, драйверы для тех или иных СУБД, а также обеспечивать настройки, необходимые для их правильного функционирования.
Наиболее популярными среди универсальных механизмов доступа к данным можно назвать следующие:
Open DataBase Connectivity (ODBC);
OLE DB;
ActiveX Data Objects (ADO);
Borland Database Engine (BDE).
Универсальные механизмы ODBC, OLE DB и ADO фирмы Microsoft представляют собой по существу промышленные стандарты. Что касается механизма доступа к данным BDE фирмы Borland, то он так и не стал промышленным стандартом, однако до недавнего времени применялся довольно широко, поскольку до выхода Delphi 5 был практически единственным универсальным механизмом доступа к данным, поддерживаемым средствами разработки Borland на уровне компонентов и классов.
В общем случае приложение, использующее базы данных, может применять следующие механизмы доступа к ним:
непосредственный вызов функций клиентского API (или обращение к СОМ-объектам клиентских библиотек);
вызов функций ODBC API (или применение классов, инкапсулирующих подобные вызовы);
непосредственное обращение к интерфейсам OLE DB;
применение ADO (или применение классов, инкапсулирующих обращение к объектам ADO) + OLE DB;
применение ADO + OLE DB + ODBC;
применение BDE + SQL Links (или применение классов, инкапсулирующих обращение к функциям BDE);
применение BDE + ODBC Link + ODBC.
Помимо этих существуют и другие способы доступа к данным, обычно в той или иной степени использующие перечисленные универсальные механизмы или непосредственно клиентские API.
Технологии доступа к данным OLE DB и ADO
Универсальный механизм доступа к данным (Universal Data Access) являет собой стратегию предоставления унифицированного доступа к любому типу данных.
Он обеспечивает высокопроизводительный доступ к различным источникам информации (включая реляционные и нереляционные данные), к данным электронной почты и файловой системы, к текстовым, графическим и географическим данным и др. Для многих современных приложений, использующих данные, характерно подобное разнообразие их источников. Более того, вполне очевидно, что могут появляться новые форматы данных и способы их хранения, поэтому разумным требованием к универсальному механизму доступа к данным была бы возможность поддержки не только существующих в настоящее время форматов и источников данных, но и форматов данных, которые будут созданы в будущем.
Назначение универсального механизма доступа к данным фирмы Microsoft - предоставить доступ к перечисленным источникам данных с помощью единой модели доступа к данным.
В настоящее время универсальный механизм доступа к данным фирмы Microsoft поддерживает все наиболее популярные настольные и серверные СУБД.
Ниже рассмотрим следующие основные компоненты архитектуры универсального механизма доступа к данным Microsoft.:
Microsoft ActiveX Data Objects (ADO) представляет собой программный интерфейс для доступа к данным из приложений. С точки зрения программирования ADO и его расширения являются упрощенным высокоуровневым объектно-ориентированным интерфейсом к OLE DB;
OLE DB - это низкоуровневый интерфейс для доступа к данным.
ADO использует OLE DB, но можно использовать OLE DB и напрямую, минуя ADO.
Open Database Connectivity (ODBC) - стандартный способ доступа к реляционным данным. Этот компонент универсального механизма доступа к данным оставлен с целью обеспечения совместимости с прежними версиями программного обеспечения. В современных приложениях применению ODBC-драйверов предпочитают использование OLE DB-провайдеров.

Рисунок 6.1. Архитектура универсального механизма доступа к данным Microsoft
Архитектура универсального механизма доступа к данным Microsoft схематически представлена на рисунке 6.1.
Архитектура и интерфейс OLE DB
Рассмотрим составные части универсального механизма доступа к данным фирмы Microsoft.
OLE DB представляет собой программный интерфейс для доступа к различным источникам данных, таким как реляционные и нереляционные данные, текстовые, графические и географические данные, архивы электронных писем, файловая система, бизнес-объекты. В спецификации OLE DB определен набор СОМ-интерфейсов (COM, Component Object Model, - компонентная модель объектов Microsoft, являющаяся составной частью 32-разрядных версий Windows), инкапсулирующих различные сервисы управления данными и предоставляющих однотипный доступ к перечисленным выше данным. Эти интерфейсы могут быть использованы в приложениях, предоставляющих доступ к данным.
Компоненты OLE DB
На самом верхнем уровне можно отметить три главных компонента OLE DB: потребители данных (consumers), провайдеры данных (data providers) и сервисные компоненты (service components).
Любой компонент программного обеспечения, применяющий интерфейсы OLE DB, является потребителем. Это может быть какое-либо офисное или иное бизнес-приложение, средство разработки типа Visual Basic или Delphi либо даже СОМ-объекты для доступа к данным, применяющие интерфейсы OLE DB. Потребители могут обращаться к данным посредством ActiveX Data Objects (ADO), представляющих собой высокоуровневый интерфейс к OLE DB, или применять OLE DB непосредственно, с использованием OLE DB-провайдера.
Провайдер - это часть программного обеспечения, в которой реализованы интерфейсы OLE DB. С точки зрения OLE DB существуют два типа OLE DB-провайдеров: провайдеры данных и сервисные компоненты.
Провайдер данных - это компонент программного обеспечения, манипулирующий данными. Он располагается между потребителем данных и базой данных. В OLE DB все провайдеры представляют данные в табличном формате (аналогичном тому, в котором хранятся данные в реляционных СУБД и файлах электронных таблиц), в виде виртуальных таблиц.
Провайдер данных выполняет следующие функции:
получение от потребителя запросов на получение или модификацию данных;
получение данных из базы данных или их модификация в базе данных;
возвращение данных потребителю.
Примером провайдеров данных является провайдер Microsoft Jet 4.0 OLE DB Provider, который используется для доступа к данным Microsoft Access, а также к данным I-ISAM (Installable Indexed Sequential Access Method), файлам рабочих книг Excel, хранилищ данных Microsoft Outlook и Microsoft Exchange, таблиц dBase и Paradox, текстовым файлам и др.
Еще один пример OLE DB-провайдера - Microsoft OLE DB Provider for SQL Server, применяемый для доступа к базам данных Microsoft SQL Server 6.5, 7.0 и 2000.
Провайдер сервисов (или сервисный компонент) реализует расширенную функциональность, не поддерживаемую обычными провайдерами данных, например сортировку и фильтрацию данных, обработку транзакций и SQL-запросов, управление курсором и др. Сервисный компонент может обращаться к хранилищу данных непосредственно или с помощью соответствующего провайдера данных - в этом случае провайдер сервисов является одновременно и провайдером, и потребителем. Например, сервисные компоненты, такие как Microsoft Cursor Service for OLE DB и Microsoft Data Shaping Service for OLE DB, могут использоваться совместно с провайдерами данных OLE DB для расширения их функциональности.
На рисунке 6.2 показано, как компоненты OLE DB взаимодействуют между собой

Рисунок 6.2. Взаимодействие компонентов OLE DB
Из рисунка следует, что потребитель может получать данные как непосредственно с помощью провайдера данных, так и с использованием сервисов, предоставляемых сервисными компонентами.
В таблице 1 приведен список провайдеров, доступных в составе набора MDAC (Microsoft Data Access Components), поставляемого как отдельно, так и в составе ряда продуктов фирмы Microsoft.
Таблица 1. Провайдеры, доступные в составе Microsoft Data Access Components
Провайдер Описание
Microsoft OLE DB Provider for ODBC Drivers Позволяет осуществить доступ к любому ODBC- источнику
Microsoft Jet 4.0 OLE DB Provider Применяется для доступа к данным Microsoft Access и некоторых других СУБД
Microsoft OLE DB Provider for SQL Server Используется для доступа к данным Microsoft SQL Server
Microsoft OLE DB Provider for Oracle Используется для доступа к данным Oracle
Microsoft OLE DB Provider for Internet Publishing Используется для доступа к Web-серверам и ресурсам, обслуживаемым Microsoft FrontPage или Microsoft Internet Information Server
OLE DB Provider for Microsoft Directory Services Применяется для доступа к гетерогенным службам каталогов с помощью Microsoft Active Directory Service Interfaces (ADSI)
Microsoft OLE DB Provider for Microsoft Index Server Предоставляет доступ "только для чтения" к файловой системе и данным Web, индексированным с помощью Microsoft Indexing Service
Microsoft OLE DB Simple Provider Используется для доступа к текстовым файлам
Cursor Service for OLE DB Расширяет функциональность курсора
Data Shaping Service for OLE DB Применяется для создания связей между наборами данных и получения иерархических наборов данных
OLE DB Persistence Provider Используется для сохранения наборов данных в форматах ADTG (Advanced Data Table Gram) или XML (extensible Markup Language)
OLE DB Remoting Provider Позволяет обращаться к провайдерам данных на удаленных компьютерах
Microsoft OLE DB Provider for OLAP Services Применяется с расширением ADO Multi-Dimensional (ADO MD) для доступа к многомерным данным, созданным с помощью Microsoft SQL Server 7.0 OLAP Services
Объекты OLE DB
OLE DB представляет собой набор СОМ-интерфейсов. На рисунке 6.3 схематически представлены четыре основных объекта и их интерфейсы, а также методы, с помощью которых они взаимодействуют.

Рисунок 6. 3. Объекты и интерфейсы OLE DB
Отметим, что каждый OLE DB-провайдер должен содержать реализацию объектов DataSource, Session и Rowset. Помимо трех основных объектов могут быть и другие. Далее рассмотрим эти объекты более подробно.
Каждый OLE DB-провайдер должен содержать реализацию объектов DataSource, Session и Rowset. Помимо трех основных объектов могут быть и другие.
Рассмотрим эти объекты более подробно.
Объектная модель OLE DB содержит четыре ключевых объекта:
DataSource;
Session;
Command;
Rowset.
Объект DataSource
Объект DataSource, применяемый потребителями данных для соединения с провайдером, может быть создан различными способами, включая вызов функции GoCreatelnstance с идентификатором класса (CLSID, Class Identifier) OLE DB-провайдера, использование объекта Enumerator , который занимается поиском источников данных, и пр. Объект DataSource инкапсулирует информацию, связанную с соединением (включая имя пользователя и пароль).
Основное назначение этого объекта - предоставлять данные из источника данных потребителю.
Для создания новой сессии (объект Session) потребитель должен вызвать метод CreateSession интерфейса IDBCreateSession объекта DataSource.
Объект Session
Объект Session предоставляет контекст для транзакций, может генерировать наборы данных (rowsets) из источников данных, а также команды для запросов к источнику данных. Объект Session может выполнять роль фабрики классов для объектов Command и Rowset и объекта Transaction, применяемого для управления вложенными транзакциями.
Объекты Command и Rowset могут быть использованы для создания или модификации таблиц и индексов. Интерфейс lOpenRowset используется потребителями данных для работы с отдельными таблицами и индексами в хранилище данных.
С одним объектом DataSource может быть связано несколько объектов Session.
Если OLE DB-провайдер поддерживает команды или запросы, он должен уметь порождать объект Command. С одним объектом DataSource может быть связано несколько объектов Command. Для создания нового объекта Command применяется метод CreateCommand интерфейса IDBCreateCommand.
Объект Command
Объект Command используется для выполнения команд, представляющих собой строки, передаваемые от потребителя данных объекту DataSource для выполнения. В большинстве случаев такая команда представляет собой SQL-предложение SELECT, однако в общем случае это может быть любое другое SQL-предложение (например, DDL-предложение). Команды могут содержать параметры - в этом случае применяется интерфейс I Command WithParameters. Одна сессия может порождать несколько команд. Результатом выполнения команды (с помощью метода Execute интерфейса ICommand) обычно является новый объект Rowset.
Объект Rowset
Объект Rowset (набор данных) позволяет OLE DB-провайдеру данных представлять данные из источников данных в табличном формате, то есть в виде набора строк, содержащих одну или несколько колонок. Этот объект может быть результатом выполнения команды или может быть сгенерирован непосредственно провайдером данных, если провайдер не поддерживает команды. Все провайдеры данных "умеют" создавать наборы данных напрямую. Объект Rowset может быть также использован для обновления, добавления или удаления строк - это зависит от функциональности провайдера данных.
С помощью интерфейса IRowset из объекта Rowset потребители могут перемещаться по набору данных вперед и, если набор данных позволяет, назад. Некоторые провайдеры могут предоставлять дополнительные функции наподобие непосредственного доступа или определения примерной позиции данной строки в наборе.
Частным случаем объекта Rowset является объект Index, предоставляющий набор строк, использующий соответствующий индекс для получения набора данных в упорядоченном виде.
Существуют также специальные объекты типа Rowset - schema rowsets, содержащие метаданные (то есть сведения о структуре данных), и view rowsets, содержащие подмножество строк и столбцов объекта Rowset.
Помимо четырех основных объектов, перечисленных выше, существуют и другие объекты OLE DB. Они нужны для перечисления источников данных, управления транзакциями, обработки ошибок и др.
Объект Enumerator
Объект Enumerator необходим для получения списка доступных объектов, обеспечивающих доступ к источникам данных (OLE DB-провайдеров). Этот объект используется потребителями данных для поиска соответствующих объектов. В большинстве случаев сведения, возвращаемые объектом Enumerator, извлекаются из системного реестра. Этот объект реализует интерфейс ISourceRowset и возвращает объект Rowset с описанием всех источников данных и других доступных с его помощью объектов Enumerator. Для этой цели используется метод GetSourcesRowset интерфейса ISourceRowset.
Объект Transaction
Объект Transaction поддерживает транзакции в источнике данных. Транзакции позволяют определить группу операций, которые либо все вместе выполняются, либо все вместе отменяются.
Транзакции бывают локальными и распределенными.
Локальные транзакции - это транзакции, выполняемые в контексте единого провайдера данных. Провайдер, поддерживающий локальные транзакции, должен реализовать интерфейс ITransactionLocal. Транзакция начинается с вызова метода Start Transaction, завершается с помощью метода Commit или откатывается с помощью Abort. Способность провайдера поддерживать транзакции может быть определена с помощью интерфейса IDBProperties.
Распределенные транзакции выполняются в контексте нескольких провайдеров данных. Для выполнения таких транзакций потребители используют интерфейс TtransactionJoin, доступный, только если провайдер данных поддерживает распределенные транзакции. В этом случае потребитель вызывает метод JoinTransaction для регистрации сессии в распределенной транзакции. После присоединения к распределенной транзакции потребитель использует интерфейс ITransaction для завершения или отката транзакции.
Объект Error
В дополнение к кодам возврата и информации о состоянии, свидетельствующей об успехе или неуспехе вызова любого из методов OLE DB, OLE DB-провайдеры могут предоставлять расширенную информацию об ошибках с помощью объекта Error. Потребители данных могут использовать интерфейс ISupportErrorlnfo для того, чтобы определить, может ли данный объект возвратить объект Error, и если да, то каковы эти интерфейсы.
Microsoft ActiveX Data Objects (ADO)
ADO представляет собой высокоуровневый программный интерфейс для доступа к OLE DB-интерфейсам.
Он позволяет манипулировать данными с помощью любых OLE DB-провайдеров - как входящих в состав Microsoft Data Access Components некоторых других продуктов Microsoft, так и произведенных сторонними производителями.
ADO содержит набор объектов, используемых для соединения с источником данных, для чтения, добавления, удаления и модификации данных.
Объект ADO Connection применяется для установки связи с источником данных. Он представляет единственную сессию. Этот объект позволяет изменить параметры соединения с базой данных, а также начать или завершить транзакцию.
Используя объект Connection, можно выполнять команды (например, SQL-запросы) с помощью метода Execute. Если команда возвращает набор данных, автоматически создается объект Recordset, который возвращается в результате выполнения этого метода.
Объект Error используется для получения сведений об ошибках, возникающих в процессе выполнения.
Объект Command представляет собой команду, которую можно выполнить в источнике данных. Команда может содержать SQL-предложение или вызов хранимой процедуры. В последнем случае для определения параметров процедуры может быть использована коллекция Parameters объекта Command.
Объект Recordset - это набор записей, полученных из источника данных, который может быть использован для добавления, удаления, изменения, просмотра записей. Данный объект может быть открыт непосредственно или создан с помощью объектов Connection или Command.
Объект Field - это колонка в наборе данных, представленных объектом Recordset. Он может быть использован для получения значений конкретного поля, его модификации, извлечения метаданных, таких как имя колонки и тип данных.
На рисунок 6.4 изображена объектная модель ADO.
Объект Record представляет одну запись внутри объекта Recordset и может быть использован для работы с гетерогенными и иерархическими данными.
Объект Stream представляет двоичные данные, связанные с объектом Record. Например, если объект Record представляет собой файл, то его объект Stream должен содержать данные внутри этого файла.

Рисунок 6.4. Объектная модель ADO
ВыводыУниверсальные механизмы доступа к данным обычно реализованы в виде библиотек и модулей, называемых драйверами или провайдерами, содержащих стандартный набор функций или классов, реализованных на основе функций клиентского API конкретных СУБД;
Наиболее общеупотребительными среди универсальных механизмов являются ODBC, OLE DB и ADO, а так же, в определенной степени, BDE.Далее мы рассмотрели BDE и возможности, предоставляемые этим механизмом доступа к данным.
Физически BDE представляет собой библиотеки доступа к данным, реализующие функции BDE API для манипуляции данными;
Функции BDE API могут обращаться:
к функциям клиентского API или ODBC API;
BDE-драйверы прямого доступа сегодня имеются для всех версий dBase, Paradox, IB Database, Microsoft Access 95 и Microsoft Access 97, Microsoft FoxPro, Microsoft SQL Server 4.x и 6.x., Oracle 7, Oracle 8 (начиная с Oracle 8.0.4), Sybase, IBM DB2, Informix;
для доступа с помощью BDE к источникам данных, отличным от перечисленных выше, следует использовать ODBC-драйвер и ODBC Link;
для доступа к данным Paradox и поздних версий dBase требуется наличие BDE, даже в случае применения других универсальных механизмов доступа к данным (ODBC, OLE DB, ADO);
Для доступа к данным Microsoft Access 2007, Microsoft SQL Server и MSDE использовать BDE не рекомендуется.
Применение BDE в ряде случаев связано с определенными ограничениями, причиной которых нередко является отсутствие необходимых BDE-драйверов.
Существует возможность выбора продуктов третьих фирм, способных заменить BDE в приложениях, созданных с помощью средств разработки Borland.
Теоретические вопросы для самоконтроляУниверсальный механизм доступа к данным (Universal Data Access)...
Microsoft ActiveX Data Objects (ADO)...
Программный интерфейс для доступа к различным источникам данных, таким как реляционные и нереляционные данные, текстовые, графические и географические данные, архивы электронных писем, файловая система, бизнес-объекты- это...
Стандартный способ доступа к реляционным данным- это...
Open Database Connectivity (ODBC)
Провайдер
Провайдер данных
Провайдер данных выполняет следующие функции:
Объектная модель OLE DB содержитc следующие ключевые объекты:
Объект DataSource
Объект Session
Объект Command
Объект Rowset (набор данных)
Объект Transaction
Локальные транзакции
Распределенные транзакции- это ...
ADO Extensions for Data Definition Language and Security (ADOX)
Реплика
ADO Multi-Dimensional Extensions (ADOMD) -
Jet and Replication Objects
Выводы по теме
При удаленном (сетевом) доступе к данным возможны альтернативные технологии: файл-сервер и клиент-сервер.
Основными преимуществами клиент-серверной технологии является уменьшение загрузки сети и облегчение организации многопользовательского доступа.
В настоящее время наиболее популярными являются реляционные базы данных.
Традиционным методом организации информационных систем является двухзвенная архитектура клиент-сервер.
Универсальные механизмы доступа к данным обычно реализованы в виде библиотек и модулей, называемых драйверами или провайдерами, содержащих стандартный набор функций или классов, реализованных на основе функций клиентского API конкретных СУБД.
Теоретичксние вопросы для самоконтроля:
Какими преимуществами обладают информационные системы, использующие архитектуру "клиент-сервер"?
Что называют сервером?
Дайте определение понятию триггер?
Что представляет собой хранимая процедура, представление?
Перечислите на какие категории можно разделить программное обеспечение (ПО) промежуточного уровня?
Что представляет собой специальный прикладной программный интерфейс (Application Programming Interface, API) для доступа к данным.
В виде чего реализован универсальный механизм доступа к данным.
Какие механизмы доступа к данным может применять приложение, использующее базы данных.
Что может выступать в роли доступа к данным в простых двухзвенных моделях "клиент - сервер".
Какие части включает каждое приложение, построенное на основе архитектуры "клиент - сервер"?
Какой набор функций содержит библиотека доступа к данным?
Что представляет собой ODBC (Open Database Connectivity)?
Что представляет собой JDBC (Java Data Base Connectivity) ?
Что представляет собой Microsoft ActiveX Data Objects (ADO)?
Что представляет собой потребитель (клиент), провайдер (сервер)?
Что представляет собой BDE (Borland Database Engine)
Какие функции выполняет провайдер данных?
Что означают понятия «локальные транзакции», «распределенные транзакции»?
Задание для самоконтроля:
Создать объекты доступа к данным для программного доступа и управления данными в локальной или удаленной базе данных
Тема 4.2. Принципы и средства проектирования баз данныхСерверные системы управления базами данных.
Разработка и организация систем управления базами данных
Средства проектирования данных.
Структурное моделирование.
Моделирование данных.
Инструментальные средства автоматизации проектирования.
Серверные системы управления базами данныхХарактеристика серверных СУБД. Типы хранилищ и их использование.
Характеристика серверных СУБД
Принцип централизации хранения и обработки данных является базовым принципом серверных СУБД.
Современные серверные СУБД обладают широкими возможностями управления пользовательскими привилегиями и правами доступа к различным объектам базы данных. Как правило, в базе данных хранятся сведения о ее пользователях, их паролях и привилегиях, а каждый объект базы данных принадлежит какому-либо пользователю. Владелец объекта может предоставить другим пользователям право использовать его тем или иным способом (например, позволить читать из него данные какому-либо другому пользователю). Большинство серверных СУБД поддерживает так называемые роли, представляющие собой совокупность прав на доступ к тем или иным объектам базы данных. В этом случае каждый пользователь может иметь одну или несколько ролей и соответственно определенные в этих ролях привилегии.
Современные серверные СУБД обладают также широкими возможностями резервного копирования и архивации данных, а нередко и оптимизации выполнения запросов. Они также, как правило, предоставляют возможность параллельной обработки данных, особенно в случае использования многопроцессорных компьютеров в качестве сервера баз данных.
Современные серверные СУБД обычно предоставляют дополнительный набор сервисов, связанных с обслуживанием хранения и обработки данных, созданием клиентских приложений, сменой СУБД или ее версии, обслуживанием нескольких баз данных, публикацией данных в Internet.
На сегодняшний день известно более двух десятков серверных СУБД, однако, наиболее популярными, исходя из числа продаж и инсталляций, следует признать Oracle, Microsoft SQL Server, Informix, Sybase, DB2. Oracle является бессменным лидером на рынке производителей коммерческих СУБД и второй (после Microsoft) по величине компанией, производящей программное обеспечение.
Почти все современные серверы баз данных существуют в нескольких версиях для различных платформ (как правило, различные коммерческие версии UNIX - Solaris, HP/UX и др., а также Windows NT Server и, с недавнего времени, Windows 2000). Многие производители серверных СУБД также выпускают версии своих серверов для Windows NT Workstation и Windows 95/98/2000 (а иногда даже для Windows СЕ). В последнем случае такие серверы нередко бывают персональными (однопользовательскими) либо в их реализации отсутствуют возможности, характерные для полнофункциональных версий этих серверов. Подобные персональные серверы, как правило, используются в "переносных" системах, например на ноутбуках, применяемых для работы с базой данных отдельно от центрального офиса компании с последующей репликацией данных (о репликации данных см. ниже в этой главе). Иногда такие серверы используются при создании приложений с целью изоляции разработчика от сервера баз данных, находящегося в процессе эксплуатации.
В последнее время многие производители серверных СУБД выпускают также версии для Linux - в этом плане Linux в последние два года была весьма "модной" платформой.
Исключением из этого правила является Microsoft SQL Server. Однако для данной СУБД это вполне оправданно - компания Microsoft сама производит серверные операционные системы.
Административные утилиты
Администрирование сервера баз данных, конечно, удел профессионалов. Однако и профессионал предпочтет удобные утилиты администрирования унылому окну с интерфейсом командной строки. Наличие удобных утилит администрирования, как ни странно, иногда оказывается одним из решающих факторов при выборе СУБД. Именно поэтому подавляющее большинство современных СУБД обычно поставляется с подобными утилитами, и их интерфейс в последнее время концептуально напоминает интерфейс Windows Explorer.
Следует отметить, что производители СУБД, вовремя не заметившие эту тенденцию, оказались лишенными значительной части рынка или практически вытесненными с него. В результате потенциальные пользователи некоторых СУБД, нередко очень неплохих с точки зрения хранения данных и скорости обработки запросов, но не успевших обзавестись удобными утилитами администрирования, средствами репликации и OLAP-средствами, сделали выбор в пользу других СУБД.
Резервное копирование данных
Резервное копирование данных и журналов транзакций поддерживается всеми без исключения серверными СУБД (возможно, за исключением некоторых некоммерческих продуктов, но их в данной книге мы не рассматриваем). Различия между СУБД в поддержке резервного копирования заключаются в том, возможно ли производить резервное копирование в процессе работы пользователей, и если да, то какие пользовательские операции в это время нельзя выполнять. Помимо этого в комплекте поставки некоторых СУБД могут содержаться утилиты для работы с различными внешними устройствами (например, накопителями на магнитных лентах) в качестве средств хранения резервных копий.
Обслуживание репликаций
Репликация по сути представляет собой гарантированное копирование информации из одной базы в несколько других. Репликации используются для разделения нагрузки между серверами в сети, для перемещения поднаборов данных на вспомогательные серверы, для синхронизации данных на нескольких серверах и многих других целей.
В том или ином виде репликации поддерживаются всеми современными серверными СУБД. Различия могут быть лишь в поддержке тех или иных конкретных сценариев репликаций (например, внесение изменений одновременно на нескольких серверах, возможность шифрования реплицируемых данных и др.). Исключение здесь составляет IB Database, в текущей версии не поддерживающая репликаций.
Если вы планируете иметь несколько серверов баз данных с необходимостью синхронизации данных (например, у вашего предприятия существует не сколько филиалов), стоит обратить внимание на то, какие сценарии репликаций поддерживаются в вы бранной вами СУБД.
Параллельная обработка данных в многопроцессорных системах
О возможностях повышения производительности с помощью параллельной обработки запросов в многопроцессорных системах начали говорить несколько лет назад, после появления первого продукта такого класса - Oracle Parallel Server. Серверы, поддерживающие параллельную обработку, разрешают нескольким процессорам обращаться к одной базе данных, что повышает скорость обработки транзакций.
В настоящее время подавляющее большинство производителей серверных СУБД поставляют на рынок версии продуктов (обычно это версии для Windows NT и коммерческих версий UNIX), поддерживающие параллельную обработку данных.
Если вы рассчитываете использовать многопроцессорный компьютер в качестве сервера баз данных, имеет смысл обратить внимание на то, поддерживает ли выбранная вами серверная СУБД параллельную обработку данных.
Поддержка OLAP и создания хранилищ данных
OLAP (On-Line Analytical Processing) представляет собой технологию построения многомерных хранилищ данных (Data Warehouses), как правило, агрегатных, то есть являющихся результатом обработки набора данных, нередко состоящего из нескольких таблиц. Такие хранилища данных в последнее время широко используются в системах поддержки принятия решений. Более подробно об идеях, лежащих в основе OLAP, будет рассказано в главе 10, здесь же мы ограничимся лишь упоминанием этой возможности.
Многомерные хранилища данных могут быть реализованы как в виде набора обычных реляционных таблиц, так и в виде нереляционной многомерной базы данных. В последнем случае такое хранилище обычно управляется отдельным сервером. Многие производители серверных СУБД поставляют такие серверы отдельно (например, фирмы Oracle и Informix), некоторые включают их в состав сервера реляционных баз данных (Microsoft SQL Server 7.0/2000 Enterprise Edition). Нередко с целью повышения конкурентоспособности подобные OLAP-системы строят многомерные хранилища на основе данных из других СУБД, как это сделано, например, в Microsoft SQL Server Analysis Services и в Sybase Adaptive Server IQ.
Если вы планируете создавать системы поддержки принятия решений, вам необходимо обратить внимание на то, какие OLAP-серверы можно использовать на выбранной вами платформе и поддерживают ли они выбранную вами СУБД.
Распределенные запросы и транзакции
О распределенных транзакциях и запросах заговорили в последнее время, когда наличие нескольких серверов баз данных в одной организации стало обычным явлением. Нужно отметить, что возможности выполнения распределенного запроса или распределенной транзакции поддерживаются сейчас почти всеми серверными СУБД, по крайней мере в том случае, когда все вовлеченные в транзакцию серверы - от одного и того же производителя. С этой целью используется механизм двухфазного завершения транзакций (two-phase commit), когда на первом этапе серверы, вовлеченные в транзакцию, сигнализируют о готовности ее завершить, а на втором этапе происходит реальная фиксация изменений в базах данных.
Что касается распределенных транзакций с участием "чужих" серверов, то они, как правило, реализуются с помощью мониторов транзакций или иных подобных сервисов, например Microsoft Distributed Transaction Coordinator (DTC).
Если вы планируете использовать несколько серверов баз данных и совершать операции, затрагивающие данные на нескольких серверах, есть смысл поинтересоваться, поддерживают ли выбранные вами СУБД двухфазное завершение транзакций.
Средства проектирования данных
Многие производители серверных СУБД выпускают также средства анализа бизнес-процессов и проектирования данных, иногда универсальные (как в случае Sybase DataArchitect), а порой ориентированные главным образом на конкретную СУБД (как в случае Oracle Designer/2000). Многие производители СУБД не имеют в своем арсенале собственных средств проектирования данных, ориентируясь на универсальные CASE-средства типа Platinum ERwin фирмы Computer Associates. Нередко производители СУБД встраивают в административные утилиты несложные средства проектирования данных, позволяющие визуально редактировать схемы данных, как это сделано, например, в Microsoft SQL Server 7.0 и 2000. Отметим, что фирма Microsoft также выпускает продукт Microsoft Visio, обладающий средствами проектирования данных.
Выбирая CASE-средство, обратите внимание - поддерживает ли оно выбранную вами СУБД.
Поддержка собственных и "чужих" средств разработки и генераторов отчетов
Многие производители серверных СУБД выпускают также средства разработки и генераторы отчетов. Иногда данные средства Разработки используют тот же язык программирования, что применяется при написании триггеров и хранимых процедур (в этом случае, как правило, клиентское приложение должно включать интерпретатор этого языка), что позволяет отлаживать хранимые процедуры, помещая их в клиентское приложение. Типичный пример подобного подхода реализован в Oracle Developer/2000. Однако чаще средства разработки производителей серверных СУБД используют языки программирования, отличные от языков создания серверного кода (характерный пример - средства разработки Microsoft). Следует, однако, сказать, что в Microsoft .Net появится возможность написания хранимых процедур на любом из поддерживаемых в платформе языков программирования - в настоящее время их около 30!
Практически все производители серверных СУБД делают все возможное для того, чтобы клиентские приложения для их СУБД можно было создавать с помощью средств разработки сторонних фирм. С этой целью они предоставляют разработчикам описания программного интерфейса (АИ) клиентской части, ODBC-драйверы, OLE DB-провайдеры, а нередко и объектные модели, позволяя использовать СОМ-объекты клиентской части в приложениях (как, например, это сделано в клиентских частях СУБД фирм Oracle, Microsoft и Informix).
Производители серверных СУБД, ориентирующиеся только на собственные средства разработки, как правило, оказываются вытесненными с рынка или теряют его часть. Показательной в этом плане явилась ситуация 1997 года, когда в комплекте поставки некогда популярного сервера SQLBase компании Gupta (ныне Centura) содержался ODBC-драйвер производства компании Intersolv (ныне Merant), не поддерживавший хранимые "процедуры". Это вызвало недовольство пользователей Visual Basic и Delphi, и в конечном итоге они перешли на другую серверную СУБД, более совместимый с их средствами разработки.
Выбирая СУБД и средство разработки, обратите внимание на то, какие механизмы доступа к данным при этом можно использовать и какие именно серверные объекты в этом случае будут доступны клиентскому приложению. Есть смысл попробовать поработать с оценочными версиями этих продуктов, чтобы убедиться, что вы не попадете в ситуацию, описанную выше.
Поддержка доступа к данным через Internet
Без поддержки публикации данных в Internet или получения данных от удаленных Internet-клиентов сегодня не обходится практически ни одна СУБД, в том числе и настольные базы данных. Тем или иным способом производители серверных СУБД поддерживают Web-технологии. Чаще всего эта поддержка осуществляется с помощью Web-серверов собственного производства, либо посредством создания расширений для существующих Web-серверов, либо просто путем включения в комплект поставки утилит, генерирующих Web-страницы согласно определенному расписанию. Помимо публикации данных в Web, некоторые СУБД позволяют осуществлять их удаленное администрирование через Internet, обмен XML-данными с клиентскими приложениями и пр.
Обсудив, какие сервисы предоставляют современные серверные СУБД, мы можем наконец поговорить и о конкретных серверах баз данных. Далее мы рассмотрим наиболее популярные из них.
Типы хранилищ и их использование
Хранилища данных – это процесс сбора, отсеивания и предварительной обработки данных с целью представления результирующей информации пользователям для статистического анализа и аналитических отчетов. Ральф Кинболл (автор концепции хранилищ данных) описывал хранилища данных как «место, где люди могут получить доступ к своим данным». Он же сформулировал основные требования к хранилищам данных:
– поддержка высокой скорости данных из хранилища;
– поддержка внутренней непротиворечивости данных;
– возможность получения и сравнения данных;
– наличие удобных утилит просмотра данных хранилища;
– полнота и достоверность хранимых данных;
– поддержка качественного процесса пополнения данных.
Всем перечисленным требованиям удовлетворять зачастую не удается, поэтому для реализации хранилищ данных используют несколько продуктов. Одни из которых представляют средства хранения данных, другие – средства их извлечения и просмотра, в-третьих – средства пополнения хранилищ данных. Типичное хранилище данных как правило отличается от реляционной базы данных: 1) Обычная база данных предназначена для того, чтобы помочь пользователям выполнять повседневную работу, тогда как хранилища данных предназначены для принятия решений; 2) Обычная база данных подвержена постоянным изменениям в процессе работы пользователей, а хранилища данных относительно стабильно; данные в нем обновляются согласно расписанию (например, ежечасно, ежедневно, ежемесячно), в идеале, процесс пополнения данными за определенный период времени без изменения прежней информации находящейся уже в хранилище. 3) Обычная база данных чаще всего является источником данных попадающих в хранилище, кроме того хранилище может пополняться за счет внешних источников (например, сжатия данных).
Принципы построения
Информация, которая загружается в хранилище, должна интегрироваться в целостную структуру, отвечающую целям анализа данных. При этом минимизируются несоответствия между данными из различных оперативных систем, в хранилище именуются и выражаются единым образом. Данные интегрированы на множестве уровней: на уровне ключа, атрибута, на описательном, структурном уровне и так далее. Общие данные и общая обработка данных консолидированы и являются единообразным для всех данных, которые подобны или схожи в хранилище данных. При этом информация структурируется по разным уровням детализации:
– высокая степень суммаризации;
– низкая степень суммаризации;
– текущая детальная информация.
Хранилища можно рассматривать как набор моментальных снимков состояния данных: можно восстановить картинку на любой момент времени. Атрибут времени всегда явно присутствует в структурах данных хранилища.
Попав однажды в хранилище, данные уже никогда не изменяются, а только пополняются новыми данными из оперативных систем, где данные постоянно меняются. Новые данные по мере поступления обобщаются с уже накопленной информацией в хранилище данных.
Основные компоненты хранилища данных
Использование технологии хранилищ данных предполагает наличие в системе следующих компонентов:
– оперативных источников данных;
– средств переноса и трансформации данных;
– метаданных – включают каталог хранилища и правила преобразования данных при загрузке их из оперативных баз данных;
– реляционного хранилища;
– OLAP хранилища;
– средств доступа и анализа данных.
Назначение перечисленных компонентов таково. Оперативные данные собираются из различных источников. Поступившие оперативные данные очищаются, интегрируются и складываются в реляционные хранилище. Они уже доступны для анализа при помощи средств построения отчетов. Затем данные (полностью или частично) подготавливаются с использованием средств переноса и трансформации данных для OLAP анализа, который реализуется применением средств доступа и анализа данных. При этом они могут быть загружены в специальную базу данных OLAP или оставаться в реляционном хранилище.
Важнейшим элементом хранилища являются метаданные, т.е. данные о структуре, размещении, трансформации данных, которые используются любыми процессами хранилища. Метаданные могут быть востребованы для различных целей, например: извлечения и загрузки данных; обслуживании хранилища и запросов. Метаданные для различных процессов могут иметь различную структуру, т.е. для одного и того же элемента данных может существовать несколько вариантов метаданных.
Итак, хранилища данных являются структурированными. Они содержат базовые данные, которые образуют единый источник для обработки данных во всех системах поддержки принятия решений. Элементарные данные, присутствующие в хранилище, могут быть представлены в различной форме. Хранилища данных исключительно велики, поскольку в них содержатся интегрированные и детализированные данные.
Эти характеристики являются общими для всех хранилищ данных. Но, несмотря на то что хранилища обладают общими свойствами, разные типы хранилищ имеют свои индивидуальные особенности.
Технологии управления информацией
Для работы с хранилищем данных используются СУБД, к которым предъявляются специальные требования. Поскольку в ходе обсуждения проблем хранилищ данных эти требования либо уже обсуждались, либо присутствие их в перечне и без обсуждения интуитивно понятно, просто перечислим их:
– высокая производительность загрузки данных;
– возможность обработки данных на уровне загрузки;
– наличие средств управления качеством данных;
– высокая производительность запросов;
– широкая масштабируемость по размеру и количеству пользователей;
– возможность организации сети хранилищ данных;
– наличие средств администрации хранилищ данных;
– поддержка интегрированного многомерного анализа;
– расширенный набор функциональных средств запросов.
OLAP технология
OLAP – это технология комплексного многомерного анализа данных, это ключевой компонент организации хранилищ данных. В 1993 г. эта технология была описана Эдгером Коддом. Для упрощения анализа была предложена и разработаны концепция хранилища данных. Предполагается что такое хранилище содержит сведения, поступающие от разных источников, а так же интегрированные данные, получаемые в результате анализа первичных данных. Естественно, для поддержки предложенной концепции потребовались специальные средства управления процессом хранения и обработки информации, к которым относятся инструментальные средства OLAP технологии.
OLAP – это способ представления данных в простом и понятном для конечного пользователя виде. Назначение систем класса OLAP – предоставить пользователям гибкий, интуитивно понятный и простой доступ к данным. Наличие такого доступа позволяет отказаться от использования предопределенных отчетов, делает пользователей самодостаточными, независящими от администраторов баз данных и программистов. В основе концепции OLAP лежит принцип многомерного представления данных. Данные представляются в виде многомерного куб, причем пользователь может быстро свернуть или развернуть данные по любому измерению. Хранилища данных не измеряются, а дополняют традиционные реляционные базы данных с первичной информацией.
Для построения систем OLAP используются специализированные многомерные базы данных, либо надстройки над обычными реляционными базами данных. До последнего времени OLAP технология ассоциировалась с большими проектами по хранению массивов данных и сложными приложениями для их анализа. Сложный и дорогой OLAP инструментарий был доступен только очень крупным компаниям.
И все же в последнее время ситуация на рынке резко изменилась. Произошло это благодаря тому, что было найдено компромиссное решение: укомплектовать полноценным OLAP сервером хорошо зарекомендовавшие себя недорогие программные продукты. К таким продуктам относятся, например, MS SQL сервер баз данных, начиная с версии 7 и позднее, который во всем мире активно используется для построения хранилищ данных. Компания Microsoft предпринимает ряд серьезных мер, чтобы обеспечить наилучшую поддержку хранилищ данных и построения информационных систем. Вследствие указанного изменения ситуации современные OLAP системы анализа данных стали действительно доступны малому и среднему бизнесу.
Выводы
1. По масштабу информационные системы делят на одиночные, групповые, кор-поративные. В соответствии с этим СУБД делятся на локальные (настольные) и серверы баз данных (SQL-серверы).
2. Модель данных предполагает три основных аспекта: структурирование дан-ных; способы поддержания целостности данных; операции манипулирования данными.
3. За несколько десятилетий последовательно появились системы, основанные на четырех базовых моделях данных: иерархические; сетевые; реляционные; объектно-ориентированные.
4. Анализ современных СУБД, банков данных и реализованных на их основе приложений позволяет предположить следующие направления их развития: поиск более совершенных моделей представления и типов данных в базах; разработка новых архитектур СУБД; расширение областей применения БД; улучшение сервиса конечных пользователей, администраторов и разработчиков.
Теоретические вопросы для самоконтроля
1.По каким классификационным признакам можно классифицировать современные системы управления базами данных (СУБД)?
2.На какие основные группы делятся СУБД в соответствии с делением по масштабу информационных систем? Приведите примеры СУБД.
3.Что называют моделью данных?
4.Какие существуют основные модели данных?
5.Приведите примеры реляционных и объектно-ориентированных СУБД.
6.Какие основные модели используются в настоящее время для моделирования хранилищ данных?
7.Какая модель данных популярна в настоящее время, какой модели данных принадлежит будущее?
8.Какие существуют гибридные СУБД?
9.Какие существуют перспективные направления развития СУБД?
10.С появлением каких новых баз данных связано развитие СУБД? Охарактеризуйте их.
11.Как происходит разработка новых перспективных архитектур СУБД?
12.Какие два класса задач можно отнести к новым областям применения СУБД?
Разработка и организация систем управления базами данныхПринципы разработки многопользовательских ИС
Как следует из концепции CALS-технологий, разрабатываемые на предприятиях информационные системы и базы данных должны быть многопользовательскими.
Принципы разработки многопользовательских баз данных должны сводиться к соблюдению двух обязательных условий: системного подхода и стандартизации.
Системный подход. Системный подход к разработке информационной системы означает, что такая система рассматривается как большая система, состоящая из некоторого множества взаимосвязанных и взаимодействующих между собой элементов. При проектировании информационных систем необходимо соблюдать следующие принципы:
учет интересов всех потенциальных пользователей систем;
модульный принцип разработки и внедрения.
Учет интересов всех потенциальных пользователей систем. Этот принцип означает следующую последовательность разработки БД.
Установить, каким специалистам и в каких подразделениях предприятия необходима информация о конкретном информационном объекте.
Установить признаки описания объектов различными пользователями.
Установить общий состав признаков объектов одного класса.
Такой подход к проектированию увеличивает сроки разработки БД, но обеспечивает значительное снижение затрат на разработку всей системы в целом.
Для пояснения этого принципа можно привести следующий реальный пример разработки БД на одном из предприятий. Появление программ создания баз данных было по достоинству оценено сотрудниками и они "бросились" разрабатывать необходимые для себя базы данных.
Одной из задач, стоящих перед технологами цехов, являлась задача выбора инструмента для механической обработки деталей. Они разработали свою, цеховую БД по режущему инструменту (затратив на это и время, и средства).
В то же время в конструкторском отделе завода специалисты, занимающиеся проектированием режущего инструмента, также создали свою БД. Однако когда руководство приняло решение создать общезаводскую информационную систему по режущему инструменту, то оказалось, что одни и те же признаки режущего инструмента разные специалисты описывали разными способами. В результате разработанные базы данных пришлось полностью переделывать, что потребовало как дополнительного времени, так и дополнительных затрат. Средства на разработку несогласованных между специалистами баз данных были потеряны для предприятия.
Модульный принцип разработки и внедрения. Модульный принцип означает, что любая система должна разрабатываться в виде отдельных взаимосвязанных модулей (подсистем), которые могут внедряться в производстве отдельно, до окончательной разработки всей системы.
Стандартизация. Стандартизация разработки информационных систем, учитывая их многопользовательский характер, имеет следующие аспекты:
информационный;
программный;
аппаратный.
Стандартизация информационного обеспечения обусловлена принципами компьютерной обработки символьной информации, так как объекты баз данных должны однозначно распознаваться компьютером.
Этот аспект разработки БД означает, что на все информационные объекты должны быть установлены четкие правила их идентификации (грамматические правила их написания). Так, установив название инструмента для механической обработки детали "Резец расточной", не допускается никакого другого способа его обозначения (например, название "Расточной резец" не идентично названию "Резец расточной").
Необходимость стандартизации программного обеспечения очевидна - при разработке многопользовательских, удаленных друг от друга систем данные одной системы должны обрабатываться программным обеспечением другой системы.
Стандартизация аппаратного обеспечения связана с необходимостью снижения затрат на эксплуатацию компьютерной техники. Внедрение на предприятиях России концепции CALS-технологий предусматривает широчайшее применение единых, в том числе и международных, стандартов.
Организация многопользовательских СУБД
Компьютерные информационные системы современных предприятий разрабатываются с применением сетевых технологий - объединением компьютеров в локальные вычислительные сети (ЛВС). При разработке баз данных в локальных вычислительных сетях предприятий применяют два типа (две архитектуры) их организации:
архитектура файл-сервер;
архитектура клиент-сервер.
Общими признаками для этих типов организации баз данных является наличие сервера (компьютера), на котором находятся базы (файлы) данных и рабочих станций (компьютеров пользователей) - клиентов.
Отличаются эти две архитектуры организации баз данных способами обработки информации.
В архитектуре файл-сервер все процессы обработки информации производятся на компьютере клиента. Для этого клиенту по соответствующему запросу пересылается весь файл с данными.
В архитектуре клиент-сервер все процессы обработки информации выполняются на сервере по запросу клиента, которому отсылаются только результаты обработки данных.
При организации многопользовательских сетевых баз данных предпочтительным является организация системы по типу клиент- сервер, что следует из недостатков архитектуры файл -сервер и преимуществ архитектуры клиент-сервер.
Недостатки организации БД по архитектуре файл-сервер:
при передаче по сети файлов БД, особенно с большими объемами информации и с учетом возможного обращения к файлам одновременно нескольких пользователей, резко снижается производительность работы с системой;
при одновременной передаче по сети файлов с большими объемами нескольким пользователям увеличивается вероятность нарушения достоверности передаваемой информации, что снижает надежность работы системы.
Преимущества организации БД по архитектуре клиент-сервер:
при передаче по сети только результатов обработки данных по запросам клиентов резко снижается нагрузка на сеть и, как следствие, увеличивается возможность подключения к БД большего числа пользователей. Производительность работы системы значительно выше, чем в архитектуре файл -сервер;
централизованное хранение и обработка данных на сервере повышает надежность работы системы;
разработку серверной части СУБД можно выполнять на языке SQL или других языках высокого уровня, что повышает надежность и производительность обработки данных. Разработку клиентской части СУБД можно выполнять с применением прикладных программных продуктов, например Visual Basic, Microsoft Access, что значительно сократит время на разработку информационной системы.
Этапы проектирования
В современных условиях развития производства и бизнеса необходимо перейти от стратегии проектирования баз данных как самостоятельных объектов к стратегии создания многопользовательских информационных систем - общих баз данных. Такой переход предусматривает следующие стадии проектирования многопользовательских баз данных.
Разработка концептуальной модели многопользовательской базы данных.
Разработка проекта СУБД в соответствии с техническим заданием.
Реализация проекта и разработка технической документации.
Разработка концептуальной модели многопользовательской базы данных. На данной стадии проектирования многопользовательских баз данных необходимо выполнить следующие этапы:
определение цели создания ИИС;
установление состава пользователей БД;
разработка концептуальной модели БД;
разработка технического задания на проектирование локальных СУБД;
определение потребных трудовых и материальных ресурсов для разработки БД.
Определение цели создания ИИС. Очевидно, что целью разработки любой компьютерной системы является достижение определенного экономического эффекта от ее реализации, поэтому в условиях конкретного предприятия необходимо установить приоритетные направления в создании ИИС. Базы данных могут разрабатываться практически для всех задач управления производством, например:
поставка материалов и комплектующих изделий;
проектирование конструкции новых изделий; .
проектирование технологических процессов изготовления продукции;
проектирование технологического оснащения (приспособления, инструмент);
оперативное календарное планирование и управление выпуском изделий;
разработка нормативной базы (потребность в трудовых и материальных ресурсах, основных и вспомогательных материалах и др.);
управление качеством выпускаемой продукции;
управление сбытом и др.
Принятие решения о выборе направления для разработки баз данных, естественно, является прерогативой руководителей предприятия.
Установление состава пользователей БД. Выбрав область производственной деятельности, необходимо установить состав пользователей информацией разрабатываемой базы данных. Это необходимо для решения следующих задач:
определение классов информационных объектов, их характеристик и, в конечном итоге, определение состава таблиц баз данных;
определение месторасположения потенциальных пользователей и, в конечном итоге, определение архитектуры ЛВС.
Разработка концептуальной модели БД. Конечной задачей разработки концептуальной модели является установление оптимального состава таблиц базы данных. На данном этапе создания многопользовательских баз данных оптимальный состав таблиц определяется сначала исходя из потребностей каждого пользователя ИИС, а затем каждая таблица может быть подвергнута процедуре нормализации.
Разработка технического задания на проектирование локальных СУБД. После определения состава таблиц базы данных и состава пользователей ИИС можно приступить к разработке технического задания на проектирование СУБД. В техническом задании необходимо:
обосновать выбор архитектуры ЛВС и архитектуры баз данных;
обосновать выбор программной системы для разработки СУБД;
разработать требования к формам выходных документов, предоставляющих необходимую информацию для каждого пользователя БД;
разработать требования к созданию пользовательского интерфейса с учетом задач каждого пользователя;
разработать требования к организационному обеспечению СУБД, в том числе, определить права доступа пользователей к базе данных и ее компонентам как в процессе заполнения таблиц информацией, так и в процессе получения информации.
Определение потребных трудовых и материальных ресурсов для разработки БД. После выполнения всех перечисленных выше этапов необходимо оценить потребность в трудовых и материальных ресурсах для выполнения задач технического задания.
Для этого целесообразно воспользоваться программной системой управления проектами, например Microsoft Project.
Применение этой системы целесообразно не только для определения потребности в ресурсах; она позволяет эффективно руководить всем ходом выполнения работ по проектированию СУБД. Расширенное семейство продуктов Microsoft Project 2002 сочетает в себе интуитивно-понятные средства управления проектами, доступ к информации и поддержку коллективной работы, а также является мощной платформой корпоративного управления проектами.
Разработав техническое задание и определив состав исполнителей, можно приступить к реализации проекта - созданию системы управления базами данных для выбранного направления производственной деятельности предприятия.
Разработка проекта СУБД в соответствии с техническим заданием. На данной стадии проектирования многопользовательских баз данных необходимо выполнить следующие задачи.
Сбор, анализ и подготовка исходной информации об объектах конкретной предметной области для их преобразования в таблицы баз данных.
Разработка оптимального состава и структуры таблиц базы данных.
Установление логических связей между таблицами.
Разработка необходимого числа запросов для реализации поставленной задачи.
Разработка необходимого числа отчетов, отвечающих требованиям к выходным документам, определенных техническим заданием.
Разработка форм пользовательского интерфейса.
Разработка управляющих модулей, автоматизирующих работу пользователя с системой.
Реализация проекта и разработка технической документации. Реализация проекта разработанной СУБД сводится к следующим задачам:
заполнение таблиц баз данных информацией об объектах;
проверка функционирования СУБД при выполнении постав ленных задач;
разработка инструкций для пользователей;
сдача системы заказчику.
Основные компоненты
Проект СУБД должен содержать, как минимум, следующие основные компоненты:
таблицы;
запросы;
формы;
отчеты;
управляющие программы.
Таблицы. Таблицы базы данных могут иметь различное назначение (например, таблицы постоянной информации, таблицы переменной информации). Таблицы постоянной информации (условно постоянной) должны содержать данные, не меняющиеся в течение длительного времени (например, списки сотрудников организации, названия технологических операций, применяемых при изготовлении продукции, и т.п.). Таблицы переменной информации - это таблицы, информация об объектах в которых постоянно дополняется или изменяется пользователем.
Запросы. Запросы базы данных представляют собой некоторый набор команд, предназначенных для поиска и обработки информации в таблицах по заданным пользователем условиям (значениям полей). Современные СУБД позволяют формировать запросы:
на выборку;
обновление;
добавление;
удаление;
создание таблиц.
Запрос на выборку предназначен для поиска (выбора) информации в конкретной таблице (таблицах) базы данных.
Запросы на обновление предназначены для автоматического обновления данных в отдельных ячейках таблицы. Запросы на добавление или удаление предназначены для автоматического добавления записей в таблицы или удаления записей из таблиц БД.
Запросы на создание таблиц предназначены для создания новых таблиц на основе уже имеющихся в БД. При этом автоматически формируется структура новой таблицы.
Формы. Формы при разработке информационных систем предназначены для организации "дружественного" интерфейса между пользователем и компьютером. По назначению формы можно разделить на следующие группы:
формы для ввода данных в таблицы;
формы для ввода условий выполнения запросов;
формы для автоматического управления работой системы (кнопочные формы, формы -меню и др.)
Отчеты. Отчеты - это виды документов для вывода результатов обработки информации. Как правило, отчеты могут соответствовать формам отчетности, принятым на предприятии. Это могут быть формы бухгалтерской отчетности или формы технологической документации и др. Отчеты разрабатываются на основе информации, содержащейся в таблицах БД или формирующейся в результате выполнения запросов. При разработке СУБД ее элементы могут быть связаны между собой.
Управляющие программы. Управляющие программы предназначены для автоматизации работы с компонентами базы данных. Они пишутся с помощью макрокоманд (макросов) или на языке программирования, например VBA.
Теоретические вопросы для самоконтроля:
Перечислите программные средства при помощи которых осуществляется создание, преобразование и передачи информации.
Укажите принципы разработки многопользовательских баз данных сводятся к соблюдению обязательных условий.
Что означает системный подход к разработке информационной системы?
Какие принципы необходимо соблюдать при проектировании информационных систем?
Укажите последовательность разработки базы данных по принципу учета интересов всех потенциальных пользователей систем ?
Какие аспекты имеет стандартизация разработки информационных систем, учитывая их многопользовательский характер?
Что означает стандартизация информационного обеспечения ?
Что означает стандартизации программного обеспечения ?
Что означает стандартизация аппаратного обеспечения ?
Какие два типа (две архитектуры) организации применяют при разработке баз данных в локальных вычислительных сетях предприятия?
Перечислите стадии проектирования многопользовательских баз данных.
Какие этапы необходимо выполнить для разработки концептуальной модели многопользовательской базы данных?
Что является целью разработки информационной системы?
Для чего необходимо устанавливать состав пользователей информации для разрабатываемой базы данных?
Для чего разрабатывают концептуальную модель базы данных?
Что необходимо указать в техническом задании на проектирование СУБД?
Какие задачи решаются на этапе разработки проекта СУБД в соответствии с техническим заданием?
Какие задачи решаются на этапе реализации проекта и разработка технической документации?
Какие основные компоненты должен содержать проект СУБД?
Таблицы постоянной информации должны содержать данные, не меняющиеся в течение длительного времени.
Таблицы переменной информации должны содержать информацию об объектах в которых постоянно дополняется или изменяется пользователем.
Таблицы постоянной информации должны содержать данные, меняющиеся в течение длительного времени.
Таблицы переменной информации должны содержать информацию, не меняющеюся в течение длительного времени.
Что такое запрос к базе данных?
Какие типы запросов позволяют формировать современные системы управления базами данных (СУБД)?
Для чего предназначен запрос на выборку?
Для чего предназначен запрос на обновление?
Для чего предназначен запрос на создание таблиц?
Для чего предназначены формы при разработке информационных систем?
На какие группы можно разделить формы по их назначению?
На основе чего разрабатывается отчет?
Что понимается под отчетом?
Для чего предназначены управляющие программы?
3. Средства проектирования данныхЖизненный цикл информационной системы в общем случае начинается с момента принятия решения о ее создании и заканчивается после выведения ее из эксплуатации.
Основными его этапами являются:
проведение предпроектного обследования;
проектирование данных;
разработка приложений, тестирование, написание документации;
внедрение созданной информационной системы и обучение пользователей;
эксплуатация и сопровождение;
выведение из эксплуатации и утилизация.
На этапе предпроектного обследования осуществляются анализ и моделирование бизнес-процессов, подлежащих автоматизации (иногда этот процесс называется структурным моделированием), а также формулируются требования к будущему продукту. Нередко на этом же этапе производится выбор СУБД и инструментальных средств. Обычно подобное обследование проводится с участием потенциальных пользователей, являющихся экспертами в той или иной предметной области.
Этап проектирования данных также обычно проходит с участием потенциальных пользователей. Иногда в процессе проектирования данных создаются прототипы работающих приложений, позволяющих уточнить и дополнить требования к конечному продукту. Если предусматривается, что внедрение новой информационной системы будет сопровождаться выведением из эксплуатации ее предшественницы, то принимаются решения о том, каким образом использовать унаследованные данные, и в модель данных, результирующую этот этап, вносятся необходимые изменения.
Реальное же создание программного продукта, в том числе клиентских приложений и приложений, выполняющих генерацию отчетов и анализ данных, происходит на этапе разработки. Большую роль в этом случае также играют тестирование и документирование создаваемого продукта. Данный этап обычно завершается созданием дистрибутива приложения или его частей и документированием процедуры его инсталляции.
Авторы многих работ, посвященных общим принципам разработки проектов информационных систем, утверждают, что стоимость исправления ошибки, допущенной на предыдущем этапе жизненного цикла, примерно в десять раз превышает затраты на ее исправление на текущем этапе. В частности, многие разработчики сталкиваются с тем, что ошибки проектирования данных приводят иногда к написанию кода большого объема, так или иначе их компенсирующего, и нередко вызывают проблемы на этапе сопровождения готового продукта. Поскольку проектирование данных следует непосредственно за предпроектным обследованием, очень важно, чтобы эта часть работы над проектом была выполнена максимально качественно. Именно важность этого этапа обусловила в течение последних десяти лет стремительный рост популярности такой категории программного обеспечения, как средства проектирования данных.
Результаты различных этапов жизненного цикла информационных систем представлены в табл. 1.
Таблица 1. Этапы жизненного цикла информационных систем
Этап Результат
Проведение предпроектного обследования Модель бизнес-процессов, формирование требований к будущему проекту
Проектирование данных Логическая и физическая модели данных; база данных либо SQL-скрипт для ее генерации
Разработка приложений, тестирование, написание документации Приложения, готовые к внедрению
Внедрение созданной информационной системы и обучение пользователей Организованный процесс эксплуатации информационной системы, наличие у пользователей необходимых знаний и навыков
Эксплуатация и сопровождение Данные, результаты их анализа и обработки
Выведение из эксплуатации и утилизация Данные, предназначенные для переноса в новую информационную систему
Многие современные СУБД содержат визуальные средства (нередко входящие в состав утилит администрирования), позволяющие создать новую схему базы данных или просмотреть уже имеющуюся. Существуют также утилиты (поставляемые отдельно от СУБД), позволяющие разрабатывать или редактировать метаданные. Однако в последнее время все более популярными становятся так называемые CASE-средства (Computer-Aided System Engineering), имеющие в своем составе инструменты для создания диаграмм "сущность-связь" и проектирования данных.
В лекции дается общая характеристика CASE-средств создания и сопровождения информационных систем. Рассматриваются модели жизненного цикла программных систем, описываются модели структурного и объектно- ориентированного проектирования. Дается классификация CASE-средств и приводится характеристика наиболее популярных систем.
Проектирование базы данных (БД) включает в себя описание отношений между данными, которые накапливаются и обрабатываются информационной системой. Это описание выражается в виде инфологической модели (ИЛМ) предметной области. ИЛМ содержит, в частности, описание объектов и связей между ними, которые могут задаваться диаграммой "сущность-связь" (ER-диаграммой).
Результатом проектирования БД является даталогическая модель (ДЛМ) базы данных, содержащая описание таблиц, образующих проектируемую БД, на языке выбранной СУБД.
ER-диаграммы стали основой для более совершенных методологий создания ИЛМ, учитывающих такие требования, как простота для изучения и возможность автоматизации. В частности, такой методологией является методология IDEF 1X, реализованная в ряде специальных программ автоматизации проектирования БД, например, в программе ERwin.
CASE- технологии
Для автоматизации проектирования и разработки информационных систем в 70-80-е гг. широко применялась структурная методология, означающая использование формализованных методов описания разрабатываемой системы и принимаемых технических решений. При этом использовались графические средства описания различных моделей информационных систем с помощью схем и диаграмм. При ручной разработке информационных систем такие графические модели разрабатывать и использовать весьма трудоемко.
Отмеченные обстоятельства послужили одной из причин появления программно - технологических средств, получивших название CASE-средств и реализующих CASE-технологию создания и сопровождения информационных систем. Кроме структурной методологии, в ряде современных CASE-средств используется объектно-ориентированная методология проектирования.
Термин CASE (Computer Aided Software Engineering) дословно переводится как разработка программного обеспечения с помощью компьютера. В настоящее время этот термин получил более широкий смысл, означающий автоматизацию разработки информационных систем.
CASE-средства представляют собой программные средства, поддерживающие процессы создания и/или сопровождения информационных систем, такие как: анализ и формулировка требований, проектирование баз данных и приложений, генерация кода, тестирование, обеспечение качества, управление конфигурацией и проектом.
CASE-систему можно определить как набор CASE-средств, имеющих определенное функциональное предназначение и выполненных в рамках единого программного продукта.
CASE-технология обычно определяется как методология проектирования информационных систем плюс инструментальные средства, позволяющие наглядно моделировать предметную область, анализировать ее модель на всех этапах разработки и сопровождеения информационной системы и разрабатывать приложения для пользователей.
CASE-индустрия объединяет сотни фирм и компаний различной ориентации. Практически все серьезные зарубежные программные проекты осуществляются с использованием CASE-средств, а общее число распространяемых пакетов превышает 500 наименований.
Основная цель CASE-систем и средств состоит в том, чтобы отделить проектирование программного обеспечения от его кодирования и последующих этапов разработки (тестирование, документирование и пр.), а также автоматизировать весь процесс создания программных систем, или инжиниринг (от англ, engineering - разработка).
В последнее время все чаще разработка программ начинается с некоторого предварительного варианта системы. В качестве такого варианта может выступать специально для этого разработанный прототип, либо устаревшая и не удовлетворяющая новым требованиям система. В последнем случае для восстановления знаний о программной системе с целью последующего их использования применяют повторную разработку - реинжиниринг.
Повторная разработка сводится к построению исходной модели программной системы путем исследования ее программных кодов. Имея модель, можно ее усовершенствовать, а затем вновь перейти к разработке. Так часто и поступают при проектировании. Одним из наиболее известных принципов такого типа является принцип «возвратного проектирования» - Round Trip Engineering (RTE).
Современные CASE-системы не ограничиваются только разработкой, а чаще всего обеспечивают и повторную разработку. Это существенно ускоряет разработку приложений и повышает их качество.
Перспективная CASE-система
Динамика изменения позиций структурных и объектно-ориентированных систем позволяет предположить, что перспективная CASE-система будет объектно-ориентированной. Рассмотрим требования к идеальной перспективной CASE-системе.
Полнофункциональная объектно-ориентированная система должна решать задачи анализа и моделирования, проектирования, разработки (реализации), а также иметь эффективную инфраструктуру, обеспечивающую сервисом первые три основные задачи.
Для решения задач анализа и моделирования целесообразно иметь интегрированную среду разработчика, которая должна обеспечивать возможности:
динамического моделирования событий в системе;
динамической и согласованной коррекции всей совокупности диаграмм;
добавления пояснительных надписей к диаграммам моделей и в документацию;
автоматической генерации документации;
создания различных представлений и скрытия неиспользуемых слоев системы;
поддержки различных нотаций (это требование ослабевает в связи с переходом к единому языку моделирования).
Осуществление процесса проектирования предполагает наличие возможностей:
определения основной модели прикладной задачи (бизнес-модели, обычно объектно-ориентированной) и правил ее поведения (бизнес-правил);
поддержки процесса проектирования с помощью библиотек, оснащенных средствами хранения,
поиска и выбора элементов проектирования (объектов и правил);
создания пользовательского интерфейса и поддержания распространенных программных интерфейсов (поддержка стандартов OLE, OpenDoc, доступ к библиотекам HTML/Java и т. п.);
создания различных распределенных клиент-серверных приложений.
Средства разработки в составе CASE-системы должны обеспечивать построение приложения по результатам предыдущих этапов разработки приложения. Максимально высоким требованием к средствам разработки можно считать генерацию готовой к выполнению программы.
CASE-системы ближайшего будущего должны позволять создавать скелетные заготовки под классы, атрибуты и методы, готовые приложения на объектно-ориентированных языках программирования типа C++ или Smalltalk, либо программы на языках клиент-серверных продуктов (PowerBuilder, Forte, VisualAge, VisualWorks и т. д.). К поддерживаемым языкам, по-видимому, скоро добавится язык Java.
Для обеспечения связи с другими этапами жизненного цикла приложения средства CASE-системы должны включать и функции контроля программного кода на синтаксическую корректность и соответствие моделям.
Ядром инфраструктуры будущих CASE-систем должен быть репозиторий, отвечающий за генерацию кода, реинжиниринг и обеспечивающий соответствие между моделями и программными кодами. Основу репозитория составят объектно-ориентированные БД, хотя ранее для этого использовались реляционные БД. Другими важнейшими функциями инфраструктуры являются функции контроля версий и управления частями системы при коллективной разработке.
Составные части процесса проектирования данных
Процесс проектирования данных можно условно разделить на два этапа: логическое моделирование и физическое проектирование. Результатом первого из них является так называемая логическая (или концептуальная) модель данных, отображаемая обычно диаграммой "сущность-связь", или ER (Entity-Relationship) -диаграммой, которая представлена в одной из стандартных нотаций, принятых для отображения подобных диаграмм. Результатом второго этапа является готовая база данных либо скрипт на языке SQL, выполняемый для ее создания (таблица 2).
Таблица 2. Логическая модель
Этап Результат
Логическое моделирование Логическая модель
Физическое проектирование База данных или скрипт на языке SQL, выполняемый для ее создания
Логическое моделирование
Логическая модель данных описывает факты и объекты, подлежащие регистрации в будущей базе данных. Основными компонентами такой модели являются сущности, их атрибуты и связи между ними. Как правило, физическим аналогом сущности в будущей базе данных является таблица, а физическим аналогом атрибута - поле этой таблицы.
С логической точки зрения сущность представляет собой совокупность однотипных объектов или фактов, называемых экземплярами этой сущности. Физическим аналогом экземпляра обычно является запись в таблице базы данных. Как и записи в таблице реляционной СУБД, экземпляры сущности должны быть уникальными, то есть полный набор значений их атрибутов не должен дублироваться. И так же, как и поля в таблице, атрибуты могут быть ключевыми и неключевыми.
На этапе логического проектирования для каждого атрибута обычно определяется примерный тип данных (строковый, числовой, BLOB и др.). Конкретизация происходит на этапе физического проектирования, поскольку различные СУБД поддерживают разные типы данных и ограничения, на их длину или точность.
Связь с логической точки зрения представляет собой соотношение между сущностями, которое нередко может быть выражено обычными фразами, например: "Клиент размещает заказ" (, где существительными являются названия связанных между собой сущностей.
Подавляющее большинство средств проектирования данных дает возможность создавать ER-диаграммы визуально, изображая сущности и соединяя их связями с помощью манипулятора "мышь". Интерфейс таких средств нередко настолько прост, что позволяет освоить логическое проектирование данных не только разработчику, но и пользователю-непрограммисту, если таковой участвует в проектировании данных как эксперт в предметной области.
Отметим, что на этапе логического проектирования можно описать поведение СУБД при нарушении правил ссылочной целостности, определяемых данной связью (например, при удалении сведений о заказчике, разместившем хотя бы один заказ, для связи, изображенной на рисунке ). Для этого многие (но не все!) средства проектирования данных обладают не зависящим от СУБД языком шаблонов, на котором можно описать алгоритм обработки подобной ситуации, например с помощью соответствующих триггеров или иных объектов базы данных, а также набором стандартных шаблонов, реализующих некоторые типовые алгоритмы подобной обработки (например, отказ от удаления с последующей генерацией диагностического сообщения, каскадное удаление дочерних записей и др.). В процессе создания физической модели (о ней будет рассказано чуть ниже) эти шаблоны преобразуются в код на процедурном расширении языка SQL, применяемом в конкретной СУБД.
Ряд публикаций проводит градацию категорий логических моделей по степени детализации описания сущностей, атрибутов и связей. Модель, обсуждаемая с заказчиком, являющимся обычно экспертом в подлежащей автоматизации предметной области, а не программистом или аналитиком, должна содержать, например, основные сущности и связи, но не обязана иметь их детальную техническую проработку (в частности, описания алгоритмов обработки нарушений ссылочной целостности). В то же время модель, служащая основой технического задания на разработку клиентских приложений, обязана содержать детальное представление структуры данных, ключевых атрибутов, их текстовое описание, а также представлять сущности в нормализованном виде (иногда такая модель называется полной атрибутивной моделью). Иными словами, нормализация модели данных обычно происходит на этапе логического проектирования.
Отметим, что логическая модель данных, как правило, не связана с конкретной СУБД и не учитывает технические особенности конкретных платформ, применяемых при ее последующей физической реализации.
Физическое проектирование данных
Физическое проектирование данных осуществляется на основе логической модели. Результатом этого процесса является физическая модель, содержащая полную информацию, необходимую для генерации всех необходимых объектов в базе данных. Для СУБД, поддерживающих системный каталог, физическая модель соответствует его содержимому.
Обычно на основании физической модели создается SQL-скрипт (скрипт, содержащий набор команд на подмножестве языка SQL- Data Definition Language, DDL) для создания объектов базы данных, либо эти объекты создаются непосредственно из CASE-средства - подавляющее большинство современных средств такого класса поддерживает различные механизмы доступа к данным и может выступать в роли клиентского приложения, инициирующего выполнение DDL-скриптов.
В процессе физического проектирования следует определить наименования таблиц и типы данных для всех полей. Если необходимо, на этом же этапе описываются представления (если таковые будут создаваться) и может быть создан код хранимых процедур. Далее обычно требуется определить, какие именно объекты и каким образом будут создаваться: например с помощью каких SQL-предложений создаются индексы, с помощью каких объектов - триггеров или серверных ограничений - реализуется ссылочная целостность, создаются ли индексы для альтернативных ключей и т.д.
Пример диаграммы, отображающей физическую модель для SQL Server 7.0, соответствующую приведенной выше логической модели.
Пример скрипта для создания объектов базы данных, сгенерированный на основании этой модели с помощью одного из рассмотренных ниже CASE-средств, приведен ниже.
Пример простейшей физической модели данных
CREATE TABLE Customer(
CREATE TABLE Customer(
CustomerlD char(5) NOT NULL,
CompanyName nvarchar (40) NOT NULL,
ContactName nvarchar (30) NULL,
ContactTitle nvarchar (30) NULL,
Address nvarchar (60) NULL,
City nvarchar (15)NULL,
Region nvarchar (15) NULL,
PostalCode nvarchar (10) NULL,
Country nvarchar (15)NULL,
Phone nvarchar (24) NULL,
Fax nvarchar (24) NULL
)

ALTER TABLE Customer
ADD PRIMARY KEY (CustomerlD)
CREATE TABLE Order (
OrderlD int IDENTITY,
CustomerlD char(5) NULL,
EmployeelD int NULL,
OrderDate datetime NULL,
RequiredDate datetime NULL,
ShippedDate datetime NULL,
ShipVia int NULL,
Freight money NULL,
ShipName nvarchar(40) NULL,
ShipAddress nvarchar(60) NULL,
ShipCity nvarchar(15)NULL,
ShipRegion nvarchar(15)NULL,
ShipPostalCode nvarchar( 10) NULL,
ShipCountry nvarcharf 15) NULL,
FOREIGN KEY (CustomerlD)
REFERENCES Customer
)

CREATE INDEX XIF1 Order ON Order (CustomerID)

ALTER TABLE Order ADD PRIMARY KEY (OrderID)
create trigger tD_Customer on Customer for DELETE as
begin
declare @errno int, @errmsg varchar(255)
if exists (select * from deleted,Order
where Order.CustomerlD = deleted.CustomerlD)
begin
select @errno = 30001,
@errmsg = 'Cannot DELETE Customer because Order exists.'
goto error
end
return
error:
raiserror @errno @errmsg
rollback transaction
end
create trigger tU_Customer on Customer for UPDATE as
begin
declare @numrows int, @nullcnt int,
@validcnt int, ©insCustomerlD char(5),
@errno int, @errmsg varchar(255)

select @numrows = @@rowcount
if update(CustomerID)
begin
if exists (select * from deleted, Order where
Order.CustomerID = deleted. CustomerID)
begin
select @errno = 30005,
@errmsg = 'Cannot UPDATE Customer because Order exists.'
goto error
end
end
return
error:
raiserror @errno @errmsg
rollback transaction
end
Как правило, современные средства проектирования данных поддерживают несколько типов СУБД различных производителей (например, ERwin фирмы Computer Associates поддерживает более 20 различных СУБД). Уровень поддержки той или иной платформы в разных средствах проектирования данных также может быть различен. Например, конкретное средство может поддерживать или не поддерживать для данной СУБД такие особенности, как создание хранимых процедур, генерация объектов физической памяти (табличных пространств, сегментов отката и др.), задание местоположения объектов базы данных в физических объектах и т.д. Поэтому, выбирая средство проектирования данных для решения конкретной задачи, стоит поинтересоваться, каковы его возможности с точки зрения поддержки особенностей той или иной платформы - при удачном раскладе можно сэкономить немало времени на "ручное" доведение создаваемой базы данных (или DDL-скрипта для ее генерации) до необходимого состояния. При этом, естественно, чем больше возможностей и платформ поддерживает конкретное средство проектирования данных, тем дороже оно стоит (следует отметить, что CASE-средства вообще относятся к не самым дешевым программным продуктам - цены на них составляют обычно от одной до нескольких десятков тысяч долларов).
Отметим, что физическое проектирование может включать и дополнительную "ручную" работу по доведению базы данных или скрипта для ее генерации до "товарного" вида. Например, нередко в скрипт также включаются SQL-предложения для заполнения некоторых таблиц, данные в которых более или менее постоянны, таких, например, как список субъектов Российской Федерации или справочник телефонных кодов различных стран, а также нестандартные триггеры и процедуры.
В последнее время в техническое задание на разработку приложений нередко включается полное описание физической модели данных или ее части, с которой должно иметь дело разрабатываемое приложение. Подавляющее большинство современных средств проектирования данных предоставляют возможность не только документировать модель, но и создавать по ней отчеты, содержащие те или иные сведения о модели, в том числе сведения, необходимые для разработки приложений.
Некоторые средства проектирования данных позволяют осуществлять коллективное проектирование. Нередко средства проектирования данных дают возможность также присваивать таблицам и полям так называемые расширенные атрибуты, то есть свойства, связанные с отображением их в клиентских приложениях, созданных с помощью какого-либо средства разработки, а также генерировать код приложений для ввода и отображения данных.
Кроме того, подавляющее большинство средств проектирования данных позволяют восстанавливать физическую модель данных их системного каталога и представлять ее в виде ER-диаграммы (этот процесс называется обратным проектированием - reverse engineering), а также производить синхронизацию системного каталога и физической модели. При создании информационной системы, призванной использовать унаследованные от предшествующих ей систем данные, такая особенность весьма полезна - в этом случае логическое проектирование можно начать с модификации уже имеющейся модели (этот процесс получил название round-trip engineering).
Выводы
Жизненный цикл ИС − это непрерывный процесс, который начинается с момента принятия решения о необходимости создания ИС и заканчивается в момент ее полного изъятия из эксплуатации.
Основным нормативным документом, регламентирующим жизненный цикл ИС, является международный стандарт ISO/IEC 12207.
Структура жизненного цикла информационных систем по стандарту ISO/IEC 12207 базируется на трех группах процессов: основные процессы, вспомогательные процессы, обеспечивающие выполнение основных процессов, организационные процессы.
Под моделью жизненного цикла ИС понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении жизненного цикла.
Основным недостатком каскадного подхода является существенное запаздывание с получением результатов.
Спиральная модель ЖЦ делает упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Главная задача как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований.
Основная проблема спирального цикла − определение момента перехода на следующий этап.
Наибольшая потребность в использовании CASE-систем испытывается на начальных этапах разработки, а именно на этапах анализа и спецификации требований к ИС.
CASE-технологии обладают определенными преимуществами по сравнению с традиционной технологией оригинального проектирования: улучшение качества разрабатываемого программного приложения за счет средств автоматического контроля и генерации; возможность повторного использования компонентов разработки; поддержание адаптивности и сопровождения ИС; снижение времени создания системы; освобождение разработчиков от рутинной работы по документированию проекта, так как при этом используется встроенный документатор; возможность коллективной разработки ИС в режиме реального времени.
Инструментальные средства CASE - специальные программы, которые поддерживают одну или несколько методологий анализа и проектирования ИС.
Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы жизненного цикла, такая классификация в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы: средства анализа (Upper CASE), средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций; средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных; средства разработки приложений; средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций.
Теоретические вопросы для самоконтроля:
Что называют жизненным циклом (ЖЦ) программного обеспечения (ПО) ИС?
Что означают понятия «процесс» и «этапы»?
Какой стандарт является основным нормативным документом, регламентирующим жизненный цикл ИС?
На каких группах процессов базируется структура жизненного цикла?
Что понимают под моделью жизненного цикла ИС?
Какие существуют модели жизненного цикла ИС?
Каковы достоинства и недостатки моделей жизненного цикла ИС?
Что означает термин CASE?
На каких этапах разработки испытывается наибольшая потребность в использовании CASE-систем?
Что означают понятия «метод», «нотация», «инструментальные средства CASE»?
Что представляет собой архитектура CASE-средства?
По каким признакам классифицируются современные CASE-системы?
Какими CASE-средствами располагает Российский рынок программного обеспечения сегодня?
Чем логический уровень модели данных отличается от физического?
Какие проблемы возникают при документировании модели?
Структурное моделированиеМодель жизненного цикла (ЖЦ) цикла программного обеспечения информационной системы (ПО ИС) при автоматизированном проектировании ИС играет достаточно важную роль. Это обусловлено тем, что каждая из CASE-систем ориентирована на (поддерживает) определенную модель ЖЦ ПО ИС.
Жизненный цикл ПО ИС представляет собой непрерывный процесс, начинающийся с момента принятия решения о создании ПО и заканчивающийся при завершении его эксплуатации.
Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC12207 (InternationalOrganizationofStandardization- Международная организация по стандартизации/ InternationalElectrotechnicalCommission- международная комиссия по электротехнике). В нем определяется структура ЖЦ, содержащая процессы, действия и задачи, которые должны быть выполнены при создании ПО.
Под моделью ЖЦ ПО понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении ЖЦ. Наибольшее распространение получили следующие модели ЖЦ ПО: каскадная, с промежуточным контролем и спиральная.
Модели каскадная и с промежуточным контролем включают следующие этапы жизненного цикла ПО: анализ, проектирование, реализация, внедрение и сопровождение.
Каскадная модель предполагает строго последовательную реализацию перечисленных этапов жизненного цикла. Достоинствами такой модели являются: формирование на каждом этапе законченного комплекта документации и возможность планирования сроков завершения работ и соответствующих затрат. Недостатком модели является ее несоответствие реальному процессу создания ПО, который обычно не укладывается в жесткую схему и требует возврата к предыдущим этапам для уточнения или пересмотра принятых решений.
Модель с промежуточным контролем приближает жизненный цикл к реальному процессу создания и применения ПО. В отличие от каскадной модели, она допускает возврат с каждого этапа жизненного цикла на любой предыдущий этап для выполнения межэтапной корректировки. При этом обеспечивается большая надежность ПО, но вместе с тем увеличивается длительность периода разработки.
Спиральная модель жизненного цикла (рисунок 4.1) позволяет устранить недостатки предыдущих моделей. Основной упор в ней делается на начальные этапы: анализ и проектирование. На них реализуемость технических решений проверяется с помощью создания прототипов.

Рисунок 4.1 Спиральная модель жизненного цикла
При спиральной схеме разработки неполное завершение работ на очередном этапе позволяет переходить на следующий этап. Незавершенная работа может выполняться на следующем витке спирали. Тем самым обеспечивается возможность предъявить пользователям системы ее некоторый работоспособный вариант для уточнения требований.
Объектно - ориентированные модели
Большинство моделей объектно-ориентированного проектирования близки по возможностям, но имеют отличия в основном в форме представления. Популярность объектно-ориентированных технологий привела к сближению большинства известных моделей. Многообразие моделей порождает трудности проектировщиков по выбору модели и по обмену информацией при работе над разными проектами. В этой связи известные специалисты Г.Буч, Д.Рамбо и И.Джекобсон при поддержке фирмы Rational Software Corporation провели работу над унифицированной моделью и методом, получившим название UML (Unified Modeling Language - унифицированный язык моделирования).
Общая характеристика UML
UML представляет собой единый язык моделирования, предназначенный для спецификации, визуализации, конструирования и документирования материалов программных систем, а также для моделирования бизнеса и других непрограммных систем. В основу создания UML положены три наиболее распространенные модели:
Booch, получившая название по фамилии автора Гради Буча (Grady Booch);
ОМТ (Object Modeling Technique - метод моделирования объектов);
OOSE (Object-Oriented Software Engineering - объектно-ориентированное проектирование программного обеспечения).
На заключительной стадии разработки, унификации и принятия UML в качестве стандарта большой вклад внес консорциум OMG (Object Management Group - группа управления объектом). UML можно определить также как промышленный объектно- ориентированный стандарт моделирования. Он включает в себя в унифицированном виде лучшие методы визуального (графического) моделирования. В настоящее время имеется целый ряд инструментальных средств, производители которых заявляют о поддержке UML, среди них можно выделить: Rational Rose, Select Enterprise, Platinum и Visual Modeler.
Типы диаграмм UML
Создаваемый с помощью UML проект информационной системы может включать в себя следующие 8 видов диаграмм (diagrams):
прецедентов использования (use case),
классов (class),
состояний (statechart),
активности (activity),
следования (sequence),
сотрудничества (collaboration),
компонентов (component),
размещения (deployment).
Диаграммы состояний, активности, следования и сотрудничества образуют набор диаграмм, служащих для описания поведения разрабатываемой информационной системы. Причем, последние две обеспечивают описание взаимодействия объектов информационной системы. Диаграммы компонентов и размещения описывают физическую реализацию информационной системы.
Каждая из диаграмм может содержать элементы определенного типа. Типы допустимых элементов и отношений между ними зависят от вида диаграммы. Охарактеризуем указанные виды диаграмм более подробно.
Диаграммы прецедентов использования описывают функциональность ИС, видимую пользователями системы. Каждая функциональность изображается в виде прецедентов использования.
Прецедент - это типичное взаимодействие пользователя с системой, которое выполняет следующее:
описывает видимую пользователем функцию,
представляет различные уровни детализации,
обеспечивает достижение конкретной цели.
Прецедент изображается как овал, связанный с типичными пользователями, называемыми «актерами» (actors). Актером является любая сущность, взаимодействующая с системой извне, например человек, оборудование, другая система. Прецедент описывает, что система предоставляет актеру - определяет набор транзакций, выполняемый актером при диалоге с информационной системой. На диаграмме изображается один актер, но пользователей, выступающих в роли актера, может быть много. Диаграмма прецедентов использования имеет высокий уровень абстракции и позволяет определить функциональные требования к ИС.
Диаграммы классов описывают статическую структуру классов. В состав диаграмм классов входят следующие элементы: классы, объекты и отношения между ними. Класс представляется прямоугольником, включающим три раздела: имя класса, атрибуты и операции. Аналогичное обозначение применяется и для объектов, с той разницей, что к имени класса добавляется имя объекта и вся надпись подчеркивается.
Допускается отображение дополнительной информации (абстрактные операции и классы, стереотипы, общие и частные методы, интерфейсы, и т. д.). Ассоциации, или статические связи между классами, изображаются в виде связующей линии, на которой может указываться мощность ассоциации, направление, название, и возможное ограничение. Можно отразить свойства ассоциации, например отношение агрегации, когда составными частями класса являются другие классы. Отношение агрегации изображается в виде ромба, расположенного рядом с агрегирующим классом. Отношение обобщения изображается в виде треугольника и связующей линии, позволяя представить иерархию наследования классов.
Диаграммы состояний описывают поведение объекта во времени, моделируют все возможные изменения в состоянии объекта, вызванные внешними воздействиями со стороны других объектов или извне. Диаграммы состояний применяются для описания поведения объектов и для описания операций классов. Этот тип диаграмм описывает изменение состояния одного класса или объекта. Каждое состояние объекта представляется в виде прямоугольника с закругленными углами, содержащего имя состояния и, возможно, значение атрибутов объекта в данный момент времени. Переход осуществляется при наступлении некоторого события (например, получения объектом сообщения или приема сигнала) и изображается в виде стрелки, соединяющей два соседних состояния. Имя события указывается на переходе. На переходе могут указываться также действия, производимые объектом в ответ на внешние события.
Диаграммы активности представляют частный случай диаграмм состояний. Каждое состояние есть выполнение некоторой операции, и переход в следующее состояние происходит при завершении операции в исходном состоянии. Тем самым реализуемся процедурное, синхронное управление, обусловленное завершением внутренних действий. Описываемое состояние не имеет внутренних переходов и переходов по внешним событиям.
Для диаграмм активности используются аналогичные диаграммам состояний обозначения, но на переходах отсутствует сигнатура события и добавлен символ «синхронизации» переходов для реализации параллельных алгоритмов. Диаграммы активности используются в основном для описания операций классов.
Диаграмма следования определяет временную последовательность (динамику взаимодействия) передаваемых сообщений, порядок, вид и имя сообщения. На диаграмме изображаются объекты, непосредственно участвующие во взаимодействии, и не показываются статические ассоциации с другими объектами.
Диаграмма следования имеет два измерения. Первое - слева направо, в виде вертикальных линий, изображающих объекты, участвующие во взаимодействии. Верхняя часть линий дополняется прямоугольником, содержащим имя класса объекта или имя экземпляра объекта. Второе измерение - вертикальная временная ось. Посылаемые сообщения изображаются в виде стрелок с именем сообщения и упорядочены по времени возникновения.
Диаграммы сотрудничества описывают взаимодействие объектов системы, выполняемого ими для получения некоторого результата. Под получением результата подразумевается выполнение законченного действия, например, описание в терминах взаимодействующих объектов смоделированного ранее прецедента использования информационной системы или некоторого сервиса, объявленного как операция класса на соответствующей диаграмме.
Диаграмма сотрудничества изображает объекты, участвующие во взаимодействии, в виде прямоугольников, содержащих имя объекта, его класс и, возможно, значение атрибутов. Ассоциации между объектами изображаются в виде соединительных линий. Возможно указание имени ассоциации и ролей объектов в данной ассоциации. Динамические связи (потоки сообщений) представляются в виде соединительных линий между объектами, сверху которых располагается стрелка с указанием направления и имени сообщения.
Диаграмма компонентов служит для определения архитектуры разрабатываемой системы путем установления зависимости между программными компонентами: исходным, бинарным и/или исполняемым кодом. Во многих средах разработки модуль, или компонент, соответствует файлу. Пунктирные стрелки, соединяющие модули, показывают отношения взаимозависимости(как при компиляции).
Диаграммы размещения используются для задания конфигурации компонентов, процессов и объектов, действующих в системе на этапе выполнения. Кроме того, они показывают физическую зависимость аппаратных устройств, участвующих в реализации системы, и соединений между ними -маршрутов передачи информации.
Примеры диаграмм UML
Чтобы получить более наглядное представление, приведем ряд диаграмм UML. Рассмотрим пример, в котором описана объектная модель, построенная в Rational Rose 98. В качестве предметной области используем описание работы библиотеки, которая получает запросы от клиентов на различные издания и регистрирует информацию об их возвращении в фонды библиотеки.
Пример диаграммы прецедентов использования приведен на рисунке 4.2. На диаграмме приведен ряд выделенных при анализе реализуемых информационной системой функций: администрирование пользователей (Administrative Client); учет книг (Administrative Books); составление отчетов (Report) и поиск издания (Find Book).

Рисунок 4.2. Диаграмма прецедентов использования
Пример диаграммы следования приведен на рисунке 4.3. Приведенная диаграмма описывает поведение объектов во времени. Она показывает объекты и последовательность сообщений, посылаемых объектами.

Рисунок 4.3. Диаграмма следования
Отметим, что построение модели ИС до ее программной разработки является необходимым этапом проектирования. Хорошие модели позволяют наладить конструктивное взаимодействие между заказчиками, пользователями и разработчиками. Диаграммы UML обеспечивают ясное представление архитектурных решений для разрабатываемой системы. Сложность информационных систем растет и как следствие возрастает актуальность применения эффективных языков моделирования, таких как UML.
Теоретические вопросы для самоконтроля:
Что содержит и как описывается инфологическая модель (ИЛМ) предметной области.
Что является результатом проектирования БД.
Дайте определение зависимой и независимая сущности.
Идентифицирующая связь: определение и типы, графическое изображение
Дайте определение CASE-средствам и CASE-технологии.
Дайте определение понятия модели жизненного цикла ПО и назовите основные варианты моделей.
Перечислите требования к перспективной CASE-системе.
Охарактеризуйте спиральную модель жизненного цикла ПО.
Перечислите распространенные модели и диаграммы графического представления, используемые при структурном анализе и проектировании.
Охарактеризуйте методологию функционального моделирования, приведите пример декомпозиции диаграмм.
Что представляет собой унифицированный язык моделирования UML?
Назовите типы диаграмм унифицированного языка моделирования.
Для чего служат диаграммы прецедентов использования и диаграммы классов?
5. Моделирование данныхБазовые понятия
Одной из основных частей информационного обеспечения является информационная база. Как было определено выше (см. лекцию 9), информационная база (ИБ) представляет собой совокупность данных, организованную определенным способом и хранимую в памяти вычислительной системы в виде файлов, с помощью которых удовлетворяются информационные потребности управленческих процессов и решаемых задач. Разработка БД выполняется с помощью моделирования данных. Цель моделирования данных состоит в обеспечении разработчика ИС концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей, которые относительно легко могут быть отображены в любую систему баз данных. Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (ERD). С помощью ERD осуществляется детализация накопителей данных DFD – диаграммы, а также документируются информационные аспекты бизнес-системы, включая идентификацию объектов, важных для предметной области ( сущностей ), свойств этих объектов ( атрибутов ) и их связей с другими объектами (отношений).
Базовые понятия ERD
Сущность (Entity) — множество экземпляров реальных или абстрактных объектов (людей, событий, состояний, идей, предметов и др.), обладающих общими атрибутами или характеристиками. Любой объект системы может быть представлен только одной сущностью, которая должна быть уникально идентифицирована. При этом имя сущности должно отражать тип или класс объекта, а не его конкретный экземпляр (например, АЭРОПОРТ, а не ВНУКОВО).
Каждая сущность должна обладать уникальным идентификатором. Каждый экземпляр сущности должен однозначно идентифицироваться и отличаться от всех других экземпляров данного типа сущности. Каждая сущность должна обладать некоторыми свойствами:
иметь уникальное имя; к одному и тому же имени должна всегда применяться одна и та же интерпретация; одна и та же интерпретация не может применяться к различным именам, если только они не являются псевдонимами;
иметь один или несколько атрибутов, которые либо принадлежат сущности, либо наследуются через связь ;
иметь один или несколько атрибутов, которые однозначно идентифицируют каждый экземпляр сущности.
Каждая сущность может обладать любым количеством связей с другими сущностями модели.
Связь (Relationship) — поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Связь — это ассоциация между сущностями, при которой каждый экземпляр одной сущности ассоциирован с произвольным (в том числе нулевым) количеством экземпляров второй сущности, и наоборот.
Атрибут (Attribute) — любая характеристика сущности, значимая для рассматриваемой предметной области и предназначенная для квалификации, идентификации, классификации, количественной характеристики или выражения состояния сущности . Атрибут представляет тип характеристик или свойств, ассоциированных с множеством реальных или абстрактных объектов (людей, мест, событий, состояний, идей, предметов и т.д.). Экземпляр атрибута — это определенная характеристика отдельного элемента множества. Экземпляр атрибута определяется типом характеристики и ее значением, называемым значением атрибута. На диаграмме "сущность-связь" атрибуты ассоциируются с конкретными сущностями. Таким образом, экземпляр сущности должен обладать единственным определенным значением для ассоциированного атрибута.
Метод IDEFI
Наиболее распространенными методами для построения ERD-диаграмм являются метод Баркера и метод IDEFI.
Метод Баркера основан на нотации, предложенной автором, и используется в case-средстве Oracle Designer.
Метод IDEFI основан на подходе Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме. На основе совершенствования метода IDEFI создана его новая версия — метод IDEFIX, разработанный с учетом таких требований, как простота для изучения и возможность автоматизации. IDEFIX-диаграммы используются в ряде распространенных CASE-средств (в частности, ERwin, Design/IDEF).
В методе IDEFIX сущность является независимой от идентификаторов или просто независимой, если каждый экземпляр сущности может быть однозначно идентифицирован без определения его отношений с другими сущностями. Сущность называется зависимой от идентификаторов или просто зависимой, если однозначная идентификация экземпляра сущности зависит от его отношения к другой сущности (рисунки 5.1-5.2).

Рисунок 5.1. Независимые от идентификации сущности

Рисунок 5.2. Зависимые от идентификации сущности
Каждой сущности присваиваются уникальные имя и номер, разделяемые косой чертой "/" и помещаемые над блоком.
Связь может дополнительно определяться с помощью указания степени или мощности (количества экземпляров сущности-потомка, которое может порождать каждый экземпляр сущности-родителя). В IDEFIX могут быть выражены следующие мощности связей:
каждый экземпляр сущности-родителя может иметь ноль, один или более одного связанного с ним экземпляра сущности-потомка;
каждый экземпляр сущности-родителя должен иметь не менее одного связанного с ним экземпляра сущности-потомка;
каждый экземпляр сущности-родителя должен иметь не более одного связанного с ним экземпляра сущности-потомка;
каждый экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка.
Если экземпляр сущности-потомка однозначно определяется своей связью с сущностью-родителем, то связь называется идентифицирующей, в противном случае — неидентифицирующей.
Связь изображается линией, проводимой между сущностью-родителем и сущностью-потомком, с точкой на конце линии у сущности-потомка (рисунок 5.3 ). Мощность связей может принимать следующие значения: N — ноль, один или более, Z — ноль или один, Р — один или более. По умолчанию мощность связей принимается равной N.

Рисунок 5.3. Графическое изображение мощности связи
Идентифицирующая связь между сущностью-родителем и сущностью-потомком изображается сплошной линией. Сущность-потомок в идентифицирующей связи является зависимой от идентификатора сущностью. Сущность-родитель в идентифицирующей связи может быть как независимой, так и зависимой от идентификатора сущностью (это определяется ее связями с другими сущностями ).
Пунктирная линия изображает неидентифицирующую связь (рисунок 5.4). Сущность-потомок в неидентифицирующей связи будет независимой от идентификатора, если она не является также сущностью-потомком в какой-либо идентифицирующей связи.
Атрибуты изображаются в виде списка имен внутри блока сущности. Атрибуты, определяющие первичный ключ, размещаются наверху списка и отделяются от других атрибутов горизонтальной чертой (рисунок 5.4).
Сущности могут иметь также внешние ключи (Foreign Key), которые могут использоваться в качестве части или целого первичного ключа или неключевого атрибута. Для обозначения внешнего ключа внутрь блока сущности помещают имена атрибутов, после которых следуют буквы FK в скобках (рисунок 5.4).

Рисунок 5.4. Неидентифицирующая связь
Отображение модели данных в инструментальном средстве ERwin
ERwin имеет два уровня представления модели — логический и физический.
Логический уровень — это абстрактный взгляд на данные, когда данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире, например "Постоянный клиент", "Отдел" или "Фамилия сотрудника". Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами. Логическая модель данных может быть построена на основе другой логической модели, например на основе модели процессов. Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД.
Физическая модель данных, напротив, зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация обо всех объектах БД. Поскольку стандартов на объекты БД не существует (например, нет стандарта на типы данных), физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах — таблицах, колонках, индексах, процедурах и т.д.
Документирование модели
Многие СУБД имеют ограничение на именование объектов (например, ограничение на длину имени таблицы или запрет использования специальных символов — пробела и т. п.). Зачастую разработчики ИС имеют дело с нелокализованными версиями СУБД. Это означает, что объекты БД могут называться короткими словами, только латинскими символами и без использования специальных символов (т. е. нельзя назвать таблицу, используя предложение — ее можно назвать только одним словом). Кроме того, проектировщики БД нередко злоупотребляют "техническими" наименованиями, в результате таблица и колонки получают наименования типа RTD_324 или CUST_A12 и т.д. Полученную в результате структуру могут понять только специалисты (а чаще всего — только авторы модели), ее невозможно обсуждать с экспертами предметной области. Разделение модели на логическую и физическую позволяет решить эту проблему. На физическом уровне объекты БД могут называться так, как того требуют ограничения СУБД. На логическом уровне можно этим объектам дать синонимы — имена более понятные неспециалистам, в том числе на кириллице и с использованием специальных символов. Например, таблице CUST_A12 может соответствовать сущность Постоянный клиент. Такое соответствие позволяет лучше документировать модель и дает возможность обсуждать структуру данных с экспертами предметной области.
Масштабирование
Создание модели данных, как правило, начинается с разработки логической модели. После описания логической модели проектировщик может выбрать необходимую СУБД, и ERwin автоматически создаст соответствующую физическую модель. На основе физической модели ERwin может сгенерировать системный каталог СУБД или соответствующий SQL-скрипт. Этот процесс называется прямым проектированием (Forward Engineering). Тем самым достигается масштабируемость — создав одну логическую модель данных, можно сгенерировать физические модели под любую поддерживаемую ERwin СУБД. С другой стороны, ERwin способен по содержимому системного каталога или SQL-скрипту воссоздать физическую и логическую модель данных (Reverse Engineering). На основе полученной логической модели данных можно сгенерировать физическую модель для другой СУБД и затем создать ее системный каталог. Следовательно, ERwin позволяет решить задачу по переносу структуры данных с одного сервера на другой. Например, можно перенести структуру данных с Oracle на Informix (или наоборот) или перенести структуру dbf-файлов в реляционную СУБД, тем самым облегчив переход от файл-серверной к клиент-серверной ИС. Однако, формальный перенос структуры "плоских" таблиц на реляционную СУБД обычно неэффективен. Для того чтобы извлечь выгоды от перехода на клиент-серверную технологию, структуру данных следует модифицировать.
Для переключения между логической и физической моделью данных служит список выбора в центральной части панели инструментов ERwin (рисунок 5.5).
Если при переключении физической модели еще не существует, она будет создана автоматически.

Рисунок 5.5. Переключение между логической и физической моделью
Интерфейс ERwin. Уровни отображения модели
Интерфейс выполнен в стиле Windows-приложений, достаточно прост и интуитивно понятен. Рассмотрим кратко основные функции ERwin по отображению модели.
Каждому уровню отображения модели соответствует своя палитра инструментов. На логическом уровне палитра инструментов имеет следующие кнопки:
кнопку указателя (режим мыши) — в этом режиме можно установить фокус на каком-либо объекте модели;
кнопку внесения сущности ;
кнопку категории (категория, или категориальная связь, — специальный тип связи между сущностями, которая будет рассмотрена ниже);
кнопку внесения текстового блока;
кнопку перенесения атрибутов внутри сущностей и между ними;
кнопки создания связей: идентифицирующую, "многие-ко-многим" и неидентифицирующую.
На физическом уровне палитра инструментов имеет:
вместо кнопки категорий — кнопку внесения представлений (view);
вместо кнопки связи "многие-ко-многим" — кнопку связей представлений.
Для создания моделей данных в ERwin можно использовать две нотации: IDEFIX и IE (Information Engineering). В дальнейшем будет рассматриваться нотация IDEFIX.
ERwin имеет несколько уровней отображения диаграммы: уровень сущностей, уровень атрибутов, уровень определений, уровень первичных ключей и уровень иконок. Переключиться между первыми тремя уровнями можно с использованием кнопок панели инструментов. Переключиться на другие уровни отображения можно при помощи контекстного меню, которое появляется, если "кликнуть" по любому месту диаграммы, не занятому объектами модели. В контекстном меню следует выбрать пункт Display Level (рисунок 5.6) и затем — необходимый уровень отображения.

Рисунок 5.6. Выбор уровней отображения диаграммы
Построение логической модели
Различают три уровня логической модели, отличающихся по глубине представления информации о данных:
диаграмма сущность-связь (Entity Relationship Diagram, ERD);
модель данных, основанная на ключах (Key Based model, KB);
полная атрибутивная модель (Fully Attributed model, FA).
Диаграмма сущность-связь представляет собой модель данных верхнего уровня. Она включает сущности и взаимосвязи, отражающие основные бизнес-правила предметной области. Такая диаграмма не слишком детализирована, в нее включаются основные сущности и связи между ними, которые удовлетворяют основным требованиям, предъявляемым к ИС. Диаграмма сущность-связь может включать связи "многие-ко-многим" и не включать описание ключей. Как правило, ERD используется для презентаций и обсуждения структуры данных с экспертами предметной области.
Модель данных, основанная на ключах, — более подробное представление данных. Она включает описание всех сущностей и первичных ключей и предназначена для представления структуры данных и ключей, которые соответствуют предметной области.
Полная атрибутивная модель — наиболее детальное представление структуры данных: представляет данные в третьей нормальной форме и включает все сущности, атрибуты и связи.
Сущности и атрибуты
Основные компоненты диаграммы ERwin — это сущности, атрибуты и связи. Каждая сущность является множеством подобных индивидуальных объектов, называемых экземплярами. Каждый экземпляр индивидуален и должен отличаться от всех остальных экземпляров. Атрибут выражает определенное свойство объекта. С точки зрения БД (физическая модель) сущности соответствует таблица, экземпляру сущности — строка в таблице, а атрибуту — колонка таблицы.
Построение модели данных предполагает определение сущностей и атрибутов, т. е. необходимо определить, какая информация будет храниться в конкретной сущности или атрибуте. Сущность можно определить как объект, событие или концепцию, информация о которых должна сохраняться. сущности должны иметь наименование с четким смысловым значением, именоваться существительным в единственном числе, не носить "технических" наименований и быть достаточно важными для того, чтобы их моделировать. Именование сущности в единственном числе облегчает в дальнейшем чтение модели. Фактически имя сущности дается по имени ее экземпляра. Примером может быть сущности Заказчик (но не Заказчики!) с атрибутами Номер заказчика, Фамилия заказчика и Адрес заказчика. На уровне физической модели ей может соответствовать таблица Customer с колонками Customer_number, Customer_name и Customer_address. Каждая сущность должна быть полностью определена с помощью текстового описания. Для внесения дополнительных комментариев и определений к сущности служат свойства, определенные пользователем (UDP). Использование (UDP) аналогично их использованию в BPwin.
Как было указано выше, каждый атрибут хранит информацию об определенном свойстве сущности, а каждый экземпляр сущности должен быть уникальным. Атрибут или группа атрибутов, которые идентифицируют сущность, называется первичным ключом .
Очень важно дать атрибуту правильное имя. Атрибуты должны именоваться в единственном числе и иметь четкое смысловое значение. Соблюдение этого правила позволяет частично решить проблему нормализации данных уже на этапе определения атрибутов. Например, создание в сущности Сотрудник атрибута Телефоны сотрудника противоречит требованиям нормализации, поскольку атрибут должен быть атомарным, т. е. не содержать множественных значений. Согласно синтаксису IDEFIX имя атрибута должно быть уникально в рамках модели (а не только в рамках сущности!). По умолчанию при попытке внесения уже существующего имени атрибута ERwin переименовывает его.
Каждый атрибут должен быть определен, при этом следует избегать циклических определений, например, когда термин 1 определяется через термин 2, термин 2 — через термин 3, а термин 3 в свою очередь — через термин 1. Часто приходится создавать производные атрибуты, т. е. атрибуты, значение которых можно вычислить из других атрибутов. Примером производного атрибута может служить Возраст сотрудника, который может быть вычислен из атрибута Дата рождения сотрудника. Такой атрибут может привести к конфликтам; действительно, если вовремя не обновить значение атрибута Возраст сотрудника, он может противоречить значению атрибута Дата рождения сотрудника. Производные атрибуты — ошибка нормализации, однако их вводят для повышения производительности системы, чтобы не проводить вычисления, которые на практике могут быть сложными.
Связи. Связь является логическим соотношением между сущностями. Каждая связь должна именоваться глаголом или глагольной фразой. Имя связи выражает некоторое ограничение или бизнес-правило и облегчает чтение диаграммы. По умолчанию имя связи на диаграмме не показывается. На логическом уровне можно установить идентифицирующую связь "один-ко-многим", связь "многие-ко-многим" и неидентифицирующую связь "один-ко-многим".
В IDEFIX различают зависимые и независимые сущности. Тип сущности определяется ее связью с другими сущностями. Идентифицирующая связь устанавливается между независимой (родительский конец связи ) и зависимой (дочерний конец связи ) сущностями. Когда рисуется идентифицирующая связь, ERwin автоматически преобразует дочернюю сущность в зависимую. Зависимая сущность изображается прямоугольником со скругленными углами. Экземпляр зависимой сущности определяется только через отношение к родительской сущности. При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности автоматически переносятся в состав первичного ключа дочерней сущности. Эта операция дополнения атрибутов дочерней сущности при создании связи называется миграцией атрибутов. В дочерней сущности новые атрибуты помечаются как внешний ключ — FK.
При установлении неидентифицирующей связи дочерняя сущность остается независимой, а атрибуты первичного ключа родительской сущности мигрируют в состав неключевых компонентов родительской сущности. Неидентифицирующая связь служит для связывания независимых сущностей.
Идентифицирующая связь показывается на диаграмме сплошной линией с жирной точкой на дочернем конце связи, неидентифицирующая – пунктирной (рисунок. 5.6).
Мощность связей (Cardinality) — служит для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней.
Различают четыре типа сущности:
общий случай, когда одному экземпляру родительской сущности соответствуют 0, 1 или много экземпляров дочерней сущности ; не помечается каким-либо символом;
символом Р помечается случай, когда одному экземпляру родительской сущности соответствуют 1 или много экземпляров дочерней сущности (исключено нулевое значение);
символом Z помечается случай, когда одному экземпляру родительской сущности соответствуют 0 или 1 экземпляр дочерней сущности (исключены множественные значения);
цифрой помечается случай точного соответствия, когда одному экземпляру родительской сущности соответствует заранее заданное число экземпляров дочерней сущности.
Имя связи (Verb Phrase) — фраза, характеризующая отношение между родительской и дочерней сущностями. Для связи "один-ко-многим", идентифицирующей или неидентифицирующей, достаточно указать имя, характеризующее отношение от родительской к дочерней сущности (Parent-to-Child). Для связи многие-ко-многим следует указывать имена как Parent-to-Child, так и Child-to-Parent.
Типы сущностей и иерархия наследования
Как было указано выше, связи определяют, является ли сущность независимой или зависимой. Различают несколько типов зависимых сущностей.
Характеристическая — зависимая дочерняя сущность, которая связана только с одной родительской и по смыслу хранит информацию о характеристиках родительской сущности (рисунок 5.7).

Рисунок 5.7. Пример характеристической сущности "Хобби"
Ассоциативная — сущность, связанная с несколькими родительскими сущностями. Такая сущность содержит информацию о связях сущностей.
Именующая — частный случай ассоциативной сущности, не имеющей собственных атрибутов (только атрибуты родительских сущностей, мигрировавших в качестве внешнего ключа).
Категориальная — дочерняя сущность в иерархии наследования.
Иерархия наследования (или иерархия категорий) представляет собой особый тип объединения сущностей, которые разделяют общие характеристики. Например, в организации работают служащие, занятые полный рабочий день (постоянные служащие), и совместители. Из их общих свойств можно сформировать обобщенную сущность (родовой предок) Сотрудник (рисунок 5.7), чтобы представить информацию, общую для всех типов служащих. Специфическая для каждого типа информация может быть расположена в категориальных сущностях (потомках) Постоянный сотрудник и Совместитель.
Обычно иерархию наследования создают, когда несколько сущностей имеют общие по смыслу атрибуты, либо когда сущности имеют общие по смыслу связи (например, если бы Постоянный сотрудник и Совместитель имели сходную по смыслу связь "работает в" с сущностью Организация ), либо когда это диктуется бизнес-правилами.
Для каждой категории можно указать дискриминатор — атрибут родового предка, который показывает, как отличить одну категориальную сущность от другой ( атрибут Тип на рисунке 5.8).

Рисунок 5.8. Иерархия наследования. Неполная категория
Иерархии категорий делятся на два типа — полные и неполные. В полной категории одному экземпляру родового предка (сущность Служащий, рисунок 5.9) обязательно соответствует экземпляр в каком-либо потомке, т. е. в примере служащий обязательно является либо совместителем, либо консультантом, либо постоянным сотрудником.

Рисунок 5.9. Иерархия наследования. Полная категория
Если категория еще не выстроена полностью и в родовом предке могут существовать экземпляры, которые не имеют соответствующих экземпляров в потомках, то такая категория будет неполной. На рисунке 5.8 показана неполная категория — сотрудник может быть не только постоянным или совместителем, но и консультантом, однако сущность Консультант еще не внесена в иерархию наследования.
Ключи
Как было сказано выше, каждый экземпляр сущности должен быть уникален и должен отличаться от других атрибутов.
Первичный ключ (primary key) — это атрибут или группа атрибутов, однозначно идентифицирующая экземпляр сущности . атрибуты первичного ключа на диаграмме не требуют специального обозначения — это те атрибуты, которые находятся в списке атрибутов выше горизонтальной линии (см., например, рисунок 5.10).
В одной сущности могут оказаться несколько атрибутов или наборов атрибутов, претендующих на роль первичного ключа. Такие претенденты называются потенциальными ключами (candidate key).
Ключи могут быть сложными, т. е. содержащими несколько атрибутов. Сложные первичные ключи не требуют специального обозначения — это список атрибутов, расположенных выше горизонтальной линии.
Рассмотрим кандидатов на роль первичного ключа сущности Сотрудник (рисунок 5.10).

Рисунок 5.10. Определение первичного ключа для сущности "Сотрудник"
Здесь можно выделить следующие потенциальные ключи:
Табельный номер ;
Номер паспорта ;
Фамилия + Имя + Отчество.
Для того чтобы стать первичным, потенциальный ключ должен удовлетворять ряду требований:
Уникальность. Два экземпляра не должны иметь одинаковых значений возможного ключа. потенциальный ключ № 3 ( Фамилия + Имя + Отчество ) является плохим кандидатом, поскольку в организации могут работать полные тезки.
Компактность. Сложный возможный ключ не должен содержать ни одного атрибута, удаление которого не приводило бы к утрате уникальности. Для обеспечения уникальности ключа № 3 дополним его атрибутами Дата рождения и Цвет волос. Если бизнес-правила говорят, что сочетания атрибутов Фамилия + Имя + Отчество + Дата рождения достаточно для однозначной идентификации сотрудника, то Цвет волос оказывается лишним, т. е. ключ Фамилия + Имя + Отчество + Дата рождения + Цвет волос не является компактным.
При выборе первичного ключа предпочтение должно отдаваться более простым ключам, т. е. ключам, содержащим меньшее количество атрибутов. В приведенном примере ключи № 1 и 2 предпочтительней ключа № 3.
Атрибуты ключа не должны содержать нулевых значений. Значение атрибутов ключа не должно меняться в течение всего времени существования экземпляра сущности. Сотрудница организации может выйти замуж и сменить как фамилию, так и паспорт. Поэтому ключи № 2 и 3 не подходят на роль первичного ключа.
Каждая сущность должна иметь по крайней мере один потенциальный ключ. Многие сущности имеют только один потенциальный ключ. Такой ключ становится первичным. Некоторые сущности могут иметь более одного возможного ключа. Тогда один из них становится первичным, а остальные — альтернативными ключами.
Альтернативный ключ (Alternate Key) — это потенциальный ключ, не ставший первичным.
Нормализация данных
Нормализация данных — процесс проверки и реорганизации сущностей и атрибутов с целью удовлетворения требований к реляционной модели данных. Нормализация позволяет быть уверенным, что каждый атрибут определен для своей сущности, а также значительно сократить объем памяти для хранения информации и устранить аномалии в организации хранения данных. В результате проведения нормализации должна быть создана структура данных, при которой информация о каждом факте хранится только в одном месте. Процесс нормализации сводится к последовательному приведению структуры данных к нормальным формам — формализованным требованиям к организации данных. Известны шесть нормальных форм.
На практике обычно ограничиваются приведением данных к третьей нормальной форме. Для углубленного изучения нормализации рекомендуется книга К. Дж. Дейта "Введение в системы баз данных" (Киев; М.: Диалектика, 1998).
ERwin не содержит полного алгоритма нормализации и не может проводить нормализацию автоматически, однако его возможности облегчают создание нормализованной модели данных. Запрет на присвоение неуникальных имен атрибутов в рамках модели (при соответствующей установке опции Unique Name) облегчает соблюдение правила "один факт — в одном месте". Имена ролей атрибутов внешних ключей и унификация атрибутов также облегчают построение нормализованной модели.
Домены
Домен можно определить как совокупность значений, из которых берутся значения атрибутов . Каждый атрибут может быть определен только на одном домене, но на каждом домене может быть определено множество атрибутов. В понятие домена входит не только тип данных, но и область значений данных. Например, можно определить домен "Возраст" как положительное целое число и определить атрибут Возраст сотрудника как принадлежащий этому домену.
В ERwin домен может быть определен только один раз и использоваться как в логической, так и в физической модели.
Домены позволяют облегчить работу с данными как разработчикам на этапе проектирования, так и администраторам БД на этапе эксплуатации системы. На логическом уровне домены можно описать без конкретных физических свойств. На физическом уровне они автоматически получают специфические свойства, которые можно изменить вручную. Так, домен "Возраст" может иметь на логическом уровне тип Number, на физическом уровне колонкам домена будет присвоен тип INTEGER.
Каждый домен может быть описан, снабжен комментарием или свойством, определенным пользователем (UDP).
Создание физической модели данных
Физическая модель содержит всю информацию, необходимую для реализации конкретной БД. Различают два уровня физической модели:
трансформационную модель;
модель СУБД.
Трансформационная модель содержит информацию для реализации отдельного проекта, который может быть частью общей ИС и описывать подмножество предметной области. Данная модель позволяет проектировщикам и администраторам БД лучше представить, какие объекты БД хранятся в словаре данных, и проверить, насколько физическая модель удовлетворяет требованиям к ИС.
Модель СУБД автоматически генерируется из трансформационной модели и является точным отображением системного каталога СУБД.
Физический уровень представления модели зависит от выбранного сервера. ERwin поддерживает более 20 реляционных и нереляционных БД.
По умолчанию ERwin генерирует имена таблиц и индексов по шаблону на основе имен соответствующих сущностей и ключей логической модели, которые в дальнейшем могут быть откорректированы вручную. Имена таблиц и колонок будут сгенерированы по умолчанию на основе имен сущностей и атрибутов логической модели.
Правила валидации и значения по умолчанию
ERwin поддерживает правила валидации для колонок, а также значение, присваиваемое колонкам по умолчанию.
Правило валидации задает список допустимых значений для конкретной колонки и/или правила проверки допустимых значений. В список допустимых значений можно вносить новые значения. ERwin позволяет сгенерировать правила валидации соответственно синтаксису выбранной СУБД с учетом границ диапазона или списка значений.
Значение по умолчанию – значение, которое нужно ввести в колонку, если никакое другое значение не задано явным образом во время ввода данных. С каждой колонкой или доменом можно связать значение по умолчанию. Список значений можно редактировать.
После создания правила валидации и значения по умолчанию их можно присвоить одной или нескольким колонкам или доменами.
Индексы
В БД данные обычно хранятся в том порядке, в котором их ввели в таблицу. Многие реляционные СУБД имеют страничную организацию, при которой таблица может храниться фрагментарно в разных областях диска, причем строки таблицы располагаются на страницах неупорядоченно. Такой способ позволяет быстро вводить новые данные, но затрудняет поиск данных.
Чтобы решить проблему поиска, СУБД используют объекты, называемые индексами. Индекс содержит отсортированную по колонке или нескольким колонкам информацию и указывает на строки, в которых хранится конкретное значение колонки. Поскольку значения в индексе хранятся в определенном порядке, при поиске просматривать нужно значительно меньший объем данных, что существенно уменьшает время выполнения запроса. Индекс рекомендуется создавать для тех колонок, по которым часто производится поиск.
При генерации схемы физической БД ERwin автоматически создает индекс на основе первичного ключа каждой таблицы, а также на основе всех альтернативных ключей и внешних ключей, поскольку эти колонки наиболее часто используются для поиска данных. Можно отказаться от генерации индексов по умолчанию и создать собственные индексы. Для увеличения эффективности поиска администратор БД должен анализировать часто выполняемые запросы и на основе анализа создавать собственные индексы.
Триггеры и хранимые процедуры
Триггеры и хранимые процедуры – это именованные блоки кода SQL, которые заранее откомпилированы и хранятся на сервере для того, чтобы быстро производить обработку запросов, валидацию данных и другие часто выполняемые функции. Хранение и выполнение кода на сервере позволяет создавать код только один раз, а не в каждом приложении, работающем с БД. Это экономит время при написании и сопровождении программ. При этом гарантируется, что целостность данных и бизнес-правила поддерживаются независимо от того, какое именно клиентское приложение обращается к данным. Триггеры и хранимые процедуры не требуется пересылать по сети из клиентского приложения, что значительно снижает сетевой трафик.
Хранимой процедурой называется именованный набор предварительно откомпилированных команд SQL, который может вызываться из клиентского приложения или из другой хранимой процедуры .
Триггером называется процедура, которая выполняется автоматически как реакция на событие. Таким событием может быть вставка, изменение или удаление строки в существующей таблице. Триггер сообщает СУБД, какие действия нужно выполнить при выполнении команд SQL INSERT, UPDATE или DELETE для обеспечения дополнительной функциональности, выполняемой на сервере.
Триггер ссылочной целостности – это особый вид триггера, используемый для поддержания целостности между двумя таблицами, которые связаны между собой. Если строка в одной таблице вставляется, изменяется или удаляется, то триггер ссылочной целостности сообщает СУБД, что нужно делать с теми строками в других таблицах, у которых значение внешнего ключа совпадает со значением первичного ключа вставленной строки (измененной или удаленной строки).
Для генерации триггеров ERwin использует механизм шаблонов – специальных скриптов, использующих макрокоманды. При генерации кода триггера вместо макрокоманд подставляются имена таблиц, колонок, переменные и другие фрагменты кода, соответствующие синтаксису выбранной СУБД. Шаблоны триггеров ссылочной целостности, генерируемые ERwin по умолчанию, можно изменять.
Для создания и редактирования хранимых процедур ERwin располагает специальными редакторами, аналогичными редакторам, используемым для создания триггеров. В отличие от триггера хранимая процедура не выполняется в ответ на какое-то событие, а вызывается из другой программы, которая передает на сервер имя процедуры. Хранимая процедура более гибкая, чем триггер, поскольку может вызывать другие хранимые процедуры. Ей можно передавать параметры, и она может возвращать параметры, значения и сообщения.
Проектирование хранилищ данных
В хранилища данных помещают данные, которые редко меняются. Хранилища ориентированы на выполнение аналитических запросов, обеспечивающих поддержку принятия решений для руководителей и менеджеров. При проектировании хранилищ данных необходимо выполнять следующие требования:
хранилище должно иметь понятную для пользователей структуру данных;
должны быть выделены статические данные, которые модифицируются по расписанию (ежедневно, еженедельно, ежеквартально);
должны быть упрощены требования к запросам для исключения запросов, требующих множественных утверждений SQL в традиционных реляционных СУБД;
должна обеспечиваться поддержка сложных запросов SQL, требующих обработки миллионов записей.
Как видно из этих требований, по своей структуре реляционные СУБД существенно отличаются от хранилищ данных. Нормализация данных в реляционных СУБД приводит к созданию множества связанных между собой таблиц. Выполнение сложных запросов неизбежно приводит к объединению многих таблиц, что значительно увеличивает время отклика. Проектирование хранилища данных подразумевает создание денормализованной структуры данных, ориентированных в первую очередь на высокую производительность при выполнении аналитических запросов. Нормализация делает модель хранилища слишком сложной, затрудняет ее понимание и снижает скорость выполнения запроса. Для эффективного проектирования хранилищ данных ERwin использует размерную модель – методологию проектирования, предназначенную специально для разработки хранилищ данных. Размерное моделирование сходно с моделированием связей и сущностей для реляционной модели, но имеет другую цель. Реляционная модель акцентируется на целостности и эффективности ввода данных. Размерная модель ориентирована в первую очередь на выполнение сложных запросов
В размерном моделировании принят стандарт модели, называемый схемой "звезда", которая обеспечивает высокую скорость выполнения запроса посредством денормализации и разделения данных. Невозможно создать универсальную структуру данных, обеспечивающую высокую скорость обработки любого запроса, поэтому схема "звезда" строится для обеспечения наивысшей производительности при выполнении самого важного запроса (или группы запросов).
Схема "звезда" обычно содержит одну большую таблицу, называемую таблицей факта, помещенную в центре. Ее окружают меньшие таблицы, называемые таблицами размерности, которые связаны с таблицей факта радиальными связями.
Для создания БД со схемой "звезда" необходимо проанализировать бизнес-правила предметной области для выяснения центрального запроса. Данные, обеспечивающие выполнение этого запроса, должны быть помещены в центральную таблицу. При проектировании хранилища важно определить источник данных, метод, которым данные извлекаются, преобразуются и фильтруются, прежде чем они импортируются в хранилище. Знания об источнике данных позволяют поддерживать регулярное обновление и проверку качества данных.
Вычисление размера БД
ERwin позволяет рассчитать приблизительный размер БД в целом, а также таблиц, индексов и других объектов через определенный период времени после начала эксплуатации ИС. Расчет строится на основе следующих параметров: начальное количество строк; максимальное количество строк; прирост количества строк в месяц. Результаты расчетов сводятся в отчет.
Прямое и обратное проектирование
Прямым проектированием называется процесс генерации физической схемы БД из логической модели. При генерации физической схемы ERwin включает триггеры ссылочной целостности, хранимые процедуры, индексы, ограничения и другие возможности, доступные при определении таблиц в выбранной СУБД.
Обратным проектированием называется процесс генерации логической модели из физической БД. Обратное проектирование позволяет конвертировать БД из одной СУБД в другую. После создания логической модели БД путем обратного проектирования можно переключиться на другой сервер и произвести прямое проектирование.
Кроме режима прямого и обратного проектирования программа обеспечивает синхронизацию между логической моделью и системным каталогом СУБД на протяжении всего жизненного цикла создания ИС.
Генерация кода клиентской части с помощью ERwin
Расширенные атрибуты
ERwin поддерживает не только проектирование сервера БД, но и автоматическую генерацию клиентского приложения в средах разработки MS Visual Basic и Power Builder. Технология генерации состоит в том, что на этапе разработки физической модели данных каждой колонке присваиваются расширенные атрибуты, содержащие информацию о свойствах объектов клиентского приложения (в том числе и визуальных), которые будут отображать информацию, хранящуюся в соответствующей колонке. Эта информация записывается в файле модели. На основе информации, содержащейся в расширенных атрибутах, генерируются экранные формы. Полученный код может быть откомпилирован и выполнен без дополнительного ручного кодирования.
Каждой колонке в модели ERwin можно задать предварительно описанные и именованные свойства:
правила валидации (проверка значений);
начальные значения, устанавливаемые по умолчанию;
стиль визуального объекта (например, радиокнопка, поле ввода и др.);
формат изображения.
Для описания каждого свойства ERwin содержит соответствующие редакторы.
Генерация кода в Visual Basic
ERwin поддерживает генерацию кода в Visual Basic версий 4.0 и 5.0. В качестве источника информации при генерации форм служит модель ERwin. С помощью ERwin можно одновременно описывать как клиентскую часть (объекты, отображающие данные на экране), так и сервер БД (процедуры и триггеры ), тем самым оптимально распределяя функциональность ИС между клиентской и серверной частью. Компонент ERwin Form Wizard автоматически проектирует формы с дочерними объектами – кнопками, списками, полями, радиокнопками и т. д., используя расширенные атрибуты. Совместное использование ERwin и Visual Basic позволяет сократить жизненный цикл разработки ИС путем употребления для каждой задачи наиболее эффективного инструмента. Visual Basic может быть использован для проектирования визуального интерфейса, а ERwin – для разработки физической и логической модели данных с последующей генерацией системного каталога сервера. Если БД уже существует, то с помощью ERwin можно провести обратное проектирование, полученную модель дополнить расширенными атрибутами и сгенерировать клиентское приложение.
Создание отчетов
Для генерации отчетов в ERwin имеется простой и эффективный инструмент – Report Browser. По умолчанию Report Browser содержит предварительно определенные отчеты, позволяющие наглядно представить информацию об основных объектах модели данных – как логической, так и физической. С помощью специального редактора существующие отчеты можно изменить или создать собственный отчет. Каждый отчет может быть настроен индивидуально, данные в нем могут быть отсортированы и отфильтрованы. Browser Report позволяет сохранять результаты выполнения отчетов, печатать и экспортировать их в распространенные форматы.
Генерация словарей
Для управления большими проектами ERwin имеет специальный инструмент – ERwin Dictionary, который обеспечивает коллективную работу над диаграммами и позволяет сохранять и документировать различные версии моделей данных. ERwin Dictionary представляет собой специальную БД, которая позволяет решить проблемы документирования и хранения моделей, однако не полностью отвечает требованиям многопользовательской работы.
Теоретические вопросы для самоконтроля:
Что представляет собой информационная база (ИБ)?
В чем состоит цель моделирования данных?
Какое самое распространенное средство моделирования данных?
Что можно осуществить с помощью ERD (диаграммы "сущность-связь")?
Базовое понятие ERD: Сущность (Entity)
Какими свойствами должна обладать каждая сущность?
Базовое понятие ERD: Связь (Relationship)
Базовое понятие ERD:Атрибут (Attribute)
Какие самые распространенные методы для построения ERD-диаграмм?
На чем основан метод IDEFI?
Когда в методе IDEFIX сущность называют независимой от идентификаторов или просто независимой?
Какую сущность называют зависимой от идентификаторов или просто зависимой?
В каких CASE- средствах используются IDEFIX-диаграммы?
6. Инструментальные средства автоматизации проектированияУтилиты автоматизированного проектирования базы данных. Построение диаграмм.
На этапе инфологического проектирования базы данных должна быть построена модель предметной области, не привязанная к конкретной СУБД, понятная не только разработчикам информационной системы, но и экономи- стам, менеджерам и другим специалистам. В то же время модель предметной области должна максимально точно отражать семантику предметной области, выявлять бизнес–правила и позволять легко перейти к модели данных конкретной СУБД.
Такими моделями являются модели "сущность-связь". Зачастую эти модели называют моделями данных. Но этот термин неудачен, т. к. перекликается с термином "модель данных". Известно несколько методологий построения моделей "сущность-связь". Наибольшее распространение получила методология IDEF1X. Рассмотрим построение моделей "сущность-связь", ориентируясь на продукт CA ERwin Data Modeler. Для простоты будем использовать старое название продукта: ERwin.
ERwin имеет два уровня представления модели:
– Логический уровень, соответствующий инфологическому этапу про-
ектирования и не привязанный к конкретной СУБД. Модели логического уровня оперируют с понятиями сущностей, атрибутов и связей, которые на этом уровне именуются на естественном языке (в нашем случае – на русском) так, как они называются в реальном мире.
– Физический уровень – это отображение логической модели на модель данных конкретной СУБД. Одной логической модели может соответствовать
несколько физических моделей. Причем, Erwin (как и другие CASE-системы проектирования баз данных) позволяет автоматизировать отображение логи-
ческой модели на физическую.
Модель"сущность-связь"строитсяввидедиаграммы "сущность-связь", основными компонентами которой являются сущности (Entity) и связи (Relationship). Отсюда происходят часто используемые названия мо-дели (ER-модель) и диаграммы (ER-диаграмма).
Сущность – это абстракция множества предметов или явлений реального мира, информацию о которых надо сохранить. Все экземпляры сущности имеют одинаковые характеристики и подчиняются одним и тем же пра- вилам поведения. Например, можно выделить сущность СТУДЕНТ. Экземп- лярами сущности СТУДЕНТ будут данные о конкретных студентах. Сущ- ность должна иметь имя – существительное в единственном числе.
Сущности обладают определенными свойствами – атрибутами. Атрибут – это абстракция одной характеристики объекта или явления реального мира. Каждый атрибут должен иметь имя – существительное в единственном числе, и получать значение из некоторого множества допустимых значений – домена.
У каждой сущности должен быть выделен идентификатор, или первич- ный ключ. Первичный ключ – это один или несколько атрибутов, однозначно определяющих каждый экземпляр сущности. Если первичный ключ состоит из нескольких атрибутов, то он называется составным. Первичный ключ не должен изменяться и принимать неопределенное значение (NULL). Ключ должен быть компактным, т. е. не содержать слишком много атрибутов. Сущность может иметь несколько потенциальных ключей, из которых должен быть выбран первичный ключ. Иногда приходится использовать искусственный первичный ключ (некоторый номер или код), когда ключ содержит слишком много атрибутов (в пределе каждый экземпляр сущности может оп- ределяться всем множеством атрибутов). Используется также понятие внешнего ключа. Внешний ключ – это первичный ключ другой сущности, который мигрирует (копируется) в сущность и служит для связи сущностей.
Пример сущности показан на рисунок 6.1.
Каждая сущность должна сопровождаться описанием. Описание сущности должно объяснять ее смысл, а не то, как будет использоваться инфор- мация данной сущности. Описание должно быть ясным, полным и непроти- воречивым, понятным специалистам предметной области.

Рисунок 6.1. Пример сущности
Сущности и атрибуты выделяются в результате анализа требований к системе. При выборе атрибутов целесообразно придерживаться следующих правил (не входящих в IDEF1X), позволяющих перейти к физической модели, находящейся в третьей нормальной форме:
1. Атрибуты должны быть неделимыми.
2. Каждый неключевой атрибут должен полностью зависеть от состав-
ного ключа, а не от части ключа.
3. Не должно существовать транзитивных зависимостей атрибутов от ключа. Например, если ключ ТАБЕЛЬНЫЙ_НОМЕР определяет атрибут НО-
МЕР_ОТДЕЛА, а НОМЕР_ОТДЕЛА определяет ТЕЛЕФОН, то ТАБЕЛЬНЫЙ_НОМЕР транзитивно определяет ТЕЛЕФОН.
Связи
Связи между объектами реального мира отражаются в виде связей (от- ношений, ассоциаций) между сущностями. Отношение – это ассоциация или "связь" между двумя сущностями. Отношение представляется в модели ли- нией, соединяющей две сущности, и именем отношения – глагольной конст- рукцией, которая описывает, как две сущности зависят друг от друга. Имена сущностей, соединенные именем отношения, должны образовывать осмысленную фразу, описывающую бизнес-правило отношения. Например, СТУДЕНТ <Обучается в> УЧЕБНАЯ ГРУППА. В примере имя отношения показано в угловых скобках. Отношения двунаправлены, поэтому должны иметь имена в каждом направлении.
Отношение обладает следующими свойствами:
степень,
направленность,
тип,
мощность,
обязательность.
Степень отношения представляет собой число сущностей, ассоциированных с отношением. Чаще всего используются бинарные отношения, связывающие две сущности. Унарные, или рекурсивные отношения представляют случаи, когда экземпляр сущности связан с другим экземпляром той же самой сущности. Часто унарные или рекурсивные отношения рассматриваются как бинарные рекурсивные отношения, связывающие экземпляр сущности с другим ее экземпляром.
Направленность отношения указывает на исходную сущность в отношении. Сущность, из которой отношение исходит, называется родительской сущностью. Сущность, в которой отношение заканчивается, называется подчиненной (дочерней) сущностью. Направленность отношения определяется взаимосвязью между сущностями и зависит от типа и мощности отношения. В отношении между независимой и зависимой сущностями отношение исходит из независимой сущности и заканчивается в зависимой сущности. Если обе сущности независимые, отношение симметрично. В отношении один-ко-многим родительской является сущность, входящая в отношение однократно. Отношения многие-ко-многим симметричны. Ключ родительской сущности мигрирует (повторяется) в дочерней сущности. Такой мигрировавший ключ в дочерней сущности называется внешним ключом. Внешний ключ в зависимости от типа связи может стать частью составного ключа дочерней сущности или неключевым атрибутом дочерней сущности. С помощью внешнего ключа экземпляр дочерней сущности ссылается на соответствующий экземпляр родительской сущности.
В ERwin отношение между двумя сущностями, или сущности самой с собой, может принадлежать к одному из следующих типов:
идентифицирующее отношение,
неидентифицирующее отношение,
типизирующее отношение,
отношение многие-ко-многим,
рекурсивное отношение.
Каждый тип отношений определяет поведение атрибутов первичного ключа, когда они мигрируют из родительской сущности в подчиненную. Ниже будут описаны особенности каждого из типов отношений.
Идентифицирующим является отношение между двумя сущностями, в котором каждый экземпляр подчиненной сущности идентифицируется значениями атрибутов родительской сущности. Это означает, что экземпляр подчиненной сущности зависит от родительской сущности и не может существовать без экземпляра родительской сущности. В идентифицирующем отношении единственный экземпляр родительской сущности связан с множеством экземпляров подчиненной. Атрибуты первичного ключа родительской сущности мигрируют в атрибуты подчиненной, чтобы стать там атрибутами первичного ключа. На рис. 6.2 представлено идентифицирующее отношение между сущностями Заказ и Состав заказа. В сущности Заказ использован искусственный первичный ключ ID заказа (Идентификатор заказа), который мигрировал в дочернюю сущность Состав заказа и стал там первичным ключом. В реальной диаграмме атрибут Заказчик, скорее всего, будет являться мигрировавшим ключом сущности, описывающей заказчиков. Пример рисунка 5.2 показывает, что дочерняя сущность не может существовать без родительской. Этот пример также демонстрирует, как показать переменный состав заказа: в заказ может входить произвольное количество товаров.

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

Рисунок 6.3. Пример обязательного неидентифицирующего отношения
На примере рисунка 6.3 рассмотрим также понятие обязательности отношения. Неидентифицирующее отношение называется обязательным (No Nulls), если все экземпляры дочерней сущности должны участвовать в отношении. Неидентифицирующее отношение называется необязательным (Nulls Allowed), если некоторые экземпляры дочерней сущности могут не участвовать в отношении. Очевидно, что студент должен принадлежать одной из учебных групп. На рисунке 6.4 показан пример необязательно отношения: допускается, что сотрудник может не принадлежать ни одному из отделов.

Рис. 6.4. Пример необязательного неидентифицирующего отношения
Типизирующими называются отношения между родительской и одной или более подчиненными сущностями, когда сущности разделяют общие характеристики. Такие отношения называются еще иерархией наследования или иерархией категорий. Типизирующие отношения используются в том случае, когда экземпляр родительской сущности определяет различные наборы атрибутов в подчиненных сущностях. Например, имеются различные категории сотрудников, отличающиеся только небольшим количеством атрибутов (рисунок 6.5). Для каждой категории необходимо указать дискриминатор – атрибут родительской сущности, показывающий, как отличить одну категориаль- ную сущность от другой. На рисунке 6.5 дискриминатором является атрибут Тип. На рисунке 6.5 показана полная категория, т. е. каждый экземпляр сущности сотрудник относится к одной из перечисленных категорий. Возможна неполная категория, когда существуют экземпляры родительской сущности, не имеющие соответствующих экземпляров в дочерних сущностях (значок категории содержит одну горизонтальную линию).

Рисунок 6.5. Пример полной категории иерархии наследования
Отношения многие-ко-многим возникают тогда, где один экземпляр одной сущности связан с несколькими экземплярами другой, и один экземпляр этой другой сущности также связан с несколькими экземплярами первой сущности. Эти отношения также называют неспецифическими. Отношения многие-ко-многим используются только на логическом уровне. На физическом уровне эти отношения реализуются за счет использования ассоциативной сущности, содержащей ключи родительских сущностей и, возможно, дополнительные атрибуты. Для большей наглядности диаграммы желательно ввести ассоциативные сущности на логическом уровне. На рисунке 6.6 показан пример связи "многие-ко-многим", а на рисунке 6.7 – пример использования ассоциативной сущности.

Рисунок 6.6. Пример связи "многие-ко-многим"

Рисунок 6.7. Пример использования ассоциативной сущности
Рекурсивное отношение – это неидентифицирующее отношение между двумя сущностями, которое указывает, что экземпляр сущности может быть связан с другим экземпляром той же самой сущности. При рекурсивном отношении родительская и подчиненная сущности совпадают. На рисунке 6.8 показаны примеры двух реализаций рекурсивного отношения для сущности Сотрудник, с использованием имени роли и без него. Имя роли показывает, какую роль играет внешний ключ в сущности. В данном примере внешний ключ задает табельный номер. Обратите внимание, что ERwin "унифицирует" атрибуты внешнего ключа и первичного ключа, когда имя роли не используется. Использование имени роли приводит к размещению внешнего ключа в качестве неключевого атрибута.

Рисунок 6.8. Примеры реализации рекурсивных отношений с использованием имени роли и без него в сущности Сотрудник
Мощность отношения задает максимальное число экземпляров одной сущности, которые могут быть связаны с экземплярами другой сущности. Мощность отношения определяется для обеих сторон отношения – для исходной и завершающей сущностей. Количество элементов определяет максимальное количество экземпляров сущностей, участвующих в отношении, в то время как обязательность определяет минимальное число экземпляров. Количество элементов часто выражается как один или много. Один и много могут появляться в трех различных комбинациях:
Один-к-одному (1:1) – один и только один экземпляр сущности связан с одним и только одним экземпляром другой сущности.
Один-ко-многим (1:N) – один и только один экземпляр родительской сущности связан со многими экземплярами подчиненной сущности.
Многие-ко-многим (M:N) – много экземпляров одной сущности связаны со многими экземплярами другой сущности (также называется неспецифическим отношением).
В отношении один-к-одному один и только один экземпляр сущности связан с одним и только одним экземпляром другой сущности. Это редкий случай отношения, следует рассмотреть возможность объединения двух отношений в одно. Но, например, в отношении сущностей Факультет и Сотрудник целесообразнее установить связь один-к-одному, чем заносить данные о декане в сущность Факультет.
В отношении один-ко-многим один и только один экземпляр родительской сущности связан со многими экземплярами дочерней сущности. Это наиболее распространенное отношение.
Отношение многие-ко-многим уже было рассмотрено.
В ERwin отношение изображается линией с точкой на конце "много".
Кроме общего случая мощности отношения 0, 1 или много можно задать частные случаи отношений: 1 или много (обозначается буквой p), 0 или 1 (обозначается буквой z), конкретное число экземпляров дочерней сущности (обозначается числом экземпляров, например, 6).
В ERwin реализована также методология IE (Information Engineering),
которая принципиально не отличается от методологии IDEF1X .
Правила ссылочной целостности
Целостность данных является понятием базы данных. ERwin позволяет в модели "сущность-связь" задать правила ссылочной целостности (возможно также задание ограничений на значения атрибутов, но мы не рас- сматриваем эту возможность). При генерации схемы базы данных ERwin ге- нерирует правила декларативной ссылочной целостности и триггеры. То есть, правила ссылочной целостности задаются в модели "сущность-связь", а реализуются в построенной по этой модели реляционной базе данных. Соот- ветствие между моделью и базой данных легко устанавливается, учитывая, что сущностям модели соответствуют отношения реляционной базы данных, а экземплярам сущностей – кортежи отношений.
Так как внешние ключи кортежей дочернего отношения служат ссылками на соответствующие кортежи родительского отношения, то эти ссылки не должны указывать на несуществующие кортежи. Это определяет следующее правило целостности внешних ключей (правило ссылочной целостности): для каждого значения внешнего ключа должно существовать соответствующее значение первичного ключа в родительском отношении.
Ссылочная целостность может нарушиться в результате операций с кортежами отношений. Таких операций три: вставка, обновление и удаление кортежей в отношениях. Рассмотрим эти операции для родительского и дочернего отношений.
При операциях с кортежами родительского отношения возможны следующие ситуации:
1. Вставка кортежа в родительское отношение. Так как допустимо существование кортежей родительского отношения, на которые нет ссылок
из дочерних отношений, то вставка кортежа в родительское отношение не нарушает ссылочной целостности.
2. Обновление кортежа родительского отношения. При обновлении
кортежа родительского отношения может измениться значение ключа. Если есть экземпляры дочернего отношения, ссылающиеся на обновляемый кортеж родительского отношения, то значения их внешних ключей станут не- корректными. Обновление кортежа в родительском отношении может привести к нарушению ссылочной целостности, если это обновление затрагивает значение ключа.
3. Удаление кортежа родительского отношения. При удалении кортежа родительского отношения удаляется значение ключа. Если есть кортежи дочернего отношения, ссылающиеся на удаляемый кортеж родительского отношения, то значения их внешних ключей станут некорректными. Удаление кортежа родительского отношения может привести к нарушению ссылочной целостности.
При операциях с кортежами дочернего отношения возможны следующие ситуации:
1. Вставка кортежа дочернего отношения может привести к нарушению ссылочной целостности, если вставляемое значение внешнего ключа некорректно.
2. Обновление кортежа дочернего отношения может привести к нарушению ссылочной целостности при некорректном изменении значения внешнего ключа.
3. При удалении кортежа дочернего отношения ссылочная целостность не нарушается.
Таким образом, ссылочная целостность в принципе может быть нарушена при выполнении одной из четырех операций:
1) обновление кортежа в родительском отношении;
2) удаление кортежа в родительском отношении;
3) вставка кортежа в дочернее отношение;
4) обновление кортежа в дочернем отношении.
Существуют две основные стратегии поддержания ссылочной целостности:
1) RESTRICT (ограничить) – не разрешать выполнение операции, приводящей к нарушению ссылочной целостности. Это самая простая стратегия, требующая только проверки, имеются ли кортежи дочернего отношения, связанные с некоторыми кортежами родительского отношения.
2) CASCADE (каскад) – разрешить выполнение требуемой операции, но внести при этом необходимые поправки в других кортежах отношений так, чтобы не допустить нарушения ссылочной целостности и сохранить все имеющиеся связи. Изменение начинается в родительском отношении и каскадно выполняется в дочернем отношении. Так как дочернее отношение может быть родительским для некоторого третьего отношения, то может потребоваться выполнение каскадной стратегии и для этой связи и т.д. Это самая сложная стратегия, но она хороша тем, что при этом не нарушается связь между кортежами родительского и дочернего отношений.
Эти стратегии являются стандартными и присутствуют во всех СУБД, в которых имеется поддержка ссылочной целостности.
ERwin реализует также дополнительные стратегии поддержания ссылочной целостности (если они реализованы в целевой СУБД):
1) NONE (никакой) – никаких операций по поддержке ссылочной целостности не выполняется. В этом случае в дочернем отношении могут появляться некорректные значения внешних ключей, и вся ответственность за целостность базы данных ложится на приложение.
2) SET NULL (установить в null) – разрешить выполнение требуемой операции, но все возникающие некорректные значения внешних ключей заменять на неопределенные значения (null-значения). При этом кортежи дочернего отношения теряют всякую связь с кортежами родительского отношения.
3) SET DEFAULT (установить по умолчанию) – разрешить выполнение требуемой операции, но все возникающие некорректные значения внешних ключей изменять на некоторое значение, принятое по умолчанию. При этом должен существовать кортеж родительского отношения, первичный ключ которого принят как значение по умолчанию для внешних ключей. Этот кортеж нельзя удалять из родительского отношения, и в этом кортеже нельзя изменять значение ключа. Кроме того, как и в предыдущем случае, кортежи дочернего отношения теряют всякую связь с кортежами родительского отношения.
Рассмотрим применение стратегии поддержания ссылочной целостности.
При обновлении кортежа в родительском отношении допустимы следующие стратегии:
1) RESTRICT – не разрешать обновление, если имеется хотя бы один кортеж дочернего отношения, ссылающийся на обновляемый кортеж родительского отношения.
2) CASCADE – выполнить обновление и каскадно изменить значения внешних ключей во всех кортежах дочернего отношения, ссылающихся на обновляемый кортеж.
3) SET NULL – выполнить обновление и во всех кортежах дочернего отношения, ссылающихся на обновляемый кортеж, изменить значения внешних ключей на null-значение
4) SET DEFAULT – выполнить обновление и во всех кортежах дочернего отношения, ссылающихся на обновляемый кортеж, изменить значения внешних ключей на некоторое значение, принятое по умолчанию.
5) NONE – выполнить обновление, не обращая внимания на нарушения ссылочной целостности.
При удалении кортежа в родительском отношении допустимы стратегии:
1) RESTRICT – не разрешать удаление, если имеется хотя бы один кортеж в дочернем отношении, ссылающийся на удаляемый кортеж.
2) CASCADE – выполнить удаление и каскадно удалить кортежи в дочернем отношении, ссылающиеся на удаляемый кортеж.
3) SET NULL – выполнить удаление и во всех кортежах дочернего отношения, ссылающихся на удаляемый кортеж, изменить значения внешних ключей на null-значение.
4) SET DEFAULT – выполнить удаление и во всех кортежах дочернего отношения, ссылающихся на удаляемый кортеж, изменить значения внешних ключей на некоторое значение, принятое по умолчанию.
5) NONE – выполнить удаление, не обращая внимания на нарушения ссылочной целостности.
При вставке кортежа в дочернее отношение возможны стратегии:
1) RESTRICT – не разрешать вставку, если внешний ключ во вставляемом кортеже не соответствует ни одному значению потенциального ключа родительского отношения.
2) SET NULL – вставить кортеж, но в качестве значения внешнего ключа занести не предлагаемое пользователем некорректное значение, а null-значение.
3) SET DEFAULT – вставить кортеж, но в качестве значения внешнего ключа занести не предлагаемое пользователем некорректное значение, а некоторое значение, принятое по умолчанию.
4) NONE – вставить кортеж, не обращая внимания на нарушения ссылочной целостности
При обновлении кортежа в дочернем отношении возможны стратегии:
1) RESTRICT – не разрешать обновление, если внешний ключ в обновляемом кортеже становится не соответствующим ни одному значению потенциального ключа родительского отношения.
2) SET NULL – обновить кортеж, но в качестве значения внешнего ключа занести не предлагаемое пользователем некорректное значение, а null-значение.
3) SET DEFAULT – обновить кортеж, но в качестве значения внешнего ключа занести не предлагаемое пользователем некорректное значение, а некоторое значение, принятое по умолчанию.
4) NONE – обновить кортеж, не обращая внимания на нарушения ссылочной целостности.
1. Создание логической модели данных
1.1. Начало работы с ERwin Запуск программы осуществляется через меню Пуск>Все програм- мы>CA>ERwin>ERwin Data Modeler r7.3>ERwin Data Modeler или через ярлык на рабочем столе.
При запуске ERwin открывается главное окно программы ERwin
Data Modeler (рисунок 1.1).
Рис. 1.1. Главное окно программы ERwin Data Modeler
Порядок построения модели данных в среде ERwin рассмотрим на примере автоматизированной информационной системы "Реализация средств вычислительной техники", предназначенной для учета продаж настольных компьютеров по заказам клиентов.
Создание новой модели начинается с выбора типа модели: логическая, физическая, логико-физическая. При проектировании базы данных целесообразнее выбирать логико-физическую модель.
Выбор типа новой модели осуществляется в диалоге Create Model
(рисунок 1.2), вызываемом через File>New или кнопку создания нового файла
. При выборе физической или логико-физической модели в диалоге Create Model необходимо также указать необходимую СУБД и номер ее версии (в полях Database и Version).

Рисунок 1.2. Диалог Create Model
Данный диалог позволяет также открыть существующую модель дан-
ных указанного типа посредством активизации кнопки .
В соответствии с выбранным действием при активизации кнопки ОК открывается окно для построения новой модели данных (рисунок 1.3) или окно редактирования модели, созданной раннее.

Рис. 1.3. Окно для построения новой модели данных
Подуровни логического уровня модели данных
Создание модели данных начинается с разработки логической модели, которая должна представлять состав сущностей предметной области с перечнем атрибутов и отношений между ними.
Если предварительно был выбран логико-физический уровень представления модели данных, то в списке выбора для переключения между логической и физической моделью (пункт Logical, расположенный на панели инструментов) автоматически будет выбрана логическая модель (рисунок 1.4).

Рисунок 1.4. Пункт Logical на панели инструментов
В противном случае тип модели необходимо выбрать из выпадающего меню данного пункта (рисунок 1.5).

Рисунок 1.5. Выпадающее меню пункта Logical
На логическом уровне ERwin поддерживает две нотации (IE и IDEF1X), на физическом уровне – три нотации (IE, IDEF1X и DM). По умол- чанию используется нотация IDEF1X (Integration DEFinition for information modeling).
Смену нотации можно сделать на вкладке Notation диалога Model Properties, вызываемого через меню Model>Model Properties (рисунок 1.6).
Для построения ER-модели используется панель инструментов, состав которой (условные графические обозначения) зависит от выбранного стан- дарта представления моделей и типа модели: логическая или физическая.
Поскольку стандарт IDEF1X используется по умолчанию, то на панели инструментов автоматически будут отображаться виды кнопок данного стан- дарта, описание которых приведено в таблице 1.


Рисунок 1.6. Смена нотации на вкладке Notation диалога Model Properties


Таблица 1. Палитра инструментов логического уровня
Вид кнопки Назначение кнопки
Указатель (режим мыши) – в этом режиме можно установить фокус на каком-либо объекте модели
Создание новой сущности – для создания сущности необходимо
щелкнуть левой кнопкой мыши по кнопке и один раз по свободному пространству на модели
Создание категории – для установления категориальной связи (спе-
циальный тип связи между сущностями) необходимо щелкнуть ле- вой кнопкой мыши по кнопке категории, затем один раз щелкнуть по родительской сущности и затем один раз по сущности-потомку
Создание идентифицирующей связи
Создание связи «многие ко многим»
Создание неидентифицирующей связи



В зависимости от глубины представления информации о данных различают 3 подуровня логического уровня модели данных:
−диаграмма сущность – связь (Entity Relationship Diagram, ERD);
−модель данных, основанная на ключах (Key Based model, KB);
−полная атрибутивная модель данных (Fully Attributed model, FA).
Диаграмма сущность-связь включает сущности и взаимосвязи, отражающие основные бизнес-правила предметной области.
Модель данных, основанная на ключах – более подробное представление данных. Данная модель включает описание всех сущностей и первичных ключей, необходимых для подробного описания предметной области.
Полная атрибутивная модель данных – наиболее детальное представление структуры данных предметной области. Данная модель представляет данные в третьей нормальной форме и включает все сущности, атрибуты и связи.
Создание сущностей и атрибутов
Построение логической модели данных предполагает определение сущностей и атрибутов, т. е. необходимо определить, какая информация будет храниться в конкретной сущности и в конкретном атрибуте. Сущность можно определить как объект, событие или концепцию, информация о которых должна сохраняться.
Например, сущность Клиент (но не Клиенты!) может иметь атрибуты Номер клиента, Фамилия клиента, Адрес клиента и Телефон клиента. На уровне физической модели данных данной сущности может соответствовать таблица (отношение) Client с колонками Client_number, Client_name, Client_address и Client_telephone.
Для внесения сущности в модель необходимо щелкнуть левой кнопкой
мыши по кнопке сущности , расположенной на панели инструментов, и затем щелкнуть один раз в поле проектирования модели на том месте, где необходимо расположить новую сущность. В результате в поле проектирования
появится сущность с именем E/1 по умолчанию (рисунок 1.7).

Рисунок 1.7. Размещение в поле проектирования сущности с именем E/1 по умолчанию
Определение имени сущности осуществляется через диалог Entities, который открывается через пункт Entity Properties (свойства сущности) контекстного меню по щелчку правой кнопкой мыши по выделенной сущности или пункта главного меню Model/Entities.
Диалог Entities (рисунок 1.8) содержит вкладки, которые позволяют назначить и редактировать свойства сущности: имя (Name), определение (Definition), объем (Volumetrics), примечания (Note, Note2, Note3), определяемые пользователем свойства (UDP – User definition properties), иконки (Icon), историю (History).

Рисунок 1.8. Диалог Entities
Вкладка Definition используется для ввода определения сущности в виде ее текстового описания. На логическом уровне определения позволяют четче понять объект, а на физическом уровне – их можно экспортировать как часть схемы и использовать в реальной базе данных.
Вкладка Volumetrics позволяет указать предполагаемое начальное и максимальное количество экземпляров сущности и возможное их увеличение.
Вкладки Note, Note2, Note3, UDP служат для внесения дополнительных комментариев и определений к сущности, в частности:
− вкладка Note позволяет добавлять дополнительные замечания о сущности, которые не были отражены в определении (Definition), например, описать бизнес – правило или соглашение по организации диаграммы;
− вкладка Note2 позволяет задокументировать некоторые возможные запросы, которые предполагается использовать по отношению к сущности в базе данных;
− вкладка Note3 позволяет в произвольной форме вводить примеры данных для сущности;
− вкладка UDP позволяет пользователю определить свойства сущности и объем хранимых данных.
Вкладка Icon позволяет каждой сущности поставить в соответствие изображение, которое будет отображаться в режиме просмотра модели на уровне иконок.
Вкладка History позволяет просмотреть историю всех изменений, связанных с сущностью и добавить комментарий к изменению в окне Comment.
По активизации кнопки ОК на поле проектирования отобразится сущность с заданным именем и определенными свойствами (рисунок 1.9).

Рисунок 1.9. Размещение в поле проектирования сущности с именем Клиент
При разработке ER-модели можно установить параметры шрифтов и цветовое оформление сущностей для облегчения обзора и понимания модели. При этом можно изменять установки параметров, назначенные по умолчанию, при добавлении нового объект на поле диаграммы, как для всех объектов диаграммы, так и для групп выделенных объектов или отдельных сущностей.
Параметры шрифта для названия сущности и цвет для заполнения поля блока редактируются с помощью пункта Object Font & Color контекстного меню (всплывающего меню по щелчку правой кнопкой мыши на поле выделенной сущности). Аналогичным образом изменяются параметры и для групп выделенных объектов диаграммы.
Определение атрибутов сущностей и их характеристик осуществля- ется в диалоговом окне Attributes, которое открывается с помощью пункта Attributes… контекстного меню и позволяет ввести данные об атрибутах выбранной сущности (рисунок 1.10).

Рисунок 1.10. Диалоговое окно Attributes
При активизации кнопки New… диалогового окна Attributes открывается диалог New Attribute, позволяющий добавить новый атрибут для выделенной сущности (рисунок 1.11).

Рисунок 1.11. Диалоговое окно New Attribute
В диалоговом окне New Attribute указывается имя нового атрибута (поле Attribute Name), имя, соответствующее ему в физической модели колонки (поле Column Name) и домен (тип колонки на уровне физической модели).
Имена атрибутов можно задавать с помощью шрифтов типа "Кириллица" или "Латиница". При этом следует учитывать возможности СУБД, которые будут использоваться для сопровождения базы данных. Например, при использовании СУБД типа Access можно использовать имена сущностей и атрибутов для физической модели данных на русском языке (рисунок 1.12).

Рисунок 1.12. Определение нового атрибута для сущности Клиент
Атрибуты должны именоваться в единственном числе и иметь четкое смысловое значение, что позволяет частично решить проблему нормализации данных на этапе определения атрибутов. Например, создание для сущности Клиент атрибута Телефоны клиента противоречит требованиям нормализации, т. к. атрибут должен быть атомарным, т.е. не содержать множественных значений.
Согласно синтаксису нотации IDEF1X имя атрибута должно быть уникально в рамках модели, поэтому новый атрибут, в случае совпадения его имени с уже существующим в рамках модели, должен быть переименован.
При активизации кнопки ОК новый атрибут добавляется в список атрибутов выделенной сущности, отражающийся в поле Attribute диалогового окна Attributes (рисунок 1.13).
Для определения первичного ключа выделенной сущности необходимо перейти на вкладку General и сделать пометку в окне выбора Primary Key (рисунок 1.14).

Рисунок 1.13. Атрибуты сущности Клиент

Рисунок 1.14. Определение первичного ключа в окне выбора Primary Key
Вкладка Datatype позволяет с помощью выпадающего списка на странице уточнить тип данных для выделенного атрибута (рис. 1.15).
Вкладка Constraint позволяет задать ограничения для выделенного атрибута.
Вкладка Definition позволяет записать определения отдельных атрибутов.
Вкладка Note позволяет добавлять замечания об одном или нескольких атрибутах сущности, которые не вошли в определения.
Вкладка UDP предназначена для задания значений свойств, определяемых пользователем.

Рисунок 1.15. Уточнение типа данных атрибута Адрес клиента
Вкладка Key Group (рисунок 1.16) предназначена для отображения атрибутов, входящих в группу ключевых атрибутов сущности. В частности, на вкладке показано, что первичным ключом сущности Клиент является атрибут Номер клиента.

Рисунок 1.16. Вкладка Key Group диалога Attributes
Сущность может иметь несколько возможных (потенциальных) ключей. Один потенциальный ключ объявляется первичным, а остальные могут быть объявлены альтернативными ключами (Alternate Key). ERwin по умолчанию на физическом уровне генерирует уникальные индексы по первичному и альтернативным ключам. ERwin позволяет также строить неуникальные индексы по атрибутам, называемым инверсными входами (Inver- sion Entries). Неуникальный индекс обеспечивает быстрый доступ не к одной строке таблицы, а к нескольким, имеющим одинаковое значение инверсного входа. Это ускоряет доступ к данным.
Альтернативные ключи и инверсные входы создаются в диалоге Key Groups, который появляется после выбора соответствующего пункта контекстного меню (рисунок 1.17).

Риунок 1.17. Диалог Key Groups

Как видно на рисунке 1.17, что имеется первичный ключ (PK), включающий атрибут Номер клиента. Создадим инверсный вход по атрибуту Фамилия клиента. Для этого выделяем атрибут Фамилия клиента и нажимаем на кнопку New. Появляется диалог New Key Group (рисунок 1.18).
Рисунок 1.18. Диалог New Key Group
В этом диалоге выбираем Inversion Entry. Имя ключевой группы (Key Group) и индекса (Index) присваиваются автоматически. Щелкаем по кнопке OK и возвращаемся в диалог Key Groups (рисунок 1.19).

Рисунок 1.19. Диалог Key Groups при построении инверсного входа
В верхнем окне Key Group вкладки выбираем ключевую группу XIE1Клиент, являющуюся инверсным входом (IE). В окне Available Attributes выбираем атрибут Фамилия клиента и с помощью кнопки включаем его в состав ключевой группы.
Альтернативные ключи создаются аналогично.
Вкладка History диалога Attributes отображает историю создания и изменения свойств атрибута и позволяет добавить комментарии к изменению в окне Comment (рисунок 1.20).
При нажатии на кнопку ОК в поле проектирования модели отобразится сущность с атрибутами, определенными пользователем (рисунок 1.21).

Рисунок 1.20. История создания и изменения свойств атрибута Фамилия клиента

Рисунок 1.21. Сущность Клиент с заданными атрибутами
Диалоговое окно Attributes позволяет пользователю редактировать имена атрибутов выделенной сущности и корректировать список атрибутов путем выполнения операции удаления ошибочно определенного атрибута.
Редактирование имени атрибута осуществляется в диалоге Rename Attribute, который открывается при активизации кнопки диалогового окна Attributes (рисунок 1.22).

Рисунок 1.22. Редактирование имени атрибута Фамилия клиента
При активизации кнопки диалогового окна Attributes пользователю предоставляется возможность удаления выделенного атрибута из списка атрибутов. При этом необходимо внимательно относиться к данному действию, т.к. ERwin не требует подтверждения удаления атрибута.
Для описания свойств сущности часто приходится создавать производные атрибуты, т.е. атрибуты, значение которых можно вычислить из других атрибутов. Примером производного атрибута может служить атрибут Сумма заказа, значение которого может быть вычислено из атрибутов Количе- ство заказанного товара и Цена за единицу товара.
Многие производные атрибуты часто приводят к конфликтам. Например, значение производного атрибута Возраст сотрудника может быть вычислено из атрибута Дата рождения сотрудника. Возникновение конфликтной ситуации здесь возможно в случае несвоевременного обновления значения атрибута Возраст сотрудника, что приводит к противоре- чию значению атрибута Дата рождения сотрудника.
Производные атрибуты – ошибка нормализации. Нарушение синтаксиса нормализации допустимо в случаях необходимости повышения производительности системы. Например, хранение Итоговой суммы заказа позволяет повысить производительности системы при формировании документов на оплату заказа за счет непосредственного обращения к соответствующему атрибуту и исключения проведения предварительных вычислений, которые могут быть достаточно сложными, особенно при использовании специальных методик расчета с введением коэффициентов различного назначения.
ERwin позволяет переносить атрибуты внутри и между сущностями. Для этого необходимо щелкнуть правой кнопкой мыши по атрибуту. При этом указатель приобретает вид кисти руки, после чего можно перетащить выделенный атрибут на новое местоположение внутри сущности или в поле другой сущности диаграммы.
Для описания объектов предметной области по реализации настольных компьютеров по заказам клиентов выделены следующие сущности: Тип компьютера, Компьютер, Клиент, Заказ, Продажа, Менед- жер, Отдел (рисунок 1.23).

Рисунок 1.23. Сущности, выделенные для описания объектов предметной области
Создание связей
Логическим соотношением между сущностями является связь. Каждому виду связи соответствует определенная кнопка, расположенная на палитре инструментов. Имя связи выражает некоторое ограничение или бизнес-правило и облегчает чтение диаграммы. Каждая связь должна именоваться глаголом или глагольной фразой. Например, связь между сущностями Компьютер, Продажа и Менеджер показывает (рисунок 1.24), какой компьютер продан и какой менеджер оформил сделку продажи компьютера:
− каждый Компьютер < продается > Продажа;
− каждая Продажа < оформляет > Менеджер.

Рисунок 1.24. Связь между сущностями Компьютер, Продажа и Менеджер
В нотации IDEF1X различают зависимые и независимые сущности. Тип сущности определяется ее связью с другими сущностями. Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями и показывается на диаграмме сплошной линией с жирной точкой на дочернем конце связи. При установлении идентифицирующей связи ERwin автоматически преобразует дочернюю сущность в зависимую сущность. Зависимая сущность на диаграмме изображается прямоугольником со скругленными углами, например, сущность Продажа. Экземпляр зависимой сущности определяется только через отношение к родительской сущности. Например, информация о продаже не может быть внесена и не имеет смысла без информации о проданном компьютере. При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности автоматически переносятся в состав первичного ключа дочерней сущности. Операция дополнения атрибутов дочерней сущности при создании связи называется миграцией атрибутов. В дочерней сущности новые (мигрированные) атрибуты помечаются как внешний ключ (FK). В случае идентифицирующей связи при генерации схемы базы данных атрибутам внешнего ключа присваивается признак NOT NULL, что означает невозможность внесения записи в таблицу, соответствующей дочерней сущности, без идентификационной информации из таблицы, соответствующей родительской сущности. Например, невозможность внесения записи в таблицу продаж без информации об идентификационном номере проданного компьютера, определенного в таблице описания имеющихся в наличии компьютеров.
Неидентифицирующая связь показывается на диаграмме пунктирной линией с жирной точкой и служит для установления связи между независимыми сущностями. При установлении неидентифицирующей связи дочерняя сущность остается независимой, а атрибуты первичного ключа мигрируют в состав неключевых атрибутов родительской сущности (рисунок 1.25).

Рисунок 1.25. Пример неидентифицирующей связи между независимыми сущностями Менеджер и Отдел
Для создания новой связи необходимо:
− установить курсор на кнопке, расположенной на палитре инструментов и соответствующей требуемому виду связи (см. таблица.1), и нажать левую кнопку мыши;
− щелкнуть левой кнопкой мыши сначала по родительской, а затем по дочерней сущности.
Изменить форму линии связи и ее местоположение между связанными сущностями можно путем захвата мышью выделенной линии связи и переноса ее с места на место, пока линия не примет необходимые местоположение и форму.
Редактирование свойств связи осуществляется в диалоговом окне Relationship, которое открывается через пункт Relationship Properties контекстного меню, активизируемого посредством нажатия правой кнопки мыши на выделенной связи (рисунок 1.26).
Вкладка General диалогового окна Relationship позволяет задать мощность, имя и тип связи.
Мощность связи (Cardinality) служит для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней сущности. Различают 4 типа мощности связи (рисунок 1.27):
− общий случай – не помечается каким-либо символом и соответствует ситуации, когда одному экземпляру родительской сущности соответствуют 0,1 или много экземпляров дочерней сущности;
− символом Р помечается случай, когда одному экземпляру родительской сущности соответствуют 1 или много экземпляров дочерней сущности, т.е. исключено нулевое значение;
− символом Z помечается случай, когда одному экземпляру родительской сущности соответствуют 0 или 1 экземпляр дочерней сущности, т.е. исключены множественные значения;
− цифрой помечается случай точного соответствия, когда одному экземпляру родительской сущности соответствует заранее заданное число экземпляров дочерней сущности.

Рисунок 1.26. Диалоговое окно Relationship
–0,1 или много
P
–1 или много
Z
–0 или 1
5
–точно N = 5
Рисунок 1.27. Обозначение мощности связей
По умолчанию символ, обозначающий мощность связи, не показывается на диаграмме. Для отображения мощности связи следует включить опцию Cardinality пункта Relationship Display контекстного меню, которое появляется по щелчку правой кнопкой мыши по любому месту диаграммы, не занятому объектами модели.
Имя связи (Verb Phrase) – фраза, характеризующая отношение между родительской и дочерней сущностями. Для связи "один ко многим" (идентифицирующей или неидентифицирующей) достаточно указать имя, характеризующее отношение от родительской к дочерней сущности (Parent-to-Child), а для связи "многие ко многим" необходимо указывать имя связи как от родительской к дочерней сущности (Parent-to-Child), так и от дочерней к родительской сущности (Child-to-Parent).
Пример определения мощности и имени связи между сущностями Отдел и Менеджер приведен на рисунок 1.28.

Рисунок 1.28. Пример определения мощности и имени связи между сущностями
Тип связи (Relatioпships Type) позволяет обозначить идентифицирующую (Identifying) или неидентифицирующую (Non-Identifying) связь. Для не- идентифицирующей связи необходимо указать обязательность связи (Nulls Allowed или No Nulls). В случае обязательной связи (No Nulls), несмотря на то, что внешний ключ не войдет в состав первичного ключа дочерней сущности, при генерации схемы базы данных атрибут внешнего ключа получит признак NOT NULL. В случае необязательной связи (Nulls Allowed) внешний ключ может принимать значение NULL. Это означает, что экземпляр дочерней сущности не будет связан ни с одним экземпляром родительской сущности. Необязательная неидентифицирующая связь помечается прозрачным ромбом со стороны родительской сущности (рисунок 1.29).

Рисунок 1.29. Графическое представление необязательной неидентифицирующей связи

Например, при оформлении сделки по продаже компьютера информация о покупателе (клиенте) не всегда участвует в оформлении расходных документов (рисунок 1.30).
Рисунок 1.30. Пример реализации необязательной неидентифицирующей связи
Вкладка Definition позволяет дать более полное определение связи для того, чтобы в дальнейшем иметь возможность на него ссылаться.
Вкладка Rolename открывает окно диалога Relationships, которое позволяет задать имя роли атрибута внешнего ключа (рисунок 1.31).

Рисунок 1.31. Окно диалога Relationships вкладки Rolename
Имя роли (Rolename, функциональное имя) – это синоним атрибута внешнего ключа, который показывает, какую роль играет атрибут в дочерней сущности. Например, в сущности Менеджер внешний ключ Номер отдела имеет функциональное имя "Где работает", которое показывает, какую роль играет этот атрибут в данной сущности. По умолчанию в списке атрибутов показывается только имя роли. Для отображения полного имени атрибута (как функционального имени, так и имени роли необходимо включить опцию Rolename/Attribute пункта Entity Display контекстного меню, которое появляется по щелчку правой кнопки мыши по любому месту диаграммы, не занятому объектами модели. В результате отобразится Полное имя атрибута, включающее функциональное имя и базовое имя, разделенные между собой точкой (рисунок 1.32).

Рисунок 1.32. Пример Полного имени внешнего атрибута Номер отдела сущности Менеджер
Обязательным является применение имен ролей в том случае, когда два или более атрибута одной сущности определены по одной и той же области, т. е. они имеют одинаковую область значений, но разный смысл. Другим примером обязательности присвоения имен ролей являются рекурсивные связи (иногда их называют "рыболовным крючком" – fish hook), когда одна и та же сущность является и родительской и дочерней одновременно. При задании рекурсивной связи атрибут мигрирует в качестве внешнего ключа в состав неключевых атрибутов той же сущности. Атрибут не может появиться дважды в одной сущности под одним именем, поэтому обязательно должен получить имя роли. Например, сущность Менеджер содержит атрибут первичного ключа Табельный номер. Информация о старшем менеджере (руководителе) содержится в той же сущности, поскольку старший менеджер работает в этой же организации. Чтобы сослаться на старшего менеджера, необходимо создать рекурсивную связь руководит/подчиняется и присвоить имени роли значение старший (рисунок 1.33). Рекурсивная связь может быть только необязательной неидентифицирующей. В противном случае внешний ключ должен был бы войти в состав первичного ключа и получить при генерации схемы признак NOT NULL, что делает невозможным построение иерархии – у дерева подчиненности должен быть корень – менеджер, который никому не подчиняется в рамках данной организации.
Связь руководит/подчиняется позволяет хранить древовидную иерархию подчиненности сотрудников. Такой вид рекурсивной связи называется иерархической рекурсией (hierarchical recursion) и задает связь, когда руководитель (экземпляр родительской сущности) может иметь множество подчиненных (экземпляров дочерней сущности), но подчиненный имеет только одного руководителя.

Рисунок 1.33. Пример рекурсивной связи
Другим видом рекурсии является сетевая рекурсия (network recursion), когда руководитель может иметь множество подчиненных и, наоборот, подчиненный может иметь множество руководителей. Сетевая рекурсия задает паутину отношений между экземплярами родительской и дочерней сущностей. Это случай, когда сущность находится сама с собой в связи "многие-ко- многим". Для разрешения связи "многие-ко-многим" необходимо создать дополнительную сущность (подробнее связь "многие-ко-многим" рассматривается ниже).
Правила ссылочной целостности (referential integrity (RI)) – логические конструкции, которые выражают бизнес – правила использования данных и представляют собой правила вставки, замены и удаления. Определение правилссылочной целостности осуществляется с помощью вкладки RI Actions контекстного меню Relationships (рисунок 1.34). Заданные на вкладке RI Actions опции логической модели используются при генерации схемы базы данных для определения правил декларативной ссылочной целостности, которые предписываются для каждой связи, и триггеров, обеспечивающих ссылочную целостность.
На рисунке 1.34 показан пример установленных по умолчанию правил ссы- лочной целостности для неидентифицирующей связи между сущностями Отдел и Менеджер. На удаление экземпляра родительской сущности (Parent Delete) устанавливается ограничение RESTRICT. Это означает, что экземпляр родительской сущности нельзя удалить, если с ней связан экземпляр дочерней. С экземпляром родительской сущности может быть не связан ни один экземпляр дочерней сущности. Поэтому при вставке экземпляра родительской сущности (Parent Insert) не проводится никакой проверки (ограничение NONE). При изменении ключевых атрибутов родительской сущности (Parent Update) нарушится связь с дочерними сущностями, так как внешний ключ дочерних сущностей не равен ключу родительской сущности. Поэтому по умолчанию такое изменение запрещено (ограни- чение RESTRICT). Отметим, что в данном случае можно применить ограничение CASCADE, приводящее к изменению внешних ключей дочерних сущностей при изменении ключа родительской сущности. При удалении экземпляра дочерней сущности (Child Delete) ссылочная целостность не нарушается, поэтому по умолчанию применено ограничение NONE. Если при вставке экземпляра дочерней сущности (Child Insert) ее внешний ключ будет отличаться от ключа родительской сущности, то нарушится ссылочная целостность. Такая ситуация проверяется ограничением RESTRICT. Аналогично, ограничение RESTRICT не допускает присвоения внешнему ключу дочерней сущности значения, отличного от значения родительского ключа (Child Update).

Рисунок 1.34. Окно диалога Relationships вкладки RI Actions
ERwin автоматически присваивает каждой связи значение ссылочной целостности, устанавливаемой по умолчанию, прежде чем добавить ее в диаграмму. Режимы RI, присваиваемые ERwin по умолчанию, могут быть изменены на вкладке RI Defaults редактора Model Properties (меню Model/Мodel Properties). Правила ссылочной целостности можно изменить на вкладке RI Actions диалогового окна Relationships.
Правила ссылочной целостности реализуются специальными программами – триггерами, хранящимися в базе данных и выполняемыми всякий раз при выполнении команд вставки, замены или удаления (INSERT, UPDATE или DELETE). На логическом уровне ERwin создает шаблоны триггеров, построенные с использованием специальных макрокоманд. Шаблоны триггеров и расширенный код, зависящий от выбранной СУБД, можно увидеть на вкладке Relationships Templates контекстного меню Relationships. Подробнее о создании триггеров можно узнать в и системе помощи ERwin.
Связь "многие-ко-многим" может быть создана только на уровне логической модели. Такая связь обозначается сплошной линией с двумя точками на концах. Установление связи "многие-ко-многим" осуществляется при активизации соответствующей кнопки на палитре инструментов посредством щелчка левой кнопки мыши сначала по одной, а затем по другой сущности.
С целью облегчения чтения диаграммы связь "многие-ко-многим"должна иметь двунаправленное имя: от родительской к дочерней сущности (Parent-to-Child) и от дочерней к родительской сущности (Child-to-Parent).
Примером связи "многие-ко-многим" может служить связь между сущностями Компьютер и Клиент (рисунок 1.35), т.к. один тот же вид компьютера может быть заказан многими клиентами (покупателями), а один и тот же клиент организации может заказать разные виды компьютеров:
− Компьютер < заказывается > Клиент;
− Клиент < заказывает > Компьютер.

Рисунок 1.35. Пример реализации связи "многие-ко-многим"
Нотация IDEF1X требует, чтобы на физическом уровне связь "многие- ко-многим" была преобразована, так как СУБД не поддерживают связь "многие- ко-многим". По умолчанию при переходе к физическому уровню ERwin автоматически не преобразует связь "многие-ко-многим". В этом случае на физическом уровне диаграмма выглядит так же, как и на логическом, однако при генерации схемы базы данных системы такая связь игнорируется. Поэтому уже на логическом уровне предпочтительно таких связей избегать. Кроме того, этого требует и синтаксис нормализации до третьей нормальной формы.
ERwin позволяет реализовать принудительное преобразование связи "многие-ко-многим", которое включает создание новой (связывающей) таблицы и двух новых связей "один-ко-многим" от старых таблиц к новой таблице. При этом имя новой таблице может присваиваться как автоматически, так и определяться пользователем. В случае автоматического присвоения имени связывающей таблице назначается имя, включающее имена обеих сущностей. Например, в случае автоматического разрыва связи "многие-ко- многим" между сущностями Компьютер и Клиент связывающая таблица получит имя КомпьютерКлиент.
Для осуществления принудительного преобразования связи "многие-ко-многим" необходимо выбрать пункт контекстного меню Create Association Entity. В результате откроется диалог Many-To-Many Transform Wizard (рисунок 1.36).

Рисунок 1.36. Окно диалога Many-To-Many Transform Wizard
Диалог Many-To-Many Transform Wizard предлагает выполнить четыре шага для преобразования связи. Для перехода к следующему шагу необходимо щелкнуть по кнопке Далее. На втором и третьем шаге следует задать имя вновь создаваемой таблицы и имя преобразования. По окончании выполнения действий диалога Many-To-Many Transform Wizard на диаграмме будет добавлена новая таблица с заданным пользователем именем, а связь "многие-ко-многим" заменится идентифицирующими связями "один-ко-многим" от старых таблиц к новой таблице. При этом новые связи автоматически получат соответствующие имена от связи "многие-ко- многим".
Пример результата принудительного преобразования связи "многие-ко-многим" между сущностями Компьютер и Клиент, реализованного с помощью диалога Many-To-Many Transform Wizard, приведен на рисунке 1.37.
Принудительного решения проблемы связи "многие-ко-многим" невсегда оказывается достаточно. Часто для описания сущности согласно бизнес – логике требуется добавление дополнительных атрибутов, позволяющих идентифицировать новую сущность. Например, для описания сущности Заказ необходимо добавить такие атрибуты, как Дата заказа, Дата исполнения заказа и Сумма заказа.

Рисунок 1.37. Пример результата принудительного преобразования связи "многие ко многим"
Особым типом объединения сущностей является иерархия наследования (иерархия категорий или категориальная связь), согласно которой разделяются их общие характеристики. Обычно иерархию наследования создают, когда несколько сущностей имеют общие по смыслу атрибуты, или когда сущности имеют общие по смыслу связи, или когда это диктуется бизнес – правилами. Чтобы представить информацию, общую для всех типов экземпляров сущности, из их общих свойств можно сформировать обобщенную сущность (родовой предок). При этом специфическая для каждого типа экземпляра сущности информация будет располагаться в категориальных сущностях (потомках).
Например, в организации работают менеджеры и консультанты, которые имеют сходную по смыслу связь "работает в" с сущностью Отдел. Чтобы представить информацию, общую для всех типов служащих, из их общих свойств можно сформировать обобщенную сущность Сотрудник. При этом категориальными сущностями будут являться Менеджер и Консультант (рисунок 1.38).

Рисунок 1.38. Пример иерархии наследования (категориальной связи)
Для создания категориальной связи следует:
установить курсор на кнопке , расположенной на палитре инструментов и нажать левую кнопку мыши;
щелкнуть сначала по родовому предку, а затем – по потомку;
установить вторую связь в иерархии категории, выбрав кнопку и щелкнув сначала по символу категории на диаграмме, затем – по второму потомку.
Редактирование категорий осуществляется в диалоговом окне Sub- type Properties, которое открывается при выборе пункта Subtype Properties… контекстного меню, отображаемого по щелчку правой кнопкой мыши по символу категории (рисунок 1.39). Поля диалогового окна позволяют указать дискриминатор – атрибут категории (список Discrimina- tor) и тип категории – полная/неполная (радиокнопки Complete/Incomplete).

Рисунок 1.39. Диалоговое окно Subtype Properties
Дискриминатор категории – это атрибут родового предка, который показывает, как отличить одну категориальную сущность от другой.
Иерархии категорий делятся на два типа – полные и неполные. В полной категории одному экземпляру родового предка обязательно соответствует экземпляр в каком-либо потомке. Например, сотрудник обязательно является либо менеджером, либо консультантом. Если категория еще не выстроена полностью и в родовом предке могут существовать экземпляры, которые не имеют соответствующих экземпляров в потомках, то такая категория будет неполной. Например, сотрудник может быть не только менеджером или консультантом, но и совместителем. В случае неполной категории сущность Совместитель еще не внесена в иерархию наследования. На рисунке 1.40 представлен пример полной категории.
Результат разработки логической модели данных системы "Реализация средств вычислительной техники", предназначенной для учета продаж настольных компьютеров по заказам клиентов приведен на рисунке 1.40.

Рисунок 1.40. Логическая модель данных системы
"Реализация средств вычислительной техники"
Логический уровень модели данных является универсальным и никак не связан с конкретной реализацией СУБД. Одному и тому же логическому уровню модели могут соответствовать несколько разных физических уровней различных моделей, где описывается вся информация о конкретных физических объектах: таблицах, колонках, индексах, процедурах и т.д. При этом физические модели данных могут соответствовать СУБД разных производителей, например, Oracle, MS SQL Server, MySQL, SYBASE, Informix, MS Access, Progress и т.д. Возможность синхронизации логического уровня модели с несколькими моделями, имеющими разный физический уровень, позволяет повысить эффективность разработки гетерогенных информационных систем.
Созданная логическая модель данных системы является основанием для создания физической модели данных под выбранную СУБД.
2 Создание физической модели данных
2.1. Выбор физического уровня представления модели данных
Создание физической модели является вторым шагом построения модели данных системы. ERwin позволяет построить физическую модель как независимую, так и зависимую от логического уровня представления модели данных.
Построение физической модели, независимой от логического уровня представления модели данных, начинается с активизации диалога Create Model (рисунок 1.2) через пункты основного меню File>New или кнопку нового файла , при этом в окне выбора нового типа модели New Model Type (рисунок 2.1) следует выбрать физический уровень представления (радиокнопка Physical).

Рисунок 2.1. Окно выбора нового типа модели New Model Type
Физический уровень представления модели зависит от конкретной реализации СУБД, поэтому необходимо предварительно осуществить ее выбор. CA ERwin Data Modeler 7.3 поддерживает 17 наиболее распространенных СУБД. Выбор СУБД осуществляется в окне Target Database диалога Create Model. Для выбора СУБД необходимо открыть выпадающий спи- сок с перечнем поддерживаемых СУБД и щелкнуть по соответствующему имени. При этом в поле Version отобразится версия выбранной СУБД (рисунок 2.2)

Рисунок 2.2. Окно выбора СУБД Target Database
При активизации кнопки ОК диалога Create Model откроется поле для построения физической модели данных.
При выборе логико-физической модели для проектирования базы данных преобразование логической модели в физическую модель осуществляется автоматически по переходу к пункту Physical в списке выбора для переключения между логической и физической моделью, расположенном на панелиинструментов (рисунок 2.3).

Рисунок 2.3. Переход к физической модели через пункт Physical панели инструментов
В случае автоматического перехода к физической модели ERwin генерирует имена таблиц и колонок по умолчанию на основе имен соответствующих сущностей и атрибутов логической модели, учитывая максимальную длину имени и другие синтаксические ограничения, накладываемые выбранной СУБД. При этом правила ссылочной целостности, принятые на логическом уровне модели данных системы, также принимаются по умолчанию, т.е. сохраняются (рисунок 2.4).

Рисунок 2.4. Физический уровень логико-физической модели данных
При генерации имени таблицы или колонки по умолчанию ERwin по возможности (частично) преобразовывает их названия в соответствии с англоязычным представлением. При реализации базы данных с помощью СУБД Access допускается сохранять названия таблиц и колонок на русском языке.
2.2. Добавление/редактирование таблиц
Для построения/редактирования ER-модели физического уровня используется панель инструментов, содержащая кнопки редактирования модели, условные графические обозначения которых приведены в таблице 2.
Таблица 2. Палитра инструментов физического уровня
Вид кнопки Назначение кнопки
Указатель (режим мыши) – в этом режиме можно установить фокус на каком-либо объекте модели

Создание новой таблицы – для создания таблицы необходимо щелкнуть левой кнопкой мыши по кнопке и один раз по свободному пространству на модели

Создание нового представления (view table) – для создания представления необходимо щелкнуть левой кнопкой мыши по кнопке и один раз по свободному пространству на модели
Создание идентифицирующей связи
Создание связи между представлением и временной таблицей
Создание неидентифицирующей связи



Для внесения новой таблицы в модель на физическом уровне необхо- димо щелкнуть по кнопке , расположенной на палитре инструментов, а за- тем на поле проектирования модели в том месте, где необходимо располо- жить новую таблицу. В результате в поле проектирования будет размещена таблица с именем по умолчанию E/1.
Определение/редактированиеименитаблицыосуществляетсячерез вкладку General пункта Table Properties (свойства таблицы) контекстного меню, отображаемого по щелчку правой кнопкой мыши по выделенной сущности (рисунки 2.5, 2.6), или пункт главного меню Model/Tables….
При этом открывается диалог Tables, отражающий имя выбранной для реализации СУБД. Например, при выборе для реализации СУБД Access диалог Tables будет называться Access Tables (рисунок 2.7).

Рисунок 2.5. Контекстное меню добавленной таблицы

Рисунок 2.6. Контекстное меню таблицы Клиент

Рисунок 2.7. Диалог Access Tables
Диалог Tables (в нашем случае Access Tables) позволяет переключаться с одной таблицы на другую и задать свойства любой таблицы модели, отличные от значения по умолчанию.
Переключиться на другую таблицу можно при помощи раскрывающегося списка выбора таблиц для редактирования окна Table, расположенного в верхней части диалога (рисунок 2.8).

Рисунок 2.8. Список выбора таблиц для редактирования окна Table
Окно Name служит для задания/изменения имени текущей таблицы. Окно Owner позволяет внести/изменить имя владельца таблицы, отличное от имени пользователя, производящего генерацию логической модели базы данных. Окно выбора Physical Only предназначено для создания объектов только на физическом уровне. Выбор опции Generate позволяет сгенерировать логическую модель базы данных путем выполнения команды CREATE TABLE (создать таблицу). Кнопка DB Sync предназначена для синхронизации модели с системным каталогом базы данных (рисунок 2.9).
Диалог Tables содержит следующие вкладки:
−Comment – для внесения комментария к таблице (рисунок 2.9);
−Volumetrics –для оценки размера БД;
−UDP –для задания свойств, определяемых пользователем;
−Validation –для задания правил валидации;
−History – отображает историю создания и изменения свойств таблицы и позволяет добавить комментарии к изменению в окне Comment (рисунок 2.10).

Рисунок 2.9. Изменение имени и внесение имени владельца таблицы Клиент

Рисунок 2.10. История создания и изменения свойств таблицы Клиент
Таблицы физической модели данных определяются в соответствии с семантическим анализом предметной области. При этом каждому объекту (сущности) предметной области ставится в соответствие таблица, характеристикам объекта (атрибутам) соответствуют колонки (поля) таблицы, а иден- тификатору объекта соответствует ключ (ключевое поле) таблицы.
2.3. Определение свойств колонок таблицы
Задание/редактирование свойств колонок таблицы осуществляется с помощью редактора диалогового окна Columns, которое открывается через пункт Columns контекстного меню выделенной таблицы или пункт главного меню Model/Columns…. При этом редактор предлагает установить типы данных согласно выбранной СУБД (рисунок 2.11).

Рисунок 2.11. Диалоговое окно Columns
По умолчанию ERwin присваивает пустые значения (NULL) всем неключевым колонкам, а для колонок первичного ключа и альтернативных ключей устанавливает режим NOT NULL. Режим NOT NULL не присваивается автоматически инверсным входам (Inversion Entry).
Диалоговое окно Columns по своему внешнему виду напоминает диалоговое окно редактора свойств атрибутов Attributes (рисунок 1.10) и содержит окна и вкладки, позволяющие добавлять, редактировать и удалять колонки выделенной таблицы.
Вкладка General позволяет присвоить колонку определенному домену, создать колонку только на физическом уровне и включить ее в состав первичного ключа (рисунок 2.12).
Вкладка, соответствующая выбранной СУБД, называется по имени СУБД и позволяет задать тип данных, опцию NULL и значение по умолчанию (рисунок 2.11). Имя вкладки устанавливается автоматически и соответствует названию выбранной для реализации СУБД. Например, при выборе для реа- лизации базы данных системы СУБД Access вкладка будет называться Access. Для СУБД Access, PROGRESS и Teradata создается дополнительная вкладка для задания свойств колонки (рисунок 1.13).

Рисунок 2.12. Вкладка General

Рисунок 2.13. Вкладка … Access
Вкладка Constraint позволяет задать имена и значения ограничений, накладываемых на поле указанной колонки таблицы, включая и значение, которое присваивается в окне Default автоматически, т.е. по умолчанию (рисунок 2.14).

Рисунок 2.14. Вкладка Constraint
Значение по умолчанию – значение, которое нужно ввести в колонку, если никакое другое значение не задано явным образом во время ввода данных. Для создания нового значения ограничения по умолчанию необходимо перейти по кнопке поля Default в диалоговое окно Default/Initial Values, по активизации кнопки New открыть диалог New Default Value, ввести в поле Name имя правила и щелкнуть по кнопке ОК (рисунок 2.15).

Рисунок 2.15. Создания нового значения ограничения по умолчанию
Список всех заданных имен значений по умолчанию отображается в поле Default Name диалогового окна Default/Initial Values. Для удаления и переименования значений по умолчанию используют соответственно кнопки Delete и Rename.
Вкладка Comment предназначена для внесения комментария к каждой колонке. Вкладка UDP позволяет задать свойства, определяемые пользователем. Вкладка Index служит для включения колонки в состав индексов. Вкладка History отображает историю создания и изменения свойств колонки и позволяет добавить комментарии к изменению в окне Comment (рисунок 2.16).

Рисунок 2.16. Вкладка History
Упорядоченный список колонок таблицы отображается в поле Column, расположенный в левой части диалогового окна Columns. Для перемещения колонок в списке на позицию вверх или вниз используют соответственно кнопки и .
Кнопки New, Rename и Delete служат соответственно для создания, переименования и удаления колонки. При помощи кнопки Reset можно переустановить свойства колонки, заданные вручную, на значения по умолчанию. Кнопка DB Sync позволяет запустить процесс синхронизации модели с системным каталогом БД.
Связи между таблицами физической модели создаются так же, как и при создании логического уровня модели данных. При создании связи колонки первичного ключа родительской таблицы мигрируют в состав колонок дочерней таблицы в качестве внешнего ключа.
Изменения, внесенные в имена таблиц и колонок физической модели, не отражаются на именах сущностей и атрибутов, поскольку информация на логическом и физическом уровнях в ERwin хранится отдельно.
Индексы
Индекс – это особый объект, позволяющий решить проблему поиска данных в таблице БД.
Создание нового уникального индекса осуществляется через диалог New Index, открывающийся по активизации кнопки New…, при включенной опции Unique (рисунок 2.18). Уникальные индексы генерируются на основе первичного и альтернативных ключей и предотвращают попытки вставить запись с неуникальным (повторяющимся) значением посредством извещения пользователя об ошибке и игнорирования на его действия по добавлению неверного (повторяющегося) значения индекса.
Для создания индекса с повторяющимися значениями опцию Unique следует выключить. Повторяющиеся значения индекса разрешаются, если ожидается, что индексированная колонка будет с большой вероятностью содержать повторяющуюся информацию. Неуникальный индекс генерируется на основе внешнего ключа.

Рисунок 2.18. Создание нового уникального индекса
При создании нового индекса ERwin автоматически создает альтернативный ключ для уникального индекса и инверсионный вход для неуникального индекса, а также дает соответствующее ключу имя индекса. Имя сгенерированного индекса в дальнейшем при необходимости можно изменить вручную через диалог Rename Index, открывающийся по активизации кнопки Rename… (рисунок 2.19).

Рисунок 2.19. Диалог Rename Index
Задание для самостоятельной работыРазработать логическую модель данных системы «Поликлиника», обладающей следующими возможностями:
– хранение данных о пациентах, врачах, приемах, диагнозах, лечениях, лекартвах;
– корректировка данных о пациентах и врачах;
– поиск данных о пациентах и врачах по фамилии или адресу;
– добавление новых лекарств с описанием их свойств;
– поиск справочных данных по лекарствам;
– регистрация приемов на дому или в поликлинике.
– формирование статистической информации за отчетный период.
При создании логической модели данных системы в среде ERwin выбрать логико – физический тип модели.
Тема 4.3. Разработка и эксплуатация удаленных баз данныхОсновы проектирования серверной части приложения.
Технологии разработки и управления базами данных средствами языка SQL.
Разработка и эксплуатация серверной части.
Планирование и реализация индексов.
Внешние ключи и ссылочная целостность.
Серверные объекты базы данных.
Принципы проектирования клиентской части баз данных.
Построение запросов к базе данных с помощью языка SQL.
Обработка данных с помощью языка SQL.
Разработка и эксплуатация клиентской части.
Программы управления удаленными базами данных.
Публикация баз данных.
Основы проектирования серверной части приложения
Программное обеспечение баз данных
В настоящее время реляционные системы управления базами данных (СУБД) являются важным инструментом во многих областях, начиная с таких традиционных областей применения, как бизнес, научные исследования, образование, и заканчивая разработкой поисковых серверов в Internet. Однако, несмотря на важность наличия хорошей базы данных для введения и доступа к информационным ресурсам, многие организации не применяют их в своей работе. Исторически сложилось так, что СУБД стоили очень дорого, а продавцы устанавливали очень высокие цены как на программное обеспечение, так и на услуги по технической поддержке. Кроме того, механизмы СУБД требовали удовлетворения существенных требований по производительности от аппаратных платформ, что еще больше повышало стоимость таких решений.
В последние годы ситуация резко изменилась как с точки зрения программного обеспечения, так и с точки зрения аппаратуры. Компьютеры одновременно дешевеют и становятся мощнее. При этом обозначилась тенденция создания высокопроизводительных операционных систем, которые можно купить по цене дешевых лазерных дисков или даже получить бесплатно через Internet, таких как операционные системы, созданные на базе ОС BSD UNIX (FreeBSD, NetBSD, OpenBSD), а также различные версии ОС Linux (RedHat, Caldera, LinuxPPC).
Создание операционных систем, позволяющих максимально использовать возросшие возможности компьютеров, произошло прежде всего благодаря тому, что были разработаны и свободно распространялись такие средства разработки, как компилятор GNU С gcc. Эти попытки создания программного обеспечения, которое было бы доступно для каждого, кто хочет его получить, дало толчок движению, которое сейчас известно как Open Source movement, и дало жизнь многим важным и нужным программам. В качестве примера успешного применения идеологии Open Source movement можно привести самый загруженный узел FTP в мире - ftp.cdrom.com, работающий под управлением ОС FreeBSD. Сервер Apache является самым широко используемым сервером в Internet. Еще одним успешным проектом Open Source является язык написания сценариев Perl и быстро завоевывающий поклонников язык РНР.
Программное обеспечение баз данных тоже стало более доступным. Достаточно вспомнить такие СУБД, как Postgres и mSQL, которые можно получить за невысокую плату или совсем бесплатно. Совсем недавно такие мощные коммерческие производители, как Informix и Oracle начали предлагать свое программное обеспечение совсем бесплатно для таких ОС, как Linux. (Однако эти продукты поставляются обычно в двоичном виде и без поддержки, что снижает их пользу.)
Одним из новейших явлений на "арене" недорогих или бесплатных баз данных является MySQL, реляционная СУБД, типа клиент/сервер, созданная в Скандинавии. СУБД MySQL включает в себя SQL-сервер и программы-клиенты, осуществляющие доступ к серверу, средства администрирования и программный интерфейс для программирования своих собственных программ.
СУБД MySQL "уходит своими корнями" в 1979 год и происходит от СУБД UNIREG, разработанной Михаэлем Видениусом по заказу шведской компании ТсХ. В 1994 году компания ТсХ начинает искать SQL-сервер для создания Web-приложений. Было опробовано несколько коммерческих серверов, но те оказались слишком медленными для больших таблиц данных, которые использовались в компании ТсХ. Они также обратили внимание на СУБД mSQL, но та не совсем удовлетворяла задачам компании ТсХ. Поэтому Монти начал работать над созданием нового сервера. Программный интерфейс был разработан как аналог mSQL, так как тогда в наличии было несколько бесплатных средств mSQL. Пользуясь аналогичным интерфейсом, эти же средства можно использовать для СУБД MySQL с минимальными затратами на перенос.
MySQL работает на многих платформах и распространяется как в двоичных кодах, так и в исходных текстах.
СУБД MySQL нельзя причислить в полной мере к проектам Open Source, так как при определенных условиях покупка лицензии все же требуется. Тем не менее MySQL пользуется широкой популярностью среди сторонников движения Open Source, так как условия лицензирования здесь не очень строгие. (По сути, MySQL распространяется бесплатно за исключением тех случаев, когда вы намереваетесь ее продавать или продавать услуги, создаваемые с ее помощью.)
Но популярность СУБД MySQL не ограничивается только сообществом Open Source. Да, она работает на персональных компьютерах (при этом многие разработки, производящиеся на MySQL, создаются на недорогих Linux-системах). Но MySQL обладает отличной переносимостью и может с тем же успехом использоваться на дорогих коммерческих операционных системах (таких как Solaris, Irix или Windows) и на любой аппаратуре вплоть до мощных серверов. Более того, так же как и ее более "дорогие соперники", она позволяет обрабатывать большие базы данных, содержащие миллионы записей.
Теперь СУБД MySQL предстала перед нами во всей красе: бесплатные операционные системы, работающие на мощных, но не очень дорогих персональных компьютерах, предоставляющих в распоряжение пользователей значительную вычислительную мощность и более широкий выбор операционных систем, чем прежде. Снижение экономических барьеров позволяет получить доступ к базам данных большему количеству людей и организаций, чем когда бы то ни было. Вы можете, например, общаться с СУБД MySQL с помощью языков Perl и РНР, сервера Apache на ПК, работающем под управлением ОС LinuxPPC.
Прошли те времена, когда многие организации могли только мечтать об использовании огромных возможностей мощных реляционных СУБД. Теперь это уже не проблема. Цены на СУБД снизились, поэтому использовать СУБД можно уже и индивидуальным пользователям. Люди, даже не мечтавшие об использовании баз данных, теперь могут широко их применять, например, для реализации задачи хранения и просмотра данных о генеалогических исследованиях, ведения собственных коллекций (бабочки, марки, бейсбольные карточки и т.д.), помощи в своем бизнесе на начальной стадии или обеспечения поисковых возможностей персональных Web-страниц.
Это занятие - введение в систему управления реляционными базами данных MySQL и язык структурированных запросов (SQL), который "понимает" СУБД MySQL. Тут описаны основные термины, и концепции, а также база данных, которая будет использована во всех примерах, приведенных в последующих занятиях.
По сути, система баз данных представляет собой способ манипулирования информационными списками. При этом информация может поступать из различных источников. Например, это могут быть данные, полученные в ходе исследований, деловые записи, заказы потребителей, спортивная статистка, отчеты о продажах, отчеты об ошибках или оценки учащихся. Несмотря на то, что СУБД могут содержать широкий диапазон информации, вы не будете использовать СУБД только из-за нее самой.
Хорошим примером является список продуктов. Список содержит перечень покупок, из которого затем вычеркиваются купленные продукты. А потом этот список удаляется. Вряд ли вы воспользуетесь СУБД в этих целях. Даже в том случае, если у вас есть переносной ПК, вы воспользуетесь программой Блокнот, а не возможностями СУБД.
СУБД проявляет себя как мощный инструмент тогда, когда информация, которую необходимо организовать и которой уже необходимо манипулировать, становится объемной и сложной, вследствие чего записи становятся непонятными и трудно обрабатываемыми вручную. Конечно, базы данных могут использоваться большими корпорациями, обрабатывающими миллионы транзакций в день. Но СУБД может также потребоваться для маломасштабных операций, которые обрабатывает один человек в личных целях. Можно привести множество примеров ситуаций, когда СУБД будет использоваться даже в том случае, когда объемы информации не возросли до огромных размеров. Некоторые из таких ситуаций описаны ниже.
В вашем столярном бизнесе занято несколько работников. Нужно упорядочить записи о работниках и выплатах таким образом, чтобы иметь представление, кому вы и когда платили, получить возможность составлять отчеты о доходах в налоговые инстанции. Могут также понадобиться записи о нарядах, которые выполнял работник, и информация о том, кто планировался для выполнения этой работы.
Вы содержите сеть складов автомобильных запасных частей. Необходимо получить оперативную информацию о том, на каком из складов лежит запасная часть, заказанная покупателем.
Вы продавец игрушек и зависите от колебания спроса на игрушки.
Вам необходимо знать тенденции в продажах определенных товаров так, чтобы иметь возможность оценки необходимости увеличения складских накоплений (для товаров, которые становятся более популярными) или уменьшения (нет нужды хранить на складе то, что уже не будет хорошо продаваться).
Нужно проанализировать гору данных, полученных в ходе исследований за долгие годы, чтобы фраза "опубликуй или погибни" не стала эпитафией вашей карьеры. Вам необходимо переварить массу данных, чтобы получить итоговую информацию и более детальные выборки для более подробного статистического анализа. Вы известный докладчик, объезжающий страну с докладами в различных аудиториях: будь то выпускные церемонии, деловые встречи и т.д. Часто вспомнить, что вы говорили в той или иной аудитории, бывает довольно затруднительно. Поэтому потребовалось вести протоколы своих встреч с тем, чтобы использовать их в своих планах на будущее. Это нужно для того, чтобы не повторяться в одной и той же аудитории. В этом случае запись о докладе, проведенном в этой аудитории, поможет избежать повторений. Кроме того, можно оставлять запись о том, насколько хорошо здесь был принят ваш доклад.
Учитель ведет записи об успеваемости и посещаемости своих уроков. После каждого теста вы записываете оценку, полученную каждым учащимся. Простым решением является запись оценок в журнале, но последующее использование этих записей затруднительно. При этом затруднительна сортировка учеников по баллам. Кроме того, учет посещаемости также вырастает в большую проблему.
Вы работаете в организации секретарем и ведете список членов этого общества. (Организация может быть самой разной - профессиональное общество, клуб, театр, симфонический оркестр или атлетический клуб.) На основании постоянно корректируемого документа ежегодно издается список членов. Этот документ редактируется по мере изменения информации о членах организации. Из-за ограничений, присущих этому методу, вы устали вести список вручную. Трудно сортировать записи. Довольно проблематично выбрать только определенную часть каждой записи (например, перечень, состоящий только из фамилий и телефонов). Или трудно выбрать ту часть зарегистрированных членов общества, срок членства которых истек и которым следует немедленно возобновить свое членство.
Кроме того, вы хотите избежать редактирования этого списка собственноручно, но бюджет общества не позволяет нанять кого-либо для выполнения этой работы. Вы что-то где-то слышали о "безбумажном офисе", когда информация хранится в электронном виде, но не видели никакой выгоды от внедрения этой технологии для себя. Записи о членстве хранятся в электронном виде, но, по иронии, они хранятся в труднодоступной форме.
Такие сценарии применимы как для ситуаций с большими объемами информации, так и для ситуаций с малыми объемами информации. Все их можно охарактеризовать, как класс задач, которые в принципе можно производить вручную, хотя эффективнее они могут обрабатываться с помощью СУБД.
Каких преимуществ можно ожидать от использования такой СУБД, как СУБД MySQL? Это зависит от ваших конкретных задач и требований и, как видно из приведенных примеров, может сильно варьироваться. Давайте представим себе ситуацию, которая возникает достаточно часто, и поэтому очень показательна при использовании СУБД MySQL.
СУБД часто применяется для таких задач, для решения которых обычно используются картотеки. Действительно, базу данных можно представить в некотором роде большой картотекой. Можно назвать несколько очень серьезных преимуществ ведения данных в электронном виде перед хранением информации вручную. Например, в офисе, где ведутся учетные записи клиентов, использование СУБД MySQL значительно облегчит вам жизнь.
Преимущества применения СУБД MySQL описаны ниже.
Сокращение времени, необходимого для ведения записей. В случае использования СУБД много времени на просмотр всей картотеки на предмет необходимости добавления новой записи не требуется.
Вы просто вводите ее в систему, не заботясь о месте размещения.
Сокращение времени, необходимого для поиска записей. При поиске данных в СУБД нет необходимости последовательно просматривать все записи, чтобы найти интересующую. Предположим, что вы работаете в стоматологическом кабинете. Надо разослать приглашения всем пациентам, которые забыли пройти профилактический осмотр. Для этого достаточно сделать запрос к информационной системе. Конечно, это происходит не так, как при обычном общении с людьми, когда вы формулируете свой запрос примерно таким образом: "Найдите, пожалуйста, тех пациентов, которые не посещали нас на протяжении последних 6 месяцев". При работе с базой данных вы делаете такую странную сентенцию:
SELECT last_name, first_name, last_visit
FROM patient WHERE last_visit < DATE_SUB(CURRENT_DATE, INTERVAL 6 MONTH)
Возможно, вы никогда не встречали ничего подобного, но перспектива получить ответ через секунду или две вместо изнурительного многочасового просмотра записей должна показаться привлекательной.
Гибкость поиска. Нет необходимости искать записи строго в соответствии с порядком, в котором они были записаны (по фамилии пациента, например). Информационной системе можно приказать расположить записи, отсортированные в любом порядке: по фамилии, названию страховой компании, дате последнего визита и т.д. Гибкость формата вывода. После того как необходимые записи были найдены, копировать записи вручную не нужно. Можно сделать запрос информационной системе на вывод нужного списка. Иногда достаточно просто распечатать информацию. В других случаях вам может понадобиться воспользоваться этими данными в другой программе. (Например, после получения списка пациентов, которые забыли сделать регулярный профилактический осмотр, эти данные можно переслать в текстовый редактор и уже на основании этой информации распечатать приглашения этим пациентам посетить ваш кабинет.) Предположим, что вам нужна только итоговая информация, такая как счетчик выбранных записей. И это совсем не обязательно делать вручную. Информационная система сгенерирует такой отчет сама.
Одновременный многопользовательский доступ к записям. Предположим, что сразу два человека хотят одновременно просмотреть одну запись. При бумажном способе ведения дел второй кандидат всегда вынужден ждать, пока первый закончит просмотр бумаг. СУБД позволяет получить доступ к одной и той же записи одновременно.
Удаленный доступ и передача записей в электронном виде. Бумажная технология ведения дел требует от вас быть там, где находятся сами бумаги, в противном случае кто-то должен скопировать и переслать их вам. Электронный способ ведения записей позволяет производить удаленный доступ к записям и передачу их в электронном виде. Предположим, что ваша стоматологическая фирма состоит из подразделений, удаленных территориально, электронный способ ведения учета позволяет производить доступ к вашим записям из удаленных офисов. Нет необходимости посылать копии записей о пациентах курьером, даже если кто-либо не имеет в своем распоряжении базы данных, аналогичной вашей, но имеет электронную почту. Ему можно будет посылать содержимое базы данных в электронном виде.
Тот, кто имел опыт работы с СУБД, знает об этих преимуществах и может уже подумать не только о банальном замещении бумажной картотеки. СУБД теперь используются для предоставления услуг, о которых еще недавно не могло быть и речи. Примером тому может служить использование многими организациями баз данных в совокупности с доступом к Internet.
Предположим, что ваша компания имеет базу данных учета материальных ценностей, которой пользуются менеджеры при поступлении запросов от потребителей о наличии и стоимости товаров. Это достаточно традиционное использование баз данных, однако, если ваша компания может создать свой Web-узел, в перечне сервисов которого потребителям предоставляется возможность самим узнать о наличии товара на складе и по цене, это позволит потребителям самим получать нужную им информацию о товарах и способах их поставки. При этом потребитель получает информацию немедленно, не слушая раздражающую музыку в телефонной трубке. Такой магазин может работать круглые сутки. Для всех посетителей вашего Web-узла это будет означать, что им придется сделать на один звонок меньше.
Но базе данных можно найти еще лучшее применение. Запросы на поиск товара, сделанные через ваш Web-узел, могут служить источником информации не только для тех, кто их делает, но и для вас самих.
Вы сможете получить ответ на очень важный вопрос: "Что нужно потребителю?" А результаты выполнения запросов потребителей покажут, сможете ли вы удовлетворить их запросы. Если у вас нет того, что им нужно в данный момент, ваш бизнес может прогореть. Поэтому есть смысл хранить информацию о спросе на товары и об имеющемся ассортименте. Имея под руками такую информацию, вы сможете эффективно управлять запасами товаров на складе и тем самым удовлетворять спрос покупателей.
Еще одним новейшим применением баз данных на Web-страницах может служить реклама на баннерах. Они являются популярным применением СУБД MySQL, который может здесь быть использован для хранения рекламы и поиска ее Web-сервером для отображения. Кроме того, СУБД MySQL может хранить данные о том, как часто происходили обращения к данному роду деятельности, об отслеживании рекламы, которая сработала, сколько раз она запрашивалась, с каких узлов был произведен доступ и т.д.
Структурная терминология
СУБД MySQL классифицируется как реляционная система управления базами данных (RDBMS - relational database management system).
Эта аббревиатура разбивается на части следующим образом.
База данных (БД) (DB в RDBMS) - это совокупность информации, разбитой простым способом, регулярным образом.
Совокупность данных в базе данных объединена в таблицы.
Таблица состоит из строк и столбцов.
Строка таблицы является ее записью.
Записи содержат несколько единиц информации, каждый столбец таблицы содержит одну такую единицу.
Система управления (СУ) (MS) является программным обеспечением, позволяющим вставлять, выбирать, модифицировать и удалять записи.
Слово "реляционная" обозначает популярную разновидность СУБД, в которых отслеживается "соответствие" записей в одной таблице на "соответствие" записей в другой таблице. Мощь реляционных СУБД заключается в их способности выбирать соответствующие данные из этих таблиц и создавать ответы на вопросы, которые нельзя получить только из одной такой таблицы. Приведем пример того, как реляционная база данных объединяет данные в таблицы и связывает данные из одной таблицы с данными из другой таблицы.
Предположим, что вы сопровождаете Web-узел, представляющий сервис размещения баннеров. Вы поддерживаете контакт с компаниями, которые хотят разместить свою рекламу. Эта реклама будет появляться при каждом посещении вашего Web-узла. Всякий раз, когда посетитель вашего узла попадает на одну из ваших страниц, вы вместе с ней посылаете встроенную рекламу на броузер посетителя и получаете с рекламируемой компании небольшой гонорар.
Для отображения этой информации воспользуемся тремя таблицами (рисунок 1). Первая таблица company содержит столбцы с именами компаний, номером, адресом и телефонным номером. Вторая таблица ad содержит номера реклам, компаний, которым принадлежат эти рекламы, сумму, которую вы берете с них за один доступ к их рекламе. Третья таблица hits регистрирует количество обращений к рекламе и дату, когда это произошло.
Ответы на некоторые вопросы можно получить, пользуясь информацией из одной таблицы. Для определения количества компаний, с которыми у вас имеются контракты, достаточно посчитать строки в таблице company. Аналогично, для подсчета количества обращений за определенный период времени достаточно таблицы hit. Другие вопросы посложнее и, для получения ответов на них, необходимо опросить не одну, а несколько таблиц. Например, для определения, сколько раз было сделано обращение ко всем рекламам компании Pickles, Inc. 14 июля вам потребуется просмотреть три таблицы.
По названию компании (Pickles, Inc.) в таблице company определить номер компании (14).
По номеру компании найти соответствующие ему записи в таблице ad, содержащие номера рекламы. В нашем примере мы видим две такие записи 48 и 101.
С помощью номера рекламы для всех найденных в таблице ad записей определить соответствующие записи в таблице hit, попадающие в нужный диапазон дат, а затем подсчитать количество совпадений. Найдено три совпадения для рекламы номер 48 и два совпадения для рекламы номер 101.
На первый взгляд, непросто. Но это лишь основа, на которой зиждется совершенство реляционных баз данных. Здесь сложность несколько иллюзорна. Ибо каждый только что описанный шаг содержит нечто большее, чем простые операции выборки: вы связываете одну таблицу с другой с подбором значений из строк одной таблицы со строками другой таблицы. Эта простая операция может быть использована различными способами для получения ответов на следующие вопросы. Сколько различных реклам имеет каждая компания? Рекламы, какой компании наиболее популярны? Сколько дохода приносит каждая реклама? Каков полный гонорар от каждой компании за текущий период?

Рисунок 1. Таблица учёта баннерной рекламы
Терминология языка запросов SQL.
Для общения с СУБД MySQL применяется язык SQL. Он является стандартом работы с базами данных.
Терминология архитектуры СУБД MySQL.
СУБД MySQL использует традиционную архитектуру клиент/сервер, поэтому работая с СУБД MySQL, пользователь реально работает с двумя программами.
Программой сервера базы данных, расположенной на компьютере, где хранится база данных. Она "прослушивает" запросы клиентов, поступившие по сети, и осуществляет доступ к содержимому базы данных для представления информации, которую запрашивают клиенты
Клиентской программой, которая является программой, осуществляющей подключение к серверу и передающей запросы на сервер.
Дистрибуция СУБД MySQL включает в себя несколько клиентских программ и сервер. Клиентские программы используются в соответствии с поставленными целями. Одной из наиболее популярных и наиболее привлекательных клиентских программ является mysql. Это интерактивная программа, позволяющая создавать запросы и просматривать полученные результаты.
Другими клиентскими программами являются утилита mysqldump и mysql import, которые осуществляют дамп базы данных в файл и восстановление его обратно, и утилита mysqladmin, позволяющая производить проверку состояния сервера и осуществлять административные задачи, такие как выключение сервера (shut-down). Клиентские программы могут не подходить по своим функциональным возможностям для ваших целей, тогда вам может пригодиться библиотека для написания своей собственной программы-клиента СУБД MySQL. Эту библиотеку можно вызывать прямо из программ, написанных на языке С. Для других языков программирования предусмотрены свои библиотеки.
СУБД MySQL обладает многими преимуществами.
Быстродействие. MySQL - достаточно быстродействующая СУБД. Разработчики склоняются к мнению, что СУБД MySQL является одной из самых быстрых баз данных из имеющихся на современном рынке. В этом можно удостовериться, посетив Web-узел http: //www.mysql.com/benchmark.'html. Эта страница позволяет делать сравнительную проверку производительности на Web-узле MySQL.
Простота использования. СУБД MySQL является высокопроизводительной и относительно простой в использовании СУБД, которую значительно проще инсталлировать и администрировать, чем многие большие системы.
Цена. СУБД MySQL распространяется бесплатно для домашнего использования.
Поддержка языка запросов. MySQL "понимает" команды языка SQL (Structured Query Language - структурированный язык запросов). Этот язык применяется во всех современных СУБД. MySQL также поддерживает интерфейс ODBC (Open Database Connectivity), протокол интерфейса с базами данных, разработанный компанией Microsoft.
Возможности. Сервер позволяет одновременно подключаться неограниченному количеству пользователей. Доступ к серверу СУБД MySQL можно осуществить в интерактивном режиме с помощью различных интерфейсов, позволяющих вводить запросы и просматривать полученные результаты: это программы- клиенты, работающие с командной строкой, Web-броузеры или программы-клиенты, работающие в системе X Window. Кроме того, в наличии имеются программные интерфейсы для таких языков, как С, Perl, Java, PHP и Python. Таким образом, можно использовать как готовое клиентское программное обеспечение, так и создавать свое собственное.
Взаимодействие и безопасность. MySQL предназначена для работы в сети и может быть доступна через Internet, таким образом, с данными можно работать в любой точке земного шара. Но при этом СУБД MySQL снабжена развитой системой защиты от несанкционированного доступа.
Переносимость. СУБД MySQL отлично работает как под управлением самых различных версий UNIX, так и под управлением систем, не использующих UNIX, таких как Windows и OS/2. СУБД MySQL работает как на домашних ПК, так и на мощных серверах.
Открытое распространение. Дистрибуция СУБД MySQL легкодоступна. Для этого достаточно воспользоваться Web-броузером. Если вы не понимаете как что-либо работает, просмотрите исходный код. Если вам что-то в работе не нравится, можно внести коррективы.
А как обстоят дела с поддержкой? Хороший вопрос, тем более, что от базы данных, которой нельзя пользоваться, польза невелика.
СУБД MySQL имеет хорошую поддержку.
СУБД MySQL снабжена расширенным справочным руководством (450 страниц и постоянное дополнение).
Можно заключить контракты на техническую поддержку с самими разработчиками MySQL.
Есть список рассылки, на который может подписаться любой желающий. В нем принимает участие очень много грамотных пользователей, в том числе включая и самих разработчиков MySQL. Этого будет достаточно для большинства пользователей СУБД MySQL.
Ответы на вопросы, размещенные в списке рассылки, можно получить за считанные минуты. Обнаружив ошибку, разработчики исправят ее за считанные дни (иногда часы!), и исправления можно получить немедленно по Internet. Это резко контрастирует с нередко разочаровывающим опытом работы с бюрократическими отделами поддержки больших компаний, продающих СУБД.
Если вы находитесь на этапе выбора, то СУБД MySQL является идеальным кандидатом для проведения оценки. Эту СУБД можно проверить в работе безо всякого риска и финансовых расходов. Если у вас возникают какие-либо проблемы, можно обратиться к списку рассылки. Оценка всегда требует определенного времени, но это не относится к рассматриваемой СУБД, ее инсталляция и установка требует гораздо меньше времени, чем многие другие современные СУБД.
Предварительные требования
Предварительно необходимо установить СУБД MySQL. В частности, необходимо иметь доступ к клиентам СУБД MySQL и какой-либо сервер СУБД MySQL. Клиентские программы устанавливаются на вашем компьютере. По крайней мере вам понадобится mysql, также может пригодиться утилита mysql import. Сервер также может быть установлен на вашем компьютере, хотя в этом нет необходимости. Имея право на подключение к серверу, вы можете располагать его где угодно.
Предположим, что клиент и сервер установлены на вашем компьютере. Все готово. Если же надо приобрести СУБД MySQL, При этом, если вы устанавливаете его самостоятельно, в противном случае - покажите ее администратору базы данных. Если подключение к сети происходит через провайдера Internet (ISP) убедитесь в том, что ваш провайдер имеет СУБД MySQL.
После этого необходимо получить право на создание своей тестовой базы данных и ее таблиц. Если такого права нет, обратитесь к администратору базы данных. Он может дать вам такое право с помощью следующих команд.
GRANT ALL ON samp_db.* TO paul@localhost IDENTIFIED BY "secret"
GRANT ALL ON samp_db.* TO paul@% IDENTIFIED BY "secret"
Первая команда дает пользователю paul полный доступ к базе данных samp_db и всем ее таблицам, когда paul подключается с адреса localhost (узел на котором работает сервер). Он также назначает ему пароль secret. Вторая команда аналогична, но позволяет пользователю paul осуществлять полный доступ к базе данных с любого узла ('%' - синоним всего). Здесь можно заменить символ "%" именем конкретного узла. (Оператор GRANT может вам пригодиться для доступа с узла localhost, благодаря тому, что сервер просматривает таблицы привилегий для входящих соединений.)
Различие между MySQL и mysql
Во избежание разночтений, подчеркнем, что MySQL относится ко всей СУБД MySQL, a "mysql" - название конкретной клиентской программы. В разговорной речи это звучит одинаково, но в написании одно наименование пишется заглавными буквами, а другое - прописными. С одной стороны, MySQL, произносится как "май-эс-кью-элл". Это известно из руководства по использованию MySQL. С другой стороны, SQL произносится как "сиквел".
Оптимальный выбор типа для хранения данных
Почти каждый оператор SQL неким образом обращается к базе данных или элементам, ее составляющим.
При присвоении имен элементам базы данных мы ограничены набором допустимых символов и длиной имени. Вид имени также зависит от контекста, в котором оно используется.
Допустимые символы. Имя может состоять из любого алфавитно-цифрового символа из набора символов, которые использует сервер, плюс символы '_' (символ подчеркивания) и '$' (знак доллара). Имена могут начинаться с любого допустимого символа, включая цифры. Однако имя столбца не может состоять из одних цифр: это сделает его неотличимым от чисел. В СУБД MySQL предусмотрена уникальная возможность начинать имя с цифры. При этом необходимо быть особенно внимательным при использовании имен, содержащих символ "Е" или "е". Такие имена приводят к неоднозначности. Выражение 23е + 14 может означать сложение значения столбца 23е плюс 14. А что может значить 23е+14? Это имя или это число в научной нотации?
Длина имени. Имена баз данных, таблиц, столбцов и индексов имеют длину до 64 символов. Имена псевдонимов могут иметь до 256 символов.
Квалификаторы имен. Для обращения к базе данных достаточно просто указать ее имя.
USE db_name
SHOW TABLES FROM db_name
Для ссылки на таблицу есть два варианта: дать полностью квалифицированное имя таблицы, состоящее из двух частей, разделенных точкой, - имени базы данных и имени таблицы:
SHOW TABLES FROM db_name.tbl_name
SELECT * FROM db_name.tbl_name
При указании только имени таблицы обращение происходит к текущей базе данных. Два следующих оператора идентичны:
SHOW TABLES FROM member
SELECT * FROM samp_db.member
Для ссылки на столбец есть три варианта: указание полностью квалифицированного имени столбца, указание частично квалифицированного имени столбца и указание неквалифицированного имени столбца. Полностью квалифицированное имя столбца (в нотации db_name.tbl_name.col_name) дает ссылку на определенный столбец из определенной таблицы, входящей в состав определенной базы данных. Частично квалифицированное имя столбца (записанное как tbl_name.col_name) ссылается на определенный столбец в определенной таблице. Вот два запроса, ссылающиеся на одноименные столбцы. Но из контекста предложений FROM видно, что они относятся к разным таблицам:
SELECT last_name, first_name FROM president
SELECT last_name, first_name FROM member
Обычно давать полностью квалифицированные имена не нужно, хотя это и не будет ошибкой. Использование оператора USE делает базу данных текущей. В операторе SELECT таблица становится текущей таблицей для всех столбцов в данном операторе, если она одна указана в предложении FROM. Имена таблиц нужно квалифицировать только при наличии в операторе нескольких таблиц (когда таблицу или базу данных нельзя определить по контексту). Вот несколько ситуаций, при которых возникает такая неоднозначность.
Запросы, ссылающиеся на таблицы из нескольких баз данных. Любая таблица, не являющаяся в данный момент текущей, должна указываться нотацией db_name. tbl_name. Это помогает определить, из какой базы данных использовать таблицу.
Запросы, выбирающие столбцы из нескольких таблиц. Это запросы, в которых столбец с одним и тем же именем присутствует в нескольких таблицах.
Чувствительность к регистру в операторах SQL
Правила, которым подчиняется синтаксис операторов SQL с точки зрения чувствительности к регистру, зависят от части оператора и от операционной системы, под управлением которой работает сервер.
Ключевые слова и имена функций. Ключевые слова и имена функций не зависят от регистра. Они могут вводиться в любом регистре. Вот абсолютно идентичные операторы:
SELECT NOW()
select now()
SeLeCt nOw()
Имена баз данных и таблиц. Имена баз данных и таблиц подчиняются правилам именования каталогов и файлов в операционной системе, работающей на сервере. Вследствие этого, чувствительность к регистру имен баз данных и таблиц подчиняется правилу, предусмотренному для имен файлов и принятому в операционной системе. Для сервера, работающего под управлением ОС UNIX, имена баз данных и таблиц зависят от регистра, а в ОС Windows имена файлов не зависят от регистра, поэтому имена баз данных и таблиц поведут себя аналогичным образом.
Об этом нужно помнить в случае, когда ставится задача переноса базы данных из ОС UNIX в ОС Windows. Если в процессе работы с базой данных были созданы две таблицы, например, abc и ABC, то после переноса базы данных в среду ОС Windows они будут неразличимы. Как этого избежать? Достаточно выработать для себя правило, регламентирующее создание всех баз и таблиц только в одном регистре. Только тогда при переносе данных из одной операционной среды в другую можно не беспокоиться о неоднозначности данных.
Имена столбцов и индексов. В СУБД MySQL имена столбцов и индексов не чувствительны к регистру. Следующие операторы будут эквивалентны:
SELECT name FROM student
SELECT NAME FROM student
SELECT nAmE FROM student
Имена псевдонимов. В СУБД MySQL псевдонимы чувствительны к регистру. Псевдоним можно объявлять в любом регистре (верхнем или нижнем, в обоих сразу), но при дальнейших обращениях к нему необходимо четко соблюдать первоначальный регистр.
Опыт показывает, что независимо от того, является база данных, таблица или псевдоним чувствительным к регистру, их необходимо указывать в одном и том же регистре на протяжении одного и того же запроса. Это правило не относится к ключевым словам языка SQL, именам функций, столбцов и индексов, которые можно вводить в разных регистрах. Естественно, необходимо стремиться делать запросы как можно более читабельными и стремиться вырабатывать определенный стиль ввода элементов запроса.
Типы данных СУБД MySQL
В СУБД MySQL существует несколько типов данных. Это общие категории, по которым можно классифицировать данные
Цифровые данные
Числами будем считать значения, наподобие 48 или 193.62. СУБД MySQL различает целые числа (числа без дробной части) или числа с плавающей точкой (числа с дробной частью). Целые представляются в десятичном или шестнадцатеричном формате.
Целое состоит из последовательности цифр. Целое в шестнадцатеричном представлении состоит из '0х', с последующими шестнадцатеричными цифрами (от 0 до 9 и от а до f). Например, 0х0а равно десятичному 10, a 0x0ffff равно 65535. Нецифровые шестнадцатеричные цифры могут быть представлены как в нижнем, так и в верхнем регистре. Но ведущая последовательность '0х' должна быть представлена только в нижнем регистре.
Числа с плавающей точкой состоят из последовательности цифр, разделенных точкой. Одна из этих последовательностей (но не все сразу) может быть пустой.
СУБД MySQL может работать и с научной нотацией чисел. Этот формат выглядит следующим образом: число в целом или плавающем формате, затем символ экспоненты "е" или "Е", знак ("+" или "-") и целочисленная экспоненциальная часть. 1.34Е+12 или 43.27е-1 - это числа в правильной научной нотации. Однако 1.34Е12 является неправильной научной нотацией, так как перед экспонентой отсутствует символ знака. Шестнадцатеричные числа не могут быть представлены в научной нотации: символ "е", предваряющий экспоненту, здесь является полноправным числом, и таким образом выражение становится неоднозначным.
Для обозначения отрицательных значений, числа предваряются знаком минус "-".
Строковые (символьные) данные
Строками являются такие значения, как "Madison, Wisconsin" или "patient shows improvement". Для обозначения строки она берется в одинарные или двойные кавычки.
Для обозначения специальных символов применяются управляющие последовательности. Они представлены в таблице. 1. Последовательность начинается с символа обратной косой черты ("\") Для временного отключения от обычных правил интерпретации символов. Обратите внимание, что байт NUL это не то же самое, что значение NULL. NUL - это байт с нулевым значением, a NULL символизирует отсутствие какого-либо значения вообще.
Таблица 1. Управляющие последовательности
Последовательность Значение
\0 NUL (ASCII 0)
\' Одинарная кавычка
\" Двойная кавычка
\b Backspace
\n Новая строка
\r Возврат каретки
\t Табуляция
\\ Обратная косая черта
В строковых переменных тоже используется шестнадцатеричный формат. Синтаксис шестнадцатеричного формата был показан ранее на примере числовых значений. Но в этом случае шестнадцатеричные цифры интерпретируются как ASCII-коды и преобразуются в символы. Результат будет строкой. Например, при интерпретации 0x616263 получим "abc".
Календарные данные
Дата и время - это значения типа "1999-06-17" или "12:30:43". СУБД MySQL воспринимает также комбинированные значения типа дата/время, такие как "1999-06-17 12:30:43". Обратите внимание, что СУБД MySQL отображает даты в формате год-месяц-день. Этот факт удивляет новичков, начинающих работать с СУБД MySQL, несмотря на то, что этот формат является стандартом ANSI SQL. Отображать дату можно в любом формате. Для этих целей существует функция DATE FORMAT(), но по умолчанию принят формат с предшествующим годом! Поэтому при вводе даты сначала вводится год.
Пустое значение (Null)
Null - это значение, находящееся вне всяких типов. Обычно оно используется для определения значений "нет значения", "неизвестное значение", "вне диапазона", "ничто из вышеперечисленного" и т.д. Пустые значения можно добавлять в таблицы, осуществлять поиск пустых значений по таблицам, проверять, является или не является значение пустым. Арифметические операции с пустыми значениями невозможны. (Такое значение возвращает Null.)
Типы столбцов
В MySQL поддерживаются три основных типа столбцов: числа, строки и значения даты/времени. К первому типу относятся целые числа и числа с плавающей запятой. Строки содержат цепочки текстовых или двоичных символов. Значения даты/времени могут быть представлены в самых разных форматах.
Тип столбца определяет диапазон значений, которые можно заносить в данный столбец. Здесь не допускается та гибкость, которая свойственна переменным. Тип столбца жестко задается при определении таблицы. При записи в ячейку значения другого формата осуществляется автоматическое приведение типа.
Спецификация большинства типов допускает указание размерности в скобках. Это значение определяет максимальное количество символов в представлении значения, не считая знака "минус" и цифр после запятой для чисел. В случае чисел с плавающей запятой можно указать вторую размерность, определяющую количество цифр после запятой.
Как правило, размерность не играет никакой роли для числовых столбцов. Более крупные значения принимаются и отображаются правильно. Разве что числа с плавающей запятой могут округляться до нужной разрядности. Размерность важна для строковых столбцов. Слишком длинные строки усекаются в момент вставки в таблицу.
Числа
Числа могут храниться в целом и десятичном форматах, а также в формате с плавающей запятой. Особенностью десятичных чисел является то, что они хранятся в целочисленном виде с указанием точного количества цифр после запятой. Числа с плавающей запятой вычисляются приблизительно, с той или иной точностью.
Целые числа
Далее в таблице перечислены целочисленные типы данных и соответствующие им диапазоны значений. Числа, выходящие за пределы диапазона, преобразуются в минимальное или максимальное значение.
Диапазоны целочисленных типов
Тип Знаковый диапазон Беззнаковый диапазон
TINYINT -127-127 0-255
SMALLINT -32768-32767 0-65535
MEDIUMINT -8388608-8388607 0-16777215
INT, INTEGER -2147483648-2147483647 0-4294967295
BIGINT -9223372036854775808-9223372036854775807 0-18446744073709551615
Синтаксис спецификации целочисленного типа таков:
<тип>[(<размерность>)] [UNSIGNED] [ZEROFILL]
Как минимум, нужно указать имя типа. Следом за ним в скобках приводится требуемая размерность. Флаг UNSIGNED обозначает беззнаковое число. Флаг ZEROFILL говорит о том, что в случае необходимости число должно быть дополнено ведущими нулями до нужной размерности. Применение флага ZEROFILL продемонстрировано далее.
Создание целочисленного столбца с флагом zerofill
mysql> CREATE TABLE testint (
-> i INT(11) UNSIGNED ZEROFILL
-> );
Query OK, 0 rows affected (0.03 sec)

mysql> INSERT INTO testint VALUES (123);
Query OK, 1 row affected (0.02 sec)
mysql> SELECT * FROM testint;
+-------------+
| i |
+-------------+
| 00000000123 |
+-------------+
1 row in set (0.02 sec)
Числа с плавающей запятой
Числа плавающей запятой представляют собой приблизительные значения. Они подходят для столбцов, где хранятся дробные величины или числа, выходящие за пределы самого крупного целочисленного диапазона (BIGINT). Чтобы не происходило непредсказуемых погрешностей вычислений, MySQL округляет вставляемые числа до требуемой точности, которая указана в определении столбца, хотя на практике такие погрешности никогда не возникают.
Имеются два типа чисел с плавающей запятой: числа одинарной точности и числа двойной точности. Их диапазоны приведены далее.
Тип Диапазон
FLOAT ±1,175494351Е-38 - ±3,402823466Е+38
DOUBLE, DOUBLE PRECISION, REAL ±2,2250738585072014E-308 - ±1,7976931348623157Е+308
Синтаксис спецификации типа с плавающей запятой таков:
<тип>[{<размерность>,<точность>)] [ZEROFILL]
Точность- это количество цифр после запятой. Флаг ZEROFILL указывает на необходимость дополнения числа ведущими нулями до нужной размерности. Беззнаковые числа с плавающей запятой в MySQL не поддерживаются. При описании столбца данного типа достаточно указывать одну лишь размерность. Это соответствует спецификации ODBC.
Создание столбцов с плавающей запятой
mysql> CREATE TABLE testfloat(
-> f FLOAT(20),
-> d FLOAT(40)
-> );
Query OK, 0 rows affected (0.00 sec)
mysql> DESCRIBE testfloat;
+-------+-------- +------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------+-------- +------+-----+---------+-------+
| f | float | YES | | NULL | |
| d | double | YES | | NULL | |
+-------+--------+------+-----+---------+--------+
Десятичные числа
Десятичные числа имеют фиксированное количество цифр после запятой. Эти цифры ВЫЧИСЛЯЮТСЯ точно, в отличие от чисел с плавающей запятой. Столбцы данного типа удобно использовать для хранения денежных величин, где погрешности округлений недопустимы.
Создание столбца типа DECIMAL демонстрируется в далее. Размерность определяет общее количество цифр числа, включая те, что стоят после запятой. В случае размерности 6 и точности 2 допустимый диапазон значений будет таким: -9999,99 - 9999,99. Беззнаковые десятичные числа не поддерживаются.
Создание десятичного столбца
mysql> CREATE TABLE testdec (
-> m DECIMAL(6,2) ZEROFILL
-> );
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO testdec VALUES (123.45);
Query OK, 1 row affected (0.00 sec)
mysql> SELECT * FROM testdec;
+---------+
| m |
+---------+
| 0123.45 |
+---------+
1 row in set (0.00 sec)
Строки
Строки представляют собой цепочки символов и бывают трех типов: ASCII-строки, большие двоичные объекты и перечисления. Длина ASCII-строк ограничена 255-ю символами. Большой двоичный объект (Binary Large Object, BLOB) может содержать до 16 Мбайт текста, а в MySQL версии 4.1 этот предел будет расширен до 4 Гбайт. Перечисления - это строки с предопределенным набором возможных значений.
ASCII-строки
ASCII-строки имеют тип CHAR либо VARCHAR. Описание этих типов вместе с их псевдонимами приведено далее. Столбец типа CHAR имеет фиксированную размерность. Когда значения такого столбца записываются на диск, они дополняются до нужной размерности хвостовыми пробелами, которые автоматически удаляются при извлечении этих значений. По сути, если в такой столбец заносится строка с хвостовыми пробелами, они удаляются.
Столбец типа VARCHAR хранится в базе данных в виде строки неременной длины, а в остальном ведет себя подобно столбцу типа CHAR. Это подразумевает удаление хвостовых пробелов при записи строки в ячейку. В MySQL версии 4.1 в столбцах типа
VARCHAR хвостовые пробелы удаляться не будут. В настоящее время аналогичные функции можно реализовать с помощью типа TINYTEXT.
Типы ASCII-строк
Тип Диапазон
CHAR, CHARACTER Строка фиксированной длины
VARCHAR, CHARACTER VARYING Строка переменной длины
Синтаксис спецификации строкового типа таков:
[NATIONAL] <тип>[ {<размерность>) ] [BINARY]
Значение размерности определяет максимальную длину строки. Более длинные строки будут усекаться. Если присутствует флаг BINARY, то в операциях сортировки и сравнения значений данного столбца будет учитываться регистр символов. В противном случае регистр не играет роли.
Флаг NATIONAL делает доменом столбца набор символов, установленный в системе по умолчанию. Это стандартный режим работы программы MySQL, поэтом)' данный флаг можно не указывать. Он присутствует для совместимости со стандартом SQL92.
Большие двоичные объекты
Большие двоичные объекты ведут себя подобно строкам переменной длины, но способны хранить огромные информационные массивы. Кроме того, хвостовые пробелы не отсекаются. Столбцы данного вида могут быть либо двоичными, либо текстовыми с дополнительной дифференциацией но размерности. Столбцы семейства BLOB являются двоичными, поэтому в операциях сравнения будет учитываться регистр. Столбцы семейства TEXT являются текстовыми и не чувствительны к регистру. Как и в случае обычных строк, значения, превышающие максимальную длину, усекаются. У столбцов данного типа отсутствуют значения по умолчанию. Подобная возможность появилась в MySQL версии 4.1.
Типы больших двоичных объектов
Тип Максимальная длина
TINYBLOB,TINYTEXT 255 байтов
BLOB, TEXT 64 Кбайт (G5535 байтов)
MEDIUMBLOB, MEDIUMTEXT 16 Мбайт (16777215 байтов)
LONGBLOB, LONGTEXT 4 Гбайт (4294967295 байтов)
Перечисления и множества
К строковым типам относятся также перечисления и множества. Ячейка типа ENUM (перечисление) в определенный момент времени содержит лишь одно значение из списка возможных. Ячейка типа SET (множество) может содержать несколько уникальных значений из числа тех, что входят в множество.
Перечисления и множества
Тип Максимальное число значений
ENUM 65535
SET 64
Значение, заносимое в ячейку типа ENUM, указывается в строковом виде. Значение ячейки типа SET записывается в виде строки, содержащей разделенные запятыми элементы множества. Это подразумевает, что сами элементы не содержат запятых.
Далее демонстрируется создание таблицы со столбцами типа ENUM и SET, а также вставка значений в эти столбцы. Строки, которые не указаны в определении перечисления или множества, игнорируются, за исключением пустых строк.
Работа с перечислениями и множествами
mysql> CREATE TABLE testenum (
-> e ENUM ('a', 'b', 'c'),
-> s SET ( 'a', 'b', 'c' )
-> );
Query OK, 0 rows affected (0.00 sec)
mysql> INSERT INTO testenum VALUES ('a', ('b,c,x'));
Query OK, 1 row affected (0.01 sec)
mysql> INSERT INTO testenum VALUES (2, 5);
Query OK, 1 row affected (0.00 sec)
mysql> SELECT * FROM testenum;
+------+------+
| e | s |
+------+------+
| a | b,c |
| b | a,c |
+------+------+
2 rows in set (0.00 sec)
Если в качестве значения перечисления указано число, оно считается индексом элемента в определении перечисления. Нумерация элементов начинается с единицы. Ячейки типа SET интерпретируются как битовые поля. Первому элементу множества соответствует младший значащий бит.
Значения даты/времени
В MySQL поддерживаются пять типов столбцов, хранящих информацию о дате/времени. Чаще всего применяются типы DATETIME и TIMESTAMP. Для всех типов значение 0 является допустимым.
Типы больших двоичных объектов
Тип Диапазон значений
DATE '1000-01-01'-'9999-12-31'
DATETIME '1000-01-01 00:00:00' - '9999-12-31 23:59:59'
TIME '-838:59:59'-'838:59:59'
TIMESTAMP '1970-01-01 00:00:00' - '2037-12-31 23:59:59'
YEAR 1970-2069 или 1901-2155
Значения даты/времени вполне можно хранить в целочисленных или строковых столбцах, но лишь благодаря специальным типам данных появляется возможность эффективно манипулировать этими значениями. Например, поддерживается операция сложения дат, что продемонстрировано далее. Для управления такими столбцами на уровне строк или чисел потребовалось бы писать специальные программы. Значения даты/времени могут присутствовать в предложении ORDER BY и их можно сравнивать друг с другом.
Работа со значениями даты/времени
mysql> CREATE TABLE testtime (
-> ts TIMESTAMP,
-> dt DATETIME,
-> d DATE,
-> t TIME,
-> у YEAR(2)
-> );
Query OK, 0 rows affected (0.00 sec)
mysql> INSERT INTO testtime (dt, d, t, у)
-> VALUES ('1989-10-17 17:04:13', 19970322,
-> '10:15:00', 95);
Query OK, 1 row affected (0.01 sec)
mysql> SELECT * FROM testtime \G
*************************** 1. row ***************************
ts: 20040220231813
dt: 1989-10-17 17:04:13
d: 1997-03-22
t: 10:15:00
у: 95
1 row in set (0.00 sec)
mysql> UPDATE testtime
-> SET у = NOW(),
-> dt = dt + INTERVAL 15 MONTH;
Query OK, 1 row affected (0.01 sec)
Rows matched: 1 Changed: 1 Warnings: 1
mysql> SELECT * FROM testtime \G
*************************** 1. row ***************************
ts: 20040220232023
dt: 1991-01-17 17:04:13
d: 1997-03-22
t: 10:15:00
у: 04
1 row in set (0.00 sec)
Значения данного типа являются составными, представляющими собой набор целочисленных значений. У каждого компонента свой диапазон. Например, номер месяца должен находиться в интервале от 1 до 12, номер дня - от 1 до 31, номер часа - от 0 до 23, а число минут и секунд может меняться от 0 до 59.
MySQL не проверяет осмысленность таких дат, как, например, 31 февраля. Разработчики MySQL справедливо полагают, что подобные проверки должны осуществляться не в СУБД, а в прикладных программах. Допускаются неполные даты наподобие 1970-00-00. Это означает, что дата относится к 1970 году, но месяц и день неизвестны.
Вводимые данные могут быть представлены по-другому, в строковом или числовом виде. Предполагается, что дата записывается как набор целых чисел в следующем порядке: год, месяц, день, час, минуты, секунды. Номер года может состоять из двух или четырех цифр. Поля года, месяца и дня являются обязательными. Отсутствующие поля времени заполняются нулями.
Значение даты, записанное в числовом виде, представляет собой цепочку цифр. Дробная часть числа отбрасывается. В строковом представлении компоненты разделяются знаками пунктуации. Это может быть любой печатный символ кроме буквы и числа. Между номером дня и часа может стоять пробел, по между всеми остальными компонентами пробелы недопустимы. Неправильные даты обнуляются. К двухсимвольным номерам года в диапазоне 00-69 добавляется значение 2000, а к номерам в диапазоне 70-99 добавляется 1900.
Спецификация типов DATETIME, DATE и TIME не поддерживает понятия размерности. Значения этих типов всегда содержат определенное количество информации. Столбцы типа YEAR могут иметь размерность 2 или 4.
Столбцы типа TIMESTAMP по умолчанию имеют размерность 14. Допускаются также размерности 12, 8 и 6. Нечетное число преобразуется в ближайшее большее четное. Размерность определяет, какая часть спецификации даты/времени должна отображаться в результатах запроса. Реальные значения столбца всегда хранят полную спецификацию. Необычный диапазон значений столбца TTMESTAMP объясняется тем, что в UNIX время измеряется в виде количества секунд прошедших с начала так называемой эпохи (1 января 1970 г.). Это значение хранится в виде четырехбайтового целого числа.
В самую пенимо ячейку типа TIMESTAMP автоматически записывается текущее Время при изменении других ячеек строки. Данная особенность была продемонстрирована в предыдущем примере. Чтобы этого избежать, нужно явно занести в ячейку какое-то значение.
Теоретические вопросы для самоконтроля:
Перечислите клиентские программы, включенные в дистрибутив СУБД MySQL:
Возможно ли при работе с удаленной БД двум или более пользователям проссмотреть одну запись одновременно?
Сколько баз данных может содержать серверная часть СУБД?
СУБД MySQL обладает следующими преимуществами:
Поиск и сортировку записей может выполнять только администратор, или пользователь с администраторскими правами.
Совокупность данных в базе данных объединена в...
Система управления (СУ) (MS) в RDBMS является программным обеспечением, не позволяющим
К какой системе управления базами данными относится СУБД MySQL ?
Для написания сценариев доступа к базам данных СУБД MySQL вы можете воспользоваться языками написания сценариев:
Сервер не позволяет:
База данных (DB) в RDBMS (relational database management system) означает, что...
Напишите аббривиатуру понятия "Язык структурированных запросов"
Работая с СУБД MySQL, пользователь реально работает со следующими программами:
Слово "реляционная" означает
При помощи какого оператора осуществляется выборка данных в MySQL?
Программа сервера базы данных
Введите название программы, позволяющей создавать запросы и просматривать полученные результаты.
Задание для самоконтроля.
Произведите соединение с сервером, установленном на вашем компьютере.
Технологии разработки и управления базами данных средствами языка SQLНазначение языка SQL. Основные правила записи операторов
Структурированный язык запросов SQL основан на реляционном исчислении с переменными кортежами. Язык имеет несколько стандартов, наиболее распространенными из которых являются SQL-89 и SQL-92
Язык SQL предназначен для выполнения операций над таблицами (создание, удаление, изменение структуры) и над данными таблиц (выборка, изменение, добавление и удаление), а также некоторых сопутствующих операций. SQL является непроцедурным языком и не содержит операторов управления, организации подпрограмм, ввода-вывода и т. п. В связи с этим SQL автономно не используется, обычно он погружен в среду встроенного языка программирования СУБД (например, FoxPro СУБД Visual FoxPro, ObjectPAL СУБД Paradox, Visual Basic for Applications СУБД Access).
В современных СУБД с интерактивным интерфейсом можно создавать запросы, используя другие средства, например QBE. Однако применение SQL зачастую позволяет повысить эффективность обработки данных в базе. Например, при подготовке запроса в среде Access можно перейти из окна Конструктора запросов (формулировки запроса по образцу на языке QBE) в окно с эквивалентным оператором SQL. Подготовку нового запроса путем редактирования уже имеющегося в ряде случае проще выполнить путем изменения оператора SQL. В различных СУБД состав операторов SQL может несколько отличаться.
Язык SQL не обладает функциями полноценного языка разработки, а ориентирован на доступ к данным, поэтому его включают в состав средств разработки программ. В этом случае его называют встроенным SQL. Стандарт языка SQL поддерживают современные реализации следующих языков программирования: PL/I, Ada, С, COBOL, Fortran, MUMPS и Pascal.
В специализированных системах разработки приложений типа клиент-сервер среда программирования, кроме того, обычно дополнена коммуникационными средствами (установление и разъединение соединений с серверами БД, обнаружение и обработка возникающих в сети ошибок и т. д.), средствами разработки пользовательских интерфейсов, средствами проектирования и отладки.
Различают два основных метода использования встроенного SQL: статический и динамический.
При статическом использовании языка (статический SQL) в тексте программы имеются вызовы функций языка SQL, которые жестко включаются в выполняемый модуль после компиляции. Изменения в вызываемых функциях могут быть на уровне отдельных параметров вызовов с помощью переменных языка программирования.
При динамическом использовании языка (динамический SQL) предполагается динамическое построение вызовов SQL-функций и интерпретация этих вызовов, например, обращение к данным удаленной базы, в ходе выполнения программы. Динамический метод обычно применяется в случаях, когда в приложении заранее неизвестен вид SQL-вызова и он строит в диалоге с пользователем.
Основным назначением языка SQL (как и других языков для работы с базами данных) является подготовка и выполнение запросов. В результате выборки данных из одной или нескольких таблиц может быть получено множество записей, называемое представлением.
Представление по существу является таблицей, формируемой в результате выполнения запроса. Можно сказать, что оно является разновидностью хранимого запроса. По одним и тем же таблицам можно построить несколько представлений. Само представление описывается путем указания идентификатора представления и запроса, который должен быть выполнен для его получения.
Для удобства работы с представлениями в язык SQL введено понятие курсора.
Курсор представляет собой своеобразный указатель, используемый для перемещения по наборам записей при их обработке.
Описание и использование курсора в языке SQL выполняется следующим образом. В описательной части программы выполняют связывание переменной типа курсор (CURSOR) с оператором SQL (обычно с оператором SELECT). В выполняемой части программы производится открытие курсора (OPEN <имя курсора>), перемещение курсора по записям (FETCH <имя курсора>.„), сопровождаемое соответствующей обработкой, и, наконец, закрытие курсора (CLOSE <имя курсора>).
Основные операторы языка
Опишем минимальное подмножество языка SQL, опираясь на его реализацию в стандартном интерфейсе ODBC (Open Database Connectivity — совместимость открытых баз данных) фирмы Microsoft.
Операторы языка SQL можно условно разделить на два подъязыка: язык определения данных (Data Definition Language — DDL) и язык манипулирования данными (Data Manipulation Language — DML). Основные опера-горы языка SQL представлены в табл. 1.
Рассмотрим формат и основные возможности важнейших операторов, за исключением специфических операторов, отмеченных в таблице символом “*”. Несущественные операнды и элементы синтаксиса (например, принятое во многих системах программирования правило ставить “;” в конце оператора) будем опускать.
1. Оператор создания таблицы имеет формат вида:
CREATE TABLE <имя таблицы>
(<имя столбца> <тип данных> [NOT NULL] [,<имя столбца> <тип данных> [NOT NULL]] ... )
Обязательными операндами оператора являются имя создаваемой таблицы и имя хотя бы одного столбца (поля) с указанием типа данных, хранимых в этом столбце.
При создании таблицы для отдельных полей могут указываться некоторые дополнительные правила контроля вводимых в них значений. Конструкция NOT NULL (не пустое) служит именно таким целям и для столбца таблицы означает, что в этом столбце должно быть определено значение.
Операторы языка SQL:
DDL CREATE TABLE создание таблицы
DROP TABLE удаление таблицы
ALTER TABLE изменение структуры таблицы
CREATE INDEX создание индекса
DROP INDEX удаление индекса
CREATE VIEW создание представления
DROP VIEW удаление представления
GRAND*назначение привилегий
REVOKE*удаление привилегий
DMLUPDATEизменение записей
SELECTвыборка записей
INSERTвставка новых записей
DELETE удаление записей
В общем случае в разных СУБД могут использоваться различные типы данных. В интерфейсе ODBC поддерживаются свои стандартные типы данных, например, символьные (SQL_CHAR, SQL_VARCHAR, SQL_LONGVARCHAR) и др. При работе с БД некоторой СУБД посредством интерфейса ODBC выполняется автоматическое преобразование стандартных типов данных, поддерживаемых интерфейсом, в типы данных источников и обратно. При необходимости обмен данными между программой и источником данных может вестись без преобразования - во внутреннем формате данных источника.
Пример 1. Создание таблицы.
Пусть требуется создать таблицу goods описания товаров, имеющую поля: type - вид товара, comp_id — идентификатор компании-производителя, name — название товара и price — цена товара.
1. Оператор определения таблицы может иметь следующий вид:
CREATE TABLE goods (type SQL_CHAR(8) NOT NULL,
Comp_id SQL_CHAR(10) NOT NULL, name SQL_VARCHAR(20),price SQL_DECIMAL(8,2)).
2. Оператор изменения структуры таблицы имеет формат вида:
ALTER TABLE <имя таблицы>
( {ADD, MODIFY, DROP} <имя столбца> [<тип данных>]
[NOT NULL]
[,{ADD, MODIFY, DROP} <имя столбца> [<тип данных>]
[NOT NULL]]...)
Изменение структуры таблицы может состоять в добавлении (ADD), изменении (MODIFY) или удалении (DROP) одного или нескольких столбцов таблицы. Правила записи оператора ALTER TABLE такие же, как и оператора CREATE TABLE. При удалении столбца указывать <тип данных> не нужно.
Пример 2. Добавление поля таблицы.
Пусть в созданной ранее таблице goods необходимо добавить поле number, отводимое для хранения величины запаса товара. Для этого следует записать оператор вида:
ALTER TABLE goods (ADD number SQL_INTEGER).
3. Оператор удаления таблицы имеет формат вида:
DROP TABLE <имя таблицы>
Оператор позволяет удалить имеющуюся таблицу. Например, для удаления таблицы с именем items достаточно записать оператор вида:
DROP TABLE items.
4. Оператор создания индекса имеет формат вида:
CREATE [UNIQUE] INDEX <имя индекса>
ON <имя таблицы>
(<имя столбца> [ ASC | DESC ]
[,<имя столбца> [ ASC DESC ]... )
Оператор позволяет создать индекс для одного или нескольких столбцов заданной таблицы с целью ускорения выполнение запросных и поисковых операций с таблицей. Для одной таблицы можно создать несколько индексов.
Задав необязательную опцию UNIQUE, можно обеспечить уникальность значений во всех указанных в операторе столбцах. По существу, создание индекса с указанием признака UNIQUE означает определение ключа в созданной ранее таблице.
При создании индекса можно задать порядок автоматической сортировки значений в столбцах — в порядке возрастания ASC (по умолчанию), или в порядке убывания DESC. Для разных столбцов можно задавать различный порядок сортировки.
Пример 3. Создание индекса.
Пусть для таблицы ЕМР, имеющей поля: NAME (имя), SAL (зарплата), MGR (руководитель) и DEPT (отдел), нужно создать индекс main_indx для сортировки имен в алфавитном порядке и убыванию размеров зарплаты. Оператор создания индекса может иметь вид:
CREATE INDEX main_indx ON emp (name, sal DESC).
5. Оператор удаления индекса имеет формат вида:
DROP INDEX <имя индекса>
Этот оператор позволяет удалять созданный ранее индекс с соответствующим именем. Так, например, для уничтожения индекса main_indx к таблице emp достаточно записать оператор DROP INDEX main_indx.
6. Оператор создания представления имеет формат вида:
CREATE VIEW <имя представления>
[(<имя столбца> [,<имя столбца> ]... )]
AS <оператор SELECT>
Данный оператор позволяет создать представление. Если имена столбцов в представлении не указываются, то будут использоваться имена столбцов из запроса, описываемого соответствующим оператором SELECT.
Пример 4. Создание представления
Пусть имеется таблица companies описания производителей товаров с полями: comp_id (идентификатор компании), comp_name (название организации), comp_address (адрес) и phone (телефон), а также таблица goods производимых ров с полями: type (вид товара), comp_id (идентификатор компании), name нание товара) и price (цена товара). Таблицы связаны между собой по полю comp_ id. Требуется создать представление герг с краткой информацией о товарах и их производителях: вид товара, название производителя и цена товара. Оператор определения представления может иметь следующий вид:
CREATE VIEW
repr
AS
SELECT
goods.type, companies.comp_name, goods.price
FROM
goods, companies
WHERE
goods.comp_id == companies.comp_id
7. Оператор удаления представления имеет формат вида:
DROP VIEW <имя представления>
Оператор позволяет удалить созданное ранее представление. Заметим, что удаление представления таблицы, участвующие в запросе, удалению не подлежат. Удаление представления repr производится оператором вида:
Drop VIEW repr.
8. Оператор выборки записей имеет формат вида:
SELECT[ALL DISTINCT]
<список данных>
FROM <список таблиц>
[WHERE <условие выборки>]
[GROUP BY <имя столбца> [,<имя столбца>] ... ]
[HAVING <условие поиска>]
[ORDER BY <спецификация> [,<спецификация>] ...]
Это наиболее важный оператор из всех операторов SQL. Функциональные возможности его огромны. Рассмотрим основные из них.
Оператор SELECT позволяет производить выборку и вычисления над данными из одной или нескольких таблиц. Результатом выполнения оператора является ответная таблица, которая может иметь (ALL), или не иметь (DISTINCT) повторяющиеся строки. По умолчанию в ответную таблицу включаются все строки, в том числе и повторяющиеся. В отборе данных участвуют записи одной или нескольких таблиц, перечисленных в списке операнда FROM.
Список данных может содержать имена столбцов, участвующих в запросе, а также выражения над столбцами. В простейшем случае в выражениях можно записывать имена столбцов, знаки арифметических операций (+,—,*,/), константы и круглые скобки. Если в списке данных записано выражение, то наряду с выборкой данных выполняются вычисления, результаты которого попадают в новый (создаваемый) столбец ответной таблицы.
При использовании в списках данных имен столбцов нескольких таблиц для указания принадлежности столбца некоторой таблице применяют конструкцию вида: <имя таблицы>.<имя столбца>.
Операнд WHERE задает условия, которым должны удовлетворять записи в результирующей таблице. Выражение <условие выборки> является логическим. Его элементами могут быть имена столбцов, операции сравнения, арифметические операции, логические связки (И, ИЛИ, НЕТ), скобки, специальные функции LIKE, NULL, IN и т. д.
Операнд GROUP BY позволяет выделять в результирующем множестве записей группы.
Группой являются записи с совпадающими значениями в столбцах, перечисленных за ключевыми словами GROUP BY. Выделение групп требуется для использования в логических выражениях операндов WHERE и HAVING, а также для выполнения операций (вычислений) над группами.
В логических и арифметических выражениях можно использовать следующие групповые операции (функции): AVG (среднее значение в группе), МАХ (максимальное значение в группе), MIN (минимальное значение в группе), SUM (сумма значений в группе), COUNT (число значений в группе).
Операнд HAVING действует совместно с операндом GROUP BY и используется для дополнительной селекции записей во время определения групп. Правила записи <условия поиска> аналогичны правилам формирования <условия выборки> операнда WHERE.
Операнд ORDER BY задает порядок сортировки результирующего множества. Обычно каждая <спецификация> аналогична соответствующей конструкции оператора CREATE INDEX и представляет собой пару вида: <имя столбца> [ ASC | DESC ].
Одной из таких конструкций, например, являются так называемые подзапросы. Они позволяют формулировать вложенные запросы, когда результаты одного оператора SELECT используются в логическом выражении условия выборки операнда WHERE другого оператора SELECT.
Вторым примером более сложной формы оператора SELECT является оператор, в котором отобранные записи в дальнейшем предполагается модифицировать (конструкция FOR UPDATE OF). СУБД после выполнения такого оператора обычно блокирует (защищает) отобранные записи от модификации их другими пользователями.
Еще один случай специфического использования оператора SELECT — выполнение объединений результирующих таблиц при выполнении нескольких операторов SELECT (операнд UNION).
Пример 5. Выбор записей.
Для таблицы ЕМР, имеющей поля: NAME (имя), SAL (зарплата), MGR (руководитель) и DEPT (отдел), требуется вывести имена сотрудников и размер их зарплаты, увеличенный на 100 единиц. Оператор выбора можно записать следующим образом:
SELECT name, sal+100
FROM emp.
Пример 6. Выбор с условием.
Вывести названия таких отделов таблицы ЕМР, в которых в данный момент отсутствуют руководители. Оператор SELECT для этого запроса можно записать так:
SELECT dept
FROM emp
WHERE mgr is NULL.
Пример 7. Выбор с группированием.
Пусть требуется найти минимальную и максимальную зарплаты для каждого из отделов (по таблице ЕМР). Оператор SELECT для этого запроса имеет вид:
SELECT dept, MIN(sal), MAX(sal)
FROM emp
GROUP BY dept.
9. Оператор изменения записей имеет формат вида:
UPDATE <имя таблицы>
SET <имя столбца> = {<выражение> , NULL }
[, SET <имя столбца> = {<выражение> , NULL } ... ]
[WHERE <условие>|
Выполнение оператора UPDATE состоит в изменении значений в определенных операндом SET столбцах таблицы для тех записей, которые удовлетворяют условию, заданному операндом WHERE.
Новые значения полей в записях могут быть пустыми (NULL), либо вычисляться в соответствии с арифметическим выражением. Правила записи арифметических и логических выражений аналогичны соответствующим правилам оператора SELECT.
Пример 8. Изменение записей.
Пусть необходимо увеличить на 500 единиц зарплату тем служащим, которые получают не более 6000 (по таблице ЕМР). Запрос, сформулированный с помощью оператора SELECT, может выглядеть так:
UPDATE emp
SET sal = 6500 WHERE sal <= 6000.
10. Оператор вставки новых записей имеет форматы двух видов:
INSERT INTO <имя таблицы>
[(<список столбцов>)]
VALUES (<список значений>)
и
INSERT INTO <имя таблицы>
[(<список столбцов>)]
<предложение SELECT>
В первом формате оператор INSERT предназначен для ввода новых записей с заданными значениями в столбцах. Порядок перечисления имен столбцов должен соответствовать порядку значений, перечисленных в списке операнда VALUES. Если <список столбцов> опущен, то в <списке значений> должны быть перечислены все значения в порядке столбцов структуры таблицы.
Во втором формате оператор INSERT предназначен для ввода в заданную таблицу новых строк, отобранных из другой таблицы с помощью предложения SELECT.
Пример 9. Ввод записей.
Ввести в таблицу ЕМР запись о новом сотруднике. Для этого можно записать такой оператор вида:
INSERT INTO emp
VALUES (“Ivanov”, 7500, “Lee”, “cosmetics”).
11. Оператор удаления записей имеет формат вида:
DELETE FROM <имя таблицы>
[WHERE <условие>]
Результатом выполнения оператора DELETE является удаление из указанной таблицы строк, которые удовлетворяют условию, определенному операндом WHERE. Если необязательный операнд WHERE опущен, т.е. условие отбора удаляемых записей отсутствует, удалению подлежат все записи таблицы.
Пример 10. Удаление записей.
В связи с ликвидацией отдела игрушек (toy), требуется удалить из таблицы ЕМР всех сотрудников этого отдела. Оператор DELETE для этой задачи будет выглядеть так:
DELETE FROM emp
WHERE dept = “toy”.
В заключение отметим, что, по словам Дейта, язык SQL является гибридом реляционной алгебры и реляционного исчисления. В нем имеются элементы алгебры (оператор объединения UNION) и исчисления (квантор существования EXISTS). Кроме того, язык SQL обладает реляционной полнотой.
Выводы:
Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL - Structured Query Language.
2. Язык SQL позволяет определять схему реляционной базы данных; манипулировать данными, содержит специальные средства определения ограничений целостности базы данных, позволяют определять так называемые представления БД, производить авторизацию доступа к объектам базы данных и др.
3. select − предложение языка SQL − извлекает строки, столбцы и производные значения (например, вычисляемые выражения) из одной или нескольких таблиц БД.
4. При формировании запроса select пользователь описывает ожидаемый набор данных, не указывает, какие физические операции должны быть произведены для получения этого набора.
Задания для самоконтроля
Покажите что с помощью вырахения((S[П#] MINUS (SP WHERE Д#=’P2’)[П])JOIN S)[Имя] реляционной алгебры можно получить имена поставщиков , которые не поставляют деталь Р2.
Сформулируйте вопрос, в котором требуется определить названия фирм, которые поставляют товары, отличные от товаров, предлагаемых фирмой Pencraft.
Что будет трезультотаом выполнения запроса
UPDATE emp
SET sal = 6500 WHERE sal <= 6000.
Теоретические вопросы для самоконтроля:
Охарактеризуйте язык SQL.
Что позволяет определить язык SQL?
Что позволяет сделать select −предложение языка SQL?
Указывает ли пользователь при формировании запроса select, какие физические операции должны быть произведены?
Какие основные фразы включает полный синтаксис стандартного предложения select?
Каково краткое назначение основных фраз предложения select?
Как осуществить выборку без использования фразы WHERE?
Зачем применяются ключевые слова all, distinct?
С какой целью используется символ (*) после ключевого слова SELECT?
Как во фразу select включить выражения для вычисления числовых значений, текстовые выражения, числовые или текстовые константы?
3. Разработка и эксплуатация серверной частиСоздание, модификация и удаление таблиц
Когда становится очевидно, что старая структура таблицы уже не соответствует текущим задачам появляется необходимость ее изменения. Появилась какая-то дополнительная информация, или таблица содержит данные, ставшие уже избыточными. Существующие столбцы оказались слишком малы, или опыт работы с таблицей показал, что они непредусмотрительно были объявлены слишком большими и для экономии пространства и оптимизации запросов их требуется уменьшить. Возможно, просто была допущена ошибка в имени столбца при создании таблицы. Для этого у нужна модификация таблиц.
Далее в занятии рассматриваются использование операторов для модификации структуры таблиц; приемы эффективной работы с клиентской программой mysql. Показано, как просто подключиться к серверу и вводить запросы, копируя их из одного черновика.
Оператор ALTER TABLE в СУБД MySQL обладает достаточно универсальными возможностями.
Оператор ALTER TABLE может пригодиться в том случае, когда становится очевидно, что старая структура таблицы уже не соответствует текущим задачам. Появилась какая-то дополнительная информация, или таблица содержит данные, ставшие уже избыточными. Существующие столбцы оказались слишком малы, или опыт работы с таблицей показал, что они непредусмотрительно были объявлены слишком большими и для экономии пространства и оптимизации запросов их требуется уменьшить. Возможно, просто была допущена ошибка в имени столбца при создании таблицы с помощью оператора CREATE TABLE.
Вот несколько таких ситуаций.
Вы ведете на Web-сервере анкету и сохраняете результаты каждого опроса как запись таблицы. Затем вы решили модифицировать анкету и добавить в нее несколько вопросов. Для этого необходимо добавить столбцы в таблицу для того, чтобы сохранять новые вопросы.
Предположим, что вы участвуете в научном проекте. Каждому эксперименту вы присваиваете номер и сохраняете его в столбце с параметром AUTO_INCREMENT. По всем оценкам, исследования должны длиться достаточно долго. Количество регистрирующих записей должно составлять около 50000. Вы совершенно справедливо приняли решение для хранения номеров опытов выбрать тип UNSIGNED SMALLINT, который может хранить до 65535 значений. Однако по полученным результатам проект был признан успешным и его финансирование возобновилось. По предварительным оценкам может быть сделано еще 50000 записей. Необходимо изменить имеющийся тип столбца на более вместительный.
Размеры столбцов могут меняться и в другую сторону. Предположим, был создан столбец типа CHAR (255), но в процессе работы с таблицей оказалось, что длина значений в этом столбце не превышает 100 символов. Длину столбца можно уменьшить.
Инструкция ALTER TABLE позволяет менять определение таблицы. Для этого необходимо иметь привилегии ALTER, CREATE и INSERT.
Общий ее формат таков:
ALTER [IGNORE] TABLE имя спецификация[, спецификация ...]
Поскольку программа MySQL способна вносить незаметные изменения в определения таблиц, существует вероятность того, что инструкция ALTER не возымеет никакого эффекта.
В качестве параметров инструкция ALTER TABLE принимает имя таблицы и как минимум одну спецификацию изменений. Спецификации отделяются друг от друга запятыми, и подобная форма записи является расширением стандарта языка SQL.
Флаг IGNORE заставляет программу MySQL игнорировать дубликаты, если данные, уже находящиеся в таблице, конфликтуют с ее новым определением. Например, когда столбец, содержащий дублирующиеся данные, объявляется первичным ключом, то по умолчанию программа отказывается вносить изменения. При наличии флага IGNORE изменения будут учтены, а все дублирующиеся записи, кроме одной, - выброшены.
В случае добавления нового столбца соответствующие ячейки существующих записей будут заданы равными NULL, если столбец это допускает, или же в них будут записаны значения по умолчанию.
Ниже описаны все возможные варианты спецификаций.
ADD [COLUMN] определение [FIRST | AFTER столбец]
С помощью этой спецификации к таблице добавляется новый столбец. Формат определения столбца должен быть таким же, как и в инструкции CREATE TABLE. По умолчанию столбец добавляется в конец списка, но с помощью ключевого слова FIRST его можно объявить первым, а с помощью предложения AFTER - стоящим после заданного столбца.
Далее демонстрируется добавление двух столбцов, располагаемых в определенном порядке. Возможно, эти столбцы не были учтены при создании таблицы.
Добавление столбцов в заданном порядке
mysql> ALTER TABLE user
-> ADD middleName VARCHAR(32) AFTER username,
-> ADD prefix VARCHAR(32) FIRST;
Другая причина добавления столбцов - введение первичного ключа. Так, далее в таблицу вставляется столбец-счетчик. В результате каждая строка получит уникальный идентификатор в поле ID.
Задание: Произведите соединение с сервером 192.168.16.50 (user- stud, password- 111, база данных- xxpovgg) с помощью клиентской программы mysql. Добавьте в таблицу customers 2 столбца в определенном порядке
Добавление первичного ключа
mysql> ALTER TABLE user
-> ADD ID INT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST;
ADD [COLUMN] (определение, определение, ...)
С помощью этой спецификации в конец списка столбцов добавляется группа новых столбцов. Определения столбцов разделяются запятыми.
mysql> ALTER TABLE address
-> ADD PRIMARY KEY(ID);
ADD UNIQUE [имя] (столбец, ...)
Эта спецификация налагает на заданные столбцы ограничение уникальности. Если в столбцах содержатся дублирующиеся значения, инструкция ALTER завершится неудачей. Воспользуйтесь флагом IGNORE, чтобы вызвать принудительное изменение.
ALTER [COLUMN] столбец DROP DEFAULT
С помощью этой спецификации из определения столбца удаляется описание значения по умолчанию. Для столбца будет выбрано новое стандартное значение на основании его типа и допустимости значений NULL. Если значения NULL разрешены, выбор будет сделан в их пользу. В противном случае будет выбрано значение 0 или пустая строка. Задание: Добавьте в таблицу customers первичный ключ uid INT(11)- Автоматически увеличиваемый счетчик, содержащий уникальный идентификатор покупателя.
Добавление группы столбцов
mysql> ALTER TABLE user ADD (
-> middleName VARCHAR(32),
-> prefix VARCHAR(32)
-> );
ADD [CONSTRAINT имя] FOREIGN KEY имя (столбец, ...) ссылка
Эта спецификация существует для совместимости с другими СУБД. Факт существования столбцов не проверяется, а информация об ограничении не сохраняется в таблице. Разработчики MySQL добавили функции хранения внешних ключей в версию 4.0.
ADD FULLTEXT [имя] (столбец, ...)
Эта спецификация предназначена для добавления к указанным столбцам полнотекстового индекса.
ADD {KEY | INDEX} [имя] (столбец, ...)
Эта спецификация позволяет добавить индекс к одному или нескольким столбцам. Ключевые слова KEY и INDEX являются синонимами. Аналогичную функцию выполняет также инструкция CREATE INDEX.
Добавление индекса
mysql> ALTER TABLE user
-> ADD INDEX (username);
ADD PRIMARY KEY (столбец, ...)
С помощью этой спецификации к таблице добавляется первичный ключ. У таблицы может быть только один такой ключ, поэтому существующий ключ необходимо предварительно удалить.
Отмена значений по умолчанию
mysql> ALTER TABLE address
-> ALTER prefix DROP DEFAULT;
ALTER [COLUMN] столбец SET DEFAULT литерал
Эта спецификация назначает столбцу значение по умолчанию. Подобное изменение не затрагивает существующие записи.
Задание значения по умолчанию
CHANGE [COLUMN] столбец определение
С помощью этой спецификации меняется определение столбца: его имя, размерность и тип. Подобная возможность не предусмотрена в стандарте языка SQL. Другие СУБД тоже допускают модификацию определений столбцов, но программа MySQL является наиболее гибкой в этом плане.
MySQL пытается привести существующие данные к новому типу. Если столбец проиндексирован, его размерность не может стать меньше, чем размерность индекса. Например, наличие индекса первых 16 символов столбца типа VARCHAR означает, что размерность столбца тоже должна составлять не менее 16 символов.
Далее показано, как тип столбца меняется с VARCHAR (32) на ENUM. Обратите внимание на то, что имя столбца повторяется дважды. Это не ошибка. Первый раз идентифицируется существующий столбец, а второй раз дается его новое определение. Задание: Отмените значения по умолчанию в столбце password таблицы customers, входящую в базу данных xxpovgg.
Изменение определения столбца
mysql> ALTER TABLE address
-> CHANGE prefix
-> prefix ENUM('Mr.', 'Mrs.', 'Miss', 'Ms');
DROP [COLUMN] столбец
Эта спецификация предназначена для удаления столбца из таблицы и не является частью стандарта языка SQL. Индексы, охватывающие удаляемый столбец, автоматически перестраиваются. Если в индекс входил только один этот столбец, индекс удаляется. Задание: Измените тип столбца lstname VARCHAR(5) [ таблицы customers, входящую в базу данных xxpovgg ] на lastname CHAR(15).
Удаление столбца
mysql> ALTER TABLE address
-> DROP middleName;
DROP PRIMARY KEY
Эта спецификация аналогична предыдущей, но удаляется не произвольный столбец, а лишь первичный ключ. Если для таблицы не задан первичный ключ, удаляется первый уникальный индекс.
DROP INDEX индекс
С помощью этой спецификации удаляется указанный индекс. Подобная возможность не предусмотрена в стандарте.
Удаление индекса
mysql> ALTER TABLE address
-> DROP INDEX lastName;
MODIFY [COLUMN] определение
Эта спецификация служит для изменения определения столбца, кроме его имени. Данная возможность появилась в MySQL под влиянием СУБД Oracle. Задание: Удалите столбец otch [ таблицы customers, входящую в базу данных xxpovgg]
Модификация определения столбца
mysql> ALTER TABLE address
-> MODIFY prefix ENUM('Mr.','Mrs.','Miss1,'Ms');
ORDER BY столбец
Данная спецификация предназначена для изменения физического порядка записей по значениям заданного столбца. В некоторых случаях это позволяет ускорить выполнение запросов к таблице. Обратите внимание на то, что переупорядочение записей происходит лишь один раз. Последующие операции вставки и удаления приведут к изменению порядка записей.
Задание: Произведите модификацию любого столбца таблицы customers.
Ответьте на вопрос: Чем отличается команда изменения определения столбца и модификация определения столбца?
RENAME [TO] имя
Эта спецификация позволяет менять имя таблицы. Аналогичную функцию выполняет инструкция RENAME TABLE.
Изменение имени таблицы
mysql> ALTER TABLE address
-> RENAME addr;
Задание: Переименуйте таблицу customers на pokupateli.
Получение информации о базах данных и таблицах
Познакомимся с несколькими операторами, позволяющими получить информацию о базах данных и таблицах. Они полезны для отслеживания структуры базы данных, особенно для предварительного просмотра свойств столбцов таблицы перед внесением изменений в их структуру с помощью оператора ALTER TABLE.
Для получения самой разноплановой информации о базе данных и таблицах можно воспользоваться оператором SHOW.SHOW DATABASESПеречень баз данных на сервере
SHOW TABLESПеречень таблиц в текущей базе данных
SHOW TABLES FROM имя_базыПеречень таблиц в указанной базе данных
SHOW COLUMNS FROM имя_таблицыОтображение информации о столбцах в указанной таблице
SHOW INDEX FROM имя_таблицыОтображение информации об индексах в указанной таблице
SHOW TABLE STATUSОтображение описательной информации о таблицах в текущей базе данных
SHOW TABLE STATUS FROM имя_базыОтображение описательной информации о таблицах в указанной базе данных
Операторы DESCRIBE имя_таблицы и EXPLAIN имя_таблицы являются синонимами оператора SHOW COLUMNS FROM имя_таблицы.
Синтаксис приведенных выше операторов:
DESCRIBE
Инструкция DESCRIBE возвращает таблицу, содержащую описание одного или нескольких столбцов заданной таблицы.
Общий формат инструкции таков:
{DESCRIBE | DESC} таблица [столбец | условие_отбора)
Вместо слова DESCRIBE можно указывать его сокращенную форму DESC. В простейшем случае задается только таблица. В результате будет выдано описание каждого ее столбца. Имени таблицы может предшествовать имя базы данных. Допускается указывать конкретный столбец или шаблон имени. Аналогичные результаты выдает инструкция SHOW COLUMNS. Далее приведены результаты инструкции DESCRIBE. В первых двух колонках указаны имя и тип каждого столбца. В колонке "Null" будет стоять YES, если столбец допускает значения NULL. Для столбцов, являющихся частью первичного ключа, в четвертой колонке будет стоять PRI. Если же столбец входит в состав другого индекса, то в этой колонке будет указано NUL. В пятой колонке отображается значение по умолчанию. В последней колонке приводится дополнительная информация о столбце. В частности, здесь указывается, является ли столбец полем-счетчиком.
Инструкция DESCRIBE
mysql> DESCRIBE mysql.user;
SHOW DATABASES
Инструкция SHOW DATABASES возвращает список баз данных, существующих на сервере:
SHOW DATABASES [LIKE шаблон]
Пример инструкции показан далее. В предложении LIKE задается шаблон имен баз данных.
Вывод списка баз данных
mysql> SHOW DATABASES LIKE '%mysql';
Инструкция SHOW TABLES возвращает список таблиц, существующих в указанной базе данных:
SHOW [OPEN] TABLES [FROM база_данных] [LIKE шаблон]
По умолчанию отображаются все таблицы текущей базы данных. Флаг OPEN ограничивает список только открытыми таблицами. В этом случае во втором столбце указывается, сколько раз таблица кэшировалась и использовалась.
Получение списка открытых таблиц
mysql> SHOW OPEN TABLES FROM mysql;
SHOW TABLE STATUS
Инструкция SHOW TABLE STATUS выводит статусную информацию о таблицах. Ее синтаксис таков:
SHOW TABLE STATUS [FROM база_данных] [LIKE шаблон]
В предложении LIKE задается шаблон имен таблиц. Список столбцов возвращаемой таблицы приведен в таблице. Описание каждой таблицы базы данных занимает одну строку.
Статусная информация о таблицах
Auto_incrementСледующее значение поля-счетчика
Avg_row_lengthСредняя длина записи
ChecktimeВремя последнего выполнения инструкции CHECK TABLE
CommentКомментарии, указанные при создании таблицы
CreateoptionsПараметры создания таблицы
CreatetimeВремя создания таблицы
Data_frееЧисло выделенных, но неиспользуемых байтов
Data_lengthДлина файла данных
Index_lengthДлина индексного файла
Max_data_lengthМаксимальная длина файла данных
NameИмя таблицы
RowsЧисло записей в таблице
Row_formatФормат хранения записей: сжатый, динамический или фиксированный
ТуреТип таблицы
UpdatetimeВремя последнего обновления таблицы
SHOW COLUMNS
Инструкция SHOW COLUMNS возвращает описание столбцов таблицы. Она имеет следующий синтаксис:
SHOW [FULL] {COLUMNS|FIELDS}
FROM таблица [FROM база_данных] [LIKE шаблон]
Флаг FULL задает выдачу для каждого столбца информации о привилегиях. Предложение LIKE позволяет отобрать из таблицы только те столбцы, имена которых соответствуют указанному шаблону. Аналогичные результаты выдает инструкция DESCRIBE.
Инструкция SHOW COLUMNS
mysql> SHOW COLUMNS FROM user;
Выводы
. Оператор SELECT , с помощью которого в SQL реализуется язык манипулирования данными, DML, применяется, в частности, для извлечения данных из одной таблицы.
2. В SQL существует фраза where, позволяющая указать критерии для отбора нужных строк.
3. Кроме традиционных операторов сравнения (= | <> | < | <= | > | >=), в WHERE-фразе используются условия between (между), like (похоже на), in (принадлежит), is null (не определено) и exists (существует), которые могут предваряться оператором not (не). Критерий отбора строк формируется из одного или нескольких условий, соединенных логическими операторами: and; or; and not; or not.
4. С помощью between ... and ... (находится в интервале от ... до ...) можно отобрать строки, в которых значение какого-либо столбца находится в заданном диапазоне.
5. Оператор like позволяет указывать строковый шаблон для проверки на совпадение в предложениях select, insert, update и delete. Строковый шаблон может включать обобщающие символы: символ _ (подчеркивание) заменяет любой одиночный символ; символ % (процент) заменяет любую последовательность из N символов (где n может быть нулем).
6. Фраза упорядочения ORDER BY позволяет указать, что выражение для сортировки должно возвращаться в восходящем (asc) или нисходящем (desc) порядке.
7. В SQL существует ряд специальных стандартных функций (агрегатных SQL-функций). Каждая из этих функций оперирует совокупностью значений столбца некоторой таблицы и создает единственное значение: count− число значений; sum− сумма значений; avg− среднее значение; min− минимальное значение; мах− максимальное значение в столбце.
8. Фраза having играет такую же роль для групп, что и фраза where для строк: она используется для исключения групп точно так же, как where используется для исключения строк. Эта фраза включается в предложение лишь при наличии фразы group by, а выражение в having должно принимать единственное значение для группы.
Задание: Перечисленные выше инструкции поэкспериментируйте на своей базе данных xxpovgg.
4 Планирование и реализация индексовИндекс и ключ. Создание, перестройка и удаление индекса.
Индексы играют большую роль в базах данных, так как это основной способ ускорения их работы. Обычно записи в таблице располагаются в хаотическом порядке. Для того, чтобы найти нужную запись, необходимо сканировать всю таблицу, на что уходит большое количество времени. Идея индексов состоит в том, чтобы создать для столбцов копию, которая постоянно будет поддерживаться в отсортированном состоянии. Это позволяет очень быстро осуществлять поиск по такому столбцу, так как заранее известно, где необходимо искать значение. Обратной стороной медали является то, что добавление или удаление записи требует дополнительного времени на сортировку столбца, кроме того, создание копии увеличивает объем памяти, необходимый для размещения таблицы на жестком диске. На данном занятии вы рассмотрите основные команды пользовательских программ и научитесь производить различные операции над индексами.
Добавление первичного ключа
mysql> ALTER TABLE user
-> ADD ID INT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST;
ADD [COLUMN] (определение, определение, ...)
С помощью этой спецификации в конец списка столбцов добавляется группа новых столбцов. Определения столбцов разделяются запятыми.
mysql> ALTER TABLE address
-> ADD PRIMARY KEY(ID);
ADD UNIQUE [имя] (столбец, ...)
Эта спецификация налагает на заданные столбцы ограничение уникальности. Если в столбцах содержатся дублирующиеся значения, инструкция ALTER завершится неудачей. Воспользуйтесь флагом IGNORE, чтобы вызвать принудительное изменение.
ALTER [COLUMN] столбец DROP DEFAULT
С помощью этой спецификации из определения столбца удаляется описание значения по умолчанию. Для столбца будет выбрано новое стандартное значение на основании его типа и допустимости значений NULL. Если значения NULL разрешены, выбор будет сделан в их пользу. В противном случае будет выбрано значение 0 или пустая строка. Задание: Добавьте в таблицу customers первичный ключ uid INT(11)- Автоматически увеличиваемый счетчик, содержащий уникальный идентификатор покупателя.
Добавление группы столбцов
mysql> ALTER TABLE user ADD (
-> middleName VARCHAR(32),
-> prefix VARCHAR(32)
-> );
ADD [CONSTRAINT имя] FOREIGN KEY имя (столбец, ...) ссылка
Эта спецификация существует для совместимости с другими СУБД. Факт существования столбцов не проверяется, а информация об ограничении не сохраняется в таблице. Разработчики MySQL добавили функции хранения внешних ключей в версию 4.0.
ADD FULLTEXT [имя] (столбец, ...)
Эта спецификация предназначена для добавления к указанным столбцам полнотекстового индекса.
ADD {KEY | INDEX} [имя] (столбец, ...)
Эта спецификация позволяет добавить индекс к одному или нескольким столбцам. Ключевые слова KEY и INDEX являются синонимами. Аналогичную функцию выполняет также инструкция CREATE INDEX.
Добавление индекса
mysql> ALTER TABLE user
-> ADD INDEX (username);
ADD PRIMARY KEY (столбец, ...)
С помощью этой спецификации к таблице добавляется первичный ключ. У таблицы может быть только один такой ключ, поэтому существующий ключ необходимо предварительно удалить.
Отмена значений по умолчанию
mysql> ALTER TABLE address
-> ALTER prefix DROP DEFAULT;
ALTER [COLUMN] столбец SET DEFAULT литерал
Эта спецификация назначает столбцу значение по умолчанию. Подобное изменение не затрагивает существующие записи.
Задание значения по умолчанию
CHANGE [COLUMN] столбец определение
С помощью этой спецификации меняется определение столбца: его имя, размерность и тип. Подобная возможность не предусмотрена в стандарте языка SQL. Другие СУБД тоже допускают модификацию определений столбцов, но программа MySQL является наиболее гибкой в этом плане.
MySQL пытается привести существующие данные к новому типу. Если столбец проиндексирован, его размерность не может стать меньше, чем размерность индекса. Например, наличие индекса первых 16 символов столбца типа VARCHAR означает, что размерность столбца тоже должна составлять не менее 16 символов.
Далее показано, как тип столбца меняется с VARCHAR (32) на ENUM. Обратите внимание на то, что имя столбца повторяется дважды. Это не ошибка. Первый раз идентифицируется существующий столбец, а второй раз дается его новое определение. Задание: Отмените значения по умолчанию в столбце password таблицы customers, входящую в базу данных xxpovgg.
Изменение определения столбца
mysql> ALTER TABLE address
-> CHANGE prefix
-> prefix ENUM('Mr.', 'Mrs.', 'Miss', 'Ms');
DROP [COLUMN] столбец
Эта спецификация предназначена для удаления столбца из таблицы и не является частью стандарта языка SQL. Индексы, охватывающие удаляемый столбец, автоматически перестраиваются. Если в индекс входил только один этот столбец, индекс удаляется.
Теоретические вопросы для самоконтроля:
Какая команда предписывает MySQL использовать базу данных с именем db_name в последующих запросах по умолчанию.
Синтаксис команды, представляющий собой сокращенный вариант команды SHOW COLUMNS FROM.
С помощью каких команд можно просмотреть структуру таблицы.
Перечислите виды индексов.
Варианты создания первичного ключа.
Команда создания первичного ключа при создании таблицы.
5 Внешние ключи и ссылочная целостностьОбеспечение непротиворечивости и целостности данных
Данное занятие включает рассмотрение вопросов выполнения основных операций над данными и сохранение целостности базы данных, нарушения ссылочной целостности.
Связь между таблицами связана на понятиях первичного ключа и внешнего ключа.
Первичным ключом (ключом отношения, ключевым атрибутом) называется атрибут отношения, однозначно идентифицирующий каждый из его кортежей. Например, в отношении СОТРУДНИК(ФИО, Отдел, Должность, Д_Рождения) ключевым является атрибут "ФИО".
Ключ может быть составным (сложным), т. е. состоять из нескольких атрибутов.
Каждое отношение обязательно имеет комбинацию атрибутов, которая может служить ключом. Ее существование гарантируется тем, что отношение - это множество, которое не содержит одинаковых элементов - кортежей. Т. е. в отношении нет повторяющихся кортежей, а это значит, что по крайней мере вся совокупность атрибутов обладает свойством однозначной идентификации кортежей отношения. Во многих СУБД допускается создавать отношения, не определяя ключи.
Возможны случаи, когда отношение имеет несколько комбинаций атрибутов, каждая из которых однозначно определяет все кортежи отношения. Все эти комбинации атрибутов являются возможными ключами отношения. Любой из возможных ключей может быть выбран как первичный.
Пусть в отношении R1 имеется не ключевой атрибут А, значения которого являются значениями ключевого атрибута В другого отношения R2. Тогда говорят, что атрибут А отношения R 1 есть внешний ключ.
Как правило, изменения базы данных, обусловленные внешними явлениями, требуют выполнения нескольких запросов. В промышленных базах данных одно событие может затрагивать гораздо большее число таблиц и требовать выполнения многочисленных запросов. Если на этапе выполнения одного из запросов происходит сбой, это может нарушить целостность базы данных.
Так, ключ catalogs . id _ catalog является первичным ключом таблицы catalogs , а ключ products . id _ catalog — внешний ключ таблицы products . Совокупность ключей catalogs . id _ catalog и products . id _ catalog образует связь между таблицами catalogs и products.
Содержимое таблицы catalogs представлено в листинге 1.
Листинг 1. Содержимое каталога catalogs
mysql > SELECT * FROM catalogs;

Пусть в связи с реорганизацией электронного магазина требуется удалить запись каталога "Жесткие диски". Для этого можно прибегнуть к оператору DELETE (листинг 2).
Листинг 2. Удаление каталога "Жесткие диски"
mysql > DELETE FROM catalogs WHERE name = ' Жесткие диски ';
mysql >SELECT * FROM catalogs ;
После удаления раздела с первичным ключом id _ catalog , равным 4, в таблице products остались товарные позиции, которые принадлежат удаленному разделу (листинг 3).
Листинг 3. Товарные позиции, которые не принадлежат ни одному элементу каталога
mysql> SELECT id_product, id_catalog, name FROM products WHERE id_catalog = 4;

Такую ситуацию называются нарушением ссылочной целостности. В рамках реляционной модели таблицу catalogs называют предком, a products — потомком. Всего существует четыре типа изменений базы данных, которые могут нарушить ссылочную целостность.
Добавление новой строки-потомка. Добавление в электронный магазин товарной позиции, не принадлежащей ни одному из элементов каталога, т. е. если поле id _ catalog таблицы products принимает, например, значение 104. Следует отметить, что добавление в таблицу catalogs строки, для которой не имеется соответствия в таблице products , не вызывает противоречий, т. к. существование каталога без товарных позиций вполне допустимое явление.
Обновление внешнего ключа в строке-потомке. Это та же проблема, что и в предыдущей ситуации, но выраженная в иной форме. При обновлении поля id _ catalog таблицы products , т. е. при переносе товарной позиции от одного элемента каталога в другой необходимо, чтобы каталог с новым значением id_ catalog существовал в таблице catalogs , иначе товарная позиция опять повисает в воздухе.
Удаление строки-предка. Эта ситуация описана ранее в листингах 2 и 3. Удаление элемента каталога из таблицы catalogs приводит к тому, что ряд товарных позиций принадлежат к несуществующей позиции каталога.
Обновление первичного ключа в строке-предке. Эта иная форма проблемы, рассмотренной в предыдущем пункте. При обновлении первичного ключа каталога у товарных позиций, которые относятся к данному каталогу, внешний ключ не меняется.
Средства поддержки ссылочной целостности языка SQL позволяют обрабатывать каждую из четырех описываемых ситуаций.
Первая проблема (добавление новой строки-потомка) решается путем проверки значений в столбцах внешнего ключа перед выполнением оператора insert . Если передаваемые оператору insert значения не равны ни одному из значений первичного ключа, то возвращается ошибка добавления записи.
Вторая проблема (обновление таблицы-потомка) решается аналогично путем проверки нового значения внешнего ключа. Если такого значения среди первичных ключей таблицы-предка не обнаружено, возвращается ошибка.
Третья проблема (удаление строки-предка) может потребовать различной реакции в зависимости от контекста и предметной области. Так, применительно к электронному магазину при удалении записи каталога из таблицы catalogs могут быть применены следующие действия:
не удалять элемент каталога до тех пор, пока принадлежащие ему товарные позиции из таблицы products не будут соотнесены с другой записью каталога;
автоматически удалить все товарные позиции таблицы products , принадлежащие удаляемому элементу каталога;
для товарных позиций, принадлежащих удаляемому элементу каталога, в поле id _ catalog поместить значение NULL , которое будет сигнализировать о том, что элемент каталога для этих товарных позиций не известен;
для товарных позиций, принадлежащих удаляемой записи каталога, в поле id _ catalog поместить значение по умолчанию, отличное от NULL , например, значение id _ catalog для элемента каталога "Разное".
Точно такие же проблемы возникают в четвертой ситуации (обновление первичного ключа в таблице-предке). Для задания всех этих действий в стандарте SQL предусмотрены специальные ключевые слова. До этого момента при определении структуры таблицы явным образом обозначался только первичный ключ. Однако для того чтобы задать правила удаления и обновления, требуется также явное указание вторичного ключа, задаваемое конструкцией foreign key , которая имеет следующий синтаксис:
FOREIGN KEY [name_key] {coll, ...) REFERENCES tJbJ (tbl_col, ...)
[ON DELETE {CASCADE|SET NULL|NO ACTION|RESTRICT|SET DEFAULT}]
[ON UPDATE {CASCADE|SET NULL|NO ACTION|RESTRICT|SET DEFAULT}]
Данная конструкция позволяет задать внешний ключ с необязательным именем пате_кеу на столбцах, которые перечисляются в круглых скобках (один или несколько). Ключевое слово references указывает таблицу tbl , на которую ссылается внешний ключ, в круглых скобках задаются имена столбцов. Необязательные конструкции on delete и on update позволяют определить поведение СУБД при удалении и обновлении строк из таблицы-предка, соответственно. Параметры, следующие за этими ключевыми словами, имеют следующие значения:
cascade — при удалении или обновлении записи, содержащей первичный ключ, записи со ссылками на это значение в таблице-потомке удаляются или обновляются автоматически;
set null — при удалении или обновлении записи, содержащей первичный ключ, в таблице-потомке значения внешнего ключа, ссылающегося на таблицу-предка, устанавливаются в null ;
no action — при удалении или обновлении записей, содержащих первичный ключ, с таблицей-потомком никаких дополнительных действий не производится;
restrict — если в таблице-потомке имеются записи, ссылающиеся на первичный ключ таблицы-предка, при удалении или обновлении записей с таким первичным ключом возвращается ошибка. СУБД не позволяет изменять или удалять запись с первичным ключом, пока не останется ни одной ссылки из таблицы-потомка;
set default -— согласно стандарту SQL , при удалении или обновлении первичного ключа в таблице-потомке для ссылающихся на него записей в поле внешнего ключа должно устанавливаться значение по умолчанию. Однако в СУБД MySQL это ключевое слово зарезервировано, но не обрабатывается.
Снабдим таблицы учебной базы данных shop внешними ключами (листинг 4). Следует помнить, что внешние ключи поддерживаются только таблицами типа InnoDB, поэтому все таблицы должны быть преобразованы к данному типу. Это можно осуществить либо при помощи оператора alter table, либо создав таблицы заново с использованием оператора create table .
Создаем 2 таблицы в базе банных base на сервере 192.168.16.90. (stud, 1)
Листинг 4. Создание внешних ключей.
mysql> CREATE TABLE catalogs (
id_catalog int(10) NOT NULL auto_increment,
name tinytext NOT NULL,
PRIMARY KEY (id_catalog)
)
TYPE=InnoDB;
mysql> CREATE TABLE products (id_product int(10)
NOT NULL auto_increment,
name text NOT NULL,
price decimal(7,2) default '0.00',
count int(12),
mark float NOT NULL,
description text,
id_catalog int(10),
primary key (id_product),
FOREIGN KEY (id_catalog) REFERENCES catalogs (id_catalog)
)TYPE=InnoDB;
Добавим записи:
INSERT INTO catalogs (id_catalog, name)
VALUES (1,'Processory'),
(2,'Materinskie platy'),
(3,'Videoadaptery'),
(4,'Jestkie diski'),
(5,'Operativnaya pamyat');
INSERT INTO products (id_product, name, price, count, mark, description, id_catalog) VALUES
(1,'Celeron 1.8',1595,10,3.6,'Processor CeleronR 1.8GHz, 128kb, 478-PGA, 400Mhz, OEM 0.18',1),
В листинге 4 в табличном пространстве InnoDB создаются таблицы catalogs и products . В таблице products поле id _ catalog объявлено как внешний ключ ( foreign key ) с правилом удаления и обновления cascade . Это означает, что обновление таблицы catalogs приводит к автоматическому обновлению таблицы products (листинг 5).
Листинг 5. Каскадное обновление
mysql> UPDATE catalogs SET id_catalog =10 WHERE id_catalog = 4;

mysql> SELECT id_product, id_catalog, name FROM products;
А удаление любого из элементов каталога в таблице catalogs приведет к тому, что все записи таблицы products , поле id _ catalog которых равно первичному ключу удаляемой записи каталога, также будет удалено из таблицы (листинг 6).
Листинг 6. Каскадное удаление
mysql> DELETE FROM catalogs WHERE id_catalog > 2;
mysql> SELECT * FROM catalogs;
mysql> SELECT id_product, id_catalog, name FROM products;
Как видно из листинга 6, удаление записей с первичным ключом приводит к автоматическому удалению ссылающихся на него записей с внешним ключом. Записи с внешними ключами сами могут выступать в качестве ссылок для внешних ключей других таблиц, и один-единственный запрос может осуществлять достаточно сложные преобразования базы данных. Удаление и обновление базы данных, когда таблицы связаны внешним ключом с правилом cascade , называется каскадным удалением или обновлением.
Внешний ключ может рекурсивно ссылаться на записи своей же таблицы . Это часто необходимо, когда требуется моделировать реферальные системы и вложенные каталоги при помощи одной и той же таблицы .
СУБД MySQL позволяет отключить проверку ограничений внешнего ключа. Для этого достаточно установить для системной переменной foreign _ key _ checks значение 0. Установка системных переменных осуществляется при помощи оператора set листинг 7).
Листинг 7. Управление системной переменной foreign _ key _ checks
mysql> SELECT @@foreign _ key _ checks;
Для того чтобы извлечь текущее значение системной переменной, ее имя следует предварить двумя символами @. Более подробно системные переменные и синтаксис оператора set обсуждается.
Оператор SET
Оператор SET позволяет устанавливать системные переменные, которые влияют на работу сервера и клиента. Помимо пользовательских переменных, оператор SET позволяет динамически (без перезапуска сервера) изменять системные и сеансовые переменные. Сервер MySQL поддерживает два типа переменных: глобальные, которые влияют на сервер, и сеансовые, которые влияют на текущее соединение с сервером.
К сожалению, внешние ключи доступны только при использовании таблиц типа InnoDB , которые уступают в скорости таблицам MylSAM . Однако каскадные удаления и обновления можно эмулировать и для других типов таблиц, используя вложенные запросы совместно с операторами delete и update . В листинге 8 представлен запрос, удаляющий из таблицы orders учебной базы данных shop все заказы, которые принадлежат покупателю с фамилией Simdyanov.
Листинг 8. Использование вложенного запроса в операторе DELETE
mysql> SELECT id_order, surname FROM orders, users WHERE orders.id_user = users.id_user;
mysql> DELETE FROM orders WHERE id_user = (SELECT id_user FROM users WHERE surname = ' Simdyanov ')
mysql> SELECT id_order, surname FROM orders, users WHERE orders.id_user = users.id_user;
Вложенный запрос возвращает первичный ключ таблицы users — id _ user для покупателя Simdyanov и подставляет его в условие where внешнего запроса, по которому производится удаление из таблицы orders .
Для таблиц типа MylSAM использование транзакций недоступно. Однако их можно эмулировать при помощи операторов lock tables и unlock tables . В отличие от полноценных транзакций, данные операторы блокируют всю таблицу, в результате чего никто не может работать с таблицами до тех пор, пока они остаются заблокированными. Оператор lock tables выполняет блокировку таблиц, a unlock tables снимает блокировку (листинг 9).
Все таблицы, заблокированные в текущем соединении, разблокируются при повторном вызове оператора lock tables .
Операторы LOCK TABLES И UNLOCK TABLES имеют синонимы LOCK TABLE и UNLOCK TABLE , соответственно.
Листинг 9.. Использование операторов LOCK TABLES И UNLOCK TABLES
mysql> LOCK TABLES catalogs WRITE;
mysql> INSERT INTO catalogs VALUES(NULL,' Переферия ');
mysql> INSERT INTO catalogs VALUES(NULL,' Разное ');
mysql> UNLOCK TABLES;
Листинг 10 демонстрирует блокировку таблицы catalogs на время добавления данных в базу данных. Следует обратить внимание, что после оператора lock tables записывается имя блокируемой таблицы, при снятии блокировки при помощи оператора unlock tables указания имени таблицы уже не требуется. Основная причина применения блокировки таблицы при помощи lock tables — это увеличение скорости обновления таблиц и добавления больших объемов данных.
При использовании блокировок можно явно указать тип блокировки — на чтение ( read ) или на запись ( write ) (листинг 11).
Листинг 11. Детализация типа блокировки
mysql> LOCK TABLES catalogs WRITE;
mysql> INSERT INTO catalogs VALUES(NULL,' Переферия 1 );
mysql> INSERT INTO catalogs VALUES(NULL,' Разное ');
mysql> UNLOCK TABLES catalogs;
mysql> LOCK TABLES catalogs READ;
mysql> INSERT INTO catalogs VALUES(NULL,' Переферия ');
mysql> INSERT INTO catalogs VALUES(NULL,' Разное ');
mysql> UNLOCK TABLES;
Различие между блокировками на чтение ( read ) и запись ( write ) заключается в том что клиент, установивший блокировку на чтение, и остальные клиенты могут только читать из таблицы данные. При блокировке на запись ( write ) установивший ее клиент может как вносить записи в таблицу, так и читать, в то время как доступ других клиентов к таблице блокируется. Причем все остальные клиенты ожидают, когда блокировка будет отменена оператором unlock tables . Следует отметить, что время ожидания может быть значительным и это следует предусмотреть в клиентской программе (листинг 12).
Листинг 12. Время блокировки может быть значительным
mysql> LOCK TABLES products READ; Query OK, 0 rows affected (331.67 sec)
Один оператор lock tables может блокировать сразу несколько таблиц, причем рекомендуется блокировать все таблицы, которые участвуют в запросах внутри блокировки. Это связано с тем, что пока блокировка, установленная lock tables , активна, невозможно получить доступ ни к каким таблицам, которые не были блокированы этим оператором (листинг 13).
Листинг 13. Блокировка нескольких таблиц
mysql> LOCK TABLES catalogs WRITE, products WRITE;
mysql> SELECT * FROM catalogs, products WHERE products.id_catalog = catalogs.id_catalogs
mysql> INSERT INTO catalogs VALUES(NULL,' Разное ');
mysql> UNLOCK TABLES catalogs;
Если запрос обращается к таблице через псевдоним, требуется блокировать таблицу, используя тот же псевдоним. Блокировка таблицы не будет работать, если не указан псевдоним (листинг 14).
Листинг 14.Ошибка при использовании псевдонима
mysql> LOCK TABLES products READ;
mysql> SELECT * FROM products AS p;
ERROR 1100: Table 'p' was not locked with LOCK TABLES
И наоборот, если таблица блокирована по псевдониму, к ней следует обращаться, используя этот псевдоним (листинг 15).
Листинг 15. Обращение к таблице по псевдониму
mysql> LOCK TABLE products AS p READ;
mysql> SELECT * FROM products;
ERROR 1100: Table 'products' was not locked with LOCK TABLES
Блокировки по записи ( write ) обычно имеют более высокий приоритет, чем блокировки по чтению ( read ), чтобы гарантировать, что обновления данных пройдут как можно быстрее. Это означает, что если один или несколько клиентов устанавливают блокировку на чтение ( read ), а затем другой клиент устанавливает блокировку на запись ( write ) по этим же таблицам, то все остальные клиенты будут ожидать, пока блокировка по записи не будет снята.
Можно использовать ключевое слово low _ priority совместно с ключевым словом write, что бы позволить другим клиентам устанавливать блокировку по чтению, пока клиент ожидает возможности установки блокировки по записи (листинг 16).
Листинг 16. Использование ключевого слова LOW_PRIORITY WRITE
mysql> LOCK TABLES catalogs LOW_PRIORITY WRITE;
mysql> INSERT INTO catalogs VALUES(NULL,' Переферия ')
mysql>UNLOCK TABLES catalogs;
Однако при интенсивном обращении к серверу, когда таблицы постоянно блокированы по чтению, клиент, установивший блокировку с низким приоритетом, может не дождаться своей очереди.
Поддержка и управление транзакциями
Изменения базы данных, обусловленные внешними явлениями, требуют выполнения нескольких запросов. Так при покупке товара в электронном магазине shop требуется добавить запись в таблицу orders для данного заказа и уменьшить число товарных позиций на складе.
Например, товар может быть продан, а число товарных позиций на складе не обновлено; деньги могут быть сняты с одного счета, но не переведены на другой и т. п. Чтобы сохранить целостность базы данных, все изменения должны выполняться как единое целое — либо все изменения успешно выполняются, либо в случае сбоя хотя бы одного из изменений база данных принимает состояние, которое было до начала изменений. Это обеспечивается средствами обработки транзакций.
Транзакция — это последовательность операторов SQL , выполняющихся как единая операция, которая не прерывается другими клиентами. То есть пока происходит работа с записями таблицы (их обновление или удаление), никто другой не может получить доступ к этим записям, т. к. СУБД MySQL автоматически блокирует доступ к ним.
Таблицы ISAM , MylSAM и HEAP не поддерживают транзакции . В настоящий момент их поддержка осуществляется только в таблицах BDB и InnoDB .
Транзакции позволяют объединять операторы в группу и гарантировать, что все операции внутри группы будут выполнены успешно. Если часть транзакции выполняется со сбоем, результаты выполнения всех операторов транзакции до места сбоя отменяются, приводя базу данных к виду, в котором она была до выполнения транзакции.
Системы, поддерживающие возможности транзакций, часто еще характеризуют как обеспечивающие свойства ACID ( ACID является сокращением Atomic (атомарный) Consistent (целостный), Isolated (изолированный), Durable (длительный)).
Атомарность. Операторы транзакции формируют единый логический блок, каждый элемент которого невозможно выполнить без выполнения всех остальные элементов блока.
Целостность. База данных является целостной до и после выполнения транзакции.
Изоляция. Отдельные транзакции не влияют на работу друг друга.
Длительность. При выполнении транзакции все ее результаты сохраняются в базе данных.
Для выяснения механизма транзакций рассмотрим ситуацию, которая возможна при работе с электронным магазином shop . Предположим, что два покупателя одновременно начинают покупку процессора Celeron D 320 2.4 GHz , который остался на складе в одном экземпляре (листинг 17).
Листинг 17. Покупка Celeron D 320 2.4 GHz
mysql> SELECT id_product, name, @total := count FROM products WHERE name = 'Celeron D 320 2.4GHz';
Первый покупатель оформляет покупку, при этом происходят следующие события:
При помощи оператора select запрашивается число товарных позиций на складе (листинг 17), которое помещается в переменную © total — дальнейшая регистрация покупки разрешена, если число процессоров больше нуля.
Регистрируется факт покупки в таблице orders — для этого в таблицу вставляется новая запись при помощи оператора insert .
Обновляется количество товарных позиций, доступных на складе, с первичным ключом id _ product = 8 (таблица products ). Для этого из переменной @ total вычитается единица, и полученная цифра присваивается полю count товарной позиции (листинг 18).
Листинг 18. Обновление числа товарных позиций
mysql> UPDATE products SET count = @total - 1 WHERE name = 'Celeron D 320 2.4GHz';
Одновременно второй покупатель начинает оформление покупки. Запрос на выборку количества процессоров для него также возвращает значение 1, которое помещается в локальную переменную @total , видимую только в рамках текущего соединения : базой данных.
После регистрации покупки первым покупателем число товарных позиций, оставшихся на складе, обновляется с 1 на 0 (листинг 19).
После регистрации покупки вторым покупателем также происходит обновление таблицы products (листинг 19), но т. к. текущее соединение ничего не знает о запросе, параллельно выполняющемся в другом соединении, то баланс по результату двух покупок будет 1 процессор, в то время как покупатели заплатят за 2 и будут ожидать поставки двух процессоров.
Для предотвращения такой ситуации выполнение всех трех этапов покупки должно происходить, как одна транзакция.
Другая проблема, связанная с выполнением группы операций, заключается в том, что при возникновении ошибки в середине группы операторов база данных останется в полумодифицированном состоянии.
Если при оплате покупки происходит перевод денежной суммы со счета клиента на счет электронного магазина, то счет клиента должен уменьшиться на сумму sum , а счет электронного магазина увеличится на ту же сумму (листинг 19).
Листинг 19. Обновление счетов
UPDATE account SET balance = balance — sum WHERE name = 'client';
UPDATE account SET balance = balance + sum WHERE name = 'bookshop';
Если в момент завершения первого запроса и перед началом выполнения второго произойдет сбой, транзакция окажется незавершенной.
Следует обратить внимание, что транзакции имеют смысл только в случае с типами таблиц, которые их поддерживают- InnoDB и BDB . Если существующие таблицы имеют другой тип, например MylSAM , для работы с транзакциями его следует изменить при помощи оператора alter table (листинг 20).
Листинг 20. Изменение типа таблиц
mysql> ALTER TABLE catalogs ENGINE = InnoDB;
mysql> ALTER TABLE products ENGINE = InnoDB;
Следует особенно внимательно следить, чтобы при изменении типа MylSAM на любой другой в таблице отсутствовали FULLTEXT -индексы, т. к. никакой другой тип таблиц их не поддерживает.
По умолчанию СУБД MySQL работает в режиме автоматического завершения транзакций, т. е. как только выполняется оператор обновления данных, который модифицирует таблицу, MySQL тут же сохраняет изменения на диске. Для объединения в транзакцию нескольких операторов необходимо отключить этот режим. Это можно осуществить при помощи системной переменной autocommit, значение которой выставляется при помощи оператора set (листинг 21).
Листинг 21. Отключение режима автоматического завершения транзакций
mysql > SET AUTOCOMMIT =0;
После отключения режима автоматического завершения транзакций следует использовать оператор commit , чтобы сохранять изменения на диске, либо rollback , чтобы отменять изменения, выполненные с момента начала транзакции (листинг 13). Для того чтобы включить режим автоматического завершения транзакций, необходимо выполнить оператор set autocommit =1.
Листинг 22. Использование транзакций
mysql> SET AUTOCOMMIT=0;
mysql> INSERT INTO catalogs VALUES(NULL,' Переферия ')
mysql> INSERT INTO catalogs VALUES(NULL,' Разное ');
mysql> SELECT * FROM catalogs;
mysql> ROLLBACK;
mysql> SELECT * FROM catalogs;
mysql> INSERT INTO catalogs VALUES(NULL,' Переферия ' )
mysql> INSERT INTO catalogs VALUES(NULL,' Разное ');
mysql> COMMIT;
mysql> SELECT * FROM catalogs;
mysql> SET AUTOCOMMIT=1;
В листинге 23 в таблицу catalogs добавляются новые записи, при этом выполнение оператора ROLLBACK позволяет отменить все изменения, которые были произведены над таблицей catalogs. напротив, оператор COMMIT сохраняет изменения на диске и уже следующий оператор ROLLBACK вернет последнее сохраненное состояние.
Для того, чтобы включить режим автоматического завершения транзакций только для отдельной последовательности операторов, можно воспользоваться оператором START TRANSACTION (листинг 23).
Листинг 23. Использование оператора START TRANSACTION
mysql> START TRANSACTION;
mysql> SELECT © total := count FROM products WHERE name = 'Celeron D 320 2.4GHz'; mysql> UPDATE products SET count = © total - 1 WHERE name = 'Celeron D 320 2.4GHz';
mysql> COMMIT;
После выполнения оператора START TRANSACTION режим автоматического завершения транзакций остается включенным до явного завершения транзакции с помощью оператора commit или отката транзакции при помощи rollback .
Оператор SET TRANSACTION появился в СУБД MySQL , начиная с версии 4.0.11 и имеет два синонима : BEGIN и BEGIN WORK , появившиеся еще в версии 3.23. Однако рекомендуется использовать именно SET TRANSACTION .Для некоторых операторов нельзя выполнить откат при помощи оператора ROLLBACK. К их числу относят CREATE INDEX, DROP INDEX, CREATE TABLE, DROF TABLE, TRUNCATE TABLE, ALTER TABLE, RENAME TABLE, CREATE DATABASE, DROF database , alter database . Следует избегать помещать их в транзакции с другими операторами.
Кроме того, существует ряд операторов, которые неявно завершают транзакцию, как если бы был вызван оператор commit . К их числу относятся alter table, begin, create index, create table, create database, drop database, drop index, drop table, drop database, load master data, lock tables, rename, set autocommit=1, start transaction, truncate table.
Операторы create table, truncate table, drop database и create DATABASE приводят к неявному завершению транзакции , начиная с версии MySQL 4.1.13 и 5.0.8.
Транзакции не могут быть вложенными. Это связано с тем, что любой оператор, начинающий транзакцию, приводит к завершению предыдущей транзакции.
Начиная с версий MySQL 4.0.14 и 4.1.1, для таблиц типа InnoDB поддерживаются операторы savepoint и rollback to savepoint , которые позволяют работать с именованными точками начала транзакции (листинг 24).
Листинг 24. Работа с именованными точками начала транзакции
mysql> SAVEPOINT cheops;
mysql> INSERT INTO catalogs VALUES(NULL,' Переферия ');
rnysql> INSERT INTO catalogs VALUES(NULL,' Разное ');
mysql> ROLLBACK TO SAVEPOINT cheops;
В листинге 24 оператор savepoint устанавливает именованную точку начала транзакции с именем cheops . Если текущая транзакция имеет точку сохранения с таким же именем, старая точка удаляется и устанавливается новая. Оператор rollback to savepoint cheops откатывает транзакцию к состоянию, в котором находилась база данных на момент установки именованной точки, с помощью оператора savepoint . Все точки сохранения транзакций удаляются, если выполняется оператор commit или rollback без указания имени точки сохранения.
Блокировка таблиц.
Для таблиц типа MylSAM использование транзакций недоступно. Однако их можно эмулировать при помощи операторов lock tables и unlock tables . В отличие от полноценных транзакций, данные операторы блокируют всю таблицу, в результате чего никто не может работать с таблицами до тех пор, пока они остаются заблокированными. Оператор lock tables выполняет блокировку таблиц, a unlock tables снимает блокировку (листинг 25).
Все таблицы, заблокированные в текущем соединении, разблокируются при повторном вызове оператора lock tables .
Операторы LOCK TABLES И UNLOCK TABLES имеют синонимы LOCK TABLE и UNLOCK TABLE , соответственно.
Листинг 25. Использование операторов LOCK TABLES И UNLOCK TABLES
mysql> LOCK TABLES catalogs WRITE;
mysql> INSERT INTO catalogs VALUES(NULL,' Переферия ');
mysql> INSERT INTO catalogs VALUES(NULL,' Разное ');
mysql> UNLOCK TABLES;
Листинг 26 демонстрирует блокировку таблицы catalogs на время добавления данных в базу данных. Следует обратить внимание, что после оператора lock tables записывается имя блокируемой таблицы, при снятии блокировки при помощи оператора unlock tables указания имени таблицы уже не требуется. Основная причина применения блокировки таблицы при помощи lock tables — это увеличение скорости обновления таблиц и добавления больших объемов данных.
При использовании блокировок можно явно указать тип блокировки — на чтение ( read ) или на запись ( write ) (листинг 26).
Листинг 26. Детализация типа блокировки
mysql> LOCK TABLES catalogs WRITE;
mysql> INSERT INTO catalogs VALUES(NULL,' Переферия 1 );
mysql> INSERT INTO catalogs VALUES(NULL,' Разное ');
mysql> UNLOCK TABLES catalogs;
mysql> LOCK TABLES catalogs READ;
mysql> INSERT INTO catalogs VALUES(NULL,' Переферия ');
mysql> INSERT INTO catalogs VALUES(NULL,' Разное ');
mysql> UNLOCK TABLES;
Различие между блокировками на чтение ( read ) и запись ( write ) заключается в том что клиент, установивший блокировку на чтение, и остальные клиенты могут только читать из таблицы данные. При блокировке на запись ( write ) установивший ее клиент может как вносить записи в таблицу, так и читать, в то время как доступ других клиентов к таблице блокируется. Причем все остальные клиенты ожидают, когда блокировка будет отменена оператором unlock tables . Следует отметить, что время ожидания может быть значительным и это следует предусмотреть в клиентской программе (листинг 27).
Листинг 27. Время блокировки может быть значительным
mysql> LOCK TABLES products READ; Query OK, 0 rows affected (331.67 sec)
Один оператор lock tables может блокировать сразу несколько таблиц, причем рекомендуется блокировать все таблицы, которые участвуют в запросах внутри блокировки. Это связано с тем, что пока блокировка, установленная lock tables , активна, невозможно получить доступ ни к каким таблицам, которые не были блокированы этим оператором (листинг 28).
Листинг 28. Блокировка нескольких таблиц
mysql> LOCK TABLES catalogs WRITE, products WRITE;
mysql> SELECT * FROM catalogs, products WHERE products.id_catalog = catalogs.id_catalogs
mysql> INSERT INTO catalogs VALUES(NULL,' Разное ');
mysql> UNLOCK TABLES catalogs;
Если запрос обращается к таблице через псевдоним, требуется блокировать таблицу, используя тот же псевдоним. Блокировка таблицы не будет работать, если не указан псевдоним (листинг 29).
Листинг 29.Ошибка при использовании псевдонима
mysql> LOCK TABLES products READ;
mysql> SELECT * FROM products AS p;
И наоборот, если таблица блокирована по псевдониму, к ней следует обращаться, используя этот псевдоним (листинг 30).
Листинг 30. Обращение к таблице по псевдониму
mysql> LOCK TABLE products AS p READ;
mysql> SELECT * FROM products;
Блокировки по записи (write) обычно имеют более высокий приоритет, чем блокировки по чтению (read), чтобы гарантировать, что обновления данных пройдут как можно быстрее. Это означает, что если один или несколько клиентов устанавливают блокировку на чтение (read), а затем другой клиент устанавливает блокировку на запись ( write) по этим же таблицам, то все остальные клиенты будут ожидать, пока блокировка по записи не будет снята.
Можно использовать ключевое слово low _ priority совместно с ключевым словом write, что бы позволить другим клиентам устанавливать блокировку по чтению, пока клиент ожидает возможности установки блокировки по записи (листинг 31).
Листинг 31. Использование ключевого слова LOW_PRIORITY WRITE
LOCK TABLES catalogs LOW_PRIORITY WRITE;
INSERT INTO catalogs VALUES(NULL,' Переферия ')
UNLOCK TABLES catalogs;
Однако при интенсивном обращении к серверу, когда таблицы постоянно блокированы по чтению, клиент, установивший блокировку с низким приоритетом, может не дождаться своей очереди.
6 Серверные объекты базы данныхХранимые процедуры, представления и триггеры
Для решения типовых (часто повторяющихся) задач выборки или обновления, а также в значительной части для управления доступом к данным (как альтернатива механизму разрешения-запрета) и обеспечения целостности данных целесообразно использовать процедуры. Кроме того, другое преимущество, уже в части администрирования, состоит в том. что не надо специально определять пользователю права доступа к таблицам и представлениям. используемым в процедуре: достаточно определить только разрешение на выполнение процедуры.
Существуют два способа взаимодействия приложения с SQL- сервером.
Можно создать приложение, отправляющее клиентские операторы на сервер, либо создать хранимые процедуры непосредственно на сервере.
В первом случае операторы каждый раз компилируются сервером.
Второй способ активизирует хранимые процедуры, вызывая их из приложения одним оператором. При первом вызове хранимой процедуры она компилируется и создается план ее выполнения, который сохраняется в памяти. При последующих вызовах SQL- сервер будет использовать этот план и процедуру повторно не компилирует. Таким образом, когда для решения определенных задач требуется многократно выполнить одну и ту же последовательность операторов SQL, применение хранимой процедуры обеспечивает более высокую производительность.
Клиент-серверная архитектура - это решение задачи интеграции данных при условии приемлемой скорости работы приложения.
Данное решение основано на следующих положениях:
коллективное использование данных, которые являются общими для всех структур фирмы;
исполнение сервером совместно используемых программируемых объектов базы данных.
Под программируемыми объектами базы данных понимают просмотры, хранимые процедуры и триггеры.
Представления (View) существует независимо от информации в базе, но тесно с ней связаны. Представления используются для фильтрования и предварительной обработки данных.
Представление- это по существу некая виртуальная таблица, содержащая результаты выполнения запроса (оператора SELECT) к одной или нескольким таблицам. Для конечного пользователя представление выглядит как обычная таблица в базе данных, над которой можно выполнять операторы SELECT, INSERT, UPDATE и DELETE.
Типы представлений. Различные типы представлений имеют свои преимущества и недостатки. Выбор того или иного типа представлений полностью зависит от задач приложения.
Выделяют следующие типы представлений:
подмножество полей таблицы — состоит из одного или более полей таблицы и считается самым простым типом представления. Обычно используется для упрощения представления данных и обеспечения безопасности;
подмножество записей таблицы — включает определенное количество записей таблицы и также применяется для обеспечения безопасности;
соединение двух и более таблиц — создается соединением нескольких таблиц и используется для упрощения сложных операций соединения;
агрегирование информации — создается группированием данных и также применяется для упрощения сложных операций.
Представления также позволяют логически объединять данные. Например, если данные хранятся в нескольких таблицах, их затем посредством представления можно объединить в более крупную виртуальную таблицу.
Еще одно преимущество представлений заключается в том, что они могут иметь более низкий уровень безопасности, чем их исходные таблицы. Запрос для представления выполняется согласно уровню безопасности вызывающего его пользователя. Таким образом, представление можно применять для сокрытия данных от определенной группы пользователей.
Представления, как и индексы, можно создавать различными способами: использовать для этого мастер; или команду SQL, имеющую в общем случае следующий формат.
CREATE VIEW имя представления [столбец[, .]] AS SELECT-onepamop
Следует отметить, что использование в операторе SELECT предложения WHERE позволяет локализовать доступ пользователя к данным даже на уровне отдельных строк и столбцов.
Достоинства применения представлений (просмотров)
Для их оценки следует иметь в виду, что пользователи клиент-серверного приложения могут:
работать в структурах фирмы, которые решают разные задачи. Например, одни сопровождают списки арендаторов и владельцев, а другие договоры аренды недвижимости;
иметь различные привилегии доступа к документу. Например, клерк и главный менеджер. Последний знает не только то, что арендуют, но и стоимость аренды.
Теперь, учитывая вышесказанное, а также возможность хранения на сервере нескольких представлений, которые разделены на группы для разных рабочих мест, перечислим основные достоинства представлений.
Упрощение доступа к данным. Просмотры "хранят" наборы данных одной или нескольких таблиц, которые можно отобразить, когда это необходимо без затрат времени на составление SQL-команд.
Настройка доступа к данным. Каждый пользователь может использовать "свой" просмотр. Это позволяет реализовать клиентские места так, чтобы пользователи работали только с данными, входящими в их компетенцию.
Обеспечение независимости от данных. Просмотры защищают пользователей от изменений структуры базы данных. Например, если администратор базы данных решает представить одну таблицу двумя, то новым просмотром можно объединить эти новые таблицы так, что пользователь не заметит изменений.
Защита данных. Просмотры ограничивают доступ к ответственной информации базы данных. Например, вы можете просматривать информацию о сторонах договора аренды, но не можете видеть связанную информацию о стоимости аренды.
Хранимая процедура (stored procedure) — это набор операторов SQL, которые SQL-сервер компилирует в единый план выполнения.
Этот план сохраняется в кэше процедур при первом выполнении хранимой процедуры, и затем план можно повторно использовать уже без рекомпиляции при каждом вызове.
Хранимая процедура аналогична процедурам в языках программирования: она может принимать входные параметры, возвращать данные и коды завершения.
Применение хранимых процедур улучшает производительность, например, при использовании в хранимой процедуре условных операторов (таких как IF и WHILE), поскольку условие будет проверяться непосредственно на сервере и серверу не потребуется возвращать промежуточные результаты проверки условия программам-клиентам.
Хранимые процедуры также позволяют централизованно контролировать выполнение задачи, что гарантирует соблюдение бизнес-правил.
Хранимые процедуры, как и представления, можно создавать различными способами:
использовать для этого "мастер" или команду SQL, имеющую в общем случае следующий формат
CREATE PROCEDURE имя процедуры [(%параметр1 тип_данных[,..]] AS SQL-операторы
Существует два типа хранимых процедур: системные и пользовательские.
Первые поддерживается SQL-сервером и применяются для управления сервером и отображения информации о базах данных и пользователях.
Вторые создаются пользователями для выполнения прикладных задач.
Хранимая процедура - это отдельная программа, написанная на процедурном языке используемого сервера баз данных.
Существует две разновидности хранимых процедур: процедуры выбора (аналог SELECT-запросов) и исполняемые процедуры.
Процедуры выбора возвращают наборы данных, которые состоят из строк или отдельных значений.
Исполняемые процедуры не возвращают данные. Они предназначены для исполнения команд, например, DELETE.
Для передачи процедуре значений из вызывающего приложения используют вхПараметр. Для возвращения результатов хранимой процедуры - выхПараметр.
Тело процедуры имеет формат:
[DECLARE VARIABLE имяПерем <тип>;
DECLARE VARIABLE имяПерем <тип>; …]]
BEGIN
<оператор>
[…]
<оператор>
END
Ключевые слова DECLARE VARIABLE объявляют локальные переменные процедуры.
Изменение и удаление хранимых процедур
Изменение хранимой процедуры производится оператором ALTER PROCEDURE .
Для удаления хранимой процедуры из базы данных используется оператор: DROP PROCEDURE ИмяПроцедуры;
Исполнение хранимых процедур
Запуск исполняемой хранимой процедуры производят командой ЕХЕСОТ РRОСЕDURЕ, а процедуры выбора - SELECT.
Запуск процедур выбора из приложения клиента
В ВDЕ-ориентированных клиентах доступ к хранимым процедурам обеспечивают компоненты TStoredProc и TQuery. Выбор компонента зависит от того, как создана хранимая процедура, как необходимо возвращать данные и от используемого сервера баз данных. Выбор метода зависит от типа процедуры: процедуры выбора инициируют методом Open, исполняемые - ЕхесSQL.
Триггер (trigger) — это особый тип хранимой процедуры, которая автоматически выполняется при изменении таблицы с помощью операторов UPDATE, INSERT или DELETE.
Как и хранимые процедуры, триггеры содержат операторы SQL, но в отличие от процедур запускаются не индивидуально, а автоматически при выполнении операций изменения данных. Триггеры наряду с ограничениями обеспечивают целостность данных и соблюдение бизнес-правил, однако их следует использовать разумно. Например, не нужно создавать триггер, проверяющий наличие значения первичного ключа в одной таблице, чтобы определить, можно ли вставить значение в соответствующее поле другой таблицы. Однако трудно обойтись без триггеров при выполнении каскадных изменений в дочерних таблицах.
Триггер создается на одной таблице в текущей базе данных, хотя может использовать данные других таблиц и объекты других баз данных. Триггеры нельзя создавать на представлениях, временных и системных таблицах. Таблица, для которой определен триггер, называется таблицей триггера.
Существуют три типа триггеров: UPDATE, INSERT и DELETE, каждый из которых инициируется при выполнении одноименной команды.
Операции UPDATE, INSERT и DELETE иногда называют событиями изменения данных. Можно создать триггер, который будет срабатывать при возникновении более чем одного события, например, запускаться в ответ на операторы UPDATE или INSERT. Такие комбинированные триггеры называются UPDATE/INSERT. Возможно создание триггеров, срабатывающих при выполнении любого из трех операторов обновления данных (триггер UPDATE/ INSERT/DELETE).
Триггеры, как и представления, можно создавать различными способами: использовать для этого мастер; или команду -SQL, имеющую в общем случае следующий формат:
CREATE TRIGGER имя_триггера
ON имя_таблицы
FOR [INSERT] [,] [UPDATE] [,] [DELETE]
AS SQL-операторы
В программе-триггере нельзя использовать операторы создания, реструктуризации, удаления объектов, реконфигурации и восстановления.
Работа триггеров подчиняется следующим правилам:
• триггеры запускаются только после завершения выполнения вызывающего их оператора. Например, триггер UPDATE не начинает работать, пока не завершится выполнение оператора UPDATE;
• триггер не начинает работать, если при выполнении оператора происходит нарушение какого-либо ограничения таблицы или возникает другая ошибка;
• триггер и вызывающий его оператор образуют транзакцию. В результате вызова из триггера оператора ROLLBACK отменяются изменения, выполненные триггером и оператором. При возникновении серьезной ошибки, например, при отключении пользователя, SQL-сервер автоматически выполнит откат всей транзакции;
• триггер запускается один раз для каждого оператора, независимо от количества изменяемых оператором записей
Триггеры возвращают результаты своей работы в приложение, подобно хранимым процедурам Как правило, пользователь не ожидает вывода после выполнения операторов UPDATE, INSERT и DELETE, вызывающих срабатывание триггеров. Если триггер возвращает данные, приложение должно содержать код, правильно интерпретирующий результаты модификации таблицы и вывод триггера
Для каждого триггера SQL- сервер создает две временные таблицы, на которые можно ссылаться в описании триггера Эти таблицы хранятся в памяти и локальны по отношению к триггеру, то есть триггер имеет доступ только к своей собственной версии таблиц. Временные таблицы применяются для сравнения состояния таблицы до и после внесения изменений
Например, в MS SQL Server возможно создание нескольких триггеров на таблице для каждого события изменения данных (UPDATE, INSERT или DELETE) и рекурсивный вызов триггера Например, если для таблицы уже определен триггер UPDATE, то можно определить еще один триггер UPDATE для той же самой таблицы В этом случае после выполнения соответствующего оператора сработают оба триггера Кроме того, допускаются вложенные триггеры, которые срабатывают в результате выполнения других триггеров Они отличаются от рекурсивных тем, что не запускают сами себя.
Репликация базы данных заключается в копировании, или тиражировании, данных из одной таблицы или базы данных в другую.
Офис с сетью региональных отделений — показательный случай для использования системы с репликацией транзакций Каждый филиал ведет работу со своими счетами, информация о которых содержится в его базе данных. Главный офис является подписчиком на базы данных всех филиалов, что позволяет собирать в нем информацию по всей организации.
Репликация основана на метафоре "издатель — подписчик" издатель (публикующий сервер) предоставляет данные, распространитель содержит тиражируемую базу или служебную информацию для управления репликацией, подписчик — получает и обрабатывает реплицированные данные. Данные передаются от публикующего или рассылающего сервера в направлении каждого из подписчиков Данные не могут пересылаться подписчику непосредственно от другого подписчика Если один из подписчиков перестает функционировать, это не должно оказывать никакого влияния на издателя или других подписчиков.
В схеме репликации транзакций для доставки данных от публикующего сервера на каждый из серверов-подписчиков используются три следующих компонента:
агент синхронизации (Snapshot Agent). Создает файлы данных и структуры, используемые для согласования новых подписчиков с текущим состоянием публикации,
агент чтения журнала (Log Reader Agent) Считывает из журнала транзакций публикующего сервера подлежащие репликации транзакции и помещает их в базу данных рассылки, агент рассылки (Distnbutation Agent). Пересылает подлежащие репликации транзакции из базы данных рассылки всем подписчикам на публикацию. Каждая публикация (набор реплицируемых данных — статей, которыми могут быть таблицы, записи, поля или хранимые процедуры) создается для выделения данных, подлежащих репликации в базе данных подписчиков. Агент синхронизации создает файл схемы, предназначенный для создания в базе данных табличных структур реплицируемых данных Этот агент также создает файлы, содержащие данные из публикуемых статей, и обновляет содержимое базы данных рассылки для фиксации нового задания на согласование. В журнале транзакций публикующего сервера все транзакции, подлежащие репликации в адрес одного или более подписчиков, помечаются специальным флажком. Агент чтения журнала считывает из журнала все помеченные этим флажком команды INSERT, UPDATE и DELETE. Агент следит за появлением подлежащих репликации транзакций для каждой публикации, существующей в базе данных публикующего сервера. Любая обнаруженная транзакция копируется им в базу данных рассылки. Затем агент чтения журналов адресует рассылаемые данные каждому подписчику на публикацию.
После исходного согласования состояний подписчика и публикующего сервера весь объем данных никогда не пересылается в адрес подписчика. Поддержание актуального состояния базы данных подписчика обеспечивается агентом рассьлки. Он пересылает подписчику все команды INSERT, UPDATE и DELETE, введенные пользователями на стороне публикующего сервера. Очень важно четко представлять всю последовательность действий, которые выполняются при передаче подписчику сведений об изменениях, проведенных на стороне публикующего сервера.
При создании публикации разработчик может разрешить подписчику выполнять обновление собственной локальной копии данных. В этом случае все выполненные на стороне такого подписчика изменения будут переданы в обратном направлении на публикующий сервер, а последний разошлет их в адрес всех остальных серверов-подписчиков. Отсутствие конфликтов и гарантия внесения изменений на публикующий сервер обеспечиваются благодаря использованию на сервере-подписчике протокола двухступенчатой фиксации изменений. Если публикующий сервер по какой-либо причине не сможет получить сведения о внесенных изменениях, выполненная на стороне подписчика транзакция будет отменена и восстановится исходное состояние базы данных. В такой схеме непосредственно обновляемых подписчиков используются триггеры, хранимые процедуры, координатор распределенных транзакций, а также средства обнаружения конфликтов и рекурсии. Триггеры размещаются на стороне подписчика. Это гарантирует, что любая начатая на сервере-подписчике транзакция будет обязательно зафиксирована на публикующем сервере, прежде чем появится возможность зафиксировать ее на сервере-подписчике. Здесь используется протокол с двухступенчатой фиксацией изменений (Two Phase Commit — 2РС). Если транзакцию не удастся зафиксировать на публикующем сервере, она будет отменена и на сервере-подписчике, поэтому состояние обеих баз данных останется согласованным. Хранимые процедуры размещаются на стороне публикующего сервера. Это гарантирует, что любые реплицируемые транзакции будут выполнены только в том случае, если это не приведет к конфликту. Если в результате выполнения транзакции возникает конфликт, на серверах обоих узлов для данной транзакции будет выполнен откат. Координацию выполнения двухступенчатой фиксации изменений между публикующим сервером и сервером-подписчиком осуществляет Координатор распределенных транзакций (Microsoft Distributed Transaction Coordinator — MS DTC), который вызывает выполнение удаленных хранимых процедур.
Задания для самоконтроля
Введите 2 инструкции, позволяющие выводить описание каждого столбца таблицы Покупатели. входящей в базу данных xxpovgg.
Теоретические вопросы для самоконтроля:
Для чего создаются процедуры. Преимущества.
Способы взаимодействия приложения с SQL- сервером.
Перечислите программируемые объекты базы данных .
Представления и их типы.
Команды SQL для создания представления, хранимой процедуры, триггера.
Достоинства применения представлений (просмотров).
Хранимая процедура и ее типы. Способы создания.
Триггер, разновидности. Способы создания.
Каким правилам подчиняются триггеры.
7 Принципы проектирования клиентской части баз данныхОсновные требования к разработке пользовательского интерфейса
Создание пользовательского приложения требует разработки так называемого дружественного интерфейса пользователя, т.е. организации диалога между пользователем и компьютером (клиентом и сервером).
Основным способом организации диалога является разработка диалоговых форм, которые по назначению можно подразделить на следующие группы:
для ввода данных в таблицы;
для ввода условий обработки информации в запросы;
для автоматизации работы с объектами базы данных.
Формы для ввода данных в таблицы предназначаются для такой организации процедур внесения информации, которые могли бы свести к минимуму возможность ошибок оператора. Кроме того, такие формы могут служить для проведения анализа имеющихся в таблицах данных.
Формы для ввода условий обработки информации в запросы имеют назначение, аналогичное формам для ввода данных в таблицы.
Формы для автоматизации работы с объектами базы данных имеют различное назначение, например это формы-заставки, формы-меню, кнопочные формы и др.
Все эти формы и представляют собой интерфейс пользователя.
Разработка форм может производиться различными средствами визуального проектирования, например:
с помощью языков программирования (С++, Delphi, VBA);
с помощью специальных компонентов СУБД (конструкторов форм Microsoft Access, Oracle и др.).
Однако какими бы средствами не разрабатывались формы интерфейса пользователя, необходимо учитывать следующие советы и рекомендации:
прежде чем приступать к проектированию форм, необходимо продумать «сценарий» пользовательского интерфейса, т.е. определить последовательность появления форм на экране компьютера пользователя в соответствии с выполняемыми задачами. Фактически разработчик форм должен научиться создавать сценарии аналогично сценаристу художественных фильмов;
каждая форма должна иметь название, которое однозначно определяет ее назначение;
форма должна иметь привлекательный внешний вид, но при этом не должна содержать информации, не относящейся к конкретной задаче;
формы для ввода данных в таблицы или параметров в запросы должны обеспечивать:
минимизацию возможных ошибок при вводе данных пользователем за счет согласования терминов и сокращений, ввода данных из списков и создания сообщений о допущенной ошибке;
оптимальные способы перемещения курсора (табуляцией, стрелками, указателем мыши);
получение пояснительных сообщений или инструкций при вводе данных в поля таблиц или запросов;
автоматическое закрытие формы и переход к следующей форме.
Средства визуального проектирования
Чтобы информационная система была удобна для работы пользователя, кроме создания эффективной модели данных (разработки состава и взаимодействия таблиц и запросов) необходимо разработать удобный дружественный пользовательский интерфейс.
Разработка интерфейса пользователя связана с настройкой панелей инструментов, созданием пользовательского меню, разработкой различных диалоговых форм.
Настройка панелей инструментов и пользовательского меню. Для создания и настройки панелей инструментов, строк меню и контекстных меню, а также для установки свойств, влияющих на их вид и работу, используется диалоговое окно Настройка. Для его открытия необходимо выбрать в меню Вид команду Панели инструментов и подкоманду Настройка.
Создание специальной панели инструментов для открытой базы данных производится в следующем порядке:
• в меню Вид выбрать команду Панели инструментов, а затем подкоманду Настройка;
• на вкладке Панели инструментов нажать кнопку [Создать];
• в поле Панель инструментов ввести необходимое имя и нажать кнопку [ОК];
• на вкладке Панели инструментов нажать кнопку [Свойства];
• установить требуемые свойства и нажать кнопку [Закрыть].
Новая панель инструментов появится за диалоговым окном Настройка. Чтобы закончить создание панели инструментов, следует выполнить следующие действия:
• добавить кнопки из диалогового окна Настройка;
• переместить или скопировать кнопку с другой панели инструментов.
1. К панели инструментов можно добавить меню пользователя.
2. Панели инструментов, содержащие кнопки, запускающие существующие макросы, создаются автоматически. Специальную панель инструментов можно присоединить к форме или отчету.
Создание специального контекстного меню для активной базы данных. Создание специального контекстного меню производится в следующем порядке:
• в меню Вид выбрать команду Панели инструментов и подкоманду Настройка;
• на вкладке Панели инструментов нажать кнопку [Создать];
• в поле Панель инструментов ввести имя и нажать кнопку [ОК];
• на вкладке Панели инструментов нажать кнопку [Свойства];
• в поле со списком Тип выбрать пункт Контекстное меню;
• установить или снять флажок [Настройка] и нажать кнопку [Закрыть].
После выполнения указанных операций контекстное меню будет добавлено на панель инструментов.
Итак, мы рассмотрели некоторые общие приемы построения систем меню при разработке пользовательского интерфейса. Теперь дадим некоторые практические рекомендации.
Очевидно, что пользовательский интерфейс представляет собой некоторую последовательность диалоговых форм. Следовательно, их созданию должна предшествовать работа по созданию «сценария» пользовательского интерфейса.
Сначала создают формы-заставки, в которых необходимо показать основное назначение разработанной системы. На этих формах также можно организовать и меню пользователя. Это могут быть ниспадающие и кнопочные меню.
Создание ниспадающего меню можно организовать в виде определенной последовательности макросов.
Для каждого из пунктов Нового меню разрабатывается соответствующий макрос, устанавливающий состав подменю следующего уровня. На рис. 9.3 показан макрос Меню_Заполнение базы данных, устанавливающий состав подменю для пункта Ведение базы данных. Данный макрос состоит из трех макрокоманд, каждая из которых запускает соответствующий макрос. Назначение каждого запускаемого на выполнение макроса состоит в открытии соответствующей формы ввода данных. Рассмотренным способом можно проектировать многоуровневые меню.
Кроме того, создание меню для пользователя возможно в виде командных кнопок, щелкая по которым мышью, выбирают дальнейший путь по сценарию интерфейса.
8 Построение запросов к базе данных с помощью языка SQL.
Построение запросов к базе данных (SQL): добавление, изменение, удаление данных, выборка.
Цель занятия: рассмотреть вопросы наполнения таблиц данными, изменения существующих записей в базе данных и удаления данных из таблиц.
Успешное изучение учебного материала позволит: принципы построения запросов на добавление, изменение и удаление данных.
Иметь представление об многообразии команд работы с данными в СУБД MySQL.
Владеть основными приемами создания SQL- команд на добавление, модификацию и удаление данных из таблиц.
При изучении учебного материала необходимо особое внимание уделить синтаксису основных команд работы с данными, влияние ключевых слов на вывод данных.
После проектирования и создания базы данных (таблиц и, возможно, индексов) для начала полноценной работы в нее нужно поместить данные, которые впоследствии можно будет в случае необходимости добавлять, изменять и удалять. У вас есть структура. Теперь требуется наполнить ее содержанием.
В SQL для изменения данных используются три основные команды (их часто называют операторами модификации данных).
Оператор INSERT добавляет новые строки в базу данных.
Оператор UPDATE изменяет существующие в базе данных строки.
Оператор DELETE удаляет строки из базы данных.
Добавление записей в таблицу
Традиционно в реляционных базах данных для осуществления операции заполнения таблиц данными применяют три подхода:
однострочный оператор INSERT добавляет в таблицу данных новую запись;
многострочный оператор INSERT добавляет в таблицу данных несколько новых записей;
пакетная загрузка данных служит для добавления в таблицу данных из внешнего файла.
Можно добавлять записи в таблицы вручную. Для этой цели служит оператор insert. Можно добавлять записи прямо из файла или как исходные данные с помощью команды load data; с помощью утилиты mysql import или в виде предварительно созданных и сохраненных в файле операторов insert.
Далее демонстрируются все эти методы.
Оператор insert языка SQL определяет таблицу, куда будет производиться добавление, строка добавляемых данных и значений. Однострочный оператор INSERT может использоваться в нескольких формах.
Упрощенный синтаксис первой формы выглядит следующим образом:
- Определение значений всех столбцов.
INSERT [IGNORE] [INTO] tbl_name [(col_name,...)] VALUES (valuel, value2,...)
Данный оператор вставляет новую запись в таблицу tbl_name, значения записи перечисляются в списке (valuel, value2,...), порядок следования столбцов может задаваться списком col_name,... Значения передаются в списке после ключевого слова VALUES.
Для MySQL 3.22.5 слово into является опциональным (это верно и для других форм оператора insert.) Список value должен содержать все столбцы, хранящиеся в таблице. (Обычно это порядок следования названий столбцов в операторе create. Для определения этого порядка можно воспользоваться оператором describe tbl_name.)
Выделять строковые значения или значения типа "дата" можно как одинарными, так и двойными кавычками. Пустые значения здесь будут присвоены столбцам с атрибутом автоинкрементна в таблицах student и event. (Ввод недостающего значения приводит к генерированию следующего номера для student_id или event_id.) Начиная с версии СУБД MySQL 3.22.5 можно производить добавление сразу нескольких строк с помощью одного оператора insert:

INSERT INTO tbl_name VALUES(...),(...),...
Например:
mysql> INSERT INTO student
VALUES('Abby1,'F',NULL),('Kyle','M',NULL);
Такой оператор потребует ввода меньшего количества информации, да и сервер сможет эффективнее обработать эту команду. Версия СУБД MySQL 3.22.10 позволяет задавать имена столбцов и их значение в форме col_name = value:

INSERT INTO tbl_name SET col_namel=valuel,.col_name2=value2,...
Например:
mysql> INSERT INTO student
SET last_name ='Stein', first name=' Waldo';
Столбцы, не перечисленные в SET, получают значение по умолчанию. Такая форма оператора insert неприменима для вставки нескольких строк.
Существуют и другие методы загрузки данных в таблицы базы данных прямо из "плоских" файлов. Для этого существует оператор LOAD data и утилита mysqlimport.
Оператор load data действует как массовый загрузчик, считывающий данные из файла. Так она работает из mysql.
mysql> LOAD DATA LOCAL INFILE "member.txt" INTO TABLE member;
Этот оператор считывает данные из файла member.txt, находящегося в текущем каталоге на узле клиента, и загружает их на сервер в таблицу member.
Вариант load data local не работает в версиях до 3.22.15, так как, начиная только с этой версии, была добавлена возможность чтения данных прямо с компьютера клиента. (Без ключа LOCAL загружаемый файл должен быть расположен прямо на сервере, и поэтому для загрузки такого файла пользователь должен обладать широкими правами доступа к серверу, которых у него обычно нет.)
Формат данных в файлах по умолчанию предполагает, что столбцы разделены табуляциями, строки заканчиваются с началом новой строки, значения располагаются в порядке следования столбцов таблицы. Но есть возможность загружать файлы в других форматах или определять другой порядок столбцов.
Утилиту mysql import можно рассматривать как интерфейс между вводом на уровне оболочки операционной системы и оператором LOAD DATA.
% mysql - - local samp_db member.txt
Здесь, по сути, утилита mysql import генерирует оператор LOAD data для загрузки файла member.txt в таблицу member. Такая команда не сработает для версии СУБД MySQL старше 3.22.15, так как для нее потребуется оператор LOAD DATA LOCAL. Здесь все делается так, как это делается в mysql: если нужны параметры для связи, указывайте их перед именем базы данных.
Утилита mysql import получает имя таблицы, для которой предназначены данные из имени файла. (Для этого используется все, что указывается в имени файла до первой точки.) Например, данные из файла member.txt будут загружены в таблицу member, а из файла- president.txt - в таблицу president. Будьте осторожны, если возникла необходимость загрузки таблиц базы данных из нескольких файлов. Так, при использовании имен member1.txt и member2.txt для корректной работы утилиты mysql import должны использоваться таблицы member1 и member2. В нашем случае подойдут имена member1.txt и member2.txt или member.txt1 и member.txt2.
Если поэкспериментировав с добавлением данных на базе данных, можно удалить содержимое таблиц и загрузить данные. Для этого прямо из оболочки необходимо выполнить следующие команды.
% mysql samp_db < insert_president.sql
% mysql samp_db < insert_member.sql
% mysql samp_db < insert_student.sql
% mysql samp_db < insert_score.sql
% mysql samp_db < insert_event.sql
% mysql samp_db < insert_absence.sql
Каждый файл содержит оператор delete, предназначенный для удаления всех записей, введенных в таблицу, и набор операторов insert для инициализации содержимого таблицы. Это ввод можно упростить и ввести команду.
% cat insert_*.sql | mysql samp_db
Оператор INSERT позволяет добавлять строки в базу данных одним из двух способов: с помощью ключевого слова VALUES или с помощью оператора SELECT.
INSERT INTO table [(column_name, ...)] VALUES (expression,...) ||
INSERT INTO table [(column_name, ...)] SELECT ...
Опишем сначала правила использования ключевого слова VALUES.
Ключевое слово VALUES определяет значения некоторых или всех данных в столбцах новой строки. Ниже представлена общая форма оператора INSERT, использующего ключевое слово VALUES:
СИНТАКСИС:
INSERT INTO имя_таблицы [(столбец1 [ , столбец2]...)]
VALUES (константа1 [ , константа2]...)
Добавим в таблицу customer, имеющую следующую структуру, несколько записей.
(uid int(11) NOT NULL auto_increment,
login varchar(32) NOT NULL default '',
usertype char(1) NOT NULL default '1',
password varchar(128) NOT NULL default '',
firstname varchar(128) NOT NULL default '',
lastname varchar(128) NOT NULL default '',
otch varchar(128) NOT NULL default '',
email varchar(128) NOT NULL default '',
address varchar(255) NOT NULL default '',
phone varchar(32) NOT NULL default '',
zipcode int(10) default NULL,
date datetime default NULL,
PRIMARY KEY (uid),
UNIQUE KEY login (login),
KEY usertype (usertype)
) TYPE=MyISAM;
Для этого используем оператор INSERT:
INSERT INTO customer VALUES("2", "serg", "1", "202cb962ac59075b964b07152d234b70", "Калачев", "Сергей",
"Александрович", "11pov99@rambler.ru", "г. Ипатово, ул. Калинина 330", "5-95-44", "356630", NULL);
Задание: Добавьте запись в таблицу customer: ("4", "admin", "2", "202cb962ac59075b964b07152d234b70", "Калачев", "Сергей",
"Александрович", "11pov99@rambler.ru", "г. Ипатово, ул. Калинина 330", "5-95-44", "127", NULL);
Порядок полей в INSERT не обязательно должен совпадать с порядком полей, в котором они определялись при создании таблицы.
Вполне допустима и такая версия предыдущего предложения:
INSERT INTO customer(login, firstname, lastname, otch, email) VALUES("serg", "Калачев", "Сергей",
"Александрович", "11pov99@rambler.ru");
Соблюдаться строгий порядок перечисления вводимых значений необходимо, если не имеем перечня загружаемых столбцов и СУБД можетиспользовать лишь перечень, который определен при создании модифицируемой таблицы.
Подобно операции DELETE операция INSERT может нарушить непротиворечивость базы данных. Отсутствие значения породит противоречие: в базе появится ссылка на несуществующую запись. Отметим, что все "приличные" СУБД имеют механизмы для предотвращения ввода записей со значениями внешних ключей, отсутствующих среди значений соответствующих первичных ключей.
Использование оператора SELECT в команде INSERT
Для получения данных из одной или нескольких таблиц в команде INSERT можно использовать оператор SELECT.
Упрощенный синтаксис команды INSERT, использующей оператор SELECT, имеет следующий вид:
INSERT INTO имя_таблицы [(вставляемый_список_столбцов)]
SELECT список_столбцов
FROM список_таблиц
WHERE условия
Оператор SELECT в команде INSERT позволяет взять данные из нескольких или всех столбцов одной таблицы и вставить их в другую таблицу. Если вы вставляете значения только для части столбцов, определить значения для других столбцов можно будет позднее с помощью оператора UPDATE.
Если вы вставляете строки из одной таблицы в другую, эти таблицы должны иметь совместимую структуру, т.е. соответствующие столбцы должны иметь одинаковый тип, или же система должна уметь автоматически выполнять нужное преобразование.
Если столбцы в обеих таблицах совместимы по типам и определены в одинаковом порядке в соответствующих операторах CREATE TABLE, перечислять их в команде INSERT необязательно.
Задания:
На примере таблицы catalogs (id_catalog- первичный ключ наблицы, снабженный атрибутом auto_increment, значение по умолчанию- NULL и name-название каталога, значение по умолчанию- пустая строка) добавьте запись 1, "Процессоры". Просмотрите данные таблицы с помощью команды SELECT.
Измените порядок следования столбцов при добавление (name, id_catalog) и добавьте запись "Материнские платы", 2.
Попробуйте добавить запись 2, "Видеоадапторы". Не получилось? Вывелась ошибка ERROR 1062: Duplicate entry '2' for key 1. Если необходимо, чтобы новые записи с дублирующим ключом отбрасывались без генерации ошибки, необходимо добавить после оператора INSERT ???? (введите необходимое ключевое слово).
Вставьте запись таблицы только значение столбца name ("Жесткие диски"). Посмотрите, что добавилось в столбец id_catalog?
Можно ли в таблицу добавить пустые строки? Попробуйте добавить в таблицу catalogs.
Модификация существующих записей
Операция обновления позволяет менять значения полей в уже существующих записях. Для обновления данных предназначены операторы UPDATE, REPLACE.
Первый позволяет обновлять отдельные поля в уже существующих записях, тогда как оператор REPLACE больше похож на INSERT, за исключением того, что если старая запись в данной таблице имеет то же значение индекса UNIQUE или PRIMARY KEY, что и новая, то старая запись перед занесением новой записи будет удалена. Для модификации уже существующих записей можно воспользоваться оператором UPDATE.
Он имеет следующий синтаксис:
UPDATE tbl_name SET какой столбец изменить WHERE какую запись изменить
В инструкции, сразу после ключевого слова UPDATE указывается таблица tbl_name, которая подвергается изменению. В предложении SET перечисляются столбцы, которые подвергаются обновлению, и устанавливаются их новые значения. Необязательное условие WHERE позволяет задать критерий отбора строк- обновлению будут подвергаться только те строки, которые удовлетворяют условию where_definition.
Вот запрос, который изменит имена всех учащихся из таблицы student на имя "George":
mysql> UPDATE student SET name = "George";
Очевидно, что необходимо быть достаточно осторожными с такими запросами.
К записям, которые подвергаются модификации, необходимо подходить более детально. Предположим, что недавно в "Историки России" вступил новый член. При этом были заполнены только отдельные столбцы:
mysql> INSERT member (last_name, first_name)
-> VALUES ('York' , 'Jerome');
После этого стало понятно, что была пропущена дата окончания срока членства. Это легко поправимо:
mysql> UPDATE member
-> SET expiration' 2001-7- 20'
-> WHERE last_name = 'York1 AND first_name = 'Jerome';
Можно модифицировать несколько столбцов одновременно. Этот запрос изменит адреса электронной и обычной почты одновременно:
mysql> UPDATE member
-> SET email = 'jeromey@aol.com', street = 123 Elm St', city = 'Any town' ,
-> state = 'NY', zip=' 01003'
-> WHERE last name = 'York' AND first_name ' Jerome
Можно присвоить значениям столбцов пустое значение {если столбец их имеет). Допустим, Джером решил заплатить большой членский взнос, что позволяет ему стать "пожизненным" членом. Это можно зафиксировать, установив дату истечения срока полномочий в null (никогда не наступает):
mysql> UPDATE member AND firstname 'Jerome'
-> SET expiration=NULL
-> WHERE last name = 'York'
Для оператора update так же, как и для оператора delete верно утверждение, что нужно проверять правильность предложения where с помощью оператора SELECT. Если ваш критерий выборки слишком широк, но модифицируется слишком много записей, если слишком узок - слишком мало.
Синтаксис оператора REPLACE аналогичен оператору INSERT:
REPLACE [INTO] tbl_name [(col_name,...)] VALUES (valuel, value2,...)
В таблицу tbl_name вставляются значения, определяемые в списке после ключевого слова VALUES. Задать порядок столбцов можно при помощи необязательного списка col_name, следующего за именем таблицы tbl_name. Точно также, как и в случае оператора INSERT, оператор REPLACE допускает многострочный формат.
Удаление записей
Для удаления данных из таблиц предусмотрены операторы:
DELETE;
TRUNCATE TABLE.
Иногда требуется избавиться от определенных записей. Для этой цели существуют оператор delete.
Оператор DELETE имеет следующий синтаксис:
DELETE FROM tbl_name WHERE where_definittion ORDER BY ... LIMIT rows
Оператор удаляет из таблицы tbl_name записи, удовлетворяющие условию where_definittion. Предложение where определяет, какая именно запись удаляется. Она может опускаться, но в этом случае будут удалены все записи в таблице! Это значит, что чем проще оператор delete, тем он "опаснее". Ограничение LIMIT позволяет задать максимальное число записей, которые могут быть уничтожены.
DELETE FROM tbl_name
Этот запрос стирает все содержимое таблицы. Будьте бдительны! При удалении определенных записей для указания этих записей воспользуйтесь предложением WHERE. Совсем, так как в операторе SELECT. Например, для того, чтобы удалить из таблицы president всех президентов, родившихся в штате Огайо, выведите следующую команду.
DELETE FROM president WHERE state
OK, 7 rows affected (0.00 sec)
Ограничение, накладываемое на предложения WHERE в операторах DELETE, заключается в том, что там можно указывать только столбцы из таблицы, записи которой удаляются.
Перед использованием предложения WHERE в операторе DELETE проверьте его работу в операторе SELECT. He мешает убедиться, какие записи будут удалены оператором delete. Предположим, что нужно удалить запись о президенте Теодоре Рузвельте. Выполнит ли следующий запрос эту задачу?
mysql> SELECT last_name, first_name
-> WHERE last_name = 'Roosevelt'lastnamefirstname
RooseveltTheodore
RooseveltFranklin D.
Этот результат показывает, что требуется более серьезная детализация запроса.
mysql> SELECT last_name, first_name, FROM president
->WHERE last_name *= 'Roosevelt' AND firstnamelastnamefirstname
Roosevelt Theodore
Теперь нам известно правильное предложение WHERE. Таким образом, правильный оператор будет иметь вид:
mysql> DELETE FROM president AND first_name = 'Theodore'
-> WHERE last__name = 'Roosevelt'
Правда, операция удаления записи требует много предварительной работы? Семь раз отмерь, один раз отрежь! (На этом не стоит экономить. Сэкономить можно на копировании, вставке или методах редактирования строк.)
Задания для самоконтроля
Удалите из таблицы catalogs записи, имеющие значение первичного ключа id_catalog больше двух.
Измените запись таблицы "Процессоры" в таблице catalogs на "Процессоры (INTEL)".
Добавьте в таблицу catalogs 2 новых записи: (4, "Сетевые адаптеры"), (5, "Программное обеспечение")
Теоретические вопросы для самоконтроля:
Какие подходы применяются в реляционных базах для заполнения таблиц данными?
Напишите упрощенный синтаксис команды добавления данных в таблицу.
Какая из перечисленных команд позволит выполнить запросу без вывода ошибки, при этом не добавит новую запись с дублирующим ключом:
INSERT INTO catalogs VALUES (2. "Видеоадапторы");
NSERT INTO catalogs (name) values (2, "Видеоадапторы")
INSERT IGNORE INTO catalogs VALUES (2, "Видеоадапторы")
Действительно ли все операции, которые позволяет осуществить оператор LOAD DATA INFILE, могут быть выполнены при помощи утилиты mysqlimport.
Какие операторы позволят удалить данные из таблиц?
Синтаксис оператора обновления данных таблицы.
В каких случаях команда REPLACE работает также как и команда INSERT?
9. Обработка данных с помощью языка SQL.
Квалифицированный выбор при использовании операторов SQL
Теперь, когда таблицы созданы и заполнены данными, посмотрим, что можно сделать с этими данными. Оператор select позволяет производить выборку и отображение информации из таблиц любым способом.
Цель занятия: рассмотреть вопросы наполнения таблиц данными, изменения существующих записей в базе данных и удаления данных из таблиц.
Успешное изучение учебного материала позволит: принципы построения запросов на добавление, изменение и удаление данных.
Иметь представление об многообразии команд работы с данными в СУБД MySQL.
Владеть основными приемами создания SQL- команд на добавление, модификацию и удаление данных из таблиц.
При изучении учебного материала необходимо особое внимание уделить синтаксису основных команд работы с данными, влияние ключевых слов на вывод данных.
СУБД MySQL также позволяет производить выборку из нескольких таблиц.
Оператор выборки записей имеет формат вида:
SELECT[ALL DISTINCT]
<список данных>
FROM <список таблиц>
[WHERE <условие выборки>]
[GROUP BY <имя столбца> [,<имя столбца>] ... ]
[HAVING <условие поиска>]
[ORDER BY <спецификация> [,<спецификация>] ...]
Это наиболее важный оператор из всех операторов SQL.
Оператор SELECT позволяет производить выборку и вычисления над данными из одной или нескольких таблиц. Результатом выполнения оператора является ответная таблица, которая может иметь (ALL), или не иметь (DISTINCT) повторяющиеся строки. По умолчанию в ответную таблицу включаются все строки, в том числе и повторяющиеся. В отборе данных участвуют записи одной или нескольких таблиц, перечисленных в списке операнда FROM.
Список данных может содержать имена столбцов, участвующих в запросе, а также выражения над столбцами. В простейшем случае в выражениях можно записывать имена столбцов, знаки арифметических операций (+,—,*,/), константы и круглые скобки. Если в списке данных записано выражение, то наряду с выборкой данных выполняются вычисления, результаты которого попадают в новый (создаваемый) столбец ответной таблицы.
При использовании в списках данных имен столбцов нескольких таблиц для указания принадлежности столбца некоторой таблице применяют конструкцию вида: <имя таблицы>.<имя столбца>.
Операнд WHERE задает условия, которым должны удовлетворять записи в результирующей таблице. Выражение <условие выборки> является логическим. Его элементами могут быть имена столбцов, операции сравнения, арифметические операции, логические связки (И, ИЛИ, НЕТ), скобки, специальные функции LIKE, NULL, IN и т. д.
Операнд GROUP BY позволяет выделять в результирующем множестве записей группы.
Группой являются записи с совпадающими значениями в столбцах, перечисленных за ключевыми словами GROUP BY. Выделение групп требуется для использования в логических выражениях операндов WHERE и HAVING, а также для выполнения операций (вычислений) над группами.
В логических и арифметических выражениях можно использовать следующие групповые операции (функции): AVG (среднее значение в группе), МАХ (максимальное значение в группе), MIN (минимальное значение в группе), SUM (сумма значений в группе), COUNT (число значений в группе).
Операнд HAVING действует совместно с операндом GROUP BY и используется для дополнительной селекции записей во время определения групп. Правила записи <условия поиска> аналогичны правилам формирования <условия выборки> операнда WHERE.
Операнд ORDER BY задает порядок сортировки результирующего множества. Обычно каждая <спецификация> аналогична соответствующей конструкции оператора CREATE INDEX и представляет собой пару вида: <имя столбца> [ ASC | DESC ].
Оператор select позволяет производить выборку и отображение информации из таблиц любым способом.
Можно сделать выборку всех столбцов и всех строк таблицы:
SELECT * FROM president ;
Или сделать выборку одного столбца и одной строки таблицы:
SELECT birth FROM president WHERE last_name = "Hoover"
Оператор select состоит из нескольких предложений (частей), которые можно сочетать в любом порядке, в зависимости от того, какая информация требуется для выборки. Любое предложение может быть сложным или простым, в зависимости от чего весь оператор SELECT может быть сложным или простым.
Для создания оператора select необходимо определить, что требуется выбрать из таблиц. Для этой цели служат предложения from и where, которые используются наиболее часто, и group by, order by и limit, которые встречаются реже.
Предложение from обычно присутствует в операторе select, но в нем нет необходимости, если отображаются данные не из таблиц. Например, этот запрос просто отображает значения выражений, которые могут вычисляться без ссылки на таблицу, так что в предложении from нет необходимости.
SELECT 2+2, "Hello, world", VERSION()
Вывод для этого запроса:


При использовании предложения FROM для определения таблицы, из которой требуется произвести выборку, мы можем получить наиболее "общую" форму запроса. Для этого вместо указания конкретного столбца введем "*", что означает "все". Такой запрос выбирает и отображает все столбцы из таблицы student.
SELECT * FROM student
Вывод для этого запроса:

Значения всех столбцов возвращаются в том же порядке, в котором они хранятся в таблице. Этот совпадает с порядком, в котором столбцы перечислены оператором DESCRIBE student ('...' в конце распечатки показывает, что запрос возвращает больше строк, чем показано).
В операторе SELECT имена столбцов можно указывать явно. Для выборки только имен учащихся нужно сделать следующий запрос.
SELECT name FROM student
Вывод для этого запроса:

Для отображения нескольких столбцов в операторе SELECT можно рез запятую указать имена столбцов. Этот оператор аналогичен оператору SELECT * FROM student, но каждый столбец указывается здесь явным образом:
SELECT name, sex, student_id FROM student
Вывод для этого запроса:


Столбцы можно перечислять в произвольном порядке.
SELECT name, student_id FROM student; SELECT student_id, name FROM student
Столбцы можно указывать сколько угодно раз. Имена столбцов можно указывать в любом регистре.
SELECT name, student_id FROM student
SLECT NAME, STUDENT_ID FROM student
SELECT nAmE, sTuDeNt_Id FROM student
Определение критериев выборки
Таблицы имеют тенденцию становиться очень большими, поскольку с течением времени, все большее и большее количество строк в нее добавляется. Поскольку обычно из них только определенные строки интересуют вас в данное время, SQL дает возможность вам устанавливать критерии чтобы определить какие строки будут выбраны для вывода.
WHERE - предложение команды SELECT, которое позволяет вам устанавливать предикаты, условие которых может быть или верным или неверным для любой строки таблицы. Команда извлекает только те строки из таблицы, для которой такое утверждение верно. Например, предположим вы хотите видеть имена и комиссионные всех продавцов в Лондоне. Вы можете ввести такую команду:
SELECT sname, city FROM Salespeople WHERE city = 'LONDON'
Когда предложение WHERE представлено, программа базы данных просматривает всю таблицу по одной строке и исследует каждую строку чтобы определить верно ли утверждение. Следовательно, для записи Peel, программа рассмотрит текущее значение столбца city, определит что оно равно 'London', и включит эту строку в вывод. Запись для Serres не будет включена, и так далее. Вывод для вышеупомянутого запроса показан на рис. 3:

Рисунок 1. SELECT c предложением WHERE
Давайте попробуем пример с числовым полем в предложении WHERE. Поле rating таблицы Заказчиков (Customers) предназначено чтобы разделять заказчиков на группы основанные на некоторых критериях, которые могут быть получены в итоге через этот номер. Возможно это - форма оценки кредита или оценки основанной на томе предыдущих приобретений. Такие числовые коды могут быть полезны в реляционных базах данных как способ подведения итогов сложной информации. Мы можем выбрать всех заказчиков с рейтингом 100, следующим образом:
SELECT *FROM Customers WHERE rating = 100
Кавычки не используются здесь потому, что оценка - это числовое поле. Результаты запроса показаны на рисунке 2.

Рисунок 2. SELECT с числовым полем в предикате
Другими словами, вы можете использовать номера столбцов, устранять дубликаты, или переупорядочивать столбцы в команде SELECT, которая использует WHERE. Однако, вы можете изменять порядок столбцов для имен только в предложении SELECT, но не в предложении WHERE.
Ограничение набора выбираемых оператором select записей производится с помощью предложения where, которым определяется набор выбираемых строк.
В качестве критериев можно задавать цифровые значения.
SELECT * FROM score WHERE score > 95
Вывод для этого запроса:

Можно задавать в качестве критериев строковые значения. (Обратите внимание на то, что сравнения строк обычно не чувствительны к регистру.)
SELECT last_name, first_name FROM president WHERE last_name = "bush"
Вывод для этого запроса:

Или производить выборку по дате:
SELECT last_name, first_name, birth FROM president WHERE birth < "1750-1-1"
Вывод для этого запроса:

Выборку можно производить по комбинации значений.
SELECT last_name, first_name, birth, state FROM president WHERE birth < "1750-1-1" AND (state='VA' OR state='MA')
Вывод для этого запроса:

Выражения в предложениях WHERE могут содержать арифметические операторы, операторы сравнения и логические операторы. Выражения группируются с помощью скобок. Операторы могут содержать константы, столбцы таблиц и вызовы функций.
Теоретические вопросы для самоконтроля:
Какой оператор позволит выбрать данных из таблиц БД.
Какой операнд оператора SELECT используется для сортировки вывода информации.
С помощью какого операнда можно ограничить вывод данных результирующей таблицы.
Что такое группа и как ее создать (укажите операнд).
Какое ключевое слово нужно использовать, чтобы определить условие внутри группы.
10. Разработка и эксплуатация клиентской частиРасширенные средства создания запросов
С помощью SQL вы можете вкладывать запросы внутрь друга друга. Обычно, внутренний запрос генерирует значение, которое проверяется в предикате внешнего запроса, определяющего верно оно или нет. Например, предположим, что мы знаем имя продавца: Motika, но не знаем значение его поля snum, и хотим извлечь все порядки из таблицы Порядков. Имеется один способ чтобы сделать это:
SELECT * FROM Orders
WHERE snum =
( SELECT snum
FROM Salespeople
WHERE sname = 'Motika');
Чтобы оценить внешний( основной ) запрос, SQL сначала должен оценить внутренний запрос ( или подзапрос ) внутри предложения WHERE. Он делает это так как и должен делать запрос, имеющий единственную цель - отыскать через таблицу Продавцов все строки, где поле sname равно значению Motika, и затем извлечь значения поля snum этих строк. Единственной найденной строкой естественно будет snum = 1004. Однако SQL, не просто выдает это значение, а помещает его в предикат основного запроса вместо самого подзапроса, так чтобы предиката прочитал что WHERE snum = 1004.

Основной запрос затем выполняется как обычно с вышеупомянутыми результатами. Конечно же, подзапрос должен выбрать один и только один столбец, а тип данных этого столбца должен совпадать с тем значением с которым он будет сравниваться в предикате. Часто, как показано выше, выбранное поле и его значение будут иметь одинаковые имена( в этом случае, snum ), но это необязательно.
Конечно, если бы мы уже знали номер продавца Motika, мы могли бы просто напечатать WHERE snum = 1004 и выполнять далее с подзапросом в целом, но это было бы не так универсально. Это будет продолжать работать даже если номер Motika изменился, а, с помощью простого изменения имени в подзапросе, вы можете использовать его для чего угодно.
Скорее всего было бы удобнее, чтобы наш подзапрос в предыдущем примере возвращал одно и только одно значение.
Имея выбранным поле snum " WHERE city = 'London' вместо "WHERE sname = 'Motika', можно получить несколько различных значений. Это может сделать уравнение в предикате основного запроса невозможным для оценки верности или неверности, и команда выдаст ошибку.
При использовании подзапросов в предикатах основанных на реляционных операторах, вы должны убедиться. что использовали подзапрос который будет выдавать одну и только одну строку вывода. Если вы используете подзапрос, который не выводит никаких значений вообще, команда не потерпит неудачи; но основной запрос не выведет никаких значений. Подзапросы, которые не производят никакого вывода (или нулевой вывод) вынуждают рассматривать предикат ни как верный ни как неверный, а как неизвестный. Однако, неизвестный предикат имеет тот же самый эффект что и неверный: никакие строки не выбираются основным запросом.
Это плохая стратегия, чтобы делать что-нибудь подобное следующему:
SELECT *
FROM Orders
WHERE snum =
( SELECT snum
FROM Salespeople
WHERE city = Barcelona );
Поскольку имеем только одного продавца в Barcelona - Rifkin, то подзапрос будет выбирать одиночное значение snum и следовательно будет принят. Но это - только в данном случае. Большинство SQL баз данных имеют многочисленных пользователей, и если другой пользователь добавит нового продавца из Barcelona в таблицу, подзапрос выберет два значения, и ваша команда потерпит неудачу.
Также можно использовать подзапросы внутри предложения HAVING. Эти подзапросы могут использовать свои собственные агрегатные функции если они не производят многочисленных значений или использовать GROUP BY или HAVING. Следующий запрос является этому примером:
SELECT rating, COUNT ( DISTINCT cnum)
FROM Customers
GROUP BY rating
HAVING rating
( SELECT AVG (rating)
FROM Customers
WHERE city = ' San Jose';

Эта команда подсчитывает заказчиков с оценками выше среднего в San Jose. Так как имеются другие оценки отличные от 300, они должны быть выведены с числом номеров заказчиков которые имели эту оценку.
Вы можете, в некоторых случаях, использовать DISTINCT чтобы вынудить подзапрос генерировать одиночное значение. Предположим что мы хотим найти все порядки кредитований для тех продавцов которые обслуживают Hoffmanа ( cnum = 2001 ).
Имеется один способ чтобы сделать это :
SELECT *
FROM Orders
WHERE snum =
( SELECT DISTINCT snum
FROM Orders
WHERE cnum = 2001 );

Подзапрос установил, что значение поля snum совпало с Hoffman - 1001, и затем основной запрос выделил все порядки с этим значением snum из таблицы Порядков ( не разбирая, относятся они к Hoffman или нет). Так как каждый заказчик назначен к одному и только этому продавцу, мы знаем что каждая строка в таблице Порядков с данным значением cnum должна иметь такое же значение snum. Однако так как там может быть любое число таких строк, подзапрос мог бы вывести много ( хотя и идентичных ) значений snum для данного поля cnum. Аргумент DISTINCT предотвращает это. Если наш подзапрос возвратит более одного значения, это будет указывать на ошибку в наших данных - хороша вещь для знающих об этом.
Альтернативный подход должен быть чтобы ссылаться к таблице Заказчиков, а не к таблице Порядков в подзапросе. Так как поле cnum - это первичный ключ таблицы Заказчика, запрос выбирающий его должен произвести только одно значение. Это рационально только если вы как пользователь имеете доступ к таблице Порядков но не к таблице Заказчиков. В этом случае, вы можете использовать решение, которое мы показали выше. Пожалуйста учтите, что методика используемая в предшествующем примере применима только когда вы знаете, что два различных поля в таблице должны всегда совпадать, как в нашем случае. Эта ситуация не является типичной в реляционных базах данных, она является исключением из правил.
Вы должны обратить внимание, что предикаты, включающие подзапросы, используют выражение < скалярная форма > < оператор > < подзапрос >, или < подзапрос > < оператор > < скалярное выражение > или, <подзапрос> <оператор> < подзапрос >. Другими словами, вы можете записать предыдущий пример так:

SELECT *
FROM Orders
WHERE ( SELECT DISTINCT snum
FROM Orders
WHERE cnum = 2001 )= snum;

Один тип функций, который автоматически может производить одиночное значение для любого числа строк, конечно же, - агрегатная функция.
Любой запрос, использующий одиночную функцию агрегата без предложения GROUP BY будет выбирать одиночное значение для использования в основном предикате. Например, вы хотите увидеть все порядки имеющие сумму приобретений выше средней на 4-е Октября.
SELECT *
FROM Orders
WHERE amt >
( SELECT AVG (amt)
FROM Orders
WHERE odate = 10/04/1990 );

Средняя сумма приобретений на 4 Октября - 1450 ( 760 + 690) делится пополам, что в целом равняется = 725. Все строки со значением в поле amt выше этого - являются выбранными.

Имейте ввиду, что сгруппированные агрегатные функции, которые являются агрегатными функциями определенными в терминах предложения GROUP BY, могут производить многочисленные значения. Они, следовательно, не позволительны в подзапросах такого характера. Даже если GROUP BY и HAVING используются таким способом, что только одна группа выводится с помощью подзапроса, команда будет отклонена в принципе. Вы должны использовать одиночную агрегатную функцию с предложением WHERE, что устранит нежелательные группы. Например, следующий запрос который должен найти сред нее значение комиссионных продавца в Лондоне:
SELECT AVG (comm)
FROM Salespeople
GROUP BY city HAVlNG city = 'London';

Вы можете использовать подзапросы, которые производят любое число строк, если вы используете специальный оператор IN ( операторы BETWEEN, LIKE, и IS NULL не могут использоваться с подзапросами ). Как вы помните, IN определяет набор значений, одно из которых должно совпадать с другим термином уравнения предиката в порядке, чтобы предикат был верным. Когда вы используете IN с подзапросом, SQL просто формирует этот набор из вывода подзапроса. Мы можем, следовательно, использовать IN чтобы выполнить такой же подзапрос который не будет работать с реляционным оператором, и найти все атрибуты таблицы Порядков для продавца в Лондоне :
SELECT *
FROM Orders
WHERE snum IN
( SELECT snum
FROM Salespeople
WHERE city = 'LONDON');

В ситуации подобно этой, подзапрос - более прост для пользователя чтобы понимать его и более прост для компьютера чтобы его выполнить, чем если бы Вы использовали объединение:
SELECT onum, amt, odate, cnum, Orders.snum
FROM Orders, Salespeople
WHERE Orders.snum = Salespeople.snum
AND Salespeople.city = 'London';

Теоретические вопросы для самоконтроля:
При помощи какого оператора осуществляется выборка данных в MySQL?
Компонент клиент-серверной информационной системы "сервер баз данных"
Сервером называют
В результате команды select * from (имя таблицы) происходит...
Какой аргумент позволяет устранять двойные значения из вашего предложения SELECT
Оператор ... определяет набор значений в которое данное значение может или не может быть включено
Какой знак замещает последовательность любого числа символов?
Предложение HAVING...
Для удаления определенных записей из таблицы используется следующая команда
Внутренний запрос
В подзапросах могут использоваться:
Как называется язык написания запросов?
Выберите правильный вариант соединения с базой данных
При помощи какого ключевого слова в предложении SELECT происходит сортировка данных (в вернем регистре)
С помощью какого ключевого слова производится ограничение набора записей, выбираемых оператором select
Стандартные операторы Буля
11. Программы управления удаленными базами данныхОператоры SQL в прикладных программах
Язык SQL можно использовать как в интерактивном режиме, так и путем внедрения его операторов в программы, написанные на процедурных языках высокого уровня. Примером интерактивного использования SQL-операторов является окно Query Analyzer в среде MS SQL Server. Применение же языка SQL в прикладных программах на практике реализовано двумя различными способами:
Внедренные SQL-операторы. Отдельные SQL-операторы внедряются прямо в исходный текст программы и смешиваются с операторами базового языка. Этот подход позволяет создавать программы, обращающиеся непосредственно к базе данных. Специальные программы-предкомпиляторы преобразуют исходный текст с целью замены SQL-операторов соответствующими вызовами подпрограмм СУБД, затем он компилируется и собирается обычным способом.
Использование прикладного интерфейса программирования (API). Альтернативный вариант состоит в предоставлении программисту стандартного набора функций, к которым можно обращаться из создаваемых им программ. Конкретный вариант API может предоставлять тот же набор функциональных возможностей, который существует при подключении встроенных операторов, однако при этом устраняется необходимость предкомпилирования исходного текста. Кроме того, некоторые разработчики указывают, что в этом случае используется более понятный интерфейс и созданный программный текст более удобен с точки зрения его сопровождения.
Оба способа предполагают использование операторов как статического SQL, так и динамического SQL.
Что касается операторов статического SQL, то какого-либо изменения после их однократного написания не предполагается. Они могут храниться как в файлах, предназначенных для дальнейшего использования, так и в виде хранимых процедур базы данных, однако программисты не получают всей той гибкости, которую предлагает им динамический SQL. Несмотря на наличие большого числа запросов, доступных конечному пользователю, может случиться так, что ни один из этих "законсервированных" запросов не сможет удовлетворить его текущим потребностям.
Динамический SQL дает возможность программисту или конечному пользователю создавать операторы во время выполнения приложения и передавать их базе данных, которая после выполнения этих операторов помещает выходные данные в переменные программы. Динамический SQL часто используется инструментальными средствами, предназначенными для построения заранее незапланированных запросов, позволяющих оперативно формировать тот или иной оператор SQL в зависимости от особых требований, возникших в конкретной ситуации. После настройки оператора SQL в соответствии с потребностями пользователя он направляется серверу баз данных для проверки на наличие синтаксических ошибок и необходимых для его выполнения привилегий, после чего происходит его компиляция и выполнение.
Рассмотрим применение прикладного интерфейса программирования (API) для выполнения операторов SQL.
Прикладной API включает набор библиотечных функций, предоставляющих программисту разнообразные типы доступа к базе данных, а именно: подключение, выполнение различных SQL-операторов, выборка отдельных строк данных из результирующих наборов данных и т. д.
Чтобы не разрабатывать отдельные версии пользовательского приложения для каждой из целевых СУБД, с которыми данное приложение планируется использовать, Microsoft разработала стандарт, получивший название Open Database Connectivity ODBC. Технология ODBC предусматривает применение единого интерфейса для доступа к различным базам данных SQL, причем язык SQL рассматривается как основное стандартное средство доступа. Этот интерфейс обеспечивает высокую степень универсальности, в результате одно и то же приложение может получать доступ к данным, хранящимся в базах различных целевых СУБД, без необходимости внесения изменений в его программный текст. Таким образом, разработчики получили инструмент для создания и распространения приложений архитектуры "клиент-сервер", способных работать с широким спектром различных целевых СУБД, а связать приложения с любой выбранной целевой СУБД можно посредством соответствующего ODBC-драйвера.
В настоящее время технология ODBC фактически приобрела значение отраслевого стандарта. Основной причиной ее популярности является присущая ей гибкость, предоставляющая разработчикам следующие пре