Добавил:
Меня зовут Катунин Виктор, на данный момент являюсь абитуриентом в СГЭУ, пытаюсь рассортировать все файлы СГЭУ, преобразовать, улучшить и добавить что-то от себя Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Информатика / Методички / Методичка Патлань_Киселева.doc
Скачиваний:
13
Добавлен:
02.08.2023
Размер:
971.26 Кб
Скачать

6. Особенности проектирования реляционных баз данных

6.1.Понятие реляционной базы данных

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

Таблица 2

№№

ИМЯ ПОЛЯ

ТИП ПОЛЯ

1

Фамилия

Текстовый

2

Имя

Текстовый

3

Отчество

Текстовый

4

Почтовый индекс

Текстовый

5

Страна

Текстовый

6

Город

Текстовый

7

Адрес

Текстовый

8

Кредит

Денежный

9

Примечание

МЕМО или OLE

10

Категория товара

Текстовый

11

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

Текстовый

12

Фирма-производитель

Текстовый

13

Цена

Денежный

14

Дата заказа

Дата/Время

15

Заказано

Числовой

16

Дата продажи

Дата/Время

17

Продано

Числовой

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

Поэтому целесообразно разбить эту таблицу на четыре таблицы “КЛИЕНТЫ”, “ЗАКАЗЫ И ПРОДАЖИ”, “ТОВАРЫ” и "ПОСТАВЩИКИ", установив связи между ними, например, так, как показано на рис. 6.1.

Рис. 6.1. Схема данных в реляционной БД

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

6.2. Первичные ключи и индексирование

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

В Access допускается определение первичных ключей трех типов:

  • Ключевые поля счетчика. Поле счетчика можно задать таким образом, чтобы при добавлении каждой новой записи в таблицу в это поле автоматически вносился порядковый номер. Указание такого поля в качестве ключевого является наиболее простым способом создания первичного ключа. Если до сохранения созданной таблицы ключевые поля не были определены, Access предлагает создать ключевое поле автоматически. При нажатии кнопки "Да" будет создано ключевое поле счетчика.

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

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

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

Рис. 6.2. Пример таблицы, требующей создания составного ключа

Для создания составного ключа следует в режиме конструктора выделить нужные поля, удерживая клавишу CTRL, а затем выполнить команду ПРАВКА/КЛЮЧЕВОЕ ПОЛЕ (кнопка ).

Если порядок полей в составном первичном ключе должен отличаться от порядка полей в таблице, следует выполнить команду ВИД/ИНДЕКСЫ (кнопка на панели инструментов), чтобы открыть окно "Индексы". В этом окне и следует указать другой порядок полей для индекса с именем "PrimaryKey" (см. рис.6.3).

Рис. 6.3. Окно для изменения порядка полей в составном ключе

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

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

Пример окна для создания индексированного поля типа "Да (Совпадения не допускаются)" приведён на рис. 6.4 – это поле "КОД ТОВАРА" таблицы "ТОВАРЫ".

Рис. 6.4. Вид таблицы "ТОВАРЫ" в режиме конструктора

Такой тип индексации описывает уникальное поле, т.е. товары могут иметь повторяющиеся значения в полях "КАТЕГОРИЯ", "НАИМЕНОВАНИЕ" и даже "ЦЕНА", но поле "КОД ТОВАРА" однозначно идентифицирует этот товар.