Курсовая работа: Создание базы данных для организации

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

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

Страницы: 1, 2, 3, 4, 5, 6, 7, 8