Hầu hết xưởng sản xuất bắt đầu bằng Excel. Rồi ai đó thêm một file thứ hai để theo dõi tồn kho, một thư mục chia sẻ cho xác nhận đơn hàng, một file thứ ba cho danh sách nhà cung cấp. Mọi thứ ổn trong một thời gian. Rồi xưởng sản xuất lớn lên — nhiều đơn hàng hơn, nhiều người cùng động vào một con số — và chính hệ thống file từng đơn giản ấy bắt đầu cho ra số liệu sai, trả lời chậm, và những lỗi không ai truy được về nguồn gốc. Đây không phải xui rủi. Đây là giới hạn cấu trúc của cách quản lý dữ liệu bằng file thô, và trong lý thuyết cơ sở dữ liệu nó có tên gọi hẳn hoi: bốn nhược điểm kinh điển của hệ thống file so với một hệ quản trị cơ sở dữ liệu (DBMS) thật sự.
1. Một sự thật nằm ở năm nơi, và chúng không khớp nhau
Khi địa chỉ khách hàng hay mã hàng chỉ nằm ở một file, cập nhật rất đơn giản. Nhưng khi nó được chép sang một file bán hàng, một file sản xuất, một mẫu hóa đơn — vì ba người khác nhau cần dùng — thì cập nhật nghĩa là phải tìm và sửa ở mọi nơi cùng lúc, và luôn có một bản bị bỏ sót. Đây là dư thừa và mất nhất quán dữ liệu (redundancy and inconsistency): cùng một thông tin bị nhân bản qua nhiều file, rồi lệch dần theo thời gian đến mức không ai biết bản nào đúng.
2. Mỗi câu hỏi mới cần một chương trình mới
Một bảng tính chỉ trả lời được những câu hỏi nó được thiết kế sẵn để trả lời. Ngay khi có ai hỏi điều gì đó ngoài dự tính — "đơn hàng nào giao trễ tháng trước, theo từng khách hàng" — thì không có cách nào chung để hỏi. Ai đó phải mở file thô ra và viết logic mới cho đúng cấu trúc riêng của nó. Đây là vấn đề khó truy xuất dữ liệu (difficult data access): không có lớp truy vấn, mỗi câu hỏi mới trở thành một dự án phát triển nhỏ thay vì một câu hỏi đơn thuần.
3. Dữ liệu vốn thuộc về nhau lại nằm tách biệt
Đơn hàng, tồn kho, dữ liệu sản xuất thường nằm ở các file riêng, định dạng không tương thích nhau, do những người khác nhau quản lý. Dù một lô hàng giao trễ, một đợt thiếu nguyên liệu, và một sự chậm trễ sản xuất thực ra là cùng một chuỗi sự kiện, dữ liệu mô tả chúng lại bị cô lập ở những nơi khác nhau nên không ai nối chúng lại dễ dàng. Đây là cô lập dữ liệu (data isolation) — và đó là lý do nhiều xưởng sản xuất trả lời một câu hỏi liên phòng ban đơn giản bằng cách hỏi ba người rồi đối chiếu, thay vì tra cứu.
4. Quy tắc chỉ tồn tại ở nơi có người nhớ thực thi nó
Một quy tắc như "tồn kho không được âm" hay "đơn hàng phải gắn với một khách hàng có thật" chỉ đáng tin cậy đúng bằng mức độ mọi chương trình và mọi người từng động vào file có tuân thủ nó hay không. Trong hệ thống file thô, quy tắc này phải được cài lại ở từng nơi cần đến, và rất dễ bị vi phạm một cách âm thầm — một lỗi gõ, một bước kiểm tra bị bỏ qua, một file Excel mới quên mất quy tắc từ đầu. Đây là vấn đề toàn vẹn dữ liệu (integrity problems): không có một điểm trung tâm thực thi ràng buộc, dữ liệu sai lọt vào âm thầm và chỉ bị phát hiện khi nó gây ra hậu quả rõ ràng.
Không vấn đề nào trong bốn vấn đề trên được giải quyết bằng cách "cẩn thận hơn" hay thuê người dọn bảng tính gọn gàng hơn — chúng chỉ được giải quyết khi dữ liệu chuyển vào một hệ thống được xây để ngăn chặn cả bốn vấn đề này về mặt cấu trúc: một cơ sở dữ liệu dùng chung, quản lý tập trung, có một lớp truy vấn và các ràng buộc được thực thi — đó chính xác là điều một DBMS được thiết kế để làm. Nếu số liệu của xưởng sản xuất bạn đã bắt đầu khác nhau tùy vào việc ai mở file nào, đó không phải là vấn đề kỷ luật làm việc. Đó là dấu hiệu dữ liệu đã lớn vượt quá hệ thống file đang chứa nó.
Nguyễn Hải Minh
Tôi làm việc trong ngành CNTT tại Đức — trực tiếp viết phần mềm và xử lý dữ liệu hệ thống ERP (như INFOR) cho các nhà máy sản xuất của Đức. Về học vấn, tôi có bằng Cử nhân Kỹ thuật CNTT và bằng Kỹ thuật viên Điện tử Thông tin cấp nhà nước tại Đức. Tất cả những nền tảng đó giúp tôi rèn luyện một tư duy hệ thống vững vàng để làm tự động hóa và tối ưu vận hành chuẩn chỉ.
Tìm hiểu thêm về tác giả →