最近、自分の仕事の過程で、ユーザー中心の統一データベーステーブルの構造設計を担当する会社は、代替のアイデアの数の誕生は、特にPaizhuanを楽しみにして、それを共有することができます。
次のように思考の進化があります。
第一段階：
企業、教育機関、家族や「組織」として抽象化の他のエンティティ、組織、PARENTID協会により、組織の複数のレベルを可能にする、「O」と呼びます。
抽象エンティティの部門や他の組織所属のブランチ「部門」、部門は、「D」と呼ばれる、多くの部門が関連によってPARENTIDことができます。
「天然」として抽象化天然の実体は、ヒトは、「H」と称します。
抽象的な「アカウント」、アカウントは、「A」と呼ばれます。
抽象的な「役割」、役割は、「R」と呼ばれます。
各組織は、複数の部門を持つことができ、すべての組織が自然人以上を持つことができ、すべての部門では、より多くの個人を持つことができます。
すべての組織は、部署、個人が複数のアカウントを持つことが許可されています。
アカウントが複数の役割を共有することができます。
図ERに示す第1の位相関係
これは非常に単純明快なモデルです。
残念ながら、現実の世界はそれほど単純ではありません。
第二段階：
製品事業の深い理解を通じて、需要がに変更されました：
組織が複数の部門を持っていますが、部門は複数の組織に属することができます。（例：2つの独立して所有薬局チェーンは、同一のストレージ部門を共有します。）
自然人以上を持つ部門は、自然の人は複数の部門に所属することができます。（例：部長、会社のゼネラルマネージャー、重要なセクタ数の一部。）
自然人以上を持つ組織は、自然の人は複数の組織に属することができます。（例：医師はもっと練習することができます。）
図関係ERにおける第二段階
今かなり正常な。
第三段階：
郵便配達の住所 - シンプルな機能を追加します。
これは、単純な機能ですが、合併症があることである：最後のビジネスは、「組織は部門が配送先住所配送先住所の配送先住所または自然人を持っていたされたエンティティとレシート配信アドレス所有のアカウントを持っている????住所、多くの関係に一つまたは一から一？「これらの質問、製品は将来の拡張の方向を決定することができない、あなただけ答えることができる」そうです。」ハハ。。。
従来の設計方法によると、組織、部署間で、自然人、アカウントと配送先住所、2アドオン多くの関係テーブルの間。テーブルの数との関係は、果物や野菜の量以上であることを、果樹園として、雑草の数を膨潤し始めます。。。
雑草、雑草の抽象的なデザインの数を減らすために：
配送先住所に決めた郵便配達先ID、;列挙コードは2つのエンティティID、実際の意思決定エンティティ値を持つエンティティによって関係エンティティ（団体、部署、個人、口座）と住所を、追加します。
例えば：
エンティティ列挙コードO、エンティティID 1、ID 10郵便配達アドレスは、発現：組織1のIDを、配送先住所のID 10を有します。
エンティティ列挙コードH、エンティティID 2、ID 20郵便配達アドレスは、発現：自然人のid 2を、配送先住所のID 20を有します。
エンティティ列挙コードA、エンティティID 3、ID 30郵便配達アドレスは、発現：アカウント3のIDを、配送先住所のID 30を有します。
ERに示す第3の位相関係
第四段階：
この時、会社の幹部は、議論のニーズに参加します、
、必要なデータの制御粒子は、単一のデータに到達しなければならず、関係データは、最大設計の柔軟性を行うために必要な任意の外部エンティティ、権限制御が、不定の特定のニーズに応じてあってもよいです。
B、追加の資格管理、有効な管理機能は、ビジネスにも知らない何最大設計の柔軟性を行うために必要な拡張の将来の方向。
その結果、抽象雑草の数が膨らむようになりました。
Aの需要は、設計OneIdテーブルは、テーブル内のすべてのエンティティのIDバックアップが、将来は、データの行レベルのアクセス制御と、の関係がOneIdテーブルによって拡張します。
そして、抽象雑草の数は、次のように設計された、ユニバーサルデザインのテーブルを展開しないようにするには：
| ユニバーサルテーブル | |||
| エンティティ列挙コード | エンティティID | エンティティ列挙コード | エンティティID |
例えば
| ユニバーサルテーブル | |||
| エンティティ列挙コード | エンティティID | エンティティ列挙コード | エンティティID |
| ザ・ | 1 | H | 10 |
| ザ・ | 1 | H | 11 |
| H | 10 | A | 100 |
| H | 10 | A | 101 |
データの上、記述されています
「二自然人の10、11のIDを持つ組織のID 1」。
「2つのアカウントの100、101のIDを持つ天然の人のID 10、。」
どれ複雑/未定多くの関係は、このユニバーサルテーブルで記述することができます。
データベース全体の設計変更の最終バージョン：
注意：どんなに関係がどのように変化するか、将来の事業拡大は、唯一、新しいエンティティに拡張する必要がある他のエンティティとの関係を検討する必要があるか、デザインの歴史がどんな影響がありません。
これは、データベース設計、データベース設計、シンプルで普遍的な方法のすべての既存のパラダイムからの脱却である、ユニバーサルDB設計法、UDDMが、それはユダの方法に言及、私は非常に適切な感じ。
上記の設計方法は、私のチームは、我々が探求する積極的Paizhuanを楽しみにして、善悪を判断するのに十分な内部容量をしていません。