2025-08-16 01:49

Tags:

📚 SQL 참조(Reference)의 모든 것: 데이터베이스 관계의 완전한 핸드북 가이드

📌 들어가며

데이터베이스에서 **참조(Reference)**라는 개념은 테이블 간의 관계를 정의하고 데이터 무결성을 보장하는 핵심 메커니즘입니다. 마치 도서관에서 책을 찾기 위해 도서 목록을 참조하듯이, SQL 데이터베이스에서는 한 테이블의 데이터가 다른 테이블의 특정 데이터를 참조함으로써 논리적인 연결고리를 만들어냅니다.¹²

SQL에서 참조는 주로 외래 키(Foreign Key) 제약조건을 통해 구현되며, 이는 데이터베이스 설계의 기초가 되는 관계형 모델의 핵심 원리입니다. 이 핸드북은 SQL 참조의 모든 측면을 체계적으로 다루어, 초보자부터 고급 개발자까지 실무에서 바로 활용할 수 있는 실용적인 지식을 제공합니다.

SQL 외래 키 관계를 보여주는 전자상거래 데이터베이스 구조도

🎯 SQL 참조가 만들어진 이유와 배경

데이터 무결성의 필요성

SQL 참조 시스템은 관계형 데이터베이스의 아버지로 불리는 Edgar F. Codd의 관계형 모델에서 출발했습니다. 1970년대 IBM에서 개발된 이 개념은 다음과 같은 핵심 문제들을 해결하기 위해 만들어졌습니다:³

1. 데이터 중복성 문제

기존의 파일 기반 시스템에서는 같은 정보가 여러 곳에 저장되어 일관성을 유지하기 어려웠습니다. 예를 들어, 고객 정보가 주문 테이블과 배송 테이블에 각각 저장되면, 고객이 주소를 변경했을 때 모든 곳을 업데이트해야 했죠.⁴

2. 고아 레코드(Orphan Records) 방지

참조 무결성이 없다면 존재하지 않는 고객에 대한 주문이나 삭제된 부서에 속한 직원 같은 논리적으로 불가능한 데이터가 생성될 수 있습니다.⁵⁶

3. 데이터 일관성 보장

비즈니스 규칙을 데이터베이스 레벨에서 강제함으로써 애플리케이션 로직의 복잡성을 줄이고, 다양한 애플리케이션이 같은 데이터베이스를 사용해도 일관성을 유지할 수 있게 했습니다.⁷⁸

실제 업무에서의 필요성

현실 세계의 비즈니스는 관계로 이루어져 있습니다. 고객은 주문을 하고, 직원은 부서에 소속되며, 제품은 카테고리에 분류됩니다. 이러한 관계를 데이터베이스에 정확히 반영하고 유지하기 위해 참조 시스템이 필수적이었습니다.⁹¹⁰

🏗️ SQL 참조의 핵심 구조와 개념

외래 키(Foreign Key)의 정의

외래 키는 한 테이블의 컬럼이 다른 테이블의 기본 키를 참조하는 제약조건입니다. 이는 두 테이블 사이에 논리적 연결을 만들고, 데이터의 참조 무결성을 보장합니다.²¹¹

 
-- 기본 구조 예시
 
CREATE TABLE customers (
 
customer_id INT PRIMARY KEY,
 
name VARCHAR(50),
 
email VARCHAR(100)
 
);
 
  
 
CREATE TABLE orders (
 
order_id INT PRIMARY KEY,
 
customer_id INT,
 
order_date DATE,
 
FOREIGN KEY (customer_id) REFERENCES customers(customer_id)
 
);
 

참조 무결성(Referential Integrity)의 원리

참조 무결성은 외래 키 값이 유효한 기본 키 값을 참조하거나 NULL이어야 한다는 규칙입니다. 이는 다음 두 가지 조건을 만족해야 합니다:³⁴

1. 존재하는 값 참조: 외래 키 값은 반드시 부모 테이블의 기본 키에 존재하는 값이어야 합니다

2. NULL 허용: 외래 키 컬럼이 NULL을 허용한다면, NULL 값을 가질 수 있습니다

부모-자식 테이블 관계

SQL 참조에서는 **부모 테이블(Parent Table)**과 **자식 테이블(Child Table)**의 개념이 중요합니다:²¹²

• 부모 테이블: 기본 키를 제공하는 테이블 (예: customers)

• 자식 테이블: 외래 키를 포함하는 테이블 (예: orders)

📋 SQL 참조의 다양한 유형과 사용법

1. 일대다 관계 (One-to-Many)

가장 일반적인 관계로, 한 부모 레코드가 여러 자식 레코드와 연결됩니다.¹³¹⁴

 
-- 부서-직원 관계 예시
 
CREATE TABLE departments (
 
dept_id INT PRIMARY KEY,
 
dept_name VARCHAR(50)
 
);
 
  
 
CREATE TABLE employees (
 
emp_id INT PRIMARY KEY,
 
emp_name VARCHAR(50),
 
dept_id INT,
 
FOREIGN KEY (dept_id) REFERENCES departments(dept_id)
 
);
 

실무 활용 예시:

• 고객 ↔ 주문 관계

• 카테고리 ↔ 제품 관계

• 부서 ↔ 직원 관계

2. 일대일 관계 (One-to-One)

각 부모 레코드가 정확히 하나의 자식 레코드와 연결되는 관계입니다.¹⁵

 
-- 직원-여권 관계 예시
 
CREATE TABLE employees (
 
emp_id INT PRIMARY KEY,
 
emp_name VARCHAR(50)
 
);
 
  
 
CREATE TABLE passports (
 
passport_id INT PRIMARY KEY,
 
emp_id INT UNIQUE NOT NULL,
 
passport_number VARCHAR(20),
 
FOREIGN KEY (emp_id) REFERENCES employees(emp_id)
 
);
 

주의사항: 일대일 관계에서는 외래 키에 UNIQUE 제약조건을 추가해야 합니다.¹⁵

3. 다대다 관계 (Many-to-Many)

**연결 테이블(Junction Table)**을 통해 구현되는 복합 관계입니다.¹³¹⁶

 
-- 학생-과목 관계 예시
 
CREATE TABLE students (
 
student_id INT PRIMARY KEY,
 
student_name VARCHAR(50)
 
);
 
  
 
CREATE TABLE subjects (
 
subject_id INT PRIMARY KEY,
 
subject_name VARCHAR(50)
 
);
 
  
 
-- 연결 테이블
 
CREATE TABLE enrollments (
 
student_id INT,
 
subject_id INT,
 
enrollment_date DATE,
 
grade CHAR(2),
 
PRIMARY KEY (student_id, subject_id),
 
FOREIGN KEY (student_id) REFERENCES students(student_id),
 
FOREIGN KEY (subject_id) REFERENCES subjects(subject_id)
 
);
 

4. 자기참조 관계 (Self-Referencing)

같은 테이블 내에서 레코드들이 서로를 참조하는 관계입니다.¹⁷¹⁸¹⁹

 
-- 직원-관리자 관계 예시
 
CREATE TABLE employees (
 
emp_id INT PRIMARY KEY,
 
emp_name VARCHAR(50),
 
manager_id INT,
 
FOREIGN KEY (manager_id) REFERENCES employees(emp_id)
 
);
 

활용 사례:

• 조직도에서 상하급 관계

• 게시판의 댓글-대댓글 구조

• 카테고리의 상위-하위 분류

⚙️ 참조 동작 옵션과 활용법

SQL에서는 부모 테이블의 데이터가 변경되거나 삭제될 때 자식 테이블에서 어떤 동작을 수행할지 정의할 수 있습니다.⁷⁸¹²

CASCADE 옵션

부모 레코드의 변경/삭제가 자식 레코드에 자동으로 전파됩니다.⁸²⁰

 
CREATE TABLE orders (
 
order_id INT PRIMARY KEY,
 
customer_id INT,
 
order_date DATE,
 
FOREIGN KEY (customer_id) REFERENCES customers(customer_id)
 
ON DELETE CASCADE
 
ON UPDATE CASCADE
 
);
 

장점:

• 관련 데이터가 자동으로 동기화됨

• 고아 레코드 발생 방지

주의사항:

• 의도하지 않은 대량 삭제 위험

• 복구가 어려움

SET NULL 옵션

부모 레코드가 삭제되면 자식 테이블의 외래 키 값을 NULL로 설정합니다.⁸²⁰

 
CREATE TABLE orders (
 
order_id INT PRIMARY KEY,
 
customer_id INT,
 
order_date DATE,
 
FOREIGN KEY (customer_id) REFERENCES customers(customer_id)
 
ON DELETE SET NULL
 
);
 

활용 시나리오:

• 담당자가 퇴사해도 프로젝트 기록은 유지하고 싶은 경우

• 카테고리가 삭제되어도 제품은 보관하고 싶은 경우

RESTRICT/NO ACTION 옵션

자식 레코드가 존재하면 부모 레코드의 삭제/수정을 거부합니다.⁷¹²

 
CREATE TABLE orders (
 
order_id INT PRIMARY KEY,
 
customer_id INT,
 
order_date DATE,
 
FOREIGN KEY (customer_id) REFERENCES customers(customer_id)
 
ON DELETE RESTRICT
 
);
 

장점:

• 실수로 인한 데이터 손실 방지

• 명시적인 데이터 정리 과정 강제

🔧 실무에서의 SQL 참조 활용법

JOIN 연산과의 연계

외래 키는 JOIN 연산의 기초가 됩니다.²¹²²²³

 
-- INNER JOIN 예시
 
SELECT
 
c.customer_name,
 
o.order_date,
 
o.total_amount
 
FROM customers c
 
INNER JOIN orders o ON c.customer_id = o.customer_id
 
WHERE o.order_date >= '2025-01-01';
 
  
 
-- LEFT JOIN으로 모든 고객 조회 (주문이 없는 고객 포함)
 
SELECT
 
c.customer_name,
 
COUNT(o.order_id) as order_count
 
FROM customers c
 
LEFT JOIN orders o ON c.customer_id = o.customer_id
 
GROUP BY c.customer_id, c.customer_name;
 

복합 외래 키

여러 컬럼을 조합한 외래 키도 가능합니다.⁶

 
CREATE TABLE order_details (
 
order_id INT,
 
product_id INT,
 
line_number INT,
 
quantity INT,
 
price DECIMAL(10,2),
 
PRIMARY KEY (order_id, line_number),
 
FOREIGN KEY (order_id, product_id)
 
REFERENCES order_products(order_id, product_id)
 
);
 

인덱스 최적화

외래 키 컬럼에는 자동으로 인덱스가 생성되는 경우가 많지만, 성능 최적화를 위해 명시적으로 관리하는 것이 좋습니다.¹²²⁴

 
-- 외래 키 성능 최적화를 위한 인덱스
 
CREATE INDEX idx_orders_customer_id ON orders(customer_id);
 
CREATE INDEX idx_order_items_product_id ON order_items(product_id);
 

📏 참조와 데이터베이스 정규화

SQL 참조는 데이터베이스 정규화와 밀접한 관련이 있습니다.²⁵²⁶²⁷

제1정규형 (1NF)

각 컬럼이 원자값을 가지고 기본 키가 존재해야 합니다.²⁵²⁶

위반 사례:

 
-- 잘못된 예시 (1NF 위반)
 
CREATE TABLE orders_bad (
 
order_id INT,
 
customer_name VARCHAR(50),
 
product_names TEXT -- 여러 제품명이 하나의 컬럼에 저장
 
);
 

올바른 예시:

 
-- 1NF 준수
 
CREATE TABLE orders (
 
order_id INT PRIMARY KEY,
 
customer_id INT,
 
FOREIGN KEY (customer_id) REFERENCES customers(customer_id)
 
);
 
  
 
CREATE TABLE order_items (
 
order_id INT,
 
product_id INT,
 
quantity INT,
 
PRIMARY KEY (order_id, product_id),
 
FOREIGN KEY (order_id) REFERENCES orders(order_id),
 
FOREIGN KEY (product_id) REFERENCES products(product_id)
 
);
 

제2정규형 (2NF)

모든 비키 속성이 기본 키 전체에 완전 함수적 종속되어야 합니다.²⁵²⁶²⁷

제3정규형 (3NF)

비키 속성이 다른 비키 속성에 종속되지 않아야 합니다.²⁷²⁸

🎨 참조 명명 규칙과 모범 사례

일관된 명명 규칙

가독성과 유지보수성을 위해 일관된 명명 규칙을 따르는 것이 중요합니다.^24293031

 
-- 권장 명명 규칙
 
-- 기본 키: pk_테이블명
 
-- 외래 키: fk_테이블명_참조테이블명
 
-- 인덱스: idx_테이블명_컬럼명
 
  
 
CREATE TABLE customers (
 
customer_id INT,
 
customer_name VARCHAR(50),
 
email VARCHAR(100),
 
CONSTRAINT pk_customers PRIMARY KEY (customer_id)
 
);
 
  
 
CREATE TABLE orders (
 
order_id INT,
 
customer_id INT,
 
order_date DATE,
 
CONSTRAINT pk_orders PRIMARY KEY (order_id),
 
CONSTRAINT fk_orders_customers
 
FOREIGN KEY (customer_id) REFERENCES customers(customer_id)
 
);
 

제약조건 명명 모범 사례

체계적인 제약조건 명명으로 디버깅과 유지보수를 쉽게 만들 수 있습니다:³¹³²³³

• 기본 키: pk_테이블명

• 외래 키: fk_자식테이블_부모테이블

• 고유 제약: uq_테이블명_컬럼명

• 체크 제약: ck_테이블명_컬럼명

🚨 실무에서 주의해야 할 참조 관련 이슈들

순환 참조 문제

테이블들이 서로를 참조하는 순환 구조는 피해야 합니다.

 
-- 문제가 있는 설계
 
CREATE TABLE employees (
 
emp_id INT PRIMARY KEY,
 
dept_id INT,
 
FOREIGN KEY (dept_id) REFERENCES departments(dept_id)
 
);
 
  
 
CREATE TABLE departments (
 
dept_id INT PRIMARY KEY,
 
manager_id INT,
 
FOREIGN KEY (manager_id) REFERENCES employees(emp_id) -- 순환 참조!
 
);
 

해결책:

 
-- 개선된 설계
 
CREATE TABLE departments (
 
dept_id INT PRIMARY KEY,
 
dept_name VARCHAR(50)
 
);
 
  
 
CREATE TABLE employees (
 
emp_id INT PRIMARY KEY,
 
emp_name VARCHAR(50),
 
dept_id INT,
 
manager_id INT,
 
FOREIGN KEY (dept_id) REFERENCES departments(dept_id),
 
FOREIGN KEY (manager_id) REFERENCES employees(emp_id) -- 자기참조로 해결
 
);
 

성능 고려사항

대용량 데이터에서 외래 키 제약조건은 성능에 영향을 줄 수 있습니다:¹²³⁴

1. INSERT/UPDATE 성능: 참조 무결성 검사로 인한 오버헤드

2. DELETE 성능: CASCADE 옵션 사용 시 연쇄 삭제 처리

3. 인덱스 관리: 외래 키 컬럼의 적절한 인덱싱 필요

데이터 마이그레이션 시 주의사항

기존 데이터가 있는 테이블에 외래 키를 추가할 때는 신중해야 합니다:

 
-- 기존 데이터 정합성 검사 후 제약조건 추가
 
-- 1단계: 문제 데이터 확인
 
SELECT o.order_id, o.customer_id
 
FROM orders o
 
LEFT JOIN customers c ON o.customer_id = c.customer_id
 
WHERE c.customer_id IS NULL;
 
  
 
-- 2단계: 문제 데이터 정리 후 제약조건 추가
 
ALTER TABLE orders
 
ADD CONSTRAINT fk_orders_customers
 
FOREIGN KEY (customer_id) REFERENCES customers(customer_id);
 

🔍 고급 참조 기법과 실전 활용

조건부 참조

특정 조건을 만족하는 경우에만 참조를 허용하는 고급 기법입니다.

 
-- 활성화된 고객만 참조 허용하는 CHECK 제약조건
 
CREATE TABLE orders (
 
order_id INT PRIMARY KEY,
 
customer_id INT,
 
order_date DATE,
 
FOREIGN KEY (customer_id) REFERENCES customers(customer_id),
 
CONSTRAINT ck_active_customer
 
CHECK (customer_id IN (
 
SELECT customer_id FROM customers WHERE status = 'ACTIVE'
 
))
 
);
 

다중 데이터베이스 간 참조

서로 다른 데이터베이스 간의 참조는 일반적으로 제약조건으로 강제할 수 없으므로 애플리케이션 레벨에서 관리해야 합니다.

 
-- 애플리케이션에서 관리해야 하는 교차 데이터베이스 참조
 
-- order_db.orders 테이블
 
CREATE TABLE orders (
 
order_id INT PRIMARY KEY,
 
customer_id INT, -- customer_db.customers를 참조하지만 FK 제약조건 불가
 
order_date DATE
 
);
 

소프트 참조와 하드 참조

소프트 참조: 제약조건 없이 논리적으로만 연결

하드 참조: 외래 키 제약조건으로 물리적 연결 강제

 
-- 소프트 참조 (유연하지만 무결성 보장 안됨)
 
CREATE TABLE logs (
 
log_id INT PRIMARY KEY,
 
user_id INT, -- users 테이블 참조하지만 FK 제약조건 없음
 
action_type VARCHAR(50),
 
created_at TIMESTAMP
 
);
 
  
 
-- 하드 참조 (무결성 보장하지만 제약이 있음)
 
CREATE TABLE orders (
 
order_id INT PRIMARY KEY,
 
customer_id INT,
 
order_date DATE,
 
FOREIGN KEY (customer_id) REFERENCES customers(customer_id)
 
);
 

📊 성능 최적화 전략

외래 키 인덱스 설계

외래 키 컬럼에 대한 효율적인 인덱스 전략이 중요합니다:¹²²⁴

 
-- 복합 인덱스로 성능 최적화
 
CREATE INDEX idx_orders_customer_date
 
ON orders(customer_id, order_date DESC);
 
  
 
-- 부분 인덱스 활용 (PostgreSQL 예시)
 
CREATE INDEX idx_active_orders
 
ON orders(customer_id)
 
WHERE status = 'ACTIVE';
 

통계 정보 관리

데이터베이스 옵티마이저를 위한 통계 정보를 최신 상태로 유지:

 
-- SQL Server 예시
 
UPDATE STATISTICS customers;
 
UPDATE STATISTICS orders;
 
  
 
-- MySQL 예시
 
ANALYZE TABLE customers;
 
ANALYZE TABLE orders;
 

🛠️ 참조 무결성 검증과 모니터링

참조 무결성 검사 쿼리

시스템의 참조 무결성 상태를 주기적으로 점검하는 것이 중요합니다:

 
-- 고아 레코드 찾기
 
SELECT 'orders' as table_name, COUNT(*) as orphan_count
 
FROM orders o
 
LEFT JOIN customers c ON o.customer_id = c.customer_id
 
WHERE c.customer_id IS NULL
 
  
 
UNION ALL
 
  
 
SELECT 'order_items' as table_name, COUNT(*) as orphan_count
 
FROM order_items oi
 
LEFT JOIN orders o ON oi.order_id = o.order_id
 
WHERE o.order_id IS NULL;
 

제약조건 상태 모니터링

 
-- SQL Server에서 비활성화된 제약조건 확인
 
SELECT
 
t.name AS table_name,
 
fk.name AS constraint_name,
 
fk.is_disabled
 
FROM sys.foreign_keys fk
 
INNER JOIN sys.tables t ON fk.parent_object_id = t.object_id
 
WHERE fk.is_disabled = 1;
 

📈 미래지향적 참조 설계

마이크로서비스 아키텍처에서의 참조

마이크로서비스 환경에서는 서비스 간 강한 결합을 피하기 위해 다른 접근 방식이 필요합니다:

1. 이벤트 기반 일관성: 데이터 변경을 이벤트로 전파

2. Saga 패턴: 분산 트랜잭션 관리

3. 최종 일관성: 강한 일관성 대신 최종적 일관성 수용

클라우드 환경에서의 고려사항

클라우드 데이터베이스에서는 추가적인 고려사항이 있습니다:

• 리전 간 복제: 외래 키 제약조건과 복제 정책의 충돌

• 자동 스케일링: 참조 무결성 검사의 성능 영향

• 백업/복구: 관련 테이블의 일관된 백업 보장

🎯 결론 및 핵심 포인트

SQL에서 참조는 단순히 테이블을 연결하는 기술이 아닌, 데이터의 품질과 신뢰성을 보장하는 핵심 메커니즘입니다. 현대의 복잡한 애플리케이션에서 데이터 무결성을 유지하려면 참조 설계에 대한 깊은 이해가 필수적입니다.

핵심 기억사항:

1. 참조는 데이터 무결성의 기초 - 외래 키 제약조건을 통해 논리적으로 불가능한 데이터 생성을 방지

2. 관계 유형의 정확한 파악 - 일대다, 일대일, 다대다, 자기참조 관계의 특성을 이해하고 적절히 구현

3. 참조 동작 옵션의 신중한 선택 - CASCADE, SET NULL, RESTRICT 등의 옵션이 비즈니스 요구사항에 맞는지 검토

4. 성능과 무결성의 균형 - 참조 무결성 보장과 성능 최적화 사이의 적절한 균형점 찾기

5. 일관된 명명 규칙 - 팀 협업과 유지보수성을 위한 체계적인 네이밍 컨벤션 적용

SQL 참조를 마스터하는 것은 견고하고 확장 가능한 데이터베이스 설계의 출발점입니다. 이 핸드북의 내용을 바탕으로 실무에서 만나는 다양한 데이터 관계를 효과적으로 설계하고 관리할 수 있을 것입니다. 데이터의 무결성은 곧 비즈니스의 신뢰성이며, SQL 참조는 그 신뢰성을 기술적으로 뒷받침하는 핵심 도구임을 기억하시기 바랍니다.

⁂

레퍼런스(References)

참조

Footnotes

1. https://learn.microsoft.com/en-us/sql/relational-databases/tables/create-foreign-key-relationships?view=sql-server-ver17 ↩

2. https://www.w3schools.com/sql/sql_foreignkey.asp ↩ ↩² ↩³

3. https://stackoverflow.com/questions/41906587/database-design-without-relations-with-relations-should-i-use-foreign-keys ↩ ↩²

4. https://cloud.google.com/spanner/docs/foreign-keys/how-to ↩ ↩²

5. https://www.geeksforgeeks.org/dbms/foreign-key-in-dbms/ ↩

6. https://www.ibm.com/docs/en/i/7.5.0?topic=constraints-referential ↩ ↩²

7. https://www.slainstitute.com/primary-key-and-foreign-in-sql/ ↩ ↩² ↩³

8. https://milvus.io/ai-quick-reference/how-do-foreign-keys-work-in-sql ↩ ↩² ↩³ ↩⁴

9. https://www.acceldata.io/blog/why-referential-integrity-constraints-are-vital-for-data-accuracy ↩

10. https://docs.oracle.com/cd/E05553_01/books/admintool/admintool_DataModeling4.html ↩

11. https://dev.mysql.com/doc/en/create-table-foreign-keys.html ↩

12. https://opentextbc.ca/dbdesign01/chapter/chapter-9-integrity-rules-and-constraints/ ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

13. https://dev.to/bshadmehr/mastering-table-relationships-in-relational-databases-the-role-of-primary-and-foreign-keys-1go9 ↩ ↩²

14. https://www.cockroachlabs.com/blog/what-is-a-foreign-key/ ↩

15. https://www.ibm.com/docs/en/db2/11.5.x?topic=constraints-foreign-key-referential ↩ ↩²

16. https://stackoverflow.com/questions/23771547/database-design-foreign-key-and-primary-key-relationships-across-3-tables ↩

17. https://strapi.io/blog/5-key-sql-relationship-types-to-improve-database-design ↩

18. https://learn.microsoft.com/en-us/sql/relational-databases/tables/primary-and-foreign-key-constraints?view=sql-server-ver17 ↩

19. https://www.reddit.com/r/SQL/comments/17bq4p2/primary_key_vs_foreign_key/ ↩

20. https://public.support.unisys.com/aseries/docs/ClearPath-MCP-20.0/82223819-004/section-000018865.html ↩ ↩²

21. https://www.geeksforgeeks.org/sql/relationships-in-sql-one-to-one-one-to-many-many-to-many/ ↩

22. https://www.reddit.com/r/SQL/comments/1e14nqr/many_to_many_one_to_many_many_to_one/ ↩

23. https://stackoverflow.com/questions/4601703/difference-between-one-to-many-and-many-to-one-relationship ↩

24. https://www.devart.com/dbforge/sql/studio/sql-relationships.html ↩ ↩² ↩³

25. https://www.metabase.com/learn/grow-your-data-skills/data-fundamentals/table-relationships ↩ ↩² ↩³

26. https://stackoverflow.com/questions/25878192/how-to-add-a-foreign-key-referring-to-itself-in-sql-server-2008 ↩ ↩² ↩³

27. https://www.geeksforgeeks.org/dbms/difference-between-on-delete-cascade-and-on-delete-set-null-in-dbms/ ↩ ↩² ↩³

28. https://codefinity.com/courses/v2/5ac24d9d-4a16-45b3-8856-07dec028c5e9/3d6c4ab0-f470-4b5d-ad0e-5f76d28ca0af/7992cacf-81b2-4169-b8e9-6d2e322daf07 ↩

29. https://www.dbvis.com/thetable/how-to-use-a-foreign-key-referring-to-the-source-table-in-postgres/ ↩

30. https://support.microsoft.com/en-us/office/guide-to-table-relationships-30446197-4fbe-457b-b992-2f6fb812b58f ↩

31. https://database.guide/understanding-self-referencing-foreign-keys-a-beginners-tutorial/ ↩ ↩²

32. https://stackoverflow.com/questions/5383612/setting-up-table-relations-what-do-cascade-set-null-and-restrict-do ↩

33. https://voiceofthedba.com/2023/11/06/creating-a-self-referencing-fk-in-a-create-statement-sqlnewblogger/ ↩

34. https://www.geeksforgeeks.org/sql/cascading-referential-integrity-constraints-in-sql-server-management-studio/ ↩