저예산 데이터 마이닝 가이드

API 기능이 매일 바뀌는 기존의 응용 프로그래밍과 달리 데이터베이스 프로그래밍은 기본적으로 동일합니다. Microsoft Visual Studio .NET의 첫 번째 버전은 2002년 2월에 릴리스되었으며 서비스 팩 릴리스를 제외하고 약 2년마다 새 버전이 릴리스되었습니다. 이러한 급격한 변화로 인해 IT 직원은 회사의 응용 프로그램을 2년마다 평가해야 하며 응용 프로그램의 기능은 그대로 유지하지만 최신 기술과 기술을 최신 상태로 유지하기 위해 완전히 다른 소스 코드를 사용하게 됩니다.

데이터베이스 소스 코드에 대해서도 마찬가지입니다. SQL 초기에 작성된 SELECT / FROM / WHERE / GROUP BY 의 표준 쿼리는 오늘날에도 여전히 작동합니다. 물론 이것이 관계형 데이터베이스 프로그래밍의 발전이 없었다는 것을 의미하지는 않습니다. 기술적인 것보다 논리적인 것이 더 많았습니다 .

Bill Inmon과 Ralph Kimball이 데이터 웨어하우스 설계에 대한 이론을 발표한 이후로 데이터베이스 프로그래밍의 발전은 귀중한 정보의 손실을 방지하고 데이터에서 모든 귀중한 정보를 추출하는 데 중점을 두었습니다. Inmon과 Kimball이 데이터 웨어하우징에 데이터베이스 세계를 도입한 후 데이터베이스 개발자가 메타데이터에 쉽게 액세스할 수 있도록 하는 ETL(추출/변환/로드) 도구와 작업하기 어려웠던 비관계형 데이터베이스 소스의 데이터에 주요 변경 사항이 있었습니다. 과거에. 이로 인해 귀중한 정보를 추출하는 데 사용할 수 있는 데이터의 양이 증가했으며, 이러한 사용 가능한 데이터의 증가는 OLAP 큐브 및 데이터 마이닝 알고리즘을 통한 데이터 처리의 발전으로 이어졌습니다.

데이터 웨어하우스, OLAP 큐브 및 데이터 마이닝 알고리즘을 데이터베이스 아키텍처에 추가하면 비즈니스 프로세스를 극적으로 능률화하고 존재하지 않는 데이터의 패턴을 밝힐 수 있습니다. 자동화는 또한 비즈니스 인텔리전스 기능에 중대한 영향을 미칠 수 있습니다.

그러나 새로운 도구와 기술을 추가하기 전에 트랜잭션 데이터베이스가 제대로 구축되었는지 확인해야 합니다.

트랜잭션 데이터베이스

트랜잭션 데이터베이스는 기반이며 트랜잭션 데이터베이스가 신뢰할 수 없고 정확하지 않은 경우 무엇이든 추가하는 것은 재앙의 지름길입니다.

데이터베이스에 레이어를 추가할 때 명심해야 할 중요한 점은 모든 프로젝트가 투자 수익을 보여야 한다는 것입니다. 따라서 레이어를 추가하기 전에 현재 아키텍처를 최대한 활용하는 것이 가장 좋습니다. 이러한 모든 계층은 트랜잭션 데이터베이스에서 가져온 데이터를 활용합니다. 많은 상황에서 단순히 트랜잭션 데이터베이스를 쿼리하여 동일한 출력을 얻을 수 있습니다. 물론 데이터 웨어하우스나 OLAP 큐브에서 모든 보고서를 읽는 것이 이상적인 방법이지만 조직이 이러한 수준의 복잡성에 대비할 준비가 되지 않은 경우 보고 요구 사항을 먼저 충족하는 것이 더 중요합니다. 기본 보고 요구 사항이 충족되면 적절한 데이터 웨어하우스 및 OLAP 큐브가 비즈니스에 도움이 될 수 있는 방법에 대한 논의를 시작하는 것이 훨씬 쉽습니다.

거의 모든 프로그래머는 데이터베이스 정규화의 세 가지 규칙을 알고 있습니다. 트랜잭션 데이터베이스에서 읽는 저장 프로시저는 최적화의 경로입니다. 찾아야 할 문제는 가독성, 동일한 데이터베이스 테이블에 대한 다중 호출, 변수의 불필요한 사용입니다.

모든 엘리트 데이터베이스 프로그래머는 저장 프로시저의 가독성에 대해 까다롭습니다. 데이터베이스 전문가가 쿼리 형식을 지정하는 방식에는 애플리케이션 개발자와 다른 몇 가지 공통점이 있습니다. 일반적으로 키워드 및 집계 함수는 대문자로 표시되지만 테이블 및 필드 이름은 카멜케이스 또는 밑줄을 사용합니다. 테이블 별칭은 실제 테이블 이름과 약간의 상관 관계가 있습니다. 저장 프로시저의 섹션 정렬에는 일종의 블록 패턴이 있습니다.

다음은 읽을 수 있는 형식을 사용하는 쿼리의 예입니다.

 SELECT c.customer_id, c.name, SUM (po.purchase_amount) total_purchase_amount FROM customer c JOIN purchase_orders po ON c.customer_id = po.customer_id GROUP BY c.customer_id, c.name

다음으로 찾아야 할 사항은 쿼리가 테이블에 두 번 이상 도달하는지 여부입니다. 다른 집계 함수를 집계해야 하는 드문 경우를 제외하고 대부분의 쿼리에서 테이블에 한 번만 액세스하면 됩니다. 이것은 일부 응용 프로그램 프로그래머가 저지르는 또 다른 실수입니다. 아마도 응용 프로그램 프로그래머가 객체 지향 설계의 관점에서 생각하기 때문일 것입니다.

객체 지향 설계는 각각의 고유한 데이터 요소에 대해 별도의 객체를 생성하지만 데이터베이스 프로그래머는 집합 논리의 관점에서 생각해야 합니다. 쿼리가 필요한 것보다 더 많이 테이블에 액세스한다고 해서 쿼리가 부정확한 데이터를 생성한다는 의미는 아니지만 쿼리의 성능에 영향을 미칩니다.

조인이 있을 때마다 레코드가 삭제되거나 복제되어 쿼리의 정확성이 손상되는 또 다른 문제가 발생합니다. 변수의 불필요한 사용은 쿼리가 애플리케이션 개발자에 의해 개발되었다는 또 다른 신호입니다. 응용 프로그램 개발자는 코드 전체에서 변수를 사용하지만 쿼리는 저장 프로시저에 대한 매개 변수로 선언된 경우를 제외하고는 변수를 사용할 필요가 거의 없습니다. 다시 한번 개발자가 집합 논리의 관점에서 생각하지 않았다는 신호입니다.

ETL(추출 변환 로드) 및 보고

클라이언트의 트랜잭션 데이터베이스에 제대로 작동하는 쿼리가 있으면 다음 단계는 비즈니스 프로세스를 간소화하는 것입니다.

ETL 프로세스 또는 자동화된 보고에 대한 비즈니스 요구를 식별하는 가장 쉬운 방법은 누가 트랜잭션 데이터베이스에서 데이터를 읽고 있는지 확인한 다음 스프레드시트를 사용하여 데이터를 조작하는 것입니다. 스프레드시트는 데이터베이스 테이블과 같은 구조입니다. 둘 다 행과 열을 포함합니다. 최종 사용자가 스스로 데이터를 조작하게 하는 경우 "왜 해당 프로세스를 자동화할 수 없습니까?"라고 자문해야 합니다.

비즈니스 프로세스를 자동화하면 즉각적인 투자 수익을 얻을 수 있으며 데이터 웨어하우징과 같은 더 비싼 프로젝트로 넘어가기 전에 항상 고려해야 합니다. 스프레드시트를 통해 데이터를 조작하는 최종 사용자를 식별하는 것은 간단하게 들릴 수 있지만 이 프로세스에는 주의 사항이 있습니다.

개발자는 프로세스 자동화를 좋아합니다. 그들이 하는 일입니다. 최종 사용자는 특히 작업을 위협하는 경우 자동화된 프로세스를 반드시 좋아하지 않습니다. 따라서 순진하게 생각하지 말고 최종 사용자가 귀하에게 달려가 자동화할 수 있는 일일 작업을 식별할 것이라고 생각하지 마십시오. 합리화 기회를 식별하는 데 정말로 앞장서야 합니다.

잘 구축된 ETL 시스템은 트랜잭션 데이터베이스에 로드된 모든 데이터를 원래 소스 파일로 역추적하는 기능도 제공해야 합니다. 이것은 데이터베이스 아키텍처의 중요한 부분입니다. 각 레코드가 추가된 정확한 날짜/시간과 레코드를 추가한 소스 이름(사용자 이름 또는 파일 이름)을 모른다면 트랜잭션 데이터베이스에 로드된 잘못된 데이터를 처리할 준비가 되지 않은 것입니다. "누군가 잘못된 파일을 보내면 어떻게 될까요?"라고 자문해 보십시오. 거기에서 나온 기록을 확인하는 데 얼마나 걸립니까?

데이터웨어 하우스

데이터 웨어하우스 설계에는 두 가지 이론이 있습니다. 인몬 이론과 킴볼 이론의 차이점은 다음과 같이 요약할 수 있다.

Inmon 이론은 먼저 데이터 웨어하우스를 개발한 다음 데이터 웨어하우스에서 보고하기 위한 차원 데이터 마트를 구축하는 것입니다. Kimball 이론은 먼저 보고를 위한 차원 데이터 마트를 개발한 다음 함께 병합하여 데이터 웨어하우스를 만드는 것입니다.

당신은 항상 고객에게 가장 빠른 투자 수익을 제공하기를 원합니다. 데이터 마트를 구축하는 것은 간단한 과정입니다. 보고서 뒤에 있는 쿼리를 가져와 결과 집합을 반환하는 것에서 영구 테이블에 결과 집합을 저장하는 것으로 변경하는 것으로 시작합니다. TRUNCATE TABLE tablename 을 추가하기만 하면 됩니다. 원래 SELECT 키워드 앞에 INSERT INTO 테이블 이름 . 기능적인 데이터 마트 테이블이 몇 개 있으면 데이터 마트를 병합할 기회를 식별해야 합니다. 동일한 테이블 목록을 사용하는 보고서 쿼리를 찾은 다음 필드 목록을 병합합니다. 이것은 특히 테이블 목록이 증가할 때 더 복잡한 쿼리가 필요합니다. 그러나 쿼리를 철저히 테스트하는 한 일반적인 비즈니스 프로세스를 중단하지 않고 각 증분 변경을 수행할 수 있습니다.

Kimball 데이터 웨어하우스 설계를 개선할 때마다 고객에게 ROI를 보여줄 기회가 있습니다. 데이터 웨어하우스가 먼저 구축되고 보고 데이터 마트가 정적 데이터 웨어하우스에서 구축되기 때문입니다. 따라서 데이터 웨어하우스 프로젝트 초기에 대부분의 비용이 발생합니다.

OLAP 큐브

OLAP 큐브는 빠른 응답 시간, 최종 사용자를 위한 임시 드릴다운 기능 및 데이터 마이닝과 함께 집계 데이터를 제공함으로써 조직에 도움이 될 수 있습니다. 적절한 OLAP 큐브가 있으면 데이터에서 모든 값을 추출할 수 있습니다. OLAP 큐브는 데이터 웨어하우스 위에 구축되지만 표준 데이터베이스 SQL과 다른 언어인 MDX를 사용합니다. 또한 데이터베이스 서버보다 더 복잡한 구성 노력이 필요합니다. 이러한 복잡성으로 인해 OLAP 프로젝트는 비용이 많이 들고 숙련된 MDX 개발자를 찾기가 어렵습니다.

데이터 설계자는 SQL 쿼리, 데이터 웨어하우스 또는 미리 준비된 보고서로 대체할 수 없는 단일 프로세스 없이 큐브를 활용하는 단순한 대시보드에 불과한 기존 OLAP 큐브를 종종 봅니다. OLAP 큐브는 미리 준비된 보고서보다 빠른 응답 시간을 제공할 수 있지만 대부분의 경우 그 차이는 무시할 수 있습니다. 드릴다운 기능의 이점도 얻을 수 있지만 최종 사용자에게 드릴다운 기능을 제공하기 전에 유사한 임시 인터페이스를 제공하는 미리 준비된 보고서를 사용하는 것이 좋습니다.

이를 통해 최종 사용자가 실행 중인 임시 쿼리를 기록할 수 있으며, 그런 다음 최종 사용자가 생성될 수 있다는 사실을 깨닫지 못한 새로운 미리 준비된 보고서를 식별할 수 있습니다. 일반적으로 OLAP 큐브를 개발할 때 응답 시간과 드릴다운 개선 사항이 모두 최소화되므로 관련된 데이터 마이닝을 처리할 수 있는 데이터베이스 아키텍처가 필요할 때까지 클라이언트에 제안할 필요가 없습니다. 이것은 고객에게 깊은 인상을 주고 강력한 데이터베이스 아키텍처 없이는 결코 알지 못했을 비즈니스에 대해 보여줄 수 있는 때입니다.

이전에 언급했듯이 OLAP 큐브를 구축하는 것은 어려울 수 있습니다. 하이브리드 OLAP 큐브를 고려하는 것은 좋은 정책입니다. Microsoft Excel의 PowerPivot은 완전한 OLAP 큐브의 복잡성 없이 사용하기 쉬운 데이터 마이닝 도구를 제공합니다. 하이브리드의 가장 큰 단점은 응답 시간이 동일하지 않다는 것입니다. 그러나 큰 장점은 MDX를 사용하는 것보다 Excel을 사용하여 데이터 마이닝 보고서를 만드는 것이 더 쉽다는 것입니다. 데이터 마이닝을 할 때 유용한 세 가지 보고서가 있습니다. 우리는 실제 사례와 그것을 해석하는 방법을 볼 수 있습니다.

이 모든 보고서는 작성자가 구축한 자동화된 일일 거래 애플리케이션에서 가져온 것입니다.

시각적 보고

산점도 보고서

산점도 보고서는 두 변수를 비교하는 세부 수준 보고서입니다. 실제 점에 색상과 크기를 추가하면 해당 변수와 관련하여 실제 결과를 시각화하는 데 도움이 됩니다.

상자와 수염 보고서

이 보고서는 산점도 보고서의 x 및 y 값을 요약합니다. x축 값은 버킷 세트로 이산화됩니다.

각 수염(선)의 끝은 이상값을 나타냅니다. 노란색과 연한 파란색 막대는 상위 및 하위 하나의 표준 편차 범위를 나타냅니다.

선형 회귀 모델

이 보고서는 수식으로 나타낼 수 있는 선의 평활화와 함께 x 및 y축 값 간의 상관 관계를 보여줍니다. 상관 관계가 얼마나 신뢰할 수 있는지 보여주기 위해 R 제곱 값이 포함됩니다.

결론

회사가 성장함에 따라 일반적으로 데이터베이스도 함께 커집니다.

대부분의 조직에는 처음에 데이터베이스 전문가나 데이터 과학 전담 회사가 필요하지 않습니다. 대신 IT 직원이 여러 책임을 처리하도록 하거나 "많은 모자를 쓰십시오"라는 말이 있습니다. 이것은 어느 정도 효과가 있지만 결국에는 전문가를 데려와야 합니다.

이 문서에 나열된 항목은 사용자가 알지 못했던 데이터베이스 문제를 빠르고 쉽게 식별할 수 있는 방법입니다. 값비싼 소프트웨어 라이선스에 많은 비용을 들이지 않고 최고 수준의 데이터 마이닝 도구를 구축할 수 있는 방법도 다루었길 바랍니다. 이렇게 하면 IT 직원에 데이터베이스 전문가를 추가함으로써 조직이 얼마나 많은 이점을 얻을 수 있는지 더 잘 알 수 있습니다.