#【概要】
Djangoのアーキテクチャの一つM(モデル)の基礎知識と構築の記事です。
【具体的な内容】
1 モデルの役割
2 DB(データベース)について
3 実際のModels.pyのコード例
#【1 モデルの役割】
モデルはWebAPPにおけるDB(データベース)の役割を与えられています。
Djangoの全体の中でModelがどのように関わるかを以下に記載します。
・全体の流れ
ブラウザからのリクエスト → Webサーバー → ミドルウェア → URLディスパッチャ → View → URLディスパッチャ → ミドルウェア → Webサーバー
簡単にまとめると、ブラウザの操作がviewへ届き操作のフィードバックがブラウザに反映されます。この中でモデルはユーザの操作によってDB内部のデータを作成・更新・削除などを行ったり必要な時にviewへデータを渡す役割を担っています。
Viwe ← → Model
####・Django Object-Relational-mapper
DjangoはDjango ORMapperと呼ばれるマッパー機能を提供しており、「DBにおけるテーブルとカラム定義」と「モデルにおけるクラス属性の定義」を対応させています。
これにより、SQL文を使わずにSQLコマンドを使用したり、DBの種類における違いを吸収してくれます。
#【2 DB(データベース)について】
・DBの構造
最上位の単位はデータベース
その下に複数のテーブル
テーブルの中にデータの項目と各データが格納されています。
・Djangoの中でDBやテーブルは。
Djangoプロジェクトの中にModelはDjangoのアプリケーションの数だけ存在します。
Model(models.py)の中にはclass化されたテーブルを用意し
自分はDjangoを学び始めていた時はDBについてあまり知らず経験もない状態で、その状態で開発を進めると後でモデルの構造がスパゲティ状態になることがありました。保守性と拡張性に問題が出るため、良いとされるDB構造を学ぶことを推奨します。
#【3 Models.pyのコード例】
学校の生徒の管理用のアプリケーションを実装する場合を想定します。
以下、生徒のデータを管理するためにStudentテーブルを作成したい場合の例です。
※idのAutoFieldはデータ作成時に自動的にDjangoから生成されるIDの値です。
from django.db import models
class Student(models.Model):
id = models.AutoField(primary_key=True)
name = models.CharField(max_length=256)
この状態でターミナルツールでマイグレーションを行うことで、プロジェクトのDBにStudentテーブルが追加されます。
python3 manage.py makemigrations
python3 manage.py migrate
部活テーブルを追加する場合はclassをmodels.pyに追加します。
class ClubTeam(models.Model):
id = models.AutoField(primary_key=True)
name = models.CharField(max_length=256)
生徒データに部活のデータを紐づけた管理をしたい場合はstudentクラスを以下のように編集します。
from django.db import models
class Student(models.Model):
id = models.AutoField(primary_key=True)
name = models.CharField(max_length=256)
club = models.ForeingKey(Clubteam, on_delete=models.CASCADE)
clubのForeingKey(...)は外部キーを取得したい場合の書き方です。
これ何が変わったのかというと、外部キーというものを使って部活テーブルのデータのidを生徒のclubカラムへ格納してます。
データ同士に関係性がある場合にDBで「一対一」「多対一」「多対多」のリレーションを定義したりします。
「DB リレーション」などで調べると色々出てきます。
ForeingKey(...)は多対一
OneToOneField(...)は一対一
ManyToManyField(...)は多対多の構造の時の書き方です。
on_delete=CASCADEは引っ張ってきた元データが削除された場合このデータも削除されるというオプションなのですが、ほかにどんなオプションがあるのか調べるとDBの構築の一助になるかと思います。
こうすることで、部活テーブルに変更があった場合でも生徒テーブルのデータも連動します。
例えば野球部が廃部した場合、部活テーブルのnameがbaseballの部活が削除されます。
生徒テーブルの元野球部員たちは部活テーブルのbaseballの削除に伴い、自動的にclubの中身が空白になります。
便利ですよね。
DBに明るくない方はモデル構築の前に基礎知識を調べてイメージを固めてください。
自分は、なぜ外部キーが必要なのか知らなかった時期にモデル構築をしたせいで後々大改修が必要になりました。
あるテーブルの特定の列のデータが削除されたら、他テーブルのデータを削除するみたいな処理を延々作ってました。
超アホです。
自分ならこんな人と一緒に仕事するの怖いです笑
こんな風にならないためにDBの基礎知識は学習し、データ同士の関係性などは実装前にきっちり設定しましょう。