Разработка информационного обеспечения и анализ данных для информационной системы "Станция технического обслуживания" (стр. 3 из 7)
Одни и те же услуги могут выполнять разные мастера, поэтому услугу можно представить как отдельный объект. С другой стороны один и тот же мастер может выполнять много услуг, поэтому отношение между услугой и мастером будет многие-ко-многим.
Зарплата мастеров зависит от выполняемых заказов, поэтому для каждого мастера необходимо завести "зарплатную книжку", то есть сформировать таблицу, которая будет в себе содержать информацию о мастере и его текущие начисления. То есть появляется новый объект "зарплата мастера".
Для формирования финансового отчёта необходимо учитывать заработную плату всех сотрудников, которая определяется окладом, заработную плату мастеров, которая начисляется в соответствии с выполненными заказами, а также расходы на покупку деталей. То есть появляется ещё один объект "отчёт", который включает в себя информацию о заработных платах и о заказах склада. Отношение между сотрудником и отчётом - один-ко-многим, так как в отчёте хранятся данные о всех сотрудниках, а у одного сотрудника может быть только одна зарплата. Аналогично определяется связь между зарплатой мастера и отчётом. Связь между заказом деталей и отчётом так же будет один-ко-могим, так как в отчёте хранятся данные по четырём заказам склада, соответствуя четырём неделям месяца. Заказ склада, в свою очередь содержит в себе информацию о деталях и стоимость. Связь между деталью и заказом склада - один-ко-многим.
Таким образом выделены следующие объекты: заказ, клиент, сотрудник, принимающий участие в организации заказа (секретарь, менеджер, бригадир), мастер, услуга, квалификация, заработная плата мастера, деталь, заказ деталей, отчёт по распределению финансов.
2.2 Инфологическое проектирование данных
Согласно представленным объектам в системном анализе предметной области необходимо представить объекты в виде сущностей и связей. Для этого будет использоваться методология Питера Чена:
Рисунок 3 - Инфологическая модель данных
В данной схеме хорошо просматриваются сущности, их атрибуты и связи. Сущности и связи соответствуют объектам, выделенным в предыдущем пункте, и их связям.
Датaлогическое проектирование. Нормализация данных
Для дальнейшего проектирования необходимо выбрать CASE-средства. Оценка CASE-средств будет производиться по следующим критериям:
возможность ввода и редактирования информации, описывающей элементы данных системы и их отношения;
удобство пользовательского интерфейса. Удобство расположения и представления часто используемых элементов экрана, способов ввода данных и др.;
простота освоения. Трудовые и временные затраты на освоение средств;
совместимость обновлений (совместимость новых версий с существующими, включая, например, совместимость по входным или выходным данным);
совместимость с версиями ОС (возможность работы в среде различных версий одной и той же ОС, простота модификации CASE-средства для работы с новыми версиями ОС);
переносимость данных между различными версиями CASE-средства;
затраты на CASE-средство. Включают стоимость приобретения, установки, начального сопровождения и обучения. С учётом цены для всех необходимых конфигураций (включая единственную копию, несколько копий, локальную лицензию, лицензию для предприятия, сетевую лицензию).
Каждый критерий может иметь оценку 0-5.
Оценка "0" означает, что данное программное обеспечение полностью не удовлетворяет требованию критерия.
Оценка "5" означает, что данный критерий выполняется полностью.
То CASE-средство, которое будет иметь наибольший балл, будет принято. Балл этого программного обеспечения не должен быть меньше 30.
Оценка отражена в таблице1.
В выборе и оценке учавствуют следующие программные средства: Vantage Team Builder (Westmount I-CASE), Designer/2000, Silverrun, ERwin+BPwin, S-Designor, CASE. Аналитик.
Таблица 1
Оценка CASE-средств
| CASE-средства Критерии оценки | Westmount I-CASE | Designer/2000 | Silverrun | ERwin+BPwin | S-Designor | CASE. Аналитик |
| возможность ввода и редактирования информации, описывающей элементы данных системы и их отношения | 5 | 5 | 5 | 5 | 5 | 5 |
| удобство пользовательского интерфейса | 4 | 3 | 3 | 5 | 4 | 4 |
| простота освоения | 4 | 3 | 4 | 5 | 5 | 4 |
| совместимость обновлений | 5 | 5 | 5 | 5 | 5 | 4 |
| совместимость с версиями ОС | 5 | 5 | 5 | 5 | 4 | 5 |
| переносимость данных между различными версиями CASE-средства | 5 | 4 | 5 | 5 | 4 | 5 |
| затраты на CASE-средство | 4 | 3 | 0 | 4 | 4 | 0 |
| ИТОГОВЫЙ БАЛЛ | 32 | 28 | 27 | 34 | 31 | 26 |
Из приведённой таблицы видно, что наиболее удобным средством для проектирования является Computer Associates Erwin, так как он имеет наибольший балл.
Переведём сущности и связи, определённые в предыдущем пункте, в отношения и связи. Для этого будем использовать логическую ER-модель.
Для нормализации данных необходимо устранить связи многие-ко-многим. Для этого эти связи разрываются дополнительной таблицей. Эта нормализация отображена на рисунке 5.
Рисунок 4 - Модель данных до нормализации
Рисунок 5 - Логическая схема данных
Нормализация необходима для устранения избыточности данных, которая возможна при наличии связей многие-ко-многим.
Физическое проектирование без учёта ПО для разработки СУБД
Все СУБД имеют определённый набор типов данных, имеющих одинаковый смысл, но имеющие разное написание. Поэтому можно определить общие типы данных, не ссылаясь на определённую СУБД. Для этого для каждой таблицы опишем все атрибуты, их расшифровки и общие типы.
Таблица 2
Определение типов таблицы "Клиент"
| Атрибут | Расшифровка | Тип |
| id_klient | Идентификационный номер | Автосчётчик |
| fam | Фамилия | Строка |
| name | Имя | Строка |
| otch | Отчество | Строка |
| nomer_avto | Номер автомобиля | Строка |
Таблица 3
Определение типов таблицы "Заказ"
| Атрибут | Расшифровка | Тип |
| id_sakas | Идентификационный номер | Автосчётчик |
| id_klient | ID клиента | Длинное целое |
| data_oformlenia | Дата оформления | Дата |
| stoimost | Стоимость | Деньги |
| data_vipolnenia | Дата выполнения | Дата |
| data_zakritia | Дата закрытия | Дата |
Таблица 4
Определение типов таблицы "Деталь"
| Атрибут | Расшифровка | Тип |
| id_detal | Идентификационный номер | Автосчётчик |
| Detal | Деталь | Строка |
| Cena | Цена | Деньги |
| kol | Количество | Байт |
Таблица 5
Определение типов таблицы "Заказ склада"
| Атрибут | Расшифровка | Тип |
| id_sak_sklada | Идентификационный номер | Автосчётчик |
| id_detal | ID детали | Длинное целое |
| Stoim_sak | Стоимость заказа | Деньги |
Таблица 6
Определение типов таблицы "Деталь-заказ"
| Атрибут | Расшифровка | Тип |
| id_detal | ID детали | Длинное целое |
| id_sakas | ID заказа | Длинное целое |
| id_klient | ID клиента | Длинное целое |
Таблица 7
Определение типов таблицы "Мастер"
| Атрибут | Расшифровка | Тип |
| id_master | Идентификационный номер | Автосчётчик |
| Fam | Фамилия | Строка |
| Name | Имя | Строка |
| Otch | Отчество | Строка |
| Stash | Стаж | Байт |
| nomer_pasp | Номер паспорта | Длинное целое |
| seria_pasp | Серия паспорта | Целое |
| data_post_na_rab | Дата поступления на работу | Дата |
| id_kvalif | ID квалификации | Длинное целое |
Таблица 8
Определение типов таблицы "Квалификация"
| Атрибут | Расшифровка | Тип |
| id_kvalif | Идентификационный номер | Автосчётчик |
| Kvalif | Квалификация | Строка |
Таблица 9
Определение общих типов таблицы "Мастер-заказ"
| Атрибут | Расшифровка | Тип |
| id_master | ID мастера | Длинное целое |
| id_sakas | ID заказа | Длинное целое |
| id_klient | ID клиента | Длинное целое |
Таблица 10
Определение типов таблицы "Зарплата мастера"