DB

[sqld 이론정리] 데이터 모델링의 이해

미미_밍 2024. 10. 12. 02:56

 

데이터베이스 모델링이란 무엇일까 ? 
현실세계를 "단순화" 하여 표현하는 기법이다. 

즉 현실세계를 그림과 같은 모델로 만듦으로서 데이터의 저장 과정을 한눈에 보기 쉽게 그려놓은 것이다. 

 

 

 

그렇다면 모델링이 갖추어야 할 조건은? 

1) 현실세계를 반영하여야 한다. 

2) 단순화하여 표현하여야 한다. 

3) 관리하고자 하는 데이터를 모델로 설계하여야 한다. 

 

여기서 관리하고자 하는 데이터는 "우리가 모델링 해야  할" 데이터 이다.

필요없는 데이터까지 모델링 해 데이터베이스의 자원을 낭비할 필요는 없다. 

 

 

모델링의 특징

1)추상화 -> 아이디어나 개념을 간략하게 표현한다. 모델링 단계에서 섬세한 표현 ex)pk 등을 미리 지정해 줄 필요는 없다.

2)단순화 -> 현실세계를 정해진 표기법으로 단순하게 표현하여야 한다. 

3)명료화 -> 불분명하게 표현해서는 안된다. 개념을 추상화 해야 한다고 해서 명료하지 않게 표현하라는 말은 아니다. 간략하게 표현하되 명확하게 표현하여야 한다. 

 

자 그럼 데이터베이스 모델링이란?

현실세계를 단순화하여 표현하는 기법이며 추상화, 단순화, 명료화 라는 특징을 가진다. 

어떻게 이런 특징을 가지며 모델링 시킬 수 있을까 ? 

 

모델링을 어떤 관점으로 할 것인가 

우리는 세가지 관점으로 모델링을 진행할 수 있다. 

1) 데이터관점 -> 업무에 얽힌 데이터를 기준으로 모델링 한다.  

2) 프로세스 관점 -> 업무가 실제로 처리하고 있는 일을 기준으로 모델링 한다. 

3) 데이터와 프로세스의 상관 관점 -> 프로세스의 흐름에 따라 데이터가 어떤 영향을 받는지 보면서 모델링한다. 

 

*데이터의 품을을 보장하기 위해 데이터 모델링시 중복, 비유연성, 비일관성 등에 유의해야 한다. 

  -중복 : 같은 데이터가 여러 엔티티에 중복으로 저장되면 안된다. 

  -비유연성 : 데이터 모델과 프로세스를 분리하여 유연성을 높여야 한다. 즉 프로세스의 변경에도 데이터는 유연하게 처리되어야 한다. 

  -비일관성 : 개발자가 다른 데이터와의 연관관계를 고려하지 않고 일부 데이터만 변경할 때 비일관성 문제가 생길 수 있다. 모델링시 데이      터간의 연관관계에 대해 명확하게 정의해야 한다. 

 

 

모델링의 세가지 단계 

이때까지 모델링이 갖추어야 할 조건, 특징 모델링의 관점에 대해 알아보았다.

이제 모델링을 시작해보자.

모델링은 세가지 단계를 거쳐 이루어진다. 

1) 개념적 데이터 모델링 - 전 회자 차원적 데이터 모델링 수행 시 이루어지며 추상화 레벨이 가장 높은 모델링이다.(엔티티 , 관계 구성)

2) 논리적 데이터 모델링 - 재사용성이 가장 높은 모델링이다. key , 속성, 관계 등을 모두 포함한다. (정규화 , pk, fk) 

3) 물리적 데이터 모델링 - 실제 데이터베이스로 구현할 수 있도록 성능 등의 물리적 성격 고려하여 모델을 표현하는 단계이다. (인덱스등)

 

 

의문점

이 다음장이 데이터의 독립성을 설명하는 장이다. 흐름대로 데이터 모델링에 관한 설명을 하다 갑자기 흐름이 뚝 끊기는 느낌이었다. 

데이터의 독립성을 데이터베이스의 스키마 구조를 설명하는 파트인데 우리는 모델링에 관해 배우고 있으니 저 위의 1,2,3 번 모델링 중 하나에 속하지 않을까? 라는 생각으로 찾아보았더니 스키마 구조를 구성하는 각 단계에서 개념적, 논리적, 물리적 모델링이 이루어 진다고 한다. 

 

 

데이터의 독립성에 대해 살펴보자 

ANSI-SPARC 아키텍쳐란 dbms 의 추상적인 설계 표준이다. 이 아키텍쳐에서는 스키마를 3단계 구조로 나누는데 데이터베이스에 대한 사용자들의 관점과, db 가 표현되는 물리적 방식을 분리해 독립성을 유지하기 위함이다. 이 단계에서 분석/설계가 다 이루어 진다고 생각하면 된다. 

 

3단계 스키마 구조 

1) 외부스키마 - 사용자 관점, 각 사용자가 보는 데이터베이스의 스키마 정의

2) 개념스키마 - 통합된 관점, 모든 사용자가 보는 데이터베이스 스키마 통합 => 전체 데이터베이스 나타냄, 데이터들의 관계 그려줌

이 단계에서 개념적, 논리적 모델링이 진행된다. 

3) 내부스키마 - 물리적 관점, 물리적 저장 구조를 나타낸다. 컬럼 정의, 인덱스 등이 포함된다. 이단계에서 물리적 모델링이 진행된다. 

 

* 3단계 스키마 구조가 보장하는 독립성 

-논리적 독립성 : 개념스키마가 변경되어도 외부스키마는 영향 받지 않는다. 

ALTER TABLE Student ADD Email VARCHAR(255);

CREATE VIEW StudentView AS
SELECT 학생ID, 이름, 전공 FROM Student;

 

-물리적 독립성 : 내부스키마가 변경되어도 외부/개념 스키마는 영향받지 않는다. 

CREATE INDEX idx_name ON Student(Name);

 

이렇게 인덱스 변경이나 개념스키마의 변경(테이블 변경) 시에도 독립적인 것을 볼 수 있다. 

 

자 이제 데이터베이스를 설계해보자 외부스키마가 그려졌다고 가정하고 개념스키마 단계에서 개념적 데이터 모델링을 위한 erd 를 먼저 그려야 한다. 여러 표기법 중에서 우리는 IE/Corw's Foot 표기법을 사용 할 것이다. 

 

 

erd 작성순서

1) 엔티티 도출, 그리기

2) 엔티티 적절한 위치에 배치

3) 엔티티간 관계 설정

4) 관계명 기입

5) 관계의 참여도 기입

6) 관계의 필수/ 선택여부 기입 

의 순서로 진행된다. 

 

엔티티란 무엇일까 ? 

엔티티란 사전적 의미로 '독립체' 라고 한다. 데이터베이스에서는 식별 가능한 개체 라고 생각하면 된다. 물론 모델링의 특징인 명확함을 담고 있어야 한다. 모호한 엔티티는 성립 불가하다.  ex) 탈퇴가 예상되는 회원, 예상? 너무 모호하다. 추측에 불과한 단어가 있는 엔티티는 성립 불가하다. 

 

erd 의 예시이다. 여기서 네모 박스를 엔티티라 하며 이어진 선에 따라 관계를 표기해 준다. 명확한 IE/Corw's Foot  기법을 사용한 것은 아니지만 설명을 위해 단순한 erd를 가져왔다. 

각 엔티티는 자신을 상세히 나타내기 위해 속성을 가진다. 여기서 엔티티를 table 속성을 column 엔티티의 가로행을 row 라 칭한다. 

위의 예제는 해당 erd를 구체화 하여 나타낸 것이다. 회원 엔티티에서는 회원아이디, 비밀번호 , 이름 등을 속성으로 가지는 것을 볼 수 있다. 해당 예제에서는 세로로 그려놓았지만 실제로는 가로로 들어가서 밑에 row 가 쌓이게 된다. 

 

좀더 세분화 해서 엔티티와 속성에 대해 자세히 들여다 보자. 

 

엔티티 특징

 

1) 업무에서 쓰이는 정보여야 한다. 

2) 유니크함을 보장할 수 있는 식별자가 있어야 한다. 식별이 모호하면 엔티티 설계가 잘못된 것이라고 볼 수 있다. 

3) 2개 이상의 인스턴스를 갖고 있어야 함 (인스턴스는 row 를 말한다 , 즉 행이 2개 이상이어야 함) 

4) 반드시 속성을 가지고 있어야 함

5) 다른 엔티티와 1개 이상의 관계를 가지고 있어야 함 

 

이렇게 만들어진 엔티티는 어떻게 분류할 수 있을까 ?

 

엔티티의 분류

 

1) 유형 vs 무형 

- 유형 : 물리적 형태 존재 ex) 상품, 회원

- 개념 : 물리적 형태 없음 ex) 부서, 학과 

- 사건 : 행위를 함으로서 발생 ex) 주문

 

2) 발생시점

-기본 : 업무에 원래 존재하는 정보 ex) 상품, 회원

-중심 : 기본 엔티티에서 파생된것 , 업무에 있어서 중심적 역할을 함 ex) 주문, 계약

-행위 : 2개 이상의 엔티티로부터 파생 , 데이터가 자주 변경/증가 할 수 있음 ex) 주문내역

 

* 엔티티 이름은 약어 사용 x , 단수로 표현, 띄어쓰기x , 다른엔티티와 중복 불가 등의 규칙을 가진다. 

 

 

속성이란 ? 

사물이나 개념의 특징을 설명해줄 수 있는 항목을 말한다. 속성은 더이상 쪼개지지 않는 레벨이어야 한다. 하나의 속성은 한 개의 속성값만 가질 수 있다. 하나의 속성이 여러개의 속성값을 갖는경우 별도의 엔티티로 분리해야 한다. 

 

속성을 특성에 따라 분류해보자 어떤 속성들이 있을까 ? 

 

특성에 따른 분류 

1) 기본속성 : 업무 프로세스 분석을 통해 바로정의가 가능한 속성 , 엔티티의 가장 많은 퍼센티지를 차지한다. 

 

2) 설계속성 : 업무에 존재하지 않지만 설계 과정에서 합리적인 모델링을 위해 만들어진 속성이다. pk 가 없다면 고유번호를 할당하는 것을 예시로 들 수 있겠다. 

 

3) 파생속성 : 다른 속성으로부터 파생된 속성을 말한다. 상품 주문 프로세스를 생각해보면 상품을 주문하여 결제하는 순간 주문내역 엔티티가 만들어진다. 이때 재고를 구하려면 주문내역에서 해당 상품의 개수를 계산한 다음 상품개수에서 빼야 하는데 이런 수고를 덜기 위해 주문상품 엔티티에 상품의 구매수량을 미리 구해 놓으면 계산이 빨라진다 이런 경우를 파생속성이라 부른다. 

 

구성 방식에 따른 분류 

pk 속성 - 엔티티에 속한 각 인스턴스에 유니크함을 부여하는 속성이다. 

fk 속성 - 다른 엔티티와 관계를 맺게 해주는 매개체 역할을 한다. 

일반속성 - 그 외 속성이다. 

 

 

 

1장 회고 

쳅터 1장의 데이터 모델링의 이해는 상당히 짧은 부분인데 글로 쓰자니 생각보다 길어져서 놀랐다. sqld 를 준비하면서 공부한 내용을 이해하기 쉽게 적어보려 했는데 설명이 논리정연하게 이루어 졌는지 모르겠다. 저자의 살명은 너무 뒤죽박죽 이었다.   여러 개발책을 보면서 느낀 문제점은 흐름대로 글을 쓰지 않는다는 것이었다. 특히 모델링과 스키마 쪽이 매끄럽게 연결되지 않는 부분을 볼 수 있다. 암기만 하며 공부하지 말고 전체적 틀을 보면서, 지금 어느위치에 있는지 생각하며 공부하자. 

 

 

참고자료 

https://iinomad.com/88

 

다이어그램 ERD 그리기, 외래키 연결

다이어그램 ERD 그리기, 외래키 연결

iinomad.com

sql 개발자 과외노트