테이블 설계
테이블 이란?
① 관계형 데이터베이스에서 데이터를 관리 및 저장하는 장소
② 데이터의 효율적인 관리 및 적절한 조작이 매우 중요함
③ 실생활에서 광범위하게 사용되는 2차원 표와 유사함
•
테이블은 현실 세계를 반영함
•
개념이나 집합에 대응하는 형식으로 존재
•
완두콩, 토마토, 옥수수 등은 행은 될 수 있어도 집합은 될 수 없음
테이블 설계 규칙
집합을 나누는 방법
① 집합을 나누는 방법에 따라 한 개 혹은 여러 개의 테이블이 될 수 있음
일반회원, 프리미엄회원 테이블은 회원 테이블로 통합 될 수 있다.
회원 테이블은 일반회원, 프리미엄회원 테이블로 나눠질 수 있다.
데이터베이스 VS 자바, 파이썬
기본키의 중요성
① 기본키는 특정 집합에서 특정 행을 유일하게 식별할 수 있는 속성의 집합
(EX. 학번, 카드발급번호, 주민등록순번)
② 현실 세계에 2명의 같은 사람은 없다, 기본키는 중복되면 안된다.
기본키의 값은 한번 정해지면 가급적 변경 안됨
③ 반드시 기본키를 설정해야 함(한 개 테이블 내에서 중복 행은 허용하지 않음),
기본키는 NULL 값 허용 안됨
④ 단, 업무상의 이유로 기본키가 없는 테이블이 운영되는 곳도 있음
회원 아이디는 기본키(Primary key) ⇒ unique한 고유의 특성을 가지게 됨
정규형
정규형이란?
① 테이블을 정의하는 기본 형태
② 즉 제대로 된 형태를 뜻함 —> 테이블 갱신 시 부정합이 발생하기 어려운 형태
③ 정규형을 제대로 지키는 행위를 정규화 위반이라고 부름
→ 정규화가 제대로 되지 않아 관리의 어려움을 겪는 시스템이 다수 존재함
제1정규형(1NF) 위반
① 테이블의 셀에 여러 개의 값을 포함하지 않는다.
•
연락처 컬럼에 두 가지 값이 들어가 있음
•
이럴 경우 제 1 정규형 위반임
제1정규형(1NF) 위반 해소
① 기존의 회원 테이블에서 회원연락처 테이블을 추가하여 제 1정규형을 만족하게 함
테이블 = 함수
① 테이블은 함수와 같다. 기본키의 값을 입력하면 특정 출력 값이 나오는 구조이다
② 입력 X의 경우 반드시 한 개의 출력을 Y 결정 ⇒ 함수 종속성이 있다.
통화를 넣으면 환율 값이 나온다..!
•
함수 종속성(Functional Dependency)
• 통화 --> 환율
◦
환율은 통화에 종속된다
• 사원아이디 --> 사원명
• 사원아이디 --> 사원나이
• 주민등록번호 --> 성명
• 학번 --> 소속학과
• 회원아이디 --> 연락처는 복합 값이 포함되어 성립 안됨
◦
연락처가 여러 개일 경우는 성립이 안됨
제2정규형(2NF) 위반
① 부분함수 종속성을 허용하지 않음
② 기본키를 구성하는 열의 일부에만 함수 종속이 존재하는 것
각각 고객명, 고객 등급은 오로지 고객 아이디에만 함수 종속성을 가짐 ⇒ 부분 함수 종속
•
올바른 집합 단위에 기초하고 있지 않음
•
갱신 시에 갱신 이상이 발생할 가능성 존재
•
주문 시마다 고객정보를 저장해야 함
•
고객 정보의 중복이 발생할 수 있음
•
고객 정보를 모르면 주문이 불가능 함
함수 종속성(Functional Dependency) 분석
분석 → 결과
•
주문일자는 고객 아이디와 주문 순번으로 결정된다.
→ 부분함수 종속 아님, 즉 기본키를 구성하는 열 전부에 함수 종속이 존재
•
고객명은 고객 아이디로만 결정된다.
→ 부분함수 종속임, 즉 기본키를 구성하는 열의 일부에만 함수 종속이 존재하는 것(제2정규형 위반)
•
고객등급은 고객아이디로만 결정된다.
→ 부분함수 종속임, 즉 기본키를 구성하는 열의 일부에만 함수 종속이 존재하는 것(제2정규형 위반)
제2정규형(2NF) 위반 해소
① 전체 열이 기본키만으로 함수 종속 가짐
② 기본키의 일부에만 종속하는 열 없음
함수 종속성(Functional Dependency) 분석
분석 → 결과
•
주문일자는 고객아이디와 주문순번으로 결정된다. → 부분함수 종속 아님, 즉 기본키를 구성하는 열 전부에 함수 종속이 존재
•
고객명은 고객아이디로 결정된다. → 부분함수 종속 아님, 즉 기본키를 구성하는 열 전부에 함수 종속이 존재
•
고객등급은 고객아이디로 결정된다. → 부분함수 종속 아님, 즉 기본키를 구성하는 열 전부에 함수 종속이 존재
제3정규형(3NF) 위반
① 기본 키를 제외한 일반 컬럼끼리 함수 종속이 발생
② 기본 키 이외의 키 간 발생하는 함수의 종속
함수 종속성(Functional Dependency) 분석
분석 → 결과
•
고객명은 고객아이디로 결정된다. → 부분함수 종속 아님, 즉 기본키를 구성하는 열 전부에 함수 종속이 존재
•
나이는 고객아이디로 결정된다. → 부분함수 종속 아님, 즉 기본키를 구성하는 열 전부에 함수 종속이 존재
•
직업명은 직업코드로 결정된다. → 일반 칼럼인 직업코드에 함수 종속이 존재함 (제3정규형 위반)
제3정규형(3NF) 위반 해소
① 고객 테이블과 직업 테이블로 테이블을 분리함
② 직업명은 직업코드에만 종속되므로 별도의 테이블로 분리 해야함
⇒ 이 때 직업코드를 참조키로 설정
제 4, 5 정규형
•
제4정규형 및 5정규형은 실무에서 거의 쓰이지 않음
•
제3정규형 까지만 완벽히 이해하는 것이 중요함
ER 다이어그램 (Entity-Relationship Diagram)
① 데이터 모델링 분야에서 개체-관계 모델이란 구조화된 데이터에 대한 일련의 표현이다.
② "구조"화된 데이터를 저장하기 위해 데이터베이스를 쓴다. 이 데이터의 "구조" 및 그에 수반한 제약 조건들은 다양한 기법에 의해 설계될 수 있다.
그 기법 중 하나가 개체-관계 모델링(Entity-Relationship Modelling)이다. 줄여서 ERM이라고 한다.
③ ERM 프로세스의 산출물을 가리켜 개체-관계 다이어그램(Entity-Relationship Diagram)이라 한다. 줄여서 ERD라 일컫는다. 데이터 모델링 과정은 데이터 모델을 그림으로 표현하기 위해 표시법을 필요로 한다
Barker 표기법
① 1986년에 영국 컨설팅 회사 CACI에서 근무하던 Richard Barker 등에 의해 개발
② 이후 지속적으로 개선되어, 오라클 사에서 기본 표기법으로 채택하고 사용하고 있음.
아래의 그림은 고객과 고객 주문 ⇒ one to many 관계 ⇒ 1:N
FK는 존재하지 않는 primary key를 참조할 수 없다. ⇒ 참조무결성
•
엔터티 (테이블)
1.
테이블과 유사하다고 할 수 있음
2.
#으로 시작하는 것은 식별자(기본키)
3.
로 시작하는 것은 NOT NULL
4.
°로 시작하는 것은 NULL
5.
끝에 (FK)로 끝나는 것은 외래키
릴레이션십(Relationship)
① 엔터티(테이블)과 엔터티(테이블) 사이의 관계를 말한다.
② 정의된 엔터티(테이블)은 대부분이 혼자서는 존재할 수 없음 관계가 정의 되어야 만 비로소 그 역할을 해낼 수 있음
③ 정리하자면 엔터티 간의 관련성을 표현한 것이고 핵심 사항은 FK(Foreign Key)인 컬럼은 부모 테이블의 기본키를 참고하고 있다는 것이다.
고객 엔티티(부모)에서 PK 인 고객 아이디가 고객 주문 엔티티(자식)에서 참조키로 쓰이면서 식별관계 성립
