Trong nhiều năm làm việc với tư cách là người lập mô hình dữ liệu và kiến trúc sư cơ sở dữ liệu, tôi đã nhận thấy rằng có một số quy tắc cần được tuân thủ trong quá trình xây dựng và mô hình hóa dữ liệu. Ở đây tôi mô tả một số mẹo với hy vọng rằng chúng có thể giúp ích cho bạn. Tôi đã liệt kê các mẹo theo thứ tự mà chúng xuất hiện trong vòng đời của dự án hơn là liệt kê chúng theo mức độ quan trọng hoặc mức độ phổ biến của chúng.
1. Lên kế hoạch
Không lập kế hoạch là việc lập kế hoạch thất bại.
Alan Lakein
Một vấn đề mà tôi đã thấy là khi mô hình hóa dữ liệu xảy ra cùng lúc với phát triển phần mềm. Điều này giống như việc xây dựng nền móng trước khi hoàn thành các bản thiết kế. Trước đây, lập kế hoạch dường như là một bước hiển nhiên trước khi bắt đầu phát triển. Các nhóm phát triển sẽ không tạo cơ sở dữ liệu mà không lập kế hoạch giống như các kiến trúc sư sẽ không xây dựng các tòa nhà mà không có bản thiết kế.
Trong phát triển ứng dụng, điều quan trọng là phải hiểu bản chất của dữ liệu.
Việc lập kế hoạch thường bị bỏ qua để các nhà phát triển có thể “bắt đầu viết mã”. Dự án bắt đầu và khi các vấn đề xuất hiện, không có sự chậm trễ trong lịch trình để giải quyết chúng. Các nhà phát triển sử dụng các phím tắt với mục đích sửa chúng sau nhưng điều này hiếm khi xảy ra.
Lập kế hoạch cẩn thận là cách đảm bảo rằng bạn có một cơ sở dữ liệu phù hợp và không bị tấn công cùng nhau. Nếu bạn không dành thời gian và công sức để giải quyết trước dữ liệu theo yêu cầu của các quy trình, bạn sẽ phải trả tiền cho nó sau này bằng một cơ sở dữ liệu phải được làm lại, thay thế hoặc loại bỏ.
Ngay cả khi việc lập kế hoạch không phải lúc nào cũng được thực hiện, nhiều nhà lập mô hình dữ liệu vẫn tuân theo các nguyên tắc này. Điều đó không có nghĩa là chúng tôi có thể dự đoán trước mọi nhu cầu thiết kế, nhưng hầu hết các nhà lập mô hình tin rằng cần nỗ lực để hiểu dữ liệu và cách sử dụng dữ liệu. Bạn sẽ không muốn một thiết kế để xử lý giao dịch khi nhu cầu là tạo báo cáo phân tích.
Thời gian đã thay đổi; Các phương pháp Agile đang phổ biến hơn nên các nhóm cơ sở dữ liệu phải suy nghĩ lại về cách tiếp cận của họ đối với mô hình dữ liệu. Trong Agile, Mô hình miền từ các Ca sử dụng được sử dụng thay vì Sơ đồ mối quan hệ thực thể. Tuy nhiên, nhu cầu lập kế hoạch vẫn không hề giảm bớt. Chúng tôi cần hiểu dữ liệu và những gì nó phải làm. Nói chung, một số Sprint đầu tiên phải tập trung vào thiết kế dữ liệu.
Vì vậy, vấn đề không phải Agile đối với những người lập mô hình cơ sở dữ liệu mà là những cá nhân không nắm bắt được bản chất của dữ liệu. Một số xem phát triển cơ sở dữ liệu cũng giống như phát triển ứng dụng. Mô hình hóa cơ sở dữ liệu và phát triển phần mềm là khác nhau và cần có trọng tâm thích hợp.
Cơ sở dữ liệu là cốt lõi của hầu hết các ứng dụng phần mềm. Bạn phải dành thời gian để phân tích các yêu cầu và mô hình dữ liệu sẽ đáp ứng chúng như thế nào. Điều này làm giảm khả năng quá trình phát triển sẽ mất đi hướng đi và hướng đi.
Các nhà phát triển phải hiểu tầm quan trọng của dữ liệu và đóng góp của nó vào quá trình phát triển. Chúng ta đang sống trong thời đại thông tin. Ứng dụng hiển thị và thao tác dữ liệu. Chính thông tin có trong dữ liệu mang lại ý nghĩa cho ứng dụng.
Không thể thấy trước mọi yêu cầu cũng như mọi vấn đề, nhưng điều quan trọng là phải chuẩn bị cho các vấn đề bằng cách lập kế hoạch cẩn thận.
2. Ghi lại mô hình của bạn
Khi thực hiện một mô hình dữ liệu, mọi thứ dường như hiển nhiên. Bạn đặt tên cho đồ vật sao cho mục đích của chúng được thể hiện rõ ràng và chỉ cần đọc tên là mọi người sẽ hiểu được ý nghĩa. Điều này có thể đúng, nhưng nó không hiển nhiên như bạn nghĩ. Khi chọn tên cho bảng và cột, hãy làm rõ cách sử dụng của từng đối tượng. Theo thời gian, ý nghĩa của các đối tượng sẽ không rõ ràng nếu không có tài liệu.
Sử dụng quy ước đặt tên là một bước hướng tới tài liệu hiệu quả. Khi bạn phải thực hiện các thay đổi trong tương lai, bạn sẽ đánh giá cao mọi tài liệu hiện có. Một tài liệu ngắn, đơn giản mô tả các quyết định mà bạn đã đưa ra và mô tả thiết kế sẽ giúp giải thích lựa chọn thiết kế tại thời điểm đó.
Bạn muốn có đủ tài liệu để quản trị viên mới có thể quản lý cơ sở dữ liệu và họ có thể hiểu ý nghĩa mà không cần phải quay lại gặp bạn để giải thích. Nếu mô hình dữ liệu và môi trường không được lập thành văn bản, rất khó để duy trì hoặc thay đổi nó khi các yêu cầu thay đổi.
Ở một mức độ nào đó, tài liệu có rất ít liên quan đến việc lập mô hình dữ liệu. Tài liệu giúp truyền đạt thiết kế và làm cho nó dễ hiểu trong tương lai.
Tài liệu thường là một suy nghĩ sau. Khi lịch trình ngắn, tài liệu sẽ bị bỏ qua. Tuy nhiên, đây là khoản nợ kỹ thuật với chi phí cao. Việc cắt giảm các góc trong chu kỳ phát triển sẽ tích lũy chi phí trong tương lai cho các thay đổi cơ sở dữ liệu, xác định vấn đề, theo dõi lỗi và để hiểu mô hình dữ liệu và bản chất của dữ liệu.
Ví dụ:các mô hình dữ liệu thường có trường “ID” làm khóa chính cho bảng hoặc một phần tên của khóa. Đây có thể là một khóa chính như TransactionID trên Transaction bàn. Nếu một số bảng sử dụng "Số" như một phần của tên khóa, thì tốt hơn là nên ghi lại lý do tại sao. Có lẽ ReferenceNumber được sử dụng làm tên của khóa chính trên Thông báo vì đó là những gì tham chiếu được gọi trong lĩnh vực kinh doanh. Ví dụ:trong các dịch vụ tài chính, thông báo tài chính thường bao gồm một số tham chiếu.
Ghi lại định nghĩa của bảng, cột và mối quan hệ để người lập trình có thể truy cập thông tin. Tài liệu phải mô tả các kỳ vọng của cấu trúc cơ sở dữ liệu.
Trong công cụ Vertabelo, tôi có thể đưa ngay nhận xét vào bất kỳ mục nào:bảng, cột, tham chiếu, khóa thay thế, có nghĩa là tài liệu được lưu trữ ngay lập tức với kiểu máy của tôi chứ không phải trong một số tài liệu bổ sung được lưu trữ riêng biệt.
Tài liệu kém hoặc không có thường là do suy nghĩ thiển cận, nhưng đừng bỏ qua tầm quan trọng của nó. Đây vẫn là một vấn đề cần được giải quyết.
3. Tuân theo các quy ước
Quy ước đặt tên có thể không quan trọng trong quá trình thiết kế. Trên thực tế, tên gọi cung cấp cái nhìn sâu sắc để hiểu một mô hình. Chúng là một phần mở đầu và phải logic.
Đặt tên không nhất quán không có mục đích gì. Nó chỉ làm phiền các nhà phát triển phải truy cập dữ liệu, quản trị viên cơ sở dữ liệu và người lập mô hình, những người phải thực hiện các thay đổi trong tương lai.
Khi “ID” được sử dụng cho một số khóa nhân tạo nhưng một số bảng sử dụng quy ước đặt tên khác (chẳng hạn như Số), các nhà phát triển, nhà phân tích và DBA có thể lãng phí thời gian để hiểu các ngoại lệ. Quy ước đặt tên yếu cũng dẫn đến sai sót trong quá trình phát triển do việc đặt tên không nhất quán.
Có sẵn tài liệu hướng dẫn, sử dụng quy ước đặt tên giúp ai đó có thể hiểu được mô hình trong tương lai. Không chuyển đổi ngẫu nhiên giữa việc sử dụng “ID” (như CustomerID ) và “Số” (AccountNumber ) làm khóa cho các bảng. Chỉ đưa ra các ngoại lệ đối với các quy ước khi chúng được chứng minh. Ghi lại ngoại lệ là gì và tại sao quy ước không được tôn trọng.
Điều tương tự cũng áp dụng cho những cái tên khó hiểu như “XRT1” - đó có phải là các bảng tham chiếu mở rộng không? Dự đoán của bạn cũng tốt như của tôi. Tôi hy vọng rằng nhà thiết kế biết tại sao anh ấy lại chọn một cái tên khó hiểu như vậy, nhưng tôi nghi ngờ rằng người tiếp theo truy cập vào cơ sở dữ liệu có thể đoán được lý do.
Quy ước đặt tên là một vấn đề của sự lựa chọn cá nhân. Đảm bảo các quyết định nhất quán và được lập thành văn bản.
Nếu tôi thành công trong việc thuyết phục bạn áp dụng quy ước đặt tên trong thiết kế cơ sở dữ liệu của bạn, vui lòng đọc bài viết tiếp theo của tôi hoàn toàn dành cho chủ đề này.
4. Suy nghĩ kỹ về các phím
Các khóa thường gây ra tranh cãi:khóa chính, khóa ngoại và khóa nhân tạo. Các bảng cần một khóa chính xác định từng hàng. Nghệ thuật là quyết định cột nào nên là một phần của khóa chính và những giá trị nào cần bao gồm.
Để chuẩn hóa thích hợp, mỗi bảng cần có một khóa nhận dạng. Tính độc đáo phải được đảm bảo. Tuy nhiên, khóa tự nhiên và khóa chính không nhất thiết phải giống nhau. Trên thực tế, chúng có thể không, miễn là bảng có khóa tự nhiên.
Một số nhà lập mô hình dữ liệu thích một khóa nhân tạo để tạo tính duy nhất. Tuy nhiên, một số nhà lập mô hình thích một khóa tự nhiên để đảm bảo tính toàn vẹn của dữ liệu.
Vì vậy, chúng ta có nên sử dụng một khóa tự nhiên làm khóa chính? Một thách thức nảy sinh nếu khóa tự nhiên phải được thay đổi. Nếu khóa tự nhiên bao gồm nhiều cột, bạn có thể cần thực hiện thay đổi ở nhiều chỗ. Một thách thức khác là sử dụng khóa nhân tạo làm khóa duy nhất cho bảng.
Ví dụ:bạn có thể có một bảng lưu trữ thông tin về sản phẩm. Bảng có thể được xác định bằng khóa nhân tạo như dãy, mã cho tên chữ cái ngắn của sản phẩm và định nghĩa sản phẩm. Nếu chỉ đảm bảo tính duy nhất bằng khóa nhân tạo thì có thể có hai hàng có cùng mã sản phẩm. Đây có phải là cùng một sản phẩm được nhập hai lần? Có lẽ khóa có mã sản phẩm thích hợp hơn.
5. Sử dụng Kiểm tra tính toàn vẹn một cách cẩn thận
Để đảm bảo tính toàn vẹn của dữ liệu, chúng ta cần các khóa và ràng buộc ngoại. Hãy cẩn thận để không lạm dụng hoặc lạm dụng các kiểm tra tính toàn vẹn này.
Bảng miền có hiệu quả để thực thi tính toàn vẹn. Bảng miền hoạt động tốt khi có nhiều giá trị cần kiểm tra hoặc các giá trị cần kiểm tra thường xuyên thay đổi.
Một vấn đề có thể là các nhà phát triển quyết định rằng ứng dụng sẽ kiểm tra tính toàn vẹn. Vấn đề ở đây là một cơ sở dữ liệu trung tâm có thể được nhiều ứng dụng truy cập. Ngoài ra, bạn thường muốn bảo vệ dữ liệu ở vị trí:trong cơ sở dữ liệu.
Nếu các giá trị có thể bị giới hạn hoặc trong một phạm vi, thì ràng buộc kiểm tra có thể thích hợp hơn. Giả sử rằng thư được xác định là Thư đến hoặc Thư đi, trong trường hợp này không cần khóa ngoại. Tuy nhiên, đối với những thứ như tiền tệ hợp lệ, mặc dù chúng có vẻ tĩnh, nhưng chúng thực sự thay đổi theo thời gian. Các quốc gia tham gia liên minh tiền tệ và tiền tệ thay đổi.
Các ứng dụng cũng phải thực hiện kiểm tra tính toàn vẹn, nhưng đừng chỉ dựa vào ứng dụng để kiểm tra tính toàn vẹn. Việc xác định các quy tắc toàn vẹn trên cơ sở dữ liệu đảm bảo rằng các quy tắc đó sẽ không bao giờ bị vi phạm. Bằng cách này, dữ liệu luôn thỏa mãn các quy tắc toàn vẹn đã xác định.
6. Đừng quên các chỉ mục trong thiết kế của bạn
Một số thiết kế lập chỉ mục rất hữu ích trong quá trình lập mô hình cơ sở dữ liệu, ngay cả khi các chỉ mục có thể thay đổi trong quá trình triển khai và sử dụng thực tế. Tất nhiên, có thể có quá nhiều chỉ mục, cũng giống như có thể có quá ít.
Lập chỉ mục là một quá trình liên tục. Trong quá trình thiết kế, bạn bắt đầu quá trình trên mô hình của mình. Công việc thiết kế dựa trên các khóa chính và các ràng buộc.
Chỉ mục rất quan trọng khi xem xét các truy vấn trên dữ liệu. Khi lập mô hình, bạn nên xem xét cách dữ liệu sẽ được truy vấn. Chú ý đừng lập chỉ mục quá mức. Lập chỉ mục xoay quanh việc tối ưu hóa truy vấn.
7. Tránh các bảng tra cứu thông thường
Tôi thường thấy một bảng tra cứu chung cho các cặp thuộc tính. Việc xác định một bảng miền chung, duy nhất được coi là đơn giản hóa thiết kế. Kiểu bảng miền này tạo ra một định nghĩa trừu tượng cho việc lưu giữ văn bản. Tôi đã nghe nói nó được gọi là bảng “Giá trị được phép” hoặc “Giá trị hợp lệ”, nhưng thuật ngữ bảng “MUCK” đã được đặt ra cho loại chống này vào năm 2006:Khóa mã thống nhất rộng rãi.
Bảng MUCK chứa dữ liệu không liên quan.
Ví dụ:bạn có thể có một bảng xác định miền, mục nhập và mô tả. Nghĩ lại ví dụ thông báo ở trên, hai mục nhập có thể là:
| Tên miền | Mục nhập | Mô tả |
|---|---|---|
| 1 | Tôi | Ngân hàng nhận được tin nhắn đến |
| 1 | O | Thư đi do ngân hàng gửi |
Bây giờ, hãy thêm các mục nhập cho một miền khác:
| Tên miền | Mục nhập | Mô tả |
|---|---|---|
| 2 | BÌA | Bao thanh toán |
| 2 | SERIAL | Thanh toán nối tiếp |
| 2 | SSI | Hướng dẫn Thu xếp Tiêu chuẩn |
Đây chỉ là một mớ hỗn độn. Bảng có nghĩa là gì?
Để cho vui, tôi đã mô hình hóa một ví dụ đơn giản về bảng MUCK (hoặc OTLT, “Một bảng tra cứu đích thực” nếu bạn là người hâm mộ Tolkien) và kèm theo một số nhận xét. Xin lưu ý rằng đây là một mô hình chống lại và tôi không khuyên bạn nên sử dụng nó trong mô hình dữ liệu của mình.
Với bảng MUCK, không thể xác định các ràng buộc. MUCK có thể trở thành nhiều hàng mà không có bất kỳ ý nghĩa nào. Khi bạn phải truy vấn một bảng khác để hiểu ý nghĩa của một trường, điều này không lý tưởng.
Các bảng “bất cứ điều gì xảy ra” làm cho việc kiểm tra tính toàn vẹn trở nên phức tạp hoặc thậm chí là không thể. Một lý do mà các bảng này có thể được tạo là vì một số bảng trong cơ sở dữ liệu có định nghĩa tương tự. Khi đó, việc kiểm tra tính toàn vẹn của dữ liệu trở nên không thể. Ngoài ra, kích thước của chúng có thể trở nên khá lớn.
Quá trình bình thường hóa nên tránh xa các bảng MUCK. Một bảng đơn nên đại diện cho một miền duy nhất; chứ không phải là một bảng (MUCK) duy nhất đại diện cho tất cả các miền. Nếu không có bảng MUCK, chúng ta có thể đặt các ràng buộc khóa ngoại.
Sử dụng các bảng riêng biệt cho các đối tượng miền thay vì nhồi nhét chúng vào một bảng duy nhất. Điều này cho phép các loại cột, ràng buộc và mối quan hệ thích hợp. Bảng "Giá trị được phép" chỉ là một mớ hỗn độn và không có vị trí trong mô hình dữ liệu.
8. Xác định Chiến lược Lưu trữ
Tôi thường xuyên thấy cơ sở dữ liệu được tạo ra mà không có chiến lược lưu giữ và lưu trữ dữ liệu thích hợp. Dữ liệu sẽ được lưu giữ trực tuyến trong các bảng cơ sở dữ liệu đang hoạt động trong bao lâu? Hầu hết các hệ thống được xây dựng để giữ dữ liệu trong cơ sở dữ liệu "mãi mãi". Đối với hầu hết các hệ thống, đây không phải là một chiến lược lưu giữ dữ liệu dài hạn hợp lý. Tại một số thời điểm, dữ liệu đang hoạt động sẽ được lưu trữ.
Một cách tiếp cận mà tôi ủng hộ là bao gồm việc lưu giữ dữ liệu như một phần của việc cân nhắc thiết kế của bạn. Bạn có các bảng hiện hoạt và lịch sử để việc chèn các hàng mới trong bảng hiện hoạt vẫn nhanh chóng trong khi các tìm kiếm trên dữ liệu lịch sử có thể được tối ưu hóa không?
Điều này tránh phải thiết kế lại lưu trữ vào cơ sở dữ liệu của bạn trên thiết kế ban đầu.
9. Kiểm tra sớm, kiểm tra thường xuyên
Để diễn giải Al Capone (hoặc John Van Buren, con trai của Tổng thống thứ 8 của Hoa Kỳ), “hãy kiểm tra sớm, kiểm tra thường xuyên”. Bằng cách này, bạn đi theo con đường Tích hợp liên tục. Thử nghiệm ở giai đoạn phát triển ban đầu giúp tiết kiệm thời gian và tiền bạc.
Kiểm tra luôn là một thách thức trong kế hoạch phát triển. Thường có một giai đoạn kiểm tra khi kết thúc Agile Sprint và kiểm tra hệ thống khi kết thúc quá trình phát triển. Kiểm tra nói chung là điều đầu tiên cần được thực hiện khi thời gian ngắn lại.
Trong quá trình kiểm tra cơ sở dữ liệu, mục tiêu phải là mô phỏng môi trường sản xuất:“Một ngày trong vòng đời của cơ sở dữ liệu”. Những khối lượng nào có thể được mong đợi? Những tương tác nào của người dùng có thể xảy ra? Các trường hợp ranh giới có được xử lý không?
Vì vậy, kế hoạch kiểm tra và kiểm tra thích hợp phải là một phần không thể thiếu của việc xây dựng mô hình dữ liệu và phát triển cơ sở dữ liệu.
Kết luận
Đây là những vấn đề chính mà tôi đã thấy khi làm việc với người lập mô hình dữ liệu và xem xét mô hình dữ liệu. Bằng cách chú ý đến những mẹo này, cơ sở dữ liệu của bạn sẽ được thiết kế tốt hơn và mạnh mẽ hơn. Tuy nhiên, việc hoàn vốn cho một số khoản đầu tư này không phải lúc nào cũng rõ ràng hoặc có thể nhìn thấy được. Lập kế hoạch, lập tài liệu, sử dụng các tiêu chuẩn, tạo khóa, đảm bảo tính toàn vẹn, thực hiện lập chỉ mục, tránh MUCK, phát triển chiến lược và KIỂM TRA!
Không có hoạt động nào trong số này sẽ mất nhiều thời gian nhưng lại có tác động lớn đến chất lượng mô hình dữ liệu của bạn.
Quan điểm của bạn về những mẹo này là gì?
