엔터티인지 아닌지를 가르는 기준은 "중요해 보이는가"가 아니라 "두 건 이상 생기는가"입니다.
풀고 시작
문제 1. 어떤 업무에서 부서는 단 하나뿐이고 앞으로도 늘어날 계획이 없습니다. 이때 부서를 엔터티로 볼 수 없는 가장 큰 이유는?
엔터티의 조건 중 하나가 인스턴스가 두 건 이상 존재해야 한다는 것입니다. 한 건뿐인 개념은 속성이나 상수로 두는 편이 낫습니다. 눈에 보이지 않아도 엔터티가 될 수 있으므로 유형 여부는 기준이 아닙니다.
엔터티는 사물이 아니라 집합입니다
엔터티를 처음 배울 때 가장 많이 하는 오해가 "엔터티는 물건"이라는 생각입니다. 그래서 상품과 창고는 엔터티 같고, 주문과 계약은 왠지 아닌 것 같죠. 그런데 실제 모델을 뜯어 보면 주문과 계약이 훨씬 중요한 엔터티로 앉아 있습니다.
엔터티(entity)는 업무에서 관리해야 하는, 서로 구분되는 것들의 집합입니다. 여기서 핵심은 집합이라는 말입니다. 학생 한 명은 엔터티가 아니라 인스턴스이고, 학생 전체가 엔터티입니다. 그래서 엔터티 이름은 단수 명사로 쓰되 머릿속에서는 언제나 여러 건이 담긴 상자를 떠올려야 합니다.
집합으로 보는 습관이 왜 중요할까요. 엔터티가 집합이라면 그 안의 원소는 반드시 서로 구별되어야 하고, 구별하는 수단이 곧 식별자가 되며, 원소가 공통으로 갖는 성질이 곧 속성이 되기 때문입니다. 4강까지의 이야기가 전부 이 한 문장에서 갈라져 나옵니다.
엔터티가 되기 위한 조건
교재마다 표현은 조금씩 달라도 요구하는 조건은 대체로 같습니다.
첫째, 업무에서 필요로 하는 정보여야 합니다. 실제로 쓰지 않는데 있어 보인다는 이유로 만든 엔터티는 빈 껍데기로 남습니다. 둘째, 유일한 식별자로 각 인스턴스를 구별할 수 있어야 합니다. 셋째, 인스턴스가 두 건 이상 있어야 합니다. 한 건뿐이면 그냥 값입니다. 넷째, 반드시 속성을 가져야 합니다. 식별자만 있고 다른 속성이 하나도 없다면 그 엔터티가 존재할 이유를 다시 봐야 합니다. 다섯째, 다른 엔터티와 최소 한 개 이상의 관계를 가집니다. 통계용 코드처럼 예외가 없지는 않지만, 아무와도 이어지지 않은 섬 같은 엔터티는 대개 설계를 잘못한 신호입니다.
이 조건들을 외우려 하기보다 반대로 물어 보세요. "이걸 지우면 업무가 곤란한가", "두 건을 어떻게 구별하지", "이 안에 뭐가 들어 있지". 세 질문에 답이 나오면 엔터티입니다.
눈에 보이는가, 언제 생기는가, 무엇을 담는가
엔터티는 세 가지 축으로 분류합니다. 시험이 아주 좋아하는 대목입니다.
분류 축
종류
예
유무형
유형, 개념, 사건
상품과 사원은 유형, 부서와 조직은 개념, 주문과 접수는 사건입니다
발생 시점
기본, 중심, 행위
사원은 기본, 주문은 중심, 주문변경이력은 행위입니다
속성 수
단일 속성 엔터티와 복합 속성 엔터티
코드성 집합과 여러 속성을 가진 집합의 구분입니다
두 번째 축이 특히 자주 나옵니다. 기본 엔터티는 다른 것에 의존하지 않고 스스로 존재하며 자기 고유의 식별자를 가집니다. 중심 엔터티는 기본 엔터티에서 발생해 업무의 중심 역할을 하고, 다시 다른 엔터티를 낳습니다. 행위 엔터티는 두 개 이상의 엔터티 사이의 행위로 생기며 대체로 발생량이 가장 많습니다. 사원과 상품이라는 기본 엔터티가 있고, 거기서 주문이라는 중심 엔터티가 나오고, 주문에서 주문상태변경이라는 행위 엔터티가 나오는 식이죠.
이름을 잘못 지으면 모델이 아니라 낙서가 됩니다
엔터티 이름에도 규칙이 있습니다. 현업의 업무 용어를 쓰고, 약어를 함부로 쓰지 않으며, 단수 명사로 짓고, 전체 모델에서 유일해야 하고, 엔터티가 생성되는 의미대로 이름을 붙입니다.
마지막 규칙이 은근히 어렵습니다. 예를 들어 사원이 부서를 옮긴 기록을 담는 집합에 "부서"라고 이름을 붙이면 뒤에 오는 사람은 그것이 부서 목록인지 이동 이력인지 알 수 없습니다. "부서이동"이라고 지어야 그 집합이 왜 생겼는지가 이름에 남죠. 1강에서 말한 명확화가 여기서 실제로 작동합니다.
다음 강에서는 이 상자 안에 들어가는 내용물, 곧 속성을 봅니다. 엔터티를 집합으로 보는 눈이 생겼다면 속성은 훨씬 쉽게 정리됩니다.
인출 문제
문제 1. 엔터티의 성립 조건으로 옳지 않은 것은?
부서나 조직처럼 눈에 보이지 않는 개념도, 주문이나 접수처럼 순간에 일어나는 사건도 엔터티가 됩니다. 유형 여부는 분류의 축일 뿐 성립 조건이 아닙니다.
문제 2. 발생 시점에 따른 분류에서 행위 엔터티에 대한 설명으로 가장 적절한 것은?
행위 엔터티는 다른 엔터티들 사이의 행위에서 생겨 발생량이 많습니다. 첫 번째는 기본 엔터티, 두 번째는 중심 엔터티의 설명이고, 마지막은 속성 수에 따른 분류라 축 자체가 다릅니다.
문제 3. 엔터티 명명 규칙으로 적절하지 않은 것은?
엔터티는 집합이지만 이름은 단수 명사로 짓는 것이 관례입니다. 이름이 집합임을 드러내지 않아도 모델을 읽는 사람은 엔터티가 집합이라는 사실을 이미 알고 있기 때문입니다.
문제 4. 사원이 부서를 옮긴 내역을 관리하는 엔터티의 이름으로 가장 적절한 것은?
이름은 그 집합이 왜 생겼는지를 담아야 합니다. 부서나 사원은 이동 내역이 아니라 대상 자체를 가리키고, 사원정보는 무엇을 담는지 알 수 없을 만큼 넓습니다. 이동이라는 사건이 이름에 남아야 뒤에 오는 사람이 모델을 읽을 수 있습니다.
더 풀기
출제기준의 세세항목을 따라 이 강의 범위에서 새로 낸 문제입니다. 모의고사도 여기에서 뽑습니다.
묶음 1
문제 1. 엔터티를 가장 정확하게 설명한 것은?
엔터티는 개별 사물이 아니라 같은 성질을 가진 것들의 집합입니다. 테이블은 엔터티를 물리로 옮긴 결과일 뿐이고, 화면이나 작업은 프로세스 쪽의 개념입니다.
문제 2. 엔터티와 인스턴스의 관계를 바르게 설명한 것은?
사원이라는 엔터티 안에 홍길동이라는 인스턴스가 들어갑니다. 집합과 원소의 관계라고 보면 됩니다. 속성은 인스턴스가 가지는 항목이라 층이 다릅니다.
문제 3. 다음 중 엔터티가 되기 위한 조건으로 보기 어려운 것은?
계약이나 주문처럼 눈에 보이지 않는 것도 얼마든지 엔터티가 됩니다. 눈에 보이는지는 유형과 개념을 나누는 분류 기준일 뿐 자격 조건이 아닙니다.
문제 4. 인스턴스가 한 건뿐인 대상을 엔터티로 만들면 안 되는 이유로 가장 알맞은 것은?
회사가 하나뿐인데 회사 엔터티를 두면 그 안에는 늘 한 건만 있습니다. 집합으로 관리할 이유가 없으니 설정값이나 상수로 두는 편이 맞습니다.
문제 5. 속성이 하나도 없는 엔터티가 문제가 되는 이유로 가장 알맞은 것은?
엔터티는 무엇인가를 알기 위해 두는 것입니다. 담을 정보가 없다면 그 자리는 엔터티가 아니라 코드값이거나 다른 엔터티의 속성일 가능성이 큽니다.
문제 6. 다른 엔터티와 아무 관계도 맺지 않는 엔터티를 발견했을 때 가장 먼저 의심해야 할 것은?
업무는 서로 이어져 있어서 완전히 고립된 집합은 드뭅니다. 관계가 없다면 관계를 빠뜨렸거나 그 엔터티가 업무에 쓰이지 않는 것입니다. 다만 코드성 집합처럼 예외도 있으니 확인이 필요합니다.
문제 7. 유형 엔터티에 해당하는 것으로 가장 알맞은 것은?
유형 엔터티는 물리적으로 존재하며 오래 유지되는 대상입니다. 개념 엔터티는 눈에 보이지 않는 관리 개념이고, 사건 엔터티는 업무 처리로 발생합니다.
문제 8. 개념 엔터티에 해당하는 예로 가장 알맞은 것은?
부서나 직급은 눈에 보이는 물체가 아니라 관리 목적으로 정의한 개념입니다. 상품은 유형, 주문과 배송 이력은 업무 처리로 생기는 사건 쪽에 가깝습니다.
문제 9. 사건 엔터티의 특징으로 가장 알맞은 것은?
주문이나 입금 같은 사건은 업무가 발생할 때마다 한 건씩 쌓입니다. 그래서 건수가 가장 크게 늘고 이력 관리와 성능 설계의 중심이 됩니다.
문제 10. 발생 시점으로 엔터티를 나눌 때 기본 엔터티를 가장 잘 설명한 것은?
사원이나 상품처럼 원래 존재하는 것이 기본 엔터티입니다. 중심 엔터티는 기본에서 파생되고, 행위 엔터티는 두 개 이상의 엔터티가 만나 생깁니다.
묶음 2
문제 1. 중심 엔터티를 가장 잘 설명한 것은?
주문이나 계약처럼 업무의 허리를 이루는 것이 중심 엔터티입니다. 기본 엔터티에서 나오고 다시 행위 엔터티를 낳는 자리에 있어 관계가 많이 몰립니다.
문제 2. 행위 엔터티의 예로 가장 알맞은 것은?
주문 상세는 주문과 상품이라는 두 엔터티가 만나서 생깁니다. 사원과 상품은 기본, 부서는 개념 쪽에 가깝습니다.
문제 3. 엔터티 이름을 지을 때 지켜야 할 원칙으로 보기 어려운 것은?
논리 이름과 물리 이름은 목적이 달라 같을 필요가 없습니다. 논리 이름은 사람이 읽는 말이고 물리 이름은 제품의 제약을 받습니다.
문제 4. 엔터티 이름에 처리라는 말을 붙이면 곤란한 이유로 가장 알맞은 것은?
엔터티는 무엇을 저장하는가를 가리켜야 합니다. 처리나 관리 같은 말이 붙으면 프로세스 이름처럼 읽혀 데이터 관점이 흐려집니다.
문제 5. 같은 대상을 부서마다 고객, 거래처, 회원으로 다르게 부르고 있을 때 모델링에서 취해야 할 조치로 가장 알맞은 것은?
먼저 정말 같은 집합인지 확인하는 것이 순서입니다. 같다면 통합해 중복 정의를 막고, 다르다면 무엇이 다른지를 이름과 정의에 명확히 남깁니다.
문제 6. 엔터티 정의서에 반드시 남겨야 할 항목으로 가장 알맞은 것은?
정의가 없으면 같은 이름을 두고 사람마다 다른 것을 떠올립니다. 무엇의 집합인가를 한 문장으로 못 적으면 그 엔터티는 아직 정리되지 않은 것입니다.
문제 7. 엔터티를 도출할 때 업무 기술서와 인터뷰에서 주로 찾아야 하는 품사는?
관리 대상은 대개 명사로 나타납니다. 동사는 프로세스나 관계의 실마리가 되고 형용사는 속성의 실마리가 되는 경우가 많습니다.
문제 8. 어떤 대상이 엔터티인지 속성인지 헷갈릴 때 판단 기준으로 가장 알맞은 것은?
자신만의 속성을 여러 개 가지고 인스턴스가 여러 건 관리된다면 엔터티입니다. 값 하나로 끝난다면 다른 엔터티의 속성입니다.
문제 9. 부서 코드와 부서 이름만 관리하던 것을 부서장, 설립일, 상위 부서까지 관리하기로 했다면 모델은 어떻게 바뀌어야 하나요?
관리할 속성이 여러 개 생기고 인스턴스가 집합을 이루면 그것은 더 이상 속성이 아니라 엔터티입니다. 컬럼을 붙이면 사원마다 같은 부서 정보가 중복됩니다.
문제 10. 엔터티를 지나치게 잘게 쪼개면 나타나는 문제로 가장 알맞은 것은?
쪼갤수록 중복은 줄지만 조인이 늘어납니다. 어디까지 쪼갤지는 업무 의미와 사용 방식을 함께 보고 정하는 판단의 문제입니다.
묶음 3
문제 1. 다음 중 엔터티로 잡기에 가장 부적절한 것은?
화면은 데이터를 보여 주는 창구이지 관리 대상 집합이 아닙니다. 화면을 엔터티로 잡으면 모델이 프로세스를 따라가 흔들립니다.
문제 2. 코드성 엔터티를 따로 두는 가장 큰 이유는?
코드 목록을 한곳에 두면 허용된 값만 들어가고 이름이 바뀌어도 한 번만 고치면 됩니다. 조인은 오히려 늘어나지만 그 대가로 일관성을 얻습니다.
문제 3. 엔터티의 인스턴스가 시간이 지나면서 성질이 달라지는 경우, 예를 들어 가망 고객과 실제 고객처럼 나뉜다면 모델링에서 고려할 방법으로 가장 알맞은 것은?
속성과 관계가 대부분 같다면 한 엔터티에 상태를 두는 편이 낫고, 서로 다른 속성이 많다면 나누는 편이 낫습니다. 정답이 하나로 정해진 문제가 아니라 판단의 문제입니다.
문제 4. 다음 설명 중 옳지 않은 것은?
관계는 있어야 하지만 개수가 정해져 있지는 않습니다. 관계가 하나뿐인 엔터티도 얼마든지 정상입니다.
문제 5. 이력을 관리해야 하는 엔터티에서 흔히 나타나는 특징으로 가장 알맞은 것은?
같은 대상이 시점마다 다른 값을 가지므로 대상 식별자만으로는 한 건을 특정할 수 없습니다. 그래서 시작일 같은 시점 속성이 식별자에 합류합니다.
문제 6. 엔터티를 도출한 뒤 검증할 때 확인할 항목으로 가장 거리가 먼 것은?
성능은 물리 설계에서 다루는 항목입니다. 논리 단계의 검증은 업무 필요성과 집합으로서의 자격에 집중합니다.
문제 7. 다음 중 사건 엔터티에서 특히 신경 써야 하는 설계 요소로 가장 알맞은 것은?
사건은 계속 쌓입니다. 언제 일어났는지를 정확히 남기고 얼마나 오래 보관할지를 정해 두지 않으면 나중에 손댈 수 없는 크기가 됩니다.
문제 8. 업무 담당자가 상품 관리 대장이라고 부르는 문서를 보고 엔터티를 도출할 때 가장 알맞은 접근은?
현업 문서는 여러 집합이 한 장에 섞여 있는 경우가 많습니다. 상품과 재고와 입출고가 한 대장에 있다면 세 엔터티로 나뉘어야 합니다.
문제 9. 엔터티 통합을 검토할 때 통합하지 않는 편이 나은 경우로 가장 알맞은 것은?
통합하면 서로 상관없는 속성이 대부분 비어 있는 테이블이 됩니다. 공통이 적고 고유가 많다면 나누어 두는 편이 읽기도 쉽고 제약도 걸기 쉽습니다.
문제 10. 엔터티 정의가 모호할 때 가장 먼저 생기는 실무 문제는?
정의가 흐리면 입력 기준이 흐려집니다. 어떤 건은 들어가고 비슷한 건은 다른 곳에 들어가면서 나중에는 집계조차 믿을 수 없게 됩니다.