親愛なる読者への挨拶。
この資料は、私が長年にわたって取り組んできたRDBMSを使用することの利便性の問題を明らかにしますが、伝える時間はありませんでした。

データの検索、表示、分析を行っていない場合、または行っている場合でも、完全に便利で何も必要ない場合は、このテキストを読むのをやめてください。

発行

したがって、あなたはDBMSを読み込む権利を持つユーザーです。 おそらく典型的なサブタスクのセットがあるでしょう：

• データ構造を扱う
• 必要なエンティティを見つけます
• 必要なフィールドを見つけてください
• エンティティ間の関係を見つける
• 関心のある値を見つける
• 値のセットを選択します
• 必要なデータを選択してください
• これが本当に探していたMOSTデータであることを確認してください
• 結果を保存
• それらからレポートを準備する

最後に、これらの問題を定期的に解決する必要がある可能性が非常に高くなります。

データ処理ツールの市場には、クエリ、キューブ、およびレポートの作成専用のツールが大量にあります。 残念ですが、それらのほとんどは、ユーザーが上記のタスクを完全に持っているのを見ません。 一般的な問題を前のリストと逆の順序でリストします。

• 新しいリクエストごとに、見つかった知識を修正する機会に出会う場所はまれです。最初から
• 以前に準備されたリクエストは、
  純粋なSQL
• 要求の構造（フィールド、フィルター、グループ化）は変更が困難です。 通常、急速な変化の代償は、完全性の損失または冗長性の残存です。
• フィルターの準備は盲目的に行われます
• エンティティ間の関係は手動で指定されます。
• 彼がアクセスできるデータベーススキーマ全体が抜け落ちます

これらはすべて、構造に関するドキュメントの欠如を背景にしています。 ツールの外側にあるという事実にもかかわらず、問題はツールに直接関係します。

これらの問題の現実が何であるかが明確でない場合は、私がどのように問題を解決しようとしているのかを学ぶことでこれを理解してくれることを願っています あなたの意見では、これらの問題が遠慮がちである場合、さらに読み進めなければ、私たちにとってより簡単になります。

解決策

プログラム「サンプリングの自由」で特定された問題に対する包括的な解決策は、同時にいくつかの方向で実行されます。 このセクションのテキストでは、適用される概念と実装のニュアンスについて詳しく説明しています。

明確で便利なデータ構造

最も単純なデータベースにのみ、失われることのできないエンティティが含まれています。 よく開発されたアプリケーション領域では、テーブルとフィールドはそれぞれ数十と数百で測定されます。ストレージについて言えば、これらは数百と数千です。 さらに、開発者またはアナリストは、多くの場合、各サブジェクトエリアに対して複数の接続（テスト、生産的、アーカイブ）を持っていますが、これも原則として非常に多くの接続です。

必要なものを完全に不要なものと区別することは、ツールによって解決される最初のタスクの1つです。

データベースとテーブル

選択したアクセス「エンジン」内で、接続を作成および記憶できますが、これは標準です。

テーブルの完全なリストで、サブストリングごとに関心のあるフィールドを見つけることができます。次に例を示します。

コンテキスト

エンティティ/テーブルコンテキストは、Business Objectsユニバースに近い概念ですが、より広い概念です。 ユーザーは、選択したテーブルに関係のないテーブルには興味がないと考えるのが自然です。 コンテキストに直接関連するテーブルのみがコンテキストに含まれていると考えるのは間違いです。したがって、コンテキストでは、任意のレベルのネストを確認できます。



ノードはエンティティであり、リーフはフィールドです。 関連するエンティティは、関係を持つエンティティのフィールドの横に表示されます。 同じエンティティへの複数の接続は、リンクが示されるフィールドによって区別されます。



デフォルトでは、フィールドによって参照されるエンティティのみが表示されますが、反対側からの関係も確認できます。



この操作は、テーブルごとに1回だけ実行されるか、すべてのテーブルのモードが自動的にオンになります。

認識

システム設計者がすべての外部キーを提供し、それらをスキームに登録しておけば、接続は自動的に決定され、これをほとんど気にする必要はありません。 私はそのようなデータベースを見るのが大好きです。 上記のスクリーンショットの例は、そのうちの1つで作成されています。プロジェクトの1つの先生に感謝します。

アーキテクトがこれを予見しなかった場合だけでなく、アクセスコンポーネントのサブドライバーがこの情報の取得をサポートしていない場合も幸運ではありません。 この状況はADOおよびODBCで頻繁に発生しますが、これらのエンジンだけがツールで使用できるわけではありません。

定義

何らかの理由で、接続のデータを回線から取得できないという事実にまだ直面しているとします。 しかし、それらは毎回使うのにとても便利です。

それらを自分で決定することができます。 これを行うにはいくつかの方法があります。

最も簡単なのは、コンテキストメニューとダイアログを使用した1つのフィールドの1回限りの束です（場合によっては、互いの上にドラッグアンドドロップフィールドを介して行うことができます）。



より複雑なのは、いくつかのフィールドの集まりです：



最後に、曲技飛行は、必要なすべてのテーブルの複数の典型的な接続です。



私は最後のタスクを実行し、人気のあるオープンソースポータルのスキームを分析しなければなりませんでした。そこでは、各ルックアップテーブルへの数十の明らかなリンクがあり、リンクの数は同じ順番になります。

これらの接続はすべて、ローカルの「スキーム」に保存され、ドライバーを介してデータベースへの自動認識リンクへの追加として存在し、それらとともにコンテキストを決定し続けます。

その他の機能

特定の場合には、コンテキストをより柔軟にする個別の利点があります。 コンテキストメニューのスナップショットだけを詳しく説明します。

でも、これは何のためですか？！

ユーザーが操作するエンティティのコンテキストの定義と表示は、リンクにネストされた必要なデータの選択に集中できるようにするだけでなく、行われます。 クエリビルダーは接続フィールドを考慮し、リンクの性質はユーザーに透過的であるため、ユーザーはそれらをリンクすることを考えません。

リクエストを作成する便利さ

便利な作業の最初の一歩を踏み出しました-重要なものを二次的なものから分離しました。 今、私たちの仕事は、手頃な価格から必須の選択を簡素化することです。

外出先で

私たちのタスクは、コンテキストを目的の深さまで開き、必要なフィールドを選択することです。 テーブルはそれらに移動するための単なる方法であり、それらを指定することはまったく必要ありません。 クエリ内のフィールドを使用した一般的な操作は、選択範囲への追加、フィルターへの追加、および式への追加（選択範囲またはフィルター内）です。

一般的なアクションの3つのボタンアイコンが図で強調表示され、そのうちの1つの結果（フィルターに追加）が、Serviceテーブルによって参照されるServiceSubGroupテーブルのNameフィールドの例に示されています。



ツールでテーブルを選択すると、選択にすべてのフィールドを自動的に追加することができます。 ただし、結果に余分なゴミは必要ないので、いくつかのフィールド（図では同じServiceテーブル）を削除する必要があります。



...そして、コンテキストの深さからフィールドを追加します（ドラッグアンドドロップで行います）：



...グループの最大フィールド値と行数を見つけます。



...次に、フィールドを再グループ化します。



...リクエストを行います（フィルタの追加定義は省略されます。詳細については後述）：



...サンプルから1つのフィールドを一時的に削除し、別のフィールドをグループ解除します。



...新しいリクエストを作成し、より興味深い結果を確認します。



これだけでなく、さらに多くのことができるようになりました。今では、最小限のクリックで済みます。

オブジェクトモデル

「Freedom of Fetch」ツールの最も重要な機能は、データベースオブジェクトがどこでも全体的に解釈されることです。つまり、表示、追加、削除、非表示などです。 これにより、ユーザーは操作しながらリラックスでき、機器は失われず、
ユーザーとの対話でそれらを台無しにします。

オブジェクトモデルは、接続の必要性と十分性を明確に制御し、要求をグループ化するフィールドを考慮します。 例：



グループ内のすべてのサービスをサブグループとサービス名で除算して、グループ要求を作成します。図の中央には、生成された要求が示されています。

次に、サブグループのみでグループ化したいため、サービスの名前を「非表示」にします。



要求では、両方の部分（選択、グループ化）からショートネームが消えました。

最後に、選択条件を削除します（再び一時的に）：



リクエストでは、whereセクションが完全に消えただけでなく、ServiceGroupテーブルのフィールドが不要になったため、結合が1つ少なくなりました。

当然、同じ数回のクリックで、リクエストを逆の状態に戻すことができます。

式エディター

フィールドと関係だけを使用しても、ある程度しか十分ではありません。 遅かれ早かれ、データベースから直接表されない新しい値を計算する必要が生じます。 私たちがすでに知っている快適さと手動での作成、さらにはデザインの変更を組み合わせる方法は？

解決策は非常に簡単です。フィールドをオブジェクトとして使用し続ける必要があり、すべてのさまざまなDBMSの最も豊富な構文（標準の集計関数を除く）の残りはユーザーに任せる必要があります。 つまり、フィールドではないすべてのものは、テキストで書くことに加えて、「正しいスタイル」でフィールドを参照する、または参照しない機会があります。

式エディターは、式テキスト内の使用可能なフィールドへのリンクをどこにでも挿入できるように、または以前に指定したリンクを削除できるように設計されています。



この図では、セッションの合計と操作の合計の差を作成し（必要に応じて0になるように）、すべてを100で割ったことがわかります（元はコペック単位でした）。 この式には、ツールによって管理および区別される6つのオブジェクトがあります。開始ブラケット、2つのフィールド、集約関数、および2つの終了ブラケットです。 ブラケットはマネージオブジェクトに配置され、ペアの制御が簡素化されます（一方のブラケットを削除すると、もう一方のブラケット/関数は自動的に削除されます）。また、フィールドが集計式にあるかどうかを確認できます。 他のすべての文字： - 、 / 、1、0、0は「そのまま」サーバーに転送され、機器にとっては何も意味しません。

これはあまり便利ではないように思われるかもしれません。リンクと式の残りの部分を書くことを切り替えてください。 ただし、フィールド内の平均文字数のタイピング速度のみを比較しても、すでに勝っています。 ここで可能なコンテキストの深さを追加します。 また、このテキストの前後で説明した操作の利便性に対する支払いとして、この違いはまったく考慮できません。

選択またはフィルターで指定されたフィールドは、すでに次のような変更可能な式です。

最も便利なフィルタリング

選択を操作するための優れた手段が存在する場合、リミッターを使用した作業も同様に単純でなければならないことは明らかです。 私たちが自由に使える機会を考えてみましょう。

数回クリックするだけでフィルターを設定します

フィルターを操作するためのパネルには、最初はフィルター用の空のコンテナーが含まれています。



コンテナにフィルターを追加するには、いくつかの方法があります。

• 空の新しいものを作成する
• スキームの「フィルター内」ボタンを押す
• ダイアグラムからマウスでフィールドをドラッグします
• 式を選択範囲からコンテナにドラッグします（式のコピーでフィルターが作成されます）

その結果、次のようなものが得られます（フィルターはスケッチされるだけですが、すべては未定です）。



フィルターのいずれかを選択してフィルターを追加し、そのタイプと値を指定できます。

予測値の選択

左側の式の複雑さに関係なく、フィルター処理する可能性のある多くの値をすばやく把握することができます。 表現をもう少しキャッチーにして、「ガイド」が何を提供してくれるか見てみましょう。



マニュアルは、この表現のすべての組み合わせを慎重に提供しました。

ただし、これが最も単純なケースでした。これは、それらが属するテーブルフィールドのすべての組み合わせが選択されたためです。 多くの場合、それらが多すぎるため、それらがサンプルに含まれることさえ保証されません。 このような場合、2つの追加選択モードがあります。



それらは、増加する順序の期間に配置されます。

「フィルターなしで予期される」とは、選択されたフィールドのテーブルから参照される値のみが選択されることを意味します。

「フィルタを使用して期待」では、スーパーインポーズされたフィルタが考慮されるため、オプションがさらに絞り込まれます。 当然、現在のフィルターは破棄されます。

前の例から空のフィルターを削除し、「フィルターが必要です」選択を選択すると、次の結果が表示されます。



空のサンプルを取得するたびに、長くて苦労して値を選択できました。 この式のフィルターは冗長であるか、「寿命と互換性がありません」。

フィルターのグループ化、並べ替え、無効化

これまでに、いくつかの単純なフィルターの最も単純なセットを調べてきました。 ただし、このパネルでは、それらを任意の組み合わせにグループ化し、「and」、「or」、および拒否に基づいてそれらの和集合演算を実行できます。 これは、ドラッグアンドドロップジェスチャとツールバーボタンを使用して行われます。 ルートでも、各フィルターを無効にできます。 たとえば、次のような構成を作成できます。

しっかりと永遠に

かつて何が行われたとしても、少なくとも仕事について話している場合は、もう一度繰り返したくありません。 一度作成したら、どの結果に頼ることができるかをリストしましょう。

リンク構成の保存

ツールの便利さの基本の1つはテーブルコンテキストです。 手動で作業する必要がある場合は、ファイルに保存されます。ファイルは手動で編集することも、別のワークステーションに持ち込むこともできます。 ただし、この情報がアーキテクトによって規定されている場合、全員が優れています。

回復可能なクエリ構造

作成されたリクエストは保存して、本格的な「ドキュメント」として転送できます。別の時間または別の場所で開くと、すべての詳細が復元されます。 唯一の自然な制限は、データベースへの接続にアクセスできる必要があり、その構造が使用されるフィールドの精度と一致する必要があるということです。 コンテキスト設定の転送は必須ではなく、必要なリンクのコピーがドキュメントに登録されます。

完了した各リクエストは履歴プールに保存されます。

リクエストを完了するとすぐに、以前に実行されたリクエストのリストに追加されます。 これは、フィールド、条件、グループ化などの絞り込みの反復間で結果を比較できるようにするために行われます。 データセットに加えて、クエリ構造が（ドキュメントとして）保存されます-復元でき、元のSQLクエリ（手動で変更できます）。

セッションの自動保存と復元

最後に、プログラムを緊急に中断した場合に備えて、クエリ履歴全体が保存され、再起動後に完全に復元されます。

開発方向

このツールには特徴的な機能ではないため、ここでは言及しなかった多くの小さなものがあります。 さらに、これらのささいなことの多くは、まれにしか使用されなかったり、リファクタリングの副産物によって死んだり、死んだりします。

このツールはあまり知られていませんが、開発者が直面しているものだけが含まれています。 関心と需要があれば、多くを修復して完了することができます。

当初、このツールはデスクトップとして開発されていましたが、最近では単純化されたWebインターフェイスが実験として実装されました。 デスクトップインターフェイス自体はかなり時代遅れです。

親愛なる読者の皆さんの反応は、このツールが動的な生活を送るべきか、それとも単なる例示なのかを判断することを願っています
別の行き止まりの開発ブランチ。 ご清聴ありがとうございました！