для информационной модели доменного производства
| Наименование | Описание |
| Шихтовые материалы | Наименования используемых шихтовых материалов |
| Доли шихтовых материалов | Соотношение весовых долей шихтовых материалов, загружаемых в печь |
| Коксовая батарея | Характеристики коксовых батарей |
| Химанализ кокса | Химический анализ кокса, поступающего в доменный цех |
| Кокс на печь | Соответствие между коксовой батареей и доменной печью |
| Т_параметры | Перечень технологических параметров, контролируемых в ходе работы печи, с указанием их идентификаторов для однозначного определения их в базе данных |
| Выпуск | Информация о выпуске жидких продуктов плавки из доменной печи (дата выпуска, время начала и окончания выпуска, температура чугуна на выпуске) |
| НСИ элементов | Нормативно-справочная информация по физико-химическим соединениям, образующимся в жидких продуктах плавки |
Таблица 2.2
Данные по доменному переделу, приведенные
к третьей нормальной форме
| Имя сущности (таблицы) | Имя атрибута сущности (поля таблицы) | Тип данных | Описание |
| Доменная печь | № печи | Числовой | Ключевое поле |
| Наименование печи | Текстовый | ||
| Полная высота_м | Числовой | ||
| Полезная высота_м | Числовой | ||
| Высота зумпфа_м | Числовой | ||
| Высота горна_м | Числовой | ||
| Высота заплечиков_м | Числовой | ||
| Высота распара_м | Числовой | ||
| Высота шахты_м | Числовой | ||
| Высота колошника_м | Числовой | ||
| Диаметр горна_м | Числовой | ||
| Диаметр распара_м | Числовой | ||
| Диаметр колошника_м | Числовой | ||
| Угол наклона шахты_град | Числовой | ||
| Угол наклона заплечиков_град | Числовой | ||
| Полезный объем печи_м2 | Числовой | ||
| Число воздушных фурм_шт | Числовой | ||
| Диаметр фурм_м | Числовой | ||
| Число чугунных леток_шт | Числовой | ||
| Число работающих фурм_шт | Числовой | ||
| Шихтоподача | № печи | Числовой | Составной ключ |
| Дата шихтовки | Дата/время | ||
| № подачи | Числовой | ||
| Вес подачи_кг | Числовой | ||
| Порядок загрузки | Текстовый | ||
| Доли шихтовых материалов | № печи | Числовой | Составной ключ |
| № подачи | Числовой | ||
| Код материала | Числовой | ||
| Дата шихтовки | Дата/время | ||
| Доля материала_% | Числовой | ||
| Т_Параметры | Код параметра | Числовой | Ключевое поле |
| Наименование параметра | Текстовый | ||
| Шихтовые материалы | Код материала | Числовой | Ключевое поле |
| Наименование материала | Текстовый | ||
| Окончание таблицы 2.2 | |||
| Химанализы шихтовых материалов | Код материала | Числовой | Составной ключ |
| Технологические параметры | Код элемента | Числовой | |
| Значение | Числовой | ||
| Дата | Дата/время | ||
| № печи | Числовой | Составной ключ | |
| НСИ элементов | Код параметра | Числовой | |
| Дата | Дата/время | ||
| Значение | Числовой | ||
| Код элемента | Числовой | Ключевое поле | |
| Кокс на печь | Наименование элемента | Текстовый | |
| № печи | Числовой | Составной ключ | |
| Коксовая батарея | № коксовой батареи | Числовой | Ключевое поле |
| № коксовой батареи | Числовой | ||
| Химанализ кокса | Наименование коксовой батареи | Текстовый | |
| № коксовой батареи | Числовой | Составной ключ | |
| Выпуск | Дата | Дата/время | |
| Код элемента | Числовой | ||
| Значение | Числовой | ||
| № печи | Числовой | Составной ключ | |
| Химанализ чугуна и шлака | № выпуска | Числовой | |
| Характер расплава | Текстовый | ||
| Дата выпуска | Дата/время | ||
| Время начала выпуска | Дата/время | ||
| Время окончания выпуска | Дата/время | ||
| Температура чугуна | Числовой | ||
| № печи | Числовой | Составной ключ | |
| № выпуска | Числовой | ||
| Характер расплава | Текстовый | ||
| Код элемента | Числовой | ||
| Значение | Числовой | ||
Перейдем к реализации модели данных доменного производства в программе ERwin.
Сначала создадим логический уровень модели. Для этого зададим режим отображения сущностей Edit/Logical Model. Создадим при помощи линейки инструментов (ERwin Toolbox) сущности "Доменная печь", "Шихтоподача", "Химанализы шихтовых материалов" и т.д. Сущности будем именовать на русском языке. Выбрав каждую сущность, зададим для нее подробное описание (Definition) на русском языке в редакторе "Entity Editor" (рис. 2.21). Это описание появится в отчетах ERwin и может быть отображено на диаграмме.
 |
Далее укажем связи между сущностями. Например, сущность "Доменная печь" связана идентифицирующей связью, т.е. является родительской сущностью для сущностей "Шихтоподача", Выпуск", "Кокс на печь" и "Технологические параметры". Описание связи вводится в редакторе "Relationship Editor" (рис. 2.22). На вкладке General отображаются названия сущности-родителя и сущности-потомка, имеется возможность задать мощность (Cardinality) связи, а также ее тип (идентифицирующая, неидентифицирующая). На других вкладках можно ввести подробное описание связи (вкладка Definition), определить правила для контроля целостности отношений между сущностями (вкладка Rolename/RI Actions), а также определить так называемые правила (проверки допустимых значений) и начальные (по умолчанию) значения для любых логических или физических объектов ERwin (вкладка UDP).
Теперь перейдем в режим задания атрибутов Edit/Attribute. В диалоговом окне "Attribute Editor" (рис. 2.22) зададим на русском языке имена ключевых и неключевых атрибутов. Заметим, что некоторые ключевые атрибуты для дочерних сущностей не указываются вручную, они автоматически переходят
 |
(мигрируют) из родительской сущности. Например, при вводе атрибутов для сущности "Технологические параметры" в качестве ключевого здесь уже присутствует атрибут "№ печи", который перешел из родительской сущности "Доменная печь". Дополнительно здесь же зададим два ключевых атрибута "Код параметра" и "Дата", а также неключевой атрибут "Значение". Таким образом мы создали составной ключ из трех атрибутов "№ печи", "Код параметра" и "Дата", чтобы однозначно идентифицировать каждый технологический параметр любой доменной печи цеха в определенный момент времени. Аналогично введем другие атрибуты всех сущностей для разработанной схемы базы данных.
Отображение на логическом уровне информационных объектов доменного производства, их атрибутов, а также отношений между ними в виде ER-диаграммы приведено на рис. 2.24.
2.11.2. Физическая реализация информационной модели
Перейдем к физической реализации базы данных доменного производства. Для этого выберем целевую систему управления базой данных в диалоговом окне "Server/Target Server", например Microsoft (MS) Access 97 (рис. 2.25). Как видно из рисунка, ERwin поддерживает как самые современные, так и предыдущие версии основных программ СУБД – INFORMIX, ORACLE, SQL Server, SQL Base, SYBASE, FoxPro, Clipper, dBASE, Paradox и др.
После выбора целевой СУБД проектирование на физическом уровне выполняется в терминах той базы данных, которую предполагается использовать в информационной системе. Важно подчеркнуть, что программе ERwin "известны" соответствия между возможностями СУБД различных производителей, вследствие чего возможно преобразование физической схемы, спроектированной для одной СУБД, в другую. Такой процесс преобразования называется обратным проектированием (reverse engineering) и используется при выборе оптимальной аппаратной платформы для существующей базы данных, а также при расширении или модификации существующей логической структуры информационной системы.
Выберем команду меню "Tasks/Forwards Engineer/Schema Generation…". Появляется окно "Access Schema Generation" (рис. 2.26), в котором показан диалог выбора параметров генерации базы данных. В ходе процесса генерации программа ERwin строит пакет SQL-команд для создания структуры базы данных. На рисунке видно, что пользователь может определить фильтр (Filter), т.е. генерировать не все таблицы, пакет SQL-команд можно просмотреть(Preview), распечатать (Print), сохранить в файл отчета (Report), выполнить генерацию (Generate).
 |
После выбора процедуры генерации следует заполнить пустые поля появившегося окна подключения к СУБД MS Access (рис. 2.27), в котором содержится следующая информация:
 |
· имя пользователя (User Name), от имени которого производится подключение к системе управления базой данных MS Access. В нашем случае полагаем, что подключение осуществляется от имени администратора базы данных, имя которого admin;
· пароль (Password) пользователя;
· местоположение и имя файла базы данных (Database), в которую будет сгенерирована разработанная логическая схема. Заметим, что файл базы данных с указанным именем должен быть предварительно создан в программе MS Access 97. В нашем случае был создан пустой файл с именем Dom.mdb в корневом каталоге диска "C";
· местоположение и имя системной базы данных (System Database) пакета MS Access.
После заполнения указанных полей окна подключения следует нажать кнопку Connect и ждать выполнения всех SQL-команд по созданию структуры базы данных, которое отражается в окне "Generate Database Schema". Об успешном окончании процесса генерации структуры базы данных свидетельствует запись Schema Generation Complete, 494 query succeeded.
Результат выполнения можно просмотреть, загрузив в программу MS Access файл "Dom.mdb". На рис. 2.28 показана схема базы данных доменного производства, которая состоит из нескольких таблиц, связанных между собой по ключевым полям.
В процессе разработки и совершенствования информационной системы может возникнуть ситуация, когда физическая структура базы данных, например в MS Access, и информационная модель в ERwin не соответствуют друг другу. Для этого в программе ERwin предусмотрена функция синхронизации с базой данных, которая вызывается командой меню "Tasks/Complete Compare…". Появившееся диалоговое окно (рис. 2.29) предлагает список несоответствий между существующей структурой базы данных MS Access и моделью ERwin.
 |
Например, если в базе данных создана новая таблица, то ERwin предложит провести включение ее в модель. Если в модель добавлена новая сущность, ERwin предложит создать на ее основе таблицу в реальной базе данных. Аналогично: при добавлении или модификации полей в базе данных или атрибутов сущностей в информационной модели ERwin предлагает провести соответствующие операции по синхронизации.
 |
При завершении работы над информационной моделью, как правило, необходимо распечатать логический и физический уровни диаграммы, а также отчеты по соответствиям "сущность–таблица", "атрибут–имя колонки". Диаграмма физической модели является необходимым и очень удобным материалом для разработчиков прикладных программ, использующих обращения к базе данных. Для этого с помощью команды меню "Tasks/Generate Reports…" можно вызвать диалоговое окно "Report Browser", в котором представлены всевозможные виды отчетов по разработанной информационной модели. Рисунок 2.40 иллюстрирует пример построения отчета о соответствии названий сущностей и их атрибутов именам колонок реальной базы данных.
Сгенерированный отчет может быть выведен на печать или сохранен на диске в удобном формате, предусматривающем его последующую корректировку в текстовом редакторе или электронных таблицах.
2.12. Контрольные вопросы
1. Чем характеризуется традиционный подход к организации данных? В чем проявляется его ограниченность?
2. Какие компоненты включает в себя система баз данных?
3. В чем заключаются преимущества и недостатки использования системы баз данных для построения информационных систем?
4. Какие варианты архитектур используются для построения многопользовательских централизованных систем баз данных с удаленным сетевым доступом?
5. Поясните принципы работы централизованной и распределенной систем баз данных. Какая из этих систем является более перспективной и почему?
6. Дайте характеристику клиент/серверной технологии построения программного обеспечения. С какой целью производится деление компьютерного приложения на отдельные уровни?
7. На каких принципах основан реляционный подход к организации данных? Перечислите основные понятия реляционных баз данных.
8. Из каких этапов состоит процесс разработки баз данных при классической методологии проектирования? Какие свойства при этом необходимо обеспечить?
9. В чем состоит основная идея метода нормализации схемы базы данных? Поясните условия, которые необходимо обеспечить для приведения схемы отношения базы данных к первой, второй и третьей нормальным формам.
10. Чем вызвана необходимость семантического моделирования данных? Дайте определения понятиям «сущность», «связь», «атрибут».
11. Что понимается под CASE-технологией разработки информационных систем?
[1] Сопровождение (ведение, поддержка) данных – термин, объединяющий действия по добавлению, удалению или изменению хранимых в компьютере данных.
[2] Операнд – часть выражения, над которой производится операция, аргумент операции.