[iOS - swift] 5. 관계형 데이터 베이스(RDBMS)의 개념

* 프로퍼티 리스트는 데이터를 쌓기보다는 데이터 갱신에 초점

- 만약 프로퍼티 리스트로 데이터를 관리한다면, 배열타입이므로 "query"를 사용하지 못하므로 검색에 어려움

- 새로운 데이터를 추가하려면 매번 모든 배열 데이터를 메모리로 "load"했다가 다시 프로퍼티 리스트에 저장하므로 비효율 적

 

* 관계형 데이터 베이스 : 데이터들이 서로 결합될 수 있는 관계를 제공하는 데이터베이스 형태

관계형 데이터 베이스끼리 "Join"

1. DBMS

1) 개념

(Database Management System)

* DB : 데이터들을 저장하고 있는 공간

* DBMS : DB내에 저장된 데이터에 손쉽게 접근할 수 있도록 해주는 소프트웨어 도구 (Oracle, MariaDB, MySQL, SQLServer)

 

cf) "개발자들의 대화에서는 DB무엇을 쓰나요? == DBMS를 무엇을 쓰나요? 의미 통용하므로 주의

 

2) 종류

 - 서버로 분류되는 DBMS : SQL Server, MySQL

 - 응용 프로그램의 부분적인 모듈로 작동하는 DBMS : SQLite (독릭적인 서버로 설치해서 사용할 수 없다는 의미)

    (SQLite는 다른 DBMS처럼 네트워크를 통해 서비스를 제공하지 않기 때문에 항상 애플리케이션과 함께 있어야 함)

 - 데이터 사이들의 Join관계를 지원하지 않는 데이터베이스 (==NoSQL) : MongoDB(JSON형테 데이터), Hadoop

 

3) 트랜잭션

CRUD를 적절히 사용하여 원하는 업무를 해내는 것

    == 업무적인 측면에서 데이터베이스 작업의 최소 단위

 

- commit : 트랜잭션의 최종 결과가 성공

- Rollback : 트랜잭션의 결과가 실패인 경우 아무것도 실행되지 않았던 처음으로 되돌리는 것

 

4) 트랜잭션의 원칙

- Atomicity(원자성): 한 트랜잭션은 모두 수행되든지 아무것도 수행되지 않아야 함(애매하게 중간 결과를 유지하면 안됨)

- Consistency(일관성) : (== 무결성을 유지), A가 B에게 100만원을 보낼 때, A, B돈의 합은 트랜잭션 전 후 같아야함

- Isolation(격리성) : 각각의 트랜잭션은 독립성을 지녀야 하며, 하나의 트랜잭션이 실행되는 동안 다른 트랜잭션이 접근할 수 없음

- Durability(지속성) : 트랜잭션이 성공해서 DB에 커밋되면 어떤 오류가 발생되어도 DB에 계속 보존 지속 되어야 함

 

2. RDBMS

id	사원코드	주민번호	이름
1	M001	940304-1122334	홍길동
2	M002	870302-1122331	김길동

1) Table, Entity

 Entity : 공통적인 속성 항목을 가지는 데이터를 관리하기 위해 정의하는 구조

 Table : Entity를 실제 DB에 적용하여 사용 가능하도록 구현한 것

 

2) Row, Record

 Table의 각 행 단위 데이터를 "가리키는" 것을 의미

 

3) Column, Field, Attribute

 테이블의 하위 구조이며 하나의 레코드를 구성하는 요소

 

4) PK(Primary Key), 기본키

 사원코드, 주민번호

테이블 내의 고유값이 저장된 칼럼이름을 PK라 함, 단 아래 조건(유일성)을 만족해야하는 것

- PK로 지정된 칼럼은 값이 중복되지 않아야 함

- PK로 지정된 칼럼은 값이 NULL이면 안됨

 

* PK를 찾기 어렵다면, Auto Increment등과 같은 "Unique 값"설정

   위 테이블에서, id

 

* PK의 이점? 물리적 장치에 의해 무결성 원칙 보장(실수에 의한 값의 중복 입력 방지)

 

5) CK(Candidate Key), 후보키

 사원코드, 주민번호

하나의 테이블에서 PK로 사용할 수 있는 칼럼이 여러개인 경우, 이 Key들을 CK라 함

 

6) CK(Complexed Key), 복합키

 하나의 칼럼으로는 기본 키의 요건에 부합되지 않는 경우 복수의 키로만 기본키의 요건을 만족하는 경우

 - 단, 최소화된 칼럼 조합으로 기본키가 표현 되어야 함

 

3. 정규화

DB에서 크고 제대로 조직되지 않은 데이블을 여러 개의 작고 잘 조직된 테이블로 나누는 것을 의미

일반적으로는 제1 정규화~ 제6정규화까지 존재하지만, 업무에서는 1~3정규화까지 이해해도 용이

 

1) 제 1 정규화(도메인이 원자값) : 하나의 칼럼에 들어가는 값은 더 이상 쪼갤 수 없는 원자값

2)제 2 정규화(부분적 함수 종속 제거) : 기본키가 복합키인 경우 복합키끼리 모두 종속되어야 함(일방적 종속 x)

3) 제 3 정규화(이행적 함수 종속 제거) : 모든 칼럼은 기본키에 종속되어야 함

 

ex) 비유로 알아보는 정규화

파티의 주최자는 기본키,

파티의자에 앉을 때 한의자에 오직 한 명씩만 앉아야 함(도메인이 원자 값)

A, B가 파티를 주최했다면 A와 B양쪽에서 모두 초청받은 사람만 파티에 참석 가능(부분적 함수 종속 제거)

A주최자 한 명이고 A와 B가 친구일 때 A의 파티에 B가 참석하는 것은 괜찮지만, B의 친구인 C가 참석하면 안됨(이행적 함수 종속 제거)

 

 

---

제 1 정규화 위반 (도메인이 원자 값 이위반)

id	이름	전화번호
1	홍길동	010-1234-4567
2	김길동	010-1234-1221, 010-1234-2123

 

해결

id	이름	전화번호
1	홍길동	010-1234-4567
2	김길동	010-1234-1221
3	김길동	010-1234-2123

 

---

제 2 정규화 위반 (부분적 함수 종속 제거 위반)

부서명	근무지	사원정보
인사팀	201호	사원코드   사원명   직급 M001.      홍길동.   과장 M002,     김길동,   부장
개발팀	202호	사원코드   사원명   직급 M003.      홍박동.   사원 M004,     김박동,   과장

 

해결(단 근무지 칼럼이 중복되는 문제 존재, 부서가 결정되면 근무지도 종속되어 있음)

부서명	근무지	사원코드	사원명	직급
인사팀	201	M001	홍길동	과장
인사팀	201	M002	김길동	부장
개발팀	202	M003	홍박동	사원
개발팀	202	M004	김박동	과장

* 갱신 이상 - 만약 인사팀이 201호에서 301호로 이사했다면, 모든 정보 업데이트해야 하는데 일부만 하는 경우

  삽입 이상 - 새로운 부서가 추가 되었을 때, (사원코드, 사원명, 직급의 데이터는 비어있음)

  삭제 이상 - 유일한 부서(위 테이블에서 마케팅팀 이의 사원만 있는 경우), 그 사원을 삭제하면 마케팅팀의 부서정보도 사라짐

-> 하나의 테이블을 외래키를 두고 두 테이블로 나눈 후 join이 필요

 

---

<부서 테이블>

부서명	근무지
인사팀	201호
개발팀	202호

<사원 테이블>

부서명	사원코드	사원명	직급
인사팀	M001	홍길동	과장
인사팀	M002	김길동	부장
개발팀	M003	홍박동	사원
개발팀	M004	김박동	과장

 

사원 테이블에서 부서명은 부서 테이블의 외래 키이므로 결합하여 사용

(단 부서명의 칼럼은 언제든 값이 바뀔 수 있으므로 따로 부서 코드를 새로 칼럼으로 만들고 그것을 통해 join하는 것이 합리적)

- 연결된 관계를 "Relation"이라 함