-
데이터 모델링 - 실체 엔터티DataBase/SQL 2024. 6. 26. 13:49
1. 실체 엔터티 정의
실체 엔터티는 실체라는 단어에 답이 담겨있듯 실체의 물체나 외형에 실상 즉, 실제로 보이는 것을 나타내는 데이터를 관리하는 엔터티가 실체 엔터티다. (데이터가 만질 수 있는 것을 타나내면 실체 엔터티다)
데이터 분류
1. 보이는 것, 만질 수 있는 것 : 실체
2. 보이지 않는 것, 추상적인 것
2.1 연상되는 것 : 주문,강의, 대출 (주로 어떤 행위)
2.2 연상되지 않는 것 (환율, 과목, 상품 유형)
실체 엔터티는 만질 수 있는 데이터를 관리, 주의할 점은 실체의 존재와 연관된 본질적인 데이터를 관리한다는 것
즉, 홍길동이란 실체 의미 홍길동의 주문, 불평 등은 의미하지 않는다.
2. 실체 엔터티가 중요한 이유
모델 구조적으로 실체 엔터티가 최상위에 존재하기 때문에 중요하다!
실체 엔터티는 대게 하위 엔터티가 많다. 주로 행위 엔터티의 주체가 되기 때문이다.
3. 실체 엔터티와 유사한 엔터티
현실 세계에는 실체에 해당하는 데이터가 매우 많다. (도서관, 학교, 아파트 등)
하지만, 시스템 설계 시 해당 업무에서 관리하는 데이터여야 의미가 있기 때문에 실제로 관리하는 실체 데이터는 많지 않다.
실무의 대표적인 실체 데이터는 고객, 사원, 상품 등이다.
주의할 점은 고객, 사원, 상품 등이 온전히 실체 데이터라고 생각하면 안된다는 것이다.
예를 들어
도서관에 책을 예로 들어보자.
도서관에 있는 책은 실체 엔터티다 (만질 수 있고, 실체가 있기 때문이다.)
그렇다면 희망도서는 어떠할까? 희망도서는 실체가 아니다.
실제로 존재하는 낱권을 지목해서 구비해달라는 것이 아니라, 책을 나타내는 정보를 지목하는 것이다.
즉, 책을 상징하는 것이지 책 자체가 아니다.
위 모델링을 확인해보면, 도서관에 있는 실제 책과 도서 정보를 나타내는 도서를 분리했다. 이와 같이 실체와 실체가 아닌 것을 잘 구분해야한다.
도서는 여러권 존재할 수 있지만, 도서관의 도서는 특정 위치에 몇개만 실제로 존재한다 이를 떠올려보는 것이다!
비슷한 예시로 주문을 들어보자
인터넷에서 주문할 때 상품 정보를 보게 된다. 이때 상품은 기본 정보를 의미하므로 실체가 아니다!
주문이 되면, 창고에서 실물 하나가 출고될 것이고, 이를 식별해야한다. 이를 관리한다면, 해당 엔터티는 실체 엔터티다.
상품이라고해서 모두 실체가 되는 것이 아니다!
또 하나의 예시로 역할을 생각해보자
사람을 관리하는 고객 엔터티를 예시로 들어보면, 한 사람을 하나의 고객으로 관리한다면 실체 엔터티가 분명하다.
하지만 고객 엔터티에 다양한 실체가 통합되는 경우가 있다.
예를 들어 사원도 고객으로 통합한다면, 사원이면서 고객인 사람이 있을 수도 있다.
이런 순간 사원은 실체가 아니라, 역할이 된다.
정리하자면, 실체라고 생각되는 것이 실제로는 실체 자체가아니라, 실체를 나타내는 개념 혹은 역할일 수 있으니 이를 잘 구분해서 생각하자
4. 실물의 개수와 실체 엔터티의 개수
실체 엔터티의 중요한 특징 중 기억하기 쉬운 것은 엔터티를 관리하고 있는 인스턴스의 개수와 실제 존재했던 실체의 개수가 같다는 점이다!
기계적으로 같다 보다는 논리적으로 그렇다는 것이다.
예를 들어 회사의 사원이 30명이면 사원 엔터티의 인스턴스 개수도 30개가 된다는 것이다.
퇴사한 사원도 사람이기 때문에 실체이며, 사원 엔터티에 존재해야하고, 상태만 퇴사로 구분할 수 있으면 된다.
실체 엔터티의 인스턴스는 존재했던 그 자체를 의미하기 때문이다!
두번째로 변경이력이 실체에 영향을 주지 않는다는 점이다.
홍길동을 홍길순으로 이름을 변경한다고해서 두명이 있는 것이 아니다!
속성이 아무리 바뀌어도 실체는 하나로 존재한다.
따라서 실체 엔터티와 실체의 변경이력 데이터는 별도의 엔터티로 관리해야한다.
고객의 변경이력 데이터를 고객 자체에서 관리하도록 설계하면 위험할 수 있다!
잘못설계하면 고객 엔터티가 하위 엔터티에 미치는 영향이 작지 않을 수 있다.
정리하자면, 실체 데이터는 한 번 존재하면 지속해서 하나의 인스턴스로 존재해야 하는 데이터다.
고객의 속성 값에 대한 변경이력 데이터가 고객의 숫자에 영향을 미치면 안된다는 점을 잘 기억하자
5. 오직 한 번 존재하는 실체 엔터티의 주 식별자 (식별자를 단순하게 구성하는 것이 좋다)
실체 엔터티의 주 식별자의 특징
1. 존재가 한 번만 발생하는 실체의 성격 주 식별자에 시각 속성이 포함되지 않는 다는 점이 핵심이다.
- 한 번 없어지면 끝이며 다시 생기지 않는다
2. 주 식별자를 인조 식별자로 설계해야한다.
- 실체라는 개념 자체에 이미 지목할 수 있는 식별 번호가 있다는 것을 내포한다. 따라서 고객번호, 상품번호, 장비번호, 사원번호 등을 식별자로 사용한다.
- 고객번호와 같이 일반화된 식별 번호를 주 식별자로 사용하면 데이터가 직관적으로 연상되고, 성격이 명확해진다.
- 주 식별자가 여러 속성으로 구성된다면 모델 전반적으로 관계가 복잡해진다. 가동성이 나빠지고, 관리가 힘들어진다.
3. 또한, 기준 엔터티, 중요 행위 언테터, 기본 정보를 관리하는 엔터티나 역할 엔터티도 인조 식별자가 적절하다.
6. 통합이 수월하고 적절한 실체 엔터티
실체 엔터티는 보이는 것이고, 존재 자체를 의미하므로 일반화 하기 수월하다.
특성이 유사하기 때문에 통합하기 수월한 엔터티가 실체 엔터티이다.
주 식별자가 인조 식별자인 점도 통합을 수월하게 만든다.
7. 명사형 엔터티명
실체 엔터티의 이름은 실체라는 성격에 어울리게 명사형으로 붙이면 된다.
행위 데이터가 아닌 이상 명사형으로 끝나도록 붙이는 게 좋다.
탈퇴 회원을 관리하는 엔터티면 탈퇴회원이 적절하며, 동사형 명사로 끝나는 회원탈퇴는 적절하지 않다.
행위 엔터티는 뒤에 했음을 붙여서 자연스러우면 적절한 이름이다.
반대로 생각하면, 실체 엔터티에 했음을 붙여 자연스럽다면 적절하지 않다!
8 행위 엔터티보다 실체 엔터티로 도출
실체 엔터티는 태생적으로 눈에 띄기 때문에 도출이 용이하다.
애매한 엔터티도 존재하는데, 대표적으로 계좌이다. 언뜻보면 만질 수 없기 때문에 엄격하게보면 실체 엔터티는 아니다.
하지만 느슨하게 생각하면 통장이나 잔고 증명서와 연결돼 실체가 연상되기도 한다.
이러한 이유로 계좌도 실체로 보기도 한다.
실체 엔터티는 데이터 성격도 직관적으로 만들고, 모델 구조에서 토대가 되도록 하는게 좋다!
원인(행위) 데이터와 결과(실체)도 잘 관리하자
'DataBase > SQL' 카테고리의 다른 글
SQL BOOSTER - 문서번호 처리 기술 (0) 2024.07.09 SQL BOOSTER - 트랜잭션 (0) 2024.07.08 SQL BOOSTER - HASH JOIN과 성능 (0) 2024.06.24 SQL BOOSTER - MERGE 조인과 성능 (0) 2024.06.24 SQL BOOSTER - MERGE (0) 2024.06.23