close

Вход

Забыли?

вход по аккаунту

?

82.Базы данных

код для вставкиСкачать
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Министерство образования и науки Российской федерации
Федеральное государственное бюджетное образовательное
учреждение высшего профессионального образования
«Оренбургский государственный университет»
Кафедра программного обеспечения вычислительной техники
и автоматизированных систем
С.А.Щелоков
БАЗЫ ДАННЫХ
Рекомендовано Ученым советом федерального государственного бюджетного образовательного учреждения высшего профессионального образования «Оренбургский государственный университет» в качестве учебного пособия
для студентов, обучающихся по программам высшего профессионального образования по направлениям подготовки 231000.62 Программная инженерия и
230100.62 Информатика и вычислительная техника
Оренбург
2014
1
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
УДК 002.52
ББК 32.81
Щ46
Рецензент – кандидат технических наук, доцент Боровский А.С.
Щ46
Щелоков, С.А.
Базы данных: учебное пособие/ С.А.Щелоков; Оренбургский гос. ун-т.
– Оренбург: ОГУ, 2014. – 298 с.
Учебное пособие по дисциплине «Базы данных» предназначено для
учебно-методического обеспечения подготовки бакалавров по направлениям 230100.62 Информатика и вычислительная техника по профилю «Программное обеспечение средств вычислительной техники и автоматизированных систем» и 231000.62 Программная инженерия по профилю «Разработка программно-информационных систем». Дисциплина «Базы данных»
входит в состав базовой части профессионального цикла по профилям подготовки бакалавров.
В учебном пособии изложены общие теоретические основы баз данных
в составе информационных систем, концептуальные направления и перспективы развития баз данных, основы распределенной обработки информации. Учебное пособие содержит методические основы и практикумы работы в базах данных с использованием современных программных инструментальных средств.
УДК 002.52
ББК 32.81
© Щелоков С.А.,2014
© ОГУ, 2014
2
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Содержание
Введение…………………………………………………………………....
4
1 Основы систем баз данных…………………………………………….
6
1.1 Назначение и основные компоненты системы баз данных………...
6
1.2 Назначение, структура и основные компоненты СУБД Access…….. 30
1.3 Основы построения реляционных баз данных ……………………… 48
1.4 Нормализация баз данных………….………………………………….
73
1.5 Моделирование данных……………………………………………..… 104
2 Технология работ с базами данных в СУБД Access…………………. 124
3 Манипулирование данными…………………………………………... 137
3.1 Структурированный язык запросов SQL……………………………..
137
3.2 Манипулирование данными на основе реляционной алгебры ……..
162
3.3 Распределенная обработка данных…………………………………… 181
4
Работа в СУБД SQL Server в инструментальной среде Visual
Studio.NET…………………………………………………………………
…..
199
4.1 Практикум по созданию базы данных в СУБД SQL Server 2008
199
4.2 Общие сведения о сетевой базе данных SQL Server, компоненты
SQL Server………………………………………………………………….
211
4.3 Практикум по созданию Windows-приложения к базе данных SQL
Server в инструментальной среде Visual Studio по технологии .NET….
230
5 Использование средств автоматизации для проектирования и создания баз данных……………………………………………………………..
254
5.1 Общие сведения об IDEF-технологии………………………………... 254
5.2 Метод функционального моделирования IDEF0 ……………………. 259
5.3 Метод описания диаграммы потоков данных ……………………….. 279
5.4 Метод описания процессов IDEF3 …………………………………… 282
6 Развитие гибридных объектно-реляционных баз данных на основе
фреймово-слотовой нормальной формы…………………………………. 290
Список использованных источников…………………………………….
298
3
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Введение
В основе современной автоматизированной информационной системы
находится база данных предприятия, построенная на основе анализа информационных потоков внутри и вне предприятия. Разработанная база данных совместно с приложением пользователя лежит в основе программного и информационного обеспечения автоматизированного рабочего места.
Системный проектировщик должен иметь специальную подготовку по
эффективному использованию возможностей объектов современных систем
управления базами данных (СУБД): таблиц, форм, запросов, отчетов, макросов,
модулей. Классической СУБД является приложение офиса Windows – Access,
обладающая всеми объектами базы данных.
Процессы распределенной обработки информации требуют разработки и
внедрения распределенных баз данных, позволяющих работать нескольким
пользователям. Поэтому современный этап проектирования и разработки баз
данных производится на основе сетевых технологий. Наибольшее распространение в настоящее время получила сетевая база данных SQL Server.
Для разработки интерфейсной логики базы данных используется технология DOT.NET в инструментальной среде Visual Studio на основе Windows приложения с использованием языка программирования C#.
Учебный материал в курсе лекций по указанным выше направлениям изложен в шести разделах. Его могут использовать как преподаватели, так и студенты для самостоятельного изучения, обучающиеся по направлениям «Информатика и вычислительная техника» и «Программная инженерия».
В первом разделе раскрываются основы построения реляционных баз
данных, обсуждаются существующие термины и определения систем баз данных, дается характеристика нормальных форм, объясняются существующие методы моделирования и проектирования баз данных.
4
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Во втором разделе раскрываются объекты СУБД Access, поясняются основные правила работы с объектами: таблица, форма, запросы, отчеты и макросы.
В третьем разделе объясняются правила использования в базах данных
структурированного языка запросов SQL, содержатся основные положения реляционной алгебры Кодда, раскрываются основы распределенной обработки
данных.
В четвертом разделе раскрывается структура распределенной базы данных
SQL Server и поясняется основные правила работы в ней по созданию таблиц,
запросов и представлений. Объясняется технология DOT.NET в инструментальной среде Visual Studio и правила разработки Windows приложения с использованием языка программирования C#.
В пятом разделе раскрывается технология использования средств автоматизации BPWin (бизнес – планирования под Windows) для разработки моделей
информационных потоков в базах данных.
В шестом разделе обсуждаются направления развития баз данных на основе многомерных гиперкубов и объектно-ориентированного программирования.
Учебно-методический материал соответствует рабочим программам дисциплины «Базы данных» и предназначен для выполнения задач в соответствии с
ФГОС ВПО и ООП ВПО по указанным направлениям подготовки:
- обучение технологии проектирования, производства и сопровождения
баз данных как объектов профессиональной деятельности;
- обучение технологии и инструментальных средств, применяемых на
всех этапах моделирования, проектирования, разработки и реализации баз данных;
- обучение методам, языкам и технологиям разработки корректных программ SQL-запросов информации из баз данных, интерфейсов приложений презентационной логики баз данных в соответствии с основными парадигмами
программирования.
5
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
1 Основы систем баз данных
1.1 Назначение и основные компоненты системы баз данных
В современном мире информацию рассматривают как один из основных
ресурсов развития общества, а информационные системы и технологии как
средство повышения производительности и эффективности деятельности людей.
Наиболее широко информационные системы и технологии используются
в производственной, управленческой и финансовой деятельности, одновременно начались подвижки в сознании людей, занятых и в других сферах, относительно необходимости их внедрения и активного применения.
Согласно концепции баз данных (БД) основой информационной технологии являются данные, организованные в такую структуру, которая адекватно
отражает реалии действительности в той или иной предметной области и обеспечивает пользователя актуальной информацией в соответствующей предметной области.
Развитие современного промышленного производства и бизнеса невозможно без создания автоматизированных информационных систем, одно из
назначений которых - предоставление пользователю достоверной и своевременной информации, необходимой для принятия оптимального решения. Рассмотрим и обсудим термины и определения, касающиеся баз данных.
Понятие об информационных системах
Под системой понимают любой объект, который одновременно рассматривается и как единое целое, и как объединенная в интересах достижения поставленных целей совокупность разнородных элементов. Системы значительно
отличаются между собой как по составу, так и по главным целям.
6
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Приведем примеры несколько систем, состоящих из разных элементов и
направленных на реализацию разных целей (таблица 1.1).
Таблица 1.1
Система
Организация
Компьютер
Телекоммуникационная система
Информационная
система
Элементы системы
Люди, оборудование, материалы, здания и др.
Электронные и электромеханические элементы, линии связи и
др.
Компьютеры, модемы, кабели,
сетевое программное обеспечение и др.
Компьютеры, компьютерные
сети, люди, информационное и
программное обеспечение
Главная цель
системы
Производство
Обработка данных
Передача
информации
Производство
профессиональной
информации
В информатике понятие ―система‖ широко распространено и имеет множество смысловых значений. Чаще всего оно используется применительно к
набору технических средств и программ. Системой может называться аппаратная часть компьютера. Системой может также считаться множество программ
для решения конкретных прикладных задач, дополненных процедурами ведения
документации и управления расчетами.
Добавление к понятию ―система‖ слова ―информационная‖ отражает цель
ее создания и функционирования. Информационные системы обеспечивают
сбор, хранение, обработку, поиск и выдачу информации, необходимой в процессе принятия решений задач из любой области. Появление электронных вычислительных машин и персональных компьютеров предопределило создание и
внедрение автоматизированных информационных систем (АИС), которые значительно повысили производительность и результативность информационных
технологий по обработке и выдачи информации.
Понятие информационной системы содержит Федеральный закон РФ от
27 июля 2006 года № 149-ФЗ «Об информации, информационных технологиях и
о защите информации»: информационная система - совокупность содержащейся
7
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
в базах данных информации и обеспечивающих еѐ обработку информационных
технологий и технических средств.
Международный стандарт ISO/IEC 2382-1 дает следующее определение:
«Информационная система - система обработки информации, работающая совместно с организационными ресурсами, такими как люди, технические средства
и финансовые ресурсы, которые обеспечивают и распределяют информацию».
Российский ГОСТ РВ 51987 определяет информационную систему как автоматизированную систему, результатом функционирования которой является
представление выходной информации для последующего использования.
В качестве основного классификационного признака АИС целесообразно
рассматривать особенности автоматизируемой профессиональной деятельности
- процесса переработки входной информации для получения требуемой выходной информации, в котором АИС выступает в качестве инструмента должностного лица или группы должностных лиц, участвующих в управлении организационной системой.
В соответствии с предложенным классификационным признаком можно
выделить следующие классы АИС (рисунок 1.1):
АСУ
Автоматизированные системы управления
СППР
Системы
поддержки
принятия
решений
АИС
Классы АИС
АИВС
Автоматизированные
информационновычислительные
системы
АСО
Автоматизированные
системы
обучения
АИСС
Автоматизированные
информационносправочные
системы
Рисунок 1.1 – Классификация АИС
8
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
АИС – взаимосвязанная совокупность средств, методов и персонала, используемых для хранения, обработки и выдачи информации в интересах достижения поставленной цели.
Современное понимание АИС как системы предполагает использование в
качестве основного технического средства переработки информации персонального компьютера. Кроме того, техническое воплощение информационной системы само по себе ничего не будет значить, если не будет учтена роль человека, для которого предназначена производимая информация и без которого невозможно ее получение и представление.
Структуру АИС составляет совокупность отдельных ее частей, называемых подсистемами.
Подсистема – это часть системы, выделенная по какому-либо признаку.
Общую структуру информационной системы можно рассматривать как
совокупность подсистем независимо от сферы применения. В этом случае говорят о структурном признаке классификации, а подсистемы называют обеспечивающими. Таким образом, структура любой информационной системы может
быть представлена совокупностью обеспечивающих подсистем (рисунок 1.2).
Техническое
обеспечение
Математическое
обеспечение
Информационное
обеспечение
АИС
Программное
обеспечение
Организационное
обеспечение
Правовое
обеспечение
Рисунок 1.2 - Структура АИС как совокупность обеспечивающих
подсистем
9
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Среди обеспечивающих подсистем обычно выделяют информационное,
техническое, математическое, программное, организационное и правовое
Дадим определение АСУ согласно ГОСТ 19675-74:
АСУ - это человеко-машинная система, обеспечивающая автоматизированный сбор и обработку информации, необходимой для оптимизации управления в различных сферах человеческой деятельности.
Структура
АИС
с
элементами
управления
может
иметь
вид,
представленный на рисунке 1.3.
База
данных
Информационная система
Блок
запросов
Блок
поиска
запрос
Блок
учета
транзакций
Администратор базы
данных
Управляющая система
Орган
управления
управляющая
информация
Исполняющий
орган
управляющие воздействия
информация
Управляемая система
об объекте
Управляемый
объект
Обратная
связь
внешние возбуждающие
воздействия
Рисунок 1.3 - Структурная схема АИС
10
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Анализ содержания и систематизация основных понятий АИС позволяют
выделить и определить ее обобщенные функции:
1)
вычислительную, своевременно и качественно выполняющую обра-
ботку информации во всех видах интересующих систему управления аспектах;
2)
следящую, отслеживающую и формирующую всю необходимую для
управления внешнюю и внутреннюю информацию;
3)
запоминающую, обеспечивающую непрерывное накопление, система-
тизацию, хранение и обновление необходимой информации;
4)
коммуникационную, обеспечивающую передачу нужной информации
между необходимыми пунктами;
5)
информирующую, реализующую быстрый доступ, поиск и выдачу не-
обходимой информации всех видов: научной, технической, экономической и
пр.;
6)
регулирующую, осуществляющую информационно-управляющее воз-
действие на объект управления и его звенья при отклонении параметров их
функционирования от заданных значений;
7)
оптимизирующую, обеспечивающую оптимальные плановые расчеты
и перерасчеты по мере измерения целей, критериев и условия функционирования системы;
8)
самоорганизующуюся, гибко изменяющую свою структуру и парамет-
ры для достижения вновь поставленных целей (в том числе для реализации цикла «исследование – разработка – внедрение – производство» с минимальными
затратами ресурсов);
9)
самосовершенствующуюся, накапливающую и анализирующую опыт
с целью обоснованного отбора лучших методов проектирования, производства и
управления, организационных форм осуществления мероприятий;
10) исследовательскую, обеспечивающую выполнение научных исследований производственных проблем, процессы создания новых видов техники и
технологии, а также формирование тематики целевых программ комплексных
научных исследований;
11
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
11) прогнозирующую, определяющую основные тенденции, закономерности и показатели развития производственных комплексов и окружающей среды;
12) анализирующую, определяющую основные показатели техникоэкономического уровня производства;
13) синтезирующую, обеспечивающую автоматизированную разработку,
проектирование и совершенствование конструкторско-технологических решений и сводных нормативов;
14) контролирующую, выполняющую автоматизированный контроль качества средств производства и выпускаемой продукции;
15) диагностирующую, обеспечивающую автоматизированный процесс
диагностики состояния объектов управления (в первую очередь технологического оборудования) и выявления ослабленных и ненадежных звеньев в объектах;
16) документирующую, обеспечивающую формирование всех необходимых
учетно-отчетных,
планово-распорядительных,
конструкторско-
технологических и других форм документов.
Анализ функций, выполняемых АИС, показателей качества и содержания
всех видов преобразуемой в производственном комплексе информации
позволяет
определить
основные
факторы,
совершенствование
которых
существенно зависит от качества информации.
Понятие о данных и информации
В этом разделе рассмотрим и обсудим два основных понятия – это данные
и информация, их взаимосвязь. Еще раз подчеркнем, что с философской точки
зрения эти понятия однозначно и до конца не определены. Чтобы отличить базу
данных от овощной базы необходимо,
прежде всего дать определение дан-
ных.
12
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Данными называют описание в сознании человека предметов, событий и
явлений окружающего мира. Существуют три основных формы описания и
дальнейшего представления данных: символьная; текстовая; графическая.
Символьная форма, основанная на использовании символов - букв, цифр,
знаков, является наиболее простой, но она практически применяется только
для передачи несложных сигналов
и
различных
событий.
(Например
-
сигналы светофора).
Более сложной является текстовая форма, в которой, как и в предыдущей
форме, используются символы - буквы, цифры, математические знаки. Однако
информация заложена не только в этих символах, но и в их сочетании, порядке
следования. Удобство текстовой информации обусловлено взаимосвязью текста
и речи человека.
Самой емкой и сложной является графическая форма представления информации. К этой форме относятся виды природы, фотографии, чертежи, схемы, рисунки.
Говоря о формах информации важно еще раз подчеркнуть свойство нематериальной информации - для ее существования обязательно должен быть какой-либо материальный объект: свет, воздух, вода, электрический ток, эфир
электромагнитных колебаний и т.д.
Итак, носителем информации может быть как непосредственно наблюдаемый
физический объект, так и энергетический субстрат. В последнем случае
информация представлена в виде сигналов световых, звуковых, электрических и
т.д.
При отображении на носителе информация кодируется, т.е. ей ставится в
соответствие форма, цвет, структура и другие параметры элементов носителя.
Примеры:
1. Почему человек различает цвета воспринимаемого изображения?
Потому, что простой белый цвет имеет частотные составляющие спектры
электромагнитных колебаний для цветов: красного, оранжевого, желтого, зеле-
13
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ного, голубого, синего, фиолетового. Сетчатка глаз способна различать частотные спектры цветности и сообщать сведения в мозг человека.
2. Книга - носитель кодированной последовательности букв, цифр, символов, графики. Читая книгу, мы как раз и воспринимаем информацию, записанную на ее страницах, в виде
щих
кодовых
комбинаций
из последовательности символов (букв,
(слов),
состоя-
цифр) принятого алфавита.
То же самое можно сказать и относительно информации, сообщаемой в процессе устной речи.
В теории информатики особого внимания заслужила наиболее стандартная и единая форма представления информации - двоичная форма. Она заключается в записи любой информации в виде последовательности только двух
символов:
1, или «да», или «истина»; 0, или «нет», или «ложь». В ЭВМ эти
символы обозначаются наличием либо отсутствием в рассматриваемой точке
электрического или магнитного импульса. В этом случае реквизитом информации, т.е. самой малой порцией информации (меньше не может быть) является
ответ на любой вопрос в виде «да» или «нет». Эта порция определяет единицу
измерения информации, называемую «битом». Последовательность битов может иметь различную разрядность. Запись нулей и единиц производится по правилам кодирования, используемых в ЭВМ.
Поясняя определение данных, мы
непроизвольно стали использовать
термин информация. Уясним взаимосвязь этих двух терминов.
Мы с вами уяснили, что информация - это первичное понятие, точного
определения которого не существует.
Информация (от латинского «informatio» - «разъяснение, изложение,
осведомлѐнность») - сведения о чѐм-либо, независимо от формы их представления.
Существует четыре основных направлений толкования термина информация:
1. Информация - это смысл полученного сообщения, его интерпретация.
14
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Пример учителя и ученика. Учитель имеет информацию о предмете. С
помощью сообщений (рассказ с показом, демонстрация) передает ученику сведения, данные. Ученик получает сообщения и усваивает их. То, что он понял
со своей точки зрения и есть информация. Степень адекватности реальному образу проверяется учителем контрольным опросом. В этом отношении компьютер никогда не оценивает смысл информации, ему все равно с какими данными
работать. Только человек имеет возможность получить информацию на основе
данных компьютера.
2. Информация - это как содержание сообщений, так и само сообщение,
данные. В этом смысле примером может служить книга с ценными для потребителя
сведениями, газета, кодограмма и т.п.
3. Некоторые ученые и, прежде всего, философы считают, что информация - это третья составляющая основ мироздания (материя, энергия и информация).
Н. Винер в одной из работ написал: «Информация есть информация, а не
материя и энергия».
4. В математической теории информации понятие информация определяется только для случайных событий. В этом отношении информация - это то,
что уменьшает неопределенность события.
Приведем пример: Компьютер с помощью генератора случайных чисел
выдал число от 1 до 16. Наша задача угадать это число. Мы задаем вопросы
компьютеру, а он отвечает «да» (истина, 1) или «нет» (ложь, 0). За какое минимальное количество вопросов можно отгадать число? Сколько нужно информации, чтобы угадать загаданное число? Неопределенность равна 16. Первый вопрос: задуманное число меньше 9? Ответ «да» или «нет» уменьшает неопределенность в два раза и мы получаем информацию, равную одному биту. Если
число находится в пределах от 9 до 16, то мы задаем вопрос: число меньше 13 ?
Получаем ответ и еще один бит информации и т.д. Итого, количество информации, необходимое для угадывания числа равно 4 битам.
15
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Подведем итоги и решим проблемный вопрос в однозначном понятии
информации:
1) под словом «информация» (в переводе с латинского «Information»)
понимается разъяснение, изложение, чего-либо, сообщение о чем-либо;
2) ответьте на вопрос - материальна или нематериальна информация? Будем понимать так, информация не материальна, но информация является свойством материи и не может существовать без своего материального носителя средства переноса ее в пространстве и во времени.
Рассмотрим взаимосвязь двух понятий – данных и информации. Если
рассматривать процесс передачи данных от источника данных до потребителя
(рисунок 1.4), то можно сделать вывод о том, что источник в виде базы данных содержит большое количество различных данных, а потребителю информации нужна определенная и необходимая ему информация о конкретной
предметной области.
Канал связи
Источник
получатель
данных
информации
Рисунок 1.4 – Взаимосвязь данных и информации
Исходя из данной взаимосвязи мы можем дать свое определение информации. Информация – это необходимые для получателя данные, переданные по
каналу связи от источника данных своевременно и достоверно.
Количество и качество информации – как их анализировать7
16
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
В предыдущем разделе мы дали определение информации исходя из взаимосвязи данных и информации, при этом указали два показателя качества информации – достоверность и своевременность. Возникает проблемный вопрос –
как анализировать и оценивать качество и количество информации.
В свете идей науки о знаковых системах – семиотики адекватность информации, т.е. соответствие содержания образа отображаемому объекту, может
выражаться в трех формах: синтаксический, семантический и прагматический.
Синтаксическая адекватность связана с воспроизведением формальноструктурных характеристик отражения независимо от смысловых и потребительских параметров объекта. На синтаксическом уровне учитываются тип носителя и способ представления информации, скорость ее передачи и обработки,
размеры кодов представления информации, надежность и точность преобразования этих кодов и т.п. Информацию, рассматриваемую только с синтаксических позиций, обычно называют данными.
Семантическая адекватность выражает аспект соответствия образа, знака и объекта, т.е. отношение информации и ее источника. Проявляется семантическая информация при наличии единства информации (объекта) и пользователя. Семантический аспект имеет в виду учет смыслового содержания информации; на этом уровне анализируются те сведения, которые отражает информация, рассматриваются смысловые связи между кодами представления информации.
Прагматическая адекватность отражает отношение информации и потребителя, соответствие информации цели управления, которые на ее основе
реализуется. Прагматический аспект связан с ценностью, полезностью использования информации для выработки правильного управленческого решения. С
этой точки зрения анализируются потребительские свойства информации.
В соответствии с тремя формами адекватности выполняется и измерение
информации. Терминологически принято говорить о количестве информации и
об объеме данных.
17
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Синтаксические меры информации. Определение количества информации
на синтаксическом уровне невозможно без рассмотрения понятия неопределенности состояния системы (энтропии системы).
Действительно, получение информации о какой-либо системе всегда связано с изменением степени неосведомленности получателя о состоянии этой системы. До получения информации получатель мог иметь некоторые предварительные (априорные) сведения
о системе
. Мера неосведомленности о си-
стеме H ( ) и является для него мерой неопределенности состояния системы.
После получения некоторого сообщения получатель приобретает
некоторую
дополнительную информацию I ( ), уменьшающую его априорную неосведомленность так, что апостериорная (после получения сообщения ) неопределенность состояния системы становится равной H ( ). Тогда количество информации I ( ) о системе , полученное в сообщении , определится как:
I ( ) = H ( ) – H ( ),
т.е. количество информации измеряется изменением (уменьшением) неопределенности состояния системы.
Если конечная неопределенность H ( ) обратится в нуль, то первоначальное неполное знание заменится полным знанием и количество информации
станет равным:
I ( ) = H ( ).
Иными словами, энтропия системы H ( ) может рассматриваться как мера
недостающей информации. Энтропия системы H ( ), имеющей N возможных
состояний согласно формуле ШЕННОНА, равна:
N
H( )=–
Pi log Pi,
i=1
где: Pi –вероятность того, что система находится в i-м состоянии.
18
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Для случая, когда все состояния системы равновероятны, ее энтропия
определяется по формуле:
N
1
H( )=–
log
1
log N .
i-1
Рассмотрим пример. По каналу связи передается n- разрядное сообщение,
использующее m различных символов.
Так как количество всевозможных кодовых комбинаций определяется по
формуле N = mn, то при равной вероятности появления любой из них количество информации, приобретенной абонентом в результате получения сообщения, будет определяться по формуле ХАРТЛИ:
I = log N = n log m.
Если в качестве основания логарифма принять m, то формула упростится
и количество информации станет равным:
I = n.
В данном случае количество информации (при условии полного априорного незнания абонентном содержания сообщения) будет равно объему данных
I = Vд, полученных по каналу связи.
Наиболее часто используются двоичные и десятичные логарифмы. Единицами измерения в этих случаях будут соответственно «бит» и «дит».
Степень информативности сообщения определяется отношением количества информации к объему данных, т.е.
Y = 1/ Vд , причем 0 Y 1,
где: Y – характеризует лаконичность сообщения.
С увеличением Y уменьшаются объемы работы по преобразованию информации (данных) в системе. Поэтому стремятся к повышению информатив-
19
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ности, для чего разрабатываются специальные методы оптимального кодирования информации.
Семантическая мера информации. Синтаксические меры количества информации в общем случае не могут быть непосредственно использованы для
измерения смыслового содержания, ибо имеют дело с обезличенной информацией, не выражающей смыслового отношения к объекту.
Для измерения смыслового содержания информации, т.е. ее количества на
семантическом уровне наибольшее признание получила тезаурусная мера информации, предложенная Ю.И. ШНЕЙДЕРОМ. Он связывает семантические
свойства информации прежде всего со способностью пользователя принимать
поступившее сообщение. Используется понятие «тезаурус пользователя». Тезаурус можно трактовать как совокупность сведений, которыми располагает данная система, пользователь.
В зависимости от соотношений между смысловым содержанием инфор
мации S и тезаурусом пользователя Sn изменяется количество семантической
информации Jc, воспринимаемой пользователем и включаемой им в дальнейшем
в свой тезаурус.
При Sn
0 пользователь не воспринимает, не понимает поступающую ин-
формацию; при Sn
пользователь все знает, и поступающая информация ему
не нужна: и в том, и в другом случае Jc 0. Максимальное значение Jc приобре
тает при согласовании S c тезаурусом Sn (Sn – Sn opt), когда поступающая информация понятна пользователю и несет ему ранее не известные (отсутствующие в
его тезаурусе) сведения ( рисунок 1.5).
Следовательно,
количество семантической информации в сообщении,
количество новых знаний, получаемых пользователем, является величиной относительной. Одно и то же сообщение может иметь смысловое содержание для
компетентного пользователя и быть бессмысленным (семантический шум) для
пользователя некомпетентного.
В то же время понятная, но известная компетентному пользователю информация представляет собой для него тоже семантический шум.
20
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 1.5 - Зависимость Jc = f (Sn)
При разработке информационного обеспечения АИС следует стремиться к

согласованию величины S и Sn так, чтобы циркулирующая в системе информация была понятна, доступна для восприятия и обладала наибольшей содержательностью S, т.е.
S = Jc/Vд.
Прагматическая мера информации – это ее полезность, ценность для
управления. Эта мера также величина относительная, обусловленная особенностями использования этой информации в той или иной системе.
Ценность информации целесообразно измерять в тех же самых единицах
(или близких к ним), в которых измеряется целевая функция управления системой. В автоматизированной системе управления производством, например, ценность информации определяется эффективностью осуществляемого на ее основе экономического управления:
Jn ( ) =
( / )-
( ),
где: Jn ( ) – ценность информационного сообщения
для системы управ-
ления ;
( ) – априорный ожидаемый экономический эффект функционирования системы управления ;
21
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
( / ) - ожидаемый эффект функционирования системы при условии, что для управления будет использована информация, содержащаяся в сообщении .
Поскольку экономический эффект функционирования АИС складывается
из экономического эффекта решения отдельных функциональных задач, то для
вычисления Jn следует определить:
используется информация
-множество задач, для решения которых
; F – частоту решения каждой задачи за период
времени, для которого оценивается экономический эффект; R - степень влияния информационного сообщения
на точность решения задачи, 0 R
1.
Тогда:
Z
Jn ( ) =
( / )-
( )=
Fi R
j
j
j=1
где: Пj – экономический эффект от решения j-й задачи в системе.
В такой постановке единицей измерения ценности информации АИС является обычно рубль.
Качество информации. Информация в АИС является и предметом труда и
продуктом труда, поэтому от ее качества существенно зависят эффективность и
качество функционирования системы.
Качество информации можно определить как совокупность свойств, обусловливающих возможность ее использования для удовлетворения определенных в соответствии с ее назначением потребностей.
Возможность и эффективность использования информации для управления обусловливается такими ее потребительскими показателями качества, как
репрезентативность, содержательность, полнота, доступность, актуальность,
своевременность, устойчивость, точность, достоверность и ценность.
Репрезентативность информации связана с правильностью ее отбора и
формирования с целью адекватного отражения заданных свойств объекта. Важ22
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
нейшее значение здесь имеют: правильность концепции, на базе которой сформулировано исходное понятие; обоснованность отбора существенных признаков
и связей отображаемого явления; правильность методики измерения и алгоритма формирования информации.
Содержательность информации – это ее удельная семантическая емкость, равная отношению количества семантической информации в сообщении
к объему данных, его отображающих, т.е. S = Ic/Vд. С увеличением содержательности информации растет семантическая пропускная способность информационной системы, так как для получения одних и тех же сведений требуется
преобразовать меньший объем данных.
Полнота информации означает, что она содержит минимальный, но достаточный для принятия правильного управленческого решения состав (набор
показателей). Как неполная, т.е. недостаточная для принятия правильного решения, так и избыточная информация снижают эффективность управления;
наивысшим качеством обладает именно полная информация.
Доступность информации для восприятия при принятии управленческого
решения в АИС обеспечивается выполнением соответствующих процедур ее
получения и преобразования. Так, назначением автоматизированной системы
обработки данных и является увеличение ценности информации путем согласования ее с тезаурусом пользователя, т.е. преобразование ее к доступной и удобной для восприятия управляющими органами форме.
Актуальность определяется степенью сохранения ценности информации
для управления в момент ее использования и зависит от статистических характеристик отображаемого объекта (от динамики изменения этих характеристик) и
от интервала времени, прошедшего с момента возникновения данной информации.
Своевременной является такая информация, которая может быть учтена
при выработке управленческого решения без нарушения установленной процедуры и регламента, т.е. такая информация, которая поступает на тот или иной
23
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
уровень управления не позже заранее назначенного момента времени, согласованно со временем решения задачи управления.
Устойчивость есть свойство управляющей информации реагировать на
изменения исходных данных, сохраняя необходимую точность. Устойчивость
информации, как и ее репрезентативность, обусловлены методической правильностью ее отбора и формирования.
Точность информации определяется степенью близости отображаемого
информацией параметра и истинного значения этого параметра.
Для экономических показателей, отображаемых цифровым кодом, известны четыре классификационных понятия точности:
формальная точность, измеряемая значением единицы младшего разряда
числа, которым показатель представлен;
реальная точность, определяемая значением единицы последнего разряда
числа, верность которого гарантируется;
достижимая точность, - максимальная точность, которую можно получить
в данных конкретных условиях функционирования системы;
необходимая точность, определяемая функциональным назначением показателя.
Достоверность информации – это свойство информации отражать реально существующие объекты с необходимой точностью. Измеряется достоверность информации доверительной вероятностью необходимой точности, т.е. вероятностью того, что отображаемое информацией значение параметра отличается от истинного значения этого параметра в пределах необходимой точности.
Наряду с понятием «достоверность информации» существует понятие
«достоверность данных» т.е. информация, рассматриваемой в синтаксическом
аспекте. Под достоверностью данных понимается их безошибочность; измеряется она вероятностью появления ошибок в данных.
Ценность информации – комплексный показатель ее качества, ее мера на
прагматическом уровне.
24
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Исследования показывают, что для целевой функции оптимизация функционирования методически правильно спроектированной информационной системы в качестве ограничений, обусловливаемых параметрами качества информации, достаточно использовать ограничения только по полноте, своевременности и достоверности.
Понятие о базах данных
Термин база данных (database) страдает от обилия различных интерпретаций. Он использовался ранее для обозначения чего угодно — от обычной
картотеки до многих томов данных, которые правительство собирает о своих
гражданах.
Рассмотрим некоторые из них.
Определение 1. База данных – это компьютезированная система хранения
информации, основная цель которой содержать информацию и предоставлять
еѐ по требованию.
Определение 2. База данных – это хранение структурированных данных,
при этом данные должны быть не противоречивыми, минимально избыточными
и целостными.
В настоящее время действует Закон «О правовой охране программ для
ЭВМ и баз данных» от 23.09.92 г. В нем дается определение БД:
Определение 3. База данных - это объектная форма представления и организации совокупности данных (например, статей, расчетов), систематизированных таким образом, чтобы эти данные могли быть найдены и обработаны с помощью ЭВМ.
Определение 4. База данных – это набор интегрированных записей с само- описанием.
Определение 5. База данных – это организованная в соответствии с определенными правилами и поддерживаемая в памяти компьютера совокупность
данных, характеризующая актуальное состояние некоторой предметной области
25
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
и используемая для удовлетворения информационных потребностей пользователей.
Определение 6. База данных — именованная совокупность данных, отражающая состояние объектов и их отношений в рассматриваемой предметной
области.
Определение 7. База данных — это совокупность сведений (о реальных
объектах, процессах, событиях или явлениях), относящихся к определенной теме или задаче, организованная таким образом, чтобы обеспечить удобное представление этой совокупности как в целом, так и любой ее части.
В Толковом словаре по вычислительным системам дается следующее
определение:
Определение 8. База данных, в обычном, строгом смысле слова — файл
данных, для определения и обращения к которому используются средства
управления базой данных.
Рассмотрим определение базы данных Дэвида Кренке, который предложил использовать термин база данных в следующей формулировке:
Определение 9. База данных — это самодокументированное собрание интегрированных записей.
Возьмем данное определение за основное, как самое лаконичное и объемное. Обсудим данное определение.
База данных является самодокументированной (self-describing) если она
содержит, в дополнение к исходным данным пользователя, описание собственной структуры. Это описание называется словарем данных (data dictionary), каталогом данных ( data directory ) или метаданными (metadata).
Интегрированность записей проявляется в стандартной иерархии данных,
которая выглядит следующим образом: биты объединяются в байты, или символы; символы группируются в поля; из полей формируются записи; записи организуются в файлы.
Информационная технология баз данных была разработана для того, чтобы преодолеть ограничения, свойственные системам обработки файлов. Чтобы
26
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
понять, каким образом это было сделано, сравните систему обработки файлов
(рисунок 1.6) с системой обработки базы данных (database processing system).
Рисунок 1.6 – Иерархия данных в системах баз данных
Программы обработки файлов обращаются непосредственно к файлам
данных. В отличие от них, программы обработки баз данных для доступа к данным вызывают системы управления БД. Это отличие важно тем, что оно упрощает прикладное программирование: программистам больше не нужно задумываться о том, как физически организовано хранение данных, и они могут смело
сконцентрироваться на вопросах, представляющих важность для пользователя, а
не для компьютерной системы.
В зависимости от вида организации данных различают следующие основные модели представления данных в базе: иерархическую; сетевую; реляционную.
Иерархические модели данных имеют древовидную структуру, когда
каждому узлу структуры соответствует один сегмент, представляющий собой
поименованный линейный кортеж полей данных. Каждому сегменту соответствует один входной и несколько выходных сегментов (рисунок 1.7,а). Каждый
27
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
сегмент структуры лежит на единственном иерархическом пути, начинающемся
от корневого сегмента.
Ри-
сунок
1.7 - Струк-
Структура иерархической (а) и сетевой (б) БД
Сетевая модель БД во многом подобна иерархической. Отличие заключается в том, что в сетевой модели для сегментов допускается несколько входных сегментов наряду с возможностью наличия сегментов без входов с точки
зрения иерархической структуры.
На рисунке 1.7,б представлен простой пример сетевой структуры, полученной на основе модификации иерархической структуры.
Реляционной моделью БД называется модель, в которой средства управления БД поддерживают реляционную (табличную) структуру данных. Концепция реляционной
модели была предложена в 1970 г. Эдгаром Коддом и
имеет в настоящее время большое значение в деле организации работы с БД.
Данная модель позволяет представить все данные в виде двумерного массива в виде таблиц, соответствующих какому-то определенному объекту или
действию, называемым сущностью. Основой реляционных баз данных является
28
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
таблица В таблице 1.2 представлены термины, которые используют различные
специалисты по базам данных.
Таблица 1.2
Заказчик,
пользователь
Таблица
Столбец
Строка
Количество столбцов
Количество строк
Системный аналитик,
Программист
проектировщик
Сущность, отношение
Файл
Поле
Атрибут
Запись
Кортеж
Арность
Степень
Мощность
Кардинальное число
Системы управления базами данных (СУБД)
СУБД представляет собой совокупность лингвистических и программных
средств, предназначенных для создания, ведения и совместного использования
БД многими пользователями.
В Толковом словаре по вычислительным системам
дано следующее по-
нятие СУБД:
Система управления базой данных — система программного обеспечения,
имеющая средства обработки на языке базы данных, позволяющая обрабатывать обращения к базе данных, которые поступают от прикладных программ и
(или) конечных пользователей, и поддерживать целостность базы данных.
Вопросы для самоконтроля:
1. Что называется данными?
2. Дайте определение и толкования термина «информация».
3. Что называется базами данных?
4. Как определить качество информации?
5. Какие показатели качества информации вы знаете?
6. Что означает тезаурус пользователя информации?
7. Какие модели данных вы знаете?
8. Дайте характеристику реляционных баз данных?
9. Что называется системой управления БД?
29
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
1.2 Назначение, структура и основные компоненты СУБД Access
Предыдущий материал был посвящен уяснению основных понятий, терминов и определений системы баз данных. Предметом дальнейшего и последовательного обучения будет система управления базами данных. СУБД стала
неотъемлемой частью баз данных, что непроизвольно привело к отождествлению двух понятий – базы данных и системы управления базами данных. Не заостряя данную проблему рассмотрим общие теоретические и практические вопросы на примере конкретной СУБД «Access», входящей в состав приложений
офиса MS Windows.
Введение
Цель предстоящего изучения состоит в том, чтобы заложить основу для
дальнейшего и более детального изучения методик и правил работы в информационной технологии с использованием СУБД. В настоящее время существует
достаточно много типов СУБД: Access, InterBase, FoxPro, Oracle, Paradox, SQLServer, Informix, Ingres и др. Современный этап автоматизации предприятий
всех уровней в России предусматривает обязательную разработку и внедрение
баз данных в информационное обеспечение производства. Это обстоятельство
обусловливает особую актуальность и необходимость изучения этого учебного
материала. Уясним и изучим назначение СУБД, ее структуру и компоненты.
Назначение СУБД
В понятийных терминах мы определили СУБД как совокупность лингвистических и программных средств, предназначенных для создания, ведения и
совместного использования БД многими пользователями.
За основное определение СУБД взяли определение из Толкового словаря
по вычислительным системам: Система управления базой данных — система
программного обеспечения, имеющая средства обработки на языке базы дан30
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ных, позволяющая обрабатывать обращения к базе данных, которые поступают
от прикладных программ и (или) конечных пользователей, и поддерживать целостность базы данных.
Дополним эти понятия задачами и функциями, которые выполняются с
помощью СУБД.
Чем отличается база данных от кучи данных?
Основное отличие состоит в том, что набором данных, входящих в состав
базы данных управляет специальная системная программа, называемая системой управления базами данных, которая обладает знаниями по поводу структурной организации разнородных данных.
Располагается СУБД между собственно физической организацией БД и
приложением пользователя системы.
Установленная на компьютере СУБД автоматизировано выполняет
следующие общие задачи:
добавление новой информации в существующие файлы БД;
добавление новых пустых файлов в БД;
изменение (модификация) информации в существующих файлах БД;
поиск информации в БД;
удаление информации из существующих файлов БД;
удаление файлов из БД.
Если говорить более детально, то к функциям СУБД можно отнести следующие:
управление созданием базы данных - функция, позволяющая с помощью
языка определения данных DDL (Data Definition Language) создавать структуру,
тип данных, ограничения и связи между данными;
управление
манипулированием
данными
–
функция,
позволяющая
вставлять, обновлять, удалять и извлекать информацию из БД (Insert, Update,
Delete,
Read).
Эти
операции
осуществляются
с
помощью
языка,
31
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
принадлежащего группе DML (Data Manipulation Language). К этой группе
языков относится и язык запросов SQL (Structure Query Language);
управление данными непосредственно в БД - функция, обеспечивающая
хранение данных, непосредственно входящих в БД и служебной информации,
обеспечивающей работу СУБД;
управление данными в памяти компьютера - функция, связанная в
первую очередь с тем, что СУБД работают с БД большого размера. В целях
ускорения работы СУБД используется буферизация данных в оперативной памяти компьютера. При этом пользователь СУБД использует только необходимую для его конкретной задачи часть БД, а при необходимости получает новую
"порцию" данных;
управление транзакциями - функция СУБД, которая производит ряд операций над БД как над единым целым. Как правило, такие операции производятся в памяти компьютера. В первую очередь транзакции необходимы для поддержания логической целостности БД в многопользовательских системах. Если
транзакция (манипуляция над данными) успешно выполняется, то СУБД вносит
соответствующие изменения в БД. В обратном случае ни одно из сделанных изменений никак не влияет на состояние БД;
управление изменениями в БД и протоколирование - функция, связанная с
надежностью хранения данных, то есть возможностью СУБД восстанавливать
состояние БД в аварийных ситуациях, например, при случайном выключении
питания или сбое носителя информации. Очевидно, что для восстановления БД
нужно располагать дополнительной информацией, с помощью которой и осуществляется восстановление. С этой целью ведется протокол изменений БД, в который перед манипуляциями с данными делается соответствующая запись. Для
восстановления БД после сбоя СУБД используется протокол и архивная копия
БД - полная копия БД к моменту начала заполнения протокола;
поддержка языков БД - для работы с БД используются специальные языки, в целом называемые языками баз данных. В СУБД обычно поддерживается
единый язык, содержащий все необходимые средства - от создания БД до обес32
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
печения пользовательского интерфейса при работе с данными. Наиболее распространенным в настоящее время языком СУБД является язык SQL (Structured
Query Language) – структурированный язык запросов.
Обеспечение безопасности данных – функция, обеспечивающая контролируемый доступ к данным с помощью следующих средств:
- системы обеспечения безопасности, предотвращающей несанкционированный
доступ к данным БД со стороны посторонних пользователей;
- системы поддержки целостности данных, обеспечивающей непротиворечивое
состояние хранимых данных;
- системы управления параллельной работой приложений, контролирующей
процессы их совместного доступа к БД;
- системы восстановления, позволяющей восстановить БД до предыдущего непротиворечивого состояния, нарушенного в результате сбоя аппаратного или
программного обеспечения;
- доступного пользователям каталога, содержащего описание хранимой в БД
информации (метаданные).
Основная функция, реализованная и выполняемая во всех типах СУБД предоставление пользователю БД возможности работать с ней, не вникая в детали на уровне аппаратного обеспечения.
Структура систем управления базами данных
Большинство современных СУБД включает следующие пять основных
структурных блоков (рисунок 1.8), обеспечивающих работу с БД широкому
кругу прикладных процессов.
Остановимся несколько детальнее на каждом из этих структурных блоков. В общем случае лингвистическое обеспечение СУБД включает ряд языков,
обеспечивающих интерфейс с банком данных пользователям различного уровня. Из данных языковых средств можно выделить две основные группы: языки
описания данных (ЯОД) и языки работы с БД (ЯрБД). Группа ЯОД предназна33
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
чена для описания структур данных и отношений между ними, поддерживаемых СУБД. Каждая конкретная СУБД располагает своим ЯОД, но все ЯОД
поддерживают один и тот же набор основных функций.
СУБД
Язык описания данных
(ЯОД)
Предназначение
Описание структуры файлов БД,
записей файлов и их полей данных
Язык работы с БД
(ЯрБД)
Получение ответа на санкционированный
запрос пользователя или БД-приложения
Общие утилиты для БД
Выполнение общих процедур по
поддержанию БД в актуальном состоянии
Генераторы
БД-приложений
Генераторы
отчетов
Создание модульных систем решения задач
пользователя по работе с БД
Вывод результатов работы в виде отчетов
Рисунок 1.8 - Состав основных компонент СУБД
Среди лингвистических средств СУБД центральное место занимают
ЯрБД, спектр которых весьма широк по их уровню синтаксическо - семантической организации, реализации и назначению. Языки данной группы позволяют
не только организовывать запросы из БД нужной информации, но и программировать нужные БД-приложения.
Набор общих утилит предназначен для обеспечения наиболее часто используемых процедур работы с данными и файлами БД (редактирование данных, удаление записей, создание новых файлов и т.д.). В этом отношении средства данной группы обеспечивают общие функции поддержания БД в актуальном состоянии, подобно тому, как это делают утилиты MS-DOS для обеспечения
работы с ее файловой структурой.
Генератор приложений представляет собой компоненту СУБД, обеспечивающую пользователя средствами создания простейших БД-приложений
34
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
без их программирования. На основе описания задачи генератор из программных модулей, находящихся в специальных библиотеках, компилирует (собирает
и редактирует) программную систему, обеспечивающую решение поставленной
задачи.
Наконец, генераторы отчетов позволяют выводить результаты работы с
БД в виде отчетов, оформленных по требованию пользователя, используя достаточно простой язык (командный, табличный и др.).
На рисунке 1.9 показаны основные компоненты системы базы данных.
Базу данных обрабатывает СУБД, которая используется разработчиками и пользователями, обращающимися к СУБД напрямую или косвенно, через прикладные программы.
Как нам уже известно из первой лекции база данных состоит из четырех
основных элементов: данных пользователя, метаданных, индексов и метаданных приложений.
Рисунок 1.9 – Компоненты системы базы данных
35
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Данные пользователя
Сегодня большинство баз данных представляют данные пользователя в
виде отношений (relations). Столбцы таблицы содержат поля, или атрибуты, а
строки содержат записи о конкретных объектах предметной области. В качестве
примера на рисунке 1.10 показана таблица «Студент», где в столбцах таблицы
указаны атрибуты: номер группы, номер студента, ФИО, год рождения и адрес.
В строках заполняются кортежные записи, однозначно характеризующие каждого студента.
Рисунок 1.10 – Отношение «Студент»
Все таблицы, имеющиеся в данных пользователя связываются схемой
взаимосвязи (рисунок 1.11) по ключевым атрибутам. Ключевым атрибутом или
ключем называют такой атрибут (например, характеристику студента), который
однозначно идентифицирует каждый экземпляр сущности (каждого студента). В
данном примере номер студента (номер его зачетной книжки) однозначно определяет каждого студента. Если мы возьмем в качестве ключа фамилию студента,
то может возникнуть путаница в случае наличия двух и более студентов по фамилии Иванов и мы будем задавать себе вопрос – какой Иванов нам нужен?
36
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 1.11 – Схема связи таблиц данных пользователя
Метаданные
Как было указано в первой лекции, база данных является самодокументированной, то есть одной из ее составляющих является описание собственной
структуры. Это описание называется метаданными. Так как СУБД предназначены для хранения таблиц и манипулирования ими, большинство из них хранят
метаданные в форме таблиц, иногда называемых системными таблицами.
В таблице 1.3 представлен пример хранения метаданных в системных
таблицах. В таблице, называемой SysTables, перечислены все таблицы, имеющиеся в базе данных, и для каждой таблицы указаны количество столбцов и
имена одного или нескольких столбцов, служащих первичным ключом.
37
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Таблица 1.3 - Таблица Sys Tables
Имя таблицы
Число столбцов
Первичный ключ
Студент
Преподаватель
Кафедра
6
6
4
Номер Студента
Табельный Номер
Код Кафедры
В таблице 1.4 перечислены столбцы, имеющиеся в каждой таблице, а также тип данных и ширина каждого столбца. Эти две таблицы представляют собой типичные образцы системных таблиц, в других подобных таблицах хранятся списки индексов, ключей, хранимых процедур и т. п.
Таблица 1.4 - Таблица Sys Columns
Имя столбца
Номер группы
Номер студента
ФИО
Год рождения
Адрес
Балл при поступлении
Таб-номер
ФИО
Год рождения
Ученая степень
Ученое звание
Код кафедры
Код кафедры
Название
Телефон
Имя таблицы
Тип данных
Студент
Студент
Студент
Студент
Студент
Студент
Преподаватель
Преподаватель
Преподаватель
Преподаватель
Преподаватель
Преподаватель
Кафедра
Кафедра
Кафедра
Числовой
Числовой
Текстовый
Дата/время
Текстовый
Числовой
Числовой
Текстовый
Дата/время
Текстовый
Текстовый
Числовой
Числовой
Текстовый
Текстовый
Длина
(байт)
4
10
25
10
30
2
10
25
25
15
10
10
10
20
15
Хранение метаданных в таблицах не только эффективно для СУБД, но и
удобно для разработчиков, поскольку для запроса метаданных они могут использовать те же самые средства, что и для запроса пользовательских данных.
38
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Индексы
Третий тип данных, которые хранятся в базе данных, предназначен для
улучшения ее производительности и доступности. Индексы используются в
двух основных случаях. В первом случае они используются для ускорения процесса сортировки данных по выбранному аргументу. Например, если мы поставим индекс на фамилию студента, то в таблице все фамилии будут указаны в
алфавитном порядке, если мы поставим индекс на номер студента, то в таблице
студенты будут отсортированы (упорядочены) в порядке возрастания номеров и
т.п.
Индексы используются не только для сортировки, но и для быстрого доступа к данным. Пусть, например, пользователю нужны сведения только о тех
студентах, чьей специальностью являются информационные системы. Без индекса пришлось бы проводить поиск по всей таблице. Имея же индекс, можно
найти в нем соответствующую запись и использовать ее для нахождения нужных строк в таблице.
Метаданные приложений
Четвертый тип информации в базе данных — это метаданные приложений (application metadata), которые описывают структуру и формат пользовательских форм, отчетов, запросов и других компонентов приложений. Большинство современных СУБД хранят эту информацию в базе данных. Следует
учесть, что ни разработчики баз данных, ни пользователи не обращаются к метаданным приложений напрямую, а пользуются соответствующими средствами,
которые предоставляет СУБД.
СУБД
СУБД значительно различаются по своим характеристикам и функциям.
Первые СУБД были разработаны для больших ЭВМ в конце 1960-х годов и были весьма большими и примитивными. С тех пор СУБД постоянно совершен39
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ствовались, а функции их расширялись. Усовершенствования касались не только обработки баз данных, но и также снабжались функциями, упрощающими
создание приложений баз данных. В нашей лекции для иллюстрации возможностей СУБД мы будем использовать Мicrosoft Access. Это обусловлено тем, что
Ассеss является приложением офиса операционной системы, а также обладает
всеми типичными характеристиками и функциями современной СУБД.
Как видно из рисунка 1.12, характеристики и функции СУБД можно
разделить на три подсистемы: подсистему средств проектирования, подсистему
средств обработки и ядро СУБД.
Подсистема средств проектирования
Подсистема средств проектирования (design tools subsystem) представляет
собой набор инструментов, упрощающих проектирование и реализацию баз
данных и их приложений. Как правило, этот набор включает в себя средства для
создания таблиц, форм, запросов и отчетов. В СУБД имеются также языки программирования и интерфейсы для них. Например, в Ассеss есть два языка: макроязык, не требующий глубокого знания программирования, и версия языка
Visual Basic.
Подсистема обработки
Подсистема обработки (run-time subsystem) занимается обработкой компонентов приложения, созданных с помощью средств проектирования. Например, в Ассеss имеется компонент, материализующий формы и связывающий
элементы форм с данными таблиц.
На рисунке 1.13 показан пример формы, созданный на основе данных из
разных таблиц, при этом, как показано на рисунке, может быть построена главная форма, а в нее встроена подчиненная форма.
40
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 1.13 – Форма представления данных
Все это делается автоматизировано в режиме диалога с мастером форм.
Другие процессоры подсистемы обработки предназначены для выполнения запросов и вывода отчетов. На рисунке 1.14 показан пример отчета «Список
студентов», построенного на основе запроса.
Рисунок 1.14 – Пример отчета «Список студентов»
41
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Кроме того, в подсистеме обработки имеется компонент, обрабатывающий запросы прикладных программ на чтение и запись данных в базу.
Ядро СУБД
Третий компонент СУБД — это ее ядро (DBMS engine), которое выполняет функцию посредника между подсистемой средств проектирования, подсистемой обработки и данными. Ядро СУБД получает запросы от компонентов,
выраженные в терминах таблиц, строк и столбцов, и преобразует эти запросы в
команды операционной системы, выполняющие запись и чтение данных с физического носителя.
Кроме того, ядро СУБД участвует в управлении транзакциями, блокировке, резервном копировании и восстановлении данных.
Ядро СУБД помогает координировать действия, с тем чтобы либо выполнялись все действия в группе, либо вовсе не выполнялись.
Для Access может быть представлено два различных ядра: Jet Engine и
SQL Server. Ядро первого типа используется для небольших персональных и
коллективных баз данных. Ядро SQL Server, представляющее собой независимый продукт Microsoft, предназначено для крупных баз данных.
Объекты СУБД Access
В базе данных Access основными объектами являются таблицы, запросы,
формы, отчеты, макросы и модули.
На рисунке 1.15 показана взаимосвязь между объектами Access. Дадим
краткую характеристикам объектам.
Таблица – это основной, базовый объект, который используется для хранения данных. Каждая таблица содержит информацию о субъектах (предметах)
определенного типа (например, клиентах). Поля (столбцы) таблицы служат для
хранения различных характеристик субъектов (например, фамилий и адресов), а
42
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
каждая запись (строка) содержит сведения о конкретном субъекте (например,
данные о конкретном студенте). Для каждой таблицы можно определить первичный ключ (одно или несколько полей, имеющих уникальные для каждой записи значения) и один или несколько индексов, ускоряющих доступ к данным.
Запрос – это объект, позволяющий пользователю получить нужные данные из одной или нескольких таблиц с указанием условий отбора данных.
Для определения простого запроса можно использовать бланк запроса по
образцу или запроса на выборку - QBE (Query By Example).
Сложные запросы создаются с помощью инструкции структурированного
языка запросов SQL, когда необходимо выбрать данные из разных таблиц, при
этом используется математический инструмент реляционной алгебры (алгебры
логики), позволяющий манипулировать данными (склеивать, разрезать).
В Access можно создавать перекрестный запрос, позволяющий получить
информацию в виде сводной таблицы (например, данные о заработной плате
сотрудников по месяцам, или расписание экзаменов, или график отпусков сотрудников предприятия и т.п.).
В Access можно конструировать и выполнять запросы – действия. К ним
относятся запросы на обновление, удаление или добавление данных. С помощью запросов можно также создавать новые таблицы, используя данные из одной или нескольких существующих таблиц.
Форма – это объект, предназначенный в основном для ввода данных,
отображения их на экране или управления работой приложения.
В Access возможно создать главную кнопочную форму, с помощью которой организуется интерфейс взаимодействия пользователя с базой данных. На
рисунке 1.16 показан пример главной кнопочной формы базы данных «Учебный
процесс».
43
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 1.15 – Взаимодействие объектов в СУБД Access
С помощью элементов управления (командных кнопок) можно просматривать формы, отчеты и другие сведения, изменять элементы кнопочной формы, выходить из базы данных. Главная кнопочная форма с помощью макроса
автоматически загружается для просмотра при запуске базы данных.
44
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 1.16 – Главная кнопочная форма база данных
«Учебный процесс»
Можно использовать формы для того, чтобы реализовать требования
пользователя к представлению данных таблиц или наборов записей запросов.
Формы можно также распечатать. С помощью формы вы можете в ответ на некоторое событие (например, изменение значения поля) запустить макрос или
модуль.
Отчет - это объект, предназначенный для форматирования, вычисления
итогов и печати выбранных данных. Прежде чем выводить отчет на принтер, вы
можете предварительно просмотреть его на экране. Отчеты важны для тех пользователей, которые обязаны представлять информацию в стандартных бланках
(накладная, счет-фактура и т.п.)
Макрос – это объект, представляющий собой структурированное описание одного или нескольких действий, которые должен выполнить Access в ответ
на определенное событие. Например, можно определить макрос, который при
выборе некоторого элемента в основной форме открывает другую форму.
45
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
С помощью макроса вы можете осуществлять проверку значения некоторого поля при изменении его содержимого.
В макрос можно включить дополнительные условия для выполнения или
пропуска тех или иных указанных в нем действий.
Макросы можно использовать для открытия таблиц, выполнения запросов, просмотра или печати отчетов. Из одного макроса можно также
запустить другой макрос или процедуру Visual Basic для аппликаций (VBA).
В общем-то, макросы должны быть знакомы вам, т.к. они используются и
в других приложениях офиса Windows (в электронных таблицах, в текстовом
редакторе).
Однозначное понимание макроса представляется как указание на выполнение одной или нескольких последовательных команд управления приложением.
Модуль – это объект, содержащий программный код на языке Visual Basic
для приложений, позволяющие разбить некоторый процесс на несколько небольших процедур и обнаружить ошибки, которые вы не могли бы найти, если
бы использовали макросы. Модули могут быть независимыми объектами, содержащими функции, вызываемые из любого места приложения, или непосредственно «привязанными» к формам или отчетам для реакции на те или иные события. Модули используются и для макро описания некоторых переменных,
используемых в приложении.
В таблицах хранятся данные, которые можно извлекать с помощью запросов. Используя формы, можно выводить данные на экран или изменять их.
Формы и отчеты получают данные как непосредственно из таблиц, так и через
запросы. Для выполнения нужных вычислений и форматирования данных запросы могут использовать встроенные функции или функции, созданные с помощью VB для приложений. События, происходящие в формах или отчетах,
могут запускать макросы или процедуры VBA. Под событием понимается любое изменение состояния объекта Access, например открытие формы, закрытие
формы, ввод новой строки в форму, изменение содержимого текущей записи
46
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
или использование Active – X элемента управления в объекте формы или отчета, который может содержать данные. Для обработки события создается макрос
или процедура VBA.
Заключение
Подведем итоги по учебному материалу. Рассмотрена структура базы
данных в сложной системе, которая включает и СУБД и разработчиков и пользователей. Системный подход позволил рассмотреть внутреннюю структуру базы данных, структуру ее системы управления. Важно изучить определение
СУБД, назначение, решаемые задачи и возложенные на СУБД функции.
На примере конкретной СУБД Access рассмотрены в общем виде объекты
(компоненты) системы базы данных, что в дальнейшем позволит более детальное их изучение.
Вопросы для самоконтроля
1. Дайте определение СУБД.
2. Какие задачи решает СУБД?
3. Какие функции выполняет СУБД?
4. Назовите принципиальный состав основных компонент СУБД.
5. Чем является поле, запись, кортеж, атрибут в таблице?
6. Какой атрибут в таблице является ключевым?
7. Зачем используются индексы в базе данных?
8. Что включают метаданные базы данных?
9. Назначение объекта «таблица»?
10. Назначение объекта «запрос»?
11. Назначение объекта «форма»?
12. Назначение объекта «отчет»?
13. Назначение объекта «макрос»?
14. Назначение объекта «модуль»?
15. Объясните взаимодействие компонентов в Access.
47
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
1.3 Основы построения реляционных баз данных
Основоположником теории реляционных баз данных считается сотрудник
фирмы IВМ доктор Э. Ф. Кодд, опубликовавший 6 июня 1970 года статью «Реляционная модель данных для больших коллективных банков данных» («A Relational Model of Data for Large Shared Databanks »).
Статья Кодда положила начало движению в сфере проектирования баз
данных, которое привело несколько лет спустя к созданию реляционной модели
базы данных (relational database model). Эта модель представляет собой определенный способ структурирования и обработки базы данных.
Преимущество реляционной модели заключается в способе хранения
данных, который минимизирует их дублирование и исключает определенные
типы ошибок обработки, возникающие при других способах хранения данных.
Реляционная БД представляет собой информацию (данные) об объектах,
представленную в виде двумерных массивов — таблиц, объединенных определенными связями. Приступая к изучению реляционных баз данных, рассмотрим применяемые в теории и практике термины и определения, а также основные принципы и правила их построения.
Термины и определения
Таблица базы данных — двумерный массив, содержащий информацию об
одном классе объектов. В теории реляционной алгебры двумерный массив (таблицу) называют отношением.
Таблица состоит из следующих элементов (таблица 1.5): поле, ячейка, запись.
Поле содержит значения одного из признаков, характеризующих объекты
базы данных. Число полей в таблице соответствует числу признаков, характеризующих объекты БД.
48
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Таблица 1.5 - Файл авторов публикаций БД
Номер
Автор
Адрес
1
Иванов
Оренбург
2
Петров
…
...
N
Сидоров
Телефон
Число
публикаций
52-45-67
134
С.Петербург
456-78-90
45
...
...
...
234-56-43
23
Москва
Фиксация данных осуществляется с помощью конкретного средства общения (например, с помощью естественного языка или изображений) на конкретном носителе (например, камне или бумаге). Обычно данные (факты, явления, события, идеи или предметы) и их интерпретация (семантика) фиксируются совместно, так как естественный язык достаточно гибок для представления
того и другого. Примером может служить утверждение "Автор - Иванов". Здесь
"Иванов" – данное, а "Автор" – его семантика.
Более подробно рассмотрим понятие «сущность».
Сущность – это любой различимый объект (объект, который мы можем
отличить от другого), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, самолеты, рейсы, вкус, цвет и т.д. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных объектов (личностей, предметов, событий или идей), выступающих как целое. Экземпляр сущности относится к конкретному объекту в наборе. Например, типом сущности может быть
ГОРОД, а экземпляром – ОРЕНБУРГ.
К. Дейт предложил следующую классификацию сущностей. Он определил
три основные класса сущностей: стержневые, ассоциативные и характе-
ристические, а также подкласс ассоциативных сущностей – обозначения.
Стержневая сущность – это независимая, стержневая сущность (студент, преподаватель, кафедра). Названия сущностей помещаются в прямоугольники.
49
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Ассоциативная сущность (ассоциация) – это связь между двумя или более
сущностями или экземплярами сущности. Ассоциации рассматриваются как
полноправные сущности.
Характеристическая сущность (характеристика) – это связь, уточняющая свойства основной сущности (частный случай ассоциации). Единственная
цель характеристики в рамках рассматриваемой предметной области состоит в
описании или уточнении некоторой другой сущности. Необходимость в них
возникает в связи с тем, что сущности реального мира имеют иногда многозначные свойства. Например, книга – как стержневая сущность может иметь
несколько переизданий (исправленное, дополненное, переработанное). Существование характеристики полностью зависит от характеризуемой
сущности:
если не будет книги, то не будет и ее переизданий.
Графическое изображение сущностей и атрибутов показано на рисунке
1.17.
Обозначающая сущность или обозначение – это связь между двумя сущностями и отличается от характеристики тем, что она не зависит от обозначаемой сущности. Например, если на предприятии один сотрудник работает на
двух должностях, то в случае сокращения одной должности, он не исключается
из штата предприятия, а остается на несокращенной должности в соответствующем отделе.
В данном примере сотрудники имеют независимое существование (если
удаляется отдел, то из этого не следует, что также должны быть удалены сотрудники этого отдела). Поэтому они не могут быть характеристиками отделов
и названы обозначениями. Обозначения используют для хранения повторяющихся значений больших текстовых атрибутов: "кодификаторы" изучаемых
студентами дисциплин, наименований организаций и их отделов, перечней товаров и т.п.
50
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Стержень
Связь
Обозначение
Связь
Характеристика
Атрибут
Ключ
Рисунок 1.17 – Графическое изображение сущностей и атрибутов
Обозначения и характеристики не являются полностью независимыми
сущностями, поскольку они предполагают наличие некоторой другой сущности,
которая будет "обозначаться" или "характеризоваться". Однако они все же
представляют собой частные случаи сущности и могут, конечно, иметь свойства, могут участвовать в ассоциациях, обозначениях и иметь свои собственные
(более низкого уровня) характеристики. Подчеркнем также, что все экземпляры
характеристики должны быть обязательно связаны с каким-либо экземпляром
характеризуемой сущности.
Атрибут – поименованная характеристика сущности. Его наименование
должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей (например, ЦВЕТ может быть определен для многих сущностей: ДОМ, ДЫМ, КРАСКА и т.д.). Атрибуты используются для определения того, какая информация должна быть собрана о сущности. Примерами атрибутов для сущности ДОМ являются: Номер, Тип, Адрес,
Цвет и т.д. Здесь также существует различие между типом и экземпляром. Тип
атрибута ЦВЕТ имеет много экземпляров (значений): Красный, Синий, Серый и
51
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
т.д., однако каждому экземпляру сущности присваивается только одно значение
атрибута.
Абсолютное различие между типами сущностей и атрибутами отсутствует. Атрибут является таковым только в связи с типом сущности. В другом контексте атрибут может выступать как самостоятельная сущность. Например, для
автомобильного завода цвет – это только атрибут продукта производства, а для
лакокрасочной фабрики цвет – тип сущности.
Ячейка в таблице содержит конкретное значение соответствующего поля
(признака одного объекта). Важное требование по заполнению ячеек – вводимое
значение должно быть атомарным, т.е. неделимым, не массивом, а также однотипным во всем поле (столбце).
Запись - это строка таблицы. Она содержит значения всех признаков, характеризующих один объект. Число записей (строк) соответствует числу объектов
(экземпляров сущностей), данные о которых содержатся в таблице.
В теории баз данных термину запись соответствует понятие кортеж — последовательность атрибутов, связанных между собой отношением AND (И).
Одним из важных понятий, необходимых для построения оптимальной
структуры реляционных баз данных, является понятие ключа, или ключевого поля.
Ключом считается поле, значения которого однозначно определяют значения
всех остальных полей в таблице. Например, поле «Номер студента (номер зачетной книжки)», или «Номер паспорта», однозначно определяет характеристики любого физического лица. Для отношения предусматривают уникальный идентификатор, то есть один или несколько атрибутов, значения которых в одно и то же
время не бывают одинаковыми. Идентификатор называют первичным ключом.
Таблица рассматривается как непосредственное «хранилище» данных.
Традиционно в реляционных системах таблицу называют отношением. Строку
таблицы называют кортежем, а столбец - атрибутом. При этом атрибуты
имеют уникальные (в пределах отношения) имена. Количество кортежей в таблице называют кардинальным числом, а количество атрибутов - степенью.
52
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Домен - это множество допустимых однородных значений для того или
иного атрибута. Таким образом, домен можно рассматривать как именованное
множество данных, причем составные части этого множества являются логически неделимыми единицами (в качестве домена могут выступать, например,
перечень фамилий сотрудников учреждения, однако не все фамилии
могут
присутствовать в таблице).
Одним из важных понятий в теории и практике построения реляционных баз
данных является «тип связи» между таблицами.
Сущности изображаются прямоугольниками, ассоциации – ромбами или
шестиугольниками, атрибуты – овалами, а связи между ними – ненаправленными ребрами, над которыми может проставляться степень связи (цифра или
буква,
заменяющая слово «один» или «много») и необходимое пояснение.
Между двумя сущностям, например А и В, возможны четыре основных вида
связей.
Первый тип – связь ОДИН-К-ОДНОМУ (1:1): в каждый момент времени
каждому представителю (экземпляру) сущности А соответствует 1 или 0 представителей сущности В (рисунок 1.18):
1
А
Студент
1
АВ
1
Назначение
В
1
Стипендия
Рисунок 1.18
Студент может не "заработать" стипендию, получить обычную или одну
из повышенных стипендий.
53
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Второй тип – связь ОДИН-КО-МНОГИМ (1:М): одному представителю
сущности А соответствуют 0, 1 или несколько представителей сущности В (рисунок 1.19).
1
А
Квартира
1
АВ
М
Вселение
В
М
Жилец
Рисунок 1.19
Квартира может пустовать, в ней может жить один или несколько жильцов. Так как между двумя сущностями возможны связи в обоих направлениях,
то существует еще два типа связи МНОГИЕ-К-ОДНОМУ (М:1) и МНОГИЕ-КОМНОГИМ (М:N). Например, если связь между сущностями МУЖЧИНА и
ЖЕНЩИНА называется БРАК, то существует четыре возможных представления такой связи:
1
Мужчина
1
Брак
Женщина
Традиционный брак
1
Мужчина
М
Брак
Женщина
Многоженство
М
Мужчина
1
Брак
Женщина
Многомужество
M
Мужчина
N
Брак
Женщина
Групповой брак
Характер связей между сущностями не ограничивается перечисленными
вариантами.
54
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Существуют и более сложные связи:
множество связей между одними и теми же сущностями:
М
1
Врач
Лечащий врач
М
Пациент
N
Консультант
(пациент, имея одного лечащего врача, может иметь также несколько врачей-консультантов; врач может быть лечащим врачом нескольких пациентов и
может одновременно консультировать несколько других пациентов);
тренарные связи:
М
Врач
N
Назначенный
анализ
Анализ
P
Пациент
(врач может назначить несколько пациентов на несколько анализов, анализ может быть назначен несколькими врачами нескольким пациентам и пациент может быть назначен на несколько анализов несколькими врачами);
связи более высоких порядков, семантика (смысл) которых иногда
очень сложна.
Итак, мы рассмотрели основные термины и определения, касающиеся реляционной базы данных как совокупности отношений, содержащих всю информацию, которая должна храниться в БД как совокупности таблиц и связей
между ними. Выделим и уясним основные правила первоначального этапа построения таблиц.
1. Каждая таблица должна состоять из однотипных строк и иметь уникальное имя.
2. Строки должны иметь фиксированное число полей (столбцов) и значений, при этом, множественные поля и повторяющиеся группы недопустимы.
55
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Иначе говоря, в каждой позиции таблицы на пересечении строки и столбца всегда имеется одно значение или ничего.
3. Строки таблицы должны обязательно отличаться друг от друга хотя бы
единственным значением, что позволяет однозначно идентифицировать любую
строку такой таблицы.
4. Столбцам таблицы должно однозначно присваиваться имя. В столбцах
должны размещаться однородные значения данных (даты, фамилии, оценки, целые числа или денежные суммы).
5. Полное информационное содержание базы данных представляется в
виде явных значений данных и такой метод представления является единственным.
При выполнении основных из этих функций СУБД должна использовать
различные описания данных. А как создавать эти описания?
Естественно, что проект базы данных надо начинать с анализа предметной
области и выявления требований к ней отдельных пользователей (сотрудников
организации, для которых создается база данных). Отметим, что проектирование обычно поручается человеку (группе лиц) – администратору базы данных
(АБД). Им может быть как специально выделенный сотрудник организации, так
и будущий пользователь базы данных, достаточно хорошо знакомый с компьютерной обработкой данных.
Объединяя частные представления о содержимом базы данных, полученные в результате опроса пользователей и свои представления о данных, которые могут потребоваться в будущих приложениях, АБД сначала создает обобщенное неформальное описание создаваемой базы данных. Это описание, выполненное с использованием естественного языка, математических формул,
таблиц, графиков и других средств, понятных всем людям, работающим над
проектированием базы данных,
называют инфологической моделью данных.
Такая модель логического уровня полностью независима от физических
параметров среды хранения данных, от выбранной СУБД. Поэтому инфологи56
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ческая модель не должна изменяться до тех пор, пока какие-то изменения в реальном мире не потребуют изменения в ней некоторого определения, чтобы эта
модель продолжала адекватно отражать предметную область.
Остальные модели, показанные на рисунке 1.20, являются компьютероориентированными. С их помощью СУБД дает возможность пользователям
осуществлять доступ к хранимым данным лишь по их именам, не заботясь о физическом расположении этих данных. Нужные данные отыскиваются СУБД в
запоминающих устройствах по физической модели данных.
Так как указанный доступ осуществляется с помощью конкретной СУБД,
то модели должны быть описаны на языке описания данных этой СУБД. Такое
описание, создаваемое АБД по инфологической модели данных, называют даталогической моделью данных.
Трехуровневая структура (инфологический, даталогический и физический
уровни) позволяет обеспечить независимость хранимых данных от используемых программ. АБД может при необходимости переписать хранимые данные на
другие носители информации и (или) реорганизовать их физическую структуру,
изменив лишь физическую модель данных. АБД может подключить к системе
любое число новых пользователей (новых приложений), дополнив, если надо,
даталогическую модель. Указанные изменения физической и даталогической
моделей не будут замечены существующими пользователями системы (окажутся "прозрачными" для них), так же как не будут замечены и новые пользователи.
Предметная область
Инфологическая модель
предметной области
СУБД
Даталогическая модель
Физическая модель
База данных (БД)
Рисунок 1.20 – Трехуровневая структура моделей базы данных
57
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Этапы проектирования и создания баз данных
При проектировании баз данных можно выделить следующие основные
этапы:
-
анализ предметной области, выделение информационных объектов,
определение на основе нормализации отношений состава таблиц и их структуры;
- определение типов данных и их взаимосвязей, формирование схемы БД.
Перед созданием базы данных пользователь должен определить: из
каких таблиц должна состоять база данных, какие данные нужно поместить в
каждую таблицу, как связать таблицы. Такие вопросы решаются на этапе проектирования базы данных.
В результате проектирования должна быть определена логическая структура базы данных, т. е. состав реляционных таблиц, их структура и межтабличные связи.
На основе такого описания на этапе проектирования базы данных осуществляется определение состава и структуры данных предметной области, которые должны находиться в базе данных и обеспечивать выполнение необходимых запросов и задач пользователя. Структура данных предметной области отображается информационно-логической моделью. На основе этой модели легко
создается реляционная база данных.
В процессе разработки модели данных необходимо выделить информационные объекты, соответствующие требованиям нормализации данных и
определить связи между ними. Эта модель позволяет создать реляционную базу
данных без дублирования, в которой обеспечивается однократный ввод данных
при первоначальной загрузке и корректировках. В такой базе данных СУБД
обеспечивает целостность данных при внесении изменений.
При определении логической структуры реляционной базы данных на
основе модели каждый информационный объект адекватно отображается реля-
58
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ционной таблицей, а связи между таблицами соответствуют связям между информационными объектами.
В процессе создания базы данных сначала осуществляется конструирование таблиц, соответствующих информационным объектам построенной модели
данных. Далее может создаваться схема данных, в которой фиксируются существующие логические связи между таблицами. Эти связи соответствуют связям
информационных объектов. В схеме данных могут быть заданы параметры
обеспечения целостности базы данных, если модель данных была разработана в
соответствии с требованиями нормализации. Целостность данных означает, что
в базе данных установлены и корректно поддерживаются взаимосвязи между
записями разных таблиц при загрузке, добавлении и удалении записей в связанных таблицах, а также при изменении значений ключевых полей.
После формирования схемы данных осуществляется ввод данных,
содержащихся в документах предметной области.
О первичных и внешних ключах
Напомним, что ключ или возможный ключ – это минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр
сущности. Минимальность означает, что исключение из набора любого атрибута не позволит идентифицировать сущность по оставшимся атрибутам.
Каждая сущность обладает хотя бы одним возможным ключом. Один из
них принимается за первичный ключ.
При выборе первичного ключа следует отдавать предпочтение несоставным ключам или ключам, составленным из минимального числа атрибутов. Нецелесообразно также использовать ключи с длинными текстовыми значениями
(предпочтительнее использовать целочисленные атрибуты). Так, для идентификации студента можно использовать либо уникальный номер зачетной книжки,
либо набор из фамилии, имени, отчества, номера группы и может быть дополнительных атрибутов, так как не исключено появление в группе двух студентов
с одинаковыми фамилиями, именами и отчествами.
59
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Не допускается, чтобы первичный ключ стержневой сущности (любой атрибут, участвующий в первичном ключе) принимал неопределенное значение.
Иначе возникнет противоречивая ситуация: появится не обладающий индивидуальностью, и, следовательно не существующий экземпляр стержневой сущности. По тем же причинам необходимо обеспечить уникальность первичного
ключа.
Свойства внешних ключей:
- если сущность С связывает сущности А и В, то она должна включать
внешние ключи, соответствующие первичным ключам сущностей А и В;
- если сущность В обозначает сущность А, то она должна включать внешний ключ, соответствующий первичному ключу сущности А.
При рассмотрении проблемы выбора способа представления ассоциаций и
обозначений в базе данных основной вопрос, на который следует получить ответ: "Каковы внешние ключи?".
Далее для каждого внешнего ключа необходимо решить три вопроса.
1. Может ли данный внешний ключ принимать неопределенные значения
(NULL-значения)? Иначе говоря, может ли существовать некоторый экземпляр
сущности данного типа, для которого неизвестна целевая сущность, указываемая внешним ключом?
В случае поставок каких-либо товаров - это может быть поставка, осуществляемая неизвестным поставщиком, или поставка неизвестного продукта.
Такая ситуация не имеет смысла.
Но в случае с сотрудниками такая ситуация однако могла бы иметь смысл
– вполне возможно, что какой-либо сотрудник в данный момент не зачислен вообще ни в какой отдел.
2. Что должно случиться при попытке УДАЛЕНИЯ целевой сущности, на
которую ссылается внешний ключ? Например, при удалении поставщика, который осуществил по крайней мере одну поставку.
60
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Существует три возможности:
КАСКАДИРУЕТСЯ
ОГРАНИЧИВАЕТСЯ
УСТАНАВЛИВАЕТСЯ
Операция удаления "каскадируется" с
тем, чтобы удалить также поставки этого поставщика.
Удаляются лишь те поставщики, которые еще не осуществляли поставок.
Иначе операция удаления отвергается.
Для всех поставок удаляемого поставщика NULL-значение внешнего ключа
устанавливается в неопределенное значение, а затем этот поставщик удаляется. Такая возможность, конечно, неприменима, если данный внешний ключ не
должен содержать NULL-значений.
3. Что должно происходить при попытке ОБНОВЛЕНИЯ первичного
ключа целевой сущности, на которую ссылается некоторый внешний ключ?
Например, может быть предпринята попытка обновить номер такого поставщика, для которого имеется по крайней мере одна соответствующая поставка. Этот
случай для определенности снова рассмотрим подробнее.
Имеются те же три возможности, как и при удалении:
КАСКАДИРУЕТСЯ
Операция обновления "каскадируется" с
тем, чтобы обновить также и внешний
ключ в поставках этого поставщика.
ОГРАНИЧИВАЕТСЯ
Обновляются первичные ключи лишь тех
поставщиков, которые еще не осуществляли поставок. Иначе операция обновления отвергается.
Для всех поставок такого поставщика
NULL-значение внешнего ключа устанавливается в неопределенное значение, а затем обновляется первичный ключ поставщика. Такая возможность, конечно,
неприменима, если данный внешний
ключ не должен содержать NULLзначений.
УСТАНАВЛИВАЕТСЯ
61
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Таким образом, для каждого внешнего ключа в проекте проектировщик
базы данных должен специфицировать не только поле или комбинацию полей,
составляющих этот внешний ключ и целевую таблицу, которая идентифицируется этим ключом, но и также ответы на указанные выше вопроса (три ограничения, которые относятся к этому внешнему ключу).
Ограничения целостности
Целостность (от англ. integrity – нетронутость, неприкосновенность, сохранность) – понимается как правильность данных в любой момент времени.
Эта цель может быть достигнута лишь в определенных пределах: СУБД
не может контролировать правильность каждого отдельного значения, вводимого в базу данных (хотя каждое значение можно проверить на правдоподобность). Например, нельзя обнаружить, что вводимое значение 5 (представляющее номер дня недели) в действительности должно быть равно 3. С другой стороны, значение 9 явно будет ошибочным и СУБД должна его отвергнуть. Однако для этого ей следует сообщить, что номера дней недели должны принадлежать набору (1,2,3,4,5,6,7).
Поддержание целостности базы данных может рассматриваться как защита данных от неверных изменений или разрушений (не путать с незаконными
изменениями и разрушениями, являющимися проблемой безопасности). Современные СУБД имеют ряд средств для обеспечения поддержания целостности
(так же, как и средств обеспечения поддержания безопасности).
Выделяют три группы правил целостности:
- целостность по сущностям;
- целостность по ссылкам;
- целостность, определяемая пользователем.
62
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Общие правила целостности, общих для любых реляционных баз данных.
1. Не допускается, чтобы какой-либо атрибут, участвующий в первичном
ключе, принимал неопределенное значение.
2. Значение внешнего ключа должно быть: либо равным значению первичного ключа цели; либо быть полностью неопределенным, т.е. каждое значение атрибута, участвующего во внешнем ключе должно быть неопределенным.
3. Для любой конкретной базы данных существует ряд дополнительных
специфических правил, которые относятся к ней одной и определяются разработчиком. Чаще всего контролируется: уникальность тех или иных атрибутов,
диапазон значений, принадлежность набору значений.
Процедура проектирования
Процесс проектирования информационных систем является достаточно
сложной задачей. Он начинается с построения инфологической модели данных,
т.е. идентификации сущностей. Затем необходимо выполнить следующие шаги
процедуры проектирования даталогической модели.
1. Представить каждый стержень (независимую сущность) таблицей базы
данных (базовой таблицей) и специфицировать первичный ключ этой базовой
таблицы.
2. Представить каждую ассоциацию (связь вида "один – ко - многим" или
"один - к- одному" между сущностями) как базовую таблицу. Использовать в
этой таблице внешние ключи для идентификации участников ассоциации и специфицировать ограничения, связанные с каждым из этих внешних ключей.
3. Представить каждую характеристику как базовую таблицу с внешним
ключом, идентифицирующим сущность, описываемую этой характеристикой.
Специфицировать ограничения на внешний ключ этой таблицы и ее первичный
ключ для обеспечения гарантированной уникальности в рамках описываемой
сущности.
63
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
4. Представить каждое обозначение, которое не рассматривалось в предыдущем пункте, как базовую таблицу с внешним ключом, идентифицирующим
обозначаемую сущность. Специфицировать связанные с каждым таким внешним ключом ограничения.
5. Представить каждое свойство как поле в базовой таблице, представляющей сущность, которая непосредственно описывается этим свойством.
6. Для того чтобы исключить в проекте непреднамеренные нарушения
каких-либо принципов нормализации, выполнить процедуру нормализации.
7. Если в процессе нормализации было произведено разделение какихлибо таблиц, то следует модифицировать инфологическую модель базы данных
и повторить перечисленные шаги.
8. Указать ограничения целостности проектируемой базы данных и дать
(если это необходимо) краткое описание полученных таблиц и их полей.
Рассмотрим процесс построения моделей базы данных базы данных на
примере фирмы, которая ведет деловые контакты с несколькими десятками заказчиков и выполняет различного рода услуги, в том числе выполняет заказы на
ремонт вычислительной техники.
Проблема
проектирования
реляционной
базы
данных
состоит
в
обоснованном принятии решений о том, из каких отношений (таблиц) должна
состоять БД и какие атрибуты (характеристики и свойства) должны быть у этих
отношений. Классическим является подход, при котором весь процесс
проектирования производится в терминах реляционной модели данных методом
последовательных
приближений
к
удовлетворительному
набору
схем
отношений.
Исходной точкой является представление предметной области в виде
одного или нескольких отношений и на каждом шаге проектирования
производится некоторый набор схем отношений, обладающих лучшими
свойствами.
64
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Анализируя информационные потоки в организации набор сущностей и
их атрибутов в проектируемых базах данных представлен в табличной форме,
где каждой таблице соответствует определенная стержневая, ассоциативная или
характеристическая сущность.
В результате анализа данных предметной области определили, что база
данных «Заказы на ремонт» содержит следующие сущности:
Заказы на ремонтные работы
Код заказа
Код клиента
Код сотрудника
Номер заказа
Дата получения заказа
Дата назначения заказа
Серийный номер
Описание неисправности
Дата завершения ремонта
Выдано
Налоговая ставка
Клиент - заказчик
Код клиента
Название компании
Имя заказчика
Фамилия заказчика
Адрес счета
Город
Почтовый индекс
Страна
Должность
Телефон
Факс
Сотрудник фирмы
Код сотрудника
Имя
Фамилия
Должность
Телефон домашний
Телефон рабочий
Тарифная ставка
65
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Оплата за ремонт
Код оплаты
Код заказа
Код метода оплаты
Сумма
Дата оплаты
Номер карточки
Имя владельца карточки
Срок действия карточки
Необходимое оборудование
для ремонта
Код необходимого оборудования
Код заказа
Код имеющегося оборудования
Количество
Цена
Имеющееся оборудование в
фирме
Код имеющегося оборудования
Название оборудования
Цена
Описание оборудования
Метод оплаты
Код метода оплаты
Метод оплаты
Карточка
Необходимые ресурсы
Код ресурсов
Код заказа
Код сотрудника
Временные ресурсы
Ставка
Примечание
Основным требованием к инфологической модели, вытекающим из ее назначения, является требование адекватного отображения предметной области. Ин66
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
фологическая модель должна быть непротиворечивой. Она является единым интегрированным описанием предметной области и отражает взгляды и потребности всех пользователей системы
Инфологическая модель
(ИЛМ) представляет информационные потоки,
сущности и связи данной предметной области. Она может быть представлена в
виде ER- диаграммы и реляционной схемы (рисунок 1.21).
Целью построения этой структуры является выявление и объединение информационных требований пользователя, связей между элементами данных без относительно к их содержанию и среде их хранения. ИЛМ должна обладать свойством легкой расширяемости, обеспечивающим ввод новых данных без изменений
ранее определенных. Центральной компонентой инфологической модели является
описание объектов предметной области и связей между ними (ER- диаграмма).
Для повышения иллюстративности рассматриваемых связей не показаны
все атрибуты сущностей и ассоциаций. В связи с этим язык ER-диаграмм используется для построения небольших моделей и иллюстрации отдельных
фрагментов больших. Чаще же применяется менее наглядный, но более содержательный язык инфологического моделирования (ЯИМ), в котором сущности
и ассоциации представляются предложениями вида:
СУЩНОСТЬ (атрибут 1, атрибут 2 , ..., атрибут n)
АССОЦИАЦИЯ [СУЩНОСТЬ S1, СУЩНОСТЬ S2, ...]
(атрибут 1, атрибут 2, ..., атрибут n),
где S – степень связи, а атрибуты, входящие в ключ, должны быть отмечены с помощью подчеркивания.
Так, вариант ИЛМ базы данных «Заказы на ремонт», может быть описан
на ЯИМ следующим образом:
Клиент-заказчик (Код клиента, Название компании, Имя клиента, Фамилия клиента, Адрес выставления счета, Город, Регион, Индекс, Страна, Должность, Телефон, Факс )
Сотрудник-исполнитель ремонта (Код сотрудника, Фамилия, Имя, Должность, Внутренний телефон, Домашний телефон, Тарифный разряд)
Заказ на ремонт [ Клиент-заказчикM, Сотрудник-исполнитель
ремонта
М]
67
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
(Код заказа, Код клиента, Код сотрудника, Номер заказа, Дата получения,
Дата назначения, Изготовитель модели, Серийный номер, Описание неисправности, Дата завершения, Выдано, Налоговая ставка)
Оборудование, имеющееся в фирме (Код оборудования, Название, Цена,
Описание )
Оборудование, необходимое для ремонта [Заказ на ремонт М, Оборудование М] (Код необходимого оборудования, Код заказа, Код оборудования, Количество, Цена)
Оплата[Заказ на ремонт М, Метод оплаты]
(Код Оплаты, Код заказа, Код метода оплаты, Сумма, Дата, Номер карточки, Имя владельца карточки, Срок действия карточки)
Метод оплаты (Код метода оплаты, Метод оплаты, Карточка)
Необходимые ресурсы [Заказ на работы М, Сотрудник-исполнитель ремонта]
(Код необходимых ресурсов, Код заказа, Код сотрудника, Оплачиваемые
часы, тарифный разряд-ставка, примечание)
Даталогическая модель является моделью логического уровня и представляет
собой отображение логических связей между элементами данных безотносительно к их содержанию и среде хранения. Эта модель строится в терминах информационных единиц, допустимых в той конкретной СУБД, в среде которой мы проектируем базу данных.
Этап создания даталогической модели называется даталогическим проектированием, где производится описание логической структуры базы данных на
языке СУБД в виде схемы связей между таблицами.
Построенная средствами СУБД Access даталогическая модель показана на рисунке 1.22.
68
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
код кл
код зак
фирма
код кл
заказ на ремонт
1 М
необходимое
оборудование
М
адрес
М
код сотр
фамилия
цена
М
1
1
код оборуд
сведения об
оборуд
сотрудник
М
оплата
должн
код оборуд
код зак
1 М
клиент
код сотр
наименован
цена
М
код опл
1
код зак
код опл
метод
оплаты
карточка
дата
сумма
Рисунок 1.21 - ER-диаграмма базы данных «Заказы на ремонт»
69
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 1.22 - Даталогическая модель базы данных «Заказы на ремонт»
Все данные и другая информация в СУБД хранятся на магнитных дисках в
дисковых файлах. Файл данных представляет собой таблицу, каждая строка которой (запись) содержит некоторые сведения об описываемом объекте. Все записи базы данных имеют идентичную, заданную пользователем структуру и размеры.
Для привязки даталогической модели к среде хранения используется модель данных физического уровня (для краткости часто называемая физической
моделью). Эта модель определяет используемые запоминающие устройства, способы физической организации данных в среде хранения. Описание физической
структуры базы данных называется схемой хранения. Соответствующий этап
проектирования базы данных называется физическим проектированием.
Данные в таблицах СУБД (для примера возьмем Access) сохраняются в
определенном формате, который называется типом данных. Типы данных могут
70
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
быть классифицированы по четырем категориям: числовые (numeric), символьные (character), даты (date) и BLOB. Числовые данные включают в себя все числа, начиная с целых вплоть до чисел двойной точности с плавающей точкой.
Символьные данные содержат строки текста. Даты используются для хранения
дат и времени. Типы данных (Data Type) в Access приведены в таблице 1.6.
Таблица 1.6
Тип данных
Использование
Размер
Текстовый
Текст или комбинация текста и
чисел, например, адреса, а также
числа, не требующие вычислений, например, номера телефонов, инвентарные номера или
почтовые индексы.
До 255 символов.
Поле MЕМО
Длинный текст или числа,
например, примечания или описания.
Числовой
Числовые данные, используе- 1, 2, 4 или 8 байтов.
мые для математических вычис- 16 байтов только для кодов
репликации (GUID).
лений.
Дата/время
Даты и время.
Денежный
Значения валют. Предполагает 8 байтов.
до 15 символов в целой части
числа и 4 - в дробной.
Логический
Поля, содержащие только одно 1 бит.
из двух возможных значений,
таких как «Да/Нет», «Истина/Ложь», «Вкл/Выкл».
Поле объекта
OLE
Объекты OLE (например, доку- До 1 гигабайта (ограничено объементы Microsoft Word, элек- мом диска).
тронные таблицы Microsoft
Excel, рисунки, звуки и другие
двоичные данные).
Гиперссылка
Поле, в котором хранятся ги- До 64 000 символов.
перссылки и пути к ним в виде
пути UNC или URL-адреса.
Для определения максимального количества символов,
которые можно ввести, используйте свойство Размер
поля (FieldSize).
До 64 000 символов.
8 байтов.
71
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
В перечне типов данных возможен выбор мастера подстановок, который
создает поле, позволяющее выбрать значение из другой таблицы или из списка
значений, используя поле со списком. При выборе данного параметра в списке
типов данных запускается мастер для автоматического определения этого поля,
при этом определяется тот же размер, который имеет первичный ключ, являющийся также и полем подстановок, обычно — 4 байта.
Формально описать объекты и их свойства позволяет таблица свойств
объектов. В ней каждый объект базы данных представляется в виде таблицы с
набором полей определенного типа и свойств, а также указаны возможные процессы для каждого свойства. Формализованное описание объектов предметной
области производится при работе с объектом Access «Таблица» в режиме «Конструктор» (рисунок 1.23).
Рисунок 1.23 - Физическое проектирование данных
72
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Вопросы для самоконтроля
1.
Что называется сущностью?
2.
Назовите типы сущностей.
3.
Что называется ключом?
4.
Что называется атрибутом?
5.
Назовите типы связей между сущностями и их примеры.
6.
Чем отличается первичный ключ от внешнего ключа?
7.
Что называется доменом?
8.
Назовите правила первоначального этапа построения таблиц.
9.
Дайте определение трем уровням моделей БД.
10. Дайте характеристику этапам построения реляционных БД.
11. Дайте определение целостности БД?
12. Назовите общие правила целостности.
13. Покажите графическое изображение сущностей.
14. Объясните алгоритм процедуры проектирования БД.
1.4 Нормализация базы данных
Основное предназначение процесса нормализации заключается в том,
чтобы проект базы данных был хорошим, а он будет хорошим, если база данных
будет целостная, т.е. не будет иметь аномалий в ходе добавления, обновления и
удаления данных в базе. Кроме того, база данных не должна быть избыточной,
т.е. не должна иметь повторяющихся данных, особенно когда количество этих
данных составляет несколько тысяч записей. Как достичь этих требований, чтобы проект базы данных не был плохим, рассмотрим в материалах этого раздела.
Ключевые слова: нормальная форма, функциональная зависимость, полная функциональная зависимость, многозначная функциональная зависимость,
транзитивная функциональная зависимость, зависимость проекции соединения,
детерминант.
73
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Введение
Теория и практика построения реляционных баз данных имеет более чем
сорокалетнюю историю. За это время накопился достаточный опыт в работе
разработчиков баз данных.
Реляционная модель важна по двум причинам. Во-первых, поскольку конструкции реляционной модели имеют широкий и общий характер, то она позволяет описывать структуры баз данных независимым от СУБД образом. Вовторых, реляционная модель является основой почти всех СУБД. Таким образом, понимание принципов этой модели существенно.
В данной лекции обсудим и рассмотрим фундаментальные принципы
нормализации (normalization). Нормализация в общем виде — это процесс преобразования отношения, имеющего некоторые недостатки, в отношение, которое этих недостатков не имеет. Вопрос о том, является ли структурированное
отношение хорошим, был предметом многочисленных теоретических исследований.
Термин нормализация обязан своим появлением пионерам технологии баз
данных: Э. Кодду, Д. Бойсу, Р. Фагину, П. Чену, Р.Баркеру, которые определили различные нормальные формы (Normal Form) отношений.
В
последнее время
более тщательное исследование данного вопроса
можно найти в работах: Д. Ульмана, Г. Молина, Д. Уидома, Д. Кренке, а также
российских ученых С. Глушакова, Д. Ломотько, Э. Фуфаева, Н. Соловьева и др.
Отношения можно классифицировать по типам аномалий модификации,
которым они подвержены. Теоретики реляционных баз данных постепенно сокращали количество этих типов. Кто-то находил аномалию, классифицировал ее
и думал, как предотвратить ее возникновение. Каждый раз, когда это происходило, критерии построения отношений совершенствовались.
Появились классы отношений и способы предотвращения аномалий.
Классы отношений стали называть нормальными формами. В зависимости от
74
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
своей структуры, отношение может быть в первой, во второй или в какой-либо
другой нормальной форме.
Реляционная база данных представляет собой некоторое множество таблиц, связанных между собой. Число таблиц и их содержание в базе данных зависит от многих факторов, основными из которых являются:
состав пользователей данных;
обеспечение целостности данных (особенно важно в многопользовательских информационных системах);
исключение избыточности данных, обеспечение наименьшего объема требуемой памяти и минимального времени обработки данных.
Накопленный опыт многих ученых и, прежде всего таких как Э. Кодд, Д.
Бойс, Р. Фагин, позволяет учесть данные факторы при проектировании реляционных баз данных методами нормализации таблиц и установлением связей между ними.
Классы нормальных форм
Процесс разработки и создания таблиц в реляционных базах данных
начинается с логического и абстрактного мышления человека в ходе анализа
данных предметной области, а затем на основе этого строится информационная
модель предметной области. В этом процессе применяется основной и классический подход, при котором вся работа проектирования производится в терминах реляционной модели данных методом последовательных приближений к
приемлемому набору схем отношений.
Началом должно служить представление предметной области (т.е. той реальной информации, которая будет храниться в БД) в виде одного или нескольких отношений. Рекомендуется на каждом шаге проектирования производить
некоторый набор схем отношений, обладающих лучшими свойствами с точки
зрения представления информации.
75
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Вообще говоря, процесс проектирования представляет собой в том числе
и нормализацию схем отношений, причем каждая следующая нормальная форма
(НФ) обладает свойствами лучшими, чем предыдущая. Так скажем, в структуре
БД «Учебный процесс», приведенной на рисунке 1.24, интуитивно чувствуется,
что имеется избыточность. Действительно, в отношении «Студенты» присутствует атрибут ФИО, однако и в отношении «Успеваемость» этот атрибут имеет место.
Таким образом, информация о фамилии, имени и отчестве студента дублируется. При этом возникают проблемы, например связанные с тем, что при
изменении фамилии студента возникает необходимость ее изменения в обоих
отношениях. Из вышесказанного следует простейший вывод - хорошая структура БД содержит по одному элементу информации и только в одном месте, что и
позволяет избежать избыточность.
Рисунок 1.24 – Схема связей базы данных «Учебный процесс»
76
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
В
теории
реляционных
БД
обычно
выделяется
следующая
по-
следовательность нормальных форм:
• 1НФ - первая нормальная форма (First Normal Form – 1NF);
• 2НФ - вторая нормальная форма (Second Normal Form – 2NF);
• 3НФ - третья нормальная форма (Third Normal Form – 3NF);
• НФБК - нормальная форма Бойса-Кодда (Brice – Codd Normal Form BCNF):
• 4НФ - четвертая нормальная форма (Fourth Normal Form – 4NF);
• 5НФ или НФПС - пятая нормальная форма или нормальная форма проекции-соединения (Fifth Normal Form – 5NF или PJ/NF);
•
ДКНФ – доменно-ключевая нормальная форма (Domain/Key Normal
Form, DK/NF).
Функциональные зависимости
Чтобы понять, что такое нормализация, мы предварительно должны уяснить некоторые термины и определения, и прежде всего: функциональная зависимость и ключ.
Функциональная зависимость (functional depedencu) — это связь между
атрибутами. Предположим, что если мы знаем значение одного атрибута, то
можем вычислить (или найти) значение другого атрибута. Например, если нам
известен номер студента, то мы можем определить его успеваемость (оценки по
предметам обучения). В таком случае мы можем сказать, что атрибут ОЦЕНКА
функционально зависит от атрибута НОМЕР СТУДЕНТА.
В общем виде это формализуется так: атрибут Х функционально зависит
от атрибута У, если значение У определяет значение Х. Другими словами, если
нам известно значение У, мы можем определить значение Х.
77
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Арифметические уравнения тоже выражают функциональные зависимости. Например, если мы знаем цену и количество приобретенного товара, мы
можем определить стоимость покупки по следующей формуле:
Стоимость = Цена * Количество
В этом случае мы могли бы сказать, что атрибут СТОИМОСТЬ функционально зависит от атрибутов ЦЕНА и КОЛИЧЕСТВО. В электронных таблицах
это легко и однозначно решается.
В отличие от случая с арифметическим уравнением, функциональные зависимости в реляционных таблицах базы данных нельзя разрешить при помощи
арифметики; вместо этого они хранятся в базе данных. Фактически, можно
утверждать, что базу данных стоит иметь только ради хранения и выдачи функциональных зависимостей.
Функциональные зависимости обозначаются следующим образом:
НОМЕР СТУДЕНТА > СПЕЦИАЛЬНОСТЬ
НОМЕР ГРУППЫ > КОЛИЧЕСТВО СТУДЕНТОВ
Первое выражение читается так: «атрибут НОМЕР СТУДЕНТА функционально определяет атрибут СПЕЦИАЛЬНОСТЬ», «атрибут НОМЕР СТУДЕНТА определяет атрибут СПЕЦИАЛЬНОСТЬ» или «атрибут СПЕЦИАЛЬНОСТЬ
зависит от атрибута НОМЕР СТУДЕНТА». Атрибуты по правую сторону от
стрелки называются детерминантами (determinants).
Как уже говорилось, если номер студента определяет специальность, то
каждому номеру студента соответствует только одна специальность. Между
тем, одной и той же специальности может соответствовать более одного номера
студента. Пусть студент под номером 12 специализируется на бухгалтерском
учете. Тогда для любого отношения, где присутствуют столбцы НОМЕР СТУДЕНТА и СПЕЦИАЛЬНОСТЬ, выполнится условие: если НОМЕР СТУДЕНТА=12, то СПЕЦИАЛЬНОСТЬ = Бух.учет. Обратное утверждение будет неверным: если СПЕЦИАЛЬНОСТЬ = Бух.учет, то атрибут НОМЕР СТУДЕНТА может принимать различные значения, так как на Бух.учете может специализиро-
78
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ваться много студентов. Следовательно, мы можем сказать, что связь атрибутов
НОМЕР СТУДЕНТА и СПЕЦИАЛЬНОСТЬ имеет вид М:1.
В общем случае можно утверждать, что если А определяет В, связь между значениями А и В имеет вид М:1.
В функциональные зависимости могут быть вовлечены группы атрибутов.
Рассмотрим отношение УСПЕВАЕМОСТЬ (НОМЕР СТУДЕНТА,
ДИСЦИ-
ПЛИНА, ОЦЕНКА). Комбинация номера студента и дисциплины определяет
оценку. Такая функциональная зависимость записывается следующим образом:
(НОМЕР СТУДЕНТА, ДИСЦИПЛИНА) > ОЦЕНКА
Это означает то, что для определения оценки требуется как номер студента, так и дисциплина. Мы не можем разделить эту функциональную зависимость, поскольку ни номер студента, ни дисциплина не определяют оценку сами
по себе.
В общем виде формализация этой функциональной зависимости имеет
вид:
Если Х > (У, Z), то X > У и
X > Z.
Например, если НОМЕР СТУДЕНТА > (ИМЯ СТУДЕНТА, ФАМИЛИЯ
СТУДЕНТА), то НОМЕР СТУДЕНТА > ИМЯ СТУДЕНТА и НОМЕР СТУДЕНТА > ФАМИЛИЯ СТУДЕНТА.
Если (X, У) > Z, то в общем случае неверно, что X >У или X > Z.
Следовательно, если (НОМЕР СТУДЕНТА, ДИСЦИПЛИНА) > ОЦЕНКА, то ни номер студента, ни дисциплина как таковые оценку не определяют.
При описании нормальных форм используются следующие понятия:
«функциональная зависимость между полями»; «полная функциональная зависимость между полями»; «многозначная функциональная зависимость между
полями»; «транзитивная функциональная зависимость между полями»; «взаимная независимость между полями».
Функциональной зависимостью между полями А и В называется зависимость, при которой каждому значению А в любой момент времени соответствует единственное значение В из всех возможных. Примером функциональной за79
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
висимости может служить связь между идентификационным номером налогоплательщика и номером его паспорта.
Полной функциональной зависимостью между составным полем А и полем В называется зависимость, при которой поле В зависит функционально от
поля А и не зависит функционально от любого подмножества поля А.
Многозначная функциональная зависимость между полями определяется
следующим образом. Поле А многозначно определяет поле В, если для каждого
значения поля А существует «хорошо определенное множество» соответствующих значений поля В. Например, если рассматривать таблицу успеваемости
учащихся в школе, включающую в себя поля «ПРЕДМЕТ» (поле А) и «ОЦЕНКА» (поле В), то поле В имеет «хорошо определенное множество» допустимых
значений: 1, 2, 3, 4, 5, т.е. для каждого значения поля «ПРЕДМЕТ» существует
многозначное «хорошо определенное множество» значений поля «ОЦЕНКА».
Транзитивная функциональная зависимость между полями А и С существует в том случае, если поле С функционально зависит от поля В, а поле В
функционально зависит от поля А, при этом не существует функциональной зависимости поля А от поля В.
Взаимная независимость между полями определяется так: поля будут
взаимно независимы, если ни одно из них не является функционально зависимым от другого.
Ключи и функциональные зависимости
Ключ (key) - это группа из одного или более атрибутов, которая уникальным образом идентифицирует строку.
Рассмотрим отношение Студент (рисунок 1.25), имеющее атрибуты НОМЕР СТУДЕНТА, НОМЕР ГРУППЫ и СПЕЦИАЛЬНОСТЬ. Строка этого отношения содержит информацию о том, что студент посещает определенную
группу и обучается по выбранной специальности. Предположим, что студент
одновременно не может посещать более одной группы. В этом случае значение
80
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
атрибута НОМЕР СТУДЕНТА идентифицирует единственную строку, поэтому
данный атрибут является ключом.
Номер Студента
10
20
30
40
Номер группы
41
42
41
44
Специальность
ПОВТАС
АСОИУ
ПОВТАС
СИТ
Рисунок 1.25 - Отношение СТУДЕНТ
Ключи могут также составляться из нескольких атрибутов. Например, если студентам разрешено одновременно посещать более одной группы, то один и
тот же номер студента может появиться в разных строках таблицы, поэтому атрибут НОМЕР СТУДЕНТА не будет уникальным образом определять строку.
Для этого потребуется какое-то сочетание атрибутов; возможно, это будет комбинация (НОМЕР СТУДЕНТА, НОМЕР ГРУППЫ).
Попутно отметим, что в предыдущем абзаце затронут тонкий, но весьма
важный аспект. Являются ли атрибуты ключами и являются ли они функционально зависимыми — это определяется не абстрактным набором правил, а моделями, присутствующими в воображении пользователей, а также деловым регламентом организации, использующей базу данных. Что в приведенном выше
примере является ключом? Им может быть: НОМЕР СТУДЕНТА, или комбинация (НОМЕР СТУДЕНТА, НОМЕР ГРУППЫ), или какое-то еще сочетание
атрибутов. Ответ на вопрос целиком и полностью определяется тем, как представляют себе ситуацию люди, работающие в организации, которая использует
базу данных. Ответы на эти подобные вопросы проектировщик базы данных
должен получить от пользователей. По ходу дальнейшего изложения имейте в
виду, что все наши предположения о функциональных зависимостях, ключах,
ограничениях и тому подобных вещах определяются моделями в воображении
пользователей.
81
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Допустим, что в ходе опроса пользователей мы выяснили, что студентам
разрешено одновременно быть записанными в несколько групп. Эта ситуация
отражена в отношении СТУДЕНТ (рисунок 1.26). Как мы отметили, НОМЕР
СТУДЕНТА не является ключом этого отношения. В самом деле, студент с номером 10 посещает группу 41 и 43 , и атрибут НОМЕР СТУДЕНТА со значением 10 появляется в двух различных строках. Фактически, для этого отношения
ни один атрибут сам по себе не является ключом, то есть ключ должен состоять
из двух или более атрибутов.
Номер Студента
10
20
10
30
40
Номер группы
41
42
43
41
44
Специальность
ПОВТАС
АСОИУ
САПР
ПОВТАС
СИТ
Рисунок 1.26 - Отношение СТУДЕНТ
Рассмотрим, какие комбинации из двух атрибутов возможны для данной
таблицы. Таких комбинаций имеется три: (НОМЕР СТУДЕНТА, НОМЕР
ГРУППЫ), (НОИЕР СТУДЕНТА, СПЕЦИАЛЬНОСТЬ) и (НОМЕР ГРУППЫ,
СПЕЦИАЛЬНОСТЬ). Является ли какая-либо из этих комбинаций ключом?
Чтобы быть ключом, группа атрибутов должна уникальным образом
идентифицировать строку. Опять-таки, ответы на подобные вопросы мы должны получить от пользователей. Наше решение не должно основываться на выборочных данных, подобных тем, которые приведены на рисунке 1.26 или на
наших собственных предположениях.
Допустим, что поговорив с заказчиком базы данных, мы пришли к выводу, что студент может получить две специальности, находясь в списке одной
группы. Поскольку это так, комбинация (НОМЕР СТУДЕНТА, НОМЕР ГРУППЫ) не может уникальным образом определить строку. Например, студент с
номером 10 посещает одну 41 группу (рисунок 1.27), которая обучается по
двум специальностям. Это означает, что комбинация (10, 41) возникла бы в таблице дважды, поэтому такая комбинация не может быть ключом.
82
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Номер Студента Номер группы
Специальность
10
41
ПОВТАС
20
41
ПОВТАС
10
41
САПР
40
44
СИТ
Рисунок 1.27 - Отношение СТУДЕНТ
Может ли быть ключом сочетание (НОМЕР ГРУППЫ, СПЕЦИАЛЬНОСТЬ)? Может ли комбинация (41, ПОВТАС) уникальным образом определить строку? Нет, не может, поскольку группу №41 может посещать много студентов.
Это приводит нас к важному заключению. Каждое отношение имеет минимум один ключ. Это утверждение должно быть верным, поскольку ни одно
отношение не может иметь одинаковых строк, и, следовательно, в крайнем случае ключ будет состоять из всех атрибутов отношения.
Функциональные зависимости, ключи и уникальность
У многих студентов возникает путаница с понятиями функциональной зависимости, ключа и уникальности. Чтобы избежать этой путаницы, уясните себе
следующее: детерминант функциональной зависимости может в отношении
быть уникальным или неуникальным. Если нам известно, что А определяет В и
что А и В находятся в одном и том же отношении, мы все равно не знаем, является ли А уникальным в этом отношении. Мы знаем только то, что А определяет В.
Например, в отношении СТУДЕНТ (рисунок 1.27) атрибут НОМЕР
ГРУППЫ функционально определяет атрибут СПЕЦИАЛЬНОСТЬ, однако номер конкретной группы может, тем не менее, фигурировать в нескольких строках отношения.
Функциональная зависимость говорит только о том, что везде, где атрибуту НОМЕР ГРУППЫ соответствует атрибут СПЕЦИАЛЬНОСТЬ, конкретному
значению атрибута НОМЕР ГРУППЫ всегда соответствует одно и то же значение атрибута СПЕЦИАЛЬНОСТЬ. То есть, студент, посещающий группу № 41
83
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
всегда обучается по специальности ПОВТАС, независимо от того, сколько раз
группа № 41 фигурирует в таблице.
В отличие от детерминантов, ключи всегда являются уникальными. Ключ
функционально определяет целую строку. Если бы значения ключей дублировались, дублировался бы и весь кортеж. Но это недопустимо, поскольку по определению, строки в отношении должны быть уникальными. Таким образом, когда мы говорим, что атрибут (или комбинация атрибутов) является ключом, мы
знаем, что этот атрибут или комбинация будут уникальными. Например, если
сочетание (НОМЕР СТУДЕНТА, НОМЕР ГРУППЫ) является ключом, то сочетание (10, Специальность) может и должно появиться в таблице только один
раз.
Аномалии модификации
В практике реляционных баз данных не все отношения одинаково желательны. Таблица, отвечающая минимальному определению отношения, может
иметь неэффективную или неподходящую структуру. Для некоторых отношений изменение данных может привести к нежелательным последствиям, называемым аномалиями модификации (modification anomalies). Аномалии могут
быть устранены путем разбиения исходного отношения на два или более новых
отношения. В большинстве случаев переопределенные, или нормализованные,
отношения являются более предпочтительными.
Рассмотрим опять отношение СТУДЕНТ (рисунок 1.27). Если мы удалим
строку, где записаны данные о студенте с номером 40, мы потеряем не только
информацию о группе № 44 но и тот факт, что студенты могли бы обучаться по
специальности «Сетевые информационные технологии». Это называется аномалией удаления (delete anomaly) - то есть, удаляя факты, относящиеся к одной
сущности (студент с номером 40 обучается по специальности СИТ), мы непроизвольно удаляем факты, относящиеся к другой сущности (в группе №44 обуче-
84
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ние производится по специальности СИТ). Выполнив одну операцию удаления,
мы теряем информацию о двух сущностях.
На примере того же самого отношения можно продемонстрировать аномалию вставки (insertions anomaly). Предположим, мы хотим записать в базу
данных тот факт, что студент группы №44 обучается по экономической специальности, однако мы не можем ввести эти данные в отношение СТУДЕНТ, пока
хотя бы один студент не запишет в группу № 44 по новой специальности. Это
ограничение выглядит глупо. Почему для того, чтобы указать новую специальность, требуется ждать, когда кто-нибудь запишется в эту группу? Это ограничение называется аномалией вставки. Суть его в том, что мы не можем записать
в таблицу некоторый факт об одной сущности, не указав дополнительно некоторый факт о другой сущности.
Отношение, показанное на рисунке 1.27 может быть использовано в приложениях баз данных, но оно имеет явные проблемы. Мы можем устранить как
аномалию удаления, так и аномалию вставки, разделив отношение СТУДЕНТ
на два отношения, каждое из которых будет содержать информацию на определенную тему. Например, в одно отношение мы поместим атрибуты НОМЕР
СТУДЕНТА и НОМЕР ГРУППЫ (назовем это отношение СТУДЕНТГРУППА), а в другое - атрибуты НОМЕР ГРУППЫ и СПЕЦИАЛЬНОСТЬ
(назовем это отношение ГРУППА - СПЕЦИАЛЬНОСТЬ).
Эти два новых отношения с данными из нашего примера изображены на
рисунке 1.28.
СТУДЕНТ-ГРУППА
10
20
30
40
41
42
41
44
ГРУППА - СПЕЦИАЛЬНОСТЬ
41
42
44
ПОВТАС
АСОИУ
СИТ
Рисунок 1.28 - Разбиение отношения СТУДЕНТ на два отношения
85
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Теперь, если мы удалим запись о студенте с номером 10 из таблицы СТУДЕНТ-ГРУППА, мы уже не потеряем тот факт, что группа № 41 обучается по
специальности ПОВТАС. Более того, мы можем добавить в таблицу ГРУППА СПЕЦИАЛЬНОСТЬ нового студента по новой специальности, не дожидаясь,
пока кто-либо запишется в эту группу. Таким образом, аномалии удаления и
вставки устранены.
Разбиение одного отношения на два имеет, однако, один недостаток.
Предположим, что студент хочет записаться в несуществующую группу.
Например, студент с номером 10 хочет записаться в группу № 45 по ускоренному обучению. Мы можем вставить соответствующую строку в отношение СТУДЕНТ- ГРУППА (строка будет содержать запись 10, 45), но следует ли это делать? Стоит ли разрешать студенту записываться в группу, которая отсутствует
в отношении ГРУППА - СПЕЦИАЛЬНОСТЬ? Другими словами, должна ли система каким-либо образом препятствовать добавлению строк в таблицу СТУДЕНТ-ГРУППА, если название соответствующей секции отсутствует в таблице
ГРУППА - СПЕЦИАЛЬНОСТЬ? Ответ на этот вопрос содержится в требованиях пользователей. Если такое действие должно быть запрещено, данное ограничение (а это не что иное, как условия делового регламента) необходимо внести в
схему базы данных. Позже, на стадии реализации, выполнение этого ограничения будет возложено на СУБД, если используемая СУБД предоставляет такую
возможность. Если нет, то соблюдение ограничения должно обеспечиваться
прикладными программами.
Допустим, пользователи указывают, что группы могут существовать и до
того, как кто-либо в них запишется, однако студент не может записаться в
группу, для которой не указана специальность (то есть в группу, данные о которой отсутствуют в таблице ГРУППА - СПЕЦИАЛЬНОСТЬ.
При проектировании базы данных мы можем формализовать это ограничение любым из следующих способов:
86
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
«множество значений атрибута НОМЕР ГРУППЫ в таблице СТУДЕНТГРУППЫ является подмножеством множества значений атрибута НОМЕР
ГРУППЫ в таблице ГРУППА – СПЕЦИАЛЬНОСТЬ»;
«СТУДЕНТ - ГРУППА [Номер группы] является подмножеством множества ГРУППА - СПЕЦИАЛЬНОСТЬ [Номер группы]».
Квадратные скобки в этой записи обозначают столбец данных, извлекаемый из отношения. Смысл этих выражений в том, что атрибут НОМЕР ГРУППЫ в отношении СТУДЕНТ-ГРУППА может принимать только те значения,
которые имеет атрибут НОМЕР ГРУППЫ в отношении ГРУППА - СПЕЦИАЛЬНОСТЬ. Это означает также, что прежде чем ввести название какой-то секции в отношение СТУДЕНТ-ГРУППА, мы должны проверить, что такое название уже существует в отношении ГРУППА - СПЕЦИАЛЬНОСТЬ.
Ограничения, подобные этому, называются ограничениями ссылочной целостности (referential integrity constraints), или ограничениями целостности по
внешнему ключу (inter – relation constraints)
Суть нормализации
Суть процесса нормализации можно пояснить на примере такого вопроса.
Почему в данной лекции тест разбит на абзацы? Это разбиение производится по
тому правилу, что абзац в книге должен иметь только одну тему. Если абзац содержит более одной темы, то его нужно разбить на два или более абзаца таким
образом, чтобы каждый из получившихся абзацев содержал ровно одну тему.
Аналогичные высказывания справедливы и для отношений. Каждое нормализованное отношение имеет одну-единственную тему. Любое отношение, содержащее две или более темы, следует разбить на два или более отношения, каждое
из которых будет содержать одну тему. Этот процесс составляет суть нормализации. Когда мы обнаруживаем отношение с аномалиями модификации, мы
устраняем эти аномалии, разбивая отношение на два или более новых отношения, каждое из которых содержит факты, относящиеся к одной теме.
87
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Однако не стоит забывать, что всякий раз, когда мы разбиваем отношение,
мы, возможно, порождаем ограничение ссылочной целостности. Поэтому следует обязательно проверять наличие таких ограничений каждый раз при разбиении отношения на два или более новых.
Теперь рассмотрим правила нормализации отношений, относящихся к
каждому классу нормальных форм.
Характеристика нормальных форм
Каждая НФ более высокого порядка является более выгодной с точки зрения концепции реляционных БД, чем предыдущая. При этом необходимо заметить тот факт, что если некоторая БД находится, скажем, во 2НФ, то не исключено, что часть ее уже находится в ЗНФ, внутри которой может находиться
часть в НФБК и т. д.
Основные свойства НФ:
- каждая следующая НФ является в некотором смысле лучше предыдущей;
- при переходе к следующей НФ свойства предыдущих нормальных форм
сохраняются.
В основе процесса проектирования лежит метод нормализации - декомпозиция отношения, находящегося в предыдущей НФ на два или более отношений, удовлетворяющих требованиям следующей НФ.
Каждой НФ соответствует некоторый набор ограничений. Отношение,
находящееся в некоторой НФ, должно удовлетворять свойственному этой форме набору ограничений. Поскольку требование 1НФ является базовым в классической реляционной модели данных, начнем изложение с требований именно
к этой форме.
Отношение будет находиться в 1НФ при условии, что оно содержит только логически неделимые значения. Такие значения в дальнейшем будем называть скалярными (атомарными). При этом необходимо заметить, что приведенное определение говорит о нахождении любого нормализованного отношения в
88
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
1НФ. В то же время отношение, находящееся только в 1НФ, обладает структурой не совсем желательной, например, по причине ее возможной избыточности.
Допустим, что отношение «УСПЕВАЕМОСТЬ» (рисунок 1.29) содержит
всю информацию о студенческой группе и оценках.
Оценка Номер студента
Oz
УСПЕВАЕМОСТЬ
Специальность Номер группы Код предмета
NS
Sp
NG
KP
Рисунок 1.29 - Структура отношения УСПЕВАЕМОСТЬ
Для отношения УСПЕВАЕМОСЬ имеем в качестве первичного ключа
комбинацию {NS, KP}. Кроме того, имеет место функциональная зависимость
номера группы студента и его специальности, то есть NG  SP. Если построить
диаграмму функциональных зависимостей для этого отношения, то она будет
иметь вид, представленный на рисунке 1.30.
NS
NG
KP
Sp
Oz
Рисунок 1.30 - Диаграмма функциональных зависимостей для отношения
УСПЕВАЕМОСТЬ
Нежелательность такой структуры связана с тем, что неключевые атрибуты не являются взаимно независимыми (NG  Sp), или с тем, что неключевые атрибуты не все неприводимо зависимы от первичного ключа (NG и Sp), а
зависимы от NS каждый в отдельности.
Кроме того, возникают дополнительные проблемы, связанные с избыточностью отношения. Так, скажем, при выполнении операции JNSERT (вставка)
нельзя вставить данные о студентах и студенческой группе, если ими еще не
89
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
сдавался экзамен. Для такого случая будет неизвестно значение первичного
ключа.
При выполнении операции DELETE (удаление) будет удалена информация не только о конкретной оценке студента по конкретному предмету, но и
информация о том, в какой группе и на какой специальности этот студент учится.
При выполнении операции UPDATA (обновление) для какого-либо студента при переводе его из одной группы в другую, возникает ситуация аномалии. Если мы будем вынуждены либо искать всю информацию об этом студенте, внося соответствующие коррективы, либо в отношении будет иметь место
несовместимый результат - один и тот же студент будет, как бы, одновременно
находиться в разных группах.
Избежать этих ситуаций можно путем замены исходного отношения на
два новых. Диаграмма функциональных зависимостей для двух новых отношений показана на рисунке 1.31.
Такая структура позволит выполнить без проблем: операцию INSERT
даже при отсутствии информации о сданных экзаменах; операцию DELETE над
оценками без потери информации о студенте; операцию UPDATE без необходимости исправления данных во всех кортежах, относящихся к переводимому в
другую группу студенту.
NS
NG
NS
Oz
KP
Sp
Рисунок 1.31 - Диаграмма функциональных зависимостей для двух новых
отношений
90
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Отношение находится во 2НФ в том случае, когда оно уже считается
находящимся в 1НФ и каждый неключевой атрибут полностью зависит от всего
(не от части, а от всего) первичного ключа.
Два новых отношения находятся во 2НФ с первичными ключами соответственно {NS, KP} и NS.
Действительно, если над этими отношениями
произвести соединение по атрибуту NS, то получим исходное отношение.
Однако в отношении СПЕЦИАЛЬНОСТЬ (рисунок 1.32) из-за функциональной зависимости NG  Sp все равно могут возникнуть проблемы при манипуляции с данными.
NG
NS
Sp
Рисунок 1.32 – Отношение СПЕЦИАЛЬНОСТЬ
Так, при выполнении операции INSERT нельзя указать, что данная группа
относится к некоторой специальности, пока в этой группе не появится хотя бы
один студент. Если над этим отношением будет выполнена операция DELETE,
то вместе с информацией о группе будет утрачена информация о специальности, по которой проходит обучение данная группа. В то же время, при выполнении операции UPDATE, при изменении наименования специальности возникнет
необходимость либо искать всю информацию по корректируемой специальности во всем отношении, внося соответствующие изменения, либо будет иметь
место несовместимый результат.
Для решения вновь возникших проблем заменим отношение СПЕЦИАЛЬНОСТЬ на две проекции – ГРУППА и СПЕЦИАЛЬНОСТЬ (рисунок 1.33).
91
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ГРУППА
NS
СПЕЦИАЛЬНОСТЬ
NG
NG
Sp
Рисунок 1.33 - Диаграмма функциональных зависимостей отношений
ГРУППА и СПЕЦИАЛЬНОСТЬ
Действительно, путем декомпозиции была исключена "двойная" зависимость атрибута Sp от первичного ключа NS и атрибута NG.
Отношение находится в ЗНФ в том случае, если оно находится во 2НФ,
неключевые атрибуты взаимно независимы (исключены так называемые транзитивные зависимости) и каждый неключевой атрибут неприводимо зависит от
первичного ключа (то есть возможно изменять значение атрибутов без изменения первичного ключа и других неключевых атрибутов).
Отношение, находящееся во 2НФ, всегда может быть приведено к эквивалентному набору отношений в ЗНФ
На практике схема отношений в ЗНФ в большинстве случаев достаточна,
то есть, приведением отношения к ЗНФ процесс проектирования реляционной
БД обычно заканчивается. Однако иногда полезно продолжить процесс нормализации.
Введем определение детерминанта. Детерминат - это любой атрибут, от
которого полностью функционально зависит некоторый другой атрибут.
Введя данное понятие, можно дать определение НФБК.
Отношение будет находиться в НФБК, если оно находится в 3НФ и каждый детерминант является потенциальным ключом.
92
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Если проанализировать рассмотренные выше примеры то можно сказать,
что отношение УСПЕВАЕМОСТЬ не находится в НФБК, а отношения ОЦЕНКА, ГРУППА, СПЕЦИАЛЬНОСТЬ находятся в НФБК.
Действительно, отношение УСПЕВАЕМОСТЬ содержит три детерминанта – NS, NG и {NS, KP}, из которых только {NS, KP} является потенциальным
ключом. Отсюда и сделан вывод, что отношение УСПЕВАЕМОСТЬ не находится в НФБК.
Для отношений ОЦЕНКА, ГРУППА, СПЕЦИАЛЬНОСТЬ можно говорить о том, что они находятся в НФБК, поскольку в каждом из них единственный потенциальный ключ является единственным детерминантом.
Рассмотрим отношение СТУДЕНТ, показанное на рисунке 1.34, которое
отображает связи между студентами, специальностями и секциями. Предположим, что студенты могут иметь несколько специальностей и изучают различные типы СУБД. В таком случае единственным ключом является комбинация
(НОМЕР СТУДЕНТА, СПЕЦИАЛЬНОСТЬ, СУБД). Например, студент с номером 10 специализируется на ПОВТАС и САПР и, кроме того, изучает СУБД Access и InterBasa, а студент с номером 15 специализируется только на ЛВС и занимается СУБД Oracle.
Какова связь между атрибутами НОМЕР СТУДЕНТА и СПЕЦИАЛЬНОСТЬ? Это не функциональная зависимость, поскольку у студента может
быть несколько специальностей. Одному и тому же значению атрибута НОМЕР
СТУДЕНТА может соответствовать много значений атрибута СПЕЦИАЛЬНОСТЬ. Помимо того, одному и тому же значению атрибута НОМЕР СТУДЕНТА может соответствовать много значений атрибута СУБД.
Такая зависимость атрибутов называется многозначной зависимостью
(multi-value dependency). Многозначные зависимости приводят к аномалиям модификации.
Для начала обратим внимание на избыточность данных в отношении
СТУДЕНТ (рисунок 1.34). Студенту с номером 10 посвящено четыре записи, в
каждой из которых указана одна из ее специализаций и одна из изучаемых
93
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
СУБД. Если бы те же данные хранились в меньшем количестве строк (скажем,
было бы две строки — одна для ПОВТАС и Access, а другая - для САПР и InterBase), это дезориентировало бы пользователей. Получалось бы, что студент с
номером 10 изучает Access только тогда, когда специализируется на ПОВТАС, а
в InterBasa работает только тогда, когда специализируется на САПР. Но такая
интерпретация нелогична. Специальности и СУБД совершенно независимы
друг от друга. Поэтому, чтобы избежать таких неверных заключений, мы храним все сочетания специальностей и СУБД.
Допустим, что студент с номером 10 решил изучать СУБД SQL Server, и
поэтому мы добавляем в таблицу строку [10, ПОВТАС, SQL Server], как показано на рисунке 1.35, а.
В этом случае из анализа отношения можно сделать
вывод, что студент 10 занимается SQL Server только как специалист ПОВТАС,
но не как специалист САПР. Чтобы данные имели согласованный характер, мы
должны добавить столько строк, сколько имеется специальностей, и в каждой из
них указать тип СУБД SQL Server. Таким образом, мы должны добавить строку
[10, САПР, SQL Server ], как показано на рисунке 1.35, 6. Это аномалия обновления: требуется слишком много модификаций, чтобы внести одно простое изменение.
СТУДЕНТ (Номер Студента, Специальность, СУБД)
Ключ: (Номер Студента, Специальность, СУБД)
Многозначные зависимости:
Номер Студента >> Специальность
Номер Студента >> СУБД
Номер Студента
10
10
10
10
15
Специальность
ПОВТАС
САПР
ПОВТАС
САПР
ЛВС
СУБД
Access
Access
InterBasa
InterBasa
Oracle
Рисунок 1.34 - Отношение с многозначными зависимостями
94
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Вообще говоря, многозначная зависимость существует, когда отношение
имеет минимум три атрибута, причем два из них являются многозначными, а их
значения зависят только от третьего атрибута. Другими словами, в отношении R
(А, В, С) существует многозначная зависимость, если А многозначным образом
определяет В и С, а сами В и С не зависят друг от друга. Как мы видели из
предыдущего примера, НОМЕР СТУДЕНТА многозначно определяет атрибуты
СПЕЦИАЛЬНОСТЬ и СУБД, но сами атрибуты СПЕЦИАЛЬНОСТЬ и СУБД не
зависят друг от друга.
Вернемся вновь к рисунку 1.34. Обратите внимание на то, как обозначаются многозначные зависимости: Номер Студента >> Специальность и Номер
Студента >> Секция. Это читается следующим образом: «атрибут НОМЕР
СТУДЕНТА многозначно определяет атрибут СПЕЦИАЛЬНОСТЬ» и «атрибут
НОМЕР СТУДЕНТА многозначно определяет атрибут СЕКЦИЯ». Данное отношение находится в НФБК (2НФ — поскольку его ключом является совокупность всех атрибутов, ЗНФ — так как отсутствуют транзитивные зависимости, и
НФБК — поскольку нет неключевых детерминантов). Однако, как мы убедились, оно имеет аномалии: если студент берет дополнительную специальность,
мы должны добавить в отношение столько строк, в скольких секциях данный
студент занимается, и в каждой из этих строк указать новую специальность. То
же самое справедливо и для случая, когда студент записывается в новую секцию. Если студент отказывается от одной из специальностей, мы должны удалить все строки, где указана данная специальность. Если студент занимается в
четырех секциях, то название специальности будет содержаться в четырех строках, и все эти строки необходимо будет удалить.
Чтобы устранить эти аномалии, мы должны избавиться от многозначной
зависимости. Мы сделаем это, создав два отношения, в каждом из которых будут храниться данные только по одному многозначному атрибуту.
СТУДЕНТ (Номер Студента, Специальность, СУБД)
Ключ: (Номер Студента, Специальность, СУБД)
95
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
10
10
10
10
10
ПОВТАС
ПОВТАС
САПР
ПОВТАС
САПР
SQL Server
Access
Access
InterBasa
InterBasa
15
ЛВС
Oracle
а
10
10
10
10
10
10
15
ПОВТАС
САПР
ПОВТАС
САПР
ПОВТАС
САПР
ЛВС
SQL Server
SQL Server
Access
Access
InterBasa
InterBasa
Oracle
б
Рисунок 1.35 - Отношение СТУДЕНТ с аномалиями вставки:
а – вставка одной строки;
б — вставка нескольких строк
Улучшенные результирующие отношения не будут иметь аномалий. Это отношения СТУДЕНТ-СПЕЦИАЛЬНОСТЬ (Номер Студента, Специальность) и СТУДЕНТ-СУБД (Номер Студента, СУБД), приведенные на рисунке 1.36.
СТУДЕНТ-СПЕЦИАЛЬНОСТЬ (Номер Студента, Специальность)
Ключ: (Номер Студента, Специальность)
Номер Студента
10
10
15
Специальность
ПОВТАС
САПР
ЛВС
СТУДЕНТ-СЕКЦИЯ (Номер Студента, СУБД)
Ключ: (Номер Студента, СУБД
96
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Номер Студента
10
10
10
15
СУБД
SQL Server
Access
InterBasa
Oracle
Рисунок 1.36 - Устранение многозначной зависимости
Исходя из сделанных нами рассуждений, мы определим четвертую нормальную форму следующим образом:
Отношение находится четвертой нормальной форме, если оно находится в
НФБК и не имеет многозначных зависимостей.
Уясним 4НФ на втором примере, рассмотрим схему отношения ПРЕДМЕТЫ,
приведенную на рисунке 1.37.
Код Предмета
ПРЕДМЕТЫ
Курс
Вид Отчетности
KP
KURS
WO
Рисунок 1.37 - Структура отношения ПРЕДМЕТЫ
Отношение ПРЕДМЕТЫ содержит коды предметов. Для каждого предмета
указывается перечень курсов, включенных в этот предмет и перечень видов отчетностей, предусматриваемых по курсу (при этом, по курсу видов отчетности может
быть несколько, а разные курсы могут включать одинаковые виды отчетности).
Каждый кортеж отношения связывает некоторый предмет с курсом и видом
отчетности, которые должны быть выполнены в рамках данного курса.
По причине сформулированных выше условий, единственным возможным
ключом отношения является составной атрибут {KP, KURS, WO} и нет никаких
других детерминантов. Следовательно, отношение ПРЕДМЕТЫ находится в НФБК.
Но при этом оно обладает недостатками: если, например, некоторый вид отчетности
добавляется к данному курсу, необходимо вставить в отношение ПРЕДМЕТЫ
97
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
столько кортежей, сколько видов отчетности в нем предусмотрено. Таким образом,
в данном отношении существуют многозначные зависимости.
В отношении R {А, В, С} существует многозначная зависимость между А и В
(А>> В) в том случае, если множество значений В, соответствующее паре значений
А и С, зависит только от А и не зависит от С.
В отношении ПРЕДМЕТЫ существуют следующие две многозначные зависимости:
KP >> KURS
KP>> WO
Дальнейшая нормализация отношений, подобных отношению ПРЕДМЕТЫ,
основывается на проецировании без потерь. Здесь под последним понимается такой
способ декомпозиции отношения, при котором исходное отношение полностью и
без избыточности восстанавливается путем естественного соединения полученных
отношений.
Таким образом:
Отношение находится в 4НФ, если в случае существования многозначной зависимости А >> В все остальные атрибуты отношения функционально зависят от А.
В нашем примере можно произвести декомпозицию отношения ПРЕДМЕТЫ в
два отношения ПРЕДМЕТЫ-КУРСЫ и ПРЕДМЕТЫ-ОТЧЕТНОСТЬ, как показано
на рисунке 1.38.
ПРЕДМЕТЫ – КУРСЫ
Код Предмета
Курс
KP
KURS
ПРЕДМЕТЫ - ОТЧЕТНОСТЬ
Код Предмета
Вид Отчетности
KP
WO
Рисунок 1.38 - Декомпозиция отношения ПРЕДМЕТЫ
98
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Оба полученных отношений находятся в 4НФ и свободны от отмеченных выше проблем.
Во всех рассмотренных до этого момента примерах
нормализация про-
изводилась методом декомпозиции одного отношения в два. Иногда это сделать не
удается, но возможна декомпозиция в большее число отношений, каждое из которых обладает лучшими свойствами. Рассмотрим отношение ПРЕПОДАВАТЕЛЬ,
структура которого приведена на рисунке 1.39.
ПРЕПОДАВАТЕЛЬ
Код Предмета
KP
Код кафедры
KK
Табельный номер
TN
Рисунок 1.39 - Структура отношения ПРЕПОДАВАТЕЛЬ
Предположим, что один и тот же преподаватель может работать на разных
кафедрах и проводить занятия по нескольким учебным предметам. Первичным ключом этого отношения является полная совокупность его атрибутов, то есть {KP, KK,
TN}. В отношении отсутствуют функциональные и многозначные зависимости. Поэтому отношение находится в 4НФ. Однако в нем могут существовать проблемы,
которые можно устранить путем декомпозиции в три отношения
Введем понятие зависимости соединения. Отношение R (X, Y,..., Z) удовлетворяет зависимости соединения * (X, Y,..., Z) только в том случае, когда R восстанавливается без потерь путем соединения своих проекций на X, Y,.... Z. Тогда:
Отношение находится в 5НФ (НФПС) только в том случае, когда любая зависимость соединения в отношении следует из существования некоторого возможного
ключа в данном отношении.
Введем следующие имена составных атрибутов:
PК = {KP, KK} – ПРЕДМЕТ-КАФЕДРА;
РN = {KP, TN} - ПРЕДМЕТ-ПРЕПОДАВАТЕЛЬ;
КN = {KK, TN} – КАФЕДРА-ПРЕПОДАВАТЕЛЬ.
99
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Предположим, что в отношении ПРЕПОДАВАТЕЛЬ существует зависимость
соединения: * ( PK, РN, КN).
На примерах легко показать, что при вставках и удалениях кортежей из отношения ПРЕПОДАВАТЕЛЬ могут возникнуть проблемы. Их можно устранить путем декомпозиции исходного отношения в три новых отношения, представленных
на рисунке 1.40.
ПРЕДМЕТ - КАФЕДРА
KP
KK
ПРЕДМЕТ - ПРЕПОДОВАТЕЛЬ
KP
TN
КАФЕДРА - ПРЕПОДАВАТЕЛЬ
KK
TN
Рисунок 1.40 - Декомпозиция отношения ПРЕПОДАВАТЕЛЬ
5НФ - это нормальная форма, которую можно получить путем декомпозиции
на три и более отношений, при этом ее условия достаточно нетривиальны, и на
практике 5НФ используется достаточно редко.
И, наконец, рассмотрим последнюю нормальную форму – ДКНФ.
Все описанные выше нормальные формы были выделены исследователями,
выявившими аномалии у некоторых отношений, которые находились в нормальной
форме более низкого порядка: обнаружение аномалий модификации у отношений во
второй нормальной форме привело к определению третьей нормальной формы и т.
д. Хотя каждая новая нормальная форма решала часть проблем, найденных у предыдущей нормальной формы, никто не мог сказать, какие проблемы еще не выявлены.
Каждый такой шаг являлся прогрессом на пути к представлению об оптимальной
структуре базы данных, однако никто не мог гарантировать, что не будет ли обнаружено еще каких-либо аномалий.
100
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рассмотрим нормальную форму, которая будет свободна от аномалий любого
типа. Когда мы приводим отношения к этой форме, мы знаем, что в этом случае даже скрытые аномалии, связанные с пятой нормальной формой, возникнуть не могут.
В 1981г. Фагин опубликовал важную статью, в которой он определил доменно-ключевую нормальную форму.
Он показал, что отношение в ДКНФ не имеет аномалий модификации и более
того, любое отношение, не имеющее аномалий модификации, должно находиться в
ДКНФ. Это открытие положило конец введению последующих нормальных форм, и
теперь в нормальных формах более высокого порядка нет необходимости — по
крайней мере, для устранения аномалий модификации.
Столь же важно и то, что определение доменно-ключевой нормальной формы
затрагивает только понятия домена и ключа. Они непосредственно поддерживаются
существующими СУБД. В каком-то смысле, работа Фагина формализовала и обосновала то, во что многие специалисты верили интуитивно, но были не в состоянии
точно описать.
Понятие ДКНФ весьма просто:
Отношение находится в доменно-ключевой нормальной форме, если каждое
ограничение, накладываемое на это отношение, является логическим следствием
определения доменов и ключей.
Рассмотрим важные термины, фигурирующие в этом определении: ограничение, ключ и домен.
Термин ограничение (constraint) имеет в данном определении намеренно широкое толкование. Фагин определяет ограничение как любое правило, регулирующее возможные статические значения атрибутов и достаточно точное для того, чтобы можно было установить, выполняется оно или нет. Правила редактирования, ограничения взаимоотношений и структуры отношений, функциональные зависимости и многозначные зависимости являются примерами таких
ограничений. Фагин явным образом исключает отсюда ограничения, относящиеся к
изменениям значений данных, или ограничения, зависящие от времени. Например,
101
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
правило «Стипендия студента за текущий период не может быть меньше, чем за
предыдущий период» не подпадает под определение ограничения, которое дал Фагин. За исключением ограничений, зависящих от времени, определение Фагина является широким и охватывает много случаев.
Ключ (Key) — это уникальный идентификатор кортежа, как мы его уже знаем.
Третий важный термин в определении ДКНФ — домен (domain). Мы уже уяснили ранее, что домен — это описание допустимых значений атрибута. Он состоит
из двух частей: физического описания и семантического (логического) описания.
Физическое описание — это множество значений, которые может принимать атрибут, а логическое описание — это смысл данного атрибута. Доказательство Фагина
относится к обеим частям.
Говоря неформально, отношение находится в ДКНФ, если выполнение ограничений на домены и ключи приводит к выполнению всех ограничений и отношения в ДКНФ не могут иметь аномалий модификации.
СУБД может предотвратить возникновение этих аномалий, реализуя выполнение ограничений на домены и ключи.
К сожалению, пока не известен ни один алгоритм преобразования отношения
к доменно-ключевой нормальной форме; неизвестно даже, какие отношения могут
быть приведены к ДКНФ. Нахождение и создание отношений в ДКНФ является более искусством, чем наукой.
Выводы. Таким образом, мы пришли к итоговой схеме (общим определениям
и общим правилам) процедуры нормализации отношений.
Отношение в 1НФ необходимо разбить на проекции для исключения всех зависимостей, не являющихся неприводимыми. Все неключевые атрибуты должны зависеть от всего ключа. Как результат в итоге будет получен набор отношений во
2НФ.
Отношение, находящееся в 2НФ следует разбить на проекции для исключения
"двойных" функциональных зависимостей (транзитивных зависимостей). В результате будет получен набор отношений в ЗНФ.
102
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Полученные отношения в ЗНФ следует разбить на проекции для исключения
любых функциональных зависимостей, в которых детерминанты являются потенциальными ключами. В результате такого приведения будет получен набор отношений в НФБК.
Отношения, находящиеся в НФБК. необходимо разбить на проекции для исключения любых многозначных зависимостей, которые не являются функциональными. В итоге получим набор отношений в 4НФ.
Отношения в 4НФ разбивают на проекции с целью исключения любых зависимостей соединения, которые не обусловлены потенциальными ключами. Таким
образом будет получен набор отношений в 5НФ.
ДКНФ является ориентиром в процессе проектирования базы данных, но как
его достичь никто пока не знает.
Вопросы для самоконтроля
1. Объясните понятие «функциональная зависимость».
2. Что называется многозначной функциональной зависимостью?
3. Что называется транзитивной функциональной зависимостью?
4. Поясните какие аномалии могут быть в базах данных?
5. Объясните суть нормализации.
6. Объясните требования к 1НФ.
7. Объясните требования ко 2НФ.
8. Объясните требования к 3НФ.
9. Объясните требования к НФБК.
10. Объясните требования к 4НФ.
11. Объясните требования к 5НФ.
12. Объясните требования к ДКНФ.
103
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
1.5 Моделирование данных
Моделирование данных — это сложный процесс создания логического представления структуры базы данных. Правильно сконструированная модель данных должна
быть адекватна предметной области, т.е. соответствовать всем пользовательским представлениям данных. Если база данных будет неверно отражать пользовательское представление данных, то пользователи найдут ее приложения неудобными, неполными и
непригодными для работы. Поэтому моделирование данных является первым и основным этапом в разработке системы баз данных, основой для всей последующей работы
при разработке баз данных и их приложений.
Ключевые слова: диаграмма «сущность—связь», сущности, атрибуты, идентификаторы и связи, семантический объект, представления, кардинальное число атрибута,
типы и подтипы сущностей, слабая сущность, СДМ – методика, семантическая объектная модель, семантическая объектная диаграмма.
Введение
Началом проектирования баз данных является анализ данных предметной области, представление реальной информации, которая будет хранится в базе данных в виде
одного или нескольких отношений. Очень важно уяснить разработчику базы данных
так называемый «деловой регламент» вместе с заказчиком базы данных. В деловом регламенте должно быть отражено все, что касается предметной области: виды деятельности, информационные потоки, документооборот, различные условия, ограничения,
стандартные значения и т.д.
Разработанная модель должна отражать логическую структуру данных, так же
как блок-схемы алгоритмов с операторными блоками и условными операторами отражают логическую структуру программы.
На сегодняшний день не существует единого общепринятого стандарта для представления моделей базы данных, зато есть набор общих конструкций и правил (нотаций),
которые лежат в основе большинства вариантов этих моделей.
104
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
На рисунке 1.41 показана структура существующих подходов в моделировании
баз данных. Основным классификатором подходов моделирования является способ автоматизации: ручной, неавтоматизированный способ относят к структурному (процедурному) походу; использование средств автоматизации проектирования предполагает
автоматизированный подход моделирования – с применением САПР базы данных, с
применением CASE – технологий (проектирование с помощью компьютера) на протяжении всего жизненного цикла базы данных, применение объектно-ориентированных
языков программирования.
Моделирование данных - процесс создания логического
представления структуры базы данных
Структурные подходы
Объектная семантическая модель
Модель
«Сущность-связь»
(Эдгар Кодд)
Язык UML
Ричард Баркер
Питер Чен
Объектно-ориентированные подходы
Использование CASE - технологий на основе САПР
( Rational Rose )
Рисунок 1.41 – Классификация подходов в моделировании баз данных
Символы, применяемые для графического представления моделей, весьма различны. Мы обсудим не только традиционные символы, но и символы языка UML (Uni105
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
fied Model Language, унифицированный язык моделирования) — средства проектирования, завоевывающего все большую популярность среди программистов ООП и
включающего в себя модель «сущность—связь».
Модель «сущность—связь»
Рассмотрим правила построения, проиллюстрируем на примерах использование
модели «сущность—связь» (entity-relationship model), введенной Питером Ченом (Peter Chen) в 1976 году. Чен заложил основу модели, которая с тех пор расширялась и
модифицировалась самим Ченом и многими другими учеными. Модель «сущность—
связь» вошла в состав множества CASE-инструментов, которые также внесли свой
вклад в ее эволюцию.
Ключевыми элементами модели «сущность—связь» являются сущности, атрибуты, идентификаторы и связи. Несмотря на то, что нам уже известны эти определения
из предыдущих лекций, рассмотрим на практических примерах правила их графического отображения в моделях.
Сущность (entity) — это некоторый объект, идентифицируемый пользователем в предметной области.
Примерами сущностей могут служить СТУДЕНТ (рисунок 1.42). Сущности одного
и того же типа группируются в классы сущностей (entity classes). Так, класс сущностей СТУДЕНТ является совокупностью всех сущностей СТУДЕНТ.
В моделях классы сущностей обозначаются заглавными буквами.
Важно уяснить разницу между классом сущностей и экземпляром сущности. Класс сущностей — это совокупность сущностей, и описывается оп структурой или форматом сущностей, составляющих этот класс. Экземпляр сущности
(entity instance) представляет конкретную сущность, такую как СТУДЕНТ 101; он
описывается значениями атрибутов данной сущности. Обычно класс сущностей содержит множество экземпляров сущности.
106
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
СТУДЕНТ
сущность содержит:
Номер Студента
Фамилия
Имя
Отчество
Адрес
Год рождения
Балл при поступлении
Номер Телефона
Два экземпляра сущности СТУДЕНТ
101
Соловьев
Николай
Алексеевич
Оренбург
1985
5,0
24-44-25
110
Скворцова
Ирина
Михайловна
Москва
1986
4,6
64-62-25
Рисунок 1.42 – Сущность СТУДЕНТ
У сущностей есть атрибуты (attributes), или, как их иногда называют, свойства (properties), которые описывают характеристики сущности. В моделях атрибуты обозначаются как прописными, так и строчными буквами. В модели
«сущность—связь» предполагается, что экземпляры данного класса сущностей
имеют одинаковые атрибуты.
Исходное определение модели «сущность—связь» включает в себя композитные атрибуты (composite attributes) и многозначные атрибуты (multi-valued attributes). В качестве примера композитного атрибута можно привести атрибут Адрес,
который может состоять из группы атрибутов {Улица, Город, Область, Индекс}.
Иными словами, композитный атрибут можно обозначить как сумму отдельных
атрибутов.
Примером многозначного атрибута может служить атрибут Балл при поступлении, который может содержать либо балл по результатам единого государственного экзамена (ЕГЭ), либо балл по результатам вступительных экзаменов по тестам, балл по результатам собеседования и т.п. Атрибут может быть одновременно
и композитным, и многозначным, например, композитный атрибут Телефон, со107
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
стоящий из группы атрибутов {Код Региона, Местный Номер}, может быть и многозначным, что позволит иметь в базе данных несколько телефонных номеров одного и того же лица. В большинстве реализаций модели «сущность—связь» однозначные композитные атрибуты игнорируются, и требуется, чтобы многозначные
атрибуты (будь они составные или нет) преобразовывались в другие сущности
для исключения неоднозначности.
Экземпляры сущностей имеют идентификаторы (identifiers) - это атрибуты, с помощью которых эти экземпляры именуются, или идентифицируются.
Например, экземпляры сущностей класса СТУДЕНТ могут идентифицироваться по
атрибутам Номер Зачетной Книжки. Такие атрибуты, как Адрес или Фамилия, не
могут служить идентификаторами экземпляров сущностей класса СТУДЕНТ, поскольку обычно эти атрибуты не используются для однозначного указания на конкретного студента.
Идентификатор экземпляра сущности состоит из одного или более атрибутов сущности. Идентификатор может быть уникальным (unique) либо неуникальным (nonunique). Если идентификатор является уникальным, его значение будет указывать на один и только один экземпляр сущности. Если идентификатор является неуникальным, его значение будет указывать на некоторое множество экземпляров. Номер зачетной книжки студента является уникальным идентификатором, а Фамилия - неуникальным (например, может быть несколько студентов по
фамилии Иванов.
Идентификаторы, состоящие из нескольких атрибутов, называются композитными идентификаторами (composite identifiers). Примером может для телефона - совокупность вида {Код Региона, Местный Номер}.
Взаимоотношения сущностей выражаются связями (relationships). Модель
«сущность—связь» включает в себя классы связей и экземпляры связей.
Классы связей (relationship classes) - это взаимоотношения между классами
сущностей, а экземпляры связи (relationship instances) — взаимоотношения между
экземплярами сущностей. У связей могут быть атрибуты.
108
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Класс связей может затрагивать несколько классов сущностей. Число классов сущностей, участвующих в связи, называется степенью связи (relationship degree).
Изображенная на рисунке 1.43, а связь СТУДЕНТ-ГРУППА имеет степень 2,
поскольку в ней участвуют два класса сущностей: СТУДЕНТ и ГРУППА. Связь
КОМЛЕКТАЦИЯ (рисунок 1.43, б) имеет степень N, так как в ней могут участвовать несколько классов сущностей.
Связи степени 2 весьма распространены, их часто называют еще бинарными
связями (binary relationships).
ГРУППА
ДВИГАТЕЛЬ
…….
…….
ГРУППА-СТУДЕНТ
СТУДЕНТ
а
КУЗОВ
КОМПЛЕКТАЦИЯ
АВТОМОБИЛЬ
б
Рисунок 1.43 - Различные степени связей:
а — связь степени 2; б — связь степени N
На рисунке 1.44 показаны три основных типа бинарных связей.
В связи 1:1 («один к одному») одиночный экземпляр сущности одного типа связан с одиночным экземпляром сущности другого типа. На рисунке 1.44, а
связь БРАК связывает одиночную сущность класса МУЖ с одиночной сущностью
класса ЖЕНА. В соответствии с этой диаграммой, ни за одним мужем не может записано более одной жены, и ни один муж не может быть записан более чем за одной женой.
Числа внутри ромба, символизирующего связь, обозначают максимальное
количество сущностей на каждой стороне связи. Эти ограничения называются
максимальными кардинальными числами, а совокупность из двух таких ограниче109
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ний для обеих сторон связи называется максимальной кардинальностью (maximum
cardinality) связи. Например, о связи, изображенной на рисунке 1.43, б, говорят,
что она обладает максимальной кардинальностью 1:N. Кардинальные числа могут иметь и другие значения, а не только 1 и N. Например, связь между сущностями ПРДАВЕЦ и ТОВАР может иметь кардинальность 1:10, что говорит нам о том,
что в магазине у продавца может быть не более десяти видов товаров.
МУЖ
1:1
а
ПРОДАВЕЦ
ЖЕНА
БРАК
ТОВАР
1:N
б
СТУДЕНТ
ПРОДАВЕЦ-ТОВАР
N:M
ПРЕПОДАВАТЕЛЬ
СТУДЕНТ-ПРЕПОДАВАТЕЛЬ
в
Рисунок 1.44 - Три типа бинарных связей: а — бинарная связь 1:1; б — бинарная связь 1:N; в — бинарная связь N:M
Связи трех типов, представленных на рисунке 1.44, называются иногда
связями типа «имеет», или связями обладания (HAS-A relationships). Такой термин
используется потому, что одна сущность имеет (has) связь с другой сущностью.
Например: муж может иметь одну жену, продавец имеет товары, у преподавателей имеются студенты.
Схемы, изображенные на рисунке 1.44, называются диаграммами «сущность—связь», или ER-диаграммами (entity-relationship diagrams, ER-diagrams).
Такие диаграммы стандартизированы, но не слишком жестко. В соответствии с
110
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
этим стандартом, классы сущностей обозначаются прямоугольниками, связи обозначаются ромбами, а максимальное кардинальное число каждой связи указывается внутри ромба. Имя сущности указывается внутри прямоугольника, а имя связи
указывается рядом с ромбом.
Как мы уже говорили, максимальная кардинальность показывает максимальное число сущностей, которые могут участвовать в связи. Каково же минимальное
число таких сущностей, приведенные диаграммы не сообщают. Например, рисунок 1.44,а показывает, что муж может иметь одну жену, однако из диаграммы не
ясно, обязан ли муж быть в официальном браке с женой.
Для указания минимальной кардинальности (minimum cardinality) существует несколько способов. Один из них, показанный на рисунке 1.45, заключается
в следующем: чтобы показать, что сущность обязана участвовать в связи, на линию
связи помещают перпендикулярную черту, а чтобы показать, что сущность может
(но не обязана) участвовать в связи, на линию связи помещают овал. Соответственно, диаграмма показывает, что сущность ОБЩЕЖИТИЕ должна быть связана как
минимум с одной сущностью СТУДЕНТ, однако сущность СТУДЕНТ не обязана
иметь связь с сущностью ОБЩЕЖИТИЕ. Полный набор накладываемых на связь
ограничений состоит в том, что ОБЩЕЖИТИЕ имеет минимальное кардинальное
число, равное единице, и максимальное кардинальное число, равное «многим»
сущностям СТУДЕНТ. СТУДЕНТ имеет минимальное кардинальное число, равное
нулю, и максимальное кардинальное число, равное одному экземпляру сущности
ОБЩЕЖИТИЕ.
ОБЩЕЖИТИЕ
1:N
СТУДЕНТ
ПРОЖИВАНИЕ
Рисунок 1.45 - Связь с указанием минимальной кардинальности
Может существовать связь между сущностями одного и того же класса.
Например, для сущностей класса КЛИЕНТ может быть определена связь НОВЫЙ
КЛИЕНТ, если нового клиента в фирму привел прежний клиент. Такая связь пока-
111
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
зана на рисунке 1.46. Связи между сущностями одного и того же класса называются иногда рекурсивными связями (recursive relationships).
КЛИЕНТ
1:N
Рисунок 1.46 - Рекурсивная связь
В некоторых моделях ER-диаграмм атрибуты обозначаются эллипсами, соединенными с сущностью или связью, которой они принадлежат. На рисунках 1.47
и 1.48 показаны примеры ER – диаграмм с атрибутами. Если сущность имеет много
атрибутов, такое их перечисление в ER-диаграмме может сделать ее чересчур громоздкой (как на рисунке 1.48) и трудной для восприятия. В подобных случаях список атрибутов сущностей дается отдельно, как показано на рисунке 1.49.
Рисунок 1.47 – ER-диаграмма «Студент» с атрибутами
112
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
код кл
код зак
фирма
1
код кл
код тов
код зак
М
клиент
код сотр
заказ на товар
1 М
товар
М
адрес
М
код сотр
фамилия
1
1
цена
код тов
сведения о
товаре
сотрудник
М
оплата
должн
М
наименован
цена
М
код опл
1
код зак
код опл
метод
оплаты
карточка
дата
сумма
Рисунок 1.48 - ER-диаграмма предметной области «Реализация товаров»
Заказы на товар
Код заказа
Код клиента
Код сотрудника
Номер заказа
Дата получения заказа
Дата назначения заказа
Изготовитель модели
Серийный номер
Описание неисправности
Дата завершения ремонта
Выдано
Налоговая ставка
113
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
………………
Клиент - покупатель
Код клиента
Название компании
Имя заказчика
Фамилия заказчика
Адрес счета
Город
Область
Почтовый индекс
Страна
Должность
Телефон
Факс
Рисунок 1.49 – Отдельное перечисление атрибутов в таблицах
В модели «сущность—связь» определен особый тип сущности, называемый
слабой сущностью (weak entity). К слабым сущностям относятся такие сущности,
которые могут существовать в базе данных только в том случае, если в ней присутствует сущность некоторого другого типа. Сущность, не являющаяся слабой,
называется сильной сущностью (strong entity).
Чтобы разобраться в том, что такое слабые сущности, рассмотрим базу данных фирмы, реализующей товары (рисунок 1.50).
ЗАКАЗ
1:N
КЛИЕНТ
ЗАКАЗЫ НА ТОВАРЫ
Рисунок 1.50 - Пример слабой сущности
Предположим, что, в соответствии с деловым регламентом, экземпляр сущности КЛИЕНТ может существовать, не будучи связанным ни с одной сущностью
класса ЗАКАЗ, но сущность ЗАКАЗ не может существовать вне связи с какой-либо
сущностью класса КЛИЕНТ. Тогда сущность ЗАКАЗ является слабой. Это означает,
114
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
что данные о сущности ЗАКАЗ могут появиться в базе данных только в том случае,
если эта сущность имеет связь с какой-либо сущностью класса КЛИЕНТ. Как показано на рисунке 1.50, слабые сущности обозначаются прямоугольниками с закругленными углами.
Некоторые сущности имеют необязательные наборы атрибутов. Эти сущности
часто представляются с помощью подтипов (subtypes).
Рассмотрим, например, сущность СТУДЕНТ, которая может иметь атрибуты
для студентов, обучающихся на бюджетной основе, и есть атрибуты для студентов,
обучающихся на коммерческой основе. Тогда для экземпляров сущностей СТУДЕНТ, обучающихся
на бюджетной основе будут необязательными атрибуты для
студентов, обучающихся на коммерческой основе. Или другой, который может
быть связан с сущностью ПРЕПОДАВАТЕЛЬ в том случае, если в штате преподавателей есть такие, которые приняты по конкурсу, есть преподаватели с почасовой
оплатой, есть преподаватели по совместительству и т.д. В этом случае на ERдиаграмме показываются подтипы, как показано на рисунке 1.51.
СТУДЕНТ
m
СТУДЕНТ
СТУДЕНТ
на бюджетной основе
на коммерческой
основе
Рисунок 1.51 – Пример изображения подтипов
Символ
над сущностями указывает, что они являются подтипами сущности
СТУДЕНТ. Каждый подтип должен принадлежать надтипу СТУДЕНТ. Кривая линия с цифрой m рядом показывает, что сущность надтип может включать все подтипы. Если бы стояла цифра 1, то это обозначало, что сущность надтип должна при115
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
надлежать к одному и только одному подтипу. В этом случае подтипы являются
взаимоисключающими и что требуется только один из них.
Диаграммы «сущность—связь» в стиле UML
Унифицированный язык моделирования UML (Unified Modeling Language)
представляет собой язык для определения, представления, проектирования и документирования программных систем различного назначения.
Унифицированный язык моделирования (UML) — это набор структур и методик для моделирования и проектирования объектно-ориентированных программ
(ООП) и приложений. UML — это одновременно и методология разработки систем
ООП, и набор инструментов для разработки таких систем.
UML содержит стандартный набор диаграмм и нотаций самых разнообразных
видов. UML создан на основе методов объектно-ориентированного анализа и проектирования в 1995 г.
Одной из главных целей UML - это предоставить пользователям готовый к
использованию выразительный язык визуального моделирования, позволяющий им
разрабатывать осмысленные модели и обмениваться ими.
Мы рассмотрим UML как средство для моделирования данных, как инструмент для построения диаграммы «сущность - связь».
Сущности и связи в UML
На рисунке 1.52 показан пример представления данных в стиле UML. Каждая
сущность представлена классом сущностей, который изображен в виде прямоугольника с тремя сегментами. В верхнем сегменте указано имя сущности. Во втором
сегменте перечислены имена атрибутов сущности, а в третьем описаны ограничения
и методы (программные процедуры), относящиеся к данной сущности.
Связи показаны линиями, соединяющими две сущности. Кардинальность
представлена в формате х..у, где х — это необходимый минимум, а у — допустимый
максимум. Так, 0..1 означает, что наличие данной сущности необязательно, а мак116
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
симально допустимое количество — одна. Звездочка представляет неограниченное
количество. Например, запись 1..* означает, что требуется одна сущность, а допускается неограниченное количество.
КУРС
КУРС-СТУДЕНТ
0..*
1..1
0..*
СТУДЕНТ
Номер курса
Форма обучения
Номер студента
Фамилия
Имя
Отчество
Год рождения
Адрес
Ограничения и методы
Ограничения и методы
Рисунок 1.52 - Представления сущностей и связей в UML
Представление слабых сущностей
На рисунке 1.53 изображено представление слабых сущностей в стиле UML.
На линии связи рядом с сущностью, от которой зависит слабая сущность, помещается закрашенный ромб. Сущность РЕЦЕПТ является слабой сущностью, а сущность ПАЦИЕНТ — ее родителем. Все слабые сущности имеют родителя, поэтому
их кардинальность в связи с родителем всегда 1..1. Исходя из этого, кардинальность
на родительской стороне обозначается просто как 1.
ПАЦИЕНТ
Номер пациента
Ф.И.О.
Адрес
Телефон
Идентификатор: Номер
пациента
Методы
ПАЦЕНТ-РЕЦЕПТ
1
0..*
РЕЦЕПТ
Номер рецепта
Название лекарства
Доза
Кто выписал
Идентификатор: Номер Рецепта
Методы
Рисунок 1.53 - Представление слабых сущностей в UML
UML использует объектно-ориентированную нотацию для обозначения видимости атрибутов и методов. Атрибуты, именам которых предшествует знак «+», яв117
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ляются открытыми, атрибуты со знаком «#» являются защищенными, а со знаком «» - закрытыми. Эти термины имеют корни в объектно-ориентированном программировании. Открытым (public) называется такой атрибут, который может читаться и
изменяться любым методом любого объекта. Термин защищенный (protected) означает, что атрибут или метод доступен только для методов данного класса и его подклассов, а термин закрытый (private) указывает на то, что соответствующий атрибут
или метод доступен только для методов данного класса.
Информационное проектирование по СДМ-методике (Casting Developing
Method) Ричарда Баркера
На рисунке 1.54. показан пример ER – диаграммы предметной области «учебный процесс» с использованием CDM – методики.
Кафедра
Факультет
# *Код_кафедры
*Название
о Описание
# *Код_факультета
*Название
о Описание
содержится
содержит
имеет
Группа
имеется
# *Номер_группы
*Курс
*Форма_обучения
Рисунок 1.54 – ER-диаграмма предметной области
К основным соглашениям графического отображения объектов диаграммы относятся:
- классы объектов изображаются в прямоугольниках с закругленными углами;
- в названии класса первая буква заглавная, а в свойствах прописные буквы;
- связи обозначаются линиями;
118
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
- обозначение свойств:
- звездочка «*» - обозначает обязательное свойство;
- нолик «о»
- обозначает необязательное свойство;
- решетка «#» - это ключевое свойство.
Семантическая объектная модель
Семантическая объектная модель (semantic object model), которая, так же как и
модель «сущность - связь», используется для моделирования данных. Семантическая объектная модель была впервые представлена Эдгаром Коддом в 1988 году как
модель данных.
Какой способ лучше, какой способ выбрать? Ответим так. Конкретная форма
модели данных зависит от способа проведения исследования.
При нисходящем проектировании «сверху - вниз», заказчик определяет общую концепцию системы, заказчик еще не знает какие будут отчетные данные и в
какой форме будет представляться выходная информация При этом используется
модель «сущность—связь». Конструируемая модель будет содержать сущности, атрибуты и связи. На основе построенной модели формируются пользовательские
конструкции данных, такие, как формы, отчеты, запросы, элементы интерфейса и
т.п.
При восходящем проектировании, «снизу - вверх», заказчик вместе с проектировщиком анализируют предоставленные ими отчеты, формы и запросы и на их основе строят пользовательскую модель данных. Эта модель данных в дальнейшем
воплощается в структуре базы данных. В случае использования семантической объектной модели конструируемая модель будет содержать семантические объекты и
связанные с ними конструкции.
Какой способ предпочтительнее? Однозначного ответа нет, так как выбор способа моделирования зависит от постановки задачи заказчиком. Статистика показывает, что первый способ используется в 80% случаев. Второй способ, несмотря на
то, что он более конкретный (значит менее абстрактный), является лучшим по сравнению с первым способом с точки зрения более качественной детализации констру119
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ируемой модели данных. Иначе говоря, еще не построив модель, проектировщик
уже знает, что будет на выходе системы базы данных. Однако, в процентном отношении предпочтения выбора, второй способ моделирования выбирают всего 20%
проектировщиков.
Семантические объекты
Начальная задача проектировщика базы данных состоит в том, чтобы определить зависимость форм, отчетов и запросов от сущностей и объектов, представляющие смысловой интерес для потребителя базы данных.
Поэтому целью ранних стадий разработки базы данных является определение
того, какие объекты должны быть представлены в базе данных, с какими характеристиками и с какими взаимосвязями.
Возник термин – «семантический объект» (semantic objects). Слово семантический означает «смысловой», и семантический объект — это объект, который в определенной степени моделирует смысл пользовательских данных. Семантические объекты моделируют восприятие пользователя более точно, чем модель «сущность—
связь».
Сущности и объекты в некоторых отношениях схожи, но у них есть и различия. Сходство заключается в том, что семантический объект — это представление
некоторой вещи, идентифицируемой в рабочей среде пользователя. Если выражаться более формально, семантический объект — это именованная совокупность атрибутов, которая в достаточной степени описывает отдельный экземпляр. Подобно
сущностям, семантические объекты группируются в классы. У объектного класса
есть имя, которое отличает его от других классов и соответствует именам вещей,
представляемых этим классом.
Семантические объекты имеют атрибуты, описывающие их характеристики.
Есть три типа атрибутов.
Простые атрибуты (simple attributes) состоят из одного элемента (например,
фамилия студента).
120
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Групповые атрибуты (group attributes) являют собой совокупности других атрибутов ( пример - атрибут Адрес, состоящий из атрибутов {Улица, Город, Область,
Индекс}).
Семантические объектные атрибуты (semantic object attributes) — это атрибуты, которые устанавливают связь между двумя семантическими объектами ( пример
– атрибут ФАКУЛЬТЕТ, ПРЕПОДАВАТЕЛЬ, СТУДЕНТ, показанные на рисунке
1.55).
На рисунке 1.55 показана, так называемая, семантическая объектная диаграмма (semantic object diagram), или просто объектная диаграмма (object diagram). Такие
диаграммы используются разработчиками для описания и визуального представления структуры объектов. Объекты изображаются в вертикально ориентированных
прямоугольниках. Имя объекта указывается вверху, а атрибуты записываются по
порядку после имени объекта.
Рисунок 1.55 – Семантическая объектная диаграмма объекта КАФЕДРА
Смысл этих объектных атрибутов, или объектных ссылок (object links) состоит в том, что когда пользователь анализирует информацию о кафедре, он имеет в
виду не только название кафедры, ее адрес, номер телефона кафедры, но и также
факультет, в котором она находится, преподавателей и студентов, находящихся в
121
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ней. Поскольку ФАКУЛЬТЕТ, ПРЕПОДАВАТЕЛЬ и СТУДЕНТ также являются
объектами, полная модель данных содержит диаграммы и для них. Объект ФАКУЛЬТЕТ несет в себе атрибуты факультета, объект ПРЕПОДАВАТЕЛЬ – атрибуты
преподавательского состава, а объект СТУДЕНТ содержит атрибуты студентов.
Каждый атрибут семантического объекта имеет максимальное и минимальное
кардинальные числа. Минимальное кардинальное число показывает количество экземпляров атрибута, которые должны существовать, чтобы объект был допустимым.
Обычно это число равно 0 или 1. Если оно равно 0, атрибут не обязан иметь значение, а если 1, то атрибут обязан иметь значение. Минимальное кардинальное число
иногда может быть больше единицы. Например, атрибут Студент в объекте под
названием ГРУППА может иметь минимальное кардинальное число, равное 10, это
означает, что наименьшее число студентов, требуемое для создания группы равно
10.
Максимальное кардинальное число показывает максимальное количество экземпляров атрибута, которое может иметь объект. Обычно оно равно 1 или N. Если
оно равно 1, атрибут может иметь не более одного экземпляра; если оно равно N,
атрибут может иметь много экземпляров, и предельное количество не задано. Иногда максимальное кардинальное число равно определенному числу, например 5, —
это означает, что объект может иметь не более пяти экземпляров атрибута.
Кардинальность изображается в виде нижнего индекса атрибута в формате
N.M, где N — минимальное кардинальное число, а М — максимальное. На рисунке
1.55 минимальное кардинальное число для атрибута Название Кафедры равно 1, и
максимальное также 1; таким образом, требуется ровно один экземпляр этого атрибута. Кардинальность атрибута Телефон равна 1.N, то есть кафедра обязана иметь
минимум один номер телефона, но в принципе номеров у нее может быть много.
Объектный идентификатор (object identifier) — это один или несколько объектных атрибутов, с помощью которых пользователи идентифицируют экземпляры
объектов В семантических объектных диаграммах объектные идентификаторы обозначаются с помощью букв ID перед атрибутом. Обычно, если атрибут должен использоваться в качестве идентификатора, он обязан иметь значение. Кроме того, как
122
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
правило, для данного объекта имеется не более одного идентифицирующего атрибута. Поэтому в большинстве случаев кардинальность атрибута-идентификатора равна
1.1.
Домен (domain) атрибута — это описание множества его значений. Характеристики домена зависят от типа атрибута. Домен простого атрибута состоит из физического и семантического описания. Физическое описание (physical description)
показывает тип данных (например, число или строка), длину данных и другие ограничения (например, требование, чтобы первый символ был буквой или чтобы значение не превышало 10). Семантическое описание (semantic description) указывает
функцию, или назначение данного атрибута; оно отличает этот атрибут от других
атрибутов с тем же физическим описанием.
Вопросы для самоконтроля
1. Назовите типы моделей баз данных и дайте им общую характеристику.
2. Нотации построения модели «сущность - связь» по методу Ричарда Баркера.
3. Соглашения построения модели «сущность - связь» с использованием
UML.
4. Что называется максимальным кардинальным числом?
5. Приведите примеры рекурсивных связей.
6. Приведите примеры слабых сущностей.
7. Приведите примеры типов и подтипов.
8. Как отображается кардинальность в стиле UML?
9. В чем отличие моделей «сущность – связь» и семантической объектной
модели?
123
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
2 Технология работ с базами данных в СУБД Access
Технология разработки таблиц баз данных
Процесс создания таблиц баз данных можно подразделить на следующие этапы:
•
разработка физической модели данных;
•
создание таблицы с помощью Конструктора таблиц;
•
установление связей между таблицами;
•
заполнение таблиц данными.
Разработка физической модели данных
Прежде чем включить компьютер и запустить ACCESS, мы предлагаем с карандашом в руках составить обязательные характеристики объектов БД, т.е. физическую
модель данных:
•
установить номенклатуру признаков описания объекта (состав и число
полей);
•
установить характеристики каждого поля таблицы;
•
оформить результаты в табличном виде (таблица 2.1).
После того как состав признаков описания объектов и соответствующие им характеристики полей продуманы, можно приступить к созданию таблицы в среде ACCESS.
В имеющихся версиях этой системы последовательность действий практически
одинакова. Отличия состоят лишь в некоторой разнице оформления диалоговых
окон.
Таблица 2.1 – Таблица для описания характеристик полей БД
Состав признаков
объектов БД
№ п/п Признак
Характеристики полей БД
Имя поля
Тип данных
Количество Точность
символов
124
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Создание таблицы с помощью Конструктора таблиц
Для создания таблицы с помощью Конструктора таблиц необходимо выполнить следующие действия:
•
включить компьютер и загрузить программное обеспечение Windows и
Access;
•
после загрузки Access в появившемся диалоговом окне дважды щелкнуть
кнопкой по меню Файл и выбрать команду Создать;
•
в появившемся диалоговом окне Создание активизировать переключатель
База данных, а затем щелкнуть мышью по кнопке ОК (рисунок 2.1);
Рисунок
2.1
–
Диалоговое окно Создание базы данных
•
в следующем появившемся диалоговом окне Файл новой базы данных
присвоить имя файлу, указав при этом имя директории (папки), где будет храниться
БД; щелкнуть мышью по кнопке Создать (рисунок 2.2).
125
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок
2.2
–
Диалоговое окно указания имени и места файла БД
В следующем появившемся диалоговом окне База данных активизировать закладку Таблица и выбрать команду Создать в режиме конструктора.
В появившемся диалоговом окне Конструктор таблиц создать структуру таблицы в соответствии с установленными составом и характеристиками полей.
Конструктор таблиц (рисунок 2.3) содержит четыре информационных блока:
• имя поля;
• тип данных;
• описание;
• свойства поля.
В блоке Свойства поля имеется два окна (закладки): Общие и Подстановка.
Свойства поля Общие заполняются обязательно. В окне Подстановка можно
задать список значений, который будет выводиться при вводе данных непосредственно в таблицу. Пользователь в этом случае должен будет щелкнуть мышью по
нужному значению. Такие поля называют полями со списком.
126
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 2.3 – Окно Конструктора таблиц
При задании имен полям таблицы необходимо руководствоваться следующими рекомендациями:
• имя поля не должно начинаться с пробела;
• в имени поля не должно быть знаков препинания, скобок, восклицательных
знаков;
• не допускается повторение имен в таблице;
• имена полей могут содержать до 255 символов. Имя следует задавать имя
минимальным числом символов (это необходимо для минимизации объема памяти и
времени поиска информации). Желательно, чтобы имя поля представляло аббревиатуру названия признака объекта, которое будет вводиться в ячейки поля.
Технология заполнения данных в строки информационных блоков Конструктора таблиц аналогична технологии работы с таблицами в текстовом редакторе
Word.
127
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Заполнение информационных блоков следует производить последовательно
для каждого поля. Рекомендуем следующий порядок заполнения информационных
блоков:
• ввести имя поля;
• выбрать тип данных;
• ввести в строку блока Описание комментарий, поясняющий характер вводимых значений в ячейку данного поля (в дальнейшем при заполнении таблицы этот
комментарий выводится в строку подсказки в нижней части экрана);
• задать свойства поля;
• повторить указанные действия для всех остальных полей таблицы.
После того как имя поля введено в соответствии с изложенными выше рекомендациями, выбираем для него тип данных. В Конструкторе таблиц Microsoft
Access выбор типа данных можно осуществить выбором из списка.
После установления имени и типа данных следует поместить курсор в соответствующую строку блока Описание и ввести комментарий, позволяющий пользователю правильно вводить информацию при заполнении таблицы.
Мы рекомендуем обязательно вводить комментарий, особенно для тех случаев, когда в обозначении имени или подписи поля содержится недостаточно информации для правильного ввода данных.
После ввода комментария необходимо перейти к блоку Свойства поля, разделу Общие и задать полю необходимые свойства. В Конструкторе таблиц каждому
ролю в зависимости от типа данных автоматически (по умолчанию) задается определенный набор свойств. Конструируя таблицу, эти свойства можно изменять в соответствии с конкретными требованиями к данным.
В таблице 2.2 перечислены характеристики свойств полей, задаваемые в информационном блоке Свойства поля, Общие.
128
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Таблица 2.2 – Характеристики свойств полей таблиц БД
Свойство поля
Характеристика
Размер поля
Устанавливает максимальный размер данных, вводимых в
ячейки данного поля.
Размер данных текстовых (символьных) полей не может
превышать 255 знаков.
Для числовых полей размер водимых данных устанавливается автоматически в зависимости от типа числа: байт – целые
числа от 0 до 255 – 1 байт;
целое – целые числа от -32 768 до +32 767 – 2 байт;
длинное – целые числа от -2 147483 648 до +2 147483 648;
целое с плавающей точкой с точностью до шести знаков –
числа от -3,4 х 1038 до +3,4 х 1038 – 4 байт;
целое с плавающей точкой с точностью до восьми знаков числа от -1,797 х 10 308 до +1,797 х 10 308 -8 байт
Формат поля
Для полей типа Текстовый и MEMO можно задавать формат
ввода данных, в соответствии с которым данные будут выводиться на экран дисплея.
Для полей типов Числовой, Денежный могут быть
выбраны следующие форматы:
стандартный – формат, устанавливаемый по умолчанию (отсутствуют разделители тысяч, знаки валют, число десятичных знаков соответствует точности числа);
денежный – устанавливается два знака после запятой и выводится символ валюты;
фиксированный – как минимум, один знак до запятой и два
знака после запятой;
с разделителями тысяч – два знака после запятой и разделитель тысяч;
процентный – в конце числа выводится знак процента;
экспоненциальный – числа выводятся в экспоненциальном
виде (например, 1.10 103).
Для полей логического типа могут применяться следующие
форматы: Да/Нет; Истина/Ложь; Вкл/Выкл
Число десятичЗадается для полей типов Числовой и Денежный. Число знаных знаков (точ- ков – от 0 до 15
ность поля)
Маска ввода
Маска устанавливает шаблон для ввода данных в поля типов
Текстовый, Числовой, Денежный, Дата/Время. Маска ввода
для полей типа Дата/Время соответствует выбранному формату
129
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Продолжение таблицы 2.2
Свойство поля
Характеристика
Подпись поля
Предназначена для более описательного названия поля, которое будет вводиться в заголовки («шапки») таблиц и другие элементы форм, отчетов. Если подпись поля не вводится,
то в соответствующих элементах таблиц, форм и отчетов будут вводится имена полей
Условие на знаУстанавливает ограничения на значения вводимых данных.
чение
Например, задание условия «<100» для числового поля означает, что в это поле нельзя вводить данные более 100.
Условие вида «Москва» OR «Вологда» OR «Новосибирск»
означает, что вводимые названия городов должны быть только Москва, или Вологда, или .Новосибирск.
Условия на значение вводимых данных задаются выражениями, состоящими из операторов сравнения, и значениями,
которые используются для сравнения. При задании условий
применяются известные операторы:
< (меньше);
<= (меньше или равно);
> (больше);
>= (больше или равно)
При задании условий применяются известные операторы:
= (равно);
< > (не равно).
В выражениях могут применяться логические операторы: OR
(или), AND (и), а также операторы сравнения: BETWEEN,
IN, LIKE:
BETWEEN – проверяет, что введенное значение поля находится внутри заданного диапазона. Верхняя и нижняя границы диапазона разделяются логическим оператором AND.
Например, выражение BETWEEN 20 AND 45 означает, что
вводимое значение должно находиться в интервале от 20 до
45. Это выражение также может быть записано в виде: >50
AND < 100; IN – проверяет равенство введенного значения
поля любому значению из заданного списка. Например, IN
(«Москва», «Вологда», «Новосибирск») означает, что это
выражение соответствует также выражению «Москва» OR
«Вологда» OR «Новосибирск»;
LIKE – проверяет соответствие полей Текстовый или Мемо
заданному шаблону символов.
Сообщение об
Текст, который будет выводиться на экран при несоответошибке
ствии заданным условиям значений вводимых данных
130
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Продолжение таблицы 2.2
Свойство поля
Характеристика
Обязательное по- Если поле выбрано обязательным, то это значит, что при зале
полнении таблицы в ячейки этого поля данные должны вводиться обязательно
Пустые строки
Разрешение на ввод пустых строк для полей Текстовый и
Мемо
Индексированное Рекомендуется устанавливать это значение для полей, по
поле
значениям которых предполагается осуществлять поиск данных в таблицах. Задание индекса значительно ускоряет поиск
данных
На рисунке 2.4 показан пример заполнения свойств полей таблицы.
Рисунок
2.4
-
Пример заполнения свойств полей таблицы
131
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
После описания характеристик (свойств) всех полей таблицы конструктор закрывают; при этом открываются диалоговые окна, в которых предлагается задать
имя таблицы и установить ключевые поля, если они не были заданы.
При задании имени таблицы необходимо учесть следующие рекомендации:
• имя поля должно отражать содержание данных в таблице (класс объектов);
• в имени таблицы не должно быть знаков препинания, скобок, восклицательных знаков;
• имя таблицы не должно начинаться с пробела;
• в одном файле БД не должно быть таблиц с одинаковыми именами.
Ключевые поля устанавливаются в тех случаях, когда данные таблицы БД
должны быть связаны с данными других таблиц. Ключевое поле должно однозначно
определять каждую запись в таблице. Значения данных ключевого поля не повторяются (не должны повторяться). Ключевым может быть любое поле таблицы, если
значения данных этого поля могут однозначно определить всю запись. Если запись
нельзя однозначно определить по значению данных одного поля, то устанавливают
несколько ключевых полей. В качестве ключевого поля можно выбрать поле типа
Счетчик, которое однозначно определяет каждую запись таблицы. Ключевое поле
создается при описании свойств полей в Конструкторе таблиц. Для этого необходимо выделить необходимое поле и на панели инструментов щелкнуть по соответствующей кнопке.
Сделаем несколько замечаний по технологии разработки таблиц. Технология
работы в Конструкторе таблиц полностью аналогична работе с таблицами в текстовом редакторе Word.
При создании нескольких таблиц, содержащих одинаковые характеристики
объектов, следует применять технологию копирования данных. Для этого необходимо:
1) открыть созданную ранее таблицу в режиме Конструктор;
2) выделить поле, которое повторяется в другой таблице;
3) скопировать выделенное поле (со всеми его свойствами) в буфер обмена;
132
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
4) при конструировании другой таблицы вставить из буфера обмена характеристики поля в соответствующую строку Конструктора таблиц.
После того как структуры таблиц БД созданы, необходимо установить логические связи между таблицами.
Установление связей между таблицами
Установление связей между таблицами необходимо для обеспечения целостности данных. Целостность данных гарантирует защиту информации от случайных
изменений в связанных таблицах. В связанных таблицах одна таблица является
главной, а вторая – подчиненной. Главная таблица должна обязательно содержать
ключевое поле. Подчиненная таблица должна содержать аналогичное поле, которое
не является ключевым.
Для установления связей между таблицами необходимо выполнить следующие действия.
• на панели инструментов окна базы данных активизировать команду (значок)
Схема данных;
• в открывшееся окно построителя схемы данных ввести главную и подчиненные таблицы (рисунок 2.5);
• связать таблицы по одинаковому полю (рисунок 2.6) .
В процессе создания связи включен параметр Обеспечение целостности данных. При этом параметре не допускается произвольное удаление или изменение записей в главной таблице. Если установить (включить) параметры связи между таблицами Каскадное обновление связанных полей и Каскадное удаление связанных записей, то при любых изменениях данных в главной таблице произойдет автоматическое изменение связанных данных в подчиненной таблице.
133
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 2.5 – Окно построителя схемы данных
Рисунок 2.6 – Пример установления связи «один ко многим»
На рисунке 2.7 показан пример схемы связи базы данных «Учебный процесс».
134
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок
2.7
–
Схема связи базы данных «Учебный процесс»
После того как состав таблиц базы данных установлен, структура каждой таблицы разработана, определены и установлены связи между таблицами, приступают
к заполнению таблиц данными.
Технология ввода данных в таблицы производится двумя способами:
• непосредственным вводом данных в ячейки таблицы;
• организацией ввода данных через формы.
При выборе первого способа ввода данных необходимо руководствоваться:
• уменьшением вероятности ошибок оператора;
• удобством организации самого процесса ввода данных.
Если таблица базы данных имеет небольшое число полей, которые размещаются на экране монитора, и не связана с другими таблицами, а также если вы создаете некоммерческую систему, то для ввода данных можно не создавать соответствующей формы.
135
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
В остальных случаях рекомендуется разработка формы для ввода данных в
таблицы.
Вопросы для самоконтроля
1. Из каких информационных блоков состоит Конструктор таблиц и в какой последовательности их следует заполнять?
2. Из скольких символов может состоять имя поля?
3. Может ли имя поля начинаться с пробелов?
4. Какие символы не допускаются при обозначении имени поля?
5. В чем состоит отличие текстового типа данных от MEMO?
6. В чем состоит отличие числового типа данных от денежного?
7. В каких случаях следует применять тип данных OLE?
8. В каких случаях следует применять тип данных Гиперссылка?
9. В каких случаях полю присваивают свойство Ключевое поле?
10.Может ли ключевое поле иметь повторяющиеся значения данных в таблице БД?
11.В каких случаях полю присваивают свойство Обязательное?
12.Какие таблицы называются главными, а какие – подчиненными?
13.Какой смысл имеет термин «Обеспечение целостности данных»?
136
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
3 Манипулирование данными
3.1 Структурированный язык запросов SQL
Структурированный язык запросов (Structured Query Language -SQL) разработан в НИЦ JBM в г.Сан-Хосе в середине 70-х годов. Аббревиатура произносится «сикуэл». Рекомендован американским институтом стандартов (ANSI) как стандартный язык манипулирования РБД.
Выполняет функции:
- языка управления данными (DML);
- языка определения данных (DDL);
- языка доступа к данным (DSL);
- стандартных команд управления;
- выполнения условий ограничений и триггеров.
Рассмотрим синтаксис инструкции SELECT как ядра языка SQL. Инструкция
используется для отбора строк и столбцов из таблиц БД и содержит пять основных
предложений:
SELECT <список полей>
FROM <список таблиц>
[WHERE <спецификация выбора строк>]
[GROUP BY <спецификация группировки>]
[HAVING <спецификация выбора групп>]
[ORDER BY <спецификация сортировки>]
SELECT – выбрать данные из указанных столбцов и (если необходимо) выполнить перед выводом их преобразование в соответствии с указанными выражениями и (или) функциями;
FROM - из перечисленных таблиц, в которых расположены столбцы;
WHERE - где строки из указанных таблиц должны удовлетворять указанному
перечню условий отбора строк;
137
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
GROUP BY – группируя по указанному перечню столбцов с тем, чтобы получить для каждой группы единственное агрегированное значение, используя во фразе
SELECT функции:
SUM – сумма;
COUNT – количество;
MIN – минимальное значение;
MAX – максимальное значение;
AVG – среднее значение;
HAVING - имея в результате лишь те группы, которые удовлетворяют указанному перечню условий отбора групп;
ORDER BY – вид сортировки, задает порядок расположения строк.
Рассмотрим примеры использования инструкции SELECT применительно к
таблице СТУДЕНТ.
СТУДЕНТ
Номер
100
Фамилия
Иванов
Специальность
ПОВТАС
Курс
4
150
Петров
ПОВТАС
3
200
Сидоров
История
2
Составим простую инструкцию на выборку первых трех атрибутов таблицы и
получим результат запроса:
SELECT Номер, Фамилия, Специальность
FROM СТУДЕНТ
Номер
100
Фамилия
Иванов
Специальность
ПОВТАС
150
Петров
ПОВТАС
200
Сидоров
История
Для изучения языка запросов и проверки результатов целесообразно использовать СУБД SQL Server. В среде Microsoft SQL Server Management Studio (рисунок
3.1) создадим таблицу СТУДЕНТ, заполним гипотетическими данными, перейдем в
138
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
режим разработки представлений. В диалоговом окне представления выделено четыре сегмента. В первом верхнем сегменте помещена таблица СТУДЕНТ. С помощью переключателей пометим «птичкой» необходимые поля таблицы. Во втором
сегменте визуально определим условия отбора данных. В третьем сегменте можно
прочитать листинг SQL – запроса. В четвертом нижнем сегменте представляются
результаты запроса. Используйте это окно представлений для визуального конструирования различных вариантов запроса и проверки написания листинга на языке
запросов SQL.
Рисунок 3.1 – Диалоговое окно представлений
Вызовем в запросе поле Специальность:
SELECT Специальность
FROM СТУДЕНТ
Специальность
ПОВТАС
ПОВТАС
История
139
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Сконструируем запрос списка специальностей без повторений с помощью дополнительного оператора DISTINCT:
SELECT DISTINCT Специальность
FROM СТУДЕНТ
Специальность
ПОВТАС
История
Результат проверки запроса показан на рисунке 3.2.
Рисунок 3.2 – Результат запроса списка специальностей
140
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Изунесколько
Номер
100
Фамилия
Иванов
Специальность
ПОВТАС
Курс
4
ных
150
Петров
ПОВТАС
3
при-
пользова-
чим
еще
конкретмеров исния
ин-
струкции запросов на выборку данных.
Выберем список студентов, обучающихся по специальности ПОВТАС:
SELECT *
FROM СТУДЕНТ
WHERE Специальность = ‘ПОВТАС’
Проверим выполнение запроса в СУБД SQL Server (рисунок 3.3).
Рисунок 3.3 – запрос на выборку студентов, обучающихся по специальности
ПОВТАС
В предложении WHERE можно указать несколько условий:
SELECT Фамилия. Курс
141
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
FROM СТУДЕНТ
WHERE Специальность = ‘ПОВТАС’ AND Курс = ‘4’
Проверим выполнение условий по рисунку 3.4.
Рисунок 3.4 – Запрос на несколько условий
В предложении WHERE можно указать множество значений:
SELECT Фамилия.
FROM СТУДЕНТ
WHERE Специальность IN [‘ПОВТАС’ ]
Фамилия
Иванов
Петров
SELECT Фамилия
FROM СТУДЕНТ
WHERE Специальность NOT IN [‘ПОВТАС’ ]
Фамилия
Сидоров
142
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
В предложении WHERE можно указать диапазоны и шаблоны. Диапазоны задаются с помощью оператора BETWEEN.
Оператор LIKE используется в SQL- выражениях для выборки по шаблону:
SELECT Фамилия, Специальность
FROM СТУДЕНТ
WHERE Номер BETWEEN 150 AND 200
Фамилия
Петров
Специальность
ПОВТАС
Сидоров
История
Эквивалентное выражение:
SELECT Фамилия, Специальность
FROM СТУДЕНТ
WHERE Номер >= 150 AND Номер <=200
Оператор LIKE используется в SQL - выражениях для выборки по шаблону. В
шаблоне можно использовать символ ‘?’ как одиночный произвольный символ и
символ ‘*’ последовательность из одного или более произвольных символов:
SELECT Фамилия
FROM СТУДЕНТ
WHERE Курс LIKE ‘4’
Фамилия
Иванов
SELECT Фамилия
FROM СТУДЕНТ
WHERE Фамилия LIKE ‘С*’
Фамилия
Сидоров
143
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Для поиска пустых (или отсутствующих ) значений используется оператор IS
NULL.
Рассмотрим примеры сортировки в SQL. Строки результирующего отношения
могут быть отсортированы по значениям одного или нескольких столбцов с помощью оператора ORDER BY:
SELECT Фамилия, Специальность, Курс
FROM СТУДЕНТ
WHERE Специальность = ‘ПОВТАС’
ORDER BY Фамилия
Фамилия
Специальность
Курс
Иванов
ПОВТАС
4
Петров
ПОВТАС
3
Сидоров
История
2
Строки результирующего отношения могут быть отсортированы по возрастанию ( оператор ASC ) или по убыванию (оператор DESC):
SELECT Фамилия. Специальность. Курс
FROM СТУДЕНТ
WHERE Специальность = ‘ПОВТАС’
ORDER BY Курс DESC
Фамилия
Специальность
Курс
Иванов
ПОВТАС
4
Петров
ПОВТАС
3
Сидоров
История
2
Рассмотрим примеры использования встроенных функций в SQL. Предусмотрено пять встроенных функций (built-in functions): COUNT, SUM, AVG, MAX и
MIN.
Функции COUNT и SUM различны, хотя обе они выполняют подсчет.
144
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Функция COUNT вычисляет количество строк в таблице, функция SUM подсчитывает сумму числовых столбцов.
Функции AVG, МАХ и MIN также работают с числовыми столбцами. Функция AVG вычисляет среднее значение, а МАХ и MIN находят соответственно максимальное и минимальное значение столбца в таблице.
SELECT COUNT (*)
FROM СТУДЕНТ
подсчитывает количество
строк в таблице СТУДЕНТ:
3
SELECT COUNT ( Специальность)
FROM СТУДЕНТ
3
SELECT COUNT ( DISTINCT Специальность)
FROM СТУДЕНТ
2
Рассмотрим примеры использования встроенных функций с группировкой.
Встроенные функции можно применять к группам строк внутри таблицы:
SELECT Имя, COUNT (*)
FROM СТУДЕНТ
GROUP BY Специальность
ПОВТАС
2
История
1
В некоторых случаях возникает потребность рассматривать не все группы.
Например, мы сформировали группы студентов, имеющих одинаковую специальность, и теперь хотим рассматривать только те из них, количество студентов в которых больше двух. Чтобы указать нужное нам подмножество групп, мы можем воспользоваться SQL-предложением HAVING:
145
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
SELECT Имя, COUNT (*)
FROM СТУДЕНТ
GROUP BY Специальность
HAVING COUNT (*) > = 2
ПОВТАС
2
Рассмотрим правила объединения запросов в SQL. Для размещения нескольких простых запросов вместе и объединения их вывода используют предложение
UNION. Предложение UNION объединяет вывод двух и более SQL запросов в единый набор строк и столбцов. Введем дополнительную таблицу ПРЕПОДАВАТЕЛЬ.
ПРЕПОДАВАТЕЛЬ
Номер
Фамилия
ДИСЦИПЛИНА
10
Федоров
Базы данных
15
Пятин
Математика
20
Михайлов
История
SELECT Фамилия
FROM СТУДЕНТ
WHERE Фамилия BETWEEN ‘ K ’ AND ‘ C ’
UNION
SELECT Фамилия
FROM ПРЕПОДАВАТЕЛЬ
WHERE Фамилия BETWEEN ‘ K ’ AND ‘ C ’ ;
Проанализируйте результат запроса:
Михайлов
Петров
Пятин
Сидоров
Возможна вставка комментариев и указание порядка вывода строк:
SELECT ‘Студент
’ Фамилия
FROM СТУДЕНТ
UNION
SELECT ‘Преподаватель’ Фамилия
FROM ПРЕПОДАВАТЕЛЬ
146
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ORDER BY 2 ASC;
Цифра 2 указывает на столбец, который будет упорядочен.
Результат запроса:
Студент
Иванов
Преподаватель
Михайлов
Студент
Петров
Преподаватель
Пятин
Студент
Сидоров
Преподаватель
Федоров
Запрос нескольких таблиц
Для иллюстрации примеров запросов будут использоваться таблицы СТУДЕНТ, ЗАНЯТИЯ и ЗАПИСЬ (рисунок 3.5).
Личный
номер
Имя
Специальность
Курс
100
150
200
250
300
350
400
450
ДЖОНС
ПАРКС
БЕЙКЕР
ГЛАСС
БЕЙКЕР
РАССЕЛ
РАЙ
ДЖОНС
ИСТОРИЯ
БУХГАЛТЕРСКИЙ УЧЕТ
МАТЕМАТИКА
ИСТОРИЯ
БУХГАЛТЕРСКИЙ УЧЕТ
МАТЕМАТИКА
БУХГАЛТЕРСКИЙ УЧЕТ
ИСТОРИЯ
а
АС
С2
АС
С4
С4
С3
С1
С4
Номер
Студента
Название
Предмета
Порядковый
номер
100
150
200
200
300
400
400
400
450
BD445
BA200
BD445
CS250
CS150
BA200
BF410
CS250
BA200
б
1
1
2
1
1
2
1
2
3
147
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Название
Предмета
Время
Аудитория
ВА200
BD445
BF410
CS150
CS250
П-Я9
ПСЯ3
ПСЯ8
ПСЯ3
ПСЯ1
SC110
SC213
SC213
EA304
EB210
в
Рисунок 3.5 - Данные для примера применения SQL:
а – отношение СТУДЕНТ;
б – отношение ЗАПИСЬ; в – отношение ЗАНЯТИЯ
Вложенные запросы
Предположим, мы хотим знать имена студентов, записанных на предмет под
шифром BD445. Если нам известно, что на этот предмет записаны студенты с номерами 100 и 200, то правильные результаты выдаст следующий запрос:
SELECT Имя
FROM СТУДЕНТ
WHERE ЛичныйНомер IN [100. 200]
Обычно мы не знаем номеров студентов, записанных на какой-то предмет, но
у нас есть возможность их определить.
Рассмотрим выражение:
SELECT НомерСтудента
FROM ЗАПИСЬ
WHERE НазваниеПредмета = 'BD445'
Результатом операции будет таблица:
100
200
Комбинируя последние два запроса, мы получаем следующее:
SELECT Имя
FROM СТУДЕНТ
WHERE ЛичныйНомер IN
148
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
(SELECT НомерСтудента
FROM ЗАПИСЬ
WHERE НазваниеПредмета = 'BD445')
Второе предложение SELECT, которое называется вложенным запросом
(subquery), заключено в круглые скобки.
Эти выражения оказывается проще понять, если читать их снизу вверх. Последние три оператора выдают номера студентов, записанных на предмет BD445, а
первые три оператора выдают имена выбранных студентов. Результат запроса таков:
ДЖОНС
БЕЙКЕР
Чтобы
данная
операция
была
семантически
корректной,
СТУ-
ДЕНТ.ЛичныйНомер и ЗАПИСЬ.НомерСтудента должны иметь один и тот же домен.
Вложенные запросы могут состоять из трех или даже большего количества
таблиц. Предположим, например, что мы хотим узнать имена студентов, в расписании у которых стоят занятия по понедельникам, средам и пятницам с 3 часов (они
обозначены в наших данных как 'ПСЯЗ'). Прежде всего, нам нужны названия предметов, занятия по которым начинаются в это время:
SELECT ЗАНЯТИЯ. Название Предмета
FROM ЗАНЯТИЯ
WHERE Время = 'ПСЯЗ'
Поскольку мы имеем дело с тремя различными таблицами, мы указываем
имена столбцов вместе с именами таблиц, чтобы избежать недоразумений и неоднозначности. Так, ЗАНЯТИЯ. Название Предмета обозначает столбец Название
Предмета в отношении ЗАНЯТИЯ.
Далее мы определяем личные номера студентов, записанных на эти предметы,
с помощью следующего выражения:
SELECT ЗАПИСЬ.НомерСтудента
FROM ЗАПИСЬ
149
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
WHERE ЗАПИСЬ.НазваниеПредмета IN
(SELECT ЗАНЯТИЯ,НазваниеПредмета
FROM ЗАНЯТИЯ
WHERE Время = 'ПСЯЗ')
Это даст результат:
100
200
300
Чтобы получить имена этих студентов, мы используем следующее выражение:
SELECT СТУДЕНТ.Имя
FROM СТУДЕНТ
WHERE СТУДЕНТ.ЛичныйНомер IN
SELECT ЗАПИСЬ.НомерСтудента
FROM ЗАПИСЬ
WHERE ЗАПИСЬ.НазваниеПредмета IN
(SELECT ЗАНЯТИЯ.НазваниеПредмета
FROM ЗАНЯТИЯ
WHERE ЗАНЯТИЯ.Врем я = 'ПСЯЗ')
Результатом будет:
ДЖОНС
БЕЙКЕР
БЕЙКЕР
Эта стратегия работает хорошо, пока атрибуты, входящие в ответ, происходят
из одной и той же таблицы. Если же результат содержит информацию из двух или
более таблиц, перед нами встает проблема.
Предположим, к примеру, что мы хотим узнать имена студентов и названия
предметов, на которые они записаны. То есть нам нужны атрибуты ЛичныйНомер,
ИмяСтудента и НазваниеПредмета.
В этом случае результаты происходят из двух различных таблиц (СТУДЕНТ и
ЗАПИСЬ), и стратегия вложенных запросов не работает.
150
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Соединение с помощью SQL
Чтобы получить атрибуты ЛичныйНомер, Имя и НазваниеПредмета для каждого студента, мы должны соединить таблицу СТУДЕНТ с таблицей ЗАПИСЬ. Это
делается следующими операторами:
SELECT СТУДЕНТ.ЛичныйНомер, СТУДЕНТ.Имя, ЗАПИСЬ. Название
Предмета
FROM СТУДЕНТ. ЗАПИСЬ
WHERE СТУДЕНТ.ЛичныйНомер = ЗАПИСЬ.НомерСтудента
Вспомните, что соединение — это комбинация трех операций: умножения, затем выборки и наконец (обычно) — проекции. В этом выражении оператор FROM
производит перемножение отношений СТУДЕНТ и ЗАПИСЬ, а оператор WHERE
производит выборку. Значение выражения звучит так: «Выбрать из произведения
отношений СТУДЕНТ и ЗАПИСЬ те строки, в которых значение атрибута ЛичныйНомер из отношения СТУДЕНТ равно значению атрибута НомерСтудента в отношении ЗАПИСЬ». Наконец, после выборки берется проекция на номер студента,
имя и название предмета.
Результат имеет следующий вид:
100
150
200
200
300
400
400
400
450
ДЖОНС
ПАРКС
БЕЙКЕР
БЕЙКЕР
БЕЙКЕР
РАЙ
РАЙ
РАЙ
ДЖОНС
BD455
BA200
BD445
CS250
CS150
BA200
BF410
CS250
BA200
Предложение WHERE может содержать и другие квалификаторы помимо тех,
которые непосредственно требуются для соединения. Например,
SELECT СТУДЕНТ.Личный номер, Запись. Название Предмета
FROM СТУДЕНТ. ЗАПИСЬ.
WHERE СТУДЕНТ.ЛичныйНомер = ЗАПИСЬ.Номер Студента
AND СТУДЕНТ . Имя = 'РАЙ'
AND ЗАПИСЬ. Порядковый номер = 1
151
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Здесь дополнительные квалификаторы – это условия СТУДЕНТ. Имя = «РАЙ»
и ЗАПИСЬ. Порядковый номер = 1. Это выражение будет иметь своим результатом
список учетных номеров всех студентов по имени РАЙ, кто записался первым на
какой-либо предмет, и список соответствующих предметов.
400
BF410
Когда требуются данные более чем из двух таблиц, мы можем использовать
аналогичную стратегию. В следующем примере соединяются три таблицы.
SELECT СТУДЕНТ.Личный номер, ЗАНЯТИЯ. Название Предмета, ЗАНЯТИЯ. Время.
ЗАПИСЬ. Порядковый Номер
FROM СТУДЕНТ. ЗАПИСЬ. ПРЕДМЕТ
WHERE СТУДЕНТ. ЛичныйНомер = ЗАПИСЬ.Номер Студента
AND ЗАПИСЬ.НазваниеПредмета = ЗАНЯТИЯ. НазваниеПредмета
AND СТУДЕНТ.Имя = 'БЕЙКЕР'
Результатом этой операции будет:
200
200
300
BD445
CS250
CS150
ПСЯ3
ПСЯ12
ПСЯ3
2
1
1
Сравнение вложенного запроса и соединения
Соединение может использоваться в качестве альтернативы множеству вложенных запросов. Например, мы использовали вложенный запрос для нахождение
студентов, записанных на предмет BD445. Для представления этого запроса мы
также можем использовать соединение:
SELECT СТУДЕНТ.Имя
FROM СТУДЕНТ. ЗАПИСЬ
WHERE СТУДЕНТ.ЛичныйНомер = ЗАПИСЬ.НомерСтудента
AND ЗАПИСЬ.НазваниеПредмета = 'BD445'
152
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Подобным же образом вопрос «Каковы имена студентов, занимающихся и понедельникам, средам и пятницам в 3 часа?» может быть представлен в виде запроса:
SELECT СТУДЕНТ.Имя
FROM СТУДЕНТ. ЗАПИСЬ. ЗАНЯТИЯ
WHERE СТУДЕНТ.ЛичныйНомер = ЗАПИСЬ.НомерСтудента
AND ЗАПИСЬ.НазваниеПредмета = ЗАНЯТИЯ.НазваниеПредмета
AND ЗАНЯТИЯ.Время = 'ПСЯЗ'
Хотя выражения с соединением во многих случаях могут составить альтернативу вложенным запросам, они не способны заменить их в любой ситуации. Вложенные запросы со служебными словами EXISTS и NOT EXISTS нельзя представить с помощью соединений.
Не все соединения можно заменить вложенным запросом. Когда используется
соединение, отображаемые столбцы могут относиться к любой из соединяемых таблиц, а вложенный запрос способен отобразить столбцы только той таблицы которая
указана в выражении FROM первого оператора SELECT. Предположим, пример, что
мы хотим определить названия курсов, на которые записаны студенты. Мы можем
выразить это в виде вложенного запроса:
SELECT DISTINCT НазваниеПредмета
FROM ЗАПИСЬ
WHERE НомерСтудента IN
(SELECT ЛичныйНомер
FROM СТУДЕНТ
WHERE Курс NOT = 'AC')
или в виде соединения:
SELECT DISTINCT НазваниеПредмета
FROM ЗАПИСЬ. СТУДЕНТ
WHERE ЗАПИСЬ.НомерСтудента = СТУДЕНТ.ЛичныйНомер
AND Курс NOT = 'AC'
Но если мы хотим знать и названия предметов, и номера курсов, на которых
учатся студенты, мы должны использовать соединение. Вложенный запрос не подойдет, поскольку требуемые результаты происходят из разных таблиц, а именно
153
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
названия предметов хранятся в таблице ЗАПИСЬ, а имена студентов — в таблице
СТУДЕНТ. Правильный ответ выдаст следующий запрос:
SELECT DISTINCT ЗАПИСЬ.НазваниеПредмета. СТУДЕНТ.Курс
FROM ЗАПИСЬ. СТУДЕНТ
WHERE ЗАПИСЬ.НомерСтудента = СТУДЕНТ.ЛичныйНомер
AND СТУДЕНТ.Курс NOT = 'AC'
Результат имеет следующий вид:
BA200
CS150
BA200
BF410
CS250
BA200
C2
C4
C1
C1
C1
C4
Внешнее соединение
Стандарт ANSI SQL не поддерживает операцию внешнего соединения. Однако эта операция поддерживается многими СУБД. Здесь мы продемонстрируем использование одной из них.
Предположим, нам нужен список студентов и названия предметов, на которые
они записаны.
Допустим, кроме того, что мы хотим получить сведения обо всех студентах,
включая даже тех, кто не записан ни на один из предметов.
В Microsoft Access этот результат можно получить с помощью следующего
выражения:
SELECT Имя. НазваниеПредмета
FROM СТУДЕНТ LEFT JOIN ЗАПИСЬ
ON ЛичныйНомер = НомерСтудента;
Результатом будет:
154
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ДЖОНС
ПАРКС
БЕЙКЕР
БЕЙКЕР
ГЛАСС
БЕЙКЕР
РАССЕЛ
РАЙ
РАЙ
РАЙ
ДЖОНС
BD445
BA200
BD445
CS250
Null
CS150
Null
BA200
BF410
CS250
ВА200
Обратите внимание на различия между Access SQL и записью, принятой в
стандарте ANSI. Условия соединения задаются с помощью ключевого слова ON.
Кроме того, все выражения SQL заканчиваются точкой с запятой.
Операторы EXISTS и NOT EXISTS
EXISTS и NOT EXISTS («существует» и «не существует») — логические операторы, принимающие значение «истина» или «ложь», в зависимости от наличия
или отсутствия строк, удовлетворяющих заданным условиям. Пусть, например, мы
хотим узнать номера студентов, записанных более чем на один предмет:
SELECT DISTINCT НомерСтудента
FROM ЗАПИСЬ А
WHERE EXISTS
(SELECT*
FROM ЗАПИСЬ В
WHERE А.НомерСтудента = В.НомерСтудента
AND А.НазваниеПредмета NOT = В.НазваниеПредмета)
В этом примере как основной, так и вложенный запросы относятся к таблице
ЗАПИСЬ. Во избежание неоднозначности этим двум вариантам использования таблицы ЗАПИСЬ присвоены различные имена. В первом операторе FROM таблице
ЗАПИСЬ присвоено временное произвольное имя А, а во втором операторе FROM
— другое временное произвольное имя В.
155
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Выражение во вложенном запросе означает следующее: следует найти две
строки в таблице ЗАПИСЬ, имеющие один и тот же помер студента, но различные
названия предметов. (Это означает, что студент записан более чем на один предмет.)
Если такие две строки существуют, то оператор EXISTS будет иметь логическое
значение «истина»; в этом случае номер данного студента будет присутствовать в
ответе. В противном случае оператор EXISTS будет иметь логическое значение
«ложь», и номер данного студента в результате фигурировать не будет.
Можно рассматривать этот запрос и по-другому: представим себе две отдельные и идентичные копии таблицы ЗАПИСЬ. Назовем одну из копии А, а другую В.
Будем сравнивать каждую строку А с каждой строкой В. Сначала рассмотрим
первую строку А и первую строку В. Поскольку эти две строки идентичны, то и номер студента, и название предмета в них совпадают, поэтому атрибут НомерСтудента из данной строки не попадет в ответ.
Теперь рассмотрим первую строку А и вторую строку В. Если номер студента
один и тот же, а названия предметов различаются, данный номер студента будет
отображен в результатах. В сущности, мы сравниваем первую строку таблицы ЗАПИСЬ со второй строкой этой же таблицы. В представленных данных ни номер студента, ни название предмета не совпадают.
Далее мы продолжаем сравнивать первую строку А с каждой строкой В. Если
выполняются заданные нами условия, мы выводим номер студента. Когда будут
пройдены все строки таблицы В, мы перейдем ко второй строке таблицы А и будем
сравнивать ее с каждой строкой таблицы В.
Результатом этого запроса будет:
200
400
Чтобы продемонстрировать использование ключевого слова NOT EXISTS,
предположим, что мы хотим узнать имена студентов, которые записаны на все предметы. По-другому это можно выразить так: нам нужны имена таких студентов, для
156
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
которых не существует предметов, на которые они не были бы записаны. Это делается с помощью следующего запроса:
SELECT СТУДЕНТ.Имя
FROM СТУДЕНТ
WHERE NOT EXISTS
(SELECT*
FROM ЗАПИСЬ
WHERE NOT EXISTS
(SELECT*
FROM ЗАНЯТИЯ
WHERE ЗАНЯТИЯ.НазваниеПредмета = ЗАПИСЬ.НазваниеПредмета
AND ЗАПИСЬ.НомерСтудента = СТУДЕНТ.ЛичныйНомер))
Этот запрос состоит из трех частей. В нижней части ведется поиск предметов,
на которые записан студент. Средняя часть определяет, есть ли такие предметы, на
которые студент не записан. Если нет, то студент записан на все предметы, и его
имя отображается в результатах.
Этот запрос может оказаться сложным для понимания. Для этих данных ответ
состоит в том, что нет ни одного студента, который был бы записан на все предметы. Вы можете попытаться изменить данные таким образом, чтобы какой-либо студент был записан на все предметы. Еще один способ уяснить себе суть этого запроса
— попробовать представить его в другом виде без применения ключевого слова
NOT EXISTS. Проблемы, с которыми вы при этом столкнетесь, помогут вам понять,
почему оператор NOT EXISTS необходим.
Изменение данных
В SQL предусмотрены средства для изменения данных в таблицах путем вставок новых строк, удаления строк и модификации значений в существующих строка.
SQL позволяет также менять структуру данных.
Вставка данных
Строки можно вставлять в таблицы по одной или группами. Чтобы вставить
од: строку, мы пишем следующее:
157
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
INSERT INTO ЗАПИСЬ
VALUES (400. 'BD445'. 44)
После ключевого слова INSERT INTO указывается имя таблицы, а после ключевого слова VALUES — вставляемые значения.
Если мы знаем не все данные (например, нам неизвестно значение атрибута
Позиция), можно поступить следующим образом:
INSERT INTO ЗАПИСЬ
(НомерСтудента, НазваниеПредмета)
VALUES (400, 'BD445'. 44)
Атрибут ПорядковыйНомер может быть добавлен позже. Обратите внимание
на то, что в результате этого запроса поле Позиция в новой строке будет иметь нулевое значение. Можно также копировать группы строк из одной таблицы в другую.
Пусть, например, нам нужно заполнить таблицу ТРЕТЬЕКУРСНИК.
INSERT INTO ТРЕТЬЕКУРСНИК
VALUES
(SELECT ЛичныйНомер. Имя. Специальность
FROM СТУДЕНТ
WHERE Курс = 'СЗ')
Вложенный оператор SELECT, как и все выражения SELECT, описанные в
предыдущих двух разделах, позволяет указывать строки для копирования. Это свойство предоставляет весьма широкие возможности.
Удаление данных
Как и в случае вставки, строки можно удалять по одной или группами. Следующий пример удаляет строку с данными о студенте 100:
DELETE FROM СТУДЕНТ
WHERE СТУДЕНТ.ЛичныйНомер = 100
158
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Обратите внимание, что если студент 100 записан на какие-либо предметы,
это удаление вызовет нарушение целостности, поскольку для строк таблицы ЗАПИСЬ, в которых НомерСтудента = 100, не будет соответствующей строки в таблице СТУДЕНТ.
Каким образом можно удалить группу строк, показывают следующие два
примера. В них из таблицы ЗАПИСЬ удаляется информация о предметах, на которые записаны студенты, специализирующиеся на бухгалтерском учете, а из таблицы
СТУДЕНТ удаляются данные обо всех таких студентах:
DELETE FROM ЗАПИСЬ
WHERE ЗАПИСЬ.НомерСтудента IN
(SELECT СТУДЕНТ.ЛичныйНомер
FROM СТУДЕНТ
WHERE СТУДЕНТ.Специальность = 'Бухгалтерский учет')
DELETE FROM СТУДЕНТ
WHERE СТУДЕНТ.Специальность = 'Бухгалтерский учет'
Порядок выполнения этих операций имеет значение: если бы он был обратным, ни одна строка из таблицы ЗАПИСЬ не была бы удалена, потому что соответствующие строки из таблицы СТУДЕНТ оказались бы уже удаленными.
Модификация данных
Строки можно также модифицировать — по одной или группами. Для изменения значения столбца предназначены ключевые слова UPDATE и SET. После SET
указывается имя столбца, значение в котором требуется изменить, а затем новое
значение либо способ его вычисления. Рассмотрим два примера:
UPDATE ЗАПИСЬ
SET ПорядковыйНомер = 44
WHERE НомерСтудента = 400
и
UPDATE ЗАПИСЬ
SET ПорядковыйНомер = МАХ(ПорядковыйНомер) + 1
WHERE НомерСтудента = 400
159
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Во втором операторе UPDATE значение столбца вычисляется с помощью
встроенной функции МАХ. Некоторые реализации SQL, однако, могут не допускать
использования встроенных функций в качестве аргумента команды SET.
Для демонстрации массовых обновлений предположим, что название предмета поменялось с BD445 на BD564. В этом случае, чтобы предотвратить проблемы с
целостностью, должны быть изменены как таблица ЗАПИСЬ, так и таблица ПРЕДМЕТ.
UPDATE ЗАПИСЬ
SET НазваниеПредмета = 'BD564'
WHERE НазваниеПредмета = 'BD445'
UPDATE ЗАНЯТИЯ
SET НазваниеПредмета = 'BD564'
WHERE НазваниеПредмета = 'BD445'
Помните, что массовые обновления могут представлять большую опасность.
Пользователю дается огромная власть, которая при правильном се использовании
позволяет быстро выполнить насущную задачу, а если ею распорядиться неверно,
может привести к серьезным проблемам.
Заключение
SQL — это наиболее важный на сегодняшний день язык манипулирования реляционными данными. Он превратился в стандартный язык для обмена информацией между компьютерами, и популярность его продолжает расти.
Операторы SOL, действующие на отдельную таблицу, — это операторы SELECT, SELECT с предложением WHERE, SELECT с предложением GROUP BY и
SELECT с предложениями GROUP BY и HAVING.
В SQL также имеются встроенные функции COUNT, SUM, AVG, МАХ и MIN.
Операции с двумя и более таблицами выполняются с помощью вложенных запросов, соединений и операторов EXISTS и NOT EXISTS.
Вложенные запросы и соединения часто выполняют одни и те же операции, но
не являются полностью взаимозаменяемыми. Для вложенных запросов требуется,
160
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
чтобы запрашиваемые атрибуты происходили из одной и той же таблицы, а в случае
соединений это не обязательно.
С другой стороны, существуют типы запросов, которые можно реализовать с
помощью вложенных запросов и операторов EXISTS и NOT EXISTS, но невозможно с помощью соединений.
Операторы SQL для модификации данных включают команды INSERT, DELETE и UPDATE, которые предназначены соответственно для вставки, удаления и
изменения значений данных.
Вопросы для самоконтроля
1. Объясните синтаксис основной инструкции SELECT языка SQL.
2. Порядок выборки в SQL.
3. Правила сортировки и группировки данных.
4. Использование встроенных функций в SQL.
5. Порядок использования вложенных запросов.
6. Правила соединения с помощью SQL.
7. Порядок сравнения вложенного запроса и соединения.
8. Порядок внешнего соединения.
9. Предназначение и использование операторов EXISTS и NOT EXISTS.
10. Порядок вставки, удаления и модификации данных.
161
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
3.2 Манипулирование данными на основе реляционной алгебры
Основная идея реляционной алгебры состоит в том, что коль скоро отношения
являются множествами, средства манипулирования отношениями могут базироваться на традиционных теоретико-множественных операциях, дополненных некоторыми специальными операциями, специфичными для реляционных баз данных.
Существует много подходов к определению реляционной алгебры, которые
различаются наборами операций и способами их интерпретации, но, в этой лекции
мы опишем начальный вариант алгебры, который был предложен Коддом (будем
называть ее «алгеброй Кодда».
Обзор реляционной алгебры Кодда
В конце 60-х годов прошлого столетия появились работы, в которых обсуждались возможности моделирования данных в базах данных, т.е. возможности использования привычных и естественных способов представления данных. Наиболее значительной из них была статья сотрудника фирмы IBM Эдгара Кодда (Codd E.F., A
Relational Model of Data for Large Shared Data Banks. CACM 13: 6, June 1970), где
был применен термин "реляционная модель данных".
Основоположник реляционных баз данных Э.Кодд предложил использовать
для обработки данных аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Он показал, что любое представление данных сводится к совокупности двумерных таблиц особого вида, известного в математике как
отношение (relation).
Набор основных алгебраических операций состоит из восьми операций, которые делятся на два класса — теоретико-множественные операции и специальные
реляционные операции.
В состав теоретико-множественных операций входят операции: объединения
отношений; пересечения отношений; взятия разности отношений; взятия декартова
произведения отношений.
162
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Специальные реляционные операции включают: ограничение отношения;
проекцию отношения; соединение отношений; деление отношений.
Кроме того, в состав алгебры включается операция присваивания, позволяющая сохранить в базе данных результаты вычисления алгебраических выражений, и
операция переименования атрибутов, дающая возможность корректно сформировать
заголовок (схему) результирующего отношения. Общая интерпретация основных
реляционных операций (их восемь) схематически представлена на рисунке 3.6.
Рисунок 3.6 - Интерпретация операций реляционной алгебры
163
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Итак, под реляционной алгеброй будем понимать кортеж вида RA{T,O}, который определяется множеством Т реляционных таблиц совокупности с множеством О алгебраических операций над ними.
Классификация операций весьма условна. Несмотря на то, что реляционная
алгебра и базируется на теории множеств, в чистом виде теория множеств не приемлема для табличной алгебры и применяется с некоторыми особенностями. В лекции
эти особенности рассматривать не будем, а приведем один пример. Для выполнения
операции объединения теория множеств предполагает для объединения любые
множества, а для объединения таблиц должно выполняться одно условие – объединяются лишь те таблицы, которые имеют одинаковые наименования столбцов (полей).
Реляционная алгебра обладает важным свойством - она замкнута относительно понятия отношения. Это означает, что выражения реляционной алгебры выполняются над отношениями реляционных БД и результаты их вычисления также представляют собой отношения. Поэтому любое выражение может быть представлено
как отношение, что позволяет использовать его в других выражениях реляционной
алгебры.
Основная идея реляционной алгебры состоит в том, что средства манипулирования отношениями, рассматриваемыми как множества, основаны на традиционных
множественных операциях, дополненных некоторыми специфичными операциями
для БД.
Существует много подходов к определению реляционной алгебры, которые
различаются набором операций и способами их интерпретации, но в принципе все
они более или менее равносильны.
Опишем вариант алгебры, который был предложен Коддом. В этом варианте,
как уже было показано выше, набор алгебраических операций состоит из восьми основных: выборка отношения; проекция отношения; объединения отношений; пересечение отношений; вычитание отношений; произведение отношений, соединение
отношений, деление отношений.
164
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Эти операции можно объяснить следующим образом:
- результатом выборки отношения по некоторому условию является отношение, которое включает только те кортежи первоначального отношения, которые
удовлетворяют этому условию;
- при осуществлении проекции отношения на заданный набор его атрибутов
будет получено отношение, кортежи которого взяты из соответствующих кортежей первоначального отношения;
- при выполнении операции объединения двух отношений будет получено
отношение, включающее все кортежи, входящие хотя бы в одно из участвующих в
операции отношений;
- в качестве результата операции пересечения двух отношений получается отношение, включающее все кортежи, входящие в оба первоначальные отношения;
- отношение,
являющееся разностью
двух отношений, включает все кор-
тежи, входящие в первое отношение и одновременно такие, что ни один из них не
входит в отношение, являющееся вторым;
- при выполнении произведения двух отношений получается отношение, кортежи которого являются сочетанием кортежей первого и второго отношения;
- при соединении двух отношений по некоторому условию образуется результирующее отношение, кортежи которого являются сочетанием кортежей первого и
второго отношений, удовлетворяющим этому условию;
- операция реляционного деления имеет два операнда - бинарное (т. е. состоящее из двух атрибутов) и унарное (содержит один атрибут) отношения.
Результат операции - отношение, состоящее из кортежей, включающих значения первого атрибута кортежей первого отношения, причем таких, что множество
значений второго атрибута совпадает со множеством значений второго отношения.
Помимо вышеперечисленных, есть ряд особых операций, характерных для работы с БД:
- как результат операции переименования получается отношение, набор кортежей которого совпадает с телом первоначального отношения, но имена атрибутов
изменены;
165
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
- операция присваивания позволяет, сохранить результат вычисления реляционного выражения в существующем отношении БД.
Рассмотрим общую интерпретацию реляционных операций, используемых в
реляционной алгебре Кодда.
При выполнении операции объединения (UNION) двух отношений с
одинаковыми
заголовками
производится
отношение,
включающее
все
кортежи, которые входят хотя бы в одно из отношений-операндов.
Операция пересечения (INTERSECT) двух отношений с одинаковыми
заголовками производит отношение, включающее все кортежи, которые входят в
оба отношения-операнда.
Отношение, являющееся разностью (MINUS) двух отношений с одинаковыми
заголовками, включает все кортежи, входящие в отношение-первый операнд, такие,
что ни один из них не входит в отношение, которое является вторым операндом.
При выполнении декартова произведения (TIMES) двух отношений, пересечение заголовков которых пусто, производится отношение, кортежи которого производятся путем объединения кортежей первого и второго операндов.
Результатом ограничения (WHERE) отношения по некоторому условию является отношение,
включающее кортежи отношения-операнда, удовлетворяющее
этому условию.
При выполнении проекции (PROJECT) отношения на заданное подмножество
множества его атрибутов производится отношение, кортежи которого являются соответствующими подмножествами кортежей отношения-операнда.
При соединении (JOIN) двух отношений по некоторому условию образуется
результирующее отношение, кортежи которого производятся путем объединения
кортежей первого и второго отношений и удовлетворяют этому условию.
У операции реляционного деления (DIVIDE BY) два операнда — бинарное и
унарное отношения. Результирующее отношение состоит из унарных кортежей,
включающих значения первого атрибута кортежей первого операнда таких, что
множество значений второго атрибута (при фиксированном значении первого атри166
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
бута) включает множество значений второго операнда.
Операция переименования (RENAME) производит отношение, тело которого
совпадает с телом операнда, но имена атрибутов изменены.
Операция присваивания (:=) позволяет сохранить результат вычисления
реляционного выражения в существующем отношении БД.
Поскольку результатом любой реляционной операции (кроме операции присваивания, которая не вырабатывает значения) является некое отношение, можно
образовывать реляционные выражения, в которых вместо отношения-операнда некоторой реляционной операции находится вложенное реляционное выражение. В
построении реляционного выражения могут участвовать все реляционные операции,
кроме операции присваивания. При построении реляционного выражения необходимо учитывать приоритетность выполнения реляционных операций (табл.3.1.).
Таблица 3.1 - Таблица приоритетов операций реляционной алгебры
Наименование операции
RENAME (переименование)
RESTRICT (ограничение)
PROJECT (проекция)
TIMES (произведение)
JOIN (соединение)
INTERSECT (пересечение)
DIVIDE BY (деление)
UNION (объединение)
MINUS (разность)
Приоритет
4
3
3
2
2
2
2
1
1
Манипулирование реляционными данными
Стремление к минимизации числа таблиц для хранения данных может привести к возникновению различных проблем при их обновлении и будут даны рекомендации по разбиению некоторых больших таблиц на несколько маленьких. Но как
сформировать требуемый ответ, если нужные для него данные хранятся в разных
таблицах?
Предложив реляционную модель данных, Э.Ф.Кодд создал и инструмент для
удобной работы с отношениями – реляционную алгебру. Каждая операция этой ал167
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
гебры использует одну или несколько таблиц (отношений) в качестве ее операндов и
продуцирует в результате новую таблицу, т.е. позволяет "разрезать" или "склеивать"
таблицы.
Созданы языки манипулирования данными, позволяющие реализовать все
операции реляционной алгебры и практически любые их сочетания. Среди них
наиболее распространены SQL (Structured Query Language – структуризованный
язык запросов) и QBE (Quere-By-Example – запросы по образцу). Оба относятся к
языкам очень высокого уровня, с помощью которых пользователь указывает, какие
данные необходимо получить, не уточняя процедуру их получения.
С помощью единственного запроса на любом из этих языков можно соединить
несколько таблиц во временную таблицу и вырезать из нее требуемые строки и
столбцы (селекция и проекция).
Реляционная алгебра определяет простые и мощные методы конструирования
новых отношений из уже имеющихся. Реляционная алгебра состоит из набора операторов, использующих отношения в качестве операндов и возвращающих отношение в качестве результатов. Это реляционное свойство называется свойством замкнутости.
Так как операнды и результат имеют одинаковую структуру, это позволяет
использовать результат одной операции в качестве исходных данных для другой
операции.
Принято считать, что два отношения совместимы по типу, если у них идентичные заголовки, для этого должны выполняться следующие условия:
- если каждое из отношений имеет одно и то же множество имен атрибутов
(т.е. заведомо имеют одну и ту же арность);
- если соответствующие атрибуты определены на одном и том же домене;
- атрибуты в отношениях должны быть расположены в одном порядке.
168
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Пример:
Отношения А и В совместимы по типу:
Поставщики из города Г
НоИмя
мер
пост.
1
4
Иванов
Сидоров
Поставщики, которые поставляют
деталь Д
Статус
Город
Номер
пост.
Имя
Статус Город
20
15
Г1
Г2
10
4
Петров
Сидоров
16
15
Г10
Г2
Коддом были определены 8 операций реляционной алгебры, 5 из них считаются основными и 3 дополнительными.
Основные операции: объединение; разность; декартово произведение; проекция; выборка.
Дополнительные операции: соединения, деления и пересечения. Эти операции
не расширяют множество функций реляционной алгебры, так как могут быть выражены через 5 основных. Дополнительные операции были определены для обеспечения краткости записи.
Операции проекции и выборки являются унарными , т.е. производимые над
одним отношением, остальные – бинарными – исходными являются два отношения,
в результате мы всегда получаем одно отношение.
Операции реляционной алгебры
Проекция
С1,…, Сi
(А)
Операция возвращает отношение содержащее кортежи исходного отношения
после исключения их него некоторых определенных атрибутов. Результатом является вертикальное подмножество исходного отношения. Повторяющиеся кортежи в
итоговом отношении удаляются по определению.
169
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Например:
А
С1
а
а
д
д
и
С2
б
б
е
е
к
С3
в
в
а
а
л
С4
и
г
и
г
и
С5
к
д
к
д
к
С6
л
е
л
е
л
С1
а
а
д
д
и
Пусть А – отношение арности к. Для построения
С3
в
в
а
а
л
С1
а
д
и
С1С,3(А)
С3
в
а
л
нужно из каждого
кортежа, принадлежащего А, сформировать кортеж длины 2 из первого и третьего
атрибутов отношения А в указанном порядке.
Например, создать список сотрудников, указав в нем: Имя, Дату рождения.
Имя, Дата рождения
(Сотрудник)
Выборка (селекция)
Унарная операция, возвращающая отношение, содержащее множество кортежей, удовлетворяющих условию (предикату) F.
F – это формула образованная:
1) операндами, являющимися константами или именами атрибутов;
2) арифметическими операциями сравнения >, <, >=, <=, <>;
3) логическими операторами И, ИЛИ, НЕ;
4) скобками.
F(A)
Результатом является горизонтальное подмножество исходного отношения.
А
С1
а
а
д
д
и
С2
б
б
е
е
к
С3
в
в
а
а
л
С4
и
г
и
г
и
С5 С6
к л
д
е
к л
д
е
к л
А
С1
а
С2
б
С3
в
С4
г
С5
д
С6
е
170
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
F – C1="а" and С4="г"
Например, необходимо выбрать список всех сотрудников – мужчин.
(Сотрудник)
Пол= "м" (Сотрудник))
Пол= "м"
Имя(
Объединение
Объединение двух совместимых по типу отношений А и В представляет собой
отношение с тем же заголовком, что А и В и состоящее из множества кортежей принадлежащих обоим отношениям. Повторяющиеся кортежи в итоговом отношении
удаляются по определению.
АUВ
А
б
е
к
а
д
и
в
а
л
и
г
В
к
д
л
е
а
д
и
г
АUВ
б
е
к
д
в
а
л
е
Например необходимо объединение таблицы Сотрудник с таблицей Сотрудник, присланной на дискете из филиала организации.
Разность
Разностью двух совместимых по типу отношений А и В является отношение,
содержащее все кортежи, принадлежащие одному из двух отношений и не принадлежащих второму.
а
д
и
А
б
е
к
в
а
л
и
г
А-В
В
к
д
л
е
а
д
А-В
б
е
в
а
171
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Например, необходимо сделать список кодов должностей, на которых не работают сотрудники предприятия. Для этого необходимо сделать проекцию по коду
должности из отношения Должность, затем сделать проекцию по коду должности из
отношения Работа, получить разность между первым и вторым отношением.
Декартово произведение
Декартовым произведением отношений А арности к1 и отношения В арности
к2 называется отношение, содержащее множество кортежей длины к1+к2, являющихся всевозможным сочетанием кортежей, принадлежащих двум исходным отношениям и соединенных операцией сцепления (конкатенации). При этом первые к 1
компонентов кортежей нового отношения принадлежат А, последние к 2 компонентов – отношению В.
Если в исходных отношениях существуют атрибуты с одинаковыми названиями, то в результирующем отношении вводится новое название этих атрибутов.
АхВ
Допустимо для любых двух отношений.
а
д
и
А
б
е
к
в
а
л
и
г
В
к
д
л
е
а
а
д
д
и
и
б
б
е
е
к
к
АхВ
в
и
в
г
а
и
а
г
л
и
л
г
к
д
к
д
к
д
л
е
л
е
л
е
Декартово произведение дает информации больше, чем необходимо, поэтому
в чистом виде используется редко.
172
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Дополнительные операции
Пересечение
Пересечение двух совместимых по типу отношений А и В возвращает отношение с тем же заголовком, что у А и В и множеством кортежей принадлежащих
одновременно и А и В.
А
В
Эта операция эквивалентна следующему выражению: А – (А – В)
а
д
и
А
б
е
к
а
д
и
А
б
е
к
а
д
и
А
б
е
к
в
а
л
в
а
л
в
а
л
и
г
В
к
д
и
г
В
к
д
а
д
А-В
б
е
А
л
е
л
е
в
а
В
и
к
л
а
д
А-В
б
е
в
а
А – (А – В)
и
к
л
Деление
Для двух отношений – А арности к1 , мощности и1, В арности к2, мощности и2,
где к1>к2 и В – не пустое отношение, деление А на В есть отношение, состоящее из
множества кортежей и3, длины к1-к2, таких, что для всех кортежей и2 длины к2, принадлежащих В, декартово произведение кортежей и2 х и3 принадлежит А.
Пример 1, для бинарного и унарного отношений деление возвращает
отношение содержащее все значения одного атрибута бинарного отношения,
который соответствует в другом атрибуте всем значениям в унарном отношении.
173
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
А
а
а
а
в
в
в
В
б
с
б
с
д
б
с
к
А:В
а
в
Пример 2:
А
а
д
и
а
а
д
ж
б
е
к
б
б
е
з
В
в
в
л
с
и
с
и
г
г
г
д
к
д
к
в
с
г
д
А :В
а
б
д
е
Эта операция может быть выражена через основные операции:
А:В =
1,2, к1-к2(А)
-
1,2, к1-к2(А)
1,2, ,к1-к2((
1,2, к1-к2(А)
А
а
д
и
а
а
д
ж
б
е
к
б
б
е
з
в
в
л
с
и
с
и
г
г
г
д
к
д
к
а
д
и
ж
1,2, к1-к2(А)
а
д
и
ж
б
е
к
з
х В) – А)
б
е
к
з
1,2, к1-к2(А)
В
в
с
г
д
а
а
д
д
и
и
ж
ж
б
б
е
е
к
к
з
з
хВ
в
с
в
с
в
с
в
с
г
д
г
д
г
д
г
д
174
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
1,2, к1-к2(А)
а
а
д
д
и
и
ж
ж
б
б
е
е
к
к
з
з
и
и
ж
ж
к
к
з
з
в
с
в
с
в
с
в
с
(С)
в
с
в
с
хВ
г
д
г
д
г
д
г
д
а
д
и
а
а
д
ж
б
е
к
б
б
е
з
в
в
л
с
и
с
и
г
г
г
д
к
д
к
А=С
к
к
з
з
и
и
ж
ж
хВ–
в
с
в
с
г
д
г
д
1,2, к1-к2(С)
г
д
г
д
и
ж
1,2, к1-к2(А)
а
д
и
ж
1,2, к1-к2(А)
А
б
е
к
з
1,2, к1-к2(С)
ж
и
з
к
к
з
А : В = 1,2, к1-к2(А)
- 1,2, к1-к2(С)
а
б
д
е
Операция деления удобна тогда, когда надо сравнить некоторое множество
характеристик отдельных атрибутов.
Например, одно отношение Типы художественных произведений содержит
информацию о всех существующих типах или видах – Гуашь, пастель, масло, темпера, уголь и т.п., а в отношении Выставки хранятся записи о выставленных на той
или иной выставке работах, принадлежащих к определенному типу.
Если необходимо определить выставку, на которой были представлены все
типы (а мы знаем, что такие были), то необходимо разделить отношение Выставки
на отношение Типы по атрибуту код типа:
175
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Код
выставки
Выставки
Номер Код
работы типа
1
1
1
1
2
2
3
3
1
1
2
3
4
1
2
1
2
3
Типы
Код
типа
1
1
2
3
1
1
1
2
3
Результат
Код
выставки
1
2
3
1
3
Соединение
Возвращает отношение, кортежи которого - это сочетание двух кортежей
(принадлежащих соответственно двум определенным отношениям), имеющих общее значение для одного или нескольких общих атрибутов этих двух отношений (и
такие общие значения в результирующем кортеже появляются только один раз, а не
дважды). Это естественное соединение или соединение по эквивалентности.
Обозначение: А >< В
Алгоритм операции:
а) вычисляется произведение А х В - произведение;
б) реализуем операцию выборки по заданному условию – значение атрибута
(атрибутов) первой части сцепленного результирующего кортежа равно значению
атрибута (атрибутов) второй части сцепленного кортежа;
в) реализуем операцию проекции для удаления продублированного столбца.
А3(
А.А3=В.В2(А
хВ))
176
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
А
А2
б
е
а
у
А1
а
д
с
д
В
А3
с
к
б
с
В1
и
д
В2
к
с
а
а
д
д
с
с
д
д
б
б
е
е
а
а
у
у
АхВ
с
с
к
к
б
б
с
с
и
д
и
д
и
д
и
д
к
с
к
с
к
с
к
с
Соединение
Обозначение: А >< В,
f
где: f – условие арифметического сравнения атрибутов
Естественное соединение – это частный случай Соединения, когда используется операция =.
A
1
4
7
А
B
2
5
8
B
C
3
6
9
D E
3 1
6 2
А
A B
1 2
1 2
4 5
><
C
3
3
6
В
D
3
6
6
E
1
2
2
f -B<D
Рассмотренные примеры операции соединения относятся к так называемому
внутреннему соединению.
Зачастую при соединении двух отношений кортеж из одного отношения не
находит соответствующего кортежа в другом отношении, т.е. в столбцах соединения
оказываются несовпадающие значения. Может потребоваться, чтобы информация из
одного или обеих отношений присутствовала, даже если не имеются совпадающие
значения в общих столбцах.
В таком случае используют операцию внешнего соединения.
Внешнее соединение – это расширенная форма внутреннего соединения, отличающаяся тем, что кортежи в одном отношении, которые не имеют соответствующих кортежей во втором отношении появляются в результирующем отношении со
177
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
значением NULL в позициях атрибутов второго отношения вместо того, чтобы быть
просто проигнорированными, как это делается во внутреннем соединении.
Существует несколько разновидностей внешнего соединения:
- левое внешнее соединение, сохраняющее информацию из левого отношения,
включает в себя все строки из левой таблицы (А) – совпадающие и не совпадающие
плюс совпадающие значения из правой таблицы (В). Для строк из таблицы А, которым не найдено соответствие, значения NULL заносятся в столбцы, извлекаемые из
таблицы В;
- правое внешнее соединение, сохраняющее информацию из правого отношения, обратно предыдущему - включает в себя все строки из правой таблицы (В) –
совпадающие и не совпадающие плюс совпадающие значения из левой таблицы (А).
Для строк из таблицы В, которым не найдено соответствие, значения NULL заносятся в столбцы, извлекаемые из таблицы А;
- полное внешнее соединение, сохраняющее информацию с обеих сторон – это
комбинация левого и правого соединения. Присутствуют все строки из обеих таблиц. Если строки совпадают, то они заполнены реальными значениями. В несовпадающих строках значения столбцов заменяются значениями NULL.
Пример:
Категория должности
Должность
Код (ПК)
Название
Код (ПК)
Название
Код категории (ВК)
1
2
АУП
ППС
1
2
ректор
проректор
1
1
3
УВП
3
доцент
2
178
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
1
1
1
2
2
2
3
3
3
Внутреннее соединение
АУП
1
ректор
АУП
2
проректор
АУП
3
доцент
ППС
1
ректор
ППС
2
проректор
ППС
3
доцент
УВП
1
ректор
УВП
2
проректор
УВП
3
доцент
1
1
2
1
1
2
1
1
2
Левое внешнее соединение
1
АУП
1
ректор
1
1
АУП
2
проректор
1
1
АУП
3
доцент
2
2
ППС
null
доцент
null
2
ППС
null
null
null
2
ППС
null
null
null
3
УВП
null
null
null
3
УВП
null
null
null
3
УВП
null
null
null
Правое внешнее соединение
1
АУП
1
ректор
1
1
АУП
2
проректор
1
null
null
3
доцент
2
null
null
1
ректор
1
null
null
2
проректор
1
2
ППС
3
доцент
2
null
null
1
ректор
1
null
null
2
проректор
1
null
null
3
доцент
2
Внутреннее соединение (объединение левого и правого
внешних соединений)
1
АУП
1
ректор
1
1
АУП
2
проректор
1
1
АУП
3
доцент
2
2
ППС
1
ректор
1
2
ППС
2
проректор
1
2
ППС
3
доцент
2
3
УВП
null
null
null
3
УВП
2
проректор
1
3
УВП
3
доцент
2
179
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Вопросы для самоконтроля
1. Назовите основные и дополнительные виды операций реляционной
алгебры.
2. Что является результатом операции реляционной алгебры - проекция
и выборка?
3. Что является результатом операции реляционной алгебры - разность?
4. Что является результатом операции реляционной алгебры - произведение?
5. Что является результатом операции реляционной алгебры - объединение?
6. Что является результатом операции реляционной алгебры - соединение?
7. Что является результатом операции реляционной алгебры – деление?
8. В чем заключается реляционное свойство замкнутости реляционной
алгебры?
9. Какие условия необходимы для того, чтобы отношения считались
совместимыми по типу?
10.
Изобразите геометрическую интерпретацию операций реляци-
онной алгебры.
11.
Перечислите приоритеты операций реляционной алгебры.
180
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
3.3 Распределенная обработка данных
При размещении СУБД на персональном компьютере, который не находится в
сети, БД всегда используется в монопольном режиме. Даже если с ней работают несколько пользователей, они могут работать только последовательно.
Однако, как показала практика применения локальных баз данных, в большинстве
случаев информация, которая в них содержится, носит многопользовательский характер, поэтому возникает необходимость разработки таких СУБД, которые обеспечили бы
возможность одновременной работы пользователей с базами данных. Тем более, что
все современные предприятия строят свою политику в области информационного
обеспечения на основе принципов САLS-технологий.
Системы управления базами данных, обеспечивающие возможность одновременного доступа к информации различным пользователям называют системами управления
распределенными базами данных. В общем случае режимы использования БД имеют
вид, представленный на рисунке 3.7. Рассмотрим основные понятия, применяемые в
системах управления распределенными базами данных.
Рисунок 3.7 - Режимы работы с базами данных
Пользователь БД — программа или человек, обращающийся к базе данных.
Запрос — процесс обращения пользователя к БД с целью ввода, получения или
изменения информации в БД.
181
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Транзакция — последовательность операций модификации данных в БД, переводящая БД из одного непротиворечивого состояния в другое непротиворечивое состояние.
Логическая структура БД — определение БД на физически независимом
уровне; ближе всего соответствует концептуальной модели БД.
Топология БД, или структура распределенной БД, — схема распределения физической организации базы данных в сети.
Локальная автономность означает, что информация локальной БД и связанные с
ней определения данных принадлежат локальному владельцу и им управляются.
Удаленный запрос — запрос, который выполняется с использованием модемной
связи.
Возможность реализации удаленной транзакции — обработка одной транзакции, состоящей из множества SQL-запросов, на одном удаленном узле.
Поддержка распределенной транзакции допускает обработку транзакции, состоящей
из нескольких запросов SQL, которые выполняются на нескольких узлах сети (удаленных или локальных), но каждый запрос в этом случае обрабатывается только на одном узле.
Распределенный запрос — запрос, при обработке которого используются данные
из БД, расположенные в разных узлах сети.
Системы распределенной обработки данных в основном связаны с первым поколением БД, которые строились на мультипрограммных операционных системах и
использовали централизованное хранение БД на устройствах внешней памяти центральной ЭВМ и терминальный многопользовательский режим доступа. При этом пользовательские терминалы не имели собственных ресурсов, т. е. процессоров и памяти, которые могли бы использоваться для хранения и обработки данных. Первой полностью
реляционной системой, работающей в многопользовательском режиме, была СУБД
SYSTEM R фирмы IВМ. Именно в ней были реализованы как язык манипулирования
данными SQL, так и основные принципы синхронизации, применяемые при распределенной обработке данных, которые до сих пор являются базисными практически во
всех коммерческих СУБД.
182
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Модели клиент - сервер в технологии распределенных баз данных
Вычислительная модель клиент - сервер связана с появлением в 1990-х гг. открытых систем. Термин «клиент - сервер» применялся к архитектуре программного обеспечения, которое состояло из двух процессов обработки информации: клиентской и серверной. Клиентский процесс запрашивал некоторые услуги, а серверный процесс обеспечивал их выполнение. При этом предполагалось, что один серверный процесс может
обслужить множество клиентских процессов. Учитывая, что аппаратная реализация этой
модели управления базами данных связана с созданием локальных вычислительных сетей предприятия, такую организацию процесса обработки информации называют архитектурой клиент - сервер.
Основной принцип технологии клиент - сервер применительно к технологии
управления базами данных заключается в разделении функций стандартного интерактивного приложения на пять групп, имеющих различную природу:
- функции ввода и отображения данных (Presentation Logic);
- прикладные функции, определяющие основные алгоритмы решения задач приложения (Business Logic);
- функции обработки данных внутри приложения (Database Logic);
- функции управления информационными ресурсами (Database Manager System);
- служебные функции, играющие роль связок между функциями первых четырех
групп.
Структура типового приложения, работающего с базой данных в архитектуре
клиент— сервер, приведена на рисунке 3.8.
Презентационная логика как часть приложения определяется тем, что пользователь видит на своем экране, когда работает приложение. Сюда относятся все интерфейсные экранные формы, которые пользователь видит или заполняет в ходе работы
приложения. К этой же части относится все то, что выводится пользователю на экран
как результаты решения некоторых промежуточных задач либо как справочная информация. Поэтому основными задачами презентационной логики являются:
• формирование экранных изображений;
183
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
• чтение и запись в информации экранные формы;
• управление экраном;
• обработка движений мыши и нажатие клавиш клавиатуры.
Рисунок 3.8 - Структура типового приложения, работающего с базой данных
Бизнес-логика, или логика собственно приложений — это часть кода приложения, которая определяет собственно алгоритмы решения конкретных задач приложения. Обычно этот код пишется с использованием различных языков программирования, таких как С, С++, Visual Basic и др.
Логика обработки данных — это часть кода приложения, которая непосредственно связана с обработкой данных внутри приложения. Данными управляет собственно СУБД. Для обеспечения доступа к данным используется язык SQL.
Процессор управления данными — это собственно СУБД. В идеале функции
СУБД должны быть скрыты от бизнес-логики приложения, однако для рассмотрения архитектуры приложения их надо выделить в отдельную часть приложения.
В централизованной архитектуре эти части приложения располагаются в единой среде и комбинируются внутри одной исполняемой программы.
В децентрализованной архитектуре эти задачи могут быть по-разному распределены между серверным и клиентским процессами. В зависимости от характера
распределения можно выделить следующие модели распределений:
• распределенная презентация (DR – Distribution Presentation);
• удаленная презентация (RP - Remote Presentation);
184
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
• распределенная бизнес-логика (RBL – Remote business logic);
• распределенное управление данными (DDM – Distributed data manegement);
• удаленное управление данными (RDM – Remote data manegement).
Эта условная классификации показывает, как могут быть распределены отдельные задачи между серверным и клиентскими процессами. В этой классификации отсутствует реализация удаленной бизнес-логики. Считается, что она не может
быть удалена сама по себе полностью, а может быть лишь распределена между разными процессами, которые могут взаимодействовать друг с другом.
Двухуровневые модели
Двухуровневая модель фактически является результатом распределения пяти указанных выше функций между двумя процессами, которые выполняются на двух платформах: на клиенте и на сервере. В чистом виде почти никакая модель не существует, однако рассмотрим наиболее характерные особенности каждой двухуровневой модели:
модели удаленного управления данными и модели удаленного доступа к данным.
Модель удаленного управления данными. Она также называется моделью файлового сервера (FS – File Server). В этой модели презентационная логика и бизнес-логика
располагаются на клиентской части. На сервере располагаются файлы с данными, и
поддерживается доступ к файлам. Функции управления информационными ресурсами
в этой модели находятся на клиентской части. Распределение функций в этой модели
представлено на рисунке 3.9.
Рисунок 3.9 – модель файлового сервера
185
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
В этой модели файлы базы данных хранятся на сервере, клиент обращается к серверу с файловыми командами, а механизм управления всеми информационными ресурсами, собственно база метаданных, находится на клиенте.
Достоинство этой модели заключается в том, что приложение разделено на два
взаимодействующих процесса. При этом сервер (серверный процесс) может обслуживать множество клиентов, которые обращаются к нему с запросами.
Собственно СУБД должна находиться в этой модели на клиентском компьютере.
Алгоритм выполнения клиентского запроса сводится к следующему.
1. Запрос формулируется в командах ЯМД.
2. СУБД переводит этот запрос в последовательность файловых команд.
3. Каждая файловая команда вызывает перекачку блока информации на компьютер
клиента, а СУБД анализирует полученную информацию; если в полученном блоке не
содержится ответ на запрос, то принимается решение о перекачке следующего блока
информации, и т.д.
4. Перекачка информации с сервера на клиентский компьютер производится до
тех пор, пока не будет получен ответ на запрос клиента.
Данная модель имеет следующие недостатки:
• высокий сетевой трафик, который связан с передачей по сети множества блоков
и файлов, необходимых приложению;
• узкий спектр операций манипулирования с данными, который определяется
только файловыми командами;
• отсутствие адекватных средств безопасности доступа к данным (защита только
на уровне файловой системы).
Модель удаленного доступа к данным. В модели удаленного доступа (RDA – Remote Data Access) база данных хранится на сервере. На сервере же находится и ядро
СУБД. На компьютере клиента располагается презентационная логика и бизнес-логика
приложения. Клиент обращается к серверу с запросами на языке SQL. Структура модели
удаленного доступа приведена на рисунке 3.10.
186
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рису-
нок
3.10 - Структура модели удаленного доступа к данным
Преимущества данной модели заключаются в следующем:
• перенос компонента представления и прикладного компонента на клиентский
компьютер существенно разгружает сервер БД, сводя к минимуму общее число выполняемых процессов в операционной системе;
« сервер БД освобождается от несвойственных ему функций; процессор или процессоры сервера целиком загружаются операциями обработки данных запросов и транзакций;
• резко уменьшается загрузка сети, так как по ней от клиентов к серверу передаются не запросы на ввод-вывод в файловой терминологии, а запросы на SQL, а их объем существенно меньше. В ответ на запросы клиент получает только данные, соответствующие запросу, а не блоки файлов.
Основное достоинство RDA-модели — унификация интерфейса клиент—сервер
(стандартом при общении приложения-клиента и сервера становится язык SQL).
Данная модель имеет следующие недостатки:
• запросы на языке SQL при интенсивной работе клиентской части приложения
могут существенно загрузить сеть;
• так как в этой модели на клиенте располагается и презентационная логика, и
бизнес-логика приложения, то при повторении аналогичных функций в разных приложениях код соответствующей бизнес-логики должен быть повторен для каждого клиентского приложения. Это вызывает излишнее дублирование приложения;
187
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
• сервер в этой модели играет пассивную роль, поэтому функции управления информационными ресурсами должны выполняться на клиенте.
Модель сервера баз данных
Для того чтобы избавиться от недостатков модели удаленного доступа, должны
быть соблюдены следующие условия.
1. Необходимо, чтобы БД в каждый момент отражала текущее состояние предметной области, которое определяется не только собственно данными, но и связями
между объектами данных, т.е. данные, которые хранятся в БД, в каждый момент времени должны быть непротиворечивыми.
2. БД должна отражать некоторые правила предметной области, законы, по которым она функционирует (business rules). Например, завод может нормально работать только в том случае, если на складе имеется некоторый достаточный запас (страховой запас)
деталей определенной номенклатуры; деталь может быть запущена в производство
только в том случае, если на складе имеется в наличии достаточно материала для ее изготовления, и т.д.
3. Необходим постоянный контроль за состоянием БД, отслеживание всех изменений и адекватная реакция на них. Например, при достижении некоторым измеряемым
параметром критического значения должно произойти отключение определенной аппаратуры; при уменьшении товарного запаса ниже допустимой нормы должна быть сформирована заявка конкретному поставщику на поставку соответствующего товара и т. п.
4. Необходимо, чтобы возникновение некоторой ситуации в БД четко и оперативно
влияло на ход выполнения прикладной задачи.
5. Одной из важнейших проблем СУБД является контроль типов данных. В настоящий момент СУБД контролирует синтаксически только стандартно-допустимые типы
данных, т.е. такие, которые определены в DDL (data definition language) — языке описания
данных, который является частью SQL. Однако в реальных предметных областях действуют данные, которые несут в себе еще и семантическую составляющую, например
координаты объектов или единицы измерений.
188
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Такую модель поддерживают большинство современных СУБД: Informix, Ingres,
Sybase, Oracle, MS SQL Server. Основу данной модели составляет механизм хранимых
процедур как средство программирования SQL-сервера, механизм триггеров как механизм отслеживания текущего состояния информационного хранилища и механизм
ограничений на пользовательские типы данных, который иногда называется механизмом поддержки доменной структуры. Модель активного сервера базы данных представлена на рисунке 3.11.
Рисунок 3.11 - Модель активного сервера базы данных
В этой модели бизнес-логика разделена между клиентом и сервером. На сервере
бизнес-логика реализована в виде хранимых процедур — специальных программных модулей, которые хранятся в БД и управляются непосредственно СУБД. Клиентское приложение обращается к серверу с командой запуска хранимой процедуры, а сервер выполняет эту процедуру и регистрирует все изменения в БД, которые в ней предусмотрены. Сервер возвращает клиенту данные выполненного запроса, которые требуются
клиенту либо для вывода на экран, либо для выполнения части бизнес-логики. При
этом трафик обмена информацией между клиентом и сервером резко уменьшается.
Централизованный контроль в модели сервера баз данных выполняется с использованием механизма триггеров. Триггеры также являются частью БД.
Термин «триггер» взят из электроники и семантически очень точно характеризует механизм отслеживания специальных событий, которые связаны с состоянием БД.
Триггер в БД является неким тумблером, который срабатывает при возникновении определенного события в БД. Ядро СУБД проводит мониторинг всех событий, которые вызывают созданные и описанные триггеры в БД, и при возникновении соответствующего события сервер запускает соответствующий триггер. Каждый триггер представляет
189
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
собой также некоторую программу, которая выполняется над базой данных. Триггеры
могут вызывать хранимые процедуры.
Механизм использования триггеров предполагает, что при срабатывании одного
триггера могут возникнуть события, которые вызовут срабатывание других триггеров.
В данной модели сервер является активным, потому что не только клиент, но и сам
сервер, используя механизм триггеров, может быть инициатором обработки данных в
БД.
И хранимые процедуры, и триггеры хранятся в словаре БД. Они могут быть использованы несколькими клиентами, что существенно уменьшает дублирование алгоритмов обработки данных в разных клиентских приложениях.
Недостатком данной модели является очень большая загрузка сервера, так как он
обслуживает множество клиентов и выполняет следующие функции:
• осуществляет мониторинг событий, связанных с описанными триггерами;
• обеспечивает автоматическое срабатывание триггеров при возникновении связанных с ними событий;
• обеспечивает исполнение внутренней программы каждого триггера;
• запускает хранимые процедуры по запросам пользователей;
• запускает хранимые процедуры из триггеров;
• возвращает требуемые данные клиенту;
• обеспечивает все функции СУБД (доступ к данным, контроль и поддержку целостности данных в БД, контроль доступа, обеспечение корректной параллельной работы всех пользователей с единой БД).
Если мы перенесем на сервер большую часть бизнес-логики приложений, то требования к клиентам в этой модели резко уменьшатся. Иногда такую модель называют моделью
с тонким клиентом. Ранее рассмотренные модели называют моделями с толстым клиентом.
Для разгрузки сервера была предложена трехуровневая модель — модель сервера
приложений.
190
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Модель сервера приложений
Эта модель является расширением двухуровневой модели, в ней вводится дополнительный промежуточный уровень между клиентом и сервером. Архитектура трехуровневой модели приведена на рисунке 3.12. Этот промежуточный уровень содержит один
или несколько серверов приложений.
В этой модели компоненты приложения делятся между тремя исполнителями:
клиентом, сервером, сервером базы данных.
Клиент обеспечивает логику представления, включая графический пользовательский интерфейс, локальные редакторы; клиент может запускать локальный код
приложения клиента, который может содержать обращения к локальной БД, расположенной на компьютере-клиенте. Клиент исполняет коммуникационные функции front end части приложения, которые обеспечивают доступ клиенту в локальную или глобальную сеть. Дополнительно реализация взаимодействия между клиентом и сервером
может включать в себя управление распределенными транзакциями, что соответствует
тем случаям, когда клиент также является клиентом менеджера распределенных транзакций.
Серверы приложений составляют новый промежуточный уровень архитектуры. Серверы приложений поддерживают функции клиентов как частей взаимодействующих рабочих групп, поддерживают сетевую доменную операционную среду, хранят и исполняют наиболее общие правила бизнес-логики, поддерживают каталоги с данными, обеспечивают обмен сообщениями и поддержку запросов, особенно в распределенных транзакциях..
Рисунок 3.12 - Модель сервера приложений
191
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Серверы баз данных в этой модели занимаются исключительно функциями
СУБД: обеспечивают функции создания и ведения БД, поддерживают целостность
реляционной БД, обеспечивают функции хранилищ данных (warehouse services). Кроме того, на них возлагаются функции создания резервных копий БД и восстановления
БД после сбоев, управления выполнением транзакций и поддержки устаревших (унаследованных) приложений (legacy application).
Эта модель обладает большей гибкостью, чем двухуровневые модели. Наиболее
заметны преимущества модели сервера приложений в тех случаях, когда клиенты выполняют сложные аналитические расчеты над базой данных, которые относятся к области OLAP-приложений (On-line analytical processing).
В этой модели большая часть бизнес-логики клиента изолирована от возможностей встроенного SQL, реализованного в конкретной СУБД, и может быть выполнена на языках программирования, таких как С, С++, СоЬо1. Это повышает переносимость системы, ее масштабируемость.
Модели серверов баз данных
В период создания первых СУБД технология клиент - сервер только зарождалась. Поэтому изначально в архитектуре систем не было адекватного механизма организации взаимодействия процессов типа «клиент» и процессов типа «сервер». В современных же
СУБД он является фактически основополагающим и от эффективности его реализации
зависит эффективность работы системы в целом.
Рассмотрим эволюцию типов организации подобных механизмов. В основном этот
механизм определяется структурой реализации серверных процессов, и часто он называется архитектурой сервера баз данных.
Первоначально, как мы уже отмечали, существовала модель, у которой управление данными (функция сервера) и взаимодействие с пользователем были совмещены в
одной программе. Это можно назвать нулевым этапом развития серверов БД.
Затем функции управления данными были выделены в самостоятельную группу
— сервер, однако модель взаимодействия пользователя с сервером соответствовала
структуре связей между таблицами баз данных «один к одному» (рисунок 3.13), т.е. сер192
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
вер обслуживал запросы только одного пользователя (клиента), а для обслуживания
нескольких клиентов нужно было запустить эквивалентное число серверов.
Рисунок 3.13 - Взаимодействие клиентских и серверных процессов
в модели «один к одному»
Выделение сервера в отдельную программу было революционным шагом, который
позволил, в частности, поместить сервер на одну машину, а программный интерфейс с
пользователем — на другую, осуществляя взаимодействие между ними по сети. Однако
необходимость запуска большого числа серверов для обслуживания множества пользователей сильно ограничивала возможности такой системы.
Для обслуживания большого числа клиентов на сервере должно было быть запущено большое число одновременно работающих серверных процессов, а это резко повышало требования к ресурсам ЭВМ.
Кроме того, каждый серверный процесс в этой модели запускался как независимый, поэтому если один клиент сформировал запрос, который был только что выполнен
другим серверным процессом для другого клиента, то запрос выполнялся повторно. В такой модели весьма сложно обеспечить взаимодействие серверных процессов. Эта модель
самая простая, и она появилась первой.
Проблемы, возникающие в информационной модели «один к одному», решаются в архитектуре систем с выделенным сервером, который способен обрабатывать запросы от многих клиентов. Сервер единственный обладает монополией на управление
данными и взаимодействует одновременно со многими клиентами (рисунок 3.14). Логически каждый клиент связан с сервером отдельной нитью или потоком, по которому
пересылаются запросы. Такая архитектура получила название многопотоковой односерверной.
193
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Она позволяет значительно уменьшить нагрузку на операционную систему, возникающую при работе большого числа пользователей.
Рисунок 3.14 - Многопотоковая односерверная архитектура
Кроме того, возможность взаимодействия многих клиентов с одним сервером
позволяет в полной мере использовать разделяемые объекты (начиная с открытых
файлов и кончая данными из системных каталогов), что значительно уменьшает потребности в памяти и общее число процессов операционной системы.
Например, системой с моделью «один к одному» будет создано 100 копий процессов СУБД для 100 пользователей, тогда как системе с многопотоковой архитектурой
для этого понадобится только один серверный процесс. Однако такое решение имеет
свои недостатки. Так как серверный процесс может выполняться только на одном
процессоре, возникает естественное ограничение на применение СУБД для мультипроцессорных платформ. Если компьютер имеет, например, четыре процессора, то
СУБД с одним сервером используют только один из них, не загружая оставшиеся три.
В некоторых системах эта проблема решается вводом промежуточного диспетчера.
Подобная архитектура называется архитектурой виртуального сервера (рисунок 3.15).
Рисунок 3.15 - Архитектура виртуального сервера
194
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
В этой архитектуре клиенты подключаются не к реальному серверу, а к промежуточному звену, называемому диспетчером, который выполняет только функции диспетчеризации запросов к серверам. В этом случае нет ограничений на использование
многопроцессорных платформ. Число серверов может быть согласовано с числом процессоров в системе.
Однако и эта архитектура не лишена недостатков, потому что здесь в систему
добавляется новый слой, который размещается между клиентом и сервером, что увеличивает потребность в ресурсах на поддержку баланса загрузки серверов и ограничивает возможности управления взаимодействием клиент— сервер. Во-первых, становится
невозможным направить запрос от конкретного клиента конкретному серверу; вовторых, серверы становятся равноправными, так как нет возможности устанавливать
приоритеты для обслуживания запросов.
Подобная организация взаимодействия между клиентом и сервером может рассматриваться как аналог банка, где имеется несколько окон кассиров и специальный
банковский служащий, администратор зала, который направляет каждого пришедшего
посетителя (клиента) к свободному кассиру (актуальному серверу).
Система работает нормально, пока все посетители равноправны (имеют равные
приоритеты), однако стоит появиться посетителям с высшим приоритетом, которые
должны обслуживаться в специальном окне, как возникают проблемы. Учет приоритета клиентов особенно важен в системах оперативной обработки транзакций, однако
именно эту возможность не может предоставить архитектура систем с диспетчеризацией.
Современное решение проблемы СУБД для мультипроцессорных платформ заключается в возможности запуска нескольких серверов базы данных, в том числе и на
различных процессорах. При этом каждый из серверов должен быть многопотоковым.
Если эти два условия выполнены, то есть основания говорить о многопотоковой архитектуре с несколькими серверами, представленной на рисунке 3.16.
195
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 3.16 - Многопотоковая мультисерверная архитектура
Такую архитектуру называют также многонитиевой мулътисерверной архитектурой. Эта архитектура обеспечивает распараллеливание выполнения одного пользовательского запроса несколькими серверными процессами.
В этом случае пользовательский запрос разбивается на ряд подзапросов, которые
могут выполняться параллельно, а результаты их выполнения потом объединяются в
общий результат выполнения запроса. Тогда для обеспечения оперативности выполнения запросов их подзапросы могут быть направлены отдельным серверным процессам,
а затем полученные результаты объединены в общий результат (рисунок 3.17).
Ри-
су-
нок
3.17 Многонитевая мультисерверная архитектура
В данном случае серверные процессы не являются независимыми процессами —
такими, как рассматривались ранее. Эти серверные процессы принято называть нитями.
Управление нитями множества запросов пользователей требует дополнительных расхо-
196
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
дов от СУБД, однако при оперативной обработке информации в хранилищах данных
такой подход наиболее перспективен.
Типы параллелизма
Рассматривают следующие программно-аппаратные способы распараллеливания запросов: горизонтальный, вертикальный и смешанный параллелизм.
Горизонтальный параллелизм. Этот параллелизм возникает тогда, когда хранимая в
БД информация распределяется по нескольким физическим устройствам хранения — нескольким дискам. При этом информация из одного отношения разбивается на части по
горизонтали. Этот вид параллелизма иногда называют распараллеливанием, или сегментацией, данных. Параллельность достигается путем выполнения одинаковых операций,
например фильтрации, над разными физическими хранимыми данными. Эти операции
могут выполняться параллельно разными процессами — они независимы. Результат выполнения целого запроса складывается из результатов выполнения отдельных операций.
Вертикальный параллелизм. Этот параллелизм достигается конвейерным выполнением операций, составляющих запрос пользователя. Этот подход требует серьезного
усложнения модели выполнения реляционных операций ядром СУБД. Он предполагает,
что ядро СУБД может произвести декомпозицию запроса, базируясь на его функциональных компонентах; при этом ряд подзапросов может выполняться параллельно, с
минимальной связью между отдельными шагами выполнения запроса. Общее время
выполнения подобного запроса, конечно, будет существенно меньше, чем при традиционном способе выполнения последовательности из четырех операций (рисунок 3.18).
Рисунок 3.18 - Схема выполнения запроса при вертикальном параллелизме
197
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Смешанный параллелизм. Этот параллелизм является гибридом горизонтального и
вертикального параллелизма (рисунок 3.19).
Рисунок 3.19 - Схема выполнения запроса при смешанном параллелизме
Все виды параллелизма применяются в приложениях, где они позволяют существенно сократить время выполнения сложных запросов над очень большими объемами
данных.
Вопросы для самоконтроля
1. Дайте определения следующих понятий:
• топология БД, или структура распределенной БД;
• локальная автономность;
• удаленный запрос;
• поддержка распределенной транзакции; « презентационная логика;
• бизнес-логика.
2. Какие двухуровневые модели вы знаете? Назовите их достоинства и недостатки.
3. Назовите характеристики следующих архитектур организации баз данных:
« многопотоковая односерверная архитектура;
• архитектура с виртуальным сервером;
• многонитиевая мультисерверная архитектура.
4. Для чего применяют распараллеливание запросов и какие типы параллелизма вы
знаете?
198
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
4 Работа в СУБД SQL Server в инструментальной среде Visual
Studio.NET
4.1 Практикум по созданию базы данных в СУБД SQL Server 2008
Двойным нажатием левой кнопки мыши включить среду Microsoft SQL Server
Management Studio (рисунок 4.1) и осуществить соединение с сервером.
Рисунок 4.1 – Соединение с SQL Server 2008
Отобразится обозреватель объектов СУБД SQL Server (рисунок 4.2). Раскроем
папку «Базы данных», нажатием правой кнопки мыши вызовем контекстное меню, в
котором выберем команду «Создать базу данных» (рисунок 4.3).
В диалоговом окне «Создание базы данных» (рисунок 4.4) установим общие
свойства базы данных. Дадим название базе данных - «Кафедра». При необходимости укажем путь к месту сохранения файлов базы данных. При создании базы данных в СУБД SQL Server формируются два файла.
Первый файл является физическим файлом хранимых данных и имеет расширение - mdf.. Второй файл является логическим файлом и имеет расширение - ldf.
199
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 4.2 – Обозреватель объектов СУБД SQL Server
Рисунок 4.3 – Выбор команды «Создать базу данных»
200
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 4.4 – Диалоговое окно «Создание базы данных»
В списке баз данных обозревателя объектов появится папка Кафедра. Раскроем папку Кафедра, активизируем папку Таблицы, вызовем контекстное меню, выберем команду – Создать таблицу (рисунок 4.5).
Рисунок 4.5 – Вызов команды Создать таблицу
201
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
В конструкторе таблиц создадим таблицу Группа (рисунок 4.6), состоящую из
двух атрибутов: номер группы (тип данных – символьный из десяти знаков); количество студентов (тип данных – целочисленный). Атрибут Номер группы обозначим
ключевым, поэтому в столбце «Разрешить нулевое значение» уберем знак переключателя. При первоначальном конструировании таблицы остальные свойства столбцов таблицы оставляем без указаний по умолчанию.
Рисунок 4.6 – Конструирование таблицы Группа
Аналогичным способом создадим шаблон второй таблицы Студент (рисунок
4.7) с атрибутами: Номер зачетной книжки; Фамилия; Имя Отчество; Дата рождения; Адрес. Для организации связи типа – Один ко Многим (ссылочной целостности) с таблицей Группа добавим атрибут внешнего ключа Номер группы.
202
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 4.7 – Создание шаблона таблицы Студент
В обозревателе объектов (рисунок 4.8) в списке таблиц появятся две таблицы:
dbo.Группа и dbo.Студент.
Индекс dbo в названии таблиц означает базу данных
пользователя (таблица не является системной).
Рисунок 4.8 – Обозреватель созданных таблиц
203
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Следующим этапом создания базы данных является формирование схемы связей между таблицами. Этот объект называется Диаграммой базы данных (рисунок
4.9). Активизируем указанный объект, вызовем контекстное меню и выберем команду Создать диаграмму базы данных.
Рисунок 4.9 – Вызов команды Создать диаграмму базы данных
В появившемся диалоговом окне Добавление таблицы (рисунок 4.10) необходимо указать названия таблиц, участвующих в организации связей.
С помощью указателя курсора и таблиц свойств связей организовать необходимую логическую связь между таблицами (рисунок 4.11). В нашем примере организована связь типа Один ко Многим между первичным и внешним ключом обозначенных таблиц по атрибуту Номер группы.
На следующем этапе необходимо заполнить поля таблиц базы данных конкретными данными в указанных типах данных и форматах. Для этого необходимо в
обозревателе объектов (рисунок 4.12) активизировать таблицу Группа, вызвать контекстное меню и выбрать команду - Изменить первые 200 строк.
204
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 4.10 – Добавление таблиц на схему связей
Рисунок 4.11 – Диаграмма связей в базе данных
205
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 4.12 – Выбор команды на заполнение таблиц данными
В появившейся таблице Группа заполнить поля таблиц конкретными данными
(рисунок 4.13).
Рисунок 4.13 – Заполнение таблицы Группа данными
206
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Аналогично заполнить остальные таблицы базы данных (рисунок 4.14), после
чего можно приступить к конструированию запросов информации из базы данных.
Рисунок 4.14 – Данные в таблице Студент
Для конструирования запросов в списке объектов СУБД имеется объект, который называется - Представление.
Активизируем объект Представление (рисунок 4.15), вызовем контекстное меню и выбреем команду на создание представления.
Рисунок 4.15 – Вызов команды на создание Представления
207
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
В диалоговом окне Добавление таблицы (рисунок 4.16) указать названия таблиц, участвующих в организации запроса интересующей информации.
Появится окно конструктора запроса (рисунок 4.17), состоящее из четырех
сегментов, В верхнем сегменте отображаются таблицы, участвующие в запросе. Во
втором сегменте визуально определяются условия запроса. В третьем сегменте
отображается листинг Инструкции SELECT на структурированном языке запросов.
В четвертом нижнем сегменте отображаются результаты запроса.
Рисунок 4.16 – Выбор таблиц для конструирования запроса
Произведем конструирование запроса из двух имеющихся таблиц Группа и
Студент. Выберем поля таблиц: Номер группы, Фамилия, Адрес. Условием отбора
обозначим студентов, проживающих по адресу Оренбург.
Сравните данные результатов запроса с заполненными данными в таблице
Студент (рисунок 4.15) и оцените правильность выполнения запроса.
208
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 4.17 – Окно Конструктора запросов
После создания и работы с базой данных ее можно отсоединить от сервера.
Для этого необходимо в Обозревателе объектов активизировать папку с базой данных (рисунок 4.18), вызвать контекстное меню, выбрать команды Задачи и Отсоединить.
Для присоединения файлов базы данных необходимо выполнить команды Задачи и Подсоединить. После этого в диалоговом окне «Расположение файлов базы
данных» (рисунок 4.19) указать необходимый файл.
Обычно файлы базы данных располагаются по умолчанию на системном диске в папке программных файлов в директориях MSSQL и Date.
209
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 4.18 – Отсоединение базы данных от сервера
Рисунок 4.19 – Подсоединение файлов базы данных к серверу
Для завершения первого практикума по созданию базы данных потренируйтесь самостоятельно в создании таблиц Кафедра и Преподаватели.
210
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
4.2 Общие сведения о сетевой базе данных SQL Server, компоненты SQL
Server
С точки зрения операционной системы база данных — это один или несколько
обычных файлов ОС, доступ к данным которых осуществляется не напрямую, а через СУБД. При этом данные обычно располагаются на машине-сервере, а СУБД
обеспечивает корректную и эффективную их обработку из приложений, выполняющихся на машинах-клиентах.
С другой стороны, в рамках СУБД, база данных
— это логически структурированный набор объектов, связанных не только с хранением и обработкой прикладных данных, но и обеспечивающих целостность БД,
управление доступом, представление данных и т. д.
Объекты СУБД MS SQL Server
В СУБД MS SQL Server база данных включает следующие объекты (рисунок
4.20):
• таблицы;
• хранимые процедуры;
• триггеры;
• представления;
• правила;
• пользовательские типы данных;
• индексы;
• пользователи;
• роли;
• публикации;
• диаграммы.
Кроме того, при создании базы данных для нее всегда определяется журнал
транзакций, который используется для восстановления состояния базы данных в
случае сбоев или потери данных. Журнал размещается в одном или нескольких фай211
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
лах. В журнале регистрируются все транзакции и все изменения, произведенные в
их рамках. Транзакция не считается завершенной, пока соответствующая запись не
будет внесена в журнал.
Управление системой баз данных производится обычно с помощью нескольких сервисных программ — отдельных приложений, выполняемых в среде операционной системы.
Рисунок 4.20 – Обозреватель объектов СУБД
Рассмотрим основные функции и компоненты управления на примере сервера
реляционных баз данных MS SQL Server.
В СУБД SQL Server реализована возможность выполнять следующие основные функции:
• запускать и конфигурировать SQL Server;
• управлять доступом пользователей к объектам БД;
212
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
• создавать
и
модифицировать
базы
данных
и
их
объекты,
такие, как таблицы, индексы, представления и т. д.;
• управлять выполнением заданий «по расписанию»;
• управлять репликациями;
• создавать резервные копии баз данных и журналов транзакций.
Планирование БД
Использование концепции файлов и файловых групп для физического размещения хранимых данных упрощает управление базами данных и дисковой памятью,
а также обеспечивает гибкость при размещении конкретных объектов на устройстве
или устройствах.
Причем в этом случае обеспечивается реальное распределение данных между
всеми входящими в группу файлами (отдельными дисковыми устройствами или
RAID-массивами): дисковые устройства действительно одновременно, а не поочередно будут заполняться поступающими данными, поскольку данные будут пропорционально «чередоваться» по файлам группы (рисунок 4.21).
Рисунок 4.21 - Чередование данных в файловой группе
213
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Индексы
Для повышения производительности системы в ряде случаев может использоваться индекс — отдельная физическая структура в базе данных, создаваемая на основе таблицы и предназначенная для ускорения выборки данных, поиск которых
осуществляется по значению из проиндексированного столбца. Кроме того, индексы
используются для обеспечения уникальности строк и столбцов таблиц, упорядочения данных таблицы в отдельном файле или группе файлов для повышения скорости доступа.
Однако наличие индекса замедляет такие операции с таблицей, как вставка,
обновление и удаление данных: индексы являются динамически поддерживаемыми
структурами, т. е. при вставке, удалении или обновлении данных информация в индексах также должна быть изменена для отражения выполненных в таблице изменений. Для такой обработки требуются дополнительные операции ввода-вывода.
Кластерный индекс представляет собой двоичное дерево, в котором на нулевом уровне (уровне листьев) содержатся страницы актуальных данных таблицы, а
физическое расположение информации в данном индексе логически упорядочено.
Такое размещение данных позволяет сократить время доступа к данным, но только
при отборе по этому индексу. В других случаях это приводит к задержкам, так как
доступ к данным осуществляется только через индекс и начинается всегда с корня.
Для отдельной таблицы можно построить только один кластерный индекс.
В случае некластерных индексов страницы уровня листа содержат не текущие
данные таблицы (как в случае кластерного индекса), а указатель на строку данных,
включающий номер страницы данных и порядковый номер записи на станице.
Некластерный индекс позволяет быстро получить доступ к данным и не требует физического переупорядочения строк данных таблицы. Для каждой таблицы
можно создавать до 249 некластерных индексов (рисунок 4.22).
214
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 4.22 - Кластерный и некластерный индексы
Тип индекса устанавливается в меню свойств (рисунок 4.23)
Рисунок 4.23 – Меню свойств индекса
215
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Управление доступом
Система безопасности SQL Server имеет несколько уровней безопасности:
• операционная система;
• SQL Server;
• база данных;
• объект базы данных.
С другой стороны механизм безопасности предполагает существование четырех типов пользователей:
• системный администратор, имеющий неограниченный доступ;
• владелец БД, имеющий полный доступ ко всем объектам БД;
• владелец объектов БД;
• другие пользователи, которые должны получать разрешение на доступ к объектам БД.
Модель безопасности SQL Server включает следующие компоненты:
• тип подключения к SQL Server;
• пользователь базы данных;
• пользователь (guest);
• роли (roles).
Тип подключения к SQL Server
При подключении (и в зависимости от типа подключения) SQL Server поддерживает два режима безопасности:
• режим аутентификации Windows;
• смешанный режим аутентификации.
В режиме аутентификации Windows
используется система безопасности
Windows NT и ее механизм учетных записей. Этот режим позволяет SQL Server использовать имя пользователя и пароль, которые определены в Windows, и тем са216
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
мым обходить процесс подключения к SQL Server. Таким образом, пользователи,
имеющие действующую учетную запись Windows, могут подключиться к SQL Server, не сообщая своего имени и пароля. Когда пользователь обращается к СУБД, последняя получает информацию об имени пользователя и пароле из атрибутов системы сетевой безопасности пользователей Windows (которые устанавливаются, когда
пользователь подключается к Windows).
В смешанном режиме аутентификации задействованы обе системы аутентификации: Windows и SQL Server. При использовании системы аутентификации SQL
Server отдельный пользователь, подключающийся к SQL Server, должен сообщить
имя пользователя и пароль, которые будут сравниваться с хранимыми в системной
таблице сервера. При использовании системы аутентификации Windows пользователи могут подключиться к SQL Server, не сообщая имя и пароль.
Пользователи базы данных
Понятие пользователь базы данных относится к базе (или базам) данных, к которым может получить доступ отдельный пользователь. После успешного подключения сервер определяет, имеет ли этот пользователь разрешение на работу с базой
данных, к которой обращается.
Единственным исключением из этого правила является пользователь guest
(гость). Особое имя пользователя guest разрешает любому подключившемуся к SQL
Server пользователю получить доступ к этой базе данных. Пользователю с именем
guest назначена роль public.
Права доступа
Для управления правами доступа в SQL Server используются команды:
• GRANT. Позволяет выполнять действия с объектом;
• REVOKE. Аннулирует права доступа для объекта;
• DENY. He разрешает выполнять действия с объектом (в то время, как команда REVOKE просто удаляет эти права доступа).
217
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Объектные права доступа позволяют контролировать доступ к объектам в SQL
Server, предоставляя и аннулируя права доступа для таблиц, столбцов, представлений и хранимых процедур.
Чтобы выполнить по отношению к некоторому объекту некоторое действие,
пользователь должен иметь соответствующее право доступа. Например, если пользователь хочет выполнить оператор SELECT * FROM table, то он должен иметь права выполнения оператора SELECT для таблицы table.
Командные права доступа определяют тех пользователей, которые могут выполнять административные действия, например, создавать или копировать базу данных. Ниже приведены командные права доступа:
CREATE DATABASE — право создания базы данных;
CREATE DEFAULT — право создания стандартного значения для столбца
таблицы;
CREATE PROCEDURE — право создания хранимой процедуры.
CREATE ROLE — право создания правила для столбца таблицы;
CREATE TABLE — право создания таблицы;
CREATE VIEW — право создания представления;
BACKUP DATABASE — право создания резервной копии;
BACKUP TRANSACTION — право создания резервной копии журнала транзакций.
Роли
Назначение пользователю некоторой роли позволяет ему выполнять все функции, разрешенные этой ролью. По сути роли логически группируют пользователей,
имеющих одинаковые права доступа. В SQL Server есть следующие типы ролей:
• роли уровня сервера;
• роли уровня базы данных.
218
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Роли уровня сервера
С помощью этих ролей предоставляются различные степени доступа к операциям и задачам сервера. Роли уровня сервера заранее определены и действуют в
пределах сервера. Они не зависят от конкретных баз данных, и их нельзя модифицировать.
В SQL Server существуют следующие типы ролей уровня сервера:
• Sysadmin — дает право выполнить любое действие в SQL Server;
• Serveradmin — дает право изменить параметры SQL Server и завершить его
работу;
• Setupadmin —дает право инсталлировать систему репликации и управлять
выполнением расширенных хранимых процедур;
• Securityadmin — дает право контролировать параметры учетных записей для подключения к серверу и предоставлять права доступа к базам данных;
• Processadmin — дает право управлять ходом выполнения процессов в SQL
Server;
• Dbcreator — дает право создавать и модифицировать базы данных;
• Diskadmin — дает право управлять файлами баз данных на диске.
Роли уровня базы данных
Роли уровня базы данных позволяют назначить права для работы с конкретной базой данных отдельному пользователю или группе. Роли уровня базы данных
можно назначать учетным записям пользователей в режиме аутентификации Windows или SQL Server. Роли могут быть и вложенными, так что учетным записям
можно назначить иерархическую группу прав доступа.
В SQL Server существует три типа ролей:
• заранее определенные роли;
• определяемые пользователем роли;
• неявные роли.
219
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Заранее определенными являются стандартные роли уровня БД. Эти роли
имеет каждая база данных SQL Server. Они позволяют легко и просто передавать
обязанности.
Заранее определенные роли зависят от конкретной базы данных и не могут
быть изменены. Ниже перечислены стандартные роли уровня базы данных.
db_owner — определяет полный доступ ко всем объектам базы данных, может
удалять и воссоздавать объекты, а также
присваивать объектные права другим пользователям. Охватывает все функции, перечисленные ниже для других стандартных ролей уровня базы данных;
db_accessadmin — осуществляет контроль за доступом к базе данных путем
добавления или удаления пользователей в режимах аутентификации;
db_datareader — определяет полный доступ к выборке данных (с помощью
оператора SELECT) из любой таблицы базы данных. Запрещает выполнение операторов INSERT, DELETE и UPDATE для любой таблицы БД;
db_datawriter — разрешает выполнять операторы INSERT, DELETE и UPDATE для любой таблицы базы данных. Запрещает выполнение оператора SELECT
для любой таблицы базы данных;
db_ddladmin — дает возможность создавать, модифицировать и удалять объекты базы данных;
db_securityadmin — управляет системой безопасности базы данных, а также
назначением объектных и командных разрешений и ролей для базы данных;
db_backupoperator — позволяет создавать резервные копии базы данных;
db_denydatareader — отказ в разрешении на выполнение оператора SELECT
для всех таблиц базы данных. Позволяет пользователям изменять существующие
структуры таблиц, но не позволяет создавать или удалять существующие таблицы;
db_denydatawriter — отказ в разрешении на выполнение операторов модификации данных (INSERT, DELETE и UPDATE) для любых таблиц базы данных;
public — автоматически назначаемая роль сразу после предоставления права
доступа пользователя к БД.
220
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Роли, определяемые пользователем, позволяют группировать пользователей и
назначать каждой группе конкретную функцию безопасности.
Существуют два типа ролей уровня базы данных, определяемых пользователем:
• стандартная роль;
• роль уровня приложения.
Стандартная роль предоставляет зависящий от базы данных метод создания
определяемых пользователем ролей. Самое распространенное назначение стандартной роли — логически сгруппировать пользователей в соответствии с их правами
доступа. Например, в приложениях выделяют несколько типов уровней безопасности, ассоциируемых с тремя категориями пользователей. Опытный пользователь
может выполнять в базе данных любые операции; обычный пользователь может модифицировать некоторые типы данных и обновлять данные; неквалифицированному
пользователю обычно запрещается модифицировать любые типы данных.
Роль уровня приложения позволяет пользователю выполнять права некоторой
роли. Когда пользователь принимает роль уровня приложения, он берет на себя выполнение новой роли и временно отказывается от всех других назначенных ему прав
доступа к конкретной базе данных. Роль уровня приложения имеет смысл применять в среде, где пользователи делают запросы и модифицируют данные с помощью
клиентского приложения.
Управление обработкой
Представления, хранимые процедуры, триггеры
Для решения типовых (часто повторяющихся) задач выборки или обновления
данных, а также в значительной части для управления доступом к данным (как альтернатива механизму разрешения — запрета) и обеспечения целостности данных
целесообразно использовать процедуры. Кроме того, другое преимущество, уже в
части администрирования, состоит в том, что не надо специально определять поль221
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
зователю права доступа к таблицам и представлениям, используемым в процедуре:
достаточно определить только разрешение на выполнение процедуры.
Существуют два способа взаимодействия приложения с SQL Server:
- создать приложение, отправляющее клиентские операторы на SQL сервер;
- создать хранимые процедуры непосредственно на сервере.
В первом случае операторы каждый раз рекомпилируются сервером. Второй
способ активизирует хранимые процедуры, вызывая их из приложения одним оператором.
При первом вызове хранимой процедуры она компилируется и создается план
ее выполнения, который сохраняется в памяти. При последующих вызовах SQL
Server будет использовать этот план и процедуру повторно не компилирует. Таким
образом, когда для решения определенных задач требуется многократно выполнить
одну и ту же последовательность операторов SQL, применение хранимой процедуры
обеспечивает более высокую производительность.
Для управления обработкой в процедурах можно использовать локальные переменные, которые создаются с помощью оператора DECLARE. Переменная доступна с момента ее объявления и до выхода из процедуры. После выхода из процедуры на переменную ссылаться нельзя. Локальные переменные можно объявлять в
пакете, в сценарии, внешней программе, а также в хранимой процедуре. В операторе
DECLARE необходимо указать имя переменной и ее тип.
Представления
Представления (View) существуют независимо от информации в базе данных,
но тесно с ней связаны. Представления используются для фильтрования и предварительной обработки данных.
Представление — это по существу некая виртуальная таблица, содержащая
результаты выполнения запроса (оператора SELECT) к одной или нескольким таблицам. Для конечного пользователя представление выглядит как обычная таблица в
базе данных, над которой можно выполнять операторы SELECT, INSERT, UPDATE
222
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
и DELETE. В действительности представление хранится в виде предопределенного
оператора SQL.
Различные типы представлений имеют свои преимущества и недостатки. Выбор того или иного типа представлений полностью зависит от задач приложения.
Выделяют следующие типы представлений:
• подмножество полей таблицы — состоит из одного или более полей таблицы
и считается самым простым типом представления. Обычно используется для упрощения представления данных и обеспечения безопасности;
• подмножество записей таблицы — включает определенное количество записей таблицы и также применяется для обеспечения безопасности;
• соединение двух и более таблиц — создается соединением нескольких таблиц и используется для упрощения сложных операций соединения;
• агрегирование информации — создается группированием данных и также
применяется для упрощения сложных операций.
Представления также позволяют логически объединять данные. Например, если данные хранятся в нескольких таблицах, их затем посредством представления
можно объединить в более крупную виртуальную таблицу.
Еще одно преимущество представлений заключается в том, что они могут
иметь более низкий уровень безопасности, чем их исходные таблицы. Запрос для
представления выполняется согласно уровню безопасности вызывающего его пользователя. Таким образом, представление можно применять для сокрытия данных от
определенной группы пользователей.
Представления, как и индексы, можно создавать различными способами: использовать для этого «мастер» или команду T-SQL, имеющую в общем случае следующий формат.
CREATE VIEW имя_представления [столбец [,..]] AS SELECT-оператор
Следует отметить, что использование в операторе SELECT предложения
WHERE позволяет локализовать доступ пользователя к данным даже на уровне отдельных строк и столбцов.
223
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Хранимые процедуры
Хранимая процедура (stored procedure) — это набор операторов T-SQL, которые SQL SERVER компилирует в единый план выполнения.
Этот план сохраняется в кэше процедур при первом выполнении хранимой
процедуры, и затем план можно повторно использовать уже без рекомпиляции при
каждом вызове. Хранимая процедура аналогична процедурам в языках программирования: она может принимать входные параметры, возвращать данные и коды
завершения.
Применение хранимых процедур улучшает производительность, например,
при использовании в хранимой процедуре условных операторов (таких как IF и
WHILE), поскольку условие будет проверяться непосредственно на сервере и серверу не потребуется возвращать промежуточные результаты проверки условия программам-клиентам.
Хранимые процедуры также позволяют централизованно контролировать выполнение задачи, что гарантирует соблюдение бизнес-правил.
Хранимые процедуры, как и представления, можно создавать различными
способами: использовать для этого «мастер» или команду T-SQL, имеющую в общем случае следующий формат
CREATE PROCEDURE имя_ процедуры [(%параметр1 тип_данных[,..]]
AS SQL-операторы
Существует два типа хранимых процедур: системные и пользовательские.
Первые поддерживается SQL Server и применяются для управления сервером и
отображения информации о базах данных и пользователях. Вторые создаются пользователями для выполнения прикладных задач.
224
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Триггеры
Триггер (trigger) — это особый тип хранимой процедуры, которая автоматически выполняется при изменении таблицы с помощью операторов UPDATE, INSERT
или DELETE.
Как и хранимые процедуры, триггеры содержат операторы T-SQL, но в отличие от процедур запускаются не индивидуально, а автоматически при выполнении
операций изменения данных. Триггеры наряду с ограничениями обеспечивают целостность данных и соблюдение бизнес-правил, однако их следует использовать разумно. Например, не нужно создавать триггер, проверяющий наличие значения первичного ключа в одной таблице, чтобы определить, можно ли вставить значение в
соответствующее поле другой таблицы. Однако трудно обойтись без триггеров при
выполнении каскадных изменений в дочерних таблицах.
Триггер создается на одной таблице в текущей базе данных, хотя может использовать данные других таблиц и объекты других баз данных. Триггеры нельзя
создавать на представлениях, временных и системных таблицах. Таблица, для которой определен триггер, называется таблицей триггера.
Существуют три типа триггеров: UPDATE, INSERT и DELETE, каждый из которых инициируется при выполнении одноименной команды. Операции UPDATE,
INSERT и DELETE иногда называют событиями изменения данных.
Можно создать триггер, который будет срабатывать при возникновении более
чем одного события, например, запускаться в ответ на операторы UPDATE или INSERT. Такие комбинированные триггеры называются UPDATE/INSERT. Возможно
создание триггеров, срабатывающих при выполнении любого из трех операторов
обновления данных (триггер UPDATE/ INSERT/DELETE).
Триггеры можно создавать различными способами: использовать для этого
«мастер» или команду T-SQL, имеющую в общем случае следующий формат:
CREATE TRIGGER имя_триггера
ON имя_ таблицы
FOR [INSERT] [,] [UPDATE] [,] [DELETE]
AS SQL-операторы
225
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
В программе-триггере нельзя использовать операторы создания, реструктуризации, удаления объектов, реконфигурации и восстановления.
Работа триггеров подчиняется следующим правилам:
• триггеры запускаются только после завершения выполнения вызывающего
их
оператора.
Например,
триггер UPDATE не начинает работать, пока не за-
вершится выполнение оператора UPDATE;
• триггер не начинает работать, если при выполнении оператора происходит
нарушение какого-либо ограничения таблицы или возникает другая ошибка;
• триггер и вызывающий его оператор образуют транзакцию. В результате вызова из триггера оператора ROLLBACK отменяются изменения, выполненные триггером и оператором. При возникновении серьезной ошибки, например, при отключении пользователя, SQL-Server автоматически выполнит откат всей транзакции;
• триггер запускается один раз для каждого оператора, независимо от количества изменяемых оператором записей.
Триггеры возвращают результаты своей работы в приложение, подобно хранимым процедурам. Как правило, пользователь не ожидает вывода после выполнения операторов UPDATE, INSERT и DELETE, вызывающих срабатывание триггеров. Если триггер возвращает данные, приложение должно содержать код, правильно интерпретирующий результаты модификации таблицы и вывод триггера.
Для каждого триггера SQL Server создает две временные таблицы, на которые
можно ссылаться в описании триггера. Эти таблицы хранятся в памяти и локальны
по отношению к триггеру, то есть триггер имеет доступ только к своей собственной
версии таблиц. Временные таблицы применяются для сравнения состояния таблицы
до и после внесения изменений.
В MS SQL Server возможно создание нескольких триггеров на таблице для
каждого события изменения данных (UPDATE, INSERT или DELETE) и рекурсивный вызов триггера. Например, если для таблицы уже определен триггер UPDATE,
то можно определить еще один триггер UPDATE для той же самой таблицы. В этом
случае после выполнения соответствующего оператора сработают оба триггера.
Кроме того, допускаются вложенные триггеры, которые срабатывают в результате
226
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
выполнения других триггеров. Они отличаются от рекурсивных тем, что не запускают сами себя.
Управление транзакциями
Репликация базы данных заключается в копировании, или тиражировании,
данных из одной таблицы или базы данных в другую.
Офис с сетью региональных отделений — показательный случай для использования системы с репликацией транзакций. Каждый филиал ведет работу со своими
счетами, информация о которых содержится в его базе данных. Главный офис является подписчиком на базы данных всех филиалов, что позволяет собирать в нем информацию по всей организации.
Репликация основана на метафоре «издатель — подписчик»: издатель (публикующий сервер) предоставляет данные; распространитель содержит тиражируемую
базу или служебную информацию для управления репликацией; подписчик — получает и обрабатывает реплицированные данные. Данные передаются от публикующего или рассылающего сервера в направлении каждого из подписчиков. Данные не
могут пересылаться подписчику непосредственно от другого подписчика. Если один
из подписчиков перестает функционировать, это не должно оказывать никакого
влияния на издателя или других подписчиков.
Каждая публикация (набор реплицируемых данных — статей, которыми могут
быть таблицы, записи, поля или хранимые процедуры) создается для выделения
данных, подлежащих репликации в базе данных подписчиков. Агент синхронизации
создает файл схемы, предназначенный для создания в базе данных табличных
структур реплицируемых данных. Этот агент также создает файлы, содержащие
данные из публикуемых статей, и обновляет содержимое базы данных рассылки для
фиксации нового задания на согласование.
В журнале транзакций публикующего сервера все транзакции, подлежащие
репликации в адрес одного или более подписчиков, помечаются специальным
флажком.
227
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Агент чтения журнала считывает из журнала все помеченные этим флажком
команды INSERT, UPDATE и DELETE. Агент следит за появлением подлежащих
репликации транзакций для каждой публикации, существующей в базе данных публикующего сервера. Любая обнаруженная транзакция копируется им в базу данных
рассылки. Затем агент чтения журналов адресует рассылаемые данные каждому
подписчику на публикацию.
После исходного согласования состояний подписчика и публикующего сервера весь объем данных никогда не пересылается в адрес подписчика. Поддержание
актуального состояния базы данных подписчика обеспечивается агентом рассылки.
Он пересылает подписчику все команды INSERT, UPDATE и DELETE, введенные
пользователями на стороне публикующего сервера. Очень важно четко представлять
всю последовательность действий, которые выполняются при передаче подписчику
сведений об изменениях, проведенных на стороне публикующего сервера.
Координацию выполнения двухступенчатой фиксации изменений между публикующим сервером и сервером-подписчиком осуществляет Координатор распределенных транзакций (Microsoft Distributed Transaction Coordinator — MS DTC), который вызывает выполнение удаленных хранимых процедур.
Резервное копирование и восстановление
Архивирование и восстановление базы данных с корректировкой целостности
основаны на механизме регистрации изменений, использующем журнал транзакций
и контрольные точки.
В журнале транзакций регистрируются все транзакции и все изменения базы
данных, произведенные в их рамках. Транзакция не считается завершенной, пока
соответствующая запись не будет внесена в журнал.
Журнал может размещаться в нескольких файлах, допускающих автоматический рост. Журнал рассматривается не как таблица, а как отдельный файл в базе
данных: запись в журнал ведется блоками любого размера, не зависящего от размера
страниц сервера. При обновлении журнала или его архивировании происходит усечение журнала.
228
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Контрольная точка — это операция согласования состояния базы данных в
физических файлах с текущим состоянием кэша — системного буфера. С целью
улучшения производительности сохраняемые в БД данные сначала помещаются в
кэш, а потом система перезапишет модифицированные страницы на диск (отложенная запись), причем пользователь не может знать, когда эта запись производится.
Вопросы для самоконтроля
1. Назовите объекты базы данных в СУБД MS SQL Server;
2. Назначение и типы индексов в СУБД MS SQL Server;
3. Назовите уровни в системе безопасности SQL Server;
4. Назначение и типы ролей уровня базы данных SQL Server;
5. Назначение представлений;
6. Какие типы представлений и какие они имеют преимущества и недостатки;
7. Назначение хранимых процедур;
8. Назначение триггеров;
9. Объясните порядок управления транзакциями;
10. Как осуществляется резервное копирование и восстановление СУБД
MS SQL Server.
229
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
4.3 Практикум по созданию Windows-приложения к базе данных SQL
Server в инструментальной среде Visual Studio по технологии .NET
После того как база данных создана, файл базы данных перемещен в нужное
место, можно приступать к разработке структуры базы данных и созданию клиентского приложения.
Разработка структуры базы данных и создание клиентского приложения выполняется в среде MS Visual Studio 2010.
Для начала разработки необходимо открыть Visual Studio 2010 и создать новый проект: меню ―File(Файл)‖→ ―New(Новый)‖→ ―Project(Проект)‖… (рисунок
4.24).
Рисунок 4.24 – Создание нового проекта
В открывшемся диалогом окне ―New Project(Новый проект)‖ выбрать ―Visual
C#‖→ ―Windows Forms Application(Приложение Windows Forms)‖, в поле
Name(Имя) указать имя проекта (в данном случае указано ―WindowsFormsApplication‖) (рисунок 4.25).
230
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 4.25 – Выбор типа проекта
Затем необходимо добавить в проект источник данных: ―Главное меню‖→
―Data(Данные)‖→ ―Add New Data Source…(Добавить новый источник данных…)‖
(рисунок 4.26).
Рисунок 4.26 – Добавление нового источника данных
231
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
В окне выбора типа источника данных нажать левой кнопкой мыши на ―Database(База данных)‖ и далее нажать кнопку ―Next(Далее)‖ (рисунок 4.27).
Рисунок 4.27 – Выбор типа источника данных
В следующем окне необходимо указать модель базы данных (рисунок 4.28), а
затем создать строку соединения с источником данных: нажать на кнопку ―New
Connection…(Создать подключение)‖ (рисунок 4.29).
Рисунок 4.28 – Выбор модели базы данных
232
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 4.29 – Выбор подключения базы данных
В появившемся окне ―Add Connection‖ нажать кнопку Change…(Изменить)‖
напротив поля ввода ―Data source(Источник данных)‖ (рисунок 4.30).
Рисунок 4.30 – Добавление источника подключения
233
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
В окне ―Change Data Source(Сменить источник данных)‖ в списке ―Data
source(Источник данных)‖ кликнуть на пункт
―Microsoft SQL Server‖ и нажать
кнопку ―OK‖ (рисунок 4.31).
Рисунок 4.31 – Смена источника данных
После этого в окне
―Add Connection(Добавить подключение)‖ произвести
остальные настройки:
1) в поле ―Server name(Имя сервера)‖ указать имя компьютера, на котором
располагается SQL-сервер с созданной базой данных ―Тест‖;
2) в радио-группе
―Log on to the server(Вход на сервер)‖ выбрать тип
аутентификации в соответствии с настройками SQL-сервера (если выбран ―Use SQL server Authentication(Использовать проверку подлинности SQL Server‖, то необходимо указать логин и пароль пользователя
SQL-сервера);
3) в радио-группе ―Connect to a database(Подключение к базе данных)‖ в
поле ―Select or Enter a database name(Выберите или введите имя базы
данных)‖ указать имя базы данных (―Тест‖) и нажать кнопку ―OK‖.
После возврата в окно ―Data Source Configuration Wizard(Мастер настройки
источника данных)‖ указать
―Yes, include sensitive data in connection string(Да,
234
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
включить конфиденциальные данные в строку подключения)‖ и нажать кнопку
―Next(Далее)‖.
Далее в следующем окне ―Data Source Configuration Wizard(Мастер настройки
источника данных)‖ оставить имя, которое среда присвоит созданной строке соединения, и нажать ―Next(Дальше)‖ (рисунок 4.32)
Рисунок 4.32 – Имя присвоенное строке соединения
В появившемся окне ―Выбор объектов базы данных‖ выбрать нужные пункты
напротив объектов базы данных (рисунок 4.33) и нажать кнопку ―Finish(Готово)‖.
235
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 4.33 –Выбор объектов базы данных
Теперь можно приступить к созданию структуры базы данных. Создание
структуры базы данных сводится к составлению ее диаграммы, содержащей информацию о составе таблиц и связей между ними. Для этого необходимо открыть обозреватель серверов: ―Server Explorer(Обозреватель серверов)‖ (рисунок 4.34).
После этого в обозревателе серверов раскрыть пункт, соответствующий только что созданной строке соединения, кликнуть правой кнопкой мыши по пункту
―Database Diagrams‖ и выбрать пункт ―Add New Diagram(Добавить новую схему)‖
(рисунок 4.35).
236
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 4.34 –Открытие обозревателя серверов
Рисунок 4.35 – Добавление новой схемы
237
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Затем в появившемся справа окне (рабочей области диаграммы) нажать правой кнопкой мыши по свободному месту и в появившемся контекстном меню выбрать пункт ―New Table…(Создать таблицу)‖ (рисунок 4.36).
Рисунок 4.36 – Создание таблиц
В появившемся диалоговом окне ―Choose Name(Выбор имени)‖ необходимо
ввести имя таблицы. В данном случае ―Техника‖ (рисунок 4.37).
Рисунок 4.37 – Название таблицы
238
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
В рабочей области диаграммы появилась новая таблица, необходимо добавить
в нее поля. Для этого нужно нажать левой кнопкой мыши на первой пустой строке, в
колонке ―Column Name(Имя столбца)‖ указать имя поля, в колонке ―Data Type(Тип
данных)‖ из выпадающего списка выбрать необходимый тип данных. Поле ―ИД‖ в
данной таблице должно обладать свойством автоинкримента, чтобы придать ему такое свойство нужно кликнуть правой кнопкой на строке, соответствующей описанию
поля
для
вызова
панели
―Properties(Свойства)‖.
В
панели
―Properties(Свойства)‖ найти графу ―Identity Specification(Спецификация идентификатора)‖ и установить свойство ―Is Identity‖ в положение ―Yes(Да)‖ (Рисунок 4.38 Правый нижний угол рисунка).
Рисунок 4.38 – Спецификация идентификатора
Затем поле ―ИД‖ необходимо сделать первичным ключом таблицы, для чего
нужно кликнуть по его строке на диаграмме правой кнопкой и в появившемся кон-
239
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
текстном меню выбрать пункт ―Set Primary Key(Задать первичный ключ)‖ (рисунок
4.39).
Рисунок 4.39 – Задание первичного ключа
Аналогичным образом создаются остальные поля данной таблицы, т.е. в колонке
―Column Name(Имя столбца)‖ указывается имя поля, в колонке
―Data
Type(Тип данных)‖ из выпадающего списка выбирается необходимый тип данных.
Далее вышеописанным способом создаются все остальные таблицы базы данных. Единственная особенность создания таблиц, которую нужно оговорить – это
создание вычисляемых полей. В этой базе данных – это поле ―Сумма‖ в таблице
―ПозицияДокументаОРемонтеТехники‖ (Рисунок 4.40).
Рисунок 4.40 – Создание вычисляемых полей
240
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Для того чтобы сделать его вычисляемым нужно вызвать для него панель ―
Properties(Свойства)‖. В панели ―Properties‖ найти графу ―Computed Column Specification(Спецификация столбца)‖ и в свойство ―Formula(Формула)‖ записать формулу, для расчета этого поля (в данном случае ―([Цена]*[Количество])‖) (рисунок
4.41).
Рисунок 4.41 – Ввод формул
После того, как все таблицы будут созданы, диаграмма примет вид, подобный
представленному на рисунке 4.42.
Теперь нужно указать связи между таблицами. Это делается следующим образом: выбирается поле, являющееся первичным ключом первой таблицы, и перетаскивается на поле другой таблицы, которое должно стать внешним ключом.
В данном примере создавалась связь между таблицами ―ПозицияДокумента…‖ и ―ЕдиницаИзмерения‖ с помощью первичного ключа ―ИД‖ таблицы ―ЕдиницаИзмерения‖. После перетаскивания появляется окно, часть которого представлена
на рисунке 4.43, в котором нужно нажать кнопку ―OK‖.
241
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 4.42 – Диаграмма базы данных после добавления в нее всех таблиц
Рисунок 4.43 – Установление связи между таблицами
Затем необходимо кликнуть правой кнопкой мыши на появившейся на диаграмме линии между таблицами, обозначающей связь и вызвать для нее панель
―Properties(свойства)‖. В панели ―Properties(Свойства)‖ найти графу ―INSERT And
Update Specification(Спецификация INSERT и UPDATE)‖ и установить свойства
242
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
―Delete Rule(Удалить правило)‖ и ―Update Rule(Обновить правило)‖ в положение
―No Action(Без действия)‖ (рисунок 4.44).
Рисунок 4.44 – Задание свойств графы INSERT и Update
Аналогичным образом создаются связи между всеми остальными таблицами
базы данных. После установления всех связей диаграмма примет вид, представленный на рисунке 4.45.
Для того, чтобы по диаграмме была построена база данных необходимо сохранить диаграмму: ―File(Файл)‖→―Save DiagramDB(Сохранить DiagramDB)‖.
После этого среда ―Visual Studio‖ сообщит о том, что в структуру базы данных будут внесены изменения и спросит, продолжить выполнение операции или нет
– нужно нажать кнопу ―Yes(Да)‖.
243
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 4.45 – Диаграмма базы данных с установленными связями
между таблицами
Создание представления
В разрабатываемом программном средстве частым запросом будет запрос на
получение последних цен на запчасти, который будет вызываться как пользователем
для получения соответствующей информации, так и СУБД для определения цены
запчасти при записи позиции документа о ремонте, поэтому целесообразно создать
представление, с помощью которого можно будет получать соответствующую информацию.
Для того чтобы создать представление, с помощью которого можно получить
информацию о действующих ценах на запчасти, необходимо в обозревателе серверов кликнуть правой кнопкой мыши по пункту ―Views(Представления)‖ и в появившемся меню выбрать пункт ―Add New View(Добавить новое представление)‖
(рисунок 4.46)
244
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 4.46 – Добавление представления
В появившемся окне необходимо написать текст запроса (рисунок 4.47).
Рисунок 4.47 – Текст запроса представления
Затем необходимо нажать кнопку ―Save (Сохранить)‖ основной панели и в
появившемся окне ввести имя представления, после нажать кнопку ―OK‖.
245
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Создание функций
В создаваемом приложении частой операцией будет получение последней цены на конкретную запчасть, поэтому целесообразно создать функцию, возвращающую эти данные. Для добавления функции, возвращающей действующую цену запчасти (в виде числа), необходимо в обозревателе серверов нажать правой кнопкой
мыши по пункту
―Functions(Функции)‖, в контекстном меню выбрать пункт
―Scalar-valued Function(Скалярная функция)‖ (рисунок 4.48) и в появившемся окне
ввести текст кода функции (рисунок 4.49).
Рисунок 4.48 – Добавление новой функции
Рисунок 4.49 – Текст кода функции
246
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Для написания функций (запросов с параметрами) необходимо в обозревателе
серверов выбрать подключенную базу данных и создать в ней подставляемую функцию, как показано на рисунке 4.50.
Рисунок 4.50 – Создание запроса с параметрами
Будет создан макет кода функции, пример которого изображен на рисунке
4.51.
Рисунок 4.51 – Макет кода функции
247
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Этот вариант функции выполним на примере другой базы данных. Для начала
необходимо определить параметр (или параметры, если их несколько), на основании
которого будет осуществляться запрос. Допустим, необходимо реализовать следующий запрос: Сформировать для заданного преподавателя итоговую сумму (в часах) запланированных и выполненных объемов работ по семестрам и сгруппировать
по фамилии и учебному году. Данный запрос будет обращаться к двум таблицам:
«Индивидуальный план» и «Выполненный объем работ».
Параметром для данного запроса будет наименование техники преподавателя.
В коде функции параметр определяется так, как показано на рисунке 4.52.
Рисунок 4.52 – Определение параметра запроса
После объявления параметров запроса, можно перейти к написанию основного
кода запроса. Можно написать код вручную, но более удобно и просто это можно
сделать с помощью конструктора (рисунки 4.53 и 4.54).
248
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 4.53 – Вызов конструктора запроса SQL
Рисунок 4.54 – Построитель запросов
Выберем все необходимые таблицы («Индивидуальный план» и «Выполненный объем работ») и создадим с помощью конструктора обычный запрос без пара249
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
метров и нажмем клавишу «ОК». В код функции добавится этот запрос на языке
SQL (рисунок 4.55).
Рисунок 4.55 –Код функции
Осталось только добавить условие проверки на равность нашему параметру.
Для этого в код необходимо добавить одну строку с оператором WHERE (рисунок
4.56).
Рисунок 4.56 – Добавление условия проверки
Для вывода результатов выполнения написанной функции, необходимо ее добавить в источники данных и создать для нее форму (как для обычных таблиц). Результат представлен на рисунке 4.57.
250
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 4.57 – Форма для запроса с параметром
Создание триггеров
В таблицу ―ПозицияДокументаОРемонте‖ необходимо добавить два триггера:
на команду INSERT и на команду UPDATE, чтобы в соответствующий столбец при
добавлении и изменении строки подставлялось значение цены соответствующей запчасти. Для этого в обозревателе серверов необходимо нажать правой кнопкой мыши по пункту ―ЗапчастиДляРемонта‖, в контекстном меню выбрать пункт ―Add
New Trigger(Создать новый триггер)‖ (рисунок 4.58) и в появившемся окне ввести
текст кода триггера (рисунки 5.59 и 4.60).
Рисунок 4.58 – Добавление нового триггера
251
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 4.59 – Текст триггера на вставку строк
Рисунок 4.60 – Текст триггера на обновление строк
Для разрешения проблем параллельной работы, к таблицам ―Запчасти для ремонта‖ и ―Цены запчастей‖ прикрепляются триггеры, реализующие с помощью
средств SQL обновление этих таблиц с блокировкой и представленные на рисунках
4.61 и 4.62.
252
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 4.61 – Текст триггера
Рисунок 4.62 – Текст триггера
В случае если очередной запрос на добавление или редактирование данных в
этих таблицах поступит менее чем через 15 секунд после предыдущего, то он получит отказ.
253
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
5 Использование средств автоматизации для проектирования и
создания баз данных
5.1 Общие сведения об IDEF -технологии
В лекции излагается материал по технологии структурного анализа АИС с
трех ключевых точек зрения одновременно:
- средство верхнего уровня, поддерживающее методологии IDEF0 (функциональная модель Integration Definition for Function Modeling), рассматривается как
диаграмма потоков работ;
- IDEF3 (WorkFlow Diagram), рассматривается как диаграмма потоков процессов;
- DFD (DataFlow Diagram), рассматривается как диаграмма потоков данных.
IDEF0 – технология структурного анализа и проектирования. Предложена более 25 лет назад Д.Россом. Первоначально она называлась как SADT (Structured
Analysis and Design Technigue). IDEF0 представляет собой совокупность действий
(activities), которые взаимодействуют между собой на основе определенных правил
(Control), с учетом информационных, человеческих и производственных ресурсов
(Mechanism), имеющих четко определенные вход (Input) и выход (Output).
IDEF3 – это технология сбора данных, необходимых для проведения структурного анализа АИС, дополняющая технологию IDEF0.
DFD – представляет собой диаграмму потоков данных.
На каких этапах используются указанные технологии? Графически это можно
показать так:
Анализ
Моделирование
Проектирование
---IDEF0---------------- IDEF3--------------DFD----------0
t1
t2
t3
t
254
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Указанные методологии имеют мощную компьютерную поддержку в виде интегрированного программного пакета ВPWin (рисунок 5.1).
функциональное моделирование ---описание бизнес - процессов ----------диаграмма потоков данных ------------
Рисунок 5.1 - Диалоговое меню программного пакета ВPWin
Общие принципы построения IDEF -технологии
Основу методологии IDEF0 составляет графический язык описания бизнес процессов. Модель в нотации IDEF0 представляет собой совокупность иерархически
упорядоченных и взаимосвязанных диаграмм.
Вершина этой древовидной структуры, представляющая собой самое общее
описание системы и ее взаимодействия с внешней средой, называется контекстной
диаграммой.
После описания системы в целом проводится разбиение ее на крупные фрагменты. Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции.
После декомпозиции контекстной диаграммы проводится декомпозиция каждого большого фрагмента системы на более мелкие и так далее до достижения нужного уровня подробности описания.
255
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Синтаксис описания системы в целом и каждого ее фрагмента одинаков во
всей модели. Работы (Activity), которые означают некие поименованные процессы,
функции или задачи, изображаются в виде прямоугольников. Именем работы должен быть глагол или глагольная форма.
Взаимодействие работ с внешним миром и между собой описывается в виде
стрелок. Стрелки представляют собой некую информацию и именуются существительными. В IDEF0 различают пять типов стрелок:
Вход (Input) - материал или информация, которая используется или преобразовывается работой.
Управление (Control) - правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку
управления.
Выход (Output) - материал или информация, которая производится работой.
Каждая работа должна иметь хотя бы одну стрелку выхода.
Механизм (Mechanism)- ресурсы, которые выполняют работу, например, персонал предприятия станки, механизмы и т.д.
Вызов - специальная стрелка, указывающая на другую модель работы.
Каждый тип стрелок подходит или выходит к определенной стороне прямоугольника, изображающего работу. К левой стороне подходят стрелки входов, к
верхней - стрелки управления, к нижней - механизмов реализации выполняемой
функции, а из правой - выходят стрелки выходов (рисунок 5.2).
Такое соглашение предполагает, что используя управляющую информацию и
реализующий ее механизм, функция преобразует свои входы в соответствующие
выходы.
Рисунок 5.2 - Пример диаграммы в нотации IDEF0
256
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Общие принципы построения модели в методологиях DFD и IDEF3 сходны с
IDEF0: модель представляет собой совокупность иерархически зависимых диаграмм, прямоугольники изображают работы или процессы, стрелки- это тоже некие
данные, построение модели осуществляется сверху вниз путем проведения декомпозиции крупных работ на более мелкие.
Диаграммы потоков данных (Data flow diagramming, DFD) используются для
описания документооборота и обработки информации. Их можно использовать как
дополнение к модели IDEF0 для более наглядного отображения текущих операций
документооборота в корпоративных системах обработки информации. DFD описывают функции обработки информации (работы), документы (стрелки, arrow), объекты, сотрудников или отделы, которые участвуют в обработке информации (внешние
ссылки, external references) и таблицы для хранения документов (хранилище данных,
data store). В отличие от IDEF0 для стрелок нет понятия вход, выход, управление
или механизм и неважно, в какую грань работы входит или из какой грани выходят
стрелки.
Примеры диаграмм технологии IDEF
IDEF0 – технология анализа системы в целом как совокупность действий
257
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
IDEF3 – описание бизнес процесса как последовательность событий и
описание объектов
DFD – моделирует систему как совокупность действий, которые обрабатывают данные
258
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
5.2 Метод функционального моделирования IDEF0
Метод функционального моделирования IDEF0 — это технология описания
системы в целом как множества взаимозависимых действий, или функций. Важно
отметить функциональную направленность IDEF0 — функции системы исследуются
независимо от объектов, которые обеспечивают их выполнение. "Функциональная"
точка зрения позволяет четко отделить аспекты назначения системы от аспектов ее
физической реализации.
Наиболее часто как технология исследования и проектирования систем на логическом уровне. По этой причине он, как правило, используется на ранних этапах
разработки проекта, до IDEF3 моделирования для сбора данных и моделирования
процесса "как есть". Результаты IDEF0 анализа могут применяться при проведении
проектирования с использованием моделей IDEF3 и диаграмм потоков данных.
Модели IDEFO
IDEF0 сочетает в себе небольшую по объему графическую нотацию (она содержит только два обозначения; блоки и стрелки) со строгими и четко определенными рекомендациями, в совокупности предназначенными для построения качественной и понятной модели системы.
Методология TDEF0 в некоторой степени напоминает рекомендации, существующие в книгоиздательском деле, часто набор напечатанных моделей IDEF0 организуется в брошюру (называемую в терминах IDEF0 комплект), имеющую содержание, глоссарий и другие элементы, характерные для законченной книги.
Первый шаг при построении модели IDEF0 заключается в определении назначения модели — набора вопросов, на которые должна отвечать модель. Набор вопросов можно сравнить с предисловием, в котором раскрывается назначение книги.
Границы моделирования предназначены для обозначения ширины охвата
предметной области и глубины детализации и являются логическим продолжением
уже определенного назначения модели. Как читающий модель, так и непосред259
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ственно ее автор должны понимать степень детальности ответов на поставленные в
назначении модели вопросы.
Следующим шагом указывается предполагаемая целевая аудитория, для нужд
которой создается модель. Зачастую от выбора целевой аудитории зависит уровень
детализации, с которым должна создаваться модель. Перед построением модели
необходимо иметь представление о том, какие сведения о предмете моделирования
уже известны, какие дополнительные материалы и (или) техническая документация
для понимания модели могут быть необходимы целевой аудитории, какие язык и
стиль изложения являются наиболее подходящими.
Под точкой зрения понимается перспектива, с которой наблюдалась система
при построении модели. Точка зрения выбирается таким образом, чтобы учесть уже
обозначенные границы моделирования и назначение модели. Однажды выбранная
точка зрения остается неизменной для всех элементов модели. При необходимости
могут быть созданы другие модели, отображающие систему с других точек зрения.
Вот несколько примеров точек зрения при построении моделей: клиент, поставщик,
владелец, редактор.
Действия
Действие, обычно в IDEF0 называемое функцией, обрабатывает или переводит
входные параметры (сырье, информацию и т.п.) в выходные. Поскольку модели
IDEF0 представляют систему как множество иерархических (вложенных) функций,
в первую очередь должна быть определена функция, описывающая систему в целом
— контекстная функция.
Функции изображаются на диаграммах как поименованные прямоугольники,
или функциональные блоки. Имена функций в IDEF0 подбираются по сходным правилам с именами действий в IDEF3 — с использованием глаголов или отглагольных
существительных.
Важно
подбирать
имена
таким
образом,
чтобы
они
отражали
систему так, как если бы она обозревалась с точки зрения, выбранной для моделирования.
260
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Границы и связи
Чтобы быть полезным, описание любого блока должно, как минимум, включать в себя описание объектов, которые блок создает в результате своей работы
("выхода"), и объектов, которые блок потребляет или преобразует ("вход").
В IDEF0 также моделируются управление и механизмы исполнения. Под
управлением понимаются объекты, воздействующие на способ, которым блок преобразует вход в выход. Механизм исполнения — объекты, которые непосредственно
выполняют преобразование входа в выход, но не потребляются при этом сами по
себе.
Для отображения категорий информации, присутствующих на диаграммах
IDEF0, существует аббревиатура ICOM, отображающая четыре возможных типа
стрелок:
I (Input) — вход — нечто, что потребляется в ходе выполнения процесса;
С (Control) — управление — ограничения и инструкции, влияющие на ход выполнения процесса;
О (Output) — выход — нечто, являющееся результатом выполнения процесса;
М (Mechanism) — исполняющий механизм — нечто, что используется для выполнения процесса, но не потребляется само по себе. Рис. 2.3 показывает 4 возможных типа стрелок в IDEF0, каждый из типов соединяется со своей стороной функционального блока.
Для названия стрелок, как правило, употребляются имена существительные.
Стрелки могут представлять собой людей, места, вещи, идеи или события. Как и в
случае с функциональными блоками, присвоение имен всем стрелкам на диаграмме
является только необходимым условием для понимания читателем сути изображенного. Отдельное описание каждой стрелки в текстовом виде может оказаться критическим фактором для построения точной и полезной модели.
Стрелки входа. Вход представляет собой сырье, или информацию, потребляемую или преобразуемую функциональным блоком для производства выхода. Стрелки входа всегда направлены в левую сторону прямоугольника, обозначающего в
IDEF0 функциональный блок. Наличие входных стрелок на диаграмме не является
261
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
обязательным, так как возможно, что некоторые блоки ничего не преобразуют и не
изменяют. Примером блока, не имеющего входа, может служить "принятие решения
руководством", где для принятия решения анализируется несколько факторов, но ни
один из них непосредственно не преобразуется и не потребляется в результате принятия какого-либо решения.
Стрелки управления. Стрелки управления отвечают за регулирование того, как
и когда выполняется функциональный блок, и, если он выполняется, какой выход
получается в результате его выполнения. Так как управление контролирует поведение функционального блока для обеспечения создания желаемого выхода, каждый
функциональный блок должен иметь, как минимум, одну стрелку управления.
Стрелки управления всегда входят в функциональный блок сверху.
Управление часто существует в виде правил, инструкций, законов, политики,
набора необходимых процедур или стандартов. Влияя на работу блока, оно непосредственно не потребляется и не трансформируется в результате. Может оказаться,
что целью функционального блока является как раз изменение того или иного правила, инструкции, стандарта и т.п. В этом случае стрелка, содержащая соответствующую информацию, должна рассматриваться не как управление, а как вход
функционального блока.
Управление можно рассматривать как специфический вид входа. В случаях,
когда неясно, относить ли стрелку к входу или к управлению, предпочтительно относить ее к управлению до момента, пока неясность не будет разрешена.
Стрелки выхода. Выход — это продукция или информация, получаемая в результате работы функционального блока. Каждый блок должен иметъ, как минимум,
один выход. Действие, которое не производит никакого четко определяемого выхода, не должно моделироваться вообще (по меньшей мере, должно рассматриваться в
качестве одного из первых кандидатов на исключение из модели).
При моделировании непроизводственных предметных областей выходами, как
правило, являются данные, в каком-либо виде обрабатываемые функциональным
блоком. В этом случае важно, чтобы названия стрелок входа и выхода были достаточно различимы по своему смыслу. Например, блок "Прием пациентов" может
262
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
иметь стрелку "Данные о пациенте" как на входе, так и на выходе. В такой ситуации
входящую стрелку можно назвать "Предварительные данные о пациенте", а исходящую — "Подтвержденные данные о пациенте".
Стрелки механизма исполнения. Механизмы являются ресурсом, который
непосредственно исполняет моделируемое действие.
С помощью механизмов исполнения могут моделироваться: ключевой персонал, техника и (или) оборудование. Стрелки механизма исполнения могут отсутствовать в случае, если оказывается, что они не являются необходимыми для достижения поставленной цели моделирования.
Комбинированные стрелки. ВIDEF0 существует пять основных видов комбинированных стрелок: выход — вход, выход — управление, выход — механизм исполнения, выход — обратная связь на управление и выход — обратная связь на
вход.
Стрелка выход — вход применяется, когда один из блоков должен полностью
завершить работу перед началом работы другого блока.
Так, на рисунке 5.3 формирование счета должно предшествовать приему заказа.
Рисунок 5.3 - Комбинация стрелок выход — вход
Стрелка выход — управление отражает ситуацию преобладания одного блока
над другим, когда один блок управляет работой другого. На рисунке 5.4 принципы
формирования инвестиционного портфеля управляют поведением брокеров на бирже.
263
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 5.4 - Комбинированная стрелка выход — управление
Стрелки выход — механизм исполнения встречаются реже и отражают ситуацию, когда выход одного функционального блока применяется в качестве оборудования для работы другого блока. На рисунке 5.5 устройство, используемое для закрепления детали во время ее сборки, должно быть собрано для того, чтобы выполнить сборку детали.
Рисунок 5.5 - Комбинированная стрелка выход — механизм исполнения
Обратные связи на вход и на управление применяются в случаях, когда зависимые блоки формируют обратные связи для управляющих ими блоков. На рисунке
5.6 получаемая от брокеров информация о текущих биржевых курсах применяется
для корректировки стратегии игры на бирже.
264
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 5.6 - Комбинированная стрелка выход — обратная связь
на управление
Стрелка выход — обратная связь на вход обычно применяется для описания
циклов повторной обработки чего-либо. Рисунок 5.7 может служить примером применения стрелки такого типа. Кроме того, связи выход — обратная связь на вход
могут применяться в случае, если бракованная продукция может заново использоваться в качестве сырья, как это происходит, например, при производстве оконного
стекла, когда разбитое в процессе производства стекло перемалывается и переплавляется заново вместе с обыкновенным сырьем.
Рисунок 5.7 - Комбинированная стрелка выход — обратная связь на вход
Разбиение и соединение стрелок. Выход функционального блока может использоваться в нескольких других блоках. Фактически чуть ли не главная ценность
IDEF0 заключается в том, что эта методология помогает выявить взаимозависимости между блоками системы. Соответственно IDEF0 предусматривает как разбиение, так и соединение стрелок на диаграмме. Разбитые на несколько частей стрелки
могут иметь наименования, отличающиеся от наименования исходной стрелки. Ис265
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ходная и разбитые (или объединенные) стрелки в совокупности называются связанными. Такая техника обычно применяется для того, чтобы отразить использование в
процессе только части сырья или информации, обозначаемых исходной стрелкой
(рисунок 5.8). Аналогичный подход применяется и к объединяемым стрелкам.
Рисунок 5.8 - Разбитая на две части и переименованная стрелка
Туннели
Понятие связанные стрелки используется для управления уровнем детализации диаграмм. Если одна из стрелок диаграммы отсутствует на родительской диаграмме (например, ввиду своей несущественности для родительского уровня) и не
связана с другими стрелками той же диаграммы, точка входа этой стрелки на диаграмму или выхода с нее обозначается туннелем. На рисунке 5.9, например, стрелка
"корпоративная информационная система" — важный механизм исполнения для
данной диаграммы, но, возможно, она более нигде не используется в модели. Туннель в данном случае используется как альтернатива загромождению родительских
диаграмм помещением на них несущественных для их уровня стрелок.
266
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 5.9 - Пример применения туннеля
Кроме того, туннели применяются для отражения ситуации, когда стрелка,
присутствующая на родительской диаграмме, отсутствует в диаграмме декомпозиции соответствующего блока.
На рисунке 5.10 туннель у стрелки "модуль производственного отдела" обозначает, что на диаграмме декомпозиции производственного отдела отсутствует
стрелка механизма управления с соответствующим наименованием.
Рисунок 5.10 - Пример применения туннеля
267
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Построение моделей IDEF0
В этом подразделе мы рассмотрим методику построения моделей IDEF0 более
подробно.
На рисунке 5.11 типовая диаграмма IDEF0 показана вместе с находящейся на
ее полях служебной информацией. Служебная информация состоит из хорошо выделенных верхнего и нижнего колонтитулов (заголовка и "подвала"). Элементы заголовка используются для отслеживания процесса создания модели. Элементы
"подвала" отображают наименование модели, к которой относится диаграмма, и показывают ее расположение относительно других диаграмм модели.
Рисунок 5.11 - IDEF0-диаграмма со служебной информацией на полях
268
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Все элементы заголовка диаграммы перечислены в таблице 5.1.
Таблица 5.1 - Элементы заголовка диаграммы IDEF0
Поле
USED AT
Author, date,
project
Назначение
Используется для отражения внешних ссылок на данную
диаграмму (заполняется на печатном документе вручную)
Содержит ФИО автора диаграммы, дату создания, дату последнего внесения изменений, наименование проекта, в
рамках которого она создавалась
Notes 1 ... 10
При ручном редактировании диаграмм пользователи могут
зачеркивать цифру каждый раз, когда они вносят очередное
исправление
Status
Статус отражает состояние разработки или утверждения
данной диаграммы. Это поле используется для реализации
формального процесса публикации с шагами пересмотра и
утверждения
Working
Publication
Новая диаграмма, глобальные изменения или новый автор
для существующей диаграммы
Диаграмма достигла некоторого приемлемого для читателей
уровня и готова для представления на утверждение
Диаграмма одобрена и утверждена. Какие-либо изменения
не предвидятся
Диаграмма готова для окончательной печати и публикации
Reader
ФИО читателя
Date
Дата знакомства читателя с диаграммой
Context
Набросок расположения функциональных блоков на родительской диаграмме, на котором подсвечен декомпозируемый данной диаграммой блок. Для диаграммы самого верхнего уровня (контекстной диаграммы) в поле помещается контекст ТОР
Draft
Recommended
Все элементы "подвала" диаграммы перечислены в таблице 5.2.
269
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Таблица 5.2 - Элементы "подвала" диаграммы IDEF0
Поле
Node
Title
Number
(еще называют СNumber)
Назначение
Номер диаграммы, совпадающий с номером родительского
функционального блока.
Имя родительского функционального блока.
Уникальный идентификатор данной версии данной диаграммы.
Таким образом, каждая новая версия данной диаграммы будет
иметь новое значение в этом поле. Как правило, C-Number состоит из инициалов автора (которые предполагаются уникальными среди всех аналитиков проекта) и последовательного
уникального идентификатора, например SDO005. При публикации эти номера могут быть заменены стандартными номерами страниц. Если диаграмма замещает другую диаграмму, номер заменяемой диаграммы может быть заключен в скобки —
SDO005 (SDO004). Это обеспечивает хранение истории изменений всех диаграмм модели.
Моделирование деловых процессов, как правило, выполняется с помощью
case-средств. К таким средствам относятся BPwin (PLATINUM technology), Silverrun
(Silverrun technology), Oracle Designer (Oracle), Rational Rose (Rational Software) и др.
Функциональные возможности инструментальных средств структурного моделирования деловых процессов будут рассмотрены на примере case-средства BPwin.
BPwin поддерживает три методологии моделирования: функциональное моделирование (IDEF0); описание бизнес-процессов (IDEF3); диаграммы потоков данных (DFD).
Инструментальная среда BPwin
BPwin имеет достаточно простой и интуитивно понятный интерфейс пользователя. При запуске BPwin по умолчанию появляется основная панель инструментов, палитра инструментов (вид которой зависит от выбранной нотации) и, в левой
части, навигатор модели — Model Explorer (рисунок 5.12).
270
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
При создании новой модели возникает диалог, в котором следует указать, будет ли создана модель заново или она будет открыта из файла либо из репозитария
ModelMart, затем внести имя модели и выбрать методологию, в которой будет построена модель (рисунок 5.13).
Как было указано выше, BPwin поддерживает три методологии — IDEF0,
IDEF3 и DFD, каждая из которых решает свои специфические задачи. В BPwin возможно построение смешанных моделей, т. е. модель может содержать одновременно
диаграммы как IDEF0, так и IDEF3 и DFD.
Состав палитры инструментов изменяется автоматически, когда происходит
переключение с одной нотации на другую.
Рисунок 5.12 - Интегрированная среда разработки модели BPwin
271
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 5.13 - Диалоговое окно создания модели
Модель в BPwin рассматривается как совокупность работ, каждая из которых
оперирует с некоторым набором данных. Работа изображается в виде прямоугольников, данные — в виде стрелок. Если щелкнуть по любому объекту модели левой
кнопкой мыши, появляется контекстное меню, каждый пункт которого соответствует редактору какого-либо свойства объекта.
На начальных этапах создания ИС необходимо понять, как работает организация, которую собираются автоматизировать. Руководитель хорошо знает работу в
целом, но не в состоянии вникнуть в детали работы каждого рядового сотрудника.
Рядовой сотрудник хорошо знает, что творится на его рабочем месте, но может не
знать, как работают коллеги. Поэтому для описания работы предприятия необходимо построить модель, которая будет адекватна предметной области и содержать в
себе знания всех участников бизнес-процессов организации.
272
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Наиболее удобным языком моделирования бизнес-процессов является IDEF0,
где система представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной — функции
системы анализируются независимо от объектов, которыми они оперируют. Это
позволяет более четко смоделировать логику и взаимодействие процессов организации.
Процесс моделирования системы в IDEF0 начинается с создания контекстной
диаграммы — диаграммы наиболее абстрактного уровня описания системы в целом,
содержащей определение субъекта моделирования, цели и точки зрения на модель.
Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами, другими словами, определить, что будет в дальнейшем рассматриваться как компоненты системы, а что как
внешнее воздействие. На определение субъекта системы будут существенно влиять
позиция, с которой рассматривается система, и цель моделирования — вопросы, на
которые построенная модель должна дать ответ. Другими словами, в начале необходимо определить область моделирования. Описание области как системы в целом,
так и ее компонентов является основой построения модели. При формулировании
области необходимо учитывать два компонента — широту и глубину. Широта подразумевает определение границ модели — что будет рассматриваться внутри системы, а что снаружи. Глубина определяет, на каком уровне детализации модель является завершенной. При определении глубины системы необходимо помнить об
ограничениях времени — трудоемкость построения модели растет в геометрической
прогрессии с увеличением глубины декомпозиции. После определения границ модели предполагается, что новые объекты не должны вноситься в моделируемую систему.
Цель моделирования определяется из ответов на следующие вопросы:
Почему этот процесс должен быть смоделирован?
Что должна показывать модель?
Что может получить клиент?
273
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Точка зрения (Viewpoint)
Под точкой зрения понимается перспектива, с которой наблюдалась система
при построении модели. Хотя при построении модели учитываются мнения различных людей, все они должны придерживаться единой точки зрения на модель. Точка
зрения должна соответствовать цели и границам моделирования. Как правило, выбирается точка зрения человека, ответственного за моделируемую работу в целом.
IDEF0-модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения. Для внесения области, цели и точки зрения в модели IDEF0 в BPwin следует выбрать пункт меню Model/Model Properties, вызывающий диалог Model Properties (рисунок 5.14). В закладке
Purpose следует внести цель и точку зрения, а в закладку Definition — определение
модели и описание области.
Рисунок 5.14 - Диалог задания свойств модели
274
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Основу методологии IDEF0 составляет графический язык описания бизнеспроцессов. Модель в нотации IDEF0 представляет собой совокупность иерархически
упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма является единицей
описания системы и располагается на отдельном листе.
Модель может содержать четыре типа диаграмм:
контекстную диаграмму(в каждой модели может быть только одна контекстная диаграмма);
диаграммы декомпозиции;
диаграммы дерева узлов;
диаграммы только для экспозиции (FEO).
Контекстная диаграмма является вершиной древовидной структуры диаграмм
и представляет собой самое общее описание системы и ее взаимодействия с внешней средой. После описания системы в целом проводится разбиение ее на крупные
фрагменты. Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции. После декомпозиции контекстной диаграммы
проводится декомпозиция каждого большого фрагмента системы на более мелкие и
так далее, до достижения нужного уровня подробности описания. После каждого сеанса декомпозиции проводятся сеансы экспертизы — эксперты предметной области
указывают на соответствие реальных бизнес-процессов созданным диаграммам.
Найденные несоответствия исправляются, и только после прохождения экспертизы
без замечаний можно приступать к следующему сеансу декомпозиции. Так достигается соответствие модели реальным бизнес-процессам на любом и каждом уровне
модели. Синтаксис описания системы в целом и каждого ее фрагмента одинаков во
всей модели.
Диаграмма дерева узлов показывает иерархическую зависимость работ, но не
взаимосвязи между работами. Диаграмм деревьев узлов может быть в модели сколь
угодно много, поскольку дерево может быть построено на произвольную глубину и
не обязательно с корня.
275
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Диаграммы для экспозиции (FEO)строятся для иллюстрации отдельных фрагментов модели, для иллюстрации альтернативной точки зрения, либо для специальных целей.
Работы (Activity)обозначают поименованные процессы, функции или задачи,
которые происходят в течение определенного времени и имеют распознаваемые результаты. Работы изображаются в виде прямоугольников. Все работы должны быть
названы и определены. Имя работы должно быть выражено отглагольным существительным, обозначающим действие (например, "Деятельность компании", "Прием заказа" и т.д.). Работа "Деятельность компании" может иметь, например, следующее определение: "Это учебная модель, описывающая деятельность компании".
При создании новой модели (меню File/New) автоматически создается контекстная
диаграмма с единственной работой, изображающей систему в целом (рисунок 5.15).
Рисунок 5.15 - Пример контекстной диаграммы
276
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Для внесения имени работы следует щелкнуть по работе правой кнопкой мыши, выбрать в меню Name Editor и в появившемся диалоге внести имя работы. Для
описания других свойств работы служит диалог Activity Properties (рисунок 5.16).
Рисунок 5.16 - Редактор задания свойств работы
Диаграммы декомпозиции содержат родственные работы, т. е. дочерние работы, имеющие общую родительскую работу. Для создания диаграммы декомпозиции
следует щелкнуть по кнопке
на панели инструментов.
Возникает диалог Activity Box Count (рисунок 5.17), в котором следует указать
нотацию новой диаграммы и количество работ на ней. Остановимся пока на нотации
IDEF0 и щелкнем на ОК. Появляется диаграмма декомпозиции (рисунок 5.18).
Допустимый интервал числа работ — 2-8. Декомпозировать работу на одну
работу не имеет смысла: диаграммы с количеством работ более восьми получаются
перенасыщенными и плохо читаются. Для обеспечения наглядности и лучшего понимания моделируемых процессов рекомендуется использовать от трех до шести
блоков на одной диаграмме.
277
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 5.17 - Диалог Activity Box Count
Рисунок 5.18 - Пример диаграммы декомпозиции
Если оказывается, что количество работ недостаточно, то работу можно добавить в диаграмму, щелкнув сначала по кнопке на палитре инструментов, а затем по
свободному месту на диаграмме.
278
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Работы на диаграммах декомпозиции обычно располагаются по диагонали от
левого верхнего угла к правому нижнему.
Такой порядок называется порядком доминирования. Согласно этому принципу расположения в левом верхнем углу помещается самая важная работа или работа,
выполняемая по времени первой. Далее вправо вниз располагаются менее важные
или выполняемые позже работы. Такое размещение облегчает чтение диаграмм,
кроме того, на нем основывается понятие взаимосвязей работ.
5.3 Метод описания диаграммы потоков данных
Диаграммы потоков данных (Data Flow Diagramming) являются основным
средством моделирования функциональных требований к проектируемой системе.
Требования представляются в виде иерархии процессов, связанных потоками данных. Диаграммы потоков данных показывают, как каждый процесс преобразует
свои входные данные в выходные, и выявляют отношения между этими процессами.
DFD-диаграммы успешно используются как дополнение к модели IDEF0 для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет
моделируемую систему как сеть связанных работ. Основные компоненты DFD (как
было сказано выше) – процессы или работы, внешние сущности, потоки данных,
накопители данных (хранилища).
В BPwin для построения диаграмм потоков данных используется нотация
Гейна-Сарсона.
Для того чтобы дополнить модель IDEF0 диаграммой DFD, нужно в процессе
декомпозиции в диалоге Activity Box Count «кликнуть» по радио-кнопке DFD. В палитре инструментов на новой диаграмме DFD появляются новые кнопки:
(External Reference) — добавить в диаграмму внешнюю ссылку;
(Data store) — добавить в диаграмму хранилище данных;
Diagram Dictionary Editor – ссылка на другую страницу. В отличие от
IDEF0 этот инструмент позволяет направить стрелку на любую диаграмму (а не
только на верхний уровень).
279
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
В отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как объекты (включая данные) двигаются от одной
работы к другой. Это представление потоков совместно с хранилищами данных и
внешними сущностями делает модели DFD более похожими на физические характеристики системы — движение объектов, хранение объектов, поставка и распространение объектов (рисунок 5.19).
В отличие от IDEF0, где система рассматривается как взаимосвязанные работы, DFD рассматривает систему как совокупность предметов. Контекстная диаграмма часто включает работы и внешние ссылки. Работы обычно именуются по названию системы, например «Система обработки информации». Включение внешних
ссылок в контекстную диаграмму не отменяет требования методологии четко определить цель, область и единую точку зрения на моделируемую систему.
Рисунок 5.19 - Пример диаграммы DFD
В DFD работы (процессы) представляют собой функции системы, преобразующие входы в выходы. Хотя работы изображаются прямоугольниками со скругленными углами, смысл их совпадает со смыслом работ IDEF0 и IDEF3. Так же, как
процессы IDEF3, они имеют входы и выходы, но не поддерживают управления и
механизмы, как IDEF0.
280
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Внешние сущности изображают входы в систему и/или выходы из системы.
Внешние сущности изображаются в виде прямоугольника с тенью и обычно располагаются по краям диаграммы (блок «Звонки клиентов). Одна внешняя сущность
может быть использована многократно на одной или нескольких диаграммах.
Обычно такой прием используют, чтобы не рисовать слишком длинных и запутанных стрелок.
Потоки работ изображаются стрелками и описывают движение объектов из
одной части системы в другую. Поскольку в DFD каждая сторона работы не имеет
четкого назначения, как в IDEF0, стрелки могут подходить и выходить из любой
грани прямоугольника работы. В DFD также применяются двунаправленные стрелки для описания диалогов типа «команда-ответ» между работами, между работой и
внешней сущностью и между внешними сущностями.
В отличие от стрелок, описывающих объекты в движении, хранилища данных
изображают объекты в покое (рисунок 5.20).
Рисунок 5.20 - Хранилище данных
В материальных системах хранилища данных изображаются там, где объекты
ожидают обработки, например в очереди. В системах обработки информации хранилища данных являются механизмом, который позволяет сохранить данные для последующих процессов.
В DFD стрелки могут сливаться и разветвляться, что позволяет описать декомпозицию стрелок. Каждый новый сегмент сливающейся или разветвляющейся
стрелки может иметь собственное имя.
Диаграммы DFD могут быть построены с использованием традиционного
структурного анализа, подобно тому, как строятся диаграммы IDEF0.
В DFD номер каждой работы может включать префикс, номер родительской
работы (А) и номер объекта. Номер объекта — это уникальный номер работы на
диаграмме. Например, работа может иметь номер А.12.4. Уникальный номер имеют
281
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
хранилища данных и внешние сущности независимо от их расположения на диаграмме. Каждое хранилище данных имеет префикс D и уникальный номер, например D5. Каждая внешняя сущность имеет префикс Е и уникальный номер, например
Е5.
5.4 Метод описания процессов IDEF3
Наличие в диаграммах DFD элементов для обозначения источников, приемников и хранилищ данных позволяет более эффективно и наглядно описать процесс
документооборота. Однако для описания логики взаимодействия информационных
потоков более подходит IDEF3, называемая также workflow diagramming, — методология моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов. Диаграммы Workflow могут быть использованы в
моделировании бизнес-процессов для анализа завершенности процедур обработки
информации. С их помощью можно описывать сценарии действий сотрудников организации, например последовательность обработки заказа или события, которые
необходимо обработать за конечное время. Каждый сценарий сопровождается описанием процесса и может быть использован для документирования каждой функции.
IDEF3 — это метод, имеющий основной целью дать возможность аналитикам
описать ситуацию, когда процессы выполняются в определенной последовательности, а также описать объекты, участвующие совместно в одном процессе.
Техника описания набора данных IDEF3 является частью структурного анализа. В отличие от некоторых методик описаний процессов IDEF3 не ограничивает
аналитика чрезмерно жесткими рамками синтаксиса, что может привести к созданию неполных или противоречивых моделей.
IDEF3 может быть также использован как метод создания процессов. IDEF3
дополняет IDEF0 и содержит все необходимое для построения моделей, которые в
дальнейшем могут быть использованы для имитационного анализа.
Каждая работа в IDEF3 описывает какой-либо сценарий бизнес-процесса и
может являться составляющей другой работы. Поскольку сценарий описывает цель
282
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
и рамки модели, важно, чтобы работы именовались отглагольным существительным, обозначающим процесс действия, или фразой, содержащей такое существительное.
Точка зрения на модель должна быть документирована. Обычно это точка
зрения человека, ответственного за работу в целом. Также необходимо документировать цель модели — те вопросы, на которые призвана ответить модель.
Диаграмма является основной единицей описания в IDEF3. Важно правильно
построить диаграммы, поскольку они предназначены для чтения другими людьми (а
не только автором).
Единицы работы — Unit of Work (UOW) — также называемые работами
(activity), являются центральными компонентами модели. В IDEF3 работы изображаются прямоугольниками с прямыми углами и имеют имя, выраженное отглагольным существительным, обозначающим процесс действия, одиночным или в составе
фразы, и номер (идентификатор); другое имя существительное в составе той же фразы обычно отображает основной выход (результат) работы (например, «Изготовление изделия»). Часто имя существительное в имени работы меняется в процессе моделирования, поскольку модель может уточняться и редактироваться. Идентификатор работы присваивается при создании и не меняется никогда. Даже если работа
будет удалена, ее идентификатор не будет вновь использоваться для других работ.
Обычно номер работы состоит из номера родительской работы и порядкового номера на текущей диаграмме.
Связи показывают взаимоотношения работ. Все связи в IDEF3 однонаправлены и могут быть направлены куда угодно, но обычно диаграммы IDEF3 стараются
построить так, чтобы связи были направлены слева направо.
283
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
В IDEF3 различают три типа стрелок, изображающих связи, стиль которых
устанавливается через меню Edit/Arrow Style:
Старшая (Precedence)
сплошная линия, связывающая единицы работ (UOW). Рисуется слева направо
или сверху вниз. Показывает, что работа-источник должна закончиться прежде, чем
работа-цель начнется.
Отношения (Relational Link)
пунктирная линия, использующаяся для изображения связей между единицами работ (UOW) а также между единицами работ и объектами ссылок.
Потоки объектов (Object Flow)
стрелка с двумя наконечниками, применяется для описания того факта, что
объект используется в двух или более единицах работы, например, когда объект порождается в одной работе и используется в другой.
Старшая связь показывает, что работа-источник заканчивается ранее, чем
начинается работа-цель. Часто результатом работы-источника становится объект,
необходимый для запуска работы-цели. В этом случае стрелку, обозначающую объект, изображают с двойным наконечником. Имя стрелки должно ясно идентифицировать отображаемый объект. Поток объектов имеет ту же семантику, что и старшая
стрелка.
Отношение показывает, что стрелка является альтернативой старшей стрелке
или потоку объектов в смысле задания последовательности выполнения работ —
работа-источник не обязательно должна закончиться, прежде чем работа-цель
начнется. Более того, работа-цель может закончиться прежде, чем закончится работа-источник.
Окончание одной работы может служить сигналом к началу нескольких работ,
или же одна работа для своего запуска может ожидать окончания нескольких работ.
Для отображения логики взаимодействия стрелок при слиянии и разветвлении или
284
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
для отображения множества событий, которые могут или должны быть завершены
перед началом следующей работы, используются перекрестки (Junction). Различают
перекрестки для слияния (Fan-in Junction) и разветвления стрелок (Fan-out Junction).
Перекресток не может использоваться одновременно для слияния и для разветвления. Для внесения перекрестка служит кнопка — (добавить в диаграмму перекресток — Junction) в палитре инструментов. В диалоге Select Junction Type необходимо указать тип перекрестка. Смысл каждого типа приведен в таблице 5.3.
Все перекрестки на диаграмме нумеруются, каждый номер имеет префикс J.
Можно редактировать свойства перекрестка при помощи диалога Junction Properties,
который вызывается в контекстном меню перекрестка командой Definition/Note. В
отличие от IDEF0 и DFD в IDEF3 стрелки могут сливаться и разветвляться только
через перекрестки.
Объект ссылки в IDEF3 выражает некую идею, концепцию или данные, которые нельзя связать со стрелкой, перекрестком или работой. Для внесения объекта
ссылки служит кнопка — (добавить в диаграмму объект ссылки — Referent) в палитре инструментов.
Объект ссылки изображается в виде прямоугольника, похожего на прямоугольник работы.
Имя объекта ссылки задается в диалоге Referent (пункт Name контекстного
меню), в качестве имени можно использовать имя какой-либо стрелки с других диаграмм или имя сущности из модели данных. Объекты ссылки должны быть связаны
с единицами работ или перекрестками пунктирными линиями. Официальная спецификация IDEF3 различает три стиля объектов ссылок — безусловные (unconditional),
синхронные (synchronous) и асинхронные (asynchronous). BPwin поддерживает только безусловные объекты ссылок. Синхронные и асинхронные объекты ссылок, используемые в диаграммах переходов состояний объектов, не поддерживаются.
285
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Таблица 5.3 - Типы перекрестков
Смысл в случае разветвления стрелок (Fan-out
Junction)
Asynchronous Все предшествующие про- Все следующие процесAND
цессы должны быть завер- сы должны быть запушены
щены
Synchronous
Все предшествующие про- Все следующие процесAND
цессы завершены одновре- сы запускаются одноменно
временно
Asynchronous Один или несколько пред- Один или несколько
OR
шествующих процессов
следующих процессов
должны быть завершены
должны быть запущены
Synchronous
Один или несколько пред- Один или несколько
OR
шествующих процессов за- следующих процессов
вершены одновременно
запускаются одновременно
XOR
Только один предшествую- Только один следующий
(Exclusive OR) щий процесс завершен
процесс запускается
Смысл в случае слияния
Обозначение Наименование
стрелок (Fan-in Junction)
При внесении объектов ссылок помимо имени следует указывать тип объекта
ссылки. Типы объектов ссылок приведены в таблице 5.4.
В IDEF3 декомпозиция используется для детализации работ. Методология
IDEF3 позволяет декомпозировать работу многократно, т. е. работа может иметь
множество дочерних работ. Это позволяет в одной модели описать альтернативные
потоки. Возможность множественной декомпозиции предъявляет дополнительные
требования к нумерации работ. Так, номер работы состоит из номера родительской
работы, версии декомпозиции и собственного номера работы на текущей диаграмме.
Рассмотрим процесс декомпозиции диаграмм IDEF3, включающий взаимодействие автора (аналитика) и одного или нескольких экспертов предметной области.
Перед проведением сеанса экспертизы у экспертов предметной области должны быть документированные сценарии и рамки модели, для того чтобы понять цели
декомпозиции. Обычно эксперт предметной области передает аналитику текстовое
описание сценария. В дополнение к этому может существовать документация, описывающая интересующие процессы. Из этой информации аналитик должен соста286
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
вить предварительный список работ (отглагольные существительные, обозначающие процесс) и объектов (существительные, обозначающие результат выполнения
работы), которые необходимы для перечисленных работ. В некоторых случаях целесообразно создать графическую модель для представления ее эксперту предметной
области.
Таблица 5.4 - Типы объектов ссылок
Тип объекта
Цель описания
ссылки
OBJECT
Описывает участие важного объекта в работе
GOTO
Инструмент циклического перехода (в повторяющейся последовательности работ), возможно на текущей диаграмме, но не обязательно. Если все работы цикла присутствуют на текущей диаграмме,
цикл может также изображаться стрелкой, возвращающейся на стартовую работу. GOTO может ссылаться на перекресток
UOB (Unit of Применяется, когда необходимо подчеркнуть множественное исbehaviour)
пользование какой-либо работы, но без цикла. Например, работа
«Контроль качества» может быть использована в процессе «Изготовление изделия» несколько раз, после каждой единичной операции.
Обычно этот тип ссылки не используется для моделирования автоматически запускающихся работ
NOTE
Используется для документирования важной информации, относящейся к каким-либо графическим объектам на диаграмме. NOTE является альтернативой внесению текстового объекта в диаграмму
ELAB
Используется для усовершенствования графиков или их более де(Elaboration) тального описания. Обычно употребляется для детального описания
разветвления и слияния стрелок на перекрестках
На рисунке 5.21 представлено описание процесса «Сборка настольных компьютеров» в методологии IDEF3.
Поскольку разные фрагменты модели IDEF3 могут быть созданы разными
группами аналитиков в разное время, IDEF3 поддерживает простую схему нумерации работ в рамках всей модели. Разные аналитики оперируют разными диапазонами номеров, работая при этом независимо. Пример выделения диапазона приведен в
таблице 5.5.
В результате дополнения диаграмм IDEF0 диаграммами DFD и IDEF3 может
быть создана смешанная модель, которая наилучшим образом описывает все сторо287
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ны деятельности предприятия. Иерархию работ в смешанной модели можно увидеть
в окне Model Explorer (рисунок 5.22).
Таблица 5.5 - Диапазоны номеров
работ
АнаИва-
Диапазон номеров
IDEF3
1-999
Пет-
1000-1999
Си-
2000-2999
литик
нов
ров
доров
Рисунок 5.21 - Описание процесса в методологии IDEF3
288
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 5.22 - Представление смешанной модели в окне Model Explorer
Модели в нотации IDEF0 изображаются зеленым цветом, в IDEF3 — желтым,
в DFD — голубым.
289
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
6 Развитие гибридных объектно-реляционных баз данных на
основе фреймово-слотовой нормальной формы
Одним из направлений развития современных баз данных является использование метода разработки гибридной объектно-реляционной базы данных на основе
описания семантических сетей с фреймами и слотами в вершинах.
Современные способы разработки и создания баз данных, основанные на традиционной теории реляционных баз данных, ограничены для современных масштабов по объему и форме обрабатываемой информации. В реляционных базах данных
не допускается хранение и обработка массивов информации, так как нарушаются
требования нормализации по первой нормальной форме. Предлагаемый метод разработки и создания баз данных основан не на традиционной теории реляционных
баз данных, а на теории концептуального моделирования систем организационного
управления. В основе метода лежит процесс описания семантической сети, в вершинах которой находятся фреймы и слоты (рисунок 6.1).
Условные обозначения:
Иерархия
рабочих
мест
РМ
РМ
РМ
Интерпритация на уровне
принятия решений
РМ ... РМ
РМ ... РМ
РМ ... РМ
РОЛЬ
Интерпритация на уровне
документооборота
-межфреймовые связи
внутри рабочего места
-межфреймовые связи между
рабочими местами
-фрейм
РМ
.
. . .
.
-слот
.
РМ
-рабочее место
РОЛЬ
Данные
Действия
Лицо
Правила
выбора
действий
Мотивы,
стимулы,
приоритет
связи по лицам
РОЛЬ
РОЛЬ
Рисунок 6.1 - Концептуальная модель базы данных
290
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Одним из элементов новизны предлагаемого метода заключается в новом
представлении информационно-логической и даталогической моделей базы данных.
В теории реляционных баз данных информационно-логическая модель представляется в виде ER-диаграммы (диаграммы сущность - связь) или в виде семантической
объектной модели. В предлагаемом способе информационно-логическая модель
представляется в виде логической модели объектно-реляционной базы данных (рисунок 6.2).
Рисунок 6.2 - Фреймово – слотовая модель базы данных
Фреймы и слоты интерпретируются в гиперкубы. В структуре гиперкубов
находятся массивы информации (рисунок 6.3).
291
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Фрейм
название
фрейма
значение
фрейма
указатель
указатель
название
фрейма
Гиперкуб фрейма
значение
фрейма
название
слота
Слот
значение
слота
указатель
указатель
название
слота
Гиперкуб слота
значение
слота
Массив М: {2; ± ∞}
указатель название
значение
Рисунок 6.3 - Интерпретация гиперкубов в табличные массивы
В настоящее время применяются три способа хранения данных: MOLAP (Multidimensional OLAP), ROLAP (Relational OLAP) и HOLAP (Hybrid OLAP). Гибридная
292
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
объектно-реляционная база данных на основе фреймов и слотов позволяет совместить достоинства и минимизировать недостатки, присущие предыдущим классам:
они объединяют аналитическую гибкость и скорость ответа MOLAP с постоянным
доступом к реальным данным, свойственным ROLAP. В случае использования гибридной архитектуры (HOLAP) исходные данные остаются в реляционной базе, а
агрегаты размещаются в многомерной. Построение OLAP-куба выполняется по запросу OLAP-средства на основе реляционных и многомерных данных. Такой подход
позволяет избежать взрывного роста данных. При этом можно достичь оптимального времени исполнения клиентских запросов.
Преимущества средств объектно-ориентированного проектирования и программирования позволяют не только успешно моделировать организационные
структуры в виде систем объектов (агентов), но также строить и динамически развивающиеся структуры. Агентную систему формально можно описать как объединение множества типов данных Т, алфавита событий X, множества идентификаторов
объектов I, классов (объектных моделей) С и объектов О (европейская нотация по
объектно-ориентированному программированию ЕССОР): S = (Т, X, I, С,О).
Направлением развития предлагаемого метода является исследование и реализация ссылок на фреймы и слоты. Например, типы данных в С# разделяют по
способу хранения элементов на типы-значения и ссылочные типы (рисунок 6.4).
Рисунок 6.4 - Классификация типов данных в С# по способу хранения
293
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Элементы типов-значений, или значимых типов (value types), представляют
собой просто последовательность битов в памяти, необходимый объем которой выделяет компилятор. Иными словами, величины значимых типов хранят свои значения непосредственно. Величина ссылочного типа хранит не сами данные, а ссылку
на них (адрес, по которому расположены данные). Сами данные хранятся в хипе.
Несмотря на различия в способе хранения, и типы-значения, и ссылочные типы являются потомками общего базового класса Object.
Методику разработки и создания многомерной базы данных рассмотрим на
конкретном примере.
Постановка задачи: необходимо разработать и создать автоматизированную
информационную систему (АИС) оценки и соизмерения качества однотипной продукции или услуг.
На основе концептуального моделирования информационная интерпретация
АИС может быть представлена в виде семантической модели (рисунок 6.5).
Рисунок 6.5 – Семантическая модель данных
294
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Для хранения названий проектов проведения оценки качества реализован массив NameProject. Каждый проект несет в себе определенный набор глобальных переменных (B, K, L), которые необходимо хранить в массивах BProject, LProject,
KProject. Индексы последних массивов ссылаются на основной массив NameProject
(рисунок 6.6).
NameProject
Индекс
Значение (имя проекта)
BProject
Индекс
Значение (переменная B)
LProject
Индекс
Значение (переменная L)
KProject
Индекс
Значение (переменная K)
Рисунок 6.6 – Массивы для хранения переменных проекта оценки качества
Реализация данной структуры в традиционных таблицах РБД представлена на
рисунке 6.7.
Рисунок 6.7 – Схема связи таблиц с проектными переменными
295
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Для хранения произведенных замеров характеристик образцов в проекте
оценки необходима организация многомерной структуры данных (рисунок 6.8).
Образец
Проект
Значение
параметра
Параметр
Рисунок 6.8 – Гиперкуб ―Замеры характеристик‖
Реализация конечной структуры в традиционных таблицах РБД представлена
на рисунке 6.9.
Рисунок 6.9 – Реализация конечной структуры
296
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Далее производится программная реализация, которая направлена на разработку приложения АИС ―Оценка качества образцов‖.
Для запуска приложения ―Программная система оценки качества‖ необходимо
запустить файл-приложение ―Quality.exe‖ в каталоге программы.
На рисунке 6.10 показ пример результата оценки качества двух образцов и
его представление в виде столбчатой диаграммы.
Рисунок 6.10 - Результат оценки качества
Рассматриваемый
метод
можно
использовать при разработке
OLAP-
продуктов, которые в настоящее время очень актуальны в системах поддержки принятия решений и весьма разнообразны по структуре. Аналитические модули появились в составе пакетов финансово-производственных приложений SAP R/3, Oracle
Applications и других. Одновременно с лидерами мирового рынка подобные модули
включили в свои системы российские фирмы «Парус» и «АйТи».
297
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Список использованных источников
1 Советов, Б. Я. Базы данных: теория и практика: учеб. для бакалавров / Б. Я.
Советов, В. В. Цехановский, В. Д. Чертовской.- 2-е изд. - М. : Юрайт, 2012. - 464 с.
2 Кузин, А. В. Базы данных: учеб. пособие / А. В. Кузин, С. В. Левонисова.- 2-е
изд., стер. - М. : Академия, 2008. - 316 с.
3 Хомоненко, А. Д. Базы данных: учеб. для вузов / А. Д. Хомоненко, В. М. Цыганков, М. Г. Мальцев; под ред. А. Д. Хомоненко.- 6-е изд. - СПб. : КОРОНА-Век,
2010. - 736 с. : ил.
4 Пирогов, В.Ю. SQL Server 2005: Программирование клиент-серверных приложений / В.Ю. Пирогов – СПб.: БХВ-Петербург, 2006. – 336 с.: ил.
5 Соловьев, Н.А. Концепция фреймово - слотовой нормальной формы базы данных для систем управления: Материалы всероссийской научно-практической конференции / Н.А. Соловьев, С.А. Щелоков. – Оренбург, ИПК ГОУ ОГУ, 2004.
6 Стогний, А. А. Построение концептуальной модели систем управления / А.А.
Строгний, С. С. Азаров, Я. И. Барсук // УСиМ. - 1988, № 2.
7 Соловьев, Н.А. Автоматизация проектирования баз данных на основе фреймово - слотовой нормальной формы: монография / [авт. кол.: Соловьев Н.А., Семенов А.М., Щелоков С.А.] // Инновационные технологии управления. Материалы
международного научного симпозиума «Наука в жизни современного человека»
[коллектив авторов]- В 2 книгах. Кн. 2. – Одесса: КУПРИЕНКО СВ, 2013 – 116с.: ил.
табл. С. 66 – 92.
8 Черемных, С.В. Моделирование и анализ систем. IDEF – технологии: практикум / С.В.Черемных - М.: Финансы и статистика, 2006. – 192 с.: ил.- (Прикладные
информационные технологии).
9 Павловская, Т.А. С#. Программирование на языке высокого уровня: учебник
для вузов / Т.А. Павловская – СПб.: Питер, 2008. – 432 с.: ил.
10 Кренке, Д. Теория и практика построения баз данных./ Д. Кренке - 8-е изд.
СПб.: Питер, 2003. – 800с.: ил.
298
Документ
Категория
Информатика
Просмотров
2 126
Размер файла
5 113 Кб
Теги
данных, базы
1/--страниц
Пожаловаться на содержимое документа