1.모델이란 무엇일까?
어떤 목적을 가지고 진짜를 모방한것. > 그렇기 때문에 좋은 모델이란 목적에 부합하는 모방
우리의 목적은 컴퓨터, 관계형 데이터베이스 -> 표의 정보를 담는것
일단 정보를 db표에 담는것에 성공하면 인간의 기본적인 능력으로 상상할수없는 거대한양의 데이터를 엄청난 속도로 다룰수있게 된다.
우리는 이삿짐 센터다아아아!!!
아무리 복잡한것도 표에 담을 수 있다는 자신감을 가지게 될것이다.
2.데이터 모델링이 어떤 순서로 진행되는지 배워보자
업무파악>개념적데이터 모델링> 논리적 데이터 모델링 > 물리적 데이터 모델링
업무파악) 우리가 할려고하는 그 일이 무엇이냐. 우리에게 의뢰한 사람과 잘 협력해서 알아내야됨, 의뢰한 사람이 어떤걸 꿈꾸고 있냐를 파악하는 것. 그과정속에서 기획서를 산출물로 제출해야 함. 개념적 데이터 모델링) 내가 하고자하는 일에는 어떠한 개념들이 , 각각의 개념들이 어떻게 상호작용하는가를 심사숙고 하는 과정, 이과정에서 erd를 그리게 됨. 그다음과정의 초석. 논리적 데이터 모델링) 관계형 데이터 패러다임에 맞는 표로써 우리가 만들었던 개념을 표로 전환하는 작업. 이렇게 표를 이상적으로 잘 그린다고해서 db 상에서 잘되는게 아님. 그다음 단계에서 내가 어떤 db 제품을 사용할건지를 선택하고 이 db제품에 최적화된 표를 만들어야됨 물리적 데이터 모델링) 실제표를 만드는것이 이 단계, 이 산출물은 표를 생성할 수있는 sql 코드를 가지게 되는 것.
데이터 모델링이란 문제를 현실로부터 뜯어내서 고도의 추상화과정을 거쳐서 컴퓨터라는 새로운 현실로 옮겨 담는 작업이다. 이 두개의 세계는 서로 다르기 때문에 처음에 해결하려고 했던 문제가 db 표에 잘 담겨있는지 확인하는 작업을 끊임없이 계속해서 해내가야되겠구나라는 생각이 드셨다고 하심.
데이터 모델링이라는 현실의 문제를 우리의 머릿속으로 이사시키는 작업을 시작해보자아아아아ㅏ아!!!! 이게 끝나면 현실로 돌아가 자신만의 모델링 작업을 수행해보자아아!! 나의 현실에 어울리는 모델링 기법을 수행하게 될. 것. 임.
3.업무파악 인트로
업무파악을 할때 많이 사용하는 방법> UI를 같이 그려보기!
우리가 꿈꾸는 앱의 UI를같이 그려보는 과정에서 원하는 것을 분명히 할 수 있기 때문이다. 말의 힘을 불신하십시오. 말의 진의를 불신하라는것이 아닌 말의 기능을 불신하라. 말을 불신할 수록 말의 신뢰성은 높아진다.
말의 불신에서 말의 신뢰성을 높이는 테크닉인 기획서를 만들어보며 수업에서 사용할 예제를같이 만들어보며 동기화 시켜볼것임
4.기획서를 만들어 볼거다.
툴에 대한 자세한 설명은 안할거야.(oven app - 카카오에서 만든/ 사람들에게 지식을 전하는 일종의 메뉴얼 사이트)
현업에서 이런 작업들을 하기 전에 최대한 그 의사 결정자들 또 이해 당사자들이 모여서 자주, 명확하게 대화를 주고 받으며 커뮤니케이션을 하면 덜 불행한 미래가 기다리고 있을 것임
5.개념적 데이터 모델링
개념적 모델링 이란? 우리가 파악한 업무에서 개념을 뽑아내는 과정
우리가 일을하는 순서와 공부를 하는 순서는 다를 수 있다. 개념적 모델링은 논리적 모델링/물리적 모델링 보다 앞선 단계이지만 논리적/물리적을 경험해 보지 않는 사람이 개념적 모델링을 할수는 없다. > 개념적 모델링은 관계형 데이터 모델링 전체 프로세스의 극치. 개념적 모델링을 잘했다면 논리/물리적 모델링은 비교적 기계적인 일이라서. 모델링 이라는 건 업무라는 현실과 db 라는 또다른 현실이 있을때 그것을 이사시키는 작업이라. 이 두가지의 정통하지 않는 사람이 개념을 뽑아 낸다는 것은 가능한 일이 아니라고 생각함.
느긋한 마음으로 언젠가는 되겠지라는 마음가짐으로 수업에 참가해라
개념적 모델링이 주는 효용: 1.현실에서 개념을 추출하는 일종의 필터를 우리에게 제공 2. 개념에 대해서 다른 사람들과 대화하게 해주는 일종의 언어로써 작용 —>이러한 목적을 이루게 해주는 하나의도구가 erd 라는 entity relationship diagram이라고 하는 그림!
지옥같은 현실에서 개념을 뽑아내는 것은 무척 어려운일.. 현실을 간단하게 바라볼수있는 파인더와 같은 것이 우리에게 있다면 얼마나 좋을까. erd는 현실을 3개의 관점으로 바라볼수있는 파인더를 우리에게 제공해준다. 1.정보 :정보를 발견하고 그것을 다른사람에게 표현할 수 있게 도와준다. 2.그룹 : 서로 연관된 정보를 그룹핑해서 인식하고 이것을 다른 사람들에게 표현할 수 있게 해줌 3. 관계 :정보와 그룹사이의 관계를 인식하고 그것을 다른사람에게 표현할 수 있게 해준다.현실로부터 개념을 인식하는 도구이면서 그것을 다른사람도 알아볼수있게 표현하는 도구가 erd이다.
6. ERD 만드는방법
기획서에는 여러가지 정보들이 흩어져있는데 글/제목/저자 등등 여기서 서로 연관된 정보를 묶어주는 큰 정보들을 끄집어 내야됨.
이걸 그림으로 표현하면 어떤 모습이 되어야될까? > 정답따윈 없다. 설명이 가능하고 모순이 없으면 된다. 좌/우측 모두 괜찮지만 관계형 데이터베이스의 잘 어울리는 모델이 더 유리하다. 그런점에서 우측 모델을 선택해야됨.
멀리서 큰틀의 흐름만 생각해보자/ 왜 하필 아래쪽에 있는 모델이 관계형 데이터 베이스 다운가를 생각해보자.
erd는 내표형 관계를 허용하지 않는다. > 일을 잘하는 사람 그러면서도 관계형 db에 대한 깊은 이해가 없으면 방법을 찾아낸다. . . . . 초 거대 표 하나를 만들어버리게 됨. (좌측 두번째 표) 이 표는 만약에 우리의 프로젝트가 어마어마하게 크다하면 이 표의 컬럼이 1000개가 될 수 도 있는데 이 표에서 글의 목록만 필요하다고 하면 그러면 얘만 가져오고 싶은데 우리는 1000개 컬럼을 가져와야되기 때문에 흥청망청 데이터를 쓰게 됨. 뿐만 아니라 댓글과 글내용에 대한 저자가 같기 때문에 중복이 발생함. 1억개가 중복되어버리면. 우리의 소중한 저장장치를 흥청망청 쓰게 됨. 또한 저자의 이름을 바꿨다하면 1억개의 이름을 바꾸는데 시간역시 오래걸림… 즉) 거대 단일 테이블로 표현하면 중복이 발생한다.
좌측 3번째 표 ) 우리가 표를 쪼개개되면 좋은 점은 주제에 따라 그 속성들 주제에 따라서 데이터를 그룹핑할 수 있다. 두번째로는 우리가 만약에 글에 대한 정보만 필요하다그러면 글만 뽑아내면 돼서 컴퓨터 자원을 아낄수있다. 그리고 마지막은 바로 조인, 글과 저자 따로따로 들어가는게 아닌 저자 누가 작성했는가 그 저자 이름 저자에 대한 소개이런것까지 포함됐으면 좋겠다라고 하면 이런식의 정보가 필요함( 좌측 4번째 표) 관계형데이터 베이스에서는 조인이라고 하는 메커니즘을 통해 언제든지 필요할때마다 순간순간 합성해 낼수있어 우측 상단의 첫번째표인 포함관계가 아닌 우측 하단의 좀더 평면적인 관계의 개념을 뽑아내는 것이 우리가 하려고 하는 관계형 데이터 베이스의 더 어울리는 방식이다.
7. 관계형 데이터 모델렝 - erd 구성요소
- 댓글 글 저자를 동등한 표로 표현할 수 있다.
- 이렇게 찾아낸 개념을 개념적 모델링 또는 erd에서는 entity라고 칭함
- Entity > table 로 전환할것임
- 글이라는 entity는 실제 데이터가 아님. 구체적인 데이터는 제목, 생성일, 본문 이러한 것들에 담겨있다. 이러한 것들을 그룹핑한것이 글이라는 entity다. 구체적인 데이터를 영어로는 attribute라고 함. 이것은 후에 표의 컬럼이 된다.
- 왜 여기에 있는 저자의 이름 , 댓글 이러한 것들은 글의 속성이 되지않는가? 만약 저자의 이름만 우리 시스템에 필요하다면 저자의 이름은 속성이 되면 된다. 하지만 저자이름 뿐만 ㄴ아니라 저자에 대한 자기소개, 가입일같은 정보가 필요하다면 저자는 이름, 소개, 가입일과 같은 속성을 포함하는 entity가 되는 것임.
- 엔티티를 디렉토리 속성을 파일이라고 하면 엔티티란 파일만 담을수있고 자식 디렉토리를 담을 수 없는 제한적인 디렉토리다. 다른 디렉토리를 품을 수 없는 평면적인 디렉토리라고 생각해보면 좋을 것 같다(어영부영 설명하셨다고 하심…..)
- 관계에 대한 얘기를 해보자 엔티티들간의 관계) 저자와 글과 댓글은 서로 복잡한 관계를 가지고있다. 글과 댓글은 서로 소속관계를 가지고 있고 댓글은 저자와 글을 쓴다라는 관계를 가지고 있다. 이렇게 연관성을 표현해준걸 관계(relation)이라고함. 우리가 나중에 논리적 데이터 모델링으로 가게 되면 표에서는 기본키 또 외래키라는 형태로 이 관계가 표현되게 된다. 이렇게 표현된, 저장된 데이터를 기반으로 우리가 조인을 통해서 동쪽 테이블들을 연결하게 될것임
- 개념적데이터 모델링은 개념에 집중한 db 패러다임으로부터 거리를 주고 있기 때문에 용어가 실제데이터 베이스 제품들과는 다르다. 각각의 용어가 나중에 무엇이 될지 정리하고 이번영상을마무리할것임.
'STUDY > SQL' 카테고리의 다른 글
MySQL 데이터베이스 한번에 끝내기 (0) | 2021.05.09 |
---|---|
[생활코딩] 관계형 데이터 모델링 (26-32강의 : 물리적데이터 모델링/역정규화) (0) | 2021.05.09 |
[생활코딩] 관계형 데이터 모델링 (22-25강의 : 정규화) (0) | 2021.05.09 |
[생활코딩] 관계형 데이터 모델링 (15-21강의 : 논리적 데이터 모델링) (0) | 2021.05.09 |
[생활코딩] 관계형 데이터 모델링 (8-14강의 : 개념적 모델링) (0) | 2021.05.09 |