個人に関するプロファイルを保存するデータベースがあります。これらの個人には、約 50 の可能なフィールドがあります。
いくつかは、名、姓、電子メール、電話番号などの一般的なものです。
その他は、趣味、スキル、興味などです
いくつかは、身長、体重、肌の色です。
これらの各グループは、システムによって異なる時点で使用されます。データベースを介してネゴシエートできるという点では、それぞれ約 8 フィールドの 7 つのテーブルを使用したいと考えています。ベストプラクティスは何ですか？
編集:データは、プロファイルの一致を見つけるために、検索エンジンで使用されます。これは私がしていることに影響しますか?
私はノーマライズ陣営にいます。
開始するためのいくつかのヒントを次に示します。
各「人」に任意の一意の識別子を割り当てるプロセスから始めます。PersonIdこれを 、またはそのようなものと呼びます。この識別子は代理キーと呼ばれます。代理キーの唯一の目的は、代理キーと現実世界の実在の人物との間の 1 対 1 の関係を保証することです。他の属性の値をデータベース内の「人」に関連付けるときは、代理キーを使用します。
データベースのレイアウトを開発するにつれて、他の属性にも代理キーが必要 (または少なくとも有用) であることがわかる場合があります。
管理する各属性を確認します。次の質問をしてください。この属性の値が 1 つしかない人はいますか?
たとえば、各人には「生年月日」が 1 つだけあります。しかし、どうして「趣味」を持つことができるのでしょうか。おそらくゼロから多数。単一の値の属性 (生年月日、身長、体重など) はPersonId、キーとして共通テーブルに入る候補です。この時点では、各テーブルの属性の数は気にする必要はありません。
ホビーなどの多値属性は、少し異なる処理が必要です。多値属性ごとに個別のテーブルを作成したい場合があります。Hobbies を例として使用すると、次のテーブルを作成できますPersonHobby(PersonId, Hobby)。この表の行は次のようになります(123, "Stamp Collecting")。このようにして、1 行に 1 つずつ、各人に必要な数の趣味を記録できます。「興味」「スキル」などについても同様です。
組み合わせによって他に何も決定されない多数の多値属性があるPersonId + Hobby場合 (つまり、この「趣味」、「興味」、または「スキル」を行っているこの人物について記録する興味深いものが何もない場合)、ひとまとめにすることができます。のような構造を持つ属性値テーブルにそれらを変換しますPersonAV(PersonId, AttributeName, Value)。行は次のようになります(123, "Hobby", "Stamp Collecting")。
AttributeNameこの方法を使用する場合は、テーブル内のPersonAVを代理キーに置き換え、別のテーブルを作成してこのキーをその説明に関連付けることもお勧めします。次のようなもの: Attribute(AttributeId, AttributeName). この表の行は次のよう
(1, "Hobby")になり、対応するPersonAV行は次のようになります(123, 1, "Stamp Collecting")。これはAttributeNames、データベース/アプリケーションで有効なものを知る必要がある場合に、それらを検索する場所を確保するために一般的に行われます。「興味」が有効な値であるかどうかを検証する方法を考えてみてください。
AttributeName誰かがそれを持っていることを記録していない場合、データベースAttributeNameにはその記録がありAttributeNameません。それが存在するかどうかをどのように判断しますか? よくAttribute表に出して見てください！
一部の属性には複数の関係がある場合があり、それもテーブルの正規化方法に影響します。あなたの例ではこれらの依存関係は見当たりませんでしたので、次のことを考慮PartIdしWeightClassてStockCountくださいShipCost。これは、次のようなテーブルを示唆していますPart(PartId, WeightClass, StockCount, ShipCost)。ただし、非キー属性間に関係が存在する場合は、除外する必要があります。たとえば、 がWeightClassを直接決定するとしShipCostます。これは、単独で決定するにWeightClassは十分であり、表から除外する必要があることを意味します。ShipCostShipCostPart
正規化はかなり微妙な芸術です。適切に行うには、データ モデル内のすべての属性間に存在する機能の依存関係を特定する必要があります。機能の依存関係を考え出すだけでも、かなりの熟考と考慮が必要ですが、適切なデータベース設計に到達するためには重要です。
データベースを構築する前に、時間をかけて正規化についてもう少し勉強することをお勧めします。ここで過ごした数日は、後々元が取れるほどの価値があります。「機能依存性」、「正規化」、「データベース設計」を Google/Wikipedia で検索してみてください。読んで、調べて、学んでから、正しく構築してください。
データベース設計の正規化に関して私が行った提案は、取るべき方向性に関するヒントにすぎません。アプリケーションで管理しようとしているすべてのデータを十分に把握していない場合は、ここでのアドバイスを「一粒の塩」で受け取る必要があります。
言うのは難しく、アプリケーションが必要とするものに基づいています。データベースを正規化する方法を示し、独自のテーブルなどに分離したいものに光を当てる必要があるため、データベースの正規化を調べることをお勧めします.
いくつかのテーブルをお勧めします。過度の正規化は管理が難しく、パフォーマンスが低下する複雑なクエリを作成することになります。
絶対に必要な場合にのみ正規化し、論理的に考えます。上記で提供された限られた情報を使用して、3 つのテーブルを使用します。
表 1: PersonalDetails 表 2:アクティビティ 表 3:その他
必要に応じて使用できるクラスタリングなど、パフォーマンスを高速化する他の手法があります。
IMO、必要なテーブルの数よりも、保存されているデータの品質を心配することが重要です。
たとえば、変更を追跡する必要がありますか? ジョンが 2007 年 1 月に 5 フィート 2 インチで、2010 年 10 月に 5 フィート 11 インチだったとしたら、知りたいですか? その場合、その人物を高さから 2 つのテーブルに分ける必要があります。
趣味はどうですか - 趣味は 3 つしか許されていませんか? 彼らはより多く/より少なく持つことができますか? これはあなたが将来的に質問したいことですか？その場合は、別のテーブルが必要です。
データベースの設計と正規化について読む必要があります (このサイト自体にいくつかの優れたスレッドがあります)。
あなたが説明したことから、私は確かにそれを複数のテーブルに分割します。ただし、任意の数の列で分割することはしません。代わりに、エンティティを構成するか、データをヒットするために使用するアクセス パターンに一致する列の論理コレクションを考えてみてください。
すべての人が同じ数の趣味を持っていない限り (つまり、全員が 2 つの趣味を挙げている場合)、標準化する必要があります。
個人と常に 1 対 1 であるフィールドは、同じテーブルにある必要があります。たとえば年齢。2 つの異なる年齢を持つ人はいません。
100% 正しいデータベース構成はありません。目的に十分に適合するものは 1 つだけです。将来、単一の優れたデータベース サーバーの機能を超えることが予測できない場合は、データを正規化し、外部キー、カスケード削除などの多くの制約を使用して、データベースを楽しく操作できるようにします。一方、何十億ものリクエストを持つ多くのアプリケーションのデータベースを見ると、パフォーマンスとスケーラビリティの名の下に、これらの優れた機能の多くが見落とされていることがわかります。
これは、データをいつ、どのように使用するか、データが変更される頻度、およびデータベースの使用量に大きく依存するため、この質問に対する正解はありません。
私が個人的にやりたいことは、データを論理エンティティに整理し、それらのエンティティに基づいてテーブルを作成することです。これは少なくとも私が始めるところです。
多くの小さなテーブル、つまりここでは正規化が最適です。柔軟性を提供し、冗長性を減らし、データベース編成を改善します。