- •Введение
- •Глава 1. Системный анализ предметной области асу «автошкола»
- •1.1. Анализ объекта автоматизации ооо «арго»
- •Информационная модель
- •1.2. Обзор информационных технологий, подходящих для разработки бд
- •1.4. Требования к разрабатываемой базе данных
- •2.1. Разработка инфологической модели бд
- •2.2. Обоснование выбора модели данных
- •Сетевая модель
- •Иерархическая модель
- •Объектно-ориентированная модель
- •Реляционная модель
- •2.3. Даталогическое проектирование бд
- •2.4 Нормализация
- •Первая нормальная форма
- •Вторая нормальная форма
- •Третья нормальная форма
- •Глава 3. Программная реализация бд автошколы «арго»
- •3.1 Анализ и выбор субд
- •3.2. Физическое проектирование бд
- •3.3 Разработка представлений
- •3.4 Разработка форм
- •3.5 Разработка отчетов
- •3.6. Безопасность и контроль
- •Список источников и литературы
3.4 Разработка форм
После того как создали приложение в APEX Application Builder, разработаем меню для нашего приложения и добавим страницы.
Рис. 19. Интерфейс разрабатываемого приложения
Также создали формы для ввода данных, как показано на рисунке ниже.
Рис. 20. Формы для ввода данных
3.5 Разработка отчетов
Создадим отчеты, используя ранее созданные представления.
Рис. 21. Отчет по курсам, которые стоят 35000 и дешевле.
Рис. 22. Отчет по группам сотрудника Лавр
Рис. 23. Отчет о клиентах, которые ходят в группу 3.
3.6. Безопасность и контроль
Средства безопасности в Oracle можно разделить на две категории:
·Безопасность доступа.
·Безопасность данных.
Безопасность доступа
В Oracle имеется целый ряд механизмов для идентификации и верификации пользователей. Самый простой из них – обязательное указание пользователем своих имени и пароля при каждом подключении. Эта верификация должна выполняться независимо от того, какое внешнее интерфейсное средство используется для доступа к базе данных. Идея состоит в том, чтобы допустить пользователей к работе со средствами базы данных только после того, как он установит санкционированное соединение с ней. Имя пользователя и пароль сверяются с указанными в таблице SYS.USERS, куда пароль заносится в зашифрованной форме.
В большинстве приложений баз данных существуют разные категории пользователей, которые работают с разными частями системы и имеют разные права на просмотр и изменение данных. В простом случае может быть всего два класса пользователей: те, кто вводит данные, и менеджеры, выполняющие запросы к данным. Но в большинстве случаев существует несколько категорий пользователей, и функциональные возможности, к которым они должны иметь доступ, пересекаются. В таких ситуациях можно избежать дублирования работы, создав одно приложение с меню или панелью инструментов, вид и содержимое которой зависят от задач конкретного пользователя.
Безопасность данных
Если подключаться к базе данных могут лишь уполномоченные пользователи, и они могут запускать только те модули, на выполнение которых им явно предоставлено право, то нужно подумать о следующем уровне безопасности – ограничении доступа этих пользователей к данным.
Для добавления пользователя в базу данных администратор базы данных создает учетную запись с именем пользователя и паролем. Каждому пользователю присваивается профиль — характеристика предельных объемов системных ресурсов, которые могут быть выделены данному пользователю. Сюда входит лимит совокупного процессорного времени, предоставляемого в течение одного сеанса или за один вызов Oracle, и другие подобные ограничения.
В Oracle имеются системные и объектные привилегии. Системные привилегии — это права на выполнение общих задач, таких как SELECT ANY TABLE и UPDATE ANY TABLE. Объектные привилегии относятся к действиям с определенными элементами базы данных — таблицами, представлениями и последовательностями. Для предоставления привилегий другому пользователю можно использовать оператор GRANT.
У нас в приложение Oracle Apex реализована авторизация пользователей с помощью Authorization Schemes. Было создано несколько схем авторизации. Первое, что нам нужно сделать - это понять, какие уровни авторизации нужно будет реализовать в нашем приложении, потому что это определит не только роли, которые мы создаем в общем компоненте контроля доступа к приложениям, но также будет определять, какие схемы авторизации мы определяем и могут применяться к различным компонентам APEX.
Мы будем использовать 2 разных уровня авторизации:
· 1- Руководитель
· 2 - Инструктор
У администратора будет доступ ко всему. У инструктора есть доступ ко всем страницам кроме страниц Сотрудники.
Для этого создали таблицу Users c ролями как показано на рис.25.
Рис. 24. Таблица Users
Сами по себе роли контроля доступа, по сути, ничего не делают, но предоставляют возможность связать пользователя с ролью. Это связанные схемы авторизации, которые обеспечивают логику, которая позволяет нам связать роль с данным компонентом в APEX. Далее создаются схемы авторизации.
Для каждого пользователя используется свои привилегии пользования над базой данных.
Рис. 25. Привилегии для ADMIN
Рис. 26. Привилегии для INSTRUCTOR
Выводы
С помощью базы данных Oracle была произведена физическая реализация проекта. Разработана политика безопасности и определены соответствующие ограничения. В СУБД Oracle, посредством APEX, был реализован привычный для работы user interface.
ЗАКЛЮЧЕНИЕ
Курсовая работа посвящена разработке базы данных автошколы «АРГО». Для выполнения курсовой работы использовались разработки инфологической и даталогической модели БД совместно с системным анализом предметной области. Также была произведена программная реализация базы данных и приложения в Oracle Application Express.