우선! 자극적으로 제목을 작성한 것에 양해를 구합니다.
이 포스트는 그저 제 의견이며 무조건 옳다는 것은 아니라는 점을 밝힙니다.
(레퍼런스는 포스트 마지막 부분에 있습니다.)
본 포스트를 읽고 이해한 이후 "SQL JOIN을 벤 다이어그램으로 설명" 하는 것을 보면 어디인지 모르게 불편한 마음이 드는 현상에 대해 책임지지 않습니다!
SQL JOIN을 설명할 때에는 벤 다이어그램을 자주 사용합니다.
구글에 검색을 해보아도, 책에서도, 온라인 포스트에서도 벤 다이어그램을 통해 설명합니다.
심지어는 누군가에게 배우거나 누군가를 가르칠 때에도 벤 다이어그램의 도움을 받기도 합니다.
SQL JOIN 외에도 벤 다이어그램을 통해 설명하는 방식은 널리 쓰이다 보니 누구에게나 굉장히 익숙하지 않은가 하는 생각도 듭니다.
그래서... "모두" 가 그렇게 사용하고 있으니 정확한 방식으로 표현하는 것일까요?
그것을 뒷받침하듯이 구글 검색 결과도 이렇게나 벤 다이어그램이 많이 나오니까 말이에요.
결론적으로, SQL JOIN을 벤 다이어그램으로 설명하는 것은 대체적으로 정확한 방식이 아닙니다.
SQL JOIN을 설명할 때에 벤 다이어그램을 사용하는 것이 정확하지 않은 이유를 이해하기 위해서는 벤 다이어그램이 어떤 개념인지 살펴 볼 필요가 있습니다.
(아래의 인용 내용은 그 아래에서 추가적으로 설명하니 스윽 훑고 내리셔도 괜찮습니다.)
벤 다이어그램(Venn diagram)은 서로 다른 집합들 사이의 관계를 표현하는 다이어그램이다.
주황색 원(집합 A)은 다리가 두 개인 모든 생물들, 푸른 원(집합 B)은 날 수 있는 모든 생물들을 나타낸다. 각종 생물은 곧 그림의 어느 곳에 위치한 점과 같다. 예를 들어 비둘기처럼 두 다리를 가진 날 수 있는 생물은, 두 원이 겹치는 부분에 위치하는 점이다.
인간과 펭귄은 다리가 두 개여서 주황색 원에 위치하나, 날지는 못하므로 푸른 원과 겹치지 않은 곳에 위치한다. 날 수 있지만 다리가 여섯 개인 모기는, 푸른 원 중 주황색 원과 겹치지 않은 부분에 있다. 고래나 거미처럼, 두 다리를 갖지도 않고 날지도 못하는 생물은 두 원의 바깥에 있을 것이다.
A와 B를 합친 영역을 A와 B의 합집합이라고 한다. 이는 곧 두 다리를 가졌거나, 날 수 있거나, 혹은 양쪽 다에 해당하는 생물들을 모은 것이다.
A와 B가 겹쳐진 영역을 A와 B의 교집합이라고 한다. 이는 곧 두 다리와 날 수 있는 능력을 동시에 갖춘 생물들을 모은 것이다.
널리 쓰이고 나름대로의 레퍼런스를 요구하는 위키피디아에서의 정의와 예시입니다.
설명하라고 하면 막상 명확하게 설명하지는 못 하더라도 머릿속에서는 한창 떠올리고 있는 그것입니다.
이 벤 다이어그램은 집합과 집합간의 관계를 표현하기 위한 개념입니다.
다리가 2개인 생물과 날 수 있는 생물에서의 대표적인 교집합은 "다리가 2개이고 날 수 있는 생물" 일 것입니다.
중요하니 한 번 더 표현하자면 "다리가 2개이고 날 수 있는 생물" 입니다.
다리가 2개인 생물과 날 수 있는 생물을 결합(JOIN)한 그 결과가 아니라, 애초부터 이미 "다리가 2개이고 날 수 있는 생물" 이라는 것이 포인트입니다.
어떤 말을 하고 싶은지 눈치챈 분이 혹시 있을까요?
(벌써 눈치 채셨다면 축하드립니다! 설마 INTP인가요!?)
그렇습니다.
벤 다이어그램으로 표현하는 집합 연산 결과는 어느 집합에 있던 것이든 각각의 원소에 어떠한 조작도 가하지 않는다는 것입니다.
아직 이해가 되지 않은 분을 위해 다르게 표현하자면, SQL JOIN은 양쪽의 원소를 결합(JOIN)하는 연산이고, 벤 다이어그램은 결합이 아니라 분류를 하는 연산입니다.
(엄밀한 표현은 아니지만 말이 그렇다는 것입니다.)
그래도 이해하기가 아직 어려울 수 있을 것 같습니다.
눈을 감거나 뒤로가기를 하지 말고, 아래 섹션을 마저 살펴 보면 이해를 도울 수 있을 것입니다.
SQL JOIN을 벤 다이어그램 보다 정확하게 설명하는 것은 의외로 어렵지 않습니다.
그저 결과를 요약해 표현하면 됩니다.
마치 아래 이미지처럼 말이죠.
(레퍼런스를 기반으로 직접 다시 그렸음을 밝힙니다.)
대표적인 4가지 JOIN 연산인 INNER, LEFT, RIGHT, FULL 순서대로 보이는 그림입니다.
순서대로, 왼쪽의 숫자 집합과 오른쪽의 알파벳 집합이 연산 정의에 따라 같은 위치의 있는 레코드가 결합(JOIN)해 결과를 나타냅니다.
INNER JOIN으로 보자면, 정확히 같은 위치에 있는 레코드끼리만 결합(JOIN)하는 형태입니다.
나머지 JOIN 연산도 비슷한 원리입니다.
벤 다이어그램과의 차이점은 결합결과까지도 표현한다는 것입니다.
살펴 보았듯이 SQL JOIN을 설명함에 있어 벤 다이어그램은 적절한 방식이 아닙니다.
언뜻 생각해보면 그래도 SELF JOIN은 사정이 다르지 않겠느냐 할 수 있지만, JOIN은 레코드를 결합하는 연산이니 여전히 적절한 방식이 아닙니다.
이제 여러분은 "SQL JOIN을 벤 다이어그램으로 설명" 하는 것을 보면 어디인지 모르게 불편한 마음이 드는 현상이 발생할 것입니다!
이것을 위해 이 포스트를 작성한... 것은 아니고, 이러한 의견도 있다는 것을 포스트로 작성해보고 싶었습니다.
여기까지 읽어 주셔서 감사합니다.
그럼 벤 다이어그램을 두 집합에 대한 벤 다이어그램에서 세 집합에 대한 벤 다이어그램으로 바꾸면 어떨까요? 예를들어 JOIN문 조건이 on A.animal = B.animal 일때, 주어 집합 P는 "A 데이터 테이블에 있는 동물 집합", 주어 집합 Q는 "B 데이터 테이블에 있는 동물 집합", 술어 집합 R은 "주어 집합의 모든 개체 x 각각 에 대한 {A 혹은 B 데이터 테이블에 있는 모든 컬럼} 정보 집합" 으로 하는거죠, 그리고 INNER JOIN이면, P∩Q∩R 인거고, LEFT JOIN이면 P∩R라고 설명하는거에요
마지막으로, 없는 정보는 null이라고 표시한다는 명제를 추가하거나 R을 null 데이터 포함으로 정의 하면되요
:thumbsup