엔터티

엔터티는 업무에서 관리할 필요가 있는 사람·장소·사물·사건·개념을 데이터로 표현한 대상입니다. 엔터티의 각 사례는 인스턴스, 그 사례를 설명하는 항목은 속성입니다.

엔터티는 업무에서 필요하고, 둘 이상의 인스턴스를 가지며, 각 인스턴스를 구별할 속성이 있고, 다른 엔터티와 관계를 맺을 수 있어야 합니다. 업무 규칙에 따라 예외가 있을 수 있으므로 정의를 기계적으로 적용하지 않습니다.

엔터티는 개념·논리 모델에서 정의하고 물리 모델에서는 보통 테이블로 구현합니다. 그래서 설계 단계의 엔터티와 실제 테이블을 완전히 같은 말로 쓰지는 않습니다. 공연 예매 서비스라면 관객, 공연, 예매가 관리 대상입니다. 관객 엔터티의 관객번호·관객명·가입일은 속성, 관객번호 A01인 관객 한 명은 인스턴스, 그 사람의 관객명 이도윤은 속성값입니다.

이 표에는 관객 인스턴스가 3건 있습니다. 관객번호는 각 인스턴스를 구별하는 식별자 역할을 하고, 관객명은 같은 이름이 여러 명에게 있을 수 있어 보통 식별자로 적합하지 않습니다.

시험에서는 위 표의 다섯 가지 특징을 앞 글자를 따서 업·식·인·속·관으로 외웁니다. 특히 인스턴스 2개 이상, 속성 2개 이상, 다른 엔터티와 관계라는 표현을 자주 묻는데, 이는 엔터티를 판단하는 모델링 기준입니다. 테이블을 만들자마자 데이터가 2행 이상 있어야 한다는 DBMS 제약이 아닙니다. 반대로 식별자도 속성도 없이 이름만 있는 대상은 엔터티가 될 수 없습니다.

엔터티 분류는 하나의 정답표가 아니라 서로 다른 기준으로 같은 대상을 바라보는 방법입니다. 존재 형태와 발생 시점의 분류 기준을 섞지 않는 것이 중요합니다.

발생 시점 분류에서 기본 엔터티는 다른 엔터티에 기대지 않는 핵심 관리 대상, 중심 엔터티는 기본 엔터티로부터 업무 중심에서 발생하는 대상, 행위 엔터티는 두 개 이상의 엔터티가 연결되며 생기는 상세 기록입니다. 업무가 진행될수록 계속 쌓이므로 양이 가장 많고 변경이 잦은 것은 행위 엔터티입니다. '개념 엔터티'는 유무형 분류의 항목이라 발생 시점 분류에는 없습니다.

고객과 서비스처럼 M:N 관계를 풀려고 둔 서비스이용 같은 교차(관계) 엔터티는 양쪽 엔터티와 모두 관계를 맺습니다. 어느 쪽과도 관계가 없는 독립 엔터티가 아닙니다.

엔터티 분류는 업무 규칙과 모델의 상세 수준에 따라 달라질 수 있으므로, 이름만 보고 기계적으로 정하지 않습니다.

엔터티명은 업무에서 사용하는 용어로 정하고, 약어를 쓰지 않으며, 단수형 명사를 사용합니다. 모델 안에서 이름이 유일해야 하고, 생성 의미대로 이름을 붙입니다. 각 엔터티는 인스턴스를 유일하게 식별할 기준을 가져야 합니다.

엔터티를 구분할 때는 업무 목적, 인스턴스의 생명주기, 속성의 성격을 함께 봅니다. 단순히 화면이나 프로그램 단위로 테이블을 나누면 업무의 의미가 흐려질 수 있습니다.

공연 예매 담당자가 '이도윤이 밤의 재즈를 예매했고, 같은 관객이 오후의 현악도 예매했다'처럼 문장만 기록한다고 합시다. 관객 이름과 공연 제목이 예매마다 반복되면, 이름이나 공연 정보를 고칠 때 여러 기록을 찾아 바꿔야 할 수 있습니다.

이 문장에서 관객, 공연, 예매라는 서로 다른 관리 대상을 뽑아낼 수 있습니다. 관객 정보는 관객 엔터티에, 공연 정보는 공연 엔터티에 두고, 예매 엔터티는 어떤 관객이 어떤 공연을 예매했는가라는 사실을 기록하면서 두 대상의 식별자를 외래키(FK)로 연결합니다.

엔터티를 나눈다고 기록 수가 꼭 줄어드는 것은 아닙니다. 달라지는 점은 관객과 공연의 고유 정보를 각자 한 곳에서 관리하고, 예매에는 연결을 나타내는 식별자와 예매 자체의 속성만 남긴다는 것입니다.