Разработка базы данных для справочной службы театров города

Исходя из выше приведенных данных, были установлены связи между сущностями:

«Театр» - «Спектакль». Спектакли проходят в театре. В одном театре проходит много спектаклей, но при этом один спектакль может проходить в нескольких театрах. Исходя из этого получается связь «много ко многим».

«Театр» - «Билеты». Один театр продает много билетов. Связь «один ко многим»

«Худ. Состав» - «Спектакль». Один актер (Худ. Состав) может участвовать в одном спектакле. Но при этом в спектакле может быть задействовано много актеров. Исходя из этого получается связь «Один ко Многим».

«Спектакль» - «Сеанс». Во время одного сеанса может проходить много спектаклей. Связь «Один ко многим».

Чтобы исключить связь «Многие ко Многим» в БД была введена дополнительная сущность «ДС» связывающая таблицы «Театр», «Спектакль», «Худ. Состав». И обеспечивая связь   «Один ко Многим».

 

Рисунок 1 – ER модель

 

2. Выбор средства проектирования

Для реализации данной базы данных был использован Microsoft Office Access 2007. Выполненная в данной среде БД отвечает всем  заданным требованием заказчика.

Требования к составу и параметрам технических средств.

• компьютер и процессор: частота не меньше 500 МГц
• RAM: не менее 256 МБ
• HDD: 1,5 ГБ. Часть места на диске будет освобождена после установки при удалении с него исходного загрузочного пакета.
• устройство чтения дисков: дисковод для компакт-дисков или DVD-дисков
• экран:  разрешение не менее 1024x768 точек
• ОС: Microsoft Windows XP с пакетом обновления 2 (SP2), Windows Server 2003 с пакетом обновления 2 (SP2) или более поздняя версия
• клавиатура , «мышь»;

Требования к программной документации;

Состав программной документации должен включать в себя:

• техническое задание;
• руководство оператора.

Надежное (устойчивое) функционирование программы должно быть обеспечено выполнением Заказчиком совокупности организационно-технических мероприятий, перечень которых приведен ниже:

• организацией бесперебойного питания технических средств;
• использованием лицензионного программного обеспечения;
• регулярным выполнением рекомендаций Министерства труда и социального развития российской федерации, изложенных в Постановлении от 23 июля 1998 года «Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств»;
• регулярным выполнением требований ГОСТ 51188-98. Защита информации. Испытания программных средств на наличие компьютерных вирусов

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

 

 

3. Разработка физической модели

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

Физическая модель содержит всю информацию, необходимую для реализации конкретной БД. Различают два уровня физической модели:

– трансформационную модель;

– модель СУБД.

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

Таблица №1 «Театр»

Название поля	Тип данных	Размер поля
#ID_Театра	Счетчик	Длинное целое
Название театра	Текстовый	100
Адрес	Текстовый	100
Вместимость	Числовой	Длинное целое
Худ Рук	Текстовый	50
Деятельность ВП	Логический	Вкл/Выкл

 

Таблица №2 «Спектакль»

Название поля	Тип данных	Размер поля
#ID_Спектакля	Счетчик	Длинное целое
Название	Текстовый	100
Жанр	Текстовый (мастер подстановок)	100
Год постановки	Дата/Время	Краткий формат даты
Театр	Числовой	Длинное целое
Труппа	Числовой	Длинное целое
Спектакль ВП	Логический	Вкл/Выкл

 

Таблица №3 «Худ. Состав»

Название поля	Тип данных	Размер поля
#ID_Артиста	Счетчик	Длинное целое
Название труппы	Текстовый	100
Фамилия	Текстовый	30
Имя	Текстовый	30
Должность	Текстовый (мастер подстановок)	30
Код спектакля	Числовой	Длинное целое
Код театра	Числовой	Длинное целое

 

Таблица №4 «Билеты»

Название поля	Тип данных	Размер поля
#ID_Билета	Счетчик	Длинное целое
Цена билета	Денежный	Денежный
Код Театра	Числовой	Длинное целое
Код Спектакля	Числовой	Длинное целое

 

Таблица №5 «Сеансы»

Название поля	Тип данных	Размер поля
#ID_Сеанса	Счетчик	Длинное целое
Спектакль	Числовой	Длинное целое
Дата Сеанса	Дата/Время	Длинный формат даты
Время Сеанса	Дата/Время	Краткий формат времени
Сцена/Площадка	Текстовый	20

 

Таблица №6 «ДС»

Название поля	Тип данных	Размер поля
Код	Счетчик	Длинное целое
Код Театра	Числовой	Длинное целое
Код Спектакля	Числовой	Длинное целое
Код Артиста	Числовой	Длинное целое

 

Физическая модель данных представлена на рисунке 2.

 

 

Рисунок 2 – физическая модель базы данных

Образец таблицы представлен на рисунке 3.

Рисунок 3 – Таблица «Спектакли»

 

4. Формы

Форма — это объект базы данных, который можно использовать для создания интерфейса пользователя для приложения базы данных. "Привязанная" форма напрямую соединена с источником данных, например к таблице или запросу, и может использоваться для ввода, изменения или отображения данных из источника данных. Как вариант, можно создать "свободную" форму, которая не связана напрямую с источником данных, но которая все равно может содержать кнопки, надписи и другие элементы управления, необходимые для работы приложения.

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

В данном курсовом проекте были созданы формы с помощью мастера так и с помощью конструктора.

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

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

Рисунок 4 – форма «Театры»

 

Формы созданные в режиме «мастер форм» представлены на рисунке 5. данный вид форм не предусматривает возможность изменения, в основном формы построенные по такому принципу созданы по таблицам полностью отвечающим требованиям разработчика.

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

 

 

Рисунок 5 – форма «Работник».

 

5. Запросы

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

Запросы на выборку и перекрестные запросы используются для извлечения и представления данных, а также для передачи данных в формы и отчеты. При выполнении запроса на выборку или перекрестного запроса в программе Microsoft Office Access 2007 результаты запроса отображаются в режиме таблицы.

Ниже представлены несколько запросов в виде SQL-формы.

 

Запрос №1 «Репертуар театра по его названию»

SELECT Театры.[Название театра], Спектакли.Название

FROM Театры INNER JOIN (Спектакли INNER JOIN ДС ON Спектакли.ID_Спектакль = ДС.Код_спектакля) ON Театры.ID_Театра = ДС.Код_театра

GROUP BY Театры.[Название театра], Спектакли.Название

HAVING (((Театры.[Название театра])=[Введите  название театра]))

ORDER BY Спектакли.Название DESC;

 

Запрос №2 «Получение о составе и жанре спектакля , по его названию»

SELECT Спектакли.Название, Спектакли.Жанр, [Худ состав].Фамилия, [Худ состав].Имя, [Худ состав].Длжность

FROM [Худ  состав] INNER JOIN (Спектакли INNER JOIN ДС ON Спектакли.ID_Спектакль = ДС.Код_спектакля) ON [Худ состав].ID_артиста = ДС.Код_артиста

WHERE (((Спектакли.Название)=[Введите  название спектакля]));

 

6. Отчеты

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