이번 포스팅에서는
헬스케어 데이터를 데이터베이스로 옮기는 과정과 ERD 다이어그램,
개체(Entity), 속성(Attribute), 관계(Relationship)에 대해 알아보겠습니다.
데이터 엔지니어링 및 헬스케어 데이터의 특징
데이터 엔지니어링이란
데이터의 수집, 저장, 처리, 분석을 위한 데이터 파이프라인을 설계하고 관리하는 분야 입니다.
데이터 엔제니어는 데이터의 출처, 저장 방식, 효율적인 활용 방법을 설계합니다.
처음부터 끝까지 관리하는 모든 과정을 설계하는 일이라고 생각하면 쉽습니다.
예를 들어
환자의 정보를 받으면 (수집)
-> 이 정보를 어디에 저장하고 (저장)
-> 나중에 분석하기 좋게 정리하며 (처리)
-> 최종적으로 의료 연구에 사용할 수 있도록 준비하는 (분석)
모든 단계를 만드는 겁니다.
데이터 엔지니어는 데이터가 잘 흘러갈 수 있도록 물길(파이프라인)을 만드는 사람이라고 생각하면 됩니다.
데이터를 저장하는 방법
| 구분 | 예시 | 설명 |
| 로컬 파일 | 엑셀, CSV | 정형화된 표 형태로 데이터 저장 |
| RDBMS | MySQL, PostgreSQL | SQL 기반, 테이블 간 관계로 데이터 관리 |
| NoSQL | MongoDB, Redis | 문서형/키-값 등 비정형 데이터 처리 |
| Data Warehouse | BigQuery, Snowflake | 대용량 데이터 분석용 시스템 |
| Data Lake | AWS S3, Hadoop | 다양한 형식의 원시 데이터 저장 |
흔히 쓰는 엑셀은 컴퓨터에 저장하는 작은 파일처럼 데이터를 표 형태로 저장하는 방식입니다.
그러나 병원처럼 방대한 량의 데이터를 다룰 때에는
엑셀만으로는 부족하기 때문에 등장한 것이 EDBMS나 NoSQL 같은 전문적인 데이터베이스 시스템입니다.
더 예시를 들어보자면
• RDBMS(관계형 데이터베이스):
잘 정리된 여러개의 엑셀 시트(테이블)들을 서로 연결해서 사용하는 것과 같습니다.
'환자 정보 시트', '진료 기록 시트' 를 환자 ID 로 연결해서 관리하는 식으로,
이렇게 이용할 경우 데이터가 꼬일 일이 적고 정확하게 관리할 수 있습니다.
• NoSQL:
엑셀 시트처럼 정해진 형식이 아닌 자유로운 형태로 데이터를 저장합니다.
사진이나 의사의 소견서처럼 형태가 다양하고 빠르게 변하는 데이터를 저장할 때 유용합니다.
• Data Warehouse:
수많은 데이터를 모아놓고 분석하기 좋게 잘 정리해둔 창고입니다.
큰 그림을 보고 미래를 예측할 때 사용할 수 있습니다.
• Data Lake:
모든 종류의 데이터를 일단 다 모아두는 거대한 저수지 같은 곳입니다.
정제되지 않은 날 것의 데이터(원시 데이터)까지 모두 저장했다가 필요할 때 꺼내 씁니다.
데이터 엔지니어는 이 다양한 저장소를 연결해서 데이터가 끊임없이 흐를 수 있도록 만드는 역할을 합니다! 👍🏻
헬스케어/의료 데이터의 특징
1. 정형데이터 + 비정형데이터
정형데이터는 환자 ID, 혈압, 혈당, 진료 날짜 등 숫자나 표로 정리된 데이터이고,
비정형데이터는 엑스레이, MRI이미지, 의사 소견서, 음성 기록 등 형식이 일정하지 않은 데이터입니다.
의료 DB는 이 두 가지를 모두 저장할 수 있어야 합니다.
2. 보안과 개인정보 보호가 최우선
환자 정보(이름, 주민번호, 진단 기록 등) 민감 데이터는 암호화, 접근권한 관리, 로그 기록, 익명화가 필수입니다.
의료법, 개인정보보호법 등 법적 규제를 준수해야 합니다.
3. 정확성과 일관성 (무결성) 중요
진료기록의 오타나 중복은 생명에 영향을 줄 수 있는 문제이기 때문에 **관계형 DB(RDB)** 를 주로 사용합니다.
테이블을 나누고 뒤에 나올 외래키(Foreign Key)로 연결하여 데이터의 무결성을 보장합니다.
4. 대용량 + 장기 저장 필요
의료 데이터는 평생 보관해야할 필요성이 있으므로 수백 GB~TB 단위의 대용량 저장이 필요하며
확장성 있는 클라우드 및 분산 저장 시스템이 요구됩니다.
5. 분석과 AI 학습용으로 활용
진단 자동화, 질병 예측, 맞춤형 치료 등에 활용되지만 AI 학습 전 익명화(De-identification)이 필수입니다.
일반 상업용 DB보다 데이터 품질 및 표준화가 더욱 중요합니다.
데이터베이스 개요 및 종류
데이터와 정보를 알아보겠습니다.
• 데이터 (Data):
현실 세계에서 수집된 단순한 사실과 값들의 모음. (예: 10월 매출 1,000만원)
• 정보 (Information):
데이터를 특정 목적에 의해 해석하거나 가공한 형태. (예: 10월 매출 1,000만원은 작년 대비 20% 증가한 수치)
• 데이터베이스: 데이터를 모아 효율적으로 관리하는 시스템
파일처리 시스템의 한계
옛날에는 데이터를 단순 파일로 저장했습니다.
예를 들어 환자 정보를 엑셀 파일로 저장하고, 진료기록을 또 다른 엑셀파일로 저장하는 방식이었는데
이러한 파일처리 시스템은 몇가지 문제가 있습니다.
• 데이터 종속 문제: 데이터 구조가 변경되면 응용 프로그램도 수정
• 데이터 중복 문제: 프로그램마다 데이터를 따로 만들어 중복이 발생
• 무결성 유지 어려움: 데이터가 정확하고 일관되게 유지되기 어려움
이런 문제들을 해결하기 위해 나온 것이 바로 데이터베이스 시스템 입니다.
데이터베이스 종류
| 종류 | 설명 | 예시 |
| RDB (Relational Database) |
관계형 모델 기반으로 SQL을 이용해 데이터 관리, 테이블 간 관계 설정 | MySQL, PostgreSQL, MariaDB |
| NoSQL (Not Only SQL) |
데이터 간 관계를 정의하지 않고 유연한 구조 사용 | MongoDB, Redis, Firebase |
관계형 데이터베이스는 가장 흔히 쓰이는 방식으로, 데이터를 표(테이블) 형태로 저장한 후
이 표들 사이의 관계를 명확하게 정의해서 관리합니다. 덕분에 데이터는 정확하고 일관되게 유지될 수 있습니다.
대신 표의 형태가 정해져 있기 때문에 새로운 종류의 데이터를 추가하기가 번거로울 때가 있습니다.
은행 고객 정보처럼 규칙적이고 중요한 데이터를 다룰 때 많이 사용 됩니다.
비관계형 데이터베이스는 RDB와 달리 정해진 표 형태가 아닌 좀 더 자유로운 방식으로 데이터를 저장합니다.
마치 여러 가지 상자에 다양한 물건을 넣는 것과 같다고 생각할 수 있습니다.
텍스트, 이미지, 동영상 등 온갖 형태의 데이터를 빠르게 저장하고 처리할 수 있기 때문에
SNS 피드나 실시간 로그 데이터처럼 끊임없이 변하고 양이 많은 데이터를 다룰 때 아주 유용합니다.
어떤 DB를 쓸지는 데이터의 구조가 명확한지 아니면 빠른 환작성과 유연성이 필요한지에 따라 달라집니다. 😎
관계형 데이터베이스 구성 요소 및 무결성
관계형 데이터베이스 구성 요소
| 구성요소 | 설명 | |
| 테이블(Table) | 행과 열로 구성된 데이터 저장 구조 | 가장 기본적인 표. 예: '환자'테이블, '의사'테이블 |
| 속성(Attribute) | 데이터의 특성을 나타내는 가장 작은 단위(Column) | 테이블의 열. 예: 환자테이블에서 '환자ID', '이름', '생년월일' |
| 튜플(Tuple) | 속성이 모여 구성된 하나의 행(Row) | 테이블의 행. 예: 환자테이블에서 '한 명의 환자에 대한 모든 정보' |
| 도메인(Domain) | 속성이 가질 수 있는 값의 범위 | 값의 범위나 유형. 예: '나이' 속성의 도메인은 0에서 150 사이의 정수. '성별' 속성의 도메인은 남 혹은 여. |
키 (Key)
키는 테이블에서 특정 튜플을 유일하게 식별하거나,
테이블 간의 관계를 정의하는데 사용되는 하나 또는 여러 속성의 집합입니다.
• 기본키 (Primary Key, PK)
- 테이블 내에서 각 튜플을 유일하게 식별할 수 있는 속성
- 중복되는 값을 가질 수 없음, Null 값을 가질 수 없음.
- 테이블 당 오직 1개만 설정할 수 있음 (예: patient_id)
• 외래키 (Foreign Key, FK)
- 다른 테이블의 기본키를 참조하는 속성
- 테이블 간의 관계를 정의
(예: '예약'테이블의 환자ID는 '환자'테이블의 환자ID(기본키)를 참조하는 외래키.
이런식으로 외래 키를 사용하면 '예약'정보만 보고도 어떤 환자의 예약인지 알 수 있게 연결해주는 것.
마치 건물의 문은 여러개여도 특정 열쇠로 특정 문만 열 수 있는 것과 같음!)
• 후보키 (Candidate Key)
- 기본키가 될 수 있는 키. 유일성과 최소성을 만족하는 속성들의 집합. (기본키는 후보키의 일종)
• 대체키 (Alternate Key)
- 후보키 중에서 기본키로 선택되지 않은 키
• 슈퍼키 (Super Key)
- 튜플을 유일하게 식별할 수 있는 유일성은 만족하지만 최소성은 만족하지 않는 키.
* 유일성(Uniqueness)과 최소성(Minimality)
• 유일성: '구별할 수 있는 능력'
특정 키 값이 한 테이블 내에 오직 하나의 행만을 가리켜야 합니다. 즉, 중복되는 값이 없어야 합니다.
예를 들어 주민등록번호나 학번은 각 개인을 유힐하게 식별할 수 있으므로 유일성을 만족합니다.
똑같은 주민등록번호를 가진 사람이 둘 이상 있을 수 없습니다.
• 최소성: '가장 간결한 구별 능력'
어떤 속성들의 집합이 유일성을 만족할 때 그 속성들 중에 어떤 속성 하나라도 제거하면 유일성이 깨지는 경우에
최소성을 만족한다고 합니다. 즉, 행을 식별하는데 필요한 최소한의 속성들로만 구성되어야 한다는 뜻입니다.
예를 들어 (학번, 이름) 으로 학생을 유일하게 식별할 수 있다고 한다면
여기서 (이름) 을 빼고 (학번) 만으로도 학생을 유일하게 식별할 수 있습니다.
이 경우에 (학번, 이름)은 유일성은 만족하지만 학번만으로도 가능하므로 최소성은 만족하지 않습니다.
(학번) 하나만으로도 학생을 유일하게 식별할 수 있다면 (학번)은 유일성과 최소성을 모두 만족합니다.
최소성을 만족해야 불필요한 속성 없이 가장 효율적으로 데이터를 식별할 수 있습니다! ✔️
무결성 제약 조건
데이터의 정확성과 일관성을 유지하기 위한 규칙들을 알아보겠습니다.
• 개체 무결성 (Entity Integrity): 기본키는 Null 값, 중복된 값을 가질 수 없음.
• 참조 무결성 (Referential Integrity): 외래키는 Null 이거나, 참조되는 릴레이션(테이블)의 기본키 값과 동일해야 함.
• 도메인 무결성 (Domain Integrity): 특정 속성값은 그 속성이 정의된 도메인(값의 범위)에 속한 값 이어야 함.
• NULL 무결성 (NULL Integrity): 특정 속성은 NULL(비어있음) 상태를 허용하지 않음.
• 고유 무결성(Unique Integrity): 특정 속성(예: 이메일, 주민 번호)은 중복될 수 없음.
• 키 무결성 (Key Integrity): 테이블에는 최소 한 개 이상의 **키(튜플을 구분할 기준)**가 존재해야 함.
데이터 모델링 및 ERD
데이터 모델링
현실 세계의 데이터를 데이터베이스로 체계적으로 표현하는 과정입니다.
이 과정을 거쳐야 현실의 복잡한 정보가 데이터베이스 안에서 질서 정연하게 관리될 수 있습니다.
• 개념적 설계: 현실 세계를 개념으로 표현 (예: '환자', '진료', '처방' 등 개체로 정의)
• 논리적 설계: DBMS가 이해할 수 있는 구조 설계 (예: 테이블 간 관계(FK) 정의)
• 물리적 설계: 실제 저장 구조 설계 (예: MySQL에서 각 테이블 생성)
ER 다이어그램 (ERD)
Entiti-Relationship Diagram (개체-관계 다이어그램)
현실 세계의 데이터와 관계를 시각적으로 표현한 그림입니다.
피터 첸 표기법, 바커 표기법, IE 표기법등이 있는데 이 중 E-R 모델을 제안한 피터 첸의 표기법이 교재등에서 주로 쓰이고,
실무에서는 바커 표기법, IE 표기법 등이 쓰인다고 합니다.
• 개체 (Entity): 데이터로 표현할 대상 (직사각형)
• 속성 (Attribute): 개체의 구체적 정보 (타원형)
• 관계 (Relationship): 개체 간의 연관성 (마름모)
관계의 종류
개체들 사이의 관계는 다양한 유형으로 나눌 수 있습니다.
| 관계 | 설명 | 예시 |
| 1 : 1 | 한 개체가 다른 한 개체와 하나씩만 연결 | 딱 한번만 연결되는 관계. (예: 한 사람 당 한 개의 주민등록번호) |
| 1 : N | 한 개체가 여러 다른 개체와 연결 | 환자(1) : 진료(N) (한 명의 환자는 여러번의 진료를 받을 수 있음) |
| N : M | 여러 개체가 여러 다른 개체와 연결 | 의사(N) : 환자(M) (여러 명의 의사가 여러 명의 환자를 진료할 수 있음) |
보통 N:M 관계는 데이터베이스에서 직접 표현이 어렵기 때문에 중간 테이블을 만들어서 1:N 관계로 풀어줍니다.
예를 들어
'의사'와 '환자' 사이의 관계에 '진료' 라는 중간 테이블을 만들어
의사(1) ㅡ 진료(N) / 환자 (1) ㅡ 진료 (N) 이런식으로 풀어줄 수 있습니다.
까마귀발 표기법 (Crow's Foot Notation)
IE 표기법이라고도 하는 까마귀발 표기법은
두 개체(테이블)가 어떤 관계로 연결되어 있는지 그림으로 쉽게 보여주는 방법입니다.
마치 새 발자국처럼 생겼다고 해서 이런 이름이 붙었습니다.
• 하나: 직선 하나
• 제로 또는 하나: 원과 직선
• 하나 또는 그 이상 (N): 직선과 까마귀발
• 제로 또는 그 이상 (N): 원과 까마귀발
배운 것을 종합하여 draw.io 사이트를 이용해 직접 ER 다이어그램을 그려보겠습니다.
예시로 환자-의사-진료 구조를 설계해보자면 아래와 같이 그려볼 수 있습니다.
