| Oracle® Communications Data Modelリファレンス リリース11.3.1 B70210-01 |
|
 前 |
 次 |
Oracle Communications Data Modelの論理データ・モデルは、ビジネス・エンティティとそのリレーションシップを定義し、ビジネスおよびOracle Communications Data Modelデータ・ウェアハウスのデータ要件への理解を提供します。
この章の内容は次のとおりです。
次の項では、Oracle Communications Data Modelの主要な(または典型的な)サブジェクト・エリアに関連する主なエンティティについて説明します。
|
注意: これらのサブジェクト・エリアの主要な参照エンティティのE-R図は、Oracle Communications Data Model IPパッチで利用可能です。IPパッチは、追加ドキュメントを含みます。IPパッチの取得およびOracle Communications Data Modelパッチ・セットの最新情報は、https://support.oracle.comのMy Oracle Supportにアクセスしてください。 |
表2-1に、アカウント・シンプル・サブジェクト・エリアに関連するエンティティを示します。
表2-2に、顧客サブジェクト・エリアに関連するエンティティを示します。
表2-3に、ディーラー・サブジェクト・エリアに関連するエンティティを示します。
表2-4に、地理サブジェクト・エリアに関連するエンティティを示します。
表2-4 サブジェクト・エリアのエンティティ: 地理
| 地理エンティティ・リスト |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
GEOGRAPHY DEMOGRAPHY ATTRIBUTE |
|
|
|
|
|
|
|
|
|
GEOGRAPHY HIERARCHY LEVEL ASSIGNMENT |
|
|
|
|
|
GEOGRAPHY LEVEL ATTRIBUTE VALUE |
|
|
|
|
|
|
|
|
|
PARTY ADDRESS LOCATION ASSIGNMENT |
|
|
|
|
表2-6に、パーティ・サブジェクト・エリアに関連するエンティティを示します。
表2-6 サブジェクト・エリアのエンティティ: パーティ
| パーティ・エンティティ・リスト |
|---|
|
ACCESS METHOD PARTY ASSIGNMENT |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ORGANIZATIONAL DEMOGRAPHY VALUE |
|
|
|
|
|
PARTY ADDRESS LOCATION ASSIGNMENT |
|
|
|
|
|
PARTY CONTACT LIST PARTICIPATION |
|
|
|
PARTY GEOGRAPHY ENTITY ASSIGNMENT |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
表2-7に、パーティ(拡張)・サブジェクト・エリアに関連するエンティティを示します。
表2-7 サブジェクト・エリアのエンティティ: パーティ(拡張)
| パーティ(拡張)・エンティティ・リスト |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PARTY ADDRESS LOCATION ASSIGNMENT |
|
|
|
|
|
|
|
|
|
PARTY CONTACT INFORMATION TYPE |
|
|
|
PARTY GEOGRAPHY ENTITY ASSIGNMENT |
|
|
|
PARTY LOYALTY PROGRAM PARTICIPATION |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
表2-8に、製品サブジェクト・エリアに関連するエンティティを示します。
表2-8 サブジェクト・エリアのエンティティ: 製品
表2-9に、製品インスタンス・サブジェクト・エリアに関連するエンティティを示します。
表2-9 製品インスタンス・サブジェクト・エリアのエンティティ
| 製品インスタンス・エンティティ・リスト |
|---|
|
ACCESS METHOD EQUIPMENT ASSIGNMENT |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EQUIPMENT INSTANCE RENTING CONTRACT |
|
EQUIPMENT INSTANCE STATUS HISTORY |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
表2-10に、サービス・サブジェクト・エリアに関連するエンティティを示します。
表2-11に、サブスクリプション・サブジェクト・エリアに関連するエンティティを示します。
表2-11 サブジェクト・エリアのエンティティ: サブスクリプション
| サブスクリプション・エンティティ・リスト |
|---|
|
ACCESS METHOD SUBSCRIPTION ASSIGNMENT |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EQUIPMENT INSTANCE RENTING CONTRACT |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
SIM CARD SUBSCRIPTION ASSIGNMENT |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
表2-12に、時間カレンダ・サブジェクト・エリアに関連するエンティティを示します。
表2-13に、ベンダー・サブジェクト・エリアに関連するエンティティを示します。
表2-13 サブジェクト・エリアのエンティティ: ベンダー・エンティティ
| ベンダー・エンティティ・リスト |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
VENDOR FACTOR COMPANY ASSIGNMENT |
|
|
|
|
|
VENDOR SITE COURIER ASSIGNMENT |
表2-14に、ワイヤレス・ネットワーク・サブジェクト・エリアに関連するエンティティを示します。
|
注意: Oracle Communications Data Modelでは、電話回線(PSTN)およびケーブル・タイプのネットワークもカバーされます。ここでのワイヤレス・ネットワークは、サポートされるネットワーク・タイプの1つの例です。 |
表2-14 サブジェクト・エリアのエンティティ: ワイヤレス・ネットワーク
| ワイヤレス・ネットワーク・エンティティ・リスト |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
NETWORK SERVICE COVERAGE ASSIGNMENT |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
SWITCH ROUTING DEVICE ASSIGNMENT |
|
|
|
|
|
|
これらのビジネス・エリアのリストには、ビジネス・エリアごとにグループ化されたデータ・モデルの論理エンティティが含まれます。
|
注意: ビジネス・エリアの概念は厳密ではありません。つまり、一部のビジネス・エリアは重複しています。そのため、1つの論理エンティティが複数のビジネス・エリアに属する(または必要とされる)ことがあります。一部の論理エンティティは、表の間のリレーションシップを表すのみであるか、ビジネス・エリアにとってあまり重要でないか、単に検索エンティティであるために、リストに明示されていません。詳細は、「Oracle Communications Data Modelのビジネス・エリアおよびサブジェクト・エリア」を参照してください。 |
ビジネス・エリア論理データ・モデル・エンティティを次に示します。
|
注意: 属性およびエンティティを使用した完全なダイアグラムを示すビジネス・エリアの図は、Oracle Communications Data Model IPパッチとともに利用可能です。IPパッチは、追加ドキュメントを含みます。IPパッチの取得およびOracle Communications Data Modelパッチ・セットの最新情報は、https://support.oracle.comのMy Oracle Supportにアクセスしてください。 |
表2-15に、コストの論理エンティティを示します。
表2-15 コスト・ビジネス・エリア論理エンティティ
| コスト・エンティティ・リスト |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EMPLOYEE ACTUAL LABOR SALARIED |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ORGANIZATION BUSINESS UNIT COST |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
表2-16に、顧客管理の論理エンティティを示します。
表2-16 顧客管理ビジネス・エリア論理エンティティ
表2-17に、マーケティングの論理エンティティを示します。
表2-17 マーケティング・ビジネス・エリア論理エンティティ
| マーケティング・エンティティ・リスト |
|---|
|
ACCOUNT PMP PARTICIPATION HISTORY |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PARTY CONTACT LIST PARTICIPATION |
|
|
|
PARTY GEOGRAPHY ENTITY ASSIGNMENT |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PROMOTION CONTACT LIST UTILIZATION |
|
|
|
PROMOTION MARKET PLAN ASSIGNMENT |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
表2-18に、ネットワークの論理エンティティを示します。
表2-18 ネットワーク・ビジネス・エリア論理エンティティ
| ネットワーク・エンティティ・リスト |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EVENT PARTY INTERACTION LETTER |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
NETWORK SERVICE COVERAGE ASSIGNMENT |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
SWITCH ROUTING DEVICE ASSIGNMENT |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
WIRELESS CONTENT DOWNLOADING EVENT |
|
|
|
|
表2-19に、パートナ管理の論理エンティティを示します。
表2-19 パートナ管理ビジネス・エリア論理エンティティ
| パートナ管理エンティティ・リスト |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
DEALER DISCOUNT GROUP ASSIGNMENT |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
NP REQUEST LINE ITEM STATE TYPE |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
VENDOR SITE COURIER ASSIGNMENT |
|
|
表2-20に、製品管理の論理エンティティを示します。
表2-20 製品管理ビジネス・エリア論理エンティティ
表2-21に、プロビジョニングおよびサービスの論理エンティティを示します。
表2-21 プロビジョニングおよびサービス・ビジネス・エリア論理エンティティ
表2-22に、収益の論理エンティティを示します。
表2-22 収益ビジネス・エリア論理エンティティ
表2-23～表2-29に、論理データ・モデル・エンティティをアルファベット順にリストします。
表2-23 エンティティの説明(A～C)
| エンティティ名 | タイプ | 説明 |
|---|---|---|
|
リファレンス |
顧客のサービスへのアクセス方法または利用方法。例:
|
|
|
リファレンス |
アカウントへのACCESS METHODの割当て。 |
|
|
検索 |
2つのACCESS METHOD間のリレーションシップのタイプ。例:
|
|
|
リファレンス |
関連するACCESS METHODへのACCESS METHODの割当て。 |
|
|
リファレンス |
ACCESS METHODは、管理がしやすいように複数の要素に分割できます。各要素はACCESS METHODのセグメントであり、各セグメントはアクセス方法のグループを表します。たとえば、電話番号のアクセス方法には、次のようなアクセス方法要素があります。
|
|
|
検索 |
ACCESS METHOD ELEMENTのタイプの参照。例:
|
|
|
リファレンス |
アクセス・メソッドと機器インスタンスとのバインド。例:
|
|
|
リファレンス |
地理的地域へのアクセス方法の割当て。 |
|
|
リファレンス |
パーティへのアクセス方法の割当て。 |
|
|
検索 |
ACCESS METHODとPARTY間のリレーションシップのタイプの参照。例:
アクセス方法とパーティの管理タイプのリレーションシップは、従業員がアクセス方法グループを管理することを指定します。 |
|
|
リファレンス |
論理ネットワーク・リソース。例:
|
|
|
ベース |
番号移行方式に基づいて、別の通信事業会社から顧客が持ってきたアクセス方法の履歴。 |
|
|
リファレンス |
使用状況の追跡のために定義されたACCESS METHODのセグメント。例:
|
|
|
リファレンス |
製品機能に必要なアクセス方法セグメントを定義するACCESS METHOD SEGMENTとPRODUCT CAPABILITYのリレーションシップ。 |
|
|
リファレンス |
SERVICEとACCESS METHOD間のリレーションシップを定義します。たとえば、どのサービス(GSM音声)がどの携帯電話番号を使用しているかという関係です。 |
|
|
ベース |
ACCESS METHODのステータス。現在および履歴のステータスを定義します。例:
|
|
|
検索 |
ACCESS METHODのステータス変更の理由の参照。 例:
|
|
|
検索 |
使用可能なACCESS METHODステータス・タイプおよび説明の参照。例:
|
|
|
リファレンス |
SUBSCRIPTIONへのACCESS METHODの割当て。 |
|
|
検索 |
ACCESS METHODタイプの参照: 顧客によるサービスまたは製品の使用方法またはアクセス方法のタイプを定義します。例:
|
|
|
リファレンス |
アイテム、製品またはサービスに加えてサービス・プロバイダから購入する付属品。例:
|
|
|
リファレンス |
アカウントは、サービス・プロバイダと顧客の契約によって生成されます。サービス・プロバイダが、CDMA、GSM、ブロードバンドおよびその他の異なるネットワークをホストする場合、1人の顧客が様々なネットワークの異なるアカウントを持つか、それらを1つにまとめることもできます。 設定が完了すると、顧客はWebサイトまたはサービス・プロバイダ・ターミナルからセルフ・サービスでアカウントを使用できます。この場合は通常、アカウントをパスワードで保護します。 |
|
|
リファレンス |
2つのACCOUNT間のリレーションシップのタイプ。たとえば、法人アカウントには、複数の関連するアカウントがあります。 |
|
|
ベース |
ACCOUNTの支払請求サイクルのステータス履歴。 |
|
|
検索 |
すべての調停理由の参照。例:
|
|
|
リファレンス |
ACCOUNT間のリレーションシップの割当て。たとえば、親アカウントと子アカウントなど。 |
|
|
検索 |
ACCOUNTの関連付けに使用可能な理由の参照。 |
|
|
ベース |
アカウント残高へのすべての調整のリストが含まれます。これらは純粋な調整であり、追加の支払いやコストのみではありません。通常、アカウント残高の調整はPARTY INTERACTION THREADに関連します。 |
|
|
検索 |
すべての調整のタイプの参照。例:
|
|
|
ベース |
プリペイド残高の各「バケット」の有効期限およびチャージ日を追跡します。 |
|
|
リファレンス |
残高グループの概念により、1つのアカウントで複数の残高グループを持つことができ、異なるサービスのグループに適用できます。たとえば、一部の特別な割引(金額残高)をワイヤレス・コールに割り当て、固定回線サービスに割り当てないことが可能です。 |
|
|
ベース |
主要通貨によるACCOUNTの残高履歴。残高値は残高タイプによって分類されています。例:
|
|
|
ベース |
アカウント残高変更の詳細(特定のイベントが原因)。例:
|
|
|
導出 |
ACCOUNTおよびPRODUCT MARKET PLANの無料時間割引(PPA)の日次集計。 |
|
|
ベース |
2つのACCOUNT間のpeer-to-peer残高転送。あるACCOUNTから別のACCOUNTにクレジット(無料時間など)を転送できます。 |
|
|
検索 |
アカウント残高のタイプ。例:
|
|
|
リファレンス |
ACCOUNTの支払請求サイクルのステータス履歴。 |
|
|
リファレンス |
ACCOUNTの請求頻度の履歴。 |
|
|
リファレンス |
ACCOUNTの各請求発生を指定します。請求発生は、事前定義済の請求サイクルまたはアカウント終了などの他のイベントによってトリガーされる場合があります。単一アカウント請求発生で、複数の請求書が生成される場合があります。 |
|
|
リファレンス |
ACCOUNTの請求期間の履歴。 |
|
|
リファレンス |
顧客アカウントによって割り当てることができるビジネス対話役割。 |
|
|
リファレンス |
||
|
ベース |
||
|
ベース |
アカウント、サブスクリプションまたは契約への貸出限度額の割当て。 |
|
|
導出 |
各アカウントの借入状況の日次サマリー。 |
|
|
集計 |
ACCOUNT DEBT DAY DRVDから導出。各CUSTOMER TYPEの借入状況の月次サマリー。 |
|
|
ベース |
借入れを清算して受取勘定から削除する取引。 |
|
|
検索 |
アカウント・イベント・タイプの参照。 |
|
|
ベース |
PARTY ACCOUNT ASSIGNMENTのサブタイプ。アカウント管理履歴は、販売チャネルを通じたアカウントの作成、アカウントの更新または解約など、従業員からアカウントへの管理リレーションシップを追跡します。 |
|
|
リファレンス |
PRODUCT MARKET PLANへのアカウントおよびパーティの割当て。 |
|
|
ベース |
アカウントに対するパーティからの受取による資金の割当て。製品またはサービスの提供および供給への未払額に対するクレジットとしてのパーティからの一括払いの受取。 |
|
|
ベース |
||
|
導出 |
すべての顧客による支払いの日次集計。 |
|
|
ベース |
各アカウントの優先支払い方法のステータス履歴。例:
|
|
|
集計 |
支払い方法ステータスに対するすべての変更および経時的な変化の理由を収集します。 |
|
|
導出 |
支払い方法ステータスに対する変更を収集します。 |
|
|
検索 |
アカウントの支払い方法の個別ステータスの参照。例:
|
|
|
検索 |
ACCOUNT PAYMENT METHOD STATUSのタイプの参照。例:
|
|
|
集計 |
すべての顧客による支払いの月次サマリー。 |
|
|
ベース |
アカウントによるPRODUCT MARKET PLANの使用方法の履歴を定義します。 |
|
|
リファレンス |
アカウントの優先する請求書配送タイプの履歴。 |
|
|
リファレンス |
アカウントの優先支払い方法が含まれます。 |
|
|
リファレンス |
アカウントに関する詳細を記録します。 |
|
|
ベース |
顧客アカウントへのチャージ(補充)。 |
|
|
ベース |
顧客への返金は、通常では請求額の調整に基づいて、顧客の口座に戻される金銭です。 |
|
|
導出 |
顧客への返金および収益への影響の日次サマリー。 |
|
|
集計 |
顧客への返金および収益への影響の月次サマリー。 |
|
|
検索 |
返金が発生する理由の参照。例:
|
|
|
検索 |
ACCOUNT ROLEのタイプ(プライマリ・アカウントやセカンダリ・アカウントなど)。 |
|
|
リファレンス |
類似の特徴を持つ異なるアカウント・グループを識別するセグメント。通常、アカウント・セグメントはデータ・マイニング分析から生成されます。 |
|
|
リファレンス |
各アカウントへのアカウント・セグメントの割当て。 |
|
|
リファレンス |
アカウントの集まりを作成します。 |
|
|
導出 |
各アカウントのアカウント統計。通常、1つのアカウントには複数のSUBSCRIPTIONおよびCONTRACTがあり、すべての値はアカウント・レベルで合計されます。削除または停止されているアカウントも含まれており、任意の削除または停止かどうかにかかわらず、それらはチャーンとしてみなされます。 |
|
|
集計 |
CUSTOMER TYPE別のより高いレベルでのアカウント統計情報。 |
|
|
導出 |
すべての顧客についての月次のステータス変更情報。 |
|
|
ベース |
有効化、一時停止などを含むアカウント・ステータスの変更履歴。 |
|
|
検索 |
アカウント・ステータスの理由の参照、または特定アカウントのステータスの変更について考えられる理由の参照。 |
|
|
検索 |
アカウント・ステータスのタイプの参照。 |
|
|
集計 |
顧客タイプ別のより高いレベルでのアカウント統計情報。 |
|
|
リファレンス |
アカウントによるサブスクリプションの履歴。 |
|
|
検索 |
各アカウントとサブスクリプションのリレーションシップに関連付けられた理由。例:
|
|
|
検索 |
アカウント・タイプの参照。例:
|
|
|
検索 |
内部請求期間。利用額を計算し、総勘定元帳勘定のために勘定残高を更新します。 |
|
|
検索 |
発生した費用に関連付けることが可能なカテゴリの参照。例:
|
|
|
リファレンス |
製品、パーティおよびその他の情報に関するメモやコメントを複数の言語で保存できます。 |
|
|
リファレンス |
実際の住所またはメール・アドレスの詳細。 |
|
|
リファレンス |
同じADDRESS LOCATIONで使用する他の名前を追跡します。 |
|
|
リファレンス |
住所を他の住所に関連付けます。住所は様々な方法で関連付けできます。たとえば、ある住所は、複数の住所を持つ場所用の別の住所の代替になります。 |
|
|
検索 |
住所の関連付けの理由の参照。 |
|
|
検索 |
2つのアドレス間のリレーションシップのタイプの参照。 |
|
|
ベース |
所在地住所の現在のステータス。例:
|
|
|
検索 |
現在のADDRESS STATUSの変更理由の参照。 |
|
|
検索 |
住所タイプの参照。例:
|
|
|
リファレンス |
広告期間を定義します。 |
|
|
リファレンス |
広告カレンダの四半期を定義します。 |
|
|
リファレンス |
広告カレンダの週を定義します。 |
|
|
リファレンス |
広告カレンダの年を定義します。 |
|
|
検索 |
有効期間に従って顧客をグループ分けする値の範囲の参照。例:
|
|
|
検索 |
サブスクライバのライフ・サイクルの範囲を定義します。例:
|
|
|
リファレンス |
ネットワークの集計部分のインタフェースである集計インタフェースとして機能するDEVICE INTERFACEを定義します。この役割の目的は、特定のドメインのすべての集計インタフェースで同じ一般的な構成コマンドを受け取るためにPOLICYの定義を有効化することです。 |
|
|
リファレンス |
SUBSCRIPTIONに対して課金が開始される前に許可される値引き。 |
|
|
リファレンス |
米国で使用される所有地住所。 |
|
|
リファレンス |
オーストラリアおよびニュージーランドで使用されるSICコード。 |
|
|
ベース |
ビジネス遂行のために将来の時間を定義する2つのパーティ間の約束。例:
|
|
|
ベース |
ベンダーまたはプロバイダがサービスを提供する時間を割り当てます。 |
|
|
検索 |
約束事のタイプの参照。例:
|
|
|
集計 |
CUSTOMER TYPEレベルのARPUを計算するための収益の月次サマリー。 |
|
|
導出 |
収益およびサブスクライバ・ベース・カウントを伴う収益の構成の月次サマリー。ARPUの値を計算するために使用されます。 |
|
|
検索 |
1単位当たりの平均収益バンドの定義。例:
|
|
|
リファレンス |
事業者の財務ステータスの対象となる可能性がある、事業者が所有する有形または無形の経済資源。たとえば、ルーター、スイッチなどのネットワーク要素や土地、建物、特許などの事業資産が資産となる場合があります。 |
|
|
ベース |
ASSETの評価履歴。 |
|
|
ベース |
内部の従業員または請負業者によって検査された、ASSETの状態履歴。これは、乗り物や建物にとって重要です。 |
|
|
ベース |
特定のASSETの会計上の減価償却履歴。 |
|
|
リファレンス |
||
|
リファレンス |
||
|
検索 |
ASSETのタイプ。例:
|
|
|
リファレンス |
非同期転送モード(ATM)は、固定サイズのセルのデータ転送に基づいたネットワーク・テクノロジです。ATMで使用するセルは、古いテクノロジで使用するセルと比べて比較的小さいサイズです。原則として、小さい不変のセル・サイズは、ATM機器による同じネットワーク上のビデオ、オーディオおよびコンピュータ・データの送信を許可し、単一タイプのデータがネットワーク・トラフィックを占有しないようにします。ATMは、データ転送が開始されるたびに2つのポイント間の固定ルートを作成します。これは、メッセージがパケットに分割され、各パケットで送信元から送信先への異なるルートを使用できるTCP/IPと異なります。この違いによってATMネットワークのデータ使用の追跡および請求が容易になりますが、ネットワーク・トラフィックの突然の増加に適応しにくくなります。 |
|
|
リファレンス |
自律システム(AS)は、ルーティングを使用するシステムを分離して、ルーティングの構造化ビューを提供します。例:
これにより、システムが一連の個別に管理されたドメインに分割され、それぞれ固有の個別のルーティング・ポリシーを使用します。これはRFC1771で定義されています。 |
|
|
リファレンス |
このエンティティは、デバイスの適切な運用に必要な電源、ファン、ケーブルなどの管理エンティティを表しますが、デバイスの主要なエンドユーザー機能とは異なる主要な機能があります。 補助コンポーネントとEQUIPMENTの他のサブクラスの違いは、物理オブジェクトがデバイスの主要な機能の固有の機能を実行するかどうかです。たとえば、ROUTERについて考えてみます。ルーターの主要な機能は、パケットのルーティングおよび転送です。ROUTERの適切な動作に必要ですがパケットのルーティングと転送を直接サポートしないため、電源は補助コンポーネントです。目的がパケットのルーティングおよび転送のため、ルーティング機能を提供するライン・カードは、EQUIPMENTのサブクラスです。類似する例は、基準が異なる可能性がある様々なタイプの機器に対して存在します。たとえば、パケットをルーティングまたは転送するかどうかのかわりに、コンポーネントを適切に分類するために基準「信号を送信するか」が役立つ場合があります。 |
|
|
検索 |
LOYALTY PROGRAMおよび通信事業者の収益への貢献に基づいた顧客のロイヤルティ・レベル。例:
|
|
|
リファレンス |
取引で使用される銀行の情報。 |
|
|
リファレンス |
PAYMENT CHANNELのサブタイプ。顧客が銀行口座からの自動引き落としによって支払いができる様々な銀行ルートを追跡します。 |
|
|
検索 |
顧客がサービスの使用を禁止される理由の定義の参照。 |
|
|
リファレンス |
DAYのベースとして機能する1日の抽象化された情報。 |
|
|
リファレンス |
NETWORK ELEMENTのサブタイプで、ネットワークのBase Station Controller (BSC)のリストです。従来、Base Station Controllerは、BASE TRANSCEIVER STATION (BTS)の背後でインテリジェンスを提供します。通常、数十または数百のBTSがBSCの制御下にあります。BSCは、無線チャネルの割当て、携帯電話からの測定値の受信、およびBTS間のハンドオーバーの制御を行います。 |
|
|
リファレンス |
Base Transceiver Station (BTS)は、User Equipment (UE)とネットワーク間の無線通信を支援する機器です。 |
|
|
導出 |
ネットワーク要素に関するBER (Bit Error Rate)およびFER (Frame Error Rate)の日次統計。 |
|
|
集計 |
ネットワーク要素に関するBER (Bit Error Rate)およびFER (Frame Error Rate)の月次統計。 BER FER ERROR RATIO DAY DRVDから導出されます。 |
|
|
検索 |
BER (Bit Error Rate)またはFER (Frame Error Rate)の統計値を示します。 |
|
|
検索 |
各請求期間/サイクルの記録。通常、請求期間は1か月です。顧客は、請求期間内の異なる日付に請求される場合があります。例:
|
|
|
検索 |
請求頻度は、請求期間を構成する請求周期の数を指定します。 |
|
|
検索 |
トリガー・タイプで分類できる請求発生のタイプ。例:
|
|
|
検索 |
請求周期は、請求期間を計算するために使用される単位を指定します(日または月など)。 |
|
|
検索 |
請求ステータスのカテゴリの参照。例:
|
|
|
検索 |
NETWORK EVENTが特定の請求ステータスの理由の参照。例:
|
|
|
検索 |
請求結果(理由を含む)のステータス・タイプの参照。例:
|
|
|
ベース |
すべてのブラックリスト顧客の履歴。 |
|
|
リファレンス |
ハードウェアに関連するブランド(通常はハンドセットだが、ITEMにも適用される)。 |
|
|
リファレンス |
ブリッジング・プロトコルはOSIモデルのデータ・リンク・レイヤーで動作し、様々なタイプの同種および異種のローカル・エリア・ネットワークの通信を定義するために使用されます。 |
|
|
リファレンス |
PRODUCTサービスのサブタイプ。ブロードバンド製品に固有の特性を示します。 |
|
|
リファレンス |
PRODUCT RATING PLAN(BROADBAND製品に適用)のサブタイプ。 |
|
|
リファレンス |
ブロードバンド・サービスは、ユーザーが使用するブロードバンド・サービスを追跡するためのSERVICEのサブタイプです。 |
|
|
ベース |
顧客がネットワークに接続している間の期間として通常実装されるブロードバンド・ネットワーク使用イベント。これは時間の使用に基づいて請求されます。 インターネット接続製品によっては、データ量に応じて料金が発生する場合もあります。 |
|
|
検索 |
クライアント・ブラウザのブランドの参照。例:
|
|
|
リファレンス |
顧客のブラウザのバージョン(Internet Explorer 6.0やFirefox 3.6など)。 |
|
|
ベース |
詳細な製品バンドル使用イベント。バンドルされたネットワーク・イベントは、製品バンドル使用または製品コンポーネント使用の可能性がある他の製品使用イベントで構成されます。 |
|
|
リファレンス |
事業者の財政的関心の対象となる事業資産。例:
注意: ネットワークの一部である機器は、エンティティNETWORK ELEMENTに含まれます。 |
|
|
リファレンス |
業務カレンダの半月を定義します。 |
|
|
リファレンス |
業務カレンダの半年を定義します。 |
|
|
リファレンス |
1つ以上のPARTY ROLE、要素役割および顧客アカウント間の手配、契約、連絡または共同活動を示します。ビジネス対話は、1つ以上のBUSINESS INTERACTION ITEMで構成される場合があります。BUSINESS INTERACTION ITEMは、製品、サービス、要素または指定のいずれかを参照する場合があります。ビジネス対話は、1つ以上の場所で詳細に定義されます。ビジネス対話が別のビジネス対話を参照し、BUSINESS INTERACTION ITEMが同じまたは異なるビジネス対話の別のBUSINESS INTERACTION ITEMを参照する場合があります。 5つのタイプのビジネス対話があります。
|
|
|
リファレンス |
2つのBUSINESS INTERACTION間のリレーションシップを定義します。 |
|
|
検索 |
下位のビジネス対話などの対話タイプ。 |
|
|
リファレンス |
BUSINESS INTERACTIONの特性品質または特殊機能。 |
|
|
検索 |
||
|
リファレンス |
||
|
ベース |
ビジネス対話の目的が製品タイプ、PRODUCT MARKET PLAN、サービス・タイプまたはNETWORK ELEMENT TYPEで表されるか、製品、サービスまたはNETWORK ELEMENTを参照する場合があります。BUSINESS INTERACTIONに含まれる詳細アイテム。 |
|
|
ベース |
これは、元のリストおよび製品設定からの割引価格に関係なくBUSINESS INTERACTION ITEMに請求される実際の価格です。 関連付けられたPMP価格で評価されるBUSINESS INTERACTION ITEMに関連付けられている金額。 |
|
|
リファレンス |
住所に割り当てることができるBUSINESS INTERACTION ROLE。例:
|
|
|
ベース |
支払いとBUSINESS INTERACTION間の関連付け。たとえば、契約または顧客注文の支払いです。 |
|
|
リファレンス |
PARTYまたはリソースなどの他のビジネス対話要素で使用できる役割。 |
|
|
ベース |
BUSINESS INTERACTIONのステータス履歴。例:
|
|
|
検索 |
BUSINESS INTERACTIONのステータスが変化した理由の説明。 |
|
|
検索 |
使用可能なBUSINESS INTERACTIONステータス・タイプおよび説明の参照。例:
|
|
|
検索 |
BUSINESS INTERACTIONのタイプ。例:
|
|
|
リファレンス |
異なるインスタンスのElementSpecificationsを区別する機能を表します。その他または元と異なる特定の形式または種類のElementSpecificationを表します。形式は、新しいElementSpecificationを作成するほどではない、この特定のElementSpecificationの特性を示す属性、方法、リレーションシップまたは制約の違いを表します。 |
|
|
検索 |
法人の法的立場。たとえば、公開会社、非公開会社など。 |
|
|
リファレンス |
業務カレンダの1か月を定義します。 |
|
|
リファレンス |
業務カレンダの四半期を定義します。 |
|
|
リファレンス |
組織内の事業単位への職種の割当て。 |
|
|
リファレンス |
事業単位に関連付けられる交代勤務。これらの交代勤務時間の割当てのために従業員の職種にマップされます。 |
|
|
リファレンス |
業務カレンダの週を定義します。 |
|
|
リファレンス |
業務カレンダの年を定義します。 |
|
|
リファレンス |
導体またはファイバのコンテナ。2つ以上のコネクタがケーブルに接続されます。 |
|
|
リファレンス |
EQUIPMENT INSTANCEのサブタイプ。通信サービス・プロバイダのネットワークに接続された顧客サイトにインストールされたすべてのケーブル・モデム・インスタンスを集めます。 |
|
|
リファレンス |
グレゴリオ暦または通常のカレンダの半月を定義します。 |
|
|
リファレンス |
グレゴリオ暦または通常のカレンダの半年を定義します。 |
|
|
リファレンス |
グレゴリオ暦または通常のカレンダの月を定義します。 |
|
|
リファレンス |
グレゴリオ暦または通常のカレンダの四半期を定義します。 |
|
|
リファレンス |
グレゴリオ暦または通常のカレンダの週を定義します。 |
|
|
リファレンス |
グレゴリオ暦または通常のカレンダの年を定義します。 |
|
|
検索 |
コール・カテゴリの参照。例: データ、Faxまたは音声。 |
|
|
リファレンス |
通信事業者またはプロバイダのコール・センターを定義します。 |
|
|
リファレンス |
コール・センター・エージェント。 |
|
|
検索 |
コール・センター・エージェントのタイプの参照。例: 従業員またはIVR。 |
|
|
導出 |
コール・センターからのカスタマ・コール統計の日次集計。コールの時間、通話時間、サブスクライバまたは非サブスクライバのコール、コールの方向でカスタマ・コールを分析します。 |
|
|
集計 |
コール・センターのカスタマ・コール統計の月次サマリー。 |
|
|
導出 |
コール・センターで開始または解決されたすべてのケースの統計。例:
|
|
|
集計 |
コール・センターで開始または解決されたすべてのケースの統計の月次サマリー。 |
|
|
検索 |
コール・センターからのケース・タイプをさらに詳しく描写するための参照。ケースのサブタイプにより、特定のケース・タイプを様々なサブタイプに分類できます。たとえば、ケース・タイプが「Srv: サービス要求」の場合、サブタイプは「パッケージ・アップグレード」、「パッケージ・ダウングレード」、「簡単な契約更新」、または「オンサイト・サポート」として分類できます。 |
|
|
検索 |
CALL CENTER CASE SUB TYPEをさらに分類します。たとえば、「サービス要求」および「テクニカル・サポート」というコール・センター・ケース・タイプには、コール・センターのケースに次のようなタイトルを付けることができます。
|
|
|
検索 |
コール・センターのケース・タイプの参照。例:
|
|
|
リファレンス |
コール・センターで処理できる言語、製品または地理的な領域をCALL CENTERに割り当てます。 |
|
|
検索 |
着信か発信かを示します。 |
|
|
リファレンス |
電話サービスの一種。受信側が通話中の場合、発信側は電話を切らずに待つことができます。 |
|
|
検索 |
三者通話やユーザー定義の特殊な通話など、その他の通話の特性を記録します。 |
|
|
検索 |
通話中に音声搬送チャネルがリサイクルされる理由の参照。 |
|
|
検索 |
通話ルートの定義の参照。例:
|
|
|
検索 |
通話で使用できるサービス・タイプの参照。例:
|
|
|
リファレンス |
エンティティは、任意の発信元と発信先の組合せに関連付けられた使用可能なすべてのゾーンを表します。これらの通話の発信元または発信先は、市内通話、国内長距離通話、内線通話などの様々なグループに通話を分類します。 注意: このエンティティの目的は、A-B番号マッピングを再現することではありません(これは請求処理です)。このエンティティは、そのようなマッピングの結果のみを表します。 |
|
|
検索 |
様々な理由または原因によって通話を成功または失敗に分類するための参照。通話の成功と失敗は、通話の方向とともに、ローミングでの通話に必要な分析に役立ちます。 |
|
|
検索 |
通常の料金に加算される追加の料金。 |
|
|
検索 |
通話の終了理由の参照。例:
|
|
|
検索 |
通話カテゴリを通話タイプにさらに分類します。例:
|
|
|
リファレンス |
||
|
リファレンス |
キャンペーンとは、特定のマーケティング・コミュニケーション・プログラムのコミュニケーション戦略全体です。マーケティング・コミュニケーション・プログラムでは、多くの場合、プロモーション・イベントおよび個々のプロモーションを支援しますが、独立している可能性があります。キャンペーンは常にMEDIA OBJECTに関連付けられます(テレビ・キャンペーンなど)。 |
|
|
リファレンス |
CAMPAIGNを顧客に公開するチャネル。たとえば、新聞を発行するニュースグループまたはメディア企業、テレビ局など。 版/溝で用紙に印刷された1枚の新聞紙は出版物/メディア・オブジェクトです。 キャンペーン・チャネルは、CAMPAIGN CHANNEL TYPEで分類できます。 |
|
|
リファレンス |
任意のCAMPAIGN CHANNELに対して起動するCAMPAIGNを定義する割当て。 |
|
|
検索 |
キャンペーン・チャネル・タイプの参照。例: 新聞、テレビ、雑誌。 |
|
|
リファレンス |
CAMPAIGNの特性品質または特殊機能。特性は、プレス・リリースの数などの個々の値、50,000 - 100,000に達する見込み客の数などの一定範囲の値を取得したり、証券会社の顧客の数 = すべての証券会社インスタンス特性の合計などの式から導出したりできます。 |
|
|
リファレンス |
CAMPAIGN CHARACTERISTICに割り当てることができる数値またはテキスト。 |
|
|
ベース |
||
|
リファレンス |
キャンペーン活動中に提供される顧客ドキュメント。 |
|
|
リファレンス |
CAMPAIGNの管理に関するキャンペーン・パーティ・ロールの履歴。この場合、パーティは、TELCOオペレータで販売またはマーケティングを担当する従業員だけでなく、キャンペーン・パートナである可能性もあります。 |
|
|
リファレンス |
CAMPAIGN中に放送または送信されたメッセージに関する詳細。 |
|
|
ベース |
メッセージの独創的なコンテンツに関する情報。 |
|
|
リファレンス |
CAMPAIGNの実行メッセージの表現方法に関する詳細。 |
|
|
検索 |
キャンペーンの目的のタイプの参照。例:
|
|
|
リファレンス |
2つのCAMPAIGN間のリレーションシップを定義します。例:
|
|
|
検索 |
CAMPAIGNのステータス。 |
|
|
リファレンス |
特定のキャンペーンの期間値。 |
|
|
検索 |
キャンペーンのタイプの参照。例:
|
|
|
導出 |
顧客の料金請求方式/パッケージの変更に関する計算された詳細な情報。 通常、プリペイドの顧客の場合は、顧客を特定できないため、製品間の顧客の移動を追跡できません。一部の顧客は、次の「月初め」に変更する可能性があります。 |
|
|
集計 |
すべての顧客に関する料金請求方式またはパッケージの計画的変更の月次サマリー。 通常、プリペイドの顧客の場合は、顧客を特定できないため、製品間の顧客の移動を追跡できません。 |
|
|
リファレンス |
これは、PHYSICAL CAPACITYおよびLOGICAL CAPACITYの親である抽象ベース・エンティティです。これらのエンティティは、別のエンティティの最小および最大の要件、制限または他の可変的な機能を定義します。 |
|
|
リファレンス |
SLOTにプラグインできる物理コンテナのタイプを表します。カードは、ネットワーク・カードなどの主要な機能または別のカードをサポートするメモリー・カードなどの補助機能を表す場合があります。このタイプのすべてのオブジェクトは、電気信号および光信号を送信できます。また、カードは、チップやカードなどの他のタイプの管理物理要素のマウント・ポイントも提供します。 |
|
|
リファレンス |
この関連性エンティティは、カード上のカード集計のセマンティクスを表します。カード・リレーションシップは、CARDのマウント方法または別のCARDへのプラグイン方法を示す属性を定義します。 |
|
|
リファレンス |
GSMなどのワイヤレス・ネットワーク内のセルは、BASE TRANSCEIVER STATION (BTS)によってサービスされる領域です。 |
|
|
検索 |
セルの機能停止が発生する理由の参照。例:
|
|
|
リファレンス |
ほとんどのセルは、効率を高めてより多くの通話を処理できるように、セクターまたは個別領域に分割されます。セル・サイト機器は、各セクターに独自のチャネル・セットを提供します。 |
|
|
リファレンス |
基地局の無線装置およびアンテナが配置される場所。セル・サイトは、セルの無線カバレージを提供します。 |
|
|
ベース |
COSTのサブタイプで、CELL SITEに適用される。例:
|
|
|
検索 |
CELL SITEのタイプの参照。セル・サイトのタイプは、たとえば、GSM/CDMA/PHS/ブロードバンド/有料テレビ放送によって分類されます。 |
|
|
導出 |
セル・レベルで取得されるネットワーク・パラメータおよびランタイム統計。 |
|
|
集計 |
月別および一定の地理レベルで集計される、すべてのCELL SITEのネットワーク・パラメータおよびランタイム統計。 |
|
|
検索 |
すべての可能なセル・タイプの参照。たとえば、マクロ、マイクロおよびピコ:
|
|
|
リファレンス |
CFSタイプ集計のリレーションシップを定義します。特に、アプリケーションを使用して、特定のタスクに対して適切なこのCUSTOMER FACING SERVICEタイプのバージョンのセットを定義できます。 |
|
|
検索 |
顧客の料金表変更の変更内容の提案者の参照。例:
|
|
|
リファレンス |
販売またはサービスの目的で電話会社プロバイダと顧客が交流するすべてのチャネルを示します。 |
|
|
ベース |
COSTのサブタイプ。特定の販売チャネルに特に関連のあるすべてのコストを集めます。 |
|
|
検索 |
チャネルの機能により定義されたチャネル・タイプの参照。例:
|
|
|
リファレンス |
シャーシは、その他の管理対象の物理エンティティを収める保護ホルダーで、デスクトップやネットワーク・デバイスなど、それ自体に限定される機能を提供します。たとえば、ルーターやスイッチなどがあります。 |
|
|
リファレンス |
ラックのシャーシ集計のセマンティクスを表します。RACKに配置されているCHASSISの場所を定義するため、位置と場所の2つの属性を定義します。 |
|
|
導出 |
各アカウントに関する月次統計で、チャーン予測マイニング・モデルのトレーニング用資料としての役割を果たします。 |
|
|
検索 |
アカウントのチャーン理由の参照。 |
|
|
検索 |
回路のタイプを分類するカテゴリの参照。例:
|
|
|
リファレンス |
各回路の各コンポーネントの説明。通常、回路には複数のコンポーネントが含まれます。たとえば、2つの顧客サイトをリンクするデジタル・データ・サービス回路には、次の3つのコンポーネントが含まれます。
2つのシナリオがあります:
2つのスイッチをリンクする最初のシナリオでは、switch_idおよびsecondary_switch_id属性が2つのスイッチを識別します。site_id属性はNULLです。 回路コンポーネントがスイッチと顧客サイトをリンクする場合は、switch_id属性がスイッチを識別し、site_id属性が顧客サイトを識別します。secondary_switch_id属性はNULLです。 |
|
|
ベース |
回路を別の事業者に賃貸し、毎月または固定の収入を得るビジネス行為。 |
|
|
検索 |
賃貸イベントのタイプの参照。例:
|
|
|
ベース |
各CIRCUIT COMPONENTの一定期間のトラフィック量の統計。期間は実装ごとに異なりますが、通常は時間単位です。 |
|
|
検索 |
詳細な回路タイプの参照。例: 相互接続の場合:
ADSL顧客接続の場合:
|
|
|
リファレンス |
このエンティティは、管理エンティティ・オブジェクトのコレクションを表します。コレクションは、一般的な属性、方法、リレーションシップおよび他のセマンティクスを様々なタイプの管理エンティティ・オブジェクトのコレクションに適用できます。コレクションのサブクラスで絞り込むことができます。 |
|
|
リファレンス |
金融協定に従って事業者のかわりに顧客債務を回収するPARTYのサブタイプ。例:
|
|
|
導出 |
特定期間における製品およびサービスの販売により、販売代理店に与えられるすべての手数料の統計。 |
|
|
集計 |
特定期間における製品およびサービスの販売により、販売代理店に与えられるすべての手数料の月次集計。 |
|
|
検索 |
販売代理人に支払われる手数料のタイプの参照。例:
|
|
|
リファレンス |
固定回線電話、携帯電話などを含む製品のサービス・タイプ。 |
|
|
リファレンス |
COMPETITOR INTELLIGENCEの特性品質または特殊機能。特性は、プレス・リリースの数などの個々の値、MARKET SEGMENT内の顧客の数(50,000 - 100,000)などの一定範囲の値を取得したり、MARKET SEGMENTで提供された製品の数 = MARKET SEGMENTに関連付けられているCOMPETITORの製品インスタンスの数などの式から導出したりできます。 |
|
|
リファレンス |
COMP INTEL CHARACTERISTICに割り当てることができる数値またはテキスト。 |
|
|
リファレンス |
COMPETITORが製品を利用可能にするMARKET SEGMENT。 |
|
|
リファレンス |
COMPETITOR PRODUCT CORRELATIONの特性品質または特殊機能。特性は、地理的な支払い(中央、国、カスケード)などの個々の値を取得できます。特性は、一定範囲の値($500,000 - $1,000,000の競合他社製品の収益など)を取得したり、式(相関のMARKET SEGMENTの数 = この相関に関連するMARKET SEGMENTの数など)から導出したりできます。 |
|
|
リファレンス |
COMP PROD CRRL CHARACTERISTICを関連するCOMPETITOR INTELLIGENCE特性に割り当てます。 |
|
|
リファレンス |
2つのCOMP PROD CRRL CHARACTERISTIC間のリレーションシップを定義します。 |
|
|
リファレンス |
COMP PROD CRRL CHARACTERISTICに割り当てることができる数値またはテキスト。 |
|
|
リファレンス |
サイズ別、提供された製品ラインなどのCOMPETITORの分類。 |
|
|
リファレンス |
MARKET SEGMENTの企業のPRODUCTに類似したPRODUCTを提供するPARTY。 |
|
|
リファレンス |
COMPETITORの計画および活動に関して収集したファクト。これらのファクトは、COMPETITOR SWOT分析を実行してCOMPETITORの理解を深めます。 |
|
|
リファレンス |
||
|
リファレンス |
COMPETITORが位置するMARKET SEGMENT。 |
|
|
リファレンス |
COMPETITORが位置するMARKET SEGMENTの強み、弱み、機会または脅威を指定します。 |
|
|
リファレンス |
企業のPRODUCTとCOMPETITORの製品の比較またはリレーションシップ。相関情報には、MARKET SEGMENT、製品ライフ・サイクル段階、管轄区域または定義可能なCOMP PROD CRRL CHARACTERISTICが含まれる場合があります。 |
|
|
リファレンス |
COMPETITORと比較する場合の一般的な(MARKET SEGMENT固有ではない)強み、弱み、機会または脅威。 |
|
|
リファレンス |
サイズ別、提供された製品ラインなどのCOMPETITORの分類。 |
|
|
リファレンス |
複合体住所は、複合体(GEOGRAPHY COMPLEX)の内部住所を記述します。たとえば、敷地内道路や建物番号などです。 |
|
|
リファレンス |
価格の単一の要素を表す製品価格の一部。 |
|
|
リファレンス |
コンポジットまたはアトミックCOMP INTEL CHARACTERISTICの可能性がある他のCOMP INTEL CHARACTERISTICを集計して形成されるCOMP INTEL CHARACTERISTICのタイプ。 |
|
|
リファレンス |
別の新しい評価計画を形成する評価計画のグループを表すPRODUCT RATING PLANの特別なタイプ。 |
|
|
リファレンス |
各COMPOSITE PRODUCT RATING PLANが含むPRODUCT RATING PLANのリレーションシップを定義します。 |
|
|
リファレンス |
新しいサービスを形成するサービスのグループ。 |
|
|
リファレンス |
COMPOSITE SERVICEとアトミック・サービス間のリレーションシップを定義します。コンポジット・サービスを含むと、COMPOSITE SERVICEの形成方法が定義されます。 |
|
|
リファレンス |
各コンポジット・サービス・タイプが含むアトミック・サービス・タイプのリレーションシップを追跡します。 |
|
|
リファレンス |
部分で構成される製品価格。部分は、他のコンポジット製品価格またはコンポーネント製品価格である場合があります。 |
|
|
リファレンス |
これは、本質的に管理可能でPRODUCTを形成するすべてのコンポジット・エンティティの抽象ベース・エンティティです。 ネットワーク要素とCOMPOUND ELEMENTの主な違いは、ネットワーク要素が物理エンティティまたは論理エンティティのいずれかを示すことです。対照的に、COMPOUND ELEMENTは、他の管理エンティティのコレクションである管理エンティティを示します。つまり、COMPOUND ELEMENTの一部である各管理エンティティをPHYSICAL ELEMENTまたはLOGICAL ELEMENTとして個々に管理できます。 |
|
|
リファレンス |
個々に管理できるエンティティ。 複合要素コレクションは、NETWORK ELEMENTおよびオプションで複合要素コレクション・エンティティを構成する集計エンティティです。そのため、複合要素コレクションは、管理エンティティを集合的に表す一連のPHYSICAL ELEMENTおよびLOGICAL ELEMENTを表します。たとえば、ネットワークは複合要素コレクションのサブクラスです。ネットワークは、他のネットワークおよびサブネットワークで構成できます。各ネットワークまたはサブネットワークは、要素コレクションで収集および表現される物理コンポーネントおよび論理コンポーネントで構成できます。ネットワークの各ノードは、NETWORK ELEMENTで表すことができます。 |
|
|
リファレンス |
COMPOUND ELEMENTをCOMPOUND ELEMENTに集計するセマンティクスを定義します。 |
|
|
リファレンス |
COMPOUND ELEMENT集計のセマンティクスを定義します。サブクラスのみインスタンス化する必要があるため、複合要素詳細は抽象的です。この特定のCOMPOUND ELEMENTへのPHYSICAL ELEMENT、LOGICAL ELEMENTおよびCOMPOUND ELEMENTの集計を表すために使用される、このクラスの3つの具体サブクラスがあります。 |
|
|
リファレンス |
これは、COMPOUND ELEMENTにLOGICAL ELEMENTを集計するセマンティクスを定義する具体エンティティです。 |
|
|
リファレンス |
これは、COMPOUND ELEMENTにPHYSICAL ELEMENTを集計するセマンティクスを定義する具体エンティティです。 |
|
|
リファレンス |
このエンティティは、PHYSICAL ELEMENT ROLEとLOGICAL ELEMENT ROLEの対話で定義される役割です。複合要素役割を形成するには、少なくとも1つ以上のPHYSICAL ELEMENT ROLEおよび1つ以上のLOGICAL ELEMENT ROLEが必要です。ただし、PHYSICAL ELEMENT ROLEおよび論理要素役割は、複合要素役割に属さないようにする必要があります。 |
|
|
リファレンス |
COMPOUND ELEMENTとネットワーク要素役割の間のリレーションシップを実装します。 |
|
|
リファレンス |
COMPOUND ELEMENTとネットワーク要素役割の間のリレーションシップを実装します。 |
|
|
リファレンス |
これは、COMPOUND ELEMENTの不変的な特性および動作、属性、方法、制約およびリレーションシップを定義する抽象ベース・エンティティです。複合要素仕様およびPHYSICAL ELEMENT SPECまたはLOGICAL ELEMENT SPECのいずれかの主な違いは、PHYSICAL ELEMENT SPECおよびLOGICAL ELEMENT SPECでPHYSICAL ELEMENTおよびLOGICAL ELEMENTの不変的な特性および動作を指定するテンプレートをそれぞれ定義することです。一方、複合要素仕様は、1つ以上のPHYSICAL ELEMENT SPECおよび1つ以上のLOGICAL ELEMENT SPECを含むテンプレートを示します。オプションで、1つ以上の複合要素仕様が指定される場合もあります。そのため、複合要素仕様は、補完するPHYSICAL ELEMENT SPECおよびLOGICAL ELEMENT SPECを指定するための実質上の「簡潔表記」です。 |
|
|
リファレンス |
このエンティティは、COMPOUND ELEMENTオブジェクトを作成する特定の属性、動作、リレーションシップ、制約およびセマンティクスを示します。このエンティティの目的は、他のタイプの要素仕様と区別してCOMPOUND ELEMENTの仕様を追跡することです。このエンティティは要素仕様の変更集計を継承するため、対応するCOMPOUND ELEMENTエンティティとともに使用できます。COMPOUND ELEMENT SPECおよびPHYSICAL ELEMENT SPECまたは論理要素タイプのいずれかの主な違いは、PHYSICAL ELEMENT SPECおよび論理要素タイプでPHYSICAL ELEMENTおよびLOGICAL ELEMENTの不変的な特性および動作を指定するテンプレートをそれぞれ定義することです。一方、COMPOUND ELEMENT SPECは、1つ以上のPHYSICAL ELEMENT SPECおよび1つ以上の論理要素タイプを含むテンプレートを示します。オプションで、1つ以上のCOMPOUND ELEMENT SPECが指定される場合もあります。複合要素仕様アトミック・エンティティとCOMPOUND ELEMENT SPEC COMPOSITEエンティティの違いは、複合要素仕様アトミック・エンティティがスタンドアロン・エンティティとして設計されていることです。 (1つ以上のPHYSICAL ELEMENT SPECおよび1つ以上の論理要素タイプを引き続き集計しますが、結果としてこの複合要素仕様アトミック・エンティティをそれ自体で使用できます。一方、COMPOUND ELEMENT SPEC COMPOSITEエンティティは、1つ以上のCOMPOUND ELEMENT SPECで構成され、いずれかを複合要素仕様アトミック・エンティティにする必要があります。 |
|
|
リファレンス |
このエンティティは、コンポジットCOMPOUND ELEMENTオブジェクトを作成する特定の属性、動作、リレーションシップ、制約およびセマンティクスを示します。このエンティティの目的は、他のタイプの要素仕様と区別してCOMPOUND ELEMENTの仕様を追跡することです。 このエンティティは要素仕様の変更集計を継承するため、対応するCOMPOUND ELEMENTエンティティとともに使用できます。COMPOUND ELEMENT SPECおよびPHYSICAL ELEMENT SPECまたは論理要素タイプのいずれかの主な違いは、PHYSICAL ELEMENT SPECおよび論理要素タイプでPHYSICAL ELEMENTおよびLOGICAL ELEMENTの不変的な特性および動作を指定するテンプレートをそれぞれ定義することです。一方、COMPOUND ELEMENT SPECは、1つ以上のPHYSICAL ELEMENT SPECおよび1つ以上の論理要素タイプを含むテンプレートを示します。オプションで、1つ以上のCOMPOUND ELEMENT SPECが指定される場合もあります。COMPOUND ELEMENT SPEC ATOMICエンティティと複合要素仕様コンポジット・エンティティの違いは、COMPOUND ELEMENT SPEC COMPOSITEエンティティがスタンドアロン・エンティティとして設計されていることです。(1つ以上のPHYSICAL ELEMENT SPECおよび1つ以上の論理要素タイプを引き続き集計しますが、結果としてこのCOMPOUND ELEMENT SPEC ATOMICエンティティをそれ自体で使用できます。一方、複合要素仕様コンポジット・エンティティは、1つ以上のCOMPOUND ELEMENT SPECで構成され、いずれかをCOMPOUND ELEMENT SPEC COMPOSITEエンティティにする必要があります。 |
|
|
リファレンス |
TERMINATION POINTとCOMPOUND ELEMENTをリンクする具体エンティティ。たとえば、依存性およびTERMINATION POINTと他のTERMINATION POINTの対話方法でこの特定の要素ポートを構成するTERMINATION POINTの特性および動作を示します。 |
|
|
リファレンス |
要素単位は、個別に管理できるエンティティです。複合要素単位は、管理要素の物理的および論理的な側面で構成される集計エンティティです。たとえば、ROUTERは要素単位です。異なるPHYSICAL ELEMENTオブジェクトは、ROUTERの物理的な側面を詳細にモデル化できます。たとえば、CARD、各CARDのPHYSICAL PORTの数値およびタイプなどがあり、異なるLOGICAL ELEMENTオブジェクトはROUTERの論理的な側面を詳細にモデル化できます(たとえば、未処理の障害またはアラームがある場合の実行中のソフトウェア、現在有効なタイプのDEVICE INTERFACEの数などがあります)。リソース要素は、すべてのPHYSICAL ELEMENTおよびLOGICAL ELEMENTオブジェクトを集計して、提供される要素の物理的および論理的な側面の高度な表示を可能にします。 |
|
|
導出 |
1日当たりのネットワーク上のACCESS METHODごとのすべての接続および切断に関する統計。このエンティティはネットワーク使用量またはトラフィックに関連があります。このエンティティは特定のサービスへの「サブスクリプション」のカウントとは関連がありません。 |
|
|
集計 |
1日当たりのネットワーク上のすべての接続および切断の月次集計。ネットワーク使用量またはトラフィックの分析。 |
|
|
リファレンス |
これは、CONNECTION TERMINATION POINT間の情報の透過的な転送を行う管理オブジェクトのクラスです。接続はトレイルのコンポーネントです。複数の接続を上位の評価トレイルにバンドルできます。トレイルを形成するため、一連の1つ以上の接続がリンクします。接続は一方向または双方向になる場合があります。 |
|
|
リファレンス |
これはネットワーク接続の実際または将来のエンド・ポイントです。たとえば、物理リンクの論理チャネルまたはタイムスロットを表すことができます。すべてのPHYSICAL PORTを少なくとも1つのタイプのCTPに接続します。 |
|
|
リファレンス |
PERFORMANCE CONSEQUENCEの一部として発生する通信。レスポンスを予期しないため、通知は一般的に一方向です。たとえば、違反したPERFORMANCE OBJECTIVEの結果としてアラートが発生します。 |
|
|
リファレンス |
PERFORMANCE CONSEQUENCEの一部として発生する通信(通知)を定義する不変的な特性。レスポンスを予期しないため、通知は一般的に一方向です。たとえば、違反したPERFORMANCE OBJECTIVEの結果としてアラームが発生する場合があります。 |
|
|
リファレンス |
CAMPAIGNのための見込みおよび既存のCUSTOMERのリスト。連絡先リストは、マーケティング活動、特定のモデルの実行、または別の組織から取得して、電話会社によって作成されます。 |
|
|
検索 |
CONTACT LISTの変更について使用可能な理由の参照。 |
|
|
ベース |
COSTのサブタイプ。指定されたCONTACT LISTに適用されます(通常、連絡先リストの購入および管理に関連するコスト)。 |
|
|
検索 |
CONTACT LISTの反復についての分類。例:
|
|
|
検索 |
連絡先個人が担当者とのリレーションシップで果たすことができる様々な役割を示します。 |
|
|
リファレンス |
事業者のネットワークを通じて顧客に提供するすべてのダウンロード可能なコンテンツを保持します。例:
|
|
|
ベース |
コンテンツがダウンロードされたEVENT。 |
|
|
リファレンス |
コンテンツのダウンロード/注文の価格。これは個別のコンテンツ・クリップの価格です。コンテンツごとに異なる価格を設定するのではなく、均一料金が設定される場合もあります。この場合、価格情報はPRODUCT RATING PLANにあります。 |
|
|
検索 |
コンテンツの価格設定のタイプの参照。例:
|
|
|
リファレンス |
エンド・ユーザーによって使用されるコンテンツのプロバイダ。ビデオ、オーディオ・クリップまたはテキスト・コンテンツなどがあります。 |
|
|
検索 |
コンテンツのタイプの参照。例:
|
|
|
リファレンス |
通信サービス・プロバイダとアカウントとの間の法的な契約。 |
|
|
ベース |
契約に高いレベルの承認またはレビューが必要な場合、事業者の権限を付与された従業員によるCONTRACTへの承認。 |
|
|
リファレンス |
契約間のリレーションシップを定義します。 |
|
|
検索 |
2つの契約が関連している理由の参照。例: 契約を別の契約に置き換える理由:
契約が別の契約に依存する理由:
|
|
|
検索 |
2つの契約間の割当てのタイプの参照。例:
|
|
|
検索 |
契約変更の開始者の分類の参照。 |
|
|
検索 |
契約変更のすべてのタイプの参照。例:
|
|
|
導出 |
分析の目的のために顧客の現在/将来の契約に関する導出された情報。このエンティティは、変更された契約、現在または将来の契約のみを取得します。 |
|
|
リファレンス |
契約の署名時に顧客が提供した書類。例:
|
|
|
導出 |
分析の目的のために顧客の現在/将来の契約に関する導出された情報。このエンティティには、変更された契約(現在または将来)のみが含まれます。 |
|
|
リファレンス |
||
|
集計 |
分析の目的のために顧客の現在/将来の契約に関する導出された情報。このエンティティには、変更された契約(現在または将来)のみが含まれます。 |
|
|
リファレンス |
契約の製品に関する特別なリンクまたは追加の使用方法への対応。 |
|
|
ベース |
CONTRACTのステータス履歴。 |
|
|
検索 |
契約のステータス変更についての説明の参照。例:
|
|
|
検索 |
CONTRACT STATUSのすべての可能なタイプの参照。例:
|
|
|
検索 |
CONTRACTに付加されるすべての可能な条件の参照。例:
|
|
|
ベース |
CONTRACTに付加される条件の重要性。例:
値は契約の期間に応じて異なります。たとえば、月額料金は最初の6か月間は100、最後の6か月は80である可能性があります。違約金も契約の残りの月数に基づきます。 |
|
|
検索 |
契約のタイプの参照。 |
|
|
リファレンス |
ネットワークのコアのインタフェースであるコア・インタフェースとして機能するDEVICE INTERFACE役割を定義します。この役割の目的は、特定のドメインのすべてのコア・インタフェースで同じ一般的な構成コマンドを受け取るためにPOLICYの定義を有効化することです。 |
|
|
ベース |
追跡可能なレベルの営業やイベントから生じた経費。例:
|
|
|
リファレンス |
コストの配分先となるCOURIERまたはプロバイダのコスト・センター。 |
|
|
ベース |
特定の会計期間における各COST CENTERの予算。 |
|
|
集計 |
顧客にかかる様々な費用の統計。これらの詳細は次のような分析にとって重要です。
|
|
|
導出 |
顧客にかかる様々な費用の月次集計。これらの詳細は次のような分析にとって重要です。
|
|
|
|
集計 |
通信事業者の内部の各事業単位によるすべての費用の月次集計。 |
|
導出 |
通信事業者の内部の各事業単位によるすべての費用の統計。これらの値は監査および予算に役立ちます。 |
|
|
検索 |
費用が生じたすべての可能な理由の参照。例:
|
|
|
検索 |
COST TYPEのさらなる分類の参照。例:
|
|
|
検索 |
コストのタイプの参照。たとえば、CUSTOMER、CHANNEL、COURIERまたはEMPLOYEEのコスト(携帯電話の月々の請求または購入)。 |
|
|
リファレンス |
通信事業会社のクーリエ・サービスを提供するパーティ。 |
|
|
ベース |
||
|
リファレンス |
PRODUCTまたはSERVICEで使用される、CPE(Customer Premise Edge)デバイスの特定の役割を実装するために必要な論理機能を定義します。 |
|
|
リファレンス |
顧客に割り当てられる可能性のある利用可能な信用度カテゴリのリスト。例:
|
|
|
集計 |
すべての顧客の信用度カテゴリの月次集計。 |
|
|
導出 |
月ごとに各顧客に割り当てられる信用度カテゴリ。信用度カテゴリは、信用度カテゴリ・ディメンションで定義されます。 |
|
|
リファレンス |
サービス・プロバイダに対する各顧客の参照財務格付けスコアを提供します。この情報は、「信用格付け機関」とも呼ばれます。 |
|
|
検索 |
取引に使用される通貨の参照。 |
|
|
ベース |
為替レート・タイプおよび受渡し日によって決定される、主要通貨に対する為替レート。 |
|
|
リファレンス |
地理的領域への通貨使用の割当て。 |
|
|
リファレンス |
顧客に関する情報。 |
|
|
導出 |
PRODUCTごとの新規顧客件数の日次集計。 |
|
|
集計 |
PRODUCTごとの新規獲得顧客の月次サマリー。 |
|
|
導出 |
どのCUSTOMERがどのCUSTOMER COMMUNITYに属しているかを定義します。 |
|
|
検索 |
顧客分類コードの参照。例:
|
|
|
リファレンス |
顧客クラスへの顧客の割当て。顧客は、様々な時点での利用状況により、異なる顧客クラスに所属する場合があります。したがって、顧客と顧客クラスは、多対多のリレーションシップです。 |
|
|
リファレンス |
マイニング・アルゴリズムによって識別される顧客コミュニティ。 |
|
|
ベース |
どのCUSTOMERがどのCUSTOMER COMMUNITYに属しているかを定義します。 |
|
|
ベース |
顧客に適用されるCOSTのサブタイプ。たとえば、顧客に贈られたギフトの費用。 |
|
|
集計 |
顧客の詐欺および代金回収の統計。 |
|
|
導出 |
顧客の詐欺および代金回収の月次サマリー。 |
|
|
リファレンス |
CUSTOMER ORDERに用意される様々なタイプの顧客の証拠書類、契約など。 |
|
|
導出 |
各顧客についての顧客機器インストール行為に関する統計。通常、これらの統計には、インターネットおよびテレビ機器のモデム、ルーターまたはDSLボックスが含まれます。 |
|
|
集計 |
各顧客についての顧客機器インストール行為の月次サマリー。通常、これらの統計には、インターネットおよびテレビ機器のモデム、ルーターまたはDSLボックスが含まれます。 |
|
|
リファレンス |
これは、CUSTOMER FACING SERVICEを定義するベース・エンティティです。CUSTOMER FACING SERVICEは、顧客または他の適切なPARTY ROLEで確認される特定のSERVICEの特性および動作を定義する抽象です。そのため、このPARTY ROLEは、このタイプのSERVICEを購入、賃貸、使用するか、直接認識します。これはCUSTOMER FACING SERVICEをサポートするRESOURCE FACING SERVICEと正反対ですが、顧客によって直接確認または購入されません。たとえば、VPNはCUSTOMER FACING SERVICEの例で、VPNを構成するネットワーク・デバイス間の様々なタイプのルーティングを実行するサブサービスはRESOURCE FACING SERVICEの例です。 |
|
|
リファレンス |
CUSTOMER FACING SERVICEの一連のSERVICE ROLEでSERVICEを定義します。このエンティティは、このSERVICEの役割でCUSTOMER FACING SERVICEの可変的な特性を表すSERVICE ROLEを定義します。このエンティティは、SERVICE ROLEを使用してCUSTOMER FACING SERVICEを抽象的に管理できます。また、顧客対応サービス役割は、所有または提供する機能でSERVICEを定義できます。 |
|
|
検索 |
これは、顧客対応サービス仕様を定義するベース・エンティティです。顧客対応サービス仕様は、顧客が確認する特定のCUSTOMER FACING SERVICEの不変的な特性および動作を定義する抽象です。不変的な部分は、この一般的な顧客対応サービス仕様をすべて使用する一連の可変的なCUSTOMER FACING SERVICEを作成する単一の共通基盤として役立ちます。 |
|
|
検索 |
このエンティティは、下位のCUSTOMER FACING SERVICE SPECがないCUSTOMER FACING SERVICE SPECを定義します。つまり、顧客対応サービス仕様アトミックは、スタンドアロンのCUSTOMER FACING SERVICE SPECで、テンプレートとして機能するCUSTOMER FACING SERVICEの不変的な特性(変更されない属性、方法、リレーションシップおよび制約)の定義をサポートするCUSTOMER FACING SERVICE SPECが必要ありません。 |
|
|
検索 |
このエンティティは、顧客がリクエストするSERVICEの要件をまとめて満たすCUSTOMER FACING SERVICEの統合セットを定義します。たとえば、顧客は、それぞれに固有のQoSを持つ一連のSERVICE BUNDLEを定義するSERVICE PACKAGEであるGoldServiceをリクエストする場合があります。SERVICE PACKAGEの一部である個々のCUSTOMER FACING SERVICEをCUSTOMER FACING SERVICE SPECから導出できます。この場合、顧客対応サービス仕様コンポジットは、すべての個々のCUSTOMER FACING SERVICE SPECを単一の名前が付いたオブジェクトに集計します。このオブジェクトはスタンドアロン・オブジェクトです。ただし、他の顧客対応サービス仕様コンポジットやCUSTOMER FACING SERVICE SPEC ATOMICエンティティで構成されます。これがこのエンティティと顧客対応サービス仕様アトミック・エンティティの主な違いです。 |
|
|
リファレンス |
CUSTOMER FACING SERVICEに対して、一連のサービス仕様役割でサービス仕様を定義します。これは、CUSTOMER FACING SERVICEの不変的な特性を表すために使用されるサービス仕様役割を定義するベース・エンティティです。このエンティティは、サービス仕様役割を使用してCUSTOMER FACING SERVICEを抽象的に管理できます。また、顧客対応サービス仕様役割は、所有または提供する機能でサービス仕様を定義できます。 |
|
|
リファレンス |
CUSTOMER FACING SERVICE SPECの履歴バージョンを保持します。 |
|
|
ベース |
顧客サイトでサービスをインストールする活動。例:
|
|
|
ベース |
顧客のための特定機器インスタンスのオン・サイト・インストール。 |
|
|
ベース |
顧客サービスに関する詳細。 |
|
|
ベース |
顧客にオン・サイト・サポートを提供する活動。 |
|
|
検索 |
サービス事業者が定義する基準に基づいて顧客をグループ化するための参照コード。 |
|
|
リファレンス |
サービス事業者が定義する基準に基づいた顧客のグループ化。 |
|
|
リファレンス |
||
|
検索 |
データ・マイニング・モデルから予測される顧客生涯価値のバンド。たとえば、0~100USD、100~200USDなどがあります。 |
|
|
導出 |
チャーンの確立、顧客生涯価値(LTV)マイニング、およびその他の測定値を含むマイニング分析からの結果の測定値。 |
|
|
リファレンス |
顧客が記念して祝うイベント。例:
|
|
|
検索 |
行事タイプの参照。例: 結婚記念日、誕生日、会社の創立記念日など。 |
|
|
ベース |
顧客からの注文。現在、この顧客注文は、ハンドセット、ブロードバンドのインストール要求、またはその他の注文の申し込みができるサービス・プロバイダのショップ・サービスでの注文です。 |
|
|
リファレンス |
CUSTOMER ORDERの送信中に提供されるドキュメント。 |
|
|
ベース |
CUSTOMER ORDERのアイテムに関する詳細。 |
|
|
ベース |
注文明細の現在の状態。 |
|
|
ベース |
CUSTOMER ORDERに適用される支払い。 |
|
|
検索 |
CUSTOMER ORDERに割り当てることができる可能な優先順位の参照。 |
|
|
ベース |
CUSTOMER ORDERの現在の状態。 |
|
|
検索 |
顧客注文の状態および顧客注文明細アイテムの状態が変更されるすべてのタイプの理由。 |
|
|
リファレンス |
CUSTOMER(およびPARTY)のサブタイプ。個人とは対照的に、組織の詳細が含まれます。組織は、一個人のみ(個人事業者など)でも構成できます。 |
|
|
リファレンス |
プライベートとしてみなされる顧客に関する詳細情報。 |
|
|
検索 |
顧客の収入条件での分類が含まれます。例: $100から$200までの小銭を持つ顧客。 |
|
|
リファレンス |
顧客の収入バンドを指定します。 |
|
|
検索 |
顧客が事業者にもたらす収益のタイプの参照。例:
|
|
|
リファレンス |
信用度、行動またはその他の基準に基づいて顧客に割り当てるスコアまたはスコア範囲。例:
|
|
|
リファレンス |
市場または顧客セグメントへの顧客の割当て。 |
|
|
リファレンス |
顧客のプロファイルに使用するセグメンテーション・モデル。例:
|
|
|
検索 |
パーティの対話(電話、電子メール、シンプル・メール)で報告された様々な顧客の感情の参照。この値はテキスト・マイニングに使用できます。例:
|
|
|
リファレンス |
顧客へのSIC/NASICコードの割当て。 |
|
|
リファレンス |
顧客との最初のきっかけまたは接点。例:
|
|
|
検索 |
顧客のタイプの参照。例: 個人または企業。 |
表2-24 エンティティの説明(D～F)
| エンティティ名 | タイプ | 説明 |
|---|---|---|
|
ベース |
データ・サービス・イベント。例:
|
|
|
導出 |
データ使用量の日次集計。 |
|
|
集計 |
データ使用量の月次集計。 |
|
|
リファレンス |
すべてのカレンダの最下位レベルである日を定義します。 |
|
|
リファレンス |
特定の場所で特定の日に実績に影響を与える可能性がある天候および内外の条件。 |
|
|
リファレンス |
日レベルでの今日までの変換の実装方法の記録。 |
|
|
リファレンス |
日の変換。たとえば、昨年の日に対応する今年の日、昨年の日、先月の日などへのマッピングを行います。 |
|
|
リファレンス |
サプライヤから通信プロバイダへの特別な提案。一般に、サービス・プロバイダがサプライヤからより多くの製品またはサービスを購入するように動機付けるための値引き、割引、支払いに関する特別に有利な条件などのインセンティブのことです。 |
|
|
リファレンス |
サービス・プロバイダとの取引の一部として提供される特定の製品またはサービスを識別し、取引コストがどのように処理されるかを定義します。 |
|
|
リファレンス |
サービス・プロバイダとの取引の一部として提供される特定の製品またはサービスを識別し、取引コストがどのように処理されるかを定義します。 |
|
|
リファレンス |
事業者からの製品を販売するPARTY。 |
|
|
リファレンス |
DEALERを割引グループに割り当てます。 |
|
|
検索 |
借金の期間に基づいて借金をグループ分けするための時間範囲。例:
|
|
|
ベース |
組織内の借金取立人によって、不履行の支払いを顧客から回収するための特殊なやりとり。 |
|
|
ベース |
借金の取立てを社外の借金取立て担当者に割り当てます。 |
|
|
ベース |
取立人に送られた取立て任務のグループ分け。 |
|
|
リファレンス |
年齢、収入、教育、収益など、人またはものを認識または定義するために使用する機能または品質。 |
|
|
リファレンス |
DEMOGRAPHIC CHARACTERISTICを定義する単一の値または一定範囲の値。 |
|
|
リファレンス |
値を割り当てることができるユーザー定義の人口統計属性。 |
|
|
リファレンス |
PARTYに関するプロファイル情報のグループ分けに使用される区分領域。例:
およびその他の関連人口統計およびサイコグラフィック。 |
|
|
リファレンス |
事前決定済の条件に基づいた顧客の導出値。 |
|
|
検索 |
CALL SOURCE DESTINATIONに関連付けられた発信先タイプの参照。例:
|
|
|
リファレンス |
これは、デバイスの(論理)インタフェースまたはサブインタフェースを表す具体エンティティです。このエンティティは送信エンティティではありません。むしろ、DEVICE INTERFACEは、デバイスのSERVICEおよびLOGICAL ELEMENTをプログラムするために使用されます。たとえば、デバイス・インタフェースを使用して、デバイスからネットワーク媒体に論理接続をプログラムします。様々なタイプのデバイス・インタフェースは、様々なタイプのネットワーク・メディアに対して存在します。たとえば、このようなメディアをプログラムできるようにネットワークで使用されるATMと比較したIPなどがあります。LOGICAL DEVICEおよびデバイス・インタフェースの組合せは、デバイスで実行するSERVICEを定義するために開発者がプログラムする内容です。 |
|
|
リファレンス |
一般的に、DEVICE INTERFACEを管理する複数の方法があります。最初の違いは管理内容にあります。モデルは、2つのタイプの管理コマンド・カテゴリ、構成および操作を定義します。構成コマンドを使用して、DEVICE INTERFACE(また、複数の特定のDEVICE INTERFACEに影響を与えるコマンドのLOGICAL DEVICE)を構成します。操作コマンドを使用して、ソフトウェア、ネットワーク接続およびデバイス自体を監視およびトラブルシューティングします。 |
|
|
検索 |
任意のDEVICE INTERFACEをサポートできるPHYSICAL PORTを定義します。 |
|
|
リファレンス |
特定のDEVICE INTERFACEに関連付けることができる様々なタイプの役割を表します。 |
|
|
リファレンス |
DEVICE INTERFACEとTERMINATION POINT間のリレーションシップを定義します。 |
|
|
検索 |
現在のステータスが自動引落しによる支払いである様々な理由の参照。例:
|
|
|
リファレンス |
従業員またはパートナが参加する割引グループ。 |
|
|
リファレンス |
SUBSCRIPTIONの値下げの割引。 |
|
|
検索 |
地理的な距離によってネットワーク・イベントの特性を示す距離範囲。 |
|
|
検索 |
メールボックスに通話を転送またはメールボックスから通話を取得するすべての理由の参照。例:
|
|
|
検索 |
通話の転送または通話の取得のタイプの参照。例:
サブスクライバの通話は、サブスクライバの指示または設定により、指定されたボイスメールまたはUnified Messaging Service (UMS)メールボックスに転送されます。たとえば、サブスクライバが通話中か、ハンドセットの電源を切ったか、サブスクライバが電話に出られないとき、通話は転送されます。サブスクライバは後で、指定した番号を通じてメールボックスにアクセスするか、UMSの場合はインターネットを使用して、メールボックスに保存されたすべての通話を取得できます。通話の転送および取得によって生じるすべてのトラフィックは、転送または取得などの通話タイプに基づいて分析されます。Divert Retrieve Typeでは、通話を転送または取得として整理して、この分析の実行に役立ちます。 |
|
|
検索 |
ドキュメント状態のタイプの参照。例:
|
|
|
検索 |
ドキュメント・タイプの参照。例:
|
|
|
検索 |
確認のために顧客がサービス・プロバイダに提供するDOCUMENT TYPEのグループ。例:
|
|
|
リファレンス |
異なるDOCUMENT TYPEを異なるDOCUMENT TYPE GROUPに割り当てます。 |
|
|
リファレンス |
銅線(ルーター)でブロードバンドを実装するxDSLモデム。 |
|
|
リファレンス |
ネットワークの境界のインタフェースであるエッジ・インタフェースとして機能するDEVICE INTERFACE役割を定義します。この役割の目的は、特定のドメインのすべてのエッジ・インタフェースで同じ一般的な構成コマンドを受け取るためにPOLICYの定義を有効化することです。 |
|
|
検索 |
顧客に割り当てられる人口統計学的な教育レベル。 |
|
|
リファレンス |
要素仕様の特性品質または特殊機能。特性は、色などの個々の値、100-240mVの感度などの一定範囲の値を取得したり、使用時間(時) = 30 - 会話時間*3などの式から導出したりできます。色などの特定の特性は、注文や他のプロセスの途中で構成される場合があります。 |
|
|
リファレンス |
追加プロパティ(属性)が要素仕様特性に含まれる類似したプロパティのプロパティを適用またはオーバーライドするサービス仕様による要素仕様特性の使用。 |
|
|
リファレンス |
要素仕様特性の間の集計、移行、置換、依存性または排他性のリレーションシップ。 |
|
|
リファレンス |
要素仕様特性に割り当てることができる数値またはテキスト。 |
|
|
リファレンス |
追加プロパティ(属性)が要素仕様特性値に含まれる類似したプロパティのプロパティを適用またはオーバーライドするエンティティ仕様による要素仕様特性値の使用。 |
|
|
リファレンス |
要素仕様特性値の間の集計、移行、置換、依存性または排他性のリレーションシップ。 |
|
|
リファレンス |
CUSTOMERに割り当てられた電子メールのすべてのメールボックスを指定します。 |
|
|
リファレンス |
個人のサブタイプ。プロバイダの従業員。 |
|
|
ベース |
時間給従業員が勤務した交代勤務時間。 |
|
|
ベース |
定額給従業員が勤務した交代勤務時間。 |
|
|
ベース |
従業員に適用されるCOSTのサブタイプ。たとえば、従業員の給与およびボーナス。 |
|
|
検索 |
従業員の組織に存在する様々な職名。例:
|
|
|
リファレンス |
EMPLOYEEをDISCOUNT GROUPに割り当てます。 |
|
|
ベース |
経費を請求するために従業員(請負業者を含む)が送信する費用レポート。EMPLOYEE(パーティ)およびPAYMENT CHANNEL(チャネル)は、スーパー・エンティティEVENTによって取得されます。費用送信日はイベント開始日です。 |
|
|
ベース |
各EMPLOYEE EXPENSE REPORTの詳細明細アイテム。 |
|
|
ベース |
特定のEMPLOYEE EXPENSE REPORTの異なる状態。例:
|
|
|
リファレンス |
||
|
検索 |
従業員への職種の割当ての関連性。例: 一次、二次など。 |
|
|
リファレンス |
特にコール・センター担当者および営業担当者について、顧客への応対に従業員が使用できる言語を指定します。 |
|
|
リファレンス |
プライベートとしてみなされるEMPLOYEEに関する詳細情報。 |
|
|
リファレンス |
場所、役割、シフトおよび従業員に関する計画された人材配置スケジュール。 |
|
|
ベース |
従業員が受けたトレーニングのリスト。通常、従業員のトレーニング記録は、特定の製品またはサービスのトレーニングを受けるコール・センター担当者に適用されます。 |
|
|
検索 |
従業員のタイプの参照。例:
|
|
|
リファレンス |
このエンティティは、直接管理できないエンティティを表します。たとえば、ハブなどがあります。 |
|
|
リファレンス |
これは、エンティティの機能を示すエンティティの様々なタイプの役割の概念を定義する抽象ベース・エンティティです。 |
|
|
リファレンス |
これは、別のエンティティの不変的な特性、属性、方法、制約およびリレーションシップを定義する抽象ベース・エンティティです。 |
|
|
リファレンス |
CUSTOMERがサービスのアクセスに使用できるCOURIERによって配送されるか、DEALER店舗で収集されるデバイス。デバイスは、携帯電話、固定回線電話、Fax送受信機などの場合があります。デバイスは顧客に貸与または販売されます。機器エンティティはPRODUCTのサブタイプです。 |
|
|
リファレンス |
機器を保管する施設。 |
|
|
ベース |
COSTのサブタイプ。特定のEQUIPMENT CENTERに特に関連のあるすべての費用の集まり(設備の賃借料、税など)。 |
|
|
リファレンス |
EQUIPMENTの機能。例:
|
|
|
リファレンス |
EQUIPMENTに機能を割り当てます。 |
|
|
リファレンス |
他の物理オブジェクトをホスト、保持または格納できる管理可能な物理オブジェクトを表します。このオブジェクト・クラスのインスタンスで表すことができる物理オブジェクトの例はRACK、CHASSIS、棚およびSLOTです。SLOTやCHASSISなどの機器ホルダのサブクラスとCARDなどのホルダ役割を持つEQUIPMENTのサブクラスの違いは、機器ホルダのサブクラスが他のハードウェアを保存するためにのみ使用されることです。通常拡張のための二次的な機能として保存機能を使用するホルダ役割を持つEQUIPMENTのサブクラス。ただし、主要な機能は他のオブジェクトを保存しません。 |
|
|
リファレンス |
通信の実装。例:
|
|
|
リファレンス |
顧客がEQUIPMENTを賃貸するCONTRACTのサブタイプ。この機器は、引き続きサービス・プロバイダに属します。契約が終了すると、デバイスをサービス・プロバイダに戻す必要があります。例:
|
|
|
ベース |
EQUIPMENT INSTANCEのステータス履歴。例:
|
|
|
検索 |
特定の機器インスタンスのステータス・タイプの参照。例:
|
|
|
リファレンス |
顧客による有形のデバイスの使用を追跡するSUBSCRIPTIONのサブタイプ。 |
|
|
検索 |
(顧客側)機器のタイプの参照コード。例:
|
|
|
ベース |
請求エンジンからのエラーが発生した/リサイクルされた調整済のイベント・レコード。 |
|
|
ベース |
請求エンジンからのエラーが発生した/リサイクルされた評価済のイベント・レコード。 |
|
|
ベース |
調整プロセスからのエラーが発生した/リサイクルされた/拒否されたRAWイベント・レコード。 |
|
|
ベース |
通信サービス・プロバイダとの交流についての記述。イベントには非ネットワーク・イベントのみ(通話データ記録以外)が含まれます。 イベントはプロバイダとの関連において発生する場合があります。たとえば、機器の故障やサービスの途絶などがあります。イベントはCUSTOMERとの関連において発生する場合もあります。たとえば、サービスの注文または料金の支払いなどがあります。 特別なキャンペーンの実行または顧客のコストの分析のために顧客の行動がイベントに格納されます。通常、イベントにはコストが発生し、事業者の収益を生じる場合もあります。 イベントのタイプまたはイベントの交流に特有の情報は、対応するイベント・サブタイプに格納されます。 |
|
|
ベース |
アクセス・メソッド使用の発生。 |
|
|
ベース |
アカウントで発生するイベント。例:
|
|
|
ベース |
一意のイベント間のリレーションシップの説明。 |
|
|
検索 |
2つのEVENT間にリレーションシップが存在するすべての可能な理由の参照。例:
|
|
|
検索 |
2つのEVENT間のすべてのリレーションシップ・タイプの参照。 |
|
|
検索 |
さらにEVENT TYPEにグループ化されるEVENT CATEGORYの参照。例:
|
|
|
ベース |
サービス担当者とCUSTOMER間の対話履歴。 |
|
|
ベース |
サービス担当者とCUSTOMER間の対話履歴詳細。各対話メッセージは1つのレコードとして保存されます。 |
|
|
ベース |
固定回線(ブロードバンドまたは電話回線)のレンタルに対応する「非ネットワーク・イベント」のサブタイプ。通常、レンタルには、様々なタイプの活動の料金が発生します。例:
|
|
|
検索 |
発生する可能性があるEVENTのタイプの分類の参照。例:
|
|
|
ベース |
||
|
ベース |
特定のEVENTに特に関連するCOSTのサブタイプ。通常、このコストは、顧客との対話などの非ネットワーク・イベントに使用されます。たとえば、サービスの問題または故障の後のオンサイト・メンテナンスに使用されます。 |
|
|
リファレンス |
ポリシー・イベント・セットに適用される制約(存在する場合)を決定する式。このエンティティは、このイベントのタイプを識別できる追加のセマンティクスも定義します。 |
|
|
ベース |
従業員への給与支払いイベント(販売手数料を除く)。EVENTのサブタイプ。 |
|
|
ベース |
||
|
ベース |
アカウントまたは請求書に関連する財務イベント。EVENTのサブタイプ。 |
|
|
ベース |
プロバイダの事業に影響を与える可能性がある地理的領域に関するイベント。EVENTのサブタイプ。例:
|
|
|
ベース |
通常製品市場計画プロモーションのため、契約またはサブスクリプションに発生するギフト償還イベント。誤った請求などのイベントで、事業者がギフト・アイテムを引き渡す場合もあります。償還にLOYALTY PROGRAMは含まれません。 |
|
|
ベース |
顧客へのインボイスの配送。例:
|
|
|
リファレンス |
EVENTに住所を割り当てます。 |
|
|
ベース |
顧客ロイヤルティ・プログラムの各イベントまたは取引に関連付けられたイベント。例:
|
|
|
ベース |
EVENT LOYALTY PROGRAMのサブタイプ。ネットワーク使用量、支払いまたはその他のイベントに基づいて、顧客がロイヤルティ・プログラム・ポイント、クレジットを受け取ります。 |
|
|
ベース |
EVENT LOYALTY PROGRAMのサブタイプ。顧客がロイヤルティ・プログラム・ポイント、クレジットを使用して、勘定残高への現金の振込みなどを含むギフト・アイテムの交換、または玩具などのその他の景品と交換します。 |
|
|
ベース |
イベントに1つまたは複数のパーティを割り当てる、多対多のリレーションシップ。 |
|
|
ベース |
顧客との対話または交流。例:
|
|
|
ベース |
EVENT PARTY INTERACTIONのサブタイプ。顧客から受けたすべての電話とその詳細。
|
|
|
ベース |
EVENT PARTY INTERACTIONのサブタイプ。顧客からの電子メールによる対話。 |
|
|
ベース |
単一のEVENT PARTY INTERACTIONで複数のスレッドが検討される場合、この明細アイテムは関連スレッドとその他の情報(アカウントやサブスクリプションなど)をリストします。これは、PARTY INTERACTION THREADとイベント間のM:Mリレーションシップでもあります。 |
|
|
ベース |
EVENT PARTY INTERACTIONのサブタイプ。手紙による顧客との対話。 |
|
|
ベース |
顧客との同じ対話に参加する複数の従業員を追跡します。 |
|
|
ベース |
顧客による店舗への訪問。EVENTのサブタイプ。 |
|
|
ベース |
パーティ・プロファイル情報が変更または更新されたイベント。 |
|
|
リファレンス |
|
|
|
ベース |
PREPAID MOBILE EVENT TYPEアカウントに関連する活動。EVENT ACCOUNTのサブタイプ。例:
|
|
|
ベース |
提供またはPRODUCT PACKAGEに関連するイベント。EVENTのサブタイプ。 |
|
|
検索 |
イベントの理由の参照。例: 滞納 |
|
|
検索 |
イベント理由のカテゴリの参照。カテゴリはさらにイベント理由に細分されます。 |
|
|
リファレンス |
EVENTの解決で発生する可能性がある結果のドメイン。 |
|
|
検索 |
EVENTで使用される可能性がある応答理由の参照。 |
|
|
検索 |
結果または任意のイベントについての記述の参照。例:
|
|
|
ベース |
||
|
ベース |
イベント・ステータスの参照。例:
|
|
|
検索 |
イベント・ステータスの理由の参照。例:
|
|
|
検索 |
EVENT STATUSの参照。例:
|
|
|
ベース |
サブスクリプションに関連するイベント。EVENTのサブタイプ。例:
|
|
|
ベース |
現在のサブスクリプション・ベースへの製品およびサービスの一時的な提供および放棄に関連するイベント。 |
|
|
リファレンス |
各POLICY EVENTのPOLICY RULEの実行、評価を追跡します。 |
|
|
検索 |
イベント・タイプの参照。例:
|
|
|
ベース |
サービスの申込みのためにWebサイトで登録する顧客のイベント。 |
|
|
ベース |
サービス・プロバイダのWebサイトへの顧客の訪問を追跡する顧客の対話イベントのサブタイプ。 |
|
|
リファレンス |
属性exclusionFunctionは、外部管理システムから移入するために設計され、1つ以上の要素ポートを除外する基準を表します。事前定義済の除外機能は、エッジ役割に対する要素ポートの役割を制限します。ただし、このエンティティは、追加機能を使用して要素ポートを除外できます。 |
|
|
ベース |
特定のEMPLOYEE EXPENSE REPORTの異なるPARTYの関与。例:
|
|
|
検索 |
EMPLOYEE EXPENSE REPORTが移行する可能性のあるSTATEのタイプの参照。例:
|
|
|
検索 |
請求される費用のタイプの参照。例:
|
|
|
リファレンス |
顧客の信用価値を定義できる情報のソース。 |
|
|
リファレンス |
特定の顧客の信用プロファイルを提供した外部の代理業者または機関を示します。 |
|
|
導出 |
社外の集金人による毎日の集金。 |
|
|
集計 |
社外の集金人による毎月の集金。 |
|
|
リファレンス |
人口統計情報または顧客情報を取得する情報源。 |
|
|
リファレンス |
国内の競合企業またはローミング・パートナを含め、サービス・プロバイダが取引を行うすべての事業者。 |
|
|
検索 |
外部組織のタイプの参照。 |
|
|
リファレンス |
債権買取会社に関する情報を格納します。債権を保持する金融商品です。 |
|
|
検索 |
ネットワークの障害解決のタイプの参照。 |
|
|
検索 |
障害のタイプの参照。 |
|
|
リファレンス |
FDAはファイバ配線領域です。FDAは、提供される集約ファイバ・ブロードバンドの地理的領域です。提供される各領域は、1つのネットワーク・サイトです。 |
|
|
検索 |
サポート・エンジニアが実行している顧客への対応活動に関する結果タイプの参照。例:
|
|
|
検索 |
サポート・エンジニアが実行できる顧客への対応活動のタイプの参照。例:
|
|
|
リファレンス |
会計年度カレンダの半月を定義します。 |
|
|
リファレンス |
会計年度カレンダの半年を定義します。 |
|
|
リファレンス |
会計年度カレンダの月を定義します。 |
|
|
リファレンス |
会計年度カレンダの四半期を定義します。 |
|
|
リファレンス |
会計年度カレンダの週を定義します。 |
|
|
リファレンス |
会計年度カレンダの年を定義します。 |
|
|
リファレンス |
LOGICAL DEVICEの使用に必要な異なるルーティング機能を抽象化します。これにより、多くの異なる機能セットを持つ(特に)ネットワーク・デバイスのモデル化を簡略化できます。たとえば、ほとんどのルーターでトラフィックのルーティング、転送およびファイアウォールを実行できます。これらの機能を3つの役割にモデル化することで、ルーターによるファイアウォールおよび専用ファイアウォール・デバイスによるファイアウォールの違いを区別するため、ルーター機能が抽象化および分類されます。 |
|
|
リファレンス |
PRODUCTのサブタイプ。固定回線サービスに関する詳細情報を提供します。 |
|
|
ベース |
固定回線電話での通話に関連するイベント。 |
|
|
リファレンス |
顧客に固定回線サービスを提供する電話プラグに関連付けられたポートID。固定回線ポートは、顧客の電話をSWITCHに接続します。 |
|
|
リファレンス |
固定回線のみと関連するPRODUCT RATING PLANのサブタイプ。 |
|
|
リファレンス |
固定回線サービスに関する詳細情報用のSERVICEのサブタイプ。 |
|
|
リファレンス |
すべてのタイプの特性の一般的な構造を提供する抽象エンティティ。すべての様々なタイプの特性を製品、サービス、ネットワーク要素などを含む対象に適用できます。このエンティティは、複雑な機能を持つエンティティに対して追加属性を定義する柔軟な方法を提供します。 |
|
|
リファレンス |
特性を対象に割り当てます。 |
|
|
リファレンス |
ASSIGNMENT TYPEの参照。例:
|
|
|
リファレンス |
特性が別の特性と競合する可能性があるなどの特性間のリレーションシップ。 |
|
|
リファレンス |
FLEXIBLE CHARACTERISTICタイプの参照。 |
|
|
リファレンス |
事前定義済の選択や空いている数値を含む、特性で取得される可能性のある値。 |
|
|
リファレンス |
特性値を適用可能な対象に割り当てます。 |
|
|
リファレンス |
2つの柔軟な特性値の間のリレーションシップ。たとえば、排他性、同一性などがあります。 |
|
|
検索 |
顧客またはディーラーが犯す可能性がある詐欺プロファイルのすべてのクラスの参照。 |
|
|
リファレンス |
FSAM (ファイバ提供領域モジュール)は、FDAの集約です。FSAMは、ほとんどがFTTH (光ファイバ・ブロードバンド)のサービスの事業者により提供される領域のグループです。 |
表2-25 エンティティの説明(G～J)
| エンティティ名 | タイプ | 説明 |
|---|---|---|
|
検索 |
性別の参照。 |
|
|
リファレンス |
GEOGRAPHY HIERARCHYの作成レベル。 |
|
|
リファレンス |
地理で定義される市区町村。 |
|
|
リファレンス |
GEOGRAPHY HIERARCHYの複合体レベルを指定します。複合体には、都市、大学、工業団地などの複数の複合体(限定された領域を形成する少数の建物)が含まれます。 |
|
|
リファレンス |
地理で定義された国。 |
|
|
リファレンス |
地理で定義された郡。 |
|
|
リファレンス |
ユーザー定義のDEMOGRAPHY ATTRIBUTEの分類。 |
|
|
リファレンス |
特定の地理に関する人口統計情報を表すユーザー定義の属性。 |
|
|
リファレンス |
DEMOGRAPHY ATTRIBUTEに対応するユーザー定義の値。 |
|
|
リファレンス |
ユーザー定義の地理的な単位。 |
|
|
リファレンス |
ユーザー定義の階層レベルへのGEOGRAPHY ENTITYの割当て。 |
|
|
リファレンス |
||
|
リファレンス |
ユーザー定義の地理的な階層。 |
|
|
リファレンス |
地理的な階層でのユーザー定義のレベル。 |
|
|
リファレンス |
GEOGRAPHY HIERARCHYレベルをGEOGRAPHY ENTITYに割り当てます。 |
|
|
リファレンス |
GEOGRAPHY HIERARCHY LEVELのユーザー定義の名前および説明。 |
|
|
リファレンス |
GEOGRAPHY LEVELに関連するユーザー定義の属性。 |
|
|
リファレンス |
GEOGRAPHY LEVEL ATTRIBUTEに割り当てられた値。 |
|
|
リファレンス |
GEOGRAPHY HIERARCHYの近所を定義します。 |
|
|
リファレンス |
地理の地域を定義します。 |
|
|
リファレンス |
地理の都道府県を定義します。 |
|
|
リファレンス |
GEOGRAPHY HIERARCHYの市区を定義します。 |
|
|
リファレンス |
地理の小地域を定義します。 |
|
|
リファレンス |
地理の最上位レベル。 |
|
|
導出 |
顧客へのすべての引渡しアイテムの統計。プロモーションでの使用または保存を目的としています。 |
|
|
集計 |
顧客に与えたすべての引渡しアイテムの月次集計。プロモーションでの使用または保存を目的としています。 |
|
|
検索 |
引渡しのタイプの参照。 |
|
|
リファレンス |
GL勘定は、特定の観点から財務ステータスを追跡するために定義されます。すべてのGL仕訳は、各ビジネス取引の財務上の影響を反映するように、様々なGL勘定に転記されます。各勘定は、特定のコードおよびフラグ(勘定が有効であるかどうか、詳細転記または詳細予算が許可されるかどうかなど)によって定義されます。 |
|
|
リファレンス |
勘定階層を作成するために2つのGL ACCOUNT間のリレーションシップを定義します。これは、各集計勘定に関連付けられた明細勘定のリストを格納します。 |
|
|
リファレンス |
GL ACCOUNTの異なるタイプ(現金、銀行、設備など)を定義します。 |
|
|
検索 |
GL ACCOUNTのタイプの参照。例:
|
|
|
ベース |
明細勘定と集計勘定の実績、予算および引当残高を指定します。 |
|
|
リファレンス |
特定のCOST CENTERにGL ACCOUNTをリンクするGL SEGMENTのサブタイプ。 |
|
|
ベース |
仕訳を指定します。 |
|
|
ベース |
仕訳バッチを指定します。 |
|
|
検索 |
仕訳カテゴリの参照。カテゴリの名前と説明を指定します。総勘定元帳の各仕訳には、その目的を識別するために仕訳カテゴリが割り当てられます。例:
|
|
|
ベース |
特定のGL JOURNAL ENTRYによって行われる各GL ACCOUNTの変更を追跡するための仕訳明細を指定します。GL JOURNAL ENTRYと仕訳明細間には1対多のリレーションシップがあります。 |
|
|
ベース |
GL JOURNAL ENTRY LINEとGL SUBLEDGER JOURNAL ENTRY LINE間のリレーションシップを定義します。総勘定元帳の仕訳明細に集計された補助元帳の個々の取引を表します。 |
|
|
リファレンス |
財務システムで定義される元帳および元帳セットに関する情報を定義します。GL元帳は、4C、勘定体系(COA)、機能通貨、会計カレンダおよび会計処理基準によって定義されます。 |
|
|
リファレンス |
勘定体系(COA)を構成するためにGL ACCOUNTをGL LEDGERに割り当てます。 |
|
|
リファレンス |
GL ACCOUNTを対応するORGANIZATION BUSINESS UNITに割り当てます。 |
|
|
リファレンス |
会計カレンダで定義される会計期間に関する情報を指定します。 |
|
|
リファレンス |
GL ACCOUNTを対応するPRODUCTに割り当てます。 |
|
|
リファレンス |
GL ACCOUNTを対応するPROJECTに割り当てます。 |
|
|
リファレンス |
総勘定元帳からのグループまたはカテゴリ。収益に関連するすべての活動を分類します。 |
|
|
リファレンス |
各GL ACCOUNTには、財務システムの設定で指定される少数の独立したセグメントが含まれます。たとえば、通信事業会社は次の形式でGL勘定を設定できます。 <Country, Cost Center, Account, SubAccount> 1 Y3G1 US 1001 2000 2 Y1C1 JP 1001 3000 3 Y2C1 CN 2001 4000 この例の場合、国やコスト・センターなどは、すべて異なるGLセグメントです。勘定科目1001は現金を、2001は銀行を、4000は特定の銀行口座を表します。各GL ACCOUNTは、GLセグメントのサブエンティティを通じて組織事業単位やプロジェクトなどの特定のビジネス・エンティティ(概念)にリンク(ロールアップ)できます。 注意: この説明の勘定(Account)と、顧客アカウントのACCOUNTとを混同しないでください。 |
|
|
検索 |
GL SEGMENTのタイプの参照。例:
|
|
|
リファレンス |
補助元帳を指定し、アプリケーションに応じて変化する元のビジネス取引情報を表します。 |
|
|
ベース |
補助元帳の仕訳を表します。補助元帳の仕訳元帳は、元のレベルで取引を記録してそれが各請求書になりますが、それ以外の場合、各発注書は補助元帳仕訳に1つの項目を含む必要があります。 |
|
|
ベース |
補助元帳の仕訳明細を表します。補助元帳の仕訳ヘッダーと補助元帳間には1対多のリレーションシップがあります。GL補助元帳仕訳明細によって、GL SUBLEDGER JOURNAL ENTRYが異なるGL ACCOUNTに分割されます。 |
|
|
導出 |
GPRS (General Packet Radio Service)のPCU (Packet Control Unit)に関する統計。送信バイト数、受信バイト数、転送データ量など。 |
|
|
集計 |
GPRS (General Packet Radio Service)のPCU (Packet Control Unit)に関する統計値の月次集計。例:
|
|
|
リファレンス |
PRODUCTのサブタイプ。GPRS (General Packet Radio Service)に関する詳細情報。 サービス・プロバイダはGPRSにより、インターネット、WAPなどの様々なサービスを顧客またはサブスクライバに提供します。これらのサービスの使用状況に関する情報は、個別および集計レベルで分析されます。GPRSサービス・ディメンションは、すべてのGPRSサービスを整理します。 |
|
|
導出 |
サブスクライバに提供されるGPRSサービスに関する日別の合計。 |
|
|
集計 |
サブスクライバに提供されるGPRSサービスに関する月別の合計。 |
|
|
ベース |
GPRSセッション・イベントを指定します。これにより、ETSIの定義によるGPRS S-CDRおよびG-CDRで確認されるフィールドのほとんどが説明されます。 |
|
|
リファレンス |
時間の一部としての30分の定義。 |
|
|
リファレンス |
半月レベルの日付変換情報。 |
|
|
リファレンス |
半月についての変換。例:
|
|
|
リファレンス |
半年レベルの累積時間変換。 |
|
|
リファレンス |
半年についての変換。例:
|
|
|
リファレンス |
ハンドセットのインスタンス。 |
|
|
リファレンス |
ハンドセットのモデル。 |
|
|
導出 |
CUSTOMER、SALES CHANNELおよびSALES CHANNEL REPRESENTATIVEによるハンドセット在庫統計の日次集計。 |
|
|
集計 |
SALES CHANNELおよびSALES CHANNEL REPRESENTATIVEによるハンドセット在庫統計の月次サマリー。 |
|
|
導出 |
ギフト、割引またはロイヤルティ・バウチャ・ポイントに関連するハンドセット流通の日別の合計。 |
|
|
集計 |
ギフト、割引またはロイヤルティ・バウチャ・ポイントに関連するハンドセット流通の月別の合計。 |
|
|
リファレンス |
このエンティティは、PHYSICAL LINKまたはPHYSICAL CONNECTORではないアトミック単位として存在するハードウェア・エンティティのタイプを表します。ハードウェアは個々の物理アイデンティティを持つコンポーネントとして定義され、PHYSICAL DEVICEのコンポーネントである可能性があります。保存してラベルを付加できる物理的な表現を持つ場合、オブジェクトは物理アイデンティティを持ちます。そのため、ソフトウェア、ファイル、プロトコルおよびポリシーは物理オブジェクトではありません。 |
|
|
リファレンス |
個々に管理可能でコンポジット(ネスト)機器ホルダを形成しないEQUIPMENTのアトミック・ホルダを表します。各ホルダ・アトミック・オブジェクトはFRUである可能性があります。 |
|
|
リファレンス |
他の機器ホルダ(このエンティティのインスタンスおよびホルダ・アトミック・エンティティ)で構成される機器ホルダを表します。これは、それぞれ個々に管理可能でオブジェクトのセットを全体で管理できる一連のコンポーネントを収集するセマンティクスを提供します。この包含は、ホルダあり集計を使用してモデル化されます。 |
|
|
リファレンス |
顧客アカウント情報をIntelligent Network (IN)またはInternet Multimedia System (IMS)に保持するサーバー。例:
|
|
|
リファレンス |
時間の一部としての1時間の定義。 |
|
|
リファレンス |
各顧客が属する世帯の世帯情報を取得します。 |
|
|
リファレンス |
PRODUCTのサブタイプ。IDDサービスに関する情報を提供します。 |
|
|
ベース |
国際ダイヤル通話(IDD)に関連するイベント。 |
|
|
リファレンス |
通信サービス・プロバイダが運営するIN (Intelligent Network)プラットフォーム。通常、プリペイド携帯電話またはフリーダイヤル・ビジネスはINプラットフォームに依存します。 |
|
|
導出 |
日レベルでのIN PLATFORM機能およびパフォーマンスに関連するパラメータの日別の要約。 |
|
|
集計 |
月レベルでのIN PLATFORM機能およびパフォーマンスに関連するパラメータの月別の要約。 |
|
|
リファレンス |
ネットワークで利用されてINネットワークまたはワイヤレスINネットワーク(INはIntelligent Network)でコール・ルーティングを決定する、VLR、HLRおよびSCPサーバーなどのすべての様々なタイプのデバイスを指定します。 |
|
|
リファレンス |
顧客個人および顧客の世帯に関する人口統計値。 |
|
|
リファレンス |
ユーザー定義のDEMOGRAPHY ATTRIBUTEに割り当てられた値。 |
|
|
リファレンス |
履歴に従って個々のパーティで使用するすべての名前を記録します。 |
|
|
検索 |
イニシアチブのすべての可能な結果の参照。結果の例:
|
|
|
検索 |
イニシアティブ・タイプの参照。 |
|
|
ベース |
顧客請求の分割払い方法。 |
|
|
ベース |
イニシアチブな質問に対応する回答、選択肢の定義。 |
|
|
リファレンス |
プロバイダまたは顧客の交流に使用されるチャネル。例:
|
|
|
検索 |
イニシアチブの方向の参照。例:
|
|
|
リファレンス |
2つの各ナビゲーション・アイテム間のナビゲーション・パス。たとえば、ようこそページからログイン・ページへ、または注目商品ページから特定の製品市場計画宣伝ページへのナビゲーションです。ナビゲーションは、時間の経過に伴って変化する可能性があります(製品が注目商品ページに短い期間のみ掲載されるなど)。 |
|
|
ベース |
各対話コールまたはWeb訪問での顧客ナビゲーション・パスの履歴。たとえば、IVRコールでは、顧客は次のステップを経験します。
これらのアクションは、履歴内で3つのレコードになります。 |
|
|
リファレンス |
顧客がIVRまたはWebサービス・コンテキストで移動する可能性のあるすべての場所を指定します。 |
|
|
検索 |
対話ナビゲーションのタイプの参照。例:
|
|
|
検索 |
アイテムが存在するパス深度に基づいた対話ナビゲーションのレベルの参照。 |
|
|
検索 |
INTERACTION NAVIGATION ITEMのタイプの参照。例:
|
|
|
リファレンス |
INTERACTION NAVIGATION ITEMの履歴バージョン。 |
|
|
検索 |
各EVENT PARTY INTERACTIONに割り当てることができる異なる優先順位の参照。 |
|
|
ベース |
交流の質問にCUSTOMERが提供した応答。 |
|
|
検索 |
交流の理由の参照。例:
|
|
|
検索 |
顧客との対話への反応の参照。例:
|
|
|
検索 |
有効な対話ステータスの参照。例:
|
|
|
ベース |
対話転送の履歴。 |
|
|
検索 |
あるエージェントから別のエージェントに対話が転送される理由の参照。例:
|
|
|
検索 |
会社とCUSTOMERの対話のタイプの参照。例:
|
|
|
導出 |
社内の集金人による支払いおよび集金の日次サマリー。 |
|
|
集計 |
社内の集金人による支払いおよび集金の月次サマリー。 |
|
|
ベース |
NETWORK EVENTのサブタイプ。URLおよび時間の詳細情報を伴う顧客のインターネット検索履歴を取得します。 |
|
|
ベース |
特定の在庫ロケーションに、特定の在庫状態で保管され、特定の収益センターによって制御または管理される特定の在庫ITEMの単位レコードを指定します。 |
|
|
ベース |
アカウントに対して発行される請求書。指定された期間の商品およびサービスに対する支払いを求めます。 |
|
|
ベース |
INVOICEの調整。 |
|
|
集計 |
INVOICEに加えられたすべての調整の計算されたメジャーの月次集計。 |
|
|
導出 |
INVOICEに加えられたすべての調整の計算されたメジャー。 |
|
|
リファレンス |
INVOICE ADJUSTMENTのEMPLOYEEへの割当て数。 |
|
|
検索 |
顧客またはパートナの請求が調整される理由の参照。例:
|
|
|
検索 |
顧客への請求書に適用される有効な調整タイプの参照。例:
|
|
|
集計 |
顧客タイプ・レベルでの後払い顧客へのすべてのINVOICEの月次集計。 |
|
|
リファレンス |
顧客に配送される各請求書のヘッダー、フォントなどを含む形式仕様。 |
|
|
検索 |
顧客へのINVOICEの有効な配送タイプの参照。例:
|
|
|
ベース |
INVOICEに適用される割引。 |
|
|
検索 |
有効な割引理由の参照。 |
|
|
検索 |
顧客への請求書に適用される有効な割引タイプの参照。 |
|
|
導出 |
請求書に関する統計のさらなる集計。 後払いの顧客は、毎月サービスの使用料を請求されます。各サブスクライバに対する請求がパッケージ、カテゴリおよび使用料に基づいて計算され、印刷されて支払いのために顧客アカウントの住所に送られます。 |
|
|
ベース |
顧客が所持する特定の製品コンポーネントに関するINVOICEの明細行。請求書アイテムは、金銭的な料金または払込額に関連するとはかぎりません(ただし、通常では金銭的な料金または払込額が伴います)。通常、請求書アイテムは、特定のアカウントに対する請求可能なアイテムであり、使用量またはその他のイベントの料金が請求されます。請求書アイテムに含まれる請求可能でないアイテムには、ロイヤルティ・ポイント、無償ユニットの金額/繰越などがあります。 例:
|
|
|
ベース |
製品使用量レベルを含む、INVOICE ITEMに関するその他の詳細。 |
|
|
検索 |
請求書アイテムの詳細のタイプの参照(アイテムの詳細は、特定の請求書アイテムの各列の説明です)。携帯電話の請求書アイテムの詳細タイプは分類されています。例:
|
|
|
ベース |
INVOICE ITEM間のリレーションシップを定義します。 |
|
|
検索 |
請求書アイテムのタイプの参照。例:
|
|
|
ベース |
支払いとINVOICEを適合させます。 |
|
|
ベース |
各INVOICEの支払い条件。例:
|
|
|
検索 |
支払い条件の有効なタイプの参照。 |
|
|
ベース |
INVOICEのステータス履歴(たとえば、請求書のステータスはオープンからクローズ済に、またはオープンから延長に変化します)。 |
|
|
検索 |
INVOICEステータスのタイプ。例:
|
|
|
ベース |
INVOICEに適用される税金アイテム。 |
|
|
検索 |
請求書の生成プロセスに応じたINVOICEのタイプの参照。例:
|
|
|
リファレンス |
IPアドレスを表します。IPアドレスは、v4またはv6形式の可能性があり、ドット付き10進数またはCIDRとしてフォーマットできます。1つ以上のホスト別名も指定できます。 |
|
|
リファレンス |
ACCESS METHOD POOLのサブタイプ。顧客が利用可能なすべてのIPアドレスのリスト。 |
|
|
リファレンス |
共通のアドレス・コンポーネントを共有するネットワークの一部分です。TCP/IPネットワークでのサブネットは、同じ接頭辞のIPアドレスを持つすべてのデバイスとして定義されます。たとえば、IPアドレスが100.100.100で始まるすべてのデバイスは、同じサブネットの一部です。 |
|
|
リファレンス |
IPv4に固有のフォーマット機能を追加するため、汎用IP ADDRESSを調整します。 |
|
|
リファレンス |
インターネット・サービス・プロバイダ(ISP)。 |
|
|
リファレンス |
ISPが提供する事業。例:
これにはISP固有の事業のみが含まれます(アプリケーション・プロバイダ事業は含まれません)。 |
|
|
リファレンス |
「事業」リレーションシップによるISPと通信サービス・プロバイダの関連付け。このエンティティは、ISP BUSINESSの、対応するISPとのリレーションシップの定義を割り当てます。 |
|
|
検索 |
高レベルのISPビジネス・タイプの参照。たとえば、Cooper Line Internet Connection (DSL、ISDNとしてさらに分割される)、コロケーション、DNS名など。例:
|
|
|
検索 |
ISPのタイプの参照。 |
|
|
ベース |
インターネット・サービス・プロバイダISPを使用してユーザーが実行する各セッションのトラフィックの詳細を記録します。このエンティティは、接続および切断の日付/時刻、ローカルおよび海外のダウンロード/アップロード・バイト数を記録します。通常、実行時間の長いセッションでは複数の行です。このエンティティは実装に依存しますが、通常、1時間ごとに記録が生成されます。1つのセッションに関する記録はどれも接続および切断日時が同じですが、イベントの開始/終了日時によって使用量(バイト数)がカバーする期間が特定されます。 |
|
|
リファレンス |
インターネット・サービス・プロバイダ(ISP)のサブスクリプションに関連するユーザー名を識別します。 |
|
|
リファレンス |
アイテムまたはPRODUCTの詳細。 |
|
|
検索 |
アイテム(PRODUCT)のタイプの参照。 |
|
|
ベース |
IVR対話ナビゲーション履歴を指定します。 |
|
|
検索 |
IVRナビゲーション・システム全体を構成するために使用できるIVR MENU ITEM。各IVR MENU ITEMは、グループまたは特定のビジネス機能を表します。 |
|
|
リファレンス |
顧客の職業、すなわち、顧客が収入を得るために行う主な活動です。 |
|
|
リファレンス |
従業員に割り当てられる、会社で定義された職種。例:
|
|
|
ベース |
GL SUBLEDGER JOURNAL ENTRY LINEからCUSTOMER ORDER LINE ITEMへの相互参照。 |
|
|
ベース |
表2-26 エンティティの説明(K～N)
| エンティティ名 | タイプ | 説明 |
|---|---|---|
|
リファレンス |
SERVICE(ネットワークまたは非ネットワーク)や同じタイプのSERVICEのグループのある側面のパフォーマンスの尺度。 |
|
|
リファレンス |
製品、サブスクリプションまたはサービスの特定の側面のパフォーマンスの尺度。主要品質指標(KQI)は、KPIを含む、複数のソースから尺度を計算するデータを抽出します。 |
|
|
リファレンス |
ローカル・エリア・ネットワーク(LAN)は、家庭、職場、小規模の建物群などの特定のローカル・エリアを対象とするコンピュータ・ネットワークです。LANは、コンピュータとデバイス間の通信を提供します。 |
|
|
リファレンス |
LANプロトコルは、OSIモデルの最下位の2つのレベル、物理リンクおよびデータ・リンクで動作し、様々なタイプのローカル・エリア・メディアの通信を定義するために使用されます。 |
|
|
検索 |
社内またはCUSTOMERとの対話で使用する言語(口頭または書面)。 |
|
|
リファレンス |
口語または文語の方言の特別なタイプ。 |
|
|
リファレンス |
レイヤー・ネットワークは、情報を転送するために関連付けられる可能性がある同じタイプのアクセス・グループの一式で定義されます。転送される情報はレイヤー・ネットワークの特性で、特性情報と呼ばれます。レイヤー・ネットワークのトレイルを形成するトレイル終了の関連性がレイヤー・ネットワーク管理プロセスで行われて切り離され、接続性が変更される場合があります。個々の論理的に区別されたレイヤー・ネットワークは、各トレイル終了タイプに対して存在します。レイヤー・ネットワークのトポロジは、アクセス・グループ、サブネットワークおよびそれらのリンクによって示されます。 |
|
|
検索 |
パーティの対話の一部として(通常、債務の支払いについて合意が得られなかった後)、法的手続きの様々な状況の参照。 |
|
|
検索 |
CUSTOMERに送る手紙のタイプの参照。例:
|
|
|
導出 |
ORGANIZATION BUSINESS UNITごとの日別のアクティベーションおよび解約された回線数の統計。 |
|
|
集計 |
ORGANIZATION BUSINESS UNITごとのアクティベーションおよび解約された回線数の月次集計。 |
|
|
リファレンス |
NETWORK ELEMENTなどの特定のオブジェクトを検索するための特定の地理的な住所所在地の部分的な場所。 |
|
|
リファレンス |
このエンティティは、様々なタイプの管理エンティティの最小および最大の要件、制限または他の可変的な機能を表します。 |
|
|
リファレンス |
このエンティティは、全体的にデバイスに関連付けられる管理可能な論理的な概念およびサービスを表します。論理デバイスは、デバイスの様々な側面(たとえば、デバイスに含まれるソフトウェア、デバイスで実行するプロトコル、提供するサービスのセットなど)を結合する便利な集計ポイントを表します。また、論理デバイスでは、デバイス自体で単一の論理的な表現を使用できます。概念的に、これはデバイスの「中枢」を表します。 たとえば、論理デバイスは、パケットのルーティング方法を把握するため、ROUTERに必要なエンティティのセットを表します。 |
|
|
リファレンス |
全体的にデバイスに関連付けられる管理可能な論理的な概念およびサービスを表すエンティティ。デバイスの様々な側面(たとえば、デバイスに含まれるソフトウェア、デバイスで実行するプロトコル、提供するサービスのセットなど)を結合する便利な集計ポイントを表します。 また、論理デバイス・アトミックでは、デバイス自体で単一の論理的な表現を使用できます。実際はアトミック(たとえば、個別に管理できる複数の個々の論理デバイスで構成されていないなど)のすべての論理デバイスを表します。 |
|
|
リファレンス |
全体的にデバイスに関連付けられる管理可能な論理的な概念およびサービスを表すエンティティ。デバイスの様々な側面(たとえば、デバイスに含まれるソフトウェア、デバイスで実行するプロトコル、提供するサービスのセットなど)を結合する便利な集計ポイントを表します。 また、論理デバイス・コンポジットでは、デバイス自体で単一の論理的な表現を使用できます。実際はコンポジット(たとえば、個別に管理できる複数の個々の論理デバイスで構成されているなど)のすべての論理デバイスを表します。コンポジット・パターンは、論理デバイス・コンポジット・オブジェクトをLOGICAL DEVICEオブジェクト(LOGICAL DEVICE ATOMICや論理デバイス・コンポジット・オブジェクト)で構成できます。 |
|
|
リファレンス |
これは関連クラスで、論理デバイスによるOSの使用関連付けのセマンティクスを定義します。これは複雑なクラスなので、読者がこのクラスで定義されたパラメータのタイプを把握するため、少数の単純な属性のみがこの視点で示されます。 |
|
|
リファレンス |
PRODUCTまたはSERVICEで使用される様々なLOGICAL DEVICEの様々な役割を実装するために必要な論理的な機能を定義します。 |
|
|
リファレンス |
すべての論理デバイス役割仕様のエンティティ。論理デバイス役割仕様エンティティは、コア・モデルの他のクラスとのリレーションシップを定義できます。これにより、リレーションシップの拡大を防ぐことができます。論理デバイス役割仕様は、モデルのLOGICAL DEVICEに関連付けられている様々なタイプの役割の不変的な属性、方法、リレーションシップおよび制約を定義します。 |
|
|
リファレンス |
このエンティティは、PRODUCTを構成するデバイスの異なる論理的な側面(DEVICE INTERFACEなど)を示します。論理要素には、主に2つの目的があります。
|
|
|
リファレンス |
これは、LOGICAL ELEMENTモデルで定義される関連性エンティティです。論理要素物理サポートは、セマンティクスを表します。たとえば、1つ以上のLOGICAL ELEMENTを使用してPHYSICAL ELEMENTをサポートする場合に存在する、依存、使用および他のリレーションシップなどがあります。このエンティティを拡張して、含まれる特定のセマンティクスをモデル化する必要があります。拡張する場合、必須属性であるため、OfDependency属性のタイプを含める必要があります。ただし、値の列挙リストに新しい値が追加される場合があります。 |
|
|
リファレンス |
このエンティティは、LOGICAL ELEMENTに関連付けることができる様々なタイプの役割の概念を定義します。 |
|
|
リファレンス |
論理要素を示す役割集計のセマンティクスを実装します。 |
|
|
リファレンス |
すべてのLOGICAL ELEMENT ROLE仕様サブクラスのエンティティ。論理要素役割仕様は、他のクラスとのリレーションシップを定義できます。これにより、リレーションシップの拡大を防ぐことができます。論理要素役割仕様は、LOGICAL ELEMENTに関連付けられている様々なタイプの役割の不変的な属性、方法、リレーションシップおよび制約を定義します。 |
|
|
検索 |
このエンティティは、LOGICAL ELEMENTの不変的な特性および動作(属性、方法、制約およびリレーションシップ)を定義します。 |
|
|
検索 |
このエンティティは、LOGICAL ELEMENTオブジェクトを作成する特定の属性、動作、リレーションシップ、制約およびセマンティクスを示します。このエンティティの目的は、他のタイプの要素仕様と区別してLOGICAL ELEMENTの仕様を追跡することです。このエンティティは要素仕様の変更集計を継承するため、対応するLOGICAL ELEMENTエンティティとともに使用できます。このエンティティと論理要素タイプ・コンポジット・エンティティの違いは、このエンティティがLOGICAL ELEMENTオブジェクトのスタンドアロン仕様を表すことです。論理要素タイプ・コンポジット・エンティティは、LOGICAL ELEMENTオブジェクトの仕様の階層を表します。 |
|
|
検索 |
このエンティティは、LOGICAL ELEMENTオブジェクトを作成する特定の属性、動作、リレーションシップ、制約およびセマンティクスを示します。このエンティティの目的は、他のタイプの要素仕様と区別してLOGICAL ELEMENTの仕様を追跡することです。このエンティティは要素仕様の変更集計を継承するため、対応するLOGICAL ELEMENTエンティティとともに使用できます。このエンティティと論理要素タイプ・アトミック・エンティティの違いは、このエンティティがLOGICAL ELEMENTの仕様の階層を表すことです。論理要素タイプ・アトミック・エンティティは、LOGICAL ELEMENTの単一のスタンドアロン仕様を表します。 |
|
|
リファレンス |
これは、特定の論理要素タイプおよび依存するPHYSICAL ELEMENT SPEC間に存在する不変的な属性、方法、制約およびリレーションシップを定義します。 |
|
|
リファレンス |
このエンティティの目的は、他のタイプの要素仕様と区別して論理要素タイプ仕様を追跡することです。このエンティティはmodifiesElementSpec集計を継承するため、対応する論理要素タイプ仕様エンティティとともに使用できます。 |
|
|
リファレンス |
すべての仮想インタフェースのスーパークラスとして機能する抽象エンティティ。論理インタフェースは、仮想インタフェースとも呼ばれます。論理インタフェースに関連付けられるハードウェアがないため、論理インタフェースは物理的にネットワークに接続されません。サブクラスに影響を与える異なるリレーションシップを実行する便利な集計ポイントとして機能する論理インタフェース。結果として、本質的に同じ複数のリレーションシップをインスタンス化する必要がありません。 |
|
|
検索 |
すべての検索エンティティの抽象ENTITY。 |
|
|
リファレンス |
顧客が参加することができるロイヤルティ・プログラム。 |
|
|
リファレンス |
顧客がロイヤルティ・プログラムに参加、変更または償還する際に使用するチャネル。例:
|
|
|
導出 |
LOYALTY PROGRAM統計のCUSTOMER、PRODUCT、SALES CHANNEL、LOYALTY PROGRAM CHANNEL、SALES CHANNEL REPRESENTATIVE、AGE ON NET BAND、CREDIT CATEGORY別の日次集計。 |
|
|
検索 |
PARTYに与えられる賞の更新のタイプの参照。例:
|
|
|
検索 |
LOYALTY PROGRAMで使用できるLOYALTY PROGRAMイベントのタイプの参照。 |
|
|
集計 |
LOYALTY PROGRAM統計のPRODUCT、SALES CHANNEL、LOYALTY PROGRAM CHANNEL別の月次サマリー。 |
|
|
検索 |
LOYALTY PROGRAMのPARTY参加者に割り当てられる役割または責任の参照。例:
|
|
|
ベース |
LOYALTY PROGRAMでPARTYに与えられる残高ポイント。 |
|
|
検索 |
顧客が特定のLOYALTY PROGRAMの参加を終了した理由。 |
|
|
リファレンス |
CUSTOMERに割り当てられたメールボックス。 |
|
|
検索 |
製品市場計画で実行可能な管理活動のタイプの参照。例:
|
|
|
リファレンス |
これは、共通の次のセマンティクスを持つ管理環境のエンティティを表す抽象エンティティです。 |
|
|
リファレンス |
このエンティティは、追加セマンティクスをハードウェア・ベース・エンティティに追加します。これらのセマンティクスは、ハードウェアの管理情報を提供します。たとえば、このエンティティで定義された属性は、エンティティの管理上および操作上の状態を示し、アラームがあるかどうかを通知できます。 |
|
|
リファレンス |
このエンティティは、情報を送信および受信する接続自体か、その形成をサポートする様々なタイプの論理エンティティを示します。これは、ITUおよびIETF概念を一体化するため、様々なRFCで確認できるような様々なITU仕様(G.805やM.3100など)およびIETF概念に対するスーパークラスを表します。 |
|
|
リファレンス |
2つの重要なプロパティを持つENTITYの特別なグループを表します。1つめとして、管理オブジェクトを意味のある論理的なグループに分割するために使用されます。2つめに、管理機能を提供および測定する方法を示す手段を提供します。 |
|
|
リファレンス |
管理プロトコルは、ネットワーク・デバイス間の管理情報を交換する専用プロトコルの抽象スーパークラスです。このタイプのプロトコルはアプリケーション・レイヤー・プロトコルで、デバイスの情報の構成、監視および収集に使用されます。 |
|
|
検索 |
個人に割り当てられる婚姻関係の参照。 |
|
|
リファレンス |
利用可能な人口統計データがある地理的な領域または地域またはその他の地理的な意味合いを持つもの。 |
|
|
リファレンス |
市場領域の階層レベル。 |
|
|
導出 |
月別の事業者間のポーティング件数。事業者間で受け継がれた番号ポーティングに関する情報のサマリーを提供します。 |
|
|
リファレンス |
各PRODUCT MARKET PLANの顧客ドキュメント要件を定義します。 |
|
|
ベース |
従業員による市場計画の管理履歴。 |
|
|
リファレンス |
顧客が特定の顧客カテゴリ(学生、高齢者、失業者など)に固有の市場計画にアクセスするための文書が保存されます。通常、これらの市場計画では、このエンティティに格納される要求の有効性を証明する文書(所得証明書または身元確認資料など)が必要です。 |
|
|
リファレンス |
月額料金なども含めて、市場計画の各期間に従った詳細な期間値。 |
|
|
リファレンス |
パーティ、地理的領域、販売チャネルなどのグループ。MARKET SEGMENTは、内部および外部のCOMPETITORと他のプロバイダの視点からのマーケティング・キャンペーン、PRODUCT MARKET PLAN、製品プロモーション、製品配置および製品プログラムのターゲットです。 |
|
|
リファレンス |
MARKET SEGMENTの特性品質または特殊機能。特性は、性別などの個々の値、一定範囲の値($50,000 - $100,000の世帯収入など)を取得したり、式(世帯数 = 顧客パーティ役割の数など)から導出したりできます。 |
|
|
リファレンス |
MARKET SEGMENT CHARACTERISTICに割り当てることができる数値またはテキスト。 |
|
|
|
リファレンス |
2つのMARKET SEGMENT間の包含リレーションシップ。 |
|
集計 |
市場情報を定義します。PRODUCT MARKET PLANの地理的な市場占有率の月次サマリー。 |
|
|
導出 |
市場情報を定義します。月別の、住所および事業単位ごとの売上収益。 |
|
|
リファレンス |
MARKET SEGMENT別のパフォーマンス尺度の分類。PERFORMANCEは、市場のサービス・プロバイダおよびサービス・プロバイダのCOMPETITORに対して測定されます。 |
|
|
|
リファレンス |
2つの市場統計間のリレーションシップ。 |
|
リファレンス |
このエンティティは、すべての仮想インタフェースのスーパークラスとして機能します。論理インタフェースは、仮想インタフェースとも呼ばれます。論理インタフェースに関連付けられるハードウェアがないため、物理的にネットワークに接続されません。サブクラスに影響を与える異なるリレーションシップを実行する便利な集計ポイントとして機能するメディア・インタフェース。結果として、本質的に同じ複数のリレーションシップをインスタンス化する必要がありません。 |
|
|
リファレンス |
CAMPAIGN MESSAGEが登場するいずれかのメディア。例:
|
|
|
リファレンス |
あるMEDIA OBJECTと別のMEDIA OBJECTの関係。 |
|
|
ベース |
MEDIA OBJECTの使用から生じる費用。特定のメディア(新聞、テレビ・コマーシャル、チラシなど)に関連するすべての費用を集めるCOSTのサブタイプ。 |
|
|
検索 |
利用可能なMEDIA OBJECTのタイプの参照。例:
|
|
|
ベース |
元のデバイス情報、通話の途切れ、不在着信情報による通話イベントの調整。通常、これらの通話は評価エンジンによって無視されます。通話イベントは、評価エンジンによって通話が評価される前に収集されます。 |
|
|
検索 |
正常な調整や失敗などの調整ステータスのカテゴリの参照。 |
|
|
検索 |
ネットワーク・イベントが特定の調整ステータスの理由の参照。例:
|
|
|
検索 |
特定のRAWネットワーク・イベントの調整ステータスの参照。例:
|
|
|
リファレンス |
時間の一部として分を定義します。 |
|
|
ベース |
Account Balanceのサブタイプ。特定の月にサブスクライバに割り当てられる無料またはプリペイドの分数を表します。 |
|
|
リファレンス |
マルチメディア・メッセージング・サービス(MMS)に関連する情報を含むVALUE ADDED SERVICEおよびPRODUCTのサブタイプ。MMS EVENT自体と混同しないでください。 |
|
|
ベース |
NETWORK EVENTのサブタイプ。マルチメディア・メッセージング・サービス(MMS)タイプのコールに関するすべての情報を収集します。 |
|
|
リファレンス |
移動通信交換局(MSC)は、制御対象エリア内の移動機の回線交換、移動管理およびGSMサービスを提供する高度な電話交換局です。音声、データ、FAXサービス、SMSおよび転送サービスが含まれます。 |
|
|
検索 |
アイテムのモデル・タイプの参照。特定のモデルに様々なタイプが存在する場合があります。たとえば、ハンドセットでは、Bluetoothが使用可能な場合とそうでない場合があります。 |
|
|
リファレンス |
日付の時間変換を実行するための関連カレンダ要素の定義。 |
|
|
リファレンス |
月についての変換。例:
|
|
|
導出 |
MSC (移動通信交換局)の機能およびパフォーマンスに関連するパラメータ、構成およびランタイム統計。 |
|
|
集計 |
MSC (移動通信交換局)の機能およびパフォーマンスに関連するパラメータ、構成およびランタイム統計の月次集計。 |
|
|
リファレンス |
VALUE ADDED SERVICEおよびPRODUCTのサブタイプ。音楽ダウンロード・サービスの関連情報が含まれます。 |
|
|
リファレンス |
北米産業分類システム(NAICS: North American Classification System)の分類を指定します。 |
|
|
リファレンス |
北米産業分類システム(NAICS: North American Industry Classification System)の産業の最下位の分類。 |
|
|
リファレンス |
北米産業分類システム(NAICS: North American Industry Classification System)の分類グループの参照。 |
|
|
リファレンス |
北米産業分類システム(NAICS: North American Industry Classification System)の産業セクターの参照。 |
|
|
リファレンス |
北米産業分類システム(NAICS: North American Industry Classification System)の産業サブセクターの参照。 |
|
|
検索 |
利用可能な国籍の参照。 |
|
|
リファレンス |
事前定義済のSLA仕様と比較して、交渉されたサービス・レベル仕様。 |
|
|
リファレンス |
関連ネットワークの名称およびサービス・プロバイダ。サービス・プロバイダに関する全詳細は、PARTYおよび組織エンティティにあります。 ネットワークは、相互接続された通信および情報を交換できる管理オブジェクトの集計を表す管理オブジェクトです。ネットワークが要素コレクションからサブクラス化される理由は、ネットワークがこのコレクションの通信および管理オブジェクトの物理的および論理的な特性および動作を表すことが重要であるためです。ネットワークには、1つ以上の一般的な特性および動作を持つ追加セマンティクスがあります。たとえば、ネットワークが単一の顧客またはプロバイダによって所有されるか、特定のセットのサービスの配信と関連付けられる場合があります。ネットワークは別の(より大きい)ネットワーク内にネストされる場合があるため、包含リレーションシップを形成します。別のネットワークに含まれるネットワークの例は、送信サブネットワークです。ネットワークは単一の管理で所有され、送信機能のみ実行できます。 |
|
|
リファレンス |
ネットワーク・アドレスの汎用的な概念を表します。ネットワーク・アドレス・サブクラスは、IP ADDRESSやIPXAddressなどの異なるテクノロジの様々なタイプのアドレスを定義します。ネットワーク・アドレスの使用は、送信元と送信先のリレーションシップの便利なポイントとして役立つ機能にあります。これにより、NETWORK ADDRESSのサブクラスと対話するリレーションシップの過度の重複がなくなります。 |
|
|
リファレンス |
このNETWORK ADDRESSがこの特定のDEVICE INTERFACEに含まれる方法のセマンティクスを定義します。 |
|
|
検索 |
NETWORK ADDRESSを定義する不変的な特性のネットワーク・アドレスのタイプの参照。たとえば、IPv4、IPv6、IPXなどがあります。 |
|
|
リファレンス |
NETWORK間のリレーションシップを定義します。例:
|
|
|
検索 |
ネットワーク・リレーションシップのタイプの参照。例:
|
|
|
リファレンス |
スタンドアロン・ネットワークを表します。ネットワーク・アトミックは、適切なネットワーク・コンポジット・オブジェクトに集計して、より大きいネットワークに結合される場合があります。 |
|
|
導出 |
ネットワーク可用性の測定値および事業者のネットワークで発生したすべての故障の統計。 |
|
|
集計 |
ネットワーク可用性の統計および事業者のネットワークで発生したすべての故障の月次集計。 |
|
|
リファレンス |
特定のネットワーク・ルート、トレイルまたは接続のネットワーク容量。 |
|
|
リファレンス |
ネットワーク・アトミックおよびネットワーク・コンポジット・オブジェクトの集計を表します。各ネットワーク・アトミック・オブジェクトは、スタンドアロン・ネットワークを表します。適切なタイプのネットワーク・コンポジット・オブジェクトを選択してネットワーク・アトミック・オブジェクトを集計し、これらを結合してより大きいネットワークを構築できます。また、ネットワーク・コンポジット・オブジェクトは複数のネットワーク・コンポジット・オブジェクトを集計できます。 |
|
|
リファレンス |
ネットワーク・ドメインは、管理上および操作上の特性の一般的なセットを共有する一連の管理物理エンティティを表します。これらの重要事項は、一般的なネーミング方法の使用です。ネットワーク・ドメインは、管理エンティティ・インスタンスを論理グループにパーティション化します。たとえば、1つ以上の一般的なマネージャで制御する操作上および管理上のグループなどがあります。ネットワーク・ドメインは、一連の管理エンティティの操作上の特性を管理および制御する方法を提供します。 |
|
|
リファレンス |
NETWORK ELEMENTをNETWORK DOMAINに割り当てます。 |
|
|
リファレンス |
通信サービスを提供するネットワーク(通常では通信サービス・プロバイダのネットワークのみ)のすべての要素。 |
|
|
リファレンス |
NETWORK ELEMENTによって割り当てることができるビジネス対話役割。 |
|
|
検索 |
NETWORK ELEMENT TYPEをさらに分類するネットワーク要素のカテゴリ。 |
|
|
ベース |
COSTのサブタイプ。特定のコストをNETWORK ELEMENTに関連付けます(購入、メンテナンス、リサイクルなど)。 |
|
|
ベース |
NETWORK FAULTをSUBSCRIPTIONに割り当てます。 |
|
|
リファレンス |
要素の所有関連付けのセマンティクスを定義します。要素の管理関連付けとは対照的に、問題が管理ではなく所有権であるため、これにPARTY ROLEの任意のタイプを指定できます。管理には特定のスキル・セットが含まれ、所有権には含まれません。この関連付けのセマンティクスには、要素を管理する値ネットワーク役割への権限の付与とともに、このPARTY ROLEで要素を所有できる期間の指定が含まれます。 |
|
|
リファレンス |
パーティおよび管理NETWORK ELEMENT間のリレーションシップを定義します。 |
|
|
リファレンス |
要素の管理関連付けのセマンティクスを定義します。これは、任意のタイプのPARTY ROLEではなく値ネットワーク役割をデバイスの管理に許可することを定義します。この関連付けのセマンティクスには、要素を管理できる要素の所有者の権限の付与とともに、この値ネットワーク役割で要素を管理できる期間の指定が含まれます。 |
|
|
リファレンス |
2つのNETWORK ELEMENT間のリレーションシップ。たとえば、GSMで複数のBTSがBSCに接続され、ブロードバンドで複数の顧客回線がDSLAMに接続される場合があります。 |
|
|
検索 |
NETWORK ELEMENT RELATIONSHIPのタイプ。例:
|
|
|
リファレンス |
このエンティティは、リソースと関連付けられる様々なタイプの役割の概念を定義します(物理および論理の両方)。 |
|
|
リファレンス |
役割を持つネットワーク要素リレーションシップのセマンティクスを実装します。ネットワーク要素役割割当ては、物理要素を示す役割、LOGICAL ELEMENTを示す役割および複合要素を示す役割リレーションシップを実装するクラスを定義する親エンティティとしても機能します。 |
|
|
リファレンス |
パーティ役割で管理される要素役割関連付けのセマンティクスを定義します。パーティ役割で管理される要素役割関連付けは、特定のPARTY ROLEで管理される一連の要素役割を定義します。多くの場合、大幅に異なるスキル・セットや方法などを必要とする様々なタイプの要素間に重要な機能の違いがあり、これらの要素はそれを管理するPARTY ROLEによって使用されます。たとえば、エッジ・ルーターと比較してコア・ルーターを管理するために異なる管理者が割り当てられる場合があります。これは、ルーター全体ではなく、ライン・カードなどの物理機能および論理機能に適用されます。たとえば、DEVICE INTERFACE、コンポーネントなどがあります。ネットワーク要素役割パーティ割当てエンティティは、これらのセマンティクスを取得します。 |
|
|
リファレンス |
これは、すべての要素役割仕様サブクラスの抽象ベース・エンティティです。ネットワーク要素役割仕様は、他のネットワーク要素役割とのリレーションシップを定義できます。これにより、リレーションシップの拡大を防ぐことができます。ネットワーク要素役割仕様は、要素に関連付けられている様々なタイプの役割の不変的な属性、方法、リレーションシップおよび制約を定義します(物理および論理の両方)。 |
|
|
ベース |
ネットワーク要素の状態履歴は、電源切断、使用中、無効などの各NETWORK ELEMENTの状態履歴を追跡します。 |
|
|
検索 |
NETWORK ELEMENTが特定の状態の理由の参照。例:
|
|
|
検索 |
特定のNETWORK ELEMENTのNETWORK ELEMENT STATEの参照。例:
|
|
|
リファレンス |
このエンティティは、管理要素の不変的な特性および動作(属性、方法、制約およびリレーションシップ)を定義します。 |
|
|
リファレンス |
異なるインスタンスの要素仕様を区別する機能を表します。ネットワーク要素タイプ・バージョンは、その他または元と異なる特定の形式や種類の要素仕様を表します。形式は、新しい要素仕様を作成するほどではない、この特定の要素仕様の特性を示す属性、方法、リレーションシップまたは制約の違いを表します。 |
|
|
リファレンス |
modifiesElementSpec集計のセマンティクスを定義します。特に、アプリケーションを使用して、特定のタスクに対して適切なこの要素仕様のバージョンのセットを定義できます。 |
|
|
リファレンス |
本来の目的のための要素の使用発生。 |
|
|
検索 |
ネットワーク要素使用イベント(リソースの購入や賃貸など)の詳細な説明。 |
|
|
ベース |
顧客の使用によって事業者のネットワークに発生したすべてのイベントの抽象化イベント。通常、顧客はネットワーク・イベントに基づいて請求されます。 |
|
|
ベース |
特定のNETWORK EVENTによるACCOUNT BALANCE BUCKETに対する残高の影響。たとえば、1回の音声電話によって、「USD 100有効日20110101、期限日20120101」という勘定残高バケットから10セント差し引かれます。 |
|
|
ベース |
NETWORK EVENTがどのように勘定残高に影響するか。たとえば、1回の音声電話によって、現金勘定残高から10セント差し引かれます。 |
|
|
ベース |
NETWORK EVENTと別のNETWORK EVENT間のリレーションシップを定義します。 |
|
|
リファレンス |
名前、カテゴリ、タイプ、プレゼンスおよび一連の許可される値で示される特定のタイプのNETWORK EVENTを定義する属性の詳細な説明。 |
|
|
リファレンス |
NETWORK EVENTタイプで特性を利用する方法。 |
|
|
リファレンス |
集計、移行、置換、依存性、排他性などのNETWORK EVENT CHARACTERISTIC間のリレーションシップ。 |
|
|
リファレンス |
特性で示されるネットワーク・イベント情報の高度な側面を表すカテゴリ。 |
|
|
リファレンス |
イベントの属性値を表すNETWORK EVENT CHARACTERISTICの値。 |
|
|
リファレンス |
追加のプロパティ、属性がNETWORK EVENT CHARACTERISTIC VALUEに含まれる類似したプロパティのプロパティを適用またはオーバーライドするNETWORK EVENTによる特性値の使用。 |
|
|
リファレンス |
集計、移行、置換、依存性、排他性などのNETWORK EVENT CHARACTERISTIC VALUE間のリレーションシップ。 |
|
|
検索 |
NETWORK EVENTのステータスの参照。例:
|
|
|
検索 |
利用可能なNETWORK EVENTタイプの参照。 |
|
|
リファレンス |
その他または元と異なるNETWORK EVENT TYPEの特定の形式または種類。形式は、新しいNETWORK EVENT TYPEを作成するほどではない、NETWORK EVENT TYPEの特性を示すプロパティの違いを表します。 |
|
|
ベース |
登録されたすべての障害の記録。 |
|
|
検索 |
各NETWORK FAULTに割り当てることができる異なる優先順位。 |
|
|
ベース |
サービスはNETWORK FAULTの影響を受ける可能性があります。 |
|
|
ベース |
NETWORK FAULTのステータス履歴。例:
|
|
|
ベース |
ネットワーク問題を影響を受けたすべてのサブスクリプションに関連付けます。これにより、ネットワーク障害の影響を受けた顧客およびサービスのリストが得られます。 |
|
|
リファレンス |
ネットワーク・ルートの可能性がある一連の場所を定義します。 |
|
|
リファレンス |
NETWORK ROUTEの経路の可能性があるポイント。 |
|
|
リファレンス |
NETWORK ROUTEへのNETWORK ROUTE POINTの割当て。複数のNETWORK ROUTEで、同じNETWORK ROUTE POINTを共有する場合があります。 |
|
|
リファレンス |
NETWORK TOUCHPOINTとSERVICE COVERAGE AREAのリレーションシップの定義。 |
|
|
リファレンス |
NETWORK ELEMENTが配置またはインストールされる場所を指定します。 |
|
|
リファレンス |
サブスクライバがCELL SITEまたはFIXED LINE PORTにアクセスするサービス・サイト・ポイント。 サイトはエリアではなく、地理的な位置であるため、いずれかの地理的エンティティに属します。たとえば、GEOGRAPHY ENTITYのタイプではなく、市区または町です。 例:
|
|
|
検索 |
利用可能なNETWORK TOUCHPOINTのクラスの参照。例:
|
|
|
集計 |
NETWORK TOUCHPOINTの月次サマリー(CUSTOMER別、NETWORK別、アドレス別、およびその他)。 |
|
|
導出 |
NETWORK TOUCHPOINTの月次サマリー(CUSTOMER別、郡別、およびその他)。 |
|
|
検索 |
NETWORK TOUCHPOINTの利用可能なステータスコードおよび説明の参照。 |
|
|
検索 |
NETWORK TOUCHPOINTのタイプの参照。例:
|
|
|
検索 |
NETWORKのタイプの参照。次を含む:
|
|
|
検索 |
UMSまたはVMSメールボックスで受信または転送された場合、サブスクライバが受信する通知のタイプの参照。例:
UMS通知タイプ・ディメンションは、他のディメンションとともに、通知タイプによる通知データの整理に役立ちます。 |
|
|
リファレンス |
移植した番号の移動体MSISDN番号。 |
|
|
ベース |
顧客による番号ポーティング(NP: Number Porting)要求の提出(Porting In)または受け取った事業者(Porting Out)。 |
|
|
ベース |
番号ポーティング(NP: Number Porting)要求内の要求回線アイテム。 |
|
|
ベース |
番号ポーティング(NP: Number Porting)要求回線アイテムの状況履歴。 |
|
|
検索 |
番号ポーティング(NP: Number Porting)回線アイテムの状況のタイプの参照。例:
|
|
|
ベース |
番号ポーティング(NP: Number Porting)要求の状況履歴。 |
|
|
検索 |
番号ポーティング(NP: Number Porting)要求の状況のタイプの参照。例:
|
|
|
検索 |
番号ポーティング(NP: Number Porting)要求のタイプの参照。例:
|
|
|
検索 |
番号ポーティング(NP: Number Porting)要求の手順。例:
|
|
|
リファレンス |
特定のエリアに関連するコードの定義。通常、これらのコードは固定回線番号に電話をかける場合に使用します。例:
番号エリアは、地理的なエリアではなく、他の通信事業者に関連する場合もあります。たとえば、フランスの9など。 |
|
|
リファレンス |
国番号。例:
|
|
|
検索 |
サブスクリプションとの関連で使用されるネットワーク・テクノロジの分類の参照。例:
|
|
|
導出 |
ポーティング要求(イン/アウト)の日別集計。 |
|
|
集計 |
ポーティング要求(イン/アウト)の月次サマリー。 |
表2-27 エンティティの説明(O～R)
| エンティティ名 | タイプ | 説明 |
|---|---|---|
|
検索 |
コールの分類の参照:
|
|
|
リファレンス |
オペレーティング・システムは、LOGICAL ELEMENTを実行するソフトウェアおよびファームウェアを表す具体エンティティです。このエンティティは、LOGICAL ELEMENTで利用可能な要素、タスク、ファイル・システム、セキュリティおよびデータを実装および管理します。オペレーティング・システムは、要素で実行されるソフトウェア・アプリケーションとは異なります。すべてのアプリケーションおよびソフトウェアは、必要なすべての操作に対してオペレーティング・システムと通信する必要があります。 |
|
|
検索 |
事業者の分類グループ。たとえば、次のように分類できます。
|
|
|
検索 |
事業者を分類する事業者タイプの参照。例:
通常、国際事業者には複数の子会社があります。子会社のリレーションシップはパーティ・リレーションシップでモデル化されています。 |
|
|
リファレンス |
ジオメトリ情報を提供します。 |
|
|
リファレンス |
管理している注文明細の商品に割当て可能なステータスの参照。例:
|
|
|
検索 |
注文状況のタイプの参照。例:
|
|
|
検索 |
注文ステータスのタイプの参照。例:
|
|
|
検索 |
CUSTOMER ORDERのタイプの参照。例:
|
|
|
リファレンス |
ORGANIZATION CHAIN内のORGANIZATION HIERARCHY LEVEL。Organization Areaエンティティは、1つ以上のORGANIZATION REGIONの親です。 |
|
|
リファレンス |
消費者が一目で認識できる会社、組織または子会社の名前、またはカタログ、Webチャネルまたは在来型店舗に掲示される店名。 |
|
|
リファレンス |
事業分析および取引のための事業の一部の論理エンティティ。事業エンティティの分類には、会社、業務単位、店舗または倉庫などがあります。 |
|
|
リファレンス |
販売チャネル(Webサイト、店舗、パートナの売店など)を通じて限られた範囲の特定通信サービスまたは商品を提供する組織の事業単位。たとえば、SuperTelcoの例では、2つの事業単位を次のように定義できます:
|
|
|
ベース |
COSTのサブテーブル。このエンティティは、特定のコストをORGANIZATION BUSINESS UNITに関連付けます(EMPLOYEE COSTによってカバーされないコスト)。 |
|
|
検索 |
ORGANIZATION BUSINESS UNITのタイプの参照。例:
|
|
|
リファレンス |
ORGANIZATION COMPANY内のORGANIZATION HIERARCHY LEVEL。Organization Chainエンティティは、1つ以上のORGANIZATION AREAの親です。 |
|
|
リファレンス |
ORGANIZATION CORPORATE内のORGANIZATION HIERARCHY LEVEL。Organization Companyエンティティは、1つ以上のORGANIZATION CHAINの親です。 |
|
|
リファレンス |
ORGANIZATION HIERARCHYの最上位レベル。Organization Corporateエンティティは、1つ以上のORGANIZATION COMPANYの親です。 |
|
|
リファレンス |
ORGANIZATION REGION内のORGANIZATION HIERARCHY LEVEL。Organization Districtエンティティは、1つ以上のORGANIZATION BUSINESS UNITの親です。 |
|
|
リファレンス |
||
|
リファレンス |
ユーザー定義。組織内のすべての階層のマスター・リストです。 |
|
|
リファレンス |
階層およびレベルの関連性エンティティ。 |
|
|
リファレンス |
ORGANIZATION HIERARCHYへの階層レベルの割当て。 |
|
|
リファレンス |
ORGANIZATION HIERARCHYのバージョン。 |
|
|
リファレンス |
販売価格をアイテムに関連付けます。各組織で同じアイテム・モデルの価格が異なる場合があります。 |
|
|
リファレンス |
組織内のすべての事業レベルのリスト。 |
|
|
リファレンス |
ORGANIZATION HIERARCHY LEVELに関連付けるユーザー定義の属性値。 |
|
|
リファレンス |
ORGANIZATION LEVELに割り当てられる属性。 |
|
|
リファレンス |
社内または社外のパーティに関する、公表されている統計情報。DUNSナンバーおよび従業員数などがあります。 |
|
|
リファレンス |
様々なタイプの組織名は、組織の関連付けられている事業法的ステータスを表します。 |
|
|
リファレンス |
ORGANIZATION AREA内のORGANIZATION HIERARCHY LEVEL。Organization Regionエンティティは、1つ以上のORGANIZATION DISTRICTの親です。 |
|
|
リファレンス |
ORGANIZATION BUSINESS UNITのサブタイプ。このエンティティは、事業者が管理するWebサイト上のすべての情報を集めます。通常は公開情報のみが含まれます。 |
|
|
リファレンス |
商品または在庫品(ルーター、ハンドセット、コンピュータなど)が、店舗に送られたりCSPで利用されたりする前に保管される場所(販売される場所ではありません)。例:
|
|
|
リファレンス |
ORGANIZATION BUSINESS UNITに関連する、人口統計についてのユーザー定義の属性の定義および対応する値。 |
|
|
リファレンス |
OSをライセンスするパーティ役割関連付けのセマンティクスを定義します。OSライセンス割当て属性は、この特定のOPERATING SYSTEMインスタンスのライセンス詳細を指定できます。 |
|
|
リファレンス |
||
|
リファレンス |
PRODUCTまたはSERVICEで使用されているように、P(プロバイダ・コア)デバイスの特定の役割を実装するために必要な論理機能を定義します。 |
|
|
ベース |
ベンダー、ディーラーなどのパートナに対する支払い。パートナにはOracle BRMなどのソース・システムのアカウントが存在する可能性もあるため、この支払いでそのアカウントを参照する場合があります。 |
|
|
検索 |
パートナ支払い取引のタイプの参照。例:
|
|
|
リファレンス |
||
|
集計 |
上位レベルでパートナに起きた金銭的解決活動の月次集計。 |
|
|
導出 |
1か月以内に各パートナに起きた金銭的解決活動。 |
|
|
検索 |
パートナの解決についての有効な理由コードの参照。 |
|
|
リファレンス |
パーティは実在する人物、組織、支店、子会社、法人、持ち株会社またはその他のエンティティです。実際に存在し、名前を付けることができる対象はパーティです。 パーティの属性はユニバーサルです。つまり、リレーションシップが販売パーティであるか究極の購入パーティであるかに関係なく共通の属性が使用されます。 パーティは必ずしも顧客ではありません。パーティには、見込み客や、支店、本店、コングロマリットなどのORGANIZATION HIERARCHYの構成要素も含まれ、会社とのリレーションシップが支払い請求であるとはかぎりません。 アクティブなアカウントを持つパーティは顧客とみなすことができます。 パーティに関する履歴情報は、パーティ履歴で取得できます。 |
|
|
リファレンス |
ACCOUNTへのPARTYの割当て。パーティのタイプに応じて、次のリレーションシップがあります。
|
|
|
検索 |
PARTYとACCOUNT間のリレーションシップの参照。パーティのタイプに応じて、次のリレーションシップがあります。
|
|
|
リファレンス |
1つ以上の住所をPARTYに関連付けます。 |
|
|
ベース |
ACCESS METHOD、PRODUCT MARKET PLANおよびPARTY間の割当て履歴。 |
|
|
ベース |
PARTY、ACCESS METHODおよびPRODUCT MARKET PLAN間の割当てのステータス履歴。 |
|
|
リファレンス |
PARTYを1つ以上の他のパーティに関連付けます。 リレーションシップには、顧客間または顧客と通信事業者間のリレーションシップが含まれます。後者のタイプのリレーションシップの例として、アカウント・マネージャが1以上の顧客とリレーションシップを持つアカウント管理ポートフォリオがあります。 |
|
|
検索 |
パーティを相互に関連付ける有効な理由の参照。例:
|
|
|
検索 |
パーティ・リレーションシップのタイプの参照。例:
|
|
|
リファレンス |
PARTYによって割り当てることができるビジネス対話役割。 |
|
|
リファレンス |
パーティの連絡先情報。 |
|
|
検索 |
連絡先情報のタイプの参照。例:
|
|
|
検索 |
PARTYとCONTACT LIST間のリレーションシップ。たとえば、パーティは連絡先リストに含まれます。 |
|
|
検索 |
CONTACT LISTのPARTYの役割。 |
|
|
リファレンス |
||
|
検索 |
PARTY CONTRACT ASSIGNMENTでパーティに割り当てられる有効な役割の参照。 |
|
|
検索 |
PARTY CONTRACT ASSIGNMENTのタイプの参照。例:
|
|
|
ベース |
PARTYへのコスト・アイテムの割当て。1つのパーティから複数のコストが生じる場合があります。たとえば、顧客の獲得のために、顧客に次のような商品を与えるとコストが生じます。
複数のパーティにコストを割り当てることができます。たとえば、営業費の場合、複数の組織がPROMOTIONまたはCAMPAIGNで同じ費用を分担します。 |
|
|
リファレンス |
PARTYの人口統計プロファイル。 |
|
|
リファレンス |
特定のパーティ人口統計プロファイルの個人および組織の人口統計値を定義します。 |
|
|
検索 |
パーティ・プロファイルに割り当てる有効なEVENT TYPEの参照。パーティに対して実行できる様々なイベント・タイプがあります。 |
|
|
リファレンス |
PARTYを1つ以上のGEOGRAPHY ENTITYに割り当てます。 |
|
|
リファレンス |
PARTYを一意に識別する情報。 |
|
|
検索 |
PARTY IDENTIFICATIONの有効なタイプの参照。例:
|
|
|
ベース |
関連するPARTYとのコンタクト・イベントを1本のスレッドにまとめます。 |
|
|
ベース |
PARTY INTERACTION THREADと関連するSUBSCRIPTION間のリレーションシップ。 |
|
|
検索 |
PARTY INTERACTION THREADのタイプ。例:
|
|
|
リファレンス |
各パーティの言語能力スコアを保持します。 |
|
|
検索 |
PARTYに住所を割り当てる根拠について、利用可能な理由コードおよび説明の参照。例:
|
|
|
検索 |
PARTYと住所間のリレーションシップのタイプ。例:
|
|
|
リファレンス |
各顧客が参加しているLOYALTY PROGRAMを識別します。 |
|
|
検索 |
CAMPAIGNでパーティが担当するすべての役割の定義。管理または見込み客などがあります。 |
|
|
リファレンス |
PARTYを属している市場セグメントに割り当てます。 |
|
|
リファレンス |
特定のパーティの全履歴から他の既知の名前をリストします。 |
|
|
ベース |
PARTYを特定の注文に割り当てます。例:
|
|
|
検索 |
PARTY ORDER ASSIGNMENTに関する利用可能な割当てタイプのコードおよび説明の参照。例:
|
|
|
リファレンス |
パーティ・プロファイルで取得する可能性がある特性。たとえば、年齢、教育などがあります。 |
|
|
リファレンス |
パーティ・プロファイルの各PARTY PROFILE CHARACTERISTICの実際の値。 |
|
|
ベース |
イニシアチブに対する顧客の応答結果を記録します。肯定的な反応を次に示します:
|
|
|
検索 |
||
|
リファレンス |
パーティに対するパーティの役割の割当て。PARTYとPARTY ROLEは、X対Xのリレーションシップです。このリレーションシップは、契約の変更やその他の理由により変更される場合があります。 |
|
|
リファレンス |
プロセスを使用するパーティ役割関連付けのセマンティクスを定義します。様々なPARTY ROLEにOPERATING SYSTEMを操作および実行する異なる権限があるため、これらの詳細を正確にモデル化するには、関連付けクラスが必要です。 |
|
|
リファレンス |
PARTYが引き受けた各役割のステータス履歴。 |
|
|
検索 |
セグメントを作成するための方法。データ・マイニングでのK-meansによるクラスタリングなど。 |
|
|
リファレンス |
||
|
検索 |
PARTYがSERVICEに対して割り当てる可能性がある有効な役割および説明の参照。例:
|
|
|
検索 |
||
|
リファレンス |
||
|
検索 |
||
|
リファレンス |
各PARTYに対するスコアを使用したスキルおよびスキル・レベルを定義します。 |
|
|
検索 |
パーティ・ステータスの上位レベル。例:
|
|
|
検索 |
パーティ・ステータスの変更に対して割り当てられる有効な理由の参照。例:
|
|
|
ベース |
事業者の関心事項に関する現在のPARTYステータス履歴の定義。 顧客またはディーラーの全存続期間について取得された履歴情報。この情報は、社内データ(支払いなど)から計算するか、信用評価会社などの外部ソースから入手できます。 |
|
|
検索 |
PARTYのステータス・タイプの参照。例:
信用クラスは、顧客の信用のランク付けに使用されます。エンティティの値の例を次に示します。
または、顧客を次のように定義する場合もあります:
パーティの信用は、パーティが保持するアカウントが基礎となります。 |
|
|
リファレンス |
PARTYとSUBSCRIPTIONのリレーションシップを定義します。例: 顧客がサブスクリプションを所有。 |
|
|
検索 |
SUBSCRIPTIONに関してPARTYに割り当てられる有効な役割の参照。 |
|
|
検索 |
パーティの固有の特性および構造に基づいて関連するパーティを分類するパーティ・タイプの参照。例:
|
|
|
リファレンス |
PARTY IDENTIFICATIONのタイプとしてのパスポート。 |
|
|
検索 |
給与明細書の支払いカテゴリのタイプの参照。例:
|
|
|
リファレンス |
PRODUCTのサブタイプ。有料テレビは、顧客にテレビ・チャネルを配信するサブスクリプション・ベースの製品です。 |
|
|
検索 |
従業員への支払いのタイプの参照。例:
|
|
|
検索 |
支払い遅延履歴に従ったアカウントの分類。例:
|
|
|
導出 |
||
|
集計 |
顧客債務のエイジングの月次サマリー。 |
|
|
リファレンス |
顧客がサービスの支払いに使用するチャネル。例:
|
|
|
検索 |
有効な支払い方法の参照。例:
|
|
|
検索 |
ACCOUNT PAYMENTに関連付けられた取引タイプに対応するタイプのコードおよび説明の参照。支払いの例を次に示します。
|
|
|
検索 |
GPRSテクノロジのPacket Control Unit (PCU)の故障の理由の参照。例:
|
|
|
リファレンス |
PRODUCTまたはSERVICEで使用されているように、PE(プロバイダ・エッジ)デバイスの特定の役割を実装するために必要な論理機能を定義します。 |
|
|
検索 |
タイム・スロットの定義は使用に依存しますが、すべての製品/パッケージに共通ではありません。タイムの時間(ピーク、オフピークおよび夜間)は、パッケージごとに異なります。また、次の場合も異なります。
システムに定義された特別な日。 |
|
|
リファレンス |
SERVICEまたは要素およびその両方が機能する方法の尺度。 |
|
|
リファレンス |
PERFORMANCE SPECIFICATIONを測定するまたは測定しない時刻または日。 |
|
|
リファレンス |
PERFORMANCE CATEGORYの内容をさらに定義するPERFORMANCE CATEGORYに提供される特性仕様の値。 |
|
|
リファレンス |
2つのインスタンスのPERFORMANCE CATEGORY間で確立できる関連付けの仕様。たとえば、コーデック・インスタンスと保有者タイプ・インスタンス間のリレーションシップを確立できます。 |
|
|
リファレンス |
一般的な特性のために一緒に分類されるパフォーマンス品質のグループまたはセットを定義する不変的な特性。 |
|
|
リファレンス |
一般的な特性のために一緒に分類されるパフォーマンス品質のグループまたはセット。 |
|
|
リファレンス |
2つのインスタンスのPERFORMANCE CATEGORY間の関連付け。たとえば、コーデック・インスタンスと保有者タイプ・インスタンス間のリレーションシップなどがあります。 |
|
|
リファレンス |
PERFORMANCEの内容をさらに定義するPERFORMANCEに提供される特性仕様の値。 |
|
|
リファレンス |
PERFORMANCE OBJECTIVEが満たされていない場合のアクション。 |
|
|
リファレンス |
PERFORMANCE INDICATOR SPECIFICATIONに対して決定される数値またはテキスト。たとえば、平均的なパケット遅延を表す005msの値などがあります。 |
|
|
|
リファレンス |
PERFORMANCE INDICATORの計算に使用されるパラメータ。特性仕様をパラメータとして使用したり、別のPERFORMANCE INDICATOR SPECIFICATIONを使用したりできます。 |
|
リファレンス |
その他から導出されるインジケータなどの2つのPERFORMANCE INDICATOR間の関連付け。 |
|
|
リファレンス |
その他から導出されるインジケータなどの2つのPERFORMANCE INDICATOR SPECIFICATION間の関連付け。 |
|
|
リファレンス |
PERFORMANCE CONSEQUENCEの作成をトリガーする可能性があるPERFORMANCE SPECIFICATIONに対して定義される、失われたパケットや平均的なジッターなどのエンティティの特定の側面のパフォーマンスの尺度。 |
|
|
リファレンス |
IP ADDRESSに対するパフォーマンス関連の拡張。 |
|
|
|
検索 |
IP ADDRESS関連パフォーマンス尺度のタイプ。 |
|
リファレンス |
セル・サイトや基地局コントローラなどのモバイル要素を識別するネットワーク・アドレス。 |
|
|
リファレンス |
NETWORK ADDRESSに対するパフォーマンス関連の拡張。NETWORK ADDRESSは、IP ADDRESS、IPXAddress、ポイント・コードなどの要素の場所を識別する様々な方法を定義します。 |
|
|
|
検索 |
ネットワーク・アドレス仕様に対してパフォーマンス関連の拡張を定義する不変的な特性。ネットワーク・アドレス仕様は、IP ADDRESSやIPXAddressなどの異なるテクノロジの様々なタイプのアドレスを定義します。関連する各PERFORMANCE NETWORK ADDRESSインスタンスには、同じ不変的な特性があります。ただし、インスタンス化されたPERFORMANCE NETWORK ADDRESSエンティティの他の特性に関連付けられている値は、各インスタンスに固有です。 |
|
リファレンス |
パフォーマンスの測定の一部として発生する通信。レスポンスを予期しないため、通知は一般的に一方向です。 |
|
|
リファレンス |
パフォーマンス測定の一部として発生する通信(通知)を定義する不変的な属性。レスポンスを予期しないため、通知は一般的に一方向です。 |
|
|
リファレンス |
メトリック、しきい値および許容範囲で定義されたPERFORMANCE INDICATORの目標。 |
|
|
リファレンス |
PERFORMANCE OBJECTIVEを評価するまたは評価しない時刻または日。 |
|
|
リファレンス |
PERFORMANCE OBJECTIVEの違反に対してパフォーマンス目的結果を適用するまたは適用しない時刻または日。 |
|
|
リファレンス |
POINT CODE(NETWORK ADDRESSのサブタイプ)で収集されるパフォーマンス。 |
|
|
リファレンス |
関連するPERFORMANCE SPECIFICATION INTERVALに含まれるPERFORMANCE SPECIFICATION INTERVALのインスタンス数を定義する変換要素。 |
|
|
リファレンス |
SERVICEまたは要素およびその両方が機能する方法を決定する尺度を定義する不変的な特性。関連する各PERFORMANCEインスタンスには、同じ不変的な特性があります。ただし、インスタンス化されたPERFORMANCEエンティティの他の特性に関連付けられている値は、各インスタンスに固有です。 |
|
|
リファレンス |
PERFORMANCE SPECIFICATIONによって表される時間の間隔。 |
|
|
リファレンス |
期間レベルの累積時間変換。 |
|
|
リファレンス |
期間レベルの時間変換。 |
|
|
リファレンス |
このエンティティは、管理デバイスまたはMANAGED HARDWAREオブジェクトの最小および最大の要件、制限または他の可変的な機能を表します。 |
|
|
リファレンス |
PHYSICAL CAPACITYあり関連付けのセマンティクスを表します。物理容量詳細は、この管理コンポーネントが含む様々なタイプのPHYSICAL CAPACITYを示す追加セマンティクスを提供し、この特定の管理コンポーネント・インスタンスに関連付けられるPHYSICAL CAPACITYの数を通知する方法を提供します。 |
|
|
リファレンス |
これは、EQUIPMENTまたは機器ホルダ・オブジェクトに格納できる様々なタイプの物理コンポーネントのベース・エンティティです。スタンドアロン・オブジェクトとしては使用できません。管理の視点から、このオブジェクトを構成部分に分割できないか、分割する必要がありません。たとえば、ASIC(またはチップ)は分割できないため、データ記憶域のテープを構成部分に分割する必要がありません。PHYSICAL LINK、PHYSICAL CONNECTOR、EQUIPMENTまたは機器ホルダではないハードウェアの一部は、このクラスのサブクラスです。 |
|
|
リファレンス |
これは、他のハードウェア・ユニットに接続して相互に信号および電力を送信するハードウェア・ユニットのタイプを表す具体エンティティです。 |
|
|
リファレンス |
このエンティティは、追加セマンティクスをMANAGED HARDWAREエンティティに追加します。関連付けられた属性は、MANAGED HARDWAREオブジェクトを削除または置換できるかどうかおよびこのアクションの実行時にアクションで電源を切断する必要があるかどうかを定義します。 |
|
|
リファレンス |
このエンティティは、管理できるハードウェア・デバイスを表します。デバイスの異なる側面(たとえば、ケーブル、コネクタ、カード、電源、デバイスをまとめて構成する他のオブジェクトなど)を結合する便利な集計ポイントを表します。そのため、デバイス自体で物理的な表現(たとえば、PHYSICAL DEVICEとして識別できる「インターネット・ゲートウェイ・ルーター」など)を使用できます。このエンティティの例には、ルーター、スイッチ、コンピュータおよび管理される他のエンドデバイスなどがあります。 |
|
|
リファレンス |
下位デバイスを含まない管理可能なハードウェア・デバイスを表すエンティティ。つまり、この物理デバイスはスタンドアロン物理デバイスです。デバイスの異なる側面(たとえば、物理構成や提供されるサービスのセットなど)を結合する便利な集計ポイントを表します。また、物理デバイス・アトミックでは、デバイス自体で物理的な表現を使用できます。このエンティティの例には、ルーター、スイッチ、コンピュータおよび管理される他のエンドデバイスなどがあります。 |
|
|
リファレンス |
1つ以上の下位デバイスを含む管理可能なハードウェア・デバイスを表すエンティティ。つまり、物理デバイスはスタンドアロン物理デバイスではありません。逆に、物理デバイスの集計を表します。この集計の各物理デバイスを管理できます。デバイスの異なる側面(たとえば、物理構成や提供されるサービスのセットなど)を結合する便利な集計ポイントを表します。また、物理デバイス・コンポジットでは、デバイス自体で物理的な表現を使用できます。このエンティティの例には、ルーター、スイッチ、コンピュータおよび管理される他のエンドデバイスなどがあります。 |
|
|
リファレンス |
すべての物理デバイス役割仕様サブクラスのエンティティ。物理デバイス役割仕様は、コア・モデルの他のエンティティとのリレーションシップを定義できます。これにより、リレーションシップの拡大を防ぐことができます。物理デバイス役割仕様エンティティは、モデルのPHYSICAL DEVICEに関連付けられている様々なタイプの役割の不変的な属性、方法、リレーションシップおよび制約を定義します。 |
|
|
リファレンス |
物理デバイス役割の指定集計のセマンティクスを取得します。 |
|
|
リファレンス |
このエンティティは、PHYSICAL DEVICEオブジェクトを作成する特定の属性、動作、リレーションシップ、制約およびセマンティクスを示します。 |
|
|
リファレンス |
このエンティティは、PRODUCTを構成する様々なタイプのハードウェアを示します。物理要素には、主に2つの目的があります。
|
|
|
リファレンス |
PHYSICAL ELEMENT SPECの特性の機能および動作を定義するエンティティ。各PHYSICAL ELEMENT SPECには、このPHYSICAL ELEMENT SPECと他の物理要素仕様を区別する重要な各種属性、方法、制約およびリレーションシップがあります。これらを物理要素仕様特性と呼びます。これらの各特性は、PHYSICAL ELEMENT SPECの特性を示すために事業レベルで使用されます。 |
|
|
リファレンス |
これは、デバイスが持つ物理的な役割です。物理要素役割は、トラフィックをルーティングする物理コンポーネントとトラフィックをルーティングする論理機能の相関を有効化します。 |
|
|
リファレンス |
物理要素を示す役割集計のセマンティクスを実装します。 |
|
|
リファレンス |
すべての物理要素役割仕様サブクラスのエンティティ。物理要素役割仕様は、モデルの他のクラスとのリレーションシップを定義できます。これにより、リレーションシップの拡大を防ぐことができます。物理要素役割仕様は、モデルの物理要素に関連付けられている様々なタイプの役割の不変的な属性、方法、リレーションシップおよび制約、PHYSICAL DEVICEまたはハードウェアのサブクラスかどうかを定義します。 |
|
|
検索 |
このエンティティは、PHYSICAL ELEMENTの不変的な特性および動作、属性、方法、制約およびリレーションシップを定義します。 |
|
|
検索 |
PHYSICAL ELEMENTオブジェクトを作成する特定の属性、動作、リレーションシップ、制約およびセマンティクスを示します。このエンティティの目的は、他のタイプの要素仕様と区別して物理要素仕様を追跡することです。このエンティティは要素の指定集計を継承するため、対応するPHYSICAL ELEMENTエンティティとともに使用できます。このエンティティとPHYSICAL ELEMENT SPEC COMPOSITEエンティティの違いは、このエンティティがスタンドアロン物理要素仕様を表すことです。PHYSICAL ELEMENT SPEC COMPOSITEエンティティは、物理要素仕様のセット(通常は階層)で実際に構成される仕様を表します。 |
|
|
検索 |
このエンティティは、物理要素オブジェクトを作成する特定の属性、動作、リレーションシップ、制約およびセマンティクスを示します。このエンティティの目的は、他のタイプの要素仕様と区別して物理要素仕様を追跡することです。 このエンティティはmodifiesElementSpec集計を継承するため、対応するPHYSICAL ELEMENT SPECエンティティとともに使用できます。このエンティティとPHYSICAL ELEMENT SPEC ATOMICエンティティの違いは、このエンティティが物理要素仕様の階層を表すことです。PHYSICAL ELEMENT SPEC ATOMICエンティティは、単一のスタンドアロン物理要素仕様を表します。 |
|
|
リファレンス |
交換可能コンポーネントを含む管理デバイスの物理コンポーネントを表します。このオブジェクト・クラスのインスタンスは、1つの地理的場所のみに存在する必要があります。機器オブジェクトは別の機器オブジェクト内にネストされる場合があるため、包含リレーションシップが作成されます。このオブジェクト・クラスをサブクラス化して、機器タイプを識別する必要があります。機器タイプを識別するため、サブクラスまたは属性の名前が使用される場合があります。 |
|
|
リファレンス |
これは、ハードウェア・エンティティの接続または配線を表す具体エンティティです。このエンティティは、ワイヤレス通信およびコネクタ・ベース通信をモデル化できます。 |
|
|
リファレンス |
トポロジ(物理)リンクの実際または将来のエンド・ポイントを表し、トポロジ・マップの物理ポートに直接対応します。物理ポートは常に別の物理オブジェクトに含まれ、それ自体では存在できません。2つの最も一般的な例は、CARDおよびCHASSISの物理ポートです。 |
|
|
リファレンス |
このエンティティは、要素ポートのPHYSICAL PORT集計のセマンティクスを定義する具体エンティティです。たとえば、依存性およびPHYSICAL PORTと他のPHYSICAL PORTの対話方法でこの特定の要素ポートを構成するPHYSICAL PORTの特性および動作を示します。 |
|
|
リファレンス |
PHYSICAL ELEMENT ROLEの指定集計のセマンティクスを取得します。 |
|
|
リファレンス |
パイプは、2つのネットワーク・リソース(TERMINATION POINTとしても抽象化される)間の抽象化されたリンクです。 |
|
|
リファレンス |
PARTY INTERACTION THREAD (PIT)の特性品質または特殊機能。 |
|
|
検索 |
PARTY INTERACTION THREAD (PIT)の特性のタイプ。 |
|
|
リファレンス |
PARTY INTERACTION THREAD (PIT)の特性の値。 |
|
|
リファレンス |
計画カレンダの期間レベル。 |
|
|
リファレンス |
計画カレンダの四半期レベル。 |
|
|
リファレンス |
計画カレンダの季節レベル。 |
|
|
リファレンス |
計画カレンダの週レベル。 |
|
|
リファレンス |
計画カレンダの年レベル。 |
|
|
リファレンス |
異なるエリアの使用可能な製品市場計画または組織事業単位の参照。 |
|
|
リファレンス |
ロイヤルティ・プログラム参加者のPRODUCT MARKET PLANの可用性を定義します。 |
|
|
リファレンス |
特定の市場セグメントのPRODUCT MARKET PLANの可用性を定義します。 |
|
|
リファレンス |
ORGANIZATION BUSINESS UNIT (店舗、アウトレットなど)で利用可能なPRODUCT MARKET PLANサブスクリプション。 |
|
|
リファレンス |
POLICY STATEMENTの正常な評価(つまり、条件を満たしている評価)の結果。結果は、製品の価格で表されます。製品提供価格アクションは、POLICY ACTIONのタイプです。 |
|
|
リファレンス |
ルールの評価を定義する1つの制約を表すPOLICY STATEMENTの一部。制約は、1つ以上の製品、製品仕様タイプ、製品価格および製品価格コンポーネントで指定されます。製品提供価格ルール条件は、POLICY CONDITIONのタイプです。 |
|
|
リファレンス |
POLICY STATEMENTの評価の結果として製品の公正な交換とみなされる金銭または他の交換媒体で表される量。 |
|
|
リファレンス |
製品、製品価格または製品仕様タイプを表すPOLICY VARIABLEのタイプ。 |
|
|
リファレンス |
PRODUCT MARKET PLANとPRODUCT INSTANCE間のリレーションシップ。この割当てを通じて、製品インスタンスに基づいて製品市場計画を設計できます。たとえば、電子メール・サービスを使用して、映画アバターのプロモーションを実行できます。この例で、事業者は、今月の電子メールの定期購読で映画アバターを無償で提供するプロモーション(IPTVまたはダウンロード)を実行できます。 |
|
|
リファレンス |
PRODUCT MARKET PLAN内の製品の標準評価料金の値引きやプレミアム料金の付いた変更された評価計画。 |
|
|
リファレンス |
製品市場計画内の製品の標準評価料金の変更、値引きまたはプレミアム料金の詳細。 |
|
|
リファレンス |
地域、小地域、ノード・タイプおよびノード名にマップするISUPシグナリングOPCおよびDPC属性。 |
|
|
リファレンス |
このエンティティは、POLICYモデルのルートです。そのため、すべてのポリシー・サブクラスが使用および参加する一般的な属性、方法およびリレーションシップを定義します。 |
|
|
リファレンス |
このエンティティは、POLICY RULEのアクション句の形成方法を表します。これは、{variable, operator, value}形式の1つのPOLICY STATEMENTで構成されます。ポリシー・アクションには、値に変数を設定するセマンティクスがあります。条件句がTRUEの場合に呼び出される成功アクションと条件句がFALSEの場合に呼び出される失敗アクションの2つのタイプのアクションがあります。 |
|
|
リファレンス |
このエンティティは、含まれるポリシー・アクション集計に必要なセマンティクスを指定します。 |
|
|
リファレンス |
これは、すべての単純なPOLICY ACTIONのベース・エンティティです。単純なPOLICY ACTIONは、単一のアクションを実行する単一のブール句で構成されます。これは、{SET | CLEAR} POLICY VARIABLE to POLICY VALUE形式の1つのPOLICY STATEMENTで構成されます。これは、POLICY STATEMENTを使用しないポリシー・アクション・ベンダーとは明確に異なります。さらに複雑なアクション構造を形成するため、ポリシー・アクション・アトミック・オブジェクトも使用できます。ポリシー・アクション・コンポジット・オブジェクトは、ポリシー・アクション・アトミック・オブジェクトのグループを含みます。このグループにより、複数のポリシー・アクション・アトミック・オブジェクトをグループとして実行できます。また、ポリシー・アクション・アトミック・オブジェクトは、複合ポリシー・アクションのセマンティクスを提供するため、1つ以上のポリシー・アクション・アトミック・オブジェクト(必要に応じて、ポリシー・アクション・コンポジット・グループ)を含むことができます。いずれの場合も、含まれるポリシー・アクション集計を使用して、集計が実行されます。 |
|
|
リファレンス |
ポリシー・アクション・アトミック、ポリシー・アクション・ベンダーまたはポリシー・アクション・コンポジット・エンティティを配置する汎用コンテナとして機能します。最初の2つは、このコンテナがグループ化するアクションを提供し、残りはPOLICY ACTIONの実行を順序付ける階層を確立します。単純および複雑なPOLICY ACTIONをこのコンテナに配置できます。各ポリシー・アクション・アトミックおよびポリシー・アクション・ベンダー・オブジェクトは、含まれるポリシー・アクション関連付けを使用して、このオブジェクトにリンクします。 |
|
|
リファレンス |
このエンティティは、ポリシー・ルールのポリシー・アクション集計に必要なセマンティクスを指定します。この集計は、このPOLICY RULEに含まれるPOLICY ACTIONのセットを定義します。 |
|
|
リファレンス |
このモデルに指定された属性でモデル化されていないPOLICY ACTIONを表す一般的な拡張メカニズムを提供します。このエンティティは、ベンダー固有の条件の内容およびフォーマットを定義する2つのプロパティ(制約および制約エンコーディング)を使用します。このオブジェクトをPOLICY RULEオブジェクトの他のPOLICY ACTIONオブジェクトとともに配置するため、3番目のプロパティ(actionResponse)で標準的な結果を提供します。標準化された拡張は、このエンティティの使用を考慮していません。 |
|
|
リファレンス |
これは、このポリシー情報を適用するポリシー・ドメインの管理エンティティを明示的に定義する関連付けクラスです。 |
|
|
リファレンス |
このエンティティは、POLICY RULEの条件句の形成方法を表します。このエンティティは、ルール固有または再使用可能なポリシー条件を表します。ポリシー条件は、形式{variable, operator, value}(通常、operatorはMATCH演算子ですが、別のタイプの演算子(compareなど)の場合があります)で構成されます。これは、「条件がTRUE(またはFALSE)」のセマンティクスを提供します。POLICY CONDITIONのサブクラスは、再帰的な集計とともに、同じ構造をサポートする単純および複合(ネストなど)POLICY CONDITIONを使用できます。 |
|
|
リファレンス |
このエンティティは、ポリシー条件のポリシー条件集計に必要なセマンティクスを指定します。この集計は、このPOLICY CONDITIONに含まれるPOLICY CONDITIONのセットを定義します。POLICY CONDITIONの包含ポリシー条件詳細エンティティおよびポリシー条件ルール詳細エンティティは、概念的に同じ属性を持ちます。このため、条件式を形成するセマンティクスが提供されます。違いは、POLICY RULEエンティティに関連する配置です。つまり、包含ポリシー条件詳細エンティティは条件句内の個々の式を結合し、ポリシー条件ルール詳細エンティティはPOLICY RULEに対する完全な条件句の表示方法を示します。これらの属性は、この付録のデータ・ディクショナリに関する項に示されています。 |
|
|
リファレンス |
これは、すべての単純なポリシー条件のベース・エンティティです。単純なポリシー条件は、単一の条件をテストする単一のブール句で構成されます。これは、形式{variable, operator, value}の1つのPOLICY STATEMENTで構成されます。この設計は、POLICY STATEMENTに依存して、条件句の実際の条件を提供します。したがって、すべてが条件句に対して正規化されるため、ポリシー条件アトミックのサブクラスは必要ありません。かわりに、適切なPOLICY STATEMENTクラスのサブクラスが提供されます。複合POLICY CONDITIONは、上位のPOLICY CONDITIONに含まれる1つ以上のPOLICY CONDITIONで構成されます。必要に応じて、POLICY CONDITION COMPOSITEオブジェクトでこれらをオプションでグループ化できます。 |
|
|
リファレンス |
POLICY CONDITION COMPOSITEエンティティは、すべての複雑なポリシー条件のベース・エンティティです。複雑なポリシー条件は、複雑なブール文を形成するPOLICY CONDITION ATOMICおよびPOLICY CONDITION COMPOSITEオブジェクトの集計で構成されます。このようなオブジェクトは、引き続き単一のTRUEまたはFALSEブール値に対して評価します。 概念的に、これは、ネストまたはグループ化された下位POLICY CONDITIONを評価する全体のコンテキストを提供する1つのPOLICY CONDITIONで構成されるスタンドアロン・オブジェクトです。 |
|
|
リファレンス |
このエンティティは、ポリシー・ルールのポリシー条件集計に必要なセマンティクスを指定します。この集計は、このPOLICY RULEに含まれるポリシー条件のセットを定義します。包含ポリシー条件詳細エンティティおよびポリシー条件ルール詳細エンティティは、概念的に同じ属性を持ちます。このため、条件式を形成するセマンティクスが提供されます。違いは、POLICY RULEエンティティに関連する配置です。つまり、包含ポリシー条件詳細エンティティは条件句内の個々の式を結合し、ポリシー条件ルール詳細エンティティはPOLICY RULEに対する完全な条件句の表示方法を示します。これらの属性は、この付録のデータ・ディクショナリに関する項に示されています。 |
|
|
ベース |
イベント詳細集計エンティティのeventConstraint属性に従って制約されるポリシー・イベントの集計を表します。このセットのポリシー・イベントは、条件句の評価をトリガーするため、1つ以上のPOLICY RULEに示されます。このエンティティは、ポリシー・サーバーなどの外部アプリケーションを使用して、POLICY RULEの評価をトリガーするために使用しているイベントのセットを動的に調整できます。 |
|
|
ベース |
POLICY RULEの条件句の評価をトリガーする単一のアトミック・イベントの発生を表します。 |
|
|
ベース |
コンポジット・イベントの発生を表します。コンポジット・イベントは、一連のポリシー・イベント・アトミック・エンティティおよびポリシー・イベント・コンポジット・エンティティで構成されるイベントです。ポリシー・イベント・アトミックのように、POLICY RULEの条件句の評価をトリガーするため、ポリシー・イベント・コンポジットも使用できます。 |
|
|
リファレンス |
このエンティティは、一般化された集計コンテナです。ポリシー・グループは、単一のコンテナにPOLICY RULEおよびPOLICY GROUPを集計できます。POLICY GROUPが他のPOLICY GROUPを含む場合、それ自体を含むPOLICY GROUPの古くなった場合を含むループは許可されていません。 |
|
|
リファレンス |
これは、POLICY GROUPに適用されるポリシー・イベント・セットに関連付けられるセマンティクスを定義する関連性エンティティです。特に、評価できるように、実行フィルタ属性を通じてこのポリシー・イベント・セットが渡されるPOLICY GROUPのコンポーネントを制御します。 |
|
|
リファレンス |
これは、POLICY STATEMENTの様々なタイプの演算子をモデル化する具体エンティティです。POLICY STATEMENTで使用する演算子のタイプを制限して、そのPOLICY STATEMENTのセマンティクスを効果的に制限できます。 |
|
|
リファレンス |
POLICY OPERATORとPOLICY VARIABLE間のリレーションシップを定義します。 |
|
|
リファレンス |
このエンティティは、使用される異なるポリシーの様々なタイプの役割の概念を定義します。 |
|
|
リファレンス |
モデル・ポリシー・ルールを形成する「イベント-条件-成功アクション-失敗アクション」セマンティクスを実現するエンティティ。このルールのセマンティクスは、ルールがイベントの発生時に評価されます。条件句を満たす場合、pass-action句が実行されます(それ以外の場合は、fail-action句が実行されます)。POLICY RULEは、POLICY RULE内にネストされる場合があります。これは、ネットワーキング(バンド幅の割当てなど)に頻繁に必要です。 |
|
|
リファレンス |
このエンティティは、2つのタイプの収集を定義します。POLICY RULEはポリシー・イベント、POLICY CONDITIONおよびPOLICY ACTIONを収集し、POLICY GROUPはPOLICY RULEおよびPOLICY GROUPを収集します。この2つの重要で強力な機能は、POLICY SETが一般的な決定戦略およびPOLICY GROUPで使用するPOLICY ROLEの一般的なセットと継承されるPOLICY RULEを定義することです。 |
|
|
リファレンス |
POLICY SET間のリレーションシップを定義します。 |
|
|
リファレンス |
このエンティティは、POLICY CONDITIONおよびPOLICY ACTIONエンティティで使用する3つの値{variable, operator, value}をモデル化します。セマンティクスは、それぞれに使用できる演算子のタイプで反映されます。条件には、「値に関連する変数」のセマンティクス(「関連」は通常一致演算子ですが、他の適用可能な演算子(比較演算子など)の可能性もあります)が必要です。アクションには、「値への変数の設定」のセマンティクスが必要です。ここで、使用できる演算子は集合演算子のみです。 |
|
|
リファレンス |
POLICY STATEMENTで発生する様々なタイプの値をモデル化する抽象ベース・エンティティ。POLICY VALUEは、設定またはクリアするか(POLICY ACTIONで使用される場合)、POLICY CONDITIONのPOLICY VARIABLEの値と一致または比較する必要がある属性を指定します。 |
|
|
リファレンス |
このエンティティは、POLICY STATEMENTを形成する様々なタイプの変数をモデル化します。変数には、条件を評価する場合に値と一致または比較する必要がある属性または概念を指定します。 |
|
|
リファレンス |
これは、この値がこの変数で制約される方法の特定のセマンティクスを定義するために使用するOCL式を含む関連付けクラスです。これには、POLICY VALUEオブジェクトで取得できる値の上限や下限などの制約が含まれます。 |
|
|
検索 |
運送業者が利用できる郵便サービス・タイプのタイプの参照。例:
|
|
|
リファレンス |
郵便番号、Zipコード(米国郵便番号)または類似の地理的な指定。 |
|
|
リファレンス |
料金後払いワイヤレスに関するPRODUCTのサブタイプ。 |
|
|
検索 |
プリペイド割引の分類の参照。例:
|
|
|
検索 |
プリペイド割引(PPA)に関連する有効な減額タイプ |
|
|
導出 |
日次のプリペイドACCOUNTアクティベーションとそのすべての初期値のサマリー。 |
|
|
導出 |
通話時間、チャージ値などを含むプリペイド・アカウント収益の月次集計。ACCOUNT、SALES CHANNEL、AGE ON NET BAND別。 |
|
|
集計 |
通話時間、チャージ値などを含むプリペイﾄﾞ・アカウントの月次サマリー。CUSTOMER SEGMENT、PRODUCT MARKET PLAN別。 |
|
|
導出 |
ACCOUNTおよびPRODUCT MARKET PLANの無料時間割引(PPA)の日次集計。 |
|
|
集計 |
PRODUCT MARKET PLANの無料時間割引(PPA)の月次サマリー。 |
|
|
導出 |
プリペイド通話の日次集計。ACCOUNT、PRODUCT MARKET PLANおよびACCESS METHOD別。 |
|
|
集計 |
プリペイド通話アクティビティの月次サマリー。PRODUCT MARKET PLAN、CUSTOMER TYPE別。 |
|
|
検索 |
プリペイド・モバイル・サブスクリプションに対して実行されるプリペイド・モバイル・イベント・タイプの参照。個々のイベント・タイプは、実装ごとに異なります。例:
|
|
|
ベース |
PREPAID VOUCHER INSTANCEをチャージするACCOUNT PAYMENTのタイプ。 |
|
|
リファレンス |
プリペイド・アカウントを補充するために顧客が購入できるバウチャ。通常、紙またはプラスチックのカードです。例:
|
|
|
リファレンス |
各バウチャ・インスタンス生成バッチによって、数千のバウチャが生成される可能性があります。 |
|
|
リファレンス |
各プリペイド・カードを表します。カードは、プリペイド・モバイルの料金をチャージする手段です。物理的には、アカウント番号とPIN (個人識別番号)コードを持つプラスチック・カードまたは紙片です。 |
|
|
導出 |
日次のプリペイド・バウチャ・チャージのサマリー。 |
|
|
リファレンス |
PREPAID VOUCHERのタイプのチャージ・オプション。バウチャは顧客に対する異なる知覚価値で構成することができ、それらのいずれか1つと交換できます。たとえば、バウチャには次のチャージ・オプションがあります。
|
|
|
リファレンス |
サービス製品のタイプ。プリペイド・ワイヤレス・サービスのみ、SERVICEのサブタイプ。 |
|
|
リファレンス |
割引グループに基づいて、現在の販売ユニット小売金額をアカウントへの請求金額に変換するための方法の指定。 |
|
|
リファレンス |
割当てを超える製品を使用した顧客のイベントなど、請求処理をトリガーする可能性があるイベントのタイプ。 |
|
|
リファレンス |
通信事業者が提供する製品。製品にはPRODUCT PACKAGE情報が含まれます。PRODUCT PACKAGEの構成は製品リレーションシップで追跡されます。 |
|
|
リファレンス |
他の既存の属性に適合しないか、異なる言語を使用するユーザーのためにカスタマイズが必要なその他の説明テキスト。 |
|
|
リファレンス |
PRODUCTと関連製品のリレーションシップの定義。 |
|
|
検索 |
PRODUCT ASSIGNMENTの有効な理由コードおよび説明の参照。 |
|
|
検索 |
PRODUCTまたはPRODUCT MARKET PLANのブランド。事業者は、同じ製品を異なる顧客セグメントに異なるブランドで提供できます。たとえば、事業者は同じGSMワイヤレス製品にビジネス、ハイエンド、エコノミカルなどのブランドを割り当てることができます。 |
|
|
リファレンス |
様々な製品の機能または特徴。例:
|
|
|
検索 |
PRODUCT CAPABILITYのタイプの参照。 |
|
|
リファレンス |
PRODUCT CAPABILITYの詳細。情報量はPRODUCT CAPABILITY TYPEごとに異なります。 |
|
|
リファレンス |
書籍やWebサイトなど、価格および図を含む販売用のPRODUCT MARKET PLANのリスト。製品カタログは、セルフケア注文プロセス中に顧客が使用可能で、1つ以上の流通チャネルで使用される場合があります。 |
|
|
リファレンス |
製品カタログ仕様の特性品質または特殊機能。 |
|
|
リファレンス |
追加プロパティ(属性)が製品カタログ仕様特性に含まれる類似したプロパティのプロパティを適用またはオーバーライドするエンティティ仕様による製品カタログ仕様特性の使用。 |
|
|
リファレンス |
特性仕様の間の集計、移行、置換、依存性または排他性リレーションシップ。 |
|
|
リファレンス |
製品カタログ特性に関連付けられている値。 |
|
|
リファレンス |
追加プロパティ(属性)が製品カタログ仕様特性値に含まれる類似したプロパティのプロパティを適用またはオーバーライドする製品カタログ仕様による製品カタログ仕様特性値の使用。 |
|
|
リファレンス |
特性仕様値の間の集計、移行、置換、依存性または排他性リレーションシップ。 |
|
|
リファレンス |
地理的領域で使用可能なPRODUCT CATALOGを定義します。 |
|
|
リファレンス |
PRODUCT CATALOGとPRODUCT CATALOGに表示される製品市場計画間のリレーションシップを定義します。 |
|
|
リファレンス |
PRODUCT CATALOG表示タイプ。例:
|
|
|
リファレンス |
エンド・ユーザーがPRODUCT CATALOGを使用可能な場所を定義します。 |
|
|
検索 |
PRODUCT CATALOGの不変的な特性を定義するタイプの参照。 |
|
|
検索 |
特定の一般的な特性に従ったPRODUCTの分類の参照。 |
|
|
リファレンス |
製品仕様の特性品質または特殊機能。特性は、色などの個々の値、一定範囲の値(100-240mVの感度など)を取得したり、式(使用時間(時) = 30 - 会話時間*3など)から導出したりできます。色などの特定の特性は、注文や他のプロセスの途中で構成される場合があります。 |
|
|
リファレンス |
追加プロパティを適用する製品仕様による特性仕様の使用。 |
|
|
リファレンス |
製品仕様特性の間の集計、移行、置換、依存性または排他性のリレーションシップ。 |
|
|
検索 |
||
|
リファレンス |
||
|
リファレンス |
追加プロパティ(属性)が製品カタログ仕様特性値に含まれる類似したプロパティのプロパティを適用またはオーバーライドする製品カタログ仕様による製品カタログ仕様特性値の使用。 |
|
|
リファレンス |
製品仕様特性の間の集計、移行、置換、依存性または排他性のリレーションシップ。 |
|
|
検索 |
PRODUCTに対するPRODUCT PACKAGE料金のタイプのコードおよび説明の参照。例:
|
|
|
リファレンス |
関連するPRODUCT CHARGE TYPEの割当て。 |
|
|
検索 |
PRODUCT CHARGE TYPEを相互に関連付けるために利用可能な理由の参照。 |
|
|
検索 |
PRODUCT RATING PLANの製品料金に利用可能な理由の参照。例:
|
|
|
ベース |
COST TYPE表の副表。特定の製品とコストの関連付けに使用されます。 |
|
|
リファレンス |
地理的領域の製品の範囲。 |
|
|
検索 |
PRODUCT COVERAGE AREAのタイプ・コードおよび説明の参照。例:
|
|
|
リファレンス |
特定のPRODUCT COVERAGE AREAに詳細な地理的な場所をリンクします。 |
|
|
リファレンス |
1つ以上のPRODUCTに関連付けられる機能。たとえば、ハンドセットの場合は次のような機能があります。
|
|
|
リファレンス |
1つ以上のPRODUCT FEATUREをPRODUCTに割り当てます。同じPRODUCT FEATUREを持つ複数の製品があります。 |
|
|
リファレンス |
有効なEQUIPMENT FUNCTIONALITYおよびPRODUCT VERSIONをPRODUCTに割り当てます。 |
|
|
リファレンス |
PRODUCTをGEOGRAPHY ENTITYに割り当てます。特に、ローカルまたは限られた地域でのみ提供される製品に使用されます。たとえば、特定の都市および郵便番号エリアのブロードバンド・サービスなどがあります(通常は都市の通信事業者に使用されます)。 |
|
|
検索 |
PRODUCTを、通常では類似する機能に基づいて、カテゴリまたはグループに割り当てます。 注意: PRODUCT MARKET PLAN GROUPエンティティとは異なりますので、混同しないでください。 たとえば、製品を次のようなカテゴリに分けることができます:
|
|
|
リファレンス |
PRODUCTおよび1つ以上のPRODUCT GROUPのリレーションシップを定義します。 |
|
|
検索 |
PRODUCT GROUPのタイプのコードおよび説明の参照。 |
|
|
リファレンス |
顧客が購入または賃借(またはPRODUCT MARKET PLANの一部として最終的に無料で取得)できる特定のPRODUCTの実際のインスタンス。製品インスタンスは顧客注文明細アイテムにリンクされ、製品と顧客を関連付けます。例:
|
|
|
ベース |
PRODUCT INSTANCEのステータスの履歴。例:
|
|
|
検索 |
特定の製品インスタンスのステータス・タイプの参照。例:
|
|
|
検索 |
事業組織に従って製品を分類する方法の参照。たとえば、ワイヤレス、固定回線などがあります。 |
|
|
ベース |
EMPLOYEE、PRODUCT MANAGEMENT ROLEおよびPRODUCT間のリレーションシップを定義します。 |
|
|
検索 |
PRODUCT MANAGEMENT HISTORYリレーションシップの利用可能な理由の参照。 |
|
|
検索 |
PRODUCT MANAGEMENT HISTORYで従業員に割り当てられる有効な役割のコードおよび説明の参照。例:
|
|
|
リファレンス |
配置、価格およびバンドル詳細を含む製品を市場に導入する方法を定義します。例:
|
|
|
リファレンス |
製品をPRODUCT MARKET PLANに割り当てます。 |
|
|
検索 |
市場計画の製品参加(取込み)のタイプの参照。例:
|
|
|
ベース |
COST TYPE表の副表。このエンティティは、特定のコストを所定のPRODUCT MARKET PLANに関連付けます。コストはPRODUCT MARKET PLANにのみ関連付けられ、CAMPAIGNまたはPROMOTIONには関連がありません。 |
|
|
リファレンス |
PRODUCT MARKET PLANと地理のリレーションシップ。一部のPRODUCTは特定の地域でのみ販売されます。 |
|
|
リファレンス |
様々なPRODUCT MARKET PLANを分類する階層レベル。例:
|
|
|
リファレンス |
PRODUCT MARKET PLANと1つ以上のPRODUCT MARKET PLAN GROUPとのリレーションシップを定義します。 |
|
|
検索 |
PRODUCT MARKET PLAN GROUPのタイプ・コードおよび説明の参照。 |
|
|
リファレンス |
2つのPRODUCT MARKET PLAN間のリレーションシップを定義します。例:
|
|
|
検索 |
PRODUCT MARKET PLANリレーションシップのタイプの参照。 |
|
|
検索 |
PRODUCT MARKET PLANのタイプ。例:
|
|
|
リファレンス |
||
|
リファレンス |
PRODUCT MARKET PLANの基盤となるバンドルされたPRODUCTのグループ。製品パッケージは顧客と直接に面するものではなく、顧客はPRODUCT MARKET PLANを通じて製品パッケージにサブスクライブします。例:
|
|
|
リファレンス |
PRODUCTをPRODUCT PACKAGEに割り当てます。 |
|
|
検索 |
PRODUCTに対するPRODUCT PACKAGE料金のタイプのコードおよび説明の参照。例:
|
|
|
リファレンス |
PRODUCTに関連する価格や用途の制限に応じたグループ分け手法。 |
|
|
リファレンス |
PRODUCT RATING PLANの詳細。PRODUCT CHARGE TYPEごとに価格および用途の制限を定義します。 |
|
|
検索 |
PRODUCT RATING PLANのタイプの参照。 |
|
|
ベース |
PRODUCTのステータスの履歴。 |
|
|
検索 |
製品ステータスのタイプの参照。 |
|
|
検索 |
PRODUCTのタイプの参照。例:
|
|
|
リファレンス |
特定の製品の顧客に割り当てられるユーザー名。例:
|
|
|
リファレンス |
||
|
リファレンス |
ビジネス活動(TASK)は、それぞれの共通の目的に従って特定のプロジェクトに分類できます。例:
|
|
|
リファレンス |
||
|
リファレンス |
プロモーションには、プロモーション・イベント中に特定の製品の売上高または使用量をさらに増やすために、事業者が取り掛かる戦略が反映されます。プロモーションは、ターゲットとなる視聴者に確実に認識してもらうように、販促キャンペーンの一部として頻繁に伝えられます。 |
|
|
ベース |
特定のCUSTOMER SEGMENT、クラスタを、特定のPROMOTIONまたはプロモーション・リストに割り当てます。顧客セグメントは、Oracle Miningなどの分析アプリケーションによって生成され、この割当てにより、PROMOTIONの顧客セグメントの使用状況が追跡されます。 |
|
|
ベース |
CONTACT LISTとPROMOTIONのリレーションシップを定義します: 連絡先リストは、特定のプロモーションが提案されたマーケティング・キャンペーンで使用されています。 |
|
|
ベース |
特定のプロモーションに一意に関連付けられる特定のコストを関連付けるために使用するCOSTのサブタイプ。たとえば、事業者がプロモーションを実行する場所の賃借料金などがあります。 |
|
|
ベース |
キャンペーン・エピソードの管理に関するキャンペーン・パーティの役割の履歴。 |
|
|
リファレンス |
市場計画をPROMOTIONに割り当てます。通常、市場計画で一定期間中に追加の割引(PROMOTION)を提供する場合に適用されます。 |
|
|
リファレンス |
各CAMPAIGN MESSAGEのMEDIA OBJECTによるブロードキャストに関する詳細。 |
|
|
リファレンス |
||
|
リファレンス |
PRODUCT CATALOGをPROMOTIONに関連付けます。 |
|
|
リファレンス |
2つのPROMOTION間のリレーションシップを定義します。 |
|
|
検索 |
販売キャンペーン中の特定のPROMOTIONに対する見込み客の反応の参照。例:
|
|
|
リファレンス |
各SALES CHANNELへのPROMOTIONリソースまたはアクションの割当て。 |
|
|
検索 |
PROMOTION TERM VALUEに関連付けられたプロモーション期間の有効なタイプ・コードおよび説明の参照。例:
|
|
|
ベース |
PROMOTION TERM TYPEを、Term Typeに対応する値を持つPROMOTIONに割り当てます。例:
|
|
|
検索 |
PROMOTIONのタイプの参照(限られた時間または契約期間のいずれか)。例:
|
|
|
リファレンス |
定義された法的境界の一区画の土地。これは、地理的場所の具体エンティティです。 |
|
|
リファレンス |
所有地と所有地を識別するために使用される住所所在地のリレーションシップを定義します。 |
|
|
リファレンス |
プロモーションの見込み客が利用可能な提案。新製品の販売などのアップセルの提案またはリテンション・プログラム(長期契約期間の無料時間)の可能性があります。 |
|
|
リファレンス |
2つのPROPOSAL間のリレーションシップ。 |
|
|
リファレンス |
現在は商品やサービスを購入していないが、将来購入する可能性がある個人、個人の集合、会社または公的機関。見込み客は、まだ特定のPRODUCTを購入していないが(購入する可能性がある)、別のPRODUCT(すでに購入済)のCUSTOMERである場合があります。 見込み客には、プロバイダとの関係に関する記録はありません。 |
|
|
リファレンス |
組織ではない個人のPROSPECTの属性。 |
|
|
リファレンス |
組織の見込み客の属性。 |
|
|
検索 |
見込み客および見込み客の対象に割り当てることができる異なる優先順位。 |
|
|
リファレンス |
PROSPECTに適用できる品質スコアのタイプの参照。例:
|
|
|
リファレンス |
様々なタイプの基準で見込み客ごとに割り当てられる品質スコア値。 |
|
|
検索 |
提案またはPROPOSALが見込み客によって拒否される理由の説明。 |
|
|
リファレンス |
2つのエンティティで情報を交換する方法(通常、1つ以上のタイプのネットワーク・メディア上)を管理するルールおよび規則の公式セット。このエンティティは、管理できるプロトコルを表します。プロトコルを管理および使用する方法を定義する便利な集計ポイントを表します。 |
|
|
ベース |
有料テレビの全チャネルのアクティベーション・イベント。 |
|
|
ベース |
QPIサービスの詳細。 |
|
|
ベース |
PAY TVサービスの顧客の使用量。 |
|
|
リファレンス |
CAMPAIGNで使用するMEDIA OBJECTが属する広告。 |
|
|
検索 |
広告のタイプについてのコードおよび説明の参照。 |
|
|
ベース |
事業組織(購入組織)の購入単位によってサプライヤで発生するすべての発注。発注のタイプは多く、通常はワンタイム、標準、一括、リリースなどが含まれます。 |
|
|
ベース |
発注明細アイテム情報を指定します。 |
|
|
ベース |
各PURCHASE ORDER LINE ITEMの状態変更履歴を指定します。 |
|
|
ベース |
一定期間特定の状態であるPURCHASE ORDER LINE ITEMのレコードを定義します。 |
|
|
検索 |
発注または明細アイテムの状態の異なるタイプの参照。例:
|
|
|
リファレンス |
単一または一連のビット文字列値を表します。ビット文字列は、個々の文字が値「0」または「1」を持つ文字列として定義されます。他の値は使用できません。 |
|
|
リファレンス |
ブール値(TRUEまたはFALSE)を表します。 |
|
|
リファレンス |
整数または整数範囲値のリストを提供します。各整数は任意のサイズである可能性があります。 |
|
|
リファレンス |
ポリシー条件に一致するIPv4アドレス、IPv6アドレス、IPv4アドレス範囲、IPv6アドレス範囲およびホスト名の順序付けされていないリストを提供します。各文字列のフォーマットは、IPv4アドレスのABNF定義に従って指定します。ホスト名を別の有効なIPアドレスと照合する場合、ホスト名を有効なIPv4またはIPv6アドレスで解決して照合が行われます。相互のIPアドレス(同じタイプ)の照合などの相互のホスト名の照合は、文字列の比較を使用して行われます。IPv4アドレスとIPv6アドレスの照合は失敗します。 |
|
|
リファレンス |
単一の文字列値または一連の文字列値を表します。各値にワイルドカードを使用できます。 |
|
|
リファレンス |
単一または一連のビット文字列変数を表します。そのため、このPOLICY VARIABLEの条件式の値部分で、ビット文字列値クラスのみ使用できます。 |
|
|
リファレンス |
単一または一連の文字列変数を表します。それぞれワイルドカードを使用できます。そのため、このPOLICY VARIABLEの条件式の値部分で、文字列値クラスのみ使用できます。 |
|
|
リファレンス |
特定のタイプのQoSを実装するために必要な様々なタイプのサブサービスを定義する汎用仕様を表します。これにより、ネットワークにビジネス・ルールをマップし、ネットワークで提供されるサービスを定義できます。 QoSサービスは、SERVICE BUNDLEなどで指定された機能を実現するために必要なサブサービスの集計とみなすことができます。これにより、ネットワーク管理者は、詳細な抽象オブジェクトまたは一連のオブジェクトで指定されるビジネス・ルールをネットワークにマップでき、ネットワーク設計者は、ネットワークで様々なタイプのアプリケーションの異なる機能を提供するためにネットワークを設計できます。 QoSサービスはRESOURCE FACING SERVICEのタイプで、SERVICE BUNDLEを使用して一緒にバンドルされます。SERVICE BUNDLE SPECを使用して、QoSサービスをテンプレートに変換できます。 QoSサービス自体は、DiffServ、ToS、IEEE 802.xなどのQoSを実装する様々なテクノロジ固有の方法を調整する手段です。そのため、QOSサービス・エンティティは抽象エンティティです。 |
|
|
|
検索 |
QOS SERVICE仕様タイプ。 |
|
リファレンス |
時間階層で定義された15分。 |
|
|
リファレンス |
四半期レベルの累積時間変換。 |
|
|
リファレンス |
四半期に関する変換。例:
|
|
|
リファレンス |
ラックは、CHASSISなどの機器ホルダを配置する筐体を表すセキュア・ホルダのタイプです。通常、ラックは筐体にすぎず、すべての機能コンポーネントはCHASSISにパッケージ化されます。通常、ラックの論理識別子はデバイス(ネットワーク要素)に関連付けられません。これを論理識別子がデバイスに関連付けられているベイまたは棚と比較します。そのため、ラックはネットワークの論理モデルの一部ではありません。通常、ラックはCHASSIS、棚およびベイの「マスター筐体」として機能します。また、ラックは、複数のデバイスの複数のインスタンスをマウントできます。 |
|
|
検索 |
各イベント・タイプの有効な候補となる評価可能単位測定(RUM)の指定の参照。例:
|
|
|
ベース |
RAWまたは調整済ネットワーク・イベントに関連付けられている評価情報を含みます。 |
|
|
検索 |
評定法タイプのコードおよび説明の参照。例:
|
|
|
ベース |
ネットワーク要素で取得されるRAW MMS EVENT。 |
|
|
ベース |
RAW WIRELESS CALL EVENT。 |
|
|
|
リファレンス |
このクラスは、ElementFacingServiceに対して一連のServiceSpecificationRolesでSERVICE SPECを定義します。これは、ElementFacingServiceの可変的な特性を表すために使用されるServiceSpecificationRolesを定義するベース・クラスです。これにより、ServiceSpecificationRolesを使用してElementFacingServiceを抽象的に管理できます。また、所有または提供する機能でSERVICE SPECを定義できます。 |
|
検索 |
プリペイド用のチャージ・クーポンから得た収益バンドの参照(チャージ収益と呼ばれています)。現在のすべてのアクティブなプリペイド・サブスクライバおよび解約時点までのすべてのチャーン・サブスクライバのチャージ収益が分析されます。 たとえば、$0-$25、$25-$50などのチャージ収益のグループを作成して収益をまとめることができます。 |
|
|
リファレンス |
繰返し料金を使用したPRODUCT MARKET PLAN(PMP)評価計画のタイプ。 |
|
|
導出 |
ロイヤルティ・ポイントの償還の日次集計。CREDIT CATEGORY、LOYALTY PROGRAM CHANNEL、AGE ON NET BANDおよびEMPLOYEE別。 LOYALTY PROGRAMの償還統計の日次集計。LOYALTY PROGRAM CHANNEL、SALES CHANNEL、AGE ON NET BAND、CREDIT CATEGORYおよびEMPLOYEE別。 |
|
|
集計 |
LOYALTY PROGRAM CHANNEL別のLOYALTY PROGRAMの償還統計の月次サマリー。 |
|
|
検索 |
償還タイプの参照。分析のために、可能なすべてのポイント償還タイプを管理し、償還タイプ別に償還データを整理します。 |
|
|
検索 |
宗教の参照。例:
|
|
|
リファレンス |
これは、リソース対応サービスを定義するベース・エンティティです。リソース対応サービスは、顧客によって直接確認または購入されない特定のSERVICEの特性および動作を定義する抽象です。リソース対応サービスは、CUSTOMER FACING SERVICEをサポートするために必要な「内部」サービスです。顧客はCUSTOMER FACING SERVICEを購入し、顧客が直接購入しているCUSTOMER FACING SERVICEをサポートするリソース対応サービスを認識しません。たとえば、VPNはCUSTOMER FACING SERVICEの例です。特定のタイプのVPNでは、サポートするBGPが必要になる場合があります。顧客はBGPを購入せず、BGPの実行を認識しません。そのため、BGPはりソース対応サービスの例です。 |
|
|
リファレンス |
RESOURCE FACING SERVICEに対して一連のSERVICE ROLEでSERVICEを定義します。これは、このSERVICEの役割でRESOURCE FACING SERVICEの可変的な特性を表すSERVICE ROLEを定義するベース・エンティティです。このエンティティは、SERVICE ROLEを使用してRESOURCE FACING SERVICEを抽象的に管理できます。また、リソース対応サービス役割は、所有または提供する機能でSERVICEを定義できます。 |
|
|
検索 |
これは、リソース対応サービス仕様を定義するベース・エンティティです。リソース対応サービス仕様は、特定のRESOURCE FACING SERVICEの不変的な特性および動作を定義する抽象です。これは顧客に示されません。ただし、正しく機能させるため、1つ以上のCUSTOMER FACING SERVICE SPECで必要です。不変的な部分は、この一般的なリソース対応サービス仕様をすべて使用する一連の可変的なRESOURCE FACING SERVICEを作成する単一の共通基盤として役立ちます。 |
|
|
検索 |
このエンティティは、特定のCUSTOMER FACING SERVICEの要件を満たすスタンドアロンRESOURCE FACING SERVICEを定義します。スタンドアロンRESOURCE FACING SERVICEは、CUSTOMER FACING SERVICEに直接リンクしたり、リソース対応サービス・コンポジットで集計したりする場合があります。 |
|
|
検索 |
このエンティティは、CUSTOMER FACING SERVICEの要件をまとめて満たすRESOURCE FACING SERVICEの統合セットを定義します。たとえば、顧客は、それぞれに固有のQoSを持つ一連のSERVICE BUNDLEを定義するSERVICE PACKAGEである「GoldService」をリクエストする場合があります。SERVICE BUNDLEインスタンスごとに必要なQoSを提供する異なる各SERVICE BUNDLEインスタンスに1つ、一連のリソース対応サービス製品を定義できます。 |
|
|
リファレンス |
RESOURCE FACING SERVICEに対して、一連のサービス仕様役割でサービス仕様を定義します。これは、RESOURCE FACING SERVICEの不変的な特性を表すサービス仕様役割を定義するベース・エンティティです。このエンティティは、サービス仕様役割を使用してRESOURCE FACING SERVICEを抽象的に管理できます。また、リソース対応サービス役割は、所有または提供する機能でサービス仕様を定義できます。 |
|
|
リファレンス |
RESOURCE FACING SERVICE SPECの履歴バージョンを保持します。 |
|
|
ベース |
サービスをプロビジョニングする要素に分解されるサービス注文のサービスを表すリクエストのタイプ。 |
|
|
ベース |
NETWORK ELEMENT TYPEまたはNETWORK ELEMENTで表されるRESOURCE ORDERの目的。 |
|
|
リファレンス |
要素が機能する方法の尺度。 |
|
|
検索 |
要素が機能する方法の尺度の不変的な特性。関連する各PERFORMANCEインスタンスには、同じ不変的な特性があります。ただし、インスタンス化されたPERFORMANCEエンティティの他の特性に関連付けられている値は、各インスタンスに固有です。 |
|
|
リファレンス |
PERFORMANCE SPECIFICATIONを定義する要素仕様の役割。 |
|
|
リファレンス |
リソース・ポートは、単一のエンティティとして一緒に管理する論理ポートおよび物理ポートを含みます。 |
|
|
リファレンス |
内部組織のサブタイプ。通常、通信サービス・プロバイダが製品を展示し、顧客に直接販売する店舗のリストです。小売店には複数のSELLING LOCATIONが含まれる場合もあります。 |
|
|
リファレンス |
すべての携帯電話会社または無線(RF)通信事業者の参照リスト。 |
|
|
導出 |
無線(RF)ネットワーク容量の利用統計の日次集計。 無線(RF)インタフェースは、ネットワークに2つのレベルで存在します:
|
|
|
集計 |
無線(RF)ネットワーク容量の利用統計の月次サマリー。 |
|
|
リファレンス |
modifiesRFSSpec集計のセマンティクスを定義します。特に、アプリケーションを使用して、特定のタスクに対して適切なこのリソース対応サービス仕様のバージョンのセットを定義できます。 |
|
|
リファレンス |
SUPPLEMENTARY SERVICEの副表。携帯電話の着信音として音楽をダウンロードできます。 |
|
|
検索 |
通話を分類する様々なローミング・タイプの参照。例:
|
|
|
リファレンス |
これは、様々なタイプの役割の概念を定義する抽象ベース・エンティティです。 |
|
|
リファレンス |
組織内の職種間の階層。 |
|
|
リファレンス |
ほとんどのポリシー・エンティティの抽象を提供します。ルート・エンティティ・プロパティは、環境内で管理が可能および不可能なすべてのオブジェクトの名前付け、説明および識別を実行できます。 |
|
|
リファレンス |
このエンティティは、管理できる様々なタイプのルーテッド・プロトコルを表します。ルーテッド・プロトコルは、ルーターでルーティングできるプロトコルです。特に、ルーターは、ルーテッド・プロトコルで指定される論理的な相互ネットワークを解釈できるようにする必要があります。ルーテッド・プロトコルを管理および使用する方法を定義する便利な集計ポイントを表します。 |
|
|
リファレンス |
IPベース・ネットワークのルーティング機能を実行する物理デバイスのタイプ。 |
|
|
リファレンス |
INネットワークまたはワイヤレスでは、VLR、HLR、SCPサーバーなどの多数の異なるタイプのデバイスがネットワークで利用されてコールをルーティングします。このエンティティはデバイス情報を追跡します。 |
|
|
リファレンス |
このエンティティは、管理できる様々なタイプのルーティング・プロトコルを表します。ルーティング・プロトコルを使用して、情報のルーティング方法(たとえば、中間システムの横断方法など)を決定します。このエンティティは、ルーティング・プロトコルを管理および使用する方法を定義する便利な集計ポイントを表します。 |
|
|
リファレンス |
LOGICAL DEVICEの使用に必要な異なるルーティング機能を示す抽象エンティティ。このエンティティにより、多くの異なる機能セットを持つネットワーク・デバイスのモデル化を簡略化できます。たとえば、ほとんどのルーターでトラフィックのルーティング、転送およびファイアウォールを実行できます。これらの機能を3つの役割にモデル化することで、ルーターによるルーティングおよびL3スイッチによるルーティングの違いを区別するため、ルーター機能が抽象化および分類されます。 |
表2-28 エンティティの説明(SからV)
| エンティティ名 | タイプ | 説明 |
|---|---|---|
|
導出 |
PROMOTION RESULT TYPEおよび販売キャンペーン・クライアント・コード別のキャンペーン結果の日次集計。 |
|
|
集計 |
PRODUCT MARKET PLAN、CAMPAIGN CHANNEL、PROMOTION RESULT TYPE別の販売キャンペーンの月次サマリー。 |
|
|
リファレンス |
販売のためにパーティとの対話に使用されるチャネル。例:
販売チャネルは、チャネル・レベルによって示され、チャネル・ディメンションの最下位レベルになります。 |
|
|
ベース |
どのSALES CHANNELの履歴をどのSALES COMMISSION PLANに適用できるかを定義します。 |
|
|
リファレンス |
顧客に製品を販売する営業担当者。例:
|
|
|
ベース |
契約によって販売代理店が取得した販売手数料。 |
|
|
ベース |
販売代理店に発行される販売手数料。 |
|
|
リファレンス |
特定のPRODUCT PACKAGEおよび販売代理店レベルの販売手数料計画。 |
|
|
リファレンス |
PRODUCT MARKET PLANおよびPROMOTIONについてのSALES COMMISSION PLAN。販売ノルマおよび手数料率などが含まれます。 |
|
|
導出 |
SALES CHANNEL、PRODUCT MARKET PLAN、事業単位、営業担当者、CUSTOMER別の売上の日次集計。 |
|
|
集計 |
SALES CHANNEL、PRODUCT MARKET PLAN、事業単位、営業担当者別の売上の月次サマリー。 |
|
|
導出 |
売上、手数料などによって測定される営業担当者の実績の月次サマリー。 |
|
|
|
検索 |
すべての子に対するSCD2およびLANGUAGEサポートを提供するスーパー・エンティティ。 |
|
リファレンス |
調査の際に個人に提示される、分類された特定の質問または意見のリスト。 |
|
|
リファレンス |
イニシアチブの一部として、顧客に関する質問をイニシアチブの質問として記録します。 |
|
|
検索 |
スクリプト・アイテムの分類に使用される値の範囲。例:
|
|
|
検索 |
シーズンとその属性。シーズンは任意の期間であり、その周辺でプロバイダが売買パターンを体系化します。それぞれの日は、1つのシーズンに含まれます。 |
|
|
リファレンス |
時間階層に定義された秒の階層レベル。 |
|
|
リファレンス |
このエンティティは、RACKおよびCHASSISエンティティの親として機能するホルダ・コンポジットのタイプです。このエンティティは、RACKおよびCHASSISに適用する一般的なプロパティを一般化します。 |
|
|
検索 |
ITEMに関連付けられるセキュリティ要件のタイプおよび説明の参照。 |
|
|
リファレンス |
ACCOUNT SEGMENTまたはCUSTOMER SEGMENTに関連する各セグメントの最小および最大スコア。 |
|
|
検索 |
ACCOUNT SEGMENTATION MODELまたはCUSTOMER SEGMENTATION MODELの定義に使用されるタイプ・コードおよび説明の参照。 |
|
|
リファレンス |
RETAIL STOREで商品の販売または展示のために専用に使用される物理的な場所。 |
|
|
検索 |
SELLING LOCATIONの定義に使用されるタイプ・コードおよび説明の参照。例:
|
|
|
リファレンス |
サービスは、エンド・ユーザーが使用可能なPRODUCTの内部の技術的な表現です。様々な顧客は、同じ製品名の異なるサービスをサブスクライブする場合があります。たとえば、4MBブロードバンドのサービスでは、サービスがADSLサービスまたはFTTH(光ファイバ)で実装される可能性があります。 |
|
|
リファレンス |
概念的に、サービス・バンドルは、要素対応サービス仕様のコレクションとみなされます。このエンティティは、異なるセットの要素対応サービス仕様の要件をグループ化できるため、「バンドル」という名前が付けられています。これらはリソース対応仕様のため、特定のCUSTOMER FACING SERVICE(SERVICE PACKAGEで表されます)で必要な要素対応サービスを実装する再使用可能なテンプレートを定義します。サービス・バンドルは、CUSTOMER FACING SERVICEで必要な一連のサービスのクラス仕様をまとめて定義するために設計されました。SERVICE PACKAGEは、CUSTOMER FACING SERVICEの要件をモデル化するエンティティです。そのため、SERVICE PACKAGEでは、顧客に販売される様々なパッケージのCUSTOMER FACING SERVICEを指定でき、サービス・バンドルでは、各CUSTOMER FACING SERVICEで必要な要素対応サービスのセットを指定します。サービス・バンドルは、SERVICE PACKAGEの要件を実装する一般的な方法で、サービス・バンドルを使用するサービス・パッケージ集計を通じてSERVICE PACKAGEに関連付けられます。 |
|
|
リファレンス |
サービス・バンドル仕様は、顧客(または他の適切なPARTY ROLE)でサブスクライブできるバンドルされた要素対応サービス仕様の異なるクラスを定義するベース・エンティティです。この性質の顧客サブスクリプションを表す推奨方法は、使用している要素対応サービス仕様のセットを定義するサービス・バンドル仕様を定義することです。概念的に、サービス・バンドル仕様は、異なるセットの要素対応サービス仕様の要件をグループ化できるコレクションとみなされます。「バンドル」は、関連付けられてグループ化されたサービス仕様の概念を表します。これらはリソース対応仕様のため、特定のCUSTOMER FACING SERVICE(SERVICE PACKAGEで表されます)で必要な要素対応サービスを実装する再利用可能なテンプレートを定義します。 |
|
|
リファレンス |
サービス・バンドル仕様アトミック・オブジェクトは、個別の要素対応サービス仕様の一連の異なるインスタンスとして様々なSERVICE BUNDLE SPECをモデル化します。これは、他の既存のSERVICE PACKAGE SPEC(および固有の拡張機能)の組合せとして1つのSERVICE BUNDLE SPEC COMPOSITEをモデル化するSERVICE BUNDLE SPEC COMPOSITEエンティティとは基本的に異なります。たとえば、SERVICE PACKAGE SPECではなくサービス・パッケージのサブクラスであるゴールド・パッケージ・サービスに2つの異なるCoSサービス・インスタンスが必要であるとします。ゴールド・パッケージ・サービスが2つの異なるタイプのトラフィック条件メカニズムを必要とする2つの異なるグループのアプリケーションを含む可能性があります。これはサービス・バンドル仕様アトミック・オブジェクトで表されます。ここで、プラチナ・パッケージ・サービスにゴールド・パッケージ・サービスおよび新しい一連のトラフィック条件メカニズムを必要とする新しいサービスが含まれていると仮定します。これには、ユーザーが最初のサービス・バンドル仕様アトミック・オブジェクトを再使用するため、2つめのサービス・バンドル仕様アトミック・オブジェクトが必要です。これらを集計して、SERVICE BUNDLE SPEC COMPOSITEエンティティのインスタンスを形成できます。 |
|
|
リファレンス |
サービス・バンドル仕様コンポジットは、要素対応サービス仕様コンポジット・エンティティの要件をまとめて満たすSERVICE BUNDLE SPECの統合セットを定義します。これは、他の既存のSERVICE PACKAGE SPEC(および固有の拡張機能)の組合せとして1つのサービス・バンドル仕様をモデル化するサービス・バンドル仕様アトミック・オブジェクトとは基本的に異なります。たとえば、SERVICE PACKAGE SPECではなくSERVICE PACKAGEのサブクラスであるゴールド・パッケージ・サービスに2つの異なるCoSサービス・インスタンスが必要であるとします。ゴールド・パッケージ・サービスが2つの異なるタイプのトラフィック条件メカニズムを必要とする2つの異なるグループのアプリケーションを含む可能性があります。これはSERVICE BUNDLE SPEC ATOMICエンティティで表されます。ここで、プラチナ・パッケージ・サービスにゴールド・パッケージ・サービスおよび新しい一連のトラフィック条件メカニズムを必要とする新しいサービスが含まれていると仮定します。これには、ユーザーが最初のSERVICE BUNDLE SPEC ATOMICエンティティを再使用するため、2つめのSERVICE BUNDLE SPEC ATOMICエンティティが必要です。これらを集計して、サービス・バンドル仕様コンポジット・オブジェクトのインスタンスを形成できます。 |
|
|
|
リファレンス |
これは関連性エンティティです。このエンティティは、特定のSERVICEを使用して事業関係者の所有、使用、他のリレーションシップなどのセマンティクスを表します。 |
|
検索 |
SERVICEのカテゴリの参照。例:
|
|
|
リファレンス |
このエンティティは、このサービス仕様の主な機能を表します。たとえば、バンド幅は、多くの様々なタイプのサービスの特性を示します。バンド幅が重要な場合(このサービスを購入する顧客の視点などから)、バンド幅はその特定のSERVICEのサービス特性である可能性があります。この例では、バンド幅を複数のサービスで使用する不変的な機能として定義する必要があります。それ以外の場合は、サービス特性として定義する必要があります。 |
|
|
リファレンス |
追加プロパティ(属性)がサービス仕様特性に含まれる類似したプロパティのプロパティを適用またはオーバーライドするサービス仕様によるサービス仕様特性の使用。 |
|
|
リファレンス |
サービス仕様特性の間の集計、移行、置換、依存性または排他性のリレーションシップ。 |
|
|
リファレンス |
サービス仕様特性値オブジェクトは、サービス仕様特性オブジェクトの対応する一連の属性に1つずつ割り当てることができる一連の属性を定義します。サービス仕様特性値オブジェクトの属性の値は、対応するサービス仕様特性オブジェクトで取得できる属性の値を示します。 |
|
|
リファレンス |
追加プロパティ(属性)がサービス仕様特性値に含まれる類似したプロパティのプロパティを適用またはオーバーライドするエンティティ仕様によるサービス仕様特性値の使用。 |
|
|
リファレンス |
サービス仕様特性値の間の集計、移行、置換、依存性または排他性リレーションシップ。 |
|
|
検索 |
サービスのクラス。QoSのため、コールを異なるクラスに分類できます(基本的には、家庭用回線または事業用回線など)。また、サービス・クラスは、回路線を利用している回線またはIPパケットなど、他の観点から分類することもできます。 |
|
|
検索 |
SERVICE CLASSを定義するタイプまたはベースの参照。 |
|
|
リファレンス |
特定の製品の組合せによりサービス・プロバイダが活動する地理的エリア。 サービス・エリアを定義することで、サービス・プロバイダは、ネットワークが対応する地理的範囲の人口統計/心理的/住民に関するデータを測定できます。 |
|
|
検索 |
SERVICE COVERAGE AREAのタイプ・コードおよび説明の参照。 |
|
|
リファレンス |
最下位レベルのサービス範囲に関する詳細。例:
|
|
|
リファレンス |
サービス間の依存性。GSMローミングがHLRサービスに依存してサブスクリプション・ステータスを決定し、同様に複数のADSLサービスがコアIPネットワークに依存して情報を転送するなど、サービスの機能が外部に依存する場合があります。 |
|
|
リファレンス |
特定の要素対応サービスを特定のDEVICE INTERFACEに実装する方法を表すセマンティクスを取得します。 |
|
|
リファレンス |
EQUIPMENT INSTANCEによって結合されるSERVICEとNETWORK TOUCHPOINTに基づいた、NETWORK TOUCHPOINT、EQUIPMENTおよびSERVICE間の割当て。 |
|
|
リファレンス |
可用性、バンド幅などを含むサービス品質を指定する顧客とサービス・プロバイダ間の契約を保持する契約の特別なタイプ。サービス・レベル契約の詳細条件は、CONTRACT TERM VALUEで指定します。 |
|
|
リファレンス |
SERVICE LEVEL AGREEMENTの詳細明細アイテム。 |
|
|
検索 |
すべてのサービス・レベルのタイプの参照。たとえば、サービス・レベルの分類はゴールド、シルバー、ブロンズの可能性があります。 製品ごとに様々なサービス・レベル契約設定を使用する場合があります。 |
|
|
ベース |
SERVICE LEVEL AGREEMENTに対する違反ごとの顧客事例。 |
|
|
リファレンス |
パラメータおよびパラメータに関連付けられているメトリック、しきい値および許容範囲で定義されるサービス・レベル仕様の品質目標。 |
|
|
リファレンス |
サービス・レベル仕様、サービス・レベル目的またはサービス・レベル仕様結果を緩和するまたは緩和しない時刻または日。 |
|
|
リファレンス |
SERVICE LEVEL OBJECTIVEが満たされていない場合に発生するアクション。 |
|
|
リファレンス |
サービス・レベル目的のコンプライアンスを決定する値の変数を指定します。 |
|
|
リファレンス |
目的が満たされていない場合の事前定義済または交渉済の一連のサービス・レベル目的および発生する結果。 |
|
|
検索 |
サービス・レベル要件が満たされていない場合の結果のタイプの参照。 |
|
|
リファレンス |
これは関連性エンティティです。サービスLR依存性は、LOGICAL ELEMENTで特定の要素対応サービスを提供またはサポートする場合に存在するセマンティクス(存在、使用および他のリレーションシップなど)を表します。 |
|
|
リファレンス |
ネットワーク要素でサービスをサポートする方法を定義します。 |
|
|
ベース |
製品が認識されるサービスに分解される顧客注文の製品を表すリクエストのタイプ。 |
|
|
ベース |
SERVICE SPECまたはサービスで表されるSERVICE ORDERの目的。 |
|
|
リファレンス |
サービス・パッケージは、関連付けられているSERVICE PACKAGE SPECから導出されます。SERVICE PACKAGE SPECは、導出されるすべてのサービス・パッケージ・インスタンスの不変的な属性、方法、リレーションシップおよび制約を定義します。このエンティティにより、個々のサービス・パッケージでアプリケーション固有の変更可能な特性および動作を追加できます。特定のサービス・パッケージを導出元のSERVICE PACKAGE SPECに関連付けるために使用される特定の集計はありません。SERVICE PACKAGE SPECおよびサービス・パッケージの両方でサービスの指定集計を継承するため、この(事業レベルの)ビューで、このリレーションシップを表すために必要な新しいセマンティクスはありません。最後に、コンポジット・パターンをサービス・パッケージに適用できる可能性がありますが、それを実行する必要はありません。複数のサービス・パッケージは製品バンドルによって集計されますが、個別の製品コンポーネントとして表示されます。 |
|
|
|
リファレンス |
サービス・バンドルでSERVICE PACKAGEを実装する方法を定義します。 |
|
リファレンス |
サービス・バンドルのタイプでSERVICE PACKAGEの他のタイプをサポートできる方法を定義します。 |
|
|
検索 |
サービス・パッケージ仕様は、1つ以上の製品仕様で指定された機能を満たす一連の異なるCUSTOMER FACING SERVICE SPECをバンドルする概念を定義します。このエンティティは、複数のPRODUCTを関連付けられた製品仕様から作成するため、これらのCUSTOMER FACING SERVICEの不変的な特性および動作を指定できます。単一のオブジェクトとしてこのセットのCUSTOMER FACING SERVICE SPECを処理することは、VPNなどの複雑なサービスを作成するために重要です。このエンティティは、製品アイテムが顧客の必要とする機能を提供する一連の異なるCUSTOMER FACING SERVICEで実際に構成されていても、製品仕様から最終的に導出される単一の製品アイテムを顧客に提供できます。 |
|
|
検索 |
サービス・パッケージ仕様アトミック・オブジェクトは、個別のCUSTOMER FACING SERVICE SPECの一連の異なるインスタンスとして様々なSERVICE PACKAGE SPECをモデル化します。これは、他の既存のSERVICE PACKAGE SPEC(および固有の拡張機能)の組合せとして1つのSERVICE PACKAGE SPECをモデル化するサービス・パッケージ仕様コンポジット・オブジェクトとは基本的に異なります。たとえば、ゴールド・パッケージ仕様はサービスの個々のパッケージであるため、サービス・パッケージ仕様アトミック・エンティティのインスタンスです。ゴールド・パッケージ仕様で定義されたサービスとプラチナ・パッケージ仕様などの別のサービス・パッケージ仕様アトミック・エンティティで定義されたサービスを結合したサービスがある場合、サービス・パッケージ仕様コンポジット・エンティティのインスタンスを形成して、この組合せを集計できます。 |
|
|
検索 |
これは、他の既存のSERVICE PACKAGE(および固有の拡張機能)の組合せとして異なるパッケージをモデル化します。これは、一連の異なるインスタンスとして様々なSERVICE PACKAGEをモデル化するサービス・パッケージ・アトミックとは基本的に異なります。 |
|
|
リファレンス |
SERVICEが機能する方法の尺度。 |
|
|
検索 |
SERVICEが機能する方法の尺度の不変的な特性。関連する各PERFORMANCEインスタンスには、同じ不変的な特性があります。ただし、インスタンス化されたPERFORMANCEエンティティの他の特性に関連付けられている値は、各インスタンスに固有です。 |
|
|
リファレンス |
これは関連性エンティティです。サービスPR依存性は、PHYSICAL ELEMENTで特定のRESOURCE FACING SERVICEを提供またはサポートする場合に存在するセマンティクス存在、使用および他のリレーションシップなど)を表します。 |
|
|
ベース |
PARTY INTERACTION THREADのサブタイプ。顧客フィールド・サービス・サポート注文をトリガーするサービス・リクエスト専用です。 |
|
|
リファレンス |
このエンティティは、一連の役割でSERVICEを定義します。要素対応サービスおよび顧客対応サービスに関係なく、役割を使用してサービスの機能の特性を示します。サービス役割はサービスの機能を表し、サービスの不変的および可変的な特性および動作の組合せです。サービス役割でSERVICEを表すと、事業関係者、PHYSICAL ELEMENT、LOGICAL ELEMENTまたは他のサービスと区別してSERVICEの機能を定義できます。 |
|
|
リファレンス |
このエンティティは、一連の役割でサービス仕様を定義します。リソース対応サービスおよび顧客対応サービスに関係なく、役割を使用してサービスの不変的な機能の特性を示します。サービス仕様役割は、サービスの不変的な機能を表します。サービス仕様役割でSERVICEを表すと、事業関係者、ネットワーク要素または他のサービスと区別してSERVICEの機能を定義できます。 |
|
|
リファレンス |
このエンティティは、ServiceSpecification階層を定義します。すべてのサービスは、顧客が直接表示可能および使用可能かどうかの特性で示されます。これにより、サービスの2つのサブクラス、CUSTOMER FACING SERVICEおよびElementFacingServiceが発生します。ただし、サービスの各インスタンスは、可変的および不変的な属性、方法、リレーションシップおよび制約で構成されます。ServiceSpecificationは、サービスの不変的な特性を定義します。異なるサービス・インスタンスをインスタンス化できるテンプレートとして概念的にみなすことができます。これらの各サービス・インスタンスには、同じ不変的な特性があります。ただし、インスタンス化されたサービスの他の特性は各インスタンスに固有です。 このエンティティは、特定のタイプのサービスを実装する汎用仕様を表すテンプレートとみなすことができます。ServiceSpecificationは、コレクションとして提供される他のServiceSpecificationsで構成される場合があります。コレクションのメンバーは、個別または集合的に提供される場合があります。ServiceSpecificationsは、製品内などのグループ内に存在する可能性もあります。 |
|
|
リファレンス |
このエンティティは、下位のSERVICE SPECがないSERVICE SPECを定義します。つまり、ServiceSpecAtomicはスタンドアロンSERVICE SPECのため、サポートしているSERVICE SPECでテンプレートとして機能するサービスの不変的な特性を定義する必要はありません。 |
|
|
リファレンス |
このエンティティは、他のSERVICE SPECを集計して形成されるSERVICE SPECを定義します。集計されるSERVICE SPECのタイプは、ServiceSpecAtomicまたはServiceSpecCompositeインスタンスの場合があります。ServiceSpecCompositeは、テンプレートとして機能するサービスのすべての不変的な特性をまとめて定義します。 |
|
|
リファレンス |
サービス仕様とネットワーク要素間のリレーションシップを定義します。たとえば、特定のタイプのサービス仕様の処理に必要なネットワーク要素タイプを追跡します。 |
|
|
リファレンス |
任意のサービス仕様を必要とする製品の追跡など、サービス仕様と製品間のリレーションシップを定義します。 |
|
|
リファレンス |
このエンティティは、異なるインスタンスのSERVICE SPECを区別する機能を表します。その他または元と異なる特定の形式または種類のSERVICE SPECを表します。形式は、新しいSERVICE SPECを作成するほどではない、この特定のSERVICE SPECの特性を示す属性、方法、リレーションシップまたは制約の違いを表します。 |
|
|
検索 |
SERVICEのすべてのステータス・タイプの参照。例:
|
|
|
検索 |
同様のSERVICE STATUSを分類するカテゴリ。 |
|
|
ベース |
SERVICEのステータスの履歴。たとえば、アクティブ、非アクティブ、不履行、解約などです。 |
|
|
検索 |
SERVICEが特定のステータスである理由の参照。 |
|
|
検索 |
SERVICEのタイプの参照。たとえば、値は次のサブタイプから取得する必要があります。 CUSTOMER FACING SERVICE RESOURCE FACING SERVICE COMPOSITE SERVICE |
|
|
検索 |
このエンティティは、下位のサービス仕様のないサービス仕様を定義します。つまり、サービス仕様アトミックはスタンドアロン・サービス仕様のため、サポートしているサービス仕様でテンプレートとして機能するサービスの不変的な特性を定義する必要はありません。 |
|
|
検索 |
このエンティティは、他のサービス仕様を集計して形成されるサービス仕様を定義します。集計されるサービス仕様のタイプは、サービス仕様アトミックまたはサービス仕様コンポジットのインスタンスの可能性があります。サービス仕様コンポジットは、テンプレートとして機能するサービスのすべての不変的な特性をまとめて定義します。 |
|
|
検索 |
異なるインスタンスのサービス仕様を区別する機能を表します。サービス・タイプ・バージョンは、その他または元と異なる特定の形式や種類のサービス仕様を表します。形式は、新しいサービス仕様を作成するほどではない、この特定のサービス仕様の特性を示す属性、方法、リレーションシップまたは制約の違いを表します。 |
|
|
検索 |
サービス使用イベント(サービスの購入や使用など)の詳細な説明。 |
|
|
リファレンス |
テレビ・サービスのセットトップ・ボックス。 |
|
|
リファレンス |
セットトップ・ボックスのモデル仕様。 |
|
|
導出 |
PRODUCT MARKET PLAN別の回線カウントの日次集計。例:
|
|
|
集計 |
PRODUCT MARKET PLAN別の回線カウントの月次サマリー。このエンティティで使用量および収益性を分析します。例:
|
|
|
リファレンス |
棚は、様々なタイプの機器を保持するために設計されている機器ホルダのタイプです。棚には、棚を格納するベイに頻繁に関連付けられる論理識別子があります(多くの場合、棚の一意の識別子は、ネットワーク要素識別子、ベイ識別子および棚識別子の連結です)。通常、棚の論理識別子はデバイス(ネットワーク要素)に関連付けられます。これを論理識別子がデバイスに関連付けられないRACKと比較します。そのため、棚はネットワークの論理モデルの一部です。多くの場合、棚には、外部ヒューズ、アラームおよび他のタイプのパネルへのオプション接続とともに、プラッガブル・コンポーネント(CARD、電源など)および配線(光、ワイヤーなど)も含まれます。 |
|
|
導出 |
顧客および取引の件数、待ち時間などを含め、店舗の効率性に関する詳細のORGANIZATION BUSINESS UNITおよびGEOGRAPHY REGION別の日次集計。 |
|
|
集計 |
顧客および取引の件数、待ち時間などを含め、店舗の効率性に関する詳細のORGANIZATION BUSINESS UNITおよびGEOGRAPHY REGION別の月次サマリー。 |
|
|
リファレンス |
標準産業分類(SIC)の産業の割当て。 |
|
|
検索 |
標準産業分類(SIC)で2つの産業が割り当てられる理由を示すコードおよび説明の参照。 |
|
|
検索 |
標準産業分類(SIC)の分類グループ。例: A.分類A: 農業、林業および漁業:
|
|
|
リファレンス |
SIC分類のベース・レベル。詳細は、「SIC CLASSIFICATION」を参照してください。 |
|
|
検索 |
産業分類階層の中間レベル。 |
|
|
リファレンス |
このエンティティは、管理できる様々なタイプのシグナリング・プロトコルを表します。シグナリング・プロトコルは、特定のパスで情報を送信するために使用されます。シグナリング・プロトコルを管理および使用する方法を定義する便利な集計ポイントを表します。 |
|
|
リファレンス |
取り外し可能なSIMカード上のSubscriber Identity Module (SIM)に、移動電話通信機器(携帯電話など)のサブスクライバを識別するためのサービス・サブスクライバ・キー(IMSI)が安全に保存されます。 CDMA (Code Division Multiple Access)ネットワークのUIM (User Identity Module)でも使用されます。 |
|
|
リファレンス |
ACCESS METHODとSIM CARDのリレーションシップの履歴。随時、1枚のSIMカードに多数のアクセス方法を割り当てることができます。 |
|
|
検索 |
SIM CARDとACCESS METHOD間のリレーションシップを表す有効な理由コードおよび説明の参照。 |
|
|
検索 |
SIM CARDを有効化した理由を表す有効な理由コードおよび説明の参照。 |
|
|
検索 |
SIM CARDの使用状況。例:
|
|
|
リファレンス |
HANDSET INSTANCEとSIM CARDのリレーションシップの履歴。ハンドセット間でSIMカードの交換ができます。 |
|
|
リファレンス |
SIM CARDとSUBSCRIPTION間のリレーションシップの履歴。 |
|
|
検索 |
SIM CARDとSUBSCRIPTIONの関連付けの理由。 |
|
|
検索 |
SIM CARDのタイプの参照。例:
|
|
|
リファレンス |
サイトは、通信事業会社の関心のある地理的な場所です。 |
|
|
リファレンス |
この役割は、一連の顧客のインタフェースである顧客サイトを定義します。この役割の目的は、このサイトのすべての顧客が同じサービスを受け取れるようにポリシーの定義を有効にすることです。たとえば、ルーティング通知、トラフィック・マーキングなどがあります。 |
|
|
検索 |
サービス・プロバイダの関心のあるすべての可能なタイプのサイトの参照。 |
|
|
検索 |
個々のパーティの使用可能なスキル・タイプの参照。 |
|
|
リファレンス |
これは、2つの主な目的を持つ具体エンティティです。1つめは、ホスティング・ボードのベース機能を追加または実行するドーター・カードを受け入れるため、ホスティング・ボードの機能をモデル化することです。2つめは、CHASSISでサポートされる様々な拡張スロットを表すことです。 |
|
|
リファレンス |
このエンティティは、隣接スロット関連付けのセマンティクスを表します。SLOTリレーションシップには、機器ホルダのSLOTを示す一般的なレイアウト情報を提供するために使用される2つの属性が含まれます。1つめのスロット間の距離は、物理パッケージの2つの隣接するSLOT間のインチ単位の距離を定義します。2つめの共有スロットは、相互に近くに配置されている2つのSLOT間の依存性を示すブール属性です。2つのSLOTが非常に近い場合があるため、1つのSLOTにアダプタCARDが挿入されている場合は他のSLOTを空にする必要があります。この属性をTRUEに設定する場合、2つめのSLOTを空にする必要があります。 |
|
|
リファレンス |
VALUE ADDED SERVICEのサブタイプ。このエンティティは、ショート・メッセージ・サービス(SMS)に関連する情報を定義します。このエンティティとSMS EVENTを混同しないでください。 |
|
|
ベース |
NETWORK EVENTのサブタイプ。ショート・メッセージ・サービス(SMS)の製品使用に関するすべての情報を収集します。 |
|
|
リファレンス |
PRODUCT RATING PLANのサブタイプ。ショート・メッセージ・サービス(SMS)およびマルチメディア・メッセージング・サービス(MMS)用に予約されています。 |
|
|
リファレンス |
SOC (Standard Occupational Classification)職業分類の最も詳細なレベルを保持します。例:
|
|
|
リファレンス |
Standard Occupational Classification (SOC)の各職業が配置されているSOCのカテゴリの参照。一般的なSOCの階層はNN-MMM0です。これらの職業カテゴリは、449の代表職業名またはカテゴリに対応しています。例:
|
|
|
リファレンス |
Standard Occupational Classification (SOC)の各職業が配置されているSOCの分類の参照。一般的なSOCの階層はNN-MM00です。例:
|
|
|
リファレンス |
Standard Occupational Classification (SOC)の各職業が配置されているSOCの23の大分類からの参照。一般的なSOCの階層はNN-0000です。例:
|
|
|
リファレンス |
このエンティティは、ソフトウェアを表します。ソフトウェアは、デバイスに含まれるユーザーが参照できる機能およびプロセスのセットを表します。ソフトウェア機能あり関連付けは、プログラムやオペレーティング・システムなどのLOGICAL DEVICEに関連付けられるソフトウェアを定義します。このソフトウェアをデバイスまたはデバイス・コンポーネントおよびその両方に関連付けることができるため、この関連付けは2つのクラスのルート間で定義されます。ソフトウェアは他のソフトウェア内にネストされる場合があるため、システム・ビューの一部である包含リレーションシップが作成されます。現在、このクラスのサブクラスはユーザー対応機能を反映しています。たとえば、ユーザーおよびアプリケーションで管理可能、構成可能および実行可能な機能などがあります。言語クラスへの言語を使用するソフトウェア関連付けを作成して、国際化および言語機能がサポートされます。 |
|
|
リファレンス |
このエンティティは、個々に管理可能なアトミック単位のソフトウェアを表し、コンポジット(ネスト)のソフトウェア単位を形成しません。有限ステート・マシン・ビューでは、各ソフトウェア・アトミック要素を個々に管理でき、インストールおよび実行も可能です。また、各ソフトウェア・アトミック要素はFRUである可能性があります。これは、特定の機能を定義する具体サブクラスを作成するスーパークラスです。たとえば、デバイス・ドライバ、より大きいルーティング・ソフトウェア・パッケージの一部としてMPLSを実装するソフトウェアなどがあります。 |
|
|
リファレンス |
ソフトウェア・コマンドは、特定のPARTY ROLEでプログラム可能な機能のセットを示します。たとえば、開発者、ネットワーク事業者、まれにエンド・ユーザーなどがあります。これを機能と混同しないでください。機能は、要素に対して特定の時点で使用可能な機能を定義します。そのため、ソフトウェア・コマンドはデバイスで使用可能な特定のコマンドを表し、機能は要素で使用可能な上位の汎用機能を表します。たとえば、BGPルーティングを実行する機能が機能、BGPルーティングの実装に使用する実際のコマンドがソフトウェア・コマンドです。 |
|
|
リファレンス |
このエンティティは、他のソフトウェア単位で構成されるソフトウェア単位(つまり、このエンティティおよびソフトウェア・アトミック・ベース・エンティティのインスタンス)を表します。これは、それぞれ個々に管理可能でオブジェクトのセットを全体で管理できる一連のコンポーネントを収集するセマンティクスを提供します。たとえば、単位として管理可能で、個々に管理可能なコンポーネントで構成されているオペレーティング・システムです。ソフトウェア・コンポーネントの包含構成を使用して、この包含がモデル化されます。有限ステート・マシン・ビューで、各ソフトウェア・コンポジット要素を管理、インストールおよび実行できます。また、各ソフトウェア・コンポジット要素はFRUである可能性があります。これは、機能のグループを定義する具体サブクラスを作成するスーパークラスです。たとえば、エンドユーザーに対してアプリケーションレベル機能を提供する機能セットなどがあります。 |
|
|
リファレンス |
ソフトウェア機能セットは、特定のリリースのソフトウェアを区別するソフトウェア・コマンドのグループを示します。ソフトウェア機能セットに含まれるソフトウェア・コマンドは、特定のPARTY ROLE(たとえば、開発者、ネットワーク事業者、まれにエンド・ユーザーなど)によってプログラム可能です。多くの場合、ソフトウェア機能は、ソフトウェアのカスタムまたはセミカスタムの作成を定義するために製造業者が使用するか、顧客が注文できる一連のオプションとして提供されます。これを機能と混同しないでください。機能は、要素に対して特定の時点で使用可能な機能を定義します。そのため、ソフトウェア機能セットはデバイスで使用可能なコマンドのグループを表し、機能は要素で使用可能な上位の汎用機能を表します。たとえば、BGPルーティングを実行する機能が機能で、BGPルーティングの実装に使用する実際のコマンドが1つ以上のソフトウェア機能セットのソフトウェア・コマンドです。したがって、ソフトウェア機能セットは、プログラム可能な機能としてBGPを提供する場合があります。 |
|
|
リファレンス |
これは関連付けクラスで、OSと対話するソフトウェア関連付けのセマンティクスを定義します。これは複雑なクラスなので、読者がこのエンティティで定義されたパラメータのタイプを把握するため、少数の単純な属性のみがこの視点で示されます。 |
|
|
リファレンス |
読み込まれる情報のソースとなる記録システム。 |
|
|
リファレンス |
元のソース・システムのPARTY、顧客または従業員の追跡キー。このキーは、ソース管理システムまで遡って情報を追跡できます。 |
|
|
検索 |
SOURCE SYSTEMを表すためのタイプ・コードおよび説明の参照。例:
|
|
|
リファレンス |
これは、管理エンティティの不変的な特性、属性、方法およびリレーションシップを定義するエンティティです。 |
|
|
リファレンス |
これは、すべての役割仕様サブクラスのエンティティです。 |
|
|
リファレンス |
特定のワイヤレス範囲の地理的なカバレッジ・エリア。 |
|
|
リファレンス |
今後定義される予定 |
|
|
リファレンス |
サブネットワーク接続の可能性を示すネットワーク管理システム(NMS)に要素管理システム(EMS)で提供される抽象。サブネットワークは、エンド・ポイントに関連付けられている役割に従ったサブネットワークを通じて、閉じたまたは半分開いた透過的なエンドツーエンド接続またはTRAILも提供します。 |
|
|
検索 |
サブスクライバのアクティベーションの説明に使用される有効なサブスクライバ・アクティベーション・コードおよび理由の参照。例:
|
|
|
リファレンス |
契約に基づいて製品またはサービスを使用している顧客の記録。サービスへの顧客のサブスクリプションは、請求およびネットワーク使用権限の基盤となります。 |
|
|
リファレンス |
SUBSCRIPTIONの別のSUBSCRIPTIONへのリレーショナル割当て。これはオプションです。 |
|
|
検索 |
SUBSCRIPTION ASSIGNMENTに関するタイプ・コードおよび説明の参照。 |
|
|
検索 |
利用可能なサブスクリプション・イベントのタイプ・コードおよび説明の参照。 |
|
|
リファレンス |
SUBSCRIPTIONとNETWORK ELEMENT ROLE間のリレーションシップを定義します。 |
|
|
リファレンス |
SUBSCRIPTIONとPRODUCT MARKET PLANのリレーションシップ。SUBSCRIPTIONは、その存続期間中に、異なるPRODUCT MARKET PLANに再度割り当てることができます。 |
|
|
リファレンス |
特定のサブスクリプションの料金情報。 |
|
|
リファレンス |
特定のサブスクリプションに適用する価格変更。 |
|
|
リファレンス |
SUBSCRIPTION PRICEのサブタイプとして個々のサブスクリプションに適用する金銭的な料金。 |
|
|
リファレンス |
SUBSCRIPTION PRICEの管理者を追跡するためのパーティ役割とSUBSCRIPTION PRICE間のリレーションシップ。 |
|
|
リファレンス |
SUBSCRIPTIONとSERVICE間のリレーションシップ。1つのサブスクリプションは複数のサービスを評価するために使用できます。たとえば、WCDMA 3Gデータ + Wifi (逆の場合も同様)です。GSM携帯電話などの1つのサービスで複数の製品をサポートできます(通話分数や割引など)。 |
|
|
リファレンス |
SUBSCRIPTIONのサービス・クラスを定義します。 |
|
|
導出 |
サブスクライバによるチャーンに関する情報の月次集計。ACCOUNT、PRODUCT MARKET PLAN、SALES CHANNEL、AGE BAND、AGE ON NET BAND、CREDIT CATEGORY、DEBT AGING BAND、CUSTOMER REVENUE BAND、ARPU BAND、CUSTOMER別。 |
|
|
集計 |
サブスクライバによるチャーンの月次サマリー。PRODUCT、PRODUCT MARKET PLAN、CUSTOMER TYPE、GEOGRAPHY ENTITY、ORGANIZATION BUSINESS UNIT別。 |
|
|
検索 |
SUBSCRIPTIONのステータスに利用可能なコードおよび説明の参照。例:
|
|
|
検索 |
SUBSCRIPTION STATUSをグループ化または分類するためのカテゴリ・コードおよび説明の参照。 |
|
|
ベース |
SUBSCRIPTIONのステータスの履歴。例:
サブスクリプションに複数のステータスが同時に含まれる場合があります。たとえば、サブスクリプションは、アクティブであると同時に、負債があるか、しきい値未満の金額である可能性があります。 |
|
|
検索 |
SUBSCRIPTIONにステータスを割り当てる理由を定義するために利用可能な理由コードおよび説明の参照。 |
|
|
検索 |
SUBSCRIPTIONのステータスに利用可能なコードおよび説明の参照。例:
サブスクリプションは同時に2つのステータスを持つことがあります。たとえば、サブスクリプションは、アクティブであると同時に、負債があるか、しきい値未満の金額である可能性があります。 |
|
|
検索 |
値が割り当てられるSUBSCRIPTIONおよびPRODUCTに関する利用可能なタイプ・コードおよび説明の参照。例:
|
|
|
ベース |
SUBSCRIPTIONおよびPRODUCTに関するサブスクリプション条件の値の割当て。例:
値は期間ごとに異なる場合があります。たとえば、月額料金は最初の6か月間は100、最後の6か月は80である可能性があります。また、契約の残りの月数に基づいて違約金が割り当てられる場合もあります。 |
|
|
検索 |
SUBSCRIPTIONで利用可能なタイプ・コードおよび説明の参照。例:
|
|
|
集計 |
NVPスキーム・アイテムおよび無料アイテムを除き、補助金として与えられるアイテムの予算額についてのPRODUCT MARKET PLAN別およびCUSTOMER TYPE別の月次サマリー。 |
|
|
導出 |
NVPスキーム・アイテムおよび無料アイテムを除き、補助金として与えられるアイテムの予算額についてのPRODUCT MARKET PLAN別およびCUSTOMER TYPE別の月次集計。 |
|
|
検索 |
補助金のタイプ・コードおよび説明の参照。 |
|
|
リファレンス |
電話およびデータ・サービスなどの既存サービスを補足またはサポートする付加サービスが含まれるPRODUCTのサブタイプ。例:
|
|
|
導出 |
付加サービスの使用の集計情報を保持します。コア・ネットワーク計画のSUPPLEMENTARY SERVICEを分析します。 |
|
|
集計 |
SUPPLEMENTARY SERVICEの使用に関する料金および請求の月次サマリー。事業単位、PRODUCT MARKET PLANおよびPRODUCT別。 |
|
|
リファレンス |
調査は、PROMOTIONのサブタイプです。 |
|
|
リファレンス |
ネットワーク・スイッチまたは交換機。スイッチは、PSTN (電話回線)デジタルまたはアナログ、またはGSM移動局コントローラ(ワイヤレス)です。 |
|
|
リファレンス |
各スイッチまたは交換機の特定の機能特性を記録します。任意の機能のタイプは、顧客サービスを使用できるタイプです。このエンティティでは、事業者が特定のスイッチの顧客が特定のサービス(VPNなど)を利用できるかどうかを識別できます。 |
|
|
検索 |
SWITCH CAPABILITYの分類に使用されるタイプ・コードおよび説明の参照。 |
|
|
リファレンス |
スイッチに送信され、対処するように指示するコマンド。たとえば、指定されたパラメータを使用してポートをアクティブ化するなど。 |
|
|
リファレンス |
いずれかのタイプのネットワークでスイッチにルーティング・デバイスを割り当てます。 |
|
|
検索 |
スイッチ・タイプおよび製造業者の分類。 |
|
|
リファレンス |
このエンティティは、管理できる様々なタイプのスイッチング・プロトコルを表します。スイッチング・プロトコルは、ルーティングでバンド幅やQoSなどのレイヤー2情報を考慮できるプロトコルです。(従来のルーティング・プロトコルは、各フレームのレイヤー3ヘッダーのみを評価するために設計されています。)レイヤー2情報を参照して次のホップを定義するタスクを実行するため、複数の方法を使用できます。ほとんどの場合、従来のヘッダーのすべての情報を評価しないで次のホップを定義する手段のラベルの概念を使用しています。 |
|
|
リファレンス |
LOGICAL DEVICEの使用に必要な異なるルーティング機能を抽象化します。これにより、多くの異なる機能セットを持つ(特に)ネットワーク・デバイスのモデル化を簡略化できます。たとえば、ほとんどのルーターでトラフィックのルーティング、転送およびファイアウォールを実行できます。これらの機能を3つの役割にモデル化することで、ルーターによる転送トラフィックおよびL3スイッチによる転送トラフィックの違いを区別するため、スイッチ機能が抽象化および分類されます。 |
|
|
検索 |
COMPETITORと比較する場合に企業が持つ強み、弱み、機会、脅威(SWOT)。SWOTは、組織の成長機会を識別および構築する正式なフレームワークです。 |
|
|
ベース |
顧客またはパートナ・ネットワークで呼び出されるネットワーク・イベント。これらのイベントを請求目的のアカウントに関連付ける必要があります。 |
|
|
ベース |
事業者のネットワークのパートナ顧客によるネットワーク・イベント。 |
|
|
リファレンス |
PROMOTIONに関連するACCESS METHOD。 |
|
|
リファレンス |
||
|
リファレンス |
||
|
リファレンス |
PROMOTIONのターゲットとなるGEOGRAPHY ENTITY。 |
|
|
リファレンス |
特定のCAMPAIGNに含まれるMARKET SEGMENT。 |
|
|
検索 |
PROMOTIONに関する有効なタイプ・コードおよび説明の参照。例:
|
|
|
リファレンス |
PROJECT内の特定のタスク。 |
|
|
リファレンス |
消費税を徴収する政府当局。政府当局のために店舗がこれらの消費税を集めます。例:
|
|
|
検索 |
請求書アイテムに適用される可能性がある税金カテゴリ。 |
|
|
検索 |
ITEMに関する有効な非課税コードおよび説明の参照。 |
|
|
検索 |
トラフィック・チャネルのタイプの参照。例:
|
|
|
検索 |
NETWORK ELEMENTを定義するテクノロジの名前および説明。例:
|
|
|
検索 |
TECHNOLOGYを分類またはカテゴライズする利用可能なタイプ・コードおよび説明の参照。例:
|
|
|
リファレンス |
アクセス方法のサブタイプとしての電話番号。 |
|
|
リファレンス |
電話会社に割り当てられる電話番号プール。 |
|
|
リファレンス |
SERVICE LEVEL AGREEMENT仕様のテンプレート。 |
|
|
リファレンス |
このエンティティは、トレイルや接続などのトランスポート終了エンティティに対して使用します。このオブジェクト・クラスは、トレイル終了ポイントやCONNECTION TERMINATION POINTなどのサブクラスが導出される基本オブジェクト・クラスです。 |
|
|
検索 |
通話時間のバンド。例:
|
|
|
リファレンス |
HOUR、HALF HOURおよびQUARTER HOURとの関連でDAY内の時間帯を定義する参照エンティティ。すべての時間の導出および集計表で使用されます。 |
|
|
リファレンス |
カレンダの日をシーズンおよび標準の日に関連付けます。特定の日と、特定のシーズンのその日までのすべての日とのリレーションシップを指定します。 |
|
|
リファレンス |
カレンダの週をシーズンおよび標準の週に関連付けます。特定の週と、特定のシーズンのその週までのすべての日とのリレーションシップを指定します。 |
|
|
検索 |
グリニッジ標準時(GMT +0.00)との関連における地理的タイム・ゾーンの参照。 |
|
|
リファレンス |
トレイルは、1つ以上の他のレイヤー・ネットワークから特性情報の転送の整合性を管理するレイヤー・ネットワークの管理オブジェクトのクラスです。トレイルは、2つのトレイル終了ポイントおよび1つ以上の接続および関連付けられているCONNECTION TERMINATION POINTで構成されます。 |
|
|
リファレンス |
このエンティティは、様々なタイプのトレイル終了ポイントをグループ化します。このエンティティは、このエンティティに対する単一の構成(CTPsInTrail)を実行でき、サブクラスで継承されます。これは、(現在)3つのタイプのトレイル終了ポイントとCTPクラス間の3つのリレーションシップを作成するより効率的であるとみなされています。それぞれ同じ包含リレーションシップがあります。 |
|
|
リファレンス |
テレビ・チャネルをPTV USAGE EVENTに関連付けるPRODUCT INSTANCEのタイプ。 |
|
|
検索 |
Unified Messaging Services (UMS)の有効なタイプ・コードおよび説明の参照。UMSアクセス・タイプは、顧客がメールボックスにアクセスする方法を示します。特に、指定された番号により標準の方法でメールボックスにアクセスするか、インターネット・メールを使用するUMSユーザーに適用されます。 |
|
|
ベース |
NETWORK EVENTのサブタイプ。UMS通知タイプ・ディメンションで、Unified Messaging Service (UMS)はVoice Message Service (VMS)の高度なバージョンです。SMSまたはインターネット・メールのどちらでもUMSを使用してサブスクライバに通知できるため、それと同様に、サブスクライバも標準アクセス番号の呼出しまたはインターネットを通じて、様々な方法でメールボックスにアクセスできます。 UMSアクセスに関連する情報は、アクセス・タイプにより分析されます。UMSアクセス・タイプ・ディメンションの使用によって、この要件が満たされます。 |
|
|
検索 |
UMSイベントのタイプの参照。例:
|
|
|
検索 |
システム内のデータに有効な測定単位の参照。例:
|
|
|
リファレンス |
都会の所有地住所。 |
|
|
リファレンス |
EMPLOYEE、JOB ROLE、事業単位の関連性エンティティ。従業員が特定の事業単位で実行する各職種の一意のIDを関連付けます。従業員はEMPLOYEEエンティティに一度だけ表示されますが、USERエンティティでは従業員が事業単位の職種ごとに表示されます。 |
|
|
リファレンス |
着信転送、通話制限、CLI、CLIR、UMSまたはVMSなどの追加のサービスまたは付加価値サービスを構成する製品のタイプ。 |
|
|
リファレンス |
このエンティティは、アプリケーション固有の方法で使用できるカスタム値オブジェクトを定義する2つの基本属性を提供します。これらの2つの属性は、valueModelAttributeおよびvalueModelClassと呼ばれます。valueModelAttributeは、POLICY VALUEとして評価または設定されるvalueModelClass属性で指定されるエンティティ内の属性の名前を定義する文字列属性です。valueModelClassは、属性がPOLICY VALUEとして評価または設定されるエンティティの名前を定義する文字列属性です。この組合せは、モデル化するエンティティおよび属性を指定する値カスタムの新しいカスタム・サブクラスを定義できます。これらの2つのプロパティを検索すると、現在のモデル・スキーマのユーザーはこれらの新しいサブクラスを確認できます。また、モデル・ユーザーは新しい拡張の目的をすぐに理解できます。 |
|
|
検索 |
価値の測定単位の参照。たとえば、金額または期間(今後3年間の顧客など)の観点から、顧客またはプロファイルの価値を測定できます。 |
|
|
リファレンス |
これは、一連の標準化されたPOLICY VALUEを定義する抽象ベース・エンティティです。このセットのPOLICY VALUEは、時間の経過とともに追加され、様々なPBNMアプリケーションで役立つ一連の一般的な値を表します。値標準のサブクラスは、PBNMで発生する一般的な変数のセマンティクスを定義する一連のクラスです。 |
|
|
検索 |
||
|
リファレンス |
変数カスタムおよび変数標準と呼ばれるPOLICY VARIABLEの2つのサブクラスがあります。変数カスタム・エンティティは、アプリケーション固有の方法で使用する一連の標準化されたポリシー変数を定義します。「カスタム」とは、このような変数がモデルの変数標準サブクラスにはない属性で使用するために明示的に設計されていることを意味します。そのため、適用可能な制約を含む特定のセマンティクスはモデルに認識されません。このエンティティは、アプリケーション固有の方法で使用するカスタム変数を定義する2つの基本属性を提供します。 |
|
|
リファレンス |
このエンティティは、ほとんどのPBNMアプリケーションに共通のPOLICY VARIABLEオブジェクトの標準セットを定義します。 |
|
|
リファレンス |
VALUE ADDED SERVICEを含むサブスクリプションのタイプ。 |
|
|
集計 |
CUSTOMER TYPE別のVALUE ADDED SERVICE詳細の月次サマリー。 |
|
|
導出 |
CUSTOMERおよびACCESS METHOD別のVALUE ADDED SERVICE詳細の月次集計。 |
|
|
導出 |
コンテンツ・ベース(およびその他を含む)のすべての付加価値サービスの日次使用統計。M2M、P2P、SMS、MMS、着信音、音楽、ビデオ、電子メール、ユニバーサル(音声/電子メール)メッセージおよびその他が含まれます。 |
|
|
集計 |
VAS USAGE DAY DRVDからのVAS使用統計の月次集計。 |
|
|
リファレンス |
ビジネス要件を満たすために事業者によって所有および使用される自動車。 |
|
|
リファレンス |
機器または供給品のサプライヤまたは供給源。 |
|
|
ベース |
プロバイダまたは小売サイトを訪問するVENDOR担当者に割り当てられる単一または繰返しの訪問回数。 |
|
|
検索 |
ベンダーの分類の参照。例:
|
|
|
リファレンス |
VENDORとの期限を定めた契約。 |
|
|
リファレンス |
VENDORとFACTOR COMPANY間のリレーションシップを定義します。 |
|
|
リファレンス |
実績を基準にVENDORに割り当てるスコア。 |
|
|
検索 |
VENDOR RATINGの実績基準のタイプ・コードおよび説明の参照。 |
|
|
リファレンス |
VENDORがプロバイダと取引をするVENDORに関連付けられたサイトまたは場所。ベンダー・サイトには事務所、倉庫、発送センターなどがあります。 |
|
|
リファレンス |
商品輸送の観点からのVENDOR SITEおよびCOURIERコードの関連付け。 |
|
|
検索 |
VENDOR SITEに関する有効なタイプ・コードおよび説明の参照。例:
|
|
|
リファレンス |
特定の目的のために形成された事業単位タイプ。例:
|
|
|
リファレンス |
SERVICEのサブタイプ。 |
|
|
導出 |
TIME SLOT、事業単位、郡、PRODUCT、CUSTOMER TYPE、発信者、発信先、CALL DIRECTION、コールの成功/失敗、ローミング・サービス別の音声電話の統計の日次集計。 |
|
|
ベース |
ネットワーク・イベントのサブタイプ。Voice Over IP (VOIP)電話専用。 |
|
|
集計 |
事業単位、PRODUCT、CUSTOMER TYPE、CALL CATEGORY、CALL DIRECTION、コールの成功/失敗別の音声電話の統計の月次サマリー。 |
|
|
検索 |
ネットワーク・イベントの特質を容量で表します。単位には、バイト、分、パケット、ダウンロードがあります。このエンティティは、通話およびその他のネットワーク・イベントの評価の一部として使用されます。 |
|
|
リファレンス |
VPNRoleは、様々なタイプのVPN役割クラスのスーパークラスです。たとえば、MPLS VPNは、このエンティティのCPELogicalDeviceRole、PELogicalDeviceRoleおよびPLogicalDeviceRoleサブクラスを使用して、MPLS VPNのCPE、PEおよびP役割に必要な機能を抽象化します。他のタイプのVPNは、VPNRoleクラスの他のサブクラスを使用します。このクラスの利点は、MPLSVPNServiceSpecificationで様々なタイプのVPN役割を指定できることです。 |
|
|
リファレンス |
顧客によって現在使用されているVPNサービス。 |
表2-29 エンティティの説明(W～Z)
| エンティティ名 | タイプ | 説明 |
|---|---|---|
|
リファレンス |
WANプロトコルは、OSIモデルの最下位の3つのレベル、物理、データ・リンクおよびネットワークで動作します。WANプロトコルを使用して、様々なタイプの広域メディアの通信を定義します。 |
|
|
リファレンス |
特定の日に影響を及ぼす、一般的な意味での様々な「気象」条件の参照。内部の「天気」(店舗の洪水、従業員のストライキなど)と外部の「天気」(嵐、洪水、雪およびその他)では異なります。この情報は、ネットワーク障害との関連で役立ちます。 |
|
|
ベース |
Web訪問での顧客ナビゲーション・パスの履歴。 |
|
|
リファレンス |
サービス事業者のWebサイトのWebページ。Webページでは、製品の表示または顧客サービス・リクエストの処理を行う場合があります。 |
|
|
リファレンス |
||
|
検索 |
WEB PAGEレンダリングのタイプの参照。例:
|
|
|
検索 |
Webページ・タイプは、コンテンツおよび目的に従ってWebページをグループ化します。例:
|
|
|
リファレンス |
週レベルの累積時間変換。 |
|
|
リファレンス |
週レベルの時間変換。 |
|
|
リファレンス |
カレンダの平日。 |
|
|
ベース |
ワイヤレス・コールの発生を定義します。 |
|
|
ベース |
ネットワーク・イベントのタイプ。音楽、ビデオ・クリップなどのワイヤレス・コンテンツのダウンロードを追跡します。 |
|
|
導出 |
分析のためにNETWORK ELEMENT階層から導出。 |
|
|
リファレンス |
PRODUCT RATING PLANのサブタイプ。ワイヤレスの音声およびデータ・サービス用に予約されています。 |
|
|
ベース |
TAP INおよびTAP OUTイベントを含む事業者間をローミングするワイヤレス・コール・イベント。このエンティティは、GSMA(Global System for Mobile Communications)の公式文書TD.57に従って設計されています。 |
|
|
ベース |
詳細としてローミング・イベントを含むバッチ。通常、このバッチは1つのTAPファイルにあります。 |
|
|
リファレンス |
顧客が使用しているワイヤレス・サービス。例:
|
|
|
リファレンス |
サービス・プロバイダ・ネットワークで使用するワイヤレス範囲。 |
|
|
リファレンス |
年レベルの変換。 |
