XML 사고를 사용하여 데이터를 구성하는 방법에 대한 자세한 소개(그림)

서문

시대가 변했습니다.

과거 데이터에 대한 모든 족쇄가 인터넷으로 인해 하나씩 풀린 것 같지만, IT 실무자로서 사용자에게 필요한 데이터와 얻고자 하는 수단을 제공하는 것이 우리의 임무입니다. 과거에 우리가 우려했던 사용자 인터페이스의 변화, 애플리케이션 간 호출의 변화, 애플리케이션의 내부 로직의 변화, 점점 빨라지는 속도 등 다양한 변화를 견딜 수 있어야 하지만, 가장 근본적인 변화 - 데이터 자체의 변화.

관계

모델

은 정보세계를 2차원 표로 설명하라고 하는데, 책을 보면 너무 '불' 자연스럽습니다. 곧 시작될 프로젝트의 집 꾸미기 계획과 작업 내역을 2차원 테이블로 정리하는 것도 적절하지 않은 것 같습니다. "엔티티-관계"는 급변하는 환경에서 항상 필요할 것이며 "데이터-애플리케이션-프런트 엔드 상호 작용"의 일련의 변화를 수반하며 종종 몸 전체에 영향을 미칩니다. 많은 신세대 애플리케이션이 새로운 트렌드에 더 적합한 솔루션인

XML

을 찾은 것 같습니다. 애플리케이션과 사용자 경험을 우리 자신의 생각에 더 가까운 방식으로 구성합니다. 그렇다면 기업의 경우 데이터를 정리하는 비교적 기본적인 작업도 XML 사고를 사용하여 수행할 수 있습니까? 작동해야합니다. 데이터 엔터티 자체의 변경 사항에 대처

디자인 패턴

을 사용하든 다양한 패턴을 사용하든 데이터 엔터티는 항상 애플리케이션의 가장 안정적인 부분으로 간주되어 왔습니다. 오픈 소스 개발 프레임워크(이러한 프레임워크 자체 포함)는 모두 애플리케이션 자체의 변경 사항에 적응하려고 노력하고 있습니다. 그렇다면 실제 상황은 어떻습니까? l 교환해야 하는 데이터 개체는 우리 자신과 파트너의 필요에 따라 자주 변경됩니다.

l 파트너가 제공하는 데이터 개체는 자주 변경됩니다.

l SOA 및 Enterprise 2.0 개념이 도입되면서 데이터 개체 자체가 여러 소스에서 매시업되고 데이터 개체 자체도 반복적으로 조합되고 결합됩니다.

l 비즈니스가 더욱 정교해짐에 따라 우리 직원들은 점점 더 풍부하고 자세한 정보를 얻기를 바랍니다.

따라서 과거에는 필요와 디자인에 따라 가장 먼저 수정되어야 하는 데이터 개체가 점점 더 많아지고 있습니다. 기술 분야에서 더욱 민첩해지고 비즈니스 현상 유지를 위해서는 지속적인 조정이 필요합니다. 이 요구 사항에 적응하기 위해 우리는 위에서 아래로 시작하여 애플리케이션 자체의 유연성을 지속적으로 조정할 수 있습니다. 또 다른 방법은 "루트"에서 이 문제를 처리하고 이러한 변화에 지속적으로 적응할 수 있는 새로운 데이터 모델을 채택하는 것입니다. , 예: XML 데이터 모델 및 XML 관련 기술 제품군.

예를 들어, 사용자 엔터티를 정의할 때 처음에는 다음 정보로 충분합니다. 여기서 ICustomer는 애플리케이션이 사용할 사용자

인터페이스

이고 CUSTOMER는 관계형 데이터베이스 모드의 표현입니다. 는 XML입니다.

그러나 우리는 사용자의 사무실 전화번호, 집 전화번호를 추가해야 하기 때문에 이 엔터티 디자인에 몇 가지 문제가 있음을 발견했습니다. , 그리고 가능하다면 1. 2 이메일, 그의 MSN 또는 Skype 번호 등. 다른 문제와 상관없이 관계형 모델 카테고리 1의 요구사항만 토대로 RDBMS와 XML의 두 가지 모델을 개발한 결과는 다음과 같습니다.

단지 "고객" 데이터 엔터티 끝의 "연락처 정보"만 변경된 것일 뿐 관계형 모델과 XML 모델의 적응성에는 매우 큰 차이가 있음을 쉽게 알 수 있습니다. 관계형 모델은 새로운 관계형 용도를 지속적으로 확장해야 합니다. 지속적으로 정제된 데이터 엔터티를 설명하기 위해 XML 모델 자체의 계층적 특성은 변화하는 조건에서 자체적인 지속적인 확장을 제공할 수 있습니다. 실제 프로젝트에서도 '학력', '경력' 등의 정보에 비슷한 문제가 존재하는데, 관계 모델에서는 고객이 특정 단계에서 '파견' 방식을 추가하고 싶어도 찾게 된다. 해당 필드는 예약되어 있어서 "work unit" 필드에 문자열 로 넣어야 하고, 그 뒤에 "(secondment)" 가 와야 하는 것과 같습니다. 비즈니스 의미론에 포함된 정보는 이를 하위 노드 또는 속성 으로 설명할 수 있으므로 데이터 모델 자체가 데이터를 삭제합니다. 업무 경험, 연락처 정보)는 관계형 모델에 포함되어 데이터 개체 내부에 집중되며, 각 개체 자체의 확장된 정보(예: "근무 모드": 파견, 교환, 단기 집중) 등도 가능합니다. 데이터 엔터티 내부에 설명되는 동시에 "고객" 엔터티 자체는 외부 응용 프로그램에서 볼 수 있습니다. 여전히 엔터티이므로 실제 비즈니스 시나리오에 더 가까운 데이터 엔터티를 사용하면 외부 변화에 보다 효과적으로 적응할 수 있습니다. .

위에서 논의한 것은 하나의 데이터 개체일 뿐입니다. 특정 비즈니스 도메인 모델로 더 발전할 때 비즈니스 기능을 완성하기 위해 여러 데이터 개체를 동시에 통합해야 하는 경우가 많습니다. 예를 들어, 보험 정책에 따라 고객은 위의 정보 외에도 개인 건강 정보, 자녀, 부모 및 파트너의 주요 가족 정보를 제공해야 하며 동시에 사용자의 신용 정보는 다른 기관에서 수집됩니다. 엔터티 조합은 주로 기업 내에서 사용됩니다. 다양한 응용 분야가 있으므로 데이터 사용 측면에서 응용 프로그램 부분을 최대한 안정적으로 만들기 위해서는 데이터 엔터티가 안정적인 것이 가장 좋지만 연락처 정보 부분만 사용하면 됩니다. 사용자 정보 중 일부는 반복적으로 변경될 수 있습니다. 따라서 애플리케이션이 이러한 변경 요소의 조합에 전적으로 의존하는 경우 결과적으로 애플리케이션의 안정성을 보장하기가 어렵습니다. 따라서 소스에서 첫 번째 단계는 이를 보장하는 것입니다. 다양한 애플리케이션은 가능한 한 특정 엔터티에만 의존합니다. 이는 효과적인 개선을 위한 첫 번째 단계일 수 있습니다. 이때 XML의 계층적 특성의 장점이 다시 드러납니다. 예를 들어 이 정보를 다음과 같이 자유롭게 결합할 수 있습니다. 다양한 애플리케이션 테마에 적용:

이러한 방식으로 애플리케이션은 통합된 엔터티를 직면하고 그에 따라 사용합니다. 전용 XML 기술을 사용하면 새로운 서비스가 동적으로 응답할 수 있습니다. 애플리케이션 프레임워크는 변경되지 않은 채로 데이터 엔터티를 변경합니다.

데이터와 콘텐츠의 통합에 대한 대처

위에서 언급한 데이터 엔터티는 중앙화된 맥락에서 더 많이 논의되지만, 개념 설계 외에도 사용되는 다른 측면도 있습니다. 일반적으로 데이터세트를 통해 달성되는 이러한 정보를 함께 "수집"하는 방법입니다.

(다만 '아키텍처'라는 단어가 남용되는 것처럼 '데이터 통합' 역시 여러 제조사에서 BI 등 각자의 제품 특성을 바탕으로 서로 다른 개념을 조합한 것으로 정의하고 있다벤더들은 이를 ETL과 동의어로 표현하려고 노력합니다. 데이터 교환 플랫폼을 제공하는 벤더들은 이를 BizTalk Framework를 구현하는 제품으로 설명합니다. 기업의 데이터 통합은 효과적인 거버넌스를 전제로 데이터 서비스 제공을 보장하는 방법에 관한 것입니다. 또한 일부 제조업체의 경우 데이터 통합에는 비즈니스 의미 조합 등도 포함됩니다.)그러나 사용자로서 우리는 어떤 문제에 집중해야 할까요?

l 데이터 개체의 관계 매핑

l 다양한 교환 프로토콜, 산업 데이터 표준 및 보안 제어 제약 조건에 따른 데이터 소스 상호 연결

l 데이터 교환 프로세스

l 데이터 개체의 검증 및 재구성,

l 데이터 미디어 및 데이터 매체의 변환

이론적으로 이러한 작업을 코딩으로 완료하는 것은 문제가 되지 않습니다. 기업 통합 로직이 점점 더 복잡해지고, 점점 더 빠르게 변화함에 따라, 1:N 통합에 대응하기 위해 코드를 수정하더라도, M:N 상황인 경우가 많으면 부족할 것입니다. 더 간단한 방법이 있나요? "매핑"의 논리적 수준에서 말하면:

l

객체 지향

사고는 우리에게 반전에 의존하고, 구체성보다는 추상화에 의존하려고 노력한다는 것을 의미합니다. 엔터티 유형보다 l 디자인 패턴에서는 호환되지 않는 인터페이스 어댑터(Adapter)가 좋은 방법이라고 말합니다.

그럼 데이터 분야에도 비슷한 기술이 있나요? XML 스키마 +

XSLT

가 옵션일 수 있습니다.

위는 신규 및 기존 사용자 엔터티와 호환되도록 수행된 변환입니다. 마찬가지로 데이터 엔터티 집계 작업의 위 부분을 수행해야 하는 경우입니다. 다른 주제에 대해서도 XSLT(스키마 간의 적응 관계)를 통해 추상 데이터 정의(스키마) 수준에서 완성됩니다.

이렇게 하면 데이터 개체 수준에서 데이터가 어떻게 집계되는지 알 수 있지만, 그 전에 먼저 해결해야 할 문제가 있습니다: 차량 정보, 신용 정보 및 레거시 시스템 고객 정보는 각각 관계형 데이터베이스와 파트너의 웹 서비스에 저장됩니다. 이 데이터 채널을 연결하는 방법은 무엇입니까? 이제부터 XML은 여전히 ​​좋은 선택입니다.

일반 텍스트, 관계형 데이터베이스, EDI 메시지 또는 SOAP 메시지와 같은 다양한 데이터 매체의 데이터를 원본 형식으로 추출하고 다양한 정보 채널 집계 지점을 통해 데이터 통합으로 전달할 수 있습니다. , 대상 데이터 소스의 필요에 따라 어댑터를 통해 이기종 데이터 소스를 변환합니다.

이때 Point-to-Point 어댑터를 두 가지 유형별로 설계하면 전체 규모가 N^2 수준 추세에 따라 발전하므로 XML로 통합하는 것이 좋습니다. 위에서 소개한 XSLT 기술은 데이터 엔터티 간의 매핑을 수행한 후 XML을 대상 데이터 소스에서 요구하는 형식으로 변환하므로 전체 적응 시스템의 복잡성이 N으로 감소됩니다. 수준.

다음으로 XML 기술이 데이터 통합 ​​필수 요구 사항을 어떻게 충족하는지 살펴보겠습니다.

l 데이터 엔터티, 데이터 미디어 및 데이터 매체 매핑 변환, 데이터 엔터티 검증 및 재구성:

위와 같이 데이터는 먼저 균일하게 XML로 변환된 다음 XML 계층적 이점을 사용하여 처리되고 XML 관련 기술과 결합됩니다.

l 다양한 교환 프로토콜, 산업 데이터 표준 및 보안 제어 제약 조건 하에서 데이터 소스의 상호 연결

XML 데이터는 네트워크와 방화벽을 넘을 수 있을 뿐만 아니라 네트워크에서도 쉽게 사용할 수 있습니다. 인터넷 환경(그러나 여전히 메시지 큐 메소드를 사용하여 메시지로 정의할 수 있음), 데이터 자체는 특수 바이너리 연산으로 인해 교환 프로토콜에 의해 제한되지 않습니다. 현재 다양한 산업 표준에서는 자체 산업 DM(Data Modal)을 설명하기 위해 기본적으로 XML을 사용하고 있습니다. 내부 시스템 자체의 데이터 엔터티가 데이터베이스 설계 및 역사적 유산과 같은 문제로 인해 이러한 DM을 따르지 않더라도 다양한 프로토콜이 사용됩니다. XML 데이터의 통합 관리 표준은 변환을 용이하게 할 수 있습니다. 보안과 관련하여 WS-* 관련 프로토콜보다 인터넷 환경에 더 적합한 보안 표준 제품군은 없는 것 같습니다. 모든 표준은 예외 없이 XML 엔터티를 사용하여 데이터와 추가 보안 메커니즘 간의 결합 관계를 정의할 수 있습니다.

l 데이터 교환 프로세스의 오케스트레이션

동일한 시스템 환경 또는 호환 가능한 미들웨어 시스템에만 기반한 플랫폼의 경우 레거시 워크플로 메커니즘을 사용하여 오케스트레이션을 수행할 수 있습니다. 데이터 교환 프로세스에서는 서비스 지향 시대에 적응하기 위해 보다 일반적인 BPEL 표준을 채택할 수 있습니다. 이때 XML은 데이터일 뿐만 ​​아니라 Java 기술에 비해 실행 명령의 형태로도 나타납니다. , 이는 항상 크로스 플랫폼으로 광고되었습니다. 즉, XML로 정의된 교환 프로세스는 훨씬 더 크로스 언어입니다.

통합으로 많은 문제가 해결된 것 같지만, 분명한 문제는 모든 작업을 직접 구현하고 애플리케이션에 이를 수행하는 방법을 단계별로 알려주어야 한다는 것입니다. 더 이상 웹을 단순히 "새로운 것"으로 간주하지 않고 정보 콘텐츠를 제공하고 상호 작용할 수 있는 시스템으로 생각할 때 이러한 분산된 서비스 기능을 어떻게 우리 자신에게 제시할 수 있습니까? 이 시점에서 아마도 XML의 개방형 메타데이터 정의의 장점이 실제로 드러날 것입니다.

의미 네트워크의 복잡성에 대처

다양한 의미 알고리즘 외에도 분산된 다양한 서비스를 모아서 우리에게 서비스를 제공하는 방법은 XML의 가장 핵심 요소 중 하나를 찾는 것입니다. 데이터 단서의 백본을 파악하고, 이 백본에 있는 개체 간의 관계와 점진적인 분해 및 개선 과정을 명확히 합니다. 이 수준의 데이터는 애플리케이션에서 수동적으로 호출하는 개체일 뿐만 아니라 애플리케이션에서 추가 추론을 위한 지원을 제공합니다. 예:

여기서 애플리케이션은 현재 처리 중인 개체가 거위 고기라는 것을 먼저 학습합니다. 거위 고기는 일종의 가금류 고기(가금류)이므로 가금류 고기는 식용이 가능합니다. 거위고기는 먹을 수 있다는 것을 점차적으로 추론할 수 있습니다. 위의 추론 과정은 복잡하지 않지만, 관계형 데이터베이스를 이용하여 구현하면 상대적으로 복잡해집니다. 일반 텍스트로 작성하면 구현하기가 훨씬 더 어렵습니다. 그리고 해산물은 모두 관계의 관점에서 표현됩니다. 데이터베이스나 텍스트 작성은 실제로 사용하기가 "어렵습니다". XML은 기업 ERP 환경의 생산 자재 준비 과정이든 생일 파티를 위한 요리 준비 과정이든 자연스럽게 우리의 사고 습관에 가까우며 개방적이면서도 서로 얽혀 있는 방식으로 친숙한 의미를 설명할 수 있습니다. 구매 계획을 위해.

요약

아마도 너무 오랫동안 2차원 그리드의 제약으로 인해 우리의 응용 프로그램에 대한 디자인과 아이디어가 컴퓨터 처리 자체에 의해 점점 더 제약을 받고 있지만 비즈니스 환경이 변화함에 따라 비즈니스 요구 사항 발생과 애플리케이션 구현 및 출시 사이의 시간이 점점 짧아지고 있습니다. 이때는 컴퓨터에서 생각을 철회해야 합니다. 우리의 다양한 생각. 데이터가 구현된 후 조직의 경우 다양한 성숙한 기술을 계속 사용하여 데이터를 완성할 수 있지만 보다 가까운 비즈니스 수준과 보다 불안정한 환경에 더 가까워지면 XML이 유연하고 강력해 보입니다.

위 내용은 XML 사고를 사용하여 데이터를 구성하는 방법에 대한 자세한 소개(그림)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!