Контрольная работа по "Базы данным"

    Атрибуты  не упорядочены (слева направо). Т.к. каждый атрибут имеет уникальное имя в пределах отношения, то порядок  атрибутов не имеет значения. Это  свойство несколько отличает отношение  от математического определения  отношения. Это также третья причина, по которой нельзя отождествить отношения  и таблицы - столбцы в таблице  упорядочены. Одно и то же отношение  может быть изображено разными таблицами, в которых столбцы идут в различном  порядке.

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

    Из  свойств отношения следует, что  не каждая таблица может задавать отношение. Для того, чтобы некоторая таблица задавала отношение, необходимо, чтобы таблица имела простую структуру (содержала бы только строки и столбцы, причем, в каждой строке было бы одинаковое количество полей), в таблице не должно быть одинаковых строк, любой столбец таблицы должен содержать данные только одного типа, все используемые типы данных должны быть простыми.

    Каждое  отношение можно считать классом  эквивалентности таблиц, для которых  выполняются следующие условия:

    Таблицы имеют одинаковое количество столбцов.

    Таблицы содержат столбцы с одинаковыми  наименованиями.

    Столбцы с одинаковыми наименованиями содержат данные из одних и тех же доменов.

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

    Все такие таблицы есть различные  изображения одного и того же отношения.  

2. Сущность  нормализации, ее место  в прцессе проектирования. Базовые нормальные формы. Этапы нормализации. Примеры отношений в различных формах.

 
 

     Нормализация - это набор стандартов проектирования данных, называемых нормальными  формами (normal forms). Общепринятыми считаются пять нормальных форм, хотя их было предложено значительно больше. Создание таблиц в соответствии с этими стандартами называется нормализацией. Нормальные формы изменяются в порядке от первой до пятой. Каждая последующая форма удовлетворяет требования предыдущей. Если следовать первому правилу нормализации, то данные будут представлены в первой нормальной форме. Если данные удовлетворяют третьему правилу нормализации, они будут находиться в третьей нормальной форме (а также в первой и второй формах).  

     Выполнение  правил нормализации обычно приводит к разделению таблиц на две или  больше таблиц с меньшим числом столбцов, выделению отношений первичный  ключ - внешний ключ в меньшие  таблицы, которые снова могут  быть соединены с помощью операции объединения.  

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

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

Первая  нормальная форма.  

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

     В ряде случаев объектное моделирование  приводит к тем же результатам, так  как в этом случае мы имеем отношение  один-ко-многим (одна накладная - много  позиций).  

Вторая  нормальная форма  

     Второе  правило нормализации требует, чтобы  любой не ключевой столбец зависел  от всего первичного ключа. Следовательно, таблица не должна содержать не ключевых столбцов, зависящих только от части  составного первичного ключа. Представление  таблицы во второй нормальной форме  требует, чтобы все столбцы, не являющиеся первичными ключами (столбцы, описывающие  объект, но однозначно не идентифицирующие его), зависели от всего первичного ключа, а не от его отдельных компонентов.  

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

Третья  нормальная форма 

     Третья  нормальная форма повышает требования второй нормальной формы: она не ограничивается составными первичными ключами. Третья нормальная форма требует, чтобы  ни один не ключевой столбец не зависел  от другого не ключевого столбца. Любой не ключевой столбец должен зависеть только от столбца первичного ключа.  

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

Четвертая и пятая нормальные формы  

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

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

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

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

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

3. Задача.

Создайте  базу данных для хранения следующей информации: код владельца, номер  автомобиля, марка  автомобиля, дата выпуска, дата регистрации.

Разработать запросы:

- получить список  номеров и марок  автомобилей, зарегистрированных  в ноябре и декабре  прошлого года;

- найти средний  «возраст» по каждой  из встречающихся  марок автомабилей;

- найти «возраст»  с точностью до  года каждого из  автомобилей, зарегистрированных  в феврале и  марте текущего  года;

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

 

1.Создание таблиц 

Исходя из условий  задания приходим к выводу, что необходимо создать три таблицы со следующими полями:

Автосалон –  № продажи, Дата, Марка автомобиля, Цвет, № покупателя.

Покупатель –  № покупателя, ФИО, Адрес, Телефон.

Автомобили –  Марка автомобиля, Страна-производитель, Гарантийный срок, Стоимость.

Для создания таблицы  Автомобили выполняем следующие  действия:

В окне созданной  базы, находясь в пункте меню «Таблицы», нажимаем пункт «Создание таблицы  в режиме конструктора».

В появившемся  окне в первой строке графы «имя поля», набираем имя «Марка автомобиля», тип данных выбираем текстовый, в  свойствах поля размер поля оставляем как предлагается по умолчанию 50.

Во второй строке в графе «имя поля» набираем «Страна-производитель», тип данных выбираем Мастер подстановок, далее печатаем страны в столбец.

В третьей строке в графе «имя поля» набираем «Гарантийный срок», тип данных выбираем текстовый.

В четвертой  строке набираем «Стоимость», тип данных выбираем денежный.

Закрываем конструктор, выбираем сохранить изменения и  в появившемся окне вводим имя  таблицы «Автомобили» и нажимаем «ОК». 

 

Для создания таблицы  «Покупатель» выполняем те же действия, но создаем следующие поля со свойствами:

№ покупателя –  Числовой;

ФИО – Текстовый;

Адрес – Текстовый;

Телефон – Числовой.

Закрываем конструктор, выбираем сохранить изменения и  в появившемся окне вводим имя  таблицы «Покупатель» и нажимаем «ОК». 

 

Созданные две  таблицы будет в дальнейшем использоваться как словари при вводе данных в основную таблицу, чтобы не вводить  повторяющиеся значения такие как № покупателя и Марка автомобиля.

Для создания таблицы  «Автосалон» выполняем те же действия, но создаем следующие поля со свойствами:

№ продажи –  Счетчик.

Дата – Дата/Время.

Марка автомобиля – тип данных мастер подстановок, связь этого поля будет в дальнейшем с полем «Марка автомобиля» из таблицы «Автомобили».

Цвет – Мастер подстановок, и вводим несколько  цветов в столбец.

№ покупателя - тип данных мастер подстановок, связь  этого поля будет в дальнейшем с полем «№ покупателя» из таблицы  «Покупатель».