Name: Ejecutar consultas de mayor complejidad relacional (MySQL) y NoSQL (MongoDB y existen) crecen de tamaño ISO/EN 13606 EHR estandarizadas las bases de datos (Video) | JoVE Journal
Uploaded: 2018-03-19T14:30:00.000+00:00
Duration: 7 min 26 s
Description: Aprende a comparar la complejidad computacional de bases de datos relacionales (MySQL) y NoSQL (MongoDB) mediante consultas de creciente complejidad. Este método evalúa tiempos de respuesta y rendimiento en concurrencia para seleccionar el sistema adecuado según el tipo de consulta y el tamaño de los datos.

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

Los autores desean dar las gracias a Dr Dipak Kalra, líder de la fuerza de tarea EHRCom que define el estándar 13606 de ISO/EN y su equipo de University College de Londres para su permiso usar la EN/ISO 13606 W3C XML Schema.
Este trabajo fue apoyado por Instituto de Salud Carlos III [números de concesión PI15/00321, PI15/00003, PI1500831, PI15CIII/00010 y RD16CIII].

1. construir un SGBD relacional MySQL para almacenar bases de datos de extractos de HCE estandarizada tamaño doble tres
<ol><li>Importar el W3C (World Wide Web Consortium) esquema de XML correspondiente a la ISO/EN13606 RM y los tipos de datos ISO21090 en un 'IDE Java' (entorno de desarrollo integrado). Nota: ISO significa International Standards Organization. EN los soportes para la norma europea.</li>
	<li>Ejecutar la JAXB (Java XML Binding) Plug-in en el IDE; Esto produce clases Java correspondientes a la estructura de los elementos de los archivos XML de extractos de HCE.</li>
	<li>La etiqueta manualmente las clases Java con etiquetas JPA. Estas etiquetas se refieren a los cardinalities y otras relaciones entre las tablas relacionales de la base de datos MySQL.</li>
	<li>Importar las bibliotecas de la JPA (Java API de persistencia) en el IDE y ejecutar el método que se construye una base de datos MySQL de las clases de Java etiquetadas.</li>
	<li>Crear tres directorios con extractos de HCE realista de 5.000, 10.000 y 20.000 archivos XML.</li>
	<li>Ejecutar el método JPA para cargar un extracto XML en el DBMS MySQL en todos los extractos de la guía de 5.000 extractos.</li>
	<li>Repita el paso 1.6 dos veces, una vez con el directorio de 10.000 extractos y una vez con el directorio de extractos de 20.000.</li>
</ol>2. construir un DBMS de NoSQL MongoDB para almacenar bases de datos de extractos de HCE estandarizada tamaño doble tres
<ol><li>Proceso de cada uno de los tres directorios que contiene 5.000, 10.000 y 20.000 realistas EHR extractos de archivos XML con un programa estándar para convertir archivos XML a archivos JSON, como json.org.XML. Tres directorios con archivos JSON de 5.000, 10.000 y 20.000 deben ser producidos.</li>
	<li>Lanzar MongoDB GUI (interfaz gráfica de usuario, véase Tabla de materiales).</li>
	<li>Lanzamiento de MongoDB 2.6 servidor ejecutando el programa mongod desde una ventana de DOS (Disk Operating System) sistema.</li>
	<li>Conecte la interfaz gráfica de MongoDB al servidor localhost puerto 27017.<ol>
<li>Seleccione el menú "conectar".</li>
		<li>Escriba un nombre para la conexión (por ejemplo ' primero').</li>
		<li>Escriba localhost:27017 en el cuadro de texto servidor de DB.</li>
		<li>Pulse el botón "Connect"; un árbol con las bases de datos actuales debe aparecer en la izquierda.</li>
	</ol>
</li>
	<li>Construir una base de datos que contiene 5.000 EHR estandarizado extractos.<ol>
<li>Haga clic en el nombre de la conexión en la parte superior del árbol a la izquierda.</li>
		<li>Seleccione el menú "archivo".</li>
		<li>Elija "añadir base de datos".</li>
		<li>Introduzca el nombre de la base de datos en el cuadro de diálogo que aparece.</li>
		<li>Haga clic en Aceptar.</li>
	</ol>
</li>
	<li>Construir una colección que contiene 5.000 EHR estandarizado extractos.<ol>
<li>Haga clic en el nombre de la base de datos en el árbol de la izquierda.</li>
		<li>Seleccione el menú "base de datos".</li>
		<li>Elija "AddCollection".</li>
		<li>Introduzca el nombre de la colección en el cuadro de diálogo que aparece.</li>
		<li>Haga clic en " crear".</li>
		<li>Haga clic en el nombre de la colección.</li>
		<li>Seleccione el menú "importar".</li>
		<li>Seleccione el botón de radio ''JSON - shell mongo / / mongoexport ".</li>
		<li>Haga clic en "siguiente".</li>
		<li>Presione el botón "Agregar archivos de código fuente".</li>
		<li>Navegar en la computadora usando el cuadro de diálogo.</li>
		<li>Abra el directorio que contiene 5.000 JSON extraer archivos.</li>
		<li>Seleccionar todos los archivos en el directorio.</li>
		<li>Pulsa "Open". La lista de archivos JSON debe aparecer en el cuadro de diálogo de importación.</li>
		<li>Pulse "siguiente"; en la izquierda aparece una vista previa de la nueva colección en la base de datos.</li>
		<li>Pulse "siguiente".</li>
		<li>Presione "iniciar importación". El progreso de la importación aparece abajo a la izquierda, indicando el número de archivos importados y el tiempo transcurrido.</li>
	</ol>
</li>
	<li>Repita los pasos 5 y 6 para construir una colección de 10.000 EHR estandarizado extractos.</li>
	<li>Repita los pasos 5 y 6 para construir una colección de 20.000 EHR estandarizado extractos.</li>
</ol>3. construir un NoSQL existen DBMS a tienda tres doble tamaño estandarizado EHR extractos de bases de datos
<ol><li>Lanzamiento de la base de datos existen .</li>
	<li>Mediante el icono de la base de datos, abra al cliente de administrador de Java.</li>
	<li>Introduzca la contraseña de admin.</li>
	<li>Pulse el botón "Connect".</li>
	<li>Construir una colección que contiene 5.000 EHR estandarizado extractos.<ol>
<li>En la barra de herramientas, seleccione el menú "crear una nueva colección".</li>
		<li>En el cuadro de diálogo que aparece, escriba el nombre de la nueva colección.</li>
		<li>Haga clic en "Aceptar"; aparece la nueva colección.</li>
		<li>Seleccione el nombre de la colección.</li>
		<li>En la barra de herramientas, seleccione el menú "archivos de la tienda en la base de datos".</li>
		<li>Navegar en la computadora usando el cuadro de diálogo.</li>
		<li>Seleccione el directorio que contiene 5.000 archivos de extracto XML estandarizados.</li>
		<li>Haga clic en el botón "Seleccione los archivos o directorios para almacenar". Observe que aparece un cuadro de diálogo que muestra el progreso, los archivos están almacenados y el porcentaje de la base de datos creada.</li>
	</ol>
</li>
	<li>Repita el paso 5 para crear una colección que contiene 10.000 EHR estandarizado extractos.</li>
	<li>Repita el paso 5 para crear una colección que contiene 20.000 EHR estandarizado extractos.</li>
</ol>4. diseñar y ejecutar en las bases de datos relacionales MySQL 3 6 consultas de mayor complejidad
<ol><li>Diseño de seis consultas de mayor complejidad según los arquetipos utilizados por los extractos de HCE.</li>
	<li>Programa una secuencia de comandos SQL con la primera consulta en la base de datos MySQL. La SQL debe adaptarse a la estructura especial de la base de datos MySQL debido a la estandarización de extractos (arquetipos). La base de datos de mapas de toda la estructura de los extractos. Como resultado, la consulta SQL es bastante compleja.</li>
	<li>Identificar los atributos de las bases de datos que serían acelerar el tiempo de respuesta de las consultas si un índice se construyó sobre ellas y, a continuación construcción de tales índices, aunque la mayoría de los índices se construyen automáticamente por el DBMS.</li>
	<li>Si una consulta necesita un índice automáticamente no construido, construir manualmente.<ol>
<li>Conectarse al servidor de MySQL (suplementario Figura 1).</li>
		<li>Seleccione y haga clic en el nombre de la base de datos a la izquierda.</li>
		<li>Seleccione y haga clic en la tabla relacional donde reside el campo indizado.</li>
		<li>Haga clic en la pestaña "estructura".</li>
		<li>Seleccione y haga clic en la columna donde se construirá el índice.</li>
		<li>Haga clic en "Índice". Tenga en cuenta que la sentencia SQL, el índice de construcción aparece, y aparece un mensaje que indica que la oración se ha construido con éxito.</li>
	</ol>
</li>
	<li>Ejecutar la primera consulta.<ol>
<li>Seleccione y haga clic en el nombre de la base de datos a la izquierda.</li>
		<li>Haga clic en la pestaña "SQL".</li>
		<li>Escriba o pegue el código SQL de la primera consulta (ver figura 2 complementaria).</li>
		<li>Pulse "continuar". Observe que aparece la primera pantalla de la lista de resultados, junto con un mensaje con el tiempo de ejecución de la consulta.</li>
		<li>Repita la ejecución 5 veces y calcular el tiempo medio de respuesta.</li>
	</ol>
</li>
	<li>Repita el paso 5 con consultas de 2 a 6.</li>
	<li>Ver todo el proceso tres veces, con las bases de datos de extractos de 5.000, 10.000 y 20.000.</li>
</ol>5. diseñar y ejecutar en las bases de datos NoSQL MongoDB 3 6 consultas de mayor complejidad
<ol><li>Lanzar la GUI de MongoDB (véase Tabla de materiales).</li>
	<li>Iniciar el servidor de MongoDB 2.6 ejecutando el programa mongod desde una ventana DOS del sistema (ver figura 3 complementaria).</li>
	<li>Siga el paso 2.4 para conectar la interfaz gráfica de MongoDB al servidor localhost puerto 27017.</li>
	<li>Seleccione y expanda la base de datos MongoDB en el lado izquierdo.</li>
	<li>Seleccione la colección.</li>
	<li>Haga clic en el menú de "colección" en la barra de herramientas.</li>
	<li>Ejecutar la primera consulta de MongoDB.<ol>
<li>Haga doble clic en el botón de "Query Builder".</li>
		<li>Haga doble clic en el "campo de consulta" del generador de consultas en la derecha.</li>
		<li>Escriba el campo de la consulta de MongoDB en el campo cuadro de texto del panel de consulta (ver complementarios figura 4).</li>
		<li>Escriba el valor de la consulta de MongoDB en el valor cuadro de texto del panel de consulta. Nota: Esta consulta debe ser algo como {"ns3:EHRExtract.allCompositions.content.items.parts.parts.name.ns2:originalText. valor":"Descripcion"}. El campo el valor cotizado y son separados por punto y coma.</li>
		<li>Haga doble clic en el campo de la proyección del generador de consultas</li>
		<li>Escriba la primera proyección en el cuadro de texto de proyección (ver complementarios Figura 5).</li>
		<li>Haga doble clic en el campo de proyección para añadir un nuevo cuadro de texto de proyección.</li>
		<li>Escriba la segunda proyección en el cuadro de texto de proyección. Nota: Una proyección selecciona una parte del documento obtenido por la consulta. Debe ser algo como {"ns3:EHRExtract. allCompositions.content.items.parts.parts.value.value": 1} y {" ns3: EHRExtract.all Compositions.content.items.parts.parts.value.nullFlavor ": 1}</li>
		<li>Haga clic en el botón de play azul para ejecutar la consulta.</li>
		<li>Visualizar el código de consulta en la pestaña código de consulta.</li>
		<li>Ver los detalles del resultado en la ficha explicar: número de resultados, tiempo de ejecución en milisegundos.</li>
		<li>Ver, ampliar y examinar los resultados en la pestaña de resultado.</li>
		<li>Si se requiere más procesamiento de la consulta, escriba un programa en Java con el driver de MongoDB Java con la consulta y un método para procesar los resultados.</li>
		<li>Repita la ejecución 5 veces y calcular el tiempo medio de respuesta.</li>
	</ol>
</li>
	<li>Paso de 5.7 para las 2 restantes a través de 6 consultas.</li>
	<li>Repetir todo el proceso en los 5.000, 10.000 y 20.000 extractos de bases de datos MongoDB.</li>
</ol>6. diseñar y ejecutar en los 3 NoSQL existen consultas de complejidad cada vez mayor de bases de datos 6
<ol><li>Lanzar el existen DBMS.</li>
	<li>Abra al cliente de administrador de Java.</li>
	<li>Presione el botón "conectar a la base de datos".</li>
	<li>Seleccione la base de datos y haga clic en él.</li>
	<li>Haga clic en el menú "consultar base de datos de XPath"; aparece el cuadro de diálogo de consulta.</li>
	<li>Ejecutar la consulta XPath de primera (ver complementarios Figura 6).<ol>
<li>Escriba o pegue el código XPath de la primera consulta en la parte superior del cuadro de diálogo.</li>
		<li>Haga clic en el menú "Ejecutar" en la barra de herramientas del cuadro de diálogo.</li>
		<li>Ver resultados de XML mediante la ficha "XML" en la parte inferior del cuadro de diálogo.</li>
		<li>Ver el número de resultados de compilación y tiempo de ejecución en la parte inferior del cuadro de diálogo.</li>
		<li>Repita la ejecución 5 veces y calcular el tiempo medio de respuesta.</li>
	</ol>
</li>
	<li>Repita el paso 6 para consultas de 2 a 6.</li>
	<li>Hacer todo el proceso tres veces, para los extractos de 5.000, 10.000 y 20.000 existen bases de datos.</li>
</ol>7. diseñar y ejecutar un experimento de concurrencia con el MySQL y MongoDB 5.000 extractos de bases de datos
Nota: Se ha eliminado la base de datos existen del experimento en este momento debido a la peor performance en los experimentos anteriores.
<ol><li>Seleccione las consultas con las tres respuestas de tiempo más cortas en los experimentos anteriores utilizando las bases de datos de 5.000 extractos (típicamente debajo de varios segundos).</li>
	<li>Identificar y construir manualmente índices de atributos apropiados para las consultas, si es necesario.</li>
	<li>Programa dos aplicaciones multihilo de Java, uno para MySQL y el otro para MongoDB; cada aplicación tendrá tres subprocesos de prioridad diferente, uno para cada consulta seleccionada en el paso 1.</li>
	<li>Ejecutar y calcular las CPU (Unidad Central de procesamiento) usar la distribución para cada subproceso (consulta).</li>
	<li>Ejecutar cada aplicación multiproceso, haga clic en el botón ejecutar cinco veces durante cada período de 10 minutos y calcular la más ejecutada (máxima prioridad) consulta rendimiento promedio y el tiempo promedio de las tres consultas.</li>
	<li>Ver las consultas de ejecución, con prioridades y tiempo de ejecución.</li>
	<li>Calcular el rendimiento promedio y tiempo medio de respuesta de cada una de las tres consultas.</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>

Los autores no tienen nada que revelar. Los conjuntos de datos utilizados en estos experimentos fueron proporcionados por varios hospitales españoles bajo licencia para estos experimentos y en consecuencia no están públicamente disponibles. El esquema ISO/EN 13606 RM XML fue proporcionado por la Universidad College Londres centro de informática de la salud y la educación multiprofesional (campana).

Este protocolo muestra que sistemas ORM relacionales pura parece prácticos para único paciente consulta (Q1, Q3 y Q4) puesto que los tiempos de respuesta son más lentos, probablemente debido a un elevado número de tablas relacionales realizar muchas operaciones de combinación costosos y debido a la sistema de almacenamiento utilizado por el tipo específico de base de datos. Bases de datos NoSQL almacenan datos de manera basado en el documento, mientras que sistemas relacionales utilizan una manera basados en tablas que se propaga cada documento a lo largo de la base de datos entera. Sistemas NoSQL muestran una pendiente lineal, con MongoDB realizar considerablemente más rápido que existen DBMS. En concurrencia, MongoDB también se comporta mucho mejor que relacional ORM MySQL7.
Este protocolo presenta un protocolo de resolución de problemas para los resultados presentados en el7 con respecto al DBMS MySQL de ORM. El servidor MySQL ha sido actualizado a la versión más reciente y los resultados han sido ligeramente modificados. Además, un punto crítico en el documento de los sistemas NoSQL MongoDB es que puede conservar consistencia cuando almacenar información médica7 porque cuando un extracto de HCE se actualiza, no se sobreescribe, pero un todo Extracto de nuevo con los nuevos datos es generados y almacenados en el sistema, y el extracto de la original se mantiene. Este es un requisito estricto de información médica, porque algunos médicos pueden haber hecho importantes decisiones médicas basadas en los datos originales.
El sistema de brazo relacional mejorado drásticamente disminuye el número de tablas relacionales y mejora relacional. Sin embargo, puesto que modifica el esquema relacional, puede consultar información médica en poder de los extractos, pero extractos no pueden ser recuperados en su forma original exacta.
Para bases de datos muy grandes de secundaria utilizan (investigación), no está claro qué sistema de base de datos es más apropiado, puesto que las consultas de todo paciente (Q2 y Q5) se comportan mejor en ORM que en sistemas NoSQL, pero estos sistemas se desempeñan mejor que el simplificado relacional sistemas en 12. Consideramos Q6 una consulta especial entre clínica y secundaria uso cuyo comportamiento no puede ser determinado por los resultados producidos por estos experimentos.
Sin embargo, una limitación del método es la indisponibilidad de experimentos directos comparando el mejor sistema relacional brazo con NoSQL MongoDB sobre consultas de práctica médica de paciente con exactamente los mismos datos utilizados en el protocolo. Mantuvimos los resultados interpolación tabla 3 y tabla 5 sobre consultas del paciente hasta que se realizó el experimento incluyendo el brazo de optimizada en el protocolo. Os dejamos estos experimentos para futuras aplicaciones. Un paso crítico dentro del protocolo es la selección de la base de datos gratis, versiones de software similares de los últimos años, para que podamos comparar estado de arte exacto de las tres tecnologías.
Este es uno de los primeros intentos para comparar directamente relacionales y sistemas NoSQL con información médica real, realista, estandarizada. Sin embargo, el sistema específico a utilizar depende mucho de la situación real y problema resuelto8.

NoSQL (no solo SQL) DBMS han surgido recientemente como una alternativa para el DBMS relacional tradicional (RDMBS). RDBMS han dominado la forma de los datos fueron almacenados en los sistemas de base de datos durante décadas. Cálculo y álgebra relacional bien estudiado y entendido han garantizado la eficiencia y la consistencia de RDBMS1. Sistemas NoSQL no serán sustitutos de sistemas relacionales, pero podría comportarse de manera ventajosa en ciertos escenarios y en diferentes condiciones.
Algunos de estos escenarios particulares y condiciones ocurriría en el diseño de la persistencia de la base de datos de los sistemas de registro de salud electrónico (EHR) para administrar y almacenar información médica. Para ser interoperables y sostenible en la práctica, varias normas internacionales como ISO/EN 13606, openEHR, HL72,3,4,5 se han utilizado para estandarizar extractos de HCE.
Varios estándares tales como ISO/EN 13606 y openEHR han separado la información y el conocimiento en dos diferentes niveles de abstracción, representado por el modelo de referencia (RM) y estructuras de datos especiales llamadas arquetipos. Esta separación a menudo es llamada el modelo dual y permite sistemas EHR que conocimientos médicos y semánticamente interoperable para evolucionar sin reprogramar todo el sistema EHR y, en consecuencia, a ser mantenible y sostenible en la práctica6 . Sin embargo, el modelo dual implementado en sistemas EHR estandarizados requiere que la organización de la información sigue una estructura específica, y esto tiene profundas consecuencias en el nivel de persistencia de base de datos del sistema es diseñado7.
Objeto relacional Mapping (ORM)8 es una metodología para implementar un sistema de HME utilizando el paradigma de base de datos relacional. ORM mapas exhaustivamente la estructura de archivos XML (eXtensible Markup Language) extractos EHR estandarizados utilizados por el sistema de base de datos relacional. ORM construye muchas tablas relacionales exhaustivamente siguiendo la estructura de los archivos XML estandarizados de EHR extractos. Estas tablas relacionales están relacionadas a través de muchas de las claves externas y el sistema resultante puede no ser muy eficiente.
Se han propuesto varias mejoras relacionales ORM. Nodo + ruta9 de openEHR reduce el número de tablas relacionales serializar subárboles del extracto entero archivo XML en BLOBs (objetos grandes binarios). Sin embargo, esta simplificación causa lógica compleja recuperación, dañar consultas complejas. Arquetipo de mapeo relacional (brazo)10 genera un modelo de base de datos impulsado por arquetipos, construcción de un nuevo esquema relacional basado en asignaciones entre arquetipos y tablas relacionales. En consecuencia, la información no médica del extracto de HCE se pierde.
Muchas bases de NoSQL basada en documento almacenan documentos todo como BLOBs todos respetando una original XML o JSON (JavaScript Object Notation) formato. Esto significa que no se construyen tablas relacionales. Estas bases de datos NoSQL no tienen ningún esquema y no soportan que se une o (ácido) propiedades11, es decir, atomicidad, consistencia, aislamiento o durabilidad. Como resultado, pueden ser muy ineficientes si un elemento de un documento hace referencia a elementos del mismo u otros tales documentos utilizando un enlace de direccionamiento indirecto. Esto sucede porque, con el fin de mantener la coherencia, la totalidad de los documentos de referencias tienen que ser procesadas secuencialmente. Sin embargo, una base de datos no relacionales puede todavía apropiada si la principal tarea desempeñada por el SGBD es una tarea basada en el documento. Esto es porque los datos pueden permanecer en una forma más estrechamente aproximar su representación verdad usando una base de datos NoSQL basada en el documento, aunque esto también es debido a las políticas de la especial persistencia logradas por documentos médicos de EHR (véase la sección discusión).
El propósito de estos métodos es mostrar varios experimentos para comparar la aplicación de la capa de persistencia de un sistema de HCE estandarizada utilizando tres diferentes DBMS: uno relacional (MySQL) y dos NoSQL (basadas en documentos MongoDB y XML nativo). Su complejidad computacional ha sido calculado y comparado usando tres diferentes bases de tamaño creciente y seis distintas consultas de mayor complejidad. Los servidores de base de tres datos han instalado y configurado localmente en el mismo ordenador donde se ha ejecutado la consulta. Ver la Tabla de materiales por técnicas.
Experimentos de concurrencia también se han realizado para comparar el rendimiento de MySQL y de NoSQL MongoDB DBMS relacionales. Las mejoras descritas de ORM (nodo + ruta y brazo) también han sido comparadas con resultados apropiados relevantes de la literatura10.
Sistemas de gestión de bases de datos están evolucionando continuamente a un ritmo acelerado. Nadie podría pensar acerca de este desarrollo exponencial cuando el único paradigma vigente era el modelo relacional. Por poner un ejemplo, véase por ejemplo12, donde se propone un modelo para implementar el tiempo de respuesta mejor bases de datos relacionales conservando las propiedades de ácido.

<table><tbody><tr><td>MySQL 5.7.20</td><td></td><td></td><td>Experimentos MySQL</td></tr><tr><td>Red Hat Enterprise Linux Server versión 7.4 (Maipo), 2,60 GHz, RAM 16 GB</td><td></td><td></td><td></td></tr><tr><td>MongoDB 2.6</td><td></td><td></td><td>Experimentos MongoDB</td></tr><tr><td>Windows 7, 2,66 GHz, RAM 12 GB&nbsp;</td><td></td><td></td><td></td></tr><tr><td>eXist 3.0RC1</td><td></td><td></td><td>eXist experimenta</td></tr><tr><td>Windows 7, 2.66GHz, RAM 12GB&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>

ejecutar consultas de mayor complejidad relacional (mysql) y nosql (mongodb y existen) crecen de tamaño iso/en 13606 ehr estandarizadas las bases de datos

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

Esta investigación muestra un protocolo para evaluar la complejidad computacional de consultas relacional y no relacionales (NoSQL (no sólo lenguaje de interrogación estructurado)) estandarizados sistemas de bases de datos de información médica electrónicos de salud (EHR) de registro (DBMS). Utiliza un conjunto de tres tamaño duplicar bases de datos, es decir, bases de datos de almacenamiento de 5000, 10.000 y 20.000 realistas estandarizado extractos de HCE, en tres sistemas de gestión de base de datos (DBMS): relacional MySQL el Mapeo objeto-relacional (ORM), basado en documentos NoSQL MongoDB y lenguaje de marcado extensible nativos existen NoSQL (XML).
Se calcularon los tiempos de respuesta promedio a seis consultas de mayor complejidad, y los resultados mostraron un comportamiento lineal en los casos de NoSQL. En el campo de NoSQL MongoDB presenta una pendiente lineal mucho más plana que existen.
Sistemas NoSQL también pueden ser más apropiados mantener sistemas de información médica estandarizados debido a la especial naturaleza de las políticas de actualización de la información médica, que no debe afectar a la consistencia y la eficiencia de los datos almacenados en bases de datos NoSQL.
Una limitación de este protocolo es la falta de resultados directos de la mejora de los sistemas relacional como mapeo relacional de arquetipo (brazo) con los mismos datos. Sin embargo, la interpolación de resultados de base de datos de tamaño doblar a los presentados en la literatura y otros resultados publicados sugieren que los sistemas NoSQL sería más apropiados en muchos escenarios específicos y problemas a resolver. Por ejemplo, NoSQL puede ser apropiado para tareas basadas en documentos como extractos her utilizados en clínica, edición y visualización o situaciones donde el objetivo es no sólo a la información médica de la consulta, sino también a restaurar el EHR en exactamente su forma original.

Seis distintas consultas en realista extractos estandarizados de EHR que contiene información sobre los problemas de los pacientes, incluyendo sus nombres, las fechas iniciales y finales y la gravedad, se muestran en la tabla 1.
Tiempos de respuesta promedio de las seis consultas en las tres bases de datos de tamaño doble en cada DBMS se muestran en las tablas 2-4. Las figuras 1-6 muestran los mismos resultados gráficamente (aviso que los ejes verticales utilizan escalas muy diferentes a lo largo de estas cifras).
El fuerte comportamiento lineal de la complejidad computacional es evidente a lo largo de todas las consultas de las bases de datos NoSQL, aunque con la precaución apropiada debido al tamaño relativamente pequeño de los 3 conjuntos de datos utilizados. Sin embargo, la base de datos relacional ORM muestra un claro comportamiento lineal. La base de datos MongoDB tiene una pendiente mucho más plana que la base de datos existen.
Resultados de la mejora de los sistemas relacional discutida en la introducción Publicada en la literatura pueden encontrarse en la tabla 5. Interpolando MongoDB resultados del cuadro 3 con consultas similares y tamaños de base de datos de los resultados del brazo de tabla 5 es igual a ambos sistemas de bases de datos en la Q1, pero favorece a MongoDB en Q3.
Los resultados de los experimentos de simultaneidad se pueden encontrar en la tabla 5 y tabla6. MongoDB late MySQL tanto en tiempo de respuesta y rendimiento. De hecho, MongoDB se comporta mejor en concurrencia que en aislamiento y se erige como una impresionante base de datos en ejecución concurrente.
<img alt="Figure 1" class="xfigimg" src="/files/ftp_upload/57439/57439fig1.jpg"> Figura 1 : Complejidad algorítmica de ORM MySQL, MongoDB, existen DBMS para consultas Q1 y Q4 y. Esta cifra se modificó de7 con licencia de Creative Commons (http://creativecommons.org/ licenses/by/4.0/) y muestra los tiempos de respuesta en segundos para 5.000, 10.000 y 20.000 tamaño EHR extractos de bases de datos para cada SGBD y consultas Q1 y Q4. <a href="//cloudflare.jove.com/files/ftp_upload/57439/57439fig1large.jpg" target="_blank">Haga clic aquí para ver una versión más grande de esta figura.</a>
<img alt="Figure 2" class="xfigimg" src="/files/ftp_upload/57439/57439fig2.jpg"> Figura 2 : Complejidad algorítmica de DBMS MySQL de ORM para la consulta Q2. Esta figura muestra los tiempos de respuesta en segundos para 5.000, 10.000 y 20.000 tamaño EHR extractos ORM MySQL base de datos para la consulta Q2. <a href="//cloudflare.jove.com/files/ftp_upload/57439/57439fig2large.jpg" target="_blank">Haga clic aquí para ver una versión más grande de esta figura.</a>
<img alt="Figure 3" class="xfigimg" src="/files/ftp_upload/57439/57439fig3.jpg"> Figura 3 : Complejidad algorítmica de MongoDB y existen DBMS para consultas de Q2 y Q5. Esta cifra se modificó de7 con licencia Creative Commons (http://creativecommons.org/licenses/ por / 4,0) y tiempos de respuesta en segundos para 5.000, 10.000, 20.000 tamaño y her extractos de bases de datos para cada SGBD y consultas Q2 y Q5. <a href="//cloudflare.jove.com/files/ftp_upload/57439/57439fig3large.jpg" target="_blank">Haga clic aquí para ver una versión más grande de esta figura.</a>
<img alt="Figure 4" class="xfigimg" src="/files/ftp_upload/57439/57439fig4.jpg"> Figura 4 : Complejidad algorítmica de DBMS MySQL de ORM para consultas Q3 y Q5. Muestra los tiempos de respuesta en segundos para 5.000, 10.000 y 20.000 tamaño EHR extractos de bases de datos para cada SGBD y consultas Q3 y Q5. <a href="//cloudflare.jove.com/files/ftp_upload/57439/57439fig4large.jpg" target="_blank">Haga clic aquí para ver una versión más grande de esta figura.</a>
<img alt="Figure 5" class="xfigimg" src="/files/ftp_upload/57439/57439fig5.jpg"> Figura 5: complejidad algorítmica de MongoDB DBMS para consulta Q3 y existen. Esta cifra se modificó de7 con licencia de Creative Commons (http://creativecommons.org/licenses/ por/4.0) y muestra los tiempos de respuesta en segundos para 5.000, 10.000 y 20.000 tamaño EHR extractos de bases de datos para cada DBMS y consulta Q3. <a href="//cloudflare.jove.com/files/ftp_upload/57439/57439fig5large.jpg" target="_blank">Haga clic aquí para ver una versión más grande de esta figura.</a>
<img alt="Figure 6" class="xfigimg" src="/files/ftp_upload/57439/57439fig6.jpg"> Figura 6 : Complejidad algorítmica de ORM MySQL, existen y MongoDB DBMS para consulta Q6. Esta cifra se modificó de7 con licencia de Creative Commons (http://creativecommons.org/licenses/ por/4.0) y muestra los tiempos de respuesta en segundos para 5.000, 10.000 y 20.000 tamaño EHR extractos de bases de datos para cada DBMS y consulta Q6. <a href="//cloudflare.jove.com/files/ftp_upload/57439/57439fig6large.jpg" target="_blank">Haga clic aquí para ver una versión más grande de esta figura.</a>
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td></td>
			<td>Consulta</td>
		</tr>
<tr>
<td>Q1</td>
			<td>Encontrar todos los problemas de un solo paciente</td>
		</tr>
<tr>
<td>Q2</td>
			<td>Encontrar todos los problemas de todos los pacientes</td>
		</tr>
<tr>
<td>Q3</td>
			<td>Encontrar la fecha inicial, fecha de resolución y la gravedad</td>
		</tr>
<tr>
<td></td>
			<td>de un solo problema de un solo paciente</td>
		</tr>
<tr>
<td>Q4</td>
			<td>Encontrar la fecha inicial, fecha de resolución y la gravedad</td>
		</tr>
<tr>
<td></td>
			<td>de todo problema de problemas de un solo paciente</td>
		</tr>
<tr>
<td>Q5</td>
			<td>Encontrar la fecha inicial, fecha de resolución y la gravedad</td>
		</tr>
<tr>
<td></td>
			<td>de todo problema de problemas de todos los pacientes</td>
		</tr>
<tr>
<td>Q6</td>
			<td>Encontrar a todos los pacientes con 'faringitis' problema,</td>
		</tr>
<tr>
<td></td>
			<td>inicial de fecha &gt; = 16 de octubre de 2007 ', fecha de resolución</td>
		</tr>
<tr>
<td></td>
			<td>&lt; = 05 de junio de 2008 ' y 'alta' de gravedad</td>
		</tr>
</tbody></table>Tabla 1: las seis consultas realizaron en los relacionales y bases de datos NoSQL extractos de HCE estandarizada que contiene acerca de los problemas de los pacientes. Esta tabla ha sido modificada de7 con licencia de Creative Commons (http://creativecommons.org/ licenses/by/4.0/) y muestra las seis consultas creciente complejidad realizadas en las tres bases de datos crecen de tamaño para cada DBMS expresado en natural lengua.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td>ORM y MySQL</td>
			<td>5000 docs</td>
			<td>10.000 documentos</td>
			<td>20.000 documentos</td>
		</tr>
<tr>
<td>Q1 (s)</td>
			<td>25.0474</td>
			<td>32.6868</td>
			<td>170.7342</td>
		</tr>
<tr>
<td>Q2 (s)</td>
			<td>0.0158</td>
			<td>0.0147</td>
			<td>0.0222</td>
		</tr>
<tr>
<td>Q3 (s)</td>
			<td>3.3849</td>
			<td>6.4225</td>
			<td>207.2348</td>
		</tr>
<tr>
<td>Q4 (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>P6 (s)</td>
			<td>1.4382</td>
			<td>2.4844</td>
			<td>183.4979</td>
		</tr>
<tr>
<td>Tamaño de la base de datos</td>
			<td>4.6 GB</td>
			<td>9.4 GB</td>
			<td>19.4 GB</td>
		</tr>
<tr>
<td>Extractos totales</td>
			<td>5000</td>
			<td>10.000</td>
			<td>20.000</td>
		</tr>
</tbody></table>Tabla 2: promedio de tiempos de respuesta en segundos de las seis consultas en bases de datos de tamaño doble de lo SGBD relacional ORM MySQL. Esta tabla muestra seis tiempos de respuesta para cada consulta tres tamaño duplicar bases de datos utilizando el DBMS relacional ORM MySQL y el tamaño en memoria de las tres bases de datos.
<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 documentos</td>
			<td>20.000 documentos</td>
			<td>pendiente (*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>Q2 (s)</td>
			<td>34.5181</td>
			<td>68.6945</td>
			<td>136.2329</td>
			<td>6,780.99</td>
		</tr>
<tr>
<td>Q3 (s)</td>
			<td>0.048</td>
			<td>0.058</td>
			<td>0.1201</td>
			<td>4.81</td>
		</tr>
<tr>
<td>Q4 (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>P6 (s)</td>
			<td>9.5153</td>
			<td>18.5566</td>
			<td>36.7805</td>
			<td>1,817.68</td>
		</tr>
<tr>
<td>Tamaño de la base de datos</td>
			<td>1,95 GB</td>
			<td>3.95GB</td>
			<td>7,95 GB</td>
			<td></td>
		</tr>
<tr>
<td>Extractos totales</td>
			<td>5000</td>
			<td>10.000</td>
			<td>20.000</td>
			<td></td>
		</tr>
</tbody></table>Tabla 3: promedio de tiempos de respuesta en segundos de las seis consultas en bases de datos de tamaño doble de los DBMS de NoSQL MongoDB. Esta tabla ha sido modificada de7 con licencia de Creative Commons (http://creativecommons.org/ licenses/by/4.0/) y muestra los tiempos de respuesta de seis de cada consulta para las tres tamaño duplicar bases de datos utilizando el DBMS de NoSQL MongoDB y el tamaño en memoria las tres bases de datos. También se indica la pendiente lineal de cada consulta.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td>Existen</td>
			<td>5000 docs</td>
			<td>10.000 documentos</td>
			<td>20.000 documentos</td>
			<td>pendiente (*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>Q2 (s)</td>
			<td>60.7761</td>
			<td>129.3645</td>
			<td>287.362</td>
			<td>15,105.73</td>
		</tr>
<tr>
<td>Q3 (s)</td>
			<td>0.6976</td>
			<td>1.771</td>
			<td>4.1172</td>
			<td>227.96</td>
		</tr>
<tr>
<td>Q4 (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>P6 (s)</td>
			<td>68.3798</td>
			<td>138.9987</td>
			<td>475.2663</td>
			<td>27,125.82</td>
		</tr>
<tr>
<td>Tamaño de la base de datos</td>
			<td>1,25 GB</td>
			<td>2,54 GB</td>
			<td>5,12 GB</td>
			<td></td>
		</tr>
<tr>
<td>Extractos totales</td>
			<td>5000</td>
			<td>10.000</td>
			<td>20.000</td>
			<td></td>
		</tr>
</tbody></table>Tabla 4: promedio de tiempos de respuesta en segundos de las seis consultas en bases de datos de tamaño doble de existen DBMS NoSQL. Esta tabla ha sido modificada de7 con licencia de Creative Commons (http://creativecommons.org/ licenses/by/4.0/) y muestra los tiempos de respuesta de seis de cada consulta tres tamaño duplicar bases de datos utilizando el NoSQL existen DBMS y el tamaño en memoria de las tres bases de datos. También se indica la pendiente lineal de cada consulta.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td></td>
			<td>Papel de brazo</td>
			<td>BRAZO (s)</td>
			<td>Nodo + ruta (s)</td>
		</tr>
<tr>
<td>Q1</td>
			<td>Consulta 2.1</td>
			<td>0.191</td>
			<td>24.866</td>
		</tr>
<tr>
<td>Q3</td>
			<td>Consulta 3.1</td>
			<td>0.27</td>
			<td>294.774</td>
		</tr>
<tr>
<td></td>
			<td>Tamaño de la base de datos</td>
			<td>2,90 GB</td>
			<td>43,87 GB</td>
		</tr>
<tr>
<td></td>
			<td>Extractos totales</td>
			<td>29.743</td>
			<td>29.743</td>
		</tr>
</tbody></table>Tabla 5: promedio de tiempos de respuesta en segundos de consultas similares a Q1 y Q3 de la mejora de los sistemas relacional presentados en 10 . Esta tabla ha sido modificada de7 con licencia de Creative Commons (http://creativecommons.org/ licenses/by/4.0/) y muestra las dos consultas más similar a Q1 y Q3 presentado en10 correspondiente a dos sistemas de bases de datos relacionales mejorada y sus tiempos de respuesta. También se muestran los tamaños de dos base de datos.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td>ORM y MySQL</td>
			<td>Rendimiento de procesamiento</td>
			<td>Tiempo de respuesta</td>
		</tr>
<tr>
<td>Q1 (s)</td>
			<td>4,711.60</td>
			<td>0.0793</td>
		</tr>
<tr>
<td>Q3 (s)</td>
			<td>4,711.60</td>
			<td>0.1558</td>
		</tr>
<tr>
<td>Q4 (s)</td>
			<td>4,711.60</td>
			<td>0.9674</td>
		</tr>
</tbody></table>Tabla 6: promedio de tiempo de respuesta y rendimiento en segundos de consultas Q1, Q3 y Q4 de ORM MySQL relacional DBMS en ejecución concurrente. Esta tabla ha sido modificada de7 con licencia de Creative Commons (http://creativecommons.org/ licenses/by/4.0/) y muestra el mayor rendimiento promedio de las tres consultas del paciente y sus tiempos de respuesta promedio en el concurrente experimento de ejecución mediante el sistema relacional ORM MySQL.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td>MongoDB</td>
			<td>Rendimiento de procesamiento</td>
			<td>Tiempo de respuesta</td>
		</tr>
<tr>
<td>Q1 (s)</td>
			<td>178,672.60</td>
			<td>0.003</td>
		</tr>
<tr>
<td>Q3 (s)</td>
			<td>178,672.60</td>
			<td>0.0026</td>
		</tr>
<tr>
<td>Q4 (s)</td>
			<td>178,672.60</td>
			<td>0.0034</td>
		</tr>
</tbody></table>Tabla 7: promedio de tiempo de respuesta y rendimiento en segundos de consultas Q1, Q3 y Q4 de MongoDB, NoSQL DBMS en ejecución concurrente. Esta tabla ha sido modificada de7 con licencia de Creative Commons (http://creativecommons.org/ licenses/by/4.0/) y muestra el mayor rendimiento promedio de las tres consultas del paciente y sus tiempos de respuesta promedio en el concurrente experimento de ejecución mediante el sistema MongoDB NoSQL.
Suplementario Figura 1: la captura de pantalla muestra la pantalla de software para conectarse al servidor MySQL. <a href="//cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_1.png" target="_blank">Haga clic aquí para descargar esta figura.</a>
Suplementario Figura 2: la captura de pantalla muestra la interfaz SQL al servidor MySQL en la primera consulta SQL se ha escrito. <a href="//cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_2.png" target="_blank">Haga clic aquí para descargar esta figura.</a>
3 figura suplementaria: el 2.6 de MongoDB localhost servidor es lanzado utilizando una ventana DOS del sistema ejecutando el servidor mongod. <a href="//cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_3.png" target="_blank">Haga clic aquí para descargar esta figura.</a>
Suplementario figura 4: la captura de pantalla muestra la consulta escrita en los cuadros de texto del generador de consultas, como se muestra en pasos 5.7.1 a través 5.7.4. La captura de pantalla ilustra paso 5.7.3. <a href="//cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_4.png" target="_blank">Por favor haga clic aquí para descargar esta figura.</a>
Suplementario Figura 5: la imagen muestra el paso 5.7.6. <a href="//cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_5.png" target="_blank">Haga clic aquí para descargar esta figura.</a>
Suplementario Figura 6: la captura de pantalla ilustra la escritura de la consulta de XPath en theupper parte del cuadro de diálogo. <a href="//cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_6.png" target="_blank">Haga clic aquí para descargar esta figura.</a>

Este estudio compara relacionales y no relacionales (NoSQL) normalizar sistemas de información médica. La complejidad computacional de los tiempos de respuesta de consulta de dichos sistemas de gestión de base de datos (DBMS) se calcula utilizando bases de datos de tamaño doble. Estos resultados ayudan a la discusión de la idoneidad de cada enfoque de base de datos a diferentes escenarios y problemas.

Ejecutar consultas de mayor complejidad relacional (MySQL) y NoSQL (MongoDB y existen) crecen de tamaño ISO/EN 13606 EHR estandarizadas las bases de datos

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

El objetivo general de este experimento es comparar la complejidad computacional de los sistemas de bases de datos NoSQL, tanto relacionales como relacionales y no solo con lenguaje de consulta estructurado o NoSQL, medidos por sus tiempos de respuesta a consultas crecientes y complejas. Este método puede ayudar a responder preguntas clave en el campo de los sistemas de gestión de bases de datos, como qué tipo de consultas son más apropiadas para qué tipo de sistemas de bases de datos. La principal ventaja de esta técnica es que compara los tiempos de respuesta a las consultas para bases de datos dobles de cada tipo, junto con la complejidad computacional a calcular, y Por lo tanto, este método puede proporcionar información sobre MySQL, MongoDB y el exceso de sistemas de bases de datos.También se puede aplicar a otros sistemas XML nativos y basados en documentos relacionales, como SQL Server y Base X. La primera vez que escuchamos este método es cuando tenemos que seleccionar un sistema persistente para un sistema de historia clínica electrónica. Diseñar y ejecutar consultas que aumentan la complejidad con índices no construidos automáticamente en una base de datos MySQL relacional. Conéctese al servidor MySQL y seleccione el nombre de la base de datos.Seleccione la tabla relacional dentro del campo de índice y abra la pestaña de estructura. Seleccione la columna donde se construirá el índice y haga clic en index. La oración SQL que construye el índice aparecerá seguida de un mensaje que indica que la oración se ha construido correctamente.Para ejecutar la primera consulta, seleccione el nombre de la base de datos y abra la pestaña SQL, introduzca el código SQL de la primera consulta y haga clic en continuar. Aparecerá la primera pantalla de la lista de resultados con el mensaje de la hora de ejecución de la consulta.Para diseñar y ejecutar consultas que aumenten la complejidad y una base de datos Mongo no relacional, no solo o NoSQL, inicie la interfaz gráfica de usuario de la base de datos Mongo y el servidor de la base de datos Mongo 2.6 que ejecuta el programa Mongo desde una ventana del sistema DOS. Conecte la interfaz de usuario gráfico de la base de datos Mongo al servidor host local a través del puerto 27017 y seleccione el menú conectar. Introduzca un nombre para la conexión e introduzca la ubicación del host local en el cuadro de texto del servidor de base de datos y, a continuación, haga clic en conectar.Debería aparecer un árbol con las bases de datos actuales. Expanda la base de datos de Mongo. Seleccione la colección de interés y abra el menú de colección.Para ejecutar la primera consulta de la base de datos Mongo, haga doble clic en el generador de consultas y en los botones del campo de consulta. Introduzca los campos de la consulta de la base de datos Mongo en el cuadro de texto de campos del panel de consulta y el valor de la consulta en el cuadro de texto de valor del panel de consulta. Haga doble clic en el campo de proyección del generador de consultas e introduzca la primera proyección en el cuadro de texto de la proyección.Haga doble clic en el campo de proyección para agregar un nuevo cuadro de texto de proyección e ingrese la segunda proyección, luego haga clic en reproducir, reproducir para ejecutar la consulta y visualizar el código de consulta en la pestaña de código de consulta. Los detalles del resultado se podrán ver en la pestaña de explicación y resultados. Para diseñar y ejecutar consultas de complejidad creciente en una base de datos NoSQL EXist, inicie la base de datos EXist y abra el cliente de administración de Java.Haga clic, conéctese a la base de datos y seleccione la base de datos. Haga clic en consultar la base de datos utilizando la ruta X. Aparecerá el cuadro de diálogo de consulta.A continuación, ejecute la primera consulta de ruta X. En esta tabla, se muestran seis consultas diferentes realizadas en extractos de historias clínicas electrónicas estandarizadas y realistas que contienen información sobre los problemas de los pacientes, incluidos sus nombres, fechas iniciales y finales y gravedad. El tiempo medio de respuesta de las seis consultas y las tres bases de datos de tamaño duplicado en cada sistema de gestión de bases de datos, demuestran un comportamiento lineal largo de complejidad computacional a lo largo de todas las consultas de las bases de datos no relacionales que no se observa en el análisis de bases de datos de mapeo relacional de objetos relacionales.La interpolación de los resultados de la base de datos de Mongo con consultas y tamaños de base de datos similares de los resultados de la asignación relacional de arquetipos genera resultados iguales en ambos sistemas de base de datos para la primera consulta, pero con resultados más favorables determinados utilizando la base de datos de Mongo para la tercera consulta. En los experimentos de simultaneidad, la base de datos Mongo es preferible a la base de datos MySQl, tanto en rendimiento como en tiempos de respuesta, ya que la base de datos Mongo se comporta mejor en simultaneidad que en aislamiento y se mantiene como una base de datos impresionante en ejecución simultánea. Bueno, pensé que esto es importante recordar mantener todos los servidores localmente en las mismas máquinas en las que el cliente realiza las consultas.Siguiendo este procedimiento, se pueden realizar otros métodos, como el uso de otros tipos de sistemas de bases de datos, para responder preguntas adicionales, como ¿puede existir un tipo de base de datos y ganar tanto en una sola como en todas las consultas de los pacientes? Después de su desarrollo, esta técnica allanó el camino para que los investigadores en el campo de la complejidad algorítmica exploraran el rendimiento comparativo de las bases de datos en diferentes tipos de sistemas de bases de datos. Después de ver este video, debe tener una buena comprensión de cómo ejecutar consultas que aumentan la complejidad en bases de datos crecientes de tamaño de sistemas de bases de datos de muy diferentes tipos.

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

Research

Investigación

JoVE Journal

Medicine

Medicina

Presentamos un protocolo y código de programación asociada así como muestras de metadatos para soportar una identificación automatizada basada en nube de Asociación de la categoría frases que representan conceptos únicos en dominio de conocimiento seleccionado usuario en literatura biomédica. La Asociación de categoría de frase cuantificada por este protocolo puede facilitar en el análisis de la profundidad en el dominio del conocimiento seleccionado.

Minería de frase basado en la nube y el análisis de Asociación de categoría de frase definida por el usuario en publicaciones biomédicas

Muchos investigadores generan datos "de tamaño medio", de baja velocidad y multidimensionales, que se pueden gestionar de forma más eficiente con bases de datos en lugar de hojas de cálculo. Aquí proporcionamos una visión general conceptual de las bases de datos, incluida la visualización de datos multidimensionales, la vinculación de tablas en estructuras de bases de datos relacionales, la asignación de canalizaciones de datos semiautomáticas y el uso de la base de datos para dilucidar el...

Bases de datos para gestionar eficientemente datos de tamaño medio, baja velocidad y multidimensionales en ingeniería de tejidos

TBase combina un registro de salud electrónico con una innovadora base de datos de investigación para receptores de trasplante de riñón. TBase se basa en una plataforma de base de datos en memoria, conectada a diferentes sistemas hospitalarios y utilizada para la atención ambulatoria regular. Integra automáticamente todos los datos clínicos relevantes, incluidos los datos específicos del trasplante, creando una base de datos de investigación única.

TBase - una base de datos integrada de investigación y registro electrónico de salud para receptores de trasplante de riñón

gP2S es una aplicación web para el seguimiento de experimentos de crioem. Se describen sus principales características, así como los pasos necesarios para instalar y configurar la aplicación. Una vez configurada, la aplicación permite registrar con precisión los metadatos asociados con los experimentos de manchas negativas y cryoEM.

gP2S, un sistema de gestión de la información para experimentos cryoem

El íleo postoperatorio (POI) es una complicación de la cirugía abdominal que lleva a una mayor morbilidad y una estancia hospitalaria prolongada. Como las estrategias profilácticas o terapéuticas faltan intensificación de la investigación es necesaria. Por lo tanto, se estableció un modelo de ratón estandarizado y factible para investigar la fisiopatología de la PDI y estudiar posibles opciones terapéuticas.

Evaluación funcional de la motilidad intestinal y la inflamación de la pared intestinal en roedores: Análisis de un modelo estandarizado de manipulación intestinal

Lesión Explorer (LE) es una tubería semi-automático, procesamiento de imágenes desarrollado para obtener tejido cerebral regional y subcorticales volumetría lesión hiperintensidad de resonancia magnética estructural de la enfermedad de Alzheimer y ancianos normal. Para asegurar un alto nivel de precisión y fiabilidad, el siguiente es un video-guiada, protocolo estandarizado para los procedimientos manuales de LE.

Lesión Explorer: Un video-guiada, Protocolo normalizado para precisa y fiable volumétrica derivados de la RM en la Enfermedad de Alzheimer y normal Ancianos

Se describe un curso de cubierta, portátil, estandarizada que se puede utilizar para evaluar evitación de obstáculos en personas que tienen una visión ultrabajo. El curso es relativamente barato, fácil de administrar, y se ha demostrado ser fiable y reproducible.

Una carrera de obstáculos normalizado para la evaluación de la función visual en Ultra Baja Visión y Visión Artificial

Este protocolo describe una técnica de osteosíntesis que utiliza un clavo de bloqueo intramedular para la fijación estandarizada de osteotomías de fémur, que se puede utilizar para analizar la cicatrización ósea normal y defectuosa en ratones.

Un clavo intramedular de bloqueo para estandarizada fijación del fémur osteotomías para analizar normal y defectuoso Bone Healing en ratones

Aquí, presentamos un protocolo estandarizado para medir la diferencia de potencial nasal (NPD). Regulador de la conductancia transmembrana de la fibrosis quística (CFTR) y función epitelial del sodio (ENaC) son evaluados por el cambio en el voltaje a través del epitelio nasal después de la superfusion de soluciones que modifican la actividad del canal del ion, proporcionando un medida de resultado.

Medición estandarizada de la diferencia de potencial transepitelial Nasal membrana (NPD)

Las bases de datos de literatura se utilizan comúnmente para evaluar publicaciones en un determinado tema, disciplina, país o región del mundo, una práctica conocida como análisis bibliométrico. El protocolo actual detalla cómo utilizar las bases de datos PubMed, Scopus y Web of Science para realizar análisis bibliométricos.

Comparación del análisis bibliométrico con PubMed, Scopus y Web of Science Databases

Aprende a comparar la complejidad computacional de bases de datos relacionales (MySQL) y NoSQL (MongoDB) mediante consultas de creciente complejidad. Este método evalúa tiempos de respuesta y rendimiento en concurrencia para seleccionar el sistema adecuado según el tipo de consulta y el tamaño de los datos.

Ejecutar consultas de mayor complejidad relacional (MySQL) y NoSQL (MongoDB y existen) crecen de tamaño ISO/EN 13606 EHR estandarizadas las bases de datos (Video) | JoVE Journal

Ejecutar consultas de mayor complejidad relacional (MySQL) y NoSQL (MongoDB y existen) crecen de tamaño ISO/EN 13606 EHR estandarizadas las bases de datos

Explorar más videos