Docsvisionデータベース構造。 開発者から開発者へ！

Docsvisionは単なるプログラムではなく、電子文書管理のための独自のソリューションを作成できるプラットフォームです。 同僚のDocsvision開発者Dima Leikinによる記事は、このようなソリューションの開発者を対象としています。これには、当社のパートナーや顧客企業のIT部門の従業員が含まれます。



5つの論理部分に分かれた資料には、Docsvisionシステムの動作に関する基本情報が含まれています。 さらに、私たちと一緒に仕事をしたい開発者にとって、この知識はさらにプラスになります。









一般に、Docsvisionはクライアント/サーバーシステムであり、そのソリューションの開発は一連のカード（つまり、ライブラリ）の開発にかかっています。



カードは、Docsvisionシステムの基本概念です。 クライアントの観点から見ると、カードはドキュメントまたはタスクを操作しているときに表示されるUIです。 クライアント部分のプログラマーの観点から見ると、カードは情報をサーバーに保存できるオブジェクトモデルです。 サーバープログラマーの観点から見ると、カードはテーブルにアクセスするための一連のテーブルとストアドプロシージャです。 カード開発者の観点から見ると、カードはまず第一にメタデータです。 このメタデータに従って、カードのテーブルとストアドプロシージャが生成されます。これらには、セキュリティ、カードデータのクライアントへのダウンロード方法など、多くの属性が含まれています。



ディレクトリも別の重要な概念です。 ディレクトリは、単一のコピーに存在するカードです。 たとえば、従業員のディレクトリ、保存された検索のディレクトリ、役割のディレクトリなど。

システム自体には、すでに書かれたカードのライブラリがいくつか付属しています。 これらは、プラットフォームPlatform、ManagedPlatform、Takeoffice、Workflow、Backofficeのライブラリです。

記事の最初のシリーズは、システムの基礎であるDocsvisionデータベースに焦点を当てています。 もちろん、これは完全な説明にはほど遠い。 情報は主にシステムの原則に当てられているため、簡単にするために多くの詳細を犠牲にする必要がありました。

パート1.セクションテーブル

CardManagerユーティリティを使用してカードライブラリを開発すると、カードのメタデータ記述を含むxmlが作成されます。 次に、このメタデータに基づいて、テーブルとストアドプロシージャがデータベースに生成され、これらのカードを操作できます。 メタデータは、基本的にカードの種類の説明です。

メタデータについて簡単に

メタデータの観点から見ると、カードはセクションの集まりです。 このセクションは、データベース内のテーブルとして想像できるため、より明確になります。 セクションはフィールドのコレクションです。 フィールドは、このテーブルの列と考えることができます。 セクションは、コレクション、木製、または構造体のタイプにすることができます。 セクションには子セクションを含めることができます。これについては、後で詳しく説明します。



各カードには一意の識別子（カードタイプ識別子）があります。 同様に、セクションとフィールドには一意の識別子があります。 セクションテーブルの名前は現在[dbo]。[Dvtable_ {id}]で生成されるため、セクション識別子は非常に重要です。ここでidはセクション識別子です。



多くの場合、初心者は型やインスタンスと混同されます。 たとえば、テーブル[dbo]。[Dvsys_instances]では、カードインスタンスに関する情報が格納され、InstanceIDフィールド（カードインスタンス識別子）でドキュメントカードのカードタイプ識別子の検索を開始します。 そして、彼らがそこで彼を見つけられないとき、彼らは非常に驚いています。 （ここで、ディレクトリのDocsvisionの最新バージョンでは、カード識別子はタイプ識別子と等しいことに注意してください）。

データベースへの情報の保存に関するセクション

情報を保存するという観点から見ると、セクションはデータベーステーブルです。 データベースのセクションフィールドは、テーブルの列に対応しています。 フィールドの列に加えて、各「セクション」テーブルには、いわゆるシステム列（RowID、InstanceID、ParentRowID、ParentTreeRowIDなど）があります。



InstanceIDおよびRowID列

RowID-セクションテーブル（主キー）の行の一意の識別子（Guid）。

InstanceID-この行が属するカードのインスタンスの識別子（Guid）。 テーブル[dbo] [Dvsys_instances]のカードの識別子に対応します。



セクションテーブルは次のように想像できます。

InstanceID	ROWID	...
Cardid1	ROWID1	...
Cardid1	ROWID2	...
Cardid2	Rowid3	...
Cardid2	Rowdd4	...

同じテーブルには、このタイプのカードのすべてのインスタンスのセクションラインに関する情報が格納されます。



データベース内のさまざまなタイプのセクションの表現

セクションには、コレクション、木製、タイプ構造体があります。 セクションの名前は、明らかに、これらのタイプのセクションが保存されるデータ構造に由来しています。



収集可能なセクション

コレクションセクションは、オブジェクトのコレクションを格納するように設計されています。 データベースの観点から見ると、これはセクションテーブルの行の中に同じInstanceIDを持つ行が存在する可能性があることを意味します。



タイプ構造体のセクション

タイプ構造体のセクションは、データ構造を格納することを目的としています。 実際、これは同じコレクションセクションですが、コレクションのみが最大1つのオブジェクトを持つことができます。 データベースの観点から見ると、これは、同じInstanceIDを持つ2つの行がセクショナルテーブルに存在できないことを意味します。 セクションテーブルの列は、構造のフィールドに対応しています。



木製のセクション

木製のセクションは、木を保管するためのものです。 ツリーは次のように保存されます。システム列ParentTreeRowIDがあり、各行にはツリーの親行の識別子が書き込まれます。親行がない場合はGuid.Emptyが書き込まれます。 木製のセクションでは、カードの1つのコピーに対して複数のツリーを保存できます。制限はありません。

ツリーの行を削除すると、そのすべての子行が削除されます。これは、行を削除するためのストアドプロシージャによって提供されます。



子セクション

木製のセクションを使用すると、オブジェクトに対して同じタイプの子オブジェクトのコレクションを保存できます。 しかし、異なるタイプの子のコレクションを保存したい場合はどうでしょうか？ このために、子セクションが意図されています。 親セクションと子セクションの「古典的な」例は、従業員ディレクトリ内の部門と従業員のセクションです。 各ユニットには従業員のコレクションがあります。 データベースでは、次のようになります。システム列ParentRowIDの従業員のセクションテーブル（ParentTreeRowIDと混同しないでください）には、親ユニットの識別子が示されています。

ROWID
CompanyID1
CompanyID2

ROWID	ParentRowID
EmployeeID1	CompanyID1
EmployeeID2	CompanyID1

子セクションのセクションテーブルの場合、カスケード削除を使用して、親テーブルに（子のParentRowIDから親テーブルのRowIDまで）外部キーが生成されます。 つまり、たとえば、ユニットが削除されると、そのすべての従業員が削除されます。

ワークショップ

この知識をどのように実践できますか？ Docsvisionデータベースがあり、どの従業員が従業員ディレクトリに登録されているかを確認するとします。 まず、従業員の従業員ディレクトリのセクションの識別子を見つける必要があります。 もちろん、最も簡単な方法はCardManagerまたはxmlを調べることですが、手元にない場合は重要ではありません。



従業員のディレクトリの識別子を見つけます。

select * from [dbo].[dvsys_carddefs] where Alias like '%Staff%'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

セクションのリストを取得します。

 select * from [dbo].[dvsys_sectiondefs] where CardTypeID = '6710B92A-E148-4363-8A6F-1AA0EB18936C'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Employeesエイリアスを持つセクションのSectionTypeIDフィールドには、従業員セクション識別子「DBC8AE9D-C1D2-4D5E-978B-339D22B32482」が表示されます。 従業員の部門別表から要求を行います。

 select * from [dbo].[dvtable_{DBC8AE9D-C1D2-4D5E-978B-339D22B32482}]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

目の前の従業員のリスト。 ここで、Testという名前のユニットに含まれる従業員の種類を確認したいとします。 同様に、ユニットセクションの識別子を見つけて、次のように記述します。

 select Emp.* from [dvtable_{DBC8AE9D-C1D2-4D5E-978B-339D22B32482}] Emp join [dvtable_{7473F07F-11ED-4762-9F1E-7FF10808DDD1}] Company ON Emp.ParentRowID = Company.RowID where Company.Name = 'Test'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、従業員セクションが部門セクションの子会社であるという事実を使用しました。 ここで、テストユニットとそのすべての子（ツリー内）ユニットを表示してみましょう。

 ;WITH Companies (RowID, ParentTreeRowID, Name) AS ( SELECT Company.RowID, Company.ParentTreeRowID, Company.Name FROM [dvtable_{7473F07F-11ED-4762-9F1E-7FF10808DDD1}] Company WHERE Company.Name = 'Test' UNION ALL SELECT Company.RowID, Company.ParentTreeRowID, Company.Name FROM [dvtable_{7473F07F-11ED-4762-9F1E-7FF10808DDD1}] Company JOIN Companies ON Company.ParentTreeRowID = Companies.RowID ) SELECT RowID, ParentTreeRowID, Name FROM Companies
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、ユニットセクションが木製のセクションであるという事実を使用しました。

パート2.メタデータについてもう少し

カードのメタデータを含むXMLは、プラットフォームライブラリのVersionedFileカードのメタデータを含むxmlファイルです。







メタデータは、基本的にカードインスタンスのタイプ定義です。 多くの場合、データベース内のメタデータとカードのインスタンスはカードと呼ばれ、やや混乱します。 メタデータについて話すとき、カードは常にカードの種類を意味し、カード識別子はカードの種類識別子を意味します。

メタデータは、カードの名前と識別子、その属性、およびセクションツリーを定義します。 セクションごとに、セクションの名前と識別子、その属性とフィールドが設定されます。 各フィールドについて、フィールドの名前と識別子、およびそのタイプが指定されます。

カードの属性の中で、まず第一に、カードが参考書であるかどうかに関与する属性に注目する価値があります。 セクションの属性の中で、最も重要な属性はセクションのタイプ（コレクション、木製、または構造体タイプ）です。

子セクションは、xmlファイルで次のように定義されます。 要素には子要素があり、子セクションの要素が指定されています。 子セクションには、子セクションもあります。 したがって、セクションのツリーは判明します。

CardManagerユーティリティ

Docsvisionは、CardManagerの開発者がメタデータを操作するためのユーティリティを使用します。 このユーティリティを使用すると、メタデータカードの作成と編集を自動化できます。





スクリーンショットは、Backofficeライブラリが開いているCardManagerユーティリティを示しています。





スクリーンショットは、Backofficeライブラリのスタッフ参照のメタデータを示しています。 AlternativeHierarchy木製セクションは、ユーザーグループを保存するために開いています。 GroupおよびGrpViewFieldsの子セクション、Name、Comments、AccountNameなどが表示されます。

パート3.参照

フィールドには、文字列へのリンク（refid）やカードのインスタンスへのリンク（refcardid）など、さまざまなタイプがあります。

ROWID	マイリファレンス
ROWID	Id1

ROWID	...
Id1	...

行へのリンクの場合、この行が参照する行の識別子は表のセルで参照します。 しかし、この識別子で行を検索するのはどのテーブルですか？ これは、リンクを保存するためのフィールドのメタデータによって決定されます（図の場合、MyReferenceフィールドのメタデータによって決定されます）。

カードへのリンクを保存する場合、[dbo]。[Dvsys_instances]テーブルのInstanceIDカードインスタンス識別子がテーブルセルに書き込まれます。 メタデータは、リンクが保存されているカードのタイプを示します。

ROWID	MyCardReference
ROWID	Id1

InstanceID	CardTypeID	...
Id1	タイプID	...

リンクタイプハード、ウィーク、オート

カードへのリンクには、ハード、弱い、自動のタイプがあります。

ハード 、またはハードリンクは、次のことを意味します。カードへの最後のハードリンクが削除されると、カードが削除されます。

弱い 、または弱いリンクは、カードの取り外しには影響しません。

自動 -自動リンクはカードの削除にも影響しませんが、カードを削除すると、リンク自体がリセットされます。

テーブル[dbo]。[Dvsys_links]

リンクを保存するには、[dbo]。[Dvsys_links]テーブルを使用します。 このテーブルは、異なるセクションテーブルに散在するリンク情報をまとめます。 テーブルへのレコードの追加/削除は、セクションフィールドで機能する同じストアドプロシージャを提供するため、ここでは非同期は発生しません。



この表には、次の有用な列があります。

• RowID-参照する行
• FieldID-リンクの値を保存するためのフィールドのタイプの識別子
• SourceCardID-参照するカードのインスタンスの識別子
• DestinationTypeID-参照するカードのインスタンスの識別子
• タイプ-リンクのタイプ

リンクとは何ですか？

リンクにより、カードは再利用可能なコンポーネントになります。 たとえば、作成するカードにバージョン管理をサポートするファイルのコレクションを含める場合は、BackofficeシステムライブラリのFileListカードへのリンクを含むフィールドを作成します。

パート4.システムテーブルとライブラリ

基本的なシステムテーブル

[dbo]。[dvsys_globalinfo]-テーブルには、Docsvisionデータベースのバージョンに関する情報が含まれます。 このテーブルには、データベースの現在のバージョンを含む有用なバージョンフィールドがあります。

データベースのバージョンに対応するようにすべてのライブラリのバージョンを更新する必要がある場合がありますが、データベースに新しいバージョンのライブラリをロードする気はありません。 これを行うには、次の方法があります：[dbo]。[Dvsys_globalinfo]のバージョンを見てから、ストアドプロシージャを呼び出します。

 exec [dbo].[dvsys_help_set_version] @Version =  
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

メタデータテーブル：

• [dbo]。[dvsys_libraries]-インストールされているカードライブラリに関する情報
• [dbo]。[dvsys_carddefs]-インストールされているカードに関する情報
• [dbo]。[dvsys_sectiondefs]-セクション情報
• [dbo]。[dvsys_fielddefs]-フィールド情報

その他の重要な表

• [dbo]。[dvsys_instances]カードインスタンスのテーブル
• [dbo]。[dvsys_links]リンクテーブル
• [dbo]。[dvsys_locks]ロックテーブル
• [dbo]。[dvsys_security]セキュリティ
• [dbo]。[dvsys_crypto]暗号オブジェクト
• [dbo]。[dvsys_log]、[dbo]。[dvsys_log_application]、[dbo]。[dvsys_log_security]ログテーブル

ファイルを保存するには、2つのテーブルが重要です。

• [dbo] .dvsys_files
• [dbo] .dvsys_binaries

dvsys_filesテーブルにはファイルに関する情報が格納され、dvsys_binariesにはその内容が含まれます。

また、カードフィールドにはfileIdタイプがあることに言及することも重要です。 このタイプのフィールドには、dvsys_filesテーブルのファイル識別子が格納されます。

プラットフォームライブラリ

フォルダーのディレクトリ

Docsvision Navigatorを開いた場合、最初に目にしたのは、フォルダーツリーと、フォルダーに含まれるカードを表示するグリッドです。 実際、フォルダーにはカード自体は含まれていませんが、ラベルが付いています。



フォルダディレクトリは、プラットフォームライブラリのFoldersCardディレクトリであり、フォルダに関する情報と、フォルダ内にあるカードのラベルを保存します。 フォルダは木製のフォルダセクションに保存されます。



ショートカットは、ショートカットセクションの子セクションに保存されます。 このセクションには、HardCardIDおよびCardIDフィールドがあります。 それと別のフィールドの両方は、カードへのリンクです。 唯一の違いは、HardCardIDフィールドがハードリンクであり、CardIDがAutoタイプのリンクであることです。 したがって、同じカードのラベルは別のフォルダに配置でき、ハードリンクのある最後のラベルが削除されると、カードは削除されます。



フォルダーには、通常のフォルダー、仮想フォルダー、デリゲートフォルダー、およびシステムフォルダーの種類があります。 仮想フォルダーは、検索クエリを使用してその中のラベルに関する情報を返すという点で異なります。 デリゲートフォルダーは、基本的に他のフォルダーへのポインターです。 システムフォルダー-通常、検索結果のフォルダーやフォルダー「バスケット」などの特別なフォルダー。 多くのシステムフォルダーはユーザーには見えません。 次のようなシステムフォルダーを表示できます。

 select Name from [dbo].[dvtable_{FE27631D-EEEA-4E2E-A04C-D4351282FB55}] Folders where [Type] = 16 -- System
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

バージョンファイルカード

プラットフォームライブラリにはVersionedFileカードがあります。 このカードは、単一のファイルの複数のバージョンを保存する必要がある場合に使用すると便利です。 カードには木製セクションのバージョンがあり、ファイルのバージョンのツリーを保存できます。 [バージョン]セクションには、ファイルへのリンクが保存されているfileID型のFileIDフィールドがあります。 MainInfoセクションには、最新と見なされるバージョンへのリンクを含む有用なCurrentIDフィールド（refid型）があります。



ナンバリングカード

ナンバリングカードは、ドキュメントや他のカードに番号を発行するために使用されます。



保存済みビューカード

このカードは、ユーザービュー（Docsvision Navigatorグリッドに表示されるビュー）に関する情報を保存するために使用されます。



保存済み検索カード

このカードは、ユーザー検索クエリに関する情報を保存するために使用されます。

バックオフィスライブラリ

種リファレンス

Backofficeライブラリの作成者は、カードのタイプへの分離が不十分であると見なし、ビューを追加してライブラリ内のカードのタイプを明確にすることにしました。 文書があり、着信文書があるとしましょう-これは一種の文書です。 ビューには、その機能の一部を継承する子ビューと、独自の機能を持つ子ビューを含めることができます。 そして、種の木は判明しました。 これらの種はすべて、種ディレクトリに保存されます。



ドキュメントカード、タスク、タスクグループ、調整

これらは、Docsvisionシステムの主要なワーキングカードです。 これらは、ワークフローの主要なエンティティに対応しています。 多数の異なるサービスを提供し、さまざまなシナリオに参加します。



状態参照

状態ディレクトリには、状態カードの状態マシンが格納されます。 状態から状態に移行すると、操作が実行されます。



ロール参照

役割ディレクトリには、役割のセキュリティ情報が格納されます。 実際、これは役割-状態-利用可能な操作の3次元マトリックスです。 ディレクトリのUIを使用すると、この3次元マトリックスのセクションを表示できます。



マークアップ参照

マークアップディレクトリで、カードの外観をカスタマイズし、コントロールをカードに追加し、イベントにサブスクライブし、動的フィールドを定義して、コントロールに関連付けることができます。



スクリプト参照

スクリプトのディレクトリを使用すると、カード用のカードスクリプトを作成できます。



従業員名簿

従業員ディレクトリには、従業員とユニット、およびグループとロールが格納されます。



取引先ディレクトリ

取引先ディレクトリには、組織と従業員-取引先が格納されます。

パート5.検索および送信サブシステム

検索と提出は、互いにそれほど違いはありません。 主なアイデア：UIを使用するか、コードを使用して検索/プレゼンテーションの説明を作成します。 この説明に従って、サーバーは、結果を含む選択を返すストアドプロシージャを生成します。 検索の説明は検索クエリディレクトリに保存され、ビューは保存されたビューディレクトリに保存されます。 検索/ビューには、再度呼び出すときに既存のストアドプロシージャを呼び出すための識別子が必要です。これはパフォーマンスに影響します。



ビューとは、ユーザーがナビゲータグリッドに表示するものです。 まず、デフォルトで使用されるシステムビュー（ダイジェスト）があります。 通常のプレゼンテーションとページごとのプレゼンテーション（いわゆるキーセットビュー）も異なります。 ビューは、データソースとして通常のフォルダー、検索結果、またはその他のものを使用できます。 検索とビューは、ユーザーがUIを介して、またはプログラムによって、呼び出し時に設定されるパラメーターをサポートします。 パラメーターとして、検索語を設定できます（I、Today、My alternates、および他の多く）。 収集可能なパラメーターが許可されます。



検索とビューの定義は、本質的にxml構文を持つ小さな言語であり、この言語は多くの異なる機能をサポートしています。 サーバーでストアドプロシージャを生成するシステムは、XmlからSqlへの変換プログラムです。



検索サブシステムは、2種類の検索- 限定的検索と全文検索をサポートしています 。 全文検索では、特定の文字列を含むカードまたはファイルを検索できます。 属性検索により、表示されているカードのフィールドの値に条件を課すことができます。 フィールド値の条件では、フィールドのタイプに応じて、等しい、等しくない、より大きい、より小さいなどの演算を使用できます。 ANDまたはORを使用して条件を組み合わせることができます。 したがって、条件ツリーが取得されます。 ストアドプロシージャが生成されるとき、WHEREの条件はそれらによって生成されます。



表現も同様のアプローチを使用します。一般的な場合、それらもすべてのカードを表示するべきではないためです。 検索とは異なり、ビューはいわゆる計算フィールドをサポートします。 計算フィールドの生成は、ストアドプロシージャの選択結果のSELECTステートメントのリストに別の式を追加することと考えることができます。 計算フィールドの式は、条件ツリーの式に似ています。 実際、これは同じツリーであり、比較演算の代わりに、算術演算とCASE WHEN式（C＃のスイッチに似ています）を使用することがほとんどです。



簡単にするために、表現のサンプリングスキームは次のように表すことができます。

 SELECT     FROM   JOIN    WHERE 
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際、もちろん、すべてがより複雑です。 まず、ビューにはそのような選択が1つではなく複数含まれている場合があり、これらのサンプルはUNION ALLを使用して結合されます。 これは、さまざまなタイプのカードを1つのビューに表示するのに役立ちます。 次に、ページビューでは、データベースからすべてのページのすべてのデータを読み取るとパフォーマンスが大幅に低下するため、ジェネレーターは適切な魔法を使用し、1つのサンプルから複数のストアドプロシージャを生成します。



表現は、集計、連結、木製セクションの開示など、高度な機能も提供します。 ビューのソートがサポートされています。 そして、グループ化はすでにクライアントで行われています。



より詳細な検索および表示モデルは、今後の記事の1つで検討できます。基本情報はこのブロックに表示されます。