筆者はファイルメーカーProを愛用している。ただし，まったくの個人ユースである。
何でも，自分なりにデータを集めて，処理に使っている。自分が使いやすいようにデータを集めているのである。
素材のデータはインターネット上に山のようにアップされている。しかし，表の形になっていたり，PDFだったり，複数のページに分散していたりする。検索エンジンで1回だけ検索して情報を得るだけなら，複数のサイトを見比べればだいたい必要な情報は入手できるが，いつも同じサイトに行き着くとは限らない。
そこで，データを手元に確保するために，ファイルメーカーを利用して，自分のデータベースを作っている。
現在なら，交通系ICカードの使用履歴をデータで読み出して，この情報から交通費精算をすることは比較的容易である。しかし最初は，履歴を確認するには駅の券売機で履歴をプリントアウトするしか方法がなかった。メモ帳に都度，利用区間と支払い額を手で記入しておいた方が早いぐらいだった。
仕事上の行先はほぼ固定されているので，20個程度の運賃データベースが手元にあれば，乗車駅と降車駅を入れるだけで運賃はすぐに出力できる。この程度ならExcelでもvlookup関数を使えばもちろん簡単にできる。データが出てこなければ，データベースにどんどん足していけば，次回には使える。
世の中の業務用の経理システムは，この運賃データベースを搭載して，すべての駅間での清算が可能になっているか，インタフェース（API）を使ってインターネット上のデータとリンクして運賃を検索して表示できるようになっていると思われる。毎年3月に行われるダイヤ改正で，運賃が大幅に変わることもある。手元のローカルのデータをいちいち更新するのは大変である。
いちおう筆者も，運賃検索サービスを利用して，データを自動で集める仕組みは作ってみた。関東地方にある約5000駅の相互の駅名を入力し，検索結果を取得してデータベース化する。機能的には合っているが，何しろ組み合わせが膨大なほか，ほとんどが知らない駅ばかりで，おそらく今後も行くことはなさそうなので，数を絞ってみた。それでもダイヤ改正のデータを適切に更新するほどの利用価値がないので，プロジェクトは途中で止まっている。
ここまで書いてきて，「結局，デジタルのいいところは“正規性”にある」と筆者は言えそうである。正規性とは，関係性が1:1で決まることであり，すべてテーブル（表）とキー（基準となる項目）でつながっている状態である。つまり，1つが決まれば，その属性がすべて一意に決まるということである。
筆者が作るデータベースは，必ず正規化されている。そして，筆者が望ましいと思うように多少のアレンジを加えている。したがって，筆者にとって使いやすいデータベースになっている。
一方，メタデータであるインターネット全体がデータベースであるメタデータベースでは，答えが1つではない。正規化されていない。検索エンジンなら，候補が山のように出てくるが，そこから検索者が判断して選ぶことができる。しかし生成AIは，勝手に決め打ちして提示してしまう。正規性がないのである。
生成AIがクイズ番組に回答者として出演したら，面白いことになるかもしれない。まあ，現在のクイズ番組のような出題の仕方だと，人間の回答者の方が速くて正確かもしれないが。
検索エンジンは，意味のないゴミみたいな情報までキーワードとして単純に見つけて表示するので，そこから意味のある情報を探し出すのに時間がかかった。生成AIは，このゴミみたいな情報は排除して絞り込んでくるが，どれが正解かは判断できない情報でまとめてくる。非常に危険である。
筆者は勝手に，当用漢字DBや2字熟語DB，苗字DB，銀行コード-支店コードDB，単位換算DBなどを構築している。たとえば2字熟語では，一般用語，専門用語，重要用語などで独自にランキング分けしたりしている。これも手元にデータがあるからこそできる評価である。わざわざ辞典DBを作ることはないと思っている。それは出版社の仕事である。
