Làm thế nào để thực sự giải quyết các vấn đề kinh doanh, làm hài lòng người dùng và tránh những sai lầm tốn kém

Thiết kế cơ sở dữ liệu đưa ra một câu hỏi hóc búa: Làm thế nào bạn có thể thiết kế một cơ sở dữ liệu khi bạn chưa từng thiết kế một thứ gì đó tương tự?

Giống như, làm thế nào bạn có thể biết điều gì hiệu quả và điều gì không hiệu quả khi tất cả các mẹo và thủ thuật của bạn trên Google hơi khác hoặc tệ nhất là vẫn mâu thuẫn với nhau? Hoặc làm thế nào để bạn tránh được những sai lầm tốn kém có thể cản trở hiệu suất khi bạn đang xây dựng mọi thứ từ đầu? Dưới đây là 8 điều bạn có thể làm.

Tuyên bố từ chối trách nhiệm: Bài viết này tập trung vào các nguyên tắc để thiết kế cơ sở dữ liệu quan hệ, được cho là loại được sử dụng phổ biến nhất. Một số hướng dẫn có thể không liên quan đến thiết kế cơ sở dữ liệu không quan hệ và nên được thực hiện với một chút muối.

1. Suy nghĩ nghiêm túc về các vấn đề kinh doanh

Nếu bạn cần lấy đio điều ne từ bài này, nó phải là thế này. Các doanh nghiệp không chi tiền để tạo cơ sở dữ liệu chỉ để có được quyền chuẩn hóa, lập chỉ mục, hiệu suất truy vấn và tối ưu hóa. Họ đầu tư một lần vì tồn tại một vấn đề cốt yếu, và vấn đề đó phải được giải quyết . Điều này có nghĩa là vào cuối ngày, không có kỹ thuật thiết kế cơ sở dữ liệu ưa thích nào là vấn đề nếu vấn đề chưa được giải quyết.

Vì vậy, trước khi thiết kế bất cứ thứ gì cho cơ sở dữ liệu, tôi nghĩ điều quan trọng là phải tự hỏi bản thân 4 câu hỏi.

• Doanh nghiệp đang hy vọng giải quyết vấn đề gì với cơ sở dữ liệu (hoặc ứng dụng được cơ sở dữ liệu hỗ trợ)?
• Tôi đã hiểu đầy đủ những tác vụ nào cần phải được thực hiện bởi TẤT CẢ người dùng doanh nghiệp sẽ tương tác với hệ thống chưa?
• Tôi có thể tự tin liệt kê những dữ liệu cần thiết để cho phép người dùng doanh nghiệp thực hiện những công việc đó không?
• Các trường hợp ngoại lệ và bất thường được xử lý như thế nào trong thực tế?

Và vâng, tôi biết thật khó để trở thành chuyên gia trong các hoạt động thực tế, đặc biệt là khi tất cả chúng ta đều có thời hạn hoàn thành chặt chẽ. Nhưng nó không đủ tốt nếu chỉ dừng lại ở sự hiểu biết một phần và vội vàng cung cấp một cái gì đó. Đối với tôi, với tư cách là một chuyên gia, lời nhắc cơ bản này có nghĩa là dành thời gian cần thiết để đặt đủ câu hỏi, thu thập thông tin và đưa ra một số suy nghĩ nghiêm túc về vấn đề, cách tiếp cận, nhiệm vụ, giải pháp mong muốn và trách nhiệm đi kèm với nhận định của tôi . Tất cả chúng ta đều muốn tự hào vì đã tạo ra một giải pháp mạnh mẽ và chu đáo thay vì xây dựng một con quái vật cồng kềnh, tôi có chính xác không?

2. Sử dụng tên có ý nghĩa cho các đối tượng

Trước khi tạo bản nháp đầu tiên của mô hình cơ sở dữ liệu của bạn, việc chuẩn bị sẵn một số quy tắc nền tảng cơ bản để đặt tên đối tượng sẽ giúp bạn tiết kiệm rất nhiều thời gian để giao tiếp với các thành viên khác trong nhóm, người dùng doanh nghiệp và các bên liên quan.

Nhưng cũng đừng lãng phí cả tuần để thống nhất quy ước đặt tên. Ai đó chỉ cần đề xuất một bộ quy tắc, gửi cho mọi người và hoàn thiện nó trong một cuộc họp. Giữ cho nó ngắn gọn và ngọt ngào (ít hơn nửa trang A4 là lý tưởng) vì không ai thích cảm giác tham khảo tài liệu dài. Các trường hợp ngoại lệ sẽ phát sinh khi các trường và bảng mới được xác định, nhưng các kịch bản cụ thể đó có thể được thảo luận trong cuộc họp nhóm hàng ngày.

Nếu bạn cần một số cảm hứng, đây là một số quy tắc cơ bản mà tôi đã và đang sử dụng. Bạn có thể tuân theo một bộ quy tắc hoàn toàn khác và điều đó hoàn toàn ổn. Điều quan trọng nhất cần ghi nhớ là tên là để truyền đạt những ý nghĩa nhất định, vì vậy hãy làm cho chúng có ý nghĩa và phù hợp với người dùng doanh nghiệp .

• Sử dụng những cái tên có ý nghĩa giúp truyền đạt ngữ cảnh cho người dùng doanh nghiệp
• Danh từ số ít, tất cả các từ viết thường được phân tách bằng dấu gạch dưới (để giúp tăng tốc độ nhập và tránh sai lầm nếu bạn đang xử lý MySQL phân biệt chữ hoa chữ thường)
• Tránh các ký tự đặc biệt (bao gồm khoảng cách) và các từ dành riêng cho cơ sở dữ liệu
• Sử dụng các từ đầy đủ – không viết tắt trừ khi chúng cần thiết và được người dùng doanh nghiệp sử dụng thường xuyên
• Tránh để cột và bảng trùng tên (để tránh nhầm lẫn khi viết truy vấn)
• Khóa chính của cột số ít: id
• Khóa ngoại một cột: <referenced_table> _id

3. Trước khi chuẩn hóa, hãy hiểu cơ sở dữ liệu của bạn đang được xây dựng để làm gì

Chuẩn hóa được coi là một trong những phương pháp thiết kế tốt nhất cần tuân thủ. Nhưng nó có đúng mọi lúc không? Vâng, hãy suy nghĩ lại.

Mọi người không xây dựng cơ sở dữ liệu vì lợi ích của việc chúng tồn tại biệt lập. Cơ sở dữ liệu được xây dựng để thu thập và xử lý dữ liệu cho một ứng dụng cụ thể. Để chuẩn hóa hay không phụ thuộc vào việc ứng dụng có mang tính giao dịch và phân tích hay không.

Cơ sở dữ liệu được xây dựng để hỗ trợ ứng dụng giao dịch cần đảm bảo dữ liệu không có sự mâu thuẫn logic trong quá trình chèn, cập nhật và xóa. Ví dụ, một nhân viên bình thường có mức lương cố định theo giờ. Bình thường hóa (tức là tách hồ sơ lương hàng tháng và tỷ lệ trả lương thành 2 bảng riêng biệt) loại bỏ sự cần thiết của kế toán nhập tỷ lệ giờ của nhân viên bình thường hàng tháng. Ít thứ cần nhập hơn có nghĩa là ít sai sót của con người hơn, điều này cuối cùng chuyển thành dữ liệu nhất quán và chính xác hơn.

Cơ sở dữ liệu được xây dựng để hỗ trợ ứng dụng phân tích cần tạo các tổng hợp và tính toán trên nhiều bảng càng nhanh càng tốt. Nhưng mỗi lần tham gia giữa 2 bảng cần có thời gian. Và đó không phải là một nhiệm vụ thú vị khi chúng ta phải xử lý hàng triệu bản ghi giao dịch cùng một lúc. Do đó, chúng tôi phải giảm thiểu số lượng liên kết cần thiết để truy vấn dữ liệu của chúng tôi, có nghĩa là chuẩn hóa không còn là một ý tưởng hay nữa trong trường hợp này.

Vì vậy, bây giờ chúng ta biết chuẩn hóa là hoàn hảo cho các ứng dụng giao dịch, nhưng nó có thể là một cơn ác mộng khi thiết kế cơ sở dữ liệu cho các ứng dụng phân tích . Nhưng làm thế nào để bạn biết cái nào từ cái nào? Dưới đây là một so sánh nhanh để hướng dẫn bạn cùng.

4. Ôm khóa chính tự nhiên

Cơ sở dữ liệu GV: Mỗi bảng quan hệ cần có khóa chính để tránh các bản ghi bị trùng lặp.

Ai đó đã nói trên một trang web: Cách tốt nhất là sử dụng trường số nguyên tự động tăng dần cho khóa chính.

Tôi không hiểu: Được rồi, tôi nên tạo một trường số nguyên tự động tăng dần có tên “id” để làm khóa chính cho mọi bảng quan hệ.

Giờ thú tội! Đây là một sự hiểu lầm tôi từng có cho đến khi Bill Karwin sửa chữa cho tôi thông qua cuốn sách tuyệt vời của ông có tên là Phản vật chất SQL . Kiểm tra cuốn sách đó. Đó là một trong những cuốn sách SQL tuyệt vời nhất hiện có. Trong khi đó, đây là lời giải thích tóm tắt của tôi về điểm cụ thể này để bạn không mắc phải sai lầm tương tự nữa.

Một khóa chính tồn tại để thể hiện một ràng buộc rất quan trọng: Mỗi hàng trong cơ sở dữ liệu quan hệ phải là duy nhất . Bất kỳ mục nhập nào có cùng khóa chính đều bị trùng lặp và sẽ bị ngăn vào cơ sở dữ liệu. Không trùng lặp có nghĩa là không tính hai lần khi báo cáo các số liệu kinh doanh như tổng số khách hàng thực, doanh số hàng tháng, chi phí đào tạo nhân viên, v.v.

Bảng trên ghi lại mối quan hệ giữa bài viết và thẻ. Ví dụ: bài viết này có thể có nhiều thẻ được liên kết như thiết kế cơ sở dữ liệu, khóa chính, SQL. Nhưng sự kết hợp giữa “article_id” và “tag_id” xác định một hàng duy nhất trong bảng này. Cột “id” ở đây là khóa chính tự động tăng. Nhưng nó có ngăn các bản sao xâm nhập vào cơ sở dữ liệu không? Không, nó không.

Được rồi, làm thế nào về việc xác định ràng buộc DUY NHẤT để kiểm tra xem sự kết hợp giữa “article_id” và “tag_id” có phải là duy nhất trước khi chèn một hàng mới không? Vâng, điều đó có thể. Nhưng tại sao chúng ta phải sử dụng cột “id” tự động tăng ngay từ đầu?

Điều này đưa chúng ta đến một nguyên tắc quan trọng: Nếu tồn tại một cột hoặc kết hợp các cột có thể xác định một bản ghi duy nhất dựa trên thứ tự kinh doanh tự nhiên và đáp ứng các điều kiện danh sách dưới đây, hãy xem xét sử dụng nó làm khóa chính . Cách này hoạt động tốt hơn cách mù quáng tạo một cột “id” số nguyên tăng tự động khác (ví dụ: khóa thay thế, GUID) chỉ vì ai đó đã nói như vậy ở đâu đó.

• Duy nhất và không rỗng
• Hỗ trợ lập chỉ mục
• Không có khả năng bị trùng lặp
• Không có khả năng được cập nhật thường xuyên
• Nhỏ gọn và chứa ít cột nhất có thể

5. Tạo bảng và cột với ý nghĩ tối giản

Đừng nhân rộng các thực thể vượt quá mức cần thiết.

Đó là khẩu hiệu nổi tiếng được gọi là “Ockham’s Razor” do William of Ockham , một trong những nhà triết học lỗi lạc nhất trong thời kỳ Trung Cổ. Trong ngữ cảnh cơ sở dữ liệu, chúng ta có thể hiểu nó như sau: không tạo thêm bảng hoặc cột nếu điều đó không cần thiết.

Hãy nhớ rằng cơ sở dữ liệu càng có nhiều bảng và cột thì việc bảo trì càng phức tạp và tốn kém. Vì vậy, nếu bạn không đạt được bất kỳ lợi thế nghiêm trọng nào ngoài việc làm cho cuộc sống của bạn khó khăn hơn một chút, tại sao phải bận tâm?

Nhưng sau khi cân nhắc cả chi phí và lợi ích, nếu phán quyết tuyên bố rằng bạn thực sự cần tạo thêm bảng hoặc cột, thì đây là một số gợi ý hợp lệ.

• Để lưu trữ các thuộc tính nhiều giá trị (ví dụ: nhiều số điện thoại của khách hàng, nhiều thẻ cho một bài viết, nhiều cách sử dụng cho một mặt hàng): Thay vì liên tục thêm ngày càng nhiều cột trên cùng một bảng, hãy tạo một bảng phụ thuộc để lưu trữ nhiều giá trị trong nhiều hàng .
• Để chia bảng thành nhiều bảng nếu kích thước bảng làm chậm hiệu suất: Thay vì chia bảng theo cách thủ công, hãy xem xét phân vùng ngang để tách các phần hàng thành các phần riêng lẻ. Khi làm như vậy, bảng của bạn được tách về mặt kỹ thuật để cải thiện hiệu suất nhưng vẫn xuất hiện dưới dạng một bảng duy nhất để người dùng cuối dễ dàng truy vấn.
• Để cho phép những người dùng khác nhau xem các phần khác nhau của bảng dựa trên quyền truy cập của họ : Thay vì tạo các bảng riêng biệt cho các quyền truy cập khác nhau, hãy cân nhắc tạo chế độ xem nếu dữ liệu thường xuyên thay đổi. Tuy nhiên, nếu dữ liệu không thay đổi thường xuyên, hãy chọn chế độ xem cụ thể hóa để có hiệu suất tốt hơn vì kết quả của truy vấn được lưu trữ dễ dàng trong đĩa.
• Để lưu trữ tệp, mp3 hoặc các đoạn văn bản dài : Thay vì tạo các cột BLOB hoặc TEXT trên cùng một bảng có các giá trị giao dịch đơn giản khác (ví dụ: số nguyên, chuỗi có độ dài giới hạn), hãy tạo một bảng phụ thuộc riêng biệt được tham chiếu đến các bản ghi gốc thông qua ngoại hạn chế chính .

6. Tận dụng cơ sở dữ liệu để thực thi tính toàn vẹn tham chiếu

Nhìn bề ngoài, việc thực thi tính toàn vẹn tham chiếu thông qua các ràng buộc khóa ngoại có vẻ rắc rối vì chúng có thể xung đột với dữ liệu được di chuyển từ hệ thống khác. Cùng với ngày hoạt động sắp tới, cơ sở dữ liệu thường được coi là vị trí kết xuất dữ liệu. Và bạn đã nghe ai đó gợi ý, “Hãy giữ cho cơ sở dữ liệu đơn giản và để ứng dụng xử lý các quy tắc xác thực.” Một vài người đã gật đầu và tất cả các quy tắc xác thực để đảm bảo tất cả các giá trị khóa ngoại tham chiếu đến khóa chính hợp lệ, hiện có trong bảng mẹ đều được tích hợp vào ứng dụng.

Vậy điều đó có gì sai? Để tôi cho bạn một phép loại suy. Để lau nhà, chúng ta có hai lựa chọn là chổi và máy hút bụi. Bạn sẽ đi cho cái nào? Bạn có thể chọn lấy chổi để lau nhà, vì nghĩ rằng nó sẽ loại bỏ bụi bẩn như làm sạch máy hút bụi. Vì vậy, bạn đã dành 20 phút để làm như vậy trong khi tất cả những gì bạn cần là 5 phút với máy hút bụi. Và tôi dám cá rằng một số bụi sẽ vẫn còn dưới thảm hoặc ở một số góc sau tất cả các công việc khó khăn. Khi chúng ta từ chối để cơ sở dữ liệu làm những gì chúng làm tốt nhất, đó là thực hiện tính toàn vẹn tham chiếu, chúng ta sẽ khiến mọi thứ kém hiệu quả hơn và có thể không bao giờ đạt được chính xác những gì chúng ta muốn.

Và đừng quên các ứng dụng được triển khai, sau đó được nâng cấp hoặc thay thế, trong khi cùng một dữ liệu có xu hướng tồn tại lâu dài với doanh nghiệp (không phải như vậy)! Chúng ta có thể đủ khả năng xây dựng và xây dựng lại các quy tắc xác thực giống nhau trong tất cả các loại ứng dụng bao nhiêu lần?

Tất nhiên, có những cơ sở dữ liệu không hỗ trợ các ràng buộc khóa ngoại như công cụ lưu trữ MyISAM của MySQL. Thật không may, chúng tôi không có sự lựa chọn trong trường hợp như vậy. Nhưng nếu cơ sở dữ liệu có thể hỗ trợ các ràng buộc khóa ngoại, thì hãy để nó xử lý những gì nó hoạt động tốt nhất. Điều này sẽ giúp chúng tôi tiết kiệm thời gian và nỗ lực để thực hiện mã hóa bổ sung để kiểm tra tính toàn vẹn của tham chiếu . Càng ít mã phải viết trong ứng dụng của chúng tôi, càng ít lỗi cần sửa và việc duy trì toàn bộ giải pháp càng đơn giản. Ai lại không thích tình huống đôi bên cùng có lợi?

7. Sử dụng mô hình dữ liệu để xác nhận hiểu biết của bạn

Giả sử bạn đã tạo bản nháp đầu tiên của các mô hình dữ liệu hoặc bạn đã không đếm được số lần bạn đã thực hiện các thay đổi đối với nó, nhưng làm thế nào bạn biết liệu bạn đã bao gồm tất cả mọi thứ chưa? Chà, bản thân mô hình dữ liệu có thể cung cấp cho bạn rất nhiều manh mối. Điều duy nhất chúng ta phải làm là bắt đầu xem xét mô hình và đặt đủ loại câu hỏi về các thực thể và mối quan hệ.

Nhưng bạn nên hỏi những câu hỏi nào? Hãy để tôi chia sẻ với bạn một số câu hỏi mà tôi thường suy ngẫm khi sử dụng mô hình dữ liệu để tìm hiểu và xem xét công việc của mình.

Ở phần đầu của bài đăng này, tôi đã nhấn mạnh tầm quan trọng của việc hiểu vấn đề trước khi bắt đầu. Nhưng việc tìm hiểu về vấn đề này không dừng lại khi chúng tôi đã đưa ra mô hình dữ liệu bởi vì bản nháp đầu tiên sẽ không bao giờ hoàn hảo. Do đó, tôi đề nghị bất kỳ ai đang thiết kế cơ sở dữ liệu bắt đầu xem xét mô hình và đặt nhiều câu hỏi. Câu trả lời cho những câu hỏi này có thể dẫn đến bất cứ điều gì giữa những thay đổi nhỏ và một cuộc đại tu lớn đối với mô hình dữ liệu, nhưng đừng băn khoăn. Hãy nắm bắt những thay đổi và quá trình lặp đi lặp lại. Tôi hứa bạn có thể chinh phục nó và bạn sẽ xuất hiện từ đầu bên kia với sự duyên dáng, kiến ​​thức và ý thức mục đích mạnh mẽ hơn để thực hiện một giải pháp mà ít hối tiếc và khuôn mặt cau có hơn.

8. Đừng đọc lướt tài liệu

Ah, tài liệu hóa, công việc được cho là nhàm chán và tốn thời gian nhất trong năm! Chà, đã viết vô số tài liệu dự án, tôi hiểu bạn đến từ đâu. Nhưng hãy để tôi chia sẻ cách tôi xoay sở để đẩy lùi lời bào chữa của mình.

• Bây giờ tôi không có thời gian cho tài liệu. Errr, vậy sau này tôi có thời gian ngồi lại nhiều cuộc họp với nhóm để truyền đạt cách tạo cơ sở dữ liệu trong quá trình triển khai không?
• Nhóm của chúng tôi đã làm việc rất chặt chẽ với nhau. Đồng đội của tôi biết chính xác những gì tôi đang làm. À vâng, nhưng họ có thể đọc được suy nghĩ của tôi và hiểu chính xác lý do tại sao tôi đã làm những gì tôi đã làm không? Và họ không có những thách thức riêng để ghi nhớ và ưu tiên sao?
• Tôi luôn sẵn sàng hỏi đáp nếu ai đó cần biết điều gì đó về thiết kế. Nhưng tôi có thể chắc chắn nhớ mọi chi tiết, đặc biệt là khi các thay đổi được thực hiện liên tục trong suốt quá trình thiết kế? Tôi biết rất rõ rằng tôi không thể.
• Thiết kế là tiêu chuẩn và tự giải thích. Có thật không? Tôi đã thử yêu cầu ai đó hiểu nó một mình chưa? Ý thức của tôi về dịch vụ giá trị gia tăng và lòng tốt với người khác ở đâu?

Nhưng những gì nên được ghi lại? Với những hạn chế về thời gian và chi phí, việc ghi lại nhật ký thiết kế của chúng tôi là không thực tế. Vì vậy, dưới đây là những gì bạn có thể muốn đưa vào kho lưu trữ thiết kế cơ sở dữ liệu.

1. Sơ đồ thực thể-mối quan hệ hiển thị các bảng, cột và mối quan hệ cuối cùng
2. Định nghĩa / Ý nghĩa của từng cột dữ liệu
3. Đặc tả quy tắc nghiệp vụ được ánh xạ tới các ràng buộc cơ sở dữ liệu và / hoặc các trình kích hoạt được triển khai
4. Xem sơ đồ và thông số kỹ thuật
5. Ghi chú được biên soạn cho các quyết định được đưa ra trong quá trình thiết kế
6. Các mẫu dữ liệu được thu thập trong quá trình phân tích

Kết thúc

Đừng quên điều ác là trong các chi tiết khi thiết kế cơ sở dữ liệu ngay cả đơn giản nhất. Hoàn toàn không sao khi cảm thấy thất vọng sau khi thực hiện nhiều thay đổi. Nhưng hãy nhớ rằng bạn đang giúp một người hoặc nhiều người giải quyết một vấn đề quan trọng. Và nếu bạn đã được chọn để làm công việc đó, tôi chắc chắn rằng bạn có trong mình điều đó để biến nó thành hiện thực.

Tôi chân thành hy vọng bạn đã thích đọc bài đăng trên blog cũng như tôi thích nghiên cứu và viết về chủ đề này. Cho đến thời điểm tiếp theo!