ERD 특강정리

ERD(Entity-Relationship Diagram)

ERD는 개체(Entity), 개체 간의 관계(Relationship), 그리고 개체의 속성(Attribute)을 시각적으로 표현한 다이어그램이다. 

 

 

 

ERD의 필요성

1. 비즈니스 요구사항의 체계적 이해

• ERD를 작성하는 과정은 비즈니스 요구사항을 분석하고, 관리 대상이 되는 객체(개체)와 그들 사이의 관계를 명확히 파악 가능
• 애매모호한 부분을 줄여 비개발자(기획자, 의사결정권자)와 개발자 사이의 원활한 커뮤니케이션이 가능

2. 데이터 구조의 시각화

• 복잡한 데이터 구조를 직관적으로 이해 가능

3. 정규화와 무결성 확보

• ERD를 기반으로 데이터 정규화를 진행 - 데이터 중복과 이상 현상을 방지
• 각 개체 간 참조 무결성을 확보

4. 개발 및 유지보수 편의성 향상

• 실제 구현 시 테이블 구조를 확정하고, 외래 키(Foreign Key)와 인덱스(Index)를 설정할 때 참조할 근거
• 데이터베이스 구조를 체계적으로 관리하고 수정할 수 있어 유지보수와 확장성을 크게 개선

 

데이터 정규화(Data Normalization)란?

데이터 정규화는 데이터베이스 테이블을 설계할 때, 데이터를 중복 없이 체계적으로 분해하고 정리하는 과정이다. 이를 통해 데이터 구조를 단순화하고, 불필요한 중복을 제거하며, 논리적 안정성과 일관성을 확보할 수 있다.

 

• 중복 최소화 : 동일한 정보가 여러 테이블이나 칼럼에 중복되어 있으면, 하나의 데이터를 변경할 때마다 모든 중복되는 곳을 수정해야 하는 비효율이 발생한다. 정규화를 통해 이러한 중복을 줄일 수 있다. 
• 데이터 무결성 유지 : 정규화를 통해 데이터가 잘못되거나 불일치한 상태로 들어가는 것을 예방할 수 있다.
• 이상현상 최소화 : 정규화는 이상현상을 방지하거나 최소화하는 중요한 역할을 한다.

 

 

데이터 이상현상(Data Anomalies)란?

데이터 이상현상은 데이터베이스 설계가 비합리적으로 이루어져 있을때, 데이터 삽입(Insert), 수정(Update), 삭제(Delete) 과정에서 발생하는 비정상적이고 부정적인 결과를 의미한다. 

 

 

주요 이상현상

 

1. 삽입 이상(Insert Anomaly) : 새로운 데이터를 삽입하려 할 때, 다른 불필요한 데이터도 함께 삽입해야 하는 비효율적인 상황을 말한다. 예를 들어, 어떤 테이블이 과도하게 많은 정보를 담고 있어, 단순히 '새로운 과목'을 등록하기 위해 '학생 정보'까지 동시에 입력해야 하는 경우

 

2. 갱신 이상(Update Anomaly) : 동일한 정보가 여러 장소에 중복되어 있어, 한 곳의 데이터를 변경한 뒤 다른 곳도 모두 변경해야 하는 상황이다. 변경을 깜빡하고 한 곳만 수정하면 데이터 불일치가 발생한다.

 

3. 삭제 이상(Delete Anomaly) : 한 정보를 삭제할 때 의도치 않게 관련된 다른 정보도 함께 사라지는 상황이다. 예를 들어, 어떤 과목과 학생 정보가 한 테이블에 섞여 있고, 한 학생의 수강 기록을 삭제하려다 보니 그 학생에 대한 모든 정보가 사라져 버리는 문제가 발생할 수 있다. 

 

 

 

참조 무결성(Referential Integrity)이란? 

참조 무결성은 테이블 간의 관계를 맺는 외래키(Foreign Key)가 항상 유효한 값을 유지하도록 보장하는 데이터 무결성 규칙이다. 즉, 한 테이블에서 다른 테이블을 참조할 때(외래키 관계), 참조 대상이 유효한 레코드(행)를 반드시 가져야 한다는 것.

 

예시를들면, 주문(Order) 테이블이 고객(Customer) 테이블을 참조한다고 할 때, 주문 테이블의 Customer_ID 칼럼은 반드시 Customer 테이블에 존재하는 Customer_ID를 가리켜야 한다. 만약 Customer 테이블에서 Customer_ID=100인 고객이 삭제되었는데, Order 테이블에 Customer_ID=100인 주문 기록이 그대로 남아 있다면, 참조 무결성이 깨지게 된다. 

이를 방지하기 위해 외래키 제약 조건을 두어, 참조 대상이 삭제되거나 변경될 때 연쇄적으로 처리(ON DELETE CASCADE, ON UPDATE CASCADE)하거나, 참조 무결성을 위반하는 행위를 아예 막아버린다. 

 

 

 

ERD의 기본 구성 요소

 

1) 개체(Entity)

• 데이터베이스에서 독립적으로 관리할 가치가 있는 '대상'을 의미 OR 업무에 서 관리하고자 하는 실체
• 데이터베이스에서 테이블 단위로 표현
• 예를 들어, '고객', '주문', '상품' 등과 같이 실제로 존재하거나 관리 대상인 명사를 떠올리며 된다.

개체 판단 기준

• 독립적인 실체성(Existence) : 해당 대상이 업무나 비즈니스 로직 상 독립적으로 존재하며, 다른 대상 없이도 식별이 가능한가를 확인한다. 즉, 그 자체로 하나의 테이블(혹은 데이터 집합)로 관리할 가치가 있어야한다. 
• 고유한 식별자(Identifier) 보유 여부 : 해당 대상에 고유한 식별자(Primary Key)로 삼을 만한 속성이 있는지 확인한다. '고객'은 고객ID로, '상품'은 상품코드로, '과목'은 과목코드로 식별할 수 있어야한다.
• 속성(Attribute) 집합의 존재 : 대상에 여러 속성이 따르며, 이 속성들이 해당 대상을 상세히 표현하고 관리할 필요가 있는지를 살핀다. 만약 어떤 대상이 단 하나의 속성만 갖거나 별도의 특징을 관리할 필요가 없다면, 굳이 개체로 만들지 않고 상위개체의 속성으로 처리할 수 있다.
• 비즈니스 의미와 관리 필요성 : 해당 대상을 데이터베이스로 관리함으로써 얻을 수 있는 비즈니스 가치를 고려한다. 이 대상이 업무 상 중요한 정보를 담고 있거나, 다른 개체와의 관계를 통해 의미 있는 통계나 로직을 구축하는데 필수적이라면 개체로 삼을 가치가 있다. 
• 다른 개체와 관계성(Relationship) 판단 : 해당 대상이 다른 개체와의 관계(1:1, 1:N, M:N)를 형성하고 있어야 한다. 대체로 개체는 다른 개체와 관계를 맺음으로써 데이터베이스 설계 전체에서 의미를 갖게 된다. 반면 관계 없이 고립되고, 속성도 거의 없으며 관리 필요성도 없다면, 개체로 식별하기 어렵다. 

2) 속성(Attribute)

• 해당 개체가 갖는 특성이나 정보
• 데이터베이스에서 칼럼으로 표현
• 예로, '고객'개체는 '고객ID', '이름', '연락처', '주소'와 같은 속성을 가질 수 있다.
• 개체의 속성 중에는 특정 행을 유일하게 식별하거나, 개체 간의 관계를 형성하는 데 사용되는 키(Key) 개념이 중요(대표적으로, 기본키(Primary Key), 왜래키(Foreign Key))

키(Key)의 종류

 

1. 후보키(Candidate Key)

• 한 테이블에서 각 행을 유일하게 식별할 수 있는 속성(또는 속성의 집합)이다.
• 후보키는 중복 값이 없어야 하며(유일성), NULL 값을 가져서는 안된다.
• 하나의 테이블에는 여러 후보키가 존재할 수 있는데, 이 중 하나를 골라 주요 식별자로 사용한다.

2. 기본키(Primary Key)*

• 후보키 중에서 해당 테이블의 대표 식별자로 선택된 키이다.
• 기본키는 각 행을 고유하게 식별할 수 있으므로 유일해야 하고, NULL을 허용하지 않는다.
• ex: 고객(Customer) 테이블의 Customer_ID, 상품(Product)테이블의 Product_Code 등
• 기본키를 통해 데이터베이스 엔진은 특정 행을 식별, 검색, 업데이트, 삭제 등 다양한 연산을 효율적으로 수행한다.

3. 대체키(Alternate Key)

• 후보키 중 기본키로 선택되지 않은 나머지 후보키
• 대체키도 기본키와 마찬가지로 유일성과 무결성을 갖지만, 대표 식별자 역할은 기본키가 담당하므로 보조적인 식별자 역할을 한다.

4. 외래키(Foreign Key)*

• 한 테이블의 칼럼이 다른 테이블의 기본키(또는 후보키)를 참조하는 경우, 이 칼럼을 외래키라고 한다.
• 외래키는 두 테이블 간의 관계(Relationship)를 표현하며, 참조 무결성(Referential Integrity)을 보장한다.
• ex: 주문(Order) 테이블에서 Customer_ID 컬럼이 고객(Customer)테이블의 Customer_ID를 참조한다면, 주문 테이블의 Customer_ID는 고객 테이블의 기본키를 참조하는 외래키가 된다. 

5. 복합키(Composite Key)

• 두 개 이상의 속성을 합쳐서 하나의 키로 사용하는 경우를 복합키라고 한다.
• 단일 속성으로는 유일하게 식별하기 어려울 때, 여러 속성을 조합하여 유일성을 확보한다.
• ex: 수강 기록(Enrollment) 테이블에서 (Student_ID, Course_ID, Semester_ID)를 모두 합쳐야 한 행을 유일하게 식별할 수 있다면, 이 세 속성을 합쳐 복합키를 구성할 수 있다. 

 

키를 설계할 때 고려사항

 

1. 유일성(Unique)

기본키나 후보키는 테이블 태에서 각 행을 고유하게 식별할 수 있어야 한다. 중복된 값이 없어야 하며, NULL을 허용하지 않는다.

 

2. 간결성(Simplicity)

가능한 한 키 컬럼은 단순한 속성을 사용하는 것이 좋다. 너무 많은 속성을 합쳐 복합키를 만들기보다는 ,단순한 기본키(ex: 숫자형 시리얼ID)를 사용하는 것이 향후 관리와 성능에 유리할 수 있다.

 

3. 변경 빈도 최소화(Minimal Variability)

키로 사용되는 속성은 자주 바뀌지 않는 것이 좋다. 식별자 역할을 하는 기본키가 자주 변경된다면, 관련된 외래키 관계를 가진 다른 테이블의 무결성에도 영향을 미치게 된다. 

 

4. 성능(Performance)

키는 인덱스를 통해 데이터 접근 속도에 영향을 미친다. 효율적인 키 선정은 데이터 조회, 정렬, 조인 등의 연산을 빠르게 할 수 있게 한다. 

 

 

3) 관계(Relationship)

• 두 개체 간의 연관성을 나타내며, 한 개체가 다른 개체에 어떻게 연결되는지 표현
• 예를 들어, '고객'과 '주문'간에는 '고객이 주문을 한다(Order)'는 관계가 형성 가능