No.0?? Entity Relationship Diagram [2017-06-14]

ERD?

- 1976년 Chen에 의해 제안된 E-R 모델은 개념적 모델에서 가장 일반적으로 사용되고 있는 모델로서 그 모델이 지니고 있는 단순성 때문에 현재 광범위한 응용 분야에서 사용

- 데이터에 대해 관리자, 사용자, 프로그래머들이 서로 다르게 인식되고 있는 뷰들을 하나로 통합할 수 있는 단일화된 설계안

- 서로 다른 뷰들을 충족시킬 수 있는 데이터 처리와 제약조건 등의 요구사항 들을 정의

- 최종 사용자의 관점에서 데이터베이스를 그림형태로 묘사한 것으로서, 세 개의 기본요소인 개체, 관계, 그리고 속성으로 구성

 

구성요소

Entity

- 단순히 우리가 데이터 수집의 대상이 되는 정보 세계에 존재하는 사물(thing)

- 개념적 개체 : 장소, 사건 등과 같은 눈에 보이지 않는 것

- 물리적 개체 : 물건 등과 같은 눈에 보이는 것, 현실 세계에 존재하는 사물

- 직사각형으로 나타내고 이름을 붙임

 

Weak Entity

- 그 개체의 키가 자체적으로 존재하지 않음

- Weak entity는 관계를 맺는 다른 개체에 있는 키를 계승 받음

 

Attribute

- 객체의 구조를 나타내는 특성들을 의미

 ①simple attribute   ②Composite attribute

- 직사각형에 실선으로 연결된 타원형으로 표현

 

Relationship

- 개체들 사이에 존재하는 연관성을 의미

 ①Unary relationship  ②Binary relationship  ③Ternary relationship

- 두 개체들을 연결하는 실선들이 있고 그 사이에 마름모 모양의 표시

 

Connectivity

- 한 개체가 관계를 통하여 다른 개체와 관련되는 개체들의 수

 ①One to one  ②One to many  ③Many to many

 

Cardinality

- 관계에 참여하는 하나의 개체에 대해 다른 개체형에서 몇개의 개체가 참여하는지를 나타냄

 

설계과정

- ERD 설계 과정은 모델링의 대상이 되는 조직체의 담당자(고객)와 인터뷰를 하여 데이터를 수집 및 분석한 결과인 데이터베이스 요구사항을 가지고 시작

- 기본이 되는 개체, 관계, 속성들을 규명

- 설계를 해나가는 과정에서 새로운 개체, 관계, 속성 등의 요소들이 발견되었다면 이를 ERD에 추가해야 하며, 또한 불필요한 요소들이 발견되었다면 이를 ERD 에서 삭제해야 하는 반복적인 작업

- 설계자나 고객의 요구사항이 완전히 표현되었다고 볼 때까지 반복

 

1. 데이터베이스 설계의 단계

 아래 질문에 대한 해결방안을 찾아가는 과정이 DB 설계 단계이다.

- 중요한 데이터는 무엇인가?

- 데이터를 어떻게 표현할 것인가?

- 데이터를 어디에 저장할 것인가?

 

2. ERD 작성(1)

- 데이터 요구사항 수집과 분석

 ①업무 기술서 검토

 ②현업 장표 검표

 ③현업 업무 전문가와의 면담

 ④기 구축된 시스템 산출물 검토

- 요구사항 정리(예)

 ①여러 학과가 있다.

 ②각 학과에 대해서 번호와 이름이 있다.

 ③각 학과는 여러 명의 교수들이 소속되며, 각 교수에 대하여 번호와 이름이 있다.

 ④각 교수는 여러 과목을 강의하며, 각 과목에 대해서 번호, 이름, 학점이 있다.

 ⑤각 학과는 여러 명의 학생들이 소속된다.

 ⑥각 학생에 대하여 번호, 이름, 주소, 학년, 전화번호가 있다.

 ⑦각 학생은 여러 번 등록을 할 수 있으며 등록 시 번호와 등록 일이 있다.

 ⑧각 학생은 등록 후 여러 과목을 수강하며 중간, 기말 성적이 기록된다.

 

-----------------------------------------------------------

 

테이블 설계서

1. 정의

 논리 설계 단계에서는 대략의 데이터 크기를 산정하여 소요 디스크량을 추정하고 지역 분산시의 기초 자료로 사용하기 위하여, 지역별 Raw 데이터 크기, 월증가량, 디스크 보관 주기 등을 산출해낸다.

 물리 설계 단계에서는 이러한 내용을 토대로 하여 운영 환경에 필요한 실제 디스크 소요량을 산정하고 디스크 상의 I/O(Input/Output) 부하 분산을 위한 기초 자료로 이용할 수 있도록 테이블 크기, 테이블스페이스 크기 등을 파악하며, 이를 근거로 실제로 디스크에 할당하는 작업을 수행한다.

 

2. 절차

절차	내용	참조
테이블스페이스 설계	1) 테이블별 테이블스페이스 결정 2) DB파일 구성 및 디스크 할당	테이블스페이스 설계서
테이블 설계	1) 데이터 건수와 길이 산정 2) 테이블 총크기 산정 3) 테이블의 파라미터 값 결정	테이블 용량 산정서 테이블 설계서
인덱스 설계	1) 인덱스 총크기 산정 2) 인덱스 파라미터 값 결정	인덱스 용량 산정서 인덱스 설계서
파티션 설계	1) 테이블 선정 2) 파티션 키 선정 3) 파티션 개수 결정 4) 인덱스 유형 선택	파티션 설계서
DDL 생성 및 관리	1) 테이블/인덱스 DDL 2) 테이블스페이스 DDL	DDL script

 

3. 테이블 설계

3.1 데이터 건수 및 용량 산정

 1) 데이터 건수와 길이 산정

 - 테이블 크기를 산정하기 위한 양식을 업무 담당자에게 배포하여 데이터 건수와 산정근거를 조사한다.

업무명	테이블명	초기건수	월발생건수	보관기간

 - 데이터 없이 빈 테이블을 구성하여 SQL문을 통하여 정확한 테이블별 row의 길이를 구할 수 있다.

 

 2) 테이블 총크기 산정

 - 조사된 데이터 건수와 길이를 바탕으로, 계산 공식이 반영된 Excel 양식을 이용하여 자동으로 산정한다.

 - Row 길이에 헤더 사이즈를 감안하여 평균 길이를 구한다.

 - 30% 정도의 여유공간을 감안하여 테이블의 총크기를 구한다.

테이블명	최종길이	초기건수	월발생건수	보관기간	총데이터건수	총크기

 

3.2 테이블의 파라미터 값 결정

 - 파라미터 값 결정

  <INITIAL 결정>

INITIAL

INITIAL 파라미터는 테이블/ 인덱스 모두 동일하게 1M를 지정한다.

 

  <PCTFREE 결정>

Scenario	Setting
Insert, Update, Delete의 발생이 비슷하며, update시 길이의 변화 적음	PCTFREE = 10
Update가 많으며, Row의 length가 증가하는 Update 대부분 포함	PCTFREE = 20
Insert, Delete 많고, Update시 row length의 변화 거의 없음	PCTFREE = 5
채번테이블	PCTFREE = 90

 

  <기타 파라미터>

파라미터	설정 기준
MINEXTENT	INITIAL 파라미터 값을 Data의 Extent가 일어나지 않을 크기로 설정하였으므로 1로 설정한다.
MAXEXTENT	Unix의 O/S에 따른 최대 MAXEXTENT 파라미터 값을 지정한다. Default로 설정하면 무난하다.
INITRANS	- 다중 트랜잭션이 동시에 동일한 Data block에 있는 행을 액세스 할 때 block의 각 트랜잭션 입력 항목에 대해 영역을 미리 할당해 놓는 것으로 동시 트랜잭션 수를 고려하여 적절한 값을 설정한다. - Default : 테이블은 1, 클러스터와 인덱스는 2 - 마스터성 테이블이나 트랜잭션이 다량으로 발생하는 테이블은 3. (향후 조정)
BUFFER_POOL	- default (시스템의 기본값) - keep(자주 사용하는 코드성 테이블의 경우)
MAXTRANS	- 동시에 Data block의 데이터를 사용할 수 있는 트랜잭션의 입력 항목 수를 제한하는 것으로 너무 낮게 값을 설정하면 동시 트랜잭션이 이 값을 초과 할 경우 영역 할당을 못 받은 트랜잭션은 다른 트랜잭션의 처리가 끝날 때까지 기다려야 한다. - Default 값(255)으로 설정.