KPT 회고법

• Keep : 만족하며 이어나갈 부분
• Problem : 개선이 필요한 부분
• Try : 문제 해결을 위한 action

자격증

2025년 동안 Opic응시, 빅분기 필기, 정처기를 취득했다. 처음에는 그냥 남이 하니까라는 생각으로 하고 전날 준비하는 등(학교 전공공부를 해놔서 다행..) 다이나믹하게 했는데 Opic 점수가 아시운 것을 제외하면 괜찮은 것 같다.

다만, 이렇게 살면 안된다고 느꼈다. 이번에는 원하는 도메인에 대한 자격증도 취득해보고 Opic 점수도 올려봐야겠다.

취업 준비

2025년은 사실 취업 준비를 위해 서류는 열심히 썼지만 해당 기업이 먼지도 모르고 그냥 gpt를 통해 2시간 동안 살피고 제출하는 것이 반복되었다. (실제 자소서만 생각하면 사실 1시간정도만 쓰는.... 대참사..) 그 과정에서 중고신입이라는 명목 하에 서류 합격이 어느정도 있지만 지나고 나니 뭔가 믿는 구석 있는 듯 노력하지 않은 것 자체에 아쉬움이 커지는 것 같다. 실제로 면접도 준비를 전 날 새벽에 준비하는 등 나태한 나였따..

2026년에는 다음과 같이 준비하려 한다.

• 기업 분석 스터디
• 면접 스터디
• 자소서 스터디

지금 자소서 스터디는 진행 중이고 기업 분석, 면접 스터디는 내가 한 번 주최해서 해볼려고 한다. 책임감이 부여되는 순간 그래도 피해를 끼치지 않기 위해 노력하는 것 같아서 남들을 이용?이 아닌 함께 준비해보려 한다 ㅎㅎ

개발

2025년에는 진짜 개발을 거의 하지 않았다. 1~3월에 진행한 사이드 프로젝트 외에는 아무것도 하지 않았다... 2026년에는 사이드 프로젝트부터 시작해서 뜻이 맞는 사람들과 해커톤, 공모전도 나가보고 어플리케이션 운영도 하고 싶다.

도서

책, 책, 책을 읽읍시다!! 2025년에는 인문학적 책만 4권 읽었다... 턱없이 부족한 것 같고 시간이 지나니 사실 기억이 나지 않는다..

2026년에는 개발 책은 매달 한 권씩 읽고 블로그로 정리해보고, 다른 책은 읽고 노션에 독서기록으로 남겨서 매달 두 권씩 읽도록 해봐야겠다... 매일 지하철 타면서 폰은 자제하고 책을 다시 읽어야겠다..

2026년의 미래를 정리하면 다음과 같이 노력하려 한다. 너무 많이 쓰기보다 지금 내가 열망하는 것에 맞춰서 할 수 있는 대로 작성해보았다.

2026년

• 취업 활동

  • 스터디 운영 (자소서, 면접)
  • 매일 코딩테스트 준비
  • 이력서 기반 재활 프로젝트

• 개발

  • 사이드 프로젝트 진행
  • 해커톤 및 공모전 참여해보기
  • 매일 코테 2문제

• 영어

  • 텝스
  • 오픽 AL

• 독서

  • 개발도서 매달 한 권씩 읽고 정리
  • 인문, 자기계발 도서 매달 한권 씩 읽고 독서 기록

나에게는 다사다난하고 많은 변화가 있던 2025년은 이제 보내주고 새롬게 2026년을 맞이하며 같이 열심히 하는 사람들과 행복한 2026년이 되도록 노력해야겠다.

본 글은 메타코드 M에서 제공하는 강좌의 내용이 포함되어 있습니다.

추천 시스템을 설계할 때에는 Collaborative Filtering, MF와 같은 베이스 라인의 모델을 구축하여 성능 테스트를 진행한 성능을 고도화 하기 위한 노력을 진행합니다.

이를 개선하는 방법은 주로 다음 두 방향의 방법이 존재합니다.

• DeepLearning
• Regression

이번 글에 정리할 내용은 Deep Learning 모델에 대해 설명하빈다.

Deep Learning

• 신경망은 사람의 뇌를 모방한 구조로 여러 레이어로 구성되어 있고 각 레이어를 통해 데이터 처리 및 복잡한 패턴을 찾아낼 수 있습니다.
• 중간 레이어에서 특징 추출을 자동으로 수행합니다.
• 이미지, 음성, NLP 등에서 복잡한 패턴을 인식하는 능력이 뛰어납니다.

DNN (Deep Nueral Network)

딥러닝 기반 회귀모델로 해당 실습에서는 다음의 구성을 지닌다.

• ReLu 활성화 함수를 통해 3개의 은닉층에서의 값을 처리한다. 각 은닉층은 64, 32, 16개의 노드를 지닌다.
• Batch Normalization, Dropout 등의 정규화 기법을 사용한다.
• 입력층은 총 128개의 노드로 구성되어 있다.

from keras.models import Sequential
from keras.layers import Dense, Dropout, BatchNormalization
from keras.optimizers import Adam
from keras.callbacks import EarlyStopping, ReduceLROnPlateau

# Define the model
model = Sequential()

model.add(Dense(128, activation='relu', input_shape=(X_train.shape[1],))) # fully connected, 레이어 입력층 선언
model.add(BatchNormalization()) # 레이어의 출력을 정규화하여 학습을 안정적으로 만듦
model.add(Dropout(0.2)) # 랜덤하게 20% 가중치 삭제

model.add(Dense(64, activation='relu'))
model.add(BatchNormalization())
model.add(Dropout(0.2))

model.add(Dense(32, activation='relu'))
model.add(BatchNormalization())
model.add(Dropout(0.2))

model.add(Dense(16, activation='relu'))
model.add(BatchNormalization())
model.add(Dropout(0.2))

model.add(Dense(1)) #출력층으로, 1개의 노드만 가짐. 출력값이 하나(연속형 값)로

# learning_rate=0.01 학습 속도, 학습이 진행될수록 decay=0.01를 통해 학습률이 점점 감소
optimizer = Adam(learning_rate=0.01, decay=0.01)
model.compile(optimizer=optimizer, loss='mean_squared_error')

early_stopping = EarlyStopping(monitor='val_loss', patience=5, min_delta=0.001) #reduce_lr = ReduceLROnPlateau(monitor='val_loss', factor=0.5, patience=3, min_lr=0.0001)

model.fit(X_train, y_train, epochs=20, batch_size=256, validation_split=0.2,
          callbacks=[early_stopping, reduce_lr])

Neural Collaborative Filtering (NCF)

• Collaborative Filtering을 신경망 구조로 확장하여, 유저와 아이템 간의 비선형 관계를 모델링할 수 있도록 한다.
• 유저의 latent factor와 item의 latent factor를 찾아내 학습한다.

Tranditional Collborative Filtering vs NCF

• 기존의 Tranditional Collaborative Filtering은 선형 모델에 의존
• NCF는 MLP를 통해 비선형 구조를 처리하며 이러한 과정에서 유저와 아이템 간의 latent factor를 포착할 수 있다. 즉, 좀 더 좋은 표현공간으로 특징을 전이하여 처리한다고 볼 수 있다.

# Neural Collaborative Filtering model
n_latent_factors = 64
user_input = Input(shape=(1,))
item_input = Input(shape=(1,))

user_embedding = Embedding(n_users, n_latent_factors)(user_input)
user_vec = Flatten()(user_embedding)
item_embedding = Embedding(n_items, n_latent_factors)(item_input)
item_vec = Flatten()(item_embedding)

concat = Concatenate()([user_vec, item_vec])

dense = Dense(256, activation='relu')(concat)
dense = BatchNormalization()(dense)
dense = Dropout(0.2)(dense)

dense = Dense(128, activation='relu')(dense)
dense = BatchNormalization()(dense)
dense = Dropout(0.2)(dense)

output = Dense(1)(dense)

model = Model([user_input, item_input], output)
model.compile(optimizer='rmsprop', loss='mean_squared_error')

model.fit([X_train['user_id_mapped'], X_train['isbn_mapped']], y_train, epochs=2, batch_size=128, validation_split=0.2)

y_pred = model.predict([X_test['user_id_mapped'], X_test['isbn_mapped']])

해당 글에서 배울 내용은 IoC, DI에 대해 알아볼 예정입니다. 이 두 특성은 스프링에서 모든 기능의 기반으로 두고 있습니다.

IoC

Inversion of Control의 줄인 표현으로 제어의 역전이라고 부릅니다. 메소드나 객체의 호출작업을 개발자가 직접 생성하거나 제어하는 것이 아니라 외부에서 관리하는 객체를 가져와 사용하는 것을 의미합니다.

일반적인 경우 제어권에 대해 논할 때에는 개발자가 직접 의존성을 다음과 같은 함수처럼 생성하여 제어합니다.

public class IoCController {
    private IoCService IocService = new IocService();
}

위의 참고글과 다르게 아래는 스프링 컨테이너가 객체를 관리하는 코드입니다.

public class IoCController {
    private IocService iocService;
}

일반적인 상황에서 개발자가 의존성을 직접 생성하고 제어하는 방법과 다르게 IoCController를 직접 생성하는 것이 아니라 외부에서 해당 의존성을 가져옵니다.

DI

스프링에서는 위에서 설명한 것 처럼 의존성 관리를 위해서 IoC를 사용합니다. 그리고 이를 구현하기 위해 사용하는 방법으로 DI가 있습니다. DI는 Dependency Injection을 줄인 표현으로 의존성 주입이라고 부릅니다.

DI는 객체 지행 프로그래밍에서 객체 간의 의존 관계를 외부에서 주입하는 디자인 패턴으로 외부에서 생성된 객체를 위의 IOC처럼 주입받아 사용하여 객체 간의 결합도를 낮추고, 유연성과 재사용성에 초점을 맞추었습니다.

즉, 이를 통해 저희가 Spring을 사용할 때 얻을 수 있는 효과가 객체의 생성과 사용을 분리할 수 있습니다.

주로 스프링에서는 어노테이션을 사용하여 의존성을 주입하는데 가장 일반적인 어노테이션으로는 @Autowired, @Resource, @Repository등이 존재합니다.

추후 어노테이션에 대해서, 어떤 종류들이 있는지 포스트가 올라올 예정입니다!

8.1 뷰

뷰

여기서 말하느 뷰는 관계 데이터베이스 시스템의 뷰로 다른 릴레이션으로부터 유도된 릴레이션으로 가상 릴레이션이다.

• 3단계 아키텍쳐의 외부 뷰와 다르다.
• 데이터베이스의 보안 메카니즘
• 복잡한 질의를 간단하게 표현하는 수단
• 데이터독립성을 높이기 위해 사용된다.
• 데이터를 검색하거나 갱신할 수 있는 동적인 창의 역할을 한다.

스냅 샷

• 어느 시점의 SELECT문의 결과를 릴레이션 형태로 저장
• 어떤 시점의 조직체의 현황

• 기본 릴레이션에 대한 SELECT 문으로 정의된다.
  • 애트리뷰트들 명시 생략시 SELECT절에 열거된 애트리뷰트들의 이름과 동일한 애트리뷰트들이 포함.
  • 산술식, 집단 함수가 사용된 애트리뷰트 존재시 조인이 포함.
    • 두 개 이상의 다른 릴레이션에서 가져오기에 이름이 같을 수도 있다.
    • 뷰 정의 시 모든 애트리뷰트들의 이름을 지정해야한다.

CREATE VIEW  뷰이름 [애트리뷰트들]
AS SELECT문
[WITH CHECK OPTION];

과정

관계 DBMS 에서 뷰 사용시의 과정

• SELECT문 검색
• 뷰의 접근 권한 검사
• 뷰에 대한 질의를 기본 릴레이션에 대해 동등한 질의로 변환한다.

장점

• 뷰는 복잡한 질의를 간단하게 표현 가능

기본 릴레이션 사용 뷰 사용

• 데이터 무결성 보장에 활용
  • 투플이 뷰를 정의하는 SELECT문의 WHERE절 기준에 맞지 안흥면 사라진다.
  • WITH CHECK OPTION : VIEW 정의 만족하는 경우에만 UPDATE 가능
• 데이터 독립성 제공
  • 구조가 바뀌어도 기존의 질의를 다시 작성할 필요설을 줄이는데 사용될 수 있다.
• 데이터 보안 기능 제공
  • 직접 접근이 아닌 뷰를 통해 데이터를 접근하도록 하기 때문에 보안 메커니즘으로 사용될 수 있다.
  • 일부 애트리뷰트들 또는 일부 투플들을 검색하는 SELECT문으로 정의되기에 기본 릴레이션의 일부만 검색
• 동일 데이터에 대해 여러가지 뷰를 제공한다
  • 특정 기준에 따라 데이터를 접근하도록 한다.

갱신

뷰에 대한 갱신도 기본 릴레이션에 대한 갱신으로 변환된다.

• 한 릴레이션 위에서 정의된 뷰에 대한 갱신

  나머지는 NULL 값으로 입력된다.

• 두 개의 릴레이션 위에서 정의된 뷰에 대한 갱신 ~

EMP_PLANNING 은 두 개의 릴레이션위에서 정의된 것으로 대부분 갱신이 불가능하다

하지만, JOIN이 정의된 VIEW라도 뷰의 한 투풀이 기본 릴레이션의 한투플과 정확하게 대응되는 경우 갱신을 허용해준다 (기본키가 NULL이 아닌 전제 하에)

• 집단 함수 등을 포함한 뷰

개별 투플값 임의로 변경하기에 논리적으로 타당하지 않아 DBMS에서 거절한다.

갱신이 불가능한 뷰

• 기본 키가 포함되지 않은 뷰
• 뷰에 포함되지 않은 애트리뷰트가 NOT NULL이 지정되었을 때
• 집단함수가 포함된 뷰
• 조인이 정의된 뷰

8.2 시스템 카탈로그

데이터 베이스의 객체(사용자, 릴레이션, 뷰, 인덱스) 와 구조들에 대한 모든 데이터

• 메타데이터라고도 부른다,
• 사용자 및 질의 최적화 모듈 등 DBMS 자신의 구성용소에 의해서 사용된다.
• 관계 DBMS마다 서로 다른 형태로 시스템 카탈로그 기능을 제공한다,
• 데이터 사전, 시스템 테이블이라고도 부른다.

협조 필터링이라 불리는 이것은 인터렉션 정보를 사용하여 추천을 진행하는 방식으로 다음 두 가지로 나뉩니다.

• 메모리 기반 방법 : 이미 있는 데이터를 기반으로 필터링 하는 것
  • 사용자-사용자 메모리 기반 방법 : 추천받을 사용자와 선호도가 비슷한 사용자의 내역에 착안하여 추천을 수행하는 방법
  • 아이템-아이템 메모리 기반 방법 : 추천받을 사용자가 선호하는 아이템에 착안하여 추천을 수행하는 방법
• 모델 기반 방법 : 기계학습을 적용한 필터링 방식으로 사용자와 아이템이 숨겨진 특성 값을 계산하여 필터링하는 것

메모리 기반 방법 알고리즘

해당 챕터에서는 주로 사용자-사용자 메모리 기반 방법으로 협조 필터링에 대해 설명합니다.

기호 데이터

사용자로부터 얻은 아이템에 대한 선호도 정보

해당하는 데이터를 얻는 방법은 다음 두가지가 존재합니다.

• 명시적 피드백
  • 사용자에게 아이템의 좋고 싫음 혹은 괌심 여부에 관해 질문하고 답변을 받아 획득하는 방법
• 암묵적 피드백
  • 사용자가 구입, 즐겨찾기 등록, 열람 등의 행동 이력을 통해 사용자의 관심을 추정하여 획득하는 방법

아이템의 내용을 나타내는 정보를 사용해 추천하는 알고리즘으로 사용자가 선호하는 정보를 기반으로 내용이 비슷한 아이템을 계산함으로써 추천합니다.

예를 들어, A가 교보문고에서 백엔드 관련 도서 중 Spring에 대한 책을 주로 클릭하였다면 (여기서 클릭을 선호한다는 개념을 잡고 개발했다고 가정합니다) 추천 책의 리스트로 Spring과 관련된 도서들을 추천합니다.

이를 Content-based filtering(내용 기반 필터링)이라고 합니다.

여기서 사용하는 데어터는 다음과 같습니다.

• 사용자 프로필
• 아이템 특징과의 유사도

사용자 프로필

해당 데이터는 사용자들이 좋아하는 아이템의 특징을 나열한 리스트의 형태로 표현 가능합니다.

예를 들어 사용자가 선호하는 개발 직군 및 기술이 프로필에 포함됩니다.

• User 1

  • 직군 : 백엔드 개발자
  • 기술 : Spring, Java

• User 2

  • 직군 : 프론트엔드 개발자
  • 기술 : react, typescript

아이템의 경우는 다음과 같을 수 있습니다.

• Item 1
  • 이름 : 스프링 부트3 백엔드 개발자 되기
  • 기술 : Spring Boot, Spring, Java
  • 대상 : 백엔드 개발자
• Item 2
  • 이름 : Flutter 생존 코딩
  • 기술 : Flutter, Dart
  • 대상 : 프론트엔드 개발자

위와 같이 정리되어 있는 아이템을 사용자에게 추천한다고 하는 경우 사용자 1의 프로필에 주목하여 추천하는 정보는 Item1, 사용자 2에게 추천되는 도서는 Item2이다.

여기서 User2와 Item2는 완벽하게 일치하지 않지만 유사도가 높기에 충분히 추천될 수 있습니다.

아이템 특징 획득

Content-based filtering에서 사용할 아이템의 특징을 획득하는 방법은 다음과 같습니다.

• 책
  • 제목
  • 장르
  • 문자 수
  • 작가
  • 출판 일
• 음악
  • 작곡자, 작곡 연도
  • 음성분석을 통해 음 높이, 음색, 음량 등이 수치화된 데이터
• 이미지
  • 색채 정보
  • 피사체 형태

위와 같이 상품, 아이템에 따라 멀티미디어 처리등의 추가적인 방식을 통해 아이템의 특징을 데이터화시킬 수도 있습니다.

사용자 프로필 획득

Content-based filtering에서 사용할 사용자 프로필을 획득하는 방법은 다음과 같습니다.

1. 간접 지향형

• 과거 행동 이력에 기반해 사용자 프로필을 작성합니다.
• 예를 들어 사용자가 백엔드 개발 관련 도서를 많이 구매하였다면 해당 아이템의 특징(백엔드)을 해당 사용자가 선호하는 것으로 판단하여 프로필을 구성합니다.
  • 해당 내용은 사용자가 그 순간의 선호하는 부분이 바뀔 수 있기에 유저의 니즈를 정확히 맞추지 못합니다. 예를 들어 사용자가 AI에 관심을 가지게 된 경우에는 이를 반영하지 못합니다.

2. 직접 지정형

• 유저가 선호하는 아이템을 명시적으로 지정하여 이를 이용합니다.
• 예를 들어 사용자가 AI에 관심을 가지고 해당 부분을 선호하는 분야로 잡는다면 해당 관련 도서가 추천됩니다.
• 이런 명시적인 선호도 지정은 서비스 가입 직후 온보딩 또는 마이 페이지 등에서 수행됩니다.

추천 시스템 개발에 필요한 3가지 스킬

• 비즈니스 문제 해결 능력
• 데이터 사이언스 능력
• 데이터 엔지니어링 능력

비즈니스 문제 해결 능력

추천 시스템 도입시에 기대할 수 있는 무언가를 정의해야합니다.

즉, 추천 시스템을 도입함으로써 사용자의 어떤 행동 변화를 기대하는가에 관한 KGI, KPI 책정이 되어야합니다.

(추가보충)

데이터 사이언스 능력

위에서 비즈니스 목표를 설정하였다면 이를 달성하기 위한 이상적인 추천 시스템을 실제 구현 가능한 시스템으로 만들어낼 수 있는 것에 직결되는 능력입니다. 이는 데이터의 양과 종류, 비즈니스마다 구현의 복잡도가 달라집니다.

오픈 소스 소프트웨어로 공개된 사용 가능한 알고리즘 다수 존재하지만 아이템 혹은 유저 정보를 고려하기 어려운 경우 독자적으로 정식화한 알고리즘을 검토하고 코드화 해야합니다.

데이터 엔지니어링 능력

서비스의 비즈니스 요건을 고려해 구현하고 안정적으로 가동시켜야 합니다. 예를 들어 추천 리스트 작성 연산이 24시간 안에 종료되어야 하는 경우 추천 모델을 만들어도 계산에 100시간이 걸린다면 실제 비즈니스에서 사용이 불가능합니다.

그러기 위해 필요한 데이터 엔지니어링 능력으로 다음의 처리(파이프라인)과정을 조정할 수 있어야합니다.

• 처리를 병렬화
• 데이터베이스 설계
• 튜닝

프로젝트 진행 방법

해당 책에서는 위의 역량을 가진 사람들이 협업하는 과정을 7단계의 프로세스로 나누어 설명합니다.

1. 과제 정의
2. 가설 수립
3. 데이터 설계/수집/가공
4. 알고리즘 선정
5. 학습/파라미터 튜닝
6. 시스템 구현
7. 평가 및 개선

개발자가 담당하는 부분은 3, 4, 5, 6, 7 이고 비즈니스 부서가 담당하는 부분은 1, 2, 7 입니다.

하지만 여기서는 1, 2, 7의 내용 또한 가볍게 다룰 것 입니다. 왜냐하면 비즈니스 성격을 이해하고 시작하는 능동적인 개발자가 되는 것이 저는 매우 중요하다고 생각하기 때문입니다. 실제로 스타트업에서 개발을 진행하였을 때 이 비즈니스에 대한 주입도 많이 사수분에게 받았고 이것이 내가 개발하는 것에 어떤 영향을 서비스에 미치는지에 대한 영향을 느꼈기 때문입니다.

과제 정의

매출 2배, 회원 등록 2배는 명확하게 다른 비즈니스 상의 목적입니다. 이에 대한 기준을 명확히 정해 KPI를 결정하여 현재와 비교해 적절한 조치를 정리하는 과정이 필요합니다.

가설 수립

각 과제를 해결하는 방법 및 그것을 실현하기 위한 비용을 검토하여 비용 대비 효과가 높은 것부터 실행합니다.

데이터 설계/수집/가공

현재 어떤 데이터가 축적되어 있는지 정리하는 과정입니다. 주로 1장에서 말한 콘텐츠 정보 와 인터렉션 정보를 다룹니다.

우선 자사 서비스에서 갖고 있는 데이터를 정리 후 해당 데이터를 통해 추천 시스템을 구축할 수 있는지에 대한 검토를 진행합니다. 초기 단계의 서비스라면 인터렉션 정보가 없기에 콘텐츠 정보를 이용해서 만들기도 합니다.

예를 들어 책에 '자기 계발', 'IT'라는 카테고리를 나타내는 태그가 부여되어 있는 경우에 해당 테그를 이용해 유저가 선호하는 태크의 책을 추천하는 시스템을 생각해봅니다. 해당 데이터가 부족한 경우에는 크라우드 소싱을 활용해 추천 시스템을 활용할 수 있는 형태로 정리해야합니다.

크라우드 소싱 업활동의 전 과정에 소비자 또는 대중이 참여할 수 있도록 일부를 개방하고 참여자의 기여로 기업활동 능력이 향상되면 그 수익을 참여자와 공유하는 방법

알고리즘 선정

알고리즘 계산 시간, 필요 데이터, 요구되는 예측 정확도 등 다양한 관점 중 비즈니스 목표에 적합한 것을 선택합니다.

주로 서비스 초기에는 간단한 알고리즘(적은 비용)으로도 일정 정확도까지 도달하기에 이를 먼저 구현하는 것이 효율적입니다.

비용 대비 효과의 관계

(그림)

학습/파라미터 튜닝

추천 시스템의 학습과 튜닝을 수행하고 실제 서비스로 출시 전에는 과거 데이터를 통해 추천 시스템의 좋고 나쁨을 검증합니다.

개발자가 이를 수행하고 비즈니스 관련 부서와 의논할 때에는 결과의 구체적인 사례를 제시하면 원만한 커뮤니케이션이 가능합니다. 예를 들어 이전 알고리즘의 추천 아이템 그룹과 변경된 알고리즘의 추천 아이템 그룹의 사례를 제시한다면 이러한 튜닝에서의 결과를 PM 과의 소통과정이 원만하게 이루어질 수 있습니다.

또한, 이렇게 온라인에서 검증시에는 데이터 편향에 주의해야 합니다.

예를 들어 다음의 경우가 존재합니다.

• 아마존 : 별을 통한 평가 데이터에서는 보통 상품에 호감을 가진 사람만 평가하기에 별 5개 많다는 편향이 존재합니다.
  • 해당 책을 구매한 사람은 많지만 실제 평가는 81명
• 검색 엔진을 이용한 추천 시스템 : 검색 엔진의 경우 상위에 나타나는 것이 클릭하기 쉽고 상대적으로 하위에 나타나는 것은 클릭하기 어렵습니다. 이 엔진의 이력 기반 추천 시스템을 만들 시 검색 결과 상위의 것이 더 잘 추천됩니다.

시스템 구현

온라인 상에 보일 수 있는 좋은 추천 알고리즘을 완성한 후 이를 실제 시스템에 조합합니다. 시스템에서 고려할 부분은 다음과 같습니다.

• 추천 알고리즘의 학습
• 예측 변경 빈도
• 신규 아이템 또는 사용자에 대한 추천 방식
• 추천에 연관된 데이터 파이프라인 설계

실제 자주 사용되는 사례로는 배치 추천, 실시간 추천이 존재합니다.

• 배치 추천 : 1일 1회, 1주 1회 등 정해진 시점에 해당 시점의 정보를 통해 추천 목록을 업데이트
• 실시간 추천 : 사용자의 직전 행동 이력을 즉시 반영해 추천 목록 생성

평가 및 개선

추천 기능을 출시하고 이것이 효과가 있는지 검증하는 단계입니다.

추천 시스템만 보는 것이 아닌 전체 시스템을 보고 악영향이 없는지를 판단해야 합니다.

• 실제 사례로 추천 시스템 도입 후 로그 확인 시 추천 시스템을 통한 매출은 증가하였지만 검색 사용자가 급격히 감소하며 전체적으로는 증가되는 부분이 없음을 확인하였습니다.

Recommendation Systems

추천 시스템은 우리가 다음에 무엇을 하면 좋을지 의사 결정을 지원하는 기술입니다.

우리의 삶에는 다음과 같이 포함되어 있습니다.

• 아마존의 customers who viewed this item also viewed
• 유튜브 맞춤 동영상
• 트위터 팔로우 추천
• 스포티파이 추천 플레이리스트
• 넷플릭스 추천 시스템

위의 서비스에서는 처음 회원가입 시에 막대한 양의 데이터 중 특별한 키워드 없이도 마음에 드는 아이템을 마주할 수 있습니다.

해당 책에서의 추천 시스템 정의 여러 후보 가운데 가치 있는 것을 선정해서 의사 결정을 지원하는 시스템

역사

1990년대 인터넷의 발전과 함께 다양한 것이 정보화되면서 가치있는 것을 선정하는 기술이 중요해졌습니다. 그 당시 마우스, 이더넷 등을 발명한 제록스 팔토알토 연구소의 골드버그는 날로 늘어가는 전자 메일 중 단순한 필터 처리만으로 유익한 메일을 찾는 것이 어려웠기에 협조 필터링을 사용한 메일 스코어링을 제안하며 탄생하였습니다.

이후 아마존에서의 추천 시스템, 넷플릭스의 추천 알고리즘 경쟁 대회 등 학계나 업계에서 대규모 데이터에 대한 예측 정확도를 효율적으로 높일 수 있는 연구가 가속되어 현재 저희가 사용하는 서비스에 녹아들어 있습니다.

요소

추천 시스템의 요소에 있어 다음의 세 가지 요소가 존재합니다.

• 입력
• 프로세스
• 출력

입력

입력은 데이터를 들어오는 행위를 의미하는데 추천 시스템에서 사용하는 데이터는 다음 두가지가 존재합니다.

• 콘텐츠
  • 사용자 : 나이, 성별, 주소 등의 프로필 정보
  • 선호하는 카테고리 혹은 가격대
  • 아이템 : 카테고리, 상품 설명문, 발매일, 가격, 제작자 등
  • 내용 기반 필터링(Content-based filtering)의 데이터 입력으로 사용
• 인터랙션 : 사용자가 서비스 안에서 행동한 이력 데이터
  • 열람, 구입, 북마크, 평가 등
  • 주로 사용자가 서비스 안에서 행동할수록 축적
  • 협조 필터링(collaborative filtering)의 데이터 입력으로 사용

인터렉션 데이터가 실시간으로 업데이트되기에 collaborative filtering이 사용자의 기호를 더 적극적으로 반영하는 경향이 있습니다. 하지만 행동이력이 없는 경우 콘텐츠 데이터를 사용한 Content-based filtering으로 추천하는 경우가 존재합니다.

위의 처음 단계에서 추천이 어려워지는 것을 콜드 스타트 문제 라고도 부릅니다.

프로세스 (추천 설계)

입력 데이터를 활용해 추천하는 방법

개요 추천

• 개인화가 없는 상태
• 아마존 판매 순위와 같이 모든 사용자에게 동일한 내용을 제시합니다.
• 신규 아이템순, 낮은 가격순, 높은 인기순 등의 개인이 아닌 종합된 데이터를 입력으로 하여 추천합니다.

  연관 아이템 추천

• ex) 이 상품을 확인한 사람은 이런 상품도 확인했습니다.
• 각 아이템 사이의 유사도를 사용합니다.
• Content-based filtering : 아이템 설명문, 카테고리 정보 등의 콘텐츠 정보를 기반으로 설계
• Collaborative filtering : 사용자 행동 이력을 기반으로 유사한 데이터를 제공하도록 설계, 카테고리나 키워드로 표현하기 어려운 분위기나 콘셉트를 유사도에 반영

  아이템 유사도 판단 관점

아이템 유사도를 판단하는 관점은 다음 두 관점이 존재합니다.

1. 비슷한 아이템일 가능성
2. 함께 구입할만한 가능성

프린터를 구매한다고 하였을 때를 가정해보자 1번 관점에서는 성능이나 가격이 유사한 프린터를 제공받을 수 있다. 2번 관점에서는 프린터를 구매했으니 카트리지 같은 소모품, 컴퓨터 등이 제공될 수 있습니다.

해리 포터 문제

추천의 개념은 인기와도 연관되는데 특정 시기에 많은 사람이 해리포터 서적을 다른 아이템과 구매하면 모든 아이템의 추천 아이템으로 해리 포터가 추천되기도 합니다.

즉, 해리 포터 서적 + 아이템 구매 -> 모든 아이템 추천에 해리 포터등장

이러한 현상은 유저들에게 추천하는 방향이 잘못될 수 있기에 인기 아이템 (해리포터)의 영향을 제거하기도 해야합니다.

개인화 추천

• 유저의 프로필이나 행동 이력을 기반으로 각 유저에게 맞추어 추천하는 것
• 방법은 다음 두 가지가 존재합니다.
  • 콘텐츠기반으로 하는 방법
  • 인터렉션 데이터를 활용하는 방법

콘텐츠 기반 추천

나이나 거주지 등의 프로필 정보를 기반으로 하여 그에 맞는 아이템 그룹 설계

예를 들어 구인 추천의 경우 유저의 위치 가까운 곳의 구인 정보를 추천합니다.

인터렉션 데이터 기반 추천

유저와 아이템의 인터렉션 데이터를 기반으로 추천하는 것으로 Collaborative filtering 기술 이용하며 유저의 과거 행동 이력을 통해서 추천 아이템 그룹을 설계

1. 열람 이력 그대로 표시
   • 구현 비용이 낮으며 그에 비해 효과는 높습니다.
   • 유튜브, 멜론, 아마존 등에도 사용되고 있습니다.
2. 열람 이력과 연관 아이템 추천 구조 조합
   • 유저가 마지막에 열람한 아이템과 비슷한 아이템 그룹을 연관 아이템 추천 구조로 추출합니다.
   • 유저의 흥미나 기호를 실시간으로 반영하기에 클릭 또는 구입 예측 성능이 뛰어납니다.

출력 (추천 결과 제시)

유저에게 추천 아이템을 제시하는 방법입니다. 비즈니스적 관점에서 중요하며 제시 방법이 나쁘면 유저의 행동 자체를 이끌어 낼 수 없습니다.

다음의 방식이 존재합니다.

• 웹 사이트에서 제시
• 메일 발송
• 우편으로 추천 아이템 쿠폰 전달
• 추천 이유 곁들이기

위 세 개의 틀 속에서 현재 가지고 있는 데이터 파악, 알고리즘을 통한 비즈니스적 영향, 제시 방법을 사용하기 위한 유저의 행동 정리를 통해 새로운 시각을 갖춰나가야 합니다.

검색 시스템과 추천 시스템

추천 시스템과 비슷한 개념으로 이 둘의 역할 차이를 이해하는 것은 중요합니다.

검색 시스템

키워드를 입력해 원하는 문장을 찾아내는 기술

초기에는 키워드와 완전히 일치하는 것을 포함한 문자만 찾아냈지만 후에는 유사어를 포함하고 키워드 속 사용자의 의도를 포함하여 정보를 효율적으로 검색하기는 방향으로 발전하였습니다.

페이지랭크 검색에 사용되는 알고리즘으로 문장의 단어뿐만 아니라 페이지 사이에 존재하는 링크 정보를 사용해 중요한 링크가 더 많이 모인 웹 사이트일 수록 중요도가 높다고 판단하는 알고리즘입니다.

오늘날 구글 검색, 아마존 상품 검색, 트위터 게시물 검색과 같은 시스템에 포함되어 있습니다.

추천 시스템과의 비교

둘 다 수많은 데이터 중 가치 있는 것을 선택하는 것이지만 목적에 따라 다음 두 가지의 타입으로 나뉩니다.

Pull 타입

• 검색 시스템이 이에 속합니다.
• 사용자가 미리 마음에 드는 아이템을 파악하고 있는 경우가 많음
• 키워드(쿼리) 입력 존재
• 연관 아이템 추천 방법으로 입력된 키워드를 통해 의도를 추측하여 추천
• 유저입장 능동적 시스템
• 기존에는 개인화가 없지만 최근 개인화 서비스가 증가

  Push 타입

• 추천 시스템이 이에 속합니다.
• 사용자가 미리 마음에 드는 아이템이 무엇인지 파악하지 않는 경우가 많음
• 키워드 입력이 없음
• 사용자 프로필 혹은 과거 행동이력으로 추측
• 유저입장 수동적 시스템
• 개인화하는 경우가 다수 존재

검색과 추천의 경우는 한쪽만 조합해서는 충분하지 않으며 서로 협력해서 만들어야 합니다. 실제로 유튜브, 아마존, 넷플릭스 서비스는 두 시스템을 전부 포함하고 있습니다. 넷플릭스에서는 추천 서비스를 경유한 시청이 80%, 아마존에서는 추천 시스템을 경유한 매출이 35%로 2018년에 나온 이력이 있습니다. 이는 각 시스템의 사용 비중은 서비스에 따라 다름을 의미하며 이를 어떻게 조합할지는 비즈니스 모델, 사용자 경험 설계에 따라 다르기에 이 능력 또한 중요합니다.

연산자에 대해 다루기 전에 간단한 용어에 대한 설명을 먼저 하겠습니다.

피연산자 : 연산자가 연산을 수행하는 대상입니다. 4 * 2 라는 연산을 한다면 4와 2는 피연산자입니다. 단항 연산자 : 피연산자가 하나인 연산자입니다. 이항 연산자 : 두 개의 피연산자를 받는 연산자입니다.

수학 연산자

Javscript에서 지원하는 수학 연산자는 다음과 같습니다.

• 덧셈 +
• 뺄셈 -
• 곱셉 *
• 나눗셈 /
• 나머지 %
• 거듭제곱 **

나머지 연산자 %

나눈 후 나머지를 반환하는 연산자입니다.

거듭제곱 연산자 **

a ** b 를 연산하면 a 를 b 번 곱한 값을 반환하는 연산자입니다.

console.log(2 ** 4); // 16
console.log(8 ** (1/3)); // 2

2장에서는 이름을 잘 붙여 놓으면 왜 좋은지 그리고 이름을 잘 짓는 간단한 규칙을 소개해보겠습니다.

의도를 분명히 밝혀라

변수나 함수 그리고 클래스 이름은 굵직한 질문에 모두 답해야합니다.

• 존재 이유
• 수행 기능
• 사용 방법

다음과 같은 내용들에 답변이 되지 않고 주석이 필요한 변수는 수정이 필요합니다.

다음은 변수의 예시입니다.

int d; // 경과 시간 (단위: 날짜)

int daysSinceCreation;
int daysSinceModification;

• 변수 d는 아무런 의미를 나타내지 못해 주석이 필요하기에 의도가 드러나지 못한 좋지 못한 변수 예시입니다.
• 아래의 변수들 (daysSinceCreation, daysSinceModification) 경과시간 및 시점에 대한 기준과 측정하려는 값(단위)에 대한 정보가 잘 담겨 있어 의도가 잘 드러난 의미 있는 변수의 예시들 입니다.

다음은 변수말고도 함수에 대한 예시입니다.

// 1
public List<int[]> getThem() {
    List<int[]> list1 = new ArrayList<int[]>();
    for (int[] x : theList)
        if (x[0] == 4)
            list1.add(X);
    return list1;
}

// 2
public List<int []> getFlaggedCells() {
    List<int[]> flaggedCells = new ArrayList<int[]>();
    for (int [] cell : gameBoard)
        if (cell[STATUS_VALUE} == FLAGGED)
            flaggedCells.add(cell)
    return flaggedCells;
}

• 1번의 코드와 2번의 코드의 단순함은 거의 동일합니다. 하지만 코드의 함축성에 있어서 큰 차이를 보입니다.
• 1번의 경우 어떤 정보를 제공하는지 알 수 없습니다.
• 2번의 코드는 다음의 명시적인 코드들을 통해 함수가 하는 일을 빠르게 이해할 수 있습니다.
  • FLAGGED : 깃발이 꽃힌 상태
  • gameBoard : 게임판

그릇된 정보를 피해라

그릇된 단서가 담겨있는 코드는 그 코드의 의미를 흐리기에 프로그래머들은 이러한 행위를 지양하도록 해야합니다. 다음과 같

• 함부로 약어를 사용하지 않습니다.
• 흡사한 이름을 사용하지 않도록 합니다.

의미 있게 구분하라

public static void copyCHars(char a1[], char a2[]) {
    for (int i = 0; i < a1.length; i++) {
        a2[i] = a1[i];
    }
}

• a1, a2 ... aN과 같이 연속적인 숫자를 덧붙이거나 불용어 를 사용한 이름은 그릇된 정보를 제공하지 않으면서 아무런 정보도 제공하지 않습니다. 즉, 의도를 전혀 드러내지 않습니다.

발음하기 쉬운 이름을 사용하라

1. 절약하는 시간이 많아진다.
   • 좋은 이름을 지으려면 시간이 엄청 걸립니다. 하지만

데이터를 표현하고 관리하고 처리하기 위한 구조

스택

• 후입선출 구조 (Last In First Out)
• 아래 사진과 같이 가장 나중에 쌓은 top에 존재하는 데이터만 접근가능합니다.

스택관련 용어

• top : 가장 최신의 데이터
• push : 삽입하는 연산으로 top의 데이터가 변경됩니다.
• pop : 삭제하는 연산으로 top의 데이터가 삭제됩니다.

시간 복잡도

• 삽입 : O(1)
• 삭제 : O(1)
• 탐색 : O(n)

활용되는 예시

• 브라우저 방문기록 (뒤로가기)
• 실행 취소
• 역순 문자열 (문자열 거꾸로 뒤집기)

큐

• 선입선출 구조 (First In First Out)
• 스택과 달리 삽입이 이루어지는 위치와 삭제가 이루어지는 위치가 다릅니다.

큐관련 용어

• front : 가장 최신의 데이터로 해당 위치로 삽입됩니다.
• rear : 가장 오래된 데이터로 해당 위치에서 삭제가 이루어집니다.
• enQueue : 삽입하는 연산으로 해당 데이터가 front의 데이터가 됩니다.
• deQueue : 삭제하는 연산으로 rear의 데이터가 삭제됩니다..

시간 복잡도

• 삽입 : O(1)
• 삭제 : O(1)
• 탐색 : O(n)

활용되는 예시

• BFS 알고리즘
• 캐시 구현

이 글을 보는 대부분은 개발자이겠죠? 요즘은 이러한 지식을 크게 알지 못해도 어느 정도 개발을 진행할 수 있습니다. (저 또한 그렇습니다 ㅎㅎ..) 하지만 인터넷이 어떻게 작동하는지에 대해 잘 아는 것이 실제 서비스를 구축할 때 효율적이고 완벽한 아키텍쳐를 구성하는데 도움이 된다고 생각합니다. 그래서 개발을 시작한지 1년차가 되어가는 저는 자투리 시간을 이용해 이러한 정보들을 기초부터 다시 정리하는 시간을 가지려합니다.

인터넷

Network

• 컴퓨터들이 통신망을 통해 서로 그물처럼 연결된 체계

인터넷은 이러한 네트워크들이 서로 연결되어 형성되는 관계라고 볼 수 있습니다.

예를 들어 철수라는 친구 집에는 철수가 사용하는 휴대폰, 컴퓨터 등으로 형성되어 있는 네트워크가 존재하고, 영희라는 친구 집에는 영희가 사용하는 휴대폰, 컴퓨터 등으로 형성되어 있는 네트워크가 존재합니다. 철수와 영희는 이러한 본인의 네트워크에서도 서로가 소통을 하며 새로운 네트워크를 형성합니다. 이것을 인터넷이라고 볼 수 있습니다.

인터넷의 역사

1960년, 미군 국방부에서 핵 전쟁등의 상황에서도 살아남을 수 있는 분산형 통신망 즉, 네트워크의 목적으로생성되었습니다.

1983년 기점으로 현재와 같은 TCP/IP 기반의 네트워크가 형성되었고 1989년에는 그래픽 환경의 개선, 월드와이드웹(www)의 등장으로 상업적 목적의 온라인 서비스의 추가 및 이용자층이 확산되며 콘텐츠 및 이용자의 면에서 양/질적 팽창이 이루어졌습니다.

이후 1993년 상업적 이용의 허용, 인터넷을 편리하게 사용할 수 있는 최초의 브라우저인 모자이크가 출시되면서 사용자가 폭발적으로 증가되었다고 합니다.

이러한 흐름으로 복잡하고 정교하게 인터넷은 발전해나가면서 현재는 우리 삶에 깊게 녹아들어와 있습니다.

인터넷의 작동 방식

//더 정리 인터넷은 표준화된 프로토콜을 이용해 통신하면서 작동합니다. 여기서의 프로토콜은 기기간 정보를 어떻게 전송할지와 데이터가 안전하게 전송되도록 합니다.

인터넷은 상호 연결된 라우터들이 모인 글로벌 네트워크로 구성되며 해당 라우터들은 서로 다른 장치와 시스템 간의 트래픽을 관리합니다. 인터넷을 통해 데이터를 전달할 대, 데이터들은 작은 패킷단위로 나누어져 라우터로 전송되고 해당하는 라우터는 패킷을 검사하고 목적지를 향해 다음 라우터로 전송해주는 역할을 합니다.

패킷들을 검사하여 안전하게 전달하기 위한 방법으로 인터넷은 다양한 프로토콜을 사용하여 전송합니다.

• TCP : 패킷들이 확실하고 올바른 순서로 전송되도록 하는 역할
• IP : 해당하는 목적지로 패킷들을 전송하는 역할

이러한 프로토콜외에도 DNS, SSL/TLS(Secure Sockets Layer/Transfer Layer Security) 프로토콜과 같은 다양한 프로토콜들이 존재합니다.

프로토콜의 역할

프로토콜 기기 및 컴퓨터간 정보, 데이터의 교환 방식을 정의하는 규칙 체계입니다. 이러한 프로토콜은 인터넷 상에서 데이터 통신에 중요한 역할을 합니다.

위에서 살펴 보았듯 인터넷에는 다양한 프로토콜이 사용됩니다.

• IP (Internet Protocol)
  • 수신 호스트에 패킷들을 전송하느 ㄴ역할
• TCP (Transmission Control Protocol)
• UDP (User Datagram Protocol)
• DNS (Domain Name System)

이러한 표준화된 프로토콜을 이용할 때에 서로 다른 시스템, 기기들이 서로 원활하게 통신할 수 있게 해줍니다.

IP Address and Domain Names

IP 주소 및 도메인이름은 인터넷 작동을 이용할 때 중요한 개념입니다. IP 주소란 하나의 네트워크를 담당하는 디바이스에 부여되는 유일한 식별자로 데이터가 의도된 수신 호스트에서 올바르게 전달할 수 있도록 사용됩니다.

현재 인터넷에서 사용되는 IP 주소 체계로는 IPv4가 있습니다. 그러나 Ipv4는 주소공간 고갈 문제가 발생하여 그에 대한 Ipv6 또한 대표적인 Ip 주소체계로 자리잡았습니다.

Example

• Ipv4 : 192.168.1.1
• Ipv6 : 2001:0db8:85a3:0000:0000:8a2e:0370:7334

도메인 주소는 웹사이트 혹은 인터넷 리소스들을 사람이 읽을 수 있는 수준의 이름으로 표시한 것으로 해당 주소는 DNS를 통해 IP 주소로 변경됩니다. 컴퓨터는 이렇게 변경된 Ip 주소를 통해 유저가 요청한 웹사이트 혹은 인터넷 리소스에 접근합니다.

HTTP and HTTPS

두 프로토콜은 인터넷 기반의 서비스 개발에 가장 많이 사용되는 프로토콜입니다.

HTTP는 클라이언트와 서버 간 통신을 위한 통신규칙입니다.

예를 들어 chrome을 통해 웹사이트 방문 시에 chrome이라는 웹 브라우저가 해당 웹사이트를 담은 서버에 HTTP 요청을 보냅니다. 이후 서버는 해당 웹사이트를 담은 response를 반환해줍니다.

HTTPs는 HTTP의 보안단계가 강화된 버전으로 SSL/TLS 암호화 방식을 이용해 암호화한 데이터를 클라이언트와 서버간 통신하는 통신규약입니다. 이것은 기존의 계층에서 로그인 정보, 결제 정보 등과 같이 보안에 민감한 정보들을 보호하기 위한 보안 계층이 추가된 형태로 제공됩니다.

HTTPS를 사용해 웹사이트 방문 시 다음과 같이 주소 바에 자물쇠 아이콘이 보여집니다.

SSL/TLS 보안 연결

• 증명서

  • 클라이언트와 서버간의 신뢰를 보장하기 위해 사용되는 증명서로 제 3자를 통해 서명된 정보와 서버 식별자를 포함하여 클라이언트의 인증을 진행합니다.

• Handshake

  • SSL/TLS 핸드쉐이크 과정 동안 클라이언트와 서버는 보안연결을 위한 암호화 알고리즘 및 매개 변수들을 협상하기 위한 정보를 교환합니다.

• Encryption

  • 보안 연결이 성립된 후, 데이터는 협의된 알고리즘을 사용하여 암호화되며 클라이언트와 서버간 보안성을 갖추어 전송됩니다.

함수에 전달되는 값은 적절한 자료형으로 변환해야합니다. 그렇기 위해 Javascript 말고도 다른 언어들도 형변환이 중요합니다.

문자형 변환

예를 들어 alert와 같은 매개변수로 문자형을 받기 때문에 값들을 받을 때 문자형으로 변환이 필요합니다.

let value = null;
alert(typeof(value)); // object;

value = String(value)
alert(typeof(value)); // string;

위와 같이 String(value) 함수를 호출하여 전달받은 값을 문자열로 반환할 수 있습니다.

숫자형 변환

Javascript에서 숫자형 변환은 수학과 관련된 함수 및 표현식에서 자동으로 일어납니다.

// 1.
console.log(typeof("6"/"2")); // number

// 2.
let str = "123";
console.log(typeof(str)); // string
let num = Number(str);
console.log(typeof(num)); // number

위의 1번 예시를 보면 수학과 관련된 연산을 통해 문자열이 숫자열로 자동변환되어 연산이 수행되는 것을 알 수 있습니다.

위의 2번 예시는 함수를 이용해 숫자로 바꾸어주는 예시입니다.Number() 함수를 사용해 주어진 값을 숫자형으로 명시하여 변환할 수 있습니다.

하지만 Number() 함수를 통해 문자열을 숫자형으로 변환하려하는데 숫자 이외의 글자가 들어 있스면 다음의 3번 예시와 같이 결과가 NaN이 됩니다.

let value = Number('숫자형으로 변환 123');
console.log(value); // NaN
console.log(typeof(value)); // number

다음은 숫자형 변호나이 되는 예시입니다. (이후 추가 예정)

console.log(Number("  123  "));        // 123
console.log(Number("123z"));        // NaN ( 'z'는 숫자 변환이 실패함.)
console.log(Number(undefined));        // NaN
console.log(Number(true));            // 1
console.log(Number(false));            // 0
console.log(Number(null));            // 0

예외 : 숫자형 변환 시 undefinded는 0이 아니라 NaN 이 됩니ㅏㄷ.

불린형 변환

논린 연산을 수행할 때 발생합니다.

Boolean(value)를 호출하면 불리언으로의 형 변환을 수행할 수 있습니다.

• false : 0, null, undefined, NaN, ""
• true : 그외의 값들.

console.log(Boolean(1));            // true
console.log(Boolean(0));            // false
console.log(Boolean(undefined));    // false
console.log(Boolean(NaN));            // false
console.log(Boolean(null));            // false
console.log(Boolean(""));            // false
console.log(Boolean("123"));        // true
console.log(Boolean("0"));            // true
console.log(Boolean(" "));            // true

예외 : 마지막 예시를 보았을 때 Javascript에서는 문자열 "0" 또는 " "(공백이 존재하는 문자열)은 true 입니다

위와 같은 형변환의 규칙들과 예외들을 어느정도 기억하고 있어야 실무에서도 놓치는 부분 없이 시간을 단축해 프로그래밍을 할 수 있습니다.

예외들은 프로그래밍하면서 생기는 대로 추가할 예정입니다. ~

참고자료

• https://ko.javascript.info/type-conversions

9.1 트랜잭션

• 하나의 논리적 단위를 수행하는 데이터베이스 연산들의 모인
• 객체들을 접근하고 갱신하는 프로그램 수행 단위

특성

ACID

• 원자성 (Atomicity)
  • 1 또는 0. 모든 연산들이 완전히 수행되거나 전혀 수행되지 않음을 의미한다.
  • 시스템이 다운되는 경우 DBMS의 회복모듈이 트랜잭션의 영향을 취소함으로써 트랜잭션의 원자성을 보장한다.

• 일관성 (Consistency)

  • 수행되기전에 데이터베이스가 일관된 상태였다면 수정 후에도 일관된 상태를 유지한다.

  • 트랜잭션 수행 중에는 일시적으로 일관되지 않을 수도 있다.

• 고립성 (Isolation)

  • 트랜잭션 완료전까지는 갱신 중인 데이터를 다른 트랜잭션들이 접근하지 못하도록 한다.
  • 다수의 트랜잭션이 동시 수행되더라도 결과는 트랜잭션들이 차례대로 수행한 결과와 같아야함.
  • DBMS의 동시성 제어 모듈이 고립성 보장
  • 다양한 고립 수준 제공

• 지속성 (Durability)

  • 한 트랜잭션 완료(commit) 시 그 이후에는 손실되지 않는다.
  • DBMS의 회복 모듈이 지속성 보장

트랜잭션 완료

• 변경 내용 데이터베이스에 완전하게 반영
• COMMIT WORK

트랜잭션 철회

• 일부만 반영된 경우네는 원자성 보호를 위해서 수행전의 상태로 되돌린다.

• ROLLBACK WORK

  

트랜잭션 실패 요인

• 시스템 고장
• 트랜잭션 고장
• 매체 고장
• 통신 고장
• 자연재해
• 부주의 OR 고의 고장

9.2 동시성 제어

• 다수 사용자들 동시에 동일 테이블 접근
• DBMS 성능 높이기 위해 필수적
• 트랜잭션들 간의 간섭 발생 방지해야한다.

스케줄

트랜잭션의 수행순서

• 직렬 스케줄

  • 한 트랜잭션씩 차례대로 수행

    T1 : 011, 012 T2 : 021, 022, 023 S1 : T1, T2 (011, 012, 021, 022, 023) S2 : T2, T1 (021, 022, 023, 011, 012) 트랜잭션 내의 순서 변경 X

• 비직렬 스케줄

  • 여러 트랜잭션 동시 수행

  S3 : 011, 021, 022, 012, 023

  • 트랜잭션 내부 연산의 순서는 유지되어야 한다.

  • 직렬가능

    • 비직렬 스케줄의 결과가 직렬 스케줄의 수행 결과와 동등
      • S3의 수행 결과가 S1의 결과와 동일시 직렬가능으로 올바른 비직렬 스케줄이다.

데이터 베이스 연산

• Input(X)
• Output(X)
• read_item(X)
• write_item(X)

동시성 제어하지 않을 때 발생 가능한 문제

• 갱신손실 : 갱신한 내용을 다른 트랜잭션이 덮어 써 갱신이 무효가 되는 경우

• 오손 데이터 읽기 : 완료되지 않은 트랜잭션이 갱신된 데이터를 읽는 것

• 반복할 수 없는 읽기 : 동일한 데이터 두번 읽을 때 서로 다른 값을 읽는 경우

로킹

데이터 항목과 연관된 하나의 변수

• 동시성 제어위해 가장 널리 사용되는 기법

• 요청한 로크에 관한 정보는 로크 테이블 등에 유지된다.

• 접근할 때 로크 요청, 접근을 끝낸 후에 로크 해제

  • 갱신 목적 접근 : 독점 로크
  • 읽기 목적 접근 : 공유 로크

  

로크를 일찍 해제하는 경우

• A=B로 시작
• A 값
  • 첫번째 unlock(A)에서 A+1이 된다.
  • 두번째 unlock(A)에서 2A+2
• B 값
  • 첫번째 unlock(B)에서 2B
  • 두번째 unlock(B)에서 2B + 1
• A, B 는 같은 수행을 했음에도 불구하고 값ㄹ이 다르게 된다.

2단계 로킹 프로토콜

• 로크를 요청하는 단계 + 로크를 해제하는 단계로 총 2단계로 이루어짐

• 로크 확장 단계 후 로크 수축 단계

• 로크를 한 개라도 해제하면 로크 수축 단계가 된다.

  로크 확장 단계(1단계)

  • 트랜잭션이 데이터 항목에 대해 새로운 로크 요청가능
  • 보유하고 있던 로크 해제 불가

    로크 수축 단계(2단계)

  • 보유하고 있던 로크 해제가능
  • 새로운 로크 요청 불가
  • 트랜잭션 완료 시점에 이르렀을 때 한꺼번에 모든 로크 해제 가능

    로크 포인트

    필요로 하는 모든 로크를 걸어놓은 시점

  

데드록

• 2단계 로킹 프로토콜에서 발생 가능
• 두 개 이상의 트랜잭션들이 상대방이 보유하고 있는 로크를 요청하며 기다리는 상태 (무한정 대기)
• 희생자 선정하여 데드록 풀기도 한다.

순서

1. T1이 X에 대해 독점 로크 요청
2. T2가 Y에 대해 독점 로크 요청
3. T1이 Y에 대해 독점 OR 공유 로크 요청 시 로크 해제까지 대기
4. T2가 X에 대해 독점 OR 공유 로크 요청 시 로크 해제까지 대기

다중 로크 단위

투플 수에 따라 로크를 하는 데이터 항목의 단위 구분이 필요하다

로크할 수 있는 데이터 항목이 두가지 이상 있으면 다중 로크 단위라고 부른다.

• 데이터베이스, 릴레이션, 디스크 블록, 투플

• 로크 단위가 작을수록 로킹에 따른 오버헤드가 증가 + 동시성의 정도 증가

• Intention Lock : 상위 level에 lock

  • 하위단위에 대해서도 모두 lock => 오버헤드가 증가한다

  

보충필요

팬텀 문제

• 1시간에서 1번부서에 성이 김, 박 이있다고 가정

• 2시간에서 정씨가 추가 된다.
• 3시간에서 김, 박 , 정(phantom 등장) 한 채로 완료된다.

원래 트랜잭션 T1에서 시행하려던 결과는 김, 박 이 두번 나와야했지만 두번째 SELECT문에서 김, 박, 정이 나오게 되어 결과가 다르게 나타난다. ➡ 팬텀 문제

9.3 회복

• 시스템이 다운되었을 때, 트랜잭션의 수행이 일부만 반영 ➡ 어떻게 T의 수행을 취소하여 원자성 보장
• 모든 갱신 효과가 주기억 장치로부터 디스크에 기록되지 않았을 수 있다. ➡ 어떻게 완전하게 반영되도록 하여 지속성을 보장할것인가?

트랜잭션 수행동안 위와 같은 문제들에 맞닥뜨리게 된다. 그렇기에 회복 기능이 필요하다

회복

• 버퍼의 내용을 디스크에 기록하는 것을 가능한 줄여야한다.
• 버퍼에 갱신사항 반영했지만 디스크 기록전에 고장 가능
• 고장 발생 전에 트랜잭션이 COMMIT시 회복 모듈은 이 트랜잭션의 갱신 사항을 재수행(REDO) 하여 갱신이 지속성을 지녀야한다.
• 고장 발생 전 COMMIT 실패 시 원자성 보장위해 데이터에 반영했을 가능성이 있는 모든 갱신 사항을 취소(UNDO) 해야한다.

저장 장치의 유형

• 주기억장치
  • 휘발성 저장 장치
  • 시스템이 다운된 후에 모두 사라진다.
• 디스크
  • 비휘발성 저장 장치
  • 다운되어도 유지 (디스크 헤드 고장 X 일 때만)
• 안전 저장 장치
  • 모든 유형의 고장을 견딜 수 있는 저장 장치
  • 두 개 이상의 비휘발성 저장 장치가 동시 고장 가능성이 낮다.
  • 비휘발성 저장 장치에 두 개 이상의 사본 중복 저장하여 안전저장장치 구현
    • 1개 고장확률 1%라고 가정
    • 0.01 X 0.01 = 0.00001 로 고장 가능성 0.01%

재해적 고장과 비재해적 고장

• 재해적 고장
  • 디스크가 손상을 입어 데이터베이스를 읽을 수 없는 경우
  • 데이터베이스를 백업해 놓은 자기테이프를 기반으로 회복한다.
• 비재해적 고장
  • 대부분의 회복 알고리즘들 적용
    • 로그를 기반으로 한 즉시 갱신 (대부분 이용)
    • 로그를 기반으로 한 지연 갱신
    • 그림자 페이징

로그를 사용한 즉시 갱신

즉시 갱신

갱신 사항이 주기억 장치의 버퍼에 유지되다가 트랜잭션이 완료되기 전에도 디스크의 데이터베이스에 기록이 가능하다.

• 데이터베이스에는 철회된 수행결과도 반영된다.

• 원자성과 지속성 보장을 위해 로그라고 불리는 파일 유지

• 모든 트랜잭션의 연산들에 대해 로그 레코드를 기록한다.

  • 각 로그 레코드는 로그 순서 번호(LSN) 로 식별

  

• 로그 생성 시에 로그 버퍼에 로그 레코드를 기록

  • 로그 버퍼가 꽉찰 때 디스크에 기록

• 로그는 필수적이기에 안전 저장 장치에 저장된다.

• 이중 로그 : 로그를 두 개의 디스크에 중복해서 저장

• 로그 레코드가 어떤 트랜잭션 소속인지 식별하기 위해 각 로그 레코드마다 트랜잭션 ID를 포함한다.

• 동일 트랜잭션에 존재하는 로그레코드들은 이전 레코드에 대한 LSN을 포함하여 연결리스트로 유지한다.

로그 레코드 유형

• [Trans-ID, start]
  • 한 트랜잭션이 생성될 때 기록되는 로그 레코드
• [Trans-ID, X, old_value, new_value]
  • 수정했음을 나타내는 로그레코드
• [Trans-ID, commit]
  • 성공적으로 완료하였음을 나타내는 로그 레코드
• [Trans-ID, abort]
  • 철회되었음을 알리는 로그 레코드

트랜잭션의 완료점

• 데이터 베이스 갱신사항이 로그에 기록되었을 때
• [Trans-ID, commit] 로그 레코드 존재 트랜잭션 REDO
• [Trans-ID, commit] 없으면 UNDO

로그 먼저 쓰기(WAL)

• 주기억 장치의 데이터베이스 버퍼에 갱신 사항 기록, 로그버퍼에는 이에 대응되는 로그 레코드 기록
• 로그버퍼보다 데이터베이스 버퍼가 먼저 디스크에 기록 되면 시스템 다운 되었을 때 로그 레코드가 존재하지 않아 이전값을 알 수 없다.
  • 트랜잭션의 취소 불가능
• 데이터베이스 버퍼보다 로그 버퍼를 먼저 디스크에 기록해야한다.

체크 포인트

DBMS가 회복시 재수행할 트랜잭션의 수를 줄이기 위해서 주기적으로 체크포인트를 수행한다.

• 오래 전에 완료된 트랜잭션은 이미 디스크에 반영되었을 가능성 농후
• 갱신 사항이 주기억 장치 버퍼로부터 디스크에 기록되었는지 확인 불가
• 체크포인트 시점에는 주기억 장치의 버퍼 내용이 디스크에 강제로 기록
• 체크포인트를 수행하면 디스크 상에서 로그와 데이터베이스의 내용 일치
• 체크포인트 작업이 끝나면 로그에 [checkpoint] 로그 레코드가 기록

작업

• 수행 중인 트랜잭션 일시적으로 중지시킨다
  • 퍼지 체크포인트 알고리즘에서는 이럴 필요 x
• 주기억 장치의 로그 버퍼를 다스크에 강제 출력
• 데이터 베이스 버퍼도 강제 출력
• [checkpoint] 로그 레코드를 로그 버퍼에 기록한 후 디스크에 강제 출력
• 수행중이던 트랜잭션들의 ID도 [checkpint] 로그 레코드에 함께 기록

• T0, T1, T3, T4, T5, T6 는 COMMIT된 것으로 재수행
• T2, T6 취소

• T0, T1, T3
  • 체크 포인트 이전 완료이기에 디스크레 반영 보장
  • Unflushed : 디스크기록 x, 버퍼 o인 상태에서 checkpoint로 인해 모든 연산이 디스크에 반영
• T4, T5
  • COMMIT된 상태로 재수행(REDO) 되어야한다.
  • 체크포인트 이전의 것 엑세스하면서 이후의 것 REDO
• T2, T6
  • 시스템 다운 이전에도 COMMIT이 되지 않았기에 취소(UNDO)되어야 한다.
  • T2의 경우 체크포인트 이전의 레코드 엑세스하고나서 UNDO

Fuzzy checkpoint

• Tc 부분이 범위가 길다.
  • 체크포인트가 명확히 어딘지 알기 힘들다
• 중요한 산업에서는 시스템을중단해서는 안되기에 중단 대신 하나씩 디스크의 버퍼를 로코를 걸어 swapping 해준다.
• Available 시간이 증가하고
• 성능 또한 증가

데이터베이스 백업과 재해적 고장으로부터의 회복

디스크 헤드 고장으로 인해 데이터베이스 읽지 못하는 경우

• 주기적으로 자기 테이프에 전체 데이터베이스와 로그를 백업 후 자기테이프를 안전하게 보관
• 데이터베이스 사용 허용하면서 지난 번 백업 이후의 갱신 내용만 백업하는 점진적인 백업

9.4 PL/SQL의 트랜잭션

트랜잭션의 시작과 끝

• 암시적으로 끝나거나 명시적(Commit)으로 끝날 수 있다.
• COMMIT
  • 결과 데이터베이스에 반영 후 트랜잭션 완료
• ROLLBACK
  • 데이터베이스에서 결과를 모두 되돌리고 트랜잭션 철회
• SAVEPOINT
  • 저장점을 표시하여 트랜잭션을 더 작게 나눈다,
  • ROLLBACK TO SAVEPOINT를 이용해 지정된 저장점 이후에 갱신된 내용만 되돌린다.
    • SAVEPOINT가 없으면 처음으로

• _SET 명령_을 사용하여 여러 데이터 조작어 한 트랙잭션으로 처리 가능

속성

• 읽기 전용 명시하여 DBMS 동시성 정도 높일 수 있다.

  • 읽기 전용이면 갱신 작업 트랜잭션 수행 불가능
    • UPDATE, INSERT, DELETE

      SET TRANSACTION READ ONLY

• 쓰기 작업

  • 모든 작업 수행 가능
    • INSERT, UPDATE, DELETE, SELECT

SET TRANSACTION READ WRITE

고립 수준

한 트랜잭션이 다른 트랜잭션과 고림되어야 하는 정도

• 고립수준 낮으면 동시성은 높아지지만 정확성(일관성)은 저하
• 고립수준 높으면 데이터는 정확, 동시성은 저하
• 고립 수준 선택하여 성능 향상 가능
• 명시한 고립 수준에 따라 DBMS가 사용하는 로킹 동작이 달라진다.

READ UNCOMMITTED

• 가장 낮은 고립 수준
• 공유 로크 없이 데이터를 읽는다
  • 다른 트랜잭션 기다릴 필요가 없기에 동시성이 높아진다.
• 오손 데이터 읽기 가능
• 갱신 데이터에 대해서는 독점 로크 걸고, 트랜잭션이 끝날 때 까지 보유한다.
  • 갱신손실 허용 X

READ COMMITTED

• 읽으려는 데이터에 대해서 공유 로크 읽기가 끝나자마자 로크 해제
  • 오손데이터 읽기 방지
  • 2단계 로킹이 아니다.
  • 일관성 저하 동시성 상승
• 다시 읽기 위해 공유 로크를 다시 걸면 이전 값과 다른 값을 읽을 수도 있다.
  • 반복할 수 없는 읽기
• 갱신 데이터에 독점 로크를 걸고 트랜잭션이 끝날 때 까지 보유
  • 갱신손실 허용 X
• PL/SQL의 디폴트

REPEATALE READ

• 읽으려하는 데이터에 대해 공유 로크, 트랜잭션이 끝날 때 까지 보유
• 한 트랜잭션 내에서 동일 질의 두 번 수행해도 이전 값 그대로 유지
  • 반복할 수 없는 읽기 발생하지 않음
• 갱신 데이터에 독점 로크를 걸고 트랜잭션이 끝날 때 까지 보유
  • 갱신손실 허용 X

SERIALIZABLE

• 가장 높은 고립 수준
• 투플뿐만 아니라 _인덱스_에 대해서도 공유 로크를 걸고 트랜잭션이 끝날 때 까지 보유
• 동일 질의 두 번 수행해도 매번 같은 값
  • 반복할 수 없는 읽기 발생하지 않음
• 갱신 데이터에 독점 로크를 걸고 트랜잭션이 끝날 때 까지 보유
  • 갱신손실 허용 X
• 가장 TRANSACTION의 특징을 만족하여 SQL2의 디폴트 고립 수준
• 동시성은 저하

REPEATABLE READ VS SERIALIZABLE

SELEECT col1 FROM A WHERE col1 BETWEEN 1 AND 10

범위에 해당하는 데이터 2건(col1 = 1 and 5) 7 데이터 값 삽입 시

• REPEATABLE READ
  • 다른 사용자가 col1이 1이나 5인 ROW에 대해 UPDATE 불가
  • 데이터 2건 이외의 범위에 해당하는 나머지 ROW에는 INSERT 가능
    • 7 삽입하려하면 가능 => 결과는 1, 5, 7
    • 팬텀문제 발생
• SERIALIZABLE
  • 범위 전체에 해당하는 데이터 수정 및 입력 불가
    • 팬텀문제 방지

부주의한 데이터베이스 설계 ➡ 제어할 수 없는 데이터 중복 야기 + 갱신 이상 유발

7.1 정규화

릴레이션 스키마를 함수적 종속성과 기본 키를 기반으로 분석해 원래의 릴레이션을 분해해 중복과 세 가지 갱신 이상을 최소화한다.

좋은 DB 스키마 설계 목적

• 정보의 중복과 갱신 이상 방지
• 정보의 손실 방지
• 실세계 표현
• 애트리뷰트들 간의 관계 잘 표현
• 무결성 제약조건 시행 간단하게
• 갱신 이상 발생하지 않도록 노력이 우선, 그 후 효율성 고려

갱신 이상

• 수정 이상

  • 반복된 데이터 중 일부만 수정시 데이터의 불일치 발생

• 삽입 이상

  • 불필요한 정보를 함께 저장하지 않고 원하는 정보 저장 불가능

• 삭제 이상

  • 유용한 정보 함께 삭제하지 않고는 어떤 정보 삭제 불가능

  결국 일부만 하는 것으로는 갱신 이상 피할 수 없다.

나쁜 설계 예시들

• NULL값 존재

• 부서 수 제한이 필요 없다.

• 첫번째 레코드 삭제 시 1번 영업부의 정보가 삭제 된다

  • 삭제 이상

• 부서 이름 변경시 일부 사원의 투플만 부서이름 변경하는 경우 데이터 불일치가 발생한다.

  • 수정 이상 : 데이터 불일치 발생

• 4번 홍보부 추가 시 나머지 애트리뷰트가 전부 NULL을 가지게 된다.(사원이 없기 때문)

  • 사원번호가 NULL이기에 무결성 제약조건으로 인해 삽입불가
  • 삽입 이상

• 정보의 중복 발생

  • 사원번호, 사원이름, 주소, 전화번호 등의 애트리뷰트들이 중복되어 저장공간이 낭비된다.

갱신이상

아래의 세 이상들을 총칭하여 갱신이상이라고 부른다.

• 수정 이상
• 삽입 이상
• 삭제 이상

릴레이션 분해

📄 하나의 릴레이션 두 개 이상의 릴레이션으로 나누어 갱신이상 해결!!

• 분해하여도 원래의 릴레이션을 다시 구할 수 있음을 보장해야 한다.
• 분해 실패시 얻을 수 있는 정보가 원래 릴레이션 정보보다 적거나 많음
• 함수적 종석성에 관한 지식을 기반으로 분해한다.

나쁜 예시를 이렇게 2개(사원1, 부서)의 릴레이션으로 분해하여 발생하는 갱신이상을 해결할 수 있다.

• 수정 이상
  • 사원1 릴레이션에 부서 이름이 포함되지 않기에 수정 이상이 발생하지 않는다.
• 삽입 이상
  • 사원 배정이 없어도 부서 릴레이션에만 추가하여 해결!
• 삭제 이상
  • 유일한 사원의 투플을 삭제하여도 부서 릴레이션에 부서정보 남아있기에 해결!

정규형의 종류

• 제 1정규형
• 제 2정규형
• 제 3정규형
• BCNF
• 제 4정규형
• 제 5정규형

관계 데이터베이스 설계의 비공식적인 지침

• 이해하기 쉽고 명확한 스키마 생성
  • 여러 곳에 속한 애트리뷰트들을 하나의 릴레이션에 포함시키지 않는다.
• NULL값 피하기
• 가짜 투플 생성 방지
• 스키마 정제

7.2 함수적 종속성

• 릴레이션의 애트리뷰트들의 의미로부터 결정된다.
• 스키마에 대한 주장 (NOT 인스턴스)
• 가능한 모든 인스턴스들이 만족
• 제 2정규형부터 BCNF 적용

결정자

• 어떤 애트리뷰트의 값은 다른 애트리뷰트의 값 고유하게 결정 가능
  • 사원번호는 사원이름을 고유하게 결정
  • 주소는 사원이름 결정 X

다른 애트리뷰트를 고유하게 결정하는 하나 이상의 애트리뷰트 A->B A가 B를 결정한다.

• 사원번호 -> 사원이름
• 사원번호 -> 주소
• 사원번호 -> 전화번호
• 부서번호 -> 부서이름

함수적 종속성

• A->B이면 B가 A에 함수적으로 종속한다,
• 각 A 값에 대해 반드시 한 개의 B값이 대응된다.

🔎 사원번호 -> 사원이름, 주소, 전화번호이므로 사원이름, 주소, 전화번호는 사원번호에 함수적으로 종속

🔎 (사원번호, 부서번호) -> 직책이지 사원번호에 함수적으로 종속하지 않음.

💡 직책은 사원번호 + 부서번호 집합에 고유하게 결정되지 사원번호에 의해 결정되지 않는다.

완전 함수적 종속성 (FFD)

릴레이션 R에서 애트리뷰트 B가 애트리뷰트 A[복합 애트리뷰트]에 함수적으로 종속(A->B)이면서 A의 어떠한 진부분 집합에도 함수적 종속이 안될 시.

A 그대로에 함수적 종속 (부분에 종속 x)

• (사원번호, 부서번호) -> 직책
  • 사원번호 -> 직책 : 불가 => 완전 함수적 종속성
• 부분 함수적 종석성
  • (사원번호, 부서번호) -> 부서이름 가능!
  • 부서 번호 -> 부서 이름 : 부분 함수적 종속성 ⭕
  • 사원 번호 -> 부서 이름 : 부분 함수적 종속성 ❌

이행적 함수적 종속성 (transitive FD)

A, B, C 애트리뷰트가 있을 때 애트리뷰트 C가 이행적으로 A에 종속한다는 것

A→B ∧ B→C (동시성립)

A→B ∧ A→C

• A가 릴레이션의 기본 키 라면 키의 정의에 따라 성립
  • _C가 B에도 함수적으로 종속(B→C)_한다면 C는 A에 직접 함수적으로 종속하면서 B를 거쳐서 A에 이행적으로 종속한다.
  • A→B ∧ B→C 성립함을 의미

• 학번 → 학과이름 ∧ 학과이름 -> 전화번호
  • 학번 → 전화번호 : 이행적으로 종속.

7.3 릴레이션 분해

하나의 릴레이션을 두 개 이상으로 나누는 것

• 함수적 중복성 이용
• 분해 시 중복이 감소되고 갱신 이상이 줄어든다.
• 잠재적인 문제 발생 가능
  • 조인이 필요 없는 질의가 분해 후에는 조인을 필요로 하기도 한다.
  • 원래 릴레이션으로 재구성하지 못할 수도 있다.

무손실 분해

분해된 릴레이션 조인 시 완전하게 얻을 수 있다.

• 손실 : 정보의 손실
  • 조인 시 원래 정보보다 적거나 많은 것을 정보의 손실이라고 한다.

• 학번 → 이름, 이메일
• 이메일 → 학번, 이름
• (학번, 과목번호) → 학점

여기서 학생1 릴레이션 분해

• 학번이 중복된다.

  • 손실 분해

  

• 학번이 중복된다.

  • 손실 분해

• 과목번호, 학점간의 연관성이 표현되지 않는다.

  • 나쁜 분해

  

위의 예시는 원래 릴레이션에 존재하지 않는 투플들이므로 가짜 투플 (손실 분해) 이다.

7.4 정규형

제 1 정규형

• 릴레이션 R의 모든 애트리뷰트가 원자값만을 갖는다.
  • 관계 데이터베이스의 요구사항
• 반복 그룹이 나타나지 않으면 제 1 정규형이 만족한다.

위의 그림은 반복 그룹이 애트리뷰트에 존재하므로 제 1 정규형을 만족하지 않는다.

위의 그림은 반복 그룹을 제거시켰지만 데이터가 중복되어 있기에 이를 없애기 위해 분해시켜줘야 한다.

갱신 이상

제 1정규형에도 갱신이상이 존재한다.

아래의 그림은 제1정규형을 만족하는 릴레이션이다.

• 삽입 이상
  • 인공지능학과가 생겼을 때 이를 삽입할 수 없다.
    • 기본키인 학번이 NULL이기에 학생 릴레이션에 추가할 수 없다.
• 수정 이상
  • 같은 학번 전호번호 변경 어려움
    • CS310 듣는 11002 투플의 전화번호를 수정하면 CS313을 듣는 투플의 전화번호에서 데이터 불일치가 발생한다.
• 삭제 이상
  • 마지막 24036학번 투플 삭제하면 24036 학생이 없어지는 것으로 삭제가 어렵다.

갱신 이상 발생 이유

부분 함수적 종속성이 학생 릴레이션에 존재하기때문이다.

• A 에서 FD1이 존재하기에 어렵다.

제 2 정규형

• 제 1정규형을 만족하면서, 어떤 후보 키에도 속하지 않는 모든 애트리뷰트들이 릴레이션의 기본 키에 완전하게 함수적으로 종속해야한다.

• 기본 키가 두 개 이상의 애트리뷰트로 구성되었을 때 고려

  

갱신 이상

• 삽입 이상

  • 학과 신설할 시 소속 학생이 없기에 학과 정보를 기입할 수 없다.
    • 엔티티 무결성 제약조건

• 수정 이상

  • 소속 학과의 전화번호 변경시 모든 학과 투플 전화번호 수정하지 않으면 데이터 불일치 발생

• 삭제 이상

  • 학과에 남은 단 하나의 학생 투플 삭제 시 학과의 전화번호 삭제

발생 이유

• 릴레이션에 이행적 종속성이 존재

• 학과 이름이 KEY 애트리뷰트가 아님에도 다른 애트리뷰트를 결정한다.

• 학번 - 전화번호 : 직접 연관이 없음에도 이행적 종속성이 있기에 문제 발생

제 3 정규형

• 제 2정규형 만족하면서 키가 아닌 모든 애트리뷰트가 릴레이션의 기본키에 이행적으로 종속하지 않는 것

갱신 이상

• 수정 이상

  • 강사 변경 시 모든 투플에서 수정하지 않으면 데이터 불일치 발생

• 삽입 이상

  • 과목 신설 시 학생이 없으면 투플 추가 불가
    • 학번이 기본키를 구성하는 것인데 엔티티 무결성 제약조건에 의해 NULL값을 추가할 수 없기 때문이다.

• 삭제 이상

  • 이수하는 인원 한 명뿐인데 이 투플 삭제 시 과목을 가르치는 강사에 대한 정보도 사라진다.

발생 이유

키가 아닌 애트리뷰트가 다른 애트리뷰트를 결정하기 때문이다.

• FD1

• 7.21의 후보 키 (학번, 과목) , (학번, 강사)

  • (학번, 강사) 과목 결정해서 애트리뷰트 구성

BCNF

• 제 3정규형을 만족하고, 모든 결정자가 후보 키가 되어야한다.
• 그림 7.21은 강사 애트리뷰트가 후보 키가 아님에도 과목 애트리뷰트를 결정하기에 BCNF가 되지 않는다.
• 하나의 후보키를 가진 릴레이션이 제 3정규형 만족 시 BCNF 만족

만드는 방법

• 키가 아니면서 결정자 역할을 하는 애트리뷰트와 그 결정자에 함수적으로 종속하는 애트리뷰트를 하나의 테이블에 넣는다.
  • 이 릴레이션에서 결정자는 기본 키
• 기존 릴레이션에 결정자를 남겨서 기본 키의 구성요소가 되게 한다.
  • 이 결정자는 새로운 릴레이션에 대한 외래키

• C가 후보 키가 아님에도 B 애트리뷰트를 결정한다.

  • C -> B : C 결정자 역할 + B는 C에 함수적으로 종속

• C는 외래키의 역할을 하며 기본 키의 구성요소가 된다.

요약

• 주요 애트리뷰트 : 키에 속하는 애트리뷰트
• 비주요 애트리뷰트 : 키에 속하지 않는 애트리뷰트

7.5 역정규화

정규화

장점

• 중복 감소, 갱신 이상 감소
• 무결성 제약조건을 시행하기 위한 필요코드 감소

  단점

  • _성능상의 관점_에서는 높은 정규형을 만족하는 릴레이션 스키마가 무조건 최적은 아니다.
  • 분해 시 두개의 릴레이션
  • 많은 릴레이션 접근하므로 조인의 필요성이 증가한다.

정규화 ⬇

SELECT 학과이름, 학과전화번호
FROM 학생1
WHERE 학번 = '11002';

에서 정규화 시

SELECT 학과이름, 학과전화번호
FROM 학생2, 학과
학번 = '11002' AND 학생2.학과이름 = 학과.학과이름;

역정규화

보다 낮은 정규형으로 되돌아 가는 것

• 일부분을 역정규화함으로써 데이터 중복 및 갱신 이상을 대가로 치르면서 성능상의 요구를 만족시키기도 한다.

• 검색 질의의 비율보다 갱신 질의의 비율이 높기에 분해된 릴레이션 합치기도 한다.

논리적인 설계의 데이터 구조를 물리적인 데이터 모델로 사상한다.

• 예상 빈도를 포함하여 데이터베이스 질의와 트랜잭션들을 분석한다.
• 분석을 통한 효율적인 접근을 제공하기 위해 저장 구조와 접근 방법들을 다룬다.
• 특정 DBMS의 특성을 고려한다.
• 질의의 효율적 지원을 위해 인덱스 구조를 적절히 사용한다.

6.1 보조 기억 장치

데이터 검색을 위해 DBMS는 데이터베이스로부터 원하는 데이터를 포함하고 있는 블록을 읽어서 주기억 장치로 가져온다.

자기디스크

자기물질로 만들어진 여러 개의 판으로 이루어져 있다

• 면마다 디스크 헤드 존재
• 각 판은 트랙과 섹터로 구분된다.
• 정보는 트랙(동심원)을 따라 저장된다.
• 같은 지름을 갖는 트랙들을 실린더라고 부른다.
• 시간 = 탐구 시간(arm assembly가 이동하는 시간) + 회전 지연 시간(원판이 회전해 오는 시간) + 전송 시간(읽고 전송)

• 섹터 : 조각

• 트랙 : 원
  • 트랙은 여러 섹터로 구성
• 실린더 : 지름이 같은 서로 다른 트랙들
  • 그림에서 볼 때 1개의 실린더에는 6개의 트랙이 존재한다. (3 * 2[양면])
• 읽고 쓰는 헤드(arm assembly
• spindle(축)이 회전하여 원판이 움직이는 구조

💡 탐색시간을 줄이는 방법 함께 엑세스 되는 데이터들은 동일 실린더에 저장하여 arm이 움직이지 않고 볼 수 있다.

6.2 버퍼 관리와 운영 체제

• 디스크 입출력은 가장 속도가 느린 작업이기에 입출력 횟수를 줄여야 DBMS의 성능을 향상시킬 수 있다.
• 가능한 많은 블록들 주기억 장치에서 유지 또는 자주 참조되는 블록들을 주기억 장치에 유지하면 블록 전송 횟수를 줄일 수 있다.
• 버퍼 : 디스크 볼록들을 저장하는데 사용되는 주기억 장치 공간
• LRU 알고리즘 존재 but 데이터 베이스에서 우수 X

6.3 디스크 상에서 화일의 레코드 배치

• 애트리뷰트들은 고정 길이 또는 가변 길이의 필드로 표현
• 연관 필드가 모여서 고정 길이 또는 가변 길이의 레코드가 된다.
• 레코드들의 모임이 화일이라는 블록들의 모임에 저장된다.

애트리뷰트 -> 필드 -> 레코드 -> 화일

위의 그림에서 가변 길이의 모임도 가능하다.

디스크 상에서 화일의 레코드 배치

• 블록들이 반드시 인접할 필요 x
• 탐구 시간, 회전 지연 시간을 줄이기 위해 인접하도록 주기적으로 재조직한다.

FAT (File Allocation Table)

하나의 블록에 대해 디스크 상 몇번째 블록이 저장되는지 나타내는 표

BLOB(Binary Large Object)

이미지, 동영상 등 대규모 크기의 데이터 저장에 사용된다.

채우기 인수

• 각 블록에 레코드를 채우는 공간의 비율
• 기존의 레코드 이동 가능성 줄이기 위해서 어느정도 비워둔다.

• 오른쪽의 100% 채움의 경우 다른 페이지(블록)에 할당해야한다.

  100% 채움에서 새로운 레코드가 들어올 때 순서가 바뀌어 기존의 레코드가 다른 블록으로 할당되는 경우가 발생한다. 이를 방지하기 위해 왼쪽과 같이 어느 정도의 빈 공간을 둔다.

고정 길이 레코드

간단한 산술계산으로 레코드의 위치를 찾아 읽을 수 있다.

• 순서 유지의 장점 존재
• 여러 개의 레코드를 이동하는 단점 존재.

• 순서가 중요하지 않을 때
• 레코드 위치 이동에 대한 주기적인 처리 필요하다.

이러한 경우를 대비해 지연 관리 방법이 존재한다.

지연 관리 방법

• 이동이 필요 없다.
• 삭제된 공감을 관리하기 위해 free list를 관리한다.

화일 내의 클러스터링

• 한 화일 내에서 함께 검색될 가능성이 높은 것들은 가까운 곳에 모아둔다.

화일 간의 클러스터링

• 두 개 이상의 화일 또한 논리적으로 함께 검색될 가능성이 높다면 가까이 저장한다.

6.4 화일 조직

• 히프 화일
• 순차 화일
• 인덱스된 순차 화일
• 직접 화일

히프 화일(비순서 화일)

• 가장 단순

• 삽입된 순서대로 화일에 저장된다.

  • 특정 애트리뷰트 값에 따른 순서가 아니다.

• 삽입/검색/삭제

  • 삽입 : 화일의 가장 끝에 첨부
  • 검색 : 순차적을 접근
  • 삭제 : 검색 후 삭제된 레코드가 차지하던 공간 재사용하지 않는다.

• 좋은 성능을 위해서는 주기적으로 재조직해야한다.

성능

• 모든 레코드를 참조하고 레코드 순서가 중요하지 않을 때 사용한다.
• 특정 레코드들을 검색하는 경우에는 비효율적이다.
• 점 질의(특정), 범위 질의(범위) 모두 비효율적이다.

순차 화일

• 순서대로 저장
• 레코드의 탐색 키 값의 순서에 따라 저장된다.
• 탐색 키 : 순차 화일을 정렬하는데 사용되는 필드
• 삽입/삭제/검색
  • 삽입 연산은 삽입하려는 레코드의 순서를 고려로 시간이 걸린다.
    • 넣을 공간 찾는 시간 + 다른 레코드로 이동하는 시간
  • 삭제 연산은 삭제된 공간 빈 공간으로 남기기에 주기적으로 순차화일 재조직이 필요하다.
  • 검색 연산은 탐색 키의 유무에 따라 시간소요가 다르다.
    • 탐색 키 기반 탐색 : 효율적(이진탐색)
    • 탐색 키가 아닌 필드 사용 : 시간 많이 소요

성능

SELECT TITLE
FROM EMPLOYEE
WHERE EMPNO = 1365;

• 위의 SELECT 문은 이진 탐색을 이용 (빠르게 접근)

SELECT EMPNAME, TITLE
FROM EMPLOYEE
WHERE SALARY >= 3000000 AND SALARY <= 4000000;

• 두번 째 SELECT문은 WHERE절 조건이 저장 순서와 무관하기에 화일 전체를 탐색해야한다.

연산 시간 효율 높이기

삽입: 100% 미만의 채우기 인수로 소요시간을 줄일 수 있다. 삭제: FREE LIST를 이용해서 삭제된 공간 관리, 삭제표시 + 재조직으로 시간을 줄일 수 있다. 검색: 탐색 키 이용

6.5 단일 단계 인덱스

이진 탐색의 문제점

• 정렬비용이 높게 들기에 사용을 많이 하지 않는다.

• 주로 기본 인덱스에서만 사용

• 인덱스를 통해서 임의의 레코드를 접근할 수 있는 화일

• 엔트리 모양

  • <탐색 키, 레코드에 대한 포인터>

• 탐색 키 값의 오름차순으로 정렬

인덱스

탐색 키를 가진 레코드의 빠른검색을 위해 엔트리모양으로 관리하는 구조

• 데이터 화일과 별도의 화일에 저장
• 인덱스의 크기는 데이터 화일 크기에 비해 작다.
  • 주로 탐색 키 + 포인터로 구성
• 하나의 화일에 여러 인덱스들을 정의할 수 있다.

탐색 키

• 인덱스가 정의된 필드
• 후보 키처럼 반드시 고유하지 않다.
• 모든 애트리뷰트(키 구성 + 키 구성 x) 탐색 키로 사용 가능
• 인덱스 엔트리들은 탐색 키 값의 오름차순 정의이기에 이진탐색 가능하다.

기본 인덱스

탐색 키가 데이터 화일의 기본 키인 인덱스

• 희소 인덱스로 불리기도 한다.
• 각 릴레이션 마다 최대 한 개의 기본 인덱스 생성 가능
• 기본 키 값에 의해 _정렬된 데이터 화일_에 대해 정의

• 레코드 포인터가 아닌 블록 포인터로 존재한다.

• 레코드 포인터 : 데이터 화일의 모든 레코드 가르킨다.

• 블록 포인터(50) + 레코드 오프셋(2)
  • 블록 포인터 : 각 데이터 블록의 첫번째 레코드를 가르킨다.
• 데이터 블록 안에서 레코드 오프셋을 통해 접근

• 인덱스 또한 인덱스 블록으로 구성되어 있다.
• 데이터 블록에 있는 레코드들 중에서 하나의 레코드들만 인덱스 엔트리에 존재한다.
  • 주로 첫번째 엔트리

표시가 없는 레코드(ex 20) 찾을 때

• 인덱스를 통해 저장된 데이터 블록 쉽게 찾기가 가능하다.
• 10 과 30 사이 존재 => 10 블록 포인터로 데이터 블록에 접근

클러스터링 인덱스

• 중복이 가능한 탐색키에 의해 정렬된 화일 위에서 정의
• 범위 질의에 유용
• 범위 시작 값에 해당하는 인덱스 엔트리를 찾고, 인덱스 엔트리들을 따라가면서 레코드를 검색하면 디스크에서 읽는 블록 수가 최소화 된다.

👆 사원 이름에 따라 정렬

• index 이용 줄여 블록 순차적으로 접근하여 검색 가능

👆 탐색키 순서에 따라 정렬 x

• 랜덤하게 접근
• 블록 Access가 과다 => 탐색 시간, 참조 시간이 길다.

보조 인덱스

• 탐색 키 값에 따라 정렬되지 않은 데이터 화일에 대해 정의
• 보조 인덱스는 일반적으로 밀집 인덱스
• 디스크 접근 횟수가 기본 인덱스보다 높다.

• 레코드 포인터로 구성
• 데이터 화일 레코드 수와 동일한 인덱스 수

탐색 키가 기본 키인 경우 (기본 인덱스)

기본 인덱스를 밀집 인덱스으로 표현한 예시이다.

희소 인덱스와 밀집 인덱스의 비교

• 엔트리
  • 희소 인덱스는 데이터 블록마다 한 개
  • 밀집 인덱스는 각 레코드 마다 한 개
• 일반적으로 희소 인덱스의 엔트리 수가 밀집 인덱스의 엔트리 수보다 훨씬 적다.
• 희소 인덱스가 인덱스 탐색시 디스크 접근 수는 1만큼 적다.
  • 희소 인덱스가 밀집 인덱스에 비해 인덱스 단계 수가 1정도 적기 때문
• 희소 인덱스가 모든 갱신과 대부분의 질의에 대해 더 효율적
  • 인덱스가 정의된 애트리뷰트만 검색(COUNT질의)의 경우 데이터 화일에 접근할 필요가 없이 인덱스만 접근하기에 밀집 인덱스가 희소 인덱스보다 유리하다.
• 한 화일에는 한 개의 희소 인덱스와 다수의 밀집 인덱스를 가질 수 있다.

클러스터링 인덱스와 보조 인덱스

• 클러스터링 인덱스는 희소 인덱스일 경우가 많다.
  • 범위 질의에 좋다.
• 보조 인덱스는 거의 밀집 인덱스이므로 화일 접근 없이 처리가 가능하기도 하다.

6.6 다단계 인덱스

• 인덱스 자체가 큰 경우 인덱스 엔트리 탐색시간을 줄이기 위해 단일 단계 인덱스에 대해 다시 인덱스 정의

  • 단일 단계 인덱스를 순서화일로 간주

• 가장 상위 단계 인덱스 : 마스터 인덱스

  • 마스터 인덱슨느 한 블록이기에 주기억 장치에 상주가능
  • 주기억 장치에 상주하기에 디스크 접근이 필요없다.

• 주로 B+- 트리 사용

• 2, 3 단계 희소인덱스
• 1단계 인덱스 : 희소 or 밀집 인덱스
• 인덱스 블록 인수만큼 단계 올라갈수록 수가 줄어든다.
  • 블로킹 인수 10 이면 1/10씩 인덱스 수들이 줄어든다.
• 우리는 항상 마스터 인덱스에서 논의한다.

SQL 인덱스 정의문

• SQL의 CREATE TABLE에서 PRIMARY KEY로 명시된 애트리뷰트에 대해 DBMS가 자동적으로 기본 인덱스 생성
• UNIQUE로 명시한 애트리뷰트에 대해 자동적으로 보조인덱스 생성
• 추가로 인덱스를 정의하기 위해서는 CREATE INDEX문 이용

다수의 애트리뷰트를 사용한 인덱스 정의

두개 이상의 애트리뷰트들의 조합에 대해 하나의 인덱스 정의 가능

CREATE INDEX EMPINDEX ON EMPLOYEE (DNO, SALARY);

• DNO 기준 먼저 정렬
• DNO 같은 것들에 대해 SALARY 정렬
• 오름차순

• 범위 조건 (DNO >= 2), 동등 조건 (DNO = 2) 모두에 활용 가능
• 인덱스 정의어와 관련 없는 부분에 대한 조건질의에는 활용 불가
  • SALARY >= 300000 AND SALARY <= 400000

인덱스의 장단점

• 장점
  • 검색 속도 향상
  • 소수 래코드 수정, 삭제 연산의 속도가 향상
• 단점
  • 인덱스 저장을 위한 공간이 추가로 필요
  • 삽입, 삭제, 수정의 연산의 속도는 저하시킨다.

릴레이션이 매우 크고 , 투플들 중 일부를 검색, WHERE절이 잘 표현되어 있는 경우 성능에 큰 도움

6.7 인덱스 선정 지침과 데이터 베이스 튜닝

• 바람직한 성능들을 고려하여 인덱스 선정
• 가장 중요한 질의들을 차례로 고려, 현재의 인덱스가 최적의 계획에 적합한지 고려

인덱스 결정에 도움이 되는 지침

• 기본 키는 클러스터링 인덱스를 정의할 훌륭한 후보
• 외래 키도 인덱스를 정의할 중요한후보
  • 주로 JOIN에 자주 사용
• 투플이 많이 들어 있는 릴레이션에서 대부분의 질의가 검색하는 투플이 2%~4%인 경우 인덱스 생성
• 자주 갱신되는 애트리뷰트에는 인덱스 정의 X
  • 인덱스 갱신에 오버헤드 발생
• 갱신이 빈번한 릴레이션에도 인덱스 정의 X
• 한 애트리뷰트에 상이한 값들의 개수가 거의 전체 레코드와 비슷하며, 그 애트리뷰트가 동등 조건에 사용된다면 비 클러스터링 인덱스 생성
• 후보 키는 기본 키가 갖는 모든 특성을 가지기에 인덱스를 생성할 후보이다.
  • 이 때, 후보 키가 운영에 중요한지 고려하여 결정한다.
• 인덱스는 화일의 레코드를 충분히 분할해야한다.
• 정수형 에트리뷰트에 인덱스 생성
• VARCHAR 애트리뷰트에는 인덱스 생성 X
• 작은 화일에는 인덱스 X
  • 데이터 화일에 순차적 스캔보다 성능이 개선될 때에만 인덱스 생성
• 대량의 데이터 삽입 시 모든 인덱스를 제거한다.
  • 삽입 후 인덱스 재생성

인덱스가 사용되지 않는 경우

• 시스템 카탈로그가 오래 전의 데이터베이스 상태를 나타낸 경우
  • 예전 정보는 정확하지 않기에
• 릴레이션의 크기가 작아서 인덱스가 도움되지 않는 경우
  • DBMS의 질의 최적화 모듈이 판단
• 인덱스가 정의된 애트리뷰트에 산술연산자가 사용
• DBMS가 제공하는 내장 함수가 사용된 경우
• NULL값에 대해서는 주로 인덱스 사용 X
  • DBMS에 따라 NULL 관리 X 이기에

질의 튜닝을 위한 추가 지침

• DISTINCT 절 사용 최소화
• GROUP BY절과 HAVING절의 사용 최소화
• 임시 릴레이션 사용 X
• SELECT * 보다 SELECT절에 애트리뷰트 이름 구체적 명시

논리적 설계 단계에서 ER 스키마를 관계 데이터 모델의 릴레이션들로 사상한다. (Mapping)

• 관계 데이터베이스에는 엔티티 타입과 관계 타입을 구분하지 않는다.
• 사상대상에 따라 사상방법이 달라진다.
  • 엔티티 타입 or 관계타입
  • 정규 엔티티 타입 or 약한 엔티티 타입
  • 2진 관계 타입 or 3진 이상의 관계 타입
  • 단일 값 애트리뷰트 or 다치 애트리뷰트

ER-관계 사상 알고리즘

단계 1 정규 엔티티 타입과 단일 값 애트리뷰트

• 정규 엔티티 타입에 대해 릴레이션 생성
• 복합 애트리뷰트는 모두 단순 애트리뷰트로 바꾸어 릴레이션에 포함
• 엔티티 타입의 기본키가 릴레이션의 기본키

단계 2 약한 엔티티 타입과 단일 값 애트리뷰트

• 약한 엔티티 타입(E2)에 있던 모든 애트리뷰트들을 릴레이션(R)에 포함
• 소유 엔티티 타입(E1)의 기본 키를 R의 외래 키로 포함시킴
• R의 기본 키는 약한 엔티티 타입의 부분 키와 외래 키(소유 엔티티 타입의 기본키)의 조합으로 이루어짐.

단계 3 2진 1:1 관계 타입

• 관계 타입 R에 대해 R에 참여하는 엔티티 타입에 대응되는 릴레이션 2개 존재.
• 관계 타입에 완전하게 참여하는 릴레이션을 외래 키를 포함시키는 릴레이션을 선택
  • 완전 참여하는 쪽 릴레이션을 선택하여 외래키를 생성하는 이유는 최대한 NULL를 적게 만들기 위함이다.
• 관계 타입 R이 가지고 있는 모든 단순 애트리뷰트들을 외래키 가지고 있는 릴레이션에 포함.
• 두 엔티티 타입 모두 완전하게 참여 시에는 하나의 릴레이션으로 합치는 방법 존재.
  • 방법 4

• 추가적으로 방법 3은 관계를 나타내는 별도의 릴레이션을 만들어 각 릴레이션의 기본키를 외래키로 가져와서 기본키로 만든다.

단계 4 정규 2진 1:N 관계 타입

릴레이션 T, S 존재, 관계 R 존재

• 1:N 관계 에서 N측의 엔티티 타입에 대응되는 릴레이션 S
• 릴레이션 T의 기본 키를 릴레이션 S에 외래키로 포함.
  • 1측의 T에 외래 키로 포함시키면 애트리뷰트에 값들의 집합 또는 정보의 중복이 많이 발생. (N축 키를 외래키로 생성 X)
• 관계 타입 R 의 애트리뷰트 S로 포함

단계 5 2진 M:N 관게 타입

• 참여 엔티티 타입의 릴레이션들의 기본 키를 관계 릴레이션에 외래키로 포함시키고 이들의 조합을 기본 키로 한다.

단계 6 3진 이상의 관계 타입

• 단계 5처럼 관계 릴레이션 R 을 만들어서 대응되는 릴레이션들의 기본 키를 릴레이션 R에 외래 키로 포함시킨다.

• 엔티티 타입들의 카디날리티가 1:N:N이면 카디날리티가 1인 릴레이션의 기본 키를 참조하는 외래 키는 기본키 결합에서 제외된다.

단계 7 다치 애트리뷰트

• 다치 애트리뷰트에 대한 릴레이션 MVA 생성
• 관계 타입에 해당하는 릴레이션의 기본 키를 릴레이션 R에 외래키로 포함
• MVA의 다치 애트리뷰트와 외래 키의 조합은 기본 키가 된다.

• 마지막으로 ER 개념과 데이터베이스 개념들의 대응 관계이다.

ER 모델

데이터베이스 설계를 용이하기 위해 P.P.Chen이 제안하였으며 현재는 EER(Enhanced Entity Relationship)모델이 사용되고 있다.

• 개념적 설계를 위한 모델로 많은 CASE 도구들에서 지원
• 실세계를 엔티티, 애트리뷰트, 엔티티들 간의 관계로 표현한다.
• 관계 데이터 모델로 사상된다.
• 기본적인 구문으로 엔티티, 관계, 애트리뷰트가 있고 카디날리티 비율, 참여 제약조건 등이 있다.
• 정형적이고, 구현에 독립적이어서 설계자와 사용자들 간의 의사 소통에 적합하다.
• ER기반 모델을 기반으로 한 다수의 CASE도구(ERWin 등)은 ER 설계를 자동적으로 오라클, SQL Server, 사이베이스 등의 데이터 정의어로 변환한다.

기본적인 구문들에 대해 상세히 알아볼 것이다.

엔티티

사람, 장소, 사물, 사건 등과 같이 독립적으로 존재하며 고유하게 식별이 가능한 실세계(작은 세계)의 객체로 실체가 없는 생각이나 개념과 같은 추상적인 것도 엔티티가 되기도 한다.

엔티티 타입

엔티티들은 엔티티 타입(또는 집합)으로 분류된다.

• 타입 : 동일한 애트리뷰트들을 가진 엔티티들의 틀로 릴레이션의 내포에 해당한다.
• 집합 : 동일한 애트리뷰트들을 가진 엔티티들의 모임으로 릴레이션의 외연에 해당한다.
• 엔티티 하나는 여러 엔티티 집합에 속할 수 있다.
• 집합과 타입을 엄격하게 구분할 필요가 없다.
• ER 다이어 그램에서 엔티티 타입은 직사각형으로 나타낸다.

강한 엔티티 타입 정규 엔티티 타입으로 독자적으로 존재하며 자신의 키 애트리뷰트를 사용하여 고유하게 엔티티들을 식별할 수 있는 엔티티 타입

   ** 약한 엔티티 타입**

• 키를 형성하기에 충분한 애트리뷰트들을 갖지 못한 엔티티 타입
• 존재하기 위해서는 _소유 엔티티 타입_이 있어야 한다.
• 소유 엔티티 타입의 키 애트리뷰트를 결합해야만 약한 엔티티 타입의 엔티티들을 식별할 수 있다.

🔎 약한 엔티티 타입의 경우 사원(소유) 부양가족(약)으로 생각하여 한 사원의 부양가족에 동일이름이 없게 하여 구분이 가능하며 전체로 보았을 때 사람이 동일이름을 가질 수 있지만 한 사원(식별자)의 부양가족으로 보면 구분이 가능하다.

애트리뷰트

하나의 엔티티는 연관된 애트리뷰트들의 집합이다. 🔎 사원 엔티티 / 애트리뷰트 : 사원번호, 이름, 직책, 급여 등

• 애트리뷰트의 도메인 : 그 애트리뷰트가 가질 수 있는 모든 가능한 값들의 집합이다. 🔎 1000~9999의 사원번호

• 여러 애트리뷰트가 동일한 도메인을 공유할 수 있다. 🔎 사원번호와 부서번호는 도메인 : 1000~9999 가능

• 키 애트리뷰트 : 한 엔티티 타입내에서 각 엔티티들을 고유하게 식별한다. 🔎 한 애트리뷰트 또는 애트리뷰트들의 모임

• ER 다이어그램에서 타원형으로 표시하고, 기본 키 애트리뷰트는 밑줄을 그어 표시한다.

• 명사나 형용사로 표현된다.

• 엔티티는 독립적, 애트리뷰트는 독립적인 의미가 아니며 둘(엔티티 타입 - 애트리뷰트)은 실선으로 연결한다.

단순 애트리뷰트

원자성 지닌(쪼개지지 않는) 애트리뷰트

복합 애트리뷰트

두개 이상의 애트리뷰트로 이루어진 애트리뷰트로 서로 연관된 것들을 모아둔 것이다.

• 특정요소 검색이 필요할 시에 복합 애트리뷰트를 사용한다.

단일 값 애트리뷰트

엔티티마다 정확하게 하나의 값을 갖는 애트리뷰트

• 단순 애트리뷰트와 동일하게 표현 🔎 사원의 사원번호 애트리뷰트는 고유하다. 그렇기에 단일 값 애트리뷰트
• 대부분의 애트리뷰트가 이것에 속한다.

다치 애트리뷰트

엔티티마다 여러 개의 값을 가질 수 있는 애트리뷰트

• 이중선 타원으로 표현한다.

🔎 취미 - 축구, 농구

유도된 애트리뷰트

다른 애트리뷰트의 값으로 부터 얻어진 애트리뷰트

• 릴레이션의 애트리뷰트로 포함시키지 않는 것이 좋다.
• 점선 타원으로 표현

🔎 Age는 생년월일이라는 애트리뷰트를 통해서 구할 수 있다.

약한 엔티티 타입

위에서 말했듯이 키를 형성하기에 애트리뷰트가 부족한 엔티티 타입이다.

• 이를 구분하기 위해 약한 엔티티 타입에게 키 애트리뷰트를 제공하는 소유 엔티티 타입(식별 엔티티 타입)이다.
• 이중선 직사각형으로 표기한다.

부분 키 위의 설명처럼 한 사원(소유)에 속한 부양가족(약한)내에서는 서로 다르지만 회사 전체 사원들의 부양가족들 전체에서는 같을 수 있는 애트리뷰트 🔎 부분 키 : 부양가족 이름

• 약한 엔티티 타입의 부분 키는 점선 밑줄 로 표기한다

관계

관계는 엔티티들 사이의 연결로서 엔티티 타입들 사이의 사상(MAPPING)이다.

• 관계 집합 : 동질의 관계들의 집합

• 관계 타입 : 동질의 관계들의 틀

• 요구사항에서의 동사표현은 ER다이아그램에서 관계(다이아몬드)로 표현된다.

• 엔티티와 관계 사이는 실선으로 표현한다.

관계의 애트리뷰트

관계를 설명하는 애트리뷰트들을 가진다.

• 관계 타입은 키 애트리뷰트를 가지지 않는다.

차수

관계로 연결된 엔티티 타입들의 수를 의미한다.

🔎 1진 관계, 2진 관계, 3진 관계, N진 관계

카다날리티 비율

엔티티가 참여할 수 있는 관계의 수를 의미한다.

• 관계에 참여하는 엔티티들의 조합을 제한한다. 🔎 1:1, 1:N, M:N

📗 1:1 관계

• 정확하게 각각 다른 하나 엔티티와 연관되는 경우이다. (위 그림 참조) 🔎 사원이 최대한 한개의 PC(A)를 가지고 각 PC에 대해 한 명의 사원(B)이 있는 경우

📗 1:N 관계

• A의 각 엔티티가 B의 복수의 엔티티와 연관되고, B의 경우 A에게 한 엔티티와만 연관되는 관계 🔎 각 사원은 최대 PC(A) 한 개, 각 PC에 대해 여러 명의 사원들 (B)이 있는 경우

📗 M:N 관계

• A의 엔티티 타입 여러 개수가 B 엔티티 타입 여러게에 연관 🔎 각 사원에 대해 여러 대의 PC(A), 각 PC에 대해 여러명의 사원(B)

카디날리티 비율의 최소값과 최대값

• ER 다이어그램에서 관계와 엔티티 사이 실선은 (min, max) 형태로 표시
• min은 엔티티 타입 내의 각 엔티티는 적어도 min번 관계에 참여함을 의미한다.
  • min = 0 의 경우 반드시 관계에 참여할 필요가 없음
• max는 각 엔티티가 최대한 max번 관계에 참여함을 의미한다.
  • max = * 에 대해 엔티티가 관계에 임의의 수만큼 참여할 수 있음을 의미

• 화살표 존재 : 1의 관계
• 화살표 머리 X : N의 관계

카디날리티가 적용된 관계 타입 예시

• CAR : 안팔리거나 1번 팔리기
• CUSTOMER : 고객님이 안사거나 여러개 구매
• SALESPER : 못 팔거나 여러대 판매

카디날리티 비율 역할

관계 타입의 의미를 명확하게 사용하기 위해 사용된다.

• 관계 타입에 하나의 엔티티타입이 여러 번 나타나는 경우 반드시 역할 표기
• 간선 위에 표시한다.

전체 참여와 부분 참여

전체 참여

어떤 관계에 엔티티 타입의 모든 엔티티들이 관계 타입에 의해 다른 엔티티 타입과 연관되는 것을 의미한다.

• 약한 엔티티 타입은 항상 관계에 전체참여
• 전체 참여는 이중 실선으로 표시한다.

부분 참여

어떤 관계에 엔티티 타입의 일부 엔티티만 참여하는 것을 의미한다.

참여 조건은 카디날리티 비율과 함께 관계에 대한 중요한 제약조건이다.

다중 관계

• 엔티티 타입 사이에 두 개 이상의 관계 타입이 존재할 수 있다.

순환적 관계

엔티티 타입이 동일한 관계 타입에 두 번 이상 참여한다.

ER 스키마 작성 지침

• 엔티티는 키 애트리뷰트 이외에 설명 정보를 가진다.
• 다치 애트리뷰트는 엔티티로 분류한다. 관계 DB스키마에서는 원자값만 요구하기에 다치 애트리뷰트가 적절하지 않다.
• 가능한 복합 식별자를 피해야한다.
• 엔티티와 관계 중 어느 것으로 모델링할 것인지를 구분하는 것은 어렵기에 요구사항에 따라 구분한다.

애트리뷰트 vs 엔티티

엔티티와 애트리뷰트를 구분하는 절대적인 기준은 없다.

🔎 공급자에 대한 정보

• 공급자 번호
• 공급자 이름
• 신용
• 공급자 도시

  공급자는 엔티티가 명확하다. 여기서, 공급자 도시는 엔티티인가 또는 애트리뷰트인가?

  • 도시가 조직체에 관심이 있는 객체인가?
  • 도시에 관한 애트리뷰트들을 유지할 필요가 있는가?
  • 도시를 여러 엔티티 타입들이 공유하는가?

위의 고려사항 중에 하나라도 대답이 '예' 라면 도시에 대한 추가 정보를 모아서 엔티티로 나타낸다.

새발 표기법

• ER 모델의 또 다른 표기법

• 1대1 관계

• 1대N 관계

• M대N 관계

• 엔티티 타입과 애트리뷰트

  • 엔티티 타입은 직사각형을 확장한다.
  • 다치, 유도, 복합 애트리뷰트를 구분하기 어렵다.

데이터베이스 설계는 개념적 데이터베이스 설계와 물리적 데이터베이스 설계로 구분된다.

• 개념적 데이터베이스 : 실제 데이터베이스 구현과는 별개로 정보 사용의 모델을 개발하는 과정이다.
• 물리적 데이터베이스 : 물리적인 저장 장치와 접근 방식에 대해 다룬다.

개념적 데이터베이스

실제 데이터베이스 구현과는 별개로 정보 사용의 모델을 개발하는 과정으로 조직체(실세계)의 엔티티, 관계, 프로세스, 무결성 제약조건 등을 나타내는 _추상화 모델_을 만든다.

• 엔티티 : 서로 구분이 되며 데이터베이스에 나타내려는 객체(사람, 장소, 사물)를 의미한다.
• 관계 : 엔티티들간의 연관을 나타낸다.
• 프로세스 : 활동
• 무결정 제약조건 : 데이터의 정확성과 비즈니스 규칙

개념적 수준의 모델

• 특정 데이터 모델(관계, 네트워크, 객체지향 모델)과 독립적으로 응용 시계를 모델링한다.
• 데이터베이스 스키마, 구조를 하향식으로 개발할 수 있는 틀을 제공한다.
• 다수의 구현 데이터 모델이 존재하는데 그 중 대표적으로 ER모델이 있다.

구현 단계에서는 관계, 네트워크, 객체지향, 계층 데이터 모델이 사용된다.

5.1 데이터베이스 설계의 개요

데이터 베이스 설계

데이터 베이스

조직체의 운영과 목적을 지원하기 위해 데이터베이스를 생성하는 것이다.

목적

모든 주요 응용과 사용자들이 요구하는 데이터, 데이터간의 관계를 표현하기 위해서 만들어 진다.

설계

아래는 훌륭한 데이터베이스의 설계에 대한 설명이다.

• 시간의 흐름에 따른 데이터의 모든 측면을 나타낸다.

• 데이터 항목의 중복을 최소화한다.
• 데이터베이스에 대해 효율적인 접근을 제공한다.
• 데이터베이스의 무결성을 제공한다.
• 이해하기 쉬워야 한다.

데이터베이서 설계의 주요 단계

위 그림은 데이터 베이스 설계의 단계를 나눈 것이다.

일반적으로, 설계의 완성도를 높이기 위해 유동적으로 작업하기도 한다.

요구사항 수집과 분석

• 작은 세계(설계 대상)에 대해 문서 조사, 인터뷰, 설문 조사와 같은 사실 수집(데이터 수집)
• 요구사항을 기반으로 엔티티들과 이들의 애트리뷰트, 관계를 파악한다.
• 데이터 처리에 관한 연산, 연산들의 의미, 접근하는 데이터의 양을 분석한다.

개념적 설계

• 한 조직체에서 사용되는 정보의 모델을 구축한다.
• 요구사항으로부터 개념적 스키마가 생성된다.
• 정형적인 언어로 데이터 구조를 명시한다.
• ER모델, 객체지향 모델, UML 모델 등이 존재한다.
• 완성된 개념적 스키마(ER 스키마)는 ER 다이어그램으로 표현한다.

개념적 설계 단계에서는 엔티티 타입, 관계 타입, 애트리뷰트들을 식별, 애트리뷰트들의 도메인을 결정하고, 후보 키와 기본 키 애트리뷰트를 결정한다.

DBMS 선정

여러 요인들을 검토하여 선정한다.

• 기술적 : DBMS가 제공하는 데이터 모델, 저장 구조, 인터페이스, 질의어, 도구, 제공되는 서비스
• 정치적 : 고수준의 전략적인 결정
• 경제적 : DBMS 구입 비용, 하드웨어 구입 비용, 유지비용, 변환비용 등

논리적 설계

데이터 베이스 관리르 위해 DBMS의 데이터 모델을 사용하여 논리적 스키나(외부 스키마도 포함)를 생성함.

• 개념적 스키마에 알고리즘을 적용하여 논리적 스키마를 생성한다.
• 관계 데이터 모델을 사용하는 경우, ER모델로 표현된 개념적 스키마를 관계 데이터베이스 스키마로 사상한다.
• 더 좋은 관계 데이터베이스 스키마로 변환하기 위해 정규화 과정을 적용한다.
• 개념적 설계 없이 논리적 설계로 가면 좋은 관계 데이터베이스 스키마가 생성되지 않는다.

물리적 설계

요구사항을 만족 시키기 위해 저장 구조와 접근(엑세스) 경로 등을 결정한다.

성능상의 주요 기준

• 응답 시간
• 트랜잭션 처리율
• 보고서 생성 시간

트랜잭션 설계

데이터베이스 설계 과정 과 별도로 트랜잭션 설계를 할 수 있다.

• 완성될 데이터베이스에서 동작할 응용프로그램
• 데이터베이스 스키마는 트랜잭션에서 요구되는 모든 정보를 포함해야한다.
• 검색, 갱신, 혼합 등으로 구분하여 입력, 출력, 동작등을 식별한다.

1. NoSQL vs SQL

MySQL은 SQL의 대표적인 데이터베이스다. 그렇다면 NoSQL의 대표적인 데이터베이스는 무엇일까? 위에 보이는 몽고디비는 NoSQL의 대표 주자이다.

그렇다면 NoSQL과 SQL의 차이점은 무엇일까? 위에 보이는 표는 SQL과 NoSQL의 차이점을 정리한 표이다.

하나하나 차례대로 설명해보자.

• NoSQL에는 고정된 테이블이 없다.

예를 들어 MySQL은 users 테이블을 생성할 때 name, age 등의 칼럼과 자료형, 옵션 등을 정의하짐나, 몽고디비는 users 컬렉션(Mysql기준 테이블)을 만들고 어떠한 데이터든 들어간다.

• mongoDB에는 JOIN 기능이 없다.

JOIN기능이 없는 대신 aggregate를 통해 join과 비슷한 역할을 수행할 수 있다. 하지만 동시에 쿼리를 수행하는 경우 쿼리가 섞여 예상치 못한 결과를 낼 수 있다는 단점이 있다.

• 확장성과 기용성이 뛰어나다.

MySQL과 달리 안정성과 일관성을 보장해주는 기능이 약한 대신 데이터를 빠르게 넣을 수 있고 쉽게 여러 서버에 데이터를 분산해서 넣을 수 있다는 장점이 있다.

• 용어가 다르다.

이것은 표에 있는 것들을 매치해서 비교해보자!!

❓그렇다면 어떤 데이터베이스를 써야할까??

개발을 할 때 꼭 한가지 데이터베이스를 사용해야하는 것은 아니지만 각각의 특징에 맞게 알맞은 데이터베이스를 사용하면 된다.

예를들어 상용적인 서비스같은 경우는 일관성 있게 전달이 되어야하므로 SQL를 빅테이터, 메시징, 세션 관리등 빠르게 전달이 필요할 때는 NoSQL을 사용한다. (비정형 데이터를 사용할 때!)

MEAN스택

2. 데이터베이스, 컬렉션 생성하기

데이터베이스를 만들어 보기전에 어드민 설정 후 커넥션을 생성해보자!

어드민 설정 및 연결

mongoDB를 실행하고 있을 때 누구나 mongoDB에 접속하는 것은 보안성이 떨어진다. 그렇기에 관리자 계정을 추가하자.

기본적으로 존재하는 admin이라는 스키마로 변경한다.

db.createUser 메서드를 통해 관리자 계정을 추가한다. 여기서 roles : ['root'] 는 모든 권한이 있는 것으로 나중에 실무에 가게되면 상황에 맞는 역할을 부여하게 된다.

그 후 mongod를 명령 프롬프트로 실행해 위의 명령어로 접속한다. 여기서 --auth는 로그인이 필요하다는 의미이다,

그 후 앞에서 쓴 이름과 비밀번호를 입력하여 관리자 권한으로 들어간다.

이 외에도 맥, 리눅스도 있지만 지금 윈도우로 하고 있으니 나중에 아래의 참고자료를 통해 그 환경에서 해보자!

커넥션 생성하기

mongodb를 실행한 후 컴퍼스로 접속한다.

위의 사진은 실행화면이며 여기에서 Authentication을 Username/Password로 바꾼 후 등록한 몽고비디의 계정 이름과 비밀번호를 입력하여 Connect한다.

연결 중

연결이 완료되면 다음과 같이 기본적으로 존재하는 세 개의 데이터베이스가 화면에 표시된다.

데이터베이스 생성하기

이제 nodejs라는 데이터베이스를 생성해보자!

명령프롬프트를 사용하여 보여줄 것이지만 compass의 사진도 첨부할 것이다!

위의 그림처럼 use [데이터베이스명] 이렇게 치면 데이터베이스가 생성되고 그 데이터베이스로 이동하게 된다.

하지만 show dbs를 실행할 때에는 데이터베이스 목록에 뜨지 않는다.

그 이유는 아직 nodejs라는 데이터베이스가 아무 데이터도 들어있지 않기 때문이다. 그렇기에 현재 위치를 확인하기 위해 db를 눌러보았을 때 nodejs가 뜨면서 생성이 잘 되었음을 확인할 수 있다.

아래는 compass에서 만드는 방법이다!

이 버튼을 누르면 아래의 그림처럼 데이터베이스를 쉽게 생성할 수 있다!

컬렉션 생성하기

이제 컬렉션을 생성해보자! 컬렉션은 SQL로 따지면 테이블이라고 생각하면 편하다.

사실 다큐먼트(row)를 넣는 순간 컬렉션이 자동으로 생성되기에 따로 생성할 필요가 없다.

하지만 생성하는 방법은 알아두자.

이렇게 db.createCollection 이라는 명령어를 통해 collection을 생성할 수 있다.

중간에 잘못 만들어서 삭제를 해야한다면 db.[collction name].drop()을 하면 해당 collection을 삭제할 수 있다.

compass로도 살펴보자!

nodejs 데이터 베이스를 들어가서 보면 위의 버튼이 있을 것이다. 이걸 이용해서 삭제하면된다.

위의 그림은 명령 프롬프트를 이용해서 생성한 collection들이다.

compass가 편하지만 지원이 안 되는 부분들도 있으니 명령 프롬포트를 이용해서 하는 방법에 익숙해지자!

3. CRUD 작업하기

mongoDB는 필드(컬럼)을 정의하지 않아도 된다!

mongoDB는 자유로움이 장점이기에 json 형식이면 알아서 데이터가 들어가게 된다.

Create

설명의 편리성을 위해 compass로 json형태의 데이터를 만들어보자!

+09 로 해야 대한민국 시간

_id 란? odject id 라고 겹치지않는 고유한 값. 날짜 포함 -> 시간순정렬 가능

몽고디비는 자유롭게 다양한 데이터 형식 받을 수 있다는 의미!

kang 의 object 아이디

comments와 user 연결 -> kang의 댓글

다만, mongoDB는 mysql과 달리 검사를 하지 않는다. 오타 시 취약.

콘솔 나중에 CRUD 콘솔로 한번 정리후 나중에 위에 내용 정리

4. 몽구스 사용하기

몽구스 ODM

• 몽구스란?

몽고디비 작업을 쉽게 할 수 있도록 도와주는 라이브러리 (javascript로 구성)

❓ 왜 몽고디비도 javascript로 되어있는데 한 번더 쓰는 이유

💡 몽고디비에 없어 불편한 기능들을 몽구스가 보완을 해준다! ex) 테이블과 유사한 기능, JOIN 기능 Update시 set 빼먹는 행위 방지해주는 기능, 추가 즉, SQL과 비슷한 방식으로 만들어서 기능을 보완해준다.

BUT! sql과 비슷해져서 확장성 가용성 제한되는 단점이 존재

그래서 사실상 몽구스를 사용하는건 모순이 존재하지만 db마저 javascript로 하고 싶은 개발자들이 만든 것이라고 보고, 공부하자!!