데이터 모델링(Data Modeling)
- 현실 세계를 데이터베이스로 표현하기 위해 추상화 하는 것
- 고객의 업무 프로세스를 이해하고 고객이 이해하기 편하게 모델링해야한다.
- 데이터 모델링은 추상화해야 한다. → 공통적인 특징을 찾고 간략하게 표현한다.
- 데이터 모델링은 단순화해야 한다. → 복잡하지 않게 누구나 이해할 수 있게 표현한다.
- 데이터 모델링은 명확해야 한다. → 해석이 모호하지 않고 명확하게 해석되어야 한다.
데이터 모델링 단계
- 개념적 모델링(Conceptual Data Modeling)
- 고객의 비즈니스 프로세스를 분석하고 업무 전체에 대해 모델링을 진행
- 업무적 관점으로 중요한 부분만 기술적 용어를 자제하며 진행
- 엔티티, 속성, ERD를 작성
- 논리적 모델링(Logical Data Modeling)
- 개념적 모델링을 논리적 모델링으로 변환하는 과정
- 릴레이션을 정의하고 정규화를 수행한다.
- 물리적 모델링(Physical Modeling)
- 성능, 보안, 가용성 등을 고려하여 실제 데이터베이스를 구축한다.
ERD(Entity Relationship Diagram)
- 엔티티를 도출하고 그린다.
- 엔티티를 배치한다.
- 중요한 엔티티를 좌측 상단에 배치
- 엔티티 간의 관계를 설정한다.
- 관계명을 서술한다.
- 관계 참여도를 표현한다. (1-N, N-M, …)
- 관계의 필수 여부를 표현한다. (종속 여부)
고려사항
- 정규화를 통해 중복된 데이터를 제거하여 모델의 독립성을 확보
- 고객과 소통을 위해 요구사항을 간결하고 명확하게 표현
- 데이터 표준을 정의하고 관리하여 데이터 품질 향상
3층 스키마(3-Level Schema)
- 사용자, 설계자, 개발자가 각 관점에 따라 관계를 정의한 ANSI 표준
- 데이터베이스의 독립성을 확보하기 위한 방법
- 각 계층을 View라고도 한다.
- 외부 스키마(External View) : 사용자 관점, 응용 프로그램이 접근하는 DB를 정의
- 개념 스키마(Conceptual View) : 설계자 관점, 통합 DB 구조(DB 내의 규칙과 구조)
- 내부 스키마(Internal View) : 개발자 관점, 물리적 저장 구조(레코드, 필드, 인덱스 등)
- 논리적 독립성 : 개념 스키마가 변경되도 외부 스키마가 영향을 받지 않는 것
- 물리적 독립성 : 내부 스키마가 변경되도 개념 스키마가 영향을 받지 않는 것
구성요소
- 엔티티(Entity)
- 저장되고 관리되어야 하는 데이터 집합
- 특징
- 유일한 식별자가 있어야 함
- 2개 이상의 인스턴스가 있어야 함
- 반드시 속성을 지님
- 다른 엔티티와 최소 한 개 이상의 관계를 지님
- 업무에서 관리되어야 하는 집합
- 유-무형에 따른 종류
- 유형 엔티티 : 지속적으로 사용되는 엔티티(고객, 강사, 사원 등)
- 개념 엔티티 : 물리적 형태가 없는 엔티티(주식 종목, 보험 상품 등)
- 사건 엔티티 : 비즈니스를 실행하며 생성되는 엔티티(주문, 체결 등)
- 발생 시점에 따른 종류
- 기본 엔티티 : 키 엔티티라고도 하며 타 엔티티에 영향을 받지 않고 독립적으로 생성되는 엔티티(고객, 상품, 부서 등)
- 중심 엔티티 : 기본 엔티티 - 행위 엔티티 사이에 존재, 기본 엔티티로부터 발생하고 행위 엔티티를 생성(계좌, 주문, 취소, 체결 등)
- 행위 엔티티 : 2개 이상의 엔티티로부터 발생(주문 이력, 체결 이력 등)
- 속성(Attribute)
- 엔티티가 가지는 항목, 의미적으로 더 이상 분리되지 않음
- 일반적으로 하나의 값을 가지며, 주식별자에게 함수적으로 종속됨
- 분해 여부에 따른 종류
- 단일 속성 : 하나의 의미로 구성(회원ID, 이름 등)
- 복합 속성 : 여러 의미로 구성, 분해될 수 있음(주소 - 시, 군, 동)
- 다중값 속성 : 여러 값을 가질 수 있음, 엔티티로 분해 가능(상품 리스트 등)
- 특성에 따른 종류
- 기본 속성 : 비즈니스 프로세스에서 도출되는 본래의 속성(ID, 이름 등)
- 설계 속성 : 데이터 모델링 과정에서 발생되는 속성, 유일한 값을 부여함(상품 코드, 지점 코드 등)
- 파생 속성 : 다른 속성에 의해 만들어지는 속성(합계, 평균 등)
- 관계(Relationship)
- 엔티티 간의 관련성을 의미하며 존재 관계와 행위 관계로 나뉜다.
- 존재 관계 : 엔티티 간의 상태이며 (고객 - 관리점) 사이의 “고객은 관리점에 소속된다.” 관계는 존재 관계이다.
- 행위 관계 : 엔티티 간의 어떤 행위가 있는 것으로, (계좌 - 주문이력) 사이의 “주문을 발주한다” 관계는 행위 관계이다.
- 관계 차수(Relationship Cardinality)
- 1대1 관계 : 완전 1대1(두 엔티티 간의 관계가 하나, 반드시 존재), 선택적 1대1(두 엔티티 간의 관계가 하나이거나 없을 수도 있음)
- 1대N 관계 : 고객-계좌와 같이 하나의 엔티티에 다른 엔티티의 값이 여러 개가 있는 관계
- M대N 관계 : 학생-과목과 같이 두 엔티티가 서로 여러개의 관계를 지님, Join 연산 시 카타시안 곱이 발생하므로 1대N / N대1로 해소해야 함
- 필수적 관계 : 반드시 하나가 있어야 하는 관계(”|”로 표현)
- 선택적 관계 : 없을 수도 있는 관계(”O”로 표현)
- 식별관계 : 고객-계좌에서 고객은 강한개체(Strong Entity)이며 계좌는 약한개체가 된다. 이 때 강한개체는 독립적으로 존재가 가능하고, 약한개체는 속성으로 강한개체의 기본키를 본인의 기본키에 포함하여 갖는다.
- 비식별관계 : 강한개체의 기본키를 본인의 기본키가 아닌 일반 칼럼으로 관계를 가짐
- 엔티티 식별자(Entity Identifier)
- 키의 속성 : 최소성, 대표성, 유일성, 불변성
- 기본키(Primary Key) : 후보키 중 엔티티를 대표하는 키
- 후보키(Candidate Key) : 유일성과 최소성을 만족하는 키
- 슈퍼키(Super Key) : 유일성은 만족하지만 최소성을 만족하지 않는 키
- 대체키(Alternate Key) : 후보키 중 기본키를 제외한 나머지 키
- 외래키(Foreign Key) : 다른 테이블의 기본키를 가리키는 키로, 참조 무결성을 확인하기 위해 사용되는 키
- 대표성에 따른 분류
- 주식별자 : 유일성과 최소성을 만족하며 엔티티를 대표하는 식별자
- 보조 식별자 : 유일성과 최소성은 만족하지만 대표성을 만족하지 못하는 식별자
- 생성 여부에 따른 분류
- 내부 식별자 : 엔티티 내부에서 생성되는 식별자(부서코드, 주문번호 등)
- 외부 식별자 : 다른 엔티티와 관계로 인해 만들어지는 식별자(계좌 엔티티가 갖는 회원 ID)
- 속성의 수에 따른 분류
- 단일 식별자 : 하나의 속성으로 구성
- 복합 식별자 : 두 개 이상의 속성으로 구성
- 대체 여부에 따른 분류
- 본질 식별자 : 비즈니스 프로세스에서 생성되는 식별자
- 인조 식별자 : 인위적으로 만들어지는 식별자
데이터 모델과 성능
정규화(Normalization)
- 데이터의 일관성, 최소한의 데이터 중복, 최대한의 데이터 유연성을 위한 방법
- 정규화를 진행하지 않은 테이블에서는 이상현상(Anomaly)가 발생한다.
- 제1정규화부터 제5정규화까지 있지만, 실질적으로는 제3정규화까지 수행하는편
| 종류 | 설명 |
|---|---|
| 제1정규화 | 속성의 원자성을 확보한다. 기본키를 설정한다. |
| 제2정규화 | 기본키가 2개 이상의 속성으로 이루어진 경우, 부분 함수 종속성을 제거한다. |
| 제3정규화 | 기본키를 제외한 칼럼 간 종속성을 제거한다. 즉, 이행 함수 종속성을 제거한다. |
| BCNF | 기본키를 제외한 후보키가 있는 경우, 후보키가 기본키를 종속시키면 분해한다. |
| 제4정규화 | 여러 칼럼이 하나의 칼럼을 종속시킬 경우 분해하여 다중값 종속성을 제거한다. |
| 제5정규화 | 조인에 의해서 종속성이 발생하는 경우 분해한다. |
- 정규화의 문제점
- 데이터 조회(SELECT)시에 Join을 유발하기에 자원을 많이 사용하게 된다.
- 실제로는 인덱스와 옵티마이저(Optimizer)를 사용하여 비효율이 적게 발생한다.
- 어찌되었던 성능저하를 유발하는데, 이를 위해 반정규화가 존재한다.
- 반정규화(De-Normalization)
- DB의 성능 향상을 위해, 데이터 중복을 허용하고 Join을 줄이는 방법이다.
- 정규화로 인해 수행 속도가 느려지거나, 다량의 범위를 자주 처리하는 경우, 특정 범위의 데이터만 자주 처리하는 경우, 요약/합계가 자주 요구되는 경우 유용하다.
- 반정규화 대상 조사 → 다른 방법(클러스터링, 뷰, 인덱스, 파티션 등) 검토 → 수행
- 계산된 칼럼 추가
- 배치 프로그램으로 총합, 평균 등을 미리 계산하여 그 결과를 칼럼에 추가
- 테이블 수직 분할
- 하나의 테이블을 두 개 이상의 테이블로 분할
- 칼럼을 분할하여 새로운 테이블을 생성한다.
- 테이블 수평 분할
- 하나의 테이블에 있는 값을 기준으로 테이블을 분할
- 2001~2010년 데이터 → 2001~2005, 2006~2010 두 개로 분할
- 테이블 병합
- 1대1 관계의 테이블을 하나로 병합하여 성능을 향상
- 1대N 관계의 테이블을 병합할 수도 있지만, 많은 양의 데이터 중복 발생
- Super / Sub Type 관계 발생 시, 하나로 통합하여 성능 향상
- Super Type : 부모타입인듯, 고객-(개인고객, 법인고객)
- Sub Type : 자식타입인듯, 고객-(개인고객, 법인고객), 둘 중 하나에만 속할 수 있으면 배타적 관계, 둘 다 동시에 가능하면 포괄적 관계
- 변환 방법
- One-To-One Type : 슈퍼타입과 서브타입을 개별 테이블로 도출, 테이블 수가 많아서 조인이 많이 발생하고 관리가 어려움
- Plus Type : 슈퍼타입과 서브 타입 테이블로 도출, 조인이 발생하고 관리가 어려움
- Single Type : 슈퍼타입과 서브타입을 하나의 테이블로 도출, 조인 성능이 좋고 관리가 편하지만 입출력 성능이 나쁨
분산 데이터베이스
- 중앙 집중형 데이터베이스 : 한 대의 물리적 데이터베이스 관리 시스템을 설치하고 여러 사용자가 시스템에 접속하여 사용하는 형태
- 분산 데이터베이스 : 물리적으로 떨어진 데이터베이스를 네트워크로 연결하여 단일 데이터베이스의 이미지를 보여주고 분산된 작업 처리를 하는 형태
- 분산 데이터베이스의 투명성 : 사용자는 시스템이 네트워크로 분산되어 있다는 사실을 알지 못하며 자신만의 데이터베이스를 사용하는 것처럼 사용할 수 있다.
속성 설명 분할 투명성 고객은 하나의 릴레이션이 여러 단편으로 분할되어 각 단편의 사본이 여러 시스템에 저장되어 있음을 인식할 필요가 없다. 위치 투명성 고객이 사용하는 데이터의 저장 장소를 명시할 필요가 없다.
데이터가 어느 위치에 있더라도 동일한 명령으로 접근 가능해야 한다.지역 사상 투명성 지역 DBMS와 물리적 DB 사이 사상이 보장되어 각 지역 시스템 이름과 무관한 이름이 사용 가능하다. 중복 투명성 DB 객체가 여러 시스템에 중복되어 존재하여도 데이터의 일관성이 유지된다. 장애 투명성 분산되어 있는 각 지역의 시스템/통신망에 장애가 발생해도 데이터 무결성은 보장된다. 병행 투명성 여러 고객이 동시에 데이터베이스에 대한 트랜잭션을 수행해도 결과에 이상이 없다. - 상향식 설계 방식 : 지역 스키마 작성 이후 전역 스키마를 작성
- 하향식 설계 방식 : 전역 스키마 작성 이후 지역 스키마를 작성
- 분산 데이터베이스의 장단점
- 장점 : 신뢰성과 가용성이 높음, 병렬 처리로 인해 빠른 응답, 용량 확장이 쉬움
- 단점 : 관리와 통제가 어려움, 보안관리, 무결성관리가 어려움, 설계가 복잡함
안녕하세요<br>반가워요<br>안녕히가세요