--- title: 202406DominoHub データそのまま丸裸 tags: #domino #notes #dominoforever #lotus notes #dominohub author: [あう゛](https://image.docswell.com/user/abesat) site: [Docswell](https://www.docswell.com/) thumbnail: https://bcdn.docswell.com/page/47ZL6W69J3.jpg?width=480 description: 2024年6月｢DominoHub 2024｣でのトーク資料です 他のツールはともかく、Dominoは設計とデータが分離してますよというお話をしました。 published: January 30, 26 canonical: https://image.docswell.com/s/abesat/ZQXYRJ-202406DominoHub --- # Page. 1 ![Page Image](https://bcdn.docswell.com/page/47ZL6W69J3.jpg) -DominoHub 2024- 2024/06/13 忘れちゃった？ Notes は データそのままで 丸裸にできるって 阿部 覚 (X:) @abesat # Page. 2 ![Page Image](https://bcdn.docswell.com/page/YJ6W2G2DJV.jpg) ごあいさつ Domino まわりでやってることと、 この場ほかの場での属性： ✋XPages.JP にて 「 DX Today じゃぱ～～ん ! 」の掲示役をしています ✋月イチ「のの会」にて「＠関数 Talk 」をやってます 2015 IBM Champion, 2020-2024 HCL Ambassador # Page. 3 ![Page Image](https://bcdn.docswell.com/page/GJ5M2V28J4.jpg) DX Today じゃぱ～～ん！ https://www.xpages.jp/Japan/ctjp.nsf/home.xsp (X:) @DXTodayJapan # Page. 4 ![Page Image](https://bcdn.docswell.com/page/LE3WKDKGE5.jpg) のの会 https://notesknows.connpass.com/ # Page. 5 ![Page Image](https://bcdn.docswell.com/page/8EDK3P3N7G.jpg) のの会 https://notesknows.connpass.com/ # Page. 6 ![Page Image](https://bcdn.docswell.com/page/V7PK4N4NJ8.jpg) のの会 https://notesknows.connpass.com/ # Page. 7 ![Page Image](https://bcdn.docswell.com/page/2JVVXKXYJQ.jpg) 忘れちゃった？ 「丸裸」 …というたとえをするからには Notes は それに対する「衣」👚があるわけで データそのままで それって 丸裸にできるって 7 / 40 # Page. 8 ![Page Image](https://bcdn.docswell.com/page/5EGLVQVWJL.jpg) 「設計要素」 です 8 / 40 # Page. 9 ![Page Image](https://bcdn.docswell.com/page/4JQY6K6Q7P.jpg) ここで Notes Domino 以外の製品…わかりやすいところでは たとえば、 Excel などの表計算シートを 想像いただければと思います セルの中には書き込まれたデータも入れば 式が入っていることもあります 表計算シートで「設計」と「データ」の境目は混沌曖昧 といった印象があります 9 / 40 # Page. 10 ![Page Image](https://bcdn.docswell.com/page/K74W4P4YE1.jpg) あるいは、 Oracle, SQL Server … など リレーショナルなデータベース製品 (RDB) をご経験の方 主キーが存在しなくちゃならない とか キーはユニークじゃなくてはならない とか 関連テーブルとの間の参照制約 とか 各種制約があって それらを踏まえた正規化設計をして しっかり作らなきゃなりません 要するに、設計通りでないデータの存在が 許されないつくりです 10 / 40 # Page. 11 ![Page Image](https://bcdn.docswell.com/page/LJ1Y494NEG.jpg) Domino と競合するソリューションのいくつかでは 設計にこんな制約があったりしませんか？ ・フォームレイアウトに新たな項目を追加すると 既存のすべてのレコードに その項目が追加される （値は NULL だったり所定の初期値だったり） ・フォームレイアウトから項目を削除すると 既存のすべてのレコードから その項目が値ごと削除されてしまう 11 / 40 # Page. 12 ![Page Image](https://bcdn.docswell.com/page/GJWGXQZM72.jpg) あるいは、ビューと密接に結び付き Notes Domino でいえば、ビューの列項目を作ることで フィールドとその見出しが設定されるものもありますね 多くのソリューションでは 設計とデータは 一体、もしくは連動したものになっていると思います 12 / 40 # Page. 13 ![Page Image](https://bcdn.docswell.com/page/4EZL6W1M73.jpg) Notes Domino の場合、そのどちらでもなく 設計は確かに存在するけど データを作ったり変えたり見たりするのに使うんだけど でも、設計とデータはけっこう明確に分離しています 設計の変更が即時にデータに影響を及ぼすってことは 基本ないと思います 13 / 40 # Page. 14 ![Page Image](https://bcdn.docswell.com/page/Y76W2GL57V.jpg) Notes Domino で 設計とデータの紐づきといわれて まず思い浮かぶ設計要素は「フォーム」ですが 設計要素「フォーム」とデータ（文書）とは "Form" という予約フィールドを通して ゆるーく結びついているに過ぎないです 14 / 40 # Page. 15 ![Page Image](https://bcdn.docswell.com/page/G75M2V1G74.jpg) Notes Domino で フォーム設計がデータに影響を及ぼすタイミングって ほぼ、これくらいでは？ ◎作成・編集画面から画面更新・保存したとき ○コード上でフォーム情報を反映して保存したとき たとえば LotusScript で ComputeWithForm を行ってから Save 15 / 40 # Page. 16 ![Page Image](https://bcdn.docswell.com/page/9J29431DER.jpg) 例外として フォームを文書に格納（保存）する オプションを設定した場合 Form フィールドは使われずに 設計とフォームが一体化されます （そんなに利用されてないかな…） 16 / 40 # Page. 17 ![Page Image](https://bcdn.docswell.com/page/DEY4M1ZMJM.jpg) 例外として おなじ Domino でも Domino Leap については 従来の Notes DB アプリと構造が違うところがあり 設計とデータが連動し 項目の変更がデータに影響を与えることがあるそうです 17 / 40 # Page. 18 ![Page Image](https://bcdn.docswell.com/page/VJNYW23378.jpg) だから、たとえば… Notes Domino の DB アプリから 設計要素だけが無くなっちゃっても データは直接の影響を受けません 18 / 40 # Page. 19 ![Page Image](https://bcdn.docswell.com/page/YE9PX19PJ3.jpg) 実際にやっちゃうかどうかは いろいろ難しいとは思いますが 仮にそれをやる 👿👹とすれば ①設計要素を片っ端から消す ②設計要素がないテンプレートで設計置換する 19 / 40 # Page. 20 ![Page Image](https://bcdn.docswell.com/page/GE8D249XED.jpg) DB 内を「データだけ」にしちゃう 👿👹 ①設計要素を地味に片っ端から消しまくっちゃう ビューは最低１つ必要など、消せないものもあります 20 / 40 # Page. 21 ![Page Image](https://bcdn.docswell.com/page/LELM26WN7R.jpg) DB 内を「データだけ」にしちゃう 👿👹 ②設計要素のないテンプレートを作って 設計の置き換えをやっちゃう ただしこちらの方法では このチェックが入っている設計要素が 消えない場合がありますけど 21 / 40 # Page. 22 ![Page Image](https://bcdn.docswell.com/page/4JMY859QJW.jpg) じゃあ、そうやって丸裸になった DB アプリについて 予備知識なしにどんなデータが入っているかを 吟味するとします せっかく丸裸にしたところをナンですが、 こうした場合のために ・ひとつのビュー ・ひとつのフォーム を追加します ✋以下、 2023 年の 「のの会 / @ 関数 Talk 」からの流用です 22 / 40 # Page. 23 ![Page Image](https://bcdn.docswell.com/page/PJR953GK79.jpg) ひとつのビュー どんな文書でもとりあえず 多少は中身を表示してくれるビュー 23 / 40 # Page. 24 ![Page Image](https://bcdn.docswell.com/page/PEXQK4X5JX.jpg) どんな文書でもとりあえず 多少は中身を表示してくれるビュー： どんな文書でも表示するという前提で ビューの選択は、簡易検索なら条件なし 式を入れるなら SELECT @All にしておきます # Page. 25 ![Page Image](https://bcdn.docswell.com/page/3EK95ZWRED.jpg) どんな文書でもとりあえず 多少は中身を表示してくれるビュー： とことんどんな文書でも表示するという前提で ビュープロパティの 「返答文書を階層表示する」には チェックを入れないことをおすすめ まんいち、「迷子の返答文書」があっても表示されます これで、権限がないのでない限りは すべての文書がビューに表示されるはず 25 / 40 # Page. 26 ![Page Image](https://bcdn.docswell.com/page/L73WKD1G75.jpg) どんな文書でもとりあえず 多少は中身を表示してくれるビュー： 列ごとに、 " @DocFields の○個目 " の 「フィールド ID 」と、（可能なら）「その内容」を 表示しています 26 / 40 # Page. 27 ![Page Image](https://bcdn.docswell.com/page/87DK3PXNJG.jpg) 実は @DocFields という関数、ヘルプ上では ビュー列式では使えないことになっています 文書が保存される時点の画面 UI から情報をもらうらしく ビュー上の表示にずれがありうるためでは。。 27 / 40 # Page. 28 ![Page Image](https://bcdn.docswell.com/page/VJPK4NPNE8.jpg) フィールドの数分だけ列を作るわけにもゆかないので ビュー上で全部のフィールドを出すのには無理がある点 💦 リッチテキストは中味が表示されない点にご注意ください あくまで予備知識なしに概略をつかむ目的なので 28 / 40 # Page. 29 ![Page Image](https://bcdn.docswell.com/page/2EVVXK2YEQ.jpg) なお、ここでは、 次に紹介する、ひとつのフォームとセットで使うために ビューの「フォームの式」に、 そのフォームの名前を設定しておきます 次に紹介するフォームは 今回はとりあえずこんな名前で作成します 29 / 40 # Page. 30 ![Page Image](https://bcdn.docswell.com/page/57GLVQRWEL.jpg) ひとつのフォーム どんな文書でも とりあえず全フィールドの中身を テキスト表示するフォーム 30 / 40 # Page. 31 ![Page Image](https://bcdn.docswell.com/page/4EQY6KVQJP.jpg) フォームにフィールドはひとつも置きません たったひとつの計算結果テキストを置きまして そこへ式を入れます 31 / 40 # Page. 32 ![Page Image](https://bcdn.docswell.com/page/KJ4W4PMY71.jpg) こんな式です 32 / 40 # Page. 33 ![Page Image](https://bcdn.docswell.com/page/LE1Y498N7G.jpg) こんなふうに、 各フィールドのタイトルと中味をテキスト表示できます # Page. 34 ![Page Image](https://bcdn.docswell.com/page/GEWGXQGMJ2.jpg) こんな式でした、やや粗削りですが 😏 @DocFields @DocFields は変数へ代入 は変数へ代入 @DocFields @DocFields の要素数分を の要素数分を @For @For で回し で回し フィールド名とフィールド値を追加 フィールド名とフィールド値を追加 フィールド値は フィールド値は @GetField @GetField したら、属性が不定なので したら、属性が不定なので @Text @Text をかけ、 をかけ、 複数値の場合に備えカンマで区切ります 複数値の場合に備えカンマで区切ります # Page. 35 ![Page Image](https://bcdn.docswell.com/page/47ZL6WLMJ3.jpg) 丸裸にできること あらためてお伝えしたかったのは 35 / 40 # Page. 36 ![Page Image](https://bcdn.docswell.com/page/YJ6W2GW5JV.jpg) Notes Domino 界隈には 永年使いこまれた、改修も何度も行っているような DB アプリが多く運用され続けているのではないかと思い ます 多くの場合、設計書はロクに残っていない（経験上 何度も改修されたせいで処理が複雑怪奇 あちこちに、いまでは不要かもしれない機能が散在 36 / 40 😓） # Page. 37 ![Page Image](https://bcdn.docswell.com/page/GJ5M2VMGJ4.jpg) コードはやたら長い ソースコメントには改修の痕跡だらけ 開発当初のすっきりしたコードは見る影もない 既存の設計をリバースエンジニアリングするよりも いっそ、いまの業務に合わせて レイアウトも処理も作り直したら？ いまの設計を脱いで新たな設計を着せる この方法なら設計要素を着替えなおすだけで データの移行は気にしなくてよいはず 37 / 40 # Page. 38 ![Page Image](https://bcdn.docswell.com/page/9E29439D7R.jpg) 留意点は、データの「意味」が設計側だけに存在する部分 ○ DB のタイトルやフォームの見出し （何のデータかの趣旨） ○キーワードのフィールドで 「別名」が使われている場合 その意味で、丸裸にするといっても どこかに元の設計の情報は取りおきはしておきます 38 / 40 # Page. 39 ![Page Image](https://bcdn.docswell.com/page/D7Y4M14MEM.jpg) さすがに、本番運用中の DB を 本当にある日突然丸裸にすることは 実務ではないだろうとは思いますが たとえそこまでやっても 設計とデータは分離してるよと認識できれば Notes 内でのマイグレーションの 敷居が低くなると思う次第です 39 / 40 # Page. 40 ![Page Image](https://bcdn.docswell.com/page/VENYW2Y3J8.jpg) ♥ ご清聴 ありがとうございました