#Глава 2. Моделирование данных — две таблицы для системы заявок

В прошлой главе мы установили NocoBase и познакомились с интерфейсом. Теперь соберём скелет системы заявок — определим модель данных.

В этой главе мы создадим две таблицы — заявки и категории, настроим типы полей (однострочный текст, выпадающий список, многие к одному и т. д.) и установим связи между таблицами. Модель данных — фундамент системы: сначала продумываем, что хранить и как данные связаны, и тогда сборка интерфейса и настройка прав пройдут естественно.

#2.1 Что такое таблица и поле

Если Вы работали с Excel, понять таблицу легко:

Например, наша «таблица заявок» — это как лист Excel: каждый столбец — поле (заголовок, статус, приоритет…), каждая строка — запись.

При этом NocoBase гораздо мощнее Excel. Поддерживаются разные типы таблиц, каждый со своими возможностями:

Сегодня мы используем обычную и древовидную таблицы. Остальные типы рассмотрим, когда понадобятся.

Открываем управление источниками данных: нажмите иконку «Управление источниками данных» в левом нижнем углу (иконка БД рядом с шестерёнкой). Вы увидите главный источник данных — туда мы и поместим все наши таблицы.

#2.2 Создаём основную таблицу: заявки

Сразу к сути — создаём ядро системы, таблицу заявок.

#Создание таблицы

1. На странице управления источниками данных нажмите главный источник и зайдите внутрь

2. Нажмите «Создать таблицу» и выберите «Обычная таблица»

3. Имя таблицы: tickets, заголовок: Заявки

При создании таблицы система по умолчанию отмечает набор системных полей, которые автоматически фиксируют метаинформацию о записи:

Эти системные поля можно оставить по умолчанию — управлять ими вручную не требуется. Если в каком-то сценарии они не нужны, снимите галочки.

#Добавляем базовые поля

Таблица создана, теперь добавим поля. Нажмите у таблицы заявок «Configure fields» — Вы увидите, что системные поля уже в списке.

Нажмите кнопку «Add field» в правом верхнем углу — раскроется список типов полей; выберите нужный.

Сначала добавим собственные поля заявки, а связные — позже.

1. Заголовок (однострочный текст)

Каждой заявке нужен короткий заголовок-резюме. Нажмите «Add field» → «Single line text»:

• Имя поля: title, заголовок: Заголовок
• Нажмите «Set validation rules», добавьте правило «Required»

2. Описание (Markdown(Vditor))

Нужно подробно описать проблему с поддержкой форматирования, удобно вставлять картинки и код. В категории «Add field» → «Media» три варианта:

Выберем Markdown(Vditor).

• Имя поля: description, заголовок: Описание

3. Статус (выпадающий список — единичный выбор)

Заявка проходит путь от подачи до завершения, нужен статус для отслеживания.

• Имя поля: status, заголовок: Статус
• Добавьте варианты («значение опции» и «метка опции», цвет — опционально):

Сначала заполните опции и сохраните. Затем снова нажмите «Edit» на этом поле — теперь в «Default value» можно выбрать «На рассмотрении».

При первом создании опций ещё нет, поэтому значение по умолчанию выбрать нельзя — сохраните, затем вернитесь и настройте.

Почему именно выпадающий список с одиночным выбором? Статус — фиксированный набор значений. Выпадающий список предотвращает произвольные ввод и обеспечивает корректность данных.

4. Приоритет (выпадающий список — единичный выбор)

Отделяет срочные заявки и помогает сортировать обработку.

• Имя поля: priority, заголовок: Приоритет
• Добавьте варианты:

В таблице заявок теперь 4 базовых поля. Но у заявки должна быть «категория»: сетевые проблемы, сбои ПО и т. д.

Можно сделать категорию выпадающим списком, но Вы быстро упрётесь: у категорий могут быть подкатегории («аппаратные проблемы» → «монитор», «клавиатура», «принтер»), и выпадающего списка уже не хватит.

Нам нужна отдельная таблица для категорий. И лучше всего сделать её древовидной в NocoBase.

#2.3 Создаём древовидную таблицу категорий: добавляем иерархию

#Что такое древовидная таблица

Это особый тип таблицы со встроенными отношениями родитель-ребёнок — у каждой записи может быть «родительский узел». Идеально подходит для иерархических данных:

Аппаратные проблемы          ← категория 1-го уровня
├── Монитор                   ← категория 2-го уровня
├── Клавиатура и мышь
└── Принтер
Сбои ПО
├── Офисное ПО
└── Системные проблемы
Сетевые проблемы
Учётные записи и права

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

#Создание таблицы

1. Возвращаемся в управление источниками данных, нажимаем «Создать таблицу».

2. На этот раз выбираем «Древовидная таблица» (не обычную!).

3. Имя таблицы: categories, заголовок: Категории заявок

После создания, помимо системных полей, в таблице автоматически появятся два поля связей — «Parent» и «Children». Это особенность древовидной таблицы. Через Parent — доступ к родителю, через Children — ко всем потомкам, добавлять вручную не нужно.

#Добавляем поля

Нажмите «Configure fields» — увидите системные поля и автоматически созданные Parent, Children. Нажмите «Add field» в правом верхнем углу:

Поле 1: название категории

1. Выберите «Single line text».
2. Имя поля: name, заголовок: Название категории.
3. Нажмите «Set validation rules», добавьте «Required».

Поле 2: цвет

1. Выберите «Color».
2. Имя поля: color, заголовок: Цвет.

Поле цвета даёт каждой категории свой цвет — на интерфейсе это смотрится нагляднее.

Базовые поля обеих таблиц настроены. Теперь свяжем их.

#2.4 Возвращаемся к таблице заявок: добавляем связные поля

Связные поля могут показаться абстрактными. Если непонятно, перейдите сразу к Главе 3. Сборка страниц — на практике увидите, как данные отображаются, и потом вернётесь к связям.

Заявка должна быть связана с категорией, заявителем и обработчиком. Эти поля называются связными — они хранят не текст, а ID записи из другой таблицы и через него получают связанные данные.

Посмотрим на конкретную заявку — слева её атрибуты; в полях «категория» и «заявитель» хранится не текст, а ID. Через ID система точно находит запись в правой таблице:

В интерфейсе Вы видите имена («Сетевые проблемы», «Иван Иванов»), но за ними стоит связь по ID. Несколько заявок могут указывать на одну категорию или одного пользователя — это связь многие к одному.

#Добавляем связное поле

В таблице заявок нажмите «Configure fields» → «Add field» → «Many to one».

В диалоге появятся такие настройки:

Внешний ключ по умолчанию генерируется случайно (например, f_xxxxx) — рекомендуем заменить на осмысленное имя, чтобы было удобно сопровождать. Используйте латиницу в нижнем регистре с подчёркиваниями (например, category_id), без CamelCase.

Добавьте по очереди три поля:

5. Категория → таблица категорий заявок

• Заголовок поля: Категория
• Целевая таблица: «Категории заявок» (если в списке нет, введите имя — таблица создастся)
• Внешний ключ: category_id

6. Заявитель → таблица пользователей

Кто отправил заявку. В NocoBase встроенная таблица пользователей, связываемся напрямую.

• Заголовок поля: Заявитель
• Целевая таблица: «Пользователи»
• Внешний ключ: submitter_id

7. Обработчик → таблица пользователей

Кто отвечает за заявку.

• Заголовок поля: Обработчик
• Целевая таблица: «Пользователи»
• Внешний ключ: assignee_id

#2.5 Полная картина модели

Вот итоговая модель данных:

}o--|| означает связь «многие к одному»: слева «многие», справа «один».

#Итоги главы

В этой главе мы построили скелет системы заявок:

1. Таблица заявок (tickets): 4 базовых поля + 3 связных поля, тип — обычная таблица.
2. Таблица категорий заявок (categories): 2 кастомных поля + автоматические Parent/Children, тип — древовидная, что естественно поддерживает иерархию.

Мы освоили несколько важных понятий:

• Таблица (Collection) = контейнер однотипных данных
• Тип таблицы = разные сценарии — разные типы (обычная, древовидная и т. д.)
• Поле (Field) = атрибут данных, создаётся через «Configure fields» → «Add field»
• Системные поля = ID, дата создания, автор и т. д. (отмечены при создании автоматически)
• Связное поле (многие к одному) = ссылка на запись в другой таблице, основа для связей

Возможно, Вы заметили, что на скриншотах далее уже есть данные — это тестовые записи для демонстрации, не переживайте. В NocoBase создание, чтение, изменение и удаление выполняются через интерфейс. В Главе 3 мы соберём таблицы для отображения данных, в Главе 4 — формы для ввода. Раскроем тему пошагово.

#Анонс следующей главы

Скелет готов, но таблицы пустые. В следующей главе мы соберём страницу, чтобы данные действительно появились на экране.

До встречи!

#Связанные ресурсы

• Источники данных — основные концепции моделирования в NocoBase
• Поля таблицы — описание всех типов полей
• Связь «многие к одному» — настройка связей