はじめに
前回までは会員テーブルのみの更新処理を紹介しました。最終回となる今回は、関連するテーブルの更新を含め、名寄せにあたって考慮すべき点について紹介します。
- 関連テーブルの更新処理
- トランザクション処理
- 排他制御
対応可能なRDB
MySQL（4.1以上）、SQL Server、Access、PostgreSQL、OracleなどのRDBで可能です。
ただし、EXISTS演算子とサブクエリーが利用できないSQLiteでは不可です。
必要となる前提知識と環境
前半部分はSQL命令の解説になるので、SQLの基礎知識が前提となります。
後半部分は各回を通して、ASP.NET開発の基礎知識（SQL Serverへのアクセス方法、MultiViewコントロールの使い方を含む）、および以下の環境が前提となります。
- 開発ツール：Visual Web Developer 2010 Express SP1（以下、VWD2010と略記）
- 開発言語など：Visual Basic（以下、VBと略記）、コードビハインドモデルで開発
- 使用データベース：SQL Server 2008 Express Edition SP1
【理論編】名寄せに関連して必要になる処理
RDBシステムであれば当然、会員テーブルに関連した（Relational）テーブルがあるはずです。会員テーブルの名寄せに連動して、関連テーブルの更新を含め、必要になる処理を紹介します。
RDBの正規化について
本項はご存じであれば読み飛ばしていただいて結構です。
Excelのような表計算ソフトを使って、会員管理を手作業で行っている場合は、下図のような表でも支障はないでしょう。
しかし、RDBではプログラミングを単純化するため、「正規化」という作業が重要です。通常、第3正規化（データ内の繰り返し部分をなくし、主キー以外の列が主キーのみによって決まるように、テーブルの分割などを行う）までを行います。
関連テーブルの更新処理
正規化されたRDBであれば、会員テーブルの名寄せを行った後、関連テーブル（前項の例では、MemberService）の更新を行うだけで事足ります。これ以外にも例えば「担当トレーナー情報」や「会費納入記録」などのテーブルがあるかもしれませんが、更新が必要なのは会員IDを外部キーに持ち、直接関連するテーブルだけでいいはずです。
なお、関連テーブルには、第2回の会員テーブルと同様、「状況」列と「名寄せ先ID」列を追加し、誤操作だった場合の復元手段を確保するものとします。
会員テーブルの名寄せにより、3つの会員IDを持っていた「渡辺京子」の会員IDは新たに払い出した「46071」になります。関連テーブルでは、元の会員IDを持つレコードを名寄せされたものとして処理します。その上で会員IDが「46071」、サービスIDが「名寄せ元のサービスID」のレコードを新規に作成します。ただし、「名寄せ元のサービスID」が重複するレコードは作成しないようにしなければなりません。
RDBの中にはテーブル間にリレーションを作成し、主キーの変更に伴って外部キーを自動的に変更する機能を持つものもありますが、重複レコードを除く必要があるため、その機能では対応できません。
「名寄せ元のサービスID」を重複しないように取り出すため、DISTINCT句を使ったSQL命令は以下のようになります。
SELECT DISTINCT ServiceID FROM MemberService WHERE MemberID IN (4286,29153,30993)
また、名寄せした後で会員ID「29153」は別人であったことが分かった場合、会員テーブルと関連テーブルを復元する手順は、下図のようになります。
なお、上記の処理が適さない関連テーブル（下図参照）も考えられます。
ここでは単純な更新処理のみ説明しますが、お使いのシステムに応じて適切なテーブル更新処理を行うようにしてください。
