Проектирование системы учета заказов компьютерного сервис-центра

 

МИНИСТЕРСТВО  ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

Федеральное государственное бюджетное образовательное  учреждение

высшего профессионального образования

«Сибирский  Государственный Аэрокосмический  университет

имени академика М.Ф. Решетнева»

 

 

Институт  информатики и телекоммуникаций

Кафедра информатики и вычислительной техники

 

 

 

 

 

 

 

 

КУРСОВОЙПРОЕКТ

 

по дисциплине«УПРАВЛЕНИЕ ДАННЫМИ»

 

на тему: «Проектирование системы учета заказов компьютерного сервис-центра»

 

 

 

 

 

 

 

 

 

Выполнил  студент гр. БИС-01 

Очной формы  обучения

Ланг А.Н.

Руководитель:

к.т.н., профессор ФаворскаяМ. Н.

 

 

 

 

 

Дата сдачи  «____» ______________2013г.

Дата защиты «____» _____________2013г.

Оценка:

 

 

 

 

Красноярск 2013 г. 

 

 

СОДЕРЖАНИЕ

 

Введение 3

Глава I  Проектирование базы данных 4

1.1. Анализ предметной области 4

1.2. Построение информационно-логической модели данных 5

1.3. Логическое проектирование базы данных 6

1.4. Выбор целевой СУБД и среды программирования 8

1.5. Физическое проектирование базы данных 10

Глава II Разработка приложения 14

2.1. Интерфейс программного продукта 14

2.2. Реализация бизнес-логики предприятия в приложении 15

2.3. Руководство пользователя 16

Заключение 22

Список использованной литературы 23

 

 

 

 

Введение

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

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

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

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

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

• спроектировать базу данных;
• выбрать необходимое программное обеспечение, язык разработки и СУБД;
• реализовать базу данных;
• создать приложение, обеспечивающее пользователю доступ к базе данных;

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

Пояснительная записка изложена на 23 страницах,  содержит 12 рисунков и 10 таблиц.

Глава I  Проектирование базы данных

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

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

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

В общем случае существуют два похода к выбору состава и структуры  предметной области:

• Функциональный подход – он реализует принцип движения «от задач» и применяется тогда, когда заранее известны функции некоторой группы лиц и комплексов задач, для обслуживания информационных потребностей которых создается рассматриваемый программный продукт. В этом случае мы можем четко выделить необходимый минимальный набор объектов предметной области, которые должны быть описаны.
• Предметный подход – когда информационные потребности будущих пользователей БД жестко не фиксируются. Мы не можем точно выделить минимальный набор объектов предметной области, которые необходимо описывать. В описание предметной области в этом случае включаются такие объекты и взаимосвязи, которые наиболее характерны и наиболее существенны для нее. БД, конструируемая при этом, называется предметной, то есть она может быть использована при решении множества разнообразных, заранее не определенных задач.

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

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

Данная база предназначена для  ведения учета сборки оргтехники, в ней находятся 10 таблиц, в которые входят: «Клиенты», «Заказы», «Счет», «Комплектующие», «Сотрудники», «Комплектующие в заказе», «Заказ комплектующих», «Поставщик», «Приход» и «Оплата прихода».

2.   Построение информационно-логической модели данных

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

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

Необходимо построить базу данных, содержащую информацию о системе учета заказов компьютерного сервис-центра:

• перечень клиентов;
• список сотрудников;
• список поставщиков комплектующих;
• сведения о оказание услуг по заказу;
• сведение о приходе комплектующих;

На основании анализа предметной области мы выделили следующие сущности модели «сущность-связь» («Entity Relationship» - ER-модели): «Клиенты», «Поставщики», «Сотрудники», «Заказ», «Приход», «Инженеры» (рисунок 1).

Рисунок 1 - Сущности модели

 

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

1. Клиент делает заказ на ремонт.

2. Сотрудник принимает заказ.

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

3. Логическое  проектирование базы данных

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

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

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

Таким образом, выявление функциональных зависимостей между атрибутами БД дает нам схему базы данных «Система учета  заказов компьютерного сервис-центр»(Рис. 2).

Рисунок 1. - Логическая модель базы данных

4.   Выбор целевой СУБД и среды программирования

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

MySQL - свободная реляционная система управления базами данных. Разработку и поддержку MySQL осуществляет корпорация Oracle. Продукт распространяется как под GNU General Public License, так и под собственной коммерческой лицензией. MySQL является решением для малых и средних приложений. Входит в состав серверов WAMP, AppServ, LAMP и в портативные сборки серверов Денвер, XAMPP. Обычно MySQL используется в качестве сервера, к которому обращаются локальные или удалённые клиенты, однако в дистрибутив входит библиотека внутреннего сервера, позволяющая включать MySQL в автономные программы. Гибкость СУБД MySQL обеспечивается поддержкой большого количества типов таблиц: пользователи могут выбрать как таблицы типа MyISAM, поддерживающие полнотекстовый поиск, так и таблицы InnoDB, поддерживающие транзакции на уровне отдельных записей. Более того, СУБД MySQL поставляется со специальным типом таблиц EXAMPLE, демонстрирующим принципы создания новых типов таблиц. Благодаря открытой архитектуре и GPL-лицензированию, в СУБД MySQL постоянно появляются новые типы таблиц.

PostgreSQL - свободная объектно-реляционная система управления базами данных (СУБД). Существует в реализациях для множества UNIX-like платформ, включая AIX, различные BSD-системы, HP-UX, IRIX, Linux, Mac OS X, Solaris/OpenSolaris, Tru64, QNX, а также для Microsoft Windows. Сильными сторонами PostgreSQL считаются:

• поддержка БД практически неограниченного размера;
• мощные и надёжные механизмы транзакций и репликации;
• расширяемая система встроенных языков программирования: в стандартной поставке поддерживаются PL/pgSQL, PL/Perl, PL/Python и PL/Tcl; дополнительно можно использовать PL/Java, PL/PHP, PL/Py, PL/R, PL/Ruby, PL/Scheme и PL/sh, а также имеется поддержка загрузки C-совместимых модулей;
• легкая расширяемость;

SQLite — легковесная встраиваемая реляционная СУБД. Исходный код библиотеки передан в общественное достояние. Слово «встраиваемый» означает, что SQLite не использует парадигму клиент-сервер, то есть исполняемый процесс SQLite не является отдельно работающим процессом, с которым взаимодействует программа, а предоставляет библиотеку, с которой программа компонуется и движок становится составной частью программы. Таким образом, в качестве протокола обмена используются вызовы функций (API) библиотеки SQLite. Такой подход уменьшает накладные расходы, время отклика и упрощает программу. SQLite хранит всю базу данных (включая определения, таблицы, индексы и данные) в единственном стандартном файле на том компьютере, на котором исполняется программа.