일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 | 31 |
- UITextView
- Clean Code
- rxswift
- Protocol
- UICollectionView
- collectionview
- Refactoring
- uiscrollview
- Observable
- clean architecture
- 스위프트
- 리펙토링
- SWIFT
- 리팩토링
- MVVM
- 리펙터링
- RxCocoa
- Xcode
- uitableview
- HIG
- combine
- tableView
- ios
- map
- 애니메이션
- swiftUI
- swift documentation
- 클린 코드
- ribs
- Human interface guide
- Today
- Total
김종권의 iOS 앱 개발 알아가기
[iOS - swift] 5. 관계형 데이터 베이스(RDBMS)의 개념 본문
* 프로퍼티 리스트는 데이터를 쌓기보다는 데이터 갱신에 초점
- 만약 프로퍼티 리스트로 데이터를 관리한다면, 배열타입이므로 "query"를 사용하지 못하므로 검색에 어려움
- 새로운 데이터를 추가하려면 매번 모든 배열 데이터를 메모리로 "load"했다가 다시 프로퍼티 리스트에 저장하므로 비효율 적
* 관계형 데이터 베이스 : 데이터들이 서로 결합될 수 있는 관계를 제공하는 데이터베이스 형태
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"이라 함
'iOS 실전 (swift) > 데이터베이스' 카테고리의 다른 글
[iOS - swift] 7. SQLite DBMS (설치부터 기본 사용방법) (0) | 2020.05.09 |
---|---|
[iOS - swift] 6. SQL 4가지 쿼리문 형태 (0) | 2020.05.09 |
[iOS - swift] 4. Login정보 저장하기 (로컬) UserDefaults, Property List (0) | 2020.05.05 |
[iOS - swift] 3. UserDefaults (0) | 2020.05.05 |
[iOS - swift] 2. 프로퍼티 리스트(Property List) (0) | 2020.05.05 |