<DB모델링의 주요 개념>
1) 엔티티(Entity, 개체)
== 자바에서의 클래스, 오라클에서의 테이블과 같은 개념
업무의 관심 대상이 되는 유형, 무형의 사물(개체)
엔티티 조건
- 업무의 관심 대상이 되는 사물이어야 함
- 두 개 이상의 인스턴스를 소유해야 함
- 마땅한 속성을 소유해야 함
2) 속성(Attribute)
== 자바에서의 필드, 오라클에서의 컬럼과 같은 개념
엔티티에서 관리해야 할 최소 단위 정보 항목
엔티티는 하나 이상의 속성을 포함
속성의 명명 규칙
- 속성의 의미가 분명히 드러나게 작성
- 업무에서 사용하는 이름 부여 (학생/수강생은 가능하지만 우리반사람들 안 됨)
- 서술식, 약어, 수식어, 소유격은 사용하지 않음 (EMPLOYEE를 E로만 표현하는 건 좀...)
- 엔티티에서 유일하게 식별 가능하도록(중복 X) 지정할 것
3) 인스턴스(Instance)
== 자바에서의 객체, 오라클에서의 튜플, 행과 같은 개념
엔티티의 속성으로 실제로 구현된 하나의 값
4) 관계(Relationship)
두 엔티티 사이의 관련성을 나타냄
5) 카디널리티(Cardinality)
각 엔티티에 속해 있는 인스턴스들 간에 수적으로 어떤 관계에 있는지를 나타냄종류는 1:1, 1:N, M:N 관계가 있음(M:N은 개념적으로만 존재할 뿐 실제 DB로는 구현 불가함)
6) 주식별자(Primary Identifier)
== 오라클에서 기본키
엔티티 내 각 인스턴스를 구별하는 기준이 되는 속성
*주식별자의 4가지 특성(최근 sqld 단골 문제)
모두 만족해야 주식별자가 될 수 있음
유일성 | 식별 가능한 중복 안 되는 값이어야 함 (UNIQUE) |
최소성 | 테이블당 하나씩만 존재해야 함 (한 테이블당 하나의 PK) |
불변성 | 값이 웬만해서는 수정 불가해야 함 |
존재성 | 값이 무조건 존재해야 함 (NOT NULL) |
7) 외래식별자(Foreign Identifier)
== 오라클에서 외래키
관계가 있는 엔티티 간의 연결고리 역할을 하는 속성
<DB 설계>
1) 개념적 설계(개념적 모델링)
👉🏻 설계 도면을 만드는 단계 (ERD)
요구분석 단계에서 정의된 핵심 개체와 그들간의 관계를 바탕으로 ERD를 생성하는 단계
- Entity 정의 (엔티티 도출 - 요구사항 명세서를 확인하며 엔티티와 속성 도출 및 추가/제거 판단)
- ERD(Entity-Relationship Diagram, 개체 관계도) 분석하여 엔티티와 속성을 그림으로 그려 관계 도출
사원은 부서를 가지지 않을 수도 있지만(선택적, 새로 입사한 경우) 부서는 필수적으로 사원을 가져야 한다
한 부서에 많은 사원(多)이 들어갈 수 있지만 한 사람은 오직 하나의 부서(1)만 가질 수 있다
주식별자는 하나가 아닌 여러 속성일 수 있음 (복합키) 프로젝트 때는 하지 마세여! 나중에 코드 짤 때 불편함
엔티티의 속성 중 주식별자 속성이 없다면 새로운 속성을 만들어 줌 (프로젝트 때 활용! 없으면 시퀀스 따기)
관계가 있는 두 엔티티를 부모, 자식 엔티티로 구분한 후 부모의 주식별자와 공통 속성이자식에게도 존재하면 해당 속성을 외래 식별자로 지정
식별 관계: 다른 테이블에서 끌고 온 외래키가 기본키가 되는 경우 (복합키가 됨, PFK)비식별 관계: 다른 테이블에서 끌고 온 외래키는 그냥 외래키로만 씀(FK)
결론
* 복합키 지양
* 인위적 주식별자 사용 권장
* 웬만해서는 비식별관계 => 훨씬 쉬움!
2) 논리적 설계(논리적 모델링)
👉🏻 설계 도면을 다듬는 단계, 테이블을 구체화해서 쪼개는 단계, 중복을 최소화하는 단계
개념 설계에서 추상화된 데이터를 구체화하여 개체, 속성을 테이블화하고 상세화하는 과정
정규화
관계형 데이터베이스에서 데이터를 구조화하는 작업
최대한 테이블을 쪼개는 상세화 과정 (= 정규화)
정규화의 목적
- 데이터 중복 방지
- 무결성 보장
- 정규화를 하지 않으면 삽입, 삭제, 갱신 이상 발생 가능성이 커짐
- 삽입 이상: 불필요한 정보를 함께 저장하지 않고는 어떤 정보 저장이 불가능
- 갱신 이상: 반복된 데이터 중 일부만 수정하면 데이터의 불일치가 발생
- 삭제 이상: 유용한 정보를 함께 삭제하지 않고는 삭제가 불가능
제1 정규화
=> 한 컬럼의 값이 여러 개일 경우 테이블 쪼개기 (도메인이 원자값을 갖도록)
컬럼에 여러 개의 값들이 들어가는 것을 해소
제2 정규화
=> 복합키일 경우 행해짐 (부분 함수적 종속 제거)
== 모든 일반 컬럼은 반드시 주식별자 전부에 종속되어야 함
복합키가 있는 상황에서 나머지 일반 컬럼 중 복합키 중 하나에 해당하는 애들만 따로 빼자
주식별자가 아닌 속성 중에서 주식별자 전체가 아닌 일부 속성에 종속된 속성을 찾아 제거하는 것
주문번호, 품목코드가 모두 기본키인 복합키인데 품목단가는 품목코드랑만 관련 있으므로
품목코드는 따로 빼 버리고 기본키/외래키랑 묶자!
제3 정규화
모든 속성이 기본키에 직접 종속되도록 => (이행적 함수 종속 제거)
주식별자가 아닌 속성들 중에서 종속 관계에 있는 속성을 찾아 제거하는 것
고객번호로 이미 고객 식별 가능한데 주문 테이블에 굳이 고객명, 고객 주소가 들어갈 필요가 있을까?
그냥 고객 테이블 만들어서 빼 버리자~!
BCNF - 모든 결정자가 후보키
제4 정규화 - 다치 종속 제거
제5 정규화 - 조인 종속성 이용
다시 결론(이걸 지키면 굳이 정규화 필요 없음)
* 복합키 지양
* 인위적 주식별자 사용 권장
* 웬만해서는 비식별관계 => 훨씬 쉬움!
3) 물리적 설계
👉🏻 데이터베이스 실물을 만드는 단계, DDL 작성 후 실행/구축하는 단계
논리적 설계 단계에서 표현된 데이터(ERD)를 실제 컴퓨터의 저장장치에 어떻게 표현할 것인가 (관계형 데이터베이스로 전환)
정규화 작업 이후 JOIN을 너무 많이 실행해야 할 것 같다면
물리적 설계 단계에서 반정규화 진행
DB 모델링 툴 활용: https://www.erdcloud.com/
내보내기 - SQL 미리보기 클릭 시 DDL 구문 만들어 줌!
MySQL 기준이라 맹신은 하면 안 됨