Conceptual Data Modeling Basics

 

 

 

 

 

 

 

 

 

 

 

 

 

 

개념적 데이터 모델링(Conceptual Data Modeling)은 개체-관계 모델링(Entity-Relationship Modeling) 기법을 이용하여 업무요구사항의 개념적 모델을 생성하는 단계
업무상 알 필요가 있거나 보관한 필요가 있는 중요한 데이터와 각 데이터 간의 관계를 정의하고 모델링함

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Conceptual Data Model

데이터베이스 설계 과정에서 우리는 현실 세계에 존재하는 무수히 많은 개체(entity)들 중 데이터베이스에 저장할 대상들을 추출하여 이를 추상화 시킨 개념으로 표현하게 됨
이 과정을 개념적 모델링(Conceptual Modeling)이라고 함
가장 대표적인 개념적 데이터 모델은 개체-관계 모델(Entity-Relationship Model)

 

 

Logical Data Model

개념적 데이터 모델은 컴퓨터(DBMS)가 직접 이해할 수 없기 때문에 다시 컴퓨터가 이해하고 처리할 수 있는 구조로 변환시켜야 하는데 이 변환 과정을 논리적 데이터 모델링(Logical Data Modeling)이라고 함
일반적으로 개념적 데이터 모델은 DBMS나 데이터베이스 구현 방식과 독립적이지만 논리적 데이터 모델은 DBMS의 종류 및 데이터베이스 구조와 밀접한 관련을 가지게 됨

 

 

 

 

 

 

 

 

 

개념적 데이터 모델링

전산화의 대상인 업무에서 실제로 저장하고 관리해야 할 필요가 있는 중요한 정보가 무엇인지 도식화해내는 과정
이 단계에서 생성한 개념적 데이터 모델은 시스템으로 구현될 때에 어떤 하드웨어나 소프트웨어를 사용하느냐에 따라 영향을 받지 않음
개념적 데이터 모델은 구현 환경에 대하여 독립적이어야 하며 따라서 이후 구현 단계에서 다양한 방법으로 구현될 수 있는 가능성이 있음
예를 들어, 같은 개념적 데이터 모델이 계층형 데이터베이스나 네트워크형 데이터베이스로 구현될 수도 있고 관계형 데이터베이스로 구현될 수도 있는 것
이러한 변환은 데이터베이스 설계 단계에서 이루어지게 됨

 

 

 

Entity-Relationship Model (E-R Model)

객체-관계 모델(Entity-Relationship Modeling, E-R Modeling)은 개념적 데이터 모델링 단계에서 사용되는 대표적인 데이터 모델
E-R model은 E-R diagram (ERD)으로 표현될 수 있음
이는 업무요구사항에 따른 데이터와 데이터 간의 관계 구조를 표현하는 수단으로 사용됨

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

E-R model은 시스템 분석 과정 중 생성되며, 업무 명세나 설명으로부터 도출된다.

 

 

 

 

 

Benefits of ER Modeling

• 조직에 명확한 양식으로 문서화된 정보를 제공
• 정보 요구사항의 범위에 대한 명확한 정보을 제공
• 데이터베이스 설계를 위해 이해하기 쉬운 도면을 제공
• 여러 가지 응용 프로그램을 통합하기 위한 효과적인 구조(framework)을 제공

 

 

 

 

 

 

 

 

 

 

 

Entity

Entity란 업무의 대상으로서 알 필요가 있으며 보관할 필요가 있는 중요한 정보를 의미

보통 명사형으로 나타나고 사물의 범주나 유형이 될 수 있음

Entity는 여러 개의 occurrence(혹은 instance)를 가질 수 있음

예를 들어 부서, 직원, 주문 등은 entity가 될 수 있으며, 부서 entity는 ‘영업부’, ‘마케팅부’, ‘관리부’, ‘교육부’ 등의 occurrence로 나타날 수 있음

 

 

 

Attribute

Attribute는 entity를 기술하는 구체적인 정보로서 entity를 식별하거나 계량화시키거나 상태를 나타낼 수 있는 모든 항목을 말함

예를 들어 직원 entity의 attribute는 사번, 이름, 직급, 입사일, 월급 등이 될 수 있음

각각의 attribute는 꼭 필요한 항목일 수도 있고 그렇지 않은 항목일 수도 있음

이 특성을 optionality라고 함

 

 

 

Relationship

Relationship은 entity 간의 관계를 나타내는 것으로 업무에서 요구되는 정보들을 연결하는 업무규칙을 의미

Unique Identifiers (UID) Unique identifier는 entity의 각 occurrence를 식별하기 위해 사용되는 attribute나 relationship의 조합을 말함

Entity의 모든 occurrence는 유일하게 식별이 가능해야 함

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Entity

Entity의 이름은 단수형의 유일한 이름을 사용하며 대문자로 씀

동일한 entity에 대해 사용되는 다른 이름(synonym)이 있는 경우에는 괄호 안에 역시 대문자로 씀

 

 

 

Attribute

Attribute의 이름은 단수형을 사용하며 소문자로 씀

모든 occurrence에서 꼭 필요한 attribute일 경우에는 이름 앞에 ‘*’를, 그렇지 않은 attribute인 경우에는 ‘o’를 붙여줌

 

 

 

Unique Identifier (UID)

UID를 구성하는 각 attribute 이름 앞에 ‘#’을 붙여줌

Secondary UID인 경우에는 ‘(#)’을 붙여줌

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Relationship은 양방향으로 나타나며 각 방향 별로 다음의 구성요소를 가짐

• Label : 예를 들어 ‘assigned to’, ‘composed of’
• Optionality : ‘must be’ 또는 ‘may be’ •Degree (Cardinality) : ‘one and only one’ 또는 ‘one or more’

 

 

 

 

 

 

 

 

 

 

 

Relationship은 아래와 같은 방식으로 읽음

 

첫 번째 ERD

• Each EMPLOYEE must be assigned to one and only one DEPARTMENT.
• Each DEPARTMENT may be composed of one or more EMPLOYEEs.

 

두 번째 ERD

• Each COURSE may be taken by one or more STUDENTs.
• Each STUDENT may be enrolled in one or more COURSEs

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Relationship 세 가지 유형

• Many-to-One (M : 1) : 고객과 영업사원, 부서와 직원
• Many-to-Many (M : M) : 환자와 간호사, 주문과 상품, 학생과 수강과목
• One-to-One (1 : 1) : 자전거와 자전거 선수, 신랑과 신부

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

M : M 관계에서는 두 entity의 relationship으로부터 발생하는 attribute를 어느 entity에 포함시킬 것인가가 모호하다.

이러한 문제는 설계 단계에 들어가기 전에 해결해 주어야만 한다.