みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
Pages: 1
OS:[Windows10 ]
FileMaker Ver:[12 ]
テーブルというのは具体的にどのように使うものなのでしょうか？
リレーションをとったファイルを複数作って使っています。
テーブルを新たに作るのとどういう違いがあるのでしょうか。
よろしく
ファイル毎に管理している情報を、テーブル間で共有できますね。
特に大きな物が、アクセス権関連。これの設定は結構手間がかかり、ファイル間で同期させないといけない事がほとんどですので、非常に面倒です。全部のテーブルを1ファイルに纏めると、1個の管理だけで良いので、非常に楽になりますね。
Offline
使っている内にどちらにした方がいいのか分かってくるような？
でも既に多数のファイルを繋いでしまっていると統合も大変なので手遅れ？
両ファイルからのリレーションの設定や、外部スクリプト実行も
めんどくさい・・・
Offline
うーん、よくわかりません。
テーブルと別ファイルは同じようなものと考えていいのでしょうか？
セキュリティやリレーションシップがそのまま使えるということでしょうか？
このテーブルを切り替えるのはどうするのでしょうか？
例えば出庫伝票があり、それに対して商品マスターファイルがあるとすると、
このマスターファイルを出庫伝票の別テーブルとして登録するということなのでしょうか？
重箱の隅のような指摘で悪いけど、マスターテーブルは、別ファイルがお勧め。
出庫伝票テーブルと、その明細テーブルは、同じファイルの中にあるべきでしょう。また、それと関連する受注テーブルは同じテーブルがお勧め。
テーブルのまとめ作業は、現場で見てみないと何とも言えませんが、テーブルデータそのものとスクリプトはインポートできますが、レイアウトは地道にコピペして行くしかないです。上手にテーブル名を設定して、クリップボード用のツールを使うと、手間が半減します。
とりあえず、テーブルその物は１ファイルに集めて（adv 番をお持ちなら、新規テーブルにインポートすれば可能）、リレーションマップの中のテーブルオカレンスを各ファイルから外部ファイルへの参照としてそのテーブルを指定していけば、少しまとまるでしょう。
Last edited by Shin (2016-09-27 08:45:08)
Offline
そうですね。マスターテーブルは別ファイルにすべきですよね。
ここはよく理解できます。
ただ、出庫テーブル、明細テーブル、受注テーブルを１つのファイルの別テーブルにするというところがよくわかりません。
別テーブルにしてもレイアウトは同じところにつくるわけですから、逆にレイアウト数は増えてしまいますよね。
別にテーブルに分けずに同じテーブルにフィールドを追加すればいいのではないかなと思います。
レコード数はテーブルによって違ってきますね。違うテーブルとリレーションがないなら、別テーブルにする必要はないわけで、別ファイルであるべきですね。
ほんとに理解できてないので、トンチンカンなことを言っているかもしれません。
別テーブルの必要性がわからないのです。
ファイルとテーブルの違いを理解するためには
データモデリングなどの書籍に一度目を通すと良いかも知れません。
1つのエンティティが1つのテーブルを構成します。（顧客・商品・受注・出庫など）
→表計算アプリケーションではシートに該当します。
テーブルにフィールドを定義してエンティティの各属性を格納します。（名前・性別・血液型など）
→表計算アプリケーションではセルに該当します。
エンティティのなかのひとつの事象の属性の集合が1レコードです。（山田太郎・男性・A型といった感じ）
→表計算アプリケーションでは行に該当します。
FileMaker は Ver.7 以降では 1ファイルに複数のテーブルを作成できるようになりましたが
単純にコンバートしたファイルでは1ファイル=1テーブルのままなのでファイル=テーブルと考えてしまう方もいます。
アカウントとアクセス権・スクリプト・カスタム関数・リレーションシップグラフ等はファイル毎に独立しているので
複数のテーブルで構成されている場合でもファイル数が少ないほうが開発効率は上がります。
※複数ファイルでは各ファイルに定義を行う必要があります。
Shinさんがマスタを別ファイルに分ける例を出していますが
機能部分だけのメンテナンスを容易にする分離モデルなど複数のファイルで構成するのが適する場合もあります。
ただ、出庫テーブル、明細テーブル、受注テーブルを１つのファイルの別テーブルにするというところがよくわかりません。
別テーブルにしてもレイアウトは同じところにつくるわけですから、逆にレイアウト数は増えてしまいますよね。
出庫・明細・受注は異なるエンティティの情報ですから別のテーブルにわけます。
運用しながら必要に応じてフィールドを追加することが必須なカスタムAppは望ましくありません。
出庫は1商品に対して1回きりではないですからフィールドが段々増えることが予想されます。
商品と出庫を商品番号などでリレーションしてポータルで表示すれば同じレイアウトで表現ができます。
明細は1受注に対して1個きりではないですからフィールドが段々増えることが予想されます。
受注と明細を受注番号などでリレーションしてポータルで表示すれば同じレイアウトで表現ができます。
このような結びつきを表現するためにリレーションシップグラフが存在し、
テーブルオカレンス同士をリレーションすることでテーブルとテーブルの関係性を作成します。
テーブルオカレンスに基づいてレイアウトを作成して必要な情報を表現します。
同じテーブルでなければ同じレイアウトに表現できないということはありません。
独学や掲示板での学習には限界があります。書籍に目を向けることも悪いことではないですよ。
http://www.filemaker.com/jp/learning/index.html#fmb
一番簡単なデータベースの基本は FileMaker Master Book 初級編にも収録されています。
Last edited by Moz (2016-09-27 10:22:08)
Offline
ありがとうございます。
うーん。もっとむずかしくなってしまうー。
実際には、リレーションをとっているファイルが50個にもなっています。今更ファイル数を少なくする必要はないのです。
ファイルメーカーサーバーを使っていますので、ファイルを追加するには、サーバーを止めなければならないので、その点テーブルの追加だとサーバーを止める必要がないので便利なのですが・・・。
ただ、このメインのファイルはすべてのファイル群の中心的な存在ですので、できるだけ触りたくないし、触らせたくないのです。
ここにテーブルを追加するのは、なにか気持ち悪いわけです。
テーブルを追加したりレイアウトを追加したりするために、セキュリティ権限のあるアカウントで入る必要があるわけで、そうすると意図しないトラブルが発生するかもしれないと考えています。
他のセキュリティのゆるいファイルのほうは、担当部署で自由に使えばよいと考えているわけです。マスターファイルとかこのメインのファイルは修正がきかないようにしておきたいわけです。
ファイルメーカーサーバーを使っていますので、ファイルを追加するには、サーバーを止めなければならないので、その点テーブルの追加だとサーバーを止める必要がないので便利なのですが・・・。
マニュアル類をよく読みましょう。ファイルアップロードで FileMaker Server を止める必要はありません。
http://www.filemaker.com/jp/support/pro … elp_ja.pdf
・利用中のカスタムAppの運用方針
・FileMaker におけるファイル・テーブル等構造への理解
2つを切り離して考えたほうが良いでしょう。私がコメントしたのは主に後者の内容です。
既に動いているカスタムApp（ファイル群）に手を加えて万が一にもダメになってしまうのを避けるのが最優先なら
別ファイルとして追加していくことは悪いことではありません。
技術・知識としての理解と実運用を守ることは別々の問題です。
出庫テーブル、明細テーブル、受注テーブルを１つのファイルの別テーブルにするというところがよくわかりません。
テーブルを追加したりレイアウトを追加したりするために、セキュリティ権限のあるアカウントで入る必要があるわけで、そうすると意図しないトラブルが発生するかもしれないと考えています。
他のセキュリティのゆるいファイルのほうは、担当部署で自由に使えばよいと考えているわけです。マスターファイルとかこのメインのファイルは修正がきかないようにしておきたいわけです。
残念ながらここは既存のファイルを壊す壊さない云々とは別としてある程度の技術・知識を習得する必要があります。
FileMaker のカスタムAppを使い続けて運用・発展していくためには
なんとなーくかるーく使いたいという要求を押し通せる部分ではないのでどこかで腹をくくりましょう（汗）
Last edited by Moz (2016-09-27 14:06:09)
Offline
ありがとうございます。
なにしろ、ファイルメーカーは非常に使いやすく、次から次へとクライアントからの要求をこなしていったら、ファイルが50にもなっていました。
かなり素人の私でもやってこられたのは、このサイトや昔あったキップミーサイトで教えていただいているおかげです。
ろくに、本も読まず、勉強もせずこのサイトに頼り切りの状況です。
ほんとにこのサイトはありがたいです。すぐに解決してくださいますからね。
ところで、ファイルのアップロードはファイルメーカーサーバーを止めなくてもできるとのことでしたが、ファイルは閉じなければならないのではないでしょうか？
ま、それならば、コンピュータのリブートもかねてサーバーを止めてファイルアップロードをしています。
ファイルに手を加える際のトラブルを避けるためには、別ファイルではなく別テーブルのほうが良いとのことですが、レイアウトなどは別テーブルの場合必ず追加しなければならないと思います。そのときアクセス権限のあるアカウントで入っているわけで、トラブル発生の危惧はありませんでしょうか？
ところで、ファイルのアップロードはファイルメーカーサーバーを止めなくてもできるとのことでしたが、ファイルは閉じなければならないのではないでしょうか？
ファイルを追加アップロードするなら閉じる必要はありません。
同じファイル名や同じファイルの新しいファイルをアップロードする場合はファイルを閉じて削除してからアップロードします。
ファイルに手を加えるのを避けるという運用をしたいようなので必要ないのではと思いますが。
「ファイル」と「テーブル」をご自身の中で混同していませんか？
トラブルを避けるために既存ファイルに手を加えないならテーブル追加ではなく別ファイルをオススメしていますよ。
新しいファイルでもテーブルの作成やレイアウトの作成には完全アクセスのアクセス権セットが必要です。
既存のカスタムAppと連携させる際には既存ファイルの完全アクセスのアクセス権セットが必要でしょう。
完全アクセスのアクセス権セットでファイルを開いただけでトラブルなんてことはあり得ません。
もしアクセス権セットによって処理が変わるようなトリガが心配ならば各ファイルの作成者に確認しておくべきです。
質問者さんが開発者だとして誤った操作をしない限り大丈夫です。それが不安ならば開発を諦めたほうが......（汗）
もし開発をしないユーザのアカウントが完全アクセスのアクセス権セットを持っているならばまずはそこを見直すべきでしょう。
Offline
アクセス権は、ファイルごとに設定しています。
メインのファイルとかマスターファイル以外は、自由にレイアウト作成やらスクリプト作成やらを部門の担当のひとがやります。
で、メインのファイルに対して完全アクセス権で別テーブル作成しての作業があったわけです。
別テーブルだからメインファイルには影響しないだろうということだったのですが、メインファイルに対して完全アクセス権を使用することを避けたいわけです。
で、メインのファイルに対して完全アクセス権で別テーブル作成しての作業があったわけです。
別テーブルだからメインファイルには影響しないだろうということだったのですが、メインファイルに対して完全アクセス権を使用することを避けたいわけです。
書いていることが矛盾しています。
テーブル定義を行うためには完全アクセスのアクセス権セットが必要ですから
メインファイルに別テーブルを作成できて完全アクセスのアクセス権がないアカウントは成立しません。
※完全アクセスのないアカウントがデータベース定義を開く方法もありますがその場合も一時的に完全アクセスが付与されます。
メインファイルおよびそのファイル群と連携する部分は管理者にあたる人間のみが触ることができ
新機能が欲しければ部門別の担当者がファイルを作成して各々アップロードして利用するのもひとつの手でしょう。
ただしこの方法で FileMaker Server へのアップロードを無制限にして破綻した現場はいくつもありますから
最低でも FileMaker Server へのアップロードについては運用方法をしっかり決めたほうが良いでしょう。
ホストできるのは最大125ファイルまでです。
※余談ですが勝手にアップロードした挙げ句125を越えて FileMaker Server を追加した現場を知っています。
※管理がずさんな上、一応の管理者も去ってしまい何のファイルなのか分からない混沌が残されていましたが......
Offline
各部門が完全アクセス権を使わないようにしているのですが、テーブル定義をするために完全アクセス権を使用してしまうのです。
その後も完全アクセス権で操作をするのですが、テーブルが別だから影響しないとの言い分なのです。
もう、管理がずさんで、なんのファイルかわからない混沌のカオスに落ち込んでおります。
"影響しない" というのが何を指すのか分かりませんが......
完全アクセスのアクセス権セットを使っている限り動いているモノを誤ってダメにする可能性はあります。
アクセス権はファイル単位ですからテーブルが別れているなどは関係ありません。
"言い分"もなにも仕様ですから理解するのみです。仕様を決めるのは部門の担当者ではないですから。
現状がマズいとして変えたいのか何なのか......何をしたいのかよく分からなくなってきましたね。
目標を定めて達成するために何をしたらいいのか考えたほうがよいと思いますよ。
現場が暴走して止められないと嘆いていても事態は悪化するだけです。
場合によっては技術・知識ではなく政治が必要かも知れませんね。そうなるとここでは解決しづらいですが（汗）
Offline
各ファイルの完全アクセス権を全体の管理者以外が持っていると、下手すると、全体の管理者があるファイルでは管理者としては閉め出される可能性が出てきますよ。少なくとも、セキュリティ設定だけは解放しない事が絶対でしょう。
テーブル操作やスクリプト操作は、スクリプトを使って、メニュー項目を開くようにさせるといいです。その際に、完全アクセス権で実行、オプションを設定しておくと、何管理者と同じ様に変更が可能です。その際には、カスタムメニューを作りインストールしておくといいでしょう。
Offline
そうですね。スクリプトやレイアウトを作成できる人が増えてきた現状では、アクセス権をしっかり設定しないといけないですね。テーブルを作ってしまう人もでてきたわけですのでね。
ファイルメーカーサーバーは隔離された場所にあるので、ファイルメーカーサーバーの操作はだれでもできないので、新しいファイルがアップロードされるとかはないと思っていたわけです。
アクセス権がアカウントではなく、特定のPCに設定できるようになっていたら、どこからでも操作できないのでいいのですけどね。（そのPCが壊れたら一大事かぁ）
”影響しない”というのは、別テーブルだから、ファイルのデータには影響しないという意味だと思うのですが、私にもそこがわかりません。誤操作や勘違いでデータが消えたり、レイアウトが変わったり、スクリプトが変わったりしてしまうことが怖いと思っています。
ファイルが50個もありますが、１つづつアクセス権を設定していかないといけないかなぁと思っています。完全アクセス権は自由に使えないようにしないといけないかな。
他もデータの削除ができないようにする必要もありますね。リレーションをとっているファイルからデータが削除、変更できる、できないの設定もいるかなぁ。
アクセス権に対する甘さが今になってちょっと大変な作業になろうとしています。アクセス権は最初にちゃんと決めておかないとだめですねぇ。反省！
Pages: 1
[ Generated in 0.008 seconds, 7 queries executed - Memory usage: 580.77 KiB (Peak: 617.67 KiB) ]