[CapstoneDesign #1] DB Design
첫 TIL을 기입해 보려고한다.
이번 학교에서 캡스톤디자인 이라는 과목을 수강하면서 실제 db를 설계해보는것을 팀원들과 함께 진행하였다.
이 과정에서 배운 내용을 정리하고자 한다.
[설계 과정 이야기]
일단 우리는 관계형 데이터 베이스를 설계하였다. 프레임워크는 spring boot 를 이용하기 때문에 이 관계형 DB를 java의 상속을 이용을 하기에는 해당 상속이라는 개념이 관계형 DB에는 없다.
관계형 DB에서는 슈퍼타입(super type), 서브타입(sub type) 관계를 이용하여 매핑한다.
이를 물리형으로 바꿀때는 아래 3가지 방안이 있다.
1. 각각 테이블 변환
2. 통합 테이블로 통째로 변환
3. 서브타입 테이블로 변환
정도로 본다.
이때 내가 선택한 방법은 1번인 각각 테이블 변환이다. 이는 join을 이용한 방법이다.
단, join을 많이 사용할 시에는 성능의 저하가 크게 발생할 수 있으니 설계를 신중히 해야한다.
아무튼 위와 같은 전략을 살펴본 후, 처음으로 구분해야할 내용은 식별관계이다.
[식별 관계]
식별관계 - 부모 테이블의 기본 키를 내려받아서 자식 테이블의 기본키 +외래키 로 사용한다.
비식별관계 - 부모키를 자식이 받아서 외래키로 사용하는것이다
DB 구성을 할때 주로 사용한것은 비식별 관계를 사용하였는데, 이는 각 테이블의 id는 따로 둠으로써 indexing 기능을 강화하고자 하였다.
이때 김영한님의 자바 orm jpa 프로그래밍에서도 비식별 관계를 선호한다고 써있는데, 이는 식별관계가 가지는 고질적 문제 ( 식별 관계로 가져가면 자식 테이블이 늘어가는 부모 키를 계속해서 가져가는 문제 ) 도 있고, 조인시 기본키 인텍스가 불필요하게 많아진다는 단점이 있기 때문이다. 따라서 주로 식별관계를 이용하는 경우는 비즈니스 의미가 있는 자연 키 컬럼을 조합하는 경우가 많다고 설명한다.
솔직히 1:1 관계를 제외한 나머지 관계들은 비식별관계를 사용하면 된다고 생각하면 편하지만, 굳이 이유를 따지자면 상단과 같은 이유를 가진다고 생각하면 편할것이다.
[용어 정리]
근데 그 전에 데이터 베이스를 수강하였다면 한번쯤은 들어 봤을 용어 정리를 하고 가는게 나을것 같다.
데이터 무결성(data integrity) 을 지키기 위해서는 데이터 무결성 제약조건( integrity constraint) 을 지켜야한다.
이떄 constraint는 규칙이다. 테이블에 규칙을 정해주면 데이터 무결성을 지킬 수 있다는 것을 의미한다.
그렇다면 데이터 무결성이란 무엇일까?
만약 데이터의 변경을 원하는데 인가(인증)이 되어있지 않은 방법이라면 변경할 수 없게 막아두는것이다.
이런 인가를 통하여 데이터의 변화를 최소화하여 정확하고 완전한 데이터를 얻을 수 있다.
이걸 왜 말하냐면 이러한 완전한 데이터를 위해서 데이터 베이스가 5가지 제약조건을 가지기 때문인데
1. unique -> 해당 데이터가 유일해야함
2. not null -> 해당 데이터가 비어있으면 안됨
3. primary key -> 위 두 조건이 모두 충족해야함
4. foreign key -> 해당 칼럼에 참조하는 테이블로부터 존재하는 값들만 사용한다 ( 단 , 자식 테이블이 부모 테이블을 참조하는 경우에 부모 테이블은 자신의 값을 삭제하지 못한다)
5. check -> 조건에 부합하는 데이터만 넣을수 있게한다
따라서 이런 제약조건을 알고 시작하면 더욱 이해가 쉬우므로 정리하도록 하자
[Relationship]
테이블간 관계는 관계를 맻는 테이블 수에 따라 아래와 같이 나눌 수 있다.
1. 일대일 (one-to-one)
2. 일대다(one-to-many)
3. 다대다(many-to-many)
여기서 가장 포인트가 되는건 위 제약조건에서도 설명한 foreign key 및 primary key이다.
위 관계형을 나타나기 위해서는 foreign key를 사용해야한다.
Foregin key는 다른 테이블의 행을 식별할 수 있게 한다.
그림은 쉽게 알아보기 위해 가져왔다
[자료출처. http://www.tcpschool.com/mysql/mysql_intro_relationalDB]
실제 내가 ERD에서사용한것을 간단히 확인하자면 다음과 같이 이루어져있다
1. Member - resume => 일대다
2. Member - scrap => 일대다
3. Resume - scrap => 일대다
1은 사용자는 여러 이력서를 가질 수 있다
2는 사용자는 여러개의 스크랩된 이력서를 가질 수 있다
3은 이력서는 스크랩을 할 수 있다.
정도의 관계를 가진다고 생각하면 될 것 같다.
해당 로직은 erdcloude 에 있는 OKKY의 구조를 많이 참고하였으므로 다음에도 본다면 참고하면 좋을것 같당
끝