Database
< 기본키(Primary Key), 외래키(Foreign Key) 란? >
- 슈퍼키
행을 구분할 수 있는 모든 키
예를 들어 학번을 알면 이름과 주소를 알 수 있고, 이름을 알면 주소를 알 수 있다고 가정할 때
슈퍼키는 학번, 이름
- 후보키
해을 구분할 수 있는 최소키
예를 들어 학번과 이름으로 주소를 알 수 있지만
학번만으로도 주소를 알 수 있음
여기서 후보키는 학번
- 기본키
후보키 중 하나
테이블의 모든 데이터를 식별하는 기준이 되는 컬럼
테이블 당 단 하나의 PK 가 존재
중복된 데이터 삽입 불가
NULL 데이터 불가
함수적 종속 관계
- 대체키
후보키 중 기본키가 되지 못한 키들
- 외래키
테이블 간의 관계를 의미하는 외부 식별자키
종속이 필요한 두 테이블 간 관계의 접점이 되는 컬럼을 외래키로 지정하여 두 테이블이 서로 참조할 수 있도록 관계를 맺어줌
B 테이블에서 유일한 값을 갖는 컬럼을 A 테이블의 외래키로 둠으로써, A 테이블과 B 테이블 간의 관계를 맺음
< 함수적 종속성이란? >
함수적 종속성(Functional Dependency)이란, 테이블 내의 어떤 컬럼값에 의해 다른 컬럼값을 곧바로 식별할 수 있는 속성
예를 들어 학번, 이름, 전공 세 컬럼으로 구성된 테이블에서
학번을 알면 이름, 전공을 곧바로 알 수 있음
하지만 이름을 안다고 해서 학번, 전공을 곧바로 알 수 없으며
전공을 안다고 해서 학번, 이름을 곧바로 알 수 없음
학번을 X, 이름 전공을 Y 라고 할 때 Y(이름, 전공)는 X(학번)에 함수적 종속이라고 함
X(학번)을 결정자, Y(이름, 전공)을 종속자라고 함
기호로 표현하면 X→Y
< Index 란? >
indexing 의 기준이 되는 칼럼의 값과, 해당 레코드가 저장된 주소를 키-값 쌍으로 저장해두는 것
indexing 이 된 컬럼의 값은 항상 정렬되어 있어 검색(select 의 where) 시 빠른 실행 속도를 보여주지만,
레코드 삽입(insert into), 수정(update), 삭제(delete from) 등의 update 처리에 추가 작업이 들어가서 실행 속도가 느려지게 됨
index 가 저장하는 만큼의 데이터 공간이 줄어들게 됨
따라서 index 는 데이터 저장 성능(느린 update 실행 속도, 데이터 저장 공간)을 희생하는 대신 검색 속도를 높이는 기능
Primary Key 는 기본적으로 indexing 이 되어있음
성별처럼 도메인 범위가 적은 컬럼보단,
이름이나 주민등록번호처럼 도메인 범위가 높은 컬럼이 indexing 하기에 더 효율적임
왜냐하면 where 절로 필터링 할 수 있는 기준이 많기 때문
카디널리티란, 튜플(행)의 개수
update 함에 따라 늘어나거나 줄어듦
< DDL, DML, DCL >
DDL : Data Definition Language
테이블, 스키마 등을 정의, 변경, 제거하는 언어. create, drop, alter 등
DML : Data Manipulation Lanaguage
데이터 조작 언어. select, delete, insert into, update 등
DCL : Data Control Language
데이터 권한 제어 언어. 권한 부여, 권한 취소
< 프로시저 >
DB 서버에 원하는 쿼리문을 만들어서 실행하는 일종의 함수
다음 명령어로 생성
delimiter //
create procedure 프로시저명 (IN/OUT 변수 변수타입..)
begin
쿼리문
end//
다음 명령어로 호출
call 프로시저명(파라미터)
다음 명령어로 삭제
drop procedure 프로시저명
< 트리거 >
DB 에 특정 이벤트(데이터 삽입, 삭제, 수정 등) 발생시
이벤트 발생 후 자동으로 다음 액션이 수행되도록 만든 코드
A 테이블에 이벤트가 발생하면 자동으로 B 테이블에 특정 액션을 수행하라 같은.
트리거를 둠으로써 DB 의 무결성과 유일성을 보장하려고 함
한 테이블 데이터 업데이트 할 때, 트리거를 설정해두면 관련된 테이블의 해당 데이터를 자동으로 변경
제약조건이 복잡하게 얽혀있는 경우 효과적임
< Index >
primary key 에 자동으로 인덱스가 붙음
unique key 속성이 있는 컬럼에도 인덱스가 자동으로 붙음
삽입과 삭제시 비용이 많이 들지만 검색이 아주 효율적임
< Index 자료구조 >
DBMS 에서 Index 를 구현 할 때 두 가지 자료구조 중 하나를 사용
- B tree
인덱스에서 균형이 잡힌 Balance Tree 를 사용
값을 찾을 때 항상 root 부터 탐색한다는 단점이 있음
- B+tree
변형되지 않은 그대로의 컬럼 값(혹은 뒷 부분을 자른 컬럼 값의 앞 남은 부분) 을 key 로 두어 indexing 함
B+tree는 모든 key, data 가 리프노드에 모여있으며, 선형 linked list 를 이루고 있음
B tree 가 갖는 단점이 없음 왜냐면 한 번 찾은 후 리프노드에서 다른 리프노드로 이동이 가능하기 때문(효율적인 순차검색)
tree 구조로 indexing 을 빠르게 할 수 있고( O(logn) 만큼 시간이 듦 ),
부등호(<, >...) 연산이 포함된 검색문(선형 탐색) 에서 linked list 를 사용하기 때문에 시간 복잡도가 줄어듦
- Hash Table
컬럼 값의 Hash 값을 key 로 두어 indexing 함
검색하는데 O(1) 시간이 듦
Hash 충돌이 일어날 수 있음
컬럼 값 자체가 Hash 로 변형되어 indexing 되기 때문에, wild card 를 사용하는 like 같은 검색문에서는 사용할 수 없음
부등호(<, >...) 연산이 포함된 검색문에서는 사용할 수 없음. 오로지 등호(=) 연산이 있는 검색문에서만 사용 가능
< 정규화란? >
관계형 데이터베이스에서 테이블 간 데이터 중복을 최소화하기 위해, 테이블을 구조화하는 작업
다양한 정규형이 존재하며, 제 1, 제 2, 제 3 정규형까지 진행해도 괜찮음
정규화를 진행하면, 중복성을 없애 정보 검색을 쉽게 하고
삽입 이상, 삭제 이상, 수정 이상을 없앨 수 있고
데이터베이스 확장 시, 테이블 구조 변경을 최소화 할 수 있음
여기서 말하는 '이상(Anomaly)' 이란, 잘못 설계된 테이블 위에 데이터를 삽입,삭제,수정 할 때 논리적으로 오류(무결성이 깨짐)가 생기는 것을 말 함
- 삽입 이상 : 데이터를 삽입 시, 불필요한 데이터까지 넣어야 하는 이상
(강의 코드 및 강의명은 꼭 들어가야 하는 데이터라는 전제)
위의 테이블에 강의를 듣지 않는 학생의 정보를 넣으려고 할 때,
강의 코드 및 강의명 컬럼에 null 혹은 '없음' 등의 불필요한 데이터를 넣어야 함
- 삭제 이상 : 데이터 삭제 시, 삭제하려는 데이터 외 다른 데이터까지 같이 삭제되는 이상
위의 테이블에서 이태경 학생의 강의를 수강 취소하려고, 강의코드 AAC2 가 포함된 row 를 삭제하면
AAC2를 수강하는 이태경 학생의 학번, 이름, 나이, 성별 등의 다른 데이터까지 같이 삭제됨
- 수정 이상 : 중복이 존재하는 데이터 수정 시, 중복 데이터 중 일부만 수정되는 이상
서준호 학생의 전화번호가 바뀌어서 테이블을 수정한다고 하자
위의 테이블에서 3번째 row (서준호)의 전화번호를 수정하고 마무리 지으면,
(중복 데이터인) 4번째 row 의 전화번호가 수정되지 않았기 때문에 이상이 발생
정규화를 진행하면 테이블 간의 릴레이션이 많이 생기게 되어, 릴레이션 간의 연산(JOIN 연산)이 많아짐
이로 인해 질의에 대한 응답 시간이 느려질 수 있음
< 반정규화란? >
정규화의 반대 작업
정규화로 인해 질의 응답 시간이 느려지기 때문에, 응답 시간을 줄이기 위해 일부러 반정규화를 진행하기도 함
테이블과 테이블을 통합하거나,
테이블의 중복데이터를 허용하거나,
테이블을 row 나 column 단위로 잘라 두 테이블로 나누는 등의 작업
응답 시간을 줄어들겠지만, 정규화의 이점(Anomaly 를 없애는 것, 데이터 정합성을 높이는 것 등)은 어느 정도 포기하게 됨
< 트랜잭션(Transaction) 이란? >
참고 https://eyeballs.tistory.com/514
트랜잭션이란, 작업들을 하나로 묶은 단위
이렇게 묶인 트랜잭션 내의 작업들을 모두 완벽하게 처리하거나
또는 처리하지 못할 경우에는 원 상태로 복구해서
작업의 일부만 적용되지 않도록 만들어줌
작업이 완벽하게 적용되거나, 완벽하게 적용되지 않거나(원래 상태) 둘 중에 하나.
따라서 데이터의 정합성을 보장함
사용자의 입장에서는 작업의 논리적 단위로 이해를 할 수 있음
시스템의 입장에서는 데이터에 접근 또는 데이터를 변경하는 프로그램의 단위가 됨
트랜잭션은 ACID 라는 4 가지 특성을 만족해야 함
- A : 원자성(Atomicity)
트랜잭션은 완벽하게 수행되거나, 완벽하게 수행되지 않는 것을 보장해야 함
예) 1000원을 송금하는 트랜잭션에서, 완벽하게 1000원이 보내지거나, 1000원이 보내지지 않아야 함.
중간에 이슈가 생겨서 500원만 보내지면 안 됨
- C : 일관성(Consistency)
트랜잭션이 완료된 후에도, 트랜잭션이 일어나기 전과 동일하게 일관성 있는 데이터베이스 상태를 보장해야 함
항상 유효한 데이터만 저장하도록 하는 성질임
Data 저장 시 엄격한 규칙을 적용하여 DB가 깨지지 않도록 보장하는 성질
예) 1000원을 송금하는 트랜잭션 A가 수행된 이후에도 데이터베이스는 기존과 같은 상태를 보여야 함
트랜잭션 B 를 수행했더니 숫자가 들어가야 하는 컬럼에 문자가 들어가 있는 등의 문제가 생기면 안 됨 (type 제한)
혹은 primary key 가 없으면 안 됨 (primary is not null)
혹은 나이 column 에 들어가는 숫자는 3자리를 넘으면 안 됨 (길이 제한)
(일관성이라는 게 이해하기 어려운 개념인 듯. 실제로 일관성을 데이터베이스의 속성이 아닌 Application 의 속성임
즉, 데이터를 일관성있게 유지하는 것은 데이터베이스의 역할이 아님 [참고])
- I : 고립성(Isolation)
각각의 트랜잭션은 서로 간섭, 영향없이 독립적으로 수행되어야 함
예) 1000원을 송금하는 트랜잭션 A를 수행하는 동안, 다른 트랜잭션 B를 수행해도, A에는 영향이 없어야 함
B 가 수행됨으로써 A에서 보내는 금액 500원이 되어버리면 안 됨
- D : 지속성(Durability)
트랜잭션이 정상적으로 종료된 후의 작업 결과가 영구적으로 데이터베이스에 저장되어야 함
예) 1000원을 송금하는 트랜잭션이 마무리가 된 후, disk 에 결과를 확정적으로 저장해야 함
결과를 disk 에 쓰는 과정 중 갑자기 서버가 내려갔을 때, 서버 복구 후 disk 에 결과가 없으면 안 됨
(참고로, 위와 같은 경우에는 데이터베이스가 미리 써 둔 log 를 이용하여 복구 가능하다고 함)
트랜잭션을 사용하는 이유는
데이터 복구와 동시성 제어를 위함
동시성 제어란, 여러 트랜잭션이 동시에 수행될 경우 서로 간섭하여 일관성을 해치는 경우가 없도록 제어하는 것
트랜잭션 별로 연산을 순차적으로 수행하는 스케줄링을 통해 동시성 제어 가능
동시성 제어를 하지 않으면, A 트랜잭션이 업데이트 한 내용을 B 트랜잭션이 덮어씌워서 무효화 하는 등의 문제가 나타남
< 데이터베이스의 Lock 이란? >
Lock 이란, 데이터의 무결성을 보장하기 위한 방법임
트랜잭션이 작업을 하는 동안, 작업에 사용되는 자원(테이블 등)에 다른 트랜잭션이 쿼리를 날리지 못하도록 하는 방법
lock 은 COMMIT 이나 ROLLBACK 구문 이후에 풀리게 됨
두 가지 종류가 있음
- 공유 Lock(Shared Lock, Read Lock)
트랜잭션 A 가 Table 을 점유하는 동안 다른 트랜잭션 B는 Table 에 Select 는 가능하지만 Insert, Delete, Update 는 불가능함
- 베타적 Lock(Exclusive Lock, Write Lock)
트랜잭션 A 가 Table 을 점유하는 동안 다른 트랜잭션 B는 Table 에 Select, Insert, Delete, Update 가 불가능함
< 데이터베이스의 교착 상태 (Deadlock) 란? >
교착상태란, 두 개 이상의 트랜잭션이 특정 자원(테이블 또는 행)의 잠금(Lock)을 획득한 채
다른 트랜잭션이 소유하고 있는 잠금(Lock)을 요구하며 무한히 기다리는 상태를 말 함
트랜잭션 1이 Table 1을 업데이트하면서 Table 1의 lock 을 가져옴
트랜잭션 2가 Table 2를 업데이트하면서 Table 2의 lock 을 가져옴
트랜잭션 1은 Table 2를 업데이트하려고 했는데 트랜잭션 2에 의해 Table 2가 lock 이 걸려있어서 업데이트가 불가
트랜잭션 2도 Table 1을 업데이트하려고 했는데 트랜잭션 1에 의해 Table 1이 lock 이 걸려있어서 업데이트가 불가
두 트랜잭션은 서로 원하는 테이블의 lock 이 풀릴 때 까지 기다리게 됨
교착 상태를 발생시키는 4 가지 조건이 존재함
- 상호배재 : 트랜잭션이 자원을 (배타적으로) 점유하고, 다른 트랜잭션이 그 자원을 사용 못함
- 점유와 대기 : 트랜잭션이 자원을 점유하고 있는 동시에 다른 자원을 요구
- 비선점 : 트랜잭션에 할당된 자원은, 점유한 트랜잭션에 의해 해제 될 때 까지 다른 트랜잭션에 의해 해제될 수 없음
- 순환대기 : 트랜잭션 간 자원 요청이 하나의 원형 체인을 구성
교착 상태를 예방하는 방법은 다음과 같음
- 비선점 부정으로 예방 : 다른 트랜잭션에 의해 자원이 해제될 수 있음
- 순환 대기 부정으로 예방 : 트랜잭션 간 동일한 요청 순서를 부여
교착 상태 해결 방방은 다음과 같음
- Lock timeout : 점유 시간에 제한을 둠. 예를 들어 100초 동안만 점유할 수 있고, 100초 후에는 점유할 수 없도록 함
- Wait-Die : 나중에 생긴 트랜잭션이 먼저 생긴 트랜잭션이 점유한 자원 요청을 포기하도록 함
- Wound-Wait : 먼저 생긴 트랜잭션이 나중에 생긴 트랜잭션이 점유한 자원을 빼앗음(선점)
< Data Warehouse 모델링 용어 >
Fact 테이블(사실 테이블)이란?
- 중심테이블(major 테이블)
- 관련성이 높은 Measure들의 집합
- 'fact'라고 부르는 (주로) 숫자 값의 형태를 따르는 비즈니스 측정값을 가지고 있는 테이블
Dimension 테이블(차원 테이블)이란?
- 부속 테이블(minor 테이블)
- 각 Fact를 분석하는 하나의 관점
Fact 테이블이, 텍스트처럼 크기가 큰 Row를 갖게 되면, 많은 공간을 차지하게 되고 성능도 떨어짐
그렇기 때문에, 가능한 한 텍스트는 Dimension 테이블에서 관리하고
이를 효과적으로 연결할 수 있는 값을 Fact 테이블에 저장하는 것이 좋음
실제로 데이터 웨어하우스를 구축하고 나면 Fact 테이블이 전체 모델의 약 90%를 차지한다고 함
< Data Warehouse 모델링 설계 기법 : 스타 스키마 >
스타 스키마란?
- Fact 테이블과 Dimension 테이블로 데이터를 분리하여 설계한 모델임
- Fact 테이블(위 그림의 매출 테이블)을 중심으로
Dimension 테이블(위 그림의 기간, 매장, 제품, 영업직원 테이블) 이 (외래키로) 엮여있음
- Fact 테이블은 정규화되어있고, Dimension 테이블은 비정규화 되어있음
장점
- 사람이 직관적으로 이해하기 쉬움
- 계층구조 정의가 용이함
- 물리적인 조인수가 줄어들어 쿼리 성능 향상
단점
- dimension 테이블은 비정규화 되어있는 단일 테이블이기 때문에, 설명 및 속성이 중복 저장 될 가능성이 있음
스타 스키마에 대해 다음과 같은 쿼리를 작성할 수 있음 (위 그림 참고)
18년 1월 서울에서 어떤 노트북이 얼마나 팔렸는지 알아보는 쿼리
SELECT 제품 Dim.제품명 as 제품, Sum (매출 Fact.매출수량) as 매출량 FROM 매출 Fact, 제품 Dim, 매장 Dim, 기간 Dim WHERE 매출 Fact.제품# = 제품 Dim.제품# AND 매출 Fact.매장# = 매장 Dim.매장# AND 매출 Fact.기간# = 기간 Dim.기간# AND 매장 Dim.지역명 = '서울’ AND 기간 Dim.년 = 2018 AND 기간 Dim.월 = 1 AND 제품 Dim.제품군명 = '노트북' GROUP BY 제품 Dim.제품명 |
< Data Warehouse 모델링 설계 기법 : 눈송이 스키마 >
눈송이 스키마란?
- 스타 스키마의 모든 dimension 테이블을 정규화한 스키마
장점
- 정규화를 통해 dimension 테이블에 중복된 데이터를 제거하여, 아노말리를 제거하고 저장공간을 절약함
(Fact 테이블에 비해 dimension 테이블의 크기가 작기서 저장공간 절약 효과는 미미함)
단점
- 조인 등을 많이 사용해야 하므로, 검색 속도가 떨어짐
- 사람이 직관적으로 이해하기 쉽지 않음
눈송이 스키마에 대해 다음과 같은 쿼리를 작성할 수 있음 (위 그림과 상관 없음)
스타 스키마와 다른 점만 알아두자. 눈송이에서는 dimension 테이블과 dimension 테이블끼리도 inner join 을 맺음
SELECT pdim.Name Product_Name, Sum (sfact.sales_units) Quanity_Sold FROM Sales sfact INNER JOIN Product pdim ON sfact.product_id = pdim.product_id INNER JOIN Store sdim ON sfact.store_id = sdim.store_id INNER JOIN State stdim ON sdim.state_id = stdim.state_id INNER JOIN Date ddim ON sfact.date_id = ddim.date_id INNER JOIN Month mdim ON ddim.month_id = mdim.month_id WHERE stdim.state = 'Kerala' AND mdim.month = 1 AND ddim.year = 2018 AND pdim.Name in (‘Novels’, ‘DVDs’) GROUP BY pdim.Name |
참고
https://ko.myservername.com/pl-sql-package-oracle-pl-sql-package-tutorial-with-examples
http://www.jidum.com/jidums/view.do?jidumId=692
https://datalibrary.tistory.com/43
https://datalibrary.tistory.com/8
< NoSQL 이란? >
관계형 데이터 모델을 거부한(테이블 간 관계가 없는) 데이터베이스(No SQL 혹은 Not Only SQL)
스키마가 존재하지 않음
RDB 보다 대용량의 데이터 저장 가능
분산형 구조를 갖고 있어서 rdb는 하기 힘든 scale-out 도 가능
비정형, 반정형 데이터 저장 가능
데이터 중복이 발생 가능
Join 이 어려움
트랜잭션을 갖고 있지 않음
< CAP 이론이란? >
네트워크로 연결된 분산 데이터베이스의 종류에 따른 특성을 설명하는 이론.
각각의 데이터베이스는 종류마다 C, A, P 세 가지 특성 중 두 가지를 갖을 수 있음
세 가지 특성을 모두 갖는 데이터베이스 종류는 존재할 수 없음
하지만 CAP 이론은 허점이 있는 이론임이 밝혀졌고, 그에 따라 PACELC라는 이론이 새롭게 등장하게 됨
- C : 일관성(Consistency)
다중 클라이언트에서 (같은 시간에 조회하는) 데이터는 항상 동일한 데이터임을 보증함
즉, 모든 클라이언트는 동시간에 동일한 데이터를 봄
일관성을 만족시키지 않는 데이터베이스에서는 사용자마다 서로 다른 데이터를 볼 가능성이 있음
- A : 가용성(Availability)
모든 클라이언트의 읽기와 쓰기 요청에 대하여 항상 응답이 가능해야 함을 보증함
즉, 클라이언트들은 언제나 데이터베이스를 읽고 쓸 수 있음(가용)
내고장성이라고도 하며, 내고장성을 갖는 데이터베이스는 클러스터 내에서 몇 개의 노드가 망가지더라도 정상적인 서비스가 가능
이러한 가용성을 보장하기 위해 데이터 복제(Replication)을 사용되기도 함
동일한 데이터를 다중 노드에 중복 저장해두면, 그 중 몇 대의 노드가 고장나도 데이터가 유실되지 않아 내고장성을 갖음
- P : 분할 내구성(Partition tolerance)
네트워크 이슈로 인해 클러스터 노드 간 연결이 끊겼어도
각 노드들로 오는 사용자 쿼리는 잘 수행됨을 보증함
예를 들어, A node와 B node 가 네트워크로 연결된 상황에서 갑자기 네트워크가 끊김
사용자가 A node 에 쿼리를 날려도 A node 는 쿼리 처리를 잘 수행함
사용자가 B node 에 쿼리를 날려도 B node 는 쿼리 처리를 잘 수행함
가용성은 노드에 장애가 났을 때도 사용자 쿼리를 잘 수행해야 함을 의미하고
분할 내구성은 노드 간 네트워크가 끊겼을 때도 사용자 쿼리를 잘 수행해야 함을 의미함
< 저장 방식에 따른 NoSQL 분류 >
NoSQL 은 데이터를 어떤 형식으로 저장하느냐에 따라 분류가 가능함
- Key-Value Database
하나의 키에 하나의 데이터를 저장하고 조회할 수 있는 단일 키-값 구조
저장되는 데이터는 어떠한 자료구조라도 들어갈 수 있음. 심지어 이미지나 비디오도 가능
저장 구조가 단순하여 고속 읽기, 쓰기에 최적화 되었지만, 복잡한 조회 연산을 지원하지 않음
하나의 서비스 요청에 다수의 데이터 조회 및 수정 연산이 발생하면 트랜잭션 처리가 불가능하여 데이터 정합성을 보장할 수 없음
대표적으로 Redis 가 있음
- Column Family Database
키-컬럼 패밀리의 쌍으로 데이터를 저장
하나의 키에 여러 column-value 가 들어가는 구조는 마치 RDB 와 비슷함
키는 Primary Key, column 은 컬럼, value 는 컬럼의 값
예를 들어 키는 학번, 내부의 column 은 이름, 전공이고 value 는 '눈가락', '컴퓨터공학' 등
위의 그림과 같이 하나의 키 내에 있는 column-value 조합들을 column family 라고 함
컬럼 패밀리마다 컬럼의 구성을 다르게 할 수 있음
대표적으로 HBase 와 Cssandra 가 있음
- Document Database
하나의 키에 하나의 구조화된 문서(JSON, XML,YAML 등)를 저장하고 조회하는 구조
키는 문서에 대한 ID 로 표현됨
저장된 문서를 컬렉션으로 관리
문서 저장과 동시에 문서 ID (key)에 대한 인덱스를 생성하여 조회가 빠름 (O(1) 시간이 걸림)
내부적으로 b-tree 가 사용되는데, b-tree는 크기가 커질수록 데이터 삽입, 삭제 성능이 떨어지므로
읽기 70% 쓰기 30% 정도의 작업에서 최적의 성능을 보임
대표적으로 MongoDB 가 있음
- Graph Database
데이터를 노드로(그림에서 파란, 녹색 원) 표현하며
노드(데이터) 사이의 관계를 엣지(그림에서 화살표)로 표현
일반적으로 RDBMS 보다 성능이 좋고 유연하며 유지보수에 용이한 것이 특징.
Social networks, Network diagrams 등에 사용할 수 있다.
데이터베이스 참고
김정준 교수님 데이터베이스 수업 http://www.kocw.or.kr/home/cview.do?cid=a45bbf7abe190eda
https://tecoble.techcourse.co.kr/post/2021-09-18-db-index/
https://kosaf04pyh.tistory.com/294
https://mangkyu.tistory.com/110
https://chrisjune-13837.medium.com/db-transaction-%EA%B3%BC-acid%EB%9E%80-45a785403f9e
https://itpenote.tistory.com/624
https://www.w3schools.com/sql/sql_foreignkey.asp
https://dodo000.tistory.com/20
https://sabarada.tistory.com/91
https://osy0907.tistory.com/95
https://itholic.github.io/database-cardinality/
https://happycloud-lee.tistory.com/156
https://code-lab1.tistory.com/53
'Coding Interview' 카테고리의 다른 글
| [IT] CS 면접 대비 JAVA 질문 모음 (0) | 2021.12.31 |
|---|---|
| [IT] CS 면접 대비 Network 질문 모음 (0) | 2021.12.30 |
| 코딩 검사할 때 엣지케이스 찾기 리스트 (0) | 2020.06.14 |
| [2020 KAKAO BLIND RECRUITMENT] 자물쇠와 열쇠 (0) | 2020.06.10 |
| [SW Expert Academy] 2112. [모의 SW 역량테스트] 보호 필름 (0) | 2020.06.05 |