 |
|
|
 |
|
|
 모델링의 개요
|
|
사용자의 요구사항으로부터 데이터의 실체를 도형으로 나타내는 것이다.
|
|
- 데이터 모델링을 통해 정해진 용어를 사용하고 정해진 방법과 절차에 의해 모든 과정을 표준화하여 사용자/설계자/개발자 간의 효율적인 의사소통의 수단으로 활용한다.
- 데이터 중심 분석을 통해 데이터의 흐름을 제어하고 데이터 기반의 효율적인 시스템을 구축한다.
|
|
| |
|
|
| 개념적 모델링 |
|
- 기업에서 지속적인 관심을 가지고 정보화를 해야 하는 대상으로 고객, 직원, 상품, 주문, 결제 등 다양하다. 도출되는 Entity는 모델링을 하고자 하는 분야 및 서비스에 따라서 예를 들면 도메인, 호스팅, 디자인, 결산 등 형태 및 명칭이 달라진다.
- Entity는 식별 가능한 데이터 요소를 갖는다. 예를 들면 직원의 경우 부서, 팀, 직급 등의 속성을 가지고 있어야 Entity가 될 수 있다.
|
| ▶ Key Entity: 태초부터 창조된 실체를 말한다. 즉, 부모를 가지지 않는 Entity를 말한다. |
| 예를 들면 직원, 고객, 상품, 제품 등이 있다. 신용카드는 언뜻 생각하면 Key Entity 같 |
| 이 보이나 카드를 발급 받는 사람과 발급해 준 카드사의 상품이 존재하지 않으면 생성될 |
| 수 없는 Entity임으로 Key Entity가 될 수 없다. |
| ▶ Main Entity: 나무의 골격을 구성하는 가지처럼 Key Entity에 의해 탄생된 집합이지만 자 |
| 신의 하위에 다양한 자식 Entity를 거느리고 있는 Entity이다. 예를 들면 주문, 계약, |
| 청구, 매출 등이 있다. 신용카드는 부모가 존재하지만 스스로 하위 Entity를 생성할 수 |
| 있어 Main Entity이다. |
| ▶ Action Entity: 자식을 갖지 않는 Entity로 최하위 Entity이다. 우편번호, 통계정보, 워 |
| 터마크 등이 있다. 따라서 Action Entity는 Key/Main Entity에 따라 생성될 수도 삭제될 |
| 수도 있다. |
|
|
|
- Entity에서 관리해야 할 정보들의 항목이다. 예를 들면 상품 Entity에는 협력사번호, 개발자번호, 상품코드, 시작일시, 종료일시 등이 있다.
- 속성의 명칭은 명확해야 하며 내용을 함축할 수 있도록 부여하고 Entity명은 속성으로 사용하지 말아야 한다.
- 파생(Deriving)되는 속성은 정의하지 않는다. 예를 들면 단가 1,000원 제품을 3개 판매할 경우 판매금액을 계산한 결과를 속성으로 정의하거나 생년월일 정보를 사용하여 나이를 다시 계산해서 속성으로 정의하는 경우 등이 있다.
|
③ 식별자(UID - Unique identifier) |
- 하나의 Entity를 대표하는 속성으로 여러 개의 속성이 하나의 UID가 될 수 있다.
- 하나의 Entity는 반드시 하나의 UID를 가져야 한다.
- 해당 속성은 반드시 필수(Mandatory)여야 하며 유일값(Unique)이어야 한다.
|
|
| |
|
|
| 상세 개념적 모델링
|
개념적 데이터 모델링 단계가 개괄적 분석 작업이라면 상세 개념적 데이터 모델링은 구체적으로 분석하고 실체를 추가적으로 찾아내며 불필요한 실체는 제거함으로써 실체의 관계를 보다 명확하게 하는 단계이다. 상세 개념적 데이터 모델링은 주로 정규화 및 역정규화에 치중한다.
|
|
- 1차 정규화: Entity 내의 모든 속성은 반드시 하나의 값을 가져야 한다.
- 2차 정규화: Entity 내의 모든 속성은 반드시 식별자 모두에 종속되어야 한다.
- 3차 정규화: Entity 내의 모든 속성은 상호 종속될 수 없다.
|
| 정규화를 하는 이유 |
| ▶ 데이터의 중복성을 제거할 수 있다. |
| ▶ 데이터 모형을 단순화한다. |
| ▶ 속성(Attribute)의 배열상태를 검증해 볼 수 있다. |
| ▶ 개체(Entity), 속성(Attribute)의 누락 여부를 검증해 볼 수 있다. |
| ▶ 데이터 모형의 안정성을 유지시킬 수 있다. |
|
|
|
Entity A에 존재하는 데이터 1개와 관계되는 Entity B에 존재하는 데이터의 개수가 여러 개이며, Entity B에 존재하는 데이터 1개와 관계되는 Entity A에 존재하는 데이터의 개수도 여러 개인 실체간의 관계를 N:M 관계라 한다. 예를 들면 학생 Entity와 과목 Entity의 관계는 N:M 관계이며 이를 해소하기 위해 수강 Entity라는 교차 Entity를 도출한다.
이처럼 N:M 관계는 교차 Entity를 도출하여 해소한다.
|
 |
|
| |
|
|
| 논리적 모델링 |
ERD와 DBMS를 매핑(Mapping)시키는 단계이다. 즉, 개념적 데이터 모델링 단계를 거쳐 작성된 분석 결과를 기반으로 구현하고자 하는 DBMS를 선정한 다음 관리적인 측면과 성능적인 측면을 고려하여 최적의 데이터베이스가 구축될 수 있도록 설계하는 단계이다.
|
|
▶ 실체를 테이블로 작성
- ERD에 정의된 Entity는 논리적 DB 설계 단계에서 테이블로 작성된다.
- ERD의 Entity는 테이블명으로 사용하는 것이 좋다.
- Entity명은 한글로 작성하고 동의어는 영문으로 작성한다.
- 테이블명은 영문명을 사용하고 너무 길지 않게 작성한다.
▶ 속성을 컬럼으로 작성
- ERD에서 정의된 속성은 논리적 DB 설계 단계에서는 컬럼으로 작성된다.
|
 |
- 가능한 표준화된 약어를 사용한다.
- SQL 언어의 예약어를 컬럼명으로 사용하지 않는다.
- 가능한 컬럼명을 짧게 부여하여 사용의 편리를 도모한다.
▶ 식별자를 식별키로 작성
- ERD에서 정의된 UID는 논리적 DB 설계 단계에서 Primary key로 작성된다.
▶ 관계를 외부키로 작성
- 1:N의 관계에서 반드시 한쪽의 Primary key 컬럼을 N 테이블 컬럼의 Foreign key로 설정해야 한다.(전이관계)
- 1:1 관계에서 어느 한쪽이 필수인 경우 선택 쪽의 Primary key를 필수 쪽의 Foreign key로 설정한다.
- 1:1 관계에서 양쪽 모두 선택인 경우 효율적 측면에서 빈번하게 사용되는 테이블이 참조 테이블이 되는 것이 유리하다.
- 순환관계에서는 자신의 Primay key를 Foreign key로 정의된다.
|
|
| |
|
|
| 물리적 모델링 |
개념적 데이터 모델링 및 논리적 데이터 모델링 과정을 통해 산출된 ERD를 기반으로 DBMS 내의 객체들을 생성하는 단계를 말한다.
또한 데이터베이스의 전체적인 물리적 구조에 대한 설계 작업도 함께 수행한다.
|
|
제약조건이란 테이블의 해당 컬럼에 사용자가 원치 않은 데이터가 입력, 변경, 삭제되는 것을 방지하기 위해서
테이블을 생성할 때 어떤 조건을 설정할 수 있는데 이것을 제약조건이라고 한다. 제약조건은 데이터의 무결성(Integrity)을 보
장해 준다.
▶ Primary key: 하나의 행에서 그 행을 대표하는 컬럼이며 Foreign key 컬럼이 참조하는 컬럼은 반드시 Primary key 컬럼이어야
한다.
▶ Foreign key: 입력되어야 할 값이 다른 테이블의 Primary key 컬럼인 컬럼
▶ Unique: 컬럼의 값이 테이블 전체에서 유일한 값이어야 하는 경우
▶ Not Null: 컬럼에 Null 값이 입력되어서는 안 되는 경우
|
|
|
|
