Một khách hàng muốn thêm một trường (field) mới vào form đơn hàng — cờ "mức độ ưu tiên", hay một mã tham chiếu phụ, đại loại vậy. Nghe có vẻ là việc năm phút: thêm một ô nhập liệu, một dropdown. Người phụ trách ERP hứa "được, tuần này xong", rồi ước tính đó âm thầm trượt thành cả tháng kiểm thử và sửa lỗi mà chẳng ai yêu cầu. Đây không phải do làm ẩu. Nó xảy ra vì "hệ thống ERP" chưa bao giờ là một khối phẳng — nó là ba tầng xếp chồng lên nhau, và một thay đổi tưởng chỉ là một cú click ở tầng trên cùng có thể buộc phải sửa ở mọi tầng bên dưới.
Ba tầng, không phải một hệ thống
Kiến trúc cơ sở dữ liệu theo mô hình ANSI/SPARC chia bất kỳ hệ thống nào — kể cả ERP của xưởng sản xuất — thành ba tầng:
- Tầng ngoài (external layer) — các khung nhìn (views) và form mà một người dùng hay một ứng dụng cụ thể thực sự nhìn thấy: màn hình nhập đơn hàng, báo cáo hóa đơn, dashboard mà quản lý xưởng sản xuất xem mỗi sáng.
- Tầng khái niệm (conceptual layer) — lược đồ logic (logical schema): toàn bộ mô hình dữ liệu gồm thực thể, quan hệ và ràng buộc mô tả nghiệp vụ (khách hàng, đơn hàng, vật tư, tồn kho), độc lập với bất kỳ màn hình riêng lẻ nào.
- Tầng vật lý (internal layer) — lược đồ vật lý (physical schema): dữ liệu thực sự được lưu trên đĩa như thế nào, file nào, index nào, cách bố trí block mà bộ máy cơ sở dữ liệu dùng để truy vấn cho nhanh.
Vì sao ba tầng phải thay đổi được độc lập với nhau
Lý do người ta tách hệ thống thành ba tầng như vậy là để mỗi tầng có thể thay đổi mà không buộc phải viết lại các tầng còn lại. Đây gọi là tính độc lập dữ liệu (data independence), và có hai loại:
- Tính độc lập logic (logical data independence) nghĩa là có thể sửa lược đồ khái niệm — thêm một trường, tách một bảng, siết một ràng buộc — mà không làm hỏng các form và ứng dụng đang chạy phía trên, miễn là ánh xạ giữa lược đồ logic và các khung nhìn đó được điều chỉnh theo.
- Tính độc lập vật lý (physical data independence) nghĩa là có thể thay đổi cách lưu trữ dữ liệu — thêm index, tổ chức lại file, chuyển sang ổ lưu trữ nhanh hơn — mà hoàn toàn không đụng đến lược đồ logic hay các ứng dụng phía trên.
Chỗ mà "chỉ thêm 1 field" thực sự vỡ trận
Trong một hệ thống được xây tốt, trường "mức độ ưu tiên" thêm vào form đơn hàng chính xác là loại thay đổi mà tính độc lập dữ liệu sinh ra để xử lý: thêm vào lược đồ logic, chỉnh lại ánh xạ, phần còn lại của ERP vẫn chạy bình thường. Trên thực tế, mọi thứ chỉ diễn ra gọn gàng như vậy khi ba tầng thực sự được tách bạch ngay từ đầu. Một trường nhỏ kéo theo việc viết lại truy vấn, kiểm thử lại báo cáo, và đánh lại chỉ mục toàn bộ cơ sở dữ liệu khi:
- Màn hình đơn hàng được xây bằng những đường tắt giả định đúng hình dạng của bảng dữ liệu bên dưới.
- Các báo cáo khác đã tham chiếu thẳng vào bảng đó.
- Tầng lưu trữ vật lý chưa từng được thiết kế để nhận thêm trường mà không cần dựng lại index.
Chỉ cần một trong ba điều đó xảy ra, một yêu cầu năm phút biến thành ước tính một tháng — lý do được giải thích.
Điều thực tế xưởng sản xuất cần rút ra không phải là phải học lý thuyết cơ sở dữ liệu cho hoàn hảo. Mà là, trước khi yêu cầu "chỉ thêm 1 field" tiếp theo được gửi tới người đang giữ hệ thống ERP, hãy hỏi: thay đổi này chỉ chạm vào một màn hình, hay chạm vào mô hình dữ liệu chung mà mọi màn hình khác đang phụ thuộc vào? Nếu không ai trong xưởng sản xuất trả lời được câu hỏi đó một cách chắc chắn, thì chính sự không chắc chắn đó — chứ không phải bản thân cái field — mới là chi phí thật đang nằm trong hệ thống.
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ả →