
- •А.В. Брешенков
- •Проектирование баз данных на основе информации табличного вида
- •1. Анализ проблемы проектирования реляционных баз данных на основе использования информации табличного вида 8
- •5. Назначение ключевых полей 142
- •6. Выявление и формирование связей между заполненными таблицами 157
- •7. Объединение таблиц 190
- •8. Разработка и исследование модели методики проектирования реляционных баз данных на основе использования информации табличного вида 220
- •Предисловие
- •Глава 5 посвящена методу назначения ключевых полей в заполненных нереляционных таблицах.
- •1. Анализ проблемы проектирования реляционных баз данных на основе использования информации табличного вида
- •1.1. Понятие информации табличного вида
- •1.2. Мотивы преобразования информации табличного вида в файлы реляционных баз данных
- •1.3. Основные требования к средствам преобразования информации табличного вида в реляционные таблицы
- •1.4. Задачи объединения и разбиения реляционных таблиц
- •1.5. Задачи нормализации реляционных таблиц
- •1.6. Преобразование реляционных нормализованных таблиц в файлы бд
- •1.7. Вопросы преобразования электронных таблиц
- •Упражнения и вопросы для самоконтроля
- •2. Постановка задачи проектирования реляционных баз данных на основе использования информации табличного вида
- •2.1. Укрупненная модель реляционной базы данных
- •2.2. Укрупненная модель информации табличного вида
- •2.3. Задачи преобразования заполненных нереляционных таблиц в реляционные таблицы Преобразование нереляционных таблиц в реляционные таблицы
- •Нормализация заполненных таблиц
- •Назначение ключевых полей для заполненных таблиц
- •Выявление и формирование связей между заполненными реляционными таблицами
- •Упражнения и вопросы для самоконтроля
- •3. Преобразование нереляционных таблиц в реляционные таблицы
- •3.1. Приведение значений атрибутов заполненных таблиц к одному типу
- •3.2. Исключение дублирования записей
- •Упражнения и вопросы для самоконтроля
- •4. Нормализация заполненных реляционных таблиц.
- •4.1. Проблемы нормализации
- •4.2. Модели информации табличного вида и реляционных таблиц.
- •4.2.1. Модель информации табличного вида
- •4.2.2. Модель реляционной таблицы
- •4.3. Преобразование заполненных таблиц к первой нормальной форме
- •4.3.1. Избавление от сложных атрибутов
- •4.3.2. Исключение подзаголовков расположенных внутри таблицы
- •4.3.3. Нормализация заполненных таблиц с подзаголовками в первом столбце.
- •4.4. Преобразование заполненных таблиц ко второй нормальной форме
- •4.5. Преобразование заполненных таблиц к третьей нормальной форме
- •Избавление от функциональной зависимости.
- •4.6. Преобразование заполненных таблиц к четвертой нормальной форме.
- •Упражнения и вопросы для самоконтроля
- •5. Назначение ключевых полей
- •5.1. Задача назначения ключевых полей в заполненных реляционных таблицах
- •5.2. Алгоритмы назначения ключевых полей в заполненных реляционных таблицах
- •Упражнения и вопросы для самоконтроля
- •6. Выявление и формирование связей между заполненными таблицами
- •6.1. Выявление и формирование связей один - к одному
- •6.2. Выявление и формирование связей один - ко многим
- •6.3. Выявление и формирование связей многие - ко многим.
- •Формирование 3-й таблицы для реализации многозначных связей.
- •Упражнения и вопросы для самоконтроля
- •7. Объединение таблиц
- •7.1. Проблемы объединения таблиц
- •Исходные таблицы по своей природе удовлетворяют требованиям совместимости, а по форме – нет.
- •Исходные таблицы удовлетворяют требованиям совместимости, результирующую таблицу необходимо обновлять.
- •Исходные таблицы частично удовлетворяют требованиям совместимости.
- •7.2. Объединение и обновление совместимых таблиц
- •7.3. Объединение таблиц, частично удовлетворяющих требованиям совместимости
- •Упражнения и вопросы для самоконтроля
- •8. Разработка и исследование модели методики проектирования реляционных баз данных на основе использования информации табличного вида
- •8.1. Постановка задачи разработки модели методики
- •8.2. Операторная модель преобразования информации табличного вида к реляционным базам данных
- •8.3. Исследование методики преобразования информации табличного вида в реляционные базы данных
- •8.4. Исследование динамических свойств функционирования системы.
- •8.5. Исследование временных свойств системы.
- •Упражнения и вопросы для самоконтроля
- •Список литературы
4.3.3. Нормализация заполненных таблиц с подзаголовками в первом столбце.
Нередко в таблицах первый столбец используется для хранения подзаголовков групп. Например, это справедливо для табл. 4.3.6.
Т а б л и ц а 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-й столбец в отдельную таблицу;
- пронумеровать его записи;
- исключить в новой таблице повторяющиеся записи;
- пронумеровать записи исходной таблицы в соответствии с новой таблицей;
- удалить первый столбец исходной таблицы;
- сформировать связи между полученными таблицами.
Выполним описанные преобразования на примере.
В табл. 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 |
Бег |
В табл. 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.
Значение счетчика записывается в поле ключевого столбца соответствующей строки.
П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
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.
Рис. 4.3.8. Фрагмент таблицы в формате Microsoft Excel с заголовками в 1-м столбце
После импорта этой таблицы в Microsoft Access она примет следующий вид (рис. 4.3.9).
Рис. 4.3.9. Результат импорта в Microsoft Access
С помощью запроса можно сформировать новую таблицу, которая включает в себя только заголовки. Этот запрос имеет следующий вид.
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 с дополнительным полем
Следующим шагом преобразования является ввод в таблицу 4.3.9 номеров регионов. В результате получится таблица, представленная на рис. 4.3.12.
Рис. 4.3.12. Таблица с пронумерованными регионами
Для обеспечения связи между таблицами необходимо в режиме Конструктора в таблице “Таблица” изменить тип поля ”Регион” на числовой.
После названных преобразований можно построить схему данных, которая представлена на рис. 4.3.13.
Рис. 4.3.13. Схема данных
После выполненных манипуляций обеспечена ссылочная целостность данных, т.е. в таблице Таблица нельзя ссылаться на несуществующий регион. Обеспечивается каскадное обновление, т.е. при изменении названия региона в таблице Таблица2 все соответствующие ссылки в таблице Таблица обновятся. Обеспечивается каскадное удаление, т.е. при удалении региона из таблицы Таблица2 удалятся все записи, связанные с этим регионом в таблице Таблица. Кроме того, сводится к минимуму вероятность ошибок при вводе нового региона. Действительно, вводить регион достаточно только в одну таблицу.
Для просмотра всей необходимой информации из двух таблиц можно построить следующий запрос.
SELECT Таблица2.Регион, Таблица.[№ п/п], Таблица.Дата, Таблица.Заказчик
FROM Таблица2 INNER JOIN Таблица ON Таблица2.[Номер региона] = Таблица.Регион;
Запрос позволяет выбрать указанные поля из обеих таблиц. Конструкция “Таблица2 INNER JOIN Таблица ON Таблица2.[Номер региона] = Таблица.Регион” свидетельствует о том, что используется внутреннее соединение двух таблиц (INNER JOIN), т.е. выбираются из таблиц только те поля, у которых ключевые поля совпадают (Таблица2.[Номер региона] = Таблица.Регион). В квадратных скобках указываются поля, в которых есть пробел.
Результат выполнения этого запроса представлен на рис. 4.3.14.
Рис. 4.3.14. Результат выполнения запроса
Как видно из выполненных мероприятий, даже для небольших по объему таблиц, они не являются тривиальными. Повышение размерности преобразуемых таблиц существенно увеличивает трудоемкость необходимых преобразований, а также увеличивает вероятность ошибок разработчика, допущенных в ходе выполнения преобразования.