Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Проектирование схемы данных.doc
Скачиваний:
6
Добавлен:
24.08.2019
Размер:
212.99 Кб
Скачать

Заказы потребителей

N

Наименование

Тип

1

Код потребителя

Числовой

2

Код товара

Числовой

3

Цена

Денежный

4

Количество

Числовой

5

Дата поставки

Дата/Время

Между таблицами Поставки товаров и Заказы потребителей существует отношение «много-ко-многим», так как на каждый поставляемый товар может быть более одного заказа. Аналогично, каждый заказанный товар может производиться более чем одним предприятием.

Связь между таблицами устанавливается на основании значений в совпадающих полях Код товара.

Проектирование нормализованных баз данных

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

  • Обеспечить быстрый доступ к данным в таблицах

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

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

Теория нормализации оперирует с пятью нормальными формами таблиц (от первой до пятой включительно).

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

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

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

Пример: таблица Продажи, содержащая следующую информацию:

  • Сведения о покупателях

  • Дату заказа и количество заказанного товара

  • Дату выполнения заказа и количество проданного товара

  • Характеристику проданного товара (наименование, стоимость, марка)

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

Проблемы, возникающих при работе с базой такой структуры

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

  • При изменении адреса или телефона покупателя необходимо корректировать все записи, содержащие сведения о заказах этого покупателя

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

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

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

Таблица Продажи

N

Тип

1

Код клиента

Числовой

2

Фамилия

Текстовый

3

Имя

Текстовый

4

Отчество

Текстовый

5

Телефон -

Текстовый

6

Факс

Текстовый

7

Индекс

Текстовый

8

Страна

Текстовый

9

Город

Текстовый

10

Адрес

Текстовый

11

Предприятие

Текстовый

12

Руководитель

Текстовый

13

Кредит

Денежный

14

Примечание

Memo

15

Код товара

Числовой

16

Дата заказа

Дата/Время

17

Заказано

Числовой

18

Дата продажи

Дата/Время

19

Продано

Числовой

20

Цена

Денежный

21

Примечание к заказу

Memo

22

Категория

Числовой

23

Наименование товара

Текстовый

Таблица приведенной структуры является ненормализованной.

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

Первая нормальная форма таблицы

Таблица в первой нормальной форме должна удовлетворять следующим требованиям:

  1. Таблица не должна иметь повторяющихся записей.

  2. В таблице должны отсутствовать повторяющиеся группы полей.

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

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

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

Таблица Заказы

N

Наименование

Тип

1

Код клиента

Числовой

2

Код товара

Числовой

3

Дата заказа

Дата/Время

4

Заказано

Числовой

5

Дата продажи

Дата/Время

5

Продано

Числовой

7

Цена

Денежный

8

Примечание к заказу

Memo

99

Таблица Клиенты

Наименование

Тип

1

Код клиента

Числовой

2

Фамилия, И., О.

Текстовый

3

Телефон -

Текстовый

4

Факс

Текстовый

5

Индекс

Текстовый

6

Страна

Текстовый

7

Город

Текстовый

8

Адрес

Текстовый

9

Предприятие

Текстовый

10

Руководитель

Текстовый

11

Кредит

Денежный

12

Примечание

Memo

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

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

1) Добавим в таблицу новое уникальное ключевое поле Код заказа, что позволит однозначно идентифицировать каждый из заказов.

Однако при работе с MS Аccess это — далеко не лучший метод: при разработке многотабличных форм и отчетов связь между таблицами осуществляется посредством индексов. Ввод нового ключевого поля в таблицу Заказано не позволит связать таблицы Клиенты и Заказы по значениям поля Код клиента при создании многотабличных форм и отчетов.

2)-й способ исключения повторяющихся записей: использован уникальный составной индекс, состоящий из полей Код клиента, Код товара и Дата заказа.

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

Вторая нормальная форма таблицы

О таблице говорят, что она находится во второй нормальной форме, если:

  1. Она удовлетворяет условиям первой нормальной формы.

  2. Любое неключевое поле однозначно идентифицируется полным набором ключевых полей.

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

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

Третья нормальная форма таблицы

Таблица находится в третьей нормальной форме, если:

  1. Она удовлетворяет условиям второй нормальной формы.

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

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

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

Таблица Клиенты

Наименование

Тип

1

Код клиента

Числовой

2

Фамилия, И., О.

Текстовый

3

Телефон -

Текстовый

4

Индекс

Текстовый

5

Страна

Текстовый

6

Город

Текстовый

7

Адрес

Текстовый

8

Предприятие

Т екстовый

9

Кредит

Денежный

10

Примечание

Memo

Таблица Менеджер

Наименование

Тип

1

Предприятие

Т екстовый

2

Руководитель

Текстовый

Таблица Заказы

N

Наименование

Тип

1

Код клиента

Числовой

2

Код товара

Ч исловой

3

Дата заказа

Дата/Время

4

Заказано

Числовой

5

Дата продажи

Дата/Время

5

Продано

Числовой

7

Цена

Денежный

8

Примечание к заказу

Memo

Таблица Товары

Наименование

Тип

1

Код товара

Числовой

2

Категория

Числовой

3

Наименование товара

Текстовый

Требование, чтобы все таблицы были нормализованы, не является обязательным в MS Access. Однако в рассмотренном примере при проектировании многотабличной базы данных можно отметить определенные преимущества использования нормализованных таблиц.

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

Определение связей между таблицами

В MS Access вы можете устанавливать постоянные связи между таблицами, которые будут поддерживаться при создании форм, отчетов и запросов.

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

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

Отношение «один-ко-многим» — создается в том случае, когда только одно из полей является ключевым или имеет уникальный индекс

Отношение «один-к-одному» — создается в том случае, когда оба связываемых поля являются ключевыми или имеют уникальные индексы

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

В окне диалога «Схема данных» при переносе поля, не являющегося ключевым или не имеющего уникального индекса, на другое поле, которое также не является ключевым или не имеет уникального индекса, создается неопределенное отношение. В запросах, содержащих таблицы с неопределенным отношением, MS Access по умолчанию создает объединения между таблицами, но условия целостности данных при этом не поддерживаются и нет гарантии уникальности записей в таблицах.

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

  • Изменить структуру таблицы

  • Изменить существующую связь

  • Удалить связь

  • Удалить таблицу из окна диалога «Схема данных»

  • Вывести на экран все существующие связи или связи только для конкретной таблицы

  • Определить связи для запросов, не задавая условия целостности данных