А. В. Брешенков Проектирование баз данных на основе информации табличного вида Допущено в качестве учебного пособия для студентов высших учебных заведений, обучающихся по направлению подготовки диплом

Вид материала

Диплом

Содержание 1.4. Задачи объединения и разбиения реляционных таблиц 1.5. Задачи нормализации реляционных таблиц

Подобный материал:

• Учебное пособие Допущено Министерством образования Российской Федерации в качестве, 2582.59kb.
• Д. В. Андреев Программирование микроконтроллеров mcs-51, 2064.3kb.
• И. В. Борискина, А. А. Плотников, А. В. Захаров проектирование современных оконных, 1699.55kb.
• «История нового времени», 4001.1kb.
• Учебное пособие. 3-е изд., испр и доп, 125.38kb.
• М. В. Ломоносова Хрестоматия по истории государства и права зарубежных стран, 11295.75kb.
• В. В. Крупица Личность Коллектив Стиль отношений (социально-психологический аспект), 4876.34kb.
• И. М. Синяева, В. М. Маслова, В. В. Синяев сфера, 5230.77kb.
• И. К. Корнеев информационная безопасность и защита информации учебное пособие, 7667.6kb.
• Курслекций допущено умо по образованию в области социальной работы в качестве учебного, 2178.14kb.

1.4. Задачи объединения и разбиения реляционных таблиц

Если удастся преобразовать информацию табличного вида в реляционные таб­лицы, то это не всегда означает, что их можно непосредственно преобразовывать в формат БД. Может потребоваться объединение нескольких таблиц в одну. Это обу­словливается различными причинами.

В частности:

- информация, которую нужно включить в БД, поступает от нескольких контрагентов;

- в существующей БД, в кото­рую вводятся новые данные, используется таблица, объединяющая в себя ин­формацию из нескольких включаемых таблиц.

С другой стороны, может воз­никнуть обратная проблема, которая связана с преобразованием одной таблицы в несколько таблиц.

Это может произойти:

- когда данные из таблицы, включаемые в суще­ствующую БД, в ней уже представлены несколькими таблицами;

- когда таблица в БД не удовлетворяет условиям нормализации [2].

Одним из самых простых случаев является случай, когда несколько одинаковых по сути таблиц необходимо объединить в одну. Решение задачи может свестись к выбору исходной таблицы и добавлению в эту таблицу записей с данными из других таблиц. Однако, если столбцы исходных таблиц не расположены в одинаковой после­довательности, то исходные таблицы необходимо предварительно преобразовать к нужному виду. Кроме того, в соответствии с требованиями к таблицам БД их записи должны быть уникальны, т.е. в них должны отличаться значения хотя бы одного поля. Это требование далеко не всегда выполняется, например, когда в исходных таблицах записи отличаются только порядковыми номерами, а эти номера в различ­ных таблицах могут совпадать. В связи с этим может возникнуть необходимость до­бавления в таблицу специального ключевого поля, значение которого должно быть уникальным для каждой записи.

Более сложным является случай, когда необходимо объединить не­скольких дополняющих по данным друг друга таблиц в одну. При этом число и смы­словая нагрузка столбцов исходных таблиц может не совпадать. Тогда, кроме про­блем объединения, возникают новые проблемы. Для решения задачи объеди­нения такого характера необходимо выявить поля в исходных таблицах, по которым можно провести объединение. Эти поля должны присутствовать во всех таблицах и иметь одинаковую смысловую нагрузку. Такие поля называют ключевыми. После чего необходимо формировать записи целевой таблицы из записей исходных таблиц, при этом критериями формирования новых записей являются одинаковые значения ключевых полей в исходных таблицах. Кроме того, в процессе формирования записи необходимо исключать заголовки и данные одинаковых столбцов.

В случае необходимости разбиения одной таблицы на несколько таблиц, следует руководствоваться критериями эффективности построения новой БД на основе использования исходных таблиц. В частности, необходимо руководствоваться требованиями нормализации таблиц. Если БД уже существует, то необходимо руководствоваться со­ставом таблиц БД, их структурой и связями между таблицами. При разбиении таблиц необходимо иметь в виду, что пользователю БД может потребоваться обработка ин­формации из нескольких таблиц одновременно. Поэтому между результирующими таблицами необходимо обеспечить связи, например, через механизм первичных и внешних ключей.

Для качественного, бездефектного решения задач объединения и разбиения ре­ляционных таблиц необходима разработка формальных моделей исходных и целевых таблиц, формальной методики преобразования таблиц.

1.5. Задачи нормализации реляционных таблиц

После того, как информация приведена к реляционной форме, нет ника­кой гарантии, что эти таблицы самые удачные с точки зрения их представления и ис­пользования в БД. Дело в том, что одни и те же данные могут группироваться в раз­личные отношения (таблицы). Определенный набор отношений обладает лучшими свойствами при манипуляциях с БД, если он отвечает требованиям нормализации от­ношений. Нормализация отношений - формальный аппарат ограничений на форми­рование отношений, который позволяет устранить дублирование, обеспечить непро­тиворечивость хранимых данных, уменьшает затраты на ведение баз данных. Во­просы приведения отношений к нормальным формам широко освещены в литературе по теории построения БД, в частности в [1-6]. Чаще всего выделяют 4-е нормальные формы представления реляционных таблиц. Нет никаких гарантий того, что реляци­онные таблицы, полученные после этапов преобразования, удовлетворяют этим правилам. Более того, они, скорее всего, нормальным формам не удовлетворяют.

Если данные из реляционных таблиц добавляются к таблицам суще­ствующей, нормализованной БД, а структура добавляемых данных совпадает со структурой таблиц БД, то проблема нормализации не стоит, т.к. предполагается, что БД спроектирована, нормализована и изменениям не подлежит.

Если данные из реляционных таблиц добавляются к таблицам суще­ствующей, нормализованной БД, а структура добавляемых данных не совпадает со структурой таблиц БД, то возникает проблема нормализации и преобразования структур добавляемых данных.

Если создается новая БД или к существующей БД добавляются новые таблицы, то проблема нормализации актуальна. В связи с этим следующим этапом преобразования информации таб­личного вида в файлы БД должен быть этап нормализации реляционных таблиц.

Реляционные таблицы находятся в 1-й нормальной форме, если значения в таб­лице являются атомарными для каждого атрибута таблицы. Другими словами в таб­лице не должно быть подзаголовков. Этому требованию, если следовать предложен­ным этапам преобразования информации, реляционные таблицы уже должны удовлетворять.

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

Реляционные таблицы соответствуют 3-й нормальной форме, если устранены транзитивные зависимости между атрибутами отношения. Другими словами, неклю­чевые поля таблицы не должны зависеть друг от друга, а должны зависеть только от ключевого поля. Опосредовано выявить нарушение нормализации такого рода можно, если обнаружить часто повторяющиеся поля или группы полей в записях таблицы. В связи с этим процесс приведения к 3-й нормальной форме можно автома­тизировать, что и реализовано в некоторых системах управления базами данных, в частности в Microsoft Access. Однако результаты нормализации после использования предла­гаемых средств не всегда удовлетворительны, и в этом направлении имеет смысл работать.

Реляционные таблицы соответствуют 4-й нормальной форме, если между реляци­онными таблицами устранены многозначные зависимости. Между таблицами имеет место многозначная зависимость, если записи одной таблицы связаны с несколькими записями другой и наоборот. Для устранения многозначной зависимости вводится третья таблица, в которой хранятся ключевые поля первых 2-х таблиц. Многознач­ную зависимость между таблицами можно описать формально. В связи с этим, веро­ятнее всего, процесс приведения реляционных таблиц к 4-й нормальной форме можно автоматизировать.