1. 데이터베이스 설계
1) 사용자의 다양한 요구 사항을 고려하여 DB를 생성하는 과정
2) 이미 구축된 DB는 구조를 변경하기 어려우므로 체계적인 설계를 통해
DB가 올바르게 구축되어야 함.
3) 대표적인 설계 방법
- E-R 모델
- 정규화를 이용한 설계
2. DB 설계 단계
1) 요구 사항 분석
- 실제 세계에서 어떤 요구사항의 시스템을 구축할 것인지 대한 DB의 용도 파악
- 요구 사항에 대한 어떤 데이터들이 필요한지, 어떤 기능들이 필요한지 분석
- 산출물 : 요구 사항 명세서
2) 개념적 설계 (Conceptual Model)
- 요구 사항 분석 결과물을 개념적 데이터 모델을 표현
- 요구 사항 명세서를 E-R 다이어그램으로 표현
3) 논리적 설계
- 관계 모델 (Relation model)을 통해 개념적 모델을 논리적으로 표현
- 산출물 : 릴레이션 스키마
4) 물리적 설계
- DBMS로 구현이 가능한 물리적인 구조 설계
- 저장 타입 등 설계
- 산출물 : 물리적 스키마
5) 소프트웨어 구현
6) 서비스(사이트) 운영
3. 요구 사항 분석
1) DB를 사용할 주요 사용자의 범위 결정
2) 사용자가 수행하는 업무를 분석
3) 수집된 요구 사항 대한 분석 결과를 요구 사항 명세서임.
4) 예
- 이젠아카데미에 회원으로 가입하려면 회원아이디, 비밀번호, 이름, 이메일, 전화번호를
--- ---------- -------- --- ----- -------
입력해야 한다.
- 회원은 회원아이디로 식별한다.
- 강의(상품)에 대한 강의번호, 강의명, 수강생수, 수강비를 유지해야 한다.
- 상품은 상품번호로 식별한다.
- 회원이 강의를 주문하면 주문에 대한 주문번호, 주문수량, 강의실, 주문일자 정보를
유지해야 한다.
4. 개념적 설계
1) DMBS에 독립적인 개념적 스키마를 설계하는 과정
2) 요구사항 분석 결과를 기반으로 중요한 개체를 추출하고
개체 간의 관계를 결정하여 E-R 다이어그램으로 표현
3) 작업 과정
- step 1 : 개체 추출, 각 개체의 주요 속성과 키 속성 선별
- step 2 : 개체 간의 관계 결정
- step 3 : E - R 다이어그램 작성
4) Step 1
- 개체 : 저장할 만한 가치가 있는 중요한 데이터를 가진 사람이나 사물 등
- 개체 / 속성 추출 방법
- 요구 사항 문장에서 업무(서비스)와 관련이 깊은 의미 있는 명사를 찾음.
- 찾아낸 명사를 개체와 속성으로 분류
5) Step 2
- 관계 (Relationship) : 개체 간의 의미 있는 연관성
- 관계 추출 방법
- 요구 사항 문장에서 개체 간의 연관성을 의미 있게 표현한 동사를 찾음.
- 찾아낸 관계에 대해 매칭 Cardinality와 참여 특성을 결정
- 매칭 Cardinality
- 1:1, 1:n, m:n
- 참여 특성
- 전체 참여, 부분 참여
- 예
- 주문
- 개체: 회원(선택), 상품(선택)
- Cardinality : m:n
- 속성 : 주문번호, 주문수량, 배송지, 주문일자
- 공급
- 개체: 상품(필수), 제공업체(선택)
- Cardinality : 1:n
- 속성 : 공급일자, 공급량
- 작성
- 개체: 회원(선택), 게시글(필수)
- Cardinality : 1:n
6) Step 3
- ER 모델 (Entity Relation Model)
- 요구사항에서 얻어낸 정보를 개체, 속성, 관계성으로 기술하는 데이터 모델.
- (Peter) Chen notation
- Crow's Foot (까마귀 발) notation
- barker 표기법
5. 개체 (Entity)
1) 저장할 만한 가치가 있는 중요한 데이터를 가진 사람이나 사물, 행위 등.
2) 개체 이름을 포함하는 네모로 표현
6. 속성 (Attribute)
1) 이름을 포함한 원으로 표현
2) Key Attribute
- 특정 Entity를 식별할수 있는 고유한 값을 가진 Attribute
- 이름에 underscore
7. 관계 (Relationship)
1) Entity간의 어떤 상호작용을 하는지 표현
2) Relationship 이름을 포함한 다이아몬드(마름모)로 표현
3) Relationship도 Attribute을 가질수 있음
8. Cardinality (Degree of Relationship)
1) 관계를 맺는 두 Entity대해 한 객체가 얼마나 많은 다른 개체와 관련될 수 있는지
나타내는 표현.
- "1", "N", "M"
2) cardinality에 따른 관계 타입의 유형
one to one (1:1)
- 일대일 관계
- 하나의 개체가 하나의 개체에 대응
- 예) 사원 - 컴퓨터
one to many (1:N)
- 일대다 관계
- 하나의 개체가 여러 개체에 대응
- 예) 학과 - 학생
many to one (N:1)
- 다대일 관계
- 여러 개체가 하나의 개체에 대응
- 예) 학과 - 학생
many to many (M:N)
- 다대다 관계
- 여러 개체가 여러 개체에 대응
- 예) 학생 - 강좌
9. 정규화(Normalization)의 개념
1) 관계형 데이터베이스의 설계에서 데이터 중복을 최소화하게 구조화하는 프로세스.
2) 함수적 종속성을 이용해서 연관성 있는 속성들을 분류하고,
각 릴레이션에서 이상현상이 생기지 않도록하는 과정.
3) 함수적 종속성(FD) 등과 같은 이론에 근거하여 관계형 데이터베이스의 테이블의
삽입,삭제,갱신 이상(anomaly) 현상 발생을 최소화하기 위해 좀 더 작은 단위의
테이블로 설계하는 과정.
- 조회 => 처리조건에 따라 성능이 향상 혹은 저하 됨.
- 입력/수정/삭제는 무조건 성능이 향상 됨.
10. 정규화의 목적
1) 불필요한 데이터를 제거, 데이터 중복을 최소화
2) 무결성 제약조건의 시행을 간단하게 하기 위해
3) 이상(anomaly) 현상을 방지하기 위해 테이블 구성을 논리적이고 직관적으로 만들기 위해
- 삭제 이상(deletion anomaly)
: 튜플을 삭제함으로써 유지되어야 하는 정보까지도 연쇄적으로 삭제되는 경우.
4) 이상 현상이 발생하는 원인
- 관련 없는 속성들을 다 모아서 하나의 릴레이션으로 만들었기 때문에.
- 정규화를 통해 릴레이션을 관련이 있는 속성들로만 구성되는 작은 여러 개의
릴레이션으로 분해해야 함.
- 속성들의 간의 관련성 판단 : 함수적 종속성
- 하나의 릴레이션에는 하나의 함수적 종속성만 존재하도록 정규화를 함
11. 정규화 효과 및 장점
1) 상호 종속성이 강한 데이터 요소들을 분리, 독립된 개념(엔티티, 테이블)으로
정의를 하게 됨에 따라 high cohesion & loose coupling 원칙에 충실해짐.
2) non key 데이터 요소의 중복이 최소화 됨.
12. 함수적 종속성 (Functional Dependency: FD)
1) 릴레이션(Relation)의 속성(Attribute)들 사이의 관계를 표현.
주로 기본키(primary key)와 다른 non key 속성들 사이의 관계를 표현.
- 결정자(Determinant) : 함수적 종속성에서 기본키 속성(컬럼)을 결정자라함.
2) 함수적 종속성의 분석을 통해 정규화를 실행
3) 함수 : 입력 X의 경우 반드시 한개의 출력 Y 결정
- 예) 통화 (달러) --> 환율
사원아이디 --> 사원명
주번 --> 성명
학번 --> 소속학과
13. 정규형 (NF : Normal Form)
1) 정규화 결과에 의해 도출된 데이터 모델
14. 1NF (First Normal Form, 제 1 정규화, 제 1 정규형)
1) 릴레이션에 속성들은 원자값(atomic value, 하나의 값)을 갖도록 해야 함.
2) 복수의 속성값을 갖는 속성을 분리.
3) 속성의 원자성 확보.
4) 여러 값을 가지고 있는경우 다른 릴레이션으로 분리함.
15. 2NF (Second Normal Form, 제 2 정규화, 제 2 정규형)
1) 1NF를 만족하고 모든 Non-key 컬럼은 기본 키 전체에 종속되어야 함.
2) 기본 키에 종속적이지 않거나 기본 키 일부 컬럼(들)에만 종속적인 컬럼은 분리되어야 함.
3) 함수적 종속성(Functional Dependency) 분석 (예)
- 주문일자 : 고객아이디와 주문순번으로 결정됨.
=> 기본키를 구성하는 속성(열,컬럼) 전부에 함수종속이 존재함.
- 고객명 : 고객아이디로만 결정됨.
=> 부분 함수 종속됨.
기본키를 구성하는 열의 일부에만 함수종속이 존재함.(제2정규화 위반)
- 고객등급 : 고객아이디로만 결정됨.
=> 부분 함수 종속됨.
기본키를 구성하는 열의 일부에만 함수종속이 존재함.(제2정규화 위반)
8. 3NF (Third Normal Form, 제 3 정규화, 제 3 정규형)
1) 제 2정규형을 만족하고 일반속성들간에도 종속관계가 존재하지 않아야 함.
2) 일반속성들 간 종속관계가 존재하는 것들은 분리되어야 함.
3) 함수적 종속성(Functional Dependency) 분석 (예)
- 고객명은 고객아이디로 결정됨
=> 부분 함수 종속 아님. 함수종속이 존재함
- 나이는 고객아이디로 결정됨
=> 부분 함수 종속 아님. 함수종속이 존재함
- 직업명은 직업코드로 결정됨.
=> 일반 속성(컬럼)인 직업코드에 함수 종속이 존재함.(제3정규형 위반)
16. 제 4, 5 정규형 (4NF, 5NF)
1) 실무에서 거의 쓰이지 않음
2) 제 3 정규형까지만 이해하는 것이 중요함.
<논리적 설계>
1. 논리적 설계 (논리적 모델링 or 데이터 모델링)
1) 관계 모델을 통해 개념적 모델을 논리적으로 표현
2) 개념적(Conceptual) 스키마 ==> 논리적(Relational) 스키마
------------------------
2. 릴레이션 스키마 변환 규칙
1) 규칙1 : 모든 개체는 릴레이션으로 변환한다.
2) 규칙2 : 다대다(n:m) 관계는 릴레이션으로 변환한다.
3) 규칙3 : 일대다(1:n) 관계는 외래키(foreign key)로 표현함.
4) 규칙4 : 일대일(1:1) 관계는 외래키(foreign key)로 표현함.
'Web > Oracle SQL' 카테고리의 다른 글
| 10. JDBCConnectTest (0) | 2022.01.29 |
|---|---|
| 9. CASE (0) | 2022.01.29 |
| 8. 서브쿼리 (0) | 2022.01.29 |
| 7. 조인 (0) | 2022.01.29 |
| 6. 내장함수 (0) | 2022.01.29 |
댓글