第 5 章: 完全な設計アプローチ
1. 3 つの構築前提条件
1.1 統一されたデータ思考
1.1.1 データ認識
企業が自社のデータを明確かつ統一的に理解しているかどうかを判断するには、主に次の 3 つの質問に答えて、統一された答えを形成できるかどうかによって決まります。
- データはどこにありますか?
- データの価値とは何でしょうか?
- データの使い方は？
1.1.2 データアーキテクチャ
DT 時代では、データ アーキテクチャは、データのスムーズな流れを確保し、データ リソースをデータ資産として動作させ、ビジネスと製品の商業的価値のライフラインとして機能するために使用されます。
- ビジネスのデータ化: データ アーキテクチャの最下層は、ビジネス プロセスまたは対象となるデータ保持を通じて各ビジネス システムによって生成される情報システム データです。技術者は、収集および交換ツールを使用して、ビジネス システム内のデータをクリーンアップ、交換、要約して、エンタープライズ データ センターを形成できます。
- データ資産化: データセンターでは、データ開発者は、オフライン、リアルタイム、アルゴリズム開発などのさまざまなコンピューティング エンジン ツールを使用して、さまざまな種類のデータを処理できます。つまり、生のデータを分類し、理解、表示、分析できるデータに処理します。ビジネスで使用されるデータ資産は資産管理ツールにも存在し、引き続き管理および最適化されます。
- アセット サービス: アセット センターでは、標準化された編成と並べ替えが行われたデータ資産がフィルタリングされ、サービス コンポーネント ツールに注ぎ込まれます。サービス センターでは、すべてのデータ呼び出しと操作に対して、測定、グローバル監視、およびスケジューリング構成を実行できます。
- サービスの商用化: 作成されたデータ サービス (API) は、カプセル化層のインターフェイスで既存のビジネス システムやデータ アプリケーション製品に直接接続でき、最終的にはビジネスをサポートして問題解決や業務実行効率の向上を支援し、ビジネス価値を生み出します。
1.1.3 約定保証
実行保証とは、企業のあらゆるレベルで対応するデータ戦略保証と対応作業を行う必要性を指します。
- リーダーはデータ戦略の方向性の指針を提供し、対応する組織サポートを提供するために組織構造を調整する必要があります。
- 経営者は、データ戦略を戦術的サポートに変換し、具体的なデータ指向の運用計画と評価指標を策定し、データ戦略の効果的な改善と下方への伝達を導く必要があります。
- 実行層は、運用計画と評価指標に従って、データフローの円滑な進行とデータアーキテクチャリンクの秩序ある接続を確保するために積極的に努力し、データ思考とデータを通じてデータの運用と使用の能力と限界を継続的に改善する必要があります知識の学習。
1.1.4 価値の推進要因
データ資産の価値を実現することが最も基本的な目標です。どのようなデータを接続するのか、どのようなデータ資産を構築するのか、どのように管理・最適化するのか、どのようなデータアーキテクチャを構築するのか、どのようなサポートを提供するのかなど、価値の観点から検討する必要があります。
1.1.5 シナリオの機能
不確実な将来に直面している企業は、柔軟なデータ サポート機能を必要としています。データ項目、データ項目、およびデータ サービスは疎結合されており、いつでも分割または結合できます。再利用可能な価値を持つデータ資産アイテムとデータ サービス機能を、事前にデータ センターに預けることができます。
1.2 適切な事前調査
1.2.1 ビジネスシナリオ調査
サービスを受ける顧客は誰ですか? 顧客のビジネスプロセスはどのように実行されますか? お客様の日々の業務プロセスはどのように進められているのでしょうか？それに関連付けられている上流ノードは何ですか? 下流ノードとは何ですか? クライアントの現在の役割の目標は何ですか? チームの目標は何ですか? 部門の目標は何ですか?
1.2.2 オンデマンドの問題点に関する調査
どのビジネス リンクにどのような問題点が存在しますか? これらの痛みの原因は何でしょうか? これらの問題点はどれほど深刻で、どのような重大な結果をもたらすのでしょうか? では、どのような需要が生まれるのでしょうか？
1.2.3 データの徹底的な調査
- どのようなデータがあるのかをユーザーに推測させるのではなく、事実から真実を求め、実際に存在するデータを登録・整理します。
- 顧客がデータを過小評価しないようにしてください。
1.3 アイデアを正しく実装する
1.3.1 ビジネスプロセスに基づいてデータカテゴリシステムを整理する
企業の既存業務プロセスの情報システムにおいて、企業の既存データ状況を整理し、企業のデータカテゴリーシステムを構築することができます。「プロセス」ごとに整理されたデータ、「モノ」ごとに整理されたデータ、「人」ごとに整理されたデータで構成されます。
1.3.2 ビジネスニーズに応じたラベルカテゴリシステムの設計
企業の既存のデータ メモリを完全に組み合わせた後、ビジネス ニーズに応じてラベル カテゴリ システムを設計できます。「ヒト・モノ」に合わせてデザインされるラベルは、ビジネスニーズを考慮する一方で、「ヒト・モノ」ごとに整理されたデータに基づいたものでなければなりません。
2. 6 つの設計ステップ
2.1 オブジェクトの識別
「人」は積極的に行動を起こす主体、「物」は行動の受け手、「関係」とは、ある瞬間における人と物、人と人、物と物などの間の一定のつながりを指します。行動関係、所属関係、思考関係などの弱い関係。
2.2 同じオブジェクトのデータを開く
複数のシステムでは、同じオブジェクトが異なる ID で構成された情報レコードを持っているため、複数の ID の間で同じオブジェクトを識別する必要があります。
2.2.1 IDマッピング技術
ビッグ データの分野における ID マッピング テクノロジは、特定のオブジェクトについて複数のデータ ソースを接続するという問題を解決するために使用されます。ID 関係のペアを入力し、機械学習アルゴリズムを使用して確率一致計算を実行し、ID 関係ネットワークを構築します。
2.2.2 ワンID
各 Web サイトは、One-ID と呼ばれるユーザーの統一 ID をカスタマイズできます。各ユーザー アカウント ID は、特定の One-ID コードに一意に対応できます。
2.2.3 4段階のID
- 第 1 レベル ID: ID カード情報、パスポート番号、運転免許証番号、顔 ID、指紋 ID、虹彩 ID などの強力なアイデンティティ属性 ID。現実社会で個人を一意に識別するために使用される番号です。
- 第 2 レベル ID: 携帯電話番号、携帯 IMEI、携帯 IDFA、携帯電話 MAC、PC MAC など、個人に密接なデバイス関連の ID。
- 第 3 レベル ID: Alipay アカウント、淘宝網アカウント、WeChat アカウント、水道メーター アカウント、医療保険アカウント、ゲーム アカウントなどの登録アカウントに関連する ID。それらは多くの場合、個人の社会化された行動を反映しています。
- 第 4 レベルの ID: Cookie、IP アドレス、GPS 測位、操作動作などの関連する ID を一時的に記録します。このタイプの ID は弱い ID です。上位レベルの ID が利用できない場合は、それらを使用して ID を確立することもできます。コア ID との関係 一時的な関係。
2.2.4 IDとIDの関連付け操作
One-IDのベッドフレームルールを設定した後、One-IDと他のID間で情報を通信します。One-ID に関連付けられる ID が増えるにつれて、ID 間のペア関係のペアの数はますます速く増加します。
2.3 データに基づいた物事の表現
現実世界を素早く読み取るためのデータマッピング：あらゆるものを「人」「物」「関係」の3つのカテゴリにマッピングし、各オブジェクトの全次元属性とその下流の特定の属性値を体系的に整理します。それぞれの属性。データに基づくものによって表現される意味には次のようなものがあります。
- この方法は、データ カテゴリ システムとラベル カテゴリ システムを構築するための基礎となります。
- この方法は、ビジネス担当者がデータの考え方を変革し、データ言語を使用してビジネスの問題点を表現および変換する方法を学ぶのに役立ちます。
- このデジタル分解手法を通じて、データ情報を整理し、秩序だった方法で分類することができます。
- このアプローチは、現在のビジネス上の問題を解決するだけでなく、将来のデータ使用のインスピレーションを引き起こすこともできます。
2.4 データカテゴリーシステムの構築
2.4.1 データカテゴリーシステムのオブジェクト抽象化
企業情報構築では、取得、保管、通信などの段階を経て、さまざまな生データが蓄積されます。従来の企業は「業務プロセス」に沿ってデータを蓄積するだけでしたが、一定の情報化基盤やデータウェアハウス構築が完了した企業では、業務システムのデータベースから「人」や「モノ」に関する情報を具体的に抽出し、基本的なデータと組み合わせることで、 「人」と「物」の情報テーブル。エンティティオブジェクトの包括的な情報の要約を実現するために、「人」と「物」の独自のデータベースが構築されます。
2.4.2 データカテゴリシステムのカテゴリ分類
オブジェクト ディレクトリが決定したら、そのオブジェクトの下のデータ カテゴリを展開する必要があります。
1) 「プロセス」オブジェクトのデータカテゴリーを整理する
多くの場合、プロセス データ カテゴリでは、ビジネス所有権、ビジネス リポジトリ、ビジネス テーブルなどに従ってデータを分類できます。
２）「人」や「物」などの実体オブジェクトのカテゴリーを整理する
データ カテゴリ システムは、企業の元のデータに対する構築者の理解を反映しており、データベース、データ テーブル、データ フィールドが実際にどのように編成されているかを、発散しすぎずに、それに応じてデータ カテゴリに変換できます。
元のデータがデータカテゴリーシステムに従って処理された後、以前のビジネスでデータ収集の形式、サイクル、送信方法がどのように変更されたとしても、データカテゴリーシステムに転送された後もデータは安定したままになります。 。オリジナルデータの管理、つまりデータカテゴリシステムは、業務フォームや業務計画などの上位の変更に伴って、その根底にある構造を変えることはありません。
2.5 ラベルカテゴリシステムの構築
企業が独自に蓄積したデータカテゴリシステムを整理した後、ビジネスシナリオのニーズに応じてタグとタグカテゴリシステムを設計する必要があります。ラベル カテゴリ システムの設計プロセスは、データ カテゴリ システムよりも複雑です。
2.5.1 ラベルとは
データ カテゴリ システムのデータは、まだ処理されていない企業の元のデータを指し、クリーニングと処理が必要なすべてのデータのカテゴリです。データ収集側を重視しており、「データはどこにあるのか?」という質問に答えます。「タグ」とは、元のデータからクリーンアップおよび処理され、ビジネスで使用して価値を生み出すことができるデータ リソースを指します。通常、サービス指向の使用を確保するには、フィールドの粒度に合わせて構造化する必要があります。データ活用側に特化しており、「データをどう活用するか」「データの価値は何か」という疑問に答えます。
1) ラベルデザインの 2 つの前提条件
ラベルは何もないところから設計することはできず、ラベルの開発と実装のデータの実現可能性を考慮する必要がありますが、同時にラベルはビジネス ニーズであり、ビジネス担当者がビジネス上の判断、サポート、支援を行うのに役立つデータ項目である必要があります。
2) ラベルとラベル値の違い
タグはオブジェクトの属性を記述し、フィールドの細分性に従って構造化されたデータ リソースです。タグは、特定の種類のオブジェクトの本質を記述します。タグ値はフェーズであり、多くの場合、時間と空間とともに変化し、各人は異なるタグ値を持ちます。
2.5.2 ラベルデザインの5つのアイデア
ラベルのデザインは通常、ビジネス要求の抽象化から生まれます。ビジネスの問題点を対応するデータ ソリューションに分解し、データ ソリューション内のデータ リソースをフィールド粒度に分解するのがラベル設計プロセスです。
- 中心となる単語の属性の観点から分岐します。
- インクルージョンとポゼッションの観点から分岐します。
- 詳しく考えてください。
- 開発プロセスの観点から考えてください。
- 同じ種類のものの統一された抽象化から生まれる特別なラベルデザインのアイデアがあります。タイプを強調表示する必要がある場合は、値をラベルに変換することもできます。ラベルの各値に「wether」プレフィックスまたは「degree/index」サフィックスを追加します。
2.5.3 ラベル カテゴリ システムが必要な理由は何ですか?
データ マッピングの原理によれば、企業または企業の事業部門によって蓄積されるデータ項目と、ビジネスで使用する必要があるラベル項目が多数存在すると推定されます。タグを体系的に分類するには、分類メカニズムが必要です。
- ラベルを分類および管理し、ガバナンスを最適化し、計画を推進するためのラベル カテゴリ システムを確立します。
- ラベル カテゴリ システムを使用して、オブジェクトとカテゴリに基づいてラベルをデザインできます。体系的に考えて、データ資産の分類とグレーディングを計画し、上から下まで、粗いものから細かいものへと製造ラベルを整理します。
2.5.4 ラベルカテゴリシステムの構造
1) ルートディレクトリ
タグ カテゴリ システムを構築するには、まずルート ディレクトリを決定する必要があります。表示中の細分化されたグループはラベルカテゴリ体系にマッピングされており、細分化されたルートディレクトリであるか、細分化する必要がないのかは属性値によって区別される。
- セグメント化されたオブジェクトのプロパティは大きく異なりますか? 企業の情報構築がますます完全かつ豊富になり、オブジェクトの研究がますます深くなると、多数のオブジェクトと特定のオブジェクトに基づくラベルカテゴリシステムを構築する必要があります。
- 現実世界の分類をカテゴリとして直接使用しないでください。サブディビジョン オブジェクトの属性タイプが類似していない場合、それらは直接複数のサブディビジョン オブジェクトに分割され、属性のアウトラインが類似している場合、それらは 1 つのオブジェクトになります。ラベル カテゴリ システムのカテゴリは、オブジェクトではなくラベルの分類です。
2) オブジェクト属性タグ
「人」と「物」のエンティティ オブジェクトには、当然ながらいくつかの静的タグがあります。「人」や「物」が動き、何らかのつながりが生じると、新たな「○○関係」というオブジェクトが生成されます。この新しいオブジェクトには、関係が発生する動的タグが当然あります。これらの「関係」オブジェクトの動的タグを「人」または「物」に投影することで、閲覧時間、閲覧チャネル、閲覧深度、その他の動的タグなどの対応する動的タグを生成できます。
3) カテゴリーシステム
カテゴリシステムとは、ある種類のアイテムの分類および構造編成方法を指します。カテゴリ体系はツリー構造になっており、ルートディレクトリから伸びる第 1 レベルの枝が第 1 レベルのカテゴリとなります。第 1 レベルの枝から伸びる第 1 レベルと第 2 レベルの枝が第 2 レベルのカテゴリになり、第 2 レベルの枝から伸びる第 3 レベルの枝が第 3 レベルのカテゴリになります... 上位レベルのカテゴリを持たないカテゴリは第一レベルのカテゴリとなり、下位レベルのカテゴリを持たないカテゴリはリーフ カテゴリとなり、リーフ カテゴリにぶら下がっている特定のリーフはラベルになります。下位カテゴリを持つカテゴリは下位カテゴリの親カテゴリであり、上位カテゴリを持つカテゴリは上位カテゴリのサブカテゴリです。
2.5.5 ラベルカテゴリーシステムのカテゴリー設計の考え方
データカテゴリシステムは、データの収集、保管、管理、その他のシステムの元のシステムに従って分割することをお勧めします。これにより、データ管理者とデータ開発者がカテゴリを思考方法や認知方法と一致させ、必要なデータを見つけることができます。ラベル カテゴリ システムの重要性は、ビジネス担当者、プロダクト マネージャー、その他のデータ資産ユーザーが理解し、検索し、評価するためのものであるため、オブジェクトの理解や価値シナリオなどのデータ アプリケーションの観点に応じてラベル カテゴリ システムを分割することをお勧めします。ビジネスに必要なラベルを探索し、データ資産の価値を最大限に活用します。従来の技術的な視点を変え、ビジネス担当者が理解できるビジネス的な視点でタグを整理する必要がある。
さまざまなビジネスおよび管理シナリオにおけるすべての企業、機関、政府のデータ ニーズを満たすことができる、普遍的で統一されたタグ カテゴリ アーキテクチャは存在しません。唯一変わらないのは、実際のビジネスと経営のニーズに応じてラベルカテゴリシステムを構築するという考えです。以下のアイデアと経験は参考として提供されます。
１）ラベルカテゴリー「人」のデザイン案
人間のラベル カテゴリ システムを構築する場合、第 1 レベルのカテゴリは次の次元から考慮できます。 まず、比較的静的で固定された基本属性。これには、個人の統計情報、ファイル情報、生理学的情報、教育情報、仕事情報、永住地が含まれます。情報など; 基本的な属性の上に、各人の行動の内容とその行動で発生する関係性を含む、より動的でシーンベースの行動関係を考慮します; 行動の上に、行動に基づいて抽出された興味や習慣に注目します趣味、行動習慣などを含む人間関係、興味や習慣に基づいて人々の性格特性をさらに調査でき、性格に基づいて人々の思考意識を抽象化できます。
２）「もの」のラベルカテゴリーのデザインアイデア
構造物のカテゴリにラベルを付ける場合、第 1 レベルのカテゴリは次の緯度から考慮できます。
- 物体の基本情報、カテゴリの所属、色パターン、包装と保管、サイズと重量、成分組成などを含む、静的で固定された基本属性を考慮します。
- 基本情報に基づいて、サービス、利用方法、利用サイクルなどのオブジェクトの機能的役割を含む、オブジェクトの機能的有用性を検討します。
- 機能的な有用性の後には、所属、生成と製造、運用と販売、リリースと保守などを含むマスターとスレーブの属性がさらに考慮されます。
- 最初の数種類の静的な情報の後で、閲覧、収集、購入、輸送、評価、苦情のプロセスから拡張できる、ものの使用プロセスにおけるさまざまな関係を含む、より動的な受動的な関係を検討します。
- 関係条件、関係行動、関係結果など、表と裏の開発プロセスから展開します。
- 家庭で使用する、仕事で使用する、娯楽で使用するなど、さまざまなタイプの受動的な関係に応じて分割します。
- 品質評価、サービス評価、コストパフォーマンス、安全性評価、適用性、拡張性、市場シェア、競争ランキング、認証と認可などのさまざまな側面を含むオブジェクトの価値評価を深く要約し、調査します。
第 1 レベルのカテゴリを構築したら、人々のラベル システム構築のアイデアを参考にして第 2 レベルと第 3 レベルのカタログを拡張し、各リーフ カテゴリの下にタグを配置できます。
3) 「関係性」ラベルカテゴリーのデザインアイデア
関係のラベル カテゴリを構築する場合、第 1 レベルのカテゴリは次の次元から考慮できます。
- 関係に関与する関連する人々と関連するオブジェクトのラベルを整理します。関係オブジェクトの下にある関連する人物または関連する物は、関係の属性記述であり、関係全体に表示される人物または物の属性のみを含みます。
- 関係を引き起こすための機会、仕組み、準備条件などの関係の準備レベルから考え、次に時間、場所、天気、方法、経路、その他の空間などの関係の実際のプロセスレベルから考える-関係の時間的条件、関係の時間と場所、参加者、参加者、ステップ、頻度、程度、強さ、つながり、その他のプロセスの行動、最後に関係の結果レベルから考えることができます。プロセスの直接的な結果、各リンク内のリンクの変換、総合的な効果の評価、各リンクの分割、要因の副作用評価、最適化の推奨事項、その他の側面。
第 1 レベルのカテゴリを構築した後、人々のラベル システム構築のアイデアを参考にして第 2 レベル、第 3 レベルのカタログを拡張し、各リーフ カテゴリの下に詳細なタグを配置できます。
4) 各オブジェクトカテゴリの概要
人、物体、関係のラベル カテゴリを要約すると、企業の完全なラベル カテゴリ構造図が得られます。
2.5.6 タグカテゴリシステム構築時のよくある質問
1) 同じものが異なるオブジェクトにラベルを形成しますが、この情報は冗長ですか?
タグ カテゴリ システムを構築する主な目的は何ですか? これにより、ビジネス担当者は目的のタグをできるだけ早く見つけて、それらを簡単かつ迅速に組み合わせることができます。タグ カテゴリ システムの方法論では、タグを検索および使用するときのロジックが明確になるように、それぞれの目的に応じて包括的なタグを構築することが推奨されます。
2) 現在は使用されていないが、将来使用される可能性のあるラベルをデザインする必要がありますか?
ラベル カテゴリ システムは、既存のデータベース、現在および将来のビジネス ニーズに基づいて設計および計画されており、再利用可能で価値のあるラベルの完全なセットです。人、物、および関係オブジェクトの下にある利用可能なラベルをすべて含める必要があります。可能な限り。タグカテゴリシステムは、顧客の現在のニーズを解決するだけでなく、企業の将来のシナリオベースのデータニーズにも対応し、将来の問題を解決します。
3) 事業展開に伴ってタグカテゴリシステムの構造も変化するのでしょうか？
- ラベル カテゴリ システムの階層的かつ段階的な抽選は、将来の適用可能性を可能な限り考慮に入れており、カテゴリ構造を頻繁に変更することはお勧めできません。したがって、カテゴリを設定するたびに、ある程度の拡張性を考慮し、並列カテゴリの粒度が一貫しているかどうかに注意する必要があります。タグを追加する場合、通常は元のカテゴリを変更する必要はありませんが、元のカテゴリに基づいてサブカテゴリを細分化する必要があります。
- カテゴリ システム構造は通常 3 つのカテゴリを超えず、階層レベルの数が多すぎないことをお勧めします。タグの数が多い場合は、カテゴリの深さをカテゴリの幅に変換する、つまり水平分類の数を増やすとよいでしょう。
ラベル カテゴリ システムの使用シナリオを広範に検証した結果、各レベルのカテゴリが 10 個以下の 3 レベルの分類構造、つまり合計カテゴリ ツリーが 1,000 個以下の方がより適切なカテゴリであることがわかりました。構造。
2.6 表裏ラベルのカテゴリー体系
会社の完全なラベル カテゴリ システムを構築した後、それをさらにフロントエンド カテゴリとバックエンド カテゴリに処理する必要があります。
2.6.1 フロントエンドとバックエンドのカテゴリとは何ですか?
エンタープライズ バックグラウンド タグ カテゴリ システム: データ資産の完全なコレクション、つまり、デポジットされ、再利用可能で価値のあるすべてのタグ プールです。データ資産設計者または管理者は背景ラベル カテゴリ システムを作成および維持でき、他の担当者はカテゴリ システムを表示できますが、自由に変更することはできません。背景ラベル カテゴリ システムは比較的安定しており、文字や関係のさまざまなオブジェクトの本質的な説明と説明属性の普遍的な分類です。ビジネス シナリオと疎結合されており、人、物、関係などのさまざまなオブジェクトに対するグローバルで安定したラベル定義を維持します。
フロントエンド ラベル カテゴリ システムは、ビジネス シナリオへの影響に焦点を当て、ビジネス要件に従って必要なラベルのセットを収集し、ビジネス システムまたは呼び出すデータ アプリケーションのビジネス理解に従ってラベルを分類します。したがって、フロントエンドのラベル カテゴリ システムはビジネス シナリオの変化に応じて変化し、柔軟で構成可能です。ビジネス シナリオ自体は、存続期間が短かったり、すぐに生成されたり、すぐに終了したり、別のビジネス シナリオに発展したりする場合があり、それに関連するフロントエンド ラベル カテゴリもそれに応じて追加、削除、または発展します。
2.6.2 フロントエンド カテゴリとバックエンド カテゴリの関係と違い
フロントエンド ラベル カテゴリは通常、大規模なシーン/サブシーン/データ サービスのレベルに応じて拡張されます。大規模なシーン/サブシーン/データ サービスの下で、まず関係するオブジェクトを抽象化し、次にバックグラウンド ラベル カテゴリ システム オブジェクトの下のラベル コレクションに移動して、データ サービスに必要なラベルを見つけて、それをフォアグラウンド カテゴリ オブジェクトに追加します。 。
フロントエンド カテゴリの構築の考え方はバックエンド カテゴリの構築とは異なります。フロントエンド カテゴリの構築方法はデータ シナリオの設計と密接に関連していることが多く、合理的なフロントエンド カテゴリ システムは多くの場合密接に関連しています。データ製品システムの設計に関連します。フロントエンド カテゴリは、データ製品システムのアプリケーション開発を容易にし、フロントエンド開発エンジニアがデータ製品の各機能モジュールとオブジェクト タグの間のマッピング関係を迅速に明確にするのに役立ちます。
分類されたフロントエンドとバックエンドのタグ カテゴリ システムを組み合わせると、企業向けの完全なタグ カテゴリ システムが形成されます。
2.6.3 前カテゴリと後カテゴリの意味を区別する
フロントエンド カテゴリとバックエンド カテゴリを区別するのはなぜですか? ビジネスニーズと技術管理の間には矛盾があるためです。一方で、ビジネスは柔軟かつ変化しており、そのデータ要件は応答性が高く柔軟であるため、特定のシナリオに応じたラベルの編成方法は自由に構成できる必要があります。しかしその一方で、技術的な観点からタグを管理する場合、タグの編成方法が比較的安定していることが望まれ、ビジネス担当者がタグ ポータルにアクセスしてタグを表示および選択するときに、タグの編成方法が安定していることも期待されます。比較的安定。
2.6.4 フロントエンドおよびバックエンド カテゴリの設計手順を完了する
- 企業の既存のビジネス ニーズとデータ状況に基づいて、オブジェクトを特定します。
- これらのオブジェクトをラベル カテゴリ システムのルート ディレクトリとして決定します。
- 各ルート ディレクトリの下で考えられるすべてのタグを分類し、カテゴリ アーキテクチャを使用してタグを分類します。
- 取得したカタログを記録、計画、管理します。
- 各バックエンド カテゴリの下に特定のタグを配置します。
- 企業内のすべてのタグのカテゴリ管理であるバックグラウンドタグカテゴリシステムが構築され、タグカテゴリ関連の文書または参照可能なシステム情報が形成されます。
- ビジネス シナリオのニーズに応じて、特定のデータ アプリケーション シナリオ、つまりフロント デスクを決定します。
- 前景シーンに含まれるオブジェクトを決定する 原則として、前景オブジェクトは背景のすべてのオブジェクトのサブセットです。
- フロントエンド データ アプリケーションのシナリオに従って、必要なタグとフロントエンド カテゴリ構造を整理します。
- フロントエンドカテゴリを統一した方法で記録、調整、管理します。
- 使用する必要があるタグを各フロントエンド カテゴリの下に置きます。
ラベル デザインとカテゴリ デザインのプロセスは、相互に統合される補完的なプロセスです。最初にビジネス ニーズに従ってラベルをデザインすることを選択し、次にラベルを分類することもできます。また、最初にカテゴリを計画し、次にそのカテゴリの下で特定のラベルをデザインすることもできます。 ; 実際の状況は、上記 2 つのプロセスの最適化の反復を繰り返すこともあります。