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

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

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

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

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

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

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 Тульский механический завод.

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

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