過去の桐井戸端BBS (桐ver.7)
962 表引き関数について su 1999/1/3-11:44
Ver7から桐を始めました初心者です。
現在Ver7.1を使用していますが、表引き関数について分からないことがあります。
B.tblの[氏名]に #表引き( [整理番号] , = , "A.tbl" , [整理番号] , [氏名] ) という関数を設定しました。
これで氏名は引っ張ってこれました。
そこでA.tblの氏名に変更をくわえ、B.tblの氏名を見てみますと、変更されていません。
表引き関数では、リアルタイムに元表のデータが反映されると思っていたのですが、
違うのでしょうか。
それともやり方が間違っているのでしょうか。
どうぞよろしくお願いいたします。
963 Re: 川浪 1999/1/3-13:52
記事番号962へのコメント
B.TBLの計算項目で 置換 をかけたら更新すると思います.
桐の場合,自動的には反映されません.
964 Re: su 1999/1/3-21:24
記事番号963へのコメント
川浪様、早速のご回答ありがとうございます。
計算項目では再計算がされないわけですね。
これは非常に驚きでした。
そうするとこのような場合には結合表などを使わなければならないと言うことなのでしょう。
発想を変えないといけませんね。
また、よろしくお願いします。
965 Re: ikjun 1999/1/4-01:12
記事番号964へのコメント
>計算項目では再計算がされないわけですね。
>これは非常に驚きでした。
>そうするとこのような場合には結合表などを使わなければならないと言うことなのでしょう。
>発想を変えないといけませんね。

 えーと、誤解されているようなので、少し説明をさせて頂きます。再計算という言葉から、
エクセルなどの表計算の経験のあるかたのコメントと推測させて頂きました。

 桐は表計算ではなく、データベースですので、項目の入力ごとに再計算するという機能はありません。
すべて、レコード単位つまり行単位での処理になります。それが、なにを意味するかというと、計算はそのレコードの入力が終わった段階でするということです。

 おそらく、結合表では解決になりません。

 簡単にやりたいなら、ただ単に表示モードにいったんしてから訂正モードにしてもいいでしょう。

 これを意識せずに行おうとする場合などは、一括処理で組む必要があります。

 桐は表計算から入ると、結構癖が強く発想の転換をせまられる場面が出てきます。
でも使い慣れると、とても表計算では出来ないようなことが簡単に出来ます。

 それまではちょっと大変かもしれませんが、努力は報われますので、もう少しがんばってみて下さい。
966 Re: ikjun 1999/1/4-02:07
記事番号965へのコメント
 失礼しました。元記事をあらためて読んでみたら、とんでもない誤解をしていたことに気がつきました。
参照される方のテーブルを更新した場合の話ですね。
この場合だと、川浪さんのおっしゃるように置換機能で再計算するか、結合ファイルを使うしかないでしょうね。

 いやいや、新年そうそう馬鹿なコメントをしてしまった。ただ単に再計算というところに反応してしまった。
967 データベースと表計算の違い 佐田 守弘 1999/1/4-04:28
記事番号962へのコメント
suさん、川浪さん、ikjunさん
 suさんから質問が有りました、桐の項目計算式に設定した表引き関数の値が、表引き元の表を更新しても、参照している表が自動更新されない件については、川浪さん、ikjunさんからのコメントが有るとおりです。
この件について不思議と思われる方も他におられると思いますので、補足させて頂きます。
●桐の関数の戻り値
 ここで話題になっている「#表引き」関数を始め、その他にも「#日時値」(実行時の日付時刻)、
あるいは「#総件数」(編集対象表の全レコード数)など、時事刻々と値が変る関数は多数有ります。
これらの関数はいつ時点の値を返すのか。それはこれらの関数が実行された時点の値です。
つまり、ここでの話題である項目計算式に設定した表引き関数であれば、その項目計算式が実行される時です。
●項目計算式はいつ実行される
 疑問のポイントはここにあります。桐の項目計算式は、
@新規の行を追加した時(レコードの入力の終了時)
A計算項目が参照している項目の値が更新された時(そのレコードの更新終了時)
B再計算を設定した項目の編集が終わった時(その項目の更新時)
C表全体の再計算を実行した時(全レコードの全項目について)
です。
●なぜ再計算は自動で実行されない
 川浪さん、ikjunさんのコメントにもあります様に、リアルタイムで再計算が行われるのは、表計算ソフト特有の機能です。
それは、オンメモリでデータ処理する表計算ソフトだからできる話であり、オンディスクで処理するデータベースソフトでは実現するのは不可能でしょう。
 余談になりますが、MS-Excelの前身であるMultiplanでは、1つのセルのデータ更新がある度に、全セルの計算式の再計算(正しくは自動計算)をしていました。
これが本来のリアルタイム更新でしょうね。
そのMultiplanには表引きに相当するlookupという関数があり、丁度suさんの質問の様な名簿を表引きするワークシートを作った事があります。
テスト用の小さなワークシートではうまく行きました。
しかし実用サイズのワークシートで実行したら、1つのデータを入力する度に、数分待たされる事になり、とても使えない状態でした。
このため自動計算を停止して、手動で再計算を行う必要がありました。
当時のPCが遅かった事もあるのでしょうが、膨大な表でまともにリアルタイム更新を行うと、とんでもない事になる1例です。なお現在のMS-Excelは、更新されたセルだけの再計算を行ない、処理時間を稼いでいると思います。
 桐の様なデータベースは、オンディスクで処理する事により、表計算とは桁違いのデータ量を扱えます。
その代わり、自動計算によるリアルタイム更新は処理時間的に不可能ですから、行わない仕様になっていると考えて下さい。
●表引きは桐特有の機能
 表引きと言う概念はどちらかと言えば表計算に近い概念で、本来のデータベースにはありません。
データベースではクエリー、桐で言う結合表の機能で行います。
クエリーの場合も、参照元を更新した時は再クエリー(再結合)を行う事によって、参照先を更新します。
●桐の表と表計算のワークシートは「似ていて非」
 「桐の表は表計算の感覚で」などと言われます。
しかしこれはあくまでも「方便」です。
桐の表は表計算風に見せておりますが、これはあくまでも分りやすくするための「仮相」(仮の姿)であり、実相は全くの別物です。
suさんの、
 >発想を変えないといけませんね。
は、正しくその真理に気がつかれたのだとお見受けします。
桐を知るには、表計算の感覚で入るのが簡単です。
しかし本当に桐を知るには、表計算の感覚を捨て去る事も大切です。
 私のHPにも関連する事を書いてありますので、どうぞご参照下さい。
968 Re: ikjun 1999/1/4-10:59
記事番号966へのコメント
 名誉挽回というわけでは無いのですが、表計算から来た(勝手に決めてます)人に違いだけ説明しても、具体的にどうするかがわからないと解決にならないのではないかと考えて、1つのやり方を説明したいと思います。

 まず、表引き関数を使用すると、コードとそれを元にして表引きしてきたデータの間には矛盾が生じる場合があるということを、常に頭にいれます。
そして、この場合はコードの方が常に正しいと自分のなかのルールとして決めます。

1.集計とかで、データを加工していく処理のなかで、表引き関数を使うときは常に置換をして使う。

2.印刷する前に、元になる表に関数を使ってあるものがあれば、再計算して使用する。

3.データ入力時は新規の時は問題なし、訂正の時は問題になるが、かえって以前のマスターがどうだったかわかる。
うっかりマスターを訂正した場合には復活の手がかりになるので、気がついた時点で置換する。

 3番なんですが、桐の一つの問題点(?)として、表引き関数を使うとコードと表引きされたデータという、本来同じものを表すものを表の中に2重に持ってしまうことになります。

 これは本来リレーショナルデータベースでは、あってはならないことです。
(そういうことをなくすために、リレーショナル『関連づけ』にしてあるわけですから、)

 しかし、実際問題として、コンピュータに不慣れな人にデータを入力させると、データを入力しながら、マスターデータを訂正していくことがよくあります。

 コンピュータの経験が少しでもあれば、当然常識であるはずのデータ入力後のコード訂正はしないということを、この人達は知りません。

 もちろん、説明をするのですが、馬耳東風、右の耳から左の耳へで「そんなこといったけ?」で済まされてしまいます。

 その結果、予想もしなかった結果になり、「コンピュータが壊れている」ということになります。

 もちろん、これはユーザーの問題であって、プログラムを作る側にはなんの落ち度も無いのですが、そんなことに関係なく、結果責任だけ追及されることがあります。
こんな場合、ほとんどのユーザーは自分の落ち度を認めません。

 こんな時に、表引き関数でのデータが残っていると原因追及に役に立ちますし、原因をはっきり目に見える形でユーザーに示すことができます。
もちろん、復旧に大いに役に立ちます。

 今のように、ギガバイトのハードディスクが容易に手に入る時代に、2重にデータが入っていてもあまり問題にはならないと思います。

 このように、自動的にデーターが更新されないというのは、考え方によっては大きなプラスになります。
発想の転換とは、こういったことも含めてのことだと考えます。

 どうしても、いやならフォームやレポートに直接、表引き関数を使うことも出来るはずです。
これならデータが2重になるという点も、リアルタイムに更新されないという問題点も無いはずです。

 ただ、私自身は好きでないのでそうはしてませんが・・・・・・・・

 追伸:佐田さん、いつもながらの丁寧なコメント大変参考になりました。ありがとうございました。
970 Re: 川浪(tkfuyo) 1999/1/4-13:13
記事番号962へのコメント
ikjunさんや佐田先生の回答を読ませていただいて,恥ずかしくなりました.
私の回答はわずか2行だったのに皆さんは実に詳しく他の人にも参考になる内容だったからです.
SUさんごめんなさい.私も昔はマルチプランでしたので,再計算の概念があり最初は違和感が
有りました.でも桐はいいですよ.これからも宜しくお願いします.
971 Re: ikjun 1999/1/4-15:58
記事番号970へのコメント
川浪(tkfuyo)さんは No.970「Re:表引き関数について」で書きました。
>ikjunさんや佐田先生の回答を読ませていただいて,恥ずかしくなりました.
>私の回答はわずか2行だったのに皆さんは実に詳しく他の人にも参考になる内容だったからです.

 川浪さんの回答は、簡潔明瞭で要領を得ていたと思います。

 むしろ、恥じ入るのはよく質問を読まないで回答した私の方です。

 佐田先生に関しては別格ですので、これに懲りずに回答と質問の方をよろしくお願いします。

>SUさんごめんなさい.私も昔はマルチプランでしたので,再計算の概念があり最初は違和感が
>有りました.でも桐はいいですよ.これからも宜しくお願いします.

 わたしも一番最初はマルチプランです。
ンッまてよ!スーパーカルクかな?さすがに、ビジュアルカルクは知らないなあ?
最初に使ったデータベースはdBASEIIだったので、他の人に比べると桐が最初のデータベースでなかったぶんだけ、違和感は少なかったかも知れません。

 逆に、テータベースなのにテーブルに計算式が入るというほうが、違和感があったような気がします。
dBASEもアクセスもテーブルに計算式は入りません。
そういう意味では桐は表計算に近いとも言えるのではないでしょうか?
(でもこれはプログラムだけみても、わからない部分があるということでもあるので、善し悪しかも知れません。)

 桐は基本的にはデータベースに違いないのですが、リレーショナル・データベースの概念からは、かなりはずれるのではないでしょうか?
説明が難しいのですが、桐は桐、他のプログラムで似ているものは基本的にありません。
表計算とデータベースとワープロの概念が混ざった独特の世界だと思います。
(そういえば、Win桐の発売が待てなくて、桐互換ということでDBProというのを買ったことがあった。
眠っているけれど・・・プログラムの記述方法がなんとも納得できなくて、すぐにいやになった。
なんであんなことしたのだろう?)

 初心者へ心配りと、上級者でもある程度納得させるスペックの両立というのは、非常に難しいと思いますが、桐は基本的に高いレベルで両立させていると思います。
そして、これが最大の桐の魅力でしょう。

 ただやさしいだけなら、スペックが高いだけなら他にもあるのですが、やさしくて、スペックが高いなどというものはそうそうありません。
(dBMAGICは結構いいとこいってたのですが、不安定で高価格だった。)

 そのかわり、桐には桐の独自の世界があるので、他の世界から来た人にはどうしても、馴染めないところもあると思います。

 これなどいい例だと思います。なまじっか表計算に似ているから、「どうして?」ということになります。
アクセスなら全然違うので、そうは思わないでしょう。

 Win桐はまだ未完成だと思いますが、それでも小規模オフィスの業務処理プログラムとしては、今のところこれに勝るソフトはないと考えてます。
990 みなさん、ありがとうございます su 1999/1/6-14:35
記事番号971へのコメント
川浪さん、ikjunさん、佐田先生、本当にありがとうございました。
ここまで詳しく教えていただけるとは思っていませんでしたから、なんだか恐縮してしまいます。
おかげさまで、今までもやもやとしていた概念の一端が見えてきた思いです。
これまで私は、TheCardを長いこと使っていました。
(ここでの表引き機能が、元表のデータを変更すると、リアルタイムに実票に反映されていたものですから、データベースとはそういうものだと思いこんでしまっていたのです。)
マクロ機能のようなものがついていますから、そこそこのものが比較的簡単に作れてしまい重宝していたのですが、やはり限界を感じて、他のデータベースソフトを探していたところです。
そこには当然Accessがあり、FileMakerProなども検討しました。
Accessなどは1.0から所有しており、バージョンアップがなされる度に解説書の山をつくり、挫折を繰り返してきました。
しかし今回の選定にあたって、もう少し勉強してみたら、そこそこ理解できるようになり、今度こそいけるかと思いました。
それと同時に桐も勉強し始めたわけです。
そうすると、両者の比較ができるようになり、どちらが自分にふさわしいのかわかり始めました。
(現実には1月間ほどあっちに行ったり、こっちに行ったりと、右往左往していました。)
結果、会話処理での利用、一括処理のわかりやすさ(それでも四苦八苦しています)、ワープロ並のレポートの表現力。
等々、自分の手足のように自由に動く道具としては、桐の方が使えると判断したわけです。

まだまだ分からないことだらけで、特に変数という概念が今までなかったので、苦労しているところです。
そんなわけで、これからも初歩的な質問をすると思いますが、どうかよろしくお願いします。

最後になりましたが、幅田さんのこのHomePageは毎日のように覗かせていただいています。
ここで救われたこと数知れずと言ったところです。
特に最近では、過去のBBSが大変見やすくなり、データ的な資産価値はすごいと思います。
今後とも利用させていただきますのでよろしくお願いします。

戻る