초보 개발자의 프로그래밍 공부방

- JOIN -

하나이상의 테이블로 부터 연관된 테이블(컬럼)을 검색할 수 있는 방법이다.

또한 JOIN에서 ON과 WHERE의 차이점은 JOIN하는 범위가 다르다.

또한 PK(PrimaryKEY) & FK(Foreign KEY)의 값에 연관에 의해 보통 JOIN이 성립하지만,

어떤 경우에는 이러한 PK,FK 관계가 없어도 논리적인 값들의 연관만으로 JOIN이 성립되기도 한다.

- JOIN의 종류 -

- EQUIJOIN : column 간의 값들이 서로 정확히 일치하는 경우에 사용, 일반적으로 PK, FK 관계에 의함

- NON-EQUIJOIN : 한 컬럼의 값이 다른 컬럼의 값과 정확히 일치하지 않는 경우에 사용

- OUTER JOIN : JOIN 조건을 만족하지 않는 경우에도 모든 행들을 다 보려는 경우에 사용

- SELF JOIN : 같은 테이블에 있는 행들을 JOIN 하고자 하는 경우에 사용

JOIN에 대한 조건이 생략되거나 잘못 기술되면, 한 테이블에 있는 모든 행들과 JOIN되고,

이런 결과를 Cartesian product (모든 케이스가 다 JOIN 되는 것) 이라고 하는데, 이런 상황을 방지하기 위해서는 반드시 JOIN시에 WHERE를 써야 한다.

1. EQUIJOIN

서로 다른 테이블에서 같은 값을 이용해 데이터를 출력한다.

EQUIJOIN(INNER JOIN)의 기본 구조

2. NON-EQUIJOIN

연산자 외에 다른 연산자를 사용하여 조인하는 방법이다.

즉 한 컬럼의 값이 다른 컬럼의 값과 정확히 일치하지 않는 경우 '=' 연산자 외의 다른 연산자를 사용하여

JOIN하는 방법을 말한다. 즉, 정확한 값의 비교가 아니라 값의 범위를 비교해야 할 때 사용한다.

3. OUTER JOIN

OUTER JOIN을 하는 경우에는 (+) 연산자를 사용한다.

(+)를 사용하는 위치는 JOIN할 데이터가 부족한 쪽 (즉, 상대 테이블과 비교할 데이터가 존재하지 않는쪽) 에 위치시킨다.

(+)는 WHERE절에서 비교연산자 기준으로 좌변 또는 우변의 어느 한쪽에 위치 시킨다.

OUTER JOIN에서 IN이나 OR을 사용할 수 없다.

4. SELF JOIN

하나의 테이블을 마치 여러개인 것처럼 사용할 수 있다.

반드시 테이블에 대한 ALIAS를 각기 다르게 지정해야 한다.

칼럼의 이름 앞에 반드시 테이블의 ALIAS를 붙여야 한다.

SELF JOIN의 횟수는 제한되어 있지 않다.

SET 연산자의 종류

UNION : 각 QUERY 결과의 합집합

UNION ALL : 각 QUERY 결과의 합집합에 공통부분을 더함

INTERSECT : 각 QUERY결과의 교집합

MINUS : 첫번째 QUERY 결과와 두번째 QUERY 결과의 차집합

첫번째 SELECT 구문에서 기술된 컬럼들과 두번째 SELECT 구문에서 기술된 컬럼들은 그 개수와 타입이 일치해야 한다.

FROM절 뒤에 기술된 테이블은 서로 다를 수도, 같은 수도 있다.

컬럼 HEADING는 첫번째 SELECT 구문의 컬럼명이 출력된다.

ORDER BY 절은 마지막에 한번만 기술한다.

출처 : https://songc92.tistory.com/43

Oracle에는 순위를 매길수 있는 여러가지 함수가 있습니다.

RANK 함수 문법

SELECT 컬럼1, 컬럼2, 컬럼3, RANK() OVER (ORDER BY 기준_컬럼 DESC) AS 별명 FROM 테이블;

DENSE_RANK 함수 문법

SELECT 컬럼1, 컬럼2, 컬럼3, DENSE_RANK() OVER (ORDER BY 기준_컬럼 DESC) AS 별명 FROM 테이블;

ENSE_RANK 함수 문법

SELECT 컬럼1, 컬럼2, 컬럼3, ROW_NUMBER() OVER (ORDER BY 기준_컬럼 DESC) AS RANK FROM 테이블;

ENSE_RANK 예시

게시판에 있는 글들을 추천수 상위 10개만 뽑아서 출력하고 싶을 때 사용하는 쿼리

'

출처

http://blog.naver.com/PostView.nhn?blogId=nomadgee&logNo=220854618303

1. SQL Developer 을 실행해서 도구 -> 데이터베이스 export를 선택

2. sqldeveloper에 등록해둔 계정(schema) 중에서 작업할 계정을 선택

3. DDL export 부분을 체크하면 스크립트가 만들어지는데 고려해야될 사항들이 몇가지 있다.

4. 데이터 export 부분을 체크하고 설정합니다. 형식에는 다음과 같은 종류가 있습니다.

5. 다른 이름으로 저장 (V) 을 선택합니다. 다음과 같은 종류가 있습니다.

7. 인코딩 유형은 백업일 경우 현재 데이터베이스의 캐릭터셋에 맞추고 옮기는 경우는 대상 데이터베이스의

캐릭터셋에 맞추면 되겠습니다.

8. 파일(F) 항목에서 생성될 파일 이름을 저장합니다. insert 형식에서 단일 파일로 저장할 경우 파일명을 지정하고,

별도의 파일이나 유형 파일을 사용할 경우에는 폴더를 지정합니다.

9. 다음 단계는 export 단계로 표준객체 유형에서 export 할 항목만 체크하면 됩니다.

10. 다음으로 export할 객체를 지정하는 단계이다.

상단의 조회를 눌러서 보여지는 리스트중에서 선택하고, 화살표를 사용해서 export할 자료를 선택하면 된다.

11. 다음 단계는 테이블 데이터중에 특정열을 선택해서 export할 수 있는데, 테이블의 열 항목을 클릭하면

연필 모양의 아이콘이 생기는데 거기서 export할 열을 선택할 수 있습니다.

따로 선택하지 않았을 시에는 전체 export가 됩니다.

12. 완료를 눌러서 export를 하면 된다.

import 하는 방법

만들어진 sql파일을 그대로 드래그해서 insert를 하면 된다.

출처

https://offbyone.tistory.com/162

출처

https://offbyone.tistory.com/162

1. 자연키 (Natural Key)

회원테이블을 만든다고 가정해보자.

이 테이블에서는 각 회원 테이블의 속성을 추출해냈고,  추출한 속성들중 가장 기본키로서 효율적인 속성을 골라내어

기본키로 설정하기로 했는데, 기본키만을 위한 데이터가 아니라 비즈니스 모델에서 자연스레 나오는 속성으로 기본키를 정한다고해서

자연키(Natural Key)라고 표현.

이 테이블에서 기본키 (자연키)는 회원ID이고, 다른 속성들은 중복되거나 변경되거나 

NULL값 등등이 나올수도 있기 때문에 기본키가 되기에 적합하지 않다.

2. 인조키 (Artificial Key)

앞선 내용에서는 회원이라는 내용을 가지고 테이블을 설계했는데, 보통 회원이라는건 가입자한테 그 사실을 알려주고 

(DB차원에서 기본키랑은 상관없이) 그 회원의 고유한 값을 전달해주게 된다. 거기서 자연스레 고유한 값은 ID가 추출됐고, 그걸 기본키로

설정한것이다. 그럼 비슷한 데이터지만 회원과는 조금 다른 테이블을 설계해보자.

이벤트 참여 개인정보를 제공받는 테이블이다.

회원 테이블과 거의 동일하다.

하지만 이벤트 참여를 받을땐 참여자로부터 고유한 값을 입력받지 않는다.

때문에 앞선 회원 테이블의 ID와 같은 고유한 값이 없다.

입력받는게 없다면 부여하면 된다. (예를 들면 카페에서 커피를 시킬때 번호표를 받는것처럼.....)

우리가 부여한 "참여자 번호" 로 인해 우리는 참여자가 몇명이든 그들을 구분할 수 있는 속성을 갖게됐다.

DBMS적인 측면에서 본다면 Oracle의 Sequence, MySQL의 Auto Increment라고 보면된다.

비즈니스 모델과는 달리 키를 위한 데이터라는 측면에서 인조키 (Artificial Key) 라고 부른다.

출처

https://multifrontgarden.tistory.com/180?category=471242

1. 외래키 (Foreign Key)

아래와 같이 상품테이블과 주문테이블이 있다고 가정했을때, 하나의 상품은 여러 주문에서 구매할 수 있고, (재고가 있을시)

하나의 주문은 여러 상품을 구매할 수 있다.

다대다 (N : M) 관계라는 뜻이다.

ERD 상으로는 이렇게 그릴 수 있지만 다대다 관계는 중간에 관계 테이블을 추가해서 사용한다.

주문_상품이라는 관계 테이블을 추가했다 (주문 테이블에 속성도 추가) 주문_상품 테이블은 각각 상품 테이블과 일대다, 주문 테이블과

다대일 관계를 갖고있다. 주문_상품이 없는 상품은 존재할 수 있지만 주문_상품이 없는 주문은 존재할 수 없다.

주문_상품 테이블은 관계 테이블로서 주문번호와 상품번호를 갖고 있다. 상품번호와 주문번호는 각각의 테이블에서는 기본키였지만

주문_상품테이블에서는 관계를 찾아가기위한 참조키로서 외래키 (Foreign Key)라고 부른다.

2. 식별관계 (Identifying Relationship)

위에 있는 주문테이블을 보면 속성중에 회원 ID가 존재한다.

회원 ID는 ERD상에는 나타나지 않은 회원 테이블의 기본키이며, 주문테이블이 외래키로 갖고있는 것이다.

즉 주문 테이블도 회원과의 관계를 이미 지니고 있는 것이다.

다시말해서 주문_상품 테이블도 테이블이니 기본키가 필요하다는 것이다.

주문번호와 상품번호, 단독으로는 기본키가 될 수 없지만 두 키를 합친 복합키라면 기본키가 될 수 있다는 것이다.

기본키는 2개 이상의 컬럼 (속성) 으로 구성되는 것도 가능하고, 외래키가 기본키가 되는것도 충분히 가능하다.

이렇게 외래키를 기본키로 사용하는 관계를 식별 관계 (Identifying Relationship) 이라고 한다.

3. 비식별관계 (Non Identifying Relationship)

위에서 알아본 관계는 하나의 주문에서 같은 상품을 2개 이상 사는 경우는 고려하지 않았다.

만약 주문번호 1001 주문에서 상품번호 1001, 1001, 1002 상품을 구매한다면 주문번호와 상품번호로 기본키를 구성할 수 없게 된다.

(실제로는 상품개수라는 속성을 추가해서 개수로 관리한다.)

이럴때는 인조키를 사용하면 된다.

외래키들을 기본키로 사용하지 않고 일반 속성으로 취급하는 관계를 비식별관계라고 표현한다.

ERD에서 비식별 관계는 관계를 점선으로 표시한다.

관계 테이블에서는 식별 관계보다는 인조키를 이용한 비식별 관계를 권장한다.

출처

https://multifrontgarden.tistory.com/181?category=471242