22.Реляционные базы данных. Сущности, атрибуты, связи. Ключевые поля.

Реляционная модель данных

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

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

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

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

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

1. В реляционных БД совокупности данных представляются в виде двумерных таблиц (подобных описанному выше примеру).

2. Каждая таблица состоит из фиксированного числа столбцов (доменов). Количество строк - переменное число.

3. Каждый столбец представляет конкретное данное (код фирмы, код продукции и т.д.). На языке БД столбцы называются полями (естественно при этом рассматривать одну запись- строку). Для каждого поля разработчик должен определить:

• уникальное имя поля;

• тип поля;

• длину поля.

Например, поле «Себест» может иметь тип «Числовое» и длину 7 (4 знака до точки и 2 знака после точки).

«Поле»- это наиболее распространенный термин, заменяющий слово «данное».

4. Каждая строка таблицы на языке БД называется записью. Записи нумеруются по порядку 1, 2, …., n, где n- число на данный момент. Добавление записей- нормальная рабочая операция. Добавление полей - реорганизация БД – сфера действий системного программиста.

5. Каждое поле может входить в несколько таблиц, например «Катег.»

Рассмотрим еще пару типичных примеров.

Пример 1. Учет заказов на продукцию завода.

ZAKAZ

1. Ном_зак - номер заказа.

2. Код_зак - код заказчика.

3. Банк_рек - банковские реквизиты заказчика.

4. Код_прод - код продукции.

5. Объем - объем заказа в кг.

6. Дат_исп - дата исполнения заказа (ДД / ММ / ГГ).

7. Цена - цена продукции (руб/кг).

Пример 2.

KADR

1. ФИО

2. Год­_рожд

3. Образов

4. Должность

5. Оклад

Рассматривая эти таблицы, замечаем, что в них используется код, а не прямо имя завода заказчика. В связи с этим возникает вопрос - почему используется код, хотя компьютер может обрабатывать и символы? Первый очевидный ответ - из экономии. Но есть и более важный аспект- проблема одинаковости ввода. Например, название «Тульский механический завод» могут разные люди вводить как Тульск. мех. завод, Тульск. мех. з-д и т.п. Проблема решается также как и в примере с телефонным справочником - КАТЕГ, то есть в базу вводят словарь, в котором для этого конкретного случая будет строка, например:

708 Тульский механический завод.

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

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

Главный ключ системы

Для выполнения операций над данными необходимо иметь для каждой записи (строки) таблицы уникальный идентификатор, значение которого однозначно определяет только эту запись. Этот идентификатор называют Главный ключ (primary key). Он может состоять из одного или нескольких полей. Например, в TELEF (телефонный справочник, см. пример)- роль ключа выполняет одно поле- Номер телефона, а в SEBEST- 3 поля: Фирма, Прод., Сх.

Главный ключ должен обладать двумя свойствами:

1. Однозначной идентификацией записи.

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

В примере ZAKAZ - главным ключом является номер завода (поскольку бессмысленно иметь иначе).

Главным ключом в таблице KADR «просится» быть Ф.И.О…. (посмотрим далее).

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

Вернемся к Ф.И.О.- это не надежный ключ. Более надежным является в пределах предприятия - табельный номер; в пределах страны - номер и серия паспорта или просто один номер (как в США- social secuirity number).

Слово «главный» предполагает и наличие неглавного или простого (вторичного) ключа. Этот термин возникает в операции, подразумевающей просмотр по какому-либо полю. Например, по полю «Катег» в примере с телефонным справочником. Т.е. при этом «Катег»- это простой ключ и его значение может быть неуникальным.

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

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

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