데이터 타입 선정 원칙, 절차

 

타입을 선택하는 건 모델링 과정에서 중요한 부분입니다. 적합하지 않은 타입은 데이터 무결성 손상에 원인이 될 수 있으며 저장 공간을 많이 차지하고 성능 저하에 영향을 줄 수 있습니다. 

 

데이터 타입 선정 원칙

타입을 결정하는데 가장 중요한 원칙은 저장될 데이터 성격에 맞는 타입을 결정하는 것입니다. 속성에 저장될 데이터가 어떤 종류의 데이터인지 모르고는 데이터 타입을 결정할 수 없습니다. 데이터 성격을 명확히 파악하고 규정하는 것은 모델러에게 중요한 역할입니다.

속성 데이터가 날짜면 Date 타입을, 숫자면 Nuber 타입을 문자면 Varchar2 타입을 사용하는 것이 기본 원칙입니다. (Oracle 10g 기준)

 

속성에 저장될 데이터가 숫장임에도 Varchar2 타입으로 설정해 사용하면 숫자 0을 뜻하는데 알파벳 o가 들어갈 수 있으며 제로와 같은 데이터가 들어갈 수 있습니다. 

 

저장될 데이터가 날짜임에도 Varchar2 타입을 사용하면 2024년 1월 1일 같은 날짜가 입력될 수 있습니다. 어플리케이션 유효성 체크에서도 잘못된 데이터느 수도 없이 만나게 됩니다. 어떠한 이유든 데이터 무결성이 깨지게 돼어 DBMS에서 정확한 데이터 타입을 지정해 무결성을 지켜야 합니다.

 

데이터 무결성은 99.9999%도 부족하다. 가입일자 속성에 천만 건의 데이터가 있다.

천만 건 모두가 가입일자를 의미해야 한다. 0000년 00월 00일 과 같이 실제 날짜를 의미하지 않는 데이터가 한 건이라도 존재하지 않도록 해야한다. 

 

 

데이터 타입 선정 절차

우선 판단사항은 문자 타입인지 숫자 타입인지 결정하는 것이다. 판단은 비교적 간단하다. 

성격은 숫자지만 종류가 한정돼 있다면 문자 타입으로 결정하는 것이 좋다.

예를 들어 고객 등급이 1등급 부터 5등급까지 있다. 숫자 타입으로 사용하는 것보다 01, 02 등으로 코드로 변환해서 사용하는 것이 효율적이다. 코드값의 데이터 타입은 보통 문자 타입으로 사용하게 된다.

 

문자 타입으로 결정했다면 고정 길이인지 가변 길이인지 판단하게 된다. 고정 길이라고 판별되더라도 시렞 Char 타입을 사용하는 예는 드물다. 이는 Char 타입의 특성 때문으로 조회에 사용할 때 큰 문제가 될 수 있다.

무엇보다 Varchar2 타입에 비해 뚜렷한 장점은 없다. Char 타입을 사용하지 않아도 데이터가 고정 길이인지 판별할 필요성은 있다. 식별자일 때 반드시 검토해야 한다.

 

가변 기이라면 최대 길이를 결정하게 된다. Varchar2 타입은 가변이어서 최대 길이를 충분히 잡을 때가 많은데 가능한 근접하게 정하는 것이 좋습니다. 최대 길이 역시 데이터 성격을 나타내는 하나의 요소이므로 의미 없이 크게 잡는 것은 바람직하지 않습니다.

 

타입 길이에 따라 도메인이 정해지는데 도메인을 얼마나 세분화해서 관리하냐에 따라 최대 길이를 비교적 정확히 결정하기도 하고 다소 크게 결정하기도 합니다.

 

최대 길이가 4000~5000 정도로 매우 길어야 하면 Clob 등의 타입을 사용할 수도 있으며 속성을 물리적으로 분리해야 할 수도 있습니다.

문자 형식이긴 하지만 이미지나 문서 등의 파일을 관리하는 속성은 Blob등을 사용해야 합니다.

 

데이터 타입에 대해 잘못 생각하는 부분은 데이터 타입을 결정하는 시기입니다. 보통 모델링 초반 단계나 상세 논리 모델링 단계까지 데이터 타입이 결정되지 않아야 한다고 생각하는 사람이 많습니다.

 

 

Char/Varchar2 타입

속성에 저장될 데이터가 문자이며 고정 길이라면 Char 타입을 사용하고 가변길이면 Varchar2 타입을 사용하는 것이 원칙입니다. Char 타입을 사용할 때는 거의 없습니다. 예를 들어 부서 코드 속성에는 4자리의 문자만 사용돼야 한다는 규칙이 있다면 Char(4) 타입을 사용해야 합니다. 하지만 Char 타입을 사용하지 않는 이유는 Varchar2 타입에 비해 뛰어난 장점은 없는 대신 불편함이 존재하기 때문입니다.

 

만약 부서코드에 3자리 값이 들어간다면 블랭크가 입력된다. Char 타입을 사용한 속성에 한 byte라도 값이 들어가면 내부에서 길이가 확정되면서 블랭크가 사용됩니다. 이때 블랭크를 고려한 조회를 해야할 수도 있습니다.

 

최대 길이를 실제 공간으로 사용하지 않지만 어플리케이션 공간으로 할당해 사용하기도 합니다.

 

모델링 일정이 짧다면 Varchar2 타입 속성의 최대 길이를 정확하게 분석하는게 쉽지 않다. 최대 길이도 일종의 제약이며 데이터 품질을 향상시키는 요소로 세심한 분석이 필요하지만 여의치 않는다면 충분히 큰 값을 지정할 수도 있습니다.

 

Number 타입

속성에 관리할 데이터가 숫자일 때 Number 타입을 사용합니다. 숫자임에도 Varchar2 타입을 사용하는 경우는 거의 없습니다.

Number 타입은 원칙적으로 전체 자릿수와 소수점 자릿를 지정해서 Number(15,3)과 같이 사용해야 합니다.

전체 자릿수와 소수점 자릿수도 일종의 제약으로 제약이 많으면 관리는 어렵지만 데이터 품질은 높일 수 있습니다.

 

Number(7) 타입에 소수를 저장하면 12,345.67 Number(7,0)을 의미하므로 12345로 저장되고 (7,2) 타입에 저장하면 12345.67로 저장됩니다.

 

고객 번호와 같은 주 식별자는 고정 길이라 Number타입을 사용할 때는 100000001과 같이 1로 시작하도록 해서 고정 길이를 만들어줘야 합니다. 만약 00000001로 저장하면 1 데이터로 저장돼 고정길이가 되지 않습니다.

 

Date 타입

일시나 일자를 나타내는 날짜일 때는 Date 타입을 사용해야 합니다. 하지만 당연한 원칙이 지켜지지 않는 경우가 많습니다.

예를들어 2024년 1월 1일 과 같은 날짜를 저장할때 Varchar2(8) 타입을 사용하는 예가 많습니다.

 

Date 타입을 사용해야 하는 가장 큰 이유는 데이터 정합성 입니다.

날짜 데이터라는 것을 보장해야 합니다. 어플리케이션 체크에서도 날자가 아닌 데이터가 존재할 수 있어 문제가 될 수 있기에 정합성을 최우선으로 선택해야합니다.

 

Date 타입은 물리적으로 7바이트를 차지합니다. 반면 Varchar2 타입을 사용하면 8바이트가 필요해 저장 성능 면에서도 도움을 줍니다.

날짜 데이터를 저장하는 속성은 전체 시스템에 많이 존재하므로 1byte의 차이라도 모이면 커지게 된다.

 

Date 타입을 사용하면 옵티마이저에 대한 정확한 판단 정보를 제공하게 됩니다. 예를들어 2024년 1월 1일과 2024년 1월 31일 사이 데이터 조회시 옵티마이저는 하루 차이라는 것을 인식하고 그에 맞는 플랜을 생성하게 됩니다.

 

하지만 Varchar2(8) 타입을 사용하면 20240101과 20240131 사이를 한달로 인식하지 못하고 많은 값이 존재한다고 생각해 최적의 플랫을 생성하지 못할 수 있습니다. 옵티마이저가 정확히 판단하지 못해 인덱스 범위 스캔이 발생하지 않고 테이블 풀 스캔이 발생할 수 있습니다.

 

CLOB, BLOB

대량의 문자 데이터를 저장하려면 Clob 타입을 사용합니다. Clob 타입은 최대 4Gbyte까지 저장할 수 있습니다.

이미지, 문서 파일과 같은 이진 바이너리 파일을 저장하려면 Blob 타입을 사용해야 합니다.

Blob 타입도 최대 4Gbyte까지 정할 수 있습니다.