【データベース Access2003】

お寺のデータベースをこれから作ろうと思っています、初心者です。
現在、エクセル等で管理している下記の3つのリストがあり、
()のような主キーを設定しようと考えています。

・檀家名簿(主キー:檀家ID)
・過去帳(主キー:故人ID)
・墓地リスト(主キー:墓地番号)


それぞれに項目のある「墓地番号」で関連付けてデータベースを作ろうと考えたのですが、
困ったことがありました。

「お墓を複数(2つ)持っている(墓地番号が2個ある)檀家さん」

の扱いです。
なにか良い解決方法がありましたら教えてください。
よろしくお願いします。

回答の条件
  • 1人5回まで
  • 13歳以上
  • 登録:2011/11/12 14:51:10
  • 終了:2011/11/18 10:08:52

ベストアンサー

id:Baku7770 No.4

Baku7770回答回数2832ベストアンサー獲得回数1812011/11/14 00:23:52

ポイント25pt

・檀家名簿(主キー:檀家ID)
・過去帳(主キー:故人ID)
・墓地リスト(主キー:墓地番号)
 過去帳と墓地リストの相関用のテーブルを新たに設ければ済む話しではないのですか?
 お立場がわからないのでどういった業務が必要なのかは解りませんが。
 墓に対して檀家は1軒で済むでしょうから、墓地リストに檀家IDを持たせるのは構いませんが、一つの檀家が複数の墓を管理する場合を想定するなら檀家名簿には墓地IDを持たせるわけにはいきません。
 例えば掃除料の請求業務は檀家ごとに墓地リストとマッチングをかければ済む話しです。
 実際に起こりえるのは、故人が複数の墓地に埋葬される(分骨)、複数の故人が一つの墓に埋葬される合祀といったケース、複数の故人が複数の墓地に合祀される可能性も捨て切れません。
 システム的には、基本的に故人一人に墓地一つとして墓地、過去帳、相関の3つのテーブルに対する登録画面を作り、複数の場合には追加レコードを相関と墓地の2つに登録できるようにすれば済む話しだと考えます。(ただし墓地は追加不要の場合アリ)

その他の回答(3件)

id:mario-16 No.1

蝸牛角上争何事回答回数219ベストアンサー獲得回数212011/11/12 15:42:28

ポイント25pt

「墓地番号」で関連付けるのではなく「檀家ID」で関連付ければ良いと思います。
「お墓を複数(2つ)持っている(墓地番号が2個ある)檀家さん」の場合には「墓地リスト」テーブルに2レコードのデータが作られることになります。

id:der_freischutz

回答ありがとうございます。
質問で説明が足りなくて申し訳ないのですが、
「1個の墓地を2軒の檀家で管理(所有)している」
という場合があります。

墓地は物理的に個数が確定しているので、できたら墓地番号を全ての基点に
管理できると助かるのですが・・・。

2011/11/12 15:47:50
id:windofjuly No.2

うぃんど回答回数2625ベストアンサー獲得回数11492011/11/12 15:51:39

ポイント25pt

Accessで行うということなので私なら下記のような具合にします
故人ではなく個人として遺族や関係者も一緒に扱うことで、
使い勝手が向上するはずです
 
檀家テーブル
・檀家ID(主キー)
・檀家名
・個人ID 頭首の情報は個人テーブルから持ってくる
 
個人テーブル
・個人ID(主キー)
・氏名
・檀家ID
・没年月日 ここに日付が入っていれば故人、無ければ存命
・墓地番号 存命の場合は(入るであろう)墓地番号、もしくは空白
・その他、住所や連絡先などの個人情報
 
墓地テーブル
・墓地番号
・場所
・その他、墓地固有の情報
 
檀家ではなく個人単位で管理するのがミソです

id:der_freischutz

回答ありがとうございます。
施主(頭首)以外に檀家にどのようなメンバーが存在するかは寺には分からないのです・・・。(個人ごとの情報は、「故人」のもののみ、過去帳にしかありません)

2011/11/12 16:16:06
id:windofjuly

不要であれば生者に対して深く掘り下げる必要はありません
個人テーブルには、故人と頭首の情報だけ入れておけば、それで十分です
 
故人ならびに頭首以外の個人については、
無理せず、頭首のご家族・縁者など判る範囲で入れておけば、
将来何かの役に立つかもしれないというようなことです

2011/11/12 16:31:12
id:takejin No.3

たけじん回答回数1470ベストアンサー獲得回数1892011/11/12 21:01:16

ポイント25pt

墓地番号で関連付けして、墓地で検索すると、同じ檀家が2回以上ヒットする。
これで、問題点は?
複数ヒットすることだけを避けたいなら、検索するクエリを作って、集計してしまえば同じ檀家が表示されるのを防げるのでは?
どのような場合に、複数ヒットすることを避けたいのかを知りたいです。

id:der_freischutz

複数ヒットすること自体はあまりこだわっていません。
心配なのは、たとえば檀家リストで1件の檀家が2個のレコードにしたときに、
どちらかを訂正漏れしてしまったりすることです。

考えられる業務での使い方を書いておきます。
・墓地リストから、その墓を管理している檀家を調べる。
・墓地リストから、そのお墓に入っている個人を調べる(過去帳から)。

・檀家リストからその家の墓地を調べる。
・檀家リストからその家に関係のある個人を過去帳から調べる。

・過去帳の「今年n回忌」の個人をよりぬき、それに関係する檀家を調べる。

墓地リスト、檀家リストのどちらからたどってもOKな仕組みが知りたいです。

2011/11/13 09:10:07
id:takejin

各基礎データ(墓地に関する基礎データ:位置や面積など固定値のみとID。檀家基礎データ:ID、檀家としてのデータ。過去帳データ:固定されているものID)と、関連付けテーブル(1レコードには1対1の関係だけ記載する。複数の関係があれば、その数だけレコードが増える)
検索は、関連付けテーブルを使用して行う。出てきたIDと、基礎データテーブルを関連付けて表示する。
テーブルの関連付けと、基礎テーブル内の改変とは、別の入力画面を使って作業をし、独立した入出力を行うことで記載漏れを防止する。

2011/11/16 08:46:04
id:Baku7770 No.4

Baku7770回答回数2832ベストアンサー獲得回数1812011/11/14 00:23:52ここでベストアンサー

ポイント25pt

・檀家名簿(主キー:檀家ID)
・過去帳(主キー:故人ID)
・墓地リスト(主キー:墓地番号)
 過去帳と墓地リストの相関用のテーブルを新たに設ければ済む話しではないのですか?
 お立場がわからないのでどういった業務が必要なのかは解りませんが。
 墓に対して檀家は1軒で済むでしょうから、墓地リストに檀家IDを持たせるのは構いませんが、一つの檀家が複数の墓を管理する場合を想定するなら檀家名簿には墓地IDを持たせるわけにはいきません。
 例えば掃除料の請求業務は檀家ごとに墓地リストとマッチングをかければ済む話しです。
 実際に起こりえるのは、故人が複数の墓地に埋葬される(分骨)、複数の故人が一つの墓に埋葬される合祀といったケース、複数の故人が複数の墓地に合祀される可能性も捨て切れません。
 システム的には、基本的に故人一人に墓地一つとして墓地、過去帳、相関の3つのテーブルに対する登録画面を作り、複数の場合には追加レコードを相関と墓地の2つに登録できるようにすれば済む話しだと考えます。(ただし墓地は追加不要の場合アリ)

  • id:TransFreeBSD
    補足的に。
    コメントによれば檀家対墓地の関係が以下の両方であるため、その関係は多対多になります。
    - 一つの檀家が複数の墓地を持つ
    - 複数の檀家が一つの墓地を持つ
    この場合は、檀家対墓地の関係を別テーブルで関連付ける事で正規化します。
    参考 http://itpro.nikkeibp.co.jp/members/ITPro/ITBASIC/20000919/1/

    そのための専用テーブルを作っても良いですが、今回の場合に故人の関係を見たとき、以下の両方が成り立つなら、前述の檀家対墓地の関係を記述出来る可能性があります。
    - 故人は複数の檀家に属することはない
    - 故人は複数の墓地に入ることはない
    それぞれが多対1であれば故人のレコードに檀家と墓地のIDを入れることが可能だからです。
    それがwindofjulyさんの解答になります。

    注意点として、故人により檀家と墓地の関係を記述しているので、以下の場合には問題になります。
    - 檀家に属する故人が入っていない墓地を管理している檀家がある場合
    - 檀家に属する故人が入っているが、その檀家はその墓地を管理していない場合
    端的にいえば「故人の属する檀家と入っている墓地という情報だけで檀家と墓地の関係が言えるか?」ということです。
    前者の場合は、ダミーの故人レコードを作り対処すれば良いでしょう(ダミーデータで案内状等が作成されない等の配慮が必要ですが)。
    問題は後者で以下のどちらかになります。
    - 檀家や墓地に備考欄やメモ欄を作って書くなど、検索時にヒットしても手動で取り除くなどの運用で回避する
    - 檀家と墓地を結びつける専用テーブルを設ける
    前者はミスが発生しやすいがデータ管理がシンプルにななるメリットがありますので、「檀家に属する故人が入っているが、その檀家はその墓地を管理していない」というのがどれほど可能性のあることか、そういった檀家に連絡してしまった時などに念のためなどで許容出来るか、などを考慮して決める事になるかと思います。


    最後に、一つ考慮しないといけないのが、前述の故人と檀家、墓地の関係です。
    - 故人は複数の檀家に属することはない
    - 故人は複数の墓地に入ることはない
    これが成り立たないならば、檀家対墓地と同じく多対多の関係になってしまいます。
    ただ、これらは非常にまれな事ととらえて、その場合だけ特別に同じ故人に対し2つのIDとレコードを作る、という対応もありえるでしょう。
    もしくは十分ありえるととらえるなら、いっそ、檀家、墓地、故人はそれぞれ独立したテーブルにし、それらとは別に関連付けを記録するテーブルを作って柔軟性を持たせる手もあります。
  • id:der_freischutz
    TransFreeBSDさま。
    大変参考になりました。ありがとうございます。

    墓地・檀家の関連付け用テーブルを作ることで上手く対処できそうです。
    たすかりました(^-^)
  • id:windofjuly
    うぃんど 2011/11/18 10:14:38
    TransFreeBSD さんに回答リクエスト送って、
    このページに戻ったら終了してたorz
     
    TransFreeBSD さん手間かけてゴメン
  • id:TransFreeBSD
    der_freischutzさん
    ポイントありがとうございました。
    解答に書けば良かったですね。(^^;

    windofjulyさん
    解答リクエスト飛んで来ませんでした。
    終了の方が早かったようで(笑)
    気になさらずに。

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません