Name: Wykonywanie zapytań zwiększających złożoność w relacyjnych (MySQL) i NoSQL (MongoDB i EXist) bazach danych EHR zgodnych z normą ISO/EN 13606 (Wideo) | JoVE Journal
Uploaded: 2018-03-19T14:30:00.000+00:00
Duration: 7 min 26 s
Description: Poznaj metodę porównywania złożoności obliczeniowej baz danych SQL i NoSQL poprzez analizę czasów odpowiedzi na zapytania o rosnącej złożoności. Badanie obejmuje MySQL, MongoDB i EXist.

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

Autorzy chcieliby podziękować Dr Dipakowi Kalrze, liderowi grupy zadaniowej EHRCom, która zdefiniowała normę ISO/EN 13606 oraz jego zespołowi z University College London za zgodę na użycie schematu XML ISO/EN 13606 W3C.
Ta praca była wspierana przez Instituto de Salud Carlos III [numery grantów PI15/00321, PI15/00003, PI1500831, PI15CIII/00010 i RD16CIII].

1. Zbuduj relacyjny baz danych MySQL DBMS do przechowywania trzech dwuwymiarowych standardowych baz danych ekstraktów EHR
<ol>
	<li>Zaimportuj schemat XML W3C (World Wide Web Consortium) odpowiadający typom danych ISO/EN13606 RM i ISO21090 do "Java IDE" (zintegrowane środowisko programistyczne). 
	UWAGA: ISO to skrót od International Standards Organization (Międzynarodowa Organizacja Normalizacyjna). EN to skrót od European Norm (norma europejska).</li>
	<li>Uruchom wtyczkę JAXB (Java XML Binding) w IDE; spowoduje to utworzenie klas Java odpowiadających strukturze elementów EHR i wyodrębnienie plików XML.</li>
	<li>Ręcznie oznacz klasy Java utworzone za pomocą etykiet JPA. Te etykiety odnoszą się do kardynalności i innych relacji między tabelami relacyjnymi bazy danych MySQL.</li>
	<li>Zaimportuj biblioteki JPA (Java Persistence API) do IDE i wykonaj metodę, która buduje bazę danych MySQL z oznaczonych klas Java.</li>
	<li>Utwórz trzy katalogi z 5 000, 10 000 i 20 000 realistycznych plików XML wyodrębnianych przez EHR.</li>
	<li>Wykonaj metodę JPA, aby załadować ekstrakt XML do MySQL DBMS we wszystkich ekstraktach z katalogu 5 000 ekstraktów.</li>
	<li>Powtórz krok 1.6 dwa razy, raz z katalogiem 10 000 ekstraktów i raz z katalogiem 20 000 ekstraktów.</li>
</ol>
2. Zbuduj bazę danych NoSQL MongoDB do przechowywania trzech dwuwymiarowych standardowych baz danych ekstraktów EHR
<ol>
	<li>Przetwarzanie każdego z trzech katalogów zawierających 5 000, 10 000 i 20 000 realistycznych plików EHR wyodrębnia pliki XML za pomocą standardowego programu do konwersji plików XML na pliki JSON, takie jak json.org.XML. Należy utworzyć trzy katalogi z plikami JSON 5 000, 10 000 i 20 000</li>.
	<li>Uruchom MongoDB GUI (graficzny interfejs użytkownika, patrz tabela materiałów).</li>
	<li>Uruchom serwer MongoDB 2.6 wykonując program mongod z okna systemu DOS (Disk Operating System).</li>
	<li>Połącz graficzny interfejs użytkownika bazy danych MongoDB z serwerem hosta lokalnego przy użyciu portu 27017.
	<ol>
		<li>Wybierz menu "Połącz".</li>
		<li>Wpisz nazwę połączenia (na przykład "pierwszy").</li>
		<li>Wpisz localhost:27017 w polu tekstowym serwera bazy danych.</li>
		<li>Naciśnij przycisk "Połącz"; po lewej stronie powinno pojawić się drzewo z aktualnymi bazami danych.</li>
	</ol>
	</li>
	<li>Zbuduj bazę danych zawierającą 5 000 standaryzowanych wyciągów z elektronicznej dokumentacji medycznej.
	<ol>
		<li>Kliknij nazwę połączenia w górnej części drzewa po lewej stronie.</li>
		<li>Wybierz menu "Plik".</li>
		<li>Wybierz "Dodaj bazę danych".</li>
		<li>Wprowadź nazwę bazy danych w wyświetlonym oknie dialogowym.</li>
		<li>Kliknij przycisk OK.</li>
	</ol>
	</li>
	<li>Zbuduj kolekcję zawierającą 5 000 standaryzowanych ekstraktów elektronicznej dokumentacji medycznej.
	<ol>
		<li>Kliknij nazwę bazy danych w drzewie po lewej stronie.</li>
		<li>Wybierz menu "Baza danych".</li>
		<li>Wybierz "Dodaj Kolekcję".</li>
		<li>Wprowadź nazwę kolekcji w wyświetlonym oknie dialogowym.</li>
		<li>Kliknij " Utwórz".</li>
		<li>Kliknij na nazwę kolekcji.</li>
		<li>Wybierz menu "Importuj".</li>
		<li>Wybierz przycisk opcji ''JSON - mongo shell / / mongoexport'.</li>
		<li>Kliknij "Dalej".</li>
		<li>Naciśnij przycisk "Dodaj pliki źródłowe".</li>
		<li>Poruszaj się po komputerze za pomocą okna dialogowego.</li>
		<li>Otwórz katalog zawierający 5 000 plików wyodrębniania JSON.</li>
		<li>Zaznacz wszystkie pliki w katalogu.</li>
		<li>Naciśnij "Otwórz". Lista plików JSON powinna pojawić się w oknie dialogowym Importowanie.</li>
		<li>Naciśnij "Dalej"; po lewej stronie pojawi się podgląd nowej kolekcji w bazie danych.</li>
		<li>Naciśnij "Dalej".</li>
		<li>Naciśnij "Rozpocznij import". Postęp importu jest wyświetlany na dole po lewej stronie, wskazując liczbę zaimportowanych plików i czas, który upłynął.</li>
	</ol>
	</li>
	<li>Powtórz kroki 5 i 6, aby utworzyć kolekcję 10 000 standardowych fragmentów elektronicznej dokumentacji medycznej.</li>
	<li>Powtórz kroki 5 i 6, aby utworzyć kolekcję 20 000 standardowych fragmentów elektronicznej dokumentacji medycznej.</li>
</ol>
3. Zbuduj bazę danych NoSQL eXist DBMS do przechowywania trzech dwuwymiarowych standardowych baz danych ekstraktów EHR
<ol>
	<li>Uruchom bazę danych eXist.</li>
	<li>Korzystając z ikony bazy danych, otwórz klienta Java Admin Client.</li>
	<li>Wprowadź hasło administratora.</li>
	<li>Naciśnij przycisk "Połącz".</li>
	<li>Zbuduj kolekcję zawierającą 5 000 standaryzowanych ekstraktów elektronicznej dokumentacji medycznej.
	<ol>
		<li>Na pasku narzędzi wybierz menu "Utwórz nową kolekcję".</li>
		<li>W wyświetlonym oknie dialogowym wpisz nazwę nowej kolekcji.</li>
		<li>Kliknij "akceptuj"; pojawi się nowa kolekcja.</li>
		<li>Wybierz nazwę kolekcji.</li>
		<li>Na pasku narzędzi wybierz menu "Przechowuj pliki w bazie danych".</li>
		<li>Nawiguj po komputerze za pomocą okna dialogowego.</li>
		<li>Wybierz katalog zawierający 5 000 standardowych plików wyodrębniania XML.</li>
		<li>Kliknij przycisk "Wybierz pliki lub katalogi do przechowywania". Należy zauważyć, że zostanie wyświetlone okno dialogowe pokazujące postęp, przechowywane pliki i procent utworzonej bazy danych.</li>
	</ol>
	</li>
	<li>Powtórz krok 5, aby utworzyć kolekcję zawierającą 10 000 standaryzowanych ekstraktów EHR.</li>
	<li>Powtórz krok 5, aby utworzyć kolekcję zawierającą 20 000 standaryzowanych ekstraktów EHR.</li>
</ol>
4. Projektuj i realizuj w 3 relacyjnych bazach danych MySQL 6 zapytań zwiększających złożoność
<ol>
	<li>Zaprojektuj sześć zapytań zwiększających złożoność zgodnie z archetypami używanymi przez ekstrakty EHR.</li>
	<li>Zaprogramuj skrypt SQL z pierwszym zapytaniem w bazie danych MySQL. SQL musi dostosować się do specjalnej struktury bazy danych MySQL ze względu na standaryzację ekstraktów (archetypy). Baza danych odwzorowuje całą strukturę ekstraktów. W rezultacie zapytanie SQL jest dość złożone.</li>
	<li>Zidentyfikuj atrybuty baz danych, które przyspieszyłyby czas odpowiedzi na zapytania, gdyby został na nich zbudowany indeks, a następnie skonstruuj takie indeksy, chociaż większość indeksów jest tworzona automatycznie przez system DBMS.</li>
	<li>Jeśli zapytanie wymaga indeksu, który nie jest tworzony automatycznie, skompiluj go ręcznie.
	<ol>
		<li>Połącz się z serwerem MySQL (rysunek uzupełniający 1).</li>
		<li>Wybierz i kliknij nazwę bazy danych po lewej stronie.</li>
		<li>Wybierz i kliknij tabelę relacyjną, w której znajduje się indeksowane pole.</li>
		<li>Kliknij zakładkę "Struktura".</li>
		<li>Wybierz i kliknij kolumnę, w której zostanie zbudowany indeks.</li>
		<li>Kliknij "indeks". Zauważ, że pojawi się zdanie SQL budujące indeks i pojawi się komunikat informujący, że zdanie zostało pomyślnie zbudowane.</li>
	</ol>
	</li>
	<li>Wykonaj pierwsze zapytanie.
	<ol>
		<li>Wybierz i kliknij nazwę bazy danych po lewej stronie.</li>
		<li>Kliknij zakładkę "SQL".</li>
		<li>Wpisz lub wklej kod SQL pierwszego zapytania (patrz rysunek uzupełniający 2).</li>
		<li>Naciśnij "kontynuuj". Należy zauważyć, że zostanie wyświetlony pierwszy ekran listy wyników wraz z komunikatem z czasem wykonania zapytania.</li>
		<li>Powtórz wykonanie 5 razy i oblicz średni czas odpowiedzi.</li>
	</ol>
	</li>
	<li>Powtórz krok 5 z zapytaniami od 2 do 6.</li>
	<li>Wykonaj cały proces trzy razy, korzystając z baz danych 5 000, 10 000 i 20 000 ekstraktów.</li>
</ol>
5. Projektowanie i wykonywanie w 3 bazach danych NoSQL MongoDB 6 Zapytania zwiększające złożoność
<ol>
	<li>Uruchom graficzny interfejs użytkownika MongoDB (patrz tabela materiałów).</li>
	<li>Uruchom serwer MongoDB 2.6 wykonując program mongod z okna systemu DOS (patrz Rysunek 3).</li>
	<li>Wykonaj krok 2.4, aby połączyć graficzny interfejs użytkownika bazy danych MongoDB z serwerem hosta lokalnego przy użyciu portu 27017.</li>
	<li>Wybierz i rozwiń bazę danych MongoDB po lewej stronie.</li>
	<li>Wybierz kolekcję.</li>
	<li>Kliknij menu "Kolekcja" na pasku narzędzi.</li>
	<li>Wykonaj pierwsze zapytanie bazy danych MongoDB.
	<ol>
		<li>Kliknij dwukrotnie przycisk "Kreator zapytań".</li>
		<li>Kliknij dwukrotnie "Pole zapytania" w Kreatorze zapytań po prawej stronie.</li>
		<li>Wpisz pole zapytania MongoDB w polu tekstowym pola panelu zapytań (patrz rysunek uzupełniający 4).</li>
		<li>Wpisz wartość zapytania MongoDB w polu tekstowym wartości panelu zapytań. 
		UWAGA: To zapytanie powinno wyglądać mniej więcej tak: {"ns3:EHRExtract.allCompositions.content.items.parts.parts.name.ns2:originalText. value": "Opis"}. Pole i wartość są ujęte w cudzysłowy i oddzielone średnikiem.</li>
		<li>Kliknij dwukrotnie pole Projekcja w Konstruktorze zapytań</li>
		<li>Wpisz pierwsze rzutowanie w polu tekstowym projekcji (patrz rysunek uzupełniający 5).</li>
		<li>Kliknij dwukrotnie pole projekcji, aby dodać nowe pole tekstowe projekcji.</li>
		<li>Wpisz drugą projekcję w polu tekstowym projekcji. 
		UWAGA: Projekcja wybiera część dokumentu pobraną przez zapytanie. Powinny one wyglądać mniej więcej tak: {"ns3:EHRExtract. allCompositions.content.items.parts.parts.value.value": 1} i {"ns3: EHRExtract.all Compositions.content.items.parts.parts.value.nullFlavor" : 1}</li>
		<li>Kliknij niebieski przycisk odtwarzania, aby wykonać zapytanie.</li>
		<li>Wizualizacja kodu zapytania na karcie Kod zapytania.</li>
		<li>Wyświetl szczegóły wyniku w zakładce Wyjaśnienie: liczba wyników, czas wykonania w milisekundach.</li>
		<li>Wyświetl, rozwiń i sprawdź wyniki na karcie Wynik.</li>
		<li>Jeśli wymagane jest dalsze przetwarzanie zapytania, napisz program Java ze sterownikiem Java MongoDB z zapytaniem i metodą do przetwarzania wyników.</li>
		<li>Powtórz wykonanie 5 razy i oblicz średni czas odpowiedzi.</li>
	</ol>
	</li>
	<li>Wykonaj krok 5.7 dla pozostałych zapytań od 2 do 6</li>.
	<li>Powtórz cały proces w 5 000, 10 000 i 20 000 wyodrębnionych bazach danych MongoDB.</li>
</ol>
6. Projektowanie i wykonywanie w 3 bazach danych NoSQL eXist 6 Zapytania o rosnącej złożoności
<ol>
	<li>Uruchom system zarządzania bazami danych eXist.</li>
	<li>Otwórz klienta Java Admin Client.</li>
	<li>Naciśnij przycisk "połącz z bazą danych".</li>
	<li>Wybierz bazę danych i kliknij na nią.</li>
	<li>Kliknij menu "Skonsultuj bazę danych za pomocą XPath"; pojawi się okno dialogowe konsultacji.</li>
	<li>Wykonaj pierwsze zapytanie XPath (patrz rysunek uzupełniający 6).
	<ol>
		<li>Wpisz lub wklej kod XPath pierwszego zapytania w górnej części okna dialogowego.</li>
		<li>Kliknij menu "Wykonaj" na pasku narzędzi okna dialogowego.</li>
		<li>Wyświetl wyniki XML za pomocą zakładki "XML" w dolnej części okna dialogowego.</li>
		<li>Wyświetl liczbę wyników oraz czas kompilacji i wykonania w dolnej części okna dialogowego.</li>
		<li>Powtórz wykonanie 5 razy i oblicz średni czas odpowiedzi.</li>
	</ol>
	</li>
	<li>Powtórz krok 6 dla zapytań od 2 do 6.</li>
	<li>Wykonaj cały proces trzy razy, dla 5 000, 10 000 i 20 000 wyodrębnionych baz danych eXist.</li>
</ol>
7. Zaprojektuj i wykonaj eksperyment współbieżności przy użyciu baz danych MySQL i MongoDB 5 000 ekstraktów
UWAGA: Baza danych eXist została usunięta z eksperymentu w tym momencie z powodu gorszych wyników w poprzednich eksperymentach.
<ol>
	<li>Wybierz zapytania z trzema odpowiedziami o najkrótszym czasie w poprzednich eksperymentach przy użyciu 5 000 wyodrębnionych baz danych (zwykle poniżej kilku sekund).</li>
	<li>W razie potrzeby zidentyfikuj i ręcznie utwórz odpowiednie indeksy atrybutów dla tych zapytań.</li>
	<li>Zaprogramuj dwie wielowątkowe aplikacje Java, jedną dla MySQL, a drugą dla MongoDB; każda aplikacja będzie miała trzy różne priorytety, po jednym dla każdego zapytania wybranego w kroku 1.</li>
	<li>Wykonaj i oblicz dystrybucję użycia procesora CPU (jednostki centralnej) dla każdego wątku (zapytania).</li>
	<li>Uruchom każdą aplikację wielowątkową, klikając przycisk wykonywania pięć razy w każdym 10-minutowym przedziale i oblicz najczęściej wykonywaną (o najwyższym priorytecie) średnią przepływność zapytania oraz średni czas odpowiedzi trzech zapytań.</li>
	<li>Wyświetlanie wykonywanych zapytań z priorytetami i czasem wykonywania.</li>
	<li>Obliczanie średniej przepływności i średniego czasu odpowiedzi dla każdego z trzech zapytań.</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>

Autorzy nie mają nic do ujawnienia. Zestawy danych wykorzystane w tych eksperymentach zostały dostarczone przez kilka hiszpańskich szpitali na podstawie licencji na te eksperymenty i w związku z tym nie są publicznie dostępne. Schemat XML RM ISC/EN 13606 został dostarczony przez University College London Centre for Health Informatics & Multiprofessional Education (CHIME).

Protokół ten pokazuje, że czysto relacyjne systemy ORM nie wydają się praktyczne w przypadku zapytań dla jednego pacjenta (Q1, Q3 i Q4), ponieważ czasy odpowiedzi są wolniejsze, prawdopodobnie ze względu na dużą liczbę tabel relacyjnych wykonujących wiele kosztownych operacji łączenia oraz ze względu na system przechowywania używany przez określony rodzaj bazy danych. Bazy danych NoSQL przechowują dane w sposób oparty na dokumentach, podczas gdy systemy relacyjne używają sposobu opartego na tabelach, który rozprzestrzenia każdy dokument w całej bazie danych. Systemy NoSQL wykazują nachylenie liniowe, przy czym MongoDB działa znacznie szybciej niż eXist DBMS. W współbieżności MongoDB zachowuje się również znacznie lepiej niż relacyjny MySQL ORM7.
Ten protokół przedstawia protokół rozwiązywania problemów dla wyników przedstawionych w7 dotyczących ORM MySQL DBMS. System MySQL został zaktualizowany do najnowszej wersji, a wyniki zostały nieznacznie zmodyfikowane. Ponadto krytycznym punktem w systemach NoSQL opartych na dokumentach, takich jak MongoDB, jest to, że mogą one zachować spójność podczas przechowywania informacji medycznych7 , ponieważ gdy ekstrakt EHR jest aktualizowany, nie jest nadpisywany, ale generowany i przechowywany w systemie jest zupełnie nowy wyciąg z nowymi danymi, a oryginalny wyciąg jest zachowywany. Jest to ścisły wymóg dotyczący informacji medycznych, ponieważ niektórzy lekarze mogli podejmować ważne decyzje medyczne na podstawie oryginalnych danych.
Ulepszony relacyjny system ARM drastycznie zmniejsza liczbę tabel relacyjnych i poprawia wydajność relacyjną. Jednakże, ponieważ modyfikuje schemat relacyjny, informacje medyczne zawarte w ekstraktach mogą być przeszukiwane, ale ekstrakty nie mogą być odzyskane w ich dokładnej oryginalnej formie.
W przypadku bardzo dużych baz danych w wtórnym użyciu (badaniach) nie jest jasne, który system baz danych jest bardziej odpowiedni, ponieważ zapytania dla wszystkich pacjentów (Q2 i Q5) zachowują się lepiej w systemach ORM niż w systemach NoSQL, ale systemy te działają lepiej niż uproszczone systemy relacyjne w 12. Uważamy, że Q6 jest szczególnym zapytaniem pomiędzy praktyką kliniczną a wtórnym użyciem, którego zachowanie nie może być zdeterminowane przez wyniki uzyskane w tych eksperymentach.
Jednak jednym z ograniczeń metody jest brak bezpośrednich eksperymentów porównujących ulepszony relacyjny system ARM z NoSQL MongoDB dotyczących zapytań do pojedynczego pacjenta w praktyce medycznej z dokładnie tymi samymi danymi, które zostały użyte w protokole. Utrzymaliśmy wyniki interpolacji Tabeli 3 i Tabeli 5 dotyczącej zapytań u jednego pacjenta do czasu przeprowadzenia eksperymentu z uwzględnieniem zoptymalizowanego ARM w protokole. Pozostawiamy te eksperymenty na przyszłe zastosowania. Jednym z kluczowych kroków w ramach protokołu jest wybór darmowej bazy danych, podobnych wersji oprogramowania z ostatnich lat, abyśmy mogli porównać dokładny stan wiedzy z tych trzech technologii.
Jest to jedna z pierwszych prób bezpośredniego porównania systemów relacyjnych i NoSQL przy użyciu rzeczywistych, realistycznych, ustandaryzowanych informacji medycznych. Jednak konkretny system, który ma być zastosowany, zależy w dużej mierze od rzeczywistego scenariusza i problemu, który ma zostać rozwiązany8.

NoSQL (nie tylko SQL) DBMS pojawił się ostatnio jako alternatywa dla tradycyjnego relacyjnego DBMS (RDMBS). RDBMS od dziesięcioleci dominują w sposobie przechowywania danych w systemach baz danych. Dobrze zbadana i zrozumiana algebra relacyjna i rachunek różniczkowy zagwarantowały wydajność i spójność RDBMS1. Systemy NoSQL nie staną się substytutami systemów relacyjnych, ale mogą zachowywać się korzystnie w niektórych scenariuszach i pod kilkoma warunkami.
Niektóre z tych szczególnych scenariuszy i warunków wystąpiłyby podczas projektowania trwałości bazy danych systemów elektronicznej dokumentacji medycznej (EHR) używanych do zarządzania i przechowywania informacji medycznych. Aby zapewnić interoperacyjność i zrównoważony rozwój w praktyce, do standaryzacji ekstraktów EHR zastosowano kilka międzynarodowych standardów, takich jak ISO/EN 13606, openEHR i HL72,3,4,5.
Kilka standardów, takich jak ISO/EN 13606 i openEHR, rozdzieliło informacje i wiedzę na dwa różne poziomy abstrakcji, reprezentowane przez Model Referencyjny (RM) i specjalne struktury danych zwane archetypami. Ta separacja jest często nazywana modelem podwójnym i pozwala systemom EHR na semantyczną interoperacyjność, a wiedza medyczna na ewolucję bez przeprogramowywania całego systemu EHR, a w konsekwencji na utrzymanie i trwałość w praktyce6. Jednak podwójny model zaimplementowany w ustandaryzowanych systemach EHR wymaga, aby organizacja informacji była zgodna z określoną strukturą, a to ma poważne konsekwencje w sposobie, w jaki projektowany jest poziom trwałości bazy danych systemu7.
Object Relational Mapping (ORM)8 to jedna z metodologii implementacji systemu EHR wykorzystującego paradygmat relacyjnej bazy danych. ORM wyczerpująco odwzorowuje strukturę ustandaryzowanych plików EHR extracts XML (eXtensible Markup Language) używanych przez system do relacyjnej bazy danych. ORM konstruuje wiele tabel relacyjnych w sposób wyczerpujący zgodnie ze strukturą ustandaryzowanych plików XML wyodrębnianych przez EHR. Te tabele relacyjne są powiązane za pomocą wielu kluczy obcych, a wynikowy system może nie być zbyt wydajny.
Zaproponowano kilka ulepszeń relacyjnych dla ORM. openEHR's Node+Path9 zmniejsza liczbę tabel relacyjnych poprzez serializację poddrzew całego pliku XML do BLOB-ów (dużych obiektów binarnych). Jednak to uproszczenie powoduje złożoną logikę pobierania, uszkadzając złożone zapytania. Archetype Relational Mapping (ARM)10 generuje model bazy danych oparty na archetypach, budując nowy schemat relacyjny oparty na mapowaniach między archetypami i tabelami relacyjnymi. W związku z tym niektóre informacje niemedyczne zawarte w wyciągu z elektronicznej dokumentacji medycznej zostają utracone.
Wiele baz danych NoSQL opartych na dokumentach przechowuje całe dokumenty jako całe BLOBy, przestrzegając oryginalnego formatu XML lub JSON (JavaScript Object Notation). Oznacza to, że nie są konstruowane żadne tabele relacyjne. Te bazy danych NoSQL nie mają schematu i nie obsługują ani sprzężeń, ani właściwości (ACID)11, tj. niepodzielność, spójność, izolację lub trwałość. W rezultacie mogą być bardzo nieefektywne, jeśli element dokumentu odwołuje się do elementów tego samego lub innych takich dokumentów wykorzystujących link pośredni. Dzieje się tak dlatego, że w celu zachowania spójności całość dokumentów referencyjnych musi być przetwarzana sekwencyjnie. Jednak nierelacyjna baza danych może być nadal odpowiednia, jeśli główne zadanie wykonywane przez DBMS jest zadaniem opartym na dokumentach. Dzieje się tak, ponieważ dane mogą pozostać w formie bardziej zbliżonej do ich prawdziwej reprezentacji przy użyciu bazy danych NoSQL opartej na dokumentach, chociaż jest to również spowodowane specjalnymi zasadami trwałości realizowanymi przez dokumenty medyczne EHR (patrz sekcja dyskusji).
Celem tych metod jest pokazanie kilku eksperymentów w celu porównania implementacji warstwy trwałości standardowego systemu EHR przy użyciu trzech różnych DBMS: jednego relacyjnego (MySQL) i dwóch NoSQL (MongoDB opartego na dokumentach i natywnego XML eXist). Ich złożoność obliczeniowa została obliczona i porównana przy użyciu trzech różnych baz danych o rosnącym rozmiarze i sześciu różnych zapytań zwiększających złożoność. Trzy serwery baz danych zostały zainstalowane i skonfigurowane lokalnie na tym samym komputerze, na którym zostały wykonane zapytania. Szczegółowe informacje techniczne można znaleźć w tabeli materiałów.
Eksperymenty z współbieżnością zostały również przeprowadzone w celu porównania wydajności relacyjnych baz danych MySQL i NoSQL MongoDB. Opisane ulepszenia ORM (Node+Path i ARM) zostały również porównane przy użyciu odpowiednich wyników z literatury10.
Systemy zarządzania bazami danych stale ewoluują w coraz szybszym tempie. Nikt nie myślałby o tym wykładniczym rozwoju, gdyby jedynym istniejącym paradygmatem był model relacyjny. Dla przykładu, zobacz na przykład12, gdzie zaproponowano model do implementacji ulepszonych relacyjnych baz danych w czasie odpowiedzi, zachowujących właściwości ACID.

<table><tbody><tr><td>MySQL 5.7.20</td><td></td><td></td><td>Eksperymenty MySQL</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 eksperymenty</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 eksperymentuje</td></tr><tr><td>z Windows 7, 2.66GHz, RAM 12GB&nbsp;</td><td></td><td></td><td></td></tr><tr><td>Graficzny interfejs użytkownika programu Studio 3T 5.5.1</td><td>3T Software Labs Gmbh</td><td></td><td>MongoDB</td></tr></tbody></table>

wykonywanie zapytań zwiększających złożoność w relacyjnych (mysql) i nosql (mongodb i exist) bazach danych ehr zgodnych z normą iso/en 13606

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

To badanie pokazuje protokół do oceny złożoności obliczeniowej systemów baz danych informacji medycznych (DBMS) relacyjnych i nierelacyjnych (NoSQL (nie tylko Structured Query Language)) standaryzowanych systemów baz danych informacji medycznych (DBMS) relacyjnych i nierelacyjnych (NoSQL (nie tylko Structured Query Language)). Wykorzystuje zestaw trzech baz danych o podwójnej wielkości, tj. baz danych przechowujących 5000, 10 000 i 20 000 realistycznych, ustandaryzowanych ekstraktów EHR, w trzech różnych systemach zarządzania bazami danych (DBMS): relacyjnym mapowaniu obiektowo-relacyjnym MySQL (ORM), opartym na dokumentach NoSQL MongoDB i natywnym rozszerzalnym języku znaczników (XML) NoSQL eXist.
Obliczono średni czas odpowiedzi na sześć zapytań zwiększających złożoność, a wyniki wykazały liniowe zachowanie w przypadkach NoSQL. W polu NoSQL MongoDB prezentuje znacznie bardziej płaskie nachylenie liniowe niż eXist.
Systemy NoSQL mogą być również bardziej odpowiednie do utrzymywania standardowych systemów informacji medycznej ze względu na specjalny charakter polityk aktualizacji informacji medycznych, które nie powinny wpływać na spójność i wydajność danych przechowywanych w bazach danych NoSQL.
Jednym z ograniczeń tego protokołu jest brak bezpośrednich wyników ulepszonych systemów relacyjnych, takich jak mapowanie relacyjne archetypu (ARM) z tymi samymi danymi. Jednak interpolacja wyników bazy danych o podwojonym rozmiarze do tych przedstawionych w literaturze i innych opublikowanych wyników sugeruje, że systemy NoSQL mogą być bardziej odpowiednie w wielu konkretnych scenariuszach i problemach do rozwiązania. Na przykład NoSQL może być odpowiedni do zadań opartych na dokumentach, takich jak wyciągi z elektronicznej dokumentacji medycznej stosowane w praktyce klinicznej lub edycja i wizualizacja, lub w sytuacjach, w których celem jest nie tylko zapytanie o informacje medyczne, ale także przywrócenie elektronicznej dokumentacji medycznej w dokładnie jej pierwotnej formie.

To badanie porównuje relacyjne i nierelacyjne (NoSQL) standardowe systemy informacji medycznej. Złożoność obliczeniowa czasów odpowiedzi na zapytania dotyczące takich systemów zarządzania bazami danych (DBMS) jest obliczana przy użyciu baz danych o podwójnym rozmiarze. Wyniki te pomagają w omówieniu adekwatności każdego podejścia do bazy danych do różnych scenariuszy i problemów.

Wykonywanie zapytań zwiększających złożoność w relacyjnych (MySQL) i NoSQL (MongoDB i EXist) bazach danych EHR zgodnych z normą ISO/EN 13606

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

Ogólnym celem tego eksperymentu jest porównanie złożoności obliczeniowej relacyjnych i nierelacyjnych, nie tylko ustrukturyzowanych języków zapytań lub systemów baz danych NoSQL, mierzonej ich czasem odpowiedzi na zapytania o rosnącej złożoności. Ta metoda może pomóc w udzieleniu odpowiedzi na kluczowe pytania w dziedzinie systemów zarządzania bazami danych, takie jak to, które zapytania są bardziej odpowiednie dla danego rodzaju systemów baz danych. Główną zaletą tej techniki jest to, że porównuje ona czasy odpowiedzi na zapytania dla podwójnej bazy danych każdego typu wraz ze złożonością obliczeniową, która ma zostać obliczona, a więc ta metoda może zapewnić wgląd w MySQL MongoDB i nadmiarowe systemy baz danych.Może być również stosowany do innych relacyjnych systemów opartych na dokumentach i natywnych systemach XML, takich jak SQL Server i base X. Po raz pierwszy słyszeliśmy, że są tam dla tej metody, gdy musimy wybrać trwały system dla systemów elektronicznej dokumentacji medycznej. Projektowanie i wykonywanie zapytań zwiększających złożoność z nieautomatycznie budowanymi indeksami w relacyjnej bazie danych MySQL. Połącz się z serwerem MySQL i wybierz nazwę bazy danych.Wybierz tabelę relacyjną w polu indeksu i otwórz zakładkę struktura. Wybierz kolumnę, w której zostanie zbudowany indeks i kliknij indeks. Pojawi się zdanie SQL budujące indeks, a następnie komunikat informujący, że zdanie zostało pomyślnie zbudowane.Aby wykonać pierwsze zapytanie, wybierz nazwę bazy danych i otwórz zakładkę SQL. Wprowadź kod SQL pierwszego zapytania i kliknij przycisk kontynuacji. Pojawi się pierwszy ekran listy wyników z komunikatem dotyczącym czasu wykonania zapytania.Aby zaprojektować i wykonać zapytania zwiększające złożoność i nierelacyjne, nie tylko lub NoSQL Mongo Database uruchamia graficzną interakcję użytkownika bazy danych Mongo i serwer bazy danych Mongo 2.6 wykonując program Mongo z okna systemu DOS. Podłącz graficzną interakcję użytkownika bazy danych Mongo z lokalnym serwerem hosta przez port 27017 i wybierz menu Połącz. Wprowadź nazwę połączenia i wprowadź lokalizację hosta lokalnego w polu tekstowym serwera bazy danych, a następnie kliknij przycisk Połącz.Powinno pojawić się drzewo z aktualnymi bazami danych. Rozwiń bazę danych Mongo. Wybierz interesującą Cię kolekcję i otwórz menu kolekcji.Aby wykonać pierwsze zapytanie do bazy danych Mongo, kliknij dwukrotnie przycisk kreatora zapytań i pola zapytania. Wprowadź pola zapytania bazy danych Mongo w polu tekstowym pól panelu zapytania, a wartość zapytania w polu tekstowym wartości panelu zapytania. Kliknij dwukrotnie pole projekcji kreatora zapytań i wprowadź pierwszą projekcję w polu tekstowym projekcji.Kliknij dwukrotnie pole projekcji, aby dodać nowe pole tekstowe projekcji i wprowadź drugą projekcję, a następnie kliknij, odtwórz, aby wykonać zapytanie i zwizualizować kod zapytania na karcie kodu zapytania. Szczegóły wyniku będą widoczne w zakładce wyjaśnienia i wyniki. Aby zaprojektować i wykonać zapytania o rosnącej złożoności w bazie danych NoSQL EXist, uruchom bazę danych EXist i otwórz klienta Java Admin.Kliknij, połącz się z bazą danych i wybierz bazę danych. Kliknij, skonsultuj się z bazą danych za pomocą ścieżki X. Pojawi się okno dialogowe konsultacji.Następnie wykonaj pierwsze zapytanie o ścieżkę X. W tej tabeli przedstawiono sześć różnych zapytań przeprowadzonych na realistycznych, standaryzowanych wyciągach z elektronicznej dokumentacji medycznej zawierających informacje o problemach pacjentów, w tym ich imiona i nazwiska, daty początkowe i końcowe oraz ciężkość. Średni czas odpowiedzi dla sześciu zapytań i trzech baz danych o podwojonym rozmiarze w każdym systemie zarządzania bazami danych pokazuje długie liniowe zachowanie złożoności obliczeniowej we wszystkich zapytaniach nierelacyjnych baz danych, które nie jest obserwowane w analizie bazy danych mapowania relacyjnego obiektów relacyjnych.Interpolacja wyników bazy danych Mongo z podobnymi zapytaniami i rozmiarami bazy danych archetypu wyników mapowania relacyjnego generuje równe wyniki w obu systemach baz danych dla pierwszego zapytania, ale z korzystniejszymi wynikami określonymi przy użyciu bazy danych Mongo dla trzeciego zapytania. W eksperymentach współbieżności baza danych Mongo jest lepsza niż baza danych MySQl zarówno pod względem przepływności, jak i czasu odpowiedzi, przy czym baza danych Mongo zachowuje się lepiej pod względem współbieżności niż izolacja i jest imponującą bazą danych w współbieżnym wykonywaniu. Cóż, pomyślałem, że ważne jest, aby pamiętać, aby utrzymywać wszystkie serwery lokalnie na tych samych maszynach, gdy klient wykonuje zapytania.Zgodnie z tą procedurą można zastosować inne metody, takie jak użycie innych rodzajów systemów baz danych, aby odpowiedzieć na dodatkowe pytania, takie jak: czy typ bazy danych może istnieć i wygrywać zarówno w pojedynczych, jak i wszystkich zapytaniach pacjentów? Po jej opracowaniu technika ta utorowała drogę badaczom zajmującym się złożonością algorytmiczną do badania porównawczej wydajności baz danych w różnych rodzajach systemów baz danych. Po obejrzeniu tego filmu powinieneś dobrze zrozumieć, jak wykonywać zapytania zwiększające złożoność w rosnących bazach danych systemów baz danych bardzo różnych rodzajów.

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

Research

JoVE Journal

Medicine

Medycyna

Prezentujemy protokół i związany z nim kod programistyczny, a także próbki metadanych, aby wspierać opartą na chmurze automatyczną identyfikację skojarzenia fraz i kategorii reprezentujących unikalne koncepcje w wybranej przez użytkownika dziedzinie wiedzy w literaturze biomedycznej. Powiązanie frazy-kategorii określone ilościowo przez ten protokół może ułatwić dogłębną analizę w wybranej dziedzinie wiedzy.

Eksploracja fraz w chmurze i analiza zdefiniowanych przez użytkownika powiązań frazo-kategoria w publikacjach biomedycznych

Wielu badaczy generuje dane "średniej wielkości", o niskiej prędkości i wielowymiarowe, które mogą być efektywniej zarządzane za pomocą baz danych niż arkuszy kalkulacyjnych. W tym miejscu przedstawiono koncepcyjny przegląd baz danych, w tym wizualizację danych wielowymiarowych, łączenie tabel w strukturach relacyjnych baz danych, mapowanie półautomatycznych potoków danych i używanie bazy danych do wyjaśniania znaczenia danych.

Bazy danych do efektywnego zarządzania średniej wielkości, wielowymiarowymi danymi o niskiej prędkości w inżynierii tkankowej

TBase łączy elektroniczną dokumentację medyczną z innowacyjną bazą danych badawczych dla biorców przeszczepów nerek. Baza TBase jest zbudowana na platformie bazy danych w pamięci, podłączona do różnych systemów szpitalnych i używana do regularnej opieki ambulatoryjnej. Automatycznie integruje wszystkie istotne dane kliniczne, w tym dane specyficzne dla przeszczepu, tworząc unikalną bazę danych badawczych.

TBase - Zintegrowana Elektroniczna Dokumentacja Medyczna i Baza Danych Badawczych dla Biorców Przeszczepu Nerki

gP2S to aplikacja internetowa do śledzenia eksperymentów krioelektromagnetycznych. Opisano jego główne funkcje, a także kroki wymagane do zainstalowania i skonfigurowania aplikacji. Po skonfigurowaniu aplikacja pozwala na dokładne rejestrowanie metadanych związanych z eksperymentami z barwieniem ujemnym i krioEM.

gP2S, system zarządzania informacjami dla eksperymentów krioelektromagnetycznych

Pooperacyjny niedrożność jelit (POI) jest powikłaniem operacji w obrębie jamy brzusznej, prowadzącym do zwiększonej zachorowalności i przedłużonego pobytu w szpitalu. Ze względu na brak strategii profilaktycznych lub terapeutycznych konieczne są intensywne badania. W związku z tym opracowaliśmy zstandaryzowany i wykonalny model mysi, aby zbadać patofizjologię POI oraz przestudiować potencjalne opcje terapeutyczne.

Funkcjonalna ocena motywności jelit i stanu zapalnego ściany jelita u gryzoni: analizy w zestandaryzowanym modelu manipulacji jelitowej

Lesion Explorer (LE) to półautomatyczny potok przetwarzania obrazów opracowany w celu uzyskania objętości regionalnej tkanki mózgowej i podkorowej hiperintensywności zmian ze strukturalnego rezonansu magnetycznego choroby Alzheimera i zdrowych osób starszych.  Aby zapewnić wysoki poziom dokładności i niezawodności, poniżej znajduje się prowadzony przez wideo, ustandaryzowany protokół dla ręcznych procedur LE.

Lesion Explorer: Ustandaryzowany protokół z przewodnikiem wideo do dokładnej i niezawodnej wolumetrii pochodzącej z MRI u osób z chorobą Alzheimera i zdrowymi osobami w podeszłym wieku

Opisujemy wewnętrzny, przenośny, ustandaryzowany kurs, który może być wykorzystany do oceny unikania przeszkód u osób z ultrasłabym wzrokiem. Kurs jest stosunkowo niedrogi, prosty w administrowaniu i wykazano, że jest niezawodny i powtarzalny.

Ustandaryzowany tor przeszkód do oceny funkcji wzrokowych w ultra słabym widzeniu i sztucznym widzeniu

Ten protokół opisuje technikę osteosyntezy wykorzystującą gwóźdź blokujący śródszpikowy do standaryzacji osteotomii kości udowej, która może być używana do analizy prawidłowego i wadliwego gojenia kości u myszy.

Śródszpikowy gwóźdź blokujący do standaryzowanego mocowania osteotomii kości udowej w celu analizy prawidłowego i wadliwego gojenia kości u myszy

Tutaj prezentujemy ustandaryzowany protokół pomiaru różnicy potencjału nosowego (NPD). Transbłonowy regulator przewodnictwa mukowiscydozy (CFTR) i funkcja nabłonkowego kanału sodowego (ENaC) są oceniane na podstawie zmiany napięcia w nabłonku nosa po superfuzji roztworów, które modyfikują aktywność kanału jonowego, zapewniając miarę wyniku.

Standaryzowany pomiar różnicy potencjału przeznabłonkowego błony nosowej (NPD)

Bazy danych literatury są powszechnie używane do oceny publikacji na określony temat, dyscyplinę, kraj lub region świata, praktyka znana jako analiza bibliometryczna. Obecny protokół szczegółowo opisuje, jak używać baz danych PubMed, Scopus i Web of Science do przeprowadzania analizy bibliometrycznej.

Porównywanie analiz bibliometrycznych przy użyciu baz danych PubMed, Scopus i Web of Science

Poznaj metodę porównywania złożoności obliczeniowej baz danych SQL i NoSQL poprzez analizę czasów odpowiedzi na zapytania o rosnącej złożoności. Badanie obejmuje MySQL, MongoDB i EXist.

Wykonywanie zapytań zwiększających złożoność w relacyjnych (MySQL) i NoSQL (MongoDB i EXist) bazach danych EHR zgodnych z normą ISO/EN 13606 (Wideo) | JoVE Journal

Wykonywanie zapytań zwiększających złożoność w relacyjnych (MySQL) i NoSQL (MongoDB i EXist) bazach danych EHR zgodnych z normą ISO/EN 13606

Przeglądaj więcej filmów