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

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

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

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

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

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

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

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

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