4.1 모델링의 기본 개념

복잡한 고객의 요구를 시스템의 목적과 무관한 부분을 제거시켜 가면서 우리 의 관심 부분에만 집중시켜 나가는 일련의 과정을 추상화하고 한다. 현실 세계의 복잡한 문제를 추상화 과정을 통하여 최대한 단순하게 만드는 능력이 가장 크게 요구된다고 할 수 있다. 이렇게 추상화된 실세계의 요구를 컴퓨터가 이해하기 쉬운 수학적인 방법으로 표현하는 것이 모델링이다.

제조실행시스템

4.1.1 엔티티, 관계, 속성

모델링은 엔티티를 정의하는 것으로 시작해서 속성을 정의하는 것으로 마무리된다. 엔티티, 관계, 속성은 데이터 모델링에서 사용하는 기본적인 용어임으로 그 의미를 정확히 이해하는 것이 중요하다.

 

엔티티(Entity)

엔티티란 "데이터베이스 내에서 표현되는 작은 세계의 실체"라고 할 수 있다. 엔티티는 의미 있는 유용한 정보를 제공하기 위해 관리하는 데이터로서 물리적으로 존재하지 않는 개념적인 것(예를 들어 사람, 사물, 장소, 개념, 사건 등)을 포함한다. 엔티티는 영속적으로 존재하는 단위이기도 하다.
 
실세계에서는 제품정보, 고객정보와 같이 물리적인 실체를 가진 것과 고객의 주문내역과 같이 물리적인 실체가 없는 개념적인 것 들도 존재한다. 이러한 실세계를 컴퓨터가 관리할 수 있는 데이터베이스라는 작은 세계로 옮겨 놓을 때 제품정보, 고객정보, 주문내역 같은 것들을 표현한 것이 엔티티(Entity)이다. 

엔티티의 특징

① 구축하고자 하는 시스템을 통해 사용자가 관리하고자 하는 업무정보여야 한다. 아무리 좋은 정보라도 구축하고자 하는 시스템에 맞지 않거나 사용자가 관리하기를 원하지 않는다면 엔티티가 될 수 없다.
② 식별자에 의해 유일한 엔티티로의 식별이 가능해야 한다. 즉, 각각의 엔티티가 유일한 식별자에 의해 구분될 수 있어야 한다. 따라서 도출된 엔티티가 식별자에 의해 오직 한 개씩만 존재하는지 확인해보아야 한다.
③ 엔티티는 속성을 가지고 있어야 한다. 속성이 없는 엔티티는 업무분석이 부족하여 속성이 누락되었다고 볼 수 있다.
④ 엔티티와 엔티티 간에는 최소 한 개 이상의 관계가 있어야 한다. 그러나 실제 모델링을 하다 보면 관계가 없는 엔티티가 발생한다. 주로 코드성의 엔티티는 너무나 많은 관계를 가짐으로써 이를 생략하는 경우가 있고 통계 등의 업무를 위해 추가되는 집계성의 읽기 전용 엔티티들에서도 관계를 생략하는 경우가 많기 때문이다.

엔티티의 수집 및 분류

① 엔티티가 될 가능성이 있는 모든 대상을 수집한다.
② 너무 깊게 생각하지 말고 엔티티 자격 유무만 판단하도록 한다.
③ 비슷한 동의어가 있더라도 함부로 버리지 말고 후보로 수집한다.
④ 개념을 확실하게 파악해 두는 것이 중요하다. 너무 일반적이고 상식적이라고 쉽게 생각하지 말아야 한다. 사람마다 서로 다른 의미로 받아들일 수 있으므로 의미를 명확히 해두는 것이 좋다. 또한 일단 엔티티 대상으로 선정했다면 그 핵심적인 특징을 파악해 두는 것이 중요하다.
⑤ 프로세스나 예외 경우에 너무 집착하지 말아야 한다. 기본적인 업무 프로세스에 중점을 두어 수집하도록 한다.
⑥ 사용자의 설명에 의존하지 말고 자신의 이해를 바탕으로 엔티티를 수집해야 한다.
⑦ 항상 자신이 구현할 시스템의 본질을 생각해야 한다. 후보로 선정된 엔티티들의 분류가 끝났다면 수집되고 분류된 엔티티의 후보들이 모두 엔티티가 될 수 있을지 엔티티의 선정 기준과 검증을 통해 최종 엔티티를 확정해야 한다.

엔티티의 검증과 확정

① 수행하는 업무의 영역을 구분한다.
② 각 업무 영역에 존재하는 유일한 식별자를 도출한다.
③ 각 업무에서 사용하는 서식 및 장표, 업무기술서, 인터뷰 내용으로부터 명사를 도출한다.
④ 기존의 정보시스템이 있다면 기존 시스템을 분석하여 엔티티 정보를 참조할 수 있다.
⑤ 회사의 마스터플랜, 중장기계획, 전략을 고려하여 시스템의 확장이 가능하도록 엔티티를 선정한다.
⑥ 개념이 불분명한 것과 광범위한 것은 제거한다.
⑦ 중복되거나 포괄적인 명사는 제거한다.
⑧ 엔티티의 특성이나 속성에 해당하는 명사는 제거한다.
⑨ 누락된 엔티티는 없는지 유추해 본다.

 

관계(Relationship)

관계란 하나 이상의 엔티티 간에 존재하는 연관성으로 해당 실체와 관련된 업무가 수행되는 규칙으로부터 정의된다. 또한 관계는 두 개의 엔티티 사이의 논리적인 관계, 즉 엔티티와 엔티티가 존재의 형태나 서로에게 영향을 주는 형태를 말하기도 한다.

관계의 표현

① 마름모꼴 또는 실선을 이용하여 엔티티 간에 관계를 표시한다. 요즘은 마름모 대신 대부분 실선을 이용한다.
② 연결된 엔티티 간의 관계에 따라 적당한 관계명을 부여한다. 관계명은 가능한 구체적으로 표현하며 관계 내용을 양방향으로 표시한다.
③ 일반적이거나 애매모호한 관계명은 사용하지 않도록 한다.
④ 누구나 이해할 수 있는 일반적이고 객관적인 용어를 사용한다.

관계의 기수성과 선택성

관계의 기수성이란 두 개의 엔티티 간 관계에서 참여자의 수를 표현하는 것을 말한다. 즉, 특정 실체와 관련된 대상 실체의 최대 인스턴스의 수를 의미한다. 가장 일반적인 기수성 표현방법은 1:1, 1:M, M:N의 관계이다.

 

속성(Attribute)

속성이란 "업무에 필요한 엔티티 내에서 관리하고자 하는 항목들로 더 이상 분리되지 않는 최소의 데이터 단위"라 말할 수 있다. 엔티티는 두 개 이상의 어커런스(Row)가 존재하고 각각의 어커런스는 고유의 성격을 표현하는 속성 정보를 한 개 또는 그 이상 가질 수 있다.

속성의 분류

① 기본속성(Basic): 업무로부터 도출된 기본적인 속성을 말한다. 엔티티에 가장 일반적이고 많은 속성을 차지한다. 기본속성의 예로는 제품 엔티티의 제품코드, 제품명, BOM, 라우팅 등이 있다.
② 설계속성(Designed): 업무에 필요한 데이터 이외에 데이터 모델링을 위해 업무를 규칙화하려고 속성을 새로 만들거나 변형하여 정의하는 속성을 말한다. 즉, 설계자의 필요에 의해 만들어지는 속성들이 여기에 속한다. 설계속성의 예로는 주로 내부관리용 코드들이 있다. 
③ 파생속성(Derived): 다른 속성에 영향을 받아 발생하는 속성으로서 보통 계산 등의 가공처리에 의해 생성되는 값을 말한다. 기존에 존재하는 원본(Raw) 속성의 값을 읽어서 Sum, Count, Min, Max, First, Last, Average 등의 연산을 통해 생성되는 속성이다. 데이터의 조회 시간을 단축하기 위해서지만 데이터 정합성을 맞춰야 하는 부가적인 부하가 필요해 조회 속도가 문제가 되지 않는 한 사용하지 않는 것을 원칙으로 해야 한다.

속성의 명명 방법

① 해당 업무에서 사용하는 이름을 부여하도록 한다.
② 의미가 명확하고 내용을 함축성 있게 표현하도록 한다.
③ 서술식의 속성 이름은 너무 길어 사용하지 않도록 한다.
④ 약어 사용은 가급적 피하도록 한다.
⑤ 엔티티에서 유일하게 식별 가능하도록 지정한다.
⑥ 엔티티명을 속성명으로 사용하지 않는다.
⑦ 속성명 부여에 대한 표준을 마련하여 사용토록 한다.
⑧ 가능한 복합명사를 사용하여 의미를 보다 명확히 표현하도록 한다.