Khi viết một bài đăng trên blog về mô hình cơ sở dữ liệu, bạn phải chuẩn bị rằng mô hình trừu tượng của bạn không đáp ứng được nhu cầu của hầu hết người đọc. Lý do rất đơn giản. Các mô hình cơ sở dữ liệu trong đời thực thường được tạo liên quan chặt chẽ đến các yêu cầu phát triển và kinh doanh cụ thể trong khi các mô hình blog thì không.
Trong vài tuần gần đây, tôi đã viết các bài đăng trên blog về việc tạo các mô hình cơ sở dữ liệu. Các chủ đề trải dài từ cách tiếp cận chung để lập mô hình cơ sở dữ liệu thông qua một diễn đàn trực tuyến đơn giản đến mô hình cho một cuộc khảo sát trực tuyến phức tạp hơn.
Đối với mỗi mô hình cơ sở dữ liệu mà tôi tạo, tôi cố gắng hiểu rõ ràng lĩnh vực kinh doanh và tìm ra trong đầu bức tranh toàn cảnh về mô hình.
Thách thức của phát triển cơ sở dữ liệu trừu tượng
Thông thường, như một giải pháp kiến trúc sư , Tôi thực hiện các yêu cầu kinh doanh cụ thể và chuyển đổi các yêu cầu đó thành các chi tiết kỹ thuật của những gì cần được tạo từ phía kỹ thuật: dịch từ ngôn ngữ kinh doanh sang ngôn ngữ kỹ thuật - thiết kế các thuật toán ở cấp độ cao và mô hình hóa các yêu cầu dữ liệu cho các thuật toán.
Rất tiếc, tôi không thể viết blog về các mô hình cơ sở dữ liệu trong thế giới thực mà tôi tạo tại nơi làm việc. Đối với một điều, chúng rất cụ thể đối với lĩnh vực kinh doanh và đối với một điều khác, tôi bị hạn chế bởi các thỏa thuận bảo mật. Đối với blog, tôi tạo một bản tóm tắt hoàn toàn khái niệm không có yêu cầu kinh doanh cụ thể ngoại trừ những yêu cầu mà tôi tưởng tượng tồn tại trong lĩnh vực kinh doanh. Bây giờ, điều đó ổn; Tôi có trí tưởng tượng khá tốt và tôi thường xuyên chỉ ra rằng các yêu cầu của bạn có thể khác khi tôi mô tả các lựa chọn mà tôi đang thực hiện. Nhưng quá trình viết blog này khiến tôi nghĩ về quá trình này khác với việc tạo ra các mô hình trong một dự án thực tế như thế nào.
Quá trình phát triển trong đời thực
Trong tình huống thực tế, tôi sẽ làm việc chặt chẽ với nhóm phát triển sau khi tạo ra giải pháp cấp cao và thiết kế kỹ thuật trong một tương tác để mô hình phù hợp với nhu cầu phát triển.
Các nhà phát triển có thể phàn nàn rằng mô hình dữ liệu quá bình thường để hỗ trợ hiệu suất cao hoặc họ có thể yêu cầu chuẩn hóa bổ sung trong một số khu vực nhất định. Nếu bất kỳ Khóa thay thế nào bị thiếu, các nhà phát triển sẽ nhanh chóng phàn nàn và chúng tôi cũng sẽ nhận thấy điều đó trong quá trình kiểm tra hiệu suất của cơ sở dữ liệu.
Chúng tôi sẽ xem xét độ dài trường chính xác nên dựa trên độ dài tối đa của dữ liệu được lưu trữ và trên thiết kế màn hình để nhập và hiển thị dữ liệu. Tất nhiên, độ dài trường chính xác trong mô hình cơ sở dữ liệu khái niệm không quan trọng.
Chúng tôi sẽ làm việc thông qua các ví dụ về dữ liệu nào sẽ được lưu trữ trong các bảng và cách nó sẽ được ứng dụng sử dụng, đồng thời tạo các tập lệnh để điền trước các bảng để kiểm tra đơn vị của ứng dụng. Bằng cách này, chúng tôi sẽ nắm bắt các trường hợp góc để đảm bảo rằng mô hình hỗ trợ các giới hạn của ứng dụng.
Vì vậy, về cơ bản, chúng tôi sẽ xoa bóp mô hình cho đến khi nó thực sự hỗ trợ các yêu cầu kinh doanh và phi chức năng của hệ thống bằng quy trình lặp đi lặp lại cho đến khi chúng tôi phát triển một mô hình thành một thứ mà tất cả chúng ta đều có thể chấp nhận bất chấp những thỏa hiệp được tích hợp trong đó.
Như tôi đã nói, đây sẽ là một quá trình lặp đi lặp lại có thể tiếp tục trong nhiều tháng trong khi mã ứng dụng, giao diện người dùng và giao diện ứng dụng đang được phát triển.
Hạn chế của phản hồi có mục đích tốt
Trong tình hình viết blog hiện tại, mặc dù số lượng độc giả được thừa nhận là hạn chế của tôi, cung cấp cho tôi phản hồi về các vấn đề và thách thức mà họ quan sát được với các mô hình, thì điều đó nhất thiết phải là hời hợt. Tôi nghi ngờ rằng có bất kỳ độc giả nào đang trực tiếp sử dụng các mô hình để tạo ứng dụng và khám phá những gì thực sự hoạt động và nơi có vấn đề.
Vì vậy, những nhận xét như "mô hình không được suy nghĩ tốt" gần như chắc chắn là đúng. Mặt khác, “còn thiếu FK” là khá chính xác, nhưng hy vọng tôi đã giải thích trong phần nội dung của bài viết tại sao tôi lại đưa khóa ngoại vào hay không.
Kết luận
Bây giờ, vui lòng không đọc bài đăng này như một lời phàn nàn hoặc nhận xét về phản hồi mà người đọc đang đưa ra, thay vào đó tôi đang phản ánh về khó khăn của việc tạo mô hình cơ sở dữ liệu khi bạn không ở trong một môi trường cho phép trao đổi tương tác với lặp lại quá trình phát triển.
Có thể có những tình huống khác mà người lập mô hình cơ sở dữ liệu bị loại khỏi quá trình phát triển, nhưng giờ tôi đã nhận ra điều đó sẽ nguy hiểm như thế nào và chúng sẽ dễ gặp vấn đề như thế nào.
Bạn có thể tưởng tượng một mô hình cơ sở dữ liệu không bao giờ thay đổi không? Không bao giờ điều chỉnh một cột, không bao giờ bổ sung khóa ngoại, không bao giờ cần một bảng mới. Thành thật mà nói, tình huống duy nhất mà tôi có thể tưởng tượng như vậy là khi ứng dụng sử dụng cơ sở dữ liệu không còn phát triển nữa và đã đi đến ngõ cụt:kết thúc vòng đời.
