Разработка базы данных для фирмы, занимающейся ремонтом организационной техники

 

 

СОДЕРЖАНИЕ

 

ВВЕДЕНИЕ	3
1 Описание предметной области	5
2 Инфологическое (концептуальное) проектирование	6
2.1 Определение и формулировка сущностей	6
2.2 Назначение сущностям описательных атрибутов	7
2.3 Установление отношений между сущностями	7
2.4 Диаграмма связей типа «Атрибут - Атрибут»	7
3 Логическое проектирование	8
3.1 Отображение концептуально-инфологической модели на реляционную модель	8
3.2 Нормализация отношений	10
4 Физическое проектирование	12
5 Руководство пользователя	13
ЗАКЛЮЧЕНИЕ	15
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ ПРИЛОЖЕНИЯ	16 17

 

 

 

 

 

 

 

 

 

 

 

 

 

ВВЕДЕНИЕ

 

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

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

Современные СУБД в основном являются приложениями Windows, так как данная среда позволяет более полно использовать возможности персональной ЭВМ, нежели среда DOS. Снижение стоимости высокопроизводительных ПК обусловил не только широкий переход к среде Windows, где разработчик программного обеспечения может в меньше степени заботиться о распределении ресурсов, но также сделал программное обеспечение ПК в целом и СУБД в частности менее критичными к аппаратным ресурсам ЭВМ.

Среди наиболее ярких представителей систем управления базами данных можно отметить: Lotus Approach, Microsoft Access, Borland dBase, Borland Paradox, Microsoft Visual FoxPro, Microsoft Visual Basic, а также баз данных Microsoft SQL Server и Oracle, используемые в приложениях, построенных по технологии «клиент-сервер». Фактически, у любой современной СУБД существует аналог, выпускаемый другой компанией, имеющий аналогичную область применения и возможности, любое приложение способно работать со многими форматами представления данных, осуществлять экспорт и импорт данных благодаря наличию большого числа конвертеров. Общепринятыми, также, являются технологии, позволяющие использовать возможности других приложений, например, текстовых процессоров, пакетов построения графиков и т.п., и встроенные версии языков высокого уровня (чаще – диалекты SQL и/или VBA) и средства визуального программирования интерфейсов разрабатываемых приложений. Поэтому уже не имеет существенного значения на каком языке и на основе какого пакета написано конкретное приложение, и какой формат данных в нем используется.

Более того, стандартом «де-факто» стала «быстрая разработка приложений» или RAD (от английского Rapid Application Development), основанная на широко декларируемом в литературе «открытом подходе», то есть необходимость и возможность использования различных прикладных программ и технологий для разработки более гибких и мощных систем обработки данных. Поэтому в одном ряду с «классическими» СУБД все чаще упоминаются языки программирования Visual Basic 4.0 и Visual C++, которые позволяют быстро создавать необходимые компоненты приложений, критичные по скорости работы, которые трудно, а иногда невозможно разработать средствами «классических» СУБД. Современный подход к управлению базами данных подразумевает также широкое использование технологии «клиент-сервер».

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

 

1. Описание предметной области

 

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

1. Учет всех принимаемых аппаратов на ремонт;

2. Учет всех расходуемых материалов для ремонта;

3. Ведение справочников сотрудников и клиентов;

4. Постоянно обновляемый  прейскурант оказываемых услуг;

Для непосредственной работы, необходима возможность формирования отчётов. При этом требуется следующий отчет:

1. Общий отчет по ремонтам.

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

 

2. Инфологическое (концептуальное) проектирование

 

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

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

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

 

1. Определение и формулировка сущностей

 

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

Сущность «Заказы» содержит подробную информацию о поступивших аппаратах на ремонт.

Сущность «Клиенты» содержит сведения о клиентах фирмы.

Сущность «Определение стоимости заказа» содержит перечень всех выполненных услуг с указанием их стоимости.

Сущность «Сотрудники» содержит информацию о сотрудниках, работающих в данной фирме.

Сущность «Типы аппаратов» содержит полный перечень всех аппаратов, принимаемых на ремонт и обслуживание фирмой.

Сущность «Услуги» содержит перечень всех услуг, которые фирма может выполнить, а так же их стоимость.

 

2.2 Назначение  сущностям описательных атрибутов

 

Проанализировав предметную область, выделим оптимальный набор атрибутов в каждой сущности, которые отражены в таблицах 1-6 приложения А.

 

3. Установление отношений между сущностями

 

1. «Заказы» - «Определение  стоимости заказов».

Одному экземпляру сущности «Заказы» соответствует несколько экземпляров сущности «Определение стоимости заказов», так как для одного заказа на ремонт может быть выполнено несколько услуг. Следовательно, устанавливается связь «один ко многим».

2. «Услуги» - «Определение стоимости заказов».

Одному экземпляру сущности «Услуги» соответствует несколько экземпляров сущности «Определение стоимости заказов», так как одна услуга может быть выполнена для нескольких заказов.

3. «Сотрудники» - «Заказы».

Одному экземпляру сущности «Сотрудники» соответствует несколько экземпляров сущности «Заказы», так как один сотрудник может выполнять несколько заказов.

4. «Клиенты» - «Заказы».

Одному экземпляру сущности «Клиенты» соответствует несколько экземпляров сущности «Заказы», так как один клиент может заказать несколько заказов.

5. «Типы аппаратов» - «Заказы».

Одному экземпляру сущности «Типы аппаратов» соответствует несколько экземпляров сущности «Заказы», так как один тип аппарата может быть заказан в нескольких заказах.

 

2.4 Диаграмма связей типа «Атрибут - атрибут»

 

Диаграммы связей всех имеющихся сущностей представлены на рисунках 1-6 приложения Б.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

3 Логическое проектирование

 

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

Логическое проектирование выполняется в два этапа:

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

- анализ полученных отношений  на соответствие трем нормальным  формам.

 

3.1 Отображение концептуально-инфологической модели на реляционную модель

 

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

1. «Заказы» - «Определение стоимости  заказов»

«Заказы»

Код заказа

Дата

Сотрудник

Клиент

Тип аппарата

Модель аппарата

Сер. номер

«Определение стоимости заказов»

Код заказа

Наименование услуги

Цена

Данная связь имеет тип «Один ко многим». Исходной будет сущность «Заказы», так как из нее исходит простая связь, следовательно порожденной является сущность «Определение стоимости заказов».

2. «Услуги» - «Определение  стоимости заказов».

«Услуги»

Наименование

Цена

«Определение стоимости заказов»

Код заказа

Наименование услуги

Цена

Данная связь имеет тип «Один ко многим». Исходной будет сущность «Услуги», так как из нее исходит простая связь, следовательно порожденной является сущность «Определение стоимости заказов».

3. «Сотрудники» - «Заказы».

 «Сотрудники»

Код сотрудника

Фамилия

Имя

Отчество

Должность

Специализация

«Заказы»

Код заказа

Дата

Сотрудник

Клиент

Тип аппарата

Модель аппарата

Сер. номер

Данная связь имеет тип «Один ко многим». Исходной будет сущность «Сотрудники», так как из нее исходит простая связь, следовательно порожденной является сущность «Заказы».

4. «Клиенты» - «Заказы».