![]() Главная страница Случайная страница КАТЕГОРИИ: АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника |
Нормализация данных
Теперь займемся проектированием эффективной структуры данных. Теория реляционной базы данных была разработана в начале 70-х годов прошлого века Коддом (E. F. Codd) на основе математической теории отношений. В реля- ционной базе данных все данные хранятся в виде таблиц, при этом все операции над базой данных сводятся к манипуляциям таблицами. Основными понятиями в этой теории являются: таблица, строка, столбец, индекс, первичный и внешний ключи, связи. Таблица состоит из строк и столбцов и имеет уникальное имя в базе данных. База данных содержит множество таблиц, связь между которыми устанавливается с помощью совпадающих полей. В каждой из таблиц содержится информация о каких-либо объектах одного типа. Приступая к созданию нового приложения, главное — самым тщательным образом спроектировать структуру его таблиц. Если не уделить структуре должного внимания, то в лучшем случае это может проявиться в неэффективной работе приложения, а в худшем — в невозможности реализации некоторых требований к системе в целом. И, наоборот, при хорошей организации набора таблиц будут решены не только текущие проблемы, но и потенциальные, которые в данный момент вы не могли предвидеть. В общем, структура данных является определяющим фактором успеха или провала всего приложения. Э. Ф. Кодд доказал, что, следуя при создании таблиц и связей между ними только немногим формализованным правилам, можно обеспечить простоту манипулирования данными. Его методика получила наименование нормализации данных. Теория реляционных баз данных основана на концепции использования ключевых полей для определения отношений между таблицами. Чем больше таблиц, тем больше отношений требуется определить, чтобы связать их между собой. Из теории Кодда отнюдь не следует, что каждая таблица должна быть напрямую связана с любой другой таблицей. Но, поскольку каждая таблица связана хотя бы с одной таблицей в базе данных, можно утверждать, что все таблицы в базе имеют прямые или косвенные отношения друг с другом. Мы установили, какие поля будут включены в базу данных. Следующий этап состоит в разделении их на таблицы. Конечно же, можно было бы работать с приведенной выше единственной таблицей " Недвижимость", но даже не знающим правил нормализации ясно, что для каждого проживающего в квартире не имеет смысла повторять всю информацию о здании, квартире, ответственном квартиросъемщике и лицевом счете, а при переименовании улицы — вносить исправления в тысячи записей, содержащих сведения о технических характеристиках квартиры. Наличие повторяющейся информации приведет к неоправданному увеличению размера базы данных. В результате снизится скорость выполнения запросов. При многократном вводе повторяющихся данных возрастет вероятность ошибки. Представьте себе ситуацию, связанную с вводом данных о проживающих на Восточном шоссе. Это пять тысяч человек. Вот несколько вариантов адреса: Шоссе Восточное, Восточное шоссе, ш. Восточное, ш-се Восточное. А сколько еще вариантов может появиться у пользователя, работающего с вашей программой. О грамматических ошибках и вариантах с номером дома, запятыми и точками в адресе позволю себе умолчать. Какую информационно-поисковую систему мы получим в результате? Скорее всего, искать можно — найти нельзя! Вашему вниманию — несколько советов по включению полей в таблицы. П Включайте поля, относящиеся только к предметной области таблицы. Поле, представляющее факт из другой предметной области, должно принадлежать другой таблице. Позже, при установлении отношений между таблицами, вы увидите, как можно объединить данные нескольких полей из разных таблиц. А на этом этапе убедитесь, что каждое поле таблицы описывает только одну предметную область. Если вы обнаружите, что в разных таблицах встречается однотипная информация, значит, какие-то таблицы содержат лишние поля. П Не включайте производные или вычисляемые данные. В большинстве случаев вам нет необходимости хранить результаты вычислений в таблице. С помощью Microsoft Access вы всегда сможете выполнить данные вычисления в нужный момент. Не имеет смысла хранить итоговые поля в таблице. П Включите всю необходимую информацию. Довольно легко упустить важные данные. Вернитесь к собранным на первой стадии проектирования материалам. Внимательно рассмотрите бланки и отчеты и убедитесь в том, что вся интересующая вас информация может быть извлечена или вычислена из таблиц. Подумайте о вопросах, которые вы будете формулировать к базе данных. Сможете ли вы получить на них ответ, используя данные из ваших таблиц? Включили ли вы поля, в которых будут храниться уникальные данные типа кода клиента? Какие таблицы содержат информацию, обязательную для создания отчета или формы? П Разделите информацию на наименьшие логические единицы. Вам может показаться, что удобно иметь одно поле для хранения полного имени клиента или одно поле для названия и описания продукта. Это ошибка. Если вы объединяете более одной категории информации в одном поле, потом вам будет очень не просто выделить из него отдельные факты. Постарайтесь разбить информацию на наименьшие логические части. Воспользуемся практическими рекомендациями теории нормализации для разработки на основании таблицы " Недвижимость" многотабличной базы данных Real Estate. На рис. 1.1 вы видите то, что у вас должно получиться после всех манипуляций, кратко изложенных выше и предусмотренных теорией нормализации. Практический же путь к этому результату смотрите на следующих полутора десятках страниц.
|