DB2 - Oracle (2)Join (완)

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

@16.1.테이블의 분해 조립 - 분해하기

Relation 이라는 말이 관계형 데이터베이스의 정체성을 규정한다.

1. 표라는 형태로 데이터를 다룬다는 굉장히 혁명적인 측면
2. 지금부터 살펴볼 얘긴데 표를 사용하다보면 표가 비대해짐 

-> 이때 관계형 데이터베이스를 이용하면

(1)표를 필요에 따라 잘게 쪼갠다든지

(2)쪼개진 표들을 요렇게 저렇게 결합하는 것

을 통해 실제로 존재하지 않는 표인데 원래부터 존재하고 있었던 것과 같은 환상적인 표를 만들 수 있다

 

컴퓨터 공학적으로 컴퓨터는 인간이 수동으로 할 수 있는 일만 처리할 수 있다. --대표적으로 자동화!

-> 인간이 할 수 없는 일을 처리하면 특이점이 온 것.

여러분이 알고 있는 것을 분명하게 확인하기 위해서는 기계한테 자동화를 시키기 전에 수동으로 먼저 해보시라는 것

-> 할 수 있고 설명할 수 있으면 확실하게 이해하고 있는 것.

 

정보공학을 공부할 때 항상 극단적인 생각을 해야함.

(1)컬럼을 추가할 때 정보가 1억개라면?

 > 이름, 직업을 추가했는데 그 사람 직업이 바뀌어서 바꾸는데 그게 1억개면 3년걸리고

(2)또 하나의 칸에 데이터가 1기가짜리면? 그걸 계속 해당하는 행의 컬럼마다 입력해야하면 낭비임. 1이라고 해놓고 딴테이블에서 갖고오는게

(3)이름과 직업이 같은 두 사람이 있으면?

(4)저자이긴한데 글을 쓰지 않은 사람이 있다면, 이 사람의 존재를 책, 이름 직업만 있는 표에서 어떻게 표현?

 

이런문제들을 극복하는 법 : 표(▽를 평소에) 쪼개서 두는 것.

아래의 쪼갠 두 테이블 중 topic테이블의 author_id의 1이라는 정보로 오른쪽 테이블에서 이름과 직업을 알 수 있다.

 > 연결이 돼 있네

- 옛날에는 egoing이 직업을 바꾸면 표에서 1억번 바꿔야 했지만

 + 만약에 행하나가 1기가 짜리라면? 오라클의 저장공간은 소중한데 흥청망청 쓰는 것

 > 이제 author에서 하나의 행만 우아하게 developer를 manager로 수정하면 한번에 수정되는 폭발적인 효과를 가질 수 있다.

- 글을 한번도 쓴적 없는 사람은 author테이블 안에서만 존재할 수도 있다. topic 테이블에서 안 갖다 써도 존재가능

- eoing이름과 직업이 같은 사람은 author테이블의 별도의 id값을 갖고 있는 행을 통해 정보가 똑같아도 다른 사람으로 구분할 수 있다.

 

하나의 거대한 표를 성격에 따라 쪼개는 걸 통해서 엄청난 효과를 얻을 수 있다라는 겁니다.

 

관계형DB에서 굉장히 중요한 요소인 표를 (1)분해하고 (2)필요에 따라 조립한다 라는 ‘분해‘ 측면.

 

방금 제가 한걸 설명해보십쇼 글로 써보시고요 내가 지금 어디가 설명이 안되는가를 꼭 자기눈으로 확인하고 그것을 충분히 음미한 다음에 다음 영상을 보시면 행복하실 겁니다 행복합시다

 

▽내 설명 : 분해를 했기 때문에 고유 id를 부여하곤 그것에 대한 정보를 한번만 쓰면 됐고

- 중복되는 이름을 구분할 수 있었고

- 그에 따르는 정보들을 한번만 바꿔도 됐고 > ▽이 단어는 항상 어떤 공간을 가르키게 하고 딱 거기만 바꾸면 되는 느낌

- 그러므로 테이블을 여러 개로 나눠놓는 것에 이득이 있다.

- 그리고 JOIN 은 이러이러한 편리로 평소에 나눠놓은 테이블을 조합할 때 쓰는 것

 

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

@16.2.테이블의 분해 조립 - 조립하기

 

표를 쪼갠다는 발상은 굉장히 뛰어난 것. - 어떻게 쪼개지? 걱정하지 마세요 다 방법론이 존재함.

쪼개는법 : 후속수업 관계형 데이터 모델링 등.

 

(1)하나의 표로 만드는건 보기가 좋지만 수정을 하는게 너무 안좋고 - 읽기는 좋고 쓰기가 굉장히 나쁨

(2)쪼개져 있는건 쓰기가 폭발적으로 좋아졌지만 읽기가 너무 불편해. 한 컬럼에서 1인걸 보고 다른테이블가서 1을..

 

공학에서 고민하는 것은 trade off다 장단점을 갖고 있는 두 개 사이에서의 균형

공학의 지상과제 합성해서 마치 장점만 존재한것과 같은 환상을 만들어내는 것.

->그것을 할 수 있게 도와주는 것이 JOIN ∴ 평소에 쪼개놨다가 볼때 합치면 되겠다

 

JOIN :

잘 표를 분리한 다음에(방법론이 있다~)

필요할 때마다 순간순간 조립해서 마치 조립된 상태로 저장돼 있었던 것처럼 환상을 만들어내는 것

관계형 데이터베이스의 정말 중요한 기능

 

자세하게 하지만 적당히 설명할 것. 우리 수업의 위기인 부분. 설명을 듣고 자기가 설명해보세요 그래야 자기가 잘 이해하고 있는지 교차검증을 할 수가 있다

 

SELECT * FROM topic LEFT JOIN author

 : 토픽 테이블의 각각의 행 옆에다가 author테이블을 붙여줘 (LEFT가 기준 테이블, 왼쪽 테이블의 모든 행이 유지)

SELECT * FROM topic LEFT JOIN author ON topic.author_id = author.id;

 : 아무거나 옆에 붙는게 아니라 조건에 맞춰서 옆에 붙임. author_id 가 1인거에 id가 1인 행이 붙어야한다!

 

*테이블과 컬럼은 . 으로 이어진다

 

SELECT문을 쓸 때 JOIN을 사용하면 이렇게 저장된것과 같은 일루전을 만들 수 있다.

관계형 데이터베이스가 40년동안 DB시장을 지배할 수 있었던 어마어마한 기능.

SELECT*FROM topic LEFT JOIN author ON topic.author_id = author.id; - id컬럼 두번 중복. 따로 hr에서도 해보니 중복됨.

author_id 가 1인건 전부 1인것이 붙는다

 

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

@16.3.테이블의 분해 조립 - 분해 실행하기(sql developer활용)

16.2에서 손으로 써보면서 한걸 16.3~4에서 오라클갖고 실습하는것임, GUI 활용법

sql developer에서 테이블에 우클릭하고 뉴 테이블하면 테이블 생성 가능.

여기에서 PK 여부, 이름, 데이터타입, 사이즈, Not Null 다 지정해줄 수 있다

DDL을 누르면 방금한 그래피컬한 환경에서 한 일이 SQL문으로는 어떤 코드인가를 보여줌.

이러고 OK버튼 누르면 방금봤던 SQL문을 sql developer가 서버한테 전송을 해서 일을 하는 것.

 

또 테이블을 누르고, 컬럼스라고 돼 있는 탭을 클릭하고 밑에 수정버튼을 누르면 창이뜨고 +버튼을 누르면 컬럼 추가가 됨.

 

시퀀스 만드는것도 커넥션쪽 폴더같이생긴걸로 있음 현재 시퀀스 목록도 나옴.

 

테이블을 누르고 Data탭을 누르면 데이터를 추가할 수가 있음. - 여기서 시퀀스 객체 추가하는 방법이 있지만 이건 명령어가 더 편함.

계정에 우클릭하고 Open SQL Worksheet 누르면 명령어로 할 수 있음.(접속을 처음 했을 때 뜨는 흰바탕 명령어 쓰는 걔랑 똑같은 것)

 

sql developer 테이블누르고 데이터탭에서 더블클릭해도 수정할 수가 있다. 그 위에 commit버튼 있음 그거 눌러야 저장됨. 초록색 재생버튼이 컨트롤+엔터군

 

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

@16.4.테이블의 분해 조립 - 조립 실행하기 JOIN

연관된 다른 테이블의 프라이머리키 값을 적어놓은 컬럼을 foregin key라고 함.

FK라는 기능이 있기도 하지만 개념적으로도 있어 여기선 기능을 사용하진 않았음. --그러네 연결이 되는 값은 그곳의 PK겠구나

 

1.토픽테이블을 가져오는데

2.토픽테이블을 기준으로 오른쪽에다 author 테이블의 행을 옆에다가 붙일것임 ->LEFT JOIN이군요

ON 기준을 정하고, 그 기준에 일치하는(프라이머리키겠지) 행을 옆에 붙여줌.

  : 16.2에서 썼던 join문 설명

 

투 테이블의 컬럼 이름이 같을 땐 테이블.컬럼 이렇게 붙여주면 애매에러로부터 벗어남 select에서 쓸때도 마찬가지

다를땐 그냥 써도 되나보네 --어 해보니까 돼

 

별명도 설명함 그냥 옆에다 쓰면 되는거

 

표의 이름에 대한 별명도 정할 수 있네 오 그래서 그 별명으로도 별명.컬럼 이렇게 쓸 수가 있어

조인하는 문장의 테이블 이름에도 옆에 별명쓰면(예를들어 A) 그때부터 A.id 이런식으로 쓸 수 있어

컬럼 이름도 바꿀 수 있어 select topic.id TOPIC_ID 라고 하면 됨

id라고 써있으면 topic의 id인건 쓰는사람만 알았지만

저렇게하면 TOPIC_ID라고 표시해줌

 

SELECT ~ FROM ~ LEFT JOIN ~ ON ~여기에 WHERE 까지도 쓸 수 있음. 그럼 그 행만 나와

 

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

@17. 수업을 마치며

앞으로 여러분이 관심을 가져볼만한 주제를 소개해드리겠습니다.

 

관계형 데이터 베이스를 사용하는건 쉬운 일.

관계형 데이터 베이스를 잘 사용하는건 인생을 갈아넣어도 어려움.

현실의 문제를 관계형 데이터 베이스에 맞게 옮기는 것은 천재적인 엔지니어에게도 쉽지 않다.

▽코딩도 내 생각을 코드로 표현하는거잖아

관계형 DB의 선구자들은 천재가 아닌 사람들도 그들이 제시하는 방법론에 따르면 천재적인 표를 만들 수 있는 다양한 방법론들을 고안해놨음. 이런 방법론들을 잘 모아서 정리해둔 것인 관계형 데이터 모델링.

Relational Data Modeling 좋은 표를 만드는 표준화된 방법. 표에대한 시야가 획기적으로 넓어짐.

 

정보가 많아지면 원하는 정보를 찾는 것이 매우 어려워짐. 미래에 (정보가 많아져서)성능이 느려진다면

혹은 지금부터 미래를 대비하고 싶다면 INDEX라는 주제를 살펴보세요

INDEX는 데이터가 쓰여질때 미리미리 정돈을 해두는 것을 의미함. 이렇게 잘 정리정돈을 해두면 데이터를 읽을 때 놀라운 속도로 정보를 찾아낼 수 있습니다. 1시간짜리 읽기 작업을 1초에 끝낼 수 있는 마법임.

 

우리는 수업에서 데이터베이스를 있는그대로 사용했지만 실제론 직접적으로 DB만을 사용하는 경우는 거의 없다.

웹, 앱 등 장치들이 사용자의 금융정보나 작성한 글이나 장기간 만든 데이터를 DB에 보관함.

사용자가 사용하는 UI와 DB사이에 존재하는 다리역할을 하는 기술을 Middleware라고 함. DB의 기본 사용법을 배웠다면 Middleware의 사용법을 익히는것도 좋은 경로다. 

범 자바 진영의 JSP, Sevlet, Spring과 같은 것이 있고 

PHP, Python, Node-js, Ruby와 같은 기술들도 오라클의 미들웨어로 사용될 수 있습니다.