Xupper技術サポート部のページ

弊社開発手法やXupper(クロスアッパー)の活用法等について、ご説明させていただきます。

マスタの履歴管理パターン(その2)

2006年10月03日 | データモデルパターン
文字数の関係で記事を2つに分割します。(前の記事から・・・) ■マスタ情報を複写して管理(パターン5)取引が発生した時点の商品情報を取引(トランザクション)に複写して持つことにより、過去の商品情報を管理するようにします。【図5】  ①参照時点のマスタ情報をトランザクション側に持つ場合、マスタ情報の変更が発生した場合、トランザクション側の情報も同期をとって変更する必要があります。② . . . 本文を読む
コメント (1)

マスタの履歴管理パターン(その1)

2006年10月02日 | データモデルパターン
久しぶりにデータモデルの話題です。 ここでは、マスタの履歴管理について、いくつかのパターンを挙げて説明したいと思います。 ■履歴保存用のエンティティを追加し管理(パターン1)商品エンティティのキーに適用開始年月日を保持し、変更があったタイミングでレコードを追加することにより商品の変更履歴を管理します。 【図1】 ①ある1レコードについて、ある時点の全ての属性の値を、履歴として管理することに . . . 本文を読む
コメント

明細と明細の関係を管理できるようにする・・・(モデルの汎用化⑧)

2005年09月26日 | データモデルパターン
”受注明細”のサブタイプとして”受注明細(調整)”を分離することにより、受注にまつわる調整情報を管理できるようにはなりますが、“受注明細”間の関係については、どのような関連になっているのか管理できません。 例えば、ある商品に対して10%値引きを行うといった場合、複数存在する受注商品のうち、どの商品に対して値引きを行っているのかがわからないという問題です。 また、調整明細で配送料を別途もらいうけ . . . 本文を読む
コメント

受注明細で各種調整を管理する・・・(モデルの汎用化⑦)

2005年09月22日 | データモデルパターン
一般的に受注入力を行う場合は、商品の受注情報のみではなく、さまざまな調整を行うことになります。例えば、「商品値引」「全体値引」「端数切捨て」といったものです。 しかし、前述のモデルの場合、受注明細の中で商品受注の情報も、調整の情報も管理する構造になっています。 “商品”と“受注明細”との間にリレーションを定義しているので、商品受注の情報を管理することは可能ですが、調整の情報を管理しようとすると . . . 本文を読む
コメント

取引先との関係を汎用化する・・・(モデルの汎用化⑥)

2005年09月21日 | データモデルパターン
ここまでのモデルでは、“受注”と“取引先”の関係として「受注先」「納入先」という関係のみ管理可能な形になっています。 しかし、新たに“取引先”との間で「保守先」や「問合せ先」を管理したいとなった場合、この構造ではできません。(リレーションを追加する必要があります。) 新たに管理したい関係が増えても対応可能とするように、“受注”と“取引先”との間に取引関連を管理するためのエンティティを追加します . . . 本文を読む
コメント

状態履歴を管理する・・・(モデルを汎用化する⑤)

2005年09月20日 | データモデルパターン
ここまでのモデルでは“受注”に「受注登録日」「受注変更日」「受注取消日」といった受注状態の変化した日付や、「売上計上フラグ」「出荷指示書フラグ」「受注一覧発行済フラグ」「仕入計上フラグ」といった、受注状態そのものを管理するための属性が定義されています。 しかし、受注としてどのような状態を管理すればいいかという問題は、企業や業務のやり方によって千差万別であり、同じ会社であってもビジネス要件が変更さ . . . 本文を読む
コメント

複数の取引条件を管理できるようにする・・・(モデルの汎用化④)

2005年09月16日 | データモデルパターン
ここまでのモデルは、受注に対する条件を「受注備考」を使用して管理していこうというモデルとなっています。 しかし、取引に関する条件は様々な条件が存在するはずです。例えば「キャンセル可能日数」といった取消に関する条件や、「当月売上翌月入金」「3ヶ月支払手形」「現金・振込み」「半分現金・半分手形」といった売上や入金に関する条件等などです。それらの情報を「受注備考」で管理しようとすれば、テキストで必要な . . . 本文を読む
コメント

複数担当者の管理を行えるように変更する・・・(モデルの汎用化③)

2005年09月15日 | データモデルパターン
ここまでのモデルでは、受注の担当者は入力担当者のみを管理してきましたが、営業社員の成績を把握するためには、受注単位にどの営業社員の担当分なのかがわかるようにしておく必要があります。 担当者といった場合はデータを入力するのみではなく、受注の営業担当、受注内容を確認・承認する担当者等複数の社員の関連を管理する必要があります。 また、社員からみても自分が担当する受注は1つではなく複数存在することが考 . . . 本文を読む
コメント

取引先を汎化すると・・・(モデルの汎用化②)

2005年09月14日 | データモデルパターン
前述の受注基本モデルの場合、得意先と仕入先と納入先にはそれぞれ「名称」「ふりがな名」「略称名」「郵便番号」「電話番号」「FAX番号」が定義されています。これらは、共通属性であるため、スーパータイプとして“取引先”を追加し、“得意先”“納入先”は、それぞれ“取引先”のサブタイプとして定義します。 【共通属性の分離】 また、こうすることによってデータの二重入力(管理)を避けることが可能となります。 . . . 本文を読む
コメント

まずは、基本的なモデルの説明(モデルの汎用化①)

2005年09月13日 | データモデルパターン
ここまで、各種のデータモデルのパターンについて述べてきました。 では、実際に拡張性のある(汎用的な)モデルを作成するためには、どのような手順を踏んでいけばいいのでしょうか? ここでは汎用的なモデルの作成過程を、ある例を用いて解説していきます。 今回は、もっとも一般的だと考えられる“受注”を例にして解説していきます。 一般的な受注関連のエンティティ関連図としては、以下のようなモデルが想定され . . . 本文を読む
コメント