데이터베이스 재 설계를위한 모범 사례

응용 프로그램의 데이터베이스를 디자인 할 때 일반적인 모범 사례를 알고 있지만 다시 디자인하는 것은 어떻습니까?

내부 비즈니스 응용 프로그램을 다시 디자인하는 팀을 맡고 있지만 "내부"라고 말하더라도 불행히도 많은 계층의 사람들이 시스템의 실제 사용자와 연락을하지 않습니다.

현재 프로그램은 Oracle Forms에 있으며 정규화되지 않은 여러 테이블에 흩어져 있으며 때로는 서로의 데이터에 약간의 변형이있는 여러 개의 중복 테이블이 있습니다. 제약 조건은 종종 강제 적용 저장 프로 시저 형식으로되어 있습니다. 유형조차 제대로 저장되지 않은 것 같습니다. 오라클이 무시하는 것처럼 보이지만 SQL Server의 가져 오기 / 내보내기 마법사에 적합한 모든 종류의 나쁜 데이터가 발생했습니다. (예를 들어, 두 자리 정수는 완전한 날짜 시간을 구성하지 않습니다!)

원래 프로그램은 아마도 20 년 전으로 거슬러 올라갈 수 있으며, 모든 원래 개발자는 오래 전에 은퇴했으며 여기에있는 노인조차도 자신이 누구인지 전혀 몰랐습니다. 결과적으로 실제 요구 사항도 충족되지 않습니다. 기존 응용 프로그램의 기능을 복제하고 기존 데이터를 유지해야합니다.

다시 쓰기의 최종 결과는 백엔드 용 MS SQL Server와 함께 ASP.NET에서 실행되는 웹 기반 버전이 될 것입니다.

저의 다른 두 개발자 팀원은 비즈니스 / MIS 배경을 가진 반면, CS는 나보다 훨씬 나이가 많습니다. 선임 멤버의 경험은 거의 독점적으로 Oracle 형식이며 다른 멤버는 대부분 Visual Basic에서 비즈니스 응용 프로그램 작업을 수행했습니다. 내 데이터베이스 배경은 MySQL 또는 SQLite의 프로젝트를위한 새 데이터베이스 디자인으로 제한되었지만 주로 저학년 수업을 위해 실제로 데이터베이스를 설계 한 경험이있는 유일한 사람 인 것 같습니다.

이미 모든 기존 데이터를 중립 형식으로 읽어서 다시 캐스팅하여 새 데이터베이스에 넣을 수있는 작은 프로그램을 C #으로 작성했습니다. 대상 데이터베이스를 디자인 한 후로드 코드를 작성하여 새로운 정규화 된 테이블간에 데이터를 올바르게 분할하고 올바른 제약 조건을 따르는 올바른 순서로 추가 할 수 있습니다. 같은 프로그램을 나중에 다시 실행할 수 있습니다. 실제 새로 배포 된 재 설계에 생산 데이터를 복사합니다. 이를 통해 데이터베이스의 실제 재 설계가 가장 중요하게 생각됩니다.

내 질문의 핵심 : 기존 응용 프로그램의 데이터베이스 수준에서 재 설계를 수행하는 모범 사례는 무엇입니까?

데이터베이스를 표준화하는 방법을 이미 알고 있다고 생각합니다.

필요한 것은 모든 소프트웨어를 새 데이터베이스로 옮길 때의 위험을 최소화하기위한 전략입니다.

내가 제안하는 것은 위험을 줄이기위한 절충안으로 더 많은 일을하는 것입니다.

데이터베이스를 정규화하고 정규화 된 데이터베이스를 원래 데이터베이스의 데이터로 채우는 프로세스를 작성하십시오. 원본 데이터베이스는 삽입, 업데이트 및 삭제를위한 데이터베이스입니다. 정규화 된 데이터베이스는 변환 중에 만 쿼리 데이터베이스가됩니다 .

채우기 프로세스는 쿼리 데이터의 필요성만큼 자주 실행되어야합니다. 일별 데이터가 허용되는 경우 야간 채우기 프로세스를 실행할 수 있습니다. 최신 데이터가 더 필요한 경우 연속 채우기 프로세스를 실행해야합니다.

새로운 표준화 된 데이터베이스를 가리키면서 새로운 ASP.NET 시스템의 쿼리 부분을 빌드하십시오.

새 시스템의 쿼리 결과는 원래 시스템의 쿼리 결과와 비교해야합니다.

이 시점에서 멈출 수 있습니다. 그것은 기술적 결정이 아닌 비즈니스 결정입니다.

여가 시간에는 새로운 ASP.NET 시스템에서 새로운 삽입 / 업데이트 / 삭제 기능을 작성하십시오. 새 기능을 만들면 해당 원래 시스템의 일부가 꺼집니다. 어떤 시점에서는 원래 시스템이 남아 있지 않습니다.

이러한 방식으로 변환하면 쿼리 부분을 먼저 작성하여 위험을 줄일 수 있습니다. 일반적으로 쿼리 기능은 삽입 / 업데이트 / 삭제 기능에 내장 된 비즈니스 로직에 비해 단순합니다.

삽입 / 업데이트 / 삭제 기능을 한 번에 한 프로세스 씩 변환합니다. 비즈니스 로직을 이해하는 데 문제가있는 경우 사용자가 원래 시스템을 사용하는 동안 문제를 해결할 수 있습니다.

채우기 프로세스가 절대적으로 일관성이 있다는 것은 말할 필요도 없습니다.

그들에게 새로운 시스템의 개발을 외부 회사와 계약하도록 설득하십시오. 제한된 개발 팀보다 빠르고 효율적으로 응용 프로그램을 제대로 개발할 수있는 리소스를 보유한 좋은 개발 회사가 많이 있습니다. 좋은 개발 회사는 또한 당신이 요청한 경우하지 말아야 할 일을 당신의 상사들에게 강요 할 수있을 것입니다. IT 담당자보다 관리 권한 아래에 여러 단계를 배치해야합니다.

초기 비용이 많이 들지만 개발 및 구현에 필요한 적절한 리소스를 확보하려면 많은 시간을 투자해야합니다. 당신이 RFP를 내놓을 수 있다면 나는 당신이 얻는 입찰이 당신이하려는 일이 당신의 관리자가 인식하는 것보다 훨씬 더 복잡하다는 것을 나타냅니다.

필요한 데이터 유형으로 필요한 정규화 된 데이터베이스를 설계하십시오. 그런 다음 가장 어려운 부분은 데이터를 마이그레이션하는 것입니다. 먼저, 구식에서 신식으로 매핑하는 방법과 새로운 구조에 맞지 않는 데이터로 무엇을 할 것인지에 대한 계획이 필요합니다. 예를 들어 적절한 무결성 제약 조건이 없으면 데이터를 식별 할 수 없습니다. 단순히 해당 데이터를 이동하지 않거나 이동해야하지만 "알 수 없음"이라는 새 상위 레코드에 연결해야 할 수 있습니다. 날짜가 실제 날짜가 아닌 경우 마이그레이션 할 때 필드에 널을 넣을 수 있습니까? 이런 종류의 질문에 대한 답이 필요합니다. 나는 일부 개발자가 GUI를 변경하여 새 데이터베이스 구조를 사용하고 다른 일부는 마이그레이션에 대해 엄격하게 작업하도록 제안합니다. 마이그레이션은 엄청난 작업입니다. 그것은 많은 기술과 많은 시간을 소모 할 것입니다. 나중에 생각하지 마십시오.

SQL Server를 사용하고 있으므로 SSIS를 통해 실제 마이그레이션을 수행 할 수 있습니다.

기존 시스템과 결과가 새 시스템과 동일하다는 것을 비교할 수 있도록 적절한 테스트 사례 세트를 작성하십시오.

수년간의 데이터가 있으므로 두 부분으로 마이그레이션 할 수 있습니다. 먼저 대부분의 데이터를 마이그레이션 한 다음 실시간으로 전환해야 할 때 변경된 데이터 만 마이그레이션하십시오. 물론 아직 가지고 있지 않은 변경된 데이터를 찾으려면 데이터베이스에 컨트롤을 배치해야합니다. 일부 데이터를 아카이브하려는 경우이 시점에서 고려할 수도 있습니다.

MS Access 파일 (.mdb)로 생성 된 여러 레거시 응용 프로그램의 지원 및 추가 개발로 인해 거의 매일 데이터베이스 스키마를 다시 디자인하는 데 어려움을 겪고 있습니다. 서버는 여전히 원래 디자인의 "유아 사망"을 가지고 있습니다. 다음은 내가 유용하다고 생각한 몇 가지 사례입니다.

공개적으로 사용 가능한 데이터베이스 스키마 표면을 최소화하십시오.

즉, 외부 응용 프로그램에서 사용할 수있는 일부 공용 API를 설계해야합니다. 일반적으로 정적 데이터를 뷰 (단일 테이블을 기반으로하는 경우에도)로 동적 데이터를 매개 변수 뷰 또는 저장 프로 시저로 구현하려고합니다. 단일 값만으로 충분한 데이터 쿼리의 경우 스칼라 함수를 사용할 수도 있습니다.

이들 (보기, 저장 프로 시저 및 스칼라 함수) 만 외부 응용 프로그램 (ORM을 통해 또는 직접)에 표시되며 모든 CRUD 작업에 사용됩니다. 그런 다음이 스키마는 완전히 고정 된 반면 내부적으로 기본 테이블을 변경하고 프로 시저를 개선 할 수 있습니다. 이렇게하면 응용 프로그램과의 호환성이 손상되지 않습니다.

책의 기준이 아닌 실제 기준에 맞게 최적화하십시오.

표준화는 데이터베이스 디자인에 대한 모든 책에서 큰 주제입니다. 그러나 실제로는 정규화로 인해 데이터베이스가 많이 또는 느려지지 않는 경우가 있습니다. 예를 들어 반복되는 데이터가 있지만 반복 비율이 매우 낮은 경우 등입니다. 내가 여기서 말하려는 것은 회의론과 신중함을 가지고 해결해야한다는 것입니다.

프로파일 링 세션을 기록하고 분석하십시오.

데이터베이스 스키마만을 기반으로 한 데이터베이스 재 설계가 완료되지 않았습니다. 동적 데이터베이스에서 데이터베이스를 살펴보고로드 테스트 중에 병목 현상을 찾아서 해결하십시오. MS SQL Server의 경우 기록 된 활동 추적에 대한 일부 권장 사항을 생성 할 수 있는 특수 조정 어드바이저 가 있습니다.

내 대답은 다음과 같습니다.

1. 먼저 현재 데이터베이스 시스템을 최대한 이해하십시오. 이러한 시스템과 사용자의 모든 용도를 알아야합니다. 시스템에 대한 모든 소스 및 해당 소스 시스템으로 사용중인 시스템을 알아야합니다.

2. 운영 또는보고 또는 둘 다에 관계없이 시스템의 다양한 용도를 모두 식별해야합니다. 데이터베이스를 사용중인 응용 프로그램 및 업스트림 시스템을 식별하십시오. 그렇게하면 더 이상 필요없고 더 이상 필요없는 현재 데이터베이스의 요소를 알게됩니다.

3. 또한 데이터베이스에 데이터를로드하고 데이터베이스에서 데이터를 추출하는 현재 ETL 프로세스를 분석하고 이해하십시오.

4. 데이터베이스의 모든 데이터 요소를 이해하고 중복 요소를 식별하는 데 도움이되는 상자 행렬을 작성할 수 있는지 이해하십시오.

5. 모든 정보를 얻은 후에는 요구 사항 수집의 일부로 수집 한 정보를 사용하여 데이터베이스를 처음 설계하는 것처럼 재 설계에 접근 할 수 있습니다.

6. 행운을 빕니다!