일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- spring 쇼핑몰
- 인증번호 전송
- 스프링 게시판 구현
- 삭제 구현
- 회원가입 기능
- 스프링 쇼핑몰 프로젝트
- 쇼핑몰 프로젝트
- 정규표현식
- 쇼핑몰 포트폴리오
- arraylist
- 이미지 출력
- spring 프로젝트
- 스프링 프로젝트 설정
- 스프링 프로젝트 기본 설정
- 스프링 프로젝트
- 스프링 쇼핑몰
- ResponseEntity
- 스프링 HikariCP
- Bcrypt
- 스프링 포트폴리오
- 파일 업로드
- oracle 설치방법
- 스프링 파일 삭제
- 로그인 기능
- 스프링 이미지
- BCrypt 적용
- 스프링 업로드
- 스프링 메일 전송
- 스프링 게시판
- 로그아웃 기능 구현
- Today
- Total
Kim VamPa
[Oracle 기본사용법][07] 표(table) 분리 필요성 본문
"생활코딩 Oracle"을 개인 공부 후 자료를 남기기 위한 목적이기에 내용 상에 오류가 있을 수 있습니다.
목표
- 관계형 데이터베이스에서 표(table) 분해가 왜 필요한지에 대해 공부합니다.
목차
- 표(table) 분해하지 않을 시 불편한 점
- 표(table) 분해 했을 경우
표(table) 분해하지 않을 시 불편한 점
관계형 데이터베이스는 표(table) 형태로 데이터를 다루는 혁명적인 방법입니다. 이러한 표(table)가 작은 개념 단위로 분리되어야 하는 이유에 대해 살펴보고자 합니다.
제가 책 인터넷 쇼핑몰 사이트를 운영한다고 가정하겠습니다. 저는 제가 가지고 있는 제품을 체계적으로 관리하기 위해 [book_product] 표(table)를 데이터베이스 시스템을 통해 운영 중입니다. 표는 다음과 같습니다.
book_product | |||||
제품번호 | 책제목 | 출판사 | 재고량 | 작가 | 작가 작품 수 |
B_00001 | 살인자의 기억법 | 문학동네 | 30 | 김영하 | 20 |
B_00002 | jaAVA의 정석 | 도우 출판 | 15 | 남궁성 | 5 |
B_00003 | 표현의 기술 | 생각의길 | 20 | 유시민 | 40 |
B_00004 | 오직 두 사람 | 문학동네 | 30 | 김영하 | 20 |
... | ... | ... | ... | ... | ... |
표를 보시면 각 제품(책)에 제품번호가 매겨져 있고 해당 책의 출판사, 재고량, 작가, 작가의 작품 수의 정보를 알 수 있습니다. 표에선 4개의 제품만 보이지만 이표의 레코드(제품 종류 수)는 1천 개라고 가정하겠습니다. 다시 말해 저는 1천 개의 제품을 book_product를 통해서 관리하고 있는 셈입니다.
그런데 book_product 표는 관리하는데 불편한 점 두가지가 있습니다. 첫 번째, 어떤 특정 데이터의 정보를 수정을 해야 할 경우 그와 관련된 데이터 개수만큼 일일이 수정해야 한다는 점입니다. 예를 들어 '유시민'이라는 작가가 새로운 책을 출간하였다고 가정하겠습니다. '작가 작품 수'는 40에서 41개로 수정되어야만 합니다. 따라서 book_product 표에선 한 행을 추가하고 기존에 있던 유시민 작가의 '작가 작품 수' 40개를 일일이 수정(40=>41)해주어야 합니다. 좀 더 극단적으로 생각을 해보면 하나의 데이터를 수정해야 하는데 관련 데이터가 1억 개인 경우 일일이 1억 개를 모두 수정해주어야 하는 것입니다.
두 번째, 특정 컬럼의 데이터는 분명 존재하지만 표(table)에 아직 그와 관련된 칼럼의 데이터가 존재하지 않기 때문에 표(table)에는 데이터가 존재할 수 없다는 점입니다. 예를 들면 '설민석'이라는 작가는 세상에 분명 존재합니다. 하지만 저의 book_product에서는 아직 '설민석'작가의 책을 보유하지 않았기 때문에 book_product표에는 데이터 자체가 존재하지 않습니다.
표(table) 분해 했을 경우
아래는 book_product를 제품의 개념 단위와(book_product) 작가의 개념 단위(book_author)를 분리한 경우의 표입니다.
book_product | ||||
제품번호 | 책제목 | 출판사 | 재고량 | 작가ID |
B_00001 | 살인자의 기억법 | 문학동네 | 30 | A_001 |
B_00002 | JAVA의 정석 | 도우 출판 | 15 | A_002 |
B_00003 | 표현의 기술 | 생각의길 | 20 | A_003 |
B_00004 | 오직 두 사람 | 문학동네 | 30 | A_001 |
... | ... | ... | ... | ... |
book_author | ||
작가ID | 작가 | 작가 작품 수 |
A_001 | 김영하 | 20 |
A_002 | 남궁성 | 5 |
A_003 | 유시민 | 40 |
A_004 | 김영하 | 20 |
... | ... | ... |
A_101 | 설민석 | 12 |
표를 보시면 작가ID를 통해 두 개의 테이블 데이터들이 연결되어 있습니다. 이렇게 표가 분리되었을 경우 앞서 표가 분리되지 않아서 불편했던 두 가지가 모두 해결이 됩니다. 첫 번째, 기존에 '유시민'이라는 작가의 '작가 작품 수'를 수정하기 위해선 작품 수(40개)만큼 일일이 수정을 해주어야만 했습니다. 하지만 분리 한 이후에는 book_author 테이블의 서 단 한 개의 필드만 수정을 해주면 됩니다.
두번째, '설민석'이라는 작가가 존재하고 '설민석'작가의 데이터를 관리하고 싶었음에도 기존 테이블(book_product)에 다른 칼럼의 데이터(작품)를 가지지 않았기 때문에 데이터를 관리하지 못하였습니다. 하지만 표를 분리한 이후 제품(책)을 아직 소유하지 못하여서 book_product 테이블에 데이터가 존재하지 않지만 작가 개념만 존재하는 테이블(table)이 존재함으로써 '설민석'작가의 데이터를 관리할 수 있게 되었습니다.
정리를 하면 표(테이블)을 작은 개념 단위로 분해 함으로써 사용자가 데이터에 대해 특정한 요청을 하였을 때 빠른 속도로 처리할 수 있고, 데이터를 좀 더 효율적이고 효과적으로 관리할 수 있습니다.
Reference
Date
- 2020.04.14 작성
'공부 > 데이터베이스' 카테고리의 다른 글
[데이터베이스][JOIN][1] 조인(JOIN)이란? (0) | 2020.04.21 |
---|---|
[Oracle 기본사용법][08] 표(table) JOIN (0) | 2020.04.15 |
[Oracle SQL Developer][02] 데이터베이스 접속 방법 (2) | 2020.04.11 |
[Oracle SQL Developer][01] SQL Developer 설치방법 (0) | 2020.04.10 |
[Oracle 기본사용법][06]오라클에서의 서버(Server)와 클리아언트(client)란? (0) | 2020.04.09 |