Name: executing complexity-increasing queries in relational (mysql) and nosql (mongodb and exist) size-growing iso/en 13606 standardized ehr databases
Uploaded: 2018-03-19T14:30:00.000+00:00
Duration: 7 min 26 s
Description: Watch this Scientific Journal Video about Executing Complexity-Increasing Queries in Relational MySQL and NoSQL MongoDB and EXist Size-Growing ISO/EN 13606 Standardized EHR Databases at JoVE.com

저자 박사 Dipak Kalra, 표준 ISO/EN 13606와 ISO/EN 13606 W3C XML 스키마를 사용 하 여 그들의 종류 권한을 대학 대학 런던에서 그의 팀을 정의 하는 EHRCom 태스크 포스의 리더를 감사 하 고 싶습니다.
이 작품은 Instituto de에 의해 지원 되었다 건배 카를로스 III [보조금 번호 PI15/00321, PI15/00003, PI1500831, PI15CIII/00010, RD16CIII].

1. 3 개의 두 배 크기의 표준화 된 EHR 추출 데이터베이스를 저장 하는 관계형 MySQL DBMS 구축
<ol><li>가져오기는 W3C (World Wide Web 컨소시엄) XML 스키마에 해당 하는 ISO/EN13606 RM 및 ISO21090 데이터 형식에는 '자바 IDE' (통합 개발 환경). 참고: ISO 국제 표준 기구에 대 한 의미합니다. EN 유럽 표준에 대 한 의미합니다.</li>
	<li>JAXB (자바 XML 바인딩); IDE에 플러그인 실행 이 EHR 추출 XML 파일의 요소에의 구조에 해당 하는 자바 클래스를 생성 합니다.</li>
	<li>JPA 레이블 생성 하는 Java 클래스를 수동으로 태그. 이러한 분류는 카디널리티 및 MySQL 데이터베이스의 관계형 테이블 사이 다른 관계를 참조 하십시오.</li>
	<li>IDE에 JPA (자바 지 속성 API)의 라이브러리를 가져오고 태그 자바 클래스에서 MySQL 데이터베이스를 구축 하는 방법을 실행.</li>
	<li>XML 파일 5000, 10000 그리고 20000 현실적인 EHR 추출 물과 세 가지 디렉터리를 만듭니다.</li>
	<li>XML 추출 5000 추출 디렉터리의 모든 추출 물에 MySQL DBMS를 JPA 메서드를 실행 합니다.</li>
	<li>한 번 10000 추출 디렉터리와 함께 한 번 20000 추출 디렉터리 1.6 단계를 두 번 반복 합니다.</li>
</ol>2. 3 개의 두 배 크기의 표준화 된 EHR 추출 데이터베이스를 저장 하는 NoSQL MongoDB DBMS 구축
<ol><li>프로세스 각 5000, 10000 그리고 20000 현실적인 EHR 추출 XML 파일 XML 파일 json.org.XML 같은 JSON 파일을 변환 하는 표준 프로그램을 포함 하는 세 가지 디렉터리의. 5000, 10000, 20000 JSON 파일 세 개의 디렉터리를 생산 한다.</li>
	<li>시작 MongoDB GUI (그래픽 사용자 인터페이스, 테이블의 자료를 참조).</li>
	<li>DOS (디스크 운영 체제) 시스템 창에서 mongod 프로그램을 실행 하 여 MongoDB 2.6 서버 를 시작 합니다.</li>
	<li>MongoDB GUI 27017 포트를 사용 하 여 로컬 호스트 서버에 연결 합니다.<ol>
<li>"연결" 메뉴를 선택 합니다.</li>
		<li>연결에 대 한 이름을 작성 (예를 들어 ' 첫 번째').</li>
		<li>DB 서버 텍스트 상자에 localhost:27017를 작성 합니다.</li>
		<li>"연결" 단추; 현재 데이터베이스와 나무는 왼쪽에 표시 됩니다.</li>
	</ol>
</li>
	<li>추출 물 5000 표준화 EHR을 포함 하는 데이터베이스를 구축 합니다.<ol>
<li>왼쪽에 나무의 상단에 연결의 이름을 클릭 하십시오.</li>
		<li>"파일" 메뉴를 선택 합니다.</li>
		<li>"데이터베이스 추가"를 선택 하십시오.</li>
		<li>나타나는 대화 상자에서 데이터베이스의 이름을 입력 합니다.</li>
		<li>클릭 확인입니다.</li>
	</ol>
</li>
	<li>추출 물 5000 표준화 EHR을 포함 하는 컬렉션을 빌드하십시오.<ol>
<li>왼쪽 트리에서 데이터베이스의 이름을 클릭 하십시오.</li>
		<li>메뉴 "데이터베이스"를 선택 합니다.</li>
		<li>"AddCollection"를 선택 하십시오.</li>
		<li>나타나는 대화 상자에 컬렉션의 이름을 입력 합니다.</li>
		<li>" 생성"을 클릭 합니다.</li>
		<li>컬렉션의 이름을 클릭 하십시오.</li>
		<li>"가져오기" 메뉴를 선택 합니다.</li>
		<li>라디오 단추를 선택 하십시오'JSON-몽고 쉘 / / mongoexport ".</li>
		<li>"다음"을 클릭 합니다.</li>
		<li>"소스 파일 추가" 버튼을 누릅니다.</li>
		<li>대화 상자를 사용 하 여 컴퓨터에 이동 합니다.</li>
		<li>오픈 5000 JSON를 포함 하는 디렉터리 파일을 추출 합니다.</li>
		<li>디렉터리에 있는 모든 파일을 선택 합니다.</li>
		<li>"열기"를 누릅니다. JSON 파일 목록 가져오기 대화 상자에 표시 됩니다.</li>
		<li>누르십시오 "다음"; 데이터베이스에 새 컬렉션의 미리 보기가 왼쪽에 나타납니다.</li>
		<li>"다음"을 누릅니다.</li>
		<li>"가져오기 시작"을 누릅니다. 가져오기의 진행 경과 시간과 가져온 파일의 수를 나타내는 왼쪽 아래로 나타납니다.</li>
	</ol>
</li>
	<li>단계 5와 추출 10000 표준화 EHR의 컬렉션을 구축 하는 6 단계를 반복 합니다.</li>
	<li>단계 5와 추출 물 20000 표준화 EHR의 컬렉션을 구축 하는 6 단계를 반복 합니다.</li>
</ol>3. 빌드는 NoSQL DBMS 저장 3 두 배 크기의 표준화 EHR 추출 데이터베이스에 존재
<ol><li>존재 하는 데이터베이스를 시작 합니다.</li>
	<li>데이터베이스의 아이콘을 사용 하는 Java 관리자 클라이언트를 엽니다.</li>
	<li>관리자 암호를 입력 합니다.</li>
	<li>"연결" 버튼을 누릅니다.</li>
	<li>추출 물 5000 표준화 EHR을 포함 하는 컬렉션을 빌드하십시오.<ol>
<li>도구 모음에서 "만들기 새 컬렉션" 메뉴를 선택 합니다.</li>
		<li>나타나는 대화 상자에서 새 컬렉션의 이름을 입력 합니다.</li>
		<li>클릭 "적용"; 새 컬렉션 표시 됩니다.</li>
		<li>컬렉션의 이름을 선택 합니다.</li>
		<li>도구 모음에서 "데이터베이스에 파일 저장" 메뉴를 선택 합니다.</li>
		<li>대화 상자를 사용 하 여 컴퓨터에 이동 합니다.</li>
		<li>5000 표준화 된 XML 추출 파일이 포함 된 디렉터리를 선택 합니다.</li>
		<li>"파일 또는 저장 하는 디렉터리를 선택" 버튼을 클릭 합니다. Note는 대화 상자가 나타납니다 파일 저장 되는 진행률을 표시 하 고 생성 하는 데이터베이스의 백분율.</li>
	</ol>
</li>
	<li>추출 물 10000 표준화 EHR을 포함 하는 컬렉션을 구축 하는 5 단계를 반복 합니다.</li>
	<li>추출 물 20000 표준화 EHR을 포함 하는 컬렉션을 구축 하는 5 단계를 반복 합니다.</li>
</ol>4. 디자인 고 3 관계형 MySQL 데이터베이스에서 6 복잡성 증가 하는 쿼리 실행
<ol><li>EHR 추출 물에서 사용 하는 전형에 따라 6 복잡성 증가 하는 쿼리를 디자인 합니다.</li>
	<li>MySQL 데이터베이스에 첫 번째 쿼리는 SQL 스크립트를 프로그램. SQL 추출 표준화 (전형)으로 인해 MySQL 데이터베이스의 특별 한 구조에 적응 해야 합니다. 데이터베이스 추출의 전체 구조를 매핑합니다. 그 결과, SQL 쿼리는 다소 복잡 합니다.</li>
	<li>비록 대부분의 인덱스는 DBMS에 의해 자동으로 만들어지는 인덱스 그들에 만들어진 경우 쿼리 응답 시간을 빠르게 것 이라고 다음 이러한 인덱스를 구성 하는 데이터베이스의 특성을 식별 합니다.</li>
	<li>쿼리가 아닌 자동으로 만들어진된 인덱스를 경우 수동으로 빌드.<ol>
<li>MySQL 서버 (보조 그림 1)에 연결 합니다.</li>
		<li>선택 하 고 왼쪽에 데이터베이스 이름을 클릭 하십시오.</li>
		<li>선택한 인덱싱된 필드 있는 관계형 테이블을 클릭 합니다.</li>
		<li>"구조" 탭을 클릭 하십시오.</li>
		<li>선택한 인덱스 구축 될 열을 클릭 합니다.</li>
		<li>"인덱스"를 클릭 하십시오. Note는 인덱스를 작성 하면 SQL 문장, 나타나고 문장 성공적으로 구축 되었습니다 내용의 메시지가 나타납니다.</li>
	</ol>
</li>
	<li>첫 번째 쿼리를 실행 합니다.<ol>
<li>선택 하 고 왼쪽에 데이터베이스 이름을 클릭 하십시오.</li>
		<li>"SQL" 탭을 클릭 하십시오.</li>
		<li>작성 하거나 첫 번째 쿼리의 SQL 코드를 붙여 넣습니다 ( 보충 그림 2참조).</li>
		<li>"계속"을 누릅니다. 참고 쿼리 실행 시간에 포함 된 메시지와 함께 결과 목록의 첫 번째 화면이 나타납니다.</li>
		<li>5 번 실행을 반복 하 고 평균 응답 시간 계산.</li>
	</ol>
</li>
	<li>쿼리 2-6 단계 5를 반복 합니다.</li>
	<li>세 번, 5000, 10000, 20000 추출 데이터베이스와 전체 프로세스를 할.</li>
</ol>5. 디자인 고 3 NoSQL MongoDB 데이터베이스에 6 복잡성 증가 하는 쿼리 실행
<ol><li>MongoDB GUI를 실행 ( 재료의 표참조).</li>
	<li>DOS 시스템 창에서 mongod 프로그램을 실행 하는 MongoDB 2.6 서버 시작 ( 보충 그림 3참조).</li>
	<li>따라 단계 2.4 MongoDB GUI 27017 포트를 사용 하 여 로컬 호스트 서버에 연결할.</li>
	<li>선택한 왼쪽에 MongoDB 데이터베이스를 확장 합니다.</li>
	<li>컬렉션을 선택 합니다.</li>
	<li>도구 모음에서 "컬렉션" 메뉴에서 클릭 합니다.</li>
	<li>첫 번째 MongoDB 쿼리를 실행 합니다.<ol>
<li>"쿼리 작성기" 버튼을 두 번 누릅니다.</li>
		<li>"쿼리 필드" 쿼리 작성기 오른쪽의 두 번 클릭.</li>
		<li>쿼리 패널 ( 보충 그림 4참조)의 필드 텍스트 상자에 MongoDB 쿼리의 필드를 작성 합니다.</li>
		<li>쿼리 패널의 값 텍스트 상자에 MongoDB 쿼리 값을 작성 합니다. 참고:이 쿼리 {"ns3:EHRExtract.allCompositions.content.items.parts.parts.name.ns2:originalText 같은 것 이어야 한다. "값:"Descripcion"}. 필드와 값 인용 하 고 세미콜론으로 구분 됩니다.</li>
		<li>쿼리 작성기의 투영 필드를 두 번 클릭</li>
		<li>프로젝션 텍스트 상자에 첫 번째 투영을 작성 ( 보충 그림 5참조).</li>
		<li>프로젝션 필드 새로운 프로젝션 textbox를 추가를 두 번 클릭.</li>
		<li>프로젝션 텍스트 상자에 두 번째 투영을 작성 합니다. 참고: 투영 쿼리에서 검색 하는 문서의 부분을 선택 합니다. 이 {"ns3:EHRExtract 같은 것을 해야. allCompositions.content.items.parts.parts.value.value": 1} 및 {" n s 3: EHRExtract.all Compositions.content.items.parts.parts.value.nullFlavor ": 1}</li>
		<li>쿼리를 실행 하려면 파란색 재생 버튼을 클릭 합니다.</li>
		<li>쿼리 코드 탭에서 쿼리 코드를 시각화 합니다.</li>
		<li>설명 탭에서 결과의 세부 정보를 볼: 결과의 수, 실행 시간 (밀리초)입니다.</li>
		<li>확인, 확장, 하 고 결과 탭에서 결과 검사.</li>
		<li>추가 쿼리의 처리 하는 것이 필요한 경우 결과 처리 하는 쿼리 및 메서드 MongoDB Java 드라이버와 자바 프로그램을 작성 합니다.</li>
		<li>5 번 실행을 반복 하 고 평균 응답 시간 계산.</li>
	</ol>
</li>
	<li>5.7 6 쿼리를 통해 나머지 2 단계 할.</li>
	<li>MongoDB 데이터베이스를 추출 하는 5000, 10000, 20000 전체 프로세스를 반복 합니다.</li>
</ol>6. 디자인 고 3에서 실행 NoSQL 데이터베이스 6 증가 복잡성 쿼리 존재
<ol><li>존재 DBMS를 시작 합니다.</li>
	<li>자바 관리 클라이언트를 엽니다.</li>
	<li>""데이터베이스에 연결단추를 누릅니다.</li>
	<li>데이터베이스를 선택 하 고 그것을 클릭.</li>
	<li>"XPath를 사용 하 여 데이터베이스를 참조 하십시오"; 메뉴 클릭 상담 대화 상자가 나타납니다.</li>
	<li>첫 번째 XPath 쿼리 실행 ( 보충 그림 6참조).<ol>
<li>작성 하거나 대화 상자의 상단 부분에 첫 번째 쿼리의 XPath 코드를 붙여 넣습니다.</li>
		<li>대화 상자의 도구 모음에서 "실행" 메뉴에서 클릭 합니다.</li>
		<li>대화 상자의 아래 부분에 "XML" 탭을 사용 하 여 XML 결과 보기.</li>
		<li>결과 및 컴파일 및 실행 시간 대화 상자의 맨 아래에 보기 수입니다.</li>
		<li>5 번 실행을 반복 하 고 평균 응답 시간 계산.</li>
	</ol>
</li>
	<li>쿼리 2 6-6 단계를 반복 합니다.</li>
	<li>5000, 10000, 20000 추출 존재 데이터베이스 전체 과정 3 번 마십시오.</li>
</ol>7. 디자인 하 고 MySQL 데이터베이스를 추출 하는 MongoDB 5000를 사용 하 여 동시성 실험 실행
참고: 존재 데이터베이스 이전 실험에서 더 성능 때문에 시점에서 실험에서 제거 되었습니다.
<ol><li>(일반적으로 몇 초)에서 5000 추출 데이터베이스를 사용 하 여 이전 실험에서 3 개의 짧은 시간 응답에 포함 된 쿼리를 선택 합니다.</li>
	<li>식별 하 고 필요한 경우 수동으로 해당 쿼리에 대 한 적절 한 특성 인덱스를 작성 합니다.</li>
	<li>자바 다중 스레드 응용 프로그램 2, MySQL에 대 한 하나; MongoDB에 대 한 다른 각 응용 프로그램은 1 단계에서 선택한 각 쿼리에 대 한 하나의 3 개의 다른 우선 순위 스레드가 있을 것 이다.</li>
	<li>실행 하 고 있는 CPU (중앙 처리 장치) 배포를 사용 하 여 각 스레드 (쿼리)에 대 한 계산.</li>
	<li>각 10 분 기간 동안 5 번 실행 버튼 클릭 하면 각 다중 스레드 응용 프로그램을 실행 하 고 가장 실행된 (가장 높은 우선 순위) 계산 평균 처리량과 평균 시간 응답의 3 개의 쿼리를 쿼리.</li>
	<li>쿼리 실행, 우선순위와 실행 시간에에서 보기.</li>
	<li>평균 처리량 및 3 개의 질문의 각각의 평균 응답 시간을 계산 합니다.</li>
</ol>

<ol>
	<li>Codd, E. F. <a target="_blank" href="http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=PubMed&cmd=Search&doptcmdl=Citation&defaultField=Title+Word&term=A+relational+model+for+large+shared+data+banks.">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://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=PubMed&cmd=Search&doptcmdl=Citation&defaultField=Title+Word&term=.">.</a> ISO 13606 electronic health record communication part 1: reference model. , (2008).</li><li>Kalra, D., et al. <a target="_blank" href="http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=PubMed&cmd=Search&doptcmdl=Citation&defaultField=Title+Word&term=.">.</a> Electronic health record communication part 2: archetype interchange specification. , (2008).</li><li>Kalra, D., Beale, T., Heard, S. <a target="_blank" href="http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=PubMed&cmd=Search&doptcmdl=Citation&defaultField=Title+Word&term=The+openEHR+foundation.">The openEHR foundation.</a> Stud. Health Technol. Inform. 115, 153-173 (2005).</li><li>Beale, T. <a target="_blank" href="http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=PubMed&cmd=Search&doptcmdl=Citation&defaultField=Title+Word&term=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&#225;nchez-de-Madariaga, R., et al. <a target="_blank" href="http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=PubMed&cmd=Search&doptcmdl=Citation&defaultField=Title+Word&term=Examining+database+persistence+of+ISO/EN+13606+standardized+electronic+health+record+extracts:+relational+vs.+NoSQL+approaches.">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="http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=PubMed&cmd=Search&doptcmdl=Citation&defaultField=Title+Word&term=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/entrez/query.fcgi?db=PubMed&cmd=Search&doptcmdl=Citation&defaultField=Title+Word&term=Archetype+relational+mapping+-+a+practical+openEHR+persistence+solution.">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://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=PubMed&cmd=Search&doptcmdl=Citation&defaultField=Title+Word&term=Managing+data+in+healthcare+information+systems:+many+models,+one+solution.">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="http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=PubMed&cmd=Search&doptcmdl=Citation&defaultField=Title+Word&term=An+innovative+approach+to+manage+heterogeneous+information+using+relational+database+systems.">An innovative approach to manage heterogeneous information using relational database systems.</a> Advances in Intelligent Systems and Computing. 557, (2017).</li></ol>

저자는 공개 없다. 이 실험에 사용 된 데이터 집합이이 실험에 대 한 라이센스 여러 스페인 병원에 의해 제공 되었다 고 따라서 공개적으로 사용할 수 있습니다. ISO/EN 13606 RM XML 스키마 했다 대학 대학 런던 센터 의료 정보학 및 Multiprofessional 교육 (차 임)에 제공 됩니다.

이 프로토콜 표시는 순수 관계형 ORM 시스템 하지 않는 것 단일 환자 쿼리 (Q1, Q3, Q4)에 대 한 실제 응답 시간이 느린 때문에 많은 비싼 조인 작업을 수행 하는 관계형 테이블의 높은 숫자 때문에 아마 때문에 특정 종류의 데이터베이스에서 사용 하는 스토리지 시스템. NoSQL 데이터베이스는 관계형 시스템 사용 테이블-기반 패션 데이터베이스 전체에 걸쳐 각 문서를 확산 하는 문서 기반 패션에 데이터를 저장 합니다. NoSQL 시스템 DBMS 보다 상당히 빠른 수행 MongoDB와 선형 경사를 보여줍니다. 동시성, MongoDB는 또한 관계형 MySQL ORM7보다 훨씬 더 잘 동작합니다.
이 프로토콜은 ORM MySQL DBMS에 관한7 에서 제시 하는 결과 대 한 문제 해결 프로토콜을 제공 합니다. MySQL 시스템 최신 버전으로 업데이트 하 고 결과 약간 수정 되었습니다. 또한, 문서 기반의 NoSQL 시스템에서 중요 한 포인트와 같은 MongoDB EHR을 추출 하 여 업데이트 될 때 그것은 덮어쓰기되지 않습니다, 때문에 의료 정보7 를 저장 하지만 전체 새로운 새 데이터로 추출 하는 때 그들은 일관성을 보존할 수는 생성 하 고 시스템에 저장 된 원래 추출 유지 됩니다. 이것은 의료 정보의 엄격한 요구 사항 때문에 일부 의료 종사자 들은 원래 데이터에 따라 중요 한 의료 결정을 만들 수 있습니다.
크게 향상 된 관계형 팔 시스템 관계형 테이블의 수를 감소 하 고 관계형 성능을 향상 시킵니다. 관계형 스키마를 수정 하는 때문에, 추출 하 여 보유 하는 의료 정보를 쿼리할 수 있습니다, 그러나, 추출 물 그들의 정확한 원래 형태로 복구할 수 없습니다.
중에서 매우 큰 데이터베이스 사용 (연구), 그것은 때문에 모든 환자 쿼리 (q 2와 q 5) 행동 보다 ORM에 더 나은 NoSQL 시스템, 데이터베이스 시스템은 더 적절 한 불분명 하지만 이러한 시스템 수행 보다는 단순화 된 관계형 12에서시스템입니다. 우리 고려 Q6 임상 연습 사이 및 보조 특별 한 쿼리 사용 동작 이러한 실험에 의해 굴복 하는 결과 의해 결정 될 수 없습니다.
그러나, 방법의 한 가지 한계는 정확히 동일한 데이터 프로토콜에 사용 되는 향상 된 관계형 팔 시스템 NoSQL MongoDB 쿼리를 단일 환자, 의료 연습에 관한 비교는 직접 실험의 inavailability. 우리는 인터폴 레이 팅 표 3 및 표 5 단일 환자 쿼리에 관한 실험 프로토콜에 최적화 된 팔을 포함 하 여 수행 될 때까지 결과 유지. 우리는 미래의 응용 프로그램에 대 한 이러한 실험을 두고. 우리는 정확한 상태--예술의 세 가지 기술을 비교할 수 있도록 프로토콜 내에서 하나의 중요 한 단계는 다양 한 무료 데이터베이스, 최근 몇 년 동안에서 유사한 소프트웨어 버전입니다.
이것을 직접 관계형 비교할 첫 번째 시도 및 실제, 현실, 표준화 된 의료 정보를 사용 하 여 NoSQL 시스템 중 하나입니다. 그러나, 사용 될 특정 시스템 훨씬 실제 시나리오 및 문제 해결된8수에 따라 다릅니다.

NoSQL (뿐만 아니라 SQL) DBMS 최근 대신 전통적인 관계형 DBMS (RDMBS)에 등장. RDBMS는 데이터 수십 년 동안 데이터베이스 시스템에 저장 하는 방법을 지배 있다. 잘 공부 하 고 이해 관계형 대 수와 미적분학 효율성과 RDBMS1의 일관성을 보장 했습니다. NoSQL 시스템 관계형 시스템에 대 한 대체 될 수 없는 것입니다 하지만 그들은 특정 시나리오에서 조건 하에서 여러 advantageously 행동할 수 있었다.
특정 시나리오의 일부 데이터베이스 유지 관리 및 의료 정보를 저장 하는 데 사용 하는 전자 건강 기록 (EHR) 시스템을 설계할 때 발생 합니다. 상호 운용성 및 연습, 여러 국제 표준 ISO/EN 13606, openEHR, 및 HL72,,34등 지속 가능한 있어야,5 표준화 EHR 추출 물 사용 되었습니다.
ISO/EN 13606, openEHR 등 여러 기준을 참조 모형 (RM)으로 표현 하는 추상화의 전형이라는 특수 한 데이터 구조는 두 가지 서로 다른 수준으로 정보와 지식을 분리 했습니다. 이 분리는 종종 듀얼 모델 이라고 하 고 그것 EHR 시스템을 전체 EHR 시스템 프로그래밍을 하지 않고, 그리고 결과적으로, 진화를 의미상으로 운용 하 고 의료 지식을 관리 하 고 실제로6 지속 가능한 . 그러나, 표준화 된 EHR 시스템에서 구현 하는 듀얼 모델 하려면 정보 특정 구조를 따르는이 방식으로 시스템의 데이터베이스 지 속성 수준 설계7깊은 결과가지고 합니다.
개체 관계형 매핑 (ORM)8 은 관계형 데이터베이스 패러다임을 사용 하 여 EHR 시스템을 구현 하기 위해 한 방법입니다. ORM은 철저 하 게 표준화 된 EHR 추출 XML (확장 마크업 언어) 파일 시스템에서 사용 하는 관계형 데이터베이스의 구조를 매핑합니다. ORM는 철저 하 게 표준화 된 EHR 추출 XML 파일의 구조에 따라 많은 관계형 테이블을 생성 합니다. 이러한 관계형 테이블 많은 외래 키를 통해 관련 고 결과 시스템은 매우 효율적으로 되지 않을 수 있습니다.
ORM 여러 관계형 개선 제안 되었습니다. openEHR의 노드 + 경로9 Blob (이진 대형 개체)로 전체 추출 XML 파일의 직렬화 하위에 의해 관계형 테이블의 수를 줄입니다. 그러나,이 단순화는 복잡 한 쿼리를 손상 하는 복잡 한 검색 논리를 발생 합니다. 상을 관계형 매핑 (팔)10 전형, 전형 및 관계형 테이블 간의 매핑을 기반으로 새로운 관계형 스키마를 구축에 힘입어 데이터베이스 모델을 생성 합니다. 따라서, 일부 EHR 추출의 비 의료 정보는 손실 됩니다.
많은 문서 기반의 NoSQL 데이터베이스는 원래 XML 또는 JSON (자바 스크립트 객체 표기법)을 존중 하는 전체 Blob으로 전체 문서 저장 형식. 즉, 관계형 테이블이 생성 됩니다. 이러한 NoSQL 데이터베이스 스키마 있고 중 조인 또는 (산) 속성11, 즉, 원자성, 일관성, 격리, 또는 내 구성을 지원 하지 않습니다. 결과적으로, 그들은 수 있습니다 매우 효율적으로 동일한 요소를 참조 하는 문서 요소 또는 간접 링크를 활용 하 여 다른 문서. 일관성을 유지 하기 위해 참조 된 문서의 전체 순차적으로 처리 해야 하기 때문에 발생 합니다. 그러나, 비-관계형 데이터베이스는 DBMS에 의해 수행 하는 주요 작업은 문서 기반 작업 하는 경우에 아직도 적절 한 수 있습니다. 이 때문에 데이터가 남아 있을 수 있습니다 폼에 더 밀접 하 게 가깝게 문서 기반의 NoSQL 데이터베이스를 사용 하 여 그것의 진정한 표현을 EHR 의료 문서 (토론 섹션 참조)에 의해 수행 하는 특별 한 유지 정책 때문 이기도 하지만.
이 방법의 목적은 세 가지 다른 Dbms를 사용 하 여 표준화 된 EHR 시스템의 지 속성 계층의 구현을 비교 몇 가지 실험을 선보일: 한 관계형 (MySQL)와 두 개의 NoSQL (MongoDB 문서 기반 그리고 네이티브 XML). 그들의 복잡 한 계산 되었습니다 계산 하 고 3 개의 다른 증가 크기 데이터베이스 및 6 다른 복잡성 증가 하는 쿼리를 사용 하 여 비교. 세 가지 데이터베이스 서버를 설치 하 고 쿼리 실행 되어 같은 컴퓨터에서 로컬로 구성 되었습니다. 기술적인 세부 사항에 대 한 테이블의 자료 를 참조 하십시오.
동시성 실험 또한 관계형 MySQL과 NoSQL MongoDB Dbms의 성능을 비교 하기 위해 실시 되었습니다. 설명된 ORM 개선 (노드 + 경로 및 팔)도 문학10관련 적절 한 결과 사용 하 여 비교 되었습니다.
데이터베이스 관리 시스템은 가속 속도로 지속적으로 진화 하고있다. 아무도 유일한 기존 패러다임은 관계형 모델이 지 수 개발에 대 한 생각 것 이다. 예제를 참조 하십시오 예를 들어12, ACID 속성을 유지 하는 응답 시간 향상 된 관계형 데이터베이스를 구현 하는 모델 제안 어디.

<table><tbody><tr><td>MySQL 5.7.20</td><td></td><td></td><td>MySQL experiments</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 experiments</td></tr><tr><td>Windows 7, 2.66GHz, RAM 12GB&amp;nbsp;</td><td></td><td></td><td></td></tr><tr><td>eXist 3.0RC1</td><td></td><td></td><td>eXist experiments</td></tr><tr><td>Windows 7, 2.66GHz, RAM 12GB&amp;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>

executing complexity-increasing queries in relational (mysql) and nosql (mongodb and exist) size-growing iso/en 13606 standardized ehr databases

이 연구는 관계형 쿼리 계산 복잡도 평가 하는 프로토콜 및 비-관계형 (NoSQL (뿐만 아니라 구조적 쿼리 언어)) 표준화 전자 건강 기록 (EHR) 의료 정보 데이터베이스 시스템 (DBMS). 그것은 사용 하 고 3 배 크기의 데이터베이스, 즉 데이터베이스 저장 5000, 10000 그리고 20000 현실적인 세 가지 다른 데이터베이스 관리 시스템 (DBMS)에서 EHR 추출 물, 표준화: 관계형 MySQL 개체-관계형 매핑 (ORM), 문서 기반의 NoSQL MongoDB, 그리고 네이티브 확장 마크업 언어 (XML) NoSQL 존재.
6 증가 하는 복잡 한 쿼리를 평균 응답 시간 계산 된 고 결과 NoSQL의 경우 선형 동작을 보였다. NoSQL 필드에 MongoDB 존재 보다 많은 아첨 선형 슬로프를 제공합니다.
NoSQL 시스템 일관성과 NoSQL 데이터베이스에 저장 된 데이터의 효율성에 영향을 주지 해야 의료 정보의 업데이트 정책의 특별 한 특성으로 인해 표준화 된 의료 정보 시스템을 유지 하기 위해 더 적절 한 수도 있습니다.
이 프로토콜의 한계가 상 관계형 매핑 (팔) 같은 데이터와 향상 된 관계형 시스템의 직접적인 결과의 부족 이다. 그러나, 그 두 배로 크기 데이터베이스 결과의 보간 문학에서 제시 하 고 다른 게시 된 결과 NoSQL 시스템은 더 많은 특정 시나리오 및 문제 해결에 적절 한 수 있습니다 제안 합니다. 예를 들어 NoSQL EHR 추출 임상 연습, 또는 판 및 시각화, 또는 목표 뿐만 아니라 상황에 사용 된 쿼리 의료 정보를 뿐만 아니라 정확 하 게 그것의 원래 모양에서 EHR 복원 같은 문서 기반 작업에 대 한 적절 한 있을 수 있습니다.

6 다른 쿼리 수행 현실적인 표준화 EHR 추출 물을 포함 하 여 그들의 이름, 초기 및 최종 날짜와 심각도, 환자의 문제에 대 한 정보를 포함 하는 표 1에 표시 됩니다.
각 DBMS의 3 배로 크기 데이터베이스에서 6 쿼리의 평균 응답 시간 표 2-4에 나와 있습니다. 그림 1-6 동일한 결과 그래픽으로 표시 (통지 수직 축이이 수치를 통해 매우 다른 비늘을 사용).
복잡 한 계산의 강한 선형 동작 3 데이터 집합 사용의 상대적으로 작은 크기에 따른 적절 한 주의 함께 비록 NoSQL 데이터베이스의 모든 쿼리를 통해 분명 하다. 그러나, 관계형 ORM 데이터베이스 불분명 선형 동작을 보여 줍니다. MongoDB 데이터베이스는 존재 데이터베이스 보다 훨씬 아첨 슬로프.
문학에서 출판 하는 소개에서 설명 하는 향상 된 관계형 시스템으로 결과 표 5에서 찾을 수 있습니다. MongoDB 결과 표 3 에서 비슷한 쿼리 및 표 5 에서 팔 결과의 데이터베이스 크기를 인터폴 레이 팅 두 데이터베이스 시스템, 1 분기에서와 동일 하지만 3 분기에 MongoDB를 하시 더군요.
동시성 실험의 결과 표 5 및 표6에서 찾을 수 있습니다. MongoDB은 처리량과 응답 시간에서 모두 MySQL을 친다. 사실, MongoDB 잘 동작 하는 절연, 보다 동시성 및 동시 실행에 인상적인 데이터베이스로 서.
<img alt="Figure 1" class="xfigimg" src="/files/ftp_upload/57439/57439fig1.jpg"> 그림 1 : 알고리즘 복잡성 ORM MySQL, MongoDB의 쿼리 q 1과 q 4에 대 한 DBMS를 존재 하 고. 이 그림7 크리에이 티브 코몬즈 라이센스 (http://creativecommons.org/ licenses/by/4.0/)를 사용 하 여 수정 된 고에서는 응답 시간 초 5000, 10000 및 20000 EHR 각 DBMS 및 쿼리 q 1과 q 4에 대 한 데이터베이스를 추출. <a href="//cloudflare.jove.com/files/ftp_upload/57439/57439fig1large.jpg" target="_blank">이 그림의 더 큰 버전을 보려면 여기를 클릭 하십시오.</a>
<img alt="Figure 2" class="xfigimg" src="/files/ftp_upload/57439/57439fig2.jpg"> 그림 2 : 쿼리 q 2에 대 한 ORM MySQL DBMS의 알고리즘 복잡성. 이 그림은 10000 및 20000 EHR 추출 ORM MySQL 데이터베이스 쿼리 q 2에 대 한 5000, 초에서 응답 시간을 보여 줍니다. <a href="//cloudflare.jove.com/files/ftp_upload/57439/57439fig2large.jpg" target="_blank">이 그림의 더 큰 버전을 보려면 여기를 클릭 하십시오.</a>
<img alt="Figure 3" class="xfigimg" src="/files/ftp_upload/57439/57439fig3.jpg"> 그림 3 : 알고리즘 복잡성 MongoDB의 쿼리 q 2와 q 5에 대 한 DBMS를 존재 및. 이 그림7 크리에이 티브 커먼즈 라이센스를 사용 하 여에서 수정 되었습니다 (에 의해 http://creativecommons.org/licenses/ / 4.0)에서는 응답 시간 초 5000, 10000 그리고 20000 크기 EHR 각 DBMS 및 쿼리 q 2와 q 5에 대 한 데이터베이스를 추출 하는 고. <a href="//cloudflare.jove.com/files/ftp_upload/57439/57439fig3large.jpg" target="_blank">이 그림의 더 큰 버전을 보려면 여기를 클릭 하십시오.</a>
<img alt="Figure 4" class="xfigimg" src="/files/ftp_upload/57439/57439fig4.jpg"> 그림 4 : 쿼리에 Q3 Q5 ORM MySQL DBMS의 알고리즘 복잡성. 각 DBMS 및 쿼리 q 3와 Q5에 대 한 데이터베이스를 추출 하는 10000 그리고 20000 크기 EHR 5000, 초에서 응답 시간을 표시 합니다. <a href="//cloudflare.jove.com/files/ftp_upload/57439/57439fig4large.jpg" target="_blank">이 그림의 더 큰 버전을 보려면 여기를 클릭 하십시오.</a>
<img alt="Figure 5" class="xfigimg" src="/files/ftp_upload/57439/57439fig5.jpg"> 그림 5: 존재와 MongoDB 쿼리 q 3에 대 한 DBMS의 알고리즘 복잡성. 이 그림7 크리에이 티브 코몬즈 라이센스 (여/4.0/http://creativecommons.org/licenses/)를 사용 하 여 수정 된 고에서는 응답 시간 초 5000, 10000 및 20000 EHR 각 DBMS 및 쿼리 q 3에 대 한 데이터베이스를 추출. <a href="//cloudflare.jove.com/files/ftp_upload/57439/57439fig5large.jpg" target="_blank">이 그림의 더 큰 버전을 보려면 여기를 클릭 하십시오.</a>
<img alt="Figure 6" class="xfigimg" src="/files/ftp_upload/57439/57439fig6.jpg"> 그림 6 : 알고리즘 복잡성 ORM MySQL의 존재와 MongoDB DBMS에 대 한 쿼리 Q6. 이 그림7 크리에이 티브 코몬즈 라이센스 (여/4.0/http://creativecommons.org/licenses/)를 사용 하 여 수정 된 고에서는 응답 시간 초 5000, 10000 및 20000 EHR 각 DBMS 및 쿼리 Q6에 대 한 데이터베이스를 추출. <a href="//cloudflare.jove.com/files/ftp_upload/57439/57439fig6large.jpg" target="_blank">이 그림의 더 큰 버전을 보려면 여기를 클릭 하십시오.</a>
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td></td>
			<td>쿼리</td>
		</tr>
<tr>
<td>1 분기</td>
			<td>단일 환자의 모든 문제를 찾아</td>
		</tr>
<tr>
<td>Q2</td>
			<td>모든 환자의 모든 문제를 찾아</td>
		</tr>
<tr>
<td>3 분기</td>
			<td>초기 날짜, 해상도 날짜 및 심각도</td>
		</tr>
<tr>
<td></td>
			<td>단일 환자에의 한 문제</td>
		</tr>
<tr>
<td>4 분기</td>
			<td>초기 날짜, 해상도 날짜 및 심각도</td>
		</tr>
<tr>
<td></td>
			<td>단일 환자의 모든 문제 문제</td>
		</tr>
<tr>
<td>Q5</td>
			<td>초기 날짜, 해상도 날짜 및 심각도</td>
		</tr>
<tr>
<td></td>
			<td>모든 환자의 모든 문제 문제</td>
		</tr>
<tr>
<td>Q6</td>
			<td>문제 '인 두 염', 모든 환자를 찾기</td>
		</tr>
<tr>
<td></td>
			<td>초기 날짜 > 2007/10/16 ' =', 해결 날짜</td>
		</tr>
<tr>
<td></td>
			<td>< = ' 06/05/2008 ' 및 심각도 '높은'</td>
		</tr>
</tbody></table>표 1: 6 쿼리는 관계형에서 수행과 NoSQL 데이터베이스 포함 된 표준화 된 EHR 환자의 문제에 대 한 추출. 이 테이블 크리에이 티브 코몬즈 라이센스 (http://creativecommons.org/ licenses/by/4.0/)를 사용 하 여7 에서 수정 되었습니다 및 자연에서 표현 하는 각 DBMS에 대 한 3 크기 성장 하는 데이터베이스에 수행 6 성장 하는 복잡 한 쿼리를 보여 줍니다. 언어입니다.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td>ORM/MySQL</td>
			<td>5000 문서</td>
			<td>10000 문서</td>
			<td>20000 문서</td>
		</tr>
<tr>
<td>1 분기 (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>3 분기 (s)</td>
			<td>3.3849</td>
			<td>6.4225</td>
			<td>207.2348</td>
		</tr>
<tr>
<td>4 분기 (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>데이터베이스 크기</td>
			<td>4.6 GB</td>
			<td>9.4 GB</td>
			<td>19.4 G B</td>
		</tr>
<tr>
<td>총 추출</td>
			<td>5000</td>
			<td>10000</td>
			<td>20000</td>
		</tr>
</tbody></table>표 2: 평균 응답 시간 두 배로 크기 데이터베이스 ORM MySQL 관계형 DBMS의 6 개의 쿼리의 초에서. 이 테이블 3 배 크기의 데이터베이스 ORM MySQL 관계형 DBMS를 사용 하 여 세 가지 데이터베이스의 메모리 크기에 대 한 각 쿼리에 대 한 6 응답 시간을 보여 줍니다.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td>MongoDB</td>
			<td>5000 문서</td>
			<td>10000 문서</td>
			<td>20000 문서</td>
			<td>슬로프 (*10exp(-6))</td>
		</tr>
<tr>
<td>1 분기 (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>3 분기 (s)</td>
			<td>0.048</td>
			<td>0.058</td>
			<td>0.1201</td>
			<td>4.81</td>
		</tr>
<tr>
<td>4 분기 (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>데이터베이스 크기</td>
			<td>1.95 GB</td>
			<td>3.95 기가바이트</td>
			<td>7.95 G B</td>
			<td></td>
		</tr>
<tr>
<td>총 추출</td>
			<td>5000</td>
			<td>10000</td>
			<td>20000</td>
			<td></td>
		</tr>
</tbody></table>표 3: 평균 응답 시간 MongoDB NoSQL DBMS의 배로 크기 데이터베이스에 6 개의 쿼리의 초에. 이7 크리에이 티브 코몬즈 라이센스 (http://creativecommons.org/ licenses/by/4.0/)를 사용 하 여 수정 된 테이블과 NoSQL MongoDB DBMS 및 메모리 크기를 사용 하 여 3 배 크기의 데이터베이스에 대 한 각 쿼리 6 응답 시간을 보여 줍니다. 세 가지 데이터베이스. 각 쿼리의 선형 슬로프도 표시 됩니다.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td>존재</td>
			<td>5000 문서</td>
			<td>10000 문서</td>
			<td>20000 문서</td>
			<td>슬로프 (*10exp(-6))</td>
		</tr>
<tr>
<td>1 분기 (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>3 분기 (s)</td>
			<td>0.6976</td>
			<td>1.771</td>
			<td>4.1172</td>
			<td>227.96</td>
		</tr>
<tr>
<td>4 분기 (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>데이터베이스 크기</td>
			<td>1.25 GB</td>
			<td>2.54 GB</td>
			<td>5 월 12 일 기가바이트</td>
			<td></td>
		</tr>
<tr>
<td>총 추출</td>
			<td>5000</td>
			<td>10000</td>
			<td>20000</td>
			<td></td>
		</tr>
</tbody></table>표 4: 평균 응답 시간 존재 NoSQL DBMS의 배로 크기 데이터베이스에 6 개의 쿼리의 초에. 이 표7 크리에이 티브 코몬즈 라이센스 (http://creativecommons.org/ licenses/by/4.0/)를 사용 하 여에서 수정 되었습니다 및 DBMS와의 메모리 크기는 NoSQL을 사용 하 여 3 배 크기의 데이터베이스에 대 한 각 쿼리 6 응답 시간 존재 표시 3 데이터베이스입니다. 각 쿼리의 선형 슬로프도 표시 됩니다.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td></td>
			<td>암 종이</td>
			<td>팔 (s)</td>
			<td>노드 + 경로 (s)</td>
		</tr>
<tr>
<td>1 분기</td>
			<td>쿼리 2.1</td>
			<td>0.191</td>
			<td>24.866</td>
		</tr>
<tr>
<td>3 분기</td>
			<td>3.1 쿼리</td>
			<td>0.27</td>
			<td>294.774</td>
		</tr>
<tr>
<td></td>
			<td>데이터베이스 크기</td>
			<td>2.90 GB</td>
			<td>43.87 GB</td>
		</tr>
<tr>
<td></td>
			<td>총 추출</td>
			<td>29,743</td>
			<td>29,743</td>
		</tr>
</tbody></table>표 5: 평균 응답 시간 쿼리 q 1과 q 3에는 향상 된 관계형 시스템의 비슷한 초에서 10 . 이 테이블7 크리에이 티브 코몬즈 라이센스 (http://creativecommons.org/ licenses/by/4.0/)를 사용 하 여 수정 된 나타나고 두 대부분 비슷한 쿼리 q 1과 q 3에10 두 향상 된 관계형 데이터베이스 시스템에 해당 하 그리고 그들의 응답 시간입니다. 두 개의 데이터베이스 크기도 표시 됩니다.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td>ORM/MySQL</td>
			<td>처리량</td>
			<td>응답 시간</td>
		</tr>
<tr>
<td>1 분기 (s)</td>
			<td>4,711.60</td>
			<td>0.0793</td>
		</tr>
<tr>
<td>3 분기 (s)</td>
			<td>4,711.60</td>
			<td>0.1558</td>
		</tr>
<tr>
<td>4 분기 (s)</td>
			<td>4,711.60</td>
			<td>0.9674</td>
		</tr>
</tbody></table>표 6: 평균 처리량과 응답 시간 쿼리 1 분기, 3 분기 및 4 분기의 ORM MySQL 관계형 DBMS 동시 실행에의 초. 이 테이블7 크리에이 티브 코몬즈 라이센스 (http://creativecommons.org/ licenses/by/4.0/)를 사용 하 여 수정 된 및 동시에 3 개의 단일 환자 쿼리 및 그들의 평균 응답 시간 가장 높은 평균 처리량을 보여줍니다. ORM MySQL 관계형 시스템을 사용 하 여 실행 실험입니다.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td>MongoDB</td>
			<td>처리량</td>
			<td>응답 시간</td>
		</tr>
<tr>
<td>1 분기 (s)</td>
			<td>178,672.60</td>
			<td>0.003</td>
		</tr>
<tr>
<td>3 분기 (s)</td>
			<td>178,672.60</td>
			<td>0.0026</td>
		</tr>
<tr>
<td>4 분기 (s)</td>
			<td>178,672.60</td>
			<td>0.0034</td>
		</tr>
</tbody></table>표 7: 평균 처리량과 응답 시간 (초)의 동시 실행 쿼리 1 분기, 3 분기 및 4 분기 MongoDB NoSQL DBMS. 이 테이블7 크리에이 티브 코몬즈 라이센스 (http://creativecommons.org/ licenses/by/4.0/)를 사용 하 여 수정 된 및 동시에 3 개의 단일 환자 쿼리 및 그들의 평균 응답 시간 가장 높은 평균 처리량을 보여줍니다. MongoDB NoSQL 시스템을 사용 하 여 실행 실험입니다.
보충 그림 1: 스크린샷 MySQL 서버에 연결 하는 소프트웨어 화면을 보여줍니다. <a href="//cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_1.png" target="_blank">이 그림을 다운로드 하려면 여기를 클릭 하십시오.</a>
보충 그림 2: 스크린샷 보여줍니다 SQL 인터페이스 MySQL 서버에 첫 번째 SQL 쿼리 작성 되었습니다. <a href="//cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_2.png" target="_blank">이 그림을 다운로드 하려면 여기를 클릭 하십시오.</a>
보충 그림 3: The MongoDB 2.6 localhost 서버 서버 mongod를 실행 하 여 DOS 시스템 창을 사용 하 여 시작 됩니다. <a href="//cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_3.png" target="_blank">이 그림을 다운로드 하려면 여기를 클릭 하십시오.</a>
보충 그림 4: 스크린샷 단계 5.7.4 통해 5.7.1 에서처럼 쿼리 작성기의 텍스트 상자에 작성 하는 쿼리를 보여 줍니다. 스크린샷 단계를 5.7.3 보여 줍니다. <a href="//cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_4.png" target="_blank">이 그림을 다운로드 하려면 여기를 클릭 하십시오.</a>
보충 그림 5: 스크린샷은 단계 5.7.6. <a href="//cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_5.png" target="_blank">이 그림을 다운로드 하려면 여기를 클릭 하십시오.</a>
보충 그림 6: 화면 캡처 설명 대화 상자의 theupper 부분에 XPath 쿼리 작성. <a href="//cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_6.png" target="_blank">이 그림을 다운로드 하려면 여기를 클릭 하십시오.</a>

Watch this Scientific Journal Video about Executing Complexity-Increasing Queries in Relational MySQL and NoSQL MongoDB and EXist Size-Growing ISO/EN 13606 Standardized EHR Databases at JoVE.com

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

이 연구 비교 관계형 및 비-관계형 (NoSQL) 표준화 의료 정보 시스템. 복잡 한 계산 같은 데이터베이스 관리 시스템 (DBMS)을 쿼리 응답 시간이 배로 크기의 데이터베이스를 사용 하 여 계산 됩니다. 이러한 결과 다른 시나리오와 문제 각 데이터베이스 접근 방법의 적합성의 토론 도움이.

관계형 (MySQL)에 NoSQL 복잡성 증가 하는 쿼리를 실행 (MongoDB 존재) ISO/EN 13606 표준화 EHR 데이터베이스 크기 증가

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

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

Research

Education

JoVE Core

JoVE Journal

Nursing

Medicine

Unit 1

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

Documentation and Reporting

SCIENTISTS IN ACTION

9.2K 조회수.  Health Institute "Carlos III". 이 연구 비교 관계형 및 비-관계형 (NoSQL) 표준화 의료 정보 시스템. 복잡 한 계산 같은 데이터베이스 관리 시스템 (DBMS)을 쿼리 응답 시간이 배로 크기의 데이터베이스를 사용 하 여 계산 됩니다. 이러한 결과 다른 시나리오와 문제 각 데이터베이스 접근 방법의 적합성의 토론 도움이.

비디오: Executing Complexity-Increasing Queries in Relational MySQL and NoSQL MongoDB and EXist Size-Growing ISO/EN 13606 Standardized EHR Databases

Generation of Comprehensive Thoracic Oncology Database - Tool for Translational Research

The Thoracic Oncology Program Database Project was created to serve as a comprehensive, verified, and accessible repository for well-annotated cancer specimens and clinical data to be available to researchers within the Thoracic Oncology Research Program. This database also captures a large volume of genomic and proteomic data obtained from various tumor tissue studies. A team of clinical and basic science researchers, a biostatistician, and a bioinformatics expert was convened to design the database. Variables of interest were clearly defined and their descriptions were written within a standard operating manual to ensure consistency of data annotation. Using a protocol for prospective tissue banking and another protocol for retrospective banking, tumor and normal tissue samples from patients consented to these protocols were collected. Clinical information such as demographics, cancer characterization, and treatment plans for these patients were abstracted and entered into an Access database. Proteomic and genomic data have been included in the database and have been linked to clinical information for patients described within the database. The data from each table were linked using the relationships function in Microsoft Access to allow the database manager to connect clinical and laboratory information during a query. The queried data can then be exported for statistical analysis and hypothesis generation.

A thoracic oncology database was developed to serve as a comprehensive repository for clinical and laboratory data for the purposes of translational research. The database will serve translational cancer researchers within the Thoracic Oncology Research Program. This database is adaptable to other cancer models, as well as other human diseases.

종합 흉부 종양학 데이터베이스의 생성 - Translational 연구 도구

The Thoracic Oncology Program Database Project was created to serve as a comprehensive, verified, and accessible repository for well-annotated cancer ...

연구

의학

A Data Integration Workflow to Identify Drug Combinations Targeting Synthetic Lethal Interactions

A synthetic lethal interaction between two genes is given when knock-out of either one of the two genes does not affect cell viability but knock-out of both synthetic lethal interactors leads to loss of cell viability or cell death. The best studied synthetic lethal interaction is between BRCA1/2 and PARP1, with PARP1 inhibitors being used in clinical practice to treat patients with BRCA1/2 mutated tumors. Large genetic screens in model organisms but also in haploid human cell lines have led to the identification of numerous additional synthetic lethal interaction pairs, all being potential targets of interest in the development of novel tumor therapies. One approach is to therapeutically target genes with a synthetic lethal interactor that is mutated or significantly downregulated in the tumor of interest. A second approach is to formulate drug combinations addressing synthetic lethal interactions. In this article, we outline a data integration workflow to evaluate and identify drug combinations targeting synthetic lethal interactions. We make use of available datasets on synthetic lethal interaction pairs, homology mapping resources, drug-target links from dedicated databases, as well as information on drugs being investigated in clinical trials in the disease area of interest. We further highlight key findings of two recent studies of our group on drug combination assessment in the context of ovarian and breast cancer.

Large genetic screens in model organisms have led to the identification of negative genetic interactions. Here, we describe a data integration workflow using data from genetic screens in model organisms to delineate drug combinations targeting synthetic lethal interactions in cancer.

합성 치명적인 상호 작용을 대상으로 하는 약물 조합을 식별 하기 위해 데이터 통합 워크플로우

A synthetic lethal interaction between two genes is given when knock-out of either one of the two genes does not affect cell viability but knock-out of ...

암 연구학

Implementation of a Real-Time Psychosis Risk Detection and Alerting System Based on Electronic Health Records using CogStack

Recent studies have shown that an automated, lifespan-inclusive, transdiagnostic, and clinically based, individualized risk calculator provides a powerful system for supporting the early detection of individuals at-risk of psychosis at a large scale, by leveraging electronic health records (EHRs). This risk calculator has been externally validated twice and is undergoing feasibility testing for clinical implementation. Integration of this risk calculator in clinical routine should be facilitated by prospective feasibility studies, which are required to address pragmatic challenges, such as missing data, and the usability of this risk calculator in a real-world and routine clinical setting. Here, we present an approach for a prospective implementation of a real-time psychosis risk detection and alerting service in a real-world EHR system. This method leverages the CogStack platform, which is an open-source, lightweight, and distributed information retrieval and text extraction system. The CogStack platform incorporates a set of services that allow for full-text search of clinical data, lifespan-inclusive, real-time calculation of psychosis risk, early risk-alerting to clinicians, and the visual monitoring of patients over time. Our method includes: 1) ingestion and synchronization of data from multiple sources into the CogStack platform, 2) implementation of a risk calculator, whose algorithm was previously developed and validated, for timely computation of a patient&#39;s risk of psychosis, 3) creation of interactive visualizations and dashboards to monitor patients&#39; health status over time, and 4) building automated alerting systems to ensure that clinicians are notified of patients at-risk, so that appropriate actions can be pursued. This is the first ever study that has developed and implemented a similar detection and alerting system in clinical routine for early detection of psychosis.

We demonstrate how to deploy a real-time psychosis risk calculation and alerting system based on CogStack, an information retrieval and extraction platform for electronic health records.

CogStack을 사용하여 전자 건강 기록을 기반으로 실시간 정신병 위험 감지 및 경고 시스템 구현

Recent studies have shown that an automated, lifespan-inclusive, transdiagnostic, and clinically based, individualized risk calculator provides a powerful ...

행동분석학

Databases to Efficiently Manage Medium Sized, Low Velocity, Multidimensional Data in Tissue Engineering

Science relies on increasingly complex data sets for progress, but common data management methods such as spreadsheet programs are inadequate for the growing scale and complexity of this information. While database management systems have the potential to rectify these issues, they are not commonly utilized outside of business and informatics fields. Yet, many research labs already generate "medium sized", low velocity, multi-dimensional data that could greatly benefit from implementing similar systems. In this article, we provide a conceptual overview explaining how databases function and the advantages they provide in tissue engineering applications. Structural fibroblast data from individuals with a lamin A/C mutation was used to illustrate examples within a specific experimental context. Examples include visualizing multidimensional data, linking tables in a relational database structure, mapping a semi-automated data pipeline to convert raw data into structured formats, and explaining the underlying syntax of a query. Outcomes from analyzing the data were used to create plots of various arrangements and significance was demonstrated in cell organization in aligned environments between the positive control of Hutchinson-Gilford progeria, a well-known laminopathy, and all other experimental groups. In comparison to spreadsheets, database methods were enormously time efficient, simple to use once set up, allowed for immediate access of original file locations, and increased data rigor. In response to the National Institutes of Health (NIH) emphasis on experimental rigor, it is likely that many scientific fields will eventually adopt databases as common practice due to their strong capability to effectively organize complex data.

Many researchers generate "medium-sized", low-velocity, and multi-dimensional data, which can be managed more efficiently with databases rather than spreadsheets. Here we provide a conceptual overview of databases including visualizing multi-dimensional data, linking tables in relational database structures, mapping semi-automated data pipelines, and using the database to elucidate data meaning.

조직 공학에서 중간 크기의 저속, 다차원 데이터를 효율적으로 관리하는 데이터베이스

Science relies on increasingly complex data sets for progress, but common data management methods such as spreadsheet programs are inadequate for the ...

생체공학

A Metadata Extraction Approach for Clinical Case Reports to Enable Advanced Understanding of Biomedical Concepts

Clinical case reports (CCRs) are a valuable means of sharing observations and insights in medicine. The form of these documents varies, and their content includes descriptions of numerous, novel disease presentations and treatments. Thus far, the text data within CCRs is largely unstructured, requiring significant human and computational effort to render these data useful for in-depth analysis. In this protocol, we describe methods for identifying metadata corresponding to specific biomedical concepts frequently observed within CCRs. We provide a metadata template as a guide for document annotation, recognizing that imposing structure on CCRs may be pursued by combinations of manual and automated effort. The approach presented here is appropriate for organization of concept-related text from a large literature corpus (e.g., thousands of CCRs) but may be easily adapted to facilitate more focused tasks or small sets of reports. The resulting structured text data includes sufficient semantic context to support a variety of subsequent text analysis workflows: meta-analyses to determine how to maximize CCR detail, epidemiological studies of rare diseases, and the development of models of medical language may all be made more realizable and manageable through the use of structured text data.

We present a protocol and associated metadata template for the extraction of text describing biomedical concepts in clinical case reports. The structured text values produced through this protocol can support deep analysis of thousands of clinical narratives.

있도록 임상 사례 보고서에 대 한 메타 데이터 추출 방법 고급 생물 의학 개념의 이해

Clinical case reports (CCRs) are a valuable means of sharing observations and insights in medicine. The form of these documents varies, and their content ...

Cloud-Based Phrase Mining and Analysis of User-Defined Phrase-Category Association in Biomedical Publications

The rapid accumulation of biomedical textual data has far exceeded the human capacity of manual curation and analysis, necessitating novel text-mining tools to extract biological insights from large volumes of scientific reports. The Context-aware Semantic Online Analytical Processing (CaseOLAP) pipeline, developed in 2016, successfully quantifies user-defined phrase-category relationships through the analysis of textual data. CaseOLAP has many biomedical applications.
We have developed a protocol for a cloud-based environment supporting the end-to-end phrase-mining and analyses platform. Our protocol includes data preprocessing (e.g., downloading, extraction, and parsing text documents), indexing and searching with Elasticsearch, creating a functional document structure called Text-Cube, and quantifying phrase-category relationships using the core CaseOLAP algorithm.
Our data preprocessing generates key-value mappings for all documents involved. The preprocessed data is indexed to carry out a search of documents including entities, which further facilitates the Text-Cube creation and CaseOLAP score calculation. The obtained raw CaseOLAP scores are interpreted using a series of integrative analyses, including dimensionality reduction, clustering, temporal, and geographical analyses. Additionally, the CaseOLAP scores are used to create a graphical database, which enables semantic mapping of the documents.
CaseOLAP defines phrase-category relationships in an accurate (identifies relationships), consistent (highly reproducible), and efficient manner (processes 100,000 words/sec). Following this protocol, users can access a cloud-computing environment to support their own configurations and applications of CaseOLAP. This platform offers enhanced accessibility and empowers the biomedical community with phrase-mining tools for widespread biomedical research applications.

We present a protocol and associated programming code as well as metadata samples to support a cloud-based automated identification of phrases-category association representing unique concepts in user selected knowledge domain in biomedical literature. The phrase-category association quantified by this protocol can facilitate in depth analysis in the selected knowledge domain.

클라우드 기반 구문 마이닝 및 생물 의학 간행물에 사용자 정의 구문 범주 협회의 분석

The rapid accumulation of biomedical textual data has far exceeded the human capacity of manual curation and analysis, necessitating novel text-mining ...

TBase - an Integrated Electronic Health Record and Research Database for Kidney Transplant Recipients

TBase is an electronic health record (EHR) for kidney transplant recipients (KTR) combining automated data entry of key clinical data (e.g., laboratory values, medical reports, radiology and pathology data) via standardized interfaces with manual data entry during routine treatment (e.g., clinical notes, medication list, and transplantation data). By this means, a comprehensive database for KTR is created with benefits for routine clinical care and research. It enables both easy everyday clinical use and quick access for research questions with highest data quality. This is achieved by the concept of data validation in clinical routine in which clinical users and patients have to rely on correct data for treatment and medication plans and thereby validate and correct the clinical data in their daily practice. This EHR is tailored for the needs of transplant outpatient care and proved its clinical utility for more than 20 years at Charit&#233; - Universit&#228;tsmedizin Berlin. It facilitates efficient routine work with well-structured, comprehensive long-term data and allows their easy use for clinical research. To this point, its functionality covers automated transmission of routine data via standardized interfaces from different hospital information systems, availability of transplant-specific data, a medication list with an integrated check for drug-drug interactions, and semi-automated generation of medical reports among others. Key elements of the latest reengineering are a robust privacy-by-design concept, modularity, and hence portability into other clinical contexts as well as usability and platform independence enabled by HTML5 (Hypertext Markup Language) based responsive web design. This allows fast and easy scalability into other disease areas and other university hospitals. The comprehensive long-term datasets are the basis for the investigation of Machine Learning algorithms, and the modular structure allows to rapidly implement these into clinical care. Patient reported data and telemedicine services are integrated into TBase in order to meet future needs of the patients. These novel features aim to improve clinical care as well as to create new research options and therapeutic interventions.

TBase combines an electronic health record with an innovative research database for kidney transplant recipients. TBase is built upon an in-memory database platform, connected to different hospital systems, and used for regular outpatient care. It automatically integrates all relevant clinical data including transplantation-specific data creating a unique research database.

TBase is an electronic health record (EHR) for kidney transplant recipients (KTR) combining automated data entry of key clinical data (e.g., laboratory ...

Clinical Application of Artificial Intelligence Preoperative Planning System Combined with Expert Database Retrieval in Complex Revision Hip Surgery

Accurate preoperative planning in revision hip arthroplasty is crucial for achieving successful outcomes. To enhance the intuitive evaluation of acetabular bone defect severity and leverage previous successful experience in revision hip arthroplasty, this study proposes a novel approach based on expert surgical case database retrieval and is initially implemented in clinical application.&#160;In this study, five patients who required revision hip arthroplasty were preoperatively planned to employ the expert case database surgical planning system.The patient&#39;s imaging data was entered into the system and matched with cases in the expert case database. Based on the expert&#39;s surgical experience, a revision surgery plan was recommended. If no suitable case was found, the model and position of the prosthesis were planned based on patient-specific reconstruction results. A total of five patients were enrolled in this study, four males and one female, with a mean age of 50.6 years. The diagnosis was aseptic prosthesis loosening after hip arthroplasty. The mean operative time was 123.2 min, and the mean intraoperative hemorrhage was 672 mL. No intraoperative complications, such as vascular or nerve injury, were observed. In Case 2, for instance, the application of this innovative planning scheme enabled the surgeon to delineate the revision surgery plan for this patient in the preoperative period, thereby reducing the operative time and intraoperative hemorrhage. Furthermore, patients could be apprised of the outcomes of analogous cases in advance. Leveraging a big data analysis approach through our comprehensive case database enables automated identification of matching expert treatment plans throughout the entire process. This particularly benefits inexperienced orthopedic surgeons by providing accurate guidance on surgical strategies to assist them in selecting appropriate prosthetic sizes and mounting positions. Additionally, the matching results can offer patients visualizations depicting predicted postoperative outcomes.

This study proposes a novel artificial intelligence preoperative planning approach based on expert surgical case database retrieval in revision hip arthroplasty. Additionally, the technique was initially employed in five patients, exhibiting a reduction in operative time and intraoperative hemorrhage.

복잡한 고관절 재수술에서 전문가 데이터베이스 검색과 결합된 인공 지능 수술 전 계획 시스템의 임상 적용

Accurate preoperative planning in revision hip arthroplasty is crucial for achieving successful outcomes. To enhance the intuitive evaluation of ...

Methods of Documentation VII: EMR

Electronic Medical Records (EMRs) primarily center around electronically documenting patients&#39; health information within a single healthcare organization or practice. They contain essential clinical data related to a patient&#39;s medical history, diagnoses, medications, treatment plans, lab results, and other pertinent information relevant to the specific encounter or episode of care. EMRs are designed to streamline documentation and workflow processes within individual healthcare settings, facilitating the delivery of patient care within that organization.
Electronic Health Records (EHRs)&#160; encompass a broader scope of patient health information, extending beyond the confines of a single healthcare organization or encounter. They integrate data from multiple sources and care settings, including medical histories from various providers, lab results from different laboratories, imaging reports, pharmacy records, insurance claims data, and patient-generated health information. EHRs provide a longitudinal view of a patient&#39;s health history, facilitating continuity of care, care coordination across different providers and settings, and comprehensive clinical decision-making.
Characteristics of EMR or EHRs:
<ul>
	<li>&#8226; They consist of structured collections of patients&#39; digital medical records originating from electronic formats or converted from paper records.</li>
	<li>&#8226;&#160;The information is digitally stored in electronic records. It can be easily distributed to healthcare providers in standardized formats, enabling efficient comparison and assessment of patient progress.</li>
	<li>&#8226;&#160;Healthcare facilities use standardized assessment tools like the minimal data set to systematically organize and document patient information.</li>
	<li>&#8226;&#160;The minimal data set typically includes nursing care components (e.g., diagnoses, interventions), patient demographic information (e.g., gender, date of birth), and service components (e.g., admission, discharge dates).</li>
</ul>
Critical Benefits of EMRs to Nurses:
<ul>
	<li>&#8226;&#160;EMRs offer several benefits to nurses, including the ability to compare ongoing clinical data with baseline data, maintain detailed patient logs, and quickly access patient records.</li>
	<li>&#8226;&#160;They facilitate legible, accurate, up-to-date, and complete documentation about patients, improving efficiency and quality of care delivery.</li>
</ul>