개념적 설계 - (개체(Entity) 속성(Attribute) 관계(Relation))로 이루어진다
(객체지향 객체(Object) - DB 튜플(Tuple) 유사)
결과물 : (ER-D) 설계
DB의 전체 논리적 구조를 나타내는 조직의 스키마를 명시해서 DB를 쉽게 설계하도록 개발됨
실세계의 조직의 의미와 상호작용을 개념적 스키마로 나타내는데 매우 유용
데이터 베이스 설계
DB를 생성함에 있어, 요구사항 분석이 매우 중요하다. 요구사항 분석이 잘못되면 전체 설계가 틀어질 수 있기 때문
ER-D 설계 이상 -> 정규화를 통해 해결
정규화 -> 6단계가 있다
1NF) 원자값 분해
2NF) 완전 함수 종속 분해 (기본키의 부분집합이 결정자가 되선 안됨)
3NF) 이행적 종속 제거 (A->B, B->C)
BCNF) 모든 결정자가 후보키여야 한다
------------주로 사용--------------
4NF) 다치 종속이 없어야 함
5NF) 조인 종속이 없어야함, 조인 연산을 했을때 손실이 없어야 함

개체 (Entity)
실제 세계에서 다른 객체와 구별되는 유, 무형의 사물
속성(Attribute)
한 개체를 기술하기 위한 속성
개체 집합에 속한 모든 개체들은 동일한 속성을 가짐
가능한 값의 집합인 Domain을 지정하며, 개체를 식별하기 위한 Key 지정
단순 속성Simple Attribute과 복합 속성Composite Attribute
단일값 속성Single-value Attribute과 다중값 속성Multi-valued Attribute
유도된 속성Derived Attribute
개체 집합(Entity set)
개체들의 집합
학생 (학생 1, 학생 2, ... 학생 n)
교수 (교수 1, 교수 2, ... 교수 n)
함수 종속 - X와 Y를 각각 R의 속성(attribute) 집합의 부분 집합이라 하자. 속성(attribute) X의 값 각각에 대해 시간에 관계없이 항상 속성(attribute) Y의 값이 오직 하나만 연관되어 있을 때 Y는 X에 함수 종속이라 하고, X → Y라고 표기한다
즉) R 내의 속성(attribute) 의 집합 X와 역시 R 내에 있는 또 다른 속성(attribute) 의 집합 Y에 대해, 각각의 X 값에 대해 최대 한 개의 Y 값에 연관되어 있을 때, 속성(attribute) 의 집합 X를 함수 결정(to functionally determine)하다 한다
함수 종속의 종류 - 완전 함수 종속, 부분 함수 종속, 이행 함수 종속, 결정자 함수 종속, 다중값 종속, 조인(결합) 종속
테이블이 있을때 Column A, B가 있다 하자.
t1.A = t2.A이고 t1.B = t2.B이면 이를 함수 종속 된 상태 라고 한다.

관계 - 여러 개체들 사이의 연관성
관계 집합 - 같은 유형 관계들의 집합. n >= 2 개의 개체집합(중복허용) 사이의 수학적 관계
관계집합 참가 - 개체 집합 사이의 연관
역할 - 관계에서 개체가 행하는 기능
관계는 설명형 속성 이라는 속성을 가진다
관계의 관계모델 변환
관계에 참여하는 각 개체를 식별하고, 관계의 설명형 속성에 값을 줄 수 있어야 한다
참여하는 각 개체 집합의 기본키(외래 키 필드의 자격)
관계집합 자체의 설명형 속성
Chen's Notation
Mapping Cardinality - (1대1, 1대다, 0대1, 0대다, ... 등)
반드시 관계에 참여해야 하는 경우 - 실선
반드시 관계에 참여할 필요가 없는 경우 - 점선
-> Conceptual Design에 주로 사용
IE Notation
crow foot notation이라고도 한다
Mapping Cardinality, Cardinality Ratio 라고도 함
One to One
A의 한 개체는 B의 한 개체와 연관을 가지고 B의 한 개체는 A의 한 개체 연관을 가진다.
One to Many
A의 한 개체는 임의의 수 (0 또는 그 이상)의 B 개체와 연관을 가진다. 그러나 B의 개체는 A의 한 개체만 연관을 가진다.
Many to One
A의 한 개체는 B의 한 개체와 연관을 갖는다. 그러나 B의 개체는 A의 임의의 수 (0또는 그 이상)의 개체와 연관을 갖는다.
Many to Many
A의 한 개체는 임의의 수(0 또는 그 이상)의 B 개체와 연관을 갖고 B의 한 개체도 임의의 수 (0 또는 그 이상)의 A 개체와 연관을 갖는다.
릴레이션에서 키 제약 조건에 따라 대응수가 정해진다
개체집합 E가 관계집합 R에 대해 키 제약 조건을 가지고 있다면, E 인스턴스에 속한 개체는 R 인스턴스에 속한 관계중 하나에만 나타난다
3진관계 이상의 관계는 테이블 설계가 잘못될 수 있으니 반드시 확인해 봐야 한다.
OLTP 등...의 방법
DBMS 작성시 자동으로 int가 늘어나는 값을 만들고 싶으면 auto_increment 를 선언해 주면 된다
시간도 자동 삽입하고 싶다? datetime not null default current_timestamp
혹은 now() 해버리면 MySQL 8.0 부터 작동 가능
키가 존재하지 않는 개체집합
자신의 일부 속성과 다른 개체의 Primary Key를 조합하여야 유일하게 식별 됨
다른 개체를 식별 소유자(Identity Owner)라고 함
다음 조건들을 만족할 때 성립
식별 소유자와 약 개제 집합 사이에는 One-to-Many 관계 집합이 성립
약 개체 집합은 식별 관계집합에 전체적으로 참여하여야 함
소유자 개체에 대해 약 개제 하나를 유일하게 식별해 주는 속성 집합을
약 개체집합에 대한 구별자(discriminator) 또는 부분 키(Partial Key)라고 함
만약 약 개체집합을 유지하는 개체가 사라진 경우 관계가 있는 약 개체 인스턴스는 바로 삭제되게 해야 한다(ON DELETE CASCADE) - primary key가 당연히 없어서 상관없다
하나의 개체 집합은 집합내의 다른 개체들과 구분되는 개체들의 하위집합을 가질 수 있음
개체 집합 내의 어떤 부분집합은 개체 집합내의 모든 개체들과 공유되지 않는 속성들을 가질 수 있음
개체 집합에 속한 세부 개체들을 세부 부류(subclass)로 분류
포함 제약 조건(Inclusion Constraint)
중첩 제약 조건(Overlap Constraints)
두 서브 클래스에 같은 개체가 포함될 수 있는가를 결정
포괄 제약 조건(Covering Constraints)
서브 클래스의 모든 개체를 모으면 수퍼 클래스의 모든 개체가 되어야 하는가를 결정
ER 모델로도 모든 의미를 다 표현할 수 없다
ER 모델링은 스키마 설계에 대한 완벽한 방법은 아니다
속성으로 모델링 하는 경우
한 개체가 속성을 단일 값으로 가지는 경우(단일값이니 속성으로 빼자!)
요구 사항에서 수직, 수평적으로 분리될 수 없는 값인 경우
개체로 모델링 하는 경우
한 개체가 여러 값을 가지는 경우
ERD 에서 주소의 구조를 표현해야 하는 경우
개체
관계가 관계로 생성되는 한 개체에 국한되는 속성을 가짐
A 개체집합의 개체가 정확히 B 개체집합의 한 개체에만 해당
관계
관계집합에서 중복이 발생하는 경우
두 개체 사이에 일어나는 동작을 기술하는 경우(동사에 해당하는 경우)
이진 관계
약 개체가 포함되는 경우
관계의 변화가 개체에 영향을 미치는 경우
삼진 관계
관계의 변화가 개체에 영향을 미치는 경우
식별 관계의 체인이 존재하지 않는 경우