Thực tiễn tốt nhất để thiết kế lại cơ sở dữ liệu

Tôi biết một số thực tiễn tốt nhất chung khi thiết kế cơ sở dữ liệu cho một ứng dụng, nhưng còn thiết kế lại thì sao?

Tôi thuộc nhóm được giao nhiệm vụ thiết kế lại một ứng dụng kinh doanh nội bộ, mặc dù tôi nói "nội bộ", thật không may, nhiều người không tiếp xúc với người dùng thực tế của hệ thống.

Chương trình hiện tại nằm trong Oracle Forms, nằm rải rác trên một loạt các bảng không được chuẩn hóa, đôi khi có nhiều bảng gần trùng lặp giữ các biến thể nhỏ trên dữ liệu của nhau. Các ràng buộc thường ở dạng thủ tục lưu trữ được thực thi kém. Ngay cả các loại dường như không được lưu trữ đúng. Tôi đã gặp tất cả các loại dữ liệu xấu mà Oracle dường như bỏ qua nhưng đã cung cấp (và đúng như vậy) cho Trình hướng dẫn Nhập / Xuất của SQL Server. (Ví dụ: hai số nguyên không tạo thành một datetime hoàn chỉnh!)

Chương trình ban đầu có lẽ đã quay trở lại hai mươi năm và tất cả các nhà phát triển ban đầu đã nghỉ hưu từ lâu đến nỗi ngay cả những người lớn tuổi ở đây cũng không biết họ là ai. Do đó, thực sự cũng không có bất kỳ yêu cầu rõ ràng nào được đưa ra - chúng tôi chỉ cần sao chép chức năng của ứng dụng hiện có và giữ dữ liệu hiện có của nó.

Kết quả cuối cùng của việc viết lại sẽ là một phiên bản dựa trên web chạy trên ASP.NET với MS SQL Server cho mặt sau.

Hai đồng đội phát triển khác của tôi lớn hơn tôi nhiều tuổi, cả hai đều có nền tảng kinh doanh / MIS trong khi tôi là CS. Kinh nghiệm của thành viên cấp cao hầu như chỉ là các hình thức của Oracle và thành viên khác hầu hết đã thực hiện các ứng dụng kinh doanh hoạt động trong Visual Basic. Mặc dù nền tảng cơ sở dữ liệu của tôi đã bị giới hạn trong việc thiết kế cơ sở dữ liệu mới cho các dự án trong MySQL hoặc SQLite, chủ yếu là cho các lớp dưới đại học của tôi, tôi dường như là người duy nhất có kinh nghiệm thực sự thiết kế cơ sở dữ liệu.

Tôi đã viết một chương trình nhỏ trong C # đọc tất cả dữ liệu hiện có sang định dạng trung tính, sẵn sàng để được truyền lại và đặt vào cơ sở dữ liệu mới. Tôi dự định viết mã tải sau khi cơ sở dữ liệu đích được thiết kế, để dữ liệu có thể được phân chia chính xác qua các bảng được chuẩn hóa mới, được thêm vào theo đúng thứ tự để tuân theo các ràng buộc mới, v.v. để sao chép dữ liệu sản xuất sang thiết kế lại hoàn thành mới được triển khai thực sự. Điều này để lại thiết kế lại thực tế của cơ sở dữ liệu là điều chính để tìm ra.

Vì vậy, trung tâm của câu hỏi của tôi: một số thực tiễn tốt nhất để thực hiện thiết kế lại từ cơ sở dữ liệu lên đến một ứng dụng hiện có là gì?

Tôi nghĩ bạn đã biết cách bình thường hóa cơ sở dữ liệu.

Những gì bạn cần là các chiến lược để giảm thiểu rủi ro khi chuyển tất cả phần mềm sang cơ sở dữ liệu mới.

Những gì tôi đang đề xuất là làm việc nhiều hơn như một sự đánh đổi để ít rủi ro hơn.

Bình thường hóa cơ sở dữ liệu và tạo một quy trình để điền vào cơ sở dữ liệu đã chuẩn hóa với dữ liệu từ cơ sở dữ liệu gốc. Cơ sở dữ liệu ban đầu sẽ là cơ sở dữ liệu để chèn, cập nhật và xóa. Cơ sở dữ liệu chuẩn hóa sẽ chỉ là cơ sở dữ liệu truy vấn trong quá trình chuyển đổi.

Quá trình dân cư của bạn sẽ phải chạy thường xuyên như nhu cầu về dữ liệu truy vấn. Nếu dữ liệu cũ ban ngày được chấp nhận, bạn có thể chạy quy trình nhập cư hàng đêm. Nếu bạn cần thêm dữ liệu hiện tại, bạn phải chạy một quy trình dân cư liên tục.

Xây dựng phần truy vấn của hệ thống ASP.NET mới của bạn, trỏ đến cơ sở dữ liệu chuẩn hóa mới.

Các kết quả truy vấn từ hệ thống mới của bạn sẽ so sánh với các kết quả truy vấn từ hệ thống ban đầu.

Bạn có thể dừng lại ở thời điểm này. Đó là một quyết định kinh doanh, không phải là một quyết định kỹ thuật.

Để giải trí, bạn tạo chức năng chèn / cập nhật / xóa mới trong hệ thống ASP.NET mới của mình. Khi bạn tạo chức năng mới, bạn tắt các phần của hệ thống ban đầu tương ứng. Tại một số điểm, không có gì của hệ thống ban đầu vẫn còn.

Ưu điểm của việc chuyển đổi theo cách này là giảm rủi ro bằng cách xây dựng phần truy vấn trước. Nói chung, các hàm truy vấn rất đơn giản so với logic nghiệp vụ được nhúng trong chức năng chèn / cập nhật / xóa.

Bạn chuyển đổi chức năng chèn / cập nhật / xóa một quá trình tại một thời điểm. Nếu có vấn đề với việc hiểu sai logic kinh doanh, nó có thể được sửa trong khi người dùng của bạn đang sử dụng hệ thống ban đầu.

Nó nên đi mà không nói rằng quá trình dân cư của bạn tốt hơn là hoàn toàn phù hợp.

Hãy cố gắng thuyết phục họ ký hợp đồng phát triển hệ thống mới cho một công ty bên ngoài, có rất nhiều công ty phát triển tốt có nguồn lực để phát triển ứng dụng đúng cách nhanh hơn và tốt hơn nhóm hạn chế của bạn. Một công ty phát triển tốt cũng sẽ có thể buộc cấp trên của bạn làm những việc họ có thể không làm nếu bạn yêu cầu họ làm, Thủ tướng của công ty được trả rất nhiều tiền để phát triển một ứng dụng có nhiều sự lôi kéo hơn để thu hút sự tham gia của người dùng hơn anh chàng IT nhiều cấp dưới quyền quản lý để sắp xếp những việc như vậy.

Nó tốn rất nhiều tiền trước mắt, nhưng nó sẽ trả hết thời gian lớn để có các nguồn lực thích hợp để phát triển và thực hiện. Nếu bạn quản lý để đưa RFP ra, tôi sẽ đặt cược rằng giá thầu bạn nhận được cho thấy rằng những gì bạn đang cố gắng làm phức tạp hơn nhiều so với những người quản lý của bạn nhận ra.

Thiết kế cơ sở dữ liệu chuẩn hóa mà bạn cần với các loại dữ liệu bạn cần. Sau đó, phần khó nhất là di chuyển dữ liệu. Trước tiên, bạn cần có một kế hoạch về cách bạn sẽ ánh xạ từ cũ sang mới và những gì bạn sẽ làm với dữ liệu không đáp ứng cấu trúc mới. Chẳng hạn, bạn có thể có dữ liệu hiện không thể xác định được nếu bạn không có các ràng buộc toàn vẹn phù hợp. Bạn có thể muốn đơn giản là không di chuyển dữ liệu đó hoặc bạn có thể cần di chuyển dữ liệu đó nhưng đính kèm nó vào một bản ghi gốc mới có tên là "Unknown". Nếu một ngày không thực sự là một ngày thực sự, bạn có thể đặt null vào trường khi di chuyển không? Bạn sẽ cần câu trả lời cho những loại câu hỏi. Tôi muốn đề nghị rằng bạn nên có một số nhà phát triển làm việc trên guin để sử dụng cấu trúc cơ sở dữ liệu mới và những người khác để làm việc nghiêm ngặt trong việc di chuyển. Việc di chuyển là một nhiệm vụ lớn, nó sẽ mất rất nhiều kỹ năng và rất nhiều thời gian. Đừng để nó như một suy nghĩ lại.

Vì bạn đang sử dụng SQL Server, bạn có thể thực hiện di chuyển thực tế thông qua SSIS.

Tạo một tập hợp các trường hợp kiểm thử tốt để bạn có thể so sánh kết quả đó với hệ thống cũ giống với hệ thống mới.

Bởi vì bạn có rất nhiều năm dữ liệu, bạn có thể muốn di chuyển thành hai phần. Đầu tiên di chuyển hầu hết dữ liệu và sau đó là thời gian để đi vào hoạt động, chỉ di chuyển dữ liệu đã thay đổi. Tất nhiên, bạn sẽ cần đặt các điều khiển vào vị trí trên cơ sở dữ liệu để có thể tìm thấy dữ liệu thay đổi mà bạn có thể chưa có. Bạn cũng có thể comsider tại thời điểm này nếu bạn muốn lưu trữ một số dữ liệu.

Tôi phải đối mặt với việc thiết kế lại lược đồ cơ sở dữ liệu gần như hàng ngày do hỗ trợ và phát triển thêm một số ứng dụng cũ được sinh ra dưới dạng tệp MS Access (.mdb) và sau đó phát triển thành cơ sở dữ liệu lớn với hàng trăm bảng hiện có trên MS SQL Máy chủ nhưng vẫn có "sự cố trẻ sơ sinh" của thiết kế ban đầu. Dưới đây là một số thực hành tôi thấy hữu ích cho tôi:

Cố gắng giảm thiểu bề mặt có sẵn công khai của lược đồ cơ sở dữ liệu của bạn.

Điều này có nghĩa là bạn nên cố gắng thiết kế một số API công khai mà bạn cung cấp cho các ứng dụng bên ngoài. Tôi thường cố gắng thực hiện dữ liệu tĩnh dưới dạng các khung nhìn (ngay cả khi chúng chỉ dựa trên một bảng) và dữ liệu động dưới dạng các tham số được tham số hóa hoặc như các thủ tục được lưu trữ. Đối với các truy vấn dữ liệu trong đó chỉ một giá trị duy nhất là đủ, người ta cũng có thể sử dụng các hàm vô hướng.

Chỉ những cái này (khung nhìn, thủ tục được lưu trữ và các hàm vô hướng) được hiển thị cho các ứng dụng bên ngoài (thông qua ORM hoặc trực tiếp) và được sử dụng cho tất cả các hoạt động CRUD. Lược đồ này sau đó bị đóng băng hoàn toàn, trong khi bên trong bạn có thể thay đổi các bảng bên dưới, cải thiện các quy trình của mình, v.v. - điều này sẽ không phá vỡ tính tương thích với ứng dụng của bạn.

Cố gắng tối ưu hóa cho các tiêu chí trong thế giới thực, không phải cho những người từ sách.

Chuẩn hóa là một chủ đề lớn trong mỗi cuốn sách về thiết kế cơ sở dữ liệu. Nhưng trong cuộc sống thực, có những trường hợp khi bình thường hóa sẽ không mang lại cho bạn nhiều hoặc thậm chí làm chậm cơ sở dữ liệu của bạn, ví dụ nếu bạn có một số dữ liệu được lặp lại, nhưng tỷ lệ lặp lại rất thấp, v.v. Tôi không chống lại bình thường hóa, Điều tôi đang cố gắng nói ở đây là bạn phải giải quyết nó bằng một chút hoài nghi và thận trọng.

Ghi lại phiên hồ sơ và phân tích chúng.

Thiết kế lại cơ sở dữ liệu chỉ dựa trên lược đồ cơ sở dữ liệu chưa hoàn tất. Nhìn vào cơ sở dữ liệu của bạn trong động lực học của nó, cố gắng tìm ra các nút thắt cổ chai trong quá trình kiểm tra tải và giải quyết chúng. Trong trường hợp MS SQL Server, có một Cố vấn điều chỉnh đặc biệt có thể tạo ra một số đề xuất theo dõi hoạt động được ghi lại.

Đây là câu trả lời của tôi:

1. Trước tiên hãy hiểu hệ thống cơ sở dữ liệu hiện tại càng nhiều càng tốt. Bạn cần biết tất cả các công dụng của các hệ thống này cũng như người dùng. Bạn cần biết tất cả các nguồn cho hệ thống cũng như các hệ thống mà nó có thể đang phục vụ như hệ thống nguồn của chúng.

2. Bạn cần xác định tất cả các sử dụng khác nhau của hệ thống, cho dù đó là cho hoạt động hoặc báo cáo hoặc cả hai. Xác định các ứng dụng và hệ thống ngược dòng có thể đang sử dụng cơ sở dữ liệu. Bằng cách làm như vậy, bạn sẽ biết các yếu tố của cơ sở dữ liệu hiện tại đã lỗi thời và không còn cần thiết nữa.

3. Đồng thời phân tích và hiểu quy trình ETL hiện tại tải dữ liệu vào cơ sở dữ liệu và trích xuất dữ liệu từ cơ sở dữ liệu.

4. Hiểu tất cả các yếu tố dữ liệu của cơ sở dữ liệu và nếu bạn có thể xây dựng ma trận hộp có thể giúp bạn xác định các yếu tố trùng lặp.

5. Có được tất cả thông tin, bạn có thể tiếp cận thiết kế lại như thể bạn đang thiết kế cơ sở dữ liệu lần đầu tiên với thông tin bạn đã thu thập như một phần của việc thu thập yêu cầu của bạn.

6. Chúc may mắn!