Week 8 - Database Design Using E-R Model

Design Phase

1. Initial Phase
   잠재적으로 해당 데이터베이스 사용자의 요구사항을 파악하는 단계
   ex : 도서관 데이터베이스 구축 → 사서,도서관 이용자 → 필요 데이터 : 책 관련 데이터

   1. 도서관에 있는 모든 책(제목, 저자, 장르, ISBN, 이용 가능 여부)을 추적합니다.
   2. 고객 정보(이름, 연락처, 도서관 카드 번호)를 관리합니다.
   3. 거래(도서 대출, 반납, 기한, 벌금)를 기록합니다.
      → 도서관 데이터에 시장 데이터가 필요없는 것처럼 필요한 데이터와 그에 대한 관계를 정립

2. Second Phase
   데이터 모델 선택 및 데이터 모델 개념 적용
   ex : 관계형 모델 개념을 적용하여 테이블과 관계를 정의하겠습니다:
   1.도서 테이블: 도서 정보를 포함합니다.
   2. 후원자 테이블: 후원자 정보를 포함합니다.
   3. 거래 테이블: 각 도서의 대출과 반납을 기록합니다.
   → 이러한 요구 사항을 데이터베이스의 개념적 스키마로 변환

3. 도서 테이블: BookID(PK), 제목, 저자, 장르, ISBN, IsAvailable

4. 후원자 테이블: 후원자ID(PK), 이름, 연락처, 라이브러리카드번호

5. 거래 테이블: 트랜잭션ID(PK), 도서ID(FK), 후원자ID(FK), 체크아웃 날짜, 반납 날짜, 기한 날짜, 벌금

6. Final Phase
   마지막 단계는 논리적 스키마를 정의한 다음 물리적 저장 및 검색 메커니즘을 구현하여 추상적인 설계를 실제 데이터베이스로 변환하는 것
   Logical Design : 개념 스키마를 기반으로 데이터베이스 스키마를 결정
   테이블,필드,데이터 유형, 제약 조건 및 테이블 간의 관게를 정의하는 작업
   데이터를 정규화하여 중복을 제거하고 데이터 무결성을 보장

   1. Business Decision : DB 에 어떤 속성을 기록해야하는지
   2. Computer Science Decision : relation schema : 관계 Schema 와 스키마에 대한 Attribute 를 어떻게 분배할지 결정
      필수 쿼리와 트랜잭션을 지원하는지 확인
      Physical Design : 데이터가 하드웨어에 저장되는 방식을 결정
      

Design Alternative

Database Schema 를 디자인하는데 있어서 2가지 주요 고려사항

1. 중복성 (Redundancy)
   잘못된 설계로 인해 정보가 반복되어 불일치가 발생

   [! note] 예시

   • 도서 테이블: BookID, 제목, 저자, 장르, ISBN, 서가 위치
   • 빌린 책 테이블: TransactionID, BookID, PatronID, CheckoutDate, ReturnDate, DueDate, Fine, Title, Author, Genre, ISBN, ShelfLocation

   이 디자인에서 BorrowedBooks 테이블은 Books 테이블에 이미 있는 책에 대한 정보(제목, 저자, 장르, ISBN, 서가 위치)를 중복으로 저장합니다. 예를 들어 책의 서가 위치가 변경되면 두 테이블 모두에서 업데이트해야 하므로 이러한 중복으로 인해 불일치가 발생할 수 있습니다.
2. 불완전성 (Incompleteness)
   잘못된 설계로 인해 기업의 특정 측면을 모델링하기 어렵거나 불가능하게 만들 수 있음

[!note] 예를 들어, 도서관에서 실제 책 외에 전자책을 제공하기 시작하면 초기 디자인이 이 새로운 유형의 미디어를 수용하지 못할 수 있습니다. ‘도서’ 테이블이 실물 도서용으로만 설계된 경우 디지털 형식이나 다운로드 링크와 같이 전자책과 관련된 필드가 누락될 수 있습니다.

보다 완벽한 디자인을 위해서는 보다 일반적인 `Items` 테이블을 만들고 유형 필드를 사용하거나 다른 항목 유형에 대해 별도의 테이블을 사용하는 것이 좋습니다:

Design Approaches

Entity Relationship Model

• A collection of entities and relationships
  • Entity : a Thing or Objects that is distinguishable from other objects
    • Described by a set of attributes
  • Relationship : An Association among several entities

ER model in Data Modeling

• 데이터베이스의 전체 논리 구조를 나타내는 스키마를 지정
• 데이터베이스 설계를 용이하게 하기 위해 개발

개념

Entity sets

• 데이터베이스 설계, 특히 ER 모델의 맥락에서 기본적인 개념
  Entity : An object that exists and is distinguishable from other objects

• represented by a set of attributes|
  
  An entity is represented by a set of attributes.
  
  A subset of the attributes form a primary ket of the entity set

• Representing Entity sets in ER Diagram
  
  Rectangles represent entity sets
  Attributes listed inside entity rectangle
  Underline indicates primary key attribute

Relationship sets

relationship type represents the association between entity types
→ collection of similar relationships among entities from one or more entity sets

Relationship sests in ER diagrams

For example

Relationship sets with Attributes

Roles

관계에서 수행하는 기능
관계 설정의 의미를 명확히 할 필요가 있을 때 유용하다
엔티티 : 사각형
관계 : 다이아몬드

Degree of a Relationship set

이진 관계는 두 개의 엔티티 집합을 포함
대부분의 relationship set 은 binary 이다
관계에 참여하는 두 개의 엔티티 집합 → 코스에 등록

Relationship between more than two entity sets are rare

Attributes

엔티티 유형을 정의하는 속성
properties which define the entity type
For example, Roll_No, Name, Age
attribute = oval (타원)

Key attribute

엔티티셋에서 uniquely identify 하는 속성
밑줄 친 타원으로 표현한다

Composite Attribute (복합 속성)

다른 여러 속성으로 구성된 속성
여러 타원에서 합쳐진 타원으로 구성

Multivalued Attribute (다중값 속성)

특정 엔티티에 대해 둘 이상의 값으로 구성된 속성 → 학생1명 - 전화변호 여러개 있을 수 있음
Phone no = 한 제공자에 대해 둘 이상의 값이 있을 수 있다

Derived Attribute (파생 속성)

다른 속성에서 파생될 수 있는 속성
나이(생년월일(DOB) 가능) 생년월일을 알면 나이는 자동으로 알 수 있는 값임

Mapping Cardinality Constraints

다른 엔티티를 연결할 수 있는 엔티티 수를 표현
binary relationship set을 설명할 때 유용

• one to one
• one to many
• many to one
• many to many
  
  
  카디널리티 제약조건 : 관계 집합과 엔티티 집합 사이에 하나를 의미하는 방향이 있는 선 또는 다수를 의미하는 뱡향이 없는 선으로 표현
• one to one
  
• one to many
• many to one
• many to many

전체 참여와 부분 참여

Total Participation (indicated by doubled line) 전체 참여
: Entity set 에서 모든 Attribute 는 Relationship set 의 적어도 하나의 relation 에 참여

Partial Participation (가는 선으로 표시)
: Entity set 에서 일부 Attribute 는 Relationship set 의 하나의 relation 에도 참여하지 않을 수 있음

ex :
지도 교수 - 학생 : total
교수 - 지도 교수 : Partial

더 복잡한 제약조건에 대한 표현 방법

l..h 형식으로 쓴다 : 최소 , 최대
교수는 0명 이상의 학생을 지도할 수 있다, 최대 제한이 없음 : 부분관계 ~ * 로 표현
학생은 1명의 교수에게만 지도 받을 수 있다 : 최대 카디널리티 값이 전체 참여 값인 1 이다.

Weak Entity Set (약한 테이블)

엔티티 타입 내의 엔티티가 자체적으로 갖고 있는 애트리뷰트 값에 의해서 고유하게 식별할 수 없는 경우
(교수의 가족 이름은 다른 교수의 가족 이름과 겹칠 수 있음)
→ 키 속성(Primary Key)이 없기 때문에 Weak Entity Sets
Primary key 를 가지면 Strong Entity Sets
특징

• Owner entity 에 의존(depend on)
• Weak entitiy 는 반드시 owner entity 에 한 개의 관계를 가지고 있어야 하는 total particiaption constraint 존재
• Weak entity 는 partial key 가 있다 → 약한 Entity 의 튜플(data) 을 구분할 수 있는 attribute 집합 (여러개의 att)

강한 테이블에 약한 테이블은 항상 의존할 수 밖에 없다.
약한 테이블을 강한 테이블에 대해서 double rectangle 로 표현한다

기본 키 : under line
weak entity 를 구별할 수 있게 하는 discriminator (Partial key) 는 dashed underline 으로 표시한다.

확장 E-R 특징

데이터가 복잡해지면서 기존 ER 만을 사용하는 것이 점점 더 어려워졌다.
복잡한 관계를 처리할 수 있도록 새로운 개념이 추가되었다

Specialization

하나의 상위 엔티티(테이블) 을 두개의 하위 엔티티로 나눌 수 있는 하향식 접근 방식
(one higher level can be broken down into two lower level entity)
Attribute Inheritance (속성 상속) : 상위 엔티티의 모든 attribute 와 relationship 을 모두 상속받는다

Genetialization

Specialization 의 반대
다수의 하위 엔티티를 하나의 엔티티로 결합하는 상향식 접근 방식

Aggregation

relation 을 갖고 있는 몇개의 entity를 하나의 엔티티로 취급하는 process
( 헬스 클럽 - PT 코스 ) 하나의 엔티티로 묶어서 수강생이 센터 가입 뿐만 아니라 PT 문의까지 모두 하게 되는 것

프로젝트에서 가이드별로 학생의 평가를 기록한다고 가정할 때
모든 eval_for 는 proj_guide 관계에 대응 → 즉 eval_for 이 모두 proj_guide 에 포함된다
그러면 proj_guide 를 삭제할 수 는 없음 → 이 때 두 relation 의 중복을 해결하기 위해서
새로운 엔티티로 추상화해서 해결하는 것

지도 교수 - 프로젝트 - 학생 모두 proj_guide 에 연관되어있기 떄문에 하나의 엔티티로 묶고, 이 엔티티는 evaluation 으로 평가된다는 것을 이렇게 표현할 수 있다.

Design Decision

• The use of an attribute or entity set to represent an object
• The use of a strong / weak entity set
• The use of a ternary relationship versus a pair of binary relationships
• The use of specialization / generalization / aggregation
• 
• **전체 참여(total participation)**는 한 엔티티의 모든 값이 다른 엔티티에 모두 연결되어야 한다는 관계 제약 조건입니다. 즉, 한 엔티티의 모든 튜플이 다른 엔티티의 적어도 하나의 튜플과 연결되어야 합니다.
  예를 들어, 학생 개체와 수강 관계가 있다고 가정합니다. 전체 참여가 있는 경우, 모든 학생 튜플은 적어도 하나의 수강 튜플과 연결되어 있어야 합니다. 즉, 학생이 수강을 하지 않는 경우는 없습니다.
  

Unified Modeling Language (UML)

• 범용 모델링 언어
• 주 목적 : 시스템이 설계되는 방식을 시각화 하는 표준 방법을 제시하는 것
• 전체 소프트웨어 시스템의 다양한 측면을 그래픽으로 모델링 할 수 있는 요소가 있음
• ER 다이어그램과 일치하지만 몇가지 차이점이 존재
  
  
  

---

“이 글은 Obsidian 에서 작성되어 업로드 되었습니다”