- •7. Базы данных
- •7.1. Объекты, атрибуты, связи
- •7.2. Модели данных
- •7.2.1. Иерархическая модель данных
- •7.2.2. Сетевая модель данных
- •7.2.3. Реляционная модель данных
- •7.3. Этапы разработки базы данных
- •7.4. Безопасность баз данных
- •7.5. Системы управления базами данных
- •7.6. Создание базы данных
- •7.6.1. Нормализация
- •7.6.2. Задание первичных ключей
- •7.6.3. Установление связей между таблицами Реляционные базы данных состоят из нескольких таблиц.
- •7.6.4. Пример
- •7.6.5. Свойства полей базы данных.
- •7.7. Конструирование запросов
- •7.8. Конструирование форма и отчетов
7.6.4. Пример
Пусть некая фирма занимается торговлей кондитерскими изделиями. Клиентами фирмы являются рестораны, кафе, клубы и т.п. для учета и анализа заказов фирма может вести таблицу с именем Заказы и со следующими полями (табл. 7.6.4.1)
Таблица 7.6.4.1.
Имя поля |
Тип поля |
Номер накладной |
Числовой (целое) |
Код клиента |
Числовой (целое) |
Наименование клиента |
Текстовый |
Телефон |
Текстовый |
Дата создания фирмы |
Дата/время |
Код продукта |
Числовой (целое) |
Название продукта |
Текстовый |
Количество |
Числовой (с плав. точкой.) |
Дата поставки |
Дата/время |
Цена |
Числовой (с плав. точкой.) |
Стоимость |
Числовой (с плав. точкой.) |
Каждая строка этой таблицы содержит полную информацию о конкретном заказе, а вся таблица в целом дает возможность не только вести учет, но и анализировать деятельность фирмы.
Таблицу Заказы мы спроектировали плохо. Например, мы включили в нее поля Телефон и дата создания фирмы, значения которых зависят от значения кода клиента, но не зависит от ключа нашей таблицы – номера накладной. Вводя многократно одни и те же данные (наименование клиента, его телефон и дату создания фирмы), мы не только проделаем массу лишней работы, но и неминуемо ошибемся (и не один раз). Поэтому следует удалить поля наименование клиента, телефон и ДАТА СОЗДАНИЯ ФИРМЫ из таблицы ЗАКАЗЫ, и включить их в классификатор (словарь) КЛИЕНТЫ, имеющий четыре поля – код, наименование, телефон клиента и дату создания фирмы.
Продолжив рассмотрение таблицы ЗАКАЗЫ, мы обнаружим еще три лишних поля – НАЗВАНИЕ ПРОДУКТА, ЦЕНА ПРОДУКТА, СТОИМОСТЬ. Значения первых двух полей не зависят от номера накладной, но зависят от кода продукта. Поэтому и место этих полей в классификаторе ПРОДУКТЫ (код, название, цена).
Значение поля СТОИМОСТЬ – это произведение цены на количество, поэтому его вообще не следует включать в таблицы: система обязана при необходимости просто вычислить стоимость заказа.
В результате из исходной таблицы ЗАКАЗЫ мы получили три таблицы: оперативную таблицу ЗАКАЗЫ, классификатор КЛИЕНТЫ и классификатор ПРОДУКТЫ. Этот процесс называется нормализацией.
Таблица КЛИЕНТЫ связана с таблицей ЗАКАЗЫ по полю Код клиента, а таблица ПРОДУКТЫ связана с таблицей ЗАКАЗЫ по полю Код продукта. В паре КЛИЕНТЫ – ЗАКАЗЫ первая таблица считается главной, а вторая – подчиненной. Поле Код клиента является для первой таблицы первичным ключом, а для второй таблицы – внешним ключом. Кроме того, вторая таблица имеет собственной первичный ключ (Номер накладной).
Легко видеть, что каждому значению первичного ключа в главной таблице соответствует одна, несколько или ни одной записи в подчиненной таблице. В самом деле, таблица ЗАКАЗЫ содержит перечень заказов какой-то группы клиентов за определенный промежуток времени. Ясно, что какой-то клиент за это время мог сделать и один, и несколько заказов, а мог и вообще не заказывать продукты.
Такое отношение между двумя таблицами называется связью «Один-ко-Многим».
Аналогичная связь наблюдается между таблицами ПРОДУКТЫ – ЗАКАЗЫ по полю Код продукта.
Рис.7.6.4.1. Окно Схема данных