jpa
db
erd 다이어그램을 그리는 것이 좋다. erd는 요구사항을 모델링하는 한 방법이다.
목표: 주어진 스키마가 어떤 정규형을 만족하는지 판단할 수 있다.
db디자인의 최종 목표는? sql이 나오는 것이다.
데이터베이스 설계는 테이블을 만드는 과정이다.
테이블을 만드는 과정은 애트리뷰트를 어떻게 묶을 것인지를 결정하는 것이다. 좋은 테이블을 설계하는 것이란 애트리뷰트를 잘 묶는 방법이다.
mysql스토리지는 innodb와 myI3??
sql은 db에 종속적이다. 설계를 여러 과정으로 나눠 개념적, 논리적, 물리적 설계로 단계를 나누고, 물리적 결과물이 sql이고 개념적 설계의 결과가 erd이다. erd는 컨셉츄얼하기에 논리적 산출물
속성=애트리뷰트
우리가 원하는 베스트 스팟은 한 테이블밖에 없는 것과 칼럼수만큼 N개만큼 있는 것의 중간에 있따. 결국 좋은 테이블을 설계하는 것은 애트리뷰트를 잘 묶는 것이다.
테이블과 1대1로매핑되는 것은 엔티티이다. 자바에 있는 특정 비즈니스 모델을 구현하는데 필요한 엔티티라는 애가 db 테이블이 된다. jpa에는 그것을 독립적으로 나눠놨다.
모델과 엔티티는 비슷한데, 도메인과 엔티티는 다르다. 모델은 mvc컨셉에서 나온 말이다. model view controller로 나눠 controller은 로직, model은 데이터, view는 보여지는 것이다. 테이블은 레코드 필드, 로우 칼럼, 엔티티 애트리뷰트라고 말한다.
DDD는 우리가 풀어야할 문제 그 자체를 도메인이라고 한다.
쇼핑몰 도메인이 도메인이다. 이것이 서브 도메인으로 나뉘어, 게시판 도메인, 결제 도메인 등등이 된다. 즉 해결해야할 문제의 집합이다. 옛날로 따지면 프론트, 백, dba 있었는데, 이제는 정산팀, 결제팀 등으로 나눈다. 조영호의 오브젝트에 따르면 패러다임은 단순한 뜻이었는데, 과학자가 논문을 썼는데 이전에는 조금씩 발전했던반면, 이제는 혁명적 이론으로 사람들의 생각이 완전히 바뀌는 것을, 모든 사람이 공통적으로 가지는 세상에 대한 인식을 패러다임이라고 한다. 패러다임의 전환이 항상 있다. 이 전환이 있음으로써 사실이 바뀌는 것처럼 인식된다. 자연은 그대로지만 인간의 사고가 바뀐다. 조영호 작가에 따르면 개발에도 이게 있어서 ... 공통적으로 가지고 있는 oop패러다임으로 개발해서 비용을 줄여보자고 한다. 패러다임을 근거로 어떤 방식의 개발을 주장하면 다들 납득한다.
다만 과학과 달리 개발 패러다임은 상호배타적이지 않고, 상호보완적이다.
DDD가 요즘 세상에서 통하는 패러다임이다 이거임.
엔티티란, ddd에서 하위개념으로 엔티티가 등장한다. 영속적인 값을 구별할수있고, 내 도메인로직을 구현하기 위해 필요한 유니크한 identifier을 가진 것이다.
VO와 엔티티의 차이는? 식별자의 유무 차이이다. VO는 식별자가 없고, 엔티티는 식별자가 있어 유니크하게 자기 자신을 식별할수있다. VO는 immutable해서 값이 변할수없다. 엔티티는 상태를 가지기 때문에 mutable하다. 엔티티가 유니크한 identifier을 갖는것은 다른 상태들이 변하기 때문이다.
메소드는 상태를 변화시킨다.
잘 설계된 테이블:
다른 테이블의 애트리뷰트 값을 읽어오는 것은 외래키의 참조를 통해서만 가능해야한다. (자바의 디미터 법칙과 유사하다는,, 호눅스 생각)
Database Normalization
잘못된 설계 테이블은 이상현상 생길 수 있으므로 정규화를 해줘야한다. 이상현상이 생기는 테이블을 나누는 것, 쪼개는 것을 정규화라고 하며, 1정규형, 2정규형 , bcnf??가 있다.
단계가 높을 수록 이상현상이 덜 발생한다. 4nf가 나온 이유는 3nf나 bcnf에서도 이상현상이 생긴 것이다. 4nf도 불완전해서 5nf가 나오고, 6nf가 나왔다. 실무에선 전혀 사용안된다. 테이블을 조갤 수록 조인을해야하고 성능이 떨어지고 관리가 힘들어진다. 그래서 실무에서는 3nf bcnf 이상으론 사용하지 않는다.
employee와 department를 한 줄 에 둔다면?
삽입이상: 새로운 부서를 만들려면 반드시 그 부서에 사원이 있어야 한다. 사원이 없는 새로운 부서를 만들 수 없다.
삭제이상: 마지막 사원이 나가면 부서가 사라짐
갱신이상: 팀 이름이 변경되면 전부 다 바꿔야함.
이게 다 정규화가 안됐기때문에 발생하는 문제이다.
정규형:
이상현상이 잘 안생기는 좋은 테이블이 갖추어야할 조건.
1,2,3정규형과 BCNF 수준까지 알면 초보 수준에서 문제 없다.
정규화: 테이블이 정규형을 만족할 수 있도록 잘 분해하는 과정
-1정규화-> 테이블이 1정규형을 만족하게 됨.
함수적 종속성:
두 애트리뷰트 x, y에서 x가 y를 함수적으로 결정하면, x->y와 같이 표현할수있다. x가 y를 결정한다. x가 결정되면 y가 결정된다. x값이 유일한 y값을 결정한다. (여러 x에 대해 하나의 y인건 ok, 하나의 x에 대해 여러 y인것은 안됨.) 1대다는 함수적 종속이 안된다.
y는 x에 함수적으로 종속된다.
y값이 달라지면 x는 반드시 달라진다. (반면 x가 달라져도 y는 같을 수 있다.) (x=3와 같은 그래프는 어떤 y에 대해서도 x=3이라, y달라져도 x는 달라지지 않음. 함수 아님)
1.주민번호->이름: 다른 이름이면 반드시 다른 주민번호이다. 함수적 종속적 yes
2.부서ID->부장이름
3.이름->직속상관: no 직속상관이 다른데 이름이 같을 수 있다.
pk는 다른 모든 애트리뷰트를 함수적 결정한다. pk는 해당 다른 한 테이블의 모든 애트리뷰트를 함수적으로 결정하는 애트리뷰트를 pk로 할 수 있다.
슈퍼 key:
애트리뷰트의 집합.
고유하게 식별됨.
슈퍼키는 한 애트리뷰트가 아니라, 애트리뷰트란 단어는 erd에서 entity relationshiP/??? 어쩌고다.
고유하게 식별할 수 있는 애트리뷰트의 집합을 슈퍼키라고 한다. 사번+부양가족이름으로 모든 사원을 고유하게 식별할수있다. 사실 사번만으로도 고유하기때문에 부양가족이름까지 합치면 당연히 고유하다. 주민번호앞뒤자리+이름도 고유하다.
모든 애트리뷰트 다 합치면 고유하게 식별할수있기에 슈퍼키라고 할 수 있다.
후보키:
슈퍼키의 부분 집합.
구성 애트리뷰트 중 하나라도 제거하면 슈퍼키가 아닌 것.
슈퍼키에서 군더더기 제거한 것.
1.사번+부양가족이름에서 부양가족이름을 제거한 사번. 사번만으로 유니크하니까.
2.주민번호앞자리+뒤자리+이름에서 이름을 제거한 주민번호앞뒤자리. 주민번호7자리만으로 유니크하니까.
후보키라고 부르는 이유는? 후보키 중 하나가 pk가 된다. 후보키는 pk의 후보이다.
jpa를 쓰면 언제나 인공키를 선택한다.
Long id는 현실에 존재안하고 인위적으로 identity를 부여한 것이기에 인공키라고 부른다. 반면 사번 같은 것은 natural키이다.
내츄럴 키를 사용하면 장점이 많다. dba는 인공키를 싫어한다.
기본키: primary key
여러 후보 키 중 대표적이 ㄴ키 하나가 테이블의 기본키가 된다. 우리가 선택한다.
후보키는 유니크하게 식별할수있는 것이라고 했는데, 이것을 다시 말하면
한 테이블의 다른 애트리뷰튜를 함수적으로 결정하는 애트리뷰트를 후보키라고 말할 수 있다.
ssn->ename을 결정한다. ename다르면 ssn같을수가 없다.
후보키는 다른 애트리뷰트를 함수적으로 결정하는 키고, 그 중하나가 pk가 된다.
제 1정규형
테이블은 반드시 하나 이상의 키(pk)를 가지고 있어야 한다.
애트리뷰트의 도메인이 오직 원자값만을 포함한다.
원자값이란, 더 이상 쪼갤 수 없는 값이다. multi-value를 허용하지 않는다는 뜻이다. json은 array가 되므로, 1정규형을 위배하는 것이다. 정규형의 sql만으로 데이터 조작을 끝내갰다는 목표를 위배하는것이다.
스토리지의 값이 싸져서 이런 것이 덜 중요하게 됐다. 지금은 개발 비용 중 인건비가 제일 많이 든다.
제1정규형은 복합 애트리뷰, 다중 애트리뷰트, 중첩 릴레이션을 허용안한다. 중첩릴레이션은 속성을 테이블로 갖는 것..??? 이다.
1정규형을 위배하면 테이블이라고 볼수도 없고, ..
완전 함수적 종속과 제 2정규형
완전함수적 종속: abc->x라고 할 때, (멀티애트리뷰트가 하나의 함수적 종속을 결정) abc 중 하나라도 제거하면 함수적 종속이 발생하지 않는 경우. 주민번호앞/뒤자리가 예시이다.
x 는 임ㅇ의의 a애트리뷰트를 말한다.
부분함수적종속: 완전함수적 종속이 아닌 경우 부분 함수적 종속이라고 한다.
abc->d인데, bc->d이다. 두개 다 성립하면 부분함수적 종속이다.
제2정규형
1정규형을 만족하면서 후보키가 아닌 애트리뷰트들이 후보 키에 대해 완전 함수적 종속인 경우.
후보키가 아니면서 부분함수적 종속이 발생하면 안된다. 즉, 부분함수적 종속이 일어나면 안된다는게 한줄요약이다.
그
ssn단독으로는 pname을 결정할수없다. pnumber로는 ename을 결정할수없다. ssn 과 pummber이 쌍으로 결정한다. 완전 함수 종속이 되도록 테이블을 쪼개야한다.
emp는 ssn뿐이다. emp(ssn,ename)데이
이행 종속과 제 3정규형
이행종속이란: x-> y 이고 y->z 이면 x->z . x가 y를 함수적 결정하고,, 함수적 결정 관계이다.
제3정규형
2정규형을 만족하면서 (후보키가 아닌 애트리뷰트들에서 이행 종속이 발생하지 않는다.
ssn-> dnumber ->dname 사이 이행 종속이 발생해 결과적으로 ㄴssn->dname이 되긴한다. 그렇지만 이것은 그냥 종속이 아니라 이행종속이다. 이것이 발생하지 않도록 쪼개야한다. dept(dnumber, dname, dmgrssn) 날려줘서 테이블 두개로 만들면 된다. 테이블 쪼갠 대신에 emp(ename, ssn, bdate, addressm dnumber)로 emp 마지막에 외래키(dnumber)을 넣어줘야한다.
bcnf:
x->y인 모든 xy에 대해
1)y가 x의 부분집합이거나
2)x는 후보키여야 한다.
후보키가 아닌 애트리뷰트가 다른 애트리뷰트를 함수적으로 결정하면 bcnf가 아니다.
cycle이 생기면 bcnf가 아니다. 키 말고 결정하는게 있으면 안된다.
싸이클이 생기는 것을 따로 떼내면 된다.
pk는 물리적 db이고, 우리가 말하는 것은 논리적 디자인이다.
1정규형의 핵심 키워드는: 테이블에 후보키가 있어야한다.(기본키 아님!) 후보키가 원자값이다.
2정규형은 부분함수적 종속이 없고 완전함수
3정규형 이행종속 있으면 안된다
bcnf 후보키 아닌 애트리뷰트가 다른 애트리뷰트를 함수적으로 결정하면 안된다.
