Основные сведения о создании баз данных. Проектирование базы данных

Каждая таблица содержит информацию на отдельную тему, а каждое поле в таблице содержит отдельные сведения по теме таблицы. Например, в таблице с данными о клиенте могут содержаться поля с названием компании, адресом, городом, страной и номером телефона. При разработке полей для каждой таблицы необходимо помнить:

Каждое поле должно быть связано с темой таблицы.

В таблице должна присутствовать вся необходимая информация.

Информацию следует разбивать на наименьшие логические единицы (Например, поля «Имя» и «Фамилия», а не общее поле «Имя»).

4. Задание индивидуального значения каждому полю

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

5. Определение связей между таблицами

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

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

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

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

7. Добавление данных и создание других объектов базы данных

Если структуры таблиц отвечают поставленным требованиям, то можно вводить все данные. Затем можно создавать любые запросы, формы, отчеты, макросы и модули.

8. Использование средств анализа в Microsoft Access

В Microsoft Access существует два инструмента для усовершенствования структуры баз данных. Мастер анализа таблиц исследует таблицу, в случае необходимости предлагает новую ее структуру и связи, а также переделывает ее.

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

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

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

Скачать заметку в формате или , примеры в формате

Анализ «что если» на основе Таблицы с одной переменной

На рис. 21.1 в ячейки В6 используется функция ПЛТ, косвенно зависящая от значения ячейки В2. Если вы измените годовую ставку ставка, функция ПЛТ обновит значение в ячейке В6. Цель состоит в том, чтобы одновременно увидеть, как месячный платеж будет меняться при пяти различных годовых ставках. Хотя это можно сделать путем написания формулы, функция Таблица может быть полезна по двум причинам:

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

Чтобы создать таблицу данных:

Создайте заголовки А9:В9. В ячейке В10 введите формулу =В6. В ячейки А11:А15 введите значения годовой ставки для анализа. Выделите диапазон А10:В15.
Пройдите по меню ДАННЫЕ –> Анализ «что если» –> Таблица данных , чтобы открыть диалоговое окно Таблица данных , или нажав и удерживая клавишу Alt, последовательно нажмите Ы, Ё, Т (после нажатия Alt в меню будут появляться подсказки).
Поскольку вы анализируете влияние годовой ставки, укажите ссылку на нее в поле Подставлять значение по строкам в (рис. 21.2). Вы говорите Таблице данных , заменить значение из ячейки В2 в процессе расчета ПЛТ и вместо него подставить в формулу значения из диапазона А11:А15.
Нажмите ОК.

Рис. 21.2. Диалоговое окно Таблица данных

Если вы выделите диапазон В11:В15 и взглянете на строку формул, то увидите формулу массива Таблица со ссылкой на ячейку В2. Функцию Таблица нельзя ввести с клавиатуры; она автоматически создается при использовании диалогового окна Таблица данных .

Рис. 21.3. Функцию Таблица можно ввести только с помощью диалогового окна Таблица данных

На рис. 21.4 ячейки в диапазон E3:I3 содержат различные формулы, которые прямо или косвенно ссылаются на число проданных штук (в ячейке В3). Используя Таблицу данные можно выполнить анализ «что если» для пяти формул. Причем все они основываются на одной и той же переменной, расположенной в диапазоне D4:D12.

Рис. 21.4. Одна переменная Таблицы данных может работать на нескольких формулах; чтобы увеличить изображение кликните на нем правой кнопкой мыши и выберите Открыть картинку в новой вкладке

Две переменные в Таблице данных

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

Рис. 21.5. Таблица данных с двумя переменными

Второй пример (рис. 21.6) вы уже видели в . Там использовалась формула массива. Например, в ячейке F9: =ИНДЕКС($C$2:$C$15;ПОИСКПОЗ($E9&F$8;$A$2:$A$15&$B$2:$B$15;0)). Решение на основе Таблицы данных проще, и работает быстрее.

Рис. 21.6. Использование Таблицы данных , как альтернатива ВПР по двум параметрам

Одно заключительное замечание по поводу Таблицы данных : существует параметр, который позволяет отключить автоматическое обновление Таблиц данных , при этом другие формулы будут пересчитываться автоматически. Если ваш файл «тормозит», пройдите по меню ФАЙЛ –> Параметры , перейдите на вкладку Формулы , и выберите опцию автоматически, кроме таблиц данных (рис. 21.7). Когда вы всё же захотите обновить вычисления в Таблице данных , нажмите F9.

Рис. 21.7. Отключение автоматического вычисления Таблиц данных

Реляционная модель данных (РМД) некоторой предметной области представляет собой набор отношений, изменяющихся во времени.

При создании информационной системы совокупность отношений позволяет хранить данные об объектах предметной области и моделировать связи между ними. Элементы РМД и формы их представления приведены в табл.1.

Отношение является важнейшим понятием и представляет собой двумерную таблицу, содержащую некоторые данные.

Сущность есть объект любой природы, данные о котором хранятся в базе данных. Данные о сущности хранятся в отношении.

Атрибуты представляют собой свойства, характеризующие сущность.

В структуре таблицы каждый атрибут именуется и ему соответствует заголовок некоторого столбца таблицы. Математически отношение можно описать следующим образом. Пусть даны n множеств %%D1, D2, D3,..., Dn%%, тогда отношение %%R%% есть множество упорядоченных кортежей %%%%, где %%dk \subset Dk%%, %%dk%% - атрибут, a %%Dk%% - домен отношения %%R%%.

На рис.1 приведен пример представления отношения СОТРУДНИК.

В общем случае порядок кортежей в отношении, как и в любом множестве, не определен. Однако, в реляционных СУБД для удобства кортежи все же упорядочивают. Чаще всего для этого выбирают некоторый атрибут, по которому система автоматически сортирует кортежи по возрастанию или убыванию. Если пользователь не назначает атрибута упорядочения, система автоматически присваивает номер кортежам в порядке их ввода.

Домен представляет собой множество всех возможных значений определенного атрибута отношения.

Отношение СОТРУДНИК включает 4 домена. Домен 1 содержит фамилии всех сотрудников, домен 2 - номера всех отделов фирмы, домен 3 - названия всех должностей, домен 4 - даты рождения всех сотрудников. Каждый домен образует значения одного типа данных, например, числовые или символьные.

Отношение СОТРУДНИК содержит 3 кортежа. Кортеж рассматриваемого отношения состоит из 4 элементов, каждый из которых выбирается из соответствующего домена. Каждому кортежу соответствует строка таблицы (рис.1).

Схема отношения (заголовок отношения) представляет собой список имен атрибутов. Например, для приведенного примера схема отношения имеет вид СОТРУДНИК (ФИО, Отдел, Должность, Дата рождения) . Множество собственно кортежей отношения часто называют содержимым (телом) отношения.

Первичным ключом (ключом отношения, ключевым атрибутом) называется атрибут отношения, однозначно идентифицирующий каждый из его кортежей.

Например, в отношении СОТРУДНИК (ФИО, Отдел, Должность, Дата рождения) ключевым является атрибут «ФИО». Ключ может быть составным (сложным), то есть состоять из нескольких атрибутов.

Каждое отношение обязательно имеет комбинацию атрибутов, которая может служить ключом. Ее существование гарантируется тем, что отношение - это множество, которое не содержит одинаковых элементов - кортежей. То есть в отношении нет повторяющихся кортежей, а это значит, что по крайней мере вся совокупность атрибутов обладает свойством однозначной идентификации кортежей отношения. Во многих СУБД допускается создавать отношения, не определяя ключи.

Возможны случаи, когда отношение имеет несколько комбинаций атрибутов, каждая из которых однозначно определяет все кортежи отношения. Все эти комбинации атрибутов являются возможными ключами отношения. Любой из возможных ключей может быть выбран как первичный.

Если выбранный первичный ключ состоит из минимально необходимого набора атрибутов, говорят, что он является не избыточным .

Ключи обычно используют для достижения следующих целей:

исключения дублирования значений в ключевых атрибутах (остальные атрибуты в расчет не принимаются);
упорядочения кортежей. Возможно упорядочение по возрастанию или убыванию значений всех ключевых атрибутов, а также смешанное упорядочение (по одним - возрастание, а по другим - убывание);
ускорения работы к кортежами отношения;
организации связывания таблиц.

Пусть в отношении R1 имеется не ключевой атрибут А, значения которого являются значениями ключевого атрибута В другого отношения R2. Тогда говорят, что атрибут А отношения R1 есть внешний ключ .

С помощью внешних ключей устанавливаются связи между отношениями.

Например, имеются два отношения Студент (ФИО, Группа, Специальность) и Предмет (Назв.Пр, Часы) , которые связаны отношением СТУДЕНТ_ПРЕДМЕТ(ФИО, Назв.Пр. Оценка) (рис.2). В связующем отношении атрибуты ФИО и Назв.Пр образуют составной ключ . Эти атрибуты представляют собой внешние ключи, являющиеся первичными ключами других отношений.

Рис.2. Связь отношений

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

Поскольку не всякой таблице можно поставить в соответствие отношение, приведем условия, выполнение которых позволяет таблицу считать отношением.

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

Если задаваемое таблицей отношение имеет ключ, то считается, что таблица тоже имеет ключ, и ее называют ключевой или таблицей с ключевыми полями . К отношениям можно применять систему операций, позволяющую получать одни отношения из других. Например, результатом запроса к реляционной БД может быть новое отношение, вычисленное на основе имеющихся отношений. Поэтому можно разделить обрабатываемые данные на хранимую и вычисляемую части.

Основной единицей обработки данных в реляционных БД является отношение , а не отдельные его кортежи (записи).

Как отмечалось выше, определение ключа для таблицы означает автоматическую сортировку записей, контроль отсутствия повторений значений в ключевых полях записей и повышение скорости выполнения операций поиска в таблице. Для реализации этих функций в СУБД применяют индексирование .

Термин «индекс» тесно связан с понятием «ключ», хотя между ними есть и некоторое отличие.

Под индексом понимают средство ускорения операции поиска записей в таблице, а следовательно, и других операций, использующих поиск: извлечение, модификация, сортировка и т. д. Таблицу, для которой используется индекс, называют индексированной.

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

Индексы, создаваемые пользователем для не ключевых полей, иногда называют вторичными (пользовательскими) индексами. Введение таких индексов не изменяет физического расположения записей таблицы, но влияет на последовательность просмотра записей.

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

Основными этапами проектирования базы данных являются:

· определение цели создания базы данных;

· определение таблиц, которые должна содержать база данных;

· определение необходимых в таблице полей;

· определение полей с уникальными значениями в каждой записи;

· определение связей между таблицами.

Определение цели создания базы данных

На первом этапе проектирования базы данных необходимо определить назначение базы данных, как она будет использоваться, и какие сведения она должна содержать. Зная это, можно определить, какие сведения будут храниться в таблицах и в полях таблиц. База данных должна отвечать требованиям тех, кто будет непосредственно с ней работать. Для этого нужно определить темы, которые должна покрывать база данных, отчеты, которые она должна выдавать, проанализировать документы, которые в настоящий момент используются для записи данных, сравнить создаваемую базу данных с хорошо спроектированной, подобной ей базой. Целью данной базы данных является получение как можно больше сведений о клиенте, а именно, фамилию, имя, отчество, адрес, телефон, а также услугу, которую необходимо выполнить для данного клиента.

Определение таблиц, которые должна содержать база данных

Определение необходимых в базе данных таблиц может оказаться самым непростым этапом процесса проектирования базы данных, поскольку результаты, которые должна выдавать база данных -- отчеты, формы и т.п. -- не всегда дают полное представление о структуре таблиц, по которым они создаются. Для проектирования таблиц вовсе не обязательно использовать Microsoft Access. Сначала лучше разработать структуру на бумаге. При разработке таблиц рекомендуется руководствоваться следующими основными принципами:1) Сведения не должны дублироваться в таблице или между таблицами. В этом отношении таблицы в реляционной базе данных отличаются от таблиц в приложениях, работающих с таблицами в текстовом формате, таких как редакторы электронных таблиц. Данные, хранящиеся только в одной таблице, обновляются только в этой таблице. Это более эффективно и, кроме того, исключает возможность дублирования записей, содержащих разные сведения. Например, адрес и номер телефона каждого клиента достаточно сохранить один раз, в одной таблице.2) Каждая таблица должна содержать информацию только на одну тему. Когда каждая таблица содержит сведения только по одной теме, со сведениями по каждой теме можно работать независимо от остальных тем. Например, адрес клиента хранится отдельно от заказов этого клиента, что позволяет удалить один запрос, сохранив сведения о клиенте. В данной базе данных содержится семь таблиц: жилищная организация, жилой дом, квартира, жильцы, информация о жильцах, услуга, информация о выполненной услуге.

Определение необходимых в таблице полей

Каждая таблица содержит сведения по конкретной теме, а каждое поле в таблице содержит конкретный факт по теме таблицы. Например, таблица «Жильцы» содержит поля фамилия, имя, отчество, а конкретный факт это конкретный человек, например, Иванов Иван Иванович.

При составлении полей для каждой таблице необходимо учитывать следующие основные принципы:

· Каждое поле должно быть связано с темой таблицы;

· Таблица должна содержать все необходимые сведения;

· Данные следует разбить на наименьшие логические единицы.

Определение полей с уникальными значениями в каждой записи

Для связывания в Microsoft Access сведений, хранящихся в разных таблицах - например, для связывания паспортистки со всеми ее клиентами - каждая таблица базы данных должна содержать поля или набор полей, однозначно определяющих каждую запись. Такое поле или набор полей называют первичным ключом. Например, таблица “Жилищная организация” связана с таблицей “Жилой дом” связью “один ко многим”, следовательно, таблица “Жилой дом” имеет вторичный ключ “Номер организации”, а первичный ключ “Номер дома”.

Определение связей между таблицами

После того, как разбили сведения на таблицы и определили ключевые поля необходимо выбрать способ, которым Microsoft Access будет вновь объединять связанные сведения. Для этого следует определить связи между таблицами базы данных Microsoft Access. Связи бываю: один ко многим, много ко многим (реже используется).

1.1. Виды таблиц;
1.2. Виды справочников;
1.3. Виды связок;
2. Обобщение классификации;
2.1. Классификация в табличном виде;
2.2. Классификация в схематичном виде;
3. Некоторые комментарии по применению классификации;
3.1. Применение классификации при нормализации таблиц;
Заключение.

Обоснование статьи и некоторые ключевые понятия

Очень часто присутствовал на обучении дисциплине «Базы данных». Обучался когда-то сам… Как-то даже пришлось проводить целый курс для друзей и знакомых. Во время обучения мною было замечено, что трудности возникают уже на этапе понимания таблиц и того, как ими пользоваться. Многие просто не могли и не могут разработать простейшие базы данных. После более детального рассмотрения такого понятия как таблицы и маленькой классификации, трудности восприятия таблиц в реляционных базах данных почти всегда исчезают. Итак!

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

Для понимания дадим краткие определения целостности и избыточности данных:

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

Избыточность данных – это состояние базы данных, при котором в таблицах присутствуют лишние данные.

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

1.1. Виды таблиц

Немного углубимся в маленькую классификацию таблиц по видам их структуры. Разделим таблицы на два общих вида. Первым видом будут таблицы-справочники, вторым таблицы-связки.

Рисунок 1. Справочники и связки

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

В справочниках содержатся сведения об объектах и субъектах, связях. В связках содержатся сведения о действиях, процессах, событиях и так далее.

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

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

Справочники могут подразделяться на несколько видов. Это статичные, статично-динамичные и динамичные справочники. Разумеется, вряд ли можно назвать абсолютно статичный справочник, так как в этом мире может измениться всё. Или почти всё.

Статичный справочник – справочник, данные об объектах, субъектах, связях в котором либо никогда не подвергаются модификации после первичной модификации, либо настолько редко подвергаются модификации, что этим можно пренебречь.

Примером таких справочников могут служить список месяцев с названиями и номерами, список дней недели, список времён года, список океанов и так далее…

Таблица 1. Пример статичных справочников

– справочник, в котором хранятся данные о связях, если связи носят справочный характер. В таком справочнике могут быть внешние ключи.

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

Таблица 2. Пример статично-динамичных справочников

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

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

Таблица 3. Пример динамичных справочников

Рисунок 2. Виды справочников

Таблицы-связки можно разделить на два вида.

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

Примером справочника-связки будет являться таблица платёжных транзакций. Или таблица с данными о футбольном матче.

Таблица 4. Пример справочника-связки

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

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

Таблица 5. Пример связки

Необходимо пояснить, что это за поля, которые образуют справочник, но не могут быть выделены в отдельную таблицу-справочник. Примером таких полей являются поля «комментарий», «жалоба», «описание», «предложение». Словом, если приводить популярный пример, то поле «сообщение» в таблице базы данных любой социальной сети…

Рисунок 3. Виды связок

2. Обобщение классификации

2.1. Классификация в табличном виде

Вид таблицы	Описание	Примеры	Плюсы (+)	Минусы(-)
Статичный справочник	Таблица. Данные из неё берутся для других таблиц. Из справочника в других таблицах можно использовать только первичный ключ. В статичном справочнике должна содержаться информация, которая либо вообще не изменяется, либо изменяется так редко, что этим можно принебречь. На статичный справочник ссылаются (внешний ключ), когда нужно получить названия, обозначения, нормы, количественные или качественные показатели. Иное.	Справочник (наименований и номеров) месяцев. Справочник складов и цехов предприятия. Справочник правил игры.	Иногда заменяет системные функции СУБД, позволяет более гибко работать с некоторыми данными. В случае, если меняется редко изменяемая информация, предостерегает от серьёзных последствий.	Использование таблицы с любой структурой может замедлять работу, в случае, если таблица заменяет системное хранилише. Приходится писать дополнительные функции и обработки для данной таблицы, которые не всегда правильно оптимизированны. В некоторых случаях невозможно оптимизировать.
Статично-динамичный справочник	Таблица. Данные из неё берутся для других таблиц. Из справочника в других таблицах нельзя использовать внешний ключ этого справочника, однако можно использовать первичный ключ.	Справочник окладов по должностям. Справочник (размеров обуви, веса, роста, размера головы) физиологических параметров. Справочник (менеджеров, компаний) содержащий компании и менеджеров, которые эти компании обслуживают и учитывают.		Справочник, выделенный из справочника-связки, никуда не девается и не имеет никакой реляционной связи, которая позволила бы ему превратиться в статичный или динамичный справочник. А значит, всегда избыточен.
Динамичный справочник	Таблица. Данные из неё берутся часто для других таблиц. Из справочника в других таблицах можно использовать только первичный ключ. В динамичном справочнике должна содержаться информация, которая часто изменяется.	Справочник клиентов. Справочник поставщиков. Справочник контрагентов. Справочник менеджеров компании. Справочник работников. Справочник студентов.	Позволяет хранить динамичные данные, при этом давая возможность однозначно ссылаться на них.	Чаще всего накопительного типа и не делим, что создаёт определённую избыточность.
Справочник-связка	Таблица. Данные из неё не могут содержаться в других таблицах, но на основе них могут быть созданы данные в других таблицах.	Платёжные транзакции. Продажи. Межзаводские перемещения. График перевозок.	Позволяет проводить гибкую нормализацию по схеме «Справочник-связка» = «Связка»+«Статично-динамичный справочник».	Справочник-связка после нормализации превращается в связку и сводит избыточность данных к минимуму, не затрагивая целостность, однако не делим и при архивировании в текущей таблице не подлежит оптимизации.
Связка	Таблица. Данные из неё не могут содержаться в других таблицах, но на основе них могут быть созданы данные в других таблицах. Таблица не может содержать кортежей, значения атрибутов в которых являются неделимыми и не уникальными.	Автоматический лог ошибок в программе. Лог запроса сервера. Результаты трассировок. Отчёты о выгрузке и загрузке компонентов. Автоматические отчёты системы безопасности.	Связка сводит избыточность данных к минимуму, не затрагивая целостность.	Накапливаясь, является неделимой таблицей. Сложно оптимизировать.

Таблица 6. Классификация

2.2. Классификация в схематичном виде

Рисунок 4. Схема классификации таблиц в реляционных базах данных по признакам целостности и избыточности данных

3. Некоторые комментарии по применению классификации

3.1. Применение классификации при нормализации таблиц

Процесс нормализации, если не учитывать некоторые этапы (Но учитывать результаты этих этапов!) - это обычное «дробление» таблиц на более мелкие таблицы с созданием реляционной связи между ними непосредственно или через промежуточные таблицы (связь «Многие ко многим»). Под реляционной связью может не всегда пониматься реляционное отношение!

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

Для примера. Пусть имеется база данных, в которой единственная операция по модификации данных - это добавление. В таком случае становится неэффективным каждый раз при изменении какого либо отдельного атрибута сущности, «копировать» остальные значения атрибутов уже в другой кортеж. В этом случае используются NULL или же создание статично-динамичного справочника, где описывается ряд атрибутов одной семантики или один атрибут, а дублируется лишь внешний ключ с первичным ключом последовательности. Этот же метод может использоваться в традиционной схеме модификации данных с обновлением и удалением данных.

Заключение

Данная классификация была создана мной на основе наблюдений при проектировании баз данных, а также исходя из прочитанной теории по проектированию в реляционных СУБД. Моим друзьям и знакомым, изучающим дисциплину «базы данных» и занимающимся проектированием баз данных, и мне эта классификация достаточно серьёзно упростила «жизнь» и позволила во многих ситуациях заранее выбрать наиболее подходящий и, как оказывалось потом, правильный вид таблицы для хранения в ней тех или иных данных.

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

Надеюсь, кому ни будь ещё поможет эта классификация при освоении дисциплины «Базы данных» и при проектировании баз данных в реляционных СУБД.