名寄せに関連して必要になる処理
―ASP.NETでの実装方法

既存のRDBシステムに会員情報の名寄せ機能を追加する 第3回

　会員情報を含むRDBシステムでは、同じ人が別々のIDでテーブルに登録されることがありえます。本連載では、二重登録状態を解消する「名寄せ」機能の追加方法を紹介します。

はじめに

　前回までは会員テーブルのみの更新処理を紹介しました。最終回となる今回は、関連するテーブルの更新を含め、名寄せにあたって考慮すべき点について紹介します。

1. 関連テーブルの更新処理
2. トランザクション処理
3. 排他制御

対応可能なRDB

　MySQL（4.1以上）、SQL Server、Access、PostgreSQL、OracleなどのRDBで可能です。

　ただし、EXISTS演算子とサブクエリーが利用できないSQLiteでは不可です。

必要となる前提知識と環境

　前半部分はSQL命令の解説になるので、SQLの基礎知識が前提となります。

　後半部分は各回を通して、ASP.NET開発の基礎知識（SQL Serverへのアクセス方法、MultiViewコントロールの使い方を含む）、および以下の環境が前提となります。

1. 開発ツール：Visual Web Developer 2010 Express SP1（以下、VWD2010と略記）
2. 開発言語など：Visual Basic（以下、VBと略記）、コードビハインドモデルで開発
3. 使用データベース：SQL Server 2008 Express Edition SP1

【理論編】名寄せに関連して必要になる処理

　RDBシステムであれば当然、会員テーブルに関連した（Relational）テーブルがあるはずです。会員テーブルの名寄せに連動して、関連テーブルの更新を含め、必要になる処理を紹介します。

RDBの正規化について

　本項はご存じであれば読み飛ばしていただいて結構です。

　Excelのような表計算ソフトを使って、会員管理を手作業で行っている場合は、下図のような表でも支障はないでしょう。

図1．正規化されていない会員管理表

　しかし、RDBではプログラミングを単純化するため、「正規化」という作業が重要です。通常、第3正規化（データ内の繰り返し部分をなくし、主キー以外の列が主キーのみによって決まるように、テーブルの分割などを行う）までを行います。

図2．正規化されたテーブル群

関連テーブルの更新処理

　正規化されたRDBであれば、会員テーブルの名寄せを行った後、関連テーブル（前項の例では、MemberService）の更新を行うだけで事足ります。これ以外にも例えば「担当トレーナー情報」や「会費納入記録」などのテーブルがあるかもしれませんが、更新が必要なのは会員IDを外部キーに持ち、直接関連するテーブルだけでいいはずです。

　なお、関連テーブルには、第2回の会員テーブルと同様、「状況」列と「名寄せ先ID」列を追加し、誤操作だった場合の復元手段を確保するものとします。

　会員テーブルの名寄せにより、3つの会員IDを持っていた「渡辺京子」の会員IDは新たに払い出した「46071」になります。関連テーブルでは、元の会員IDを持つレコードを名寄せされたものとして処理します。その上で会員IDが「46071」、サービスIDが「名寄せ元のサービスID」のレコードを新規に作成します。ただし、「名寄せ元のサービスID」が重複するレコードは作成しないようにしなければなりません。

図3．会員テーブルと関連テーブルの名寄せ処理

　RDBの中にはテーブル間にリレーションを作成し、主キーの変更に伴って外部キーを自動的に変更する機能を持つものもありますが、重複レコードを除く必要があるため、その機能では対応できません。

　「名寄せ元のサービスID」を重複しないように取り出すため、DISTINCT句を使ったSQL命令は以下のようになります。

リスト1　名寄せ元のサービスID」を重複しないように取り出すSQL命令

SELECT DISTINCT ServiceID FROM MemberService WHERE MemberID IN (4286,29153,30993) 

　また、名寄せした後で会員ID「29153」は別人であったことが分かった場合、会員テーブルと関連テーブルを復元する手順は、下図のようになります。

図4．誤操作だった場合の会員／関連テーブルの復元手順

　なお、上記の処理が適さない関連テーブル（下図参照）も考えられます。

図5．関連テーブル処理のさまざまな例

　ここでは単純な更新処理のみ説明しますが、お使いのシステムに応じて適切なテーブル更新処理を行うようにしてください。