Name: İlişkisel (MySQL) ve NoSQL karmaşıklık artan sorguları yürütme (NoSQL ve mevcut) boyutu büyüyen ISO/EN 13606 standart EHR veritabanları (Video) | JoVE Journal
Uploaded: 2018-03-19T14:30:00.000+00:00
Duration: 7 min 26 s
Description: Keşfedin MySQL ve MongoDB veritabanlarında karmaşıklık artan sorguların yürütme sürelerini karşılaştırarak hesaplama karmaşıklığını analiz etme yöntemini. Bu teknik, veritabanı seçimi için performans içgörüleri sunar.

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

Yazarlar Dr Dipak Kalra, standart ISO/EN 13606 ve ekibi için ISO/EN 13606 W3C XML şema kullanmak izin onların tür University College London'dan tanımlanan EHRCom görev gücü'nün lideri teşekkür etmek istiyorum.
Bu eser Instituto de tarafından desteklenen Salud Carlos III [grant numaraları PI15/00321, PI15/00003, PI1500831, PI15CIII/00010 ve RD16CIII].

1. Üç Kişilik ölçekli standart EHR özleri veritabanı depolamak için ilişkisel bir MySQL DBMS inşa
<ol><li>İthalat W3C (World Wide Web Consortium) XML ISO/EN13606 RM ve ISO21090 veri türleri için bir 'Java IDE' (Integrated Development Environment) karşılık gelen şema. Not: ISO International Standards Organization için duruyor. EN Avrupa Norm için gösterir.</li>
	<li>JAXB (Java XML Binding) IDE içinde eklenti yürütmek; Bu öğeleri EHR özleri XML dosyaları yapısı için karşılık gelen Java sınıfları oluşturur.</li>
	<li>JPA etiketleri ile üretilen Java sınıflarını manuel olarak etiketleme. Bu Etiketler cardinalities ve diğer ilişkiler MySQL veritabanı ilişkisel tablolar arasında bakın.</li>
	<li>JPA (kalıcılığı API Java) kütüphanelerin IDE içine alabilir ve etiketli Java sınıfları dışında bir MySQL veritabanı oluşturur yöntemi uygulamak.</li>
	<li>Üç dizinler 5.000, 10.000 ve 20.000 gerçekçi EHR özleri ile XML dosyaları oluşturun.</li>
	<li>Bir XML ayıklamak 5000 özleri dizinin tüm özleri üzerinde MySQL DBMS yüklemek için JPA yöntemi uygulamak.</li>
	<li>1.6 iki kez, 10.000 özleri directory ile bir kez ve bir kez 20.000 özleri directory ile adımları yineleyin.</li>
</ol>2. bir NoSQL NoSQL DBMS üç kişilik ölçekli standart EHR özleri veritabanı depolamak için build
<ol><li>Sürecinin her 5.000, 10.000 ve 20.000 gerçekçi EHR özleri içeren XML dosyalarını json.org.XML gibi JSON dosyaları XML dosyaları dönüştürmek için bir standart program içeren üç dizinler. 5.000, 10.000 ve 20.000 JSON dosyalarla üç dizini üretilen.</li>
	<li>Başlatmak NoSQL GUI (grafik kullanıcı arayüzü, Tablo malzemelerigörmek).</li>
	<li>Mongod programın bir DOS (Disk işletim sistemi) sistemi penceresinden yürütme NoSQL 2.6 sunucu başlatın.</li>
	<li>NoSQL GUI kullanarak bağlantı noktası 27017 localhost sunucuya bağlanın.<ol>
<li>"Bağlan" menüsünü seçin.</li>
		<li>Bağlantı için bir ad yazın (örneğin ' ilk').</li>
		<li>Localhost:27017 DB sunucu metin kutusuna yazın.</li>
		<li>"Bağlan" düğmesine basın; bir ağaç geçerli veritabanları ile sol tarafta görüntülenir.</li>
	</ol>
</li>
	<li>Özler 5000 standart EHR içeren bir veritabanı oluşturmak.<ol>
<li>Soldaki ağaç üstündeki bağlantısının adını tıklatın.</li>
		<li>"Dosya" menüsünü seçin.</li>
		<li>"Veritabanı Ekle" seçin.</li>
		<li>Görüntülenen iletişim kutusunda veritabanının adını girin.</li>
		<li>Tamam'ı tıklatın.</li>
	</ol>
</li>
	<li>5000 standart EHR içeren bir koleksiyon özleri oluşturmak.<ol>
<li>Soldaki ağaçta veritabanının adını tıklatın.</li>
		<li>Menü "veritabanı".</li>
		<li>"AddCollection" seçin.</li>
		<li>Koleksiyon adı görüntülenen iletişim kutusunda girin.</li>
		<li>" Oluştur" u tıklayın.</li>
		<li>Koleksiyon adını tıklatın.</li>
		<li>"Alma" menüsünü seçin.</li>
		<li>Radyo düğmesini seçin ''JSON - mongo kabuk / / mongoexport ".</li>
		<li>"İleri" düğmesini tıklatın.</li>
		<li>"Kaynak dosyaları ekle" düğmesine basın.</li>
		<li>İletişim kutusunu kullanarak bilgisayarda gidin.</li>
		<li>Açık 5000 JSON içeren dizin dosyaları ayıklayın.</li>
		<li>Dizindeki tüm dosyaları seçin.</li>
		<li>"Aç" tuşuna basın. JSON dosya içe aktarma iletişim kutusunda görünmelidir.</li>
		<li>Basın "sonraki"; Yeni koleksiyon veritabanındaki bir önizlemesi sol tarafta görünür.</li>
		<li>"İleri" tuşuna basın.</li>
		<li>"Almayı başlat" tuşuna basın. Alma işleminin ilerleme aşağı içe aktarılan dosyaları ve geçen süreyi sayısını gösteren solda görünür.</li>
	</ol>
</li>
	<li>5 ve 6 özleri 10.000 standart EHR bir koleksiyon oluşturmak için adımları yineleyin.</li>
	<li>5 ve 6 özleri 20.000 standart EHR bir koleksiyon oluşturmak için adımları yineleyin.</li>
</ol>3. kurmak bir NoSQL mevcut stok üç çift boyutlu standart EHR ayıklar veritabanlarına DBMS
<ol><li>Varolan veritabanı başlatmak.</li>
	<li>Veritabanının simgesini kullanarak, Java Admin istemcisini açın.</li>
	<li>Yönetici şifresini girin.</li>
	<li>"Bağlan" düğmesine basın.</li>
	<li>5000 standart EHR içeren bir koleksiyon özleri oluşturmak.<ol>
<li>Araç çubuğunda, menü "Oluştur yeni bir koleksiyon" seçin.</li>
		<li>Görüntülenen iletişim kutusunda, yeni koleksiyonun adını yazın.</li>
		<li>Tıklatın "kabul"; Yeni koleksiyon-ecek gözükmek.</li>
		<li>Koleksiyon adını seçin.</li>
		<li>Araç çubuğunda, "veritabanı dosyaları saklamak" menüsünü seçin.</li>
		<li>İletişim kutusunu kullanarak bilgisayarda gidin.</li>
		<li>5000 standart XML özü dosyalarını içeren dizini seçin.</li>
		<li>"Dosya veya dizinler depolamak için seçmek" düğmesini tıklatın. Bir iletişim kutusu saklanan dosyaları ilerlemesini göstermek ve oluşturduğunuz veritabanını yüzdesi göründüğünü unutmayın.</li>
	</ol>
</li>
	<li>Özler 10.000 standart EHR içeren bir koleksiyon oluşturmak için 5 arasındaki adımları yineleyin.</li>
	<li>Özler 20.000 standart EHR içeren bir koleksiyon oluşturmak için 5 arasındaki adımları yineleyin.</li>
</ol>4. tasarım ve 3 ilişkisel MySQL veritabanı 6 karmaşıklık artan sorguları yürütmek
<ol><li>Altı karmaşıklık artan sorguları EHR özler tarafından kullanılan archetypes göre dizayn.</li>
	<li>Programı ilk sorgu MySQL veritabanı ile bir SQL komut dosyası. SQL MySQL veritabanı özleri standardizasyon (archetypes) nedeniyle özel yapısına uyum gerekir. Veritabanı özler tüm yapısını eşler. Sonuç olarak, SQL sorgusu oldukça karmaşık olduğunu.</li>
	<li>Olsa da çoğu dizinler otomatik olarak DBMS tarafından oluşturulan dizin üzerinde oluşturuldu ve sorgu yanıt süresini hızlandırmak sonra böyle dizinler oluşturmak istiyorum veritabanlarının özniteliklerini tanımlamak.</li>
	<li>Bir sorgu otomatik olarak sigara yapılı bir dizin ihtiyacı varsa, el ile oluşturun.<ol>
<li>(Ek şekil 1) MySQL sunucusuna bağlayın.</li>
		<li>Seçin ve veritabanı adı sol tıklatın.</li>
		<li>Seçin ve ilişkili tabloda yer aldığı dizine alınmış alanı tıklatın.</li>
		<li>"Yapı" sekmesini tıklayın.</li>
		<li>Seçin ve dizin nerede kurulacak sütun'u tıklatın.</li>
		<li>"Dizin"'ı tıklatın. Not Dizin oluşturma SQL cümlesi görünür ve cümle başarıyla inşa etti belirten bir ileti görüntülenir.</li>
	</ol>
</li>
	<li>İlk sorguyu yürütün.<ol>
<li>Seçin ve veritabanı adı sol tıklatın.</li>
		<li>"SQL" sekmesini tıklayın.</li>
		<li>İlk sorguyu SQL kodu yapıştırın veya yazın (bkz. ek Şekil 2).</li>
		<li>"Devam" tuşuna basın. Not sonuç listesindeki ilk ekran, sorgu yürütme süresi ile bir ileti ile birlikte görünür.</li>
		<li>Yürütme 5 kez tekrarlayın ve ortalama yanıt süresi hesaplamak.</li>
	</ol>
</li>
	<li>5 ile sorgular 2 ile 6 arasındaki adımları yineleyin.</li>
	<li>Tüm süreç üç kez, 5.000, 10.000 ve 20.000 özleri veritabanları ile yapmak.</li>
</ol>5. tasarım ve 3 NoSQL NoSQL veritabanlarında 6 karmaşıklık artan sorguları yürütmek
<ol><li>NoSQL GUI başlatın ( Tablo malzemelerigörmek).</li>
	<li>Mongod programın bir DOS sistem penceresinden yürütme NoSQL 2.6 sunucu başlatma (bkz. ek şekil 3).</li>
	<li>Takip adım 2.4 NoSQL GUI kullanarak bağlantı noktası 27017 localhost sunucusuna bağlanmak için.</li>
	<li>Seçin ve sol tarafında NoSQL veritabanını genişletin.</li>
	<li>Koleksiyonu seçin.</li>
	<li>Araç çubuğundaki "koleksiyon" menüsünde'ı tıklatın.</li>
	<li>İlk NoSQL sorguyu yürütün.<ol>
<li>"Sorgu Oluşturucusu'nu" düğmesini çift tıklayın.</li>
		<li>Sorgu alanı"sağ Sorgu Oluşturucusu'nu çift tıklatın.</li>
		<li>NoSQL sorgu alan sorgu paneli (bkz: ek şekil 4) alanı metin kutusuna yazın.</li>
		<li>NoSQL sorgu değeri sorgu paneli değer metin kutusuna yazın. Not: Bu sorgu {"ns3:EHRExtract.allCompositions.content.items.parts.parts.name.ns2:originalText. gibi bir şey olmalıdır değer":"Descripcion"}. Alan ve değer alıntı ve noktalı virgülle ayrılmış.</li>
		<li>Sorgu Oluşturucusu'nun projeksiyon alanı çift tıklatın</li>
		<li>İlk projeksiyon projeksiyon metin kutusuna yazmak (bkz ek Şekil 5).</li>
		<li>Yeni projeksiyon metin kutusu eklemek için projeksiyon alanı çift tıklatın.</li>
		<li>İkinci projeksiyon projeksiyon metin kutusuna yazın. Not: Bir projeksiyon sorgu tarafından alınan belgenin bir parçasını seçer. Bunlar {"ns3:EHRExtract. gibi bir şey olmalıdır allCompositions.content.items.parts.parts.value.value": 1} ve {" ns3: EHRExtract.all Compositions.content.items.parts.parts.value.nullFlavor ": 1}</li>
		<li>Sorguyu yürütmek için mavi yürüt düğmesini tıklatın.</li>
		<li>Sorgu kodu sekmesinde sorgu kodu görselleştirin.</li>
		<li>Sonuç açıklama sekmesini görüntülemek: sonuç sayısı, yürütme süresi (milisaniye cinsinden).</li>
		<li>Görüntülemek genişletin ve sonuç sekmesinde sonuçları inceleyin.</li>
		<li>Sorgunun işlenmesi gerekiyorsa, bir Java programı sonuçları işlemek sorgu ve yöntemi ile NoSQL Java sürücüsüyle yazmak.</li>
		<li>Yürütme 5 kez tekrarlayın ve ortalama yanıt süresi hesaplamak.</li>
	</ol>
</li>
	<li>5,7 kalan 2'den 6 sorguları için adım.</li>
	<li>Tüm süreç 5.000, 10.000 ve 20.000 NoSQL veritabanları ayıklar yineleyin.</li>
</ol>6. tasarım ve çalıştırmak 3'te NoSQL mevcut veritabanları 6 artan karmaşıklık sorgular
<ol><li>Mevcut DBMS başlatın.</li>
	<li>Java Admin istemcisini açın.</li>
	<li>"Veritabanına bağlan" düğmesine basın.</li>
	<li>Veritabanını seçin ve tıklayın.</li>
	<li>Tıkırtı üstünde yemek listesi "XPath kullanarak veritabanı başvurun"; konsültasyon iletişim kutusu görüntülenir.</li>
	<li>İlk XPath sorgusu yürütmek (bkz. ek şekil 6).<ol>
<li>İletişim kutusunun üst kısmındaki ilk sorgunun XPath kodu yapıştırın veya yazın.</li>
		<li>İletişim kutusunun araç çubuğunda "Execute" menüsünde'ı tıklatın.</li>
		<li>İletişim kutusunun alt kısmında "XML" sekmesini kullanarak XML sonuçlarını görüntüleyin.</li>
		<li>Sonuçları ve derleme ve iletişim kutusunun alt tarafındaki yürütme saat sayısını görüntüleyin.</li>
		<li>Yürütme 5 kez tekrarlayın ve ortalama yanıt süresi hesaplamak.</li>
	</ol>
</li>
	<li>Sorgu 2'den 6 için 6 arasındaki adımları yineleyin.</li>
	<li>5.000, 10.000 ve 20.000 özleri veritabanları için tüm süreç üç kez yapmak.</li>
</ol>7. tasarım ve MySQL ve NoSQL 5.000 ayıklar veritabanlarını kullanarak bir eşzamanlılık deneme çalıştırmak
Not: Mevcut veritabanı deneme bu dönemde önceki deneylerde daha kötü performansı nedeniyle kaldırıldı.
<ol><li>Üç kısa zaman yanıt sorgularla (genellikle birkaç saniye altında) 5.000 özleri veritabanı kullanarak önceki deneyler seçin.</li>
	<li>Tanımlamak ve el ile gerekirse bu sorguları için uygun öznitelik dizinler oluşturmak.</li>
	<li>Program iki Java çok iş parçacıklı uygulamalar, MySQL için bir ve diğer NoSQL için; her uygulama üç farklı öncelikli konu, 1. adımda seçtiğiniz her sorgu için bir tane olacak.</li>
	<li>Yürütmek ve CPU (merkezi işlem birimi) dağıtım kullanmak için her iş parçacığı (sorgu) hesaplamak.</li>
	<li>Beş kez her 10dk span sırasında yürütmek düğmesini tıklatarak çoklu iş parçacığı kullanan her uygulama için yürütmek ve en yürütülen (en yüksek öncelik) hesaplamak ortalama işlem hacmi ve ortalama süre yanıt üç sorgular sorgu.</li>
	<li>Sorguları yürütme, öncelikleri ve yürütme süresi ile görüntüleyin.</li>
	<li>Hesaplama ortalama işlem hacmi ve ortalama yanıt süresi her üç sorgu.</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>

Yazarlar ifşa gerek yok. Bu deneylerde kullanılan veri kümeleri bu deneyler için lisansı altında birkaç İspanyol hastaneler tarafından sağlanan ve sonuç olarak halka açık değildir. ISO/EN 13606 RM XML şeması University College London Merkezi tarafından Sağlık Bilişimi & Multiprofessional eğitim (çan) için sağlanan.

Bu iletişim kuralı yanıt süreleri yavaş, muhtemelen yüksek bir sayıda ilişkisel tablolar çok pahalı birleştirme işlemlerini gerçekleştirme ve nedeniyle nedeniyle olduğundan saf ilişkisel ORM sistemleri tek-hasta sorgularında (S1, S3 ve S4) pratik görünmüyor olduğunu gösterir veritabanı belirli tür tarafından kullanılan depolama sistemi. İlişkisel sistemleri her belgenin tüm veritabanını boyunca yayılır tablo temelli bir moda kullanırken NoSQL veritabanları belge tabanlı bir biçimde veri depolar. NoSQL sistemleri doğrusal bir yamaç, DBMS var daha önemli ölçüde daha hızlı gerçekleştirme NoSQL ile göster. Eşzamanlılık içinde NoSQL de ilişkisel MySQL ORM7daha iyi davranır.
Bu iletişim kuralı için sonuçları7 ORM MySQL DBMS ile ilgili olarak sunulan bir sorun gidermesi Protokolü sunar. MySQL sistemi en son sürümüne güncellendi ve sonuçları biraz değiştirilmiş. Buna ek olarak, belge tabanlı NoSQL sistemlerde kritik bir noktaya NoSQL EHR ekstresi güncelleştirildiğinde, değil yazılır çünkü tıbbi bilgiler7 depolamak, ama bir bütün yeni verilerle yeni ayıkladığınızda onlar tutarlılığı korumak gibi olduğunu oluşturulan ve sisteminde depolanan ve özgün özü korunur. Bazı tıp uygulayıcıları Tıbbi kararlar özgün verilere dayanarak yapılmış olabilir çünkü bu tıbbi bilgi, sıkı bir gereksinimdir.
Gelişmiş ilişkisel kol sistemi büyük ölçüde ilişkisel tablolar sayısı azalır ve ilişkisel performansını artırır. Ancak, ilişkisel şemayı değiştiren beri özler tarafından tutulan tıbbi bilgilerin sorgulanmasını ama özleri tam orijinal formlarında kurtarılamaz.
Çok büyük ikincil veritabanlarında kullanın (araştırma), all-hasta sorguları (Q2 ve Q5) ORM içinde NoSQL sistemlerinde uslu hangi veritabanı sistemi daha uygun olduğu için açık değil, ama bu sistemleri Basitleştirilmiş daha iyi performans için ilişkisel 12sistemlerinde. Klinik pratikte arasında ve ikincil özel sorgu kullanma olan davranış bu deneyler tarafından vermiştir sonuçlarına göre tespit edilemez Q6 göz önünde bulundurun.
Ancak, bir yöntem gelişmiş ilişkisel kol sistemiyle NoSQL NoSQL tek-hasta, tıbbi uygulama sorguları ile ilgili iletişim kuralında kullanılan tam olarak aynı verilerle karşılaştırarak doğrudan deneyler inavailability kısıtlamasıdır. Tablo 3 ve Tablo 5 tek-hasta sorguları ile ilgili protokol içinde en iyi duruma getirilmiş kol dahil olmak üzere deneme gerçekleştirildi kadar enterpolasyonla sonuçları saklanır. Bu deneyler gelecekteki uygulamalar için yola çıkıyoruz. Tam state-of--art üç teknolojileri karşılaştırmak iletişim kuralına bir kritik adım ücretsiz veritabanı, son yıl, benzer yazılım sürümleri seçimdir.
Bu doğrudan ilişkisel karşılaştırmak için ilk deneme ve gerçek, gerçekçi, standart tıbbi bilgileri kullanarak NoSQL sistemleri biridir. Ancak, kullanılacak belirli bir sistem çok gerçek senaryo ve sorun çözüldü8olarak bağlıdır.

NoSQL (sadece SQL) DBMS son zamanlarda alternatif için geleneksel ilişkisel DBMS (RDMBS) olarak ortaya çıktı. RDBMS veri veritabanı sistemlerinde yıllardır saklanan edildi şekilde hakim olmuş. İyi okudu ve anlaşılır ilişkisel cebir ve diferansiyel ve İntegral Hesap verimlilik ve RDBMS1tutarlılığını garanti. NoSQL sistemleri ilişkisel sistemleri karşılıklarını olmak değil, ama onlar avantajlı belirli senaryolarda ve çeşitli koşullar altında davranır.
Bu belirli senaryolar ve koşullar bazı tıbbi bilgi depolamak ve yönetmek için kullanılan elektronik sağlık kaydı (EHR) sistemleri veritabanı sebat tasarlarken oluşacak. Birlikte çalışabilir ve pratikte ISO/EN 13606, openEHR ve HL72,3,4gibi çeşitli uluslararası standartları sürdürülebilir olması için,5 kullanılan EHR özleri standartlaştırmak.
ISO/EN 13606 ve openEHR gibi birkaç standart bilgi ve bilgi referans modeli (RM) tarafından temsil soyutlama ve özel veri yapıları archetypesolarak adlandırılan iki farklı düzeylerde ayrılmış. Bu ayrılık kez çift modeli olarak adlandırılan ve EHR sistemleri tüm EHR sistem yeniden programlama olmadan ve sonuç olarak, için gelişmeye anlam olarak birlikte çalışabilir ve tıbbi bilgi verir Bakımı ve sürdürülebilir pratik6 . Ancak, standart EHR sistemlerinde uygulanan çift model belirli bir yapı kuruluşu bilgi izler ve bu sistem veritabanı kalıcı düzeyde tasarlanmış7şekilde derin sonuçları vardır gerektirir.
Nesne ilişkisel eşleme (ORM)8 ilişkisel veritabanı paradigması kullanarak bir EHR sistemi uygulamak için bir metodoloji'dir. ORM etraflıca bir ilişkisel veritabanı için sistem tarafından kullanılan standart EHR özleri XML (eXtensible Markup Language) dosyalarının yapısını eşler. ORM etraflıca standart EHR özleri XML dosyalarının yapısını takip birçok ilişkisel tablolar oluşturur. Bu ilişkisel tablolar birçok yabancı anahtarları ile ilişkilidir ve elde edilen sistemi çok etkili olmayabilir.
ORM için çeşitli ilişkisel iyileştirmeler önerilmiştir. openEHR'ın düğüm + yolu9 tarafından bütün ayıklayın XML dosyası biçimlendiricisi alt ağaçlar BLOB (ikili büyük nesne) içine ilişkisel tablolar sayısını azaltır. Ancak, bu basitleştirme karmaşık alma mantığı, karmaşık sorgular zarar neden olur. Güzel örneği ilişkisel eşleme (kol)10 archetypes, archetypes ve ilişkisel tablolar arasındaki eşlemeleri dayalı yeni bir ilişkisel şema oluşturma tarafından yönlendirilen bir veritabanı modeli oluşturur. Sonuç olarak, bazı tıbbi olmayan bilgileri EHR ekstresinin şey bitti.
Birçok belge tabanlı NoSQL veritabanı tüm belgeleri bir orijinal XML ya da JSON (JavaScript Object Notation) saygı tüm BLOB'lar depolamak biçimi. Böylelikle hiçbir ilişkisel tablolar oluşturulur. Bu NoSQL veritabanları hiçbir şema var ve birleşimler veya (asit) özellikleri11, Yani, atom oranı, tutarlılık, yalıtım ya da dayanıklılık desteklemez. Sonuç olarak, onlar aynı unsurları bir belge öğesi başvuruda bulunuyorsa veya bir yönlendirme bağlantısı kullanan diğer tür belgeleri çok verimsiz olabilir. Tutarlılık sağlamak için başvurulan belgelerin tamamını olduğundan, ardışık olarak işlenmek üzere bu olur. Ancak, ilişkisel olmayan bir veritabanı DBMS tarafından gerçekleştirilen ana görevi bir belge tabanlı görev ise hala uygun olabilir. Bunun nedeni veri bu da EHR tıbbi belgeleri (tartışma bölümüne bakın) tarafından başarılı Özel kalıcılık politikaları nedeniyle olmasına rağmen daha yakından bir belge tabanlı NoSQL veritabanı kullanarak anlayışına doğru yaklaşıldığıdır bir formda kalabilir.
Bu yöntemlerin amacı sebat katman üç farklı DBMS'ler kullanarak standart bir EHR sisteminin uygulanması karşılaştırmak için çeşitli deneyler vitrin etmektir: bir ilişkisel (MySQL) ve iki NoSQL (NoSQL belge tabanlı ve yerel XML var). Onların hesaplama karmaşıklık oldu hesaplanan ve üç farklı artan boyutu veritabanı ve altı farklı karmaşıklık artan sorgularını kullanarak karşılaştırıldığında. Üç veritabanı sunucularının yüklendiği ve nerede sorgular yürütülen aynı bilgisayara yerel olarak yapılandırılmış. Teknik ayrıntılar için Malzemeler tablo görmek.
Eşzamanlılık deneyler de ilişkisel MySQL ve NoSQL NoSQL DBMS'ler performansını karşılaştırmak üzere yapılmıştır. Açıklanan ORM iyileştirmeler (düğüm + yolu ve kol) da edebiyat10ilgili uygun sonuçları kullanılarak karşılaştırılmıştır.
Veritabanı yönetim sistemleri sürekli hızlanan bir hızla gelişmektedir. Sadece mevcut paradigma ilişkisel model yaşındayken hiç kimse bu üstel gelişme hakkında düşünürdüm. Bir örnek almak için örneğin nerede bir model tepki süresi gelişmiş ilişkisel veritabanları ACID özelliklerini koruyarak uygulamak için önerilmiş12, bakın.

<table><tbody><tr><td>MySQL 5.7.20</td><td></td><td></td><td>MySQL deneyleri</td></tr><tr><td>Red Hat Enterprise Linux Server sürüm 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 deneyleri</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 deneyleri</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 Yazılım Laboratuvarları Gmbh</td><td></td><td>MongoDB GUI</td></tr></tbody></table>

İlişkisel (mysql) ve nosql karmaşıklık artan sorguları yürütme (nosql ve mevcut) boyutu büyüyen iso/en 13606 standart ehr veritabanları

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

Bu araştırma, sorgulama Hesaplamalı karmaşıklığını ilişkisel değerlendirmek için bir protokol gösterir ve ilişkisel olmayan (NoSQL (sadece yapılandırılmış sorgu dili)) elektronik sağlık kaydı (EHR) tıbbi bilgi veritabanı sistemleri (DBMS) standart. Üç iki katına ölçekli veritabanı, veritabanları, 5000 depolama 10.000 ve 20.000 gerçekçi standart EHR özleri, üç farklı veritabanı yönetim sistemleri (DBMS) Yani bir dizi kullanır: ilişkisel MySQL nesne-ilişkisel eşlemeyi (ORM), NoSQL NoSQL belge tabanlı ve yerel Genişletilebilir Biçimlendirme Dili (XML) NoSQL adlı biri yok.
Ortalama yanıt süreleri altı karmaşıklık artan sorguları için hesaplanan ve sonuçlar NoSQL durumlarda doğrusal bir davranış gösterdi. NoSQL alanında NoSQL var daha bir çok düz doğrusal eğim sunar.
NoSQL sistemleri de özel olması nedeniyle standart tıbbi bilgi sistemleri tutarlılığı ve verimliliği NoSQL veritabanlarında depolanan verilerin etkilememelidir tıbbi bilgi güncelleştirme politikalarının korumak daha uygun olabilir.
Bu iletişim kuralı bir sınırlama güzel örneği ilişkisel eşleme (kol) ile aynı verileri gibi gelişmiş ilişkisel sistemlerinin doğrudan sonuçları olmaması. Ancak, katlama boyutu veritabanı sonuçları bu ilişkilendirme literatürde sundu ve yayımlanmış diğer sonuçları göstermektedir NoSQL sistemleri birçok belirli senaryolar ve çözülmesi gereken sorunları daha uygun olabilir. Örneğin, NoSQL klinik pratikte, ya da baskı ve görselleştirme veya amaç değil sadece olduğu durumlar kullanılan EHR özleri için tıbbi bilgileri sorgulama, aynı zamanda tam olarak orijinal biçiminde EHR geri yüklemek gibi görevleri belge tabanlı için uygun olabilir.

Hastaların, onların adları, ilk ve son tarihleri ve önem derecesi gibi sorunlar hakkında bilgi içeren gerçekçi standart EHR özü üzerinde gerçekleştirilen altı farklı sorgular Tablo 1' de gösterilmiştir.
Ortalama yanıt süreleri altı sorguların her DBMS üç katlama-boyut veritabanında Tablo 2-4' te gösterilmiştir. Rakamlar 1-6 göster aynı sonuçları grafik olarak (dikey eksen boyunca bu rakamlar çok farklı ölçekler kullanır dikkat edin).
Hesaplama karmaşıklık güçlü doğrusal davranışını kullanılan 3 veri kümeleri nispeten küçük boyutu nedeniyle uygun dikkatli rağmen NoSQL veritabanları, tüm sorguları belirgindir. Ancak, ilişkisel ORM veritabanı belirsiz bir doğrusal davranışı gösterir. NoSQL veritabanı bir düz kadar yamaç var veritabanına daha vardır.
Literatürde Yayınlandı giriş ele gelişmiş ilişkisel sistemleri tarafından sonuçları Tablo 5' te bulunabilir. Benzer sorguları ve veritabanı boyutu Tablo 5 kol sonuçlarının NoSQL sonuçlar Tablo 3 enterpolasyonla her iki veritabanı sistemleri Q1 eşittir ama NoSQL Q3 içinde yanadır.
Eşzamanlılık deneylerin sonuçlarını Tablo 5 ve tablo6' da bulunabilir. NoSQL MySQL her iki işlem hacmi ve yanıt zaman içinde daha iyi. Aslında, NoSQL daha iyi yalıtım eşzamanlılık davranır ve eşzamanlı yürütme etkileyici bir veritabanında gibi duruyor.
<img alt="Figure 1" class="xfigimg" src="/files/ftp_upload/57439/57439fig1.jpg"> Resim 1 : ORM MySQL, NoSQL, algoritmik karmaşıklık ve sorguları için Q1 ve Q4 DBMS var. Bu rakam7 Creative Commons lisansı (http://creativecommons.org/ licenses/by/4.0/) kullanarak değiştirildi ve yanıt süreleri saniye 5.000, 10.000 ve 20.000 ölçekli EHR her DBMS ve sorgu Q1 ve Q4 için veritabanları ayıklar gösterir. <a href="//cloudflare.jove.com/files/ftp_upload/57439/57439fig1large.jpg" target="_blank">Bu rakam daha büyük bir versiyonunu görüntülemek için buraya tıklayınız.</a>
<img alt="Figure 2" class="xfigimg" src="/files/ftp_upload/57439/57439fig2.jpg"> Resim 2 : ORM MySQL DBMS sorgu Q2 için algoritmik karmaşıklık. Bu şekilde yanıt süreleri saniye 5.000, 10.000 ve 20.000 ölçekli EHR ORM MySQL veritabanı sorgu Q2 için ayıklar gösterilir. <a href="//cloudflare.jove.com/files/ftp_upload/57439/57439fig2large.jpg" target="_blank">Bu rakam daha büyük bir versiyonunu görüntülemek için buraya tıklayınız.</a>
<img alt="Figure 3" class="xfigimg" src="/files/ftp_upload/57439/57439fig3.jpg"> Şekil 3 : NoSQL algoritmik karmaşıklık ve sorgu Q2 ve Q5 DBMS var. Bu rakam7 Creative Commons lisansı kullanarak değiştirildi (http://creativecommons.org/licenses/ tarafından / 4.0) ve gösterir yanıt süreleri saniye 5.000, 10.000 ve 20.000 ölçekli EHR her DBMS ve sorgu Q2 ve S5 için veritabanları ayıklar. <a href="//cloudflare.jove.com/files/ftp_upload/57439/57439fig3large.jpg" target="_blank">Bu rakam daha büyük bir versiyonunu görüntülemek için buraya tıklayınız.</a>
<img alt="Figure 4" class="xfigimg" src="/files/ftp_upload/57439/57439fig4.jpg"> Şekil 4 : ORM MySQL DBMS algoritmik karmaşıklık sorgu Q3 ve S5 için. Yanıt süreleri saniye 5.000, 10.000 ve 20.000 ölçekli EHR her DBMS ve sorgu Q3 ve S5 için veritabanları ayıklar gösterir. <a href="//cloudflare.jove.com/files/ftp_upload/57439/57439fig4large.jpg" target="_blank">Bu rakam daha büyük bir versiyonunu görüntülemek için buraya tıklayınız.</a>
<img alt="Figure 5" class="xfigimg" src="/files/ftp_upload/57439/57439fig5.jpg"> Şekil 5: var ve NoSQL DBMS için sorgu Q3 algoritmik karmaşıklık. Bu rakam7 Creative Commons lisansı (http://creativecommons.org/licenses/ tarafından/4.0 /) kullanarak değiştirildi ve yanıt süreleri saniye 5.000, 10.000 ve 20.000 ölçekli EHR her DBMS ve sorgu Q3 için veritabanları ayıklar gösterir. <a href="//cloudflare.jove.com/files/ftp_upload/57439/57439fig5large.jpg" target="_blank">Bu rakam daha büyük bir versiyonunu görüntülemek için buraya tıklayınız.</a>
<img alt="Figure 6" class="xfigimg" src="/files/ftp_upload/57439/57439fig6.jpg"> Şekil 6 : ORM MySQL, algoritmik karmaşıklık var ve NoSQL DBMS için sorgu S6. Bu rakam7 Creative Commons lisansı (http://creativecommons.org/licenses/ tarafından/4.0 /) kullanarak değiştirildi ve yanıt süreleri saniye 5.000, 10.000 ve 20.000 ölçekli EHR her DBMS ve sorgu S6 için veritabanları ayıklar gösterir. <a href="//cloudflare.jove.com/files/ftp_upload/57439/57439fig6large.jpg" target="_blank">Bu rakam daha büyük bir versiyonunu görüntülemek için buraya tıklayınız.</a>
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td></td>
			<td>Sorgu</td>
		</tr>
<tr>
<td>Q1</td>
			<td>Tek bir hastanın tüm sorunları bulma</td>
		</tr>
<tr>
<td>Q2</td>
			<td>Tüm hastaların tüm sorunları bulma</td>
		</tr>
<tr>
<td>Q3</td>
			<td>Başlangıç tarihi, çözünürlük Tarih ve önem bulmak</td>
		</tr>
<tr>
<td></td>
			<td>tek bir hastanın tek bir sorunu</td>
		</tr>
<tr>
<td>Q4</td>
			<td>Başlangıç tarihi, çözünürlük Tarih ve önem bulmak</td>
		</tr>
<tr>
<td></td>
			<td>tek bir hasta bütün sorunları problemini</td>
		</tr>
<tr>
<td>Q5</td>
			<td>Başlangıç tarihi, çözünürlük Tarih ve önem bulmak</td>
		</tr>
<tr>
<td></td>
			<td>tüm hastaların tüm sorunları sorunu</td>
		</tr>
<tr>
<td>S6</td>
			<td>Sorun 'farenjit' olan tüm hastalarda bulmak</td>
		</tr>
<tr>
<td></td>
			<td>ilk tarihi &gt; ' 16/10/2007 =', çözümleme tarihi</td>
		</tr>
<tr>
<td></td>
			<td>&lt; = ' 06/05/2008 ' ve 'yüksek'</td>
		</tr>
</tbody></table>Tablo 1: altı sorgular ilişkisel üzerinde gerçekleştirilen ve NoSQL veritabanlarını içeren standart EHR ayıklar hakkında hastaların sorunları. Bu tablo7 Creative Commons lisansı (http://creativecommons.org/ licenses/by/4.0/) kullanarak değiştirildi ve doğal olarak ifade edilen her DBMS için üç boyutu büyüyen veritabanı üzerinde gerçekleştirilen altı karmaşıklık büyüyen sorguları gösterir dili.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td>ORM/MySQL</td>
			<td>5000 Dokümanlar</td>
			<td>10.000 Dokümanlar</td>
			<td>20.000 Dokümanlar</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>S6 (s)</td>
			<td>1.4382</td>
			<td>2.4844</td>
			<td>183.4979</td>
		</tr>
<tr>
<td>Veritabanı boyutu</td>
			<td>4.6 GB</td>
			<td>9.4 GB</td>
			<td>19,4 GB</td>
		</tr>
<tr>
<td>Toplam özler</td>
			<td>5000</td>
			<td>10.000</td>
			<td>20.000</td>
		</tr>
</tbody></table>Tablo 2: ortalama iki katına boyutlu veritabanları ORM MySQL ilişkisel DBMS altı sorgulamaları saniye içinde yanıt kez. Bu tablo ORM MySQL ilişkisel DBMS ve üç veritabanı bellek boyutunu kullanarak üç iki katına boyutlu veritabanları için her sorgu için 6 yanıt sürelerini gösterir.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td>NoSQL</td>
			<td>5000 Dokümanlar</td>
			<td>10.000 Dokümanlar</td>
			<td>20.000 Dokümanlar</td>
			<td>yamaç (*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>S6 (s)</td>
			<td>9.5153</td>
			<td>18.5566</td>
			<td>36.7805</td>
			<td>1,817.68</td>
		</tr>
<tr>
<td>Veritabanı boyutu</td>
			<td>1,95 GB</td>
			<td>3,95 GB</td>
			<td>7.95GB</td>
			<td></td>
		</tr>
<tr>
<td>Toplam özler</td>
			<td>5000</td>
			<td>10.000</td>
			<td>20.000</td>
			<td></td>
		</tr>
</tbody></table>Tablo 3: ortalama iki katına boyutlu veritabanları NoSQL NoSQL DBMS altı sorgulamaları saniye içinde yanıt kez. Bu tablo7 Creative Commons lisansı (http://creativecommons.org/ licenses/by/4.0/) kullanarak değiştirildi ve her sorgu altı yanıt süreleri NoSQL NoSQL DBMS ve bellek boyutu kullanarak üç iki katına boyutlu veritabanları için gösterir Üç veritabanları. Her sorgu doğrusal eğimi de gösterilir.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td>biri yok</td>
			<td>5000 Dokümanlar</td>
			<td>10.000 Dokümanlar</td>
			<td>20.000 Dokümanlar</td>
			<td>yamaç (*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>S6 (s)</td>
			<td>68.3798</td>
			<td>138.9987</td>
			<td>475.2663</td>
			<td>27,125.82</td>
		</tr>
<tr>
<td>Veritabanı boyutu</td>
			<td>1,25 GB</td>
			<td>2.54GB</td>
			<td>5.12GB</td>
			<td></td>
		</tr>
<tr>
<td>Toplam özler</td>
			<td>5000</td>
			<td>10.000</td>
			<td>20.000</td>
			<td></td>
		</tr>
</tbody></table>Tablo 4: ortalama iki katına boyutlu veritabanları EXIST NoSQL DBMS altı sorgulamaları saniye içinde yanıt kez. Bu tablo7 Creative Commons lisansı (http://creativecommons.org/ licenses/by/4.0/) kullanarak değiştirildi ve DBMS ve bellek boyutunu her sorgu altı yanıt süreleri NoSQL kullanarak üç iki katına boyutlu veritabanları için mevcut gösterir Üç veritabanı. Her sorgu doğrusal eğimi de gösterilir.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td></td>
			<td>KOL kağıt</td>
			<td>KOL (s)</td>
			<td>Düğüm + yolu (s)</td>
		</tr>
<tr>
<td>Q1</td>
			<td>Sorgu 2.1</td>
			<td>0.191</td>
			<td>24.866</td>
		</tr>
<tr>
<td>Q3</td>
			<td>Sorgu 3.1</td>
			<td>0,27</td>
			<td>294.774</td>
		</tr>
<tr>
<td></td>
			<td>Veritabanı boyutu</td>
			<td>2.90GB</td>
			<td>43.87GB</td>
		</tr>
<tr>
<td></td>
			<td>Toplam özler</td>
			<td>29,743</td>
			<td>29,743</td>
		</tr>
</tbody></table>Tablo 5: ortalama yanıt süreleri saniye sorgu Q1 ve Q3 sunulan gelişmiş ilişkisel sistemlerinin benzer 10 . Bu tablo7 Creative Commons lisansı (http://creativecommons.org/ licenses/by/4.0/) kullanarak değiştirildi ve iki çoğu benzer sorgu Q1 ve iki gelişmiş ilişkisel veritabanı sistemleri için karşılık gelen10 sundu Q3 gösterir ve onların yanıt süreleri. İki veritabanı boyutları da gösterilmiştir.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td>ORM/MySQL</td>
			<td>Üretilen iş</td>
			<td>Tepki süresi</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>Tablo 6: ortalama işlem hacmi ve yanıt süresi saniye sorgu Q1, S3 ve S4 ORM MySQL ilişkisel eşzamanlı yürütme DBMS'de. Bu tablo7 Creative Commons lisansı (http://creativecommons.org/ licenses/by/4.0/) kullanarak değişiklik yapılmış ve en yüksek ortalama akış verimi, üç tek-hasta sorgu ve onların ortalama yanıt süreleri eşzamanlı gösterir ORM MySQL ilişkisel sistemini kullanarak yürütme deney.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td>NoSQL</td>
			<td>Üretilen iş</td>
			<td>Tepki süresi</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>Tablo 7: ortalama işlem hacmi ve yanıt süresi saniye sorgu Q1, S3 ve S4 NoSQL NoSQL DBMS eşzamanlı yürütme. Bu tablo7 Creative Commons lisansı (http://creativecommons.org/ licenses/by/4.0/) kullanarak değişiklik yapılmış ve en yüksek ortalama akış verimi, üç tek-hasta sorgu ve onların ortalama yanıt süreleri eşzamanlı gösterir NoSQL NoSQL sistemini kullanarak yürütme deney.
Ek şekil 1: MySQL sunucusuna bağlanmak için yazılım ekran ekran gösterir. <a href="//cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_1.png" target="_blank">Bu rakam indirmek için buraya tıklayınız.</a>
Ek Şekil 2: ekran SQL arabirimi gösterir MySQL sunucusuna nerede ilk SQL sorgusu yazıyor. <a href="//cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_2.png" target="_blank">Bu rakam indirmek için buraya tıklayınız.</a>
Ek şekil 3: NoSQL 2.6 localhost sunucu sunucu mongod yürüterek bir DOS sistem penceresini kullanarak başlatılır. <a href="//cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_3.png" target="_blank">Bu rakam indirmek için buraya tıklayınız.</a>
Ek şekil 4: ekran 5.7.1 5.7.4 aracılığıyla adımda gösterildiği gibi Sorgu Oluşturucusu'nu metin kutuları içinde yazılı sorgu gösterir. Ekran adımı 5.7.3 göstermektedir. <a href="//cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_4.png" target="_blank">Bu rakam indirmek için buraya tıklayınız.</a>
Ek Şekil 5: ekran gösterir adım 5.7.6. <a href="//cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_5.png" target="_blank">Bu rakam indirmek için buraya tıklayınız.</a>
Ek şekil 6: ekran görüntüsü iletişim theupper kısmında XPath sorgusu yazma gösterilmiştir. <a href="//cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_6.png" target="_blank">Bu rakam indirmek için buraya tıklayınız.</a>

Bu çalışmada ilişkisel karşılaştırır ve ilişkisel olmayan (NoSQL) tıbbi bilgi sistemleri standart. Böyle veritabanı yönetimi sistemleri (DBMS) sorgulama yanıt süreleri hesaplama karmaşıklığı kullanarak iki katına boyutlu veritabanları hesaplanır. Bu sonuçlar her veritabanı yaklaşım sorunları ve farklı senaryolar uygunluğunu tartışma yardım.

İlişkisel (MySQL) ve NoSQL karmaşıklık artan sorguları yürütme (NoSQL ve mevcut) boyutu büyüyen ISO/EN 13606 standart EHR veritabanları

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

Bu deneyin genel amacı, yalnızca yapılandırılmış sorgu dili veya NoSQL veritabanı sistemlerinin değil, ilişkisel ve ilişkisel olmayan sistemlerin karmaşıklık büyüyen sorgulara yanıt süreleriyle ölçülen hesaplama karmaşıklığını karşılaştırmaktır. Bu yöntem, hangi tür veritabanı sistemleri için hangi tür sorguların daha uygun olduğu gibi veritabanı yönetim sistemleri alanındaki temel soruların yanıtlanmasına yardımcı olabilir. Bu tekniğin temel avantajı, hesaplanacak hesaplama karmaşıklığı ile birlikte her türden çift veritabanı için sorgulara yanıt sürelerini karşılaştırmasıdır ve bu nedenle bu yöntem MySQL MongoDB ve fazla veritabanı sistemleri hakkında bilgi sağlayabilir.Ayrıca, SQL sunucusu ve temel X gibi diğer ilişkisel belge tabanlı ve yerel XML sistemlerine de uygulanabilir.Elektronik sağlık kayıt sistemleri için kalıcı bir sistem seçmemiz gerektiğinde bu yöntem için ilk kez orada duyduk. İlişkisel bir MySQL veritabanında otomatik olarak oluşturulmayan indekslerle karmaşıklığı artıran sorgular tasarlamak ve yürütmek. MySQL sunucusuna bağlanın ve veritabanı adını seçin.Dizin alanı içinde ilişkisel tabloyu seçin ve yapı sekmesini açın. Dizinin oluşturulacağı sütunu seçin ve dizine tıklayın. Dizini oluşturan SQL cümlesi görünecek ve ardından cümlenin başarıyla oluşturulduğunu belirten bir mesaj gelecektir.İlk sorguyu yürütmek için veritabanı adını seçin ve SQL sekmesini açın. İlk sorgunun SQL kodunu girin ve tıklayın, devam edin. Sonuç listesinin ilk ekranı, sorgunun yürütme süresi mesajıyla birlikte görünecektir.Karmaşıklığı artıran sorguları ve ilişkisel olmayan bir Mongo Veritabanını tasarlamak ve yürütmek için, yalnızca veya NoSQL Mongo Veritabanı, Mongo veritabanı grafik kullanıcı arafazını ve Mongo programını bir DOS sistem penceresinden yürüten Mongo veritabanı 2.6 sunucusunu başlatın. Mongo veritabanı grafik kullanıcı arafazını 27017 numaralı bağlantı noktası üzerinden yerel ana bilgisayar sunucusuna bağlayın ve bağlan menüsünü seçin. Bağlantı için bir ad girin ve veritabanı sunucusu metin kutusuna yerel ana bilgisayar konumunu girin ve ardından bağlan'a tıklayın.Geçerli veritabanlarına sahip bir ağaç görünmelidir. Mongo veritabanını genişletin. İlgilendiğiniz koleksiyonu seçin ve koleksiyon menüsünü açın.İlk Mongo veritabanı sorgusunu yürütmek için sorgu oluşturucuya ve sorgu alanı düğmelerine çift tıklayın. Mongo veritabanı sorgusunun alanlarını sorgu panelinin alanlar metin kutusuna, sorgunun değerini ise sorgu panelinin değer metin kutusuna girin. Sorgu oluşturucunun projeksiyon alanına çift tıklayın ve ilk projeksiyonu projeksiyon metin kutusuna girin.Yeni bir projeksiyon metin kutusu eklemek için projeksiyon alanına çift tıklayın ve ikinci projeksiyonu girin, ardından tıklayın, sorgularını yürütmek için oynatın ve sorgu kodunu sorgu kodu sekmesinde görselleştirin. Sonucun ayrıntıları, açıklama ve sonuçlar sekmesi altında görüntülenebilir olacaktır. Bir NoSQL EXist veritabanında artan karmaşıklık sorguları tasarlamak ve yürütmek için EXist veritabanını başlatın ve java yönetici istemcisini açın.Tıklayın, veritabanına bağlanın ve veritabanını seçin. Tıklayın, X yolunu kullanarak veritabanına danışın. Danışma iletişim kutusu görünecektir.Ardından ilk X yolu sorgusunu yürütün. Bu tabloda, hastaların isimleri, başlangıç ve bitiş tarihleri ve önem derecesi dahil olmak üzere sorunları hakkında bilgi içeren gerçekçi standartlaştırılmış elektronik sağlık kaydı ekstreleri üzerinde gerçekleştirilen altı farklı sorgu gösterilmektedir. Her veritabanı yönetim sistemindeki altı sorgunun ve üç katına çıkan boyutlu veritabanının ortalama yanıt süresi, ilişkisel nesne ilişkisel eşleme veritabanı analizinde gözlemlenmeyen, ilişkisel olmayan veritabanlarının tüm sorguları boyunca hesaplama karmaşıklığının uzun bir doğrusal davranışını gösterir.Mongo veritabanı sonuçlarının benzer sorgularla ve arketip ilişkisel eşleme sonuçlarının veritabanı boyutlarıyla enterpolasyonlanması, ilk sorgu için her iki veritabanı sisteminde de eşit sonuçlar üretir, ancak üçüncü sorgu için Mongo veritabanı kullanılarak daha uygun sonuçlar belirlenir. Eşzamanlılık deneylerinde, Mongo veritabanı hem aktarım hızı hem de yanıt sürelerinde MySQl veritabanına tercih edilir, Mongo veritabanı eşzamanlılıkta bir yalıtımdan daha iyi davranır ve eşzamanlı yürütmede etkileyici bir veritabanı olarak durur. Bunu düşündüm, istemci sorguları gerçekleştirirken tüm sunucuları yerel olarak aynı makinelerde tutmayı unutmamak önemlidir.Bu prosedürü takiben, bir veritabanı türü var olabilir mi ve hem tek hem de tüm hasta sorgularında kazanabilir mi? gibi ek soruları yanıtlamak için diğer tür veritabanı sistemlerini kullanmak gibi başka yöntemler de gerçekleştirilebilir. Geliştirildikten sonra bu teknik, algoritmik karmaşıklık alanındaki araştırmacıların farklı türdeki veritabanı sistemlerindeki karşılaştırmalı veritabanı performanslarını keşfetmeleri için bir yol açtı. Bu videoyu izledikten sonra, çok farklı türdeki veritabanı sistemlerinin boyut büyüten veritabanlarında karmaşıklığı artıran sorguların nasıl yürütüleceğini iyi anlamış olmalısınız.

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

Research

JoVE Journal

Medicine

Tıp

Biz bir iletişim kuralı ve ilişkili programlama kodu aynı zamanda bir bulut tabanlı otomatik kimliği kullanıcı seçili bilgi etki Biyomedikal edebiyat alanındaki benzersiz kavramları temsil eden ifadeler-Kategori Derneği desteklemek için meta veri örnekleri mevcut. Bu iletişim kuralı tarafından sayısal ifade-Kategori Derneği derinlik analizi seçili bilgi etki alanındaki kolaylaştırabilir.

Bulut tabanlı ifade araştırma ve analiz Biyomedikal yayınlarda kullanıcı tanımlı tümcecik-Kategori Derneği

Birçok araştırmacı, elektronik tablolar yerine veritabanları ile daha verimli bir şekilde yönetilebilen "orta ölçekli", düşük hız ve çok boyutlu veriler oluşturur. Burada, çok boyutlu verileri görselleştirme, ilişkisel veritabanı yapılarındaki tabloları bağlama, yarı otomatik veri ardışık lıklarının eşlemi nin eşleştirilmesi ve veri anlamlarının açıklığa kavuşturulması için veritabanını kullanma gibi veritabanlarının kavramsal bir genel görünümünü salıyoruz.

Doku Mühendisliğinde Orta Ölçekli, Düşük Hız, Çok Boyutlu Verileri Verimli Bir Şekilde Yönetecek Veritabanları

TBase, elektronik sağlık kaydını böbrek nakli alıcıları için yenilikçi bir araştırma veritabanıyla birleştirir. TBase, farklı hastane sistemlerine bağlı ve düzenli ayakta bakım için kullanılan bir bellek içi veritabanı platformu üzerine inşa edilir. Transplantasyona özgü veriler de dahil olmak üzere ilgili tüm klinik verileri otomatik olarak entegre ederek benzersiz bir araştırma veritabanı oluşturur.

TBase - Böbrek Nakli Alıcıları için Entegre Elektronik Sağlık Kaydı ve Araştırma Veritabanı

gP2S, cryoEM deneylerinin izlenmesi için bir web uygulamasıdır. Ana özellikleri, uygulamayı yüklemek ve yapılandırmak için gereken adımlar gibi açıklanmıştır. Yapılandırıldıktan sonra, uygulama negatif leke ve cryoEM denemeleriyle ilişkili meta verileri doğru bir şekilde kaydetmeye izin verir.

gP2S, CryoEM Deneyleri için Bir Bilgi Yönetim Sistemi

Postoperatif ileus (POI) artmış morbidite ve uzamış hastanede kalış yol abdominal cerrahi bir komplikasyonudur. Profilaktik veya terapötik stratejiler yoğunlaştırılmış araştırma yokluğu nedeniyle gereklidir. Bu nedenle İÇN patofizyolojisi araştırmak ve olası tedavi seçenekleri incelemek için bir standart ve uygulanabilir fare modeli kurulmuştur.

Bağırsak Manipülasyon bir Standart Model Analizleri: Kemirgenler Barsak Motilite ve Gut Duvar İnflamasyon İşlevsel Değerlendirilmesi

Lezyon Explorer (LE), Alzheimer hastalığı ve normal yaşlı yapısal MRG bölgesel beyin dokusu ve subkortikal hiperintens lezyon Volumetrics elde etmek için geliştirilmiş bir yarı-otomatik, görüntü işleme boru hattı. Doğruluk ve güvenilirlik yüksek düzeyde sağlamak için, aşağıdaki LE kılavuzu prosedürleri için bir video-güdümlü, standart bir protokoldür.

Lezyon Explorer: Doğru ve Güvenilir MR türetilmiş Alzheimer Hastalığı Volumetrics ve Normal Yaşlı Bir Video-güdümlü, Standart Protokol

Biz ultralow vizyona sahip kişilerin engel kaçınma değerlendirmek için kullanılabilecek bir kapalı, portatif, standart ders anlatmak. Ders yönetmek için basit, nispeten ucuz olan, güvenilir ve tekrarlanabilir olduğu gösterilmiştir.

Ultra Düşük Vizyon Görsel Fonksiyon ve Yapay Vizyon Değerlendirilmesi için Standart Engel Kursu

Bu protokol, farelerde normal ve kusurlu kemik iyileşmesini analiz etmek için kullanılabilen, femur osteotomilerinin standardize edilmesi için intramedüller kilitleme çivisi kullanan bir osteosentez tekniğini tanımlar.

Femur Osteotomiler standardize Sabitleme için bir intramedüller Kilitleme Nail Fare Normal ve Arızalı Kemik Şifa Analiz

Burada, burun potansiyel farkı (NPD) ölçmek için standart bir protokol mevcut. Kistik Fibrozis Transmembran gürültülerinden regülatörü (CFTR) ve epitel sodyum kanal (ENaC) işlevi değerlendirilir voltaj değişikliği tarafından arasında nazal epitel iyon kanal etkinlik, değiştirmek çözümler superfusion sonra sağlayan bir Sonuç ölçü.

Burun membran Transepithelial potansiyel farkının (NPD) standart ölçüm

Literatür veritabanları genellikle bibliyometrik analiz olarak bilinen bir uygulama olan belirli bir konuda, disiplinde, ülkeveya dünyanın bölgesinde yayınları değerlendirmek için kullanılır. Geçerli protokol, bibliyometrik analiz yapmak için PubMed, Scopus ve Web of Science veritabanlarının nasıl kullanılacağını ayrıntılarıyla anlatır.

PubMed, Scopus ve Web of Science Veritabanlarını Kullanarak Bibliyometrik Analizlerin Karşılaştırılması

Keşfedin MySQL ve MongoDB veritabanlarında karmaşıklık artan sorguların yürütme sürelerini karşılaştırarak hesaplama karmaşıklığını analiz etme yöntemini. Bu teknik, veritabanı seçimi için performans içgörüleri sunar.

İlişkisel (MySQL) ve NoSQL karmaşıklık artan sorguları yürütme (NoSQL ve mevcut) boyutu büyüyen ISO/EN 13606 standart EHR veritabanları (Video) | JoVE Journal

İlişkisel (MySQL) ve NoSQL karmaşıklık artan sorguları yürütme (NoSQL ve mevcut) boyutu büyüyen ISO/EN 13606 standart EHR veritabanları

Daha fazla video keşfet