База данных налоговой инспекции
Для автоматизации учета работы налоговой службы <...> области необходима следующая информация: об отделениях налоговой инспекции (номер отделения, тип (городская, районная, областная), название (<...> область, г. <...>, <...> район, ...), год начала функционирования, телефон, адрес, сотрудники (ФИО, дата рождения, должность, оклад, образование (высшее, среднетехническое, среднее, среднее специальное))) и о предприятиях, выплачивающих налоги (название предприятия, форма собственности (государственное, частное, ЗАО, ОАО, ООО,…), телефон, год начала работы, количество сотрудников, платежи налоговой службе (вид платежа (налог на добавленную стоимость, налог с прибыли, штраф за неуплату налогов,…), дата, сумма, кто оформлял (сотрудник инспекции))).
- Спроектировать концептуальную модель базы данных (БД) для заданной предметной области и представить ее в виде взаимосвязанных таблиц, находящихся в третьей нормальной форме (в случае денормализации БД – обосновать необходимость). Выделить базовые таблицы и таблицы-справочники, указать для них первичные и внешние ключи.
- Создать базу данных в среде СУБД средствами языка SQL. Добавить таблицы, домены, индексы.
- Разработать не менее шести триггеров (по одному для каждого типа события), как минимум для двух различных таблиц БД. Триггеры типа BEFORE INSERT должны быть созданы для всех таблиц и с использованием генераторов задавать значение первичного ключа для вновь добавляемой записи.
- Заполнить таблицы БД с использованием соответствующих запросов на языке SQL (не менее десяти записей в каждом справочнике, не менее 10 000 - 50 000 псевдослучайных записей в таблицах).
- Сформулировать следующие виды запросов:
- симметричное внутреннее соединение с условием (два запроса с условием отбора по внешнему ключу, два – по датам);
- симметричное внутреннее соединение без условия (три запроса);
- левое внешнее соединение;
- правое внешнее соединение;
- запрос на запросе по принципу левого соединения;
- итоговый запрос без условия;
- итоговый запрос без условия c итоговыми данными вида: «всего», «в том числе»;
- итоговые запросы с условием на данные (по значению, по маске, с использованием индекса, без использования индекса);
- итоговый запрос с условием на группы;
- итоговый запрос с условием на данные и на группы;
- запрос на запросе по принципу итогового запроса;
- запрос с использованием объединения
- запросы с подзапросами (с использованием in, not in, case, операциями над итоговыми данными).
- Запросы без параметров реализовать в виде представлений, остальные запросы – в виде хранимых процедур и/или функций. Создать, по меньшей мере, одно модифицируемое представление, используя механизм триггеров. ВСЯ логика проектируемого ПО – на сервере.
- Разработать клиентское приложение, которое предоставляет следующие возможности для работы с созданной базой данных:
- многопользовательский режим работы (одна программа для всех ролей – ситуативный доступ к интерфейсу)
- наличие нескольких ролей пользователя (администратор – добавление/удаление/редактирование пользователей, их прав/ролей; пользователи_1 – …, пользователи _2 – ...)
- просмотр содержимого таблиц и представлений (здесь и далее – с учетом прав пользователей);
- добавление, редактирование и удаление записей таблиц и модифицируемых представлений;
- работа с наборами данных, находящимися в отношении «один-ко-многим» (создать составную форму для просмотра и редактирования данных родительской и дочерней таблиц);
- поиск и фильтрация данных отображаемых таблиц;
- просмотр результатов выполнения запросов;
- визуализация результатов одного из итоговых запросов (диаграммы, экспорт в Excell).
- Обеспечить защиту данных, информации от несанкционированного доступа
В системе существует 3 роли пользователей: простой пользователь, оператор и администратор.
Простому пользователю доступно только локализированное (таблицы, каждая строка которых закреплена за одним из отделений — Сотрудники, Платежи — позволяют работать только с теми записями, которые относятся к тому же отделению, что и пользователь. Например: сотрудник отделения А видит только сотрудников из отделения А и платежи, которые были оформлены в отделении А. В то же время он не может получить доступ к сотрудникам или платежам отделения Б) чтение таблиц и добавление записей в таблицу Платежи.
Оператор также имеет локализированный доступ к таблицам, но уже может выполнять все CRUD-операции во всех таблицах, за исключением некоторых ограничений: в таблице Платежи разрешены лишь операции чтения и добавления; в таблицах Отделения и Аккаунты разрешено только чтение. В дополнение к этим правам оператор также может выполнять некоторые запросы.
Администратор имеет все права на все таблицы в базе данных, может выполнять все запросы и управлять пользователями.
