2. 2장 데이터베이스 설계 (database design) (2) - ER Modeling

ER modeling을 하기 위한 개념을 설명한다.

 

Entities

Entity

엔티티 == 객체!!!!!!

    자바, 파이썬, C++같은걸 배울 때 나오는 class를 생각하면 될것같다!

    학생, 강의실, 회사.. 등등이 엔티티가 된다

attribute

속성 <- 엔티티를 설명하는것

    class의 멤버변수와 비슷하게 생각하면 된다!

    학생이면,,, 학번, 이름, 나이 와 같은 속성을 가지고 있다

속성은 도메인을 가질 수 있다 (값의 범위, 타입 등을 가짐

    이름 속성이면, string이라는 도메인을 가진다

속성은 단일값, 다중값 모두 가능하다!

entity set

엔티티 집합 == 여러개의 객체를 모아둔것

    class를 이용해 여러개의 변수 (객체)를 만들 수 있다

    -> 이런 객체들을 모아둔걸 엔티티 집합이라고 보면 된다!

    학생 엔티티 집합.. 이라고 하면 철수, 영희, 맹구,,, 를 모아서 만든 집합을 생각하면된다

    그리고 이 학생들은 똑같은 속성을 가진다 (이름, 학번, 나이 등등,,)

엔티티 집합은 서로 겹칠 수 있다

    철수가 학생이자, 학생회 부원이라면??

    => 학생 엔티티 집합과 학생회 부원집합에 동시에 속하게 된다!

엔티티 집합에는 키(key)가 존재한다

    고유하게 엔티티를 식별하는 속성!

    하나의 엔티티 집합 내에서, 키값은 중복이 안된다.

    - 기본키 (primary key) : 고유하게 엔티티를 식별하는 속성, NOT NULLL, 중복X

    - 대체키 (candidate key) : 기본키로 사용할 수 있는 여러 속성 집합 중 하나, 이 집합 중 하나가 기본키고 나머지는 대체키

엔티티 : 사원

속성 : 사번, 이름, 나이

키 : 사번

 

Entity Instance

구체적인 개별 엔티티

    -> class를 이용해 변수를 만들면, 그제서야 비로소 객체가 생성된다!

    이 변수라고 생각하면 될것같다. (실질적인것)

Relationships

relationship

관계 : 두 개 이상의 엔티티 사이의 연관성을 나타낸다

    관계 자체가 속성을 가질수도 있음

-> 엔티티간의 상호작용을 표현할 수 있다

    학교를 예를 들면,,,

    학생, 강의 == 각각 엔티티

    수강하다 == 학생과 강의를 연결하는 관계!

relationship set

관계 집합 : 관계를 모아둔것

    [학생]이 [강의]를 [수강한다]

    -> 이 관계를 여러개 모으면 관계집합이 된다

    철수가 데베시를 수강한다

    영희가 운영체제를 수강한다..

    이런식으로!

descriptive attributes

관계에도 속성이 들어갈 수 있다!

-> 관계 자체에 대한 정보를 추가로 제공하는 역할을 한다.

    예를 들어,,, 직원이 특정 부서에 "언제부터" 일했는지 기록하고 싶다면,,,

    [직원]이 [부서]에 (언제부터) [일했다]

    -> (언제부터)가 work라는 relationship의 속성으로 들어간다!

         이건 [직원]에도, [부서]에도 속성으로 들어갈수는 없음!

 

엔티티 : 사원, 부서

엔티티 속성 : 사번, 이름, 나이 / 부서id, 부서명, 예산

key : 사번, 부서id

관계 : work

관계 속성 : 기간

 

Binay and Ternary Relationships

관계에 참여하는 엔티티 숫자에 따라 이진관계, 삼항관계로 나눌 수 있다

 

Binary Relationships

이진관계 : 관계에 참여하는 엔티티가 두개인것 -> 선분이 두개!

    위에 설명한 work 관계가 이진관계이다 (사원과 부서)

 

self-referencing relationship

자기 참조 관계 : 같은 엔티티 집합 내에서 발생하는 관계이다

    사원간에 상하관계가 생기는 경우,,,

    사원A가 사원B에게 보고한다 <- 라는 관계가 생긴다

    엔티티가 2개니까 binary이긴한데, 같은 엔티티 "집합"에서 나와서 자기참조이다!

 

ternary relationships

삼항관계 : 세 개의 엔티티 집합이 참여하는 관계

자세한 설명은 나중에 나오려나보다,,ㅎㅎ 

 

Multiple Relationships

다중관계 : 하나의 엔티티 집합은 여러 관계 집합에 참여할 수 있다.

    사원을 예로 들면,,, 사원은 특정 부서에서 [일한다] 라는 관계도 존재하지만

    특정 부서를 [관리한다]라는 관계또한 가질 수 있다!

 

모델의 기능

ER model을 그릴 때, 적용하는 제약조건에 따라 모양이 약간 달라진다

Key Constraints : 화살표

키 제약 : 특정 관계에서, 하나의 엔티티가 고유하게 다른 엔티티와 연결된다는것을 의미한다

    => 일대다 관계로 제약해준다는 것 같다

    회사를 예로 들면,,,,,

    work 관계 : 한 직원이 여러 부서에서 일할 수 있음

                       동시에 한 부서에 여러 직원이 속할 수 있음

           => 다대다 관계가 된다!

    manage 관계 : 한 직원이 여러 부서를 관리할 수 있음

                             근데 한 부서에는 관리자가 한명만 존재해야함!!

            => key constraints가 적용된다 == 일대다 관계!

화살표를 이용해 표시해준다! manage에서, 하나의 부서에는 manage 관계인 사원이 한개만 있어야 한다는 뜻이 된다

 

Participation Constraints : 굵은 선분

참여제약 : 엔티티 집합의 모든 엔티티가 관계에 참여애햐 하는지 여부를 정함

    엔티티 집합 내의 일부 엔티티만 관계에 참여해도 괜찮은지, 무조건 전부 다 참여해야 하는지를 결정함

    => 참여제약이 걸리면, "모든 엔티티가" 해당 관계에 적어도 한개 이상의 관계에 참여해야한다는 뜻이다

    회사를 예로 들면,,,

    모든 사원은 적어도 1개 이상의 부서에 무조건 일을 해야한다. -> 참여제약

    모든 부서도, 적어도 1명 이상의 사원이 있어야한다. -> 참여제약

    모든 부서에는, 무조건 한명의 매니저가 있어야 한다. -> 참여제약

    모든 사원이, 매니저일 필요는 없다

weak entities

약한 엔티티 : 자체적으로는 고유하게 식별할 수 없고, 다른 엔티티에 의존해 식별되는 엔티티이다.

-> 키를 가지지 않고, 다른 에닡티의 기본키와 결합되어 식별된다!

    약한 엔티티가 의존하는 엔티티를 owner 엔티티라고 한다.

    식별 엔티티 (identifying owner)와 식별관계 (identifying relationship)을 통해 weak entity가 연결됨

    회사를 예로 들면,,,

    회사 복지제도로, 부양가족 제도가 있다고 가정해보자!

    그럼 어떤 사원의 부양가족 정보도 같이 저장되어야 한다

    => 근데,,, 사원이 존재하지 않으면 부양가족의 정보는?? 의미없어진다!!

    이런경우, owner 엔티티가 사원 엔티티, weak 엔티티가 부양가족 엔티티가 된다.

    부양가족의 key또한, 사원의 사번과 가족의 이름을 결합해서 만들어준다 -> 이름이 부분키 (partial key)

owner entity와 weak entity는 1대다 관계를 가진다

    사원은 여러명의 부양가족을 가질 수 있지만, 부양가족은 하나의 복지정책에만 해당된다 (1대다관계)

weak entity는 반드시 식별관계에 참여해야 한다

    부양가족의 존재 의의는 복지정책이므로,, 반드시 복지정책 관계에 참여해야함

 

Class Hierarchies

클래스 계층 : 엔티티 집합을 subclass로 나누는 방식

    -> 상속 구조를 만들 수 있는것!

    - 전문화 (specialization) : 상위 엔티티 집합을, 서브클래스로 나누는것 (down)

              회사를 예로 들면, 사원을 정규직과 계약직으로 나누는걸 생각할 수 있다

    - 일반화 (generalization) : 여러 엔티티 집합의 공통속성을 모아서 상위 엔티티 집합을 만드는것 (upward)

사원인데, 시간제 사원 / 계약직 사원 으로 나눠질 수 있다!

 

제약

    - 겹침 제약 (overlap constraints) : 두 서브클래스가 동일한 엔티티를 포함하는지

         중복허용 (overlapping) : 하나의 엔티티가 두개 이상의 서브클래스에 속할 수 있음

                       계약직이면서 동시에 주니어 개발자일 수 있음

         중복불가 (disjoint) : 하나의 엔티티는 오직 하나의 서브클래스에만 속함

                      시간제이면서 동시에 계약직일수는 없다.

    - 포함 제약 (covering constraints) : 상위 클래스의 모든 엔티티가 서브클래스에 포함되어야 하는지 여부

         포함 제약 (covering) : 상위 클래스의 모든 엔티티는 적어도 하나의 서브클래스에 속해야함

                       모든 사원은 시간제 혹은 계약직 하나에 속해야함

         비포함 제약 (partial) : 상위 클래스의 일부 엔티티는 서브클래스에 속하지 않을 수 있음

                       일부 사원은 시간제도 계약직도 아닐 수 있음,, (일일알바일 수 있음)

ISA 관계의 장점

    - 각 서브클래스마다의 특성을 정의할 수 있음 (속성을 추가해서)

    - 관계에 참여하는 엔티티를 식별할 수 있음

 

aggregation

집합 : 엔티티와 관계집합간의 관계를 나타내기 위한것

    관계집합이 다른 관계집합과 연결될 수 있다

    회사를 예로 들면,,,,,,

    [부서]가 [프로젝트]를 [후원한다] => 관계하나 완성!

    그리고 이 [후원]을 [담당직원]이 [모니터링]한다 => 라는 또다른 관계가 존재할때,,,

    모니터링 관계는 "엔티티 (직원)" 와 "관계 (후원)" 을 연결하는 관계이다!

    이럴 때 집합을 사용해 표현해준다

장점

    집합을 안쓰면 복잡한 삼항관계를 사용해야한다,, 이건 너무 힘든일이야!!

    [후원]관계를 하나의 엔티티 처럼 다룰 수 있어서 편하다