При проектировании платформ логистики, операций цепочки поставок или баз данных выполнения заказов, чтение исходных объявлений схем DBML может затруднить визуализацию того, как таблицы, перечисления, схемы и ссылки связаны между собой. Визуализатор схем DBML преобразует ваши определения DBML в четкие интерактивные диаграммы «сущность-связь» (ERD). При анализе структур таблиц, префиксов схем, типов перечислений, групп таблиц и связей между ними (>, <, -, <>), администраторы баз данных и архитекторы программного обеспечения могут мгновенно оценить сложные системы отслеживания.
Механика визуализации DBML
В VPasCode отображение DBML анализирует Проект настройки, Перечисление объявления, Группа таблиц блоки и Таблица определения в визуальные узлы ERD. Таблицы с пространствами имён схем (например, logistics.drivers) отображаются с полными путями, пользовательские перечисления выступают в качестве строгих типов столбцов, а ссылки внешних ключей автоматически создают визуальные связи между сущностями.
1. Необходимая настройка: Полная схема базы данных логистики FleetLogix
Чтобы визуализировать всю экосистему логистики, определите параметры проекта, роли сотрудников, сущности выполнения заказов, журналы отправок и ссылочные ограничения в корректном синтаксисе DBML:
Проект fleetlogix {
тип_базы_данных: 'PostgreSQL'
}
Перечисление employee_role {
курьер
диспетчер
менеджер
}
Перечисление status_value {
ожидание
сортировка
в пути
доставлено
исключение
}
Группа таблиц fulfillment {
logistics.parcels
logistics.vehicles
logistics.hubs
}
Таблица logistics.drivers {
id int [pk, увеличение]
email varchar(255) [не_пустой, уникальный]
full_name varchar(120)
роль employee_role [не_пустой, по_умолчанию: 'курьер']
joined_at timestamp [не_пустой, по_умолчанию: 'now()']
}
Таблица logistics.insurance_policies {
id int [pk, увеличение]
driver_id int [не_пустой]
coverage_plan varchar(20) [не_пустой]
expires_on date [не_пустой]
auto_renew boolean [не_пустой, по_умолчанию: true]
}
Таблица logistics.parcels {
id int [pk, увеличение]
tracking_number varchar(200) [не_пустой]
hub_id int
weight_kg int
estimated_days int
service_level varchar(10)
}
Таблица logistics.vehicles {
id int [pk, увеличение]
license_plate varchar(160) [не_пустой]
last_service date
}
Таблица logistics.hubs {
id int [pk, увеличение]
name varchar(80) [не_пустой, уникальный]
}
Таблица logistics.delivery_manifests {
id int [pk, увеличение]
parcel_id int [не_пустой]
driver_id int [не_пустой]
status status_value [не_пустой]
checkpoint varchar(200)
notes text
Индексы {
(parcel_id, driver_id) [уникальный]
}
}
Таблица logistics.telemetry_history {
driver_id int [не_пустой]
parcel_id int [не_пустой]
logged_at timestamp [не_пустой, по_умолчанию: 'now()']
Индексы {
(driver_id, logged_at)
}
}
Ссылка: logistics.insurance_policies.driver_id > logistics.drivers.id
Ссылка: logistics.delivery_manifests.parcel_id > logistics.parcels.id
Ссылка: logistics.delivery_manifests.driver_id > logistics.drivers.id
Ссылка: logistics.telemetry_history.driver_id > logistics.drivers.id
Ссылка: logistics.telemetry_history.parcel_id > logistics.parcels.id
Ссылка: logistics.hubs.id < logistics.parcels.hub_id
Ссылка: logistics.parcels.id <> logistics.vehicles.id
Ссылка: logistics.drivers.id - logistics.insurance_policies.id
Расширенные структурные методы в FleetLogix
Разбор конкретных разделов вашего кода DBML помогает проиллюстрировать, как различные функции базы данных работают вместе.
1. Управление водителями, страхование и пользовательские перечисления
Реестр водителей и модель защиты используют пользовательские перечисления (employee_role), строгие ограничения (unique, not null), и два типа связей: стандартная связь один ко многим и явная связь один к одному (-).
Перечисление employee_role {
courier
dispatcher
manager
}
Таблица logistics.drivers {
id int [pk, increment]
email varchar(255) [not null, unique]
full_name varchar(120)
role employee_role [not null, default: 'courier']
joined_at timestamp [not null, default: 'now()']
}
Таблица logistics.insurance_policies {
id int [pk, increment]
driver_id int [not null]
coverage_plan varchar(20) [not null]
expires_on date [not null]
auto_renew boolean [not null, default: true]
}
// Связь один ко многим с водителем
Ссылка: logistics.insurance_policies.driver_id > logistics.drivers.id
// Связь один к одному с договором водителя
Ссылка: logistics.drivers.id - logistics.insurance_policies.id
2. Группировка выполнения заказов и многие ко многим
Уровень физических активов включает TableGroup содержащий logistics.parcels, logistics.vehicles, и logistics.hubs. Он использует обратный оператор связи (<) для региональных распределительных центров и оператора связи многие ко многим (<>) между посылками и транспортными средствами доставки.
TableGroup fulfillment {
logistics.parcels
logistics.vehicles
logistics.hubs
}
Table logistics.parcels {
id int [pk, increment]
tracking_number varchar(200) [not null]
hub_id int
weight_kg int
estimated_days int
service_level varchar(10)
}
Table logistics.vehicles {
id int [pk, increment]
license_plate varchar(160) [not null]
last_service date
}
Table logistics.hubs {
id int [pk, increment]
name varchar(80) [not null, unique]
}
// Один ко многим с обратным направлением стрелки (<)
Ref: logistics.hubs.id < logistics.parcels.hub_id
// Многие ко многим (<>)
Ref: logistics.parcels.id <> logistics.vehicles.id
3. Отслеживание в реальном времени, составные индексы и перечисления статусов
Модули манифеста и телеметрии отслеживают активные операции с отправлениями. Они используют перечисление состояния отслеживания (status_value), единичные составные уникальные индексы (например, (parcel_id, driver_id) [unique]) для обеспечения целостности записей, а также многостолбцовые индексы для быстрого хронологического сканирования.
Enum status_value {
pending
sorting
transit
delivered
exception
}
Table logistics.parcels {
id int [pk, increment]
tracking_number varchar(200) [not null]
}
Table logistics.drivers {
id int [pk, increment]
full_name varchar(120) [not null]
}
Table logistics.delivery_manifests {
id int [pk, increment]
parcel_id int [not null]
driver_id int [not null]
status status_value [not null]
checkpoint varchar(200)
notes text
indexes {
(parcel_id, driver_id) [unique]
}
}
Table logistics.telemetry_history {
driver_id int [not null]
parcel_id int [not null]
logged_at timestamp [not null, default: 'now()']
indexes {
(driver_id, logged_at)
}
}
Ref: logistics.delivery_manifests.parcel_id > logistics.parcels.id
Ref: logistics.delivery_manifests.driver_id > logistics.drivers.id
Ref: logistics.telemetry_history.driver_id > logistics.drivers.id
Ref: logistics.telemetry_history.parcel_id > logistics.parcels.id
Стратегические лучшие практики для DBML
- Организуйте основные коллекции с помощью TableGroup: Группируйте тесно связанные таблицы (например,
logistics.parcels,logistics.vehicles, иlogistics.hubs) вTableGroupчтобы сохранить визуальную структуру в порядке. - Обеспечьте правильное направление отношений: Стандартизируйте на
>(многие к одному) или<(один ко многим), поэтому визуальные стрелки внешних ключей четко указывают от полей дочерних таблиц к первичным ключам. - Принудительное соблюдение бизнес-правил с помощью индексов и перечислений: Используйте составные уникальные индексы (например,
(parcel_id, driver_id) [уникальный]) и пользовательские перечисления (например,status_value) для принудительного соблюдения бизнес-ограничений непосредственно на уровне схемы.