데이터 모델링이란?
데이터 모델링이란 정보시스템 구축의 대상이 되는 업무 내용을 분석하여 이해하고 약속된 표기법에 의해 표현하는 것을 의미한다.
이렇게 분석된 모델을 가지고 실제 DB를 생성하여 개발 및 데이터 관리에 사용되는 데이터베이스 설계의 핵심과정이기도 하다.
특히 데이터를 추상화한 데이터 모델은 DB의 틀을 이해하고 그 이해를 바탕으로 SQL문장을 기능과 성능적인 측면에서 효율적으로 작성하기 위해 알고 있어야한다.
절차
1. 업무파악
2. 개념적 데이터 모델링
3. 논리적 데이터 모델링
4. 물리적 데이터 모델링
1. 업무 파악
어떠한 업무를 시작하기 전, 해당하는 업무에 대해 파악하는 단계
정확한 모델링을 하기 위해서는 업무파악은 필수적이다.
2. 개념적 데이터 모델링
일의 데이터 간의 관계를 구상하는 단계
데이터베이스 ERD 다이어그램을 표로 그리기전에 간단한 도형으로 만들어보는 개념적 데이터 모델링이라고 이해 하면된다.
도형의 의미하는 바를 알고 화살표를 통해 관계를 표현하기만 하면 된다.
Tool : https://app.diagrams.net/
3. 논리적 데이터 모델링
엔티티 중심의 상위 수준의 엔티티 중심의 모델이 완성되면, 구체화된 업무 중심의 데이터 모델을 만들어 내는데 것을 논리적인 데이터 모델링이라고 한다.
이 단계에서 업무에 대한 Key, 속성, 관계 등을 표시하며, 정규화 활동을 수행한다.
정규화는 데이터 모델의 일관성을 확보하고, 중복을 제거하여 신뢰성있는 데이터 구조를 얻는데 목적이 있다.
위에서 구현한 개념적 ERD다이어그램을 테이블 형태로 재 구성한다.
이 단계에선 단순히 추상적인 데이터에서 보다 구체화적인 데이터로 작성한다.
예를 들어 회원정보의 아이디, 비밀번호에 각 데이터 타입을 명시해 주고 각 데이터간의 관계를 정밀하게 맺어주며 테이블의 키를 지정해준다.
4. 물리적 데이터 모델링
물리적 데이터 모델ㄹ링은 최종적으로 데이터를 관리할 데이터베이스를 선택하고, 선택한 데이터베이스에 실제 테이블읗ㄹ 만드는 작업을 말한다.
시각적인 구조를 만들었으면 그것을 실제로 SQL 코딩을 통해 완성하는 단계
/* 테이블 생성 */
-- 회원정보
create table member_tbl (
member_uid bigint primary key auto_increment,
member_name varchar(45) unique not null,
member_pwd varchar(45) not null,
member_status boolean not null
);
-- 로그인기록정보
create table login_info_tbl(
member_name varchar(45) not null,
info_ip varchar(45) not null,
info_date datetime not null,
constraint fk_member_name foreign key (member_name) references member_tbl (member_name)
);
ERD 구성요소 및 표기법
Entity
엔티티는 정의 가능한 사물 또는 개념을 의미한다.
사람이나, 객체 혹은 개념이나 이벤트 들을 엔티티로 둔다.
Entity Attribute
각 각의 Entity에는 속성(Attribute)을 포함하고 있다. 필드(컬럼)명을 쓰면 된다.
Entity 분류
엔티티도 저장하는 데이터 정보 주제에 따라 종류가 구분된다.
키와 제약조건
PK (primary key)
- 중복이 없고 NULL 값이 없는 유일한 값에 지정하는 키
- 보통 대부분의 ERD 다이어그램 툴에서 열쇠 표시로 나타낸다.
- 아래 이미지에서 IDMember 필드를 기본키로 지정하고, 아래 사진에선 열쇠 표시를 주어 기본키임을 명시했다.
NOT NULL
Null을 비허용한다면, N을 적고, Null을 허용하면 N을 적지 않는다.
FK (Foreign Key)
Foreign Key를 표시할 때에는 선을 사용하는데 개체와 관계를 따져 표시한다.
외래키 역시 Key의 일종이라 ERD 엔티티에도 열쇠 아이콘으로 표시한다.
다만 PK와 구분하기 위해서 색을 다르게 하는 편이다.
아래 사진에선 Team 엔티티와 Member 엔티티가 서로 1 대 다 관계를 맺었고, TeamID를 외래키로 지정하여 Team 엔티티의 PK와 연결시켰다.
-
하나의 팀에 여러 멤버가 해당될 수 있기 때문에
선 긋기
두 개체의 관계 - 점선/실선
-
먼저 두 관계중 부모의 키를 PK로 받는지 안받는지에 따라 점선, 실선 표기가 다르게 된다.
실선 : 식별 관계
-
부모 자식 관계에서 자식이 부모의 키를 외래키로 참조해서 자신의 키로 설정
점선 : 비식별 관계
-
부모 자식 관계에서 자식이 부모의 키를 외래키로 잠조해서 일반 속성으로 사용
선 모양
두 개체의 관계 - 선의 끝 모양
관계가 존재하는 두 entity사이에 한 entity에서 다른 entity 몇개의 개체와 대응되는지 제약조건을 표기하기위해 선을 그어 표현한다.
대표적으로 Mapping Cardinality의 종류는 다음과 같다.
One to one : 1 대 1 대응
One to many : 1 대 다 대응
Many to one : 다 대 1 대응
Many to many : 다 대 다 대응
ERD 다이어그램에 저렇게 선들을 막 긋는다면 가독성이 매우 안좋아지고 표가 더러워지기 때문에, 이러한 엔티티간의 1 대 다의 관계를 표기 하기 위해 ERD에서는 선의 끝 모양을 다르게 표시하는 방법을 사용한다.
두 개체의 관계 필수 / 선택 기호
- '|' 표시가 있는 곳은 반드시 있어야 하는 개체. 필수
- 'O' 표시가 있다면 없어도 되는 개체. 선택
필수 사항과 선택사항을 구분하기 위해 사용된다.
효율적인 모델링 작업하기 (feat. 정규화)
문제 : 도서 엔티티에 관해서 말하면, 도서관의 같은책(이름이 같은)이 있다는 가정하에 모델링을 했음에도 불구하고, 이 것을 효율적으로 못한 모델링을 한 표본이 되고 말았다. 자세한 정규화 알아보기
왜내하면 도서번호로 같은 책이 있더라도 번호를 달리해 구분은 가능할지 몰라도, 똑같은 자료를 중복하게 되는 구조여서 결과적으로 데이터 공간을 낭비하는 결과를 초래한다.
즉, 도서관의 실제도서를 나타내는 Entity와 실제도서의 속성을 정의하는 Entity를 구분해야된다는 말이다.
- https://inpa.tistory.com/entry/DB-%F0%9F%93%9A-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EB%AA%A8%EB%8D%B8%EB%A7%81-1N-%EA%B4%80%EA%B3%84-%F0%9F%93%88-ERD-%EB%8B%A4%EC%9D%B4%EC%96%B4%EA%B7%B8%EB%9E%A8
- https://dba.stackexchange.com/questions/51073/er-relation-with-unique-keyVisit Website
- https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=lkwook2&logNo=100116488273Visit Website
- https://gitmind.com/kr/er-diagram-tool.htmlVisit Website
-https://rpubs.com/qkdrk777777/516343Visit Website
-https://parkhyeokjin.github.io/others/2018/11/07/DbERD.htmlVisit Website- https://gngsn.tistory.com/48
