여부 컬럼의 개요/표준

여부 칼럼 #1: 개요/표준

데이터 모델을 작성시 많이 나타나는 속성 중에 하나가 여부속성 즉 여부컬럼이다.
여부 컬럼은 테이블상에 보통 _YN, _FLAG 로 끝나는 컬럼이다.
모델링을 할 때 마다 여부 컬럼을 어떻게 구현할까 항상 고민 거리가 되는 부분이다.
심한 경우 한 테이블에 여부 컬럼이 백여 개 이상인 것들도 존재 한다.
상황에 따라 모델 구성이 제 각각으로 이루어 질 수 있다고 하지만, 가만히 그 내부를 살펴보면 몇 가지 규칙및 패턴이 있을 것이다.
이제 모델링 프로젝트에 투입시에 매번 똑 같은 고민을 하지 말고 패턴을 잘 적용하여 좀 더 알차게 적용해 보자.

여부 컬럼 예시

 

여부 컬럼들은 주로 핵심 혹은 메인 테이블에서 발생하곤 한다.

어떤 여부 컬럼들이 있을까 한번 나열해 볼까.
아래는 상품 테이블 에서 봄직 한 속성들이다.

사용여부 / 특별상품여부 / 대표상품여부 / 주문불가여부 / 판매여부 / 품절여부 / 재판매제한여부
설치상품여부 / 가격노출여부 / 비교가격표시여부 / 무료판매여부 /적립금제한여부 / 할인금적용여부
일시불할인제한여부 / 즉시적립금할인제한여부 / 방송자동적립금제한여부 / 프로모션제한여부
쿠폰할인액노출여부 / 포인트미부여여부 / 제휴특판제한여부 / 제휴할인제한여부
카드사용제한여부 / 주문제작여부 / 예약판매상품여부 / 예약주문가능여부 / 소형상품여부
방송중판매가능여부 / 방송제휴여부 / 반복구매여부 / 성인인증여부 / 삼성상품여부
배송제한여부 / 반품불가여부 / 정보수정불가여부 / 매장진열여부 / 세금계산서발행여부
특소세여부 / 사은품여부 / 이미지확인여부 / 자동주문가능여부 / 편의점택배반품여부
센터추가포장여부 / 유료배송여부 / 당일배송가능여부 / 당일배송여부
당일배송체크여부 / 유료배송추가여부 / 지정택배시행여부 / 교환반품유료여부
속성상품가격여부 / 판매종료여부 / 정품여부 / 균일가상품여부 / 결품알람여부
상품응대대상여부 / 당사상품권여부 / 인터페이스여부 / 방송상품여부
직원용상품여부 / 전시여부 / 승인여부 / 재고유무 / 포장가능여부 / 나이제한여부 /해외배송가능여부
신규여부 / 세일표기여부 / 쿠폰표기여부 / 포인트표기여부 / 카드할인표기여부 / 카드가능여부

어떤가 어지럽다. . . .

해당 속성 마다 제 고유의 비즈니스 로직도 함께 녹아져 있으니 속성의 참 뜻을 이해하기란 상당히 어렵다. 하나의 테이블에 있는 속성이라고 하더라도 개발 담당하였던 시기가 다를 때 한사람이 모든 여부 컬럼의 목적과 활용도를 알기는 쉽지 않다.

여부 컬럼들은 그 사용 목적에 따라 여러 가지 유형이 존재 할 수 있다.

1)중복 속성

- 다른 테이블의 결과만을 요약형태로 갖는 경우 (처리여부)
배치처리 및 후속 처리의 결과 값으로 활용된다.
- 부모테이블에 자식테이블 데이터가 있다 없다 표기하는 경우 (존재여부/예약여부)
- 동일테이블의 컬럼에 대한 이중 표현
승인일시의 값이 있다, 없다 로 표현할 수 있지만 여부컬럼을 부수적으로 사용할 수 있다.
(요일상품여부 + 적용요일코드) (승인여부 + 승인일시) (원본여부 + 원본코드)
(전송여부+ 전송일시)

2) 데이터 분류용, 데이터 개체의 정의로 사용되는 속성

- 서브타입 역할을 하는 것 (품목여부/해외상품여부,거래처여부,판매처여부)
- 테이블의 구성을 알려주는 역할 (복사된상품여부 / 삭제여부)

3) 제어용 속성으로서 로직 처리 하기 위함

- 어플리케이션에서 특정 데이터만을 위한 예외 처리 (사용여부/무료여부)
- 제한 및 제약을 두기 위한 처리 (특판제한여부, 반품불가여부,카드가능여부 )
가능, 불가를 표현하기 위한 것

4) 성능을 위한 속성

- 이벤트 및 거래 액션의 결과 중에서 마크가 필요한 것 : 품절여부
- 요약용 컬럼 : 프로모션중여부, 사은품있음여부
중복속성과 유사한 성격이라고 할 수 있다.

5) 코드를 여부로 나열한 속성

- M개의 값을 YN으로 표기 하는 경우 (취미코드 : 바둑여부, 게임여부, 스포츠여부,..)
- 정규화에 의해서 다른 테이블로 분리가능 한 속성들.

6) 기타

- 아주 다양한 사연을 담고 있는 여부 컬럼들이 있겠다…

여부 컬럼 하나 하나의 사례는 기회가 되면 작성해 보도록 하고
여기서는 여부 컬럼들을 모델에 표현 하는 방법을 생각해 보고자 한다.

여부 컬럼의 표준화

여부 컬럼들은 실제 데이터 모델에서는 어떻게 사용되고 있을까

1) 표준화된 명칭

- 일반적으로 속성분류어로서 일관성 있게 사용한다. 여부, 플래그, 유무라고 표현된다.

OO여부->00_YN
00플래그 ->00_FLAG

2) 물리적 세팅

- NOT NULL 화 시키고, 디폴트 값을 부여한다.

< 의견 >
여부 컬럼은 NULL 컬럼 많고, 디폴트 값을 부여하지 않은 시스템들이 많다.
하지만 본인은 DB에서 강제하는 것을 선호한다.
시간이 흘러 여러 담당자가 바뀌다 보면 해당 컬럼의 초기값과 의미를 프로그램 소스를 열어 보아야만 알 수 있는 상황이 온다. 누구나 테이블에 세팅된 값을 보고 직관적으로 이해 할 수 있도록 DB에 세팅하는 것이 좋겠다.

- 물론 운영중에 추가되는 여부 컬럼은 NULL 허용이 많다.
기존 데이터는 영향 받지 않고 신규 데이터 혹은 특정 조건 일때만 사용되기 때문이다.
또한 NOT NULL 처리시 데이터 사이즈가 클 경우 디폴트 값을 세팅하는데 오랜 시간이 걸릴 수 있다.

- 프로젝트 진행시 초기에 모델표준에서 여부 컬럼에 대한 사용을 정의해 놓지 않으면 , 개발 및 이행단계에서는 NOT NULL 화 처리 하지 못하고 NULL 허용으로 그대로 가는 경우가 있다.
또 NOT NULL 처리는 입력 및 수정 프로그램의 수정이 필요하기 때문에 영향도 파악이 쉽지 않을 수 있다.

3) NOT NULL 화 할 수 없는 여부 컬럼

모든 여부 컬럼을 NOT NULL 화 시켜야 할까 특정 컬럼은 NULL이 올 수 밖에 없는가

[상품테이블][카드가능여부] 컬럼의 값을 보자

Y:100건
N:200건
NULL :700건

업무규칙은 Y이면 상품 구매시 카드를 사용할 수 있다.
N이면 카드 사용 불가 이다.
NULL이면 아직 세팅된 값이 없지만 카드 사용 불가 이다.
N 과 NULL은 동일 업무 규칙을 따른다.
단지 판단 할 수 있는 것은 값이 변경 이력인데 처음에 여부 값은 [ NULL ] 이였다가 카드사용이 가능해 졌을때 [ Y ]로 변경되고 이후 다시 [ N ] 로 변경되었음을 짐작 할 수 있다.
컬럼값의 변경을 위한 추적이라면 이력 혹은 로그 관리를 해야 한다.

변경이 한번도 없었던 값이라는 의미로서의 NULL 값을 유지 할 필요성이 많지 않다.

모델 내린다는 것은 위험한 일이지만 생각을 단순화하는 차원에서 NOT NULL 화 시키고, 예외가 되는 부분은 NULL 허용이라는 규칙을 가져가는 것이 좋겠다.

( 예외 : YN에 인덱스를 생성하는 경우,데이터 사이즈를 조금이라고 줄이려는 경우 등)

4) 테이터 값 검증

여부 컬럼의 데이터 값은 어떻게 세팅 되는가

가) Y/N : 긍정의 의미로서 Y, 부정의 의미로서 N
일반적인 데이터 세팅이다. 표준은 YN으로 세팅하는 것이 좋겠다.

나) 1/0 : 긍정의 의미로서 1, 부정의 의미로서 0
고전적인 표기법이라고 할 수 있으며 비트연산을 고려해서 만들 수도 있겠다.
추천하지는 않는다.

다) NULL : NULL은 가급적 없애자. 특히 핵심/메인/마스터 테이블에서는.
마스터 테이블의 NULL값을 여러 시스템, 서로 다른 개발자가 다른 값으로 치환하는 경우를 간혹 볼 수있다.A프로그램에서는 NVL(카드가능여부,’Y’)B프로그램에서는 NVL(카드가능여부,’N’)로 작성 할 오류 가능성도 존재한다.

라)1/2 : 이건 모죠
혹 Y/N을 1/2로 표현한 사이트도 있지 않을까 싶어서 만들어 보았다 (웃으시고…)

마)Y/N/Y/Z : 허억, 이건 또 모냐
여부 컬럼에 왜 이리 값이 많은 것일까
컬럼이 미쳤어 ~ 미쳤어.. 에고 돌아 보려 ~~~
추측 1 ) Y/Z는 오류 값이다. YN이어야 만 한다. 이런 데이터는 클린징이 필요하다.
추측 2 ) 여부 컬럼의 개념이 확장 되었다. 처음에는 YN 값만 있었는데, 세월이 지나고 시스템이 성장하면서 의미가 확장 될 수 있다.

[ 사용여부 ]

Y : 사용
N : 미사용
Y : 삭제a 미사용은 화면에 보이는데 아예 삭제된 데이터를 표기하고자 함
Z : 검토중a 주요 속성이라서 검토/승인 프로세스 진행이라는 것을 표기

물론 이렇게 개념이 확장 된 것은 이제 컬럼명은 사용여부 이지만 도메인은 사용유형코드로 변경되어야 한다. 여부컬럼이 코드컬럼으로 진화한 경우라고 볼 수 있겠다.
( 컬럼명은 변경하기 어려울 것이다. 이미 모든 프로그램에 적용되어 있을 테니…)

5) 이해가 편한 한글속성 표기

여부 컬럼도 한글속성명과 영문컬럼명을 잘 만들어 주어야 한다.
이름이 너무 어려우면 매번 머리에서 2번 고민을 해야 의미를 알 수 있는 컬럼 들이 있다.

- 무검사여부 : YN

Y : 제품에 대한 정밀검사를 하지 않았다는 의미. 즉 검사하지 않아도 되는 제품이다.
N : 제룸에 대한 정밀검사를 하지 않으면 안된다는 의미. 즉 검사를 반드시 해야하는 제품

위 컬럼은 몇 일 지나면 반드시 또 헷갈린다.

컬럼을 이렇게 바꾼다 e 검사여부 : YN

- 신용카드사용불가여부 : YN

Y : 신용카드를 사용할 수 없는 제품이다
N : 신용카드를 사용할 수 있는 제품이다

성공과 행복의 원천은 긍정적인 마음자세라고 한다
. 컬럼도 마찬가지다. 긍적적인 표현을 사용하자

컬럼을 이렇게 바꾼다 e 신용카드가능여부 : YN

- 적립금제한여부 : YN

Y : 적립금을 줄 수 없는 상품이다
N : 적립금을 줄 수 있는 상품이다

컬럼을 이렇게 바꾼다 e 적립금가능여부 : YN

사람마다 다르겠지만 혹 제한의 의미를 더욱 강조해야만 하는 경우에는 제한여부를 사용할 수도 있겠다. 판단은 모델러에게 > 다른 관련자들의 합의하에 결정하면 된다.

다음은 NOT NULL화 되지 않는 컬럼들에서 나타나는 NVL() 처리 예시이다


SELECT C.PRD_CD
,C.PRD_NM AS PRD_NM
,NVL(C.CHR_DLV_YN, 'N') AS CHARGE_FLAG========> 여부가 NULL 처리 : N으로 바뀐다
. ,CASE WHEN NVL(C.CHR_DLVC_CD, 0) > 0 THEN
,NVL(B.SALE_PRC, 0) AS KHS_PRICE========> 금액 NULL 처리 0으로 바뀐다.
FROM배송 D
,상품 C
,가격 B
WHEREA.PRD_CD = B.PRD_CD
ANDA.PRD_CD = C.PRD_CD
ANDC.SUP_CD = D.SUP_CD
ANDVALID_STR_DTM <= SYSDATE AND VALID_END_DTM > SYSDATE
ANDA.GUBUN = 'L'
ANDA.RANKING <= 20
ANDNVL(C.REP_YN,'N') <> 'Y'========> 여부가 NULL 처리 N으로 바뀐다.
ANDNVL(C.CARD_USE_LIMIT_YN, 'Y') <> 'N'========> 여부가 NULL 처리 Y로바뀐다.
ANDC.GBN_CD <> '10')


행여 여부 컬럼이 인덱스 대상 컬럼이라면 NVL()로 인한 가공으로 인하여 인덱스를 최적으로 사용하지 못할 수도 있겠다.

 

출처 : https://dataonair.or.kr/