Добавить в коллекции Добавить в сохраненное
  1. Инженерия
  2. Информатика
  3. Базы данных

3.2. Нормализация отношений реляционных баз данных

реклама 
ФИНАНСОВАЯ АКАДЕМИЯ ПРИ ПРАВИТЕЛЬСТВЕ РОССИЙСКОЙ ФЕДЕРАЦИИ
Кафедра информационных технологий
Э.Г. ДАДЯН
ПРОЕКТИРОВАНИЕ СОВРЕМЕННЫХ БАЗ ДАННЫХ
Учебно-методическое пособие
Рекомендовано УМО по образованию в области финансов,
учета и мировой экономки в качестве учебного пособия
для студентов, обучающихся по специальностям:
"Финансы и кредит", "Бухгалтерский учет, анализ и аудит",
"Мировая экономика", "Налоги и налогообложение"
Москва 2007
3
Содержание
Введение. .................................................................................................................. 7
1. Базы данных и СУБД ........................................................................................ 8
1.2. Концепция баз данных. Архитектура СУБД ...................................... 10
1.2.1. Инфологическая модель данных ......................................................... 12
1.2.2. Даталогическая модель данных .......................................................... 14
1.2.3. Физическая модель данных ................................................................ 14
1.3. Типы датологических моделей данных ................................................ 15
1.3.1. Иерархическая даталогическая модель ............................................. 15
1.3.2. Сетевая даталогическая модель ......................................................... 17
1.3.3. Даталогическая модель на основе инвертированных списков ....... 17
1.3.4. Реляционная даталогическая модель ................................................. 18
1.3.5. Объектно- реляционная даталогическая модель ............................. 21
2. Реляционные базы данных ............................................................................. 21
2.1. Основные понятия реляционных баз данных.................................... 21
2.1.1. Тип данных ............................................................................................ 22
2.1.2. Домен ..................................................................................................... 23
2.1.3. Схема отношения, схема базы данных ............................................... 23
4
2.1.4. Кортеж, отношение .............................................................................. 24
2.2. Целостность реляционных баз данных ............................................... 25
2.3. Основные свойства отношений реляционных баз данных ............. 27
2.3.1 . Отсутствие кортежей-дубликатов...................................................... 27
2.3.2 . Отсутствие упорядоченности кортежей ............................................ 27
2.3.3 . Отсутствие упорядоченности атрибутов ......................................... 28
2.3.4 . Атомарность значений атрибутов ..................................................... 28
3. Операции над таблицами реляционных баз данных ................................. 30
3.1. Некоторые операции теории множеств .............................................. 31
3.1.1. Ограничение отношения .................................................................. 31
3.1.2. Проекция отношения ........................................................................ 31
3.1.3. Объединение отношений .................................................................. 31
3.1.4. Пересечение отношений ................................................................... 32
3.1.5. Разность отношений.......................................................................... 32
3.1.6. Произведение отношений ................................................................ 33
3.1.7. Деление отношений .......................................................................... 33
3.1.8. Соединение отношений .................................................................... 34
3.2. Нормализация отношений реляционных баз данных ...................... 35
3.2.1. Пример декомпозиции исходной «универсальной» таблицы на
простые отношения. .................................................................................... 35
3.2.2. Проблемы, возникающие при использовании универсального
отношения .................................................................................................... 37
3.2.3. Первая нормальная форма (1NF). .................................................... 40
3.2.4. Вторая нормальная форма (2NF) ..................................................... 43
3.2.5. Третья нормальная форма (3NF) ..................................................... 45
3.2.6. Нормальная форма Бойса-Кодда (BCNF) ....................................... 48
3.2.7. Четвертая нормальная форма (4NF). Пятая нормальная форма,
или нормальная форма проекции-соединения (5NF или PJ/NF) ............ 49
5
4. Разработка инфологических моделей ......................................................... 50
4.1. Диаграммы "сущность-связь" ............................................................... 50
4.2. Методология IDEF1X ............................................................................... 55
4.3. Этапы разработки инфологической модели ....................................... 59
4.3.1. Анализ выходных форм .................................................................... 60
4.3.2. Выделение сущностей ...................................................................... 62
5. Организация доступа к данным ................................................................... 64
5.1. Средства ускоренного доступа к данным ........................................... 64
5.2. Язык запросов ........................................................................................... 66
5.2.1. Язык SQL ........................................................................................... 67
5.2.2. Состав SQL-оператора ...................................................................... 68
5.2.3. SQL - оператор SELECT .................................................................. 69
5.2.4. SQL - оператор DELETE ................................................................. 87
5.2.5. SQL - оператор INSERT .................................................................. 88
5.2.6. SQL - оператор UPDATE................................................................. 89
5.3.
Обработка транзакций ......................................................................... 89
5.4. Средства восстановления после сбоев ................................................. 95
6. Принципы построения систем, ориентированных на анализ данных . 96
6.1. Хранилища данных. ................................................................................ 96
6.2. Модели данных, используемые при построении Хранилищ
Данных ............................................................................................................... 99
Заключение. ......................................................................................................... 105
Список наиболее часто встречающихся сокращений. ............................... 106
Список литературы ....................................................................................... 110
6
Введение.
Литературы на русском языке, посвященной тематике СУБД, очень
мало. Невозможно порекомендовать одну или несколько книг, содержание
которых покрывало бы материал курса «Базы данных». К числу лучших
относятся книги К. Дейта "Введение в системы баз данных" (Наука, 1980) и
"Руководство по реляционной СУБД DB2" (Финансы и статистика, 1988), а
также книга Дж. Ульмана "Основы систем баз данных" (Финансы и
статистика, 1983). Хотя эти книги несколько устарели (на английском языке
вышло уже несколько дополненных изданий), их стоит читать.
Данное учебное пособие на наш взгляд призвано систематизировать и
представить методически в доступной для первоначального изучения и
освоения форме материал в объеме и по содержанию, отвечающем
требованиям программы курса «Базы данных». Оно состоит из шести
взаимосвязанных разделов, в которых последовательно шаг за шагом
рассмотрены следующие вопросы:
1. концепция баз данных, архитектура СУБД (инфологическая модель
данных, даталогическая модель данных, физическая модель данных, типы
даталогических моделей данных, иерархическая даталогическая модель,
сетевая даталогическая модель, даталогическая модель на основе
инвертированных списков, реляционная даталогическая модель, объектнореляционная даталогическая модель);
2. реляционные базы данных (основные понятия реляционных баз
данных, тип данных, домен, схема отношения, схема базы данных, кортеж,
отношение, целостность реляционных баз данных, основные свойства
отношений реляционных баз данных);
3. операции над таблицами реляционных баз данных (операции теории
множеств, нормализация отношений реляционных баз данных);
7
4. использование языка ER-диаграмм для построения инфологических
моделей (диаграммы "сущность-связь", информационное моделирование,
методология IDEF1X, этапы разработки инфологической модели данных);
5. организация доступа к данным (средства ускоренного доступа к
данным, язык запросов, обработка транзакций, средства восстановления
после сбоев);
6. принципы построения систем, ориентированных на анализ данных
(хранилища данных; модели данных, используемые при построении
хранилищ данных).
Учебное пособие предназначено для студентов всех специальностей и
форм обучения.
1. Базы данных и СУБД
1.1. Данные и ЭВМ
Восприятие реального мира можно соотнести с последовательностью
разных, хотя иногда и взаимосвязанных, явлений. С давних времен люди
пытались описать эти явления (даже тогда, когда не могли их понять). Такое
описание называют данными.
Традиционно фиксация данных осуществляется с помощью
конкретного средства общения (например, с помощью естественного языка
или изображений) на конкретном носителе (например, камне или бумаге).
Обычно данные (факты, явления, события, идеи или предметы) и их
интерпретация (семантика) фиксируются совместно, так как естественный
язык достаточно гибок для представления того и другого. Примером может
8
служить утверждение "Стоимость авиабилета 128". Здесь "128" – данное, а
"Стоимость авиабилета" – его семантика.
Нередко данные и интерпретация разделены. Например, "Расписание
движения самолетов" может быть представлено в виде таблицы (рис. 1.1.1), в
верхней части которой (отдельно от данных) приводится их интерпретация.
Такое разделение затрудняет работу с данными (попробуйте быстро получить
сведения из нижней части таблицы).
Интерпретация
Номер
Дни
Пункт
Время
Пункт
Время
Тип
рейса недели отправления вылета назначения прибытия самолета
Стоимость
билета
Данные
138
2_4_7
Баку
21.12
Москва
0.52
ИЛ-86
115.00
57
3_6
Ереван
7.20
Киев
9.25
ТУ-154
92.00
1234
2_6
Казань
22.40
Баку
23.50
ТУ-134
73.50
242
1 по 7 Киев
14.10
Москва
16.15
ТУ-154
57.00
86
2_3_5
Минск
10.50
Сочи
13.06
ИЛ-86
78.50
137
1_3_6
Москва
15.17
Баку
18.44
ИЛ-86
115.00
241
1 по 7 Москва
9.05
Киев
11.05
ТУ-154
57.00
577
1_3_5
Рига
21.53
Таллин
22.57
АН-24
21.50
78
3_6
Сочи
18.25
Баку
20.12
ТУ-134
44.00
578
2_4_6
Таллин
6.30
Рига
7.37
АН-24
21.50
9
Рис. 1.1.1. Данные и их интерпретация.
Применение ЭВМ для ведения (сопровождения, поддержки) и
обработки данных обычно приводит к еще большему разделению данных и
интерпретации. ЭВМ имеет дело главным образом с данными как таковыми.
Большая часть интерпретирующей информации вообще не фиксируется в
явной форме (ЭВМ не "знает", является ли "21.50" стоимостью авиабилета
или временем вылета). Почему же это произошло?
Существует по крайней мере две исторические причины, по
которым применение ЭВМ привело к отделению данных от интерпретации.
Во-первых, ЭВМ не обладали достаточными возможностями для обработки
текстов на естественном языке – основном языке интерпретации данных. Вовторых, стоимость памяти ЭВМ была первоначально весьма велика. Память
использовалась для хранения самих данных, а интерпретация традиционно
возлагалась на пользователя. Пользователь закладывал интерпретацию
данных в свою программу, которая "знала", например, что шестое вводимое
значение связано со временем прибытия самолета, а четвертое – со временем
его вылета. Это существенно повышало роль программы, так как вне
интерпретации данные представляют собой не более чем совокупность битов
на запоминающем устройстве. Жесткая зависимость между данными и
использующими их программами создает серьезные проблемы в ведении
данных и делает использования их менее гибкими.1.2. Концепция баз
данных. Архитектура СУБД
Активная деятельность по отысканию приемлемых способов
обобществления непрерывно растущего объема информации привела к
созданию в начале 60-х годов специальных программных комплексов,
называемых "Системы управления базами данных" (СУБД). СУБД –
программное обеспечение, осуществляющее создание баз данных,
10
поддержание ее в рабочем состоянии и обеспечение эффективного доступа к
данным базы для пользователей и для приложений. Основная особенность
СУБД – это наличие процедур для ввода и хранения не только самих данных,
но и описаний их структуры. Файлы, снабженные описанием хранимых в них
данных и находящиеся под управлением СУБД, стали называть банки
данных, а затем "Базы данных" (БД). Таким образом, База данных (БД)–
отражение предметной области в форме структурированной совокупности
данных. Хранящиеся в ней данные характеризуют состав объектов
предметной области, их свойства и взаимосвязи.
СУБД должна предоставлять доступ к данным любым пользователям,
включая и тех, которые практически не имеют и (или) не хотят иметь
представления о:

физическом размещении в памяти данных и их описаний;

механизмах поиска запрашиваемых данных;

проблемах, возникающих при одновременном запросе одних и тех же
данных многими пользователями (прикладными программами);

способах обеспечения защиты данных от некорректных обновлений и
(или) несанкционированного доступа;

поддержании баз данных в актуальном состоянии
и множестве других функций СУБД.
При выполнении основных из этих функций СУБД должна
использовать различные описания данных. А как создавать эти описания?
Естественно, что проект базы данных надо начинать с анализа
предметной области и выявления требований к ней отдельных пользователей
(сотрудников организации, для которых создается база данных).
Проектирование обычно поручается человеку (группе лиц) –
11
администратору базы данных (АБД). Им может быть как специально
выделенный сотрудник организации, так и будущий пользователь базы
данных, достаточно хорошо знакомый с машинной обработкой данных.
1.2.1. Инфологическая модель данных
Объединяя частные представления о содержимом базы данных,
полученные в результате опроса пользователей, и свои представления о
данных, которые могут потребоваться в будущих приложениях, АБД сначала
создает обобщенное неформальное описание создаваемой базы данных. Это
описание, выполненное с использованием естественного языка,
математических формул, таблиц, графиков и других средств, понятных всем
людям, работающих над проектированием базы данных, называют
инфологической моделью данных (рис. 1.2.1).
12
Рис. 1.2.1. Уровни моделей данных
Такая человеко-ориентированная модель полностью независима от
физических параметров среды хранения данных. В конце концов этой средой
может быть память человека, а не ЭВМ. Поэтому, инфологическая модель не
должна изменяться до тех пор, пока какие-то изменения в реальном мире не
потребуют изменения в ней некоторого определения, чтобы эта модель
продолжала отражать предметную область.
Остальные модели, показанные на рис. 1.2.1, являются компьютероориентированными. С их помощью СУБД дает возможность программам и
пользователям осуществлять доступ к хранимым данным лишь по их именам,
не заботясь о физическом расположении этих данных. Нужные данные
13
отыскиваются СУБД на внешних запоминающих устройствах по физической
модели данных.
1.2.2. Даталогическая модель данных
Так как указанный доступ осуществляется с помощью конкретной
СУБД, то модели должны быть описаны на языке описания данных этой
СУБД. Такое описание, создаваемое АБД по инфологической модели данных,
называют даталогической моделью данных.
Указанные изменения физической и даталогической моделей не будут
замечены существующими пользователями системы (окажутся
"прозрачными" для них), так же как не будут замечены и новые пользователи.
Следовательно, независимость данных обеспечивает возможность развития
системы баз данных без разрушения существующих приложений.
1.2.3. Физическая модель данных
В отличие от инфологической модели данных, физическая модель
полностью зависит от конкретной СУБД. В ней должны быть учтены

ограничения на длину имен объектов базы данных (таблиц,
столбцов, индексов),

использование специальных символов в именах,

допустимые типы данных и их внутреннее представление на
устройствах хранения данных в ЭВМ.
Одной
и
той
же
инфологической
модели
данных
могут
соответствовать несколько разных физических моделей.
Трехуровневая архитектура (инфологический, даталогический и
физический уровни) позволяет обеспечить независимость хранимых данных
от использующих их программ. АБД может при необходимости переписать
хранимые данные на другие носители информации и (или) реорганизовать их
14
физическую структуру, изменив лишь физическую модель данных. АБД
может подключить к системе любое число новых пользователей (новых
приложений), дополнив, если надо, даталогическую модель.
1.3. Типы датологических моделей данных
Моделью данных - называется cпособ отображения предметной
области на структуре данных.
Как отмечалось в п. 1.2, инфологическая модель отображает реальный
мир в некоторые понятные человеку концепции, полностью независимые от
параметров среды хранения данных. Существует множество подходов к
построению таких моделей: графовые модели, семантические сети, модель
"сущность-связь" и т.д. Наиболее популярной из них оказалась модель
"сущность-связь", которая будет рассмотрена в разделе 4.
Инфологическая модель должна быть отображена в компьютероориентированную даталогическую модель, "понятную" СУБД. В процессе
развития теории и практического использования баз данных, а также средств
вычислительной техники создавались СУБД, поддерживающие различные
даталогические модели. Существуют иерархическая, сетевая, реляционная
даталогические
модели
данных,
даталогическая
модель
на
основе
инвертированных списков, объектно-реляционная даталогическая модель.
1.3.1. Иерархическая даталогическая модель
Иерархическая даталогическая модель позволяет строить базы данных
с древовидной структурой. В них каждый узел содержит свой тип данных
(сущность). На верхнем уровне дерева в этой модели имеется один узел –
“корень”, на следующем уровне располагаются узлы, связанные с этим
корнем, затем узлы, связанные с узлами предыдущего уровня и т.д., причем
15
каждый узел может иметь только одного предка, т. е. такие базы
поддерживают отношение типа "один-ко-многим".
Рис.1.3.1.1.
Иерархическая даталогическая структура
модели БД
Поиск данных в иерархической системе всегда начинается с корня.
Затем производится спуск с одного уровня на другой пока не будет достигнут
искомый уровень. Перемещения по системе от одной записи к другой
осуществляются с помощью ссылок.
Основные достоинства иерархической модели - простота описания
иерархических структур реального мира и быстрое выполнение запросов,
соответствующих структуре данных, однако, они часто содержат избыточные
данные и плохо приспособлены для представления взаимосвязей типа
"многие-ко-многим". Кроме того, не всегда удобно каждый раз начинать
поиск нужных данных с корня, а другого способа перемещения по базе в
иерархических структурах не имеется. Иерархические системы - старейшее
поколение систем баз данных. Они разрабатывались для больших ЭВМ.
16
1.3.2. Сетевая даталогическая модель
Стандарт сетевой датологической модели был разработан в начале 70х годов. В отличие от иерархических сетевые модели поддерживают
взаимосвязь типа "многие-ко-многим". Каждый порожденный элемент в них
может иметь более одного предка.
Рис.1.3.2.1. Сетевая даталогическая структура модели БД
Однако, обычно эти системы довольно сложны и требуют солидного
программного обеспечения. В них, также как и в иерархических системах,
переход от записи к записи производится по вставленным в каждую запись
ссылкам. В свое время они были достаточно популярны и стали применяться
для миникомпьютеров и для больших ЭВМ.
1.3.3. Даталогическая модель на основе инвертированных
списков
С ложность практического использования иерархических и
сетевых СУБД заставляла искать иные способы представления данных. В
конце 60-х годов появились СУБД на основе инвертированных списков,
отличающиеся простотой организации и наличием весьма удобных языков
17
манипулирования данными. База данных, организованная с помощью
инвертированных списков, похожа на реляционную БД, но с тем отличием,
что хранимые таблицы и пути доступа к ним видны пользователям. При этом:
a.
Строки таблиц упорядочены системой в некоторой
физической последовательности.
b.
Физическая упорядоченность строк всех таблиц может
определяться и для всей БД .
c.
Для каждой таблицы можно определить произвольное
число ключей поиска, для которых строятся индексы. Эти
индексы автоматически поддерживаются системой, но
явно видны пользователям.
Однако такие СУБД обладают рядом ограничений на количество файлов
для хранения данных, количество связей между ними, длину записи и
количество ее полей.
Сегодня наибольшее распространение получили реляционные
даталогические модели. Организация доступа к данным на основе
инвертированных списков используется практически во всех современных
реляционных СУБД, но в этих системах пользователи не имеют
непосредственного доступа к инвертированным спискам (индексам).
1.3.4. Реляционная даталогическая модель
В реляционной даталогической модели информация представляется в
виде прямоугольных таблиц. Каждая таблица состоит из строк и столбцов и
имеет имя, уникальное внутри базы данных.
Таблица отражает тип объекта реального мира - сущность, а каждая
ее строка один конкретный объект - экземпляр сущности. Каждый столбец
таблицы имеет уникальное для своей таблицы имя. Столбцы расположены в
18
таблице в соответствии с порядком следования их имен при ее создании.
Таблица не может иметь менее одного столбца.
В отличие от столбцов строки не имеют имен, порядок их следования
в таблице не определен, а количество - логически не ограничено. Так как
строки в таблице не упорядочены, невозможно выбрать строку по ее позиции.
Хотя в файле у каждой строки имеется номер, он не характеризует строку.
Его значение изменяется при удалении строк из таблицы. Логически среди
строк не существует “первой” и “последней”.
Реляционные системы исключили необходимость сложной навигации,
поскольку данные представлены в них не в виде одного файла, а
независимыми наборами, и для отбора данных используются операции
реляционной алгебры - прикладной теории множеств.
Реляционная модель была разработана в начале 70х годов Коддом.
Простота и гибкость модели привлекли к ней внимание разработчиков. В 80х годах она получила широкое распространение, и реляционные СУБД
оказались промышленным стандартом.
Модель опирается на систему понятий реляционной алгебры,
важнейшие из которых: таблица, строка, столбец, отношение и первичный
ключ, а все операции сводятся к манипуляциям с таблицами.
В каждой таблице реляционной модели должен быть столбец или
совокупность столбцов, значения которых однозначно идентифицируют
каждую строку таблицы. Этот столбец или их совокупность и называется
первичным ключом таблицы.
Если таблица удовлетворяет требованию уникальности первичного
ключа, она называется отношением. В реляционной модели все таблицы
должны быть преобразованы в отношения. Отношения реляционной модели
связаны между собой. Связи поддерживаются внешними ключами. Внешний
19
ключ это столбец (совокупность столбцов), значение которого однозначно
характеризует значения первичного ключа другого отношения.
Говорят, что отношение, в котором определен внешний ключ,
ссылается на соответствующее отношение, в котором та же совокупность
столбцов является первичным ключом.
Рис.1.3.4.1. Организация ссылки от одной таблицы к другой
В приведенном примере отношение "Сотрудник" ссылается на
отношение "Отдел" через название отдела.
Примечание. В реальных БД в качестве ключей используют не сами
названия, а соответствующие им коды.
Кроме самих отношений в реляционной БД хранятся метаданные и
другие объекты. Метаданными называют описатели таблиц, их столбцов,
ключей и т.д. Эта информация представлена также в виде таблиц и
размещается в словаре данных.
20
Доминирование
реляционной
модели
в
современных
СУБД
определяется:
1.
наличием развитой теории (реляционной алгебры);
2.
наличием аппарата сведения других моделей данных к
реляционной модели;
3.
наличием специальных средств ускоренного доступа к
информации;
4.
наличием стандартизированного высокоуровневого языка запросов
к БД, позволяющего манипулировать ими без знания конкретной
физической организации БД во внешней памяти.
1.3.5. Объектно- реляционная даталогическая модель
В основе объектно-реляционной даталогической модели лежит
реляционная модель со значительно расширенными возможностями,
обеспечивающими стыковку с объектно-ориентированными языками.
Появление таких баз приходится на 90-е годы прошлого века. Такого рода
базы хранят методы классов, а иногда и постоянные объекты классов, что
позволяет осуществлять беспрепятственную интеграцию межу данными и их
обработкой в приложениях.
2. Реляционные базы данных
2.1. Основные понятия реляционных баз данных
Основными понятиями реляционных баз данных являются тип
данных, домен, атрибут, кортеж, первичный ключ и отношение.
21
Для начала покажем смысл этих понятий на примере отношения
СОТРУДНИКИ, содержащего информацию о сотрудниках некоторой
организации:
2.1.1. Тип данных
Понятие тип данных в реляционной модели данных полностью
адекватно понятию типа данных в языках программирования. Обычно в
современных реляционных БД допускается хранение символьных, числовых
данных, битовых строк, специализированных числовых данных (таких как
"деньги"), а также специальных "темпоральных" данных (дата, время,
временной интервал). Достаточно активно развивается подход к расширению
возможностей реляционных систем абстрактными типами данных
(соответствующими возможностями обладают, например, системы семейства
22
Ingres/Postgres). В нашем примере мы имеем дело с данными трех типов:
строки символов, целые числа и "деньги".
2.1.2. Домен
Понятие домена более специфично для баз данных, хотя и имеет
некоторые аналогии с подтипами в некоторых языках программирования. В
самом общем виде домен определяется заданием некоторого базового типа
данных, к которому относятся элементы домена, и произвольного
логического выражения, применяемого к элементу типа данных. Если
вычисление этого логического выражения дает результат "истина", то
элемент данных является элементом домена.
Наиболее правильной интуитивной трактовкой понятия домена
является понимание домена как допустимого потенциального множества
значений данного типа. Например, домен "Имена" в нашем примере
определен на базовом типе строк символов, но в число его значений могут
входить только те строки, которые могут изображать имя (в частности, такие
строки не могут начинаться с мягкого знака).
Следует отметить также семантическую нагрузку понятия домена:
данные считаются сравнимыми только в том случае, когда они относятся к
одному домену. В нашем примере значения доменов "Номера пропусков" и
"Номера групп" относятся к типу целых чисел, но не являются сравнимыми.
Заметим, что в большинстве реляционных СУБД понятие домена не
используется, хотя в Oracle V.7 оно уже поддерживается.
2.1.3. Схема отношения, схема базы данных
Схема отношения - это именованное множество пар {имя атрибута,
имя домена (или типа, если понятие домена не поддерживается)}. Степень
или "арность" схемы отношения - мощность этого множества. Степень
отношения СОТРУДНИКИ равна четырем, то есть оно является 4-арным.
23
Если все атрибуты одного отношения определены на разных доменах,
осмысленно использовать для именования атрибутов имена
соответствующих доменов (не забывая, конечно, о том, что это является
всего лишь удобным способом именования и не устраняет различия между
понятиями домена и атрибута).
Схема БД (в структурном смысле) - это набор именованных схем
отношений.
2.1.4. Кортеж, отношение
Кортеж, соответствующий данной схеме отношения, - это множество
пар {имя атрибута, значение}, которое содержит одно вхождение каждого
имени атрибута, принадлежащего схеме отношения. "Значение" является
допустимым значением домена данного атрибута (или типа данных, если
понятие домена не поддерживается). Тем самым, степень или "арность"
кортежа, т.е. число элементов в нем, совпадает с "арностью"
соответствующей схемы отношения. Попросту говоря, кортеж - это набор
именованных значений заданного типа.
Отношение - это множество кортежей, соответствующих одной схеме
отношения. Иногда, чтобы не путаться, говорят "отношение-схема" и
"отношение-экземпляр", иногда схему отношения называют заголовком
отношения, а отношение как набор кортежей - телом отношения. На самом
деле, понятие схемы отношения ближе всего к понятию структурного типа
данных в языках программирования. Было бы вполне логично разрешать
отдельно определять схему отношения, а затем одно или несколько
отношений с данной схемой.
Однако в реляционных базах данных это не принято. Имя схемы
отношения в таких базах данных всегда совпадает с именем
соответствующего отношения-экземпляра. В классических реляционных
базах данных после определения схемы базы данных изменяются только
24
отношения-экземпляры. В них могут появляться новые и удаляться или
модифицироваться существующие кортежи. Однако во многих реализациях
допускается и изменение схемы базы данных: определение новых и
изменение существующих схем отношения. Это принято называть эволюцией
схемы базы данных.
Обычным житейским представлением отношения является таблица,
заголовком которой является схема отношения, а строками - кортежи
отношения-экземпляра; в этом случае имена атрибутов именуют столбцы
этой таблицы. Поэтому иногда говорят "столбец таблицы", имея в виду
"атрибут отношения". Когда мы перейдем к рассмотрению практических
вопросов организации реляционных баз данных и средств управления, мы
будем использовать эту житейскую терминологию. Этой терминологии
придерживаются в большинстве коммерческих реляционных СУБД.
Реляционная база данных - это набор отношений, имена которых
совпадают с именами схем отношений в схеме БД.
Как видно, основные структурные понятия реляционной модели
данных (если не считать понятия домена) имеют очень простую интуитивную
интерпретацию, хотя в теории реляционных БД все они определяются
абсолютно формально и точно.
2.2. Целостность реляционных баз данных
Для пользователей важно, чтобы база данных отображала предметную
область однозначно и непротиворечиво, т.е. чтобы она удовлетворяла условию
целостности.
Выделяют два основных типа ограничений по условию целостности:
1.
Каждая строка таблицы должна отличаться от остальных ее строк
значением хотя бы одного столбца.
25
Пример:
Сотрудники отдела могут оказаться полными тезками, родившимися в
один и тот же день. Чтобы не нарушить условия целостности, добавляем в
таблицу новый столбец - "Номер пропуска", превращая ее в отношение. Таким
образом, первое ограничение обеспечивается наличием в таблице - отношении
первичного ключа.
2.
Внешний ключ не может быть указателем на несуществующую
строку той таблицы, на которую он ссылается. Это ограничение называется
ограничением целостности по ссылкам.
Пример:
В столбце Название отдела таблицы "Сотрудник" (Рис. 2.2.1.) хранятся
сведения о принадлежности сотрудников к отделу. Здесь Название отдела
является внешним ключом для ссылки на таблицу "Отдел". Для обеспечения
ограничения целостности по ссылкам каждое Название отдела из таблицы
"Сотрудник" должно принадлежать конкретному отделу из таблицы "Отдел".
Рис. 2.2.1. Таблицы «Сотрудник» и «Отдел».
26
Примечание: В реальных базах данных названия не делают
ключевыми из-за их длины (замедление процесса поиска), а также из-за того,
что они могут изменяться (сложности с сопровождением системы)
2.3. Основные свойства отношений реляционных баз данных
Остановимся теперь на некоторых важных свойствах отношений:
отсутствие кортежей-дубликатов, отсутствие упорядоченности кортежей,
отсутствие упорядоченности атрибутов, атомарность значений атрибутов
отношения.
2.3.1 . Отсутствие кортежей-дубликатов
Это свойство следует из определения отношения как множества
кортежей. В классической теории множеств по определению каждое
множество состоит из различных элементов.
Из этого свойства вытекает наличие у каждого отношения так
называемого первичного ключа - набора атрибутов, значения которых
однозначно определяют кортеж отношения. Для каждого отношения по
крайней мере полный набор его атрибутов обладает этим свойством. Однако
при формальном определении первичного ключа требуется обеспечение его
"минимальности", т.е. в набор атрибутов первичного ключа не должны
входить такие атрибуты, которые можно отбросить без ущерба для основного
свойства - однозначно определять кортеж. Понятие первичного ключа
является исключительно важным в связи с понятием целостности баз данных.
2.3.2 . Отсутствие упорядоченности кортежей
Свойство отсутствия упорядоченности кортежей отношения также
является следствием определения отношения-экземпляра как множества
кортежей. Отсутствие требования к поддержанию порядка на множестве
кортежей отношения дает дополнительную гибкость СУБД при хранении баз
27
данных во внешней памяти и при выполнении запросов к базе данных. Это не
противоречит тому, что при формулировании запроса к БД, например, на
языке SQL можно потребовать сортировки результирующей таблицы в
соответствии со значениями некоторых столбцов. Такой результат, вообще
говоря, не отношение, а некоторый упорядоченный список кортежей.
2.3.3 . Отсутствие упорядоченности атрибутов
Атрибуты отношений не упорядочены, поскольку по определению
схема отношения есть множество пар {имя атрибута, имя домена}. Для
ссылки на значение атрибута в кортеже отношения всегда используется имя
атрибута. Это свойство теоретически позволяет, например, модифицировать
схемы существующих отношений не только путем добавления новых
атрибутов, но и путем удаления существующих атрибутов. Однако в
большинстве существующих систем такая возможность не допускается, и
хотя упорядоченность набора атрибутов отношения явно не требуется, часто
в качестве неявного порядка атрибутов используется их порядок в линейной
форме определения схемы отношения.
2.3.4 . Атомарность значений атрибутов
Значения всех атрибутов являются атомарными. Это следует из
определения домена как потенциального множества значений простого типа
данных, т.е. среди значений домена не могут содержаться множества
значений (отношения). Принято говорить, что в реляционных базах данных
допускаются только нормализованные отношения или отношения,
представленные в первой нормальной форме (раздел 3.2). Потенциальным
примером ненормализованного отношения является следующее:
28
Ненормализованное отношение «ОТДЕЛЫ»
Можно сказать, что здесь мы имеем бинарное отношение, значениями
атрибута ОТДЕЛЫ которого являются отношения. Заметим, что исходное
отношение СОТРУДНИКИ является нормализованным вариантом отношения
ОТДЕЛЫ:
Нормализованное отношение «СОТРУДНИКИ»
СОТР_НОМЕР
СОТР_ИМЯ
СОТР_ЗАРП
СОТР_ОТД_НОМЕР
2934
Иванов
112,000
310
2935
Петров
144,000
310
2936
Сидоров
92,000
313
2937
Федоров
110,000
310
2938
Иванова
112,000
315
29
Нормализованные отношения составляют основу классического
реляционного подхода к организации баз данных. Они обладают некоторыми
ограничениями (не любую информацию удобно представлять в виде плоских
таблиц), но существенно упрощают манипулирование данными. Рассмотрим,
например, два идентичных оператора занесения кортежа:
Зачислить сотрудника Кузнецова (пропуск номер 3000, зарплата
115,000) в отдел номер 320 и
Зачислить сотрудника Кузнецова (пропуск номер 3000, зарплата
115,000) в отдел номер 310.
Если информация о сотрудниках представлена в виде отношения
СОТРУДНИКИ, оба оператора будут выполняться одинаково (вставить
кортеж в отношение СОТРУДНИКИ). Если же работать с
ненормализованным отношением ОТДЕЛЫ, то первый оператор выразится в
занесение кортежа, а второй - в добавление информации о Кузнецове в
множественное значение атрибута ОТДЕЛ кортежа с первичным ключом 310.
3. Операции над таблицами реляционных баз данных
Поскольку каждая таблица в реляционной БД является отношением,
действия над таблицами базируются на операциях реляционной алгебры.
Исключение составляют лишь операции создания и заполнения таблиц
данными (операция присваивания), а также операции описания и
переименования столбцов таблицы.
30
3.1. Некоторые операции теории множеств
В теории реляционной алгебры отношение рассматривается, как
множество, строки таблицы называются кортежами, столбцы – атрибутами.
Над отношениями выполняются традиционные операции теории множеств:
3.1.1. Ограничение отношения – создает новое отношение,
отбирая в него строки отношения – операнда, которые удовлетворяют
условию ограничения. Пример использования смотри в пересечении
отношений.
3.1.2. Проекция отношения – создает новое отношение, отбирая в
него определенные столбцы отношения – операнда. Пример использования
смотри в пересечении отношений.
3.1.3. Объединение отношений – создает новое отношение,
содержащее все кортежи отношений операндов. Операнды должны иметь
одинаковые атрибуты.
Пример объединения отношений:
Ежемесячно из цехов поступают отчеты о выпуске продукции за
прошедший месяц, содержащие номер цеха, код продукции, дату выпуска и
количество выпущенной продукции. Эти сведения добавляются в общую
таблицу "Выпуск продукции" с такой же структурой, т.е. к кортежам
добавляются кортежи
Атрибуты операндов совпадают; таблица "Новая продукция" объединяется с
исходной.
31
3.1.4. Пересечение отношений – создает новое отношение,
содержащее строки, общие для сравниваемых операндов. Операнды
должны иметь одинаковые атрибуты.
Пример пересечения отношений:
Имеется
набор
экзаменационных
ведомостей
-
отношений
с
совпадающими атрибутами:
Подготовить список студентов, получивших только отличные оценки,
со столбцами "Номер зачетной книжки" и "Фамилия студента".
Для экзаменационных ведомостей нужной группы:
1.
Выполняем ограничение исходных отношений, отбирая из
каждого в новое отношение кортежи, удовлетворяющие условию оценкаi =
"отлично". Получили списки отличников группы по дисциплинам.
2.
Выполняем проекцию полученных отношений, отбирая из
каждого только атрибуты номер зачетной книжкиi и фамилия студентаi.
Получили новые списки отличников, в которых остались только номера
зачетных книжек и фамилии студентов.
3. Пересечение последних даст нам искомое отношение - "Список
отличников", содержащее номера зачетных книжек и фамилии общие
для всех списков отличников.
3.1.5. Разность отношений – создает новое отношение, содержащее
строки 1-го операнда, отсутствующие во 2-ом операнде. Операнды
должны иметь одинаковые атрибуты.
Пример разности отношений:
32
Используя ежемесячные отчеты цехов о выпуске продукции (смотри
пример объединения отношений), подготовить сведения о выпуске новых
видов продукции за последний квартал.
Для решения этой задачи выполняем ограничение отношения "Выпуск
продукции".
Условие ограничения - "дата выпуска больше последней даты
прошлого квартала".
Результат ограничения помещаем во временную Таблицу 1. Затем над
той же исходной таблицей выполняем ограничение "дата выпуска не больше
последней даты прошлого квартала" и заносим результат во временную
Таблицу 2.
Разность отношений 1 и 2 даст искомые сведения.
3.1.6. Произведение отношений – создает новое отношение, в
котором имеются все атрибуты 1-го и 2-го операндов, а строки получены
попарным сцеплением каждой строки 1-го с каждой строкой 2-го отношения.
Количество кортежей – мощность нового отношения, равно произведению
мощности 1-го отношения на мощность 2-го. Множества атрибутов
отношений не должны пересекаться. Произведение отношений используется
при решении задач подбора пар из двух множеств, например, поставщики и
потребители. Сначала составляют все возможные пары, а затем по
конкретному критерию отбирают из них подходящие.
3.1.7. Деление отношений - создает новое отношение, содержащее
атрибуты 1-го операнда, отсутствующие во 2-ом операнде и кортежи 1-го
операнда, которые совпали с кортежами 2-го. Для выполнения этой операции
2-ой операнд должен содержать лишь атрибуты, совпадающие с атрибутами
1-го.
Пример использования деления отношений:
33
Список студентов факультета для каждого студента содержит:
Ф.И.О., дату рождения, шифр группы и признак наличия стипендии (да, нет).
Необходимо отобрать студентов заданной группы, получающих
стипендию.
Для этого:
1. Создаем вспомогательное отношение с атрибутами шифр группы и
признак наличия стипендии.
2. Заполняем один кортеж этого отношения, поместив в него шифр
заданной группы и отметку о получении стипендии (да).
3. Деление исходного списка на вспомогательное отношение создаст
искомый список с атрибутами: ФИО и дата рождения.
3.1.8. Соединение отношений - создает новое отношение, кортеж
которого является результатом сцепления кортежей операндов (исходных
отношений). Соединение имеет две разновидности: естественное соединение
и соединение по условию.
При соединении по условию производится сцепление строк операндов
соединения и проверка их на соответствие заданному условию. Если условие
выполнено, полученная строка включается в отношение – результат.
При естественном соединении производится сцепление строк
операндов соединения и включение их в результат без проверки. Такое
соединение используют, когда отношения – операнды обладают общими
атрибутами.
34
3.2. Нормализация отношений реляционных баз данных
Под нормализацией подразумевается попытка предотвратить аномалии
обновления реляционных таблиц (R-таблиц), то есть ситуации, которые
могут привести к противоречивости данных. В теории реляционных баз
данных обычно выделяется следующая последовательность нормальных
форм:

первая нормальная форма (1NF);

вторая нормальная форма (2NF);

третья нормальная форма (3NF);

нормальная форма Бойса-Кодда (BCNF);

четвертая нормальная форма (4NF);

пятая нормальная форма, или нормальная форма проекции-соединения
(5NF или PJ/NF).
Процесс нормализации заключается в разложении (декомпозиции) исходных
отношений БД на более простые отношения. Каждая ступень этого процесса
приводит схему отношений в последовательные нормальные формы. Для
каждой ступени нормализации имеются наборы ограничений, которым
должны удовлетворять отношения БД. Нормализация позволяет удалить из
таблиц базы избыточную неключевую информацию.
3.2.1. Пример декомпозиции исходной «универсальной» таблицы
на простые отношения.
Предположим, что проектирование базы данных с условным
названием "Питание" начинается с выявления атрибутов и подбора данных,
образец которых (часть блюд изготовленных и реализованных 1/9/94 г.)
показан на рис. 3.2.1.1.
35
Блюдо
Лобио
Харчо
Вид
Рецепт
Закуска
Лом.
Суп
...
Порций
Дата
Р
158
1/9/94 Фасоль
144
Продукт
Калорий
-ность
Вес
(г)
Поставщик
Город
Китай
Вес
(кг)
Цена Дата П
($)
250
0.37
24/8/94
3070
200
"Хуанхэ"
Лук
450
40
"Наталка" Киев
Украина 100
0.52
27/8/94
Масло
7420
30
"Лайма"
Рига
Латвия
70
1.55
30/8/94
Зелень
180
10
"Даугава"
Рига
Латвия
15
0.99
30/8/94
1660
80
"Наталка" Киев
Украина 100
2.18
27/8/94
Лук
450
30
"Наталка" Киев
Украина 100
0.52
27/8/94
Томаты
240
40
"Полесье"
Киев
Украина 120
0.45
27/8/94
Рис
3340
50
"Хуанхэ"
Пекин
Китай
75
0.44
24/8/94
…
…
…
…
…
…
…
…
…
1/9/94 Мясо
Пекин
Страна
Рис. 3.2.1.1.Данные, необходимые для создания базы данных "Питание"
Этот вариант таблицы "Питание" не является отношением, так как
большинство ее строк не атомарны. Атомарными являются лишь значения
полей Блюдо, Вид, Рецепт (хотя он и большой), Порций и Дата_Р. Остальные
же поля таблицы рис. 3.2.1.1– множественные.
Для придания таким данным формы отношения необходимо
реконструировать таблицу. Наиболее просто это сделать с помощью простого
процесса вставки, результат которой показан на рис. 3.2.1.2. Однако такое
преобразование приводит к возникновению большого объема избыточных
данных.
Блюдо
Вид
Рецепт Порций Дата Продукт Калорий- Вес Поставщик Город
Р
ность
(г)
Лобио Закуска Лом.
158
1/9/94 Фасоль
3070
200 "Хуанхэ"
Лобио Закуска Лом
108
1/9/94 Лук
450
40
Лобио Закуска Лом
108
1/9/94 Масло
7420
Лобио Закуска Лом
108
1/9/94 Зелень
Харчо Суп
...
144
Харчо Суп
...
Харчо Суп
Страна
Пекин Китай
Вес
(кг)
Цена
($)
Дата
П
250
0.37
24/8/94
"Наталка" Киев
Украина 100
0.52
27/8/94
30
"Лайма"
Рига
Латвия
70
1.55
30/8/94
180
10
"Даугава"
Рига
Латвия
15
0.99
30/8/94
1/9/94 Мясо
1660
80
"Наталка" Киев
Украина 100
2.18
27/8/94
144
1/9/94 Лук
450
30
"Наталка" Киев
Украина 100
0.52
27/8/94
...
144
1/9/94 Томаты 240
40
"Полесье"
Киев
Украина 120
0.45
27/8/94
Харчо Суп
...
144
1/9/94 Рис
3340
50
"Хуанхэ"
Пекин Китай
75
0.44
24/8/94
Харчо Суп
...
144
1/9/94 Масло
7420
15
"Полесье"
Киев
Украина 50
1.62
27/8/94
36
…
…
...
…
…
…
…
...
…
…
…
…
…
…
Рис. 3.2.1.2. Универсальное отношение "Питание"
Таблица на рис. 3.2.1.2. представляет собой экземпляр корректного
отношения. Его называют универсальным отношением проектируемой БД. В
одно универсальное отношение включаются все представляющие интерес
атрибуты, и оно может содержать все данные, которые предполагается
размещать в БД в будущем. Для малых БД (включающих не более 15
атрибутов) универсальное отношение может использоваться в качестве
отправной точки при проектировании БД.
3.2.2. Проблемы, возникающие при использовании
универсального отношения
1. Избыточность. Данные практически всех столбцов многократно
повторяются. Повторяются и некоторые наборы данных (Блюдо-Вид-Рецепт,
Продукт-Калорийность, Поставщик-Город-Страна). Нежелательно
повторение рецептов, некоторые из которых намного больше рецепта
"Лобио". И уж совсем плохо, что все данные о блюде (включая рецепт)
повторяются каждый раз, когда это блюдо включается в меню.
2. Потенциальная противоречивость (аномалии обновления).
Вследствие избыточности можно обновить адрес поставщика в одной строке,
оставляя его неизменным в других. Если поставщик кофе сообщил о своем
переезде в Харбин и была обновлена строка с продуктом кофе, то у
поставщика "Хуанхэ" появляются два адреса, один из которых не актуален.
Следовательно, при обновлениях необходимо просматривать всю таблицу
для нахождения и изменения всех подходящих строк.
3. Аномалии включения. В БД не может быть записан новый поставщик
("Няринга", Вильнюс, Литва), если поставляемый им продукт (Огурцы) не
используется ни в одном блюде. Можно, конечно, поместить неопределенные
значения в столбцы Блюдо, Вид, Порций и Вес (г) для этого поставщика. Но
37
если появится блюдо, в котором используется этот продукт, не забудем ли мы
удалить строку с неопределенными значениями?
По аналогичным причинам нельзя ввести и новый продукт (например,
Баклажаны), который предлагает существующий поставщик (например,
"Полесье"). А как ввести новое блюдо, если в нем используется новый
продукт (Крабы)?
4. Аномалии удаления. Обратная проблема возникает при
необходимости удаления всех продуктов, поставляемых данным
поставщиком или всех блюд, использующих эти продукты. При таких
удалениях будут утрачены сведения о таком поставщике.
Многие проблемы этого примера исчезнут, если выделить в отдельные
таблицы сведения о блюдах, продуктах, рецептах, расходе блюд,
поставщиках продуктов и их городах, а также создать связующие таблицы
"Состав" и "Поставки" (Рис. 3.2.2.1).
Блюда
Продукты
Код
блюда
Блюдо
Вид
1
Лобио
Закуска
1
Фасоль
3070
2
Харчо
Суп
2
Лук
450
3
Масло
7420
…
…
…
3
Код
Продукт Калорийность
продукта
Шашлык Горячее
…
…
…
Состав
Расход
Код
Код
Веc
блюда продукта (г)
Код
Порций Дата_Р
блюда
1
1
200
1
158
1/9/94
1
2
40
2
144
1/9/94
1
3
30
3
207
1/9/94
2
5
80
4
235
1/9/94
…
…
…
...
...
...
Рецепты
Поставщики
38
Код
блюда
Рецепт
Код
Код
Поставщик
поставщика
города
1
Ломаную очищ…
1
"Полесье"
1
2
…
2
"Наталка"
1
3
…
3
"Хуанхэ"
2
...
...
4
"Лайма"
3
Поставки
Города
Код
Код
Вес
Цена Дата_П
поставщика продукта (кг)
Код
Город
города
Страна
1
6
120 0.45 27/8/94
1
Киев
Украина
1
3
50
1.82 27/8/94
2
Пекин
Китай
1
2
50
0.61 27/8/94
4
Москва Россия
2
2
100 0.52 27/8/94
5
Сочи
Россия
2
5
100 2.18 27/8/94
3
Рига
Латвия
…
…
…
…
…
…
…
…
Рис. 3.2.2.1. Преобразование универсального отношения "Питание"
1. Каждая таблица состоит из однотипных строк и имеет уникальное имя.
2. Строки имеют фиксированное число полей (столбцов) и значений
(множественные поля и повторяющиеся группы недопустимы). Иначе
говоря, в каждой позиции таблицы на пересечении строки и столбца
всегда имеется в точности одно значение или ничего.
3. Строки таблицы обязательно отличаются друг от друга хотя бы
единственным значением, что позволяет однозначно идентифицировать
любую строку такой таблицы.
39
4. Столбцам таблицы однозначно присваиваются имена, и в каждом из
них размещаются однородные значения данных (даты, фамилии, целые
числа или денежные суммы).
5. Полное информационное содержание базы данных представляется в
виде явных значений данных и такой метод представления является
единственным.
6.
При выполнении операций с таблицей ее строки и столбцы можно
обрабатывать в любом порядке.
7.
Удаление сведений о некоторых поставках или блюдах не приводит к
потере сведений о поставщиках.
8.
Включение осуществляется простым добавлением строк в
соответствующую таблицу.
Для исключения ссылок на длинные текстовые значения последние
обычно нумеруют: нумеруют блюда в больших кулинарных книгах, товары
(продукты) в каталогах и т.д. Воспользуемся этим приемом для исключения
избыточного дублирования данных и появления ошибок при копировании
длинных текстовых значений (рис. 3.2.2.1). Теперь при изменении названия
поставщика "Полесье" на "Днепро" исправляется единственное значение в
таблице Поставщики. И даже если оно вводится с ошибкой ("Днипро"), то это
не может повлиять на связь между поставщиками и продуктами (в связующей
таблице Поставки используются номера поставщиков и продуктов, а не их
названия).
3.2.3. Первая нормальная форма (1NF).
Первый этап нормализации БД - назначение первичных ключей для
каждой таблицы, т.е. превращение ее в отношение, проверка атрибутов
таблиц на атомарность и выделение атрибутов, имеющих более одного
значения, в новые сущности.
40
Атомарным называется атрибут, значения которого логически
неделимы.
Примеры:

Название фабрики "Красная синька" содержит два слова,
которые служат названием только в этом сочетании, в то время как по
частям "красная" характеризует цвет, а "синька" - изделие. Название
фабрики разделению не подлежит.

В отличие от первого примера атрибут рабочего "Сидоров
Иван Петрович", содержит три части - фамилию, имя и отчество
человека, которого он характеризует, т.е. должен быть разбит на три
атомарных
атрибута,
каждый
из
которых
может
употребляться
самостоятельно.

Атрибут "Дата рождения рабочего", как и "Фамилия Имя
Отчество", не является атомарным, поскольку включает в себя три
понятия "Год", "Месяц" и "День". Однако в БД существуют типы данных
- Date и DateTime, которые позволяют выполнять над датами
специальные операции, например, < дата 1 > - < дата 2 > = < количество
дней между ними > . В связи с этим значения дат в базах данных
считаются атомарными.
Таблица находится в первой нормальной форме тогда и только
тогда, когда ни одна из ее строк не содержит в любом своем поле более
одного значения и ни одно из ее ключевых полей не пусто.
БД находится в первой нормальной форме, если все ее таблицы
являются отношениями, а столбцы таблиц удовлетворяют условию
атомарности
В задачах часто встречаются данные, имеющие более одного
значения. Примером может служить заказ на изготовление каких - либо
41
изделий, в который вошли названия изделий, их цены и заказанное
количество:
Изделие 1
№
Изделие 2
Изделие 3
Заказчик
Дата
Название
Цена
Кол-
Назва-
во
ание
Цена
Кол- Назваво
ние
Цена
Кол- заказа
во
Сущность "Заказ" с атрибутами, полностью отражающими
приведенную таблицу, хотя и находится в первой нормальной форме, но
обладает двумя недостатками:
1.
Если заказчику требуется только один или два вида изделий, в
таблице окажутся пустые ячейки, что понижает коэффициент использования
памяти. Для четвертого вида изделий место в заказе просто отсутствует, т.е.
ему придется оформлять второй заказ. Значит, в таблице появится лишняя
строка и новые пустые ячейки
2.
Поиск изделий с конкретным названием усложнен, так как его
приходится искать в нескольких столбцах таблицы.
Эти недостатки можно устранить одним из двух способов:
1.
Разбить строку таблицы на несколько строк, в каждой из которых
будет стоять только одна группа повторяющихся атрибутов (в рассмотренном
примере это Название изделия, Цена, Количество);
2.
Перевести
повторяющиеся
атрибуты
в
новую
сущность,
назначить ей первичный ключ (Код изделия) и связать с исходной сущностью
ссылкой на первичный ключ последней (Номер заказа).
Итак, была сущность:
42
При использовании первого способа ее экземпляр будет иметь
атрибуты:
В результате этого преобразования увеличилось количество строк, зато
повысилась плотность записи и упростился поиск изделий.
После выделения новой сущности (второй способ преобразования),
стало:
3.2.4. Вторая нормальная форма (2NF)
Вторая нормальная форма к требованию атомарности атрибутов
добавляет еще одно - каждый неключевой атрибут должен функционально
полно зависеть от первичного ключа (не должен зависеть от части составного
ключа).
Таблица находится во второй нормальной форме, если она
удовлетворяет определению 1НФ и все ее поля, не входящие в первичный
ключ, связаны полной функциональной зависимостью с первичным ключом.
Состав созданной нами в предыдущем примере сущности "Заказанное
изделие" служит характерным примером нарушения второй нормальной
формы. Первичный ключ этой сущности - сочетание атрибутов Номер заказа
43
и Код изделия. От этого составного ключа зависит один атрибут - Количество
заказанных изделий; остальные атрибуты - Название и Цена изделия зависят
только от Кода изделия.
Чтобы привести сущность "Заказанное изделие" ко второй нормальной
форме, выделим из нее атрибуты, характеризующие изделие как таковое,
создав еще одну сущность - "Изделие" и будем ссылаться на нее из
"Заказанного изделия" через Код изделия :
Другой пример сущности, в которой часть неключевых атрибутов не
зависит от первичного ключа:
Даже если существует ограничение, что один лектор может читать
только одну дисциплину, такой состав атрибутов будет служить источником
ошибок:
При исключении дисциплины из планов обучения, вместе с нею
пропадает и информация о лекторе.
Если какой-либо лектор временно прекращает читать свою
дисциплину, информация о нем также пропадает.
Правильным решением в этом случае будет выделение информации о
лекторе в отдельную сущность со ссылкой на код дисциплины:
44
А если учесть, что на самом деле один лектор может читать более
одной дисциплины, также как и одну и ту же дисциплину могут читать
несколько лекторов, необходимо отказаться от жесткой привязки лектора к
дисциплине в сущности "Лектор", создав дополнительную сущность, которая
будет показывать, как связаны между собой лекторы и дисциплины:
3.2.5. Третья нормальная форма (3NF)
Третья нормальная форма подразумевает атомарность и
функционально полную зависимость атрибутов каждой сущности от ее
первичного ключа. Кроме того, между неключевыми атрибутами сущности
должны отсутствовать транзитивные зависимости, т.е. они должны быть
взаимно независимы.
Таблица находится в третьей нормальной форме, если она
удовлетворяет определению 2НФ и не одно из ее неключевых полей не
зависит функционально от любого другого неключевого поля.
В качестве примера рассмотрим сущность «Сотрудник»
гипотетической Организации, в которую человека принимают на конкретную
должность, а по истечении срока или какой-либо другой причине увольняют. Переходы с одной должности на другую там запрещены:
45
Здесь неключевые атрибуты Название должностиi и Окладi находятся
в транзитивной зависимости.
В чем опасность такой зависимости? Во-первых, несколько человек
могут работать в одной и той же должности. При изменении должностного
оклада в этом случае нужно будет менять данные в каждой записи,
содержащей эту должность. Во-вторых, в организации могут оказаться
уникальные должности, например, начальник, и тогда при увольнении этого
сотрудника (удалении записи) потеряется информация об окладе для этой
должности.
В рассмотренной ситуации нужно было создать новую сущность
"Должность" с находящимися в транзитивной зависимости атрибутами Название должностиi и Окладi и сделать ссылку от "Сотрудника" на
"Должность":
В реальных условиях сотрудник может переходить с одной должности
на другую и может одновременно занимать несколько должностей в своей
организации. В связи с этим нужно создать еще одну сущность, которая
будет фиксировать должностные перемещения сотрудников, перенеся в нее
атрибуты Код должностиi , Дата зачисленияi и Дата увольненияi, и
ссылаться на "Сотрудника" через Табельный номерi:
46
Обычно при моделировании БД нормализацию на этом заканчивают,
так как дальнейшая декомпозиция таблиц замедляет обработку данных.
В заключение рассмотрим еще один пример.
Пример: Имеется сущность "Наряд на изготовление изделий" с
атрибутами: номер наряда, дата и номер смены, на которую выписан наряд,
фамилия, имя, отчество и табельный номер исполнителя, наименование
операции 1, стоимость ее выполнения, необходимое количество1,
наименование операции 2, стоимость ее выполнения, необходимое
количество 2, …, общая стоимость работ. Пусть наряды в каждом цехе
ежедневно нумеруются с единицы.
Чтобы привести сущность к первой нормальной форме, добавим к
приведенному списку атрибут номер цеха. Теперь атрибуты номер цеха ,
дата выписки наряда и номер наряда совместно однозначно характеризуют
каждый ее экземпляр, т.е. являются первичным ключом.
Итак, сущность " Наряд " является отношением, но в ней имеются
избыточная информация и повторяющиеся атрибуты.
Избыточная
стоимость
работ»,
информация
которая
-
вычисляемый
определяется
как
атрибут:
сумма
«Общая
произведений
стоимости выполнения операции на количество операций; удаляем этот
атрибут.
Повторяющиеся атрибуты - наименование, стоимость и количество
для каждого вида операций в текущем наряде. Как уже отмечалось, наличие
повторяющихся атрибутов ведет к снижению коэффициента использования
дисковой памяти. Выделяем из сущности " Наряд " дочернюю сущность 47
"Выполняемая операция". При выделении в дочернюю сущность мигрирует
первичный ключ родительской сущности.
Первичным ключом новой сущности может служить сочетание
мигрировавших
в
нее
ключей
и
наименования
операции.
Однако,
наименование операции может быть очень длинным и потому не подходит
для ключевого поля. Добавляем сюда код операции.
Проверяем неключевые атрибуты сущности "Выполняемая операция"
на зависимость от первичного ключа: наименование и цена зависят лишь от
кода операции. Выделяем их в родительскую сущность "Операция" с
первичным ключом код операции.
3.2.6. Нормальная форма Бойса-Кодда (BCNF)
Рассмотрим внимательно таблицы, представленные на рис. 3.2.2.1.Среди
них таблицы «Блюда» и «Продукты» не удовлетворяют определению 3НФ.
Действительно, в этих таблицах имеются функциональные зависимости
между неключевыми полями:
Блюдо->Вид и Продукт->Калорийность.
48
Следовательно, для приведения таблиц «Блюда» и «Продукты» к 3НФ
их надо разбить на
Блюда(Код блюда, Блюдо),
Вид_блюда(Код блюда, Вид);
Продукты(Код продукта, Продукт);
Калор_прод(Код продукта,Калорийносить),
хотя интуиция подсказывает, что это лишнее разбиение, совсем не
улучшающее проекта базы данных.
Столкнувшись с подобными несуразностями, которые могут возникать
не только из-за введения кодированных первичных ключей, теоретики
реляционных систем Кодд и Бойс обосновали и предложили более строгое
определение для 3НФ, которое учитывает, что в таблице может быть
несколько возможных ключей.
Таблица находится в нормальной форме Бойса-Кодда, если и только
если любая функциональная зависимость между его полями сводится к
полной функциональной зависимости от возможного ключа.
В соответствие с этой формулировкой таблицы «Блюда» и «Продукты»
рис. 3.2.2.1, имеющие по паре возможных ключей (Код блюда, Блюдо) и
(Код продукта, Продукт) находятся в НФБК или в 3НФ.
3.2.7. Четвертая нормальная форма (4NF). Пятая нормальная
форма, или нормальная форма проекции-соединения (5NF или
PJ/NF)
В следующих нормальных формах (4НФ и 5НФ) учитываются не только
функциональные, но и многозначные зависимости между полями таблицы.
Для их описания познакомимся с понятием полной декомпозиции таблицы.
49
Полной декомпозицией таблицы называют такую совокупность
произвольного числа ее проекций, соединение которых полностью
совпадает с содержимым таблицы.
Например, естественным соединением таблиц рис. 3.2.2.1 можно
образовать исходную таблицу, приведенную на рис. 3.2.1.2. Следовательно,
таблицы рис. 3.2.2.1 являются полными декомпозициями таблицы Питание
рис. 3.2.1.2. Теперь можно дать определения высших нормальных форм. И
сначала будет дано определение для последней из предложенных – 5НФ.
Таблица находится в пятой нормальной форме (5НФ) тогда и только
тогда, когда в каждой ее полной декомпозиции все проекции содержат
возможный ключ. Таблица, не имеющая ни одной полной декомпозиции,
также находится в 5НФ.
Четвертая нормальная форма является частным случаем 5НФ, когда
полная декомпозиция должна быть соединением ровно двух проекций.
Весьма не просто подобрать реальную таблицу, которая находилась бы в
4НФ, но не была бы в 5НФ.
4. Разработка инфологических моделей
4.1. Диаграммы "сущность-связь"
Имеется целый ряд методик создания инфологических моделей. Одна
из наиболее популярных в настоящее время методик при разработке моделей
использует ERD (Entity-Relationship Diagrams). В русскоязычной литературе
эти диаграммы называют "объект – отношение" либо "сущность - связь".
Модель ERD была предложена Питером Пин Шен Ченом в 1976г. К
настоящему времени разработано несколько ее разновидностей, но все они
базируются на графических диаграммах, предложенных Ченом.
50
Диаграммы конструируются из небольшого числа компонентов.
Благодаря наглядности представления они широко используются в CASE
средствах (Computer Aided Software Engineering).
Терминология и обозначения
Сущность (Entity) - реальный либо воображаемый объект, имеющий
существенное значение для рассматриваемой предметной области,
информация о котором подлежит хранению.
Каждая сущность должна обладать уникальным идентификатором.
Каждый экземпляр сущности должен однозначно идентифицироваться и
отличаться от всех других экземпляров данного типа (сущности). Каждая
сущность должна обладать некоторыми свойствами:

Иметь уникальное имя; причем к этому имени должна всегда
применяться одна и та же интерпретация (определение сущности). И
наоборот: одна и та же интерпретация не может применяться к различным
именам, если только они не являются псевдонимами.

Обладать одним или несколькими атрибутами, которые либо
принадлежат сущности, либо наследуются ею через связь.

Обладать одним или несколькими атрибутами, которые
однозначно идентифицируют каждый экземпляр сущности.
Сущность может быть независимой либо зависимой. Графическое
обозначение независимой и зависимой сущностей представлено на рис.
4.1.1. Признаком зависимой сущности служит наличие у нее наследуемых
через связь атрибутов.
51
Рис 4.1.1. Графическое обозначение сущностей: А - зависимая, В независимая сущность.
Каждая сущность может обладать любым количеством связей с
другими сущностями модели.
Связь (Relationship) - поименованная ассоциация между двумя
сущностями, значимая для рассматриваемой предметной области.
Одна из участвующих в связи сущностей - независимая, называется
родительской сущностью, другая - зависимая, называется дочерней или
сущностью-потомком.
Как правило, каждый экземпляр родительской сущности
ассоциирован с произвольным (в том числе нулевым) количеством
экземпляров дочерней сущности. Каждый экземпляр сущности-потомка
ассоциирован в точности с одним экземпляром сущности-родителя.
Таким образом, экземпляр сущности-потомка может существовать
только при существовании сущности родителя.
Связи дается имя, выражаемое грамматическим оборотом глагола и
помещаемое возле линии связи. Имя каждой связи между двумя данными
сущностями должно быть уникальным, но имена связей в модели не
обязаны быть уникальными.
Каждая связь имеет определение. Определение связи образуют
соединением имени сущности-родителя, имени связи, выражения степени
связи и имени сущности-потомка.
52
Например, связь продавца с контрактом может быть определена
следующим образом:
 Продавец может получить вознаграждение за 1 или более
Контрактов;
 Контракт должен быть инициирован ровно одним Продавцом.
На диаграмме связь изображается отрезком (ломаной). Концы
отрезка с помощью специальных обозначений (смотри рис. 4.1.2)
указывают степень связи. Кроме того, характер линии - штриховая или
сплошная, указывает обязательность связи.
Рис 4.1.2. Графическое изображение связей
Атрибут - любая характеристика сущности, значимая для
рассматриваемой предметной области. Он предназначен для квалификации,
идентификации, классификации, количественной характеристики или
выражения состояния сущности.
Атрибут представляет тип характеристик(свойств), ассоциированных с
множеством реальных или абстрактных объектов (людей, мест, событий,
состояний, идей, пар предметов и т.д.).
Экземпляр атрибута - это определенная характеристика конкретного
экземпляра сущности. Экземпляр атрибута определяется типом характеристики
(например - "Цвет") и ее значением (например - "лиловый"), называемым
значением атрибута.
53
В ER-модели атрибуты ассоциируются с конкретными сущностями.
Каждый экземпляр сущности должен обладать одним конкретным значением
для каждого своего атрибута.
Атрибут может быть либо обязательным, либо необязательным.
Обязательность означает, что атрибут не может принимать неопределенных
значений (null values). Атрибут (смотри рис. 4.1.3) может быть либо
описательным (т.е. обычным дескриптором сущности), либо входить в состав
уникального идентификатора (первичного ключа).
Рис 4.1.3. Графическое отображение характеристики
атрибута
Уникальный идентификатор - это атрибут или совокупность
атрибутов и/или связей, однозначно характеризующая каждый экземпляр
данного типа сущности.
В случае полной идентификации экземпляр данного типа сущности
полностью идентифицируется своими собственными ключевыми атрибутами,
в противном случае в идентификации участвуют также атрибуты другой
сущности - родителя.
Характер идентификации отображается в диаграмме на линии связи
(Рис. 4.1.4)
54
Рис 4.1.4. Графическое отображение характера
идентификации
Каждый атрибут идентифицируется уникальным именем, выражаемым
грамматическим оборотом существительного, описывающим представляемую
атрибутом характеристику.
Атрибуты изображаются в виде списка имен внутри блока
ассоциированной сущности, причем каждый атрибут занимает отдельную
строку.
Атрибуты, определяющие первичный ключ, размещаются наверху
списка и выделяются знаком "#".
Каждая сущность должна обладать хотя бы одним возможным ключом.
Возможный ключ сущности - это один или несколько атрибутов, чьи значения
однозначно определяют каждый экземпляр сущности.
При существовании нескольких возможных ключей один из них
обозначается в качестве первичного ключа, а остальные - как альтернативные
ключи.
4.2. Методология IDEF1X
Метод IDEF1 (Icam DEFinition) является основной частью программы
ICAM (Интеграция компьютерных и промышленных технологий).
В семейство стандартов IDEF входят также
IDEF0
- Функциональное моделирование
55
IDEF1
- Информационное моделирование
IDEF2
- Поведенческое моделирование
IDEF3
- Моделирование деятельности
DFD
- Моделирование потоков данных
IDEF4
- Объектно-ориентированное проектирование
IDEF5
- Систематизация объектов приложения
IDEF6
- Использование рационального опыта
проектирования
IDEF8
- Взаимодействие человека и системы
IDEF9
- Учет условий и ограничений
IDEF14 - Моделирование сетей
Метод IDEF1 разработан Т.Рэмей (T.Ramey), основан на подходе П.Чена и
позволяет построить модель данных, эквивалентную реляционной модели в
третьей нормальной форме. В настоящее время на основе совершенствования
методологии IDEF1 создана ее новая версия - методология IDEF1X.
IDEF1X разработана с учетом таких требований, как простота изучения
и возможность автоматизации. IDEF1X-диаграммы используются рядом
распространенных CASE-средств (в частности, ERwin, Design/IDEF).
Сущность в методологии IDEF1X называется независимой от
идентификаторов или просто независимой, если каждый экземпляр сущности
может быть однозначно идентифицирован без определения его отношений с
другими сущностями.
Сущность называется зависимой от идентификаторов или просто
зависимой, если однозначная идентификация экземпляра сущности зависит от
его отношения к другой сущности (рис. 4.2.1).
56
Рис 4.2.1. Изображение сущностей и связей.
Каждой сущности присваивается уникальное имя и номер,
разделяемые косой чертой "/" и помещаемые над блоком.
Если экземпляр сущности-потомка однозначно определяется своей
связью с сущностью-родителем, то связь называется идентифицирующей, в
противном случае - не идентифицирующей.
Идентифицирующая связь между сущностью - родителем и сущностью
– потомком изображается сплошной линией.
На рисунке 4.2.1: N2 - зависимая сущность, Связь1 идентифицирующая связь.
Сущность-потомок в идентифицирующей связи является
зависимой от идентификатора сущностью.
Сущность-родитель в идентифицирующей связи может быть как
независимой, так и зависимой от идентификатора сущностью (это
определяется ее связями с другими сущностями).
Пунктирная линия изображает неидентифицирующую связь.
На рисунке 4.2.1: N4 - независимая сущность, Связь2 неидентифицирующая связь.
57
Сущность-потомок в неидентифицирующей связи будет
независимой от идентификатора, если она не является также сущностью потомком в какой-либо идентифицирующей связи.
Связь может дополнительно определяться с помощью указания
степени или мощности (количества экземпляров сущности-потомка,
которое может существовать для каждого экземпляра сущности-родителя).
В IDEF1X могут быть выражены следующие мощности связей:

каждый экземпляр сущности-родителя может иметь
ноль, один или более связанных с ним экземпляров сущностипотомка;

каждый экземпляр сущности-родителя должен иметь не
менее одного связанного с ним экземпляра сущности-потомка;

каждый экземпляр сущности-родителя должен иметь не
более одного связанного с ним экземпляра сущности-потомка;

каждый экземпляр сущности-родителя связан с
некоторым фиксированным числом экземпляров сущности-потомка.
Мощность связи обозначается, как показано на рис. 4,2.2
(мощность по умолчанию - N).
Рис 4.2.2. Мощность связи
Атрибуты изображаются в виде списка имен внутри блока сущности.
Атрибуты, определяющие первичный ключ, размещаются наверху списка и
отделяются от других атрибутов горизонтальной чертой (рисунок 4.2.3. ).
58
Рис 4.2.3. Атрибуты и первичные ключи
Сущности могут иметь также внешние ключи (Foreign Key). При
идентифицирующей связи они используются в качестве части или целого
первичного ключа, при неидентифицирующей служат неключевыми
атрибутами. В списке атрибутов внешний ключ отмечается буквами FK в
скобках.
4.3. Этапы разработки инфологической модели
В данном разделе коротко рассматриваютя два наиболее важных
этапа разработки инфологической модели данных. Подробный анализ этих
этапов на конкретных примерах и его результаты помещены во вторую часть
настоящего пособия.
59
На первом этапе производится анализ входных и выходных форм с
целью выявления информации, подлежащей хранению в базе данных.
Приводятся примеры независимых и зависимых данных, а также
разбираются виды ограничений на значения данных.
На втором этапе выделяются сущности логической модели данных.
Определяются связи между выделенными сущностями. Приводятся
примеры определения имен сущностей и связей между ними.
4.3.1. Анализ выходных форм
Анализ выходных форм осуществляется с целью выявления
информации, подлежащей хранению в базе данных.
Прежде чем создавать базу данных необходимо разобраться, как
протекают процессы, которые будут автоматизироваться с помощью этой
базы. К настоящему времени разработаны специальные языки описания
бизнес-процессов предприятий и поддерживающие их CASE средства. Мы
будем считать, что такой анализ уже произведен, что уже определены (хотя
бы предварительно) выходные формы и можно перейти к разработке
инфологической модели данных.
Разработка инфологической модели данных ведется
последовательно по шагам. Каждый следующий шаг является
детализацией предыдущего. Прототип модели, созданной разработчиком
на каждом шаге разработки, фиксируется и детально обсуждается с
заказчиком. Уточнения и дополнения, выявленные в процессе
обсуждения, также фиксируются, после чего начинается следующий шаг
разработки.
Для выявления информации, подлежащей хранению в БД, будем
анализировать проходящие через систему документы.
60
Документ с точки зрения информационной системы это совокупность
текстовой, числовой и графической информации, расположенной в
соответствии с макетом документа. Макет документа называют выходной
формой, а представленную на нем информацию - данными.
Независимыми или исходными данными, будем называть
элементарные единицы информации, значения которых можно получить
напрямую, т.е. без предварительных вычислений на основании других
данных.
К независимым данным относятся имена объектов системы, их
качественные и количественные характеристики, различные эталонные
значения.
Зависимыми будем называть данные, значения которых могут быть
выведены на основании значений других данных.
Независимые данные должны храниться в БД, в отличие от
зависимых данных, значения которых вычисляются на основании исходных
данных.
Для анализа данных выходной формы необходимо:
1.
Создать список всех упоминаемых в форме данных и для каждого
зависимого данного записать формулу или просто указать, на основании
каких данных оно вычисляется.
2.
Составить список всех независимых данных, включив в него
независимые данные исходного списка, а также независимые данные,
появившиеся в формулах пункта 1.
3.
Для каждого независимого данного подготовить:
- имя данного - существительное в единственном числе с
определением или дополнением, уточняющим принадлежность этого
данного конкретному объекту,
61
-полное определение данного, в котором отметить:

является ли его значение уникальным, т.е. может ли оно
встретиться у нескольких экземпляров объекта; пример:
шифр группы, номер паспорта, номер зачетки - уникальные
данные;

может ли оно изменяться у конкретного экземпляра
объекта; если "да", то в какой ситуации, и нужно ли хранить
историю изменений данного;

может ли один и тот же экземпляр иметь несколько
значений этого данного; пример: у одного студента
несколько экзаменационных оценок, каждая по своей
дисциплине;

особенности данного, например, способ его
формирования;
-ограничения на значения данного, которые задают, исходя из его
типа и характера использования в информационной системе.
4.3.2. Выделение сущностей
Первым этапом построения инфологической модели данных было
составление и согласование списка данных, подлежащих хранению в БД
(смотри раздел 4.3.1). На этом этапе был составлен список независимых
данных и утверждены: "Имена Данных", "Определения Данных" и
"Ограничения на значения Данных".
Теперь на основании этого списка определяется предметная область
модели, то есть выделяются сущности, которые характеризуются
отобранными данными (атрибутами сущностей) и записываются имена
сущностей в таблице.
62
Имя сущности, как и имя атрибута, - существительное в единственном
числе, именительном падеже с возможным определением или дополнением.
При подборе имен сущностей необходимо обращать внимание на характер
данного: определяет оно реальный предмет или процесс, выполняемый с
участием этого предмета.
Последний шаг - определение связей и построение диаграммы
сущность - связь для выделенных ранее сущностей.
Диаграмма строится на уровне сущностей, т.е. сущности
изображаются прямоугольниками и размещаются имена сущностей
внутри этих прямоугольников. Прямоугольник со скругленными
вершинами отображает дочернюю сущность, без скругленных вершин родительскую .
Между сущностями проводятся линии, отмечающие связи, даются
имена этим связям, а также указывается мощность связей.
Имя связи - грамматический оборот глагола, помещается возле линии
связи. Имя каждой связи между двумя данными сущностями должно
быть уникальным, но имена связей в модели не обязаны быть
уникальными. Каждая сущность может обладать любым количеством
связей с другими сущностями модели.
Пример
Связь сущностей "Студент" и "Экзамен" может быть определена
следующим образом:

Конкретный студент сдает [0, 1 или более] экзаменов.

Конкретный экзамен по конкретной дисциплине сдается [ровно 1]
студентом.
Аналогично определяется связь между сущностями "Дисциплина" и
"Экзамен":
63

Конкретная дисциплина выносится на [0, 1 или более] экзаменов.

Конкретный экзамен проводится по [ровно 1] дисциплине.
Имена связей для большей наглядности выделены подчеркиванием,
мощности связей заключены в квадратные скобки [ ].
ER-диаграмма имеет вид:
5. Организация доступа к данным
5.1. Средства ускоренного доступа к данным
Чтобы пользователь чувствовал себя комфортно, время ожидания
ответа на запрос к БД не должно превышать нескольких секунд. В связи с
этим требованием специально разрабатываются методы ускорения выборки,
позволяющие обойтись без полного перебора сток при выполнении
реляционных операций модификации отношений и отбора данных.
Наибольший эффект дают метод индексирования и метод
хеширования значений ключей отношения.
Индексирование - логическая сортировка строк таблицы. Оно
заключается в создании вспомогательных файлов, содержащих
64
упорядоченные списки значений ключей отношения со ссылками на строку
отношения, в которой они находятся. Индексные файлы занимают
дополнительную память, но резко ускоряют поиск, благодаря применению
метода половинного деления. Для одного отношения может быть создано
несколько индексов. Кроме того, можно создавать индекс для нескольких
отношений, если они содержат одинаковые атрибуты, что позволяет ускорить
выполнение операций соединения отношений.
Индексы позволяют находить строки, в которых значения ключевых
полей совпадают с заданным значением или принадлежат заданному
интервалу.
Хеширование (hashing)- использование хэш-функций, которые
вычисляют вес строки таблицы по значению ее ключевых атрибутов.
Результат вычисления хэш-функции - целое число в диапазоне физических
номеров строк таблицы.
Идеальная хэш-функция должна давать разные значения весов для
разных ключевых атрибутов. Но это не всегда возможно. На практике обычно
используют простые хэш-функции, например, f(k) = k mod p, где k - целое
число, первичный ключ отношения, p - простое целое число, mod - операция,
вычисляющая остаток при целочисленном делении. Если ключевой атрибут строка символов, то для вычисления f(k) выбирается один из методов
преобразования строки в число, например, вычисление контрольной суммы.
Для организации доступа к данным при хешировании создается
таблица с пустыми строками, которая заполняется следующим образом:

По первичному ключу новой строки вычисляется значение хэш-
функции f(k) и результат трактуется, как номер строки в созданной таблице.

Если строка уже занята, производится проверка следующих сток
по специальному алгоритму до тех пор, пока не будет обнаружено свободное
место.
65
Аналогично производится поиск нужной строки:

Если после вычисления f(k) на месте в таблице, которое
соответствует вычисленному значению, оказывается пустая строка, значит
искомой строки просто нет.

Иначе (строка занята):

Если значение ключа совпало с искомым, поиск заканчивается.

Иначе (значение не совпало) - проверяются следующие строки до
строки с нужным ключом - строка найдена, или до пустой строки - строка
отсутствует.
Если таблица заполнена не более чем на 60%, то для размещения
новой или поиска существующей строки необходимо проверить в среднем не
более двух ячеек. Хеширование используют для поиска строк по точному
совпадению значения ключевого атрибута кортежа с нужным значением
ключа.
Подробнее о хешировании можно прочитать в книге М., Мир, Т.
Кохонен, Ассоциативная память, 1980г.
5.2. Язык запросов
Для получения информации из БД пользователи направляют в СУБД
запросы. СУБД обрабатывает запросы и отправляет результаты обработки
пользователям. В этом разделе рассматриваются вопросы создания
соответствующих запросов на основе языка SQL. Во всех примерах будут
использованы базы данных Access, однако все рассмотренные методы
использования SQL справедливы для большинства форматов баз данных,
например, таких как Oracle или SQL Server.
66
5.2.1. Язык SQL
SQL (Structured Query Language – язык структурированных запросов)
представляет собой набор программных команд, которые позволяют
разработчику решать следующие задачи:
 получать информацию из одной или нескольких таблиц,
находящихся в одной или нескольких базах данных;
 манипулировать данными в таблицах, вставляя, удаляя и
обновляя записи;
 получать сводную информацию о данных в таблицах (вычислять
итоги, подсчитывать записи, определять минимальные,
максимальные и средние значения);
 создавать, модифицировать или удалять таблицы в базах
данных,
 создавать или удалять индексы (только для баз данных Access).
SQL-операторы создают запросы, которые обрабатываются затем
ядром базы данных. Запрос определяет:
 поля, которые следует обработать;
 содержащие эти поля таблицы;
 диапазон записей;
 при получении записей - порядок их представления.
При получении записей SQL-оператор обычно возвращает их в виде
динамического набора (Dynaset). Динамический набор представляет собой
обновляемый набор записей, реально содержащий указатели на базовые
записи. Динамические наборы являются временными объектами и
прекращают свое существование после закрытия базы данных.
67
5.2.2. Состав SQL-оператора
SQL-оператор состоит из трех составных частей:
 объявления операторов (необъязательные параметры, которые
передаются в SQL-оператор программой);
 управляющий оператор (сообщает ядру обработки запросов
тип операции, например, SELECT или DELETE);
 опциональные объявления (передают ядру обработки запросов
информацию об условиях фильтрации, группировки или
сортировки, например, директивы WHERE, GROUP BY, ORDER
BY).
Структура SQL-оператора имеет следующий вид:
[Объявления параметров] Управляющий оператор [опциональные
объявления]
В квадратных скобках указаны необязательные параметры.
В разделе объявления параметров можно указать параметры,
необходимые для формирования SQL-оператора. Любые величины,
определенные в разделе объявления параметров, должны указываться перед
выполнением SQL-оператора.
Ниже будут рассмотрены следующие часто используемые SQLоператоры:
Оператор
Функция
DELETE FROM Удаляет записи из таблицы
INSERT INTO
Добавляет группу записей в таблицу
SELECT
UPDATE
Возвращает группу записей, размещая их в динамическом наборе
Устанавливает
или таблице значения полей в таблице
68
5.2.3. SQL - оператор SELECT
Оператор SELECT предназначен для реализации алгоритма
возвращения записей (или затребованных полей записей) и размещения
информации в динамический набор или таблицу для дальнейшей
программной обработки. Оператор имеет следующий формат:
SELECT [Опции области действия оператора] Список полей FROM
Список таблиц [Опции межтабличных связей] [Опции выборки и
фильтрации] [Опции сортировки] [Опции группировки]
В квадратных скобках указаны необязательные параметры.
Рассмотрим применение различного наполнения оператора SELECT .
1. Выбор всех полей в таблице
Когда нужно выбрать все поля из указанной таблицы вместо опции
Список полей используется символ (*). Например, оператор
SELECT * FROM Поставки ,
примененный к нашей тестовой базе данных, вернет результирующий
набор записей, представленный на рис. 5.2.3.1.
Рис. 5.2.3.1. Результирующий набор записей
69
2. Выбор из таблицы конкретных полей
Часто бывает необходимым получить из таблицы только избранные поля.
В этом случае их имена следует включить в оператор SELECT. В списке полей
индивидуальные поля должны разделяться запятыми. Кроме того, если имя
поля содержит пробелы, его следует заключить в квадратные скобки. Набор
записей, полученный в результате выполнения приведенного ниже оператора
SELECT, представлен на рис.5.2.3.2.
SELECT Поставки.[Код поставщика], Поставки.Цена,
Поставки.Дата_П FROM Поставки
Рис.5.2.3.2. Результирующий набор записей
3. Выбор полей из нескольких таблиц
Чтобы выбрать данные из нескольких таблиц, необходимо указать
следующее:
 таблицу, из которой выбирается каждое поле;
 поля, из которых выбираются данные;
 отношения между таблицами.
70
Приводя таблицу для каждого поля, перед именем поля указывают имя
таблицы с последующей точкой (например, Поставки.Цена, Поставки.Дата_П
или Поставки.[Код поставщика]). Кроме того, после имени таблицы можно
поставить символ (*), указав тем самым на необходимость включения всех
полей из этой таблицы.
Чтобы указать используемые таблицы, их имена (разделенные запятыми)
следует разместить в директиве FROM оператора SELECT.
Отношения между таблицами указываются в директиве WHERE или
условии JOIN.
Оператор
SELECT Поставщики.Поставщик, Поставки.*, Продукты.Продукт,
Продукты.Калорийность FROM Поставщики, Поставки, Продукты
WHERE (((Поставщики.[Код поставщика])=[Поставки].[Код
поставщика]) AND ((Продукты.[Код продукта])=[Поставки].[Код
продукта]))
предназначен для получения всех полей из таблицы Поставки, поля
Поставщик из таблицы Поставщики и полей Продукт, Калорийность из
таблицы Продукты. На рис. 5.2.3.3 представлен результат выполнения
этого оператора.
71
Рис.5.2.3.3. Результирующий набор записей
Если отбираемые поля принадлежат одной таблице, ее имя перед
именами полей можно опускать. Однако указание имени таблицы перед
каждым полем считается хорошим тоном в программировании. Это позволит
избежать многих потенциальных проблем и повысит читабельность
оператора.
4. Создание вычисляемых полей
В примере на рис.5.2.3.3 использовалась информация о весе продукта
и цене за один килограмм. Предположим, мы хотим получить общую
стоимость заказанного продукта. Для этого в операторе SELECT можно
воспользоваться вычисляемым полем. Вычисляемое поле может быть
получено в результате выполнения арифметической операции над
числовыми полями (например, Вес(кг)*Цена) или строковой операции над
текстовыми полями. К числовым полям можно применять любые
стандартные арифметические операции (+,-,*,/,^). Для строк можно
использовать оператор конкатенации (&). Кроме того, для выполнения
операций над данными в полях можно применять встроенные функции
приложения. Например, функцией MID& можно воспользоваться для
выделения строки из текстового поля; функцией UCASE& - для
преобразования текста в прописные буквы; функцией SQR – для вычисления
квадратного корня.
Рассмотрим пример создания вычисляемого поля расчета общей
стоимости продукта. SQL-оператор имеет следующий вид
SELECT Поставки![Вес (кг)]*Поставки!Цена, Поставки.*
FROM Поставки
На рис. 5.2.3.4 представлен результат выполнения этого оператора.
72
Рис.5.2.3.4. Результирующий набор записей
В этом примере имена вычисляемых полей не были указаны, однако
система выполнения запросов автоматически присваивает эти имена (для
первого расчетного поля Expr1000, для второго Expr1001 и т.д.).
Для задания имени вычисляемому полю потребуется внести
некоторые изменения в синтаксис оператора SELECT. Присвоить имя
вычисляемому полю можно, указав его в директиве AS, которая должна
размещаться непосредственно после выражения. Если необходимо, таким же
способом можно поменять имена обычных полей.
SQL-оператор имеет следующий вид
SELECT Поставки![Вес (кг)]*Поставки!Цена AS [Общая стоимость],
Поставки.* FROM Поставки
На рис. 5.2.3.5 представлен результат выполнения этого оператора.
73
Рис.5.2.3.5. Результирующий набор записей
5. Присвоение таблицам псевдонимов
Указываемые в таблице имена могут быть слишком длинными. Чтобы
минимизировать возможность опечаток при наборе длинных имен, сократить
длину SQL- оператора, таблице можно присвоить псевдоним с помощью опции
AS директивы FROM. С помощью опции AS каждой таблице можно присвоить
уникальный более короткий и удобный псевдоним, который при этом может
использоваться во во всех прочих директивах вместо реального имени таблицы.
Например, оператор
SELECT Поставщики.Поставщик, Поставки.*, Продукты.Продукт,
Продукты.Калорийность FROM Поставщики, Поставки, Продукты
WHERE (((Поставщики.[Код поставщика])=[Поставки].[Код
поставщика]) AND ((Продукты.[Код продукта])=[Поставки].[Код
продукта]))
может быть записан как
SELECT П1.Поставщик, П2.*, П3.Продукт, П3.Калорийность
FROM Поставщики AS П1, Поставки AS П2, Продукты AS П3
74
WHERE (((П1.[Код поставщика])=[П2].[Код поставщика]) AND
((П3.[Код продукта])=[П2].[Код продукта])),
где П1, П2, П3 – псевдонимы таблиц соответственно: Поставщики,
Поставки, Продукты.
Использование псевдонимов значительно упрощает ввод и
читабельность операторов.
6. Опции области действия оператора: ALL, DISTINCT и
DISTINCTROW
В большинстве приложений необходимо выделять все записи,
удовлетворяющие определенному критерию. Для этого используется опция
ALL, размещенная перед списком полей. На самом деле ALL можно не
указывать, поскольку эта опция используется по умолчанию. Таким образом,
следующие два оператора эквивалентны:
SELECT * FROM Продукты
SELECT ALL * FROM Продукты
Иногда бывает необходимым получить только уникальные значения
полей. В этом случае используют опции DISTINCT или DISTINCTROW.
Использование опции DISTINCT приведет к тому, что ядро базы данных вернет
только по одной записи для каждого набора значений выбираемых полей – все
дубликаты будут опущены. Например, при выборе из базы данных полей с
фамилиями и именами можно получить несколько записей с фамилией Сидоров,
но с комбинацией Борис Сидоров может встретится только одна запись.
Если требуется отбросить записи, которые совпадают полностью,
необходимо использовать опцию DISTINCTROW. При этом будут сравниваться
значения всех полей в таблице, независимо от того, выделялись они в операторе
или нет.
75
Предположим, исходная таблица имеет следующий вид:
Применение оператора: SELECT DISTINCT Поставки.Дата_П
FROM Поставки даст следующую результирующую таблицу
А применение оператора: SELECT DISTINCTROW
Поставки.Дата_П FROM Поставки даст другой результат:
76
7. Опции межтабличных связей: JOIN, WHERE
При разработке структуры базы данных для связи таблиц используются
ключевые поля. Эти же ключевые поля применяются в операторе SELECT для
указания отношений (связей) между таблицами, чтобы оперировать
связанными данными.
Для указания отношений между таблицами используются две опции:
JOIN и WHERE.
Опция JOIN имеет следующий базовый формат:
Таблица1 (INNER│ LEFT│ RIGHT) JOIN Таблица2 ON
Таблица1.Ключ1= Таблица2.Ключ2
Ядро выполнения запросов поддерживает три разновидности опции
JOIN: INNER, LEFT и RIGHT. Любой вариант обеспечивает возврат записей,
соответствующих условию JOIN, но все они ведут себя по-разному, когда
встречают записи, не соответствующие этому условию. Особенности всех трех
вариантов опции JOIN описаны в таблице табл. 5.2.3.1.
Таблица 5.2.3.1
Разновидности
JOIN
Записи из левой
таблицы
Записи из правой
таблицы
INNER
Только записи, для
которых есть соответствие в правой таблице
Только записи, для
которых есть соответствие в левой таблице
LEFT
Все записи
Только записи, для
которых есть соответствие в левой таблице
RIGHT
Только записи, для
которых есть соответствие в правой таблице
Все записи
77
Левой считается первая из указанных таблиц (слева от ключевого
слова JOIN), а правой – вторая (справа от ключевого слова JOIN).
Чтобы лучше понять эти концепции, рассмотрим пример с нашей
тестовой базой данных (Таблицы 5.2.3.2 и 5.2.3.3).
Таблица 5.2.3.2
Таблица 5.2.3.3
Примеры трех типов опции JOIN:
1. SELECT Поставки.*, Продукты.* FROM Поставки INNER JOIN Продукты
ON Поставки.[Код продукта]=Продукты.[Код продукта] ;
Результирующая таблица (Таблица 5.2.3.4) :
78
Таблица 5.2.3.4
2. SELECT Поставки.*, Продукты.* FROM Поставки LEFT JOIN Продукты
ON Поставки.[Код продукта]=Продукты.[Код продукта] ;
Результирующая таблица (Таблица 5.2.3.5) :
Таблица 5.2.3.5
3. SELECT Поставки.*, Продукты.* FROM Поставки RIGHT JOIN Продукты
ON Поставки.[Код продукта]=Продукты.[Код продукта] ;
Результирующая таблица (Таблица 5.2.3.6) :
79
Таблица 5.2.3.6
Для связи двух таблиц в опции JOIN можно использовать любые
операторы сравнения ( < , = , > , >=, = , < > ).
Связать две таблицы можно также с помощью опции WHERE, которая
функционирует аналогично INNER JOIN. Опция WHERE выполняет ту же
функцию, что и INNER JOIN. Укажем связь между таблицами 5.2.3.2 и
5.2.3.3 с помощью опции WHERE.
SELECT Поставки.*, Продукты.* FROM Поставки, Продукты WHERE
Поставки.[Код продукта]=Продукты.[Код продукта] ;
Результат выполнения этого оператора представлен в виде таблицы
5.2.3.7 :
Таблица 5.2.3.7
80
Применение опции WHERE для объединения таблиц приводит к
созданию набора записей, предназначенного только для чтения. Для получения
набора записей с возможностью модификации следует пользоваться опцией
JOIN.
8. Опции выборки и фильтрации
Рассматриваемые ниже принципы использования фильтров годятся для
любых SQL-операторов, например, DELETE и UPDATE.
Условия фильтрации в SQL-операторах указываются в опции. Общий
формат опции WHERE имеет следующий вид:
WHERE логическое_выражение
Имеются четыре типа логических операторов, определяющих условие
фильтрации (Таблица 5.2.3.8).
Таблица 5.2.3.8
логическое_выражение
Действие
Comparison
Сравнивает значение поля с указанной величиной
LIKE
Сравнивает значение поля с шаблоном (вроде, А*)
IN
Сравнивает значение поля со списком допустимых
величин
BETWEEN
Сравнивает значение поля с диапазоном величин
Логическое_выражение comparison выполняет сравнение двух
значений. Всего имеется шесть допустимых операторов сравнения (Таблица
5.2.3.9).
81
Таблица 5.2.3.9
Оператор
Описание
<
Меньше
<=
Меньше либо равно
=
Равно
>=
Больше либо равно
>
Больше
<>
Не равно
В любом случае сравниваемые значения должны быть одного типа
(например, оба – числа или оба – строки текста). Сравниваемые значения для
строк и дат должны быть специально отформатированы. Любые строковые
величины, используемые в сравнении, должны заключаться в одинарные
кавычки, например, ‘Студент’, ‘Акад’. Аналогично, даты должны
заключаться в символы (#), например, #12.05.2004#.
Примеры SQL- операторов:
1. Сравнение текстовых (строковых) данных
SELECT * FROM ПРОДУКТЫ WHERE Продукт=’масло’
2. Сравнение числовых данных
SELECT * FROM ПРОДУКТЫ WHERE Калорийность > 500
3. Сравнение дат
SELECT * FROM ПРОДУКТЫ WHERE Дата_П > #12.04.2004#
82
Логическое_выражение LIKE позволяет сравнивать значение поля с
указанным шаблоном. Для создания шаблона применяются символы * и ?.
Например:
LastName LIKE ‘S*’
Titles
LIKE ‘*SQL*
Word
LIKE ‘M???H’
Опция LIKE применяется исключительно для сравнения строк; ее
формат имеет следующий вид:
Выражение LIKE Шаблон
В опции LIKE могут использоваться символы шаблонов и
списки/диапазоны символов. При создании шаблонов можно комбинировать
символы шаблонов и списки символов. При этом списки символов должны
удовлетворять трем критериям.
 Список должен заключаться в квадратные скобки.
 Первый и последний символы диапазона должны разделяться дефисом
(-).
 Диапазон символов должен определяться только в восходящем
порядке.
Список символов можно использовать двояко: стандартное оформление
подразумевает, что проверяемый символ должен попадать в список; если
список предварить восклицательным знаком, то подразумевается, что
проверяемый символ не должен в него попадать. Допустимые элементы
шаблонов для опции LIKE приведены в таблице 5.2.3.10.
83
Таблица 5.2.3.10
Элемент шаблона Что определяет
Пример шаблона
Пример результата
*
Любое количество
любых символов
S*
Sims, Sheep
?
Любой одиночный
символ
An?
And, Ant, any
#
Одиночная цифра
3524#
35242, 35243,35245
[Список]
Одиночный символ
из списка
[c-f]
d, e, f
[!Список]
Одиночный символ
не из списка
[!c-f]
a, b, g, h
комбинация
В зависимости от
вида шаблона
A?t*
Art, antique
Примеры использования опции LIKE:
1. Любая строка, начинающаяся с буквы S
SELECT * FROM Customers WHERE Lastname LIKE ‘S*’
2. Две буквы, вторая L
SELECT * FROM Customers WHERE State LIKE ‘?L’
3. Один символ из списка
SELECT * FROM Customers WHERE MID$ (Lastname, 1, 1) LIKE
‘[a-f]’
Использование опции IN позволяет проверить значение выражения
на совпадение с одной из нескольких величин. Пример оператора
SELECT с опцией IN:
SELECT * FROM Customers WHERE State IN (‘AL’, ‘FL’, ‘GA’)
84
Использование опции BETWEEN позволяет проверить попадание
значения выражения в определенный диапазон. Опция BETWEEN может
применяться для сравнения строк, чисел и дат; она осуществляет включающую
проверку, другими словами, если величина совпадает с граничным значением
диапазона, соответствующая запись включается в результирующий набор.
Кроме того, использование оператора NOT позволяет возвращать записи не
попадающие в заданный диапазон. Формат опции BETWEEN имеет
следующий вид:
Выражение [NOT] BETWEEN Значение1 AND Значение2
Примеры использования опции BETWEEN:
1. Сравнение строк
SELECT * FROM Customers WHERE Lastname BETWEEN ‘M’ AND ‘W’
2. Сравнение чисел
SELECT * FROM [Retail Items] WHERE Retail BETWEEN 1 AND 2.5
3. Сравнение дат
SELECT * FROM Sales WHERE Date BETWEEN #08.01.2003# AND
#08.01.2004#
4. Использование оператора NOT
SELECT * FROM Customers WHERE Lastname NOT BETWEEN ‘M’
AND ‘W’
В опции WHERE можно также комбинировать несколько условий
(например, можно указать критерии фильтрации по нескольким полям). Каждое
отдельное условие должно иметь одну из описанных выше форм. Затем
индивидуальные условия можно комбинировать с помощью операторов AND и
OR.
85
Например:
SELECT * FROM Customers WHERE Lastname = ‘Иванов’ AND
FirstName =’Виктор’
9. Опции сортировки
Оператор SELECT позволяет указывать порядок в котором записи
должны размещаться в возвращаемом наборе. Сортировка записей,
возвращаемых оператором SELECT, выполняется с помощью опции ORDER
BY. Сортировать записи можно как по одному, так и по нескольким полям; при
этом поля должны разделяться запятыми.
По умолчанию устанавливается восходящий порядок сортировки (т.е. A-Z,
1-9). Однако порядок сортировки по каждому индивидуальному полю можно
управлять с помощью ключевого слова DESC после имени поля (ключевое
слово DESC воздействует только на одно поле, а не на все, указанные в опции
ORDER BY.
Примеры использования опции ORDER BY.
1. Сортировка по одному полю
SELECT * FROM Customers ORDER BY Lastname
2. Сортировка по нескольким полям
SELECT * FROM Customers ORDER BY Lastname, FirstName
3. Сортировка в убывающем порядке
SELECT * FROM Customers ORDER BY Lastname DESC, FirstName
10. Опции группировки
Группировка записи осуществляется с помощью опции GROUP BY.
Использование групп записей позволяет создать набор записей, включающий по
одной записи для каждого из возможных значений указанного поля. В
86
большинстве случаев группы создаются на основе только одного поля. Однако в
опции GROUP BY можно указать и несколько полей. При этом результирующие
записи создаются для каждой уникальной комбинации значений полей. Поля в
опции GROUP BY должны разделяться запятыми.
Пример использования опции GROUP BY
SELECT Поставки.Дата_П, Продукты.Продукт
FROM Продукты INNER JOIN Поставки ON Продукты.[Код
продукта] = Поставки.[Код продукта]
GROUP BY Поставки.Дата_П, Продукты.Продукт;
5.2.4. SQL - оператор DELETE
Оператор DELETE предназначен для реализации алгоритма удаления из
таблицы указанных записей.
Оператор имеет следующий формат:
DELETE FROM Имя_ таблицы [ WHERE логическое выражение ]
Опция WHERE является необязательной. Если ее опустить в таблице будут
удалены все записи. Опция WHERE позволяет ограничить диапазон
удаляемых записей, установив для них некоторый критерий.
Ниже приведен пример оператора DELETE, удаляющего записи для всех
пенсионеров из общего списка:
DELETE FROM Список WHERE СоцПоложение = ‘Пенсионер’
После выполнения оператора DELETE записи удаляются окончательно и не
подлежат восстановлению. Единственное исключение делается при
обработке транзакции. Благодаря применению механизма обработки
87
транзакций для восстановления удаленной (с момента последнего оператора
BEGINTRANS) информации можно использовать оператор ROLLBACK.
5.2.5. SQL - оператор INSERT
Оператор INSERT предназначен для реализации алгоритма добавления в
таблицу группы записей.
Оператор имеет следующий формат:
Имя_ таблицы SELECT Оставшаяся часть оператора SELECT
Опция SELECT формируется так же, как и независимый оператор,
обсуждавшийся ранее. Назначение опции SELECT состоит в определении
записей, которые необходимо добавить в таблицу. Оператор INSERT определяет
необходимое действие (т.е. добавление записей) и имя таблицы, над которой оно
выполняется.
Примеры использования оператора INSERT INTO для добавления в
таблицу группы записей:
1. Создание начального списка сотрудников предприятия
SELECT CS.Фамилия & ‘ ‘ & CS.Имя AS ФИО, CS.Адрес, Zp.Город,
ZP.Регион, CS.Фирма INTO Список FROM Сотрудники AS CS,
Территория AS ZP WHERE CS.Код=ZP.Код
С помощью данного оператора создается таблица Список (опция
INTO Список), в которую включаются записи с полями: ФИО, Адрес, Фирма
из таблицы Сотрудники и Город, Регион из таблицы Территория при
установлении связи CS.Код=ZP.Код.
2. Ежемесячное обновление списка сотрудников предприятия
INSERT INTO Список SELECT CS.Фамилия & ‘ ‘ & CS.Имя AS ФИО,
CS.Адрес, Zp.Город, ZP.Регион, CS.Фирма INTO Список FROM
Сотрудники AS CS, Территория AS ZP WHERE CS.Код=ZP.Код
88
5.2.6. SQL - оператор UPDATE
Оператор UPDATE предназначен для реализации алгоритма изменений
значений указанных полей таблицы. Оператор имеет следующий формат:
UPDATE Имя_Таблицы SET Поле = Новое_значение [WHERE
Выражение]
За один раз можно обновить несколько полей таблицы; для этого
нужно указать все необходимые опции
Поле = Новое_значение,
разделенными запятыми. Опция WHERE является не обязательной, если она
опущена, изменения будут внесены во все записи таблицы.
Примеры использования оператора UPDATE для изменения
значений поля для группы записей:
1. Изменение SalesID для группы заказчиков
Customers SET SalesID = ‘EGREEN’ WHERE SalesID=’JBURNS’
Этот оператор изменяет идентификатор продавца для группы заказчиков.
2. Увеличение всех отпускных цен на 5%
UPDATE [Retale items] SET Retale= Retale*5%
5.3. Обработка транзакций
Транзакцией называют неделимую с позиции воздействия на БД
последовательность операций манипулирования данными.
Запросы, выполняемые в СУБД, ориентированных на оперативную
обработку, кардинально отличаются от запросов в аналитических системах.
Примером характерного запроса для системы оперативной обработки данных
может служить запрос: "Есть ли свободные купейные места в поезде №...,
отправляющемся такого-то числа?"
89
Для аналитической системы запрос о железнодорожных билетах имел
бы вид: "Каким будет объем продажи билетов по такому-то направлению в
таком-то квартале?"
Принципиально отличаются и структуры баз данных. В базах,
предназначенных для оперативной обработки запросов, данные хранятся в
нормализованных отношениях. Для обслуживания аналитических систем
создаются специальные многомерные хранилища данных, в которых
накапливается информация из различных источников за большой период
времени.
Не смотря на разные способы организации данных и разные типы
запросов, и в тех и в других СУБД к алгоритмам обработки транзакций
предъявляются одни и те же требования. Это - обеспечение целостности
данных и изолированности пользователей. Для обеспечения этих требований
транзакция должна обладать свойствами атомарности, согласованности,
изолированности и долговечности. Разберем, в чем заключаются эти свойства:
Атомарность. Свойство атомарности требует, чтобы транзакция
выполнялась как единая операция доступа к БД, т. е. транзакция должна быть
выполнена полностью, либо не выполнена совсем. Если какая-либо из частей
операции дала сбой, выполняется откат к состоянию предшествующему
началу транзакции.
Согласованность. Свойство согласованности гарантирует взаимную
целостность данных.
Пример: Пусть в отношении А хранится число кортежей отношения В.
При добавлении нового кортежа в отношение В необходимо изменить
соответствующее значение в отношении А, т.е. транзакция должна содержать
две операции и данные должны быть недоступны для других, пока транзакция
не закончится. С другой стороны, если произойдет сбой, отношение В должно
быть возвращено в исходное состояние.
90
Изолированность Свойство изолированности транзакций означает,
что если транзакция изменяет разделяемые данные (в многопользовательских
системах), они не должны в это время быть доступны пользователям.
Долговечность - если транзакция выполнена успешно, данные должны
быть зафиксированы, т.е. в БД заносятся все результаты ее выполнения и
остаются в ней "навсегда".
До момента завершения транзакции СУБД должна иметь возможность
отменить сделанные транзакцией изменения и вернуться к исходному
состоянию. Этот процесс называется откатом. Нормальное завершение
транзакции - ее фиксация, отменяется либо системой, либо пользователем.
Система отменяет фиксацию при нарушении целостности данных.
Пользователь для отмены фиксации должен подать специальную команду.
Механизмы отката и фиксации транзакций. В настоящее время
применяют два типа механизмов корректного отката и фиксации транзакций:
механизмы, основанные на использовании журнала транзакций, и механизмы,
основанные на тиражировании данных.
В журнал транзакций СУБД автоматически заносит состояние
модифицируемых строк перед началом и после операции. Чтобы система
могла определять моменты начала и завершения транзакций, стандарт языка
SQL предусматривает их выделение. Транзакция начинается с первого SQL оператора, вводимого пользователем, либо стоящего в прикладной программе,
а заканчивается оператором COMMIT WORK либо успешным завершением
программы, которая сформировала транзакцию. Откат производится по
оператору ROLLBACK WORK либо при завершении приложения с признаком
ошибки.
Некоторые диалекты SQL (Sybase) допускают промежуточную
фиксацию транзакции для "длинных запросов".
91
Особенности выполнения транзакций в многопользовательской
системе. В многопользовательской системе с БД в каждый конкретный
момент времени могут работать несколько программ. Однако СУБД может
сохранить изменения, выполненные лишь одной программой. Результаты
изменений данных другими программами будут потеряны. Чтобы этого не
произошло необходимо блокировать все прочие транзакции, пока не
завершится текущая. Также необходимо исключать возможность чтения
незафиксированных изменений. Такая ситуация может возникнуть, если
первый пользователь запустил программу, и она начала транзакцию. Тем
временем второй пользователь использовал данные после выполнения одной
из частей транзакции, но тут первый выполнил откат. Для предотвращения
подобных нарушений целостности данных разработаны правила совместной
обработки транзакций, так называемые правила сериализации:

транзакция не может получить доступ к незафиксированным
данным;

результат совместного выполнения транзакций должен быть
эквивалентен результату их последовательного выполнения в любом порядке.
Механизмы блокировок транзакций. В СУБД сериализация
осуществляется через механизм блокировок той части БД, к которой
транзакция обращается. В зависимости от характера изменений
заблокированной может оказаться вся база данных, ее отдельное отношение,
строка отношения или группа строк. Максимальная производительность
СУБД достигается при блокировке на уровне отдельных строк.
Взаимоблокировки транзакций: Рассмотрим пример возникновения
взаимоблокировки: пусть транзакция Т1 обновляет отношение О1, блокируя
некоторые его строки, а затем пытается модифицировать строки отношения
О2, которые в этот момент заблокированы транзакцией Т2. Транзакция Т1
переводится с состояние ожидания снятия блокировки с О2; но в этот момент
92
Т2 пытается изменить в О1 данные, заблокированные из-за Т1 СУБД
переводит Т2 в состояние ожидания. Обе транзакции заморожены:
Для предотвращения взаимоблокировок СУБД делает специальные
проверки. Если таковая обнаружится, одна из транзакций, та, что началась
позже, прерывается, а вызвавшая ее программа получает сообщение об
ошибке. В связи с этим программы, предназначенные для работы в
многопользовательских системах, должны предусматривать обработку этого
сообщения. Кроме того должно быть оговорено правило: в каком-то порядке
производить изменения отношений, например, всегда сначала обновлять О1, а
затем О2.
Транзакции в распределенных БД. В распределенных БД в одной
транзакции могут модифицироваться отношения физически хранящиеся на
разных узлах сети. Такие транзакции называются распределенными или
глобальными в отличие от локальных транзакций, проводящихся на одном
узле.
Логически распределенная транзакция представляет собой набор
локальных транзакций. СУБД должна так организовать процесс выполнения
распределенной транзакции, чтобы все ее локальные транзакции синхронно
фиксировались на затрагиваемых ею узлах распределенной системы.
Распределенная транзакция должна фиксироваться только в том случае, когда
зафиксированы все составляющие локальные транзакции. Если прерывается
хотя вы одна локальная, должна быть прервана и вся распределенная
транзакция. Этот механизм реализуется - двух стадийной фиксацией
транзакции.

Первая стадия: сервер БД, фиксирующий распределенную
транзакцию, посылает команды приготовиться к фиксации всем серверам узлам сети, задействованным в транзакции. Серверы локальных БД должны
послать отклик о готовности. Если хотя бы один сервер не откликнулся из-за
93
программной или аппаратной ошибки, сервер распределенной БД производит
откат на всех локальный узлах.

Вторая стадия: получены отклики о выполнении локальных
транзакций,
все
локальные
СУБД
готовы
к
фиксации.
Сервер,
обрабатывающий распределенную транзакцию, заканчивает ее фиксацию,
посылая команду зафиксировать транзакцию на все локальные узлы.
Механизм тиражирования данных - альтернативный подход к
выполнению транзакций. Он заключается в отказе от распределенности
данных. Все данные хранятся в одной БД, а на узлах находятся копии этой БД.
Средства тиражирования автоматически поддерживают согласованное
состояние копий, посредством переноса изменений, вносимых в любую из
копий.
Транзакции в такой системе выполняются локально. Благодаря этому
отпадает необходимость в сложной процедуре фиксации, но возникает новая
проблема - обеспечение тождественности данных в узлах сети. Функции
поддержки копий - тиражирования, выполняет специальный модуль СУБД,
называемый репликатором (от Replace).
Схема тиражирования может строиться либо на полном обновлении
измененной таблицы БД на всех узлах системы; либо на обновлении ее
изменившихся записей. Последний способ называется быстрым обновлением.
Если в системе нет необходимости постоянно поддерживать
идентичность данных на всех узлах, репликатор накапливает изменения и в
нужные, определенные алгоритмом моменты производит согласование.
Процесс тиражирования данных протекает автоматически, он скрыт от
прикладных программ.
Достоинства систем тиражирования данных:
94

Уменьшение трафика - потоков данных, передаваемых с одного
узла распределенной системы на другой. Уменьшение трафика происходит за
счет того, что. весь запрос обрабатывается локальной СУБД.

Увеличение скорости обработки запросов за счет увеличения
скорости доступа к данным.

Повышение устойчивости работы системы, поскольку обрыв связи
между узлами не останавливает обработку транзакций.
Недостатки:

Невозможно
полностью
исключить
конфликты
из-за
единовременного изменения одних и тех же данных на разных узлах сети.

Из-за несогласованности копий на разных узлах могут быть
получены разные ответы на одинаковые запросы.
5.4. Средства восстановления после сбоев
Одно из требований к системам хранения данных - надежность
хранения: СУБД должна восстанавливать согласованное состояние данных
после любых аппаратных и программных сбоев. Для восстановления
используют журнал транзакций. С помощью журнала восстанавливается
последнее до сбоя согласованное состояние базы данных. Процесс основан
на механизме отката незавершенных транзакций.
На экстренный случай - физическое уничтожение внешней памяти,
т.е. потерю всей информации БД - не распространяется. Реализация
дублирования - зеркалирование дискового пространства, единственная
возможность спасти систему в этом случае.
95
6. Принципы построения систем, ориентированных на
анализ данных
6.1. Хранилища данных.
В базах, предназначенных для оперативной обработки запросов,
данные хранятся в нормализованных отношениях. Для обслуживания
аналитических систем создаются специальные многомерные хранилища
данных, в которых накапливается информация из различных источников за
большой период времени(.
В связи с этим в них используются специализированные языки,
ориентированные на аналитическую обработку, либо создаются специальные
приложения для решения конкретных аналитических задач.
Другое отличие аналитических систем - иной способ хранения
данных. Это объясняется следующими причинами:
1.
используются большие информационные массивы;
2.
данные практически не обновляются, а лишь добавляются
(процессы накопления и считывания);
3.
большинство задач требует хронологической упорядоченности
данных;
4.
как правило, при решении задач используются обобщенные
данные.
Чтобы подчеркнуть эти отличия, базы данных для аналитических
задач называются Хранилищами Данных (ХД). Данные поступают в
хранилища из самых разных источников: считываются из электронных
архивов, вычисляются системами операционной обработки, присылаются
96
поставщиками информации. Пример представления данных в виде 3-мерного
куба приведен на рис. 6.1.1.
Рис. 6.1.1. Пример 3-мерного куба
Как следствие, данные имеют различную структуру и форматы
представления. Система управления ХД приводит данные к единому формату,
устраняет дублирование и некорректные значения, после чего загружает в
хранилище. Пользователи (аналитики) получают доступ к хранилищу через
клиентские приложения.
Основные задачи, которые требуется решать при создании ХД:
1.
выбор оптимальной структуры хранения с точки зрения
требуемого объема памяти и приемлемого времени отклика на аналитические
запросы;
97
способ первоначального заполнения и последующих пополнений
2.
хранилища;
3.
обеспечение удобства доступа к данным.
Сравнительные характеристики использования данных в системах
операционной и аналитической обработки приведены в таблице 6.1.1.
Таблица 6.1.1.
Система
Свойства
данных
Операционной
обработки
Аналитической обработки
Оперативный поиск, Аналитическая обработка,
Назначение
несложные виды
прогнозирование,
обработки
моделирование
Уровень
Детализированные
агрегации
данные
Время
хранения
Частота
обновления
Критерий
От нескольких
месяцев до одного
года
Агрегированные данные
От нескольких десятков лет и
более
Низкая. Обновление
Высокая.
Обновление малыми
порциями
большими порциями, до
нескольких миллионов
записей за 1 раз
Количество
Скорость выполнения
эффективности транзакций в
сложных запросов и
98
единицу времени
прозрачность структуры
хранения для пользователей
6.2. Модели данных, используемые при построении Хранилищ
Данных
В настоящее время наибольшее распространение получили три вида
моделей хранилищ данных: многомерная, реляционная и комбинированная.
Рассмотрим их подробнее.
Многомерная модель. В многомерной модели данные хранятся в
виде гиперкубов - упорядоченных многомерных массивов. При описании
многомерной модели используют понятия Измерение и Значения :

Измерение - множество, образующее одну из граней куба.
Измерения играют роль индексов, используемых для идентификации
конкретных значений данных.

Значения
-
подвергаемые
анализу
количественные
или
качественные данные, которые находятся в ячейках гиперкуба.
Основные операции манипулирования изменениями:

Сечение - подмножество, в котором фиксировано значение
одного или более измерений.

Вращение
-
изменение
порядка
измерений;
обычно
для
двухмерных сечений (остальные фиксированные) для приведения данных к
форме, удобной для восприятия;

Свертка - замена одного из значений измерения другим -
укрупненным, например, “месяц” заменяется “годом”. Свертка может быть
выполнена только над измерениями, в которых имеется иерархия значений
(житель дома  все жители дома, квартала, улицы, города и т.д.).
99

Детализация - операция, обратная свертке. Например, ВУЗ может
быть детализирован до факультета, факультет до потока, поток до группы, и
т.д.
Главным достоинством многомерной модели является быстрота
поиска данных. Данные находятся на пересечении измерений гиперкуба. Для
их поиска не нужно организовывать связи между таблицами, как это делается
в реляционных СУБД. Благодаря этому, среднее время ответа на сложный
(нерегламентированный) запрос в многомерной модели на 1 - 2 порядка
ниже, чем в реляционной.
Однако:

гиперкуб требует больших объемов дисковой памяти, т.к. в нем
заранее резервируется место для каждого возможного данного;

этот объем резко увеличивается при высокой степени
детализации данных ;

возникают сложности с модификацией данных, поскольку
добавление еще одного измерения требует полной перестройки гиперкуба.
Таким образом, многомерную модель ХД целесообразно
использовать, когда ее объем невелик (не более 10 - 20 гигабайт), а гиперкуб
имеет стабильный во времени набор измерений.
Пример куба: факультеты, семестры, показатели (средняя
детализация: отл - кол-во1, хор - кол-во2, общее количество студентов,
обеспечения учебниками, ....).
Свертка: сведения о наборе одного факультета за все годы обучения.
Сечение - фиксируем: факультет и семестр.
Реляционная модель хранилища. Хранилища данных, построенные
на основе реляционной модели, способны хранить огромные объемы
100
информации, но проигрывают многомерным моделям в скорости выполнения
запросов. В реляционной модели гиперкуб эмулируется СУБД на логическом
уровне. Каждое измерение гиперкуба описывается отдельной - справочной
таблицей, которая заполняется возможными значениями конкретного
описываемого измерения. Фактические данные, наиболее часто
используемые для анализа, группируются в таблице, называемой
“фактологической”.
Строка фактологической таблицы кроме фактических данных,
эквивалентных значениям, хранящимся в ячейках гиперкуба, содержит
ссылки на соответствующие значения данных из справочных таблиц
(измерений). Фактологическая таблица индексируется по сложному ключу,
составленному из индивидуальных ключей справочных таблиц, что
обеспечивает их связь с фактологической.
При малом числе измерений - не более 20, реляционные СУБД
организуются по радиальной схеме. Другое название этой схемы - звезда
(star). При числе измерений более 20, используется схема снежинка
(snowflake).
Схема звезда использует только фактологическую таблицу - дочернее
отношение, и набор справочных таблиц измерений - родительские
отношения. Пример реализации хранилища данных по схеме звезда приведен
на рис.6.2.1. В схеме снежинка появляются дополнительные справочные
таблицы более высокого уровня иерархии, которые детализируют
информацию, хранящуюся в справочных таблицах звезды.
101
Рис.6.2.1. Эмуляция гиперкуба в РСУБД (схема
звезда)
На рис.6.2.2 показана детализация некоторых атрибутов справочных
таблиц Группа обучаемых и Дисциплина. После этой детализации схема
звезда превращается в схему снежинка.
102
Рис.6.2.2. Эмуляция гиперкуба в РСУБД (схема
снежинка)
Комбинация многомерного и реляционного подхода. В последние
несколько лет стали применять комбинированные хранилища данных, в
которых реляционная СУБД объединена с целым набором многомерных.
Реляционная база данных в этом случае является центральным хранилищем и
позволяет накапливать огромные объемы информации. Данные,
необходимые конкретным аналитическим приложениям, выделяются из
центрального хранилища в многомерные базы данных. Каждая многомерная
база хранит информацию по одному из направлений деятельности
организации.
103
Выделенная информация называется киоском данных (Data Marts) или
тематическим хранилищем. Использование киосков позволяет производить
быструю обработку данных при выполнении аналитических запросов.
Создание киосков основывается на том, что ситуации, когда для анализа
необходима вся информация хранилища, возникают редко.
Каждый аналитик (аналитический отдел) обслуживает одно
направление деятельности организации, а реальный объем данных,
необходимых для решения конкретных задач такого отдела, удовлетворяет
требованиям, предъявляемым к многомерным СУБД. Логическая схема
комбинированного хранилища данных приведена на рис.6.2.3.
Рис.6.2.3. Логическая схема комбинированного
хранилища данных
104
Данные поступают в хранилище из разных источников. Процесс
загрузки начинается с приведения данных к единому формату и включает в
себя:

исключение управляющих кодов (TAB, CR, LF, …),

унификацию типов данных,

унификацию представления данных - их приведение к
одинаковым единицам измерения.
Затем производится анализ данных на предмет устранения
дублирующихся и некорректных значений - выбросов, а также
восстановления пропущенных значений.
Последний этап обработки - агрегирование данных, т.е. вычисление
обобщенных статистических показателей для тематических хранилищ.
Обработанные данные загружаются в центральное хранилище, а из
центрального хранилища подкачиваются в киоски данных - тематические
хранилища.
Заключение.
Основная цель проектирования БД – это сокращение избыточности
хранимых данных, а следовательно, экономия объема используемой памяти,
уменьшение затрат на многократные операции обновления избыточных
копий и устранение возможности возникновения противоречий из-за
хранения в разных местах сведений об одном и том же объекте. Так
называемый, "чистый" проект БД ("Каждый факт в одном месте") можно
создать, используя методологию нормализации отношений. Нормализация
должна использоваться на завершающей проверочной стадии
проектирования БД.
105
Практическая реализация рассмотренных в данном учебном пособии
методик проектирования баз данных с применением пакета ERWIN и
многочисленными заданиями приводится во второй части учебнометодического пособия автора: «Базы данных, практические задания».
Список наиболее часто встречающихся сокращений.
AC - автоматизированная система
БД - база данных
БИК - банковский идентификационный код
ГНИ – государственная налоговая инспекция
ЕСПД – Единая система программной документации
ЖЗ – жизненный цикл
ИНН – идентификационный номер налогоплательщика
ИС – информационная система
КПП – код причины постановки на учет
ОКОНХ – общероссийский классификатор отраслей народного хозяйства
ОКПО - общероссийский классификатор предприятий и организаций
ООАП – объектно-ориентированный анализ и проектирование
ОПФ – организационно-правовая форма
ПО – программное обеспечение
СУБД – система управления базами данных
ФС – форма собственности
ЭИС – экономическая информационная система
106
ADM (Application Date Model) – модель данных приложения
AIM (Application Implementation Method) – метод внедрения прикладного ПО
ANSI (American National Standarts Institute) – Американский национальный
институт стандартов
API (Application Programming Interface) – интерфейс прикладного
программирования
AWT (Abstract Window Toolkit) – средство разработки оконного интерфейса
пользователя
BPM (Business Process Model) – модель бизнес процессов
BPM (Business Process Modeler) средство моделирования бизнес-процессов
BPR (Business Process Re) – реинжиниринг бизнес-процессов
CASE (Computer Aided Software Engineering) – автоматизированная
разработка программного обеспечения
CDIF (CASE Data Interchange Format) – формат обмена данными CASE –
средств
CDM (Conception Data Model) – концептуальная модель данных
CDM (Custom Development Method) – метод разработки приложений
пользователя
CMM (Capability Maturity Model) – модель оценки зрелости технологических
процессов в организации
COCOMO (COnstructive COnst MOdel) – конструктивная стоимостная
модель (для оценки затрат на проектирование ПО)
DFD (Data Flow Diagram) – диаграмма потоков данных
107
DOORS (Dynamic Object – oriented Requirements System) – динамическая
объектно-ориентированная система управления требованиями
DWM (Data Warehouse Method) – метод создания хранимых данных
ERD (Entity – Relationship Diagram) – диаграмма «сущность – связь»
ERX (Entity – Relationship eXpert) – средство построения диаграмм
«сущность – связь»
FR (Function Point) – функциональная точка
GUI (Graphical User Interface) – графический интерфейс пользователя
HTML (Hyper Text Markup Language) – стандартный язык для создания
страниц Интернет
ICAM (Integrated Computer Aided Manufacturing) – интегрированная
компьютеризация производства
IDEF0 (Icam DEFinishion) – методология моделирования программы ICAM
IEC (International Electro technical Commission) – Международная комиссия
по электротехнике
IEEE (Institute of Electrical and Electronics Engineers) – институт инженеров
по электротехнике и электронике
IPM (Interface Presentation Model) – модель представления интерфейса
ISA (Information System Architecture) – архитектура информационной
системы
ISM (Interface Specification Model) – модель спецификации интерфейса
ISO (International Organization for Standardization – Международная
организация по стандартизации
LAN (Local Area Network) – локальная сеть
108
LOC (Lines of Code) – количество строк кода
MFC (Microsoft Foundation Classis) – библиотека базовых классов Microsoft
NATO (North – Atlantic Treaty Organization) – НАТО, Североатлантический
союз
OLE (Object Linking and Embedding) – технология связывания и встраивания
объектов
OMT (Object Modeling Technique) – метод объектного моделирования
OOSE (Object – Oriented Software Engineering) – объектно-ориентированная
разработка ПО
PDS (Primary Data Structure) – структура первичных данных
PJM (Project Management Method) – метод управления проектом
PMI (Project Management Institute) – Институт проектного менеджмента
RAD (Rapid Application Development) – быстрая разработка приложений
RDM (Relational Data Model) – реляционная модель данных
RDM (Relational Data Modeler) – модуль реляционного моделирования
SADT (Structured Analyses and Design Technique) – метод структурного
анализа и проектирования
SE (Software Engineering) – программная инженерия (проектирование и
разработка ПО)
SEI (Software Engineering Institute) – Институт программной инженерии
SoDA (Software Document Automation) – автоматизированное
документирование ПО
SPM (System Process Model) – модель процессов системы
109
SPR (Software Productivity Research) – название компании
SQL (Structured Query Language) - структурированный язык запросов
TCP/IP (Transmission Control Protocol / Internet Protocol) – протокол
управления передачей / протокол Интернет
UML (Unified Modeling Language) – универсальный язык моделирования
VBX (Visual Basic eXtention) – управляющие элементы для использования в
среде Visual Basic
WRM (Workgroup Repository Manager) – менеджер репозитория рабочей
группы
Список литературы
1.
В.В.Корнеев, А.Ф.Гарев, С.В.Васютин, В.В.Райх Базы
данных. Интелектуальная обработка информации. - М.: "Нолидж",
2000
2.
А.М.Вендров Проектирование прогаммного обеспечения
экономических
информационных
систем.
-
М.:
"Финансы
и
статистика", 2000
3.
А.Л.Фридман
Основы
объектно-ориентированной
разработки программных систем. - М.: "Финансы и статистика", 2000
4.
Г.Н.Калянов CASE структурный системный анализ. - М.:
"Лори", 1996
110
5.
А.М.Вендров CASE-технологии. Современные методы и
средства проектирования информационных систем. - М.: "Финансы и
статистика", 1998
6.
С.В.Маклаков BPwin и ERwin CASE-средства разработки
информационных систем. - М.: "ДИАЛОГ-МИФИ", 2000
7.
Н.Ю.Баженова Visual FoxPro 6.0 - М.: "ДИАЛОГ-
МИФИ", 2000
8.
Р.Пэддок, Д.Петерсен, Р.Тэлмейдж Visual FoxPro 6.0
Разработка корпоративных приложений. - М.: "ДМК", 1999
9.
Л.Н.Омельченко Самоучитель Visual FoxPro 6.0 - СПб.:
"БХВ - Санкт-Петербург", 1999
10.
Г. Джексон Проектирование реляционных баз данных
для использования с микроЭВМ: Пер. с англ. – М.: Мир, 1991.
11.
С.М. Диго Проектирование и использование баз данных:
- Учебник. М.: Финансы и статистика, 1995.
111
Похожие документы
1. Концептуальное проектирование базы данных
1. Концептуальное проектирование базы данных
Временная таблица всегда привязана к ... завершению данной сессии.
Временная таблица всегда привязана к ... завершению данной сессии.
Скачать
реклама