カラム情報
概要
Column Info 計算機は、イベントログデータセット内のすべての属性（カラム）に関する詳細なメタデータと統計情報を提供します。この管理ツールは、各属性のデータ型、値の分布、ヌル数、サンプル値などの包括的な情報を表示します。
重要：これは管理者専用の計算機であり、技術分析および研究目的で設計されています。 本番環境での使用に最適化されておらず、大規模データセットの処理にはかなりの時間がかかる場合があります。一般ユーザーは、データセットの概要把握には Dataset Information 計算機を使用してください。
この計算機は主にシステム管理者、データアナリスト、技術ユーザーによって使用され、トラブルシューティング、データ検証、データセットの最適化のためにデータ構造と品質について深い洞察を得る際に利用されます。
主な用途
- イベントログのすべての属性にわたる包括的なデータ品質監査の実施
- ヌル値や欠損値の割合が高い属性の特定
- データ型の一貫性分析と型変換問題の検出
- 属性のカーディナリティ（固有値の数）の確認によるカテゴリカル分析候補の特定
- 属性レベルの統計を確認したデータ抽出結果の検証
- 予期しない値分布を持つ属性を特定してパフォーマンス問題の診断
- 技術仕様のためのデータセットスキーマおよび特徴のドキュメンテーション
設定
この計算機には特別な構成設定は不要です。実行時に現在のデータセット内のすべての属性（ケースレベルおよびイベントレベル）を自動的にスキャンし、各属性の包括的な統計を生成します。
注意： 処理時間はデータセットのサイズと属性数によって異なります。非常に大きなデータセットの場合、この計算機の完了には数分かかることがあります。
例
例1: ETL後のデータ品質監査
シナリオ: ERPシステムから注文から入金までのデータをETLプロセスで抽出した直後です。ビジネスユーザーにデータセットを公開する前に、すべての属性が正しく抽出されているかとデータの完全性を検証する必要があります。
設定:
- タイトル: "ポストETLデータ品質検証"
- 説明: "O2Cデータセット - 2025年1月抽出"
出力:
以下の情報を含む包括的なテーブルが各属性について表示されます。
| 属性名 | タイプ | 総値数 | ヌル数 | ヌル率 | 固有値数 | サンプル値 |
|---|---|---|---|---|---|---|
| CaseID | Case | 2,456 | 0 | 0% | 2,456 | ORD-001, ORD-002, ORD-003 |
| CustomerName | Case | 2,456 | 12 | 0.5% | 847 | Acme Corp, TechStart Inc, Global... |
| OrderAmount | Case | 2,456 | 0 | 0% | 1,823 | 1250.00, 3400.50, 875.25 |
| Region | Case | 2,456 | 156 | 6.4% | 4 | North, South, East, West |
| ActivityName | Event | 18,945 | 0 | 0% | 15 | Create Order, Approve Order, Ship... |
| Timestamp | Event | 18,945 | 0 | 0% | 18,893 | 2025-01-15 08:23:00, 2025-01-15... |
| ApprovalLevel | Event | 18,945 | 8,234 | 43.5% | 3 | L1, L2, L3 |
| Department | Event | 18,945 | 3,456 | 18.2% | 8 | Sales, Finance, Operations... |
洞察: 監査によりいくつかのデータ品質上の懸念が明らかになりました。Region 属性は6.4%のヌル値が156件のケースに影響しており、これらのケースは手動レビューまたはデータ修正が必要です。より重大なのは ApprovalLevel 属性で43.5%のヌル値があり、一部のアクティビティが承認を必要としない（想定内）可能性や、承認すべきアクティビティで承認データが欠落している可能性（調査が必要）があります。CustomerName の低いヌル率（0.5%）は許容範囲であり、テスト注文を示しているかもしれません。主要識別子（CaseID、Timestamp）はヌルゼロで、データの整合性を確認しました。
例2: パフォーマンスのトラブルシューティング
シナリオ: 特定の属性でフィルタリングしたときにパフォーマンスが遅いとユーザーから報告があります。効率の悪いフィルタ処理の原因となっているかもしれない高いカーディナリティ（ユニーク値の多い）属性を特定する必要があります。
設定:
- タイトル: "属性カーディナリティ分析"
- 説明: "フィルタパフォーマンス問題の調査"
出力:
| 属性名 | タイプ | 総値数 | 固有値数 | カーディナリティ比率 | データ型 |
|---|---|---|---|---|---|
| CaseID | Case | 45,678 | 45,678 | 100% | String |
| TransactionID | Event | 367,824 | 367,824 | 100% | String |
| UserComments | Event | 367,824 | 89,234 | 24.3% | String |
| ProductSKU | Event | 367,824 | 12,456 | 3.4% | String |
| Status | Case | 45,678 | 8 | 0.02% | String |
| Priority | Case | 45,678 | 3 | 0.007% | String |
洞察: 分析により属性間で幅広いカーディナリティの差が判明しました。CaseID と TransactionID は100%のカーディナリティで（すべての値がユニーク）、ケース識別には最適ですが、カテゴリカルフィルタには不向きです。UserComments は異常に高いカーディナリティ（24.3%）で、標準化された値ではなく自由形式のテキストを含むことを示唆しており、この属性でのフィルタは遅くなり、全文検索の最適化が有効かもしれません。一方 Status（8値）と Priority（3値）は効率的なフィルタリングに適した低カーディナリティです。この分析はフィルタ設計の最適化とユーザーに高パフォーマンスの属性選択を促すガイドとなります。
例3: 統合用スキーマドキュメント作成
シナリオ: プロセスマイニング環境に統合を行う第三者ベンダーに技術文書を提供する必要があります。利用可能な属性、データ型、想定される値の範囲などの詳細情報が求められています。
設定:
- タイトル: "購買から支払いまでのスキーマドキュメント"
- 説明: "API統合の技術仕様"
出力:
| 属性名 | 属性タイプ | データ型 | 総値数 | 固有値数 | ヌル数 | サンプル値 |
|---|---|---|---|---|---|---|
| PO_Number | Case | String | 8,945 | 8,945 | 0 | PO-2025-00001, PO-2025-00002 |
| Vendor_ID | Case | String | 8,945 | 234 | 0 | V12345, V67890, V45678 |
| Total_Amount | Case | Decimal | 8,945 | 7,823 | 0 | 15750.50, 2340.00, 987.25 |
| Currency | Case | String | 8,945 | 3 | 12 | USD, EUR, GBP |
| RequestDate | Case | DateTime | 8,945 | 2,456 | 0 | 2025-01-15, 2025-01-16 |
| Activity | Event | String | 71,560 | 12 | 0 | Create PO, Approve PO, Send... |
| Resource | Event | String | 71,560 | 145 | 234 | john.smith, sarah.jones... |
| Cost_Center | Event | String | 71,560 | 67 | 1,234 | CC-1001, CC-2045, CC-3012 |
洞察: スキーマ文書により PO_Number が主なケース識別子でユニークかつヌルなしであることがわかります。全ての金額は Total_Amount（小数型）フィールドで管理され、通貨は別に指定されています。プロセスは3種の通貨（USD、EUR、GBP）をサポートし、12件の通貨データ欠損が修正対象です。Resource情報は145名のユーザー固有でイベントレベルには234のヌル値があり、自動化されたアクティビティの存在を示しています。Cost_Center 属性は1.7%のヌル値があり、一部アクティビティでデータ入力が不完全である可能性があります。これにより正確な統合計画が可能です。
例4: データ型不整合の検出
シナリオ: 複数のソースシステムからのデータをマージした後で、計算エラーや予期しない分析結果の原因となりうるデータ型の不整合が疑われています。
設定:
- タイトル: "データ型一貫性チェック"
- 説明: "複数ソースのデータ検証"
出力:
| 属性名 | 検出された型 | 総値数 | 型不整合件数 | 不整合値のサンプル |
|---|---|---|---|---|
| OrderDate | DateTime | 5,678 | 0 | - |
| OrderValue | Mixed | 5,678 | 23 | "1250.50", "$1,250.50", "1250,50" |
| QuantityOrdered | Integer | 5,678 | 8 | "100", "100.0", "100 units" |
| CustomerID | String | 5,678 | 0 | - |
| IsRush | Mixed | 5,678 | 145 | "Yes", "Y", "1", "true", "TRUE" |
洞察: 分析により重大なデータ型不整合が検出されました。OrderValue は通貨記号や異なる小数点区切り（カンマとピリオド）を含む混合形式で、計算前にデータクリーニングが必要です。QuantityOrdered は8件のテキスト付加（"100 units"）があり、数値集計でエラーを引き起こします。IsRush フラグには5種類の異なるブール表現が混在しており、"true/false"か"1/0"に統一する必要があります。これらの問題はETL処理段階で解決しなければなりません。
例5: 拡張可能性のある属性の特定
シナリオ: 分析をよりユーザーフレンドリーにするために、低カーディナリティで追加の説明情報による拡張の有益な属性を特定したい。
設定:
- タイトル: "拡張機会分析"
- 説明: "ルックアップ拡張の候補特定"
出力:
| 属性名 | タイプ | 固有値数 | ヌル率 | サンプル値 | 拡張ポテンシャル |
|---|---|---|---|---|---|
| ProductCode | Event | 45 | 0% | P001, P002, P003 | 高 - 商品名を追加 |
| StatusCode | Case | 8 | 0% | ST-01, ST-02, ST-03 | 高 - ステータス説明を追加 |
| RegionCode | Case | 4 | 0% | R1, R2, R3, R4 | 高 - 地域名を追加 |
| CurrencyCode | Case | 3 | 0% | USD, EUR, GBP | 中 - 一般的に理解されている |
| EmployeeID | Event | 234 | 2.1% | E12345, E67890 | 高 - 従業員名を追加（プライバシー順守） |
洞察: いくつかの属性はコード値を含み、拡張により利便性が向上します。製品コード45種類に対し商品名付加でビジネスユーザーの読みやすさが格段に向上します。8種類のステータスコードはコード表参照不要な説明文追加が望ましいです。社員IDはプライバシーを守りつつ名前の付加が推奨されます。これらの拡張はデータ量を大幅に増やさずユーザー体験を顕著に改善します。
例6: データ完全性の傾向監視
シナリオ: 定期的にデータ抽出を行い、現在の抽出統計と過去の基準値を比較してデータ完全性が改善または悪化しているかを監視したい。
設定:
- タイトル: "データ完全性モニタリング - 2025年2月"
- 説明: "1月基準値との比較"
出力:
| 属性名 | タイプ | 1月ヌル率 | 2月ヌル率 | 変化量 | 傾向 |
|---|---|---|---|---|---|
| ApproverName | Event | 5.2% | 3.1% | -2.1% | 改善 |
| Department | Case | 8.4% | 8.9% | +0.5% | 悪化 |
| CostCenter | Event | 12.3% | 18.7% | +6.4% | 悪化 |
| Priority | Case | 1.2% | 1.1% | -0.1% | 安定 |
| DueDate | Case | 15.6% | 9.2% | -6.4% | 改善 |
洞察: 比較によりデータ品質の傾向は混在しています。ApproverName のヌル率は5.2%から3.1%に減少し、承認段階でのデータ取得が改善されたことを示しています。CostCenter のヌル率は12.3%から18.7%に大幅に増加し、コストセンターの割り当てが悪化しており即時対応が必要です。DueDate 完全性の劇的な改善（15.6%から9.2%）は必須の期限入力導入成功を反映します。これらの傾向は継続的なデータ品質改善施策の指針となります。
出力内容
Column Info 計算機は、イベントログ内のすべての属性について詳細統計を含む包括的なテーブルを表示します。テーブルにはケースレベルおよびイベントレベルの属性が含まれ、以下の情報が提供されます。
属性名: データセット内に表示される属性の名前。
属性タイプ: ケースレベル属性（一件のケースにつき一値）かイベントレベル属性（一件のイベント／アクティビティにつき一値）かを示す。
データ型: 属性の検出されたデータ型（文字列、整数、小数、日時、ブール値など）。
総値数: その属性について存在する値の総数（ケース属性なら総ケース数、イベント属性なら総イベント数）。
ヌル数: その属性のヌルまたは欠損値の数。
ヌル率: ヌル値の割合（ヌル数／総値数 × 100）として計算。
固有値数: その属性に含まれるユニークな値の数。
カーディナリティ比率: ユニーク値数を総値数で割った比率のパーセンテージ表示。100%に近い高カーディナリティはほぼすべてユニークな値を示し、低い場合は繰り返し値が多い。
サンプル値: 属性からの代表的な値のサンプル。通常3～5つの異なる値が表示され、データ形式や内容のイメージに役立つ。
最小値: 数値型または日時型の場合は最小（最も小さい／最も古い）値。
最大値: 数値型または日時型の場合は最大（最も大きい／最も新しい）値。
インタラクティブ機能
並べ替えとフィルタ: 列ヘッダーをクリックして任意の指標でソートが可能。検索ボックスを使い特定の属性に絞り込みも可能。
結果のエクスポート: 解析結果全体をExcelまたはCSVとしてエクスポートし、ドキュメント作成や比較、技術チームとの共有に活用可能。
詳細分析: 属性名をクリックすると値の頻度分布やさらに詳細なサンプル値などの追加統計を表示。
パフォーマンス注意点
- 大規模データセット: 数百万イベントや数百属性のデータセットは解析に数分かかる場合がある
- リソース使用量: すべての属性値に対する包括的なスキャンを行うため、メモリおよびCPUリソースを多く消費
- 推奨操作: 非ピーク時間に実行するか、フィルタでデータサイズを縮小しての実行がおすすめ
管理者アクセス
この計算機は管理者ロールを持つユーザーのみ利用可能です。一般ユーザーはデータセットの概要情報が得られる Dataset Information 計算機を使用してください。こちらは詳細なカラム分析による負荷を軽減した主要指標を提供します。
本ドキュメントは mindzie Studio プロセスマイニングプラットフォームの一部です。