データベース設計の基本は医療関係者向けだけの内容ですか。

医療分野の例が含まれる場合もありますが、医療関係者だけに限定した内容ではありません。生成AI、AI活用、DX、業務改善、プロトタイプ開発など、一般的なAI学習の事例として読める内容です。

AI初心者でも読めますか。

はい。AIをこれから学ぶ方、数学が苦手な方、仕事でAIを使いたい方にも読み進めやすいように、教材の章と節の流れに沿って整理しています。

サムネイル画像は必ず表示されますか。

はい。教材にcoverUrlが設定されている場合はその画像を表示し、未設定の場合は代替サムネイル画像を表示します。

Flutterアプリケーション開発概論のほかの章も読めますか。

はい。教材トップから章立てを確認でき、前後の節へもページ下部のナビゲーションから移動できます。

データベース設計の基本 | Flutterアプリとデータベース連携入門｜アプリのデータを残す仕組み | Flutterアプリケーション開発概論・生成AIオンライン教材

項目	内容
教材名	Flutterアプリケーション開発概論
章	Flutterアプリとデータベース連携入門｜アプリのデータを残す仕組み
節	データベース設計の基本
カテゴリ	Flutter / iOS / Android / MacOS / Windows / 基礎から学ぶ / 開発 / アプリ開発
学習内容	生成AI、AI活用、DX、業務改善を実践しながら理解するための教材です。

この章で学ぶこと

この章では、データベースを作る前に考えることを学びます。

最初に覚えることは、これだけです。

いきなり作らない
↓
まず表にする
↓
保存したいデータを整理する

データベース設計とは、難しい作業に見えるかもしれません。

でも最初は、

何を保存するか？
どんな項目が必要か？
どの表に分けるか？

を考えるだけで大丈夫です。

11-1. いきなり作らず、まず表にする

データベースを作るときに、いきなりSupabaseやFirebaseで作り始める必要はありません。

最初は、紙やスプレッドシートで考える方が分かりやすいです。

例えば、Todoアプリなら、まずこのように表にします。

id	title	is_done	created_at
1	レポートを書く	false	2026-06-04
2	買い物に行く	true	2026-06-04

この表を見れば、Todoアプリに必要なデータが見えてきます。

まず表にする理由

表にすると、保存したい情報が整理できます。

何を保存するのか分かる
足りない項目に気づける
いらない項目を減らせる
後から実装しやすくなる

いきなりコードを書くと、途中で混乱しやすくなります。

まず表にすると、アプリ全体の設計が見えやすくなります。

11-2. どんなデータを保存するか考える

データベース設計で最初に考えることは、

このアプリでは、何を保存する必要があるか？

です。

Todoアプリなら、保存したいデータはシンプルです。

タスク名
完了状態
作成日時

でも、アプリによって保存するデータは変わります。

アプリごとの保存データの例

アプリ	保存するデータ
Todoアプリ	タスク名、完了状態、作成日時
メモアプリ	タイトル、本文、作成日時、更新日時
予約アプリ	名前、日時、予約内容、ステータス
在庫管理アプリ	商品名、在庫数、価格、カテゴリ
学習記録アプリ	教科、勉強時間、日付、メモ

アプリの種類によって、必要なデータは違います。

Todoアプリで考える

Todoアプリに必要な最低限のデータです。

カラム名	意味	例
`id`	Todoを見分ける番号	`1`
`title`	タスク名	`レポートを書く`
`is_done`	完了したかどうか	`false`
`created_at`	作成日時	`2026-06-04 10:00`

ログイン機能を付けるなら、user_id も必要です。

カラム名	意味
`user_id`	誰のTodoかを表すID

つまり、ログインありのTodoテーブルはこうなります。

id
user_id
title
is_done
created_at
updated_at

11-3. 1つのテーブルに詰め込みすぎない

データベース設計では、1つのテーブルに何でも入れすぎないことが大切です。

例えば、Todoアプリなのに、ユーザー情報まで全部 todos テーブルに入れると分かりにくくなります。

悪い例

Todoテーブルに、ユーザー情報まで詰め込んでいる例です。

id	title	is_done	user_name	user_email	user_address
1	レポートを書く	false	山田太郎	taro@example.com	東京都

この形でも動くかもしれません。

でも、Todoの表なのに、ユーザーの住所やメールまで入っています。

後から管理しにくくなります。

良い例

役割ごとにテーブルを分けます。

Todoを保存する表です。

id	user_id	title	is_done
1	user_001	レポートを書く	false

ユーザー情報を保存する表です。

id	name	email
user_001	山田太郎	taro@example.com

このように分けると、役割が分かりやすくなります。

テーブルを分ける目安

最初は、次のように考えます。

Todoの情報
↓
todosテーブル

ユーザーの情報
↓
usersテーブル

商品情報
↓
productsテーブル

予約情報
↓
reservationsテーブル

1つのテーブルには、1つの種類のデータを入れる。

これが基本です。

11-4. id・created_at・updated_atの役割

多くのテーブルでは、次の3つのカラムをよく使います。

id
created_at
updated_at

この3つは、データを管理しやすくするために使います。

idの役割

id は、データを見分けるための番号です。

Todoアプリなら、Todoを1件ずつ区別するために使います。

id	title
1	レポートを書く
2	レポートを書く

同じタイトルでも、id が違えば別のTodoとして扱えます。

id = データを見分けるための目印

編集や削除をするときにも、id を使います。

id: 1 のTodoを編集する
id: 2 のTodoを削除する

created_atの役割

created_at は、データを作った日時です。

created_at = 作成日時

例えば、Todoを作った日時を保存します。

id	title	created_at
1	レポートを書く	2026-06-04 10:00
2	買い物に行く	2026-06-04 11:00

created_at があると、次のようなことができます。

新しい順に並べる
古い順に並べる
今日作ったデータだけ見る
いつ作ったか確認する

updated_atの役割

updated_at は、最後に更新した日時です。

updated_at = 最後に変更した日時

例えば、Todoのタイトルを変更したときや、完了状態を切り替えたときに更新します。

id	title	updated_at
1	英語のレポートを書く	2026-06-05 09:30

updated_at があると、次のようなことが分かります。

最後にいつ編集したか
最近更新されたデータはどれか
長い間変更されていないデータはどれか

最初に入れておくと便利なカラム

Todoアプリなら、最初はこの形がおすすめです。

カラム名	意味
`id`	Todoを見分けるID
`user_id`	誰のTodoか
`title`	タスク名
`is_done`	完了状態
`created_at`	作成日時
`updated_at`	更新日時

ログインなしの練習アプリなら、user_id はなくても大丈夫です。

ログインありのアプリなら、user_id を入れます。

データベース設計の簡単な手順

初心者は、次の順番で考えると分かりやすいです。

1. 作りたいアプリを決める
2. 画面に表示したい情報を書き出す
3. 保存したい情報を書き出す
4. 表にする
5. カラム名を決める
6. サンプルデータを入れてみる
7. 不要な項目や足りない項目を確認する

例：Todoアプリの場合

作りたいアプリです。

Todoアプリ

画面に表示したい情報です。

タスク名
完了状態
作成日

保存したい情報です。

title
is_done
created_at

管理のために追加したい情報です。

id
updated_at

ログインありなら追加します。

user_id

完成形です。

id	user_id	title	is_done	created_at	updated_at
1	user_001	レポートを書く	false	2026-06-04	2026-06-04
2	user_001	買い物に行く	true	2026-06-04	2026-06-05

よくある失敗

いきなり作り始める

設計せずに作り始めると、あとで困りやすいです。

このデータも必要だった
このカラム名だと分かりにくい
同じ情報を何度も保存してしまった

まず表にしてから作る方が安全です。

カラム名が分かりにくい

カラム名は、意味が分かる名前にします。

分かりにくい例です。

text
flag
date

分かりやすい例です。

title
is_done
created_at

後から見ても意味が分かる名前にしましょう。

何でも1つのテーブルに入れる

最初は1つのテーブルでも動くことがあります。

でも、アプリが大きくなると管理しにくくなります。

Todoはtodos
ユーザーはusers
予約はreservations
商品はproducts

このように、役割ごとに分けると分かりやすくなります。

インストールや準備について

この章では、新しいインストール作業はありません。

ただし、実際にデータベースを作るときは、SupabaseやFirebaseなどを使うことがあります。

参考URLです。

Flutter公式インストール
https://docs.flutter.dev/install

Flutter × VS Code
https://docs.flutter.dev/tools/vs-code

Supabase Flutter Quickstart
https://supabase.com/docs/guides/getting-started/quickstarts/flutter

Firebase for Flutter
https://firebase.google.com/docs/flutter

supabase_flutter
https://pub.dev/packages/supabase_flutter

この章では、まだツールを触るよりも、まず表で考えることが大切です。

11-5. この章のまとめ

この章では、データベース設計の基本を学びました。

データベースを作るときは、いきなり作らず、まず表にします。

何を保存するか考える
↓
表にする
↓
カラムを決める
↓
サンプルデータを入れて確認する

1つのテーブルに何でも詰め込みすぎず、役割ごとに分けることが大切です。

Todoはtodos
ユーザーはusers
商品はproducts
予約はreservations

また、多くのテーブルでは、次のカラムをよく使います。

id
created_at
updated_at

ログインありのアプリでは、誰のデータかを分けるために user_id も使います。

id = データを見分ける
created_at = 作った日時
updated_at = 最後に変更した日時
user_id = 誰のデータか

データベース設計は、アプリを作る前の設計図です。

設計図があると、実装するときに迷いにくくなります。

データベース設計の基本

この節で学べること

ここから