データベース設計のステップは何ですか？

データベース設計は、アプリケーションのパフォーマンスに寄与する最も重要な要素の1つです。したがって、データベースがどれだけうまく設計されているかが最も重要です。データベース設計とは、製品のワークフロー、将来のロードマップ、予想される使用パターンに基づいてデータを効率的に整理することです。

データベース設計演習の出力はデータモデルです。データモデルは、システム内のすべてのオブジェクト、エンティティ、属性、関係、および制約を表します。大まかに言えば、データモデルには次の2つのタイプがあります。論理または物理的 。データモデルの表現は、実体関連図、ERD図、またはデータベース図とも呼ばれるER図を作成することによって行われます。

物理データモデルは、データベース内の実際の実装の詳細に関連しています。一方、論理データモデルは、実装技術を抽象化します。これにより、論理データモデルがビジネスで使用できるようになります。 2つのモデルの主な違いの1つは、論理モデルはデータベースに依存しないのに対し、物理モデルは使用中のデータベースに固有である必要があることです。

適切なデータベース設計は、アプリケーション開発中に控えめにされ、無視されることがよくあります。この怠慢のコストは、通常、新しいアプリケーション機能が導入されたとき、または古い機能を変更する必要があるときに、はるかに後で実現されます。これは、データベース設計が意味をなさなくなったときです。データベースの設計を将来にわたって保証することはできませんが、ビジネスのユースケースを最もよく理解し、それに応じてデータベースを設計する努力をすることは非常に可能です。データベース設計を改善するためのヒントについて詳しくは、こちらをご覧ください。

それを念頭に置いて、データベース設計の手順を見ていきましょう。

ステップ1：ビジネス要件を収集する

最初のステップは、要件についてビジネスと話し合うことです。会話が効果的である場合、論理モデルの抽象化である概念データモデルの作業を開始するのに十分な情報が得られるはずです。まず、ビジネスと話すことで、ビジネスプロセスの全体像がわかり、ビジネスがキャプチャして追跡するために重要なさまざまなデータポイントに関する情報が得られます。たとえば、タクシー予約モデルでは、次の質問をする価値があります。

ビジネスでは、アクティブな旅行があるかどうかに関係なく、データベースに車両追跡データが必要ですか？はいの場合、フィールドvehicle_trip_id テーブル内vehicle_trips nullable 。それ以外の場合は、 nullable にはなりません。
ビジネスはtrip_statusへの変更の履歴を望んでいますかデータベースに保存されていますか？はいの場合、毎回trip_status 変更があった場合、trips テーブル。それ以外の場合は、毎回trip_status 変更、trip_status その場で更新されます。

この例に示されているように、ビジネスからの入力に基づいて、一方のオプションを他方よりも選択することになります。その結果、関係するエンティティとその関係が変更されます。

要件の収集には、通常、マスクおよび暗号化するデータなど、データセキュリティに関する会話を開始することも含まれます。要件収集の演習の結果、概念データモデルの作業ドラフトによってサポートされることが多い要件ドキュメントが作成されます。

ステップ2：ビジネスロードマップを理解する

企業は常にプロセスを変更しています。適応する能力により、失敗する可能性が低くなります。ビジネスプロセスの変更とは、ワークフローとデータモデルの変更を意味します。これらの変更を事前に知ることはできませんが、ビジネスロードマップを最新の状態に保つことは確かに可能です。

たとえば、企業が新しい地理的地域をターゲットにする計画がある場合、モデルは言語サポート、通貨、タイムゾーンなどに対応する必要があります。長期的なビジネスロードマップを理解することの利点は、多くの場合、新しいビジネスプロセスへのスムーズな移行に現れます。

もう1つの例を紹介します。これは、継続的に進化するビジネスの優先順位に関するものです。タクシー事業は、COVID-19の初めに大きな影響を受けました。タクシー会社として、あなたは先制的に行動し、タクシーでの移動が可能な限り安全であること、車両が毎日消毒されていること、運転手がマスクを着用していることを確認するためにあらゆることをしていることを保証したいと考えています。時、そしてキャブで利用可能な手指消毒剤があること。ここで、このすべての情報を取得するために、drivers およびvehicles 、が必要になります。いくつかのブールフラグフィールド このビジネスユースケースに対応するには、これらのエンティティに追加する必要があります。

ステップ3：エンティティと属性を特定する

ビジネス要件が収集されると、その情報を使用して、重要な属性セットとともにエンティティを識別できます。通常、1つ以上のエンティティはビジネスプロセスに直接マッピングされ、それらのエンティティ間の関係もビジネスプロセスワークフローを模倣します。

このステップは、エンティティの識別子として機能する属性を識別するためにも使用されます。識別子は、物理モデルの主キーに変換されます。さらに、このステップですべての属性のデータ型を指定することも一般的です。

たとえば、タクシー予約モデルでは、予約アプリからユーザーとドライバーを登録するための必須フィールドとして機能する属性を特定する必要があります。ユーザー登録は、user_phoneを使用して行われます。ドライバーの登録は、driver_phoneを使用して行われます。。

同様に、他のエンティティと属性は、ビジネスプロセスワークフローにマッピングされた後、このステップで識別されます。

ステップ4：関係を特定する

エンティティとその属性を特定したら、次のステップは、要件収集フェーズで文書化されたビジネスワークフローに基づいてエンティティ間の関係を定義することです。 2つのエンティティ間に関係があることを確認することに加えて、次の4つのタイプの関係のどちらがそれらの間に存在するかを識別することも重要です。 AとBの2つの任意のエンティティについて考えてみます。

1対1→Aの1つのレコードは、Bの最大で1つのレコードに対応します。
1対多→Aの1つのレコードは、Bの多くのレコードに対応します。
多対1→Aの多くのレコードは、Bの最大1つのレコードに対応します。
多対多→Aの多くのレコードは、Bの多くのレコードに対応しています。

タクシー予約モデルでは、1つのタイプの関係、つまり1対多のみが使用されています。 users およびtrips 例として。モデルでは、1人のユーザーのみが旅行に関係することができるという仮定があります。これは、共有またはプールされたタクシーがないことを意味します。ただし、タクシーが共有またはプールされている場合は、users およびtrips 、多くのユーザーが同じtrip_idを共有している場合。

ステップ5：論理ER図を作成する

エンティティ、属性、およびエンティティの関係が定義されたら、次のステップはER図を描くことです。上記のすべての手順は、Vertabelo内で実行できます。参照表記を除いて、論理モデリングの実行方法に厳格な規則はありません。

たとえば、次の論理ER図の例を見てください。これは、タクシー会社のシンプルなビジネスワークフローをキャプチャし、ユーザーが車両を追跡する機能を備えた乗車を予約できるようにします。

ステップ6：論理ER図を検証する

論理モデリングは、多くのビジネス情報をデータベース設計に変換する必要があるプロセスです。徹底的なチェックを行わないと、データベース開発のこのフェーズでエラーが発生しやすくなり、後の段階で非常にコストがかかることが判明する可能性があります。

これを処理するために、Vertabeloには、論理モデルで実行できるチェックの完全なリストがあります。チェックは、モデル全体から個々の属性、およびその間のすべてに至るまで、すべての粒度で実行できます。簡単なチェックのいくつかは次のとおりです。

エンティティ、属性、関係などの名前はnullにすることはできず、一意である必要があります。
エンティティには少なくとも1つの属性が必要です。
識別子（PK）はすべてのエンティティに対して定義する必要があります。
モデルは、属性にリストされているデータ型の1つを使用する必要があります。

これらのチェックはすべてオプションであり、別の検証フレームワークが設定されている場合はスキップするように構成できます。 Vertabeloによる適切な検証は、可能な限り最小限の摩擦で次のステップに進むのに役立ちます。

ステップ7：物理ER図を作成する

論理ERダイアグラムが作成されたら、次のステップは物理データモデルを作成することです。物理データモデルは、データモデルを展開するデータベースに固有のものになります。すべてのデータベースには、命名規則、データ型、および制約の独自の実装があります。このため、データ定義言語（DDL）はデータベースごとに異なることがよくあります。

物理データモデルを作成するには、次の手順に従います。

ターゲットデータベースで最も近いデータ型を見つけて、論理データモデルで選択された汎用データ型を置き換えます。
ターゲットデータベースで規定されているテーブル、列、および制約の命名規則に従います。
事前定義されたクエリワークフローに合わせてモデルを変更します。これにより、通常、結合を保存するための冗長性が向上します。
最後に、インデックス、パーティション、配布キー、および並べ替えキーを作成できます。これは、モデルにパフォーマンスを向上させる変更を作成できる場合です。

これらの手順は、データモデルを最初から作成するために使用できる任意のデータモデリングツールを使用して実行できます。ただし、Vertabeloには、MySQL、PostgreSQL、Oracle、Microsoft SQL Server、Amazon Redshift、GoogleBigQueryなどのすべての主要なデータベースシステムの論理データモデルを本格的な物理データモデルに変換するオプションがあります。論理データモデルが物理データモデルに変換されたら、説明した4つのステップを続行できます。

Vertabeloには、モデルの非常に詳細なレベルでのコメントとともに、テーブルレベルでの展開前および展開後のスクリプトを追加するオプションもあります。 Vertabeloが提供するドキュメント生成機能を使用すると、コメントが便利になります。データベースドキュメントは、HTML、PDF、またはDOCXの3つの形式のいずれかでエクスポートできます。

キャブ予約の例を続けて、Vertabeloによって生成された物理データモデルを見てみましょう。

ステップ8：物理ER図を検証する

論理ERダイアグラムが検証されたのと同様に、Vertabeloには、FKが存在するかどうか、テーブル名または列名の長さが選択したデータベースに基づく制限を超えているかどうかなど、いくつかの追加チェックを使用して物理ERダイアグラムを検証するツールがあります。

検証を明示的に実行する必要はありません。これは、図が変更されたときに発生します。モデルの問題は、重大度の高いものから順に、エラー、警告、ヒントの3つのカテゴリのいずれかに分類されます。データベース設計プロセス中によくある間違いについて説明している、便利でよく書かれた記事があります。

ステップ9：物理ER図の問題を修正する

検証の結果により、修正が必要な問題が特定される場合があります。最も一般的な問題のいくつかは次のとおりです。

エンティティの関係が定義されている外部キーがありません。
テーブルに主キーがありません。
選択したデータベースでサポートされていないデータ型。

これらおよびその他の同様の問題が解決されると、モデルを、選択したデータベース管理システムのデプロイ可能なSQLスクリプトにエクスポートする準備が整います。

ステップ10：モデルをデプロイするためのDDLスクリプトを生成する

データベース設計は、ER図を作成することだけではありません。 ERダイアグラムを使用したデータモデリングの演習は、展開可能なものが得られる場合にのみ成功します。 Vertabeloには、物理モデルをすぐにデプロイできるSQLスクリプトにエクスポートするための便利なオプションがあります。生成されると、保留中の問題はSQLスクリプトで直接解決できます。

ただし、生成されたSQLスクリプトを変更することはお勧めしません。 ドリフトが発生します物理データモデルとデータベースにデプロイされたSQLスクリプトの間。これは、実際のテーブルとデータベースドキュメントの間のドリフトを意味する場合もあります。

データベース設計プロセスが終了したので、Vertabeloによって生成されたSQLコードを見てみましょう。

考えを共有する

データベース設計は、ソフトウェア開発において影響力の大きい活動です。データベース設計の分野は、ビジネス、エンジニア、およびデータアナリストの設計を表す新しい方法で長年にわたって進化してきました。これにより、多くの場合、新しいタイプの図、モデリング標準、および表記法が生まれました。進化の多くは、設計の基礎セクションで説明されています。

データベースの設計でのあなたの経験を喜んで見ていきます。 [email protected]までご連絡ください。