DA#2 DA# 다중 물리모델 설계 시스템이 하나의 DB에만 국한되어 있지 않고 여러 개의 DB에 걸쳐져 있는 경우가 더러 있다. 대부분 물리 모델을 별도로 생각하기 어렵기 때문에 각각의 모델을 관리하곤 한다. DA#에서는 어떻게 할지 생각해보자. 아래와 같은 논리 모델에서 프로젝트에 대한 것은 오라클에서 관리하고 있고 요구사항은 별도의 MYSQL 에서 관리한다고 가정하자. 물리 모델을 표현하기 위해 각각의 DBMS 를 추가하였다. 하지만 실제로 관리되는 것은 ORALCE과 MYSQL 에서 일부만 각각 관리되는 것으로 실제와 다른 모습으로 표현되고 있다. 이것 표현하기 위해 여러가지 방법이 있을 수 있겠지만 그 중 한가지를 생각해보면 각 DBMS 에 있는 엔터티만을 모델을 설계 하여 관리한다. 이 경우에는 DMBS와 무관한 전체 논리 모델.. 2016. 7. 2. DA# 3리버스 개발회사에서 담당의 특성상 이런 저런 테스트를 많이 한다. DA# 또한 업무상 필요하기도 하고 때마침 베타테스터로 활동하게 되어 긍정적으로 사용 중이다. 딱히 버그는 아니지만 개선사항들이 많이 눈이 들어온다. 하지만 1단계 목표는 버그 레포팅. 마지막 다 끝나고 나서는 개인적으로 의견을 보내야겠다. 이번주에는 사용중인 솔루션들의 데이터베이스 테이블들을 리버스하면서 살펴 보았다. 아쉽게도 문제시 될 수 있어 올리지는 못한다. 물리모델은 DA#의 리버스를 통해서 쉽게 했지만 의외로 논리모델을 역으로 만들기란 너무 어려웠다. 솔루션들처럼 특히 메타시스템이 없고 이미 물리모델로 풀어버린 상태에서는 더욱 그러했다. Mysql 를 저장소를 사용하는 Wordpree를 리버스해보자. DA#에서는 주로 ODBC를 사용하.. 2016. 6. 18. 이전 1 다음
