制約

最終公開日 : Aug 10, 2026
ファセットを使用すると、データモデルでデータ制約を定義できます。 TIBCO EBX®は、XMLスキーマ制約ファセットをサポートし、高度なデータ制御のための拡張されたプログラムファセットを提供します。
Related information

XMLスキーマでサポートされているファセット

次の表は、さまざまなデータ型でサポートされているファセットを示しています。
キー：
  • X - サポートされています。
  • 1 - whiteSpace ファセットは定義できますが、EBX®では解釈されません。
  • 2 - XMLスキーマでは、タイプ stringで境界ファセットは許可されていません。それにもかかわらず、EBX®は拡張機能などのファセットを許可します。
  • 3 - osd:resource タイプは、必須のファセット FacetOResource のみをサポートします。 拡張ファセットを参照してください。
  • 4 - osd:dataspaceKey、 osd:datasetName、および osd:color タイプはファセットをサポートしません。
    これらの型では、プログラム上の制約のみがサポートされています。
length minLength max Length pattern enumeration white Space
xs:string X X X X X 1
xs:boolean X 1
xs:decimal X X 1
xs:dateTime X X 1
xs:time X X 1
xs:date X X 1
xs:anyURI X X X X X 1
xs:Name X X X X X 1
xs:integer X X 1
osd:resource 3 1
osd:dataspaceKey 4 1
osd:datasetName 4 1
osd:color 4 1
fraction Digits total Digits max Inclusive max Exclusive min Inclusive min Exclusive
xs:string 2 2 2 2
xs:boolean
xs:decimal X X X X X X
xs:dateTime X X X X
xs:time X X X X
xs:date X X X X
xs:anyURI
xs:Name 2 2 2 2
xs:integer X X X X X X
osd:resource 3
osd:dataspaceKey 4
osd:datasetName 4
osd:color 4
例：
<xs:element name="loanRate">
    <xs:simpleType>
        <xs:restriction base="xs:decimal">
            <xs:minInclusive value="4.5" />
            <xs:maxExclusive value="17.5" />
        </xs:restriction>
    </xs:simpleType>
</xs:element>

一意性の制約

標準のXMLスキーマエレメント xs:uniqueを使用して、一意性制約を定義することができます。この制約は、値または値のセットがテーブル内で一意である必要があることを示します。
例：
以下の例では、ターゲットフィールド「name」の「publisher」テーブルに一意性制約が定義されています。これは、「publisher」テーブルの2つのレコードが同じ名前を持つことはできないことを意味します。
<xs:element name="publisher">
    ...
    <xs:complexType>
        <xs:sequence>
            ...
            <xs:element name="name" type="xs:string" />
            ...
        </xs:sequence>
    </xs:complexType>
    <xs:unique name="uniqueName">
        <xs:annotation>
            <xs:appinfo>
                <osd:validation>
                    <severity>error</severity>
                    <message>Name must be unique in table.</message>
                    <message xml:lang="en-US">Name must be unique in table.</message>
                    <message xml:lang="fr-FR">Le nom doit être unique dans la table.</message>
                </osd:validation>
            </xs:appinfo>
        </xs:annotation>
        <xs:selector xpath="." />
        <xs:field xpath="name" />
    </xs:unique>
</xs:element>
一意性制約はテーブル内で定義する必要があり、次のプロパティがあります。
プロパティ 説明 必須
name属性 データモデルの制約を識別します。 はい
xs:selectorエレメント 制限されたXPath式を使用して一意性制約が適用されるテーブルを示します（「..」は禁止されています）。また、（制約の意味を変更せずに）テーブル内のエレメントを示すこともできます。 はい
xs:fieldエレメント 制限されたXPath式を使用して、値が一意である必要があるコンテキスト内のフィールドを示します。 複数の xs:fieldエレメントを定義することにより、値のセットが一意である必要があることを示すことができます。 はい
注意:
未定義の値（null値）は、単一のフィールドに適用される一意性制約では無視されます。複数のフィールドでは、未定義の値が考慮されます。つまり、値のセットが同じ定義済み値と未定義値を持っている場合、それらは重複していると見なされます。
追加のローカライズされた検証メッセージは、エレメント annotation/appinfoの下のエレメント osd:validationを使用して定義できます。カスタム検証メッセージが定義されていない場合は、ビルトインの検証メッセージが使用されます。
一意性制約は、単純な集約リストにも適用できます。この場合、リストの各値は、テーブルのスコープではなく、リストのスコープ内で一意である必要があります。
例：
以下の例では、ターゲットフィールド「printedEditions」の「title」テーブルに一意性制約が定義されています。これは、エディションがリストに1回だけ表示されることを意味します。
<xs:element name="title">
    ...
    <xs:complexType>
        <xs:sequence>
            ...
            <xs:element name="printedEditions" type="xs:string" minOccur="0" maxOccur="5"/>
            ...
        </xs:sequence>
    </xs:complexType>
    <xs:unique name="uniquePrintedEditions">
        <xs:annotation>
            <xs:appinfo>
                <osd:validation>
                    <severity>error</severity>
                    <message xml:lang="en-US">An edition must be referenced only once by this title</message>
                    <message xml:lang="fr-FR">Une édition ne peut être référencée qu'une seule fois par ce livre</message>
                </osd:validation>
            </xs:appinfo>
        </xs:annotation>
        <xs:selector xpath="." />
        <xs:field xpath="printedEditions"/>
    </xs:unique>
</xs:element>
制限事項：
  1. xs:field エレメントのターゲットはテーブル内にある必要があります。
  2. 一意性の制約は、計算フィールドには適用されません。
  3. 一意性制約は、集約リストを含む複数のフィールドに適用することはできません。
  4. 一意性制約は、埋め込みリストには適用できません。
以下も参照してください。:

拡張ファセット

EBX®は、XMLスキーマで指定されていないが、マスターデータの管理に役立つ追加の制約を提供します。
XMLスキーマの適合性を保証するために、これらの拡張ファセットはエレメント annotation/appinfo/otherFacetsの下で定義されます。

外部キー

EBX®を使用すると、特定のファセットを使用して既存のテーブルへの参照を作成できます。詳細については、外部キーを参照してください。

動的制約

動的制約ファセットはXMLスキーマのセマンティクスを保持しますが、value属性は、別のエレメントから値をフェッチできるようにするpath属性に置き換えられます。使用可能な動的制約は次のとおりです。
  • length
  • minLength
  • maxLength
  • maxInclusive
  • maxExclusive
  • minInclusive
  • minExclusive
    これらのファセットを使用して、データモデルを動的に変更できます。
    例：
    <xs:element name="amount">
        <xs:annotation>
            <xs:appinfo>
                <osd:otherFacets>
                    <osd:minInclusive path="/domain/Loan/Pricing/AmountMini/amount" />
                </osd:otherFacets>
            </xs:appinfo>
        </xs:annotation>
          ...
    </xs:element>
    この例では、ファセット minInclusive の境界は静的に定義されていません。境界の値は、ノード /domain/Loan/Pricing/AmountMini/amountから取得されます。
    制限事項：
  • ターゲットフィールドを集約リストにすることはできません。つまり、 maxOccurs = 1を定義することはできません。
  • ターゲットフィールドのデータ型は、ファセットと互換性がある必要があります。つまり、次のようにする必要があります。
    • ファセット length、 minLength、および maxLengthのタイプ integer。
    • ファセット maxInclusive、 maxExclusive、 minInclusive、および minExclusiveのファセットを保持するフィールドのデータ型と互換性があります。
  • ファセットを保持しているフィールドがテーブルにない場合、ターゲットフィールドをテーブルに含めることはできません。
  • ファセットを保持するフィールドがテーブル内にある場合、ターゲットフィールドは同じテーブル内またはテーブル外にある必要があります。
  • ターゲットフィールドが1つ以上の集約リストの下にある場合、ファセットを保持するフィールドもこれらの集約リストの下にある必要があります。つまり、ファセットを保持するフィールドは、ターゲットフィールドと同じリストオカレンス内、または親オカレンス内にある必要があります。これにより、XPathの観点から、ターゲットフィールドは単一の値を参照します。

FacetOResource制約

このファセットは、タイプ osd:resourceを使用してすべての定義に対して定義し、使用可能なパッケージ化されたリソースファイルのサブセットを列挙として指定する必要があります。このタイプの詳細については、osd:resourceタイプを参照してください。次の属性があります。
moduleName
エイリアスを使用して、リソースを含むEBX®モジュールを示します。リソースが現在のモジュールに含まれている場合、エイリアスの前に「wbp」を付ける必要があります。それ以外の場合、エイリアスは、ファイル module.xml のエレメント <dependencies> で定義されている値の1つである必要があります。
resourceType
「Image」、 「JavaScript」、 「Style sheet」、 「HTML」のいずれかの値であるリソースタイプを表します。
relatedPath
リソースが配置されるディレクトリを示します。このディレクトリは、リソースタイプに対応するディレクトリの下に配置する必要があります。たとえば、「イメージ」タイプのリソースの場合、ターゲットモジュールのディレクトリWEB-INF/と同じレベルにあるディレクトリwww/common/images/が使用され、相対パスは次の場所から定義する必要があります。これ。さらに、リソースがローカライズされたディレクトリ（www/fr/など）で定義されている場合、同じ名前の別のリソースがディレクトリwww/common/で定義されている場合にのみ考慮されます。
このファセットの動作は列挙ファセットと同じです。値は、指定されたモジュールの指定されたリソースタイプディレクトリのローカルパスにあるすべてのファイルを再帰的に一覧表示することによって収集されます。
例：
<xs:element name="promotion" type="osd:resource">
    <xs:annotation>
        <xs:appinfo>
            <osd:otherFacets>
                <osd:FacetOResource osd:moduleName="wbp"
                    osd:resourceType="ext-images" osd:relativePath="promotion/" />
            </osd:otherFacets>
        </xs:appinfo>
    </xs:annotation>
</ xs:element>
EBX®モジュール（Java EE Webアプリケーション）の標準ディレクトリ構造の概要については、モジュール構造を参照してください。

値の除外

excludeValue制約

このファセットは、値が指定された除外値と同じでないことを確認します。
この例では、空の文字列が許可された値から除外されています。
例：
<xs:element name="roleName">
    <xs:annotation>
        <xs:appinfo>
            <osd:otherFacets>
                <osd:excludeValue value="">
                    <osd:validation>
                        <severity>error</severity>
                         <message>Please select address role(s).</message>
                    </osd:validation>
                </osd:excludeValue>
            </osd:otherFacets>
        </xs:appinfo>
    </xs:annotation>
    <xs:simpleType type="xs:string" />
</xs:element>

excludeSegment制約

このファセットは、値が値の範囲に含まれていないことを確認します。境界は除外されます。
例：
この例では、20000から20999までの値は許可されていません。
<xs:element name="zipCode">
    <xs:annotation>
        <xs:appinfo>
            <osd:otherFacets>
                <osd:excludeSegment minValue="20000" maxValue="20999">
                    <osd:validation>
                        <severity>error</severity>
                         <message>Postal code not valid.</message>
                    </osd:validation>
                </osd:excludeSegment>
            </osd:otherFacets>
        </xs:appinfo>
    </xs:annotation>
    <xs:simpleType type="xs:string" />
</xs:element>

別のノードを使用して定義された列挙型制約

注意:
この種の制約は廃止されました。 外部キー制約を使用する必要があります。これには制限があります。特に、ユーザーインターフェイスでのクイック検索および並べ替え操作では、制約によって定義されたラベルの代わりに、フィールドの生の値が使用されます。
デフォルトでは、列挙ファセットはXMLスキーマで静的に記述されます。
列挙ファセットのコンテンツは、データモデル内の単純なエレメントのリストによって動的に提供することもできます。
例：
この例では、列挙ファセットのコンテンツはノード CountryListから供給されています。
<xs:annotation>
    <xs:appinfo>
        <osd:otherFacets>
            <osd:enumeration osd:path="../CountryList" />
        </osd:otherFacets>
    </xs:appinfo>
</xs:annotation>
参照されるノード CountryList：
  • 集約リスト、つまり maxOccurs> 1である必要があります。
  • 列挙ファセットを持つノードと同じタイプのエレメントのリストである必要があります。
  • 列挙ファセットを持つノードがテーブル内にない場合は、テーブル外のノードである必要があります。
  • この列挙型のノードがテーブル内にある場合は、テーブルの外部のノード、または列挙型ファセットのあるノードと同じテーブル内にある必要があります。
  • ターゲットフィールドが1つ以上の集約リストの下にある場合、ファセットを保持するフィールドもこれらの集約リストの下にある必要があります。つまり、ファセットを保持するフィールドは、ターゲットフィールドと同じリストオカレンス内、または親オカレンス内にある必要があります。これにより、XPathの観点から、ターゲットフィールドは単一の値を参照します。
例：
<xs:element name="FacetEnumBasedOnList">
    <xs:complexType>
        <xs:sequence>
            <xs:element name="CountryList" maxOccurs="unbounded">
                <xs:simpleType>
                    <xs:restriction base="xs:string">
                        <xs:enumeration value="DE" osd:label="Germany" />
                        <xs:enumeration value="AT" osd:label="Austria" />
                        <xs:enumeration value="BE" osd:label="Belgium" />
                        <xs:enumeration value="JP" osd:label="Japan" />
                        <xs:enumeration value="KR" osd:label="Korea" />
                        <xs:enumeration value="CN" osd:label="China" />
                    </xs:restriction>
                </xs:simpleType>
            </xs:element>
            <xs:element name="CountryChoice" type="xs:string">
                <xs:annotation>
                    <xs:appinfo>
                        <osd:otherFacets>
                            <osd:enumeration osd:path="../CountryList" />
                        </osd:otherFacets>
                    </xs:appinfo>
                </xs:annotation>
            </xs:element>
        </xs:sequence>
    </xs:complexType>
</xs:element>

プログラムファセット

プログラムによる制約は、単純型の任意のXMLエレメント宣言に追加できます。
XMLスキーマの適合性を保証するために、プログラムによる制約がエレメント annotation/appinfo/otherFacets の下に指定されています。

プログラム上の制約

プログラムによる制約は、インターフェイス制約を実装するJavaクラスによって定義されます。
追加のパラメーターを定義できるため、実装されるJavaクラスはJavaBeanプロトコルに準拠している必要があります。
例：
以下の例では、Javaクラスでメソッドを定義する必要があります。たとえば、 getParam1()、 setParam1(String)、 getParamX()、 setParamX(String)などです。
<xs:element name="amount">
    <xs:annotation>
        <xs:appinfo>
            <osd:otherFacets>
                <osd:constraint class="com.foo.CheckAmount">
                    <param1>...</param1>
                    <param...n>...</param...n>
                </osd:constraint>
            </osd:otherFacets>
        </xs:appinfo>
    </xs:annotation>
    ...
</xs:element>
以下も参照してください。:

プログラム上の列挙の制約

列挙型制約は、値の順序付きリストを基本的なプログラム制約に追加します。このファセットを使用すると、リストから値を選択できます。これは、インターフェイス ConstraintEnumeration を実装するJavaクラスによって定義されます。
例：
<xs:element name="amount">
    <xs:annotation>
        <xs:appinfo>
            <osd:otherFacets>
                <osd:constraintEnumeration class="com.foo.CheckAmountInEnumeration">
                    <param1>...</param1>
                    <param...n>...</param...n>
                </osd:constraintEnumeration>
            </osd:otherFacets>
        </xs:appinfo>
    </xs:annotation>
    ...
</xs:element>
注意:
ユーザーインターフェイスでのクイック検索および並べ替え操作では、ラベルの代わりにフィールドの生の値が使用されます。この列挙を、同じ値のセットを定義するテーブルへの外部キー制約に置き換えることができるかどうかを検討してください。

「null」値の制約

場合によっては、たとえば、別のフィールドに特定の値がある場合など、いくつかの条件が満たされた場合にのみ値が必須になります。この場合、標準のXMLスキーマ属性 minOccurs は静的であるため、不十分です。
値がそのコンテキストに従って必須であるかどうかを確認するには、次の要件が満たされている必要があります。
  1. プログラムによる制約は、Javaクラスで定義する必要があります（上記を参照）。
  2. このクラスは、インターフェイス ConstraintOnNull を実装する必要があります。
  3. XMLスキーマのカーディナリティ属性は、エレメントがオプションであることを指定する必要があります（ minOccurs="0"および maxOccurs="1"）。
注意:
デフォルトでは、「null」値の制約はユーザー入力時にチェックされません。入力でチェックを有効にするには、「checkNullInput」プロパティを設定する必要があります。また、エレメントがターミナルの場合は、データセットもアクティブ化する必要があります。
例：
<xs:element name="amount" minOccurs="0" maxOccurs="1">
    <xs:annotation>
        <xs:appinfo>
            <osd:otherFacets>
                <osd:constraint class="com.foo.CheckIfNull">
                    <param1>...</param1>
                    <param...n>...</param...n>
                </osd:constraint>
            </osd:otherFacets>
        </xs:appinfo>
    </xs:annotation>
    ...
</xs:element>
以下も参照してください。:

テーブルの制約

テーブルの制約は、インターフェイス ConstraintOnTable を実装するJavaクラスによって定義されます。テーブルノードでのみ定義できます。
追加のパラメーターを定義できるように。実装されたJavaクラスは、JavaBeanプロトコルに準拠している必要があります。
例：
以下の例では、Javaクラスでメソッドを定義する必要があります。たとえば、 getParam1()、 setParam1(String)、 getParamX()、 setParamX(String)などです。
<xs:element name="myTable" type="MyTableType" minOccurs="0" maxOccurs="unbounded">
    <xs:annotation>
        <xs:appinfo>
            <osd:table>
                <primaryKeys>/key</primaryKeys>
            </osd:table>
            <osd:otherFacets>
                <osd:constraint class="com.foo.checkTable">
                    <param1>...</param1>
                    <param...n>...</param...n>
                </osd:constraint>
            </osd:otherFacets>
        </xs:appinfo>
    </xs:annotation>
</xs:element>
注意:
パフォーマンス上の理由から、テーブルの制約は、データセットまたはテーブルの検証レポートを取得するときにのみチェックされます。これは、レコードの挿入、削除、変更などの更新がテーブルで発生したときに、これらの制約がチェックされないことを意味します。ただし、依存関係が定義されている場合、内部の増分検証フレームワークはこれらの制約の検証コストを最適化します。詳細については、検証パフォーマンスを参照してください。
以下も参照してください。:

制御ポリシー

ブロッキングと非ブロッキングの制約

リポジトリ内の更新が実行され、この更新によって特定の制約に従って検証エラーが追加された場合、新しいエラーが更新をブロックする（およびトランザクションをキャンセルする）か、非ブロックと見なされるか（トランザクションをキャンセルするか）を指定できます。更新をコミットして、後でエラーを修正できるようにします）。エレメント osd:validation内のエレメント blocksCommitは、次のサポートされている値でこの指定を許可します。
onInsertUpdateOrDelete
操作（データセットの更新、データセットの削除、レコードの作成、更新、または削除）の後も、制約が常に有効である必要があることを指定します。この場合、制約に違反する操作はすべて拒否され、値は変更されません。
これは、主キー制約、データ型変換制約（整数または日付は適切に記述されている必要があります）、およびマップされたテーブルの構造制約のデフォルトの必須ポリシーです。
onUserSubmit-checkModifiedValues
ユーザーが関連付けられた値を変更してフォームを送信するたびに、制約が有効なままである必要があることを指定します。この場合、制約に違反するフォーム入力はすべて拒否され、値は変更されません。
これは、前のケースで説明したすべてのブロッキング制約のデフォルトポリシーです。たとえば、外部キー制約は、フォーム送信のコンテキストを除いて、デフォルトではブロックされません（他のレコードによって参照されているレコードは削除できますなど）。
never
制約が操作をブロックしてはならないことを指定します。この場合、制約に違反する操作はすべて許可されます。ユーザーインターフェイスのコンテキストでは、ユーザーがこの制約に違反する値を設定した場合、この制約はフォームの送信をブロックしません。
外部キー制約では、すべての操作をブロックする制御ポリシーは、フィルター処理されたレコードには適用されません。つまり、参照レコードが存在するが外部キーフィルタを満たさない場合、外部キー制約はブロックされません。この場合、更新は拒否されず、検証エラーが発生します。
マップされたテーブルで定義されている構造制約に制御ポリシーを指定することはできません。つまり、このプロパティは、基になるRDBMSブロッキング制約の検証ポリシーのため、固定長、最大長、最大桁数、および小数点以下の桁数の制約には使用できません。
このプロパティは、アーカイブのインポートやデータスペースのマージには適用されません。つまり、アーカイブをインポートしてデータスペースをマージするときは、構造上の制約を除くすべてのブロッキング制約が常に無効になります。
以下も参照してください。:

XMLスキーマファセット

制御ポリシーは、ファセットの定義の下にある annotation/appinfoのエレメント osd:validationによって記述されます。
例：
<xs:element name="zipCode">
    <xs:simpleType>
        <xs:restriction base="xs:string">
            <xs:minInclusive value="1000">
                <xs:annotation>
                    <xs:appinfo>
                        <osd:validation>
                            <blocksCommit>onInsertUpdateOrDelete</blocksCommit>
                        </osd:validation>
                    </xs:appinfo>
                </xs:annotation>
            </xs:minInclusive>
        </xs:restriction>
    </xs:simpleType>
</xs:element>

XMLスキーマ列挙ファセット

制御ポリシーは、フィールドの定義の下にある annotation/appinfoのエレメント osd:enumerationValidationによって記述されます。
例：
<xs:element name="Gender">
    <xs:annotation>
        <xs:appinfo>
            <osd:enumerationValidation>
                <blocksCommit>onInsertUpdateOrDelete</blocksCommit>
            </osd:enumerationValidation>
        </xs:appinfo>
    </xs:annotation>
    <xs:simpleType>
        <xs:restriction base="xs:string">
            <xs:enumeration value="0" osd:label="male" />
            <xs:enumeration value="1" osd:label="female" />
        </xs:restriction>
    </xs:simpleType>
</xs:element>

EBX®ファセット

制御ポリシーは、ファセットの定義（ annotation/appinfo/otherFacetsで定義）の下のエレメント osd:validationによって記述されます。
値が onInsertUpdateOrDeleteおよび onUserSubmit-checkModifiedValues の制御ポリシーは、 osd:excludeSegment、 osd:excludeValue、および osd:tableRef EBX®ファセット。
値が never の制御ポリシーは、すべての EBX® ファセットで定義できます。
プログラムによる制約では、値が never の制御ポリシーは、対応する制約のセットアップ中にのみ直接設定できます。詳細については、Java API の ConstraintContext.setBlocksCommitToNever および ConstraintContextOnTable.setBlocksCommitToNever を参照してください。
例：
<xs:element name="price" type="xs:decimal">
    <xs:annotation>
        <xs:appinfo>
            <osd:otherFacets>
                <osd:minInclusive path="../priceMin">
                    <osd:validation>
                        <blocksCommit>onInsertUpdateOrDelete</blocksCommit>
                    </osd:validation>
                </osd:minInclusive>
            </osd:otherFacets>
        </xs:appinfo>
    </xs:annotation>
</xs:element>

「null」入力を確認

EBX®のデフォルトの検証ポリシーによると、一時的に不完全な入力を許可するために、必須エレメントはユーザー入力時に完了がチェックされません。むしろ、データセットの検証でのみ検証されます。ユーザー入力の直後に完了を確認する必要がある場合、エレメントは属性 osd:checkNullInput="true"を追加で指定する必要があります。集約リスト（ maxOccurs> 1）で定義されている場合、このプロパティは無視されます。
注意:
データモデルが minOccurs="1"を使用して静的に、または「null」の制約を使用して動的に必須エレメントを指定する場合、値は必須です。ターミナルエレメントの場合、必須値はアクティブ化されたデータセットに対してのみチェックされます。非終端エレメントの場合、データセットをアクティブ化する必要はありません。
例：
<xs:element name="amount" osd:checkNullInput="true" minOccurs="1">
    ...
</xs:element>
以下も参照してください。:

データ型のEBX® 空白管理

XML Schema (https://www.w3.org/TR/xmlschema-2/#rf-whiteSpace) によると、空白の処理は preserve、replace、collapse のいずれかのプロシージャに従わなければなりません。
preserve
正規化は実行されず、値は変更されません。
replace
#x9（タブ）、#xA（改行）、および#xD（キャリッジリターン）のすべての出現箇所が#x20（スペース）に置き換えられます。ス）。
collapse
replaceプロシージャの後、連続する #x20 の列は1つの #x20に折りたたまれ、先頭または末尾の #x20は削除されます。

一般的な空白の処理

EBX®は、XMLスキーマの推奨事項に準拠しています。
  • タイプ xs:string のフィールドの場合、主キーエレメントであるかどうかに関係なく、空白は常に保持され、空の文字列が nullに変換されることはありません。
  • 他のフィールド（ xs:string以外のタイプ）の場合、空白は常に折りたたまれ、空の文字列は nullに変換されます。
注意:
例外：
  • タイプ osd:html または osd:password のフィールドの場合、空白は常に保持され、空の文字列は nullに変換されます。
  • プロパティ osd:checkNullInput="true"を定義するタイプ xs:string のフィールドの場合、空の文字列はユーザー入力で nullとして解釈されますEBX®による。

ユーザー入力時の空白の処理

前のセクションで説明したルールはユーザーインターフェイスに適用されますが、先頭と末尾の空白はユーザー入力時に削除されます。つまり、ユーザーインターフェイスでは、空白はデフォルトで常にユーザー入力時にトリミングされます。その他の入力方法（XML/CSVのインポート、データサービス、API更新）は、ユーザーインターフェイスから削除されません。
注意:
例外：
  • タイプ osd:passwordのフィールドの場合、ユーザー入力時に空白は削除されません。
  • 外部キーフィールドの場合、ユーザー入力時に空白は削除されません。
データモデルで、ユーザー入力時に空白を削除しないように指定することができます。属性 osd:trim="disable"は、ユーザー入力時に先頭と末尾の空白を許可するフィールドに設定できます。
例：
<xs:element name="field" osd:trim="disable" type="xs:string">
    ...
</xs:element>

文字列型の主キーの空白処理

タイプ xs:stringの主キー列の場合、デフォルトのEBX®制約が定義されています。この制約は、レコードを作成するときに空の文字列と折りたたまれていない空白の値を禁止します。つまり、この制約に違反するレコードの作成はすべて拒否されます。
ただし、主キーノードが独自の xs:patternファセットを指定している場合、このファセットはデフォルトのEBX®制約をオーバーライドします。たとえば、特定のパターン「.*」は任意の文字列を受け入れますが、これは推奨されません。
デフォルトの制約では、特定のあいまいさを処理できます。たとえば、ユーザーが「1234」と「1234」の文字列を区別するのは困難です。一般的な値の場合、これによって競合が発生することはありませんが、主キーでエラーが発生します。
以下も参照してください。:

空の文字列管理

デフォルトの変換

タイプ xs:stringのノードの場合、ユーザー入力時に空の文字列と null値は区別されません。つまり、空の文字列値は、ユーザー入力時に自動的に nullに変換されます。

空の文字列と「null」値の区別

空の文字列と null値が区別される場合があります。たとえば、次の場合です。
  • 主キーは、空の文字列を許可するパターンを定義します。
  • エレメントは外部キー制約を定義し、ターゲットテーブルには空の文字列を許可するパターンを定義する単一の主キーがあります。
  • エレメントは、空の文字列を含む静的列挙を定義します。
  • エレメントは、前述のケースの1つを使用して、別のエレメントへの動的な列挙を定義します。
    空の文字列と null値が区別される場合、これは次の動作を意味します。
  • 空の文字列は、ユーザー入力時に nullに変換されません。
  • タイプ xs:stringのノードの入力フィールドには、ノードの値を nullに設定するための追加のボタンが表示されます。
  • 検証時に、空の文字列は minOccurs="1"プロパティに関して準拠した値と見なされます。

検証メッセージのしきい値

検証を実行するときに、制約ごとに許可される検証メッセージの最大数をデータモデルレベルで指定できます。
例：
<xs:schema ...>
    ...
    <xs:annotation>
        <xs:appinfo>
            <osd:validation>
                <validationMessageThreshold>250</validationMessageThreshold>
            </osd:validation>
        </xs:appinfo>
    </xs:annotation>
    ...
</xs:schema>
しきい値は、データモデルおよび各データセット検証レポートで定義された制約ごとに考慮されます。制約がしきい値に達すると、制約の検証が停止され、しきい値に達したことを示すエラーメッセージが検証レポートに追加されます。
検証メッセージのしきい値は、データモデルで定義されていない場合、デフォルトで 1000に設定されます。検証メッセージの数に制限はありません。また、指定された検証メッセージのしきい値は100以上である必要があります。
以下も参照してください。: