データモデルとは何を指すのでしょうか。毎日データモデルに接して熟知しているTalendの開発者は、以下のようにデータモデルを定義しています。 ビジネスシステムデータの構造的定義 ビジネスデータのグラフィカルな表現 ビジネスソリューションを構築するためのデータ基盤 これらはいずれも真実かもしれません。しかしあえて言うなれば、いずれも本質的な定義ではありません。それぞれ単独では、データモデルが本来実現すべき核心/目的あるいは目標に到達するものではなく、末梢的であるためです。 では、何が本当にデータモデルであると言えるのでしょうか。あれこれ思いつくものの、やはり一点に尽きるのではないでしょうか。私にとって、データモデルは、ビジネス情報システムをグラフィカルな方法で明確に特徴付けるものとして表現される構造基盤です。どう思われますか? 上記の定義と同一というわけではありませんね。この定義は、すべての要素を単一の目的に包含します。つまり、データだけでなく、構造的にビジネスのユースケースに関する情報を識別するための手段なのです。 このブログシリーズの第1部では、50年間のデータモデリングの歴史を4つの短い段落にまとめました。省いた部分もありますが、前任者から学んだ教訓と改善の結果として、データモデリングに関する私たちの知識や達成がどのように実現したのかを理解できるのではないでしょうか。今日、ほとんどの企業が要件を検証するために活用してるデータモデルには、真のビジネス価値があります。しかし、これらの企業が正しい方法を理解しているかどうかを疑問に思うことがよくあります。多くの場合、永続性のあるデータモデルに対する幻想は、とりあえずモデルが存在するという事実のみによって推定され、それが正しいかどうかは確認または検証されていないのです。 私は、データアーキテクチャーとデータベース設計の実務家として、あまりにも多くの粗悪なデータモデルを目にしてきたため、ほとんどのデータモデルには何らかの問題があると言わざるを得ません。その一方で優れたモデルも多く見てきましたが、それではデータモデルの良し悪しをどのように判断できるのでしょうか。それは重要なことなのか、データの出入りに問題がなければ十分ではないのか、と疑問に思われるかもしれません。しかし、データモデルの良し悪しは明らかに重要なのです。データモデルを基盤として/データモデルと協調して運営されるビジネスシステムを確実に成功させるためには、データモデル自体が優れたものである必要があります。データモデルはビジネスの本質です。したがって、包括的であり、非の打ちどころがなく、回復力のあるものでなければなりません。 このことから、優れたデータモデルを使用する動機は明らかです。Talend StudioのようなETL/ELTツールを使ってデータを出し入れし始めると、それが明らかになります(ほとんどの人には)。どのようなソフトウェアプロジェクトでも、データモデルは欠かすことのできない3つの技術的要素の1つです。ほかの2つの要素は、アプリケーションコードとユーザーインターフェイスです。 本シリーズの第1部では、私が設計するすべてのデータモデルで採用されているデータベース開発ライフサイクル(DDLC)の方法論を取り上げましたが、お読みいただいたでしょうか。この方法論は私にとって役立つものであり、データベース開発に本気で取り組んでいるすべてのチームはぜひとも採用すべきです。このプロセスを理解して採用することで、データモデルの実装と保守を合理化/自動化/改善できます。しかし、このプロセスについては、ほかの事柄も検討する必要あります。ビジネスに貢献する信頼性、柔軟性、正確性を備えたデータモデルを促進できる、追加のベストプラクティスをご紹介します。 データモデリングのベストプラクティス 多くのデータモデルは、モデラーが論理モデルを作成してから物理モデルを作成するプロセスによって設計されます。通常、論理モデルは実体と属性、および両者を結び付ける関係を記述して、データのビジネス目的を明確に表現します。続いて、物理モデルは論理モデルを実装します(論理モデルは、テーブル、列、データ型、索引として、簡潔なデータ整合性規則と共に実装されます)。これらの規則は、プライマリーキーと外部キー、およびデフォルト値を定義します。さらに、必要に応じて実装をサポートするために、ビュー、トリガー、ストアドプロシージャーが定義されることがあります。物理モデルは、ほとんどのホストシステム(Oracle、MS SQL Server、MySQLなど)が提供する特定の構成オプションに基づいて、ディスク上のストレージ割り当ても定義します。 納得できることですね。それにもかかわらず、私は論理モデルと概念モデルの違いをめぐる激しい議論を何度も経験してきました。多くの人は、これら2つは同じであり、どちらもビジネスデータの実体と属性を提示するものであると言います。私も同意見です!概念モデルは、データに対するビジネス上の理解(技術的な理解ではありません)についてコンテキストを提供することを目的とします。概念モデルはすべてのステークホルダーが理解できるものであり、多くの人が実体と属性に取り組んでいます。適切な概念モデルは、すべての関係者にとってビジネスデータのコミュニケーションのために最善のツールになります。統一モデリング言語(UML)の側面を使用することで、概念モデルを図解して、細かい事柄にとらわれずにシンプルに保持できます。詳細は論理モデルと物理モデルで不可欠ですが、それぞれで洗練させればよいでしょう。 一般的に多くのアプリケーションシステムを使用しているエンタープライズビジネスでは、データのモデル化で高次の懸念が生じます。概念モデル、論理モデル、物理モデルだけでは十分ではありません。そこで登場するのが、全体論的データモデル(少なくとも、私がそれを改造したモデル)です! 全体論的データモデルの目的は、企業全体でデータサイロを識別・抽象化することです。これにより、データサイロが存在する場所、必要な場所、相互に関連する場所、そして最も効果的に使用するために体系づける方法を大局的に説明します。 データモデリングプロセスの4つの階層 企業内に4タイプの異なるデータモデルが存在する可能性を考慮して、定義、理解の洗練化、および具体的な設計のために、「階層」としてトップダウン型で従うデータモデリングプロセスを次のように提案します。各レベルの主要な役割については、プロセスのどこで誰が関与したかを明確にします。 全体論的データモデル: 全体論的な層は、全社的なデータサイロの抽象的な環境を表します。このデータモデルは、広範なビジネスデータガバナンスを確立する機会を生み出し、それによって企業に固有のすべてのデータ関係に対する理解を深めることができます。それらのサイロは、社内外のアプリケーションからのデータを取り込むことを目的としています。バブルチャートを使用すると、全体論的データモデルを図解できます。以下のように設計します。 バブルチャート – データサイロ バブルチャートは、一意のデータサイロを表す単純なバブルで構成されます。2つ(2つだけ)のバブルを結ぶ線(「リンク」)は、2つの間に何らかの関係が存在することを示します。基本的には、バブルの各集合(多くの場合、放射状の「スポーク」を持つ中心の「ハブ」として示されます)は、企業全体で識別された特定のデータサイロのセットを具体化するものであり、それ以上でもそれ以下もありません。要素の詳細は以下のとおりです。 青色の実線で表されたリンクは、2つのデータサイロ間の直接的な関係を示します。赤色の破線で表されたリンクは、2つのデータサイロ間の間接的な関係を示します。緑色の点線で表されたリンクは、2つのデータサイロ間の拡張された関係を示します。これらのリンクは、複数の関係(概念層で定義)を表すことがあるため、主観的に使用します。単に関係が存在すると定義します。 バブルの周囲を、より大きいバブルが囲むことがあります。大きい方のバブルは、そのデータサイロに固有の分類を体系化するオントロジーが存在する(または存在すべきである)ことを意味します。オントロジーとその分類メタデータは、それが囲むサイロへの有意義なマッピングを提供します。これは、データを高度に検索可能にするのに大いに役立つものであり、この層で識別されるべきです。 バブルチャートは、ビジネス情報の特定の集合を定義します。その目的は、サポート対象のアプリケーション、実装または技術的詳細がない情報を識別、単純化、統合することです。全体論的データモデルのメリットは、すべてのオーディエンスが単一の包括的かつ単純化されたビューで企業データ環境を理解でき、基盤となるデータモデルをほとんど/まったく中断することなく新しいデータを識別してモデルに挿入する(後述)ための柔軟な出発点を提供できることです。 ここに示したのは、完全に定義された全体論的データモデルの図解の一例です。プリンターで大きく印刷して壁に貼り、皆で検討することで、活発で生産的な会話が生まれ、それがビジネスにとって効果的で価値ある資産になります。 概念データモデル: 概念層は、ビジネスデータ要素とそれらの関係の抽象的な定義を表します。このデータモデルは、アプリケーションの観点から企業データ環境のセマンティクスを定義し、これによって基盤となるビジネス情報の理解が深まります。UMLは、このモデルを設計するためのグラフィカルな手段となります。要素オブジェクトから成る概念データモデルは、全体論的モデルのデータサイロから抽出された情報クラスを定義します。基本的には、これを情報モデルと考えることができます。以下のように設計します。 UML情報アーキテクチャー 各要素オブジェクトは、データサイロの特定部分と、2つ(やはり2つだけ)の要素間の関係を定義する接続線(「リンク」)をカプセル化します。特定の要素項目(「特性」)は、オブジェクトの理解と目的をさらに支援するために定義され、以下のいずれかになります。 保護(値は事前に決定) パブリック(値は可変) プライベート(値の使用が制限) 直接的に相互接続された要素オブジェクトは、グレーの実線のリンクと意図的なラベルによって示される「関連付け」を持つと見なされます。これらの関連付けは、親要素に付けられた菱形により、次のいずれかの関係を表します。 単純(菱形なし) 共有(塗りつぶしのない菱形) 複合(塗りつぶされた菱形) 子要素が「ナビゲート可能」な場合は、矢印と関係基数(0.* = ゼロから多数、など)で示されます。 要素オブジェクトは、「一般化」を持つこともできます。つまり、オブジェクトのインスタンスは、特定または一意の特性や関係を持つことができます。この例では、オブジェクトは1つの親要素のサブクラスに似ており、親のすべての特性に加えて、関連する一意の特性をすべて追加的に含みます。サブクラス要素は、その名前と表現の両方で洗練化されることで、抽象化された全体論的データサイロの理解しやすい洗練化を提供します。要素オブジェクトに結合する一般化は、親オブジェクトに閉じた矢印が付いた青色の実線のリンクで示され、ラベルは不要です。 …
Read Article
先日Talendに入社したカスタマーサクセスアーキテクトのSundaramです。Talendによるデータ戦略を管理するためのアーキテクチャーのガイドラインとベストプラクティスをお客様に提供しています。Talendに入社する前にデータウェアハウスの実装を何件か担ったことがありましたが、そのような場合にはETLツールとしてInformatica PowerCenterが一般的に採用されていました。あるテクノロジーから別のテクノロジーへの移行は、大きな課題となることがあります。しかし、PowerCenterでのやり方をTalendにそのまま「複製」するのではなく、一歩引いて、Talendの仕組みや機能、PowerCenterとの違いを理解することが重要です。このブログでは、Informaticaから移行して先端的な統合プラットフォームを導入した経験をご紹介し、皆さんがInformaticaからTalendに移行する際の作業を最小限に抑えるうえでの参考にしていただきたいと思います。 Talend vs. Informatica PowerCenter:両者の違いについて どちらのツールも本質的にはデータをソースからターゲットに移行するという同じ機能を果たしますが、その実現方法が異なっています。それぞれの方法にはそれぞれのメリットがあります。ETLジョブを設計する前に、これらの方法の長所と短所を理解することが重要です。 まず、どちらのツールもグラフィカルユーザーインターフェイスを提供し、ソースからデータを抽出してトランスフォーメーションを行い、ターゲットにロードしますが、実装が異なることを理解する必要があります。TalendはネイティブJavaコードを生成するので、どこでも実行できます。一方、PowerCenterは、Informatica独自のエンジンが実行に使用するメタデータを生成してRDBMSリポジトリに格納します。 Talendがコードジェネレーターであることを理解しておくことが重要です。つまり、ETL(独自のスタンドアロンサーバーで実行)エンジンとしても、ELT(ターゲットサーバーでネイティブに実行)エンジンとして実行できます。Talendによって生成されたJavaコードは、Javaをサポートするプラットフォームであれば、どこでも(データセンターのサーバーでも、クラウド上でも、またはラップトップ上でも)実行できます。どちらのプラットフォームもデータ統合に必要なタスクの大半を処理するコンポーネントを提供していますが、カスタマイズが必要な場合もあります。そのためにカスタムコーディングが行われますが、このプロセスがPowerCenterを使用する際のやっかいで非効率的な点です。一方、Talend Open Studioの場合はお客様独自のカスタムコンポーネントをJavaで構築し、面倒なく統合できます。これらが、データ統合ジョブを設計する際に重要となる考慮事項です。 ダウンロード >> Talend Open Studio for Data Integration ジョブの設計方法 ジョブの構築方法が異なる点も重要です。PowerCenterの場合は、まずマッピング(本質的には「データフロー」)を開発します。この段階で、ソースとターゲットの間のマッピングとトランスフォーメーションロジックが定義されます。マッピングが検証され、そのメタデータがリポジトリに保存されると、セッションとワークフロー(「プロセスフロー」)が作成されます。その後、ソースとターゲットのオブジェクトへの物理接続が割り当てられ、タスクが実行順に並べ替えられ、エラー処理/通知手順が実装されます。 Talendでは、データフローとプロセスフローの両方がシームレスに実装されます。「データフロー」を実装する特定機能を提供するさまざまなコンポーネントを使用して、「プロセスフロー」を定義するジョブを構築します。「プロセスフロー」は、特定のスキーマに基づく「行」を使用するコンポーネント間の「トリガー」と「データフロー」を使用して実装されます。 理解しやすいように、PowerCenterとTalendの概念を対応させて説明します。 Informatica PowerCenter Talend Studio 説明 リポジトリ プロジェクトリポジトリ PowerCenterリポジトリとTalendプロジェクトリポジトリには、再利用可能なメタデータオブジェクト(ジョブ、DB接続、スキーマ定義など)が含まれます。Talendの場合は、独自のソースコード管理システムを使用するのではなく、SVNまたはGITのソースコード管理システムにシームレスに統合されます。 フォルダー フォルダー フォルダーは、機能に基づいてオブジェクトを整理するのに役立ちます。PowerCenterの場合はサブフォルダが許可されませんが、Talendでは許可されます。 ワークフロー ジョブ ワークフロー/ジョブは、すべての接続と依存関係が定義されたETLプロセスフローを実装します。Talendの場合、ジョブはプロセスフローとデータフローの両方を表します。 ワークレット/再利用可能セッション ジョブレット ワークフロー/ジョブで再利用可能な一連のタスクの組み合わせです。エラー処理、通知、繰り返し可能プロセスなどの再利用可能コードに使用できます。 セッションとマッピング コンポーネント PowerCenterでは、接続、ファイルの場所、エラー処理がセッションで個別に定義されます。一方Talendでは、マッピングとセッションの機能が結合され、コンポーネントまたはプロセス/データフローによりリンクされたコンポーネントセットに実装されます。 トランスフォーメーション コンポーネント Talendにはコンポーネントの大規模ライブラリーがあり、これがさまざまなトランスフォーメーションをサポートします。たとえば、頻繁に使用されるコンポーネントのtMapは、Informaticaの式、ルックアップ、ルーター、ジョイナーのトランスフォーメーションを組み合わせたものとなります。 ソースとターゲット …
Read Article
ビジネスアプリケーション、データ統合、マスターデータ管理、データウェアハウジング、ビッグデータデータレイク、機械学習といったものは、いずれもデータモデルが共通の基本的要素となります(または、そうあるべきです)。この点を常に念頭に置きましょう。あるいは、(よく見られることですが)完全に無視することがないように注意してください。 データモデルこそが、Eコマースから、PoS、財務、製品、顧客管理、ビジネスインテリジェンス、IoTまで、Talendの高価値でミッションクリティカルのビジネスソリューションのほとんどすべての支柱です。適切なデータモデルがなければ、ビジネスデータはおそらく失われてしまうでしょう! Talendのジョブ設計パターンとベストプラクティスについて取り上げたブログシリーズ(第1部、第2部、第3部、第4部)では、32のベストプラクティスを紹介し、Talendでジョブを構築する最善の方法について述べました。その中で予告したデータモデリングについて、以下に述べたいと思います。 データモデルとデータモデリングの方法論は、ずっと以前(コンピューティングが始まった頃)からありました。構造は、データが意味を成すために必要であり、コンピューターが実際に処理するうえでの一手段を提供します。確かに、今日では非構造化データや半構造化データも処理されるようになっています。しかし、それは単に、一層洗練された規範へとデータ処理が進化したことを意味するだけではないでしょうか。したがって、データモデルの意義は現在も変わるものではなく、高度なビジネスアプリケーションを構築するための基盤となっています。Talendのベストプラクティスと同様、データモデルとデータモデリングの手法にも真剣に向き合う必要があります。 ダウンロード >> Talend Open Studio for Data Integration 新たな洞察を得るべく、データモデリングの歴史を振り返ってみましょう。 データモデルの進化 「コンピューティングの暗黒時代」には、フラットなレコードのレイアウト(配列)が使用され、すべてのデータは後で取得できるようにテープや大規模ディスクドライブに保存されていました。しかし、1958年に、J. W. YoungとH. K. Kentが、情報システムのモデリングは「データ処理の問題の情報的かつ時間的特徴を規定するための正確で抽象的な方法」であると論じました。その後すぐに(1959年)、CODASYL(Conference/Committee on Data Systems Languages)というコンソーシアムがミネソタ大学のチャールズ・バベッジ研究所により結成されました。これを契機として、COBOLのような標準プログラミング言語が作成され、1960年代にはGE/Honeywell社でIntegrated Data Store(IDS)という初期のデータベーステクノロジーがチャールズ・バックマンによって設計されました。IDSは使いにくいものであったため、Integrated Database Management System(IDMS)がB. F. Goodrich(米国のタイヤメーカーですが、当時は航空宇宙製造企業)により開発され、Cullinane Database Systemsにより販売されました(現在はComputer Associatesが所有)。これら2つのデータモデリングの方法論は、それぞれ「階層型データモデル」と「ネットワーク型データモデル」と呼ばれ、50年にわたってメインフレームコンピューティングで広く使用されてきました。現在でも使用しているケースがあります。 1960年代末、当時IBM社の社員だったエドガー・F・コッドは、クリス・J・デイト(『An Introduction to Database Systems』の著者)と協力し、自身の革新的なデータモデリング理論を確立して、1970年に「A Relational Model of Data for Large Shared Data Banks(大規模共有データバンクのデータ関係モデル)」という論文を発表しました。コッドは、ベンダーが方法論を正しく実装できるよう推進するため、1985に有名な「Twelve …
Read Article
ビッグデータの分野では、従来のデータウェアハウスをHadoop環境にオフロードすることが一般的です。一次使用向けの場合も、「コールドデータ」を保存するためだけの場合も、Talendは負担のないオフロードを実現します。 データアーキテクチャーを最適化しようとする多くの組織は、Hadoopをコールドデータに利用したり、アーカイブの維持のために使用したりしています。 Talendは、Hadoopのネイティブコード生成によってこのプロセスを容易にすることができます。 Talendはすでに、Sqoopを使用してこの手法をサポートするためのコネクターを事前に組み込んでいます。ここでは、Apache Sparkを使って同じ目的を達成する方法について説明します。 Download >> Talend Open Studio for Data Integration Apache Sparkは、大規模データ処理のための高速の汎用エンジンです。 このエンジンは、Hadoopディストリビューションのほとんどの最新バージョン(Cloudera、Hortonworks、MapR、AWS EMR等)で利用できます。Massively Parallel Processing(MPP)アーキテクチャー上に構築されているため、データフローを大規模に並列化してあらゆるエンタープライズワークロードを処理できます。 現在、データベースからHadoopにデータをオフロードする手段として最も高速で最も広く知られているのは、Sqoopを活用する方法です(SqoopはMapReduceプロセスの下でRDBMSからHadoopへのオフロードを実行します)。 ここでは、Sqoopを使用する場合と同じ目的を達成するために、SPARKをフレームワーク/エンディングとして使用する方法をご紹介します 最初に、Sparkを使用して1つのテーブルをOracleまたはMySQLからHadoopに移動する方法について解説します。ジョブが準備できたら、データベースサーバーからHadoopに移動するためにテーブルリストによって制御される汎用ジョブを作成するタスクを実行します。 わかりやすくするために、次の2つのシナリオで検討します。 SparkジョブからHDFSへテーブルをオフロードする 上記のジョブを自動化し、メタデータ駆動型の取り込みフレームワークに変換してテーブルリストを操作する SparkジョブからHDFSへテーブルをオフロードする このシナリオでは、Apache Sparkと次のような一般的なQueryステートメントを使用して、データベーステーブルから抽出したデータをHDFSに移動する非常に一般的なジョブを作成しています。 “SELECT concat_ws (‘” + context.FIELD_SEPARATOR + “‘,” + context.column_list + “) as my_data FROM my_table”. ) As my_data FROM my_table “. Context.FIELD_SEPARATOR …
Read Article
Guest blog post from The Digital Group. T/DG, stands for The Digital Group, has been working on Talend based data source integration for quite some time. The Digital Group recently launched 3RDi (Third Eye) Enterprise Search Discovery and Analytics Platform that utilizes capabilities of Talend for all …
Read Article
Remember our latest Step-by-Step blog post around the construction of a Job in Talend Open Studio (seen here)? Well, now we’ve taken some time to write another post around running, testing and debugging a job in Talend Open Studio to show you how easy it is to …
Read Article
My first blog post is on a topic which connects me to Talend in a special way – custom components. The open source nature and concept of custom components are a chance – especially for consultants/developers like me – to open spaces and make Talend a …
Read Article
Did you know a commercial airplane generates on average 500 GB of data per hour when flying? Taking into account the number of hours an airplane can fly per day and the flights operated on a daily basis, this creates huge volumes of data that need …
Read Article
Talend開発者が、経験が浅かろうが豊富であろうが共通して直面することが多いのが、「このジョブを記述する最善の方法は何か」という疑問です。 効率的で、読みやすく、記述しやすく、何よりも(ほとんどの場合)維持しやすいものであるべきなのは当然です。 また、Talend Studioという自由形式の「キャンバス」では、コンポーネント、リポジトリーオブジェクト、メタデータ、及びリンケージオプションの包括的で多彩なパレットを使用してコードを「描画」できることもわかります。 では、ベストプラクティスを使用してジョブ設計を作成したことを、どのように確認したらよいのでしょうか。 ジョブ設計パターン Talendを使い始めたバージョン3.4以降、ジョブ設計は私にとって非常に重要でした。 最初は、ジョブの開発でパターンを考慮することはありませんでした。それ以前からMicrosoft SSIS等のツールを使用していたので、Talendのようなビジュアルエディターには馴染んでいました。 パターンに焦点を当てる代わりに、基本的な機能、コードの再利用性、次にキャンバスのレイアウト、そして最後に命名規則に注目していました。 しかし、さまざまなユースケース向けに数百のTalendジョブを開発し、コードがより洗練されて再利用性や一貫性も向上したことから、一定のパターンが浮かび上がってきました。 今年1月にTalendに入社して以来、顧客が開発したジョブを目にする機会に多く恵まれました。その結果、全ての開発者にとって、それぞれのユースケースに複数のソリューションがあるという認識に確信を持ちました。 このことが、開発者の多くにとっての問題となっているようです。 私たち開発者は同じような考え方をしますが、自分のやり方が特定のジョブを開発するうえで最善であると思い込みがちです。一方で、さらに良い方法が存在する可能性に薄々気が付いてもいます。 そこで、ベストプラクティスが必要となり、この場合はジョブ設計パターンを探すことになります。 基本的指針の明確化 可能な限り最善のジョブコードを実現するために必要なことを考えるときには、常に基本的指針が適用されます。この指針は、長年にわたるミスと成功に基づく改善の積み重ねから生まれたものです。 これはコード構築の強固な基盤となり、(私見ですが)ないがしろにしてはならない重要な原則であり、次の事柄が含まれます(順序は問いません)。 – 読み取りやすさ:簡単に把握し、理解できるコードを作成する – 記述しやすさ:最短期間に平易で単純なコードを作成する – 維持性:変更の影響を最小限に抑えて適度な複雑さを組み込む – 機能:要件を満たすコードを作成する – 再利用性:共有可能なオブジェクトと小さな作業単位を作成する – 整合性:チーム、プロジェクト、リポジトリー、コードにわたる実質的な規範を作成する – 柔軟性:曲げることはできても折れることのないコードを作成する – 拡張性:要求に応じてスループットを調整する弾力のあるモジュールを作成する – 一貫性:全てにわたる共通性を作り出す – 効率:最適化されたデータフローとコンポーネント利用を作り出す – 区画化:単一の目的に対応する、焦点を絞った小さなモジュールを作成する – 最適化:最小限のコードで最大限の機能を作り出す – パフォーマンス:最速のスループットを生む効果的なモジュールを作成する これらの指針全体で実質的なバランスをとることが重要です。特に最初の3項目は常に相反するため、調整が欠かせません。 2つの項目を満たして3つ目を犠牲してしまうことはよくあります。 できるだけ重要度に基づいて順序付けるようにします。 (基準ではなく)規範としてのガイドライン 実際にジョブ設計パターンの検討に入る前に、前述した基本的指針と併せて、考慮すべきいくつかの詳細事項について確認しておきましょう。 設定されている基準に想定外の状況に対処する余地がなく、融通が利かないために、支障が出ることがしばしばあります。 …
Read Article
In my last blog “What is ‘The Data Vault’ and why do we need it?” I introduced a fresh, compelling methodology for data warehouse modeling authored and invented by Dan Linstedt (http://danlinstedt.com) called ‘the Data Vault’. Solving the many characteristic and inherent problems found in crafting …
Read Article