SQL 개발자(SQLD)

SQL 개발자(SQLD) 시험 노트개념 정리19 MIN

데이터 모델링과 3층 스키마

SQLD 1과목의 첫 자리입니다. 모델링의 세 가지 특징과 세 가지 관점, 외부·개념·내부 3층 스키마와 두 가지 데이터 독립성, 개념·논리·물리 모델의 단계, ERD 표기법과 작성 순서까지 표로 갈라 정리합니다.

SQLD는 객관식 50문항을 90분에 봅니다. 그중 1과목 「데이터 모델링의 이해」가 10문항이고 나머지 40문항이 2과목입니다. 총점 60점 이상이 합격이고 과목별 40% 미만이 과락이므로, 1과목에서 최소 4문항은 맞혀야 2과목을 아무리 잘 봐도 떨어지지 않습니다. 이 노트는 그 10문항이 시작되는 자리 — 데이터 모델링이라는 낱말의 뜻부터 ERD를 그리는 순서까지를 다룹니다.

데이터 모델링이라는 작업

데이터 모델링은 현실 세계의 업무를 데이터 관점에서 약속된 표기법으로 옮겨 적는 일입니다. 옮겨 적은 결과물이 데이터 모델이고, 그 모델이 나중에 테이블과 컬럼이 됩니다. 그래서 모델링은 그림 그리기가 아니라 데이터베이스 설계의 첫 단계입니다.

추상화·단순화·명확화

모델링에는 특징이 셋 있고 시험은 이 셋의 이름과 뜻을 짝지어 묻습니다.

특징 뜻 실제로 하는 일
추상화 현실을 일정한 형식으로 표현한다 사람마다 다른 「고객」을 하나의 엔터티로 뽑는다
단순화 약속된 규약과 표기법으로 간결하게 표현한다 업무 규칙을 관계선 하나로 줄인다
명확화 뜻이 하나로 읽히게 정확히 기술한다 「주문일자」가 접수일인지 결제일인지 정의한다

셋 중 하나만 빠져도 모델이 망가집니다. 추상화가 없으면 현실이 그대로 들어와 엔터티가 수백 개가 되고, 단순화가 없으면 읽는 사람마다 다르게 그리며, 명확화가 없으면 같은 컬럼을 두 팀이 다른 뜻으로 채웁니다.

세 가지 관점

같은 업무를 무엇으로 보느냐에 따라 모델링의 관점이 셋으로 갈립니다.

관점 보는 것 결과물
데이터 관점 업무가 사용하는 데이터는 무엇인가 데이터 모델(ERD)
프로세스 관점 업무가 하는 일은 무엇인가 프로세스 모델
상관 관점 그 일이 어떤 데이터를 쓰는가 CRUD 매트릭스

상관 관점은 앞의 둘을 격자로 엮어 어느 프로세스가 어느 엔터티를 생성·조회·수정·삭제하는지 표로 적은 것입니다. 세로축에 프로세스, 가로축에 엔터티를 놓고 칸마다 C·R·U·D를 적으면, 아무도 만들지 않는 엔터티나 아무도 읽지 않는 엔터티가 빈칸으로 드러납니다. 모델의 구멍을 찾는 점검표인 셈입니다. 데이터 모델링 시험이라 데이터 관점만 물을 것 같지만, 세 관점의 이름을 나열하고 틀린 설명을 고르게 하는 형태로 자주 나옵니다.

모델링을 잘못했을 때

같은 데이터가 여러 테이블에 흩어져 값이 서로 어긋나는 것이 중복, 데이터의 정의를 조금만 바꿔도 프로그램을 여러 곳 고쳐야 하는 것이 비유연성, 서로 모순되는 값이 동시에 저장되는 것이 데이터 불일치입니다.

셋 중 비유연성이 가장 늦게 드러납니다. 고객의 전화번호를 고객 테이블과 주문 테이블에 함께 두면 처음에는 조회가 편하지만, 번호 형식을 열한 자리로 바꾸는 순간 두 테이블과 그 둘을 읽는 모든 화면을 함께 손봐야 합니다. 데이터 구조와 업무 로직을 분리해 두는 것이 모델링의 목적이고, 이 셋을 줄이는 구체적인 기법이 뒤에 나올 정규화입니다.

3층 스키마

3층 스키마는 하나의 데이터베이스를 보는 시선을 세 층으로 나눠 정의한 구조입니다. 미국표준협회(ANSI/SPARC)가 제안한 것이라 ANSI 3층 스키마라고도 부릅니다.

외부·개념·내부

층 누구의 시선 무엇을 담나
외부 스키마 사용자와 개발자 각자에게 필요한 부분만 잘라 본 뷰. 여럿이다
개념 스키마 전사 통합 관점 조직 전체의 데이터를 하나로 통합한 모델. 하나다
내부 스키마 데이터베이스 관리자 실제 저장 구조, 인덱스, 파일 배치

외부 스키마는 사용자 수만큼 여럿일 수 있지만 개념 스키마는 조직에 하나뿐입니다. 이 「여럿 대 하나」가 문제로 자주 나옵니다.

두 가지 데이터 독립성

층을 나누는 목적은 한 층을 고쳐도 다른 층이 안 흔들리게 하는 것이고, 그것을 데이터 독립성이라 부릅니다.

독립성 어느 층 사이 무엇이 바뀌어도 되는가
논리적 독립성 외부 ↔ 개념 개념 스키마에 컬럼을 더해도 기존 화면과 뷰가 안 바뀐다
물리적 독립성 개념 ↔ 내부 인덱스를 추가하거나 저장 장치를 바꿔도 논리 구조가 안 바뀐다

헷갈릴 때는 바뀌는 쪽이 어디인지를 봅니다. 테이블에 컬럼을 하나 추가했는데 기존 프로그램이 멀쩡하면 논리적 독립성이고, 디스크를 SSD로 옮겼는데 SQL이 그대로면 물리적 독립성입니다.

사상

층과 층 사이를 이어 주는 대응 관계를 사상(Mapping)이라 부릅니다. 외부 스키마의 「주문조회 화면」이 개념 스키마의 어느 엔터티와 어느 속성에서 오는지를 적어 둔 것이 외부/개념 사상이고, 개념 스키마의 테이블이 실제로 어느 파일과 어느 인덱스에 담기는지를 적어 둔 것이 개념/내부 사상입니다. 독립성이 지켜진다는 말은 아래층이 바뀌었을 때 사상만 고치면 위층은 그대로 둬도 된다는 뜻입니다. 층을 셋으로 나눈 대가로 이 대응표를 유지해야 하는 것이고, 그 대가를 치르는 이유가 독립성입니다.

개념·논리·물리 데이터 모델

모델링은 한 번에 끝나지 않고 추상화 수준을 낮춰 가며 세 단계로 진행됩니다. 이름이 3층 스키마와 비슷해 보이지만 다른 개념입니다 — 3층 스키마는 완성된 데이터베이스를 보는 시선의 층이고, 이쪽은 모델을 만들어 가는 작업의 단계입니다.

단계마다 정하는 것

단계 추상화 수준 이 단계에서 정하는 것
개념 데이터 모델 높다 핵심 엔터티와 관계. 업무 전체 그림
논리 데이터 모델 중간 모든 엔터티·속성·식별자, 정규화
물리 데이터 모델 낮다 테이블·컬럼·데이터 타입·인덱스, 반정규화

개념 모델과 논리 모델의 경계가 가장 흐릿합니다. 가르는 기준은 속성을 다 채웠는가입니다. 「고객」·「주문」·「상품」 같은 핵심 엔터티와 그 사이의 관계만 있으면 개념 모델이고, 거기에 모든 속성과 식별자를 붙이고 정규화까지 마치면 논리 모델입니다.

논리 모델까지는 특정 DBMS와 무관합니다. 오라클을 쓰든 SQL Server를 쓰든 논리 모델은 같고, 물리 모델에 와서야 VARCHAR2인지 VARCHAR인지가 갈립니다. 「어느 단계부터 DBMS에 종속되는가」를 물으면 답은 물리 모델입니다.

두 가지 진행 방향

큰 그림에서 시작해 세부로 내려가는 방식을 하향식(Top-down), 개별 업무 화면과 장표에서 시작해 통합해 올라가는 방식을 상향식(Bottom-up)이라 부릅니다. 하향식은 업무 전체의 뼈대가 먼저 잡히지만 현장의 예외를 놓치기 쉽고, 상향식은 실제 쓰는 항목이 빠짐없이 들어오지만 비슷한 엔터티가 여럿 생겨 통합에 품이 듭니다. 현업에서는 개념 모델을 하향식으로 잡고 논리 모델을 상향식으로 채우는 식으로 섞어 씁니다.

ERD

ERD(Entity Relationship Diagram)는 엔터티를 상자로, 관계를 선으로 그려 데이터 모델을 표현한 그림입니다. 1976년 피터 챈이 제안한 표기법이 출발점이고, 지금 실무에서 가장 많이 쓰는 것은 IE 표기법(까마귀발 표기법)과 바커 표기법입니다.

두 표기법

견줄 것 IE 표기법 바커 표기법
다(多) 쪽 표시 선 끝이 까마귀 발처럼 세 갈래로 갈라진다 선 끝이 세 갈래로 갈라진다
선택 관계 선 위에 동그라미 관계선의 절반을 점선으로
필수 관계 선 위에 세로 막대 관계선의 절반을 실선으로
식별자 표시 상자 안 가로줄 위쪽에 적는다 속성 앞에 #

IE 표기법에서 동그라미는 「없어도 된다」, 세로 막대는 「하나는 있어야 한다」를 뜻합니다. 두 기호가 관계선의 양쪽 끝에 따로 붙으므로, 한쪽 끝만 보고 관계 전체의 성격을 단정하면 안 됩니다.

그리는 순서

ERD는 아무 데서나 시작하지 않고 순서가 정해져 있습니다.

  1. 엔터티를 그린다
  2. 엔터티를 적절히 배치한다
  3. 엔터티 간 관계를 설정한다
  4. 관계명을 기술한다
  5. 관계의 참여도(카디널리티)를 기술한다
  6. 관계의 필수 여부를 기술한다

앞의 둘이 상자, 뒤의 넷이 선입니다. 배치에도 요령이 있습니다 — 가장 중요한 엔터티를 왼쪽 위에 두고 그것을 중심으로 나머지를 펼치면 관계선이 덜 엉킵니다.

관계명은 동사로 적고 양방향을 따로 적습니다. 고객과 주문 사이라면 고객 쪽에서 읽을 때 「주문한다」, 주문 쪽에서 읽을 때 「주문된다」입니다. 한쪽만 적으면 관계를 문장으로 읽을 수 없고, 문장으로 못 읽는 관계는 대개 잘못 그린 관계입니다. 작성 순서는 번호를 섞어 놓고 바르게 나열한 것을 고르게 하는 형태로 나오며, 틀린 보기는 대개 관계 설정과 엔터티 배치의 자리를 바꾸거나 관계명을 참여도보다 뒤로 밀어 둡니다.

연습 문제

  1. 데이터 모델링의 세 가지 특징 중, 「주문일자」가 접수일인지 결제일인지 정의해 두는 일에 해당하는 것은?
    ① 추상화
    ② 단순화
    ③ 명확화
    ④ 정규화
    ③. 뜻이 하나로 읽히게 정확히 기술하는 것이 명확화입니다. 정규화는 모델링의 특징이 아니라 논리 모델 단계의 기법입니다.
  2. 3층 스키마에 대한 설명으로 옳지 않은 것은?
    ① 외부 스키마는 사용자마다 여럿일 수 있다
    ② 개념 스키마는 조직 전체를 통합한 하나의 모델이다
    ③ 내부 스키마는 인덱스와 저장 구조를 담는다
    ④ 개념 스키마는 사용자 화면 단위로 여럿을 만든다
    ④. 여럿인 쪽은 외부 스키마이고 개념 스키마는 조직에 하나입니다.
  3. 다음 상황이 보장하는 독립성은?
    「테이블에 컬럼을 하나 추가했지만 기존 화면과 뷰는 고치지 않아도 그대로 동작했다」
    ① 물리적 독립성
    ② 논리적 독립성
    ③ 구조적 독립성
    ④ 절차적 독립성
    ②. 개념 스키마가 바뀌어도 외부 스키마가 안 흔들리는 것이므로 논리적 독립성입니다. 저장 장치나 인덱스가 바뀌어도 논리 구조가 그대로인 쪽이 물리적 독립성입니다.
  4. 데이터 모델의 세 단계에 대한 설명으로 옳은 것은?
    ① 개념 모델에서 데이터 타입과 인덱스를 정한다
    ② 논리 모델은 특정 DBMS의 문법에 종속된다
    ③ 물리 모델 단계에서 반정규화를 검토한다
    ④ 정규화는 물리 모델 단계에서 처음 수행한다
    ③. 반정규화는 물리 모델에서 조회 성능을 위해 검토합니다. ①은 물리 모델, ②는 물리 모델부터 종속되며, ④의 정규화는 논리 모델 단계의 일입니다.
  5. ERD 작성 순서로 올바른 것은?
    ① 엔터티 도출 → 관계 설정 → 엔터티 배치 → 관계명 기술 → 참여도 기술 → 필수 여부 기술
    ② 엔터티 도출 → 엔터티 배치 → 관계 설정 → 관계명 기술 → 참여도 기술 → 필수 여부 기술
    ③ 엔터티 배치 → 엔터티 도출 → 관계 설정 → 참여도 기술 → 관계명 기술 → 필수 여부 기술
    ④ 엔터티 도출 → 엔터티 배치 → 관계명 기술 → 관계 설정 → 필수 여부 기술 → 참여도 기술
    ②. 상자를 먼저 그려 배치한 뒤 선을 잇고, 그 선에 이름·참여도·필수 여부를 차례로 붙입니다.
  6. 데이터 모델링의 세 가지 관점 중 CRUD 매트릭스가 만들어지는 관점은?
    ① 데이터 관점
    ② 프로세스 관점
    ③ 상관 관점
    ④ 물리 관점
    ③. 어느 프로세스가 어느 데이터를 생성·조회·수정·삭제하는지 격자로 엮는 것이 상관 관점입니다. 물리 관점이라는 항목은 세 관점에 없습니다.

1과목 10문항 중 이 노트의 범위에서 두세 문항이 나옵니다. 표의 왼쪽 열과 오른쪽 열을 가리고 서로 불러 보는 연습이 그대로 대비가 되고, 특히 3층 스키마와 세 단계 모델은 이름이 닮아 섞이기 쉬우므로 「시선의 층」과 「작업의 단계」로 갈라 외우는 편이 안전합니다.

SQL 개발자(SQLD) 시험 노트 전체 보기