Проанализировав таблицу «Организации», можно сказать, что она находится в первой нормальной форме, так как в любом допустимом значении отношения каждая ее запись содержит только одно значение для каждого из атрибутов. Так же эта таблица находится во второй нормальной форме, так как каждое поле функционально зависит от первичного ключа, который идентифицирует исходный объект таблицы. Так как таблица не содержит транзитивных зависимостей, т. е. столбцы, не являющиеся ключевыми, зависят от первичного ключа таблицы и не зависят от всех остальных столбцов, то она находится и в третьей нормальной форме.
Рассмотрим описание атрибутов и типы полей.
Описание атрибутов и типов полей для таблиц представлено ниже на рисунках 2−4.
Для каждого поля таблицы указывается размер поля (количество символов), тип. Для первичных ключей необходимо ввести запрет неопределенных значений. Для остальных полей возможность запрета неопределенных значений определяется семантикой предметной области.
Рисунок 2 — Состав таблицы «Организации».
Рисунок 3 — Состав таблицы «Деятельность».
Рисунок 4 — Состав таблицы «Налог».
Рассмотрим ситуацию, когда необходимо получить данные из разных таблиц. В таком случае необходимо воспользоваться представлениями. Представление — динамически сформированный результат одной или нескольких реляционных операций, выполненных над отношениями БД с целью получения нового отношения.
При создании базы данных «Налоговая инспекция» было создано представление, с помощью которого, в дальнейшем, можно получать специфическую информацию.
Представление — необходимо для получения информации об организациях, их данных, видах деятельности, налогах.
Описание атрибутов и типов полей для представления изображено на рисунке 5.
Рисунок 5 — Состав представления «Информация об организациях».
Логическая модель данных описывает факты и объекты, подлежащие регистрации в будущей базе данных. Основными компонентами такой модели являются сущности, их атрибуты и связи между ними. Как правило, физическим аналогом сущности в будущей базе данных является таблица, а физическим аналогом атрибута — поле этой таблицы. С логической точки зрения сущность представляет собой совокупность однотипных объектов или фактов, называемых экземплярами этой сущности. Физическим аналогом экземпляра обычно является запись в таблице базы данных. Как и записи в таблице реляционной СУБД, экземпляры сущности должны быть уникальными, то есть полный набор значений их атрибутов не должен дублироваться. И так же, как и поля в таблице, атрибуты могут быть ключевыми и неключевыми. На этапе логического проектирования для каждого атрибута обычно определяется примерный тип данных (строковый, числовой, и др.). Конкретизация происходит на этапе физического проектирования, так как различные СУБД поддерживают разные типы данных и ограничения на их длину или точность.
