20.11.11. 오전 - 데이터베이스

vol1, p389

create table 서브쿼리 문장은,

컬럼이름을 가져올때 실제 구조 전체를 가져와서 출력을 하면 그대로 인서트로 보여준다.

create table 다음에 오는 as는 서브쿼리를 가져와라 라는 하나의 문법이다.

 

 

Q. 부서별 평균급여를 저장하는 AVGDEPT 테이블을 생성하시오.

부서번호는 DEPTNO, 평균급여는 AVGSAL로 저장하시오.

 

서브쿼리 실행했을때 그대로 테이블로 만들어진다.

 

기존 테이블을 가져와 쉽게 복사할 수 있다는 장점,

기존 테이블과 독립된 테이블로 인식이라는 단점.

 - 수시로 데이터가 변경되어야하는 경우 불편

이력성 데이터 = 히스토리컬 데이터

: 과거와 현재 데이터를 계속 누적시켜 비교가 가능함. 크기가 매우 큰 관계로 소멸을 언제 시켜야할지 판단을 잘해야함.

  평균 보관일자가 5년, 현업에서는 5년을 주기로 폐기를 함.

 

 

 

p390

교재엔 없지만, 컬럼의 이름도 하나씩 변경을 할 수 있다.

 

p391

역시 교재엔 없지만, alter table rename을 이용해 컬럼의 이름을 변경할 수도 있다.

 

p392

행 컬럼에 대한 순서는 크게 의미가 없다..

 

p393

컬럼이름, 데이터타입, 문자자릿수(길이)를 지정해주면 된다.

나는 dept 테이블에 job_id라는 컬럼을 varchar형태의 9자리로 저장하겠다고 알려주는 것.

 

이렇게 새로운 행이 추가되면 자동으로 null값을 넣어서 만들어준다.

 

어제 했던 것이 그냥 rollback 되었는지 없어졌다..ㅋㅋㅋㅋ

급하게 교수님이 추가해준 것 캡쳐!

자, job_id에 aaa를 넣어줘보자.

추가했고~

읭? 어디 갔어?

그 행에 안 가고 새로운 행에 추가된 모습.

 

업데이트로 해보자

자릿수를 조정해줘볼까요?

무난무난하게 잘 줄여지고 있는 모습

이미 우리는 job_id에 3자짜리가 저장되어있는데 2자리로 줄여버리면 데이터무결성에 해당하게 되므로 자릿수 변경을 할 수가 없다고 에러가 뜨게 된다. 마찬가지로,

number타입으로 변경도 안된다. 이미 문자타입의 데이터가 들어가있는 관계로 불가능하다고 에러를 띄운다.

 

p395

컬럼을 지울 때 사용된다.

drop 명령어는 취소가 되지 않으며 절대로 복구가 되지 않는 관계로 drop 명령어를 실행시킬 때는 꼭 생각해보고 실행하자. DDL명령어는 입력하면 바로 commit되므로 가장 위험함.

어제 우리가 수행했던 DML연산은 행에 rock을 건다. 그래서 행별로 다르게 동시 접근해서 작업을 할 수 있었음.

DDL연산은 테이블 전체에 rock을 건다. 내가 구조를 변경하고 있는 와중에 구조변경에 잘못된 트랜잭션이 들어오면 트랜잭션이 모두 의미가 없게 되므로 테이블 자체를 막아버리는 것.

실제로 물리적으로 지우는 동안 테이블에 rock이 걸려있는 관계로 크기가 크면 클수록 지우는데 시간이 오래 걸리다보니 동시성이 매우 떨어지게 된다. 이런 문제를 해결하기 위해 나온 것이 바로,

pp396

set unused이다. 정보변경이며 실제 물리적인 구조와 데이터는 남아있다.

데이터 딕셔너리에 상태정보를 unused로 바꿔서 인식 못하게 덮어버리는 것.

drop컬럼의 문제를 해결하기 위해 부랴부랴 나온 명령어가 unused이다 보니 used가 없다.

그럼? 문제가 발생하는데? - 공간 사용도 못하고 삭제도 못하고 애매하게 남아있게 되잖아!

 └ drop unused column 옵션을 사용해서 unused로 표시된 열을 제거할 수 있다.

이렇게 테이블을 없앨 수도 있다.

에잇! 그럼 스트레스 안 받게 departments 테이블도 지워버리자!

응 안돼~. 참조된 employees테이블이 있기 때문에 삭제할 수 없다.

하지만 부모테이블도 지울 수 있는 방법이 있는데.. 이건 추후에 알려드리겠습니다. (알아도 이건 지우지마ㅜㅜ)

 

p399

메모한것 정리하자(손메모)

 

p401

읽고 넘어가시죠.

 

p405

10장. 제약조건 포함

 

p407

낫널은 널이 들어오면 안돼. 당연한거 아냐?

유니크제약조건에서 null은 허용. ← 여러개 인식해준다.

포린키는 반드시 유니크나 프라이머리키여야지만 참조할 수 있다. 다른 키는 참조할 수 없음.

체크 제약조건은 조건에 맞는 것만 들어오게 하겠다.

 

컬렘에 설치한다고 말씀 드렸죠? 하나의 컬럼에 여러개의 제약조건을 설치할 수 있다. 복합으로 줄 수 있다는 뜻입니다.

 

p408

대부분은 테이블을 생성할 때 제약조건도 같이 생성하는게 다수입니다.

 

p409

create	table	test
a	char(3)	column 선언부
b	char(3)

test
(pk)a	char(3)
b	char(3)

constraint 이제부터 제약조건을 선언하겠다~

constraint 제약조건이름 제약유형 (column)

제약조건이름은 보통 현업에서 이렇게 쓴다 → test_col_약어

constraint test_a_pk　　 primary key(a)

 

자, 직접 만들어볼까요?

제약조건을 설치했으니 insert해볼까요?

선언됐죠~? 근데 이걸 또 누르잖아요?

프라이머리키가 실행되어서 딱 막아버립니다. 중복이 되면 안되니까 이벤트가 뜨는거죠.

 

아까 이야기했던 제약조건들은 컬럼레벨, 테이블레벨 상관없이 모두 선언할 수 있으나 그 중에서 오로지 not null조건은 컬럼레벨에서만 선언이 가능하다. 그러므로 우리 약속합시다. not null만 컬럼, 나머지는 모두 테이블에서 쓰는 것으로 정리하자구요.

컬럼들을 먼저 선언 후 not null만 옆에서 붙이고 나머지 명령어는 constraint에서 해줍시다!!

 

p418

내가 참조를 할 대상을 지정해줄 수 있다..

 

p422

add를 이용해서 조건을 추가해줄 수 있다.

 

p424

sql은 하나의 문장만 저장이 되지만 save는 여러개를 동시에 저장할 수 있습니다.

 

과거에 사용한 것을 재사용하는 방법

 

save 파일명.sql └ 이렇게 run sql에서 치면 파일이 생성되는데, 확인하는 경로는 C:\oraclexe\app\oracle\product\11.2.0\server\bin 이 경로를 찾아 들어가면 내가 저장한 파일명을 확인할 수 있다.

실행하면 내가 마지막으로 타이핑해서 실행했던 명령어가 뜨게 되는데,

마지막으로 했던 것이

이므로 메모장에

이렇게 써진 내용이 뜨게 된다.

그럼 여기에 내가 쓰고자 하는 내용을 쓰고 저장을 하면 이 파일은 꼭 닫기버튼을 누르지 않아도 run sql에서 바로 확인할 수 있다. 대신 작성할 때 꼭 실행될 수 있도록 실행할 부분마다 ;를 찍어주도록 하자.

그리고 실행하려면 @파일명.sql을 입력해주자.

이렇게 쫘라락~ 실행된 것을 볼 수 있다.

잘 만들어졌는지 확인하고 싶으면,

요러케. 확인이 잘 된다.

 

이번엔 다른 것을 해보자.

references를 통해 참조할 테이블명과 행이름을 써주면 포린키 연결이 된다.

 

잘 실행되어서 확인까지 잘되는 것을 볼 수 있다.

 

자, 이제 카톡으로 받은 파일을 열어서 실습해봅시다.

먼저 파일을 생성해주고 그 파일에 이걸 적어주세요.

 

cascade constraints를 사용하면 종속되어있는 포린키를 삭제함으로써 관계를 끊어버리는 역할을 한다.

그렇기 때문에 부모테이블도 지울 수 있게 되는 것.

 

내가 코드를 잘못 쓰면 에러가 뭘 틀렸는지 알려준다.

정상적으로 되면 이렇게.