close
본문으로 이동

데이터 모델

위키백과, 우리 모두의 백과사전.
Image
데이터 모델링 컨텍스트의 개요: 데이터 모델은 자료, 자료 관계, 자료 의미론 및 자료 제약 조건을 기반으로 한다. 데이터 모델은 저장될 정보의 세부 사항을 제공하며, 최종 제품이 애플리케이션을 위한 컴퓨터 소프트웨어 코드 생성이거나 컴퓨터 소프트웨어의 자체 개발 또는 구매 결정을 돕기 위한 기능 명세서 작성일 때 주로 사용된다. 이 그림은 프로세스와 데이터 모델 간의 상호작용 예시이다.[1]

데이터 모델(data model)은 자료의 요소를 조직화하고, 자료 요소들이 서로 어떻게 관련되는지, 그리고 실세계 엔티티의 속성들과 어떻게 관련되는지를 표준화하는 추상 모델이다.[2][3] 예를 들어, 자동차를 나타내는 자료 요소는 자동차의 색상과 크기를 나타내고 소유자를 정의하는 다른 여러 요소로 구성되도록 데이터 모델에서 지정할 수 있다.

이와 관련된 전문 활동은 일반적으로 데이터 모델링이라 불리며, 더 구체적으로는 데이터베이스 설계라고 한다. 데이터 모델은 보통 데이터 전문가, 데이터 전문가, 데이터 과학자, 데이터 사서 또는 데이터 학자에 의해 정의된다. 데이터 모델링 언어와 표기법은 종종 다이어그램 형태의 그래픽으로 표현된다.[4]

데이터 모델은 특히 프로그래밍 언어의 문맥에서 때때로 자료 구조라고 불리기도 한다. 데이터 모델은 특히 엔터프라이즈 모델의 문맥에서 기능 모델에 의해 보완되는 경우가 많다.

데이터 모델은 자료의 구조를 명시적으로 결정한다. 반대로, 구조화된 데이터(structured data)는 명시적인 데이터 모델이나 자료 구조에 따라 조직된 자료를 말한다. 구조화된 데이터는 비정형 데이터반정형 데이터와 대비된다.

개요

[편집]

데이터 모델이라는 용어는 서로 구별되지만 밀접하게 연관된 두 가지 개념을 가리킬 수 있다. 때로는 특정 응용 도메인에서 발견되는 객체와 관계에 대한 추상적 정형화를 의미한다. 예를 들어 제조 조직에서 발견되는 고객, 제품, 주문 등이 이에 해당한다. 다른 때는 이러한 정형화를 정의하는 데 사용되는 개념의 집합을 의미한다. 예를 들어 엔티티, 속성, 관계 또는 테이블과 같은 개념이다. 따라서 은행 애플리케이션의 "데이터 모델"은 개체-관계 "데이터 모델"을 사용하여 정의될 수 있다. 이 문서는 두 가지 의미 모두로 용어를 사용한다.

대량의 구조화된 데이터와 비정형 데이터를 관리하는 것은 정보 시스템의 주요 기능이다. 데이터 모델은 관계형 데이터베이스와 같은 데이터 관리 시스템에 저장된 자료의 구조, 조작 및 무결성 측면을 설명한다. 또한 워드 프로세서 문서, 전자우편 메시지, 사진, 디지털 오디오 및 비디오와 같이 구조가 느슨한 자료를 설명할 수도 있다. 예를 들어 XDMXML 문서를 위한 데이터 모델을 제공한다.

데이터 모델의 역할

[편집]
Image
데이터 모델이 이점을 제공하는 방식[5]

데이터 모델의 주요 목표는 자료의 정의와 형식을 제공함으로써 정보 시스템의 개발을 지원하는 것이다. 매슈 웨스트(Matthew West)와 줄리언 파울러(Julian Fowler) (1999)에 따르면 "시스템 전반에 걸쳐 일관되게 이 작업이 수행되면 자료의 호환성을 달성할 수 있다. 자료를 저장하고 접근하는 데 동일한 자료 구조를 사용하면 서로 다른 애플리케이션이 자료를 공유할 수 있다. 그 결과는 위에 나타나 있다. 그러나 시스템과 인터페이스는 구축, 운영 및 유지보수에 필요한 비용보다 더 많은 비용이 드는 경우가 많다. 또한 비즈니스를 지원하기보다 제약할 수도 있다. 주요 원인은 시스템과 인터페이스에 구현된 데이터 모델의 품질이 낮기 때문이다".[5]

  • "특정 장소에서 일이 처리되는 방식에 특화된 비즈니스 규칙은 종종 데이터 모델의 구조에 고정된다. 이는 비즈니스 수행 방식의 작은 변화가 컴퓨터 시스템과 인터페이스의 큰 변화로 이어진다는 것을 의미한다".[5]
  • "엔티티 유형이 식별되지 않거나 잘못 식별되는 경우가 많다. 이는 자료, 자료 구조 및 기능의 중복을 초래할 수 있으며, 개발 및 유지보수 시 중복에 따른 비용이 수반된다".[5]
  • "서로 다른 시스템을 위한 데이터 모델이 임의로 다르다. 그 결과 자료를 공유하는 시스템 간에 복잡한 인터페이스가 필요하게 된다. 이러한 인터페이스는 현재 시스템 비용의 25~70%를 차지할 수 있다".[5]
  • "자료의 구조와 의미가 표준화되지 않았기 때문에 고객 및 공급업체와 전자적으로 자료를 공유할 수 없다. 예를 들어, 공정 설비에 대한 엔지니어링 설계 데이터와 도면은 여전히 종이로 교환되는 경우가 있다".[5]

이러한 문제의 원인은 데이터 모델이 비즈니스 요구사항을 충족하고 일관성을 유지하도록 보장하는 표준의 부재에 있다.[5]

데이터 모델은 자료의 구조를 명시적으로 결정한다. 데이터 모델의 전형적인 응용 분야에는 데이터베이스 모델, 정보 시스템 설계 및 자료 교환 활성화가 포함된다. 보통 데이터 모델은 데이터 모델링 언어로 지정된다.[3]

세 가지 관점

[편집]
Image
ANSI/SPARC 3단계 스키마 구조. 이는 데이터 모델이 외부 모델(또는 뷰), 개념 모델 또는 물리 모델이 될 수 있음을 보여준다. 이것이 데이터 모델을 보는 유일한 방법은 아니지만, 특히 모델을 비교할 때 유용한 방법이다.[5]

1975년 ANSI에 따르면 데이터 모델 인스턴스는 다음 세 가지 종류 중 하나일 수 있다.[6]

  1. 개념 데이터 모델: 모델의 범위인 도메인의 의미론을 설명한다. 예를 들어 조직이나 산업의 관심 영역에 대한 모델일 수 있다. 이는 도메인에서 중요한 사물의 종류를 나타내는 엔티티 클래스와 엔티티 클래스 쌍 사이의 연관성에 대한 관계 주장으로 구성된다. 개념 스키마는 모델을 사용하여 표현할 수 있는 사실이나 명제의 종류를 지정한다. 그런 의미에서 모델의 범위에 의해 제한된 범위를 갖는 인공 '언어'에서 허용되는 표현을 정의한다.
  2. 논리 데이터 모델: 특정 자료 조작 기술로 표현된 의미론을 설명한다. 이는 테이블과 열, 객체 지향 클래스 및 XML 태그 등의 설명으로 구성된다.
  3. 물리 데이터 모델: 자료가 저장되는 물리적 수단을 설명한다. 이는 파티션, CPU, 테이블스페이스 등과 관련이 있다.

ANSI에 따르면 이 접근 방식의 의의는 세 가지 관점이 서로 상대적으로 독립적일 수 있게 해준다는 점이다. 저장 기술이 변경되어도 논리 모델이나 개념 모델에 영향을 주지 않을 수 있다. 테이블/열 구조는 개념 모델에 (반드시) 영향을 주지 않고도 변경될 수 있다. 물론 각 경우에 구조는 다른 모델과 일관성을 유지해야 한다. 테이블/열 구조는 엔티티 클래스 및 속성을 직접 변환한 것과 다를 수 있지만, 궁극적으로 개념 엔티티 클래스 구조의 목표를 수행해야 한다. 많은 소프트웨어 개발 프로젝트의 초기 단계에서는 개념 데이터 모델 설계를 강조한다. 이러한 설계는 논리 데이터 모델로 상세화될 수 있다. 나중에 이 모델은 물리 데이터 모델로 변환될 수 있다. 그러나 개념 모델을 직접 구현하는 것도 가능하다.

역사

[편집]

정보 시스템 모델링의 초기 선구적 연구 중 하나는 영(Young)과 켄트(Kent) (1958)에 의해 이루어졌다.[7][8] 이들은 "데이터 처리 문제의 정보적 및 시간적 특성을 지정하는 정밀하고 추상적인 방법"을 주장했다. 이들은 "분석가가 어떤 종류의 컴퓨터 하드웨어 주변에서도 문제를 조직할 수 있게 하는 표기법"을 만들고자 했다. 그들의 연구는 서로 다른 하드웨어 구성 요소를 사용하여 다양한 대안 구현을 설계하기 위한 추상적인 사양과 불변의 기초를 만들려는 최초의 노력이었다. 정보 시스템 모델링의 다음 단계는 1959년에 결성된 IT 산업 컨소시엄인 CODASYL에 의해 이루어졌다. 이들은 본질적으로 영과 켄트와 동일한 목표를 가졌는데, 즉 "데이터 처리 시스템 수준에서 기계 독립적인 문제 정의 언어를 위한 적절한 구조"를 개발하는 것이었다. 이는 특정 정보 시스템 정보 대수의 개발로 이어졌다.[8]

1960년대에는 경영 정보 시스템(MIS) 개념이 시작되면서 데이터 모델링이 더욱 중요해졌다. 레온데스(Leondes) (2002)에 따르면, "그 기간 동안 정보 시스템은 관리 목적을 위한 자료와 정보를 제공했다. Integrated Data Store(IDS)라고 불리는 1세대 데이터베이스 시스템은 제너럴 일렉트릭의 찰스 바크먼에 의해 설계되었다. 이 시기에 두 가지 유명한 데이터베이스 모델인 네트워크 모델계층 데이터 모델이 제안되었다".[9] 1960년대 말에 에드거 F. 코드는 자료 배열에 관한 이론을 정립하고, 1차 술어 논리에 기초한 데이터베이스 관리를 위한 관계형 모델을 제안했다.[10]

1970년대에는 1976년 피터 첸에 의해 처음 정형화된 개체-관계 모델링이 새로운 유형의 개념 데이터 모델링으로 등장했다. 개체-관계 모델은 정보 요구사항이나 데이터베이스에 저장될 정보의 유형을 설명하기 위해 요구사항 분석 기간 동안 정보 시스템 설계의 첫 단계에서 사용되었다. 이 기법은 특정 관심 영역에 대한 모든 온톨로지, 즉 개념과 그 관계의 개요 및 분류를 설명할 수 있다.

1970년대에 G.M. Nijssen은 "Natural Language Information Analysis Method" (NIAM) 방법을 개발했고, 1980년대에 Terry Halpin과 협력하여 이를 Object–Role Modeling(ORM)으로 발전시켰다. 그러나 객체-역할 모델링의 정식 기반을 마련한 것은 테리 핼핀의 1989년 박사 학위 논문이었다.

빌 켄트(Bill Kent)는 1978년 저서 'Data and Reality'에서[11] 데이터 모델을 영토의 지도에 비유하며, 실제 세계에서는 "고속도로가 빨간색으로 칠해져 있지 않고, 강 한복판에 군 경계선이 흐르지 않으며, 산에서 등고선을 볼 수 없다"는 점을 강조했다. 수학적으로 깔끔하고 우아한 모델을 만들려 했던 다른 연구자들과 달리, 켄트는 실제 세계의 본질적인 무질서함과, 진실을 과도하게 왜곡하지 않으면서 혼돈 속에서 질서를 만들어내는 데이터 모델러의 과업을 강조했다.

얀 L. 해링턴(Jan L. Harrington) (2000)에 따르면, 1980년대에 "객체 지향 패러다임의 발전은 자료와 자료에 작용하는 절차를 바라보는 방식에 근본적인 변화를 가져왔다. 전통적으로 자료와 절차는 별도로 저장되어 왔다. 즉, 데이터베이스에는 자료와 그 관계가, 애플리케이션 프로그램에는 절차가 저장되었다. 그러나 객체 지향은 엔티티의 절차와 자료를 결합했다".[12]

1990년대 초, 세 명의 네덜란드 수학자 귀도 바케마(Guido Bakema), 함 반 더 렉(Harm van der Lek), 얀피터 즈바르트(JanPieter Zwart)는 G.M. Nijssen의 연구를 이어 나갔다. 그들은 의미론의 커뮤니케이션 부분에 더 집중했다. 1997년에 그들은 완전 커뮤니케이션 지향 정보 모델링 FCO-IM 방법을 정형화했다.

유형

[편집]

데이터베이스 모델

[편집]

데이터베이스 모델은 데이터베이스가 어떻게 구조화되고 사용되는지를 설명하는 명세이다.

여러 모델이 제안되었다. 일반적인 모델은 다음과 같다.

플랫 모델
이것은 엄밀히 말해 데이터 모델의 자격이 없을 수도 있다. 플랫(또는 테이블) 모델은 자료 요소의 단일 2차원 배열로 구성되며, 여기서 주어진 열의 모든 멤버는 유사한 값으로 간주되고 행의 모든 멤버는 서로 관련이 있는 것으로 간주된다.
계층 모델
계층 모델은 계층 모델의 링크가 트리 구조를 형성하는 반면 네트워크 모델은 임의의 그래프를 허용한다는 점을 제외하면 네트워크 모델과 유사하다.
네트워크 모델
네트워크 모델 또는 그래프 모델은 레코드(records)와 세트(sets)라는 두 가지 기본 구성을 사용하여 자료를 조직한다. 레코드(또는 노드)에는 필드(즉, 속성)가 포함되고, 세트(또는 에지)는 레코드 간의 일대다, 다대다 및 다대일 관계를 정의한다(하나의 소유자, 여러 멤버). 네트워크 데이터 모델은 데이터베이스 구현에 사용되는 설계 개념의 추상화이다. 네트워크 모델은 상호 연결성을 강조하므로 소셜 네트워크나 추천 시스템과 같이 관계가 중요한 애플리케이션에 이상적이다. 이 구조는 비용이 많이 드는 조인(join) 없이 관계를 효율적으로 쿼리할 수 있게 해준다.
관계형 모델
1차 술어 논리에 기초한 데이터베이스 모델이다. 핵심 아이디어는 데이터베이스를 유한한 술어 변수 집합에 대한 술어의 모음으로 설명하고, 가능한 값과 값의 조합에 대한 제약 조건을 설명하는 것이다. 관계형 데이터 모델의 힘은 수학적 기초와 단순한 사용자 수준 패러다임에 있다.
객체-관계 모델
관계형 데이터베이스 모델과 유사하지만, 데이터베이스 스키마와 질의어에서 객체, 클래스 및 상속이 직접 지원된다.
객체-역할 모델링
"속성이 없고(attribute free)" "사실에 기반한(fact-based)" 것으로 정의된 데이터 모델링 방법이다. 결과적으로 검증 가능하게 올바른 시스템이 구축되며, 여기서 ERD, UML 및 의미 모델과 같은 다른 일반적인 산출물을 파생시킬 수 있다. 데이터 객체 간의 연관성은 데이터베이스 설계 절차 중에 설명되므로 정규화는 프로세스의 필연적인 결과가 된다.
스타 스키마
데이터 웨어하우스 스키마의 가장 단순한 스타일이다. 스타 스키마는 임의의 수의 "차원 테이블"을 참조하는 소수의 "사실 테이블"(이름을 정당화하기 위해 보통 하나만 존재함)로 구성된다. 스타 스키마는 눈송이 스키마의 중요한 특수 사례로 간주된다.

데이터 구조 다이어그램

[편집]
Image
데이터 구조 다이어그램의 예

데이터 구조 다이어그램(DSD)은 엔티티와 그 관계, 그리고 이들을 묶는 제약 조건을 문서화하는 그래픽 표기법을 제공함으로써 개념 데이터 모델을 설명하는 데 사용되는 다이어그램이자 데이터 모델이다. DSD의 기본 그래픽 요소는 엔티티를 나타내는 상자와 관계를 나타내는 화살이다. 데이터 구조 다이어그램은 복잡한 데이터 엔티티를 문서화하는 데 가장 유용하다.

데이터 구조 다이어그램은 개체-관계 모델(ER 모델)의 확장이다. DSD에서는 속성이 엔티티 상자 외부가 아니라 내부에 지정되는 반면, 관계는 엔티티를 함께 묶는 제약 조건을 지정하는 속성으로 구성된 상자로 그려진다. DSD는 ER 모델이 서로 다른 엔티티 간의 관계에 초점을 맞추는 반면, DSD는 엔티티 내 요소의 관계에 초점을 맞추고 사용자가 각 엔티티 간의 연결과 관계를 완전히 볼 수 있게 한다는 점에서 차이가 있다.

데이터 구조 다이어그램을 표현하는 여러 스타일이 있으며, 카디널리티를 정의하는 방식에서 현저한 차이가 있다. 선택 사항은 화살표 머리, 역화살표 머리(까마귀 발 표기법), 또는 카디널리티의 수치 표현 등이 있다.

Image
IDEF1X 자체를 모델링하는 데 사용되는 IDEF1X 개체-관계 다이어그램의 예[13]

개체-관계 모델

[편집]

개체-관계 모델(ERM)은 때때로 개체-관계 다이어그램(ERD)으로 불리며, 구조화된 데이터를 나타내기 위해 소프트웨어 공학에서 사용되는 추상적인 개념 데이터 모델(또는 의미 데이터 모델이나 물리 데이터 모델)을 나타내는 데 사용될 수 있다. ERM에는 여러 표기법이 사용된다. DSD와 마찬가지로 속성은 엔티티 상자 외부가 아니라 내부에 지정되는 반면, 관계는 선으로 그려지고 관계 제약 조건은 선 위의 설명으로 표시된다. ER 모델은 강력하지만, 여러 속성을 가진 엔티티를 나타낼 때 시각적으로 번거로울 수 있다.

데이터 구조 다이어그램을 표현하는 여러 스타일이 있으며, 카디널리티를 정의하는 방식에서 현저한 차이가 있다. 선택 사항은 화살표 머리, 역화살표 머리(까마귀 발), 또는 카디널리티의 수치 표현 등이 있다.

지리 데이터 모델

[편집]

지리 정보 시스템에서의 데이터 모델은 지리적 객체나 표면을 자료로 나타내기 위한 수학적 구성체이다. 예를 들어,

  • 벡터 데이터 모델은 지리 정보를 점, 선, 다각형으로 나타낸다.
  • 래스터(raster) 데이터 모델은 수치를 저장하는 셀 매트릭스로 지리 정보를 나타낸다.
  • 그리고 Triangulated irregular network(TIN) 데이터 모델은 지리 정보를 인접하고 겹치지 않는 삼각형의 집합으로 나타낸다.[14]

일반 데이터 모델

[편집]

일반 데이터 모델(Generic data model)은 기존 데이터 모델의 일반화이다. 이들은 표준화된 일반 관계 유형과 그러한 관계 유형에 의해 연관될 수 있는 사물의 종류를 정의한다. 일반 데이터 모델은 기존 데이터 모델의 일부 단점을 해결하기 위한 접근 방식으로 개발되었다. 예를 들어, 서로 다른 모델러는 보통 동일한 도메인에 대해 서로 다른 기존 데이터 모델을 생성한다. 이는 서로 다른 사람들의 모델을 하나로 모으는 데 어려움을 줄 수 있으며 자료 교환 및 자료 통합의 장애물이 된다. 그러나 예외 없이 이러한 차이는 모델의 추상화 수준 차이와 인스턴스화될 수 있는 사실의 종류(모델의 의미론적 표현 능력) 차이로 인해 발생한다. 모델러는 차이를 덜 중요하게 만들기 위해 더 구체적으로 표현될 특정 요소에 대해 소통하고 합의해야 한다.

의미 데이터 모델

[편집]
Image
의미 데이터 모델[13]

소프트웨어 공학에서 의미 데이터 모델(semantic data model)은 다른 자료와의 상호 관계라는 문맥 내에서 자료의 의미를 정의하는 기법이다. 의미 데이터 모델은 저장된 기호가 실제 세계와 어떻게 관련되는지를 정의하는 추상화이다.[13] 의미 데이터 모델은 때때로 개념 데이터 모델이라고도 불린다.

데이터베이스 관리 시스템(DBMS)의 논리적 자료 구조는 계층형, 네트워크, 또는 관계형에 관계없이 자료의 개념적 정의에 대한 요구사항을 완전히 충족할 수 없다. 왜냐하면 범위가 제한되어 있고 DBMS에서 채택한 구현 전략에 편향되어 있기 때문이다. 따라서 개념적 관점에서 자료를 정의할 필요성이 의미 데이터 모델링 기법의 개발로 이어졌다. 즉, 다른 자료와의 상호 관계 문맥 내에서 자료의 의미를 정의하는 기법이다. 그림에서 예시된 것처럼, 자원, 아이디어, 사건 등의 측면에서 실제 세계는 물리적 자료 저장소 내에 상징적으로 정의된다. 의미 데이터 모델은 저장된 기호가 실제 세계와 어떻게 관련되는지를 정의하는 추상화이다. 따라서 모델은 실제 세계를 진실되게 표현해야 한다.[13]

주제

[편집]

데이터 아키텍처

[편집]

데이터 아키텍처는 목표 상태를 정의하고 그 목표 상태에 도달하는 데 필요한 후속 계획을 수립하기 위해 자료를 설계하는 것이다. 이는 대개 엔터프라이즈 아키텍처 또는 솔루션 아키텍처의 기둥을 형성하는 여러 아키텍처 도메인 중 하나이다.

데이터 아키텍처는 비즈니스 및 해당 애플리케이션에서 사용하는 자료 구조를 설명한다. 저장 중인 자료와 이동 중인 자료에 대한 설명, 자료 저장소, 자료 그룹 및 자료 항목에 대한 설명, 그리고 이러한 자료 산출물을 자료 품질, 애플리케이션, 위치 등에 매핑하는 작업이 포함된다.

목표 상태를 실현하는 데 필수적인 데이터 아키텍처는 주어진 시스템에서 자료가 어떻게 처리되고 저장되며 활용되는지를 설명한다. 이는 데이터 흐름을 설계하고 시스템 내의 자료 흐름을 제어할 수 있게 하는 자료 처리 작업의 기준을 제공한다.

데이터 모델링

[편집]
Image
데이터 모델링 프로세스

소프트웨어 공학에서의 데이터 모델링은 데이터 모델링 기법을 사용하여 정식 데이터 모델 설명을 적용함으로써 데이터 모델을 생성하는 프로세스이다. 데이터 모델링은 데이터베이스에 대한 비즈니스 요구사항을 정의하기 위한 기법이다. 데이터 모델은 결국 데이터베이스에 구현되기 때문에 때때로 데이터베이스 모델링이라고도 한다.[16]

그림은 오늘날 데이터 모델이 개발되고 사용되는 방식을 보여준다. 개념 데이터 모델은 개발 중인 애플리케이션의 자료 요구사항에 기반하여 개발되며, 아마도 활동 모델의 문맥에서 이루어질 것이다. 데이터 모델은 일반적으로 엔티티 유형, 속성, 관계, 무결성 규칙 및 해당 객체의 정의로 구성된다. 이것은 인터페이스 또는 데이터베이스 설계의 시작점으로 사용된다.[5]

자료 속성

[편집]
Image
자료의 몇 가지 중요한 속성[5]

요구사항을 충족해야 하는 자료의 몇 가지 중요한 속성은 다음과 같다.

  • 정의 관련 속성[5]
    • 관련성: 의도된 목적이나 응용 분야와 관련된 자료의 유용성.
    • 명확성: 자료에 대해 명확하고 공유된 정의의 가용성.
    • 일관성: 서로 다른 소스에서 온 동일한 유형의 자료 간의 호환성.
  • 내용 관련 속성
    • 적시성: 필요한 시점에 자료를 사용할 수 있는지 여부와 자료가 얼마나 최신인지의 정도.
    • 정확성: 자료가 진실에 얼마나 가까운지.
  • 정의와 내용 모두와 관련된 속성
    • 완전성: 필요한 자료 중 어느 정도를 사용할 수 있는지.
    • 접근성: 자료를 어디서, 어떻게, 누구에게 사용할 수 있게 하거나 할 수 없는지(예: 보안).
    • 비용: 자료를 획득하고 사용 가능하게 만드는 데 드는 비용.

자료 조직

[편집]

또 다른 종류의 데이터 모델은 데이터베이스 관리 시스템이나 다른 데이터 관리 기술을 사용하여 자료를 조직하는 방법을 설명한다. 예를 들어 관계형 테이블과 열, 또는 객체 지향 클래스와 속성을 설명한다. 이러한 데이터 모델은 때때로 물리 데이터 모델이라고 불리기도 하지만, 원래의 ANSI 3단계 스키마 구조에서는 "논리적"이라고 불린다. 해당 구조에서 물리 모델은 저장 매체(실린더, 트랙 및 테이블스페이스)를 설명한다. 이상적으로, 이 모델은 위에서 설명한 더 개념적인 데이터 모델에서 파생된다. 그러나 처리 능력 및 사용 패턴과 같은 제약 조건을 고려하여 달라질 수도 있다.

데이터 분석은 데이터 모델링의 일반적인 용어이지만, 이 활동은 실제로 일반적인 개념에서 구성 개념을 식별하는 분석(analysis)보다는 특정 인스턴스에서 일반적인 개념을 추론하는 종합(synthesis)의 아이디어 및 방법과 더 공통점이 많다. {아마도 시스템 종합가라고 말하는 사람이 없어서 우리 자신을 시스템 분석가라고 부르는 것일 것이다.} 데이터 모델링은 불필요한 자료 중복을 제거하고 자료 구조를 관계로 연결함으로써 관심 있는 자료 구조를 응집력 있고 분리할 수 없는 전체로 묶기 위해 노력한다.

다른 접근 방식은 자료의 암시적 모델을 자율적으로 생성할 수 있는 인공 신경망과 같은 적응형 시스템을 사용하는 것이다.

자료 구조

[편집]
Image
분기형 연결 자료 구조의 단순한 유형인 이진 트리

자료 구조는 컴퓨터에 자료를 저장하여 효율적으로 사용할 수 있도록 하는 방법이다. 이는 자료의 수학적 및 논리적 개념의 조직이다. 종종 신중하게 선택된 자료 구조는 가장 효율적인 알고리즘을 사용할 수 있게 해준다. 자료 구조의 선택은 종종 추상 자료형의 선택에서 시작된다.

데이터 모델은 주어진 도메인 내의 자료 구조를 설명하며, 함축적으로 그 도메인 자체의 하부 구조를 설명한다. 이는 데이터 모델이 사실상 그 도메인을 위한 전용 인공 언어의 전용 문법을 지정함을 의미한다. 데이터 모델은 회사가 정보를 보유하고자 하는 엔티티의 클래스(사물의 종류), 그 정보의 속성, 그리고 그 엔티티들 간의 관계 및 (종종 암시적인) 그 속성들 간의 관계를 나타낸다. 모델은 자료가 컴퓨터 시스템에 어떻게 표현될 수 있는지와 무관하게 어느 정도 자료의 조직을 설명한다.

데이터 모델에 의해 표현되는 엔티티는 실체가 있는 엔티티일 수 있지만, 그러한 구체적인 엔티티 클래스를 포함하는 모델은 시간이 지남에 따라 변하는 경향이 있다. 견고한 데이터 모델은 종종 그러한 엔티티의 추상화를 식별한다. 예를 들어, 데이터 모델에는 조직과 상호작용하는 모든 사람을 나타내는 "사람(Person)"이라는 엔티티 클래스가 포함될 수 있다. 그러한 추상 엔티티 클래스는 대개 그 사람들이 수행하는 특정 역할을 식별하는 "공급업체"나 "직원"이라고 불리는 것보다 더 적절하다.

데이터 모델 이론

[편집]

데이터 모델이라는 용어는 두 가지 의미를 가질 수 있다.[17]

  1. 데이터 모델 이론: 즉, 자료가 어떻게 구조화되고 접근될 수 있는지에 대한 정식 설명.
  2. 데이터 모델 인스턴스: 즉, 특정 애플리케이션을 위한 실질적인 데이터 모델 인스턴스를 생성하기 위해 데이터 모델 이론을 적용하는 것.

데이터 모델 이론은 세 가지 주요 구성 요소를 가진다.[17]

  • 구조적 부분: 데이터베이스에 의해 모델링된 엔티티나 객체를 나타내는 데이터베이스를 생성하는 데 사용되는 자료 구조의 모음.
  • 무결성 부분: 구조적 무결성을 보장하기 위해 이러한 자료 구조에 부여된 제약 조건을 지배하는 규칙의 모음.
  • 조작 부분: 데이터베이스에 포함된 자료를 업데이트하고 쿼리하기 위해 자료 구조에 적용될 수 있는 연산자의 모음.

예를 들어, 관계형 모델에서 구조적 부분은 수정된 수학적 관계 개념에 기반하고, 무결성 부분은 1차 논리로 표현되며, 조작 부분은 관계대수, 튜플 계산도메인 계산을 사용하여 표현된다.

데이터 모델 인스턴스는 데이터 모델 이론을 적용하여 생성된다. 이는 일반적으로 일부 비즈니스 기업의 요구사항을 해결하기 위해 수행된다. 비즈니스 요구사항은 일반적으로 의미론적 논리 데이터 모델에 의해 캡처된다. 이것은 물리적 데이터 모델 인스턴스로 변환되어 여기서 물리적 데이터베이스가 생성된다. 예를 들어, 데이터 모델러는 데이터 모델링 도구를 사용하여 일부 비즈니스 기업의 기업 자료 저장소에 대한 개체-관계 모델을 생성할 수 있다. 이 모델은 관계형 모델로 변환되고, 이는 다시 관계형 데이터베이스를 생성한다.

패턴

[편집]

패턴(Patterns)[18]은 많은 데이터 모델에서 나타나는 일반적인 데이터 모델링 구조이다.

관련 모델

[편집]

데이터 흐름도

[편집]
Image
데이터 흐름도의 예[19]

데이터 흐름도(DFD)는 정보 시스템을 통한 자료의 "흐름"을 그래픽으로 표현한 것이다. 프로그램의 제어 흐름 대신 자료 흐름을 보여준다는 점에서 순서도와 다르다. 데이터 흐름도는 데이터 처리(구조적 설계)의 시각화를 위해서도 사용될 수 있다. 데이터 흐름도는 마틴(Martin)과 에스트린(Estrin)의 계산 "데이터 흐름 그래프" 모델에 기초하여 구조적 설계의 최초 개발자인 Larry Constantine에 의해 발명되었다.[20]

시스템과 외부 엔티티 간의 상호작용을 보여주는 컨텍스트 수준 데이터 흐름도를 먼저 그리는 것이 일반적인 관행이다. DFD는 시스템이 어떻게 더 작은 부분으로 나뉘는지 보여주고 그 부분들 사이의 자료 흐름을 강조하도록 설계되었다. 이 컨텍스트 수준 데이터 흐름도는 이후 모델링되는 시스템의 더 자세한 내용을 보여주기 위해 "확장(exploded)"된다.

정보 모델

[편집]
Image
EXPRESS G 정보 모델의 예

정보 모델(Information model)은 데이터 모델의 한 유형이 아니라, 다소간의 대안적인 모델이다. 소프트웨어 공학 분야에서 데이터 모델과 정보 모델 모두 엔티티 유형의 속성, 관계 및 그에 대해 수행할 수 있는 연산을 포함하는 추상적이고 정식인 표현이 될 수 있다. 모델의 엔티티 유형은 네트워크의 장치와 같은 실제 세계의 사물일 수도 있고, 과금 시스템에서 사용되는 엔티티와 같이 그 자체가 추상적일 수도 있다. 일반적으로 이들은 폐쇄된 엔티티 유형, 속성, 관계 및 연산의 집합으로 설명될 수 있는 제약된 도메인을 모델링하는 데 사용된다.

리(Lee) (1999)에 따르면[21] 정보 모델은 선택된 담론 도메인에 대한 자료 의미론을 지정하기 위한 개념, 관계, 제약 조건, 규칙 및 연산의 표현이다. 이는 도메인 컨텍스트에 대해 공유 가능하고 안정적이며 조직화된 정보 요구사항 구조를 제공할 수 있다.[21] 더 일반적으로 정보 모델이라는 용어는 시설, 건물, 공정 플랜트 등과 같은 개별 사물의 모델에 사용된다. 그러한 경우 개념은 Facility Information Model, 빌딩 정보 모델(Building Information Model), 플랜트 정보 모델(Plant Information Model) 등으로 전문화된다. 그러한 정보 모델은 시설의 모델과 시설에 관한 자료 및 문서를 통합한 것이다.

정보 모델은 설명이 소프트웨어의 실제 구현에 어떻게 매핑되는지 제약하지 않으면서 문제 도메인의 설명에 정형성을 제공한다. 정보 모델의 매핑은 여러 가지가 있을 수 있다. 그러한 매핑은 객체 모델(예: UML 사용), 개체-관계 모델 또는 XML 스키마인지에 관계없이 데이터 모델이라고 불린다.

Image
문서 객체 모델, HTML 또는 XML을 표현하기 위한 표준 객체 모델

객체 모델

[편집]

컴퓨터 과학에서의 객체 모델(object model)은 프로그램이 자신의 세계 중 특정 부분을 조사하고 조작할 수 있게 해주는 객체나 클래스의 모음이다. 다시 말해, 어떤 서비스나 시스템에 대한 객체 지향 인터페이스이다. 그러한 인터페이스를 해당 서비스나 시스템의 객체 모델이라고 한다. 예를 들어, 문서 객체 모델(DOM)웹 브라우저페이지를 나타내는 객체들의 모음으로, 스크립트 프로그램이 페이지를 조사하고 동적으로 변경하는 데 사용된다. 다른 프로그램에서 마이크로소프트 엑셀을 제어하기 위한 마이크로소프트 엑셀 객체 모델이 있으며,[22] ASCOM 망원경 드라이버는[23] 천체 망원경을 제어하기 위한 객체 모델이다.

컴퓨팅에서 객체 모델이라는 용어는 그것들을 사용하는 특정 컴퓨터 프로그래밍 언어, 기술, 표기법 또는 방법론에서 객체의 일반적인 속성이라는 별개의 두 번째 의미를 가진다. 예를 들어 자바 객체 모델, COM 객체 모델, 또는 OMT의 객체 모델 등이 있다. 이러한 객체 모델은 보통 클래스, 메시지, 상속, 다형성캡슐화와 같은 개념을 사용하여 정의된다. 프로그래밍 언어의 정형 의미론의 하위 집합으로서 정형화된 객체 모델에 대한 방대한 문헌이 존재한다.

객체-역할 모델링

[편집]
Image
Stephen M. Richard (1999)의 "지질 표면 스키마"에서 객체-역할 모델링 적용 예시[24]

객체-역할 모델링(ORM)은 개념 모델링을 위한 방법이며, 정보 및 규칙 분석을 위한 도구로 사용될 수 있다.[25]

객체-역할 모델링은 개념 수준에서 시스템 분석을 수행하기 위한 사실 지향적 방법이다. 데이터베이스 애플리케이션의 품질은 설계에 크게 좌우된다. 정확성, 명확성, 적응성 및 생산성을 보장하기 위해 정보 시스템은 사람들이 쉽게 이해할 수 있는 개념과 언어를 사용하여 개념 수준에서 먼저 지정되는 것이 가장 좋다.

개념 설계에는 자료, 프로세스 및 행동 관점이 포함될 수 있으며, 설계를 구현하는 데 사용되는 실제 DBMS는 여러 논리 데이터 모델(관계형, 계층형, 네트워크, 객체 지향 등) 중 하나에 기반할 수 있다.[26]

통합 모델링 언어 모델

[편집]

통합 모델링 언어(UML)는 소프트웨어 공학 분야의 표준화된 범용 모델링 언어이다. 이는 소프트웨어 집약적 시스템의 산출물을 시각화, 지정, 구축 및 문서화하기 위한 그래픽 언어이다. 통합 모델링 언어는 다음을 포함하여 시스템의 청사진을 작성하는 표준 방법을 제공한다.[27]

UML은 기능 모델, 데이터 모델 및 데이터베이스 모델의 혼합을 제공한다.

같이 보기

[편집]

각주

[편집]
  1. Paul R. Smith & Richard Sarfaty Publications, LLC 2009
  2. What is a Data Model?. princeton.edu. 2024년 5월 29일에 확인함.
  3. UML Domain Modeling - Stack Overflow. Stack Overflow. Stack Exchange Inc. 2017년 2월 4일에 확인함.
  4. Michael R. McCaleb (1999). "A Conceptual Data Model of Datum Systems" 보관됨 2008-09-21 - 웨이백 머신. National Institute of Standards and Technology. August 1999.
  5. 1 2 3 4 5 6 7 8 9 10 11 Matthew West and Julian Fowler (1999). Developing High Quality Data Models. The European Process Industries STEP Technical Liaison Executive (EPISTLE).
  6. American National Standards Institute. 1975. ANSI/X3/SPARC Study Group on Data Base Management Systems; Interim Report. FDT (Bulletin of ACM SIGMOD) 7:2.
  7. Young, J. W., and Kent, H. K. (1958). "Abstract Formulation of Data Processing Problems". In: Journal of Industrial Engineering. Nov-Dec 1958. 9(6), pp. 471–479
  8. 1 2 Janis A. Bubenko jr (2007) "From Information Algebra to Enterprise Modelling and Ontologies - a Historical Perspective on Modelling for Information Systems". In: Conceptual Modelling in Information Systems Engineering. John Krogstie et al. eds. pp 1–18
  9. Cornelius T. Leondes (2002). Database and Data Communication Network Systems: Techniques and Applications. Page 7
  10. "Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks", E.F. Codd, IBM Research Report, 1969
  11. Data and Reality
  12. Jan L. Harrington (2000). Object-oriented Database Design Clearly Explained. p.4
  13. 1 2 3 4 FIPS Publication 184 보관됨 2013-12-03 - 웨이백 머신 released of IDEF1X by the Computer Systems Laboratory of the National Institute of Standards and Technology (NIST). 21 December 1993 (withdrawn in 2008).
  14. Wade, T. and Sommer, S. eds. A to Z GIS
  15. 1 2 3 4 David R. Soller1 and Thomas M. Berg (2003). The National Geologic Map Database Project: Overview and Progress U.S. Geological Survey Open-File Report 03–471.
  16. Whitten, Jeffrey L.; Lonnie D. Bentley, Kevin C. Dittman. (2004). Systems Analysis and Design Methods. 6th edition. ISBN 0-256-19906-X.
  17. 1 2 Beynon-Davies P. (2004). Database Systems 3rd Edition. Palgrave, Basingstoke, UK. ISBN 1-4039-1601-2
  18. "The Data Model Resource Book: Universal Patterns for Data Modeling" Len Silverstone & Paul Agnew (2008).
  19. John Azzolini (2000). Introduction to Systems Engineering Practices. July 2000.
  20. W. Stevens, G. Myers, L. Constantine, "Structured Design", IBM Systems Journal, 13 (2), 115–139, 1974.
  21. 1 2 Y. Tina Lee (1999). "Information modeling from design to implementation" National Institute of Standards and Technology.
  22. Excel Object Model Overview
  23. ASCOM General Requirements. 2011년 5월 13일. 2014년 9월 25일에 확인함.
  24. Stephen M. Richard (1999). Geologic Concept Modeling. U.S. Geological Survey Open-File Report 99–386.
  25. Joachim Rossberg and Rickard Redler (2005). Pro Scalable .NET 2.0 Application Designs.. Page 27.
  26. Object Role Modeling: An Overview (msdn.microsoft.com). Retrieved 19 September 2008.
  27. Grady Booch, Ivar Jacobson & Jim Rumbaugh (2005) OMG Unified Modeling Language Specification.