• data model : data들의 관계와 구조를 DB에서 표현하기 위해서 사용되는 개념과 방법의 집합
  ➡️ 가장 많이 사용하는 것은 relational(관계) data model

• data modeling :

  • data를 DB로 옮기는 과정, DB를 설계하는 과정
    

설계 단계에서 ER diagram을 통해 data modeling하는 방법을 배울 것이다.
ER diagram은 개념적 data model(data를 관계를 개념적으로 표현, 스케치)이다.

DB 설계?

• 기업, 관공서, 학교의 정보들을 전산화 한다 = DataBase를 구축, 네트워킹 환경, UI 환경 등을 만들겠다.
• 전산화를 해주는 회사들이 있다. (ex : 삼성 SDS, LG CNS, SK C&C, POSCO DX, ...)

DB 설계 단계

• DB 설계 단계 :
  
  1. 개념적 설계 : 추상적인 개념, 고수준 (ex : ERD)
  2. 물리적 설계 : XML, table 형식으로 저장 (ex : Relational model)
  3. 구조적 설계 : 성능을 최적화시키기 위해서 disk상의 저장구조(index 만들기, ..)를 설계

요구사항 수집과 분석

• DB 설계시 가장 먼저 해야 할 일이다.
• client와 인터뷰를 하며 요구사항을 정리(수집과 분석)를 해야 함.
  • 실제로는 요구사항을 정리하기 쉽지 않기 때문에 client가 DB 설계팀에 상주하는 경우도 있다.

개념적 설계

ER model을 사용한 개념적 설계

• 실세계를 entity, attribute, relationship으로 modeling함.

  • entity : 실세계에서 존재하는 실체 $\simeq$ object
  • attribute : entity들이 갖고 있는 속성
  • relationship : entity 간의 관계

• ERD는 표준화되어 있지 않아서 각각의 workbench마다 ERD가 조금씩 다르다.
  

• entity = object : 실세계에서 독립적으로 존재하는 실체

• attribute : entity를 기술하는 속성

  • example)
    
    • entity : $e_1, c_1$
    • $e_1$ entity의 attribute : Name, Address, Age, HomePhone
    • $c_1$ entity의 attribute : Name, Headquarters, President

Entity & attribute & Relationship

Entity type

• Entity type : 동일한 attribute를 갖는 entity들의 집합 == Class
  (Object Oriented Programming이 나오기 전 용어라, 용어가 어색함. Class로 이해하면 된다)
  • Entity type은 ERD에서 직사각형으로 표시함.
    

attribute

• attribute는 동그라미로 나타냄.
  

composite(복합) attribute vs simple(단순) attribute

• composite attribute : 더 작은 attribute로 나뉨
  • ex : address는 시, 구, 동, 우편번호 등으로 세부적으로 나눠질 수 있음
    
• simple attribute : 더 이상 나눌 수 없는 atomic한 attribute.

single value(단일 값) attribute vs multi-valued(다치) attribute

• single value attribute : attribute 안에 하나의 값만 넣을 수 있음

• multi-valued attribute : attribute 안에 여러 값을 넣을 수 있음
  동그라미 2개를 중첩해서 나타냄.

  • ex : hobby(축구, 야구, 농구, ...)
    

stored(저장된) attribute vs derived(유도된) attribute

• stored attribute : DB에 실제로 값이 저장된 attribute

  • ex : DOB(Date of Birth)

• derived attribute : DB에 값이 저장되어 있지 않으나, 다른 attribute나 사실에 의해 값이 유도될 수 있는 attribute.
  점선 동그라미로 나타냄.

  • ex : Age ➡️ 오늘 날짜와 DOB에 의해 나이가 유도될 수 있음
    

그래서 Age를 stored attribute로 저장해놓으면 잘못된 DB이다.
나이는 시간이 지나면서 계속해서 바뀌니까 매년 Age값을 update해야 한다.
이는 비용이 많이 들기 때문에 Age를 저장하는 것보다 DOB를 저장해놓는게 더욱 알맞은 것이다.

key attribute

• key attribute : 각 entity마다 서로 다른 값을 가지는 attribute
  밑줄을 그어 나타냄.
  

• 복합 key : 두 개 이상의 attribute들이 모여서 하나의 key attribute 역할을 하는 key

  • ex : 생년월일 + 뒷자리
    생년월일 attribute만으로 key attribute가 될 수 없음.
    뒷자리 attribute만으로 key attribute가 될 수 없음.
    생년월일 + 뒷자리는 key attribute가 될 수 있음
    

Relation

• Relation : entity들 간의 연관성(Relation)을 이용하여 연결.
  예를 들어, 위의 예제에서는 아래와 같은 연관성을 갖고 Relation을 부여할 수 있다.
  • DEPARTMENT entity type의 Manger attribute는 그 회사의 EMPLOYEE(사원)일 것이다.
  • DEPENDENT(피부양자) entity type은 부양을 하는 EMPLOYEE(사원)이 있을 것이다
  • PROJECT entity type은 해당 PROJECT를 controll하는 DEPARTMENT가 있을 것이다.

관계 type & 관계 instance

• 관계 type : 관계 타입 R은 entity들 간의 연관들의 집합
  마름모로 나타냄
• 관계 instance : 관계 type에서 관계 instance (r1 ~ r7)
  

관계 type의 degree

• 관계 degree : 관계에 참여하고 있는 entity type의 수
  • binary degree : WORKS_FOR
    
  • 3진 degree : SUPPLY
    

역할 이름과 순환적 관계

• 역할 이름 : 관계 type에 참여하는 각 entity type은 관계 내에서 특정한 역할을 담당함
  • ex : 관계 WORKS_FOR에서는 EMPLOYEE는 사원/근로자 역할이고, DEPARTMENT는 부서/고용주의 역할
• recursive 관계 :
  • WORKS_FOR라는 관계 type은 명확하게 알 수 있다.
  • SUPERVISION이라는 관계 type은 명확하게 알 수 없다. 관리자(상사)인지? 관리받는 사람(부하)인지?
    상사도 직원, 부하도 직원이기 때문에 순환적인 관계가 있다.
    그래서 관리자(상사)를 (1), 부하를 (2)로 표시하여 두 역할을 구분할 수 있다.
    

Cardinality Ratio

• Cardinality ratio : entity들이 관계에 참여하는 최대 비율

• binary degree의 관계 type에 대한 Cardinality ratio은 1:1, 1:N, M:N

• 1 : 1 :

  • 한 사원이 최대 하나의 DEPARTMENT를 관리함
  • 한 DEPARTMENT는 최대 한 명의 사원에 의해 관리되어짐.
    

• N : 1 :

  • 한 DEPART는 여러 사원에 의해 관리되어짐.
    ➡️ EMPLOYEE에서 관계에 더 많이 참여하니까 N : 1
    

• M : N :

  • 한 사원이 여러 PROJECT에 참여하는 경우가 있음.
  • 여러 사원이 하나의 PROJECT에 일하는 경우가 있음.
    

부분참여 vs 전체참여

• 부분참여 : 모든 entity type의 entity가 관계에 참여하지 않는 관계. (단일선으로 표시)
• 전체참여 : 모든 entity type의 entity가 관계에 참여하는 관계. (이중선으로 표시)
  
  • 해석 :
    모든 직원들은 반드시 소속 부서를 가져야 하고, 직원이 한 명도 없는 부서가 있을 수 있다.

관계 type의 attribute

• 관계 type의 attribute : 관계 type도 entity type처럼 attribute를 가질 수 있다.
  • ex :
    • WORKS_ON 관계 type에 Hours attribute를 포함시킬 수 있음
    • MANAGES 관계 type에 StartDate attribute를 포함시킬 수 있음(언제 관리자가 되었는지)

• 1 : 1 관계 type의 attribute : 양쪽 entity type으로 이동 가능
  한 부서에는 한 명의 직원밖에 없기 때문에
  직원이 부서에서 일을 시작한 날짜 = 그 부서가 일을 시작한 날짜

• 1 : N 관계 type의 attribute : N쪽 entity type으로 이동 가능
  직원에 따라 부서에서 일을 시작한 날짜가 다르기 때문에

• M : N 관계 type의 attribute : entity type으로 이동 불가. 반드시 관계 type에 표현되어야 함.
  

약한 entity type & 부분 키

• 약한 entity type :
  • 자신의 key attribute가 없는 entity type.
  • 약한 entity type은 다른 entity type의 key attribute와 연계됨으로서 식별될 수 있음
  • 직사각형 두 겹으로 표현.
    • 이때, 다른 entity type을 식별 entity type이라고 함.
    • 이때, 식별 entity type과의 관계 type을 식별 관계 type이라고 함. (마름모 두 겹)
• 부분 키 :
  • 약한 entity type 내에서, 서로를 구분할 수 있는 attribute들의 집합
  • 점선 밑줄로 표현
• ex :
  
  • 회사 내의 피부양자 중에서 Name, Sex, BirthDate, Relationship이 모두 똑같은 경우가 있을 수 있어서
    key가 될 수 없다.
    즉, DEPENDENTS entity type은 key가 없는 약한 entity type이다.
    
    그래서 EMPLOYEE(식별 entity type)의 key(ex:직원 id)와 연관(식별 관계 type을 이용)해서
    어떤 직원의 피부양자인지 구별해내야 한다.
    
    이때 EMPLOYEE와 연관한 DEPENDENTS에서는 이제 name attribute를 이용하여 구별해낼 수 있다.
    이때, name은 단독적인 key가 될 수 없고 EMPLOYEE의 Key와 연관하여 사용되는 key이므로,
    부분 key가 된다.
    
    
  • 부분참여, 전체참여 분석 :
    모든 직원이 피부양자(DEPENDENTS)를 가지지 않는다. (회사에 결혼을 안 한 사람도 있다.)
    만약 피부양자가 있는 직원이라면,
    피부양자들의 부양자는 해당 회사의 직원이어야 한다.

---

개념적 설계 결과 (ERD)

• 

연습

• Book은 title, author, price, year와 고유한 번호인 ISBN을 갖는다
• Publisher는 pname, location, pnumber, 그리고 고유한 pid를 갖는다
• 출판사의 위치는 여러 곳에 분산될 수 있다.
• 한 출판사는 여러 종류의 책을 Publish할 수 있으며, 모든 책은 반드시 출판사를 통해서만 출판된다
• 고객은 고유한 cid, cname, mileage를 갖는다
• 고객이 책을 구매하면 고유한 번호 bid가 부여되고, date와 payment에 대한 정보를 유지한다.
  

---

(최소값, 최대값)을 사용한 표기법

• (최소값, 최대값)
  
  • EMPLOYEE는 어느 한 부서에 반드시 속해있어야하고, 한 부서에만 속할 수 있음
  • 한 부서에는 반드시 한 명 이상의 직원이 있어야 함.

개념적 설계 결과 (ERD)