Размещено на http://www.allbest.ru/

• Содержание
• Введение
• 1. Анализ существующей системы функционирования автомагазина
• 1.1 Анализ бизнес процессов автомагазина
• 1.2 Анализ современных архитектур информационных систем
• 1.3 Современные технологии разработки приложений для БД
• 1.4 Заключение по аналитическому разделу
• 2. Проектирование информационной системы автомагазина
• 2.1 Функциональная модель бизнес-процессов автомагазина
• 2.2 Информационное моделирование уровня «сущность-связь»
• 2.2.1 Логическая модель базы данных
• 2.2.2 Физическая модель базы данных
• 2.3 Выбор инструментальных средств разработки приложения
• 2.4 Заключение по проектному разделу
• 3. Разработка информационной системы автомагазина
• 3.1 Создание реляционной базы данных «Автомагазин»
• 3.2 Разработка приложения «Автомагазин» для БД
• 3.3 Тестирование и отладка системы
• 3.4 Заключение по технологическому разделу
• 4. Расчет общей стоимости владения информационной системой «Автомагазин»
• Заключение
• Список используемой литературы


Введение

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

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

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

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

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

Целью данной курсовой работы является проектирование информационной системы для автоматизации работы «Автомагазина».

Для достижения этой цели в работе решаются следующие задачи:

Ш разработать необходимые проектные материалы, такие как бланки документации, модель «сущность-связь», структура реляционной базы данных, реализация запросов;

Ш реализовать полученные таблицы в одной из системы управления базами данных;

Ш создать программу работы локальной базы данных;

Ш реализовать запросы средствами языка SQL.

Результат работы: создание информационной системы «Автомагазин», данную систему в дальнейшем можно использовать на небольших предприятии, в офисах продажи, организациях для удобства работы с базой данных в отслеживании информации о деятельности автомагазина. Готовый программный продукт также можно легко использовать в других сферах деятельности.

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

Основные функции СУБД - это описание структуры базы данных, обработка данных и управление данными.

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

Любая СУБД позволяет выполнять четыре простейшие операции с данными:

Ш добавить в таблицу одну или несколько записей;

Ш удалить из таблицы одну или несколько записей;

Ш обновить значения некоторых полей в одной или нескольких записях;

Ш найти одну или несколько записей, удовлетворяющих заданному условию.

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



1. Анализ существующей системы функционирования автомагазина

1.1 Анализ бизнес процессов автомагазина

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

Целью создания информационной системы «Автомагазин» является учет клиентов магазина, учёт продаж, закупок, ведение складской документации и финансовых движений.

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

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

В настоящее время для проектирования БД активно используются CASE-средства, в основном ориентированные на использование ERD (Entity -- Relationship Diagrams, диаграммы «сущность-связь»). С их помощью определяются важные для предметной области объекты (сущности), отношения друг с другом (связи) и их свойства (атрибуты). Следует отметить, что средства проектирования ERD в основном ориентированы на реляционные базы данных (РБД), и если существует необходимость проектирования другой системы, скажем объектно-ориентированной, то лучше избрать другие методы проектирования.

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

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

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

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

Анализ процессов взаимодействия служб страховой компании, по обслуживанию клиентов, проведем с помощью стандартов SADT (IDEF0). Методология SADT (Structured Analysis and Design Technique - методология структурного анализа и проектирования) представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели производственной системы. Сначала строится модель существующей организации работы AS-IS (как есть) на основе должностных инструкций, нормативной документации и т.д. Анализ модели позволяет понять, где находятся слабые места, в чем будут состоять преимущества новых процессов и насколько глубоким изменениям подвергнется существующая организация деятельности предприятия (компании, отдела). Диаграмма модели AS-IS в нотации IDEF0, приведены на рисунках 1.2-1.3

Рисунок 1 Контекстная диаграмма модели AS-IS

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

1. Стрелкой входа «Клиент» - платит магазину деньги в качестве платы за оказываемые услуги.

2. Стрелкой выхода «Заключение договора о покупке Т.С. либо комплектующих».

3. Стрелками управления:

Законы РФ - внешние правила, которыми управляется процесс функционирования магазина в соответствии с законами РФ;

Устав магазина - контроль за исполнением правил магазина;

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



Рисунок 2 Диаграмма декомпозиции первого уровня

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

1.2 Анализ современных архитектур информационных систем

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

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

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

Рисунок 3 Архитектура «файл-сервер»

Рисунок 4 Модель файлового сервера в архитектуре «файл-сервер»

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

Плюсы файл-серверной архитектуры:

Ш Многопользовательский режим работы с данными;

Ш Удобство централизованного управления доступом;

Ш Низкая стоимость разработки.

Минусы файл-серверной архитектуры:

Ш Низкая производительность;

Ш Низкая надежность;

Ш Слабые возможности расширения.

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

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



Рисунок 5 Клиент-серверная архитектура

Достоинства клиент-серверных СУБД:

Ш основная обработка данных выполняется на сервере, поэтому рабочие станции могут быть маломощными;

Ш проще модернизация (достаточно увеличить мощность сервера);

Ш надёжная защита данных (устанавливается на сервере);

Ш снижается нагрузка на сеть, так как передаются только нужные данные (запросы и результаты выполнения запросов);

Ш надёжная работа при большом количестве пользователей (запросы ставятся в очередь).

К недостаткам клиент-серверной архитектуры можно отнести - повышенные требования к мощности сервера и высокая стоимость коммерческих СУБД (Microsoft SQL Server и Oracle).

Типичная модель файлового сервера приведена на рисунке 1.7.



Рисунок 6 Модель файлового сервера в архитектуре «клиент-сервер»

Трехуровневая архитектура (клиентская часть «тонкий клиент» - сервер приложений - сервер БД). Трехзвенная архитектура представляет собой дальнейшее совершенствование архитектуры «клиент-сервер». Эта архитектура функционирует в Интернет-сетях. Клиентская часть, взаимодействующая с пользователем, представляет собой HTML-страницу в Web-браузере либо Windows-приложение, взаимодействующее с Web-сервисами. Вся программная логика вынесена на сервер приложений, который обеспечивает формирование запросов к базе данных, передаваемых на выполнение серверу баз данных. Сервер приложений может быть Web-сервером или специализированной программой (например, Oracle Forms Server).

1.3 Современные технологии разработки приложений для БД

Современной формой информационных систем являются банки данных, включающие в свой состав следующие составляющие:

Ш вычислительную систему;

Ш систему управления базами данных (СУБД);

Ш одну или несколько баз данных (БД);

Ш набор прикладных программ (приложений БД).

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

В самом общем случае приложение баз данных должно уметь делать следующее:

Ш получать доступ к БД;

Ш читать, добавлять, редактировать и удалять данные;

Ш представлять полученные данные в требуемом пользователем виде (формы, отчеты, многомерное представление и т. д.);

Ш поддерживать целостность данных, определять дополнительную бизнес-логику и ограничения на данные;

Ш обеспечивать требуемую безопасность данных.

Простым программам, работающим с небольшими БД, обычно хватает возможностей генераторов форм, имеющихся в распоряжении настольных СУБД типа Microsoft Access. Профессиональные клиент-серверные проекты преимущественно разрабатывают на платформах серьезных сред программирования, таких как Embarcadero RAD Studio XE. Другими словами, в качестве инструментальных средств, применяемых для написания прикладного программного обеспечения, сегодня используют языки программирования 4-го поколения. Наиболее известными такими языками являются объектно-ориентированные языки программирования (ООП) Delphi, С++, С#, Visual Basic и Java. Язык Visual Basic также обладает элементами ООП. Эти языки обладают необходимыми инструментами обработки запросов для баз данных. Стандартом языков запросов для БД можно считать язык SQL (Structured Query Language).

У перечисленных сред разработок приложений имеются практически идентичные компоненты, инструменты и технологии работы с базами данных и СУБД. Остановимся на Delphi (Borland C++ Builder). Для того чтобы приложение Delphi (Borland C++ Builder) смогло взаимодействовать с СУБД, ему требуется посредничество драйверов и клиентских библиотек. В операционной системе Windows имеется ряд предустановленных клиентов, в первую очередь, это довольно старые драйверы провайдера открытого подсоединения к БД (Open Database Connectivity, ODBC) и технология объектов данных ActiveX (Microsoft ActiveX Data Objects, ADO). У Embarcadero Technologies имеются свои собственные решения: dbExpress, драйверы для работы с СУБД InterBase и созданная на заре появления Delphi, а на сегодня устаревшая технология Borland DataBase Engine (BDE). Выбор того или иного механизма доступа к БД существенно влияет на процесс проектирования приложения, в частности определяет набор применяемых компонентов Delphi.

Все компоненты, имеющие прямое отношение к построению клиент-серверных проектов БД, разделяются на четыре группы (см. рисунок 1.8):

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

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

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

4. Элементы управления данными, умеющие отображать и редактировать записи в наборе.



Рисунок 7 Взаимодействие компонентов Delphi для работы с БД

Входящие в группу компоненты можно дополнительно классифицировать по принадлежности к технологии доступа к данным. В соответствии с такой классификацией в Delphi имеется четыре линейки компонентов: Borland Database Engine (BDE), ActiveX Data Objects (ADO) или dbGo (в ранних версиях Delphi), dbExpress и InterBase. Компоненты InterBase специализируются только на одноименной СУБД. Остальные компоненты универсальны и способны работать с широчайшим спектром клиент-серверных баз данных.

OLE DB и ADO (Microsoft ActiveX Data Objects) являются составными частями универсального механизма доступа к данным Microsoft (Microsoft Universal Data Access). Они позволяют осуществлять доступ как к реляционным, так и к нереляционным базам данных. ADO - это библиотеки COM-объектов, реализующие прикладной программный интерфейс для доступа к данным и используемые в клиентских приложениях. ADO базируется на библиотеках OLE DB, предоставляющих низкоуровневый интерфейс для доступа к данным. Основное назначение ADO - обеспечение простого универсального механизма доступа к данным. Отметим, что OLE DB и ADO на сегодняшний день являются самыми популярными способами доступа к данным. В первую очередь этот механизм предназначен для разработчиков на Visual Basic.

Рисунок 8 Доступ к данным с помощью ADO.NET

Ранние версии ADO были разработаны для использования в настольных приложениях, а Интернет-функции были добавлены позже. Создание технологии .NET позволяет использовать ADO.NET вне зависимости от того, разрабатываются они как настольные приложения, клиент-серверное или Web-приложение. Технология ADO.NET позволяет взаимодействовать с реляционными базами данных и другими источниками и оптимизированная для распределенных приложений (см. рисунок 1.9).

ASP.NET - это часть технологии .NET, используемая для написания мощных клиент-серверных интернет приложений. Она позволяет создавать динамические страницы HTML. ASP.NET возникла в результате объединения более старой технологии ASP (активные серверные страницы) и .NET Framework. Она содержит множество готовых элементов управления, используя которые можно быстро создавать интерактивные web-сайты. Технология ASP.NET не заменяет ASP. Архитектура .NET учитывает взаимодействия разных технологий, поэтому для перехода с одной технологии на другую есть три варианта:

Ш использование ASP наравне с ASP.NET;

Ш замена страниц ASP соответствующими ASP.NET;

Ш заменить страницы ASP полностью переработанными страницами ASP.NET.

В состав Delphi (Borland C++ Builder) включены утилиты, облегчающие написание приложений БД. Дадим краткое описание этих утилит.

BDE Administrator. Позволяет создавать и изменять так называемые псевдонимы БД.

SQL Explorer. Утилита во многом сходная с BDE Administrator, но помимо создания псевдонимов БД позволяет отлаживать SQL-запросы.

Database Desktop. Утилита, позволяющая создавать и заполнять БД. Хорошо работает только с БД формата Paradox. Для других форматов БД применять не рекомендуется.

Datapump. Утилита, позволяющая конвертировать БД из одного формата в другой. Использование утилиты с современными СУБД не рекомендуется.

SQL Monitor. Позволяет отлаживать SQL-запросы при использовании технологии доступа к БД BDE.

1.4 Заключение по аналитическому разделу

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



2. Проектирование информационной системы автомагазина

2.1 Функциональная модель бизнес-процессов автомагазина

Технология проектирования информационной системы автомагазина подразумевает создание двух функциональных моделей предметной области (в нотации IDEF0):

Ш модели существующей организации бизнес-процесса AS-IS (модель приведена в параграфе 1.1);

Ш модели новой организации бизнес-процесса ТО-ВЕ.

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

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

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

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

Рисунок 9 Контекстная диаграмма модели ТО-ВЕ

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

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

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

Рисунок 10 Диаграмма декомпозиции первого уровня

Рисунок 11 Диаграмма декомпозиции работы «Деятельность автомагазина»

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

2.2 Информационное моделирование уровня «сущность-связь»

Для проектирования реляционной базы данных автомагазина на физическом уровне будем использовать методологию IDEF1X (Integration DEFinition for Information Modeling). IDEF1X - язык для семантического моделирования данных, основанный на концепции «сущность-связь» (ER-диаграмм). Различают два уровня информационной модели: логический и физический.

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

Ш Физическая модель отражает физические свойства проектируемой базы данных (типы данных, размер полей, индексы). Параметры физической информационной модели зависят от выбранной системы управления базами данных (СУБД).

2.2.1 Логическая модель базы данных

Информационную модель будем строить на основе функциональной модели TO-BE, разработанной в параграфе 2.1. Такой подход позволяет создать структуру базы данных, полностью соответствующей функциям, которые выполняют различные отделы страховой компании. Названия всех дуг функциональной модели TO-BE составляют список потенциальных сущностей (таблица 2.1). Отметим, что в этом случае достигается адекватность информационной модели выполняемым функциям.

Таблица 2.1 Список потенциальных сущностей

Стрелки входа	Стрелки выхода	Стрелки управления	Стрелки механизма
Клиент	Получение прибыли	Сотрудники магазина	Внутренний регламент
Заказ автомобилей и комплектующих у поставщика	Получение товара	Дирекция	Гос. законы
Информация о ценах	Завершение сделки	Торговое оборудование	Текущие распоряжения
Информация о плане продаж

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

Ш Клиент.

Ш Дирекция.

Ш Сотрудники магазина.

Ш Заказ.

Ш Внутренний регламент

Ш Комплектующие.

Ш Завершение сделки.

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

На логическом уровне можно установить следующие связи между сущностями: идентифицирующую связь один-ко-многим, связь многие-ко-многим и неидентифицируемую связь один-ко-многим. Связь сущности с другими сущностями определяет ее тип.

Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями. Зависимая сущность не может существовать самостоятельно - экземпляр зависимой сущности определяется только через отношение к сущности, которая его идентифицирует. При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности автоматически переносятся в состав первичного ключа дочерней сущности. Первичный ключ (Primary Key, PK) - это атрибуты чьи значения однозначно определяют каждый экземпляр сущности.

Операция дополнения атрибутов дочерней сущности при создании связи называется миграцией атрибутов. В дочерней сущности новые атрибуты помечаются как внешний ключ (FK, Foreign Key).

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

2.2.2 Физическая модель базы данных

Для построения физической модели данных в MS Visio 2010 необходимо переключиться на физический уровень представления информационной модели. Для этого нужно выбрать пункты меню База данных > Параметры > Документ. В открывшемся окне на вкладке «Общие» установить переключатель в меню «Имена», видимые на схеме. Для физического представления информационной модели необходимо выбрать пункт «Физические имена». Для каждого атрибута (поля) необходимо определить тип данных.

Таким образом, проанализировав разработанную БД, можно сделать вывод, что она нормализована и соответствует трем нормальным формам.

2.3 Выбор инструментальных средств разработки приложения

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

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

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

Клиентская часть приложения разрабатывается, как правило, с использованием универсальных языков программирования. Одним из средств разработки клиентской части приложения является объектно-ориентированный язык программирования Turbo Delphi 2006 (условно-бесплатная версия известного продукта фирмы Borland), располагающей широкими возможностями по созданию приложений для баз данных. Эта современная визуальная среда обеспечивает:

Ш простоту создания пользовательского интерфейса программы;

Ш возможность работы с Web-сервисами;

Ш создание клиент-серверных приложений (включая работу через Интернет);

Ш поддержку многоплатформенного протокола передачи данных.

Эта версия Delphi снабжена необходимым набором драйверов для доступа к известным форматам баз данных, удобными и развитыми средствами для доступа к информации, расположенной как на локальном диске, так и на удаленном сервере. Библиотека объектов содержит большой набор визуальных компонент, значительно упрощающих разработку приложений для СУБД с архитектурой клиент-сервер. Объекты инкапсулируют в себя нижний уровень - Borland Database Engine.

Объекты БД в Delphi основаны на SQL и включают в себя полную мощь Borland Database Engine. В состав Delphi также включен Borland SQL Link, поэтому доступ к СУБД Oracle, Sybase, Informix и InterBase происходит с высокой эффективностью. Кроме того, Delphi включает в себя локальный сервер Interbase для того, чтобы можно было разработать расширяемые на любые внешние SQL-сервера приложения в офлайновом режиме. Разработчик в среде Delphi, проектирующий информационную систему для локальной машины (к примеру, небольшую систему учета медицинских карточек для одного компьютера), может использовать для хранения информации файлы формата .dbf (как в dBase или Clipper) или .db (Paradox). Если же он будет использовать локальный InterBase for Windows (это локальный SQL-сервер, входящий в поставку), то его приложение безо всяких изменений будет работать и в составе большой системы с архитектурой клиент-сервер.

В технологическом разделе будет произведена разработка «эскизного проекта» - прототипа баз данных, что позволяет проверить разработанные информационные модели баз данных, на основе которых можно проверить работоспособность разработки приложения БД с помощью Turbo Delphi 2006. Именно поэтому для реализации данного этапа была выбрана СУБД Microsoft Access.

Access - это функционально полная реляционная СУБД. Microsoft Access предоставляет максимальную свободу в задании типа данных (текст, числовые данные, даты, время, денежные значения, рисунки, электронные таблицы). Можно задавать также форматы хранения предоставления этих данных при выводе на экран или печать. В Access предусмотрены все возможности, обеспечивающие связь приложении с Internet/intranet. Одним щелчком кнопкой мыши можно сохранить таблицы, запросы, формы и отчеты в формате HTML. Соответствующий мастер позволяет даже новичку перенести коды HTML из объекта на Web-страницу, делая их доступными для использования всем, кто путешествует по Internet. Гиперссылки позволяют получать доступ к данным, которые размещены на Web-странице, прямо из форм Access.

2.4 Заключение по проектному разделу

На основе проведенного в исследовательском разделе анализа была спроектирована распределенная функциональная модель (модель TO-BE) управления бизнес-процессами автомагазина. Спроектированная база данных нормализована и соответствует трем нормальным формам.



3. Разработка информационной системы автомагазина.

3.1 Создание реляционной базы данных «Автомагазин»

Как сказано в проектном разделе прототип реляционной базы данных «Автомагазин» будет создан в Microsoft Access 2010.

В состав Access 2010 входят конструкторы таблиц, форм, запросов и отчётов. Система может работать под управлением Windows 7/8, так что при работе с ней пользователю доступны все преимущества ОС Windows. Работая в среде Microsoft Office 2010, пользователь получает возможность обмена данными между Access, Excel, Word, и PowerPoint. Можно вырезать, копировать и вставлять данные из любого приложения Windows в Access и вставить его в конструктор форм.

Microsoft Access может использоваться в работе все возможности технологии динамического обмена данными (DDE) и технологию OLE (связь и внедрение объектов). Технология DDE позволяет осуществлять обмен данными между Access и любым другим поддерживающим DDE приложением Windows. Технология OLE является более изощренным средством Windows, которое позволяет установить связь с объектами другого приложения (например, с Delphi) или внедрить какие-либо объекты в базу данных Access. Такими объектами могут быть картинки, диаграммы, электронные таблицы.

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

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

Таблица 3.1 «Сотрудники»

Название поля	Тип данных	Размер поля	Свойства
Код	Счётчик	Длинное целое	Индексированное поле (PK), совпадения не допускаются
ФИО	Короткий текст	50	Обязательное поле - Да
Должность	Короткий текст	20	Обязательное поле - Да
Номер телефона	Числовой	Длинное целое	Обязательное поле - Нет

Таблица 3.2 «Клиенты»

Название поля	Тип данных	Размер поля	Свойства
Код	Счётчик	Длинное целое	Индексированное поле (PK), совпадения не допускаются
ФИО	Короткий текст	50	Обязательное поле - Да
Адрес	Короткий текст	255	Обязательное поле - Да
Номер телефона	Числовой	Длинное целое	Обязательное поле - Нет

Таблица 3.3 «Автомобили»

Название поля	Тип данных	Размер поля	Свойства
Код	Счётчик	Длинное целое	Индексированное поле (PK), совпадения не допускаются
Марка автомобиля	Короткий текст	15	Обязательное поле - Да
Модель автомобиля	Короткий текст	15	Обязательное поле - Да
Количество	Числовой	Длинное целое	Обязательное поле - Да
Фотография автомобиля	Поле объекта OLE	-	Обязательное поле - Да
Объем двигателя	Короткий текст	5	Обязательное поле - Да
Мощность двигателя	Короткий текст	3	Обязательное поле - Да
Руль(левый)	Лог.	-	Обязательное поле - Да
Привод на все колеса	Лог.	-	Обязательное поле - Да
Стоимость автомобиля	Денежный	-	Обязательное поле - Да
Новый/подержанный	Лог.	-	Обязательное поле - Да
Пробег автомобиля, км	Короткий текст	255	Обязательное поле - Нет
Год выпуска автомобиля	Короткий текст	255	Обязательное поле - Да
Тип кузова автомобиля	Короткий текст	15	Обязательное поле - Да
Тип коробки(автомат/механика)	Короткий текст	255	Обязательное поле - Да
Количество мест	Числовой	-	Обязательное поле - Да

Таблица 3.4 «Заказы»

Название поля	Тип данных	Размер поля	Свойства
Код заказа	Счётчик	Длинное целое	Индексированное поле (PK), совпадения не допускаются
Покупатель автомобиля	Короткий текст	60	Обязательное поле - Да
Признак покупателя(юридическое лицо)	Лог.	-	Обязательное поле - Да
Банк покупателя	Короткий текст	60	Обязательное поле - Да
Номер счета в банке	Короткий текст	20	Обязательное поле - Да
Дополнения	Короткий текст	255	Обязательное поле - Да
Цена со скидкой	Денежный	-	Обязательное поле - Да
Заказчик	Короткий текст	60	Обязательное поле - Да
Количество	Числовой	-	Обязательное поле - Да
Автомобиль	Короткий текст	20	Обязательное поле - Да
Фото автомобиля	Поле объекта OLE	-	Обязательное поле - Да
Стоимость автомобиля	Числовой	-	Обязательное поле - Нет
Итого	Денежный	-	Обязательное поле - Да
Дата заказа	Дата и время	-	Обязательное поле - Да
Код автомобиля	Числовой	-	Обязательное поле - Да
Код дополнения	Числовой	-	Обязательное поле - Да

Таблица 3.5 «Комплектующие»

Название поля	Тип данных	Размер поля	Свойства
Код	Счётчик	Длинное целое	Индексированное поле (PK), совпадения не допускаются
Дополнительные услуги	Короткий текст	255	Обязательное поле - Да
Цена	Числовой	-	Обязательное поле - Да
Скидка,%	Короткий текст	255	Обязательное поле - Да
Итого(с учетом скидки)	Денежный	-	Обязательное поле - Да



Таблица 3.6 - «Характеристики»

Название поля	Тип данных	Размер поля	Свойства
Марка автомобиля	Короткий текст	15	Индексированное поле (PK), совпадения не допускаются
Модель автомобиля	Короткий текст	15	Обязательное поле - Да
Фотография автомобиля	Поле объекта OLE	-	Обязательное поле - Да
Стоимость автомобиля	Денежный	-	Обязательное поле - Да
Количество мест	Числовой	-	Обязательное поле - Да

Свяжем созданные таблицы. Для этого во вкладке «Работа с базами данных» нажимаем кнопку «Схема данных». Появится окно «Схема данных» на котором будет окно «Добавление таблиц». Добавляем все таблицы и расставляем их в удобном порядке. Далее производим связывание таблиц, причем связь начинается с таблиц-оригиналов с первичными ключевыми полями. В окне «Изменение связей» выбираем «Тип отношения» выражение «один-ко-многим». Схема данных связанных таблиц приведена на рисунке

Рисунок 11 Схема данных базы данных «Автомагазин»

Связь «один ко многим» - наиболее распространенный вид связи. При такой связи каждой строке таблицы A (от первичного ключа) может соответствовать множество строк таблицы B, однако каждой строке таблицы B может соответствовать только одна строка таблицы A.

Отметим, что перед тестированием базы данных, созданием форм, запросов, отчетов и макросов необходимо ее наполнить фактическими данными. Производим заполнение таблиц базы данных «Автомагазин».

Составим SQL-запросы:

Ш Вывод покупателей и заказов вместе со стоимостью в отсортированном порядке:

SELECT Заказы.[Покупатель автомобиля], Заказы.Дополнения, Заказы.[Цена со скидкой], Заказы.Количество, Заказы.Автомобиль, Заказы.[Стоимость автомобиля], Sum(Заказы.Итого) AS Итого

FROM Заказы

GROUP BY Заказы.[Покупатель автомобиля], Заказы.Дополнения, Заказы.[Цена со скидкой], Заказы.Количество, Заказы.Автомобиль, Заказы.[Стоимость автомобиля];

Ш Вывод всех марок и моделей авто, их количество и год выпуска:

SELECT Автомобили.[Марка автомобиля], Автомобили.[Модель автомобиля], Автомобили.Количество, Автомобили.[Фотография автомобиля], Автомобили.[Стоимость автомобиля], Автомобили.[Дата появления в продаже], Автомобили.[Год выпуска автомобиля]

FROM Автомобили;

Вид запросов в табличном режиме, по первым двум запросам, приведен на рисунке 3.2. и 3.3.

Рисунок 12 Табличный вид запроса «Вывод всех клиентов»



Рисунок 13 Табличный вид запроса «Вывод всех филиалов одного города»

Также в Access можно создать формы для ввода, удаления и редактирования данных таблиц. Однако, реализацию этих процедур будет исполнять приложение «Информационная система автомагазин», разработка которого производится в интегрированной среде разработки Turbo Delphi 2006, тем не менее ниже приведены примеры некоторых возможных форм в Microsoft Access.

Рисунок 14 Вид формы для добавления продаваемых автомобилей



Рисунок 15 Вид формы кнопочной формы в Access.

3.2 Разработка приложения «Автомагазин» для БД

На данном этапе создается код программы в объектно-ориентированном языке программирования Delphi. Сначала опишем основные требования к интерфейсу пользователя. Интерфейс пользователя должен иметь:

Ш модуль главного меню, в котором осуществляется навигация по программе;

Ш модуль ввода и редактирования данных всех таблиц;

Ш модуль просмотра БД.

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

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

Запускаем Delphi. Выбираем File -> New-> VCL Forms Application.

Сохраняем модуль Unit1 и проект приложения под именем Avtoshop.dpr в своей папке. В эту же папку помещаем файл БД Страховая компания.accdb.

Сделаем нашу форму главной MDI формой (многодокументный интерфейс). Для этого в инспекторе объектов в свойствах Form1

FormStyle установим в fsMDIForm. Форма стала стартовой.

В свойстве Caption главной формы пишем «Информационная система

автомагазина».

Добавим к нашему приложению еще 6 форм, которые назовем «Клиенты», «Характеристики авто» «Сотрудники», «Заказы», «Автомобили», «Комплектующие». Знакомим все эти формы. Т.е. главная форма должна «знать» о существовании других семи форм, а те, в свою очередь, должны знать о существовании главной. Это нужно для того, чтобы мы могли из главной формы вызвать другую форму. Знакомим Form1 и Form2. Делаем активной Form1 (щелкнем по Unit1, а затем по форме). Далее File-> Use Unit. (Использовать модуль), где в контекстном меню выбираем Unit2 и жмем OK. Теперь форма Form1 знает о существовании Form2, в коде Unit1 в разделе implementation прописалась строка (проверяем это нажав F12). То же самое проводим и для других форм. Формы познакомлены.

На главной форме располагаем семь кнопок Button1-Button7 (из вкладки Standart), придаем им название по созвучию вызываемой таблицы из базы данных. Для красоты изображения вставляем компонент XPManifest (вкладка вкладке Win32). Внешний вид главной формы приведен на рисунке



Рисунок 16 Внешний вид главной формы приложения

Для реакции на нажатия кнопок по вызову других форм в Unit1 пишем следующий код:

uses Unit1, Unit3, Unit4, Unit5, Unit6;

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);

begin

Form2.Show // показать содержимое формы

end;

procedure TForm1.Button2Click(Sender: TObject);

begin

Form3.Show

end;

procedure TForm1.Button3Click(Sender: TObject);

begin

Form4.Show

end;

procedure TForm1.Button4Click(Sender: TObject);

begin

Form5.Show

end;

procedure TForm1.Button5Click(Sender: TObject);

begin

form6.Show

end;

Привязка БД «Автомагазин.accdb» к приложению

Командой File / New / Data Module (в категории Delphi Files) добавляем

в проект новый модуль данных. Дадим ему имя dm (для краткости) и сохраняем его как DatMod.pas в папку приложения.

Положим на модуль dm компонент ADOConnection (в закладке dbGo). Компонент ADOConnection1 позволит привязать БД Страховая компания.accdb к приложению. Настраивая компонент ADOConnection, дважды щелкнем на этом компоненте. В открывшемся окне установите источник связи, выбрав Use Connection String.

Рисунок 17 Окно модуля данных

Нажимаем на кнопку Build..., переходим на закладку «Поставщик данных» и выбираем Microsoft Office 12.0 Access Database Engine Provider. Нажмаем кнопку Далее.



Рисунок 18 Окно свойств связи с данными

Переходим на закладку Соединение, введём в строку Источник данных имя нашей БД. Если для доступа к БД необходим пароль и идентификатор пользователя, то их надо указать (по умолчанию к БД, созданной в MS Access, доступ есть у пользователя Admin, но пароль не нужен). После этого нажимаем кнопку Проверитьподключение, чтобы проверить подключается ли БД Страховая компания.accdb. Если будет дан ответ «Проверка подключения выполнена», то щелкаем по кнопке ОК закрыть все окна.



Рисунок 19 Подключение БД к приложению

Установим свойства ADOConnection в Инспекторе объектов:

- LoginPrompt = False - запрос имени и пароля пользователя отключен.

- Mode = cmShareDenyNone.

- Connected = True - подключение к базе активировано.

Связывание таблиц БД с приложением

Положим на модуль данных dm компоненты ADOTable (закладка

dbGo) и DataSource (закладка DataAccess).

Для удобства работы назовём их TabAvto и dsAvto, соответственно. Для этого в инспекторе объектов ADOTable1 в свойство Name записываем TabAvto, а в инспекторе объектов DataSource1 в свойство Name записываем dsAgent.

Подключим таблицу TabAvto к компоненту ADOConnection1 и к

одноименной таблице «Автомобили» нашей БД.

В инспекторе объектов таблицы TabAvto устанавливаем свойства:

- Connection = ADOConnection1.

- TableName = Агенты.

- Active = True (! это свойство устанавливать в последнюю очередь).

Рисунок 20 Установка свойств компонента (ADOTable1)

В инспекторе объектов компонента dsAvto (бывшая DataSource1)

установиv свойство DataSet = TabAvto.

Рисунок 21 Установка свойств компонента (DataSource1).

После определения свойств исчезнут красные знаки вопроса слева от

компонентов в окне Stucture, что говорит о готовности компонента к работе.

Двойным щелчком на компоненте TabAgent откроем Окно редактора полей, щелкнем в окне правой кнопкой мыши и в контекстном меню выберем команду Add all fields. Окно редактора заполнится списком всех полей таблицы Заказы. Если щелкнуть на любом поле в окне редактора полей, то в окне инспектора объектов станут доступными свойства объекта-поля.

Рисунок 22 Добавление полей в компонент

Поступая аналогичным образом, установиv в модуль dm соответствующие компоненты для таблиц «Клиенты» (компоненты TabKlient, dsKlient),

Сохраняем проект - File -> Save All.

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

Знакомим Form1 и Form2 с модулем DatMod.

Положим на Form2 компонент GroupBox (закладка Standard) и используя свойства Caption дадим ему заголовок «Автомобили» (для GroupBox1),

Положив в GroupBox1 сетку DbGrid1 (закладка Data Controls), для

DbGrid1 связываем свойство DataSource с источником данных dsAvto. В Окне редактора полей (двойной клик по DbGrid1) выберите команду Add all fields.

Проделаем ту же операцию для остальных форм.

Сохраняем (File -> Save All) и компилируем (F9) проект.

Положим в GroupBox1 под сетку DbGrid1 компонент DBNavigator

(закладка Data Controls). В инспекторе DBNavigator свойство DataSource = dsAgent.

Проделаем ту же операцию для остальных форм.

Рисунок 23 Внешний вид формы «Клиенты»

Рисунок 24 Внешний вид формы «Автомобили»



Рисунок 25 Внешний вид формы «Заказы»

Рисунок 26 Внешний вид формы «Комплектующие»



Рисунок 27 Внешний вид формы «Характеристики автомобилей»

3.3 Тестирование и отладка системы

После создания приложения необходимо провести его тестирование и отладку для обнаружения и исправления ошибок.

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

Стратегически можно подойти к процедуре построения тестов по двум направлениям:

...