Access (一般機能)

Accessの一般機能に関するフォーラムです。
  • 解決済みのトピックにはコメントできません。
このトピックは解決済みです。
質問

 
(Windows 10全般 : Access 2010)
柔軟性の高い検索
投稿日時: 18/05/07 16:21:59
投稿者: ひいらぎさとみ

通常のlike演算子では難しい、包含関係や異名を踏まえた検索の実装ができないかと考えております。
 
例えば
1)「イヌ」で包含関係にある「シェパード」「チワワ」「コッカスパニエル」etcを検索
2)「チン」で表記揺れに相当する「チン」「狆」を検索
3)「アメショー」で略称などに相当する「アメリカン・ショートヘア」「アメショー」「アメリカン・ショートヘアー」を検索
4)「シークワシャー」で「ヒラミレモン」「シークアーサー」「シークヮーサー」「シィクヮーサー」2を検索
 
「データをクレンジングする方がよい」という意見が出るのは承知の上ですが、それなりに需要がありそうな割に、めぼしい解説書を見ても全く触れているものがありませんでしたので、お伺いします。
 
包含関係、同義の検索を両方実現できれば望ましいのです。同音異義の区別はこの際どちらでも。 :?

投稿日時: 18/05/07 16:45:02
投稿者: ひいらぎさとみ

さらにぜーたくを申せば、
 「シークヮーサーには複数の品種があり、イシクニブ、フスブタ、タネブト、ミカングヮ、イングヮクニブ、ヒジャークニブ、カーアチー、カービシー、等・・・」
ということらしいので、表記揺れに加え、こういった下位概念も検索できるといいかと思っております

回答
投稿日時: 18/05/07 17:23:06
投稿者: sk

引用:
1)「イヌ」で包含関係にある「シェパード」「チワワ」「コッカスパニエル」etcを検索

・「シェパード」「チワワ」「コッカスパニエル」といった単語(犬種)を
 「イヌ」というカテゴリに含まれる単語として定義する辞書テーブルが必要。
 
引用:
2)「チン」で表記揺れに相当する「チン」「狆」を検索

・「狆」という単語とその読み「チン」を関連付ける索引テーブルが必要。
 
引用:
3)「アメショー」で略称などに相当する「アメリカン・ショートヘア」
「アメショー」「アメリカン・ショートヘアー」を検索

引用:
4)「シークワシャー」で「ヒラミレモン」「シークアーサー」
「シークヮーサー」「シィクヮーサー」2を検索

・(長音/促音/拗音/濁音/中黒等をどう扱うか次第ではあるが)
 類義語辞書に当たるテーブルが必要。
 
引用:
「データをクレンジングする方がよい」という意見が出るのは承知の上ですが、
それなりに需要がありそうな割に、めぼしい解説書を見ても全く触れている
ものがありませんでした

Access 自身にはそういう機能がありませんので。
(形態素解析や機械学習、テキストマイニングといった技術には対応していない)

回答
投稿日時: 18/05/07 17:31:34
投稿者: sk

引用:
さらにぜーたくを申せば、
 「シークヮーサーには複数の品種があり、イシクニブ、フスブタ、タネブト、ミカングヮ、イングヮクニブ、ヒジャークニブ、カーアチー、カービシー、等・・・」
ということらしいので、表記揺れに加え、こういった下位概念も検索できるといいかと思っております

そもそも、どういう構造のテーブルやテキストに対して
そういった検索機能を実装なさろうとしているのでしょうか。
 
例えば「 1 つのフィールドに特定の単語だけが記録されている」ケースだけではなく、
「今日、私は近所のスーパーでシークヮーサーを2個買いました。」といった自然文が
記録されているケースまで「イシクニブ」で検索したらヒットされるような
機能まで想定されているのでしょうか。

投稿日時: 18/05/07 17:49:27
投稿者: ひいらぎさとみ

sk さんの引用:
引用:
さらにぜーたくを申せば、

そもそも、どういう構造のテーブルやテキストに対して
そういった検索機能を実装なさろうとしているのでしょうか。
 
例えば「 1 つのフィールドに特定の単語だけが記録されている」ケースだけではなく、
「今日、私は近所のスーパーでシークヮーサーを2個買いました。」といった自然文が
記録されているケースまで「イシクニブ」で検索したらヒットされるような
機能まで想定されているのでしょうか。

自然文は想定していません。例えば書名のような固定した情報から抽出した種名がデータベースにカラムとして準備されているようなものとお考え下さい。その種名カラムを検索したいのですが、種名カラムのデータをクレンジングするというのが弊害が大きいという状況。
データは今後も追加されていくこと、バックグラウンドの違う不特定多数が検索することなどから、現時点でクレンジングしてもいずれ破綻する(現データはいずれかの段階で納品するもので、当方がメンテを続ける保障ができない)ため、検索側で吸収したいと考えたところです。
 
辞書テーブルを作るとしても、多層包含関係と類義語を包括してテーブルを作るというのは面倒そうなので先行例があればと思いました。
 

回答
投稿日時: 18/05/08 13:45:43
投稿者: sk

引用:
自然文は想定していません。例えば書名のような固定した情報から抽出した種名が
データベースにカラムとして準備されているようなものとお考え下さい。

引用:
その種名カラムを検索したいのですが、種名カラムのデータをクレンジングする
というのが弊害が大きいという状況。

その[種名カラム]自体の値が、レコードによって「アメリカン・ショートヘア」だったり
「アメショー」だったりする、という状態なのでしょうか。
 
引用:
データは今後も追加されていくこと、バックグラウンドの違う不特定多数が
検索することなどから、現時点でクレンジングしてもいずれ破綻する
(現データはいずれかの段階で納品するもので、当方がメンテを続ける
保障ができない)ため、検索側で吸収したいと考えたところです。

(どのような性質のデータベースであるのかが不明ですが)
そのデータベースの運用が開始された後、[種名カラム]に対する
データの追加/編集をユーザーが行なうのでしょうか。
 
引用:
辞書テーブルを作るとしても、多層包含関係と類義語を包括して
テーブルを作るというのは面倒そうなので先行例があればと思いました。

テーブルの構造をどう定義するか、という問題以上に、
そのテーブルに誰がどれだけの件数のレコードを追加するのか、
そのためにどれだけの手間暇が掛かりそうか、という問題の方が
深刻そうな気がしますけれど。
 
仮に辞書テーブルを定義するとすれば、例えば
以下のような構造が考えられます。
 
[T_単語辞書]
----------------------------------------------------------------------------
P 単語ID          長整数型/オートナンバー型
U 単語            テキスト型
  読み            テキスト型
  英語表記        テキスト型
  類義語          メモ型
F 上位カテゴリ    長整数型
----------------------------------------------------------------------------

・P は主キー, U はユニークキー, F は外部キー。
 
・[類義語]には複数の単語をカンマ区切りで格納。
 
・[上位カテゴリ]には、[T_単語辞書]自身と自己結合させるための
 いずれかの[単語ID]を格納。
 
(レコードの格納例)
----------------------------------------------------------------------------
単語ID	単語	読み	英語表記	類義語	上位カテゴリ
----------------------------------------------------------------------------
1	動物	ドウブツ	Animals	獣,けもの	0
2	植物	ショクブツ	Plants	草木,果実,くだもの	0
3	犬	イヌ	Dogs	わんわん,わんちゃん,いぬころ	1
4	ジャーマン・シェパード・ドッグ	ジャーマンシェパードドッグ	German Shepherd Dog		3
5	チワワ	チワワ	Chihuahua		3
6	アメリカン・コッカー・スパニエル	アメリカンコッカースパニエル	American Cocker Spaniel	アメリカンコッカスパニエル	3
7	狆	チン	Japanese Chin	ちんころ,Japanese Spaniel	3
8	アメリカン・ショートヘア	アメリカンショートヘア	American Shorthair	アメリカン・ショートヘアー,アメリカンショートヘアー,アメショー	3
9	柑橘類	カンキツルイ	Citrus	かんきつ類,柑きつ類	2
10	シークヮーサー	シークヮーサー	Citrus depressa	ヒラミレモン,シークアーサー,シィクヮーサー	9
11	イシクニブ	イシクニブ			10
12	フスブタ	フスブタ			10
13	タネブト	タネブト			10
14	ミカングヮ	ミカングヮ			10
15	イングヮクニブ	イングヮクニブ			10
16	ヒジャークニブ	ヒジャークニブ			10
17	カーアチー	カーアチー			10
18	カービシー	カービシー			10
----------------------------------------------------------------------------

(選択クエリ[Q_単語検索]の SQL ビュー)
----------------------------------------------------------------------------
PARAMETERS [キーワード] TEXT(255);
SELECT [T_単語辞書].*
FROM [T_単語辞書] LEFT JOIN [T_単語辞書] AS [T_上位カテゴリ] 
ON [T_単語辞書].[上位カテゴリ] = [T_上位カテゴリ].[単語ID] 
WHERE ([T_単語辞書].[単語] Like "*" & [キーワード] & "*") 
   OR ([T_単語辞書].[読み] Like "*" & [キーワード] & "*") 
   OR ([T_単語辞書].[英語表記] Like "*" & [キーワード] & "*") 
   OR ([T_単語辞書].[類義語] Like "*" & [キーワード] & "*") 
   OR ([T_上位カテゴリ].[単語] Like "*" & [キーワード] & "*") 
   OR ([T_上位カテゴリ].[読み] Like "*" & [キーワード] & "*") 
   OR ([T_上位カテゴリ].[英語表記] Like "*" & [キーワード] & "*") 
   OR ([T_上位カテゴリ].[類義語] Like "*" & [キーワード] & "*");
----------------------------------------------------------------------------

 
[T_単語辞書]単体で単語検索を行なう場合は
上記のクエリのような感じになるはず。

投稿日時: 18/05/08 18:04:48
投稿者: ひいらぎさとみ

sk さんの引用:
その[種名カラム]自体の値が、レコードによって「アメリカン・ショートヘア」だったり
「アメショー」だったりする、という状態なのでしょうか。

そういうことかと思います。
 
 
sk さんの引用:
引用:
データは今後も追加されていくこと、バックグラウンドの違う不特定多数が
検索することなどから、現時点でクレンジングしてもいずれ破綻する
(現データはいずれかの段階で納品するもので、当方がメンテを続ける
保障ができない)ため、検索側で吸収したいと考えたところです。

(どのような性質のデータベースであるのかが不明ですが)
そのデータベースの運用が開始された後、[種名カラム]に対する
データの追加/編集をユーザーが行なうのでしょうか。

実は当方と無関係な業者によりすでに運用は開始しています。かなり問題の多いデータで自分で一からやり直した方がきれいになりそうですが、クライアントにそういう指示は受けてないので、今のデータ本体を生かしつつ、少しでも使いやすくする提案を考えているところ。データの追加はユーザーがやる場合もありますし、そうでない場合もあり、一言では言えません。
 
サンプルによる動作は確認しました。ありがとうございます。やはり力業、ということなのかと思います。色々付随する問題が出るかもしれず当初よりは後ろ向きになりました。サンプルはサンプルとしてクライアントに提示してみることぐらいかな、と思います。