01
方言を合わせる
方言の選択は構文と識別子の解釈を変えます。SQLの方言変換はしません。MySQLではテーブル単位のFOREIGN KEYを使い、ほかの2方言では列のREFERENCESも扱います。
- 方言を変えると再解析が終わるまでコピーと保存を無効にします。
データベース・SQLツール
SQLからER図宣言された構造を読む
入力したDDLを図、列一覧、構造データで確認します。最初に元のSQLと同じ方言を選んでください。
SQLからER図
SQL DDL入力
構造の確認
SQLを入力するかサンプルを選んでください。
ブラウザー内で処理します。データベースへの接続や履歴の保存はありません。
方言と解釈
CREATE TABLEと通常の列を指定したCREATE INDEXのみ対応。明示的な外部キーだけを結び、SQLは実行しません。
上限は50,000 UTF-16単位、50テーブル、1,000列。キー・インデックス・CHECK・外部キーは合計200件。列は50件ずつ表示します。
TypeScriptは取得行の型です。大きな整数と精密な小数はstring、不明な型とSQLiteの列はunknownです。ドライバーの返却形式を確認してください。
結果が古くなっています。現在の入力を処理してから書き出してください。
SQLからER図を作ると、接続先のないテーブル定義書でもレビューを始められます。テーブル名を並べるだけでは見落としやすい複合キーや、別のファイルにしか存在しない参照先を確認するための画面です。
例にはNULL許可列、一意キー、通常のインデックス、小数型を含めています。DDL可視化の結果と元の定義を見比べて、実際に宣言された情報の範囲を把握してください。
SQLからER図で確かめられること
図にある関係と、入力からは分からない関係を区別します。
名前ではなく制約で接続する
SQLからER図への変換では、外部キーがあるテーブルだけをつなぎます。入力にない参照先は破線の外部ノードとして残すため、一部だけのDDLを完全な設計図と取り違えにくくなります。
図と取得行の型を同時に確認
図は依存先の把握に、JSONは構造の受け渡しに、TypeScriptは取得行の型のたたき台に使えます。表示を切り替えても、元になる解析結果は同じです。
読み違いを防ぐ確認手順
02
未解決の参照先を探す
部分的なDDLでは、参照先のテーブルが含まれていないことがあります。破線ノードと対象列を確認し、必要なCREATE TABLEを追加してください。
- スキーマ名のない参照は、スキーマ名のないテーブルだけと照合します。
03
型の意味を確認する
デフォルト値があっても取得行のプロパティは省略可能になりません。精密な数値はstring、既知のNULL許可型はnullとの共用体になります。
- 自動解析を切ると、ボタンまたはCtrl/Cmd + Enterで解析できます。
定義を調べるための六つの視点
三方言のテーブル定義
MySQL、PostgreSQL、SQLiteの対応するDDLを読み取ります。引用符付き識別子と修飾テーブル名を保持し、PostgreSQLの引用符なし名称は小文字に正規化します。
主キーと外部キーの組み合わせ
複合主キーと一意キーは列順を持つ一組として保存します。外部キーの両側の列も順に対応させ、中間テーブルを勝手に多対多の業務関係へ置き換えません。
列単位で元の記述を見る
型の表記、NULL許可、主キー所属を一覧で確認できます。列定義を開くとDEFAULT、CHECK、生成列の句も原文で読めます。インデックスは列順と昇降順を残します。
構造JSONを再利用する
テーブル、列、キー、インデックス、検査定義、参照先をまとめたスナップショットを保存します。未解決の外部参照も残ります。JSON Schemaによるデータ検証とは異なる出力です。
慎重なTypeScriptマッピング
安全な連番のインターフェース名と引用符付きのプロパティ名を生成します。日時はstring、バイナリはUint8Array、JSONや不明な型はunknownです。実際のドライバー設定との照合が必要です。
ドキュメントに使えるSVG
ER図をSVGとして保存できます。各カードでは先頭5列を示し、長い名前は短縮することがあります。列一覧とJSONには全項目を残すため、概観と詳細を併せて確認できます。
対応範囲と解釈上の制約
- 対応するのは構造定義の一部
- CREATE TABLEと列名によるCREATE INDEXを受け付けます。ALTER、INSERT、ビュー、トリガー、ストアドプロシージャ、CREATE TABLE AS/LIKEはバッチ全体をエラーにします。式・接頭辞・部分インデックスも簡略化せず拒否します。
- 業務上の関係は推定しない
- 列名が_idで終わっても線は増えません。矢印は宣言を示すもので、多重度や参照先の一意性、ストレージエンジンが制約を強制するかまでは証明しません。必要な制約は入力側に追加してください。
- サーバーの設定を再現しない
- PostgreSQLは引用符なし名称を小文字化し、引用符付き名称を保持します。MySQLはテーブル名を完全一致、列名を大文字小文字を区別せず照合します。SQLiteのASCII識別子も同様です。search_pathや省略スキーマは補いません。
- MySQLの列内参照はエラー
- MySQLは列に書いたREFERENCESを無視します。その記述を有効な関係として描画せず、独立したFOREIGN KEY句への変更を求めます。テーブル単位の宣言も、実環境での強制を保証するものではありません。
- SQLiteには独自のNULL規則がある
- 通常の非INTEGER主キーはNULLを許す場合があります。INTEGER主キーと対応するWITHOUT ROWID定義にはそれぞれの非NULL規則を適用します。動的型付けのため、取得行のプロパティ型はすべてunknownです。
- 大きな構造は分割する
- 上限は50,000 UTF-16単位、50テーブル、1,000列です。キー、明示的インデックス、保存したCHECK、外部キーは合計200件。さらに15,000トークン、括弧32階層、250文までで、超過時は全体を拒否します。
- 読み取り専用の解析結果
- DEFAULTやCHECKを実行しません。接続、ファイル読込、AI設計、クラウド保存、図からの編集、マイグレーション生成、PNG/DBML出力も対象外です。TypeScriptは実行時検証や挿入用DTOではありません。
SQLからER図についての質問
データベースへの接続は必要ですか？
データベースへの接続は不要です。必要なのはCREATE TABLEなどの対応DDLだけです。サーバーの権限やデータ、設定は参照しないので、構文解析が成功しても実際のデータベースで実行できるとは限りません。
どのSQL方言を読み込めますか？
MySQL、PostgreSQL、SQLiteを明示的に選択します。対応するCREATE TABLEと単純なCREATE INDEXが対象で、各製品のすべてのDDL構文を網羅するものではありません。エラー位置を確認し、未対応の句を分けてください。
主キーと外部キーを図で区別できますか？
図の列プレビューでは主キーを記号で示し、外部キーを矢印で表します。列とキーの表示では複合キーの全列を順序付きで確認できます。参照先が欠ける場合は外部・未解決と明記されます。
データベース設計の課題にも利用できますか？
テーブル定義の検討やデータベース設計の課題に使えます。ただし、業務要件や正規化の正しさを自動評価するツールではありません。入力した制約と課題の要件を、自分で対応づけて説明する必要があります。
業務の説明だけで図を作れますか？
自然言語からDDLや関係を生成する機能はありません。まずテーブル、列、主キー、外部キーをSQLで記述してください。名前の類似から関係を補うこともしないため、図の根拠を元の定義で確認できます。
整形の問題を見つけましたか？