1. すべてのサービスの土台にある「データベース」
データベースとは何なのか？
今、目の前には「でーたべーすってなにー？」と聞いてくる将来有望な小学1年生がいます。みなさんはどう答えますか？
「データベース」という言葉自体は、IT業界にいる人なら一度は聞いたことがあるはずですし、日々の仕事の中でも自然と使っているかもしれません。
でも一方で、「ちゃんと説明できるか？」と問われると、意外とむずかしいと感じる人も多いのではないでしょうか。
まずここでは、Oracle社が出している定義を確認します。
データベースとは、
「構造化した情報またはデータの組織的な集合」
のことです。
「構造化？組織的？集合？」と一気にハードルが上がってしまう気がします。
定義は堅苦しく見えるかもしれませんが、簡単に言いかえれば
「たくさんの情報を、あとで取り出しやすいように整理して保管する仕組み」 です。
たとえば、
-
顧客情報や社員名簿を表形式でまとめておく
-
必要なときに探して、取り出せるようにする
こうした仕組みは、すべてデータベースです。
もっと身近な例では、SNSのフォローフォロワーや家計簿の物と金額、もしかしたら冷蔵庫の中身とか人間関係なんかも？広い意味では、データベースと捉えられるかもしれません。
これはついつい叫びたくなってしまいますね。
※本画像はAIによって独自生成されたものであり、既存アニメキャラクターや作品とは一切関係ありません
ITの世界ではユーザー情報、商品データ、注文履歴といったさまざまな情報を、
こうした 「整理された形」 で扱うことが不可欠です。
なぜデータベースが重要なのか？
では、なぜこの「整理された形」が、ITにとって"土台"とまで言われるのでしょうか？
それは、
「多くのITサービスが人・物・時間など、あらゆるデータを"記録・再現"する必要があるから」
です。
たとえば、
- SNSならユーザー情報、投稿内容、フォロワー関係
- ECサイトなら商品、注文、在庫、決済履歴
- 業務システムなら社員情報、勤怠記録、売上レポート
のように、現代のサービスには「記録」「再現」するデータが膨大に存在します。
仮にこれらのデータを「記録」できるのが下手だったり、
「再現」することにたくさん失敗していたら、
サービスが全く機能しないことは想像つくかと思います。
他にもデータのセキュリティや同時に処理を行えるかなど、データベースには
「ユーザーがわざわざ意識する必要はないけれど、サービスの提供には欠かせない機能」
がたくさんあります。
データベースの4つの要素
上記で述べたようなサービスの土台を支えるデータベースの仕組みを安全に且つ正確に設計できるよう、現代のデータベースは必ず4つの要素をもとに作成されています。
1. 管理したいデータ＝「エンティティ」
これは、何についての情報を管理するかという要素です。たとえば、
- お客さん（顧客）
- 売っている商品（商品）
- 注文の履歴（注文）
- 請求書（請求）
こういった、情報のまとまりの"主役"になるデータを「エンティティ」と呼びます。
2. データが持っている情報＝「属性」
エンティティがどんな情報を持っているかを表すのが「属性」です。たとえば、
- 商品 → 商品名、価格、在庫数
- 顧客 → 名前、住所、電話番号
Excelでいう「列の見出し」に近いイメージです。
3. データ同士のつながり＝「リレーション(関係)」
エンティティ同士がどう関係しているかを設計するのが「リレーション」です。
現実のビジネスでは、いろんな情報がつながって意味を持ちます。 たとえば、
- 「顧客」が「注文」をする
- 「注文」が「商品」と結びつく
などです。
4. どれくらいの数でつながるか＝「多重度」
「リレーション」にはつながり方のパターンがあり、これを「多重度」と呼びます。
例を挙げると、
- 1対1：社員と社員番号（1人に1つだけ）
- 1対多：顧客と注文（1人の顧客が何件も注文できる）
- 多対多：社員と業務（1人の社員が複数の仕事を担当し、1つの仕事に複数の社員が関わる）
この「数の関係」をしっかり考えることで、現実に即したデータ構造を作ることができます。
なぜ「データベース難しそう」は起きるのか？
ここまで見てくると、一部の方には「なるほど！データベース最高！」と
思っていただけるかもしれません。
ただしまだおそらく多くの人にとってデータベースは、
「なんか難しそう」「自分には関係なさそう」と思われがちな存在かと思います。
その理由のひとつが、「自分でデーターベースを作る機会がないから」 ではないでしょうか。
社内のどこかしらで作ってみようと思っても、
- 見たこともない専門用語の多さ（正規化、リレーション、インデックス…）
- 「何か間違えたらデータが壊れるかも」という漠然とした不安
- コマンドを打ち込む黒い画面（?）
など、手を着けづらいイメージが先行し具体的な操作をする前に人を遠ざけてしまいます。
では、どうすれば「最初の一歩」をもっと気軽に踏み出せるようになるのでしょうか？
その1つのアンサーとして、私は「Supabaseを触ってみること」を提案したいと思います。
2. Supabaseという入り口からデータベースを知る
Supabaseとは？
Supabaseは、
データベースをの最初の"つまずきポイント"を徹底的に減らしてくれる基盤
だと思っています。
正確に言うと、Firebaseのオープンソース代替として生まれたモダンなバックエンドプラットフォームです。
- 開発者でなくても触れるほどシンプルで直感的
- 「PostgreSQL」という本格的なデータベース
- 無料かつオープンソース（誰でも使える）
という特徴があげられます。
このPostgreSQLは、多くの企業でも使われている信頼性の高いデータベースで、
「データベースのちゃんとした仕組みを学ぶための教材」としても最適です。
しかもSupabaseでは、以下のような機能が最初からセットになって用意されています。
- ファイル保存用のストレージ付き
- リアルタイムで反映される
- ログイン・認証機能の実装
つまり、「データベースの勉強をしたい」だけでなく、
「実際にWebサービスを作ってみたい」というニーズにも応えられる、
とても実用的で学びやすいサービスです。
Supabaseが初心者にやさしい3つの理由
1. 画面で見て、触って、理解できる
Supabaseの管理画面は非常にわかりやすく、たとえば以下のことが画面操作でできます。
- テーブルの作成・編集・削除
- データの登録・検索・更新・削除
- テーブル間のリレーションの可視化
「さっそくSQLコマンド！」ではなく、「クリック」からスタートできます。
以下はホーム画面ですが、左のツールバーからやりたいことを直感的に選ぶことができます。
（Google翻訳を反映しているので少し不自然です）
Supabaseのホーム画面
以下は「テーブルエディッター」から「テーブルを新規作成する」を選んだ時の画面です。
SQLに難しいイメージを持っている方でも「これだとできそう！」と思われませんか。
テーブルを新規作成する画面
2. ER図とSQLがセットで使える
Supabaseには、テーブルの関係を図（ER図）で表示する機能があります。
さらに、SQLの学習や実験にも最適なエディタが内蔵されており、
コードを書いて実行 → 結果を見る → 図で構造を確認、という流れが自然に行えます。
初心者がつまずきやすい「リレーション」の理解にも大きく役立ちます。
よくあるER図はこんな感じ。実際のSupabaseのER図画面はこの下で紹介します。
3. 触るだけでAPIができている
今回の入門編ではそこまで関係ないのですが、Supabaseの魅力のひとつが
データベースから自動でRESTful APIを生成してくれる ことです。
これによりフロントエンドから「認証されたユーザーがデータを読み書きする」といった処理が、
ほとんど何も書かずに実現できます。
認証、認可、リアルタイム更新も標準搭載されており、
最初から"本物のプロダクト"に近い体験ができます。
管理画面にあるAPIの説明
3. Supabaseで『キングダムの』データベースを作ってみる
ここでは実際にSupabaseを使い、データベースを作る体験ができる3ステップを紹介します。
セットアップの説明はたくさん記事があるので省略します。
以下の記事などを参考にされてください。
今回は実際のアプリやバックエンドを構築するわけではなく、あくまでデータベースを体感するためなので、必要なのはアカウント登録くらいでしょうか。5分くらいで可能かと思います。
もちろん無料の範囲で可能です。
STEP1.エンティティ・リレーションを考える
まずは「どんな情報を管理したいか」を考えます。
一度簡単な表にしておくとイメージがつきやすいかもしれません。
ここでは例として、人気漫画『キングダム』の登場人物や戦いの関係をデータベースで表現してみます。
| テーブル名 | 目的 |
|---|---|
countries（国） |
キャラクターの所属国 |
characters（人物） |
登場キャラの名前と所属国 |
battles（戦い） |
戦いの名前と勝敗 |
character_battles（人物×戦い） |
誰がどの戦いに参加したか、役割も含めて記録 |
このように 「エンティティ」を洗い出し、それらの「リレーション」を整理すること が、
データベース設計の第一歩です。
STEP2.SQLでテーブルを作成する
次に、それぞれのテーブルをSQLで定義していきます。
SupabaseではGUIでも作成できますが、せっかくなのでSQLで構造を理解してみます。
「SQLエディター」から新規でコードを書いて実行
以下は今回のサンプルSQLコードです。
この辺りがわからなかったら生成AIと対話すれば良いかと思います。
-- 国テーブル
CREATE TABLE countries (
id SERIAL PRIMARY KEY,
name TEXT NOT NULL
);
-- キャラクターテーブル
CREATE TABLE characters (
id SERIAL PRIMARY KEY,
name TEXT NOT NULL,
country_id INTEGER NOT NULL REFERENCES countries(id)
);
-- 戦いテーブル
CREATE TABLE battles (
id SERIAL PRIMARY KEY,
name TEXT NOT NULL,
outcome TEXT NOT NULL
);
-- 人物×戦いテーブル
CREATE TABLE character_battles (
id SERIAL PRIMARY KEY,
character_id INTEGER NOT NULL REFERENCES characters(id),
battle_id INTEGER NOT NULL REFERENCES battles(id),
role TEXT
);
上記のSQLで以下のER図ができました。
テーブル間のリレーションが直感的にわかるかと思います。
紀元前にこの仕組みがあれば、李斯や昌文君も泣かなかったことでしょう。
STEP3.データを追加してみる
テーブルができたら、実際にデータを追加してみましょう。
こちらも先ほどのテーブル同様SQLエディターで実行してみます。
-- 国を登録
INSERT INTO countries (name) VALUES
('秦'),
('趙'),
('魏');
-- キャラクターを登録
INSERT INTO characters (name, country_id) VALUES
('信', 1),
('王騎', 1),
('李牧', 2),
('廉頗', 3);
-- 戦いを登録
INSERT INTO battles (name, outcome) VALUES
('馬陽の戦い', '秦の勝利'),
('函谷関攻防戦', '秦の勝利');
-- 戦いへの参加記録（人物と戦いのリレーション）
INSERT INTO character_battles (character_id, battle_id, role) VALUES
(1, 1, '将軍'), -- 信
(2, 1, '兵士'), -- 王騎
(1, 2, '指揮官'); -- 信
テーブルが作成できました。
国テーブル
キャラクターテーブル。あとから気づいたのですが信が将軍になり、王騎が兵士になってしまいました
戦いテーブル
戦いへの参加記録テーブル
ここまでできれば、データベースがしっかり構造をもって情報を管理していることが実感できるはずです。
データベースの本質は、「整理して、繋げて、必要なときに取り出せること」 にあります。
たとえば先ほどのテーブルも本気で整理していくと、
「秦のキャラクターがどの戦いに参加してどうなってか？」という問いにも、
SQLで簡単に答えを出せるようになります。
キングダムは話数も多いし将軍も次々出てくるのでありがたいですね。
私は羌瘣が早く幸せになって欲しいです。
まとめ：この機会にデータベースをちょっと触ってみよう！
データベースの知識は、現代のIT開発において必須のスキルとなっています。
今回はSupabaseを使うことで実践的に学びながら、
以下のようなデータベースの基本概念を学ぶ方法を紹介しました。
- データの構造化と関連付けの考え方
- SQLによるデータ操作の基本
- データベース設計の視覚的な理解
これらの知識は、他のデータベースシステム（たとえばMySQLやBigQueryなど）を学ぶ際の土台にもなり、より高度なデータ分析や業務システムの理解にもつながっていきます。
とはいえ、データベースは一朝一夕でマスターできるものではありません。
テーブル設計やリレーション、正規化、インデックス、トランザクションなど奥が深く、
学ぶべきことも多くあります。
それでも、「ちょっと触ってみる」ことでしか得られない気づき があります。
本記事のように、馴染みのある題材で試してみるだけでも、
SQLやテーブル設計に対する苦手意識はぐっと減るはずです。
最初の一歩として、Supabaseはとてもおすすめの学習の入り口です。
もしこの記事で少しでも「わかるかも！」と思えたら、
次は自分なりの題材でテーブルを設計してみてください。
楽しみながら学ぶのが、いちばんの近道です！
Discussion