システム開発のプロジェクトをスムーズに進行し、完成度の高いシステムを構築するためには、要件定義・プロジェクト立案・設計工程といった初動プロセスが非常に重要となります。
会計業務や生産業務に使用される業務系システムにはデータを格納・管理するためのデータベースが欠かせませんが、データベースの設計に活用されるドキュメントのひとつが「CRUD図」です。
当記事では、システム開発における設計書作成の必要性から、CRUD図の概要・書き方、CRUD図を用いたCRUD分析の方法・活用法までをご紹介します。
システム開発におけるCRUD図の役割について知りたい方や、実際の業務でCRUD図を有効活用したい方は、ぜひ参考にして下さい。
CRUD図とは?
CRUD図とは、システムを構成するデータに対する主要な機能を表形式で示した、CRUD分析で使用される図のことです。
CRUD図では、以下4つの機能を図示します。
- Create:登録機能
- Read:参照機能
- Update:更新機能
- Delete:削除機能
これら4つの機能の頭文字「C」「R」「U」「D」を取って、CRUD図と呼ばれています。読み方は「クラウド図」ではなくて「クラッド図」です。
CRUD図を活用してCRUD分析を行うことは、データと処理の関係を明確化することで機能の抜け漏れや矛盾といった設計上の課題を速やかに発見できるため、データベース設計において非常に重要かつ効果的な手法といわれています。
続いて、CRUD図の具体的な書き方について以下にご紹介します。
CRUD図の書き方
CRUD図は、UML図のように統一化・標準化された書き方がありません。一般的には表形式のマトリックス図を作成して、システムの主要機能とエンティティが交差する部分に「C」「R」「U」「D」の4つの記号を記述することで表現します。
CRUD図の書き方で多く用いられるモデルケースを、以下にご紹介します。
エンティティA |
エンティティB |
エンティティC |
|
機能1 |
C |
R |
|
機能2 |
U |
C |
C |
機能3 |
R |
R |
R |
機能4 |
D |
このように、CRUD図を作成すると、それぞれのデータ(エンティティ)に対してどの機能が働いているか、また機能の有無を一覧で把握することができます。
例えば、上記の表でエンティティAが商品名、機能2が商品名変更機能であったとすると、交差する部分には「U(Update):更新」の記号が記述されます。
データベースの仕様は複雑になりやすいため、過不足なく完成度の高い設計を行なうためには、視覚的にデータと処理を把握して検討できるCRUD図の活用は必須と言えるでしょう。
あわせて考えられる要素
CRUD図は単体で使用されるケースもありますが、システムの設計工程では他の図とセットで使用されるケースも多くあります。
ここでは、CRUD図とセットで使用されることが多い「DFD」と「ER図」について、それぞれの図の概要とどのようにCRUD図と併用されるかを解説します。
DFDとER図についての理解を深めておくことで、CRUD図をより効果的に活用したり、システムやソフトウェアの設計スキルを高めたりすることが期待できるため、ぜひ参考にして下さい。
DFD
DFD(データフロー図)とは、システムの機能ならびにシステムで扱うデータの流れを示した図のことで、システム設計手法の一種である構造化分析で用いられるツールのひとつです。「データフローダイアグラム」「データフローグラフ」と呼ばれることもあります。
DFDは名称の通りデータの流れを視覚的・直感的に把握できることが特徴で、システムの設計工程をはじめ、業務フローの分析やクライアントへの説明などにも活用されます。
DFDは、以下4種類の記号を用いて、一定の書き方のルールに基づいて作成されます。
・データフロー(矢印)
データの流れを矢印で示す。
・プロセス(円)
データの加工を行う部分で、該当部分を円で囲んで示す。
・データストア(二重線)
一時的なデータ保管場所のことで、二重線で表現する。
・源泉と吸収(長方形)
システム外部の人や組織のことで、源泉はシステムにデータを渡してくる発生源、吸収はデータをシステムから受け取る吸収先を示す。
システムで扱うデータに対する機能の有無をまとめた表であるCRUD図は、処理とデータの関係は明らかとなりますが、どのような流れでデータが処理されるかというプロセスを把握することは苦手とします。
そのため、システムの設計工程では、システムの要件や仕様を明確化するために、DFDとCRUD図を併用するケースが多くあります。
ER図
ER図とは、データベース設計の際に使用される基本的な設計手法のことで、データ構造・マスタ分布・データ整合性を把握・確認するために活用されます。
ER図には10種類近くの書き方がありますが、「IE記法」と「IDEF記法」と呼ばれる2種類の記法が主に使用されています。
ER図は、以下3つの構成要素を組み合わせて記述されます。
・エンティティ
マスタ・テーブルを構成するデータのまとまりのこと。
・アトリビュート
エンティティ内の属性情報のこと。
・リレーション
エンティティ同士の関係を示し、カーディナリティと呼ばれる記号で表現する。
ER図はデータモデリングを行う際の標準的な手法として活用されていますが、データの生成や更新が行われるタイミングを表現することができません。
そのため、ER図の欠点を補う形でCRUD図を併用するといった使い方が一般的に行われています。
CRUD分析とは?
CRUD分析とは、CRUD図を用いて「C(Create:作成)」「R(Reference:参照)」「U(Update:更新)」「D(Delete:削除)」という4つの機能のライフサイクルを分析することをいいます。
CRUD分析を行うことで、各機能の稼働状況やアプリケーションの特性を把握することができるため、適切なシステム運用に役立てることができます。
CRUD分析の活用方法について、以下に解説します。
CRUD分析の活用方法
CRUD図は通常データベースの設計やデータ整合性の検証など、システム開発時に活用される図ですが、CRUD分析は、各機能の稼働状況やアプリケーション特性を把握することで、適切な運用方法を見いだすためにも活用されます。
具体的には、データの保存期間・リカバリーポイントの決定などが挙げられます。
CRUD図を活用して、データの保存期間ならびにリカバリーポイントの決定がどのように行われるかについて、以下にモデルケースを紹介します。
データの保存期間
システムを運用していくにあたっては、業務利用ならびに障害発生時のリカバリーのために、バックアップメディアにデータを保存する必要があります。
しかし、バックアップメディアの容量も無限ではないため、どのくらいの期間のデータを保存すれば上記要件を満たせるかを検討することが重要です。不必要にバックアップメディアの容量を大きくすれば、システム運用のコストを圧迫してしまいます。
そこで活用されるのが、CRUD分析です。データ量やデータ利用頻度などのシステムの稼働状況を分析することで、根拠に基づいた適切なデータ保存期間ならびにデータ削除のタイミングを導き出すことができます。
CRUD分析の結果や予算を基にバックアップメディアの容量を決定すれば、実用性とコストパフォーマンスを兼ね備えたデータ保存の仕組みを構築することが可能となります。
リカバリーポイントの決定
システムやデータベースに障害や異常が発生した際には、バックアップメディアに保存されているデータを用いて、障害や異常が発生する前の状態に復旧を行います。
リカバリーポイントとは、過去に遡ってデータ復旧が可能となる任意の地点のことです。リカバリーポイントは定期バックアップ実行時や業務の区切れなどで設定されますが、適切なリカバリーポイントが設定されていないとシステム運用上の弊害が生じます。
例えば、リカバリーポイントを多く作り過ぎるとバックアップメディアを圧迫しますし、少なすぎると空白部分の業務を再度行わなければならないなど、障害や異常が発生した際にスムーズな復旧ができなくなります。
CRUD分析を活用すれば、システムの特性・稼働状態・データのライフサイクルを細かく分析できるため、システム運用とバックアップメディアの容量双方のバランスを考慮した、最適なリカバリーポイントを決定することが可能です。
システム運用において発生する障害や異常は、早期発見できるケースだけでなく、過去に遡って追跡する必要があるケースもあります。体感で判断できないパターンも含めて根拠のあるリカバリーポイントを検討するには、CRUD分析を活用するのが得策と言えるでしょう。
なぜCRUD図を作成するのか
CRUD図はシステム開発に必要な設計書の一種です。システム開発を成功に導くためには設計工程が重要であると冒頭で述べましたが、設計の情報を開発メンバーや顧客と共有するために必要となるのが、CRUD図などの各種設計書です。
システム開発の設計書は、具体的には以下のような用途で使用されます。
システムの完成イメージを共有する
システム開発においては、完成後のイメージを開発メンバーおよびクライアントと共有して、コンセンサスを得ることが重要です。もし完成イメージの共有ができていなければ、要件と異なるシステムができあがったり、必要以上の修正が発生したりするリスクがあります。
口頭での情報共有には限界があり、また認識の齟齬がどうしても発生するため、システムの完成イメージを高レベルで共有するためにも、各種設計書は必要不可欠となります。
プログラマーへの指示
プログラマーは、システムエンジニアが作成した設計書を基にプログラミングを行います。設計書が細部に至るまで詳しく記述されているからこそ、要件・仕様通りのプログラミングを行なえると言っても過言ではありません。
反対に、設計書が無い場合や詳細に作成されていない場合は、プログラミングを進めるにあたって膨大なコミュニケーションが発生することとなり、開発効率が低下します。
設計工程だけでなく開発工程の正確性・効率性・合理性を高めるためにも、設計書の作成は必須と言えるでしょう。
保守・運用の負担軽減
システム開発に携わったメンバーと完成後の保守・運用に携わるメンバーは、必ずしも同じメンバーであるとは限りません。むしろ、違うメンバーとなることの方が多くあります。
保守・運用の業務を行う際に、設計書があればシステムの要件や仕様をスムーズに把握することができるため、保守・運用に係る負担を軽減することが可能です。
しかし、設計書が無ければ、障害や異常が発生した際にソースコードを解析する必要があるため、保守・運用の負担や工数が大幅に増して、業務効率が悪化してしまうでしょう。
設計書は設計工程・開発工程のみで活用されるイメージがありますが、保守・運用まで含めて全般的に使用される重要なドキュメントとなります。
システム開発に使用される設計書は、テキストベースのドキュメントだけでなく、視覚的に分かりやすい図表を用いたドキュメントが多く用いられます。CRUD図もそのうちのひとつです。
当記事では、業務系システム開発に必須のデータベース設計に活用されるCRUD図について解説していきます。
まとめ
CRUD図は、データベースの仕様や機能を把握・整理する上で非常に重要なドキュメントです。CRUD図の概要から活用方法までをご紹介してきましたが、CRUD図がシステム設計・開発においてどのような役割を持つかご理解いただけましたでしょうか。
CRUD図の活用は、システム設計・開発に活用される他のドキュメントと同じく、ミスやトラブルを減らして工数を短縮するためにも、作成することが望ましいと言えるでしょう。
システム開発における各種設計書は、WordやExcelといった汎用ツールで作成した設計書でも構いませんが、専用のCADツールを導入することで設計・開発プロセス全体をシステム化して、作業効率や管理効率を大幅に高めることが可能です。
弊社が提供するCADツール「SI Object Browser Designer」であれば、設計工程を効率化・合理化してシステム開発に伴う多くの課題を解決することができるため、ぜひご検討下さい。
- カテゴリ:
- コラム