[SQL고수되기] 여섯번째 이야기

출처: 네이버지식인 노하우

 http://kin.naver.com/knowhow/detail.nhn?d1id=8&dirId=8&docId=552927&qb=U1FM6rOg7IiY65CY6riw&enc=utf8&section=kin&rank=12&search_sort=0&spq=0

오늘부터 어제 만든 테이블들을 활용하여 쿼리(논리Entity)를 만들어보겠습니다.
그전에 논리 Entity에 대한 정의에 대해 상세하게 다뤄볼까합니다.

 

WORK_INF(출퇴근정보) -------------------------------------------

출근일자　　사번　　 　출근일시　　　　　　　퇴근일시
(ATTN_YMD)　(SNO)　　　(CHECK_IN)　　　　　　(CHECK_OUT)
----------------------------------------------------------------
20100401　　10010001　2010-04-01 08:40:24　2010-04-01 17:54:36

20100401　　10010002　2010-04-01 09:11:00　2010-04-01 17:36:00
20100401　　10010003　2010-04-01 08:57:48　2010-04-01 17:25:48
20100401　　10010004　2010-04-01 08:25:24　2010-04-01 17:40:12
20100401　　10010005　2010-04-01 09:02:36　2010-04-01 17:38:24
20100401　　10010006　2010-04-01 08:23:00　2010-04-01 19:05:24
20100401　　10010007　2010-04-01 08:23:00　2010-04-01 19:19:48
20100401　　10010008　2010-04-01 08:58:24　2010-04-01 17:07:12
20100401　　10010009　2010-04-01 09:09:48　2010-04-01 19:45:36
20100401　　10010010　2010-04-01 08:47:00　2010-04-01 17:54:00

----------------------------------------------------------------

위 표는 2001.04.01 출근현황으로 제가 임의로 생성하였습니다.

 

SELECT *

FROM WORK_INF

WHERE ATTN_YMD LIKE '201004%'

이렇게 조회하면 위 표대로 나오겠지요? 이건 단순한 물리적Entity조회입니다.

 

조금 바꿔볼까요. 요청을 하나 만들어 보겠습니다.

원하는 날짜에 해당하는 명단을 다음 형태로 보고싶다.

-> 일자(요일) | 사번 | 출근시간 | 근무시각(시) | 지각시각(분)

                     (시:분:초)

예)  4/1(목) 10010001 08:40:24　8시간 30분 15분

 

Entity 분석을 해보도록 하겠습니다.

　　　　　테이블정보　　　　　　　파생정보

항목　　　(원시정보,물리Entity)　(가공정보,논리Entity)

--------------------------------------------------------------------------------

근무일자　20100401　　　　　　　　SUBSTR(ATTN_YMD,5,2)||'/'||SUBSTR(ATTN_YMD,7,2)

　　사번  10010001　　　　　　　　사번

출근시간  2010-04-0108:40:24　　　TO_CHAR(CHECK_IN,'hh:mi:ss')

근무시각  None　　　　　　　　　　(CHECK_OUT-CHECK_IN)*24

지각시각  None　　　　　　　　　　CEIL((CHECK_IN-

　　　　　　　　　　　　　　　　　TO_DATE(ATTN_YMD||'09','yyyymmddhh'))*24*60)

파생정보중 사번는 물리정보 그대로 사용되었습니다. 하지만 나머지 정보들은 재정의(defined)되었습니다. 바꿔말하면 새로운 정보를 생성하였다 라고 말할수 있는것입니다. 쉽게 말해서 데이터베이스에 TO_CHAR(CHECK_IN,'hh:mi:ss') 이런 정보는 없다는 이야기입니다. 종종 Defined Query라는 표현을 보신적이 있으실 겁니다. 이말이 위에 말하고 같다라고 보시면 정확한 표현이 될것입니다.

정리하면 내가 재정의한(재가만든) 항목(Column)은 사번을 제외하고 "SUBSTR(ATTN_YMD,5,2)||'/'||SUBSTR(ATTN_YMD,7,2)", "TO_CHAR(CHECK_IN,'hh:mi:ss')", "(CHECK_OUT-CHECK_IN)*24", "CEIL((CHECK_IN-TO_DATE(ATTN_YMD||'09','yyyymmddhh'))*24*60)" 이렇습니다. 컬럼 처럼 안보이시죠? 그래서 Alias를 줘서 보이좋게 만들어보겠습니다.

 

SUBSTR(ATTN_YMD,5,2)||'/'||SUBSTR(ATTN_YMD,7,2) as "근무일자"

사번

TO_CHAR(CHECK_IN,'hh:mi:ss') as "출근시간"

(CHECK_OUT-CHECK_IN)*24 as "근무시간(시)"

CEIL((CHECK_IN-TO_DATE(ATTN_YMD||'09','yyyymmddhh'))*24*60) as "지각시각(분)"

 

이렇게 표현되겠네요. as ""는 이름을 명명하는것이지 컬럼은 아닌 것입니다.

 

이처럼 저장되어 있는 정보를 그대로 사용하는것이 아니라 어떤 상황에 맞게 재정의해서 새로운 표현을 만들어 내는것을 Query라고 말하는 것입니다. 예를들어 표현해야하는 항목이 급여액 항목이라면 어떨까요? 한 컬럼을 표현하기 위해 조인부터/계산공식까지 수많은 업무로직이 적용될 것입니다. 또 핸드폰 청구금액을 산출한다. 라고 하면 더더더 엄청난 내용으로 시간대별 적용 등등 수많은 로직을 적용해서 하나의 항목을 만들어 내게 될것입니다.

 

그러나 이전에 이런 것들을 만들어 만들어 내기 위한 원시정보(물리적정보)가 정상적이지 못하다면 그걸 토대로 가공되는 정보 또한 보장될 수 없는 정보가 될것입니다.

 

단순하게 SELECT,INSERT,UPDATE,DELETE 하는 쿼리를 문법에 의한 생성으로 한다면 절대 업무적인 관점에서 접근하기란 어렵게됩니다. 어떤 개발자는 경제학과를 나와서 IT업계에서 일하게 된 경우가 있다고 합시다. 어떨까요. DB에 대한 경험이 부족하기에 어려울꺼라 생각이 드실겁니다. 절대아닙니다. 오히려 업무에 필요한 새로운 유형의 정보들은 만들어내는 능력은 훨씬 탁월할것입니다. 이렇게 표현해야 하는데 어떻게 하면좋을까. 생각을 가지고 서적을 뒤지고 검색을 해서 만들어 냈다면 그건 자기만의 노하우가 될 것입니다. 하지만 그 반대경우라면 자기의 생각과 분석이 적용되지 않은 Entity라면 그건 누가 짠 기능을 그냥 보기만 한 수준에 그치게 되는 것입니다.

 

쿼리를 짜는데 있어 정답은 업습니다. 개발자가 100명이면 같은 결과에 생성쿼리는 다 다를수 있습니다. 경험에 차이, 생각에 차이, 처리방식의 차이 등등.. 하지만 100명이 만든 쿼리가 다 같다면 ^^ 어떨까요? 한번 곰곰히 생각해보세요.

 

 오늘 아주 간단하게 예를 들어 이야기 하였습니다. 물론 문법을 알면 조금 빠르겠지만 게시판만 짤게 아니기 때문에 논리적인 Entity를 만들어 내는 과정을 자기만의 생각으로 만들어 나가는 과정이 매우 중요합니다. 여러 상황을 접해보고 그상황에서 발생한 또는 발생할 수 있는 내용들은 재정의 해 보는게 쿼리 전문가로 가는 지름길이라고 확신합니다.