制約

最終公開日 : Sep 16, 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 を使用して、一意性制約を定義することができます。この制約は、値または値のセットがテーブル内で一意である必要があることを示します。
一意性制約で定義された文字列フィールドのチェックに使用される大文字と小文字の区別を指定できます。大文字と小文字の区別に使用できる値は、「sensitive」または「insensitive」です。デフォルトでは、一意性制約では大文字と小文字が区別されます。
注意:
大文字と小文字を区別しないオプションを適用して大規模なデータを含むテーブルをチェックすると、パフォーマンスの問題が発生する可能性があります。
例
以下の例では、「publisher」テーブルのターゲットフィールド「name」に対して一意性制約が定義されています。これは、「publisher」テーブル内の 2 つのレコードが同じ名前を持つことができないことを意味します。大文字と小文字を区別するオプションは、フィールド「name」の一意性をチェックするために使用されます。
<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>
                     <caseSensitivity>sensitive</caseSensitivity>
                    <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 を使用して定義できます。カスタム検証メッセージが定義されていない場合は、ビルトインの検証メッセージが使用されます。
一意性制約は、単純な集約リストにも適用できます。この場合、リストの各値は、テーブルのスコープではなく、リストのスコープ内で一意にする必要があります。
例
以下の例では、「title」テーブルのターゲットフィールド「printedEditions」に対して一意性制約が定義されています。これは、エディションがリストに 1 回だけ表示されることを意味します。「title」フィールドの検索には、大文字と小文字を区別しないオプションが使用されます。
<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>
                    <caseSensitivity>insensitive</caseSensitivity>
                    <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> で定義されている値のいずれかにする必要があります。
resourceType
「Image」、「JavaScript」、「Style sheet」、「HTML」のいずれかの値であるリソースタイプを表します。
relatedPath
リソースが配置されるディレクトリを示します。このディレクトリは、リソースタイプに対応するディレクトリの下に配置する必要があります。たとえば、「Image」タイプのリソースの場合、ターゲットモジュールのディレクトリ 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® モジュール (Jakarta 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 の下に指定されています。

プログラム上の制約

プログラムによる制約は、インターフェイス Constraint を実装する 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 スキーマ (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 のフィールドの場合、空の文字列は EBX® によるユーザー入力で null として解釈されます。

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

前のセクションで説明したルールはユーザーインターフェイスに適用されますが、先頭と末尾の空白はユーザー入力時に削除されます。つまり、ユーザーインターフェイスでは、空白はデフォルトで常にユーザー入力時にトリミングされます。その他の入力方法 (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® 制約をオーバーライドします。たとえば、特定のパターン「.*」は任意の文字列を受け入れますが、これは推奨されません。
デフォルトの制約では、特定のあいまいさを処理できます。たとえば、ユーザーが「12 34」と「12  34」の文字列を区別するのは困難です。一般的な値の場合、これによって競合が発生することはありませんが、主キーでエラーが発生します。
以下も参照してください。:

空の文字列管理

デフォルトの変換

タイプ 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 以上にする必要があります。
以下も参照してください。: