[Database] 5. 관계 데이터 모델
이번 포스트에서는 관계 데이터 모델에 대해 정리하겠습니다.
관계 데이터 모델의 개념
[ 관계 데이터 모델의 개념과 기본 용어 ]
관계 데이터 모델 -> 개념적 구조를 논리적 구조로 표현하는 논리적 데이터 모델 중 하나다. 하나의 개체에 대한 데이터를 릴레이션 하나에 담아 데이터베이스에 저장한다.
- 릴레이션 -> 하나의 개체에 관한 데이터를 2차원 테이블의 구조로 저장한 것.
- 속성(Attribute) -> 릴레이션의 열. ex) 고객아이디, 고객이름, 나이, 등급, 직업, 적립금이라는 속성
- 튜플(Tuple) -> 릴레이션의 행. ex) 위의 표에서 고객 개체의 4개에 대한 인스턴스
- 도메인 -> 하나의 속성이 가질 수 있는 값들의 집합. ex) 등급 속성의 값으로 vip, gold, silver, bronze 중 하나만 허용된다면, 네 가지 값을 모아놓은 것이 등급 속성의 도메인
- 널 -> 아직 모르거나 해당되는 사항이 없음을 표현하는 특별한 값
- 차수 -> 하나의 릴레이션에서 속성의 전체 개수 ex) 위의 표에서 (고객아이디, 고객이름, 나이, 등급, 직업, 적립금) 6개의 속성이 있으므로 6. 모든 릴레이션은 최소 1의 차수.
- 카디널리티 -> 하나의 릴레이션에서 튜플의 전체 개수. ex) 위의 표에서 4. 새로운 튜플이 생성되거나 삭제될 수 있으므로 자주 변한다는 동적인 특징.
[ 릴레이션과 데이터베이스의 구성 ]
관계 데이터 모델에서 릴레이션은 릴레이션 스키마와 릴레이션 인스턴스로 구성되어 있다.
- 릴레이션 스키마 -> 릴레이션의 이름과 릴레이션에 포함된 모든 속성의 이름으로 정의하는 릴레이션의 논리적 구조. 데이터베이스 관리 시스템이 내부적으로 데이터 정의어를 이용해 정의한다. 일반적으로 아래와 같은 형태로 표현한다. 릴레이션 내포(relation intension)라고도 부른다. 고객 릴레이션에서 릴레이션 스키마는 고객(고객아이디, 고객이름, 나이, 등급, 직업, 적립금)이다.
- 릴레이션 인스턴스 -> 어느 한 시점에 릴레이션에 존재하는 튜플들의 집합. 데이터베이스 관리 시스템이 내부적으로는 데이터 조작어를 이용해 릴레이션 인스턴스의 튜플을 검색하거나, 새로운 튜플 삽입과 기존 튜플 삭제 및 수정을 수행한다. 릴레이션 외연(relation extension)이라고도 부른다.
- 데이터베이스 스키마 -> 데이터베이스를 구성하는 릴레이션 스키마의 모음.
- 데이터베이스 인스턴스 -> 데이터베이스를 구성하는 모든 릴레이션 인스턴스의 모음.
[ 릴레이션의 특성 ]
관계 데이터 모델의 릴레이션에는 네 가지 중요한 특성이 있다. 기본적으로 이 네 가지 특성을 만족해야 테이블이 릴레이션으로 인정받을 수 있다. 4가지 특성을 하나씩 살펴보자.
- 튜플의 유일성 -> 하나의 릴레이션에는 동일한 튜플이 존재할 수 없다.
하나의 릴레이션에는 똑같은 튜플이 있으면 안 되고, 모든 튜플에는 다른 튜플과 구별되는 유일한 특성이 있어야 한다. 릴레이션을 튜플의 모임인 집합의 개념으로 이해한다면, 하나의 집합에 동일한 원소가 존재할 수 없다는 특성과 연관 지어 생각할 수 있다.
-> 튜플이 유일한지 구별하기 위해 선정하는 속성을 키(key)라고 한다.
- 튜플의 무순서 -> 하나의 릴레이션에서 튜플 사이의 순서는 무의미하다.
위 그림의 고객 릴레이션에서는 김현준 고객 튜플이 정소화 고객 튜플보다 먼저 표현되어 있지만 두 튜플의 순서가 바뀌어도 상관없다. 다시 말해, 튜플 순서가 바뀐다고 다른 릴레이션이 될 수 없고, 순서와 상관없이 튜플 내용이 같아야 같은 릴레이션이다.
- 속성의 무순서 -> 하나의 릴레이션에서 속성 사이의 순서는 무의미하다.
위 그림의 고객 릴레이션에는 고객아이디 속성이 등급 속성보다 먼저 표현되어 있지만 두 속성의 순서가 바뀌어도 상관없다. 다시 말해 속성은 순서가 바뀌어도 다른 릴레이션이 될 수 없고, 순서와 상관없이 같은 속성들로 구성되어 있어야 같은 릴레이션이다.
- 속성의 원자성 -> 속성 값으로 원자 값만 사용할 수 있다.
모든 속성 값은 더는 분해할 수 없는 하나의 값, 즉 원자 값만 가질 수 있다. 다시 말해 하나의 속성은 여러 개의 값. 즉 다중 값을 가질 수 없다.
[ 키 ]
- 키(key)는 릴레이션에서 튜플들을 구별하는 역할을 하는 속성 또는 속성들의 집합.
튜플을 유일하게 구별하기 위해 모든 속성을 이용하는것 보다 일부 속성만 이용하는 것이 효율성을 높일 수 있다. 릴레이션에 포함된 튜플들을 유일하게 구별해주는 역할은 속성 또는 속성들의 집합인 키가 담당한다. 키(key)는 관계 데이터 모델에서 중요한 제약조건을 정의한다. 또한 튜플을 처리하는 데 중요한 역할을 하므로 키의 개념을 정확히 이해할 필요가 있다.
[ 슈퍼키 ]
- 슈퍼키는 유일성의 특성을 만족하는 속성 또는 속성들의 집합이다.
유일성(uniqueness)은 키가 갖추어야 하는 기본 특성으로, 하나의 릴레이션에서 키로 지정된 속성 값은 튜플마다 달라야 한다는 의미다. 즉, 키 값이 같은 튜플은 존재할 수 없다.
위의 고객 릴레이션에서 고객아이디는 고객 튜플마다 값이 다르므로 슈퍼키가 될 수 있다. 그러나 나이, 등급, 직업, 적립금 속성은 값이 같을 수 있으므로 유일성을 만족시키지 못해 슈퍼키가 될 수 없다.
또한, (고객아이디, 고객이름) 속성 집합은 모든 튜플을 구별할 수 있으므로 슈퍼키가 될 수 있다. 즉, 고객아이디를 포함하는 속성 집합은 모두 슈퍼키가 될 수 있다.
-> 불필요한 속성 값까지 확인해야하는 비효율적인 작업이 요구되는데, 꼭 필요한 속성 집합만으로 튜플을 유일하게 구별할 수 있도록 하는 키가 바로 후보키이다.
[ 후보키 ]
- 후보키는 유일성과 최소성을 만족하는 속성 또는 속성들의 집합이다.
최소성(minimality)은 꼭 필요한 최소한의 속성들로만 키를 구성하는 특성이다. 그러므로 하나의 속성으로 구성된 키는 당연히 최소성을 만족한다.
위의 고객 릴레이션에서 고객아이디 속성은 단독으로 고객 튜플을 유일하게 구별할 수 있으므로 후보키가 될 수 있다. 하지만 (고객아이디, 고객이름)은 후보키가 될 수 있다. 고객아이디 속성만으로 유일성을 만족시킬 수 있기 때문이다.
[ 기본키 ]
- 기본키(primary key)는 데이터베이스 설계자나 관리자는 여러 후보키 중에서 기본적으로 사용할 키를 반드시 선택한 키다.
릴레이션에서 튜플을 구별하기 위해 여러 개의 후보키를 모두 사용할 필요는 없다. 만약 후보키가 1개만 존재하면 당연히 해당 후보키를 기본키로 선택해야 하겠지만 여러 개일 경우에는 데이터베이스 사용 환경을 고려하여 적합한 것을 기본키로 선택하면 된다.
아래 그림에서 고객 릴레이션에서는 고객아이디 속성만 후보키이기 때문에 자연스럽게 고객아이디 속성이 기본키가 되며, 기본키는 속성 이름에 밑줄을 그어 표현한다.
[ 기본키 선택 기준 ]
- 널 값을 가질 수 있는 속성이 포함된 후보키는 기본키로 부적합하다.
기본키는 튜플을 식별할 뿐만 아니라 릴레이션에서 원하는 튜플을 찾기 위한 기본 접근 방법을 제공하므로 매우 중요하다. 따라서 기본키가 널 값인 튜플은 다른 튜플들과 구별하여 접근하기 어려우므로 이런 가능성이 있는 키는 기본키로 선택하지 않는 것이 좋다.
- 값이 자주 변경될 수 있는 속성이 포함된 후보키는 기본키로 부적합하다.
기본키는 다른 튜플과 구별되는 값을 가지고 널 값은 허용하지 않으므로 이를 확인하는 작업이 필요하다. 그런데 값이 자주 변경되는 속성으로 구성된 후보키를 기본키로 선택하면 속성 값이 바뀔 때마다 기본키 값으로 적합한지 여부를 판단해야 하므로 번거롭다. 그러므로 값이 자주 변경되지 않는 속성으로 구성된 후보키를 기본키로 선택하는 것이 좋다.
- 단순한 후보키를 기본키로 선택한다.
단순한 후보키는 자릿수가 작은 정수나 단순 문자열인 속성으로 구성되거나, 구성하는 속성의 개수가 적은 후보키다. 데이터베이스를 이용하는 일반 사용자뿐 아니라 데이터베이스를 실제로 처리하는 컴퓨터 시스템도 단순 값 처리를 선호한다.
기본키 선정 과정은 대학에서 학생회장을 선발하는 과정과 유사하다. 대학에 다니는 학생들(슈퍼키) 중에서 학생회장이 될 만한 자격을 갖춘 후보 학생(후보키)을 추천한 다음, 지지를 가장 많이 받은 한 명의 학생(기본키)을 학생회장으로 임명하는 과정으로 이해하면 쉽다.
[ 대체키 ]
- 대체키는 기본키로 선택되지 못한 후보키들이다.
이름에서 알 수 있듯이 대체키는 기본키를 대신할 수 있지만 기본키가 되지 못하고 탈락한 이유가 있을 수 있다. 기본키를 선택할 때 고려할 사항을 하나씩 따져보면 고객 릴레이션은 고객아이디 속성을 기본키로 선택하는 것이 무난하다. 따라서 기본키로 선택되지 못한 (고객이름, 주소) 속성 집합이 대체키가 된다.
아래 그림은 하나의 릴레이션에서 볼 수 있는 슈퍼키, 후보키, 기본키, 대체키의 관계를 그림으로 표현한 것이다.
[ 외래키 ]
- 외래키는 어떤 릴레이션에 소속된 속성 또는 속성 집합이 다른 릴레이션의 기본키가 되는 키다.
다시 말해 다른 릴레이션의 기본키를 그대로 참조하는 속성의 집합이 외래키다. 외래키는 릴레이션들 사이의 관계를 올바르게 표현하기 위해 필요하다.
외래키의 개념과 필요성을 파악하기 위해 인터넷 쇼핑몰을 위한 데이터베이스에서 고객 릴레이션과 주문 릴레이션의 관계를 생각해보자. 고객 릴레이션과 주문 릴레이션의 스키마는 아래와 같다.
고객 릴레이션은 속성이 6개이고, 고객아이디 속성이 기본키다. 주문 릴레이션은 속성이 6개이고, 주문번호 속성이 기본키다. 여기서 주문 릴레이션의 주문고객 속성이 고객 릴레이션의 기본키인 고객아이디 속성을 참조하면 주문고객 속성을 외래키라고 한다. 외래키를 통해 고객 릴레이션과 주문 릴레이션이 관계를 맺어, 주문 릴레이션의 튜플과 연관성 있는 고객 릴레이션의 튜플을 연관시킬 수 있다. 일반적으로 주문 릴레이션과 같이 외래키를 가진 릴레이션을 '참조하는 릴레이션'이라 하고, 고객 릴레이션과 같이 기본키를 가진 릴레이션을 '참조되는 릴레이션'이라 한다.
[ 외래키 사용시 주의점 ]
- 외래키 속성의 도메인가 참조되는 기본키 속성의 도메인은 같아야 한다.
위 그림의 주문고객과 고객아이디에서 알 수 있듯이 외래키의 속성과 기본키의 속성의 이름이 달라도 된다. 하지만, 외래키 속성인 주문고객의 도메인과 참조되는 기본키인 고객아이디 속성의 도메인은 비교 연산이 가능하게 하기 위해 반드시 같아야 한다.
- 참조되는 릴레이션의 기본키가 아닌 다른 속성을 외래키로 참조하면 안된다.
기본키가 아닌 다른 속성을 외래키가 참조한다면, 튜플을 유일하게 구별하기 어렵기 때문에 참조되는 릴레이션에서 관련 있는 튜플을 검색하지 못할 수 있다.
ex ) 예를 들면, 위의 주문 릴레이션이 고객 릴레이션의 기본키가 아닌 고객이름, 나이, 등급, 직업, 적립금 속성 중 하나를 외래키로 참조한다고 가정해보면, 이 경우 속성 값이 같은 튜플이 많아 연관성 있는 유일한 튜플을 정확히 검색하기 어려워진다. 그러므로 외래키는 반드시 다른 릴레이션의 기본키를 참조해야 하며 외래키의 도메인은 참조되는 기본키와 같게 정의되어야 한다.
- 참조하는 릴레이션과 참조되는 릴레이션이 같을 수도 있다.
외래키가 다른 릴레이션의 기본키를 참조하는 키라고 정의했지만 반드시 다른 릴레이션을 참조할 필요는 없다. 참조하는 릴레이션과 참조되는 릴레이션이 같을 수도 있다. 즉, 외래키 자신이 속한 릴레이션의 기본키를 참조하도록 외래키를 정의할 수도 있다.
위 그림의 고객 릴레이션은 고객아이디 속성이 기본키다. 그리고 추천고객 속성은 추천한 고객의 아이디를 의미하므로 같은 릴레이션의 고객아이디, 즉 기본키를 참조하는 외래키다. 이처럼 고객 릴레이션은 기본키와 외래키가 하나의 릴레이션에서 표현되며, 이것은 고객 릴레이션이 자신과 관계를 맺고 있음을 의미한다.
- 외래키는 기본키를 참조하지만 기본키가 아니기 때문에 널(null) 값을 가질 수 있다.
외래키는 기본키를 참조하지만 기본키와 다른 특징이 있다. 위 그림의 고객 릴레이션에서 정지영 고객은 다른 고객의 추천을 받지 않고 가입하였기 때문에 다른 고객 튜플과 달리 추천고객 속성의 값이 널(null)이다. 이처럼 외래키는 기본키를 참조하지만 기본키가 아니기 때문에 널 값을 가질 수 있다. 이 또한 외래키가 기본키가 아니기 때문에 서로 다른 튜플이 같은 값을 가질 수 있는 것이다. 외래키에는 중요한 제약조건이 존재하는데, 이는 다음 포스트에서 자세히 다룰 예정이다.
관계 데이터 모델의 제약
[ 무결성 제약 조건 ]
- 무결성 제약 조건(integrity constraint)은 데이터를 정확하고 유효하게 유지하는 무결성을 보장해야 된다는 규칙이다.
무결성은 데이터에 결함이 없는 상태. 즉 데이터가 정확하고 유효하게 유지된 상태를 말한다. 무결성 제약조건의 주요 목적은 데이터베이스에 저장된 데이터의 무결성을 보장하고, 데이터베이스의 상태를 일관되게 유지하는 것이다. 그래서 이를 위해 필요한 세부 규칙도 정의하고 있다. 무결성 제약조건은 어느 시점에 데이터베이스에 저장된 데이터를 의미하는 데이터베이스 상태 또는 데이터베이스 인스턴스가 항상 지켜야 하는 중요한 규칙이라고 할 수 있다. 데이터베이스가 삽입, 삭제, 수정 연산으로 상태가 변하더라도 무결성 제약조건은 반드시 지켜져야 한다.
관계 데이터 모델이 기본으로 포함하고 있는 무결성 제약조건에는 개체 무결성 제약조건과 참조 무결성 제약조건이 있다. 데이터베이스의 상태를 일관성 있게 유지하기 위해서는 두 가지를 모두 만족시켜야 한다.
[ 개체 무결성 제약조건 ]
- 개체 무결성 제약조건(entity integrity constraint)은 기본키를 구성하는 모든 속성은 널 값을 가지면 안 된다는 규칙이다.
-> 즉, 기본키는 항상 유일하고 비어있을 수 없는 값이어야 한다.
관계 데이터 모델에서는 릴레이션에 포함된 튜플들을 유일하게 구별해주고 각 튜플에 쉽게 접근할 수 있도록 릴레이션마다 기본키를 정의한다. 그런데 기본키를 구성하는 속성 전체나 일부가 널 값이 되면 튜플의 유일성을 판단할 수 없어 기본키의 본래 목적을 상실하게 된다.
예를 들어, 아래의 고객 릴레이션에서는 정소화와 정지영 고객 튜플에서 기본키인 고객아이디 속성의 값이 널이다. 널 값은 아직 결정되지 않았거나 모르는 값을 의미하기 때문에, 이 경우에는 정소화 고객과 정지영 고객의 아이디가 다른 고객의 아이디와 다른지를 판단하기 어렵다. 또한 둘 다 고객아이디 속성의 값이 널이지만 두 고객의 아이디가 같다고 판단할 수도 없다. 따라서 하나의 릴레이션에는 동일한 튜플이 존재할 수 없다는 릴레이션 고유의 특성을 만족시킨다고 장담할 수 없어, 이 고객 릴레이션은 개체 무결성 제약조건을 위반한 예가 된다. 그러므로 아래와 같은 상태의 릴레이션은 실제로 존재할 수 없다.
개체 무결성 제약조건을 만족시키려면 새로운 튜플이 삽입되는 연산과 기존 튜플의 기본키 속성 값이 변경되는 연산이 발생할 때 기본키에 널 값이 포함되는 상황에서는 연산의 수행을 거부하면 된다. 이것은 일반 사용자가 직접 수행하기보다는 데이터베이스 관리 시스템이 자동으로 수행하므로 새로운 릴레이션을 생성할 때마다 기본키를 어떤 속성들로 구성할 것인지 데이터베이스 관리 시스템에 알려주면 된다.
[ 참조 무결성 제약조건 ]
- 참조 무결성 제약조건((referential integrity constraint)은 외래키는 참조할수 없는 값을 가질수 없다는 규칙이다.
-> 즉, 외래키 값은 NULL이거나 참조하는 릴레이션의 기본키 값과 동일해야 한다.
외래키는 다른 릴레이션의 기본키를 참조하는 속성이고 릴레이션 간의 관계를 표현하는 역할을 한다. 그런데 외래키가 자신을 참조하는 릴레이션의 기본키와 상관이 없는 값을 가지게 되면 두 릴레이션을 연관시킬 수 없으므로 외래키 본래의 의미가 없어진다. 그러므로 외래키는 자신이 참조하는 릴레이션에 기본키 값으로 존재하는 값, 즉 참조 가능한 값만 가져야 한다.
아래 그림에서 주문 릴레이션의 주문고객 속성은 고객 릴레이션의 기본키인 고객아이디 속성을 참조하는 외래키다. 참조 무결성 제약조건을 만족하려면 주문고객 속성 값이 현재 고객 릴레이션에 존재하는 고객아이디 속성 값 중 하나여야 하지만, 주문번호가 1001인 cherry라는 주문고객의 속성 값은 현재의 고객 릴레이션에 존재하지 않는 고객아이디이다. 즉, 존재하지 않는 고객이 주문했다는 의미가 되므로 이것은 현실 세계를 올바르게 반영한 것이 아니다. 그러므로 이 고객 릴레이션과 주문 릴레이션은 참조 무결성 제약조건을 위반한 예시가 된다.
아래 그림의 주문 릴레이션에서는 주문번호가 1003인 주문고객이 누구인지 몰라 널 값으로 처리했다. 그렇다면 이렇게 외래키가 널 값인 경우는 무조건 참조 무결성 제약조건을 위반했다고 판단해야 할까? 그렇지 않다. 주문고객 속성 값이 널이라는 것은 주문한 고객이 누구인지 모를 뿐, 고객 릴레이션에 존재하지 않는 고객이 주문한 것으로 판단하기 어렵기 때문이다. 그러므로 참조 무결성 제약조건을 만족시키려면 외래키가 참조 가능한 값만 가져야 하지만, 널 값을 가진다고 해서 참조 무결성 제약조건을 위반한 것으로 판단해서는 안 된다.
데이터베이스의 상태가 변해도 참조 무결성 제약조건을 만족시켜야 한다. 데이터베이스의 상태가 변하더라도 참조 무결성 제약조건을 만족시키는 몇 가지 유형을 위 그림의 고객 릴레이션과 주문 릴레이션 예시로 살펴보자.
위 [그림 5-13] 의 고객 릴레이션에 새로운 고객 튜플을 삽입하는 것은 참조 무결성 제약조건을 위반하는 작업이 아니다. 다만, 개체 무결성 제약조건을 위반하지 않도록 고객 릴레이션에 고객아이디 속성 값을 삽입해야 된다. 반면, 주문 릴레이션에 새로운 주문 튜플을 삽입할 때는 참조 무결성 제약조건을 위반하지 않는지 확인해야 한다. 즉, 고객 릴레이션의 기본키인 고객아이디 속성 값으로 존재하지 않는 값은 주문고객 속성 값으로 지정하지 않아야 한다. 만약 고객아이디 속성 값으로 존재하지 않는 것이 주문고객 속성 값으로 선택되면 주문 릴레이션에 새로운 튜플을 삽입하는 연산의 수행을 거부하면 된다. ex) 예를 들어 주문 릴레이션에(1004, cherry, 초코과자, 20, 700, 2022-01-12) 튜플을 삽입하는 연산은 고객 릴레이션에 고객아이디가 cherry인 고객이 존재하지 않아 수행을 거부당한다.
위 [그림 5-13]의 고객 릴레이션에 존재하는 튜플을 삭제하는 연산은 참조 무결성 제약조건을 위반하지 않는 경우에만 수행한다. ex) 예를 들어 주문 릴레이션에는 주문고객이 apple인 고객이 주문한 튜플이 존재하는데도 고객 릴레이션에서 고객아이디가 apple인 고객 튜플을 삭제하면 존재하지 않는 고객이 주문한 내역이 되어 부정확한 데이터가 된다. 이처럼 연관된 튜플이 주문 릴레이션에 남아 있으면, 고객 릴레이션에서 해당 고객의 튜퓰을 삭제하는 연산을 수행하지 않거나 주문 릴레이션의 관련 튜플을 함께 삭제하여 참조 무결성 제약조건을 만족시켜야 한다. 그리고 주문고객의 속성 값을 널이나 기본 값으로 지정하는 방법도 사용할 수 있다. 반면, 주문 릴레이션에 존재하는 튜플을 삭제하는 것은 어떠한 제약조건도 위반하지 않는다.
위 [그림 5-13]의 고객 릴레이션에 존재하는 튜플에서 기본키가 아닌 속성의 값을 변경하는 연산은 어떠한 제약조건도 위반하지 않는다. 하지만 기본키인 고객아이디 속성의 값은, 주문 릴레이션에 원래의 속성 값과 연관된 튜플이 남아 있으면 변경 연산을 수행하지 않거나, 주문 릴레이션에 남아 있는 관련 튜플에서 주문고객 속성의 값을 새로운 값으로 함께 변경해야 참조 무결성 제약조건을 만족한다. ex) 예를 들어 고객 릴레이션에서 김현준 고객의 아이디를 grape로 변경한다면 기본키의 값을 변경하는 경우에 해당한다. 그리고 주문 릴레이션의 튜플 중 외래키가 아닌 속성의 값을 변경하는 연산은 어떠한 제약조건도 위반하지 않는다. 하지만 외래키인 주문고객 속성의 값을 변경하고자 할 때는 반드시 존재하는 고객아이디 속성 값으로 변경하고 이외의 값은 허용하지 않아야 참조 무결성 제약조건을 만족시킨다.
데이터베이스 상태가 빈번하게 변경되는 경우 참조 무결성 제약조건을 계속 만족시키기가 쉽지 않다. 하지만 다행히도 이러한 작업은 데이터베이스 관리 시스템이 자동으로 수행한다. 사용자는 새로운 릴레이션을 생성할 때마다 어떤 속성들이 외래키이고 어떤 릴레이션의 기본키를 참조하면 되는지 데이터베이스 관리 시스템에 알려주면 된다. 그리고 참조 무결성 제약조건을 위반하게 되는 경우에 원하는 처리 방법도 알려주면 된다.
References
데이터베이스 개론, 김연희(2022)