リレーショナルデータベースのデザインパターン？
設計パターンは通常、オブジェクト指向設計に関連しています。
そこにあります デザインパターン 作成およびプログラミング用 リレーショナルデータベース ？
多くの問題には必ず再利用可能な解決策が必要です。
例には、テーブル設計、ストアドプロシージャ、トリガーなどのパターンが含まれます。
martinfowler.com に似た、このようなパターンのオンラインリポジトリはありますか？
パターンが解決できる問題の例：
- 階層データの保存（例：タイプのある単一のテーブルと、1：1のキーと違いがある複数のテーブル...）
- 可変構造でデータを保存する（例：汎用列vs xml vs区切り列...）
- データの非正規化（影響を最小限に抑える方法など）
Martin Fowlerの署名シリーズには、 Refactoring Databases という本があります。データベースをリファクタリングするためのテクニックのリストを提供します。データベースパターンのリストをあまり聞いたことはありません。
また、David C. Hay's Data Model Patterns およびフォローアップ A Metadata Map を強くお勧めします。これは、最初のものに基づいており、はるかに野心的で興味深いものです。序文だけでも啓発的です。
また、あらかじめ用意されているデータベースモデルを探すのに最適な場所は、Len Silverstonのデータモデルリソースブックシリーズです Volume 1 普遍的に適用可能なデータモデル（従業員、アカウント、配送、購入など）が含まれています ボリューム2 業界固有のデータモデル（会計、ヘルスケアなど）が含まれています。 ボリューム はデータモデルパターンを提供します。
最後に、この本は表面上はUMLとオブジェクトモデリングに関するものですが、Peter Coadの MLによるカラーのモデリング は、オブジェクトの4つのコアアーキタイプがあるという前提から始まるエンティティモデリングの「アーキタイプ」駆動プロセスを提供します/データ・モデル
これは、数百の無料のデータベーススキーマを開発した紳士へのリンクです。
http://www.databaseanswers.org/data_models/
おそらく、dbを迅速に構築する必要がある場合、これにより、特定のスキーマのテーブルと関係の観点から出発点が得られます。おそらくこの開始点を変更する必要があることに留意してください。とても便利だと思いました。
第二に、SQL Server Magazineには「The Data Modeler」と呼ばれる不定期のコラムがあり、非常に教育的であり、特定のシステムの完全なスキーマが含まれていることがよくあります。
デザインパターンは簡単に再利用できるソリューションではありません。
設計パターンは、定義により再利用可能です。それらはパターンですyo他の良い解決策で検出します。
パターンを簡単に再利用することはできません。ただし、パターンに従ってダウンデザインを実装できます。
リレーショナル設計パターンには次のようなものが含まれます。
外部キーを使用した1対多の関係（マスター詳細、親子）の関係。
ブリッジテーブルとの多対多の関係。
FK列のNULLで管理されるオプションの1対1の関係。
スタースキーマ：ディメンションとファクト、OLAPデザイン。
完全に正規化されたOLTPデザイン。
ディメンション内の複数のインデックス付き検索列。
1つ以上のアプリケーションで使用されるPK、説明、およびコード値を含む「ルックアップテーブル」。なぜコードがあるのですか？わかりませんが、使用する必要がある場合、これはコードを管理する方法です。
ユニテーブル。 [これをアンチパターンと呼ぶ人もいます。これはパターンであり、時には悪いこともあり、時にはそれは良いことです。
配列テーブル。これは、列に値の配列またはシーケンスを持つことにより、最初の標準形式に違反するテーブルです。
混在データベース。これは、トランザクション処理用に正規化されたデータベースですが、レポートおよび分析用の追加のインデックスが多数あります。これはアンチパターンです。これをしないでください。とにかく人々がそれを行うので、それはまだパターンです。
データベースを設計するほとんどの人は、「もう1つ」の6つを簡単にガタガタ鳴らすことができます。これらは、定期的に使用する設計パターンです。
そして、これには、使用および管理の管理上および運用上のパターンは含まれません。
このブログをご覧ください- データベースプログラマー 。
彼はいくつかの データベースパターン について説明しています。
Joe Celkoの本は、この種のもの、特に「SQL for Smarties」に優れています。彼は、一般的な問題に対する革新的な解決策をいくつか持っており、そのほとんどは再利用可能な設計パターンです。
AskTom は、おそらくOracle DBのベストプラクティスに関する唯一の最も役立つリソースです。 （通常、特定のトピックに関するGoogleクエリの最初の単語として「asktom」と入力するだけです）
リレーショナルデータベースでデザインパターンについて話すのは本当に適切だとは思いません。リレーショナルデータベースは既に、問題への「設計パターン」の適用です（問題は「整合性を維持しながらデータを表現、格納、操作する方法」であり、設計はリレーショナルモデルです）。他のアプローチ（一般的に廃止されたと考えられている）は、ナビゲーションモデルと階層モデルです（他にも多くのモデルが存在するのは当然です）。
そうは言っても、「データウェアハウジング」は、データベース設計における多少別個の「パターン」またはアプローチと考えることができます。特に、 スタースキーマ について読むことに興味があるかもしれません。
長年のデータベース開発の後、始める前に答えるべきいくつかの問題といくつかの質問があると言えます。
質問：
- 将来、別のDBMSで使用しますか？ 「はい」の場合、現在のDBMSの特別なSQLに使用しません。アプリケーションのロジックを削除します。
使用しない：
- テーブル名と列名の空白
- テーブル名と列名の非ASCII文字
- 特定の小文字または大文字にバインドします。また、小文字と大文字のみが異なる2つのテーブルまたは列を使用しないでください。
- 「FROM」、「BETWEEN」、「DELETE」などのテーブルまたは列名にSQLキーワードを使用しません
推奨事項：
- UnicodeサポートにNVARCHARまたは同等のものを使用すると、コードページに問題はありません。
- すべての列に一意の名前を付けます。これにより、結合時に列が選択しやすくなります。すべてのテーブルに列「ID」または「名前」または「説明」がある場合は非常に困難です。 XyzIDとAbcIDを使用します。
- 複雑なSQL式にはリソースバンドルまたは同等を使用します。別のDBMSへの切り替えが容易になります。
- どのデータ型にもハードキャストしません。別のDBMSはこのデータ型を持つことができません。 FORの例Oracleには、SMALLINTに数字のみがありません。
これが良い出発点になることを願っています。
あなたの質問は少し曖昧ですが、私は UPSERT が設計パターンと考えられると思います。 MERGEを実装していない言語の場合、 問題を解決するための多くの選択肢 （適切な行が存在する場合はUPDATE、それ以外の場合はINSERT）が存在します。
パターンの意味に依存します。 Person/Company/Transaction/Productなどを考えているなら、はい-すでに多くの汎用データベーススキーマが利用可能です。
Factory、Singletonを考えている場合は、いいえ-DBプログラミングには低すぎるため、これらは必要ありません。
データベースオブジェクトの命名を検討している場合、それ自体は設計のカテゴリではなく、規則のカテゴリに属します。
ところで、S.Lott、1対多および多対多の関係は「パターン」ではありません。これらは、リレーショナルモデルの基本的な構成要素です。
Title: Data Patterns
By: Microsoft Corporation
Publisher: Microsoft Press
Pub. Date: December 21, 2004
Print ISBN-13: 978-0-7356-2200-5