Name: L’exécution des requêtes de complexité croissante en relationnelle (MySQL) et NoSQL (MongoDB et existent) taille-de plus en plus les bases de données de 13606 DSE normalisé ISO/fr (Vidéo) | JoVE Journal
Uploaded: 2018-03-19T14:30:00.000+00:00
Duration: 7 min 26 s
Description: Découvrez la comparaison de la complexité computationnelle entre bases de données relationnelles MySQL et NoSQL MongoDB. Cette méthode évalue les temps de réponse pour guider le choix du système adapté.

ai_agent_IP

ai_agent

maintenance

instantTrialDurationMinutes

isBiopharma

enableNewMyJoveSectionDesign

educationFeatures

seoMetaApi

ai_copilot_institution_blacklist

ai_chat_institution_blacklist

freeAccessWindow

ssoRoleCapture

scheduledMaintenanceBanner

joveLabsFeatures

disable_autoplay_for_bots

extended_trial_duration

5 minutes

playerTrialDesktop

Les auteurs tiennent à remercier m. Dipak Kalra, chef de l’Equipe de EHRCom qui a défini le 13606 EN/ISO standard et son équipe de l’University College de Londres pour leur aimable autorisation à utiliser la norme ISO/EN 13606 W3C XML Schema.
Ce travail a été soutenu par l’Instituto de Salud Carlos III [grant Grant numbers IP15/00321, IP15/00003, PI1500831, PI15CIII/00010 et RD16CIII].

1. construire un SGBD relationnel de MySQL pour stocker trois Double taille DSE normalisés extraits de bases de données
<ol><li>Importer le W3C (World Wide Web Consortium) XML Schema correspondant à la RM ISO/EN13606 et les types de données ISO21090 dans un «Java IDE» (Integrated Development Environment). Remarque : ISO signifie International Standards Organization. FR est synonyme de norme européenne.</li>
	<li>Exécuter le JAXB (Java XML Binding) plug-in dans l’IDE ; Cela provoque des classes Java correspondant à la structure des éléments des DSE extraits des fichiers XML.</li>
	<li>Étiqueter manuellement les classes Java produites avec des étiquettes JPA. Ces étiquettes consulter les cardinalités et autres relations entre les tables relationnelles de la base de données MySQL.</li>
	<li>Importer des bibliothèques de la JPA (Java Persistence API) dans l’IDE et exécute la méthode qui génère une base de données MySQL sur les classes Java étiquetés.</li>
	<li>Créez trois répertoires avec 5 000, 10 000 et 20 000 extraits de DSE réalistes des fichiers XML.</li>
	<li>Exécutez la méthode App pour charger un extrait XML dans le DBMS MySQL sur tous les extraits du répertoire 5 000 extraits.</li>
	<li>Répétez l’étape 1.6 deux fois, une fois avec le répertoire de 10 000 extraits et une fois avec le répertoire de 20 000 extraits.</li>
</ol>2. construire un SGBD NoSQL MongoDB pour stocker trois Double taille DSE normalisés extraits de bases de données
<ol><li>Processus de chacun des trois répertoires contenant 5 000, 10 000 et 20 000 fichiers XML des extraits de la DSE réalistes avec un programme standard pour convertir les fichiers XML des fichiers JSON, comme json.org.XML. Trois répertoires avec 5 000, 10 000 et 20 000 fichiers JSON doivent être produites.</li>
	<li>Lancer un MongoDB GUI (Graphic User Interface, voir la Table des matières).</li>
	<li>Lancer le MongoDB 2.6 serveur exécutant le programme mongod depuis une fenêtre DOS (Disk Operating System) du système.</li>
	<li>Connecter le GUI MongoDB au serveur localhost en utilisant le port 27017.<ol>
<li>Sélectionnez le menu «Connect».</li>
		<li>Écrire un nom pour la connexion (par exemple le « premier »).</li>
		<li>Écrire localhost:27017 dans la zone de texte serveur de DB.</li>
		<li>Appuyez sur le bouton «Connect» ; un arbre avec les bases de données actuelles doit apparaître sur la gauche.</li>
	</ol>
</li>
	<li>Construire une base de données contenant des DSE normalisée 5 000 extraits.<ol>
<li>Cliquez sur le nom de la connexion en haut de l’arborescence sur la gauche.</li>
		<li>Sélectionnez le menu «fichier».</li>
		<li>Choisissez «Ajouter la base de données».</li>
		<li>Entrez le nom de la base de données dans la boîte de dialogue qui s’affiche.</li>
		<li>Cliquez sur OK.</li>
	</ol>
</li>
	<li>Construire une collection contenant 5 000 DSE normalisé des extraits.<ol>
<li>Cliquez sur le nom de la base de données dans l’arborescence sur la gauche.</li>
		<li>Sélectionnez le menu «base de données».</li>
		<li>Choisir «AddCollection».</li>
		<li>Entrez le nom de la collection dans la boîte de dialogue qui s’affiche.</li>
		<li>Cliquez sur « créer».</li>
		<li>Cliquez sur le nom de la collection.</li>
		<li>Sélectionnez le menu «Import».</li>
		<li>Choisissez le bouton radio ''JSON - coquille mongo / / mongoexport ».</li>
		<li>Cliquez sur «suivant».</li>
		<li>Appuyez sur le bouton «Ajouter des fichiers de Source».</li>
		<li>Naviguer sur l’ordinateur à l’aide de la boîte de dialogue.</li>
		<li>Ouvrir le répertoire contenant 5 000 JSON extraire les fichiers.</li>
		<li>Sélectionnez tous les fichiers dans le répertoire.</li>
		<li>Appuyez sur «ouvrir». La liste des fichiers JSON doit apparaître dans la boîte de dialogue Importer.</li>
		<li>Appuyez sur «suivant» ; un aperçu de la nouvelle collection dans la base de données apparaît sur la gauche.</li>
		<li>Appuyez sur «suivant».</li>
		<li>Appuyez sur «Start Import». L’état d’avancement de l’importation s’affiche vers le bas sur la gauche, indiquant le nombre de fichiers importés et le temps écoulé.</li>
	</ol>
</li>
	<li>Répétez les étapes 5 et 6 à constituer une collection de 10 000 DSE normalisé des extraits.</li>
	<li>Répétez les étapes 5 et 6 à constituer une collection de 20 000 DSE normalisé des extraits.</li>
</ol>3. construire un NoSQL existent SGBD pour magasin trois Double taille normalisée DSE extraits de bases de données
<ol><li>Lancer la base de données existe .</li>
	<li>Icône de la base de données, ouvrez le Client d’administration de Java.</li>
	<li>Entrez le mot de passe admin.</li>
	<li>Appuyez sur le bouton «Connect».</li>
	<li>Construire une collection contenant 5 000 DSE normalisé des extraits.<ol>
<li>Dans la barre d’outils, sélectionnez le menu «créer une nouvelle Collection».</li>
		<li>Dans la boîte de dialogue qui s’affiche, tapez le nom de la nouvelle collection.</li>
		<li>Cliquez sur «accepter» ; la nouvelle collection s’affiche.</li>
		<li>Sélectionnez le nom de la collection.</li>
		<li>Dans la barre d’outils, sélectionnez le menu «stocker des fichiers dans la base de données».</li>
		<li>Naviguer sur l’ordinateur à l’aide de la boîte de dialogue.</li>
		<li>Sélectionnez le répertoire contenant 5 000 fichiers d’extrait XML normalisés.</li>
		<li>Cliquez sur le bouton «Sélectionner les fichiers ou répertoires pour stocker». Notez qu’une boîte de dialogue apparaît affichant la progression, les fichiers sont stockés et le pourcentage de la base de données créée.</li>
	</ol>
</li>
	<li>Répétez l’étape 5 pour construire une collection contenant 10 000 DSE normalisé des extraits.</li>
	<li>Répétez l’étape 5 pour construire une collection contenant les DSE standardisé 20 000 extraits.</li>
</ol>4. concevoir et exécuter dans les bases de données relationnelles MySQL 3 6 requêtes de complexité croissante
<ol><li>Concevoir six requêtes de complexité croissante selon les archétypes utilisés par les extraits de DSE.</li>
	<li>Programmer un script SQL avec la première requête sur la base de données MySQL. Le SQL doit s’adapter à la structure particulière de la base de données MySQL en raison de la normalisation des extraits (archétypes). La base de données mappe l’ensemble de la structure des extraits. En conséquence, la requête SQL est assez complexe.</li>
	<li>Identifier les attributs des bases de données seraient d’accélérer le temps de réponse des requêtes si un index a été construit sur eux, puis construisez ces indices, bien que la plupart des indices sont générés automatiquement par le SGBD.</li>
	<li>Si une requête a besoin d’un index non-automatiquement construit, générer manuellement.<ol>
<li>Se connecter au serveur MySQL (supplémentaire Figure 1).</li>
		<li>Sélectionnez et cliquez sur le nom de base de données sur la gauche.</li>
		<li>Sélectionnez et cliquez sur la table relationnelle où réside le champ indexé.</li>
		<li>Cliquez sur l’onglet «Structure».</li>
		<li>Sélectionnez et cliquez sur la colonne où l’index sera construit.</li>
		<li>Cliquez sur «index». Notez que la phrase SQL construire l’index s’affiche et un message indiquant que la phrase a été construite avec succès apparaît.</li>
	</ol>
</li>
	<li>Exécutez la première requête.<ol>
<li>Sélectionnez et cliquez sur le nom de base de données sur la gauche.</li>
		<li>Cliquez sur l’onglet «SQL».</li>
		<li>Écrire ou coller le code SQL de la première requête (voir supplémentaires Figure 2).</li>
		<li>Appuyez sur «Continuer». Notez que le premier écran de la liste des résultats apparaît, ainsi qu’un message avec la durée d’exécution de la requête.</li>
		<li>Répéter l’exécution 5 fois et calculer le temps moyen de réponse.</li>
	</ol>
</li>
	<li>Répétez l’étape 5 avec requêtes 2 à 6.</li>
	<li>Voir l’ensemble du processus trois fois, avec les bases de données de 5 000, 10 000 et 20 000 extraits.</li>
</ol>5. concevoir et exécuter dans les bases de données NoSQL MongoDB 3 6 requêtes de complexité croissante
<ol><li>Lancer l’interface graphique de MongoDB (voir Table des matières).</li>
	<li>Lancer le serveur MongoDB 2.6 l’exécution du programme de mongod depuis une fenêtre du système DOS (voir supplémentaire Figure 3).</li>
	<li>Suivez l’étape 2.4 pour connecter l’interface graphique de MongoDB au serveur localhost via port 27017.</li>
	<li>Sélectionnez et développez la base de données MongoDB sur le côté gauche.</li>
	<li>Sélectionnez la collection.</li>
	<li>Cliquez sur le menu «Collection» dans la barre d’outils.</li>
	<li>Exécutez la première requête de MongoDB.<ol>
<li>Double-cliquez sur le bouton «Requêteur».</li>
		<li>Double-cliquez sur le «champ de requête» du générateur de requêtes à la droite.</li>
		<li>Écrire le champ de la requête de MongoDB dans le champ zone de texte du panneau requête (voir supplémentaires Figure 4).</li>
		<li>Écrire la valeur de la requête de MongoDB dans la zone de texte valeur du panneau requête. Remarque : Cette requête devrait être quelque chose comme {ns3:EHRExtract.allCompositions.content.items.parts.parts.name.ns2:originalText «. valeur » : « Descripcion »}. Le champ et la valeur sont cités et séparées par un point-virgule.</li>
		<li>Double-cliquez sur le champ de Projection du générateur de requêtes</li>
		<li>Écrire la première projection dans la zone de texte de projection (voir supplémentaire Figure 5).</li>
		<li>Double-cliquez sur le champ de projection pour ajouter un nouveau textbox de projection.</li>
		<li>Écrire la deuxième projection dans la zone de texte de projection. Remarque : Une projection permet de sélectionner une partie du document récupéré par la requête. Ceux-ci devraient être quelque chose comme {ns3:EHRExtract «. allCompositions.content.items.parts.parts.value.value » : 1} et {"ns3 : EHRExtract.all Compositions.content.items.parts.parts.value.nullFlavor » : 1}</li>
		<li>Cliquez sur le bouton play bleu pour exécuter la requête.</li>
		<li>Visualiser le code de requête dans l’onglet Code de requête.</li>
		<li>Afficher les détails du résultat dans l’onglet expliquer : nombre de résultats, temps d’exécution en millisecondes.</li>
		<li>Découvre, développez, puis examinez les résultats dans l’onglet résultats.</li>
		<li>Si un traitement supplémentaire de la requête est requis, écrire un programme Java avec le driver MongoDB Java avec la requête et une méthode pour traiter les résultats.</li>
		<li>Répéter l’exécution 5 fois et calculer le temps moyen de réponse.</li>
	</ol>
</li>
	<li>Faire étape 5,7 pour les 2 autres par le biais de 6 requêtes.</li>
	<li>Répéter l’ensemble du processus dans les 5 000, 10 000 et 20 000 extraits de bases de données MongoDB.</li>
</ol>6. concevoir et exécuter en 3 NoSQL existent des requêtes de bases de données 6 augmentations-complexité
<ol><li>Lancer existent SGBD.</li>
	<li>Ouvrez le Client d’administration de Java.</li>
	<li>Appuyez sur le bouton «se connecter à la base de données».</li>
	<li>Sélectionnez la base de données et cliquez dessus.</li>
	<li>Cliquez sur le menu «consulter la base de données à l’aide de XPath» ; la boîte de dialogue consulter s’affiche.</li>
	<li>Exécution de la première requête XPath (voir supplémentaires Figure 6).<ol>
<li>Écrire ou coller le code XPath de la première requête dans la partie supérieure de la boîte de dialogue.</li>
		<li>Cliquez sur le menu «exécuter» dans la barre d’outils de la boîte de dialogue.</li>
		<li>Afficher les résultats XML à l’aide de l’onglet «XML» dans la partie inférieure de la boîte de dialogue.</li>
		<li>Afficher le nombre de résultats et de compilation et d’exécution au bas de la boîte de dialogue.</li>
		<li>Répéter l’exécution 5 fois et calculer le temps moyen de réponse.</li>
	</ol>
</li>
	<li>Répétez l’étape 6 pour les requêtes de 2 à 6.</li>
	<li>Faire le processus entier trois fois, pour les 5 000, 10 000 et 20 000 extraits existent des bases de données.</li>
</ol>7. concevoir et exécuter une expérience d’accès concurrentiel en utilisant le MySQL et MongoDB 5 000 extraits de bases de données
Remarque : La base de données eXist a été retiré de l’expérience à ce stade en raison de la pire performance dans les expériences précédentes.
<ol><li>Sélectionnez les requêtes avec les trois réponses de temps plus courtes dans les expériences précédentes en utilisant les bases de données de 5 000 extraits (généralement sous plusieurs secondes).</li>
	<li>Identifier et construire manuellement des index de l’attribut approprié pour ces requêtes, si nécessaire.</li>
	<li>Programmer des applications multithreads Java deux, un pour MySQL et l’autre pour MongoDB ; chaque application aura trois threads de priorité différents, un pour chaque requête sélectionnée à l’étape 1.</li>
	<li>Exécuter et calculer la CPU (unité centrale de traitement) utiliser la distribution pour chaque thread (requête).</li>
	<li>Exécuter chaque application multithread, en cliquant sur le bouton Exécuter cinq fois au cours de chaque travée de 10 min et calculer la plus exécutée (priorité) interroger un débit moyen et la moyenne de temps de réponse des trois requêtes.</li>
	<li>Afficher les requêtes dans l’exécution, aux priorités et temps d’exécution.</li>
	<li>Calculer le débit moyen et le temps de réponse moyen de chacune des trois requêtes.</li>
</ol>

<ol><li>Codd, E. F. <a target="_blank" href="https://cs.uwaterloo.ca/~david/cs848s14/codd-relational.pdf">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://scholar.google.com/scholar?hl=en&safe=off&q=author%3aKalra%2C+D+%22ISO+13606+electronic+health+record+communication+part+1%3A+reference+model%22">ISO 13606 electronic health record communication part 1: reference model</a>. , ISO. Geneva. ISO 13606-1 (2008).</li>
<li>Kalra, D., et al. <a target="_blank" href="http://scholar.google.com/scholar?hl=en&safe=off&q=author%3aKalra%2C+D+%22Electronic+health+record+communication+part+2%3A+archetype+interchange+specification%22">Electronic health record communication part 2: archetype interchange specification</a>. , ISO. Geneva. ISO 13606-2 (2008).</li>
<li>Kalra, D., Beale, T., Heard, S. <a target="_blank" href="https://www.ncbi.nlm.nih.gov/pubmed/16160223">The openEHR foundation.</a> Stud. Health Technol. Inform. 115, 153-173 (2005).</li>
<li>Health Level seven. Health Level Seven International. , Available from:
 <a target="_blank" href="http://www.hl7.org">http://www.hl7.org</a> (2017).</li>
<li>Beale, T. <a target="_blank" href="https://www.researchgate.net/publication/237033734_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ánchez-de-Madariaga, R., et al. <a target="_blank" href="http://www.ncbi.nlm.nih.gov/pubmed?term=((Examining+database+persistence+of+ISO%2FEN+13606+standardized+electronic+health+record+extracts%3A+relational+vs.+NoSQL+approaches%5BTitle%5D)+AND+%22BMC+Medical+Informatics+and+Decision+Making%22%5BJournal%5D)">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="https://www.researchgate.net/publication/42800142_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/pubmed?term=((Archetype+relational+mapping+-+a+practical+openEHR+persistence+solution%5BTitle%5D)+AND+%22BMC+Medical+Informatics+and+Decision+Making%22%5BJournal%5D)">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://ieeexplore.ieee.org/document/7063177/">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="https://link.springer.com/chapter/10.1007/978-3-319-53480-0_1">An innovative approach to manage heterogeneous information using relational database systems.</a> Advances in Intelligent Systems and Computing. 557, Springer. (2017).</li>
</ol>

Les auteurs n’ont rien à divulguer. Les ensembles de données utilisés dans ces expériences ont été fournis par plusieurs hôpitaux espagnols sous licence pour ces expériences et par conséquent ne sont pas accessibles au public. Le schéma XML de RM EN/ISO 13606 était prévu par l’University College London Centre informatique de santé & éducation multi-disciplinaire (carillon).

Ce protocole indique que purs systèmes relationnels de ORM ne semblent pas pratiques pour les requêtes individuelles (Q1, Q3 et Q4) temps de réponse étant plus lents, probablement en raison d’un grand nombre de tables relationnelles, effectuant de nombreuses opérations de jointure coûteuse et due à la système de stockage utilisé par le type spécifique de base de données. Bases de données NoSQL stockent des données dans un mode basés sur des documents, alors que les systèmes relationnels utilisent un mode basée sur une table qui se propage à chaque document tout au long de la base de données entière. NoSQL systèmes montrent une pente linéaire, avec MongoDB exécuter beaucoup plus rapidement qu’il existe des SGBD. En simultanéité, MongoDB se comporte aussi beaucoup mieux que relationnelles MySQL ORM7.
Ce protocole présente un protocole de dépannage pour les résultats présentés dans7 concernant le SGBD MySQL de ORM. Le système de MySQL a été mis à jour vers la dernière version et les résultats ont été légèrement modifiés. En outre, est un point critique dans les systèmes NoSQL document comme MongoDB est qu’ils peuvent conserver la cohérence lorsque stockant des informations médicales7 parce que lorsqu’un extrait de DSE est mis à jour, il n’est pas écrasé, mais un tout nouveau extrait avec les nouvelles données générées et stockées dans le système, et l’extrait original est maintenue. Il s’agit d’une exigence stricte de l’information médicale, parce que certains médecins ont pu importantes décisions médicales basées sur les données d’origine.
Le système de bras relationnel amélioré considérablement diminue le nombre de tables relationnelles et améliore les performances relationnelles. Cependant, puisqu’il modifie le schéma relationnel, medical information détenue par les extraits peut-être être interrogée, mais extraits ne peuvent être récupérés dans leurs formes d’origine exactes.
Pour utilisent de très grandes bases de données dans le secondaire (recherche), on ne sait pas quel système de base de données est plus approprié, étant donné que les requêtes de tous les patients (Q2 et Q5) se comportent mieux dans ORM que dans les systèmes NoSQL, mais ces systèmes obtiennent de meilleurs résultats que le simplifié/relationnel systèmes en 12. Nous considérons Q6 une requête spéciale entre la pratique clinique et secondaire utiliser dont le comportement ne peut être déterminé par les résultats générés par ces expériences.
Cependant, une des limites de la méthode sont l’indisponibilité des expériences directes en comparant le système de bras relationnel amélioré avec NoSQL MongoDB au sujet des requêtes individuelles, médical pratique avec exactement les mêmes données utilisées dans le protocole. Nous avons maintenu les résultats en interpolant tableau 3 et tableau 5 concernant les requêtes individuelles jusqu'à ce que l’expérience y compris bras optimisée dans le protocole a été effectuée. Nous quittons ces expériences pour de futures applications. Une étape critique dans le protocole est le choix de la base de données gratuite, des versions de logiciels similaires de ces dernières années, afin que nous puissions comparer l’exacte-de-pointe des trois technologies suivantes.
C’est une des premières tentatives de comparer directement relationnelles et systèmes NoSQL à l’aide de renseignements médicaux réels, réalistes, standardisés. Toutefois, le système spécifique à utiliser dépend beaucoup sur le scénario réel et le problème d’être résolu8.

NoSQL (non seulement SQL) SGBD ont récemment émergé comme alternative aux SGBD relationnels traditionnels (RDMBS). SGBDR ont dominé la façon dont les données étaient stockées dans les systèmes de base de données depuis des décennies. Calcul et algèbre relationnelle bien étudié et compris ont garanti l’efficacité et la cohérence des SGBDR1. Systèmes NoSQL ne deviendra pas de substituts aux systèmes relationnels, mais ils pourraient se comporter avantageusement dans certains scénarios et dans diverses conditions.
Certains de ces scénarios particuliers se produirait lors de la conception de la persistance de la base de données des systèmes de dossier de santé électronique (DSE) utilisé pour gérer et stocker des informations médicales. Pour être interopérable et durable dans la pratique, plusieurs normes internationales comme ISO/EN 13606, openEHR et HL72,3,4,,,5 ont servi à normaliser DSE extraits.
Plusieurs normes comme ISO/EN 13606 et openEHR ont séparées information et au savoir dans deux différents niveaux d’abstraction, représentée par le modèle de référence (RM) et de structures de données spéciales appelées archétypes. Cette séparation est souvent appelée le modèle double et il permet à des systèmes de DSE connaissance sémantiquement interopérables et médical d’évoluer sans reprogrammer le système de DSE entier et, par conséquent, pour être plus facile à maintenir et durable dans la pratique6 . Toutefois, le modèle double, mis en œuvre dans les systèmes de DSE normalisés exige que l’organisation de l’information suit une structure spécifique, et cela a des conséquences profondes dans la façon dont le niveau de base de données de persistance du système est conçu7.
Object Relational Mapping (ORM)8 est une méthodologie pour mettre en œuvre un système de DSE en utilisant le paradigme de base de données relationnelle. ORM cartes exhaustivement la structure de fichiers normalisés DSE extraits XML (eXtensible Markup Language) utilisé par le système pour une base de données relationnelle. ORM construit plusieurs tables relationnelles exhaustivement suivant la structure des fichiers XML extraits normalisés EHR. Ces tables relationnelles sont liées par plusieurs clés étrangères, et le système qui en résulte n’est peut-être pas très efficace.
Plusieurs améliorations relationnelles ORM ont été proposées. chemin d’accès + nœud9 d’openEHR réduit le nombre de tables relationnelles par sérialisation sous-arborescences de l’extrait de tout fichier XML dans des objets BLOB (objets volumineux binaires). Toutefois, cette simplification provoque une logique complexe d’extraction, endommageant des requêtes complexes. Archétype Mapping relationnel (ARM)10 génère un modèle de base de données pilotée par des archétypes, construction d’un nouveau schéma relationnel issu des mappages entre les archétypes et tables relationnelles. Par conséquent, certaines informations non médicales de l’extrait de DSE est perdue.
Plusieurs bases de données NoSQL basés sur des documents stockent des documents entiers comme toute BLOBs respectant un original XML ou JSON (JavaScript Object Notation) format. Cela signifie qu’aucune des tables relationnelles ne sont construits. Ces bases de données NoSQL n’ont aucun schéma et ils ne supportent pas soit les jointures ou (acide) propriétés11, c'est-à-dire, atomicité, cohérence, isolement ou durabilité. Ainsi, ils peuvent être très inefficaces, si un élément d’un document fait référence à des éléments de la même ou d’autres documents utilisant un lien d’indirection. Cela arrive parce que, pour assurer la cohérence, l’intégralité des documents référencés doivent être traitées de façon séquentielle. Cependant, une base de données non relationnelles peut être encore approprié si la principale tâche exécutée par le SGBD est une tâche basée sur des documents. C’est parce que les données peuvent demeurer sous une forme plus rapprocher étroitement sa représentation fidèle à l’aide d’une base NoSQL basés sur des documents, mais c’est aussi grâce à la politique de persistance spécial réalisée par documents médicaux EHR (voir la section « discussion »).
Le but de ces méthodes est de présenter plusieurs expériences pour comparer la mise en œuvre de la couche de persistance d’un système de DSE normalisé à l’aide de trois différents SGBD : un relationnelle (MySQL) et deux NoSQL (basés sur des documents MongoDB et native XML existent). Leur théorie de la complexité a été calculée et comparée à l’aide de trois bases différentes de taille croissante et six différentes requêtes de complexité croissante. Les trois serveurs ont été installés et configurés localement sur le même ordinateur où les requêtes ont été exécutées. Voir la Table des matières pour plus de détails techniques.
Simultanéité expériences ont également été effectuées afin de comparer les performances de MySQL et de NoSQL MongoDB SGBD relationnel. Les améliorations décrites de ORM (nœud + chemin d’accès et bras) ont également été comparées en utilisant des résultats pertinents et appropriés de la littérature10.
Systèmes de gestion de bases de données évoluent continuellement à un rythme accéléré. Personne ne songerait à ce développement exponentiel quand le seul paradigme existant était le modèle relationnel. Pour prendre un exemple, voir par exemple12, où il a été proposé un modèle à mettre en œuvre des temps de réponse améliorés bases de données relationnelles conservant les propriétés ACID.

<table><tbody><tr><td>MySQL 5.7.20</td><td></td><td></td><td>Expériences MySQL</td></tr><tr><td>Red Hat Enterprise Linux Server version 7.4 (Maipo), 2,60 GHz, RAM 16 Go</td><td></td><td></td><td></td></tr><tr><td>MongoDB 2.6</td><td></td><td></td><td>MongoDB expérimente</td></tr><tr><td>Windows 7, 2,66 GHz, RAM 12 Go.</td><td></td><td></td><td></td></tr><tr><td>eXist 3.0RC1</td><td></td><td></td><td>eXist expérimente</td></tr><tr><td>Windows 7, 2,66 GHz, RAM 12 Go&nbsp ;</td><td></td><td></td><td></td></tr><tr><td>Studio 3T 5.5.1</td><td>3T Software Labs Gmbh</td><td></td><td>MongoDB GUI</td></tr></tbody></table>

l’exécution des requêtes de complexité croissante en relationnelle (mysql) et nosql (mongodb et existent) taille-de plus en plus les bases de données de 13606 dse normalisé iso/fr

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

Cette recherche montre un protocole pour évaluer la complexité du calcul des requêtes relationnelle et non relationnelles (NoSQL (non seulement Structured Query Language)) standardisé des systèmes de bases de données information médicale santé électronique (DSE) compte rendu (SGBD). Il utilise un ensemble de trois taille doublement de bases de données, c'est-à-dire les bases de données stockant les 5000, 10 000 et 20 000 réaliste normalisés DSE extraits, dans trois systèmes de gestion de base de données différente (SGBD) : relationnel MySQL mapping objet-relationnel (ORM), basés sur des documents NoSQL MongoDB et langage de balisage extensible native NoSQL (XML) existent.
On a calculé les temps de réponse moyen aux six questions de complexité croissante, et les résultats ont montré un comportement linéaire dans les cas de NoSQL. Dans le domaine de NoSQL, MongoDB présente une pente linéaire beaucoup plus plate qu’eXist.
Les systèmes NoSQL peuvent également être préférable de maintenir des systèmes d’information médicale normalisée en raison de la nature particulière de la politique mise à jour des informations médicales, qui ne devrait pas affecter la cohérence et l’efficacité des données stockées dans les bases de données NoSQL.
Une des limites du présent protocole sont le manque de résultats directs de l’amélioration des systèmes relationnels tels que mappage relationnel d’archétype (ARM) avec les mêmes données. Toutefois, l’interpolation des résultats doublement de taille de base de données à celles présentées dans la littérature et autres résultats publiés suggère que les systèmes NoSQL pourraient être plus appropriés dans de nombreux scénarios spécifiques et les problèmes à résoudre. Par exemple, NoSQL peut convenir pour des tâches basées sur des documents tels que des extraits de DSE utilisés en pratique clinique, édition et visualisation ou des situations où le but est non seulement pour demander des informations médicales, mais aussi de rétablir le DSE exactement sa forme originale.

Six différentes requêtes effectuées sur réalistes extraits standardisés de DSE contenant des informations sur les problèmes des patients, y compris leur nom, la date initiale et finale et la gravité, sont indiquées dans le tableau 1.
Temps de réponse moyen des six requêtes dans les trois bases de doubler de taille dans chaque SGBD sont indiquées dans les tableaux 2-4. Les figures 1 à 6 montrent les mêmes résultats sous forme graphique (Remarquez que les axes verticaux utilisent des échelles très différentes tout au long de ces chiffres).
Le comportement linéaire fort de complexité algorithmique est évident tout au long de toutes les requêtes des bases de données NoSQL, mais avec la mise en garde appropriée en raison de la taille relativement petite des 3 ensembles de données utilisés. Toutefois, la base de données relationnelle de l’ORM montre un comportement linéaire peu clair. La base de données MongoDB a une pente beaucoup plus plate que la base de données eXist.
On trouvera dans le tableau 5résultats par l’amélioration des systèmes relationnels discutés dans l’introduction, publiée dans la littérature. MongoDB résultats du tableau 3 avec des requêtes semblables et les tailles de base de données des résultats de bras du tableau 5 en interpolant équivaut à deux systèmes de base de données au 1er trimestre, mais favorise MongoDB en Q3.
On trouvera dans le tableau 5 et le tableau6, les résultats des expériences d’accès concurrentiel. MongoDB bat MySQL les deux au rythme de débit et de la réponse. En fait, MongoDB se comporte mieux dans la concurrence qu’en vase clos et se présente comme une base de données impressionnante dans une exécution simultanée.
<img alt="Figure 1" class="xfigimg" src="/files/ftp_upload/57439/57439fig1.jpg"> Figure 1 : Complexité algorithmique des ORM MySQL, MongoDB, et il existe des SGBD pour les requêtes T1 et T4. Ce chiffre de7 à l’aide de la licence Creative Commons (http://creativecommons.org/ licenses/by/4.0/) a été modifié et montre des temps de réponse en quelques secondes pour 5 000, 10 000 et 20 000 entreprises DSE extraits de bases de données pour chaque SGBD et requêtes T1 et T4. <a href="//cloudflare.jove.com/files/ftp_upload/57439/57439fig1large.jpg" target="_blank">S’il vous plaît cliquez ici pour visionner une version agrandie de cette figure.</a>
<img alt="Figure 2" class="xfigimg" src="/files/ftp_upload/57439/57439fig2.jpg"> Figure 2 : Complexité algorithmique du SGBD MySQL ORM pour requête Q2. Cette figure montre des temps de réponse en quelques secondes pour 5 000, 10 000 et 20 000 entreprises DSE extraits ORM MySQL base de données de requête Q2. <a href="//cloudflare.jove.com/files/ftp_upload/57439/57439fig2large.jpg" target="_blank">S’il vous plaît cliquez ici pour visionner une version agrandie de cette figure.</a>
<img alt="Figure 3" class="xfigimg" src="/files/ftp_upload/57439/57439fig3.jpg"> Figure 3 : Complexité algorithmique de MongoDB et il existe des SGBD pour les requêtes Q2 et Q5. Ce chiffre a été modifié par7 à l’aide de la licence Creative Commons (http://creativecommons.org/licenses/ par / 4,0) et indique les temps de réponse en secondes pour 5 000, DSE 10 000 et 20 000 taille extraits de bases de données pour chaque SGBD et requêtes Q2 et Q5. <a href="//cloudflare.jove.com/files/ftp_upload/57439/57439fig3large.jpg" target="_blank">S’il vous plaît cliquez ici pour visionner une version agrandie de cette figure.</a>
<img alt="Figure 4" class="xfigimg" src="/files/ftp_upload/57439/57439fig4.jpg"> Figure 4 : Complexité algorithmique du SGBD MySQL ORM pour les requêtes Q3 et Q5. Montre des temps de réponse en quelques secondes pour 5 000, 10 000 et 20 000 entreprises DSE extraits de bases de données pour chaque SGBD et requêtes Q3 et Q5. <a href="//cloudflare.jove.com/files/ftp_upload/57439/57439fig4large.jpg" target="_blank">S’il vous plaît cliquez ici pour visionner une version agrandie de cette figure.</a>
<img alt="Figure 5" class="xfigimg" src="/files/ftp_upload/57439/57439fig5.jpg"> Figure 5: complexité algorithmique d’eXist et MongoDB DBMS pour requête Q3. Ce chiffre de7 à l’aide de la licence Creative Commons (http://creativecommons.org/licenses//4.0 /) a été modifié et indique le temps de réponse en secondes pour 5 000, que DSE 10 000 et 20 000 entreprises extraits de bases de données pour chaque requête Q3 et SGBD. <a href="//cloudflare.jove.com/files/ftp_upload/57439/57439fig5large.jpg" target="_blank">S’il vous plaît cliquez ici pour visionner une version agrandie de cette figure.</a>
<img alt="Figure 6" class="xfigimg" src="/files/ftp_upload/57439/57439fig6.jpg"> Figure 6 : Complexité algorithmique de MySQL ORM, existent et MongoDB DBMS pour interroger Q6. Ce chiffre de7 à l’aide de la licence Creative Commons (http://creativecommons.org/licenses//4.0 /) a été modifié et indique le temps de réponse en secondes pour 5 000, que DSE 10 000 et 20 000 entreprises extraits de bases de données pour chaque requête Q6 et SGBD. <a href="//cloudflare.jove.com/files/ftp_upload/57439/57439fig6large.jpg" target="_blank">S’il vous plaît cliquez ici pour visionner une version agrandie de cette figure.</a>
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td></td>
			<td>Requête</td>
		</tr>
<tr>
<td>1ER TRIMESTRE</td>
			<td>Trouver tous les problèmes d’un seul patient</td>
		</tr>
<tr>
<td>Q2</td>
			<td>Trouver tous les problèmes de tous les patients</td>
		</tr>
<tr>
<td>Q3</td>
			<td>Trouver la date initiale, date de la résolution et la gravité</td>
		</tr>
<tr>
<td></td>
			<td>d’un seul problème d’un seul patient</td>
		</tr>
<tr>
<td>Q4</td>
			<td>Trouver la date initiale, date de la résolution et la gravité</td>
		</tr>
<tr>
<td></td>
			<td>de tous les problèmes de problème d’un seul patient</td>
		</tr>
<tr>
<td>Q5</td>
			<td>Trouver la date initiale, date de la résolution et la gravité</td>
		</tr>
<tr>
<td></td>
			<td>de tous les problèmes problème de tous les patients</td>
		</tr>
<tr>
<td>Q6</td>
			<td>Trouver tous les patients avec pharyngite « problème »</td>
		</tr>
<tr>
<td></td>
			<td>première date &gt; = 16 octobre 2007 ", date de la résolution</td>
		</tr>
<tr>
<td></td>
			<td>&lt; = 5 juin 2008 "et la gravité « élevée »</td>
		</tr>
</tbody></table>Tableau 1 : les six requêtes effectuées sur le relationnel et bases de données NoSQL DSE normalisé contenant des extraits sur les problèmes des patients. Ce tableau a été modifié par7 à l’aide de la licence Creative Commons (http://creativecommons.org/ licenses/by/4.0/) et montre les six requêtes de complexité de plus en plus effectuées sur les trois bases de données en croissance taille pour chaque SGBD exprimée en naturel langue.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td>ORM/MySQL</td>
			<td>5000 docs</td>
			<td>10 000 documents</td>
			<td>20 000 documents</td>
		</tr>
<tr>
<td>Q1 (s)</td>
			<td>25.0474</td>
			<td>32.6868</td>
			<td>170.7342</td>
		</tr>
<tr>
<td>T2 (s)</td>
			<td>0.0158</td>
			<td>0,0147</td>
			<td>0,0222</td>
		</tr>
<tr>
<td>3ème trimestre (s)</td>
			<td>3.3849</td>
			<td>6.4225</td>
			<td>207.2348</td>
		</tr>
<tr>
<td>4e trimestre (s)</td>
			<td>33.5457</td>
			<td>114.6607</td>
			<td>115.4169</td>
		</tr>
<tr>
<td>Q5 (s)</td>
			<td>9.6393</td>
			<td>74.3767</td>
			<td>29.0993</td>
		</tr>
<tr>
<td>Q6 (s)</td>
			<td>1.4382</td>
			<td>2.4844</td>
			<td>183.4979</td>
		</tr>
<tr>
<td>Taille de la base de données</td>
			<td>4.6 GO</td>
			<td>9.4 GO</td>
			<td>19.4 GB</td>
		</tr>
<tr>
<td>Extraits totaux</td>
			<td>5000</td>
			<td>10 000</td>
			<td>20 000</td>
		</tr>
</tbody></table>Tableau 2 : moyenne des temps de réponse en quelques secondes des six requêtes sur bases de données doublement-taille du SGBD relationnel ORM MySQL. Ce tableau montre six temps de réponse pour chaque requête pour les trois taille doublement bases de données à l’aide du SGBD relationnel ORM MySQL et la taille en mémoire des trois bases de données.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td>MongoDB</td>
			<td>5000 docs</td>
			<td>10 000 documents</td>
			<td>20 000 documents</td>
			<td>pente (*10exp(-6))</td>
		</tr>
<tr>
<td>Q1 (s)</td>
			<td>0,046</td>
			<td>0,057</td>
			<td>0.1221</td>
			<td>5.07</td>
		</tr>
<tr>
<td>T2 (s)</td>
			<td>34.5181</td>
			<td>68.6945</td>
			<td>136.2329</td>
			<td>6,780.99</td>
		</tr>
<tr>
<td>3ème trimestre (s)</td>
			<td>0,048</td>
			<td>0,058</td>
			<td>0.1201</td>
			<td>4.81</td>
		</tr>
<tr>
<td>4e trimestre (s)</td>
			<td>0,052</td>
			<td>0,061</td>
			<td>o.1241</td>
			<td>4.81</td>
		</tr>
<tr>
<td>Q5 (s)</td>
			<td>38.0202</td>
			<td>75.4376</td>
			<td>149.933</td>
			<td>7460.85</td>
		</tr>
<tr>
<td>Q6 (s)</td>
			<td>9.5153</td>
			<td>18.5566</td>
			<td>36.7805</td>
			<td>1,817.68</td>
		</tr>
<tr>
<td>Taille de la base de données</td>
			<td>1,95 GO</td>
			<td>3,95 GO</td>
			<td>7,95 GO</td>
			<td></td>
		</tr>
<tr>
<td>Extraits totaux</td>
			<td>5000</td>
			<td>10 000</td>
			<td>20 000</td>
			<td></td>
		</tr>
</tbody></table>Tableau 3 : moyenne des temps de réponse en quelques secondes des six requêtes sur bases de données doublement-taille du SGBD NoSQL MongoDB. Ce tableau a été modifié par7 à l’aide de la licence Creative Commons (http://creativecommons.org/ licenses/by/4.0/) et indique les temps de six réponse de chaque requête pour les trois taille doublement bases de données en utilisant le NoSQL MongoDB SGBD et la taille en mémoire les trois bases de données. On montre aussi la pente linéaire de chaque requête.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td>Il existe</td>
			<td>5000 docs</td>
			<td>10 000 documents</td>
			<td>20 000 documents</td>
			<td>pente (*10exp(-6))</td>
		</tr>
<tr>
<td>Q1 (s)</td>
			<td>0.6608</td>
			<td>3.7834</td>
			<td>7.3022</td>
			<td>442.76</td>
		</tr>
<tr>
<td>T2 (s)</td>
			<td>60.7761</td>
			<td>129.3645</td>
			<td>287.362</td>
			<td>15,105.73</td>
		</tr>
<tr>
<td>3ème trimestre (s)</td>
			<td>0.6976</td>
			<td>1,771</td>
			<td>4.1172</td>
			<td>227.96</td>
		</tr>
<tr>
<td>4e trimestre (s)</td>
			<td>0.6445</td>
			<td>3.7604</td>
			<td>7.3216</td>
			<td>445.17</td>
		</tr>
<tr>
<td>Q5 (s)</td>
			<td>145.3373</td>
			<td>291.2502</td>
			<td>597.7216</td>
			<td>30,158.93</td>
		</tr>
<tr>
<td>Q6 (s)</td>
			<td>68.3798</td>
			<td>138.9987</td>
			<td>475.2663</td>
			<td>27,125.82</td>
		</tr>
<tr>
<td>Taille de la base de données</td>
			<td>1,25 GO</td>
			<td>2,54 GB</td>
			<td>5,12 GO</td>
			<td></td>
		</tr>
<tr>
<td>Extraits totaux</td>
			<td>5000</td>
			<td>10 000</td>
			<td>20 000</td>
			<td></td>
		</tr>
</tbody></table>Tableau 4 : moyenne des temps de réponse en quelques secondes des six requêtes sur bases de données doublement-taille de l’exister NoSQL DBMS. Ce tableau a été modifié par7 à l’aide de la licence Creative Commons (http://creativecommons.org/ licenses/by/4.0/) et indique les temps de six réponse de chaque requête pour les trois taille doublement bases de données en utilisant le NoSQL existent SGBD et la taille en mémoire de les trois bases de données. On montre aussi la pente linéaire de chaque requête.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td></td>
			<td>Papier de bras</td>
			<td>BRAS (s)</td>
			<td>Noeud + chemin (s)</td>
		</tr>
<tr>
<td>1ER TRIMESTRE</td>
			<td>Requête 2.1</td>
			<td>0,191</td>
			<td>24.866</td>
		</tr>
<tr>
<td>Q3</td>
			<td>Query 3.1</td>
			<td>0,27</td>
			<td>294.774</td>
		</tr>
<tr>
<td></td>
			<td>Taille de la base de données</td>
			<td>2,90 GB</td>
			<td>43,87 GB</td>
		</tr>
<tr>
<td></td>
			<td>Extraits totaux</td>
			<td>29 743</td>
			<td>29 743</td>
		</tr>
</tbody></table>Tableau 5 : moyenne des temps de réponse en quelques secondes des requêtes semblables à Q1 et Q3 de l’amélioration des systèmes relationnels présenté dans 10 . Ce tableau a été modifié par7 à l’aide de la licence Creative Commons (http://creativecommons.org/ licenses/by/4.0/) et montre les deux requêtes similaires plus Q1 et Q3 présenté en10 correspondant à deux systèmes améliorés de base de données relationnelle et leurs temps de réponse. Les tailles de base de deux données sont également indiqués.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td>ORM/MySQL</td>
			<td>Débit</td>
			<td>Temps de réponse</td>
		</tr>
<tr>
<td>Q1 (s)</td>
			<td>4,711.60</td>
			<td>0.0793</td>
		</tr>
<tr>
<td>3ème trimestre (s)</td>
			<td>4,711.60</td>
			<td>0.1558</td>
		</tr>
<tr>
<td>4e trimestre (s)</td>
			<td>4,711.60</td>
			<td>0.9674</td>
		</tr>
</tbody></table>Tableau 6 : temps de débit et de la réponse en quelques secondes des requêtes Q1, Q3 et Q4 d’ORM MySQL SGBD relationnel dans une exécution simultanée moyen. Ce tableau a été modifié par7 à l’aide de la licence Creative Commons (http://creativecommons.org/ licenses/by/4.0/) et présente le plus haut débit moyen des trois requêtes individuelles et leur temps de réponse moyen dans le simultané expérience de l’exécution en utilisant le système relationnel ORM MySQL.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td>MongoDB</td>
			<td>Débit</td>
			<td>Temps de réponse</td>
		</tr>
<tr>
<td>Q1 (s)</td>
			<td>178,672.60</td>
			<td>0,003</td>
		</tr>
<tr>
<td>3ème trimestre (s)</td>
			<td>178,672.60</td>
			<td>0,0026</td>
		</tr>
<tr>
<td>4e trimestre (s)</td>
			<td>178,672.60</td>
			<td>0,0034</td>
		</tr>
</tbody></table>Tableau 7 : temps de débit et de la réponse en quelques secondes des requêtes Q1, Q3 et Q4 de MongoDB NoSQL DBMS en exécution simultanée moyen. Ce tableau a été modifié par7 à l’aide de la licence Creative Commons (http://creativecommons.org/ licenses/by/4.0/) et présente le plus haut débit moyen des trois requêtes individuelles et leur temps de réponse moyen dans le simultané expérience de l’exécution en utilisant le système de MongoDB NoSQL.
Supplémentaire Figure 1 : la capture d’écran montre l’écran du logiciel pour se connecter au serveur MySQL. <a href="//cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_1.png" target="_blank">S’il vous plaît cliquez ici pour télécharger ce chiffre.</a>
Supplémentaire Figure 2 : la capture d’écran montre l’interface SQL au serveur MySQL où la première requête SQL a été écrit. <a href="//cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_2.png" target="_blank">S’il vous plaît cliquez ici pour télécharger ce chiffre.</a>
Supplémentaire Figure 3 : The MongoDB 2.6 du serveur localhost est lancé à l’aide d’une fenêtre du système DOS en exécutant le serveur mongod. <a href="//cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_3.png" target="_blank">S’il vous plaît cliquez ici pour télécharger ce chiffre.</a>
Supplémentaire Figure 4 : la capture d’écran montre la requête écrite dans les zones de texte du générateur de requêtes, comme illustré dans les étapes 5.7.1 par 5.7.4. La capture d’écran illustre étape 5.7.3. <a href="//cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_4.png" target="_blank">S’il vous plaît cliquez ici pour télécharger ce chiffre.</a>
Supplémentaire Figure 5 : la capture d’écran montre l’étape 5.7.6. <a href="//cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_5.png" target="_blank">S’il vous plaît cliquez ici pour télécharger ce chiffre.</a>
Supplémentaires Figure 6 : la capture d’écran illustre l’écriture de la requête XPath dans la partie supérieur de la boîte de dialogue. <a href="//cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_6.png" target="_blank">S’il vous plaît cliquez ici pour télécharger ce chiffre.</a>

Cette étude compare relationnelles et non relationnelles (NoSQL) normalisé des systèmes d’information médicale. La complexité du calcul des temps de réponse de l’interrogation de ces systèmes de gestion de base de données (SGBD) est calculée à l’aide de doubler de taille des bases de données. Ces résultats à l’examen de la pertinence de chaque approche de base de données à différents scénarios et problèmes.

L’exécution des requêtes de complexité croissante en relationnelle (MySQL) et NoSQL (MongoDB et existent) taille-de plus en plus les bases de données de 13606 DSE normalisé ISO/fr

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

L’objectif global de cette expérience est de comparer la complexité de calcul des systèmes relationnels et non relationnels, et pas seulement du langage de requête structuré ou des systèmes de base de données NoSQL, mesurée par leurs temps de réponse aux requêtes de complexité croissante. Cette méthode peut aider à répondre à des questions clés dans le domaine des systèmes de gestion de bases de données, telles que le type de requêtes le plus approprié pour quel type de systèmes de base de données. Le principal avantage de cette technique est qu’elle compare les temps de réponse aux requêtes pour une base de données double de chaque type, ainsi que la complexité de calcul à calculer, et cette méthode peut donc fournir un aperçu de MySQL, MongoDB et des systèmes de base de données excédentaires.Il peut également être appliqué à d’autres systèmes XML natifs basés sur des documents relationnels tels que SQL Server et Base X. Nous avons d’abord entendu parler de cette méthode lorsque nous devons sélectionner un système persistant pour un système de dossiers médicaux électroniques. Concevoir et exécuter des requêtes de plus en plus complexes avec des index non générés automatiquement dans une base de données MySQL relationnelle. Connectez-vous au serveur MySQL et sélectionnez le nom de la base de données.Sélectionnez la table relationnelle dans le champ d’index et ouvrez l’onglet Structure. Sélectionnez la colonne dans laquelle l’index sera créé et cliquez sur index. La phrase SQL qui construit l’index apparaît, suivie d’un message indiquant que la phrase a été construite avec succès.Pour exécuter la première requête, sélectionnez le nom de la base de données et ouvrez l’onglet SQL. Entrez le code SQL de la première requête et cliquez sur Continuer. Le premier écran de la liste des résultats apparaîtra avec le message indiquant le temps d’exécution de la requête.Pour concevoir et exécuter des requêtes plus complexes et une base de données Mongo non relationnelle, non seulement ou NoSQL, lancez la base de données Mongo interface utilisateur graphique et le serveur Mongo database 2.6 exécutant le programme Mongo à partir d’une fenêtre système DOS. Connectez l’interface utilisateur graphique de la base de données Mongo au serveur hôte local via le port 27017 et sélectionnez le menu Connecter. Entrez un nom pour la connexion et entrez l’emplacement de l’hôte local dans la zone de texte du serveur de base de données, puis cliquez sur Connecter.Une arborescence avec les bases de données actuelles doit apparaître. Développez la base de données Mongo. Sélectionnez la collection qui vous intéresse et ouvrez le menu de la collection.Pour exécuter la première requête de base de données Mongo, double-cliquez sur le générateur de requêtes et les boutons du champ de requête. Entrez les champs de la requête de base de données Mongo dans la zone de texte des champs du panneau de requête et la valeur de la requête dans la zone de texte de valeur du panneau de requête. Double-cliquez sur le champ de projection du générateur de requêtes et entrez la première projection dans la zone de texte de projection.Double-cliquez sur le champ de projection pour ajouter une nouvelle zone de texte de projection et entrez la deuxième projection puis cliquez, jouez pour exécuter la requête et visualisez le code de la requête dans l’onglet du code de requête. Les détails du résultat seront consultables sous l’onglet expliquer et résultats. Pour concevoir et exécuter des requêtes de complexité croissante dans une base de données NoSQL EXist, lancez la base de données EXist et ouvrez le client d’administration java.Cliquez sur, connectez-vous à la base de données et sélectionnez la base de données. Cliquez, consultez la base de données à l’aide du chemin X. La boîte de dialogue de consultation apparaîtra.Exécutez ensuite la première requête de chemin X. Dans ce tableau, six requêtes différentes effectuées sur des extraits de dossiers de santé électroniques standardisés réalistes contenant des informations sur les problèmes des patients, y compris leurs noms, dates initiales et finales et leur gravité, sont présentées. Le temps de réponse moyen des six requêtes et des trois bases de données dont la taille est doublée dans chaque système de gestion de base de données démontre un comportement linéaire long de complexité computationnelle dans toutes les requêtes des bases de données non relationnelles qui n’est pas observé dans l’analyse des bases de données de mappage relationnel d’objets relationnels.L’interpolation des résultats de la base de données Mongo avec des requêtes et des tailles de base de données similaires aux résultats du mappage relationnel archétype génère des résultats égaux dans les deux systèmes de base de données pour la première requête, mais avec des résultats plus favorables déterminés à l’aide de la base de données Mongo pour la troisième requête. Dans les expériences de concurrence, la base de données Mongo est préférable à la base de données MySQl à la fois en termes de débit et de temps de réponse, la base de données Mongo se comportant mieux en simultanéité qu’une base de données isolée et se présentant comme une base de données impressionnante en exécution simultanée. Eh bien, je pensais bien qu’il est important de se rappeler de maintenir tous les serveurs localement dans les mêmes machines que le client effectue les requêtes.Après cette procédure, d’autres méthodes, telles que l’utilisation d’autres types de systèmes de base de données, peuvent être mises en œuvre pour répondre à des questions supplémentaires telles que : un type de base de données peut-il exister et gagner à la fois dans les requêtes individuelles et toutes les requêtes des patients ? Après son développement, cette technique a ouvert la voie aux chercheurs dans le domaine de la complexité algorithmique pour explorer les performances comparatives des bases de données dans différents types de systèmes de bases de données. Après avoir regardé cette vidéo, vous devriez avoir une bonne compréhension de la façon d’exécuter des requêtes augmentant la complexité dans des bases de données croissantes de systèmes de bases de données de types très différents.

executing-complexity-increasing-queries-relational-mysql-nosql

Research

Recherche

JoVE Journal

Medicine

Médecine

Nous présentons un protocole et code de programmation associé ainsi que des échantillons de métadonnées pour soutenir une identification automatisée basée sur un nuage des phrases-catégorie association représentant des concepts uniques dans le domaine de certaines connaissances de l’utilisateur dans la littérature biomédicale. L’association de catégorie expression quantifiée par le présent protocole peut faciliter une analyse approfondie dans le domaine de connaissances choisies.

Expression nuage Mining and Analysis of User-Defined Phrase-catégorie Association dans les Publications biomédicales

De nombreux chercheurs génèrent des données « de taille moyenne », à basse vitesse et multidimensionnelles, qui peuvent être gérées plus efficacement avec des bases de données plutôt que des feuilles de calcul. Nous fournissons ici un aperçu conceptuel des bases de données, y compris la visualisation des données multidimensionnelles, le lien entre les tables dans les structures relationnelles de base de données, la cartographie des pipelines de données semi-automatisés et l'utilisation de la...

Bases de données pour gérer efficacement les données de taille moyenne, à faible vitesse et multidimensionnelles en génie tissulaire

TBase combine un dossier de santé électronique avec une base de données de recherche innovante pour les receveurs de greffe de rein. TBase est construit sur une plate-forme de base de données en mémoire, connectée à différents systèmes hospitaliers et utilisée pour les soins ambulatoires réguliers. Il intègre automatiquement toutes les données cliniques pertinentes, y compris les données spécifiques à la transplantation, créant ainsi une base de données de recherche unique.

TBase - une base de données électronique intégrée sur les dossiers de santé et la recherche pour les receveurs de greffe de rein

gP2S est une application web pour le suivi des expériences cryoEM. Ses principales caractéristiques sont décrites, tout comme les étapes requises pour installer et configurer l’application. Une fois configurée, l’application permet d’enregistrer avec précision les métadonnées associées aux expériences de coloration négative et de cryoEM.

gP2S, un système de gestion de l’information pour les expériences CryoEM

Iléus postopératoire (POI) est une complication de la chirurgie abdominale conduisant à une morbidité accrue et un séjour prolongé à l'hôpital. Parce que les stratégies prophylactiques ou thérapeutiques font défaut intensification de la recherche est nécessaire. Par conséquent, nous avons établi un modèle de souris standard et possible d'étudier la physiopathologie de POI et d'étudier les options possibles thérapeutiques.

D&#39;évaluation fonctionnelle de la motilité intestinale et inflammation de la paroi intestinale chez les rongeurs: analyses dans un modèle standardisé de la manipulation intestinale

Lésion Explorer (LE) est un pipeline semi-automatique traitement d'image développé pour obtenir le tissu cérébral régional et sous-corticales volumétrie de lésions hypersignal de l'IRM structurelle de la maladie d'Alzheimer et des personnes âgées normale. Pour assurer un niveau élevé de précision et de fiabilité, ce qui suit est une vidéo-guidée, protocole standardisé des procédures manuelles de LE.

Lésion Explorer: Un Protocole de vidéo-guidée standardisé pour Volumetrics IRM dérivées exactes et fiables dans la maladie d&#39;Alzheimer et normale personnes âgées

Nous décrivons un portable, bien sûr intérieure standard qui peut être utilisé pour évaluer l'évitement d'obstacles des personnes qui ont une vision ultra. Le parcours est relativement peu coûteux, simple à administrer, et a été montré pour être fiable et reproductible.

Un parcours du combattant normalisée pour l&#39;évaluation de la fonction visuelle chez Ultra Low Vision et Vision artificielle

Ce protocole décrit une technique d’ostéosynthèse utilisant un clou de verrouillage intramédullaire pour la fixation standardisée des ostéotomies du fémur, qui peut être utilisée pour analyser la cicatrisation osseuse normale et défectueuse chez la souris.

Un clou intramédullaire verrouillage pour Standardized Fixation de Fémur Ostéotomies pour l&#39;analyse normale et défectueuse des os de guérison chez la souris

Nous présentons ici un protocole standardisé permettant de mesurer la différence de potentiel nasale (NPD). Régulateur de la conductance transmembranaire de la fibrose kystique (CFTR) et fonction (ENaC) de canal sodium épithélial sont évalués par la variation de la tension à travers l’épithélium nasal après une perfusion de solutions qui modifient l’activité des canaux ioniques, fournissant une mesure des résultats.

Normalisée de mesure de différence de potentiel transépithélial Membrane nasale (NPD)

Les bases de données littéraires sont couramment utilisées pour évaluer les publications dans un sujet, une discipline, un pays ou une région du monde, une pratique connue sous le nom d'analyse bibliométrique. Le protocole actuel détaille comment utiliser les bases de données PubMed, Scopus et Web of Science pour effectuer une analyse bibliométrique.

Comparaison de l'analyse bibliométrique à l'aide de bases de données PubMed, Scopus et Web of Science

Découvrez la comparaison de la complexité computationnelle entre bases de données relationnelles MySQL et NoSQL MongoDB. Cette méthode évalue les temps de réponse pour guider le choix du système adapté.

L’exécution des requêtes de complexité croissante en relationnelle (MySQL) et NoSQL (MongoDB et existent) taille-de plus en plus les bases de données de 13606 DSE normalisé ISO/fr (Vidéo) | JoVE Journal

L’exécution des requêtes de complexité croissante en relationnelle (MySQL) et NoSQL (MongoDB et existent) taille-de plus en plus les bases de données de 13606 DSE normalisé ISO/fr

Explorer plus de vidéos