Name: executing complexity-increasing queries in relational (mysql) and nosql (mongodb and exist) size-growing iso/en 13606 standardized ehr databases
Uploaded: 2018-03-19T14:30:00
Duration: 7 min 26 s
Description: Watch this Scientific Journal Video about Executing Complexity-Increasing Queries in Relational MySQL and NoSQL MongoDB and EXist Size-Growing ISO/EN 13606 Standardized EHR Databases at JoVE.com

著者は、博士 Dipak Kalra、ISO/EN 13606 標準と ISO/EN 13606 W3C XML スキーマを使用するそのような許可の大学大学ロンドンから彼のチームを定義する EHRCom タスクフォースのリーダーに感謝したいと思います。
この作品は、セルバンテス ・ デ ・によって支えられたサラッド カルロス 3 世 [許可番号 RD16CIII、PI15CIII/00010 PI1500831 PI15/00003 PI15/00321]。

1. 3 つの二重大きさで分類された標準化された EHR 抽出データベースを格納するリレーショナル MySQL DBMS を構築します。
<ol><li>インポート、W3C (ワールド ・ ワイド ・ ウェブ ・ コンソーシアム) XML スキーマ、'Java IDE' (統合開発環境) に ISO/EN13606 RM と ISO21090 データ型に対応します。 注: ISO は、国際標準化機構の略です。EN は、欧州統一規格の略です。</li>
	<li>JAXB (Java XML バインディング) IDE にプラグインを実行します。これは、EHR エキス XML ファイルの要素の構造に対応する Java クラスを生成します。</li>
	<li>JPA ラベルで生成される Java クラスを手動でタグ付けします。これらのラベルは、基数と MySQL データベースのリレーショナル テーブルの間の他の関係を参照してください。</li>
	<li>JPA (Java の永続性 API) のライブラリを IDE にインポートし、タグの Java クラスからのMySQLデータベースを作成するメソッドを実行します。</li>
	<li>XML ファイル、5,000、10,000、20,000 の現実的な EHR エキスと 3 つのディレクトリを作成します。</li>
	<li>5,000 抽出ディレクトリの抽出物すべての MySQL DBMS に XML の抜粋をロードする JPA メソッドを実行します。</li>
	<li>10,000 抽出ディレクトリと一度と 20,000 抽出ディレクトリ 1.6 のステップを 2 回、繰り返します。</li>
</ol>2. 3 つの二重大きさで分類された標準化された EHR 抽出データベースを格納するために NoSQL MongoDB DBMS を構築します。
<ol><li>プロセスごとの 5,000、10,000、20,000 現実的な EHR エキス XML ファイルを含む json.org.XML などの JSON ファイルを XML ファイルに変換する標準のプログラムと 3 つのディレクトリ。5,000、10,000、20,000 の JSON ファイルを 3 つのディレクトリを生成する必要があります。</li>
	<li>MongoDB の GUI を起動 (グラフィック ユーザー インターフェイス、材料表を参照してください)。</li>
	<li>MongoDB 2.6サーバー DOS (ディスク ・ オペレーティング ・ システム) システム ウィンドウからmongodプログラムを実行するを起動します。</li>
	<li>MongoDB GUI をポート 27017 を使用してローカル ホスト サーバーに接続します。<ol>
<li>「接続」メニューを選択します。</li>
		<li>接続の名前を書く (例えば ' 最初')。</li>
		<li>DB サーバー テキスト ボックスに localhost:27017 を記述します。</li>
		<li>「接続」ボタンを押す現在のデータベースを持つツリーが左側に表示されます。</li>
	</ol>
</li>
	<li>エキス 5,000 標準化された電子カルテを含むデータベースを構築します。<ol>
<li>左側のツリーの上部に接続の名前をクリックします。</li>
		<li>「ファイル」メニューを選択します。</li>
		<li>「データベースを追加」を選択します。</li>
		<li>表示されるダイアログ ボックスにデータベースの名前を入力します。</li>
		<li>[Ok] を。</li>
	</ol>
</li>
	<li>5,000 の標準化された電子カルテを含むコレクションの抽出物を構築します。<ol>
<li>左側のツリーに、データベースの名前をクリックします。</li>
		<li>メニューの「データベース」を選択します。</li>
		<li>「AddCollection」を選択します。</li>
		<li>表示されるダイアログ ボックスにコレクションの名前を入力します。</li>
		<li>「作成」をクリックしてします。</li>
		<li>コレクションの名前をクリックします。</li>
		<li>「インポート」メニューを選択します。</li>
		<li>ラジオ ボタンを選択するには 'JSON - mongo シェル//mongoexport」。</li>
		<li>「次へ」をクリックします。</li>
		<li>「ソース ファイルの追加」ボタンを押します。</li>
		<li>ダイアログ ボックスを使用してコンピューターに移動します。</li>
		<li>オープン 5,000 JSON を含むディレクトリは、ファイルを抽出します。</li>
		<li>ディレクトリ内のすべてのファイルを選択します。</li>
		<li>「開く」を押します。インポート ダイアログでは、JSON ファイルの一覧が表示されます。</li>
		<li>押して"次へ";データベースに新しいコレクションのプレビューは左側に表示されます。</li>
		<li>「次へ」を押します。</li>
		<li>「インポートの開始」を押します。インポートの進行状況は、インポートされたファイルと経過時間の数を示す、左にダウン表示されます。</li>
	</ol>
</li>
	<li>手順 5 とエキス 10,000 標準化された EHR のコレクションを構築する 6 を繰り返します。</li>
	<li>手順 5 と 20,000 の標準化された EHR のコレクションの抽出物を構築する 6 を繰り返します。</li>
</ol>3. ビルド、NoSQL ストア 3 ダブル サイズ標準化電子カルテ抽出データベースを DBMS が存在します。
<ol><li>存在するデータベースを起動します。</li>
	<li>データベースのアイコンを使用して、管理者クライアントを開きます。</li>
	<li>管理者パスワードを入力します。</li>
	<li>「接続」ボタンを押します。</li>
	<li>5,000 の標準化された電子カルテを含むコレクションの抽出物を構築します。<ol>
<li>ツールバー、メニューの「新しいコレクションを作成する」を選択します。</li>
		<li>表示されるダイアログで、新しいコレクションの名前を入力します。</li>
		<li>「受け入れる」をクリックします。新しいコレクションが表示されます。</li>
		<li>コレクションの名前を選択します。</li>
		<li>ツールバーのメニュー「データベース ストア ファイル」を選択します。</li>
		<li>ダイアログ ボックスを使用してコンピューターに移動します。</li>
		<li>5,000 の標準化された XML 抽出ファイルを含むディレクトリを選択します。</li>
		<li>「ファイルを保存するディレクトリを選択」ボタンをクリックします。進行状況、格納されているファイルの表示と作成されるデータベースの割合] ダイアログ ボックスが表示されることに注意してください。</li>
	</ol>
</li>
	<li>10,000 の標準化された電子カルテを含むコレクションの抽出物を構築する 5 の手順を繰り返します。</li>
	<li>20,000 の標準化された電子カルテを含むコレクションの抽出物を構築する 5 の手順を繰り返します。</li>
</ol>4 設計および 3 のリレーショナル データベースに 6 複雑さ増加クエリを実行
<ol><li>EHR の抽出で使用される原型に従って 6 複雑さ増加クエリをデザインします。</li>
	<li>MySQL のデータベースの最初のクエリで SQL スクリプトをプログラムします。SQL は、標準化エキス (アーキタイプ) により、MySQL データベースの特殊な構造に適応しなければなりません。データベース抽出物の全体の構造にマップします。結果として、SQL クエリは複雑です。</li>
	<li>ほとんどのインデックスは、DBMS によって自動的に構築されますが、インデックスはその上に構築された場合、クエリの応答時間をスピードアップし、そのようなインデックスを作成するデータベースの属性を識別します。</li>
	<li>クエリは、非自動的に構築したインデックスを必要とする場合は、手動でビルドします。<ol>
<li>MySQL サーバ (補足図 1) に接続します。</li>
		<li>選択し、左側のデータベース名をクリックします。</li>
		<li>選択し、インデックス付きのフィールドが格納されているリレーショナル テーブルの上をクリックします。</li>
		<li>「構造」のタブをクリックしてします。</li>
		<li>選択し、列をインデックスの作成場所をクリックします。</li>
		<li>「インデックス」をクリックしてします。インデックスを構築する SQL 文が表示されます、その文が正常にビルドされたことを示すメッセージが表示されますに注意してください。</li>
	</ol>
</li>
	<li>最初のクエリを実行します。<ol>
<li>選択し、左側のデータベース名をクリックします。</li>
		<li>"SQL"タブをクリックします。</li>
		<li>書き込みまたは、最初のクエリの SQL コードを貼り付けます (補足図 2を参照)。</li>
		<li>「続行」を押します。クエリの実行時間をメッセージと共に結果のリストの最初の画面が表示されることに注意してください。</li>
		<li>5 回実行を繰り返し、平均応答時間を計算します。</li>
	</ol>
</li>
	<li>クエリ 2 6 からで、手順 5 を繰り返します。</li>
	<li>5,000、10,000、20,000 抽出データベースで 3 回の全体のプロセスを行います。</li>
</ol>5. 設計し、3 の NoSQL MongoDB データベースに 6 複雑さ増加クエリを実行
<ol><li>MongoDB の GUI を起動 (材料の表を参照してください)。</li>
	<li>DOS システム ウィンドウからmongodプログラムを実行 2.6 MongoDB サーバーを起動 (補足の図 3を参照)。</li>
	<li>2.4 MongoDB GUI をポート 27017 を使用してローカル ホスト サーバーに接続するための手順に従ってください。</li>
	<li>選択し、左側の MongoDB データベースを展開します。</li>
	<li>コレクションを選択します。</li>
	<li>ツールバーの「コレクション」メニューをクリックします。</li>
	<li>最初の MongoDB クエリを実行します。<ol>
<li>「クエリービルダー」ボタンをダブルクリックします。</li>
		<li>右側にあるクエリ ビルダーの「クエリ フィールド」をダブルクリックします。</li>
		<li>クエリ パネル (補足図 4を参照) のフィールドのテキスト ボックスで MongoDB クエリのフィールドを記述します。</li>
		<li>クエリ パネルの値] テキスト ボックスに、MongoDB クエリの値を書き込みます。 注: このクエリは、{"ns3:EHRExtract.allCompositions.content.items.parts.parts.name.ns2:originalText のような何かをする必要があります.値":"Descripcion"}。フィールド、値を引用し、セミコロンで区切られました。</li>
		<li>クエリ ビルダーの [投影] フィールドをダブルクリックします</li>
		<li>投影のテキスト ボックスに最初の投影を書く (補足図 5を参照)。</li>
		<li>新しい投影 textbox を追加する投影フィールドをダブルクリックします。</li>
		<li>投影テキスト ボックスで 2 番目の投影を記述します。 注: 投影は、クエリから取得された文書の一部を選択します。これらは {"ns3:EHRExtract のような何かをする必要があります.allCompositions.content.items.parts.parts.value.value": 1} と {"ns3: EHRExtract.all Compositions.content.items.parts.parts.value.nullFlavor": 1}</li>
		<li>クエリ実行のための青い再生ボタンをクリックします。</li>
		<li>[クエリ] タブでクエリのコードを視覚化します。</li>
		<li>[説明] タブで、結果の詳細を表示: 結果の数、実行時間 (ミリ秒)。</li>
		<li>表示、展開、および [結果] タブに結果を調べます。</li>
		<li>クエリの処理が必要な場合は、結果を処理すると、クエリとメソッド MongoDB Java ドライバーと Java プログラムを記述します。</li>
		<li>5 回実行を繰り返し、平均応答時間を計算します。</li>
	</ol>
</li>
	<li>5.7 6 クエリを通じて残りの 2 ステップを実行します。</li>
	<li>MongoDB データベースを抽出、5,000、10,000、20,000 で全体のプロセスを繰り返します。</li>
</ol>6. 設計および 3 で実行 NoSQL データベース 6 増加複雑なクエリが存在します。
<ol><li>存在するDBMS を起動します。</li>
	<li>Java 管理者クライアントを開きます。</li>
	<li>「データベースに接続」ボタンを押します。</li>
	<li>データベースを選択し、それをクリックします。</li>
	<li>「XPath を使用してください。、データベースを参照してください」メニューをクリックして[参照] ダイアログ ボックスが表示されます。</li>
	<li>最初のXPath クエリの実行 (補足図 6を参照)。<ol>
<li>書き込みまたは、最初のクエリの XPath コード] ダイアログ ボックスの上部に貼り付けます。</li>
		<li>ダイアログ ボックスのツールバーのメニューの「実行」をクリックします。</li>
		<li>ダイアログ ボックスの下部に「XML」タブを使用して、XML 結果を表示します。</li>
		<li>結果とコンパイルおよび実行時間] ダイアログ ボックスの下部での数を表示します。</li>
		<li>5 回実行を繰り返し、平均応答時間を計算します。</li>
	</ol>
</li>
	<li>クエリ 2 6 からの手順 6 を繰り返します。</li>
	<li>全体のプロセスを行うと、5,000、10,000、20,000 抽出データベースが存在するため、3 回。</li>
</ol>7. 設計し、MySQL および 5,000 抽出データベースの MongoDB を使用して同時実行制御実験を実行
注: 存在するデータベースは、以前の実験でパフォーマンスが悪いためこの時点で実験から削除されました。
<ol><li>(数秒) の下で通常 5,000 抽出データベースを使用する前の実験で 3 つの最短時間応答をクエリを選択します。</li>
	<li>識別し、必要に応じて手動でこれらのクエリの適切な属性インデックスを構築します。</li>
	<li>MySQL 用と MongoDB; の Java マルチ スレッド アプリケーションのプログラミング 2各アプリケーションには、3 つの優先順位が異なるスレッドを手順 1 で選択した各クエリの 1 つがあります。</li>
	<li>実行し、 CPU (中央処理装置)分布を使用して各スレッド (クエリ) を計算します。</li>
	<li>各 10 分間に 5 回実行ボタンをクリックしてごとのマルチ スレッド アプリケーションを実行し、最も実行 (最高優先順位) を計算平均スループットと 3 つのクエリの平均時間応答をクエリします。</li>
	<li>優先順位と実行時間、実行中のクエリを表示します。</li>
	<li>平均スループットと各 3 つのクエリの平均応答時間を計算します。</li>
</ol>

<ol>
	<li>Codd, E. F. <a target="_blank" href="http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=PubMed&cmd=Search&doptcmdl=Citation&defaultField=Title+Word&term=A+relational+model+for+large+shared+data+banks.">A relational model for large shared data banks.</a> Comm ACM. 13 (6), 377-387 (1970).</li><li>Kalra, D., Lloyd, D. <a target="_blank" href="http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=PubMed&cmd=Search&doptcmdl=Citation&defaultField=Title+Word&term=.">.</a> ISO 13606 electronic health record communication part 1: reference model. , (2008).</li><li>Kalra, D., et al. <a target="_blank" href="http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=PubMed&cmd=Search&doptcmdl=Citation&defaultField=Title+Word&term=.">.</a> Electronic health record communication part 2: archetype interchange specification. , (2008).</li><li>Kalra, D., Beale, T., Heard, S. <a target="_blank" href="http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=PubMed&cmd=Search&doptcmdl=Citation&defaultField=Title+Word&term=The+openEHR+foundation.">The openEHR foundation.</a> Stud. Health Technol. Inform. 115, 153-173 (2005).</li><li>Beale, T. <a target="_blank" href="http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=PubMed&cmd=Search&doptcmdl=Citation&defaultField=Title+Word&term=Archetypes:+constraint-based+domain+models+for+future+proof+information+systems.">Archetypes: constraint-based domain models for future proof information systems.</a> OOPSLA, Workshop Behav Semant. , (2002).</li><li>S&#225;nchez-de-Madariaga, R., et al. <a target="_blank" href="http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=PubMed&cmd=Search&doptcmdl=Citation&defaultField=Title+Word&term=Examining+database+persistence+of+ISO/EN+13606+standardized+electronic+health+record+extracts:+relational+vs.+NoSQL+approaches.">Examining database persistence of ISO/EN 13606 standardized electronic health record extracts: relational vs. NoSQL approaches.</a> BMC Medical Informatics and Decision Making. 32 (2), 493-503 (2017).</li><li>Ireland, C., Bowers, D., Newton, M., Waugh, K. <a target="_blank" href="http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=PubMed&cmd=Search&doptcmdl=Citation&defaultField=Title+Word&term=Understanding+object-relational+mapping:+a+framework+based+approach.">Understanding object-relational mapping: a framework based approach.</a> Int. J. Adv. Softw. 2, 202-216 (2009).</li><li>. Node+Path Persistence Available from: <a target="_blank" href="https://openehr.atlassian.net/wiki/spaces/dev/pages/6553626/Node+Path+Persistence">https://openehr.atlassian.net/wiki/spaces/dev/pages/6553626/Node+Path+Persistence</a> (2017)</li><li>Wang, L., Min, L., Wang, R., et al. <a target="_blank" href="http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=PubMed&cmd=Search&doptcmdl=Citation&defaultField=Title+Word&term=Archetype+relational+mapping+-+a+practical+openEHR+persistence+solution.">Archetype relational mapping - a practical openEHR persistence solution.</a> BMC Medical Informatics and Decision Making. 15, 88 (2015).</li><li>Kaur, K., Rani, R. <a target="_blank" href="http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=PubMed&cmd=Search&doptcmdl=Citation&defaultField=Title+Word&term=Managing+data+in+healthcare+information+systems:+many+models,+one+solution.">Managing data in healthcare information systems: many models, one solution.</a> Computer. March. , 52-59 (2015).</li><li>Sabo, C., Pop, P. C., Valean, H., Danciulescu, D. <a target="_blank" href="http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=PubMed&cmd=Search&doptcmdl=Citation&defaultField=Title+Word&term=An+innovative+approach+to+manage+heterogeneous+information+using+relational+database+systems.">An innovative approach to manage heterogeneous information using relational database systems.</a> Advances in Intelligent Systems and Computing. 557, (2017).</li></ol>

著者が明らかに何もありません。これらの実験で使用されるデータセットはこれらの実験のライセンスの下でいくつかのスペインの病院によって提供され、その結果は公にご利用いただけません。ISO/EN 13606 RM XML スキーマは、医療情報部 Multiprofessional 教育 (チャイム) の大学大学ロンドン中心部によって提供されました。

このプロトコルを示します、純粋なリレーショナル ORM システムそうにない単一患者クエリ (Q1、Q3、および Q4) の実用的な応答時間が遅く、おそらくのために多くの高価な結合操作を実行するリレーショナル テーブルのために数が多いので、ストレージ ・ システムは、特定の種類のデータベースで使用されます。NoSQL データベースは、リレーショナル システムを使用して、各ドキュメント全体のデータベース全体に広がるテーブル ベースのファッション間ドキュメント ベースの方法でデータを保存します。NoSQL システムは、DBMS の存在よりもかなり速く実行する MongoDB を線形勾配を示します。同時実行制御、MongoDB も動作リレーショナル MySQL ORM7よりはるかに良い。
このプロトコルは、ORM MySQL DBMS に関する7で示された結果のトラブルシューティング プロトコルを提示します。MySQL システムが最新のバージョンにアップデートされて、結果が若干変更されています。さらに、ドキュメント ベースの NoSQL システムの臨界点 MongoDB は EHR エキスが更新されたときは上書きされません、ために医療情報7を保存することが、全体を新しい新しいデータを抽出するときの一貫性を保つことができる彼らのようです。生成され、システムに格納されている元の抽出は維持されます。いくつかの医療専門家は、元のデータに基づいて重要な医療決定をした可能性がありますので、これは、医療情報の厳格な要件です。
改良されたリレーショナル アーム システムは大幅にリレーショナル テーブルの数を減少する、リレーショナル パフォーマンスが向上します。リレーショナル スキーマ修飾するので抽出物が保有する医療情報のクエリを実行可能性があります、しかし、抽出物は正確な原型では復元できません。
二次非常に大規模なデータベース (研究) を使用して、データベース システムがより適切なのですべて患者クエリ (Q2、Q5) は NoSQL システムでより ORM でより良い動作は不明だが、これらのシステムをより簡略化した実行リレーショナル12のシステム。Q6 ・臨床実習の間に特殊なクエリを使用して、これらの実験で得られた結果によって行動を決定できないと考えています。
ただし、メソッドの制限の 1 つは直接実験プロトコルで使用されている正確に同じデータを持つ単一患者、医療クエリに関する NoSQL MongoDB を改良されたリレーショナル アーム システムを比較することの少ないです。プロトコルに最適化された ARM を含む実験を行ったまで単一患者クエリについて表 3 表 5の補間結果を維持しています。将来のアプリケーションこれらの実験にしておきます。プロトコル内で 1 つの重要なステップは、我々 は、正確な状態の-最新鋭の 3 つの技術を比較可能性があるために、無料データベースで、近年の同様のソフトウェア バージョンの選択です。
これは NoSQL システム実際、現実的な標準化された医療情報を使用して、リレーショナルを直接比較する最初の試みの 1 つです。ただし、使用する特定のシステムは、実際のシナリオと問題を解決8によって大いに決まります。

NoSQL (SQL だけでなく) DBMS は伝統的なリレーショナル DBMS (RDMBS) に代わるものとして最近浮上しています。RDBMS では、何十年もデータベース システムにデータが保存された方法を支配しています。よく研究、理解のリレーショナル代数と微積分は、効率と RDBMS1の一貫性を保証しています。NoSQL システム、リレーショナル システムでは、代わりになっていないが、特定のシナリオでは、いくつかの条件の下で、彼らが有利に動作します。
いくつかのこれらの特定のシナリオや条件が管理および医療情報を保存するために使用する電子健康記録 (EHR) システムのデータベースの永続性を設計するときに発生します。相互運用性と実際には、いくつかの国際基準 ISO/EN 13606、openEHR、HL72,3、4などの持続可能なをするためには、EHR エキスを標準化する,5を使用されています。
ISO/EN 13606 openEHR などいくつかの基準が 2 つの異なるレベルの抽象化は、参照モデル (RM) によって表されると原型と呼ばれる特殊なデータ構造に情報や知識を分離します。この分離はデュアル モデルを呼ばれ、それにより、EHR システム全体の電子カルテ システムをプログラムし直すことがなく、その結果に進化する意味的相互運用性と医療の知識を保守と実践6 で持続可能な.ただし、標準化された電子カルテ システムで実装されているデュアル モデルには、特定の構造に続く情報の組織化、これは、システムのデータベースの永続性レベルが設計された7方法の深遠な影響が必要です。
オブジェクト リレーショナル マッピング (ORM)8はリレーショナル データベース パラダイムを使用した電子カルテ システムを実装する 1 つの方法です。ORM は、余すところなくリレーショナル データベース システムで使用される標準化された EHR エキス XML (拡張マークアップ言語) ファイルの構造をマップします。ORM は、余すところなく標準化された電子カルテの抽出物の XML ファイルの構造に続く多くのリレーショナル テーブルを構築します。多くの外部キーを介して関連するこれらのリレーショナル テーブルとシステムの結果は、非常に効率が悪くなります。
ORM リレーショナル改良がいくつか提案されている.openEHR のノード + パス9は、Blob (バイナリ ラージ オブジェクト) を XML ファイル全体のエキスのシリアル化のサブツリー、リレーショナル テーブルの数を減らします。しかし、この単純化は、複雑な検索ロジックは、複雑なクエリの損傷を発生します。原型リレーショナル マッピング (ARM)10は、原型、原型とリレーショナル テーブルのマッピングに基づいて新しいリレーショナル スキーマの構築によって駆動されるデータベース モデルを生成します。その結果、電子カルテの抽出物の非医療情報の一部が失われます。
多くのドキュメント ベースの NoSQL データベース元 XML や JSON (JavaScript オブジェクト表記) を尊重する全体の Blob としてドキュメント全体を格納形式。これは、リレーショナル テーブルは作成されませんを意味します。これらの NoSQL データベースはスキーマを持たず、結合または11(酸) のプロパティ、すなわち、原子性、整合性、分離、または耐久性をサポートしていません。結果として、彼らがありますない非常に効率的なドキュメントの要素の同じ要素を参照する場合、または間接リンクを利用したその他の文書。これは、一貫性を維持するために参照先のドキュメントの全体がある順番に処理されるために発生します。ただし、非リレーショナル データベースがまだ適切な DBMS によって実行される主なタスク ドキュメント ベースのタスクがある場合あります。これはもっと密接にドキュメント ベースの NoSQL データベースを使用して、真の形式の近似にこれはまた電子カルテ医療ドキュメント (ディスカッション セクション参照) には、特別な永続性ポリシーのため、フォームにデータが残る場合があります。
これらのメソッドの目的は、3 つの異なる Dbms を使用して標準化された電子カルテ システムの永続化層の実装を比較するいくつかの実験を紹介する: 1 つのリレーショナル (MySQL) と 2 つの NoSQL (MongoDB ドキュメント ベースおよびネイティブ XML が存在)。自分の計算がされている計算され、3 つの異なる増加規模のデータベースと六つの異なる複雑さ増加クエリを使用して比較します。3 つのデータベース サーバーをインストールし、クエリが実行された同じコンピューターにローカルで構成されています。技術的な詳細のための材料表を参照してください。
同時実行制御の実験は、リレーショナルの MySQL と NoSQL MongoDB Dbms のパフォーマンスを比較するために行われています。記載されている ORM 改善 (ノード + パスと腕) は、文学10から関連性の高い適切な結果を使用して比較されているも。
データベース管理システムは、加速率で継続的に進化しています。誰には、唯一の既存のパラダイムのリレーショナル モデル頃この指数の開発についてと思うでしょう。例を見て、参照してください、例えば12、酸の性質を保持した応答時間改善されたリレーショナル データベースを実装するモデルを提案します。

<table border="0" cellpadding="0" cellspacing="0" width="690">
	<tbody>
		<tr height="21">
			<td height="21" style="height:21px;width:216px;">MySQL 5.7.20</td>
			<td style="width:179px;"></td>
			<td style="width:128px;"></td>
			<td>MySQL experiments</td>
		</tr>
		<tr height="63">
			<td height="63" style="height:63px;width:216px;">Red Hat Enterprise Linux Server release 7.4 (Maipo), 2.60GHz, RAM 16GB</td>
			<td style="width:179px;"></td>
			<td style="width:128px;"></td>
			<td></td>
		</tr>
		<tr height="21">
			<td height="21" style="height:21px;width:216px;">MongoDB 2.6</td>
			<td style="width:179px;"></td>
			<td style="width:128px;"></td>
			<td>MongoDB experiments</td>
		</tr>
		<tr height="42">
			<td height="42" style="height:42px;width:216px;">Windows 7, 2.66GHz, RAM 12GB&#160;</td>
			<td style="width:179px;"></td>
			<td style="width:128px;"></td>
			<td></td>
		</tr>
		<tr height="21">
			<td height="21" style="height:21px;width:216px;">eXist 3.0RC1</td>
			<td style="width:179px;"></td>
			<td style="width:128px;"></td>
			<td>eXist experiments</td>
		</tr>
		<tr height="42">
			<td height="42" style="height:42px;width:216px;">Windows 7, 2.66GHz, RAM 12GB&#160;</td>
			<td style="width:179px;"></td>
			<td style="width:128px;"></td>
			<td></td>
		</tr>
		<tr height="21">
			<td height="21" style="height:21px;width:216px;">Studio 3T 5.5.1</td>
			<td style="width:179px;">3T Software Labs Gmbh</td>
			<td style="width:128px;"></td>
			<td>MongoDB GUI</td>
		</tr>
	</tbody>
</table>

executing complexity-increasing queries in relational (mysql) and nosql (mongodb and exist) size-growing iso/en 13606 standardized ehr databases

この研究を示してリレーショナル クエリの計算量を評価するためにプロトコルと非リレーショナル (NoSQL (だけでなく構造化照会言語)) 標準化電子健康記録 (EHR) 医療情報データベース システム (DBMS)。3 倍規模のデータベース、すなわち5000 を格納するデータベース、10,000 そして 20,000 人の現実的な標準化電子カルテの抽出物、3 つの別のデータベース管理システム (DBMS) でのセットを使用して: リレーショナル MySQL オブジェクト リレーショナル マッピング (ORM)NoSQL MongoDB ドキュメント ベースおよびネイティブ拡張マークアップ言語 (XML) の NoSQL の存在します。
6 複雑さ増加クエリの平均応答時間は、計算された、結果は、NoSQL の場合線形挙動を示した。NoSQL フィールドでは、MongoDB は存在より多くに平坦な線形勾配を表示します。
NoSQL システムは、一貫性と NoSQL データベースに格納されているデータの効率に影響する必要があります医療情報のアップデート ポリシーの特別な性質のための標準化された医療情報システムを維持するためにより適切な場合があります。
このプロトコルの制限の 1 つは、原型リレーショナル マッピング (ARM) 同じデータを持つなど改良されたリレーショナル システムの直接結果の欠如です。しかし、それらに 2 倍サイズのデータベース結果の補間は文献の提示、他の公開されている結果を NoSQL システムは多くの特定のシナリオと解決すべき問題より適切かもしれない示唆しています。たとえば、NoSQL は、臨床実習や版と可視化、または目的のだけではなく状況で使われている EHR 抽出クエリ医療情報もまさにその元の形式で電子カルテを復元するなどのドキュメント ベースのタスクの適切な可能性があります。

Watch this Scientific Journal Video about Executing Complexity-Increasing Queries in Relational MySQL and NoSQL MongoDB and EXist Size-Growing ISO/EN 13606 Standardized EHR Databases at JoVE.com

Executing Complexity-Increasing Queries in Relational MySQL and NoSQL MongoDB and EXist Size-Growing ISO/EN 13606 Standardized EHR Databases

本研究比較リレーショナルと非リレーショナル (NoSQL) は、医療情報システムを標準化します。このようなデータベース管理システム (DBMS) のクエリの応答時間の計算量が 2 倍規模のデータベースを使用して計算されます。これらの結果は、さまざまなシナリオや問題に各データベースのアプローチの妥当性の議論を助けます。

リレーショナル (MySQL) と NoSQL の複雑さ増加クエリの実行 (MongoDB 存在) ISO/EN 13606 標準化された電子カルテ データベースのサイズ増加

This research shows a protocol to assess the computational complexity of querying relational and non-relational (NoSQL (not only Structured Query ...

Research

Education

JoVE Core

JoVE Journal

Nursing

Medicine

Unit 1

Executing Complexity-Increasing Queries in Relational (MySQL) and NoSQL (MongoDB and EXist) Size-Growing ISO/EN 13606 Standardized EHR Databases

Documentation and Reporting

SCIENTISTS IN ACTION

Functional Assessment of Intestinal Motility and Gut Wall Inflammation in Rodents: Analyses in a Standardized Model of Intestinal Manipulation

げっ歯類における腸運動と腸壁の炎症の機能評価：腸管操作の標準化されたモデルで分析

Inflammation of the gastrointestinal tract is a common reason for a variety of human diseases. Animal research models are critical in investigating the ...

Lesion Explorer: A Video-guided, Standardized Protocol for Accurate and Reliable MRI-derived Volumetrics in Alzheimer's Disease and Normal Elderly

病変エクスプローラ：アルツハイマー病における正確で信頼性のMRI誘導Volumetrics用ビデオガイド下、標準化されたプロトコルおよび標準高齢者

Obtaining in vivo human brain tissue volumetrics from MRI is often complicated by various technical and biological issues. These challenges are ...

A Standardized Obstacle Course for Assessment of Visual Function in Ultra Low Vision and Artificial Vision

超低ビジョンと人工視覚における視覚機能の評価のための標準化された障害物コース

We describe an indoor, portable, standardized course that can be used to evaluate obstacle avoidance in persons who have ultralow vision. Six sighted ...

An Intramedullary Locking Nail for Standardized Fixation of Femur Osteotomies to Analyze Normal and Defective Bone Healing in Mice

マウスにおける正常および不良骨治癒を分析するために大腿骨骨切り術の標準化された固定用髄内ロッキングネイル

Bone healing models are essential to the development of new therapeutic strategies for clinical fracture treatment. Furthermore, mouse models are becoming ...

Standardized Technique of Aortic Valve Re-implantation for Valve-sparing Aortic Root Replacement

弁温存大動脈の大動脈弁再置換術の標準化された技術のルート交換

Despite the obvious advantages of the preservation of a normal aortic valve during aortic root replacement, the complexity of valve sparing procedures ...

Standardized Measurement of Nasal Membrane Transepithelial Potential Difference (NPD)

Standardized Measurement of Nasal Membrane Transepithelial Potential Difference NPD

鼻膜上皮電位差 (NPD) の標準化された測定

We describe a standardized measurement of nasal potential difference (NPD). In this technique, cystic fibrosis transmembrane conductance regulator (CFTR) ...

A Minimally Invasive Model to Analyze Endochondral Fracture Healing in Mice Under Standardized Biomechanical Conditions

癒しの標準化された生体力学的条件下でマウスの軟骨破壊を分析する低侵襲モデル

Bone healing models are necessary to analyze the complex mechanisms of fracture healing to improve clinical fracture treatment. During the last decade, an ...

Comparing Bibliometric Analysis Using PubMed, Scopus, and Web of Science Databases

PubMed、Scopus、および Web のサイエンス データベースを使用した書誌分析の比較

Literature databases (i.e., PubMed, Scopus, and Web of Science) differ in terms of their coverage, focus, and the tool they provide. PubMed focuses mainly ...

Standardized Hemorrhagic Shock Induction Guided by Cerebral Oximetry and Extended Hemodynamic Monitoring in Pigs

ブタの脳オキシメトリーと拡張血行力モニタリングによって導かれる標準化された出血性ショック誘導

Hemorrhagic shock ranks among the main reasons for severe injury-related death. The loss of circulatory volume and oxygen carriers can lead to an ...

Standardized Model of Ventricular Fibrillation and Advanced Cardiac Life Support in Swine

豚における心室細動と高度心臓生活支援の標準化モデル

Cardiopulmonary resuscitation after cardiac arrest, independent of its origin, is a regularly encountered medical emergency in hospitals as well as ...

リレーショナル (MySQL) と NoSQL の複雑さ増加クエリの実行 (MongoDB 存在) ISO/EN 13606 標準化された電子カルテ データベースのサイズ増加

リレーショナル (MySQL) と NoSQL の複雑さ増加クエリの実行 (MongoDB 存在) ISO/EN 13606 標準化された電子カルテデータベースのサイズ増加