3

私は、データベース設計者に挑戦している設計上の問題についての方向性を探しています。私はアーカイブとGoogleを検索しましたが、これは単純な/初心者のタイプの問題であると思われますが、決定的なものは何も得られませんでした。

イベントの場所を格納するテーブルがあります。これは、ロケーションテーブルと呼ばれます。このテーブルでは、LocationCodeが一意である必要があります。このテーブルでは、LocationNameが一意である必要もあります。ただし、現実の世界では、2つの場所が異なる場所に存在していても、同じ名前になる場合があります（たとえば、同じ州の異なる郡に存在する同じ名前の2つの学校）。ある設計者は、郡名のように名前に値を追加することによって名前を強制的に変更する必要があると主張しています（例：ユニオン高校-フランシス郡）。これに対する彼女の理論的根拠は、「統制語彙」を確保することです。別の設計者は、名前は同じであることが許可されるべきであると主張しています。これは現実を反映しており、LocationCodesを使用して一意性を強制/追跡する必要があるためです。

私は2番目のデザイナーの方向に傾いています-名前は異なっていることが許されるべきです。私が考えることができる同等の例は、人々が同じ名前を共有することが多いという事実です（例：JaneDoe）。人々の連絡先情報を格納するテーブルでは、名前を強制的に変更することはなく、社会保障コードが一意性を追跡する役割を果たしているように見えます。

では、この問題に関する一般的なガイドラインや基準はありますか？役立つドキュメントへのリンクは素晴らしいでしょう。前もって感謝します。

4

5 に答える 5

5

私は 2 番目のデザイナーの方向に傾いています。名前が異なることは許されるべきです。

名前が同じであることを許可する必要がある、テーブルで重複した名前を許可する必要があると言うつもりだったと思います。

人々の連絡先情報を格納するテーブルでは、名前が異なることを強制されず、社会保障コードが一意性を追跡する役割を果たします。

これは単純なケースでは当てはまりますが、実際のアプリケーションでは次のことがわかります。

  • アメリカに住んでいる一部の外国人は SSAN を持っていません。
  • SSAN には、合法と非合法の両方の重複があります。
  • 一部の米国市民は SSAN を持っていません。（通常、病院以外で生まれたためです。）

人を明確に識別することは、難しい問題であり、アプリケーションに依存する問題でもあります。地元の自動車局には、人を特定する独自の方法があります。IRSには独自の方法があります。雇用主には独自の方法があります。学校や病院には独自の方法があります (ここではプライバシー法が大きな影響を与えます)。あなたはおそらくあなた自身の道を見つける必要があるでしょう。

これは絶対に避けては通れないものです。ある時点で、会社の誰かが、「ジョン スミス」という多くのデータベース行のどれが、あなたの机の前にいる怒っている顧客と一致するかを判断できなければなりません。

地名はこんな感じ。「サンフランシスコ」の正式名称は「San Francisco, California, USA」です。フルネームで「クリントン、ミス」と簡単に区別できます。「アイオワ州クリントン」より。

2 つの異なる場所に同じ非公式の名前が付けられているケースを見つけました。たとえば、「テネシー州ナチュラル ブリッジ」という名前の町があり、テネシー州の別の場所で「テネシー州ナチュラル ブリッジ」とも呼ばれる自然橋があるとします。違いは、これらの場所の 1 つは常に都市であり、もう 1 つは常に都市ではないことです。(少なくとも私の経験では、例外を発見しても驚かないでしょう。)

ただし、これらの現実の問題があなたにとって重要かどうかは、アプリケーションに依存します。都市ではない地名を扱う必要はないので、「フル ネーム」を保存することは、適切なデータを確保するための簡単で直接的な方法です。

あなたの場合、イベントの場所について、名前の重複を許可することがビジネス上の意味で実用的であるとは思えません。名前が重複している場合は、ヒントとしてその名前が与えられたときに、どの場所コードが実際の場所を参照しているかを覚えておく必要があります。かなりのサイズのデータ​​ベースでは、とにかく違いを書き留めなければ、人々はそれを確実に行うことはできません.

于 2012-08-09T16:43:18.793 に答える
2

これは、正しい設計に関する問題ではありません。情報要件についての質問です。設計段階ではなく、どちらが正しいかを発見するのは分析段階です。同じチームが両方を行っている場合でも、分析と設計を区別することが重要です。

名前の重複が許可されている場合、ユーザーはあいまいさを解消する必要があるときに、他の情報を必要とします。ID はユーザーにとって無意味な場合があるため、個別の ID を提供するだけでは不十分な場合があります。

プロジェクトを注文した人々に戻ります。彼らは何を望んでいるのか？ユーザーが望むものを何でも欲しがっている場合は、ユーザーにインタビューするか、ユーザーを代弁してくれる人にインタビューします。誰もユーザーの代わりに話すことができず、プロジェクトの所有者が自分自身について話すことを拒否した場合、あなたは最善の推測をすることになります.

于 2012-08-10T12:44:41.990 に答える
1

私は Catcall (+1) に同意しませんが、ケーキを持って食べられるようにする 3 つ目の方法があると思います。

一意の命名スキームを嫌う理由の 1 つは、修飾子を含む場所と含まない場所があることを気にする人がいるからです。

多くの場合、あいまいな名前を使用するだけで十分な場合がありますが、それ以外の場合は、正確にどの名前を意味するかについて確実性が必要です。基本的な場所の名前と修飾子を別々の列に保存しないでください。修飾子が場所を含む郡のようなものである場合、とにかくすべての場所に対してこれを保存できます。これにより、十分な場合は単純な (ただし一意ではない) 名前で作業し、必要な場合は完全修飾名で作業するオプションが提供されます。

于 2012-08-10T12:23:28.817 に答える
0

これを試みる1つの方法は、場所の経度/緯度を記録する追加の列がある場所を使用することです。場所の名前の後に経度と緯度が続くのは、常に一意です。

基本的に、テーブル構造は次のようになります。

Location(location_name, location_longitude, location_latitude)

私が行った選択を擁護しようとすることは、プログラマーとして私が利用できるものと、問題を解決するために必要な制限に関連しています。したがって、問題を効率的に解決するまでは、実際には問題ではありません。

注：緯度/経度は、任意のジオロケーションプロバイダーにWebサービスを書き込むことで取得できます。

于 2012-08-10T20:09:04.947 に答える