Sidebar






Old

staff:courses:no_sql_introduction:course_work

ИДЗ - состав, порядок работы

Порядок выполнения

Для того, чтобы минимизировать риски неудачного создания пояснительной записки/приложения в последний момент, предлагается следующая последовательность шагов:

Как работать в репозиториях

Все требования по работе в репо перечислены в описаниях заданий ниже. Создавать специально для меня PR НЕ НУЖНО. Ждать моей проверки на ваших PR - бессмысленно:(

Как сдавать задания

  • Команда внимательно читает требования ниже, убеждается, что их результат соответствует описанию.
  • Один участник команды (кого команда уполномочила сдавать это задание) пишет письмо преподвателю с темой “[NoSQL] Название_задания - номер_И_название_проекта”.
  • Остальные участники указываются в копии письма.
  • Переписка по одному заданию остается в рамках одной цепочки писем.
  • Если вам необходимо указать на объект в репозитории, предоставьте полную ссылку на него (такую, которая откроется по нажатию в браузере).
  • Если вы отправляете скринкаст - присылайте ссылку на него (прикладывать к письму не нужно).

Желательно, чтобы все участники команды сдали примерно одинаковое количество заданий ИДЗ ( == этапов, описанных ниже).

Что такое массовый импорт-экспорт

В каждой из ИДЗ необходимо реализовать функциональность массового импорта-экспорта. Что она подразумевает: - возможность импорта экспорта всех данных из системы в машино-читаемом формате (json, xml, csv …. на ваш выбор) - пользовательские интерфейсы для импорта и экспорта

Зачем это нужно: - потренироваться в создании простого модуля бакапа - посмотреть, какие возможности предоставляет ваша СУБД для работы с дампами БД

Согласована и сформулирована тема курсовой

  1. Выбрать тему и согласовать ее с преподавателем. Вам нужно письмом:
    1. Предложить свое виденье того, как будет устроено приложение.
    2. Озвучить используемые инструменты (язык программирования и БД), либо посоветоваться с преподавателем.
    3. Получить (и проверить) доступ в репозиторий

Установка и настройка выбранной БД + ЯП

Смысл данного задания - сделать минимально работоспособный пример (скрипт для командной строки) работы “выбранной БД + ЯП” на выбранном вами языке программирования, продемонстрировать его работоспособность в виде скринкаста и залить в репо. Для того, чтобы исключить на поздних этапах проекта проблемы совместимости.

Скрипт может быть быть просто HelloWorld - не связанным с ИДЗ.

  1. Результат:
    1. На вашем компьютере можно создать и запустить пример (см выше) для выбранной вами пары “Язык программирование” - БД. Приложение должно подключится к БД, записать и прочитать данные из нее.
    2. Работа приложения из пункта выше демонстрируется в виде скринкаста (скринкаст == короткая запись видео с вашего экрана). Не заливайте его в репо (можно с гугл / яндекс диска)
    3. Код приложения выше загружен в репозиторий.
    4. Делать для этого PR не нужно.
    5. Docker на данном этапе не нужен.

Use case

Презентация про то, как составлять макет и писать сценарии использования (+типичные ошибки)

Результат (размещен на вики):

  1. У вас есть формулировки основных сценариев использования приложения (текст) и макета его пользовательского интерфейса (большое изображение), размещенные на вики вашего репозитория.
  2. Макет изображен в виде графа (https://hsto.org/files/026/cab/55a/026cab55a5ad4a1daab209c39715b947.png).
  3. Каждый экран на макете имеет или уникальное осмысленное название или номер, по которому его можно идентифицировать.
  4. Все надписи и элементы на макете различимы и читаемы.
  5. Макет включает в себя элементы управления для массового импорта/экспорта данных.
  6. Вы знаете какие из сценариев использования вы сможете продемонстрировать в рамках прототипа.

На что стоит обратить внимание при составлении макета (типовые ошибки):

  • Если у вас в макете фигурирует какая-то сущность (пользователь, поставщик), у нее обязательно должна быть
    • страница для просмотра одного элемента (страница пользователя, поставщика …),
      • если элемент подразумевает редакитрование, то надо на этой же странице добавить даты создания и редактирования элемента,
      • почти всегда будет в кассу дополнять такую страницу полем “Комментарий”, где пользователи смогут хранить произвольную информацию, которая не укладывается в модель (но это не приглашение использовать это поле в качестве мусорки),
    • страница поиска элементов по нескольким полям.
  • Если логика вашего приложения подразумевает какие-либо процессы (например - трекинг задач у программистов, почтовые отправления, заказы в Интернет-магазине) или хотя бы переменные статусы (например - у сотрудника могут быть статусы Уволен, Уволился сам, В отпуске, Работает, Сокращен, ), то важно в макете предсмотреть просмотр и поиск по истории изменения состояний статуса с привязкой ко времени.
  • Как правило, в большинстве проектов нужны интерфейсы поиска сразу по нескольким сущностям (коллекциям) - например, все курьеры, на которых есть Н незакрытых заказов,

Модель данных

  1. Подготовить раздел “Модель данных”. Результат (на вики):
    1. У вас готова схема БД (вы можете подробно ответить на вопросы: что и в каких коллекциях находиться, какие связи между коллекциями/объектами используются и т.д.)
    2. Готов список сущностей модели
    3. У вас готова графическое представление схемы БД + требования из раздела 4, описанного ниже:
      1. Нереляционная модель данных (для вашей СУБД)
        1. Графическое представление
        2. Описание назначений коллекций, типов данных и сущностей
        3. Оценка удельного объема информации, хранимой в модели (сколько потребуется памяти, чтобы сохранить объекты, как объем зависит от количества объектов)
        4. Избыточность модели (отношение между фактическим объемом модели и “чистым” объемом данных).
        5. Направление роста модели при увеличении количества объектов каждой сущности.
        6. Запросы к модели, с помощью которых реализуются сценарии использования
          1. Текст запросов
          2. Количество запросов для совершения юзкейсов в зависимости от числа объектов в БД и прочих параметров
          3. Количество задействованных коллекций (если есть)
      2. Аналог модели данных для SQL СУБД - характеризуется аналогично нереляционной (см. подпункты выше)
      3. Сравнение моделей
        1. Удельный объем информации (сколько потребуется памяти, чтобы сохранить объекты, как объем зависит от количества объектов) - где данные занимают больший объем при прочих равных (http://se.moevm.info/doku.php/staff:courses:no_sql_introduction:calculating_data_model_size)
        2. Запросы по отдельным юзкейсам:
          1. Количество запросов для совершения юзкейсов в зависимости от числа объектов в БД и прочих параметров
          2. Количество задействованных коллекций (если есть)
        3. Вывод - что лучше, SQL или NoSQL модель
    4. Есть примеры хранения данных в БД.
    5. Все результаты выше лежат в репозитории.

Прототип*

  1. Подготовить прототипы приложения (“Хранение и представление” и “Анализ”). Результат:
    1. Приложение компилируется и реализует оговоренные сценарии использования через пользовательский интерфейс.
    2. Исходники и исполняемые файлы собранного приложения лежат в репозитории, там поставлен тег 0.5 (0.8)

Про пользовательский интерфейс, роли и пользователей:

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

Что подразумевает прототип “Хранение и представление” -

  1. приложение запускается,
  2. позволяет просматривать содержимое БД с помощью таблиц / списков
  3. выполняет одну из следующих функций: или позволяет добавление новых элементов данных в БД, или предоставляет интерфейсы для поиска (фильтрации) данных,
  4. если в приложении есть авторизация, то в нем должны по умолчанию присутствовать по одному отладочному пользователю на каждую роль, сами пользователи и их данные указаны в README
  5. вы можете продемонстрировать выполнение всех пунктов выше скринкастом (или демкой на занятии)

Что подразумевает прототип “Анализ” - выполненны требования “Хранение и представление”

  1. приложение разворачивается через docker-compose build –no-cache из репозитория на ubuntu 20.04+,
  2. сервер вашей СУБД добавлен docker-compose.yml (==вы не используете БД извне ваших контейнеров),
  3. добавлена недостающая часть (либо добавление элементов, либо поиск),
  4. добавлен импорт и экспорт всех данных приложения в машиночитаемом формате (XML, JSON, CSV ….),

App is ready

  1. Продемонстрировать работоспособность всех сценариев использования на окончательной версии приложения.
    1. Приложение компилируется и реализует все сценарии использования.
    2. В приложении есть представление данных в виде таблицы с serverside пагинацией.
    3. В приложение добавлено вычисление и отображение статистики / анализа данных / необходимых вычислений согласно заданию.
    4. Вы можете продемонстрировать это через docker-compose + дистанционно / с помощью скринкаста.
    5. Исходники и исполняемые файлы собранного приложения лежат в репозитории, там поставлен тег 1.0.

Пояснительная записка.

  1. Предоставить пояснительную записку в электронном виде. Результат:
    1. Ваша пояснительная записка полностью соответствует требованиям к оформлению (http://eltech.ru/assets/files/3004_3_ShABLON-kursovika.doc)и содержанию ( описание)
    2. Записка выложена в репозиторий в редактируемом формате и pdf.

Пример хорошей записки https://github.com/moevm/nosql-2017-lib_card/blob/master/%D0%9F%D0%BE%D1%8F%D1%81%D0%BD%D0%B8%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F%20%D0%B7%D0%B0%D0%BF%D0%B8%D1%81%D0%BA%D0%B0.pdf

Состав и оформление пояснительной записки

Для оформления вам пригодятся следующие ссылки:

Разделы ИДЗ:

  1. Введение
    1. Актуальность решаемой проблемы
    2. Постановка задачи
    3. Предлагаемое решение
  2. Качественные требования к решению
    1. Текущие
    2. [по желанию]Перспективные:
      1. при росте популярности решения
      2. при росте нагрузки на решение
  3. Сценарии использования
    1. Макет UI
    2. Сценарии использования для задачи
      1. импорта данных:
        1. как пользователь загружает данные в программу массово (импорт из файла или внешнего источника)
        2. как пользователь загружает данные в программу вручную
      2. представления данных
        1. как данные отображаются для пользователя и что он должен сделать для их отображения
      3. анализа данных
        1. какие действия должен сделать пользователь для проведения анализа данных
      4. экспорта данных
        1. как пользователю получить копию хранимых в программе данных в машиночитаемом формате (JSON, XML, CSV ….)
      5. дополнительные сценарии использования
    3. Вывод о том, какие операции (чтение или запись) будут преобладать для вашего решения.
  4. Модель данных
    1. Нереляционная модель данных (для вашей СУБД)
      1. Графическое представление
      2. Описание назначений коллекций, типов данных и сущностей
      3. Оценка удельного объема информации, хранимой в модели (сколько потребуется памяти, чтобы сохранить объекты, как объем зависит от количества объектов)
      4. Запросы к модели, с помощью которых реализуются сценарии использования
    2. Аналог модели данных для SQL СУБД - характеризуется аналогично нереляционной (см. подпункты выше)
    3. Сравнение моделей
      1. Удельный объем информации - где данные занимают больший объем при прочих равных (http://se.moevm.info/doku.php/staff:courses:no_sql_introduction:calculating_data_model_size)
      2. Запросы по отдельным юзкейсам:
        1. Количество запросов для совершения юзкейсов в зависимости от числа объектов в БД и прочих параметров
        2. Количество задействованных коллекций (если есть)
        3. Сложность запроса
      3. Вывод - что лучше, SQL или NoSQL модель
  5. Разработанное приложение
    1. Краткое описание
    2. Схема экранов приложения и/или схема интерфейса командной строки
    3. Использованные технологии
    4. Ссылки на Приложение
  6. Выводы
    1. Достигнутые результаты
    2. Недостатки и пути для улучшения полученного решения
    3. Будущее развитие решения
  7. Приложения
    1. Документация по сборке и развертыванию приложения
    2. Инструкция для пользователя
    3. Снимки экрана приложения
  8. Литература

Возможные вопросы в процессе сдачи

  1. Термины из курса и их понимание
  2. Обоснования решений из ИДЗ
  3. Сравнение с SQL базами данных

Top secret

  • Mongo
  • Neo4j
  • Memcached
  • ArangoDB
  • Cassandra
  • DGraph
staff/courses/no_sql_introduction/course_work.txt · Last modified: 2022/12/27 12:00 by mark