Mô hình dữ liệu trông rất gọn gàng trên bảng trắng. Các thực thể được kết nối mạch lạc. Các mối quan hệ hợp lý. Các dạng chuẩn có vẻ logic. Mọi thứ dường như có thể kiểm soát được, dự đoán được và gần như thanh lịch.
Sau đó, bạn sẽ bắt tay vào một dự án thực tế.
Đột nhiên, các yêu cầu thay đổi giữa chừng trong chu kỳ phát triển phần mềm. Các định nghĩa kinh doanh không thống nhất. Các hệ thống nguồn mâu thuẫn nhau. Dữ liệu lịch sử hoạt động khác với dữ liệu hiện tại. Và mô hình “hoàn hảo” mà bạn thiết kế tuần trước bắt đầu gặp trục trặc trong quá trình sử dụng thực tế.
Đây là phần mà không ai cảnh báo bạn cả.
Mô hình hóa dữ liệu không khó vì lý thuyết.
Nó khó vì thực tế không tuân theo lý thuyết .
Và những bài học quan trọng nhất về mô hình hóa dữ liệu không đến từ sách vở, khóa học hay chứng chỉ. Chúng đến từ các sự cố trong quá trình vận hành, các bên liên quan khó chịu, các chỉ số khó hiểu và các bảng điều khiển không khớp dữ liệu.
Bài viết này nói về những bài học đó—những bài học mà bạn chỉ học được sau khi hoàn thành các dự án thực tế .
1. Hiểu biết về kinh doanh quan trọng hơn sự hoàn hảo về kỹ thuật.
Khi mới bắt đầu sự nghiệp, bạn thường có xu hướng tập trung vào cấu trúc:
khóa chính, khóa ngoại, cấp độ chuẩn hóa, lược đồ hình sao và lược đồ hình bông tuyết.
Nhưng trong các dự án thực tế, điều đầu tiên bị lỗi không phải là cấu trúc logic mà là ý nghĩa kinh doanh của nó .
Hai nhóm có thể sử dụng cùng một từ nhưng lại mang ý nghĩa khác nhau.
“Khách hàng,” “khách hàng hoạt động,” “doanh thu,” “đơn đặt hàng,” “tỷ lệ chuyển đổi” — tất cả đều nghe có vẻ hiển nhiên cho đến khi bạn hỏi năm người có liên quan và nhận được năm câu trả lời khác nhau.
Một mô hình hoàn hảo về mặt kỹ thuật được xây dựng trên những định nghĩa không rõ ràng sẽ thất bại một cách âm thầm và nhất quán.
Các dự án thực tế dạy bạn sự thật này:
Một mô hình hơi lộn xộn nhưng phản ánh thực tế kinh doanh có giá trị hơn một mô hình hoàn hảo nhưng không phản ánh thực tế.
Các mô hình dữ liệu tốt nhất được viết ra sao cho phù hợp với cả con người lẫn máy móc.
2. Chuẩn hóa không phải là mục tiêu—Mục tiêu là khả năng sử dụng.
Về lý thuyết, chuẩn hóa dường như là tiêu chuẩn vàng.
Giảm sự trùng lặp. Cải thiện tính nhất quán. Tránh các bất thường.
Trên thực tế, các mô hình được chuẩn hóa quá mức sẽ làm chậm tiến độ của các nhóm.
Các nhà phân tích phải vật lộn để kết hợp mười bảng dữ liệu chỉ để trả lời một câu hỏi đơn giản.
Bảng điều khiển trở nên dễ bị lỗi.
Các truy vấn trở nên phức tạp.
Hiệu suất bị ảnh hưởng.
Các dự án thực tế sẽ dạy bạn khi nào nên phá vỡ các quy tắc.
Bạn sẽ hiểu rằng việc phi chuẩn hóa không phải là một thất bại—mà thường là một quyết định thiết kế .
Bạn sẽ hiểu rằng sự lặp lại có thể chấp nhận được khi nó cải thiện sự rõ ràng và tốc độ.
Bạn sẽ hiểu rằng các mô hình phân tích phục vụ một mục đích khác với các mô hình giao dịch.
Mục tiêu không phải là sự thuần khiết về mặt học thuật.
Mục tiêu là làm cho dữ liệu dễ sử dụng, khó bị lạm dụng và truy vấn nhanh chóng .
3. Hệ thống nguồn phức tạp hơn nhiều so với những gì được ghi trong tài liệu.
Tài liệu hứa hẹn lược đồ dữ liệu rõ ràng.
Thực tế lại cho thấy dữ liệu không nhất quán.
Trong các dự án thực tế, bạn sẽ khám phá ra:
- Các ID có định dạng thay đổi theo thời gian
- Các trường có thể rỗng mà lẽ ra “không bao giờ được phép rỗng”.
- Các quy tắc kinh doanh được áp dụng khác nhau giữa các vùng.
- Những ghi chép lịch sử không phù hợp với logic hiện đại.
Bạn sẽ nhanh chóng nhận ra rằng các mô hình dữ liệu phải có tính phòng thủ .
Họ phải tính đến các giá trị bị thiếu, các tổ hợp không mong đợi, dữ liệu đến muộn và các chỉnh sửa diễn ra nhiều tuần sau đó.
Một mô hình dữ liệu tốt không giả định đầu vào hoàn hảo.
Nó dự đoán những đầu vào không hoàn hảo.
4. Thời gian là yếu tố bị đánh giá thấp nhất trong mô hình dữ liệu
Một trong những điều bất ngờ lớn nhất trong các dự án thực tế là thời gian trở nên phức tạp đến mức nào.
“Điều gì là đúng vào thời điểm đó?”
“Điều gì đã thay đổi, và khi nào nó thay đổi?”
“Chúng ta biết gì vào thời điểm đó?”
Việc thay đổi kích thước chậm, ngày hiệu lực, bảng ảnh chụp nhanh và dấu thời gian sự kiện, những khái niệm này nghe có vẻ lý thuyết cho đến khi một bên liên quan hỏi:
“Tại sao báo cáo này lại đưa ra số liệu khác nhau giữa quý trước và tháng trước?”
Đó là lúc bạn nhận ra:
Nếu mô hình của bạn không xử lý thời gian chính xác, niềm tin cuối cùng sẽ bị phá vỡ.
Các dự án thực tế dạy bạn cách thiết kế cho tương lai, chứ không chỉ cho hiện tại.
5. Mô hình dữ liệu là những hệ thống sống động, không phải là những thiết kế chỉ dùng một lần.
Trong các bài hướng dẫn, mô hình dữ liệu thường mang tính hoàn thiện.
Nhưng trong thực tế, chúng chỉ là tạm thời.
Tư duy kinh doanh phát triển.
Sản phẩm thay đổi.
Các chỉ số mới xuất hiện.
Những giả định cũ lỗi thời.
Nếu mô hình của bạn quá cứng nhắc, mọi thay đổi đều trở nên khó khăn.
Nếu nó linh hoạt, quá trình phát triển sẽ dễ quản lý hơn.
Các dự án thực tế sẽ dạy bạn:
- Thiết kế để mở rộng, không phải để đạt đến sự hoàn hảo.
- tránh ghép nối quá chặt
- Hãy đón nhận sự thay đổi, chứ đừng chống lại nó.
- các mô hình phiên bản khi cần thiết
- ghi lại các giả định một cách rõ ràng
Những mô hình dữ liệu tốt nhất không phải là những mô hình không bao giờ thay đổi.
Chúng là những mô hình thay đổi một cách khéo léo .
6. Các bên liên quan không suy nghĩ theo bảng biểu — họ suy nghĩ bằng câu hỏi.
Bài học này thường đến sau lần đầu tiên bạn thiết kế giao diện thất bại.
Bạn đã mô hình hóa dữ liệu rất tuyệt vời.
Mọi thứ đều đúng về mặt logic.
Nhưng người dùng vẫn yêu cầu xuất dữ liệu, truy vấn tùy chỉnh và “thêm một cột nữa”.
Tại sao?
Bởi vì con người không suy nghĩ theo sơ đồ.
Họ suy nghĩ bằng câu hỏi.
“Tháng trước có bao nhiêu khách hàng bỏ đi?”
“Sản phẩm nào đang hoạt động kém hiệu quả?”
“Tại sao doanh thu giảm ở đây mà không giảm ở đó?”
Các dự án thực tế dạy bạn rằng một mô hình dữ liệu tốt phải dự đoán được cách thức đặt câu hỏi , chứ không chỉ cách dữ liệu được lưu trữ.
Nếu một mô hình liên tục buộc mọi người phải suy nghĩ quá nhiều, nó sẽ không đạt được mục đích của mình.
7. Mô hình hóa dữ liệu cũng quan trọng như kỹ thuật trong giao tiếp
Một trong những nhận thức thầm lặng đến từ kinh nghiệm là:
Hầu hết các vấn đề về mô hình hóa dữ liệu không phải là vấn đề kỹ thuật.
Có những vấn đề về giao tiếp.
Kỳ vọng không phù hợp.
Định nghĩa không rõ ràng.
Giả định chưa từng được kiểm chứng.
Quyết định được đưa ra mà không có bối cảnh.
Các dự án thực tế dạy bạn phải chậm lại và đặt câu hỏi:
“Mọi người có đang sử dụng thuật ngữ này theo cùng một cách không?”
“Chỉ số này có cùng ý nghĩa giữa các nhóm không?”
“Chúng ta đang mô phỏng thực tế hay chỉ là sự tiện lợi?”
Những người giỏi nhất trong việc xây dựng mô hình dữ liệu không phải là những người viết nhiều mã SQL nhất.
Họ là những người biết cách thu hẹp khoảng cách giữa bộ phận kinh doanh và bộ phận kỹ thuật .
8. Các yếu tố về hiệu năng thay đổi mọi thứ.
Một mô hình hoạt động với một triệu hàng sẽ có cách thức hoạt động rất khác khi xử lý một tỷ hàng.
Các dự án thực tế đưa ra những ràng buộc về hiệu năng mà lý thuyết hiếm khi đề cập sâu sắc.
Mô hình truy vấn rất quan trọng.
Chiến lược phân vùng rất quan trọng.
Lập chỉ mục rất quan trọng.
Định dạng lưu trữ rất quan trọng.
Bạn sẽ học được rằng:
- Một số phép nối quá tốn kém khi thực hiện ở quy mô lớn.
- một số phép tính thuộc về thượng nguồn
- Một số chiều cần được tổng hợp trước.
- một số mô hình cần các lớp phân tích riêng biệt.
Mô hình hóa dữ liệu sẽ không còn mang tính trừu tượng nữa khi khối lượng dữ liệu thực tế xuất hiện.
9. Không có mô hình nào là “đúng duy nhất”—chỉ có sự đánh đổi.
Đây là bài học quan trọng nhất.
Trong các dự án thực tế, mọi quyết định về mô hình đều là sự thỏa hiệp.
Đơn giản so với tính linh hoạt;
Hiệu năng so với độ chính xác;
Dung lượng lưu trữ so với tốc độ;
Chuẩn hóa so với khả năng sử dụng.
Không có câu trả lời đúng duy nhất cho tất cả mọi trường hợp.
Điều quan trọng là phải đưa ra những sự đánh đổi có ý thức , ghi chép lại chúng và xem xét lại khi điều kiện thay đổi.
Kinh nghiệm dạy cho bạn sự khiêm nhường.
Bạn ngừng theo đuổi sự hoàn hảo và bắt đầu theo đuổi sự rõ ràng và sự hài hòa .
10. Mô hình dữ liệu tốt tạo dựng niềm tin—Mô hình dữ liệu tồi âm thầm phá hủy niềm tin đó.
Khi mô hình dữ liệu mạnh mẽ, mọi người tin tưởng vào các con số mà không cần nghi ngờ.
Quyết định được đưa ra nhanh hơn.
Các cuộc họp tập trung vào hành động, chứ không phải giải thích.
Khi mô hình dữ liệu yếu, niềm tin sẽ bị xói mòn dần dần.
Các con số bị đặt câu hỏi.
Các báo cáo được kiểm tra lại hai lần.
Mọi người dựa vào bảng tính thay vì các hệ thống.
Các dự án thực tế dạy bạn rằng mô hình hóa dữ liệu không chỉ là cơ sở hạ tầng kỹ thuật.
Nó còn là cơ sở hạ tầng tổ chức .
Nó định hình mức độ tự tin mà một công ty thể hiện khi hành động.
Kinh nghiệm cuối cùng sẽ dạy bạn điều gì?
Sau khi hoàn thành đủ các dự án thực tế, tư duy của bạn sẽ thay đổi.
Bạn đừng hỏi nữa:
“Làm thế nào để thiết kế một mô hình hoàn hảo?”
Và hãy bắt đầu bằng câu hỏi:
“Làm thế nào để thiết kế mô hình hữu ích, bền vững và dễ hiểu nhất cho doanh nghiệp này ?”
Bạn sẽ học được rằng:
- Lý thuyết là điểm khởi đầu, không phải là đích đến.
- Sự rõ ràng vượt trội hơn sự thông minh.
- Tính linh hoạt vượt trội hơn tính cứng nhắc.
- Giao tiếp hiệu quả hơn sự phức tạp.
Việc mô hình hóa dữ liệu ngày càng ít tập trung vào sơ đồ và nhiều hơn vào khả năng phán đoán.
Lời suy ngẫm cuối cùng
Sách dạy bạn cách thức mô hình hóa dữ liệu nên hoạt động như thế nào.
Các dự án thực tế dạy bạn cách nó hoạt động trong thực tế.
Và chính khoảng cách giữa lý thuyết và thực tế đó là nơi mà chuyên môn thực sự được hình thành.
Nếu bạn từng phải thiết kế lại mô hình sau khi đã đưa vào sử dụng, phải giải thích các chỉ số đến lần thứ mười, hoặc phải sửa chữa những điểm không nhất quán do các giả định ban đầu gây ra, thì bạn không hề thất bại.
Bạn đang tìm hiểu sự thật về mô hình hóa dữ liệu.
Và sự thật đó chỉ được hé lộ sau khi các dự án thực tế được triển khai .
Bài viết liên quan: