多度大社

全体検索

人物・会・祭事・帳票・要件・画面を横断して検索します

データ品質・名寄せ

ID統合(FM/Access)・品質チェック・重複候補・ハブ未登録会員の名寄せ・移行対象の整理。移行の精度と作業量を決める画面群。

移行元ごとの扱い(要件定義書 4.2節)。「残す」は構造を変えて統合、「再構成」は新しいデータモデルに作り直し、「置換」は画面で置き換える。移行しないものは設定の「移行対象外」に一覧がある。

移行元扱い内容確認事項
崇敬者マスター.mdb(ハブ)残す13,276行。統合Personマスターの土台。FM顧客マスターとID対応を確定して適用
崇敬会.mdb/総代会.mdb/ふいご管理.mdb残す会員資格(Membership)・役職・入金に再構成。別用途の帳票3本(崇敬会)は移行しない
神馬会.mdb残す会員名簿1,001行(ハブ紐付け7.0%)は名寄せが必要。旧名簿(一般会員78件)は移行しない
多度講管理.mdb残す講員6,633人(退講者3,199人を含む。ハブ対応30.5%)。保存期間は確認事項 #30確認 #30
祈年祭.mdb/新嘗祭管理.mdb/多度祭管理.mdb再構成案内先の台帳(人×祭事)と年次の名簿確定に統合。祈年祭2などの残骸は移行しない
節分祭.mdb再構成実人数803を名寄せ(約6割は新規)。履歴は年度別の参加として移行。旧2表(372件・603件)は移行しない確認 #25
遺族会.mdb再構成支部31行の台帳+年度別の頒布実績(新設)。来賓TBLあああは要確認確認 #28
社報.mdb再構成社報tblは廃止。購読・送付履歴・刊行物・町内→組→戸数に再構成
年賀状.mdb再構成宛先ロジック(5条項)を年度別の宛先管理へ。賀勢名簿(519行)は移行しない確認 #22
メニューフォーム.mdb置換ホームの「今やる業務」とナビ項目の設定に置き換える確認 #27
FileMaker 顧客管理(★顧客管理.fmp12)残す祈祷明細139,167件(個人129,037・法人10,130)、大祓履歴39,257件、夏祭履歴23,790件。AccessとFMの正本は要確認確認 #2
未受領のDB(祈祷フォーム・祈祷管理法人・記念事業 ほか)要確認現存するか、提供可能か。FMの祈祷明細とどちらが正かも確認 #5
移行手順の骨子(4.3節)
  1. 確定済みのID対応(ハブ⇔FM顧客マスター)を適用してPersonの土台を作る
  2. 崇敬者IDを持つ各DBのMembership/Position/参加を、崇敬者ID経由でPersonに連結
  3. 崇敬者IDを持たない対象(多度講・神馬会・節分祭)を氏名+住所で名寄せし、候補提示→人手確認
  4. ハブの同一住所グループとFMの家族_IDから世帯を確定
  5. データクレンジング(NFKC正規化・法人名統一・郵便番号7桁化・旧地名の読み替え)
  6. 移行リハーサルと新旧の件数照合
  7. 切替(会費・入金が集中する3月と、出欠はがきの10〜11月を避ける)
移行時のリスク(4.4節)
  • 二重入力の継続:取込後にAccessで新規登録された387件のうち51.9%(201件)がFM未紐付け
  • FM側の未完成機能:FMを単純に正本とはできない(入金記録が2021年3月ごろ停止の可能性)
  • 孤立レコードの扱い:各DBで0〜14.2%。人物を特定できない場合の方針
  • 個人情報の受け渡し:FMレコードの書き出し・突合の方式(暗号化・ハッシュ照合)を事前に合意
  • 他テーブルのFM実データ突合が未実施:移行計画の精度はこの結果に依存