1

データモデリングに関する質問があります。次の表に3つの学生テーブルがあるとします。 Source_table1にはA_IDが主キーとして、Nameが属性として含まれています。 Source_table2は主キーとしてB_IDを持ち、その他の属性として名前&を持ちます.Source_table3は主キーとしてC_IDを持ち、属性として名前、アドレス、および年齢を持っています。そのテーブルのすべてのレコードを含むStudent Masterとして新しいテーブルを作成したい場合は、どうすればいいのですか?相互参照テーブルを作成している場合、その問題にどのように接近すべきですか?異なるソースからのデータを統合データ同じタイプの複数のテーブルを1つのテーブルにモデリングして、すべてのテーブルを1つのテーブルに集約します。

enter image description here

+0

難しいと言えます。これらのテーブルはすべて同じエンティティに関するデータを保持していますか? – ATC

+0

あなたがしたいことは不明です。あなたはテーブルを統合したいと思っていますが、古いプライマリキーを維持したいのですか?3のうちの1つを連結のポイントとして使用したいですか?あなたはあなたのソーステーブルのイメージを持っているでしょう。あなたが達成したいものの例を提供しているかもしれません。 – Matt

+0

あなたはテーブルの学生に関するデータを持っています。これらのテーブルはさまざまなソースから来ています。学生の詳細は、複数のテーブルに存在することもあれば、1つだけに存在することもあります。古いキーを維持することも、新しいキーを使用することもできます。私はユニークな記録を保持する学生マスターテーブルを作る必要があります。重複レコードは存在してはならない。すべてのテーブルには異なるキーがありますが、別のテーブルでも異なるキーを使用しているのと同じレコードを指すことがあります。だからそれに近づく方法。 – Umesh

答えて

1

複雑です。最後に、あなたは次のようなものになりたいと思っています:

student (student_id PK, name, address, source1_id, source2_id, source3_id) 

しかし、そこに到達するために解決すべきいくつかの問題があります。

アイデンティティあなたが別のソースに一致するレコードを特定する方法

?あなたのソースはサロゲート識別子を使用しているようですが、ソースデータベースのコンテキスト外では意味がありません。あなたが探しているのは、適切な自然キーです。ソースの中の唯一の共通点は生徒の名前ですが、名前は悪名高いものです。

データを実際にテストして、動作するかどうかを判断するのではなく、役立つことがあります。例えば、のようなクエリ:

(student_source_2、student_source_3)及び(student_source_1、student_source_3)に対して繰り返さ
SELECT s1.name, COUNT(*) AS amount 
FROM student_source_1 s1 
INNER JOIN student_source_2 s2 ON s1.name = s2.name 
GROUP BY s1.name 
HAVING COUNT(*) > 1 

はあなたの問題の大きさにいくつかの洞察力を与える必要があります。

名前と住所の両方に基づいてstudent_source_2とstudent_source_3を一致させることができます。それは、2つの情報源が同じ学生のために異なる住所(またはその綴り)を有する場合、より良い結果をもたらすかもしれないし、悪化するかもしれない。それが私たちの第二の懸念に私たちをもたらします:

矛盾

あなたはアイデンティティの問題を解決できると仮定すると、あなたは一貫性のないデータに対処する必要があるかもしれません。ソース2と3が同じ学生の住所が異なる場合はどうなりますか?正しい住所はどうやって決めるのですか?

場合によっては、不整合を解決せずにソースをマッピングするだけで十分な場合もあります。私が困難な場合に使用

一つの技術は、例えば、手でマッピングテーブルを構築することである現実の世界でそれを巻取

student_map (student_id PK, source1_id, source2_id, source3_id) 

各source_id列には一意性制約があり、通常は3つすべてがNULL可能です。これは上の生徒の表への第一歩です。

完全な1対1マッチをすべて挿入してから、各ソースをマッピングテーブルに結合して、一致しないレコードを取得します。比類のないソースレコードを並べて並べ替えておくと、可能性のあるマッチを視覚的に簡単に見つけることができます。面倒でエラーが起こりやすい作業ですが、時にはそれを無関係に行う必要があります。不一致の場合、私は最も完全で最もよく見えるソースをベースとして選択し、他のソースからのギャップを埋めるかもしれません。あなたが実際の生徒に精通している教師や人を関与させることができ、あるいはそれらを選択するための選択肢を提示することができれば、是非それをしてください。

多くのデータは非常に便利です。ソースに社会保障番号や家族情報などがある場合は、これらを使用して学生を照合することができます。私は、さまざまな情報の間で完璧な一致を見つけるために任意の数のクエリを使用し、それらをサイド・バイ・サイド・マッチングを実行する前にマッピング・テーブルに挿入します。

ソースには設計が不適切なため内部的な一貫性の問題があることがよくわかります。同じ学生の複数の記録。これには、続行する前にソースデータを修正する必要があります。

データのリレーショナルモデルをよく理解することは、候補キーを特定し、依存関係に続いて異常が発生するため、この種の作業にとって非常に重要です。

関連する問題