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 | Уникальный идентификатор фильма. По этому полю создается первичный ключ.(штрих код диска) |
| NAME_FILM | Строковый | VARCHAR 50 | Название фильма (индексное поле) |
| DIRECTOR | Строковый | VARCHAR 50 | Режиссер |
| GANR | Строковый | VARCHAR 10 | Жанр (набор фиксированных значений: комедия, триллер, боевик и т. д.) Индексное поле |
| KOL | Целый | INTEGER | Количество на складе |
| MONEY | Целый | INTEGER | Цена |
| DESCRIPTION | Строковый | VARCHAR 250 | Краткое описание фильма |
Таблица Клиенты(CLIENT):
| ID_C | Целый | INTEGER | Уникальный идентификатор клиента (первичный ключ) |
| FIO | Строковый | VARCHAR 50 | ФИО (индексное поле) |
| PASPORT | Строковый | VARCHAR 150 | Паспортные данные |
Таблица Заказы(DEAL):
| ID_D | Целый | INTEGER | Уникальный идентификатор(первичный ключ) |
| ID_M | Целый | INTEGER | Код фильма из поля ID таблицы MOVIE |
| CL_ID | Целый | INTEGER | Код клиента из поля ID_C таблицы CLIENT |
| DEN | Вещественный | NUMERIC | Цена с учетом скидки |
| D_D | Дата | DATE | Дата составления. По этому полю нужно создать индекс для сортировки. |
| VZVR | Символьный | CHAR 1 | Код возврата. По умолчанию ‘N’ |
Таблица Log
| WHEN | Дата | TIMESTAMP | Дата редактирования(текущая дата) |
| USER | Строковый | VARCHAR(20) | Пользователь |
| ACTION | Строковый | CHAR(3) | Действие, выполняемое пользователем |
Приложение-клиент разрабатывается при помощи программных средств Borland Delphi, используя набор компонентов Interbase Express (IBX). Эти компоненты используют функции Intebase API, т.е. обращаются к серверу непосредственно. VCL-библиотека классов среды проектирования Delphi предоставляет ряд классов, позволяющих быстро и эффективно разрабатывать различные приложения баз данных.