3層スキーマを調べたので書きました。
こんにちは、しょうteeです。
今回もDB設計について勉強したことをアウトプットしていきます!!
今回は「3層スキーマ」について調べてみました。
スキーマとは
そもそも「スキーマ(schema)」とはどういう意味か??
スキーマ とは、「枠組み」、「構図」
そして、データベース設計においては、
データベースのデータ構造やフォーマット
という意味とのこと。
この「スキーマ」は、一般的に3つのレベルに分けられる。
これら3つのスキーマに基づいたシステムを、「3層スキーマ」という。
具体的に1つずつスキーマ見ていく。
1. 外部スキーマ
ユーザーから見たデータのことを指す。
「画面やビュー」のこと。
このように、IDや教科名などを「見せるために加工したデータ」を、ユーザーが最終的に使うためのデータ構造を「外部スキーマ」という。
2. 概念スキーマ
外部スキーマをDB上で扱いやすくするために「重複の排除や項目の分割」などを行なったものを指す。
外部スキーマが「ユーザーから見たデータベース」とすれば、概念スキーマは「開発者から見たデータベース」ともいう。
また、データベースにテーブルを作成するための「設計図」ともいう。
3. 内部スキーマ
「内部スキーマ」は、概念スキーマで定義されたデータを具体的にどう格納するかを定義するもの。ハードウェア的な変更はここで吸収する。
「DBMSから見たデータベース」である。
内部スキーマの設計を、「物理設計」という。
※「論理設計・物理設計」については別の記事で書いていきます。
RDBもコンピュータ上で動く以上は、あらゆるデータは最終的に「ファイル」の形で管理されるので、「ファイルで表現される世界」と考えると良いとのこと。
概念スキーマは何のためにあるのか？
概念スキーマは？？
結論：内外部スキーマの緩衝材の役割を果たす
もし「概念スキーマ」がないと、変更に対する柔軟性がなくなるとのこと。
ユーザーが、「データの見え方を変えたい!!」と思った場合、外部だけでなく、内部のスキーマまで変更しないといけない。逆も然り。
2つだけのスキーマだとしたら、独立性が低く、依存性が高くなるため、変更に弱いシステムが出来上がってしまう。
概念スキーマは、外部スキーマと内部スキーマの間に立ち、両者の変更が互いに影響し合わないようにするための中立の立場である。
これらのスキーマの独立性のことをデータ独立性といい、
という。
まとめ
- 3層スキーマとは、以下の3つの概念がある。
1. 外部スキーマ（外部モデル）＝ ビューの世界
2. 概念スキーマ（論理データモデル）＝ テーブルの世界
3. 内部スキーマ（物理データモデル）＝ ファイルの世界
- DBの観点から見ると、
外部スキーマは「ユーザから見たデータベース」
概念スキーマは「開発者から見たデータベース」
- 概念スキーマは何のためにあるのか？
外部スキーマと内部スキーマ同士では独立性が低いため、変更に弱いシステムができるために概念スキーマが必要。
最後に
今回もざっくりではあったのですが、勉強したことをアウトプットしてみました。
記事に書く前は「スキーマ」という言葉自体よく分かってなかったのですが、調べたこと（インプット）を書くこと（アウトプット）によって頭の中も整理され、少しずつ「理解」へとつながっていきました。
最後まで読んでいただき、ありがとうございました😊
よく分かっていなかったシステム開発の工程について調べてみた
こんにちは、しょうteeです。
現在システム開発の会社で働いている駆け出しエンジニアです。
僕は未経験から転職する際に当時ポートフォリオを作っていました。
自分の作りたいと思うものを開発していたのですが、プログラミングの勉強ばかりしていて、開発工程や設計についてそこまで意識していませんでした。
今回は自身で理解をしていくためにも、まとめてみることにしました。
1. そもそも、システム開発の工程って？
何となく理解していただけだったので書きます。
システム開発の工程はレシピのようなもの。
例として、家でカルボナーラを作ることを想定します。レシピには食材、調味料、作り方などが載っており、順番に進めていけばカルボナーラができる！
これと同じで、開発工程のおかげで、必要な人を集め、計画通りにシステム開発を進めることができるとのこと。
2. システム開発の工程について
いくつかのステップに分けることができますが、一般的に大きく分類すると以下の4つになります。
- 要件定義
- 設計
- 開発（実装）
- テスト
1つずつ簡単にまとめてみます。
（1）要件定義
システムが満たすべき機能やサービスの水準などの要件を決める工程のこと。
この要件をもとに、予算や人員、期間を計画していく。 この際にシステム開発を行う目的やターゲットについて打ち合わせを行う。
（2）設計
定義された要件を満たすために必要なシステムを作るための設計を行う工程のこと。
設計には外部設計と内部設計がある。
（3）開発（実装）
設計書に従ってシステムを実際に作る工程のこと。
内部設計である程度プログラミングの設計ができたら、プログラマによるコーディングや、サーバーやネットワーク機器などのハードウェアの調達や環境構築といった作業を行なっていく。
（4）テスト
実装によって組み上がったシステムが、本当に納品できるのか、エラーが出たり機能が停止したりしないのかを試験（テスト）する工程のこと。
テストを行う順番があり、
これらの「要件定義」〜「テスト」までの工程は、システム開発における最も基本的な分類であります。
3. 設計工程と開発モデル
システム開発の進め方（開発モデル）には、大きく分けて2つある。
(1)ウォーターフォールモデル
「滝(waterfall)」という名前の通り、
- 要件定義
- 設計
- 開発（実装）
- テスト
というように一つずつ工程を踏んで、段階的にシステムを作っていく開発のこと。
滝が逆流することのないように、一度進んだ工程が戻ることはないそう。
大規模なシステム開発に採用されることが多いが、手戻りがきかないので各工程で精密度の高い仕上がりが求めらるとの事。
（2）アジャイルモデル
「俊敏な」という意味もあり、初めから厳密な仕様を決めずにおおよその仕様だけで細かい「実装→テスト実行」を繰り返して徐々に進めていく開発のこと。
アジャイル開発に代表的な手法が3つあり、
ユーザー機能駆動開発（FDD）
不具合が発覚した際に戻る工数が少なく、小さな単位で計画から設計、実装、テストを繰り返しているため、問題が発生しても一つの小さな計画の中で戻る分の工数で済む。
しかし、厳密な仕様を決めていないため、開発の方向性がブレやすいこともある。そのために変更や追加を加えていくことで当初の計画からズレていくこともあるため注意が必要。
詳しい内容は勉強して別の記事に書いていきます。
4. 最後に
今回は大まかに調べていきました。システム開発の工程について大枠では理解しましたが、細かい所までと言われると、正直まだまだですね😦
これから実務で実際にやっていくと思いますが、仕事以外でも本を読み、学習もしていこうと改めて思いました。
今回が初めての記事になりましたが、最後まで読んでいただきありがとうございました🙇♂️
