모델이란?
어떤 목적을 가지고 진짜를 모방한 것, 좋은 모델이란 목적에 부합하는 모방.
우리의 목적은 컴퓨터(관계형 데이터베이스, 표)에 정보를 담는 것이다.
정보를 데이터베이스(표)에 담는 것에 성공만 하면 거대한 데이터 양을 엄청난 속도로 다룰 수 있기 때문이다.
하지만 무한히 거대하고 복잡한 현실을 정보로 만들어서 표에 담는 것은 매우 어렵다.
전문가들은 평범한 사람들도 현실의 복잡성을 컴퓨터에 담을 수 있는 방법론을 만들었는데, 이것을 데이터모델링 이라고 한다.
데이터 모델링이란, 문제를 현실로부터 뜯어내서
고도의 추상화 과정을 거쳐 컴퓨터라는 새로운 현실로 옮겨 담는 작업이다.
출처 : https://www.youtube.com/watch?v=1d38YZKCM88&feature=emb_title
<데이터 모델링의 일반적인 순서>
- 업무 파악
- 개념적 데이터 모델링 : 현실의 업무를 뜯어내서 개념을 찾아내기(ER 다이어그램)
- 논리적 데이터 모델링 : 개념을 표로 전환하는 과정
- 물리적 데이터 모델링 : 어떤 데이터베이스 제품을 선택할 것인가, 그리고 실제로 표를 만드는 과정(SQL 코드 산출)
업무 파악
컴퓨터 공학이 해결하는 문제에는 두가지가 있다.
한 가지는 컴퓨터 자체의 문제로, 데이터베이스를 만드는 작업을 예 로 들수 있다.
또 한가지는 현실의 문제를 해결하는 것으로, 데이터베이스를 통해 현실의 문제를 해결하는 작업을 예로 들 수 있다.
현실의 문제를 해결하려면 컴퓨터를 이해하는 것 뿐만 아니라 해결하려는 문제를 컴퓨터에게 설명할 수 있어야 하며,
그 분야의 실무자들과 정확히 소통할 줄 알아야 한다.
업무 파악을 할 때 많이 사용하는 방법은, UI를 같이 그려보는 것이다.
(유저 인터페이스 : 사용자가 기계를 작동할때 사용하는 여러 조작장치)
우리가 꿈꾸는 결과물이 어떤 UI를 갖고 있는지 이를 의뢰한 사람과 함께 그려보는 과정을 통해
의뢰자가 원하는 것이 무엇인지 분명히 알 수 있다.
개념적 데이터 모델링
우리가 파악한 업무에서 개념을 뽑아내는 과정이다. ERD를 사용한다.
ERD(entity relationship diagram)
현실에서 개념을 추출하는 일종의 필터
개념에 대해서, 다른사람과 대화하게 해주는 언어로 작용한다.
현실은 아주 복잡하며, 이 현실에서 개념을 뽑아내는 건 무척 어려운 일이다.
이런 현실을 간단하게 바라볼 수 있게 해주는 파인더가 ERD이다.
ERD는 현실을 세 가지의 관점으로 바라볼 수 있게 해준다.
- 정보
- 그룹
- 관계
또한 ERD는 매우 쉽게 표로 전환할 수 있는 규칙들을 가지고 있다.
관계형 데이터베이스에 잘 어울리는 모델은 두번째 모델이다(동등한 표의 관계)
첫번째 모델은 표 안에 다른 표가 내포되어있는 개념으로, RDB는 내포관계를 허용하지 않기 때문에 덜 적합하다.
만약 테이블을 쪼개지 않고 거대 단일 테이블로 표현하면 중복이 발생하게 된다.
표를 쪼개게되면 주제에 따라 데이터를 그룹핑 할 수 있고, 글에 대한 정보만 필요하다면 글을 담고 있는 표 만을 조회하여 컴퓨터의 자원을 아낄수 있으며, 조인도 가능하다.
찾아낸 개념들은 ERD에서 엔티티(Entity)라고 부르며, 엔티티는 후에 테이블로 전환되게 된다.
글 이라는 엔티티는 실제 데이터가 아니다. 구체적인 데이터는 제목, 생성일, 본문 같은 것들이다. 이를
그룹핑 한것이 '글'이라는 엔티티인 것이다.
구체적인 데이터는 속성(Attribute)이며, 이후 표의 컬럼이 된다.
각 엔티티들은 서로 관계를 가질 수 있다.
- 저자, 글, 댓글은 서로 관계를 가진다.
- 글과 저자는 서로 쓴다는 관계를 가진다.
- 글과 댓글은 서로 소속 관계를 가진다.
댓글은 저자와 글을 쓴다는 관계를 가진다.
이러한 연관성을 표현해준 것을 Relation(관계)라고 하며,
기본키나 외래키로 해당 정보가 표현되고 조인을 통해 테이블들을 연결하게 된다.
UI와 데이터베이스 사이의 일을 원인과 결과의 관점으로 보면
정보를 입력하는 UI가 원인이 되어서 데이터베이스의 데이터를 변경하는 결과를 낳는다.
또 데이터라는 원인에 의해 UI의 내용이 표시되는 결과를 낳는다.
즉, 사용자가 마주하는 UI와 컴퓨터에 저장되는 데이터는 서로 원인과 결과의 관계에 있다.
기획자와 구현자가 다르다면 데이터모델링까지 함께 하는 것이 좋다.
-'생활코딩' 유튜브 中
<개념적 모델링의 순서>
- 기획서를 보면 제일 먼저 하는 일은 기획서에서 Entity를 찾아내는 것이다. 연관된 데이터를 그룹핑하는 엔티티를 만들며 이것은 네모로 표현한다.
- 엔티티의 Attribute(속성)을 정의한다
- 엔티티의 속성 중 대표 속성을 뽑아 식별자(identifier)를 지정한다. 식별자의 속성에는 밑줄을 그어준다.
식별자(identifier)
해당 테이블에서 식별자로 사용할 수 있는 컬럼은 'user_id, email, national_id'이다. *고유한 값을 가지는 컬럼
식별자로 사용할 수 있는 컬럼을 후보키(candidate key)라고 부른다.
이 후보키 중에서 우리가 선택한 식별자를 기본키(primary key)라고 부르며
기본키가 되지 못한(선택받지 못한) 다른 후보키들은 대체키(alternate key)라고 부르게 된다.
기본키로 삼을 식별자가 마땅히 없을 경우에는 다른 것과 중복되지 않는 일련번호 같은 것으로 인조(대리)키를 만들기도 한다.
엔티티와 엔티티의 관계(Relationship) : PK, FK
표 들은 데이터로 서로 연결되어 있다.
이 때 각각의 표에 행을 식별자는 식별자를 기본키(primary key)라고 부르고, 다른 테이블과 연결해줄 대 사용하는 컬럼을(예 : 저자의 아이디) 외래키(foreign key)라고 부른다.
관게형 데이터베이스의 Relationship은 primary key와 foreignkey가 연결되는것을 통해 실제로 구현된다.
*ERD에서는 엔티티를 네모, 속성을 동그라미, Relationship을 마름모꼴 도형으로 표현한다.
Cardinality, Optionality
엔티티 간의 Relationship에서 꼭 따져봐야 하는 요소에는 Cardinality와 Optionality가 있다.
Cardinality(기수, ex. 123456789)
테이블과 테이블 사이에는 세가지의 관계가 있다.
담임 테이블에는과 반 테이블에는 각각 행이 세개가 있다.
각 선생님은 한 반만 담임을 한다 -> 담임은 반을 한개만 가질수 있다, 담임에게 반은 한개다.
각 반의 담임은 한명이다 -> 반에게 담임은 한개다.
이러한 관계를 1:1 관계라고 한다.
저자 테이블과 댓글 테이블은 각각 세개의 행을 가진다.
저자는 여러 개의 댓글을 작성할 수 있다. 저자에게 댓글은 여러개이다.
각 댓글에는 하나의 저자만 존재한다. 댓글에게 저자는 한개다.
이러한 관계를 1:N(1:다) 관계라고 한다.
저자와 글의 테이블이 있다. 하나의 글을 여러 명이 편집할 수 있다면
저자는 여러 개의 글을 작성할 수 있다. 저자에게 글은 여러개이다.
각 글은 여러 저자가 존재한다. 글에게 저자는 여러개이다.
이러한 관계를 N:M(다:다) 관계라고 한다.
Optionality(옵션 : 있을수도 있고, 없을수도 있다)
저자와 댓글 테이블이 있다.
어떤 저자가 어떤 게시글을 등록 했다면 반드시 댓글을 가지고 있지는 않다.
저자는 댓글을 작성하지 않을 수도 있다. 즉, 저자에게 댓글은 옵션이다.
이것을 다이어그램에서는 동그라미로 표시를 한다(방향 주의)
댓글이 존재한다면 각 댓글은 반드시 저자를 가지고 있다.
댓글에게 저자는 필수(Mandatory)이다.
이것을 다이어그램에서는 작대기로 표시를 한다.
저자와 댓글은 Cardinality도 가지고 있다. 저자와 댓글이 1:N의 관계에 있다면 동시에 이렇게 표현할 수 있다.
해당 게시글은 '생활코딩' 님의 관계형 데이터 모델링 강의를 참고하였습니다.
출처 https://www.youtube.com/watch?v=1d38YZKCM88&list=PLuHgQVnccGMDF6rHsY9qMuJMd295Yk4sa
'DATABASE' 카테고리의 다른 글
| 관계형 데이터 모델링(3) - 물리적 데이터 모델링 (0) | 2021.12.11 |
|---|---|
| 관계형 데이터 모델링(2) - 논리적 데이터 모델링 (0) | 2021.12.11 |
| SQL JOIN - LEFT OUTER JOIN, INNER JOIN (0) | 2021.12.10 |
| ORACLE DATABASE - PRIMARY KEY, SEQUENCE (0) | 2021.12.09 |
| ORACLE DATABASE - 데이터의 CRUD (0) | 2021.12.09 |
