[컴][책] Data Architecture Solution

Data Architecture Solution / 데이터 구조

ITA Information Technology architecture (정보기술구조)

ITA 는 아래 3가지로 구성
  1. Enterprise architecture(전사적 구조)
    • Business Architecture
      • Business Process
      • Information Flows and Relationships : 정보의 흐름, 어디서 생성, 언제 업데이트 언제 폐기 되는 등의 관리 기준, 방법, 절차 등.
    • Data Architecture
      • Data Descriptions and Relationships : 무엇이 데이터이고, 그 데이터간의 관계는 어떻고 등의 이야기. 하지만 요즘의 시대에는 Information 이 곧 data 가 되는 사회라서, 과연 이것을 분리하는 것이 의미가 있는지 모르겠다.
    • Application Architecture
      • Applications : 실질적으로 data 를 이용하고, business 를 수행하는 주체이다. 구체적인 어플리케이션은 변동이 있을 수 있어, 그보다 상위의 application 의 기능에 대한 이야기 들을 주로 정립하는 것이라 보면 된다.
    • Technical Architecture
      • Technology Infrastructure : 물리적 계층 이라고 볼 수 있다. 실질적으로 사용하게 될 기술들에 대한 이야기를 적는다.
  2. Technical Reference Model(기술참조 모델)
  3. Standards Profile(표준 프로파일) : 기술참조모델 을 구현하기 위한 IT 표준들
ITA 에서 Enterprise architecture 를 만들기 위해 기술적인 부분이 정의돼야 하는데, 그것과 관련해서 참고해서 사용하는 것이 Technical Reference Model 이다. 즉 Technical Reference Model 에서는 기능에 대해 구체적인 동작? 을 적는다고 보면 된다. 이러이러한 기능이 가능해야 한다. 등 이 Model 을 좀 더 구체적으로 구현하기 위해서 현재의 기술들 중에 적합한 것을 선정할 것이고, 그 기술들에 대한 스펙 같은 것(profile) 을 모아 놓은 것이 Standard Profile 이 된다.
ITA 는 다음 5가지 를 충족할 수 있도록
  • 구조적
  • 시스템화
  • 구체적
  • 데이터화
  • 전문화
요약하면 시스템을 잘 만들어서, 전문화 하자. 인데, 이것을 위한 상위단계인 설계부분(architecture 를 설계하는) 부분도 포함하는 이야기를 하는 것.

Zachman 쟈크만 프레임워크, ITA framework

  1. Scope(Contextual), Planner
    • 먼저 아주 개괄적인 기획
    • 대략적으로 특정 business 에 대해서 구분 짓는다. ‘상품’, ‘사람’, 등
  2. Enterprise Model(Conceptual), Owner
    • 그 다음 기업에서 사용할 모델, 여기까지는 컨셉이다.
    • Contextual 에서 찾은 것을 이제 여러 entity 로 구체화한다. ‘사람’ 에 해당하는 ‘사원’, ‘고객’ 등에 대해서 어떤 종류의 사원이 있는지, 고객이 있는지 등에 대해 정의한다.
    • 여기부터는 DB modeling 이라고 여기면 될 듯 하다.
    • 다만 좀 더 핵심적인 entity 에 집중한다.
  3. System Model(Logical), Designer
    • 기업모델을 좀 더 세밀하게 논리적으로 표현
    • 각 entity 의 속성등을 표현. 특정 사람이 어떤 속성을 가져야 위에서 정의한 Conceptual 을 표현할 수 있는지 고려하고, 그에 맞게 속성, 관계등을 정의하면 된다. 이부분은 db table 의 column 을 정의하고, relationship 등을 정의하는 것등을 생각하면 될 듯 하다.
  4. Technology Model(Physical), Builder
    • 기술적 모델, 시스템 모델을 구현
    • 실질적으로 logical 에서 정의한 내용들을 RDBMS 등에서 table, index, key 등을 이용해서 정의한다.
  5. Detailed Representaions(Out of Context), sub contractor
    • 실질적인 구현, 흔히 프로그래머등이 액션하는 부분
프로그래머들이 어떻게 만들것인가 를 설계하는 과정에는 Enterprise Model, System Model, Technology Model 이 함께 고민된다고 보면 될 듯 싶다.
이미 data 가 존재하고 있는 상황에서는 ITA framework 를 revese engineering 을 통해 현재의 model 을 알아낸다. 그후에 이것을 다시 수정해 나간다.

Data architecture

이 책에서 설명하는 Data Architecture 는 위에서 이야기한 ITA framework 인 ‘쟈크만 프레임워크’ 의 구조를 그대로 가져온다.

Contextual Model

  • 4가지
    • 데이터 영역(Data Area)
    • 데이터 클래스(Data Class)
    • 인터렉션(Interaction)
    • 아티클 (Article) : data object 가 갖는 속성의 set
  • 데이터 영역을 구체화 한것이 Data Class
  • Interaction 도 Data Area 가 될 수 있다.
    • ‘계약’ 같은 데이터는 interaction 이면서 data 이다.
    • 어렵게 생각치 않아도 된다. 그저 db 에 저장할 만한 일인가를 판단하면 된다.
  • 개괄적인 개념이라서, 하위개념에 존재하는 모든 것들에 대한 추상화가 되어 있지 않아도 괜찮다.
    • (me: 하지만, 추후에 하위개념에서 추상적개념이 없던 것이 발생한다면, 관련된 추상화를 찾아서 추가하는 것도 고려해 보는 것도 좋을듯 싶다.)

Conceptual Model

  • Logical Modeling 과 비슷하다. 다만 대상을 핵심 entity 로 제한한다.

Logical Model

  • 데이터 모델링 이라고 보면 된다.
  • 본질적 내용을 중심으로 ‘형상화’, ‘체계화’
  • entity, relationship, attribute 를 정의하는 것
  • ERD 를 통해 표현할 수 있다.

Physical Model

  • ERD 등으로 표현되어진 ‘데이터 모델링’ 의 내용을 구체화 하는 단계다.
  • 예를 들면 RDBMS 등의 table 등의 schema 등을 만드는 것 처럼 구체적으로 구현한다.

Out-of-Context

  • 모델링에 대한 상세한 내역, description 등을 적는다.

계층간 Alignment

  • 현재 계층의 entity 가 상위 계층의 어느 부분을 구현한 것인가, 어떻게 상위 element 가 align 되었는지를 나타내는 것.

See Also

References

  1. Data Architecture Solution

댓글 없음:

댓글 쓰기