Инфологические модели

Процесс разработки информационно-логической модели предметной области (далее – ИЛМ) является творческим и трудно поддается

формализации. Для построения ИЛМ необходимо знание предметной

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

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

для решения которых строится база, и потребности задач в данных.

Строго в соответствии с потребностями выявляются информационные

объекты, из которых должна состоять БД. При втором подходе изучается предметная область, производится анализ её данных и устанавливаются типовые объекты предметной области. Возможно сочетание обоих подходов. При разработке ИЛМ в соответствии с первым подходом сначала осуществляется выявление форм документов – источников, содержащих необходимых данные. Данные в документах представлены в виде реквизитов. Далее могут быть установлены функциональные зависимости реквизитов, которые используются для выделения нормализованных информационных объектов. Последующее определение структурных связей между объектами позволяет закончить построение информационно-логической модели (ИЛМ).

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

При проектировании БД применяются понятия “Сущность” и

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

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

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

логической моделью БД предметной области (ИЛМ ПО). Выделение информационных объектов ПрО, отвечающих требованиям нормализации, может производиться на основе различных под-

ходов, требующих разных трудозатрат и имеющих различную степень

формализации действий.

Интуитивный подход к выделению информационных объектов

предполагает непосредственное выявление реальных объектов, а также

других сущностей предметной области и определение их реквизитов.

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

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

связей объектов типа “М: M” к связям типа “1: М”. При таком подходе,

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

Ниже рассматриваются формальные правила, позволяющие на основе несложного анализа функциональных взаимосвязей реквизитов

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

третьей нормальной формы (3НФ) и соответственно строить ИЛМ.

В результате анализа предметной области должен быть выявлен

состав форм документов и их реквизитов, подлежащих хранению в базе

данных. Для выделения ИнО надо произвести семантический анализ и

выявить функциональные зависимости реквизитов.

В результате анализа предметной области должен быть выявлен

состав форм документов и их реквизитов, подлежащих хранению в базе

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

что форма документа уже отображает структуру данных, так как любой

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

Ключом в документе является подмножество, состоящее из одного

или нескольких реквизитов документа, предназначенное для идентификации отдельного документа в целом или группы реквизитов в нём.

Ключ документа позволяет выделить документ из множества других

подобных документов, а ключ строки документа – строку из множества

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

визит, входящий в состав ключа. Ключ, состоящий из одного реквизита,

называется простым, а из нескольких реквизитов – составным. В ряде

случаев ключом может нескольких подмножеств ключевых реквизитов

документа. Такие подмножества называются возможными,

потенциальнымиили альтернативнымиключами. Ключ, выбранный из

множества альтернативных в качестве ключа ИнО, называется

выделенным ключом.

Совокупность всех ИнО одного типа в заданной ПрО образует

множество ИнО, элементы которого называются экземплярами ИнО.

При выбор ключа из альтернативных следует руководствоваться:

- ограничениями предметной области,

- минимизацией объёма внешней памяти, занимаемой базой

данных,

- использованием ключа в СУБД при решении задач

пользователей.

Совокупность всех значений ключа ИнО образует множество, в

котором не должно быть повторяющихся значений. В качестве ключа

ИнО, образованного из справочного документа, может быть использовано наименование или код номенклатуры1. Наименования всегда используются в документах, и их следует применять в экранных формах

документов и отчётах приложений СУБД.

Использование наименования в качестве ключа ИнО имеет следующие недостатки:

- наименования могут иметь повторяющиеся значения, напри-

мер, ФИО студента или работающего;

- они имеют большой размер (занимают много места во внешней

памяти);

- не позволяют производить отбор данных из базы данных в соответствии с заданными значениями классификационных при-

знаков.

Использование кодов номенклатуры в качестве ключа лишено перечисленных выше недостатков ключей-наименований:

- коды не имеют повторяющихся значений;

- они существенно короче наименований;

- коды позволяют производить отбор данных из базы данных в

соответствии с заданными значениями классификационных

признаков, в том числе в соответствии со значением части ко-

да.

Из сказанного выше следует, что в качестве ключа следует использовать коды номенклатуры, а не их наименования. Если код номенклатуры отсутствует в документе, то его следует ввести в ИнО, соответствующий этому документу, для использования кода в качестве

ключа.

Один и тот же реквизит в разных ИнО объектах может быть ключевым и не ключевым (описательным). Замена наименования номенклатуры её кодом целесообразна и в том случае, если этот реквизит не

ключевой, т.к. в этом случае он будет занимать меньше места на машинном носителе.

Счёт-фактура

Поставщик

Поставщик	Адрес	Телефон	ИНН
ПСТ	АДРПСТ	ТЕЛПСТ	ИННПСТ

Таблица 3.1 - Поставщик

Счет-фактура

№ Счет-фактуры	Дата выписки счет-фактуры	НДС	Наименование товара	Единица измерения	Количество	Цена
№ СФ	ДАТА	НДС	НАИМТ	ЕИ	КОЛ	ЦЕНА

Таблица 3.2 – Счет-фактура

База данных ведется у покупателя

Функциональные зависимости:

ИННПСТ -> {ПСТ, АДРПСТ, ТЕЛПСТ}

{№ СФ, ИННПСТ} -> {ДАТА, НДС}

КОДТ -> {НАИМТ, ЕИ}

{№ СФ, ИННПСТ, КОДТ} -> {КОЛ, ЦЕНА}

Графическое изображение

Документ	Наименование реквизита	Обозначение реквизита	Функциональная зависимость
Счет-фактура	№ Счет-фактуры Дата выписки счет-фактуры НДС ИНН поставщика Поставщик Адрес поставщика Телефон поставщика Код товара Наименование товара Единица измерения Количество Цена	№ СФ ДАТА   НДС ИННПСТ ПСТ АДРПСТ ТЕЛПСТ КОДТ НАИМТ ЕИ КОЛ ЦЕНА

Таблица 3.3 – Графическое изображение Счет-фактуры

Функциональная зависимость

	Название ИнО	Имя ИнО	Семантика ИнО
ИННПСТ -> {ПСТ, АДРПСТ, ТЕЛПСТ}	Поставщик	ПСТ	Общие сведения о поставщике
{№ СФ, ИННПСТ} -> {ДАТА, НДС}	Счет-фактура	СФ	Сведения о покупке товара по счет-фактуре
КОДТ -> {НАИМТ, ЕИ}	Товар	ТОВАР	Справочные сведения о товаре
{№ СФ, ИННПСТ, КОДТ} -> {КОЛ, ЦЕНА}	Покупка	ПОК	Общие сведения о документе

Таблица 3.4 – Функциональная зависимость

Связываемые ИнО

Связываемые ИнО	Общие реквизиты
Счет-фактура - Поставщик	ИННПСТ
Товар – Покупка	КОДТ
Счет-фактура - Покупка	№ СФ

Таблица 3.5 - Связываемые ИнО

Счет-фактура

Поставщик

Товар

Покупка

Счет-фактура

Покупка

Связи: М:1, М:1, 1:М соответственно

Товар		Поставщик		Покупка		Сет-фактура
КОДТ НАИМТ ЕИ	ИННПСТ ПСТ АДРПСТ ТЕЛПСТ	№ СФ ИННПСТ КОДТ КОЛ ЦЕНА	№ СФ ИННПСТ ДАТА НДС

Поставщик

Счет-фактура

Товар

Покупка

Дата добавления: 2015-10-24