Name: Toenemende complexiteit querys uitvoeren in relationele (MySQL) en NoSQL (MongoDB en bestaan) grootte groeiende ISO/nl 13606 gestandaardiseerde EMD Databases (Video) | JoVE Journal
Uploaded: 2018-03-19T14:30:00.000+00:00
Duration: 7 min 26 s
Description: Leer de computationele complexiteit van relationele en NoSQL-databases vergelijken door responsietijden bij groeiende query's te analyseren. Deze methode biedt inzicht in MySQL en MongoDB prestaties.

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

De auteurs bedank Dr Dipak Kalra, leider van de EHRCom task force, die de standaard ISO/nl-13606 en zijn team van University College London voor hun vriendelijke toestemming voor het gebruik van de ISO/nl 13606 W3C XML-Schema gedefinieerd.
Dit werk werd gesteund door het Instituto de Salud Carlos III [subsidie nummers PI15/00321 en PI15/00003, PI1500831, PI15CIII/00010, RD16CIII].

1. bouw een relationele DBMS MySQL om informatiearchiefdatabases drie dubbele grootte gestandaardiseerde EMD extracten
<ol><li>Importeren van de W3C (World Wide Web Consortium) XML-Schema overeenkomt met de ISO/EN13606 RM en de gegevenstypen van ISO21090 in een 'Java IDE' (Integrated Development Environment). Opmerking: ISO staat voor International Standards Organization. NL staat voor Europese Norm.</li>
	<li>Uitvoeren van de JAXB (Java XML-bindende) plug-in in de IDE; Dit levert de Java klassen overeenkomt met de structuur van de elementen van het EMD XML-bestanden worden uitgepakt.</li>
	<li>De Java-klassen geproduceerd met PPV labels handmatig labelen. Deze labels verwijzen naar de kardinaliteiten en andere relaties tussen de relationele tabellen van de MySQL-database.</li>
	<li>De bibliotheken van de PPV (Java Persistentie API) importeren in de IDE en uitvoeren van de methode die een MySQL -database uit de tagged Java-klassen bouwt.</li>
	<li>Drie mappen maken met 5.000, 10.000 en 20.000 realistische EMD XML-bestanden worden uitgepakt.</li>
	<li>De methode van de PPV te laden van een XML-fragment in het DBMS MySQL op alle extracten van de 5.000 extracten directory uitgevoerd.</li>
	<li>Herhaal stap 1.6 tweemaal, eenmaal met de 10.000 extracten-map en een keer met de extracten van 20.000 directory.</li>
</ol>2. bouw een NoSQL MongoDB-DBMS om te slaan drie dubbele grootte gestandaardiseerde EMD extracten Databases
<ol><li>Proces elk van de drie lijsten met 5.000, 10.000 en 20.000 realistische EMD XML-bestanden worden uitgepakt met een standaardprogramma XML-bestanden omzetten in JSON bestanden, zoals json.org.XML. Drie mappen met 5.000, 10.000 en 20.000 JSON bestanden moeten worden geproduceerd.</li>
	<li>Lanceren van een MongoDB-GUI (Graphic User Interface, Zie Tabel van materialen).</li>
	<li>Start de MongoDB 2.6 server uitvoeren van het mongod -programma van een venster van DOS (Disk Operating System) systeem.</li>
	<li>De GUI MongoDB verbinden met de localhost-server via poort 27017.<ol>
<li>Selecteer het menu "Connect".</li>
		<li>Schrijf een naam voor de verbinding (bijvoorbeeld ' eerste').</li>
		<li>Localhost:27017 in de textbox DB Server schrijven.</li>
		<li>Druk op de knop "verbinden"; een boom met de huidige databases wordt weergegeven aan de linkerkant.</li>
	</ol>
</li>
	<li>Het bouwen van een database met 5.000 gestandaardiseerde EMD extracten.<ol>
<li>Klik op de naam van de verbinding bij de bovenkant van de boom aan de linkerkant.</li>
		<li>Selecteer het menu "bestand".</li>
		<li>Kies 'Database toevoegen'.</li>
		<li>Voer de naam van de database in het dialoogvenster dat verschijnt.</li>
		<li>Klik op OK.</li>
	</ol>
</li>
	<li>Het bouwen van een collectie met 5.000 gestandaardiseerde EMD extracten.<ol>
<li>Klik op de naam van de database in de boom aan de linkerkant.</li>
		<li>Selecteer menu "Database".</li>
		<li>Kies "AddCollection".</li>
		<li>Voer de naam van de collectie in het dialoogvenster dat verschijnt.</li>
		<li>Klik op ' Maakaan '.</li>
		<li>Klik op de naam van de collectie.</li>
		<li>Selecteer het menu "importeren".</li>
		<li>Selecteer keuzerondje ''JSON - mongo shell / / mongoexport ".</li>
		<li>Klik op "volgende".</li>
		<li>Druk op de knop "Add Source Files".</li>
		<li>Navigeren op de computer met behulp van het dialoogvenster.</li>
		<li>Open de map met 5.000 JSON bestanden uitpakken.</li>
		<li>Selecteer alle bestanden in de directory.</li>
		<li>Druk op "Open". De lijst van JSON bestanden moet worden weergegeven in het dialoogvenster importeren.</li>
		<li>Druk op "volgende"; een preview van de nieuwe collectie in de database wordt weergegeven aan de linkerkant.</li>
		<li>Druk op "volgende".</li>
		<li>Druk op "Start importeren". De voortgang van het importeren wordt weergegeven naar beneden aan de linkerkant, met vermelding van het aantal geïmporteerde bestanden en de verstreken tijd.</li>
	</ol>
</li>
	<li>Herhaal stap 5 en 6 om te bouwen van een verzameling van 10.000 gestandaardiseerde EMD-extracten.</li>
	<li>Herhaal stap 5 en 6 om te bouwen van een verzameling van 20.000 gestandaardiseerde EMD-extracten.</li>
</ol>3. bouw een NoSQL bestaan DBMS tot winkel drie dubbele Sized gestandaardiseerd EMD extracten Databases
<ol><li>Start de database bestaat .</li>
	<li>Met behulp van het pictogram van de database, opent u de administratie Client van Java.</li>
	<li>Het admin wachtwoord.</li>
	<li>Druk op de knop "Connect".</li>
	<li>Het bouwen van een collectie met 5.000 gestandaardiseerde EMD extracten.<ol>
<li>Selecteer in de werkbalk het menu "maken een nieuwe collectie".</li>
		<li>Typ in het dialoogvenster dat verschijnt, de naam van de nieuwe collectie.</li>
		<li>Klik op "accepteren"; de nieuwe collectie verschijnt.</li>
		<li>Selecteer de naam van de collectie.</li>
		<li>Selecteer het menu 'Store files in de database' in de werkbalk.</li>
		<li>Navigeren op de computer met behulp van het dialoogvenster.</li>
		<li>Selecteer de map met 5.000 gestandaardiseerde XML-bestanden uitpakken.</li>
		<li>Klik op de knop "Selecteer de bestanden of mappen op te slaan". Merk op dat een dialoogvenster wordt weergegeven waarin de vooruitgang, de bestanden worden opgeslagen, en het percentage van de database gemaakt.</li>
	</ol>
</li>
	<li>Herhaal stap 5 om te bouwen van een collectie met 10.000 gestandaardiseerde EMD-extracten.</li>
	<li>Herhaal stap 5 om te bouwen van een collectie met 20.000 gestandaardiseerde EMD-extracten.</li>
</ol>4. ontwerpen en 6 toenemende complexiteit Queries uitvoeren in de 3 relationele MySQL Databases
<ol><li>Het ontwerp van zes toenemende complexiteit query's volgens de archetypen gebruikt door de EMD-extracten.</li>
	<li>Programmeren van een SQL-script met de eerste query op de MySQL database. De SQL-code moet aanpassen aan de speciale structuur van de MySQL database als gevolg van extracten normalisatie (archetypen). De database wijst de hele structuur van de extracten. Dientengevolge, is de SQL-query nogal complex.</li>
	<li>Bepaal de kenmerken van de databases die zou versnellen de responstijd van de query's als een index werd gebouwd op hen, dan bouwen deze indexen, hoewel meeste indexen automatisch door het DBMS worden gebouwd.</li>
	<li>Als een query een niet-automatisch ingebouwde index moet, moet u het handmatig bouwen.<ol>
<li>Verbinding met de mysqlserver (aanvullende figuur 1).</li>
		<li>Selecteer en klik op de naam van de database aan de linkerkant.</li>
		<li>Selecteer en klik op de relationele tabel waar het geïndexeerde veld zich bevindt.</li>
		<li>Klik op het tabblad "structuur".</li>
		<li>Selecteer en klik op de kolom waar de index zal worden gebouwd.</li>
		<li>Klik op "index". Merk op dat de SQL-zin bouwen de index weergegeven en verschijnt er een bericht waarin staat dat de zin met succes is gebouwd.</li>
	</ol>
</li>
	<li>De eerste query uitvoert.<ol>
<li>Selecteer en klik op de naam van de database aan de linkerkant.</li>
		<li>Klik op het tabblad "SQL".</li>
		<li>Schrijven of de SQL-code van de eerste query plakken (Zie aanvullende figuur 2).</li>
		<li>Druk op "Doorgaan". Merk op dat het eerste scherm van de lijst met zoekresultaten, samen met een bericht met de uitvoeringstermijn van de query verschijnt.</li>
		<li>Herhaal de uitvoering 5 keer en berekenen van de gemiddelde responstijd.</li>
	</ol>
</li>
	<li>Herhaal stap 5 met queries 2 t/m 6.</li>
	<li>Niet het hele proces drie keer, met de 5.000, 10.000 en 20.000 extracten-databases.</li>
</ol>5. ontwerpen en 6 toenemende complexiteit Queries uitvoeren in de 3 NoSQL MongoDB-Databases
<ol><li>Starten van de GUI MongoDB (Zie Tabel van materialen).</li>
	<li>Starten van de server van de MongoDB 2.6 uitvoeren van het programma van de mongod van een DOS-venster systeem (Zie aanvullende figuur 3).</li>
	<li>Volg stap 2.4 de MongoDB GUI verbinden met de localhost-server via poort 27017.</li>
	<li>Selecteer en vouw de database MongoDB aan de linkerkant.</li>
	<li>Selecteer de collectie.</li>
	<li>Klik op de "collectie" menu in de werkbalk.</li>
	<li>De eerste MongoDB-query uitvoert.<ol>
<li>Dubbelklik op de knop "Query Builder".</li>
		<li>Dubbelklik op het "queryveld" van de opbouwfunctie voor Query's aan de rechterkant.</li>
		<li>Schrijf het veld van de MongoDB-query in het tekstvak van het veld voor de query panel (Zie aanvullende figuur 4).</li>
		<li>Schrijf de waarde van de MongoDB-query in het tekstvak van de waarde van het query-paneel. Opmerking: Deze query moet iets als {"ns3:EHRExtract.allCompositions.content.items.parts.parts.name.ns2:originalText. waarde":"Descripción"}. Het veld zijn de waarde geciteerd en gescheiden door puntkomma's.</li>
		<li>Dubbelklik op het gebied van de projectie van de opbouwfunctie voor Query 's</li>
		<li>Schrijf de eerste projectie in de textbox projectie (Zie aanvullende figuur 5).</li>
		<li>Dubbelklik op de projectie gebied toe te voegen een nieuwe projectie textbox.</li>
		<li>Schrijf de tweede projectie in de textbox projectie. Opmerking: Een projectie selecteert een deel van het document opgehaald met de query. Dit moet iets als {"ns3:EHRExtract. allCompositions.content.items.parts.parts.value.value": 1} en {" ns3: EHRExtract.all Compositions.content.items.parts.parts.value.nullFlavor ": 1}</li>
		<li>Klik op de blauwe afspeelknop de query uit te voeren.</li>
		<li>Visualiseren van de code van de query in het tabblad Query Code.</li>
		<li>De details van het resultaat bekijken in het tabblad uitleg: aantal resultaten, uitvoering tijd in milliseconden.</li>
		<li>Bekijken, uit te breiden, en bekijkt u de resultaten in het tabblad resultaat.</li>
		<li>Als verdere verwerking van de query vereist is, een Java-programma te schrijven met de bestuurder van de MongoDB Java met de query en een methode voor het verwerken van de resultaten.</li>
		<li>Herhaal de uitvoering 5 keer en berekenen van de gemiddelde responstijd.</li>
	</ol>
</li>
	<li>Stap 5.7 voor de resterende 2 t/m 6 queries.</li>
	<li>Herhaal het hele proces in de 5.000, 10.000 en 20.000 extracten MongoDB databases.</li>
</ol>6. ontwerpen en uitvoeren in de 3 NoSQL bestaan Databases 6 vergroting-complexiteit query's
<ol><li>Start de bestaan DBMS.</li>
	<li>Open de administratie Client van Java.</li>
	<li>Druk op de knop "verbinden met de database".</li>
	<li>Selecteer de database en klik op het.</li>
	<li>Klik op het menu "raadplegen van de database met behulp van XPath"; het consult-dialoogvenster wordt weergegeven.</li>
	<li>De eerste XPath-query uitvoeren (Zie aanvullende figuur 6).<ol>
<li>Schrijven of de XPath-code van de eerste query plakken in het bovenste gedeelte van het dialoogvenster.</li>
		<li>Klik op het menu "uitvoeren" in de knoppenbalk van het dialoogvenster.</li>
		<li>Via het tabblad 'XML' in het onderste gedeelte van het dialoogvenster XML-resultaten weergeven.</li>
		<li>Aantal resultaten en compilatie en uitvoeringstijd onderin het dialoogvenster bekijken.</li>
		<li>Herhaal de uitvoering 5 keer en berekenen van de gemiddelde responstijd.</li>
	</ol>
</li>
	<li>Herhaal stap 6 voor query's 2 tot en met 6.</li>
	<li>Niet het hele proces drie keer, want de extracten van 5.000, 10.000 en 20.000 databases bestaan.</li>
</ol>7. het ontwerpen en uitvoeren van een Experiment van de Concurrency met behulp van de MySQL en MongoDB 5.000 extracten Databases
Opmerking: De eXist database is verwijderd uit het experiment op dit moment als gevolg van erger prestaties in de eerdere experimenten.
<ol><li>Selecteer de query's met de drie kortste tijd antwoorden in het eerdere experimenten met behulp van de 5.000 extracten databases (doorgaans onder enkele seconden).</li>
	<li>Identificeren en handmatig bouwen passende kenmerk indexen voor die query's, indien nodig.</li>
	<li>Programma twee Java multithread-toepassingen, één voor MySQL en de andere voor MongoDB; elke aanvraag zal hebben drie verschillende prioritaire onderwerpen, één voor elke query die in stap 1 hebt geselecteerd.</li>
	<li>Uitvoeren en berekenen de CPU (Central Processing Unit) gebruik verdeling voor elke thread (query).</li>
	<li>Elke multithread-toepassing te klikken op de knop uitvoeren vijf keer tijdens elke 10-min span, uitvoeren en berekenen van de meest uitgevoerde (hoogste prioriteit) gemiddelde doorvoer en de reactie van de gemiddelde tijd van de drie queries opvragen.</li>
	<li>De query's in uitvoering, met de prioriteiten en uitvoertijd weergeven.</li>
	<li>Berekenen gemiddelde doorvoer en gemiddelde responstijd van elk van de drie queries.</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>

De auteurs hebben niets te onthullen. De datasets gebruikt in deze experimenten werden verstrekt door verschillende Spaanse ziekenhuizen onder licentie voor deze experimenten en bijgevolg zijn niet publiekelijk beschikbaar. Het ISO/nl 13606 RM XML-schema werd verstrekt door het University College London Centre for Health Informatics & gezondheidsdimensie onderwijs (klokkenspel).

Dit protocol laat zien dat zuivere relationele ORM systemen niet praktisch voor single-patiënt query's (Q1, Q3 en Q4 lijken) aangezien responstijden zijn langzamer, waarschijnlijk als gevolg van een hoog aantal relationele tabellen veel dure join-bewerkingen uitvoeren, en vanwege de opslagsysteem dat wordt gebruikt door de specifieke aard van de database. NoSQL databases slaan gegevens op documenten gebaseerde wijze, terwijl relationele systemen gebruiken een tabel is gebaseerd mode die zich elk document in de hele database verspreidt. NoSQL systemen tonen een lineaire helling, met MongoDB uitvoeren aanzienlijk sneller dan bestaan DBMS. In concurrency, MongoDB ook gedraagt zich veel beter dan relationele MySQL ORM7.
Dit protocol biedt een probleemoplossing protocol voor de resultaten gepresenteerd in7 met betrekking tot de ORM MySQL DBMS. De MySQL-systeem is bijgewerkt naar de nieuwste versie en de resultaten zijn enigszins gewijzigd. Daarnaast is een kritisch punt in document gebaseerde NoSQL systemen zoals MongoDB is dat ze consistentie behouden kunnen bij het opslaan van medische informatie7 omdat wanneer een EMD uittreksel wordt bijgewerkt, wordt het niet overschreven, maar een geheel nieuw pak uit met de nieuwe gegevens gegenereerd en opgeslagen in het systeem, en het oorspronkelijke extract wordt gehandhaafd. Dit is een strikte vereiste van medische informatie, omdat sommige artsen mogelijk hebben gemaakt van belangrijke medische beslissingen op basis van de oorspronkelijke gegevens.
De verbeterde relationele armsysteem drastisch vermindert het aantal relationele tabellen en relationele prestaties verbetert. Aangezien het wijzigt het relationele schema, medische informatie, gehouden door de extracten kan worden opgevraagd, maar extracten kunnen niet worden hersteld in hun exacte originele vormen.
Voor zeer grote databases in secundaire gebruiken (onderzoek), het is niet duidelijk welke database-systeem is meer nodig, aangezien de all-patiënt-query's (Q2 en Q5) beter in ORM dan in NoSQL systemen gedragen, maar deze systemen beter dan de vereenvoudigde presteren relationele systemen in 12. Wij beschouwen de Q6 een speciale query tussen de klinische praktijk en secundaire gebruiken wier gedrag kan niet worden bepaald door de resultaten van deze experimenten.
Een beperking van de methode is echter de inavailability van directe experimenten het verbeterde relationele armsysteem met NoSQL MongoDB met betrekking tot één-patiënt, medische praktijk query's vergelijken met precies dezelfde gegevens die in het protocol worden gebruikt. Wij onderhouden de resultaten interpoleren van tabel 3 en tabel 5 met betrekking tot één-patiënt query's totdat het experiment met inbegrip van geoptimaliseerde ARM in het protocol was uitgevoerd. Laten we deze experimenten voor toekomstige toepassingen. Een kritieke stap in het protocol is de selectie van gratis database, soortgelijke softwareversies van de afgelopen jaren, zodat we de exacte state-of-the-art van de drie technologieën kan vergelijken.
Dit is een van de eerste pogingen om rechtstreeks vergelijken relationele en NoSQL systemen die gebruikmaken van de eigenlijke, realistische en gestandaardiseerde medische informatie. Het specifieke systeem worden gebruikt hangt echter wel veel van op de werkelijke scenario en het probleem als opgelost8.

NoSQL (niet alleen SQL) DBMS hebben onlangs naar voren gekomen als een alternatief voor de traditionele relationele DBMS (RDMBS). RDBMS hebben gedomineerd de manier gegevens werden opgeslagen in databasesystemen voor decennia. Goed bestudeerde en begrepen relationele algebra en calculus hebben gegarandeerd de efficiëntie en consistentie van RDBMS1. NoSQL systemen zal niet worden substituten voor relationele systemen, maar ze kunnen voordelig gedragen in bepaalde scenario's en onder verschillende voorwaarden.
Sommige van deze bepaalde scenario's en omstandigheden zou optreden bij het ontwerpen van het voortbestaan van de database van Electronic Health Record (EMD) systemen gebruikt voor het beheer en de opslag van medische informatie. Om interoperabele en duurzame in de praktijk verschillende internationale normen zoals ISO/nl 13606, openEHR en HL72,3,4werden,5 gebruikt op de standaardisering van EMD-extracten.
Diverse standaarden zoals ISO/nl-13606 en openEHR hebben gescheiden informatie en kennis in twee verschillende niveaus van abstractie, vertegenwoordigd door de Reference Model (RM) en speciale datastructuren archetypengenoemd. Deze scheiding wordt vaak de dubbele model genoemd en hierdoor EMD-systemen als semantisch interoperabele en medische kennis evolueren zonder de hele EMD-systeem te herprogrammeren en, bijgevolg, naar onderhoudbaar en duurzame in de praktijk6 . De dubbele model ten uitvoer gelegd in gestandaardiseerde EMD-systemen vereist echter dat de organisatie van informatie een specifieke structuur volgt, en dit heeft ingrijpende gevolgen in de manier waarop die de databaseniveau persistentie van het systeem ontworpen7 is.
Object Relational Mapping (ORM)8 is een methodologie om een EMD-systeem met behulp van de relationele database paradigma. ORM kaarten uitvoerig de structuur van de gestandaardiseerde EMD extracten van XML (eXtensible Markup Language) bestanden die worden gebruikt door het systeem voor een relationele database. ORM construeert vele relationele tabellen die uitputtend na de structuur van de gestandaardiseerde extracten van EMD XML-bestanden. Deze relationele tabellen zijn gerelateerd door vele refererende sleutels en het resulterende systeem kan niet zeer efficiënt zijn.
De relationele verbeteringen in ORM hebben voorgesteld. het openEHR knooppunt + pad9 vermindert het aantal relationele tabellen door serializing substructuren van het hele extract xmldossier in BLOB's (binary large objects). Deze vereenvoudiging veroorzaakt echter complexe ophalen logica, beschadiging van complexe query's. Archetype relationele Mapping (ARM)10 genereert een databasemodel gedreven door archetypen, bouwen van een nieuwe relationele schema op basis van toewijzingen tussen archetypen en relationele tabellen. Enkele van de niet-medische informatie van het EMD-extract is dus verloren.
Veel documenten gebaseerde NoSQL databases hele documenten opslaan als hele BLOBs met inachtneming van een oorspronkelijke XML of JSON (JavaScript Object Notation) formaat. Dit betekent dat geen relationele tabellen worden geconstrueerd. Deze databases NoSQL geen schema hebben en ze ondersteunen geen ofwel joins of (zuur) eigenschappen11, dat wil zeggen, atomiciteit, consistentie, isolatie of duurzaamheid. Dientengevolge, kunnen zij zeer inefficiënt als een element van een document wordt verwezen naar elementen van dezelfde of andere dergelijke documenten met behulp van een indirecte koppeling. Dit gebeurt omdat, om redenen van consistentie, het geheel van de documenten waarnaar wordt verwezen moeten worden opeenvolgend verwerkt. Een niet-relationele database kan echter nog steeds geschikt als de belangrijkste taak van het DBMS een document-gebaseerde taak is. Dit is omdat de gegevens in een formulier mogen blijven meer nauw tot onderlinge aanpassing van de ware vertegenwoordiging met behulp van een document-based database voor NoSQL, al is dit ook te wijten aan het beleid van de speciale persistentie bereikt door EMD medische documenten (zie sectie discussie).
Het doel van deze methoden is om te demonstreren van verschillende experimenten te vergelijken van de uitvoering van de laag van de persistentie van een gestandaardiseerde EMD-systeem met behulp van drie verschillende databasebeheersystemen (DBMS): een relationele (MySQL) en twee NoSQL (documentgebaseerde MongoDB en native XML bestaan). Hun computationele complexiteit is berekend en vergeleken met behulp van drie verschillende toenemende grootte databases en zes verschillende complexiteit toenemende query's. De drie databaseservers zijn geïnstalleerd en lokaal geconfigureerd in dezelfde computer waar de query's zijn uitgevoerd. Zie de Tabel van materialen voor de technische details.
Concurrency experimenten zijn ook uitgevoerd om het vergelijken van de prestaties van relationele MySQL en NoSQL MongoDB databasebeheersystemen (DBMS). Ook zijn de beschreven ORM-verbeteringen (knooppunt + pad en ARM) vergeleken met behulp van relevante passende resultaten uit de literatuur10.
Database managementsystemen evolueren voortdurend in een versneld tempo. Niemand zou denken over deze exponentiële ontwikkeling toen de enige bestaande paradigma het relationele model was. Neem een voorbeeld, zie bijvoorbeeld12, waar een model werd voorgesteld om de verbeterde relationele databases responstijd behoud van de ACID-eigenschappen.

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

toenemende complexiteit query's uitvoeren in relationele (mysql) en nosql (mongodb en bestaan) grootte groeiende iso/nl 13606 gestandaardiseerde emd databases

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

Dit onderzoek toont een protocol bij het beoordelen van de computationele complexiteit van het opvragen van relationele en niet-relationele (NoSQL (niet alleen Structured Query Language)) gestandaardiseerd elektronische medische record (EMD) medische informatie databasesystemen (DBMS). Het maakt gebruik van een set van drie verdubbeling middelgrote databases, d.w.z. databases opslaan van 5000, 10.000 en 20.000 realistische gestandaardiseerde extracten van EMD, in drie verschillende databasebeheersystemen (DBMS): relationele MySQL object-relationele mapping (ORM), document-gebaseerd NoSQL MongoDB, als inheemse extensible markup language (XML) NoSQL bestaan.
De gemiddelde responstijden voor zes toenemende complexiteit query's werden berekend, en de resultaten toonden een lineaire gedrag in de NoSQL gevallen. In het veld NoSQL presenteert MongoDB een veel vlakker lineaire helling dan bestaan.
NoSQL systemen wellicht ook meer geschikt om gestandaardiseerde medische informatiesystemen vanwege de speciale aard van het bijgewerkte beleid van medische informatie, die mag geen afbreuk doen aan de consistentie en efficiëntie van de gegevens die zijn opgeslagen in databases van NoSQL.
Een beperking van dit protocol is het gebrek aan directe resultaten van de verbeterde relationele systemen zoals archetype relationele mapping (ARM) met dezelfde gegevens. Echter de interpolatie van verdubbeling-grootte databaseresultaten die gepresenteerd in de literatuur en andere gepubliceerde resultaten blijkt dat NoSQL systemen zou meer passend is in vele specifieke scenario's en problemen op te lossen. Bijvoorbeeld, kan NoSQL dienstig voor documentgebaseerde taken zoals het EMD extracten gebruikt in de klinische praktijk, of edition en visualisatie of situaties waarin het doel is niet alleen voor query medische informatie, maar ook voor het EMD in precies de oorspronkelijke vorm te herstellen.

Zes verschillende query's uitgevoerd op realistische gestandaardiseerde extracten van EMD met informatie over de problemen van patiënten, met inbegrip van hun namen, de eerste en de laatste datums en de ernst, zijn vermeld in tabel 1.
Gemiddelde responstijden van de zes zoekopdrachten in de drie databases verdubbeling-grootte in elk DBMS staan in de tabellen 2-4. Cijfers 1-6 de dezelfde resultaten grafisch tonen (merk op dat de verticale assen zeer verschillende schalen in deze cijfers gebruiken).
Het sterke lineair gedrag van computationele complexiteit is duidelijk tijdens alle query's van de NoSQL databases, hoewel met passende voorzichtigheid als gevolg van de relatief geringe omvang van de 3 datasets gebruikt. De relationele database van ORM blijkt echter een onduidelijk lineaire gedrag. De database MongoDB heeft een veel vlakker helling dan de eXist database.
Resultaten door de verbeterde relationele systemen besproken in de inleiding gepubliceerd in de literatuur kunnen worden gevonden in tabel 5. Interpoleren MongoDB resultaten uit tabel 3 met soortgelijke vragen en database maten van ARM resultaten van tabel 5 is gelijk aan beide databasesystemen in Q1, maar gunsten MongoDB in Q3.
De resultaten van de experimenten concurrency kunnen worden gevonden in tabel 5 en tabel6. MongoDB verslaat MySQL, beide in doorvoer en responstijd. In feite, MongoDB gedraagt zich beter in concurrency dan los, en staat als een indrukwekkende database bij gelijktijdige uitvoering.
<img alt="Figure 1" class="xfigimg" src="/files/ftp_upload/57439/57439fig1.jpg"> Figuur 1 : Algoritmische complexiteit van ORM MySQL, MongoDB, en bestaan van DBMS voor query's Q1 en Q4. Dit cijfer is gewijzigd van7 met behulp van Creative Commons-licentie (http://creativecommons.org/ licenses/by/4.0/) en toont reactietijd in seconden voor 5.000, 10.000 en 20.000 middelgrote EMD extracten databases voor elk DBMS en query's Q1 en Q4. <a href="//cloudflare.jove.com/files/ftp_upload/57439/57439fig1large.jpg" target="_blank">Klik hier voor een grotere versie van dit cijfer.</a>
<img alt="Figure 2" class="xfigimg" src="/files/ftp_upload/57439/57439fig2.jpg"> Figuur 2 : Algoritmische complexiteit van ORM MySQL DBMS voor query Q2. Deze figuur toont reactietijd in seconden voor 5.000, 10.000 en 20.000 middelgrote EMD extracten ORM MySQL database voor query Q2. <a href="//cloudflare.jove.com/files/ftp_upload/57439/57439fig2large.jpg" target="_blank">Klik hier voor een grotere versie van dit cijfer.</a>
<img alt="Figure 3" class="xfigimg" src="/files/ftp_upload/57439/57439fig3.jpg"> Figuur 3 : Algoritmische complexiteit van MongoDB en DBMS bestaan voor query Q2 en Q5. Dit cijfer is gewijzigd van7 met behulp van Creative Commons-licentie (http://creativecommons.org/licenses/ door / 4.0) en toont reactietijd in seconden voor 5.000, 10.000 en 20.000 middelgrote EMD extracten databases voor elk DBMS en query's Q2 en Q5. <a href="//cloudflare.jove.com/files/ftp_upload/57439/57439fig3large.jpg" target="_blank">Klik hier voor een grotere versie van dit cijfer.</a>
<img alt="Figure 4" class="xfigimg" src="/files/ftp_upload/57439/57439fig4.jpg"> Figuur 4 : Algoritmische complexiteit van ORM MySQL DBMS voor query's Q3 en Q5. Toont reactietijd in seconden voor 5.000, 10.000 en 20.000 middelgrote EMD extracten databases voor elk DBMS en query's Q3 en Q5. <a href="//cloudflare.jove.com/files/ftp_upload/57439/57439fig4large.jpg" target="_blank">Klik hier voor een grotere versie van dit cijfer.</a>
<img alt="Figure 5" class="xfigimg" src="/files/ftp_upload/57439/57439fig5.jpg"> Figuur 5: algoritmische complexiteit van eXist en MongoDB DBMS voor query Q3. Dit cijfer is gewijzigd van7 met behulp van Creative Commons-licentie (http://creativecommons.org/licenses/ door/4.0 /) en toont reactietijd in seconden voor 5.000, 10.000 en 20.000 middelgrote EMD extracten databases voor elk DBMS en de query Q3. <a href="//cloudflare.jove.com/files/ftp_upload/57439/57439fig5large.jpg" target="_blank">Klik hier voor een grotere versie van dit cijfer.</a>
<img alt="Figure 6" class="xfigimg" src="/files/ftp_upload/57439/57439fig6.jpg"> Figuur 6 : Algoritmische complexiteit van ORM MySQL, bestaan en MongoDB DBMS voor query V6. Dit cijfer is gewijzigd van7 met behulp van Creative Commons-licentie (http://creativecommons.org/licenses/ door/4.0 /) en toont reactietijd in seconden voor 5.000, 10.000 en 20.000 middelgrote EMD extracten databases voor elk DBMS en de query V6. <a href="//cloudflare.jove.com/files/ftp_upload/57439/57439fig6large.jpg" target="_blank">Klik hier voor een grotere versie van dit cijfer.</a>
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td></td>
			<td>Query</td>
		</tr>
<tr>
<td>Q1</td>
			<td>Alle problemen van een enkele patiënt te vinden</td>
		</tr>
<tr>
<td>Q2</td>
			<td>Alle problemen van alle patiënten te vinden</td>
		</tr>
<tr>
<td>Q3</td>
			<td>Zoeken oorspronkelijke datum, resolutie datum en ernst</td>
		</tr>
<tr>
<td></td>
			<td>van een enkel probleem van een enkele patiënt</td>
		</tr>
<tr>
<td>Q4</td>
			<td>Zoeken oorspronkelijke datum, resolutie datum en ernst</td>
		</tr>
<tr>
<td></td>
			<td>van alle problemen-probleem van een enkele patiënt</td>
		</tr>
<tr>
<td>Q5</td>
			<td>Zoeken oorspronkelijke datum, resolutie datum en ernst</td>
		</tr>
<tr>
<td></td>
			<td>van alle problemen probleem van alle patiënten</td>
		</tr>
<tr>
<td>Q6</td>
			<td>Vinden van alle patiënten met probleem 'faryngitis',</td>
		</tr>
<tr>
<td></td>
			<td>eerste datum > ' 16/10/2007 =', resolutie datum</td>
		</tr>
<tr>
<td></td>
			<td>< = ' 06/05/2008 ' en ernst 'hoog'</td>
		</tr>
</tbody></table>Tabel 1: de zes query's uitgevoerd op de relationele en NoSQL databases met gestandaardiseerde EMD extracten over problemen van patiënten. Deze tabel is gewijzigd van7 met behulp van Creative Commons-licentie (http://creativecommons.org/ licenses/by/4.0/) en geeft de zes complexiteit groeiende query's uitgevoerd op de drie grootte groeiende databases voor elk DBMS uitgedrukt in natuurlijke taal.
<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 docs</td>
			<td>20.000 docs</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>Q6 (s)</td>
			<td>1.4382</td>
			<td>2.4844</td>
			<td>183.4979</td>
		</tr>
<tr>
<td>Databaseomvang</td>
			<td>4.6 GB</td>
			<td>9.4 GB</td>
			<td>19.4 GB</td>
		</tr>
<tr>
<td>Totale extracten</td>
			<td>5000</td>
			<td>10.000</td>
			<td>20.000</td>
		</tr>
</tbody></table>Tabel 2: gemiddelde reactietijd in seconden van de zes vragen over verdubbeling-grootte databases van de ORM MySQL relationele DBMS. Deze tabel toont zes responstijden voor elke query voor de drie verdubbeling middelgrote databases met behulp van de ORM MySQL relationele DBMS en de grootte in het geheugen van de drie databases.
<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 docs</td>
			<td>20.000 docs</td>
			<td>helling (*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>Q6 (s)</td>
			<td>9.5153</td>
			<td>18.5566</td>
			<td>36.7805</td>
			<td>1,817.68</td>
		</tr>
<tr>
<td>Databaseomvang</td>
			<td>1,95 GB</td>
			<td>3.95GB</td>
			<td>7,95 GB</td>
			<td></td>
		</tr>
<tr>
<td>Totale extracten</td>
			<td>5000</td>
			<td>10.000</td>
			<td>20.000</td>
			<td></td>
		</tr>
</tbody></table>Tabel 3: gemiddelde reactietijd in seconden van de zes vragen over verdubbeling-grootte databases van de MongoDB NoSQL DBMS. Deze tabel is gewijzigd van7 met behulp van Creative Commons-licentie (http://creativecommons.org/ licenses/by/4.0/) en toont de zes reactietijden van elke query voor de drie verdubbeling middelgrote databases met behulp van de NoSQL MongoDB DBMS en de grootte in het geheugen van de drie databases. De lineaire helling van elke query wordt ook weergegeven.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td>Bestaan</td>
			<td>5000 docs</td>
			<td>10.000 docs</td>
			<td>20.000 docs</td>
			<td>helling (*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>Q6 (s)</td>
			<td>68.3798</td>
			<td>138.9987</td>
			<td>475.2663</td>
			<td>27,125.82</td>
		</tr>
<tr>
<td>Databaseomvang</td>
			<td>1,25 GB</td>
			<td>2.54GB</td>
			<td>5,12 GB</td>
			<td></td>
		</tr>
<tr>
<td>Totale extracten</td>
			<td>5000</td>
			<td>10.000</td>
			<td>20.000</td>
			<td></td>
		</tr>
</tbody></table>Tabel 4: gemiddelde reactietijd in seconden van de zes vragen over verdubbeling-grootte databases van de eXist NoSQL DBMS. Deze tabel is gewijzigd van7 met behulp van Creative Commons-licentie (http://creativecommons.org/ licenses/by/4.0/) en toont de zes reactietijden van elke query voor de drie verdubbeling middelgrote databases die gebruikmaken van de NoSQL bestaan DBMS en de grootte in het geheugen van de drie databases. De lineaire helling van elke query wordt ook weergegeven.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td></td>
			<td>ARM papier</td>
			<td>ARM (s)</td>
			<td>Knooppunt + pad (s)</td>
		</tr>
<tr>
<td>Q1</td>
			<td>Query 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>Databaseomvang</td>
			<td>2.90GB</td>
			<td>43.87GB</td>
		</tr>
<tr>
<td></td>
			<td>Totale extracten</td>
			<td>29,743</td>
			<td>29,743</td>
		</tr>
</tbody></table>Tabel 5: gemiddelde reactietijd in seconden van query's vergelijkbaar met Q1 en Q3 van de verbeterde relationele systemen aangeboden 10 . Deze tabel is gewijzigd van7 met behulp van Creative Commons-licentie (http://creativecommons.org/ licenses/by/4.0/) en toont de twee meeste-soortgelijke vragen aan Q1 en Q3 gepresenteerd in10 overeenkomt met twee verbeterde relationele databasesystemen en hun responstijden. De twee database maten worden ook weergegeven.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td>ORM/MySQL</td>
			<td>Doorvoer</td>
			<td>Reactietijd</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>Tabel 6: gemiddelde doorvoer en reactie tijd in seconden van query's Q1, Q3 en Q4 van ORM MySQL relationele DBMS in gelijktijdige uitvoering. Deze tabel is gewijzigd van7 met behulp van Creative Commons-licentie (http://creativecommons.org/ licenses/by/4.0/) en toont de hoogste gemiddelde doorvoer van de drie single-patiënt queries en hun gemiddelde responstijden in de concurrent uitvoering experiment met behulp van de ORM MySQL relationele systeem.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td>MongoDB</td>
			<td>Doorvoer</td>
			<td>Reactietijd</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>Tabel 7: gemiddelde doorvoer en reactie tijd in seconden van query's Q1, Q3 en Q4 van MongoDB NoSQL DBMS in gelijktijdige uitvoering. Deze tabel is gewijzigd van7 met behulp van Creative Commons-licentie (http://creativecommons.org/ licenses/by/4.0/) en toont de hoogste gemiddelde doorvoer van de drie single-patiënt queries en hun gemiddelde responstijden in de concurrent uitvoering experiment met behulp van de MongoDB NoSQL systeem.
Aanvullende figuur 1: de schermafdruk toont het scherm van de software om te verbinden met de server MySQL. <a href="//cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_1.png" target="_blank">Klik hier voor het downloaden van dit cijfer.</a>
Aanvullende figuur 2: de schermafdruk toont de SQL-interface naar de mysqlserver waar de eerste SQL-query is geschreven. <a href="//cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_2.png" target="_blank">Klik hier voor het downloaden van dit cijfer.</a>
Aanvullende figuur 3: The MongoDB 2.6 localhost server wordt gestart met behulp van een DOS-venster systeem door het uitvoeren van de server mongod. <a href="//cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_3.png" target="_blank">Klik hier voor het downloaden van dit cijfer.</a>
Aanvullende figuur 4: de schermafdruk toont de query in de tekstvakken van de opbouwfunctie voor Query's worden geschreven in stappen 5.7.1 via 5.7.4. Screenshot toont stap 5.7.3-fouten te vermijden. <a href="//cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_4.png" target="_blank">Klik hier voor het downloaden van dit cijfer.</a>
Aanvullende figuur 5: de schermafdruk toont de stap 5.7.6. <a href="//cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_5.png" target="_blank">Klik hier voor het downloaden van dit cijfer.</a>
Aanvullende figuur 6: de screenshot illustreert het schrijven van de XPath-query in theupper deel van het dialoogvenster. <a href="//cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_6.png" target="_blank">Klik hier voor het downloaden van dit cijfer.</a>

Deze studie vergelijkt relationele en niet-relationele (NoSQL) gestandaardiseerd medische informatiesystemen. De computationele complexiteit van de responstijden van het opvragen van dergelijke databasebeheersystemen (DBMS) wordt berekend met behulp van verdubbeling middelgrote databases. Deze resultaten helpen de discussie van de geschiktheid van elke database benadering van verschillende scenario's en problemen.

Toenemende complexiteit query's uitvoeren in relationele (MySQL) en NoSQL (MongoDB en bestaan) grootte groeiende ISO/nl 13606 gestandaardiseerde EMD Databases

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

Het algemene doel van dit experiment is om de computationele complexiteit van relationele en niet-relationele niet alleen gestructureerde querytaal of NoSQL databasesystemen te vergelijken, zoals gemeten door hun responstijden op groeiende querycomplexiteit. Deze methode kan helpen bij het beantwoorden van sleutelvraagstukken in het veld van databasebeheersystemen, zoals welke soorten query's geschikter zijn voor welke soorten databasesystemen. Het belangrijkste voordeel van deze techniek is dat het de responstijden op query's voor dubbele databases van elk type vergelijkt, samen met de computationele complexiteit die moet worden berekend. En dus kan deze methode inzicht bieden in MySQL MongoDB en overtollige databasesystemen.Het kan ook worden toegepast op andere relationele, document-gebaseerde en native XML-systemen zoals SQL server en base X. We hoorden voor het eerst over deze methode toen we een persistent systeem moesten selecteren voor een elektronisch gezondheidsrecordsysteem. Om query's met groeiende complexiteit te ontwerpen en uit te voeren met niet-automatisch gebouwde indices in een relationele MySQL-database. Maak verbinding met de MySQL-server en selecteer de databasenaam.Selecteer de relationele tabel binnen het indexveld en open het structuurtabblad. Selecteer de kolom waar de index zal worden gebouwd en klik op index. De SQL-zin die de index bouwt, verschijnt, gevolgd door een bericht dat de zin met succes is gebouwd.Om de eerste query uit te voeren, selecteer de databasenaam en open het SQL-tabblad. Voer de SQL-code van de eerste query in en klik op doorgaan. De eerste scherm van de lijst met resultaten verschijnt met het bericht voor de uitvoeringstijd van de query.Om query's met groeiende complexiteit te ontwerpen en uit te voeren en een niet-relationele, niet alleen of NoSQL Mongo-database, start de Mongo-database grafische gebruikersinterface en de Mongo-database 2.6-server door het Mongo-programma uit te voeren vanuit een DOS-systeemvenster. Verbind de Mongo-database grafische gebruikersinterface met de lokale hostserver via poort 27017 en selecteer het verbindingsmenu. Voer een naam in voor de verbinding en voer de lokale hostlocatie in het tekstvak van de databaseserver in en klik vervolgens op verbinding maken.Een boom met de huidige databases zou moeten verschijnen. Breid de Mongo-database uit. Selecteer de gewenste verzameling en open het verzamelingsmenu.Om de eerste Mongo-databasequery uit te voeren, dubbelklik op de querybuilder en de queryveldknoppen. Voer de velden van de Mongo-databasequery in het tekstvak van de querypanelen in en de waarde van de query in het waardetekstvak van de querypanelen. Dubbelklik op het projectieveld van de querybuilder en voer de eerste projectie in het projectietekstvak in.Dubbelklik op het projectieveld om een nieuw projectietekstvak toe te voegen en voer de tweede projectie in en klik vervolgens op spelen om de query uit te voeren en de querycode in het querycode-tabblad te visualiseren. De details van het resultaat zijn te bekijken onder de verklaring en resultaten-tab. Om query's met groeiende complexiteit te ontwerpen en uit te voeren in een NoSQL EXist-database, start de EXist-database en open de Java-adminclient.Klik op verbinding maken met de database en selecteer de database. Klik op database raadplegen met X path. Het raadplegingsdialoogvenster verschijnt.Voer vervolgens de eerste X path-query uit. In deze tabel worden zes verschillende query's getoond die zijn uitgevoerd op realistische gestandaardiseerde elektronische gezondheidsrecordextracten die informatie bevatten over de problemen van patiënten, inclusief hun namen, begin- en einddatums en ernst. De gemiddelde responstijd van de zes query's en de drie verdubbelde grootte databases in elk databasebeheersysteem, toont een lang lineair gedrag van computationele complexiteit door alle query's van de niet-relationele databases heen, wat niet wordt waargenomen in relationele object-relationele toewijzingsdatabaseanalyse.Het interpoleren van Mongo-databaseresultaten met vergelijkbare query's en databasegroottes van archetype relationele toewijzingsresultaten genereert gelijke resultaten in beide databasesystemen voor de eerste query, maar met meer gunstige resultaten bepaald met behulp van de Mongo-database voor de derde query. In de concurrentie-experimenten is de Mongo-database te prefereren boven de MySQl-database, zowel in doorvoer als responstijden, waarbij de Mongo-database zich beter gedraagt in concurrency dan een isolatie en staat als een indrukwekkende database in gelijktijdige uitvoering. Nou, ik dacht dat het belangrijk is om te onthouden dat alle servers lokaal in dezelfde machines moeten worden onderhouden, aangezien de client de query's uitvoert.Volgend op deze procedure kunnen andere methoden zoals het gebruik van andere soorten databasesystemen worden uitgevoerd om aanvullende vragen te beantwoorden, zoals kan een type database bestaan en winnen in zowel enkele als alle patiëntenquery's? Na de ontwikkeling van deze techniek heeft het een weg geopend voor onderzoekers op het gebied van algoritmische complexiteit om vergelijkende databaseprestaties in verschillende soorten databasesystemen te verkennen. Na het bekijken van deze video, zou u een goed begrip moeten hebben van hoe u query's met groeiende complexiteit kunt uitvoeren in databases met groeiende grootte van databasesystemen van zeer verschillende soorten.

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

Research

JoVE Journal

Medicine

Geneeskunde

We presenteren een protocol en de bijbehorende programmacode evenals metagegevens monsters ter ondersteuning van een cloud-gebaseerde automatische identificatie van zinnen-categorie vereniging van unieke concepten in het domein van de geselecteerde kennis van de gebruiker in de biomedische literatuur. De vereniging van de zin-categorie gekwantificeerd door dit protocol kan vergemakkelijken diepgaande analyse in het domein van de geselecteerde kennis.

Cloud-gebaseerde zin Mining en analyse van User-Defined Phrase-categorie vereniging in biomedische publicaties

Veel onderzoekers genereren "middelgrote", lage-snelheid, en multidimensionale gegevens, die efficiënter kunnen worden beheerd met databases in plaats van spreadsheets. Hier bieden we een conceptueel overzicht van databases, waaronder het visualiseren van multidimensionale gegevens, het koppelen van tabellen in relationele database structuren, het in kaart brengen van semi-geautomatiseerde gegevens pijpleidingen en het gebruik van de database om gegevens betekenis te verhelderiseren.

Databases voor het efficiënt beheren van middelgrote, lage snelheid, multidimensionale data in weefsel engineering

TBase combineert een elektronisch patiëntendossier met een innovatieve onderzoeksdatabase voor ontvangers van niertransplantaties. TBase is gebouwd op een in-memory databaseplatform, verbonden met verschillende ziekenhuissystemen en gebruikt voor reguliere poliklinische zorg. Het integreert automatisch alle relevante klinische gegevens, inclusief transplantatiespecifieke gegevens, waardoor een unieke onderzoeksdatabase ontstaat.

TBase - een geïntegreerde elektronische patiëntendossier- en onderzoeksdatabase voor ontvangers van niertransplantaties

gP2S is een webapplicatie voor het volgen van cryoEM experimenten. De belangrijkste functies worden beschreven, net als de stappen die nodig zijn om de toepassing te installeren en te configureren. Eenmaal geconfigureerd, stelt de applicatie het mogelijk om metadata in verband met negatieve vlekken en cryoEM-experimenten nauwkeurig vast te leggen.

gP2S, een informatiebeheersysteem voor CryoEM-experimenten

Postoperatieve ileus (POI) is een complicatie van abdominale chirurgie leidt tot verhoogde morbiditeit en een langdurig verblijf in het ziekenhuis. Omdat profylactische of therapeutische strategieën ontbreken geïntensiveerd onderzoek is noodzakelijk. Daarom hebben we een gestandaardiseerde en haalbaar muismodel naar de pathofysiologie van POI te onderzoeken en mogelijke therapeutische opties te bestuderen.

Functionele Evaluatie van darmmotiliteit en de darmwand ontsteking in Knaagdieren: Analyses in een gestandaardiseerd model van Intestinal Manipulatie

Laesie Explorer (LE) is een semi-automatische, beeldverwerking pijplijn ontwikkeld om regionale hersenweefsel en subcorticale hyperintensity laesie volumetrics verkrijgen van structurele MRI van de ziekte van Alzheimer en normale ouderen. Om een ​​hoog niveau van nauwkeurigheid en betrouwbaarheid te garanderen, de volgende is een video-geleide, gestandaardiseerd protocol voor handmatige procedures LE's.

Laesie Explorer: A-Video geleid, gestandaardiseerd protocol voor nauwkeurig en betrouwbaar MRI-afgeleide Volumetrics bij de ziekte van Alzheimer en normale Ouderen

We beschrijven een overdekt, draagbare, gestandaardiseerde cursus die gebruikt kunnen worden om obstakel vermijden evalueren bij personen die hebben ultralow visie. De cursus is relatief goedkoop, eenvoudig te beheren, en is gebleken betrouwbaar en reproduceerbaar.

Een gestandaardiseerde Obstacle Course voor het beoordelen van de visuele functie in Ultra Low Vision en Artificial Vision

Dit protocol beschrijft een osteosynthesetechniek met behulp van een intramedullaire vergrendelingsnagel voor gestandaardiseerde fixatie van femurosteotomieën, die kan worden gebruikt om normale en defecte botgenezing bij muizen te analyseren.

Een Intramedullaire Locking Nail voor gestandaardiseerde Fixatie van dijbeen osteotomieën to Normal en Defecte Bone Healing Analyseren in Muizen

Hier presenteren we een gestandaardiseerd protocol voor het meten van de nasale potentiaalverschil (NPD). Cystic fibrosis transmembrane huidgeleiding regelgever (CFTR) en epitheliale natrium kanaal (ENaC) functie worden geëvalueerd door de verandering in de spanning over de nasale epitheel na superfusion van oplossingen die ion kanaal activiteit, wijzigen mits een resultaat maatregel.

Gestandaardiseerde meting van nasale membraan Transepithelial potentieel verschil (NPD)

Literatuur databases worden vaak gebruikt om publicaties te beoordelen in een bepaald onderwerp, discipline, land of regio van de wereld, een praktijk die bekendstaat als bibliometrische analyse. Het huidige protocol Details over het gebruik van PubMed, Scopus, en web of Science databases te doen bibliometrische analyse.

Het vergelijken van bibliometrische analyse met behulp van PubMed, Scopus en web of Science databases

Leer de computationele complexiteit van relationele en NoSQL-databases vergelijken door responsietijden bij groeiende query's te analyseren. Deze methode biedt inzicht in MySQL en MongoDB prestaties.

Toenemende complexiteit querys uitvoeren in relationele (MySQL) en NoSQL (MongoDB en bestaan) grootte groeiende ISO/nl 13606 gestandaardiseerde EMD Databases (Video) | JoVE Journal

Toenemende complexiteit query's uitvoeren in relationele (MySQL) en NoSQL (MongoDB en bestaan) grootte groeiende ISO/nl 13606 gestandaardiseerde EMD Databases

Meer video's verkennen