2 XML 2 XMLスキーマ設計目次 2.1 XMLスキーマスキーマとは

by user

on 15 сентября 2016

Category: Documents

>> Downloads: 3

views

Report

Comments

Description

Download 2 XML 2 XMLスキーマ設計目次 2.1 XMLスキーマスキーマとは

Transcript

2 XML 2 XMLスキーマ設計目次 2.1 XMLスキーマスキーマとは

ビジネス・ユニットの名前
IBM Information Management software
2 XMLスキーマ設計
© 2007 IBM Corporation
1
ビジネス・ユニットの名前
IBM Information Management software
2 XMLスキーマ設計目次
2.1 XMLスキーマ
スキーマとは
XMLスキーマ設計
2.2 XMLスキーマ設計のステップ
•
•
•
•
XMLスキーマの記述パターン
XMLスキーマ記述パターンの選択
XMLスキーマ記述パターン選択のポイント
XMLスキーマ分割方針の決定
XMLスキーマ設計のステップ
E. XMLスキーマおよびXMLインスタンスのプロトタイプの
作成
A. 再利用スキーマ候補の調査(業界
標準等の調査)
F. XMLスキーマの詳細設計
B. ネーミングと名前空間
ネーミングルールの定義
XMLにおける名前空間
名前空間の定義
XML Schemaにおける名前空
間
C. XMLインスタンスの設計
•
•
•
•
•
•
•
2
D. XMLスキーマの記述方針決定
XMLインスタンス単位の検討
ルート要素の検討
インスタンスIDの検討
•
•
型と構造の定義
データ型の検討(単純型)
•
•
•
•
•
派生型の宣言
複合型での構造
UMLクラス、エンティティの表現
関連の表記
関連IDの整理
•
•
多重度と空要素の検討
属性化の検討
G. XMLスキーマとXMLインスタンス・サンプルの完成
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
2.1 XMLスキーマ
© 2007 IBM Corporation
3
ビジネス・ユニットの名前
IBM Information Management software
ブランク・ページです。
4
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
XMLスキーマとは
XMLの文法
XMLの文法
に従っている
に従っている
XMLの文書構造を定義するもの
XMLの文書構造を定義するもの
Well
-formedな
(整形式の)
XML
スキーマに
スキーマに
適合している
適合している
XML
スキーマ
文書
XML Parser
XML
スキーマはXMLの文法に従っていない
DTD
DTD
<?xml encoding="UTF-8"?>
<!ELEMENT si:schemaInfo (targetNamespace,schemaDocInfo)>
<!ATTLIST si:schemaInfo
xmlns:si CDATA #FIXED 'http://www.ibm.com/DB2/XSR/XMLSchema'
xmlns:xsi CDATA #FIXED 'http://www.w3.org/2001/XMLSchema-instance'
xsi:schemaLocation CDATA #REQUIRED>
<!ELEMENT targetNamespace (#PCDATA)>
<!ATTLIST targetNamespace
xmlns CDATA #FIXED ''>
<!ELEMENT si:schemaDocInfo (schemaLocation,properties)>
<!ATTLIST si:schemaDocInfo
xmlns:si CDATA #FIXED 'http://www.ibm.com/DB2/XSR/XMLSchema'
docID #REQUIRED>
<!ELEMENT schemaLocation (#PCDATA)>
<!ATTLIST schemaLocation
xmlns CDATA #FIXED ''>
<!ELEMENT properties EMPTY>
<!ATTLIST properties
xmlns CDATA #FIXED ''>
5
Validな
(妥当な)
XML
妥当か
整形か
スキーマ自体がXMLの文法に従っている
XML
XMLSchema
Schema
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
targetNamespace="http://www.ibm.com/DB2/XSR/XMLSchema"
xmlns:si="http://www.ibm.com/DB2/XSR/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<xs:import namespace="http://www.w3.org/2001/XMLSchema-instance"
schemaLocation="xsi.xsd"/>
<xs:element name="schemaInfo">
<xs:complexType>
<xs:sequence>
<xs:element name="targetNamespace" form="unqualified"
type="xs:anyURI"/>
<xs:element ref="si:schemaDocInfo"/>
</xs:sequence>
<xs:attribute ref="xsi:schemaLocation" use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="schemaDocInfo">
<xs:complexType>
<xs:sequence>
<xs:element name="schemaLocation" form="unqualified" type="xs:anyURI"/>
<xs:element name="properties" form="unqualified">
<xs:complexType/>
</xs:element>
</xs:sequence>
<xs:attribute name="docID" use="required" type="xs:integer"/>
</xs:complexType>
</xs:element>
</xs:schema>
RELAX
RELAXNG
NG
<?xml version="1.0" encoding="UTF-8"?>
<grammar xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:si="http://www.ibm.com/DB2/XSR/XMLSchema" ns=""
xmlns="http://relaxng.org/ns/structure/1.0"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<start>
<element name="si:schemaInfo">
<attribute name="xsi:schemaLocation"/>
<element name="targetNamespace">
<data type="anyURI"/>
</element>
<element name="si:schemaDocInfo">
<attribute name="docID">
<data type="integer"/>
</attribute>
<element name="schemaLocation">
<data type="anyURI"/>
</element>
<element name="properties">
<empty/>
</element>
</element>
</element>
</start>
</grammar>
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説：

XMLにおけるスキーマとは、XMLインスタンスの構造を定義したものです。つまりXMLインスタンス内に出現する要素や属
性の配列に関して、名前、正しい並び方、データ型などを記述します。

スキーマを記述するための言語を、スキーマ言語と言います。主なXMLスキーマ言語には次のようなものがあります。
–
DTD (Document Type Definition)
–
XMLの前身であるSGMLから使用されているスキーマ言語。要素、属性、階層構造などを定義する。
W3C XML勧告(http://www.w3.org/TR/REC-xml/）[2-1]で定義されているが、DTD自体はXMLの文法に
は従っていない。
XML Schema
–
• W3Cにより勧告されたスキーマ言語。(http://www.w3.org/TR/xmlschema-0/)[2-2]
• XML文法に従っており、名前空間のサポートがある。
RELAX NG
•
•
•
•
6
OASISによって制定されている。（http://www.relaxng.org/）[2-3]
XML Schemaより簡潔な仕様となっている。

XMLスキーマ言語によって書かれた、XML構造の定義ファイルをXMLスキーマ文書と呼びます。

XML文書の構造をデザインすることは、その文書のためのXMLスキーマを定義することです。

XML文書は、XMLスキーマに照らし合わせて、正しい構造になっているかどうか検証することができます。この過程を妥当
性検査(validation)と言い、正しい構造を持つXMLインスタンスを妥当なXMLインスタンスまたはvalidなXMLインスタンスと
呼びます。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
XMLスキーマ設計
データモデリング結果をXML Schemaで表現
– DB2ではW3C XML Schemaをサポート
• 本書では、W3C XML Schemaで記述したスキーマを作成する方法を解
説
スキーマ記述での考慮事項
– XML Schema記法の標準化
– コメントの記述
• 文書価値、メンテナンス性向上のためにコメントの記入を推奨
– <xs:annotaion>を使用したコメント
<xs:annotaion>
<xs:documentation>人が読むためのコメント</xs:documentation>
<xs:appinfo>機械処理用のコメント</xs:appinfo>
</xs:annotation>
– 記法を使用したコメント
© 2007 IBM Corporation
7
ビジネス・ユニットの名前
IBM Information Management software
解説：
8

XMLスキーマ設計では、XMLインスタンスの構造を決定し、できあがったスキーマをスキーマ文書として表現します。

DB2では、妥当性検査用スキーマとしてW3C XML Schema, DTDをサポートしていますが、本書では、スキーマをW3C
XML Schemaを用いて設計、定義する方法を解説します。W3C XML Schemaの文法、書き方自体の解説は本ガイドの目
的ではありません。設計に必要な知識については解説しますが、詳細は適宜XML Schema関連の書籍, Webページ等を
参照してください。(DB2のサポートするXML Schemaについては、文献[2-2]を参照してください。)

XMLスキーマを設計するにあたり、以下の点についてプロジェクトで考慮されることをお勧めします。
– XML Schemaの書式の標準化
• 字下げ、改行など読み易さを考慮した書き方の標準化をご検討ください。
– コメントの記述
• XML Schemaのドキュメントとしての価値を高め、メンテナンス等を容易にするため、できるかぎりコメントを
記入されることをお勧めします。
• XML Schemaで表現できない設計の根拠や、ビジネス上の要求、また他の文書との関連で注意しておくべ
きことがらなどは、コメントとして記録しておくことが望まれます。
• XML Schemaにおけるコメントは、以下の2つの形式で記述することができます。
• <xs:annotation>を使ったコメント
– W3C XML Schemaで定義されたコメントの書き方です。W3C XML SchemaにのっとってXMLス
キーマを記述する際には、こちらをお勧めします。
– <xs:annotation>要素として自由なコメントを記述することができます。
– <xs:annotaion>要素を使用するためには、 xmlns:xs=“http://www.w3.org/2001/XMLSchema”名
前空間宣言が必要です。
– <xs:annotaion>の子要素としては、<xs:document>と<xs:appinfo>があり、<xs:document>は人
が読むことを想定したコメント、<xs:appinfo>は機械で処理するためのコメントを記入します。
– DB2の提供するXML分解機能では、<xs:appinfo>を使用して、DB2にXMLを分解してRDB表に格
納するための指示を与えます。
• 
– HTMLなどと共通のコメントの書き方です。XMLSchema名前空間を宣言しなくても記述することが
できます。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
2.2 XMLスキーマ設計のステップ
© 2007 IBM Corporation
9
ビジネス・ユニットの名前
IBM Information Management software
ブランク・ページです。
10
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
XMLスキーマ設計のステップ
A
再利用スキーマ候補の調査
（業界標準等の調査）
E
B
ネーミングと名前空間
F
ネーミングルールの定義
名前空間の定義
C
D
XMLスキーマの
詳細設計
型と構造の定義
関連の表現
多重度と空要素の検討
属性化の検討
XMLインスタンスの設計
XMLインスタンス単位の検討
ルート要素の検討
インスタンスIDの検討
XMLスキーマおよび
XMLインスタンスの
プロトタイプ作成
G
XMLスキーマとXML
インスタンスの
サンプル完成
XMLスキーマの記述方針
決定
XMLスキーマ記述パターンの選
択
XMLスキーマ分割方針の決定
© 2007 IBM Corporation
11
ビジネス・ユニットの名前
IBM Information Management software
解説：

この節では、XMLスキーマ設計のステップに沿って、考慮すべき事柄を解説します。

XMLスキーマの設計ステップは上の7ステップからなります。各ステップで、行うことの内容は以下のようなものです。

A. 再利用スキーマ候補の調査(業界標準等の調査)
– XML化対象範囲において、利用可能な業界標準がないか調査します。業界標準を使用する場合は、その適用方
法、カストマイズ必要性の有無、既存の他のアプリケーションとの関連において必要なことを調査します。
– この章では、以下、スキーマを再利用するのではなく、新たにスキーマをデザインするという観点でステップの説明
を行います。

B ネーミングと名前空間
–
ネーミングルールの定義
ネーミングルールを確立します。既存のネーミングルール、辞書等がある場合には、利用します。
XMLでは、データとして、データ名(タグ),データが共に保存され、また、RDBにおけるカタログのようにメタデー
タを別に保管する場所を持たないことから、ネーミングルールの定義は重要です。
–
名前空間の定義
XMLでは、名前空間を利用して、名前の衝突を避け、他の業務との連結、システムの拡張に対する柔軟性を確
保します。
C XMLインスタンスの設計
– XMLインスタンス単位の検討
同一のXMLインスタンスに収めるべき範囲を、業務での使用、DBへの保管の観点から決定します。
– ルート要素の検討
上で決定したXMLインスタンスの範囲で、XMLインスタンスのルートは何にすべきか決定します。
– インスタンスIDの検討
XMLインスタンスを一意に識別することの必要性を検討し、必要な場合、識別するためのアイデンティファイア
(ID)を検討します。

12
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説：

D XMLスキーマの記述方針決定
–
XMLスキーマ記述パターンの選択
読みやすさ、再利用のしやすさを考慮して、XMLスキーマの記述パターンを決定します。
– XMLスキーマ分割方針の決定
XMLスキーマ記述パターンおよび名前空間の定義を考慮して、XMLスキーマの範囲、分割方針を決定します。
E XMLスキーマおよびインスタンスのプロトタイプの作成
– 上位ステップの検討結果をもとにXMLスキーマ(.xsdファイル)およびXMLインスタンス(.xmlファイル)のプロトタイプを
作成します。
– これ以降のステップは、XMLスキーマのプロトタイプを推敲していきます。

F XMLスキーマの詳細設計
– XMLスキーマの内容を推敲していきます。検討すべき項目としては、以下のようなものが挙げられます。
– 型と構造の定義
• 単純型
– ビルトインデータ型
– 派生型
> 制約、デフォルト値、制限/restriction、拡張/extensionの与え方
• 複合型での構造
– 関連の表現
• 依存関係(親子関係) の表現
• 非依存関係の表現
• 汎化(継承)関係の表現
– 多重度と空要素の検討
– 属性化の検討

G XMLスキーマとXMLインスタンス･サンプルの完成
– 最終成果物としてのXMLスキーマ(.xsdファイル)とXMLインスタンス(.xmlファイル)を用意します。
© 2007 IBM Corporation
13
ビジネス・ユニットの名前
IBM Information Management software
ブランク・ページです。
14
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
A. 再利用スキーマ候補の調査
利用可能な業界標準の調査
業界標準を使用する場合は、以下を考慮
– 適用方法
– カストマイズ必要性の有無
– 既存の他のアプリケーションとの関連において、必要な
事象
© 2007 IBM Corporation
15
ビジネス・ユニットの名前
IBM Information Management software
解説：
16

XML化対象範囲において、利用可能な業界標準がないか調査します。業界標準を使用する場合は、その適用方法、カスト
マイズ必要性の有無、既存の他のアプリケーションとの関連において必要なこと等を調査します。

この章では、以下、スキーマを再利用するのではなく、新たにスキーマをデザインするという観点でステップの説明を行いま
す。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
B. ネーミングと名前空間 - ネーミングルールの定義
XMLはデータ（値）とメタデータ（要素名、属性名など）を同時に表現している言語であり、XML名に
は、データの意味を分かりやすく表現した名称（＝ネーミング）が必要
– 例えば、UMLクラス図のクラス名と属性名を組み合わせて、要素名にする
– 名称の長さに対する制限が緩やかなので、略語は必ずしも使用する必要はない
名称には半角英数字を使用することを推奨
使用する用語は統一する
– 例えば、‘お客様’‘顧客’は、customerに統一する
– 既存の用語辞書があれば活用する
XML名（要素名、属性名、接頭辞名）はできるだけ重複しないように付与することを推奨
– XMLスキーマ内やnamespace内ではできるだけユニークにする
<Home>
<HomeAddress>…</HomeAddress>
要素名だ
</Home>
けでどこの
<Business>
住所かが
<BusinessAddress>…</BusinessAddress>
わかる
</Business>
<Home>
<Address>…</Address>
</Home>
<Business>
<Address>…</Address>
</Business>
複数の用語を組み合わせる場合
要素名と上
位階層を組
み合わせな
いと、どこの
住所かわか
らない
– UpperCamelCaseルールを使用する、など統一したルールを決めて分かりやすくする
例） X customeraddress -> ○ CustomerAddress
© 2007 IBM Corporation
17
ビジネス・ユニットの名前
IBM Information Management software
解説：

XMLはデータ（値）とメタデータ（要素名、属性名など）を同時に表現できる言語であり、要素名、属性名などのXML名には、データの意
味を分かりやすく表現した名称（＝ネーミング）が必要になります。
– 他者が見てわかりやすくし、名称の統一をはかるために、ネーミングルールを定義する必要があります。
– 要素に関する分かりやすいネーミングの例として、XMLデータの元となるUMLクラス図がある場合にはクラス名と属性名を組
み合わせる、リレーショナルデータ定義がある場合には表名と列名を組み合わせる、などが考えられます。
– 列名などの文字数制限が厳しいRDBとは異なり、XML名に略称を使用する必要性は必ずしもありません。（DB2でのXML名
の文字数制限については後述）
– 一般的な略語（IDなど）以外の略語を使用する場合は、xs:annotationにより説明を加えるとわかりやすくなります。

XMLインスタンスの国際的な交換や標準への準拠を想定する場合は、英語を利用することが望ましいと考えられます。

ネーミングに使用する用語を定義しておくことで、名称の統一を図ることができます。
– UMLクラス図やリレーショナルデータで使用されている用語を使用する。
– 既存の業務用語辞書などを利用する。

XML名の重複はできるだけ避け、要素名や属性名などはXMLスキーマ内やnamespaceの範囲内ではユニークにすることが推奨され
ます。ただし、複数の似た種類のノードを共通に扱いたい場合には、同一の名前をつけてパスや属性等で区別することも考えられます。
– XML名がユニークとなる場合、
• 名称だけで、データの意味を表すことができます。
• 要素や属性などを特定する際に、名称だけで可能です。（例えば、XPath表現で、/*/HomeAddressと記述できる）
逆に類似の似た種類のノードをリストしたいとき、すべてを列挙しなければならないことがあります。
– 例. Home, Officeを問わず、住所を列挙したい
• グローバルに宣言して外部参照可能とすることができます。
– XML名がユニークにならない場合、
• 名称だけで、データの意味を表せない場合があります。
• 要素や属性などを特定する際に、階層、属性などが必要になります。（例えば、XPath表現で、 /*/Home/Addressの
ように上位階層が必要。逆に、特定せずリストしたい場合には、/*/Addressのように単純に共通に記述できます。）
複数の用語を連結する場合には、UpperCamelCase（先頭を大文字にして単語を連結する）などを利用すると、わかりやすくなります。

18
国連の標準化組織であるUN/CEFACTが、標準XMLスキーマを設計する際のネーミングルールが以下のリンクにあります。[2-4]
– http://www.unece.org/cefact/xml/xml_index.htm
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
B. ネーミングと名前空間 - XMLにおける名前空間(namespace)
XML文書を構成する語彙がユニバーサルに一意であることを保証する
XML
XML
文書
文書
XML
XML
文書
文書
XML
XML
文書
文書
XML
XML
文書
文書
ネーミングルール
ネーミングルール
XML
XML
文書
文書
XML
XML
文書
文書
<?xml version="1.0"?>
<Company
xmlns="http://example.com/Companyns"
名前空間
xmlns:emp="http://example.com/Employeens"
名前空間の単位で名前を管理。
業務単位など
xmlns:cus=“http://example.com/Productns”>
<Employee>
接頭辞
<emp:Name>夏目漱石</emp:Name>
名前空間のエイリアスの役目を果たす。
要素名に接頭辞を修飾すると、
該当のNamespaceが適用される。
ここでは、社員(Employee)と製品(Product)に
別々の名前空間を与え、
Name要素の名前の衝突を避けている。
<emp:ID>12345</emp:ID>
</Employee>
<Product>
<cus:Name>PC2007</cus:Name>
Namespace宣言
適用されるスコープはCompany要素とその内側の要素や属性。
接頭辞なしの宣言がスコープ内の省略時名前空間となる。
各々のXML名は宣言された名前空間に対して一意でなければいけ
ない。
</Product>
</Company>
© 2007 IBM Corporation
19
ビジネス・ユニットの名前
IBM Information Management software
解説：

名前空間(namespace)は、XML文書の中で要素名や属性名などとして使われる名前の集合体であり、XML文書中の語彙
が一意になることを保障する仕組みです。

名前空間は、XML文書において、文書内の語彙がどの名前空間に属すか宣言する”Namespace宣言”を行って使用します。

名前空間の接頭辞
–

省略時名前空間(default namespace)
–

20
namespace宣言において、XML文書内の語彙が明示的にどの名前空間に属するか指定するため、名前の前に：
（コロン)をつけて宣言します。
XML文書内で、接頭辞の省略時に語彙が属す名前空間の宣言です。
名前空間の範囲について、どのように定義するべきか決まりはありませんが、名前空間が要素、属性等の名前の集合であ
ることから、名前の管理が行われる範囲として、業務単位などで分けることが考えられます。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
B. ネーミングと名前空間 - 名前空間の定義
柔軟にスキーマを拡張していくために、名前空間が重要
– 名前空間を利用して、個々のスキーマにおける語彙のユニーク性を保つことで、ス
キーマの相互利用が可能
名前空間の範囲の決め方
– 範囲の決め方には複数のパターンがあり、複数のパターンを併用することも考えられる
– 開発方針、既存の辞書、将来性への要件などに応じて選択する
１
２
パターン例
例
特長
リソースやイベントエ
ンティティ単位
商品マスタ
ERモデルなどから導出しやすい
注文
共通利用しやすい単位
システム単位
受注と請求
開発プロジェクト内部で、要素や属性の意味
及び語彙を定めればよい
システム間で語彙が重複する可能性が生じ
る
３
業務単位
経理、販売
既存の業務辞書を利用できる
© 2007 IBM Corporation
21
ビジネス・ユニットの名前
IBM Information Management software
解説：
22

名前空間を利用することで、XMLスキーマの相互利用が柔軟にできるようになります。
– 複数のスキーマで要素名などが重複していても、名前空間の接頭辞によって、その要素が属する名前空間がわ
かります。
– 例えば、業界標準XMLスキーマや他社XMLスキーマなど、複数のXMLスキーマを組み合わせる場合に、名前空
間によって語彙のユニーク性を保ち、語彙の属する範囲（業務・業界標準・他社など）を識別することができます。

名前空間の範囲について、どのように定義するべきか決まりはありません。

スライドには、名前空間の範囲の一例として、エンティティ単位、システム単位、業務単位をあげています。
– この他にも、自社を一つの範囲とする、スキーマ変更に伴って要素や属性の意味が変わった場合にnamespace
を変えることでバージョン管理をする、なども考えられます。

決め方は必ずしも一つにする必要はなく、リソースエンティティ単位と業務単位を組み合わせるような決め方も考えられま
す。

開発方針、既存の辞書の範囲（例えば、全社的に用語を統一した辞書があるのか、特定システムで定めた辞書があるの
か、など）、複数システムでの再利用や他社との連携といった将来要件、などを考慮して名前空間の範囲を定めることにな
ります。

名前空間のネーミングルール
– 名前空間の名称はユニークである必要がります。決定の際には注意が必要です。
– ネーミングルール案
• 会社のURL（intrenet内で一意)/システム名など会社内で一意のもの/分割範囲名称
– xsi:schemaLocation
• XMLでスキーマ文書を特定するためには、xsi:schemaLocation属性を使用します。schemaLocationには、
名前空間のURIと、スキーマ文書のURIをペアで指定します。
• 例：
xsi:schemaLocation=“http://www.ibm.co.jp/XmlDesignGuide/Torihikisaki.org Customer.xsd”
• DB2では,XMLインスタンスの妥当性検査を行うときに、XMLインスタンス中に埋め込まれた
schemaLocationを使用することもできますが、スキーマをDB2 XMLスキーマ・リポジトリ(XSR)に登録する
ときにつけるスキーマ名を用いることもできます。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
B. ネーミングと名前空間 - XML Schemaにおける名前空間
所属する名前空間はTargetNamespaceで宣言
– TargetNamespaceを宣言しない→カメレオンスキーマ
他のスキーマ文書の利用パターン
– Heterogeneousパターン
• 再利用する側と、再利用される側の名前空間が異なる
• import
– Homogenousパターン
• 再利用する側と、再利用される側の名前空間が同一
• include
<?xml version="1.0"?>
– カメレオンパターン
• カメレオンスキーマを
再利用する
• include
<xs:schema xmlns:xs=“http://www.w3.org/2001/XMLSchema”
targetNamespace=“http://sample.employee.org”
TargetNamespace
http://sample.employee.org
xmlns="http://www.sample.employee.org“
PersonType
elementFormDefault="qualified">
<xs:complexType name="PersonType">
<xs:sequence>
Name
<xs:element name="Name" type="xs:string"/>
<xs:element name=“ID" type="xs:string"/>
</xs:sequence>
ID
</xs:complexType>
</xs:schema>
© 2007 IBM Corporation
23
ビジネス・ユニットの名前
IBM Information Management software
解説：

XML Schemaにおいて、スキーマ文書内で宣言している語彙の登録先は、TargetNamespaceで指定します。

TargetNamespaceを宣言しない場合は、カメレオンスキーマと呼ばれます。

別のXMLスキーマ文書を再利用するパターンは以下の3つがあります。
–
Heterogeneousパターン
•
•
–
Homogenousパターン
•
•
再利用する側の名前空間と、される側の名前空間が同一である場合
再利用したいスキーマをincludeすることにより、再利用します。
–
カメレオンスキーマを再利用する場合
–
これらの使用方法について、さらに知りたい場合は、以下のサイトを参照してください。
•
•
24
再利用する側の名前空間が、される側の名前空間と異なる場合
名前空間のimportを宣言します。
includeします。
XML Schemas: Best Practices by Roger L. Costello [2-5]
http://www.xfront.com/ZeroOneOrManyNamespaces.pdf
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
参考： Heterogenousな名前空間
customer.xsd
employee.xsd
<?xml version="1.0"?>
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace=“http://example.com/employeens”
targetNamespace="http://example.com/customerns"
xmlns="http://example.com/employeens “ elementFormDefault="qualified">
xmlns=“http://example.com/customerns” elementFormDefault="qualified">
<xs:complexType name=“EmployeeType">
<xs:complexType name=“CustomerType">
<xs:sequence>
<xs:sequence>
<xs:element name="Name" type="xs:string"/>
<xs:element name=“ID" type="xs:string"/>
TargetNamespace宣言が<xs:element name=“CusomerName" type="xs:string" />
それぞれ異なる
<xs:element name=“CustomerID” type=“xs:string” />
</xs:sequence>
</xs:sequence>
</xs:complexType>
</xs:complexType>
</xs:schema>
</xs:schema>
<?xml version="1.0"?>
sales.xsd
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
import
targetNamespace=“http://example.com/salesns” xmlns=“http://example.com/salesns” elementFormDefault="qualified"
xmlns:emp=“http://example.com/employeens”
xmlns:cus="http://example.com/customerns">
<xs:import namespace=“http://example.com/employeens” schemaLocation=“http://example.com/employeens employee.xsd"/>
<xs:import namespace=“http://example.com/customerns” schemaLocation=“http://example.com/customerns customer.xsd"/>
<xs:element name=“Sales">
<xs:complexType>
<xs:sequence>
<xs:element name=“Customer" type=“cus:CustomerType" />
<xs:element name=“SalesPerson" type=“emp:EmployeeType” />
<xs:element name=“SalesAmount” type=“xs:integer” />
</xs:sequence>
</xs:complexType>
</xs:element>
25
© 2007 IBM Corporation
</xs:schema>
ビジネス・ユニットの名前
IBM Information Management software
解説：

sales.xsdは、employee.xsd, customer.xsdで定義された型(CustomerType, EmployeeType)を再利用しています。

sales.xsd, employee.xsd, customer.xsdで宣言されたTargetNamespaceはそれぞれ異なるので、sales.xsdでは、利用し
たいスキーマをimportしています。

Heterogenousパターンでは、名前には名前空間の接頭辞をつけて、どの名前空間に属するものかを区別します。
したがって、その属す名前空間内で一意の名前を持っていれば、importされて再利用される場合にも名前の衝突は起こり
ません。
<?xml version="1.0"?>
このスキーマに基づくXMLインスタンスは右のように
<Sales xmlns=“example.com/salesns"
なります。

XML Schemaをデザインする際には、
このように、xsdごとに必ずTargetNamespaceを
宣言し、名前空間を明示することを
おすすめします。
xmlns:cus="http://example.com/customerns"
xmlns:emp="http://example.com/employeens"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://example.com/salesns sales.xsd">
<Customer>
<cus:CustomerName>猫山商事</cus:CustomerName>
<cus:CustomerID>12345</cus:CustomerID>
</Customer>
<SalesPerson>
<emp:Name>夏目金之助</emp:Name>
<emp:ID>45678</emp:ID>
</SalesPerson>
<SalesAmount>56</SalesAmount>
</Sales>
26
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
参考： Homogenousな名前空間
customer.xsd
employee.xsd
<?xml version="1.0"?>
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace=“http://example.com/salesns”
targetNamespace="http://example.com/salesns"
xmlns="http://example.com/salesns “ elementFormDefault="qualified">
xmlns=“http://example.com/salesns” elementFormDefault="qualified">
<xs:complexType name=“EmployeeType">
<xs:complexType name=“CustomerType">
<xs:sequence>
<xs:sequence>
<xs:element name="Name" type="xs:string"/>
<xs:element name=“ID" type="xs:string"/>
TargetNamespace宣言が
同一
<xs:element name=“CusomerName" type="xs:string" />
<xs:element name=“CustomerID” type=“xs:string” />
</xs:sequence>
</xs:sequence>
</xs:complexType>
</xs:complexType>
</xs:schema>
</xs:schema>
<?xml version="1.0"?>
sales.xsd
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
include
targetNamespace=“http://example.com/salesns” xmlns=“http://example.com/salesns” elementFormDefault="qualified">
<xs:include schemaLocation=“http://example.com/salesns Employee.xsd"/>
<xs:include schemaLocation=“http://example.com/salesns Customer.xsd"/>
<xs:element name=“Sales">
<xs:complexType>
<xs:sequence>
<xs:element name=“Customer" type=“CustomerType" />
<xs:element name=“SalesPerson" type=“EmployeeType” />
<xs:element name=“SalesAmount” type=“xs:integer” />
</xs:sequence>
</xs:complexType>
</xs:element>
27
© 2007 IBM Corporation
</xs:schema>
ビジネス・ユニットの名前
IBM Information Management software
解説：

上の例ではsales.xsdは、employee.xsdに定義されたEmployeeType, customer.xsdに定義されたCustomerTypeを再利
用しています。

すべて同一の名前空間に属すので、再利用したいスキーマをincludeしています。

Homogenousパターンでは、再利用時に名前の衝突が起こらないことが条件です。

このスキーマに基づくXMLインスタンスは右のようになります。

すべて同一の名前空間に属しているため
名前空間接頭辞がなく、名前が短くなる利点は
ありますが、元々どのxsdで宣言されていたかは
わかりません。

この方法を使うのは、同じ業務単位などで本来同じ
管理範囲であるけれども、ファイルサイズの都合
等で、スキーマファイルは分割しておきたい
というような場合になります。
<?xml version="1.0"?>
<Sales xmlns=“example.com/salesns“
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://example.com/salesns Sales.xsd">
<Customer>
<CustomerName>猫山商事</CustomerName>
<CustomerID>12345</CustomerID>
</Customer>
<SalesPerson>
<Name>夏目金之助</Name>
<ID>45678</ID>
</SalesPerson>
<SalesAmount>56</SalesAmount>
</Sales>
28
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
参考：カメレオン・スキーマ
customer.xsd
employee.xsd
<?xml version="1.0"?>
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
elementFormDefault="qualified">
<xs:complexType name=“EmployeeType">
<xs:complexType name=“CustomerType">
<xs:sequence>
<xs:element name="Name" type="xs:string"/>
<xs:element name=“ID" type="xs:string"/>
<xs:sequence>
TargetNamespace宣言
を持たない
<xs:element name=“CusomerName" type="xs:string" />
<xs:element name=“CustomerID” type=“xs:string” />
</xs:sequence>
</xs:sequence>
</xs:complexType>
</xs:complexType>
</xs:schema>
</xs:schema>
<?xml version="1.0"?>
sales.xsd
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
include
targetNamespace=“http://example.com/salesns” xmlns=“http://example.com/salesns” elementFormDefault="qualified">
<xs:include schemaLocation=“employee.xsd"/>
<xs:include schemaLocation=“customer.xsd"/>
<xs:element name=“Sales">
<xs:complexType>
<xs:sequence>
<xs:element name=“Customer" type=“CustomerType" />
<xs:element name=“SalesPerson" type=“EmployeeType” />
<xs:element name=“SalesAmount” type=“xs:integer” />
</xs:sequence>
</xs:complexType>
</xs:element>
29
© 2007 IBM Corporation
</xs:schema>
ビジネス・ユニットの名前
IBM Information Management software
解説：

上の例ではemployee.xsd, customer.xsdには、
TargetNamespace宣言がありません。このようなスキーマはカ
メレオンスキーマと呼ばれます。

このようなスキーマは、includeして利用します。includeされると、
カメレオンスキーマ内で宣言されていた名前は、includeしたス
キーマのTargetNamespaceに属するものとして扱われるように
なります。

カメレオンスキーマ内で宣言されていた名前と、includeする側
のスキーマ内で宣言されている名前は衝突しないようにする必
要があります。

このスキーマに基づくXMLインスタンスは右のようになります。

名前空間接頭辞がないので、元々どのxsdで
宣言されていたかはわかりません。

XML Schemaでは、TargetNamespace宣言を
行うのが原則です。カメレオンスキーマを使用する
のは、多数のスキーマで使用する共通部品を
分けて宣言したい場合などのケースになります。

カメレオンスキーマでは、include前と、include後で構成要素の
名前空間が異なるため、名前を指定する場合に間違いが生じ
やすくなることがあり使用には注意が必要です。
–
<?xml version="1.0"?>
<Sales xmlns=“example.com/salesns“
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://example.com/salesns Sales.xsd">
<Customer>
<CustomerName>猫山商事</CustomerName>
<CustomerID>12345</CustomerID>
</Customer>
<SalesPerson>
参考：W3C XML Schema Design Patterns:
Avoiding Complexity by Dare Obasanjo [2-6]
<Name>夏目金之助</Name>
http://www.xml.com/pub/a/2002/11/20/schemas.html
<ID>45678</ID>
</SalesPerson>
<SalesAmount>56</SalesAmount>
</Sales>
30
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
C. XMLインスタンスの設計 - XMLインスタンス単位の検討

XMLインスタンスの範囲を決定する
最終的な決定は、物理設計
–

範囲決定の方針
業務的にまとめて扱う範囲をXMLインスタンス範囲とする
–
•
–

とくに発生/消滅時期の違うものについては、インスタンスを分ける
自然な階層構造を持つもの、依存関係があるものは一つのXMLの範囲
業務内容、エンティティのライフサイクル把握のためにCRUD分析の利用も可能
input: ユースケース、分析クラス図
–
このフェーズでのCRUDでは、クラス単位、ユースケースの「処理」単位の粒度
•
C
出展
C
発注明細
ユースケース#1
C
C
同上
R
C
発注
R
注文する
取引先を登録する
倉庫
R
仕入先
R
売上明細
注文を受ける
C
売上
C
商品
R
見積明細
見積
顧客
代行者
電話
住所
取引先
クラス
処理
見積もりを提示する
R
C
C
ユースケース#2
C
商品を登録する
C
© 2007 IBM Corporation
31
ビジネス・ユニットの名前
IBM Information Management software
解説：
32

XMLインスタンスの設計として、まず、XMLインスタンスの範囲を決定します。

この段階では、論理的にどの範囲が同一インスタンスにするのに適しているかを検討し、最終的にDBに格納する文書単位
の決定は、XMLDB物理設計でパフォーマンス、DB2特性、非正規化の必要性等を考慮して決定します。

この段階での、検討は最終のXMLDB物理設計時ほどDB2特性を意識しませんが、交換用のデータの設計と、格納用の
データの設計は異なる場合があります。
– 交換用データでは、交換されるデータのまとまりの中で必要な情報が網羅されている必要があり、文書内で参照さ
れているデータは、単なる参照ではなく、実際に内容を含んだものにするのが適切であると考えられます。
– 格納用データでは、これに対して、データが継続的に存在する場合の、データ変更に伴う整合性の確保が重要と
なります。そのため、業務的にまとめて扱う範囲をXMLインスタンス範囲とし、そのライフサイクルに注目して、発
生/消滅時期の違うものについては、インスタンスを分ける、変更のあるものは、参照にとどめ、実際のデータを取
り込まないといった工夫が必要となります。
ただし、格納用データにおいても、画面処理や帳票のイメージなどで、あるデータをまとめて扱いたい要件がある
場合、交換用データをそのまま保存したい場合などは要件を考慮してXMLインスタンスの範囲を決定します。
たとえば、見積書などをXMLインスタンスとして保存する場合、顧客情報は顧客マスターに別に保管しているのだ
けれども、見積書にも、帳票イメージとして顧客名、電話番号、住所などを持ちたいというケースが考えられます。
このようなデータは、マスターデータとは別の履歴的側面を持っています。正規化されたマスター参照ではない要
件がある場合には、論理モデルも含めて見直しを行います。

自然な階層構造を持つもの、依存関係があるものは一つのXMLの範囲とするのが一般的です。（参照：「関連の表現-依
存」）

業務内容、エンティティのライフサイクル把握のためには、CRUD分析を行うことも考えられます。このフェーズでのCRUD
では、クラスまたは論理設計レベルのエンティティ単位、ユースケースの「処理」単位の粒度で十分であり、インプットとして
は、UMLのユースケース、分析クラス図のクラスを用いることができるでしょう。論理設計段階でCRUDを行っていれば、こ
れを利用する方法もあります。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
C. XMLインスタンスの設計 - ルート要素の検討
XMLインスタンス範囲に複数のルート候補がある場合
– 業務処理要件を検討
• 次ステップ(ID検討)と関連
Kokyaku
MitsumoriMeisai
Mitsumori
id
MitsumoriNo
name
MitsumoriHizuke
ShouhinNo
1
*
MitsumoriKingaku
MitsumoriGoukei
?
33
MitsumoriSuryo
?
<Kokyaku>
<Mitsumori>
<id>C0001</id>
<name>猫山商事</name>
<Mitsumori>
<MitsumoriNo>M1234</MitsumoriNo>
<MitsumoriHizuke>2007-01-10</MitsumoriHizuke>
<MitsumoriGoukei>28000</MitsumoriGoukei>
<MitsumoriMeisai>
<ShouhinNo>S9852</ShouhinNo>
:
</MitsumoriMeisai>
</Mitsumori>
</Kokyaku>
<MitsumoriNo>M1234</MitsumotiNo>
<MitsumoriHizuke>2007-01-10</MitsumoriHizuke>
<MitsumoriGoukei>28000</MitsumoriGoukei>
<Kokyaku>
<id>C0001</id>
<name>森林太郎</name>
</Kokyaku>
<MitsumoriMeisai>
<ShouhinNo>S9852</ShouhinNo>
:
</MitsumoriMeisai>
</Mitsumori>
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説：
34

XMLインスタンスの範囲を決定したら、ルート要素を決定します。

XMLインスタンスの範囲でルート要素になりうる候補が複数ある場合、業務要件を考慮してルート要素を決定します。たと
えば、見積を管理する場合、通常個々の見積を管理し、顧客の検索は必要に応じて行うのか、顧客単位に見積を管理する
ことが多いのか、などです。

何をルート要素とするかで、次ステップのインスタンスIDも異なります。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
C. XMLインスタンスの設計 - インスタンスIDの検討
インスタンスID（アイデンティファイア）とは
– インスタンスを一意に特定する座標の役割を果たす
– インスタンスをユニークに識別する上で、具体的にとりうる値リストを検討し、適切なも
のを選択する
• 例：
– 関連ID（リレーショナルの場合の外部キー）として異なるエンティティで使用される上で、適切
であるもの選択する
– 候補キーの中で、今後、値の変更の可能性が低く、ユニークであることが保証されているも
のを選択する
– システムによりオブジェクトに自動的に埋め込まれるIDやOIDの利用は避ける
– データとしてのアイデンティファイアは、業務コードから独立してアサインすることも考慮する
– インスタンスIDのXML上での表現方法
• 決められた表現はないが、ルート要素の属性を利用するとわかりやすい
<Customer cid=“100”>
<Name>…</Name>
<Address>…</Address>
….
</Customer>
CustomerというXMLインスタンスの
IDキーを、ルート要素(Customer)の属性
としている例
© 2007 IBM Corporation
35
ビジネス・ユニットの名前
IBM Information Management software
解説：

ID（アイデンティファイア）とは
– インスタンスのエントリーを識別するキーであり、リレーショナルデータモデルの主キー項目に相当します。

ID（アイデンティファイア）の定義
– インスタンスを一意に特定する座標の役割を果たす
– インスタンス内におけるインスタンスのライフサイクルを表現する

ID（アイデンティファイア）の選択基準
– インスタンスをユニークに識別する上で、具体的にとりうる値リストを検討し、適切であるか。
– 外部キーとして異なるインスタンスで使用される上で、適切であるか。
– 候補キー中で、今後、値の変更の可能性が低く、ユニークであることが保証されているか。
– システムによるオブジェクトに自動的に埋め込まれるIDやOIDの利用は避ける。
• バックアップのために、データをExport/Importするとデータが変わってしまうようなID属性は選択しない。
– データとしてのID（アイデンティファイア）は、業務コード体系やコード値から独立してアサインすることがのぞましい。
• 業務コード体系や業務コード値は、ビジネスの変更に伴い、洗い換えの可能性がある。
• データエントリの論理削除の対応の必要性を検討する。ある業務上のステータスとしては無効だが、将来の業務機会
を拡張するために、データのエントリを有効活用したい場合がある。この場合、データとしてのライフサイクルは、ある
業務上でのデータライフサイクルより長い。
– リレーショナルモデルの場合と同様に、代理キー（Surrogate key）の導入を検討する。
• 代理キー（Surrogate Key)とは、ビジネス固有のコード体系やコード値とは異なり、インスタンス上でのエントリの管理
番号として使用し、データのユニーク性を保障する目的で使用するキーのことである。
• 主キーが複数項目からなる場合は、キー自身が長くなることと、データアクセスが複雑になることを考慮し、代理キー
の使用を考慮する。
– 多くの場合、代理キーをPrimary keyとして使用する一方で、実際のビジネスプロセスで使用する、Primary
Keyの候補であるその業務で使用する業務コードである管理番号を並存させている。
– この場合は、代理キーは、実際の業務プロセスでは直接使用されないが、データ管理の番号として使用される。
XMLインスタンスIDを、XML上キーとして表現する方法を考えます。XMLのIDキーの付与方法に決まりはありませんが、ルート要素
の属性として保持するとわかりやすいといえます。
– XMLスキーマ記述として、ID型、key、uniqueなどがありますが、これらはXMLインスタンス内のユニーク性を表現するもので
あり、当ガイドでIDと呼んでいる、XMLインスタンス自身を特定するための識別子とは異なります。

36
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
参考：コンポーネントのIDキーの表現方法(1)
同一XMLインスタンス内で複数出現する要素に一意のキーをつける
– <xs:unique>
•
•
•
<xs:selector xpath”パス”>で一意性を持つコンポーネントの範囲を指定
<xs:field xpath=“パス”>でキーを指定
例：顧客一覧を文書にするとき、顧客ごとにユニークなキーを振りたい
XMLインスタンス
<CustomerList >
<Customer cid="0001“>
<Name>夏目商事</Name>
<Address>東京都文京区</Address>
</Customer>
<Customer cid="0002">
<Name>福沢運輸</Name>
<Address>東京都港区</Address>
</Customer>
:
</CustomerList>
XMLスキーマ
<xs:complexType name="CustomerType">
<xs:sequence>
<xs:element name="Name" type="xs:string"/>
<xs:element name="Address" type="xs:string"/>
</xs:sequence>
<xs:attribute name="cid" type="xs:integer"/>
</xs:complexType>
<xs:element name="CustomerList">
<xs:complexType>
<xs:sequence>
<xs:element name="Customer" type="CustomerType"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:unique name="CustomerID">
<xs:selector xpath="Customer"/>
<xs:field xpath="@cid"/>
</xs:unique>
</xs:element>
© 2007 IBM Corporation
37
ビジネス・ユニットの名前
IBM Information Management software
参考：コンポーネントのIDキーの表現方法(2)
<xs:key>
– <xs:unique>と類似の定義方法
– <xs:keyref>と組み合わせて、
文書内での参照を表現できる
•
<xs:ID>, <xs:IDREF>でもIDおよび参照の
表現は可能だが、XML Schemaにおいては、
<xs:key>, <xs:keyref>が推奨
– 例：売り上げのリストを作成するが、
売り上げ対象顧客は、顧客リスト(CustomerList)に
登録されている必要がある
XMLインスタンス
<CustomerList >
<Customer cid="0001">
<Name>夏目商事</Name>
<Address>東京都文京区</Address>
</Customer>
<Customer cid="0002">
<Name>福沢運輸</Name>
<Address>東京都港区</Address>
</Customer>
</CustomerList>
<Sales>
<SalesDate>2007-07-01</SalesDate>
<SalesCustomer>0001</SalesCustomer>
<SalesAmount>210000</SalesAmount>
38
<Sales>
XMLスキーマ
<xs:element name="CustomerList">
<xs:complexType>
<xs:sequence>
<xs:element name=“Customer” type=“CustomerType”
maxOccurs="unbounded"/>
<!– CustomerTYpe定義は、前頁のもの -->
</xs:sequence>
</xs:complexType> <xs:sequence>
<xs:key name="CustomerID">
<xs:selector xpath="Customer"/>
<xs:field xpath="@cid"/>
</xs:key>
</xs:element>
<xs:complexType name=“SalesType”>
<xs:sequence>
<xs:element name="SalesDate" type="xs:date"/>
<xs:element name="SalesCustomer" type="xs:string"/>
<xs:element name="SalesAmount" type="xs:integer"/>
</xs:sequence>
</xs:complexType>
<xs:element name="Sales“ type=“SalesType”>
<xs:keyref name="SalesCustomerRef" refer="CustomerID">
<xs:selector xpath="Sales"/>
<xs:field xpath="SalesCustomer"/>
</xs:keyref>
</xs:element>
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
D. XMLスキーマの記述方針決定 - XMLスキーマの記述パターン
XMLスキーマ記述パターンを使用する利点
– 見易さ、分かり易さの向上
– 再利用のルール化
XMLスキーマ記述パターン
名称
要素
型(単純型、長所
複合型)
入れ子型
ルートのみ
グローバル
ローカル
(Russian Doll
短所
読みやすい(ルートが1つ)
一部分の再利用、参照はできない
定義が単純
スキーマ文書ファイルを分割できない
XMLインスタンス構造が複雑になると、
構造一見して把握しづらくなる
=マトリョーシカ)
グローバル要素型
(Salami Slice)
グローバルタイプ型
(Venetian Blind)
完全グローバル型
(Garden of Eden)
すべての要
素がグロー
バル
ローカル
ルートのみ
グローバル
グローバル
すべての要
素がグロー
バル
グローバル
要素が再利用できる
ルート要素がわかりにくい
複数スキーマ文書ファイルへの分割が可能
型のカストマイズには対応できない
型の再利用、カストマイズが可能
入れ子型より、定義が冗長
複数スキーマ文書ファイルに分割可能
再利用は、要素ではなく型
型、要素の再利用が可能
定義が冗長で読みづらい
複数スキーマ文書に分割可能
ルート要素がわかりにくい
*: グローバル、ローカル宣言については、「参考：グローバル宣言とローカル宣言」を参照。
また、型については、「F. XMLスキーマの詳細設計 - 型と構造の定義」参照。
© 2007 IBM Corporation
39
ビジネス・ユニットの名前
IBM Information Management software
解説：

XMLスキーマ文書を作成する際には、どのような記述パターンを用いるか決定しておくことをおすすめします。XMLスキー
マ記述パターンは、スキーマ文書の書き方のスタイルを示します。スキーマ文書を作成する上で、記述パターンに従うこと
は必須ではありませんが、パターンにしたがって開発すると、スキーマの見易さ、分かり易さが向上します。また、スキーマ
記述パターンは、一定の再利用ルールを設けることにつながります。

XMLスキーマを構成する要素（element)と型(simpleType, complexType)をグローバル、ローカルにどのように宣言するか
に基づき、いくつかの記述パターンが提案されています。グローバル、ローカル宣言については、「参考：グローバル宣言と
ローカル宣言」,また、型については「F. XMLスキーマの詳細設計 - 型と構造の定義」も参照してください。

40
–
グローバル宣言とは、xs:schemaの直下にコンポーネントを宣言することです。このようなコンポーネントは、同一
スキーマ文書内、および、そのスキーマ文書をimport/includeして使用する他のスキーマ文書から参照することが
できます。
–
ローカル宣言とは、コンポーネント宣言をxs:schemaの直接の子要素ではない場所(たとえば、他のcomplexType
の中)で行うことです。このようなコンポーネントは、他から参照することはできません。
主なXMLスキーマ記述パターンは上の表のとおりです。
–
日本語名称は、宣言の方法を示すように今回のガイドで付けています。
–
英語名称のうち、Russian Doll, Salami Slice, Venetian Blindは、 Roger L. Costelloにより”XML Best Practice”
(http://www.xfront.com/BestPracticesHomepage.html)[2-7]により提案されたものであり、Garden of Edenは、
その後Eve Malerにより追加されました。(http://www.idealliance.org/papers/xml02/dx_xml02/papers/05-0102/05-01-02.html#schema-style)[2-8]
–
以下のページで、各記述パターンの例を示して説明しています。これらのスキーマの例は、Introducing Design
Patterns in XML Schemas by Ayub Khan and Marina Sum
(http://developers.sun.com/jsenterprise/nb_enterprise_pack/reference/techart/design_patterns.html)[2-9]か
ら引用しています。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
参考：入れ子型(Russian Doll)

<tns:Line xmlns:tns=“http://schemas.sun.com/point/russiandoll”
xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”
xsi:schemaLocation="http://schemas.sun.com/point/russiandoll">
例
<tns:PointA x=“0" y="0"/>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://schemas.sun.com/point/russiandoll"
</tns:Line>
xmlns:tns="http://schemas.sun.com/point/russiandoll"
elementFormDefault="qualified">
<xs:element name="Line">
<xs:complexType>
<xs:sequence>
<xs:element name="PointA">
<xs:complexType>
<xs:attribute name="x" type="xs:integer"/>
<xs:attribute name="y" type="xs:integer"/>
</xs:complexType>
</xs:element>
<xs:element name="PointB">
<xs:complexType>
<xs:attribute name="x" type="xs:integer"/>
<xs:attribute name="y" type="xs:integer"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
41
<tns:PointB x=“10" y=“20"/>
スキーマに対応するXMLインスタンス
•入れ子人形で知られるマトリョーシカのように、全ての要
素と型が一つの要素(ルート)の中に入れ子になった形で
定義されているようなスキーマ
・簡単
•ルートおよび対象文書の構造がはっきりわかる
・下位の要素がローカル宣言なので、スキーマを分割で
きず、他のスキーマから要素、型の再利用もできない
•XMLインスタンスが大きくなってくると、全体像が見えに
くい
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
参考：グローバル要素型(Salami Slice)

例
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://schemas.sun.com/point/salami"
xmlns:tns="http://schemas.sun.com/point/salami"
xmlns=“http://schemas.sun.com/point/salami” elementFormDefault="qualified">
<xs:element name="PointA">
<xs:complexType>
<xs:attribute name="x" type="xs:integer"/>
<xs:attribute name="y" type="xs:integer"/>
•すべての要素がグローバルに定義されているスキーマ
</xs:complexType>
•要素を並列に提示する
</xs:element>
•グローバルに宣言された要素は、refで参照する
<xs:element name="PointB">
<xs:complexType>
・要素単位に再利用できる
<xs:attribute name="x" type="xs:integer"/>
<xs:attribute name="y" type="xs:integer"/>
・XMLインスタンス文書のルートが何になるかわかりにくい
</xs:complexType>
・XMLインスタンスは、前頁と同様になる
</xs:element>
<xs:element name="Line">
<xs:complexType>
<xs:sequence>
<xs:element ref="PointA"/>
<xs:element ref="PointB"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
42
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
参考：グローバルタイプ型 (Venetian Blind)

例
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://schemas.sun.com/point/venetianblind"
xmlns:tns="http://schemas.sun.com/point/venetianblind"
xmlns="http://schemas.sun.com/point/venetianblind"
elementFormDefault="qualified">
<xs:complexType name="PointType">
<xs:attribute name="x" type="xs:integer"/>
<xs:attribute name="y" type="xs:integer"/>
</xs:complexType>
<xs:element name="Line">
<xs:complexType>
<xs:sequence>
<xs:element name="PointA" type="PointType"/>
<xs:element name="PointB" type="PointType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
•型をグローバルに宣言する
•グローバル要素はルートのみで、子要素はルー
トの下に階層構造で定義される
•要素の型として、グローバルに宣言した型を使
用する
•同じ型を持つ要素が複数ある場合は、定義を共
通化できる
•再利用するとき、再利用側で型をカストマイズで
きる
•要素そのものは再利用できない
•型宣言を伴う、入れ子型
© 2007 IBM Corporation
43
ビジネス・ユニットの名前
IBM Information Management software
参考：完全グローバル型 (Garden of Eden)

例
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://schemas.sun.com/point/gardenofeden"
xmlns="http://schemas.sun.com/point/gardenofeden"
elementFormDefault="qualified">
<xs:complexType name="PointType">
<xs:attribute name="x" type="xs:integer"/>
<xs:attribute name="y" type="xs:integer"/>
</xs:complexType>
<xs:complexType name="LineType">
<xs:sequence>
<xs:element ref="PointA"/>
<xs:element ref="PointB"/>
</xs:sequence>
</xs:complexType>
•すべての要素と型をグローバルに定義
•まず型を宣言し、その型を使用する要素を
宣言する
•要素、型の再利用が可能
•定義が複雑
•どれがルートかわかりずらい
<xs:element name="PointA" type="PointType"/>
<xs:element name="PointB" type="PointType"/>
<xs:element name="Line" type="LineType"/>
</xs:schema>
44
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
D. XMLスキーマの記述方針決定 – XMLスキーマ記述パターン選択のポイント
再利用性か、簡便さか
– 用途によって使いわけ
– 入れ子型(Russian Doll)
• 複雑さを避け、スキーマを小さくまとめたい
– グローバル要素型(Salami Slice)
• 要素の再利用を行いたい
• 要素の一覧を示したい
– グローバルタイプ型(Venetian Blind)
• 型をカストマイズしたい
• 同じ型または似た型の要素が複数存在し、定義の共通化を図りたい
– 完全グローバル型(Garden of Eden)
再利用性、カストマイズ可能性を最大限にしたい
•
グローバル宣言記法のヒント
– グローバル宣言と参照を行うとルートを基点とする木構造がわかりにくくなるが、書法をルール化すると読み解きやすくなる
•
例：
– ネストの内側の要素から、外の要素へ順に宣言していく
– ネーミングルールとして、型の名前には、使用している要素名+Typeとつける
>
<xs:element name="Line" type="LineType"/>
© 2007 IBM Corporation
45
ビジネス・ユニットの名前
IBM Information Management software
解説：
46

XMLスキーマ記述パターンに何を採用したらよいかは、XMLスキーマの利用に当たって何に重点を置くのかによって異な
ります。再利用するのか、簡便さを重視するのか、用途によって使いわけることが考えられます。上のページは、それぞれ
のパターンを採用する動機をリストしています。

入れ子型(Russian Doll)以外のXMLスキーマ記述パターンでは、型や要素のグローバル宣言が行われます。グローバル
宣言を行った型や要素を、参照していくと、スキーマの木構造がわかりにくくります。このような場合に、書法をルール化す
ると読み解きやすくなります。
–
例としては、前のページのスキーマ例にもあるように、ネストの内側の要素や型から先に宣言し、これらを参照する
型や要素の宣言を後で行うことがあげられます。なるべく小構造から定義していき、最後に最も大きなルート構造
を定義します。
–
ネーミングルールとして、型の名前には、使用している要素名+Typeとつけるようにすると要素と型が見分けられ、
スキーマが見やすくなります。
• 注：名前空間で、型と要素は別々に扱われるため、同一名をつけることは可能です。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
参考: グローバル宣言とローカル宣言

型の名前
– 名前付き型 (named type)： <xs:simpleType>, <xs:complexType>のname属性で名前を指定
• 要素や属性の型として使用できる
<顧客 cid=“1”>
• 宣言例：上で宣言した”顧客タイプ”を使用する
<名前>樋口工作所</名前>
顧客タイプで宣言されている子要素、属性を持つ要素が宣言できる
<住所>東京都千代田区</住所>
<xs:element name=“顧客” type=“顧客タイプ>
</顧客>
– 匿名型(anonymous type): 要素、属性宣言の直後など特定の場所で宣言する場合、名前の省略可能
• 他の要素や属性からは使用できない

型の宣言
– グローバル
• <xs:schema>直下に宣言
• 他から参照できる
– ローカル
• 他の要素や属性の下に宣言
• 他から参照できない
型のカストマイズ
– 他の型を利用して新たな型を宣言可能
• オブジェクト指向の継承の考え方と類似
• 単純型のカストマイズは「派生型の宣言」を参照
• 複合型のカストマイズについては、「継承のXML Schema表記」を参照
© 2007 IBM Corporation
47
ビジネス・ユニットの名前
IBM Information Management software
参考: 要素と型の再利用
48

要素も型もグローバルに宣言されているものは再利用できる
– 要素の再利用
– 型の再利用

要素の再利用
– その要素を別の場所で参照するとき
– その要素を参照する箇所が少ないとき
– 型の拡張を必要としないとき

型の再利用
– 複数の要素で同一の型を使用したいとき
– 型のカストマイズを行いたいとき
• 「F. XMLスキーマの詳細設計 - 型と構造の定義」参照
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
D. XMLスキーマの記述方針決定 – XMLスキーマ分割方針の決定
基本的には、XMLインスタンスに対して１つがわかりやすい
– メンテナンス性
複数XMLスキーマ文書を使用する場合
– 再利用
• 既存スキーマの一部を使用する
• 全体で使用するものと個別業務でしか使用しないものを分ける
• 他の業務で使用できる要素や型を切り出す
– 名前空間の考慮
• スキーマを分割する場合、名前空間も別のものにするのか
• 名前空間が異なるスキーマを使用する際にはimport
© 2007 IBM Corporation
49
ビジネス・ユニットの名前
IBM Information Management software
解説：

XMLスキーマの単位を決定します。

XMLスキーマは、基本的にはXMLインスタンスに対して１つがわかりやすいと思われます。更新等が発生する場合を考え
ても、スキーマ文書の管理がXMLインスタンスと同様の範囲で管理されている方が簡便でしょう。

複数XMLスキーマ文書を使用したいケースとしては、以下のようなものがあります。
–
再利用
•
•
•

50
既存スキーマの一部を使用する
全体で使用するものと個別業務でしか使用しないものを分ける
– この場合、全体で使用する部分は、他のスキーマからも使用されることになります。
他の業務で使用できる要素や型を切り出す
XMLスキーマ文書を分割する場合は、スキーマ文書と名前空間の対応づけを検討しておく必要があります。W3C XML
Schemaでは、「XML Schemaにおける名前空間の使用」でも記述したとおり、TargetNamespace宣言を行って、スキーマ
内で宣言されるコンポーネントが所属する名前空間を指定します。名前空間が異なるスキーマを再利用したい場合は、そ
のスキーマをimport, 名前空間が同じで異なるスキーマを使用する場合は、そのスキーマをincludeします。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
参考：共通使用部分の切り出し例

データ型の管理を統一して行いたいとき
– DataTypes.xsdなどのように、各スキーマが共通して使用する型宣言などを切り出し、1つにまとめておく
• 例
– 他の業務や、スキーマでも共通で使用するコンポーネントを別のXMLスキーマとして切り出す
– 金額、電話番号、郵便番号型などの社内標準が決まっており、すべてそれらの型名で指定したい
– 型宣言は、グローバルに行い、このスキーマをimport, includeするスキーマが利用できるようにする
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://sample/DataTypes"
xmlns=“http://sample/DataTypes” elementFormDefault="qualified">
<xs:simpleType name=“KingakuType">
<xs:restriction base="xs:integer">
<xs:minInclusive value="0" />
</xs:restriction>
</xs:simpleType>
<xs:simpleType name=“YubinBangoType”>
<xs:restriction base="xs:string">
<xs:pattern
value="[0-9]{3}-[0-9]{4}" />
</xs:restriction>
</xs:simpleType>
</xs:schema>
DataTypes.xsd例
© 2007 IBM Corporation
51
ビジネス・ユニットの名前
IBM Information Management software
ブランク・ページです。
52
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
E. XMLスキーマおよびXMLインスタンス・プロトタイプの作成
検討結果を元に以下の文書を生成
– XMLスキーマ(xsdファイル)
– XMLインスタンス(xmlファイル)
ツールの利用
– モデルからスキーマの生成
• UML → XML Schema
• 物理データモデル → XML Schema
– XMLインスタンス
←→
XML Schema
手書きによる作成
– XMLエディター
– XMLスキーマエディター
© 2007 IBM Corporation
53
ビジネス・ユニットの名前
IBM Information Management software
解説：

これまでのステップでの検討結果を元に、XMLスキーマ文書およびXMLインスタンス・ファイルのサンプルのプロトタイプを
作成します。

XMLスキーマ文書(xsdファイル)や、XMLインスタンス文書(xmlファイル)サンプルの作成方法としては、手書きでも可能で
すが、ツールを利用することが考えられます。
–
–

手書きによる作成
–

54
モデルからスキーマを生成するツール
• UML → W3C XML Schema
– Rational Software Architect (RSA)など、UMLモデルからXML Schemaを生成するツールがありま
す。
• 物理データモデル → W3C XML Schema
– Rational Data Architect (RDA)は、物理データモデルからXML Schemaを生成します。
• これらのツールが作成したスキーマを元に、XMLエディター、XMLスキーマエディターを使用して修正してい
きます。
XMLインスタンス文書から、それに適合するXML Schemaを作成する、またはXML SchemaからXMLインスタン
ス文書を作成するツールもあります。インスタンスや、スキーマのサイズが小さいときは、このような方法でも十分
対応できます。
これらのツールを使用しない場合は、XMLエディターやXMLスキーマエディターを使用して手書きすることも考えら
れます。
スキーマバージョンの割り振り
–
XMLスキーマは検討の結果変わっていきます。また運用開始後も要件によって変化する可能性があります。
–
XMLインスタンスルートなどに、version情報を持たせるようにするとわかりやすくなります。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
F. XMLスキーマの詳細設計 - 型と構造の定義
XML Schemaでは要素や属性は型(type)を持つ
単純型 (simpleType)
– 子要素、属性を持たない
– 要素の型としても、属性の型としても使用可能
• 宣言例：
<xs:simpleType name=“顧客名” type=“xs:string”/>
複合型 (complexType)
– 子要素、属性を持てる
– 要素の型として使用できるが、属性の型としては使用できない
• 宣言例：
<xs:complexType name=“顧客タイプ">
<xs:sequence>
<xs:element name=“名前" type="xs:string"/>
<xs:element name=“住所" type="xs:string"/>
</xs:sequence>
<xs:attribute name="cid" type="xs:integer"/>
</xs:complexType>
© 2007 IBM Corporation
55
ビジネス・ユニットの名前
IBM Information Management software
解説：

XML Schemaでは要素や属性は型(type)を持つ
– 型には単純型(simpleType)と複合型(complexType)があり、宣言して使用します。

単純型 (simpleType)
– 子要素、属性を持ちません。
– 要素の型としても、属性の型としても使用可能です。
• 宣言例：
<xs:simpleType name=“顧客名” type=“xs:string”/>
– 単純型の基礎となるデータ型として、後述のW3C XML Schema ビルトイン型を使用できます。
• ビルトイン型では表現できない長さや、入力値の制約をつけたい場合には、後述の派生型を宣言します。
複合型 (complexType)
– 子要素、属性を持てます。
– 要素の型として使用できるが、属性の型としては使用できません。（属性は構造を持たないため）
• 宣言例：
<xs:complexType name=“顧客タイプ">
<xs:sequence>
<xs:element name=“名前" type="xs:string"/>
<xs:element name=“住所" type="xs:string"/>
</xs:sequence>
<xs:attribute name="cid" type="xs:integer"/>
</xs:complexType>

56
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
F. XMLスキーマの詳細設計 - データ型の検討 (単純型)
右がXML Schemaでの
データ型のダイアグラム
– 上の囲み：プリミティブ型
– 下の囲み：派生型
– ビルトイン派生型は「制約」及
び「リスト」を用いて定義
ビルトイン・プリミティブ型
ビルトイン・派生型
© 2007 IBM Corporation
57
ビジネス・ユニットの名前
IBM Information Management software
解説

要件に応じて適切なデータ型を選択します。

W3C XML Schemaにおけるデータ型
– 前ページのダイアグラムは、W3C XML Schemaで定義されたビルトイン型を示しています。
– ビルトイン型はプリミティブ型と派生型に分けることが出来ます。
•
•
XML Schemaではプリミティブ型として19種、派生型として25種のデータ型を提供しています。
提供されているビルトイン型を元に、ユーザー独自の派生型を定義することが可能です。
– 派生型の定義については、次項「ユーザー定義型の宣言」を参照してください。
– 提供されているデータ型の定義についてはW3CのXMLスキーマ規約[2-2]を参照してください。

58
W3C XML Schemaのビルトイン型で表現できない要件については、派生型を宣言することができます。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
F. XMLスキーマの詳細設計 - 派生型の宣言
「制約（restriction）」を使用した派生型の定義について
– simpleType宣言を用いて、ベースとなる既存の型を元に新たな派生型を宣言し、1つもしくはそ
れ以上の「ファセット(facet)」を付加して取り得る値を制限することが可能
– 「ファセット」によって付加できる制約（括弧内はファセット名）
値の長さ
：固定長（length）、最小長（minLength）、最大長（maxLength）
字句の制約（正規表現）
：パターン（pattern）
取り得る値の候補
：列挙（enumeration）
値中のwhiteSpaceの取り扱い
：空白値（whiteSpace）
そのまま保持(preserve)、半角スペースに変換(replace)、
replace操作後に連続した#x20を1個の#x20に変換（collapse)
• 数値の範囲を制限
：以下（maxInclusive)、より小さい（maxExclusive)、以上(minInclusive)、
より大きい（minExclusive）、桁数の最大値（totalDigits)、
小数部の桁数の最大値（fractionDigits)
•
•
•
•
• ベースとなる型によって使用できるファセットが異なる
– ベース型ごとに適用可能なファセットのリストは、W3CのXML Schema仕様[2-2]を参照
© 2007 IBM Corporation
59
ビジネス・ユニットの名前
IBM Information Management software
解説

新たな派生型の宣言例
– ファセットとして、最小値（以上）を定義する「minInclusive」、最大値（以下）を定義する「maxInclusive」を使用
•
範囲を1-99に制限した整数型「MyInteger」の宣言例
<xs:simpleType name="MyInteger">
<xs:restriction base="xs:integer">
<xs:minInclusive value="1"/>
<xs:maxInclusive value="99"/>
</xs:restriction>
</xs:simpleType>
– RDBの型とXMLスキーマのデータ型を比較した場合、多くの場合XMLデータ型の方が制限が緩やかです。
•
•
そのため、RDBの型に厳密に対応させる必要がある場合、制約を付加して値の範囲を限定する必要があります。
DB2のDecimal型にあわせて最大桁数、小数点以下最大桁数を31桁に制限した派生型の宣言例
<xs:simpleType name="DECIMAL">
<xs:restriction base="xs:decimal">
<xs:totalDigits value="31"/>
<xs:fractionDigits value="31"/>
</xs:restriction>
</xs:simpleType>
60
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
F. XMLスキーマの詳細設計 – 複合型での構造
complexTypeで規定できる構造
– sequence
• 要素の出現順序に制約を加える
– 論文のように見出し・本文の順序があるとき
– 表示順序を決めたいとき
XMLスキーマ
XMLインスタンス
<xs:sequence>
<xs:element name=“A” />
<xs:element name=“B" />
<xs:element name=“C" />
</xs:sequence>
<A/>
<B/>
<C/>
A,B,Cと
いう順番
を守る
<xs:all>
<xs:element name=“A” />
<xs:element name=“B" />
<xs:element name=“C" />
</xs:all>
<B/>
<C/>
<A/>
A,B,Cが
順不同
で出現
<B/>
AかBが
出現
– all
• 要素の順不同に出現させる
– 各要素を必ず出現させたいとき
– choice
• いくつかの要素があり、いずれかを出現させる
– 文書の構造で、旧バージョンと新バージョンの
どちらかを選ぶとき
– 意味として同じような要素
<xs:choice>
（顧客名か顧客番号）を選択するとき
<xs:element name=“A" />
<xs:element name=“B” />
</xs:choice>
© 2007 IBM Corporation
61
ビジネス・ユニットの名前
IBM Information Management software
解説：

XMLスキーマの複合型（complexType）では、リレーショナル・データと異なり、要素の出現順序などを規定できます。

ここでは、complexTypeでの構造を規定するsequence,all,choiceについて説明します。

sequence
– XMLスキーマのsequence要素は、その配下にある子要素や構造が順序どおりに登場することを意味します。
• 文書構造のように、‘見出し’の後に、‘本文’が登場するという順序のきまりがあるときに利用できます。
• 顧客情報画面において、‘顧客番号’,’顧客名‘,’担当者’・・・、など登場する順序をきめたいときに利用でき
ます。
– sequence配下の要素に、mixOccursやmaxOccursを指定することもできますし、sequence自身にminOccursや
maxOccursを指定してsequence全体の出現回数を指定することもできます。

all
–
–
62
XMLスキーマのall要素は、その配下にある子要素や構造が順不同で登場することを意味します。
応用的に、all自身にminOccurs=“0” maxOccurs=“1”を指定して、‘子要素が全く登場しない‘または’子要素がす
べて一回登場する’、というように決めることもできます。

choice
– XMLスキーマのchoice要素は、その配下にある要素や構造のうち、いずれかが登場することを意味します。
• 文書構造に複数のバージョンがある場合に、‘構造V１‘か‘構造V2’かを選択するときに利用できます。
– いずれか一つを選択する場合に多く用いられますが、応用的に、choice自身にminOccursやmaxOccursを指定し
て配下の要素や構造が任意の組み合わせで登場することを表現する場合にも利用できます。

データ・メッセージの言語を日本語、英語、中国語から選択するような場合は、出現順( sequence )と選択(choice)ではなく、
属性で言語を指定することが一般的です。
– <msg xml:lang=“ja-JP”>日本語メッセージ</msg>
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
F. XMLスキーマの詳細設計 - UMLクラス、エンティティの表現
UMLクラスや、論理データモデルのエンティティはXML Schemaの
complexTypeを持つ要素で表現
– クラス属性、エンティティのデータ項目はcomplexTypeの子要素または属
性
Customer
1. クラス,エンティティ属性をXML属性に
<Customer cid=“0001”
name=“山田太郎”
tel=“03-123-4567”
fax=“03-123-4567” />
cid
name
tel
fax
2. クラス属性をクラスの子要素、クラス属性の値をその要素の値に
<Customer>
<cid>0001</cid>
<name>山田太郎</name>
<tel>03-123-4567</tel>
<fax>03-123-4567</fax>
</Customer>
多くのツールでは、要素を使用。メタ情報などは属性化を検討。
「F. XMLスキーマの詳細設計 - 属性化の検討」参照
© 2007 IBM Corporation
63
ビジネス・ユニットの名前
IBM Information Management software
解説：

UMLクラスや、論理データモデルのエンティティは、XML SchemaではcomplexTypeを持つ要素として表現できます。

その時、クラス属性や、エンティティのデータ項目はcomplexTypeの子要素または属性として表現することができます。

多くのツールでは、クラス属性、データ項目をcomplexTypeの子要素としています。本書では、とりあえず、クラス属性、
データ項目をcomplexTypeの子要素とし、後で必要に応じて属性化を検討していく手順を採用しています。

上のページのCustomerを1のようにXMLで表現した場合、XML Schemaでは以下のように書くことができます。
<xs:element name="Customer“>
<xs:complexType>
<xs:attribute name="cid" type="xs:integer"/>
<xs:attribute name="tel" type="xs:string"/>
<xs:attribute name="name" type="xs:string"/>
<xs:attribute name="fax“ type="xs:string"/>
</xs:complexType>
</xs:element>

2のXML表現は、XML Schemaでは以下のように書くことができます。
<xs:element name="Customer">
<xs:complexType>
<xs:sequence>
<xs:element name="cid" type="xs:integer"/>
<xs:element name="name" type="xs:string"/>
<xs:element name="tel" type="xs:string"/>
<xs:element name="fax" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
64
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
F. XMLスキーマの詳細設計 - 関連の表記(1) 依存
依存関係は入れ子構造で表現
– 子クラスは、親クラスの子要素となる
– 多重度はminOccurs, maxOccursで表現
<見積>
<見積番号>12345220070701001</見積番
号>
<見積日付>2007-07-01</見積日付>
<見積合計金額>230000</見積合計金額>
<見積明細>
<商品番号>98765</商品番号>
<見積数量>3</見積数量>
<見積単価>680</見積単価>
</見積明細>
<見積明細>
<商品番号>92367</商品番号>
<見積数量>2</見積数量>
<見積単価>5640</見積単価>
</見積明細>
</見積>
見積
見積明細
見積番号
見積日付
見積合計金額
商品番号
明細を持つ 1..*
見積数量
見積単価
© 2007 IBM Corporation
65
ビジネス・ユニットの名前
IBM Information Management software
解説：

UMLクラスや、論理データモデルのエンティティ間の関連には依存的なものがあります。たとえば、見積明細は、見積がな
ければまったく存在しないものなので、見積に対して依存的な関係です。

依存関係は、XMLでは入れ子構造で表すことができます。

–
XML Schema上では、依存するクラス(子クラスは)、親クラスを表現するcomplexTypeの子要素として表現します。
–
子要素の多重度はmaxOccurs, minOccurs属性で指定できます。(デフォルトはminOccurs=“1”, maxOccurs=“1”、
「多重度と空要素の検討」参照）
上のページの見積-見積明細は、XML Schemaでは以下のように書くことができます(グローバル要素(Salami Slice)型)。
<xs:element name=“商品番号” type=“xs:string"/>
<xs:element name="見積数量" type="xs:integer"/>
<xs:element name="見積単価" type="xs:integer"/>
<xs:element name=“見積番号” type=“xs:string"/>
<xs:element name="見積日付" type="xs:date"/>
<xs:element name=“見積合計金額" type="xs:integer"/>
<xs:element name="見積明細">
<xs:complexType>
<xs:sequence>
<xs:element ref=“商品番号"/>
<xs:element ref="見積数量"/>
<xs:element ref="見積単価"/>
</xs:sequence>
</xs:complexType>
</xs:element>
66
<xs:element name="見積">
<xs:complexType>
<xs:sequence>
<xs:element ref="見積番号"/>
<xs:element ref=“見積日付"/>
<xs:element ref=“見積合計金額"/>
<xs:element minOccurs=“1” maxOccurs="unbounded" ref="見積明細"/>
</xs:sequence>
</xs:complexType>
</xs:element>
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
F. XMLスキーマの詳細設計 - 関連の表記(2) 非依存
一方が他方を参照する
– 同一XMLインスタンス内であれば, <xs:key>, <xs:keyref>を使用すると
わかりやすい
<見積>
<見積番号>1234</見積番号>
<見積日付>2007-07-01</見積日付>
<顧客番号>c0002<顧客番号>
</見積>
<顧客顧客番号=“c0002”>
<名前>森鴎外</名前>
</顧客>
見積
顧客
見積番号
見積日付
見積合計金額
顧客番号
参照する
名前
– 別文書の場合は参照しているコンポーネントのIDにあたるものを持たせる
•
•
XML Schema上整合性のチェックはできない
<xs:annotation>などを利用してコメントを記入しておく
© 2007 IBM Corporation
67
ビジネス・ユニットの名前
IBM Information Management software
解説：

一方が他方を参照する非依存の関係では、入れ子ではなく、一方が参照したい相手のIDを持つ形で示すことができます。
–
同一XMLインスタンス内の場合は、<xs:key>, <xs:keyref>が使用できます。
•
–
<xs:key>, <xs:keyref>の書き方については、「参考：コンポーネントのIDキーの表現方法(2)」を参照してく
ださい。
参照したい項目が同一インスタンスにない場合は、W3C XML Schemaの範囲ではスキーマ上で明示的な表現は
できないため、ここではコメントを付記して、参照関係を示すことをおすすめします。
•
68
この場合のコメント記述については、「関連IDの整理」をご覧ください。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
F. XMLスキーマの詳細設計 - 関連の表記(3) 汎化(継承)

取引先
汎化（継承）関係はいくつかの方法で表現可能
1. 親クラスを子クラスに取り込む
取引先番号
名称
<顧客>
<取引先>
<取引先番号>0001</取引先番号>
<名称>国際事務機</名称>
</取引先>
<与信限度>100</与信限度>
</顧客>
2. 親クラス属性を子クラス内に下方複写
<顧客>
<取引先番号>0001</取引先番号>
<名称>国際事務機</名称>
<与信限度>100</与信限度>
</顧客>
3. 子クラスを親クラスの種類と考える
<取引先 type=“顧客”>
<取引先番号>0001</取引先番号>
<名称>国際事務機</名称>
<.与信限度>A001</与信限度>
</取引先>
発注先
顧客
発注条件
与信限度
スーパークラスの構造を再利用
汎化関係をXMLインスタンス上で表現できる
サブクラス間の違いを意識したいとき
XMLスキーマでの継承関係の定義を行うと、このよう
な表記となる
クラスの共通属性が多いとき
サブクラス間の違いをあまり意識しないとき
© 2007 IBM Corporation
69
ビジネス・ユニットの名前
IBM Information Management software
解説：

汎化（継承）関係は、上ページのようにいくつかの方法で表現可能です。
–
この表現については、丸山則夫, 実践!!XMLのスキーマ設計ハンドブック, ソフト・リサーチ・センター, 2002,p.102104 [2-10]を参照しています。
1.
親クラスを子クラスに取り込む
2.
スーパークラスの構造を再利用し、スーパークラスを子クラスの要素として取り込み、子クラス独自の属性
を追加します。
親クラス属性を子クラス内に下方複写
3.
–
スーパークラスが持っていた属性は、子クラスの属性として表現されます。
子クラスを親クラスの種類と考える
–
子クラスを親クラスの種類と考え、親クラスの属性として子クラスタイプを表現します。親クラスを継承する
子クラス間で、属性の違いがほとんどない場合に使いやすい方法です。
1, 3では、継承関係をXMLインスタンスを見て判断できるというメリットがあります。
–
XML Schemaの仕組みとして継承を表現するのは2の方法です。
–
–
70
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
参考：継承のXML Schema表記
XML Schemaで継承を表現する仕組みとして複合型の拡張がある
複合型はabstract属性を持てる
<xs:complexType name=“取引先タイプ” abstract=“true”>
<xs:sequence>
<xs:element name="取引先番号" type="xs:string"/>
<xs:element name="名称" type="xs:string"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="顧客タイプ">
<xs:complexContent>
<xs:extension base="取引先タイプ">
<xs:sequence>
<xs:element name="与信限度" type="xs:integer"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
親クラス=ベースとなる型
ベース型を拡張
<xs:extension>して新しい要
素を付け加える
<xs:element name=“顧客” type=“顧客タイプ”/>
© 2007 IBM Corporation
71
ビジネス・ユニットの名前
IBM Information Management software
解説：

XML Schemaで継承を表現する仕組みとして複合型の拡張があります。
–
親クラスを表す複合型(取引先タイプ)を継承し、子クラスの属性を、子複合型(顧客タイプ)の追加要素として宣言
したのが、上のページの例です。
–
型を拡張する場合には、元になる型(上の例では、取引先タイプ）はグローバルに宣言されている必要があります。
–
顧客タイプを持つ顧客要素は、XMLインスタンスでは以下のようになります。
<顧客>
<取引先番号>0001</取引先番号>
<名称>国際事務機</名称>
<.与信限度>100</与信限度>
</顧客>

複合型はabstract属性を持つことができます。
例： <xs:complexType name="取引先タイプ" abstract="true">
–
72
abstract=“true”属性を持つ複合型は、オブジェクト指向の抽象クラスに相当し、
<xs:element name=“取引先” type=“取引先タイプ”/> のように、この型を直接使って要素を作成することは
できなくなります。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
F. XMLスキーマの詳細設計 - 関連IDの整理
XMLインスタンス間の関係をしめす関連IDを整理する
– ここでの関連IDとは、リレーショナルデータモデルの外部キーに相当する
– 別XMLインスタンスのIDキー項目を参照している項目（＝関連IDと呼ぶ）を洗い出す
– 関連IDであることと参照先のIDキー項目を、XMLスキーマ上のコメントとして記述しておく
– これにより、後続の属性化検討ステップや、索引検討ステップが行いやすくなる
<Estimate eid=“100”>
<Date>…</Date>
<Customer>
<CustomerID>
AA123456
</CustomerID>
見積XMLインスタンス
…
</Customer>
<Product> … </Product>
….
</Estimate>
見積XMLスキーマでのコメントの記述例
…
<xs:element name = “CustomerID” type=“xsd:string” >
<xs:annotation>
<xs:documentation>
顧客のIDキー(cid)を参照する関連ID
</xs:documentation>
</xs:annotation>
</xs:element>
73 ….
<Customer cid=“AA123456”>
<Name>…</Name>
….
</Customer>
顧客インスタンス
顧客XMLスキーマでのコメント
記述例
<xs:complexType>
…
<xs:attribute name = “cid” type=“xsd:string” >
<xs:annotation>
<xs:documentation>
見積もりXMLなどで参照される
</xs:documentation>
</xs:annotation>
</xs:attribute>
….
</xs:complexType>
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説：

74
「関連の表現(2) －非依存」で述べたように、他のインスタンスに存在するIDを参照したいケースがあります。
–
このような項目を、ここでは関連IDと呼んでいます。これは、リレーショナル・モデルにおける外部キーに相当しま
す。
–
XML Schemaでは、このような参照関係をスキーマ上明示したり、参照制約を強制することはできません。
–
しかしながら、インスタンス間の関係を洗い出し、どの項目間にどのような参照関係があるか整理しておくことは、
モデルの理解、データの管理、後続の属性化の検討ステップ、ハイブリッド列の設計、索引設計などに役立ちます。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
F. XMLスキーマの詳細設計 – 多重度と空要素の検討
要素の多重度（=出現回数）の検討
– 論理/物理データモデルでは、エンティティのn:n関係や属性（表の列）のnot null指定でしか表現できない
– XMLスキーマでは、要素の多重度をきめ細かく指定できる
• minOccurs：最低出現回数 (省略値は1)
• maxOccurs
：最高出現回数(省略値は1)
<xs:element
name=“A” minOccurs=“0”
maxOccurs=“1”>
<xs:element name=“B”
maxOccurs=“unbounded”>
<xs:element name=“C” minOccurs=“5”
maxOccurs=“10”>
<xs:element name=“D” >
・要素Aは、出現しなくてもよいが、
出現する場合は1回のみ
・要素Bは出現回数は無制限
・要素Cの出現回数は、5から10回
・要素Dの出現回数は1回
空要素の扱いの検討
– 子要素やテキストを持たない要素を、空要素（Empty Element)と呼ぶ
例）<samp></samp>、<samp/>、<samp flg=“true”/>
– 主に最後の例のように、属性のみを記述するケースが多い
– 何もテキストを「記述すべきではない」という制約は、XMLSchemaで空の<xsd:complexType>を記述す
ることで宣言可能
<xs:element name=“samp” >
<xs:complexType>
<xs:attribute name=“flg” type=“xs:boolean” default=“true”/>
</xs:complexType>
</xs:element>
© 2007 IBM Corporation
75
ビジネス・ユニットの名前
IBM Information Management software
解説：

76
XMLスキーマでは、要素毎の出現回数を、制約の一つである多重度として設定することができます。
– リレーショナル・データを主に想定している論理データモデルや物理データモデルでは、エンティティ間のn:n関係や、
列に対するnot null指定（NULL標識）で、多重度を表現しています。
– XMLスキーマでは、リレーショナル・データよりもきめ細かく、要素毎の出現回数を指定できます。従って、要素の出
現回数に対する業務要件を確認し、必要に応じて、XMLスキーマに反映させていく必要があります。
– W3C XML Schemaでは、minOccurs（最低出現回数）とmaxOccurs（最高出現回数）を用いて多重度を宣言します。
• minOccursとmaxOccursの宣言は必須ではなく、いずれかのみを宣言することも可能です。
• minOccurs, maxOccursともに省略値は”1”です。
続いて、空要素（くうようそ:Empty Element）の扱いを検討します。
– 子要素やテキストを持たない要素を、空要素と呼びます。例は上図の通りです。
• RDBのNullと、XMLインスタンスの空要素とは、機能の目的が異なります。RDBでは考えられないことですが、
XMLスキーマで宣言した要素を、XMLインスタンスで記述しないことも可能です。（minOccurs=“0”）
• よって、RDBのように値が無いことを表現するためにNULL標識を設定しなくても、要素を記述しない、もしくは
空要素を記述するという選択が可能です。
– 上図の例のように、XMLSchemaの空のcomplexType宣言によって、必ず空要素であるという制約を、妥当性検証
で確実にすることができます。
– XMLインスタンスでは、テキストが文字列で記述され、空要素を自由に記述できます。
• XML Schemaでデータ型がstringの場合、 <samp></samp>や<samp/>のようにテキストが空でも妥当性検
証エラーにはなりません。
• しかし、データ型が日付や数値の場合は、テキストが空の要素は、妥当性検証エラーとなります。
– このような場合に、要素の内容として空を許すためには、XML Schemaでnillable=“true“を宣言し、さ
らにXMLインスタンスの属性としてxsi:nil=“true”を追加記述することで、妥当性検証エラーを防ぐこと
が出来ます。
XML Schemaでの記述：<xs:element name=“samplong” type=“xs:long” nillable=“true“/>
XMLインスタンスでの記述：<samplong xsi:nill=“true”/>
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
F. XMLスキーマの詳細設計 - 属性化の検討

論理データモデルのエンティティをXML要素で定義 (①)
Customer
論理データモデルの属性を
– XML 子要素で定義 (②)
– XML 属性で定義(③)
ID
Name
Address
Telephone
主にXML属性が使用される例
– プライマリ・キー、ユニーク・キー、IDなどのキー
– バージョン情報、ステータス、プロパティ(言語、
URL、色、フォント、サイズなど)、要素(クラス)の
型などのメタ情報

要素でなければ表現できない特性もある
①
②
③
XML構造展開
<Customer ID=“1001”>
<Name>……</Name>
<Address>…………</Address>
<Telephone>
<Home>A</Home>
</Telephone>
</Customer>
© 2007 IBM Corporation
77
ビジネス・ユニットの名前
IBM Information Management software
解説：

論理データモデルからXMLスキーマを設計する際に、論理データモデルにおける属性を、XML要素で表現するか、
属性で表現するかを検討します。このフェーズでは業務やアプリケーションの観点から検討し、後のフェーズでパ
フォーマンス面や物理的な観点から検討することになります。

基本はXML要素で表現することを検討します。

以下のような場合は、属性を使用することがあります。
– XML属性が使用される例
• プライマリ・キー、ユニーク・キー、IDなどのキー
• バージョン情報、ステータス、プロパティ(言語、URL、色、フォント、サイズなど)、要素(クラス)の型などのメタ
情報
XML要素は属性よりも豊富な機能を持ちます。たとえば以下のような特性を持ちます。
– XML要素の特性(属性では不可能、または困難な特性)
• 子要素で階層を表現できる
• 順番付けができる
• 同じ種類の情報を列挙できる、同じ名称の要素を繰り返せる (属性の名称は要素内で一意となる)
• 要素の値の文字列に空白文字(タブ、キャリッジリターンなど)を含むことができる
• 値が長い文字列になる場合に表現がしやすい
• XMLを扱うツールでの編集がしやすい (属性を個別のプロパティ画面で編集しなければならないツールがあ
る)
要素、属性の選択にかかわらず、要件に合わせたクエリー生成が可能です。クエリーのサンプルを次のページに示
します。

エンティティの属性をXMLの属性、要素で定義した場合のクエリーの違い
– エンティティの属性追加時にクエリーの変更を最小限にしたいケース
Customer
Customer
ID
Name
Address
HomeTelephone
項目追加
ID
Name
Address
Home Telephone
Cellular Telepohone
電話番号要素のタイプを属性で定義した場合
元の顧客XML
<Customer ID=“1001”>
<Name>……</Name>
<Address>…………</Address>
<Telephone Type=“Home” >A</Telephone>
</Customer>
項目追加
<Customer ID=“1001”>
<Name>……</Name>
<Address>…………</Address>
<Telephone Type=“Home”>A</Telephone>
<Telephone Type=“Cellular ”>B</Telephone>
</Customer>
電話番号->顧客名検索元のXQuery
XQuery for $y in db2-fn:xmlcolumn
(‘表.列’)/Customer/Telephone[.=‘A’]
return $y/../Name
XQuery for $y in db2-fn:xmlcolumn
(‘表.列’)/Customer/Telephone[.=‘A’]
return $y/../Name
変更不要
両方のXMLに共通
© 2007 IBM Corporation
79
ビジネス・ユニットの名前
IBM Information Management software
参考: 属性、要素とクエリーの関係(2)

エンティティの属性をXMLの属性、要素で定義した場合のクエリーの違い
– エンティティの属性追加時にクエリーの変更を最小限にしたいケース
Customer
Customer
ID
Name
Address
Home Telephone
項目追加
ID
Name
Address
Home Telephone
Cellular Telepohone
電話番号要素のタイプを子要素で定義した場合
元の顧客XML
<Customer ID=“1001”>
<Name>……</Name>
<Address>…………</Address>
<Telephone>
<Home>A</Home>
</Telephone>
</Customer>
項目追加
<Customer ID=“1001”>
<Name>……</Name>
<Address>…………</Address>
<Telephone>
<Home>A</Home>
<Cellular >B</Cellular >
</Telephone>
</Customer>
電話番号->顧客名検索元のXQuery
XQuery for $y in db2-fn:xmlcolumn
(‘表.列’)/Customer/Telephone/*[.=‘A’]
return $y/../../Name
80
XQuery for $y in db2-fn:xmlcolumn
(‘表.列’)/Customer/Telephone/*[.=‘A’]
return $y/../../Name
変更不要
両方のXMLに共通
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
G. XMLスキーマとXMLインスタンス・サンプルの完成
XMLスキーマ設計ステップの最終成果物
– XMLスキーマ(xsdファイル)
– XMLインスタンスのサンプル(xmlファイル)
ツールによるXMLスキーマ妥当性の検証
© 2007 IBM Corporation
81
ビジネス・ユニットの名前
IBM Information Management software
解説：

82
XMLスキーマ設計ステップの最終成果物として、以下の二つを用意します。
–
XMLスキーマ(xsdファイル)
–
XMLインスタンスのサンプル(xmlファイル)
XML構文解析ツール(パーサー)や、XMLスキーマエディターの機能を使用して、XMLインスタンス、XMLスキーマの構文
の検査、およびXMLインスタンスが対応するスキーマに適合しているかどうかの妥当性検査を行ってください。
© 2007 IBM Corporation

2 XML 2 XMLスキーマ設計 目次 2.1 XMLスキーマ スキーマとは

Comments

Description

Transcript

2 XML 2 XMLスキーマ設計目次 2.1 XMLスキーマスキーマとは