1 집합적 사고방식의 분류

2 SQL 작성시 집합적 사고방식

3 DB모델링시 집합적 사고방식

집합적 사고방식은 우선 2가지로 분류하여 살펴볼 수 있다. 그 2가지는 아래와 같다.

• SQL 작성시 집합적 사고방식
  
• DB모델링시 집합적 사고방식
  
  

우선 SQL작성시 필요한 개념은 ‘2차원배열 단위로 처리된다고 생각’ 이다. 일반적인 C프로그래밍에서의 2차원 배열을 생각해보자. 데이터를 2차원 테이블형태(타일모양)으로 화면에 그려준다고 생각해보자. 그러면 일단 이중 For문을 돌면서 배열의 데이터를 가져올 것이다. 아마도 머리속에서는 난리가 날 것이다. (필자는 머리가 나빠서 루프가 2개만 되도 머리가 지끈거린다.) ‘일단 변수를 하나 만들어서 초기값을 세팅하고, 처음 For문의 루틴에서는 배열을 끝까지 돌면서 데이터를 가져오고 .... ‘ 상당히 복잡하다. 그러면 SQL작성시는? 그냥 ‘A집합(Set, 2차원 배열의 데이터)을 보여줘’ 라고 하면 끝이다.

그렇다면 진짜로 과연 집합적으로만 생각하면 SQL을 잘 작성할 수 있을까? 절대 아니라고 본다. 오히려 절차적인 사고방식을 섞어 SQL을 작성해야 하는 것이 더 좋은 SQL을 만들 수 있다. 물론 전제조건이 있다. 그 전제 조건은 DBMS의 내부동작을 어느정도 알고 있어야 한다는 것이다. 우찌되었건 DBMS도 절차적인 언어로 작성되었고, 절차적인 언어로 처리되기 때문이다. (당장 이해가 가지 않아도 차차 살펴보다 보면 알게 된다. 이쯤해두자. 라고 하고 싶은데.. 사실 이게 상당한 진입장벽이다.) 다음의 소스를 보자.

--MSSQL2k, pubs..titles
SELECT 
	type
,	MAX(price) MaxPrice
FROM titles
GROUP BY type
 
--결과
type         MaxPrice              
------------ --------------------- 
business     19.9900
mod_cook     19.9900
popular_comp 22.9500
psychology   21.5900
trad_cook    20.9500
UNDECIDED    NULL

만약 여러분이 위의 결과에 title까지 조회하고 싶다면 우짤것인가? 초보들은 분명히 다음과 같이 SQL을 작성할 것이다. 그리고는 문법에 맞지 않는다는 에러 메세지를 보고 또 한번 실망할 것이다.

--Error!!
SELECT 
	type
,	title
,	MAX(price) MaxPrice
FROM titles
GROUP BY type
 
--원하는 결과가 아님
SELECT 
	type
,	title
,	MAX(price) MaxPrice
FROM titles
GROUP BY 
	type
,	title

그럼 어떻게 하지? 여러분들이 고민해보라. (만약 모르는 사람이 있다면 다음의 소스를 보기 전에 며칠이고 고민해 봐야한다. 그래야 실력이 늘어난다. 그리고 느낄 수 있다.)

--성능을 구지 따져본다면 좋지는 않다. 하지만 현재는 데이터가 더이상 들어올 것이 아니니까...전혀 상관이 없다.
--만약 성능까지 고려를 한다면 또 다른 고민을 해야 할 것이다. 
--옛날 방식이긴 하지만 이해를 돕기 위한 것이니 그냥 봐줘욧~
SELECT
	B.type
,	A.title
,	B.MaxPrice
FROM titles A INNER JOIN (
			SELECT
				type
			,	MAX(price) MaxPrice
			FROM titles
			GROUP BY type) B
ON A.type = B.type
AND A.price = B.MaxPrice
 
--결과
type         title                                                                            MaxPrice              
------------ -------------------------------------------------------------------------------- --------------------- 
trad_cook    Onions, Leeks, AND Garlic: Cooking Secrets of the Mediterranean                  20.9500
psychology   Computer Phobic AND Non-Phobic Individuals: Behavior Variations                  21.5900
popular_comp But IS It User Friendly?                                                         22.9500
mod_cook     Silicon Valley Gastronomic Treats                                                19.9900
business     The Busy Executive's Database Guide                                              19.9900
business     Straight Talk About Computers

데이터모델링시는 필요한 집합적 사고방식은 수학시간에 집합의 예를 생각하면 쉽게 알 수 있다. 예를 들어 보자.

• 롱다리: 키가 큰 사람들의 모임
  
• 사원: A사에 근무한 사람
  
  

우선 '롱다리'를 살펴보자. 롱다리는 집합인가? 수학시간에 잠깐 눈만 뜨고 있었어도 집합이 아니라는 것을 알 수 있다. 왜냐하면 '키 큰'이라는 부분이 모호하기 때문이다. '크다'라는 것은 해석하기에 따라 True/False가 달라질 수 있다. 만약 제대로 집합을 정의하려면 '서서 측정한 키가 180Cm 이상인 대한민국 국적을 가진 사람' 정도는 되어야 명확하다.

두 번째로 '사원'을 보자. '사원'을 위와 같이 정의한다면 해석하기에 따라 근무만 A사에서 하면 되는 것으로 볼 수 있다. 그러면 B사에서 파견나와 있는 김대리도 정의에 포함되고, 작년에 퇴사한 이부장도 정의에 포함되며, 서버 유지보주 업체에서 정기 점검차 왔던 박과장도 사원의 범주에 속하게 된다.

이처럼 데이터 모델링을 할 때는 애매모호한 정의를 해서는 안 된다. 물론 데이터 모델링뿐만 아니라 소프트웨어 Life Cycle동안에 모든 활동이 명확히 정의되는 것이 좋다. 많은 데이터 모델링에 책에서 '명사'를 언급하는 이유가 바로 이런 이유이다. 명사는 개념의 언어적인 표현하였다. 다음의 아리스토텔레스의 명사의 정의이다.

아리스토텔레스는 《형이상학》에서 ‘horos(사물의 끝 ·경계)’를 삼단논법과 비례식의 유추(類推)로부터 사물의 본질을 깊이 규정하고 그 능력 ·성질을 한정하는 울타리라는 뜻으로 사용하였다. 이것이 보에티우스에 의해서 ‘terminus’로 번역되어 전통논리학에서는 범주적 명제(範疇的命題)의 주어 ·술어를 가리키게 되었다. --네이버 백과사전

보다 깊숙히 알고 싶다면 필자는 아리스토텔레스의 '범주론 명제론'을 추천한다.