으로 Techopedia 직원, 2016 년 9 월 28 일
테이크 아웃 : 호스트 Rebecca Jozwiak가 OSTHUS의 Eric Little, 샌프란시스코 파트너의 Malcolm Chisholm 및 IDERA의 Ron Huizenga와 데이터 아키텍처 솔루션에 대해 설명합니다.
현재 로그인하지 않았습니다. 비디오를 보려면 로그인 또는 가입하십시오.
Rebecca Jozwiak : 신사 숙녀 여러분 안녕하세요, 2016 년 Hot Technologies에 오신 것을 환영합니다. 오늘 우리는 "비즈니스 중심 데이터 아키텍처 구축"에 대해 논의하고 있습니다. 제 이름은 Rebecca Jozwiak입니다. 오늘 웹 캐스트의 호스트가 되겠습니다. 우리는 # HotTech16의 해시 태그로 트윗을하기 때문에 이미 트위터에 있다면 자유롭게 참여해주세요. 언제든지 궁금한 점이 있으면 화면 오른쪽 하단의 Q & A 창으로 보내 주시면 답변을 드릴 것입니다. 그렇지 않은 경우, 우리는 손님이 당신을 위해 그들을 얻을 수 있도록합니다.
오늘 우리는 정말 매혹적인 라인업을 가지고 있습니다. 오늘 우리와 함께 많은 타자들. OSTHUS의 데이터 과학 부사장 인 Eric Little이 있습니다. 우리는 First San Francisco Partners의 최고 혁신 책임자 인 Malcolm Chisholm이 있습니다. IDERA의 선임 제품 관리자 인 Ron Huizenga도 있습니다. 그리고 IDERA는 데이터 관리 및 모델링 솔루션을 제공합니다. 그리고 오늘 그는 그의 솔루션이 어떻게 작동하는지 데모를 보여줄 것입니다. 하지만 에릭 리틀에 도착하기 전에 공을 당신에게 전달할 것입니다.
에릭 리틀 : 네, 감사합니다. 저는 여기서 Ron의 대화와 관련이 있고 몇 가지 Q & A 주제를위한 무대를 마련하기 위해 몇 가지 주제를 살펴볼 것입니다.
따라서 IDERA가하고있는 일에 관심이있는 것은 오늘날 복잡한 환경이 실제로 많은 비즈니스 가치를 창출하고 있다고 정확하게 지적하고 있다는 것입니다. 복잡한 환경이란 복잡한 데이터 환경을 의미합니다. 그리고 기술은 실제로 빠르게 발전하고 있으며 오늘날의 비즈니스 환경에서 유지하기가 어렵습니다. 따라서 기술 분야에서 일하는 사람들은 종종“큰 데이터는 어떻게 사용합니까? 시맨틱을 어떻게 통합합니까? 이 새로운 것들과 오래된 데이터를 어떻게 연결합니까?”그리고 그와 같은 종류의 요즘은 오늘날 많은 사람들이 잘 알고있는이 4 가지 빅 데이터로 우리를 이끌고 있습니다. 때때로 – 나는 여덟 또는 아홉을 보았습니다. 그러나 일반적으로 사람들이 빅 데이터와 같은 것에 대해 이야기하거나 빅 데이터에 대해 이야기 할 때 일반적으로 일종의 엔터프라이즈 규모의 것을보고 있습니다. 사람들은 보통 데이터의 양에 대해 생각할 것입니다. 일반적으로 초점은 바로 당신이 가진 금액입니다. 데이터의 속도는 데이터를 얼마나 빨리 이동할 수 있는지 또는 얼마나 빨리 쿼리하거나 답변을 얻을 수 있는지 등과 관련이 있습니다. 개인적으로 저는 그 왼쪽이 많은 다른 접근 방식으로 비교적 빠르게 해결되고 처리되는 것이라고 생각합니다. 그러나 오른쪽에는 개선을위한 많은 기능과 실제로 새로운 기술이 많이 등장하고 있습니다. 그리고 그것은 실제로 세 번째 열인 데이터 다양성과 관련이 있습니다.
다시 말해, 오늘날 대부분의 회사는 구조적, 반 구조적 및 비 구조적 데이터를보고 있습니다. 이미지 데이터는 인기있는 주제가되기 시작하여 컴퓨터 비전을 사용하고, 픽셀을보고, 텍스트, NLP, 엔티티 추출을 긁을 수 있고, 통계 모델에서 나오거나 의미 론적으로 나오는 그래프 정보가 있습니다. 모델의 경우 테이블에 존재하는 관계형 데이터 등이 있습니다. 따라서 모든 데이터와 이러한 다른 유형을 모두 가져 오는 것은 실제로 큰 도전을 의미하며 Gartner와 업계의 트렌드를 따르는 다른 사람들에게 이러한 문제가 있음을 알 수 있습니다.
그리고 사람들이 빅 데이터에서 이야기하는 마지막 것은 종종 이러한 모호성이라는 개념입니다. 이것은 실제로 데이터의 불확실성, 모호한 것입니다. 데이터에 대한 정보를 얼마나 잘 알고 있는지, 데이터의 내용을 얼마나 잘 이해하고 있습니까? 통계를 사용하는 능력과 알고 있거나 컨텍스트를 사용하는 것에 대한 일부 유형의 정보를 사용하는 능력이 가치가 있습니다. 따라서 보유하고있는 데이터의 양, 데이터를 얼마나 빨리 이동하거나 가져와야하는지, 회사에있을 수있는 모든 유형의 데이터 및 위치에 대한 확실성 측면에서 이러한 방식으로 데이터를 볼 수있는 기능 그것이 무엇인지, 품질이 어떤지 등입니다. 이를 위해서는 데이터를 효과적으로 관리하기 위해 많은 개인간에 대규모의 공동 노력이 필요합니다. 따라서 오늘날 세계에서는 데이터 모델링이 점점 중요 해지고 있습니다. 따라서 우수한 데이터 모델은 실제로 엔터프라이즈 응용 프로그램에서 많은 성공을 이끌고 있습니다.
우리가 말한 것처럼 다양한 소스의 데이터 소스가 있으며 실제로 많은 종류의 통합이 필요합니다. 예를 들어, 여러 유형의 데이터 소스에서 쿼리를 실행하고 정보를 다시 가져올 수 있으면이 기능을 모두 함께 사용하는 것이 매우 유용합니다. 그러나이를 위해서는 훌륭한 매핑 전략이 필요하므로 이러한 종류의 데이터를 매핑하고 이러한 매핑을 유지하는 것은 어려운 과제가 될 수 있습니다. 그런 다음 레거시 데이터를 이러한 모든 새 데이터 소스에 어떻게 연결합니까? 그래프를 가지고 있다고 가정합니다. 모든 관계형 데이터를 가져 와서 그래프에 넣습니까? 일반적으로 좋은 생각이 아닙니다. 그렇다면 사람들이 진행중인 이러한 모든 종류의 데이터 모델을 어떻게 관리 할 수 있습니까? 실제로 이러한 다양한 종류의 데이터 소스 및 조합에서 분석을 실행해야합니다. 따라서 이로부터 나오는 답변, 사람들이 실제로 올바른 비즈니스 결정을 내리는 데 필요한 답변은 매우 중요합니다.
이것은 기술을위한 기술을 구축하는 것이 아니라 실제로 무엇을할지, 어떻게 할 수 있는지, 어떤 종류의 분석을 수행 할 수 있는지, 따라서 이미 해왔 던 능력입니다. 이 물건들을 하나로 모으고 그것을 통합하는 것은 정말 정말 중요합니다. 그런 다음 이러한 유형의 분석 중 하나는 연합 검색 및 쿼리와 같은 항목에서 실행됩니다. 그것은 정말로 필수가되고 있습니다. 쿼리는 일반적으로 여러 종류의 소스에 스레드되어야하며 신뢰할 수있는 정보를 가져와야합니다.
특히 사람들이 의미 기술과 같은 핵심 사항을 살펴볼 핵심 요소 중 하나는 Ron이 IDERA 접근 방식에 대해 조금 이야기하기를 희망하는 것입니다. 원시 데이터의 데이터 계층 자체에서 데이터의 모델 계층? 따라서 데이터 영역에서 데이터베이스, 문서 데이터, 스프레드 시트 데이터, 이미지 데이터가있을 수 있습니다. 제약 산업과 같은 분야에 있다면 방대한 양의 과학 데이터가 있습니다. 그리고이 사람들 위에는 일반적으로 데이터를 신속하게 통합 할 수있는 모델을 구축 할 수있는 방법을 찾고 있습니다. 실제로 데이터를 찾을 때 모든 데이터를 모델 계층으로 끌어 올리려고하지는 않습니다., 모델 계층에서 수행하는 작업은 사물, 공통 어휘, 공통 유형의 엔티티 및 관계, 실제 데이터에 실제로 도달 할 수있는 기능에 대한 훌륭한 논리적 표현을 제공하는 것입니다. 그래서 그것은 그것이 무엇인지 말하고, 그것이 어디에 있는지를 말해야하며, 그것을 가져 와서 가져 오는 방법을 말해야합니다.
그래서 이것은 시맨틱 기술을 추진하는 데 매우 성공적인 접근법이었습니다. 이는 제가 많이 일하는 분야입니다. 그래서 Ron에게 제기하고 싶었고 Q & A 섹션에서 유용 할 것으로 생각되는 질문은 이것이 IDERA 플랫폼에 의해 어떻게 달성되는지 보는 것입니다. 모델 레이어가 실제로 데이터 레이어와 분리되어 있습니까? 더 통합되어 있습니까? 어떻게 작동하고 그들이 접근 한 결과, 이점은 무엇입니까? 따라서 참조 데이터도 실제로 중요 해지고 있습니다. 따라서 이러한 종류의 데이터 모델을 사용하려면 페더레이션을 수행하고 여러 항목을 검색 할 수 있으려면 참조 데이터가 있어야합니다. 그러나 문제는 참조 데이터가 실제로 유지 관리하기 어려울 수 있다는 것입니다. 따라서 종종 표준 자체를 명명하는 것은 어려운 과제입니다. 한 그룹은 X를 호출하고 다른 그룹은 Y를 호출 할 것입니다. 이제 이런 유형의 정보를 찾을 때 누군가 X와 Y를 찾는 방법에 문제가 있습니까? 데이터의 일부만 제공하고 싶지 않기 때문에 모든 관련 정보를 제공하려고합니다. 동시에 용어가 변경되면 소프트웨어가 더 이상 사용되지 않으므로 시간이 지남에 따라 해당 참조 데이터를 어떻게 유지하고 유지합니까?
다시 말하지만, 분류법 및 어휘, 데이터 사전과 같은 것을 사용하는 시맨틱 기술은이를 수행하는 표준 공간 방법을 제공했으며, 이는 매우 강력하고 특정 표준을 활용하지만 데이터베이스 커뮤니티는이를 위해이 작업을 수행했습니다. 다른 방식으로도 오랜 시간이 걸렸습니다. 여기서 핵심 요소 중 하나는 엔터티 관계 모델을 사용하는 방법, 그래프 모델을 사용하는 방법 또는 여기에 실제로 참조 데이터를 처리하는 표준 간격 방법을 제공 할 수있는 방법을 생각하는 것입니다. 물론 일단 참조 데이터가 있으면 매핑 전략은 다양한 이름과 엔터티를 관리해야합니다. 따라서 주제 전문가는 종종 자신의 용어를 사용하는 것을 좋아합니다.
따라서이 문제는 항상 누군가에게 정보를 제공하지만 정보를 말하는 방식과 관련이있는 방법은 무엇입니까? 예를 들어 한 그룹은 약물을 연구하는 화학자, 같은 약물을 연구하는 구조 생물 학자, 같은 유형의 실체에 대해 다른 이름을 가질 수 있습니다. 그것은 당신의 분야와 관련이 있습니다. 다른 접근 방식은 사람들이 자신의 용어를 포기하고 종종 싫어하는 다른 사람을 사용하도록 강요해야하기 때문에 이러한 개인화 된 용어를 결합하는 방법을 찾아야합니다. 여기서 또 다른 요점은 많은 동의어를 처리하는 것이 어려워 지므로 많은 사람들의 데이터에 같은 것을 나타낼 수있는 많은 다른 단어가 있습니다. 다 대일 관계 집합을 사용하여 참조하는 데 문제가 있습니다. 전문화 된 용어는 산업마다 다르므로 이러한 유형의 데이터 관리를위한 중요한 솔루션을 생각해 내려면 한 프로젝트에서 다른 애플리케이션으로 쉽게 이식 할 수 있습니까? 그것은 또 다른 도전이 될 수 있습니다.
자동화는 중요하며 도전 과제이기도합니다. 참조 데이터를 수동으로 처리하는 것은 비용이 많이 듭니다. 수동 매핑을 유지하는 것은 비용이 많이 들고 주제 전문가가 일상적인 작업을 중단하고 데이터 사전을 계속 수정하고 정의를 다시 업데이트하는 등의 작업을 수행하는 데 많은 비용이 듭니다. 복제 가능한 어휘는 실제로 많은 가치를 보여줍니다. 따라서 종종 조직 외부에서 찾을 수있는 어휘입니다. 예를 들어, 원유 작업을하는 경우 제약, 은행 산업 및 금융과 같은 오픈 소스 공간에서 빌릴 수있는 특정 종류의 어휘가있을 수 있습니다. 사람들은 재사용이 가능하고 일반적인 복제 가능한 어휘를 사용하여 사람들이 사용할 수 있도록합니다.
다시 한 번 IDERA 도구를 살펴보면 이러한 도구가 표준을 사용하는 관점에서 어떻게 처리하는지 궁금합니다. 시맨틱 세계에서는 관계보다 최소한 더 넓거나 좁은 표준을 제공하는 SKOS 모델과 같은 것들을 종종 볼 수 있으며 이러한 것들이 ER 모델에서는 수행하기 어려울 수 있지만 불가능하지는 않지만 그 정도에 달려 있습니다. 이러한 유형의 시스템에서 처리 할 수있는 기계 및 연결.
마지막으로 저는 업계에서 볼 수있는 일부 시맨틱 엔진과 비교해보고 싶었고 Ron에게 물어보고 IDERA의 시스템이 시맨틱 기술과 함께 어떻게 사용되었는지에 대해 조금 이야기 해 보았습니다. 트리플 스토어, 그래프 데이터베이스와 통합 할 수 있습니까? 시맨틱 한 세계에서 SPARQL Endpoints를 사용하여 이러한 종류의 물건을 빌릴 수 있기 때문에 외부 소스를 사용하는 것이 얼마나 쉬운가요? RDF 또는 OWL 모델을 모델로 직접 가져올 수 있습니다. 다시 참조하십시오. 예를 들어 유전자 온톨로지 또는 단백질 온톨로지는 자체 관리 구조를 사용하여 자체 공간에서 어딘가에 살 수 있으며 모든 또는 내 모델에 필요할 때 그 일부입니다. IDERA가이 문제에 어떻게 접근하는지 알고 싶습니다. 모든 것을 내부적으로 유지해야합니까, 아니면 다른 종류의 표준화 된 모델을 사용하여 가져와야하는 방법이 있습니까? 그리고 제가 마지막으로 언급 한 것은 용어집과 메타 데이터 저장소를 구축하기 위해 얼마나 많은 수동 작업이 실제로 포함되어 있습니까?
그래서 Ron이 우리에게 이런 흥미로운 것들에 대한 데모를 보여줄 것임을 알고 있습니다. 그러나 종종 고객과의 상담에서 볼 수있는 문제는 사람들이 자신의 정의 나 메타 데이터를 작성하는 경우 많은 오류가 발생한다는 것입니다. 따라서 맞춤법 오류가 발생하고 지방 손가락 오류가 발생합니다. 그 중 하나입니다. 또한 위키피디아 나 정의에서 원하는 품질이 아닌 소스에서 무언가를 가져갈 수있는 사람들을 얻거나, 한 사람의 관점에서만 정의가 이루어 지므로 완전하지 않으며 명확하지 않습니다. 거버넌스 프로세스의 작동 방식 물론 거버넌스는 참조 데이터에 대해 이야기 할 때와 누군가의 마스터 데이터에 어떻게 적용되는지, 메타 데이터를 사용하는 방법에 대해 이야기 할 때마다 매우 큰 문제입니다. 곧.
그래서 나는이 주제들 중 일부를 거기에 넣고 싶었습니다. 이것들은 많은 다른 종류의 컨설팅 계약과 많은 다른 공간에서 비즈니스 공간에서 볼 수있는 항목이며, Ron이 이러한 주제 중 일부를 지적하기 위해 IDERA와 함께 우리에게 보여줄 내용에 관심이 있습니다. . 정말 고마워요
Rebecca Jozwiak : Eric, 정말 감사합니다. Eric은 사람들이 자신의 정의 나 메타 데이터를 작성하는 경우 많은 오류가 발생할 수 있다는 의견을 정말 좋아합니다. 나는 저널리즘 세계에서“많은 눈이 오류를 거의 만들지 않는다”는 진언이 있다는 것을 알고 있습니다. 그러나 실제 응용 프로그램에 관해서는 쿠키 항아리에 너무 많은 손이 많은 쿠키를 끊는 경향이 있습니다.
에릭 리틀 : 그렇습니다.
레베카 요 즈윅 : 네. 그걸로 말콤 치슬 홀름으로 넘어가겠습니다. 말콤, 바닥은 당신입니다.
Malcolm Chisholm : 감사합니다, Rebecca. Eric이 이야기하고있는 내용을 조금 살펴보고 Ron이“비즈니스 주도형 데이터 아키텍처를 향하여”에 대해 이야기 할 때 Ron이 이에 응답해야 할 몇 가지 관찰 사항을 추가하고 싶습니다. – 비즈니스 중심이라는 것은 무엇을 의미하며 왜 중요한가? 아니면 과대 광고의 형태일까요? 나는 그렇게 생각하지 않습니다.
1964 년경 현재 회사가 메인 프레임 컴퓨터를 실제로 사용할 수있게되면서 많은 변화가 있었음을 알 수 있습니다. 그리고 이러한 변화는 프로세스 중심에서 데이터 중심으로의 전환으로 요약됩니다. 이것이 바로 비즈니스 중심의 데이터 아키텍처를 오늘날 중요하고 적절하게 만드는 이유입니다. 제 생각에는이 단어는 단순한 유행어가 아니라 절대적으로 실제적인 것입니다.
그러나 우리가 역사 속으로 뛰어 들어 1960 년대로 거슬러 올라간 후, 얼마 동안 메인 프레임이 지배한다면 조금 더 감사 할 수 있습니다. 그런 다음 PC가 들어 왔을 때 실제로 사용자에게 반란을 일으킨 PC로 향했습니다. 중앙 집중식 IT에 대한 반란은 자신의 요구를 충족하지 못한다고 생각했지만 충분히 민첩하지 않았습니다. 그것은 PC가 서로 연결되었을 때 분산 컴퓨팅을 빠르게 만들어 냈습니다. 그리고 인터넷이 시작되어 기업의 경계가 흐려졌습니다. 이제는 이전에는 일어나지 않았던 데이터 교환 측면에서 외부의 당사자와 상호 작용할 수있었습니다. 이제 클라우드와 빅 데이터의 시대에 접어 들었습니다. 클라우드는 실제로 인프라를 상용화하는 플랫폼이므로 빅 데이터 센터를 운영해야하는 IT를 그대로두고 있습니다. 클라우드 용량을 사용할 수있게되었고 Eric이 가지고있는 빅 데이터와 함께 웅변 적으로 논의했습니다. 그리고 전반적으로, 기술의 변화가 일어남에 따라 데이터 중심이되어 가면서 데이터에 더 많은 관심을 기울이고 있습니다. 인터넷과 마찬가지로 데이터 교환 방식. 빅 데이터의 경우 데이터 자체의 4 개 이상의 v.
동시에, 더 중요한 것은 비즈니스 사용 사례가 바뀌는 것입니다. 컴퓨터가 처음 소개되었을 때, 그들은 책과 기록 같은 것들을 자동화하는 데 사용되었습니다. 그리고 원장이나 그와 같은 것들을 수작업으로하는 수동 과정은 본질적으로 사내에서 프로그래밍되었습니다. 80 년대에는 운영 패키지의 가용성으로 전환되었습니다. 당신은 더 이상 자신의 급여를 쓸 필요가 없었습니다. 그 결과 많은 IT 부서에서 당시의 대규모 축소 또는 구조 조정이 발생했습니다. 그러나 데이터웨어 하우스와 같은 비즈니스 인텔리전스가 주로 90 년대에 나타났습니다. 당연히 큰 열풍이었던 닷컴 비즈니스 모델이 뒤를이었습니다. 그런 다음 MDM. MDM을 사용하면 자동화에 대해 생각하지 않는다는 것을 알 수 있습니다. 우리는 실제로 데이터를 데이터로 다루는 데 집중하고 있습니다. 그런 다음 데이터에서 얻을 수있는 가치를 나타내는 분석. 그리고 분석에서 핵심 비즈니스 모델이 데이터를 중심으로 성공한 회사를 볼 수 있습니다. 구글, 트위터, 페이스 북이 그것의 일부일 것이지만, 월마트도 주장 할 수있다.
비즈니스는 이제 데이터에 대해 실제로 생각하고 있습니다. 데이터에서 가치를 얻는 방법은 무엇입니까? 데이터가 비즈니스, 전략을 주도 할 수있는 방법과 우리는 데이터의 황금 시대에 있습니다. 그렇다면 데이터가 더 이상 애플리케이션의 백엔드에서 발생하는 배기 가스로 간주되지 않지만 실제로 비즈니스 모델의 중심에있는 데이터 아키텍처 측면에서 어떤 일이 일어나고 있습니까? IT를 달성하는 데있어 우리가 겪고있는 문제의 일부는 과거 IT 개발 초기 단계에서 프로세스 자동화 단계를 신속하게 처리하고 프로젝트도 비슷합니다. IT에게는 – 이것은 약간의 풍자 만화입니다. 그러나 제가 말하려는 것은 비즈니스 중심의 데이터 아키텍처를 얻는 데있어 장애물 중 하나는 IT의 문화가 비판적으로 받아 들여 졌기 때문입니다. 과거에서 비롯된 것입니다.
모든 것이 프로젝트입니다. 요구 사항을 자세히 알려주십시오. 문제가 해결되지 않으면 요구 사항을 알려주지 않았기 때문입니다. 자동화되지 않은 수동 프로세스 또는 비즈니스 프로세스의 기술적 변환으로 시작하지 않기 때문에 현재 데이터가 작동하지 않습니다. 기존의 생산 데이터를 사용하여 이미 자주 시도하고 있습니다. 가치를 얻습니다. 그러나 데이터 중심 프로젝트를 후원하는 사람은 그 데이터를 깊이 이해하지 못합니다. 데이터 검색을 수행하고 소스 데이터 분석을 수행해야합니다. 그리고 이것이 시스템 개발과 실제로는 맞지 않습니다. 폭포, SDLC 라이프 사이클 – 애자일 (Agile)은 그보다 더 나은 버전입니다.
그리고 초점이되는 것은 데이터가 아닌 기술과 기능입니다. 예를 들어, 테스트 단계에서 테스트를 수행 할 때 일반적으로 기능이 작동하는지, ETL이라고 가정하지만 데이터를 테스트하지는 않습니다. 우리는 들어오는 소스 데이터에 대한 가정을 테스트하지 않습니다. 그렇게하면 데이터웨어 하우스 프로젝트를 수행하고 업스트림 변경으로 어려움을 겪고 ETL을 파괴 한 누군가로서 더 나은 모습을 보일 것입니다. 실제로보고 싶은 것은 지속적인 생산 데이터 품질 모니터링을위한 예비 단계로 테스트하는 것입니다. 따라서 프로세스 중심 시대에 따라 비즈니스 중심의 데이터 아키텍처를 달성하기 어려운 많은 태도가 있습니다. 데이터 중심으로 전환해야합니다. 그리고 이것은 완전한 전이가 아닙니다. 아직 많은 프로세스 작업이 있지만, 우리는 데이터 중심의 용어로 생각할 필요가 없으며 실제로 발생할 때 발생하는 상황을 생각하지 않습니다. 그렇게해야합니다.
이제 비즈니스는 데이터의 가치를 깨닫고 데이터의 잠금을 해제하려고합니다. 어떻게해야합니까? 그렇다면 전환은 어떻게합니까? 우리는 개발 프로세스의 핵심에 데이터를 넣었습니다. 그리고 우리는 비즈니스가 정보 요구 사항을 이끌도록했습니다. 우리는 프로젝트 시작시 기존 소스 데이터를 아무도 이해하지 못한다는 것을 알고 있습니다. 데이터 구조와 데이터 자체가 각각 IT와 운영을 통해 이루어 졌다고 주장 할 수는 있지만 실제로는 그렇지 않습니다. 이것은 데이터 중심 개발입니다. 따라서 데이터 중심 세계에서 데이터 모델링의 위치와 위치를 생각할 때 데이터 검색 및 데이터 프로파일 링을 수행 할 때 정보 요구 사항을 수정하는 관점에서 사용자에게 피드백 루프를 제공해야합니다. 소스 데이터 분석을 예측하고 점차 데이터에 대해 점점 더 확실해집니다. 그리고 지금은 MDM 허브 또는 데이터웨어 하우스와 같은 전통적인 프로젝트에 대해 이야기하고 있습니다. 그리고 피드백 루프에는 데이터 모델러가 포함되어 있습니다. 데이터 모델을 점차적으로 발전시키고 사용자와 상호 작용하여 정보 요구 사항이 이해하기 쉬우면서 소스 데이터에서 가능한 것, 가능한 것을 기반으로 정보 요구 사항이 개선되도록합니다. 더 이상 데이터 모델이 존재하지 않거나 완전히 수행되지 않은 상태에서는 더 이상 데이터 모델에 초점을 맞추지 않습니다.
마찬가지로 데이터 다운 스트림의 다운 스트림에는 데이터 품질 테스트 규칙을 개발하여 데이터가 가정하고있는 매개 변수 내에 있는지 확인합니다. 들어가면서, Eric은 일어날 수있는 참조 데이터의 변화를 언급하고있었습니다. 품질 보증 규칙이 후반 작업, 지속적인 데이터 품질 모니터링으로 이어질 수 있기 때문에 다운 스트림 피해자, 해당 영역에서 관리되지 않은 변경의 다운 스트림 피해자가되기를 원하지 않습니다. 따라서 데이터 중심이 될 것인지, 데이터 중심 개발이 어떻게 기능 기반 SDLC 및 Agile과 다른지를 알 수 있습니다. 그리고 비즈니스 관점에도주의를 기울여야합니다. 우리는 Eric이 말한 것을 다시 한 번 강조합니다. 데이터베이스에 대한 데이터 스토리 청사진을 정의하는 데이터 모델이 있지만, 동시에 전통적으로 수행되지 않은 데이터에 대한 비즈니스 관점 인 개념적 모델이 필요합니다. 과거. 우리는 때때로 데이터 모델이 모든 것을 할 수 있다고 생각했지만, 개념적 관점과 의미를 가져야하고 데이터를 살펴보고 스토리지 계층을 비즈니스로 변환하는 추상화 계층을 통해 렌더링해야합니다. 전망. 그리고 에릭이 시맨틱 측면에서 말한 모든 것들이 그렇게하는 것이 중요해 지므로 실제로 추가적인 모델링 작업이 있습니다. 나는 당신이 내가했던 것처럼 데이터 모델러로서 순위에 올랐다면 다시 흥미로운 것이라고 생각합니다.
마지막으로 더 큰 아키텍처가이 새로운 현실을 반영하고 있다고 말하고 싶습니다. 예를 들어 전통적인 고객 MDM은 일종의 문제입니다. 고객 데이터를 허브로 가져 와서 실제로 백 오피스 애플리케이션의 데이터 품질 측면에서만 이해할 수 있습니다. 비즈니스 전략 관점에서 보면 하품의 종류입니다. 그러나 오늘날 우리는 정적 데이터뿐만 아니라 추가 고객 프로파일 데이터가 포함 된 고객 MDM 허브를 살펴보고 있습니다.이 데이터는 실제로 고객의 트랜잭션 응용 프로그램과 양방향 인터페이스를 갖습니다. 예, 여전히 백 오피스를 지원하지만 이제는 고객의 이러한 행동에 대해서도 알고 있습니다. 이것은 더 비싸다. 이것은 더 복잡합니다. 그러나 기존 고객 MDM과 달리 비즈니스 중심입니다. 구현하기 쉬운 더 단순한 디자인과 비즈니스 방향을 바꾸는 것이지만 비즈니스의 경우 원하는 것입니다. 우리는 실제로 새로운 시대에 접어 들면서 비즈니스 중심의 데이터 아키텍처에 대응해야 할 여러 수준이 있다고 생각하며 일을하는 것이 매우 흥미로운 시점이라고 생각합니다.
고마워요, 레베카
Rebecca Jozwiak : 감사합니다. Malcolm, 데이터 모델에 대한 귀하의 의견은 비즈니스 관점에 도움이되어야합니다. 왜냐하면 당신이 말한 것과는 달리, IT가 오랫동안 고삐를 개최 한 곳은 더 이상 그런 것이 아니기 때문입니다. 문화가 바뀌어야한다는 것입니다. 그리고 나는 당신과 100 % 동의 한 개가 백그라운드에 있다고 확신합니다. 그리고 저는 그 공을 Ron에게 전달할 것입니다. 데모를 보게되어 정말 기쁩니다. 론, 바닥은 네 꺼야
Ron Huizenga : 대단히 감사합니다 . 우리가 그것에 뛰어 들기 전에 Eric과 Malcolm이 지적한 것처럼 이것은 매우 광범위하고 깊은 주제이므로 오늘날 우리가 이야기하고있는 것은 비즈니스 중심 아키텍처에서 고려해야 할 많은 요소와 요소가 너무 많기 때문에 그 표면을 긁어내는 것입니다. 우리의 접근 방식은 모델 기반의 커뮤니케이션 가치와 다른 시스템을 가능하게하는 계층으로 사용할 수 있기 때문에 모델 기반의 진정한 가치를 이끌어내는 것입니다. 서비스 지향 아키텍처를 수행하든 다른 작업을하든 모델은 실제로 모든 메타 데이터와 비즈니스에 포함 된 데이터를 사용하여 현재 상황의 생명선이됩니다.
Malcolm이 솔루션이 발전한 방식과 그 유형의 역사에 대해 이야기했기 때문에 내가 이야기하고 싶은 것은 거의이 단계를 거꾸로 한 것입니다. 건전한 데이터 아키텍처를 갖는 것이 얼마나 중요한지를 실제로 지적하는 한 가지 방법은 제품 관리 역할을 시작하기 전에 상담 할 때 매우 자주 사용했던 사용 사례입니다. 비즈니스 혁신을 수행하든 기존 시스템과 해당 유형을 교체하든 조직이 자신의 데이터를 제대로 이해하지 못하는 방식이 매우 빠르게 드러났습니다. 이와 같은 특정 유스 케이스를 사용하는 경우, 컨설턴트 또는 조직을 막 시작한 사람이거나 다른 회사를 인수하여 수년 동안 조직을 설립 한 사람이든 관계없이 레거시 기술, ERP 솔루션 및 기타 모든 기술뿐만 아니라 여러 가지 새로운 기술이 포함 된 매우 복잡한 환경입니다.
모델링 접근법으로 실제로 할 수있는 것 중 하나는이 모든 것을 어떻게 이해 하는가에 대한 질문에 답하는 것입니다. 우리는 정보를 함께 모으기 시작할 수 있으므로 비즈니스는 우리가 가지고있는 정보를 활용할 수 있습니다. 그리고 그 환경에서 우리가 가지고있는 것은 무엇입니까? 모델을 사용하여 필요한 정보를 도출하고 해당 정보를 더 잘 이해하려면 어떻게해야합니까? 그리고 우리는 관계형 데이터 모델과 같은 모든 다른 것들에 대한 전통적인 메타 데이터 유형을 가지고 있으며, 정의와 데이터 사전, 데이터 유형 및 그 유형과 같은 것을 보는 데 익숙합니다. 그러나 실제로 더 많은 의미를 부여하기 위해 캡처하려는 추가 메타 데이터는 어떻습니까? 예를 들어, 어떤 엔티티가 실제로 참조 데이터 오브젝트 여야하는 후보이며, 마스터 데이터 관리 오브젝트 및 해당 유형의 항목이어야하며이를 묶어야합니다. 그리고 정보는 어떻게 조직을 통과합니까? 데이터는 프로세스 관점에서 소비되는 방식뿐만 아니라 비즈니스를 통한 정보의 여정과 데이터가 다른 시스템 또는 데이터 저장소를 통해 전달되는 방식과 관련하여 데이터 계보에서 흐릅니다. 우리가 I- 솔루션 또는 그러한 유형의 것들을 구축 할 때 우리는 실제 작업에 대한 정확한 정보를 실제로 소비하고 있습니다.
그리고 중요한 것은, 모든 이해 관계자, 특히 비즈니스 이해 관계자가 데이터의 의미에 대한 진정한 의미를 부여하기 때문에 비즈니스 이해 관계자와 협업 할 수있는 방법입니다. 하루가 끝나면 비즈니스가 데이터를 소유합니다. 그것들은 Eric이 말한 어휘와 사물에 대한 정의를 제공하므로, 우리는 그 모든 것을 함께 묶을 장소가 필요합니다. 우리가하는 방식은 데이터 모델링 및 데이터 저장소 아키텍처를 통하는 것입니다.
몇 가지만 살펴 보겠습니다. ER / Studio Enterprise Team Edition에 대해 이야기하겠습니다. 기본적으로 데이터 모델링과 그 유형의 작업을 수행하는 데이터 아키텍처 제품에 대해 이야기 할 것입니다. 그러나 제품군의 다른 많은 구성 요소가 아주 간략하게 언급 될 것입니다. 개념 모델을 수행 할 수있는 비즈니스 아키텍트의 스 니펫을 볼 수 있지만 비즈니스 프로세스 모델도 수행 할 수 있으며 이러한 프로세스 모델을 연결하여 데이터 모델에있는 실제 데이터를 연결할 수 있습니다. 넥타이를 하나로 묶는 데 정말 도움이됩니다. Software Architect를 사용하면 UML 모델링과 같은 추가 구성을 수행하고 우리가 이야기하는 다른 시스템 및 프로세스에 지원 로직을 제공 할 수 있습니다. 그러나 아래로 내려 가면서 저장소와 팀 서버가 있다는 점을 매우 중요하게 생각합니다.이 두 가지에 대해 같은 내용으로 이야기하겠습니다. 리포지토리는 비즈니스 용어집 및 용어로 모든 모델링 된 메타 데이터와 모든 비즈니스 메타 데이터를 저장하는 곳입니다. 이 저장소 기반 환경이 있기 때문에 동일한 환경에서 서로 다른 모든 것들을 하나로 묶을 수 있으며 실제로 기술적 인 사람들뿐만 아니라 비즈니스맨들도 소비 할 수 있습니다. 이것이 바로 협업을 시작하는 방법입니다.
그리고 마지막으로 이야기 할 마지막 부분은 이러한 환경으로 들어가면 데이터베이스가 아니라는 것입니다. 많은 데이터베이스, 데이터 저장소를 갖게 될 것입니다. 또한 레거시 아티팩트라고 부르는 것을 많이 가질 것입니다. 사람들은 Visio 또는 다른 다이어그램을 사용하여 일부를 매핑했을 수 있습니다. 어쩌면 그들은 다른 모델링 도구와 그 유형의 도구를 가지고 있었을 것입니다. MetaWizard로 우리가 할 수있는 일은 실제로 그 정보 중 일부를 추출하여 모델로 가져 와서 최신 상태로 만들고 사용할 수 있고 현재의 방식으로 다시 소비하지 않고 다시 소비하는 것입니다. 이제는 작업 모델의 적극적인 부분이되었으며 이는 매우 중요합니다.
내가 말했듯이 조직에 들어가면 많은 ERP 솔루션과 일치하지 않는 부서별 솔루션이 많이 있습니다. 많은 조직에서 외부 제어 및 관리되는 SaaS 솔루션도 사용하고 있기 때문에 데이터베이스 및 해당 호스트의 유형을 제어하지는 않지만 해당 데이터의 모양과 물론 데이터를 알아야합니다. 그 주위의 메타 데이터. 우리가 찾은 것은 Malcolm이 말한 프로젝트 기반 접근 방식으로 인해 정리되지 않은 많은 오래된 레거시 시스템입니다. 최근 몇 년간 조직이 프로젝트를 시작하고 시스템이나 솔루션을 대체 할 방법이 놀랍지 만, 구식 솔루션을 폐기 할 프로젝트 예산이 충분하지 않아서 이제 막 진행되고 있습니다. 그리고 실제로 환경에서 제거 할 수있는 것과 앞으로 유용한 것이 무엇인지 알아 내야합니다. 그리고 그것은 열악한 해체 전략과 관련이 있습니다. 그것은 같은 것의 일부이며 소포입니다.
우리가 찾은 것은이 모든 다양한 솔루션으로 많은 조직이 구축 되었기 때문에 여러 곳에서 많은 데이터가 이동하는 지점 간 인터페이스가 많이 있다는 것입니다. 이를 합리화하고 앞에서 간략하게 언급 한 데이터 계보를 파악하여 올바른 정보를 제공하기 위해 서비스 지향 아키텍처, 엔터프라이즈 서비스 버스 및 이러한 유형의 것들과 같은보다 응집력있는 전략을 가질 수 있어야합니다. 비즈니스 전반에 걸쳐 올바르게 사용하는 게시 및 구독 유형의 모델에 물론 데이터웨어 하우스, 기존 ETL이있는 데이터 마트 또는 새로운 데이터 레이크를 사용하는 경우에도 여전히 일종의 분석을 수행해야합니다. 그것은 모두 같은 것으로 귀착됩니다. 빅 데이터이든 관계형 데이터베이스의 기존 데이터이든 관계없이 모든 데이터입니다. 데이터를 관리하고 모델 전체에서 처리하는 내용을 알 수 있도록 모든 데이터를 함께 가져와야합니다.
다시, 우리가하려는 복잡성은 우리가 할 수있는 많은 단계가 있다는 것입니다. 우선, 당신은 들어 와서 그 정보 환경이 어떻게 보이는지에 대한 청사진을 가지고 있지 않을 수도 있습니다. ER / Studio Data Architect와 같은 데이터 모델링 도구에서는 먼저 외부에있는 데이터 소스를 가리키고 가져 와서 더 대표적인 것으로 서로 연결하는 측면에서 많은 리버스 엔지니어링을 수행하게됩니다. 전체 비즈니스를 나타내는 모델. 중요한 것은 비즈니스 라인을 따라 해당 모델을 분해하여 비즈니스 사람들과 관련시킬 수있는 더 작은 청크로 모델과 관련 될 수 있기를 원한다는 점입니다. 그 위에.
명명 표준은 매우 중요하며 여기서 몇 가지 다른 방식으로 이야기하고 있습니다. 모델에서 이름을 지정하는 방법에 관한 명명 표준. 논리 모델에서 수행하는 것은 매우 쉬운데, 여기서 우리는 모델에 대한 좋은 명명 규칙과 데이터 사전이 있지만, 우리가 가져 오는 많은 물리적 모델에 대해 다른 명명 규칙을 볼 수 있습니다. 리버스 엔지니어, 우리는 종종 약식 이름과 내가 이야기 할 그런 유형의 것을 본다. 또한 비즈니스에 의미가있는 의미있는 영어 이름으로 다시 변환하여 환경에있는 모든 데이터가 무엇인지 이해할 수 있도록해야합니다. 그리고 보편적 인 매핑은 우리가 함께 연결하는 방법입니다.
그 외에도 우리는 더 자세히 문서화하고 정의 할 것이며, 여기서 첨부 파일이라는 것을 사용하여 데이터를 더 분류 할 수있는 곳에서 몇 가지 슬라이드를 보여 드리겠습니다. 그런 다음 루프를 닫으면 비즈니스 용어를 묶어 다른 모델 아티팩트에 연결할 수있는 비즈니스 의미를 적용하려고합니다. 따라서 특정 비즈니스 용어에 대해 이야기 할 때 조직 전체의 데이터에 구현됩니다. 마지막으로, 나는 이미이 모든 것이 많은 협업 및 출판 기능을 기반으로하는 저장소가되어야한다는 사실에 대해 이야기했습니다. 따라서 이해 관계자가이를 활용할 수 있습니다. 리버스 엔지니어링에 대해 상당히 빨리 이야기하겠습니다. 나는 이미 당신에게 그것의 매우 빠른 하이라이트를주었습니다. 실제 데모에서 우리가 가져올 수있는 것들 중 일부를 보여주기 위해 당신에게 그것을 보여줄 것입니다.
그리고이 시나리오에서 생성 할 몇 가지 다른 모델 유형과 다이어그램에 대해 이야기하고 싶습니다. 분명히 우리는 많은 경우에 개념적 모델을 할 것입니다. 나는 그것에 많은 시간을 소비하지 않을 것입니다. 논리적 모델, 물리적 모델 및 우리가 만들 수있는 특수한 유형의 모델에 대해 이야기하고 싶습니다. 또한 동일한 모델링 플랫폼에서 이들을 모두 만들어서 서로 연결할 수있는 것이 중요합니다. 여기에는 차원 모델과 NoSQL과 같이 새로운 데이터 소스를 활용하는 모델도 포함됩니다. 그런 다음 데이터 계보 모델은 어떻게 생겼습니까? 그 데이터를 비즈니스 프로세스 모델로 연결하는 방법은 다음에 살펴 보겠습니다.
여기서는 매우 높고 빠른 개요를 제공하기 위해 모델링 환경으로 전환하겠습니다. 그리고 지금 내 화면을 볼 수 있어야한다고 생각합니다. 우선 전통적인 유형의 데이터 모델에 대해서만 이야기하고 싶습니다. 모델을 가져올 때 모델을 구성하려는 방식은 모델을 분해 할 수 있기를 원한다는 것입니다. 여기 왼쪽에 보이는 것은이 특정 모델 파일에 논리적 및 물리적 모델이 있다는 것입니다. 다음은 비즈니스 분해에 따라 분류 할 수 있으므로 폴더가 표시되는 것입니다. 연한 파란색은 논리적 모델이고 녹색은 물리적 인 모델입니다. 또한 ER / Studio 내에서 비즈니스 분해를 수행하는 경우 원하는 수준으로 깊이 또는 하위 모델을 진행할 수 있으며 하위 수준에서 변경 한 내용은 상위에서 자동으로 반영됩니다. 수준. 따라서 매우 강력한 모델링 환경이됩니다.
이 정보를 함께 모으기 시작하는 것이 매우 중요하다고 지적한 것은 하나의 논리 모델에도 해당하는 여러 개의 물리적 모델을 가질 수 있다는 것입니다. 종종 논리적 모델이있을 수 있지만 다른 플랫폼과 해당 유형의 물리적 모델이있을 수 있습니다. 하나는 SQL Server 인스턴스 일 수도 있고 다른 하나는 Oracle 인스턴스 일 수도 있습니다. 우리는 모든 것을 동일한 모델링 환경에서 함께 묶을 수 있습니다. 그리고 다시, 제가 여기에 가지고있는 것은 다시 같은 모델링 환경에 있거나 저장소에두고 다른 것들에 연결할 수있는 실제 데이터웨어 하우스 모델입니다.
제가 실제로 보여 드리고 싶은 것은 다른 것들과 우리가 도입 한 모델의 다른 변형입니다. 우리가 이와 같은 전통적인 데이터 모델에 접근 할 때 우리는 열과 메타 데이터 그리고 그 유형의 것들을 가진 전형적인 엔터티를 보는 데 익숙하지만, 새로운 NoSQL 기술 중 일부를 다루기 시작할 때 그 관점은 매우 빠르게 변합니다 또는 일부 사람들이 여전히 빅 데이터 기술이라고 부르기를 좋아합니다.
이제 환경에 Hive가 있다고 가정 해 봅시다. Hive 환경에서 엔지니어를 리버스 엔지니어링하고이 동일한 모델링 도구를 사용하여 Hive에서 엔지니어를 포워드 및 리버스 할 수 있다면 약간 다른 것을 볼 수 있습니다. 우리는 여전히 모든 데이터를 구조로 보지만 TDL은 다릅니다. SQL을 보는 데 익숙한 사람들은 이제 Hive QL입니다. Hive QL은 SQL과 매우 유사하지만 이제는 다른 스크립팅 언어로 작업을 시작할 수있는 것과 동일한 도구가 아닙니다. 따라서이 환경에서 모델링하여 Hive 환경으로 생성 할 수 있지만, 앞에서 설명한 시나리오에서 모두 역 엔지니어링하고이를 이해하고 함께 연결할 수 있습니다. .
조금 다른 또 다른 것을 보자. MongoDB는 우리가 기본적으로 지원하는 또 다른 플랫폼입니다. 그리고 문서 저장소가있는 JSON 유형의 환경에 들어가기 시작하면 JSON은 다른 동물이며 관계형 모델에 해당하지 않는 구조가 있습니다. JSON을 조사하기 시작할 때 임베디드 오브젝트 및 임베디드 오브젝트 배열과 같은 개념을 곧 다루기 시작하며 이러한 개념은 전통적인 관계 표기법에 존재하지 않습니다. 여기서 우리가 한 것은 실제로 같은 환경에서이를 처리 할 수 있도록 표기법과 카탈로그를 확장 한 것입니다.
엔터티 및 테이블과 같은 것을 보지 않고 왼쪽에서 살펴보면 객체라고합니다. 그리고 당신은 다른 표기법을 봅니다. 여기에는 일반적인 유형의 참조 표기법이 여전히 표시되지만이 특정 다이어그램에 표시되는 파란색 요소는 실제로는 포함 된 개체입니다. 그리고 우리는 다른 카디널리티를 보여줍니다. 다이아몬드 카디널리티는 한쪽 끝에는 개체가 있지만 하나의 카디널리티는 게시자 내에 해당 관계를 따르는 경우 주소 개체가 포함되어 있음을 의미합니다. JSON을 조사하면서 우리는 그것이 고객에 포함 된 것과 똑같은 객체 구조를 발견했지만 실제로는 객체의 배열로 포함되었습니다. 우리는 커넥터 자체를 통해서뿐만 아니라 실제 엔티티를 살펴보면 후원자 아래에 주소가 객체 배열로 분류되어 있음을 알 수 있습니다. 당신은 그것을 어떻게 가져올 수 있는지에 대한 매우 서술적인 관점을 얻습니다.
그리고 다시, 몇 초만에 지금까지 보았던 것은 다중 레벨 인 전통적인 관계형 모델입니다. 우리는 Hive로 같은 일을 할 수 있고, MongoDB와 같은 다른 일을 할 수 있습니다. 잘. 우리도 할 수있는 일을 아주 빨리 보여 드리려고합니다. 다른 분야에서 물건을 가져 오는 사실에 대해 이야기했습니다. 데이터베이스에서 모델을 가져 오거나 리버스 엔지니어링한다고 가정하지만 외부 메타 데이터에서 가져올 것입니다. 우리가 가져올 수있는 모든 다른 유형의 것들에 대한 매우 빠른 관점을 제공하기 위해.
보시다시피, 실제로 메타 데이터를 모델링 환경으로 가져올 수있는 수많은 것들이 있습니다. Amazon Redshift, Cassandra, 기타 여러 빅 데이터 플랫폼과 같은 것부터 시작하여 많은 목록이 표시됩니다. 알파벳 순서로되어 있습니다. 우리는 많은 빅 데이터 소스와 그 유형의 것을보고 있습니다. 또한 메타 데이터를 실제로 가져올 수있는 기존 또는 이전의 모델링 환경이 많이 있습니다. 여기서 나가고 그들 모두에게 시간을 보내지 않을 경우 모델링 플랫폼과 데이터 플랫폼 측면에서 가져올 수있는 많은 것들이 있습니다. 여기에서 알아야 할 중요한 부분은 데이터 계보에 대해 이야기하기 시작할 때 수행 할 수있는 또 다른 부분입니다. Enterprise Team Edition에서는 ETL 소스 (Talend 또는 SQL Server Information Services 매핑 등)를 조사 할 수 있습니다. 실제로 데이터 계보 다이어그램을 시작하고 이러한 변환에서 발생하는 상황에 대한 그림을 그릴 수 있습니다. 실제로 Enterprise Team Edition 제품의 일부인 130 개 이상의 서로 다른 브리지가 기본적으로 제공되므로 모든 아티팩트를 하나의 모델링 환경으로 매우 빠르게 통합 할 수 있습니다.
마지막으로, 데이터웨어 하우징 또는 모든 유형의 분석을 수행하는 경우 다른 유형의 구성이 필요하다는 사실을 잊을 수 없다는 사실에 대해서도 이야기하고 싶습니다. 우리는 여전히 팩트 테이블이 있고 차원과 사물 유형이있는 차원 모델과 같은 일을 할 수있는 능력을 원합니다. 또한 보여 드리고 싶은 것은 메타 데이터에 대한 확장 기능을 사용하여 측정 기준의 유형과 기타 항목을 분류 할 수 있다는 것입니다. 예를 들어 여기에서 차원 데이터 탭을 살펴보면 실제로 보이는 모델 패턴을 기반으로 자동으로 감지하고 차원인지 아닌지에 대한 시작점을 제공합니다. 사실 테이블. 그러나 그 이상으로, 우리가 할 수있는 것은 차원과 그 유형 내에서 이루어지며, 데이터웨어 하우징 유형의 환경에서 데이터를 분류하는 데 사용할 수있는 차원의 유형도 다릅니다. 매우 강력한 기능으로 우리는 이것을 모두 함께 바느질하고 있습니다.
나는 지금 데모 환경에 있기 때문에 이것으로 뛰어 들고 슬라이드로 돌아 가기 전에 몇 가지 다른 것을 보여줄 것입니다. 우리가 최근에 ER / Studio Data Architect에 추가 한 것 중 하나는 상황에 처한 것입니다. 프로젝트에서 작업 할 때 매우 일반적인 사용 사례입니다. 개발자는 객체와 관련하여 생각하지만 데이터는 모델러는 테이블과 엔터티 및 해당 유형의 관점에서 생각하는 경향이 있습니다. 이는 매우 단순한 데이터 모델이지만 개발자 나 비즈니스 분석가 또는 비즈니스 사용자가 서로 다른 개체 또는 비즈니스 개념으로 생각할 수있는 몇 가지 기본 개념을 나타냅니다. 지금까지는 분류하기가 매우 어려웠지만 2016 릴리스의 ER / Studio Enterprise Team Edition에서 실제로 수행 한 것은 이제 비즈니스 데이터 개체라는 개념입니다. 이를 통해 엔티티 또는 테이블 그룹을 실제 비즈니스 오브젝트로 캡슐화 할 수 있습니다.
예를 들어, 이 새로운 관점에서 볼 수있는 것은 지금 구매 주문 헤더와 주문 라인이 결합되어 개체로 캡슐화되어 데이터를 유지할 때 작업 단위로 간주한다는 것입니다. 우리는 그것들을한데 모아서 다른 청중들과 쉽게 연관시킬 수 있습니다. 모델링 환경에서 재사용 할 수 있습니다. 그것들은 단순한 그림 구조가 아닌 실제 객체이지만, 모델링 관점에서 실제로 의사 소통 할 때 선택적으로 축소하거나 확장하여 특정 이해 관계자와의 대화에 대한 요약 된 뷰를 생성 할 수 있다는 추가적인 이점이 있습니다. 물론 더 많은 기술 청중을 위해 여기에서 보는 것처럼 더 자세한 뷰를 유지할 수도 있습니다. 정말 훌륭한 의사 소통 수단입니다. 이제 우리가 보는 것은 여러 가지 다른 모델 유형을 결합하여 비즈니스 데이터 객체의 개념으로 보완하는 것입니다. 이제 우리는 이러한 유형의 사물에 실제로 더 많은 의미를 적용하는 방법과 우리의 모델에서이를 결합하는 방법에 대해 이야기하겠습니다. 전반적인 환경.
WebEx를 다시 찾으려고 노력하고 있습니다. 거기서 Hot Tech 슬라이드로 돌아갑니다. 모델 데모에서이 슬라이드를 이미 보았으므로 여기에서 몇 개의 슬라이드를 빨리 앞으로 진행하겠습니다. 명명 표준에 대해 매우 빠르게 이야기하고 싶습니다. 우리는 다른 명명 표준을 적용하고 시행하려고합니다. 우리가 원하는 것은 기본적으로 단어 나 구 또는 약어를 통해 기본적으로 그 의미를 구축하고 의미있는 영어 유형의 단어에 연결하기 위해 이름 지정 표준 템플릿을 저장소에 저장할 수 있다는 것입니다. 우리는 비즈니스 용어, 각각의 약어를 사용하고 순서, 사례를 지정하고 접두사와 접미사를 추가 할 수 있습니다. 일반적인 사용 사례는 일반적으로 사람들이 논리적 모델을 구축 한 다음 실제로 약어 및 기타 모든 것을 사용했을 수있는 물리적 모델을 만들려고하는 경우입니다.
우리가 리버스 엔지니어링 한 물리적 데이터베이스 중 일부에 대한 명명 표준 중 일부를 알 수 있다면 그 약어를 사용하여 더 길게 만들 수 있습니다. 영어 문구로 거꾸로 가져옵니다. 실제로 데이터의 모양에 맞는 적절한 이름을 도출 할 수 있습니다. 내가 말했듯이 일반적인 사용 사례는 논리적으로 물리적으로 이동하여 데이터 저장소와 해당 유형의 항목을 매핑하는 것입니다. 오른쪽의 스크린 샷을 보면 소스 이름의 약칭 이름이 있으며 명명 표준 템플릿을 적용하면 실제로 더 많은 이름이 있습니다. 그리고 우리가 사용하는 명명 표준 템플릿에 따라 원하는 경우 공백과 같은 것을 넣을 수 있습니다. 우리는 그것을 모델로 가져올 수 있도록 보이도록 만들 수 있습니다. 우리가 무엇을 부르는지 알 때만 실제로 정의를 붙일 수 있습니다. 정의가 무엇인지 알지 못하면 어떻게 의미를 적용 할 수 있습니까?
좋은 점은 모든 종류의 일을 할 때 실제로 이것을 호출 할 수 있다는 것입니다. 리버스 엔지니어링에 대해 이야기했는데 리버스 엔지니어링을 수행 할 때 실제로 명명 표준 템플릿을 동시에 호출 할 수 있습니다. 마법사를 통해 수행 할 수있는 단계는 규칙이 무엇인지 알고 있다면 실제 데이터베이스를 리버스 엔지니어링 할 수 있으며 모델링 환경에서 실제 모델로 다시 가져 오는 것입니다. 또한 이러한 명명 규칙을 적용 할 것입니다. 따라서 우리는 영어와 같은 이름의 표현이 환경의 해당 논리 모델에 무엇인지 알 수 있습니다. 또한이를 수행하고이를 XML 스키마 생성과 결합하여 SOA 프레임 워크를 수행하든 그 유형의 작업을 수행하든 모델을 사용하여 약어로 푸시 할 수 있으므로 다양한 명명 규칙을 적용 할 수 있습니다. 실제로 모델 자체에 저장했습니다. 그것은 우리에게 매우 강력한 기능을 많이 제공합니다.
여기에도 템플릿이있을 경우의 모습에 대한 예가 있습니다. 이것은 실제로 명명 표준 컨벤션에서“직원”에 대한 EMP, “급여”에 대한 SAL, “계획”에 대한 PLN을 가지고 있음을 보여줍니다. 모델을 구축하고 물건을 넣을 때 대화식으로 실행하도록 적용 할 수도 있습니다.이 약어를 사용하고 엔티티 이름에 "직원 급여 계획"을 입력하면 이름 지정 표준 템플릿으로 작동합니다. 여기에서 정의했습니다. 엔티티를 생성 할 때 EMP_SAL_PLN이 주어졌고 해당 물리적 이름이 바로 주어졌습니다.
다시 말해, 엔지니어링을 설계하고 진행할 때 매우 유용합니다. 우리는 매우 독특한 개념을 가지고 있으며, 이것이 바로 이러한 환경을 통합하기 시작하는 곳입니다. 그리고이를 범용 매핑이라고합니다. 이러한 모델을 모두 환경에 적용하고 가능한 명명 규칙을 적용하고 쉽게 찾을 수 있다고 가정하면 ER에서 Universal Mappings라는 구문을 사용할 수 있습니다. /사진관. 모델간에 엔터티를 연결할 수 있습니다. 우리가“고객”을 보는 곳마다 – 많은 다른 시스템과 많은 다른 데이터베이스에서“고객”을 갖게 될 것입니다 – 우리는 하나의 모델에서 작업 할 때 이들을 모두 연결하기 시작할 수 있습니다. 다른 모델에서 고객의 징후가 어디에 있는지 확인할 수 있습니다. 또한이를 나타내는 모델 계층이 있으므로 데이터 소스에 연결하여 데이터베이스가 어떤 데이터베이스에 있는지에 대한 질의를받을 수 있습니다. 그것은 우리에게이 모든 것을 매우 응집력있게 묶을 수있는 능력을 실제로줍니다.
비즈니스 데이터 개체를 보여주었습니다. 또한 첨부 파일이라고하는 메타 데이터 확장에 대해 매우 빠르게 이야기하고 싶습니다. 그 기능은 모델 객체에 대한 추가 메타 데이터를 생성 할 수있는 기능을 제공합니다. 데이터 거버넌스 및 데이터 품질 관점에서 많은 다른 것들을 이끌어 내고 마스터 데이터 관리 및 데이터 보존 정책에 도움이되도록 이러한 유형의 속성을 설정하는 경우가 종종 있습니다. 기본 아이디어는 이러한 분류를 작성하고 원하는 경우 테이블 레벨, 열 레벨에서 해당 유형의 항목을 첨부 할 수 있다는 것입니다. 물론 가장 일반적인 사용 사례는 엔터티가 테이블이고 다음과 같이 정의 할 수 있습니다. 마스터 데이터 개체, 참조 테이블, 트랜잭션 테이블은 무엇입니까? 데이터 품질 관점에서 비즈니스에 중요한 관점에서 분류를 수행하여 데이터 정리 노력과 해당 유형의 유형에 우선 순위를 지정할 수 있습니다.
종종 간과되는 것은 조직의 여러 유형의 데이터에 대한 보존 정책은 무엇입니까? 이를 설정하여 모델링 환경과 물론 리포지토리의 다양한 유형의 정보 아티팩트에 실제로 첨부 할 수 있습니다. 아름다움은 이러한 첨부 파일이 데이터 사전에 존재하므로 환경에서 엔터프라이즈 데이터 사전을 사용할 때 여러 모델에 첨부 할 수 있다는 것입니다. 이를 한 번만 정의하면 환경의 여러 모델에서 반복해서 활용할 수 있습니다. 이것은 첨부 파일을 만들 때 실제로 지정할 수있는 모든 스크린 샷을 보여주는 간단한 스크린 샷입니다. 여기이 예제는 실제로 값 목록이므로 값 목록에서 값을 선택할 수 있습니다. 모델링 환경에서 선택할 대상을 많이 제어 할 수 있으며 기본값을 설정할 수도 있습니다. 값은 선택되지 않은 경우입니다. 그래서 많은 힘이 있습니다. 그들은 데이터 사전에 살고 있습니다.
이 화면에서 조금 더 보여 드리고 싶은 것이 있습니다. 또한 상단에 첨부 파일이 표시되고 그 아래에 데이터 보안 정보가 표시됩니다. 실제로 환경의 여러 정보에 데이터 보안 정책을 적용 할 수 있습니다. 서로 다른 컴플라이언스 매핑, 데이터 보안 분류의 경우 생성 및 사용을 시작할 수있는 자체적으로 여러 가지를 제공하지만 자체 컴플라이언스 매핑 및 표준도 정의 할 수 있습니다. HIPAA를 수행하든 다른 이니셔티브를 수행하든 상관 없습니다. 그리고 환경에서이 매우 풍부한 메타 데이터 세트를 실제로 구축 할 수 있습니다.
그리고 용어와 용어 – 비즈니스의 의미와 관련이 있습니다. 우리는 종종 조직에서 용어집을 시작하기위한 출발점으로 사용하고있는 데이터 사전을 가지고 있지만 용어와 언어는 다음과 같습니다. 종종 매우 기술적입니다. 우리가 할 수있는 것은 원한다면 용어집을 시작하기위한 출발점으로 사용할 수 있지만, 실제로는 비즈니스가이를 소유하기를 원합니다. 팀 서버 환경에서 수행 한 작업은 사람들이 비즈니스 정의를 작성하고 모델링 환경에서 해당하는 다른 모델 아티팩트에 링크 할 수있는 기능을 제공한다는 것입니다. 또한 앞에서 논의한 요점은 입력하는 사람이 많을수록 사람의 실수가 발생할 가능성이 높다는 것입니다. 용어집 구조에서 우리가하는 일은 하나, 우리는 용어집의 계층 구조를 지원하므로 조직에 다른 용어집 유형이나 다른 유형의 것들을 가질 수 있지만, 중요한 것은 이미 이러한 소스 중 일부가 있다면 용어와 정의 된 모든 용어를 사용하여 실제로 CSV 가져 오기를 수행하여 모델링 환경과 팀 서버 또는 용어집으로 가져 와서 연결을 시작할 수 있습니다. 그리고 무언가가 바뀔 때마다 정의 및 기타 모든 측면에서 전후 이미지가 무엇인지에 대한 완전한 감사 추적이 있으며, 가까운 시일 내에 보게 될 것은 승인 워크 플로우에 더 가깝습니다. 따라서 우리는 그것을 관리하는 사람, 위원회 또는 개인의 승인 및 그 유형을 실제로 제어하여 우리가 진행함에 따라 관리 프로세스를 더욱 강력하게 만들 수 있습니다.
이것이 우리를 위해하는 일은 팀 서버 용어집에 이러한 용어집이있을 때입니다. 이것은 제가 여기서 가져온 모델 자체의 엔티티에서 편집하는 예입니다. 용어가 연결되었을 수도 있지만 여기에 실체에 포함 된 내용에 대한 메모 나 설명에 해당 용어집에있는 단어가있는 경우 해당 단어가 자동으로 더 밝은 하이퍼 링크로 표시됩니다. 우리는 실제로 비즈니스 용어집에서 정의를 볼 수 있습니다. 또한 정보 자체를 소비 할 때 풍부한 용어 정보와 함께 풍부한 정보를 제공합니다. 그것은 경험을 풍부하게하고 우리가 작업하는 모든 것에 그 의미를 적용하는 데 정말로 도움이됩니다.
다시, 그것은 매우 빠른 비행이었다. 분명히 다른 부분을 조사하면서 며칠을 소비 할 수 있었지만 이것은 표면 위로 매우 빠른 비행입니다. 우리가 실제로 노력하고있는 것은 복잡한 데이터 환경이 어떻게 보이는지 이해하는 것입니다. 우리는 이러한 모든 데이터 아티팩트의 가시성을 향상시키고 ER / Studio를 통해이를 해결하기 위해 협력하고 싶습니다. 보다 효율적이고 자동화 된 데이터 모델링을 가능하게하고 싶습니다. 그리고 그것은 우리가 이야기하는 모든 유형의 데이터입니다. 빅 데이터, 전통적인 관계형 데이터, 문서 저장소 또는 다른 것입니다. 그리고 다시, 우리는 다른 플랫폼과 다른 툴을위한 강력한 포워드 및 리버스 엔지니어링 기능을 가지고 있기 때문에이를 달성했습니다. 또한 모든 관련 이해 관계자와 조직 전체를 공유하고 커뮤니케이션하는 것입니다. 그것이 우리가 명명 표준을 통해 의미를 적용하는 곳입니다. 그런 다음 비즈니스 용어집을 통해 정의를 적용합니다. 그런 다음 데이터 품질 확장, 마스터 데이터 관리를위한 분류 또는 해당 데이터에 적용하려는 다른 유형의 분류와 같은 메타 데이터 확장을 사용하여 다른 모든 거버넌스 기능에 대한 추가 분류를 수행 할 수 있습니다. 그런 다음 다양한 이해 관계자 청중, 특히 모델러와 개발자 간의 비즈니스 데이터 오브젝트를 통해 더 요약하고 의사 소통을 강화할 수 있습니다.
그리고 이것에 대해 매우 중요한 것은 그 뒤에는 매우 강력한 변경 관리 기능을 갖춘 통합 리포지토리입니다. 상당히 복잡하기 때문에 오늘 보여줄 시간이 없었지만 저장소에는 매우 강력한 변경 관리 기능과 감사 추적 기능이 있습니다. 명명 된 릴리스, 명명 된 버전을 수행 할 수 있으며 변경 관리를 수행하는 사용자를위한 기능도 제공하며이를 작업에 바로 연결할 수 있습니다. 개발자가 코드 변경 사항을 작업중인 작업 또는 사용자 스토리와 연결하는 것처럼 오늘날에도 작업을 수행하고 모델 변경 사항을 작업과 연결할 수 있습니다.
다시 말하지만, 그것은 매우 빠른 개요였습니다. 우리가 앞으로 나아갈 때 이러한 주제 중 일부를 분리하는 것에 대해 훨씬 더 깊은 대화에 참여할 수 있도록 식욕을 자극 할 수 있기를 바랍니다. 시간 내 주셔서 감사합니다. Rebecca.
Rebecca Jozwiak : 감사합니다. Ron, 환상적이었고 청중들로부터 많은 질문을 받았지만, 우리 분석가들에게 당신이 말했던 것에 이빨을 가릴 기회를주고 싶습니다. 에릭, 계속하겠습니다. 아마이 슬라이드 나 다른 슬라이드를 다루고 싶다면, 왜 먼저 가지 않겠습니까? 또는 다른 질문.
에릭 리틀 : 물론입니다. 죄송합니다, 레베카? 내가 구체적으로 물어 보거나…
Rebecca Jozwiak : Ron에게 처음 질문을 받았음을 압니다. 지금 그에게 그 중 하나를 요청하고 싶거나 슬라이드 중 일부 또는 질문하고 싶은 관심을 불러 일으키는 다른 것들을 요청하려면? IDERA의 모델링 기능에 대하여.
Eric Little : 네. Ron 중 하나 인 것 같습니다. 여러분이 보여주는 다이어그램은 일반적으로 데이터베이스 구성에서 일반적으로 사용하는 것과 같은 일반적인 종류의 엔터티 관계 다이어그램입니다.
Ron Huizenga : 예, 일반적으로 말하지만 문서 저장소와 해당 유형에 대한 확장 유형이 있습니다. 우리는 실제로 순수한 관계 표기법과는 다른, 실제로 다른 상점에 대한 추가 표기법을 추가했습니다.
Eric Little : 그래프 기반의 모델링 유형을 활용할 수있는 방법이 있습니까? 예를 들어, 최상위 사분면, TopBraid 작곡가 도구 또는 무언가를 한 것으로 가정 해 봅시다. Protégé 또는 FIBO의 재무 담당자와 마찬가지로 시맨틱, RDF 작업에서 많은 작업을 수행하고 있습니다. 이러한 유형의 엔티티 관계형 그래프 유형 모델링을이 도구로 가져와 활용하는 방법이 있습니까? 그것?
Ron Huizenga : 실제로 그래프를 처리하는 방법을보고 있습니다. 현재 그래프 데이터베이스와 해당 유형을 명시 적으로 처리하지는 않지만 메타 데이터를 확장하기 위해 수행 할 수있는 방법을 모색하고 있습니다. 적어도 XML을 시작점으로 가져 오기 위해 XML 변환을 할 수 있다면 XML을 통해 물건을 가져올 수 있습니다. 그러나 우리는이를보다 우아한 방법으로 찾고 있습니다.
또한 우리가 가지고있는 리버스 엔지니어링 브리지 목록도 보여 주었으므로, 우리는 항상 특정 플랫폼을위한 브리지로의 확장을 찾고 있습니다. 이 새로운 구성과 다양한 플랫폼을 수용하기 시작하는 것이 합리적이라면 지속적이고 지속적인 노력입니다. 그러나 나는 우리가 분명히 그 일을하고 있다고 말할 수 있습니다. 예를 들어, MongoDB와 그 유형의 제품에 대해 보여 드린 것은 실제로 자체 제품에서이를 수행하는 최초의 데이터 모델링 공급 업체입니다.
에릭 리틀 : 네. 그러므로 제가 당신에게 한 다른 질문은 지배 구조와 유지의 관점에서 – 당신이 예를 사용했을 때와 같이, “직원”인 사람의 예를 보여 주었을 때, 나는 그것이“ 급여 "를 선택하면"계획 "이 있습니다. 예를 들어 다양한 유형의 직원을 관리 할 수있는 방법이 있습니까? 대규모 아키텍처가 있다고 가정 해 봅시다. 대기업이 있고 사람들이이 도구를 사용하여 작업을 시작하면 여기에는 "직원"이라는 단어가있는 그룹과 "작업자"라는 단어가있는 그룹이 있습니다. 그리고 여기있는 한 사람은 "급여"라고 말하고 다른 사람은 말합니다. "값."
이런 종류의 구별을 어떻게 조정하고 관리하고 관리합니까? 우리가 그래프 세계에서 어떻게 할 것인지 알고 있기 때문에 동의어 목록을 사용하거나 하나의 개념이 있고 몇 가지 속성이 있거나 SKOS 모델에서 선호하는 레이블을 가지고 있다고 말할 수 있습니다. 사용할 수있는 수많은 대체 라벨. 어떻게합니까?
Ron Huizenga : 우리는 몇 가지 다른 방식 으로이 작업을 수행하며 주로 용어에 대해 이야기합시다. 물론 우리가하는 일 중 하나는 정의되거나 승인 된 용어를 원하고 비즈니스 용어집에서 분명히 우리가 원하는 곳입니다. 그리고 우리는 비즈니스 용어집에서 동의어에 대한 링크를 허용합니다. 그래서 당신이 할 수있는 것은 당신이 말할 수 있다는 것입니다. 여기 내 용어가 있습니다.
물론 흥미로운 것은 여러분이 가지고있는 다른 모든 시스템으로이 광대 한 데이터 환경을 살펴보기 시작할 때 거기에 나가서 해당 테이블과 그 유형을 변경할 수 없다는 것입니다. 구입 한 패키지 일 수 있으므로 해당 명명 표준에 해당하므로 데이터베이스 또는 기타 변경을 전혀 제어 할 수 없습니다.
용어 정의를 연관시킬 수있을뿐만 아니라 내가 할 수있는 보편적 인 매핑을 통해, 우리가 무엇을 할 것인지, 어떤 종류의 권장 접근 방식을 통해 무엇을 할 수 있는지에 대한 포괄적 인 논리적 모델을 갖추는 것입니다. 이 다른 비즈니스 개념은 당신이 말하는 것입니다. 비즈니스 용어를 그 용어로 묶어 놓으면 좋은 점은 논리 엔티티를 그대로 나타내는이 구문을 얻은 다음 해당 논리 엔티티에서 해당 논리 엔티티의 모든 구현으로 링크를 시작할 수 있다는 것입니다. 다른 시스템.
그런 다음 여기에서 "사람"이이 시스템에서 "직원"이라고합니다. 여기서“Salary”는이 다른 시스템에서“임금”이라고합니다. 당신이 그것을 볼 수 있기 때문에, 당신은 그것들을 서로 연결했기 때문에 그것들의 모든 다른 표현을 볼 수 있습니다.
에릭 리틀 : 좋아요, 알겠습니다. 그런 의미에서 객체 지향 접근 방식과 비슷하다고 말하는 것이 안전합니까?
Ron Huizenga : 다 소요. 당신이 말할 수있는 것보다 조금 더 집중적입니다. 내 말은, 당신은 수동으로 연결하고 통과하고 검사하고 수행하는 접근법을 취할 수 있습니다. 제가 실제로 이야기 할 기회가 없었던 한 가지는 – 우리는 많은 기능을 가지고 있기 때문에 – Data Architect 툴 자체에 완전한 자동화 인터페이스를 가지고 있습니다. 그리고 매크로 기능은 실제로 도구의 프로그래밍 언어입니다. 우리는 실제로 매크로 쓰기와 같은 일을하고, 나가서 질문하고, 링크를 만들 수 있습니다. 정보를 가져오고 내보내는 데 사용하고, 사물을 변경하거나 속성을 추가하거나, 모델 자체를 기반으로하는 이벤트를 사용하거나, 실제로 나가서 정보를 조사하고 실제로 다른 구조를 채우는 배치로 실행할 수 있습니다. 모델. 따라서 사람들이 활용할 수있는 완벽한 자동화 인터페이스가 있습니다. 그리고 그것들과 유니버설 매핑을 사용하는 것이 그렇게하는 매우 강력한 방법입니다.
Rebecca Jozwiak : 알겠습니다. Ron, Eric에게 감사합니다. 좋은 질문이었습니다. 나는 우리가 시간의 정상을 약간 뛰어 넘고 있다는 것을 알고 있지만, Malcolm에게 Ron의 방법에 대한 몇 가지 질문을 던질 기회를주고 싶습니다. 말콤?
Malcolm Chisholm : 감사합니다, Rebecca. Ron, 매우 흥미 롭습니다. 여기에는 많은 기능이 있습니다. 제가 관심이있는 분야 중 하나는 개발 프로젝트가 있다면 데이터 모델링 담당자가 이러한 기능을 사용하고 데이터 분석가, 데이터 품질 분석가를 통해 비즈니스 분석가와보다 협력 적으로 작업하는 것을 어떻게 보십니까?, 프로젝트의 실제 정보 요구 사항에 대해 궁극적으로 책임을지는 비즈니스 스폰서와 함께. 우리가보고있는 기능으로 데이터 모델러가 실제로 프로젝트를보다 효과적이고 효율적으로 만드는 방법은 무엇입니까?
Ron Huizenga : 여러분이해야 할 첫 번째 작업 중 하나는 데이터 모델러라고 생각합니다. 일부 모델러를 선택하지는 않겠지 만, 어쨌든 – 일부 사람들은 여전히 데이터 모델러는 실제로 게이트 키퍼 유형의 역할이며, 작동 방식을 정의하고 모든 것이 올바른지 확인하는 경비원입니다.
이제는 사운드 데이터 아키텍처와 그 밖의 모든 것을 정의해야한다는 측면이 있습니다. 그러나 더 중요한 것은 데이터 모델러입니다. 제가 컨설팅을 할 때이 점이 상당히 분명하다는 것을 알게되었습니다. – 촉진자가되어야하므로 이들을한데 모아야합니다.
더 이상 데이터베이스를 설계하고, 생성하고, 구축하지는 않을 것입니다.해야 할 일은 리버스 엔지니어링, 정보 가져 오기, 가져 오기 등의 다양한 이해 관계자 그룹과 협력 할 수 있어야한다는 것입니다. 용어집이나 문서에 관계없이 다른 사람들이 공동 작업을 수행하고이를 저장소에 가져 와서 저장소에 개념을 연결하고 해당 사람들과 함께 작업 할 수있는 촉진자가됩니다.
실제로 작업, 토론 스레드 또는 팀 서버에있는 유형의 작업을 통해 사람들이 실제로 공동 작업을하고 질문을하고 최종 제품에 도착할 수있는 협업 유형의 환경에 가깝습니다. 데이터 아키텍처와 조직이 필요합니다. 그런 종류의 대답을 했습니까?
Malcolm Chisholm : 예, 동의합니다. 아시다시피, 촉진 기술은 데이터 모델러에서 매우 바람직한 기술이라고 생각합니다. 나는 우리가 항상 그것을 볼 수는 없다는 데 동의하지만, 나는 그것이 필요하다고 생각하며 때로는 데이터 모델링을 수행하는 데 구석에 머무를 성향이 있다고 제안하지만 실제로 다른 이해 관계자 그룹과 협력해야합니다. 또는 당신은 당신이 다루고있는 데이터 환경을 이해하지 못하며, 그 결과 모델이 어려움을 겪고 있다고 생각합니다. 하지만 그건 내 의견 일뿐입니다.
Ron Huizenga : 비즈니스가 적시에 솔루션을 제공하지 않았기 때문에 IT에서 탈퇴하는 방법에 대한 이력에 대해 슬라이드에서 앞서 언급 한 내용과 그 유형의 것들에 대해 흥미 롭습니다.
나중의 컨설팅 계약에서 제품 관리자가되기 전에 지난 2 년 동안 내가했던 대부분의 프로젝트가 비즈니스 후원을 받았으며, 실제로 비즈니스를 주도한 비즈니스와 데이터 아키텍트라는 것이 매우 흥미 롭습니다. 모델러는 IT의 일부가 아니 었습니다. 우리는 비즈니스 후원 그룹의 일원이었으며 나머지 프로젝트 팀과 함께 작업하는 진행자로 참여했습니다.
Malcolm Chisholm : 매우 흥미로운 점이라고 생각합니다. 우리는 비즈니스가 요구하는 것, 또는 생각하는 것, 프로세스가 아닌 것 등 비즈니스 세계에서 변화가 시작되고 있다고 생각합니다. 그러나 그들은 또한 데이터가 무엇인지에 대해 생각하기 시작했습니다. 내가 다루는 작업, 데이터 요구 사항, 데이터로 처리하는 데이터는 무엇이며, IDERA 제품 및 기능을 통해 이러한 관점을 지원할 수있는 정도는 어느 정도이며 비즈니스 요구도 그래도 여전히 조금 초기입니다.
Ron Huizenga : 동의합니다. 더 많은 방식으로 진행되고 있습니다. 우리는 깨어 난 것을 보았고 데이터의 중요성 측면에서 앞서 언급했습니다. 우리는 IT 초기에 또는 데이터베이스의 진화에서 데이터의 중요성을 보았습니다. 그리고 여러분이 말했듯이, 우리는이 전체 프로세스 관리주기에 들어갔습니다. 프로세스는 매우 중요합니다. 이런 일이 발생하면 데이터의 초점이 사라집니다.
그리고 이제 조직들은 데이터가 실제로 핵심이라는 것을 깨닫고 있습니다. 데이터는 비즈니스에서 수행하는 모든 작업을 나타내므로 정확한 데이터를 보유하고 의사 결정에 필요한 올바른 정보를 찾을 수 있어야합니다. 모든 것이 정의 된 프로세스에서 나오는 것은 아니기 때문입니다. 일부 정보는 다른 것의 부산물이므로 정보를 찾고 의미가 무엇인지 알 수 있으며 궁극적으로 우리가 보는 데이터를 비즈니스를 더 잘 추진하는 데 사용할 수있는 지식으로 변환 할 수 있어야합니다.
Malcolm Chisholm : 지금 당장 어려움을 겪고있는 또 다른 영역은 데이터 라이프 사이클이라고 부르는 것입니다. 즉, 기업을 통과하는 데이터 공급망을 살펴보면 데이터 수집 또는 데이터 캡처 (데이터 입력일 수도 있지만 데이터 공급 업체로부터 엔터프라이즈 외부의 데이터를 가져 오는 경우도 있음)
그런 다음 데이터 캡처에서이 데이터를 표준화하고 필요한 곳으로 배송하는 데 필요한 데이터 유지 관리로 이동합니다. 그런 다음 데이터가 사용되는 실제 지점 인 데이터 사용을 통해 데이터에서 가치를 얻을 수 있습니다.
그리고 예전에는이 모든 것이 하나의 개별 스타일로 이루어졌지만 오늘날에는 분석 환경이 될 수 있으며, 그 이후에는 더 이상 데이터를 저장하지 않는 아카이브, 상점 등이 될 수 있습니다. 그것을 필요로하고 마지막으로 제거 과정을 제거하십시오. 데이터 모델링이이 전체 데이터 수명주기의 관리에 어떻게 적합한가?
Ron Huizenga : 아주 좋은 질문입니다. 제가 오늘 여기서 자세히 설명 할 시간이 없었던 것은 데이터 계보입니다. 실제로 우리가 할 수있는 것은 도구에 데이터 계보 기능이 있으며 실제로 말한 것처럼 ETL 도구에서 일부 데이터를 추출 할 수 있지만 계보를 그려서 만 매핑 할 수도 있습니다. 캡처하고 모델로 가져온 이러한 데이터 모델 또는 데이터베이스는 데이터 연계 다이어그램에서 해당 구성을 참조 할 수 있습니다.
우리가 할 수있는 일은 소스에서 대상까지 데이터 흐름을 그리고 데이터가 다른 시스템을 통해 전송되는 방식과 찾을 수있는 전체 수명주기를 통해 직원을 채용하는 것입니다. 'data – 그것은 몇 년 전에 한 프로젝트를 기반으로하는 제가 가장 좋아하는 것 중 하나입니다. 저는 30 개의 서로 다른 시스템에 직원 데이터가있는 조직과 협력했습니다. 우리가 거기서 일을 한 것 – 그리고 Rebecca가 데이터 연계 슬라이드를 띄 웠습니다 – 이것은 상당히 단순한 데이터 계보 슬라이드입니다. 그러나 우리가 할 수 있었던 것은 모든 데이터 구조를 가져 와서 다이어그램에서 참조하는 것입니다. 실제로 흐름 사이의 흐름을 파악할 수 있으며 흐름에 서로 다른 데이터 엔터티가 어떻게 연결되어 있습니까? 그리고 우리는 그것을 넘어 설 수 있습니다. 이것은 여기서 볼 수있는 데이터 흐름 또는 연계 다이어그램의 일부입니다. 당신이 그것을 넘어 가고 싶다면 우리는이 제품군의 비즈니스 아키텍트 부분을 가지고 있으며 동일한 것이 적용됩니다.
데이터 모델링 환경에서 캡처 한 모든 데이터 구조는 비즈니스 모델링 도구에서 참조 할 수 있으므로 비즈니스 모델 다이어그램 또는 비즈니스 프로세스 다이어그램에서도 원하는 경우 개별 데이터 저장소를 참조 할 수 있습니다. 비즈니스 프로세스 모델의 폴더에서 데이터 모델링 환경을 사용하면서 정보를 소비하거나 생산하는 방법에 대한 CRUD도 지정할 수 있습니다. 영향 및 분석 보고서 및 다이어그램과 같은 것들.
우리가 목표로하고있는 것과 이미 많은 기능을 가지고 있지만, 도구가 계속 발전함에 따라 우리가보고있는 목표와 같은 목표 중 하나는, 엔드-투-엔드, 조직 데이터 계보 및 전체 데이터 수명주기를 매핑 할 수 있습니다.
말콤 키숄 : 알겠습니다. 레베카, 하나 더 허용 될까?
Rebecca Jozwiak : Malcolm, 한 번 더 허락하겠습니다.
Malcolm Chisholm : 정말 감사합니다. 데이터 거버넌스와 데이터 모델링에 대해 생각할 때 어떻게 두 그룹이 효과적으로 협력하고 서로를 이해하게 할 수 있습니까?
Eric Little : 흥미 롭습니다. 실제로 조직에 따라 다르다는 생각이 들었습니다. 초기 계획으로 돌아가는 것은 이니셔티브가 비즈니스 중심의 비즈니스 중심 조직에서 시작되었습니다. 예를 들어, 데이터 아키텍처를 주도하고있었습니다. 우리는 비즈니스 사용자와 밀접한 관련이 있었으며 실제로 데이터 거버넌스 프로그램을 세우는 데 도움을주었습니다. 다시 한 번 더 컨설팅적인 접근 방식이지만 실제로 비즈니스 기능에 가깝습니다.
실제로해야 할 일은 비즈니스를 실제로 이해하고 비즈니스 사용자와 관련이있을 수있는 데이터 모델러 및 설계자가 필요하다는 것입니다. 비즈니스는이를 원하지만 일반적으로 이러한 유형의 프로그램을 돋보이게하는 데 도움이되는 기술 지식이 있습니다. 실제로는 공동 작업이어야하지만 비즈니스 소유 여야합니다.
Malcolm Chisholm : 좋습니다. 훌륭합니다. 감사합니다.
에릭 리틀 박사 : 좋습니다.
Rebecca Jozwiak : 알겠습니다. 정말 감사합니다. 청중 여러분, 우리는 귀하의 질문에 답변을하지 않으실 것이지만, 오늘 그들이 해당 고객에게 전달되도록하겠습니다. 오늘 우리의 손님이 된 Eric, Malcolm 및 Ron에게 대단히 감사합니다. 이것은 좋은 물건이었습니다. 그리고 오늘의 IDERA 웹 캐스트를 즐겼다면 다음 수요일에 IDERA가 핫 테크놀로지에 참여하여 인덱싱 및 Oracle의 과제에 대해 논의 할 것입니다.
정말 고마워요, 여러분 돌봐주세요. 다음에 see겠습니다. 안녕.
