실체 엔터티란
실제로 보이는 것을 나타내는 데이터를 관리하는 엔터티를 의미
위의 정의처럼 보이는 것은 만질 수도 있기 때문에 이런 실제의 물체를 실체 엔터티로 이해하면 쉽다.
그럼 보이지 않는 데이터를 관리하는 데이터는 무엇일까? 보이지 않는다는 것은 추상적인 것을 의미한다. 추상적인 것을 또 구분하자면 연상이 되는 것과 아닌 것이 있을 것이다.
모델링 관점에서 연상이 되는 예는 주문, 강의 등의 행위와 관련된 것이다. 보이지 않지만 행위와 연결되어 연상이 되지만 만질 순 없으니 실체 엔터티는 아니다. 반대로 연상이 되지 않는 것은 과목, 상품유형 등이 있을 것이다.
대개 실체 엔터티는 모델의 구조적으로 최상위에 존재한다
업무에서 중요하게 다루지 않지만 보이는 것을 관리하는 엔터티가 존재하기도 하지만 대부분의 실체 엔터티는 모델 구조에서 최상위에 존재한다. 대개 실체 엔터티의 아래에 하위 엔터티가 많이 존재하여 행위 엔터티의 주체가 되기에 모델 구조에서 실체 엔터티는 중요한 엔터티이다.
시스템 설계에서의 실체 엔터티
대개 다른 서비스에서도 그렇겠지만 고객, 사원, 상품 등을 보통 실체 엔터티라고 생각하게 된다. 다만 시스템을 설계할 때 해당 업무에서 관리하는 데이터여야 의미가 있으므로 실체 엔터티가 되지 않을 수 있다.
도서관과 책
도서관에 있는 책은 실체 엔터티일까? 일단 만질 수 있으니 실체가 맞을 것이다. 그럼 희망 도서는 실체일까?
실제로 존재하는 책 낱권을 지목하여 희망 도서 신청을 하지 않을 것이다. 책에 나타내는 정보를 지목한 것이기 때문에 책을 상징하는 것이지 실제 책은 아니다.
책 |
책번호 PK |
도서번호 FK |
책위치 |
책바코드 |
도서 |
도서번호 PK |
도서명 |
저자명 |
ISBN번호 |
도서가격 |
출판사명 |
도서관에서 책을 빌린다는 것은 바코드가 붙어 있는 책 실물을 빌린다. 도서관에 특정 책이 3건의 인스턴스가 있다면 도서관에 3권이 존재한다는 의미이다. 즉 실체 엔터티에 해당한다.
희망 도서를 신청할 때는 실제 책이 아니라 책의 개념을 신청하는 것이다. 도서관에 해당 책이 몇 권이 있든 도서의 특정 상징일 뿐 1개의 인스턴스가 존재할 것이다. 그러므로 이는 실체 엔터티가 아니다.
주문과 상품
상품은 위와 같은 이유로 바코드가 찍힌 실체 상품 하나를 지목하여 주문하는 것이 아니고 기본 정보를 의미하므로 실체 엔터티가 아니다.
다만 배송에서 상품이라면 개념적인 의미가 아니고 실제 물품을 의미하는 것이므로 실체 엔터티에 해당할 것이다.
요약하자면, 실체가 있더라도 실체를 의미할 수도 있고 그 실체를 나타내는 기본 정보를 의미할 때가 있다!
역할
한 쇼핑몰에서 사원이 있으면 당연히 사원은 고객이 될 수도 있을 것이다. 이를 사원과 고객을 통합하게 되면 2건의 고객 데이터로 관리될 것이다. 하지만 위에서 강조해온 실체 엔터티의 의미에서 어긋나게 될 것이다. 한 사람이 두 사람이 될 수 없기 때문이다.
즉, 사원과 고객은 역할의 개념으로 다가가 실체 두 개가 아닌 역할 두 개로 정의해야 한다. 이처럼 역할을 실체 엔터티와 유사하여 헷갈리는 경우가 많지만 역할로 볼 것인지 실체로 볼 것인지 일관되게 설계할 필요가 있다.
실체 엔터티의 특징
- 엔터티에서 관리하고 있는 인스턴스 개수와 실제 존재하는 실체 개수는 (논리적으로) 같다
사원 엔터티가 있을 때 사원 수가 10명이면 인스턴스 수가 10개일 것이다. 물론 퇴사한 사원도 실체가 존재하고 사원이었으므로 사원 엔터티에 속해야 한다면? 복잡하게 생각할 필요 없이 사원의 상태를 퇴사로 구분해주면 되는 것이다.
- 실체 엔터티는 존재 그 자체를 의미한다
물리적으로 존재하는 실체는 하나의 인스턴스로 계속 존재하고 엔터티의 인스턴스는 물리적으로 삭제하지 않기에 실체가 소멸되면 해당 인스턴스의 상태만 변경하여 존재하게 된다.
- 속성값의 변경이 실체의 존재에 영향을 미치지 못한다
고객 엔터티에 고객명이 개명으로 바뀌게 되더라도 이름이 바뀔 뿐이지 실제 존재하지 않게 되는 것은 아니기 때문이다. 실체 변경이력 데이터의 경우도 실체 자체에 영향을 미치지 않고 관리가 필요하다면 고객이력 엔터티같은 별도의 엔터티에서 관리해야 한다. 실체 엔터티 안에 변경이력 데이터를 속성으로 관리하도록 설계하지 않도록 해야한다.
- 엔터티명 뒤에 '했음'을 붙였을 때 어울리지 않는다
반대로 '했음'을 붙였을 때 자연스러우면 행위 엔터티가 적절하다.
- 인스턴스 발생이 빈번하지 않다
- 추출 속성의 남발로 속성이 많아지는 경향이 있다
- 유형 내에서 특성이 유사하기에 통합할 수 있는 개념은 과감히 통합하는 것이 좋다
실체 엔터티의 주 식별자
실체 엔터티는 존재가 1번만 발생하므로 주 식별자에 시각 속성이 포함되지 않는다. 다른 것이 생기는 것이지 같은 것이 다시 생길 수 없다는 의미이다. 그리고 주 식별자로 인조 식별자로 식별하는 것이 좋다.
실체 엔터티의 주 식별자가 여러 속성으로 구성되어 복잡해지면 모델 전반적으로 관계가 복잡해질 수 있다. 이는 가독성이 나빠지고 관리가 힘들어질 것이다.
기준 엔터티
실체나 행위 데이터(업무)의 기준이 되는 데이터를 관리하는 엔터티
기준 엔터티는 실체 엔터티와 유사한 부분이 많다.
인조 식별자를 사용한다거나, 개수가 많지 않고 행위가 연상되지 않다는 점도 유사하다. 기준의 성격상 하나만 존재햐아 하므로 하나의 엔터티로 통합하는 게 좋다.
다만 존재를 나타내는 것이 아니고 시간이 지남에 따라 자주 변경된다는 점은 차이점이다.
'Web Study > DataBase' 카테고리의 다른 글
데이터베이스 개론 & SQL - 1 (0) | 2024.01.31 |
---|---|
SQLD 합격! 그리고 DAsP 도전 (0) | 2023.12.21 |
SQLD 그룹함수 (1) | 2023.11.20 |
SQLD - 서브쿼리 (1) | 2023.10.31 |
SQLD - 계층형 질의 (0) | 2023.10.29 |