202406DominoHub データそのまま丸裸

-DominoHub 2024- 2024/06/13 忘れちゃった？ Notes は データそのままで 丸裸にできるって 阿部 覚 (X:) @abesat

ごあいさつ Domino まわりでやってることと、 この場ほかの場での属性： ✋XPages.JP にて 「 DX Today じゃぱ～～ん ! 」の掲示役をしています ✋月イチ「のの会」にて「＠関数 Talk 」をやってます 2015 IBM Champion, 2020-2024 HCL Ambassador

DX Today じゃぱ～～ん！ https://www.xpages.jp/Japan/ctjp.nsf/home.xsp (X:) @DXTodayJapan

• https://www.xpages.jp/Japan/ctjp.nsf/home.xsp

のの会 https://notesknows.connpass.com/

• https://notesknows.connpass.com/

のの会 https://notesknows.connpass.com/

• https://notesknows.connpass.com/

のの会 https://notesknows.connpass.com/

• https://notesknows.connpass.com/

忘れちゃった？ 「丸裸」 …というたとえをするからには Notes は それに対する「衣」👚があるわけで データそのままで それって 丸裸にできるって 7 / 40

「設計要素」 です 8 / 40

ここで Notes Domino 以外の製品…わかりやすいところでは たとえば、 Excel などの表計算シートを 想像いただければと思います セルの中には書き込まれたデータも入れば 式が入っていることもあります 表計算シートで「設計」と「データ」の境目は混沌曖昧 といった印象があります 9 / 40

あるいは、 Oracle, SQL Server … など リレーショナルなデータベース製品 (RDB) をご経験の方 主キーが存在しなくちゃならない とか キーはユニークじゃなくてはならない とか 関連テーブルとの間の参照制約 とか 各種制約があって それらを踏まえた正規化設計をして しっかり作らなきゃなりません 要するに、設計通りでないデータの存在が 許されないつくりです 10 / 40

Domino と競合するソリューションのいくつかでは 設計にこんな制約があったりしませんか？ ・フォームレイアウトに新たな項目を追加すると 既存のすべてのレコードに その項目が追加される （値は NULL だったり所定の初期値だったり） ・フォームレイアウトから項目を削除すると 既存のすべてのレコードから その項目が値ごと削除されてしまう 11 / 40

あるいは、ビューと密接に結び付き Notes Domino でいえば、ビューの列項目を作ることで フィールドとその見出しが設定されるものもありますね 多くのソリューションでは 設計とデータは 一体、もしくは連動したものになっていると思います 12 / 40

Notes Domino の場合、そのどちらでもなく 設計は確かに存在するけど データを作ったり変えたり見たりするのに使うんだけど でも、設計とデータはけっこう明確に分離しています 設計の変更が即時にデータに影響を及ぼすってことは 基本ないと思います 13 / 40

Notes Domino で 設計とデータの紐づきといわれて まず思い浮かぶ設計要素は「フォーム」ですが 設計要素「フォーム」とデータ（文書）とは "Form" という予約フィールドを通して ゆるーく結びついているに過ぎないです 14 / 40

Notes Domino で フォーム設計がデータに影響を及ぼすタイミングって ほぼ、これくらいでは？ ◎作成・編集画面から画面更新・保存したとき ○コード上でフォーム情報を反映して保存したとき たとえば LotusScript で ComputeWithForm を行ってから Save 15 / 40

例外として フォームを文書に格納（保存）する オプションを設定した場合 Form フィールドは使われずに 設計とフォームが一体化されます （そんなに利用されてないかな…） 16 / 40

例外として おなじ Domino でも Domino Leap については 従来の Notes DB アプリと構造が違うところがあり 設計とデータが連動し 項目の変更がデータに影響を与えることがあるそうです 17 / 40

だから、たとえば… Notes Domino の DB アプリから 設計要素だけが無くなっちゃっても データは直接の影響を受けません 18 / 40

実際にやっちゃうかどうかは いろいろ難しいとは思いますが 仮にそれをやる 👿👹とすれば ①設計要素を片っ端から消す ②設計要素がないテンプレートで設計置換する 19 / 40

DB 内を「データだけ」にしちゃう 👿👹 ①設計要素を地味に片っ端から消しまくっちゃう ビューは最低１つ必要など、消せないものもあります 20 / 40

DB 内を「データだけ」にしちゃう 👿👹 ②設計要素のないテンプレートを作って 設計の置き換えをやっちゃう ただしこちらの方法では このチェックが入っている設計要素が 消えない場合がありますけど 21 / 40

じゃあ、そうやって丸裸になった DB アプリについて 予備知識なしにどんなデータが入っているかを 吟味するとします せっかく丸裸にしたところをナンですが、 こうした場合のために ・ひとつのビュー ・ひとつのフォーム を追加します ✋以下、 2023 年の 「のの会 / @ 関数 Talk 」からの流用です 22 / 40

ひとつのビュー どんな文書でもとりあえず 多少は中身を表示してくれるビュー 23 / 40

どんな文書でもとりあえず 多少は中身を表示してくれるビュー： どんな文書でも表示するという前提で ビューの選択は、簡易検索なら条件なし 式を入れるなら SELECT @All にしておきます

どんな文書でもとりあえず 多少は中身を表示してくれるビュー： とことんどんな文書でも表示するという前提で ビュープロパティの 「返答文書を階層表示する」には チェックを入れないことをおすすめ まんいち、「迷子の返答文書」があっても表示されます これで、権限がないのでない限りは すべての文書がビューに表示されるはず 25 / 40

どんな文書でもとりあえず 多少は中身を表示してくれるビュー： 列ごとに、 " @DocFields の○個目 " の 「フィールド ID 」と、（可能なら）「その内容」を 表示しています 26 / 40

実は @DocFields という関数、ヘルプ上では ビュー列式では使えないことになっています 文書が保存される時点の画面 UI から情報をもらうらしく ビュー上の表示にずれがありうるためでは。。 27 / 40

フィールドの数分だけ列を作るわけにもゆかないので ビュー上で全部のフィールドを出すのには無理がある点 💦 リッチテキストは中味が表示されない点にご注意ください あくまで予備知識なしに概略をつかむ目的なので 28 / 40

なお、ここでは、 次に紹介する、ひとつのフォームとセットで使うために ビューの「フォームの式」に、 そのフォームの名前を設定しておきます 次に紹介するフォームは 今回はとりあえずこんな名前で作成します 29 / 40

ひとつのフォーム どんな文書でも とりあえず全フィールドの中身を テキスト表示するフォーム 30 / 40

フォームにフィールドはひとつも置きません たったひとつの計算結果テキストを置きまして そこへ式を入れます 31 / 40

こんな式です 32 / 40

こんなふうに、 各フィールドのタイトルと中味をテキスト表示できます

こんな式でした、やや粗削りですが 😏 @DocFields @DocFields は変数へ代入 は変数へ代入 @DocFields @DocFields の要素数分を の要素数分を @For @For で回し で回し フィールド名とフィールド値を追加 フィールド名とフィールド値を追加 フィールド値は フィールド値は @GetField @GetField したら、属性が不定なので したら、属性が不定なので @Text @Text をかけ、 をかけ、 複数値の場合に備えカンマで区切ります 複数値の場合に備えカンマで区切ります

丸裸にできること あらためてお伝えしたかったのは 35 / 40

Notes Domino 界隈には 永年使いこまれた、改修も何度も行っているような DB アプリが多く運用され続けているのではないかと思い ます 多くの場合、設計書はロクに残っていない（経験上 何度も改修されたせいで処理が複雑怪奇 あちこちに、いまでは不要かもしれない機能が散在 36 / 40 😓）

コードはやたら長い ソースコメントには改修の痕跡だらけ 開発当初のすっきりしたコードは見る影もない 既存の設計をリバースエンジニアリングするよりも いっそ、いまの業務に合わせて レイアウトも処理も作り直したら？ いまの設計を脱いで新たな設計を着せる この方法なら設計要素を着替えなおすだけで データの移行は気にしなくてよいはず 37 / 40

留意点は、データの「意味」が設計側だけに存在する部分 ○ DB のタイトルやフォームの見出し （何のデータかの趣旨） ○キーワードのフィールドで 「別名」が使われている場合 その意味で、丸裸にするといっても どこかに元の設計の情報は取りおきはしておきます 38 / 40

さすがに、本番運用中の DB を 本当にある日突然丸裸にすることは 実務ではないだろうとは思いますが たとえそこまでやっても 設計とデータは分離してるよと認識できれば Notes 内でのマイグレーションの 敷居が低くなると思う次第です 39 / 40

♥ ご清聴 ありがとうございました