#目的

Attributesページは、Lakehouse Managerのすべての属性を一意の属性名でグループ化します。これらの属性はそれぞれ、リアルムに属しています：物理的または仮想的です。

#物理的な属性

物理的な属性は、Lakehouse Managerテーブルに物理的に保存されている属性です。テーブルレベルでそのカテゴリ、タイプ、その他の情報を編集できます。

Attributesページでは、名前ごとにグループ化されており、データウェアハウス/データレイク全体で各属性が取る異なるカテゴリとタイプを一目で確認できます。

各属性を展開すると、この属性を使用するプロジェクト内のオブジェクトの完全な系譜を取得できます:

• Lakehouse Manager テーブル
• Data Processing Engine アクション
• Analytics Manager クエリ

一部の属性は、辞書のキーになることがあります。その場合、別の属性がこの属性のラベルとして使用され、キーの代わりにアプリケーションに自動的に表示されます。

ラベルは、Tablesスクリーンで、辞書キーを主キーとして含むテーブルレベルで設定できます。

#サポートされている属性タイプ

属性は、次の原始的なタイプをサポートしています:

integer, bigint, float, real, double, decimal, varchar, boolean, timestamp, date。

ネイティブなGEOMETRYタイプはありません。複雑または入れ子になった構造はネイティブに保存されません。以下のパターンは、その間に最も一般的なニーズをカバーしています。

#非構造化または複雑なデータの操作

ドキュメント（PDF、Word、...）

1. 生のファイルをバケットに保存します。
2. カスタムアクション（Python、ライブラリのpypdfまたはpython-docxをPython Requirementsを通じてインストール）でその内容を抽出します。
3. メタデータと抽出されたテキストをテーブルに書き込み、クエリを実行できます。

地理的オブジェクト

現在、ネイティブなパスはありません。2つのオプションがあります:

• WKTテキストをvarchar属性として、またはWKBをVARBINARY属性として保存します。
• Apache Sedona（PySparkカスタムアクションのGit依存関係として追加）またはNotebook内のgeopandas / shapelyでスキーマの外で空間計算を実行します。

半構造化JSON

• スキーマが安定している場合は、IcebergでROW / MAPフィールドを使用します。
• スキーマが変化する場合は、Trinoのjson_*関数（json_extract, json_parse）を使用するvarchar属性を使用します。

フルテキスト/ベクトル検索

ネイティブなパスはありません。推奨されるパターンは、出力側のカスタムアクションを通じて外部サービス（管理型Elasticsearch、ベクトルデータベース）にエクスポートすることです。

#制約

物理的な属性は、テーブルが構築される際に適用される制約を持つことができます:

• 必須: フィールドはNULLを含むことはできません。
• 必須 + 識別子: フィールドはアップサート操作で行の一意性を定義するために必要です*。識別子フィールドはdoubleまたはdecimalではありません。

これらは、テーブルで属性を追加または編集する際に設定します。

#名前付け規則

属性名はテーブルごとに一意ですが、プラットフォームはAttributesページでプロジェクトレベルで名前ごとに集約します。これにより、例えば同じcode属性が1つのテーブルではintegerとしてタイプされ、別のテーブルではbigintとしてタイプされているなどの不整合を検出できますが、それを防ぐことはできません。

属性だけでなくテーブルにも適用される一般的な命名ガイドラインと予約語のリストについては、TablesページのNaming ConventionsとReserved Wordsを参照してください。

#同音異義語属性の処理

code、libelle、またはvalueのような属性が、異なるタイプの異なるソースから来る場合、次の実践を使用します:

1. ドメインまたはソースでプレフィックスを付けます。 顧客の場合はclt_code、clt_libelle、clt_valueを使用し、製品の場合はprd_code、prd_libelleを使用し、注文の場合はcmd_codeを使用します。プレフィックスはcodeをentity_codeに変換し、読み取り時と自動検出された式の両方で曖昧さを取り除きます。
2. 名前の変更が不可能な場合は、テーブル全体でタイプを統一します。 最も広いタイプ（decimalまたはbigint）を選択し、ソーステーブルでCASTをINSERT時に実行します。これにより、Attributesページでのタイプの不整合は少なくとも解消されます。
3. タグと説明で文書化し、名前が曖昧な場合の使用を区別します。
4. 短い汎用名 (code, libelle, value, id, name, status)をクロスカット使用に予約するか、全く避ける。

#共有属性の文書化: データ辞書

Data Platformには完全な外部データカタログは付属していませんが、いくつかの組み込みメカニズムはすでに機能的なデータ辞書として機能しています:

• Attributesページ。 プロジェクト全体の各属性名に1つのエントリがあり、テーブル全体でそのタイプとカテゴリの内訳（codeとしてinteger vs bigint vs decimalを検出するのに最適）があり、それを消費するオブジェクトの完全な系譜があります。上記で説明されているように。
• ポリシータグ。 ポリシータグはアクセス制御のために設計されましたが、データの分類にも再利用できます: domain: finance, sensitivity: high, pii: true, glossary_term: client_id。ポリシータグはデータセットからテーブル、属性に継承されるため、データセットに設定されたタグはその下の未タグの属性全てに適用されます。これにより、ベースラインを設定し、必要に応じて上書きできます。
• 辞書。 上記で説明されている辞書メカニズム（キー→ラベル）は、コード→ラベル参照テーブルを処理します。

属性ごとの豊富な説明、ビジネス用語集、所有権、外部カタログ（Collibra、DataHub）との統合は利用できません。これらのニーズには、補完的な外部ツールが依然として必要です。

#バーチャル属性

バーチャル属性は、データに新しい式を計算するために使用されます。これらはデータベースに保存されていませんが、クエリまたはダッシュボード/レンダリングチャートの実行時に動的に計算されます。

#バーチャル属性の式

バーチャル属性の最も重要な要素は、そのSQL定義です。

SQLキーワードと物理属性の組み合わせを含む式を記述します。

#バーチャル属性の式の例

SUM(rides)/COUNT(DISTINCT CONCAT(CAST(date AS VARCHAR), CAST(station_id AS VARCHAR)))

ここで、rides、date、およびstation_idは、Lakehouse Managerテーブルから取得した物理属性です。プラットフォームは、これらを自動的に検出し、クエリ対象の最も関連性の高いテーブル（式に明示的に定義されていない場合）を特定します。

#バーチャル属性のオプション

#必須属性

プラットフォームは、バーチャル属性の式を実行するために必要な物理属性を自動的に検出します。

バーチャル属性の詳細設定で編集できます。編集する理由は（以下に限定されません）、式内の物理属性がSQLキーワードとして検出される代わりに必要な属性として検出される、またはその逆の場合です。

#型

バーチャル属性の型は、作成時に自動的に推論されます。この型により、プラットフォームはバーチャル属性を使用するクエリの計画を自動化できます。

バーチャル属性の詳細設定で編集できます。編集する理由は（以下に限定されません）、バーチャル属性に基づいてフィルタ値を変換すると、別の型に自動的に変換され、Analytics Managerでクエリが失敗する場合です。

#さらに詳しく知る

当社のソリューションを実装するためのトレーニングや技術サポートが必要な場合は、営業担当者にお問い合わせください、またはこのリンクをクリックして見積もりを依頼し、当社のプロフェッショナルサービスの専門家にプロジェクトのカスタム分析を依頼してください。

質問をする、フィードバックを送信する、またはData Platformを構築するチームと直接交流するには、専用のDiscordチャネルをご利用ください。

OVHcloudサービスについてサポートが必要な場合は、ヘルプセンターでリクエストを作成してください。

ユーザーコミュニティに参加してください。