Дополнительные услуги:

• Код доп. услуги – int NOT NULL PK

• Справка – varchar(20) NOT NULL

• Помощь в сдаче экзамена – varchar(20) NOT NULL

Группа:

• Код группы – int NOT NULL PK

• Код курса – int NOT NULL FK

• Код доп. услуги – int NOT NULL FK

• Код сотрудника – int NOT NULL FK

Клиенты:

• Код клиента – int NOT NULL PK

• ФИО – varchar(50) NOT NULL

• Телефон – int NOT NULL

• Паспортные данные – varchar(10) NOT NULL

• Номер группы – int NOT NULL FK

Продажи:

• Код продажи – int NOT NULL PK

• Дата продажи – date NOT NULL FK

• Код клиента – int NOT NULL FK

• Количество – int NOT NULL

• Код сотрудника – int NOT NULL FK

• Код доп. Услуги – int NOT NULL FK

Исходя из приведённых выше отношений, построим схему получившейся БД (Рисунок 6).

Рис. 6. Даталогическая модель базы данных

2.4 Нормализация

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

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

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

Первая нормальная форма

-Устранение повторяющихся групп в отдельных таблицах.

-Создание отдельной таблицы для каждого набора связанных данных.

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

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

Вторая нормальная форма

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

-Связать эти таблицы с помощью внешнего ключа.

Записи могут зависеть только от первичного ключа таблицы (составного ключа, если необходимо). Возьмем для примера адрес клиента в системе бухгалтерского учета. Этот адрес необходим не только таблице Customers, но и таблицам Orders, Shipping, Invoices, Accounts Receivable и Collections. Вместо того чтобы хранить адрес клиента как отдельный элемент в каждой из этих таблиц, храните его в одном месте: или в таблице Customers, или в отдельной таблице Addresses.

Третья нормальная форма

- Устранение полей, не зависящих от ключа.

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

Разрабатываемая база данных удовлетворяет данным требованиям.

Выводы

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

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

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

Глава 3. Программная реализация бд автошколы «арго»

В главе рассматривается третий этап разработки базы данных, который включает в себя:

• Выбор СУБД

• Реализация базы данных в выбранной СУБД

• Разработка форм, отчетов, представлений

• Реализация ограничений

3.1 Анализ и выбор субд

Oracle Application Express (сокращённо именуется как Oracle Apex, APEX, ранее называлась Oracle HTMLDB) — свободная среда быстрой разработки прикладного программного обеспечения на основе СУБД Oracle Database, целиком реализованная как веб-приложение. Все элементы, возникающие в цикле разработки приложения в данной среде хранятся непосредственно в инфраструктуре Oracle Database, тем самым обеспечивается совместная работа разработчиков и контроль версий без использования файлов и дополнительных систем управления версиями.

Oracle Application Express (Apex) - это инструмент ускоренной разработки Web приложений для базы данных Oracle. С Apex можно создавать профессиональные приложения, даже с небольшим опытом программирования, с использованием только Web-браузера. [12, с. 22-23]

Ускоренная разработка обеспечивается за счет встроенных в Apex средств:

• темы пользовательского интерфейса;

• управление навигацией;

• управление формами;

• гибкие отчеты;

3.2. Физическое проектирование бд

Создадим приложение в APEX Application Builder, и разработаем меню для нашего приложения.

Рис. 7. Создание приложения в Oracle APEX

После того как создали приложение, используя даталогическую модель создадим следующие таблицы в Oracle Application Express:

• Avtomobili

• Kurs

• Gruppa

• Dop uslugi

• Klienti

• Sotrudniki

• Prodazhi

Для того чтобы создать таблицу нажимаем на кнопку Create и выбираем TABLE, после чего откроется окно Сreate Table, где заполняем Сolumn Name и выбираем тип этих полей.

Рис. 8. Пример создания таблицы

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

Рис. 9. Создание внешних ключей

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

Рис. 10. Таблица Avtomobili

Рис. 11. Таблица Kusr

Рис. 12. Таблица Klienti

Рис. 13. Таблица Sotrudniki

Рис. 14. Таблица Prodazhi

3.3 Разработка представлений

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

Первое представление показывает информацию о курсах от 35000 и дешевле.

Рис. 15. Создание представления о курсах от 35000 и дешевле.

Далее создадим второе представление, где покажем количество продаж курса .

Рис. 16. Создание представления о группах сотрудника Лавр.

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

Рис. 17. Создание представления о клиентах, которые воспользовались дополнительными услугами.

Так же сделаем представление и клиентах, которые посещают 3 группу.

Рис. 18. Создания представления о клиентах, которые посещают 3 группу.

3.4 Разработка форм

После того как создали приложение в APEX Application Builder, разработаем меню для нашего приложения и добавим страницы.

Рис. 19. Интерфейс разрабатываемого приложения

Также создали формы для ввода данных, как показано на рисунке ниже.

Рис. 20. Формы для ввода данных

3.5 Разработка отчетов

Создадим отчеты, используя ранее созданные представления.

Рис. 21. Отчет по курсам, которые стоят 35000 и дешевле.

Рис. 22. Отчет по группам сотрудника Лавр

Рис. 23. Отчет о клиентах, которые ходят в группу 3.

3.6. Безопасность и контроль

Средства безопасности в Oracle можно разделить на две категории:

·Безопасность доступа.

·Безопасность данных.

Безопасность доступа

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

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

Безопасность данных

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

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