Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
is_lr_APEX.docx
Скачиваний:
84
Добавлен:
15.05.2015
Размер:
1.86 Mб
Скачать

Лабораторная работа № 9. Самостоятельное создание приложения для выбранной предметной области

Задание к работе:

  1. В соответствии с вариантом (см. приложение), выданным преподавателем, проанализировать информационные потребности для соответствующей предметной области (ПрО) и построить инфологическую модель ПрО в виде сущностей, их атрибутов и связей между ними. Для изображения информационной модели использовать нотацию ER-диаграмм.

  2. Создать для ПрО таблицы БД, необходимые для реализации информационных потребностей.

  3. Создать веб-приложение по актуализации данных ПрО.

Алгоритм решения задач и дополнительные требования

  1. На основе информационных потребностей (исходных данных) ПрО проектируется инфологическая модель ПрО. Для этого выделяется несколько (минимум три) основных взаимосвязанных сущностей, каждая из которых должна содержать:

  • атрибуты – основные характеристики-свойства сущности с указанием домена (типа данных) и обязательности значений на основе анализа возможных значений. Например, для сущности СТУДЕНТ существует атрибут ФИО_студента.

  • ключ (первичный) – уникальный идентификатор сущности, состоящий из существующих атрибутов сущности или одного искусственно добавленного атрибута id. Например, для сущности СТУДЕНТ первичным ключом является атрибут номер_зачетки.

  • ключи (внешние) – связи с другими сущностями, представляющими собой атрибут(ы) текущей сущности, содержащий(-е) значение из идентификатора связанной другой сущности. Например, для сущности СТУДЕНТ внешним ключом является атрибут номер_группы, который связывает эту сущность с сущностью ГРУППА по атрибуту номер_группы.

  1. На основе инфологической модели создается БД, позволяющая связно хранить требуемые сведения об указанных объектах и фактах:

    1. Таблицы БД должны удовлетворять 3НФ.

    2. Каждая таблица должна иметь название, отражающее смысл содержащихся в ней данных и соответствующее следующему шаблону: <фамилия в транслитерации>_<смысловое название таблицы>. Название таблицы не должно превышать 30 символов.

    3. Для каждого столбца таблицы в соответствии с потребностями должны быть определены название (в транслитерации, не более 30 символов), тип, размер, обязательность.

    4. В каждой таблице должен быть определен первичный ключ (Primary Key).

    5. Названия объектов-последовательностей (Sequence), создаваемых для генерации значений первичного ключа, должны удовлетворять следующему шаблону: <фамилия в транслитерации>_<смысловое название таблицы>_SEQ и не должны превышать 30 символов.

    6. Если первичный ключ определен на суррогатном столбце (значения которого генерируются автоматически, например, с помощью объекта-последовательности Sequence), то в таблице должен быть дополнительно определен уникальный ключ (Unique).

    7. Для столбцов-ссылок должны быть определены ограничения ссылочной целостности – внешние ключи (Foreign Key).

  2. Создаётся приложение, основанное на созданных таблицах:

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

  • просмотр и поиск записей во всех созданных таблицах;

  • редактирование (создание, изменение, удаление) записей во всех созданных таблицах;

  • редактирование полей-ссылок с помощью списков выбора;

  • отображение практически полезных в выбранной ПрО отчетов;

  • навигацию по страницам при помощи цепочек ссылок (breadcrumbs);

  • навигацию между ключевыми страницами при помощи вкладок (tabs);

  • русскоязычный интерфейс пользователя (заголовки страниц, областей, столбцов отчетов, кнопок, вкладок и т.п. должны быть русскоязычными);

  • тему интерфейса и логотип, соответствующие тематике ПрО.

  • Приложение должно включать в себя:

    • главную страницу, содержащую ссылки на ключевые страницы (которые в свою очередь содержат ссылки на дополнительные страницы форм и отчетов);

    • хотя бы одну табличную форму;

    • хотя бы один параметризованный отчет;

    • кнопки-флажки (check boxes);

  • Взаимосвязи между страницами приложения должны быть реализованы с помощью ссылок (link), переходов (branch), перенаправлений (redirect), организующих страницы приложения в единую, логически непротиворечивую многоуровневую структуру. Например, с главной страницы можно перейти к ключевым страницам отчетов, а с ключевых страниц можно перейти на страницы форм редактирования и дополнительных отчетов. При этом для каждой страницы неявные обратные переходы и перенаправления (которые не выбирает сам пользователь) осуществляются именно на те страницы, с которых был произведен переход на данную страницу (если это не противоречит логике).

  • Тестируется работа созданного приложения.

  • Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]