Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Курсовой БД Сергеева.doc
Скачиваний:
12
Добавлен:
30.05.2015
Размер:
3.78 Mб
Скачать

4.3Нормализация отношений.

Схема, приведенная в разделе 3.1., отвечает 1НФ т.к. данные представлены в виде двумерных таблиц с выделенными ключевыми атрибутами.

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

Схема отвечает 3НФ, т.к. она отвечает всем требованиям 2НФ и ни один из не ключевых атрибутов не зависит от других не ключевых атрибутов.

5.Даталогическое проектирование

    1. Состав таблиц бд

База данных содержит восемь таблиц: «Значения», «Показатели», «Формы», «Пользователи», «Организации», «Тип значения», «Тип периода» и «Единица измерения».

Рисунок 5.1 Структура таблицы «Значения»

Рисунок 5.2 Структура таблицы «Показатели»

Рисунок 5.3Структура таблицы «Формы»

Рисунок 5.4 Структура таблицы «Пользователи»

Рисунок 5.5 Структура таблицы «Организация»

Рисунок 5.6 Структура таблицы «тип значения»

Рисунок 5.7 Структура таблицы «Значения»

Рисунок 5.8 Структура таблицы «Единица измерения»

    1. Средства поддержания целостности

Связи таблиц базы данных представлены на схеме 5.1 данных ниже.

Схема 5.1 Связи таблиц базы данных

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

    1. Запросы к базе данных

В базе данных реализовано десять запросов (см. рисунке 6.1).

Рисунок 6.1 Запросы

Примерами простого запроса являются запросы «наименование организации».

Рисунок 6.2 Простой запрос в режиме конструктора

Рисунок 6.3 Простой запрос в режиме SQL

Примерами запросов с условием являются запросы «поиск пользователя на первую букву фамилии», «Поиск по дате создания», «Поиск пользователей по какой-либо организации».

Рисунок 6.4 Запрос c условием в режиме конструктора

Рисунок 6.5 Запрос с условием в режиме SQL

Примером запроса из связанных таблиц является запрос «оперативный план на 2 квартал».

Рисунок 6.6 Запрос из связанных таблиц в режиме конструктора

Рисунок 6.7 Запрос из связанных таблиц в режиме SQL

Примером запроса с использованием оператора соединения является запрос «сцепление ФИО».

Рисунок 6.8 Запрос с оператором сцепления в режиме конструктора

Рисунок 6.9 Запрос с оператором сцепления в режиме SQL

Остальные запросы формируются таким же образом.

  1. Разработка механизмов защиты от несанкционированного доступа

Работать с базой данных будут четыре группы: одни будут вводить информацию («Operator1»), а трое других — только просматривать («Operator2», «Operator3» и «Operator4»).

«Operator1» - Экономисты УК;

«Operator2» - Сотрудники ДООО;

«Operator3» - Руководство УК;

«Operator4» - Плановый отдел УК.

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

Рисунок 7.1 Разрешение Operator 1 на доступ к базе данных

Рисунок 7.2 Разрешение Operator 1 на доступ к таблицам

Рисунок 7.3 Разрешение Operator 1 на доступ к запросам

Рисунок 7.4 Разрешение Operator 1 на доступ к формам

Рисунок 7.5 Разрешение Operator 2 на доступ к базе данных

Рисунок 7.6 Разрешение Operator 2 на доступ к таблицам

Рисунок 7.7 Разрешение Operator 2 на доступ к запросам

Рисунок 7.8 Разрешение Operator 2 на доступ к отчетам

Рисунок 7.9 Разрешение Operator 3 на доступ к базе данных

Рисунок 7.10 Разрешение Operator 3 на доступ к таблицам

Рисунок 7.11 Разрешение Operator 3 на доступ к запросам

Рисунок 7.12 Разрешение Operator 3 на доступ к отчетам

Рисунок 7.13 Разрешение Operator 4 на доступ к базе данных

Рисунок 7.14 Разрешение Operator 4 на доступ к таблицам

Рисунок 7.15 Разрешение Operator 1 на доступ к запросам

Рисунок 7.16 Разрешение Operator 4 на доступ к формам

Рисунок 7.17 Разрешение Operator 4 на доступ к отчетам