Программирование и основы алгоритмизации
Назначение и задачи информационной системы управления АТП
Содержание работы


Близкие по теме работы


Популярные страницы


Используя пример таблицы Поставки, давайте предположим, что каждая поставка может включать только один продукт, и что таблица Поставки содержит столбцы ПОС (код Поставщика) и ПР (код Продукта). В таблице Поставки может храниться много записей, относящихся к поставщику ПОС=1, который может продавать множество продуктов. Кроме того, в той же таблице может быть много записей, содержащих информацию о продукте ПР=2. В этом случае говорят, что столбцы ПОС  и ПР находятся во взаимоотношении типа многие-ко-многим. Для каждого ПР в таблице Поставки может существовать много поставщиков и для каждого ПОС — много продуктов ПР. Четвертая нормальная форма требует, чтобы вы запомнили такие элементы в отдельных таблицах и создали таблицу отношений для организации связей между таблицами, характеризующихся взаимоотношениями типа многие-ко-многим.

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

Пятая нормальная форма Пятая нормальная форма требует, чтобы вы имели возможность перестраивать свои данные в нормализованных таблицах, в которые они были переведены. Это значит, что если вы начинаете с ненормализованных таблиц, то у вас не должно быть препятствий к вырезке и вставке данных и после нормализации. Это осуществимо, если есть гарантия, что в процессе нормализации не будет потери данных. Например, если вы начинаете с таблицы СЧЕТА, которая включает столбцы КодКлиента и НаименованиеКлиента, то нормализация базы данных заставит вас создать отдельную таблицу КЛИЕНТЫ и перенести в нее столбец НаименованиеКлиента. Конечно, вы скопируете в ту же таблицу и столбец КодКлиента. Но если вы по ошибке просто удалите столбец НаименованиеКлиента из таблицы СЧЕТА, то вы не сможете перестраивать свою исходную ненормализованную таблицу, так как столбец НаименованиеКлиента больше не существует в вашем новом проекте, который, таким образом, противоречит пятой нормальной форме.

На практике идея сохранения всех элементов в базе данных в процессе нормализации воплощается чисто интуитивно. Вы ведь вряд ли будете слепо выбрасывать из таблиц элементы данных. Но тем не менее, пятая нормальная форма призвана застраховать вас от такого несчастного случая.

6. Нормализуй, но знай меру! Приступив к нормализации своих данных, важно не зайти слишком далеко. Иначе нормализация может оказать отрицательное влияние на производительность.

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

Несмотря на то, что дату истечения срока действия можно прочитать прямо из каждой кредитной карточки, когда она посылается вам как часть приходной записи, вы предпочитаете использовать другой источник, а именно, базовую таблицу кредитных карточек. Этот реляционный проект выглядит лучше, но, к сожалению, дополнительная операция присоединения потребует удвоенных затрат времени. Причем эта выборка выполняется настолько долго, что пользователь может счесть производительность такого приложения неприемлемой.

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

Отсюда следует, что при введении в проект базы данных контролируемой избыточности необходимо сначала полностью нормализовать базу данных, а затем ввести избыточность только в случае абсолютной необходимости.

Лекция 7 Пример проектирования базы данных Библиотека

План

О авторе

Артюшин Евгений Александрович

Биография

Артюшин Евгений Александрович - преподаватель Хабаровского государственного технического...
далее



Отзывы посетителей
Вот всегда все для прогульщиков и халявщиков. Поче...
Автор: Гаусс
Жалко, что здесь не выложены практические задания ...
Автор: Варвара
Классно!!! Давно искала такой курс лекций. Большое...
Автор: Римма
Такие слабенькие лекции вы выложили на сайте. У на...
Автор: Жорж


Афоризм

Рискуйте! Если вы победите, то будете счастливы, а если проиграете, то будете мудрыми.



Цитата работы
...«Назначение и задачи информационной системы управления АТП Лекция 1. Назначение и задачи информационной системы управления АТП План лекции: 1. Общи»...
подробнее

Наука России - Наше будущее!