데이터를 생각해본다.
Entity라는 개념에서 핵심이 되는 것을 뽑아보니, 러프하게 2가지 형태를 띄고 있다.
1) 스스로가 데이터로서 존재하는 것
2) 1번과 같은 엔티티 간의 관계가 발생하여 존재하는 것
더 간단하게 이야기하자면 데이터는 어찌보면 존재와 존재의 연결이라는 셈이다.
그 존재가 사람일 수도 있고, 사물일 수도 있고, 무형의 어떤 것일 수도 있다.
하지만 현실에서 존재는 그저 스스로 존재한다는 것에 가치를 부여하기 어려운 것처럼 Relation에 대한 것도 스스로는 존재하지 않지만 중요한 요소가 된다.
따라서 존재와 존재의 관계는 어느 것이 중요하다고 가치를 더 두기가 어려워 보인다.
좋아.
그럼 존재와 존재의 관계는 우위를 두는 개념이 아니다.
서로 필요로 하고 있어야 하는 것이다.
Entity로 정의할 수 있는 항목은 그럼 이처럼 존재와 존재의 관계를 통해서 반드시 있어야만 하는 것이다.
Entity는 존재하는 어떤 현실적인 것 혹은 직접적으로 존재하지 않지만 관계와 같은 추상적인 개념을 통해서 존재한다고 보이는데,
이 Entity의 구성은 그 자체로 하나의 독립적인 그룹을 이룬다는 것을 볼 수 있다.
Attributes 라는 Entity를 구성할 수 있는 속성이 그 안에 있으므로 Entity는 하나의 존재로 있을 수 있게 해준다.
그럼, Attribute 하나 하나는 Entity 내에서 중복되지 않는 속성이어야 하고, Entity의 존재의 일부로써 가치가 있는 것이어야 한다.
아무튼 생각해보니 그렇다.
회원과 상품은 스스로 존재하고, 회원이 상품 구매를 신청하면 주문이라는 관계가 생성된다.
회원의 고유의 회원번호를, 상품은 고유의 상품번호를 가지고 있었고 이 고유의 정보는 등록된 시점에서 볼 때 중복될 수 없는 불변의 값이다.
주문은 회원이 상품을 주문할 때 발생하는 관계의 정보를 담고 있고, 이 관계 역시 생성되는 시점에서 고유한 정보를 포함하여 생성된다.
이 주문의 고유한 불변의 값을 부여하기 위해서 주문번호를 생성하고, 이 주문번호는 고객의 불변 정보와 상품의 불변 정보를 참조한다.
주문을 통해서 어떤 회원이 어떤 상품을 구매하려고 하는 지 알 수 있게 된다.
Relation이 생성된 Entity는 의미를 가지게 된다.
프로세스가 생성되어 하나 이상의 flow를 가지게 되는데, 이 관계의 주어와 목적어가 되기도 하고 자신을 참조하기도 하고 혹은 주어를 더 자세하게 나열하게도 한다.
책에서 보여지듯이 관계를 일대일, 일대다, 다대다, 혹은 스스로의 참조 등 많은 관계가 있다.
이 관계의 연결이 일부는 보이는 것일 수 있고, 보이지 않는 관계(혹은 참조)일 수도 있다.
사실 여기까지는 그냥 의식의 흐름에 따라서 쉽게 접근할 수 있었다.
사전 지식이나 모델링 경험이 없는 상태에서 여러 개의 상품을 하나의 주문에 담는다는 생각 혹은 그 것이 어떻게 구현이 되어야 바른 접근인가에 대한 생각은 해보지 못했다.
조금 생각해보니 주문 내에 상품의 정보와 수량, 색상, 사이즈, 기타 정보를 한 번에 담는건 그다지 좋은 생각이 아님에 분명하다.
주문상세를 따로 두어서 하나의 주문 안에 주문상세 정보를 통해서 어떤 상품들이 어떤 조건으로 구매 신청이 되었는 지 따로 저장하고, 변경이 가능하도록 하는 것이다.
(설명을 듣고 어떻게 구현하는 지 알게된 후)
여기서 관계는 사실 주문 하나가 생성되지만, 이 관계 내의 복잡한 조건들을 자세하게 혹은 정확하게 표현하려면 이에 대한 별도의 관계에 대한 상세가 필요하게 되는 것이다.
길게 생각하기가 힘들어져서 뭔가 읽어보면서 좀 더 정리해야 할 듯...
이후의 길은 다른 누군가가 만들어 놓은 문법적인 구성과 체계, 사례의 접근 등으로 이뤄져야 할 것 같음.
으...