Computer Science/DataBase

Join, View, Transaction....

카세우스 2026. 11. 2. 18:30

보다 보면 볼수록 희한하다

Join Expression

앞에서는 정보들을 결합할 때 Cartesian Product를 사용했긴 했는데, 사실 Join을 이용하는 방법이 있다. 참고로 join이 튀어나온 이유는 딱 한가지, Cartesian Product 만으로는 다루기 매우 지랄맞은 경우가 있기 때문이다.

 

▶ Natural Join

쨋든 정보의 결합에 join이 사용되게 되며, 이에 대한 대표적인 경우로 natural join이 있겠다. natural join은 두 릴레이션 사이의 Cartesian Product와는 다르게, 양쪽 공통 attribute의 value가 같은 튜플들 만을 뱉어낸다.

 

select name, course_id
from student, takes
where student.ID = takes.ID;

select name, course_id
from student natural join takes;

그러니까 위 SQL이나, 아래 SQL문이나 같은 relation을 뱉을 것이다.  참고로 natural join을 이용해서 여러개의 릴레이션을 하나로 from절에서 불러올 수 있기도 하다.  다만 아래와 같은 경우는 문제의 소지가 발생할 수 있다.

 

select name, title
from student natural join takes natural join course;

세 릴레이션의 공통집합이 아니라, 순차적으로 집합이 계산되기 때문. 다행히도 이러한 대참사를 막기 위해서, SQL은 natural join 구조에서 어떤 얘가 같아야 하는지 명시할 수 있다.

 

select name, title
from (student natural join takes) join course using (course_id);

using 뒤에 attrubute를 명세 해 주면 된다!

 

 

▶ Join Conditions

쨋든 위에서 보다시피 (어떤 방법이로든) SQL은 임의의 속성을 명세해 이걸로 매칭하도록 할 수 있는데, Join 뒤에 (natural로 갈기지 않는 이상 무조건 따라붙게 되는) on condition의 경우 조인 되는 릴레이션 끼리의 일반적인 연산을 지원한다. 대걍 아래와 같은 쿼리를 생각해보자.

 

select *
from student join takes on student.ID = takes.ID;

여기서의 on condition의 경우 student.ID가 takes.ID와 매칭되면 튜플을 뱉어내도록 하고 있으며, 이건 natural join과 종일하다고 할 수 있다. 근데 이럴꺼면 굳이 on condition의 존재 이유가 없지 않겠는가?

 

 

▶ Outer Join

Ref : https://www.hanbit.co.kr/channel-h/view/7534

엥간한 것은 위의 두개를 활용하면 썰 수 있겠으나, 데이터는 항상 우리 맘대로 저장되어 있지 않은 경우가 대다수다. 예를 들어서, 수강신청 DB에서 어떤 학생은 수업을 아예 안들었을 수도(null) 있는 것 아닌가? 취업이 안되서 졸업 유예를 신청한 CS 학생일 것이다 아마 그러니까, natural Join에서는 뭔가 손실이 날 수 있다는 것이다. 그래서 outer-join 연산에서는 null value가 있는 tuple.. 그러니까 매칭이 되지 않는 튜플도 경우에 따라서 살린다. 그리고 이러한 outer join에는 3가지 형태가 있다.

 

  1. Left Outer Join : 왼쪽에 적힌 릴레이션의 튜플들(아마도 null값이 있는)을 살린다.
  2. Right Outer Join : 오른쪽에 적힌 릴레이션의 튜플들을 살린다.
  3. Full Outer Join : 둘다 살린다!

쨋든 Outer join을 치고 나서는, 빈 값에 null을 쳐박는다. 반대로, inner-join의 경우 매칭되지 않는 튜플은 신경쓰지 않는다.

 

select ID
from student natural left outer join takes
where course_id is null;

참고로 이런 경우도 있을 수 있는데, 얘는 교집합이 날아간 케이스라고 할 수 있겠다.

 

 

 

 

 

Views

얘의 존재 이유는... 모든 유저가 DB의 전체 튜플들을 보면 좀 거시기 할 것이 분명하기 때문. 그래서 View라는 이름의 "Virtual Relation"을 Query로 Define해서 뱉어낼 수 있게 해주었다. 얘는 미리 계산되거나 저장되는건 아니지만, 사용 될 때 쿼리에 따라서 계산되게 된다. 

 

create view faculty as <query expression>

참고로 일반적으로, View에 대해서 Modification은 허용되지 않으며 특수한 경우에만 허용된다.

 

▶ Materialized Views

몇몇 DBMS의 경우에는 Materialized View라는 기능을 지원하곤 하는데, 쉽게 말해서 쿼리로 튀어나온 결과를 램에 쳐박아 두는게 아니라 진짜 저장까지 하는 경우라고 보면 된다. 다만 View의 경우와 달리 갱신 전까지는 오래된 값이 나타나올 수 있으며, REFRESH가 필연적으로 발생하게 된다. 참고로 이러한 일련의 절차를 materialized view maintenance라고 하게 된다.

 

 

 

 

 

Transcations

Transcation이란 결국엔 Commit 또는 Rollback이라고 할 수 있겠다.

  • Commit은 말그대로 현재 Transcation을 반영한다. 그러니까 지금까지 한 짓을 영구히 DB에 반영하겠다는 소리.
  • Rollback은 말 그대로 도로아미타불을 시행하는 것을 의미한다.  그러니까 지금까지 한 짓을 없던 일로 만들어 버리겠다는 소리.

참고로 짧은 시간에 Transaction이 발생하는 경우가 생길 수도 있을 것이며, 이와 관련해서 크나큰 문제들과 이론들이 정립되어 있으니 이는 나중에 얘기하도록 하자.