どうも。つじけ（tsujikenzo）です。このシリーズでは「dbdiagram.ioでテキストからER図を書こう」について、全4回でご紹介します。
おさらい
前回、こちらのシリーズで、ER図を書くためのツールをご紹介しました。
draw.ioは、ER図を、マウスのブラウザ操作で作成するツールでしたが、今回は、テキストから作成する、dbdiagram.io（ディービーダイアグラムドットアイオー）をご紹介します。
なぜテキストなのか
ER図を作成する目的は、設計図を書いて、社内のチームメンバー（3か月後の自分も含みます）に、データベースの構造を理解してもらうためです。
では「なぜ手書きではなく、テキストから作成するか」は、2点あります。
正確性
手書きのER図でも、きちんと要点をおさえていれば、問題ありません。
しかしながら、初心者はどうしても「ざっくばらんに書きましょう」となってしまいがちです。書けばまずはOKということも多いでしょう。
そこで、下記のように、テキストで設計することで、正確にER図を描画します。
- テーブル[users]には主キーとなる数値型の属性[id]がある
- 属性[country_code]はテーブル[countries]の属性[code]とリレーションされている
- テーブル[users]とテーブル[countries]のカーディナリティは多対1である
作業効率UP
たとえば、ER図では、テーブルにすべての属性を書き出します。 
しかし、テーブルに必須な属性だけを表示させたいときもあると思います。手書きでは修正が大変ですが、テキストではコメントアウトするだけで、非表示にできます。 
ほかにも、さまざまなメリットがあります。手書きのER図からステップアップしたい方は、ぜひチャレンジしてみましょう。
無料アカウントとproアカウントの違い
dbdiagram.ioは、ブラウザ上で動くER図描画ツールです。
クラウド上にデータを保管することができ、無料でアカウントを作成できます。
無料版でも十分に使えますが、月額9ドルで、proアカウントへアップグレードが可能です（2022年2月現在）。
- 無料プランのすべての機能
- 無制限のダイアグラムとテーブル
- プライベートダイアグラム
- カラーヘッダー
- テーブルグループ
- バージョン履歴
- パスワード保護
- コラボレーション
個人的に気になったのは、保存できるダイアグラムが10個と、コラボレーション機能でしょうか。
しかしながら、チーム開発するさいも、GitHub上でコードを管理しようと思いますので、いまのところは無料プランでも問題ないかなと思います。
まとめ
以上で、「dbdiagram.ioでテキストからER図を書こう」の「はじめに」、をお送りしました。
わたしを含むノンプログラマーにとってER図は、少し学習しづらいものでした。
先にSQLを学ぶべきなのか、かといって環境がなかったり、悩まれた方も多いでしょう。
次回は、「基礎知識」をお届けします。
前回のおさらい
前回は、「はじめに」をお送りしました。
今回は、「基礎知識」をお送りします。
今日のアジェンダ
- プロジェクト
- 画面構成
- DBML
プロジェクト
dbdiagram.io（ディービーダイアグラムドットアイオー）は、1プロジェクトの中に複数のER図を作成できます。
ER図のことを、Diagram（ダイアグラム）と呼んでいます。今後はダイアグラムと呼びますが、ER図のことです。
アカウントの作成
まず、こちらのURLをクリックしましょう。
「Go To App」、もしくは「Create your diagram」をクリックします。 
ダイアグラムのサンプルが表示されます。 
画面右上の「Sign in」をクリックすると、中央にSign inウィンドウが表示されます。 
お好きな方で、Sign in（アカウント登録）を行ってください。詳細は割愛させていただきます。 
職業アンケートを聞かれますので、チェックをいれて[Submit]をクリックします。 
保存と呼び出し
サンプルを保存してみましょう。
左上にダイアグラムのタイトルを入力し（日本語も可）、「Save」をクリックします。 
タイトル横の下向き矢印をクリックして、「My Diagram」をクリックすると、保存したダイアグラムが表示されます。 
ダイアグラム一覧の[x]をクリックするとダイアグラムを削除できます。（無料プランだと10個までしか作成できないはずだけど・・・） 
ダイアグラムのURLには、ダイアグラムIDが含まれています。ダイアグラム名は、重複しても登録できますので、IDで管理するようにしましょう。 
画面構成
画面は大きく5つに分かれています。
- コードエディタ
- キャンバス
- ダイアグラム管理メニュー
- 機能メニュー（上部）
- キャンバス表示切替（下部）
かなり直感的に操作できるようにつくられているので、ポチポチとブラウザをクリックしてみた方が楽しいと思います。
わたしはハイライト表示が好きなので、以降はハイライトにチェックをいれた状態でお届けします。 
DBML
いちばんのメインは、左カラムのコードエディタです。
エディタにコードを書くことで、キャンバスにER図を作成していく流れになります。
キャンバスの表示は自動です。しかもリアルタイムです。すごいですね。 
DBMLとは
dbdiagram.ioでは、コードエディタに、DBML (Database Markup Language) という言語を書くことで、キャンバスを生成します。
DBMLは、世界中の有志（主なメンバーはdbdiagram.ioからのようです）が集まって開発した、データベース構造用に特化した無料の宣言型プログラミング言語です。
データベース操作言語のSQLをベースとしていますので、多くの構文が、SQL文と同様に設計されています。
まとめ
以上で、「基礎知識」、をお送りしました。
これで、実際にコードを書く準備が整いました。
次回は、「DBML」をお届けします。
前回のおさらい
前回は、「基礎知識」をお送りしました。
今回は、「DBML」をお送りします。
今日のアジェンダ
- DBMLのコーディング概要
- テーブル定義
DBMLのコーディング概要
dbdiagram.ioでコードを書くときは、主に、以下のことに留意しましょう。 
コードの中で 単語を””（ダブルクォーテーション）で囲む と、日本語も使用できますが、特別なばあいを除いて英語で書いていきましょう。 
テーブル定義
ダイアグラムの新規作成
まず、ダイアグラムを新規作成します。
タイトル横の下向き矢印から、「New Diagram」をクリックして、タイトルを入力します。 
必ず「Force Save（強制保存）」をクリックして、ダイアグラムを保存しましょう。普段おこなう「新規保存」や「上書き保存」と違いますが、プロジェクト全体を保存すると思ってください。 
主な、テーブル定義は下記になります。
| 項目 | 説明 | 例 |
|---|---|---|
| テーブル名 | 型を問いません。カンマやセミコロンやスラッシュや空白などは使用できません | User, 01Deals |
| カラム名 | プレーンテキスト、もしくは”カラム名”（二重引用符）が使用できます | name, “last_name” |
| 型 | カラムの型を定義します | int,integer,timestamp.varchar |
| 設定 | カラムの設定を定義します | [pk, increment, not null] |
| {} | リストを表しています | インデックス、制約、およびテーブル定義 |
| [] | 設定を表しています | [ref: > orders.id] |
テーブルとカラム定義
テーブル定義には、かならず1つ以上のカラム定義が必要です。 
テーブル定義は、このようになります。 
コードを書いてみましょう。
Table members {
id int [primary key]
}
キャンバスにテーブルが生成されました。 
テーブルは複数作成できます。 
エイリアスの活用
テーブル名は、エイリアスを設定し、後で呼び出すことができます 
このように記述します。（ref参照については、後ほど説明します） 
ノートとコメント
コードに影響をあたえない、コメントやノートを記述できます。 
コメントはエディタのどこにでも書けますが、ノートは、テーブル定義、カラム定義などのコード内に書く必要があります。
//コメントです
Table members {
id int [pk, note:'less than 10']
}
キャンバスでカラムにマウスカーソルを合わせると、参照ウィンドウが表示されます。 
同様に、テーブルへのコメントも、参照ウィンドウが表示されます。
Table countries{
code int [pk]
note:'Members origin' //コメントです
}
設定と制約
テーブル内の設定は、すべて[]（角括弧）内に記述します。 
主なプロパティ
| Property | 説明 | キャンバス対応 |
|---|---|---|
| pk, primary key | 主キー | 〇 |
| unique | 重複を認めない | × |
| not null | Nullを認めない | × |
| increment | レコードが増えると増加する | × |
主なkey:value
| Key | Values | キャンバス対応 |
|---|---|---|
| note | ‘文字列型’ | × |
| ref | > Table.columnなど | 〇 |
| default | 値 | × |
| delete | cascade,restrictなど | × |
| headercolor | ＃3498dbなど | △（近日予定） |
すでにコード内に登場している設定（pkやnote）もありますね。写経してみましょう。
//テーブル定義
Table members {
id int [pk, note:'less than 10']
full_name varchar [not null]
gender varchar(1) [default: 'm']
created_at timestamp
}
Table countries{
code int [pk]
name varchar [unique]
note:'Members origin'
}
まとめ
以上で、「DBML」、をお送りしました。
SQL文になれていない方でも、テーブルを作成したり、カラムを定義する体験ができたのではないでしょうか。
カラムの入力値に制約をかける、**varchar(1)**や、full_name varchar [not null] といった記述方法は、必要に応じて徐々に追記していけばいいと思います。
まずは、ER図をコードで書ける楽しさを体験しましょう。
次回は、「カーディナリティとリレーションシップ」をお届けします。
前回のおさらい
前回は、「DBML」をお送りしました。
今回は、「リレーションシップとカーディナリティ」をお送りします。
今日のアジェンダ
- リレーションシップと外部キー
- カーディナリティ
- 多対多の解消
リレーションシップと外部キー
テーブル同士を、外部キーで連結することを、リレーションシップと呼びます。
このように、片方のテーブルのカラム[country_code]と、もう片方のテーブルのカラム[code]を、リレーションさせることで、重複するデータがない設計ができます。 
リレーションシップはこのように定義します。 
コードを書いてみましょう。
//テーブル定義
Table members {
id int [pk, note:'less than 10']
full_name varchar [not null]
gender varchar(1) [default: 'm']
created_at timestamp
contry_code int [ref: > countries.code]
}
Table countries{
code int [pk]
name varchar [unique]
note:'Members origin'
}
キャンバスに、リレーションシップが反映されました。 
リレーションシップの省略記法
リレーションシップには省略記法があります。これらは、テーブルの外で定義できます。 
先ほどのコードを書き換えてみましょう。
//テーブル定義
Table members {
id int [pk, note:'less than 10']
full_name varchar [not null]
gender varchar(1) [default: 'm']
created_at timestamp
contry_code int //[ref: > countries.code]
}
Table countries{
code int [pk]
name varchar [unique]
note:'Members origin'
}
Ref: members.contry_code > countries.code
カーディナリティ
カーディナリティは3種類あります。それぞれ異なる記号を使って記述します。 
1対1
社用メールを管理する、userとemailの2つのテーブルがあったばあい、リレーションシップは1対1になります。 
しかし、1対1のリレーションシップは、1つのテーブルにまとめられるので、あまり見かけることはないでしょう。 
日本語中国語訳対応表などを作成するばあいは、テーブルをわけるかもしれません。 
1対多
注文書のような、見出し情報と明細情報がふくまれる帳票のリレーションシップは、1対多になります。 
よくあるパターンなので、おぼえておきましょう。 
多対多
実世界からエンティティを見つけて、リレーションシップを考えてみたところ、多対多（n対n） になることは、とてもよくあります。 
リレーションがよくわからないときは、2つのテーブルを並べて、具体的な組み合わせを書き出しましょう。必ず1対多なのか、多対多なのかが見えてきます。 
多対多の解消
多対多は、そのままでは、リレーショナルデータベースの設計に進むことができません。
多対多を解消するテクニックがあるので、ご紹介します。
中間テーブルを作成する
まず、中間テーブルを1つ作成します。テーブルの具体的なレコードも置きます。 
中間テーブルで、作成されるレコードを、具体的に書き出してみます。 
それぞれのリレーションシップを確認します。各レコードから何本のリレーションシップが出ているかを見ると、1対多か多対1になっていることがわかります。 
テーブル[Users]と[Status]には、[UserStatus]というテーブルが必要だったことが浮かびあがりました。 
リレーションシップは2つのテーブルとは限りません。このように複数のテーブルがリレーションしていることもあります。 
最後に、複数のテーブルがリレーションしたテーブルを、コードで書いてみましょう。
Table users as U{
user_id int [pk]
name varchar
}
Table tasks as T{
task_id int [pk]
task varchar
}
Table status as S{
status_id int [pk]
status varchar
}
Table UserTaskStatus as UTS{
UserTaskStatus_id int [pk]
user_id int
task_id int
status_id int
created_at datetime
}
Ref:UTS.user_id < U.user_id
Ref:UTS.task_id < T.task_id
Ref:UTS.status_id < S.status_id
このようなER図を作成できました。 
まとめ
以上で、「リレーションシップとカーディナリティ」をお送りしました。
DBMLには、他にもインデックスや、列挙型など、便利な構文があります。
DBML中級編として、いつかお届けできればいいなと思います。
Comments