- - PR -
(初心者の質問)XMLで表現する選択
1
投稿者 | 投稿内容 | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2007-04-14 09:06
いつもお世話になってます。
現在、XMLをかじり始め、EDIで使用するための 注文データをXMLであらわそうとしてます。 注文には、営業担当者、営業が管轄する顧客(営業員と担当顧客は1対多の関係) 商品、数量などがからみます。 基本的には営業員ID、 営業が データを WEBなどで入力して それをXMLデータに変換して送信、 データベースにそれを入力をイメージしてます。 属性をまったくつかわなければ <注文> <営業員> <営業員ID>A123</営業員ID> </営業員> <注文日>2007/12/31</注文日> <顧客> <顧客コード>1234</顧客コード> <注文商品> <商品コード>AAA</商品コード> <商品名>普通のねじ</商品名> <発注単位>ボックス[300個]</発注単位> <発注単価>3000</発注単価> <発注数量>3</発注数量> </注文商品> <注文商品> <商品コード>BBB</商品コード> <商品名>特殊なねじ</商品名> <発注単位>個</発注単位> <発注単価>500</発注単価> <発注数量>30</発注数量> </注文商品> </顧客> <顧客> <顧客コード>3334</顧客コード> <注文商品> <商品コード>AAA</商品コード> <商品名>普通のねじ</商品名> <発注単位>ボックス[300個]</発注単位> <発注単価>2500</発注単価> <発注数量>20</発注数量> </注文商品> <注文商品> <商品コード>CCC</商品コード> <商品名>ねじけずり</商品名> <発注単位>個</発注単位> <発注単価>200000</発注単価> <発注数量>4</発注数量> </注文商品> <注文> てな感じになるのではとは思うのですが、 属性を駆使すれば <注文 注文日="2007/12/31"> <営業員 営業員ID="A123"></営業員> <顧客 顧客コード="1234"> <注文商品 商品コード="AAA" 商品名="普通のねじ" 発注単位="ボックス[300個]" 発注単価="3000" 発注数量="3"></注文商品> <注文商品 商品コード="BBB" 商品名="特殊なねじ" 発注単位="個" 発注単価="500" 発注数量="30"></注文商品> </顧客> <顧客 顧客コード="3334"> <注文商品 商品コード="AAA" 商品名="普通のねじ" 発注単位="ボックス[300個]" 発注単価="2500" 発注数量="20"></注文商品> <注文商品 商品コード="CCC" 商品名="ねじけずり" 発注単位="個" 発注単価="200000" 発注数量="4"></注文商品> </顧客> <注文> と1:1で対応でき、将来的にも そうであるエレメントはすべて属性に突っ込んでしまうこともできます。 なにか属性にするかどうか推奨されるものはあるのでしょうか? それともこれは自由に作ってしまっていいのでしょうか? 個人的には1:1で対応できるものはすべて (たとえば商品と商品コード)属性であらわしたほうがきれいにみえます。 もう1つ質問ですが XMLの特徴は、さまざまなデータフォーマットに対応でき、 データを受け取るほうが必要な部分だけデータを加工できたり するとききましたが、 たとえば上のようなデータをもとに、 2007/12/31はずべての顧客で AAAの商品の切り口で必要な情報もXML文書からダイレクト把握できるのでしょうか? (上記の例では違う顧客が同じ製品AAAを買ったといった例ですが 顧客1234がAAAの表品を3ボックス、顧客3334がAAAの表品を20ボックス、 だから営業員A123 は 2007/12/31 に 商品AAA を 23ボックス 売りましたといった把握や 商品AAAは 単価で 3 x 3000 + 2500 x 20 で 59000円 売り上げ といった情報を、XMLのデータから直接引き出せるのでしょうか?) 要求されるデータフォーマット、および見た目(レイアウト)の両面で XMLデータは自由にあつかえるといったことを習ったのですが、勉強不足のためか はずかしながら、実際の例でまだイメージできてません。 もし理論よりも、こういった日常的なEDIの業務プロセスのデータの流れの例を豊富にのせた XMLの参考書、URLなどありましたら紹介いただけるとうれしいです。 | ||||||||||||
|
投稿日時: 2007-04-14 10:14
属性を使うのであれば、そこに設定する値が将来的にも、
改行等が含まれない事を保障できるのであればいいと思います。 でなければCDATAセクションを使う事になりますので、属性では表現できないでしょう。 集計に関してはXQueryを使うか独自で集計するかのどちらかです。 所詮XMLは単なるテキストなんで。 それを構造化したり、検索、集計などを行うのがプログラムです。 XQueryで出来ない集計などは独自で実装するしかないでしょう。 | ||||||||||||
|
投稿日時: 2007-04-16 10:48
XSLTスタイルシートを使用することで、元のXMLを異なるデータフォーマットのXMLに変換したり、見た目(レイアウト)を整えたHTMLに変換することができます。 私は書籍を買ったりしないのでお勧めの書籍は分かりませんが、@ITにも有用な情報がゴロゴロ転がっています。 例えばコレとか。ここら辺の記事を読んだだけですがそれなりに理解できましたよ。 http://www.atmarkit.co.jp/fxml/indexes/index_all.html#sp11 私は、異なるフォーマットのデータ交換のためにBizTalkServerを使っていますが、そうゆう類のミドルウェアを使うのもよいのではないでしょうか。見た目の整形をするために、ASP.NETのXMLコントロールを使ったりもしています。 ---------追記 http://www.microsoft.com/japan/biztalk/evaluation/what-is-biztalk-server.mspx BAM(ビジネスアクティビティ監視)を使って、蓄積されたメッセージを集計することもできるようです。BizTalkServerだけではなくWebSphereや他のSOA関連製品でも似たようなことができるんじゃないかと思います。 [ メッセージ編集済み 編集者: かめたろ 編集日時 2007-04-16 11:23 ] | ||||||||||||
|
投稿日時: 2007-04-20 04:03
かつのりさん、かめたろさん、ありがとうございました。
早速、読んでみます。 ちょっと技術というより商売の仕組み的?なことなんですが 今、疑問にあるのは、EDIの統一フォーマットということでXMLが持ち上げられてましたので、私のような素人はいままで Mつのメーカー、Nつの卸業、Lつの小売があったとすれば、 卸と小売だけでも Nつの卸業者が、Lつの小売に対してそれぞれフォーマット、データ体系 変形行うために、 変換が(最悪の場合はデータの項目が足りずもとの構造にデータ追加) 1つの卸が最悪 NつのEDIフォーマットに対応?しなければ、 つまり社会全体で最大 N x L とうり さらにメーカに卸をとうしたり、直販まで含めるとすさまじい数になります。 (まあだいたい商習慣で業界によってフォーマットは決まっているのでしょうが 力のあるメーカ、小売とたくさん取引して独自規格が乱立すると結構大変な気がします) これがある程度、解決できるものとしてXMLをみていました (XML紹介の記事を読んでそういう印象をうけて本格的にXMLのEDIの応用を勉強しはじめました) なにかEDIを使う団体、流通のサプライチェーンがXMLを利用して ”電化製品の流通のEDIにはこういったXMLの構造を標準として使いましょう!” ”食品の流通のEDIにはこういったXMLの構造を標準として使いましょう!” といったものはないのでしょうか? とんちんかんな質問ですみません。 | ||||||||||||
|
投稿日時: 2007-04-20 11:41
流通ではないですが、例えばココ。 http://www.xmlconsortium.org/ ContactXML、TravelXML、ContentsBusinessXMLってのがあるようです。普及させるのはなかなか難しいようではありますが・・・。 「流通XML」で検索するといいかも。 | ||||||||||||
|
投稿日時: 2007-04-21 13:12
業界標準として、規格はいろいろありますよね。 フォーマットが統一されているのであれば、それがXMLである必要もないわけです。 XMLはデータ構造を表現できますし、その構造の変更が容易なため重宝されるのだと思います。
既にXMLを業界統一フォーマットとして使用している業種は存在します。 力のあるところが旗を振らないと実現が難しいし、現在のフォーマットを捨て去ることにもなりますので、 (システムのリプレースが必要になりますから) あの業種もこの業種もとはなっていないようですが。 元のかきこみについてですが、属性を1要素に詰め込むとパッと見で見易いのですが、 情報としては今一扱いにくいと私は思っています。 <注文商品 商品コード="AAA" 商品名="普通のねじ" 発注単位="ボックス[300個]" 発注単価="2500" 発注数量="20"> XMLもデータの集まりでしかないので正規化することで、私なら上記XMLを 以下のように書き換えます。 (データ内容が良く分からないので不適切な部分があるかもしれませんがイメージとして…… 商品単価は適当な値。発注単価と商品単価は別なのですよね。)
また、きのこさんの書き込みでは注文と顧客の情報が入れ子になっています。 この辺り整理すると綺麗になりますね。 | ||||||||||||
|
投稿日時: 2007-04-24 00:32
かめたろさん
情報、ありがとうございました。 暁さん わざわざ私のデータをもとに例をだしていただきありがとうございました。 たいへんわかりやすいです。 (RDBの定石と同様、商品マスターと売上トランスアクションは わけたほうがいいんですね(というよりRDBと同様正規化したほうがいいんですね) 私の例では、商品マスターの単価はあくまで参考、顧客、発注数量によってある程度、 変動します。 (RDBと同様にこれも別でXMLで正規化して定義したほうがいいのかもしれませんが) たしかに XMLは親子関係の表現にすぐれているので複数ある親子関係 わざわざ、無理にRDBで表現するよりも自然ではありますね。 ただ変換にかんしてはかめたろさんが紹介していただいた http://www.atmarkit.co.jp/fxml/indexes/index_all.html#sp11 を読んだだけなのでなんともいえませんが、プログラムの知識がないと結構難しそうなので実際の変換作業自体は難易度や作業手数は、 すでに構造変換したデータを提供する先の会社がそれなりの ネットワークとDBを構築しているのであれば RDBのSELECT &INSERT のDB上でのSQL文でするのとそれほどかわらないような気もします。 (ただかなりプログラミングとしての機能をそなえているのであらゆることができそうですが) おそらく、SQLでやるのであれば構造変換したデータを受け取るすべての会社や団体が SQL通信をうけいれるためのネットワークの整備、DBの構築、セキュリティー設定、テーブル設計などをするよりはCSVよりはるかに変換が簡単な XMLファイルでポンとわたしてしまったほうが簡単だとということだと推測してますが。 間違っていたらご指摘ください。 本当にありがとうございました。 |
1