2020. 6. 15. 15:43ㆍ컴퓨터언어/Database
데이터베이스를 만들 때는 다음과 같은 순서를 따른다.
1. 사용자의 요구분석을 한다. - DA(Data Analyst)의 전문영역
고객이 "이러이러한 데이터베이스를 만들어주세요" 라고 의뢰한 것을 수락하고 분석하는 단계.
2. 개념적 설계를 한다. - DA(Data Analyst)의 전문영역 => 개념 스키마 도출
현실 속 정보를 컴퓨터에 데이터베이스화할 대상체(Entity)를 결정하는 단계(Data Modeling).
학생들의 정보를 데이터베이스화한다면, 학생들의 정보가 <학생>이라는 개체(Entity)가 되는 것이고, 그 <학생>이라는 현실 속 개념을 컴퓨터 내 개체로 표현하기 위해서 필요한 것이 속성(Attributes)이다.
만약 <학과>라는 개체도 동일한 방법으로 따로 데이터베이스화했다면, <학생>과 <학과> 개체의 관계(Relationship)도 고려해야 한다.
이를 ER(Entity-Relationship) 스키마라고 한다.
그런데 이 모든 과정이 너무도 추상적이고 눈에 보이지 않기 때문에, 사람이 이해하기 쉽게 만든 것이 ER 다이어그램이다.
3. 논리적 설계를 한다. - DBA(Database Analyst)의 전문영역
개념적 설계에서 만들어 놓은 ER 다이어그램을, 가장 보편적인 데이터모델인 관계스키마(테이블)로 Mapping(대응, 함수화, 사상)하는 단계.
<Mapping Rule> - 두 테이블 간 관계에 따라 다음과 같이 설계를 달리한다.
1:1 => 어느쪽에서 참조하든 상관없다.
1:n => 1의 기본키를 n의 외래키로 삼고, n에서 1의 방향으로 탐색한다.
n:m => n의 기본키와 m의 기본키를 모두 기본키로 갖는 새로운 교차테이블을 생성한다.
하지만! 지금까지 ER 다이어그램을 만들고 이를 바탕으로 관계스키마까지 만든 것은, 단지 현실 속 개념을 컴퓨터로 표현하고자 속사포로 진행한 다소 이상(ideal)적인 목표이지, 아직 데이터베이스의 효율성까지 고려하지는 않았다.
만약 개념적 설계에서 나온 개념 스키마에 무언가 잘못된 것이 있었고, 이를 제때 고치지 않는다면 나중에 서비스가 커졌을 때 엄청난 비용을 지불해야 할 수 있다.
그래서 필요한 것이 "스키마 정제" 과정이고 "정규화"이다.
2020/06/16 - [컴퓨터언어/Database] - [정규화] 효율적인 데이터베이스 스키마 구축
2020/06/17 - [컴퓨터언어/Database] - [정규화] 효율적인 데이터베이스 스키마 구축 2
4. 물리적 설계를 한다. - DBA(Database Analyst)의 전문영역 => 내부 스키마 도출
논리적 설계와 물리적 설계는 모두 DBMS에 맞게 설계해야 한다.
논리적 설계에서 개념 스키마를 관계 스키마로 바꾸고 정규화했다면, 물리적 설계는 정규화된 테이블의 성능을 극대화하는 단계이다.
그럼 어떻게 성능을 극대화할까? 다음과 같다.
- 저장될 데이터의 자료형과 크기를 미리 정해줌으로써 메모리 낭비를 방지한다. ex 이름 속성에는 10바이트면 된다.
- 사용자가 데이터베이스에 질의(쿼리)를 보내고, 그 질의에 따라 정보를 가공하고 보여주기까지 필요한 모든 트랜잭션(연산들의 집합)을 예측하고 분석한다.
- 트랜잭션을 예측분석 했을 때, 만약 쿼리마다 여러 테이블로부터 조인을 해야 해서 트랜잭션이 엄청 부담되고 그 빈도도 높을 것이 예상된다면, 논리적 설계에서 행한 정규화를 다시 취소하여 테이블을 합칠 수 있다. 이를 "반정규화(De-nomalization)"라고 한다. 이상현상(Anamoly)을 감수하더라도 비싼 컴퓨팅 자원을 쓰는게 결국 다 돈이기 때문이다(무결성,정합성 vs 단순화,성능).
- 검색이 자주 되는 데이터들을 저장장치 내에서 서로 가깝게 배치하여 접근 속도를 향상시킨다(Clustering).
2020/06/17 - [컴퓨터언어/Database] - [반정규화] 논리적 설계에서의 정규화가 오히려 독일 때
하지만 반정규화는 무결성에 위배되는 것이기 때문에, 성능을 위한다고 무조건 사용하는 것이 아니고, 먼저 "뷰 설계"나 "인덱스 구축"이나 "클러스터링" 등으로 문제를 해결할 수 있는지 먼저 파악하는 것이 중요하다.
2020/06/17 - [컴퓨터언어/Database] - [View 설계 & Index 구축] 반정규화를 하기 전 고려해야 할 선택지
5. DDL로 실제 데이터베이스를 구현한다.
운영체제 덕분에 인간과 컴퓨터가 대화를 할 수 있는 것처럼,
DBMS가 있기에 사용자는 눈에 보이지 않는 데이터를 시각화해서 요리할 수 있는 것이다.
이때 DBMS와 교감하기 위해 필요한 것이 SQL 언어이다.
우리는 SQL로 DBMS에 데이터베이스를 새로 구축하고 수정하고 삭제하고 등등 다양한 명령을 내릴 수 있는 것이다.
데이터베이스의 구현에는 "관계 데이터 연산" 개념이 필요하다.
2020/06/18 - [컴퓨터언어/Database] - [관계 데이터 연산] 관계형 데이터베이스의 이론적 기반 - 관계대수, 관계해석
스키마란 데이터의 구조를 뜻한다.
일반적으로 "<학생> 개체의 스키마가 뭐야?"라고 묻는다면, "학번, 성명, 학년, 학과로 이루어져 있고, 학번이 기본키야" 라고 하면 된다.
개념 스키마는 추상적인 것으로, "앞으로 구축할 데이터베이스의 전체적인 구성이 이러이러할 것이다"라고 일종의 "조감도"를 그리는 과정이다. DBMS에 독립적이며 ER 다이어그램으로 표현한다.
내부 스키마는 데이터의 저장을 어떻게 할 것인지, 그 자료형 등 제약조건을 설정하는 과정으로, 사용자에게 보이지는 않지만 매우 중요한 내부로직을 담당한다. 배선 등 "설계도"와 비슷하다.
설계가 끝나면 외부 스키마로서 사용자가 원하는 데이터를 가공해서 보여준다. "모델하우스"와 비슷하다.
'컴퓨터언어 > Database' 카테고리의 다른 글
| [Relationship] "관계"가 들어간 다양한 용어 정리 (0) | 2020.06.15 |
|---|---|
| [Attributes] "속성"이 들어간 다양한 용어 정리 (0) | 2020.06.15 |
| [Entity] 용어정리 (0) | 2020.06.15 |
| [Mongoose] 특정 필드만 Read하기 (0) | 2020.05.18 |
| [bcrypt] Hashing의 보안을 더 높인 Salting Round (0) | 2020.05.17 |