<목차>
ㅇ 객체
ㅇ 테이블 이름 지정 규칙
ㅇ 데이터 타입
ㅇ 9장 : 테이블 생성 및 관리 DDL
ㅇ 객체
- db 내에는 테이블과 같이 구조를 가진 애들이 있어
- DDL은 이런 객체들을 생성하고 수정하고 삭제하는 명령어
- 뷰 (다음 주 월요일)
- 데이터의 액세스를 제어하는 목적으로 만들어진 객체
- employees라는 테이블은 모~든 사원의 정보가 저장되어 있잖아. 10번 부서에 근무하는 사원들은 20번 부서에 근무하는 사원들 정보 보면 안 돼
(테이블을 사용하면 다 보게 돼) - 뷰를 통해 보면 10번만 제한해서 보게 해
- 보안과 관련이 있는 객체. 자주 사용돼
- 시퀀스
- 중복되지 않은 번호를 자동으로 생성. 1, 2, 3 ~ 이렇게
- 특히 프라이머리 키 지정할 때 이 객체를 자주 사용
( 앞의 3개는 반드시 숙지해야 해 )
- 인덱스 : 데이터 검색 속도를 빠르게 하기 위한 방법
- 튜닝과 관련 있는 객체야
- 튜닝의 원래 개념은 문제가 일어나기 전에 사전에 개선해주는 행위야
- 동의어 - 몰라도 돼 (emp 말하는 거야)
ㅇ 테이블 이름 지정 규칙
- 테이블을 만든다라는 건
1 테이블 이름 결정
2 테이블의 구성요소인 컬럼들의 이름 지정
3 컬럼들의 데이터타입과 길이를 지정 
- 문자로 시작 : 숫자나 특수기호 시작하는 건 안 돼
- 최대 30자까지
- 특수기호는 _ $ # 만 가능
한글도 가능하긴 하지만 권장하진 않아
(영어는 알파벳 하나 저장할 때 1바이트 할당
한글은 2바이트 할당. 받침이 있어서) - 한 계정 내에 똑같은 테이블, 컬럼 존재할 수 없어
- 테이블이 다르면 같은 이름의 컬럼 존재할 수 있어
- 예약어 : SELECT, FROM 같은 거
ㅇ 오라클 테이블은 2가지
- 사용자 테이블 유저테이블 - 우리가 사용했던
- 데이터 딕셔너리
- 모든 정보들이 메타데이터 형태로 데이터 딕셔너리에 저장되어 있어
- 메타데이터 : 하나의 물리적인 데이터에 관련된 모든 정보들
- 예) 101번 사원이 어느 테이블에 저장되어 있고, 얼마만큼의 사이즈를 사용하고 있고, 누구의 소유인지
- 뇌에 해당하는 부분이고 오라클 서버가 자동으로 생성하고 관리
- 우리가 손댈 수 있는 공간 아냐
ㅇ 데이터 유형
- 앞의 4개가 자주 사용하는 것 : 문자, 숫자, 날짜
- 뒤에는 사이즈가 큰 데이터 처리하는 타입들
- BFILE(비파일) : 멀티미디어 처리할 때 많이 사용
- 외부에 데이터 넣어두고 테이블에는 포인터만 위치시켜주는 (링크처럼)
- ROWID(로우아이디) : 인덱스라는 객체가 사용
- 행의 주소 정보 저장 (아파트 101동 101호처럼)
- 데이터가 실제 저장되어 있는 물리적인 주소
ㅇ 문자데이터 : CHAR, VARCHAR2
ㅇ CHAR(캐릭터) : 고정길이
ㅇ VARCHAR2(베리어블캐릭터) : 가변길이
-
aaa를 저장하려 할 때
- char(5) : 공간을 미리 5개로 만들어둬. 공간을 먼저 할당하고 aaa를 저장. 남은 공간 재사용 안 해
성능은 얘가 월등
돈 많은 회사. 돈으로 공간 늘려버리면 돼..ㅋㅋ - 들어오는 데이타 별로 할당
공간활용도는 얘가 월등. 성능은 떨어져
돈 없는 회사 ㅋㅋㅋ
- char(5) : 공간을 미리 5개로 만들어둬. 공간을 먼저 할당하고 aaa를 저장. 남은 공간 재사용 안 해
-
CHAR가 성능이 좋은 이유
- 베리어블은 들어올 때마다 공간 할당되니까 (공간 사용에 대한 정보가 변경되니까)
데이터딕셔너리 정보가 끊임없이 갱신돼 - 캐릭터는 미리 공간을 쪼개놔서
디스크에 접근해서 공간에 대한 정보가 변경될 일이 없어
- 베리어블은 들어올 때마다 공간 할당되니까 (공간 사용에 대한 정보가 변경되니까)
-
CHAR 사용할 때 자릿수 신중하게 정하기
- 주민번호 저장하려고 하는데 100자리로 지정해버리면
15자만 사용하니까 85자씩 공간 낭비 - 물론, 나중에 앨터로 사이즈 변경할 수는 있어
- 주민번호 저장하려고 하는데 100자리로 지정해버리면
-
가장 이상적인 사이즈는 실제 입력 데이터 보다 20%크게
디비의 확장성 개념으로
ㅇ 숫자 데이터 : number, number(p), number(p, s)
- number : 음수부터 0, 양수까지 다 사용
- 가변 값이 너무 커버려. 많이 사용하진 않아. 저장공간 성능 떨어져
- number(p) : 정수만 사용
- number(p,s) : 두번째자리까지는 소수점 사용. 소수점까지 가능해서 가장 많이 선호
날짜 데이터 : date, timestamp
-
date : 연/월/일이라는 날짜값 저장
- 날짜값이 출력이 되는 기본 형식은 언어체계를 뭘 쓰냐에 따라 달라짐 (한글, 영어 등등)
-
문제점
- 입력한 그대로 반영되므로 시차 문제 생김
- 밀레니엄 이슈 : 1901년을 01로 저장하면 2001도 01인 것 문제되지 않을까?
실제로는 문제 일어나지 않음! 1999년 12월31일 11시 59분.... 아무 이상이 없이 잘 넘어갔어 - 어쨌든 문제 일어날까봐 여러 데이터 타입들이 나왔는데 그 중 타임스탬프가 이제 많이 쓰임
-
timestamp : 시간/분/초까지 저장
- 데이터타입을 타임스템프로 해둔다면 sysdate가 시간/분/초까지 볼 수 있음
CF. '01/01/01'을 날짜vs문자 데이터에 입력했을 때 차이
- 날짜데이터date로 저장
- 숫자number로 변환해서 저장 돼
- 문자데이터char로 저장
- 문자char로 저장
- (숫자이지만) 아스키코드로 변환해서 문자로 저장
cf. 디스크에 대한 이해
- 디스크(저장공간)는 블럭으로 구성되어 있어. 처음 만들어져 있으면 깨끗하게 비어있는 공간
- 디스크는 순차적으로 채워서 저장 (디스크는 일반적으로 검색방식을 순차 검색을 해)
- 30 찾기 위해 3개 블럭 읽어 들여야 해 (10 아니네 20 아니네 30 오케이)
- 시스템에는 업데이트 기능 없어. 얘는 딜리트랑 인서트밖에 없어. 변경시키는 게 없어
20을 50으로 변경 = 20을 삭제 & 50은 맨 뒤에 추가
20 있던 공간 비어있어 -> 디스크 조각
- 사용하다보면 디스크 조각이 생겨서 읽어들일 블럭의 수가 많아져
이런 애들을 회수해서 빈 공간에 합쳐주는 게 디스크 조각모음
(그래서 윈도우 성능 느려지면 디스크 조각모음 하는 거야) - 실제로 데이터베이스 내에서 공간이 할당되면 그 사용공간에 대한 정보가 데이터 딕셔너리에 저장 (file 이라는 형태로)
내가 10을 써서 사용 가능 공간이 90이 되면 그 정보도 저장
공간이 할당될 때마다 공간이 ㅇㅇ개 됐다고 계속 정보가 갱신되어야 해 - 그래서 트랜잭션도 일괄처리 하는 거야
인서트 시킬 때마다 저장하면 그 저장 정보 I/O가 얼마나 많이 발생하겠어~
그래서 일괄처리 하면 I/O가 좋아져
그래서 트랜잭션은 시스템의 저장공간 활용도 측면까지 고려해서 만들어진 개념이야
STEP BY STEP