Theo kinh nghiệm của tôi, sơ đồ ER (hoặc UML) không phải là tạo tác hữu ích nhất - với một số lượng lớn các bảng, sơ đồ (đặc biệt là những sơ đồ được thiết kế ngược) thường là một mớ hỗn độn phức tạp mà không ai học được gì từ đó.
Đối với tiền của tôi, một số tài liệu tốt mà con người có thể đọc được (có thể được bổ sung với các sơ đồ của các phần nhỏ hơn của hệ thống) sẽ mang lại cho bạn một quãng đường dài nhất. Điều này sẽ bao gồm, cho mỗi bảng:
- Mô tả về ý nghĩa của bảng và cách nó được sử dụng theo chức năng (trong giao diện người dùng, v.v.)
- Mô tả ý nghĩa của từng thuộc tính, nếu nó không rõ ràng
- Giải thích về các mối quan hệ (khóa ngoại) từ bảng này với bảng khác và ngược lại
- Giải thích về các ràng buộc và / hoặc trình kích hoạt bổ sung
- Giải thích bổ sung về các chế độ xem và tài liệu chính liên quan đến bảng, nếu chúng chưa được ghi chép đầy đủ
Với tất cả những điều trên, đừng tài liệu hóa vì mục đích tài liệu - tài liệu trình bày lại những điều hiển nhiên sẽ cản trở mọi người. Thay vào đó, hãy tập trung vào những thứ khiến bạn bối rối lúc đầu và dành vài phút để viết những lời giải thích thật rõ ràng, ngắn gọn. Điều đó sẽ giúp bạn suy nghĩ thấu đáo và nó sẽ ồ ạt trợ giúp các nhà phát triển khác, những người lần đầu tiên sử dụng các bảng này.
Như những người khác đã đề cập, có rất nhiều công cụ giúp bạn quản lý việc này, như Enterprise Architect, Red Gate SQL Doc và các công cụ tích hợp sẵn từ các nhà cung cấp khác nhau. Nhưng mặc dù hỗ trợ công cụ rất hữu ích (và thậm chí rất quan trọng, trong các cơ sở dữ liệu lớn hơn), việc thực hiện công việc khó khăn là hiểu và giải thích mô hình khái niệm của cơ sở dữ liệu là chiến thắng thực sự. Từ góc độ đó, bạn thậm chí có thể làm điều đó trong một tệp văn bản (mặc dù làm điều đó trong biểu mẫu Wiki sẽ cho phép một số người cộng tác để thêm vào tài liệu đó dần dần - vì vậy, mỗi khi ai đó tìm ra điều gì đó, họ có thể thêm nó vào cơ thể đang phát triển của tài liệu ngay lập tức).
