[Database] 개념적 설계

📕 목차

1. 데이터베이스 설계 과정
2. 개체-관계(ER) 모델의 개념
3. ERD의 다양한 표현 방법
4. 고차원 관계
5. 예제 UNIVERSITY 데이터베이스

---

1. 데이터베이스 설계 과정

 

📌 과정

1. 요구 사항 분석
2. 개념적 설계 (DBMS 종속 전)
3. 논리적 설계 (DBMS 종속)
4. 물리적 설계 (DBMS 종속)

 

📌 개념적 설계

• 특정 체계의 정보 요구사항을 구성하는 개체와 관계, 그리고 속성들을 파악하는 과정
• ER(Entity Relationship) Diagram : 파악한 정보를 도형화/명세화한 것
• 필요성
  • 데이터 독립성 제공을 위한 안정된 자료 구조 창출
  • 특정 DBMS, H/W, S/W에 독립적
  • 특정 DBMS에 적합한 데이터 모델로 변환하기 용이하다. (이전하기도 좋다.)
  • ER Model과 관련 명세서를 통한 산출물로 이해도 증진

 

📌 논리적 설계

• 개념적 스키마 (ER 모델) → DBMS 논리적 스키마로 변환
  • 개념적 설계: 스키마의 표현력과 완전성을 추구
  • 논리적 설계: 논리적 모델이 제공하는 자료 구조와 제약사항을 효율적으로 이용\
• 논리적 설계 접근 방향
  1. ER Diagram을 그린다
  2. 단순한 ER Diagram으로 변환한다.
  3. DBMS의 논리적 모델로 변형

 

📌 물리적 설계

• 논리적 스키마 → 효율적인 물리적 데이터 베이스로 구성
• 구조
  • 저장 레코드 형식
  • 저장 순서
  • 접근 경로
  • 물리적 저장 장치의 할당 등
• 참고 사항
  • 물리적 DB 구조는 세부적인 성능에 영향을 준다.
  • 물리적 설계 단계에서 고려할 사항들 대부분은 특정 DBMS에 의해 해결된다.
  • DBA만이 물리적 DB 구조의 구성에 관여할 수 잇다.

 

📌 예제

아래부터는 다음 예제를 활용하여 설명을 한다.

• 회사의 사원, 부서, 프로젝트를 관리하는 DB
• 회사는 여러 개의 부서(department)로 구성
  • 각 부서는 이름과 번호, 그리고 한 명의 부서장을 가진다.
  • 부서장이 취임한 날짜를 저장해야 한다.
  • 각 부서는 여러 개의 지점들을 갖는다.
• 각 부서는 여러 개의 프로젝트(project)를 수행
  • 프로젝트마다 이름, 번호, 그리고 위치를 하나씩 갖는다.
• 사원(employee)의 이름, 주민번호, 주소, 연봉, 성별, 생일 정보를 유지
  • 각 사원은 한 부서에 근무, 여러 개의 프로젝트에 참여
  • 사원이 각 프로젝트에서 수행한 주당 업무 시간을 저장한다.
  • 각 사원의 직속 상관도 유지해야 한다.
• 사원마다 여러 명의 부양가족(dependent)이 존재한다.
  • 각 부양가족에 대해 이름, 성별, 생일, 사원과의 관계 등을 저장한다.

 

---

2. 개체-관계(ER) 모델의 개념

 

• Entities and Attributes
• Entity Types, Value Sets, and Key Attributes
• Relationships and Relationship Types
• Weak Entity Types
• COMPANY Schema에 대한 ERD

 

📌 Entities and Attributes

• Entity: DB에서 표현해야 하는 핵심적인 사물 혹은 개념
• Attribute: Entity를 표현하기 위해 사용하는 속성
  • 특정 개체는 각 속성에 대해 값을 가질 수 있다.
  • 값이 없는 속성도 있을 수 있다. (NULL 속성)
• 각 속성은 value set (또는 data type, domain)을 갖는다.

 

🟡 속성의 분류

• 단순/복합 속성
  • 단순 속성: 더 이상의 작은 요소로 분할할 수 없는 값 (ex. 주민번호, 성별)
  • 복합 속성: 몇 개의 더 작은 속성들로 분할 가능한 속성
  • 다만, ER 모델은 최대한 충실하게 현실을 반영하는 것이 초점을 둔다. 복합키를 반영할 지는 논리적 설계 단계에서 고려한다.
• 단일 값/다중 값 속성
  • 단일 값 속성: 하나의 값만 가질 경우
  • 다중 값 속성: 여러 개의 값을 가질 경우 (ex. 취미)
  • 복합-다중 값 속성의 혼합도 가능 (ex. 학생의 이전 학위(대학, 연도, 학위명, 분야))
• NULL 속성
  • 값이 입력되지 않은 속성
• 유도 속성
  • 다른 속성의 값을 이용하여 유도할 수 있는 속성 (ex. 나이는 주민등록번호나 생일로 유도 가능한 정보)
  • 유도 속성을 이용하여 계산량을 줄일 수 있다.

 

📌 Entity Types, Value Sets, and Key Attributes

🟡 Entity Types

• Entity: 실제 사례(ex. 홍길동, 김철수), 하나하나가 개체에 해당
• Entity Type: Entity를 공통점으로 Grouping한 결과 (일반적으로 Entity를 칭하면 이걸 말한다.)
  • 이름과 속성 리스트를 갖는다. (schema)
  • 예를 들어, 여러 회사원의 공통점을 묶어 Employee(Name, Age, Salary)로 표현할 수 있다.
• Entity Set: 결과(개체)의 집합

 

🟡 Key Attribute

• Entity set에 포함된 특정 개체를 식별하는 속성들의 집합
  • 유일성(Uniqueness)과 최소성(Minimality)을 만족해야 한다.
• 슈퍼 키(Super Key)
  • 유일성을 만족하는 속성들의 집합
  • 군더더기 속성들이 포함된 경우 최소성을 만족하지 못함 (있다고 해서 유일성이 성립되지 않는 것은 아니다.)

 

🟡 후보 키/주키

• 후보 키 (Candidate Key)
  • 유일성 + 최소성을 만족하는 군더더기 없는 슈퍼 키
  • 중계 테이블처럼 여러 속성의 합이 후보키가 될 수도 있다. (오히려 하나를 빼면 유일성 만족 불가)
• 주 키 (Primary Key)
  • 후보 키 중 하나를 선택
  • 선택 기준은 개체의 용도에 따라 결정 (보통 가장 많이 사용될 것으로 예상되는 후보 키 선택)
  • 모든 개체는 반드시 주 키를 갖는 것은 아니다. (반례: weak entity)

 

🟡 Value Set (Domain) of Attribute

• 각 속성이 가질 수 있는 값의 집합을 표현 (제약 조건)
  • ex. 이름 → 10자 이내의 문자열
  • ex. 생일 → MM-DD-YYYY 형태의 값
• Domain Constraint
  • Domain을 만족하는 속성 값만 데이터베이스에 저장되도록 할 것
  • Entity type E의 속성 A의 domain이 V라고 가정하면, A: E → P(V) (단, P(V)는 V의 Power set)

 

🟡 Entity Type 그리기

 

✒️ 예제에 대한 기초 데이터베이스 설계

 

• 회사는 여러 개의 부서(department)로 구성
  • 각 부서는 이름과 번호, 그리고 한 명의 부서장을 가진다.
  • 부서장이 취임한 날짜를 저장해야 한다.
  • 각 부서는 여러 개의 지점들을 갖는다.

• 각 부서는 여러 개의 프로젝트(project)를 수행
  • 프로젝트마다 이름, 번호, 그리고 위치를 하나씩 갖는다.

• 사원(employee)의 이름, 주민번호, 주소, 연봉, 성별, 생일 정보를 유지
  • 각 사원은 한 부서에 근무, 여러 개의 프로젝트에 참여
  • 사원이 각 프로젝트에서 수행한 주당 업무 시간을 저장한다.
  • 각 사원의 직속 상관도 유지해야 한다.

• 사원마다 여러 명의 부양가족(dependent)이 존재한다.
  • 각 부양가족에 대해 이름, 성별, 생일, 사원과의 관계 등을 저장한다.

 

📌 Relationships and Relationship Types

• Relationship
  • 둘 이상의 서로 다른 Entity들을 연결
  • ex. "A" 사원이 "X" 프로젝트에 참여
• Relationship Type
  • 동일한 타입의 관계들을 묶는 개념
  • ex. Employee와 Project entity 사이의 "Works_on" 관계
  • 차수(degree): 관계에 참여하는 entity의 수 (대부분 이진 관계)

 

🟡 이진 관계 제약 조건

• Cardinality Ratios(최대 참여 수 조건)
  • 각 entity가 특정 relationship에 참여하는 최대 수
  • 일대일, 일대다, 다대일, 다대다 관계
• Participation Constraint(최소 참여 수 조건)
  • 각 entity가 relationship에 참여하는 최소 수(관계에 참여 안 하는 경우가 존재하는가?)
  • Total participation: 모든 entity가 관계에 참여해야 하는 경우
  • Partial participation: entity set 중 일부 entity는 관계에 참여하지 않을 경우

 

 

🟡 Relationship의 속성 

• Relationship도 속성을 가질 수 있다. (보통 이 경우는 중계 테이블로 쓸 때)
• cardinality ratio에 따른 고려 사항
  1. 일대일이나 일대다 관계에서는 entity에 속성 이동이 가능
     • [사원] - <근무> - [부서]에서 근무 연수 속성은 n쪽의 entity(사원)으로 이동 가능
  2. 다대다 관계의 경우에는 relationship에 속성을 포함한다.
     • [학생] - <수강> - [과목]에서 성적 속성은 수강 관계에 포함

이건 직접 DB 모델링 안 하면 이해하기 어려운 내용.

 

🟡 ERD에서 관계 표현

• Cardinality: 숫자(1 또는 N)로 표시
• Participation: 겹선 = total, 홑선 = partial
• (min, max) 표시로 (partial, cardi)를 동시에 표현할 수도 있다.

 

안 쓸 거 같은데, 의외로 자주 나오는 관계

• Recursive Relationship Type
  • 동일한 entity간의 관계를 표시할 때 사용한다.
  • ex. 사원들 간의 상하 관계, 카테고리 간의 부모-자식 관계 등

 

📌 Weak Entity Types

• 키 속성이 없는 entity ↔ Strong entity
  • 외부 entity의 key를 가져와서 식별한다.
    1. ex. Dependent(이름, 성별, 생일) : 구분자는 있지만, 식별자는 없다.
    2. ex. Employee의 id + Dependent의 이름 이름을 key로 갖는 경우
  • Owner (Identifying) entity type : Weak entity set의 특정 개체를 식별하기 위한 키를 제공하는 entity type (위의 예제에선 Employee가 해당)
• Identifying relationship: Weak entity와 Owner entity를 연결하는 관계 (<<>>로 표시)
• Discriminator(구별자)
  • 동일한 owner entity에 관련된 weak entity들을 식별할 때 사용하는 속성
  • partial key라고도 부른다.
  • weak entity e의 key는 owner e의 key + 구별자

 

📌 COMPANY Schema에 대한 ERD

• 앞서 명시했던 entity 사이의 6개의 relation을 추가한 모습

 

✒️ (min, max) 표기법으로 표현한 경우

 

 이렇게도 할 수는 있다는데, 개인적으로 너무 헷갈린다. (교수님 말씀으론 책마다 정의가 다르다고 하기도 하고)

 

📌 ER 모델링 고려 사항

• 일반적으로 개체-명사, 관계-동사, 속성-개체를 수식하는 추가 명사로 표현한다.
• 개념적 설계란 초기 스키마를 반복해서 개선해나가는 과정

 

---

3. ERD의 다양한 표현 방법

 

💡 무엇을 사용하던지 상관은 없지만, 일관성을 준수해라

 

📌 Entity type, Attribute, Relationship의 표현

난 개인적으로 (i), (iii), (i)를 즐겨쓴다.

 

📌 Cardinality ratio 표현 ((min, max)와 비교)

 

📌 Attribute의 표현

 

📌 일반화/특수화의 표현 (EERD)

요건 바로 다음 파트에서 설명

 

---

4. 고차원 관계

 

• 3개 이상의 entity type에 대한 관계
  • n-ary relationship: n개의 entity type에 대한 관계
  • n-ary relationship ≠ n개의 binary relationship

이런 경우가 거의 없긴 한데, Supply라는 관계가 세 entity를 매핑하는 경우 발생한다.

다만, 단순히 3개의 entity가 관계를 맺고 있는 것과 하나의 관계에서 세 entity를 매핑하는 건 엄연히 다르다.

 

📌 고려 사항

(어떤 교수가 어떤 과목을 강의한다. 이 과목은 어느 학기에 개설되었다. 그 교수가 이 강의를 실제로 강의했다.)

=> 사실상 전부 다대다 관계. 다만 강의를 담당할 수 있는 교수가 하나밖에 없는 조건(일대다)이 성립하면, 굳이 삼진 관계를 별도로 유지할 이유가 없다.

• 특정 이진 관계가 고차원 관계로부터 유도될 수 있다면, 중복이므로 삭제할 수 있다.
  • 기존 이진 관계로 유추할 수 없는 관계에 대해, 삼진 관계를 정의해야 한다.

 

몇 가지 예제도 있었는데, 어차피 개인 정리용으로 올린 거니까 여기까지