📚

SQL-データベース　要件定義と設計

2023/06/18に公開

SQL

tech

SQLの全体像を学習する

こんにちは、わいわわです！
最近はSQLの学習を進めています。
今回からはデータベースを導入する際の流れや構成、設計など
全体像の把握をまとめていきます！

データベースを導入する流れ

要件定義
（どのようなシステムにするか決める）
　↓
設計
（テーブルやカラムを決める）
　↓
開発
（設計した内容をもとにシステムを作る）
　↓
導入・運用
（出来上がったシステムを使い始める）

システムの開発に必要な担当者

システムを開発する際には、担当者を決めておく必要があります
・データベースを設計する人
・設計を元にデータベースを構築する人
・できあがったシステムのテストを行う人
などの役割分担が必要です。
リーダーが必要な場合もあれば、
小さなプロジェクトであれば設計から開発まで一通り1人で行う場合もあります。

導入するべきかの検討

システムの導入直後は仕事の業務フローが変わったり
新システムに移行する期間で業務を止めたりする必要が出てくるかもしれません。
その場合は担当者への教育や業務を一時的に停止させるなど対応が必要です！

デメリット
メリットがある一歩でデータベースには以下のような導入のデメリットもあります。
・時間やお金がかかる
・専門知識が必要になる
・必要に応じてメンテナンスが必要になる

導入目的も検討していく内容の一つです。
データベースによって目的が達成されるのか、メリットが享受できるのか、
デメリットと天秤にかけながら検討を進めていきます。

データベース以外の選択肢としては
・表計算ソフトでデータを管理する
・目的に合った専用のソフトや製品を買う
など、あった選択をすることが大事です。

要件定義

システム開発を行う際にはまず初めに要件定義という作業を行います。
一言でいうと、「叶えたい要望をどのように実現するかをまとめる」要件の洗い出しです。

この要件定義を行うことで
開発者やクライアントなどのシステムにかかわるメンバー全員が、現状の問題点や開発する機能の内容、完成後のシステムの操作イメージ、業務の変化を把握できあらかじめ回避できる失敗を防ぐ
ことができます。

例）メモ帳を使って手作業で行っていた売上集計を自動化させたいというユーザーの要望
POSレジを導入してバーコードで売れた商品を記録する？
手作業でコンピューターで入力する？
集計は具体的にどのような計算方法になる？
画面に表示するのか、毎日メールで送られるのか

といったように要望を叶える手段として具体的なシステム上での動作を決めていきます。
決めた内容は要件定義書としてドキュメントにまとめることが多いです。

基本的にはデータベース単体で使う用途は限られており、
おそらく多くの場合はレジやアプリ、Webサイトとｌちた他の製品やソフトと連携させます。
この要件定義のフェーズでデータベースについて決めておくことは
何のデータを保存するべきか、何のデータを出力すべきか、といった点を考えるのが中心となります。

保存すべきデータを整理するために保存対象となる実態（エンティティ）と、
エンティティが持つ詳細な項目（属性）を抽出します。

エンティティは共通した内容をもったおおまかなエータのまとまりを指しており、
言い換えるとデータの中に登場する人物やものを指します。
具体例）商品、購入者、購入履歴、店舗など
属性は例えば、商品名や価格、商品IDなどを挙げることができます。

洗い出した後はリレーションシップを考えます。
エンティティ同士の結びつきのことです。

リレーショナル型のデータベースでは複数の関連するテーブル同士を組み合わせて
データを表現することになりますので、
あらかじめエンティティ同士のリレーションシップを考えておくことで、
テーブル設計の時にテーブル同士の関係と必要なカラムを把握しやすくなります。

ER図

ER図はエンティティとリレーションシップを図で表したものです。
厳密にいうといくつか種類があり、必要に応じて
概念モデル→論理モデル→物理モデルの３層に分けて作成します。
物理モデルに近づけば近づくほど具体的になります。

ER図は作成しなくても設計できますが、これを見れば
どんなデータがあってデータ同士がどんな関係かを一目で把握することができるようになるため
データベース構築が円滑に進められるようになります。

ER図はスクールに通っていた時も何度か作成しました。
私のPF作成時に作ったER図を載せておきます！
イメージはこのような形になると思います。

データの正規化

正規化は一言でいうと、データベース内のデータを整理する手順のことです。
正規化を行うメリットとしては
・データのメンテナンスが楽になる
同じデータが複数の箇所に散らばっていることがなくなるため、変更したい場合の修正が最小限になる
・データの容量を減らせる
無駄なデータの重複が減らせることで保存に必要な領域を削減できる
・データの汎用性が広がる
データを正規化して整理しておくことによって
他の複数のシステムとの連携やデータの移行がよりスムーズに行える

正規化の手順

正規化を行うときには段階をふんで行っていきます。

第１正規形…繰り返し出てくる項目の排除
カラムに複数のデータが入ることを防ぎます。
レコードが多くなってしまいますが、ここでは問題ありません。

第２正規形…データを管理しやすくする
カラムに対応して値が決まる従属関係のカラムがある場合はそれを別テーブルに分離させます。
別の種類のデータを分けて管理することができ、データの登録や編集が行いやすくなります。

第３正規形…不整合を防ぐ
従属関係をとる除くことで同じデータが複数のレコードにまたがって登録されるのを防ぎます。。
第２正規形からさらに従属関係にあるデータを分けたものになります。
第３正規形にすると従属関係がなくなり、データの不整合が起きるのを防ぐことができます。

カラムに設定を割り当てる

データを保存するのに必要なカラムを決めたら、
今度はそれぞれのカラムに割り当てるデータ型や製薬、属性を決める必要があります。
データ型や制約は、この記事でまとめましたね！

テーブルやカラムの名前は英数字を使うのが主流です。
また、命名規則やポイントに関して日本語は使わないという点以外にも
・他の人がみて分かりやすい名前にする
・略語を避ける
・「is」でBOOLEAN型、「at」で日時など
・先頭に数字は使わない
など、ポイントがあります。

また、シノニム（別の名前なのに同じ意味を持つ言葉のこと）や
ホモ二ム（同じ名前なのに別の意味を持つ言葉）は
避けて命名しましょう！

要件定義や設計は以上のようなイメージです！！

所感

本日はデータベースを導入する際、およびシステム開発をする際の
流れなどを学習していきました。
これから実際に実務に当たるうえでまたイメージが深まりました。
何気なくＰＦでもやっていたことですが、改めてしっかりした機能をつけたシステムを開発しようとするとより重要ですね！