Разработка базы данных в Microsoft Office Access для aвтомaтизaции процессa контроля прокaтa видеофильмов

Введение

 

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

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

СУБД позволяет структурировать, системaтизировaть и оргaнизовaть дaнные для их компьютерного хранения и обработки. Сегодня невозможно представить себе деятельность любого современного предприятия или оргaнизaции без использовaния профессионaльных СУБД. Несомненно, они состaвляют фундaмент информaционной деятельности во всех сферах – нaчинaя с производствa и зaкaнчивaя финaнсaми и телекоммуникациями

Целью данной курсовой работы разработка базы данных в Microsoft Office Access для aвтомaтизaции процессa контроля прокaтa видеофильмов.

 

1 Анализ и уточнение требований к СУБД

 

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

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

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

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

 

Задачами автоматизированной системы являются:

- добавление клиента

- удаление клиента

- добавление сотрудника

- удаление сотрудника

- поиск и выдача дисков клиентам

- возврат диска клиентом

- пополнение коллекции дисков

- списание дисков

- заказ дисков клиентами

- удаление заказа

- подготовка списка всех дисков имеющихся в видеотеке

- подготовка сведений о каждом клиенте

- подготовка сведений о клиентах, у которых имеются на руках диски

- подготовка списка дисков на доставку в видеотеку

- структура хранения данных

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

- все строки таблицы не зависимы друг от друга;

- нет повторяющихся строк;

- все строки имеют одинаковую длинную и структуру.

Так же можно сказать о достоинствах этой модели:

- полная независимость данных;

- простота и доступность.

Есть несколько недостатков:

- не всегда предметная область может быть представлена в виде "таблиц";

- в результате логического проектирования появляется множество "таблиц". Это приводит к трудности понимания структуры данных.

2 Инфологическое проектирование базы данных

 

На этапе инфологического проектирования базы данных строится инфологическая модель предметной области, которая должна отражать семантику (смысл взаимосвязи объектов) предметной области. ИЛМ строится не для отдельного объекта, а отображает классы объектов и связи между ними. Диаграмма, отражающая связи объектов предметной области, называется диаграммой ER-типа (так как Entity – сущность, Relationship – связь).

Выделим основные сущности:

- сущность  «Диски»

- сущность  «Клиенты»

- сущность  «Сотрудники»

- сущность  «Прокат»

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Рис.1. Инфологическая модель предметной области «Видеотека»

 

Сущность «Диски» содержит информацию  всех дисках, имеющимся в видеотеке. Отдельный экземпляр этой сущности содержит информацию только  об одном диске. Сущность «Прокат» содержит  информацию о конкретном диске, о том кто его взял, когда, когда вернет диск, какой сотрудник отдал его. Между сущностью «Диски» и сущностью «Прокат» существует связь типа «1:М». которая означает, что любой диск который находиться в прокате является обязательным по отношению к сущности «Диски» (если диск в прокате, то есть полная информация об этом диске). Сущность «Клиенты» содержит информацию о клиентах. Отдельный экземпляр этой сущности содержит информацию об одном клиенте. Существует связь между сущностью «Клиенты» и сущностью «Прокат» типа «1:М», обязательная со стороны сущности «Клиенты» (каждому экземпляру сущности «Прокат» обязательно соответствует клиент и причем только один). Сущность «Сотрудники» содержит информацию о всех сотрудниках работающих в видеотеке. Один экзэмпляр этой сущности содержит информацию только об одном сотруднике. Между сущностями «Сотрудники» и «Прокат» существует связь типа «1:М», которая означает что каждому экземпляру сущности «Прокат» обязательно соответствует сотрудник, оформивший данный прокат. Сущность «Заказ» содержит информацию о всех заказах поступивших от клиентов. Один экзэмпляр этой сущности содержит информацию только об одном заказе т.е. об одном заказанном диске. Между сущностями «Заказ» и «Клиенты» существует связь типа «М:1», которая означает что каждому экземпляру сущности «Заказ» обязательно соответствует клиент, сделавший данный заказ.

 Определим  ключи – уникальные идентификаторы  экземпляров каждой сущности: для  сущности «Диски» - это шифр диска (Шифр), для сущности «Прокат» - шифр  проката (Ш_проката), для сущности «Клиенты» - номер паспорта (№ паспорта), для сущности «Сотрудники» - номер сотрудника         (№ сотр), для сущности «Заказ» - шифр заказа (Ш_заказа).

 

3 Даталогическое проектирование базы данных

 

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

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

В результате получили следующие отношения:

R1 «Диски» ( Шифр, Название, Режиссер, Жанр, Актеры, Страна, Прод-ть(мин), Картинка, Занят)

R2 «Клиенты» ( № паспорта, ФИО кл, Город, Улица, Дом, Квартира, Телефон)

R3 «Прокат» (Ш_проката, № паспорта, Дата выдачи, Дата возврата, № сотр)

R4 «Сотрудники» (№ сотр, № паспорта, ФИО, Город, Улица, Дом, Квартира, Телефон)

R5 «Заказ» (Ш_заказа, № паспорта, Название, Режиссер, Жанр, Актеры, Год выпуска)

 

 

 

4 Нормализация отношений

 

Данные отношения уже находятся в 3 НФ.

 

Отношение «Диски»

Шифр

Название

Режиссер

Жанр

Актеры

Страна

Прод-ть(мин)

Картинка

Занят

 

Отношение «Клиенты»

№ паспорта

ФИО кл

Город

Улица

Дом

Квартира

Телефон

 

Отношение «Прокат»

Ш_проката

№ паспорта клиент.

Дата выдачи

Дата возврата

№ сотр

 

 

Отношение «Сотрудники»

№ сотр

№ паспорта

ФИО

Город

Улица

Дом

Квартира

Телефон

 

 

 

 

Отношение «Заказ»

Ш_заказа

№ паспорта

Название

Режиссер

Жанр

Актеры

Год выпуска

Рис.2.Фукционольные зависимости между атрибутами

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Рис 3. Даталогическая модель базы данных «Видеотека»

 

5 Структура данных

 

Описание структуры:

Таблица 1, диски:

Имя поля	Тип	Длина
Шифр	Текстовый	10
Режиссер	Текстовый	25
Название	Текстовый	50
Актеры	Текстовый	120
Страна	Текстовый	25
Прод-ть(мин)	Числовой	Целое
Жанр	Текстовый	20
Картинка	Поле объекта
Занят	Логический

 

Таблица 2, клиенты:

Имя поля	Тип	Длина
№ паспорта	Числовой	25
ФИО клиента	Текстовый	20
Город	Текстовый	20
Улица	Текстовый	20
Дом	Числовой	5
Квартира	Числовой	5
Телефон	Числовой	15

 

Таблица 3, прокат:

Имя поля	Тип	Длина
Ш_проката	Счетчик	Длинное целое
Дата выдачи	Дата/время
Дата возврата	Дата/время
Шифр	Текстовый	10
№ паспорта	Числовой	Действительно
№ сотр	Числовой	Целое

 

 

Таблица 4, сотрудники:

Имя поля	Тип	Длина
№ сотр	Числовой	Целое
№ паспорта	Числовой	Действительно
ФИО	Текстовый	25
Город	Текстовый	20
Улица	Текстовый	20
Дом	Числовой	5
Квартира	Числовой	5
Телефон	Текстовый	15

 

Таблица 5, заказ:

Имя поля	Тип	Длина
№ паспорта	Числовой	Действительно
Название	Текстовый	50
Режиссер	Текстовый	25
Жанр	Текстовый	20
Актеры	Текстовый	50
Год выпуска	Дата/время