1. 데이터베이스란?
① 정의 : 여러 응용 시스템을 통해 액세스가 가능한 공유된 형태의 통합된 데이터들의 집합
② 데이터베이스를 공뷰하는 이유 : 다이어리를 이용하여 주소록, 연락처 등을 관리하거나, 일기장에 일기를 쓰거나 가계부를 적는 등의 많은 일상생활 속에서 우리는 이미 데이터베이스를 구축하여 사용하고 있으며 , 이러한 내용을 컴퓨터를 이용하여 물리적, 논리적으로 체계화 시켜서 보다 효율적으로 사용할 수 있다.
2. 데이터베이스 관리 시스템(DBMS)
① 데이터베이스 관리 시스템의 특징
데이터 독립성
- 물리적 독립성: 데이터베이스 사이즈를 늘리거나 성능 향상을 위해 데이터 파일을 늘리거나 새롭게 추가하더라도
관련된 응용 프로그램을 수정할 필요가 없다.
- 논리적 독립성 : 데이터베이스는 논리적인 구조로 다양한 으용 프로그램의 논리적 요구를 만족시켜 줄 수 있다.
데이터 무결성
- 여러 경로를 통해 잘못된 데이터가 발생하는 경우의 수를 방지하는 기능으로 데이터의 유효성 검사를 통해 데이터의
무결성을 구현하게 된다.
데이터 보안성
- 인간된 사용자들만 데이터베이스나 데이터베이스 내의 자원에 접근할 수 있게 계정 관리나 권한을 설정함으로써
모든 데이터에 보안을 구현할 수 있다.
데이터 일관성
- 연관된 정보를 논리적인 구조로 관리함으로써 어떤 하나의 데이터만 변경했을 경우 발생할 수 있는 데이터의
불일치성을 배제할 수 있다.
또한 작업 중 일부 데이터만 변경되어 나머지 데이터와 일치하지 않는 경우의 수를 배제할 수 있다.
데이터 중복 최소화
- 데이터베이스는 데이터를 통합해서 관리함으로써 파일 시스템의 단점 중 하나인 자료의 중복과 데이터의 중복성을
해결 할 수 있다.
※ 파일 시스템 ? 가장 초보적인 데이터 관리 형식 업무와 관련한 데이터를 각각의 파일 단위로 저장하며 ,
이러한 파일들을 처리하기 위한 독립적인 애플리케이션과 상호 연동되어야 한다.
문제점은 데이터 종속성 문제와 중복성, 데이터 무결성이 문제가 될 수 있다.
② 데이터베이스 관리 시스템(DBMS )
- 파일 시스템의 단점을 극복하고 데이터를 효율적으로 관리하기 위한 시스템이며, 사용자 애플리케이션과
데이터베이스간의 인터페이스 역할을 하는 논리적인 프로그램
- 데이터베이스 관리 시스템(DBMS)의 유형
FileSystem= SAM-> ISAM=>USAM
- DBMS 종류
계층형(Hierarchical) DBMS
장점 : 데이터가 계층적으로 상하 종속적인 관계로 구성되어 있으며 데이터의 액세스 속도가 빠르고 데이터 사용량을
쉽게 예측할 수 있다. 데이터 사용량을 쉽게 예측할 수 있다.
단점: 데이터 구조가 상하 종속적인 관계로 구성되어 있기 때문에 초기 셋팅 후에 변화하는 프로세서를 수용하기 쉽지 않다.
(급변하는 시대에 처리하기 쉽지 않다.)
망형(Network) DBMS
데이터베이스의 구조를 네트워크상의 노드 형태로 논리적으로 표현하는 데이터 모델로서 각각의 엔티티
(Entity,데이터를 저장하기 위한 기본 단위)들로 서로 대등한 관계로 구성한 시스템
단, 구성과 설계가 복잡하다.
관계형(Relational) DBMS
RDBMS 는 수학적 논리 관계를 데이블 형태로 구성한 구조로 테이블 내의 컬럼 중 일부를 다른 테이블과 중복함으로 해서
각 테이블간의 상관관계를 정의한다.
※ RDMS 가 주류를 이루는 가장 중요한 이유?
- 업무 변화에 대한 적응 능력의 탁월함
- 유지 , 보수 또한 매우 편리하기 때문에 다른 시스템에 비해 생.산.성 이 높다.
- 질의 기능이 간편해서 사용자들의 질의한 후 이를 받아서 처리하는 응용 프로그램 개발이 비교적 용이하다.
ex) 새로운 업무가 발생했을 경우 해당 업무를 저장할 테이블 추가로 기존 테이블과 관계(Relation)을 형성함으로써
모든 프로세스들을 처리할 수 있다.
- 단 단점은 새로운 업무가 발생했을 경우 해당 업무를 저장 할 테이블을 추가로 기존 테이블과 관계(Relation)을 형성함으로써
모든 프로세스들을 처리할 수 있다.
그 외) 객체 지향(Object Oriented) DBMS
객체 관계형(Object Relational) DBMS
- RDMS의 한계점인 그래픽, 비디오, 오디오와 같은 지속적인 멀티미디어 데이터의 저장 욕구가 일기 시작하여 나온기술
○ RDBMS 예제
| 여러분은 자동차 영업사원이다. 여러분은 고객 정보를 다이어리로 기록/관리 하고 있다. 분실, 정리 문제점으로 고객 관리 데이터베이스를 만들어 고객 관리 테이블에 모든 고객 정보를 옮겨 놓기로 한다. |
- 고객 관리 테이블 구조
테이블명:『고객관리』
이름 | 주민번호 | 전화번호 | H.P | 회사명 | 직책 | 우편번호 | 주소 | 차종 | 차명 | 년식 | 구입일 |
.... | ... | ... | ... | .... | .... | ... | .... | .... | .... | .... | ... |
문제점 : 고객 중 차량을 현재 소유하지 않을 경우 차종,차명,년식 구입일... 컬럼들은 NULL값을 갖게 될 것이다.
그러면 쓸데없는 공간의 낭비되고 있다.
○ L 자형 테이블 -- > 위의 고객 정보를 차량없는 고객들과 차량 있는 고객들로 정리하면 L자형 테이블 설계 유형이 될 것이고,
이러한 L자형 테이블은 가장 잘못된 설계의 대표적인 형식이다.
※ L자형 테이블 나누는 방법
1. 레코드를 기준으로 테이블 나누기(가로)
-> 차량 소유 고객 테이블, 차량 비소유 고객 테이블
문제점: 고객이 차량 소유가 변경되었을 경우 테이블을 옮겨야 하는 문제점.
하루에도 몇 천, 몇 만건의 데이터가 서로
테이블을 옮겨야 하는 상황이 발생하게 되는데 이러한 프로세스를 누가 관리할 것인가?
해결 : 역정규화 또는 레코드를 기준으로 테이블을 나누지 않는다.
2. 컬럼을 기준으로 테이블 나누기(세로)
개인 신상 테이블 자동차 테이블
컬럼을 기준으로 테이블을 분리하면 NULL 값이 들어가는 공간이 필요 없기 때문에 효율적으로 데이터를 저장 할 수 없다.
문제점: 두 테이블의 관계(Relation) 을 설정하지 않으면 고객이 어떤 자동차를 소유하는지에 대한 정보를 알 수 없다.
★ 여기서 『관계(Relation)』라는 개념이 필요하다.
○ 관계에 대한 정의
RDBMS 의 관계(Relation)란 업무의 연관성이다. 위의 예제에서 개인신상, 자동차 두 테이블은 업무적 연관성 즉 관계가 있는가? 있다.
원래 자동차 영업사원이 업무적으로 고객관리 목적으로 하나의 테이블을 만들었지만, 테이터의 관리 효율성을 목적으로 두개의 테이블로 나누었고 영업사원이 원하는 정보를 얻으려면 위의 두 테이블에서 일치하는 정보들을 가져와야 하므로 두 테이블 간에는 업무적인 연관성 즉 관계가 있다.
○ 부모테이블과 자식테이블에 대한 정의
- 관계는 두 테이블 간에 맺어지기 때문에 하나는 반드시 부모(Parent) 테이블이고 나머지 하나는 자식(Child) 테이블이다.
※ 위의 예제에서 어느 것이 Parent / Child 테이블일까?
1. 두 테이블 중 어떤 테이블이 주체인지 파악하기 위해서 관계를 서술해보면 쉽다.
고객이 자동차를 소유한다(ㅇ)/ 자동차가 고객을 소유한다(X)
2. 1: 多 관계를 확인한다.
※ 재귀적 관계: 한 테이블이 자기 자신과 관계있는 경우
3. 정규화
① 정규화란? 정규화란 한마디로 DB서버의 메모리를 낭비하지 않기 위하여 어떤 테이블을 식별자로 가지는 여러개의 테이블로 나누는 과정을 말한다.(어떤 테이블이 더 이상 쪼갤 수 없을때까지 쪼갠다.)
② 정규화의 종류
♧ 제 1정규화
어떤 테이블에서 반복되어지는 컬럼값들이 존재한다면 값들이 반복되어 나오는 컬럼들을 분리해서 새로운 테이블을
만드는 것이다.
ex) 서울 여의도 LG라는 회사에 근무하는 거래처 직원 명단이 1000000명이라고 가정한다
그리고 한 행이 100 Byte라고 보자 (10개 컬럼)
『거래처직원』정보를 데이터베이스화 하려고 한다.
| 『거래처직원』테이블 -------------------------------------------------------------- ------------------------------------------------------------- |
<<제 1 정규화 과정>>
1. 반복되어지는 컬럼(거래처회사명/회사주소/회사전화)을 따로 걸러내어서 테이블을 생성한다.
『회사』테이블 :1 -> 부모테이블 (참조되어지는 테이블)
| --------------------------------------------- 회사ID 거래처회사명 회사주소 회사전화 (P.K) --------------------------------------------- 10 LG 서울여의도 02-345-6789 |
↑
※ 참조 받는 컬럼
1. 반드시 고유한 값만 들어가야 한다.
2. 중복된 값이 없어야 한다.
3. Not Null 이어야 한다. -> Primary Key
2. 나머지 테이블 『직원』-> 자식테이블
| ----------------------------------------- 직원명 직급 이메일 휴대폰 .... 회사ID (Reference Key) (F.K=Foreign Key)외부키 ----------------------------------------- 박지원 부장 pjw@n.c 010- ... 10 신범수 과장 sbs@n.c 011- ... 10 윤상미 대리 ysm@n.c 016- ... 10 김미나 부장 kmn@n.c 010- ... 20 임지혜 대리 ijh@n.c 010- ... 30 ............... |
3. 1정규화 과정전과 후의 메모리의 차이점
○ 1정규화 과정전?
100Byte(한 행당 차지하는 메모리) X 1000000(행의 개수)=100000000Byte=100MB
○ 1정규화 과정후 ?
40Byte X 3 + 80ByteX200만
---------- ------------
120Byte 1600만Byte
회사테이블 직원테이블
==> 메모리가 더 적게 들었다.(이럴 경우 해주는것이 더 좋다.)
※ 제 1정규화의 특징
--> 부모 테이블에 존재하는 Primary Key(식별자)는
-- 항.상 자식 테이블의 Foreign Key로 전이된다.
<<제 2 정규화 과정>>
① 제 2 정규화란? 제 1정규화를 마친 결과물에서 기본키(식별자가) 하나의 컬럼이면 하지 않는다. 그러나 기본키가 두개이상(복합 컬럼)이면 반드시 제 2정규화 해야한다.
식별자가 아닌 컬럼이 식별자 전체 컬럼에 대해 의존적이어야 한다. 식별자 전체 컬럼이 아닌 일부 컬럼에 대해 의존적이라면 이것을 분리하여 새로운 테이블을 생성한다.(예를 들어서 과목번호/교수번호가 기본키로 설정되어 있을때 교수명은 교수번호에 대해서만,과목명은 과목번호에 대해서만 의존한다. 이러한 것들을 따로 잘라낸다.)
예제. 다음 테이블들을 제 2정규화를 해보시오.
『개설과목』테이블 ------------------------------------------------------- 과목번호 과목명 교수번호 교수명 강의실코드 강의실설명
| 『점수』테이블 ------------------------------------------
|
제 2정규화 과정
『개설과목』 테이블 정규화 과정(부모테이블)
『과목』테이블 ------------------------------------ |
『교수』테이블 ------------------------------------
|
『개설과목』테이블 -------------------------------------과목번호 교수번호 강의실코드 강의실설명 P.K ------------------------------------
|
『점수』 테이블 정규화 과정(자식테이블)
『성적』테이블 ----------------------------------- | 『학생』테이블 ----------------------------------- |
<< 제 3정규화 과정>>
① 제 3정규화란? 식별자가 아닌 컬럼에 의존적이라면 이것을 분리해서 새로운 테이블을 생성한다.
② 제 3정규화 과정
제 2정규화 한 테이블에서 개설과목 테이블을 가져왔음
『개설과목』테이블 ------------------------------ ------------------------------- ※이 부분좀 이해가 안되는데..-_-.... 개설과목테이블에서 가져오는데 ... 왜 P.K가 강의실코드지? |
『강의실』테이블 ------------------------ |
<< 제 4정규화 과정>>
① 제 4정규화란? 多: 多 관계를 1:多 또는 多:1 관계로 바꾼다.
『고객』테이블 ------------------------- 고객ID 고객명 휴대폰 P.K -------------------------- CMS 장명수 010- HYH 함명환 011- | 『제품』 테이블 제품코드 제품명 단가 p.K --------------------- SWK 새우깡 700 KON 콘 칩 800 KJK 감자깡 600 |
각 테이블들은 다 대 다 관계를 이루고 있다.
고객이 여러 제품을 살수 있고 제품 또한 여러 고객에 의해서 선택 될 수 있다.
추가+
해결하기 : 주문 테이블을 하나 만든다.
-------------------------------------- |
4. 그 외
① select 문의 처리 순서
SELECT 컬러명 -- ⑤
FROM 테이블 -- ①
WHERE 조건절 -- ②
GROUP BY 절 -- ③
HAVING 조절절 -- ④
ORDER BY 절 -- ⑥
② Composite Primary Key
| 『주문』 테이블 ----------------------------------------------------- 고객ID 제품코드 주문일자 주문수량 ----------------------------------------------------- JJH 새우깡 2008-10-26 14:25:09 50 YNY 양파링 2008-10-27 15:30:06 30 SJH 새우깡 2008-10-27 16:31:08 30 SJH 초파이 2008-10-27 16:31:08 20 SJH 초파이 2008-10-27 16:31:08 20 SJH 초파이 2008-10-27 16:31:08 20 MJY 양파링 2008-10-28 15:30:06 30 MJH 양파링 2008-10-28 15:30:06 30 |
문제) 위의 주문 테이블의 기본키로 적합한 것은 무엇인가?
Primary Key 에 적합한 것은 없다. 어떤 테이블상에 존재하는 Primary Key 의 최대 개수는 1개이다.
그러나 Primary Key 를 이루는 컬럼의 개수는 복수 컬럼이 존재한다.
컬럼 1개만 가지고 생성된 Primary Key는 Single Primary Key 라 부르며 2개 이상의 컬럼을 가지도 생성된 Priamry Key는 Composite Primary Key(복합 프라이머리 키)라고 부른다.
ex) 현재 고객ID와 제품코드와 같이 기본키 역할을 한다. -> JJH새우깡/ YNY양파링..
③ 관계(Relation) 종류
1. 1:1 관계
『회원』테이블
| ----------------------------------------------------------------------------------------------------------- ID PW 성명 주민번호 우편번호 주소 전화번호 이메일 휴대폰 관심분야 결혼여부 ------------------------------------------------------------------------------------------------------------ superman 1234 |
| 『로그인』테이블 ----------------- ID PW +++++++ P.K F.K ----------------- |
* 회원테이블 과 로그인 테이블은 1:1관계이다.
2. 1:多 관계 : 제 1정규화를 한 것이다.
3. 多:多 관계: 논리적인 모델링에서는 존재하지만
실제 물리적인 DB(오라클,MSSQL 서버)에서는 존재하지 않는다.
多: 多 관계를 1: 多 관계롤 깨버리는 것이 제 4정규화이다.
[출처] DB,RDBMS,정규화 (스크랩 )|작성자 에스패스트