모델링의 특징
-
추상화
현실 세계를 일정한 형식에 맞추어 표현 -
단순화
복잡한 현실을 제한된 언어나 표기법을 통해 이해하기 쉽게 만든다 -
정확화
애매모호함을 배제하고 누구나 이해 가능하도록 정확하게 현상을 기술
시스템 구현만을 위해 진행하는 사전 단계의 작업.(X)
데이터베이스 구축만을 위한 사전작업의 의미.(X)
시스템 구현을 포함한 업무 분석 및 업무 형상화를 하는 목적도 있다
발생 시점에 따른 엔티티 분류
-
기본/키 엔티티
그 업무에 원래 존재하는 정보
다른 엔티티와의 관계에 의해 성성되는 것이 아니라, 독립적으로 생성이 가능
자신은 타 엔티티의 부모 역할을 하게 된다
다른 엔티티로부터 주식별자를 상속받지 않고, 자신의 고유 주식별자를 갖게 된다
예) 사원 / 부서 / 고객 / 상품 / 자재 -
중심 엔티티
-
행위 엔티티
모델링이 필요한 이유?
- 업무 정보를 구성하는 기초가 되는 정보들을 일정한 표기법으로 표현하기 위해
- 분석된 모델을 가지고 DB를 생성, 개발 및 데이터관리에 사용하기 위해
- 데이터모델링 자체로서 업무의 흐름을 설명하고 분석하는 의미를 가지기 때문에
데이터베이스 구축만을 위한 용도로 데이터모델링을 수행.(X)
업무에 대한 설명은 별도의 표기법을 이용.(X)
업무에 대한 설명(정보)을 일정한 표기법으로 표현하여 업무 내용을 정확하게 분석하는 것이 목적
또한, 분석된 모델을 가지고 DB를 생성하고 개발 및 데이터 관리에 사용
데이터 모델링이란?
- 정보시스템을 구축하기 위한 데이터 관점의 업무 분석 기법
- 현실 세계의 데이터(what)를 약속된 표기법으로 표현하는 과정
- 데이터베이스 구축을 위한 분석 및 설계 과정
데이터 모델링 시 유의점(주의사항)
-
중복
데이터베이스가 여러 장소에 같은 정보를 저장하는 잘못을 하지 않도록 한다 -
비유연성
데이터 모델을 어떻게 설계했느냐에 따라 사소한 업무변화에도 데이터 모델이 수시로 변하게 된다
이에 따라 유지 보수의 어려움을 가중시킬 수 있다
데이터의 정의를, 데이터의 사용 프로세스와 분리함으로써
-> 데이터 혹은 프로세스의 작은 변화가 애플리케이션 및 데이터베이스에 중대한 변화를 일으킬 수 있는 가능성을 줄인다 -
비일관성
데이터의 중복이 없더라도 발생할 수 있다
개발자가 서로 연관된 다른 데이터와 모순된다는 고려 없이 일련의 데이터를 수정할 수도 있다
데이터와 데이터 간의 상호 연관 관계를 미리 명확하게 정의하여 이 문제를 예방하는 데 도움을 줄 수 있다
사용자가 처리하는 프로세스(관련된 프로그램)와 테이블을 연계성을 높이면, 데이터 모델이 업무 변경에 취약점을 가지게 된다
데이터 모델링 개념 분류
-
개념적 데이터 모델링
추상화 수준 높음
업무중심적이며 포괄적
전사적 데이터 모델링
EA 수립 시 많이 사용 -
논리적 데이터 모델링
시스템으로 구축하고자 하는 업무에 대한 Key, 속성, 관계 등을 정확하게 표현
재사용성이 높다 -
물리적 데이터 모델링
실제로 DB에 이식할 수 있또록 성능, 저장 등 물리적 성격을 고려하는 모델링
ANSI-SPARC 데이터베이스 스키마 구조 3단계
-
외부 스키마
-
개념 스키마
통합관점의 스키마 구조를 표현(모든 사용자의 관점을 통합한 조직 전체 관점의 통합적 표현)
모든 응용시스템 또는 사용자들이 필요로 하는 데이터를 통합한, 조직 전체의 DB를 기술한 것 -
내부 스키마
ERD란?
- 피터첸에 의해 만들어졌다
- 일반적으로
엔티티 도출 -> 배치 -> 관계 설정 -> 관계명 기술의 흐름을 가진다 - 관계 명칭은 관계 표현에 있어서 매우 종요하다
가장 중요한 엔티티는 오른쪽 상단에 배치한다.(X)
추가 발생되는 엔티티는 왼쪽 및 하단에 배치한다.(X)
반대임
엔티티의 특징
-
반드시 해당 업무에서 필요하고, 관리하고자 하는 정보여야 한다
(환자, 토익의 응시횟수 등) -
유일한 식별자에 의해 식별이 가능해야 한다
-
영속적으로 존재하는 두 개 이상의 인스턴스의 집합이어야 한다
(= 한 개의 엔티티는 두 개 이상의 인스턴스의 집합이어야 한다) -
업무 프로세스에 이용되어야 한다
-
반드시 속성을 가져야 한다
한 개의 엔티티는 반드시 두 개 이상의 속성을 갖는다 -
다른 엔티티와 최소 한 개 이상의 관계가 있어야 한다
(단, 공통코드, 통계성 엔티티의 경우 관계를 생략할 수 있다)
객체지향의 디자인패턴에는 싱글패턴이 있어, 하나의 인스턴스를 가지는 클래스가 존재한다. 이와 유사하게, 엔티티는 한 개의 인스턴스를 가지는 것만으로도 충분한 의미를 부여할 수 있다.(X)
영속적으로 존재하는 두 개 이상의 인스턴스의 집합이어야 한다
엔티티에 이름 붙이기
- 가능한 한 현업에서 사용하는 용어를 사용
- 가능한 한 약어를 사용하지 말 것
- 단수명사로 표기할 것
- 모든 엔티티를 통틀어 유일한 이름을 부여할 것
- 생성 의미대로의 이름을 부여할 것
가능하면 약어를 사용하여 엔티티의 이름을 간결하고 명확하게 한다.(X)
웬만하면 약어 사용하지 말 것
속성
업무에서 필요로 하는 인스턴스에서 관리하고자 하는, 의미상 더 이상 분리되지 않는 최소의 데이터 단위.
- 사물이나 개념이 어떤 것인지를 나타내고 그것을 다른 것과 구별짓는 성질
- 업무상 관리가 가능한 최소의 의미 단위
- 한 개의 속성은 한 개의 속성값을 갖는다
하나의 인스턴스에서 각각의 속성은 하나 이상의 속성값을 가질 수 있다.(X)
하나의 속성은 하나의 속성값을 갖는다
🤷🏻♂️ ERD가 도식화된 내용은 제외
