SharePoint のリストでカスケード分類っぽいことを実現してみる
カスケード分類とは、国→県→町 のように上位の選択により下位が絞り込まれるような構造の分類情報です。日本語だと「階段状」とか「入れ子」とか言うらしいですけど。
で、このカスケード分類機能ですが、SharePoint にはありません。SharePoint は、分類（列）自体はいくつでも持つことが出来るのですが、その分類に、相互に関連性をもたせることが出来ないのです。Notes からデータを移行する際、この点が結構痛いです。SharePoint の製品仕様的には、深い階層を持たせたい場合は、リストでなくドキュメントライブラリのフォルダを利用して欲しい、ということなんだと思いますが…。
それで、結局、どうしているかと言いますと、カスケードを、半ば無理矢理、1行テキストに変換して、運用しています。例えばノーツでは 大分類 > 中分類 > 小分類（フィールド×3)だったものを、MOSS では、
大分類1-中分類1-小分類1
大分類1-中分類2-小分類2
大分類1-中分類2-小分類3
大分類2-中分類3-小分類4
大分類2-中分類3-小分類5
大分類1-中分類1-小分類1
大分類1-中分類1-小分類1
…
こんな感じで、ひとつの「分類」列（ドロップダウン選択）で表現する訳です。う～ん、つくづく無理矢理だ（苦笑）
しかし、当然ですが、このままでは使い勝手がよろしくありません。一行が、それぞれ独自の値として扱われてしまうため、例えば「大分類が A のものだけ」とフィルタをかけることや、グループ化が出来ません。
そこで、SharePoint 標準の関数を利用して、この「分類」値を分解してみました。ここでは、基準になる列名を「分類」、区切り値を「-」としています。
「大分類」「中分類」「小分類」という名の、集計値列を3つ作成し、其々に以下の数式を設定します。
大分類：=LEFT(分類,SEARCH(“-”,分類,1)-1)
中分類：=RIGHT(LEFT(分類,SEARCH(“-”,分類,SEARCH(“-”,分類,1)+1)-1),LEN(LEFT(分類,SEARCH(“-”,分類,SEARCH(“-”,分類,1)+1)-1))-SEARCH(“-”,分類,1))
小分類：=RIGHT(分類,LEN(分類)-SEARCH(“-”,分類,SEARCH(“-”,分類,1)+1))
これで、こんな風になります。
しかし、この例では、よほど関数に明るい方でないと、何をしているのか判りにくいと思います。
そこで、同じ処理を 8 つの列に分解してみます。
計算1：=SEARCH(“-”,分類,1) ※最初の - の出現位置
計算2：=SEARCH(“-”,分類,計算1+1) ※2回目の - の出現位置
計算3：=LEFT(分類,計算2-1) ※大分類-中分類を返す
大分類：=LEFT(分類,計算1-1)
計算4：=LEN(計算3)-計算1 ※- - 間の文字数を返す
中分類：=RIGHT(計算3,計算4)
計算5：=LEN(分類)-計算2 ※2回目の -より後ろの文字数を返す
小分類：=RIGHT(分類,計算5)
LEN 関数で文字数を算出し、SEARCH 関数で - の位置を特定し、それをもとに RIGHT 関数、LEFT 関数で文字列を拾っています。
しかし、こうしてみると SharePoint 2007 で利用できる関数はかなり貧弱ですね。この程度のことにかなり四苦八苦しました。同じ Office 製品なんですから、Excel で利用できる関数は、SharePoint でも利用できるようにして欲しいなぁ。
Windows SharePoint Services 3.0 のヘルプと使い方＞数式と関数
SharePoint2007 で利用できる関数とそのお作法
Infopath2003 を利用して、階層型（カスケード）分類選択を実現する
SharePointでダイナミックな分類選択を可能にする Query Based Lookup Field
中村 和彦（
AGENT: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; InfoPath.2; MS-RTC LM 8; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618; OfficeLiveConnector.1.4; OfficeLivePatch.1.3)
お疲れ様です。
関数・・・ほんと苦戦します。
そして、関数の多用で起きた障害、リスト表\示のレスポンスが、異常に遅くなりました。
いくつかの関数を組み合わせることで、結構\色々なことが出来るのですが、大きめのリストに適用すると、ユーザーから大クレームが帰ってきます（苦笑）
関数によって導き出される結果も、DB側に保持されないものでしょうか。そうすれば『計算列を参照』なんてこともできそうですよね。
AGENT: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; InfoPath.1)
お疲れ様です！
あれ？関数の計算結果ってDBに保存されないんですか？
集計列を作成する際に、アイテム数が多いリストだとそこそこ時間がかかるので、てっきり保存されているとばかり思っていました…。
レスポンスに関しては要検証ですね。
ありがとうございます！
AGENT: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; InfoPath.2; MS-RTC LM 8; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618; OfficeLiveConnector.1.4; OfficeLivePatch.1.3)
お疲れ様です。
> あれ？関数の計算結果ってDBに保存されないんですか？
！！
自分の勝手な思い込みかもしれません。。。
でも、集計列を多用するとレスポンスが悪くなると書いてあったような・・・
定かではありません。
あいまいな情報でスイマセン。
AGENT: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 2.0.50727; Sleipnir/2.8.5)
初めまして，kenchinziruと申\します。
この記事を見てなるほどと思ったので，自分で作ってみたら気がついたのでコメントします。
逆に「大分類」「中分類」「小分類」を入力させてから「カテゴリ」を計算すれば簡単です。
苦手な関数も，次のように一つ書けばイイですし。
=[大分類]&\”-\”&[中分類]&\”-\”&[小分類]
やってみたら，大分類，中分類でフィルタする事ができますので，絞り込めます。
もちろん，ビューに表\示させていないとできませんが。
どうでしょうか。
それと「インデックス付きの列」には計算した列が指定できないようなので，代わりにそれぞれの分類を指定すれば，多少なりとも早くなりそうですね（未検証）。
AGENT: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.2; .NET CLR 3.0.04506.30)
kenさま、はじめまして！
コメントありがとうございます。
そうですね〜確かに大中小分類を単独の列にしてしまえば簡単なのですが、するとカスケードが出来なくありませんか？
地方＞県＞市 のような階層情報を定義したい場合、列をわけてしまうと、列間で関連性を持たせることは出来ないんじゃないかと思いますよ。
（出来たらぜひ教えてください＾＾;;;）