梯はしこです。
昨日の深夜に8章の解説部分をさらりと読んで、今朝章末問題を解きました
その結果。
16問中12問正解…
相変わらず正答率が低いのです
8章はページ数が多いなと思っていたのですが、業務で経験したことも多かったので、
いけるいける
とサクサク進んでいたら、甘かった…
さっそく復習していきます。
８章の概要
８章のタイトルは、スキーマオブジェクトの管理。
スキーマとは何か？という説明から始まって、その後は表のデータ型や制約の話。さらに表の作成・削除と進み、これまで何度も登場した「索引」とビューの解説。
７章まではデータベース管理者よりのお話でしたが、８章はアプリケーション開発側のお話だなと思いました。
（一応）システムエンジニアである私は、がっつりかかわる部分
Bronze試験以前に、仕事をする上で知っておかねばならないことばかり。
しっかり復習していきます
スキーマとは
表や索引などのオブジェクトは、作成したユーザーの所有者として紐づきます。
ユーザーを作成したとき、ユーザー名と同じ名前のスキーマなるものも同時に作成されます。
たとえばキツネユーザーを作成する場合。
キツネユーザーを作成すると、同時にキツネスキーマが作成されます。
そしてそのキツネユーザーが表を作ったとき、その表はキツネスキーマに格納される仕組みです。
スキーマには名前空間としての役割があります。
たとえば「キツネ」くんのお道具箱と「タヌキ」くんのお道具箱には、同じように「のり」と「はさみ」が入っています。
どちらも同じ「のり」と「はさみ」で、お道具箱から出してしまえば誰のものかわかりません。
しかし「キツネ」くんのお道具箱に入っている「のり」や「はさみ」はキツネくんのものです。わざわざ「のり」や「はさみ」に名前を書いておかなくても、きちんと区別できますね。
話は変わって、ここで１つ疑問が。
今まで勉強してきた「表領域」はどこに行ったの
オブジェクトの格納先に指定する場所が表領域。
ちなみに表領域の実態がデータファイル。
ユーザー所有のオブジェクトを格納するのがユーザーのスキーマ。
ややこしや。
chatGPTに聞いてみましたよ。
質問内容。
Oracleデータベースにおける表領域とスキーマの違いを教えてください。 表領域の中にスキーマがあるイメージで良いですか。
いただいた回答はかなり長いので一部省略しますが、このような内容。
Oracleデータベースにおける「表領域」と「スキーマ」は、異なるコンセプトであり、それぞれ異なる役割を果たします。
（略）
表領域は、Oracleデータベースにおける物理的なデータの格納領域を管理するための概念です。
データファイルは表領域ごとに割り当てられ、データオブジェクトはそれらのデータファイル内に格納されます。
（略）
スキーマは論理的な構造であり、物理的なデータの格納場所ではありません。スキーマ内のデータオブジェクトは、対応する表領域に格納されます。
要するに、表領域はデータベースの物理的なデータの配置を管理し、スキーマはデータベース内でデータオブジェクトを論理的にグループ化するための名前空間です。
表領域内にスキーマがあるというイメージは、スキーマ内のデータオブジェクトが特定の表領域に配置されることを意味しますが、それらは異なるコンセプトであり、別々に管理されます。
ちょっと難しいですね。
表領域は実態であるデータファイルとの紐づき（配置）を管理して、スキーマはあくまでも「このオブジェクトは誰のもの」というものを管理する、ということでしょうか
制約について
表に格納するデータについて、
こういうデータを入れたらダメよ
という制限をするために、表の列または列の組み合わせに対して、制約を設けることがあります。
- NOT NULL制約
- UNIQUE制約
- PRIMARY KEY制約
- FOREIGN KEY制約
- CHECK制約
NOT NULL制約
UNIQUE制約
というものになります。
実際には名前や電話番号をPRIMARY KEYに設定することはあまりよろしくありません。本来であれば最初の例のように絶対に一意になる「番号」などの列を作成し、それを主キーにするのがよろしいかと。
FOREIGN KEY制約
FOREIGN KEY制約は外部キー制約とも呼ばれます。
リレーショナルデータベースは、その名の通り関連する表と表が紐づく構造になっています。
関連する表と表を紐づけるために登場するのが、FOREIGN KEY制約です。
FOREIGN KEY制約を設定することで、関連するほかの表のデータに対応していることがわかります。
たとえばこういう社員表があったとして。
これだけだと、社員たちがどこの部署に属しているのかよくわかりませんね。
そこで、部署表を見てみましょう。
部署表を見ることで、部署コード01番のタヌオは総務部、02番のはしことフォ吉は開発部に属していることがわかります。
社員表の部署コードのように、
関連する表の列がキーになっていますよ
というのがFOREIGN KEY（外部キー）です。
部署表の部署コードのように、
関連する表から見られていますよ
というキーのことを参照キーと呼びます。
また、社員表のように外部キーを持つ表のことを「子表」、部署表のように参照キーを持つ表を「親表」と呼びます。
子表は親表に従っています。
たとえば、新しい社員に「ピンク先生」が加わったとしましょう。
彼は社員教育をする「教育部」という新設された部署に所属してもらいたいと思っています。
さっそく社員表にピンク先生を追加。社員表の部署コードを04に設定して…
というのはNGです。
子表の外部キーには親表に存在する値しか入れることができません。
つまりこの場合、先に親表である部署表に部署コード04の教育部を追加してから、子表である社員表にピンク先生を追加することになります。
と、いうことは。
部署表に部署コード01の行が複数存在していたり（重複）、部署コード02の行を削除してしまったりしたらどうなるでしょう。
社員表の部署コード01がどの部署を指し示しているのかわからなくなりますね。部署コード02が親表に存在しないというのもまずい
そこで、参照キーにはUNIQUE制約またはPRIMARY KEY制約を設定する必要があります。これにより親表の重複問題は解決。
参照キーの更新やデータの削除などを実行したときには、エラーが発生します。親表に値がない問題は発生しないというわけですね。
CHECK制約
個人的にあまり馴染みがなかったのがCHECK制約。
指定した条件を満たす値を入れるようにするのがCHECK制約です。
つまり具体的に「NULLはダメ」とか「一意でなければダメ」とかいうものではなく、表を作成するユーザーが独自に作成できる制約ということですね。
たとえば
- メールアドレスは「@」が入っていないとダメ
- 郵便番号は7桁ぴったりでないとダメ
- 商品価格は100円以上でなければダメ
所感
8章はまだまだありますが、長くなってしまったのでいったんこの辺で区切りといたします。
残りは
- 表の削除
- 索引とビュー
- データ作成のためのツール