- - PR -
SQLサーバーのテーブル設計について
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2004-10-10 02:27
[OSのVER]:Windows2000
[SQLServerのVER]:2000 現在業務系のテーブル設計を行っております。 各事業所の売上データを以下のKEY項目で集計を行い、格納します。 【売上テーブル】 PKEY 売上年月日 PKEY 事業所CD PKEY 区分 ・・・「０：当日」「１：当月内」「２：その他」 売上金額 【データ例】 20041010／A10A10／0／\1,000 ・・・売上実績が本日のもの（10/10） 20041010／A10A10／1／\2,000 ・・・売上実績が本日以外の当月内のも（10/05） 20041010／A10A10／2／\3,000 ・・・売上実績が当月でないもの（09/30、08/01） ↓ 仕様変更により以下のように対応を求められてます。 「その他月」を示す「区分：２」レコードの月ごとのサマリー結果が参照したい。 ↓ この要件を満たすべく、以下のように変更を入れました。 【売上テーブル】 PKEY 売上年月日 PKEY 事業所CD PKEY 区分 ・・・「０：当日」「１：当月内」「２：その他」 PKEY 年月 【データ例】 20041010／A10A10／0／200410／\1,000 ・・・売上実績が本日のもの（10/10） 20041010／A10A10／1／200410／\2,000 ・・・売上実績が本日以外の当月内のも（10/05） 20041010／A10A10／2／200409／\2,000 ・・・売上実績が当月でないもの（09/30、08/01） 20041010／A10A10／2／200408／\1,000 ・・・売上実績が当月でないもの（09/30、08/01） ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ここで皆様へご質問。 上記のように「年月」項目を追加するのが良いのか、あるいは別テーブルを用意したほうが いいのかということです。年月が必要なパターンは「区分：２」のみであることを考えると 別テーブルの方がいいのかなぁーと悩んでおります。区分１or２にも、年月をセットする 必要があるのもちょっと？と考えてます。（業務上、必要ありません） ただPKEYなのでNULLや空白ではあまりよろしくないと考え年月をセットしてます。 別テーブルにした場合 ↓ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ 【売上テーブル】 PKEY 売上年月日 PKEY 事業所CD PKEY 区分 ・・・「０：当日」「１：当月内」「２：その他」 売上金額 【売上詳細テーブル】・・・売上テーブルの区分２のレコードの詳細を保持 PKEY 売上年月日 PKEY 事業所CD PKEY 年月 売上金額 ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＃業務上、売上詳細テーブルを参照することは、１機能くらいです。 ＃多くの機能は、売上テーブルを参照し、売上テーブルの区分２の売上金額を ＃取得します。ほとんどの機能が売上テーブルを参照するという観点から見れば ＃売上詳細テーブルを用意し、売上テーブルのレコード件数を減らすことが ＃パフォーマンスにもつながって良いかと考えてます。 皆様のご意見やアドバイスをいただければ幸いです。 | ||||
|
投稿日時: 2004-10-10 08:38
具体的な仕様の相談を、範囲限定もしないで
掲示板で行っている事が根本的に間違っています。 設計者であるならば、その時点で仕様がどうこうの以前の問題です。 物事の性質を理解して、それに沿った行動とる様に気をつけましょう。 といっても投稿時間が、、、 パニック状態を示しているのかな？って感じですが．．． 簡単な話、b-maxさんの質問には、開発者レベルでも気にするべく ・売上テーブルを登録する全プログラムの仕様概要は？ ・売上テーブルを変更する全プログラムの仕様概要は？ ・売上テーブルを削除する全プログラムの仕様概要は？ ・売上テーブルを参照する全プログラムの仕様概要は？ が記述されていません。 そんな状態で返答しようと試みても、周囲の仕様が不明な為、 適切な判断がつきません。 自分では無理、出来ないと思えばそれを周囲に伝える事も重要な仕事です。 ＜追記＞ 周囲が無責任、どうしても解らん、、、、ならば 既存は極力触らない事をベースとして作業されると宜しいかと思います。 [ メッセージ編集済み 編集者: はにまる 編集日時 2004-10-10 08:41 ] | ||||
|
投稿日時: 2004-10-11 17:49
なんか、変。
最初の「年月日」は、何を意味しているのでしょうか？これが「入力日」であるなら、「売上日」が必要なはずです。でないと、会計上困るはずです。え〜っと、税務関係のことは詳しくないですが、法律上、まずいのでは？「入力日」は「売上日」ではあり得ず、また、「入金日」が別途必要になることがあるかもしれません。しかし、これらは別個に管理しなければ、法律上まずいのでは？ たとえば今の仕様では、ある月は売り上げが少なかったので、売り上げの多い月に入力をせず、少ない月に入力する、みたいなことをして、集計を変えてしまえますよね。それってまずいのでは？ | ||||
|
投稿日時: 2004-10-11 18:15
なんという法律ですか？ 電子計算機を使っているからといって、それが帳簿であるとは限らない。帳簿をつけずに(紙に残さないで)電子計算機で代用する場合は、電子帳簿保存法の要件を満たしている電子計算機でなければならない。 帳簿は電子化せずに、伝票発行や集計などのアシストとして電子計算機を利用している顧客は少なくない。 | ||||
|
投稿日時: 2004-10-11 22:26
そこまでb-maxさんは書いていませんよね？だから、「まずいのでは？」と聞きました。このシステムが扱う範囲が不明確だからです。 書いていないので小さく（計算のアシストだけと）考えて、「＊＊したらいい」と答えたところ、実はそのまま帳簿に印刷するようなシステムだった場合、まずいですよね（私が、ではなく、「仕様」として提出したところが）。考えられる可能性の一つを書いてみたました。なお、「売上日」「入金日」「入力日」を別々に扱わなければならない、というのではなく、その次の、今の仕様では集計を変えてしまえるようなところが、まずいのでは？と聞いています。会計には明るくないですが（当然法律も）、最近の銀行やスーパーのニュースを聞いていると、そういう計算の仕方はまずのでは？と思えます。 ＃帳簿のつじつま合わせのために使う、っていうなら、知らないけど ＃でも、法律違反の片棒担いだみたいなのは嫌だなぁ | ||||
|
投稿日時: 2004-10-12 09:17
アプリケーション・システムを中心とした勉強レベルの話ですので
間違いや漏れ、不適切な表現があるかもしれませんが、 売上日と入力日は別けて管理しなければいけません。 消費税法では、消費税を算出する基準日付はサービスが発生した日となっています。 ですから入力日では無く売上日で処理する必要があります。 # ただ課税対象期間は１月１日〜１２月３１日を対象としていますが、 # 実際の所は、月度計上で処理されている様です。（真相は不明） また現金取引で無い場合は、取引先との掛けの精算方式を契約にて取決めますが この際も自社都合により決定する入力日を利用する事はありえず もし、入力日で処理した場合は取引先側の数値（請求諸の総額と納品書の総額）と 一致せずに金額不照合の原因となります。 そして、この売上日により集計された結果が決算帳票となり 法人税の算出元となるそうです。 | ||||
|
投稿日時: 2004-10-13 00:52
返事が遅れて大変申し訳ありませんでした。
東京から離れ、また、ネットができる環境にいることができず申し訳ありません。 あまり細かく書きすぎたかなぁーと反省しております。 お聞きしたかったことはずばり「テーブル設計」の仕方となります。 投稿させていただいた内容は、テーブルを分ける、分けないのどちらでも 対応が可能です。 ですが、双方にメリット／デメリットがあるかと思い、皆様のご意見を頂きたく 投稿させていただきました。データ業務要件もちらりと記載したのは、記載があれば より具体的なご意見が伺えるかと考えたからです。 問題定義をきちんと示さなかったことをお詫びいたします。 テーブルを分ける設計が良いのかどうか、再度、皆様のご意見をいただけるでしょうか？ 皆様がご心配をしていただいている売上日項目ですが、特に売上を意識したテーブルでは なくて、単に最初の年月日は入力日とイコールであり、今日売り上げた分を今日入力したのか、それとも異なる日に入力したのかを単に把握するための集計データ群となります。 当日入力することが義務ですが、実態はそうもなっておらず、その実態を把握分析するための テーブルとなります。 | ||||
|
投稿日時: 2004-10-13 09:31
いや、全然細かく書いてないどころか必要な情報が十分に出てきていないので、回答が得られないのでしょう。提示された情報だけから判断すると「単純にテーブル設計がおかしい」という結論になると思います。 まず、テーブルが正規化されていません。常識的に正規化するなら、日別事業所別売上テーブル (売上年月日, 事業所CD, 売上金額) となるはずです。 この正規化されたテーブルを使用したとしても、当月累計(区分=1)は、高々31件の集約ですし、区分=2(その他)というのも一般的な利用ケースを考えると、その他すべてではなくて当年累計なんじゃないですか？ であれば区分=2(当年累計)も高々365件の集約になりますよね。この程度の集約であれば、リアルタイムで集計しても問題ないと私なら判断します。 でも、トランスさんはあえて毎日、当月累計と全累計を持つレコードを作製するという冗長化手法を選択したわけですよね。一般的に冗長化というのは、アプリケーション(画面やレポート)でのパフォーマンスや取り扱い易さを重視して、データベースの格納形態を調整することです。それなのに、アプリケーションでの利用形態についてほとんど何も述べずに冗長化されたテーブルを提示されても回答のしようがありません。 「正規化されていない」というコメントはできますが、「その利用形態であれば、その冗長化は適切でしょう。」というコメントはできないですね。なので、テーブルを分ける・分けないについてもコメントのしようがありません。(利用ケースが分からないので) | ||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。