작성자 : Techopedia Staff, 2016 년 11 월 16 일
테이크 아웃 : 호스트 Eric Kavanagh는 Robin Bloor, Dez Blanchfield 및 IDERA의 Ron Huizenga와의 민첩한 개발에서 데이터 모델링의 중요성에 대해 논의합니다.
현재 로그인하지 않았습니다. 비디오를 보려면 로그인 또는 가입하십시오.
에릭 카바나 흐 : 좋아, 신사 숙녀 여러분. 다시 한 번 환영합니다. 수요일 오전 4시 (EST)입니다. 그것은 핫 테크놀로지의 시간이다. 네 확실합니다. 제 이름은 Eric Kavanagh입니다. 호스트입니다.
오늘의 주제에 대해서는 옛날 사람이지만 좋은 사람입니다. 우리의 데이터 관리 환경 인 "민첩한 환경에서의 데이터 모델링"을 형성하고 있기 때문에 매일 더 좋아지고 있습니다. 여러분의 진실에 대한 슬라이드가 트위터 @eric_kavanagh에서 저를 때렸습니다. 우리는 그것을 실제로 그 슬라이드에 올려야합니다. 나는 그것에 착수해야 할 것이다.
그래서 올해는 더워요. 데이터 모델링은 계속되었습니다. 실제로 정보 관리 비즈니스의 중심에 있었고 데이터 모델을 설계하고 비즈니스 모델을 이해하고이를 데이터 모델에 맞추려고 노력했습니다. 정말 당신이하려는 일 이지요?
데이터 모델은 기본적인 방식으로 비즈니스를 나타내므로 이러한 모든 새로운 데이터 소스가 어떻게 게임을 변화시키고 있습니까? 우리는 그것에 대해 알아낼 것입니다. 우리는 당신이 어떻게 민첩하게 일을 처리 할 수 있는지 알아낼 것입니다. 그리고 물론, 그것은 올해의 단어입니다.
로빈 블로어 (Robin Bloor)는 호주 시드니 출신의 수석 분석가 인 데즈 블란 치 필드 (Dez Blanchfield)와 IDERA의 수석 제품 관리자 인 론 후 이젠가 (Ron Huizenga)와 함께 있습니다. 그에게 어려운 질문, 사람들, 어려운 질문. 그걸로 로빈을 발표자로 만들겠습니다.
로빈 블로어 박사 : 좋습니다. 고마워, 에릭 제가 생각한 모델링에 대해 말해야합니다. 실제로 IT 회사가 존재하기 전에 제가 일했던 보험 회사에서 기억한다는 의미에서, 우리는 한 남자가 와서 우리에게 모든 종류를주었습니다. 데이터 모델링 방법에 대한 워크샵. 우리는 약 30 년을보고 있습니다. 30 년입니까? 아마 그보다 더 길거나, 아마 35 년 전에. 길고 오랜 모델링은 실제로 업계의 일부였으며 물론 패션쇼에서 숙녀 들과는 아무런 관련이 없습니다.
우리가 일반적으로하는 일은 저와 Dez가 다른 것들에 대해 이야기하기 때문에 말하고 싶었던 것은 방금 모델링에 대한 전반적인 개요를 줄 것이라고 생각했지만 실제로는 현실화되고 있습니다.
우리는 빅 데이터 현실, 더 많은 데이터, 더 많은 데이터 소스를 가지고 있으며 지난 3-4 년 동안 방정식에 들어간 데이터 스트림을 가지고 있으며 더 큰 부분을 차지하기 시작했습니다. 더 많은 데이터가 추가되고 더 많은 데이터 구조가 사용됨에 따라 데이터를 이해해야 할 필요성이 커지고 변경 률이 증가합니다.
어려운 세상입니다. 여기에 3 년 전에 그린 그림이 있지만 기본적으로 믹스에 스트리밍을 포함시키고 데이터 정제, 데이터 허브, 데이터 링크 등을 생각하면 데이터가 있다는 것을 알 수 있습니다. 많이 움직이지 않는다는 점에서 진정으로 쉬고 있습니다. 그리고 데이터, 스트림 및 모든 트랜잭션 응용 프로그램이 있으며 현재 이벤트, 응용 프로그램에서 발생하는 이벤트 데이터 흐름 및 필요한 모든 람다 아키텍처가 있습니다. 전체 데이터 필드에만 영향을줍니다.
그리고 요즘에는 데이터 레이어가 있다고 생각합니다. 데이터 계층은 일종의 가상 방식으로 존재합니다. 좋은 점은 클라우드에있을 수 있고 데이터 센터에 분산되어 워크 스테이션에 존재할 수 있다는 의미입니다. 데이터 계층은 어느 곳에서나 어느 의미에서든 데이터를 처리하고 데이터를 이동시키기 위해 어느 방향 으로든 시도하는 프로세스가 어디에나 있습니다. 그러나 당신이 그것을 움직일 때 그것이 무엇인지 아는 것도 큰 일입니다.
가장 일반적인 의미에서 데이터 모델링을 살펴보면 이러한 종류의 스택 맨 아래에는 파일과 데이터베이스가 있습니다. 데이터 요소에는 키, 요소 정의, 별명, 동의어, 특정 물리적 형식이 있으며이 메타 데이터 계층이 있습니다.
메타 데이터에 대한 흥미로운 점은 메타 데이터가 전적으로 데이터의 의미를 얻는 방법이라는 것입니다. 실제로 메타 데이터가 없다면 데이터의 의미를 추측 할 수 있지만 많은 어려움이 따릅니다. 메타 데이터가 있어야하지만 의미에는 구조가 있습니다. 나는 의미의 철학에 들어가고 싶지 않지만 데이터를 다루는 방식조차도 데이터에 쉽게 표현되지 않는 인간의 사고와 언어에는 많은 정교함이 있습니다. 그러나 실제로 세계에서 처리하는 데이터의 관점에서도 메타 데이터에는 메타 데이터의 의미와 구조가 있습니다. 즉, 다른 데이터와 관련된 하나의 데이터와 함께 구성 될 때의 의미와 데이터의 의미 다른 데이터와 다시 결합하기 위해 모델링해야합니다. 메타 데이터 태그를 사물에 기록하는 것만으로는 충분하지 않습니다. 실제로 구조 당 의미와 구조 간의 관계를 기록해야합니다.
그런 다음 최상위 계층 인 비즈니스 정의는 일반적으로 메타 데이터간에 의미를 전달하려고 시도하는 계층입니다. 메타 데이터는 컴퓨터에서 데이터가 구성되는 방식과 인간의 의미를 수용하는 데이터 정의 형식입니다. 따라서 해당 계층에 존재하는 비즈니스 용어, 정의, 관계, 엔티티 레벨 개념이 있습니다. 우리가이 계층들 사이에 일관성이 없다면 데이터 모델링이 필요합니다. 실제로 선택 사항은 아닙니다. 자동화 측면에서 실제로 할 수있을수록 더 좋습니다. 그러나 의미와 관련이 있기 때문에 대체하기가 정말 어렵습니다. 레코드 내에서 메타 데이터를 포착하고 일련의 의미에서이를 얻을 수있을 정도로 쉽지만 레코드의 구조 나 레코드의 의미 또는 컨텍스트를 알려주지는 않습니다.
제 생각에 이것은 데이터 모델링에 관한 것입니다. 참고 사항 : 데이터 유니버스가 복잡해질수록 더 모델링해야합니다. 다시 말해, 데이터 레코드에 해당하는 더 많은 인스턴스를 세상에 추가하는 것이 아니라 점점 더 많은 것들에 대한 데이터를 캡처하여 실제로 세상에 더 많은 의미를 추가하는 것과 같습니다. 우리가 이해해야 할 점점 더 복잡한 느낌이되고 있습니다.
이론적으로 데이터 유니버스가 있으며이를 볼 필요가 있습니다. 실제로 실제 메타 데이터는 데이터 유니버스의 일부입니다. 따라서 간단한 상황이 아닙니다. 모델링 시작은 하향식과 상향식입니다. 데이터는 컴퓨터와 프로세스에 의미가 있으며 데이터를 처리해야하지만 그 자체로는 의미가 있습니다. 따라서 데이터에 액세스해야하는 소프트웨어를 충족하는 상향식 의미가 필요하고 인간이 데이터를 이해할 수 있도록 하향식 의미가 필요합니다. 메타 데이터 모델의 구축은 프로젝트가 아니며 결코 프로젝트가 될 수 없습니다. 지속적인 활동입니다 – 존재하는 모든 환경에서 지속적인 활동이어야합니다. 다행히도 실제로는 그렇지 않은 상황이 많으며 그에 따라 제어 할 수없는 환경이 많이 있습니다.
앞으로 기술이 발전함에 따라 모델링이 중요하게 증가합니다. 내 의견이다. 그러나 IoT를 살펴보면 모바일과의 위치 차원이라는 새로운 차원이 도입되었지만 우리는 예전보다 모바일을 더 많이 이해할 수 있습니다. IoT에 도달 한 후에는 실제로는 절대로하지 않아도되었던 특별한 데이터 문제를 검토하고 있으며, 우리가 가진 것을 정확히 이해하고 정확하게 집계 할 수있는 방법을 이해해야합니다. 집계에서 의미를 얻는 것과 관련하여 할 수있는 일과 처리 할 때 할 수있는 일
나는 그것이 충분히 말했다고 생각합니다. 나는 Dez Blanchfield에게 넘어갈 것입니다. Dez Blanchfield는 다른 말을 할 것입니다.
Dez Blanchfield : 감사합니다. 항상 따라야 할 힘든 행동이지만, 이것은 프리 쇼 밴터에서 우리가 동의하고 간략히 말한 주제이며, 일찍 전화를 걸면 아마도 큰 보석을 많이 잡을 것입니다. 테이크 아웃 중 하나이며, 이 특정 천둥을 훔치고 싶지 않지만 공유하고 싶은 프리 쇼 밴터에서 가져온 테이크 아웃 중 하나는 데이터의 여정, 그리고 실제로 데이터를 생성 수명 (년, 월, 주, 일, 시, 분, 초)과는 다른 맥락에서 데이터가 취하는 여정에 대해 생각하면서 적어 놓았습니다. 해당 컨텍스트 내에 위치합니다. 코드를 실행하는 개발자인지, 데이터 전문가인지, 각 요소의 구조와 형식 및 메타 데이터 또는 시스템과 비즈니스가 상호 작용하는 방식에 대해 생각하고 있습니다.
주목할만한 흥미로운 점은 있지만 어쨌든 자세히 살펴 보도록하겠습니다. 특히 데이터 디자인은 모든 데이터와 특히 응용 프로그램 또는 데이터베이스 인프라의 개발에 대해 이야기하는 데 사용하는 문구입니다. 데이터 디자인은 내 마음 속에 모든 것을 잘 담아내는 용어라고 생각합니다. 요즘에는 데이터 디자인에 대해 이야기 할 때 최신 민첩한 데이터 디자인에 대해 이야기합니다. 필자의 견해로는 개발자와 데이터 전문가가 오래 전에 일한 적이 없었습니다. 그들은 그들 자신의 사일로에 있었고 디자인 조각들은 한 사일로에서 다른 사일로로 갔다. 그러나 저는 요즘 매우 많은 견해를 가지고 있습니다. 변화된 사례 일뿐만 아니라 변화해야합니다. 그것은 일종의 필연적이며 응용 프로그램입니다. 개발자와 데이터를 다루는 개발, 스키마 및 필드의 관련 디자인 요소를 수행하는 디자이너, 레코드 및 위치 및 데이터베이스 시스템 및 인프라, 모델링 및 전체 관리 그 주위에 도전하십시오. 그것은 이제 팀 스포츠입니다. 따라서 하늘로 떨어지는 사람들의 시각적으로 흥미로운 이미지를 재생하기 위해 팀 역할을하는 비행기에서 뛰어 내리는 많은 사람들에 대한 저의 그림입니다.
셋째, 이것을 가져 오기 위해 무슨 일이 있었습니까? 글쎄, 1986 년에 히로타카 다케우치 (Hrotaka Takeuchi)와 노나카이 쿠지로 (Ikujiro Nonaka)에게 필사적으로 정의를 시도한 두 명의 신사가 쓴 기사가 있는데, 나는 그것이“스크럼 다운 필드의 이동”이라는 제목의 기사를 제작했다고 생각합니다. 이 스크럼 활동에서 럭비 게임에서 승리하는 방법론에 대한 아이디어는 모두가 한곳에서 돌아 다니며 두 팀은 본질적으로 스크럼이라는 것을 머리에 고정하여 공을 제어하고 필드에서 플레이합니다. 트라이 라인에 도달하고 공으로지면을 터치하고 trine이라는 포인트를 얻으면이 과정을 반복하면 팀에 대한 더 많은 포인트를 얻습니다.
이 기사는 1986 년 하버드 비즈니스 리뷰 (Harvard Business Review)에 실 렸으며 흥미롭게도 실제로 많은 주목을 받았습니다. 그것은 놀라운 새로운 개념을 도입했기 때문에 많은 관심을 받았으며 여기 앞면의 스크린 샷이 있습니다. 그래서 그들은 게임 럭비에서 이러한 개념의 스크럼을 가져 와서 비즈니스, 특히 디자인 및 프로젝트 전달, 특히 프로젝트 전달 게임으로 가져 왔습니다.
scrum이 한 것은 이전에 폭포수 방법론이라고 불리는 PRINCE2 또는 PMBOK와 비교하여 새로운 방법론을 제공했습니다. 알다시피, 이 일과이 일과이 일을하고 순서대로 연결하고 연결하십시오. 주변에있는 모든 점들, 그것은 당신이 가진 것에 달려 있거나, 파트 1에 의존하기 때문에 파트 1을 마칠 때까지 파트 2를하지 마십시오. 그것이 우리에게 준 것은 조금 더 민첩한 새로운 방법론인데, 용어가 유래 된 곳, 우리가 물건을 어떻게 전달하는지, 특히 디자인 및 개발 풀뿌리 프로젝트 전달에 관한 것입니다.
주요 임차인 중 일부는 –이 문제를 해결하기 위해 – 스크럼의 주요 임차인 주위에 있습니다. 그것은 혼란의 두려움에 대해 생각하면 효과적으로 세계가 혼돈의 상태에 존재하지만 흥미로운 행성이 형성되어 건물의 불안정성, 약간 튀는 능력, 실제로 실제로 업무를 수행하고, 자체 구성 프로젝트 팀을 구성하고, 책임감있는 개발, 프로젝트 제공 과정을 통한 학습 및 통제의 다른 유형의 학습 및 통제를 통한 다양한 유형의 학습 및 통제를 통해 호의를 겹칩니다. 그렇다면 비즈니스의 한 부분에서 정보를 가져 와서 아이디어는 있지만 코드를 개발하지 않거나 데이터베이스 및 인프라를 개발하지 않고 사람들에게 데이터를 전달하는 사람들로부터 다른 곳으로 정보를 전송하는 방법은 무엇입니까? 구체적으로 타임 박스 결과. 다시 말해서, 하루 24 시간 또는 일주일 또는 몇 주일 동안이 작업을 수행하고 우리가 할 수있는 일을 확인한 다음 물러나서 살펴 봅시다.
그리고 만약 당신이 말장난을 용서한다면, 이것은 실제로 프로젝트 제공의 새로운 게임이며 여기에 조금 더 나아갈 때 의미가있는 세 가지 핵심 구성 요소입니다. 제품이 있습니다. 무언가를해야하고 그것을 둘러싼 이야기가 필요합니다. 민첩한 모델의 스토리를 만들고 스크럼 방법론을 사용하여 매일 스탠드 업을 통해 민첩한 모델로 작업하여 개발자가 토론하고 수행해야 할 작업을 이해 한 개발자는 진행하고 진행하기 만하면됩니다. 그런 다음 사람들은이 모든 것을 감독하고 그것을 추진할 수있는 방법론을 잘 이해하는 스크럼 마스터에 대해 들었습니다. 우리는 Post-It 노트로 가득 찬 벽과 화이트 보드의 오른쪽에있는이 이미지를 보았으며 칸반 벽으로 사용되었습니다. Kanban이 누구인지 모르는 경우 Kanban 씨가 누구인지, 왜 벽에서 문자 그대로 프로젝트에서 물건을 한 쪽에서 다른쪽으로 옮기는 방식이 바뀌 었는지 Google에 초대합니다.
스크럼 워크 플로는 한 눈에이 작업을 수행합니다. 조직에서 수행하고 싶은 작업 목록을 취하고 24 시간, 한 달 단위로 분류 된 스프린트라고하는 일련의 작업을 통해 실행합니다. 이 증분의 일련의 출력을 얻습니다. PMBOK라고 불리는 것을 개발하는 데 큰 역할을 한 미군과 같은 흐름으로 인해 프로젝트가 전달되는 방식에 큰 변화가있었습니다. 필드에 탱크에 총알이 없으면 쓸모가 없으므로 총알을 넣을 때까지 따라서 1 부는 탱크에 총알을 넣고 2 부는 탱크를 필드에 놓습니다. 불행히도, 개발 세계의 개발자들에게 일어난 일은 어쨌든이 민첩한 방법론을 얻었고 펑크를 질주하면 스프린트에서 평온하게 진행되었습니다.
항상 우리가 민첩성을 생각할 때 데이터베이스와 데이터베이스 세계와 관련된 것이 아니라 개발자를 생각합니다. 애자일은 개발자에게만 국한되지 않기 때문에 불행한 결과였습니다. 사실, 제 생각에 민첩한 용어는 종종 데이터베이스 디자이너 나 설계자가 아닌 소프트웨어 개발자와 독점적으로 잘못 연관되어 있습니다. 소프트웨어 및 응용 프로그램 개발에서 직면하는 동일한 과제는 설계 및 개발, 운영 및 유지 관리, 데이터 인프라 및 특히 데이터베이스와 관련된 모든 문제에 직면 해 있습니다. 이 특정 데이터 캐스트의 행위자에는 데이터 아키텍트, 성형 자, 관리자, 데이터베이스 인프라 관리자 및 실제 데이터베이스 자체가 비즈니스 및 시스템 분석가 및 설계자, 시스템에 대해 생각하고 생각하는 사람들까지 비즈니스 운영과이를 통해 데이터를 전달하는 방법에 대해 설명합니다.
데이터 전문가가 반드시 프로젝트 개발의 모든 구성 요소, 특히 개발에 밀접하게 관여해야한다는 견해를 매우 중요하게 생각한다는 점에서 끊임없이 좌절하기 때문에 정기적으로 제기하는 주제입니다. 우리가하지 않기 위해, 우리는 실제로 좋은 결과를 얻을 수있는 최고의 기회를 제공하지 않습니다. 시나리오가 존재하고 응용 프로그램을 작성하고 개발자가 항상 데이터 전문가가 아니라는 것을 알기 때문에 우리는 종종이 문제에 대해 다시 생각해야합니다. 데이터베이스 작업에는 특히 데이터에 관한 매우 전문적인 기술이 필요하며 경험을 쌓습니다. 밤새 데이터베이스 전문가 또는 데이터 지식 전문가가되는 것은 아닙니다. 이것은 종종 평생의 경험에서 비롯된 것으로, 오늘 Code Code에 실린 Dr. Robin Bloor와 매우 흡사 한 책입니다.
많은 경우에 – 불행한 일이지만 현실입니다 –이 코인에는 두 가지 부분이 있습니다. 즉, 소프트웨어 개발자는 데이터베이스 전문가에 대한 자체적 인 정전이 있고 데이터베이스 설계 모델링에 필요한 기술을 구축했습니다. 모델 개발은 단지 데이터가 어떻게 들어오는 지, 어떻게 데이터를 가져 오는지, 어떻게 보여야하는지, 그렇지 않아야하는지, 또는 의심 할 여지없이 데이터는 일반적으로 소프트웨어 개발자를 위해 설정된 기본 기술로 얻은 것을 이해하고 이해하는 전문가의 엔지니어링을위한 기본입니다. 그리고 우리가 직면 한 일반적인 과제 중 일부는 핵심 데이터베이스 디자인 자체의 기본 생성 및 유지 관리 및 관리, 데이터 및 데이터베이스 인프라를 문서화 한 다음 해당 데이터 자산, 스키마 디자인, 스키마 생성, 스키마 관리 및 유지 관리, 스키마 사용, 이 스키마가 특정 방식으로 설계된 이유에 대한 지식 공유 및 시간이 지남에 따라 발생하는 강점과 약점으로 인해 시간이 지남에 따라 데이터가 변경되고, 데이터 모델링 및 유형 우리가 통과하는 시스템과 데이터에 적용되는 모델. 데이터베이스 코드 생성 및 통합을 수행 한 다음 데이터를 모델링 한 다음 데이터에 대한 보안을 제어하기 위해 더 빠르게 액세스합니다. 데이터의 무결성은 무결성을 유지하면서 데이터를 이동 시키며 메타 데이터가 충분합니까? 판매에서 표의 모든 레코드를보아야합니까, 아니면 게시물에 물건을 보내는 주소, 이름, 성만보아야합니까? 그리고 물론 가장 큰 과제는 완전히 다른 대화 인 데이터베이스 플랫폼을 모델링한다는 것입니다.
저는이 모든 것을 염두에두고이 모든 열반을 가능하게하기 위해서는 데이터 전문가와 개발자 모두가 적절한 도구를 가지고 있으며 이러한 도구가 팀 중심의 프로젝트 제공이 가능해야한다는 것이 매우 중요합니다. 설계, 개발 및 지속적인 운영 유지 보수. 데이터베이스 전문가, 데이터, 스키마, 레코드의 출처, 해당 레코드의 소유자와 관련된 모든 것에 대한 데이터 전문가와 소프트웨어 개발자 간의 단일 프로젝트 협업, 단일 진실 지점 또는 단일 사실 출처와 같은 것을 알고 있습니다. . 저는이 시대에 절대적으로 중요하다고 생각합니다. 우리는이 열반의 데이터를 왕으로 만들 것입니다. 우리가 수동으로하기에는 너무 큰 도전이 있기 때문에 올바른 도구가 있어야합니다. 한 조직 내외로 이사 할 경우, 한 사람이 설정 한 것과 동일한 프로세스 나 방법론을 따르지 않고 기술과 능력을 반드시 이전 할 필요는 없습니다.
그런 점을 염두에두고, IDERA의 좋은 친구에게 가서 그 도구에 대한 정보와 그것이 어떻게 해결되는지에 대해 들어 보겠습니다.
Ron Huizenga : 정말 무대를 잘 설정 해준 로빈과 데즈에게 감사합니다. 제가 말씀 드린 몇 가지 사항에 약간의 중복이있을 것입니다. 그러나 그들은 데이터 모델링 관점에서 제가 이야기하려고하는 일부 개념을위한 매우 견고한 토대를 설정했습니다. 그리고 그들이 말한 많은 것들이 팀과 함께 데이터 모델링 및 데이터 아키텍처에서 컨설턴트로 일할 때 내 경험을 반영합니다. 초기에는 폭포수이며 애자일을 사용하는 프로젝트로 더 현대적인 제품으로 진화했습니다. 솔루션 제공 방법론.
오늘 제가 이야기하고자하는 것은 그러한 경험과 도구에 대한 관점과 그 여정에서 우리를 돕기 위해 우리가 사용하는 도구의 일부 기능에 근거합니다. 내가 아주 간단히 다룰 내용은 스크럼에 대해 자세히 설명하지 않겠다는 것입니다. 우리는 그것이 무엇인지에 대한 정말 좋은 개요를 가졌습니다. 데이터 모델이란 무엇이며 실제로 우리에게 무엇을 의미 하는가에 대해 이야기하겠습니다. 조직에서 민첩한 데이터 모델러 개념을 어떻게 활성화 할 수 있습니까? 데이터 모델러를 어떻게 참여 시키는가, 스프린트 동안 모델러와 건축가의 참여는 무엇입니까, 참여해야하는 활동 유형은 무엇입니까?, 그리고 그 배경으로, 우리가 실제로 그 일을 더 쉽게하는데 도움이되는 몇 가지 중요한 모델링 도구 기능은 무엇입니까? 그런 다음 약간의 마무리 작업을 수행하고 데이터 모델러를 사용함으로써 얻을 수있는 비즈니스 가치와 이점에 대해 조금 이야기하거나 실제로 이야기를하는 방식은 다음과 같습니다. 데이터 모델러가 프로젝트에 완전히 참여하지 못했던 문제와 제가 수년 전에 실제 프로젝트의 전후 이미지에 대한 경험과 결함 차트를 기반으로 보여줍니다. 그리고 몇 가지 요점을 요약 한 다음 그 외에도 질문과 답변을 드리겠습니다.
간단히 말해 ER Studio는 다양한 구성 요소가있는 매우 강력한 제품군입니다. 데이터 모델러와 설계자가 데이터 모델링을 수행하는 데 대부분의 시간을 소비하는 데이터 아키텍트입니다. UML 모델링을 위해 프로세스 모델링을 수행하는 비즈니스 아키텍트 및 소프트웨어 아키텍트와 같이 오늘날 논의하지 않을 다른 구성 요소도 있습니다. 그런 다음 리포지토리 (Repository)가 있습니다. 여기서 우리는 체크인하고 모델을 공유하며 팀이 이들에 대해 협업하고이를 팀 서버에 게시하여 프로젝트에 참여한 여러 이해 관계자 청중이 실제로 아티팩트를 볼 수 있도록합니다. 데이터 제공 관점과 프로젝트 제공 자체에서 수행하는 다른 작업을 통해 다시 작성합니다.
오늘 중점을 두어야 할 것은 데이터 아키텍트에서 볼 몇 가지 사항이며, 리포지토리 기반 측면의 협업이 중요하기 때문입니다. 특히 민첩한 개발 프로젝트뿐만 아니라 앞으로 진행될 모든 유형의 개발에 반드시 필요한 변경 관리와 같은 개념에 대해 이야기 할 때 특히 그렇습니다.
이제 Agile Data Modeler에 대해 잠시 이야기하겠습니다. 프레젠테이션에서 앞서 언급 한 바와 같이, 민첩한 개발 프로세스에 완전히 참여하는 데이터 모델러 및 / 또는 설계자가 있어야한다는 것이 필수적입니다. 역사적으로 일어난 일은 예, 우리는 개발 관점에서 민첩성에 대해 실제로 생각해 왔으며, 실제로 일어나게 된 몇 가지 일이 있습니다. 그것의 일부는 개발 자체가 전개 된 방식의 본질 때문이었습니다. 민첩한 개발이 시작되고이 자체 구성 팀 개념으로 시작했을 때 Kool-Aid를 약간 순수하게 마셨고 극단적 인 프로그래밍 측면에 있다면 다음과 같은 것들에 대한 문자 그대로의 해석이있었습니다. 많은 사람들이 해석 한 자체 구성 팀은 전체 솔루션을 구축 할 수있는 개발자 그룹 만 있으면됩니다. 코드, 데이터베이스 또는 데이터 스토어의 개발을 의미하든 모든 것이 개발자에게 위임되었습니다. 그러나 그 결과는 사람들이 가진 특별한 능력을 잃어 버리는 것입니다. 나는 가장 강력한 팀이 다른 배경을 가진 사람들로 구성된 팀이라는 것을 알았습니다. 강력한 소프트웨어 개발자, 데이터 아키텍트, 데이터 모델러, 비즈니스 분석가 및 비즈니스 이해 관계자의 조합과 같이 모두 협력하여 최종 솔루션을 도출합니다.
오늘도 이야기하고있는 것은 데이터 구성 요소와 관련된 응용 프로그램을 개발하는 개발 프로젝트의 맥락에서이 작업을 수행하는 것입니다. 그러나 그 개발 프로젝트 자체 내에서만 제한된 데이터의 생성 및 소비에 총력을 기울이는 Greenfield 개발 프로젝트가 거의 없다는 것을 알아야하기 때문에 한 걸음 뒤로 물러서야합니다. . 한 걸음 물러서서 데이터 관점과 프로세스 관점에서 전체적인 조직 관점을 살펴 봐야합니다. 우리가 찾은 것은 우리가 사용하는 정보가 이미 조직 어딘가에 존재할 수 있기 때문입니다. 모델러와 건축가로서 우리는 프로젝트 자체에서 그 정보를 어디에서 얻을 수 있는지 알기 위해 그것을 가져옵니다. 또한 개발자가 코드에 대한 디자인 패턴을 가지고있는 것처럼 디자인 패턴을 가지고 있기 때문에 관련된 데이터 구조도 알고 있습니다. 또한 전체적인 조직 관점을 취해야합니다. 우리가 구축하고있는 애플리케이션의 맥락에서 데이터를 볼 수는 없습니다. 데이터를 모델링하고 애플리케이션 자체보다 오래 지속되기 때문에 데이터를 문서화해야합니다. 이러한 응용 프로그램은왔다 갔다 할 수 있지만 데이터를 검토하고 응용 프로그램뿐만 아니라 활동, BI보고 및 다른 응용 프로그램과의 통합, 내부 및 조직 외부에서도 마찬가지입니다. 따라서 데이터의 전체 그림과 데이터의 수명주기를 살펴보고 요람에서 무덤까지 조직 전체에서 정보의 여정을 이해해야합니다.
이제 실제 팀으로 돌아가서 실제로 작업해야하는 방법은 워터 폴 방법론이 너무 느려서 결과를 전달할 수없는 것으로 인식되었습니다. 탱크 예제에서 알 수 있듯이, 한 걸음 씩 계속 걸렸으며 실행 가능한 최종 결과를 제공하는 데 너무 오래 걸렸습니다. 지금 우리가하는 일은 그것의 컴포넌트를 점진적으로 개발하고 사용 가능한 코드 나 사용 가능한 아티팩트를 생성하는 시간을 통해 그것을 반복하는 반복적 인 작업 스타일이 필요하다는 것입니다. 모든 스프린트마다 말할 것입니다. 중요한 것은 사용자 스토리를 구현 가능한 코드 비전과 해당 코드를 지원하는 데이터로 이끌어 내기 위해 협력 할 때 팀의 기술 이해 관계자와 비즈니스 이해 관계자들 간의 협업입니다. 또한 Agile Data Modeler 자체는 조직에 충분한 모델러가 없기 때문에 하나의 데이터 모델러 또는 설계자가 동시에 여러 팀을 지원할 수 있습니다.
그리고 또 다른 측면은 여러 모델러가 있더라도 동시에 비행중인 여러 프로젝트의 협업과이를 공유 할 수있는 도구 세트가 있는지 확인해야합니다. 데이터 아티팩트 및 체크인 및 체크 아웃 기능. 이전 섹션에서 이미 다루었으므로이 과정을 매우 빠르게 진행하겠습니다. 애자일의 진정한 전제는 백 로그, 스토리 또는 요구 사항을 기반으로한다는 것입니다. 반복 내에서 우리는 그룹으로 협력하고 있습니다. 일반적으로 조직에 따라 2 주 또는 1 개월 스프린트가 매우 일반적입니다. 또한 일일 검토 및 스탠드 업 회의를 통해 차단 기능을 제거하고 다른 영역에서 멈추지 않고 모든 측면을 발전시킬 수 있습니다. 그리고이 스프린트에서는 모든 스프린트의 일부로 사용 가능한 결과물을 생산하고 싶습니다.
조금 더 다를 수 있고, 더 확장하면, 스크럼은 여기서 더 구체적으로 이야기 할 방법론이며 기본적으로 몇 가지 다른면으로 이전 그림을 보강했습니다. 일반적으로 제품 백 로그가 있고 스프린트 백 로그가 있습니다. 그래서 우리는 모든 스프린트 반복이 시작될 때“이 스프린트를 무엇을 만들 예정입니까?”라고 말하면서 스프린트 계획 회의에서 완료되는 전반적인 백 로그를 가지고 있습니다. 그런 다음 그와 관련된 작업을 분류하고 매일 4 ~ 4 주 정도의 스프린트에서 실행합니다. 우리는 버닝 차트와 번 다운 차트를 통해 진행 상황을 추적하여 기본적으로 남은 것을 추적하고 개발 속도와 같은 것을 확립하기 위해 구축하는 것을 추적합니다. 일정, 모든 종류의 것들. 스프린트 중에는 몇 달을 지나가는 것이 아니라 짧게 나올 것이며 프로젝트 일정을 연장해야한다는 것을 알기보다는 모든 스프린트 동안 지속적으로 정교화됩니다. 그리고 전체 팀의 일환으로 마지막에 스프린트 검토와 스프린트 회고가 있으므로 다음 반복을 시작하기 전에 수행 한 작업을 검토하고 가능한 방법을 찾고 있습니다. 다음 번에 개선하십시오.
산출물 측면에서 이것은 기본적으로 스프린트에서 진행되는 일반적인 유형을 요약 한 슬라이드입니다. 그리고 그것은 매우 개발 중심적이므로 기능 설계 및 사용 사례, 설계 코드 테스트 수행, 이 상자를 볼 때 여기에서 볼 수있는 많은 것들을 살펴볼 것입니다. 어떤 수준이든 자세하게 설명하면 개발 지향적입니다. 그리고 여기에 묻혀있는 것은 이러한 노력을 지원하기 위해 이와 함께 제공되는 데이터 제공 물이 필요하다는 사실입니다. 따라서 백 로그, 요구 사항 및 사용자 스토리와 같은 것을 볼 때마다 수행해야 할 개발 부분, 수행해야 할 분석 부분, 방법에 대해 살펴 봐야합니다. 데이터 디자인 또는 데이터 모델과 관련하여 비즈니스 용어집과 같은 것은 어떻습니까? 비즈니스 의미를 우리가 생산하는 모든 아티팩트와 연관시킬 수 있습니까? 모든 스프린트에서 사용 가능한 결과물을 생산해야하기 때문입니다.
어떤 사람들은 모든 스프린트가 끝날 때마다 사용 가능한 코드를 만들어야한다고 말할 것입니다. 반드시 그런 것은 아닙니다. 즉, 가장 순수한 개발 관점에서 그렇습니다. 특히 처음에는 아주 자주 – 스프린트 제로 (sprint zero)와 같은 것들이있을 수 있습니다. 장소. 세부 정보를 작성하기 전에 시작하기위한 높은 수준의 디자인으로, 다른 청중을 참여시킨 다음 팀으로 발전하기 전에 시작 스토리 나 요구 사항을 정리해야합니다. 항상 약간의 준비 시간이 있으므로 스프린트 제로 또는 스프린트 제로와 하나를 가질 것입니다. 솔루션을 제공하는 데 전념하기 전에 약간의 시작 단계가 될 수 있습니다.
이 맥락에서 데이터 모델에 대해 매우 간략하게 이야기하겠습니다. 사람들이 데이터 모델을 생각할 때, 데이터 모델은 서로 다른 정보가 어떻게 연결되어 있는지를 보여주는 그림이라고 생각합니다. 이는 빙산의 일각 일뿐입니다. 민첩한 개발 및 기타 사항에 관계없이 데이터 모델링에 접근하려는 방식의 정신을 완전히 구현하려면 데이터 모델이 올바르게 수행되면 조직에서 해당 데이터가 의미하는 바에 대한 완전한 사양이됩니다. 백엔드 데이터베이스에 배치되는 방법. 데이터베이스라고 할 때, 우리가 사용하는 관계형 데이터베이스뿐만 아니라 빅 데이터 또는 NoSQL 플랫폼이있는 오늘날의 아키텍처에서 데이터베이스를 호출하는 것을 선호합니다. 또한 빅 데이터 저장소는 정보를 소비하고 솔루션으로 가져 오는 방법뿐만 아니라 솔루션에서 정보를 유지하거나 저장하는 방법과 관련하여 다양한 데이터 저장소를 결합 할 수 있기 때문입니다.
주어진 응용 프로그램의 맥락에서 여러 데이터베이스 또는 데이터 소스를 동시에 사용하고있을 수 있습니다. 매우 중요한 것은 전체 사양을 가질 수 있기를 원한다는 것입니다. 따라서 스프린트 조직적 관점에서 의미하는 바에 대한 논리적 사양, 데이터를 실제로 정의하는 방법, 데이터 간의 관계 측면에서 물리적 구성의 의미 데이터베이스, 참조 무결성 제약 조건, 검사 제약 조건, 일반적으로 생각하는 모든 유효성 검사 항목. 설명 메타 데이터는 매우 중요합니다. 애플리케이션에서 데이터를 활용하는 방법을 어떻게 알 수 있습니까? 이를 정의하고 의미가 무엇인지 알거나 해당 응용 프로그램에서 올바른 데이터를 사용하고 있는지 확인하기 위해 어디에서 왔는지 알 수없는 경우 – 올바른 명명 규칙, 전체 정의가 있는지 확인하십시오. 이 테이블을 구성하는 열과 테이블 – 그리고이 응용 프로그램을 수행 할 때에도이 정보는 다른 이니셔티브에 사용되므로이 지식 기반을 구축해야하므로이를 활용하는 방법에 대한 자세한 배포 노트 향후 구현을 위해 문서화 된 모든 내용을 갖추 었습니다.
다시 한 번, 데이터 유형, 키, 인덱스 등의 데이터 모델 자체에 이르기까지 데이터 모델 자체가 작동하는 많은 비즈니스 규칙을 구현합니다. 관계는 다른 테이블 간의 제약 조건 만이 아닙니다. 이들은 종종 데이터의 작동 방식과 데이터가 응집력있는 단위로 작동하는 방식에 대한 진정한 비즈니스 규칙이 무엇인지 설명하는 데 도움이됩니다. 물론 가치 제한이 매우 중요합니다. 물론, 우리가 끊임없이 다루고있는 것들 중 하나가 점점 더 널리 퍼지고있는 것은 데이터 거버넌스와 같은 것들입니다. 따라서 데이터 거버넌스 관점에서 볼 때 정의해야 할 사항도 살펴 봐야합니다. 보안 분류와 같은 것을 정의하려고합니다. 우리는 어떤 유형의 데이터를 다루고 있습니까? 마스터 데이터 관리로 간주되는 것은 무엇입니까? 우리가 만드는 거래 저장소는 무엇입니까? 이 애플리케이션에서 어떤 참조 데이터를 활용하고 있습니까? 모델에서 제대로 캡처되었는지 확인해야합니다. 또한 데이터 품질 고려 사항에는 다른 조직보다 조직에 더 중요한 특정 정보가 있습니다.
저는 12 개가 넘는 레거시 시스템을 새로운 비즈니스 프로세스로 교체하고이를 대체 할 새로운 응용 프로그램 및 데이터 저장소를 설계하는 프로젝트에 참여했습니다. 정보의 출처를 알아야했습니다. 비즈니스 관점에서 가장 중요한 정보 중 하나 인 여기에있는이 특정 데이터 모델 슬라이드를 살펴보면이 특정 개체의 맨 아래 상자가 작은 하위 집합이라는 것을 알 수 있습니다. 실제로 비즈니스 가치를 포착 할 수있었습니다. 조직 내에서 이러한 다양한 구성에 대해 이러한 유형의 항목에 대해 높거나 중간에 상관없이 또한 마스터 데이터 클래스, 마스터 테이블인지, 참조인지, 트랜잭션인지 여부 등을 캡처했습니다. 따라서 모델 자체에서 메타 데이터를 확장하여 데이터 자체 이외의 많은 다른 특성을 제공 할 수 있으므로 원래 프로젝트 외부의 다른 이니셔티브를 통해 실제로 진행할 수있었습니다. 이제 한 슬라이드에 많은 내용이 있었으므로 나머지 부분을 상당히 빠르게 살펴 보겠습니다.
이제 우리는 이러한 다른 스프린트를 겪을 때 데이터 모델러가하는 일에 대해 매우 빠르게 이야기 할 것입니다. 우선, 스프린트 계획 세션에 참여하여 사용자 스토리를 작성하고 스프린트에서 제공 할 내용을 커밋하고이를 어떻게 구성하고 제공 할 것인지 파악합니다. 내가 데이터 모델러로하고있는 일은 다른 개발자 또는 다른 사람들과 별도의 영역에서 작업 할 것이라는 것을 알고 있습니다. 따라서 우리가 가질 수있는 중요한 특성 중 하나는 데이터 모델을 수행 할 때 해당 영역을 하위 영역이라고 부르든 관계없이 해당 용어를 용어로 부르는 것입니다. 우리가 모델을 구축 할 때 우리는 또한 다른 하위 모델 관점에서 모델을 보여 주므로, 다른 청중은 그들과 관련된 것을보고 개발하고 발전시키는 것에 집중할 수 있습니다. 그래서 누군가 애플리케이션의 일정 부분을 작업하고 누군가가 주문 항목을 작업하여 다른 모든 작업을 단일 스프린트로 수행 할 수도 있지만, 하위 모델을 통해서만 관점을 제공 할 수 있습니다. 그들이 일하고있는 지역에 적용하십시오. 그런 다음 전체 모델과 하위 모델의 전체 구조로 롤업하여 다른 사용자에게 필요한 것을 제공합니다.
우리가 원하는 데이터 모델링 관점의 기본 사항은 스프린트의 끝이든 끝이든 우리가 할 수있는 일 중 하나가 있기 때문에 항상 되돌아 갈 수있는 기준을 가지고 있다는 것입니다. 몇 가지 스프린트 중에서, 우리는 시작한 곳을 알고 싶어하며 항상 스프린트에서 델타가 무엇인지, 또는 스프린트에서 우리가 생산 한 것의 차이점을 알기위한 기준을 가지고 있습니다. 또한 빠른 처리가 가능하도록해야합니다. 데이터 모델러로 들어 왔지만“아니요, 아니요, 그렇게 할 수 없습니다. 우리는이 모든 것을 먼저해야합니다.”라는 전통적인 게이트 키퍼 역할을한다면 실제로 필요할 때 팀에서 제외 될 것입니다. 모든 민첩한 개발 팀에 적극적으로 참여합니다. 그것은 주어진 스프린트를 수행하는 마차에서 떨어지는 것들을 의미하며 나중에 스프린트에서 픽업합니다.
예를 들어, 제가 말씀 드린 주문 입력 부분과 같이 개발을 진행하기 위해 데이터 구조에 집중할 수 있습니다. 나중에 스프린트에서, 당신은 되돌아 와서 당신이 만든 아티팩트 주변의 데이터 딕셔너리에 대한 문서와 같은 데이터를 채울 수 있습니다. 한 번의 스프린트로 그 정의를 완성하지는 않을 것입니다. 개발자가 응용 프로그램을 작성하는 데 바쁘고 데이터 저장소에 대한 지속성이있을 때 비즈니스 분석가와 함께 정보를 채울 수있는 시간이 있기 때문에 산출물을 계속해서 증가시킬 것입니다. 병목 현상이 발생하지 않도록하고 싶습니다. 개발자와 협력하는 방법에는 여러 가지가 있습니다. 우리는 디자인 패턴을 가지고 있기 때문에 모든 참가자가 먼저 참여할 수 있으므로 모델에 넣을 것이라고 말할 디자인 패턴이있을 수 있습니다. 개발자 패턴을 개발자의 샌드 박스 데이터베이스로 푸시 한 다음 작업을 시작하고 변경을 요청하십시오.
개발자가 작업하고있는 다른 영역이있을 수 있으며, 작업중인 항목이 있고 일부 프로토 타입을 작성하여 자체 개발 환경에서 몇 가지를 시도해 볼 수 있습니다. 우리는 그들이 작업 한 데이터베이스를 가져 와서 모델링 도구로 가져 와서 가지고있는 모델과 비교 한 다음 변경 사항을 해결하고 다시 푸시하여 코드를 리팩터링하여 올바른 데이터 구조를 따르도록합니다. 우리가 필요로하는 그것들은 우리가 이미 다른 곳에서 가지고 있었던 것들을 만들었을 수 있으므로 올바른 데이터 소스로 작업하고 있는지 확인하십시오. 우리는 이것을 스프린트까지 계속 반복하여 전체 데이터 제공 물, 전체 문서 및 우리가 생산하는 모든 데이터 구조의 정의를 얻습니다.
매우 우수한 배송 측면에서 내가 참여한 가장 성공적인 애자일 프로젝트는 전체 물리적 데이터베이스 사양에 대한 모든 변경 사항을 모델로하는 철학입니다. 본질적으로 데이터 모델은 우리가 만들고있는 새로운 작업에 대해 작업중인 배포 된 데이터베이스가되며 다른 외부 데이터베이스에서 소비하는 경우 다른 데이터 저장소에 대한 전체 참조를 갖습니다. 그 일부로 매번 전체 생성을 수행하는 것보다 증분 스크립트를 생성합니다. 그리고 우리는 디자인 패턴을 활용하여 우리가 작업하고있는 다른 개발 팀과 함께 스프린트를 진행하는 데있어 빠른 발전을 제공합니다.
스프린트 활동에서도 비교 / 병합의 기준이되므로 각 변경 사항을 모델링하는 아이디어를 생각해 보자. 우리가 변화를 할 때마다, 우리가하고 싶은 것은 변화를 모델링하고 싶고 매우 중요한 것, 최근까지 데이터 모델링에서 누락 된 것, 실제로, 우리가 다시 소개 할 때까지, 모델링을 연관시키는 능력입니다 실제로 이러한 변경이 발생하도록하는 사용자 스토리 및 작업이 포함 된 작업 및 결과물. 우리는 개발자가 코드를 확인하는 것과 같은 방식으로 모델 변경 사항을 확인할 수 있기를 원합니다. 사용자 스토리를 참조하여 처음 변경 한 이유를 알 수 있습니다. 그렇게하면 증분 DDL 스크립트를 생성하고 게시하여 다른 개발 결과물에서 픽업하여 빌드 솔루션에 체크인 할 수 있도록 게시합니다. 다시 한 번, 하나의 모델이 있거나 여러 팀과 협력 할 수 있습니다. 제가 말씀 드렸듯이, 어떤 것은 데이터 모델러에서 시작된 것이고, 다른 것들은 개발자에 의해 시작된 것입니다. 그리고 우리는 중간에서 만나서 최고의 디자인을 완성하고 앞으로 나아가서 제대로 설계되었는지 확인합니다. 전반적인 데이터 구조. Null이 아닌 null 값, 참조 제약 조건, 기본적으로 제약 조건 확인, 일반적으로 생각하는 모든 것을 포함하여 앞으로 나아갈 때 데이터 모델에 모든 적절한 구성을 갖도록하는 원칙을 유지해야합니다. .
이제이 작업을 수행하는 데 도움이되는 몇 가지 도구의 스크린 샷 몇 개만 살펴 보겠습니다. 제가 중요하게 생각하는 것은 협업 리포지토리를 보유하는 것입니다. 따라서 데이터 모델러로서 할 수있는 작업은 백그라운드에서 데이터 모델의 일부의 일부입니다. 우리가 할 수있는 일을 할 때 다시 점검 할 때 변경 한 사항에 대한 변경, 수정, DDL 스크립트 생성에 필요한 개체에 대한 작업 만 수행 할 수 있습니다. 따라서 ER Studio에서는 예를 들어, 작업 할 개체 또는 개체 그룹을 확인할 수 있으며 전체 모델이나 하위 모델을 확인할 필요가 없으며 관심있는 항목 만 확인할 수 있습니다. 그 후 우리가 원하는 것은 체크 아웃 또는 체크인 시간입니다. 서로 다른 개발 팀이 다른 방식으로 작업하기 때문에 두 가지 방식을 모두 수행합니다. 우리는이를 요구 사항을 추진하는 사용자 스토리 또는 작업과 연관시키고 개발자가 코드를 개발하고 체크인하는 것과 동일한 사용자 스토리 또는 작업이되도록하려고합니다.
다음은 변경 관리 센터 중 하나의 두 화면에 대한 매우 빠른 스 니펫입니다. 이 작업은 여기서 자세히 다루지 않겠지 만 사용자가보고있는 것은 사용자 스토리 또는 작업이며 실제 변경 레코드를보고있는 각 사용자 아래에 들여 쓰기됩니다. 자동 변경 레코드는 다음과 같습니다. 체크인 및 체크 아웃을 수행하며 해당 변경 기록에 대한 자세한 설명을 추가 할 수 있습니다. 작업과 관련되어 있으므로 예상대로 작업마다 여러 변경 사항을 가질 수 있습니다. 그리고 우리가 그 변화 기록을 볼 때 우리는 그것을보고 더 중요한 것을 볼 수 있습니다. 실제로 우리는 무엇을 바 꾸었습니까? 이 특별한 점에서 강조된 이야기에는 한 가지 유형의 변경이 있었으며 실제 변경 레코드 자체를 살펴보면 변경 된 모델의 개별 부분을 식별했습니다. 나는 여기에서 몇 가지 속성을 변경하고, 그것들을 다시 시퀀싱했으며, 증가하는 DLL에서 생성되도록 변경해야 할 뷰를 가져 왔습니다. 기본 개체에 대한 모델링 일뿐만 아니라 이와 같은 고성능 모델링 도구는 데이터베이스 또는 데이터 모델의 종속 개체를 통해 리플되어야하는 변경 사항도 감지합니다.
개발자와 함께 작업하고 샌드 박스에서 작업을 수행하는 두 가지 다른 작업으로이 작업을 수행하고 차이점이 어디에 있는지 비교하고보고 싶다면 오른쪽과 왼쪽의 비교 / 병합 기능을 사용합니다. 측면. "여기에 왼쪽에 모델이 있고, 오른쪽에 데이터베이스가 있습니다. 차이점을 알려주세요."그런 다음 데이터베이스에 항목을 넣거나 넣지 않더라도 이러한 차이점을 해결하는 방법을 선택하고 선택할 수 있습니다. 데이터베이스에 모델로 가져 오는 것들이 있습니다. 양방향으로 진행하여 소스와 대상을 동시에 업데이트하여 양방향으로 진행 한 다음 증분 DDL 스크립트를 생성하여 이러한 변경 사항을 데이터베이스 환경 자체에 배포 할 수 있습니다. 이는 매우 중요합니다. 우리가 할 수있는 일은 언제라도이 비교 및 병합 기능을 사용할 수 있다는 것입니다. 도중에 스냅 샷을 찍는 경우 항상 한 스프린트의 시작을 다른 스프린트의 시작 또는 끝과 비교하여 볼 수 있습니다 특정 개발 스프린트 또는 일련의 스프린트에서 수행 된 작업의 전체 증분 변경.
이것은 대체 스크립트의 매우 빠른 예입니다. 데이터베이스 작업을 한 모든 사용자는 이러한 유형의 것을 보았을 것입니다. 이것은 코드에서 대체 스크립트로 푸시하여 우리가 확인하도록합니다. 여기에 물건을 보관하십시오. 혼란을 줄이기 위해 여기에서 가져온 것은 이러한 변경 스크립트를 사용하여 수행하는 것입니다.이 테이블에도 데이터가 있다고 가정하므로 임시 테이블의 정보를 가져 오는 DML도 생성합니다. 새로운 데이터 구조로 다시 밀어 넣으면 구조뿐만 아니라 해당 구조에 이미 포함되어있는 데이터도 살펴볼 수 있습니다.
자동화 된 빌드 시스템에 대해 매우 빠르게 이야기하려고합니다. 민첩한 프로젝트를 수행 할 때는 자동화 된 빌드 시스템과 함께 작업하므로 빌드가 중단되지 않도록 서로 다른 결과물을 함께 체크인해야합니다. 즉, 우리는 결과물을 동기화하고, DDL 스크립트로 이야기 한 변경 스크립트를 체크인해야하며, 해당 애플리케이션 코드를 동시에 체크인해야하며, 현재 많은 개발자가 개발하지 않습니다. 데이터베이스와 해당 유형에 대해 직접 SQL로 수행됩니다. 우리는 종종 지속성 프레임 워크를 사용하거나 데이터 서비스를 구축하고 있습니다. 이러한 프레임 워크 또는 서비스에 대한 변경 사항을 정확히 동시에 체크인해야합니다. 일부 조직에서는 자동화 된 빌드 시스템으로 이동하며, 민첩한 방법론에서 빌드가 중단되면 앞으로 나아 가기 전에 빌드를 수정하여 모든 작업을 진행하기 전에 작업 솔루션이 있음을 알 수 있습니다. 제가 참여한 프로젝트 중 하나 인 우리는 이것을 극도로 취했습니다. 실제로 빌드가 중단되어 실제로 비즈니스 사용자와 같은 지역에있는 여러 컴퓨터에 연결된 경우 빨간색 깜박이는 표시등 만있었습니다. 경찰차의 상단처럼. 그리고 빌드가 고장 나면 그 빨간색으로 깜박이는 불빛이 꺼지기 시작했고 우리는 그것이 갑판에 모두 있다는 것을 알았습니다. 빌드를 수정하고 우리가하고있는 일을 진행하십시오.
다른 것들에 대해 이야기하고 싶습니다. 이것은 ER Studio의 고유 한 기능입니다. 이러한 아티팩트를 이러한 지속성 경계의 개발자로 구축하려고 할 때 실제로 도움이됩니다. 비즈니스 데이터 객체라는 개념과 이 매우 단순한 데이터 모델을 예로 들면 지속성 경계가있는 엔터티 또는 엔터티 그룹을 캡슐화 할 수 있습니다. 데이터 모델러로서 구매 주문 헤더, 주문 정렬 및 기타 세부 테이블과 같은 방식으로 생각할 수있는 곳에서 데이터 서비스 개발자는 데이터가 다른 데이터에 어떻게 지속되는지 알아야합니다. 구조. 개발자는 구매 주문과 같은 것을 전체적인 대상으로 생각하고 특정 대상을 만드는 방법과의 계약을 생각합니다. 우리는 데이터 서버를 구축하는 사람들이 그 아래에있는 것을 볼 수 있도록 기술적 세부 사항을 노출 할 수 있으며 다른 청중을 복잡성으로부터 보호하여 서로 다른 상위 수준의 개체를 볼 수 있으며 비즈니스와의 통신에도 매우 효과적입니다. 서로 다른 비즈니스 개념의 상호 작용에 대해서도 이야기 할 때 분석가 및 비즈니스 이해 관계자.
이것에 대한 좋은 점은 그것들을 건설적으로 확장하고 축소하여 비즈니스 데이터 객체 자체에 포함 된 구문에서 시작하더라도 상위 객체 간의 관계를 유지할 수 있다는 것입니다. 이제 모델러로서 스프린트 종료까지, 스프린트 마무리가 끝날 때해야 할 일이 많이 있습니다. 다음 스프린트를 위해 하우스 키핑이라고 부릅니다. 내가 명명 된 릴리즈라고 부르는 모든 스프린트는 이제 릴리즈가 끝났을 때의 기준을 제공합니다. 즉, 앞으로 저의 기준, 저장소에서 만들고 저장하는 모든 기준 또는 이름이 지정된 릴리스는 비교 / 병합을 수행하는 데 사용할 수 있으므로 다른 스프린트에서 주어진 스프린트의 끝과 항상 비교할 수 있습니다. 데이터 모델이 변경되는 과정에서 변경 사항이 무엇인지 아는 것이 매우 중요합니다.
또한 스프린트의 처음부터 끝까지 다시 비교 / 병합을 사용하여 델타 DDL 스크립트를 작성합니다. 전체 증분 스크립트를 체크인했을 수도 있지만, 필요한 경우 다른 샌드 박스를 세우기 위해 배포 할 수있는 스크립트가 있으므로 스프린트 시작 부분에이 스크립트가 있다고 말할 수 있습니다. 이를 통해 다음 스프린트에서 시작하기위한 데이터베이스를 샌드 박스로 구축하고 이러한 기능을 사용하여 스탠드 업 QA 인스턴스와 같은 작업을 수행 할 수 있으며 궁극적으로 변경 사항을 프로덕션으로 푸시하여 여러 가지 작업을 진행하려고합니다. 동시에. 다시, 우리는 스프린트 계획 및 회고전에 전적으로 참여합니다. 회고전은 실제로 배운 교훈이며 매우 중요합니다. 민첩한 동안 매우 빨리 갈 수 있기 때문에 지금처럼 성공을 멈추고 축하해야합니다. 무엇이 잘못되었는지 파악하고 다음에 더 나아질 수 있지만 앞으로 나아가는 스프린트에서 앞으로 나아갈 때 올바른 일을 축하하고 쌓아 올리십시오.
이제 비즈니스 가치에 대해 매우 빠르게 이야기하려고합니다. 몇 년 전에 민첩한 프로젝트로 시작된 프로젝트가 있었으며 극단적 인 프로젝트 였기 때문에 모든 일을하는 개발자 일 뿐인 순수한 자체 구성 팀이었습니다. 간단히 이야기하자면, 이 프로젝트는 지연되고 있었고, 그들은 더 많은 기능을 추진하는 것보다 실제로 발견 된 결함을 교정하고 수정하는 데 점점 더 많은 시간을 소비하고 있다는 사실을 발견했습니다. 번 다운 차트에서 그들은 엄청난 비용으로 6 개월 동안 프로젝트를 확장해야했습니다. 우리가 살펴 보았을 때 문제를 해결하는 방법은 프로젝트 자체에 관련된 숙련 된 데이터 모델러와 함께 적절한 데이터 모델링 도구를 이용하는 것입니다.
이 특정 차트 에서이 세로 막대를 보면 누적 결함 대 누적 객체가 표시되며 제약 조건이있는 테이블과 해당 유형의 테이블과 같은 생성 된 데이터 객체 또는 구조에 대해 이야기하고 있습니다. 데이터 모델러가 도입되기 전에는 결함 수가 실제로 초과되어 해당 시점까지 생성 된 실제 개체 수에 비해 약간의 차이가 발생하기 시작했습니다. 21 주 후, 즉 데이터 모델러가 들어 왔을 때, 많은 것들을 고쳐야 할 것에 기초하여 데이터 모델을 리팩토링 한 다음 프로젝트 팀의 일원으로 모델링을 시작했습니다. . 그리고 스프린트 반 정도 안에 개발자 스틱이 아닌 데이터 모델링 도구에서 생성되어 생성 및 생성 된 객체 및 데이터 구성의 수가 크게 증가했습니다. 환경에 구축하고 적절한 참조 무결성과 그에 필요한 다른 구성 요소가 있기 때문에 정확했습니다. 거의 평평한 사람들에 대한 결함 수준. 적절한 조치를 취하고 데이터 모델링이 완전히 수행되도록함으로써 프로젝트는 훨씬 더 높은 수준의 품질로 제 시간에 제공되었으며 실제로 이러한 단계가 수행되지 않으면 전혀 제공되지 않았습니다. 적절한 애자일 실패가 있으며, 올바른 역할을 수행하는 데 적합한 사람들을 참여 시키면 애자일 성공도 많이 있습니다. 저는 운영 분야의 민첩성을 크게지지하지만 민첩한 유형의 노력을 진행할 때 프로젝트 팀과 관련된 모든 올바른 그룹의 기술을 보유하고 있는지 확인해야합니다.
요약하면, 데이터 설계자와 모델러는 모든 개발 프로젝트에 참여해야합니다. 데이터 모델러와 설계자로서 주어진 개발 프로젝트의 데이터 구조뿐만 아니라 데이터가 조직에 존재하는 위치와 데이터의 출처 및 출처를 파악하기 때문에 모든 것을 하나로 묶는 접착제입니다. 우리가 작업하고있는 특정 응용 프로그램 외부에서 사용되고 사용됩니다. 복잡한 데이터 관계를 이해하고 관리 관점에서 문서를 매핑하고 전체 데이터 환경이 어떻게 보이는지 이해하는 것이 무엇보다 중요합니다.
그것은 제조와 같습니다. 나는 제조업 배경에서 왔습니다. 결국에는 품질을 검사 할 수 없습니다. 설계에 품질을 향상시킬 수 있어야합니다. 데이터 모델링은 효율적이고 비용 효율적인 방식으로 설계에 품질을 구축하는 방법입니다. . 그리고 다시 한 번 기억해야 할 것은 – 이것은 사소한 것이 아니라 진실입니다 – 응용 프로그램이왔다 갔다하고, 데이터는 기업의 중요한 자산이며 모든 응용 프로그램 경계를 뛰어 넘습니다. 응용 프로그램을 넣을 때마다 이전에 제공된 다른 응용 프로그램에서 데이터를 보존하라는 요청을 받게되므로 시간이 지남에 따라 지속적으로 유지 관리해야하는 중요한 기업 자산임을 기억하면됩니다.
그리고 그게 다야! 여기에서 우리는 더 많은 질문을 할 것입니다.
에릭 카바나 흐 : 좋아, 우선 로빈에게 넘겨 줄게. 그런 다음 데즈, 몇 가지 질문이 있습니다. 가져 가세요, 로빈
로빈 블로어 박사 : 좋습니다. 솔직히 말해서 민첩한 개발 방법에 아무런 문제가 없었으며 여기에서하고있는 일이 저에게 의미가있는 것 같습니다. 1980 년대에 실제로 통제에서 벗어난 프로젝트와 관련하여 실제로 발생하는 문제는 특정 단계를 넘어 실수가 지속되는 경우라는 점을 지적한 것을 기억합니다. 스테이지를 제대로 맞추지 못하면 문제를 해결하기가 점점 더 어려워집니다. 여기서하고있는 것 중 하나 – 그리고 이것이 슬라이드라고 생각합니다 – 그러나 여기서하고있는 것 중 하나입니다. 제 생각에는 스프린트 제로에서 실제로 결과물을 고정하려고 노력하기 때문에 절대적으로 중요합니다. 결과물을 고정하지 않으면 결과물이 모양이 바뀝니다.
그건 제 의견입니다. 또한 제 의견입니다. 실제로 데이터 모델링을 특정 수준의 세부 정보로 가져와야한다는 아이디어는 없습니다. 내가 완전히 이해하지 못했기 때문에 시도하고 수행하고 싶은 것은, 이 프로젝트 중 하나의 크기, 진행 방식, 누가, 당신이 아는가, 문제가 발생한 곳은 해결 되었습니까? 저는이 슬라이드가 그 중심에 있다고 생각하기 때문에 조금 더 자세히 설명해 주시면 매우 감사하겠습니다.
Ron Huizenga : 물론입니다. 몇 가지 예제 프로젝트를 사용하겠습니다. 실제로 올바른 사람들을 참여시키고 데이터 모델링을 수행함으로써 다시 시작된 레일은 모든 것이 실제로 설계를 더 잘 이해하고 더 나은 구현 설계를 갖도록하는 방법이었습니다. 모델링을 통해 진행됩니다. 모델링 할 때 사람들이 일반적으로 데이터베이스 환경으로 직접 들어가는 것처럼 빌드를 고수 할 필요없이 DDL과 툴의 모든 것을 툴에서 생성 할 수 있기 때문에 DDL을 생성 할 수 있기 때문입니다. 그리고 개발자들에게 일어날 전형적인 일은 그들이 거기에 들어가서 말할 것입니다. 알겠습니다. 저는이 테이블이 필요합니다. 주문 입력을하고 있다고 가정 해 봅시다. 그래서 그들은 주문 헤더와 주문 세부 사항 테이블 및 그 유형의 물건을 만들 수 있습니다. 그러나 그들은 외래 키 관계를 나타 내기 위해 제약 조건이 있는지 확인하는 것을 종종 잊거나 무시합니다. 키가 정확하지 않을 수 있습니다. 명명 규칙도 의심 스러울 수 있습니다. 예를 들어 이름이 다른 여러 테이블이 표시되는 경우와 같이 환경에 몇 번이나 들어 갔는지 알지 못하지만 해당 테이블의 열 이름은 ID, 이름 또는 기타와 같습니다. 정확히 무엇인지에 대한 표가 없으면 컨텍스트를 실제로 잃어 버렸습니다.
따라서 일반적으로 데이터 모델링을 수행 할 때 DDL에서도 생성되는 모든 아티팩트에 적절한 명명 규칙을 적용해야합니다. 그러나 프로젝트 자체의 특성에 대해 더 구체적으로 말하면 일반적으로 상당히 큰 이니셔티브에 대해 이야기하고 있습니다. 그 중 하나는 십여 개가 넘는 레거시 시스템을 교체 한 1 억 5 천만 달러의 비즈니스 혁신 프로젝트였습니다. 우리는 5 개의 다른 민첩한 팀이 동시에 진행했습니다. 전체 데이터 아키텍처 팀이 있었기 때문에 팀의 데이터 모델러가 다른 응용 프로그램 영역 팀 중 하나에 포함되어 있었으며 우리는 주제를 알고 사내 비즈니스 전문가와 협력하여 요구 사항 자체에 대한 사용자 스토리. 우리는 각 팀에 실제로 비즈니스 프로세스를 모델링하는 활동 분석가 또는 비즈니스 프로세스 다이어그램을 사용하여 비즈니스 분석가가 있었으며, 나머지 팀에서도 소비되기 전에 사용자와 더 많은 사용자 스토리를 구체화 할 수있었습니다.
물론, 그 위에 응용 프로그램 코드를 구축 한 개발자도 있습니다. 우리는 또한 협력하고있었습니다. 한 팀은 데이터 서비스를 구축하고 다른 팀은 한 영역에 전문 지식을 가진 다른 영역에 응용 프로그램 로직을 구축하는 곳에서 응용 프로그램의 다른 부분을 구축하는 4 개의 다른 시스템 통합 공급 업체라고 생각합니다 다른 비즈니스 영역에서는 해당 영역에서 응용 프로그램 논리를 작성했습니다. 그래서 우리는이 프로젝트를 수행하고있는 사람들과 완전히 협력했습니다. 그 중 하나에는 특히 팀에 150 명, 팀에 150 명의 자원이 있었는데이 팀은 2 주 스프린트를 협력하여이 문제를 해결했습니다. 그리고이를 위해서는 모든 실린더에서 발사해야하며 모든 사람이 산출물에 대해 잘 동기화되어 있으며 필요한 모든 아티팩트에 대한 납품을 완료하기 위해 자주 재설정됩니다. 모든 스프린트의 끝에서.
로빈 블로어 박사 : 글쎄요. 그리고 이것에 대해 좀 더 자세히 설명하겠습니다 – 그 프로젝트의 끝에서 전체 데이터 영역의 MDM 맵으로 완성 된 것입니까?
Ron Huizenga : 모든 비즈니스 영역으로 분해 된 완전한 데이터 모델이있었습니다. 전체 정의 측면에서 데이터 사전 자체는 약간 짧았습니다. 우리는 대부분의 테이블을 정의했습니다. 우리는 대부분의 열이 정확히 무엇을 의미하는지 정의했습니다. 거기에 없었던 것들이 있었고, 흥미롭게도, 그중 많은 것들이 프로젝트 범위가 끝난 후에도 여전히 이월 된 일련의 문서로 기록되고 있던 레거시 시스템에서 온 정보 조각이었습니다. 앞으로의 조직에 의해 유지되어야 할 것이기 때문에 프로젝트 자체 외부의 인공물. 따라서 조직은 레거시 시스템과 문서화되지 않았기 때문에 우리가 소비하려고하는 레거시 데이터 소스에 많은 단점이 있었기 때문에 데이터 거버넌스의 중요성에 대한 관점이 훨씬 높아졌습니다. 많은 경우에 우리는 리버스 엔지니어링하고 거기에 무엇이 있고 정보가 무엇인지 파악하려고하는 데이터베이스 만 가지고있었습니다.
로빈 블로어 박사 : 그 특정 측면을 놀라게하지는 않습니다. 데이터 거버넌스는 매우 현대적인 문제라고 생각합니다. 실제로 데이터 거버넌스에서 역사적으로 수행해야했던 많은 작업이 있다고 생각합니다. 그렇게하지 않으면 서 도망 칠 수 없었기 때문이 아닙니다. 그러나 데이터 리소스가 커지고 커지면서 결국에는 할 수 없었습니다.
어쨌든, 나는 할당 된 시간을 가졌다 고 생각하기 때문에 Dez로 넘어갈 것입니다. 데즈?
Dez Blanchfield : 예, 감사합니다. 이 모든 것을 통해 저는 여러 가지 방법으로 애자일이 화를내는 것을 보는 것에 대해 이야기하고 있다고 생각하고 있습니다. 그것은 부정적인 의미를 가지고 있지만; 나는 그것을 긍정적 인 방식으로 의미했습니다. 이 시나리오가 완벽한 세트라는 것을 알 수있는 두 가지 장소가 있습니다. 하나는 하루 만에 완료해야하는 새로운 프로젝트이지만, 제 경험상 변하지 않는 경우가 종종 있습니다. 프로젝트가 충분히 커져서 여러 가지 방법으로 필요한 경우, 두 세계를 접착시키는 것 사이에 흥미로운 도전이 있습니다. 조직 내 어디로 갔는지 본 성공 사례에 대한 통찰력을 줄 수 있습니까? 두 세계가 약간 충돌하여 성공적으로 넣을 수 있음이 분명해졌습니다. 이것들이 제자리에 있고 다른 방법으로 레일에 갔을 수도있는 큰 프로젝트를 모으는가? 나는 그것이 매우 광범위한 질문이라는 것을 알고 있지만, 당신이 할 수있는 특별한 사례 연구가 있는지, 당신이 말한 곳을 가리킬 수 있는지 궁금합니다.이 모든 것을 제자리에 놓고 모든 개발 팀과 함께 데이터 팀과 우리는 배를 가라 앉힐 수도있는 문제를 해결 했습니까?
Ron Huizenga : 물론, 실제로 파이프 라인 프로젝트가 된 프로젝트는 데이터 모델러 전후의 결함이있는 차트를 보여준 곳에서 언급 한 프로젝트였습니다. 아주 자주, 그리고 선입관적인 개념이 있습니다. 특히 순전히 개발 관점에서 작업이 완료된 경우 응용 프로그램을 제공하기 위해 이러한 민첩한 프로젝트에 관여하는 개발자 일뿐입니다. 물론 거기에서 일어난 일은 특히 레일과 데이터 아티팩트에서 나왔거나 그들이 생산 한 데이터가 품질 측면에서 현저히 떨어지고 전체적으로 문제를 해결한다는 것입니다. 그리고 데이터 모델러가 프로젝트 속도를 늦추고 데이터 모델러가 올바른 태도를 취하지 않으면 이러한 오해가 종종 있습니다. 내가 말했듯이, “우리는 데이터 구조의 모양을 제어하기 위해 여기에 있습니다”라는 사고 방식에서 전통적인 게이트 키퍼 자세를 가진 데이터 모델러가 있습니다. 민첩한 개발, 특히 데이터 모델러에 관여하는 사람은 팀이 실제로 발전하도록 돕는 촉진자 역할을 수행해야합니다. 그리고이를 설명하는 가장 좋은 방법은 변경 사항을 먼저 모델링하여 팀에게 생산성을 보여줄 수 있도록하는 것입니다. 그리고 다시, 이것이 제가 공동 작업에 대해 이야기 한 이유입니다.
먼저 모델링하고 개발자에게 푸시하기 위해 DDL을 생성 할 수있는 몇 가지 사항이 있습니다. 우리는 또한 그들이 제한되는 느낌을받지 않기를 원합니다. 따라서 작업중인 작업이있는 경우 개발자가 자신의 데스크톱이나 다른 데이터베이스에서 작업하여 테스트 할 부분을 변경하기 때문에 개발 샌드 박스에서 계속 작업하게하십시오. 그리고 그들과 협력하여“좋아, 그와 함께 일해라.”라고 말합니다. 우리는 도구를 도구로 가져 와서 해결 한 다음 앞으로 밀어 내고 배포 할 수있는 스크립트를 제공합니다. 데이터베이스를 실제 제재 된 실제 프로덕션 뷰로 업그레이드하여 계속 진행할 것입니다. 그리고 당신은 그것을 매우 빠른 방식으로 바꿀 수 있습니다. 나는 다른 개발 팀과 반복해서 돌아 가면서 변경 사항을보고, 비교하고, 스크립트를 생성하고, 진행시키는 과정에서 하루가 가득 찼다는 것을 알았습니다. 그리고 우리가 한 번만 네 개의 개발 팀과 쉽게 지낼 수있었습니다. 운동량을 달성했습니다.
Dez Blanchfield : 기억해야 할 것 중 하나는, 매일 매일 많은 대화가 우리에게 오는 기계에 대한이화물 열차에 관한 것입니다. -기계와 IoT. 현재 엔터프라이즈 환경에 많은 데이터가 있다고 생각되면 Google과 Facebook, Uber에 페타 바이트의 데이터가 있다는 것을 알기 위해 잠시 유니콘을 빼면 전통적인 기업에서 우리는 여전히 수백 테라 바이트와 많은 데이터에 대해 이야기하고 있습니다. 그러나 저는이화물 열차가 조직에 올 것이라고 생각합니다. Robin Bloor 박사는 IoT에 대해 일찍 언급했습니다. 알다시피, 우리는 많은 웹 트래픽, 소셜 트래픽, 모바일 및 모바일 장치, 클라우드, 종류, 폭발, 스마트 인프라, 스마트 시티를 보유하고 있습니다. 방금 폭발 한 데이터의 전 세계가 있습니다.
일상적인 조직의 경우, 거기에 앉아이 고통의 세계를보고있는 중대형 조직은 즉각적인 계획을 세우지 않고 몇 가지 문장으로 된 테이크 아웃은 무엇입니까? 이들 방법론 중 일부를 적용하는 것에 대해 대화식으로 생각하기 시작해야하는시기와 장소에 대해 그들에게. 그들은 거의 앉아 있고주의를 기울이고 계획을 세우기 시작하는 시간을 얼마나 일찍해야합니까?이 시점에서 몇 가지 도구를 준비하고 팀을 훈련시키고이 과제를 해결하기 위해 어휘 대화를하는 것이 가장 좋은 시점이라고 말합니다. 이야기의 후반이 너무 늦거나 너무 이른시기는 언제입니까? 보고있는 일부 조직의 경우 어떤 모습입니까?
Ron Huizenga : 저는 대부분의 조직에서 아직이를 수행하지 않고 이와 같은 강력한 도구로 데이터 모델링 및 데이터 아키텍처를 조정했다면 어제 시간이 필요하다고 말합니다. 오늘날에도 조직의 데이터를 볼 때 조직에 너무 많은 데이터가 있으며 일반적으로 우리가 본 일부 설문 조사에 따르면 데이터의 5 % 미만을 효과적으로 사용한다는 사실이 흥미 롭습니다. 조직을 살펴볼 때 그리고 IoT 나 NoSQL의 경우, 빅 데이터 (IoT뿐만 아니라 일반적으로 빅 데이터 임에도 불구하고)는 이제 조직 외부에서 발생하는 더 많은 정보를 소비하기 시작하고 있으며, 그 과제는 점점 커지고 있습니다. 항상. 그리고 우리가 해결할 수있는 유일한 방법은 데이터가 무엇인지 이해하는 데 도움이됩니다.
따라서 유스 케이스는 약간 다릅니다. 우리가하는 일은 데이터를 볼 때, 캡처하고, 리버스 엔지니어링하고, 데이터 레이크 또는 사내 데이터베이스에있는 데이터를 확인하고, 데이터를 합성하는 것입니다. 데이터는 데이터가 무엇인지 이해할 수 있도록 의미와 의미를 적용하는 것입니다. 그것이 무엇인지 이해하기 전까지는 우리가 그것을 올바르게 또는 적절하게 사용하고 있는지 확인할 수 없기 때문입니다. 따라서 우리는 그 데이터가 무엇인지에 대한 핸들을 얻어야합니다. 그리고 다른 부분은, 모든 외부 데이터 소비 측면에서이 외부 데이터 소비를 지원하는 유스 케이스를 가질 수 있으므로 수행하지 마십시오. 나중에 필요할 수있는 것들을 끌어 당기고 활용하기보다는 필요한 것에 집중하십시오. 중요한 것들에 먼저 집중하고 그 과정을 진행하면서 외부의 다른 정보를 소비하고 이해하려고 노력하게됩니다.
이에 대한 완벽한 예는 우리가 IoT와 센서에 대해 이야기하고 있다는 것을 알고 있지만 실제로 IoT 이전에도 많은 조직에서 동일한 유형의 문제가 여러 조직에서 발생 해 왔다는 것입니다. 파이프 라인 회사이든, 제조업이든, 제어를 통해 많은 자동화 작업을 수행하고 데이터 스트림 및 이와 유사한 것을 사용하는 프로세스 기반 회사이든, 생산 제어 시스템을 보유한 사람은 누구나 그들이 알아 내기 위해 마실려고하는 데이터의 불길, 생산 장비에서 어떤 이벤트가 발생했는지, 어떤 일이 언제 발생 했는가? 그리고이 거대한 데이터 스트림 중에는 선별, 합성, 모델링 및 이해해야하는 특정 정보 또는 태그 만 관심이 있습니다. 그리고 그들은 그것을 실제로 이해할 시간이 될 때까지 나머지 부분을 무시할 수 있으며, 그럴 경우 범위를 확장하여 점점 더 많은 범위로 옮길 수 있습니다.
Dez Blanchfield : 그렇습니다. 에릭 (Eric)이라는 신사에게서 온 한 가지 질문이 있습니다. 우리는 개인적으로 대화를 나 been습니다. 나는 그가 허락 한 그의 허락을 요청했다. 시간이 지남에 따라 조금씩 가고 있으므로 에릭에게 손을 돌려 줄 것입니다. 그러나 다른 Eric의 질문은 신생 기업 소유자가 모델링 용어와 관련된 고유 한 문제에 익숙하고 이해하고 있다고 가정하는 것이 합리적입니까? 아니면 해석을 위해 다른 사람에게 전달해야합니까? 다시 말해, 스타트 업이 능력 있고 준비가되어 있어야하며 이에 집중하고이를 제공 할 수 있어야합니까? 아니면 그들이 쇼핑하고 전문가를 데려 와야 할 것입니까?
Ron Huizenga : 짧은 대답은 그것이 실제로 달려 있다고 생각합니다. 데이터베이스를 실제로 이해하는 데이터 아키텍트 또는 모델러 인 사내 직원이없는 신생 기업인 경우, 가장 빠른 시작 방법은이 분야에 정통한 컨설팅 배경을 가진 사람을 데려 오는 것입니다. 그들이 간다. 제품 관리의 어두운면으로 넘어 가기 전에 수행 한 많은 참여에 대해 실제로 발견 한 내용은 컨설턴트로서 데이터 아키텍처 팀을 이끌고, 그들은 스스로를 다시 초점을 맞추고 사람들에게 이런 종류의 일을 수행하는 방법에 대해 훈련 시켜서 그것을 유지하고 앞으로 나아갈 임무를 수행 할 수 있도록합니다. 그런 다음 말이 맞다면 다음 참여로 넘어갈 것입니다. 거기에는 많은 사람들이 있습니다. 그들은 아주 좋은 데이터 경험을 가지고 있습니다.
Dez Blanchfield : 그 점이 대단한 견해이며 전적으로 동의합니다. Dr. Robin Bloor도 마찬가지입니다. 특히 스타트 업에서는 스타트 업 비즈니스 자체의 일부로 구축하려는 특정 제안 가치에 대해 중소 기업이되는 데 중점을두고 있으며, 모든 것에 대해 전문가가 될 필요는 없으므로 훌륭한 조언이 될 것입니다. 하지만 정말 멋진 프리젠 테이션입니다. 정말 좋은 답변과 질문. 에릭, 시간이 지남에 따라 10 분이 지났고 시간 창에 밀착되어 있다는 것을 알고 있기 때문에 다시 연락 드리겠습니다.
에릭 카바나 흐 : 괜찮습니다. 적어도 몇 가지 좋은 질문이 있습니다. 내가 당신에게 하나를 던져 보자. 나는 당신이 다른 사람들에게 대답했다고 생각합니다. 그러나 글을 쓰는 한 참석자의 매우 흥미로운 관찰과 질문, 때로는 민첩한 프로젝트에는 데이터 모델러가 전체 장기 그림을 갖지 않으므로 스프린트 1에서 무언가를 디자인 한 다음 스프린트 3 또는 4에서 다시 디자인해야합니다. 이것이 비생산적인 것처럼 보이지 않습니까? 그런 종류의 것을 어떻게 피할 수 있습니까?
Ron Huizenga : 주어진 스프린트에서 모든 것을 완벽하게 얻지 못하는 것은 민첩한 특성입니다. 그리고 그것은 실제로 민첩성의 정신의 일부입니다 : 그것과 함께 일하십시오 – 당신은 주어진 스프린트에서 코드를 다루는 곳에서 프로토 타입을 만들고, 그것을 다듬을 것입니다. 그리고 그 과정의 일부는 최종 사용자가보고있는 것을 전달하면서“그렇습니다.하지만이 부분도 좀 더해야합니다.”기능 설계에만 영향을주는 것은 아닙니다. 코드 자체의 일부이지만 사용자가 원하는 것을 제공하기 위해 이러한 특정 사항 아래에 더 많은 데이터 구조를 수정하거나 추가해야하는 경우가 종종 있습니다. 이것이 모두 공정한 게임이므로 모델링 툴에서 신속하게 모델링 및 변경을 수행 한 다음 개발자가 제공 할 수있는 데이터베이스에 대한 DDL을 생성 할 수 있기 때문에 고성능 툴을 실제로 사용하려는 이유입니다. 더 빨리 변경하십시오. 데이터 구조를 그대로 핸드 코딩하지 않아도되며, 가장 숙련 된 프로그래밍 또는 응용 프로그램 논리에 집중할 수 있습니다.
에릭 카바나 흐 : 그것은 말이됩니다. 우리는이 두 가지가 도구와 어떻게 연결되어 있는지에 대해 구체적인 질문을하는 다른 사람들도있었습니다. 나는 당신이 예제를 살펴 보는 데 시간을 보냈으며 실제로이 물건을 실제로 어떻게 굴리는 지에 대한 스크린 샷을 보여주었습니다. 이 전체 스프린트 프로세스의 관점에서 볼 때 조직에서 얼마나 자주 활동하고 있는지, 그리고 사물, 종류, 시간이 걸리고 더 많은 시간이 걸리는 전통적인 프로세스를 얼마나 자주 봅니까? 스프린트 스타일 접근법은 당신의 관점에서 얼마나 널리 퍼져 있습니까?
Ron Huizenga : 점점 더 많이보고 있다고 생각합니다. 나는 아마도 지난 15 년 동안 아마도 그들이 더 빠른 배송을 수용해야한다는 것을 인식하는 사람들이 훨씬 더 많이 채택 된 것을 보았을 것입니다. 그래서 점점 더 많은 조직이 민첩한 악대에 뛰어 드는 것을 보았습니다. 반드시 전부는 아닙니다. 그들은 그것이 효과가 있음을 증명하기 위해 몇 가지 파일럿 프로젝트로 시작할 수 있지만 여전히 매우 전통적이며 폭포 방법을 고수합니다. 물론 좋은 소식은 이러한 유형의 방법론뿐만 아니라 해당 조직에서도 도구가 매우 잘 작동한다는 것입니다. 그러나 우리는 도구에 적응할 수 있으므로 도구 상자에 도구를 사용할 수 있습니다. 그들의 손끝. 비교 및 병합과 같은 기능, 리버스 엔지니어링 기능과 같은 기능을 통해 기존 데이터 소스가 무엇인지 확인할 수 있으므로 실제로 증분 DDL 스크립트를 매우 빠르게 비교하고 생성 할 수 있습니다. 그리고 그들이 그것을 받아들이 기 시작하고 그들이 생산성을 가질 수 있음을 볼 때, 그들의 민첩성은 훨씬 더 민첩하게 받아들이려고합니다.
에릭 카바나 : 글쎄요. 방금 채팅 창에 슬라이드에 대한 링크를 게시 했으므로 확인하십시오. 그것은 당신을 위해 조금 조금 있습니다. 나중에 볼 수 있도록 이러한 웹 캐스트가 모두 있습니다. 친구 나 동료와 자유롭게 공유하십시오. 그리고 Ron, 오늘 시간 내 주셔서 감사합니다. 현장에서 진정한 전문가 인 쇼에 참여하는 것이 항상 즐겁습니다. 감사합니다. IDERA와 Dez와 우리 고유의 Robin Bloor에게 감사드립니다.
그리고 우리는 여러분에게 작별 인사를 할 것입니다. 시간과 관심에 다시 한번 감사드립니다. 75 분 동안 고집해 주셔서 감사합니다. 꽤 좋은 징조입니다. 좋은 쇼 여러분, 우리는 다음에 당신에게 이야기 할 것입니다. 안녕.
