60일차. DB 13 - 모델링 (논리설계 실습)

개념 설계 

논리 설계 - 테이블 모양으로 만드는 것

 

entity는 무조건 테이블이 된다.

관계/행위는 테이블이 될 수도 있고 안 될 수도 있음

 

ㅡㅡㅡㅡㅡ

 

Q. 설계란? 

-> Design 

ex) 강아지 집을 만들어야겠다 하면, 

     어떤 모양으로 할지 / 색깔은 뭐로 할지 등등을 끄적거려볼 것

 

어제 ppt에 그린건 1단계 -  내가 테이블에 뭘 '저장'할지 설계해본 것

오늘 2단계 - 테이블 형태로 만들어보는 것

 

맨 위의 칸은 '식별자' 

아래는 '속성'

 

ㅡㅡㅡㅡㅡ

Q. 식별키 

-> 주민번호

 

주키

후보키

대체키

 

후보키 - 후보가 될 수 있는 것들

근데 이중에서 전화번호, 이메일은 없을 수도 있으니 -> 주민번호를 정해버리면 애가 주키 (프라이머리 키)

후보키에서 주키를 빼면 대체될 수 있다하여 대체키라고 함

 

ㅡㅡㅡㅡㅡ

 

Q. 나는 주키가 주민번호가 맞는 것 같다. 

-> yes! (내 의견) 

 

Q. 나는 주키로 주민번호를 사용할 수 없을 것 같다. 

-> 쓸 수는 있되 수집하는 용도로는 별로라서 (형준님 의견) 

개인정보라서 그렇다고 한당.

 

프라이머리키가 공개가 되는거라고 생각했을 때, 주민번호는 X

 

//

 

대리키 - 식별자로 데리고 오는 녀석 (아이디 - 근데 이름이 다양함. 일련번호라고도 하고, 문자일련번호, 코드라고 말하기도 하고...) 

대리키의 이름을 통일!시켜야 한다.

아이디라고 부르면 계속 아이디라고 불러야 함! 

-> (보통) 아이디라고 부르기로 하자

 

//

 

슈퍼키

- 두 개 묶어서 키로 만들려고 할 때

- 다대다 관계 풀어낼 때 사용 

---

배운걸 가지고 이제 이걸 다시 고쳐보자

조건 : 책 제목은 중복될 수 없다고 할 때

 

Q. 리뷰에서 식별자를 '책 제목'으로 해야할까? 

-> 책 제목은 길이가 길 수 있다. 괜히 메모리 차지할 이유 없다. 

-> 외부 키 들여와서 아이디를 식별자로 하자  

 

DB에서 중복되는건 피해야한다. 

-> 리뷰를 entity라고 한 거 고치기

 

Q. 어떻게 해야할까... 리뷰를 좋아요... 

-> 표현할 수 없다고 한다. 

-> 선생님은 그냥 무시하고 표현하신다고 ㅎㅎ 

설계는 내거를 만들기 위한거니까! 

 

1. 관리자가 등록 

2. 리뷰 

3. 좋아요

 

관계도 순서가 존재하기에 ERD에 숫자도 써주신다고. (선생님은! 공식적인건 아니지만)

// 

 

관계를 이어보자

1. 회원의 행위를 보자

 

옵션 1) 

옵션 2) 자식(책)의 아이디 이름 바꿀건지 -> X

옵션 3) 부모 이름 바꿔서 넣을거니 -> O 

-> 등록자 아이디 (관리자 아이디는 별로. 행위!(등록하다)를 넣어주는게 좋다.) 

- 띄워쓰기 x

 

model property 

2번째것들 선택

-> 모양이 눈에 익게 스타일이 변함

 

 

N:N 은 무조건 새로운 테이블이 되는 애들

 

Entity name 뭐로 할거냐는 창이 나오는데, 

'찜'으로 바꿔주기 (우리 지금 찜에 대한 n:n 하고 있으니까)

이름 수정해야함 

왼쪽 선 더블 클릭해서 이름 수정

 

//

 

이번엔 오른쪽 선 더블 클릭해서 

'회원 아이디'로 수정

두 개의 FK

-> 두 개를 합쳤을 때 실제로 '찜'을 할 수 있는지 생각해봐야함 

 

1번 회원이 1책을 찜했는데, 또! 찜했을 수는 없음

-> 2개를! 넣어 사용하게 되면 이 일을 방지할 수 있지 

-> 대리키는 선택 사항

 

대리키 안 쓰고 2개만 하면 (최상에 있는 부모의 키는 커지지 않음) (대리키는 숫자가 커짐)

-> 식별자 수가 급팽창하는걸 막을 수 있음 

    ex) 각각 1억개 책 x 80만명 회원이면 -> 따로 아이디를 둔다고 하면 1억보다 큰 수가 되는 것

-> 그냥 두 개를 합쳐서 쓰면 이렇게 수가 커지는걸 막을 수 있는 것

 

ex) 유튜브. 

     비디오 식별할 때 처음에는 숫자로 했었음. 

     근데 지금은 영상 식별을 문자로 바꿈

 

anyway 섞어서 괜찮으면, 2개로만 써도 됨

-> 그럼 실선으로 (식별 관계)

 

1번은 식별자 선, 2번(점선)은 비식별자 선

단점은 

where절에 '찜'을 불러오기 위해서 & 두개의 키를 불러와야 함

(키를 다루는게 불편) 

 

만약 '찜'에 풍선 있으면 아래 뭐 넣는건데 없으면 아무것도 안 넣는 것

 

신청자아이디, 

수락자아이디 

-> 우리조거에 추가하기

cf) 이거는 추가해주지 않아도 됨 

- 우리조는 수락 과정 없이 그냥 follow 하게 해주는거니까~ 

 

ㅡㅡㅡㅡㅡ

 

0, 1, n의 의미였구나

---

1:n, n:1을 풀어보자

-> 무조건 n에 들어간다? 

 

책 ------- 모임

둘 사이 연결 관계 1:n으로 연결해보기

 

비식별(실선)으로 

옵션 세번째거로 

'책 아이디' 

 

더블클릭

general

-> no null (null 허용하지 않겠다) 

-> 0 사라짐

(책 없이 모임은 불가능하다 / 불허용하겠다는 것)

 

우리조 거♡

[책]을 해석해보자 - 맨 위: 아이디 (책의 식별자)  - 맨 아래 : 등록자아이디(FK - Foreign Key)   관리자 entity와 연결지어 해석해보면 -> '하나의' 등록자 아이디에, n개의 책이라는 것 - 책이 없어도 관리자는 존재하니 관리자--- 책0 에 null을 해준거고   (이거 이해하면 null 이해는 걱정할바 없음)  [모임]을 해석해보자 - 맨 아래 : 등록자아이디(FK)    하나의 등록자 아이디에 n개의 모임 - 책아이디(FK)   하나의 책에 n개의 모임 그리고 n:n 관계는 create 해줘서 오른쪽처럼 만들어준거고 (슈퍼키로)

 

// 

1단계 - ppt

2단계 - 이거

오후 시간에 - 3단계

---

정규화 (Normalization) 

- 정상화, 표준화랑 같은 말

 

DB의 가장 중요한 특징 중 하나 

-> 무결성 (데이터의 중복 없이)

 

중복을 제거하는 것이 중요! 

 

So, '정규화'란 db의 가장 중요한 덕목 중 하나인 중복을 없애는 방법에 대해 말하는 것

 

ㅡㅡㅡㅡㅡ

 

1 정규화

도메인 원자값.... 

무슨 말일까 

 

 

Q, '데이터에서의' 도메인이란? 

- (유효한) 값(의 범위)

Q. 원자값이란? 

- 하나의 값으로만 이루어져한다는 것

 

ex) 설립일 2020-05-14 

     전화번호 02-111-2222

     메일 admin@aaa

 

     설립일 2020-05-14

     전화번호 02-111-2222

     메일 manager@aaa

 

     만약 2개의 이메일을 가지면... 

   근데 만약 이메일 개수에 제한이 없다면 이렇게 표현하는게 문제.

   제한이 있어야 한다. 

 

  

   중복

   위반! 

 

속성만 보고도 판단을 할 줄 알아야 함

- 느낌적인 느낌으로 알아야 한다. ("이거... 하나만 입력 받나?" 하고) 

1개만 받을지

N개도 받을 수 있는지 

 

N개 받을 수 있으면 원자값이 아닌 것! 

 

-> 원자값으로만 이루어져 있어야 한다는건, 

 

중복되어있으면 조치를 취해야함

 

내가 뽑은 원자값 

-> 비밀번호, 회사명, 대표자명, 설립일, 형태, 프로필사진, 지역명, 세부지역, 나머지주소, 예금주명 

 

내가 뽑은 원자값에 위반되는거 고르기

-> 이메일, 전화번호, 팩스번호, 담당자명, 핸드폰번호, 세금계산서용이메일, 은행명, 계좌번호

 

2개 이상 있을 수 있는거

 

선생님 : 은행명, 예금주명, 계좌번호 여러개

-> 위반되는건 자식으로 빼야함

 

우리조거에서 1정규화가 위반되는걸 골라보자~! 

 

이거 식별자 틀림. 아래 그림처럼 수정해야함

 

 

대리키가 들어가면 그거 하나로 식별키가 되는 것

 

Q. 댓글 - 내용이 정규 위반이 왜 아닌거지? 

-> 이건 지금 그냥 관계를 '다시 올바르게' 고쳐준 것

 

저자 

-> 자식 테이블 만들어질 것

 

자식 테이블 만드는 법

1) 테이블 만들어서 빼기

2) 컬럼 안에다가 , 콤마로 구분해서 넣기 (선생님 선호는 2번)

 

속성이 2개 이상일 경우에는 1번으로 테이블 빼기

-> 뺐을 때의 장점은 update, delete 하기가 편하다

 

1번은 SQL로만 조작 가능, 2번은 자바로 조작 할 게 많을수도. 

 

ex) 프로필에서의 배경 - 한 개라고 하면 한 개인거긴한데, 카톡 프사처럼 이전것들 저장해주겠다 하면 위반화인 것

 

---

3정규화 

먼저 찾아보기

 

블로그 중에 공신력 있는 내용으로 설명하지 않고 자기 멋대로 평가하는 경우도 많아서 ... 

그대로 믿지 말기!! 

-> 영어 wiki를 보자 or 네이버 지식백과 (블로그부터 보는건 노노)

 

'이행적 함수 종속' 을 이해해야함

우연이 아님

 

3정규화 위반은, 계속 반복해서 들어갈 가능성이 있는 것

old한 데이터가 '자꾸' 들어갈 가능성이 있는걸 찾아야 함

 

하나 바꾸면 다른 것도 같이 바꿔야. 

 

매니저 이름, 연락처, 이메일 -> 3정규화 위반임!

 

어떻게 조치를 할거냐면 

-> 분리해야함

 

 

old한 녀석이 반복을 만들어야 하니 / 미리 만들어야 해서 부모가 됨! 

cf) 1정규화에서는 자식이 만들어졌었는데

 

노란색 - 쫓아낸 것들

 

우리 프로젝트에서 old한걸 찾아보자

(계속 같은거 들어가는거 같은데..? 하는 느낌이 드는 것들)

 

나간만큼 - FK 증가! 

 

찾아보고 테이블 분리하기 

 

3정규 위반은 무조건 테이블 분리임 (1정규 위반과는 달리 옵션이 없다.)

 

개념! 

-> 개설 테이블 있지? 

    개설하고, 또! 개설할 때 '같은 데이터'가 계속 사용되는 것. 

 

그래서 우리 조거에도 

-> 책, 책, 책... 되면 '분류'는 같을테니 빼준 것 (저자도) 

 

우리조 거♡

 

'저자'를 3정규화 오류로서 뻬주었다. 

 

피드백

저자명, 저자소개 -> 이름, 소개로 바꾸기

책 분류 -> 빼주기

 

VER2 만들 때는 고쳐지는게 많아 누더기가 될텐데 

-> 오래 운영하면 그렇게 된다고 한다 ㅎㅎ (그래서 회사 가서 테이블 가면 파악하기가 힘들다고...)

 

 

//

 

2정규 - 위반되는게 없음 (이미 지적해서) 

4정규 - 이미 했다고 한다. 

 

그래서 다음 시간에는 개념만 만들고 끝~