13. Создание инфологической и даталогической модели данных

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

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

Чаще всего концептуальная модель базы данных включает в себя:

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

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

Логическое (даталогическое) проектирование — создание схемы базы данных на основе конкретной модели данных, например, реляционной модели данных. Для реляционной модели данных даталогическая модель — набор схем отношений, обычно с указанием первичных ключей, а также «связей» между отношениями, представляющих собой внешние ключи.

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

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

В настоящее время условным общепринятым языком описания базы данных стал язык ER-модели. Для ER-модели существует алгоритм однозначного преобразования ее в реляционную модель данных, что позволило в дальнейшем разработать множество инструментальных компьютерных систем, поддерживающих процесс разработки информационных баз данных, основанных на технологии баз данных. И во всех этих системах существуют средства описания инфологической модели разрабатываемой БД с возможностью автоматической генерации той даталогической модели (СУБД-ориентированной), на которой будет реализовываться проект в дальнейшем. Такие автоматизированные инструментальные системы, основанные на методологии DEF1X, называются CASE-средствами проектирования информационных систем. А сама технология разработки – CASE-технологию создания и сопровождения информационных систем [10].

Первоначальное значение термина CASE (Computer Aided System Engineering), ограниченное вопросами автоматизации разработки только лишь программного обеспечения, в настоящее время приобрело новый смысл, охватывающий процесс разработки информационных систем в целом. Под ним понимаются программные средства, поддерживающие процессы создания и сопровождения информационных систем, которые в общем случае включают следующие этапы:

• анализ и формулировку требований предметной области;

• проектирование баз данных и прикладного программного обеспечения;

• генерацию кода для выбранной СУБД и языка приложений;

• тестирование;

• документирование;

• обеспечение требуемого качества работы информационной системы.

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

Рассмотрим некоторые аспекты информационного моделирования и его автоматизации с использованием программного CASE-средства ERWin v7.1.

ERWin – это прежде всего средство концептуального моделирования базы данных, которое сочетает графический интерфейс Windows, инструменты для построения ER-диаграмм, редакторы для создания логической и физической модели данных, а также поддержку различных сетевых реляционных СУБД и настольных баз данных. Существенным преимуществом является то, что с помощью ERWin можно создавать или проводить обратное проектирование (реинжиниринг) баз данных, т.е. преобразовать физическую модель базы данных в концептуальную модель, не привязанную к конкретной СУБД.

ERWin создает визуальное представление (модель данных) для решаемой задачи в виде ER-диаграмм. Это представление может использоваться для детального анализа, уточнения и распространения в качестве части документации, необходимой в цикле разработки. В ERWin существуют два уровня представления и моделирования – логический и физический. Логический уровень означает прямое отображение фактов сущностей из реальной жизни. Например, печи, персонал, оборудование являются реальными объектами. Они именуются на естественном языке, с любыми разделителями слов (пробелы, запятые и т.д.). На логическом уровне не рассматривается использование конкретной СУБД, не определяются типы данных (например, целое или вещественное число) и не определяются индексы для таблиц. Целевая СУБД, имена объектов и типы данных, индексы составляют второй, физический уровень модели ERWin. ERWin предоставляет возможности создавать и управлять этими двумя различными уровнями представления диаграмм. Выбор между логическим и физическим уровнем отображения осуществляется через линейку инструментов или меню. Кроме этого, уровень детализации диаграммы информационной модели может изменяться проектировщиком. Например, могут отображаться только имена сущностей (таблиц), может быть включено/выключено отображение мощности связи и т.д.

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

Все графические элементы модели ERWin могут редактироваться средствами, принятыми в Windows – группировка, копирование, удаление, перемещение, использование системного буфера обмена. С помощью удобных диалоговых окон имеется возможность использовать цветовое и шрифтовое выделение для различных компонентов диаграммы. Выделение может быть выполнено как для всей модели (например, все внешние ключи отображать красным цветом), так и для отдельного компонента (таблицы, атрибутов одной таблицы, одной связи и т.д.). Компоненты модели, представленные текстом (имена сущностей, атрибутов, текстовые комментарии) могут редактироваться непосредственно на экране. Использование цветового и шрифтового выделения на диаграмме информационной модели делает ее более наглядной и позволяет проектировщику обратить внимание пользователей диаграммы на ее отдельные элементы.

Процесс построения информационной модели в ERWin состоит из следующих этапов:

1. определение сущностей;

2. определение связей (зависимостей) между сущностями;

3. задание первичных и составных (альтернативных) ключей;

4. определение атрибутов сущностей;

5. приведение модели к требуемому уровню нормальной формы;

6. переход к физическому описанию модели: назначение соответствий имя сущности – имя таблицы, атрибут сущности – атрибут таблицы; задание ограничений предметной области;

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

Сущность на диаграмме изображается прямоугольником. В зависимости от режима представления диаграммы прямоугольник может содержать имя сущности, ее описание, список ее атрибутов и другие сведения. Горизонтальная линия прямоугольника разделяет атрибуты сущности на два набора – атрибуты, составляющие первичный ключ в верхней части и прочие (не входящие в первичных ключ) в нижней части. Сущность – это логическое понятие. Сущности соответствует таблица в реальной СУБД. В ERWin сущность визуально представляет три основных вида информации:

• атрибуты, составляющие первичный ключ;

• неключевые атрибуты;

• тип сущности (независимая/зависимая).

Каждый атрибут сущности становится атрибутом соответствующего отношения. Для каждого атрибута задается конкретный допустимый с СУБД тип данных и обязательность или необязательность данного атрибута, т.е. допустимость или недопустимость NULL-значений для него. Первичный ключ сущности становится Primary Key соответствующего отношения. Атрибуты, входящие в первичный ключ отношения, автоматически получают свойство обязательности (NOT NULL).

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

• тип связи (идентифицирующая или неидентифицирующая связь);

• родительская сущность;

• дочерняя (зависимая) сущность;

• мощность связи;

• допустимость пустых (null) значений.

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

Для определения связей ERWin выбирается тип связи, затем мышью указывается родительская и дочерняя сущность. Идентифицирующая связь изображается сплошной линией; неидентифицирующая – пунктирной линией. Линии заканчиваются точкой со стороны дочерней сущности. При определении связи происходит автоматическое перемещение (миграция) атрибутов первичного ключа родительской сущности в соответствующую область атрибутов дочерней сущности. Поэтому такие атрибуты не вводятся вручную. Атрибуты первичного ключа родительской сущности по умолчанию мигрируют со своими именами. ERWin позволяет ввести для них роли, т.е. новые имена, под которыми мигрирующие атрибуты будут представлены в дочерней сущности. На физическом уровне имя роли – это имя колонки внешнего ключа в дочерней таблице.

Мощность связи в соответствии с методологией IDEF1X представляет собой отношение количества экземпляров родительской сущности к соответствующему количеству экземпляров дочерней сущности. Мощность связи записывается как 1:N. ERWin предоставляет 4 варианта для n, которые изображаются дополнительным символом у дочерней сущности: ноль, один или больше (по умолчанию); ноль или один; один или более; ровно N, где N – конкретное число. Допустимость пустых (null) значений в неидентифицирующих связей ERWin изображает пустым ромбиком на дуге связи со стороны родительской сущности.

Для каждой связи на логическом уровне могут быть заданы требования по обработке операций вставки, обновления и удаления (insert, update, delete) для родительской и дочерней сущности. Программа ERWin предоставляет следующие варианты обработки этих событий:

• отсутствие проверки;

• проверка допустимости;

• запрет операции;

• каскадное выполнение операции удаления/обновления (delete/update);

• установка пустого (null-значения) или заданного значения по умолчанию.

В соответствии с выбранным вариантом программа ERWin автоматически создает необходимые процедуры обработки этих событий (триггеры) на языке SQL целевой СУБД, которые могут быть переопределены после генерации схемы базы данных.

Разработанные модели ERWin сохраняются на диск в виде файла с расширением *.er1. Имеется возможность хранить модель в целевой СУБД. Для этого с помощью самой программы ERWin в целевой СУБД создается метабаза ERWin, в которой сохраняется информация о модели

Инфологическая модель предметной области, в данном случае характеризуется следующими особенностями:

• справочные данные попадают в базу данных по средствам ввода пользователем или автоматическим путем посредствам пакета Integration Services;

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

Список сущностей, их назначение первичные и внешние ключи описаны в таблице 3.1.

Отношения между сущностями данной предметной области представляются в виде отношений: один-к-одному или один-ко-многим. Так же отношения между сущностями являются интуитивно понятными и не противоречат данной предметной области. Базовыми сущностями являются справочник типов материалов (tMatType), и справочник свойств стенки (tProperties) а так же Справочник предприятий и справочник типов печей.Эти сущности не содержат внешних ключей.

Таблица 3.1 - Список сущностей, их назначение первичные и внешние ключи

Сущность	Назначение	Первичный ключ	Внешние ключи
tMaterial	Является справочником огнеупорных материалов.	idMaterial	idType
tMatType	Является справочником типов огнеупорных материалов.	idType	-
tPredpriytie	Является справочником предприятий для которых выполняются расчеты.	idNomer	-
tPech	Является справочником печей на предприятии.	idPech	idPred,idTipPech
tProperties	Свойства стенки печи	id	-
tData_pred	Обьединяет данные конкретного расчета к данным печи	idData_pred	idRasch, idPech
tRasch	Хранит исходные данные и расчетные данные	idRasch	idPredpriytie
tMaterial_to_rasch	Обьединяет расчет и набор материалов для слоев стенки	-	idStenka, idRasch
tTermogramma	Хранит данные с термограммами для конкретной печи	id	idPech, idData_pred
tPredTipPech	Является справочником типов печей	idTipPech	-
tStenka	Хранит данные материалов слоев стенки	idStenka	-

С ними в отношениях один-ко-многим состоит сущность Справочника огнеупорных материалов которая связана внешним ключом с типом огнеупорных материалов. Инфологическая модель (ER-диаграмма) текущей системы полностью представлена на рисунке 3.3.

Рисунок 3.3 – Инфологическая модель (ER-диаграмма)

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

Решение данной задачи проходило в среде Microsoft Access 2007.

Microsoft Office Access или просто Microsoft Access — реляционная СУБД [11] корпорации Microsoft. Имеет широкий спектр функций, включая связанные запросы, связь с внешними таблицами и базами данных. Благодаря встроенному языку VBA, в самом Access можно писать приложения, работающие с базами данных. MS Access является файл-серверной СУБД и потому применима лишь к маленьким приложениям. Отсутствует ряд механизмов, необходимых в многопользовательских БД, таких, например, как триггеры. Существенно расширяет возможности MS Access по написанию приложений механизм связи с различными внешними СУБД: «связанные таблицы» (связь с таблицей СУБД) и «запросы к серверу» (запрос на диалекте SQL, который "понимает" СУБД). При этом имеется возможность совместить с присущей MS Access простотой инструменты для управления БД и средства разработки.

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

На рисунке 3.4 изображена сущность tMaterial, которая является справочником Огнеупорных материалов.

Рисунок 3.4 – Сущность tMaterial

Первичный ключ является типом данных счетчик, который ипользуется для формирования уникальных значений, которые могут применяться в качестве первичного ключа. Эти значения автоматически вставляются в поле при добавлении записи. Поля с типом данных "Счетчик" могут формироваться добавлением единицы, добавлением заданного значения или с помощью случайных чисел. 4 байта (16 байтов, когда поле используется как код репликации). mType – внешний ключ имеет тип данных числовой (длинное целое). Коэффициенты полинома mA, mB, mC имеют тип одинарное с плавающей точкой.

На рисунке 3.5 представлена структура таблицы tMatType, которая хранит в себе типы огнеупорных материалов.

Рисунок 3.5 – Сущность tMatType

В данной таблице первичный ключ idType имеет тип счетчик(Длинное целое). А поле fNAME Тип текстовый.

На рисунке 3.6 представлена структура таблицы tDate_pred, которая хранит в себе исходные значения для расчетов.

Рисунок 3.6 – Сущность tDate_pred

IdtDate_Pred имеет тип счетчик. idRasch, IdPesh – имеют тип Целое(2-байтовое целое число, содержащее значение от -32 768 до +32 767), чего вполне хватит для хранения идентификаторов. Поле Prim Имеет тип текстовый(Может храниться до 255 знаков).

На рисунке 3.7 представлена структура таблицы tPredpriaytie, которая хранит в себе справочник предприятий.

Рисунок 3.7 – Сущность tPredpriaytie

Id имеет тип счетчик. pTel – имеет тип Целое. Поля pName, pAddress, pWork Имеет тип текстовый(Может храниться до 255 знаков).

На рисунке 3.8 представлена структура таблицы tPech, которая хранит в себе Данные по конкретной печи предприятия.

Рисунок 3.8 – Сущность tPech

IdPech имеет тип счетчик. idPred, Tip – имеют тип Целое. Поле Name имеет тип текстовый.

На рисунке 3.9 представлена структура таблицы tPredTipPechi, которая хранит в себе справочник типов печей.

Рисунок 3.9 – Сущность tPredTipPech

IdTipPech имеет тип счетчик. TipPech имеет тип текстовый.

На рисунке 3.10 представлена структура таблицы tProperties, которая хранит в себе свойства стенки печи.

Рисунок 3.10 – Сущность tProperties

IdProperties имеет тип счетчик. MaxValue, MinValue – имеет тип Целое. Поле Name имеет тип текстовый.

На рисунке 3.11 представлена структура таблицы tRasch, которая хранит в себе данные расчета.

Рисунок 3.11 – Сущность tRasch

IdRasch имеет тип счетчик. idProperties – имеет тип Целое. Поле value имеет тип одинарное с плавающей точкой(4-байтовое целое число, содержащее значение от -3,4 x 1038 до +3,4 x 1038 и до 7 значащих цифр).

На рисунке 3.12 представлена структура таблицы tStenka, которая хранит в себе материалы слоев стенки печи.

Рисунок 3.12 – Сущность tStenka

IdStenka имеет тип счетчик. Material_1, Material_2, Material_3 – имеет тип Целое.

На рисунке 3.13 представлена структура таблицы tTermogramma, которая хранит в себе данные по термограммам печи.

Рисунок 3.13 – Сущность tTermogramma

Id имеет тип счетчик. idPech, id_Datapred – имеет тип Целое. Поле link имеет тип текстовый.

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

Рисунок 3.14 – Сущность tMaterial_to_rash

idStenka, idRasch – имеет тип Целое.