데이터 모델링의 이해 (3)

• 앞선 글에서는 나오지 않았던 개념이나 헷갈리는 문제들을 토대로 정리하고 '데이터 모델링의 이해' 챕터를 마무리하고자 합니다.

 

데이터 모델링

✅ 데이터 모델링 시 유의점 3가지!

1. 중복: 중복은 데이터의 무결성을 저해하고 저장 공간의 낭비를 초래할 뿐만 아니라, 데이터 갱신 시 일관성 문제를 발생시킬 수 있습니다. 따라서, 데이터 모델링 과정에서는 같은 데이터를 사용하는 사람, 시간, 그리고 장소를 정확히 파악하여 중복성을 최소화해야 합니다.
2. 비유연성: 데이터 모델의 설계는 업무의 변화에 유연하게 대응할 수 있도록 해야 합니다. 비유연한 데이터 모델은 사소한 업무 변화에도 모델을 수시로 변경해야 하며, 이는 유지보수의 어려움을 가중시킵니다. 이를 방지하기 위해, 데이터의 정의를 데이터의 사용 프로세스와 분리하는 것이 중요합니다.
3. 비일관성: 데이터 모델링에서는 데이터 간의 상호 연관 관계를 명확하게 정의하여 데이터의 일관성을 보장해야 합니다. 중복이 없는 경우에도, 개발자가 연관된 데이터 간의 모순을 고려하지 않고 데이터를 임의로 수정할 때 비일관성 문제가 발생할 수 있습니다. 예를 들어, 신용 상태 갱신 없이 고객의 납부 이력 정보만 갱신하는 경우가 이에 해당합니다. 따라서, 사용자가 처리하는 프로세스 혹은 관련 프로그램과 테이블 간의 연계성을 무분별하게 높이는 것은 피해야 합니다.

 

엔티티

✅ 아래 시나리오에서 엔티티로 적절한 것은?

대학교에서 학생들의 수강 신청 시스템을 개발하고자 합니다. 이 시스템은 학생들이 매 학기마다 개설되는 강좌를 신청할 수 있게 해주며, 강좌마다 담당 교수와 수강 가능한 최대 인원이 정해져 있습니다. 학생들은 학번과 이름, 학과 정보를 가지고 있으며, 각 강좌는 고유한 강좌 코드, 강좌 이름, 학점 수를 포함합니다. 교수님들은 교수 번호와 이름, 전공을 가지고 있습니다.

• 학생: 학생들은 학번, 이름, 학과 정보를 가집니다. 이는 수강 신청 시스템에서 관리되어야 하는 주요 대상입니다.
• 강좌: 강좌는 강좌 코드, 강좌 이름, 학점 수를 가지며, 학생들이 신청할 수 있는 수업의 단위입니다.
• 교수: 교수님들은 각각의 강좌를 담당하며, 교수 번호와 이름, 전공 정보를 가집니다.

 

속성

✅ 속성의 명칭 부여 방법 4가지!

1. 해당 업무에서 사용하는 이름 부여: 업무에서 이미 사용하고 있는 용어를 속성명으로 사용하면, 데이터 모델을 이해하고 사용하는 사람들에게 직관적으로 이해될 수 있습니다.
2. 서술식 속성명은 피하기: 속성명은 간결하고 명확해야 하며, 서술식이나 문장 형태는 피해야 합니다.
3. 약어 사용 피하기: 가능한 한 약어를 사용하지 않고, 전체 단어를 명시하여 속성명을 부여합니다. 이는 모호함을 줄이고, 모델의 가독성을 높이는 데 도움이 됩니다.
4. 전체 데이터 모델 내 유일성 확보: 각 속성명은 전체 데이터 모델 내에서 유일해야 합니다. 동일한 속성명이 여러 엔티티에 사용되지 않도록 주의합니다.

 

관계

✅ 연관 관계와 의존 관계

• 연관관계(Association Relationship): 두 클래스(엔티티)가 서로를 알고 있고, 상호 작용을 할 수 있는 관계를 나타냅니다. 연관관계는 두 클래스가 장기간에 걸쳐 서로에게 영향을 미치며, 이 관계는 클래스 다이어그램에서 선으로 표시됩니다. 예를 들어, '학생' 클래스와 '학교' 클래스 사이에는 학생이 학교에 속해 있다는 연관관계가 있을 수 있습니다.
• 의존관계(Dependency Relationship): 한 클래스(엔티티)의 변경이 다른 클래스에 영향을 미칠 수 있는, 보다 약한 형태의 관계입니다. 의존관계는 일반적으로 한 클래스가 다른 클래스의 메소드를 호출하거나 데이터를 사용할 때 발생합니다. 클래스 다이어그램에서는 점선 화살표로 표시되며, 한 클래스가 다른 클래스 없이는 기능을 수행할 수 없음을 나타냅니다. 예를 들어, '주문 처리' 클래스가 '고객 정보' 클래스의 데이터를 필요로 하는 경우, 이 두 클래스 사이에는 의존관계가 있습니다.

 

✅ 존재 관계와 행위 관계의 사례

1. 존재 관계

'도서'와 '도서관': 각 '도서'는 특정 '도서관'에 속해 있어야만 합니다. 이 관계는 '도서'가 '도서관' 없이는 존재할 수 없음을 나타냅니다.
'계정'과 '사용자': '계정' 엔티티는 '사용자' 엔티티에 의존적입니다. 즉, 각 '계정'은 특정 '사용자'에게 할당되어 있으며, '사용자' 없이 '계정'은 의미가 없습니다.
'자녀'와 '부모': 가족 관계 모델링에서 '자녀' 엔티티는 하나 이상의 '부모' 엔티티와 존재 관계를 맺습니다.

 

2. 행위 관계

'고객'과 '주문': '고객'이 '주문'을 생성하는 행위는 '고객'과 '주문' 사이의 행위 관계를 형성합니다. 이 관계는 '고객'의 행동에 의해 '주문'이 존재하게 됨을 나타냅니다.
'프로그래머'와 '버그 리포트': '프로그래머'가 '버그 리포트'를 해결하는 행위는 이 두 엔티티 사이의 행위 관계를 형성합니다. '버그 리포트'는 '프로그래머'의 행위에 따라 상태가 변경됩니다.
'의사'와 '진료 기록': '의사'가 환자의 '진료 기록'을 작성하는 행위는 '의사'와 '진료 기록' 사이의 행위 관계를 형성합니다.

 

✅ 두 엔티티 사이 관계에 대해 확인해야 할 사항 4가지!

1. 두 개의 엔티티 사이에 관심 있는 연관 규칙이 존재하는가?
2. 두 개의 엔티티 사이에 정보의 조합이 발생하는가?
3. 업무기술서, 장표에 관계 연결에 대한 규칙이 서술되어 있는가?
4. 업무기술서, 장표에 관계 연결을 가능하게 하는 동사가 있는가?

 

식별자

✅ 아래 '대출 기록' 엔티티의 특성에 해당하지 않는 것은?

• '대출 기록' 엔티티는 '대출 번호'를 주식별자로 사용하지만, 이는 '도서 ID'와 함께 복합식별자를 형성할 수 있기 때문에, '대출 기록' 엔티티에 대해 '단일식별자'라는 용어는 부정확할 수 있습니다. '대출 기록' 엔티티의 주식별자는 '대출 번호' 하나만을 의미하는 것이 아니라, '도서 ID'를 포함하여 대출된 특정 복사본을 유일하게 식별할 수 있어야 합니다.