物流プラットフォーム、サプライチェーン運用、または受注処理データベースを設計する際、RawなDBMLスキーマ宣言を読むと、テーブル、列挙型、スキーマ、参照がどのように接続されているかを把握するのが難しくなることがあります。DBMLスキーマビジュアライザーあなたのDBML定義を明確でインタラクティブなエンティティ関係図（ERD）に変換します。テーブル構造、スキーマ接頭辞、列挙型、テーブルグループ、参照関係（>, <, -, <>）を解析することで、データベース管理者やソフトウェアアーキテクトは、複雑な追跡システムを一目で確認できます。
DBMLビジュアライゼーションの仕組み
VPasCodeでは、DBMLレンダリングがProject設定、Enum宣言、TableGroupブロック、およびTableテーブル定義を視覚的なERDノードに変換します。スキーマ名前空間を持つテーブル（例：logistics.drivers）はフルパスで表示され、カスタム列挙型は厳密なカラムタイプとして機能し、外部キー参照はエンティティ間の視覚的リンクを自動的に生成します。
1. 必須設定：FleetLogix物流データベーススキーマの完全構築
全体の物流エコシステムを可視化するため、有効なDBML構文でプロジェクトパラメータ、従業員役割、受注処理エンティティ、出荷ログ、参照制約を定義してください：
Project fleetlogix {
database_type: 'PostgreSQL'
}
Enum employee_role {
courier
dispatcher
manager
}
Enum status_value {
pending
sorting
transit
delivered
exception
}
TableGroup fulfillment {
logistics.parcels
logistics.vehicles
logistics.hubs
}
Table 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()']
}
Table 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]
}
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]
}
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.insurance_policies.driver_id > logistics.drivers.id
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
Ref: logistics.hubs.id < logistics.parcels.hub_id
Ref: logistics.parcels.id <> logistics.vehicles.id
Ref: logistics.drivers.id - logistics.insurance_policies.id
FleetLogixにおける高度な構造技術
DBMLコードの特定のセクションを分解することで、異なるデータベース機能がどのように連携しているかを明確に示すことができる。
1. ドライバー管理、保険およびカスタム列挙型
ドライバー登録および保護モデルはカスタム列挙型（employee_role）、厳格な制約（unique, not null）、および2つの関係タイプ：標準の1対多の検索と明示的な1対1のリンク（-).
列挙型 employee_role {
カーゴ配達員
ディスパッチャー
マネージャー
}
テーブル logistics.drivers {
id int [pk, 自動増加]
email varchar(255) [not null, unique]
full_name varchar(120)
role employee_role [not null, default: 'カーゴ配達員']
joined_at timestamp [not null, default: 'now()']
}
テーブル logistics.insurance_policies {
id int [pk, 自動増加]
driver_id int [not null]
coverage_plan varchar(20) [not null]
expires_on date [not null]
auto_renew boolean [not null, default: true]
}
// 1対多のドライバー関係
参照: logistics.insurance_policies.driver_id > logistics.drivers.id
// 1対1のドライバー契約関係
参照: 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]
}
// 1対多関係を逆方向の矢印（<）で表現
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にグループ化することで、視覚的なレイアウトを整理できます。 - 関係の方向性を正しく保つ： 標準化して
>（多対一）または<(1対多) そのため、視覚的な外部キーの矢印は、子フィールドから主キーへ明確に指向する。 - インデックスと列挙型を使って、ビジネスルールを強制する： 複合一意インデックス（例：
(パッケージID、ドライバーID) [一意]）およびカスタム列挙型（例：ステータス値）を用いて、スキーマレベルでビジネス制約を強制する。