데이터 모델링

이 문서에서는 다른 문서, 특히 데이터 모델의 범위를 복제합니다. 토크 페이지에서 이 문제를 논의하여 Wikipedia의 스타일 매뉴얼에 맞게 편집하십시오.

소프트웨어 엔지니어링에서 데이터 모델링은 특정 형식 기술을 적용하여 정보 시스템의 데이터 모델을 만드는 과정입니다.

개요

데이터 모델링은 조직 내 대응하는 정보 시스템의 범위 내에서 비즈니스 프로세스를 지원하는 데 필요한 데이터 요건을 정의하고 분석하는 데 사용되는 프로세스입니다.따라서 데이터 모델링 프로세스에는 비즈니스 이해관계자 및 정보 시스템의 잠재적 사용자와 긴밀히 협력하는 전문 데이터 모델러가 포함됩니다.

요구 ^[2]사항에서 정보 시스템에 사용되는 실제 데이터베이스로 진행하면서 생성되는 데이터 모델에는 세 가지 유형이 있습니다.데이터 요건은 처음에는 개념 데이터 모델로 기록되며, 이는 기본적으로 데이터에 대한 기술에 의존하지 않는 사양의 집합이며 비즈니스 관계자와 초기 요건을 논의하는 데 사용됩니다.그런 다음 개념 모델을 논리 데이터 모델로 변환하여 데이터베이스에 구현할 수 있는 데이터 구조를 문서화합니다.하나의 개념 데이터 모델을 구현하려면 여러 논리 데이터 모델이 필요할 수 있습니다.데이터 모델링의 마지막 단계는 논리 데이터 모델을 물리적 데이터 모델로 변환하는 것입니다. 물리적 데이터 모델은 데이터를 테이블로 구성하고 액세스, 성능 및 스토리지 세부 정보를 고려합니다.데이터 모델링은 데이터 요소뿐만 아니라 그 구조와 데이터 요소 ^[3]간의 관계도 정의합니다.

데이터 모델링 기법과 방법론은 데이터를 리소스로 관리하기 위해 표준적이고 일관성 있고 예측 가능한 방식으로 모델링하는 데 사용됩니다.데이터 모델링 표준 사용은 조직 내에서 데이터를 정의 및 분석하는 표준 수단을 필요로 하는 모든 프로젝트(예: 데이터 모델링 사용)에 대해 강력히 권장합니다.

• 비즈니스 분석가, 프로그래머, 테스터, 매뉴얼 라이터, IT 패키지 셀렉터, 엔지니어, 매니저, 관련 조직 및 고객이 조직의 개념과 이들이 서로 어떻게 관련되어 있는지를 포괄하는 합의된 준정식 모델을 이해하고 사용할 수 있도록 지원합니다.
• 데이터를 리소스로 관리하다
• 정보 시스템을 통합하다
• 데이터베이스/데이터 웨어하우스(데이터 저장소라고도 함)를 설계하다

데이터 모델링은 다양한 유형의 프로젝트 중 및 프로젝트의 여러 단계에서 수행될 수 있습니다.데이터 모델은 진보적입니다. 비즈니스 또는 애플리케이션에 대한 최종 데이터 모델은 없습니다.대신, 데이터 모델은 변화하는 비즈니스에 따라 변화하는 살아있는 문서로 간주해야 합니다.데이터 모델은 시간이 지남에 따라 검색, 확장 및 편집할 수 있도록 저장소에 저장해야 합니다.휘튼 등(2004)는 다음 두 가지 유형의 데이터 ^[4]모델링을 결정했습니다.

• 전략적 데이터 모델링:이는 정보 시스템의 전체적인 비전과 아키텍처를 정의하는 정보 시스템 전략 수립의 일환입니다.IT엔지니어링은 이 접근방식을 수용하는 방법론이다.
• 시스템 분석 중 데이터 모델링:시스템 분석에서 논리 데이터 모델은 새로운 데이터베이스 개발의 일부로 작성됩니다.

데이터 모델링은 특정 데이터베이스의 비즈니스 요구사항을 상세하게 설명하는 기술로도 사용됩니다.데이터 모델이 최종적으로 데이터베이스에 ^[4]구현되기 때문에 데이터베이스 모델링이라고도 합니다.

토픽

데이터 모델

데이터 모델은 특정 정의와 형식을 제공함으로써 정보 시스템 내에서 사용되는 데이터의 프레임워크를 제공합니다.데이터 모델을 시스템 전체에서 일관되게 사용하면 데이터의 호환성을 확보할 수 있습니다.동일한 데이터 구조를 사용하여 데이터를 저장하고 액세스하면 서로 다른 애플리케이션이 데이터를 원활하게 공유할 수 있습니다.이 결과는 도표에 나와 있습니다.그러나 시스템과 인터페이스는 구축, 운영 및 유지 보수에 많은 비용이 듭니다.또한 비즈니스를 지원하기보다는 제약할 수도 있습니다.이는 시스템 및 인터페이스에 구현된 데이터 모델의 품질이 낮은 ^[1]경우에 발생할 수 있습니다.

데이터 모델에서 흔히 볼 수 있는 문제는 다음과 같습니다.

• 특정 장소에서 작업을 수행하는 방법에 대한 비즈니스 규칙은 종종 데이터 모델의 구조에서 고정됩니다.즉, 비즈니스 수행 방식의 작은 변화가 컴퓨터 시스템과 인터페이스에 큰 변화를 가져온다는 것을 의미합니다.따라서 비즈니스 규칙은 복잡한 종속성을 초래하지 않는 유연한 방식으로 구현되어야 하며, 데이터 모델은 비즈니스 변경이 데이터 모델 내에서 비교적 빠르고 효율적으로 구현될 수 있도록 충분히 유연해야 합니다.
• 엔티티 유형이 식별되지 않거나 잘못 식별되는 경우가 많습니다.이것에 의해, 데이터, 데이터 구조, 및 기능의 레플리케이션과 개발 및 유지보수의 레플리케이션에 수반하는 코스트가 발생할 가능성이 있습니다.따라서 데이터 정의는 오역 및 중복을 최소화하기 위해 가능한 한 명확하고 이해하기 쉬워야 한다.
• 시스템마다 데이터 모델이 임의로 다릅니다.그 결과 데이터를 공유하는 시스템 간에 복잡한 인터페이스가 필요합니다.이러한 인터페이스는 현재 시스템 비용의 25~70%를 차지할 수 있습니다.데이터 모델을 설계할 때는 필수 인터페이스를 고려해야 합니다.데이터 모델 자체는 다른 시스템 내의 인터페이스가 없으면 사용할 수 없기 때문입니다.
• 데이터의 구조와 의미가 표준화되지 않았기 때문에 고객 및 공급업체와 데이터를 전자적으로 공유할 수 없습니다.구현된 데이터 모델에서 최적의 가치를 얻으려면 데이터 모델이 비즈니스 요구를 충족하고 ^[1]일관성을 유지할 수 있는 표준을 정의하는 것이 매우 중요합니다.

개념, 논리 및 물리 스키마

1975년에 ANSI는 세 가지 종류의 데이터 모델인스턴스를 ^[5]설명했습니다

• 개념 스키마: 도메인의 의미론(모델의 범위)을 설명합니다.예를 들어, 조직이나 산업의 관심 분야 모형일 수 있다.이것은 도메인에서 중요한 종류의 것을 나타내는 엔티티 클래스와 엔티티 클래스 쌍 간의 연관성에 대한 관계 어설션으로 구성됩니다.개념 스키마는 모델을 사용하여 표현할 수 있는 사실 또는 명제의 종류를 지정합니다.그런 의미에서 모델의 범위에 의해 제한된 범위를 가진 인위적인 "언어"에서 허용되는 표현을 정의합니다.간단히 설명하면 개념 스키마는 데이터 요건을 구성하는 첫 번째 단계입니다.
• 논리 스키마: 일부 정보 도메인의 구조를 설명합니다.여기에는 테이블, 열, 객체 지향 클래스 및 XML 태그 등의 설명이 포함됩니다.논리 스키마와 개념 스키마가 하나로 구현되는 경우가 있습니다.^[2]
• Physical schema: 데이터 저장에 사용되는 물리적 수단을 설명합니다.이는 파티션, CPU, 테이블스페이스 등과 관련이 있습니다.

ANSI에 따르면, 이 접근방식은 세 가지 관점이 서로 상대적으로 독립적일 수 있도록 한다.논리 스키마나 개념 스키마에 영향을 주지 않고 스토리지 기술을 변경할 수 있습니다.테이블/컬럼 구조는 (필요한) 개념 스키마에 영향을 주지 않고 변경할 수 있습니다.물론 각각의 경우, 구조는 동일한 데이터 모델의 모든 스키마에서 일관성을 유지해야 합니다.

데이터 모델링 프로세스

비즈니스 프로세스 통합의 맥락에서(그림 참조) 데이터 모델링은 비즈니스 프로세스 모델링을 보완하고 궁극적으로 데이터베이스를 ^[6]생성합니다.

데이터베이스 설계 프로세스에는 앞서 설명한 세 가지 유형의 스키마(개념, 논리 및 물리적)가 포함됩니다.이러한 스키마에 문서화된 데이터베이스 설계는 데이터베이스 생성에 사용할 수 있는 데이터 정의 언어를 통해 변환됩니다.완전히 귀속된 데이터 모델에는 모델 내의 모든 엔티티에 대한 자세한 속성(설명)이 포함됩니다."데이터베이스 설계"라는 용어는 전체 데이터베이스 시스템 설계의 많은 다른 부분을 설명할 수 있습니다.기본적으로 가장 정확하게는 데이터를 저장하는 데 사용되는 기본 데이터 구조의 논리적 설계라고 생각할 수 있습니다.관계형 모델에서는 이러한 표와 뷰가 있습니다.객체 데이터베이스에서 엔티티와 관계는 객체 클래스 및 명명된 관계에 직접 매핑됩니다.그러나 "데이터베이스 설계"라는 용어는 기본 데이터 구조뿐만 아니라 데이터베이스 관리 시스템 또는 DBMS에서 전체 데이터베이스 애플리케이션의 일부로 사용되는 양식 및 쿼리에도 적용될 수 있습니다.

이 과정에서 시스템 인터페이스는 현재 시스템의 개발 및 지원 비용의 25~70%를 차지합니다.이러한 비용이 발생하는 주된 이유는 이들 시스템이 공통 데이터 모델을 공유하지 않기 때문입니다.시스템 단위로 데이터 모델을 개발하면 중복되는 영역에서 동일한 분석이 반복될 뿐만 아니라 이들 간의 인터페이스를 만들기 위해 추가 분석을 수행해야 합니다.조직 내 대부분의 시스템에는 특정 목적을 위해 재개발된 동일한 기본 데이터가 포함되어 있습니다.따라서 효율적으로 설계된 기본 데이터 모델을 통해 조직^[1] 내 다양한 시스템을 위해 최소한의 수정으로 재작업을 최소화할 수 있습니다.

모델링 방법론

데이터 모델은 관심 있는 정보 영역을 나타냅니다.데이터 모델을 작성하는 방법은 다양하지만 Len ^[7]Silverston(1997)에 따르면 두 가지 모델링 방법론만이 눈에 띄었습니다.상하향과 상향입니다.

• 상향식 모델 또는 View 통합 모델은 대개 리엔지니어링 작업의 결과입니다.일반적으로 기존 데이터 구조 양식, 응용 프로그램 화면의 필드 또는 보고서로 시작합니다.이러한 모델은 일반적으로 물리적, 애플리케이션별로 다르며 기업의 관점에서 불완전합니다.특히 조직의 ^[7]다른 부분을 참조하지 않고 구축된 경우에는 데이터 공유를 촉진하지 못할 수 있습니다.
• 반면 하향식 논리 데이터 모델은 대상 영역을 아는 사람들로부터 정보를 얻음으로써 추상적으로 작성됩니다.시스템은 논리 모델의 모든 엔티티를 구현하지 않을 수 있지만 모델은 참조점 또는 ^[7]템플릿 역할을 합니다.

때로는 애플리케이션의 데이터 요구와 구조를 고려하고 주제 영역 모델을 일관되게 참조함으로써 두 가지 방법을 혼합하여 모델을 생성할 수 있습니다.안타깝게도 많은 환경에서 논리적 데이터 모델과 물리적 데이터 모델의 구분이 모호합니다.또한 일부 CASE 툴은 논리적 데이터 ^[7]모델과 물리적 데이터 모델을 구분하지 않습니다.

엔티티-관계도

데이터 모델링에는 몇 가지 표기법이 있습니다.실제 모델은 데이터에 ^[4]기술된 실체와 관계 측면에서 데이터를 묘사하기 때문에 종종 "실체-관계 모델"이라고 불린다.개체-관계 모형(ERM)은 구조화된 데이터의 추상적 개념 표현이다.엔티티-관계 모델링은 소프트웨어 엔지니어링에서 사용되는 관계 스키마 데이터베이스 모델링 방법으로, 시스템의 개념 데이터 모델(또는 의미 데이터 모델)의 한 유형(종종 관계 데이터베이스)과 그 요구사항을 하향식으로 생성하기 위해 사용됩니다.

이러한 모델은 요구 분석 중 정보 시스템 설계의 첫 번째 단계에서 데이터베이스에 저장해야 하는 정보 요구 또는 정보 유형을 설명하기 위해 사용됩니다.데이터 모델링 기법은 특정 담론 영역(관심 영역)에 대한 온톨로지(사용 용어 및 그 관계의 개요와 분류)를 기술하는 데 사용될 수 있다.

데이터 모델 설계를 위해 몇 가지 기술이 개발되었습니다.이러한 방법론은 데이터 모델러의 작업을 안내하지만, 동일한 방법론을 사용하는 두 명의 다른 사용자가 매우 다른 결과를 도출하는 경우가 많습니다.가장 주목할 만한 것은 다음과 같습니다.

• 바흐만 도표
• 바커 표기법
• 첸 표기법
• Data Vault 모델링
• 확장 배커스-나우르 형식
• IDEF1X
• 객체-관계 매핑
• 객체 역할 모델링 및 완전 커뮤니케이션 지향 정보 모델링
• 관계형 모델
• 관계형 모델/작업관리

범용 데이터 모델링

일반 데이터 모델은 기존 데이터 모델의 일반화입니다.이들은 표준화된 일반 관계 유형과 이러한 관계 유형에 의해 관련될 수 있는 종류의 것들을 정의한다.일반 데이터 모델의 정의는 자연 언어의 정의와 유사합니다.예를 들어, 일반 데이터 모델은 개별적인 것과 종류의 것(클래스) 사이의 이진 관계인 '분류 관계'와 같은 관계 유형을 정의할 수 있으며, 하나는 부분의 역할을 가지고 다른 하나는 전체의 역할을 가지고 있는 두 가지 사이의 이진 관계이다.관련지어져 있습니다.

확장 가능한 클래스 목록을 지정하면 개별 항목을 분류하고 개별 개체에 대한 부품-전체 관계를 지정할 수 있습니다.범용 데이터 모델은 확장 가능한 관계형 리스트를 표준화함으로써 무한한 종류의 사실 표현을 가능하게 하고 자연어 능력에 접근한다.반면, 기존 데이터 모델의 인스턴스화(사용)는 모델에 미리 정의된 유형의 사실 표현만 허용하기 때문에 고정적이고 제한된 도메인 범위를 가집니다.

의미 데이터 모델링

계층형, 네트워크형, 관계형 등 DBMS의 논리 데이터 구조는 데이터 개념 정의 요건을 완전히 충족할 수 없습니다.이는 데이터 범위가 제한되고 DBMS가 채택하는 구현 전략에 치우치기 때문입니다.즉, 의미 데이터 모델이 의도적으로 데이터베이스에 구현되지 않는 한 선택입니다.퍼포먼스에 약간의 영향을 줄 수 있지만 일반적으로는 생산성이 크게 향상됩니다.

따라서 개념적 관점에서 데이터를 정의해야 하는 필요성은 의미 데이터 모델링 기술의 개발로 이어졌다.즉, 다른 데이터와의 상호 관계에서 데이터의 의미를 정의하는 기법이다.그림에서 볼 수 있듯이 실제 세계는 리소스, 아이디어, 이벤트 등의 측면에서 물리적 데이터 저장소 내에서 상징적으로 정의됩니다.의미 데이터 모델은 저장된 기호가 실제 세계와 어떻게 관련되어 있는지를 정의하는 추상화입니다.따라서, 모델은 ^[8]실제 세계를 실제로 나타낸 것이어야 합니다.

의미 데이터 모델링의 목적은 Universe of Address라고 불리는 현실 세계의 한 조각의 구조 모델을 만드는 것입니다.이를 위해 네 가지 기본적인 구조적 관계가 고려된다.

• 분류/인스턴스: 구조적으로 유사한 오브젝트는 클래스의 인스턴스로 설명됩니다.
• 집약/분해:구성 객체가 그 부품을 접합하여 얻어진다.
• 일반화/전문화: 몇 가지 공통 속성을 가진 개별 클래스는 공통 속성을 가진 보다 일반적인 클래스로 재검토됩니다.

의미 데이터 모델은 다음과 같은 다양한 목적을 ^[8]위해 사용될 수 있습니다.

• 데이터 리소스 계획
• 공유 가능한 데이터베이스 구축
• 벤더 소프트웨어 평가
• 기존 데이터베이스 통합

의미 데이터 모델의 전체적인 목표는 인공지능 분야에서 알려진 보다 강력한 추상화 개념과 관계 개념을 통합함으로써 데이터의 의미를 더 많이 포착하는 것이다.이 아이디어는 실제 ^[10]상황을 쉽게 표현하기 위해 데이터 모델의 필수 요소로 높은 수준의 모델링 원본을 제공하는 것입니다.

「 」를 참조해 주세요.

• 아키텍처 패턴(컴퓨터 사이언스
• 데이터 모델링 도구 비교
• 데이터(컴퓨팅)
• 데이터 사전
• 문서 모델링
• 엔터프라이즈 데이터 모델링
• 엔티티 데이터 모델
• 정보 관리
• 정보 모델
• 정보 모델링
• 메타데이터 모델링
• 3가지 스키마 어프로치
• 자크만 프레임워크

레퍼런스

• 이 문서에는 미국 국립표준기술연구소 웹사이트 https://www.nist.gov의 퍼블릭 도메인 자료가 포함되어 있습니다.

추가 정보

• J.H. ter Bekke(1991)관계형 환경에서의 시멘틱 데이터 모델링
• 존 빈센트 칼리스, 조셉 D.맥과이어(2001)마스터링 데이터 모델링: 사용자 주도 접근법
• 앨런 추무라, J. 마크 호이만(2005년).논리 데이터 모델링: 그것이 무엇이고 어떻게 하는지.
• 마틴 E.모델(1992)데이터 분석, 데이터 모델링 및 분류.
• M. Papazoglou, Stefano Spaccapietra, Zahir Tari(2000).객체 지향 데이터 모델링의 발전.
• G. 로렌스 샌더스(1995).데이터 모델링
• 그래미 C심시온, 그레이엄 C.위트(2005년).데이터 모델링의 필수 요소'
• Matthew West(2011) 고품질 데이터 모델 개발

외부 링크

• 신속한 변화를 위한 데이터 모델링
• 데이터 모델링 기사
• UML에서의 데이터베이스 모델링
• 데이터 모델링 101
• 의미 데이터 모델링
• Tony Drewry의 시스템 개발, 방법론 및 모델링 노트
• 제안요청 - 객체관리그룹의 정보관리 메타모델(IMM)
• 데이터 모델링은 DBMS Part 1 Chris Bradley만을 위한 것이 아닙니다.
• 데이터 모델링은 DBMS Part 2 Chris Bradley만을 위한 것이 아닙니다.