Разработка базы данных и автоматизированной информационной системы (АИС) для театра



Министерство образования и науки Российской Федерации

Филиал федерального государственного бюджетного образовательного учреждения высшего образования

"Мурманский арктический государственный университет"

(филиал МАГУ в г. Кировске)

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

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

Задачи курсового проектирования:

  • изучение предметной области разрабатываемой базы данных;
  • определение функциональных требований и разработка спецификаций к автоматизированной системе;
  • проектирование пользовательского интерфейса;
  • закрепление основных принципов построения концептуальной, логической и физической модели данных;
  • организация целостности данных;
  • построение схемы базы данных в инструментальной CASE-среде MySQL Wokbench;
  • создание объектов базы данных в СУБД MySQL;
  • использование средств заполнения базы данных;
  • создание хранимых процедур и триггеров на базах данных, запросов к базе данных;
  • разработка автоматизированной системы на базе данных;
  • осуществление доступа к данным и управление привилегиями пользователей;

В качестве индивидуального задания на курсовое проектирование была поручена разработка базы данных и автоматизированной информационной системы (АИС) для театра.

1 ОБЩАЯ ЧАСТЬ

1.1 Характеристика области применения АИС

Театр  (греч. θέατρον - основное значение - место для зрелищ, затем - зрелище, от θεάομαι - смотрю, вижу) – форма исполнительского искусства.

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

Профессия актера относится к одной из самых древних – так же, как и основное место работы актера – театр. История театра насчитывает более двух с половиной тысяч лет. С момента появления этой профессии театр пережил массу витков творческого развития. Фактически каждая культура и нация на земле имела и имеет собственные театральные традиции, приемы и способы актерской игры. С момента появления радио, телевидения и кино профессия актера приобрела особую значимость и популярность и остается такой по сегодняшний день. [2]

Директор театра – руководитель театра в соответствии с действующим законодательством и уставом театра.

Директор театра:

1.2 Постановка проблемы

При анализе предметной области были определены проблемы.

Проблема №1: Трудность организации заключения контрактов с актерами на определенную сумму.

Затрагивает: директора, администратора.

Ее следствием является: Увеличение количества документов связанных с заключением контрактов с актерами на определенную сумму.

Успешное решение: Оптимальная организация процесса заключения контрактов с актерами на определенную сумму.

Проблема №2: Высокая трудоёмкость подсчета суммы размера всех наград для каждого актера

Затрагивает: директора.

Ее следствием является: Увеличение количества наград выдаваемых актеру за определенные роли, соответственно и увеличение суммы размера всех наград для каждого актера.

Успешное решение: Автоматизация процесса подсчета суммы размеры всех наград для каждого актера.

Проблема №3: Трудность организации напоминания актерам о премьерах спектаклях в которых они участвуют и контрактах, которые они заключили на участие в этих премьерах.

Затрагивает: администратора.

Ее следствием является: Увеличение количества актеров участвующих в премьерах спектаклях и заключающих на участие в этих премьерах.

Успешное решение: Автоматизация процесса напоминания актерам о премьерах спектаклях в которых они участвуют.

Проблема №4: Недоступность связи с администратором.

Затрагивает: актера, директора.

Ее следствием является: Отсутствие возможности связаться с администратором, потому что его адрес электронной почты неизвестен тому, кто хочет написать ему письмо.

Успешное решение: Реализация функции связи с администратором.

Проблема №5: Трудность получения и поиска информации о конкретных спектаклях и ролях, которые связаны с этими спектаклями.

Затрагивает: актера, администратора, директора.

Ее следствием является: Увеличение количества информации, связанной с конкретными спектаклями и ролями, которые связаны с этими спектаклями.

Успешное решение: Автоматизация процесса получения и поиска информации нужной информации.

1.3 Определение пользователей и их потребностей

У разрабатываемой АИС можно выделить три основных пользователя: актер, администратор и директор театра. Актер — это лицо которое проверяет информацию, связанную конкретно с ним на корректность и правильность ее, а потом редактирует ее, директор это тот, кто проверяет информацию, размещенную на сайте на корректность, правильность, точность и достоверность, а администратор — это лицо которое занимается администрированием (то есть редактированием, удалением и добавлением) размещенной информацией на сайте.

Таблица 1 – Профили пользователей

Типичный представитель

Описание

Тип

Ответственности

Критерий успеха

Актер

Пользователь системы, наделенный правами на просмотр, поиск и редактирование информации связанной конкретно с ним

Пользователь

Проверка корректности и достоверности личной информации, редактирование этой информации если она является не корректной

Возможность редактирования, просмотра и поиска личной информации, связь с администратором если информация, представленная в системе, является некорректной

Продолжение таблицы 1 – Профили пользователей

Типичный представитель

Описание

Тип

Ответственности

Критерий успеха

Директор

Пользователь системы, наделенный правами на просмотр и проверку информации в системе

Пользователь

Проверка достоверности всей информации связанной с театральной деятельностью и представленной на сайте

Возможность просмотра и поиска информации, связь с администратором если информация, представленная в системе, является некорректной

Администратор

Пользователь системы, наделенный правами на администрирование, просмотр и поиск всей информации в системе, а также на рассылку важных сообщений

Пользователь

Администрирование информации размещенной в системе (редактирование, удаление, обновление), просмотр и поиск информации в системе, рассылка важных сообщений

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

Решение: Директору необходимо оперативно проверять информацию, представленную в документах, связанных с театральной деятельностью, заключает контракты с актерами на определенную роль в определенном спектакле (контрактов может быть много), а актеру нужна информация о всех спектаклях, в которых он играет определенные роли (спектаклей и ролей может быть также много как и контрактов). Требуется внедрение АИС, которая бы ускорила и оптимизировала вышеуказанные процессы.

1.4 Назначение и цели создания АИС

1.4.1 Цели создания АИС

Автоматизированная информационная система создается с целью обеспечения эффективного управления автоматизацией учета занятости актеров театра.

1.4.2 Назначение АИС

АИС УЗАТ предназначена для:

1.4.3 Задачи, решаемые АИС

АИС УЗАТ позволяет решать следующие задачи:

1.4.4 Область применения АИС

АИС УЗАТ используется:

1.5 Выбор архитектурных решений

1.5.1 Архитектурная модель АИС

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

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

В компьютерных технологиях трёхуровневая архитектура, синоним трёхзвенная архитектура (по англ.three-tier илиMultitierarchitecture) предполагает наличие следующих компонентов приложения: клиентское приложение (обычно говорят "тонкий клиент" или терминал), подключенное к серверу приложений, который в свою очередь подключен к серверу базы данных.

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

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

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

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

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

По сравнению с клиент-серверной или файл-серверной архитектурой можно выделить следующие достоинства трёхуровневой архитектуры:

Недостатки вытекают из достоинств. По сравнениюc клиент-серверной или файл-серверной архитектурой можно выделить следующие недостатки трёхуровневой архитектуры:

Для проектирования АИС УЗАТ была выбрана трехуровневая архитектура, так как она – надежная, безопасная и масштабируемая, а также она лучше всего демонстрирует структуру АИС УЗАТ. На рисунке 1 продемонстрирована модель архитектуры разрабатываемой АИС УЗАТ.

Рисунок 1 – Модель архитектуры разрабатываемой АИС

1.5.2 Модель базы данных

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

Виды моделей баз данных:

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

В сетевой модели данных у родительского элемента может быть несколько потомков, а у дочернего элемента — несколько предков. Записи в такой модели связаны списками с указателями. IDMS («Интегрированная система управления данными») от компании Computer Associates international Inc. — пример сетевой СУБД.

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

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

В отличие от двух других типов СУБД, в реляционных моделях данных нет необходимости просматривать все указатели, что облегчает выполнение запросов на выборку информации по сравнению с сетевыми и иерархическими СУБД. Это одна из основных причин, почему реляционная модель оказалась более удобна. Распространённые реляционные СУБД: Oracle, Sybase, DB2, Ingres, Informix и MS-SQL Server. [6]




Похожие работы, которые могут быть Вам интерестны.

1. Разработка автоматизированной информационной системы сети Детских Клубов «Юла» на основе базы данных MySQL

2. Разработка и создание автоматизированной информационной системы отдела по делам молодежи и спорта

3. Проектирование автоматизированной информационной системы Учёт торговых точек» для мерии г.Череповца

4. Разработка базы данных поликлиники

5. ПРОГРАММНЫЙ КОМПЛЕКС VIRTUA В КАЧЕСТВЕ АВТОМАТИЗИРОВАННОЙ БИБЛИОТЕЧНО-ИНФОРМАЦИОННОЙ СИСТЕМЫ УНИВЕРСИТЕТСКОЙ БИБЛИОТЕКИ

6. Разработка базы данных Кондитерские изделия

7. Разработка базы данных для учета стоимости междугородних телефонных переговоров

8. РАЗРАБОТКА БАЗЫ ДАННЫХ ДЛЯ УЧЕТА СТОИМОСТИ МЕЖДУГОРОДНИХ ТЕЛЕФОННЫХ ПЕРЕГОВОРОВ

9. Разработка базі данных оптовой базы для повышения качества обслуживания клиентов

10. Разработка автоматизированной системы Учет компьютерной техники и оргтехники