[설계] 데이터 모델링

adam adam·2022년 10월 28일

개요

데이터베이스를 위한 개념 데이터 모델링
데이터베이스의 논리 데이터 모델링
데이터베이스에 의한 물리 데이터 모델링

데이터 모델링은 데이터베이스에 기록하기 위한 데이터 우선순위 결정 과정. 그리고 주 기록 대상은 비즈니스 또는 상대방에게 소중한 것

데이터베이스는 도서관처럼 1명의 개인이 쓰기에는 충분하나, 여럿이 사용하면 언제나 공간이 부족하고, 뒤죽박죽. 우선 100GB정도의 데이터베이스를 상정하고 생각하겠음.

매번 그렇듯이, 비즈니스는 혼자 하는 게 아니라 여럿이 하거나 서로 상이한 자료를 바탕으로 하는 것, 그러면 직관적인 그림으로 협업. 대표적으로 Entity Relationship Diagram(ERD)

데이터베이스를 위한 개념 데이터

데이터베이스는 좁으니까, 중요하고 의미있는 데이터(= 핵심적인 개념데이터)만 추출해서 담아야함

ERD의 시작: 자료 속 핵심을 찾자

자료 요약하기

이런 작업은 순수하게 사람 머리속에서 개념적으로 작동한다고 생각중. '개념적'이라는 단어 참 편리하다

요약에서 ERD 만들기

Entity도 단위로서 우선 수용. 보다 정확히는 데이터베이스에 중요한 것만 기록하기 위한 생각의 단위.

데이터 표준화

감자탕을 시켰는데, 고기가 나와서 감자가 안나와도 넘어갔지만, 사실 감자탕의 감자가 potato가 아닌건 꽤 신기했던듯,

이렇듯 데이터에다가 이름 정할때 동음이의어가 있으면 명확히 해주고, 공유해야 혼란 최소화
협업의 1단계는 용어와 의미의 통일

데이터 표준화 문서 구글 docs(미완)

데이터베이스의 논리 데이터: 연상과 연결 데이터

관계(=연상하고 연결하기)를 짓다
1. 이미 두 눈에 보이는 엔터티 간에 연결을 짓다
2. 눈에 보이는 엔터티로부터 눈에 안보이는 엔터티를 연상하고 연결하다

근데 내가 경험해보지 못한 영역에 대해서 눈에 안보이는 걸 연상한다는 건 불가능한듯, 사장님이 도와줘야함.

ERD 눈에 안보이는 것

주어진 자료에는 사실 요구사항관리시스템으로 명시되어있으나, 내 개인적인 사고 흐름 속에서 나는 프로젝트관리시스템이 보다 포괄적인 표현이라고 나도 모르게 생각했음

그래서 눈에 보이지는 않지만, 제안요청서라는 엔터티를 연상하고 프로젝트 엔터티와 연결함

하지만 앞서 말했듯이, 데이터베이스는 노트북 HDD처럼 유한한 물리적 공간(나는 100GB 상정)을 가짐. 분명 제안요청서는 필요한 정보이지만, 이미 word나 한글로 제공된다고 할 때, 이를 추가적으로 재가공해서 데이터베이스에 담을 만큼 최우선 순위인지는 현재 나의 역량으로는 가늠이 안됨.

모든 고객사가 제안요청서를 어떻게 보내는지는 몰라도, 거기에 관심있는 수주사는 제안요청서를 반드시 저장해놓을 테니, 파일서버가 됬든 하다못해 서랍장이든 저장위치 칼럼 추가하면 해결될듯

관계 짓기와 Primary key

데이터베이스에서는 관계는 primary key 설정으로 실현한다고 생각중.

관계 짓기를 A -> B 로 연결 짓는 것으로 생각중
A를 대표할 수 있는 A의 primary key를 B에서 Foreign key로 설정함으로서
A의 중요 속성을 B가 가지게 되었으니, 구체적인 Query를 통해 A는 B를 찾아갈 수 있고,
B도 A를 찾아갈수 있게 되니까?

한편 primary key는 일반적으론 index 기능을 가지는데, index의 value가 변환을 거쳐 최종적으로 원통 좌표계 상의 벡터로 표현되고, 이에 따라 물리적으로 실재하는 HDD의 head를 향해 디스크를 회전시키걸로 생각하는 중. 그러면 여기서부터 물리단계로 넘어가는 느낌.

SSD는 심신안정을 위해 패스