Автоматизированная система сервисного центра

    

 

Министерство образования  и науки, молодежи и спорта Украины

Севастопольский национальный технический университет

 

 

 

 

 

 

Кафедра

информационных 

систем

 

 

 

 

 

 

КУРСОВОЙ ПРОЕКТ ПО ДИСЦИПЛИНЕ

«ОРГАНИЗАЦИЯ БАЗ ДАННЫХ»

 

«Автоматизированная система сервисного центра»

Пояснительная записка

 

Листов 40

 

 

 

 

 

ПРОВЕРИЛА

 «    »____________2012

 

РАЗРАБОТАЛИ

«    »____________2012

 

 

 

 

 

Севастополь

2012

 

 

 

АННОТАЦИЯ

 

Основной целью данного курсового  проекта являлась разработка информационно-справочной системы «Сервисный центр». Информационная система должна иметь удобный интерфейс, который позволяет пользователю осуществлять легкий доступ ко всем интересующим его данным.

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

После разработки программных приложений информационной системы необходимо произвести тестирование программы.

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Содержание   ВВЕДЕНИЕ 4 1 Постановка  задачи 5 2 Анализ предметной  области 7 2.1 Анализ  отношений между объектами 7 2.2 Построение  концептуальной модели 9 3 Разработка  логической схемы базы данных 12 3.1 Построение  реляционной модели 12 3.2 Нормализация  базы данных 13 4 Реализация  Баз Данных 17 4.1. Разграничение  доступа 17 4.2. Организация  секретности 18 4.3. Целостность базы данных 18 5 Исследование  информационных параметров Базы  Данных 20 6 Разработка  клиентского приложения 22 6.1 Обоснование  выбора языка программирования 21 6.2. Технические  условия применения программы 23 6.3. Тестирование  системы 24 ЗАКЛЮЧЕНИЕ 30 БИБЛИОГРАФИЧЕСКИЙ СПИСОК 31 Приложение А……………………………………………………………………32
					КУРСОВОЙ ПРОЕКТ
Из	Лист	N докум.	Подп.	Дата
Разраб.					ПОЯСНИТЕЛЬНАЯ ЗАПИСКА	Лит			Лист	Листов
Провер.									3
Н. Контр						Кафедра ИС гр. И-43д
Утв.

 

ВВЕДЕНИЕ

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

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

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

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

 Для  реализации поставленной задачи выбрана технологическая платформа 1С:Предприятие.

 

 

 

1 ПОСТАНОВКА ЗАДАЧИ

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

Курсовое проектирование включает следующие этапы:

1. Проектирование базы данных

1.1. Изучение предметной  области

1.2. Определение необходимых  операций выполняемых над БД

2. Разработка интерфейса
3. Разработка СУБД
1. Обеспечение секретности
2. Защита целостности данных

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

Основные требования к БД по функциональному  набору:

Требования по работе:

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

Требования по учету клиентов:

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

        Требования по учету сотрудников:

• возможность быстрого поиска работника.

        Требования по учету изделий:

• Учет изделий, которые подлежат ремонту.

Требования по учету брендов:

• Учет брендов, с которыми работает сервисный центр.

Внешняя модель разрабатываемой БД представлена на рис. 1.1.

 

Сотрудники

Клиент

Изделие

 

Работа

Бренд

 

 

Рисунок 1.1 - Внешняя модель базы данных

2 АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ

 

2.1 Анализ отношений между объектами

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

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

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

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

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

Изделие направляется менеджерам и инженерам в соответствии с заключенными документами.

Объектами рассматриваемой предметной области являются работа, включающий информацию о заказе на ремонт, клиенте, изделию, бренду; клиент, включающий информацию о клиенте; Изделие, включающий информацию о изделии. Каждый объект БД описывается своими свойствами, называемые атрибутами.

Для более наглядного представления  объектов представим их следующим образом, описывающих все их основные атрибуты.

1. Работа

• Номер работы

• Вид работы

2. Изделие

•   Номер изделия
•   Ви изделия
• Магазин
• Дата выпуска
• Дата продажи

        3.    Клиент

• Номер клиента
• ФИО клиента
• Телефон
• Адрес

      4.      Сотрудники

• Номер сотрудника
• Вид сотрудника(инженер, менеджер)

5.      Бренд

• Название бренда
• Адрес представителя

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

Отношение - таблица, обладающая следующими свойствами:

1. Каждый элемент таблицы представляет собой один элемент данных (отсутствие повторяющихся групп);
2. Все столбцы однородны (то есть элементы столбца имеют одинаковую природу);
3. Столбцам однозначно присвоены имена;
4. В таблице нет двух одинаковых строк;
5. В операциях с такой таблицей все строки и столбцы могут рассматриваться в любом порядке независимо от их смысла и содержания.

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

В основу модели положены следующие  допущения:

• За одним менеджером закреплено несколько брендов;
• Ремонт производится только по гарантии(бесплатно);
• За отдельными инженерами закреплены отдельные изделия;
• Один ремонт, одно изделие.

 

2.2 Построение концептуальной  модели

 Модель Сущность-Связь (ER-модель) — это модель данных, позволяющая описывать концептуальные схемы. Она предоставляет графическую нотацию, основанную на блоках и соединяющих их линиях, с помощью которых можно описывать объекты и отношения между ними какой-либо другой модели данных.

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

ER-модель является одной  из самых простых визуальных  моделей данных. Она позволяет  обозначить структуру «крупными  мазками», в общих чертах. Это  общее описание структуры называется ER-диаграммой.

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

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

• Работа;
• Изделие;
• Клиент;
• Сотрудники;
• Бренд.

Разработанная ER-диаграмма  представлена на рисунке 2.1.

ER-диаграмма состоит из  5 сущностей. Сущность изображается на диаграмме в виде прямоугольника. Каждая из них имеет свой набор атрибутов и каким-либо образом связана с другой сущностью. Такое отношение обозначается ромбом.  

                                                         Рисунок 2.1 – ER-диаграмма

 

 

 

 

 

 

 

 

 

3 РАЗРАБОТКА ЛОГИЧЕСКОЙ  СХЕМЫ БАЗЫ ДАННЫХ

 

3.1 Построение реляционной  модели

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

Любую простую сетевую  структуру можно преобразовать  в древовидную, введя избыточность.

Сотрудник

Клиент

Бренд

Работа

Изделие

Работа

 

 

 

Рисунок 3.1- Древовидная модель

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

Логическую схему  базы данных будем строить на основании  разработанной ER-диаграммы.

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

Строки имеют фиксированное  число полей (столбцов) и значений (множественные поля и повторяющиеся  группы недопустимы). Иначе говоря, в каждой позиции таблицы на пересечении  строки и столбца всегда имеется  в точности одно значение или ничего.

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

 

3.2 Нормализация базы данных

Приведение  модели к требуемому уровню нормальной формы является основой построения реляционной БД.

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

Избыточность влияет не на объем  памяти, а на устранения противоречивости данных.

Схема отношений должна удовлетворять  следующим требованиям:

1. Выбранные для отношения первичные ключи должны быть минимальными;
2. Выбранный состав отношений БД должен быть минимален, то есть отличаться минимальной избыточностью атрибутов;
3. При выполнении операций модификации, удаления и включения не должно быть трудностей;
4. Перестройка набора отношений, приведение новых типов данных должна быть минимальной;
5. Разброс времени ответа на различные запросы к БД должен быть небольшим.

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

Таблица находится в первой нормальной форме (1НФ) тогда и только тогда, когда ни одна из ее строк  не содержит в любом своем поле более одного значения (условие атомарности) и ни одно из ее ключевых полей не пусто.

Имеем следующие отношения  в 1НФ:

Работа (Номер работы,вид работы, номер изделия,номер сотрудника)

Клиент (Номер клиента, ФИО клиента, адрес, телефон)

Изделие (Номер изделия, вид изделия, магазин, дата выпуска, дата продажи, номер клиента)

Сотрудники(Номер сотрудника, вид сотрудника, ФИО сотрудника)

Бренд (Название бренда, адрес представителя) 

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

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

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

Имеем следующие отношения  во 2 НФ:

Работа (Номер работы,вид работы, номер изделия,номер сотрудника)

Клиент (Номер клиента, ФИО клиента, адрес, телефон)

Изделие (Номер изделия, вид изделия, магазин, дата выпуска, дата продажи,  номер клиента)

Сотрудники(Номер сотрудника, вид сотрудника, ФИО сотрудника)

Бренд (Название бренда, адрес представителя) 

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

Транзитивная  зависимость выявляет дублирование данных в одном отношении. Если А, В и С – три атрибута одного отношения и С зависит от В, а В от А, то говорят, что С транзитивно  зависит от А. Преобразование в третью нормальную форму происходит за счет разделения исходного отношения  на два.

 База данных находится в форме Бойса-Кодда так как каждая ее нетривиальная и неприводимая слева функциональная зависимость имеет в качестве своего детерминанта некоторый потенциальный ключ. В каждой из наших таблиц существует только один потенциальный первичный ключ, следовательно наша БД находится в НФБК.

Таким образом, получаем базу данных, приведенную к НФБК и содержащую упорядоченную информацию, детально отображающую рассматриваемую предметную область.

В разработанной БД ключевыми  полями являются:

• Номер работы;
• Номер клиента
• Номер изделия;
• Номер сотрудника.
• Название бренда

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

Рисунок 3.2 – БД после нормализации

        

 

 

 

 

 

 

 

 

 

 

 

4 РЕАЛИЗАЦИЯ БАЗЫ ДАННЫХ

 

4.1 Разграничение прав  доступа

     Исходя из предметной  области, список потенциальных  пользователей состоит из двух  элементов:

• Администратор;
• Менеджер;
• Инженер.

1. Администратор имеет неограниченный доступ. Он  осуществляет работу с базой данных. Возможности администратора:

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

2. Менеджер имеет ограниченный доступ к базе данных. Он при необходимости может осуществлять добавление и обслуживание клиентов.

3. Инженер также должен иметь ограниченный доступ к информации, 

запрещающий ему изменение  и удаление информации, так же он не должен иметь доступа к некоторой  служебной информации;

Администратор

    Таким образом, будет получена следующая системная организация проекта (Рисунок 4.1.):

Менеджер

 

Инженер

 

 

 

Рисунок 4.1. – Разграничение доступа

4.2. Организация  секретности

 

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

В данном проекте характер базы данных предполагает разграничение  доступа на редактирование данных.

        Пароли хранятся в текстовом документе и никак не защищены, но есть возможность проделать эту операцию в будущем(закодировать пароль).

        Имеется уникальный пароль для Администраторав случае если старый пароль был забыт.

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

Второй уровень предоставляет  неограниченный доступ к базе данных – уровень администратора.

4.3.   Целостность базы данных

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

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

  Выделяют три группы правил целостности:

1. Целостность по сущностям. Не допускается, чтобы какой-либо атрибут, участвующий в первичном ключе, принимал неопределенное значение.
2. Целостность по ссылкам. Значение внешнего ключа должно либо:

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

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

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

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

 

 

 

 

 

 

5 ИССЛЕДОВАНИЕ ИНФОРМАЦИОННЫХ ПАРАМЕТРОВ БАЗЫ ДАННЫХ

       Длина логической записи j-ого файла:

                                        [байт]   

L1=10+70+20+60=160 byte

L2=9+25+15+8+8=65 byte

L3=25+15=40 byte

L4=9+25=34 byte

L5=9+8+70+15+10+15+25+8=160 byte

 

        Объем памяти, необходимый для размещения информационного фонда без учёта системных данных и указателей составит:

                [байт]  где N - количество отношений реляционной базы данных, K _j - количество записей j-го файла.

I=10*160+10*65+10*40+10*34+10*160=4590 byte.

Приращение информационного  фонда

            [байт^-1]  где - число добавленных типов записей, - интенсивность добавления записей в файл j -го :

DI = 20+160+65*20+160*20= 7700.

Время резервного копирования  определяется интенсивностью отказов, сопровождающихся потерей данных

          [время]  где - интенсивность отказов,сопровождающихся потерей данных. Если данные такого рода отсутствуют, то копирование производится через промежутки времени, в которые поступает порция данных порядка 20% первоначального объёма БД.

                                                            

                                                      T= 0.2*4590/7700=0,11

Количество обращений  к логическим записям

 где  - количество обращений к записям j -го типа в i -м запросе.

N1=4

N2=4

N3=4

N4=2

N4=3

 

Интенсивность обращений  к информационному фонду

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

- данная переменная выражается  константой исходя из соображений  работы                        = 0,95; = 0,8;  = 0,75; = 0,7;  = 0,7;