InterSystems IRIS BI (DeepSee) は、トランザクションデータのリアルタイム分析を可能にするビジネスインテリジェンス（BI）テクノロジー製品であり、トランザクションアプリケーションへの組み込み用途に最適となるよう設計されています。
皆さん、こんにちは！
これから InterSystems 製品で開発を始める／未使用の機能を確認したい／運用保守を担当する など、担当される役割や学習目的に合わせた最適なラーニングパス（学習経路）を確認できるページを公開しました！
学習経路に沿った学習内容（数分の解説ビデオ、対象となる日本語ドキュメント、コミュニティ記事、セルフラーニングビデオ、体験環境付き演習（英語のみ）、オンラインラーニング（英語のみ）、講師付きトレーニングコース）を確認しながらご自身のペースで学習を進めていただくことができます。
以下、ページの使い方を簡単にご紹介します。下図のように、役割毎に各種パスが用意されています。
.png)
Pandas は単に人気のあるソフトウェアライブラリだけではありません。 これは、Python データ分析環境の基礎でもあります。 その単純さとパワーで知られており、データの準備と分析の複雑さをより扱いやすい形態に変換する上で不可欠な多様なデータ構造と関数が備わっています。 これは、主要なデータ管理および分析ソリューションである InterSystems IRIS プラットフォームのフレームワーク内で、主要評価指標（KPI）やレポート作成用の ObjectScript などの特殊な環境に特に関連しています。
データの処理と分析の分野において、Pandas はいくつかの理由により際立っています。 この記事では、それらの側面を詳細に探ります。
ここでは、Pandas を使用する様々なメリットについて深く掘り下げます。 直感的な構文、大規模なデータセットの効率的な処理、および異なるデータ形式のシームレスな操作などが含まれます。 Pandas を既存のデータ分析ワークフローに統合する容易さも、生産性と効率を強化する大きな要因です。
Pandas には、単純なデータ集計から複雑な変換まで、日常的なデータ分析タスクを処理できる十分な汎用性が備わっています。 こういった一般的な課題の解決に Pandas をどのように使用できるについて、データクリーニング、変換、および探索的データ分析における機能を紹介しながら説明します。 このセクションでは、Pandas によってこれらのタスクがどれほど単純化されるかに関する実用的なデータを提供します。
IRIS プラットフォームで KPI の開発に Pandas と ObjectScript を統合すると、まさに変革がもたらされます。 ここでは、直接 ObjectScript 内で Pandas を使用して KPI 開発プロセスを強化する方法を説明します。 また、Pandas を使ってデータの分析と可視化を行い、それによってより堅牢でインサイトに満ちた KPI を得る実用的な例も探ります。
既存の分析プロセスに新しいツールを実装するのは困難な場合があります。 そのため、このセクションでは、Pandas をできる限り円滑に IRIS 分析エコシステムに統合するためにベストプラクティスと推奨事項を紹介します。 セットアップと構成から最適化とベストプラクティスまで、データ分析ワークフローへの Pandas の統合を成功させるための基本的なガイドラインを説明します。
Pandas は、Python プログラミング言語による強力なデータ分析ライブラリです。 Pandas でデータ分析を行うことには、以下のようないくつかのメリットがあります。
ObjectScript 環境で Pandas の実装例を見てみましょう。 開発環境として VSCode を使用します。 この場合の IDE は、ObjectScript 用のデバッガーとエディターを提供する InterSystems ObjectScript Extension Pack の提供状況に基づいて選択されました。
まずは、KPI クラスを作成しましょう。
Class BI.KPI.pandasKpi Extends%DeepSee.KPI
{
}
次に、KPI のタイプ、名前、および列とフィルターの数を定義する XML ドキュメントを作成する必要があります。
XData KPI [ XMLNamespace = "http://www.intersystems.com/deepsee/kpi" ]
{
<!-- 'manual' KPI タイプは、ユーザーが定義したクラスメソッドからデータが収集されることを DeepSee に示します-->
<kpiname="MembersPandasDemo"sourceType="manual">
<!-- この KPI クエリに必要となる列は 1 つのみです -->
<propertycolumnNo="1"name="Members"displayName="Community Members"/>
<!-- 最後に、メンバーのフィルターを定義する必要があります -->
<filtername="InterSystemsMember"displayName="InterSystems member"sql="SELECT DISTINCT ISCMember from Community.Member"/>
</kpi>
}
次のステップは、Python 関数の定義、インポートの記述、および必要な変数の作成です。
ClassMethod MembersDF(sqlstring) As%Library.DynamicArray [ Language = python ]
{
# First of all, we import the most important library in our script: IRIS.
# IRIS library provides syntax for calling ObjectScript classes.
# It simplifies Python-ObjectScript integration.
# With the help of the library we can call any class and class method, and
# it returns whatever data type we like, and ObjectScript understands it.
import iris
# Then, of course, import the pandas itself.
import pandas as pd
# Create three empty arrays:
Id_list = []
time_list = []
ics_member = []
次のステップ: データベースに対するクエリを定義します。
# Define SQL query for fetching data.
# The query can be as simple as possible.
# All the work will be done by pandas:
query = """
SELECT
id as ID, CAST(TO_CHAR(Created, 'YYYYMM') as Int) as MonthYear, ISCMember as ISC
FROM Community.Member
order by Created DESC
"""
次に、生成されるデータを配列グループに保存する必要があります。
# Call the class specified for executing SQL statements.
# We use embedded Python library to call the class:
sql_class = iris.sql.prepare(query)
# We use it again to call dedicated class methods:
rs = sql_class.execute()
# Then we use pandas directly on the result set to make dataFrame:
data = rs.dataframe()
We also can pass an argument to filter our data frame.
# フィルターの例
# We take an argument sqlstring which, in this case, contains boolean data.
# With a handy function .loc filtering all the data
sqlstring が False でない場合:
data = data.loc[data["ISC"] == int(sqlstring)]
次に、データをグループ化して、その x 軸を定義する必要があります。
# Group data by date displayed like MonthYear:
grouped_data = data.groupby(["MonthYear"]).count()
残念ながら、直接グループ化されたデータ DataFrame から日付列を取得することはできないため、
代わりに元の DataFrame から日付列を取得して処理します。
# Filter out duplicate dates and append them to a list.
# After grouping by MonthYear, pandas automatically filters off duplicate dates.
# We should do the same to match our arrays:
sorted_filtered_dates = [item for item in set(data["MonthYear"])]
# Reverse the dates from left to right:
date = sorted(sorted_filtered_dates, reverse=True)
# Convert dict to a list:
id = grouped_data["ID"].id.tolist()
# Reverse values according to the date array:
id.reverse()
# In order to return the appropriate object to ObjectScript so that it understands it,
# we call '%Library.DynamicArray' (it is the closest one to python and an easy-to-use type of array).
# Again, we use IRIS library inside python code:
OBJIDList = iris.cls('%Library.DynamicArray')._New()
OBJtimeList = iris.cls('%Library.DynamicArray')._New()
# Append all data to DynamicArray class methods Push()
for i in date:
OBJtimeList._Push(i)
for i in ID:
OBJIDList._Push(i)
return OBJIDList, OBJtimeList
}
次のステップでは、DeepSee がどのデータを取得するかを理解するように KPI 固有のメソッドを定義します。
// メソッドを定義します。 The method must always be %OnLoadKPI(). Otherwise, the system will not recognise it.
Method %OnLoadKPI() As%Status
{
//Define string for the filter. Set the default to zero
set sqlstring = 0
//Call %filterValues method to fetch any filter data from the widget.
if$IsObject(..%filterValues) {
if (..%filterValues.InterSystemsMember'="")
{
set sqlstring=..%filterValues.%data("InterSystemsMember")
}
}
//Call pandas function, pass filter value if any, and receive dynamic arrays with data.
set sqlValue = ..MembersDF(sqlstring)
//Assign each tuple to a variable.
set idList = sqlValue.GetAt(1)
set timeList = sqlValue.GetAt(2)
//Calculate size of x-axis. It will be rows for our widget:
set rowCount = timeList.%Size()
//Since we need only one column, we assign variable to 1:
set colCount = 1
set ..%seriesCount=rowCount
//Now, for each row, assign time value and ID value of our members:
for rows = 1:1:..%seriesCount
{
set ..%seriesNames(rows)=timeList.%Get(rows-1)
for col = 1:1:colCount
{
set ..%data(rows,"Members")=idList.%Get(rows-1)
}
}
quit$$$OK
この時点で、KPI をコンパイルし、KPI データソースを使ってダッシュボードにウィジェットを作成します。
以上です！ InterSystems IRIS の ObjectScript アプリケーションで Pandas の統合と使用のプロセスを確認できました。 このプロセスでは、データのフェッチと整形から絞り込みと表示までを 1 つの合理化された関数で行いました。 この実演では、データ分析における Pandas の効率性と力がハイライトされています。 では次に、IRIS 環境内で Pandas を実装する際の実用的な推奨事項を詳しく見て、変換による影響に関するインサイトで締めくくりましょう。
IRIS における実用的な Pandas アプリケーションの推奨事項
サンプルのデータセットとユーティリティを使用して Pandas での作業を始めましょう。 この方法によって、制御された使い慣れた環境で Pandas の基本と意味合いを理解できます。 プロトタイピングでは、ライブデータに関連するリスクを伴うことなく、様々な Pandas 関数とメソッドを実験できます。
既存のデータプロセスに Pandas を徐々に導入しましょう。 全面的に変更するのではなく、Pandas によってデータ処理と分析が強化または単純化されるエリアを特定します。 データクリーニング集計などの単純なタスクであることも、Pandas の機能を完全に活用できるより複雑な分析であることもあります。
大きなデータセットで作業する前に、Pandas コードを最適化しておくことが重要です。 コードの効率によって、処理時間やリソース消費量が大幅に削減されるため、大規模なデータ分析では特に重要です。 ベクトル化操作、適切なデータ型の使用、データ操作でのループの回避といった手法によって、パフォーマンスは大幅に強化されます。
まとめ
InterSystems IRIS プラットフォームの ObjectScript アプリケーションへの Pandas の統合は、データ分析の分野における著しい進歩です。 Pandas によってデータ処理、分析、および可視化に使用できる多数の強力なツールを使用できるようになり、IRIS ユーザーはこれを使用できるようになりました。 この統合は KPI の開発と分析を高速化して単純化するだけでなく、IRIS エコシステム内でのより洗練された高度なデータ分析機能への道も切り開いています。
Pandas を使用することで、アナリストと開発者は、その広範な機能を活用してデータからより深い洞察を得ることで、データ分析の新たな地平を探ることができます。 大規模なデータセットを効率的に処理して分析する能力に、魅力的な可視化の作成しやすさを合わせ、ユーザーはより多くの情報に基づいた意思決定を行い、これまで検出が困難であった傾向やパターンを明らかにできるようになります。
要約すると、InterSystems IRIS 環境への Pandas の統合は変革的なステップであり、プラットフォームの機能を強化し、増え続ける最新のデータ分析の課題と複雑さに取り組むための拡張されたツールキットをユーザーに提供することができます。
IRIS BIチュートリアル試してみたシリーズの11回目です。ついに今回が最終回になります。
最終回のトピックは「ピボット・テーブルおよびダッシュボードのエクスポートとパッケージ化」です。これまでに作成したピボットテーブルやダッシュボードをエクスポートして他の環境などに移送するためのテクニックを学びます。
では、早速はじめていきましょう。
IRIS BIチュートリアル試してみたシリーズの10回目です。
今回はチュートリアル最後のページ「ピボット・テーブルおよびダッシュボードの作成とパッケージ化」についてです。
これまでアーキテクトとアナライザを使用してきましたが、今回はユーザポータル画面を使ってダッシュボードを作成していきます。
では、早速はじめていきましょう。
IRIS BIチュートリアル試してみたシリーズの9回目です。
今回は、チュートリアル全6ページのうちの5ページ目、「サブジェクト領域の作成」について試していきます。
「サブジェクト領域」という新しい概念が出てきますが、どんなものかを触りながら理解していきます。
では、早速はじめていきましょう。
IRIS BIチュートリアル試してみたシリーズの8回目です。このシリーズもだいぶ長くなってきました。
今回も、前回に引き続きチュートリアルの「キューブ定義の拡張」ページの内容です。
最後に残った2つのトピックについて進めていきます。では、はじめていきましょう。
タイトルには「置換」とありますが、ディメンジョンのレベルを集約した新しいレベルを作成する方法、と理解していただくのがよいかもしれません。
2回目の記事でちょっとだけ触れた Age Group と Age Bucket レベルを作成していきます。
まず Age Group レベルを作成します。こちらは以下のような3つのグルーピングになります。
IRIS BIチュートリアル試してみたシリーズの7回目です。
今回も、「キューブ定義の拡張」ページのトピックになります。では、早速はじめていきましょう。
IRIS BIチュートリアル試してみたシリーズの6回目です。
今回からは、全6ページのうちの4ページ目「キューブ定義の拡張」に入っていきます。
前回まではメジャーやディメンジョンなど、基本的なキューブの構成要素を作成しましたが、さらにキューブを使いやすくするための機能について学んでいきます。
では、早速はじめましょう。
IRIS BIチュートリアル試してみたシリーズの5回目です。
今回も、前回同様チュートリアルの「キューブの作成」ページになります。
前回はキューブを作成し、そのキューブを使用していくつかのピボットテーブルを作成しました。
その中で気になった点を今回は修正していきます。では、はじめていきましょう。
前回の作業の中で、ピボットテーブル作成時に気になった点は以下のものがありました。
では、これらを解消していきましょう。アーキテクト画面で Tutorial キューブを開きます。
キューブが開いたら、 Age レベルをクリックし、続いて [要素を追加] をクリックします。
要素名に AgeSort と入力し、要素選択は プロパティ を指定します。
AgeSort プロパティができました。
では、AgeSort プロパティの詳細設定を変えます。詳細ペインの [表現] に以下の式を設定します。
$CASE($LENGTH(%source.Age),2:%source.Age,:"0"_%source.Age)IRIS BIチュートリアル試してみたシリーズの4回目です。
今回からはチュートリアルの3ページ目、「キューブの作成」に沿って進めていきます。
では、早速はじめていきたいと思います。
キューブの作成はアーキテクト画面から行います。
管理ポータル画面のメニューで、 Analytics → アーキテクト を選択します。
アーキテクト画面が開きました。1回目の記事の作業のときに Patientsキューブを開いたので、私の環境では再びPatientsキューブが表示されました。
新しいキューブを作成しますので、[新規] ボタンをクリックします。
ダイアログが開いたら、以下のように指定していきます。
IRIS BIチュートリアル試してみたシリーズの3回目です。
チュートリアルの「キューブ要素の概要」ページの続きを行います。
前回同様、アナライザを操作しながらキューブの要素について説明していきます。
では、早速はじめていきましょう。
IRIS BIチュートリアル試してみたシリーズの2回目です。
今回は、前回の作業でセットアップしたサンプルキューブやデータを用いてアナライザを操作します。
アナライザは、IRIS BIのキューブ等を基にピボットテーブルを作成する機能です。Excelのピボットテーブルをご存知でしたらイメージがつきやすいかもしれません。
では、早速はじめていきたいと思います。
まずはアナライザ画面を開きます。管理ポータル画面のメニューから、 Analytics → アナライザ を選択します。
以下のような画面が表示されます。アナライザ画面は大きく3つの領域から成り立っています。
開発者コミュニティのみなさん、こんにちは。
IRISには組み込みのビジネスインテリジェンス機能であるIRIS BIが備わっております。
ただし、使い方がよく分からないということから利用に至ってない方もいらっしゃるのではないでしょうか。
幸いなことに、オンラインドキュメントの中にはIRIS BIの開発者向けチュートリアルのページがあり、それに沿って作業するとIRIS BIの簡単な概要を理解することができます。
ですので、これから数回に分けてチュートリアルを実行した結果を紹介し、IRIS BIの機能や使い方について知っていただければと思います。
初回は、チュートリアル用のネームスペースにサンプルのデータやキューブなどを作成する準備作業について説明します。
なお、使用した環境ですが、Windows PC(OS: Windows 10)にIRIS 2024.1のコミュニティエディション(コンテナ版)で行っております。
DeepSee で階層を設計する場合、子メンバーに 1 つの親しか指定できません。 子が 2 つの親に対応する場合には、信頼性のない結果が得られることになります。 類似する 2 つのメンバーが存在する場合、そのキーがそれぞれ一意になるように変更する必要があります。 これが起きる場合とそれを回避する方法について、2 つの例を見ながら説明します。
（アメリカには）Boston と言う都市がある州がたくさんあります。 私のサンプルデータでは、Boston, MA（マサチューセッツ州ボストン）と Boston, NY（ニューヨーク州ボストン）のレコードがあります。 次元は次のように定義されています。
私の場合、City（都市）と State（州）は単純な文字列です。 キューブにビルドすると、"MA" と "NY" の2 つの州メンバー、"Boston" と "Boston" の 2 つの都市メンバーが得られます。 Boston が 1 つではなく 2 つあるのはなぜでしょうか。 メンバーには 2 つの親メンバーを指定できないため、親ごとに異なるメンバーを作成する必要があります。 残念ながら、1 つのキーが 2 つの異なるメンバーを持っているため、この時点で「不適切な階層」状態になっています。
これを修正するには、キーを一意にしなければなりません。 "City" プロパティをレベルのソースプロパティとして直接使用する代わりに、ソース式を使うとこのメンバーを一意にすることができます。
こうすることで問題は解決されますが、望ましくない副作用が発生する可能性があります。 この式では、ピボットテーブルで以下のような結果になります。
これは表示フォーマットとして適切な場合も、適切でない場合もあります。 この時点ではキーとメンバー名が同じであるため、もう少し手を加えれば "Boston" だけが表示されるようにできますが、その後ろに一意のキーがあります。 詳細は、ドキュメントをご覧ください。
まとめると、異なるメンバーには一意のキーが必要です。 特定のキーを持つ子メンバーに、同じキーを持つ既存の子メンバーとは異なる親メンバーがある場合、そのキーは再利用されますが、新しいメンバーが生成されます。 このため、階層が無効になります。
無効な階層は日付階層によく見られます。 自然と以下の階層を作成する傾向にあります:
Year
Month
Week
Day
*** ここでは、具体的に DeepSee における Year、MonthYear、WeekYear、および DayMonthYear 抽出関数について言及しています。
知っての通り、Week は 2 つの月、さらには 2 つの年に含まれる場合があります。 ここでの他のすべてのレベル（Year、Month、Day）はどれも親に適合し、2 つの親に含まれることはありません。 このように Week メンバーで定義された階層がある場合、DeepSee エンジンがツリーをトラバースする方法（Jan 3 2020 から December 2019 の Week 52 2019 まで。 ただし Jan 3 2020 は December 2019 の子ではないため、エンジンはこれらの結果を削除する可能性があります）が原因で予期しない結果となる可能性があります。
一般的な解決策は、Week メンバーのみの階層を新たに作成することです。 こうすることで、元の階層の整合性を保持しながら、クエリ内で Week を使用することができます。
DeepSeeButtons on Open Exchange には、生成レポート内にこれらの条件をチェックして、階層が無効であるかを通知するセクションがあります。
*** InterSystems IRIS 2020.3 以降では、DeepSeeButtons は製品に含まれています。 追加情報は、ドキュメント をご覧ください***
コミュニティの皆さん、こんにちは！
DeepSee Web についてのパート 2 では、DSW のカスタマイズオプションについて説明します。
カスタマイズには、ウィジェットのカスタマイズとダッシュボードパネルのカスタマイズの 2 種類があります。
開発者コミュニティ分析におけるダッシュボードのカスタマイズ例。
ウィジェットのカスタマイズ
DSW の各グラフウィジェットは、凡例、凡例要素、値、上位/全部の切り替えの要素によって調整することができます。
調整パネルは、グラフウィジェットの右上にあります。
ではその仕組みを見てみましょう。
凡例
小文字の「i」は凡例の切り替えを表します。 クリックすると凡例が表示/非表示になります。 また、凡例の特定の要素を表示/非表示にすることもできます。
上位行フィルタ
星ボタンは、上位/全部の切り替えボタンで、ピボットの最初の測定の上位 20 件フィルターを素早くオン/オフにできます。
値の切り替え
「V」は <s>vendetta</s> 値です。 クリックすると、行の値が表示/非表示になります。
ウィジェットのレイアウト
DSW は最初に DeepSee ダッシュボードリソースからウィジェットレイアウトを取得して、DSW 設定の列カウント（デフォルトは 12）とウィジェットの最小高さ（100）に合わせて拡大縮小されます。
ウィジェットのレイアウトは好みに合わせて移動して設定できます。 フィルタコントロールを配置する必要がある場合などには特に便利です（フィルタコントロールは、ウィジェットの代わりにダッシュボードにフィルタが配置される場合に自動的に表示されます）。
ダッシュボードパネルのカスタマイズ
DSW では、ダッシュボードパネルとタイル/カバーの外観をカスタマイズできます。
以下は、DeepSee ダッシュボードのクラシックパネルビューです。
DSW では、ダッシュボードパネルビューを 3 つの方法でカスタマイズできます（カスタマイズは設定で変更できます）。
Show images（画像を表示）をオンにすると、DeepSee の画像がダッシュボードカバーに表示されます。
すると、ダッシュボードパネルに画像が表示されます。
Show folders（フォルダを表示）を選択すると、同じダッシュボードパネルがフォルダで編成されます。
また、ダッシュボードカバーの色やサイズを調整し、対話型にすることができます。
ダッシュボードパネルの右下からタイルエディターを開きます。
カスタマイズのデプロイ
デプロイについてはどうでしょうか。 設定やカスタマイズを開発からプロダクションソリューションに配布するには？
これを行うには、Settings（設定）メニューで現在のカスタマイズをエクスポートできます。
すべての設定が settings.json ファイルにエクスポートされるため、ターゲットプロダクションサーバーにデプロイすることができます。 DSW は、設定が含まれるファイルを /csp/dsw/configs/namespace.json ファイルで探します。
例: これは samples.json ファイルです。これを DSW インストールの /csp/dsw/config/samples.json に配置すれば、DSW がこのネームスペースのダッシュボードの設定を自動的に読み込むようになります。
尽きることのないカスタマイズ
デザイン、設定、調整などを行えるすべてのケースにおいて、カスタマイズが完成することは決してありません。 そのため、この分野において他の機能をご希望の場合は、課題をお送りいただくか、この機能を実装してプルリクエストをお送りください。
DSW の機能についてはさらに記事が追加されます。 パート 1 を読んで、今後の更新にご期待ください！
DeepSee BI ソリューションのユーザーインターフェース（UI）を配布するにはいくつかのオプションがあります。 最も一般的には以下の手法があります。
最初の手法はコーディングを行わずに比較的素早く BI ダッシュボードを構築できるためお勧めですが、事前設定のウィジェットライブラリに限られます。これを拡張することはできますが、大きな開発の手間がかかります。
2 つ目の手法には、任意の総合 js フレームワーク（D3，Highcharts など）を使用して DeepSee データを可視化する手段がありますが、ウィジェットとダッシュボードを独自にコーディングする必要があります。
今日は、上の 2 つを組み合わせて Angular ベースの DeepSee ダッシュボード用 Web UI を提供するもう 1 つの手法をご紹介します。DeepSee Web ライブラリです。
詳しい説明
DeepSee Web（DSW）は、DeepSee ダッシュボードを表示する Angular.js Web アプリで、Highcharts.js、OpenStreetMap、および一部の自作 js ウィジェットを使用する特定のネームスペースで使用できます。
仕組み
DSW は、MDX2JSON ライブラリを使用するネームスペースで使用できるダッシュボードとウィジェットのメタデータをリクエストします。 ダッシュボードを可視化するために、DSW はウィジェットとそのタイプのリストを読み取り、ほぼすべての DeepSee ウィジェットに実装されている js-widget アナログを使用します。 ダッシュボードにリストされる js ウィジェットをインスタンス化し、DeepSee REST API と MDX2JSON を使用してウィジェットのデータソースに従ってデータをリクエストし、JSON 形式でデータを取得して可視化を実行します。
そのメリットは？
DSW は以下の理由により優れています。
モバイルデバイスは？
DSW は、モバイルブラウザ（Safari、Chrome）で非常によく動作し、スタンドアロンの DeepSight iOS アプリもあります。以下はそのスクリーンショットです。
いくらですか？
無料です。 最新リリースのダウンロード、課題の送信、フォークの作成、修正や新機能を含むプルリクエストを自由に行えます。
プロダクションでの使用に適していますか？
はい。 DSW は 2014 年にリリースされ、今日まで 60 回リリースされてきました。 DSW は数十社の DeepSee ソリューションで正常に使用されています。
たとえば、開発者コミュニティでも DSW を使用しています。
ただし、DSW ライセンス（MIT ライセンス）に従い、ご自身のリスクで使用していただきます。
サポートされていますか？
コミュニティによってサポートされています。 ぜひ課題を開き、フォークを作成して、修正と新機能が含まれるプルリクエストを送信してください。
主要貢献者は [@Anton Gnibeda]、[@Nikita Savchenko]、[@Eduard Lebedyuk] です。
インストール方法は？
簡単です。 まず、MDX2JSON をインストールします。 リリースから最新のインストーラーをダウンロードして、USER ネームスペースで installer.xml をインポート/コンパイルし、以下を実行します。
USER> D ##class(MDX2JSON.Installer).setup()GitHub から最新のリリースがダウンロードされ、MDX2JSON データベースとネームスペースの作成と %All へのマッピングが行われ、/MDX2JSON Web アプリが作成されます。
すべてがうまくインストールされたことを確認するには、localhost:57772/MDX2JSON/Test を開きます。 すべてが正常である場合は、以下のように返されます。
{
"DefaultApp":"\/dsw",
"Mappings": {
"Mapped":["%SYS","MDX2JSON","SAMPLES","USER"
],
"Unmapped":["DOCBOOK"
]
},
"Parent":"18872dc518d8009bdc105425f541953d2c9d461e",
"ParentTS":"2017-05-26 16:20:17.307",
"Status":"OK",
"User":"",
"Version":2.2
}
次に DSW をインストールします。 最新の release xml をダウンロードします。
それを USER ネームスペースにインポート/コンパイルします。 以下を実行してください。
USER> Do ##class(DSW.Installer).setup()/dsw アプリが作成され、すべての js ファイルが /csp/dsw フォルダにインストールされます。
localhost:57772/dsw/index.html#!/?ns=SAMPLES を開き、動作することを確認してください。
既知の問題:
一部のシステムでは、CSP ゲートウェイで CSP 以外のファイルに UTF8 サポートを設定する必要があります。 ターミナルで以下を実行してオンにしてください。
USER> set ^%SYS("CSP","DefaultFileCharset")="utf-8"
いつインストールすべきですか？
今すぐインストールしましょう！ )
続きにご期待ください！
以下は、InterSystems IRIS で使用するデータベース、ネームスペース、および Web アプリケーションを作成できる ObjectScript スニペットです。
set currentNS = $namespace
zn "%SYS"
write "Create DB ...",!
set dbName="testDB"
set dbProperties("Directory") = "/InterSystems/IRIS/mgr/testDB"
set status=##Class(Config.Databases).Create(dbName,.dbProperties)
write:'status $system.Status.DisplayError(status)
write "DB """_dbName_""" was created!",!!
write "Create namespace ...",!
set nsName="testNS"
//グローバルの DB
set nsProperties("Globals") = dbName
//ルーチンの DB
set nsProperties("Routines") = dbName
set status=##Class(Config.Namespaces).Create(nsName,.nsProperties)
write:'status $system.Status.DisplayError(status)
write "Namespace """_nsName_""" was created!",!!
write "Create web application ...",!
set webName = "/csp/testApplication"
set webProperties("NameSpace") = nsName
set webProperties("Enabled") = $$$YES
set webProperties("IsNameSpaceDefault") = $$$YES
set webProperties("CSPZENEnabled") = $$$YES
set webProperties("DeepSeeEnabled") = $$$YES
set webProperties("AutheEnabled") = $$$AutheCache
set status = ##class(Security.Applications).Create(webName, .webProperties)
write:'status $system.Status.DisplayError(status)
write "Web application """webName""" was created!",!
zn currentNS
以下のマニュアルもご覧ください。
この「DeepSee トラブルシューティングガイド」は、DeepSee プロジェクトの問題を追跡して修正する支援を提供することを目的としています。
このガイドラインに従って問題を修正できない場合でも、少なくとも DeepSee サポートに WRC の問題を提出し、すべての証拠を提供するのに十分な情報を得ることができます。この情報によって、一緒に調査を続け、より迅速に解決することが可能となります。
ご注意ください: 特定のアクションやコマンドによってどのような結果がもたらされるかがよくわからない場合は、実行しないでください。本番システムに影響を与える可能性があります。 この場合は、サポートセンターにお問い合わせください。
左から右の操作列に進むと、このガイドを最も簡単に活用できます。
| 問題の領域 |
|---|
| ビルドの問題 |
|
ソーステーブルの行 よりも少ないレコー ドが構築される |
| maxfacts が使用されているかを確認 |
| ^DeepSee.BuildErrors/ run ##class(%DeepSee.Utils).%PrintBuildErrors(pCube) を確認 |
| ソースクラスのインデックスを確認 |
| データの欠落 |
| キューブ定義の "%OnProcessFact" を確認します |
| ビルドエラーを確認します |
| sourceExpression のメソッドをデバッグします |
| ファクトテーブルのレコードを確認します |
| ファクトテーブルとソーステーブルを比較します |
| 結果が誤っている |
|
クエリで予期しない 結果が表示される |
|
クエリをより小さなセグメントに分割 （各軸を個別に分割） 問題のあるセグメントを特定 |
| ^DeepSee.AgentLog を確認します |
| リストが空 |
| カスタム SQL リストかを確認します |
| ハング / 予期しないイベント |
| ハング |
| ライセンスの使用状況を確認 |
| 以前に動作していた操作が失敗する |
| do ##class(%DeepSee.TaskMaster).%PrintLog() を実行 |
|
^DeepSee.LastLogError を確認 ^DeepSee.PivotError() を確認 |
| パフォーマンスの問題 |
| 利用できるエージェント数を確認 |
| メモリと CPU の使用率を確認 |
| ソースの式を確認 |
| 全般的なキューブの状態を確認 |
| - do ##class(%DeepSee.Utils).%Analyze("Holefoods") |
| 高いジャーナリングアクティビティ |
| クエリパフォーマンスが低い |
| メモリと CPU の使用率を確認 |
| バッファの設定を確認 |
| 一般的なシステムパフォーマンス分析を実施 |
| 報告済みの一般的な問題 |
| アーキテクトがグレー表示される |
| ユーザーのロールを確認 |
| ブラウザが IE 8 でないことを確認 |
以下は、各問題領域のマインドマップです。
AtScale に接続するために、SQL Server Analysis Services データベースを使用します。 Power Query エディターで開いてみましょう。 これを行うには、 Home から Transform Data を選択します。
表示されたウィンドウで、Home を選択し、New Source を展開して Analysis Services を選択します。
Server 行に、AtScale に公開されたプロジェクトへの MDX リンクを指定する必要があります。 必要に応じて、Database 行にプロジェクトの名前をすぐに指定することもできます。
次に、Basic タイプの認証を選択し、AtScale のログイン/パスワードを指定します。
Navigator に、必要なメジャーとディメンションを指定する必要があります（フィールド間に関係性がない場合、正しいクエリを作成できないことに注意してください）。 タスクに応じて、キューブを複数のテーブルに分割することもお勧めします。 パフォーマンスを向上させ、エラーを回避するのに役立ちます。
自動更新をセットアップするには、Power BI Gateway と Windows 認証を使用する必要があります。 この記事では、この手順を省略します。
このトピックについては、AtScale ドキュメントをお読みください。
列を追加したら、テーブルに変更を適用できます（列名やデータ型の変更、列の追加/変更、値の置換など）。
たとえば、列の名前を変更してみましょう。 これを行うには、列名をダブルクリックします。 数値に空のフィールドがないことを確認することをお勧めします。 すべての空の値は、null としてマークされている必要があります。 空のフィールドがある場合は、フィールド型を上書きします。 これを行うには、列名の左にある型アイコンをクリックし、必要な型を選択します。
Power Query がデータ型を正しく認識しない場合があります。 この例では、日付フォーマットが誤って認識されています。
これを修正するには、特定の日付フォーマットを指定します。 指定するには、データ型のアイコンをクリックし、Use Locale… を選択します。
この場合には、Date と英語（米国）ロケールを選択しました。
これで日付が正しく表示されるようになりました。
Power Query での操作については、公式ドキュメントをご覧ください。
テーブルを日付で関連付けるために、組み込みの DAX 言語を使用して、利用可能な日付に基づいてカレンダーを作成します。
日付テーブルを作成するための 1 つの方法として、組み込みの DAX 関数の使用が推奨されます。社員の誕生日といった、追加の開始日と終了日が含まれているため、手動で CALENDAR に設定することをお勧めします。 これらの関数は、最小の日付と最大の日付の間のすべての日を返します。
Calendar = CALENDAR(<start_date>, <end_date>))
次に、年と目的の月の名称を含む列を追加しましょう。 日付階層を使用して、年と月の名称を取得できます。 Column Tools で New Column ボタンをクリックし、式を記述します。
Month = 'Calendar'[Date].[Year]
DAX では、この式の前に列名があります。 = は式の開始を表します。 その後に式自体が記述されます。 このケースでは、単純にカレンダーの日付から [Year] を取得しています。 テーブル名を記述することが常に推奨されますが、[Date].[Year] のみを書いても構いません。 Power BI はテーブル内の既存の Date 列を参照します。
(MMM-YYYY) フォーマットで、列を追加しましょう。 これには、FORMAT 関数を使用します。
Month-Year = FORMAT('Calendar'[Date], "MMM-YYYY")
ただし、Month フィールドと Month-Year フィールドはテキストフィールドであるため、アルファベット順に並べ替えられます。 並べ替えを正しく行えるように、Month 列の月の数値を持つ MonthNum と、Month-Year 列の MonthYearNum という列を作成しましょう。
MonthYearNum = FORMAT('Calendar'[Date], "YYYYMM")
次に、並べ替え基準の列を設定する必要があります。 Column Tools に移動し、Sort by を選択して、必要な列を選択します。 テキストフィールドのある残りの列にも同じ操作を行いましょう。
DAX の式をよく理解するには、Microsoft 公式サイトのレッスンを利用することができます。
Power BI Desktop の Model ビューを使うと、テーブルやアイテムのリレーションを視覚的に定義することができます。 この場合、関連データを含む 2 つ以上のテーブルがリンクされます。 これにより、ユーザーは複数のテーブルにまたがって関連するデータにアクセスできるようになります。 Model ビューでは、データの概略図を確認できます。
リンクの追加と削除は非常に簡単です。 リンクを作成するには、リンクに使用するフィールドをテーブル間でドラッグします。 リンクを削除するには、右クリックして Delete を選択します。
Data Link の詳細については、Home タブから Manage relationships に移動します。 Manage ダイアログボックスには、視覚的なダイアグラムではなく、リストでリンクが表示されます。 このダイアログボックスで、Autodiscover を選択し、新しいデータまたは湖心されたデータのリレーションを調べることができます。 Edit を選択すると、リンクを手動で変更できます。 編集セクションには、リンクの多重度やクロスリンク の方向を設定できます。
カーディナリティのオプションについて、以下の表で説明します。
| カーディナリティのオプション |
一般に、双方向リレーションの使用を制限することをお勧めします。 モデルの毛売りパフォーマンスに悪影響がある可能性があり、レポートユーザーに混乱を招く可能性があります。
データ間に正確なリレーションを設定することで、複数のデータ要素に渡って複雑な計算を作成できます。
データモデルに関する詳細は、こちらをご覧ください。
レポートページで直接使用できる単純なフィルタは、スライサーと呼ばれます。 スライサーは、レポートページで視覚的に結果をフィルタする方法に関するヒントを提供します。 スライサーには、数値、カテゴリ別、日付別など、様々なタイプがあります。 スライサーを使用すると、ページ上のすべてのビジュアルをまとめて簡単にフィルタすることができます。
この GIF は、標準的なスライスの作業を示します。 様々なオプションを選択する際に、Ctrl を使用せずに、複数の選択範囲を設定できます。
これを行うには、スライサーを選択してから Visualizations パネルで Format visual タブを選択します。Selection を開き、Multiple selection pick Ctrlをオフにします。
スライサーの外観を変更することもできます。 変更するには、スライサー要素の右上にある下矢印を選択します。
視覚的要素を追加するには、Visualizations で要素を選択します。
Stacked column chart（積み上げ縦棒グラフ）を追加しましょう。
次に、表示するフィールドを選択します。 Calendar から Month-Year フィールドを追加し、テーブルから別の数値を追加しましょう。
以下のようになります。
データを切り捨てるために、日付によるフィルタを追加します。 Calendar から Date フィールドを抽出し、可視化タイプをスライサーに変更してから、標準の階層を削除して通常の日付フォーマットを使用しましょう。 ビュータイプをすぐに relative date に変更します。
これで、過去 6 か月に絞り込むフィルタを適用できるようになりました。
可視化のビューは Formatting タブで変更できます。 それぞれに視覚的要素には、特別なパラメーターがあります。 これについての詳細は、こちらをお読みください。
タイトルや背景といった全般オプションを指定できるタブもあります。
さらにいくつかの可視化を追加して、外観を少し変更してみましょう。
これで、簡単なダッシュボードの例ができました。
レポートは必ず https://app.powerbi.com/home にあるポータルに公開されます。
したがって、アカウントがあり、Power BI Desktop で承認されている必要があります。
公開するには、Publish をクリックして、必要に応じてワークスペースを選択します。
正しく公開されたら、ポータルにアクセスし、レポートを確認します。
これらのレポートは調整できますが、制限が適用されます。 主に、新しい列またはメジャーを追加できないという事実に関連したものです。 ただし、これによって、既存の列に基づいて可視化を追加できなくなることはありません。
このレポートは、アクセス権を提供された Power BI ユーザーのみが使用できます。 レポートを他のユーザーと共有するには、次のオプションを使ってウェブに公開します: Publish to web (public)
まだ Power BI Gateway をセットアップしていないため、自動更新を有効にできません。 データは手動でのみ更新可能です。 これを行うには、Refresh ボタンをクリックしてもう一度公開します。
接続するためのドライバーが必要です。 Cloudera Hive を使用します。 公式サイトからダウンロードできます（登録が必要です）。 最適なバージョンのダウンロードを選択するには、OS とビット深度を調べておく必要があります。 インストールは簡単です（説明は不要です）。
キューブを Tableau レポートに接続するには、接続ファイルをダウンロードする必要があります。 これには、Projects ページで目的の Published プロジェクトを選択してから、Connect タブに移動し、Tableau オプションを選択します。
表示されるウィンドウで、［DOWNLOAD TDS］を選択します。
Tableau を起動する際に、左のメニューのリストから［Connect］> ［To a File］>［More...］を選択し、先にダウンロードしていた .tds ファイルを開きます。
Tableau から、AtScale のユーザー名とパスワードを入力するように求められます。 認証が完了したら、キューブがデータソースに表示され、作業を開始できるようになります。
Power BI とは異なり、各ビジュアルは個別のページに作成されます。 ただし、後でワークシートにまとめることは可能です。 Tableau には行と列がありますが、インターフェースはディメンションとメジャーの配置場所によって異なります。
可視化のタイプを選択するには、画面の右上にある［Show Me］をクリックします（可視化のタイプを変更する際に、選択された値の場所が変わる可能性があります）。
データをフィルタリングするためのデフォルトのフィールドは、左側のカードにあります。
値は、Wildcard、Condition、または Top（Bottom）を基準に手動でフィルタできます。 また、これらのタイプのフィルタリングを組み合わせることも可能です。
可視化フォーマットは、Marks で変更できます。
ワークシートはシートをグループ化するのに使用されます。 左側には、必要に応じてドラッグしてグループできる、使用可能なすべてのシートのリストがあります。 また、Objects カードのワークシートでは、テキストや画像の選択や追加が可能です。
Tableau では、Tableau Puclic、Tableau Online、および Tableau Server にレポートを公開できます。 最後の ２つのプログラムには同じ機能が備わっていますが、 Tableau Online が Tableau 自体によって維持されているのに対し、Tableau Server は組織側で維持されるという点が唯一異なります。 ライブ接続を使用して、そこにレポートを公開し、公開済みのレポートを機能の制限なく変更したり、公開済みのレポートを Tableau Desktop で編集したりすることが可能です。 Server には、サーバーに登録されていない人とはレポートを共有できないというデメリットがあります。 つまり、このレポートは組織内だけでの利用を意図したものです。Tableau Public では、リンクを持つ人のみにレポートを共有できますが、ダイレクトデータ接続は使用できません。
ここでは、Tableau Server に接続します。
まず、サインインが必要です。
目的のサーバーを選択して、認証を実施します。 そして次を選択します: Publish Workbook
必要なパラメーターを指定します。表示しやすくするには、［Show sheets as tabs］をオンにすることをお勧めします。
希望であれば、パスワードを埋め込むことができます。 そうでなければ、アカウントにアクセスするたびに、データソースのログインとパスワードを指定する必要があります。すべてのパスワードは、［Embed All Passwords］をクリックするとまとめて埋め込まれます。
ようやくサーバーにアクセスします。［Explore］アイテムを選択し、ブックを探しましょう。
開発者の皆さん、こんにちは！
InterSystems Analytics コンテストのテクノロジーボーナスが発表されました！
Adaptive Analytics (AtScale) キューブの使用- 4 ポイント
InterSystems Adaptive Analytics では、分析ソリューションに AtScale キューブを作成して使用するオプションを提供しています。
今回、コンテスト用に準備した AtScale サーバ（URLと認証情報は Discord チャンネルで確認できます）にあるキューブを使用するか、JDBC 経由で IRIS サーバに接続し、新しいキューブを作成することもできます。
AtScale を使用した Analytics ソリューションの可視化レイヤでは、Tableau、PowerBI、Excel、Logi を利用することができます。
開発者の皆さん、こんにちは！
InterSystems IRIS でアナリティクスソリューションを構築するにはどのような方法があるでしょうか。
最初に、アナリティクスソリューションは何かについて確認しようと思いますが、とても幅広いテーマになってしまうので、Analytics コンテストで発表できるソリューションに限定してご紹介します。
以下、モニタリング、インタラクティブアナリティクス、レポーティングの3種類のアナリティクスソリューションについてご紹介します。
モニタリング
一般的なモニタリングソリューションは、アクティブに更新される KPI を備えたオンラインダッシュボードで構成されています。
モニタリングの主な使用例としては、新しいデータの KPI を常に視覚的に観察し、緊急時に対応することです。
インタラクティブアナリティクス
このソリューションはフィルタやドリルダウンが行えるインタラクティブなダッシュボードのセットを想定しています。
主なユースケースは、グラフや表のデータを視覚化した上で、フィルタやドリルダウンを使用してデータを探しだし、ビジネス上の意思決定を行うことです。
レポーティング
レポーティングソリューションは、グラフやテキスト形式のデータを事前にデザインされたフォームで提供する HTML や PDF ドキュメントの形式で、静的（通常）レポートを提供し、メールで送付することもできます。
レポーティングシステムの主なユースケースは、ビジネスにとって重要な製品やプロセス、サービス、セールスなどの状況を説明するレポートを一定期間に取得することです。
このようなソリューションを構築するために、InterSystems 製品をどのように利用できるでしょうか。
以下の項目で議論してみましょう。
以下の記事では、DeepSee のより柔軟なアーキテクチャ設計の概要を説明します。 前の例で説明したとおり、この実装には、DeepSee キャッシュや DeepSee の実装と設定、および同期グローバル用の個別のデータベースが含まれています。 この例では、DeepSee インデックスを保存するための新しいデータベースを紹介します。 DeepSee インデックスがファクトテーブルや次元テーブルとともにマッピングされないように、グローバルマッピングを再定義します。
APP-FACT データベースはファクトテーブルと次元テーブルしか保存しないのに対し、アナリティクスサーバーは、中間的な例で前に定義したデータベースに加え、インデックスを保存する APP-INDEX データベースを導入します。 インデックスをファクトテーブルから分離するのは、インデックスのサイズが大きくなる可能性があるため、パフォーマンスを向上させるために APP-FACT のブロックサイズを変更することができるからです。
前の例のように、ファクトテーブルとインデックスのジャーナリングはオプションで有効にできます。 詳細については、前の記事の注意事項をお読みください。
次のスクリーンショットは、上記の実装例のマッピングを示しています。 ^DeepSee.Index グローバルのマッピングは、新たに作成された APP-INDEX データベースに保存されるように変更されています。 中間の例と同様に、^DeepSee.Fact* と ^DeepSee.Dimension* グローバルのマッピングは引き続き、ファクトテーブルと次元テーブルを APP-FACT データベースに保存するために使用されています。 クエリログと最後の MDX クエリは、オプションで DeepSee キャッシュとともに保存されます。
このアーキテクチャの例は最も高い柔軟性を備えていますが、ネームスペースごとに 5 つのデータベースを作成する必要があります。 2 つ目の例のように、DeepSee キャッシュはジャーナリングが無効になっている専用のデータベースにマッピングされており、同期グローバルは APP-DSTIME にマッピングされています。
ファクトテーブルとインデックスをマッピングすると、DeepSee の実装と設定をジャーナリングされる専用のデータベース（ APP-DEEPSEE）に保存できるため、DeepSee 実装の復元を簡単に行えるようになります。 多くの場合、対応するグローバルをファクトテーブルと共に APP-FACT に保存するだけで充分であるため、インデックス用のデータベースを個別に作成するのはオプションです。
この連載の最後の記事には、3 つの例で使用したデータベースの要約とリストを記載します。
以下の記事では、DeepSee の中程度の複雑さのアーキテクチャ設計を説明します。 前の例で説明したとおり、この実装には、DeepSee キャッシュや DeepSee の実装と設定用の個別のデータベースが含まれています。 この記事では、同期に必要なグローバルの保存用と、ファクトテーブルとインデックスの保存用に、2 つの新しいデータベースを紹介します。
前の例で紹介した APP-CACHE と APP-DEEPSEE データベースのほかに、APP-DSTIME と APP-FACT データベースを定義します。
APP-DSTIME データベースには DeppSee の同期グローバルである ^OBJ.DSTIME と ^DeepSee.Update が含まれます。 これらのグローバルは、運用サーバーにある（ジャーナリングされた）データベースからミラーリングされています。 APP-DSTIME データベースは、^DeepSee.Update を使用して caché バージョンの読み取りと書き込みができる必要があります。
APP-FACT データベースは、ファクトテーブルとインデックスを保存します。 ファクトテーブルからインデックスを分離するのは、インデックスのサイズが大きくなる可能性があるためです。 APP-FACT を定義することで、ジャーナル設定の柔軟性をより高めたり、デフォルト以外のブロックサイズを定義したりすることができます。 APP-FACT データベースのジャーナリングはオプションで有効にできますが、 この選択は主に、中断が発生した場合にキューブを再構築する際に、アナリティクスが利用できないままとなるかどう通って決まります。 この例では、ファクトテーブルとインデックスのジャーナリングは無効になっています。無効にする一般的な理由には、キューブサイズが小さいこと、キューブの再構築を比較的素早く行えること、そして定期的な再構築が頻繁に行われることがあります。 より詳しい説明は、下の方にある注意事項をお読みください。
次のスクリーンショットは、上記の実装例のマッピングを示しています。
DeepSee 同期グローバルの ^OBJ.DSTIME と ^DeepSee.Update は、APP-DSTIME データベースにマッピングされています。 ^DeepSee.LastQuery と ^DeepSee.QueryLog グローバルは、実行されるすべての MDX クエリのログを定義します。 この例では、これらのグローバルは DeepSee キャッシュとともに APP-CACHE データベースにマッピングされています。 これらのマッピングはオプションです。
^DeepSee.Fact* と ^DeepSee.Dimension* グローバルは、ファクトテーブルと次元テーブルを保存しますが、^DeepSee.Index グローバルは DeppSee インデックスを定義します。 これらのグローバルは、APP-FACT データベースにマッピングされています。
基本的な例のように、DeepSee キャッシュは、ジャーナリングが無効になっている専用のデータベースに正しく保存されています。 DeepSee の実装と設定は、DeepSee 実装を復元できるように、ジャーナリングされたデータベースに個別にマッピングされています。
同期をサポートするグローバルは APP-DSTIME にマッピングされ、プライマリでジャーナリングされています。
ファクトテーブルとインデックスを専用のデータベースにマッピングすると、DeepSee の実装と設定をジャーナリングされる専用のデータベース（ APP-DEEPSEE）に保存できるため、DeepSee 実装の復元を簡単に行えるようになります。
最後の 3 つ目の例では、APP-FACT データベースのマッピングを再定義し、DeepSee インデックスのデータベースを作成します。
キューブを構築するとキューブのファクトとインデックステーブルが削除されて再作成されることに注意してください。 つまり、ジャーナリングが有効である場合、^DeepSee.Fact* や ^DeepSee.Index などのグローバルの SET や KILL がジャーナルファイルに記録されるということです。 その結果、キューブを再構築すると、ジャーナルファイルのエントリが膨大化し、ディスク容量に問題が生じる可能性があります。
ファクトテーブルとインデックスを 1 つか 2 つの別々のデータベースにマッピングすることをお勧めします。
ファクトおよびインデックスデータベースにおいては、ジャーナリングはオプションであり、ビジネスのニーズに基づきます。 キューブが比較的小さく、素早く構築できる場合や、キューブの定期的な再構築が計画されている場合には、ジャーナリングを無効にすることをお勧めします。
キューブが比較的大きく、再構築に時間が掛かる場合には、このデータベースのジャーナリングを有効にします。 キューブが安定しており、定期的に同期されるだけで構築は行われない場合には、ジャーナリングを有効にしておくのが理想的と言えます。 キューブを安全に構築する方法の 1 つとして、ファクトデータベースのジャーナリングを一時的に無効にすることが挙げられます。
以下の記事は、DeepSee の基本的なアーキテクチャを実装するためのガイドです。 この実装には、DeepSee キャッシュ用のデータベースと DeepSee 実装と設定用のデータベースが含まれています。
アナリティクスサーバー用のこの構成には、APP-CACHE と APP-DEEPSEE データベースが含まれています。 DeepSee が円滑に実行するためには、DeepSee キャッシュを決してジャーナリングしないことが重要な設定となります。 ジャーナリングしてしまうと、ハイパージャーナリングやディスク容量の問題が発生するだけでなく、DeepSee エンジンのパフォーマンスが低下してしまいます。 このため、DeepSee キャッシュは、ジャーナリングが無効になっている別の DeepSee Cache データベース「APP-CACHE」に格納されます。
APP-DEEPSEE は、^DeepSee.* グローバルが含まれる、DeepSee の実装と設定用のデータベースです。 これらのグローバルは、定義と設定、Cube Manager、ユーザー設定など、ほとんどの DeepSee 実装を定義しています。 次に示すスクリーンショットに見られるように、すべてのデータベースは読み取り/書き込みが可能であり、APP-DEEPSEE でのみジャーナリングが有効となるように決定されていることに注意してください。 このデータベースにはすべての定義、設定、およびユーザーデータが含まれているため、これをジャーナリングすることをお勧めします。
次のスクリーンショットは、APP ネームスペース上のこの基本アーキテクチャ実装のマッピングを示しています。 ^DeepSee.Cache.* と ^DeepSee.JoinIndex は DeepSee キャッシュを APP-CACHE データベースにマッピングしています。 ^DeepSee.* グローバルはとりわけ、DeepSee の実装と設定を APP-DEEPSEE データベースにマッピングしています。
基本アーキテクチャのこの例では、DeepSee キャッシュは専用のデータベースに保存されています。 このため、^DeepSee.Cache* と ^DeepSee.JoinIndex グローバルのジャーナリングを無効にすることができます。
中断が発生した場合に DeepSee 実装（キューブ、サブジェクトエリア、DeepSee アイテム、ユーザー設定など）の復元を実現できるのが、APP-DEEPSEE データベースのジャーナリングです。
この例に説明されている構成には、いくつかの欠点があります。 まず、同期をサポートするグローバルが処理されていない点です。 2 つ目は、APP-DEEPSEE データベースには、ファクトテーブル、インデックス、およびその他の DeepSee グローバルも含まれている点です。 そのため、APP-DEEPSEE のサイズが肥大し、ジャーナリングと復元が実用的でなくなる可能性があります。 この構成は、たとえばキューブに大量のデータが含まれていない場合などに適用できます。
この連載の次の例では、キューブ同期グローバル、ファクトテーブル、およびインデックスを個別のデータベースにマッピングする方法を説明します。
以下の記事は、この連載の締めくくりとして、完全に柔軟なアーキテクチャの例で確認されたすべてのデータベースのリストを掲載しています。
以下で説明するデータベースは、ネームスペース間で共有する必要のあるアプリケーションコードを除き（例では APP-CODE データベースに格納されています）、ネームスペースごとに定義されている必要があります。 DeepSee 実装が実行するすべてのネームスペースはグローバルマッピングを使用し、グローバルが正しいデータベースに保存されて読み取られるようにする必要があります。
このデータベースはすべての DeepSee キャッシュ（^DeepSee.Cache.* および ^DeepSee.JoinIndex グローバル）を保存する必要があります（注意: ドキュメントのこちらのページに、さらに多くのグローバルが DeepSee キャッシュとしてリストされていますが、^DeepSee.Cache.* グローバルが明らかに最も重要なグローバルです）。
DeepSee キャッシュグローバルを専用のデータベースにマッピングすることを強くお勧めします。 DeepSee キャッシュグローバルは決してジャーナル化されてはいけません。ジャーナル化してしまうと、DeepSee のパフォーマンスが低下し、ジャーナルファイルが巨大化する可能性があります。
^DeepSee.Cache.* と ^DeepSee.JoinIndex グローバルをこのデータベースにマッピングします。 必要に応じて、^DeepSee.LastQuery と ^DeepSee.QueryLog グローバルもこのデータベースにマッピングします。これらは実行されたすべての MDX クエリのログを保存するグローバルです。
このデータベースには、DeepSee 実装のほとんどが含まれている ^DeepSee.* グローバルが含まれています。 このデータベースには、すべての DeepSee キューブまたはサブジェクトエリアの定義のほか、Cube Manager（^DeepSee.CubeManager*）、キューブの定義と設定（^DeepSee.Cubes、^DeepSee.Dimensions）、DeepSee のアイテム（^DeepSee.Folder*、^DeepSee.FolderItem*）、ピボット変数（^DeepSee.Variables）、用語リスト（DeepSee.TermList）、ユーザー設定（^DeepSee.DashboardSettings）、DeepSee オーバーライド（^DeepSee.Overrides）などの多数の機能に関する情報も含まれています。
これらの機能は別の読み取り/書き込み可能なデータベースに保存し、そのデータベースにジャーナリングを実行して定期的にバックアップすることをお勧めします。 そうすれば、何らかの中断が生じた場合でも、すべての定義、設定、およびユーザーデータを復元することが可能になります。
残りのすべての ^DeepSee* グローバルをこのデータベースにマッピングします。
DeepSee は、ソーステーブルでキューブを最新の状態に維持するために、^OBJ.DSTIME と ^DeepSee.Update グローバルを使用しています。 運用データベースでは、このデータベースに ^OBJ.DSTIME グローバルを保存し、アナリティクスサーバーにミラーリングします。 システムがアドホックまたは最新バージョンの Caché で実行している場合、これらには ^DeepSee.Update が使用されているため（通常、Caché 2016.1.2 以降で利用可能）、このデータベースにも ^DeepSee.Update が保存されます。 この場合、^OBJ.DSTIME を保存しているアナリティクスサーバーのデータベースは、読み取り/書き込み可能であり、^OBJ.DSTIME が ^DeepSee.Update にコピーされた後に、それをパージできる必要があります。 データベースホスティングデータ（この例では APP-DATA）が読み取り専用の場合、このデータベースを使用する必要があることに注意してください。使用しない場合、^OBJ.DSTIME をパージするのは不可能です。
運用サーバーでは、ジャーナリングが有効になっている必要があります。 ^OBJ.DSTIME と ^DeepSee.Update をこのデータベースにマッピングします。
DeepSee のキューブはソースクラスに基づいていますが、ファクトテーブルと次元テーブルにデータを入力して使用します。 これらのテーブルには、キューブに組み込まれた各レコードの情報が含まれており、ランタイム時に DeepSee によって使用されます。
ファクトテーブル、次元テーブル、およびインデックス用の専用データベースを定義するのは通常、データベースごとに異なるジャーナリングの設定を適用するためです。 ジャーナリングが有効である場合のキューブの構築について、以下の注意事項をお読みください。 ファクトテーブル、次元テーブル、およびインデックスを別のデータベースにマッピングするもう 1 つの理由は、デフォルト以外のブロックサイズを定義することができるからです（デフォルトの 8000 ブロックではなく 16000 ブロックにするなど）。 異なるブロックサイズを使用することで、MDX クエリのパフォーマンスを向上させることができます。
ファクトテーブルと次元テーブルは、^DeepSee.Fact* と ^DeepSee.Dimension* グローバルに保存されています。 DeepSee インデックスは ^DeepSee.Index に保存され、キューブがリレーションを定義するときに ^DeepSee.JoinIndex グローバルが使用されます。 これらのグローバルはこのデータベースにマッピングします。
DeepSee インデックスは、キューブのファクトテーブルのインデックスです。
DeepSee インデックスを別のデータベースに保存するのは、^DeepSee.Index グローバルのサイズが大きくなる可能性があるためです。 異なるジャーナリング設定を使用し、デフォルト以外のブロックサイズを定義すると、復元を簡単に行えるようになり、パフォーマンスの改善にも役立ちます。
ジャーナリングはオプションです。前のデータベースと同じ設定を選択してください。
^DeepSee.Index グローバルはこのデータベースにマッピングします。
キューブを構築するとキューブのファクトとインデックステーブルが削除されて再作成されることに注意してください。 つまり、ジャーナリングが有効である場合、^DeepSee.Fact* や ^DeepSee.Index などのグローバルの SET や KILL がジャーナルファイルに記録されるということです。 その結果、キューブを再構築すると、ジャーナルファイルのエントリが膨大化し、ディスク容量に問題が生じる可能性があります。
ファクトテーブルとインデックスを 1 つか 2 つの別々のデータベース（上記のデータベース 4 とデータベース 5）にマッピングすることをお勧めします。
ファクトおよびインデックスデータベースにおいては、ジャーナリングはオプションであり、ビジネスのニーズに基づきます。 キューブが比較的小さく、素早く構築できる場合や、キューブの定期的な再構築が計画されている場合には、ジャーナリングを無効にすることをお勧めします。
キューブが比較的大きく、再構築に時間が掛かる場合には このデータベースのジャーナリングを有効にします。 キューブが安定しており、定期的に同期されるだけで構築は行われない場合には、ジャーナリングを有効にしておくのが理想的と言えます。 キューブを安全に構築する方法の 1 つとして、ファクトデータベースとインデックスデータベース（順にデータベース 4 と 5）のジャーナリングを一時的に無効にすることが挙げられます。
| データベース |
この連載では、Caché と DeepSee を使用したビジネスインテリジェンスの実装に関して考慮する必要のあるデータベースとマッピング関連のベストプラクティスを説明しました。 この連載で推奨したデータベースより少ない数のデータベースを使って DeepSee 実装をデプロイすることはもちろん可能ですが、実装に制限がかかる可能性があります。
インターシステムズは、以下のプレビューバージョンをリリースしました。
来月に予定されている一般提供開始に先立ち、このプレビューリリースにて新製品の感想を皆様からお聞かせいただきたいと思います。
InterSystems IRIS Data Platform 2021.1 は、エクステンデッド・メンテナンス(EM)リリースです。前回のEMリリースである2020.1以降、継続的なデリバリー(CD)リリースで多くの重要な新機能や拡張機能が追加されています。
CDリリースの概要については、2020.2、2020.3、2020.4のリリースノートを参照してください。
このプレビューリリースのビルド番号は、2021.1.0.205.0 です。
【新機能のご紹介】
本リリースの機能強化により、開発者は選択した言語で高速かつ堅牢なアプリケーションをより自由に構築できるようになり、ユーザーは新しい高速な分析機能により大量の情報をより効果的に利用できるようになります。
皆さん、こんにちは。
iris-analytics-パッケージには、「企業が自社のソフトウェアで InterSystems Analytics の サポートをいかに簡単、そしてシンプルに利用できるかを示す」意図があります。
新しいシンプルなソリューションを作成したり、OpenExchange を使用して既存のソリューションを改善したりすることもできます。
InterSystems IRISにアップグレードしている企業のほとんどは、ツールが提供するすべての機能を活用しています。
このコンテストでの私のもう一つのターゲットは、インターシステムズを長く利用していても、自分たちがアクセスしている可能性をフルに活用していない企業です。
このプロジェクトは、他のプロジェクトをベースにしてインスピレーションを得て作成しました。ありがとう @Evgeny Shvarov @Guillaume Rongier @Peter Steiwer
それらのプロジェクトが一緒になって、このウィザードになった。
メインページはシンプルで、そこに至るまでのプロセスがわかりやすい。
ウィザードを適切に使用するためのフィールドがいくつかあります。
インスタンスのデータに基づくビジネスインテリジェンスを実装しようと計画中です。 DeepSee を使うには、データベースと環境をどのようにセットアップするのがベストですか？
このチュートリアルでは、DeepSee の 3 つのアーキテクチャ例を示しながら、上記の質問を解決します。 基本的なアーキテクチャモデルを、その制限を重点に説明するところから始めましょう。 以降のモデルは、複雑さが中程度のビジネスインテリジェンスアプリケーションに推奨されており、ほとんどのユースケースで十分なはずです。 チュートリアルの最後には、高度な実装を管理できるように、アーキテクチャの柔軟性を強化する方法を説明します。
このチュートリアルに含まれる例では、新しいデータベースとグローバルマッピングを紹介し、それらをセットアップする理由とタイミングについて説明します。 アーキテクチャを構築する際には、より柔軟な例から得られるメリットについて説明します。
データの高可用性を実現する場合、InterSystems では一般的にミラーリングとシャドウイングを使用して、ミラー/シャドウサーバーに DeepSee を実装することをお勧めしています。 データの元のコピーをホストするマシンを「プライマリサーバー」と呼び、データとビジネスインテリジェンスアプリケーションのコピーをホストするマシンを「分析（またはレポーティング）サーバー」と呼びます。
プライマリサーバーと分析サーバーを用意しておくことは非常に重要です。これは主に、いずれのサーバーにおいてもパフォーマンスに関する問題を回避するためです。 推奨アーキテクチャに関するドキュメントをご覧ください。
ソースデータとコードを同じデータベースに保存することは、通常、規模の小さなアプリケーションでのみうまく機能します。 より大規模なアプリケーションでは、ソースデータとコードをそれぞれの専用データベースに保存することが推奨されます。専用のデータベースを使用することで、データを分離しながらも、DeepSee が実行するすべてのネームスペースでコードを共有することができます。 ソースデータ用のデータベースは、本番サーバーからミラーリングできるようにしておく必要があります。 このデータベースは、読み取り専用または読み取り/書き込みのいずれかです。 このデータベースでは、ジャーナリングを有効にしておくことをお勧めします。
ソースクラスとカスタムアプリケーションは、本番サーバーと分析サーバーの両方にある専用データベースに保存します。 これら 2 つのソースコード用データベースは同期している必要がなく、同じバージョンの Caché を実行している必要もありません。 コードが別の場所で定期的にバックアップされているのであれば、ジャーナリングは通常必要ではありません。
このチュートリアルでは、次の構成を使用しています。 分析サーバーの APP ネームスペースには、デフォルトのデータベースとして APP-DATA と APP-CODE があります。 APP-DATA データベースは、プライマリサーバーにある ソースデータ用データベースのデータ（ソーステーブルのクラスとファクト）にアクセスできます。 APP-CODE データベースは、Caché コード（.cls と .INT ファイル）とほかのカスタムコードを保存します。 このようにデータとコードを分離するのは典型的なアーキテクチャであり、ユーザーは、DeepSee コードとカスタムアプリケーションを効率的にデプロイすることができます。
DeepSee を使用したビジネスインテリジェンス実装は、異なるネームスペースから実行されることがよくあります。 この記事では単一の APP ネームスペースのセットアップ方法を示しますが、同じ手順を使えば、ビジネスインテリジェンスアプリケーションが実行するすべてのネームスペースをセットアップすることも可能です。
ドキュメントに含まれる初回セットアップの実行に関するページの内容を理解しておくことをお勧めします。 このページには、Web アプリケーションのセットアップ、DeepSee グローバルを個別のデータベースに配置する方法、および DeepSee グローバルの代替マッピングのリストが含まれています。
このシリーズの第 2 部では、基本的なアーキテクチャモデルの実装について説明します。
