3. 데이터베이스 구축 - 물리 데이터베이스 설계(스토리지 ~ 데이터베이스 품질 검토)
103. 스토리지
: 단일 디스크로 처리할 수 없는 대용량의 데이터를 저장하기 위해 서버와 저장장치를 연결하는 기술
- 스토리지의 종류
1. DAS (Direct Attached Storage)
: 서버와 저장 장치를 전용 케이블로 직접 연결하는 방식
- 서버에서 저장장치를 관리
- 직접 연결 방식 -> 다른 서버에서는 접근 불가, 파일 공유 불가
- 저장 데이터가 적고 공유가 필요 없는 환경에 적합한 방식
- 장점
- 저장 장치를 직접 연결해 빠른 속도 보장
- 쉬운 설치 및 운영
- 저렴한 초기 구축 및 유지보수 비용
- 단점
- 낮은 확장성 및 유연성
2. NAS (Network Attached Storage)
: 네트워크를 통해 서버와 저장 장치를 연결하는 방식
- 별도의 파일 관리 기능을 가진 NAS Storage가 내장된 저장 장치를 직접 관리
- Ethernet 스위치를 이용한 접근 -> 다른 서버도 접근 가능, 파일 공유 가능
- 장점
- 장소에 구애받지 않고 저장장치에 쉽게 접근 가능
- DAS에 비해 우수한 확장성 및 유연성
- 단점
- 접속 증가 시 성능 저하 위험
3. SAN (Storage Area Network)
: 서버와 저장 장치를 연결하는 전용 네트워크를 별도로 구성하는 방식
- 광 채널(Fiber Channel) 스위치를 이용해 네트워크를 구성
- DAS의 빠른 처리와 NAS의 파일 공유의 장점을 혼합한 방식
- 높은 트랜잭션 처리에 적합한 방식
- 장점
- 광케이블로 서버나 저장장치를 연결 -> 빠른 처리 속도
- 저장장치 공유 -> 여러 저장 장치나 백업 장비 단일화 가능
- 뛰어난 확장성, 유연성, 가용성
- 단점
- 비싼 네트워크 구축 비용
104. 논리 데이터 모델의 물리 데이터 모델 변환
: 논리적 설계 단계에서 설계한 엔티티, 속성, 식별자 등의 논리 데이터 모델을 테이블, 컬럼, 키 등의 물리 데이터 모델로 변환하는 과정
1) 엔티티 -> 테이블 변환
: 논리 데이터 모델인 엔티티를 물리 데이터 모델인 테이블로 변환
- 테이블 목록 정의서 : 엔티티에서 변환한 테이블 전체를 목록으로 요약, 관리하는 문서
- 변환 규칙
- 변환 시 고려 사항
- 일반적으로 테이블 명칭은 엔티티 명칭과 동일하게 적용
- 테이블 명칭은 소스 코드의 가독성을 위해 영문명 사용
- 메타 데이터 관리 시스템 내에 등록된 단어 사용
※ 메타 데이터 관리 시스템 : 메타 데이터를 수집하고 사용자들에게 제공하는 시스템
2) 슈퍼타입/서브타입 -> 테이블 변환
: 논리 데이터 모델에서 이용되는 슈퍼 타입/서브 타입을 테이블로 변환
1. 슈퍼타입 기준 변환
: 서브 타입을 슈퍼 타입에 통합하여 하나의 테이블로 변환
- 서브타입의 속성이나 관계가 적은 경우 적용
- 통합된 테이블은 모든 서브 타입의 속성을 포함
- 장점
- 데이터 접근이 용이
- 뷰를 이용해 각각의 서브타입에만 접근 및 수정이 가능
- 서브타입 구분이 없는 임의 집합 처리 용이
- 조인이 필요하지 않아 수행 속도 증가
- SQL 문장 구성이 단순함
- 단점
- 테이블 컬럼 증가 -> 디스크 공간 증가
- 처리마다 서브타입에 대한 구분이 필요한 경우 증가
- 인덱스 크기 증가 -> 인덱스 효율 감소
- 슈퍼타입 '회원' 개체를 기준으로 서브타입인 '판매자'와 '구매자' 개체를 통합
- 통합된 테이블 '회원'은 '판매자'와 '구매자'의 속성을 모두 포함
2. 서브타입 기준 변환
: 슈퍼타입의 속성들을 각각의 서브타입에 추가하여 개별적인 서브타입 테이블을 생성
- 서브타입에 속성이나 관계가 많이 포함된 경우 적용
- 만들어진 각각의 서브타입 테이블들은 슈퍼타입의 속성을 포함
- 장점
- 각 서브타입 속성들의 선택 사양이 명확한 경우 유리
- 처리할 때마다 서브타입 유형 구분이 필요없음
- 테이블당 크기가 작음 -> 전체 테이블 스캔 시 유리
- 단점
- 수행 속도 감소
- 복잡한 처리 SQL의 통합이 어려움
- 부분 범위에 대한 처리가 어려움
- 서브타입 테이블을 통합한 뷰는 수정이 불가, 조회만 가능
- 식별자의 유지 관리가 어려움
- 서브타입인 '판매자'와 '구매자' 개체별로 테이블을 생성
- 만들어진 각각의 테이블은 슈퍼타입인 '회원'의 속성을 모두 포함
3. 개별타입 기준 변환
: 슈퍼타입과 서브타입들을 각각의 개별적인 테이블로 변환
- 만들어진 슈퍼타입 테이블과 서브타입 테이블 간에는 1:1 관계가 성립
- 개별타입 기준 변환을 적용하는 경우
- 전체 데이터에 대한 처리가 빈번
- 서브타입의 처리가 대부분 독립적
- 통합하는 테이블의 컬럼 수가 많음
- 트랜잭션이 주로 슈퍼타입에서 이루어짐
- 슈퍼타입의 처리 범위가 넓고 처리가 빈번하게 발생 -> 단일 테이블 클러스터링이 필요
- 장점
- 저장 공간 소모가 적음
- 슈퍼타입, 서브타입 각각의 테이블 정보만 조회하는 경우 문장 작성이 용이
- 단점
- 슈퍼타입, 서브타입의 정보를 함께 처리하면 매번 조인 연산이 발생해 성능 저하
- 슈퍼타입인 '회원'과 서브타입인 '판매자'와 '구매자'를 각각 테이블로 변환
3) 속성 -> 컬럼 변환
: 논리 데이터 모델인 속성을 물리 데이터 모델인 컬럼으로 변환
- 변환 규칙
- 변환 시 고려 사항
- 속성과 컬럼은 표준화된 약어를 통해 가능한 한 명칭을 일치
- 컬렴명에 SQL 예약어 사용을 피함
- 컬럼명은 가독성을 위해 가능한 짧게 지정
- 복합 단어를 컬럼명으로 지정할 때는 표준을 사용
- 컬럼 정의 후 row에 해당하는 샘플 데이터를 작성하여 컬럼의 정합성 검증
4) 관계 -> 외래 키 변환
: 논리 데이터 모델에서 정의된 관계를 기본 키와 이를 참조하는 외래 키로 변환
- 개체 A:B의 관계에 따라
- 1:1 관계 : A(B)의 기본 키를 B(A)의 외래 키로 추가하여 표현
- 1:M 관계 : A의 기본 키를 B의 외래 키로 추가하여 표현
- M:N 관계 : 릴레이션 A와 B의 기본 키를 모두 포함하는 교차 릴레이션을 생성하여 표현
- 1:M 순환 관계 : 테이블 내에 자신의 기본 키를 참조하는 외래 키 컬럼을 추가하여 표현
5) 관리 목적의 테이블/컬럼 추가
: 논리 데이터 모델에는 존재하지 않지만 데이터베이스의 관리 또는 수행 속도 향상을 위해 물리 데이터 모델에 테이블, 컬럼 등을 추가
6) 데이터 타입 선택
: DBMS의 물리적 특성 및 성능을 고려하여 논리적 데이터 모델의 데이터 타입을 물리적 데이터 타입으로 변환
- 데이터의 길이와 최적의 데이터 타입 선택
- Oracle에서 자주 사용되는 데이터 유형
- CHAR : 고정 길이 문자열 (최대 2000Byte)
- VARCHAR2 : 가변 길이 문자열 (최대 4000Byte)
- NUMBER : 38자릿수까지의 숫자
- DATE : 날짜
105. 물리 데이터 모델 품질 검토
: 물리 데이터 모델 설계 및 데이터베이스 객체 생성 후 개발 단계로 넘어가기 전에 이해관계자들이 모여 물리 데이터 모델의 품질을 검토
- 물리 데이터 모델은 시스템 성능에 직접적인 영향을 미치므로 면밀한 검토필요
- 데이터베이스의 성능 향상과 오류 예방이 목적
- 모든 이해 관계자가 동의하는 검토 기준 필요
- 품질 검토 기준에 따라 각 물리 데이터 모델의 구성 요소에 대한 검토 항목 작성 (테이블, 컬럼, 무결성 제약 조건, etc)
- 물리 데이터 모델 품질 기준
- 정확성 : 요구사항, 업무 규칙, 표기법 등에 따라 정확하게 표현되었음
- 완전성 : 데이터 모델 구성 요소를 누락 없이 정의하고 요구사항을 누락 없이 반영함
- 준거성 : 데이터 표준, 표준화 규칙, 법적 요건 등을 정확히 준수함
- 최신성 : 최근의 이슈나 현행 시스템, 최신의 업무 변화 등을 반영함
- 일관성 : 표현상 일관성을 유지함
- 활용성 : 작성된 모델을 사용자가 쉽게 이해 및 사용할 수 있고, 업무 변화에도 데이터 구조 변화가 최소화될 수 있음
- 물리 데이터 모델 품질 검토 순서
- 데이터 품질 정책 및 기준 확인
- 물리 데이터 품질 특성에 따라 품질 기준 작성
- 품질 기준에 따라 체크리스트 작성
- 논리 데이터 모델과 물리 데이터 모델 비교
- 품질 검토 수행
- 작성한 체크리스트 내용을 종합하여 품질 검토 보고서 작성