Day 29 · 스키마와 제약

A SMALL DETOUR

이번 회차, 내 속도로.

기초를 더 짚거나 궁금한 주제로 잠깐 넓혀 보세요. 최대 3단계를 거쳐 DAY 29로 돌아옵니다.

난이도·관심 주제 고르기

이번 회차는 어느 속도로 볼까요?기초부터새 보충 수업부터 짚어요현재 수준으로관심 주제부터 살펴봐요한 걸음 더새 심화 수업까지 넓혀요

더 살펴볼 주제 1~2개 선택레이블·관계 타입·속성 이름 규칙추가 11 · 새 수업 · DAY 26·27에서 레이블·관계·속성을 배운 뒤, 이름을 잘못 지어 질의가 조용히 틀리는 경우를 미리 막기 위해 옵니다.표·외래 키·조인 표 변환추가 12 · 새 수업 · DAY 28에서 JOIN과 순회를 비교했다면, 실제 관계형 스키마를 그래프 모델로 바꾸는 규칙과 예외를 연습하러 옵니다.레이블·속성DAY 26 · 레이블과 키–값 속성으로 노드에 종류와 값을 담는 기본 단위를 확인합니다.관계 타입·관계 속성DAY 27 · 두 노드 사이에서만 성립하는 사실을 관계 타입과 관계 속성에 적는 법을 익힙니다.JOIN·인덱스 없는 인접DAY 28 · 인접 참조를 따라가는 순회와 테이블 JOIN의 비용 차이, 그리고 그 한계를 비교합니다.객체 타입·기본 키·백킹 데이터셋DAY 72 · 레이블·속성·업무 키가 팔란티어 온톨로지의 객체 타입·속성·기본 키로 어떻게 이어지는지 미리 연결합니다.

1/2개 선택 · 새 보충·심화 수업과 본과정 다시 읽기를 선택할 수 있어요.

이렇게 다녀와요 1단계 · 약 12분

출발 · DAY 29유일성·존재 제약
1. 관심 주제레이블·관계 타입·속성 이름 규칙추가 11 · 새 추가 수업
복귀 · DAY 29원래 회차 이어가기

레이블·관계 타입·속성 이름 규칙 · DAY 26·27에서 레이블·관계·속성을 배운 뒤, 이름을 잘못 지어 질의가 조용히 틀리는 경우를 미리 막기 위해 옵니다.

선택과 경로 기록은 이 브라우저에 저장됩니다. 본과정의 회차 완료와는 별도입니다.

복귀: DAY 29 → 본과정 다음 회차: DAY 30

01 / UNDERSTAND

핵심 개념

속성 그래프 DB는 대개 스키마 선택적(schema-optional)입니다. 레이블과 속성을 미리 선언하지 않아도 노드를 넣을 수 있습니다. 덕분에 빨리 시작할 수 있지만, 같은 email을 가진 민수 노드가 두 개 생기거나 이름 없는 :Person이 들어오는 일도 막지 못합니다. 제약(constraint)은 쓰기 시점에 이런 데이터를 거부하는 규칙입니다.

유일성 제약은 같은 레이블 안에서 속성 값이 겹치지 않게 합니다. CREATE CONSTRAINT person_email FOR (p:Person) REQUIRE p.email IS UNIQUE를 걸면 이미 있는 email로 새 :Person을 만드는 쓰기가 실패합니다. Neo4j에서는 유일성 제약을 만들면 같은 이름의 범위 인덱스가 함께 생겨 email로 사람을 찾는 질의도 빨라집니다. 단, email이 아예 없는 노드는 비교 대상이 아니어서 유일성 제약만으로는 거부되지 않습니다.

존재 제약은 REQUIRE p.name IS NOT NULL처럼 속성이 반드시 있게 하고, 속성 타입 제약은 REQUIRE p.age IS :: INTEGER처럼 값의 타입을 고정합니다. 키 제약(IS NODE KEY)은 존재와 유일성을 한 번에 요구합니다. Neo4j에서 유일성 제약은 Community 에디션에서도 쓸 수 있지만, 존재·타입·키 제약은 Enterprise 에디션 기능입니다.

제약은 형식만 지킵니다. 유일한 email이라도 오타일 수 있고, 정수 나이라도 틀린 값일 수 있습니다. 또 이미 규칙을 어기는 데이터가 있으면 제약을 만드는 일 자체가 실패하므로 정리부터 해야 합니다. 어떤 속성을 업무 키로 삼고 어떤 값을 반드시 받을지는 질문과 업무 규칙에서 정합니다.

제약은 쓰기 시점에 중복·누락·타입 오류를 거부해, 스키마 선택적인 그래프의 데이터 품질을 지킵니다.

02 / WORKED EXAMPLE∑

작은 예제로 따라가기

입력 A {name:'민수', email:'minsu@lab.kr', age:29}는 세 제약(email 유일, name 존재, age 정수)을 모두 통과합니다.

입력 B {name:'민수', email:'minsu@lab.kr'}는 A와 email이 같아 유일성 제약에 걸려 거부됩니다.

입력 C {email:'c@lab.kr', age:'스물아홉'}은 name이 없어 존재 제약에, age가 문자열이라 타입 제약에 걸립니다.

03 / EXPLORE

직접 실험해 보기

제약 체크박스를 하나씩 켜고 끄며 네 가지 입력(정상/이메일 중복/이름 누락/나이 문자열)이 허용되는지 거부되는지 기록하고, 각 거부를 만든 제약을 짝지어 적으세요.

LIVE EXPERIMENT · CONSTRAINTS

제약으로 잘못된 노드 막기

CREATE (:Person {
  name: '세린',
  email: 'serin@lab.kr',
  age: 27
})

// 제약 없음 — 스키마 선택적(schema-optional)
// 어떤 속성 조합이든 그대로 저장된다

지금 제약으로 네 입력을 검사하면
입력	판정	이유
정상	허용	통과
이메일 중복	허용	통과
이름 누락	허용	통과
나이 문자열	허용	통과

기존 Person 6명 중 email이 있는 사람은 민수(minsu@lab.kr)와 지아(jia@lab.kr)다. 존재·타입 제약은 Neo4j Enterprise Edition 기능이고, 유일성 제약은 Community Edition에서도 쓸 수 있다.

04 / RECALL & PRACTICE

이번에는 직접 풀어 보세요

정답을 보기 전에 계산과 이유를 적어 보세요. 해설과 비교하고 확인 표시를 남기면 완료할 수 있습니다.

문제 1

Paper 노드의 doi는 반드시 있고 서로 겹치지 않아야 하며, year는 정수여야 합니다. 필요한 제약 문장을 쓰세요.

힌트 보기

존재와 유일성을 한 번에 요구하는 제약이 있습니다.

풀이와 비교하기

CREATE CONSTRAINT paper_doi FOR (p:Paper) REQUIRE (p.doi) IS NODE KEY와 CREATE CONSTRAINT paper_year FOR (p:Paper) REQUIRE p.year IS :: INTEGER입니다. 키 제약 대신 IS UNIQUE와 IS NOT NULL 두 제약을 써도 같은 효과입니다. 키·존재·타입 제약은 Neo4j Enterprise 기능이고, Community에서는 유일성 제약만 걸 수 있습니다.

내 풀이를 해설과 비교하고 다른 점을 확인했어요.

풀이와 확인 표시는 이 브라우저에 저장됩니다.

이 자료는 개념 학습용입니다. 실제 데이터베이스·라이브러리·플랫폼의 동작과 설정은 제품과 버전마다 다를 수 있습니다.

스키마와 제약