Задание на курсовую работу

Состоит из 5 заданий, связанных единой предметной областью (мини-проектом) и отчета. Лучше всего задания выполнять последовательно.

 1. Разработка требований

  • Выбрать предметную область для проекта. См. список вариантов.
    Выберите наиболее интересную область, не обязательно из списка. Лучше всего, если она будет интересна лично вам, и среди ваших знакомых будет эксперт, который сможет играть роль заказчика. Можно взять предметную область из курсовой работы курса по БД, это позволит сэкономить время на проектирование БД.
  • Разработать концепцию (Vision) проектируемой системы (документ на от половины страницы до двух страниц максимум).
    Лучше всего это сделать со слов знакомого-заказчика, либо согласовать с ним
  • Составить словарь специальных терминов предметной области (не обязательно)
    Чтобы любой разработчик, прочитав словарь, мог говорить с командой на одном языке
  • Нарисовать UML диаграммы сценариев использования (Use Cases) для всех ролей системы.
    Детализация сценариев хотя бы части системы, должна доходить до уровня конкретных пунктов меню, кнопок и форм
  • Детализировать требования:
    • Activity-диаграммы (для описания бизнес-процессов)
    • Диаграммы состояний объектов предметной области
    • другой способ описания или визуализации


    Материалы и примеры диаграмм см. в 1.1 Сбор и анализ требований

 2. Проектирование ER-схемы

  • Спроектировать схему БД в виде логической и физической модели в ER Case-средстве (например, er-win)
    • Таблицы и связи. Количество таблиц не регламентируется, но все сценарии (use case) из п.1 должны быть реализуемы на схеме.
    • Первичные ключи должны быть суррогатными - состоять из одного поля типа INTEGER, значения для которого генерируются из последовательности (sequence). Возможны обоснованные исключения.
    • Типы данных на логической и физической моделях должны соответствовать требованиям. По-умолчанию Er-Win используется CHAR(14) что почти всегда неверно.
    • Альтернативные ключи должны присутствовать там, где по смыслу одна или более колонок должны быть уникальными
  • Сгенерировать скрипт из ER-модели и накатить его в свою схему в Oracle.
  • При помощи команд SQL Insert или SQL Developer заполнить схему тестовыми данными (по 3-5 или более строк в каждую таблицу).

3. Разработка процедур на PL/SQL

Разработать одну или несколько процедур/функций или триггеров на процедурном языке СУБД (PL/SQL), реализующих один или часть сценария (use case) из задания №1.

Процедура должна:

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

 

Примеры возможных процедур:

  1. Выполнения массивных вставок или обновлений в БД, например заполнение свободными местами новых рейсов самолетов.
  2. Триггеры, ведущие аудит (историю изменений) данных. При insert/update/delete в основные таблицы, триггер может вставлять копию данных в дополнительную таблицу.
  3. Создания отчета по-расписанию. Данные отчета (результаты вычислений) записываются в отдельную таблицу.
  4. Реализация сценария, требующего вставки/обновления в несколько таблиц.

Материалы и примеры процедур

 4. Клиент №1 - консольное приложение

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

  1. Подсоединяется к базе данных
  2. Выполняет SQL-запрос, выводит на консоль результаты
  3. Выполняет SQL команды INSERT, UPDATE, DELETE, проверяя SELECT-ом после каждой операции, что состояние таблицы изменилось
  4. Вызывает хранимую процедуру, разработанную в задании №3, проверяет SELECT-ом результат работы процедуры

В приложении должны быть

  • Обработка исключений БД, правильное закрытие всех ресурсов (соединения, курсоров итп)
  • Параметры SQL-операторов должны идти отдельно от SQL запроса (Prepared statement, для правильного экранирования и производительности)
  • Технологию/платформу выбрать по своему усмотрению, например, Java JDBC, ADO.NET, Python, Ruby, ...

 5. Клиент №2 - приложение с графическим пользовательским интерфейсом

Разработать приложение с графическим пользовательским интерфейсом, которое реализует один или более сценариев из задания #1.

Можно выбрать технологию или платформу по своему усмотрению, например

Платформы клиента №1 и №2 должны быть различными

Минимальные требования

  • Отображение данных из одной таблицы
  • Диалоги добавления/редактирования/удаления строк таблицы
  • Валидация данных с выводом понятных пользователю сообщений на экран

Желательно (на оценку выше "3")

  • Полностью (на оценку "5") реализовывать минимально необходимое кол-во сценариев для одной роли в системе.
  • Обеспечивать целостность данных при параллельной работе нескольких клиентов (оптимистическая, или пессимистическая блокировки)
  • Иметь защиту от SQL Injection
  • Клиент должен работать достаточно быстро при увеличении объема данных в базе (использовать фильтрацию и постраничный вывод, не извлекая все содержимое таблиц в память).

Если для вашей предметной области или схемы неприменимы какие-то критерии, то они определяются индивидуально преподавателем.

6. Отчет

В отчет вносятся все артефакты заданий №1 - №5:

  • Концепция системы, диаграммы
  • ER-схема (логическая, физическая)
  • Текст хранимой процедуры и протокол ее выполнения
  • Текст программы клиента №1 (только смысловая часть, написанная вами) и скриншоты/протокол результата выполнения
  • Скриншоты клиента №2

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

Требования по оформлению отчета - только наличие стандартного титульного листа.

 

  • Нет меток