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

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

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

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

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

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

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

InterBase был разработан в начале 80-х годов группой разработчиков из американской корпорации DEC. В дальнейшем разработка данного продукта велась независимыми компаниями InterBase Software и впоследствии слившейся с ней Ashton-Tate. Borland приобрела права на InterBase у Ashton-Tate после слияния с нею.

InterBase активно используется в государственном и военном секторах США, что, видимо, и стало преградой для его продвижения в Россию. Интерес к этому серверу возрос только в последнее время в связи с включением его локальной (а начиная с Delphi 3 и 4-пользовательской) версии в состав Delphi Client/Server Suite и Delphi Enterprise. Внимание разработчиков БД InterBase привлек, во-первых, потому, что это «родной» продукт Borland (а средства разработки приложений этой компании давно зарекомендовали себя с положительной стороны), во-вторых, потому, что InterBase весьма прост в установке, настройке и администрировании по сравнению с другими SQL-серверами, и в-третьих, потому, что он обладает прекрасными функциональными возможностями.

Firebird выбран мной в качестве сервера из-за того, что он бесплатен и более функционален, чем Interbase, а также хорошо совместим с новыми операционными системами Windows Vista и Server 2008. Используемая мною версия это наиболее стабильная на данный момент – 2.0.3.

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

?????????? ???????, ????????? ???? ??? ?????? ???????? ?????? ? ?????????? ? ????????, ?????? ? ?????? ?????? ?????????? ????????????.????? ?????? ?????? ???????? ????????????? ????????? ?????? ?? ???????? ? ????? ????????? ?????? ????????? ? ?????????. ??? ??????? ??? ?????? ?? ?????? ?????? ??????? ???????? ???. ?????????? ?????? ?? ?????? ?????????????? ???????????. ????? ? ???????????? ?????????? ?????? ?????????? ???????? ? ??????????? ?? ?????????? ??????? (??????).

В процессе реализации задачи при разработке структуры для хранения данных, первым объектом выступают информация о товаре (дисках или кассетах) и клиентах. В нашем случае БД будет состоять из 3 таблиц. В таблице MOVIE будут содержаться сведения о фильмах (штрих-код, количество дисков, название, режиссер и жанр). В таблице CLIENT будут храниться все нужные сведения о клиентах – с указанием полных паспортных данных. Третья таблица DEAL будет содержать сведения о сделках (дата сделки, сумма с учетом скидки (если она есть) и т.д.) Таким образом, таблица DEAL будет центральной. Она должна будет иметь уникальной поле, которое будет однозначно определять каждую сделка. В дальнейшем по этому полю мы создадим первичный ключ, чтобы СУБД могла быстро найти нужную запись. Каждой записи в таблице MOVIE будет соответствовать произвольное количество записей в таблице DEAL (такая связь в терминологии БД называется связью один ко многим), т. е. одно из её полей будет содержать уникальный идентификатор фильма. В таблице DEAL будет также ссылка на уникальный идентификатор клиента из таблицы CLIENT. При появлении очередной записи в таблице DEAL должно меняться значение поля KOL (количество) в таблице MOVIE.

Таблица Фильмы (MOVIE):

ID

Целый

INTEGER

Уникальный идентификатор фильма. По этому полю создается первичный ключ. « 1 2 3 4 5 6 » К-во Просмотров: 257 Бесплатно скачать Курсовая работа: Создание базы данных для организации >>> Скачать <<< Меню Поиск