データベースの設計。 ベストプラクティス

このレートでの次のフローの開始を予測して 「データベース」 データベースを設計するための重要なヒントをまとめた小さな著者向けの資料を用意しました。 この資料がお役に立てば幸いです。

データベースは、最も単純なブログやディレクトリから、信頼できる情報システムや大規模なソーシャル ネットワークに至るまで、あらゆる場所に存在します。 データベースが単純であるか複雑であるかはそれほど重要ではなく、データベースを正しく設計することが重要です。 データベースが意図せずに、目的を明確に理解せずに設計されている場合、効果がないだけでなく、データベースをさらに使用する作業は、ユーザーにとっては本当に苦痛であり、侵入できない森となります。 ここでは、便利で使いやすい製品を作成するのに役立つデータベース設計のヒントをいくつか紹介します。

1. テーブルの目的とその構造を決定する

現在、スクラムや RAD (Rapid Application Development) などの開発手法により、IT チームはデータベースを迅速に開発できます。 しかし、時間を追うあまり、目標そのものが何なのか、最終的な結果はどうなるのかをぼんやりと想像しながら、いきなり基礎の構築に取り掛かりたくなる誘惑が非常に大きいです。
 
あたかもチームが効率的でスピーディーな仕事に集中しているかのように見えますが、これは蜃気楼です。 プロジェクトを深く深く掘り下げるほど、データベース設計のエラーを特定して変更するのにかかる時間が長くなります。

したがって、最初に決定する必要があるのは、データベースの目的を定義することです。 データベースはどのような種類のアプリケーションのために開発されていますか? ユーザーはレコードのみを操作し、トランザクションに注意を払う必要があるのでしょうか? それともデータ分析に関心があるのでしょうか? 拠点をどこに配置する必要がありますか? 顧客の行動を追跡するのでしょうか、それとも単に顧客関係を管理するだけなのでしょうか? 

設計チームがこれらの質問に早く答えるほど、データベース設計プロセスはよりスムーズになります。

2. ストレージにはどのデータを選択すればよいですか?

事前に計画を立てましょう。 データベースの設計対象となっているサイトやシステムが将来どうなるかについての考え。 技術仕様の単純な要件を超えることが重要です。 ただし、ユーザーが保存する可能性のあるすべての種類のデータについて考え始めないでください。 代わりに、ユーザーが投稿を書いたり、文書や写真をアップロードしたり、メッセージを交換したりできるかどうかを考えてください。 この場合、データベース内でそれらのスペースを割り当てる必要があります。

将来的にデザインベースがサポートされるチーム、部門、または組織と協力します。 顧客サービスの専門家から部門長まで、さまざまなレベルの人々とコミュニケーションを図ります。 このようにして、フィードバックの助けを借りて、会社の要件を明確に理解することができます。 

同じ部門内であっても、ユーザーのニーズが衝突することは避けられません。 このような状況に遭遇した場合は、恐れることなく自分の経験に頼って、すべての関係者に適し、データベースの最終目標を満たす妥協点を見つけてください。 安心してください。将来的には +100500 のカルマと山ほどのクッキーを受け取ることになります。

3. データのモデル化は慎重に行う

データをモデル化する際に注意すべき重要な点がいくつかあります。 前に述べたように、データベースの目的によって、モデリングにどの方法を使用するかが決まります。 オンライン レコード処理 (OLTP)、つまりレコードの作成、編集、削除を行うデータベースを設計している場合は、トランザクション モデリングを使用します。 データベースがリレーショナルである必要がある場合は、多次元モデリングを使用するのが最善です。

モデリング中に、概念的 (CDM)、物理 (PDM)、および論理 (LDM) データ モデルが構築されます。 

概念モデルは、エンティティとそれに含まれるデータの種類、およびエンティティ間の関係を記述します。 データを論理的なチャンクに分割すると、作業がはるかに楽になります。
大切なのは適度であり、やりすぎないことです。

エンティティを XNUMX つの単語またはフレーズで分類するのが非常に難しい場合は、サブタイプ (子エンティティ) を使用します。

エンティティが独自の人生を歩み、その動作と外観、および他のオブジェクトとの関係を記述する属性を持っている場合は、サブタイプだけでなくスーパータイプ (親エンティティ) も安全に使用できます。 

このルールを無視すると、他の開発者がモデル内で混乱し、データとその収集方法のルールを完全に理解できなくなります。

概念モデルは論理モデルを使用して実装されます。 これらのモデルは、物理データベース設計のロードマップのようなものです。 論理モデルでは、ビジネス データ エンティティが識別され、データ タイプが決定され、データ間の関係を制御するルール キーのステータスが決定されます。

次に、論理データ モデルが事前に選択された DBMS (データベース管理システム) プラットフォームと比較され、物理モデルが取得されます。 データが物理的にどのように保存されるかを説明します。

4. 適切なデータ型を使用する

間違ったデータ型を使用すると、データの精度が低下し、テーブルの結合が困難になり、属性の同期が困難になり、ファイル サイズが肥大化する可能性があります。
情報の整合性を確保するには、属性には許容されるデータ型のみが含まれている必要があります。 年齢をデータベースに入力する場合は、列に最大 3 桁の整数が格納されていることを確認してください。

NULL 値を含む空の列を最小限に作成します。 すべての列を NULL として作成すると、これは大きな間違いです。 データが不明であるか、まだ意味を理解していない場合に、特定のビジネス機能を実行するために空の列が必要な場合は、自由に作成してください。 結局のところ、「死亡日」や「解雇日」の欄を事前に記入することはできません;私たちは空に指を向ける予測者ではありません:-)。

ほとんどのモデリング ソフトウェア (ER/Studio、MySQL Workbench、SQL DBM、gliffy).com) data を使用すると、データ領域のプロトタイプを作成できます。 これにより、正しいデータ型、アプリケーション ロジック、良好なパフォーマンスが保証されるだけでなく、値が必須であることも保証されます。

5. 自然体になる

テーブル内のどの列をキーとして使用するかを決定するときは、ユーザーがどのフィールドを編集できるかを常に考慮してください。 それらをキーとして選択しないでください - 悪い考えです。 あらゆることが発生する可能性がありますが、それが一意であることを確認する必要があります。

ナチュラルキーまたはビジネスキーを使用するのが最善です。 これにはセマンティックな意味があるため、データベース内での重複を避けることができます。 

ビジネス キーが一意 (名、姓、役職) で、テーブルの別の行で繰り返されるか、変更する必要がない限り、生成された人工キーを主キーとして指定する必要があります。

6. 適度に正規化する

データベース内のデータを効果的に整理するには、一連のガイドラインに従ってデータベースを正規化する必要があります。 従うべき正規形は XNUMX つあります。
正規化により、冗長性が回避され、アプリケーションまたはサイトで使用されるデータの整合性が確保されます。

いつものように、正常化であっても、すべては適度でなければなりません。 データベース内に同じ一意のキーを持つテーブルが多すぎる場合は、調子に乗ってデータベースを過剰に正規化していることになります。 過度の正規化はデータベースのパフォーマンスに悪影響を与えます。

7. 早めにテストし、頻繁にテストする

テスト計画と適切なテストはデータベース設計の一部である必要があります。

データベースをテストする最良の方法は、継続的インテグレーションを使用することです。 「データベースの XNUMX 日」シナリオをシミュレートし、すべてのエッジ ケースが処理されたかどうか、およびどのようなユーザー インタラクションが発生する可能性があるかを確認します。 バグを早く発見すればするほど、時間とお金の両方を節約できます。

これらは、優れた生産性と効率性のデータベースを設計するために使用できる XNUMX つのヒントです。 これらに従えば、将来的にはほとんどの頭痛を回避できるでしょう。 これらのヒントは、データベース モデリングにおける氷山の一角にすぎません。 膨大な数のライフハックがあります。 どれを使いますか？

出所： habr.com