11.1 Entities, relationships, and attributes

The entity-relationship model

데이터베이스 설계 과정
데이터베이스 설계는 데이터베이스에 대한 구두 또는 문서화된 요구 사항에서 시작된다.
요구 사항은 엔터티-관계 모델(Entity-Relationship Model)로 형식화되며, 이후 SQL로 구현된다.

 

엔터티-관계 모델이란?

• 엔터티-관계 모델은 구현 세부 사항을 무시한 데이터 요구 사항의 하이 레벨 표현이다.
• 이 모델은 MySQL과 같은 특정 데이터베이스 시스템에서 구현을 안내한다.

엔터티-관계 모델의 구성 요소

1. 엔터티(Entity)
   • 사람, 장소, 제품, 개념, 또는 활동과 같은 객체를 나타낸다.
2. 관계(Relationship)
   • 두 엔터티 간의 관계를 나타내는 진술이다.
   • 일반적으로 두 개의 다른 엔터티 간의 관계를 나타내지만, 동일한 엔터티 간의 관계(반사 관계, Reflexive Relationship)도 가능하다.
3. 속성(Attribute)
   • 엔터티의 설명적 속성을 나타낸다.

1. 항공 예약 시스템에서 Passenger와 Booking은 엔터티이다.
2. Holds는 Passenger와 Booking 간의 관계이다.
3. PassengerNumber, PassengerName, BookingCode, BookingCost는 속성이다.
4. 인사 관리 시스템에서는 Employee-Manages-Employee(직원이 직원을 관리)는 반사 관계(Reflexive Relationship)이다.

모델이 SQL로 구현될 때, 엔터티(Entity)는 일반적으로 테이블이 된다.
관계(Relationship)와 속성(Attribute)는 각각 외래 키(Foreign Key)와 열(Column)이 되는 경우가 많다.
그러나 일부 관계와 속성은 테이블로 변환되기도 한다.
변환 과정이 간접적이기 때문에, 요구사항은 테이블, 키, 열이 아니라 엔터티, 관계, 속성으로 문서화된다.

속성(Attribute)은 엔터티-관계 모델과 관계형 모델 모두에서 사용되는 용어이다. 관계형 모델에서 속성(Attribute)은 열(Column)을 나타내는 공식 용어이다. 엔터티-관계 모델의 속성이 일반적으로 관계형 모델에서 열로 변환되기 때문에, 속성이라는 용어는 두 모델에서 유사한 의미를 가진다.

---

Entity-relationship diagram and glossary 엔터티-관계 다이어그램과 용어집

엔터티, 관계, 속성은 일반적으로 ER 다이어그램(Entity-Relationship Diagram)으로 나타낸다.

• 엔터티(Entity): 모서리가 둥근 직사각형으로 표시된다.
• 관계(Relationship): 엔터티를 연결하는 선으로 표시된다.
• 속성(Attribute): 엔터티 직사각형 내부에 나타난다.

ER 다이어그램은 항상 엔터티와 관계를 포함하며, 속성은 선택적이다.

• 추가적인 세부 정보가 필요할 때만 속성이 포함된다.

관계의 전체 이름

• 관계의 전체 이름은 관련된 엔터티를 포함하며, "Entity-Relationship-Entity" 형식으로 작성된다.
• 관계의 전체 이름은 관계의 중심을 기준으로 시계 방향으로 읽는다.
  • Ex: 아래 이미지에서 보여진 방식처럼 관계를 따라 시계 방향으로 읽으면 된다.

1. 이 항공 예약 시스템의 ER 다이어그램에는 엔터티(Entity)와 관계(Relationship)는 있지만 속성(Attribute)은 없다.
2. 관계의 전체 이름인 Passenger-Makes-Booking은 관계선 중심을 기준으로 시계 방향으로 읽는다.
3. 모든 관계는 시계 방향 규칙에 따라 읽는다.

용어집(Glossary)
용어집은 데이터 사전(Data Dictionary) 또는 저장소(Repository)라고도 불리며, 추가적인 세부 정보를 텍스트 형식으로 문서화한다.

• 용어집에는 엔터티(Entity), 관계(Relationship), 속성(Attribute)의 이름, 동의어(Synonym), 설명이 포함된다.

단순한 데이터베이스의 경우

• 사용자가 적은 간단한 데이터베이스에서는 데이터베이스 설계자가 텍스트 편집기를 사용하여 용어집을 기록할 수 있다.

복잡한 데이터베이스의 경우

• 더 복잡한 데이터베이스에서는 용어집을 위해 특별히 설계된 데이터베이스나 소프트웨어 도구를 사용하는 것이 일반적이다.

ER 다이어그램과 용어집의 상호보완성

• ER 다이어그램과 용어집은 상호보완적이며, 함께 엔터티-관계 모델(Entity-Relationship Model)을 완전히 설명한다.

---

Types and instances 

엔터티-관계 모델에서의 유형(Types)
유형은 집합(Set)을 나타낸다:

1. 엔터티 유형(Entity Type)
   • 특정 그룹의 객체를 나타낸다.
   • Ex: 회사의 모든 직원(All employees in a company).
2. 관계 유형(Relationship Type)
   • 연관된 객체의 집합을 나타낸다.
   • Ex: Employee-Manages-Department는 (직원, 부서) 쌍의 집합으로, 직원이 해당 부서를 관리한다는 관계를 나타낸다.
3. 속성 유형(Attribute Type)
   • 값의 집합을 나타낸다.
   • Ex: 모든 직원의 급여(All employee salaries).

• 엔터티, 관계, 속성 유형은 일반적으로 각각 테이블(Table), 외래 키(Foreign Key), 열(Column)로 변환된다.

엔터티-관계 모델에서의 인스턴스(Instances)
인스턴스는 집합의 요소(Element)를 나타낸다:

1. 엔터티 인스턴스(Entity Instance)
   • 특정한 객체를 나타낸다.
   • Ex: 직원 Sam Snead.
2. 관계 인스턴스(Relationship Instance)
   • 엔터티 인스턴스 간의 관계를 나타내는 서술이다.
   • Ex: "Maria Rodriguez가 Sales 부서를 관리한다."
3. 속성 인스턴스(Attribute Instance)
   • 개별적인 값을 나타낸다.
   • Ex: 급여 $35,000.

• 엔터티, 관계, 속성 인스턴스는 일반적으로 각각 행(Row), 외래 키 값(Foreign Key Value), 열 값(Column Value)로 변환된다.

Example types and instances

 

---

해당 용어와 예시를 알맞은 것끼리 짝지으시오.

entity type, attribute type, relationship type, entity instance, attribute instance, relationship instance

 

1. Students at San Antonio Community College

2. Eleanor Rigby, a student at San Antonio community college

3. Students take exams

4. Eleanor Rigby takes the final exam in calculus

5. Student record number

6. 324A21

1. entity type

2. entity instance

3. relationship type

4. relationship instance

5. attribute type

6. attribute instance

---

 

Database design

복잡한 데이터베이스는 세 단계로 개발된다:

1. 분석(Analysis)
   • 데이터 요구사항을 캡처하는 엔터티-관계 모델을 개발하며, 구현 세부 사항은 무시한다.
2. 논리적 설계(Logical Design)
   • 엔터티-관계 모델을 특정 데이터베이스 시스템에 맞게 테이블, 열, 키로 변환한다.
3. 물리적 설계(Physical Design)
   • 인덱스 추가 및 테이블이 저장 매체에 어떻게 조직되는지를 지정한다.

분석의 중요성

• 많은 사용자와 복잡한 요구사항을 가진 데이터베이스에서는 분석 단계가 특히 중요하다.
• 테이블과 사용자가 적은 소규모 데이터베이스에서는 분석 단계가 덜 중요하며 종종 생략된다.

분석과 논리적 설계 단계 요약

• 아래 표는 분석과 논리적 설계 단계를 요약한 것이다.
• 이 단계들은 순차적으로 제시되지만, 실제로는 항상 순차적으로 실행되지는 않는다.
  • 종종 이후 단계를 완료한 후 초기 단계로 다시 돌아가는 경우도 있다.

물리적 설계

• 물리적 설계는 데이터베이스 시스템마다 크게 다른 인덱스 및 테이블 구조에 따라 달라진다.
• 물리적 설계는 이 자료의 다른 부분에서 다룬다.

Table 11.1.2: Analysis steps

Table 11.1.3: Logical design steps

---

1) 분석 단계에서는 특정 데이터베이스 시스템과 관련된 구현 문제를 고려한다.

False

분석 단계에서는 특정 데이터베이스 시스템의 구현 세부 사항과 관계없이 데이터베이스 요구사항을 문서화한다.

2) 엔터티-관계 모델은 모든 데이터베이스 설계 프로젝트에서 개발된다.

False

엔터티-관계 모델은 분석 단계에서 개발된다.
사용자와 테이블이 적은 간단한 데이터베이스의 경우, 분석 단계가 생략되기도 한다.

3) 엔터티(Entity), 관계(Relationship), 속성(Attribute)은 항상 각각 테이블(Table), 외래 키(Foreign Key), 열(Column)로 직접 매핑된다.

False

논리적 설계 단계에서는 엔터티(Entity), 관계(Relationship), 속성(Attribute)이 일반적으로 테이블(Table), 외래 키(Foreign Key), 열(Column)로 변환된다.
그러나 경우에 따라 하나의 엔터티가 여러 테이블로 분리되거나, 여러 엔터티가 하나의 테이블로 병합되며, 관계와 속성이 테이블로 변환되기도 한다.