Проектирование базы данных для видеотеки

ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЮНОЕ УЧРЕЖДЕНИЕ 
МОСКОВСКАЯ АКАДЕМИЯ РЫНКА ТРУДА И ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

 

 

 

 

Курсовой проект по дисциплине:

Базы данных

Тема:

Проектирование базы данных для видеотеки

 

 

 

Выполнил:

Студент 3-го курса,

Факультета:

Прикладная информатика (в экономике)

Вальтер Александр

Преподаватель:

Обухов Александр Александрович

 

 

Москва 2012 год

 

СОДЕРЖАНИЕ

 

 

 

1. ВВЕДЕНИЕ

 

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

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

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

В данном курсовом проекте была разработана база данных в MS Microsoft SQL Server 2005 для автоматизации процесса контроля проката видеофильмов.

 

 

2. ОБСЛЕДОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

 

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

При разработке базы данных «Видеотека» было проведено обследование предметной области. В результате в БД «Видеотека» используются следующие входные данные:

• информация о клиентах;
• информация о сотрудниках;
• информация о дисках;

Выходными данными являются выходные формы, запросы.

 

 

3. ПРОЕКТИРОВАНИЕ БД

 

3.1. Инфологическое проектирование БД

 

Цель инфологического моделирования – обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Поэтому инфологическую модель данных пытаются строить по аналогии с естественным языком, который не может быть использован в чистом виде из-за сложности компьютерной обработки текстов и неоднозначности любого естественного языка. Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и их свойства (атрибуты).

Сущность  – любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолёты, рейсы, вкус, цвет и т.д. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе.

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

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

Связь – ассоциирование двух или более сущностей. Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой. Однако одно из основных требований к организации базы данных – это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определенные связи. А так как в реальных базах данных нередко содержатся сотни или даже тысячи сущностей, то теоретически между ними может быть установлено более миллиона связей. Наличие такого множества связей и определяет сложность инфологических моделей.

В базе данных определены следующие отношения между таблицами один ко многим:

 

Таблица «Прокат»		Таблица «Клиенты»
Код		код
Тип отношений:		один ко многим
Таблица «Прокат»		Таблица «Сотрудники»
Код		код
Тип отношений:		один ко многим
Таблица «Прокат»		Таблица «Диски»
Код		код
Тип отношений:		один ко многим

 

 

Инфологическая модель данных представлена в Приложении 7.1. рис. 2.

 

 

3.2. Реляционная модель БД

 

Реляционная модель данных была предложена Е. Коддом, известным американским специалистом в области баз данных. Эта модель позволила решить одну из важнейших задач в управлении базами данных – обеспечить независимость представления и описания данных от прикладных программ.

В структурной части модели фиксируется, что единственной структурой данных, используемой в реляционных БД, является нормализованное n-аурное отношение. В манипуляционной части модели утверждаются два фундаментальных механизма манипулирования реляционными БД - реляционная алгебра и реляционное исчисление. Первый механизм базируется в основном на классической теории множеств (с некоторыми уточнениями), a второй - на классическом логическом аппарате исчисления предикатов первого порядка.

 

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

В разработанной базе данных «Видеотека» существуют следующие функциональные зависимости между атрибутами:

 

Таблица 4.1.1 Диски

Наименование атрибутов	Функциональные зависимости
Код Записи Название фильма   Год выпуск Цена

 

 

Таблица 4.1.2 Клиенты

Наименование атрибутов	Функциональные зависимости
Личный номер Фамилия   Дата рождения   Номер пaспортa

 

Таблица 4.1.3 Прокат

Наименование атрибутов	Функциональные зависимости
Код записи Название фильма   Дата выдачи   Личный номер   Фамилия   №Сотрудникa Фaмилия сотрудникa

 

Таблица 4.1.4 Сотрудники

Наименование атрибутов	Функциональные зависимости
№ Сотрудника Фамилия   №Паспорта

 

 

3.2.3. Выбор ключей

 

Использование ключей и индексов позволяет:

1. однозначно идентифицировать записи;
2. избегать дублирования значений в ключевых полях;
3. выполнять сортировку таблиц;
4. ускорять операции поиска в таблицах;
5. устанавливать связи между отдельными таблицами БД.

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

 

Таблица 4.2.1 Ключи

Таблица	Ключ	Тип ключа
Прокат	Код Записи	primary
Диски	Код Записи	regular
Клиенты	Личный номер	regular
Сотрудники	№ Сотрудника	regular

 

 

 

 

 

 

 

 

 

 

 

 

 

 

3.3. Нормализация БД

 

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

 

3.3.1. Перечень сущностей

 

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

«Диски» - содержит информацию о дисках.

«Клиенты» - содержит информацию о клиентах.

«Сотрудники» - содержит информацию о сотрудниках.

 

3.3.2. Перечень атрибутов

 

Таблица «Диски» содержит:

1. Код записи – уникальный код
2. Название фильма - название фильма
3. Год выпуска – год выпуска фильма
4. Цена- цена проката

Таблица «Клиенты» содержит:

1. Личный номер – уникальный код
2. Фамилия- Фамилия клиента
3. Дата рождения – дата рождения
4. Номер паспорта – номер паспорта

Таблица «Сотрудники» содержит:

1. № Сотрудника – уникальный код
2. Фамилия – фамилия сотрудника
3. № Паспорта – номер паспорта

Таблица «Прокат» содержит:

1. Код Записи – уникальный код ;
2. Название фильма - название фильма
3. Дата выдачи – Дата выдачи фильма;
4. Личный номер – личный номер клиента;
5. Фамилия – фамилия клиента

6.  № Сотрудника – номер сотрудника

7.  Фамилия сотрудника – фамилия сотрудника

 

4. РЕАЛИЗАЦИЯ БД

 

4.1. Реализация объектов БД

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

 

Состав таблиц БД

4.1.1. Таблица диски

 

Наименование атрибутов	Тип полей	Размер полей	Допустимость неопределенных значений
Код Записи	Char	10	Not null
Название фильма	Char	20
Дата образования	Date time
Цена	money	3