AccScan
技術

Access移行前のデータクレンジング|表記ゆれ・重複・欠損の直し方

表記ゆれ・重複レコード・欠損値・型不統一の4類型を移行前に整備する実務手順。重複検索クエリウィザードと更新クエリを使った具体的な対処法と、クレンジング作業の優先順位の付け方を解説します。

まずは、自社のAccessが「解析できるか」を無料で確認できます。

約2分・ファイル送信不要・発注義務なし

結論:移行前にデータを整えると、移行後の手戻りが大幅に減る

Access移行のプロジェクトで、移行後になって「住所の表記がバラバラで検索が当たらない」「顧客が重複していてどれが正しいかわからない」といった問題が出るケースがあります。当社の経験では、こうした問題の多くは、移行前のデータクレンジング(データ品質の整備)で軽減できることが多いです。

当社の経験では、移行先の入力規則が旧環境より厳しい案件(NOT NULL制約・一意制約を新たに設けたケース等)では、移行後にデータを修正しようとすると稼働中のシステムに影響が出るため、移行前に整備した方が安全です。移行前に1週間かけてデータを整えた案件の方が、移行後トラブルは少ない傾向があります(当社実務経験)。

この記事では、Access移行前に整備すべきデータ品質の問題を類型化し、Accessのクエリ機能を使った具体的な対処手順を解説します。テーブルやデータの移行作業そのものはデータだけ先に移す記事に譲り、ここはデータ品質の整備に絞ります。

よくある5つのデータ品質問題

Access移行前にチェックすべき問題を類型ごとに整理します。

問題の種類具体例移行後に起きること
表記ゆれ「株式会社」と「(株)」が混在、全角と半角が混在名寄せ・集計で同一レコードが別カウントされる
重複レコード顧客や商品が複数回登録されている移行後システムの一意制約に引っかかる、または二重管理が続く
欠損・不正値必須項目が空白、日付を格納するテキスト型フィールドに「未定」などの文字列が入っている移行先のNOT NULL制約やデータ型制約でエラーになる
書式の不統一電話番号の書式が「03-1234-5678」「0312345678」で混在、郵便番号のハイフンあり/なしが混在完全一致検索や文字列照合で一致しない場合がある
コード体系の乱れ区分フィールドに「1」「1」「A」「a」など複数表記が存在移行先でマスタとの照合が崩れる

表記ゆれ・全角半角の修正:更新クエリを使う

表記ゆれの修正には、Accessの更新クエリ(UPDATE クエリ)が便利です。更新クエリはテーブルのレコードを一括で書き換えられ、条件を指定した部分的な修正も可能です(UPDATE 文の構文 — Microsoft Learn)。

手順は次のとおりです。まず「作成」タブ →「クエリデザイン」で対象テーブルを追加し、選択クエリとして修正対象のレコードを絞り込みます。絞り込み結果を確認してから「デザイン」タブ →「更新」でアクションクエリに切り替え、「レコードの更新」行に新しい値を入力して実行します。更新クエリは元に戻せないため、実行前に必ずバックアップを取ることが鉄則です(公式ドキュメントも同様に推奨しています)。

全角半角の統一には、AccessのVBAで StrConv 関数が使えます。たとえば半角カタカナを全角に変換するなら定数 vbWide(数値4)、全角英数字を半角にするなら vbNarrow(数値8)を指定します。ただしこれらの変換は日本語環境(東アジアロケール)を前提にしており、環境によっては動作が変わる場合があります。会社名の表記(「株式会社」と「(株)」の統一)はAccessの標準クエリ式には正規表現置換関数がないため、固定文字列なら Replace 関数で対処します。複雑なパターンが多い場合はVBAで処理をループさせるか、Excelにエクスポートして整形してから戻す方が安全です。

修正量が多いと感じた場合は、テーブル正規化の記事も参考にしてください。そもそも設計の段階で入力を制限する仕組みを入れておくと、表記ゆれは起きにくくなります。

重複レコードの検出と名寄せ:重複クエリウィザードを使う

重複レコードの検出には、Accessの「重複検索クエリウィザード」が使えます。「作成」タブ →「クエリウィザード」→「重複検索クエリウィザード」を選び、対象テーブルと照合するフィールドを指定すると、指定フィールドの値が一致するレコードの一覧を出力できます(重複レコードをクエリで検索する — Microsoft Support)。ただしこのウィザードは指定フィールドの「値の一致」を基準にするため、「株式会社ABC」と「(株)ABC」のように表記が異なる同一顧客は、そのままでは検出できません。表記ゆれを含む名寄せでは、先に比較用の正規化列(記号や空白を除いた値)を作るか、電話番号・住所など別の識別項目を組み合わせて抽出します。

検出後の対処は「名寄せ」と「削除」に分かれます。名寄せとは、複数の重複レコードを1件に統合することで、たとえば同じ顧客が2つの名前表記で登録されている場合、正規のレコードを決めて取引履歴を付け替え、もう片方を削除します。手順は多いですが、移行後にシステム側の一意制約でエラーが出るよりも、事前に整理した方が確実です。

重複レコードを削除する際は、必ず残すレコードを主キーなどで一意に特定してから削除対象のIDだけを抽出します。主キーなどの一意キーがないテーブルでは、重複行のうち削除する行だけを一意に指定できず、条件に一致した行がまとめて消えてしまう恐れがあります。まず主キーを設定するか、一意IDを付与した作業用コピーを作り、そのIDで削除対象を指定してください。削除クエリの手順はMicrosoftのサポートページでも確認できますが、「一意に特定できるまで削除しない」を鉄則にしてください(重複レコードをクエリで削除する — Microsoft Support)。削除クエリは実行前に選択クエリとして対象を確認し、人の目で正しいと確認してから切り替えるのが原則です。

名寄せ作業の規模が大きい場合は、Excelで整理してからインポートし直す方が早い場合もあります。ただしExcelはCSVをダブルクリックで開くと先頭ゼロの削除や長い数値の自動変換が起きるため、「データ」→「テキスト/CSVから」でインポートして対象列をテキスト型に指定してから作業してください。インポート前後で主キーと件数を検証することも必須です。どちらの方法が向くかはレコード数と重複の性質によって変わります。

欠損・不正値の洗い出しと対処

欠損値(NULLや空白)の洗い出しには選択クエリの抽出条件が使えます。たとえば「顧客名」フィールドが空白のレコードを探すには、抽出条件に Is Null または ""(空文字)を指定します。NULLと空文字は異なる扱いになるため、両方を確認する必要があります。

不正値の典型は、日付を格納しているテキスト型フィールドに「未定」「確認中」といった文字列が混入しているケースです。AccessのDate/Time型フィールドは日付・時刻以外の値を受け付けないため、こうした混入は短いテキスト型フィールドで起きます。このままでは移行先システムの日付型カラムに変換できずエラーになります。これらは移行前に空欄にするか、別のフィールドへ移しておく必要があります。

移行先がSQL Serverの場合、NOT NULL制約を持つカラムへの移行では欠損値の扱いに特に注意が要ります。SSMAを使ったデータ移行では、NULL値があるフィールドがNOT NULL制約に引っかかると移行時にエラーになります。どのフィールドにNOT NULL制約を付けるかは移行設計の段階で決め、それに合わせてデータ側を事前に整備しておきます。

書式の不統一・コード体系の整備

電話番号や郵便番号は、ハイフンあり/なし、全角/半角、桁数の揺れなど複数の問題が重なりやすいフィールドです。移行後のシステムで検索や照合を正確に動かすには、移行前に書式を統一しておく必要があります。

郵便番号の場合、7桁ハイフンなし(1234567)に統一するには、まず StrConv([郵便番号], 8)(vbNarrow)で数字とハイフンを半角に変換してから、Replace(..., "-", "") でハイフンを除去します。全角のハイフンや空白が混在している場合は除去対象を増やす必要があります。変換後は、Len関数が7以外の値を返すレコードを選択クエリで抜き出して個別に確認します。

区分フィールドのコード体系は、「1」と「1」(全角数字)が混在しているケースがあります。全角と半角は異なる文字列として格納されますが、比較時に区別されるかはAccessおよびSQL Serverの照合順序に依存します。移行時の差異を避けるため、事前に表記を統一しておくのが安全です。StrConvで変換した後は、変換前後の値が正しく揃っているかを選択クエリで確認します。コード体系の整備はクエリ入門の記事で解説した選択クエリと更新クエリを組み合わせて対処します。

整備作業が一段落したら、実際の移行に向けた調査として移行プロジェクトの進め方も確認しておくと、作業の全体像がつかめます。

データ品質の整備と並行して、現状のAccessが移行に適した状態かどうかを確認したい場合は、無料の解析可否チェックをご利用ください。

クレンジング作業の進め方:優先順位をつける

全テーブルを完璧にクレンジングしてから移行しようとすると、作業が終わらない場合があります。当社では、移行に影響する問題に絞った優先順位付けをお勧めしています。

最優先で対処すべきは、移行先システムで制約エラーになる問題です。具体的には、移行先のNOT NULL制約やデータ型制約に引っかかる欠損・不正値、一意制約に引っかかる重複レコードです。こうした問題を放置すると、該当行や対象テーブルの移行が失敗し、移行作業を中断・再実行する原因になります。

次に対処するのは、移行後の業務に直接影響する問題です。集計・検索・帳票に使う項目の表記ゆれや型不統一がここに該当します。逆に言えば、移行後に使わなくなるフィールドの表記ゆれは、後回しにしてよい場合もあります。

どのテーブルが移行後に重要かは、業務フロー調査の段階で把握しておくと作業効率が上がります(業務フロー調査の記事も参考にしてください)。

よくある質問

Q. 重複クエリウィザードはどこにありますか。

「作成」タブ →「クエリウィザード」をクリックし、表示された「新しいクエリ」ダイアログで「重複検索クエリウィザード」を選びます。テーブルを選択した後、照合するフィールド(たとえば「顧客名」と「住所」)を指定すると、その組み合わせで値が一致するレコードを一覧で出力するクエリが自動生成されます。

Q. 更新クエリを使う前に注意することは何ですか。

必ずバックアップを取ってください。更新クエリはアクションクエリの一種で、実行すると元に戻せません(更新クエリの作成と実行 — Microsoft Support)。更新クエリを作るときは、先に選択クエリとして実行して対象レコードが正しいことを確認してからアクションクエリに切り替えるのが安全です。

Q. NULLと空文字("")は同じですか。

Accessでは異なる値として扱われます。NULLはフィールドにデータが入っていない状態、空文字は長さ0の文字列が入っている状態です。欠損値を洗い出す際は、Is Null= "" の両方を確認してください。移行先がSQL Serverの場合、NULLとnvarchar型の空文字列も別として扱われるため、どちらに統一するかを移行設計の段階で決めておく必要があります。

Q. データクレンジングにどのくらい時間がかかりますか。

テーブル数・レコード数・問題の種類によって大きく変わります。当社の実務経験では、5〜10テーブル規模で数百件の修正が必要な場合、洗い出しから修正確認まで3〜5日程度かかることが多いです。先に洗い出しだけ行って問題の規模を把握してから、修正に入る順序を決めると見通しが立てやすくなります。

触れないAccessが「診断できるか」だけ、確かめませんか。

顧客データは送信不要。発注の義務もありません。

約2分・ファイル送信不要・発注義務なし/説明はオンライン・売り込みはしません