4. 테이블 타입과 스키마 설계

이 장에서는 저장할 데이터의 의미와 변경·조회 요구사항을 Machbase DBMS의 테이블과 컬럼으로 구체화합니다. 데이터베이스가 실행되는 것을 확인했다면, 이제 무엇을 한 행으로 저장할지부터 정합니다. 익숙한 테이블 유형을 먼저 고른 뒤 모든 데이터를 거기에 맞추면 시간 이력, 수정 범위와 보관 정책이 서로 충돌할 수 있습니다.

각 테이블 타입의 역할을 처음 접한다면 데이터 모델 개념을 먼저 읽으십시오. 이 장에서는 그 개념을 실제 스키마와 검증 가능한 설계로 연결합니다.

설계의 출발점

테이블 이름보다 먼저 한 행의 의미를 문장으로 적습니다. 예를 들어 “센서 하나의 측정값 한 건”, “설비 상태가 바뀐 사건 한 건”, “장비 하나의 현재 설치 정보”는 서로 다른 행의 단위입니다. 같은 설비에서 발생한 데이터라도 저장 역할이 다릅니다.

다음 질문에 답하면 테이블을 선택할 근거가 생깁니다.

데이터 크기나 입력 빈도 하나만으로 타입을 결정하지 않습니다. 한 행에 모은 값들이 같은 관측이나 사건을 설명하는지 확인하고, 연결이 필요한 데이터는 공통 식별자로 조인할 수 있게 설계합니다. 조인 가능한 키가 있다는 사실과 DBMS가 모든 업무 관계를 자동으로 강제한다는 뜻도 구분합니다. 지원 제약 조건은 테이블별로 확인합니다.

이 장의 구성

4.1에서 타입을 선택하고 4.2와 4.3에서 구조와 변경 정책을 정합니다. 이어서 4.4의 안티패턴을 점검하고 4.5의 패턴을 자신의 데이터에 맞게 적용합니다. 표의 비교 결과는 출발점이며 실제 SQL과 지원 조건은 연결된 테이블별 문서와 레퍼런스에서 확인합니다.

설비 모니터링을 예로 생각하기

온도, 알람, 장비 정보와 화면용 상태를 모두 같은 방식으로 저장할 필요는 없습니다.

이 표는 예시이지 고정된 정답은 아닙니다. 이벤트에 여러 측정 항목이 함께 들어오거나 수정·보관 요구가 다르면 다른 설계가 적합할 수 있습니다. TRANSACTION은 Standard Edition 지원 여부도 함께 확인합니다.

온도 이력에 최신 장비 정보를 조인하면 결과는 현재 위치와 이름으로 해석됩니다. 측정 당시 위치나 허용 기준이 필요하면 그 정보를 원본에 남기거나 기준 정보의 변경 이력을 설계해야 합니다. 현재 상태 캐시를 함께 갱신하는 경우에도 원본 입력과 캐시 갱신이 한 트랜잭션이라고 가정하지 말고, 실패 후 캐시를 다시 만들 방법을 준비합니다.

작은 데이터로 설계 검증하기

운영 규모로 늘리기 전에 대표 데이터와 자주 쓰는 쿼리로 다음을 확인합니다.

1. 정상값뿐 아니라 NULL, 누락, 경계값과 중복·지연 도착 데이터를 입력합니다.
2. 원본 조회와 집계 결과가 같은 시간 기준·단위·NULL 정책을 사용하는지 확인합니다.
3. 보정·삭제·재입력 후 결과를 비교하고 다른 행이나 관련 집계에 미치는 영향을 확인합니다.
4. 재시작 시 보존돼야 할 데이터와 다시 생성해야 할 상태를 구분해 복구 순서를 점검합니다.
5. 입력량·조회 범위·동시성을 늘려 처리량, 지연과 저장 공간을 측정합니다.

입력 오류, 오래된 스키마를 사용하는 애플리케이션과 재시작 복구는 정상 경로와 함께 설계할 대상입니다. 스키마를 변경할 때는 기존 데이터와 뷰·롤업·클라이언트의 의존성을 확인하고, 필요하면 새 테이블로 옮겨 검증한 뒤 전환합니다.

구현은 테이블별 활용 장과 개발 및 애플리케이션 연동으로, 측정은 성능 튜닝으로 이어집니다.