アクセスのテーブルの組み立て方について

質問

Accessはほとんど初めてなのですが、会社でAccessを使ってDBを作るよう指示されました。
まず、テーブルを顧客情報・商品・見積・見積明細などに分けて組み立て、商品テーブルに販売価格や仕入価格などを入れて見積に反映させました。

ところが、商品の売買だけで無く、その商品に対する修理やアフターサービス、また全く別のイレギュラーな仕事など、そのような様々な事案についてもひとつのDBにしたいという事でした。
この場合、今出来ている商品テーブルとは別にその他の事案のテーブルを作れば良いのでしょうか?
その場合、見積テーブルはまた別に作るのでしょうか?
さまざまな案件に関して、どのようにテーブルを作って関連づければいいのかわかりません。

アクセスはほとんど独学で、PCにもあまり詳しくないのでうまく説明できていないかもしれません。
要するに、必要なのは会社の収益になる品物や、サービスや、その他もろもろをすべてひとつにDB化し、見積書・契約書・粗利計算書などが出せるDBです。
また、定期的に販売した商品に対してサービスの案内をするためアラートをつけたいと言われていますがそのようなことは可能なのでしょうか?

本当に初心者で本を読みながらやっています。
現在すっかり混乱してします。どうしてもここからの構築方法がわかりません。
質問の意味がわかっていただけると嬉しいです…。
よろしくお願いします。

回答No.7

imogasi

＞についてもひとつのDBにしたいという事でした
と言っているのはデータベースやシステムを判っている人（経験者）か。
１つの.mdbにまとまっていれば良いとぐらいに解釈すべきでは。テーブルを無理して、色々違う（何を以って違うというか経験が必要だが）情報をぶち込むと困ることになる。先人の経験で言われているとおり。
リレーショナルデータベースのテーブルを分けるという発想も、相当訓練しないと出てこない発想だと思う。一般には総合とか称して、何でもそこに有るイメージを持ちやすい。
＞ひとつのDB
＞もろもろをすべてひとつにDB化し
はそういう気分を言うのだろう。
しかしテーブル面では分けるべきものは分けないといかん。
ーー
テーブル関係について
事業活動で
（1)商品の売買
顧客情報・商品・見積・見積明細
商品テーブルに販売価格や仕入価格
＝＝＞一応出来上がっている
（２）商品に対する修理やアフターサービス
＝＝＞これから作る
（３）全く別のイレギュラーな仕事
は何を言うのか読者にはわからない。
ーー
質問の主要事項は（２）だとすれば
質問者の会社で主体は、顧客、商品どちらでしょうか。やはり顧客かな。（社内で話題になるのは、XX社のｙｙの件が多いのか？YY商品はどうなっているのか？利用時には、それらをつなぐものがいるでしょうね）
（２）では必要なテーブルを作る。同じものは（１）を使う。
この検討をすれば仕舞いでしょう。
後はアクセス直接触るシステムを作る担当者の話で、良くわからない上司などに惑わされるな。テーブルの結合をして、情報を揃えればよい。
ーー
＞定期的に販売した商品に対してサービスの案内をするためアラートをつけたいと
こんなの月次作業で条件をかけて、クエリで抜き出しをおこない、社別のレポートを印刷とかの話で、根幹を左右する話ではない。
頭を混乱させず冷静に。
ーー
重複情報を持たない、出来るだけテーブルを連携して、望みの項目を揃える。
ーーー
それより、お偉いさんは、ほしいことだけ、のたまうが、入力の便利さ省力性、早期データ提出、関係者の提出の締め切りのばらつきをなくす、業務の実行と同時にデータ化されることを目指すことだ。
システムが腐る（使えないと不平が出て、使われなくなるのは、この面からが多い）。
例えばお客から修理要求があれば、まずコンピュターにデータを入れないと修理が進まないように仕組むことだ。従事者がそれをしないと決定的に困るようにすることだ。例えば受注したらコンピュターに入れないと、商品が発送されず、先方から大目玉を食らうように仕組むことだ。商品以外などでは、コンピュター処理とは別に、行動面でちゃんと修理をやって、対お客様では済んだことにすることも可能。しかしデータはコンピュタに入っていないとか。
もうひとつどうしてもまとめて入力する部分が残る。専任の入力担当者を手当てすること。兼任させると、どうしても遅れたりおろそかになる。
アクセスのテーブルなど２の次。アクセスの難しさに気を取られ、アクセス馬鹿になるな。実際動かしてれば欠点誤りには気づかしてくれるから
そのとき自分で改良すればしまい。それより体制と言うのは、偉いさん（あれもこれも途といい勝ち）が言うだけの実施面で空回りの恐れが多い。

回答No.6

gadd3

補足です

Oplockの問題は、クライアントサーバもどきにしないなら必要ないです。逆に、複数のパソコンで同時処理したいような場合には必要です。

そのほか、クライアントサーバもどきにする場合は、
無理にすべてを一つのファイルでやろうとすると失敗することがあります。
（メンテなどの都合上、オールインワンにすると業務が止まるため。
　また、１つのmdbファイル内にテーブル、フォーム、クエリなど、
　数が増えれば増えるほど管理しづらくなり、ミスやトラブルを
　誘発します　）

データの件数をよく考えながら、場合によっては、顧客は顧客のmdbだけ、各トランザクションはそれぞれ独立させて・・・、という形のほうが良い場合もあります。

各テーブルを1つのmdbに独立させた場合、参照整合性が設定できなくなるので参照整合性が取れる機能を自前で作らないといけなくなりますが、自分で作れればとくに問題は無いと思います。

最適化やバックアップも1日1回程度は行って。

また、ネットワーク越しの
リンクテーブルの速度が異常に遅くなることもあります。
その際はこちらをご参考に
http://support.microsoft.com/kb/838670/ja

クライアントが多い時やデータ件数が多い時は、これ以外にも
クエリやテーブル動作を早くする方法がありますが、
それらはまた問題が起こったときに聞けばよいと思います。

回答No.5

gadd3

>そのようなことは可能なのでしょうか?

可能ですけれども、規模にもよります。
もしあまりAccessのことを熟知していないのでしたら、
パソコンの台数が５、６台以下の場合までを想定されるとよいと思います。３０台くらいまでは大丈夫ですが、件数が1ファイル5万件を超えたあたりや台数が７、８台を超えたあたりから、作り方を注意しないと動きが遅くなります。

・顧客マスタ
・商品マスタ
・見積関連のトランザクション
・売上（成約？）関連のトランザクション
　　（↑顧客マスタとは関連しているイレギュラーな仕事なら、
　　　ここに含めてもいいかも。切り離してもいいですが。）
　　客先情報などの概要トランザクションと
　　売上商品明細のトランザクションなど。
　　売上のメインとサブ
・修理やアフターサービス関連のトランザクション

>見積書・
見積のトランザクションで管理

>契約書
売上関連のトランザクションで、契約書のファイルのフルパスを記録して契約書をリンクさせるようなかたちで管理

>粗利計算書などが出せるDBです。
売上関連のトランザクションで、定価ではなく販売価格や値引き、仕入れ値などを記録して管理

>また、定期的に販売した商品に対してサービスの案内をするためアラート
見積を売上トランザクション（概要と明細ともに）に転記して、
もし修正があれば修正し、売上トランザクション（明細部分）の
販売日付を基準値に、年数などを計算してアラートもしくは、
TELリストなどを出力

というような感じでできるのではないでしょうか？

適当に書いてしまったので参考程度にしてください。

簡易的なクライアントサーバにする場合は、
サーバ側のレジストリをいじらないとファイルが頻繁に壊れることがあります。その際は　サーバ側　の　Oplock　のレジストリ設定を変更してください。

参考
http://support.microsoft.com/kb/303528/ja　の
ネットワーク ファイル サーバーでの Opportunistic Locking (Oplock)　
のあたり。

回答No.4

hallo-2007

会社の規模や業種（販売だけなのか製造からなのか、販売先は固定した取引先だけなのか一般顧客が対象なのか）などにもよりますが、
最初に取り掛かるデータベースとしては大変です。
Accessで大丈夫か（Webなどを通じて作業を行う必要性があるのか）なども重要です。
Accessだけの知識ではなくネットーワークに加えて経営から会社全体の作業まで把握する必要があります。
既にNo1の方もおっしゃるとおりです。
ましてやイレギュラーな仕事はテーブルのリレーションや正規化するのが厄介です。
下手にシステムだけを最優先に決定してしまうと営業活動や開発など
無理が利かなくなったりします。
商品テーブルと取引先テーブルを作成して、売上(出荷)のテーブルをリレーションで作成するところ辺りからスタートしては如何でしょうか。
修理サービス、見積書などは他のデータベースとして分離、商品テーブルなど共有できる部分だけ共有する方向で後々、発展していくような方法が良いと思います。
一つのデータベースで行うのではなく、複数のデータベースに分けて、それぞれがテーブルを共有するなどしながら発展して行くことを検討してもらったほうが失敗が少ないのではないでしょうか。
別のデータベースで修理品のテーブルを作成して商品のテーブルだけを共有するとかしながら発展させていきます。
最初からしっかりとと云われるのであれば、それなりのプロの力を借りるべきです。
テーブルの構成の決定はPCの勉強以上に、経験や会社の経営などまで含めて深い知識が必要で、誤ると経営まで悪くしてしまいます。

お礼

そうですよね。もっと勉強してからすべき仕事だとは私も思うのですが…
皆さんおっしゃるようになるだけ小分けして後でどのように展開しても極力困らないように作ってみます。有難うございました。

回答No.3

noname#96417

専門家ではありませんので、的確なアドバイスはできませんが、おそらくリレーションシップというものについて勉強されると見通しがよくなるのではないかと思います。多様なデータをどのようにテーブルに分けて表現し、またそれらのテーブルをどのように結合して利用するかということです。

ただ、入門レベルでは、まずリレーションシップを使わない、簡単なデータベースの作成と利用（操作）から入り、そのあとでリレーションシップの学習に進んでいくのがよいのではないでしょうか。初心者向けの解説本はそのような構成になっているものが多いように思います。

たいへんさはお察しいたしますが、重要なお仕事であることは間違いありません。がんばってください。

お礼

リレーションについては本を読んで見ましたが、難しくて…。
期待されていると思って頑張ります！有難うございました。

回答No.2

noname#192382

アフターサービス、アラートについてコメントします。
このためには5つのテーブルを作ります。
1.販売先テーブル　顧客名、ID、住所、電話番号など
2.生産者テーブル　生産者名、ID、住所、電話番号など
3.商品テーブル　商品名、ID、など
4.販売テーブル　期日、商品ID、生産者ID、顧客ID、仕入れ価格、販売価格など
5．修理テーブル　期日、商品ID、顧客ID、故障原因など。故障原因はユーザーミスかメーカーミスか、耐用年数によるものかをはっきりさせる。
こんなデータベースがあれば、ある商品についてある故障が出た場合、原因がメーカーミスであれば、販売テーブルで同じ商品を納めている顧客を抽出して、その顧客に商品交換などの処置を取る。原因が耐用年数によるものであれば、販売テーブルを見て、同じ商品について納品期日の古いものを抽出して、更新を助言などの処置を取ることができます。

お礼

そうですよね、やっぱりテーブルを分離させて、リレーションさせていくべきですよね。具体的なご意見有難うございました！

回答No.1

Tasuke22

それはまずAccessに限らずデータベースの設計そのものです。
教育や訓練を受けずにいきなり仕事を一人で着手するのは
かなり厳しい環境です。同情します。混乱して当然と思います。

一般的にシステムを企画から運用まで10のフェーズに分けます。
Accessの設計といえばプログラム設計のフェーズ４あたりに
なろうかと思います。
データベースの設計はフェーズ３のシステム設計です。
しかし、その前にデータベースの論理設計が必要で、これは
フェーズ２の要件定義で確立しておきたい事案です。
論理設計がどうしても上手くいかない場合、企画そのものを
見直す必要があるからです。

常に現フェーズは前フェーズの結論に対して検証及びフィード
バックが必要です。これは予算やスケジュールで確保する問題
で、頭の悪い役員を説得する必要のあるタフな仕事です。

また、上司が口頭であれこれ言っているのをフェーズ１の企画
と捉えて、あなたが企画書をまとめた方がいいと考えます。
そして、要件定義書ですね。

企画段階から矛盾が必ずあると私は言い切ります。その矛盾を
明らかにし、企画のコンセプトを打ち出し（価値観）、コンセ
プトから企画の方向修正をし、上司に提案する必要があります。

データベースの基本的な考え方は、あなたの会社を中心とした、
取引会社と顧客の世界と商品を表現することです。
１つのテーブルには何もかもを詰め込まない、テーブルを
分けて、各テーブルはキーによって結合します。

現帳票や将来必要な帳票の全ての項目を洗い出し、単なる
項目とキーたる要件を持った項目に分けて、キーに着目します。

このテーブル分割が上手くいくと、将来の環境の変化に対する
システム修正に強いデータベースになります。柔軟性が高い
ということです。
殆どのシステムは、決め付けの固まったデータベースが、シス
テム開発中に既に世の中の変化に付いていけなくて、運用前に
使い物にならないことに気が付いたりするものです。

日本の多くのシステムがバブル崩壊のあたりから、少品種大量
生産から、多品種少量生産に社会に要求され切り替えようとし
ましたが、データベースがガチガチでシステムが付いてこれま
せんでした。

それで論理データベースの設計は、テーブルとテーブルの関係が
キーで結ばれますが、これがm対nにならないよう常に1対nにす
る必要があります。
例えば商品コードで結ばれたテーブル同志は、片側は同じ商品
コードのレコードが複数あっても構いませんが、片側は必ず１
レコードになるようなテーブルの意味になっていることです。

このモデルは最初は単純化し、テーブル名と概要とキーだけで
各テーブルの関係を線で結びつけて全体を見てみましょう。
どのテーブルのどのキーが1でどれがnか図の中に書いていきます。
いきなり細かい項目まで見る必要はありません。
木を見て森を見ず、になりますから。

データベースはあくまでも世界の模写です。
それに対して各機能がどのテーブルから取り掛かると必要な
データが得られるかが、スラスラ言えれば１面成功です。
データベースの設計がしっかりしていればするほど、機能の
実現が楽になります。
データベースが中途半端ですと、本来データベースが行わなけ
ればならないことを機能（プロセス）で行うことになり、開発
コストがかかる上、環境の変化に弱くなる訳です。

最初は細かくなりすぎるぐらいテーブルを分けてもいいでしょう。
少しずつ、何かが見えてきます。それは開発対象を理解する
糸口です。一方向だけでなく、多く方向から何かが見えて、
理解するものが生まれたら成功でしょう。あなたはそのころには
立派な設計者になっていると思います。
べき論を口にしだします。その頃が初心に帰るタイミングです。

まあ、一朝一夕では無理ですので、腰を落ち着けて頑張って下
さい。

テーマが大きく、短い時間で執りまとめが無いのは失礼します。

お礼

考える論理をたくさん教えていただいて有難うございます。道は険しいですが、こつこつやってみます。こんなことくらいは簡単なことだろうとほざいている上司に負けません!（笑）