ERD 툴 사이트 - http://www.databaseanswers.org/modelling_tools.htm
데이터 모델링(주요관계)
관계란 두 개의 엔티티타입 사이의 논리적인 관계, 즉 엔티티와 엔티티가 존재의 형태나 행위로서 서로에게 영향을 주는 것을 말합니다. 데이터 모델에서의 관계란 업무의 흐름을 나타냅니다.
관계 패어링
각각의 엔티티들은 자신이 관련된 엔티티들과 관계의 어커런스로 참여하는 형태를 관계 패어링(Relationship Pairing)이라 한다.
예를 들어 영업무에는 홍길동과 방자가 소속되어 있고 경리부에는 성춘향과 향단이가 소속되어 있다면 이와 같이
엔티티와 엔티티 사이에 관계가 설정되어 있는 어커런스를 관계패어링이라고 하며, 엔티티타입은 엔티티의 집합을 논리적으로 편현하였다면 관계는 관계패어링의 집합을 논리적으로 표현한 것이다
관계의 명명
각각의 관계에는 두 개의 멤버십(Membership)이 있다. 또한 각각의 멤버십에 의해 두 가지 관점으로 표현될 수 있다. 멤버십은 엔티티타입이 관계에 참여하는 것을 말합니다.
엔티티타입에서 관계가 시작되는 편을 관계 시작점(The Beginning)이라 하고, 받는 편을 관계 끝점(The End)이라고 한다. 관계 시작점과 끝점 모두 관계 이름을 가져야 하며 멤버십의 성격에 따라 관계 이름이 능동적(Active)이거나 수동적(Passive)으로 명명된다.
관계의 카디낼리티
두 개의 엔티티타입간 관계에서 참여자의 수를 표현하는 것을 카디낼리티(Cardinality)라고 한다. 가장 일반적인 카디낼리티 표현 방법은 1:M, 1:1, M:n이다. 가장 중요하게 고려해야 할 사항은 한 개의 멤버십이 존재하는냐 아니면 두 개 이상의 멤버십이 존재하느냐를 파악하는 것이다.
1:1(One To One)관계를 표시하는 방법
관계에 참여하는 각각의 엔티티는 관계를 맺는 다른 엔티티에 대해 단지 하나의 관계만을 가지고 있다.
예) 한개의 구매신청서에 한 개의 구매주문을 신청하고 한 개의 구매주문에는 한 개의 구매신청 내용을 작성한다.
1:M(One To Many) 관계를 표시하는 방법
관계에 참여하는 각각의 엔티티는 관계를 맺는 다른 엔티티타입의 엔티티에 대해 하나 이상의 수와 관계를 가진다.
그러나 반대 방향은 단지 하나의 관계만 가진다.
예) 한 명의 사원은 한 부서에 소속되고 한 부서에는 여러 사원을 포함한다.
M:N(Many To Many)관계를 표시하는 방법
관계에 참여하는 각각의 엔티티에는 관계를 맺는 다른 엔티티타입의 엔티티에 대해 하나 이상의 수와 관계가 있다. 반대 방향도 동일하게 관계에 참여하는 각각의 엔티티에는 관계를 맺는 다른 엔티티타입의 엔티티에 대해 하나 이상의 수와 관계가 있다.
예) 하나의 주문서에는 여러 개의 제품을 포함할 수 있고, 한 제품은 여러 개의 주문서를 통해 신청 될 수 있다.
관계를 읽는 방법
관계 모델을 읽는 방법은 처음 시작하는 엔티티타입의 참여도를 읽고 그 다음 엔티티타입을 읽고 관계명을 읽습니다.
관계를 읽는 방법으로 프로젝트에 참여한 고객에게 질문 목록을 만들어 질문하는 방법도 업무 분석을 위해 효과적인 방법이다. 예를 들어 주문과 제품 관계를 질문한다면 "한 주문에 대해서 하나의 제품만 주문합니까?"라고 할수 있고 또는 "한제품은 하나의 주문에 대해서만 주문을 접수 받을 수 있습니까?"라고 질문 할수 있습니다. 이러한 질문 방법은 엔티티타입간 관계설정뿐 아니라 업무의 흐름까지 분석되는 효과적인 방법이 됩니다.
출처 - http://blog.naver.com/PostView.nhn?blogId=arithri&logNo=120103050638
===================================================================================
'DB > Common' 카테고리의 다른 글
다중 Primary key 설정 (0) | 2012.03.30 |
---|---|
기본키(Primary Key) 의미 (3) | 2012.03.30 |
데이터베이스 설계 과정 1 (0) | 2012.03.28 |
테이블 설계 시 고려 사항 (0) | 2012.03.17 |
회원 정보 테이블 설계 시 고려 사항 (0) | 2012.03.17 |