Содержание

Введение

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

1.1 Общее описание предметной области

1.2 Описание информационных процессов проходящих в предметной област

1.3 Обоснование необходимости автоматизации

2. Проектирование

2.1 Построение диаграммы потоков данных

2.2 Построение Инфологической Модели

2.3 Обоснование выбора СУБД и языка программирования

2.4 Построение даталогической модели

3. Разработка приложения

3.1 Выбор среды реализации

3.2 Особенности разработки приложения

3.3 Разработка пользовательского интерфейса

Список литературы

Графическое приложение

Листинг программы

Введение

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

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

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

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

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

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

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

Деятельность по предоставлению услуг в области видеопроката относится к отрасли "культура и искусство" 93000 в соответствии с Общероссийским классификатором отраслей народного хозяйства (ОКОНХ), непроизводственной сфере деятельности. Видеопрокат относится к материальным услугам и характеризуется следующими качествами:

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

- неотделимостью от источника (контакт с потребителем - неотъемлемая часть предоставления услуги видеопроката);

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

2. 1.2 Описание информационных процессов проходящих в предметной области

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

В процессе приема заказа производится его прием от клиента и регистрация. Регистрационные данные сохраняются в компьютере и используются для последующего поиска.

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

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

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

1. 1.3 Обоснование необходимости автоматизации

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

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

Итак, можно сказать, что итогом проектирования должна быть система управления баз данных. СУБД должна иметь дружественный интуитивно понятный интерфейс (быть наглядной, простой в освоении…), так как пользоваться ей предстоит, как правило, слабо подготовленных пользователей, не имеющих определенных знаний в области информационных систем. К СУБД может быть спроектирована система помощи, направленная на ее быстрое освоение и поиска ответов на возможные возникшие вопросы при пользовании программным средством. Естественно отметить в вышеперечисленных этапах процессы, которые легко подвергаются автоматизации и в которых целесообразно создание электронных баз данных (например, регистрация заказов, данные о клиенте, ведение статистики заказов и прочее). Данная система в соответствии с проведенным ранее анализом легко подвергается автоматизации. В качестве операционной среды была выбрана MS Windows XP/Vista – совместимая среда, в качестве языка программирования SQL.

2. Проектирование ЭИС

2. 2.1 Построение диаграммы потоков данных

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

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

Внешние сущности изображают входы в систему и/или выходы из системы. Внешние сущности изображаются в виде прямоугольника с тенью и обычно располагаются по краям диаграммы(рис.1 блок «Клиент»). Потоки работ изображаются стрелками и описывают движение объектов из одной части системы в другую. Поскольку в DFD каждая сторона работы не имеет четкого назначения, как в IDEF0, стрелки могут подходить и выходить из любой грани прямоугольника работы. В DFD также применяются двунаправленные стрелки для описания диалогов типа "команда-ответ" между работами, между работой и внешней сущностью и между внешними сущностями. (рис. 1 блоки «Информация о клиенте» и «Внесение информации о заказе»). В отличие от стрелок, описывающих объекты в движении, хранилища данных изображают объекты в покое.

2.2 Построение Инфологической Модели

Так как в процессе моделирования системы было выяснено, что необходимо создание хранилищ данных (клиенты, заказы, база фильмов …), то в процессе моделирования системы необходимо рассмотреть закрепление этих хранилищ за основными процессами. Это можно сделать при помощи модели IDEF1X, которая является методологией построения реляционных структур баз данных в терминах сущность-связь. Построим модель данных в стандарте IDEF1Х. Данная модель изображена на рисунке и имеет 4 сущности (2 из которых зависимые), объединенных связями. Все связи один-ко-многим, следовательно модель не противоречит концепции IDEF1Х («связи многие-ко-многим нежелательны ибо не раскрывают реальную структуру данных…»).

В модели IDEF1X легко заметить по внешнему представлению зависимые и независимые сущности (зависимые сущности обозначаются прямоугольниками с закругленными концами). В данной модели, как это было сказано ранее, это – «Deal». Естественно, без клиента не может быть заказа, произведенного им. Статистика заказов не может существовать без заказов.

2.3 Обоснование выбора СУБД и языка программирования

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

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

Ограничения на значения отдельных столбцов; условия ограничений могут быть разнообразны — от требования удовлетворения вводимых значений определенному диапазону или соответствия некоторой маске до требуемого отношения с одной или несколькими записями из другой таблицы (или многих таблиц) БД.

Генераторы для создания и использования уникальных значений нужных полей.

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

Триггеры — подпрограммы, автоматически выполняемые сервером до или (и) после события изменения записи в таблице БД.

В составе записи БД могут определяться BLOB-поля (Binary Large Object —большой двоичный объект), предназначенные для хранения больших объемов данных в виде последовательности байтов. Таким образом могут храниться текстовые и графические документы, файлы мультимедиа, звуковые файлы и т. д. Интерпретация BLOB-поля выполняется в приложении, однако разработчик может определить так называемые BLOB-фильтры для автоматического преобразования содержимого blob-поля к другому виду.

InterBase дает возможность использовать функции, определяемые пользователем (User Defined Function, UDF), в которых могут реализовываться функциональности, отсутствующие в стандартных встроенных функциях InterBase (вычисление максимума, минимума, среднего значения, преобразование типов и приведение букв к заглавным). Например, в UDF можно реализовать извлечение из значения даты номера дня, года; определение длины символьного значения; усечение пробелов; разные математические алгоритмы и т. п. Функция пишется на любом алгоритмическом языке, позволяющем разрабатывать DLL (библиотеки динамического вызова), например, на Object Pascal.

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