34
Полная совместимость и поддержка более 20-ти типов СУБД на
основе прямого доступа к системному каталогу баз данных
(отпадает потребность в использовании ODBC).
Специальные реализации продукта с прямой поддержкой
расширенного набора атрибутов в моделях данных для средств
разработки приложений PowerBuilder и Visual Basic. Существуют
линки для работы с Delphi от третьих производителей.
Глубокая интеграция с продуктами Oracle, Sybase, Centura,
Microsoft на базе единого репозитория и эффективного обмена
проектами; импорт/экспорт с Rational Rose.
Автоматическая генерация экранных форм приложений для
PowerBuilder, Delphi, Visual Basic, созданных на основе
спроектированной модели данных.
На начальных этапах создания ИС необходимо понять, как работает
организация, которую собираются автоматизировать. Никто в организации не
знает, как она работает в той мере подробности, которая необходима для
создания ИС. Руководитель хорошо знает работу в целом, но не в состоянии
вникнуть в детали работы каждого рядового сотрудника. Рядовой сотрудник
хорошо знает, что творится на его рабочем месте, но плохо знает, как
работают коллеги. Поэтому для описания работы организации, а в нашем
случае работы менеджеров необходимо построить модель. Такая модель
должна быть адекватна предметной области, следовательно, она должна
содержать в себе знания всех участников бизнес-процессов организации.
Наиболее удобным языком моделирования бизнес-процессов является
IDEFO, называвшийся первоначально SADT Structured Analysis and Design
Technique. В IDEF0 система представляется как совокупность
взаимодействующих работ или функций. Такая чисто функциональная
ориентация является принципиальной функции системы анализируются
35
независимо от объектов, которыми они оперируют. Это позволяет более
четко смоделировать логику и взаимодействие процессов организации.
Под моделью в IDEF0 понимают описание системы (текстовое и
графическое), которое должно дать ответ на некоторые заранее
определенные вопросы.
Моделируемая система рассматривается как произвольное
подмножество. Произвольное потому, что, во-первых, мы сами умозрительно
определяем, будет ли некий объект компонентом системы, или мы будем его
рассматривать как внешнее воздействие, и, во-вторых, оно зависит от точки
зрения на систему. Система имеет границу, которая отделяет ее от
остального мира. Взаимодействие системы с окружающим миром
описывается как вход (нечто, что перерабатывается системой), выход
(результат деятельности системы), управление (стратегии и процедуры, под
управлением которых производится работа) и механизм (ресурсы,
необходимые для проведения работы). Находясь под управлением, система
преобразует входы в выходы, используя механизмы. Все это позволяет
сделать вывод о том, что методология IDEF0 наиболее подходит для
моделирования бизнес-процессов ООО «Перспектива».
Основными конструктивными элементами моделей являются
сущности, связи между ними и их свойства (атрибуты). Сущность – любой
различимый объект (объект, который мы можем отличить от другого),
информацию о котором необходимо хранить в базе данных. Логическая
структура базы данных – это описание состава, типа и длины
информационных единиц базы данных и связей между ними.
Сущности и связи модели данных представляются в виде реляционной
таблицы (отношения). Отношение, соответствующее сущности, содержит
атрибуты (столбцы), являющиеся атрибутами сущности и описывающие
сущность (объект). Атрибут или множество атрибутов, которые однозначно
определяют объект называются ключом.
36
Удобно представлять отношение как таблицу, где каждая строка есть
кортеж, и каждый столбец соответствует одному компоненту. Столбцы при
этом называются атрибутами и им присваивают имена. Список имён
атрибутов называется схемой отношения. Совокупность схем отношений,
используемых для представления информации, называются схемой базы
данных, а текущие значения соответствующих отношений – базой данных.
Процесс построения инфологической модели состоит из следующих
шагов:
– определение сущностей;
– определение зависимостей между сущностями;
– задание первичных и альтернативных ключей;
– определение атрибутов сущностей;
– приведение модели к требуемому уровню нормальной формы.
Логический уровень представления модели – это абстрактный взгляд
на данные, на нем данные представляются так, как выглядят в реальном
мире. Логическая модель данных является универсальной и никак не связана
с конкретной реализацией СУБД. Физическая модель данных, напротив,
зависит от конкретной СУБД, фактически являясь отображением системного
каталога. В физической модели содержится информация о всех объектах БД.
Поскольку стандартов на объекты БД не существует (например, нет
стандарта на типы данных), физическая модель зависит от конкретной
реализации СУБД. Следовательно, одной и той же логической модели могут
соответствовать несколько разных физических моделей.
Для инфологического проектирования базы данных было выбрано
CASE-средство Computer Associates ERwin 4.0.
Создание модели данных, как правило, начинается с создания
логической модели. После описания логической модели, проектировщик
может выбрать необходимую СУБД и ERwin автоматически создаст
соответствующую физическую модель. На основе физической модели ERwin
37
может сгенерировать системный каталог СУБД или соответствующий SQL-
скрипт. Этот процесс называется прямым проектированием (Forward
Engineering). Тем самым достигается масштабируемость – создав одну
логическую модель данных, можно сгенерировать физические модели под
любую поддерживаемую ERwin СУБД. С другой стороны, ERwin способен
по содержимому системного каталога или SQL-скрипту воссоздать и
физическую, и логическую модель данных (Reverse Engineering). На основе
полученной логической модели данных можно сгенерировать физическую
модель для другой СУБД и затем сгенерировать ее системный каталог.
Следовательно, ERwin позволяет решить задачу по переносу структуры
данных с одного сервера на другой.
Различают три уровня логической модели, отличающихся по глубине
представления информации о данных:
– диаграмма сущность-связь (Entity Relationship Diagram, ERD);
– модель данных, основанная на ключах (Key Based model, KB);
– полная атрибутивная модель (Fully Attributed model, FA).
Диаграмма сущность-связь представляет собой модель данных
верхнего уровня. Она включает сущности и взаимосвязи, отражающие
основные бизнес-правила предметной области. Такая диаграмма не слишком
детализирована, в нее включаются основные сущности и связи между ними,
которые удовлетворяют основным' требованиям, предъявляемым к ИС.
Диаграмма сущность-связь может включать связи многие-ко-многим и
не включать описание ключей. Как правило, ERD используется для
презентаций и обсуждения структуры данных с экспертами предметной
области.
Модель данных, основанная на ключах, – более подробное
представление данных. Она включает описание всех сущностей и первичных
ключей и предназначена для представления структуры данных и ключей,
которые соответствуют предметной области.
38
Полная атрибутивная модель – наиболее детальное представление
структуры данных: представляет данные в третьей нормальной форме и
включает все сущности, атрибуты и связи.
Различают два уровня физической модели:
– трансформационная модель (Transformation Model);
– модель СУБД (DBMS Model).
Физическая модель содержит всю информацию, необходимую для
реализации конкретной БД. Трансформационная модель содержит
информацию для реализации отдельного проекта, который может быть
частью общей ИС и описывать подмножество предметной области. ERwin
поддерживает ведение отдельных проектов, позволяя проектировщику
выделять подмножество модели в виде предметных областей (Subject Area).
Трансформационная модель позволяет проектировщикам и
администраторам БД лучше представлять, какие объекты БД хранятся в
словаре данных, и проверить, насколько физическая модель данных
удовлетворяет требованиям к ИС.
Модель СУБД автоматически генерируется из трансформационной
модели и является точным отображением системного каталога СУБД. ERwin
непосредственно поддерживает эту модель путем генерации системного
каталога.
39
2 Практическая часть
2.1 Информационное обеспечение задачи
2.1.1 Информационная модель и ее описание
Определим основные сущности разрабатываемой инфологической
модели:
1) Типы – типы комплектующих ПК и их характеристика;
2) Отделы – подразделения отдела информационных технологий;
3) Сотрудники – сотрудники отделов, в каких подразделениях
работают, описание их компьютера;
4) Клиенты – клиенты, для которых делаются проекты;
5) Производители – производители комплектующих;
6) Мастера – выполняют осмотр и выполняют заявки;
7) Проекты – заказанные и выполненные проекты;
8) Комплектующие – набор комплектующих компьютера;
9) Заявка – заявки на выполнение осмотра и ремонт техники;
10) Осмотр – фактическое выполнение осмотра;
11) Заказы – на приобретение комплектующих;
12) Работы – связанные с проектами;
13) Выполнение – выполнение работ, связанных с проектами.
Сущности «Типы», «Клиенты», «Производители», «Комплект»,
«Мастера», «Проекты», «Отделы», «Сотрудники» являются справочниками и
содержат данные, соответствующие их названию.
Сущность «Типы» содержит следующие данные: Тип комплектующих,
Характеристика типа комплектующих.
Сущность «Клиенты» содержит следующие данные: Номер клиента,
Наименование, ИНН, КПП, Контактную информацию, Банк, Руководитель.
Сущность «Производители» содержит следующие данные: Номер
производителя, Название производителя, Страна.
40
Сущность «Комплект» содержит следующие данные: Номер
комплекта, Номер сотрудника, Номер типа, Номер производителя, Номер
клиента, Модель, Дата выпуска, Стоимость, Срок гарантии.
Сущность «Мастера» содержит следующие данные: Номер мастера,
Фамилию, Имя, Отчество, Квалификацию.
Сущность «Проекты» содержит следующие данные: Номер проекта,
Название проекта, Номер клиента, Описание проекта, Дата начала, Дата
окончания, Стоимость, Состояние проекта.
Сущность «Отделы» содержит следующие данные: Номер отдела,
Название отдела, Фамилия, Имя, Отчество начальника отдела, Описание
отдела.
Сущность «Сотрудники» содержит следующие данные: Номер
сотрудника, Номер отдела, Фамилия, Имя, Отчество сотрудника, Должность,
Функциональные обязанности, Имя компьютера сотрудника, IP- адрес, Дата
ввода в эксплуатацию, Инвентарный номер, Описание, Контактная
информация.
Сущности «Заявка», «Осмотр», «Выполнение», «Заказы», «Работы»
являются основаниями для журналов.
Сущность «Заявка» содержит следующие данные: Номер заявки, Дата
заявки, Номер комплектующих, подлежащих осмотру, ремонту или замене,
Неисправность, Описание работ, Номер мастера, Выполнение.
Сущность «Осмотр» содержит следующие данные: Номер осмотра,
Дата осмотра, Номер комплектующих, подлежащих осмотру, ремонту или
замене, Неисправность, Номер мастера, Замена, Гарантия, Заказ.
Сущность «Выполнение» содержит следующие данные: Номер
выполнения, Номер проекта, Номер сотрудника, Характеристика.
Сущность «Работы» содержит следующие данные: Номер работы,
Номер выполнения, Дата, Характеристика.
41
Сущность «Заказы» содержит следующие данные: Номер заказа, Дата
заказа, Номер сотрудника, Наименование, Примечание.
Логическая модель базы данных, спроектированная в ERWin приведена
на Рис. 6.
2.1.2 Характеристика входной и результативноый информации
Входными данными должны быть:
а) по разрабатываемым проектам – наименование клиента, название
проекта, описиание проекта, дата начала работ, дата окончания работ,
стоимость разрабатываемого проекта;
б) данные о компьютерной и копировально-множительной техники
(расходных материалах, запчастях) – наименование, производитель,
поставщик, ответственное лицо, сведения о сервисе и ремонте.
Выходными данными должны быть:
а) сотрудники, задействованные в каждом из проектов;
б) история сервиса каждого компьютера;
в) список всех комплектующих, находящихся на гарантии;
г) комплектующие, которые необходимо заказать;
д) комплектующие, которые необходимо заменить;
е) список проектов по заказчикам;
ж) рейтинг сотрудников.
Имеется возможность поиска требуемой информации по всем таблицам
базы данных. В программе широко использован язык SQL.
Все отчеты генерируются в МS Еxcel, где их в дальнейшем также
можно редактировать.
Также имеется возможность графического отображения выходных
данных (в виде диаграммы).
Реализовано пользовательское меню и проработан пользовательский
интерфейс.
3
Рис. 6 Логическая ER-модель БД.
Klienti
id_klienta: NUMBER
Naimenovanie: VARCHAR2(50)
INN: VARCHAR2(10)
KPP: VARCHAR2(10)
Kontaktnaya_informatsiya: VARCHAR2(100)
Bank: VARCHAR2(150)
Rukovoditel: VARCHAR2(50)
Proekti
id_proekta: NUMBER
id_klienta: NUMBER
Nazvanie_proekta: VARCHAR2(50)
Opisanie_proekta: VARCHAR2(50)
Na4alo: DATE
Okon4anie: DATE
Stoimost: FLOAT
Sostoyanie: VARCHAR2(50)
Vipolnenie
id_vipolneniya: NUMBER
id_sotr: NUMBER
id_proekta: NUMBER
Harakteristika: VARCHAR2(50)
Raboti
id_raboti: NUMBER
id_vipolneniya: NUMBER
Data: DATE
Harakteristika: VARCHAR2(50)
Zayavki
Nomer_zayavki: INTEGER
id_komplekt: INTEGER
id_mastera: INTEGER
Data_zayavki: DAT E
Neispravnost: VARCHAR2(50)
Opisanie_rabot: VARCHAR2(50)
Vipolnenie: VARCHAR2(50)
Sotrudniki
id_sotr: NUMBER
id_otd: INTEGER
FIO_sotrudnika: VARCHAR2(50)
Doljnost: VARCHAR2(50)
Funktsii: VARCHAR2(50)
Imya_komputera: VARCHAR2(20)
IP: VARCHAR2(20)
Data_vvoda: DATE
Inventarniy: VARCHAR2(20)
Opisanie: VARCHAR2(50)
Kontaktnaya_informatsiya: VARCHAR2(50)
Otdeli
id_otd: NUMBER
Nazvanie_otdela: VARCHAR2(50)
FIO_na4alnika: VARCHAR2(50)
Opisanie: VARCHAR2(50)
Proizvoditeli
id_proizviditelya: NUMBER
Proizvoditel: VARCHAR2(50)
Strana: VARCHAR2(50)
Komplekt
id_komplekt: NUMBER
id_sotr: NUMBER
id_tip: NUMBER
id_proizviditelya: NUMBER
id_klienta: NUMBER
Model: VARCHAR2(50)
Data_vipuska: DAT E
Stoimost: FLOAT
Garantiya_do: DATE
Zakazi
Nomer_zakaza: NUMBER
id_sotr: INTEGER
Data_zakaza: DATE
Naimenovanie: VARCHAR2(50)
Prime4anie: VARCHAR2(50)
Tipi
id_tip: NUMBER
Tip: VARCHAR2(50)
Harakteristika: VARCHAR2(50)
Osmotr
id: NUMBER
id_komplekt: INTEGER
id_mastera: INTEGER
id_kompl: INTEGER
Data_osmotra: DAT E
Neispravnost: VARCHAR2(50)
Zamena: MLSLABEL
Garantiya: MLSLABEL
Zakaz: MLSLABEL
Mastera
id_mastera: NUMBER
FIO_mastera: VARCHAR2(50)
Kvalifikatsiya: VARCHAR2(50)
3
2.2 Программное обеспечение задачи
2.2.1 Общие положения
При анализе предметной области были выявлены специфики
предметной области. Все они были явно или неявно учтены в создаваемой
системе.
Требования к объёму данных и скорости работы системы:
количество сотрудников до 5000;
количество комплектующих до 100000;
количество мастеров до 20;
количество отделов до 100;
критичность к скорости работы всей системы;
Создаваемая система удовлетворяет этим требованиям. Превышение
указанных требований повлечёт снижение скорости работы системы,
устранение которого возможно посредством использование более мощного
технического оснащения сервера базы данных.
Спецификации по хранению различных данных: сведения о
сотрудниках, сведения о комплектующих, мастерах, заявках и т.д. были
учтены при проектировании модели данных.
Выявленные требования к уникальности некоторых данных:
название отдела;
наименование клиента;
название проекта;
ИНН, КПП;
производитель;
тип;
имя компьютера;
IP-адрес;
инвентарный номер компьютера.