이래저래 바쁜일은 없는데 공부하기 싫어서 게을러 졌습니다.. 다시 열심히 합니다!!
데이터 모델링의 이해관계자
실제 업무시스템을 구축하는 실전 프로젝트에서는 DB를 전문적으로 하는 DBA(DataBase Administrator)가 데이터 모델링을 전적으로 하는 경우는 잘 없고 응용시스템 개발자가 데이터 모델링을 같이 한다고 합니다. 왜냐하면 데이터 모델링은 DB설계 측면보다는 업무를 이해하고 분석하여 표현하는 것이 중요하고 다른 프로젝트 관련자와 의사소통하기 위한 일을 수행하기 때문입니다. 따라서 많은 시간을 업무를 군석하고 설계하는데 할애하는 성격상 업무영역별 개발팀에서 보통 모델링을 수행합니다.
--> 정보 세스템을 개발 한다고 할 때 데이터 모델링, DB구축, 구축된 데이터의 적절한 활용은 다른 어떤 일보다 중요하다.
프로젝트에 참여한 모든 IT 기술자들은 데이터 모델링에 대해 정확하게 알고 있어야 합니다. 또 IT 기술 비전공자라도 해당 업무에서 정보화를 추진하는 위치에 있는 사람은 데이터 모델링에 대한 개념 및 세부사항에 대해 어느정도의 지식을 가지고 있어야 합니다.
데이터 모델의 표기법인 ERD(Entity-Relationship-moDel)
Peter Chen이 만들었고 엔티티-사각형, 관계-마름모, 속성-타원 으로 표현. 대학교재에서 가장 많이 쓰이지만 실무적으론 잘 안쓰인다고 합니다. 우리는 IE(Information Engineering)랑 바커 표기법으로 배웁니다.
ERD는 각 업무분석에서 도출된 엔티티와 엔티티간의 관계를 이해하기 쉽게 다이어그램으로 표시하는 방법 입니다.실제 업무에서도 데이터의 흐름과 프로세스오의 연관성을 이야기하는 데 가장 중요한 표기법 입니다.
UML 표준 표기법을 사용하는 오브젝트 모델링 - 적절한 클래스다이어그램
정보공학 모델링 - ERD
오브젝트 모델링 - 관계형 DB를 위한 데이터 모델링 생성
데이터 분석이 어느정도 완료되면 엔티티, 관계, 속성 등이 데이터사전이나 각종 산출물에 의해 분석된 상태에서 ERD를 그리는것이 워낼 이론적인 작업 방법이나 실제 프로젝트 에서는 분석된 엔티티와 관계, 속성정보가 바로 ERD에 표현된다.
ERD 를 그리는 것은 데이터 모델을 누구나 공통된 시각으로 파악할 수 있고 의사소통을 원활하게 하는 장점이 있다. 최근에는 전문 데이터 모델링 툴을 활용하여 ERD를 그리게 되므로 엔티티와 관계를 바로 표현하는 방식으로 진행 하기도 한다.
ERD 작업 순서
1) 엔티티 그림: ERD는 엔티티와 엔티티 사이의 관계가 있는 정보를 나타내므로 두개를 이용하여 작성한다.
2) 엔티티 배치: 왼쪽 상단에 중요한 엔티티를 배치하고 이를 기준으로 나열하면서 전개.
3) 관계 설정: 초기에는 Primary Key로 속성이 상속되는 식별자 관계를 설정. 중복관계와 Circle관계가 발생하지 않도록
유의해야 한다.
4) 관계명 기술: 현재형을 사용하고 지나치게 포괄적인 용어는 사용하지 않도록 한다.
5) 관계의 참여도 기술: 엔티티내의 인스턴스들이 얼마나 관계에 참여하는지 관계차수를 표현. IE표기법으로 작성.
6) 관계의 필수여부 기술
좋은 데이터 모델의 요소
1) 완전성: 업무에서 필요로 하는 모든 데이터가 데이터 모델에 정의되어 있어야 한다.
2) 중복배제: 하나의 DB 내에 동일한 사실은 하 번만 기록.
3) 업무규칙: 데이터 모델링 과정에서 도출되고 규명되는 수많은 업무규칙을 데이터 모델에 표현하고 모든 사용자가 공 유할 수 있도록 제공해야 한다. 논리 데이터 모델에서 이러한 요소들이 포함 되도록 한다.
4) 데이터 재사용: 데이터의 통합성과 독립성에 대해 충분히 고려해야 한다. 데이터가 애플리케이션에 대해 독립적으로 설계 되어야만 데이터 재사용성을 향상시킬 수 있다.
5) 의사소통: 데이터모델에 기술된 업무 규칙들을 보고 의사소통 한다.
6) 통합성: 가장 바람직한 데이터 구조의 형태는 동일한 데이터는 조직의 전체에서 한번 만 정의되고 이를 여러 다른 영 역에서 활용하는 것이다.