- ベストアンサー
アクセスの設計のことについて教えてください。
Access2003を使用しています。 前任者が作ったのを使用者（一人）に依頼されて、その都度、修正をしています。 使用者が思い立ったときに、依頼があります。 今は、取引先マスタに契約内容を入力できるようにして欲しいと言われております。 「契約締結日」を入れます。 契約が締結中かどうかを判断するフィールドは要りませんか？と聞くと、今はまだ要らないとの答え。 いずれ必要にはなるだろうけれど当分先（2,3年後）のことになるそうです。 でも、いずれは必要になるそうです。その時に設けて欲しいそうです。 そこで、教えていただきたいのですが、「必要になった時に追加する」のと、「初めから設けておく」のとどちらが良い手段のでしょうか？ 操作方法が書いた本はいくつか持っていますが、設計の仕方までは書かれていないため、設計わかりません。 どなたか考え方もあわせてご教示いただけないでしょうか。 （設計を考えるときの良い本や、Webサイトがありましたらそちらも教えていただけると助かります。） 基本的な質問をしていたら申し訳ありません。 よろしくお願いいたします。
- 375k
- お礼率60% (176/289)
- その他(データベース)
- 回答数4
- ありがとう数4
- みんなの回答 （4）
- 専門家の回答
質問者が選んだベストアンサー
「初めから設けておく」が良いはずです。 データベースを最初に設計する段階で、将来予想される要望も含めすべての 内容を網羅しているのが理想です。 データベースの運用途中で、データベースの構造を変更するとつぎはぎ構造と なり、わかりにくい、使いにくいものになる可能性が高いです。 例えば、空になることを許さないフィールドを後で追加すると、その前に作成 されたレコードはすべてエラーになってしまいます。 「必要になった時に追加する」の利点としては、最初は必要最低限の フィールドしかないため、データサイズが小さいことがあるかもしれま せんが、これとて、フィールドを追加していけば結局サイズは大きく なっていきます。 >（設計を考えるときの良い本や、Webサイトがありましたらそちらも教えていただけると助かります。） Oracle というデータベースのベンダ資格があるのですが、これのデータ ベースの概念についての科目の参考書に設計のことも書かれているのでは ないかと思います。（定かではありません。）
その他の回答 (3)
- gatt_mk
- ベストアンサー率29% (356/1220)
>そこで、教えていただきたいのですが、「必要になった時に追加する」のと、「初めから設けておく」のとどちらが良い手段のでしょうか？ ケースバイケースでしょう。一般的にはマスタに相当する項目は後から追加しても登録作業が発生するだけで、プログラムに変更が必要となることは少ないかもしれませんが、トランザクションとなるテーブルに項目追加するとプログラムの大幅修正が発生する可能性が高いかもしれません。 ただご質問中の >契約が締結中かどうかを判断するフィールドは要りませんか？と聞くと、今はまだ要らないとの答え。 >いずれ必要にはなるだろうけれど当分先（2,3年後）のことになるそうです。 に関する修正は他の回答者の方も書かれているように取引先マスタに追加する項目ではないように思います。 どのような種類の契約かはわかりませんが、契約NO、取引先ID、契約締結日、有効期限（リース契約の場合などは年数など）、解約日などの項目を設けてトランザクションとして管理するのが妥当だと思います。 契約が有効かどうかは有効期限や解約日の情報の有無などで判断ができるようにした方が使いやすいような気がします。
補足
ご回答いただいた皆さま ご回答ありがとうございます。 説明不足で語弊を招いてしまってすみません。 契約に関する内容は、別途テーブルを設けてリレーションで取引先マスタとつなげてあります。
服飾デザイナでプログラマではありませんので参考程度に・・・。 ○ 必要になった時に追加する。 × 初めから設けておく。 もありえます。 <取引先> ID__名称 1___A社 2___B社 <取引先契約履歴> ID__有効__取引先_ID__契約締結日 1___No____________1__2007/11/01 2___Yes___________2__2007/11/01 3___Yes___________1__2007/11/10 通常は、このような設計だと思います。 そもそも、データベースのデータは、 (1)システムデータ___各種設定 etc. (2)基本情報データ___取引先 etc. (3)随時更新データ___取引先契約履歴 etc. の３つに分類できると思います。 この内、システムデータをユーザが更新することはないでしょう。 この内、基本情報データをユーザが変更することも稀で、ほとんど追加入力。 この内、随時更新データは、日常的にデータの発生の都度に追加されていくと思います。 ということは、ユーザにとっては＜随時更新データ追加フォーム＞が日常的な窓。 決して、＜基本情報データ追加フォーム＞が日常的な窓じゃないでしょう。 で、先に示した設計で、作成すべきは＜取引先契約履歴管理フォーム＞ということに。 しかし、しかし、この正論が通じるのでしょうかね。 どう考えても、現行の設計とニーズは＜カード型データベース＞のそれですね。 この＜カード型データベース＞が全体を貫く基本であれば、正論は通用しません。 ＜必要になった時に追加する＞も選択肢かなとも考えます。
お礼
ありがとうございました。
- CHRONOS_0
- ベストアンサー率54% (457/838)
>「必要になった時に追加する」のと、「初めから設けておく」のとどちらが良い手段のでしょうか？ データベースの基本はテーブルです その基本となるテーブルの手直しは大改造と言っていい操作になります 出来るだけ避けたい、すなわち予想できるものは最初から組みこんでおくというのが基本です それより >取引先マスタに契約内容を入力できるようにして欲しい こっちのほうが問題ですね 取引先マスタは基本情報テーブル それに対し契約はトラン(活動記録)ですから絶対に分けておくべきものです
お礼
ありがとうございました。
関連するQ&A
- Accessのレポート作成について教えてください。
Access2003を使用しています。 「T取引先マスタ」と「T取引先の契約内容」があります。 それをT取引先マスタを親とし、T取引先の契約内容を子サブフォームとした「F取引先と契約内容」を作りました。 連結フィールドは取引先IDです。 次に「F取引先と契約内容」の項目全てをレポートにしました。（T取引先マスタとT取引先の契約内容をクエリで連結させました。） レポートは３種類必要です。 契約状況がキーになります。 1.契約の有無に関わらず取引先マスタ詳細すべて。 2.契約締結している取引先マスタ詳細すべて。 3.契約締結していない取引先マスタ詳細すべて。 契約締結日のところに「Null」値で条件付けしました。 1.は問題なく作成できました。 2.3.がうまく出来ません。 取引先IDが2件出てしまうのです。 取引先ID 取引先のもろもろの情報 契約種類 101 ・・・ 基本 101 ・・・ 業務委託 101 ・・・ 基本 101 ・・・ 業務委託 契約種類は「基本」と「業務委託」の2種類があります。 クエリのデータシートでは次のようになっています。 取引先ID－契約種類 101 － 基本 101 － 業務委託 取引先IDはひとつとして、サブフォームの2種類の契約内容を契約締結日をキーとした条件抽出のレポートを作成するには、どのようにしたらいいのでしょうか？ 取引先ID－契約種類 101 － 基本 101 － 業務委託 102 － 基本 102 － 業務委託 どなたか教えてください！ 宜しくお願いいたします。
- ベストアンサー
- その他(データベース)
- 私が考えたAccessのテーブル設計に問題がないか教えてください。
Access2003を使用しています。 前任者が作成したデータベースに修正を加えています。 顧客からの問合せを記録しているT対応履歴という名のテーブルがあります。 対応履歴ID・・・主キー（オートナンバー型） 顧客No 顧客名 商品番号 問合せ区分 問合日 完了日 弊社担当者 内容 原因 対応 備考 などがあります。 その中に修理料金が発生し、修理を依頼した取引先との記録も残すフィールドを加えました。 でも、これは1レコードにつき全て発生するというわけではなくて、どちらかと言えばまれです。 内容としては、次のものがメインになります。 数量 実施日 請求日 支払日 入金確認日 取引先ID・・・取引先テーブルとつながっているため必要 テーブルの設計をするのがはじめての頃だったので、対応履歴の中に加えてしまいました。 別々のテーブルにわけることも考えたのですが、フォームやレポートのリンクがうまくいかなかったので結局一緒にしてしまいました。 やはりこのような場合は、テーブルをわけたほうがよかったのでしょうか？ そのように思うのですが、設計の自信がないため確認させていただきたいのです。 今のところ、その料金が発生した場合のデータは10件ほどです。 今からでも、テーブルをわけたほうがよいのでしょうか？ 2ヵ月後ぐらいには料金が発生するような事例が増えると言われています。 直すなら今のうちだと思っています。 設計にお詳しい方、どうぞよきアドバイスをいただけないでしょうか？ よろしくお願いいたします。
- ベストアンサー
- その他(データベース)
- Accessで３つのテーブルの結合とフィールドについて教えてください。
Access2003を使用しています。 「取引先マスタ」テーブルに契約の情報ものせることにしました。 契約は今のところ２種類ありますが、３種類になる可能性もありそうなので、応用が利くようにサブフォームにしました。http://questionbox.msn.co.jp/qa3473958.html 契約内容では弊社の誰が担当したのかわかるようにしたいです。 けれど担当者は新たにフィールドを設けずに、担当者マスタのテーブルから引っ張ってきたほうが良いのかなと思いました。 とすると、契約のテーブルには担当者IDだけでも加えないと結合できないなと思いました。 質問１．この考え方であっているでしょうか？ 各テーブルは下記のようになっています。 質問２．T取引先マスタとT担当者マスタに「担当者」という同名のフィールドがありますが、意味合いは違います。これは「取引先担当者」と「弊社担当者」と名前を分けたほうがよいのでしょうか？ 一緒でもなんとかいけるものでしょうか？ テーブルの正規化いうものがしっかりと理解できていないので正しいのかどうがわかりかねています。 この３つのテーブルを結合させて、フォームとレポートを作りたいのです。 そして、契約締結済みと未締結との取引先に抽出わけをしたいのです・・・が、ここでつまずいてしまって困っております。 お手数をおかけして申し訳ないのですが、どなたかご教示ください。 よろしくお願いいたします。 T取引先マスタ ID 取引先ID 取引先名 フリガナ 部署名 担当者名・・・・・・取引先の担当者名 郵便番号 都道府県 住所1 住所2 電話番号 FAX番号 URL 電子メール 備考 T取引先_契約内容 ID 取引先ID 契約種別・・・・・・基本と業務委託がある 契約締結日 契約終了日 契約者役職 取引先契約者名 担当者ID・・・・・・弊社の担当者を判別するもの。T担当者ますたと結合する。 T担当者 担当者ID 並べ替え 担当者名 フリガナ 備考
- 締切済み
- その他([技術者向] コンピューター)
- 設計士さんへの設計監理料とは？
設計士さんへの設計監理料とは？ 新築するにあたり、工務店とは別に建築家（設計士さん）にきちんと設計監理を頼む場合、 設計士さんに建築総額の１０％前後の金額を支払う事になると聞いています。（３０００万の家なら、３００万と考えると決して安くはないですね） で、質問です。 家が完成後、年数を経過すると何かトラブルや修繕がでてくるでしょう、 そういったフォローの為に相談したり来てもらったりアドバイスをもらう等、その設計士さんとの関係は長く続くものと考えます。 そういう時は、またその都度、設計士さんに報酬を支払う必要があるのですか？ それとも、新築時に設計士さんと契約を交わして支払う設計監理料は その後のフォローも含めての金額と考えてよいのですか？
- ベストアンサー
- 新築一戸建て
- アクセスでフォームに追加項目を増やす場合、サブフォームにしたほうがよいのか、しないほうがよいのか教えてください。
Access200３を使用しています。 「取引先マスタ」という取引先の住所などが入ったフォームに契約書に関するデータも入力できるようにして欲しいと依頼が入りました。 それは契約の種別ごとに「契約締結日」、「取引先契約者」、「弊社担当者名」を設けます。 このような場合、契約書に関するデータは別のテーブルに入力してサブフォームにしたほうがよいのでしょうか？ それとも「取引先マスタ」と同じフォームのなかに入れたほうがよいのでしょうか？ あとで支障が出にくい方法をとりたいのですが、Accessに熟練されている方はどちらの方法を取られているのでしょうか？ アドバイスをお願いいたします。
- ベストアンサー
- その他(データベース)
- 建築家に支払った設計料について困っています。
昨年より家の新築を考えています。 ある建築家に設計を依頼し施工は合い見積もりを工務店数社でとり、その中で決めるという形で、話を進めてきました。 その際建築家に支払う設計料（監理料含）は建物本体価格の15％です。 最初に建築家に会った時に自分たちの希望や建築予算について、設計可能かどうかを確認しました。その際私たちの予算は税込み3,000万円でお願いしますと伝えました。設計料の支払い方法は(1)契約締結時90万(2)基本設計を完了するまでに90万(3)実施設計を完了するまでに90万(4)工事中間時に90万(5)工事完了後残金、と分納になっています。 業務委託契約を結び、現在実施設計まで終わり270万円を支払いました。 しかし、工務店5社に合い見積もりをとったところ、予算をかなり上回る結果となり（5000万～8000万）この図面では予算内での施工は断念せざるをえない状況になりました。その際建築家より「地域的に物価が高い地域である事を理解していなかったのはこちらの落ち度であるので、もう1度構造を変更して設計します。2度目の設計料はいただきません。」といわれました。 設計料はすでに支払い済みですし建築家に家を設計してもらうのも夢だったので、再度設計をお願いしました。 その際、こちらの予算は税込み3000万なので絶対に予算内でお願いしますと書面で渡しました。 しかし構造を変えての2度目の設計も工務店に見積もりをとってみると（見積もりをとるのは建築家のいる設計事務所がします）予算を大きく上回るものでした。このような状態で家は建築できないのでハウスメーカーへの変更も考えています。 支払った設計料について返還してほしいのですが、これは返していただけるものなのでしょうか？ 業務委託契約書には契約解除について下記のように記されています。 「甲（わたしたち）及び乙（設計事務所）のいずれか一方が本契約を履行しない場合、相手方は契約を解除することができる」 このような流れで設計事務所は契約を履行しているといえるのでしょうか？不完全履行にはあたりませんか？ これから設計事務所に解約と設計料返還の話をする予定ですので、よいアドバイスをお願い致します
- 締切済み
- その他（法律）
- データベース設計、同一マスターへの外部キーについて
例えば社員マスターテーブルがあり、稟議書のテーブルがあったとします。 稟議書のレコードには、作成者、指示者、承認者など、 社員を入れるべき項目がいくつもあり、 データ上はIDとしたいですが、表示は氏名を利用したいと思っています。 こういった場合はどうテーブル設計したらいいでしょうか、 または皆様はどういうテーブル設計にしているでしょうか。 私は以下の2案しか思いつきませんでしたが、 もっとスマートな方法、または実際にどうしている、 どうすべきなどありましたら、ご教授、ご意見ください。 よろしくお願いいたします。 案a.稟議書テーブルに各項目の社員IDフィールドを作り、 表示時は、必要数分の社員マスターテーブルを別名で結合する →リレーションとしてあまり正しくない？ 処理が重くなる？ 案b.稟議書テーブルに各項目分の社員IDフィールドと 社員氏名フィールドも作る →冗長である？ 整合性が問題？
- ベストアンサー
- その他(データベース)
- オブジェクト指向で開発されたPHPに設計書は不要？
お世話になります。 システム開発を外注先に依頼し、納品を終了しました。 ただ、実際に運用していると 【ここを変えたい】【ここをこうしたい】 という物が多数でてきてしまいました。 予算の関係上、新たに都度外注先に修正を依頼するわけにもいかず 自社で修正を行いたいと考えております。 ただ、ページボリュームがそれなりにある関係上修正をするにも 修正すべき箇所を探すだけでもかなり一苦労であること、また 一部を修正することにより他に影響が出てしまう懸念があります。 オブジェクト指向で開発されているシステムについて、オブジェクト指向を理解している 他のエンジニアでしたら設計書については不要なのでしょうか？ それともかなり詳細な設計書が無いと修正は難しいのでしょうか？ もし必要であれば設計書を外注先にお願いして作業を行おうと思っています。 大変長文になりましたが何卒よろしくお願い致します。
- 締切済み
- PHP
- 建築設計士さんとの契約中止について
昨年、息子が三世帯住宅を建てるということで 設計士さんに設計及び監理業務を委託契約しました。 契約金額は294万で締結時に70万を支払って有ります。 主人が大工なので、分離発注したほうが費用を抑えられると思い依頼したのですが 主人がパナホームの仕事をしたことで、そちらの見積を取った所 クオリティの割りに値段が安いので、 設計士さんに業務の中断をお願いし、清算書を出してもらいました 間取りを検討しながら設計図を詰めているところでしたので 契約時見積書の調査・基本計画業務と実施計画業務の30万位で済むかと思いましたが なんと100万の金額で、調整値引きとして30万 要するに、前払いした金額にあわせて清算書を持ってきたわけですが どうも納得できません 契約書には中止までのかかった費用を清算とあるのですが 1回間取りを変更するたびに平面図を書き直すと8万円という風に 単価ごとの計算になっています 最初の見積とは明らかに金額が違うのですが、支払うしかないのでしょうか？
- ベストアンサー
- 新築一戸建て
お礼
ありがとうございました。