4. нормализация заполненных реляционных таблиц.

А.В. Брешенков, Губарь А.М.
Издательство МГТУ им. Н.Э. Баумана
А.В. Брешенков
Проектирование
баз данных
на основе информации
табличного вида
Допущено
в качестве учебного пособия
для студентов высших учебных заведений,
обучающихся по направлению
подготовки дипломированных специалистов
“Информатика и вычислительная техника”
Москва
Издательство МГТУ имени Н.Э. Баумана
2006
2
УДК 681.5(075.8)
Рецензенты
Брешенков А.В.
Проектирование баз данных на основе информации табличного вида: Учебн.
пособие для вузов. –
М.: Изд-во МГТУ им. Н.Э. Баумана, 2006. – 150 с.
Рассмотрены вопросы проектирования баз данных на основе использования
информации, представленной в табличной форме. Описаны алгоритмы построения
реляционных таблиц на базе информации табличного вида, алгоритмы нормализации
заполненных таблиц, алгоритм назначения ключевых
алгоритмы
формирования
связей
между
полей в заполненных таблицах,
заполненными
таблицами,
алгоритм
объединения заполненных таблиц. Даны рекомендации по использованию предложенных
средств. Приведены примеры использования систем управления базами данных для
решения задач проектирования баз данных на основе информации табличного вида.
Содержание учебного пособия соответствует разделу курса лекций, который автор читает
в МГТУ им. Н.Э. Баумана, а также лабораторным и курсовым работам.
Для студентов вузов, обучающихся по направлению подготовки дипломированных
специалистов в области информатики и вычислительной техники.
3
ПРЕДИСЛОВИЕ ................................................................................................ 7
1. АНАЛИЗ ПРОБЛЕМЫ ПРОЕКТИРОВАНИЯ РЕЛЯЦИОННЫХ БАЗ
ДАННЫХ НА ОСНОВЕ ИСПОЛЬЗОВАНИЯ ИНФОРМАЦИИ ТАБЛИЧНОГО
ВИДА ................................................................................................................. 9
1.1. ПОНЯТИЕ ИНФОРМАЦИИ ТАБЛИЧНОГО ВИДА ........................................... 9
1.2. МОТИВЫ ПРЕОБРАЗОВАНИЯ ИНФОРМАЦИИ ТАБЛИЧНОГО ВИДА В ФАЙЛЫ
РЕЛЯЦИОННЫХ БАЗ ДАННЫХ
...................................................................... 13
1.3. ОСНОВНЫЕ ТРЕБОВАНИЯ К СРЕДСТВАМ ПРЕОБРАЗОВАНИЯ ИНФОРМАЦИИ
ТАБЛИЧНОГО ВИДА В РЕЛЯЦИОННЫЕ ТАБЛИЦЫ ............................................ 15
1.4. ЗАДАЧИ ОБЪЕДИНЕНИЯ И РАЗБИЕНИЯ РЕЛЯЦИОННЫХ ТАБЛИЦ .............. 17
1.5. ЗАДАЧИ НОРМАЛИЗАЦИИ РЕЛЯЦИОННЫХ ТАБЛИЦ ................................. 19
1.6. ПРЕОБРАЗОВАНИЕ РЕЛЯЦИОННЫХ НОРМАЛИЗОВАННЫХ ТАБЛИЦ В ФАЙЛЫ БД
................................................................................................................ 21
1.7. ВОПРОСЫ ПРЕОБРАЗОВАНИЯ ЭЛЕКТРОННЫХ ТАБЛИЦ ........................... 23
УПРАЖНЕНИЯ И ВОПРОСЫ ДЛЯ САМОКОНТРОЛЯ .......................................... 31
2. ПОСТАНОВКА ЗАДАЧИ ПРОЕКТИРОВАНИЯ РЕЛЯЦИОННЫХ БАЗ
ДАННЫХ НА ОСНОВЕ ИСПОЛЬЗОВАНИЯ ИНФОРМАЦИИ ТАБЛИЧНОГО
ВИДА ............................................................................................................... 32
2.1. УКРУПНЕННАЯ МОДЕЛЬ РЕЛЯЦИОННОЙ БАЗЫ ДАННЫХ .......................... 32
2.2. УКРУПНЕННАЯ МОДЕЛЬ ИНФОРМАЦИИ ТАБЛИЧНОГО ВИДА ..................... 38
2.3. ЗАДАЧИ ПРЕОБРАЗОВАНИЯ ЗАПОЛНЕННЫХ НЕРЕЛЯЦИОННЫХ ТАБЛИЦ В
РЕЛЯЦИОННЫЕ ТАБЛИЦЫ ........................................................................... 40
УПРАЖНЕНИЯ И ВОПРОСЫ ДЛЯ САМОКОНТРОЛЯ .......................................... 44
3. ПРЕОБРАЗОВАНИЕ НЕРЕЛЯЦИОННЫХ ТАБЛИЦ В РЕЛЯЦИОННЫЕ
ТАБЛИЦЫ ....................................................................................................... 45
3.1. ПРИВЕДЕНИЕ ЗНАЧЕНИЙ АТРИБУТОВ ЗАПОЛНЕННЫХ ТАБЛИЦ К ОДНОМУ ТИПУ
................................................................................................................ 46
3.2. ИСКЛЮЧЕНИЕ
ДУБЛИРОВАНИЯ ЗАПИСЕЙ ............................................. 57
УПРАЖНЕНИЯ И ВОПРОСЫ ДЛЯ САМОКОНТРОЛЯ .......................................... 63
4. НОРМАЛИЗАЦИЯ ЗАПОЛНЕННЫХ РЕЛЯЦИОННЫХ ТАБЛИЦ. .......... 64
4.1. ПРОБЛЕМЫ НОРМАЛИЗАЦИИ................................................................ 64
4.2. МОДЕЛИ ИНФОРМАЦИИ ТАБЛИЧНОГО ВИДА И РЕЛЯЦИОННЫХ ТАБЛИЦ. ... 67
4.2.1. Модель информации табличного вида ....................................... 67
4.2.2. Модель реляционной таблицы .................................................... 71
4
4.3. ПРЕОБРАЗОВАНИЕ ЗАПОЛНЕННЫХ ТАБЛИЦ К ПЕРВОЙ НОРМАЛЬНОЙ ФОРМЕ
................................................................................................................ 73
4.3.1. Избавление от сложных атрибутов........................................... 73
4.3.2. Исключение подзаголовков расположенных внутри таблицы . 79
4.3.3. Нормализация заполненных таблиц с подзаголовками в
первом столбце....................................................................................... 88
4.4. ПРЕОБРАЗОВАНИЕ ЗАПОЛНЕННЫХ ТАБЛИЦ КО ВТОРОЙ НОРМАЛЬНОЙ ФОРМЕ
................................................................................................................ 98
4.5. ПРЕОБРАЗОВАНИЕ ЗАПОЛНЕННЫХ ТАБЛИЦ К ТРЕТЬЕЙ НОРМАЛЬНОЙ ФОРМЕ
.............................................................................................................. 111
4.6. ПРЕОБРАЗОВАНИЕ
ЗАПОЛНЕННЫХ ТАБЛИЦ К ЧЕТВЕРТОЙ НОРМАЛЬНОЙ
ФОРМЕ. ................................................................................................... 126
УПРАЖНЕНИЯ И ВОПРОСЫ ДЛЯ САМОКОНТРОЛЯ ........................................ 143
5. НАЗНАЧЕНИЕ КЛЮЧЕВЫХ ПОЛЕЙ ...................................................... 145
5.1. ЗАДАЧА НАЗНАЧЕНИЯ КЛЮЧЕВЫХ ПОЛЕЙ В ЗАПОЛНЕННЫХ РЕЛЯЦИОННЫХ
ТАБЛИЦАХ ............................................................................................... 145
5.2. АЛГОРИТМЫ НАЗНАЧЕНИЯ КЛЮЧЕВЫХ ПОЛЕЙ В ЗАПОЛНЕННЫХ РЕЛЯЦИОННЫХ
ТАБЛИЦАХ ............................................................................................... 146
УПРАЖНЕНИЯ И ВОПРОСЫ ДЛЯ САМОКОНТРОЛЯ ........................................ 159
6. ВЫЯВЛЕНИЕ И ФОРМИРОВАНИЕ СВЯЗЕЙ МЕЖДУ ЗАПОЛНЕННЫМИ
ТАБЛИЦАМИ ................................................................................................. 160
6.1. ВЫЯВЛЕНИЕ И ФОРМИРОВАНИЕ СВЯЗЕЙ ОДИН - К ОДНОМУ .................. 160
6.2. ВЫЯВЛЕНИЕ И ФОРМИРОВАНИЕ СВЯЗЕЙ ОДИН - КО МНОГИМ................ 168
6.3. ВЫЯВЛЕНИЕ И ФОРМИРОВАНИЕ СВЯЗЕЙ МНОГИЕ - КО МНОГИМ. ........... 177
УПРАЖНЕНИЯ И ВОПРОСЫ ДЛЯ САМОКОНТРОЛЯ ........................................ 194
7. ОБЪЕДИНЕНИЕ ТАБЛИЦ ...................................................................... 195
7.1. ПРОБЛЕМЫ ОБЪЕДИНЕНИЯ ТАБЛИЦ ................................................... 195
7.2. ОБЪЕДИНЕНИЕ И ОБНОВЛЕНИЕ СОВМЕСТИМЫХ ТАБЛИЦ ..................... 203
7.3. ОБЪЕДИНЕНИЕ ТАБЛИЦ, ЧАСТИЧНО УДОВЛЕТВОРЯЮЩИХ ТРЕБОВАНИЯМ
СОВМЕСТИМОСТИ .................................................................................... 211
УПРАЖНЕНИЯ И ВОПРОСЫ ДЛЯ САМОКОНТРОЛЯ ........................................ 224
8. РАЗРАБОТКА И ИССЛЕДОВАНИЕ МОДЕЛИ МЕТОДИКИ
ПРОЕКТИРОВАНИЯ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ НА ОСНОВЕ
ИСПОЛЬЗОВАНИЯ ИНФОРМАЦИИ ТАБЛИЧНОГО ВИДА ..................... 225
8.1. ПОСТАНОВКА ЗАДАЧИ РАЗРАБОТКИ МОДЕЛИ МЕТОДИКИ ...................... 225
5
8.2. ОПЕРАТОРНАЯ МОДЕЛЬ ПРЕОБРАЗОВАНИЯ ИНФОРМАЦИИ ТАБЛИЧНОГО ВИДА К
РЕЛЯЦИОННЫМ БАЗАМ ДАННЫХ ................................................................ 231
8.3. ИССЛЕДОВАНИЕ МЕТОДИКИ ПРЕОБРАЗОВАНИЯ ИНФОРМАЦИИ ТАБЛИЧНОГО
ВИДА В РЕЛЯЦИОННЫЕ БАЗЫ ДАННЫХ ....................................................... 247
8.4. ИССЛЕДОВАНИЕ ДИНАМИЧЕСКИХ СВОЙСТВ ФУНКЦИОНИРОВАНИЯ СИСТЕМЫ.
.............................................................................................................. 262
8.5. ИССЛЕДОВАНИЕ ВРЕМЕННЫХ СВОЙСТВ СИСТЕМЫ. ............................. 268
УПРАЖНЕНИЯ И ВОПРОСЫ ДЛЯ САМОКОНТРОЛЯ ........................................ 290
СПИСОК ЛИТЕРАТУРЫ............................................................................... 291
6
ПРЕДИСЛОВИЕ
Сегодня
трудно
переоценить
значение
информации
и
информационных систем. Особое место в составе информационных
систем принадлежит базам данных (БД). В настоящее время осталось
мало
таких
областей
человеческой
деятельности,
где
бы
не
использовались БД. При этом потребность в БД и в системах управления
базами данных (СУБД) постоянно растет.
К числу наиболее распространенных
относятся
реляционные
модели.
моделей построения БД
Достоинства
реляционной
модели
побудили к проведению большого числа теоретических и практических
разработок в области теории проектирования реляционных БД, в области
инструментальных средств, ориентированных на создание реляционных
БД.
Однако до сих пор существуют значительные объемы информации,
которые желательно использовать в составе реляционных БД, но по
своему представлению информация не удовлетворяет
требованиям этих
БД. Так как ценность накопленной информации зачастую превосходит
ценность БД и СУБД, то существует потребность в методах и средствах,
которые
позволят
нереляционного вида
обеспечить
преобразование
информации
в реляционные БД. Этим вопросам и посвящена
работа.
Глава 1 посвящена анализу проблемы проектирования реляционных
баз данных на основе использования информации табличного вида.
Вводится понятие
информации табличного вида, обсуждаются мотивы
преобразования информации табличного вида в файлы реляционных баз
данных,
рассматриваются
основные
требования
к
средствам
преобразования информации табличного вида в реляционные таблицы,
рассматриваются
задачи проектирования реляционных баз данных на
основе использования информации табличного вида.
7
В главе 2 изложена постановка задачи проектирования реляционных
баз
данных
на
основе
использования
существующей
информации
табличного вида, рассмотрены укрупненные модели реляционной БД и
информации табличного вида, сформулированы задачи преобразования
заполненных нереляционных таблиц в реляционные таблицы.
В главе 3 анализируются проблемы преобразования нереляционных
таблиц в реляционные таблицы,
анализируются проблемы приведения
значений атрибутов заполненных таблиц к одному типу.
В
главе
реляционных
4
рассмотрены
таблиц.
В
методы
частности,
нормализации
заполненных
сформулированы
проблемы
нормализации, описаны методы приведения заполненных таблиц к первой,
второй, третьей и четвертой нормальным формам.
Глава
5
посвящена
методу
назначения
ключевых
полей
в
заполненных нереляционных таблицах.
В главе 6 рассмотрены методы выявления и формирования связей
между заполненными таблицами. В частности, связей один - к одному,
связей один - ко многим, связей многие - ко многим.
В главе 7 выполнен анализ ситуаций, при которых возникает
необходимость объединения заполненных реляционных таблиц, приведен
алгоритм объединения таблиц.
8
1. АНАЛИЗ ПРОБЛЕМЫ ПРОЕКТИРОВАНИЯ
РЕЛЯЦИОННЫХ БАЗ ДАННЫХ НА ОСНОВЕ
ИСПОЛЬЗОВАНИЯ ИНФОРМАЦИИ ТАБЛИЧНОГО
ВИДА
1.1. Понятие информации табличного вида
Под информацией табличного вида понимается информация, которая
интерпретируется заинтересованными в ней людьми
двумерными
таблицами. При этом интуитивно или формально выделяются столбцы
таблицы, ее строки и заголовки столбцов. Это могут быть словари,
каталоги, прайс-листы, ведомости, табели учета и др.
человеческой
деятельности,
связанных
с
Во всех сферах
обработкой
документов
различного типа, широко используется информация табличного вида.
Например:
ведомости
зарплат,
прайс-листы,
каталоги,
ведомости
экзаменов, справочники и т.д. Представление информации в таком виде
настолько популярно, что это способствовало появлению целого класса
программных систем,
табличной
специально ориентированных на работу с
информацией
-
электронных
таблиц,
которые
по
распространенности уступают только текстовым процессорам.
Форма представления информации табличного вида может быть
самой различной: на бумаге, в виде текстового файла, в виде файла
электронных таблиц и др. Вид представления
информации табличного
вида также самый разнообразный. В частности, разделителями столбцов
и
строк
могут
быть
обычные
символы,
специальные
символы,
непечатаемые символы, линии или пробелы. Разделители могут и
отсутствовать. В этом случае подразумевается, что пользователь может
интуитивно выделить строки и столбцы, например, правые
границы ячеек выровнены, а начало следующей
и левые
строки таблицы
определяется самой широкой ячейкой предыдущей строки. Заголовки
столбцов могут иметь или не иметь подзаголовки, а те, в свою очередь,
подзаголовки
более
низкого
уровня.
Информация,
принадлежащая
9
заголовкам и информационным единицам, может располагаться в одной
или нескольких строках ячейки. Информация табличного вида может быть
сгруппирована в соответствии с различными критериями, и тогда внутри
таблиц появляются подзаголовки. Информация, расположенная в ячейках
одного столбца не всегда одного типа. Например, срок поставки может
быть указан в формате даты или в текстовом формате. Строго говоря,
информация такого вида не всегда является данными - информацией,
фиксированной
в
определенной
форме.
Это
и
многое
другое
обуславливают, с одной стороны, не всегда однозначное восприятие и
интерпретацию
информации ее потребителями, а с другой стороны
зачастую приводит к невозможности ее автоматизированной обработки.
На рис.1.1 приведена типичная таблица каталога, набранная в
текстовом редакторе.
Рис. 1.1. Таблица каталога, набранная в текстовом редакторе
В ней нет разделителей заголовков, нет разделителей строк,
присутствуют
подзаголовки.
Все
эти
разделители
интуитивно
воспринимаются человеком, но представляют неразрешимую проблему
для компьютера. Ни одно из существующих программных средств не
переведет эту таблицу хотя бы в формат электронных таблиц, не говоря
10
уже о том, чтобы получить реляционную таблицу, которую можно сразу
использовать в существующей БД или вновь проектируемой.
На рис.1.2. представлен результат импорта этого текстового файла в
формат электронной таблицы Microsoft Excel.
Рис.1.2. Результат импорта текстового файла в формат электронной
таблицы Microsoft Excel
Результат говорит сам за себя: несколько столбцов объединились, а
некоторые остались раздельными. Из-за отсутствия разделителей строк в
результирующей таблице смешаны строки, и понять, какие данные
относятся к какой строке практически невозможно.
Несколько лучше выглядит результат импорта в формат Microsoft
Excel той же таблицы, если она была предварительно сформирована в
формате Microsoft Word. На рис. 1.3 представлен результат импорта файла
в формате Microsoft Word в формат электронной таблицы Microsoft Excel. В
данном случае просматриваются столбцы таблицы. Однако заголовки
столбцов смещены, расположены в нескольких ячейках.
11
Рис. 1.3. Результат импорта файла формата Microsoft Word в формат
электронной таблицы Microsoft Excel
На рис.1.4 приведена таблица, в которой один столбец содержит
информацию разного типа: текстовую и цифровую.
Рис.1.4. Таблица с данными различного типа в одном столбце
Перевод такой таблицы в формат реляционной таблицы базы данных в
автоматическом режиме в принципе невозможен без корректировки данных
оператором.
12
1.2. Мотивы преобразования информации табличного вида
в файлы реляционных баз данных
Под файлами реляционных БД понимают файлы данных и вспомогательные файлы, которые созданы разработчиками БД и средствами СУБД
для обеспечения функционирования БД. Файлы данных представляют
собой информацию табличного вида, хранимую в форме реляционных
таблиц данных, а также файлы ключевых и индексных полей. Вспомогательные или системные файлы генерируются, как правило, автоматически
средствами СУБД и могут быть просмотрены, а иногда скорректированы
администратором БД. Пользователь БД доступа к этим файлам обычно не
имеет и часто не подозревает об их существовании. Строгий формальный
подход к хранению и обработке информации табличного вида в
реляционных
БД,
продуманный
механизм
сопровождения
данных
обуславливают сведение к минимуму неоднозначную интерпретацию
информации, непротиворечивость данных и надежность их хранения.
В каких случаях оправданно преобразование информации табличного
вида в файлы реляционных баз данных?
В
настоящее
время
существует
множество
документов
с
информацией табличного вида, представленной только на бумаге. Например, многостраничные сводки экспериментов, справочники, словари и т.п.
Это обусловлено тем, что документы, не утерявшие актуальность,
подготовлены на печатной машинке, тем, что утеряны электронные формы
документов, тем, что до настоящего времени не все имеют доступ к
вычислительной технике, а также другими причинами. Не вызывает сомнения,
что
обеспечивается
электронная
форма
документов
предпочтительней
-
возможность оперативного и удобного редактирования,
модификации и обработки данных. Информацию табличного вида,
представленную на бумаге, оправданно
преобразовать в формат
электронных таблиц, а во многих случаях и в формат баз данных. Это
связано с тем, что системы этих классов обладают специальными средствами работы с данными табличного вида.
13
Немало информации табличного вида, как показано на рис.1.1 и рис
1.3,
существует в текстовом формате или в формате Microsoft Word. Но
потребности пользователей этой информации таковы, что им удобнее
работать с ней, используя средства СУБД.
Значительная часть информации табличного вида сегодня хранится в
формате электронных таблиц. Несмотря на неоспоримые достоинства
программных систем данного класса, во многих случаях они не позволяют
в полном объеме решать многие проблемы. В частности, БД по сравнению
с электронными таблицами обладают следующими преимуществами:
-
БД позволяют не только вводить данные в таблицы, но и
контролировать правильность вводимых данных (их соответствие
назначенному типу, их соответствие принятому формату, их
соответствие условию на значение);
-
БД могут хранить огромное количество записей и при этом СУБД
обеспечивают удобные способы извлечения из этого количества
нужной информации;
-
если все необходимые для работы данные хранить в электронных
таблицах, то по мере накопления информации легко запутаться в
большем объеме файлов. БД позволяют хранить все данные в
одном
файле,
и
доступ
к
этим
данным
осуществляется
постранично, т.е. не превышаются ограничения на ресурсы
памяти компьютера;
-
в БД возможно создание связей между таблицами, что позволяет
совместно использовать данные из нескольких таблиц, при этом
для пользователя они будут представляться одной таблицей;
-
предоставляя связи между отдельными таблицами, БД позволяют
избежать дублирования данных, сэкономить память компьютера, а
также увеличить скорость и точность обработки информации;
-
у БД значительно больше возможностей при работе нескольких
пользователей с одними и теми же данными. При этом все
пользователи гарантированно будут работать с актуальными
данными;
-
БД имеют развитую систему защиты от несанкционированного
доступа, которая позволяет каждому пользователю или категории
14
пользователей видеть или изменять только те объекты, на
которые ему были выданы права администратором системы.
Проблемы преобразования информации табличного вида в файлы БД
стоят во многих организациях. В частности, нередко на предприятиях
информация о проданном оборудовании поступает из различных регионов
в виде файлов Microsoft Excel. В главном офисе компании установлена БД,
в которой накапливаются и обрабатываются данные из регионов.
Преобразование таблиц Microsoft Excel в формат БД осуществляется
вручную. Работы такого рода трудоемки, а результаты преобразования не
гарантируют отсутствия
ошибок.
Многие предприятия подготовили
каталоги изделий в виде текстовых файлов. Сейчас возникла потребность
разработки БД, основу которой составляют эти каталоги. Не вызывает
сомнения то, что существует и ряд других ситуаций, когда организации
остро нуждаются в эффективных средствах преобразования информации
табличного вида в файлы БД.
Таким образом, на основании сказанного выше,
можно сделать
вывод о том, что проблема преобразования информации табличного вида
в файлы реляционных баз данных актуальна. И работы в данном
направлении представляют практический интерес. Это справедливо как
для документов табличного вида, представленных на бумаге, так и для
документов, хранящихся в электронной форме, будь то текстовые файлы,
файлы текстовых процессоров или файлы электронных таблиц.
1.3. Основные требования к средствам преобразования
информации табличного вида в реляционные таблицы
Для
того,
чтобы
обеспечить
возможность
преобразования
информации табличного вида в таблицы реляционных БД, ее, прежде
всего, необходимо привести к реляционному представлению данных.
Реляционная таблица представляет собой двумерный массив и обладает
следующими свойствами:
-
каждый элемент таблицы - один элемент данных;
15
-
все столбцы таблицы однородные, т.е. все элементы в столбце
имеют одинаковый тип;
-
каждый столбец имеет уникальное имя;
-
одинаковые строки в таблице отсутствуют;
-
порядок следования столбцов и строк может быть произвольным
[1].
Из сказанного выше об информации табличного вида следует, что этими
свойствами она в общем случае не обладает. Более того, заголовки
столбцов исходных таблиц могут располагаться на нескольких строках, в
заголовках столбцов могут присутствовать недопустимые с точки зрения
БД символы (".","!" и др.), элементы данных могут располагаться на
нескольких строках. Все это недопустимо для реляционных таблиц.
В
связи с этим первым необходимым шагом методики преобразования в
файлы реляционных баз данных является генерация таблиц, обладающих
перечисленными свойствами на основе исходных таблиц. Для решения
этой проблемы необходимо разработать формальную модель информации
табличного вида, формальную модель реляционных таблиц и на основе их
использования разработать средства, обеспечивающие преобразование
формы представления данных от одного вида к другому. Естественное
пожелание, чтобы эти средства были автоматическими, в крайнем случае,
автоматизированными.
В
качестве
текстовые
исходного
файлы
или
вида
информации
электронные
таблицы.
оправданно
Если
принять
информация
представлена на бумаге, ее можно отсканировать и распознать в какомлибо текстовом редакторе и получить текстовые файлы. Если информация
представлена в виде электронных таблиц, проблемы преобразования не
снимаются, и поэтому иногда имеет смысл электронные таблицы
преобразовать в текстовые файлы. Конечно, проблема преобразования
информации
табличного
вида,
которая
в
формате
электронных таблиц, в файлы БД имеет свою специфику,
поэтому
средства преобразования информации
представлена
должны ее учитывать эту
специфику.
Программа-обработчик текстового файла должна в первую очередь
выделить заголовки таблицы. При этом необходимо:
16
-
выделить строки текста, содержащие заголовки;
-
исключить подзаголовки (если они есть) и преобразовать их в
заголовки или дать возможность сделать это пользователю;
-
преобразовать
многострочные
заголовки
в
однострочные
заголовки;
-
обнаружить недопустимые с точки зрения БД символы;
-
сформировать строку из заголовков таблицы;
-
запомнить позиции столбцов для использования их в дальнейшем
при выделении данных.
Далее программа должна выделять данные из информации табличного
вида. При этом необходимо:
-
определять
символы
разделения
строк
таблицы
или
дать
возможность сделать это пользователю;
-
преобразовывать многострочные данные в однострочные данные;
-
обнаруживать несоответствия типов данных, относящихся к
одному
столбцу,
и
давать
возможность
пользователю
редактировать данные или откладывать записи в отдельный файл
для последующей обработки;
-
располагать данные, относящиеся к одной записи таблицы, в одну
строку в позиции, соответствующие запомненным ранее позициям
заголовков столбцов;
В процессе формирования целевого текстового файла необходимо
обеспечить
включение
символов-разделителей
столбцов,
которые
впоследствии будут использованы при распознавании таблиц в БД. Для
организации
этого
лингвистические
потребуются
процесса,
средства
вероятно,
для
интерактивные
потребуются
управления
средства
для
заданием.
несложные
Кроме
разрешения
того,
проблем
преобразования пользователем, в случае если решение их не очевидно. В
программе необходимо предусмотреть интерактивное средство обработки
отложенных записей.
1.4. Задачи объединения и разбиения реляционных таблиц
17
Если
удастся
преобразовать
информацию
табличного
вида
в
реляционные таблицы, то это не всегда означает, что их можно
непосредственно преобразовывать в формат БД. Может потребоваться
объединение нескольких таблиц в одну. Это обусловливается различными
причинами.
В частности:
- информация, которую нужно включить в БД, поступает от нескольких
контрагентов;
- в существующей БД, в
которую вводятся новые данные,
используется таблица, объединяющая в себя информацию из нескольких
включаемых таблиц.
С другой стороны, может возникнуть обратная проблема, которая
связана с преобразованием одной таблицы в несколько таблиц.
Это может произойти:
- когда данные из таблицы, включаемые в существующую БД, в ней
уже представлены несколькими таблицами;
- когда таблица в БД не удовлетворяет условиям нормализации [2].
Одним из самых простых случаев является случай, когда несколько
одинаковых по сути таблиц необходимо объединить в одну. Решение
задачи может свестись к выбору исходной таблицы и добавлению в эту
таблицу записей с данными из других таблиц. Однако, если столбцы
исходных таблиц не расположены в одинаковой последовательности, то
исходные таблицы необходимо предварительно преобразовать к нужному
виду. Кроме того, в соответствии с требованиями к таблицам БД их записи
должны быть уникальны, т.е. в них должны отличаться значения хотя бы
одного поля. Это требование далеко не всегда выполняется, например,
когда в исходных таблицах записи отличаются только порядковыми
номерами, а эти номера в различных таблицах могут совпадать. В связи с
этим
может
возникнуть
необходимость
добавления
в
таблицу
специального ключевого поля, значение которого должно быть уникальным
для каждой записи.
Более сложным является случай, когда необходимо объединить нескольких дополняющих по данным друг друга таблиц в одну. При этом
18
число и смысловая нагрузка столбцов исходных таблиц может не
совпадать.
Тогда,
проблемы.
Для
кроме
проблем
объединения,
возникают
решения
задачи
объединения
такого
новые
характера
необходимо выявить поля в исходных таблицах, по которым можно
провести объединение. Эти поля должны присутствовать во всех таблицах
и
иметь
одинаковую
смысловую
нагрузку.
Такие
поля
называют
ключевыми. После чего необходимо формировать записи целевой
таблицы из записей исходных таблиц, при этом критериями формирования
новых записей являются одинаковые значения ключевых полей в исходных
таблицах. Кроме того, в процессе формирования записи необходимо
исключать заголовки и данные одинаковых столбцов.
В случае необходимости разбиения одной таблицы на несколько
таблиц,
следует
руководствоваться
критериями
эффективности
построения новой БД на основе использования исходных таблиц. В
частности, необходимо руководствоваться требованиями нормализации
таблиц. Если БД уже существует, то необходимо руководствоваться составом таблиц БД, их структурой и связями между таблицами.
При
разбиении таблиц необходимо иметь в виду, что пользователю БД может
потребоваться
обработка
информации
из
нескольких
таблиц
одновременно. Поэтому между результирующими таблицами необходимо
обеспечить связи, например, через механизм первичных и внешних
ключей.
Для качественного, бездефектного решения задач объединения и
разбиения реляционных таблиц необходима разработка формальных
моделей
исходных
и
целевых
таблиц,
формальной
методики
преобразования таблиц.
1.5. Задачи нормализации реляционных таблиц
После того, как информация приведена к реляционной форме, нет
никакой гарантии, что эти таблицы самые удачные с точки зрения их
представления и использования в БД. Дело в том, что одни и те же данные
могут группироваться в различные отношения (таблицы). Определенный
19
набор отношений обладает лучшими свойствами при манипуляциях с БД,
если он отвечает требованиям нормализации отношений. Нормализация
отношений
-
формальный
аппарат
ограничений
на
формирование
отношений, который позволяет устранить дублирование, обеспечить
непротиворечивость хранимых данных, уменьшает затраты на ведение баз
данных. Вопросы приведения отношений к нормальным формам широко
освещены в литературе по теории построения БД, в частности в [1-6].
Чаще
всего
выделяют
4-е
нормальные
формы
представления
реляционных таблиц. Нет никаких гарантий того, что реляционные
таблицы, полученные после этапов преобразования, удовлетворяют этим
правилам. Более того, они, скорее всего, нормальным формам не
удовлетворяют.
Если данные из реляционных таблиц добавляются к таблицам существующей, нормализованной БД, а структура добавляемых данных
совпадает со структурой таблиц БД, то проблема нормализации не стоит,
т.к. предполагается, что БД спроектирована, нормализована и изменениям
не подлежит.
Если данные из реляционных таблиц добавляются к таблицам существующей, нормализованной БД, а структура добавляемых данных не
совпадает со структурой таблиц БД, то возникает проблема нормализации
и преобразования структур добавляемых данных.
Если создается новая БД или к существующей БД добавляются новые
таблицы, то проблема нормализации актуальна.
В связи с этим
следующим этапом преобразования информации табличного вида в
файлы БД должен быть этап нормализации реляционных таблиц.
Реляционные таблицы находятся в 1-й нормальной форме, если
значения в таблице являются атомарными для каждого атрибута таблицы.
Другими словами в таблице не должно быть подзаголовков. Этому
требованию, если следовать предложенным этапам преобразования
информации, реляционные таблицы уже должны удовлетворять.
Реляционные таблицы находятся во 2-й нормальной форме, если
никакие неключевые атрибуты не являются функционально зависимыми
лишь от части ключа. Таким образом, эта форма может быть нарушена
только в том случае, если ключ составной (состоит из нескольких полей).
20
Для
выявления нарушений такого рода необходимо проанализировать
смысловое значение полей таблицы. Вероятнее всего, это лучше сделать
человеку.
Однако
есть
надежда,
что
этот
процесс
можно
автоматизировать.
Реляционные таблицы соответствуют 3-й нормальной форме, если
устранены транзитивные зависимости между атрибутами отношения.
Другими словами, неключевые поля таблицы не должны зависеть друг от
друга, а должны зависеть только от ключевого поля. Опосредовано
выявить нарушение нормализации такого рода можно, если обнаружить
часто повторяющиеся поля или группы полей в записях таблицы. В связи с
этим процесс приведения к 3-й нормальной форме можно автоматизировать, что и реализовано в некоторых системах управления базами
данных, в частности в Microsoft Access. Однако результаты нормализации
после
использования
предлагаемых
средств
не
всегда
удовлетворительны, и в этом направлении имеет смысл работать.
Реляционные таблицы соответствуют 4-й нормальной форме, если
между реляционными таблицами устранены многозначные зависимости.
Между таблицами имеет место многозначная зависимость, если записи
одной таблицы связаны с несколькими записями другой и наоборот. Для
устранения многозначной зависимости вводится третья таблица, в которой
хранятся ключевые поля первых 2-х таблиц. Многозначную зависимость
между таблицами можно описать формально. В связи с этим, вероятнее
всего, процесс приведения реляционных таблиц к 4-й нормальной форме
можно автоматизировать.
1.6. Преобразование реляционных нормализованных
таблиц в файлы БД
Чтобы выполнить преобразование реляционных нормализованных
таблиц в файлы БД, лучше всего, в случае возможности, воспользоваться
средствами самих СУБД. Во всех развитых СУБД предусмотрены средства
импортирования данных.
21
В частности, Microsoft Access позволяет импортировать данные,
представленные в различных форматах - в
HTML, Microsoft Excel,
текстовом формате и др. Это существенно упрощает решение проблемы
преобразования таблиц в файлы БД.
В случае, если на основе имеющихся таблиц создается новая БД, то
необходимо создать
БД, импортировать в нее таблицы
и, используя
средства СУБД, построить необходимые связи между таблицами.
Если в существующую БД добавляются новые таблицы, необходимо
открыть БД, импортировать в нее таблицы и, используя средства СУБД,
построить необходимые связи между таблицами.
Наиболее сложный случай, если данные из таблиц дополняются к
таблицам, уже имеющимся в БД. В этой ситуации могут возникнуть все
проблемы, рассмотренные выше. Эти проблемы в значительной степени
можно решить до импортирования таблиц. Однако в полном объеме их
решить удается не всегда. В любом случае таблицы необходимо
импортировать в БД с именами, не совпадающими с именами таблиц,
содержащихся в БД. Затем создать запросы на добавление данных в
таблицы БД из импортированных таблиц. Учитывая особенности объединения
таблиц различного вида, запросы на объединение таблиц могут
быть сложными. Для упрощения решения задач формирования запросов
на добавление таблиц оправданна разработка формальных моделей
исходных и целевых таблиц, а также формализованной методики
построения необходимых запросов.
В системе Oracle предусмотрено специализированное средство для
перемещения данных - SQL*Loader. В нем
в процессе перемещения
данных формируются файлы отвергнутых и некорректных записей записей, которые по каким-либо причинам не могут быть включены в БД.
Это, с одной стороны, говорит о том, что проблема преобразования
информации табличного вида в файлы БД актуальна (коль скоро ею
занимается самая крупная в мире корпорация в области БД), а, с другой
стороны, эта проблема не всегда имеет корректное решение.
Средства экспорта-импорта СУБД, а также другие механизмы обмена
данными, например ODBC, до определенной степени обеспечивают
универсальность методики преобразования информации табличного вида
22
в файлы реляционных баз данных и независимость от используемой
СУБД.
1.7. Вопросы преобразования электронных таблиц
Системы, ориентированные на работу с электронными таблицами
(ЭТ) в настоящее время являются одними из самых популярных
программных систем. Это обусловлено рядом их достоинств и, кроме того,
простотой их использования и наглядностью представления информации.
В связи с этим ЭТ широко распространены и, если необходима работа с
информацией табличного вида, в первую очередь обращаются к какимлибо средствам работы с ЭТ. Зачастую это оправданно, но не всегда.
Нередко это выясняется, когда таблицы построены и в них размещены
большие объемы данных. Эти данные с определенного момента начинают
сами по себе представлять ценность, зачастую большую ценности
программных систем, с помощью которых они хранятся и обрабатываются.
И
если
системы,
ориентированные
на
работу
с
ЭТ
перестают
удовлетворять их пользователей, то возникает проблема переноса
накопленной информации в другие системы хранения и обработки данных.
При этом желательны минимальные издержки.
Преимущества баз данных (БД) по сравнению с ЭТ обсуждаются в
ряде работ, в частности в [5,6]. В связи с этими преимуществами часто
возникает необходимость перехода к БД от ЭТ. Ниже рассматриваются
ситуации, когда такая необходимость возникает.
1. В процессе интенсивной работы с ЭТ создается множество таблиц,
которые логически связаны между собой. В этом случае очень часто
возникает
необходимость анализа информации сразу из нескольких
таблиц. В ЭТ такого рода манипуляции над данными чрезвычайно
затруднительны, а в БД - естественны.
2. Очень часто в ЭТ, даже в составе одной книги, хранится несколько
таблиц с одинаковыми столбцами. Это приводит к неэффективному
использованию памяти компьютера. Установка связей между отдельными
таблицами в БД позволяет избежать ненужного дублирования.
23
3. Объем информации, хранимой в ЭТ, в процессе работы с ЭТ может
достигнуть значительных объемов. Это приводит к тому, что информация
становится необозримой или ресурсы хранения информации достигают
пределов возможностей систем, с помощью которых она обрабатываются.
В БД гораздо проще, чем в ЭТ построить пользовательский интерфейс,
ориентированный на
информации.
Кроме
эффективную работу с большими объемами
того,
современные
БД
позволяют
хранить
и
обрабатывать очень большие объемы данных – сотни гигабайтов или
терабайтов данных.
4. Хранимая в таблицах информация нередко носит конфиденциальный
характер. Кроме того, эта информация может не представлять интерес для
определенных категорий пользователей. Организовать многоуровневую
защиту от несанкционированного доступа в системах, ориентированных на
работу с ЭТ, чрезвычайно сложно. В БД для этого предусмотрены
специальные механизмы.
5. Для ЭТ зачастую необходимо обеспечить многопользовательский
доступ. В соответствующих системах число пользователей ограничено
несколькими десятками. В современных БД обеспечивается совместная
работа тысяч пользователей.
6. С ростом объема хранимой информации все более актуальной
становится проблема безопасности данных, их сохранности и возможности
восстановления при утере. В СУБД в отличие от ЭТ детально продуманы
вопросы сжатия и восстановления
данных, их защита,
резервное
копирование.
7. При работе с ЭТ в ячейки одного и того же столбца можно ввести
данные различных типов. Иногда это оправданно, а зачастую недопустимо
(например, в случае ошибочного ввода данных). СУБД обеспечивает
автоматическую проверку данных на соответствие заранее определенному
типу. Более того, СУБД обеспечивает не только контроль вводимых типов
данных, но и правильность самих данных. Для этого реализуется
возможность описания правил проверки данных.
Это далеко не полный перечень причин, которые могут привести к
необходимости преобразования ЭТ к таблицам БД. Однако есть и причина
другого характера.
24
Как показывает опыт работы с реальными БД, нередко возникает
необходимость сбора данных, представленных в различных форматах, и
добавления их в существующую БД. Чаще всего данные, добавляемые в
БД, представлены в формате ЭТ. Такая технология обработки данных на
сегодня имеет широкое распространение и часто оправданна.
Даже если такая технология предусмотрена изначально и структура
электронных таблиц полностью соответствует структуре таблиц БД, то все
равно возникают проблемы преобразования ЭТ в таблицы БД.
Если БД и ЭТ создавались независимо друг от друга и структура
электронных таблиц не соответствует структуре таблиц БД, то проблема
преобразования усугубляется.
Таким образом, можно сделать вывод о том, что необходимость
преобразования ЭТ в таблицы БД может возникнуть, как минимум, в двух
случаях:
- когда системы управления ЭТ не удовлетворяют пользователей;
- когда возникает необходимость импорта ЭТ в существующую БД.
Из сказанного выше следует, что зачастую возникает необходимость
преобразования ЭТ в таблицы БД. Поэтому средства, реализующие такое
преобразование, востребованы.
Во многих современных СУБД имеются средства импорта ЭТ в
таблицы БД. Однако, в подавляющем большинстве случаев эти средства
неприемлемы для формирования полноценных БД, удовлетворяющих
современным требованиям. Они работают только тогда, когда ЭТ
представлены реляционными таблицами. В общем случае, а, как правило,
и
в
частностях,
ЭТ
не
являются
реляционными.
Требования
к
реляционным таблицам широко освещены в специальной литературе,
например в [2]. К числу основных причин несоответствия ЭТ реляционным
таблицам можно отнести следующие причины:
- в заголовках столбцов ЭТ зачастую имеют место подзаголовки, что
недопустимо в реляционных таблицах;
- типы данных, расположенных в одноименных столбцах очень часто
не совпадают, что также недопустимо;
- ячейки в ЭТ могут быть пустыми, что неприемлемо в БД;
25
- внутри таблицы могут быть подзаголовки таблицы, что совершенно
неприемлемо;
- в заголовках столбцов и в ячейках часто присутствуют недопустимые
с точки зрения БД символы (например, точка);
-
записи в ЭТ могут совпадать, а это неприемлемо в БД в
большинстве случаев;
- содержимое одного из столбцов может служить в качестве
заголовков строк, что недопустимо в реляционных таблицах.
Невозможность использования таблицы в формате Microsoft Excel
непосредственно
в
БД
нетрудно
видеть
из
реального
примера,
представленного на рис. 1.5.
Рис. 1.5. Пример таблицы в формате Microsoft Excel
Даже
из
подзаголовками,
небольшого
столбцы
фрагмента
со
таблицы
значениями
видны
различного
столбцы
типа.
с
Это
неприемлемо для реляционных таблиц.
Лучший
результат,
который
можно
получить
после
автоматизированного преобразования с помощью средств импорта БД
системы Microsoft Access, представлен на рис. 1.6.
26
Рис.1.6. Результат импорта таблицы в формате Microsoft Excel в
формат БД Microsoft Access
Несмотря на то, что Microsoft Access
Microsoft
Excel
преобразования
(как
разработки
не могут
быть
одной
очень хорошо сочетается с
корпорации),
использованы
без
результаты
дополнительных
модификаций структуры таблицы и ее содержимого. В частности,
заголовки таблицы необходимо исправлять, типы двух последних (на
рисунке) столбцов менять, значения отдельных столбцов корректировать.
Учитывая то, что в данной таблице более 50-и полей и около 1000 строк
выполнение названных манипуляций трудоемко. Анализируя содержимое
таблицы, нетрудно сделать вывод о том, что она избыточна. В частности,
в столбцах “Поле1”, ”Город”, ”Продавец”, ”Сегмент”, ”Тип оборудования”
имеет место дублирование значений. Кроме того, в процессе импорта
сформировалась таблица с ошибками импорта, которую разработчику БД
необходимо проанализировать и принять решение по модификации
соответствующих записей.
Выполним попытку преобразования подобной таблицы (рис. 1.7) в
формат Microsoft SQL Server.
27
Рис. 1.7. Пример таблицы в формате Microsoft Excel
В
результате
выполнения
всех
действий,
необходимых
для
выполнения импорта в формат Microsoft SQL Server, будет сформирована
таблица, представленная на рис. 1.8.
Рис.1.8. Результат импорта таблицы в формате Microsoft Excel в
формат БД Microsoft SQL Server
Результат преобразования также малоутешительный. В частности,
часть заголовков расположилась в области данных, имеются пустые
записи, некоторые заголовки отсутствуют.
28
Опыт импорта реальных ЭТ в БД показывает, что это далеко не
полный
перечень
несоответствий
ЭТ
требованиям
из
выше,
к
реляционным
таблицам.
Как
следует
сказанного
при
импорте
в
БД
не
преобразованной должным образом ЭТ, возникает множество ошибок
различных типов. При этом исправление ошибок чрезвычайно трудоемкий
процесс. Причем неисправленные или незамеченные ошибки приводят в
лучшем случае к утере информации, а в худшем случае - к ее
противоречивости. Использование БД, построенных на таблицах такого
рода, приносит не пользу, а вред.
С другой стороны, даже если импортируемая таблица создана или
преобразована должным образом, проблемы построения полноценных
реляционных таблиц в результате импорта полностью не снимаются.
Возникают
вопросы
формирования
ключевых
полей,
исключения
избыточности, формирования связи с другими таблицами. Реляционная БД
– это, в первую очередь, связанные реляционные таблицы. О наведении
связей между таблицами в процессе импорта ЭТ не может быть и речи.
Этот процесс не формализован и не может быть формализован до тех
пор, пока не проведены мероприятия, специально ориентированные на
формирование первичных и внешних ключевых полей.
Суммируя
сказанное,
можно
сделать
вывод
о
том,
что
преобразовывать ЭТ нужно, как минимум, по следующим причинам:
- ЭТ в общем случае не являются реляционными;
- ЭТ, как правило, не подготовлены для наведения связей между
ними;
- в ЭТ затруднен одновременный доступ к данным расположенных в
различных таблицах;
- ЭТ не обладает преимуществами БД.
К
настоящему
программное
времени
обеспечения,
не
в
разработаны
полном
объеме
математическое
и
удовлетворяющие
рассмотренным требованиям к средствам преобразования ЭТ в таблицы
БД. С другой стороны, эти средства представляют интерес. В связи с этим
является актуальной проблема решения теоретических и практических
вопросов преобразования ЭТ в таблицы БД.
29
На сегодня сложилась методика проектирования реляционных
БД,
которая освещена в источниках по проектированию БД [1,2]. Следуя ей,
разработчик может выполнить этапы проектирования от постановки
задачи,
инфологического
физической
и
реализации
датологического
и
создать
проектирования
высокоэффективную
до
БД,
удовлетворяющую современным требованиям. Опять же, следуя методике,
разработчик может в рамках всех этапов проектирования грамотно
построить реляционные таблицы, удовлетворяющие всем нормальным
формам. Рекомендации по проектированию БД помогают разработчику
назначить ключевые и индексные поля, сформировать связи между
таблицами, обеспечить безопасность данных и выполнить много полезных
мероприятий,
ориентированных
на
разработку
высококачественного
программного продукта. Другими словами, сегодня разработчик БД
вооружен
мощной
инструментальных
теорией
средств,
построения
БД
ориентированных
на
и
множеством
построение
БД
различного назначения в рамках этой теории. В связи с этим возникает
вопрос - насколько применима существующая теория и инструментальные
средства для преобразования ЭТ в таблицы БД.
Вся проблема в том, что в рассматриваемом случае данные уже есть,
таблицы
сформированы,
и,
конечно,
при
их
создании
никто
не
руководствовался теоретическими аспектами построения БД. Чаще всего
эти
аспекты
при
создании
электронных
таблиц
неактуальны,
их
разработчик решал другие задачи. Таким образом, при построении ЭТ
выпадают все этапы проектирования БД. Выполнить
же положения,
характерные для этапов построения БД в процессе преобразования ЭТ к
БД, о которых идет речь, не представляется возможным. Если их
выполнять, необходимо спроектировать новую БД, а затем вручную
перенести данные из ЭТ в таблицы БД. Это, может быть, и оправданно,
если данных немного. Здесь же речь идет о ситуации, при которой в ЭТ
накоплены значительные объемы информации. Желательно процесс
преобразования сделать автоматизированным, а лучше автоматическим.
Таким образом, теоретические положения поэтапной разработки баз
данных в рассматриваемом случае неприемлемы – приходится исходить
из таких представлений ЭТ, которые уже сформированы.
30
Могут ли быть полезными другие положения теории построения
реляционных БД для разработки математических и программных средств,
ориентированных на преобразование ЭТ в таблицы БД? Вероятнее всего,
да. Требования к реляционным таблицам четко сформулированы, и можно
описать
целевые
функции,
позволяющие
осуществить
автоматизированное преобразование существующих ЭТ к реляционным
таблицам.
Условия
нормализации
таблиц
формализованы
и
представляется возможным формализовать процесс нормализации одной
или совокупности заполненных реляционных таблиц. Кстати, некоторые
средства автоматизированной нормализации таблиц на основе анализа
содержащихся в них данных уже существуют, в частности в Microsoft
Access. Рекомендации к ключевым и индексным полям имеют место и их
можно
использовать
для
автоматизированного
назначения
соответствующих полей.
Обобщая вышесказанное, можно сделать вывод о том, что отдельные
положения современной теории построения реляционных БД могут быть
использованы при разработке методов и средств автоматизированного
преобразования ЭТ в таблицы реляционных БД. Однако необходима
дополнительная формализация, которая позволила бы учитывать то, что
таблицы БД формируются на основе уже имеющихся данных и их
представлений.
Резюмируя все сказанное, можно сделать вывод о том, что имеется
насущная
необходимость
преобразования
ЭТ
в
таблицы
БД,
существующие программные средства не удовлетворяют современным
требованиям преобразования, существующая теория построения БД не
позволяет решить все проблемы преобразования, необходимо решение
новых теоретических и практических вопросов.
Упражнения и вопросы для самоконтроля
1. Что такое информация табличного вида?
2. Какие существуют формы представления информации табличного
вида?
31
3. Какие проблемы возникают при импорте информации табличного
вида в БД?
4. Какие существуют мотивы преобразования информации табличного
вида в таблицы БД?
5. В чем актуальность преобразования информации табличного вида в
таблицы БД?
6. Сформулируйте основные требования к средствам преобразования
информации табличного вида в таблицы БД.
7. Сформулируйте задачи объединения и разбиения реляционных
таблиц.
8. Сформулируйте задачи нормализации реляционных таблиц.
9. Когда возникает необходимость преобразования электронных
таблиц в форматы таблиц БД?
2. ПОСТАНОВКА ЗАДАЧИ ПРОЕКТИРОВАНИЯ
РЕЛЯЦИОННЫХ БАЗ ДАННЫХ НА ОСНОВЕ
ИСПОЛЬЗОВАНИЯ ИНФОРМАЦИИ ТАБЛИЧНОГО
ВИДА
2.1. Укрупненная модель реляционной базы данных
32
БД – это взаимосвязанные объекты данных. К объектам БД относятся
таблицы, индексы, ключи, представления.
К СУБД относятся хранимые процедуры, формы, отчеты, макросы.
Кроме БД и СУБД имеются инструментальные средства, в рамках
которых и посредством которых разрабатываются БД и СУБД. К ним
относятся такие системы как Oracle, Microsoft SQL Server, Microsoft Access,
Clarion и многие другие. Эти системы также нередко называют СУБД. И в
этом
есть
резон,
так
как,
во-первых,
посредством
этих
систем
разрабатываются БД и СУБД, а, во-вторых, БД и СУБД функционируют под
управлением этих систем.
Некоторая терминологическая путаница сложилась в связи с историей
развития
методов
разрабатывались
и
и
средств
обработки
использовались
данных.
еще
БД
до
и
СУБД
появления
специализированных средств, на них ориентированных.
На рис. 2.1 представлено схематическое изображение названных
компонентов и их взаимосвязи. В рамках этого представления в
рассматриваемом случае речь идет о БД, причем рассматриваются
реляционные БД.
Инструментальные средства
БД
Пользователь БД
СУБД
Пользователь БД
33
…
Рис. 2.1. Основные компоненты баз данных
Реляционную БД можно определить как набор взаимосвязанных
реляционных таблиц, относящихся к одной предметной области. Если в
рамках одной БД задействованы реляционные таблицы из разных
предметных областей, то будем считать, что это несколько различных БД,
объединенных под общим управлением.
Задача состоит в том, чтобы спроектировать БД в принятом аспекте
этого понятия. На рис. 2.2 приведено схематичное представление такого
рода БД.
Предметная область
Т1
К.Т1
П1.Т1
…
ПN.Т1
TF
1
Т2
1 К.Т2
П1.Т2
…
ПK.Т2
1
ТL
K.TL
…
 П1.TL
…
ПM.TL
TZ
34
K1.TF
K2.TF
…
…


1
K.TZ
П1.TZ
…
ПN.TZ
Рис 2.2. Схематичное представление БД
На рисунке изображены структуры таблиц и все возможные связи
между ними.
Здесь префикс ”К” означает ключ (ключевое поле). В принципе ключ
может содержать несколько полей, но для компактности схемы такие
ситуации не показаны.
На схеме приведены возможные связи. '1’ означает связь одного
значения поля, ‘’ означает связь с несколькими значениями поля. Таким
образом отображены все возможные типы связей – “1 : 1”; “1 : ”; “ : 1”; “
: ” (Эта связь реализована посредством таблицы TF). Связь “ : 1” – это
связь “1 : ”, если рассматривать таблицы в другом порядке.
Таким образом, укрупненную модель БД можно представить в
следующем виде: T = {T1, T2,…,Тi,…,Тк}, где
Тi – i-я реляционная нормализованная таблица БД;
к – число таблиц в БД;
Ti = (Ki, Пi1, Пi2,…, Пij,…, Пin,), где
Ki – ключевое поле i- ой таблицы;
Пij – j –ое поле i-ой таблицы;
n – число неключевых полей;
Ti соответствует предметной области.
S = (S1, S2, …, Sj, …, Sm), где
Sj – связь между таблицами;
m - число связей.
Обозначим:
T(Sj) = (Tj1, Tj2) - пара таблиц инцидентных связи Sj;
N (Sj) = “1:1”  “1: ”  “  : 1”  “  :  ” – тип связи.
35
Таким
образом,
проектирование
БД
сводится
к
построению
описанной модели, а затем реализация БД на основе этой модели с
использованием соответствующих инструментальных средств.
В литературе, посвященной теории и практике проектирования БД
широко освящены задачи проектирования, этапы проектирования БД,
требования к БД и способы реализации этих требований [2]. Пользуясь
сложившейся теорией проектирования БД, можно в приемлемые сроки
разработать модель БД и реализовать БД, удовлетворяющую требованиям
непротиворечивости, минимальности, целостности.
Целью проектирования БД является построение и реализация ее
модели. Способ проектирования – использование сложившейся методики
построения
БД.
Результат
проектирования
–
эффективные,
взаимосвязанные структуры данных.
В
рассматриваемом
случае,
когда
БД
строится
на
основе
заполненных нереляционных таблиц, цель аналогична, способ неизвестен,
а результат проектирования очень желателен.
В связи с этим насущной проблемой является разработка методики
проектирования БД на основе использования заполненных нереляционных
таблиц.
Проектирование реляционных структур данных и связей между ними
на
основе
существующей
теории
имеет
ряд
основополагающих
достоинств.
1. Теория предполагает выполнение этапов проектирования: анализ
требований,
инфологическое
проектирование,
решая
задачи
проектирует
физическими.
физическое
названных
структуры
Причем
проектирование,
проектирование
этапов
данных
на
[1-3].
проектирования,
начиная
каждом
с
этапе
датологическое
Последовательно
разработчик
логических
решаются
и
БД
кончая
задачи,
ориентированные на достижение наилучших характеристик БД.
2. В соответствии с теорией разрабатываются структуры данных,
соответствующие требованиям к реляционным таблицам. Эти структуры
органично вписываются в концепцию реляционных БД.
36
3.
В
соответствии
нормализации
с
теорией
реляционных
формулируются
таблиц.
Выполняя
требования
эти
к
требования,
разработчик обеспечивает непротиворечивость и минимальность БД.
К числу недостатков существующей теории можно отнести то, что
принятие решений на каждом этапе и при использовании каждого
положения теории субъективно. И далеко не всегда принятое решение
оказывается
лучшим.
Например,
при
моделировании
локальных
представлений число моделей предметной области на логическом уровне
практически не ограничено и нет никаких гарантий, что будет разработана
наилучшая модель.
В случае проектирования БД на основе заполненных таблиц
достоинства существующей теории практически сводятся к нулю.
1. О выполнении этапов проектирования практически не может быть и
речи, так как таблицы уже заполнены, и проектировать новые логические
структуры не имеет смысла.
2. Структуры данных заполненных таблиц, как правило, не отвечают
требованиям к реляционным таблицам – приходится исходить из того, что
есть.
3. В подавляющем большинстве случаев таблицы, построенные и
заполненные вне баз данных, не нормализованы.
Правда недостаток существующей теории проектирования БД в этом
случае может обернуться даже достоинством. Состав таблиц определен,
их структура задана и нет необходимости выбора из неограниченного
множества логических структур данных.
Возникает
необходимость
оптимизации
существующих
структур
данных, которые используются для хранения информации табличного
вида. Такая необходимость обусловлена тем, что практически для всех
предметных
областей
накоплено
большое
количество
информации
табличного вида, а также тем, что имеется насущная потребность
представления этой информации в виде БД. В этой связи представляет
теоретический и практический интерес разработка средств, методов и
методик, обеспечивающих преобразования информации табличного вида в
БД.
37
2.2. Укрупненная модель информации табличного вида
В альтернативу укрупненной модели реляционной модели БД,
предельно
абстрагированной
от
большинства
ее
характеристик,
рассмотрим модель информации табличного вида.
На рис.2.3 приведена схема информации табличного вида.
Предметная область
NT1
NT2
NTQ
П1 NT1
П1 NT2
П2 NT1
П2 NT2
П2 NTQ
…
…
…
ПN NT1
ПK NT2
ПT NTQ
…
П1 NTQ
Рис.2.3. Схема информации табличного вида
В данном случае известны и соответственно отображены только
структуры таблиц. Следует подчеркнуть, что в отличие от случая,
представленного на рис. 2.2 таблицы всегда заполнены данными.
Как видно из рисунка, ключевые поля в таблицах отсутствуют, связей
между таблицами нет. Предполагается, что таблицы сгруппированы по
смыслу в рамках одной предметной области.
Таким образом, укрупненную модель информации табличного вида
можно представить следующим образом.
NТ = {NТ1, NТ2, …, NТi, …, NТq}, где
q – число таблиц в наборе;
NТi – i-я нереляционная, ненормализованная таблица набора.
NТi соответствует предметной области.
NТi = (Пi1 Пi2, …, Пij, …, Пin), где
Пij – j-е поле i – ой таблицы;
n – число полей таблицы.
38
Несмотря на сходство представленной укрупненной модели и
укрупненной модели БД, очевидны их существенные различия. В
частности:
- NТi, в отличие от Ti, нереляционные, ненормализованные таблицы;
- NТi, в отличие от Ti, не содержит ключевых полей.
NT(Sj) =  – множества связанных таблиц, в отличие от T(Sj)
пустые.
Здесь перечислены только основополагающие различия, которые
сформулированы с использованием укрупненных моделей. Детализация
моделей позволит выявить и другие важные отличия между БД и
табличным представлением информации.
Но даже этих отличий достаточно для того, чтобы сделать вывод о
том,
что
существуют
проблемы
преобразования
табличного
вида
информации к БД. Кроме того, анализ несовпадения моделей позволит
сформулировать важные проблемы преобразования.
Проведение
мероприятий
по
сведению
модели
информации
табличного вида к модели БД, с одной стороны, обеспечит построение
реляционной БД с уже внесенными данными в таблицы, а, с другой
стороны, позволит использовать в ходе разработки и эксплуатации БД
существующую теорию построения реляционных БД.
Из
сравнительного
анализа
моделей
следует
суть
основных
мероприятий, которые необходимо выполнить.
К их числу можно отнести разработку подхода преобразования
нереляционных заполненных таблиц к реляционным таблицам, разработку
подхода назначения ключевых полей в заполненных таблицах, разработку
подхода
нормализации
заполненных
таблиц,
разработку
подхода
формирования связей между заполненными таблицами.
Конкретизируем эти подходы и сформулируем задачи с целью
детального их рассмотрения и реализации соответствующих алгоритмов,
методов, методик и средств.
39
2.3. Задачи преобразования заполненных нереляционных
таблиц в реляционные таблицы
Преобразование нереляционных таблиц в реляционные таблицы
В литературе [2] сформулированы требования к реляционным
таблицам. В соответствии с этими требованиями, в частности, в
реляционных таблицах должны отсутствовать сложные атрибуты, типы
одноименных атрибутов должны совпадать, записи реляционных таблиц
не должны дублироваться.
В связи с этим необходима разработка метода избавления от
сложных атрибутов. Метод должен обеспечивать избавление от сложных
атрибутов в заголовках таблиц, а также обеспечить преобразование
сложных значений атрибутов в простые значения атрибутов.
В рамках
этого же метода необходимо выполнить следующие
мероприятия:
- разработку алгоритма исключения заголовков внутри таблиц;
- разработку алгоритма избавления от первого атрибута, если он
используется в качестве заголовка таблицы;
- разработку метода приведения значений атрибутов к одному типу;
- разработку алгоритма исключения дублирования записей.
Эти методы, организованные в нужной последовательности, составят
методику
преобразования
заполненных
нереляционных
таблиц
в
реляционные.
Нормализация заполненных таблиц
В
литературе,
данных [1],
частности,
посвященной
проектированию
реляционных
баз
сформулированы требования к нормальным формам. В
в
таблицах
не
должно
быть
сложных
атрибутов,
все
неключевые поля таблицы должны зависеть от ключевого поля, в таблицах
не должно быть транзитивных связей, в таблицах не должно быть
множественных зависимостей.
В связи с этим необходима разработка как минимум 4-х методов.
40
В частности, необходима разработка метода избавления от сложных
атрибутов в заполненных таблицах.
Необходима разработка метода исключения ситуаций в заполненных
таблицах, когда имеются неключевые атрибуты, независящие от ключевого
атрибута.
Необходима
разработка
метода
выявления
и
исключения
транзитивных зависимостей. Метод должен обеспечить преобразование
заполненных таблиц, в которых неключевые атрибуты зависят друг от
друга, в таблицы без подобных зависимостей.
Необходима
разработка
метода
выявления
и
исключения
множественных зависимостей. Метод должен обеспечить преобразование
заполненных таблиц с множественными зависимостями в таблицы, не
имеющие такие зависимости и свободные от дублирования данных.
Эти методы, организованные в требуемой последовательности и в
своем взаимодействии обеспечивающие нормализацию заполненных
таблиц, составят методику нормализации заполненных таблиц.
Назначение ключевых полей для заполненных таблиц
В литературе, относящейся к теории и практике реляционных БД,
формулируются требования к ключевым полям [2]. В частности, ключевые
поля должны идентифицировать каждую запись таблицы, должны быть
минимальны. Ключевые поля могут включать в себя несколько атрибутов
таблицы.
В связи с этим необходима разработка методики выявления или
назначения ключевых полей для заполненных реляционных таблиц.
Причем
выявленные
или
назначенные
ключевые
поля
должны
удовлетворять предъявляемым к ним требованиям.
Выявление и формирование связей между заполненными
реляционными таблицами
В литературе, посвященной реляционным БД, описаны возможные
типы связей между реляционными таблицами [2,14]. Рассмотрены 4-е типа
связей.
Эти
связи
обеспечивают
эффективный
доступ
к
данным,
хранящимся в таблицах БД.
41
В связи с этим необходима разработка методов построения связей
между заполненными таблицами. К моменту использования данного
метода к заполненным таблицам должны быть применены средства
преобразования заполненных нереляционных таблиц к реляционному
виду, а также средства назначения ключевых полей. Поэтому речь может
идти о разработке методов построения связей между заполненными
реляционными таблицами.
В связи с этим необходимы:
- разработка метода выявления и формирования связей один - к
одному в заполненных реляционных таблицах;
- разработка метода выявления и формирования связей один - ко
многим в реляционных заполненных таблицах;
- разработка метода выявления и формирования связей многие - ко
многим в заполненных реляционных таблицах.
В
своей
совокупности
данные
методы
составляют
методику
выявления и формирования связей в заполненных реляционных таблицах.
С учетом вышесказанного построена схема иерархии методов
проектирования реляционных баз данных на основе использования
существующей информации табличного вида. Она представлена на рис.
2.4.
Следует отметить, что для обеспечения этого подхода необходимы
разработка моделей реляционных и нереляционных таблиц, выполнение
оценки
предлагаемых
алгоритмов,
реализация
алгоритмов
в
виде
соответствующих программ, экспериментальная оценка и исследование
разработанных средств.
Методы проектирования реляционных БД на основе информации табличного вида
Методика преобразования нереляционных таблиц в реляционные
Алгоритм исключения подзаголовков
Алгоритм исключения заголовков внутри таблиц
Алгоритм избавления от 1-го атрибута, если его значения заголовки
42
Методика нормализации заполненных таблиц
Рис. 2.4. Схема иерархии методов проектирования реляционных баз данных на
основе использования информации табличного вида
43
Важно отметить, что разрабатываемые методы и методики –
человеко-машинные. Это обусловлено тем, что в большинстве случаев в
процессе выполнения манипуляций по проектированию БД необходимо
принятие решений разработчиком относительно выбора дальнейшей
последовательности
существенную
действий.
положительную
Человеко-машинный
сторону
–
при
подход
имеет
проектировании
БД
используется опыт и творческий потенциал разработчика.
Вопросам
человеко-машинного
(автоматизированного)
проектирования БД посвящено ряд работ, в частности [14]. Однако в них
речь идет о проектировании БД с нуля, когда таблиц еще нет, не говоря о
том, что они не заполнены. В работах предлагаются методы формального
описания предметной области и автоматического построения на основе
этих описаний структур таблиц БД и связей между ними.
К сожалению, данный подход в рассматриваемом случае практически
неприемлем – описание предметной области на логическом уровне,
конечно,
возможно,
но
автоматизированное
построение
таблиц,
полученное на основе этого описания, скорее всего не приведет к
датологической
модели,
соответствующей
заполняемым
таблицам.
Правда, не исключено, что удастся разработать и реализовать методы и
методики автоматизированного заполнения полученной датологической
модели данными из таблиц с информацией. Это является предметом
отдельных исследований и выходит за рамки данной работы.
Однако
следует
автоматизированного
отметить,
что
при
проектирования
закономерности,
которые
закономерности,
конечно,
изложены
следует
разработке
методов
используются
в
ряде
учитывать
работ
при
общие
[1-2].
Эти
разработке
специфических автоматизированных методов решения проектных задач в
ходе разработки реляционной БД.
Упражнения и вопросы для самоконтроля
1. Сформулируйте основные характеристики модели реляционной БД.
44
2. Сформулируйте основные характеристики модели информации
табличного вида.
3. В чем сходство между моделью реляционной БД и моделью
информации табличного вида?
4. В чем различие между моделью реляционной БД и моделью
информации табличного вида?
5. Сформулируйте задачи преобразования заполненных
нереляционных таблиц в реляционные таблицы.
6. Постройте схему иерархии методов проектирования реляционных
баз данных на основе использования информации табличного вида
3. ПРЕОБРАЗОВАНИЕ НЕРЕЛЯЦИОННЫХ
ТАБЛИЦ В РЕЛЯЦИОННЫЕ ТАБЛИЦЫ
45
3.1. Приведение значений атрибутов заполненных таблиц к
одному типу
Ключевым
требованием
к
реляционным
таблицам
являются
одинаковые типы значений всех атрибутов.
К числу основных типов полей в реляционных таблицах относятся:
числовой, текстовый, дата, время, логический, гиперссылки, OLE, MEMO.
При вводе нового значения в каком-либо поле таблицы БД тип значения
проверяется
автоматически.
Если
тип
вводимого
значения
не
соответствует объявленному типу, то это значение не заносится в поле
таблицы.
При
заполнении
нереляционных
таблиц
такой
проверки
не
выполняется. В связи с этим в нереляционных таблицах в одном и том же
столбце могут храниться данные различных типов. Это недопустимо в БД.
Поэтому при преобразовании нереляционных таблиц в реляционный вид
необходимо обеспечить единый тип значений для всех атрибутов.
В качестве примера таблицы с различными типами значений
атрибутов в одноименных столбцах рассмотрим таблицу, представленную
на рис. 3.1.
Рис. 3.1. Таблица с различными типами значений атрибутов в
одноименных столбцах
В этой таблице в столбце ”B”, как мы видим, должны располагаться
значения логического типа, в столбце “C” - значения числового типа, а в
столбце “D” – значения типа ”Дата”.
46
Однако после импорта этой электронной таблицы с использованием
стандартных
средств
Microsoft
Access
сформируется
таблица
БД,
представленная на рис 3.2.
Рис 3.2. Результат импорта электронной таблицы с использованием
стандартных средств Microsoft Access.
В этой таблице тип всех столбцов текстовый, так как имеет место
смешение типов. Более того, даты превратились в числа.
При этом в
процессе выполнения процедуры импорта не было никакой возможности
указать нужный тип.
При преобразовании таблиц (текстовых, электронных) стандартными
средствами других СУБД
тип столбцов иногда назначается исходя из
анализа нескольких первых записей таблицы. Но это, в принципе, мало
что меняет.
Конечно, для таблицы с незначительным числом записей и атрибутов
несложно исправить значения и свойства атрибутов. Однако для больших
объемов данных это неприемлемо. В связи с этим предлагается
автоматизированный метод назначения типов атрибутов заполненных
таблиц.
Суть метода состоит в том, что для каждого столбца импортируемой
таблицы выполняется автоматический анализ всех его значений. По
результатам
анализа
назначается
тип
столбца,
который
имеют
большинство значений этого столбца. Разработчику БД предлагается
принять назначенный тип. Если этот тип его не устраивает, предлагается
очередной по приоритету тип. И так до тех пор, пока тип столбца не будет
принят
разработчиком
БД.
Затем
осуществляется
попытка
47
автоматического преобразования всех значений текущего столбца к
назначенному типу. В результате преобразований формируются таблица
преобразованных значений и таблица значений, которые не удалось
преобразовать. Разработчик анализирует таблицу непреобразованных
значений и на основе использования автоматизированных средств
осуществляет преобразование данных к назначенному им типу.
В соответствии с известными СУБД выделим базовые типы, к которым
алгоритм должен сводить атрибуты заполненных таблиц. Это следующие
типы: числовой, строковый, дата, логический.
Суть
алгоритма
состоит
в
следующем.
Для
каждого
столбца
выполняется проверка всех его значений на принадлежность к каждому из
названных типов. Назначается тот тип, который имеют большинство
значений столбца. После назначения типа столбцу проверяются все его
значения, которые не соответствуют назначенному типу. Если значение
столбца в соответствии со своим контекстом может быть отнесено к
назначенному типу, то это значение преобразуется к формату принятого
для данного типа, запоминается позиция преобразованного значения и его
прежнее значение. Прежнее значение и его номер записываются в
соответствующую таблицу. Если значение столбца в соответствии со
своим контекстом не может быть отнесено к назначенному типу, его номер
заносится в таблицу непреобразованных значений атрибута.
Рассмотрим в качестве примера значения столбца.
А = (1, 0, да, нет, FALSE, TRUE, истина, ложно, ‘’ , NULL, верно,
неверно, 0, 0, 1, FALSE, верно, неверно).
Если формально рассматривать значения этого столбца, то его тип
будет назначен как текстовый, т.к. большинство его значений - текст.
Однако
просто
визуального
анализа
достаточно
для
того,
чтобы
определить тип столбца как логический.
Но для нескольких тысяч и даже сотен значений визуальный анализ
данных чрезвычайно затруднителен.
При автоматизированном анализе в процессе проверки типа столбца
существенно поможет таблица часто встречающихся значений для данного
типа. Например, для типа “логический” рассмотренный столбец после
преобразования вида его значений примет вид:
48
А = (да, нет, да, нет, нет, да, да, нет, '' , NULL, верно, неверно, нет, нет,
да, нет, верно, неверно).
Таблица замененных значений примет вид.
A’’ = (1, 0, , , FALSE, TRUE, истина, ложь, , , 0, 0, 1, FALSE, , 0, 0, 1,
FALSE, ,)
Таблица не замененных значений примет вид.
A’’ = (, , , , , , , , '' , NULL, верно, неверно, , , верно, неверно).
Здесь символом ”,” обозначены позиции, отмечающие значения, не
входящие в соответствующие таблицы.
Объединив эти три столбца в одну таблицу, получим табл. 3.1. Здесь в
столбце с заголовком ”№” расположены номера записей. В столбце ”А”
приведены исходные значения анализируемого столбца. В столбце ”F’ ” метки значений, которые преобразованы к выбранному типу. В столбце ”А'
” приведены
значения анализируемого столбца, полученные после
преобразования исходного столбца. В столбце ”F’’ ” -
метки значений,
которые не удалось преобразовать к выбранному типу. В столбце ”А'’ ”
приведены значения, которые не удалось преобразовать к выбранному
типу.
Т а б л и ц а 3.1
№
А
F'
A’
1
1

да
F’’
A’’
49
2
0

нет
3
FALSE

нет
4
TRUE

да
5
ИСТИНА

да
6
ЛОЖЬ

нет
7
''
''

''
8
NULL
NULL

NULL
9
ВЕРНО
ВЕРНО

ВЕРНО
10
НЕВЕРНО
НЕВЕРНО

НЕВЕРНО
11
0

нет
12
0

нет
13
1

да
14
FALSE

нет
15
ВЕРНО
ВЕРНО

ВЕРНО
16
НЕВЕРНО
НЕВЕРНО

НЕВЕРНО
Разработчику
необходимо
согласиться
c
изменениями
отменить. Кроме того, он должен иметь возможность
или
их
выбрать из
предлагаемого списка значений для замены нужные значения там, где
замен не произошло.
Возможность выполнения этих действий разработчиком следует
обеспечить в алгоритме и в его реализации. Очевидно, что трудоемкость
манипуляций разработчика можно существенно уменьшить, если до
разметки записей он укажет обязательные замены. Тогда результирующая
таблица
существенно
сократится.
Конечно,
такую
возможность
необходимо предусмотреть в алгоритме и в его реализации. Например, в
качестве обязательных замен разработчик может пометить замены,
приведенные в табл. 3.2.
Т а б л и ц а 3.2
0
нет

50
1
да

FALSE
нет

TRUE
да

ИСТИНА
да
ЛОЖЬ
нет
Тогда табл. 3.1 примет вид табл. 3.3.
Т а б л и ц а 3.3
№
А
F’
A’
5
ИСТИНА

да
6
ЛОЖЬ

нет
7
''
8
F’’
A’’
''

''
NULL
NULL

NULL
9
ВЕРНО
ВЕРНО

ВЕРНО
10
НЕВЕРНО
НЕВЕРНО

НЕВЕРНО
15
ВЕРНО
ВЕРНО

ВЕРНО
16
НЕВЕРНО
НЕВЕРНО

НЕВЕРНО
Для упрощения действий разработчика необходимо в алгоритме и его
реализации обеспечить возможность принятия всех аналогичных замен
при подтверждении одной,
а также возможность замещения всех
аналогичных вхождений при указании разработчиком шаблона для
замещения.
Например, если разработчик в строке с номером 9 выберет замену
”ВЕРНО” на “да”, то в строке с номером 15 это должно быть выполнено
автоматически.
Изложенное выше в основном нужно для разработки и пояснения
алгоритма, который разрабатывается на основе принципа “от частного к
общему”. Реализация средств разработчика БД, конечно, должна быть
более эргономична.
51
По аналогии с приведенным примером приводятся к одному типу
значения столбца в случае, если превалирующий тип отличен от
“логического'” типа.
Следует
отметить,
что
рассмотрен
простейший
случай
–
предполагаемый тип очевиден и для значений, которые остались не
замененными легко подобрать замену.
Как показывает анализ реальных таблиц, для поиска превалирующего
типа приходится выполнить проверку на соответствие нескольким типам.
Кроме того, в реальных таблицах зачастую не удается подобрать значение
для замещения из превалирующего типа, т.к. исходные значения ни на что
не похожи. Чаще всего это ошибки заполнения таблиц. В этом случае они
выявляются и исключаются. В крайнем случае, неопознанные значения
заменяются пустыми значениями.
Опираясь
на
рассмотренный
пример,
изложим
предлагаемый
автоматизированный метод приведения значений атрибутов к одному типу
в виде человеко – машинного алгоритма.
Он выглядит следующим образом.
FOR r =1 то k – 1
CN = 0
CB = 0
CS = 0
CD = 0
FOR f = 1 то m
SELECT CASE T (afr)
CASE ”NUM”
CN = CN + 1
CASE “LOG”
CB = CB + 1
CASE “STR”
CS = CS + 1
CASE “DAT”
CD = CD + 1
END SELECT
NEXT f
52
TYPE = FMAX (CN, CB, CS, CD)
PRINT (r, TYPE)
REM Вывод таблицы обязательных замен
REM Заполнение таблицы обязательных замен
PRINT (Ar, Ar', Ar’’)
REM Подтверждение (отмена) замен.
REM Присвоение значений.
NEXT r
Здесь k - степень отношения (перебираются все столбцы, кроме
ключевого столбца).
m – мощность отношения.
CN, CB, CS; CD – счетчики совпадений значений столбца с
соответствующим типом.
Функция FMAX позволяет определить наиболее часто встречающийся
тип в столбце.
Оператор PRINT (r, TYPE) позволяет вывести номер анализируемого
столбца и предлагаемый тип.
Оператор PRINT (Ar, Ar', Ar’’) позволяет вывести исходный столбец,
измененный столбец и столбец значений, для которых соответствующей
замены не нашлось.
Полужирным шрифтом выделены действия разработчика, которые он
должен выполнить в ответ на результаты работы автоматических средств.
Следует отметить, что в процессе реализации алгоритма необходимо
предусмотреть
разработку таблицы предлагаемых замен для всех
основных типов. Их формирование неочевидно. Например, для числовых
значений допустимо множество представлений. То же самое можно
сказать о типе ”Дата, время”. В связи с многообразием представления
значений одного типа программные средства замены нетривиальны.
Рассмотрим, как эта проблема решается в СУБД Microsoft Access.
В примере задана простейшая структура двух таблиц - для Таблицы1
и Таблицы2. В каждой таблице по одному полю, в Таблицы1 тип поля
”Логический”, в Таблицы2 тип поля ”Текстовый”. В обеих таблицах имена
53
полей одинаковые - ”Логический”. Таблица1 не заполнена. Таблица2
заполнена данными, представленными на рис. 3.3.
Рис. 3.3. Таблица2
Выполним попытку добавить данные из Таблицы2 в Таблицу1. Для
этого сформирован следующий запрос на добавление.
INSERT INTO Таблица1 ( Логический )
SELECT Таблица2.Логический
FROM Таблица2;
Здесь конструкция ”INSERT INTO Таблица1 (Логический)” указывает
на то, что выполняется добавление в поле “Логический” таблицы
“Таблица1”. Конструкция “SELECT Таблица2.Логический FROM Таблица2;”
указывает на то, что данные для добавления выбираются из поля
“Логический” таблицы ”Таблица2”.
В результате выполнения этого запроса будет выведено сообщение,
приведенное на рис. 3.4.
54
Рис. 3.4. Сообщение, сформированное после выполнения запроса на
добавление
Текст сообщения говорит сам за себя. В результате выполнения
запроса на добавление для 8-и из 17-и возникла ошибка преобразования
типа.
После выполнения запроса Таблица1 примет следующий вид рис. 3.5.
Рис. 3.5. Таблица1 после добавления значений поля ”Логический”
Сравнивая рис. 3.3 и рис. 3.5
легко сделать вывод о том, что
пользователь, вероятно, ожидал других результатов добавления.
Конечно, трудно ожидать от разработчиков Microsoft Access, что они
смогут предусмотреть все формы записей, соответствующих какому-либо
типу, которые придут в голову пользователю.
55
Значительно лучше обстоит дело в СУБД
Microsoft Access с
распознаванием текстовых значений, в которых подразумевается дата.
Рассмотрим еще один пример.
В примере задана простейшая структура двух таблиц - для Таблицы3
и Таблицы4. В каждой из них по одному полю. В Таблице4 тип поля ”Дата”, в Таблицы3 тип поля - ”Текстовый”. В обеих таблицах имена полей
одинаковые - ”Дата”. Таблица4 не заполнена. Таблица3 заполнена
данными, представленными на рис. 3.6.
Рис. 3.6. Таблица3 с данными
Сформируем запрос на добавление.
INSERT INTO Таблица4 ( Дата )
SELECT Таблица3.Дата
FROM Таблица3;
В результате выполнения этого запроса Таблица4 примет вид,
представленный на рис. 3.7.
56
Рис. 3.7. Результат выполнения запроса на добавление
Сравнивая рис. 3.6 и рис. 3.7 нетрудно сделать вывод о том, что,
несмотря на различные формы представления даты, большая часть
значений успешно преобразовалась. Там, где год не указан, назначается
текущий год и это логично. Не преобразовались только последние два
значения, которые явно на даты не похожи. Но, к сожалению, в реальных
таблицах такого рода ”даты” имеют место.
3.2. Исключение дублирования записей
Важным требованием к реляционным таблицам является отсутствие
дублирования записей. При наличии дублирования результаты анализа
данных могут быть противоречивы, не соответствовать действительности.
В электронных таблицах, текстовых файлах данные могут быть
выделены цветом, шрифтом, заполнением. Таким образом, придается
различный смысл разным группам данных, даже если эти данные
совпадают.
В базах данных это невозможно и поэтому дублирование
записей недопустимо.
Рассмотрим
фрагмент
реальной
электронной
таблицы
с
повторяющимися записями, представленной на рис. 3.8.
57
Рис. 3.3. фрагмент реальной электронной таблицы с
повторяющимися записями
Здесь повторяются записи с номерами строк 7 и 12, а также записи с
номерами строк 5 и 9. Цветом выделены регионы, поэтому пользователям
электронных таблиц
ясно, чем отличаются повторяющиеся записи.
Интересно также отметить, что в последнем столбце дата введена явно
некорректно,
что
еще
раз
подтверждает
актуальность
задачи,
рассмотренной в предыдущем параграфе.
При
использовании
таблиц
такого
рода
в
БД
необходимо
сформировать таблицу регионов, таблицу записей, отражающих основные
данные, удалить дублирование в основной таблице и организовать связи
между таблицами.
Перечисленные
действия
связаны
с вопросами
нормализации и организации связи между таблицами. Эти вопросы будут
рассмотрены позже в соответствующих главах.
Выше рассмотрено дублирование записей, которое не обусловлено
смысловыми ошибками, но дублирование может быть и другого рода, когда
пользователь электронной таблицы ввел неоднократно одни и те же
данные. Такая ситуация вполне возможна при наличии нескольких сотен
записей в таблице.
58
В любом случае перед использованием таблиц в БД необходимо
устранить в них дублирование записей.
После импорта исходной таблицы в БД таблица с повторяющимися
записями в формате БД примет вид, приведенный на рис. 3.9.
Рис. 3.9. Таблица с повторяющимися записями в формате БД
Чтобы выявить повторяющиеся записи можно построить запрос на
SQL, который имеет следующий вид.
SELECT
First(Предложения.Поле1)
AS
[Поле1
поле],
First(Предложения.Поле2) AS [Поле2 поле], First(Предложения.Поле3) AS
[Поле3
поле],
First(Предложения.Поле4)
AS
[Поле4
поле],
First(Предложения.Поле5) AS [Поле5 поле], First(Предложения.Поле6) AS
[Поле6
поле],
First(Предложения.Поле7)
AS
[Поле7
поле],
First(Предложения.Поле8) AS [Поле8 поле], First(Предложения.Поле9) AS
[Поле9
поле],
First(Предложения.Поле10)
AS
[Поле10
поле],
Count(Предложения.Поле1) AS Повторы
FROM Предложения
GROUP
BY
Предложения.Поле1,
Предложения.Поле2,
Предложения.Поле3,
Предложения.Поле4,
Предложения.Поле5,
Предложения.Поле6,
Предложения.Поле7,
Предложения.Поле8,
Предложения.Поле9, Предложения.Поле10
HAVING
(((Count(Предложения.Поле1))>1)
AND
((Count(Предложения.Поле10))>1));
59
Несмотря на то, что запрос занимает немало строк, он несложен по
сути – из таблицы “Предложения” выбираются первые значения всех полей
( First(Предложения.Поле1) ) и этим значениям присваивается имя ( AS
[Поле1 поле] ) . Выводимые данные группируются по этим значения (
конструкция GROUP BY). С помощью конструкции HAVING
только
те
строки,
в
которых
имеются
выводятся
повторения
(((Count(Предложения.Поле1))>1) AND ((Count(Предложения.Поле10))>1))
Результат выполнения запроса на выборку повторяющихся записей
представлен на рис. 3.10. В отдельном столбце ”Повторы” выводятся
количества повторений соответствующих записей в таблице.
Рис. 3.10. Результат выполнения запроса на выборку повторяющихся
записей
Следует отметить, что в некоторых СУБД, например в Microsoft
Access, запрос такого рода строится просто - с помощью специального
мастера ”Повторяющиеся записи”.
Как видно из рисунка 3.10, таких записей в таблице оказалось две.
При небольшом количестве повторяющихся записей, как в данном случае,
проще всего их удалить вручную. Для значительного числа повторяющихся
записей оправданно использование специально ориентированных средств.
Предлагается алгоритм исключения повторяющихся записей на
основе использования списка повторяющихся записей. Он выглядит
следующим образом.
FOR i = 1 TO k
S = SP i
C = C(SP i) - 1
FOR j = 1 TO n
60
IF (SNj = S) AND (C > 0) THEN
DELETE (SNj)
C=C-1
END IF
NEXT j
NEXT i
Здесь k – число повторяющихся записей;
n – число записей в исходной таблице;
SPi – i-я, текущая запись в таблице повторяющихся записей;
C(SP i) – количество повторений i-й записи;
SNj - j-я, текущая строка в исходной таблице;
DELETE (SNj) – оператор удаления j-ой записи в исходной таблице;
В соответствии с алгоритмом удаляются не все повторяющиеся
записи, а только лишние, поэтому и задействован оператор C = C(SP i) 1.
Как видно из алгоритма, большинство его команд соответствуют
командам языка программирования Basic. Вероятно, что алгоритм будет
реализовываться в рамках СУБД Microsoft Access, а в нем в качестве
алгоритмического языка программирования используется Visual Basic.
Следует отметить, что, несмотря на кажущуюся простоту алгоритма,
его реализация нетривиальна. В частности еще предстоит решить, каким
программным путем осуществлять последовательную выборку записей
обеих таблиц, их сравнение и удаление.
Вычислительную сложность алгоритма можно существенно понизить и
преобразовать его к следующему виду.
FOR i = 1 TO k
S = SP i
C = C(SP i) - 1
FOR j = 1 TO n
IF (SNj = S) AND (C > 0) THEN
DELETE (SNj)
61
C=C-1
END IF
IF C = 0 THEN
EXIT FOR
END IF
NEXT j
NEXT i
Добавление конструкции
“IF C = 0 THEN EXIT FOR” позволяет
после исключения повторяющихся строк не сканировать вхолостую
оставшиеся строки исходной таблицы, а завершить внутренний цикл.
Если допускается переименование таблицы с повторяющимися
записями, то практически во всех СУБД можно построить запрос, который
формирует на основе исходной таблицы новую таблицу, но
без
повторяющихся записей. Запрос для таблицы, представленной на рис. 3.9,
имеет вид.
SELECT DISTINCT Таблица1.* INTO Таблица2
FROM Таблица1;
Здесь все поля Таблицы1 (Таблица1.*) добавляются к Таблица2 (INTO
Таблица2) из Таблицы1 (FROM Таблица1). При этом посредством
конструкции
”DISTINCT” в
Таблицу2 добавляются только уникальные
значения.
После выполнения запроса Таблица2 примет вид рис 3.11.
Рис.3.6. Таблица без повторяющихся записей
62
Если не допускается переименование таблицы с повторяющимися
записями, то рассмотренный запрос на создание новой таблицы тоже
можно использовать, но с обязательным выполнением дополнительных
мероприятий. Эти мероприятия заключаются в удалении исходной
таблицы и переименовании полученной таблицы.
Подобные средства, конечно, предпочтительно использовать, если
данные представлены в формате какой-либо СУБД,
Упражнения и вопросы для самоконтроля
1. Приведите пример таблиц, содержащих данные различного типа в
одном столбце.
2. Опишите алгоритм приведения данных, содержащихся в столбце, к
одному типу.
3. Как реализовать данный алгоритм на основе визуального анализа
таблиц и существующих средств СУБД?
4. Приведите примеры реальных таблиц, содержащих дублирование
записей.
5. Опишите алгоритм исключения дублирования записей.
6. Как реализовать данный алгоритм на основе визуального анализа
таблиц и существующих средств СУБД?
63
4. НОРМАЛИЗАЦИЯ ЗАПОЛНЕННЫХ
РЕЛЯЦИОННЫХ ТАБЛИЦ.
4.1. Проблемы нормализации
В табл. 4.1 представлен
общий вид заполненной реляционной
таблицы (общий вид отношения).
Т а б л и ц а 4.1
A1
A2
…
Ai
…
Aj
…
Ak
a11
a12
…
a1i
…
a1j
…
a1k
a21
a22
…
a2i
…
a2j
…
a2k
…
…
…
…
…
…
…
…
an1
an2
…
ani
…
ani
…
ank
…
…
…
…
…
…
…
…
am1
am2
…
ami
…
amj
…
amk
Здесь A = {A1, A2, …, Ai …, Aj, …, Ak} – множество атрибутов
(заголовков) таблицы (отношения).
a = ((a11, a12 , …, a1i, …, a1j, …, a1k),
(a21, a22 , …, a2i, …, a2j, …, a2k), …,
(an1, an2 , …, ani, …, anj, …, ank), …,
(am1, am2 , …, ami, …, amj, …, amk)) – множество кортежей значений
атрибутов.
В данном представлении множество ”a” представляет собой
множество записей таблицы.
Если это же множество представить следующим образом:
64
a = ((a11, a21 , …, an1, …, am1),
(a12, a22 , …, an2, …, am2), …,
(a1i, a2i , …, ani, …, ami), …,
(a1j, a2j , …, anj, …, amj), …,
(a1k, a2k, …, ank, …, amk)),
то в таком представлении множество “а” является множеством
значений атрибутов А, где
k – степень отношения;
m – мощность отношения.
В качестве ограничений в данной таблице принимаются следующие
требования:
1.  Ai (Ai  A)  (Ai ‘  Ai)
i = 1, k; A = {A1, A2, …, Ai, …, Aj, …, Ak}
Другими словами все атрибуты отношения должны быть неделимы
(атомарны).
2. (a11  a21  … an1  … am1)  …
(a1i  a2i  … ani  … ami)  …
(a1k  a2k  … ank  … amk)),
Т.е., все
значения хотя бы одного из столбцов таблицы должны
отличаться друг от
друга.
Это требование обеспечивает
наличие
первичного ключа. Вопросы, связанные с назначением первичного ключа
рассматриваются в главе 5.
Так как ключ может содержать в себе более одного атрибута, то к
предыдущему выражению со связкой ”ИЛИ” можно приписать следующее
выражение (для двух атрибутов):
concat (a1i, a1j)  concat (a2i, a2j)  …  concat (ani, anj)  …  concat (ami,
amj)
i = 1, k; j = 1, k; i  j .
Здесь concat (a1i, a1j) - конкатанация (сцепление) значений атрибутов
Ai и Aj.
Первичный ключ может включать в себя и три атрибута. Если это так,
то к предыдущему выражению со связкой ”ИЛИ” добавится выражение,
включающее конкатенации из 3-х значений атрибутов. На практике
65
первичный ключ исключительно редко включает в себя более 3-х
атрибутов – чаще всего он состоит из одного атрибута, реже из 2-х и очень
редко из 3-х.
3.  Ai (Ai  A) (T(a1i) = T(a2i) = … = T(ani) = … = T(ali)), n = 1, m
Здесь T(a2i) – тип значения атрибута
a2i. Другими словами, типы
значений атрибутов должны совпадать. Вопросы приведения значений
одноименных атрибутов к одному типу рассмотрены в 3.1.
4. concat (a11, a12, …, a1i, …, a1j, …, a1k)  …
 concat (an1, an2, …, ani, …, anj, …, ank )  …
 concat (am1, am2, …, ami, …, amj, …, amk)
Другими словами
- все записи таблицы должны быть уникальны.
Нетрудно доказать, что так оно и будет, если удовлетворяется условие
(п.2). Действительно, в соответствии с ограничением (п.2) в отношении
должен присутствовать хотя бы один столбец, для которого выполняется
условие:
a1i  …  ani  …  ami
Таким образом, во всех конкатенациях п.4 имеются значения
атрибутов, которые не равны друг другу. А из этого следует, что не одно из
значений конкатенации не равно другому значению конкатенации, что и
требовалось доказать.
Однако не для всех таблиц задействуются ключевые поля. В связи с
этим, необходимы средства для исключения дублирования в таблицах без
ключевых атрибутов.
Часть вопросов реализации изложенных требований к заполненным
таблицам изложены в работах [6], часть вопросов рассмотрены в
предыдущей главе.
Таким образом, можно принять, что, используя предложенные методы
и средства, можно привести заполненную нереляционную таблицу к виду
табл. 4.1 и при этом удовлетворить перечисленным требованиям.
В связи с этим для дальнейших выкладок будет использоваться
таблица вида табл. 4.1, удовлетворяющая требованиям к реляционным
таблицам.
66
Несмотря на то, что таблица может быть реляционной и допустимой
для использования в БД, ее структура не всегда оптимальна. Под
оптимальностью в
отсутствие
данном случае понимается непротиворечивость,
избыточности,
отсутствие сложных зависимостей
внутри
таблицы. С целью улучшения названных свойств таблицы разработаны
требования к структурам реляционных таблиц и механизмы их реализации,
так называемые нормальные формы. Однако они хорошо работают на
этапе проектирования таблиц. Для заполненных же реляционных таблиц
существующие механизмы напрямую неприменимы. В связи с этим
оправданно использование существующей теории (насколько это можно)
для разработки средств нормализации заполненных реляционных таблиц.
Как правило, в литературе рассматриваются 4-е нормальные формы
[1]. В несколько упрощенном виде они звучат следующим образом.
1. Атрибуты должны быть атомарны.
2. Все неключевые атрибуты зависят от ключевого атрибута.
3. Неключевые атрибуты не должны зависеть друг от друга.
4. Между атрибутами не должно быть множественных зависимостей.
Следует еще раз обратить внимание на то, что в рассматриваемом
случае речь идет не о проектировании отношений, когда разработчик БД
может создавать отношения, основываясь на сформулированные условия
нормализации. Речь идет о заполненных реляционных таблицах, для
которых в общем случае эти условия не выполнены.
В связи с этим возникает задача разработки модели информации
табличного вида, модели реляционной таблицы, методов приведения
заполненных реляционных таблиц к нормальной форме. Об этом и пойдет
речь дальше.
4.2. Модели информации табличного вида и реляционных
таблиц.
4.2.1. Модель информации табличного вида
67
Данные табличного вида (DT) представляются множеством DT = {Z,
D}, где Z – множество заголовков, D - множество данных.
Z = { Z 1 ,…, Zi ,…, Z n },
i = 1,n; n>=1,
где n - степень множества
заголовков.
Допустима ситуация, когда Zi = Zm . i = 1,n ; m = 1,n; i ≠ m , где n –
степень
множества
заголовков,
т.е.
возможно
полное
совпадение
заголовков.
В данных табличного вида возможны подзаголовки 1-го уровня, что
формально выглядит следующим образом.
Z i = {P Z i1 ,…,P Z ij ,…,P Z ik }, j = 1,k; k >=2, где k - степень множества
подзаголовков i-го заголовка (1).
Z p = {P Z p1 ,…,P Z pt ,…,P Z pm }, t = 1,m; m >=2, где m - степень множества
подзаголовков p-го заголовка (2).
Допустима ситуация, когда P Z ij = P Z pt (3).
В данных табличного вида возможны подзаголовки 2-го уровня, что
формально выглядит следующим образом.
P Z ij = {PP Z ij1 ,…,PP Z ijm ,…,PP Z ijf }, m = 1,f; f >= 2, где f - степень
множества подзаголовков 2-го уровня ij-го подзаголовка 1-го уровня (4).
P Z pt = {PP Z pt1 ,…,PP Z ptr ,…,PP Z ptq }, r = 1,q; q >= 2, где q - степень
множества подзаголовков 2-го уровня pt-го подзаголовка 1-го уровня (5).
Допустима ситуация, когда PP Z ijm = PP Z ptm (6).
Теоретически в данных табличного вида может быть больше уровней
подзаголовков. Однако, как показывают экспертные оценки реальных
табличных
данных,
обычно
имеет
место
не
более
2-х
уровней
подзаголовков. В связи с этим модель заголовков ограничим 3-мя
уровнями.
На рис. 4.2.1 приведен реальный пример с подзаголовками.
68
Рис. 4.2.1. Пример с подзаголовками
Здесь
заголовок
”Тип
оборудования”
включает
в
себя
4-е
подзаголовка, заголовок “Цена” включает в себя 2-а подзаголовка.
D = {SD, Z}, где SD – множество строк данных (7).
Такого рода представление D допускает наличие нескольких заголовков и
подзаголовков 1-го и 2-го уровней, расположенных в области данных. В
том
числе
допускается
наличие
заголовков
и
подзаголовков,
расположенных до, после и между строк данных. На рис. 4.2.2 приведен
реальный пример с заголовками внутри области данных. Таковыми
являются строки 10 и 13.
69
Рис. 4.2.2. Пример с заголовками внутри области данных
SD = {SD1,…,SDi…,SDn}, i = 1,n; n >> 1, где n - мощность множества
строк данных.
SDi = {EDi1...,EDij,…,EDik}, j = 1,k; k >= 1, где k - степень множества
элементов данных i-ой строки данных; EDij – элемент данных.
Для информации табличного вида должно выполняться следующее
правило:
(  ED) ( SD  ED) ((  z (Z  z) (z  ED)) V (  (PZ)) (z  PZ) (PZ  ED)
V (  (PPZ)) (PZ  PPZ) (PPZ  ED)
Т.е.
каждому
элементу
данных
соответствует
заголовок
или
подзаголовок 1-го или 2-го уровней.
(  ED) (SD  ED ) ((  TED (ED  TED)), где TED = string V integer V
datetime
Т.е. каждому элементу данных соответствует определенный тип
данных.
В общем случае:
70
TED11≠,…,≠TEDi1≠,…,≠TEDn1
……………………………
TED1j≠,…,≠TEDij≠,…,≠TEDnj
……………………………
TED1k≠,…,≠TEDik≠,…,≠TEDnk, i = 1,n; n>>1; j = 1,k; k >= 1,
где n - мощность множества строк данных, k - степень множества
элементов i-ой строки данных; Другими словами, значения типов данных
одного столбца могут не совпадать.
Допустима ситуация, когда
SDi = SDj , i = 1,n ; j=1,n; i≠j , где n –
мощность множества данных, т.е. возможно полное совпадение строк
данных.
4.2.2. Модель реляционной таблицы
Реляционная таблица (RT) представляется множеством RT = {Z, D},
где Z – множество заголовков, D - множество данных.
Z = { Z 1 ,…, Zi ,…, Z n },
i = 1,n; n>=1,
где n - степень множества
заголовков.
Должно быть обеспечено условие Zi ≠ Zm , i = 1,n ; m = 1,n; i ≠ m (8),
где n – степень множества заголовков, т.е. недопустимо совпадение
заголовков.
D = {SD} (9), где SD – множество строк данных.
SD = {SD1,…,SDi…,SDn}, i = 1,n; n >> 1, где n - мощность множества
строк данных.
SDi = {EDi1...,EDij,…,EDik}, j = 1,k; k >= 1, где k - степень множества i-ой
строки данных; EDij – элемент данных.
Недопустима ситуация, когда
внутри таблицы данных
могут
встретиться заголовки, т.е. должно выполнятся условие:
SDi ≠ Z J , i = 1,n; n >> 1; j = 1,k; k >= 1 (10), где
n - мощность множества строк данных;
k - степень множества заголовков.
Для реляционных таблиц выполняется правило:
(  ED)(SD  ED) ((  z(Z  z) (z  ED)
71
Т.е. каждому элементу данных соответствует только один заголовок.
(  ED) (ED  SD ) ((  TED (ED  TED)),
где TED = string V integer V datetime V real V logical
Т.е. каждому элементу данных соответствует определенный тип
данных.
В реляционных таблицах обязательно выполнение следующего
требования:
TED11=,…,=TE Di1=,…,=TE Dn1
……………………………
TE D1j=,…,=TE Dij=,…,=TE Dnj
……………………………
TE D1k=,…,=TE Dik =,…,=TE Dnk, i = 1,n; n>>1; j = 1,k; k >= 1,
где n - мощность множества строк данных, k - степень множества i-ой
строки данных; EDij – элемент данных. Другими словами, значения типов
данных одного столбца должны совпадать.
Недопустима ситуация, когда SDi = S Dj , i = 1,n ; j=1,n; i≠j , где n –
мощность множества данных.
Т.е. невозможно полное совпадение строк данных.
Несмотря на некоторое сходство модели данных табличного вида и
модели реляционной таблицы, в них имеются существенные различия.
Сравнивая условия (1-7) в модели данных табличного вида и условия (910) в модели реляционной таблицы, нетрудно заметить, что эти условия не
совпадают. В связи с этим для преобразования данных табличного вида в
реляционные таблицы необходимо как минимум добиться выполнения
условий (9 -10).
При этом целевая функция для условий (1-4) выглядит следующим
образом:
((min(j)  …  min(i)  …  min(t))…  …  …
((min(m)  …  min(k)  …  min(r)), где
j - количество подзаголовков 1-го уровня 1-го заголовка;
t - количество подзаголовков 1-го уровня последнего заголовка;
m - количество подзаголовков 2-го уровня первого подзаголовка заголовка
1-го уровня;
72
r - количество подзаголовков 2-го уровня последнего подзаголовка
заголовка 1-го уровня.
Другими словами число подзаголовков 1-го и 2-го уровней нужно
минимизировать, а точнее совсем от них избавиться. Таким образом, будет
реализована 1-ая нормальная форма - атрибуты реляционной таблицы
должны быть атомарными.
4.3. Преобразование заполненных таблиц к первой
нормальной форме
4.3.1. Избавление от сложных атрибутов
В
работах
[7,8]
обоснована
актуальность
проблемы
преобразования заполненных нереляционных таблиц в реляционные
таблицы,
сформулированы
задачи
преобразования,
намечены
пути
решения отдельных задач. Здесь рассматривается одна из этих задач избавление
от
сложных
атрибутов
в
заполненных
нереляционных
таблицах. Простые атрибуты - это первое условие нормализации
реляционных таблиц. При проектировании таблиц баз данных это условие
закладывается изначально. В нереляционных таблицах или в данных
табличного вида оно, как правило, не обеспечивается.
Для того, чтобы исключить подзаголовки 1-го и 2-го уровней и не
потерять смысл атрибутов можно выполнить конкатенации заголовков и
подзаголовков всех уровней и значениям подзаголовков нижнего уровня
приписать значения конкатенации. После этого необходимо удалить строки
с заголовками 1-го и, если есть таковые, строки с заголовками 2-го уровня.
Этот процесс можно формализовать и соответственно реализовать его в
виде машинных процедур. Однако полностью исключить участие человека
из процесса преобразования данных табличного вида к реляционному виду
удается не всегда, поэтому речь идет о человеко-машинных процедурах.
Для формализации процесса избавления от сложных атрибутов
определим необходимые понятия.
73
Ячейка – это фрагмент таблицы, который имеет четыре ограничителя:
верхний,
нижний,
левый
и
правый.
В
зависимости
от
формата
представления данных табличного вида в качестве ограничителей могут
выступать пробелы, символы табуляции, точки, вертикальные линии,
горизонтальные линии или другие специальные символы. В электронных
таблицах ячейка имеет адрес. В связи с этим одной из причин участия
человека в процессе преобразования является необходимость указания
символов ограничителей ячеек. Ячейка характеризуется номером строки
таблицы данных и номером в строке. Таким образом, Яij - это область
таблицы, выделенная ограничителями, находящаяся в i-ой строке таблицы
и занимающая j-ю позицию. ЛГ(Яij) – левый ограничитель Яij; ПГ(Яij) –
правый ограничитель Яij; УГ – указатель на правую или левую границу
ячейки. С(Яij) – содержимое ячейки; СТi – i-ая строка.
Алгоритм избавления от сложных атрибутов выглядит следующим
образом:
П1:
{Подсчет числа ячеек в 1-ой, 2-ой, и 3-ей строках таблицы.}
{Подсчет выполняется для того, чтобы узнать есть ли в таблице
подзаголовки, а также узнать, сколько уровней подзаголовков.}
М1 := 1;
УГ := ЛГ(Я11);
WHILE ПГ(Я1М1) not EMPTY M1 := M1 + 1;
М2 := 1;
УГ := ЛГ(Я21);
WHILE ПГ(Я2М2) not EMPTY M2 := M2 + 1;
М3 := 1;
УГ := ЛГ(Я31);
WHILE ПГ(Я3М3) not EMPTY M3 := M3 + 1;
IF М2 = М1 THEN GOTO П4; {нет подзаголовков}
IF (М2 > М1) and (M2 = M3) THEN GOTO П2;
IF М3 > М2 THEN GOTO П3;
{один уровень подзаголовков}
П2:
k := 1;
j := 1;
УГ:= ЛГ(Я21);
74
WHILE j <> M2
WHILE ПГ(Я1K) <> ПГ (Я2J)
C(Я2J)= Concat(C(Я1K),' ',C(Я2J));
j := j + 1;
END WHILE;
k := k + 1;
j := j + 1;
END WHILE;
DELETE CT1;
GOTO П4;
{два уровня подзаголовков}
П3:
к := 1;
n := 1;
j := 1;
WHILE j <> M3
WHILE ПГ(Я2n) <> ПГ (Я3j)
C(Я3j) = Concat(C(Я1k),' ',C(Я2n),' ',C(Я3j));
j := j + 1;
END WHILE;
IF ПГ(Я1k) = ПГ(Я3j) THEN k :=k + 1;
n := n + 1;
j := j + 1;
END WHILE;
DELETE CT1;
DELETE CT2;
П4:
END.
Нетрудно заметить, что многие команды алгоритма несколько
напоминают команды языка программирования Pascal. Так сделано в связи
с тем, что при исключении подзаголовков очень вероятна работа с
текстовыми файлами, сам алгоритм неочевиден и оправданна его
изначальная ориентация на предполагаемый язык реализации.
В алгоритме задействован оператор DELETE, применение которого
реализует удаление строк. В П2 удаляется 1-ая строка CT1 со сложными
75
атрибутами. В П3 удаляется 1-ая и 2-ая строки (CT1 , CT2) со сложными
атрибутами. Следует обратить внимание, что алгоритм предназначен для
реализации в человеко-машинных процедурах. Это связано с тем, что
сформированные в соответствии с алгоритмом атрибуты могут быть
длинными и не удовлетворять требованиям инструментальной СУБД. Они
могут оказаться семантически избыточными и нуждаться в корректировке.
Кроме того, в атрибутах могут быть символы, недопустимые с точки зрения
инструментальной СУБД. В качестве таких символов могут выступать “!”,
“.”, “@” и другие. В связи с этим при реализации алгоритма необходимо
предусмотреть автоматизированное исключение из атрибутов символов,
указанных пользователем.
Нетрудно доказать, что алгоритм корректный, т.е. алгоритм сходится.
П1 алгоритма конечен, т.к. число ячеек любой строки таблицы данных
ограничено. П2 и П3 также конечны, так как циклы, которые в них
задействованы, ограничены фиксированными значениями параметров.
Кроме того, алгоритм обладает малой вычислительной сложностью,
которую можно оценить следующим образом. Для П1 максимальное число
итераций оценивается как N*3, где N – число простых атрибутов или
количество ячеек в строках с данными или степень таблицы данных. Для
П2 и П3 максимальное число операций N. Так как П2 и П3 алгоритма
альтернативны, то общая вычислительная сложность алгоритма N*4, т.е.
линейна. Причем значение коэффициента невелико.
Нетрудно показать, что таблица, полученная в результате работы
алгоритма, удовлетворяет 1-ой нормальной форме. Действительно, в
соответствии с требованиями алгоритма (П1), преобразование сложных
атрибутов в простые начинает выполняться, когда количество атрибутов
(заголовков) будет равным числу элементов в строке с данными - N. Если
бы в результате выполнения алгоритма атрибуты остались сложными, то
количество заголовков должно было получиться меньшим количества
элементов в строке с данными, а это противоречит предыдущему
высказыванию. Таким образом, число атрибутов после выполнения
алгоритма соответствует количеству ячеек в строках с данными и эти
атрибуты неделимы. Кроме того, в соответствии с пунктами алгоритма (П2,
П3) вся необходимая информация о семантике столбцов собирается и
76
сохраняется в простых атрибутах. В связи с этим после удаления строк со
сложными атрибутами смысловое назначение столбцов таблицы
не
утрачивается.
Следует отметить, что проблемы с заголовками в данных табличного
вида
полностью
не
исчерпываются
посредством
применения
предложенного алгоритма. В соответствии с моделью данных табличного
вида заголовки могут позиционироваться внутри таблиц. Для исключения
таких
заголовков
чаще
всего
недостаточно
простого
удаления
соответствующих записей. Как правило, для выбора способа избавления
от заголовков, расположенных внутри таблицы, необходим анализ
нескольких факторов. Одним из результатов анализа могут быть выводы о
необходимости реструктуризации таблицы.
Иногда для решения проблемы избавления от сложных атрибутов
оправданно использование существующих средств. Рассмотрим пример
таких средств. В качестве исходной таблицы рассмотрим фрагмент
реальной таблицы, сформированной в Microsoft Excel, представленный на
рис. 4.3.1.
Рис. 4.3.1. Исходная таблица со сложными атрибутами
Как видно из рис. 4.3.1, в таблице имеются два сложных атрибута “Тип оборудования” и ”Цена”. Выполним импорт этой таблицы в СУБД
Access. Для этого используется меню Файл/Внешние данные/Импорт. В
77
процессе выполнения шагов мастера импорта указывается лист рабочей
книги Microsoft Excel, назначается строка заголовка, имя создаваемой
таблицы. Окно мастера на его очередном шаге имеет вид рис 4.3.2.
Рис. 4.3.2. Окно мастера импорта таблиц
При выполнении следующих шагов мастера можно назначить
индексные поля, в отдельных случаях можно назначить типы полей,
назначить ключевое поле. В результате выполнения всех шагов мастера
исходная таблица в формате Microsoft Access примет вид рис 4.3.3.
Рис. 4.3.3. Исходная таблица в формате Microsoft Access
78
Даже из поверхностного анализа заголовков таблицы и содержимого
полей видно, что в таком виде таблица неприемлема для использования. В
связи с этим для избавления от сложных атрибутов необходимо, в
соответствии
с
алгоритмом,
сформировать
простые
заголовки
и
избавиться от подзаголовков, которые попали в значения атрибутов. В
значения атрибутов, как видно из рис. 4.3.3
попали части и некоторых
простых заголовков.
Редактирование заголовков реализуется, когда таблица
открыта в
режиме Конструктора; редактирование полей таблицы реализуется, когда
таблица открыта в режиме Просмотра.
После выполнения необходимых действий в режиме Конструктора и в
режиме Просмотра таблица примет вид рис. 4.3.4.
Рис. 4.3.4. Преобразованная таблица в формате Microsoft Access
Для
рассмотренного
фрагмента
таблицы
описанные
выше
манипуляции не составили большого труда. Однако даже эта таблица в
полном объеме включает в себя более сорока полей, причем многие из них
входят в состав сложных атрибутов. Нередко встречаются таблицы с
несколькими
сотнями
столбцов,
в
этом
случае
рассмотренные
мероприятия могут оказаться нетривиальными.
4.3.2. Исключение подзаголовков расположенных внутри
таблицы
Информация табличного вида нередко представлена таким образом,
что заголовки (атрибуты) таблицы чередуются со значениями атрибутов.
79
Другими словами то, что должно использоваться в качестве заголовков
таблицы используется в качестве их значений. Это недопустимо в
таблицах, используемых в реляционных БД. От такого положения вещей
следует избавляться. Рассмотрим пример, приведенный в табл. 4.3.1.
Т а б л и ц а 4.3.1
Оборудование
Цена
Количество
Эскалаторы
50000
9
Траволаторы
70000
11
Лифты
40000
7
Моторы
7000
77
Эскалаторы
40000
5
Траволаторы
60000
9
Лифты
30000
5
…
…
Москва, Подмосковье
Сибирь, Урал
…
…
Таблицу такого рода невозможно обрабатывать с помощью языка
запросов.
В связи с этим эту таблицу оправданно представить в виде 2-х
связанных реляционных таблиц: ”Продажи” и “Регионы”.
Предлагается
Формируется
новый
следующая
столбец
с
последовательность
номерами
регионов.
действий.
Сканируется
преобразованная таблица, очередному региону присваивается номер, и
этот номер распространяется на товары, проданные в данном регионе.
80
Затем
из
записей
соответствующие
с
регионами
записи
из
формируется
исходной
новая
таблица,
преобразованной
таблицы
удаляются. После этих преобразований будут сформированы 2-е таблицы,
связанные
между
собой
связью
типа
1:
.
Проиллюстрируем
вышесказанное на примере.
Результат формирование нового столбца с номерами регионов и
заполнением столбца приведен в таблице 4.3.2.
Т а б л и ц а 4.3.2
№
Оборудование
Цена
Количество
1
Москва, Подмосковье
1
Эскалаторы
50000
9
1
Траволаторы
70000
11
1
Лифты
40000
7
1
Моторы
7000
77
2
Сибирь, Урал
2
Эскалаторы
40000
5
2
Траволаторы
60000
9
2
Лифты
30000
5
m
…
m
…
…
…
Результат Формирования новой таблицы регионов и исключения
записей с регионами из исходной таблицы приведены соответственно в
табл. 4.3.3 и табл. 4.3.4
Т а б л и ц а 4.3.3
№
Регион
1
Москва, Подмосковье
2
Урал, Сибирь
81
…
m
Т а б л и ц а 4.3.4
№
Оборудование
Цена
Количество
1
Эскалаторы
50000
9
1
Траволаторы
70000
11
1
Лифты
40000
7
1
Моторы
7000
77
2
Эскалаторы
40000
5
2
Траволаторы
60000
9
2
Лифты
30000
5
…
…
m
…
…
…
Для таблиц данного вида вполне можно строить реляционные
запросы.
Для небольшого рассмотренного примера описанные манипуляции
вполне можно выполнить вручную. Для реальных таблиц мощностью
десятки тысяч записей это чрезвычайно затруднительно и чревато
ошибками.
В связи с этим предлагается машинный алгоритм преобразования.
Предварительно представим таблицу (отношение) рассматриваемого
типа в общем виде (табл. 4.3.5).
82
Т а б л и ц а 4.3.5
A1
...
Ai
...
Ak
a11
...
NULL
...
NULL
a21
...
a2i
...
a2k
…
…
…
…
…
aj1
...
NULL
...
NULL
…
...
…
...
…
af1
...
NULL
...
NULL
am1
...
ami
...
amk
Особенность таблицы такого рода состоит в том, что в некоторых ее
строках значение имеет только один атрибут. Принимается, что такой
атрибут является внутренним подзаголовком таблицы.
Неформальный
алгоритм
исключения
подзаголовков
состоит
в
следующих действиях.
П1: Выполняется сканирование всех записей отношения R. Каждая
запись проверяется на наличие в ней только одного значения атрибута.
Записи такого рода подсчитываются. Если таких записей несколько, то
подзаголовки в отношении R присутствуют и выполняется переход к
следующему пункту (П2). В противном случае алгоритм завершает работу.
П2: К отношению R приписывается дополнительный атрибут KR с
типом ”числовой” (формируется R'),.
COUNTER := 0;
П3: Выполняется сканирование всех записей отношения R'. Если в
записи имеется только одно заполненное значение атрибута, то счетчик
подзаголовков COUNTER увеличивается на 1.
Значению атрибута KR присваивается значение COUNTER.
П4: Создается новое отношение R2, включающее в себя 2-а атрибута
NR и атрибут с подзаголовком.
Выполняется сканирование всех записей отношений R'. Записи,
которые имеют только одно (кроме ключевого) заполненное значение,
атрибута перемещаются в отношение R2.
83
В результате выполнения алгоритма сформируются отношение R2 (с
подзаголовками исходной таблицы) и отношение R1 без подзаголовков.
Связи
между
таблицами
обеспечиваются
посредством
ключевых
атрибутов KR, которые присутствуют в обоих отношениях.
Формализованный алгоритм исключения внутренних подзаголовков
выглядит следующим образом.
COUNTER = 0
FOR r = 1 то m
COUNTER1 = 0
FOR f = 1 то k
IF ark = NULL THEN
COUNTER1 = COUNTER1 + 1
NEXT f
IF COUNTER1 = k-1 THEN COUNTER = COUNTER + 1
NEXT r
IF COUNTER  2 THEN EXIT
REM Формирование двух отношений
R’ = R (A1, …, Ai, …, Ak) + R (KR)
COUNTER = 0
FOR r = 1 то m
COUNTER1 = 0
FOR f = 1 то k
IF ark = NULL THEN COUNTER1 = COUNTER1 + 1
NEXT f
IF COUNTER1 = k - 1 THEN
COUNTER = COUNTER + 1
Z(R2 COUNTER,1) = COUNTER
Z(R2 COUNTER,2) = ark
DELETE * FROM R’ WHERE (A1 = ark)
ELSE
84
Z(R’r, 1) = COUNTER
END IF
NEXT r
Здесь m-мощность R.
k – степень R.
Выражение R’ = R + R (KR) означает добавление к R атрибута с
именем KR.
Выражение Z(R2COUNTER,1) означает значение элемента R2 в строке
COUNTER и 1-м столбце.
Выражение Z(R’r, 1) означает значение элемента R’ в строке r и 1-м
столбце.
Важно отметить, что предложенный алгоритм не следует применять
ко всем таблицам, которые нужно преобразовать, а только к тем таблицам,
которые имеют вид подобный рассмотренному примеру.
Назначение таблицы на преобразование – прерогатива разработчика.
Более
того,
после
принятия
решения
о
преобразовании
могут
потребоваться действия разработчика, связанные с приведением исходной
таблицы к регулярному виду. Кроме того, от разработчика потребуются
значительные усилия по формированию связей между полученными
таблицами. Способы наведения связей зависят от инструментальной
СУБД.
В
связи
с
этим
предлагаемый
метод
нельзя
назвать
автоматическим, он – автоматизированный.
Формально условие отсутствия внутренних подзаголовков в таблице
выглядит следующим образом.
  sj (sj  s)  (ajt = NULL) (ajt sj),
j = 1, m; t = 1, k-1.
Здесь s – множество строк таблицы.
ajt – значение t-го атрибута в j-й строке.
m – мощность таблицы; k – степень таблицы.
Для
формализованного
описания
алгоритма
умышленно
использованы обозначения команд, характерных для многих языков
85
программирования. Это сделано для того, чтобы облегчить реализацию
алгоритма на каком-либо языке программирования высокого уровня.
Иногда для избавления от заголовков внутри таблицы оправданно
использование существующих средств. Рассмотрим пример таких средств.
В качестве исходной таблицы рассмотрим фрагмент реальной таблицы
сформированной в Microsoft Excel, представленный на рис. 4.3.5.
Рис. 4.3.5. Фрагмент таблице в формате Microsoft Excel с заголовками
внутри таблицы
После импорта данной таблицы в формат БД Microsoft Access она
примет вид, представленный на рис. 4.3.6.
Рис. 4.3.6. Результат импорта таблицы в СУБД Microsoft Access
86
Нетрудно заметить, что заголовки, расположенные внутри таблицы,
превратились в значения ячеек с заголовком ”Регион”.
Для приведения таблицы к приемлемому виду можно в режиме
Конструктора определить новый столбец ”Месяц”, а потом в режиме
Просмотра
этот
столбец
вручную
заполнить.
Результат
такого
преобразования представлен на рис. 4.3.7.
Рис. 4.3.7. Преобразованная таблица
Теперь остается только удалить записи с пустыми значениями
первого атрибута и таблица примет приемлемый вид. Правда, полученную
таблицу нужно нормализовать, но об этом речь пойдет позже.
Использование рассмотренных средств нетрудоемко и оправданно,
когда таблица включает в себя несколько десятков записей. Реальные же
таблицы нередко включают в себя десятки тысяч записей. В этом случае
такого рода преобразование таблиц трудоемко и может привести к
ошибкам.
Эта же самая таблица, импортированная в
формат Microsoft SQl
Server, выглядит следующим образом (рис 4.3.8).
87
Рис. 4.3.8. Результат импорта таблицы в СУБД Microsoft SQl Server
Результат импорта таблицы в БД Microsoft SQl Server внешне
несущественно отличается от результата импорта таблицы в БД Microsoft
Access (рис. 4.3.6). Однако из рисунка видно, что незаполненные ячейки
явно
представлены
незаполненных
ячеек
значением
выгодно
”NULL”.
отличается
Такое
представление
от
представления
незаполненных ячеек в СУБД Microsoft Access. Дело в том, что в СУБД
Microsoft Access незаполненные ячейки и пустые строки (””) отображаются
одинаково – пустыми ячейками. Таким образом, в СУБД Microsoft Access
визуально невозможно определить содержит ли ячейка данные или нет.
Пустая строка является данными. Значение ”NULL” свидетельствует об
отсутствии данных. В рассматриваемом случае это важно, так как именно
отсутствие данных в определенных ячейках позволяет принять решение о
необходимости
нормализации
таблицы
на
основе
использования
стандартных средств СУБД. Таким образом, в качестве инструментальных
средств, используемых для приведения таблиц к 1-й нормальной форме,
предпочтительно применение средств СУБД Microsoft SQl Server.
4.3.3. Нормализация заполненных таблиц с
первом столбце.
подзаголовками в
Нередко в таблицах первый столбец используется для хранения
подзаголовков групп. Например, это справедливо для табл. 4.3.6.
88
Т а б л и ц а 4.3.6
Секция
Спортсмен
Разряд Год рождения
Плаванье
Федоров
1
1985
Панин
3
1988
Быстров
2
1987
Мишин
1
1984
Конев
3
1989
Батурин
2
1983
Иванов
мастер 1983
Синицын
3
1986
Петров
1
1986
Гребля
Бег
Использование такого рода таблицы в составе БД приведет к тому,
что будет невозможно построить запрос, чтобы получить информацию о
том, в каких секциях занимаются спортсмены Панин, Быстров, Мишин,
Батурин, Иванов, Петров.
В качестве самого простого решения этой проблемы может быть
заполнение всех незаполненных полей в 1-м столбце. Однако это может
привести к неоправданному расходованию памяти. Простое заполнение
столбца оправданно лишь в том случае, если значения 1-го столбца
включают в себя не более 5-ти символов, т.к. для нумерации записей
подавляющего большинства таблиц достаточно 4-х байтов.
В противном случае необходимо:
- выделить 1-й столбец в отдельную таблицу;
89
- пронумеровать его записи;
- исключить в новой таблице повторяющиеся записи;
- пронумеровать записи исходной таблицы в соответствии с новой
таблицей;
- удалить первый столбец исходной таблицы;
- сформировать связи между полученными таблицами.
Выполним описанные преобразования на примере.
В табл. 4.3.7 приведен результат добавления и заполнения ключевого
столбца в исходной таблице.
Т а б л и ц а 4.3.7
Секция
Спортсмен
Разряд Год рождения
K2
Плаванье
Федоров
1
1985
1
Панин
3
1988
1
Быстров
2
1987
1
Мишин
1
1984
1
Конев
3
1989
2
Батурин
2
1983
2
Иванов
мастер 1983
2
Синицын
3
1986
3
Петров
1
1986
3
Гребля
Бег
В табл. 4.3.8 приведен результат формирования новой таблицы и
исключения в ней повторяющихся строк 1-го столбца из исходной таблицы.
Т а б л и ц а 4.3.8
К2
Секция
1
Плаванье
2
Гребля
3
Бег
90
В табл. 4.3.9 приведен результат удаления 1-го столбца из исходной
таблицы.
Т а б л и ц а 4.3.9
Спортсмен
Разряд Год рождения
K2
Федоров
1
1985
1
Панин
3
1988
1
Быстров
2
1987
1
Мишин
1
1984
1
Конев
3
1989
2
Батурин
2
1983
2
Иванов
мастер 1983
2
Синицын
3
1986
3
Петров
1
1986
3
Между данными таблицами имеется связь ”1: ”, которая
осуществляется посредством ключевых полей K2.
Неформальный алгоритм исключения подзаголовков в 1-м столбце
состоит в следующем:
П1: К исходному отношению R добавляется дополнительный атрибут
со значением типа ”числовой”.
П2: COUNTER: = 0
Перебираются все записи отношения R. Если значение 1-го столбца
текущей строки непустое, то COUNTER: = COUNTER + 1.
Значение счетчика записывается в поле ключевого столбца
соответствующей строки.
91
П3: Перебираются все записи отношения R. Если значение 1-го
столбца текущей строки не пустое, то создается новая запись отношения
R2. В первое поле записи R2 заносится значение последнего атрибута
текущей записи отношения R. Во второе поле отношения R2 заносится
значение первого атрибута текущей записи отношения R.
В таблицах незначительного объема предложенные манипуляции
нетрудно выполнить вручную. В таблицах мощностью несколько сотен
записей и более оправданно использование автоматизированных средств.
Для изложения предлагаемого алгоритма в формализованной форме
представим отношение рассматриваемого типа в общем виде (табл.
4.3.10).
Т а б л и ц а 4.3.10
A1
...
Ai
...
Ak
a11
...
NULL
...
NULL
a21
...
a2i
...
a2k
…
…
…
…
…
aj1
...
NULL
...
NULL
…
...
…
...
…
af1
...
NULL
...
NULL
am1
...
ami
...
amk
Нетрудно видеть, что общий вид таблицы рассматриваемого типа
внешне не отличается от общего вида таблицы предыдущего типа. Однако,
смысловое содержание таблиц различается. В предыдущем случае были
”неправильные” записи, а в рассматриваемом случае присутствует
”лишний” столбец.
Подобие общих видов таблиц отражается и на подобии алгоритмов.
Формализованный алгоритм исключения подзаголовков в 1-м столбце
приведен ниже.
R’ = R + R(K2)
C=0
FOR r = 1 то m
92
C1 = 0
FOR f = 1 то k
IF ark = NULL THEN C1 = C1 + 1
NEXT f
IF C1 = k - 1 THEN
C=C+1
Z(R2i 1) = C
Z(R2i 2) = ark
ELSE
Z(ar
k+1)
=C
END IF
NEXT r
DEL A1 FROM R
Принятые
обозначения
аналогичны
обозначениям
предыдущего
алгоритма.
Оператор DEL A1 FROM R означает удаление 1-го столбца из R.
Как
и
в
предыдущем
случае
для
использования
алгоритма
необходимо участие разработчика БД. В частности, участие разработчика
необходимо для принятия решения о необходимости использования
алгоритма.
В отдельных случаях для исключения заголовков в первом столбце
оправданно
качестве
использование
примера
стандартных
рассмотрим
существующих
фрагмент
реальной
средств.
В
таблицы,
представленной в формате Microsoft Excel, который приведен на рис. 4.3.8.
93
Рис. 4.3.8. Фрагмент таблицы в формате Microsoft Excel с заголовками
в 1-м столбце
После импорта этой таблицы в
Microsoft Access она примет
следующий вид (рис. 4.3.9).
Рис. 4.3.9. Результат импорта в Microsoft Access
94
С помощью запроса можно сформировать новую таблицу, которая
включает в себя только заголовки. Этот запрос имеет следующий вид.
SELECT Таблица.Регион INTO Таблица2
FROM Таблица
WHERE (Таблица.Регион) Is Not Null;
В этом запросе из таблицы с именем Таблица (FROM Таблица) в
таблицу с именем Таблица2 (INTO Таблица2) записываются значения поля
”Регион” (Таблица.Регион). Причем выбираются только те поля, которые
имеют непустые значения (WHERE (Таблица.Регион) Is Not Null)
Результат выполнения этого запроса представлен на рис. 4.3.10.
Рис. 4.3.10. Результат выполнения запроса
На следующем шаге преобразований необходимо открыть таблицу
Таблица2 в режиме Конструктора, добавить новое поле типа ”Счетчик” и
назначить его ключевым. После этого таблица примет вид рис. 4.3.11.
Рис. 4.3.11. Таблица2 с дополнительным полем
95
Следующим шагом преобразования является ввод в таблицу 4.3.9
номеров регионов. В результате получится таблица, представленная на
рис. 4.3.12.
Рис. 4.3.12. Таблица с пронумерованными регионами
Для обеспечения связи между таблицами
необходимо в режиме
Конструктора в таблице “Таблица” изменить тип поля ”Регион” на
числовой.
После названных преобразований можно построить схему данных,
которая представлена на рис. 4.3.13.
Рис. 4.3.13. Схема данных
96
После выполненных манипуляций обеспечена ссылочная целостность
данных, т.е. в таблице Таблица нельзя ссылаться на несуществующий
регион. Обеспечивается каскадное обновление, т.е. при изменении
названия региона в таблице Таблица2 все соответствующие ссылки
в
таблице Таблица обновятся. Обеспечивается каскадное удаление, т.е. при
удалении региона из таблицы Таблица2 удалятся все записи, связанные с
этим регионом в таблице Таблица. Кроме того, сводится к минимуму
вероятность ошибок при вводе нового региона. Действительно, вводить
регион достаточно только в одну таблицу.
Для просмотра всей необходимой информации из двух таблиц можно
построить следующий запрос.
SELECT
Таблица2.Регион,
Таблица.[№
п/п],
Таблица.Дата,
Таблица.Заказчик
FROM Таблица2 INNER JOIN Таблица ON Таблица2.[Номер региона]
= Таблица.Регион;
Запрос позволяет выбрать указанные поля из обеих таблиц.
Конструкция
“Таблица2 INNER JOIN Таблица ON Таблица2.[Номер
региона] = Таблица.Регион”
свидетельствует о том, что используется
внутреннее соединение двух таблиц (INNER JOIN), т.е. выбираются из
таблиц
только
те
поля,
у
которых
ключевые
поля
совпадают
(Таблица2.[Номер региона] = Таблица.Регион). В квадратных скобках
указываются поля, в которых есть пробел.
Результат выполнения этого запроса представлен на рис. 4.3.14.
97
Рис. 4.3.14. Результат выполнения запроса
Как видно из выполненных мероприятий, даже для небольших по
объему таблиц, они не являются тривиальными. Повышение размерности
преобразуемых
таблиц
существенно
увеличивает
трудоемкость
необходимых преобразований, а также увеличивает вероятность ошибок
разработчика, допущенных в ходе выполнения преобразования.
4.4. Преобразование заполненных таблиц ко второй
нормальной форме
Отношение считается приведенным ко 2-й нормальной форме, если
никакие неключевые атрибуты не являются функционально зависимыми
лишь от части ключа. Таким образом, 2-я нормальная форма может быть
нарушена только в том случае, если ключ составной [2].
В табл. 4.4.1 приведен пример отношения, которое не удовлетворяет
2-й нормальной форме.
Т а б л и ц а 4.4.1
Табельный № Код работы
Начало работы
Исполнитель
98
1121
2231
3781
2231
1121
3781
2231
Здесь
27
15
27
14
11
12
33
в
качестве
Федоров
Петров
Котов
Петров
Федоров
Котов
Петров
1.1.6
15.1.6
15.1.6
17.2.6
20.1.6
20.5.6
1.1.7
составного
ключа
используются
атрибуты
“Табельный №” и “Код работы”. Нетрудно заметить, что неключевой
атрибут 'Исполнитель' зависит лишь от части ключа – от атрибута
'Табельный №', это приводит к тому, что значение атрибута “Исполнитель”,
как видно из табл. 4.4.1, дублируется. Это приводит к повышению
вероятности ошибок ввода данных – если много раз вводится фамилия
исполнителя, то легко ошибиться в написании или сопоставить ее не тому
табельному номеру.
Кроме того, если потребуется изменить имя исполнителя, то придется
его
менять
во
всех
записях
или
использовать
специальный
параметрический запрос на обновление.
И, наконец, если исполнителю еще не выдано задание, то при таком
представлении данных информация о сотруднике будет отсутствовать.
Чтобы привести данное отношение ко 2-й нормальной форме, его
необходимо представить в виде двух таблиц. При этом 1-я таблица должна
включать в себя все атрибуты, кроме последнего, а 2-я таблица должна
включать в себя последний атрибут и атрибут “Табельный №”.
Таким образом, 1-я таблица примет вид таблицы 4.4.2.
Т а б л и ц а 4.4.2
Табельный № Код работы
1121
27
2231
15
3781
27
Начало работы
1.1.6
15.1.6
15.1.6
99
2231
1121
3781
2231
14
11
12
33
17.2.6
20.1.6
20.5.6
1.1.7
Вторая таблица примет вид (табл.4.4.3).
Т а б л и ц а 4.4.3
Табельный № Исполнитель
1121
Федоров
2231
Петров
3781
Котов
2231
Петров
1121
Федоров
3781
Котов
2231
Петров
После исключения повторов табл. 4.4.3 примет вид таблицы 4.4.4.
Т а б л и ц а 4.4.4
Табельный № Исполнитель
1121
Федоров
2231
Петров
3781
Котов
Теперь табл. 4.4.2 и табл. 4.4.4 связаны между собой посредством
атрибута “Табельный №”.
Когда мощность отношения, как в примере, невелика, нетрудно
выполнить рассмотренные мероприятия вручную. В противном случае это
далеко не всегда возможно.
В
связи
с
этим
предлагается
алгоритм
автоматизированного
приведения заполненных таблиц ко 2-й нормальной форме. Кратко
сформулировать его можно следующим образом.
Для каждого атрибута, входящего в первичный ключ, выполняется
поиск неключевых атрибутов, находящихся в полной функциональной
зависимости. Для этого необходимо выявить ситуации, когда при равных
значениях атрибутов, входящих в первичный ключ, равны значения
неключевых атрибутов, находящихся в одноименных строках. Если такие
100
атрибуты, входящие в первичный ключ найдутся, то исходная таблица
разбивается на две таблицы. Для этого осуществляется операция
проекции для исходной таблицы по всем столбцам, кроме функционально
зависимогостолбца.
Далее осуществляется операция проекции для исходной таблицы по
столбцу с функционально зависимым атрибутом и столбцу, который
является
частью
первичного
ключа
и
для
которого
выявлена
функциональная зависимость.
Таблица, в которую не включен функционально зависимый атрибут,
повторно проверяется на соответствие 2-й нормальной форме, и все
перечисленные манипуляции повторяются.
Для описания алгоритма используется общий вид отношения,
представленный в табл. 4.4.5.
Т а б л и ц а 4.4.5
A1
A2
…
Ai
…
Aj
…
Ak
a11
a12
…
a1i
…
a1j
…
a1k
a21
a22
…
a2i
…
a2j
…
a2k
…
…
…
…
…
…
…
…
an1
an2
…
ani
…
ani
…
ank
…
…
…
…
…
…
…
…
am1
am2
…
ami
…
amj
…
amk
В формализованном виде алгоритм выглядит следующим образом.
Выявление функциональной зависимости.
FOR s = 3 то k
C=0
FOR r = 1 то m
AR1 = ar1
ARS = ars
101
FOR r1 = 1 то m
IF NOT((ar1 1 = AR1) and (ar1 s = ARS)) THEN GOTO M
NEXT r1
C = C +1
IF C = r THEN
sz = s
PRINT (”ЗАВИСИМЫЙ АТРИБУТ”, sz)
STOP
END IF
NEXT r
M: NEXT s
PRINT (”ЗАВИСИМОГО АТРИБУТА НЕТ”)
Поясним алгоритм.
Во внешнем цикле перебираются все столбцы (атрибуты)
кроме
столбцов входящих в первичный ключ. Предполагается, что в ключ входят
два первых атрибута. Переменная
”С” используется для подсчета
”успешных” проходов - проходов, которые не были завершены по команде
"GOTO M”.
В цикле по ”r” выбираются очередное значение первого атрибута,
входящего в первичный ключ
”AR1
= ar,1” и соответствующее ему
значение неключевого атрибута из той же строки ”ARS = ars” и s-го столбца.
Для выбранной пары в цикле по ”r1”
перебираются все записи
отношения. В данном цикле выполняется проверка равенства значения
выбранного неключевого атрибута и текущего неключевого атрибута при
равенстве выбранного атрибута, входящего в первичный ключ и текущего
атрибута, входящего в первичный ключ. Если данное условие не
выполняется, то осуществляется ”аварийный” выход из цикла и в качестве
проверяемого атрибута выбирается следующий s-й столбец отношения.
Если в цикле по ”r”
не было ”аварийных” выходов (C = r), то
зависимый атрибут найден, номер столбца запоминается в переменную sz
для использования ее на следующих шагах алгоритма нормализации.
Следует обратить внимание на то, что, несмотря на сходство работы
алгоритма с двумерным массивом, при его реализации в виде программ
вероятно
данные
не
будут
изначально
представлены
двумерным
102
массивом.
Таблица
может
быть
представлена
текстовым
файлом,
электронной таблицей или файлом БД. В связи с этим в алгоритме
намеренно используются обозначения типа ars, а не a(r,s).
В соответствии с предложенным алгоритмом на функциональную
зависимость проверяется первый атрибут, входящий в первичный ключ.
Для
проверки
на
функциональную
зависимость
второго
атрибута,
входящего в первичный ключ необходимо выполнить такой же алгоритм.
Только вместо ar1 нужно использовать ar2, а вместо ar11 - ar12. Это можно
реализовать, расширив предыдущий алгоритм, но от этого он станет менее
понятен.
При маловероятном стечении обстоятельств программные средства,
реализованные
в
соответствии
с
приведенным
алгоритмом
могут
ошибочно указать на функционально зависимый атрибут. Разработчик БД
легко может выявить эту ошибку, визуально проанализировав две записи
отношения,
в
которых
предполагаются
функционально
зависимые
атрибуты. Поэтому предлагаемый способ приведения отношения ко 2-й
нормальной форме человеко-машинный, (автоматизированный).
Если зависимый атрибут выявлен, то выполняются его следующие
шаги.
Формирование отношения из зависимых атрибутов.
FOR i = 1 TO m
bi1 = ai1
bi2 = ai sz
NEXT i
REM Исключение дублирования
FOR i = 1 TO m
s = Concat(bi1, bi2)
FOR J =i+1 TO m
s1 = Concat(bi1, bi2)
IF s1 = s THEN DLETE(Sj)
NEXT J
NEXT i
103
Поясним алгоритм.
В рамках 1-го цикла строится отношение “B” из 2-х атрибутов. При
этом для каждой строки нового отношения в качестве ключевого (1-го)
значения атрибута используется значение исходного отношения, которое
соответствует части ключа, а в качестве значения второго атрибута
используется
соответствующее
функционально
зависимое
значение
исходного отношения.
В рамках второго цикла исключается дублирование записей в
полученном отношении. Для этого во внешнем цикле посредством
оператора Concat(bi1, bi2) формируется строка из значений текущей записи
отношения, а во внутреннем цикле эта строка сравнивается с оставшимися
строками отношения. Если обнаруживается дублирование строк, то
текущая строка внутреннего цикла посредством оператора
DLETE(Sj)
удаляется.
Следует
обратить
предложенным
внимание
алгоритмом
на
то,
что
предполагается,
в
соответствии
что
с
функционально
зависимым является первый атрибут, входящий в первичный ключ. Если
функционально
зависимым
является
второй
первичный ключ, то вместо переменной
атрибут,
входящий
в
ai1 нужно использовать
переменную ai2.
Упрощение исходного отношения.
FOR i = 1 TO m
C=0
FOR J = 2 TO k
IF j <> sz THEN
C=C+1
di,c = aij
END IF
NEXT J
NEXT i
Поясним алгоритм.
В рамках внешнего цикла перебираются все записи исходного
отношения и формируются записи нового отношения “D”.
104
Во внутреннем цикле заполняются все столбцы нового отношения
значениями столбцов исходного отношения. Причем 1-й столбец не
включается, так как он в качестве ключевого атрибута задействован в
отношении ”B”.
функционально
Не включаются также в отношение ”D” значения
зависимого
столбца
с
номером
”sz”
так
как
он
задействован в отношении ”B”.
Приведение отношений ко 2-й нормальной форме реализовано в
отдельных инструментальных системах, ориентированных на создание БД,
в частности в Microsoft Access. Для этого, вероятно, использован алгоритм
подобный алгоритму описанному выше. Рассмотрим преобразование
отношения, представленного в табл. 4.4.1 ко 2-й нормальной форме.
Соответствующая таблица представлена на рис 4.4.1.
Рис. 4.4.1. Ненормализованная таблица
С помощью меню Microsoft Access Сервис/Анализ/Таблица
необходимо запустить мастер для преобразования таблицы. Выполняя
шаги мастера, разработчик в конечном итоге получит схему данных,
представленную на рис. 4.4.2.
105
Рис. 4.4.2. Схема данных, полученная после нормализации
Как видно из комментариев, представленных в окне, пользователю
предоставляется возможность изменения имен таблиц. Кроме того,
пользователю
предоставляется
возможность
самостоятельно
сформировать подходящие по смыслу группы. Нередко такое предложение
может скорее запутать, чем помочь.
Как видно из схемы данных, в “Таблица1” добавлено ключевое поле с
именем ”Уникальный код”. Неочевидно, что это ключевое поле нужно.
Правда, при желании впоследствии его можно удалить и сформировать
новое ключевое поле.
Кроме того, в “Таблица1” появилось поле с именем “Подстановка
Таблица2”.
Из
связи,
сформированной
на
схеме
данных,
можно
догадаться, что это бывшее поле “Табельный №”.
Рассмотрим содержимое сформированных таблиц. На рис 4.4.3
приведено содержимое “Таблица2”.
106
Рис. 4.4.3. Содержимое таблицы “Таблица2”
На этом рисунке то, что и ожидалось от результатов нормализации.
Он практически совпадает с табл. 4.4.4.
На рис 4.4.4 приведено содержимое таблицы ”Таблица1”.
.
Рис. 4.4.4. Содержимое таблицы “Таблица1”
Некоторое недоумение вызывает поле ”Подстановка Таблица2”. Из
его содержимого можно предположить, что это бывшее поле “Табельный
№”. Действительно, если открыть данную таблицу в режиме Конструктора
(рис. 4.4.5), можно увидеть, что поле с именем “Табельный №”
в
“Таблица1” присутствует. Все дело в том, что в качестве его подписи
использовано другое имя - ”Подстановка Таблица2”
107
Рис. 4.4.5. ”Таблица1” в режиме Конструктора
Для того, чтобы выяснить откуда такое необычное содержимое поля
“Табельный №” (новое имя ”Подстановка Таблица2”) необходимо открыть
вкладку ”Подстановка”, рис. 4.4.6.
Рис. 4.4.6. Вкладка ”Подстановка” для Таблицы
108
Как видно из рисунка, в свойстве ”Число столбцов” задействовано 4-е
столбца. В свойстве ”Источник строк” задействован SQL-запрос, который
выглядит следующим образом:
SELECT [Табельный №] AS xyz_ID_xyz, [Табельный №] & ', ' &
[Исполнитель] AS xyz_DispExpr_xyz, [Табельный №], [Исполнитель] FROM
Таблица2 ORDER BY [Табельный №];
Анализируя эту конструкцию, можно сделать вывод, что для поля с
именем ”Табельный №” в ”Таблица1” при его заполнении предлагается
список из 2-х полей ([Табельный №], [Исполнитель]) таблицы ”Таблица2”. В
качестве
содержимого
в
поле
вводятся
[Исполнитель], разделенные символом
поля
[Табельный
№],
', ' и находящиеся в таблице
“Таблица2”, в которой данные отсортированы по полю [Табельный №]
(ORDER BY [Табельный №]).
Проще говоря, при вводе данных в поле Таблицы1 используется поле
со списком, который строится посредством команды SELECT
Выбор значений из предлагаемого списка проиллюстрирован на рис.
4.4.7. Справа от поля ”Подстановка Таблица2” имеется маркер списка.
После щелчка по этому маркеру сформируется список для выбора нужного
значения.
Рис. 4.4.7. Иллюстрация поля со списком
Резюмируя сказанное выше относительно инструментальных средств
Microsoft Access, ориентированных на приведение отношений ко 2-й
109
нормальной форме, можно сделать вывод о том, что эти средства чаще
всего обеспечивают реализацию нужных функций. Однако результаты
преобразований
модифицировать
не
всегда
результаты
очевидны
и
легко
преобразования
понимаемы,
может
а
только
квалифицированный пользователь Microsoft Access.
В частности, можно убрать ”Подпись” (рис. 4.4.5), изменить вкладку
”Подстановка” в соответствии с рис. 4.4.8.
Рис. 4.4.8. Модифицированная вкладка ”Подстановка” для Таблицы1
Затем можно переписать оператор SELECT следующим образом:
SELECT [Табельный №], [Исполнитель] FROM Таблица2 ORDER BY
[Табельный №];
После этого Таблица1 примет более очевидный и удобный для
дальнейшей модификации вид (рис. 4.4.9).
110
Рис. 4.4.9. Вид модифицированной таблицы “Таблица1”
В связи с вышесказанным можно сделать вывод о том, что
квалифицированный пользователь может использовать средства Microsoft
Access для приведения таблиц ко 2-й нормальной форме. Однако, в этом
случае необходимо самостоятельно выявить ”подозрительные таблицы”, а
затем выполнить необходимые модификации.
Предложенный алгоритм наиболее актуален в том случае, если
данные
не
представлены
или
не
могут
быть
непосредственно
представлены в СУБД типа Microsoft Access.
4.5. Преобразование заполненных таблиц к третьей
нормальной форме
Рассмотрим пример заполненной таблицы, которая удовлетворяет
изложенным выше требованиям, но не удовлетворяет 3-й нормальной
форме. Рассмотрим пример приведенный в виде (табл. 4.5.1).
Т а б л и ц а 4.5.1
111
Преподаватель Должность
Табельный
Шифр
Название
Телефон
кафедры кафедры
№
Иванов
11
Доцент
И6
Компьютерные 111-22системы
Соколов
21
Профессор И6
33
Компьютерные 111-22системы
Романов
35
Наумов
44
Степанов
55
…
…
Доцент
Доцент
И6
И8
Профессор И8
…
…
33
Компьютерные 111-22системы
33
Защита
444-55-
информации
66
Защита
444-55-
информации
66
…
В данном примере легко визуально выявить зависимые атрибуты. Это
“Шифр кафедры” и “Название кафедры”. Даже из этого небольшого
примера очевидна избыточность таблицы: шифры кафедр и названия
кафедр будут дублироваться столько раз, сколько сотрудников на
кафедре.
Избыточность в реляционных БД, как правило, недопустима. Кроме
того,
такое
представление
данных
способствует
ошибкам
при
ее
заполнении. Действительно, вводя много раз значения “Шифр кафедры” и
ее название, легко ошибиться. В конечном счете, это может привести к
противоречивости БД.
В реальных таблицах могут быть сотни атрибутов и тысячи записей,
причем эти записи зачастую не сгруппированы, как в примере. В связи с
этим необходимы автоматизированные, а лучше автоматические средства
исключения зависимых атрибутов.
Суть этих средств сводится к выявлению зависимых атрибутов,
выделению этих атрибутов в отдельную таблицу и формированию связей
между оставшимися и выделенными атрибутами.
112
Неформальный алгоритм выявления зависимых атрибутов состоит в
следующем:
необходимо
выявить
атрибуты
с
повторяющимися
значениями, проверить, есть ли для этих атрибутов зависимые атрибуты,
если таковые есть, отметить все зависимые атрибуты. Важно иметь в виду,
что в таблице может быть несколько групп зависимых атрибутов. Это
следует учесть при разработке алгоритма.
Более
детально
алгоритм
выявления
зависимых
атрибутов
сформулирован ниже:
П1: Перебираются атрибуты от 1-го до предпоследнего, исключая
ключевые. Для каждого атрибута выполняется подсчет совпадений их
значений. Если совпадения есть, то запоминаются номера кортежей с
одинаковыми атрибутами для каждой группы. Каждая выявленная группа
проверяется на принадлежность к зависимым атрибутам. Для этого для
каждой группы выполняются следующие действия:
П2: Перебираются все элементы группы и анализируются значения
ближайшего справа атрибута в соответствующих кортежах.
П3: Если все значения в соответствующих кортежах равны между
собой, то выявлена функциональная зависимость для группы. Проверку
необходимо выполнить для всех групп рассматриваемого атрибута. Если
выявлена функциональная зависимость для всех групп, то это означает,
что анализируемый атрибут является зависимым. Кроме того, зависимым
является и атрибут (сосед справа), их номера запоминаются.
П4: Если для двух атрибутов выявлена функциональная зависимость,
то для выявленных атрибутов осуществляется попытка нахождения других
зависимых атрибутов. Для этого выбирается следующий атрибут справа и
выполняется П2. П2 выполняется до тех пор, пока не исчерпаются все
атрибуты. После того, как исчерпаны все атрибуты, то алгоритм завершает
работу, выдаются номера зависимых атрибутов – функциональная
зависимость найдена и будет обрабатываться.
П5: Если в П4 не все значения в соответствующих кортежах равны
между собой, то выбирается следующая группа совпадающих атрибутов и
выполняется переход к П3.
Если перебраны все группы текущего атрибута, то выполняется
переход к П1.
113
П6: Если перебраны все k-1 атрибутов отношения, то функциональная
зависимость не найдена, о чем выдается соответствующее сообщение.
Т.к. в отношении может быть несколько сочетаний зависимых
атрибутов, то после избавления от найденных зависимых атрибутов
алгоритм
следует
применить
повторно.
Причем
алгоритм
следует
применять повторно до тех пор, пока не перестанут выявляться зависимые
атрибуты.
Так как алгоритм несколько запутан, то перед его формализованным
описанием оправданно его проиллюстрировать на приведенном примере.
Первый столбец пропускается, т.к. он ключевой. Выбирается второй
столбец ”Преподаватель”. Анализируются его значения: одинаковых
значений нет. Поэтому выбирается следующий столбец “Должность”.
Анализируются его значения. Выявлено 2-е группы с совпадающими
значениями – “Доцент” и “Профессор”. Значит атрибут “Должность”
необходимо проверить на функциональную зависимость.
Проверяем значения соседнего справа атрибута для группы “Доцент”
на совпадения. В первом кортеже, где есть значение “Доцент”, значение
“Шифр кафедры” – И6, в третьем – И6, в пятом – И8. Не все значения
атрибута “Шифр кафедры” совпадают. Поэтому нет необходимости
рассматривать
группу
“Профессор”.
Функциональной
связности
с
атрибутом “Шифр кафедры” нет.
Проверяем, не связан ли атрибут “Должность” со следующим
атрибутом “Название кафедры”. Оказывается, что значению “Доцент”
соответствует
значение
информации”.
Таким
и
“Компьютерные
образом,
нет
системы”
функциональной
и
“Защита
зависимости
у
атрибута “Должность” и с атрибутом “Название кафедры”. Таким образом,
атрибут “Должность” ни с каким атрибутом не связан функциональной
зависимостью.
Выбираем
следующий
атрибут
для
анализа
функциональной
зависимости – “Шифр кафедры”. Анализируем значения этого атрибута на
совпадение. В результате выявляются две группы – “И6” и “И8”.
Проверяем для группы “И6” зависимость в соседнем справа столбце.
Получается следующий результат: 'Компьютерные системы' соответствуют
всем
вхождениям
“И6”.
Проверяем
для
следующей
группы
“И8”
114
зависимость в соседнем справа столбце. Получаем следующий результат:
столбец ”Защита информации” соответствует всем вхождениям “И8”.
Больше групп для проверки нет, поэтому делается вывод, что атрибуты
“Шифр кафедры” и “Название кафедры” функционально зависимы.
Следует
отметить,
что
ошибка
в
принципе
возможна,
хотя
маловероятна. Например, если бы на кафедрах работали преподаватели,
занимающие одну должность, то был бы сделан ошибочный вывод о том,
что между должностью и кафедрой имеется функциональная зависимость,
хотя таковой в соответствии с семантикой таблицы нет. В связи с этим
некоторое участие разработчика необходимо. Только он может оценить
смысловые нюансы. Поэтому предлагаемый метод – человеко-машинный.
Далее
предлагается
формализованное
описание
алгоритма
выявления функциональной зависимости. В описании используются
значения, принятые в Табл. 4.1.
FOR r = 1 то k – 1, k  NK
ZAV = 0
F=0
FOR r1 = r + 1 то k -1, k  NK
FOR f = 1 TO m
Smr = SELECT COUNT(amr ) FROM Ar
IF Smr  1 THEN
Smr1 = SELECT COUNT(amr1 ) FROM Ar1
IF Smr1  1 and Smr1 = Smr
THEN
Fr = 1
Fr1 = 1
ZAV = 1
ELSE
ZAV = 0
GOTO M
END IF
NEXT f
115
M:NEXT r1
IF ZAV = 1 THEN
PRINT (“Зависимые атрибуты”)
FOR i= 1 то k – 1, k  NK
PRINT (Fi)
NEXT i
END IF
NEXT r
Здесь NK – номер ключевого атрибута. Конструкция SELECT COUNT
(amr) FROM Ar означает количество повторений значения атрибута amr. F –
множество номеров зависимых атрибутов.
Дадим краткое пояснение алгоритму.
Во внешнем цикле перебираются все столбцы, кроме ключевого
столбца. Флажок ZAV и множество F обнуляется. В следующем цикле
перебираются остальные столбцы. В цикле по f перебираются все
значения текущего столбца, и для каждого значения подсчитывается число
его повторений. Если это число повторений больше 1, то подсчитывается
количество повторений значения атрибута, находящегося в той же строке и
соседнем столбце. Если количества повторений совпадает, то может быть
это и есть зависимый атрибут. Поэтому, на всякий случай, в массиве F
запоминается номера столбцов и флажку ZAV присваивается 1. Если нет,
то функциональной
зависимости наверняка нет, поэтому выполняется
обнуление ZAV и принудительный выход из цикла.
Если по окончанию
цикла по r1 переменная ZAV оказалась равной 1, то это значит, что ни разу
не произошло принудительного выхода из цикла. А это означает то, что в
обоих столбцах количество совпадений элементов, находящихся в
одноименных строках всегда было равно друг другу, что косвенно
свидетельствует о функциональной зависимости.
Следует отметить, что алгоритм позволяет выявлять только группы из
двух зависимых атрибутов. Для выявления групп из трех и более
зависимых
атрибутов
алгоритм
необходимо
несущественно
преобразовать.
116
Следующим шагом методики является приведение отношения к 3 – й
нормальной форме, т.е. избавление от функциональной зависимости.
Избавление от функциональной зависимости.
В качестве исходных данных для метода исключения функциональной
зависимости
множество
выступают
отношения
с
зависимыми
атрибутами
и
F (множество зависимых атрибутов), которое формируется
посредством предложенного выше алгоритма.
Для исключения функциональной зависимости необходимо выделить
зависимые атрибуты в отдельную таблицу R2, исключить соответствующие
атрибуты из исходного отношения R1, исключить дублирование записей в
R2 и организовать связи между отношениями R1 и R2.
Неформально алгоритм выглядит следующим образом:
П1: Из отношения R1 исключаются все зависимые атрибуты, кроме
одного.
П2: Формируется отношение R2  R1 из зависимых атрибутов.
П3: Из R2 исключаются дублирующие записи.
П4: К отношению R2 добавляется столбец типа COUNTER и
назначается ключевым атрибутом.
П5: Перебираются значения с зависимым атрибутом в отношении R2,
который не был удален из отношения R1.
П6: Для каждого выбранного значения атрибута сканируются атрибуты
не
удаленного
совпадают,
то
столбца
найденное
отношения
значение
R1.
Если
значения
отношения R1
атрибутов
заменяется на
соответствующее значение ключевого атрибута из отношения R2.
В результате выполнения алгоритма сформируются две таблицы со
связью типа “1:”. Причем со стороны “1” позиционируется отношение R2,
а со стороны “” – R1.
Проиллюстрируем алгоритм на примере.
В результате выполнения П1 и П2 получится отношение R1 (табл.
4.5.2),
Т а б л и ц а 4.5.2
117
Табельный
Преподаватель
Должность
Шифр кафедры
11
Иванов
Доцент
И6
21
Соколов
Профессор
И6
35
Романов
Доцент
И6
44
Наумов
Доцент
И8
55
Степанов
Профессор
И8
№
В результате выполнения П1 и П2 сформируется также отношение R2
(табл. 4.5.3),
Т а б л и ц а 4.5.3
Шифр кафедры
Название кафедры
Телефон
И6
Компьютерные
111-22-33
системы
И6
Компьютерные
111-22-33
системы
И6
Компьютерные
111-22-33
системы
И8
Защита информации
444-55-66
И8
Защита информации
444-55-66
В результате выполнения П3 и П4 отношение R2 примет вид таблицы 4.5.4
Т а б л и ц а 4.5.4
Ключ
Шифр
Название кафедры
Телефон
118
кафедры
1
И6
Компьютерные системы
111-22-33
2
И8
Защита информации
444-55-66
В результате выполнения П5 отношение R1 примет вид таблицы 4.5.5.
Т а б л и ц а 4.5.5
Табельный
Преподаватель
Должность
Шифр кафедры
11
Иванов
Доцент
1
21
Соколов
Профессор
1
35
Романов
Доцент
1
44
Наумов
Доцент
2
55
Степанов
Профессор
2
№
Даже из этого небольшого примера видна выгода преобразования
отношения. Учитывая то, что зависимых атрибутов могут быть десятки,
атрибутов – сотни, а записей – тысячи, выгода становится более
очевидной.
Формализованный алгоритм избавления от зависимых атрибутов
выглядит следующим образом.
F = (F1,…, Fi,…, Ft) – множество зависимых атрибутов
F' = (F1,…, Fi,…, Ft-1) – множество зависимых атрибутов без одного
(F’  F)
П1: Формируется R1  A  R такое, что
 Aj (R j A) (F’ Aj) j = 1, k, где k – степень отношения R.
П2: Формируется R2  B  R такое, что
 Bn (Bn  R) (Bn  F) n = 1, k
П3: R2' = SELECT B1, B2, …, Bf, …, Bk2
FROM R2 GROUP BY
B1, B2, …, Bf, …, Bk2
П4: R2’’ = R2’ U RK, где RK – отношение степени 1 и мощности, равной
мощности R2’, с типом атрибута COUNTER.
119
П5: FOR r = 1 то m
art = SELECT ключ FROM R2’’
WHERE art = Bt
NEXT r
Здесь art – значение атрибута отношения R1 в строке с номером r, в
столбце с зависимым атрибутом. Bt – столбец с зависимым атрибутом в
отношении R2''.
m – мощность отношений R и R1.
Приведение отношений ко 3-й нормальной форме реализовано в
отдельных инструментальных системах, ориентированных на создание БД,
в частности в Microsoft Access. Для этого, вероятно, использован алгоритм,
подобный алгоритму описанному выше. Рассмотрим преобразование
отношения, представленного в табл. 4.5.1. ко 2-й нормальной форме.
Исходная таблица представлена на рис. 4.5.1.
Рис. 4.5.1. Исходная таблица
После
необходимых
выполнения
шагов
команды
мастера
меню
будет
Сервис/Анализ/Таблица
сформирована
схема
и
данных,
представленная на рис 4.5.2.
120
Рис. 4.5.2. Схема данных, полученная в результате анализа
Из схемы данных видно, что телефоны кафедр сгруппированы в одну
таблицу “Таблица4”, хотя их оправданно хранить в таблице ”Таблица2”.
Средства анализа системы, как видно из подсказки в верхней части
экранной формы, позволяют перетащить неправильно распределенные
поля в нужные таблицы и в результате получить
схему данных,
представленную на рис. 4.5.3.
121
Рис. 4.5.3. Модифицированная схема данных
Вся проблема в том, что далеко не всегда для разработчика БД
очевидны правильные группировки полей. И в связи с этим возможны
ситуации, когда использование средств анализа не улучшит, а ухудшит
положение вещей.
Правда, в пользу преобразования в данном случае говорит выделение
должностей преподавателей в отдельную таблицу, и таким образом
исходная таблица приведена
не только к 3-й, но и ко 2-й нормальной
форме.
После выполнения всех шагов мастера сформируются таблицы,
представленные на рис. 4.5.4, рис.4.5.5, рис. 4.5.6.
Рису. 4.5.4. Таблица должностей
122
Рис. 4.5.5. Таблица кафедр
Рис. 4.5.6. Таблица преподавателей
Если вид первых двух таблиц очевиден, то последняя таблица
нуждается в анализе и изменениях. Конечно, из лучших соображений для
поля с кодом “Должность” назначена подпись ”Подстановка Таблица3”, а
для поля с кодом “Кафедра” назначена подпись ”Подстановка Таблица4”.
Сама же информация, выводимая в этих полях, может озадачить и
разработчика БД средней квалификации. Дело в том, что в этих полях
хранятся коды, а выводятся соответствующие кодам данные. Это может
ввести разработчика в заблуждение, так как
над содержимым этих полей
можно выполнять математические операции (ведь это числа), а судя по
внешнему виду – нельзя.
Для того, чтобы разобраться, каким образом
необходимо
открыть
таблицу
в
режиме
так получилось,
Конструктора.
Вкладка
”Подстановка” для поля с кодами кафедры представлено на рис. 4.5.7.
123
Рис. 4.5.7. Вкладка ”Подстановка” для поля с кодами кафедры
Из рисунка видно, что присоединенный столбец 1-й, а выводится при
подстановке 4-е столбца. Посредством свойства ”Ширина столбцов” 2-а
столбца скрыты. В результате при выборе значения для соответствующего
столбца поле примет вид рис. 4.5.8.
Рис. 4.5.8. Поле со списком
В качестве источника строк для поля со списком используется
следующая SQL команда:
SELECT [Код] AS xyz_ID_xyz, [Название кафедры] & ', ' & [Телефон
кафедры] AS xyz_DispExpr_xyz, [Название кафедры], [Телефон кафедры]
FROM Таблица2 ORDER BY [Название кафедры], [Телефон кафедры];
124
Эта команда свидетельствует о том, что из таблицы Таблица2
выводятся поля: [Код]; [Название кафедры] & ', ' & [Телефон кафедры];
[Название кафедры]; [Телефон кафедры].
С помощью конструкции AS первым двум полям приписаны имена.
С помощью конструкции ORDER BY выполняется сортировка.
Для приведения таблицы с преподавателями
к другому виду
необходимо изменить свойства вкладки ”Подстановка” и запрос – источник
данных.
Кроме формирования новых таблиц на основе ненормализованной
таблицы средства анализа Microsoft Access формируют запрос, который
позволяет собрать данные из вновь сформированных таблиц. Результаты
выполнения этого запроса представлены на рис. 4.5.9.
Рис. 4.5.9. Результаты выполнения запроса
Как видно из рисунка, он существенно отличается от рис. 4.5.1, на
котором представлена исходная таблица. Такой запрос скорее мешает,
чем помогает, поэтому необходимо сформировать другой запрос, бланк
которого представлен на рис. 4.5.10.
125
Рис. 4.5.10. Бланк запроса.
Результат выполнения этого запроса представлен на рис. 4.5.11.
Рис. 4.5.11. Результат выполнения запроса
Как видно из рис. 4.5.11, результат выполнения запроса полностью
совпадает с исходной таблицей (рис. 4.5.1).
4.6. Преобразование заполненных таблиц к четвертой
нормальной форме.
Для
формулировки
и
пояснения
цели
рассмотрим
пример
приведенный в форме табл. 4.6.1.
126
Т а б л и ц а 4.6.1.
№
Песня
Слова
Музыка
Исполнитель
Звание
исполнителя
1
П1
С1
М1
И1
Н
2
П2
С2
М2
И2
З
3
П3
С3
М3
И3
А
4
П1
С1
М1
И2
З
5
П1
С1
М1
И3
А
6
П2
С2
М2
И1
Н
7
П2
С2
М2
И3
А
8
П3
С3
М3
И2
З
9
П3
С3
М3
И1
Н
Для
компактности
примера
при
записи
значений
атрибутов
использованы мнемонические обозначения.
Суть примера в том, что одну и ту же песню могут исполнять
несколько
исполнителей.
В
таблице
представлены
3
песни
и
3
исполнителя. Если случится так, что каждый исполнитель поет все 3 песни,
то для хранения данных об этом, как видно из примера, требуется 9
записей. Но для хранения информации о песнях и об исполнителях
достаточно по 3-и записи (всего 6). В реальных таблицах эти цифры могут
быть на несколько порядков больше.
Связи такого рода внутри таблицы называются множественными, и от
них следует избавляться с тем, чтобы неоправданно не расходовать
память.
При
проектировании
реляционных
таблиц
в
соответствии
с
требованиями их нормализации [2] множественные зависимости не
допускаются. В случае же заполненных таблиц зависимости такого рода
вполне могут быть и от них необходимо избавляться.
Предлагается
следующий
способ
избавления
от
многозначных
зависимостей.
В таблице ищутся кортежи атрибутов, конкатенации значений которых
встречаются неоднократно. Если такие кортежи находится, то вероятно
127
имеет
место
многозначная
зависимость.
Для
избавления
от
этой
зависимости формируются таблицы с найденными кортежами атрибутов.
В них исключаются повторяющиеся записи. Затем для каждой пары
полученных таблиц строится таблица, которая обеспечивает связи записей
этой пары между собой – таблица связей. Таблица связей строится на
основе анализа исходной таблицы.
Прежде, чем предложить формальный алгоритм, проиллюстрируем
алгоритм на примере.
После сканирования таблицы и анализа всех возможных кортежей
атрибутов выявляются две группы кортежей атрибутов, конкатенации
значений которых повторяются. Эти таблицы (отношения) R1 и R2,
представлены ниже. Отношение R1 приведено в табл. 4.6.2. Отношение
R2 приведено в табл. 4.6.3.
Т а б л и ц а 4.6.2
Песня
Слова
Музыка
Т а б л и ц а 4.6.3
Исполнитель Звание
исполнителя
П1
С1
М1
И1
Н
П2
С2
М2
И2
З
П3
С3
М3
И3
А
П1
С1
М1
И2
З
П1
С1
М1
И3
А
П2
С2
М2
И1
Н
П2
С2
М2
И3
А
П3
С3
М3
И2
З
П3
С3
М3
И1
Н
В отношениях R1 и R2 исключаем дублирование записей. В
результате получаем новые отношения R1' и R2’ (табл. 4.6.4 и табл. 4.6.5).
Т а б л и ц а 4.6.4
Т а б л и ц а 4.6.5
128
Песня
Слова
Музыка
Исполнитель Звание
исполнителя
П1
С1
М1
И1
Н
П2
С2
М2
И2
З
П3
С3
М3
И3
А
Приписываем к отношениям R1’ и R2’ ключевые столбцы типа
COUNTER. В результате таблицы примут вид табл. 4.6.6 и табл.4.6.7.
Т а б л и ц а 4.6.6
Песня
Слова Музыка N1
Т а б л и ц а 4.6.7
N2
Исполнитель Звание
исполнителя
П1
С1
М1
1
1
И1
Н
П2
С2
М2
2
2
И2
З
П3
С3
М3
3
3
И3
А
Теперь перебираем все записи отношения R1. Для каждой записи
ищем ее позицию
в R1’, запоминаем ее в K1. В R2 выбираем
соответствующую запись, ищем ее позицию в R2’, запоминаем ее в K2.
Формируем новую запись отношения R3 = (K1, K2). Записываем K1, K2 в
соответствующие поля отношения R3.
Например, 1-я запись в R1 находится в 1-й позиции R1’.
K1 =1.
Соответствующая запись в R2 находится в 1-й позиции R2’. K2 =1.
В результате перебора всех записей R1
и выполнения описанных
действий будет сформировано отношение R3 вида (табл. 4.6.8).
Т а б л и ц а 4.6.8
129
Полученное
отношение
К1
К2
1
1
2
2
3
3
1
2
1
3
2
1
3
2
3
1
обеспечивает
связь
“
:
”
между
отношениями R1’ и R2’.
При необходимости можно сформировать запрос на основе таблиц
R1’, R2’ и R3’, который позволит сформировать исходное отношение.
Даже в этом небольшом примере очевидна экономия памяти. В R
задействовано 54 поля, в R1’, R2’ и R3 – 39 полей. На основе изложенного
предлагается
следующий
формализованный
алгоритм
приведения
заполненных таблиц к 4-й нормальной форме.
П1: Выявление групп кортежей атрибутов, конкатенации значений
которых повторяются
FOR r = 1 то k–1, k  NK
A = Ar
F=0
FOR q = r + 1 то k-1, k  NK
A = concat (A, Aq)
C = SELECT A FROM R GROUP BY A;
IF C = 1 THEN
A = A - Aq
ELSE
F=1
END IF
NEXT q
IF F = 1 THEN PRINT(A)
130
NEXT r
Здесь IA – множество позиций атрибутов, конкатенации значений
которых повторяются.
afr – значение атрибута Ar в f –ой строке.
k – степень R.
NK – номер ключевого атрибута;
Выражение SELECT A FROM R GROUP BY A; - SQL–подобная
команда, позволяющая подсчитать количество повторяющихся значений с
набором атрибутов А. Результат его выполнения – множество чисел.
Каждое число соответствует количеству повторений какого–либо набора
значений атрибутов.
С – множество этих чисел.
Выражение С = 1 означает, что повторений значений атрибутов нет. (С
– единичное множество).
Выражение A = A - Aq означает исключение из конкатенации атрибутов
атрибута Aq.
П2: Формирование таблиц без внутренних зависимостей.
R1 = Проекция A из R.
A1 = AR – A
R2 = Проекция A’ из R.
Исключение дублирования
R1’ = SELECT A FROM R1 GROUP BY A
R2’ = SELECT A FROM R2 GROUP BY A’
Здесь проекция A из R означает операцию реляционной алгебры –
проекцию, которая выполняется над отношением R. Атрибуты проекции
составляют множество A. Ограничений при выборе нет. Другими словами
формируется таблица со столбцами из множества А.
AR – множество атрибутов R;
Строго говоря, при выполнении команды ”Проекция” дублирование
записей исключается. Однако для большей прозрачности алгоритма и
удобства его реализации приведены две последние команды.
131
Назначение R1’ и R2’ ключевых атрибутов
A = A + N1
A’ = A’ + N2,
где N1 – ключевой атрибут типа COUNTER для отношения R2', N2 –
ключевой атрибут типа COUNTER для отношения R2’.
П3: Формирование таблицы для организации связей между R1’ и R2’.
FOR f = 1 то m
C1 = 0
FOR f1 =1 то m1
C1 = C1 + 1
IF Sf(R1) = Sf1(R1’) THEN GOTO M1
NEXT f1
M1: C2 = 0
FOR f2 = 1 то m2
C2 = C2 + 1
IF Sf (R2) = Sf2 (R2’) THEN GOTO M2
NEXT f2
M2: r3f,1 = C1
r3f,2 = C2
NEXT f
Здесь m - мощность R1, R2;
m1 – мощность R1’;
m2 – мощность R2’;
Sf (R2) – список значений f-й строки отношения R1.
Sf1(R1’) - список значений строки f1 отношения R1’ (из списка
исключено значение ключевого атрибута).
Аналогично Sf (R2) и Sf2 (R2’).
r3f,1 – значение 1-го атрибута f-й строки отношения R3.
r3f,2 – значение 2-го атрибута f-й строки отношения R3.
Важно отметить, что предложенный алгоритм позволяет исключить
одну множественную зависимость в отношении R. Не исключено, что в
отношениях R1' и R2' могут также быть множественные зависимости, хотя
132
это случается редко. Прерогатива разработчика – проверить R1' и R2' на
наличие множественных зависимостей.
В случае необходимости с помощью соответствующего запроса из
полученных
3-х
отношений
легко
получить
нужную
информацию.
Например, посредством запроса SELECT…формируется отношение R.
Выполним попытку нормализовать таблицу 4.6.1 стандартными
средствами СУБД Microsoft Access. В формате Microsoft Access она
представлена на рис. 4.6.1.
Рис. 4.6.1. Исходная таблица в формате Microsoft Access
После запуска мастера (меню Сервис/Анализ/таблица) и выбора
данной таблицы Microsoft Access сформирует следующее сообщение (рис.
4.6.2).
Рис. 4.6.2. Сообщение Acces
Т.е. использование мастера не позволяет выполнить действия по
приведению таблицы к 4-й нормальной форме. Мастер рекомендует
использование средств самостоятельного разделения. Далеко не всегда в
реальных таблицах с большим числом столбцов и записей разработчик
133
может выделить поля, которые можно сгруппировать. Однако можно
попытаться нормализовать таблицу посредством предлагаемых средств.
Включение соответствующего мастера приведет к формированию окна
мастера, приведенного на рис. 4.6.3.
Рис. 4.6.3. Окно мастера анализа таблиц
Если разработчик сможет догадаться, что поля “Исполнитель” и
“Звание исполнителя” должны принадлежать отдельной таблице, то он
может перетащить эти поля в новую таблицу. Результат преобразования
представлен на рис 4.6.4.
Рис. 4.6.4. Результат преобразования
134
К сожалению, если разработчик подозревает о наличии связи многие ко многим, с использованием рассматриваемых средств он не сможет
создать третью объединяющую таблицу. Поэтому будет сформировано
две таблицы (рис. 4.6.5 и рис. 4.6.6).
Рис. 4.6.5. Вид Таблицы1
Рис. 4.6.6. Вид Таблицы2
Некоторое улучшение состояния дел произошло в таблице Таблица2,
в ней значительно меньше записей, чем в исходной таблице. Однако от
связи многие - ко многим избавиться не удалось.
Выполним
манипуляции
в
рамках
Microsoft
Access,
которые
необходимы для приведения отношения, представленного на рис. 4.6.1 к
4-й нормальной форме.
Посредством следующего запроса сформируем новую таблицу на
базе исходной таблицы:
SELECT Песни.Песня, Песни.Слова, Песни.Музыка INTO Песня
FROM Песни;
135
Здесь создается новая таблица “Песня’. Она формируется на основе
полей “Песня”, “Слова” и “Музыка” из таблицы “Песни”. В результате
выполнения запроса сформируется таблица, представленная на рис. 4.6.7.
Рис. 4.6.7. Таблица песен, сформированная на базе исходного
отношения
Для исключения дублирования записей в таблице, приведенной на
рис. 4.6.1 и создания таблицы без дублирования используется следующий
запрос:
SELECT DISTINCT Песня.Песня, Песня.Слова, Песня.Музыка INTO
Песня1
FROM Песня;
В данном запросе на базе таблицы “Песня” формируется таблица
“Песня1”. Конструкция DISTINCT позволяет передать записи в новую
таблицу без дублирования. В результате выполнения данного запроса
сформируется таблица, приведенная на рис. 4.6.8.
Рис. 4.6.8. Таблица без дублирования записей
136
Теперь для полученной таблицы сформируем ключевое поле типа
“Счетчик”. Для этого откроем данную таблицу в режиме Конструктора и
добавим к списку ее полей нужное поле. На рис. 4.6.9 приведена
модифицированная таблица в режиме Конструктора.
Рис. 4.6.9. Модифицированная таблица в режиме Конструктора
Вид модифицированной таблицы в режиме Просмотра показан на рис.
4.6.10.
Следует
обратить
внимание
на
то,
что
в
свойстве
”Индексированное поле” нового поля ”Код поля” выбрана опция “Да
(Совпадения не допускаются)”. Это обеспечивает уникальность поля ”Код
поля”.
Рис. 4.6.10. Вид модифицированной таблицы в режиме Просмотра
Таким образом, посредством проведенных мероприятий на базе
исходной
таблицы
сформирована
новая
таблицы,
которая
137
позиционируется
с
одной
стороны
”многие”
и
включает
в
себя
соответствующие поля. Кроме того, в новой таблице сформировано
ключевое поле, посредством которого впоследствии будет организована
связь с другой таблицей, которая позиционируется
с другой стороны
”многие”.
Эта другая таблица включает в себя поля ”Исполнитель” и ”Звание
исполнителя”. Выполнив манипуляции с исходной таблицей, подобные
манипуляциям, проделанным выше, получим новую таблицу, которая
представлена на рис. 4.6.11.
Рис. 4.6.11. Вид полученной таблицы исполнителей в режиме
Просмотра
Следующим
шагом
приведения
исходного
отношения
к
4-й
нормальной форме является создание таблицы из ключевых полей
построенных таблиц, которые приведены на рис. 4.6.10 и 4.6.1.
В режиме Конструктора данная таблица выглядит в соответствии с
рис. 4.6.12.
138
Рис. 4.6.12. Таблица для организации связей, представленная в
режиме Конструктора
Следует обратить внимание на то, что типы полей выбраны ”Длинное
целое”. Так сделано в связи с тем, что эти поля предполагается
использовать для связывания с соответствующими полями таблиц,
которые приведены на рис. 4.6.10 и 4.6.1. Типы полей для связывания
должны совпадать. А в таблицах, которые приведены на рис. 4.6.10 и 4.6.1,
соответствующие поля имеют тип ”Счетчик”. Для формирования значения
поля типа ”Счетчик” используется тип данных ”Длинное целое”.
В свойствах полей “Индексированное поле” выбраны значения ”Да
(Допускаются совпадения)”. Это сделано в связи с тем, что по данным
полям могут сортироваться записи, кроме того, значения данных полей
могут повторяться.
Следующим
нормальной
шагом
форме
приведения
является
исходного
построение
отношения
схемы
данных
к
4-й
из
3-х
к
4-й
сформированных таблиц.
Очередным
шагом
приведения
исходного
отношения
нормальной форме является заполнение таблицы ”Связи”, которая
139
связывает таблицы ”Песня1” и ”Исполнитель1”. Для этого можно вывести
на экран содержимое 4-х таблиц: исходной, ”Песня1”, ”Исполнитель1” и
таблицы ”Связи”. Затем в соответствии с ранее изложенным алгоритмом
вручную заполнить таблицу ”Связи”.
На рис. 4.6.13 приведена соответствующая экранная форма.
Рис. 4.6.13. Экранная форма с 4-я таблицами, открытыми в режиме
Просмотра, редактирования и ввода данных
После заполнения таблицы ”Связи” в соответствии с предложенным
алгоритмом она примет вид, приведенной на рис. 4.6.14.
140
Рис. 4.6.14. Экранная форма с 4-я таблицами и заполненной
таблицей ”Связи”
Собрать данные в одну таблицу из 3-х можно с помощью запроса, вид
бланка которого приведен на рис. 4.6.15.
Рис. 4.6.15. Бланк запроса для сбора данных из трех таблиц
В формате SQL данный запрос выглядит следующим образом:
141
SELECT
Песня1.Песня,
Песня1.Слова,
Песня1.Музыка,
Исполнитель1.Исполнитель, Исполнитель1.[Звание исполнителя]
FROM Песня1 INNER JOIN (Исполнитель1 INNER JOIN Связи ON
Исполнитель1.[Код
исполнителя]
=
Связи.[Код
исполнителя])
ON
Песня1.[Код песни] = Связи.[Код песни]
ORDER BY Песня1.Песня;
Посредством данного запроса из двух таблиц выбирается пять полей.
Первая конструкция INNER JOIN позволяет выбирать данные, в которых
ключевые поля совпадают ( Исполнитель1.[Код исполнителя] = Связи.[Код
исполнителя]). Вторая конструкция
INNER JOIN позволяет выбирать
данные, в которых другие ключевые поля совпадают (Песня1.[Код песни] =
Связи.[Код песни]). Посредством конструкции “ORDER BY Песня1.Песня”
выполняется сортировка выводимых данных по полю “Песня” таблицы
”Песня1”.
Результат выполнения данного запроса представлен на рис. 4.6.16.
Рис. 4.6.16. Результат выполнения запроса, сформированного для
сборки данных из трех таблиц
Как видно из рисунка результат выполнения запроса полностью
совпадает с исходной таблицей.
При
таких
небольших
таблицах,
которые
приведены,
вполне
допустимы рассмотренные манипуляции. Однако, если исходная таблица
будет включать в себя реальное количество записей, подобная технология
избавления от многозначных зависимостей мало приемлема. В связи с
142
этим
нужны
дополнительные
автоматизированные
средства,
реализованные в соответствии с рассмотренными выше алгоритмами.
Упражнения и вопросы для самоконтроля
1. Сформулируйте проблемы нормализации заполненных
реляционных таблиц.
2. Каким образом можно представить модель реляционной таблицы?
3. Каким образом можно представить модель информации табличного
вида?
4. В чем сходство и различие между моделью реляционной таблицы и
моделью информации табличного вида?
5. Приведите примеры реальных таблиц с подзаголовками.
6. Приведите примеры реальных таблиц с заголовками в области
данных.
7. Опишите алгоритм избавления от сложных атрибутов.
8. Как реализовать данный алгоритм на основе визуального анализа
таблиц и существующих средств СУБД?
9. Опишите алгоритм избавления от заголовков внутри таблицы.
10. Как реализовать данный алгоритм на основе визуального анализа
таблиц и существующих средств СУБД?
11. Приведите примеры реальных таблиц с заголовками в первом
столбце.
12. Опишите алгоритм избавления от заголовков в первом столбце
таблиц.
13. Как реализовать данный алгоритм на основе визуального анализа
таблиц и существующих средств СУБД?
14. Приведите примеры реальных таблиц, которые не удовлетворяют
требованиям ко второй нормальной форме.
15. Опишите алгоритм выявления функциональной зависимости в
заполненных реляционных таблицах.
16. Опишите алгоритм исключения функциональной зависимости в
заполненных реляционных таблицах.
143
17. Как реализовать данный алгоритм на основе визуального анализа
таблиц и существующих средств СУБД?
18. Приведите примеры реальных таблиц, которые не удовлетворяют
требованиям к третьей нормальной форме.
19. Опишите алгоритм приведения заполненных реляционных таблиц к
третьей нормальной форме.
20. Как реализовать данный алгоритм на основе визуального анализа
таблиц и существующих средств СУБД?
21. Приведите примеры реальных таблиц, которые не удовлетворяют
требованиям к четвертой нормальной форме.
22. Опишите алгоритм приведения заполненных реляционных таблиц к
четвертой нормальной форме.
23. Как реализовать данный алгоритм на основе визуального анализа
таблиц и существующих средств СУБД?
144
5. НАЗНАЧЕНИЕ КЛЮЧЕВЫХ ПОЛЕЙ
5.1. Задача назначения ключевых полей в заполненных
реляционных таблицах
В работе [7] обоснована актуальность проблемы
преобразования
информации табличного вида в таблицы базы данных (БД), выполнена
неформальная постановка задачи такого преобразования. Основными
аспектами постановки задачи являются: формирование реляционных
таблиц на основе информации, представленной в табличной форме,
назначение ключевых полей в таблицах, формирование связей между
таблицами.
Каждый
аспект
задачи
нетривиален,
нуждается
в
формализованном подходе к его решению и зависит от множества
факторов.
Здесь
рассмотрена
одна
из
составляющих
задачи
преобразования – назначение ключевых полей.
В работах, посвященных теоретическим основам построения БД,
дается определение ключевых полей, обосновывается их необходимость,
формулируются
свойства
требования
внешних
реализуются
проектирования
на
БД
к
первичным
ключам
ключей.
Эти
этапах
инфологического
до
момента
требования
их
и
определяются
сравнительно
и
заполнения
легко
датологического
данными.
В
рассматриваемом же случае данные уже существуют сами по себе,
представляют ценность и должны быть наиболее эффективным образом
задействованы в БД. В связи с этим и возникает задача назначения
ключевых полей на основе анализа данных, представленных в таблицах.
Она распадается на две подзадачи – назначение первичных ключей и
назначение внешних ключей.
Полностью автоматизировать процесс назначения первичного ключа
невозможно, так как при анализе отношения на предмет выбора атрибута
или
совокупности
атрибутов,
удовлетворяющих
требованиям
предъявляемых к первичному ключу, необходимо учитывать не только
уникальность значений атрибута, но и семантику данных, что требует
вмешательства разработчика БД. В соответствии с [14] первичный ключ
должен удовлетворять требованиям уникальности и минимальности.
145
Уникальность ключевого поля обеспечивает уникальность записей
таблицы, что в свою очередь обеспечивает корректное удаление,
добавление и изменение записей в таблице. Минимальность ключевого
поля
обеспечивает
эффективное
использование
памяти
БД.
Эти
требования часто противоречат друг другу, так как сложный ключ (ключ,
состоящий
из
нескольких
полей)
с
большей
вероятностью
будет
уникальным, однако для него в БД будет отводиться больше памяти. В
связи с этим необходим разумный компромисс. Кроме того, выбор или
назначение
первичного
ключа
существенно
зависит
от
количества
столбцов в таблице. Так, например, в Oraclе для таблиц в один столбец
предусмотрена возможность не выделять дополнительной памяти под
ключевое поле.
В современных СУБД обеспечивается возможность использования до
1000 столбцов. Поэтому теоретически сложный ключ может состоять из
1000 полей, что, конечно, абсурдно. Кроме того, при выборе или
назначении ключевого поля необходимо учитывать типы и размеры полей.
В частности, поле типа MEMO нельзя использовать в качестве ключевого
поля.
Среди атрибутов необходимо искать атрибуты с уникальными
значениями или сочетания атрибутов, кортежи которых уникальны, но при
этом
количество атрибутов, входящих в состав составного первичного
ключа, не должно превышать разумного числа, например трех. Ввод
дополнительного атрибута типа “счетчик”, во-первых, не всегда возможен,
а во-вторых, не является наилучшим решением проблемы, так как в таком
случае
мы
можем
получить
абсолютно
одинаковые
кортежи,
различающиеся только значением ключа, а это ведет к избыточности
информации
в
БД.
Учитывая
сказанное,
предлагается
методика
назначения первичных ключей в таблицах, заполненных информацией.
5.2. Алгоритмы назначения ключевых полей в заполненных
реляционных таблицах
При разработке алгоритмов логично выделить 3 ситуации: таблица
состоит из одного поля; таблица состоит из нескольких полей, число
146
которых не равно максимально возможному количеству полей для
конкретной СУБД; таблица состоит из полей, число которых равно
максимально возможному количеству полей для конкретной СУБД.
Если таблица состоит из одного поля, то его естественно назначить в
качестве первичного ключа. Однако это решение, может быть, придется
пересмотреть в процессе формирования связей между таблицами. В
частности, если эта таблица с одним атрибутом справочного характера и
ее поля используются для выбора значения поля для другой таблицы, то
этот атрибут нельзя задействовать в качестве первичного ключа.
Множество атрибутов таблицы в случае одного поля вырождается в один
атрибут: А = {А1}. Множество значений по этому атрибуту: К1 = {К11, К12,…,
К1n} должно удовлетворять требованию уникальности, т.е. К1i  К1j; i = 1, n;
j = 1, n; i  j . Для обеспечения этого необходимо на основе отношения R1
степени 1 построить другое отношение R2 степени 1, мощность которого
будет меньшей или равной мощности отношения R1. В терминах SQL
необходимо выполнить следующий запрос на создание таблицы: SELECT
DISTINCT R1.A1 INTO R2 FROM R1;
Назначение поля ключом возможно только в том случае, если тип
атрибута А1 не является MEMO, OLE, LOB (в различных СУБД различные
типы). В противном случае необходимо сформировать новое отношение
R3 на основе отношения R1 с множеством атрибутов А = {А1, А2}. При этом
нужно сформировать n значений по атрибуту К2 = {К21, К22,…, К2 n}, причем
необходимо обеспечить условие К2i  К2j; i = 1, n; j = 1, n; i  j.
В физической реализации это сводится к назначению нового поля в
таблицу, все значения которого уникальны. Проще всего в данном случае
назначить
новому
полю
тип
–
“счетчик”.
Тогда
автоматически
сформируются уникальные значения этого поля для всех записей таблицы.
Следует иметь в виду, что не во всех СУБД реализована возможность
определения новых полей в заполненных таблицах, а тем более
назначения их ключевыми. Поэтому эти манипуляции надо выполнять в
СУБД, в которых они допустимы (например, в Microsoft Access), а затем
экспортировать преобразованные таблицы в целевую СУБД.
147
Если таблица включает в себя несколько полей, число которых не
равно максимально возможному числу для инструментальной СУБД, то
необходимо найти такое сочетание атрибутов, чтобы для всех записей
таблицы их значения были бы уникальны. Пусть отношение R1, на котором
построена таблица базируется на p – атрибутах А = {А1, А2, …, Аp}. Атрибут
Ai имеет в таблице множество значений Кi = {Кi1, Кi2, …, Кin}. Атрибут Aj
имеет в таблице множество значений Кj = {Кj1, Кj2, …, Кjm}. Так как таблица
имеет фиксированное количество записей, то n и m имеют конкретные
значения и в рассматриваемом случае n = m и равно числу записей
таблицы. Необходимо найти кортеж атрибутов КА = {КА1, КА2, …, КАr}, КА 
А такой, что все кортежи их значений были уникальны. В таком случае мы
имеем r-множество значений по числу атрибутов в кортеже КА, мощность
каждого множества n – по числу строк
КК1 = {КК11, КК12, …, КК1n},
…
ККi = {ККi1, ККi2, …, ККin},
…
ККr = {ККr1, ККr2, …, ККrn}.
Тогда должно быть выполнено условие (1):
{КК11, …, ККi1, …, ККr1}  …
{КК12, …, КKi2, …, ККr2} …
{КК1n, …, КKin, …, ККrn}.
Таким образом, необходимо выбрать кортеж атрибутов КА такой,
чтобы выполнялось условие (1), которое обеспечивает уникальность
сложного ключа. С другой стороны, важно обеспечить другое требование к
первичному ключу – минимальность. Для реализации этого требования
нужно стремиться к минимизации числа полей, входящих в первичный
ключ, т.е. к минимизации размера кортежа КА. Кроме того, необходимо
учитывать длину полей и в качестве претендентов на поля, включаемые в
первичный ключ, выбирать поля с минимальной длиной. Кроме того,
нельзя рассматривать в качестве претендентов поля, включаемые в
первичный ключ поля с определенными типами – MEMO, OLE ,LOB.
148
Основываясь на вышесказанном, можно неформально, а затем и
формально описать целевую функцию назначения первичного ключа. Суть
ее
состоит
в
том,
минимальности,
что
исключая
необходимо,
отталкиваясь
недопустимые
поля,
от
найти
требования
совокупность
атрибутов таблицы, суммарные значения которых бы не совпадали.
Формальное описание целевой функции несколько громоздко и здесь не
приводится. Методика назначения ключевого поля носит итерационный
характер – ищется самый оптимальный путь, затем ведется поиск
компромисса до тех пор, пока это возможно. Суть оптимального пути –
поиск допустимого атрибута с минимальной длиной, значения которого
уникальны. Суть компромисса сводится к тому, что ищется набор
допустимых атрибутов с минимальной общей длиной, суммарные значения
которых уникальны. При этом процесс поиска такого набора может
прекратиться не только по достижению уникальности их значений, но и в
том случае, когда из-за критического значения суммарной длины атрибутов
станет целесообразно введение дополнительного поля и назначение его
ключом.
Под критическим значением суммарной длины атрибутов понимается
такое значение, которое требует расхода памяти на формирование ключа,
превышающего расход памяти на введение дополнительного поля.
Поиск оптимального варианта состоит в следующем.
Перебираются все атрибуты Ai; i=1,r; A  Ai; ТАi  N, где ТА – тип
атрибута, N = {MEMO, OLE, LOB}.
Для каждого атрибута проверяется условие (1). В рассматриваемом
случае каждое множество вырождается в один элемент, и условие
выглядит следующим образом:
{KKi1}  {KKi2}  …  {KKin}.
Если условие выполняется, то запоминается имя атрибута и его
длина. По завершению перебора проверяется, есть ли атрибуты,
удовлетворяющие условию (1). Если таковые есть, то выбирается атрибут
с минимальной длиной, и он назначается в качестве ключевого атрибута.
Для
организации
такого
поиска
можно
использовать
относительно
несложную хранимую процедуру. Если условию (1) не удовлетворяет ни
149
один атрибут, осуществляется переход к поиску решения, при котором в
качестве ключа назначается несколько атрибутов.
Формализованная методика выбора ключевого поля в этом случае
выглядит следующим образом.
П1. Для множества LA = {LA1, … LAi, …,LAr} ищется min(LA), где LAi длина атрибута Ai (физически это выражается количеством байтов,
отводимым для значений Ai).
П2. Предположим min(LA) = LАk. Тогда выполняется анализ всех
возможных пар атрибутов Ak и Ai, i  k, i = 1, r, где r – число атрибутов
таблицы и проверяется условие (1), которое в этом случае будет
выглядеть следующим образом:
{KKk1, KKi1}  {KKk2, KKi2}  …  {KKkn, KKin}, где n – число строк
таблицы. Если данное условие выполняется, то запоминается атрибут A i и
его длина.
П3. После завершения перебора ищется min(LAN), где LAN – длины
найденных атрибутов. Предположим min(LAN) = LAq, тогда в качестве
первичного ключа назначается сложный ключ AkAq.
П4. Если условие (1) не выполняется ни для одной пары атрибутов A k
и Ai, то ищется min(LA-1), где LA-1 = {LA1, …, LAi, …LAr-1}, LA  LA-1k.
Предположим min(LA-1) = LAk1, тогда выполняется анализ всех возможных
пар атрибутов Ak1 и Ai i  k, i  k1, i = 1, r-1 и проверяется условие (1) по
аналогии с П2. Далее выполняются действия аналогичные действиям П3.
Если условие (1) не выполняется ни для одной пары атрибутов A k1 и Ai, то
ищется min(LA-2), где LA-2 = {LA1, …LAi, … LAp-2}, LAk  LA-2 , LAk1  LA-2
Итерации такого рода осуществляются до тех пор, пока не выполнится
условие (1) или не исчерпаются все атрибуты таблицы.
Если условие (1) так и не выполнилось, то это означает, что
первичный ключ на основе 2-х атрибутов назначить невозможно. В случае
наличия
в
таблице
всего
2-х
атрибутов
необходимо
ввести
дополнительное поле и назначить его ключевым полем.
Если в таблице более 2-х атрибутов и ключ из 2-х атрибутов
сформировать
введением
не
удалось,
необходимо
дополнительного
найти
компромисс
неинформативного
между
атрибута
и
150
неоправданным использованием памяти для сложного ключа из 3-х полей.
Для этого надо “измерить” суммарные длины всех возможных сочетаний
троек
атрибутов (в случае 3-х атрибутов будет одно сочетание). Если
минимальная суммарная длина сочетания превышает 4 байта, то
компромисс разрешается в пользу введения дополнительного поля и
назначения его ключевым полем. В противном случае имеет смысл
попытаться найти три атрибута для формирования сложного ключа.
Суммарная длина сравнивается с 4-мя байтами в связи с тем, что
поле типа “счетчик”, которое имеет смысл использовать в качестве
дополнительного, имеет длину 4 байта.
В формализованном виде методика поиска первичного ключа в этом
случае выглядит следующим образом.
П1. Ищется min(LA3); LA3 = {LA31, LA32, …LA3i, …LA3j, …LA3n};
LA3i = lenqth(Aqj) + lenqth (Apj) + lenqth (Atj),
qi = 1, n; pi = 1, n; ti = 1, n; qi  pi  ti ,
LA3j = lenqth(Aqj) + lenqth (Apj) + lenqth (Atj) ;
qj = 1, n; pj = 1, n; tj = 1, n; qj  pj  tj;
(qi  qj )  (pi  pj)  (ti  tj).
Если min(LA3)  4 байт, то поиск атрибутов, из которых можно
сформировать первичный ключ, прекращается, вводится дополнительный
атрибут и назначается ключевым атрибутом. В противном случае
выполняется переход к П2.
П2. Предположим, что min(LA3) = LA3k, тогда анализируется AK = {A qk,
Apk, Atk}; AAК.
Имеется три множества значений атрибутов:
KKqk = {KKqk1, …, KKqki, …, KKqkn},
KKpk = {KKpk1, …, KKpki, …, KKpkn},
KKtk = {KKtk1, …, KKtki, …, KKtkn}, где n – число записей таблицы.
Необходимо проверить условие:
{KKqk1, KKpk1,KKtk1}, …,{KKqki, KKpki, KKtki},…,{KKqkn, KKpkn,
KKtkn}. (2)
151
Если это условие выполняется, то тройка атрибутов АК принимается в
качестве сложного ключа. Процесс завершается. В противном случае
выполнятся переход к П3.
П3. Ищется min(LA3-1); LA3  LA3-1; LA3  LA3k.
Предположим, что min(LA3-1) = LA3k1. Если LA3k1  4 байт, то вводится
дополнительный атрибут и назначается ключевым атрибутом. Процесс
завершается. В противном случае анализируется тройка атрибутов АК1 по
аналогии с П2. Если условие (2) выполняется, то тройка атрибутов АК1
принимается в качестве сложного ключа и процесс завершается. В
противном случае ищется min(LA3-2); LA3  LA3-2; LA3  LA3k ; LA3  LA3k1
и выполняется анализ в соответствии с П3.
Как следует из последней рекомендации, процесс поиска описывается
рекурсивно, что позволяет сделать вывод о возможности использования
для реализации предложенной методики рекурсивных процедур.
Если в процессе поиска 3-х ключевых атрибутов с уникальными
значениями таковых не найдется, то распространять поиск на 4-е и более
атрибутов не имеет смысла. Исходя из опыта работы с СУБД, сделан
вывод, что использование 4-х и более полей для формирования сложного
ключа неоправданно. Это связано с тем, что в подавляющем большинстве
случаев их суммарная длина велика и, кроме того, более 4-х полей,
входящих в ключевое поле, плохо воспринимаются пользователями БД.
Это
экспериментально
доказано
при
выполнении
ряда
реальных
разработок. В этом случае вводится дополнительное поле и назначается
ключевым полем.
В третьей ситуации, когда таблица состоит из полей, число которых
равно максимально возможному количеству полей конкретной СУБД, поиск
атрибутов для формирования первичного ключа осуществляется в
соответствии с методикой, рассмотренной выше. Однако, когда возникает
необходимость введения нового поля и назначения его в качестве
ключевого, то это выполнить невозможно, так как будет превышено
допустимое число атрибутов. Такое случается редко. Если же это
произошло необходимо выявить атрибуты, у которых все значения пустые.
Как показывает опыт, такие атрибуты находятся - столбцы сформированы
152
на всякий случай. Затем нужно предложить потенциальному пользователю
БД выбрать из числа найденных атрибутов ненужный, переопределить его
тип и назначить ключевым. Если же пользователь БД настаивает на
необходимости всех атрибутов, то нужно проанализировать таблицу на
возможность нормализации (в некоторых СУБД, в частности в Microsoft
Access, это можно автоматизировать). Если нормализация возможна, то
таблица преобразуется в две и более таблиц, а их первичные и внешние
ключи назначаются, исходя из условий нормализации. Процесс же
назначения ключевых полей в данном случае в основном относится к
аспектам формирования реляционных таблиц на основе информации,
представленной в табличной форме и формированию связей между
таблицами. Если рассматриваемая таблица не нормализуется, то ее
можно разбить на две таблицы, затем в каждой таблице ввести
дополнительные поля, назначить их ключевыми полями и реализовать
связь один - к одному по этим полям.
Выполним назначения первичного ключа на основе средств СУБД
Microsoft Access. В качестве исходных данных возьмем реальную таблицу,
сформированную в формате Microsoft Excel и представленную на рис.
5.2.1.
Рис. 5.2.1. Исходная таблица, сформированная в формате Microsoft Excel
После импорта этой таблицы Microsoft Access с выполнением всех
необходимых манипуляций она примет вид рис 5.2.2.
153
Рис. 5.2.2. Таблица, импортированная в Microsoft Accesss
Прежде, чем выполнять манипуляции по назначению первичного
ключа, необходимо выяснить у разработчиков представленной таблицы
Microsoft
Excel,
предполагалось
ли
в
каком-либо
поле
таблицы
использование уникальных значений. Если такое поле предполагалось, то
необходимо построить запрос на выявление повторяющихся значений в
указанном столбце.
Затем, если обнаружится дублирование значений
полей, необходимо вместе с разработчиком сделать нужные исправления.
Если к разработчику таблицы нет доступа, то выявление ключевого
столбца придется осуществлять исходя из визуального анализа таблицы
или в соответствии с предложенным алгоритмом.
Так как таблица включает в себя чуть больше двухсот записей, то
можно
попытаться
визуально
определить
столбец
с
уникальными
значениями. Явными претендентами на такие столбцы являются первый и
второй столбцы, так как первые двадцать значений этих столбцов не
дублируются. В остальных столбцах, даже в начальных двадцати записях,
наблюдается дублирование значений. Для выявления дублирования
значений полей можно построить соответствующий запрос, а если записей
154
немного, проще всего отсортировать записи по нужному столбцу и оценить
дублирование визуально. На рис.
5.2.3. приведена часть значений 1-го
отсортированного столбца.
Рис. 5.2.3. Отсортированные значения 1-го столбца
Даже из анализа начальных значений столбца, становится очевидным
дублирование его значений. Таким образом, в качестве ключевого столбца
данный столбец использован быть не может.
Выполним
сортировку
значений
второго
столбца,
Несколько
отсортированных значений второго столбца представлено на рис. 5.2.4.
Рис. 5.2.4. Отсортированные значения 2-го столбца
155
Визуальный анализ первых значений
предположить,
что он может
данного столбца позволяет
претендовать на
ключевой
столбец.
Действительно, начальные значения не совпадают. После просмотра всех
значений данного столбца повторяющихся значения не обнаружено.
Поэтому можно открыть таблицу в режиме Конструктора и назначить
данное поле ключевым полем. Однако при попытке выхода из режима
Конструктора система выдает сообщение, представленное на рис 5.2.5.
Рис. 5.2.5. Сообщение системы при попытке выхода из режима
Конструктора
Данное сообщение свидетельствует о том, что все-таки визуально не
удалось выявить повторяющиеся значения второго столбца.
В связи с этим следует выполнить запрос вида:
SELECT Заказы.[№ п/п], Заказы.Дата
FROM Заказы
WHERE Заказы.[№ п/п] In (SELECT [№ п/п] FROM [Заказы] GROUP BY
[№ п/п] HAVING Count(*)>1 );
С помощью конструкций “SELECT Заказы.[№ п/п], Заказы.Дата FROM
Заказы” выводятся поля “Заказы.[№ п/п]” и
“Заказы.Дата” из таблицы
“Заказы”, которые удовлетворяют условию, указанному в конструкции
WHERE
156
В этом запросе вся сложность в конструкции WHERE. Здесь
выбираются только те записи, для которых выполняется сложное условие,
включающее в себя конструкцию
“SELECT”.
Конструкция “SELECT”
выбирает поле [№ п/п] из таблицы “Заказы”, которая посредством
конструкции ”GROUP BY [№ п/п]” сгруппирована по этому полю. Причем
выбираются только те поля, у которых количество повторений больше
единицы.
Отбор
осуществляется
посредством
условия
”HAVING
Count(*)>1”.
Таким образом, выводятся только те значения поля “Заказы.[№ п/п]”,
которые входят в результат выполнения внутренней команды “SELECT”.
Оператор вхождения - ”In”.
Следует отметить, что в рамках системы Microsoft Access имеется
специальный
Мастер
для
проектирования
запросов
на
просмотр
повторяющихся записей. Однако запрос, построенный с помощью мастера,
в виде соответствующей SQL-команды выглядит несколько сложнее.
Результат выполнения данного запроса приведен на рис. 5.2.6.
Рис. 5.2.6. Результат выполнения запроса на просмотр
повторяющихся значений поля
К сожалению, данное поле тоже не подходит на роль ключевого поля.
Поэтому, если действовать формально и в соответствии с предложенным
выше алгоритмом, необходимо попытаться сформировать первичный ключ
из двух полей. И действительно,
если выполнить запрос на проверку
повторения значений двух первых полей, то в результате получится пустой
список записей, приведенный на рис. 5.2.7.
157
Рис. 5.2.7. Пустой список записей
Соответствующий запрос выглядит следующим образом:
SELECT Заказы.Дата, Заказы.[№ п/п], Заказы.Продавец
FROM Заказы
WHERE Заказы.Дата In (SELECT [Дата] FROM [Заказы] GROUP BY
[Дата],[№ п/п] HAVING Count(*)>1 And [№ п/п] = [Заказы].[№ п/п]);
После открытия таблицы в режиме Конструктора и назначения двух
первых полей в состав ключа, ошибки не произойдет.
Однако в данном случае, вероятнее всего мы имеем дело с ошибками
ввода значений. Действительно, трудно предположить, что из двухсот
значений только два из них совпадают. Поэтому в данном конкретном
случае имеет смысл изменить повторяющиеся значения, пометив их
характерным символом, например символом “#”. А затем предоставить
Заказчику возможность ввести правильные значения. Само же поле после
этого использовать в качестве ключевого. Изменение такого рода
приведено на рис. 5.2.8.
Рис. 5.2.8. Измененное значение поля претендента на ключевое поле
Таким
образом,
для
небольших
таблиц
вполне
оправданно
задействовать творческое начало разработчика БД и принять решение о
назначении ключевых полей на основе использования стандартных
средств СУБД и визуального анализа таблиц.
158
Упражнения и вопросы для самоконтроля
1. Сформулируйте задачу назначения ключевых полей в заполненных
реляционных таблицах.
2. Опишите алгоритм назначения ключевых полей в заполненных
реляционных таблицах.
3. Как реализовать данный алгоритм на основе визуального анализа
таблиц и существующих средств СУБД?
159
6. ВЫЯВЛЕНИЕ И ФОРМИРОВАНИЕ СВЯЗЕЙ
МЕЖДУ ЗАПОЛНЕННЫМИ ТАБЛИЦАМИ
6.1. Выявление и формирование связей один - к одному
Каждая таблица может быть связана с несколькими другими
таблицами. Причем эти связи могут быть различных типов. Но каждая
связь объединяет две таблицы, поэтому оправданно для разработки
алгоритмов выявления
связей между таблицами использовать два
отношения. В связи с этим рассматриваются два отношения R1 и R2.
R1 = (A1, …, Ai, …, An)
R2 = (B1, …, Bj, …, B k),
где A1, …, Ai, …, An - множество атрибутов R1;
B1, …, Bj, …, B k - множество атрибутов R2;
В общем виде отношения R1 и R2 представлены в табл. 6.1.1 и табл. 6.1.2.
Т а б л и ц а 6.1.1
Т а б л и ц а 6.1.2
A1
A2
…
An
B1
B2
…
Bk
a11
a12
…
a1n
b11
b12
…
b1k
a21
a22
…
a2n
b21
b22
…
b2k
…
…
…
…
…
…
…
am1
am2
…
amn
bq1
…
bqk
bq2
A1 – атрибут с первичными ключами отношения R1.
B1 – атрибут с первичными ключами отношения R2.
Z (A i) = (a1i, … , a2i, … , ami ) – множество значений атрибута Аi;
Z (Bj) = (b1j, … , b2j, … , bqj) – множество значений атрибута Bj;
Неформально условие наличия между двумя отношениями связи
один - к одному звучит следующим образом. Если найдется такой атрибут
160
в первом отношении и такой атрибут во втором отношении, что все их
значения будут равны между собой, то между двумя отношениями имеется
связь один - к одному.
Формализованное условие наличия связи один - к одному выглядит
следующим образом.
Пусть m ≥ q и для каждого bpj найдется такое ari, причем только одно,
что bpj = ari;
p = 1,q; j = 1,k;
r = 1,m; i = 1,n.
Тогда между отношениями А и В имеется связь 1:1.
И наоборот.
Пусть q ≥ m и для каждого ari найдется такое bpj, причем только одно,
что ari = bpj;
p = 1,q; j = 1,k;
r = 1,m; i = 1,n;
Тогда между отношениями А и В имеется связь 1:1.
Формальные условия наличия связи один - к одному выглядят
следующим образом.
( bpj) (Z (Bj)  bpj) (Eari) (Z (Ai)  ari) (bpj = ari)  ( Eati)(Z(Ai)  ati) (bpj = ati),
p = 1,q; j = 1,k;
r = 1,m; i = 1,n;
t = 1,m;
q ≥ m.
(ari) (Z (Ai)  ari) (Ebpj) (Z (Bj)  bpj) (ari = bpj)  ( Ebtj )(Z(Bj)  btj) (ari = btj),
p = 1,q; j = 1,k;
r = 1,m; i = 1,n;
t = 1,q;
m ≥ q.
Другими словами для каждого значения ключевого атрибута одного
отношения найдется равное ему одно и только одно значение ключевого
атрибута другого отношения.
161
На основе формальных условий наличия связи один - к одному между
двумя отношениями предлагается алгоритм выявления связей такого рода,
который представлен ниже.
CNT = 0
IF q >= m THEN
GOTO П1
ELSE
GOTO П2
END IF
П1: FOR j = 1 TO k
FOR p = 1 TO q
CNT = 0
FOR i = 1 TO n
FOR r = 1 TO m
IF bpj = ari THEN
CNT = CNT + 1
JZ = j
IZ = i
END IF
FOR i1 = i + 1 TO n
IF bpj = ari1 THEN GOTO П4
NEXT i1
NEXT r
NEXT i
NEXT p
NEXT j
IF CNT = q THEN
GOTO П3
ELSE
GOTO П4
END IF
162
П2: FOR i = 1 TO n
FOR r = 1 TO m
CNT = 0
FOR j = 1 TO k
FOR p = 1 TO q
IF ari = bpj THEN
СNT = СNT +1
JZ = j
IZ = i
END IF
FOR j1 = j + 1 TO n
IF ari = bpj1 THEN GOTO П4
NEXT i1
NEXT p
NEXT j
NEXT r
NEXT i
IF CNT = m THEN
GOTO П3
ELSE
GOTO П4
END IF
П3: PRINT (' Обнаружены связи 1:1, столбцы ',IZ,JZ)
EXIT
П4: PRINT (' Cвязей 1:1 не обнаружено ')
Поясним работу алгоритма.
В П1 перебираются все столбцы и строки отношения “А”, а также все
столбцы и строки отношения “В”. Перед выбором очередного столбца для
подсчета совпадений значений атрибутов в очередных столбцах счетчик
совпадений обнуляется. Если обнаружено совпадение значений атрибутов,
то счетчик совпадений увеличивается на 1, и запоминаются позиции
соответствующих столбцов. Кроме того, проверяются оставшиеся строки
163
отношения ”А”. Если обнаружилось повторное совпадение, то связи один к одному нет. П2 аналогичен П1. Только отношения меняются местами.
Несмотря
на
сходство
выше
представленного
алгоритма
с
программой, программой он не является, так как не отражен механизм
работы с реляционными таблицами,
который существенно зависит от
инструментальных средств.
При маловероятном стечении обстоятельств, программные средства,
реализованные в соответствии с предложенным алгоритмом, могут
привести к ошибочной идентификации связи один - к одному. Разработчик
БД легко может выявить ошибку такого рода, визуально оценив несколько
значений пар предложенных атрибутов. В связи с этим в выявлении связей
между отношениями должен участвовать разработчик БД. Поэтому данный
алгоритм человеко-машинный.
В качестве иллюстрации таблиц со связями 1:1 сформированы табл.
6.1.3 и 6.1.4.
Т а б л и ц а 6.1.3
№ путевки
Санаторий
Тип номера
М192
Сокол
Люкс
А282
Авангард
Двухместный
С508
Дружба
Одноместный
Т а б л и ц а 6.1.4
№ путевки
Ф.И.О.
Год рождения
С508
Иванов
1938
М192
Петров
1950
Для представленных данных связь очевидна, но в реальных случаях
таблицы могут включать в себя тысячи записей, и их визуальный анализ
практически невозможен.
Выполним анализ, каким образом можно выявить связь один - к
одному посредством стандартных средств СУБД.
164
На рис. 6.1.1 приведена таблица “Санатории” в режиме Просмотра.
Рис. 6.1.1. Таблица “Санатории” в режиме Просмотра
На рис. 6.1.2 приведена таблица “Отдыхающие” в режиме Просмотра.
Рис. 6.1.2. Таблица “Отдыхающие” в режиме Просмотра
В данном случае нетрудно предположить, что таблицы связаны
между собой посредством полей ”№ путевки” связью один - к одному.
Действительно, имена полей совпадают, значения полей
совпадают. К
сожалению, это не всегда очевидно. Поэтому нужна проверка данного
предположения.
Для этого на схеме данных организуем связь этих таблиц по полю ”№
путевки”. Такого рода связь представлена с помощью схемы данных на
рис. 6.1.3.
Рис. 6.1.3. Связь между двумя таблицами
Для проверки того, что предположения о связи верно, оправданно
использование запросов, построенных на базе рассматриваемых таблиц.
Исходный бланк такого запроса представлен на рис. 6.1.4.
165
Рис. 6.1.4. Бланк запроса, построенного на базе двух таблиц
Для того чтобы убедиться, что таблицы действительно связаны между
собой посредством связи один - к одному необходимо просмотреть все
записи одной таблицы и связанные с ними записи другой таблицы и
наоборот. Если в первом случае будут представлены все записи первой
таблицы, а во втором случае будут представлены все записи второй
таблицы, то имеет место связь один - к одному.
Для вывода данных описанным образом необходимо использовать
параметры объединения таблиц. Чтобы выбрать нужный тип объединения
таблиц, нужно дважды щелкнуть по связи, после чего откроется форма,
приведенная на рис. 6.1.5.
Рис. 6.1.5. Форма с параметрами объединения
166
Если
использовать
объединения)
и
второй
выполнить
параметр
запрос,
объединения
сформируется
(левого
результат,
представленный на рис 6.1.6.
Рис 6.1.6. Результат левого объединения таблиц
Если
использовать
объединения)
и
третий
выполнить
параметр
запрос,
объединения
сформируется
(правого
результат,
представленный на рис 6.1.7.
Рис 6.1.7. Результат правого объединения таблиц
Из результатов выполнения запроса видно, что число выведенных
записей совпадает с числом записей таблицы “Отдыхающие”.
Результаты,
представленные
на
рис.
6.1.6
и
рис.
6.1.7
свидетельствуют о том, что действительно имеет место связь между
таблицами типа один - к одному.
В некоторых СУБД отсутствует возможность формирования запроса
по образцу, как в Microsoft Access. В этом случае можно воспользоваться
следующей SQL-командой:
SELECT
Санатории.[№
путевки],
Санатории.Санаторий,
Санатории.[Тип номера], Отдыхающие.[№ путевки], Отдыхающие.[Ф И О],
Отдыхающие.[Год рождения]
FROM Санатории RIGHT JOIN Отдыхающие ON Санатории.[№
путевки] = Отдыхающие.[№ путевки];
167
В
данном
(конструкция
случае
“RIGHT
представлено
JOIN”).
правое
Результат
объединение
выполнения
этого
таблиц
запроса
представлен на предыдущем рисунке (рис 6.1.7). В правом объединении
таблиц вместо конструкции “RIGHT JOIN” используется конструкция “LEFT
JOIN”.
Следует обратить внимание, что в различных СУБД используются
различные нотации языка SQL, но в большинстве случаев принципиальных
различий нет.
6.2. Выявление и формирование связей один - ко многим
Связи один - ко многим между двумя отношениями имеют место тогда,
когда значения ключевых атрибутов одного отношения совпадают со
значениями неключевых атрибутов другого отношения.
Выявленные и сформированные связи между таблицами типа один ко
многим
существенно
помогают
пользователям
БД
в
ходе
ее
эксплуатации. Эти связи позволяют обеспечить ссылочную целостность
данных при осуществлении автоматической
сформированной
пользователем
ссылки
проверке правильности
на
значение
данного,
находящегося в отдельной таблице. Правильно реализованная связь типа
один - ко многим обеспечивает простую реализацию каскадного удаления
данных, когда при удалении значения поля автоматически удаляются все
записи, которые ссылаются на это значение. Правильно реализованная
связь один - ко многим обеспечивает простую реализацию каскадного
обновления данных, когда при изменении значения поля, на которое
имеются ссылки, обеспечивается сохранение связи с этим полем.
В качестве примера рассмотрим отношение ”A” (табл. 6.2.1) и
отношение ”B” (табл. 6.2.2).
Т а б л и ц а 6.2.1
168
Категория продукта
Поставщик
Птица
Тульская птицефабрика
Рыба
Мурманск
Молочные
Росмолоко
Бакалея
Шебекино
Т а б л и ц а 6.2.2
Товар
Категория
Цена
Срок
годности
Куры
птица
110
90
Индюки
птица
150
90
Семга
рыба
360
60
Окунь
рыба
120
60
Молоко
молочные
25
30
Ряженка
молочные
23
30
Кефир
молочные
23
30
Если принять то, что в отношении ”A” атрибут ”Категория продукта”
является ключевым, то данное отношение связано с отношением ”B”
связями один - ко многим. Действительно, в отношении
”B” имеется
неключевой атрибут ”Категория”, значения которого повторяют значения
атрибута ”Категория продукта”.
A1 – атрибут с первичными ключами отношения А.
Bj – неключевой атрибут отношения В.
Z (A i) = (a1i, … , a2i, … , ami ) – множество значений атрибута А;
Z (Bj) = (b1j, … , b2j, … , bqj) – множество значений атрибута B;
Неформально условие наличия между двумя отношениями связи
один – ко многим звучит следующим образом. Если найдется такой
ключевой атрибут в первом отношении и такой неключевой атрибут во
втором отношении, что каждому значению неключевого атрибута второго
отношения найдется равное ему значение ключевого атрибута первого
отношения, то между двумя отношениями имеется связь один - ко многим.
169
Формализованное условие наличия связи один – ко многим выглядит
следующим образом.
Пусть q ≥ m и для каждого bpj найдется такое ari такое, что bpj = ari;
p = 1,q; j = 1,k;
r = 1,m; i = 1,n.
Тогда между отношениями А и В имеется связь 1 : .
И наоборот.
Пусть m ≥ q и для каждого ari найдется такое bpj такое, что ari = bpj;
p = 1,q; j = 1,k;
r = 1,m; i = 1,n;
Тогда между отношениями А и В имеется связь 1 : .
Формальные условия наличия связи один - ко многим выглядят
следующим образом.
( bpj) (Z (Bj)  bpj) (ari) (Z (Ai)  ari) (bpj = ari),
p = 1,q; j = 1,k;
r = 1,m; i = 1,n;
q ≥ m.
Ai – ключевой атрибут.
(ari) (Z (Ai)  ari) (bpj) (Z (Bj)  bpj) (ari = bpj),
p = 1,q; j = 1,k;
r = 1,m; i = 1,n;
m ≥ q.
Bj – ключевой атрибут.
На основе формальных условий наличия связи один - ко многим
между двумя отношениями предлагается алгоритм выявления связей
такого рода, который представлен ниже.
CNT = 0
IF q >= m THEN
GOTO П1
ELSE
170
GOTO П2
END IF
П1: FOR j = 1 TO k
FOR p = 1 TO q
CNT = 0
FOR i = 1 TO n
FOR r = 1 TO m
IF bpj = ari THEN
CNT = CNT + 1
JZ = j
IZ = i
END IF
NEXT r
NEXT i
NEXT p
NEXT j
IF CNT = q THEN
GOTO П3
ELSE
GOTO П4
END IF
П2: FOR i = 1 TO n
FOR r = 1 TO m
CNT = 0
FOR j = 1 TO k
FOR p = 1 TO q
IF ari = bpj THEN
СNT = СNT +1
JZ = j
IZ = i
END IF
NEXT p
NEXT j
NEXT r
171
NEXT i
IF CNT =m THEN
GOTO П3
ELSE
GOTO П4
END IF
П3: PRINT (' Обнаружены связи 1 : , столбцы ',IZ,JZ)
EXIT
П4: PRINT (' Cвязей 1 :  не обнаружено ')
Поясним работу алгоритма.
В П1 перебираются все столбцы и строки отношения “А”, а также все
столбцы и строки отношения “В”. Перед выбором очередного столбца для
подсчета совпадений значений атрибутов в очередных столбцах счетчик
совпадений обнуляется. Если обнаружено совпадение значений атрибутов,
то счетчик совпадений увеличивается на 1, и запоминаются позиции
соответствующих столбцов. По сути, алгоритм очень похож на алгоритм,
изложенный в предыдущем параграфе. В этом алгоритме, в отличие от
предыдущего, в случае совпадения значений атрибутов не проверяется
наличие повторных совпадений. В данном случае повторные совпадения
не только допускаются, но и даже ожидаются. Ведь основной смысл связи
один - ко многим - это совпадения одного значения атрибута в первом
отношении со многими значениями атрибута во втором отношении.
Несмотря на подобие выше представленного алгоритма программе,
программой это не является, так как не отражен механизм работы с
реляционными таблицами,
который
существенно зависит от
инструментальных средств.
При маловероятном стечении обстоятельств, программные средства,
реализованные в соответствии с предложенным алгоритмом, могут
привести к ошибочной идентификации связи один - ко многим. Разработчик
БД легко может выявить ошибку такого рода, визуально оценив несколько
значений пары предложенных атрибутов. В связи с этим в выявлении
связей между отношениями должен участвовать разработчик БД. Поэтому
данный алгоритм человеко-машинный.
172
Рассмотрим, что можно сделать по поводу выявления связей типа
один - ко многим с помощью стандартных средств СУБД.
На рис. 6.2.1 представлена
формате
СУБД
Microsoft
таблица ”Категории продуктов” в
Access,
которая
может
претендовать
на
расположение в связи один - ко многим со стороны ”один”.
Рис. 6.2.1. Таблица, которая может претендовать на расположение в
связи один - ко многим со стороны ”один”
На рис. 6.2.2 представлена
таблица ”Товары” в формате СУБД
Microsoft Access, которая может претендовать на расположение в связи
один - ко многим со стороны ”многие”.
Рис. 6.2.2. Таблица, которая может претендовать на расположение в
связи один - ко многим со стороны ”многие”
Действительно,
визуального
анализа
содержимого
приведенных
таблиц достаточно для того, чтобы предположить, что таблицы ”Категории
продуктов” и ”Товары” связаны между собой связью типа один - ко многим.
В пользу этого говорит то, что значение поля ”Категория продукта” в
таблице ”Категории продуктов” уникальны. Кроме того, для всех значений
поля ”Категория” в таблице ”Товары” находятся соответствующие значения
полей ”Категория продукта” в таблице ”Категории продуктов”.
173
Но простого визуального анализа реальных таблиц чаще всего
недостаточно для принятия решения о необходимости формирования
связей
между
ними.
В
связи
с
этим
выполним
необходимую
последовательность действий.
В первую очередь необходимо выявить в обеих таблицах поляпретенденты для организации связей.
В данном случае в качестве возможного претендента на связь со
стороны ”один” следует проверить поле ”Категория продукта” в таблице
”Категории продуктов”. Если это поле является ключевым, то этого
достаточно для того, чтобы использовать его на роль претендента. Если
это поле неключевое, то необходимо проверить уникальность его значений
и, если его значения уникальны, назначить это поле ключевым полем. В
рамках многих СУБД проще всего попытаться назначить поле ключевым, и,
если средства СУБД не выдадут сообщения об ошибке, то дублирования
значений поля не обнаружено. Так и оказалось в рассматриваемом случае
– поле ”Категория продукта” в таблице ”Категории продуктов” успешно
назначено ключевым (см. рис. 6.2.3).
Рис. 6.2.3. Назначения ключа
Таблица ”Категории продуктов” открыта в режиме Конструктора,
выделено поле ”Категория продукта”, выполнен щелчок по значку ”ключ”,
закрыта форма Конструктора. После закрытия формы Конструктора СУБД
сообщений об ошибках не выдала. Если бы сообщение об ошибке
сформировалось, то это свидетельствовало бы о том, что данное поле
нельзя использовать в качестве ключевого поля. Дальнейшие действия
разработчика зависят от того, подозревает ли он, что в таблице введено
ошибочное
значение
поля.
соответствующего запроса
Если
это
так,
то
надо
с
помощью
просмотреть повторяющиеся поля, а затем
путем редактирования значений поля исключить дублирования и назначить
данное поле ключевым. Если это не так, то данное поле
в качестве
174
возможного претендента на связь со стороны ”один” использовано быть не
может.
Далее в рассматриваемом случае в качестве возможного претендента
на связь со стороны ”многие” следует проверить поле ”Категория ” в
таблице ”Товары”. Во-первых, данное поле не должно быть первичным
ключом в таблице ”Товары”, а во - вторых, все значения этого поля должны
присутствовать в столбце ”Категория продукта” в таблице ”Категории
продуктов”. Для проверки этого требования можно построить SQL запрос
следующего вида:
[Категории
SELECT
продуктов].[Категория
продукта],
Товары.Категория
FROM [Категории продуктов] INNER JOIN Товары ON [Категории
продуктов].[Категория продукта] = Товары.Категория;
В
данном
запросе
используется,
так
называемое,
внутреннее
объединение (INNER JOIN). Эта объединение позволяет выводить только
те данные из двух таблиц, в которых связанные поля совпадают.
Связанные поля в данном случае - поля [Категории продуктов].[Категория
продукта] и Товары.. Следует обратить внимание на то, что в квадратные
скобки заключаются имена, содержащие пробел, квалифицированное имя
поля - состоит из имени таблицы и имени поля.
Если в результате выполнения данного запроса сформируется
столько же записей, сколько их имеется в таблице
”Товары”, то это
свидетельствует о том, что для каждого поля “Категория” таблицы
“Товары” нашлось соответствующее поле ”Категория продукта” в таблице
”Категории продуктов”. А это в свою очередь, означает, что поле
“Категория”
таблицы
“Товары”
вполне
пригодно
в
качестве
поля,
используемого для связи со стороны ”многие”. Поле такого типа называют
внешним ключом.
Результат выполнения запроса приведен на рис. 6.2.4.
175
Рис. 6.2.4. Результат выполнения запроса
Из результатов выполнения запросов видно, что выведено 7 записей,
а в таблице ”Товары” также 7 записей. Таким образом, поле “Категория”
таблицы “Товары” можно использовать в качестве внешнего ключа.
На рис. 6.2.5 представлена схема данных с назначенной связью один ко многим.
Рис. 6.2.5. Схема данных со связью один - ко многим
Следует отметить, что связь представленного вида обеспечивает
целостность данных, каскадное обновление связанных полей и каскадное
удаление связанных полей. В этом можно легко убедиться, если в таблицу
”Товары” попытаться ввести несуществующую категорию. На рис. 6.2.6
приведена реакция системы на попытку ввода в таблицу ”Товары”
категории ”мясо”, которая не определена в таблице ”Категории товаров”.
176
Рис. 6.2.6. Реакция системы на попытку ввода несуществующей
категории
Таким образом, для таблиц с незначительным числом полей и
записей вполне оправданно выявление и назначение связей на основе
анализа их содержимого и использования стандартных средств СУБД.
6.3. Выявление и формирование связей многие - ко многим.
Рассмотрим пример отношений ”Авторы” (А) и ”Книги” (В), которые
приведены соответственно в табл. 6.3.1 и в табл. 6.3.2.
Т а б л и ц а 6.3.1
NA
Фамилия
Публикации Город
1
Иванов
Книга 1
Балашиха
2
Иванов
Книга 2
Балашиха
3
Иванов
Книга 3
Балашиха
4
Петров
Книга 1
Ногинск
5
Петров
Книга 3
Ногинск
6
Сидоров
Книга 2
Козельск
7
Сидоров
Книга 3
Козельск
Т а б л и ц а 6.3.2
177
NK
Книга
Автор
Издательство Тираж
1
Книга 1
Иванов
Эльдорадо
10000
2
Книга 1
Петров
Эльдорадо
10000
3
Книга 2
Иванов
Континент
7000
4
Книга 2
Сидоров Континент
7000
5
Книга 3
Иванов
Пламя
15000
6
Книга 3
Петров
Пламя
15000
7
Книга 3
Сидоров Пламя
15000
Нетрудно заметить, что соавтором Иванова, который написал Книгу1,
является Петров; соавтором Сидорова, который написал Книгу2, является
Иванов; соавторами Петрова, который написал Книгу3, являются Иванов
и Сидоров.
В связи с этим и в отношении А,
и в отношении В для
отражения этого факта потребовалось по 7 записей. В обоих отношениях
могут быть задействовано множество столбцов (атрибутов) и значительное
число строк (записей), а для их хранения требуются
соответствующие
объемы памяти.
Представленную ситуацию можно существенно улучшить, если
отдельно хранить в одной таблице только необходимые данные об
авторах (без дублирования фамилий), в другой таблице хранить только
необходимые данные о книгах (без дублирования названий). А для
отражения
фактов
авторства
ввести
третью
таблицу,
в
которой
представить номера авторов и соответствующие номера книг, которые они
написали.
Табл. 6.3.1 после указанных преобразований примет вид таблицы
6.3.3.
Т а б л и ц а 6.3.3
NA
Ф.И.О.
Город
1
Иванов
Балашиха
2
Петров
Ногинск
2
Сидоров
Козельск
178
Табл. 6.3.2 после указанных преобразований примет вид таблицы
6.3.4.
Таблица 6.3.4.
NK
Книга
Издательство Тираж
1
Книга 1
Эльдорадо
10000
2
Книга 2
Континент
7000
3
Книга 3
Пламя
15000
Третья
таблица,
в
которой
представлены
номера
авторов
и
соответствующие номера книг, которые они написали, примет вид табл.
6.3.5.
Т а б л и ц а 6.3.5
NA
NK
1
1
1
2
1
3
2
1
2
3
3
2
3
3
Посредством этой третьей таблицы и организуются связи “ :”
между таблицы с авторами и таблицы с книгами.
Выгода такого преобразования заполненных таблиц очевидна даже
для приведенного небольшого примера. Она будет значительно больше,
если для проектирования БД используются реальные таблицы. В связи с
этим
представляет
теоретический
и
практический
интерес
метод
выявления и формирования связей “ : ” между заполненными
реляционными таблицами, о котором пойдет речь далее.
Из приведенного примера видно, что табл. 6.3.1 и 6.3.2 Z(Фамилии) =
Z(Автор),
Z(Публикации) = Z(Книги), где Z(A) – значения атрибута ”А”.
179
Таким образом, для выявления множественных зависимостей необходимо
сравнить во всех парах таблиц
множества значений неключевых
атрибутов. Если для каких – либо двух таблиц найдется пара одинаковых
множеств, то это означает, что между таблицами существует многозначная
зависимость и ее нужно устранить.
Пусть Ai - неключевой атрибут отношения
R1;
Am - другой неключевой атрибут отношения
Bj - неключевой атрибут отношения
R2;
Bs - другой неключевой атрибут отношения
Тогда
между
отношениями
R1
и
R1;
R2
R2;
имеется
множественная
зависимость, если выполняется следующее условие:
(E Ai) ( R1Ai ) (Am) (R1  Am) ( Bj) (R2 Bj ) ( Bs) ( R2  Bs )
(Z(Ait) = Z (Bjp)) (Z(Amt) = Z (Bsp)) , где
i = 1, n -1; m = 1,n-1; j = 1, k-1; s = 1, k-1.
Здесь n - степень отношения R1;
k - степень отношения R2;
t – номер записи в отношении R1;
p – номер записи в отношении R2;
R1 = (A1, …, Ai, …, An);
R2 = (B1, …, Bj, …, Bk).
Следует обратить внимание, что i = 1, n -1; m = 1,n-1; j = 1, k-1; s =
1, k-1 в связи с тем, что ключевые атрибуты не рассматриваются (в каждом
отношении предполагается, что для формирования первичного ключа
используется по одному атрибуту).
Алгоритм
выявления
множественных
зависимостей
между
отношениями R1 и R2.
FOR i = 1 то n
FOR t = 1 то tm
FOR j = 1 то k
FOR p = 1 то pm
IF ((Z(Ait) = Z (Bjp))
and (i <> ik) and (j <> jk) THEN
ia1 = i
180
is = t
ja1 = j
js = p
END IF
NEXT p
NEXT j
NEXT t
NEXT i
FOR i = 1 то n
FOR t = 1 то tm
FOR j = 1 то k
FOR p = 1 то pm
IF ((Z(Ait) = Z (Bjp))
and (i <> ik) and (j <> jk) and
(i <> ia1) and (j <> ja1) and (t = is) and (p = js)
THEN
ia2 = i
ja2 = j
PRINT (“Возможны множественные связи !”)
PRINT (“Атрибут R1”, i)
PRINT (“Атрибут R2”, j)
PRINT (“Значение атрибута R1”, Z(Ait)j )
PRINT (“Значение атрибута R2”, Z (Bjp) )
PRINT (“Связь по атрибуту R1”, ia1, ia2)
PRINT (“Связь по атрибуту R2”, ja1, ja2)
PRINT (“Запись в R1”, is)
PRINT (“Запись в R2”, js)
END IF
NEXT p
NEXT j
NEXT t
NEXT i
Здесь tm – мощность множества R1;
pm – мощность множества R2;
181
ik – столбец отношения R1, в котором расположен ключевой атрибут;
jk – столбец отношения R2, в котором расположен ключевой атрибут;
Остальные обозначения прокомментированы в операторах PRINT.
Поясним работу алгоритма.
В первом фрагменте алгоритма перебираются все столбцы и строки
отношения R1, а также все столбцы и строки отношения R2. Если
обнаружено совпадение значений атрибутов и они - неключевые, то
запоминаются номера атрибутов и номера записей в обоих отношениях. Во
втором фрагменте алгоритма также перебираются все столбцы и строки
отношения R1, а также все столбцы и строки отношения R2. Если
обнаружено совпадение значений атрибутов и они неключевые и не те,
которые уже обнаружены, и они находятся в тех же строках отношений, в
которых уже обнаружены одинаковые значения атрибутов, то, вероятно,
обнаружились множественные связи. В этом случае запоминаются номера
атрибутов обеих отношений, значения которых совпадают. Номера двух
пар атрибутов отношений R1 и R2 ”подозрительных” на множественные
связи выводятся на печать. Кроме того, на печать выводятся строки
отношений R1 и R2, в которых найдены ”подозрительные” значения.
В связи с тем, что рассмотренный алгоритм не дает гарантии того, что
с помощью его выявятся множественные зависимости, то разработчику БД
необходимо визуально оценить предложенные атрибуты и принять
решение о необходимости выполнения следующих шагов алгоритма.
Избавление от лишних атрибутов.
Если наличие множественных связей подтвердилось, то необходимо в
отношении R1 избавиться от атрибута Aia2 , а в отношении R2 избавиться
от атрибута Bja1 .
Для этого формируется новое отношение
R1' = R1 – R (Aia2) –
R(A
ik).
Кроме того, формируется также отношение R2’ = R2 – R (Bja1) –
R
(A jk).
Другими словами, в R2 остается атрибут Aia1 – характерный для R1 и
удаляется атрибут A ia2 – характерный для R2.
182
И, наоборот, в отношении R2 остается атрибут Bja2 – характерный для
R2 и удаляется Bja1 – характерный для R2.
Под
характерными
атрибутами
подразумеваются
атрибуты,
посредством которых ликвидируются множественные связи. В частности
для отношения ”Авторы” таким атрибутом является ”Фамилия”, а для
отношения ”Книги” таким атрибутом является ”Наименование”.
R(A ik) и R (A jk) – столбцы с ключевыми атрибутами.
Результаты
преобразования
такого
рода
проиллюстрированы
соответственно в табл. 6.3.3 и 6.3.4. В таблицах присутствует ключевой
атрибут, но этот атрибут является результатом выполнения следующего
шага алгоритма.
При выполнении рассмотренного фрагмента алгоритма исключения и
назначения
ключевых
атрибутов
оправданно
и
полезно
участие
разработчика БД. Таким образом, следует в очередной раз обратить
внимание на то, что предлагается концепция автоматизированного
проектирования БД, а не автоматического проектирования. Эта концепция
здесь и далее предлагает использование человеко-машинных процедур.
Как
видно из последних выражений, в отношениях R1 и R2
исключаются и ключевые атрибуты. Эти атрибуты на данном шаге
алгоритма становятся неактуальными, и впоследствии предполагается
сформировать новые ключи.
Следующим шагом метода
является исключение повторяющихся
записей в отношениях R1’ и R2’.
Ниже представлен алгоритм исключения повторяющихся записей в
отношении R1’.
FOR i= 1 то m
sa = sai
FOR i1 = i + 1 то m
IF sai1 = sa THEN DELETE(sai1)
NEXT i1
NEXT i
183
Если
отношения
представлены
в
формате
БД,
то
на
SQL
соответствующий запрос исключения повторяющихся записей выглядит
следующим образом.
SELECT DISTINCT Авторы.Фамилия, Авторы.Публикация, Авторы.[Email]
INTO Авторы1
FROM Авторы;
Здесь из таблицы ”Авторы” формируется таблица ”Авторы1”, в нее
включаются три поля исходной таблицы. При
этом
конструкция
“DISTINCT” позволяет исключить повторяющиеся записи.
Ниже представлен алгоритм исключения повторяющихся записей в
отношении R2’.
FOR i= 1 то m
sb = sвi
FOR i1 = i + 1 то m
IF sbi1 = sb THEN DELETE(sbi1)
NEXT i1
NEXT i
Если
отношения
представлены
в
формате
БД,
то
на
SQL
соответствующий запрос исключения повторяющихся записей выглядит
следующим образом.
SELECT DISTINCT Книги.Книга, Книги.Издательство, Книги.Тираж
INTO Книги1
FROM Книги;
Далее для отношений
R1’ и R2’ необходимо сформировать новые
первичные ключи. Наиболее просто и эффективно это осуществляется
посредством добавления в описанные таблицы нового ключевого поля
типа “СЧЕТЧИК”. В результате получаются отношения вида табл. 6.3.3 и
6.3.4.
184
Формирование 3-й таблицы для реализации многозначных
связей.
Для
формирования
таблицы
связей
необходимо
сканировать
отношение R1'.
Для каждого значения поля этого отношения необходимо найти
соответствующее значение в R1 (в исходном отношении).
Для
этого
значения
необходимо
выбрать
соответствующее
характерное значение отношения R2 (оно принадлежит той же записи
отношения R1).
В отношении R2’ необходимо найти это характерное значение.
Первому атрибуту отношения
R3 необходимо присвоить значение
ключевого атрибута текущей записи отношения R1’, а второму атрибуту R3
– присвоить значение ключевого атрибута найденной записи отношения
R2’.
Неформальный алгоритм формирования 3-й таблицы осуществляется
следующим образом:
П1: Выбирается очередное значение характерного атрибута R1’ - a'к1
до тех пор, пока они не исчерпаются, при этом запоминается значение
соответствующего ключевого атрибута ka'к .
П2:
В
отношении
R1
ищется
значение
соответствующего
характерного атрибута, равного ai1. Найденные значения в предыдущих
итерациях не рассматриваются. Если такого значения не находится, то
выполняется переход к П6.
П3: В записи с найденным значением характерного атрибута
выбирается значение атрибута, характерного для отношения R2 - an.
П4: В отношении R2’ ищется значение характерного соответствующего
атрибута an (b’m = an). Запоминается значение ключевого атрибута
соответствующее b’m (kb'm).
П5: В отношение R3 формируется запись. В качестве значения 1 –го
атрибута отношения R3 используется ka'i. В качестве значения 2 – го
атрибута отношения R3 используется kb'm. Переход к П2.
П6: Переход к П1.
185
Формальный алгоритм формирования 3-го отношения выглядит
следующим образом.
c=0
FOR k = 1 то kv
k1 = kaк’
aк = a'к1
M1: FOR n = 1 то nv
IFan1 = aк THEN
an = an2
an1 = NULL
F = TRUE
EXIT FOR
ELSE
F = FALSE
END IF
NEXT n
IF (F = FALSE) THEN EXIT FOR
FOR m = 1 то mv
IF b’m2 = an THEN
k2 = kb’m
EXIT FOR
END IF
NEXT m
CREATE S FOR R3
c=c+1
dc1 = k1
dc2 = k2
IF F THEN GOTO M1
NEXT k
Здесь kv - число записей в отношении R1';
nv - число записей в отношении R1;
mv - число записей в отношении R2’;
kaк’ – ключевой атрибут в k-й записи отношения R1';
a'к1 – 1-й характерный атрибут в k-й записи отношения R1';
186
an2 – 2-й характерный атрибут в n-й записи отношения R1;
b’m2 – 2-й характерный атрибут в m-й записи отношения R2’;
kb’m – ключевой атрибут в m-й записи отношения R2';
dc1 – 1-й характерный атрибут в c-й записи отношения R3;
dc2 – 2-й характерный атрибут в c-й записи отношения R3;
Оператор
“CREATE S FOR R3” создает новую запись в отношении
R3
Рассмотрим, что можно сделать по поводу выявления связей многие ко многим с помощью визуального анализа содержимого таблиц и
стандартных средств СУБД.
На рис. 6.3.1 представлена таблица ”Авторы” в формате Microsoft
Access, которая претендует на роль таблицы, принадлежащей связи
многие - ко многим.
Рис. 6.3.1. Таблица ”Авторы”, которая претендует на роль таблицы,
принадлежащей связи многие - ко многим
На рис. 6.3.2 представлена таблица ”Издательства” в формате
Microsoft Access, которая претендует на роль таблицы, принадлежащей
связи многие - ко многим.
187
Рис. 6.3.2. Таблица ”Издательства”, которая претендует на роль
таблицы, принадлежащей связи многие - ко многим
Визуальный анализ приведенных на рисунках таблиц позволяет
предположить, что они связаны между собой. С одной стороны связи
реализуются посредством полей ”Фамилия” и
”Авторы”).
”Публикации” (таблица
С другой стороны связи реализуются посредством и полей
”Книга” и ”Автор” (таблица ”Издательство”).
В
дальнейшем
будем
действовать
в
соответствии
с
вышеизложенными алгоритмами.
На основе таблицы ”Авторы” сформируем новую таблицу ”Авторы1”, в
которой исключено ключевое поле, поле ”Публикации” и дублирование
записей.
Соответствующий
запрос
на
создание
таблицы
выглядит
следующим образом:
SELECT DISTINCT Авторы.Фамилия, Авторы.Город INTO Авторы1
FROM Авторы;
Конструкция DISTINCT позволяет исключить повторяющиеся записи.
В результате выполнения данного запроса сформируется таблица,
представленная на рис. 6.3.3.
Рис. 6.3.3. Результат выполнения запроса на создание таблицы
На
основе
таблицы
”Авторы”
сформируем
новую
таблицу
”Издательства1”, в которой исключено ключевое поле, поле ”Автор” и
дублирование записей. Соответствующий запрос на создание таблицы
выглядит следующим образом:
188
SELECT DISTINCT Издательства.Книга, Издательства.Издательство,
Издательства.Тираж INTO Издательства1
FROM Издательства;
В результате выполнения данного запроса сформируется таблица,
представленная на рис. 6.3.4.
Рис. 6.3.4. Результат выполнения запроса на создание таблицы
Теперь назначим ключевые поля типа ”Счетчик” таблицам ”Авторы1” и
”Издательства1”. После назначения ключевого поля таблица ”Авторы1”
примет вид (рис. 6.3.5).
Рис. 6.3.5. Вид таблицы ”Авторы1” после назначения ключевого поля
После назначения ключевого поля таблица ”Издательства1” примет
вид (рис. 6.3.6).
Рис. 6.3.6. Вид таблицы ”Издательства1” после назначения ключевого
поля
На
следующем
шаге
необходимо
спроектировать
таблицу,
используемую для организации связей между таблицами ”Авторы1” и
189
”Издательства1”. Эта таблица состоит из двух числовых полей. Для
наглядности полям приписаны имена NA и NK, а самой таблице присвоено
имя ”Связи”.
Далее нужно открыть одну из исходных таблиц, таблицу ”Авторы1”,
таблицу ”Издательства1”, таблицу ”Связи” и расположить их на экране,
чтобы были видны их поля. Такое расположение названных таблиц
представлено на рис. 6.3.7.
Рис. 6.3.7. Расположение таблиц на экране для заполнения таблицы
”Связи”
Теперь нужно просматривать записи таблицы “Авторы”. Для каждого
сочетания
полей
”Фамилия”
и
”Публикации”
следует
выбирать
соответствующие значения ключевых полей в таблицах ”Авторы1” и
”Издательства1” и заносить их в таблицу ”Связи”. В результате этих
действий таблица ”Связи” примет вид рис. 6.3.8.
190
Рис. 6.3.8. Заполненная таблица ”Связи”
После выполнения перечисленных подготовительных действий можно
сформировать связи типа многие - ко многим между таблицами ”Авторы1”
и ”Издательства1” с помощью таблицы ”Связи”. Соответствующая схема
данных представлена на рис. 6.3.9.
Рис. 6.3.9. Схема данных, реализующая связь многие - ко многим
Теперь убедимся в том, что в случае необходимости мы сможем
получить данные в таком же виде, что и в исходных таблицах.
Для формирования данных, содержащихся в таблице ”Авторы”,
сформирован запрос, бланк которого приведен на рис. 6.3.10.
191
.
Рис. 6.3.10. Бланк запроса для формирования данных, содержащихся
в таблице ”Авторы”
Результат выполнения данного запроса представлен на рис. 6.3.11.
Рис. 6.3.11. Результат выполнения запроса на выборку данных об
авторах
Нетрудно заметить, что данные, приведенные на этом рисунке,
полностью совпадают с данными исходной таблицы, приведенными на рис
6.3.1.
Для формирования, данных содержащихся в таблице ”Издательства”,
сформирован запрос, бланк которого приведен на рис. 6.3.12.
192
Рис. 6.3.12. Бланк запроса для формирования данных содержащихся
в таблице ”Издательства”
Результат выполнения данного запроса представлен на рис. 6.3.13.
Рис. 6.3.13. Результат выполнения запроса на выборку данных об
издательствах
Нетрудно заметить, что данные, приведенные на этом рисунке,
полностью совпадают с данными исходной таблицы, приведенными на рис
6.3.2.
Выгода выполненного преобразования таблиц очевидна. После
несложных подсчетов можно сделать заключение, что в двух исходных
таблицах было заполнено 63 поля, а в трех полученных – 35 полей.
Гораздо
существенней
будет
ощущаться
выгода
преобразования
реальных таблиц. Правда, далеко не всегда их удастся преобразовать
193
посредством визуального анализа и использования стандартных средств
СУБД.
Упражнения и вопросы для самоконтроля
1. Приведите примеры реальных таблиц, которые связаны между
собой связью ”один - к одному”.
2. Опишите алгоритм выявления связей ”один - к одному”.
3. Как реализовать данный алгоритм на основе визуального анализа
таблиц и существующих средств СУБД?
4. Приведите примеры реальных таблиц, которые связаны между
собой связью один - ко многим.
5. Опишите алгоритм выявления связей один - ко многим.
6. Как реализовать данный алгоритм на основе визуального анализа
таблиц и существующих средств СУБД?
7. Приведите примеры реальных таблиц, которые связаны между
собой связью типа многие - ко многим.
8. Опишите алгоритм выявления связей многие - ко многим.
9. Как реализовать данный алгоритм на основе визуального анализа
таблиц и существующих средств СУБД?
194
7. ОБЪЕДИНЕНИЕ ТАБЛИЦ
7.1. Проблемы объединения таблиц
Если не рассматривать множество специфических особенностей
конкретных БД, необходимость объединения содержимого таблиц может
возникнуть в двух случаях. В первом случае данные поступают из
нескольких источников в центр и там полученные данные сводятся в одну
таблицу для дальнейшего анализа и обработки. Во втором случае, когда
создается БД на основе существующей информации табличного вида,
необходимо выявить сходные по структуре и смысловому содержанию
таблицы и объединить их в одну.
В соответствии с положениями реляционной алгебры объединение
двух отношений есть множество всех кортежей, принадлежащих каждому
из исходных отношений. Другими словами в результате объединения двух
таблиц создается третья таблица, которая включает в себя все записи 1-й
таблицы и недостающие записи 2-й таблицы. Исходные отношения
должны быть совместимы по объединению. Отношения называются
совместимыми по объединению, если они базируются на одном и том же
числе одних и тех же доменов (столбцов).
В
качестве
иллюстрации
операции
объединения
используем
отношения, представленные таблицами табл. 7.1.1, табл.7.1.2 и табл.
7.1.3. В табл. 7.1.1 и табл.7.1.2 приведены операнды операции отношение,
в табл. 7.1.3 приведен результат выполнения этой операции.
Т а б л и ц а 7.1.1
Фамилия
Год рождения
Город
Чугунов
1955
Ногинск
Конев
1958
Козельск
Деребизова
1959
Моршанск
Караваев
1957
Семикино
Попова
1951
Ледово
Т а б л и ц а 7.1.2
195
Фамилия
Год рождения
Город
Харченко
1954
Киев
Умуралиев
1954
Астана
Комлев
1958
Москва
Мялицына
1959
Москва
Попова
1951
Ледово
Чугунов
1955
Ногинск
Т а б л и ц а 7.1.3
Фамилия
Год рождения
Город
Чугунов
1955
Ногинск
Конев
1958
Козельск
Деребизова
1959
Моршанск
Караваев
1957
Семикино
Попова
1951
Ледово
Харченко
1954
Киев
Умуралиев
1954
Астана
Комлев
1958
Москва
Мялицына
1959
Москва
Из анализа табл. 7.1.1. и табл. 7.1.2. нетрудно заметить, что операнды
операции объединения совместимы. Действительно, они состоят из одних
и тех же столбцов – заголовки столбцов одинаковые, содержимое
одноименных столбцов совпадают по типу. Результаты объединения, как
видно из табл. 7.1.3., представляют собой все записи 1-й таблицы и
недостающие записи 2-й таблицы. Действительно, т.к. первая и последняя
запись 1-й таблицы присутствуют и в 1-й и во 2-й таблице, то в 3-й таблице
(результирующей) они встречаются единожды.
Смысловое содержание приведенного примера может быть таким. В
таблицах – источниках приведены списки участников конференции.
Некоторые участники по какой-либо причине зарегистрировались у двух
регистраторов. В базе данных необходимо сохранить данные обо всех
участниках
конференции
без
дублирования
записей.
Применение
196
оператора объединения для таблиц двух регистраторов и позволяет
получить нужную таблицу. Если участников конференции регистрировало
N регистраторов, то оператор объединения отношений необходимо
выполнить N -1 раз. Причем в качестве 1-го операнда при первой итерации
объединения выступает 1-я таблица, а в качестве 2-го операнда - 2-я
таблица. При второй итерации объединения в качестве 1-го операнда
выступает результат выполнения предыдущего объединения, а в качестве
2-го операнда - 3-я таблица и т.д.
Запрос, который необходимо выполнить для объединения 2-х таблиц,
выглядит следующим образом:
INSERT INTO Список1 (Фамилия, [Год рождения], Город )
SELECT Список2.Фамилия, Список2.[Год рождения], Список2.Город
FROM Список2;
Здесь
с
помощью
конструкции
“SELECT
Список2.Фамилия,
Список2.[Год рождения], Список2.Город FROM Список2” из таблицы
“Список2” выбираются значения трех полей. Посредством конструкции
“INSERT INTO Список1 (Фамилия, [Год рождения], Город)” значения
выбранных полей добавляются в соответствующие столбцы таблицы
“Список1”. На рис. 7.1.1 приведено содержимое таблицы “Список1” после
выполнения запроса.
Рис. 7.1.1. Результат выполнения запроса на добавление
197
Как видно из рисунка, в таблице имеет место дублирование записей.
Поэтому для исключения дублирования необходимо выполнить еще один
запрос вида:
SELECT DISTINCT Список1.* INTO Список_общий
FROM Список1;
Здесь посредством конструкций "SELECT DISTINCT Список1.*” и
”FROM Список1” выбираются все значения полей таблицы “Список1”.
Посредством режима ”DISTINCT” из выбранного списка исключаются
повторяющиеся записи, а посредством конструкции ”INTO Список_общий”
выбранные записи помещаются в новую таблицу ”Список_общий”. В
результате
выполнения
этого
запроса
сформируется
таблица
”Список_общий”, которая имеет вид рис. 7.1.2.
Рис. 7.1.2. Таблица без дублирования записей
Как видно из рисунка, нужный результат достигнут – сформирован
общий список, а дублирование записей исключено.
В
условию
рассмотренном
примере,
совместимости
по
который
полностью
объединению,
проблем
удовлетворяет
в
процессе
формирования сводной таблицы практически не возникает. Это видно из
сказанного выше.
В реальных ситуациях дело нередко обстоит несколько сложнее, и
возникают проблемы, которые необходимо решать. Рассмотрим эти
ситуации в порядке возрастания сложности.
198
Исходные таблицы по своей природе удовлетворяют
требованиям совместимости, а по форме – нет.
Такого рода ситуации возникают когда:
- заголовки одинаковых по смыслу столбцов у объединяемых таблиц
отличаются;
- порядок столбцов первой таблицы – операнда не совпадает с
порядком столбцов второй таблицы – операнда.
В качестве 1-го операнда для иллюстрации ситуации используем
таблицу, аналогичную отношению, приведенному в табл. 7.1.1. В формате
Microsoft Access эта таблица приведена на рис. 7.1.3.
Рис. 7.1.3. Первый операнд операции объединения в формате
Microsoft Access
В качестве 2-го операнда используем таблицу, приведенную в
формате Microsoft Access на рис. 7.1.4.
Рис. 7.1.4. Второй операнд операции объединения в формате
Microsoft Access.
199
Как видно из рис. 7.1.4, заголовки 2-го операнда не совпадают с
заголовками 1-го операнда. Кроме того, порядок столбцов 2-го операнда не
совпадает с порядком столбцов 1-го операнда. Однако визуальный анализ
содержимого 1-го и 2-го операндов (обеих таблиц) позволяет сделать
вывод о том, что структуры этих таблиц совпадают, и каждому столбцу 1-й
таблицы находится соответствующий столбец 2-й таблицы. В связи с этим
администратор БД может принять решение о том, в каком порядке
содержимое столбцов 2-й таблицы добавлять к содержимому 1-й таблицы.
Свое решение администратор может отразить в бланке запроса на
добавление. Соответствующий бланк запроса в системе Microsoft Access
приведен на рис. 7.1.5.
Рис. 7.1.5. Бланк запроса на объединение двух таблиц
Таблица, в которую предполагается добавить записи, указывается в
меню Запрос/Добавление. В нашем случае указана таблица c именем
“Список0”.
Из рисунка видно, каким образом установлено соответствии
между полями таблиц “Список3” и “Список0”. Соответствующий запрос в
режиме SQL можно просмотреть с помощью меню Вид/Режим SQL. Этот
запрос,
который
может
быть
использован
с
незначительными
модификациями в любой СУБД, выглядит следующим образом:
INSERT INTO Список0 (Фамилия, [Год рождения], Город )
200
SELECT Список3.[Участник конференции], Список3.[Дата рождения],
Список3.[Откуда прибыл]
FROM Список3;
Из анализа запроса можно сделать заключение о том, каким образом
установлено соответствие между полями двух таблиц.
Результат
выполнения
запроса
–
это
таблица
“Список0”
с
добавленными записями. Она приведена на рис. 7.1.6.
Рис.7.1.6. Результат выполнения запроса на объединение
Как видно из рисунка, результат выполнения запроса ничем не
отличается от результата выполнения запроса, приведенного
на рис.
7.1.1. Таким образом, в результате формирования описанного запроса
получен требуемый результат.
Как следует из сказанного выше, рассмотренная проблема несложно
решается, если администратор БД способен принять решение о том, каким
образом
установить
соответствие
между
столбцами
объединяемых
таблиц. Очень часто такое решение не представляет существенных
проблем, т.к. изначально, как правило, предполагается объединение таких
таблиц, для которых это имеет смысл и суть столбцов очевидна.
Теоретически
автоматически.
можно
выявить
Но для этого
нужно
соответствующие
столбцы
и
с помощью соответствующих
201
программных средств анализировать семантику содержимого столбцов,
что сложно и практически неприемлемо.
Исходные таблицы удовлетворяют требованиям совместимости,
результирующую таблицу необходимо обновлять.
Ситуации такого рода возникают в том случае, если в центральной БД
аккумулируются данные, поступающие из различных источников. При этом
формат БД центра и форматы БД источников заранее оговорены и
совпадают. В этом случае проблема совместимости не стоит. Однако
возникают проблемы двух типов.
Проблема первого типа связана с тем, что наряду с новыми записями
в центр передаются и те записи, которые уже ранее были переданы и
добавлены в таблицы центральной БД.
В этом случае, если не принять специальных мер, в центральной БД
возможно дублирование записей, что в конечном итоге приводит к
искажению информации, противоречивости БД. Передавать же только те
данные, которые не передавались ранее затруднительно, а часто и
невозможно.
Во-первых,
механизм
отслеживания
импортированных данных из БД регионов нетривиален, а
хронологии
во-вторых,
нередко имеется необходимость передачи уже импортированных данных,
т.к. эти записи с данными могут быть обновлены, например, изменена
стадия выполнения проекта.
Проблема второго типа возникает в связи с тем, что нередко в центр
передаются обновленные записи таблиц, которые ранее в центр уже
передавались. В связи с этим возникает необходимость обновления всех
записей в центре, которые повторно экспортированы из регионов и
которые в регионах были изменены. Проблема несколько упрощается в
связи с тем, что, как показывает опыт работы с такого рода механизмом
передачи и обработки данных, число обновляемых полей невелико и их
состав регламентирован.
Более детально эти вопросы рассмотрены в следующем параграфе.
Исходные таблицы частично удовлетворяют требованиям
совместимости.
202
Ситуация такого рода чаще всего возникает, когда осуществляется
проектирование баз данных на основе использования существующей
информации
табличного
вида.
Например,
возникает
необходимость
проектирования БД на основе использования набора заполненных
электронных таблиц.
Нередко в наборе электронных таблиц можно выявить группы таблиц,
в которых значительная часть атрибутов совпадает. Такое положение
вещей может быть обусловлено различными причинами. В частности,
столбцы могут быть продублированы по ошибке, одинаковые столбцы в
разных таблицах используются из соображений удобства визуального
анализа данных в рамках одной таблицы, могут быть и другие причины. В
этом случае имеет место дублирование данных. Если это иногда
приемлемо и даже оправданно в электронных таблицах, то в БД
дублирование информации недопустимо. Дублирование БД приводит к
противоречивости
БД,
ее
избыточности.
В
связи
с
этим
при
проектировании БД на основе использования существующей информации
табличного вида необходимо решить две проблемы.
Первая
проблема
связана
с
выявлением
таблиц,
в
которых
значительная часть атрибутов совпадает. В рамках этой проблемы
необходимо убедиться не только в том, что имеются совпадающие
заголовки таблиц в разных таблицах, но и в том, что эти совпадения
неслучайны и суть этих совпадающих заголовков одинакова.
Вторая проблема решается тогда, когда выявлены таблицы с
одинаковыми по смыслу атрибутами. Тогда необходимо выявленные
таблицы объединить.
В общем случае состав атрибутов даже в таблицах, в которых
имеются совпадения атрибутов, может быть различный и тогда задача
объединения таблиц усложняется по сравнению с рассмотренными выше
примерами.
Более детально данная проблема рассмотрена в 7.3.
7.2. Объединение и обновление совместимых таблиц
203
Во многих организациях используется следующий механизм сбора и
обработки данных. В подразделениях организации ведутся БД. В
установленные
даты
данные
из
подразделений
пересылаются
по
электронной почте в региональные центры. В установленные даты данные
из региональных центров передаются в центр. Таким образом, в
подразделениях организации накапливаются и обрабатываются данные,
относящиеся только к конкретному подразделению. В региональных
центрах накапливаются и обрабатываются данные, относящиеся к группе
подразделений, входящих в региональный центр. В центре накапливаются
и обрабатываются данные, относящиеся к группе региональных центров.
Число уровней хранения данных может быть и большим, а также равным
двум. Но от этого суть процесса передачи и приема данных не меняется. В
любом случае в подразделениях необходимо выполнить экспорт основных
таблиц, а в центрах необходимо выполнить импорт этих таблиц.
При таком подходе неизбежно многократное поступление одних и тех
же данных в центр из регионов. Кроме того, повторно передаваемые
данные (записи) могут быть частично изменены, например, в каком-либо
поле или группе полей могут быть перед повторной пересылкой данных
изменены
значения.
Это
порождает
одновременно
необходимость
отсеивания уже принятых данных, и необходимость модификации данных
в центрах, если они уже ранее были получены.
Самым разумным способом исключения дублирования записей при
импорте представляется использование ключевых полей. Действительно,
при попытке добавления новой записи, у которой значение ключевого поля
равно значению ключевого поля записи, содержащейся в таблице, эта
запись добавлена не будет. Это обусловлено особенностями первичных
ключей, которые должны иметь уникальные значения. Во всех СУБД
предусмотрены
средства,
которые
реализуют
невозможность
формирования или добавления записей с одинаковыми значениями
первичных ключей.
В качестве первичного ключа очень часто используется поле типа
”Счетчик”. При формировании новой записи в таком поле автоматически
формируется уникальное значение. Это очень удобно, т.к. пользователю
БД
не
нужно
заполнять
это
поле
и,
кроме
того,
автоматически
204
обеспечивается
одно
из
требований
к
реляционным
таблицам
–
уникальность записей.
Но в рассматриваемом случае использование ключевых полей типа
”Счетчик” неприемлемо. Дело в том, что в этом случае записи таблиц
различных регионов будут иметь одинаковые значения ключевых полей,
хотя по сути записи не совпадают. И при импорте записей из нескольких
регионов в центральную БД значительная часть записей не будет
импортирована. В связи с этим значения ключевых полей должны
формироваться таким образом, чтобы они были уникальны не только в
рамках таблиц региональных БД, но и были уникальны в рамках всех
аналогичных таблиц всех регионов. Один из самых простых способов
формирования первичного ключа – это использование в качестве его
значения конкатенации характерного обозначения региона, кода продавца
и номера записи.
Рассмотрим
реальный
пример:
предприятие,
занимающееся
поставкой оборудования, имеет представительства в нескольких регионах.
Каждый продавец региона ведет собственную БД, в которой ведет учет
поставки оборудования Заказчикам. Региональный руководитель собирает
данные от продавцов и пересылает их в Центр. Продавцы формируют
коммерческие предложения, каждое из которых имеет уникальное имя.
Имя состоит из кода продавца, кода региона, и порядкового номера. На
рис. 7.2.1. приведен фрагмент списка коммерческих предложений одного
из продавцов.
Рис. 7.2.1. Фрагмент списка коммерческих предложений
Уникальное имя записи в рамках всех регионов обеспечивается
посредством поля ”Offers Number”.
205
По
аналогии
формируются
ключевые
поля
и
других
таблиц,
пересылаемых в региональные центры.
Импортирование одной из таблиц в промежуточную БД, которая
отсылается в региональный центр, осуществляется посредством макроса,
фрагмент которого приведен на рис. 7.2.2.
Рис. 7.2.2. Фрагмент макроса, обеспечивающего экспорт нескольких
таблиц во вспомогательную БД
В данном случае в качестве источника для экспорта используется
таблица ”Заказчики”, а в качестве приемника ”Заказчики_ex”. БД для
экспорта располагается в папке c:\actmng\export.
Подобным образом экспортируются все основные таблицы, для
каждой
из
которых
сформирована
макрокоманда
ПреобразоватьБазуДанных.
На рис. 7.2.3. приведен фрагмент содержимого таблицы, которая
сформирована из записей, импортированных от двух продавцов. Как видно
из рисунка, ключевое поле ”Offers Number” сформировано таким образом,
что его содержимое в принципе не может повторяться у различных
продавцов.
206
Рис 7.2.3. Таблица с записями двух продавцов
Проиллюстрируем
импорт
данных,
содержащих
записи
уже
имеющихся в БД регионального центра. Эти записи наряду с новыми
записями приведены на рис. 7.2.4.
Рис.7.2.4. Данные, импортируемые в региональный центр.
Запрос на добавление записей из временной таблицы в таблицу
центра выглядит следующим образом:
INSERT INTO _КП SELECT [_КП_ex].* FROM _КП_ex;
Здесь посредством конструкции “SELECT [_КП_ex].* FROM _КП_ex”
выбираются значения всех полей временной таблицы ”_КП_ex”, и эти
значения добавляются с помощью конструкции
”INSERT INTO _КП”
добавляются в таблицу БД центра с именем “_КП”. Следует отметить, что
такое возможно в связи с тем, что с временной таблицей средствами
Microsoft
Access
организована
связь.
Число
подобных
запросов
соответствует числу импортируемых таблиц.
После
выполнения
запроса
на
импорт
этих
данных
в
БД
регионального центра таблица с данными в центре примет вид рис. 7.2.5.
207
Рис.7.2.5. Таблица БД регионального центра после выполнения
импорта данных продавца.
Как видно из рисунка, в таблицу центра добавились только новые
записи. Таким образом, в рассматриваемом примере при импорте данных
обеспечивается
фильтрация
ранее
импортированных
данных.
Это
произошло благодаря тому, что поле ”Offers Number” является ключевым, и
записи с повторяющимися значениями ключевого поля не добавляются.
Кроме рассмотренной проблемы необходимо решить проблемы
обновления записей таблиц региональных центров в том случае, если
соответствующие записи были обновлены у продавцов.
Так как в региональном центре могут храниться записи нескольких
десятков
продавцов,
то
в
средствах
обновления
должна
быть
предусмотрена возможность обновления записей непосредственно после
выполнения их импорта. Кроме того, должна быть предусмотрена
возможность обновления данных только того продавца, от которого
импортированы данные. Так как состав полей, которые продавец может
обновлять
регламентирован,
то
в
запросе
на
обновление
нет
необходимости задействовать все 250 полей таблицы. Тем более, что
запрос на обновления большого количества полей в таблицах реального
объема, будет выполняться долго (до нескольких минут).
На
рис. 7.2.6. приведен бланк запроса на обновление полей тех
записей, которые уже находятся в БД регионального центра.
208
Рис.7.2.6. Запрос на обновление записей, находящихся в БД
регионального центра.
Из рисунка видно, что обновляются только те записи, которые
содержатся в БД регионального центра (таблица _КП) и которые, кроме
того, импортируются от продавца (таблица _КП_ex). Это обеспечивается
посредством сформированной связи ”один - к одному” между этими
таблицами по ключевым полям ”Offers Number”. Из рисунка также видно,
что данные для обновления берутся из полей временной таблицы ”_КП_ex”
(строка бланка запроса ”Обновление”). Таким образом, в ходе выполнения
запроса перебираются пары одноименных записей из двух таблиц
(записей с одинаковыми значениями ключевых полей).
Одноименные
записи таблицы ”_КП” обновляются посредством записей
таблицы
”_КП_ex”. В связи с этим для каждой записи таблицы ”_КП” выбирается
соответствующая запись таблицы ”_КП_ex”, а затем, вместо старых
значений полей, таблицы ”_КП” заносятся соответствующие значения
полей таблицы ”_КП_ex”. Важно отметить, что, несмотря на использование
в рассмотренных таблицах более 200 полей, обновляются только 30
характерных полей.
Проиллюстрируем
работоспособность
предложенного
способа
обновления полей на примере. На рис. 7.2.5. представлены записи ”_КП”,
находящейся в БД регионального центра.
209
На рис 7.2.7. приведено содержимое таблицы продавца, которая
экспортируется в БД регионального центра.
Рис. 7.2.7. Содержимое таблицы продавца, которая экспортируется в
БД регионального центра.
Как видно из рисунка, импортируются те же самые записи, которые
уже были импортированы ранее. В связи с этим ожидается, что новых
записей в БД центра не появится. Однако значения полей ”Код_зак”
и
”ФИО агента” претерпели обновление, поэтому это обновление должно
быть отражено в БД центра после импорта данной таблицы.
После выполнения импорта данной таблицы
и выполнения запроса
на обновление таблица БД регионального центра примет вид рис. 7.2.8.
Рис. 7.2.8. Содержимое таблицы регионального центра после
импорта и обновления записей.
Как видно из рисунка, одноименные записи в таблицу не добавились,
что и ожидалось от импорта. А поля таблицы обновились значениями
полей одноименных записей импортируемой таблицы.
210
Таким образом, предложенный подход импорта и обновления полей
успешно работает.
Так как импортируется и обновляется несколько таблиц, оправданно
объединить команды импортирования и обновления всех таблиц в рамках
одной процедуры или в рамках одного макроса, как это реализовано на
рис. 7.2.9.
Рис. 7.2.9. Фрагмент макроса для импорта и обновления таблицы
7.3. Объединение таблиц, частично удовлетворяющих
требованиям совместимости
Принимается, что таблицы частично удовлетворяют требованиям
совместимости по объединению в том случае, если часть атрибутов этих
таблиц совпадает. Ситуация такого рода может быть как в существующих
БД, так и в наборе таблиц, которые используются для проектирования БД и
сформированы, например, в формате электронных таблиц. В любом
случае, если атрибуты двух или более таблиц совпадают, то это чаще
всего свидетельствует об избыточности БД или данных, на основе которых
проектируется БД.
От избыточности необходимо избавляться, т.к. она приводит к
нерациональному использованию памяти, возможности ввода и хранения
211
противоречивой информации, снижению защищенности БД, увеличению
времени доступа к данным.
Рассмотрим
примеры
таблиц,
частично
удовлетворяющих
требованиям совместимости. В табл. 7.3.1. приведен фрагмент ведомости
экзамена по физике.
Т а б л и ц а 7.3.1
Фамилия
N зачетной книжки
Оценка
Орлова
117У72
хор
Брейдо
121У72
отл
Камалян
108У72
удовл
Чернов
114У72
удовл
Сафронов
107У72
отл
Сидоров
133У72
хор
В табл. 7.3.2. приведен фрагмент ведомости экзамена по математике.
Т а б л и ц а 7.3.2
Фамилия
N зачетной книжки
Оценка
Орлова
117У72
удовл
Брейдо
121У72
отл
Камалян
108У72
удовл
Чернов
114У72
хор
Сафронов
107У72
отл
Сидоров
133У72
отл
В БД логичнее хранить таблицу вида табл. 7.3.3., а не две таблицы.
Т а б л и ц а 7.3.3
Фамилия
N зачетной книжки
Физика
Математика
212
Орлова
117У72
хор
удовл
Брейдо
121У72
отл
отл
Камалян
108У72
удовл
удовл
Чернов
114У72
удовл
хор
Сафронов
107У72
отл
отл
Сидоров
133У72
хор
отл
Из простого анализа даже этих
небольших фрагментов очевидна
выгода объединения таблиц – число заполненных полей уменьшилось в
полтора раза. Учитывая то, что число записей в таблицах обычно
значительно больше, чем в приведенных примерах, а количество таблиц
обычно больше двух, то эффект от объединения двух таблиц подобного
рода может быть существенным.
Неформальный
совместимых
по
алгоритм
объединению,
объединения
легко
таблиц,
просматривается
частично
из
анализа
приведенного примера. Он формулируется следующим образом.
П1. Перебираются все возможные пары из набора таблиц.
П2.Проверяется каждая пара на наличие частичной совместимости по
объединению. Если частичная совместимость не обнаружена, то - переход
к П1.
П3.
На
базе
всех
атрибутов
частично
совместимых
таблиц
формируются атрибуты третьей таблицы, при этом атрибуты в третьей
таблице не должны повторяться.
П4. К созданной таблице добавляются все записи первой таблицы.
П5. К созданной таблице добавляются только те записи второй
таблицы, у которых имеются несовпадающие значения одноименных с
первой таблицей атрибутов.
П6. Заполняются значения полей созданной таблицы. При этом
заполняются поля в тех записях, в которых имеются совпадающие
значения одноименных атрибутов исходных таблиц. Для заполнения
значений
таблицы,
результирующей
которые
таблицы
соответствуют
используются
атрибутам
значения
второй
второй
таблицы,
отсутствующим в первой таблице.
213
П7. 1-я и 2-я таблицы удаляются.
Таким образом в алгоритме учитывается ситуация общего вида:
имеются одинаковые атрибуты в объединенных таблицах; имеются
атрибуты в 1-й таблице, которых нет во 2-й таблице; во 2-й таблице
имеются атрибуты, которых нет в 1-й таблице; число записей 1-й и 2-й
таблиц могут не совпадать.
Проиллюстрируем шаги алгоритма на простых таблицах, в которых,
тем не менее, учтены все возможные особенности объединенных таблиц.
В табл. 7.3.4 и 7.3.5 приведены исходные данные для объединения.
Т а б л и ц а 7.3.4
Т а б л и ц а 7.3.5
А1
А2
А3
A1
A2
A4
ZA11
ZA21
ZA31
ZA11
ZA21
ZA41
ZA12
ZA22
ZA32
ZA12
ZA22
ZA42
ZA1K
ZA2K
ZA3K
ZA1N
ZA2N
ZA4N
В первых строках таблиц указаны имена атрибутов таблиц, в ячейках
таблиц указаны их значения. Как видно из примера, в таблицах имеются
одинаковые атрибуты, в 1-й таблице есть атрибуты, которых нет во второй
и наоборот, в таблицах имеются несовпадающие значения одноименных
атрибутов. Таким образом, этот простой пример отражает все возможные
нюансы.
Предполагается, что первые два пункта алгоритма выполнены.
Результат выполнения 3-го пункта алгоритма приведен в табл. 7.3.6.
Т а б л и ц а 7.3.6
А1
А2
А3
А4
Результат выполнения 4-го пункта алгоритма приведен в табл. 7.3.7.
Т а б л и ц а 7.3.7
А1
А2
А3
ZA11
ZA21
ZA31
ZA12
ZA22
ZA32
ZA1K
ZA2K
ZA3K
А4
214
Результат выполнения 5-го пункта алгоритма приведен в табл. 7.3.8
. Т а б л и ц а 7.3.8
А1
А2
А3
ZA11
ZA21
ZA31
ZA12
ZA22
ZA32
ZA1K
ZA2K
ZA3K
ZA1N
ZA2N
А4
ZA4N
Результат выполнения 6-го пункта алгоритма приведен в табл. 7.3.9.
Т а б л и ц а 7.3.9
А1
А2
А3
А4
ZA11
ZA21
ZA31
ZA41
ZA12
ZA22
ZA32
ZA42
ZA1K
ZA2K
ZA3K
ZA1N
ZA2N
ZA4N
Как видно из результирующей таблицы, одно значение атрибута А3 и
одно значение атрибута А4 оказались пустыми. При необходимости
пользователь БД может их заполнить или оставить пустыми (значения
NULL). При незаполненных значениях полей могут возникнуть проблемы в
процессе
выполнения запросов.
Поэтому рекомендуется,
если
нет
значения, использовать пустые строки ('''') для строковых полей или
регламентированные начальные значения для полей других типов.
Важно отметить то, что шаги алгоритма сформулированы не исходя
из соображений удобства восприятия, а исходя из простоты реализации
каждого
шага
алгоритма
на
основе
использования
языков
программирования или специализированных средств СУБД.
Проиллюстрируем предложенный алгоритм на основе реальных
таблиц и использования средств СУБД Microsoft Access.
В качестве 1-й таблицы используем таблицу, приведенную на рис.
7.3.1.
215
Рис. 7.3.1. Первая таблица, представленная в формате Microsoft
Microsoft Excel
В качестве 2-й таблицы используем таблицу, представленную на рис.
7.3.2.
Рис. 7.3.2. Вторая таблица, представленная в формате Microsoft
Microsoft Excel.
Как видно из рисунка, данные таблицы имеют одинаковые атрибуты и
отличающиеся атрибуты. При использовании этих таблиц в составе БД
имеет смысл их объединить. Для использования таблиц в составе БД, а
также для выполнения манипуляций по их объединению на основе
использования средств СУБД эти таблицы импортированы в СУБД.
Результат импорта 1-й таблицы представлен на рис. 7.3.3
.
Рис. 7.3.3. Результат импорта 1-й таблицы
216
Результат импорта 2-й таблицы представлен на рис. 7.3.4.
Рис. 7.3.4. Результат импорта 2-й таблицы
Визуальный анализ двух таблиц позволяет сделать вывод о том, что
часть атрибутов этих таблиц совпадает. Это следующие атрибуты:
”Продавец”, ”Колич”, ”Купе кабины”, ”Лебедка”, ”Цена”. Назовем эти
атрибуты характерными.
Создадим 3-ю таблицу, которая включает в себя записи 1-й таблицы и
записи
2-й
таблицы,
у
которых
значения
характерных
атрибутов
совпадают. Для этого используется запрос, бланк которого приведен на
рис. 7.3.5.
Рис. 7.3.5. Бланк запроса для формирования 3-й таблицы
Следует обратить внимание на то, что в бланке запроса таблицы
связаны по атрибутам, которые имеют место в обеих исходных таблицах.
217
Как видно из бланка запроса, между двумя объединяемыми таблицами
организованы связи по всем характерным полям. Таким образом, записи,
создаваемые на основе этого запроса, будут содержать характерные поля,
значения которых в обеих исходных таблицах совпадают. В запросе
выбираются все поля первой таблицы (Лист2) и недостающие поля второй
таблицы (лист3).
Соответствующий SQL запрос выглядит следующим образом:
SELECT Лист2.[№ п/п], Лист2.[Дата договора], Лист2.Продавец,
Лист2.Колич, Лист2.[Купе кабины], Лист2.Лебедка, Лист2.Цена, Лист3.[%
Успеха], Лист3.[Дата букинга] INTO [Объединение таблиц]
FROM
Лист2
INNER
JOIN
Лист3
ON
(Лист2.Продавец
=
Лист3.Продавец) AND (Лист2.Колич = Лист3.Колич) AND (Лист2.[Купе
кабины] = Лист3.[Купе кабины]) AND (Лист2.Лебедка = Лист3.Лебедка) AND
(Лист2.Цена = Лист3.Цена);
В
части
SELECT
перечисляются
поля
для
выборки.
После
конструкции INTO указывается целевая таблица [Объединение таблиц].
Конструкция ”FROM Лист2 INNER JOIN Лист3” указывает на то, что
исходные таблицы связаны между собой внутренним объединением (из
таблиц выбираются только те записи, у которых значения связанных полей
совпадают).
После конструкции ON указываются условия выборки –
равенства 5-и значений полей таблиц.
В результате выполнения этого запроса сформируется таблица,
представленная на рис. 7.3.6.
Рис. 7.3.6. Результат выполнения запроса на создание таблицы
218
Как видно из результатов выполнения запроса, сформировалась
таблица, которая включает в себя атрибуты обеих исходных таблиц.
Однако в таблицу включены только те записи, которые содержат значения
характерных атрибутов обеих таблиц. И в первой и во второй таблице в
общем
случае
могут
присутствовать
записи,
у
которых
значения
характерных атрибутов не совпадают. В рассматриваемом примере это
последние записи таблиц. Эти записи необходимо включить в новую
таблицу.
Предлагается следующий прием. Характерные поля в новой таблице
назначаются ключом. Выполняется запрос на добавление записей из
первой таблицы в новую таблицу. Выполняется запрос на добавление
записей из второй таблицы в новую таблицу. В новой таблице отменяется
назначение ключевого поля.
При выполнении запросов на добавления те записи, которые
присутствуют в новой таблице в соответствии со свойством ключевых
полей
добавляться не будут, а добавятся недостающие записи, что и
требуется.
На рис. 7.3.7 приведена новая таблица, открытая в режиме
Конструктора, Чтобы назначить характерные поля в состав ключа
необходимо их выделить, а затем щелкнуть по значку ”ключ”.
Рис. 7.3.7. Новая таблица, открытая в режиме Конструктора
На
следующем
шаге
необходимо
в
результирующую
таблицу
добавить записи из 1-й таблицы. Для этого используется запрос вида:
INSERT INTO [Объединение таблиц]
SELECT Лист2.*
219
FROM Лист2;
Это простой запрос на добавление всех записей таблицы “Лист2” в
таблицу [Объединение таблиц]. Но все записи после выполнения данного
запроса не добавятся, добавятся только те записи, у которых ключевые
поля не совпадают. Это видно из результатов выполнения запроса на
добавление, приведенного на рис. 7.3.8.
Рис. 7.3.8. Результат выполнения запроса на добавление
Как и предполагалась последняя запись 1-й таблицы добавилась в
результирующую таблицу.
На
следующем
шаге
необходимо
в
результирующую
таблицу
добавить записи из 2-й таблицы. Для этого используется запрос вида:
INSERT INTO [Объединение таблиц]
SELECT Лист3.*
FROM Лист3;
Это простой запрос на добавление всех записей таблицы “Лист3” в
таблицу [Объединение таблиц]. Но все записи после выполнения данного
запроса не добавятся, добавятся только те записи, у которых ключевые
поля не совпадают. Это видно из результатов выполнения запроса на
добавление, приведенного на рис. 7.3.9.
220
Рис. 7.3.9. Результат выполнения запроса на добавление записей
второй таблицы
Таким образом, посредством выполненных манипуляций удалось
объединить не полностью совместимые таблицы по объединению.
Как видно из примера, состав описанных действий несколько
отличается
от
описанных
ранее
состава
шагов
алгоритма.
Это
обусловлено возможностями Microsoft Access, которые далеко не всегда
можно задействовать. Алгоритм же применим во всех случаях, даже для
написания программ обработки текстовых файлов.
Важно, кроме того, отметить, что для таблиц с большим числом
атрибутов и записей использование способа визуального анализа таблиц и
стандартных средств СУБД зачастую практически невозможно. В связи с
этим оправданно использовать специальные программные средства для
решения задачи объединения таблиц.
Выполним формализованное описание алгоритма объединения не
полностью совместимых таблиц. Для этого воспользуемся представлением
таблиц
в
общем
виде.
Отношение
“A”
представлено
табл.7.3.10,
отношение “В” представлено табл.7.3.11.
Т а б л и ц а 7.3.10
Т а б л и ц а 7.3.11
A1
…
Ai
…
Ak
B1
…
Bq
…
Bt
a11
…
a1i
…
a1k
b11
…
b1q
…
b1t
…
…
…
…
…
…
…
…
…
…
aj1
…
aji
…
ajk
bp1
…
bpq
…
bpt
…
…
…
…
…
…
…
…
…
…
an1
…
ani
…
ank
bf1
…
bfq
…
bft
221
REM “поиск характерных атрибутов”
XA = 
FOR i =1 то k
FOR q =1 то t
IF Ai = Bq THEN XA = XA  Ai
NEXT q
NEXT i
REM “добавление в новое отношение записей с одинаковыми
REM значениями характерных атрибутов”
s=0
n1 = n
f1 = f
FOR j =1 то n
FOR p =1 то f
IF (ZAj  XA) = (ZBp  XA) THEN
s=s+1
ZCs = ZAj  ZBp
DEL (ZAj)
n1 = n1 – 1
DEL (ZBp)
f1 = f1 – 1
END IF
NEXT p
NEXT j
REM “добавление в новое отношение оставшихся записей
REM из отношения A”
FOR r = 1 то n1
s=s+1
ZCs = ZAr
NEXT r
REM “добавление в новое отношение оставшихся записей
REM из отношения B”
FOR r = 1 то f1
222
s=s+1
ZCs = ZBr
NEXT r
Здесь XA - множество характерных атрибутов;
A = (A1, …, Ai, …, Ak) – множество атрибутов 1-го отношения
(отношения А);
В = (B1, …, Bq, …, Bt) – множество атрибутов 2-го отношения
(отношения В);
ZAj = (aj1, …, aji, …, ajk) – значения j-ой строки отношения А;
ZBp = (bp1, …, bpq, …, bpt) – значения p-ой строки отношения B;
ZAj  XA – значения j – й строки отношения А, соответствующие
характерным атрибутам (ZAj  XA)  ZAj;
ZВp  XA - значения p – й строки отношения А, соответствующие
характерным атрибутам (ZВp  XA)  ZВp;
ZCs – значения s – й строки отношения C.;
Степень этого отношения равна сумме числа характерных атрибутов,
числа нехарактерных атрибутов отношения А и числа нехарактерных
атрибутов отношения В;
Оператор DEL(ZAj) обеспечивает удаление j-й записи из отношения А;
Оператор DEL (ZBp) обеспечивает удаление j-й записи из отношения
В.
Краткое пояснение алгоритма.
В циклах по i и q перебираются атрибуты отношений А и В. Если
найдутся одинаковые атрибуты, то они добавляются к множеству
характерных атрибутов.
В циклах по j и p в отношениях А и В выявляются записи, у которых
равны характерные значения. Если такая запись найдена, то формируется
запись нового отношения С и в соответствующие поля этого отношения
записываются значения полей из отношений А и В. После этого
обработанные записи из отношений А и В удаляются и подсчитывается
количество оставшихся записей в отношениях А и В.
223
В первом цикле по r к отношению С добавляются записи отношения А,
у которых не нашлось одинаковых значений характерных атрибутов в
отношении В.
Во втором цикле по r к отношению С добавляются записи отношения
В, у которых не нашлось одинаковых значений характерных атрибутов в
отношении А.
В обоих случаях при добавлении записей должно обеспечиваться
соответствие атрибутов отношений С и А, соответствие атрибутов
отношений С и В.
Упражнения и вопросы для самоконтроля
1. В каких случаях возникает необходимость объединения таблиц?
2. Какие таблицы называются совместимыми по объединению?
3. Приведите пример объединения двух совместимых по объединению
таблиц.
4. Какие таблицы называются не полностью совместимыми по
объединению?
5. Какие проблемы возникают при объединении таблиц?
6. Каким образом выполняется объединение совместимых по
объединению таблиц?
7. Каким образом выполняется обновление совместимых по
объединению таблиц?
8. Приведите пример объединения двух частично совместимых по
объединению таблиц.
9. Опишите алгоритм объединения двух частично совместимых по
объединению таблиц.
10. Приведите пример использования алгоритма объединения двух
частично совместимых по объединению таблиц.
11. Опишите порядок использования существующих средств СУБД для
объединения двух частично совместимых по объединению таблиц.
224
8. РАЗРАБОТКА И ИССЛЕДОВАНИЕ МОДЕЛИ МЕТОДИКИ
ПРОЕКТИРОВАНИЯ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ НА
ОСНОВЕ ИСПОЛЬЗОВАНИЯ ИНФОРМАЦИИ ТАБЛИЧНОГО
ВИДА
8.1. Постановка задачи разработки модели методики
Целью является разработка методов проектирования реляционных
баз данных (РБД) на основе использования существующей информации
табличного вида (ИТВ). Другими словами, необходимо разработать
приемы, способы и практические операции, подчиненные решению задач
преобразования ИТВ в РБД. Состав подзадач, решаемых в рамках
основной
задачи
и
соответственно
состав
необходимых
методов,
определен в 1-й главе. Методы решения частных задач преобразования
ИТВ в РБД, как правило, взаимосвязаны между собой и выполняются в
логической
последовательности.
А
взаимосвязанные
методы,
выполняемые в логической последовательности, составляют методику.
В рассматриваемом случае методика это не только совокупность
методов выполнения действа. Отдельные элементы методики (методы)
решения частных задач преобразования ИТВ в РБД тоже имеют право на
существование и могут быть использованы для решения конкретных задач.
Кроме того, большинству из методов соответствуют частные методики
использования
их
компонент. Так,
например,
метод
нормализации
реляционных таблиц включает в себя методы приведения таблиц к 1-й, 2й, 3-й
и 4-й нормальной форме и соответственно методику их
использования,
метод
выявления
и
формирования
связей
между
таблицами включает в себя 3-и метода (по числу типов связей) и
соответственно методику их использования.
В связи с этим, неочевидно в какой последовательности решать
проблемы работы: сначала разработать методы, а затем предложить
225
методику их использования или наоборот – разработать методику
проектирования РБД на основе ИТВ, абстрагируясь от детализации
методов, а затем разработать методы в рамках предложенной методики.
Оба подхода имеют свои преимущества и недостатки.
Преимущества первого подхода:
-
методы разработаны и при создании методики речь идет о
конкретных, существующих средствах;
-
характеристики методов и соответствующих средств к моменту
разработки методики известны и максимально полно могут быть учтены и
отражены в методике;
- состоятельность и количественные характеристики методики могут
быть оценены на основе использования реализованных методов.
Недостатки первого подхода:
- состав необходимых средств и даже методов после их разработки и
реализации может оказаться неполным для обеспечения эффективной
методики преобразования ИТВ в РБД;
-
взаимосвязь методов, алгоритмов и средств между собой к
моменту их реализации может оказаться неочевидной;
- последовательность и правильность применения методов для
обеспечения эффективного решения проблемы проектирования РБД на
основе ИТВ может оказаться недостаточно определенной.
Преимущества второго подхода:
- анализ проблемы создания системы на ранних этапах ее разработки
позволит определить состав не только основных методов и средств, но и
состав вспомогательных средств, которые необходимы для реализации
полноценной методики;
- выявление необходимых связей между методами и средствами на
ранних
этапах
разработки
системы
позволит
свести
к
минимуму
трудоемкость решения этой задачи впоследствии;
- определение последовательности и правил применения методов и
средств, ориентированных на преобразование ИТВ к РБД на ранних этапах
разработки системы, позволит свести к минимуму трудоемкость решения
этой задачи впоследствии;
226
- оценка качественных характеристик человеко-машинной системы до
ее реализации позволит исключить принципиальные ошибки в проекте
системы;
- предварительная оценка временных характеристик системы до ее
реализации позволит выявить критические места в системе заранее и
предпринять необходимые меры.
Недостатки второго подхода:
-
при описании методики проектирования РБД на основе ИТВ о
методах, которые задействованы в методике мало что известно, ведь они
еще не разработаны;
-
о
характеристиках
методов
известно
мало,
необходимые
характеристики могут быть получены только на основе экспертных оценок
или в результате специальных экспериментов;
- временные характеристики методов и соответствующих алгоритмов
неизвестны и могут быть оценены лишь предположительно.
Из вышесказанного следует, что большинство достоинств первого
подхода используемого при разработке методики проектирования РБД на
основе использования ИТВ, являются недостатками второго подхода и
наоборот. В связи с этим оправданно использование обоих подходов.
Данная глава посвящена разработке методике преобразования ИТВ к РБД
на основе второго подхода. Методика использования реализованных
методов и средств, ориентированная на решение задач проектирования
РБД на основе ИТВ, представлена в заключительной главе.
Конечно, в данном
случае речь может идти не о полноценной
методике, а лишь о ее математической модели. Причем модель должна
отражать свойства объекта исследования (методики) на ранних этапах ее
разработки, позволять выявлять концептуальные ошибки в методике,
выполнять предварительные оценки ее временных характеристик. Модель
должна
быть
адекватна
начальному
представлению
методики
или
отражать ее заданные свойства с приемлемой точностью. В связи с этим
необходимо
выполнить
использованию
модели
следующие
методики
мероприятия
проектирования
по
разработке
РБД
на
и
основе
использования ИТВ:
227
-
определить состав компонент методики (методов, алгоритмов,
специализированных средств);
-
сформировать взаимосвязи между этими компонентами;
-
выбрать
математический
аппарат,
позволяющий
описать
методику и исследовать ее характеристики;
-
выполнить построение адекватной модели методики на основе
использования выбранного математического аппарата;
-
выполнить исследование динамических свойств методики на
основе использования ее модели;
-
выполнить предварительный анализ временных характеристик
методики;
-
использовать разработанную модель в качестве основы для
разработки необходимых методов, алгоритмов и специализированных
средств, а также в качестве основы для разработки частных и общей
методик проектирования РБД на основе ИТВ.
Методика преобразования ИТВ к РБД – это человеко-машинный
процесс, поэтому в качестве ее модели оправданно использовать частный
случай алгоритмических моделей – имитационные [15]. С точки зрения
представления объектов на начальных этапах проектирования методики в
ее рамках используются такие понятия, как ИТВ, РБД, разработчик,
методы,
системы оценок.
Причем,
эти
объекты, как
правило,
не
конкретизируются, а лишь фиксируется факт их наличия, их взаимосвязи,
место в системе проектирования, последовательность и правила их
использования. Такое представление наиболее близко к системному
уровню, а на данном уровне преимущественно применяют модели систем
массового обслуживания и системы Петри [15]. На этом основании, и с
учетом специфики особенностей объекта моделирования, о котором еще
пойдет речь, в качестве основного математического аппарата для
моделирования
и
предварительного
исследования
методики
преобразования ИТВ к РБД выбран аппарат сетей Петри.
Несмотря
на
то,
что
большинство
объектов
методики
не
предполагается детализировать на ранних этапах разработки, такие
объекты, как РБД и ИТВ необходимо рассмотреть более подробно. Это
связано с тем, что данные объекты являются, с одной стороны,
228
основополагающими в работе, а с другой стороны они собственно и
определяют методику проектирования. В связи с этим в первой главе
предложены информационные модели РБД и ИТВ. Необходимо оценить
адекватность этих моделей относительно их использования в модели
методики проектирования с принятыми ограничениями ее представления.
В данном случае для анализа адекватности необходимо оценить
представлены ли все принципиальные отличия ИТВ от РБД в их
информационных моделях. Это связано с тем, что именно процесс
исключения этих различий и представляет собой методику преобразования
ИТВ к РБД. В качестве таких отличий при сравнительном анализе моделей
ИТВ и РБД а главе 2 сформулированы следующие отличия:
-
в ИТВ таблицы нереляционные;
-
в ИТВ таблицы ненормализованные;
-
в таблицах ИТВ отсутствуют ключевые поля;
-
таблицы ИТВ не связаны между собой.
Эти отличия моделей ИТВ и РБД закладываются в методику
преобразования ИТВ к РБД, определяют необходимый состав методов и
средств решения частных задач преобразования. Однако, если последние
3-и отличия ИТВ от РБД в принципе допустимо не ликвидировать и в
результате может быть спроектирована БД, правда, обладающая плохими
качественными и количественными характеристиками, то исключение 1-го
отличия – обязательно. В противном случае просто не удастся построить
БД на основе ИТВ.
В
связи
информационные
нереляционных
информационных
с
этим
необходимо
модели,
разработать
таблиц
и
моделей
тем
уточнить
модели
самым
относительно
предложенные
реляционных
добиться
модели
и
адекватности
методики
проектирования на основе ИТВ в рамках принятых ограничений. Пока же
модели ИТВ и РБД в рассматриваемом контексте неадекватны и могут
быть использованы только для начальной постановки задачи работы.
Такое уточнение выполнено в 4.2.1 и 4.2.2. После детализации моделей
таблиц ИТВ и РБД они становятся адекватными задачам разработки
модели методики. В дальнейшем для краткости под ИТВ будем понимать
модель ИТВ, а под РБД – модель РБД.
229
Реализована следующая процедура построения модели методики
проектирования РБД на основе использования ИТВ.
На первом этапе по аналогии с описанием процесса взаимодействия
решающих систем [16], используя отличительные особенности ИТВ и РБД,
в операторной форме описываются отдельные шаги преобразования ИТВ к
РБД, формируются связи между ними, определяются правила и порядок их
использования. Такое описание разработано с целью выявления основных
компонент разрабатываемой человеко-машинной системы выявления
основных
связей
между
ними,
построения
модели
методики
их
использования. В дальнейшем оно будет использовано для разработки
формальных моделей интерактивных процессов проектирования РБД на
основе
ИТВ.
Под
оператором
согласно
определению
понимается
отображение ОР: X  Y, в котором множества X и Y являются
множествами функций с элементами x(t) и y(t). Формально факт
преобразования функции x(t) в функцию y(t) посредством выполнения
оператора ОР отмечается следующим образом:
y(t) = ОР(x (t))
На втором этапе операторная модель используется в качестве
исходной формализации для разработки модели методики, построенной на
основе аппарата сетей Петри, и формируется соответствующая сеть.
На третьем этапе с помощью аппарата сетей Петри выявляются и
исключаются дефекты модели, а следовательно исключаются дефекты
объекта моделирования. В конечном итоге строится сетевая модель
методики, свободная от концептуальных ошибок, а значит адекватная
объекту моделирования (методике).
На
четвертом
этапе
с
помощью
деревьев
достижимости
анализируются динамические свойства методики при нулевых задержках
срабатывания переходов сети.
На пятом этапе выполняется предварительная оценка временных
характеристик методики.
На шестом этапе выполнены мероприятия по улучшению временных
характеристик методики.
230
8.2. Операторная модель преобразования информации
табличного вида к реляционным базам данных
.
На начальном уровне абстрагирования от большинства компонент
человеко-машинной системы схема процесса преобразования ИТВ к РБД
может быть проиллюстрирована рис. 8.2.1.
Мероприятия по
преобразованию
ИТВ
РБД
Рис 8.2.1. Исходная схема процесса преобразования ИТВ к РБД
В связи с тем, что, как известно, БД всегда проектируются с активным
участием
разработчика
автоматизированных
средств,
с
то
применением
при
соответствующих
выполнении
мероприятий
по
преобразованию ИТВ в БД разработчик тем более необходим. В связи с
этим схема, приведенная на рис 8.2.1. несколько видоизменится и примет
вид рис 8.2.2.
Мероприятия по
преобразованию
ИТВ
РБД

Рис 8.2.2. Исходная схема процесса преобразования ИТВ к РБД с
участием разработчика
Такая
схема
предполагает
необходимость
человеко-машинных
методов и средств, т.е. средств автоматизированного проектирования РБД
на основе ИТВ.
Участие разработчика в мероприятиях по преобразованию ИТВ в РБД
с одной стороны позволяет задействовать его творческий потенциал, а с
другой стороны ставит результаты преобразования в зависимость от
231
человеческого фактора. В связи с этим необходимо разработать методы и
средства, которые позволят:
- разработчику активно участвовать в процессе проектирования РБД
на основе ИТВ;
- автоматически решать все формализуемые задачи проектирования;
-
с
наибольшей
эффективностью
использовать
теоретические
положения проектирования РБД;
-
с
наибольшей
эффективностью
использовать
известные
инструментальные средства проектирования РБД.
Введем оператор преобразования ИТВ к РБД – ОП. Результатом
применения этого оператора ОП является модель РБД, отвечающая
требованиям непротиворечивости, минимальности, целостности. К числу
операндов оператора ОП в первую очередь относится модель ИТВ. Схема
преобразования модели ИТВ к модели РБД или операторная модель
преобразования примет вид рис 8.2.3.
ИТВ
ОП
РБД

Рис. 8.2.3. Операторная модель процесса преобразования ИТВ к РБД
В операторной форме преобразование ИТВ к РДБ выглядит
следующим образом: РБД = ОП (ИТВ)
Как видно из рис.8.2.3 между разработчиком и оператором ОП
имеется двухсторонняя связь. Это свидетельствует о том, что в качестве
второго операнда ОП используется модель поведения разработчика в
процессе преобразования ИТВ к РБД. С другой стороны, в качестве
результата применения ОП формируется не только модель РПД, но и
совокупность данных, позволяющих разработчику принимать решения в
соответствии со своей моделью поведения.
Таким образом, для принятия решения разработчиком о применении
средств оператора ОП необходима система оценок (СО) качества
232
преобразования ИТВ, а для реализации императив (указаний) необходим
набор действий разработчика, который реализует оператор ОПР.
С учетом сказанного рис. 8.2.3 примет вид рис.8.2.4.
ОП
ИТВ
СО

РБД
ОПР
Рис. 8.2.4. Вторая операторная форма модели преобразования ИТВ к
РБД
Коль скоро разработчик на основе СО принимает и выполняет
решение ОПР по поводу использования ОП, то логично предположить, что
и сам оператор итерационно выполняется на основе анализа системы
оценок. Учитывая это и исключив из схемы изображение человечка (теперь
он представлен СО и ОПР), получим операторную модель преобразования
ИТВ вида рис 8.2.5.
ОП
ИТВ
РБД
ОПР
СО
Рис. 8.2.5. Третья операторная форма модели преобразования ИТВ к
РБД
Уже
на
данном
шаге
представления
операторной
модели
преобразования можно сформулировать основные задачи исследования и
разработки. Необходимо выполнить следующие мероприятия:
- оценить полноту модели ИТВ относительно достаточности данных
для выполнения ОП и ОПР;
- оценить полноту модели РБД относительно достаточности данных
для выполнения ОП и ОПР;
233
- разработать методы и средства выполнения ОП и ОПР;
- разработать СО.
При
этом
названные
мероприятия
необходимо
выполнять
в
комплексе, т.к. СО, ОП, ОПР впрямую зависят от ИТВ и РБД и наоборот.
Выполним попытку разработки СО, ОП и ОПР, исходя из укрупненных
моделей ИТР и РБД, предложенных в главе 2 (рис 2.2 и рис 2.3).
Как видно из этих моделей, у них одна и та же предметная область.
Это может помочь при выполнении ОП в том случае, если одни и те же
объекты (таблицы, поля) в рамках модели ИТВ называются одинаково, тем
более это поможет при выполнении ОПР.
В обеих моделях представлено множество таблиц. Это в конечном
итоге и определяет возможность реализации ОП и ОПР.
В плане отличия моделей отмечено:
1. ИТВ в общем случае представлена нереляционными таблицами;
2. ИТВ в общем случае ненормализованы;
3. В ИТВ в общем случае отсутствуют ключевые поля;
4. ИТВ не связаны между собой.
Таким образом для выполнения ОП и ОПР необходима СО, которая
позволит оценить ИТВ, а также результат преобразования РБД.
Поэтому модель примет вид рис 8.2.6:
ИТВ
ОП
СО
ОПР
РБД
СП
Рис. 8.2.6. Четвертая операторная форма модели преобразования
ИТВ к РБД
Как видно из рис. 8.2.6 в модель добавился блок СП – система
преобразований, назначенных разработчиком. Блок введен в связи с
реальным положением дел и в соответствии с правилами операторной
формы. Теперь можно записать:
234
РБД = ОП (ИТВ, СО, СП)
СП = ОПР (СО)
Операторная
модель
такого
рода,
использующая
укрупненные
модели ИТВ и РБД позволит решать задачи преобразования ИТВ к РБД в
редких частных случаях. Действительно, если СО позволит сделать вывод
о том, что пункты 1 – 4 не выполняются, тогда функции ОП или ОПР
сводятся к импорту таблиц.
Функции СО может взять на себя разработчик БД, если ИТВ
представлена незначительным количеством таблиц небольшого размера и
мощности. Тогда ОПР выродится в формирование разработчиком указаний
инструментальной СУБД по импорту данных из ИТВ в РБД, а ОП сводится
к выполнению этих указаний средствами инструментальной СУБД. Так как
ОПР и ОП представляют собой систему операторов, то оправданно
выделить операторы импортирования, соответственно ОПРи и ОПи.
Тогда в рассматриваемом частном случае справедливы следующие
выражения:
РБД = ОПи (ИТВ, СО, СП)
СП = ОПРи (СО)
Средства
импорта данных широко
описаны в литературе
инструментальным СУБД, в частности в [5]
по
В связи с этим для
рассматриваемого частного случая реализация ОПи и ОПРи не вызывает
затруднения, так как она уже в основном выполнена.
К сожалению, этот частный случай исключительно редок, но все
равно, средства импорта данных, как правило, используются во всех
случаях, и поэтому практически всегда задействованы соответствующие
средства операторов ОПи и ОПРи.
Что касается СО, то она задействуется всегда и ее разработка –
предмет специальных исследований.
Для последовательного развертывания динамической модели, если
подходить к этому вопросу формально, необходимо рассмотреть все
возможные сочетания пунктов несоответствия модели ИТВ и модели РБД.
Обозначим несоответствия ИТВ и РБД следующим образом:
НР – ИТВ нереляционные таблицы;
НН – ИТВ ненормализованные таблицы;
235
НК – в ИТВ отсутствуют ключевые поля;
НС – таблицы ИТВ не связаны между собой.
Таблица возможных сочетаний в этой системе примет вид табл. 8.2.1:
Т а б л и ц а 8.2.1
N
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
НР
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
НН
0
0
0
0
1
1
1
1
0
0
0
0
1
1
1
1
НК
0
0
1
1
0
0
1
1
0
0
1
1
0
0
1
1
НС
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
Таким образом, если подходить к задаче построения и расширения
динамической
модели
преобразования
формально,
то
необходимо
отследить 16 вариантов возможных сочетаний несоответствия моделей
ИТВ и РБД. Более того, как известно, существуют 4-е нормальные формы
и 4-е типа связей между таблицами, 2 требования к ключевым полям и
несколько требований к реляционным таблицам, которые в таблице не
отражены. В противном случае в таблице
придется отразить 214
(1048576) сочетаний. Это нереально, и поэтому в первом приближении
будем считать, что процессам нормализации, назначению ключевых полей
236
и
назначению
связей
между таблицами
соответствует
по
одному
оператору. Однако и в этом случае необходимо рассмотреть немало
сочетаний. В связи с этим нужно использовать возможности уменьшения
рассматриваемого числа сочетаний признаков несоответствия, (если
таковые будут). При этом, конечно, сокращение числа
анализируемых
сочетаний нужно выполнять исходя из реального положения вещей и не в
ущерб адекватности модели.
Рассмотрим последовательно сочетания и примем решение об их
отражении в динамической модели.
Сочетание N1.
Это сочетание признаков несовпадения моделей ИТВ и РБД по сути
свидетельствует о том, что эти модели совпадают. В связи с этим
проблема преобразования ИТВ к РБД по сути сводится к импорту данных
ИТВ в инструментальную СУБД. Ситуация такого рода уже рассмотрена.
Однако вызывает большое сомнение, что в ИТВ каким-либо образом
описаны связи между таблицами. Эта ситуация маловероятна и поэтому не
отражена в модели ИТВ. Но если такого рода ситуация случится, то
оператор ОП сводится к выполнению стандартных средств импорта в
инструментальную СУБД таблиц ИТВ ОПи, а оператор ОПР сводится к
управлению разработчиком этими средствами ОПРи.
Кроме того ОП и
ОПР реализуют формальные операции по формированию связей между
таблицами в инструментальной СУБД, которые будут дублировать связи в
ИТВ.
Сочетание N2.
Это более вероятное сочетание – таблицы в ИТВ не связаны. Данный
вариант
похож
на
предыдущий
вариант,
но
для
выполнения
преобразования ИТВ в РБД необходимо использование операторов
формирования связей ОПс и ОПРс.
Динамическая модель преобразования ИТВ в РБД примет вид рис.
8.2.7.
237
ОПи
ИТВ
СОи
ОПРи
РБД
СПи
ОПс
СОс
ОПРс
СПс
Рис. 8.2.7. Пятая операторная форма модели преобразования ИТВ к
РБД
В связи с тем, что в рассматриваемом случае таблицы ИТВ
реляционные и нормализованы, то посредством выполнения операторов
ОПи и ОПРи выполняется их экспорт в РБД, а посредством операторов
ОПс и ОПРс формируются связи между таблицами РБД. Здесь СОс –
система оценки всех возможных пар таблиц РБД на предмет наличия
связей. Так как известно 4-е типа связей между реляционными таблицами,
то оператор ОПс по сути представляет 4-е оператора ОПс1, ОПс2, ОПс3,
ОПс4, которые выполняются последовательно друг за другом. Этим
операторам ставятся в соответствие СОсi, ОПРсi и СПсi. Из соображений
компактности представления модели эти операторы на ней не отражены.
Для
данного
случая
справедливы
следующие
операторные
выражения:
РБД = ОПи (ИТВ, СОи, СПи, ОПс (РБД, СОс, СПс) )
СПи = ОПРи (СОи)
СПс = ОПРс (СОс)
Сочетание N3.
Данное сочетание признаков несовпадения моделей свидетельствует
о
том,
что
ИТВ
представлена
реляционными,
нормализованными,
связанными таблицами, но ключевые поля в этих таблицах отсутствуют. В
этом случае задача преобразования сводится к импорту ИТВ в РБД и
назначению в таблицах РБД ключевых полей.
Операторная модель преобразования ИТВ в РБД в этом случае
примет вид рис. 8.2.8.
238
ОПи
ИТВ
СОи
РБД
СПк
ОПРк
СОк
СПи
ОПРи
ОПк
Рис. 8.2.8. Шестая операторная форма модели преобразования
ИТВ к РБД
Внешне этот рисунок совпадает с предыдущим. Однако смысл двух
операторов и двух систем оценок отличается.
Здесь:
- ОПк – оператор назначения ключевых полей в таблицах РБД;
- Сок – система оценок таблиц РБД на предмет выявления и
назначения ключевых полей;
ОПРк – оператор преобразования таблиц РБД разработчиком с целью
назначения
этим
таблицам
ключевых
полей,
преобразования
осуществляются на основе использования Сок;
СПк – система преобразований РБД, инициируемая разработчиком
РБД,
которая
ориентирована
на
назначение
ключевых
полей
в
соответствии с предъявляемыми к ним требованиями.
В этом случае справедливы следующие операторные выражения.
РБД = ОПи (ИТВ, СОи, СПи, ОПк (РБД, СОк, СПк) )
СПк = ОПРк (СОк)
СПи = ОПРи (Сои)
Представив последние два выражения в предыдущее выражение,
получим:
РБД = ОПи (ИТВ, СОи, ОПРи(СОи), ОПк (РБД, СОк, ОПРк (Сок)) )
Полученное
преобразования
выражение
ИТВ
к
РБД
формально
на
основе
описывает
методику
использования введенных
операторов и систем оценки.
Сочетание N4.
239
В данном случае выполняется преобразование таблиц ИТВ, которые
являются реляционными и нормализованными, но между таблицами нет
связей, и в таблицах отсутствуют ключевые поля. В этом случае таблицы
ИТВ можно импортировать РБД, затем назначить им ключевые поля и
только после этого сформировать связи.
Связи между таблицами РБД назначаются посредством ключевых
полей.
Поэтому
выполнение
операторов
в
строго
указанной
последовательности важно.
Операторная модель преобразования ИТВ в РБД в этом случае будет
представлять совокупность
двух предыдущих моделей
и
выглядит
следующим образом (рис. 8.2.9).
ОПс
СОс
ОПи
ИТВ
СОи
ОПРи
РБД
СПи
ОПРс
СПс
ОПк
СОк
ОПРк
СПк
Рис. 8.2.9. Седьмая операторная форма модели преобразования ИТВ
к РБД
Как следует из технологии формирования связей между таблицами
РБД, связи формируются из анализа таблиц РБД и их ключевых полей.
Поэтому СОс (система оценок РБД и ключевых полей на наличие связей
между таблицами) в динамической модели преобразования ИТВ в РБД
связана с РБД и ОПк (оператором назначения ключевых полей). В данном
случае операторные выражения примут вид:
РБД = ОПи (ИТВ, СОи, СПи, ОПк, ОПс)
СПи = ОПРи (СОи)
240
СПк = ОПРк (СОк)
РБД = ОПс (РБД, СОс, СПс)
СПс = ОПРс (СОс)
Выполнив соответствующие подстановки, получим:
РБД = ОПи (ИТВ, СОи, ОПРи (СОи)), ОПк (РБД, СОк, ОПРк(СОк), ОПс
(РБД, СОс, ОПРс (СОс)))
Сочетание N5.
Это
сочетание
соответствует
реляционным
таблицам,
ненормализованным, с назначенными ключевыми полями и связями.
В связи с этим на первый взгляд достаточно выполнить импорт
таблиц в РБД из ИТВ, а затем их привести к нормальным формам,
ключевые поля назначать не надо, а связи в РБД продублировать из ИТВ.
На самом деле ситуация иная. Импортировать таблицы, коль скоро они
реляционные, действительно можно. Однако обойтись без назначения
ключевых полей и формирования связей между таблицами вряд ли
удастся. Дело в том, что в процессе нормализации таблиц могут быть
назначены
ключевые
поля
и
сформированы
новые
связи
между
таблицами. Поэтому все компоненты предыдущей модели остаются в силе
и добавляются компоненты модели, связанные с нормализацией таблиц.
Нормализация
аналогичной
со
реляционных
схемой
таблиц
назначения
выполняется
ключевых
полей
по
схеме,
и
схемой
формирования связей между таблицами и выполняется до названных мер
по преобразованию ИТВ к РБД.
Операторная модель в соответствии с вышесказанным выглядит
следующим образом (рис. 8.2.10).
241
ОПк
ОПс
СОс
ИТВ
СОи
ОПРк
РБД
ОПи
ОПРи
СОк
СПс
ОПРс
СПи
СПк
ОПн
СОн
ОПРн
СПн
Рис. 8.2.10. Восьмая операторная форма модели преобразования
ИТВ к РБД
В операторной форме преобразование ИТВ в РБД для данного случая
выглядит следующим образом.
РБД = ОПи (ИТВ, СОи, СПи, ОПи, ОПк, ОПс)
СПи = ОПРи (СОи)
РБД = ОПн (РБД, СОи, СПн)
СПн = ОПРн (СОн)
РБД = ОПк (РБД, СОк, СПк)
СПк = ОПРк (СОк)
РБД = ОПс (РБД, СОс, СПс)
СПс = ОПРс (СОс)
Сделав
соответствующие
подстановки,
получим
следующие
выражения
РБД = ОПи (ИТВ, СОи, ОПРи(СОи)), ОПн (РБД, СОн, ОПРн (СОн)),
ОПк (РБД, СОк, ОПРк (СОк)), ОПс (РБД, СОс, ОПРс (СОс)).
Это
выражение
является
элементом
формализации
методики
преобразования ИТВ к РБД для рассматриваемого частного случая.
Важно отметить, что известны 4-е основные нормальные формы. В
связи с этим оператор ОПн по сути включает в себя 4-е последовательно
выполняемых оператора ОПн1, ОПн2, ОПн3, ОПн4. Им соответствует СОнi,
242
ОПРнi, СПнi, где i = 1,4. Из соображений компактности модели эти
операторы не представлены, но их, конечно, следует иметь в виду при
реализации динамической модели.
Сочетание N6.
Данное сочетание соответствует наличию в ИТВ реляционных
ненормализованных таблиц с наличием ключевых полей в таблицах, при
этом таблицы не связаны между собой.
Этот случай напоминает предыдущий. Только в предыдущем случае
между таблицами ИТВ имелись связи. Несмотря на это, с учетом
специфики приведения таблиц к нормальным формам в динамической
модели
задействованы
операторы
формирования
связей
между
реляционными таблицами.
Таким образом, динамические модели этого и предыдущего случаев
совпадают.
Сочетание N7.
Такое сочетание признаков несовпадения моделей ИТВ и РБД
соответствует
ситуации,
когда
в
ИТВ
представлены
реляционные
ненормализованные таблицы с наличием связей и отсутствием ключей.
Такая ситуация невозможна, так как связи между таблицами
осуществляются посредством ключевых полей.
В связи с этим нет причин модифицировать динамическую модель в
данном случае.
Сочетание N8.
Данное сочетание признаков несовпадения моделей ИТВ и РБД
свидетельствует о том, что в ИТВ представлены реляционные таблицы,
которые ненормализованны, несвязанны и в них отсутствуют ключевые
поля. В связи с этим в процессе преобразования ИТВ к РБД присутствуют
все рассмотренные этапы, отраженные в предыдущей динамической
модели.
Сочетания N9 – N16.
243
Во всех оставшихся сочетаниях признаков несовпадения моделей
необходимо предусмотреть отслеживание случаев, когда таблицы в ИТВ
представлены нереляционными таблицами.
Модели ИТВ и РБД, которые задействованы в рассмотренных выше
случаях, становятся неадекватными рассматриваемым в данном случае
сочетаниям признаков.
Действительно, признаки, по которым можно отнести таблицы РБД к
реляционным моделям в модели РБД отсутствуют. Также отсутствуют в
модели ИТВ признаки, по которым можно выяснить, почему таблицы ИТВ
не являются реляционными. В связи с этим необходимо более детальное
представление моделей ИТВ и РБД, в них должны быть отражены
свойства реляционных таблиц. Такие модели предложены в главе 4.
В РБД для представления данных используются реляционные
таблицы. В большинстве случаев инструментальные СУБД просто не
позволят описать нереляционные таблицы.
В ИТВ таблицы с данными, если не предусмотрены специальные
мероприятия,
обычно
не
являются
реляционными.
Поэтому
рассмотренные сочетания признаков несоответствия моделей ИТВ и РБД
встречаются нечасто. В связи с этим сочетания 1 – 8 рассматривались с
целью
отслеживания
частных
случаев,
а
в
основном
для
последовательного расширения динамической модели преобразования
ИТВ в РБД.
Теперь в операторной модели процесса преобразования модели ИТВ
к модели РБД задействованы расширенные модели ИТВ и РБД.
Следует отметить, что рассмотренные выше этапы (нормализация,
назначение ключевых полей, формирование связей между таблицами)
могут выполняться не только на основе укрупненных моделей ИТВ и РБД,
но и на основе их расширений. Действительно, модель ИТВ не утратила
своих свойств, и модель РБД также не утратила своих свойств.
В
связи
нереляционные
с
тем,
что
таблицы
в
не
подавляющем
могут
быть
большинстве
случаев
импортированы
в
инструментальные СУБД, этап преобразования таблиц ИТВ должен
выполняться до этапа их импорта в РБД. Кроме того, следует принять во
внимание,
что
после
преобразования
нереляционных
таблиц
к
244
реляционному виду вероятнее всего может потребоваться выполнение
этапов нормализации, назначения ключевых полей и формирования
связей. Это связано с тем, что после преобразования нереляционных
таблиц они обычно меняют свою структуру. Поэтому значения сочетаний
НН,
НК,
НС
таблицы
табл.
8.2.1.
не
влияют
на
формирование
динамической модели, все эти значения можно принять единичными.
Таким
образом,
сочетания
N9
–
N16
в
динамической
модели
преобразования модели ИТВ в модель РБД отразятся одинаково.
С учетом вышесказанного операторная модель примет вид рис.
8.2.11.
ОПРр
t1
СОр
P1
СПр
P2
ОПр
t6
ОПк
t3
ОПс
t2
СОс
P3
ИТВ
P7
СОи
P9
РБД
P8
ОПи
t7
ОПРи
t9
СОк
P5
СПс
P4
ОПРс
t4
СПи
P10
СПк
P6
ОПРк
t5
ОПн
t8
СОн
P11
СПн
P12
ОПРн
t10
Рис. 8.2.11. Девятая операторная форма модели преобразования
ИТВ к РБД
К предыдущей операторной форме представления динамической
модели добавились следующие компоненты.
ИТВ = ОПр (ИТВ, СОр, СПр)
СПр = ОПРр (СОр)
Подставив эти компоненты в предыдущую операторную связь,
получим:
245
РБД = ОПи (ОПр (ИТВ, СОр, ОПР(СОр)), СОи, ОПРи(СОи), ОПн (РБД,
СОн, ОПРн (СОн)), ОПк (РБДр, СОк, ОПРк (СОк)), ОПс (РБДр, СОс, ОПРс
(СОс))
Таким образом, построена динамическая модель преобразования
ИТВ в РБД, которая учитывает все возможные сочетания признаков
несовпадения моделей ИТВ и РБД.
Эта модель отражает методику проектирования реляционных БД на
основе использования существующей информации табличного вида. С
другой стороны она позволяет сделать заключение о необходимом составе
операторов преобразования реализуемых программными средствами
(ОП), операторов преобразования, реализуемых разработчиком (ОПР),
систем оценки текущего состояния дел в процессе преобразования (СО),
систем преобразований, назначаемых разработчиком (СП). Из рис.8.2.11.
можно сделать вывод о минимальном составе операторов, которые
необходимо реализовать в форме средств, алгоритмов и методов для
обеспечения методики проектирования РБД на основе ИТВ. К ним
относятся операторы перечисленные ниже.
ОП = ОПр, ОПи, ОПн, ОПк, ОПс
ОПР = ОПРр, ОПРи, ОПРн, ОПРк, ОПРс
СО = СОр, СОи, СОн, СОк, СОс
СП = СПр, СПи, СПн, СПк, СПс
Как следует из сказанного выше об этапах нормализации, назначения
ключевых полей и формировании связей между таблицами необходимо
реализовать еще ряд следующих операторов.
ОПн = ОПн1, ОПн2, ОПн3, ОПн4
ОПРн = ОПРн1, ОПРн2, ОПРн3, ОПРн4
СОн = СОн1, СОн2, СОн3, СОн4
СПн = СПн1, СПн2, СПн3, СПн4
ОПс = ОПс1, ОПс2, ОПс3, ОПс4
ОПРс = ОПРс1, ОПРс2, ОПРс3, ОПРс4
СОс = СОс1, СОс2, СОс3, СОс4
СПс = СПс1, СПс2, СПс3, СПс4
246
Кроме того, к реляционным таблицам предъявляется ряд требований,
которые
будут
детально
проанализированы
при
разработке
соответствующих методов и средств преобразования ИТВ. В связи с этим
ОПр, ОПРр, Сор, СПр по-видимому будут представлены несколькими
элементами. Этот вопрос рассмотрен будет позже.
Что касается средств назначения ключевых полей ОПк, ОПРк, СОк,
СПк, то они, вероятно, не будут детализированы, так как к ключевым полям
предъявляются
взаимозависимые
требования
–
уникальность
и
минимальность.
До разработки динамической модели преобразования
ИТВ в РБД
методика преобразования представлялась чисто интуитивно. Реализация
методов, алгоритмов и средств преобразования ИТВ в РБД на основе
интуитивной методики чревато ошибками, как минимум по трем причинам.
Во-первых, последовательность использования разрабатываемых методов
должна
быть
взаимосвязь
регламентированной,
между
компонентами
а
не
произвольной.
системы
Во-вторых,
преобразования
при
интуитивном представлении методики и ее вербальном описании не
очевидна. В третьих, неформально затруднительно в полном объеме
определить состав необходимых компонент системы преобразования.
Все перечисленные операторы и системы оценок представляют собой
методы, алгоритмы и средства, которые необходимо разработать. Их
разработке посвящены следующие главы.
Построенная динамическая модель преобразования ИТВ в РБД
обладает еще одним ценным качеством. Она может быть использована
для
исследования
характеристик
системы
преобразования
до
ее
реализации, для исключения принципиальных ошибок в системе на
начальных этапах ее реализации. Для достижения этих целей оправданно
использование математического аппарата, который ориентирован на
решение названных задач.
8.3. Исследование методики преобразования информации
табличного вида в реляционные базы данных
247
Преобразование
ИТВ
в
РБД,
как
видно
из
вышесказанного,
представляет собой сложный итерационный процесс, включающий в себя
ряд шагов от преобразования таблиц ИТВ к реляционному виду до
построения РБД, удовлетворяющей требованиям непротиворечивости,
минимальности,
результатов
отдельные
целостности.
В
преобразования,
а
человеко–машинные
выполняться параллельно
зависимости
также
целей
процедуры
от
промежуточных
проектирования
могут
РБД
повторяться
и
Так, например, в процессе нормализации
таблиц ИТВ могут назначаться ключевые поля и формироваться связи
между
таблицами.
Эти
действия
в
соответствии
с
методикой
преобразования ИТВ к РБД реализуются и как самостоятельные этапы
проектирования РБД на основе ИТВ, которые непосредственно не связаны
с этапом нормализации таблиц ИТВ. Для исследования характеристик
методики
автоматизированного
проектирования
РБД
на
основе
использования существующей информации табличного вида, а также для
исключения принципиальных ошибок в системах проектирования на ранних
этапах
ее
разработки
оправданно
создание
формальной
модели
интерактивного взаимодействия разработчика и системы для совместного
решения проектных задач. Также оправданно использование для этих
целей специализированного математического аппарата.
Задачами
исследования,
решение
которых
должна
обеспечить
модель и математический аппарат, являются выявление и исключение
ситуаций,
приводящих
взаимодействия,
к
выявление
зацикливанию
и
процесса
исключение
интерактивного
недостижимых
ситуаций
интерактивного взаимодействия, анализ функциональной полноты проекта
системы, предварительный анализ временных характеристик системы. При
этом модель должна отражать асинхронные процессы, предоставлять
возможность моделирования протекания параллельных процессов и
абстрагироваться от разделения ролей между разработчиком БД, между
системой специальных содержательных вопросов и между операциями
ввода
–
вывода.
В
качестве
аппарата
формализации,
полностью
удовлетворяющего сформулированным требованиям, выбран аппарат
сетей Петри. Согласно [17] сети Петри ”идеально
удовлетворяют
требованиям представления интерактивных процессов”.
248
В связи со значительным объемом разрабатываемых средств
детальное описание и исследование всех человеко-машинных процессов,
возможных
при
решении
задач
преобразования
ИТВ
к
РБД,
затруднительно. Однако задача упрощается в связи с существованием
однотипных процессов и процессов с небольшим числом состояний,
исследование которых не представляет интереса. В частности, вероятно,
не
следует
включать
в
модель
все
4-е
методики
нормализации
реляционных таблиц, все 4-е методики формирования связей между
реляционными таблицами.
Начальный уровень представления интерактивного взаимодействия в
процессе преобразования ИТВ к РБД в форме сети Петри разработан на
основе динамической модели (рис. 8.2.11).
t2
t3
t4
t5
t1
P1
P2
P3
t6
P5
P6
P4
t8
t7
P7
P8
t9
P9
P11
P10
t10
0
P12
Рис. 8.3.1. Сеть Петри соответствующая динамической модели
преобразования ИТВ в РБД
На рис. 8.3.1 приведена сеть Петри, соответствующая динамической
модели. Модели ИТВр, модели РБДр, СО, СП ставятся в соответствие
положения сети Р. Операторам ОП, ОПР ставятся в соответствие
переходы
сети
t.
Имена
положений
и
переходов
сети
Петри
соответствуют номерам компонент динамической модели.
249
Сеть Петри представляется тройкой P =  Р, Т, Р, где
Р – множество положений;
Т – множество переходов;
Н – множество маркеров.
С
помощью
построенной
модели
можно
выполнить
анализ
устойчивости сети, или анализ способности отражать реальные процессы
интерактивного взаимодействия разработчика и автоматизированных
средств в ходе проектирования РБД на основе существующей ИТВ.
Сеть Петри является устойчивой, если она имеет потоковое
назначение i  0 для каждого T  ti, где потоковое назначение – это
функция, которая приписывает каждому переходу T  ti положительное
рациональное число, называемое ее потоком [18]. Потоковое назначение
для сети Петри должно удовлетворять требованиям:
- каждая дуга переносит поток, равный потоку перехода, к которому
присоединена эта дуга;
- для каждого положения сумма потоков входных дуг должна
равняться сумме потоков выходных дуг.
Пусть для каждого перехода сети рис.
назначен поток i. Для
каждого положения Pi запишем уравнения потоков, которые не должны
противоречить друг другу, если данная сеть устойчива. Уравнения сведены
в таблицу табл. 8.3.1.
Т а б л и ц а 8.3.1
t1
Р1
Р2
Р3
Р4
Р5
Р6
Р7
Р8
Р9
Р10
Р11
Р12
t2
t3
t4
t5
-1
+1
t6
t7
t8
t9
t10
-6 +6
-6
+2 -2
-2
+3
+3 -3
-3
-4
+4
-5
+5
+8
-6 +6
-2
-3
-7
+7
-7 +7
-7
-8 +8
-9
+9
-8 +8
-8
-10
+10
250
=0
=0
=0
=0
=0
=0
=0
=0
=0
=0
=0
=0
Перепишем полученные уравнения в более компактной форме:
- 1 - 6 + 6 = 0
(1)
+ 1 - 6 = 0
(2)
+ 2 - 2 + 3 - 4 = 0
(3)
- 2 + 4 = 0
(4)
+ 3 - 3 + 8 - 5 = 0
(5)
- 3 + 5 = 0
(6)
- 7 - 6 + 6 = 0
(7)
- 2 - 3 + 7 + 8 - 8 = 0
(8)
- 7 + 7 - 9 = 0
(9)
- 7 + 9 = 0
(10)
- 8 + 8 - 10 = 0
(11)
- 8 + 10 = 0
(12)
Преобразовав уравнения, получим:
1 = 0
(1)
1 = 6
(2)
3 = 4
(3)
2 = 4
(4)
8 = 5
(5)
3 = 5
(6)
7 = 0
(7)
7 = 2 + 3
(8)
9 = 0
(9)
7 = 9
(10)
10 = 0
(11)
8 = 10
(12)
Выполнив соответствующие подстановки, получим:
1 = 2 = 3 = 4 = 5 = 6 = 7 = 8 = 9 = 10 = 0,
То есть все потоковые значения нулевые. Это противоречит условию
устойчивости системы.
251
В связи с этим рассмотренная сеть не является устойчивой, а,
следовательно,
процессы,
ею
описываемые,
также
являются
неустойчивыми.
Поэтому
модель
нуждается
в
модификации,
иначе
методика,
построенная на базе полученной модели, вероятно, будет содержать
ошибки. Как видно из системы уравнений, нулевые потоковые значения,
которые привели к нулевым потоковым значениям для всех положений,
связаны с положениями Р1, Р7, Р9, Р11. Естественно предположить то, что
если
исправить
ситуацию
для
перечисленных
положений,
то
она
исправится и для сети в целом.
Вернемся к прообразам положений
Р1, Р7, Р9, Р11 и попытаемся
выяснить существо ошибки.
Р1 отражает в модели СОр систему оценки соответствия информации
табличного вида требованиям, предъявляемым к реляционным таблицам.
Из рис. 8.2.11 видно, что СОр по выходам связана с двумя операторами, а
по входам – с одним (связь с ИТВ не является связью с оператором). Из
связи такого рода можно сделать ложный вывод о том, что СОр получается
непосредственно из ИТВ без всяких преобразований. На самом деле это
не так. Необходимо выполнить ряд оценок, что сопряжено с действиями и
соответственно
с
операторами.
Поэтому
в
динамической
модели
преобразования введем соответствующий оператор, а в сети Петри
соответствующий переход t11. (Этот оператор и другие компоненты
обновленной динамической модели отражены на рис. 8.3.4, который
построен после выполнения всех необходимых манипуляций с сетью
Петри).
Прообразом положения Р7 является ИТВ, прообразом положения Р9
является СОи (система оценки импорта). Эти компоненты модели связаны
между собой, поэтому вначале попытаемся нормализовать ситуацию с
одной из компонент, а другую рассмотрим позже. СОи по входу связана с
одним оператором ОПи, а по выходу – с двумя операторами ОПРи и ОПи.
Имеется связь между ИТВ и СОи по входу, но эта связь предполагает, что
оценки необходимых действий по импорту выполняются без участия
специальных средств. На самом деле это не так. В процессе импорта
задействуются
специализированные
средства
СУБД,
использование
252
которых не отражено. В связи с этим в операторную модель рис. 8.3.4
необходимо добавить дополнительный оператор ОСОи между ИТВ и СОИ,
а в модель на основе сети Петри добавим соответствующий переход t12.
Прообразом
положения
Р11
является
СОн
(система
оценки
нормализации таблиц РБД). СОн по входу связана с одним оператором
ОПн, а по выходу с двумя операторами ОПРн и ОПн. Это и нарушает
потоковое равновесие. СОн связана по входу непосредственно с РБД. И
если бы они были связаны посредством оператора, то фрагмент модели,
связанной с СОн, не привносил бы отрицательную составляющую в
устойчивость сети. И действительно, в динамической модели ошибочно
отражено
состояние
процесса
оценки
соответствия
таблиц
РБД
нормальным формам. Это безусловно действие и даже систему действий,
которая в динамической модели должна быть отражена хотя бы одним
оператором. В связи с этим в операторную модель рис. 8.3.4 добавим
оператор ОСОн, а в модель, полученную на основе сети Петри,
соответствующий переход t13.
В
результате
выполнения
модификаций
получим
сеть
Петри,
представленную на рис. 8.3.2.
t2
t3
t4
t5
t1
P1
P2
P3
P6
P4
t6
t8
t7
P7
P5
P8
t13
t12
t9
t11
P9
P10
P11
t10
0
P12
Рис 8.3.2. Первая модификация сети Петри
253
Несмотря на выявление и исключение теперь уже очевидных ошибок,
полной уверенности в том, что полученная сеть стала устойчивой, нет.
Дело в том, что в сеть добавлены 3-и новых перехода.
Тем самым
изменено потоковое назначение сети не только для рассмотренных
положений, но и для положений, связанных с ними через переходы.
Поэтому повторно запишем уравнения потоков для обновленной сети
(табл. 8.3.2).
Т а б л и ц а 8.3.2
t1
t2
t3
t4 t5
t6
t7
t8
t9 t10 t11 t12 t13
Р1 -1
+11
=0
-6 +6
Р2 +1
=0
-6
Р3
=0
+2 -2 +3 -4
Р4
=0
-2
+4
Р5
=0
+3 -3
-5
+8
Р6
=0
-3
+5
Р7
-11 -12
=0
-6 +6 -7
Р8
-13 =0
-2
-3
+7 -8 +8
Р9
+12
=0
-7 +7
-9
Р10
=0
-7
+9
Р11
=0
-8 +8
-10
+13
Р12
=0
-8
+10
Напишем уравнения в более компактной форме.
- 1 - 6 + 6 + 11 = 0
(1)
+ 1 - 6 = 0
(2)
+ 2 - 2 + 3 - 4 = 0
(3)
- 2 + 4 = 0
(4)
+ 3 - 3 + 8 - 5 = 0
(5)
- 3 + 5 = 0
(6)
- 7 - 6 + 6 - 11 - 12 = 0
(7)
- 2 - 3 + 7 + 8 - 8 - 13 = 0 (8)
254
- 7 + 7 - 9 + 12 = 0
(9)
- 7 + 9 = 0
(10)
- 8 + 8 - 10 + 13 = 0
(11)
- 8 + 10 = 0
(12)
Анализ уравнений позволяет сделать вывод о том, что ситуация
существенно улучшилась. Однако осталось еще два противоречивых
уравнения - уравнение 7 и уравнение 8. В уравнении 7 имеет место 4-е
исходящих потока и 1 – входящий. В уравнении 8 входит 4-е потока и
выходят 2 потока – явный дисбаланс.
Выражение 7 записано для положения 7 а положение 7 соответствует
компоненте ИТВ
в динамической модели (рис 2.2.11),
Анализируя
окружение ИТВ в динамической модели, можно сделать вывод о том, что
только один оператор, непосредственно связанный с ИТВ имеет с ней
обратную связь. А между тем, преобразование ИТВ – итерационный
процесс и обратные связи с операторами, непосредственно работающими
с ИТВ по всей видимости необходимы. Сформируем эти связи в сетевой и
динамической моделях. Модифицированная сетевая модель приведена на
рис.8.3.3, модифицированная операторная модель – на рис.8.3.4.
255
t2
t3
t4
t5
t1
P1
P2
P3
P6
P4
P5
t6
t7
P7
t11
t8
P8
t13
t12
t9
P9
P11
P10
t10
0
P12
Рис. 8.3.3. Вторая модификация сети Петри
Для
полученной
сети
запишем
уравнения
потоков,
которые
представлены в табл. 8.3.3.
Т а б л и ц а 8.3.3
t1
t2
t3
t4 t5
t6
t7
t8
t9 t10 t11
t12
t13
Р1 - 1
+11
- 6 +6
Р2 +1
- 6
Р3
+2 - 2 +3 - 4
Р4
- 2
+4
Р5
+3 - 3
-5
+8
Р6
- 3
+5
Р7
-11+11 -12+12
- 6 +6 - 7 +7
Р8
-13+13
- 2 - 3 +3
+7 - 8 +8
Р9
+12
- 7 +7
- 9
Р10
- 7
+9
Р11
- 8 +8
- 10
+13
Р12
- 8
+10
256
=0
=0
=0
=0
=0
=0
=0
=0
=0
=0
=0
=0
Уравнение потоков для положения Р7 теперь выглядит следующим
образом:
- 6 + 6 - 6 + 7 - 11 + 11- 12 + 12 = 0,
или 0 = 0.
Таким образом, уравнение превратилось в тождество, и противоречий
нет.
Уравнение потоков для положения Р8 теперь выглядит следующим
образом:
- 2 - 3 + 3 + 7 + 8 - 8 - 13 + 13 = 0, или 7 = 2.
Противоречия нет.
В результате выполненных преобразований исходной сети Петри
получена устойчивая сеть (рис.8.3.3).Функционирование такой сети не
приведет к коллизиям перемещения информационных потоков. А так как
полученная сеть взаимно однозначно соответствует динамической модели
(рис. 8.3.4), то модель методики преобразования ИТВ к РБД является
устойчивой, что исключает принципиальные ошибки в методике на ранних
этапах ее разработки и реализации.
ОПРр
t1
СОр
P1
СПр
P2
СОс
P3
ИТВ
P7
ОПр
t6
ОСОр
t11
ОПк
t3
ОПс
t2
ОСОи
t12
СОи
P9
СОк
P5
СПс
P4
ОПРс
t4
РБД
P8
ОПи
t7
ОПРи
t9
СПи
P10
СПк
P6
ОПРк
t5
СПн
P12
ОПн
t8
ОСОн
t13
ОПРн
t10
СОн
P11
Рис. 8.3.4. Динамическая модель преобразования ИТВ к РБД
257
Для того, чтобы в полной мере удостовериться в том, что полученная
сеть удовлетворяет требованиям к классической модели, построенной на
основе сети Петри, выполним ее визуальный анализ. Предварительно
напомним определение классической сети Петри – это двудольный
ориентированный граф с разметкой положений. Двудольный граф – это
граф, в котором задействованы вершины двух типов, причем вершины
одного типа связаны с вершинами другого типа. В нашем случае
положения должны быть связаны посредством ориентированных связей с
переходами и наоборот.
После пошагового построения сети Петри синхронно с пошаговым
формированием динамической модели преобразования ИТВ в РБД
оказалось, что положения Р8 и Р9 связаны непосредственно между собой,
что противоречит определению сети Петри. В связи с этим возможны
следующие ситуации:
- эта связь лишняя и не отражает реальные процессы;
- эта связь необходима, но ее надо реализовать посредством
перехода;
- динамическая модель не может быть в полном объеме отображена
посредством классической сети Петри.
Последняя ситуация хоть и несколько неприятна, но разрешима.
Можно
задействовать
аппарат
модифицированных
сетей
Петри
и
использовать соответствующие средства исследования модели или
выполнить декомпозицию таким образом, чтобы полученные подсети
удовлетворяли
требованиям
к
классическим
сетям
Петри.
Затем
выполнять исследования модели по частям. Прежде, чем выполнять эти
манипуляции, рассмотрим две оставшиеся ситуации.
Является ли данная связь лишней? Из прототипа сетевой модели
следует, что это - обратная связь, которая сформирована между РБД и
СОи (системы оценок импорта). Эта связь задействована на начальных
этапах построения динамической модели, и это косвенно свидетельствует
о ее необходимости. Действительно, СОи должна не только выполнить
анализ мероприятий, которые необходимо выполнить в процессе импорта
таблиц ИТВ в таблицы РБД, но и должна выполнить анализ успешности
258
выполнения мероприятий по импорту данных. Этот анализ выполняется во
многом на основе данных, полученных в РБД. Поэтому связь между РБД и
СОи необходима.
Нужен ли специальный переход (оператор) для реализации данной
связи. Оператор для выполнения действий над импортированными
таблицами в РБД по сути отчасти реализован в самой РБД. В частности, в
процессе импорта формируются таблицы ошибочных записей. Это и
привело к тому, что в динамической модели явно он не указан, но он есть.
Более того действий инструментальной СУБД может быть недостаточно
для формирования СОи. Вероятнее всего, потребуются специальные
методы, средства и усилия разработчика.
В связи с вышесказанным в операторную модель вводится оператор
ОПи, а в сеть Петри соответствующий переход. Таким образом, анализ
несоответствия
сетевой
модели
и
классической
помог
выявить
недостающую компоненту разрабатываемой системы.
Так как сформирован дополнительный переход t14, то вероятно
нарушился баланс потоков для положений, которые связаны посредством
нового перехода.
Новое уравнение потоков для Р8:
7 + 8 + 13 + 3 = 2 + 3 + 8 + 13 + 14 или
7 = 2 + 14
Это
противоречивое
уравнение.
Поэтому
необходимо
проанализировать Р8 на отсутствие входных связей, которые имеют
физический смысл.
Положение Р8 имеет обратные связи с переходами t3, t8 и t13,
которым соответствуют операторы ОПк, ОПн, ОСОн. Это операторы,
которые
непосредственно
связаны
с
РБД
и
реализуют
операции
назначения ключевых полей, операции нормализации таблиц РБД. Кроме
названных операторов непосредственно с РБД связан оператор ОПс –
оператор, обеспечивающий формирование связей между реляционными
таблицами. Но этот оператор не имеет обратной связи с РБД и это явное
упущение,
так
как
процесс
назначения
связей
между
таблицами
итерационный. Поэтому между ОПс и РБД формируется двунаправленная
259
связь, которая и отражена в сети (рис. 2.3.3) ОПс соответствует переход
t2.
Запишем уравнения потоков для Р8 с учетом дополнительного потока:
2 + 7 + 8 + 13 + 3 = 2 + 3 + 8 + 13 + 14 или
7 = 14
Противоречий нет.
Новое уравнение потоков для положения Р9 выглядит следующим
образом:
14 + 12 + 7 = 7 + 9 или
14 + 12 = 9
Это уравнение противоречивое.
(Из уравнения (9) следует, что 12 = 9 и тогда 14 = 0)
Очень вероятно, что для положения Р9 ошибочно не сформирована
необходимая связь, которая имеет физический смысл. Так как переход Р9
соответствует СОи (система оценки результатов импорта), то необходимо
проанализировать связанные с ней операторы на предмет наличия
входных связей. Можно предположить то, что посредством оператора
ОСОи не только формируется система оценок результатов импорта на
основе данных ИТВ, но и наоборот, посредством оператора ОСОи на
основе СОи выполняется модификация ИТВ с целью ее подготовки для
реализации успешного импорта таблиц ИТВ. По сути так оно и есть, тем
более, что между ОСОи и ИТВ имеется двунаправленная связь. Поэтому в
сети отразим обратную связь между Р9 и t12. Эту же связь отразим на
динамической модели.
Выполним проверку баланса потоков для положения Р9:
14 + 12 + 7 = 7 + 9 + 12 или
14 = 9
Противоречий нет.
Таким образом, на основе анализа опраторной модели, анализа
вариантов
сети
Петри
построена
устойчивая
сеть
Петри,
удовлетворяющая классическим требованиям.
Может создаться ложное впечатление о том, что динамическая
модель подгонялась под требования используемого математического
260
аппарата. На самом деле наоборот, математический аппарат сетей Петри
позволил выявить коллизии в динамической модели, которая построена
эмпирическим путем и не была гарантирована от ошибок. В результате
выполненных преобразований, с одной стороны, получена операторная
модель
методики
преобразования
ИТВ
к
РБД,
свободная
от
принципиальных ошибок, а с другой стороны, получено формальное
описание этой модели, которое может быть использовано для ее
дальнейшего исследования и улучшения. В связи с тем, что в формальном
описании модели выявлены и исключены принципиальные ошибки, то оно
является адекватным реальному моделируемому процессу.
Даже на данной стадии описания и исследования операторной
модели она представляет ценность. Операторная модель позволяет
сделать вывод:
- о необходимом составе операторов (методов, алгоритмов и
средств),
которые
необходимо
разработать
для
реализации
полнофункциональной системы;
- о необходимом составе системы оценок или функций (методов,
алгоритмов и средств), которые необходимо разработать для реализации
полнофункциональной системы проектирования;
- о связях между методами и средствами в разрабатываемой системе.
Кроме того, операторная модель иллюстрирует порядок и правила
использования методов и средств задействованных в процессе решении
задач преобразования ИТВ в РБД в разрабатываемой системе.
Что
касается
динамики
функционирования
сети
Петри
и
соответствующей ей операторной модели, она в данном случае отражена
лишь отчасти и сводится к ориентации информационных потоков.
Их можно визуально отслеживать и в результате делать необходимые
умозаключения. Однако, для более глубокого анализа динамических
свойств модели и соответствующего объекта исследования оправданно
использование специальных средств – маркерных сетей Петри, которые
рассмотрены ниже.
261
8.4. Исследование динамических свойств функционирования
системы.
Динамику
функционирования
системы
можно
моделировать
перемещением маркеров в сети в соответствии с правилами перехода:
М' (Р) = М (Р) – Р (ti) + Н (ti),
где М (Р) = (М (Р1), М (Р2), …, М (РN)) - разметка сети.
Рассмотрим процесс, описываемый сетью рис.8.3.3 в динамике.
Предварительно отметим, что положения Р7 и Р8 соответствуют ИТВ
и РБД, поэтому обладают особым статусом.
Инициация всего процесса преобразования начинается с ИТВ и
осуществляется разработчиком. Кроме того, по достижении положения Р8
соответствующего РБД разработчик может инициировать процесс и в
положении Р8. На сетевой модели это отображается маркером, который
изначально располагается в положении Р7. По мере необходимости в Р7
может добавляться маркер. По достижении маркером положения Р8, также
в это положение может быть при необходимости добавлен маркер. Это
отражает реальные прерогативы разработчика. Собственно процесс
моделирования
функционирования
системы
посредством
маркеров
состоит в следующем. Маркеры перемещаются по сети из положения в
положение. При этом маркеры могут быть перемещены лишь в том случае,
если сработает входной переход. А входной переход срабатывает, когда
во всех положениях, которые связаны с этим переходом по выходу,
имеются маркеры. В качестве примера рассмотрим рисунок 8.4.1.
Р1
t1
Р3
Р2
а
262
Р1
t1
Р3
Р2
б
Рис 8.4.1. Иллюстрация срабатывания перехода
Переход t1 не сработает, пока в положении Р1 и Р2 не окажутся
маркеры. Когда маркер попадают в положения Р1 и Р2, возможно
срабатывание перехода t1. При этом маркеры из положений Р1 и Р2
удаляются
и
один
маркер
разместится
в
положении
Р3,
что
и
проиллюстрировано на рис. 8.4.1,а и рис. 8.4.1,б.
Если данное правило поставить в соответствие реальным процессам,
которые моделируются, то в нашем случае оператор выполняется лишь
тогда, когда все данные, которые необходимы для его выполнения,
имеются в наличии.
Перемещение маркеров по сети позволит сделать заключение о том,
сеть
является
живой,
т.е.
есть
ли
принципиальная
возможность
срабатывания всех переходов. Позволит сделать вывод является сеть
достижимой, т.е. достижимы ли все положения сети.
Проверка построенной сети представляет особый интерес, так как
половина переходов в ней имеют больше одного входа, причем в основном
они имеют по 3 входа. Возможность их срабатывания далеко неочевидна.
Для визуального отображения перемещения маркеров по сети с
демонстрацией всех возможных состояний сети потребуется около 50-ти
рисунков подобных рис. только с различной разметкой положений. В связи
со значительным объемом информации представленной в виде рисунков и
плохой обозримости этой информации воспользуемся представлением
разметки сети в виде кортежей. В этом случае порядковый номер в
кортеже
соответствует
положении.
Начальной
количеству
маркеров
маркировке
сети
в
соответствующем
соответствует
следующая
разметка сети:
М1 = 000000100000
263
Срабатывание перехода t11 приведет к очередной разметке сети
М2 = 100000100000
Для удобства записи разметок сети и упрощения последующего их
анализа представим последовательность разметок в виде таблицы. В
настоящее время разработан ряд программных систем, которые позволяют
выполнять автоматизированное описание и исследование моделей на
основе сетей Петри. В частности разработка Н. Анисимова, А. Коваленко,
П. Постунальского и А Симанчука ”Compositional Petri Nets Environment”,
разработка Дубинина В.Н. “Комплекс программ "ПЕТРИС" для построения
и исследования сетей Петри” [19] и др. Несмотря на это, таблица
построена вручную. Это обусловлено, во-первых, необходимостью полной
уверенности в достоверности результатов формирования разметок, а вовторых,
необходимостью
отражения
специфических
свойств
2-х
положений, которые затруднительно отразить в программных системах.
Возможные маркировки сети (рис 8.2.3) отражены в табл. 8.4.1.
Т а б л и ц а 8.4.1
N
Р1
Р2
Р3
Р4
Р5
Р6
Р7
Р8
Р9
Р10
Р11
Р12
Т
1
0
0
0
0
0
0
1
0
0
0
0
0
t0
2
1
0
0
0
0
0
1
0
0
0
0
0
t11
3
0
1
0
0
0
0
1
0
0
0
0
0
t1
4
1
1
0
0
0
1
0
0
0
0
0
0
t11
5
1
0
0
0
0
0
0
0
0
0
0
0
t6
6
0
1
0
0
0
0
0
0
0
0
0
0
t1
7
0
1
0
0
0
0
1
0
0
0
0
0
t0
8
0
0
0
0
0
0
1
0
0
0
0
0
t00
9
0
0
0
0
0
0
0
0
1
0
0
0
t14
10
0
0
0
0
0
0
1
0
1
0
0
0
t0
11
0
0
0
0
0
0
0
0
1
0
0
0
t12
12
0
0
0
0
0
0
0
0
0
1
0
0
t9
13
0
0
0
0
0
0
1
0
0
1
0
0
t0
14
0
0
0
0
0
0
1
1
0
1
0
0
t00
15
0
0
0
0
0
0
1
0
1
1
0
0
t14
16
0
0
0
0
0
0
1
1
0
0
0
0
t7
264
17
0
0
0
0
0
0
1
0
1
0
0
0
t14
18
0
0
0
0
0
0
0
0
1
0
0
0
t12
19
0
0
0
0
0
0
0
0
0
1
0
0
t9
20
0
0
0
0
0
0
1
0
0
1
0
0
t0
21
0
0
0
0
0
0
1
1
0
1
0
0
t00
22
0
0
0
0
0
0
1
0
1
1
0
0
t14
23
0
0
0
0
0
0
1
1
0
0
0
0
t7
24
0
0
0
0
0
0
1
0
0
0
1
0
t13
25
0
0
0
0
0
0
1
0
0
0
0
1
t10
26
0
0
0
0
0
0
1
1
0
0
0
1
t00
27
0
0
0
0
0
0
1
0
0
0
1
1
t13
28
0
0
0
0
0
0
1
1
0
0
1
1
t00
29
0
0
0
0
1
0
1
0
0
0
0
0
t8
30
0
0
0
0
0
1
1
0
0
0
0
0
t5
31
0
0
0
0
0
1
1
1
0
0
0
0
t00
32
0
0
0
0
0
1
1
1
0
0
1
0
t13
33
0
0
0
0
0
1
1
1
0
0
0
1
t10
34
0
0
0
0
0
1
1
0
0
0
1
1
t13
35
0
0
0
0
0
1
1
1
0
0
1
1
t00
N
Р1
Р2
Р3
Р4
Р5
Р6
Р7
Р8
Р9
Р10
Р11
Р12
Т
36
0
0
0
0
1
1
1
0
0
0
0
0
t8
37
0
0
0
0
1
1
1
1
0
0
0
0
t00
38
0
0
1
0
0
0
1
0
0
0
0
0
t3
39
0
0
0
1
0
0
1
0
0
0
0
0
t4
40
0
0
0
1
0
0
1
1
0
0
0
0
t00
41
0
0
0
1
0
0
1
1
0
0
1
0
t13
42
0
0
0
1
0
0
1
1
0
0
0
1
t10
43
0
0
0
1
0
0
1
1
0
0
1
1
t13
44
0
0
0
1
1
0
1
0
0
0
0
0
t8
45
0
0
0
1
0
1
1
0
0
0
0
0
t5
46
0
0
0
1
0
1
1
1
0
0
0
0
t00
265
47
0
0
0
1
0
1
1
1
0
0
1
0
t13
48
0
0
0
1
0
1
1
1
0
0
0
1
t10
49
0
0
0
1
0
1
1
1
0
0
1
1
t13
50
0
0
0
1
1
1
1
0
0
0
0
0
t8
51
0
0
0
1
1
1
1
1
0
0
0
0
t00
52
0
0
1
1
0
0
1
0
0
0
0
0
t3
53
0
0
1
1
0
0
1
1
0
0
0
0
t00
54
0
0
1
0
0
0
1
0
0
0
0
0
t2
В последнем столбце указан переход, срабатывание которого
привело
к
соответствующей
разметке.
Виртуальное
перемещение
маркеров по сети интуитивно осуществлялось таким образом, чтобы
достич все положения и пройти все переходы. Это еще один довод в
пользу
использования
в
данном
случае
формирования
последовательности разметок сети вручную.
После просмотра последнего столбца можно сделать вывод о том,
что все переходы сработали, причем многие из них неоднократно. Это
свидетельствует о том, что полученная сеть живая, а значит и процесс
соответствующей сети живой. Т.е. имеется принципиальная возможность
выполнения всех операторов динамической модели. Следует обратить
внимание на то, что введено два фиктивных перехода t0 и t00, которые
отражают специфические особенности положений Р7 и Р8.
Единственный переход, который не представлен в последнем столбце
– это переход t2. Из маркировки N39 следует, что достижимо положение
Р3, из маркировки N40 следует, что достижимо положение Р4. Положение
Р8 достижимо по определению, т.к. оно обладает особым статусом. В
связи с этим, все положения, которые связаны по выходам с переходом t2,
достижимы и совместимы. В связи с этим имеется принципиальная
возможность перехода t2. Последовательность маркировок, которые
приведут к срабатыванию перехода t2, не представлены из соображений
минимизации записей таблицы. Важно отметит, что сработали критичные
переходы t2, t3, t6, t7, t8, t12, t13, переходы, которые имеют несколько
входов.
266
После просмотра столбцов таблицы с заголовками Р1 – Р12 делается
вывод о том, что все положения сети достижимы - в каждом столбце
имеется хотя бы одно единичное значение.
Таким образом, анализируемая сеть Петри является достижимой, а
значит
и
все
состояния
соответствующего
объекта
исследования
достижимы, исходя из логики и динамики функционирования модели
процесса преобразования ИТВ в РБД.
Как видно из таблицы, многие маркировки, представленные в таблице
совпадают. Совпадают маркировки с номерами N3 и N8; N11 и N18; N17 и
N24. Таким образом, динамика функционирования сети свидетельствует о
циклических процессах, имеющих место при функционировании сети, а
следовательно
свидетельствует
о
циклических
процессах,
которые
присутствуют в процессе проектирования РБД на основе использования
ИТВ. Это соответствует действительности, так как процесс проектирования
РБД итерационный.
В принципе процесс формирования очередных маркировок может
осуществляться до бесконечности, так как все положения сети имеют
непосредственную или опосредованную обратную связь.
В
реальной
ситуации
процесс
завершается
при
достижении
необходимого результата. Принципиальная возможность срабатывания
всех переходов свидетельствует о еще одном свойстве сети – отсутствие
тупиковых положений. Это в свою очередь свидетельствует о том, что в
объекте моделирования отсутствуют тупиковые состояния.
Из анализа таблицы следует, что анализируемая сеть является
безопасной, т.е. выполняется условие:
 М (Р)  R (Р)  Рi  М (Рi)  1,
где i = 1, n; n = Р; R (Р) разметки сети.
Из этого следует, что моделируемая система функционирует в
стационарном режиме.
Резюмируя сказанное выше, можно сделать вывод о том, что
разработанная сетевая модель обладает следующими свойствами. Она
устойчивая, живая, достижимая, безопасная, в ней отсутствуют тупиковые
положения. Эта сеть соответствует реальному процессу преобразования
267
ИТВ в РБД, и таким образом динамическая модель преобразования
обладает теми же свойствами. Таким образом динамическая модель
свободна от принципиальных ошибок и может быть использована в
качестве основы для разработки и реализации методики проектирования
РБД с использованием существующей информации табличного вида, а
также в качестве основы для разработки соответствующих методов,
алгоритмов и средств, комплексное использование которых составят
методику.
8.5. Исследование временных свойств системы.
Выполнить
исчерпывающий анализ временных свойств процесса
интерактивного проектирования РБД на базе существующей ИТВ без
реализации необходимых методов, алгоритмов и средств невозможно.
Однако, вполне реально выполнить предварительные оценки временных
характеристик динамической модели, тем более, что отдельные средства
преобразования таблиц уже реализованы в инструментальных СУБД, а
также имеются экспертные оценки выполнения большинства алгоритмов,
которые предполагается задействовать.
Модели, разработанные на базе сетей Петри, позволили исследовать
структурные особенности интерактивного взаимодействия разработчика и
системы
в
процессе
проектирования РБД.
Динамические
свойства
процесса интерактивного проектирования в разрабатываемых моделях
отражены посредством последовательности возможных маркировок сети
Петри. Однако в моделях предполагалось, что переходы срабатывают
мгновенно,
что
интерактивных
исключает
процессов.
возможность
Обеспечение
временного
возможности
анализа
получения
предварительных оценок производительности разрабатываемой системы
на ранних этапах ее разработки с целью выявления критических с точки
зрения приемлемого времени реакции процессов позволили сократить
сроки создания системы, улучшить ее характеристики. Для реализации
такой возможности воспользуемся аппаратом временных сетей Петри,
268
разработанных для моделирования асинхронных конкурирующих систем
[18].
Временная сеть Петри – это пара Р, , где Р – сеть Петри Р, Т,
М, а  - функция, которая каждому переходу ti в сети приписывает
действительное неотрицательное число i. Число I =  (ti) соответствует
времени срабатывания перехода. Напомним, что срабатывание перехода
возможно,
если
во
входном
положении
содержится
знак.
При
инициировании перехода из входных положений удаляется знак, фаза
выполнения продолжается I единиц времени, в конце этого промежутка
времени
переход
срабатывает
и
знак
перемещается
в
выходное
положение перехода. При этом должно выполняться следующее условие,
называемое балансом знаков:
М(0, Р) + Т(,ti1) + …, + Т((,tin) = М(, Р) +(,tj1) + …, + Т(,tjm),
где Т(,t) – число терминаций перехода t;
(,t) – число инициаций перехода t, включая время ;
М(0, Р) – число знаков в положении в начальный момент времени;
М(, Р) – число знаков в положении в момент времени .
Использование аппарата временных сетей Петри оправданно, если
считается, что i (продолжительность i – й деятельности) постоянна по
времени, несмотря на то, что, i не остается неизменной в процессе
функционирования человеко-машинной системы. Для предварительного
анализа временных характеристик могут быть использованы некоторые
усредненные
ожидаемые
задержки.
Поэтому
под
i
–
времени
срабатывания перехода ti далее будем понимать ожидаемое время
реакции решающих систем при выполнении i- ой человеко-машинной
процедуры. Здесь в качестве решающих систем выступает разработчик и
средства автоматизированного преобразования ИТВ. Поэтому i включает
в себя две составляющие:
i = iр + iс,
где iр – время реакции разработчика;
iс – время реакции системы.
В соответствии с методами оценки времени выполнения работ [20]
ожидаемое время реакции оценивается следующим выражением:
269
i = (аi + 4mi + bi) / 6,
где аi – оптимистическая оценка, указывающая время выполнения
работы при наиболее благоприятно сложившихся условиях;
bi – пессимистическая оценка, задающая время выполнения работ
при наиболее неблагоприятно сложившихся условиях;
mi – наиболее вероятная продолжительность работы.
При этом дисперсия ожидаемой оценки рассчитывается следующим
образом:
i2 = (bi - ai)2 / 36
Из выражений следует:
i = (аiр + аiс + 4(miр + miс )+ biр + biс) / 6,
где аiр, аiс – оптимистические оценки времен реакции соответственно
разработчика и системы в i – ом состоянии процесса проектирования;
biр, biс – пессимистические оценки времен реакции соответственно
разработчика и системы в i – Ом состоянии процесса проектирования;
miр, miс – соответствующие вероятностные оценки.
Временные оценки, используемые в моделях, могут быть получены на
основании
анализа
использованием
сложности
экспертных
решаемых
методов,
анализа
системой
опытов
задач
с
предыдущих
разработок .
Кроме того, в соответствии с использованием комплексного метода
разработки программных систем (сверху виз, снизу вверх и расширения от
ядра) отдельные модули системы, обладающие малой связностью с
другими модулями, могут быть реализованы на этапе уточнения проекта
системы. Опытная эксплуатация этих модулей позволила получить их
временные
характеристики.
Для
эффективного
использования
интерактивных средств проектирования необходимо обеспечить время
реакции проектных процедур системы, не превышающее общепринятых
норм (10 ÷ 15 секунд) [20]. Время реакции разработчика на различные
ситуации,
возникающие
в
процессе
преобразования
ИТВ
к
РБД,
существенно зависят от его индивидуальных особенностей, опыта,
квалификации. Оценки этого времени могут быть получены экспертным
270
путем, а также посредством анализа опыта эксплуатации существующих
средств.
Для моделей интерактивного взаимодействия в виде временных
сетей Петри пастулировано существование действительной временной
оси, на которой могут быть отмечены моменты срабатывания переходов
[18]. Переходы, разрешенные для ”зажигания”, и времена, в которые
происходят ”зажигания”, записываются в “таблицу зажиганий”, называемую
”расписанием зажиганий” [18]. Срабатывание перехода будем считать
осуществимым, если переход был возможен, когда его ”зажигание” было
инициировано.
Выполним анализ типичного фрагмента сети, а затем выполним
оценку временных характеристик сети в целом. Анализ выполняется с
целью предварительной оценки производительности системы, отыскания
резервов ее повышения. В качестве фрагмента выбрана подсеть с
положениями Р1, Р2, Р7 и переходами t1, t6, t11.
На
рис.
8.5.1
продемонстрировано
перемещение
маркеров
в
фрагменте сети.
P1
t1
t1
t1
P1
P2
t6
t6
P7
t11
t11
P7
t11
а
б
t1
P1
P2
t6
P7
в
t1
P1
P2
t6
t1
P1
P2
t6
P7
t11
P1
P2
t6
P7
t11
P2
P7
t11
271
г
д
t1
P1
е
t1
t1
P1
P2
t6
P1
P2
P2
t6
t6
P7
P7
t11
P7
t11
ж
t11
з
и
Рис. 8.5.1. Пример перемещения маркеров в фрагменте сети
Начальная маркировка приведена на рис. 8.5.1,а, после срабатывания
перехода
маркеры
занимают
положения
Р1
и
Р7
(рис.
8.5.1,б),
срабатывание перехода t1 позволяет переместить маркер в положение Р2
(рис. 8.5.1,в), после срабатывания перехода t11 маркеры перемещаются из
положения Р7 в положения Р1 и Р7 (рис. 8.5.1,г). После этого
сформируется такая разметка сети, что может сработать переход t6 - на
всех его входных положениях имеются маркеры. Срабатывание этого
перехода приведет к разметке сети, показанной на рис. 8.5.1,д. После
срабатывания перехода t1 маркер переместится в положение Р2 (рис.
8.5.1,е).
Пользователь
моделируемой
системы
имеет
возможность
принудительно поместить маркер в положение Р7. Физически положению
Р7
соответствует
состоянию
ИТВ
(информация
табличного
вида).
Разработчик БД всегда может инициировать это состояние системы. Такая
ситуация отражена на рис. 8.4.1,ж. После срабатывания перехода t11
маркер переместится в положение Р1 и Р7 (рис. 8.5.1,з). После
срабатывания перехода t11 повторно сформировалась маркировка сети,
позволяющая “зажечь” переход t6. Срабатывание перехода t6 приведет
сеть к маркировке рис. 8.5.1,и.
Как следует из рис. 8.4.1, маркировки сети повторяются, т.е. через
несколько итераций перемещения маркеров осуществляется возврат в
272
исходное состояние. Совпадают маркировки сети на рис. 8.5.1,в и рис.
8.5.1,ж, на рис. 8.5.1,г и рис 8.5.1,з, на рис. 8.5.1,д и рис 8.5.1,и.
Для отражения динамики функционирования сети и исследования ее
временных характеристик оправданно использовать граф переходов. Он
более компактный по сравнению с рис. 8.5.1 и наглядно отображает
срабатывание переходов, в том числе и повторное срабатывание.
В графе переходов последовательно отображаются переходы и только
положения, в которые перемещаются маркеры после срабатывания этих
переходов. На рис. 8.5.2 изображен граф переходов, соответствующий
динамике функционирования сети рис. 8.5.1.
t0 [1] 0=20
t0 [1] 0=20
P7
P7
t11 [2] 11=10
Р1
t11 [4] 11=10
Р1
P7
P7
t11 [4] 11=10
1=200 [3] t1
t6 [5] 6=10
P2
Р1
P7
P1
t1 [6] 1=200
6=10 [5] t6
P1
P2
Рис. 8.4.2. Граф переходов, соответствующий динамике
функционирования сети рис. 2.5.2
Для переходов t1, t6 и t11 в соответствии с методикой изложенной в
[28] выполнены предварительные оценки времен их срабатывания в
секундах, соответственно 1 = 200, 6 = 10, 11 = 10, 0 = 20.
Оценки
выполнялись для одной таблицы с числом атрибутов 20 и числом записей
1000, т.е. ИТВ представлено всего одной таблицей среднего объема.
Задержки
срабатывания
перехода,
как
показали
предварительные
экспериментальные исследования, линейно зависят от суммарного объема
таблиц. Данные задержки приписаны соответствующим переходам на
273
дереве переходов. Исходя из анализа дерева переходов, сформирована
таблица осуществимого расписания срабатывания переходов сети табл.
8.5.1.
Расписание становится неосуществимым, если, например, первая
инициация
перехода
t6
наступит
до
230
секунд
после
начала
функционирования системы. Это справедливо в связи с тем, что
инициация перехода t6 не может быть выполнена до терминации перехода
t1, который в свою очередь не может быть инициирован раньше 30 секунд
после начала функционирования системы.
Т а б л и ц а 8.5.1
Номер срабатывания
перехода
Идентификатор перехода
t0
t11
t1
t6
1
2
0,20
20, 30
30, 230
230, 240
20, 40
30, 40
240, 440
440, 450
3
4
40, 60
40, 50
440, 640
640, 650
5
60, 80
80, 100
60, 70
70, 80
640, 840
840, 850
6
80, 90
7
100, 110
Из таблицы видно, что при определенной последовательности
“зажиганий” инициации переходов происходят через равные интервалы
времени. Например, в установившемся режиме все ”зажигания” t0
осуществляются
через
20
осуществляются
через
200
секунд,
секунд,
”зажигания”
2÷3
перехода
t1
”зажигания”
2÷3
перехода
t6
осуществляются через 200 секунд. Особый период ”зажигания” зависит от
времени срабатывания перехода t0, поэтому он составляет то 0, то 20
секунд.
Из-за особенностей сети переход t11, как видно из таблицы, может
срабатывать 7 раз, в то время как переходы t1 и t6 успевают сработать 4
раза.
Хотя это несвойственно для системы в целом, для установившейся
последовательности
”зажиганий”
можно
определить
скорость
срабатывания переходов в единицу времени. Из таблицы табл. получены
следующие оценки для переходов:
t0 – (100 - 20) / 4, t1 – (840 - 440) / 2, t6 – (850 - 450) / 2
274
Возникает
естественный
вопрос,
можно
ли
увеличить
продолжительность отдельной компоненты интерактивной системы, а
следовательно и производительность системы в целом? В соответствии с
[4] оценка скорости выполнения к – го перехода определяется по формуле:
Uk = nk / Пк,
где nk – знаковое содержание контура, включающего к –й переход;
Пк – период “зажигания” к-го перехода.
Реализуемой границей скорости вычисления для временной сети
Петри в целом является значение:
min (n1 / П1, n2 / П2, …, nm / Пm),
где m – число переходов в сети.
Таким образом, для повышения производительности временной сети
Петри необходимо увеличить знаковое содержание контура или уменьшить
периоды зажигания переходов. Знаковое содержание контуров в сети
соответствует в системе числу процессов, протекающих одновременно в
данном режиме. Периоду зажигания соответствует интервал времени от
окончания какого-либо процесса до его повторной инициации, который
зависит от времени реакции разработчика и используемых средств
преобразования ИТВ в РБД в различных состояниях этого процесса.
Увеличить знаковое содержание рассматриваемого контура сети не
удается, т.к. все переходы и положения в данном случае взаимозависимы
и распараллелить процесс преобразования таблиц ИТВ в реляционные
таблицы не удается.
Возможно, удастся уменьшить период зажигания, но окончательные
выводы по этому вопросу можно будет сделать после реализации
соответствующего метода алгоритмов и средств. Однако уже сейчас из
анализа срабатывания переходов можно сделать вывод о том, что по
предварительным оценкам первая итерация процесса преобразования
одной
средней
таблицы
к
реляционному
виду
будет
выполнена
ориентировочно за 6 минут, для выполнения последующих итераций
преобразования потребуется немного меньше времени.
Увеличить знаковое содержание сети или распараллелить отдельные
процессы возможно удастся при анализе оставшихся контуров сети. Такую
надежду внушает то, что в процессе нормализации реляционных таблиц
275
обычно формируются и связи между ними. В то же время предусмотрены
специальные мероприятия по формированию связей между реляционными
таблицами. И при разработке метода нормализации реляционных таблиц,
и при разработке метода формирования связей между реляционными
таблицами рассматриваются по 4-е случая. Таким совпадением вероятно
удастся воспользоваться.
Для более наглядного представления динамики функционирования
оставшихся компонент сети, демонстрации живости и достижимости сети,
оценки ее временных характеристик и выявления возможности повышения
производительности сети на начальных этапах разработки системы
построим граф переходов для оставшихся компонент сети. Этот граф
представлен на рис. 8.5.3.
276
t00 [8] =20
t00 [14] =20
t12 [11] =10
P8
P8
t14 [9] =10
t14 [15] =10
P7
P9
t00 [21] =20
t9 [12] =200
t0 [13] =20
P9
P9
t0 [7] =20
==20
t0 [20] 
========
=======20
P10
P7
P8
t14 [22] =10
P7
t7 [16] =10
P9
P10
t9 [19] 
P8
t14 [17] =10
P7
t00 [28] =20
P9
P9
P8
t7 [23] =10
P7
P8
t12 [18] =10
t13 [24] =10
t00 [26] =20
P11
t8 [29] =10
t10 [25] =200
P8
P5
P12
t13 [27] =10
P11
t5 [30] =200
P6
Рис. 8.5.3. Граф переходов (часть 1)
Вторая часть графа приведена на рис. 8.5.4.
277
t00 [41] =20
t00 [47] =20
t00 [31] =20
P8
t13 [48] =10
t13 [32] =10
t00 [35] =20
P11
P8
P11
P8
P8
t13 [42] =10
P8
t13 [50] =10
t13 [34] =10
t10 [33] 200
P8
P12
P11
P8
t8 [45] =10
P6
t00 [37] =20
t00 [52] =20
t00 [54] =20
P3
t4 [39] =200
P4
P12
t8 [51] =20
P5
t5 [46] =200 P8
P6
t3 [38] =10
P11
P5
P8
P5
t10[49] 200
P12
P11
t5 [30] =200 t8 [36] =10
P11
P8
t10 [43] =200
t13 [44] =10
P8
t3 [53] =10
P3
P8
t2 [55] =10
Рис. 8.5.4. Граф переходов (часть 2)
Граф построен, исходя из анализа сети Петри (рис. 2.3.3 ). Он
построен таким образом, чтобы сработали все переходы сети с учетом
правил их срабатывания. При этом граф формировался таким образом,
чтобы при достижении всех положений был пройден минимальный путь.
Таким образом, на основании анализа построенного графа можно оценить
минимальное время срабатывания всех переходов и достижения всех
положений. Это позволит выполнить предварительную оценку времени,
необходимого для проектирования БД на основе использования ИТВ,
представленной одной таблицей средней сложности.
278
Всем переходам в графе поставлены в соответствие времена их
срабатывания. Времена срабатывания переходов как и в предыдущем
случае, получены на основе экспертных оценок и экспериментальных
исследований.
Учитывая
задержки
срабатывания
переходов
и
правила
их
срабатывания, сформируем таблицу зажиганий переходов (табл. 8.5.2).
Т а б л и ц а 8.5.2
N
Переход
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
t00
t14
t0
t00
t14
t0
t12
t9
t7
t14
t12
t9
t0
t00
t14
t7
t13
Кратко
Время
срабатывания
20
30
20
40
50
40
60
260
270
280
290
490
60
60
70
500
510
поясним
N
Переход
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
t10
t00
t00
t13
t8
t5
t00
t00
t13
t10
t13
t8
t5
t00
t3
t4
t00
принцип
Время
срабатывания
710
80
100
110
720
920
120
140
150
1120
930
1130
200
140
1140
1340
160
формирования
N
Переход
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
t13
t13
t10
t8
t5
t00
t00
t13
t13
t10
t8
t00
t3
t00
t2
таблицы
Время
срабатывания
170
180
370
380
580
160
180
190
200
390
400
180
410
200
1350
зажиганий
переходов.
Очередное срабатывание особых переходов t0 и t00, переходов,
срабатывание которых инициирует положения, соответствующие ИТВ и
РБД, могут срабатывать в произвольные моменты времени, но с
интервалом в 20 секунд. Поэтому первое срабатывание перехода t0
возможно через 20 секунд, а третье – через 60 секунд. Переход
срабатывает только тогда, когда сработали все переходы, над ним
расположенные. Поэтому из всех поддеревьев, входящих в переход,
выбирается дерево с максимальной суммарной задержкой срабатывания.
После чего к этой задержке приплюсовывается время срабатывания
перехода. Так, например, в переход t7 входят 3 – и поддерева:
t00, P8, t14, P9; t0, P7 и
279
t00, P8, t10, t0, P7, t12, P9, t9, P10
Время срабатывания перехода t7 вычисляется следующим образом
max ((00 + 14), 0, (max ((00 + 14), 0) + 12 + 9))+ 7 или
max ((20 + 10), 20, (max ((40 + 10), 20) + 10 + 200)) + 10 = 270
В соответствии с этим правилом рассчитаны времена срабатывания
всех переходов.
Кажущимся исключением из сформулированного правила является
переход t10 (N27). Он срабатывает через 1310 секунд, хотя видимых
причин для этого нет. Причина в том, что в соответствии с методикой
преобразования ИТВ в РБД нельзя начать выполнение действий,
связанных с каким-либо этапом преобразования ИТВ, до завершения
предыдущего
этапа.
Поэтому
время
срабатывания
перехода
t7
складывается из задержки его срабатывания 200 и времени срабатывания
перехода t5 (последнего перехода предыдущего этапа преобразования).
В качестве предварительной оценки времени выполнения одной
итерации преобразования таблицы ИТВ в таблицу или таблицы РБД может
быть использовано время прохождения деревьев рис. *, рис.**, а также
дерева рис. …
t итерации = 240 + 1350 = 1590 секунд.
Важно еще раз отметить, что это предварительная, вероятностная
оценка,
которая,
тем
не
менее,
служит
ориентиром
временных
характеристик реализуемой методики, а также исходными данными для
проведения мероприятий по повышению производительности сети и,
следовательно, процесса ею моделируемого на ранних этапах его
разработки.
Выполним анализ возможностей повышения производительности
сети. Один из способов производительности сети – это повышение ее
маркерной нагрузки, что соответствует распараллеливанию моделируемых
процессов. Как отмечалось ранее, процесс нормализации реляционных
таблиц тесно связан с процессом формирования связей между таблицами.
В связи с этим эти процессы часто протекают практически одновременно.
Рассмотрим
использованием
возможность
динамической
совмещения
и
сетевой
этих
процессов
моделей
с
методики
280
преобразования ИТВ к РБД.
модели,
соответствующего
Из сравнения фрагмента операторной
процессу
формирования
связей
между
таблицами СОс, ОПРс, СПс, ОПс и фрагмента операторной модели,
соответствующего процессу нормализации таблиц СОн, ОПРн, СПн,
ОПн, можно сделать вывод о том, что схожи составы их компонент. Более
того, связи между компонентами практически идентичны: СОс связан с
ОПРс, подобно тому как СОн связан с ОПРн; ОПРс связан с СПс, подобно
тому как ОПРн связан с СПн; СПс связана с ОПс, подобно тому как СПн
связана с ОПн; ОПс связана двунаправленной связью с СОс, подобно тому
как
ОПн
связан
двунаправленной
двунаправленной
связью
с
РБД,
связью
подобно
с
СОн;
тому
как
ОПС
связан
ОПн
связан
двунаправленной связью с РБД. Но есть одно отличие: ОПк связан с СОс,
но не связан с СОн.
С учетом сказанного сделан вывод, что рассмотренные фрагменты
операторных
моделей
можно
совместить,
при
этом
необходимо
обеспечить связь между ОПк и СОс.
Результат
совмещения
фрагментов
операторных
моделей
представлен на рис.8.5.5. При этом использованы новые обозначения
ОПн,с  ОПн, ОПс; СПн,с  СПн, СПс; ОПРн,с  ОПРн, ОПРс; СОн,с 
СОн, СОс.
281
ОПк
t3
ОПРр
t1
СОр
P1
ОСОр
t11
ОСОи
t12
СОк
P5
СПр
P2
ИТВ
P7
ОПр
t6
СОи
P9
РБД
P8
ОПи
t7
СПи
P10
ОПРи
t9
ОСОн
t14
ОСОн
t13
ОПРк
t5
СПк
P6
ОПн,с
СПн,c
t8,t2
P12,P4
СОн,c
P11,P3
ОПРн,,c
Рис. 8.5.5. Результат совмещения фрагментов операторных моделей
Для
обеспечения
формирования
сети
Петри
соответствующей
операторной модели, учитывающей возможность распараллеливания
процессов в операторной модели, помечены совместимые переходы и
положения.
На
варианта
основе модифицированной операторной модели и последнего
сети
Петри
построена
модификация
сети,
учитывающая
возможность протекания параллельных процессов. Эта сеть представлена
на 8.5.6.
282
t10,t4
t3
t1
P1
t5
P2
P6
P5
t6
t7
t8,t2
P7
t11
P8
t12
t14
t13
t10,t4
t9
P9
P10
P11,
P3
P12,
P4
Рис. 8.5.6. Сеть Петри соответствующая результату совмещения
фрагментов операторных моделей
Следует отметить, что так как на сетевой модели появилась новая
входная связь в положение (Р11, Р3), то для сохранения баланса потоков
для этого положения необходима выходная связь. И, действительно,
исходя из логики функционирования параллельных процессов и специфики
новых итерационных последовательностей, необходима обратная связь с
ОСОн (рис. 8.5.7,а). Есть и другая причина формирования этой связи –
коль скоро РБД связана двунаправленной связью с ОСОн, то естественно
предположить, что будет полезной двунаправленная связь между ОСОн и
СОн,с. На рис.8.5.7,б эта связь отображена как
обратная связь с
переходом t13. При такой схеме связей для положения (Р11, ЗР) баланс
потоков не нарушается.
Принципиальным отличием полученного фрагмента сети является то,
что у него удвоилась маркерная загрузка, и в связи с этим изменились его
временные характеристики.
283
Для анализа динамических свойств преобразованного фрагмента
сети и оценки его временных характеристик выделим этот фрагмент.
Исследуемый фрагмент операторной модели и соответствующая подсеть
представлены на рис. 8.5.7.
t3
ОПк
t3
t5
P6
СОк
P5
P5
СПк
P6
ОПРк
t5
t8,t2
РБД
P8
ОПн,с
СПн,c
t8,t2
P12,P4
P8
t13
t10,t4
СОн,c
P11,P3
ОСОн
t13
ОПРн,,c
P11,
P3
t10,t4
а
P12,
P4
б
Рис. 8.5.7. Фрагмент операторной модели и соответствующая сеть
описывающие параллельные процессы
Выполним процедуру перемещения маркеров в сети.
На рис. 8.5.8 и рис.8.5.9 проиллюстрирована динамика перемещения
маркеров в подсети с двойной маркерной загрузкой. Последовательность
перемещения маркеров выбрана таким образом, чтобы за минимально
возможное время сработали все переходы и чтобы маркеры побывали во
всех положениях сети. Физически это соответствует срабатыванию всех
операторов
динамической
модели,
что
позволит
оценить
время
выполнения одной итерации, выполнения мероприятий, связанных с
нормализацией реляционных таблиц, формированием связей между
таблицами и назначением ключевых полей.
На рис. 8.5.8 проиллюстрирована начальная загрузка подсети – два
маркера размещены в положении Р8. После срабатывания перехода t13
284
маркеры переместятся в положение Р11 и и по обратной связи в
положение Р8 (рис. 8.5.8,б). Срабатывание перехода (t10, t4) позволит
переместиться маркерам в положение Р4, соответствующая маркировка
подсети представлена на рис.. 8.5.8,в. Повторное срабатывание перехода
t13 приведет к загрузке сети рис. 8.5.8,г. После этого появится
принципиальная возможность срабатывания перехода (t8, t2) – во всех
входных
положениях
этого
срабатывания перехода
перехода
имеются
маркеры.
После
(t8, t2) один маркер может переместиться в
положение Р5, а другой – в Р8 (рис. 8.5.8,д). В положении Р5 возможно
нахождение лишь одного маркера в связи с тем, что в этом положении не
предусмотрена возможность параллельных процессов. Срабатывание
перехода t5 позволит маркеру переместится в положение Р6 (рис. 8.5.8,е).
На рис. 8.5.9,а отображена ситуация, когда разработчик повторно
инициировал
процесс
и
сработал
переход
t13.
Далее
процесс
перемещения маркеров осуществляется по аналогии с рассмотренным
процессом.
Рис. 8.5.9,б соответствует рис. 8.5.8,б, рис. 8.5.9,в соответствует рис.
8.5.8,в, рис. 2.5.9,г соответствует рис. 8.5.8,г, рис. 8.5.9,д соответствует
рис. 8.5.8,д.
Но следует обратить внимание на то, что в процессе выполнения 4-х
последних переходов в положении Р6, в отличии от предыдущего случая,
находился маркер. После срабатывания перехода (t8, t2) (рис. 8.5.9,д) в
подсети сформируется ситуация, когда может сработать переход t3 (все
входные положения перехода t3 промаркированы). После срабатывания
перехода t3 сеть примет вид рис. 8.5.9,е.
285
t3
t3
t5
t5
P6
P6
P5
P5
t8,t2
t8,t2
P8
P8


t13
t13
t10,t4
P11,
P3
t10,t4
P11,
P3
P12,
P4
а
P12,
P4

б
t3
t3
t5
t5
P6
P6
P5
t8,t2
t8,t2
P8
P8


t13
t13
t10,t4
P11,
P3
в
P5
t10,t4
P11,
P3
P12,
P4


P12,
P4

г
286
t3
t3
t5
t5
P6
P6
P5
P5


t8,t2
t8,t2
P8
P8


t13
t13
t10,t4
t10,t4
P11,
P3
P11,
P3
P12,
P4
д
P12,
P4
е
Рис. 8.5.8. Иллюстрация динамики перемещения маркеров в подсети
с двойной маркерной загрузкой (часть 1).
t3
t3
t5
t5
P6
P6
P5

t8,t2
t8,t2
P8
P8


t13
t13
t10,t4
P11,
P3
а
P5

t10,t4
P11,
P3
P12,
P4

P12,
P4
б
287
t3
t3
t5
t5
P6
P6
P5

P5

t8,t2
t8,t2
P8
P8


t13
t13
t10,t4
t10,t4
P11,
P3
P12,
P4

P11,
P3
в
P12,
P4


г
t3
t3
t5
t5
P6
P6
P5

P5

t8,t2
t8,t2
P8
P8


t13
t13
t10,t4
P11,
P3
д
t10,t4
P11,
P3 
P12,
P4

P12,
P4
е
Рис. 8.5.9. Иллюстрация динамики перемещения маркеров в подсети
с двойной маркерной загрузкой (часть 2).
288
Таким образом, руководствуясь правилами срабатывания переходов,
выполнено перемещение маркеров по всей сети, выявлена возможная
последовательность
переходов.
Эта
последовательность
с
соответствующими задержками срабатывания сведена в табл. 8.5.3, с
учетом того, что:
3 = 10; 5 = 200; 8, 2 = 10; 13 = 10; 10; 4 = 200; 0 = 20
Т а б л и ц а 8.5.3
N
Переход
1
2
3
4
t0
t13
t10, t11
t13
Время
срабатывания
20
30
230
240
N
Переход
5
6
7
8
t8, t2
t5
t0
t13
Время
срабатывания
250
450
470
480
N
Переход
9
10
11
12
t10, t4
t13
t8, t2
t3
Время
срабатывания
680
690
700
710
Таким образом, время прохождения подсети для выполнения одной
итерации по нормализации, формированию связей и формированию
ключевых полей – 710 секунд.
Для
оценки
распараллеливании
суммарного
времени
рассмотренных
прохождении
процессов
сети
необходимы
при
времена
срабатывания подсетей
{P1, t1,P2,t6,P7,t11} и {P9,t9,P10,t7,P7,t12}.
Для первой подсети оценка минимального времени ее срабатывания
уже выполнена и равна 240 сек. (см, табл. 8.5.1) _ . Для второй подсети
оценку времени ее срабатывания нетрудно выполнить посредством
анализа графа переходов (рис. 8.5.4). Время срабатывания этой подсети
250 сек.
Таким
образом,
суммарное
время
срабатывания
сети
при
распараллеливании процессов нормализации и формирования связей
между таблицами составляет: 710 + 240 + 250 = 1200 сек. В то время как
без распараллеливания процессов минимальное время прохождения сети
составляет
1590
сек.
(табл.
8.5.1
и
табл.
8.5.2.).
Эффект
распараллеливания процессов очевиден. Однако следует иметь в виду,
что предложенное распараллеливание возможно не всегда. Процесс
289
формирования связей между таблицами нередко не связан напрямую с
процессом нормализации таблиц.
Упражнения и вопросы для самоконтроля
1.
Что
позволит
выполнить
разработка
методики
до
полной
реализации методов в нее включаемых.
2. Что обеспечивает детализация информационных моделей ИТВ и
РБД.
3. Что обеспечивает
операторная модель человеко-машинной
системы.
4. Что позволяет модель методики в виде сети Петри.
5. Какие характеристики методики проектирования РБД позволяют
оценить деревья достижимости.
6. Что может быть использовано в качестве исходной формализации
для разработки и реализации методов, алгоритмов, средств, методик,
ориентированных
на решение общих и частных задач проектирования
РБД на основе использования ИТВ.
290
СПИСОК ЛИТЕРАТУРЫ
1.
Дейт К., Дж. Введение в системы баз данных. М.: Наука,
1980.
2.
Гэри Хансен, Джеймс Хансен. Базы данных: разработка и
управление: Пер с англ. М.:ЗАО Издательство БИНОМ, 1999.
3.
Григорьев Ю.А., Ревунков Г.И. Банки данных. Учебник для
вузов. М.: Изд-во МГТУ им. Н.Э. Баумана, 2002.
4.
Райан Стивенс, Рональд Плю. SQL: Пер с англ. М.:ЗАО
Издательство БИНОМ, 1998.
5.
Харитонова И.А., Михеева В.Д. Access 2000. СПб.:БХВ-СанктПетербург, 1999.
6.
Тихомиров Ю.В. Microsoft SQL Server 7.0. СПб.:БХВ-СанктПетербург, 1999.
7.
Брешенков А.В., Бараков Д.Д. Неформальная постановка
проблемы преобразования информации табличного вида в
файлы баз данных. Сборник трудов АУ МВД России
"Актуальные
вопросы
использования
информационных
технологий в деятельности органов внутренних дел. М.,2004.
8.
Брешенков А.В., Бараков Д.Д. Вопросы преобразования
электронных таблиц в таблицы реляционных баз данных.
Современные информационные технологии: Cб. трудов каф.
ИУ-6, посвященный 175-летию МГТУ им. Н.Э. Баумана. М.:
Эликс+, 2004.
9.
Брешенков
А.В.,
Бараков
Д.Д.
Методика
назначения
ключевых полей в заполненных реляционных таблицах.
Современные информационные технологии: Cб. трудов каф.
ИУ-6, посвященный 175-летию МГТУ. им. Н.Э. Баумана. М.:
Эликс+, 2005.
10.
Брешенков
А.В.
избавление
от
сложных
атрибутов
в
заполненных нереляционных таблицах. Cб. трудов каф. ИУ6.
291
11.
Брешенков
А.В.
Оперативная
разработка
баз
данных
средствами системы Clarion. М.:, Машиностроение, 1995.
12.
Брешенков
А.В.,
репликации
баз
изменений
Бондарь
данных
(алгоритмы
М.Л.
на
Построение
основе
синхронизации
системы
протоколирования
и
односторонней
репликации). Cб. трудов каф. ИУ-6, посвященный 175-летию
МГТУ им. Н.Э. Баумана. М.: Эликс+,2004.
13.
Брешенков А.В., Бондарь М.Л. Поддержка
целостности
данных
репликации.
в
алгоритмах
оптимистической
Современные информационные технологии: Cб. трудов каф.
ИУ-6, посвященный 175-летию МГТУ им. Н.Э. Баумана. М.:
Эликс+, 2005.
14.
Брешенков А.В., Губарь А.М. Проектирование баз данных в
среде Access: Учебное пособие для вузов. М.: Изд-во МГТУ
имени Н.Э. Баумана. 2006.
15.
Норенков
И.П.
Основы
автоматизированного
проектирования: Учеб. для вузов. 2-е изд., переработ. и доп.М.:Изд-во МГТУ им. Н.Э.Баумана,2002.-336с.
16.
Балл Г.А. Система понятий для описания приложений
интеллекта // Кибернетика. – 1979. - №2. – С 109-113.
17.
Денниг В., Эссиг Г., Маас С. Диалоговые системы ”человекЭВМ”. Адаптация к требованиям пользователя. – М.: Мир,
1984 – 112 с.
18.
Rumchandany C. Analys of asynchronous concurrent systems by
Petry
nets.
–
NAC
TR
–
120.
project
MAC,
M.I.T.
Cumbridge(MASS). 1974-p.218
19.
Дубинин В.Н. Комплекс программ "ПЕТРИС" для построения
и исследования сетей Петри. //
http://diamond.stup.ac.ru/KOI/SOFT/DESCRIPT/0007.ru.html
20.
Питерсон Дж. Теория сетей Петри и моделирования систем:
Пер. с англ. -М.: Мир, 1984. -264 с., ил.
292