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

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):

Таблица Клиенты(CLIENT):

Таблица Заказы(DEAL):

Таблица Log

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

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

5. Среда разработки Borland Delphi.

Приложение-клиент разрабатывается при помощи программных средств Borland Delphi, используя набор компонентов Interbase Express (IBX). Эти компоненты используют функции Intebase API, т.е. обращаются к серверу непосредственно. VCL-библиотека классов среды проектирования Delphi предоставляет ряд классов, позволяющих быстро и эффективно разрабатывать различные приложения баз данных.

Эти классы представлены следующими группами:

• компоненты для доступа к данным, реализующие:

  • доступ через машину баз данных BDE (Borland Database Engine), предоставляющую доступ через ODBC-драйверы или через внутренние драйверы машины баз данных BDE (компоненты страницы BDE-палитры инструментов);

  • доступ через ADO-объекты (ActiveX Data Objects), в основе которого лежит применение технологии OLE DB (компоненты страницы ADO);

  • доступ к локальному или удаленному SQL-серверу InterBase (компоненты страницы InterBase);

  • доступ посредством легковесных драйверов dbExpress;

  • доступ к БД при многозвенной архитектуре (компоненты страницы DataSnap);

• визуальные компоненты, реализующие интерфейс пользователя;

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

• компоненты для визуального проектирования отчетов.

Компоненты для доступа к серверу InterBase:

• TIBDatabase — предназначен для подключения к базе данных. Основные методы: Open, Close.

• TIBTransaction — предназначен для явного управления транзакцией. Основные методы: StartTransaction, Commit, Rollback, CommitRetaining, RollbackRetaining.

• TIBTable — аналог стандартного TTable. Компонент предназначен для получения данных из одной таблицы или представления базы данных. Основное свойство — TableName. Основные методы: Open, Close. Набор данных, полученных при помощи TIBTable, является редактируемым, если речь идет о таблице базы данных или обновляемом представлении. Компонент совместим с визуальными компонентами.

• TIBQuery — аналог стандартного TQuery. Компонент предназначен для получения данных на основе SQL-запроса. Этот набор данных не всегда будет редактируемым, зачастую необходимо использовать дополнительный компонент TIBUpdateSQL, чтобы иметь возможность редактировать полученные сведения. Основное свойство — SQL. Основные методы: Open, Close, ExecSQL. Компонент совместим с визуальными компонентами.

• TIBDataSet — предназначен для получения и редактирования данных, является потомком стандартного класса TDataSet и полностью совместим со всеми визуальными компонентами. Основные методы: Prepare, Open, Close, Insert, Append, Edit, Delete, Refresh.

• TIBStoredProc — предназначен для выполнения хранимых процедур и получения набора данных на основе результатов выполнения процедуры. Получаемый набор данных является нередактируемым. Компонент совместим с визуальными компонентами. Основное свойство — StoredProcName. Основной метод — ЕхесРгос.

• TIBUpdateSQL — аналог TUpdateSQL. Используется в паре с TIBQuery и предназначен для создания модифицируемых наборов данных. Основные свойства: DeleteSQL, InsertSQL, ModifySQL и RefreshSQL.

• TIBSQL — предназначен для выполнения SQL-запросов. В отличие от TIBQuery или TIBDataSet, TIBSQL не имеет локального буфера для набора данных и несовместим с визуальными компонентами.

• TIBDatabaseInfo — позволяет получить системную информацию о некоторых свойствах базы данных, соединения и сервера. Например, UserNames — список пользователей, подключенных к базе данных, PageSize — размер страницы базы данных.

• TIBSQLMonitor — предназначен для перехвата и отслеживания всех запросов, которые выполняют приложения, использующие IBX.

TIBEvents — предназначен для получения пользовательских событий InterBase. Основное свойство — Events. Основные методы: RegisterEvents, UnregisterEvents.

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

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

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

В целом функциональная спецификация состоит из трех основных частей:

1. Описание внешней информационной среды по отношению к программному средству;

2. Определение функций ПС. Чаще всего такие функции рассматриваются на множестве состояний внешней информационной среды;

3. Описание нежелательных ситуаций, которые могут возникнуть при работе ПС и описание реакции ПС на эти ситуации.

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

Как сказано выше, основными функциями разрабатываемого ПС являются:

- Добавление нового поступления видео-продукции с проведением маркировки. Каждое новое поступление должно быть введено в базу фильмов с заполнением всех необходимых полей. Результатом выполнения данной функции является запись в таблице базы данных и присвоение каждому видео-фильму своего индивидуального номера, с его последующим нанесением на физический носитель. Повторение индивидуального номера не допускается, поэтому необходимо либо генерировать его внутри системы. Название видео-фильма должно быть символьным и не более 50 символов. Число копий должно быть целым числом. Поля «Носитель», «Категория», «Производство фильма (Страна)», заполняются из выпадающих списков.

- Регистрация новых клиентов пункта проката. Регистрация клиентов производится только при наличии паспорта. При регистрации необходимо обязательно заполнить поля «№ паспорта», «Фамилия», «Имя», «Отчество», остальные поля не обязательными для заполнения. Также необходимо проводить проверку на совпадение вводимой информации при регистрации нового клиента по всем обязательным параметрам в совокупности и при совпадении необходимо выводить соответствующее сообщение. Поля «Фамилия», «Имя», «Отчество», «Адрес» являются символьными и ограничены 50 символами.

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

- Возможность показа статистики заказов отдельным клиентом. Результатом работы данной функции является вывод списка с информацией о клиенте и видео-продукцией, которую он заказывал ранее. В этом списке указывается количество заказов, сделанных клиентом, размер штрафа, который он уплатил, количество дней, прошедших с момента регистрации. Также указывается количество заказов, которые клиент сделал, выбирая видео-продукцию на различных видов носителей (VHS, CD, DVD). Входной информацией является ввод в поле «Номер паспорта», который является целым числом. Также имеется возможность показа статистики заказов отдельного фильма. Результатом работы является вывод списка с информацией о количестве заказов фильма, название которого введено в поле «Название фильма», а поле «Номер паспорта» остается пустым.

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

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