스키마 디자인 기본 원칙 (by joang77) [2009.11.24]
1. 데이터 무결성은 데이터베이스에 맡기기
무결성 정의
- 무결성(Integrity) = 정확성(정합성) + 일관성
- 일관성(consistence) : 중복 데이터로 인해 일관성이 깨질 수 있다.
- 무결성을 유지하기 위해서는 반드시 key가 있어야 함
- 참조무결성(Referential Integrity) : 외래키(Foreign Key)는 null일 수 없으며, 부모키에 없는 값(즉 참조할 수 없는 값)을 가질 수 없다.
Date의 데이터베이스 특징 : 통합과 공유
- 데이터베이스란 서로 관련 있는 데이터를 최소한의 중복으로 통합해서 여러 사용자가 사용할 수 있도록 해야 한다.
- 일반적으로는 데이터 항목의 각 값이 데이터베이스에 중복 없이 한번만 기록될 때 데이터의 일관성을 유지되는데, 이처럼 중복 없이 데이터를 한번만 기록하기 위한 데이터베이스의 설계 이론을 정규화(normalization)라고 한다.
- 경우에 따라서는 처리 속도의 향상을 위해서 특정 데이터 항목의 값을 중복해서 기록할 수 있지만, 예외적인 경우이다. 이런 경우에도 데이터베이스 시스템이 데이터의 중복을 통제하도록 설계해야 한다.
- 예를 들어 고객의 주소를 부득이하게 두 군데 기록했다면, 그중 하나의 주소가 변경되면 다른 주소도 자동으로 변경되게끔 만들어야 한다는 것이다.
- 데이터의 중복이 있더라도 미리 계획된 것이고, 일관성을 유지할 수 있는 대책이 마련되어 있다면 이를 '통제된 중복'이라고 부른다.
- 그러나 불가피한 경우를 제외하고는 중복을 만들어 통제하기보다 아예 중복이 없게끔 만드는 것이 데이터베이스 설계의 철학임을 다시 강조한다.
- 데이터베이스는 모든 사용자가 동일한 데이터를 사용하기 때문에 일단 잘못된 데이터가 저장된다면 심각한 피해가 발생한다. 따라서 입력 데이터에 대한 철저한 오류 검사를 하도록 데이터베이스를 설계해야 한다. 데이터가 오류가 없는 상태를 데이터 무결성이라고 하는데, 데이터베이스에는 데이터 무결성을 위해 여러 제약을 가할 수 있는 기능이 있다.
무결성을 유지하기 위해서는 무결성 규칙은 DBMS에서 관리해야 한다
- 클라이언트가 무결성을 검사 할 경우 장점
- end-user가 우수한 사용자라면 입력한 데이터가 DB에 들어갈 가능성이 없다는것을 알기 때문에 저장을 선택하기까지 기다릴 필요가 없다.
- 서버의 리소스 사용량 감소
- 클라이언트가 무결성을 검사 할 경우 단점
- 변경관리가 쉽지 않다
- QUERY REWRITE 기능 : 테이블 사이의 관계, NOT NULL 컬럼, 기본 키 등을 알지 못하면 이 기능을 사용할 수 없다
- 데이터 무결성 손상 : DB 밖에서 외래키 제약조건을 시행하도록 하는 시스템은 Foreign Key에 null 혹은 참조할 수 없는 값(부모키에 없는 값)이 있을 수 있다.
- 무결성과 속도 : 데이터의 무결성을 보장하기 위해서는 서버에서 별도의 과정을 거치지만, 애플리케이션보다 빠르며 애플리케이션에 상관없이 일관되게 적용되므로 DBMS에서 실행되는것이 더 빠르다.
- DBMS의 정보 제공 : DBMS는 데이터의 무결성을 유지하기 위해서 많은 정보를 저장한다.
- ex) A 테이블과 B테이블의 관계 정의 : A.id는 Foreign Key인데, 부모키는 B.id(B테이블에서 primary key)이다.
제약조건(Constraints)과 DML
| 구분 | Primary Key | Foreign Key | Not Null | Unique | Check |
|---|---|---|---|---|---|
| Insert | Null 불가 중복 값 불가 | Parent 테이블에 값이 있어야만 child 테이블에서 값을 삽입 가능 | Not null 조건 이 있을 때 : Null 불가 | 중복 값 불가(모든 로우는 null값 가질 수 있다) | 데이터 유효성 여부 확인 |
| Update | Null 불가 중복 값 불가 | 부모 테이블에 값이 있어야만 자식테이블에서 값을 수정 가능 | Not null 조건 이 있을 때 : Null 불가 | 중복 값 불가(모든 로우는 null값 가질 수 있다) | 데이터 유효성 여부 확인 |
| Delete | child 테이블에 삭제하려는 값이 존재하고 있는 상태라면 parent 테이불에서는 삭제 불가능 |
- Fig. Constraints and DML
- (관련 참고 자료 : 10g Admin 스터디 발표자료(데이터 관리))
2. 올바른 데이터 유형 사용하기
다른 데이터 유형으로 입력 되었을 때 문제점
- 성능 저하
- 필요한 저장소(storage) 증가 : 필드의 길이가 반드시 최대 길이로 정의될 이유는 없다.(공간의 낭비 발생)
- 데이터 무결성 깨짐
- DB에 삽입되는 순간 날짜가 실제로 날짜이고, 수가 유효한 수라는 것을 검증하는 단계에서 에러 발생
- 데이터 타입과 잘못 사용시 에러 발생 테스트
- ex) ORA-01722:invalid number(데이터 타입이 일치하지 않았을 경우 발생)
- Fig. ORA-01858 : to_date(ctime,'YYYY/MM/DD')로 바꿈
날짜 타입
1) 날짜나 수에 문자열로 정의된 컬럼 : date, timestamp 유형외 다른 문자열을 허용했을 때 데이터가 잘못 저장될 수 있음
2) 이유 : 성능을 최적화하고 데이터 무결성을 보호하기 위함
성능 저하 테스트
- 저장소 증가 테스트
3. 가장 빈번하게 사용되는 query 최적화하기
- 목적 : 스캔 대상 데이터를 최소화하고 사용자가 받을 데이터의 양을 제한하여 속도 향상
- Point : 시스템 개발 시 end-user가 개발 대상 시스템을 어떻게 사용할 것인지 고려해야 하며, 물리적인 구조 및 논리적인 IO의 100% 증가가 시스템 성능에 영향을 미친다는 점을 기억하자!!