Database Security

데이터베이스 보안

대전대학교 • 011780 • Aaron Snowberger

기말고사 스터디 가이드

p. 227-532

6.1. SQL 응용: 내장 함수

-- 새로운 manager 계정 만든다

SELECT current_user; -- postgres (기본 사용자)

​

CREATE USER manager WITH PASSWORD '1234';

GRANT ALL PRIVILEGES ON DATABASE univdb TO manager;

GRANT ALL PRIVILEGES ON 학생2, 수강2, 과목2 TO manager;

GRANT ALL ON SCHEMA public TO manager; -- 인덱스 권한까지 부여

​

SELECT * FROM pg_namespace; -- 모든 스키마 표시

​

ALTER DATABASE univdb OWNER TO manager; -- postgres 계정만 실행할 수 있다

ALTER TABLE 학생2 OWNER TO manager;

ALTER TABLE 수강2 OWNER TO manager;

ALTER TABLE 과목2 OWNER TO manager;

​

-- 위 드랍다운 화살표 누르고 New Connection... 선택

-- univdb와 manager 계정 선택하고 저장하기

SELECT current_user; -- manager (새로운 사용자!!!)

​

6.1. SQL 응용: 내장 함수

DROP VIEW IF EXISTS V1_고학년학생; -- 뷰

​

-- manager 계정으로 변경

CREATE VIEW V1_고학년학생(학생이름, 나이, 성, 학년) AS

SELECT 이름, 나이, 성별, 학년 FROM 학생2

WHERE 학년 >= 3 AND 학년 >=4;

​

SELECT * FROM V1_고학년학생;

​

CREATE VIEW V2_과목수강현황(과목번호, 강의실, 수강인원수) AS

SELECT 과목2.과목번호, 강의실, COUNT(과목2.과목번호)

FROM 과목2 JOIN 수강2 ON 과목2.과목번호 = 수강2.과목번호

GROUP BY 과목2.과목번호;

​

SELECT * FROM V2_과목수강현황;

​

CREATE VIEW V3_고학년여학생 AS

SELECT * FROM V1_고학년학생

WHERE 성 = '여';

​

SELECT * FROM V3_고학년여학생;

6.1. SQL 응용: 내장 함수

-- 인덱스

DROP INDEX IF EXISTS idx_수강;

DROP INDEX IF EXISTS idx_과목;

DROP INDEX IF EXISTS idx_학생;

​

CREATE INDEX idx_수강 ON 수강(학번, 과목번호); -- 소유자가 된다면

CREATE UNIQUE INDEX idx_과목 ON 과목(이름 ASC);

CREATE UNIQUE INDEX idx_학생 ON 학생(학번);

​

-- SHOW INDEX FROM 학생; -- MySQL만

-- PostgreSQL에서 한 테이블의 모든 인덱스 표시

SELECT indexname, indexdef

FROM pg_indexes

WHERE tablename = '수강2';

​

-- 2023 슬라이드 8장, #32부터

EXPLAIN ANALYZE SELECT * FROM 수강2;

​

​

​

​

07

SQL 응용

1. 내장 함수
2. 저장 프로시저
3. 트리거
4. 사용자 정의 함수
5. 트랜잭션

​

학습목표

​

• 내장 함수의 종류와 사용 방법을 알아본다.
• 저장 프로시저와 토리거의 개념과 활용 방법을 이해한다.
• 사용자 정의 함수의 개념과 활용 방법을 이해한다.
• 트랜잭션의 개념과 종류, 사용 방법을 이해한다.

​

p. 227-282

7.1. SQL 응용: 내장 함수

PostgreSQL에서도 SQL 명령문에서 활용할 수 있는 다양한 내장 함수를 제공합니다. 주요 숫자, 문자, 날짜 및 시간 관련 함수 사용 방법을 살펴봅니다.

7.1.1 내장 함수의 개요

SQL 명령문에서 검색 결과를 변환하거나 원하는 결과로 가공할 수 있습니다. SQL 함수는 DBMS가 제공하는 내장 함수(built-in function)와 사용자가 직접정의하는 사용자 정의 함수(user-defined function)로 분류한다.

PostgreSQL에서도 MySQL처럼 내장 함수와 사용자 정의 함수를 지원합니다. 단, 몇 가지 문법 차이가 있으므로 유의해야 합니다.

​

​

7.1. SQL 응용: 내장 함수

7.1.1 내장 함수의 개요

SQL 내장 함수는 열이름이나 상수 값을 입력받아 값 하나를 결과로 반환한다. 기본 연산 함수와 시스템 정보 제공 함수, 데이터 가공 함수 등이 제공된다. SELECT절이나 WHERE 절 뿐만 아니라 UPDATE SET절 등에서도 사용 가능하다.

​

​

MySQL과 PostgreSQL은 유사한 내장 함수들이 많지만, 일부 함수에 차이가 있습니다. MySQL의 몇 가지 함수는 PostgreSQL에 없거나 다른 이름과 기능을 가질 수 있습니다. 주요 차이점을 함수별로 정리하면 다음과 같습니다.

7.1. SQL 응용: 내장 함수

7.1.1 내장 함수의 개요

PostgreSQL에서 기본 내장 함수는 숫자, 문자, 날짜와 시간 관련 함수가 포함됩니다.

• 숫자 함수: 사칙 연산과 나머지 연산자(%)는 MySQL과 동일하게 지원됩니다.
• 문자 함수: 문자열을 변환하거나 일부를 대체하는 함수 사용은 동일하지만, 일부 함수의 이름이나 동작 방식이 다를 수 있습니다.
• 날짜 및 시간 함수: NOW()와 SYSDATE()와 같은 함수를 제공합니다. 단, SYSDATE()는 MySQL에서 주로 사용되며 PostgreSQL에서는 CURRENT_TIMESTAMP가 동일한 기능을 제공합니다.

또한 DATE_FORMAT() 함수는 MySQL에서 사용 가능하지만, PostgreSQL에서는 TO_CHAR() 함수로 대체하여 날짜 포맷을 변환할 수 있습니다.

7.1. SQL 응용: 내장 함수

7.1.1 내장 함수의 개요

숫자 함수

• ABS(값), CEIL(값), FLOOR(값), ROUND(값, 자리수)�MySQL과 PostgreSQL 모두 동일한 기능으로 지원합니다.
• FORMAT(값, 형식)�MySQL에서 FORMAT()은 숫자를 특정 형식의 문자열로 변환합니다. PostgreSQL에는 이와 동일한 함수는 없지만, TO_CHAR()를 통해 유사한 형식 변환이 가능합니다.

​

​

​

​

예: PostgreSQL에서 TO_CHAR(숫자, '형식')으로 대체.

7.1. SQL 응용: 내장 함수

7.1.1 내장 함수의 개요

문자열 함수

• LENGTH(문자열) // 바이트 단위,
• CHAR_LENGTH(문자열) // 문자 수 단위
• LTRIM/RTRIM(문자열)
• REPLACE(문자열, 검색문자열, 치환문자열)
• REPEAT(문자열, 반복횟수)�MySQL과 PostgreSQL 모두에서 동일하게 지원됩니다.

​

7.1. SQL 응용: 내장 함수

7.1.1 내장 함수의 개요

문자열 함수

• CONCAT(문자열_리스트)�PostgreSQL에서는 || 연산자를 사용해 문자열을 결합할 수도 있습니다.
• LEFT/RIGHT(문자열, 길이)�MySQL에서 지원하는 LEFT()와 RIGHT()는 PostgreSQL에서 SUBSTRING(문자열 FROM 시작 FOR 길이)로 대체할 수 있습니다.
• SUBSTRING(문자열, 위치, 길이)�PostgreSQL에서는 SUBSTRING(문자열 FROM 위치 FOR 길이)로 표현할 수 있습니다.

​

​

​

7.1. SQL 응용: 내장 함수

7.1.1 내장 함수의 개요

날짜 및 시간 함수

• SYSDATE(), NOW()�MySQL의 SYSDATE()와 NOW()는 현재 날짜와 시간을 반환합니다. PostgreSQL에서도 NOW()가 있지만 SYSDATE()는 없으며, CURRENT_TIMESTAMP로 대체할 수 있습니다.
• CURRENT_DATE(), CURRENT_TIME()�MySQL과 PostgreSQL 모두 동일하게 지원합니다.

7.1. SQL 응용: 내장 함수

7.1.1 내장 함수의 개요

날짜 및 시간 함수

• YEAR(날짜), MONTH(날짜), DAY(날짜)�MySQL에서는 각각 YEAR(), MONTH(), DAY()로 연, 월, 일을 추출합니다. PostgreSQL에서는 EXTRACT(YEAR FROM 날짜) 형식으로 사용해야 합니다.
• HOUR(시간), MINUTE(시간), SECOND(시간)�MySQL의 HOUR(), MINUTE(), SECOND() 함수는 PostgreSQL에서 EXTRACT(HOUR/MINUTE/SECOND FROM 시간)으로 대체됩니다.

7.1. SQL 응용: 내장 함수

7.1.1 내장 함수의 개요

날짜 및 시간 함수

• LAST_DAY(날짜)�MySQL은 LAST_DAY()로 해당 날짜의 마지막 날을 반환합니다. PostgreSQL에는 직접 지원하지 않지만 date_trunc와 interval을 조합하여 비슷한 결과를 얻을 수 있습니다.
• DATE_ADD(날짜, INTERVAL 증분값 DAY/MONTH/YEAR)�MySQL의 DATE_ADD()는 PostgreSQL에서 날짜 + interval '증분값 day' 형식으로 사용합니다.
• DATE_SUB(날짜, INTERVAL 감소값 DAY/MONTH/YEAR)�DATE_SUB()는 PostgreSQL에서 날짜 - interval '감소값 day' 형식으로 대체할 수 있습니다.

7.1. SQL 응용: 내장 함수

7.1.1 내장 함수의 개요

날짜 및 시간 함수

• DATE_FORMAT(날짜, '형식')�MySQL의 DATE_FORMAT()은 날짜를 특정 형식의 문자열로 변환하며, PostgreSQL에서는 TO_CHAR(날짜, '형식')으로 대체 가능합니다.

요약하면, MySQL과 PostgreSQL은 대부분의 내장 함수를 유사하게 제공하지만, 몇몇 함수들은 PostgreSQL에서 다른 함수나 형식으로 표현해야 합니다.

​

​

​

7.1. SQL 응용: 내장 함수

7.1.2 내장 함수의 적용

1) 숫자 함수

​

​

7.1. SQL 응용: 내장 함수

7.1.2 내장 함수의 적용

1) 숫자 함수

​

​

7.1. SQL 응용: 내장 함수

7.1.2 내장 함수의 적용

2) 문자 함수

​

​

7.1. SQL 응용: 내장 함수

7.1.2 내장 함수의 적용

2) 문자 함수

​

​

7.1. SQL 응용: 내장 함수

7.1.2 내장 함수의 적용

3) 날짜 / 시간 함수

​

​

7.1. SQL 응용: 내장 함수

7.1.2 내장 함수의 적용

3) 날짜 / 시간 함수

​

​

7.1. SQL 응용: 내장 함수

7.1.2 내장 함수의 적용

3) 날짜 / 시간 함수

​

​

7.2. SQL 응용: 저장 프로시저

저장 프로시저 (stored procedure)는 미리 작성하여 데이터베이스 안에 저장한 SQL 문장들의 묶음이다. 독립된 프로그램으로 데이터베이스 안에 하나의 객체로 저장된다. 보통 DBA가 데이터베이스 관리를 수행하기 위해 사용하는 기능들이 DBMS에 의해 저장 프로시저로 제공된다.

저장 프로시저를 사용할 경우, 최적화된 SQL문을 미리 데이터베이스에 작성해둘 수 있고 복잡한 SQL문을 전달할 필요가 없어 네트워크 부하가 줄어들며 여러 응용 프로그램간의 공유가 가능한 것이 장점이다.

​

​

7.2. SQL 응용: 저장 프로시저

7.2.1 삽입 / 수정 프로시저의 생성 및 활용

CREATE PROCEDURE 문

MySQL에서는 CREATE PROCEDURE와 CREATE FUNCTION이 초기부터 지원되었으며, 트랜잭션 및 데이터 변경 작업을 수행할 때 유사한 방식으로 사용할 수 있습니다.

PostgreSQL 11부터는 CREATE PROCEDURE 명령어도 사용할 수 있게 되었는데, 이 명령어는 프로시저를 생성하며 데이터베이스 내에서 트랜잭션 제어가 가능합니다. 프로시저는 값을 반환하지 않지만, 여러 SQL 명령어를 포함하고 있어 복잡한 로직을 한 번에 실행할 때 유용합니다.

프로시저는 CALL 명령어를 사용해 호출됩니다.

​

​

​

7.2. SQL 응용: 저장 프로시저

7.2.1 삽입 / 수정 프로시저의 생성 및 활용

InsertOrUpdateCourse 프로시저 생성 및 사용:

1. DELIMITER 명령어를 사용해 프로시저의 종료 구분자를 //로 지정한다.
2. CREATE PROCEDURE 명령문으로 프로시저를 생성하고, 프로시저 이름과 매개변수를 선언한다.
3. 프로시저의 매개변수를 정의하며, 입력 매개변수는 IN, 출력 매개변수는 OUT 키워드로 구분한다.
4. BEGIN .. END 블록으로 프로시저 실행부를 정의한다.
5. DECLARE 문으로 프로시저 내부의 지역 변수를 선언한다.
6. SELECT 문으로 과목번호의 행 개수를 Count 변수에 저장한다.
7. IF .. THEN .. ELSEIF .. END IF 문으로 조건을 검사하고, Count가 0이면 INSERT, 아니면 UPDATE 문을 실행한다.
8. //로 프로시저 실행을 하나의 단위로 처리한다.
9. 구분 문자를 다시 세미콜론(;)으로 변경한다.

​

​

​

​

7.2. SQL 응용: 저장 프로시저

7.2.1 삽입 / 수정 프로시저의 생성 및 활용

InsertOrUpdateCourse 프로시저 생성 및 사용:

• CALL 문으로 InsertOrUpdateCourse 프로시저를 호출하고, 매개변수 값을 전달한다.
• 과목 테이블에 새로운 행이 추가되었음을 확인한다.
• CALL 문으로 InsertOrUpdateCourse 프로시저를 다시 호출한다.
• 프로시저 실행 후 기존 행의 강의실 번호가 310에서 410으로 변경되었음을 확인한다.

​

​

​

​

7.2. SQL 응용: 저장 프로시저

7.2.1 삽입 / 수정 프로시저의 생성 및 활용

​

​

​

​

7.2. SQL 응용: 저장 프로시저

7.2.1 삽입 / 수정 프로시저의 생성 및 활용

​

​

​

​

​

7.2. SQL 응용: 저장 프로시저

7.2.1 삽입 / 수정 프로시저의 생성 및 활용

PostgreSQL 버전 11 이하에서는 저장 프로시저를 함수와 구별하여 정의하며, CREATE PROCEDURE 문을 사용하지 않고 대신 CREATE FUNCTION을 주로 사용합니다.

​

​

​

​

7.2. SQL 응용: 저장 프로시저

7.2.1 삽입 / 수정 프로시저의 생성 및 활용

SelectAverageOfBestScore 프로시저 생성 및 사용:

1. 특정 점수를 입력받을 Score 입력 매개변수를 선언한다.
2. 학생 수를 반환하기 위한 출력 매개변수 Count를 선언한다.
3. DECLARE로 필요한 지역 변수를 선언하고 SET으로 값을 할당한다.
4. 수강 테이블의 성적 데이터를 위한 커서를 선언한다.
5. 커서가 끝에 도달했을 때 NoMoreData 값을 참으로 설정하는 NOT FOUND 핸들러를 정의한다.
6. 커서를 열어 질의를 실행한다.
7. NoMoreData가 참이 될 때까지 커서의 데이터를 반복적으로 가져온다.
8. 각 행의 성적을 비교하여 높은 점수가 Score 이상이면 Count를 1씩 증가시킨다.
9. 커서를 닫는다.

7.2. SQL 응용: 저장 프로시저

7.2.2 검색 저장 프로시저의 생성 및 활용

SelectAverageOfBestScore 프로시저 생성 및 사용:

프로시저의 호출

7.2. SQL 응용: 저장 프로시저

7.2.1 삽입 / 수정 프로시저의 생성 및 활용

​

7.2. SQL 응용: 저장 프로시저

7.2.2 검색 저장 프로시저의 생성 및 활용

SelectAverageOfBestScore 프로시저 생성 및 사용:

프로시저의 호출

7.2. SQL 응용: 저장 프로시저

7.2.3 저장 프로시저의 삭제

DROP PROCEDURE 문

프로시저 삭제하기 전에 삭제할 저장 프로시저의 내용을 확인해 보자. SHOW CREATE PROCEDURE 명령어를 실행하면 삭제할 저장 프로시저의 내용을 확인할 수 있다.

​

​

​

​

7.3. SQL 응용: 트리거

PostgreSQL에서도 트리거 기능을 지원합니다. 트리거는 특정 이벤트(INSERT, UPDATE, DELETE) 발생 시 자동으로 실행되도록 설정됩니다.

​

​

​

​

7.3. SQL 응용: 트리거

7.3.1 트리거의 생성 및 활용

MySQL의 CREATE TRIGGER와 동일한 문법으로 PostgreSQL에서도 트리거를 생성할 수 있습니다. 다만, PostgreSQL에서는 트리거 함수 내에서 OLD 및 NEW 키워드를 사용하여 변경 전후의 데이터를 참조할 수 있습니다.

​

​

​

​

7.3. SQL 응용: 트리거

7.3.1 트리거의 생성 및 활용

​

​

​

​

7.3. SQL 응용: 트리거

7.3.1 트리거의 생성 및 활용

CREATE TRIGGER문

​

​

​

​

7.3. SQL 응용: 트리거

7.3.1 트리거의 생성 및 활용

CREATE TRIGGER문

​

​

​

​

7.3. SQL 응용: 트리거

7.3.1 트리거의 생성 및 활용

DROP TRIGGER문

​

​

​

​

7.4. SQL 응용: 사용자 정의 함수

PostgreSQL는 사용자가 정의한 함수와 절차를 지원하며, 둘 다 특정 작업을 자동화하거나 코드 재사용을 가능하게 합니다. 다만, 함수와 프로시저의 목적과 호출 방식에는 차이가 있습니다.

​

​

​

7.4. SQL 응용: 사용자 정의 함수

CREATE FUNCTION은 주로 값을 반환할 때 사용됩니다. 반환되는 값은 정수, 문자열 등 기본 데이터형이거나 테이블 형태일 수 있습니다. 함수 내에서 데이터를 변경할 수 있지만, 트랜잭션의 일부로 자동으로 작동하지 않으며, 이를 위해서는 트리거 또는 특정 기능을 추가해야 합니다.

​

​

​

​

PostgreSQL 11부터는 CREATE PROCEDURE 명령어를 생성하며 데이터베이스 내에서 트랜잭션 제어가 가능합니다. 프로시저는 값을 반환하지 않지만, 여러 SQL 명령어를 포함하고 있어 복잡한 로직을 한 번에 실행할 때 유용합니다. 프로시저는 CALL 명령어를 사용해 호출됩니다.

7.4. SQL 응용: 사용자 정의 함수

7.4.1 사용자 정의 함수의 생성

CREATE FUNCTION문

​

​

​

​

7.4. SQL 응용: 사용자 정의 함수

7.4.1 사용자 정의 함수의 생성

CREATE FUNCTION문

​

​

​

​

7.4. SQL 응용: 사용자 정의 함수

7.4.2 사용자 정의 함수의 삭제

DROP FUNCTION문

​

​

​

​

7.4. SQL 응용: 사용자 정의 함수

7.4.2 사용자 정의 함수의 삭제

저장 프로시저, 트리거, 사용자 정의 함수의 비교

• 저장 프로시저: 처리 일관성을 유지하고 보안을 강화하며 반복적인 SQL 처리를 최적화할 수 있음.
• 트리거: 데이터 무결성을 강화하며 다양한 규칙을 구현 가능하지만, 성능 저하가 발생할 수 있음.
• 사용자 정의 함수: 특정 값 또는 테이블 형태의 결과를 반환할 수 있어 SQL 명령문 작성의 편의성을 높여줌.

​

​

​

​

​

7.4. SQL 응용: 사용자 정의 함수

7.4.2 사용자 정의 함수의 삭제

저장 프로시저, 트리거, 사용자 정의 함수의 비교

​

​

​

​

​

7.5. SQL 응용: 트랜잭션

데이터베이스 응용 프로그램 개발 시 여러 SQL 문을 하나의 단위로 묶어 처리할 필요가 있습니다. 이를 트랜잭션 단위로 정의하여 안정성과 일관성을 확보할 수 있습니다.

7.5.1 트랜잭션의 개념

SQL 명령어 하나로는 복잡한 업무 처리가 어려울 수 있습니다. 따라서 여러 SQL 명령어를 트랜잭션 단위로 묶어 일괄적으로 처리해야 할 필요가 있습니다.

​

​

​

​

​

7.5. SQL 응용: 트랜잭션

7.5.1 트랜잭션의 개념

트랜잭션 정의

트랜잭션은 하나의 작업 단위로 처리되어야 하는 SQL 명령어 집합입니다. 이 명령어들이 모두 성공해야 트랜잭션이 완료되며, 하나라도 실패하면 전체를 취소할 수 있습니다.

트랜잭션을 시작하려면 START TRANSACTION을 사용하고, 성공적으로 완료하려면 COMMIT을 사용합니다. ROLLBACK 명령어를 사용하면 트랜잭션 시작 전 상태로 되돌릴 수 있습니다.

​

​

​

​

​

​

7.5. SQL 응용: 트랜잭션

7.5.1 트랜잭션의 개념

트랜잭션 예시

계좌 이체는 두 개의 UPDATE 문을 포함하며, 두 문이 모두 성공해야만 트랜잭션이 완료됩니다. 트랜잭션의 실패 시에는 ROLLBACK하여 모든 변경사항을 취소할 수 있습니다.

​

​

​

​

​

​

​

7.5. SQL 응용: 트랜잭션

7.5.1 트랜잭션의 개념

트랜잭션의 ACID 특성

• 원자성 (Atomicity): 모든 SQL 명령어가 성공하거나 실패하여 전체가 취소됩니다. (‘전부 혹은 전무(all or nothing)')
• 일관성 (Consistency): 트랜잭션 완료 후에도 데이터베이스의 일관성이 유지됩니다.
• 고립성 (Isolation): 커밋 전까지 다른 트랜잭션이 접근할 수 없습니다.
• 지속성 (Durability): 커밋된 트랜잭션의 결과는 데이터베이스에 영구적으로 반영됩니다.

​

​

​

​

​

​

​

​

7.5. SQL 응용: 트랜잭션

7.5.1 트랜잭션의 개념

트랜잭션 지원 DBMS 모듈

트랜잭션을 지원하기 위해 DBMS는 동시성 제어와 회복 모듈을 제공한다.

​

​

​

​

​

​

​

​

• 동시성 제어 (concurrency control) 모듈

동시에 실행되는 트랜잭션 간의 간섭을 제어한다. 최종적으로 각 트랜잭션이 순차적으로 실행한 결과와 동일한 고립성 결과를 보장하고 트랜잭션 실행 이전과 이후의 데이터베이스 일관성이 항상 유지되도록 한다.

​

• 회복(recovery) 모듈

완전한 트랜잭션 결과의 복구를 보장한다. 장애 발생 시 트랜잭션 실행의 원자성을 보장하 고 커밋된 트랜잭션의 결과는 반드시 데이터베이스에 반영되도록 지속성을 지원한다.

7.5. SQL 응용: 트랜잭션

7.5.1 트랜잭션의 개념

트랜잭션 지원 DBMS 모듈

이론적으로는 다양한 동시성 제어 및 회복 기법이 존재하지만 DBMS의 지원 기법은 대 부분 비슷하다.

• 대표적인 동시성 제어 기법은 로킹(locking)이며
• 대표적인 회복 기법은 로깅(logging)이다.

​

​

​

​

​

​

​

​

​

​

7.5. SQL 응용: 트랜잭션

7.5.2 트랜잭션의 종류

트랜잭션은 설정 모드에 따라 [그림 7-7]과 같이 3가지 트랜잭션으로 구분할 수 있다.

​

​

​

​

​

​

​

​

​

​

7.5. SQL 응용: 트랜잭션

7.5.2 트랜잭션의 종류

명시적 트랜잭션: 사용자가 START TRANSACTION과 COMMIT 명령어를 직접 지정합니다. 주로 PostgreSQL과 MySQL에서 동일하게 사용됩니다.

1. START TRANSACTION 명령문은 직접 트랜잭션의 시작을 지시한다.
2. COMMIT 명령문은 트랜잭션의 처리 결과를 성공적으로 완료한다. 모든 작업의 정상적 처리를 확정하는 명령어로 변경 내용을 모두 실제 데이터베이스에 영구적으로 반영한다.
3. ROLLBACK 명령문은 트랜잭션 처리 내용을 취소하고 트랜잭션 시작 이전의 원래 상 태로 되돌린다.

​

​

​

​

​

​

​

​

​

​

7.5. SQL 응용: 트랜잭션

7.5.2 트랜잭션의 종류

명시적 트랜잭션 예

​

​

​

​

​

​

​

​

7.5. SQL 응용: 트랜잭션

7.5.2 트랜잭션의 종류

자동완료 트랜잭션: 각 SQL 명령어가 독립적인 트랜잭션으로 자동 처리됩니다.

PostgreSQL에서는 기본적으로 모든 명령어가 개별 트랜잭션 단위로 동작하며, MySQL과 달리 자동 커밋 모드 설정이 필요하지 않습니다.

MySQL의 자동완료 모드에서는 모든 SQL문장 하나하나가 실행되면 바로 커밋되기 때문에 롤백 명령문은 적용되지 않는다.

7.5. SQL 응용: 트랜잭션

7.5.2 트랜잭션의 종류

수동완료 트랜잭션: 트랜잭션의 시작은 자동으로 실행되며, 완료만 사용자가 직접 명시합니다. PostgreSQL에서도 수동 커밋이 필요한 경우가 있으며, BEGIN을 통해 트랜잭션을 시작하고 COMMIT 또는 ROLLBACK으로 종료합니다.

7.5. SQL 응용: 트랜잭션

7.5.2 트랜잭션의 종류

주의점 (MySQL과의 차이점)

MySQL은 자동 커밋 모드를 AUTOCOMMIT 설정을 통해 조정해야 하며, 기본값이 1로 자동 완료 모드가 설정되어 있습니다.

PostgreSQL은 기본적으로 자동 커밋 모드가 비활성화된 상태에서 작업을 진행하며, COMMIT을 명시적으로 호출해야만 변경사항이 반영됩니다.

​

7.5. SQL 응용: 트랜잭션

7.5.3 트랜잭션과 로그

PostgreSQL은 트랜잭션과 로그 관리가 중요한 특징입니다. 트랜잭션은 데이터 변경의 일관성을 보장하며 로그는 데이터 복구를 위한 필수 요소입니다.

트랜잭션 처리 과정

• 쿼리 해석: SQL 명령문이 쿼리 처리기를 통해 접수되고 해석됩니다.
• 데이터 로드: 디스크에서 주기억 장치로 필요한 데이터가 로드됩니다.
• 데이터 변경: 데이터베이스 버퍼 캐시 내에서 데이터가 변경되며, 바로 디스크에 기록되지 않고 지연 쓰기 방식이 사용됩니다.

7.5. SQL 응용: 트랜잭션

7.5.3 트랜잭션과 로그

로그와 회복

• 로그 먼저 쓰기 규약 (WAL - write-ahead log protocol): 트랜잭션 실행 기록을 데이터 변경 전 로그에 먼저 기록해 장애 발생 시 데이터를 복구할 수 있습니다.
• 트랜잭션 로그 데이터베이스: 각 트랜잭션의 시작, 종료, 변경 내용을 기록하여 장애 발생 시 데이터를 롤백(취소)하거나 롤포워드(재실행)할 수 있게 합니다.
• 체크포인트 (백업 데이터베이스): 주기적으로 데이터를 동기화하여 복구 작업량을 줄입니다.
• 전체 백업 (full backup)
• 차등 백업 (differential backup)
• 증분 백업 (incremental backup)

7.5. SQL 응용: 트랜잭션

7.5.3 트랜잭션과 로그

로그의 구조와 예

7.5. SQL 응용: 트랜잭션

7.5.3 트랜잭션과 로그

로그의 기반 회복의 예

7.5. SQL 응용: 트랜잭션

7.5.4 트랜잭션과 로크

다중 사용자 환경에서 동시성 제어는 필수적입니다. PostgreSQL은 로크를 통해 데이터 무결성을 보장합니다.

바람직한 동시성 (concurrency)이란 2 개 이상의 트랜잭션을 동시에 실행하는 비직렬 스케쥴 (non-serial schedule) 의 결과가 트랜잭션을 뒤섞지 않고 순차적으로 실행하는 직렬 스케쥴 , (serial schedule) 의 결과와 같도록 보장하는 것이다. 이를 보장하는 트랜잭션 스케줄을 칙렬 가능(serializable)’이라고 한다. 직렬 가능성 (serializability)을 보장하기 위한 방법 중 하나가 로크를 이용하는 것이다.

7.5. SQL 응용: 트랜잭션

7.5.4 트랜잭션과 로크

로크 개념

• 직렬 가능성 보장: 비직렬 스케줄의 결과가 직렬 스케줄과 동일하도록 보장하여 일관성을 유지합니다.

​

7.5. SQL 응용: 트랜잭션

7.5.4 트랜잭션과 로크

로크의 종류

• 공유 로크 (Shared): 데이터 읽기를 위한 로크로, 여러 트랜잭션이 동시에 설정할 수 있습니다.
• 독점 로크 (Exclusive): 데이터 변경을 위한 배타적 로크로, 단일 트랜잭션만 설정할 수 있습니다.

7.5. SQL 응용: 트랜잭션

7.5.4 트랜잭션과 로크

로크 설정 및 해제

로크는 트랜잭션 시작 시 설정하고, 트랜잭션 커밋 또는 롤백 시 해제합니다. 독점 로크와 공유 로크 2가지 유형의 로크 사이에는 서로 추가 잠금 허용 여부를 결정하는 로크 양립성(lock compatibility) 규칙이 있다.

​

7.5. SQL 응용: 트랜잭션

7.5.4 트랜잭션과 로크

2단계 로킹 규약과 로크 해제

단지 로크를 설정했다고 해서 동시성 제어가 완벽하게 이루어지지 않는다. 로크를 적절히 설정했더라도 로크를 너무 일찍 해제할 경우, 트랜잭션의 고립성이 손상되어 결국 데이터 일관성이 유지되지 않는다. 로크 설정과 로크 해제를 적절한 시점에 할 필요가 있다.

양단계 로킹 규약(2-phase locking protocol)은 각 트랜잭션별로 로크를 설정하는 과정과 로 크를 해제하는 과정 2단계로 진행함으로써 필요한 순간까지 획득한 로크를 유지하도록 하는 규칙이다.

​

​

7.5. SQL 응용: 트랜잭션

7.5.4 트랜잭션과 로크

2단계 로킹 규약과 로크 해제

• 1단계 : 로크 확장 단계(growing phase) 접근하고자 하는 데이터에 대한 모든 로크를 획득할 때까지 새로운 로크를 지속적으로 요청하여 잠금을 설정한다. 보유하고 있는 로크를 해제할 수는 없고 로크를 추가로 획득할 수 만 있다.
• 2단계 : 로크 축소 단계(shrinking phase) 필요로 하는 모든 로크를 획득하는 시점인 로크 포인트(lock point)가 되면 보유하고 있던 로크를 점차적으로 해제한다. 로크를 계단식으로 하나씩 해제할 수도 있지만 대부분 완 료(커밋 혹은 롤백) 시점에 한꺼번에 모든 로크를 해제한다.

​

​

​

7.5. SQL 응용: 트랜잭션

7.5.4 트랜잭션과 로크

교착 상태

로크를 적용하면 교착 상태에 빠질 수 있으므로 주의해야 한다. 교착 상태 (deadlock)는 둘 이상의 트랜잭션의 로크가 서로 얽혀서 영원히 풀리지 않는 상태를 말한다. 서로 필요한 데이터 중 일부에 대한 로크를 획득하고 서로 상대방이 획득한 로크가 풀리기를 기다리게 되면 교착 상태에 들어가게 된다.

​

​

​

​

7.5. SQL 응용: 트랜잭션

7.5.4 트랜잭션과 로크

트랜잭션 고립 수준

로크를 설정하는 목적은 적절한 수준에서 트랜잭션 동시 실행이 이루어지도록 하기 위해서 이다.

필요로 하는 트랜잭션의 실행 수준에 따른 다양한 고립 수준을 정의하고 상황에 맞는 적 절한 수준의 잠금 전략을 수행한다. 고립 수준(isolation level)은 트랜잭션이 다른 트랜잭션 과 고립되는 정도를 의미한다.

​

​

​

​

​

7.5. SQL 응용: 트랜잭션

7.5.4 트랜잭션과 로크

트랜잭션 고립 수준

​

​

​

​

​

4가지 트랜잭션 고립 수준이 있습니다.

7.5. SQL 응용: 트랜잭션

7.5.4 트랜잭션과 로크

트랜잭션 고립 수준

고립 수준에 따라 발생할 수 있는 문제 유형은 다음과 같다.

• 오손 데이터 읽기 (dirty data read) 문제
• 커밋되지 않은 트랜잭션 T1의 수정된 중간 결과를 읽어오는 것이 허용된다면 발생할 수 있는 문제이다.
• 반복 불가능 읽기 (non-repeatable read) 문제
• 트랜잭션 T1이 읽어서 처리중인 데이터를 트랜잭션 T2가 자유롭게 변경하는 것이 허용 된다면 발생할 수 있는 문제이다.
• 유령 데이터 읽기 (phantom data read) 문제
• 트랜잭션 T1이 읽어서 처리중인 데이터를 트랜잭션 T2가 변경하는 것을 방지하더라도 트랜잭션 T2 의 데이터 추가가 허용된다면 발생할 수 있는 문제이다.

​

​

​

​

​

7.5. SQL 응용: 트랜잭션

7.5.4 트랜잭션과 로크

SET TRANSACTION ISOLATION LEVEL문

​

​

​

​

​

7.5. SQL 응용: 트랜잭션

7.5.4 트랜잭션과 로크

SET TRANSACTION ISOLATION LEVEL예

​

​

​

​

​

7.5. SQL 응용: 트랜잭션

7.5.4 트랜잭션과 로크

SET TRANSACTION ISOLATION LEVEL예

​

​

​

​

​

7.5. SQL 응용: 트랜잭션

7.5.4 트랜잭션과 로크

SET TRANSACTION ISOLATION LEVEL예

​

​

​

​

​

데이터베이스

연습문제

연습문제

08

정규화

• 정규화와 이상 현상
• 함수 종속성
• 기본 정규형

​

학습목표

​

• 정규화의 필요성과 이상 현상을 이해한다.
• 함수 종속성의 개념과 함수 종속 다이어그램을 알아 본다.
• 기본 정규형을 이해하고 정규화를 적용해 본다.

​

p. 283-314

8.1. 정규화: 정규화와 이상 현상

데이터베이스에서 많은 사용자가 동시에 사용하는 대량의 데이터를 효율적으로 구성하는 것은 중요한 문제입니다. 잘못된 스키마 정의는 데이터 중복과 이상 현상을 발생시킬 수 있으며, 이를 방지하기 위해 정규화가 필요합니다. 정규화는 데이터베이스 스키마를 올바르게 설계하는 방법입니다.

​

​

​

​

8.1. 정규화: 정규화와 이상 현상

8.1.1 정규화의 필요성

관계형 데이터베이스는 데이터를 테이블 형식으로 저장하며, 잘못된 설계는 데이터 중복과 무결성 훼손 등의 문제를 초래할 수 있습니다. 정규화는 이러한 문제를 최소화하여 데이터베이스의 효율성을 높입니다.

​

​

​

​

8.1. 정규화: 정규화와 이상 현상

8.1.2 이상 현상

이상 현상은 잘못된 스키마 설계로 인해 데이터 중복에서 발생하는 문제로, 삽입, 갱신, 삭제 시 원치 않는 결과를 초래할 수 있습니다.

• 삽입 이상: 데이터 삽입 시, 필요 이상의 데이터를 함께 넣어야 하는 문제.
• 갱신 이상: 중복된 데이터 갱신 시 모든 값을 수정해야 하는 문제.
• 삭제 이상: 데이터 삭제 시 유용한 정보까지 손실될 수 있는 문제.

​

​

​

​

​

8.1. 정규화: 정규화와 이상 현상

8.1.3 정규화의 개념

정규화는 데이터 중복을 줄이고 관련된 속성들만으로 릴레이션을 구성해 이상 현상을 방지하는 과정입니다. 각 릴레이션에는 하나의 종속성만 표현되도록 분해하여 효율적인 데이터베이스 구조를 만듭니다.

​

​

​

​

​

​

8.2. 정규화: 함수 종속성

함수 종속성은 같은 릴레이션 내 속성 간의 연관성을 분석하는 기준입니다. 주어진 속성 값이 다른 속성 값을 결정하는 관계를 의미하며, 이를 통해 릴레이션을 효과적으로 설계할 수 있습니다.

​

​

​

​

​

​

​

​

8.2. 정규화: 함수 종속성

8.2.1 함수 종속성 정의

함수 종속성은 속성 간에 특정 속성이 다른 속성을 결정할 때 형성됩니다. 예를 들어, 학생 정보에서 학번이 주어지면 이름, 주소 등 다른 속성 값이 자동으로 결정되는 관계입니다.

​

​

​

​

​

​

​

​

​

​

8.2. 정규화: 함수 종속성

8.2.1 함수 종속성 정의

​

​

​

​

​

​

​

​

​

​

8.2. 정규화: 함수 종속성

8.2.2 함수 종속 다이어그램

속성 간 함수 종속 관계를 시각화하는 다이어그램으로, 각 속성 간의 종속성을 직관적으로 이해할 수 있도록 돕습니다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

8.2. 정규화: 함수 종속성

8.2.2 함수 종속 다이어그램

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

8.3. 정규화: 기본 정규형

정규화는 데이터베이스에서 이상 현상을 방지하기 위해 릴레이션을 분해하는 과정이다. 정규형은 특정 조건을 만족해야 하며, 주로 제1정규형부터 제3정규형까지만 사용된다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

8.3. 정규화: 기본 정규형

8.3.1 정규형의 종류

정규형은 릴레이션이 만족해야 하는 특정한 함수 종속성을 정의하며, 높은 정규형일수록 조건이 엄격해진다. 일반적으로 제3정규형 이상을 충족하면 충분하다고 본다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

8.3. 정규화: 기본 정규형

8.3.2 제1정규형

제1정규형은 릴레이션의 모든 속성이 원자값(단일 값)을 가져야 한다. 예를 들어, 전화번호 속성이 여러 값을 가지면 제1정규형을 충족하지 못한다. 원자값을 가지도록 속성을 나누어야 하며, 이로 인해 중복 데이터와 삽입, 수정, 삭제 시 발생하는 이상 현상을 막을 수 있다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

8.3. 정규화: 기본 정규형

8.3.2 제1정규형

제 1 정규형의 문제점

‘수강_2' 릴레이션은 각 속성의 도메인이 원자 값이므로 제 1 정규형에 속한다. 그러나 실제 데이터 분석 시 불필요한 데이터 중복이 많아 삽입, 수정, 삭제 시 이상 현상이 발생할 수 있다.

(1-1) 삽입 이상

과목번호 ‘c006'인 과목의 개설학과가 ‘통계’라는 사실을 따로 삽입할 수 없다. {학번, 과목번호} 조합이 기본키이므로, 어떤 학생이 이 과목을 수강하지 않으면 ‘학번’ 속성 값이 NULL이 되어 기본키 제약 조건을 위배한다.

8.3. 정규화: 기본 정규형

8.3.2 제1정규형

제 1 정규형의 문제점

‘수강_2' 릴레이션은 각 속성의 도메인이 원자 값이므로 제 1 정규형에 속한다. 그러나 실제 데이터 분석 시 불필요한 데이터 중복이 많아 삽입, 수정, 삭제 시 이상 현상이 발생할 수 있다.

(1-2) 수정 이상

컴퓨터학과의 학과장이 변경될 경우, 모든 투플을 찾아 ‘학과장’ 속성 값을 일괄적으로 변경해야 한다. 불필요한 데이터가 여러 번 중복 저장되어 있어 일부만 변경할 경우 갱신 불일치 문제가 발생할 수 있다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

8.3. 정규화: 기본 정규형

8.3.2 제1정규형

제 1 정규형의 문제점

‘수강_2' 릴레이션은 각 속성의 도메인이 원자 값이므로 제 1 정규형에 속한다. 그러나 실제 데이터 분석 시 불필요한 데이터 중복이 많아 삽입, 수정, 삭제 시 이상 현상이 발생할 수 있다.

(1-3) 삭제 이상

과목번호 ‘c002' 과목에 관련된 유일한 투플을 삭제하면, 그 과목의 개설학과와 학과장 정보까지 함께 삭제되어 원하지 않는 정보가 사라진다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

8.3. 정규화: 기본 정규형

8.3.2 제1정규형

제 1 정규형의 문제점 해결

제 1 정규형을 충족하는 릴레이션의 이상 현상을 해결하기 위해 속성 간의 함수 종속성을 분석해야 한다. {학번, 과목번호}의 조합이 기본키이며, ‘학점’ 속성만 기본키에 완전 함수 종속되어 있다.

나머지 속성들은 기본키에 부분 함수 종속되어 있어 불필요한 데이터 중복이 발생한다. 이를 해결하기 위해 ‘수강_2' 릴레이션을 서로 연관성이 높은 속성끼리 3개의 릴레이션으로 분해해야 한다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

8.3. 정규화: 기본 정규형

8.3.2 제1정규형

무손실 분해

릴레이션 분해는 정보 손실 없이 동등한 릴레이션으로 분해해야 하며, 이를 무손실 분해(nonloss decomposition)라고 한다. 분해된 릴레이션은 자연 조인(natural join) 연산으로 원래의 릴레이션으로 복원할 수 있어야 하며, 그렇지 않으면 잘못된 분해가 된다. 분해할 때는 결정자와 그에 종속되는 속성들을 함께 떼어내고, 결정자는 분해 전의 릴레이션에 공통 속성으로 남겨두어야 한다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

8.3. 정규화: 기본 정규형

8.3.2 제1정규형

무손실 분해

[그림 8-7]의 함수 종속 관계를 고려하여 ‘수강_2' 릴레이션을 3개의 릴레이션으로 분해함으로써 데이터 중복을 줄이고 앞서 언급한 삽입, 수정, 삭제 이상의 발생을 방지할 수 있다.

제 1 정규형의 이상 원인은 기본키의 일부이면서 결정자 역할을 하는 속성이 존재하기 때문에 발생하며, 기본키의 부분 함수 종속성을 제거함으로써 문제를 해결할 수 있다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

8.3. 정규화: 기본 정규형

8.3.2 제1정규형

제 1 정규형의 문제점 해결

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

8.3. 정규화: 기본 정규형

8.3.3 제2정규형

제2정규형은 제1정규형을 충족하며, 기본키에 속하지 않는 모든 속성이 기본키에 완전 함수 종속이어야 한다. 제2정규형을 충족하지 못하는 경우 속성을 분해하여 부분 함수 종속을 제거하고, 불필요한 데이터 중복과 이상 현상을 방지할 수 있다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

8.3. 정규화: 기본 정규형

8.3.3 제2정규형

제 2 정규형의 문제점

‘수강_2' 릴레이션을 분해한 릴레이션 중 ‘과목_1’ 릴레이션은 과목 관련 속성들로 구성된 테이블이며 과목번호가 기본키이다. 이 릴레이션은 부분 함수 종속성이 없으므로 제 2 정규형에 속한다. 그러나 실제 데이터를 분석해보면 여전히 불필요한 데이터 중복이 있어 삽입, 수정, 삭제 시 이상 현상이 발생할 수 있다.

(2-1) 삽입 이상

과목개설학과인 ‘통계’학과의 학과장이 ‘홍장미’라는 사실만 따로 삽입할 수 없다. ‘과목번호’ 속성이 기본키이므로, 어떤 과목을 미리 등록하지 않으면 ‘과목번호’ 속성 값이 NULL이 되어 기본키 제약 조건을 위배한다.

8.3. 정규화: 기본 정규형

8.3.3 제2정규형

제 2 정규형의 문제점

‘수강_2' 릴레이션을 분해한 릴레이션 중 ‘과목_1’ 릴레이션은 과목 관련 속성들로 구성된 테이블이며 과목번호가 기본키이다. 이 릴레이션은 부분 함수 종속성이 없으므로 제 2 정규형에 속한다. 그러나 실제 데이터를 분석해보면 여전히 불필요한 데이터 중복이 있어 삽입, 수정, 삭제 시 이상 현상이 발생할 수 있다.

(2-2) 수정 이상

컴퓨터학과의 학과장이 변경될 경우, 여전히 과목개설학과 ‘컴퓨터’인 모든 투플을 찾아 ‘학과장’ 속성 값을 한꺼번에 변경해야 한다. ‘과목개설학과’에 대한 ‘학과장’ 속성 값이 불필요하게 중복 저장되어 있기 때문이다.

​

​

​

8.3. 정규화: 기본 정규형

8.3.3 제2정규형

제 2 정규형의 문제점

‘수강_2' 릴레이션을 분해한 릴레이션 중 ‘과목_1’ 릴레이션은 과목 관련 속성들로 구성된 테이블이며 과목번호가 기본키이다. 이 릴레이션은 부분 함수 종속성이 없으므로 제 2 정규형에 속한다. 그러나 실제 데이터를 분석해보면 여전히 불필요한 데이터 중복이 있어 삽입, 수정, 삭제 시 이상 현상이 발생할 수 있다.

(2-3) 삭제 이상

과목번호 ‘c002’의 등록을 취소하면 ‘경영’학과의 학과장 정보까지 함께 삭제되어, 다른 과목이 등록되어 있지 않다면 경영학과의 학과장 정보가 완전히 사라져버린다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

8.3. 정규화: 기본 정규형

8.3.3 제2정규형

제 2 정규형의 문제점 해결

제 2 정규형을 충족하는 ‘과목_1’ 릴레이션에서 삽입, 수정, 삭제 이상이 발생하는 이유는 둘 이상의 의미적 연관성을 하나의 릴레이션으로 함께 표현했기 때문이다. 이를 해결하기 위해 속성들 간의 함수 종속성을 분석해야 한다.

‘과목_1’ 릴레이션의 함수 종속성은 다음과 같다. 이 릴레이션의 이상 원인은 ‘학과장’ 속성이 기본키인 ‘과목번호’뿐만 아니라 ‘과목개설학과’ 속성에도 완전 함수 종속이기 때문이다. 이행적 종속 관계로 인해 불필요한 데이터의 중복이 발생한다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

8.3. 정규화: 기본 정규형

8.3.3 제2정규형

제 2 정규형의 문제점 해결

이행적 함수 종속성(transitive functional dependency)은 기본키에 속하지 않은 일반 속성 값이 다른 일반 속성 값을 결정함을 의미한다. 이 문제를 해결하려면 이행적 종속 관계를 끊어 두 종속 관계를 각기 다른 릴레이션에 표현해야 한다.

‘과목_1’ 릴레이션을 두 개의 릴레이션으로 분해하면 데이터 중복이 감소하고 앞서 지적한 삽입, 수정, 삭제 이상의 발생을 방지할 수 있다. 이행적 함수 종속성을 제거함으로써 문제를 해결할 수 있다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

8.3. 정규화: 기본 정규형

8.3.3 제2정규형

제 2 정규형의 문제점 해결

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

8.3. 정규화: 기본 정규형

8.3.3 제2정규형

제 2 정규형의 문제점 해결

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

8.3. 정규화: 기본 정규형

8.3.4 제3정규형

어떤 릴레이션 R이 제2정규형이고 기본키에 속하지 않는 모든 속성이 기본키에 이행적 함수 종속이 아니면, 제 3정규형에 속한다. 제 3정규형은 제 2정규형을 충족하는 릴레이션의 기본키가 아닌 일반 속성이 결정자인지를 검사한다. 일반 속성이 기본키 속성이 아닌 일반 속성에 종속적일 때 제 3정규형에 위배된다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

8.3. 정규화: 기본 정규형

8.3.4 제3정규형

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

8.3. 정규화: 기본 정규형

8.3.4 제3정규형

제3정규형의 문제점

제 3정규형만으로도 일반적인 중복성이 제거되므로 대부분의 경우 제 3정규형까지 정규화를 진행한다. 그러나 다음과 같은 경우 여전히 이상 현상이 발생할 수 있다.

• 삽입 이상: 기본키 제약 조건을 위배하여 강의담당교수를 따로 삽입할 수 없다.
• 수정 이상: 강의담당교수의 과목번호를 변경할 때 모든 관련 투플을 수정해야 하므로 갱신 불일치 문제가 발생할 수 있다.
• 삭제 이상: 학생이 수강을 취소하면 해당 교수의 정보가 삭제될 수 있다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

8.3. 정규화: 기본 정규형

8.3.4 제3정규형

제3정규형 문제점 해결

문제 해결을 위해 속성 간의 함수 종속성을 분석할 수 있다. ‘수강_4’ 릴레이션의 함수 종속성을 분석하여 기본키가 아닌 결정자를 분리해 2개의 릴레이션으로 분해하면 데이터 중복이 감소하고 이상 현상이 발생하지 않게 된다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

8.3. 정규화: 기본 정규형

8.3.4 제3정규형

제3정규형 문제점 해결

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

8.3. 정규화: 기본 정규형

8.3.4 제3정규형

제3정규형 문제점 해결

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

8.3. 정규화: 기본 정규형

8.3.5 보이스코드 정규형

보이스코드 정규형 (Boyce Codd Normal Form)은 릴레이션 R의 모든 결정자가 후보키이면 릴레이션 R은 보이스코드 정규형에 속한다. 제 3정규형보다 강력하며, ‘강한 제 3 정규형’이라고도 한다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

8.3. 정규화: 기본 정규형

8.3.5 보이스코드 정규형

BCNF는 제 3정규형의 경우 여러 후보키가 존재할 때 발생할 수 있는 이상 현상을 해결하기 위해 정의되었다. 제 3정규형이더라도 기본키 속성이 기본키가 아닌 일반 속성에 종속적일 때 BCNF에 위배된다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

8.3. 정규화: 기본 정규형

8.3.5 보이스코드 정규형

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

8.3. 정규화: 기본 정규형

8.3.6 정규화의 적용

정규화는 릴레이션을 정보 표현 측면에서 동등하면서도 중복을 감소시키는 더 작은 릴레이션으로 무손실 분해하여 이상 현상을 제거하는 데이터베이스 설계 방법이다.

​

8.3. 정규화: 기본 정규형

8.3.6 정규화의 적용

​

8.3. 정규화: 기본 정규형

8.3.6 정규화의 적용

반정규화

반정규화(de-normalization)는 정규화의 반대 개념으로 ‘역정규화’라고도 한다. 정 규화와는 반대로 보다 낮은 수준의 정규형으로 릴레이션을 통합하는 것이다.

반정규화는 다음과 같은 다양한 과정을 포함한다.

• 릴레이션들을병합
• 통계
• 이력 릴레이션을 추가
• 여러 릴레이션에 같은 속성을 중복하여 추가
• 총계·평균같은파생 속성을추가 반정규화는 데이터베이스 설계의 최종 단계에서 신중하게 고려한다.

​

​

데이터베이스

연습문제

연습문제

연습문제

09

E-R 모델

• E-R 모델
• E-R 다이어그램

​

학습목표

​

• E-R 모델의 기본 개념을 이해한다.
• 개체, 속성, 관계의 유형을 살펴본다.
• E-R 다이어그램 표기법을 이해하고 작성 방법을 알아본다.

​

p. 315-340

9.1. E-R 모델

현실 세계의 실체를 개체, 관계, 속성으로 표현하는 것이 E-R 모델의 핵심이다. 이 모델은 데이터베이스가 표현해야 하는 대상을 단순한 기호로 나타내며, 사용자와 개발자가 쉽게 소통할 수 있도록 돕는다.

​

​

​

​

9.1. E-R 모델

9.1.1. E-R 모델과 E-R 다이어그램

E-R 모델은 1976년 피터 첸이 제안한 개념적 모델링 방법이다. 이 모델의 장점은 그래픽 기호로 표현되는 E-R 다이어그램을 통해 이해하기 쉽게 만드는 것이다. 주요 요소는 사각형으로 표현되는 개체, 마름모로 표현되는 관계, 타원으로 표현되는 속성이다.

​

​

​

​

​

9.1. E-R 모델

9.1.2 개체

개체는 현실 세계에서 저장할 가치가 있는 데이터를 나타내며, 사람, 사물, 장소, 추상적 개념을 포함한다. 데이터베이스에서는 개체의 공통 특성을 모아 구조를 정의한다. 개체는 속성으로 구별되며, 각 속성에 대응하는 값을 정의하여 개체 인스턴스를 형성한다.

​

​

​

​

​

9.1. E-R 모델

9.1.2 개체

개체와 개체 타입, 개체 집합의 차이

개체는 실제 존재를 의미하고, 개체 집합은 동일 유형의 개체 인스턴스를, 개체 타입은 데이터베이스에 저장될 공통 특성만을 정의한 것이다.

​

​

​

​

​

​

9.1. E-R 모델

9.1.2 개체

관계형 모델과의 관계

• 개체는 투플,
• 개체 타입은 릴레이션 스키마,
• 개체 집합은 릴레이션 인스턴스와 대응된다.

​

​

​

​

​

​

​

9.1. E-R 모델

9.1.3 속성

속성은 개체나 관계의 고유한 특성이다.

1. 단일 값 속성(단일 값 가짐),
2. 다중 값 속성(여러 값 가짐),
3. 단순 속성(더 분해할 수 없음),
4. 복합 속성(분해 가능),
5. 저장 속성(값 저장),
6. 유도 속성(다른 속성에서 유도 가능),
7. 키 속성(고유 값 보유)으로 나뉜다.

​

​

​

​

​

​

​

​

​

9.1. E-R 모델

9.1.3 속성

1) 단일 값 속성과 다중 값 속성

특정 속성이 갖는 값이 하나이면 단일 값 속성(single-valued attribute)이라 한다. 보통 기본(default) 속성이 단일 값 속성이며 실선 타원으로 표시한다. 만약 개체가 갖는 속성 값이 여러 개이면 다중 값 속성(multivalued attribute)이며 이종 실선의 타원으로 표시한다.

​

​

​

​

​

​

​

​

​

​

9.1. E-R 모델

9.1.3 속성

2) 단순 속성과 복합 속성

단순 속성(simple attribute)은 의미적으로 더 이상 분해할 수 없는 속성이다. 기본 속성으로 대부분의 속성이 이에 속한다. 복합 속성(composite attribute)은 둘 이상의 속성으로 이루어져 의미적으로 더 작은 단위로 분해가 가능한 속성이다. 타원 모양의 상위 속성과 하위 속성을 실선 링크로 연결한다.

​

​

​

​

​

​

​

​

​

​

​

9.1. E-R 모델

9.1.3 속성

3) 저장 속성과 유도 속성

저장 속성(stored attribute)은 실제 값을 저장하는 속성이다. 기본 속성으로 대부분의 속성이 저장 속성이다. 유도 속성(derived attribute)은 값을 저장하지 않아도 다른 속성 값에서 계산되거나 유도될 수 있는 속성이다. 유도 속성은 E-R 다이어그램에서 점선의 타원으로 표시한다.

​

​

​

​

​

​

​

​

​

​

​

​

9.1. E-R 모델

9.1.3 속성

4) 키 속성

속성은 키 속성과 일반 속성으로 구분한다. 키 속성(key attribute)은 각 개체를 유일하게 식별할 수 있는 고유한 값을 갖는 속성이다. E-R 다이어그램에서 키 속성은 밑줄을 그어 표시한다.

​

​

​

​

​

​

​

​

​

​

​

​

​

9.1. E-R 모델

9.1.4 관계

관계는 개체 사이의 연관성을 나타낸다. 개체는 독립적 존재지만 관계는 개체 없이는 존재할 수 없다. 관계는 개체 타입들 사이의 연관성을 정의하며, 개체 간 상호 관계를 통해 의미를 확장할 수 있다.

​

​

​

​

​

​

​

​

​

​

9.1. E-R 모델

9.1.4 관계

​

​

​

​

​

​

​

​

​

​

9.1. E-R 모델

9.1.5 관계의 유형

사람과 사람, 사람과 사물, 사물과 사물 등 다양한 개체 간의 관계가 존재하며, 관계의 유형은 몇 가지로 제한할 수 있다.

​

​

​

​

​

​

​

​

​

9.1. E-R 모델

9.1.5 관계의 유형

분류기준1: 관계 카디널리티

최대 사상수: 관계에서 특정 개체와 연결된 상대 개체의 최대 수를 표시하며, 유형은

• 일대일,
• 일대다,
• 다대일,
• 다대다로 나뉜다.

​

​

​

​

​

​

​

​

​

9.1. E-R 모델

9.1.5 관계의 유형

분류기준1: 관계 카디널리티

최대 사상수: 관계에서 특정 개체와 연결된 상대 개체의 최대 수를 표시하며, 유형은

• 일대일,
• 일대다,
• 다대일,
• 다대다로 나뉜다.

​

​

​

​

​

​

​

​

​

9.1. E-R 모델

9.1.5 관계의 유형

분류기준1: 관계 카디널리티

최대 사상수: 관계에서 특정 개체와 연결된 상대 개체의 최대 수를 표시하며, 유형은

• 일대일,
• 일대다,
• 다대일,
• 다대다로 나뉜다.

​

​

​

​

​

​

​

​

​

9.1. E-R 모델

9.1.5 관계의 유형

분류기준1: 관계 카디널리티

최대 사상수: 관계에서 특정 개체와 연결된 상대 개체의 최대 수를 표시하며, 유형은

• 일대일,
• 일대다,
• 다대일,
• 다대다로 나뉜다.

​

​

​

​

​

​

​

​

​

9.1. E-R 모델

9.1.5 관계의 유형

분류기준1: 관계 카디널리티

최소 사상수: 특정 개체가 관계를 맺어야 하는 최소 수를 표시하며, 전체 참여(최소값 1)와 부분 참여(최소값 0)로 나뉜다.

• 최소값 1 인 경우(전체 참여)
• 최소값 0인 경우(부분 참여)

​

​

​

​

​

​

​

​

​

​

9.1. E-R 모델

9.1.5 관계의 유형

분류기준1: 관계 카디널리티

최소 사상수: 특정 개체가 관계를 맺어야 하는 최소 수를 표시하며, 전체 참여(최소값 1)와 부분 참여(최소값 0)로 나뉜다.

• 최소값 1 인 경우(전체 참여)
• 최소값 0인 경우(부분 참여)

​

​

​

​

​

​

​

​

​

​

9.1. E-R 모델

9.1.5 관계의 유형

분류기준2: 관계차수

• 1진관계: 개체가 자기 자신과 관계를 맺는 순환 관계.
• 2진관계: 두 개체가 맺는 일반적인 관계.
• 3진관계: 세 개체가 함께 관계를 맺는 형태.

​

​

​

​

​

​

​

​

​

​

9.1. E-R 모델

9.1.5 관계의 유형

분류기준3: 관계의 종속성

• 비식별 관계: 독립적인 개체 간의 대등한 관계.
• 식별 관계: 한 개체가 다른 개체에 종속적인 관계. 예: 직원과 부양가족 관계.
• 강 개체와 약 개체: 강 개체는 고유 식별 속성을 가진 개체이며, 약 개체는 강 개체에 의존해 식별된다. 약 개체는 부분키 속성으로 식별되며, 강 개체와 결합하여 키로 사용된다.
• 일반화 관계: 상하위 관계를 나타내며 ‘IS-A 관계’라고도 한다. 상위 개체는 공통 속성을, 하위 개체는 고유 속성을 갖는다. �예: 상위 개체인 ‘학생’과 하위 개체인 ‘학부생’, ‘대학원생’.

​

​

​

​

​

​

​

​

​

​

9.1. E-R 모델

9.1.5 관계의 유형

​

​

​

​

​

​

​

​

​

​

9.1. E-R 모델

9.1.5 관계의 유형

E-R 다이어그램 표기법

개체와 관계는 각각 고유한 표기법으로 E-R 다이어그램에 표시되며, 다양한 관계와 개체 간의 관계를 시각적으로 나타낸다.

​

​

​

​

​

​

​

​

​

9.2. E-R 다이어그램

지금까지 살펴본 E-R 다이어그램의 기호들을 정리하고 실제 예시를 통해 적용 방법을 이해해 보자.

​

​

​

​

​

​

​

​

​

9.2. E-R 다이어그램

9.2.1 E-R 다이어그램의 표기법 요약

초기 E-R 다이어그램은 사각형, 마름모, 타원, 그리고 연결 선으로만 구성되었지만, 더 상세하고 정확한 모델링을 위해 다양한 기호가 추가되며 확장되었다. 표기법 요약은 <표 9-1>에 있다. 다이어그램 작성 시, 기호의 의미와 제한 사항을 충분히 이해하지 못해 흔히 발생하는 오류들이 있다.

​

​

​

​

​

​

​

​

9.2. E-R 다이어그램

9.2.1 E-R 다이어그램의 표기법 요약

[그림 9-24]는 올바른 표기법과 잘못된 예시를 보여준다. 속성, 개체, 관계가 직접 링크로 연결될 수 없으며, 관계는 최소 두 개 이상의 개체와 연결되어야 한다.

​

​

​

​

​

​

​

​

​

9.2. E-R 다이어그램

9.2.2 E-R 다이어그램의 작성 예

수강 신청 데이터베이스를 위한 간단한 E-R 다이어그램을 작성해 보자. ‘교수’, ‘강의실’, ‘교과목’ 개체를 도출하여 사각형으로 표시하고, ‘강의’를 관계로 추가하며 속성도 연결한다.

​

​

​

​

​

​

9.2. E-R 다이어그램

9.2.2 E-R 다이어그램의 작성 예

‘교과목’ 개체에 ‘학생’을 추가하고, ‘수강신청’, ‘수강취소’ 관계를 연결하며, 신청일자와 취소일자 속성도 추가한다.

​

​

​

​

​

9.2. E-R 다이어그램

9.2.2 E-R 다이어그램의 작성 예

‘학생’ 개체에 ‘보호자’ 개체를 추가하고 ‘보호’ 관계를 연결하며 이름과 관계 속성을 포함한다. 이 과정을 통해 수강 신청 E-R 다이어그램의 완성본을 [그림 9-26]에서 확인할 수 있다.

​

​

​

​

​

​

​

​

​

​

9.2. E-R 다이어그램

9.2.2 E-R 다이어그램의 작성 예

완성된 E-R 다이어그램에서는 누락된 키 속성 및 카디널리티 표시를 확인하여 각 개체와 관계가 올바르게 연결되었는지 점검한다.

​

​

​

​

​

​

​

​

​

​

​

데이터베이스

연습문제

연습문제

10

데이터베이스 설계

• 데이터베이스 설계
• 요구사항 분석
• 개념적 설계
• 논리적 설계
• ERwin 실습

​

학습목표

​

• 데이터베이스 설계 과정을 이해한다.
• 요구사항 분석, 개념적 설계, 논리적 설계 과정을 이해하고 적용 방법을 알아본다.
• ERwin 활용 방법을 학습하고 IE 표가법의 적용 방법을 알아본다.

​

p. 341-377

10.1. 데이터베이스 설계

데이터베이스 설계는 정보 시스템 개발 과정에서 핵심적인 기초 단계입니다. 건축물 설계 도면을 작성하는 것처럼 데이터베이스 설계는 매우 중요합니다. 이 과정에서는 데이터베이스 설계 과정과 예시를 알아봅니다.

10.1.1 데이터 모델링과 데이터 모델

데이터베이스는 현실 세계를 빠르고 정확하게 반영해야 하기 때문에 구조가 매우 중요합니다.

10.1. 데이터베이스 설계

10.1.1 데이터 모델링과 데이터 모델

데이터 모델링

개발자들은 경험에 의존하여 데이터베이스 구조를 쉽게 결정하려 하지만, 이는 어려운 작업입니다. 데이터베이스 모델링은 데이터베이스 구조를 체계적으로 설계하기 위해 필요한 절차입니다. 데이터 모델링은 개념적 모델링, 논리적 모델링, 물리적 모델링의 세 단계로 이루어집니다. 각 단계에서는 다양한 데이터 모델을 사용하여 데이터베이스 구조를 명세화합니다.

​

​

​

​

​

​

​

10.1. 데이터베이스 설계

10.1.1 데이터 모델링과 데이터 모델

데이터 모델 종류

1. 개념적 데이터 모델링

사용자의 요구 사항을 분석하는 단계로, E-R 모델을 사용하여 개체(Entity)와 관계(Relationship)를 표현합니다.

​

​

​

10.1. 데이터베이스 설계

10.1.1 데이터 모델링과 데이터 모델

데이터 모델 종류

• 논리적 데이터 모델링

개념적 모델을 논리적 데이터 모델로 변환하여, 특정 DBMS와 독립적으로 관계형 데이터베이스 구조를 설계합니다.

​

​

​

​

​

​

​

​

10.1. 데이터베이스 설계

10.1.1 데이터 모델링과 데이터 모델

데이터 모델 종류

• 물리적 데이터 모델링

논리적 데이터 모델을 특정 DBMS에 맞게 최적화하여 물리적인 데이터 구조를 명세화합니다.

​

​

​

​

​

​

​

​

10.1. 데이터베이스 설계

10.1.2 데이터베이스 설계 과정

데이터베이스 설계는 총 5단계로 진행되며, 각각의 단계는 설계 품질을 높이기 위해 반복적 검토가 이루어질 수 있습니다.

1. 요구사항 분석

사용자 요구사항을 수집하고 분석하여 요구사항 명세서를 작성합니다.

• 개념적 설계

요구사항 명세서를 기반으로 E-R 다이어그램을 작성하여 개념적 스키마를 완성합니다.

10.1. 데이터베이스 설계

10.1.2 데이터베이스 설계 과정

3. 논리적 설계

E-R 다이어그램을 논리적 스키마로 변환하고, 관계형 데이터 모델에 맞게 릴레이션을 정의합니다.

• 물리적 설계

논리적 스키마를 바탕으로 DBMS의 특성에 맞는 내부 저장 구조와 접근 방식을 설계합니다.

• 구현

물리적 스키마를 SQL 명령문을 통해 실제 데이터베이스로 구현합니다.

이 과정은 단계별로 검증과 보완이 이루어지며, 최종적으로 정제된 설계 결과를 도출합니다.

​

​

​

​

​

​

​

​

10.1. 데이터베이스 설계

10.1.2 데이터베이스 설계 과정

핵심 요약

데이터베이스 모델링은 E-R 다이어그램을 작성하는 개념적 모델링에 중점을 두며, 데이터베이스 설계는 이를 논리적 데이터 모델로 변환하는 논리적 데이터 설계에 중점을 둡니다.

​

​

​

​

​

​

​

​

​

10.2. 요구사항분석

데이터베이스 설계 과정의 첫 단계인 요구사항 명세서를 작성하며, 병원 데이터베이스 구축을 예시로 간단한 논리적 스키마 설계를 시작한다.

10.2.1 요구사항 명세

데이터베이스의 구현 범위와 사용자를 결정하고, 예비 사용자들로부터 수집한 요구 사항을 분석하여 문서화한다.

분석가는 사용자의 요구 사항을 정확히 반영한 명세서를 작성하며, 최종적으로 사용자의 확인을 받는다.

​

​

​

​

​

​

​

​

​

​

10.2. 요구사항분석

10.2.2 요구사항 명세서(병원 DB)의 작성

• 병원 의사들은 진료과에 소속되며, 전문의와 전공의(인턴, 레지던트)로 구분된다.
• 환자는 여러 의사로부터 진료를 받으며, 진료 기록이 유지된다.
• 수술 환자는 입원하며 입원 날짜와 퇴원 날짜가 기록된다.
• 간병인은 1명의 환자만 간병할 수 있으며, 관련 정보가 관리된다.
• 병실과 침대는 각각 고유한 번호와 추가 정보가 관리된다.
• 모든 의사와 환자는 고유한 번호와 관련 정보를 보유한다.

​

​

​

​

​

​

​

​

​

​

10.2. 요구사항분석

10.2.2 요구사항 명세서(병원 DB)의 작성

​

​

​

​

​

​

​

​

​

​

​

10.3. 개념적 설계

개념적 설계 단계에서는 데이터베이스의 전체 구조를 결정하고, E-R 다이어그램을 작성한다. 요구사항 명세서로부터 개체, 관계, 속성을 도출하여 표현한다.

​

​

​

​

​

​

​

​

​

​

​

​

10.3. 개념적 설계

10.3.1 개체 정의

• 개체(Entity)는 저장할 가치가 있는 핵심 데이터를 가진 사람, 사물, 장소 등을 의미하며, 요구사항 명세서의 명사에서 도출한다.
• 개체는 독립적이며 지속적인 존재로, 고유한 명칭(번호, 이름 등)을 가진다.
• 병원 DB에서는 의사, 환자, 병실, 간병인 등이 개체로 정의될 수 있다.

​

​

​

​

​

​

​

​

​

​

10.3. 개념적 설계

10.3.2 관계 정의

• 관계(Relationship)는 두 개 이상의 개체 간의 연관성을 의미하며, 요구사항 명세서의 동사에서 도출된다.
• 예를 들어, 환자가 진료를 받는다는 관계는 환자와 의사 개체 간의 연관성을 나타낸다.
• 관계는 개체와 비교할 때 일시적이며, 짧은 시간 동안 지속되는 특성이 있다.

​

​

​

​

​

​

​

​

​

​

10.3. 개념적 설계

10.3.3 속성 정의

• 속성(Attribute)은 개체나 관계의 특성을 나타내는 요소로, 주어, 목적어, 서술어를 꾸며주는 하위 명사에서 도출된다.
• 속성은 실세계에서 종속적이며, 상위 개념의 명사나 동사를 수식한다.
• 예를 들어, 환자의 '이름', '나이', 병실의 '번호' 등이 속성으로 정의될 수 있다.

​

​

​

​

​

​

​

​

​

​

10.3. 개념적 설계

10.3.4 E-R 다이어그램 작성

요구사항 명세서에서 도출한 개체, 관계, 속성을 기반으로 E-R 다이어그램을 작성한다.

개체는 사각형, 관계는 마름모, 속성은 타원형으로 표현하며, 중복되는 용어는 하나의 표준 용어로 통일한다.

​

​

​

​

​

​

​

​

​

​

10.3. 개념적 설계

10.3.4 E-R 다이어그램 작성

E-R 다이어그램 작성 과정에서는 명세서의 문장을 데이터 중심의 관점에서 분석하고, 최종적으로 사용자의 요구사항을 완전히 반영하도록 한다.

​

​

​

​

​

​

​

​

​

​

10.3. 개념적 설계

10.3.4 E-R 다이어그램 작성

병원 데이터베이스의 E-R 다이어그램 예시는 환자, 의사, 병실, 진료 등의 관계와 속성을 시각적으로 표현한 결과이다.

​

​

​

​

​

​

​

​

​

​

10.4. 논리적 설계

논리적 설계 단계에서는 개념적 설계에서 만들어진 E-R 다이어그램을 특정 데이터 모델(주로 관계형 데이터 모델)에 따라 논리적 스키마로 변환합니다.

관계형 데이터베이스에서는 모든 개체와 관계를 릴레이션으로 표현하므로 E-R 다이어그램을 릴레이션 스키마로 변환하는 과정이 필요합니다.

​

​

​

​

​

​

​

​

​

​

​

10.4. 논리적 설계

10.4.1 개체 변환

개체는 기본적으로 하나의 릴레이션으로 변환되며, 이 릴레이션을 '개체 릴레이션'이라 부릅니다.

개체의 키 속성은 릴레이션의 기본키로, 일반 속성은 릴레이션의 속성으로 변환됩니다.

예시: '의사' 개체는 '의사번호', '이름', '진료과목' 속성을 포함한 '의사' 릴레이션으로 변환되며, '의사번호'가 기본키가 됩니다.

​

​

​

​

​

​

​

​

​

​

​

10.4. 논리적 설계

10.4.2 관계 변환

관계는 관계의 카디널리티(1:n, 1:1, m:n)에 따라 변환 과정이 다릅니다.

일대다(1:n) 관계: '일'측 개체의 기본키를 '다'측 개체 릴레이션의 외래키로 추가하여 변환합니다. 예를 들어, '진료과'의 '과번호'를 '의사' 릴레이션에 '소속진료과번호'로 추가하고 외래키로 정의합니다.

​

​

​

​

​

​

​

​

​

​

​

​

10.4. 논리적 설계

10.4.2 관계 변환

관계는 관계의 카디널리티(1:n, 1:1, m:n)에 따라 변환 과정이 다릅니다.

일대일(1:1) 관계: 한쪽 릴레이션의 기본키를 다른 쪽 릴레이션의 외래키로 추가합니다. 양쪽 모두 외래키를 가질 필요는 없으며, 데이터 중복을 피하기 위해 한쪽만 외래키로 정의할 수 있습니다.

​

​

​

​

​

​

​

​

​

​

​

​

10.4. 논리적 설계

10.4.2 관계 변환

관계는 관계의 카디널리티(1:n, 1:1, m:n)에 따라 변환 과정이 다릅니다.

다대다(m:n) 관계: 다대다 관계는 독립된 새로운 릴레이션으로 변환되며, 관계의 두 개체 릴레이션의 기본키를 외래키로 포함합니다. 이 외래키들의 조합을 새로운 릴레이션의 기본키로 지정합니다.

예시: '진료' 릴레이션은 '의사번호'와 '환자주민등록번호'를 외래키로 가지며, 이 두 속성의 조합이 기본키가 됩니다.

​

​

​

​

​

​

​

​

​

​

​

10.4. 논리적 설계

10.4.3 논리적 스키마 작성

개념적 설계의 E-R 다이어그램을 논리적 데이터베이스 스키마로 변환한 최종 결과물은 물리적 설계 단계로 이어집니다. 물리적 설계에서는 논리적 설계 결과를 DBMS의 특성에 맞춰 열의 데이터 유형, 크기, 제약 조건, 인덱스 등을 정의하며, 역정규화도 고려할 수 있습니다.

​

​

​

​

​

​

​

​

​

​

​

​

​

10.4. 논리적 설계

10.4.3 논리적 스키마 작성

논리적 설계와 물리적 설계를 통해 DBMS에 실제 저장 구조를 생성할 수 있으며, 이 과정은 많은 경험을 필요로 합니다. 설계 단계에서 해석과 주관적인 해결 방안이 다를 수 있어 일관된 결과를 얻기 어려운 경우도 있습니다.

​

​

​

​

​

​

​

​

​

​

​

​

​

10.5. ERwin 실습

ERwin은 ER 다이어그램을 작성하기 위한 대표적인 데이터 모델링 도구입니다. ERwin에서는 논리적 모델링과 물리적 모델링을 통합하여 작업할 수 있습니다.

ERwin 대신 erdplus.com을 상요하겠습니다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

10.5. ERwin 실습

10.5.1 ERwin의 기본 화면 구성

• 메뉴 영역(화면 맨 위쪽): ERwin의 전반적인 기능을 수행한다.
• 툴바 영역(화면 위쪽): ER 다이어그램을 그리기 위해 필요한 도구 및 메뉴 모음이다.
• 다이어그램 작성 영역(화면 중앙): ER 다이어그램을 그리는 작업 영역이다.
• 모델 탐색기 영역(화면 왼쪽): 다이어그램의 속성을 확인하거나 변경한다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

10.5. ERwin 실습

10.5.1 ERwin의 기본 화면 구성

• 개체 (Entity): 개체 유형의 이름, 식별자, 속성을 표현한다.
• 서브 타입 (Sub-Category): IS-A 관계를 갖는 슈퍼(상위) 개체와 서브(하위) 개체를 개체 간의 부모와 자식 관계로 표현한다.
• 일대다 식별(Identifying) 관계: 두 개체 사이의 1:n 식별 관계를 표현한다.
• 일대다 비식별(Non-Identifying) 관계: 두 개체 사이의 1:n 비식별 관계를 표현한다.
• 다대다 식별(Many-to-Many) 관계: 두 개체 사이의 m:n 식별 관계를 표현한다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

10.5. ERwin 실습

10.5.2 ERwin의 기본 환경 설정

​

​

​

​

​

​

​

​

​

​

​

​

​

​

10.5. ERwin 실습

10.5.2 ERwin의 기본 환경 설정

1) 적용할 모델의 유형과 대상 DBMS의 종류를 선택한다.

​

​

​

​

​

​

​

​

​

​

​

​

​

10.5. ERwin 실습

10.5.2 ERwin의 기본 환경 설정

2) 1E 표기법으로 변경한다.

​

​

​

​

​

​

​

​

​

​

​

​

​

10.5. ERwin 실습

10.5.2 ERwin의 기본 환경 설정

​

​

​

​

​

​

​

​

​

​

​

​

​

10.5. ERwin 실습

10.5.3 IE 표기법

9장과 10장에서 사용된 E-R 모델 표기법은 피터 첸(Peter Chen)의 고전적인 방법입니다.

다양한 데이터 모델링 도구에서 IE(Information Engineering) 표기법과 바커(Baker) 표기법 등을 제공합니다. 이 책에서는 ERwin의 IE 표기법을 사용한 ER 다이어그램 작성 방법을 설명합니다.

여기서는 기존의 '개체' 대신 '엔터티'라는 용어를 사용하고, 'E-R 다이어그램' 대신 'ER 다이어그램'이라고 표기합니다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

10.5. ERwin 실습

10.5.3 IE 표기법

엔터티 표현

IE 표기법에서는 엔터티와 속성을 사각형으로 표현하며, 사각형은 세 부분으로 나뉩니다.

• 위쪽 영역: 엔터티 이름을 명시
• 중간 영역: 기본 키 속성 입력
• 아래쪽 영역: 나머지 속성 입력

[그림 10-16]에서 기존 E-R 표기법과 IE 표기법을 비교할 수 있습니다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

10.5. ERwin 실습

10.5.3 IE 표기법

엔터티 표현

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

10.5. ERwin 실습

10.5.3 IE 표기법

관계선 표현

IE 표기법에서는 마름모 대신 관계선을 사용해 엔터티를 연결하며, 다양한 기호를 통해 관계의 카디널리티(참여도)를 표현합니다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

10.5. ERwin 실습

10.5.3 IE 표기법

관계선 표현

1. 'Non-identifying'과 'Identifying' 관계
1. Non-identifying: 비식별 관계로, 점선으로 표시합니다. 자식 엔터티에는 외래키 속성이 자동 추가됩니다.
2. Identifying: 식별 관계로, 실선과 둥근 사각형으로 표시하며, 외래키 속성이 키 속성으로 추가됩니다.
3. 식별 관계는 약한 엔터티(둥근 사각형)로, 비식별 관계는 강한 엔터티(직사각형)로 표시됩니다.

10.5. ERwin 실습

10.5.3 IE 표기법

관계선 표현

2. 'Nulls Allowed'와 'Nulls Not Allowed'
1. Nulls Allowed: 외래키 속성의 널 값 허용, 부모 엔터티 연결선 끝에 'o' 기호가 표시됨. 자식 엔터티의 관계 참여가 선택적임을 의미.
2. Nulls Not Allowed: 외래키 속성의 널 값 비허용, 'I' 기호가 표시되며 자식 엔터티의 관계 참여가 필수임을 의미.

10.5. ERwin 실습

10.5.3 IE 표기법

관계선 표현

3. 'Zero or One', 'One or More', 'Zero, One or More'
1. Zero, One or More: 0 이상, 선택 참여임을 의미하며, 'n' 기호로 표시.
2. One or More: 1 이상, 필수 참여로 '+' 기호로 표시.
3. Zero or One: 0 또는 1, 선택 참여임을 의미하며, '-' 기호로 표시.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

10.5. ERwin 실습

10.5.3 IE 표기법

관계선 표현

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

10.5. ERwin 실습

10.5.3 IE 표기법

관계선의 유형

[그림 10-17]에서는 다양한 관계선 유형을 보여줍니다.

부모 엔터티에서 자식 엔터티로 일대일 또는 일대다 관계를 표현하며, 'I' 기호는 1, 'n' 기호는 다수를 나타냅니다.

'o' 기호는 부분 참여를 의미하고, 기호가 없으면 전체 참여를 의미합니다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

10.5. ERwin 실습

10.5.4 1E 표기법의 적용 예

IE 표기법에 따른 엔터티와 다양한 관계 카디널리티를 갖는 관계선의 표현 예제를 살펴보자.

일대일 (1:1) 관계 예

'간병' 관계는 강 엔터티 간의 관계이므로 IE 표기법에서 비식별(non-identifying) 관계선인 점선으로 연결된다. ‘간병인’ 엔터티는 선택적인 관계를 표현하고, '환자' 엔터티는 최대 1명의 간병인만을 가질 수 있는 선택적 관계를 표현한다. ‘간병인’ 엔터티의 기본 키는 ‘환자’ 엔터티의 외래 키로 자동 추가된다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

10.5. ERwin 실습

10.5.4 1E 표기법의 적용 예

IE 표기법에 따른 엔터티와 다양한 관계 카디널리티를 갖는 관계선의 표현 예제를 살펴보자.

일대다(1:n) 관계 예

'소속' 관계는 점선으로 연결된다. ‘진료과’ 엔터티는 필수적으로 의사에게 소속되어야 하고, 의사는 여러 진료과에 소속될 수 있다. 자동으로 추가된 외래 키 속성은 ‘소속진료과번호’로 변경된다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

10.5. ERwin 실습

10.5.4 1E 표기법의 적용 예

IE 표기법에 따른 엔터티와 다양한 관계 카디널리티를 갖는 관계선의 표현 예제를 살펴보자.

다대다(m:n) 관계 예

다대다 관계는 중간 엔터티를 통해 변환된다. 예를 들어 ‘의사’와 ‘환자’ 간의 관계는 ‘진료’라는 중간 엔터티를 통해 표현된다. 각 엔터티의 기본 키는 중간 엔터티의 외래 키로 자동 추가된다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

10.5. ERwin 실습

10.5.4 1E 표기법의 적용 예

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

10.5. ERwin 실습

10.5.4 1E 표기법의 적용 예

순환관계 예

엔터티가 자신과 관계를 맺는 순환 관계는 비식별 관계로 실선으로 연결된다. 예를 들어, ‘의사’ 엔터티는 자신과 순환 관계를 맺고, 지도 교수를 선택적으로 가질 수 있다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

10.5. ERwin 실습

10.5.4 1E 표기법의 적용 예

약엔터티의 식별 관계 예

'보유' 관계는 식별 관계로 실선으로 연결된다. ‘병실’과 ‘침대’는 병실번호를 기본 키로 공유하며, ‘침대’ 엔터티의 기본 키는 ‘병실’ 엔터티의 외래 키로 추가된다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

10.5. ERwin 실습

10.5.4 1E 표기법의 적용 예

일반화관계 예

상위 엔터티와 하위 엔터티 간의 일반화 관계는 실선으로 연결된다. 상위 엔터티의 키 속성은 하위 엔터티의 키 속성으로 상속된다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

10.5. ERwin 실습

10.5.4 1E 표기법의 적용 예

ERwin을 이용한 IE 표기법 변환

논리적 모델 변환

ERwin을 이용해 IE 논리적 모델로 변환할 수 있으며, 이를 통해 전체 스키마 구조를 직관적으로 파악할 수 있다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

10.5. ERwin 실습

10.5.4 1E 표기법의 적용 예

ERwin을 이용한 IE 표기법 변환

논리적 모델 변환

ERwin을 이용해 IE 논리적 모델로 변환할 수 있으며, 이를 통해 전체 스키마 구조를 직관적으로 파악할 수 있다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

10.5. ERwin 실습

10.5.4 1E 표기법의 적용 예

ERwin을 이용한 IE 표기법 변환

물리적 모델 변환

ERwin의 논리적 모델을 기반으로 물리적 모델을 쉽게 변환할 수 있다. 물리적 모델은 데이터 유형과 같은 속성을 추가하여 실제 DBMS의 테이블 구조를 표현한다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

10.5. ERwin 실습

10.5.4 1E 표기법의 적용 예

SQL 자동생성

ERwin에서 정의된 물리적 모델은 SQL 명령문을 자동으로 생성하여 실제 데이터베이스의 테이블을 만들 수 있다. 이를 통해 Oracle DBMS에서 사용할 수 있는 스키마 생성 SQL을 자동으로 생성한다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

데이터베이스

연습문제

연습문제

11

데이터웨어하우스와 데이터베이스 응용

• 데이터웨어하우스 개념
• 데이터웨어하우스 설계
• OLAP
• 데이터베이스응용

​

학습목표

​

• 데이터웨어하우스의 출현 배경과 특성을 이해한다
• 다차원 모델링과 스타스키마 설계 방법을 알아본다.
• OLAP의 특성과 종류, 인터페이스를 알아본다
• 다양한 데이터베이스 응용에 대해 알아본다.

​

p. 380-420

11.1. 데이터웨어하우스 개념

11.1.1 데이터웨어하우스의 출현 배경

데이터베이스에 많은 데이터가 축적되면서 의사결정을 돕는 ‘데이터웨어하우스’가 등장했습니다. 기존 정보 시스템의 문제는 다음과 같습니다:

• 비통합성
• 비일관성
• 비신뢰성
• 단기성
• 비생산성

​

11.1. 데이터웨어하우스 개념

11.1.1 데이터웨어하우스의 출현 배경

• 비통합성: 데이터가 통합되지 않아 분석에 시간이 소요됩니다.
• 비일관성: 중복된 데이터가 많아 혼란이 발생합니다.
• 비신뢰성: 데이터 간 불일치로 의사결정이 어려워집니다.
• 단기성: 장기적인 데이터가 부족해 추세 분석이 어렵습니다.
• 비생산성: 많은 개발 비용이 필요합니다.

​

11.1. 데이터웨어하우스 개념

11.1.1 데이터웨어하우스의 출현 배경

데이터베이스는 즉각적인 업무 처리를 위한 OLTP(Online Transaction Processing) 환경에적합한 데이터 저장소이다. 신속한 데이터 처리에 비해 상대적으로 데이터 분석은 느리고많은 제한을 가지므로 바효율적이다.

해결 방안은 업무용 데이터와 분석용 데이터의 저장소를 분리하는 것이다. 데이터베이스는 업무 트랜잭션 처리를 위한 운영 저장소로 사용하고 분석을 위한 새로운 저장소를 구축하는 방식인데 바로 데이터웨어하우스이다.

​

11.1. 데이터웨어하우스 개념

11.1.2 데이터웨어하우스의 정의

데이터웨어하우스는 의사결정을 위한 통합 데이터 저장소입니다. 주요 특성은 다음과 같습니다:

• 주제 지향성: 특정 주제를 중심으로 구성된 데이터 구조입니다.

대학의 예를 들면, 데이터웨어하우스는 학생, 교수, 과목, 학과 등 분석하고자 하는 주제 중심으로 구성된다. 주제별로 요약되어 있어 학과뿐만 아니라 학생별 교수별 과목별로 다양한 분석이 가능하다.

​

​

​

11.1. 데이터웨어하우스 개념

11.1.2 데이터웨어하우스의 정의

데이터웨어하우스는 의사결정을 위한 통합 데이터 저장소입니다. 주요 특성은 다음과 같습니다:

• 통합성: 다양한 형식의 데이터를 통일된 형식으로 변환해 통합합니다.

남녀 성별 데이터의 경우, ‘m’과 ‘f' 또는 ‘1’과 ‘0', ‘남’과 ‘여’, ‘male’과'female' 등 다양하다. 분석을 위해서는 하나의 통일된 형식으로 변환이 필요하다.

​

​

​

11.1. 데이터웨어하우스 개념

11.1.2 데이터웨어하우스의 정의

데이터웨어하우스는 의사결정을 위한 통합 데이터 저장소입니다. 주요 특성은 다음과 같습니다:

• 시계열성: 과거부터 현재까지의 데이터가 모두 포함되어 추세 분석이 가능합니다.

과거부터 현재까지 여러 시점의 데이터가 모두 의미가 있다.추이 분석을 위해서는 각 시점에서의 데이터 버전 즉, 스냅샷(snapshot)을 저장하는 것이 중요하다.

​

​

​

​

​

11.1. 데이터웨어하우스 개념

11.1.2 데이터웨어하우스의 정의

데이터웨어하우스는 의사결정을 위한 통합 데이터 저장소입니다. 주요 특성은 다음과 같습니다:

• 비휘발성: 데이터 수정이나 삭제 없이 검색과 적재만 수행됩니다.

데이터웨어하우스는 수정이나 삭제가 거의 없는 일종의 겁색 전용 데이터베이스이다. 데이터가 일단 저장되면 검색이나 추가적 적재만 발생할 뿐 갱신과 삭제는 거의 발생하지 않는다.

​

​

​

​

​

11.1. 데이터웨어하우스 개념

11.1.2 데이터웨어하우스의 정의

데이터베이스와 데이터웨어하우스의 비교

데이터웨어하우스가 필요한 가장 큰 이유는 의사 결정에 필요한 올바른 정보(right information)를 올바른 형식(right form)으로 적시(right time)에 제공하기 위해서이다.

데이터웨어하우스는 의사 결정을 위한 맞촘 형식으로 구축되고 전적으로 데이터 분석 용도로 사용된다.

​

​

​

​

​

​

11.1. 데이터웨어하우스 개념

11.1.3 데이터웨어하우스 시스템

데이터웨어하우스 시스템은 3계층 구조로 구성됩니다:

1. 원본 데이터 계층: 운영 데이터, 비정형 데이터, 외부 데이터를 포함하며, 추출 및 변환 과정을 거칩니다.
2. 데이터 저장소 계층: 분석용 데이터를 저장하며 메타 데이터를 관리합니다.
3. 클라이언트 계층: 보고서 도구와 OLAP, 데이터 마이닝 도구 등을 포함합니다.

​

​

​

​

​

​

​

11.1. 데이터웨어하우스 개념

11.1.3 데이터웨어하우스 시스템

데이터웨어하우스 구축 방식

• 상향식: 작은 데이터 마트를 먼저 구축하고 이를 통합합니다.
• 하향식: 전사적 데이터웨어하우스를 먼저 구축한 후 데이터 마트를 추가합니다.
• 절충식: 기획은 하향식, 구축은 상향식으로 진행합니다.

데이터 마트는 일부 사용자만을 위해 주제 범위를 제한하여 구축한 작은 데이터 저장소입니다. 데이터 마트는 부서 단위로 빠르게 요구를 반영할 수 있어 인기가 높습니다.

​

​

​

​

​

​

​

​

11.1. 데이터웨어하우스 개념

11.1.3 데이터웨어하우스 시스템

데이터웨어하우스의 장점

데이터웨어하우스가 구축되면 분석 속도가 빨라지고, 수작업으로 시간이 오래 걸리던 정형 보고서도 빠르게 생성할 수 있습니다. 이는 조직의 운영과 전략을 지원하는 핵심 인프라로 자리 잡게 됩니다.

정형 보고서는 미리 개발된 고정된 형식의 보고서로, 데이터를 요약 테이블에 저장하여 빠르게 생성됩니다.

비정형 보고서는 사용자의 요청에 따라 동적으로 생성되며, 시스템 성능에 따라 시간이 더 소요될 수 있습니다.

​

​

​

​

​

​

​

11.2. 데이터웨어하우스 설계

11.2.1 다차원 모델링

다차원 모델링은 데이터베이스와 달리, 데이터웨어하우스는 데이터의 다차원성을 고려하여 구조화합니다. 이는 다양한 분석 관점에서 데이터를 조회할 수 있도록 합니다. 다차원 모델링에서는 여러 데이터 소스를 통합하고 조회 중심의 구조를 가지며, 이력 데이터를 포함하고 빠른 조회를 위해 비정규화를 활용합니다.

​

​

​

​

​

​

​

​

​

11.2. 데이터웨어하우스 설계

11.2.1 다차원 모델링

다차원 모델링 과정에서 고려해야 하는 데이터웨어하우스의 주요 특징은 다음과 같다.

• 데이터베이스 이외에도 개인 파일, 외부 매체 등의 다양한 원본으로부터 수집된 데이터들을 통합할 수 있는 구조이어야 한다.
• 데이터 변경이 아닌 조회 중심의 데이터 구조이어야 한다.
• 분석 관점에 따라 핵심 주제별로 데이터 저장소를 구성해야 한다.
• 이력 데이터의 분석이 필수이므로 대부분의 데이터 키에 시간 정보를 포함해야 한다.
• 검색 속도가 중요하므로 비정규화를 통해 데이터 중복을 허용해야 한다.
• 여러 수준으로 집계 요약한 데이터들이 다량으로 존재할 수 있어야 한다.
• 빠른 데이터 접근을 위해 상대적으로 많은 색인들이 필요하다.

​

​

​

​

​

​

​

​

​

​

11.2. 데이터웨어하우스 설계

11.2.1 다차원 모델링

다차원 데이터베이스(MDB)는 분석 전용으로 설계된 데이터베이스로, 큐브 구조를 사용하여 데이터를 저장합니다. 큐브의 셀 안에는 모든 차원 멤버의 조합에 따른 값이 저장되며, 해싱과 캐싱을 통해 빠른 검색이 가능합니다. 하지만, 차원이 많아질수록 데이터 크기가 급격히 증가하는 단점이 있습니다.

​

​

​

​

​

​

​

​

​

​

11.2. 데이터웨어하우스 설계

11.2.1 다차원 모델링

다차원 질의(Multi-dimensional query)는 데이터를 다양한 관점에서 분석할 수 있도록 하는 기능입니다. 슬라이싱(Slicing)은 큐브의 단면을 분석하고, 다이싱(Dicing)은 작은 부분 큐브를 분석합니다. 피보팅(Pivoting)은 큐브의 축을 변경하여 분석하는 방식입니다.

​

​

​

​

​

​

​

​

​

​

11.2. 데이터웨어하우스 설계

11.2.1 다차원 모델링

다차원 모델

1. 데이터 큐브는 다차원 모델의 기본 구조로, n개의 차원으로 구성된 n-차원 큐브입니다. 예를 들어, 학원의 매출 집계에서는 ‘분원’, ‘시간’, ‘강좌’의 3개 차원으로 구성된 큐브를 사용하며, 각 셀에 매출액이 저장됩니다.

​

​

​

​

​

​

​

​

​

​

​

​

11.2. 데이터웨어하우스 설계

11.2.1 다차원 모델링

다차원 모델

2. 차원(dimension)은 데이터에 대한 하나의 분석 관점 또는 분석 시각을 표현한다. 분석 관점이 다양하고 데이터 간의 상호 연관성이 높을수록 차원의 개수는 증가한다. 각 차원은 하나의 축으로 표현되기 때문에 차원의 개수에 따라 큐브의 구조가 결정된다.

​

​

​

​

​

​

​

​

​

​

​

​

11.2. 데이터웨어하우스 설계

11.2.1 다차원 모델링

다차원 모델

3. 개념 계층(Concept hierarchy)은 차원 멤버 간의 상하 관계를 나타내며, 데이터의 수준에 따라 계층적으로 구성됩니다. 예를 들어, ‘시간’ 차원은 연도, 반기, 분기, 월, 일 등의 계층 구조를 가질 수 있습니다.

​

​

​

​

​

​

​

​

​

​

​

​

11.2. 데이터웨어하우스 설계

11.2.2 스타 스키마

차원 모델링(dimensional modeling)은 관계형 스키마 구조에 차원성을 부여하는 설계 방법이다. 테이블들이 입체적인 다양한 연관성을 가질 수 있도록 주제 중심의 스키마 구조로 변환한다. 차원 모델링에 사용되는 대표적인 모델은 스타 스키마이다.

​

​

​

​

​

​

​

​

​

11.2. 데이터웨어하우스 설계

11.2.2 스타 스키마

스타 스키마(Star schema)는 관계형 데이터베이스에서 차원 모델링을 수행하는 대표적인 방식입니다. 하나의 사실 테이블(fact table)을 중심으로 여러 차원 테이블(dimension table)이 연결된 방사형 구조로, 조인 횟수를 줄여 조회 속도를 향상시킵니다.

​

​

​

​

​

​

​

​

​

​

​

11.2. 데이터웨어하우스 설계

11.2.2 스타 스키마

사실 테이블은 측정값이나 집계값을 저장하며, 예를 들어 판매량, 매출액 등이 여기에 포함됩니다. 차원 테이블은 사실 테이블의 데이터를 설명하는 특정 관점(예: 대리점명, 분기명)을 저장합니다.

​

​

​

​

​

​

​

​

​

​

​

11.2. 데이터웨어하우스 설계

11.2.2 스타 스키마

예를 들어, 대학 조직의 장학금 분석에서는 시간(연도/학기/월)과 조직(대학교/단과대학/학과)의 차원 테이블과 장학금액 등의 사실 테이블로 스키마를 구성할 수 있습니다.

​

​

​

​

​

​

​

​

​

​

​

11.2. 데이터웨어하우스 설계

11.2.2 스타 스키마

스타 스키마는 SQL을 이용하여 간단한 다차원 분석을 수행할 수 있다. 예를 들어, 연도별단과대학 장학 현황을 분석하고자 할 경우 다음과 같이 SQL문을 작성한다.

​

​

​

​

​

​

​

​

​

​

​

11.2. 데이터웨어하우스 설계

11.2.3 스노우플레이크 스키마

스노우플레이크 스키마(Snowflake Schema)는 데이터 중복을 줄이기 위해 차원 테이블을 정규화한 구조로, 스타 스키마의 변형된 형태입니다. 구조가 눈송이처럼 생겨서 스노우플레이크 스키마라고 불립니다.

예를 들어, '조직' 차원 테이블이 '학과', '단과대학', '대학교'로 나뉘며 정규화됩니다. '시간' 차원 테이블도 '월', '학기', '연도'로 분리됩니다.

​

​

​

​

​

​

​

​

​

​

​

​

11.2. 데이터웨어하우스 설계

11.2.3 스노우플레이크 스키마

이로 인해 차원 테이블이 더 세분화되어 SQL 쿼리가 복잡해질 수 있습니다.

일반적으로 스타 스키마는 응답 시간이 빠르고 구조가 간단하여 이해하기 쉬워 많이 사용됩니다.

​

​

​

​

​

​

​

​

​

​

​

​

​

11.2. 데이터웨어하우스 설계

11.2.3 스노우플레이크 스키마

은하수 스키마

은하수 스키마(Galaxy Schema)는 여러 스타 스키마가 결합된 구조로, 여러 사실 테이블들이 동일한 차원 테이블을 공유합니다. 성운 스키마라고도 하며, 다양한 데이터 분석 요구에 유연하게 대응할 수 있습니다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

11.2. 데이터웨어하우스 설계

11.2.3 스노우플레이크 스키마

스타스키마와스노우플레이크스키마의 비교

​

​

​

​

​

​

​

​

​

​

​

​

​

​

11.2. 데이터웨어하우스 설계

11.2.3 스노우플레이크 스키마

다차원 모델링의 예

지난 12개월 동안 2개 학과에서 개설한 3개 과목의 수강 실적을 분석하기 위해 다차원 모델링을 적용할 수 있습니다.

관계형 데이터베이스를 사용한 경우, 스타 스키마로 설계할 수 있으며, 다차원 데이터베이스로 설계하면 더 효율적인 구조를 얻을 수 있습니다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

11.3. OLAP

11.3.1 OLAP의 정의

OLAP(Online Analytical Processing)은 데이터웨어하우스에서 다차원 분석을 가능하게 하는 기술입니다. OLAP은 데이터베이스의 OLTP(On Line Transaction Processing)와는 반대 개념으로, 사용자가 직접 대규모 데이터를 동적으로 분석하여 의사 결정을 돕습니다. OLAP의 핵심은 다차원 분석(FASMI: Fast Analysis of Shared Multi-dimensional Information)입니다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

11.3. OLAP

11.3.1 OLAP의 정의

OLAP의 정의와 특성

• 다차원성: 사용자가 다양한 관점에서 데이터를 분석할 수 있도록 다차원 구조로 데이터를 조직화합니다.
• 직접성: 의사결정자가 개발자의 도움 없이 직접 분석할 수 있습니다.
• 대화성: 반복적인 질문을 통해 필요한 정보를 탐색할 수 있는 대화형 인터페이스를 제공합니다.
• 비정형성: 사용자가 다양한 형식의 보고서를 자유롭게 생성할 수 있습니다.
• 자동성: 메타 데이터를 사용해 손쉽게 보고서를 생성할 수 있습니다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

11.3. OLAP

11.3.2 OLAP의 종류

• MOLAP (다차원 OLAP): 데이터를 다차원 배열 구조(큐브)에 저장하여 빠른 응답을 제공하지만, 빈 셀 문제와 대용량 데이터 처리에 제약이 있습니다.
• ROLAP (관계형 OLAP): 관계형 데이터베이스를 사용하여 세부 데이터를 저장하며 확장성이 우수합니다.
• HOLAP (혼합형 OLAP): 다차원 및 관계형 데이터베이스를 결합하여 신속성과 확장성을 동시에 제공합니다.
• DOLAP & WOLAP: 데스크톱 환경에서 분석하는 DOLAP과 웹 환경에서 사용하는 WOLAP도 존재합니다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

11.3. OLAP

11.3.2 OLAP의 종류

어떤 OLAP을 선택할지에 대한 결정은 얼마나 빠른 웅답 시간을 요구하고 얼마나 복잡한질의를 사용할 것인지에 따라 다르다. 〈표 11-3〉은 3가지 OLAP 방식을 비교 분석한 내용이다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

11.3. OLAP

11.3.3 OLAP 연산 기능

OLAP 도구는 다음과 같은 표준 연산을 지원합니다:

1. 드릴-다운: 상위 수준에서 하위 수준으로 세부 데이터를 탐색합니다.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

큐브는 단과대학별 요약이 아니라 공과대학 소속의 개별 학과별 총 도서 대출권수를 상세히 보여준다.

​

​

​

​

​

​

11.3. OLAP

11.3.3 OLAP 연산 기능

OLAP 도구는 다음과 같은 표준 연산을 지원합니다:

• 롤-업: 하위 수준에서 상위 수준으로 데이터를 집계합니다.

​

‘Department’에서 ‘School' 수준으로, 다시 ‘Level' 수준으로 상승하면서 데이터를 학과별로 묶는 대신 학부와 대학원별로 데이터를 묶는다.

​

​

​

​

​

​

11.3. OLAP

11.3.3 OLAP 연산 기능

OLAP 도구는 다음과 같은 표준 연산을 지원합니다:

• 슬라이스와 다이스: 큐브의 일부분을 선택해 작은 큐브를 생성합니다.

​

예를 통해 2010년 학부생이 대출한 도서의 총 대출권수가 10권임을 분석할 수 있다.

​

​

​

​

​

​

11.3. OLAP

11.3.3 OLAP 연산 기능

OLAP 도구는 다음과 같은 표준 연산을 지원합니다:

• 피봇: 분석 데이터의 축을 변경하여 다른 시각에서 데이터를 볼 수 있게 합니다.

​

예를 들면, 가로축에 시간 정보를, 세로축에 조직 정보를 배치한 분석 보고서를 가로축과 세로축을 서로 맞바꾸어 새로운 분석 양식을 생성할 수 있다.

​

​

​

​

​

​

11.3. OLAP

11.3.3 OLAP 연산 기능

OLAP 도구는 다음과 같은 표준 연산을 지원합니다:

• 드릴-쓰루: 요약된 데이터를 통해 상세 데이터로 이동하며 분석합니다.

​

예를 들면, 월별 매출 요약 정보를 분석하다가 매출이 급감한 특정 월에 대해서 일별, 또는 시간별 매출 정보를 상세하게 분석할 수 있다.

​

​

​

​

​

​

​

11.3. OLAP

11.3.3 OLAP 연산 기능

OLAP 도구는 다음과 같은 표준 연산을 지원합니다:

• 드릴-어크로스: 현재 큐브에서 다른 큐브로 이동하여 추가 분석을 수행합니다.

​

예를 들어, 사용자가 ‘매출’ 큐브를 분석하는 과정에서 판교 매장에서 휴대폰의 매출액이 급격히 증가하고 있음을 발견했다면 사용자는 재고’ 큐브로 드릴-어크로스하여 각 매장별로 부족한 휴대폰의 재고량을 조절할 수 있다.

​

​

​

​

​

​

​

OLAP의 이러한 기능들은 사용자가 다차원 데이터를 효과적으로 분석하고 의사 결정을 내리는 데 도움을 줍니다.

11.4. 데이터베이스 응용

현대 데이터베이스는 다양한 요구사항을 수용하기 위해 확장된 형태로 발전하였습니다. 이 중 대표적인 응용 분야를 살펴보겠습니다.

11.4.1 분산 데이터베이스

정의: 분산 데이터베이스는 물리적으로 분산된 여러 데이터베이스를 네트워크로 연결하여 하나의 중앙 집중형 데이터베이스처럼 사용 가능한 시스템입니다.

분산 데이터 독립성: 사용자나 프로그램이 데이터의 분산 여부를 인식할 필요가 없으며, DBMS가 이를 관리합니다.

​

​

​

11.4. 데이터베이스 응용

11.4.1 분산 데이터베이스

5가지 투명성:

• 위치 투명성: 사용자는 데이터의 저장 위치를 몰라도 됩니다.
• 중복 투명성: 중복된 데이터의 일관성을 DBMS가 유지합니다.
• 단편화 투명성: DBMS가 데이터 분할을 관리하여 사용자는 이를 인식할 필요가 없습니다.
• 병행 투명성: 여러 트랜잭션이 동시에 처리되더라도 일관된 결과를 제공합니다.
• 장애 투명성: 시스템 장애가 발생해도 정상적인 처리가 가능합니다.

​

11.4. 데이터베이스 응용

11.4.1 분산 데이터베이스

[그림 11-25]는 데이터 투명성을 제공하기 위한 전역, 단편화, 할당 스키마를 포함한 분산데이터베이스의 구조를 보여준다. 다양한 스키마의 기능은 다음과 같다.

• 전역 스키마: 분산 데이터베이스의 모든 데이터 구조와 제약 조건을 정의
• 단편 스키마: 전역 스키마를 논리적으로 분할한 단편들을 정의
• 할당 스키마: 각 단편들을 물리적으로 저장할 지역 위치를 정의
• 지역 스키마: 지역별로 저장하는 데이터의 구조와 제약조건을 정의

​

11.4. 데이터베이스 응용

11.4.1 분산 데이터베이스

​

​

11.4. 데이터베이스 응용

11.4.1 분산 데이터베이스

클라이언트-서버 데이터베이스

클라이언트-서버 구조는 다양한 컴퓨터 장비가 네트워크로 연결된 분산 컴퓨팅 환경에서 사용하는 서비스 구조입니다. 이 구조는 요청을 처리하는 클라이언트(client)와 요청된 서비스를 수행하는 서버(server)로 기능을 분리합니다.

​

​

11.4. 데이터베이스 응용

11.4.1 분산 데이터베이스

클라이언트-서버 데이터베이스

클라이언트-서버 데이터베이스는 이 구조를 활용하여 분산 데이터베이스를 구현하는 방식입니다. 여기서 DBMS의 전체 기능을 클라이언트와 서버 컴퓨터로 분할하여 관계형 데이터베이스의 분산 시스템을 구성합니다. 클라이언트(전위 컴퓨터)는 사용자가 요청한 질의를 여러 개의 독립적인 서브질의로 나누어 서버(후위 컴퓨터)로 보냅니다. 서버는 이 서브질의를 처리한 후, 결과를 클라이언트에게 반환합니다. 클라이언트는 받은 서브질의의 결과들을 조합하여 원래 질의에 대한 최종 결과를 생성합니다.

​

​

​

11.4. 데이터베이스 응용

11.4.2 객체지향 데이터베이스

정의: 객체 단위로 데이터를 관리하며 객체, 속성, 메소드, 클래스 계층과 상속 등의 객체지향 개념을 지원합니다.

주요 개념:

• 클래스: 유사한 특성을 가진 객체들을 그룹화하여 정의한 개념.
• 객체: 고유한 식별자를 가지며 클래스의 인스턴스.
• 속성: 객체의 상태값을 나타내는 데이터.
• 메소드: 객체의 속성값을 처리하기 위한 함수.
• 상속: 하위 클래스가 상위 클래스의 속성과 메소드를 상속받아 재사용 가능.

활용 분야: CAD/CAM, 통신, 지리정보, 멀티미디어 등의 복잡한 데이터베이스 응용에 적합합니다.

​

11.4. 데이터베이스 응용

11.4.2 객체지향 데이터베이스

​

11.4. 데이터베이스 응용

11.4.3 객체-관계 데이터베이스

정의: 관계형 데이터베이스와 객체지향 데이터베이스의 장점을 결합한 하이브리드 모델입니다.

특징: 관계 데이터베이스의 간단함과 객체지향 데이터 모델의 확장성을 모두 제공합니다. SQL3 표준을 사용해 객체지향적 질의를 지원합니다.

​

​

11.4. 데이터베이스 응용

11.4.4 멀티미디어 데이터베이스

멀티미디어 데이터베이스는 텍스트, 이미지, 비디오, 오디오 등의 다양한 비정형 데이터를 효율적으로 저장하고 관리하는 시스템입니다. 정형 데이터뿐 아니라, 대용량의 사진, 동영상, 음성 데이터를 효과적으로 저장하고 검색할 수 있는 기능을 제공합니다.

​

​

11.4. 데이터베이스 응용

11.4.4 멀티미디어 데이터베이스

저장과 검색

• 저장: 원시 데이터(음성, 영상)와 관련 특성(해상도, 형식) 및 키워드 정보가 함께 저장됩니다.
• 검색: 키워드 검색이 기본 제공되며, 이미지나 동영상의 시각적 특성(색상, 질감, 모양) 기반의 내용 검색도 지원합니다. 오디오 데이터는 크기, 강도 등의 특성을 활용한 검색 기법을 사용합니다.

​

​

​

11.4. 데이터베이스 응용

11.4.4 멀티미디어 데이터베이스

시스템 유형

• 파일 시스템 방식: 단순히 파일로 저장하며, 동시 접근이나 회복 기능이 부족합니다.
• 관계형 DB 활용: 원시 데이터는 파일에, 특성 데이터는 관계형 DB에 분리 저장합니다.
• 확장된 관계형 DB 기능: BLOB (Binary Large Object) 기능을 이용해 멀티미디어 데이터를 관계형 DB에 저장합니다.
• 객체지향 DB 방식: 객체지향 개념(캡슐화, 상속 등)을 활용해 데이터 특성을 효과적으로 반영합니다.

​

​

11.4. 데이터베이스 응용

11.4.5 공간 데이터베이스

공간 데이터베이스는 다차원 공간 내 객체와 객체 간의 공간적 관계를 저장·관리하는 시스템입니다. 위치 기반의 데이터 저장, 공간 색인, 공간 질의, 공간 분석 기능을 제공합니다.

공간 데이터 유형

• 지리 데이터: 도로, 지형, 행정 경계 등의 좌표 기반 데이터입니다.
• 기하학 데이터: 빌딩, 다리 같은 구조물의 2D/3D 공간 정보를 포함합니다.
• 공간 속성 데이터: 지도 이미지와 각 공간 객체의 특성 및 통계 데이터를 표현합니다.

​

​

​

11.4. 데이터베이스 응용

11.4.5 공간 데이터베이스

기능

• 모델링 및 인덱싱: 레스터 데이터(비트맵/픽셀맵)와 벡터 데이터(다각형, 구 등)를 다차원 객체로 관리합니다.
• 공간 질의: 특정 영역의 개체 검색(영역 질의), 가까운 객체 검색(근접 질의), 최소 거리 찾기(공간 그래프 질의) 등을 지원합니다.

​

​

​

데이터베이스

연습문제

연습문제

12

빅데이터와 NoSQL

1. 빅데이터 개념
2. 빅데이터 기술과 NoSQL

​

학습목표

​

• 빅데이터의 등장 배경을 이해한다.
• 빅데이터의 특성과 유형을 살펴본다.
• 빅데이터의 수집 및 처리 기술을 이해하고 활용 방법을 알아본다.
• NoSOL과 빅데이터의 저장, 분석, 시각화 기술을 이해하고 활용 방법을 알아본다.

​

p. 421-456

12.1. 빅데이터 개념

1.1 빅데이터의 등장 배경

​

현대 사회의 복잡성을 분석하고 예측하기 위해 빅데이터 기술이 필요하다. 디지털 정보량의 급격한 증가로 SNS 메시지, IoT 센서 데이터, 웹서버 로그 등 다양한 데이터가 생성되고, 기존 기술로는 이를 처리하는 데 한계가 있다. 대용량 데이터 처리 비용이 낮아지면서 성공 사례가 늘어나 빅데이터 활용이 증가하고 있다.

​

12.1. 빅데이터 개념

1.1 빅데이터의 등장 배경

​

TIP: 데이터 과학

데이터 과학은 데이터에서 의미 있는 정보와 가치를 찾아내는 학문으로, 통계학, 컴퓨터 과학, 프로그래밍 기술 등이 융합된 분야이다. 데이터 과학자는 가설을 세우고 모델을 검증하여 숨겨진 진실을 탐구한다.

​

​

12.1. 빅데이터 개념

1.2 빅데이터의 기본 개념

​

• 정의: 빅데이터는 기존 시스템으로는 처리하기 어려운 대용량 데이터 집합이다. SNS, IoT 기기의 확산으로 데이터가 폭발적으로 증가하고, 이는 의사결정을 위한 중요한 자산으로 간주된다.
• DIKW 피라미드: 데이터 (Data) → 정보 (Information) → 지식 (Knowledge) → 지혜 (Wisdom)의 과정을 통해 새로운 통찰을 얻는다.

​

​

​

12.1. 빅데이터 개념

1.2 빅데이터의 기본 개념

​

빅데이터의 특성

• 용량(Volume): 데이터의 규모가 크며, 페타바이트 이상 수준으로 폭발적으로 증가한다.
• 다양성(Variety): 정형, 반정형, 비정형 데이터를 포함하여 유형이 다양하다.
• 속도(Velocity): 데이터 생성 속도가 빨라 신속한 처리와 분석이 필요하다.
• 가치(Value): 빅데이터 활용으로 경제적 이익과 질적 향상을 기대할 수 있다.
• 정확성(Veracity): 신뢰성 높은 분석을 위해 데이터 정제와 검증이 중요하다.

​

​

​

12.1. 빅데이터 개념

1.2 빅데이터의 기본 개념

​

빅데이터의 유형

• 정형 (structured) 데이터: 고정된 형식으로 저장된 데이터(예: 데이터베이스).
• 반정형 (semi-structured) 데이터: 구조는 있지만 형식이 유동적인 데이터(XML, JSON).
• 비정형 (unstructured) 데이터: 형식이나 구조가 없는 데이터(음성, 동영상, SNS).

각 유형은 데이터 복잡도와 용량에 따라 다르며, 비정형 데이터는 연구와 관심이 집중되는 분야이다.

​

​

​

​

12.1. 빅데이터 개념

1.2 빅데이터의 기본 개념

​

빅데이터의 유형

​

​

​

​

12.2. 빅데이터 기술과 NoSQL

빅데이터의 주요 기술

빅데이터는 대용량 데이터를 저장하고 분석 모형을 적용해 탐색, 분석, 시각화하는 과정으로 이루어진다. 주요 기술은 데이터 수집, 처리, 저장, 분석, 시각화 기술로 나뉜다.

​

​

​

​

​

12.2. 빅데이터 기술과 NoSQL

빅데이터의 주요 기술

1. 빅데이터 수집 기술: 데이터를 발굴, 변환, 정제하여 조직 내부 및 외부의 다양한 데이터를 수집하는 기술. ETL(추출, 변환, 적재) 과정을 수행하며, 수집된 데이터는 분석 목적에 맞게 추가 변환 작업이 필요하다.
2. 빅데이터 처리 기술: 데이터를 필터링, 변형, 정제하여 분석 가능한 형태로 만드는 기술. 처리된 데이터는 RDB, NoSQL, 분산파일시스템 등에 저장된다.
3. 빅데이터 저장 기술: 다양한 유형의 대용량 데이터를 효율적으로 저장. 정형 데이터는 RDB에, 반정형 데이터는 NoSQL에, 비정형 데이터는 분산 파일 시스템에 저장.
4. 빅데이터 분석 기술: 다양한 분석 기법을 사용해 데이터를 분석하고 숨겨진 의미를 파악.
5. 빅데이터 시각화 기술: 분석 결과를 차트와 그래픽으로 시각화하여 정보를 효과적으로 전달.

​

​

​

​

​

12.2. 빅데이터 기술과 NoSQL

2.1 빅데이터의 수집

조직 내부 및 외부 데이터를 정제된 형태로 수집하며, 데이터의 충분성, 완전성, 일관성, 정확성을 고려.

데이터 유형

• 정형 데이터: 테이블, 스프레드시트 등 통일된 형식으로 수집이 용이.
• 반정형 데이터: XML, JSON 등 메타데이터 포함. 변환 필요.
• 비정형 데이터: 텍스트, 소셜 미디어 데이터. 분석 가치가 높아 자동화 기술 필수.

수집 기술

• 웹 크롤링: 크롤러를 이용해 데이터 자동 수집.
• 웹 스크래핑: 특정 웹사이트 정보 자동 추출.

​

​

​

​

​

12.2. 빅데이터 기술과 NoSQL

2.1 빅데이터의 수집

의미있는 분석 결과를 얻기 위해 다음 4가지 기준을 고려한다.

• 데이터의 충분성(데이터의 축적 기간 및 분량의 충분성 등)
• 데이터의 완전성(데이터 누락 및 결측값의 비율 등)
• 데이터의 일관성(데이터 유형과 값의 일치성 등)
• 데이터의 정확성(데이터 편향과 분산 등)

​

​

​

​

​

12.2. 빅데이터 기술과 NoSQL

2.1 빅데이터의 수집

수집 데이터의처리

수집 데이터의 처리는 데이터 가공이나 데이터 분석을 준비하는 과정이다. 수집된 모든 빅데이터는 분석 가능한 데이터로 변환하는 전처리 과정을 수행한 후 저장한다. 저장 이후에는 분석을 위하여 후처리 과정을 추가적으로 수행한다.

​

​

​

​

​

​

12.2. 빅데이터 기술과 NoSQL

2.2 빅데이터의 처리와 하둡(맵리듀스)

빅데이터 처리 방식

• 비정형 데이터 분석, 처리 분산, 분석 모델 적용에 따라 적합한 방식을 선택.
• 처리 방식: 대화형, 일괄형, 실시간형.
• 일괄 처리: 분산 병렬 처리로 한꺼번에 작업.
• 실시간 처리: SNS, 블로그 등 데이터를 즉시 처리.
• 주로 하둡 기반의 일괄 처리 방식 사용.

​

​

​

​

​

12.2. 빅데이터 기술과 NoSQL

2.2 빅데이터의 처리와 하둡(맵리듀스)

아파치 하둡

• 빅데이터 처리 시간 문제를 해결하기 위해 분산 병렬 컴퓨팅 기술 활용.
• 하둡: 고확장성, 고성능 인프라 필수.
• 자바 기반의 오픈소스 플랫폼, 구글 데이터 분석에 사용.
• 수평적 확장(서버 추가) 방식으로 대규모 데이터 처리.
• 하둡 핵심 요소:
• HDFS: 대용량 데이터 저장, 마스터/슬레이브 구조, 블록 단위로 데이터 분산 저장.
• 맵리듀스: 분산 병렬 처리를 위한 프레임워크, 데이터 분할 및 병렬 처리.

​

​

​

​

​

12.2. 빅데이터 기술과 NoSQL

2.2 빅데이터의 처리와 하둡(맵리듀스)

하둡의 장단점

• 장점:
• 장비 추가 용이, 빠른 데이터 처리 속도.
• 병렬 분산 처리 자동화, 높은 확장성.
• 배치 처리에 적합.
• 단점:
• 실시간 분석 부적합.
• 데이터 변경 어려움, 반복 읽기에 최적화.

하둡 에코 시스템

• HDFS와 맵리듀스를 보완하기 위한 확장 기술 추가.
• 다양한 오픈소스 프로젝트와 하둡 생태계 형성.

​

​

​

​

​

​

12.2. 빅데이터 기술과 NoSQL

2.2 빅데이터의 처리와 하둡(맵리듀스)

맵리듀스 처리 과정

1. 맵 단계:
• 데이터를 여러 스플릿으로 나누고 〈키, 값〉 쌍으로 변환.
• 병렬 처리로 비정형 데이터를 정형 데이터로 변환.
2. 셔플 단계:
• 맵 결과를 정렬 후, 동일 키 값을 그룹화하여 리듀스 입력으로 전달.
3. 리듀스 단계:
• 중복 데이터 제거, 최종 데이터 생성 및 HDFS에 저장.

​

​

​

​

​

​

​

12.2. 빅데이터 기술과 NoSQL

2.2 빅데이터의 처리와 하둡(맵리듀스)

맵리듀스 활용 예: 단어 개수 세기

• HDFS에서 문서를 스플릿으로 나눠 병렬 처리.
• 각 스플릿에서 단어를 추출하고 〈단어, 개수〉로 변환.
• 셔플 단계에서 동일 단어를 그룹화, 리듀스 단계에서 총 개수 계산.
• 장점: 데이터 이동 최소화, 대용량 데이터에 적합한 병렬 처리 성능.

12.2. 빅데이터 기술과 NoSQL

2.3 빅데이터의 저장과 NoSQL

빅데이터 저장 방식

• SQL 데이터베이스: 정형 데이터를 스키마 기반으로 저장하는 관계형 데이터베이스. Oracle, MySQL 등이 포함되며 데이터웨어하우스에도 사용됨.
• NoSQL 데이터베이스: 고정된 스키마 없이 유연한 저장소로 반정형 및 비정형 데이터를 저장하며, 분산 환경에서 확장성과 고성능을 제공. MongoDB, Cassandra 등이 대표적.
• 분산 파일 시스템: 비정형 데이터를 분산 환경에서 저장하며, 고성능과 고장-감내성을 갖춘 저장 방식. Hadoop HDFS, Google GFS 등이 예시.

​

12.2. 빅데이터 기술과 NoSQL

2.3 빅데이터의 저장과 NoSQL

빅데이터 저장 방식

​

​

12.2. 빅데이터 기술과 NoSQL

2.3 빅데이터의 저장과 NoSQL

NoSQL 데이터베이스의 장점

• 유연성: 스키마 없이 동적 속성 추가/삭제 가능.
• 확장성: 저가 서버 추가로 수평적 확장 가능.
• 경제성: 대부분 오픈소스로 무료 제공.
• 가용성: 데이터 자동 복제 및 장애 대응 기능.

​

​

12.2. 빅데이터 기술과 NoSQL

2.3 빅데이터의 저장과 NoSQL

CAP 이론

• CAP 속성: 일관성(Consistency), 가용성(Availability), 분할 허용(Partition Tolerance) 중 최대 2가지만 만족 가능.
• CP 유형: 일관성과 분할 허용 (예: MongoDB, HBase)
• AP 유형: 가용성과 분할 허용 (예: Dynamo, Cassandra)

12.2. 빅데이터 기술과 NoSQL

2.3 빅데이터의 저장과 NoSQL

NoSQL 데이터베이스 유형

• 키-값 데이터베이스: 단순한 형태로 키와 값의 쌍으로 저장. (예: Redis)
• 문서 데이터베이스: JSON, XML 기반 반구조화 데이터 저장. (예: MongoDB)
• 컬럼 패밀리 데이터베이스: 컬럼 중심으로 데이터 저장. (예: Cassandra)
• 그래프 데이터베이스: 노드와 엣지 관계를 기반으로 저장. (예: Neo4j)

​

12.2. 빅데이터 기술과 NoSQL

2.3 빅데이터의 저장과 NoSQL

NoSQL 데이터베이스 유형

• 키-값 데이터베이스: 단순한 형태로 키와 값의 쌍으로 저장. (예: Redis)
• 문서 데이터베이스: JSON, XML 기반 반구조화 데이터 저장. (예: MongoDB)
• 컬럼 패밀리 데이터베이스: 컬럼 중심으로 데이터 저장. (예: Cassandra)
• 그래프 데이터베이스: 노드와 엣지 관계를 기반으로 저장. (예: Neo4j)

​

12.2. 빅데이터 기술과 NoSQL

2.3 빅데이터의 저장과 NoSQL

NoSQL 데이터베이스 유형

• 키-값 데이터베이스: 단순한 형태로 키와 값의 쌍으로 저장. (예: Redis)
• 문서 데이터베이스: JSON, XML 기반 반구조화 데이터 저장. (예: MongoDB)
• 컬럼 패밀리 데이터베이스: 컬럼 중심으로 데이터 저장. (예: Cassandra)
• 그래프 데이터베이스: 노드와 엣지 관계를 기반으로 저장. (예: Neo4j)

​

12.2. 빅데이터 기술과 NoSQL

2.3 빅데이터의 저장과 NoSQL

NoSQL 데이터베이스 유형

• 키-값 데이터베이스: 단순한 형태로 키와 값의 쌍으로 저장. (예: Redis)
• 문서 데이터베이스: JSON, XML 기반 반구조화 데이터 저장. (예: MongoDB)
• 컬럼 패밀리 데이터베이스: 컬럼 중심으로 데이터 저장. (예: Cassandra)
• 그래프 데이터베이스: 노드와 엣지 관계를 기반으로 저장. (예: Neo4j)

​

12.2. 빅데이터 기술과 NoSQL

2.4 빅데이터의 분석과 데이터 마이닝

빅데이터의 분석

• 빅데이터 탐색: 빅데이터를 깊이 이해하기 위해 통계 기법과 시각화를 활용해 데이터를 관찰하는 과정. 엑셀, SPSS, SAS, R, Python 등이 사용되며 차트나 그래프를 통해 데이터의 특성을 파악함.
• 빅데이터 해석: 분석된 데이터에 의미를 부여하고 지식으로 전환. 통찰(insight)을 통해 데이터 간의 관계를 발견하고 새로운 개념을 도출함.

​

12.2. 빅데이터 기술과 NoSQL

2.4 빅데이터의 분석과 데이터 마이닝

데이터 마이닝

• 정형 데이터마이닝 기법
• 분류: 데이터 대상이 속할 그룹을 예측. (로지스틱 회귀, 의사결정 나무 등)
• 군집: 유사한 데이터를 묶음. (비지도 학습)
• 연관: 데이터 간 관계를 분석. (패턴 분석)
• 예측: 데이터 패턴으로 미래 결과를 예측. (시계열 분석 등)

​

12.2. 빅데이터 기술과 NoSQL

2.4 빅데이터의 분석과 데이터 마이닝

데이터 마이닝

• 정형 데이터마이닝 기법
• 분류: 데이터 대상이 속할 그룹을 예측. (로지스틱 회귀, 의사결정 나무 등)
• 군집: 유사한 데이터를 묶음. (비지도 학습)
• 연관: 데이터 간 관계를 분석. (패턴 분석)
• 예측: 데이터 패턴으로 미래 결과를 예측. (시계열 분석 등)

​

12.2. 빅데이터 기술과 NoSQL

2.4 빅데이터의 분석과 데이터 마이닝

데이터 마이닝

• 정형 데이터마이닝 기법
• 분류: 데이터 대상이 속할 그룹을 예측. (로지스틱 회귀, 의사결정 나무 등)
• 군집: 유사한 데이터를 묶음. (비지도 학습)
• 연관: 데이터 간 관계를 분석. (패턴 분석)
• 예측: 데이터 패턴으로 미래 결과를 예측. (시계열 분석 등)

​

12.2. 빅데이터 기술과 NoSQL

2.4 빅데이터의 분석과 데이터 마이닝

데이터 마이닝

• 정형 데이터마이닝 기법
• 분류: 데이터 대상이 속할 그룹을 예측. (로지스틱 회귀, 의사결정 나무 등)
• 군집: 유사한 데이터를 묶음. (비지도 학습)
• 연관: 데이터 간 관계를 분석. (패턴 분석)
• 예측: 데이터 패턴으로 미래 결과를 예측. (시계열 분석 등)

​

12.2. 빅데이터 기술과 NoSQL

2.4 빅데이터의 분석과 데이터 마이닝

데이터 마이닝

• 비정형 데이터마이닝 기법
• 텍스트 마이닝: 문서에서 자연어 처리를 통해 정보 추출.
• 웹 마이닝: 웹 사용자 데이터 분석.
• 오피니언 마이닝: 감성 분석으로 사용자 의견 분석.
• 소셜 마이닝: 사회 연결망 관계 분석.

​

12.2. 빅데이터 기술과 NoSQL

2.5 빅데이터의 시각화

시각화 분류

1. 시간 시각화: 시간 변화 표현. (막대 그래프, 시계열 그래프 등)
2. 분포 시각화: 전체-부분 관계 표현. (파이 차트 등)
3. 관계 시각화: 변수 간 관계 표현. (히스토그램 등)
4. 비교 시각화: 다양한 변수 비교. (히트맵 등)
5. 공간 시각화: 지도 데이터 활용.

​

​

데이터베이스

연습문제

연습문제

13

NoSQL과 몽고DB

• NoSQL 몽고DB 개요
• 몽고DB 실습
• 컬렉션 문서 관리 명령문

​

학습목표

​

• NoSQL 몽고 DB 의 특성과 구조를 이해한다.
• 몽고DB를 설치하고 쉘 사용 방법을 살펴본다.
• 데이터베이스와 컬렉션, 문서 관리 명령어를 알아본다.
• lnsertOne, UpdateOne, DeleteMany, Find 명령어 함수의 작성 방법을 실습한다.

​

p. 457-490

13.1. NoSQL 몽고DB 개요

전통적인 관계형 데이터베이스는 소규모 사용자를 위한 단일 애플리케이션 운영에 적합했지만, 빅데이터, IoT, 클라우드 환경에서 발생하는 대규모 데이터와 사용자 요구를 충족하기 어렵다. 이를 해결하기 위해 NoSQL 데이터베이스가 등장했으며, 그 중 몽고DB는 문서 기반 데이터베이스로 가장 널리 사용된다.

​

​

​

13.1. NoSQL 몽고DB 개요

몽고DB는 오픈 소스 DBMS로 유연한 스키마와 높은 성능, 확장성을 제공하며 관계형 데이터베이스와 유사한 질의 기능을 지원한다.

​

​

​

13.1. NoSQL 몽고DB 개요

1.1 NoSQL 몽고DB의 특성

​

1. 유연성
• 스키마 정의가 필요 없고, 데이터 구조 변경이 자유롭다.
• 데이터 유형과 필드를 동적으로 추가/삭제 가능해 변화가 많은 환경에 적합하다.
2. 확장성
• 수평적 분산 확장을 통해 여러 서버에서 데이터를 처리 가능.
• 자동 샤딩을 지원해 대용량 데이터를 효율적으로 관리.
3. 고성능
• 읽기/쓰기 속도가 빠르고 복제를 통한 가용성이 높다.
• 복잡한 조인이나 서브쿼리는 지원하지 않지만 색인 및 간단한 질의는 가능하다.

​

​

13.1. NoSQL 몽고DB 개요

1.1 NoSQL 몽고DB의 특성

​

​

​

​

13.1. NoSQL 몽고DB 개요

1.1 NoSQL 몽고DB의 특성

​

몽고DB는 데이터베이스 → 컬렉션 → 문서로 이어지는 계층적 구조로 데이터를 관리한다.

• 문서: 기본 저장 단위로, JSON과 유사한 BSON 형식으로 저장.
• 컬렉션: 문서들의 집합으로 동적 스키마를 가진다.
• 데이터베이스: 여러 컬렉션을 포함하는 물리적 컨테이너.

​

​

​

13.1. NoSQL 몽고DB 개요

1.1 NoSQL 몽고DB의 특성

​

몽고DB 설치 후에 자동 생성되는 기본 데이터베이스는 다음과 같다.

• 'admin' 데이터베이스 : 인증과 권한 부여에 관한 데이터를 저장한다.
• ‘local’ 데이터베이스 : 단일 서버에 대한 데이터를 저장한다.
• 'config' 데이터베이스 : 샤딩된 클러스터에 관한 각 샤드(shard) 정보를 저장한다.

그림 13-3은 몽고DB 안의 계층 구조를 보여준다.

​

​

​

13.1. NoSQL 몽고DB 개요

1.1 NoSQL 몽고DB의 특성

문서 데이터 모델

몽고DB는 계층적 데이터를 문서에 저장하며, 관계형 데이터베이스의 복잡한 조인을 대체할 수 있다. 관계는 내장(embedded) 방식과 참조(reference) 방식으로 표현된다.

• 내장 방식: 하나의 문서 안에 관련 데이터를 포함.
• 참조 방식: 다른 문서의 ID를 저장해 관계를 표현.

몽고DB는 동적 스키마를 통해 데이터 구조의 빈번한 변경에도 유연하게 대응하며, 스키마가 없는 데이터베이스를 효과적으로 관리할 수 있다.

​

​

​

​

13.1. NoSQL 몽고DB 개요

1.1 NoSQL 몽고DB의 특성

JSON과 BSON의 차이

JSON(JavaScript Object Notation)

• 자바스크립트에서 객체 생성에 사용되는 표현 방식.
• 필드명과 필드값의 쌍으로 구성된 사람이 읽기 쉬운 텍스트 형식.
• 검색 시 파싱 필요, 날짜 및 이진 데이터 유형 미지원.

BSON(Binary JSON)

• JSON 데이터를 컴퓨터가 쉽게 처리할 수 있는 이진 형식으로 변환한 형태.
• 검색 속도 우수, 날짜 및 이진 데이터 유형 지원.
• 몽고DB에서 자동 처리되지만 인코딩/디코딩 작업 추가 필요.

​

​

​

​

​

​

13.1. NoSQL 몽고DB 개요

1.1 NoSQL 몽고DB의 특성

몽고DB의 동적 스키마

• 고정된 스키마 없음(schema-less).
• 동일 컬렉션 내 문서 간 구조가 다를 수 있음(schema-free).
• 데이터 구조 변경이 쉬움.

예시

• 전화번호 필드가 단일 값에서 배열로 변경되는 상황도 간단히 처리 가능.

컬렉션

• 동적 스키마를 가진 문서의 모음으로, 테이블과 유사.
• 필드명, 필드 수, 필드값 유형 등이 문서마다 다를 수 있음.

​

​

​

​

​

​

​

13.1. NoSQL 몽고DB 개요

1.1 NoSQL 몽고DB의 특성

몽고DB의 관계 표현

• 관계형 데이터베이스: 1:1, 1:n, m:n 관계를 외래키를 통해 참조.
• 몽고DB 방식
• 외래키 없이 문서 간 연관 관계를 표현.
• 내장(Embedded): 관계 데이터를 하나의 문서 내에 저장.
• 참조(Reference): 다른 문서의 키 값을 참조하여 관계 표현.
• 특징
• 중첩된 내장 문서와 배열 허용.
• 객체지향 프로그램의 객체를 그대로 저장 가능.
• 자바스크립트 기반 질의어 사용.

​

​

13.1. NoSQL 몽고DB 개요

1.1 NoSQL 몽고DB의 특성

몽고DB와 관계형 데이터베이스의 비교

​

​

​

13.1. NoSQL 몽고DB 개요

1.1 NoSQL 몽고DB의 특성

실습 예제: cinemadb

회원 컬렉션: 회원 정보 구조 포함.

​

​

​

13.1. NoSQL 몽고DB 개요

1.1 NoSQL 몽고DB의 특성

실습 예제: cinemadb

영화 컬렉션: 영화 정보 및 평점, 댓글 등의 중첩 문서 포함.

​

​

​

​

13.2. 몽고DB 실습

2.1 몽고DB의 설치 및 실행

1. 몽고DB를 다운로드하여 설치 후 MongoDB Compass 실행.
2. MongoDB Compass는 GUI 도구로 명령어 입력 및 실행 결과 확인 가능.
3. Connect 버튼을 눌러 연결 후 쉘 입력창에서 명령어 입력.
4. 몽고DB 쉘은 자바스크립트 명령어 실행 가능하며, 데이터 질의 및 관리에 유용.

​

​

​

​

13.2. 몽고DB 실습

2.1 몽고DB의 설치 및 실행

​

​

​

​

​

13.2. 몽고DB 실습

2.1 몽고DB의 설치 및 실행

Mongo Atlas는 아무것도 설치하지 않고 MongoDB를 사용해 볼 수 있는 좋은 곳입니다. 웹 애플리케이션 프로그래밍에 유용한 MongoDB의 온라인 클라우드 기반 설치입니다. 우리의 용도에는 충분할 것입니다.

​

​

​

​

13.2. 몽고DB 실습

2.2 몽고DB 쉘을 이용한 데이터베이스와 컬렉션 관리

데이터베이스 생성 및 확인

• use <데이터베이스_이름>: 데이터베이스 생성 및 변경.
• db: 현재 작업 중인 데이터베이스 이름 확인.
• show dbs: 생성된 데이터베이스 목록 확인.

​

​

​

​

​

13.2. 몽고DB 실습

2.2 몽고DB 쉘을 이용한 데이터베이스와 컬렉션 관리

TIP

• 쉘에서 방향키로 이전 명령어 재활용 가능.
• help 입력 시 도움말 제공.

​

​

​

​

​

13.2. 몽고DB 실습

2.2 몽고DB 쉘을 이용한 데이터베이스와 컬렉션 관리

컬렉션 생성 및 이름 변경

• db.createCollection("컬렉션_이름"): 새 컬렉션 생성.
• db.<현재_컬렉션_이름>.renameCollection("새_이름"): 컬렉션 이름 변경.
• capped 옵션: 크기가 초과되면 오래된 데이터 삭제.

​

​

​

​

​

13.2. 몽고DB 실습

2.2 몽고DB 쉘을 이용한 데이터베이스와 컬렉션 관리

몽고DB 데이터 유형

BSON: JSON 기반으로 날짜형, 객체형 등 추가 데이터 타입 지원.

주요 데이터 유형

• 내장 문서(객체형): 문서 안에 다른 문서를 포함. 데이터 중복 발생 가능.
• 배열형: 배열 안에 다양한 데이터 유형 저장 가능.
• 날짜형: 자바스크립트 Date 객체로 저장.
• 객체 ID형: _id 필드로 문서 고유 식별. ObjectId 함수로 자동 생성.

​

​

​

​

​

13.2. 몽고DB 실습

2.2 몽고DB 쉘을 이용한 데이터베이스와 컬렉션 관리

ObjectId 구성

• 12바이트의 고유 값:
• 4바이트: 타임스탬프.
• 5바이트: 서버 및 프로세스 식별 값.
• 3바이트: 카운터 값.

TIP: _id 필드는 기본적으로 색인이 생성되어 고유성을 보장.

​

​

​

​

​

13.3. 컬렉션 문서 관리 명령문

3.1 컬렉션 문서 삽입

쉘을 통해서 컬렉션 안에 문서를 삽입, 검색, 수정, 삭제하는 그림 13-10과 같은 명령어의 사용 방법을 살펴 보자.

​

​

​

​

​

​

13.3. 컬렉션 문서 관리 명령문

3.1 컬렉션 문서 삽입

1. 단일 문서 삽입: insertOne()

• insertOne()은 컬렉션에 하나의 문서를 추가하는 명령어.
• _id 값을 명시하지 않으면 MongoDB가 자동 생성.
• 예제: cinemadb 데이터베이스의 비회원 컬렉션에 두 개의 문서 추가.
• 같은 내용의 문서가 중복 입력될 수 있음.

​

​

​

​

​

​

13.3. 컬렉션 문서 관리 명령문

3.1 컬렉션 문서 삽입

2. 복수 문서 삽입: insertMany()

• 배열 형태로 여러 문서를 동시에 추가.
• 모든 문서에 원자성이 보장되지 않음.
• 반환 값은 입력된 문서들의 ObjectId 배열 형태.

명령어 옵션

• insert()는 단일 및 복수 문서 삽입 가능.
• find().pretty()는 복잡한 문서 내용을 정리하여 출력.

​

​

​

​