【T7b】複数のモデルクラスの連携(4/9)
| プロジェクトタイプ | (注意: 本文参照) |
|---|---|
| プロジェクト名 | T7b |
| ソリューション名 | PIT7 |
注意
- 本ページの作業内容は 前のページまでの続き になっていることに注意せよ．
- 先に前のページまでをすべて読み，指示されている作業を済ませてから本ページを読むこと．
- プロジェクトの作成作業については準備作業を参照せよ．
7b-4. モデルクラスとデータベース上の制約
本節では複数のモデルクラスを連携させる方法を学ぶが，そのまえに一つ説明しておかなければならないことがある． 通常のリレーショナルデータベースでは，テーブルの各列に 制約 を設定することが可能である． 制約とは その列のデータが満たさなければならない条件 を課すものである．条件を満たさないデータによって レコードの作成や更新をしようとすればエラーとなる．代表的な制約として_のような制約がある．
| 名前 | 標準SQLにおける文法 | 意味 |
|---|---|---|
| 主キー制約 | PRIMARY KEY | 一意制約とNOT NULL制約の両方を課すもの． |
| 一意制約 | UNIQUE | その列に含まれるデータに重複があってならない． |
| NOT NULL制約 | NOT NULL | その列のデータは空値(NULL)であってはならない． |
| 外部キー制約 | REFERENCES テーブル名 (列名) | その列に含まれるデータはテーブル名で示されるテーブルの列名の列のいずれかの値でなければならない． |
NOT NULL制約，すなわち「そのデータが必須か否か」に関しては第05回の例と同様に，プロパティの型 (Null許容な型であるか否か)から自動的に推定される． では主キー制約に関してはどうなっているだろうか． pgAdmin で確認してみよう． pgAdmin で「 Servers 」→「 PostgreSQL 16 」→「 Databases 」→「 t7b_db 」→「 Schemas 」→「 public 」→「 Tables 」以下にある Students テーブルを右クリックして 「 Properties 」をクリックする(_)．すると Students テーブルについての詳細情報を表示する子ウィンドウが開くので 「 Columns 」タブをクリックする．この画面がこのテーブルに定義されている列の一覧である(_)．
_の Not NULL? の列は，その列にNOT NULL制約が課せられているかどうかを示している．
Mail列，Birthday列，MiddleName列以外はすべてYesと表示されていることが分かるだろう．
Studentsクラスの定義では，これらのプロパティはNull許容型(?つきの型)として定義したため，
NOT NULL制約は課せられていない．
では_の Primary key? の列を見てみよう．この部分は各列に主キー制約が課せられているかどうかを示している．
この部分はId列のみが唯一Yesと表示されていることが分かるだろう．つまりId列が主キーとして認識されている．
Studentクラスには複数のプロパティが存在してるが，EF Core はどのようにして どのプロパティが主キーとして扱われるべきなのか を
判断しているのだろうか？
実はどのプロパティが主キーであるかということは，EF Core では主に プロパティの名前から判断されている ． 詳細についてはKeys - EF Core - Microsoft Docsに 説明を譲るがざっくり説明すると以下のようなルールである．
- EF Core が主キーを識別するルール
- 以下のいずれかに合致するプロパティは主キーである．
- そのプロパティが大文字小文字を問わず
Idという名前である． - そのプロパティが
型名Id - そのプロパティに
[Key]属性が付加されている．
- そのプロパティが大文字小文字を問わず
- 以下のいずれかに合致するプロパティは主キーである．
Studentクラスの場合は上記の1.に当てはまるため，特に何も指定しなくても主キーとして認識される，というわけである．
ちなみに，ここまで見てきたようなプロパティの型や名前から，データベース上の制約やフォームにおけるチェックなどを識別するルールのことを，
EF Core では コンベンション (convention≒慣習)と呼ぶ．
外部キー制約もこのようなコンベンションによって表現することになる．次節では「学生」に加えて「学科」を表すモデルクラスを定義して， これらに一対多の関係を持たせる方法について学ぶ．