Диаграмма последовательности

Рис.13 Диаграмма последовательности

1. Клиент запрашивает интересующую его информацию о билетах и спектаклях у кассира;

2. Кассир обращается за получением информации, интересующую клиента, в базу данных по всем билетам и проходящим спектаклям;

3. База данных выдает запрашиваемую информацию кассиру;

4. Кассир передает информацию полученную от базы данных клиенту;

5. Поучив необходимую информацию от кассира, клиент принимает решение покупать билет;

6. Поучив необходимую информацию от кассира, клиент принимает решение не покупать билет;

7. Решив совершить покупку клиент производит процедуру прямой покупки обратившись к кассиру;

Кассир проводит в базе данных процедуру прямой покупки билета клиентом;

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

8. Решив совершить покупку клиент производит процедуру бронирования билета обратившись к кассиру;

Кассир проводит в базе данных процедуру бронирования билета клиентом;

После внесения информации о бронирование в базу данных происходит оплата билета через кассу, в удобное для клиента время;

9. Происходит оплата билета при прямой покупке, либо при выкупе брони, через кассу, касса выдает чек о произведении оплаты;

10. После оплаты стоимости билета, кассир выдает клиенту купленный им билет.

Диаграмма кооперации

Рис. 14 Диаграмма кооперации

1. Клиент запрашивает интересующую его информацию о билетах и спектаклях у кассира;

2. Кассир обращается за получением информации, интересующую клиента, в базу данных по всем билетам и проходящим спектаклям;

3. База данных выдает запрашиваемую информацию кассиру;

4. Кассир передает информацию полученную от базы данных клиенту;

5. Поучив необходимую информацию от кассира, клиент принимает решение покупать билет;

6. Поучив необходимую информацию от кассира, клиент принимает решение не покупать билет;

7. Решив совершить покупку клиент производит процедуру прямой покупки обратившись к кассиру;

Кассир проводит в базе данных процедуру прямой покупки билета клиентом;

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

8. Решив совершить покупку клиент производит процедуру бронирования билета обратившись к кассиру;

Кассир проводит в базе данных процедуру бронирования билета клиентом;

После внесения информации о бронирование в базу данных происходит оплата билета через кассу, в удобное для клиента время;

9. Происходит оплата билета при прямой покупке, либо при выкупе брони, через кассу, касса выдает чек о произведении оплаты;

10. После оплаты стоимости билета, кассир выдает клиенту купленный им билет.

 

Диаграмма компонентов

 

 

Рис. 15 Диаграмма компонентов

Данная диаграмма включает в себя 7 компонентов.

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

Компонент Справка – связан с компонентом Головной модуль, служит для выдачи необходимой справки клиенту.

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

Компонент БД билетов – содержит в себе всю информацию о билетах театров города.

Компонент БД театров - содержит в себе всю информацию о театрах города.

Компонент БД спектаклей - содержит в себе всю информацию о спектаклях в театрах города.

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

 

Диаграмма размещений

Рис. 16Диаграмма размещений

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

ПРОЕКТИРОВАНИЕ ДАННЫХ

Логическое моделирование

 

 

 

Таблица описания связей

Таблица 1.1.

Название связи	Обозначение связи	Главный объект	Связанный объект	Вид связи	Условые связи	Способ реализации	Примечание
Работают	R1	СОТРУДНИКИ	ТЕАТР	M:1		По коду сотрудника
Содержаться	R2	ТЕАТР	СОТРУДНИКИ	1:М		По коду сотрудника
Включается	R3	ТЕАТР	ВИД	М:1		По коду вида
Включает	R4	ВИД	ТЕАТР	1:М		По коду вида
Проводит	R5	ТЕАТР	СПЕКТАКЛЬ	1:M		По коду спектакля
Проводится	R6	СПЕКТАКЛЬ	ТЕАТР	M:1		По коду спектакля
Включает	R7	ЖАНР	СПЕКТАКЛЬ	1:M		По коду жанра
Включается	R8	СПЕКТАКЛЬ	ЖАНР	M:1		По коду жанра
Продают	R9	СПЕКТАКЛЬ	БИЛЕТЫ	1:М		По коду спектакля
Продаются	R10	БИЛЕТЫ	СПЕКТАКЛЬ	М:1		По коду спектакля
Формирует	R11	БИЛЕТЫ	АФИША	1:М		По коду спектакля
Рекламирует	R12	АФИША	БИЛЕТЫ	М:1		По коду спектакля

 

Отношения приведены в табл. 1.2 – 1.8. В столбце "Динамичность" будем помечать буквой D изменяемые атрибуты (динамические), S - неизменяемые (статические). "Количество повторений" означает, сколько раз повторяется множественный атрибут. В столбце "Область возможных значений" указывается тип (C - символы, D - дата, N – число, L – логическое значение) и, возможно, диапазон изменения атрибута.

Описание атрибутов объекта ТЕАТР

Таблица 1.2

Название атрибута	Обозначение атрибута	Динамичность	Количество повторений	Область возможных значений	Примечание
Код театра	Id_teatr	S	-	N	суррогатный первичный ключ
Код вида театра	Id_vid	S		N	внешний ключ к ВИД
Код сотрудника театра	Id_sotrud	S		N	внешний ключ к СОТРУДНИК
Название театра	Nazvanie_teatr	D		C	обязательное поле
Директор театр	Director	D		C	обязательное поле
Адрес театра	Adres_teatr	S		C	обязательное поле
Телефон	Telefon_teatr	D		N	обязательное поле
Кол-во мест в партере	Kolvo_parptep	D		N	обязательное поле
Кол-во мест в амфитеатре	Kolvo_amf	D		N	обязательное поле
Кол-во мест на балконе	Kolvo_balk	D		N	обязательное поле

 

Описание атрибутов объекта СОТРУДНИК

Таблица 1.3.

Название атрибута	Обозначение атрибута	Динамичность	Количество повторений	Область возможных значений	Примечание
Код сотрудник	Id_sotrud	S	-	N	первичный ключ
Фамилия	Family	D		C	обязательное поле
Имя	Name	D		C	обязательное поле
Отчество	Otchestvo	D		C	обязательное поле
Должность	Dolzhnost	D		C	обязательное поле

 

 

Описание атрибутов объекта ВИД

Таблица 1.4.

Название атрибута	Обозначение атрибута	Динамичность	Количество повторений	Область возможных значений	Примечание
Код вида театра	Id_vid	S	-	N	первичный ключ
Название	Vid	S		C	обязательное поле
Описание	Opis_vid	S		C	обязательное поле

 

Описание атрибутов объекта СПЕКТАКЛЬ

Таблица 1.5.

Название атрибута	Обозначение атрибута	Динамичность	Количество повторений	Область возможных значений	Примечание
Код спектакля	Id_spektakl	S	-	N	суррогатный первичный ключ
Код театра	Id_teatr	S		N	внешний ключ к ТЕАТР
Код жанра	Id_zhanr	S		N	внешний ключ к ЖАНР
Название спектакля	Nazvanie_spektakl	D		C	обязательное поле
Ведущие актеры	Akter	D		C	обязательное поле
Постановщик	Postanovschik	D		C	обязательное поле
Премьерный	Premera	D		L	обязательное поле
Продолжительность	Time	D		N	обязательное поле
Дата начала	Data_start	D		D	обязательное поле
Дата окончания	Data_end	D		D	обязательное поле

 

 

Описание атрибутов объекта ЖАНР

Таблица 1.6.

Название атрибута	Обозначение атрибута	Динамичность	Количество повторений	Область возможных значений	Примечание
Код жанра	Id_ zhanr	S	-	N	первичный ключ
Название	zhanr	S		C	обязательное поле
Описание	Opis_zhanr	S		C	обязательное поле

 

Описание атрибутов объекта БИЛЕТ

Таблица 1.7.

Название атрибута	Обозначение атрибута	Динамичность	Количество повторений	Область возможных значений	Примечание
Код билета	Id_ bilet	S	-	N	первичный ключ
Код спктакля	Id_spectacl	S		N	Внешний ключ к СПЕКТАКЛЬ
Код афиши	Id_afisha	S		N	Внешний ключ к АФИША
Дата	Data	D		D	обязательное поле
Место	Mesto	D		N	обязательное поле
Цена	Cena	D		N	обязательное поле
Продан	Prodan	D		L	обязательное поле
Бронь	Bron	D		L	обязательное поле

 

 

Описание атрибутов объекта АФИША

Таблица 1.8.

Название атрибута	Обозначение атрибута	Динамичность	Количество повторений	Область возможных значений	Примечание
Код спектакля	Id_ spektakl	S	-	N	первичный ключ
Код театр	Id_teatr	S		N	обязательное поле
Дата	Data	D		D	обязательное поле

 

 

Физическое моделирование

Рис 17. ER-диаграмма

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

На рисунке 17 представлена ER-диаграмма системы театральной билетной кассы. Основными понятиями ER-диаграммы являются сущность, связь и атрибут. Сущность - это реальный или представляемый объект, информация о котором должна сохраняться и быть доступна. В диаграммах ER-модели сущность представляется в виде прямоугольника, содержащего имя сущности. Каждая сущность должна иметь наименование, выраженное существительным в единственном числе. В нашей диаграмме сущностями являются: театр, спектакль, билет, афиша, жанр, сотрудник, вид. Причем вид и жанр играют в системе роль справочника. Это сделано для того, чтобы не загромождать и без этого большие таблицы «театр» и «спектакль».

Для большей выразительности и лучшего понимания, имя сущности может сопровождаться примерами конкретных объектов этого типа. Например, сущность театры: Драматический, Современник, Оперы и балета, Юного зрителя.

Каждый экземпляр сущности должен быть отличим от любого другого экземпляра той же сущности.

Атрибут сущности - это именованная характеристика, являющаяся некоторым свойством сущности. Например сущность «Билет» содержит следующие атрибуты: место, цена, дата продажи, продан (логическое да или нет), бронь(логическое да или нет).

Сущность «Театр» содержит другие атрибуты: название, адрес, директор, телефон, количество мест в партере, количество мест в амфитеатре, количество мест на балконе, вид театра.

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

К примеру, у сущности «Театр» ключом является idТеатра, сущность «Спектакль» имеет ключ idСпектакля, сущности «Билет» и «Жанр»- idБилет и idЖанр, и т.д..

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

Связь типа один-к-одному означает, что один экземпляр первой сущности связан с одним экземпляром второй сущности. Связь один-к-одному чаще всего свидетельствует о том, что на самом деле мы имеем всего одну сущность, неправильно разделенную на две. В нашей ER-диаграмме данный тип связи отсутствует.

Связь типа один-ко-многим означает, что один экземпляр первой сущности связан с несколькими экземплярами второй сущности. Это наиболее часто используемый тип связи. В ER-диаграмме театральной билетной кассы все связи между сущностями относятся именно к этому тип.

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

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