私はデータベース設計に不慣れで、正規化についてかなり読んでいます。宿泊施設、駅、空港の3つのテーブルがある場合。各テーブルにアドレス列がありますか、それとも他のテーブルから参照されるアドレステーブルがありますか？過剰正規化のようなものはありますか？
ありがとう
5565 次
13 に答える
5
データベースの正規化とは、関係 (テーブル) 内のファクト (列) 間、およびスキーマ (データベース) を構成するさまざまな関係 (テーブル) 間で特定の機能依存関係を維持する関係 (テーブル) を構築することです。少し口いっぱいですが、それがすべてです。
A Simple Guide to Five Normal Forms in Relational Database Theory は、標準形式の古典的なリファレンスです。このホワイト ペーパーでは、各正規形の本質と、データベース テーブル設計に関するその重要性を簡単な言葉で定義します。これは非常に優れた「試金石」のリファレンスです。
特定の質問に適切に答えるには、追加情報が必要です。あなたが尋ねなければならないいくつかの重要な質問は次のとおりです。
- Address は単純な事実 (例: テキストの塊) か複合事実 (例: 複数の属性で構成される: 住所行、都市名、郵便番号など)
- 「宿泊施設」「空港」「駅」に関するその他の「事実」とは？
- 「空港」、「宿泊施設」、「駅」を一意かつ最小限に識別する「事実」のセットはどれですか (これらの事実は通常、キーまたは候補キーと呼ばれます)。
- Address ファクトと各リレーション キーを構成するファクトの間には、どのような機能上の依存関係がありますか?
言うまでもなく、あなたの質問に対する答えは、期待するほど単純ではありません!
「オーバーノーマライゼーション」のようなものはありますか？多分。これは、特定してテーブルを作成するために使用した機能の依存関係が、アプリケーション ドメインにとって重要であるかどうかによって異なります。
たとえば、住所が複数の属性で構成されていると判断されたとします。そのうちの 1 つが郵便番号です。技術的には、郵便番号も複合アイテムです (少なくともカナダの郵便番号はそうです)。これらの事実を認識するためにデータベースをさらに正規化すると、おそらく過度の正規化になります。これは、郵便番号のコンポーネントがアプリケーションとは無関係であるため、それらをデータベース設計に組み込むことは過剰な正規化になるためです。
于 2010-07-19T18:02:53.067 に答える
4
各テーブルにアドレス列がありますか、それとも他のテーブルから参照されるアドレステーブルがありますか？
空港、駅、宿泊施設はそれぞれ異なる住所形式を持つことができますか？
単一のADDRESSテーブルにより、住所（スイート、RR、郵便番号/郵便番号、州/県など）を処理するために必要な作業が最小限に抑えられます。
過剰正規化のようなものはありますか？
正規化にはさまざまなレベルがあります。私は、正規化ではなく、貧弱な設計と見なすものにしか遭遇していません。
于 2010-07-19T15:49:39.923 に答える
4
For addresses, I would almost always create a separate address table. Not only for normalization but also for consistency in fields stored.
As for such a thing as over-normalization, absolutely there is! It's hard to give you guidance on what is and isn't over-normalization as I think it mostly comes from experience. However, follow the books on each level of normalization and then once it starts to get difficult to see where things are you've probably gone too far.
Look at all the sample/example databases you can as well. They will give you a good indication on when you should be splitting out data and when you shouldn't.
Also, be well aware of the type and amount of data you're storing, along with the speed of access, etc. A lot of modern web software is going fully de-normalized for many performance and scalability reason. It's worth looking into those for reason why and when you should and shouldn't de-normalize.
于 2010-07-19T15:42:15.567 に答える
2
Personally I'd go for another table.
I think it makes the design cleaner, makes reporting on addresses much simpler and will make any changes you need to make to the address schema easier.
If you need to have it denormalized later on you can always create two views that contain the Train station and airport information along with any address information you need.
于 2010-07-19T15:43:42.567 に答える
2
これは、正規化によって私が理解していることではありません。ストレージまたはデータモデルを分割する方法だけで、冗長性の削除について話しているようには見えません。宿泊施設、鉄道駅、空港の住所の例はすべてばらばらになると思いますか?
私が知る限り、それは、あなたが線に沿って考え始めた場合にのみ、正常化になるでしょう. 郵便番号は番地に機能的に依存しているため、独自のテーブルに分割する必要があります。
その場合、これはコンテキストに応じて、望ましい場合もあれば望ましくない場合もあります。レコードを管理し、正確性を確保できる場合はおそらく望ましいですが、ユーザーが自分のレコードを更新できる場合は望ましくありません。
関連する質問は、人の名前の正規化は行き過ぎですか?
于 2010-07-19T15:57:34.647 に答える
1
パフォーマンスに非常に敏感なプロジェクト/機能がある場合、場合によってはデータベースを非正規化するのが賢明かもしれません。ただし、これにより、さまざまな理由でメンテナンスの問題が発生する可能性があります。代わりに、キャッシュ テーブルを使用してデータを複製することもできますが、これにも欠点があります。実際にはケースバイケースですが、通常の実践では、データベースの正規化は良いことです。私が見た正規化されていないデータベースの 99% は設計によるものではなく、開発者の誤解/間違いによるものです。
于 2010-07-19T16:03:27.300 に答える
1
各テーブルに住所列を配置するか、他のテーブルから参照される住所テーブルを配置するか?
他の人がほのめかしたように、これは実際には正規化の問題ではありません。冗長性を減らしたり、依存関係を整理しようとしているわけではないからです。どちらの方法でも完全に受け入れられます。住所に固有の集中型の検証またはビジネス ロジックを使用する場合は、住所を別のテーブルに移動することが理にかなっている可能性があります。
過度の正規化などはありますか？
はい。前述したように、大規模なシステム (大量のデータ、大量のトランザクション、またはその両方) では、パフォーマンスが問題になるポイントまで正規化できます。これが、多くのシステムがレポートとクエリに非正規化データベースを使用する理由です。
ただし、パフォーマンスに加えて、データのクエリがいかに簡単かという問題もあります。エンドユーザーによるデータのクエリが大量に発生するシステムでは (危険な場合があります!)、非正規化構造は、技術に詳しくない、またはデータベースに詳しくないほとんどの人にとって理解しやすいものです。
私たちが扱うほとんどのことと同様に、これは理解、パフォーマンス、および将来の保守性の間のトレードオフであり、特定のシステムでどこに線を引くかについて明確な答えがあることはめったにありません。
経験を積むことで、作成するシステムの最適な線引きを知ることができます。
そうは言っても、私の好みは、より多くの正規化とより少ない正規化の側で誤りを犯すことです。
于 2010-07-19T16:44:44.377 に答える
0
Oracle 9iを使用している場合は、アドレスオブジェクトをテーブルに格納できます。これにより、アドレス形式に関する（正当化された）懸念がなくなります。
于 2010-07-19T15:52:23.353 に答える
0
I can only add one more constructive note to the answers already posted here. However you choose to normalize your database, that very process becomes almost trivial when the addresses are standardized (look the same). This is because as you endeavor to prevent duplicates, all the addresses that are actually the same do look the same.
Now, standardizing addresses is not trivial. There are CASS services which do this for you (for US addresses) which have been certified by the USPS. I actually work for SmartyStreets where this is our expertise, so I'd suggest you start your search there. You can either perform batch processing or use the API to standardize the addresses as you receive them.
Without something like this, your database may be normalized, but duplicate address data (whether correct or incomplete and invalid, etc) will still seep in because of the many, many forms they can take. If you have any further questions about this, I'll personally assisty you.
于 2012-02-13T19:53:15.793 に答える
0
このような状況では、各テーブルに住所列があっても問題ないと思います。2 回以上使用されるアドレスはほとんどありません。ほとんどのアドレスは、エンティティごとに 1 つだけ使用されます。
しかし、余分なテーブルにある可能性があるのは、通り、都市、国の名前です...
そして最も重要なことは、すべての鉄道駅、宿泊施設、空港の住所はおそらく 1 つだけであるため、n:1 の関係です。
于 2010-07-19T15:38:14.863 に答える
0
あなたが「住所」と言うとき、通り、都市、都道府県、場合によっては国、郵便番号などの完全な住所を意味していると思います。これは 4 つか 5 つのフィールドですが、「アドレス ライン 1」と「アドレス ライン 2」、気付などを許可する場合はそれ以上になる可能性があります。ステーションにリンクするための「アドレス ID」を使用して、別のテーブルに配置する必要があります。などのテーブル。そうしないと、同じフィールド定義セットの 3 つの個別のコピーを作成することになります。一貫性を保つために余分な労力が必要になるため、これは悪いニュースです。たとえば、最初は米国の住所のみを扱っていたが (私はアメリカ人なので、米国を想定します)、後でカナダ人も許可する必要があることがわかった場合はどうでしょうか。郵便番号フィールドのサイズを拡張し、国コードを追加する必要があります。共通のテーブルがあれば、その後、これを行う必要があるのは 1 回だけです。そうでない場合は、これを 3 回行う必要があります。また、「3 回」とは、データベース スキーマを変更するだけでなく、アドレスを処理するプログラム内のすべての場所を変更することである可能性があります。
正規化の利点の 1 つは、変更の影響を最小限に抑えることです。
于 2010-07-19T16:42:21.153 に答える
0
クエリをより効率的にするために非正規化が必要な場合があります。ただし、これは非常に慎重に行う必要があり、完全に正規化されたモデルが深刻な非効率性の問題を引き起こすと信じる十分な理由がある場合にのみ行う必要があります。私の謙虚な経験では、ほとんどのプログラマーはすぐに非正規化することはできません。通常、「ああ、それを別のテーブルに分割するのは面倒です」とすぐに答えます。
于 2010-07-19T16:45:52.630 に答える
0
私はS.Lottに同意し、以下を追加したいと思います:
良い答えは、あなたがすでに知っていることにかかっています。ただし、リレーショナル データベース理論の基本的な「数学」では、非常に明確に定義された明確なレベルの正規化が定義されています。究極のノーマルフォームに到達すると、それ以上ノーマライズすることはできません。
3 つのエンティティで何をモデル化するか、およびそれらをどのように識別するかに応じて、非常に異なる概念データ モデルを考え出すことができます。これらはすべて、通常の形式の組み合わせで表現することも、まったく正規化されていない (1 のように) 表現することもできます。いたるところに記述子と NULL ホールがあるすべてのデータのテーブル...)。3 つのエンティティを究極の正規形に正規化することを検討してください。新しい要件、ユースケース、または拡張機能を導入できるようになりました。これにより、コンテンツを見ると、これまでの説明的な属性に何らかの順序付け、参照、または構造化された性質が与えられます。次に、モデルはこの動作を表す必要があり、以前は属性であったものは、おそらく他のエンティティによって参照される別のエンティティにする方がよいでしょう。
過度の正規化？特定のモデルを正規化できるという意味でのみ、特定の DB プラットフォームでの保存または処理が非効率になります。そこで効率的に処理できるものに応じて、特定の側面を非正規化し、冗長性と速度 (データ ウェアハウス データベースは常にこれを実行します) と洞察をトレードオフすること、またはその逆を行うことが必要になる場合があります。
私がこれまで見てきたすべての (動作中の) db 設計は、どちらかというと正規化された概念データ モデルを持ち、かなりの非正規化が論理および/または物理データ モデル レベル (Sybase PowerDesigner 用語で言えば) で実行され、モデルを「管理可能」にします。 -- それか、機能していないかのどちらかです。つまり、メンテナンスの問題が急速に大きくなったために失敗しました。
于 2010-07-19T16:22:17.283 に答える