데이터베이스는 저장 주소가 아니라 데이터의 내용(값)으로 참조하므로, 주소나 위치로 참조한다는 설명이 옳지 않다.
데이터베이스의 특징은 실시간 접근성, 계속적 변화, 동시 공용, 내용에 의한 참조로 정리된다. 사용자는 물리적 위치를 몰라도 조건(값)만으로 원하는 데이터를 찾는다.
- 실시간 처리 가능: 질의에 즉시 응답하는 실시간 접근성에 해당한다.
- 여러 사용자의 동시 이용: 동시 공용 특징이다.
- 삽입·삭제·갱신으로 현재의 정확한 데이터 유지: 계속적 변화(동적 특성)에 해당한다.
접근 권한 부여는 DML이 아니라 DCL(GRANT)로 수행하므로, DML로 권한을 부여한다는 설명이 옳지 않다.
SQL은 정의어(DDL), 조작어(DML: SELECT·INSERT·UPDATE·DELETE), 제어어(DCL: GRANT·REVOKE 등)로 나뉘며, 권한 관리는 DCL의 역할이다.
- 데이터 사전 등 시스템 데이터베이스 관리: 메타데이터 관리는 DBA의 업무다.
- 물리적 저장을 위한 레코드 구조 설계: 저장 구조와 접근 경로를 정하는 물리적 설계도 DBA가 맡는다.
- 요구사항 분석으로 구성요소 결정: 스키마를 정의하는 것은 DBA의 핵심 업무다.
릴레이션은 투플의 집합이므로 투플의 순서도 의미가 없다. 투플 순서가 중요하다는 설명이 옳지 않다.
릴레이션은 투플의 유일성, 투플과 속성의 무순서성, 속성값의 원자성을 특성으로 가진다.
- 제2정규형에서 이행적 종속 제거 시 제3정규형: 제3정규형의 정의와 같다.
- 속성은 도메인에서 값을 가지며 속성마다 도메인이 다를 수 있음: 옳은 설명이다.
- 기본키로 투플을 고유하게 식별하고 유일성 보장: 기본키의 성질이다.
데이터가 저장장치에 저장되는 방법을 정의하는 것은 내부 스키마이므로, 이를 외부 스키마의 설명으로 든 것이 옳지 않다.
3단계 스키마에서 외부 스키마는 사용자 관점의 논리 구조, 개념 스키마는 조직 전체의 논리 구조, 내부 스키마는 물리적 저장 구조를 정의한다.
- 서브 스키마라고도 함: 외부 스키마의 다른 이름이다.
- 하나의 데이터베이스에 여러 개 존재: 사용자·응용마다 서로 다른 외부 스키마를 둘 수 있다.
- 개별 사용자 시각의 논리적 구조: 외부 스키마의 정의 그대로다.
○ 유일성을 갖는 속성의 최소성(minimality)은 만족시키지 못함
유일성은 만족하지만 최소성은 만족하지 않는 키는 슈퍼키다.
후보키는 유일성과 최소성을 모두 만족하는 속성 집합이고, 슈퍼키는 유일성만 갖추면 되므로 불필요한 속성이 덧붙어 있어도 된다.
- 외래키: 다른 릴레이션의 기본키를 참조하는 속성으로, 유일성을 요구하지 않는다.
- 기본키: 후보키 중 선택된 하나이므로 최소성을 만족한다.
- 후보키: 유일성과 최소성을 모두 만족해야 한다.
| 릴레이션 | 차수 | 카디널리티 |
|---|---|---|
| R | 5 | 5 |
| S | 10 | 10 |
자연 조인은 공통 속성을 한 번만 남기므로 결과 차수가 12라는 설명이 옳다.
공통 속성 3개가 중복 제거되어 개 속성이 남는다.
- S ÷ R의 차수 5: 디비전은 R의 모든 속성이 S에 포함되어야 정의되는데, R의 속성 중 2개는 S에 없으므로 연산이 성립하지 않는다.
- S − R의 카디널리티 5: 차집합은 두 릴레이션이 합병 가능(차수·도메인 일치)해야 하는데 차수가 5와 10으로 달라 수행할 수 없다.
- R × S의 차수 12: 카티션 프로덕트는 속성을 모두 합쳐 차수가 이고, 카디널리티만 이 맞다.
| A | B | C | D |
|---|---|---|---|
| 1 | 3 | 7 | 1 |
| 2 | 5 | 7 | 2 |
| 3 | 3 | 7 | 1 |
| 4 | 3 | 4 | 3 |
| 5 | 9 | 7 | 2 |
ㄷ. C → D ㄹ. D → C
투플 기준으로 성립하는 함수 종속은 A → B와 D → C이다.
X → Y는 X 값이 같은 투플끼리 Y 값도 같아야 성립한다. A는 모든 투플에서 값이 달라 A → B가 성립하고, D 값 1·2·3에는 C 값이 각각 7·7·4로 하나씩만 대응한다.
- B → C: B가 3인 투플들의 C가 7과 4로 달라 성립하지 않는다.
- C → D: C가 7인 투플들의 D가 1과 2로 달라 성립하지 않는다.
모든 키를 삽입하면 마지막 분할이 루트까지 전파되어 루트에는 9 하나만 남는다.
노드당 최대 2개이므로 키가 3개가 되면 가운데 키를 부모로 올린다.
9, 4 → [4, 9] / 1 → [1, 4, 9] 분할, 루트 [4]
6 → [6, 9] / 2 → [1, 2] / 11 → [6, 9, 11] 분할, 9 상승 → 루트 [4, 9]
10 → [10, 11] / 5 → [5, 6]
12 → [10, 11, 12] 분할, 11 상승 → 루트 [4, 9, 11] 넘침 → 9가 새 루트
최종 트리는 루트 [9], 둘째 레벨 [4]·[11], 리프 [1, 2]·[5, 6]·[10]·[12]이다.
- 4: 처음에는 루트였지만 루트 분할 후 왼쪽 자식으로 내려간다.
- 6: 리프 [5, 6]에 남는다.
- 11: 루트로 올라갔다가 루트 분할 때 오른쪽 자식에 남는다.
| 시간 | T1 | T2 |
|---|---|---|
| ↓ | read(X) | |
| X = X + M | ||
| write(X) | ||
| read(X) | ||
| rollback | ||
| X = X - N | ||
| write(X) --- (가) |
가 철회 전의 값 120을 읽는 오손 읽기가 일어나므로 (가)에서 X의 최종 값은 70이다.
: X = 100 + 20 = 120 기록
: read(X) → 120
rollback → X를 100으로 복원
: X = 120 − 50 = 70 → write(X)로 70 기록
- 50: 복원된 100에서 N을 뺀 값으로, 가 철회 이전에 이미 120을 읽었다는 점을 놓친 것이다.
- 100: 철회 직후의 값이지만 이후 의 write가 덮어쓴다.
- 120: 이 쓴 중간값으로, 의 감산이 반영되지 않았다.
| R | ||
|---|---|---|
| A | B | C |
| 1 | 2 | 3 |
| 6 | 3 | 8 |
| 9 | 4 | 8 |
| S | ||
|---|---|---|
| B | D | E |
| 2 | 3 | 4 |
| 2 | 4 | 5 |
| 7 | 8 | 10 |
R ⋉ S는 S와 조인되는 R의 투플만 R의 속성으로 남기므로 결과는 투플 1개, 속성 3개다.
공통 속성 B에서 S의 값은 2와 7이다. R의 B 값 2·3·4 중 2만 일치하므로 (1, 2, 3)만 남고, 결과 스키마는 R의 속성 A, B, C 그대로다.
- 투플 2개: B가 3, 4인 R의 투플은 S에 짝이 없어 제외된다.
- 속성 5개: 자연 조인의 차수에 해당하며, 세미조인은 S의 속성 D, E를 붙이지 않는다.

제조업체(제조업체명, 전화번호)
회원(회원아이디, 이름, 등급)
주문(회원아이디, 상품번호, 주문번호, 주문수량, 주문일자)
제조업체(제조업체명, 전화번호)
회원(회원아이디, 이름, 등급)
주문(주문번호, 주문수량, 주문일자)
제조업체(제조업체명, 전화번호, 상품번호, 공급일자, 공급량)
회원(회원아이디, 이름, 등급)
주문(주문번호, 주문수량, 주문일자)
제조업체(제조업체명, 전화번호, 상품번호, 공급일자, 공급량)
회원(회원아이디, 이름, 등급)
주문(회원아이디, 상품번호, 주문번호, 주문수량, 주문일자)
N:1 관계인 공급은 N쪽 상품 릴레이션에 외래키와 관계 속성을 흡수하고, M:N 관계인 주문은 양쪽 기본키를 복합 기본키로 하는 별도 릴레이션으로 만든 스키마가 바른 변환이다.
공급은 상품(n)과 제조업체(1) 사이의 N:1 관계이므로 상품 릴레이션에 제조업체명을 외래키로 두고, 관계 속성인 공급일자·공급량도 함께 상품 쪽에 넣는다. 주문은 상품(m)과 회원(k) 사이의 M:N 관계이므로 회원아이디와 상품번호를 묶은 복합키를 기본키로 하고 주문번호·주문수량·주문일자를 속성으로 갖는 주문 릴레이션을 따로 둔다.
- 주문 릴레이션을 주문번호 하나만 기본키로 두고 회원아이디·상품번호를 빼는 변환은 M:N 관계의 양쪽 개체를 참조할 수 없어 관계 자체가 사라진다.
- 상품번호와 공급일자·공급량을 제조업체 릴레이션에 넣는 변환은 1쪽에 N쪽 키를 둔 것이라, 한 제조업체가 여러 상품을 공급하면 하나의 튜플에 담을 수 없다.
- 제조업체 쪽에 공급 정보를 두고 주문만 복합키로 만든 변환도 공급 관계의 방향이 뒤바뀌어 같은 이유로 성립하지 않는다.
원자성은 트랜잭션 연산이 모두 반영되거나 전혀 반영되지 않아야 함을 뜻하므로, 개별 반영된다는 설명이 옳지 않다.
일부 연산만 수행된 채 중단되면 회복 과정에서 철회(undo)하여 부분 반영을 남기지 않는다.
- 지속성: 완료된 트랜잭션의 결과를 영구적으로 보존한다는 설명이 옳다.
- 격리성: 수행 중인 트랜잭션에 다른 트랜잭션이 끼어들지 못하게 한다는 설명이 옳다.
- 일관성: 수행 전후 데이터베이스가 일관된 상태를 유지한다는 설명이 옳다.
CREATE TABLE 학과 (
학과명 VARCHAR(20), 전화번호 VARCHAR(20),
PRIMARY KEY(학과명)
);
CREATE TABLE 학생 (
학번 VARCHAR(20), 이름 VARCHAR(20),
학과 VARCHAR(20), PRIMARY KEY(학번),
FOREIGN KEY(학과) REFERENCES 학과(학과명)
);
UPDATE 학생 SET 학과 = ‘AI소프트웨어학과’ WHERE 학과
=‘소프트웨어학과’; --- (가)
외래키 학과는 학과 테이블의 학과명을 참조하므로, ‘AI소프트웨어학과’가 학과 테이블에 없으면 (가)는 참조 무결성 제약조건을 위반한다.
외래키 값은 NULL이거나 참조 테이블의 기본키 값 중 하나여야 한다. 따라서 바꿀 값이 학과 테이블에 먼저 존재해야 갱신이 허용된다.
- 개체 무결성 위반: 개체 무결성은 기본키(학번)의 NULL·중복 금지인데, (가)는 기본키를 바꾸지 않는다.
- 학생 테이블에 같은 학과 투플이 이미 있으면 실행 불가: 학과 속성은 기본키도 UNIQUE도 아니므로 같은 값이 여러 투플에 있어도 된다.
- 모든 투플의 학과 변경: WHERE 조건에 따라 학과가 ‘소프트웨어학과’인 투플만 변경된다.
| 시간 | T1 | T2 | T3 |
|---|---|---|---|
| ↓ | read(y) | ||
| read(z) | |||
| read(x) | |||
| write(x) | |||
| write(y) | |||
| write(z) | |||
| read(z) | |||
| read(x) | |||
| read(y) | |||
| write(y) |
충돌 연산의 선후 관계가 모두 한 방향이어서 이 스케줄은 직렬 스케줄과 충돌 동치다.
충돌 쌍을 찾으면 다음과 같다.
y: 의 read(y)·write(y)가 의 read(y)·write(y)보다 먼저 →
z: 의 write(z) 뒤에 의 read(z) →
x: 의 write(x) 뒤에 의 read(x) →
선행 그래프에 사이클이 없고 위상 정렬 결과는 하나뿐이다.
- : x에 대한 충돌로 가 보다 앞서야 한다.
- : y에 대한 충돌로 이 보다 앞서야 한다.
- 동치인 직렬 스케줄 없음: 사이클이 없으므로 충돌 직렬 가능하다.
| 사원 | ||||
|---|---|---|---|---|
| 사번 | 이름 | 부서번호 | 급여 | 직속상사 |
| 1 | Kim | 10 | 500 | NULL |
| 2 | Kwon | 20 | 500 | 3 |
| 3 | Park | 20 | 700 | NULL |
| 4 | Choi | 30 | 600 | 1 |
| 5 | Cho | 10 | 300 | 3 |
| 6 | Lee | 20 | 550 | 4 |
| 7 | Yoon | 30 | 400 | 3 |
| 8 | Chae | 20 | 650 | 1 |
| 9 | Nam | 10 | 430 | 4 |
| 10 | Ha | 30 | 200 | NULL |
| 부서 | ||
|---|---|---|
| 부서번호 | 부서이름 | 사무실위치 |
| 10 | 인사과 | 101호 |
| 20 | 개발팀 | 102호 |
| 30 | 총무과 | 103호 |
SELECT 이름
FROM 사원
WHERE 이름 LIKE ‘_a%’ AND 급여 > 500;
SELECT E.이름
FROM 사원 AS E INNER JOIN 부서 AS D ON E.부서번호 = D.부서번호
WHERE D.사무실위치 = ‘102호’ AND E.직속상사 is NULL;
SELECT 이름
FROM 사원
WHERE 이름 NOT IN (SELECT 이름 FROM 사원
WHERE 급여 < ANY (SELECT 급여 FROM 사원));
SELECT 이름
FROM 사원
WHERE 부서번호 IN (SELECT 부서번호 FROM 사원
GROUP BY 부서번호
HAVING COUNT(*) > 3);
나머지 세 질의는 결과가 Park 한 명이지만, 인원이 3명을 넘는 부서의 사원을 찾는 질의는 Kwon, Park, Lee, Chae 4명을 반환하여 결과가 다르다.
부서별 인원은 부서번호 10이 3명, 20이 4명, 30이 3명이므로 COUNT(*) > 3을 만족하는 부서는 20뿐이고, 그 소속 사원 전원이 결과가 된다.
- LIKE ‘_a%’ AND 급여 > 500: 두 번째 글자가 a인 사원은 Park·Nam·Ha이고, 급여가 500을 넘는 사원은 Park뿐이다.
- 102호이면서 직속상사가 NULL: 102호는 개발팀(부서번호 20)이며 그중 직속상사가 NULL인 사원은 Park이다.
- NOT IN과 < ANY: 급여 < ANY(전체 급여)는 최고 급여 700보다 적은 사원 전원이므로, 이를 제외하면 최고 급여자 Park만 남는다.
READ COMMITTED는 커밋된 데이터만 읽게 하므로 오손 읽기(dirty read)를 해결한다.
오손 읽기는 철회될 수 있는 미완료 트랜잭션의 갱신값을 읽는 문제다. 다른 트랜잭션이 읽은 뒤 커밋한 갱신·삽입으로 생기는 문제는 더 높은 격리 수준이 필요하다.
- 유령 읽기: 같은 조건으로 다시 검색할 때 새로 삽입된 투플이 나타나는 문제로, SERIALIZABLE 수준에서 해결된다.
- 직렬 읽기: 격리 수준이 다루는 동시 처리 문제가 아니다.
- 반복 불가능 읽기: 같은 데이터를 다시 읽을 때 그 사이 커밋된 갱신으로 값이 달라지는 문제로, REPEATABLE READ 이상이 필요하다.
| 판매자ID | 상품 | 제조사 |
|---|---|---|
| 0001 | 컴퓨터 | A |
| 0001 | 모니터 | B |
| 0002 | 컴퓨터 | A |
| 0002 | 모니터 | C |
| 0003 | 모니터 | C |
| 0003 | 컴퓨터 | D |
ㄴ. 이 테이블은 제3정규형의 조건을 만족하지 않는다.
ㄷ. 제조사 E가 모니터를 생산한다는 정보를 판매자ID 없이 투플로 추가하더라도 삽입 이상이 발생하지 않는다.
ㄹ. 판매자ID가 0001인 판매자가 모니터를 더 이상 판매하지 않아 해당 투플을 삭제한다면 삭제 이상이 발생할 수 있다.
ㅁ. 제조사 B가 생산하는 상품이 모니터에서 노트북으로 변경된다면 갱신 이상이 발생할 수 있다.
옳은 것은 ㄱ, ㄹ이다.
투플을 보면 기본키에 의한 종속 외에 제조사 → 상품(A·D는 컴퓨터, B·C는 모니터)이 성립한다. 기본키의 일부만으로는 제조사가 정해지지 않아 부분 종속이 없고, 종속되는 상품이 주요 속성이라 제3정규형까지 만족하지만 결정자 제조사가 후보키가 아니어서 BCNF는 위반한다.
- ㄱ(옳음): 판매자ID나 상품 하나만으로는 제조사가 정해지지 않으므로 부분 함수 종속이 없다.
- ㄴ(틀림): 제조사 → 상품에서 종속되는 상품이 주요 속성이므로 제3정규형 조건에 어긋나지 않는다.
- ㄷ(틀림): 판매자ID 없이 넣으면 기본키 일부가 NULL이 되어 삽입할 수 없으므로 삽입 이상이 발생한다.
- ㄹ(옳음): 제조사 B의 정보는 이 투플에만 있어, 삭제하면 B가 모니터를 생산한다는 사실까지 사라진다.
- ㅁ(틀림): B가 나오는 투플이 하나뿐이라 한 곳만 고치면 되므로 불일치가 생기지 않는다.
ㄷ. 제3정규형 ㄹ. 보이스/코드 정규형
후보키는 (B, D)와 (C, D)이고, 모든 속성이 주요 속성이어서 R은 제3정규형까지 만족한다.
(B, D)의 폐포: D → A로 A를 얻고, (A, B) → C, (A, B) → D로 전체가 된다.
(C, D)의 폐포: C → B, D → A로 A, B를 얻어 전체가 된다.
B, C, D 각각의 폐포는 전체가 아니므로 두 키 모두 최소성을 만족한다.
A·B·C·D가 모두 어떤 후보키에 속하므로 제3정규형은 성립하지만, C → B의 결정자 C가 슈퍼키가 아니므로 BCNF는 위반한다.
- (B, C): C → B는 B만 다시 얻을 뿐 A, D를 결정하지 못해 후보키가 아니다.
- 보이스/코드 정규형 포함: C → B, D → A의 결정자가 슈퍼키가 아니므로 BCNF가 아니다.
| 학생 | ||
|---|---|---|
| 학번 | 이름 | 과목번호 |
| 1111 | 을지문덕 | 200 |
| 2222 | 신사임당 | 100 |
| 3333 | 이율곡 | 300 |
| 4444 | 유관순 | 400 |
| 5555 | 김만덕 | 400 |
| 과목 | |||
|---|---|---|---|
| 과목번호 | 과목명 | 담당교수 | 개설학과 |
| 100 | 인공지능개론 | 안창호 | AI소프트웨어학과 |
| 200 | 빅데이터분석 | 김구 | 컴퓨터공학과 |
| 300 | 머신러닝 | 윤봉길 | AI소프트웨어학과 |
| 400 | 생성형AI | 김좌진 | AI소프트웨어학과 |
기본키에 NULL을 넣는 것은 개체 무결성 위반이므로, 과목번호가 NULL인 과목 삽입을 참조 무결성 위반이라 한 설명이 옳지 않다.
참조 무결성은 외래키 값이 참조 테이블의 기본키 값 중 하나(또는 NULL)여야 한다는 제약이고, 기본키의 NULL 금지는 개체 무결성이다.
- 과목 400 삭제: 유관순·김만덕이 참조하고 있으므로 참조 무결성 위반이다.
- 학번 3333의 과목번호를 500으로 변경: 과목 테이블에 500이 없으므로 참조 무결성 위반이다.
- 학번 5555로 학생 삽입: 김만덕의 학번과 중복되어 기본키 제약 위반이다.
RAID 6은 데이터와 이중 패리티를 여러 디스크에 분산 저장하므로, 패리티 전용 디스크를 분리한다는 설명이 옳지 않다.
패리티 전용 디스크를 두는 방식은 RAID 3·4이고, RAID 5·6은 패리티를 분산해 쓰기 병목을 줄인다. RAID 6은 서로 다른 패리티 2개로 디스크 2개의 동시 장애까지 견딘다.
- RAID 0: 데이터를 여러 디스크에 나누어 쓰는 스트라이핑이다.
- RAID 1: 모든 데이터를 다른 디스크에 복제하는 미러링이다.
- RAID 5: 데이터와 패리티를 모든 디스크에 분산 저장한다.
<T1, A, 30, 60>
<T2, start>
<T1, commit>
<T3, start>
<T4, start>
<checkpoint, {T2, T3, T4}>
<T3, C, 15, 45>
<T3, commit>
<T5, start>
<T2, B, 10, 50>
<T4, A, 60, 90>
<T4, abort>
<T5, D, 20, 40>
-- 시스템 장애 발생 --
는 체크포인트 이후 커밋했으므로 undo가 아니라 redo를 수행해 C에 새 값 45를 저장해야 한다.
즉시 갱신 회복에서는 체크포인트 이전에 커밋한 트랜잭션은 무시하고, 이후 커밋한 트랜잭션은 redo(새 값), 커밋하지 못한 트랜잭션은 undo(이전 값)를 수행한다.
- : 체크포인트 이전에 커밋되어 이미 반영되었으므로 복구가 필요 없다.
- : 커밋 기록이 없으므로 undo하여 B를 이전 값 10으로 되돌린다.
- : 커밋 기록이 없으므로 undo하여 D를 이전 값 20으로 되돌린다.
DBA> GRANT SELECT ON 고객 TO Kim WITH
GRANT OPTION;
DBA> GRANT SELECT ON 고객 TO Lee WITH
GRANT OPTION;
Kim> GRANT SELECT ON 고객 TO Park WITH
GRANT OPTION;
Lee> GRANT SELECT ON 고객 TO Choi WITH
GRANT OPTION;
DBA> REVOKE SELECT ON 고객 FROM Kim
CASCADE;
DBA> REVOKE SELECT ON 고객 FROM Lee
RESTRICT;
Lee에 대한 RESTRICT 회수는 Lee가 이미 Choi에게 권한을 넘겼기 때문에 거부되므로, Lee는 여전히 SELECT 권한을 가진다.
CASCADE는 연쇄적으로 넘겨준 권한까지 함께 회수하고, RESTRICT는 넘겨준 권한이 있으면 회수 자체를 거부한다. 따라서 Kim과 Park은 권한을 잃고, Lee와 Choi는 권한을 유지한다.
- Kim의 검색 권한 보유: CASCADE로 회수되어 권한이 없다.
- Park이 Cho에게 부여 가능: Kim의 권한이 연쇄 회수되면서 Park의 권한도 사라졌다.
- Choi가 Hong에게 부여 불가: Lee의 회수가 거부되어 Choi는 GRANT OPTION이 포함된 권한을 그대로 가지므로 부여할 수 있다.
뷰를 통한 원본 테이블의 데이터 조작이 전면 불가능하다는 설명이 옳지 않다.
뷰에 대한 조작은 원본 테이블에 대한 조작으로 변환되므로, 단일 테이블에서 기본키를 포함하고 집계·DISTINCT·GROUP BY가 없는 갱신 가능한 뷰는 INSERT·UPDATE·DELETE가 허용된다.
- 사용자 요구에 맞게 가공: 필요한 속성·투플만 골라 논리적 테이블을 만들 수 있다.
- 사용자별 접근 제한: 뷰에 보이는 데이터만 허용해 보안을 높인다.
- 자주 쓰는 질의 재사용: 복잡한 질의를 뷰로 정의해 두면 간단히 다시 쓸 수 있다.
CAP 이론의 C는 병행성이 아니라 일관성(Consistency)이므로 옳지 않다.
CAP 이론은 분산 시스템이 일관성·가용성·분할 감내성 세 가지를 동시에 모두 보장할 수 없다는 이론이다.
- MongoDB: 대표적인 문서 기반 NoSQL 시스템이다.
- 비정형 빅데이터 처리: 스키마가 유연하고 수평 확장이 쉬워 대용량 비정형 데이터에 적합하다.
- 키-값·문서·컬럼·그래프 모델: NoSQL의 대표 데이터 모델 분류다.
속성 단위로 분할하는 수직적 단편화는 셀렉트가 아니라 프로젝트(project) 연산으로 수행하므로 옳지 않다.
셀렉트는 투플(행)을 고르는 연산이라 수평적 단편화에 쓰이고, 프로젝트는 속성(열)을 고르는 연산이라 수직적 단편화에 쓰인다.
- 확장 용이: 지역(사이트)을 추가하는 방식으로 점진적 확장이 쉽다.
- 구축 비용 증가: 통신망과 분산 제어 소프트웨어가 필요해 비용이 더 든다.
- 지역 장애 시 작업 계속: 데이터 분산·중복으로 가용성과 신뢰성이 높다.