[SQL고수되기] 첫번째 이야기

출처 : 네이버지식인 노하우
http://kin.naver.com/knowhow/detail.nhn?d1id=8&dirId=8&docId=552770&qb=c3FsIOqzoOyImOuQmOq4sA==&enc=utf8&section=kin&rank=1&search_sort=0&spq=0

으아~ Database와 동고동락한지 벌써 13년이네요.
정말 10년전과 비교하면 많이 변한듯합니다.
걱정이 되는 것은 글을 많이 보긴 했지만 집필해보진 않았기에 오타나 이야기 진행상에 미숙한 점이 있진 않을까 우려되기도 합니다. 하지만 조금이나마 시작하시는 분들에 도움이 되고자 한것이니 재미없고 따분한 내용일지라도 이쁘게 봐주시고 잘 봐주셨으면 하는 맘입니다.

지금까지 수많은 Database를 접해왔지만 제 입맛에 딱들어서 남다른 애정을 가지고 친구처럼 지내온 DB가 있습니다. Oracle입니다.
Oracle잘하느냐? 물어보면 쿼리 잘짜느냐? 라고 물어보는 것이라고 봐도 무방할 것입니다.
물론 SQL이라는 건 하나의 도구일 뿐이지만 다들 SQL(Query) 짜는데 혈안이 되어 있는것 같습니다.

그래서 수많은 중요한 내용이 있지만 그중에서 개발자들이 많이 접하게 디는 SQL에 대해서 이야기 해볼까 합니다.

어떻게 하면 쿼리를 잘 짤수 있을까? 그러려면 어떤 책을 봐야하나? 또 어디서부터 시작해야하지? 그럼 응용은 어떻게 할까? 현재 내가 잘하는건가? 쿼리 만큼은 어떤 끝이 보이지 않는 무궁무진한 언어처럼 보입니다.

그 이유는 바로 방법만을 찾으려고 고집해서 일겁니다. 너무 막연한 얘기처럼 보이겠지만 지금부터 제가 드리는 이야기가 그 생각을 바꾸어 드릴 수 있으면 좋겠습니다. 이런 마음가짐으로 이 이야기에 서두를 시작합니다.

세상에는 수많은 유형의 정보들이 분야별로 존재합니다. 하지만 한가지 공통점은 종류가 무엇이든 상관없이 관계형 데이터베이스 저장고에 등록되고 관리됩니다. 그것이 Oracle이 되었든 MsSQL이 되었든 말입니다. 하지만 어디까지나 그것은 물리적으로 각 데이터베이스의 특징에 맞게 물리적으로 저장고(하드디스크)에 잘~~~ 보관하는데에 주 목적이 있습니다.
그럼 잘 저장되었는지 어떻게 확인할까요. 보통은 SELECT * FROM 테이블 이렇게 하실겁니다. 물론 Library를 활용한 검증을 하시는 분들도 계실겁니다. 앞에 경우던 뒤에 경우던 공통점은 물리적인 Entity의 확인일 뿐입니다.

저기요~ SELECT ~ FROM 이거 SQL 질의아닌가요? 라고 반문 하실겁니다. 맞습니다. 하지만 정확히 말하면 물리적 정보를 단순 조회하는 방법일 뿐이지 SQL의 주 목적이나 이유가 되지는 못한다는 것입니다. 그럼 SQL은 어떻게 표현하는게 맞을까요? 논리적인 Entity 정의 이것이 정확한 표현일 것입니다.  다음 그림을 보면서 한번 생각해 보도록 하겠습니다.

　　┌─────┐　┌─────┐　┌─────┐　　　　　┌─────┐

　　│ 테이블1　│　│ 테이블2　│　│ 테이블3　│　......　│ 테이블N　│

　　└─────┘　└─────┘　└─────┘　　　　　└─────┘

A사용자 요청(SR-1) : 월별 생산현황을 보고싶다 ...
B사용자 요청(SR-2) : 일일 판매실적을 사원별로 보고싶다...

위 두개의 요청사항(Service Request)에 대해 분석을 하게 될 것입니다. 분석결과 SR-1을 처리하기 위해서는 테이블1, 테이블2 정보를 활용해야 할 것으로 분석되었고, SR-2를 처리하기 위해서는 테이블1, 테이블2, 테이블3 정보를 활용해야 할 것으로 분석되었습니다. 그럼 무엇을 위한 분석일까요? 바로 SR-11을 표현하기 위한 새로운 Entity를 정의한 결과라고 보면 좋을 것입니다. 그럼 새로운 Entity(=월별생산현황)를 만들기 위해서 어떤 항목들이 필요한지... 등등 테이블 설계를 하듯이 진행하게 됩니다. 하지만 중요한건 물리적으로 존재하는 테이블1, 테이블2를 연결하여 그 안에 정의된 내용을 기준으로 만들어야 한다는 전제가 있다는 점에서 다르다고 말할 수 있습니다. 이처럼 실제 물리적으로는 일자별로 가지고 있지만 표현해야하는 내용 년, 월이라면 또 일별로 저장되어 있는 생산량을 월별 총생산량으로 표현해야한다면

SQL을 작성해서 SUBSTR(생산일자,1,4)||'년'||SUBSTR(생산일자,5,2)||'월' 이런식으로 표현해야 할 것입니다. 또 그것이 이름을(Alias) "생산년월"로 정의하고자 할 것입니다.

이처럼 정의된(한) 내용을 표현하기 위해 여러가지 방식과 방법으로 SQL이라는 DB언어를 통해 표현하게 됩니다. 안타까운 것은 테이블은 하나지만 요청자, 개발자, 사용자 등 수많은 Request에 대해 수만가지 논리적인 정보들이 만들어지게 됩니다.

필요(요청)에 따라서 실시간으로 표현되고 사라지고 하는 논리적인 Entity들, 바로 이것들을 만들기 위한 방법이 SQL언어라고 생각하시면 될 것입니다. SQL 잘 짜려면 문법도 중요하지만 테이블 설계하는 것과 똑같이 논리적인 분석 설계가 잘 되어야 쿼리를 잘 짜게 될 것입니다. 퀄리를 빨리 짜기 위해 모방하는 것은 좋습니다. 하지만 그게 계속 반복된다면 자기 생각이 아니기에 몇년 후에 경력이 쌓여서도 언제나 Copy & Paste의 반복은 계속될 것입니다. 분석은 발했지만 어떻게 구현하지? 당연히 어려울 수 있습니다. 이때 도움을 받던 사례를 보던 전개하는 방법을 내가 설계한 내용을 기준으로 한다면 아~ 이렇게 표현하면 되는구나 하고 자기 지식이 되는 것을 느끼게 될 것입니다.

과학자는 실제 실험을 통해 문제를 해결하지만 수학자는 논리적인 이론을 통해 대부분의 문제를 해결해 나갑니다. 우리는 어느쪽일까요?
이 문제의 해답을 여러분께 맡기고 오늘은 이만할까합니다.