Hướng dẫn thiết kế để truy vấn và phân tích kho dữ liệu nhân viên
Trong lĩnh vực kinh doanh thiết kế trung tâm dữ liệu, rất dễ bị ru ngủ vào một loại “sự tự mãn cộng thêm”, nơi mọi nguồn kho dữ liệu đều giống như doanh số bán lẻ. Trong thế giới bán lẻ đơn giản, tất cả các giao dịch đều là những phần nhỏ của doanh thu luôn cộng lại trên tất cả các thứ nguyên và bản thân các thứ nguyên là những thứ hữu hình, vật chất như Sản phẩm, Cửa hàng và Ngày.
Tôi thường xuyên được hỏi, “Chà, những thứ như nguồn nhân lực thì sao? Hầu hết các dữ kiện đều không phải là phép cộng. Hầu hết các dữ kiện không phải là số chẵn, nhưng rõ ràng chúng luôn thay đổi, chẳng hạn như các dữ kiện số. Làm thế nào để tôi lập mô hình đó?” Trên thực tế, mart dữ liệu nguồn nhân lực là một ứng dụng rất tốt cho mô hình chiều. Với một thiết kế duy nhất, chúng tôi có thể giải quyết tất cả các nhu cầu phân tích và báo cáo chính. Chúng ta chỉ phải cẩn thận về thứ nguyên là gì và thực tế là gì.
Để định hình vấn đề, hãy mô tả một môi trường nguồn nhân lực điển hình. Chúng tôi giả định rằng chúng tôi là bộ phận nhân sự của một doanh nghiệp lớn với hơn 100.000 nhân viên. Mỗi nhân viên có một hồ sơ nguồn nhân lực phức tạp với ít nhất 100 thuộc tính. Các thuộc tính này bao gồm tất cả các mô tả nguồn nhân lực tiêu chuẩn bao gồm ngày thuê, cấp bậc công việc, mức lương, ngày đánh giá, kết quả đánh giá, quyền được hưởng kỳ nghỉ, tổ chức, giáo dục, địa chỉ, gói bảo hiểm và nhiều thứ khác. Trong tổ chức lớn của chúng tôi, có một luồng giao dịch liên tục đối với dữ liệu nhân viên này. Nhân viên liên tục được thuê, thuyên chuyển, thăng chức và được điều chỉnh hồ sơ của họ theo nhiều cách khác nhau.
Trong thiết kế của chúng tôi
Chúng tôi sẽ giải quyết ba loại truy vấn cơ bản chạy trên dữ liệu nguồn nhân lực phức tạp này. Trong loại truy vấn đầu tiên, chúng tôi muốn báo cáo trạng thái tóm tắt của toàn bộ nhân viên một cách thường xuyên (hàng tháng). Trong các bản tóm tắt này, chúng tôi muốn số lượng, tổng tức thời và tổng tích lũy, bao gồm những thứ như số lượng nhân viên, tổng tiền lương được trả trong tháng, mức lương tích lũy được trả trong năm nay, tổng số ngày nghỉ phép cộng dồn và số ngày nghỉ phép đã tích lũy, số lượng nhân viên mới , và số lượng khuyến mãi. Hệ thống báo cáo của chúng tôi cần phải cực kỳ linh hoạt và chính xác. Chúng tôi muốn các loại báo cáo này cho tất cả các phần có thể có của dữ liệu, bao gồm phần thời gian, phần tổ chức, phần địa lý và bất kỳ phần nào khác được hỗ trợ trong dữ liệu. Hãy nhớ nguyên lý cơ bản của mô hình chiều: Nếu bạn muốn có thể phân chia dữ liệu của mình dọc theo một thuộc tính cụ thể, bạn chỉ cần làm cho thuộc tính đó xuất hiện trong bảng thứ nguyên. Bằng cách sử dụng thuộc tính làm tiêu đề hàng (với SQL) bạn tự động “cắt”. Chúng tôi yêu cầu cơ sở dữ liệu này hỗ trợ hàng trăm kết hợp cắt lát khác nhau.
Thách thức báo cáo ẩn trong loại truy vấn đầu tiên này là đảm bảo rằng chúng tôi chọn tất cả các tổng tích lũy và tức thời chính xác vào cuối mỗi tháng, ngay cả khi không có hoạt động nào trong bản ghi của nhân viên nhất định trong tháng đó. Điều này cấm chúng tôi chỉ xem qua các giao dịch đã xảy ra trong tháng.
Trong loại truy vấn thứ hai, chúng tôi muốn có thể lập hồ sơ dân số nhân viên vào bất kỳ thời điểm chính xác nào, cho dù đó có phải là cuối tháng hay không. Chúng tôi muốn chọn một số ngày và giờ chính xác tại bất kỳ thời điểm nào trong lịch sử tổ chức của mình và hỏi xem chúng tôi có bao nhiêu nhân viên và hồ sơ chi tiết của họ vào ngày đó. Truy vấn này cần phải đơn giản và nhanh chóng. Một lần nữa, chúng tôi muốn tránh sàng lọc một loạt các giao dịch phức tạp theo trình tự để tạo ra một ảnh chụp nhanh cho một ngày cụ thể trong quá khứ.
Mặc dù trong hai truy vấn đầu tiên, chúng tôi đã lập luận rằng chúng tôi không thể phụ thuộc trực tiếp vào lịch sử giao dịch thô để cung cấp cho chúng tôi phản hồi nhanh chóng, trong loại truy vấn thứ ba, chúng tôi yêu cầu mọi giao dịch của nhân viên phải được thể hiện rõ ràng. Trong truy vấn này, chúng tôi muốn xem mọi hành động được thực hiện trên một nhân viên nhất định, với trình tự giao dịch chính xác và thời gian chính xác của mỗi giao dịch. Lịch sử giao dịch chi tiết này là “sự thật cơ bản” của dữ liệu nguồn nhân lực và sẽ cung cấp câu trả lời cho mọi câu hỏi chi tiết có thể có, bao gồm cả những câu hỏi mà nhóm thiết kế data mart ban đầu không lường trước được. SQL cho những câu hỏi không lường trước này có thể phức tạp, nhưng chúng tôi tin rằng dữ liệu ở đó đang chờ được phân tích.
Trong cả ba trường hợp
Chúng tôi yêu cầu rằng thứ nguyên nhân viên luôn là mô tả hoàn toàn chính xác về cơ sở nhân viên trong thời gian tức thì được chỉ định bởi truy vấn. Sẽ là một sai lầm lớn nếu chạy một báo cáo vào tháng trước với hồ sơ nhân viên của tháng hiện tại.
Bây giờ chúng ta có những yêu cầu khó khăn này, làm thế quái nào chúng ta có thể đáp ứng tất cả chúng và giữ cho thiết kế đơn giản? Thật ngạc nhiên, chúng ta có thể làm tất cả với một giản đồ một chiều chỉ với một bảng dữ kiện và một bảng thứ nguyên mạnh mẽ được gọi là thứ nguyên Giao dịch nhân viên. Hãy dành một chút thời gian để nghiên cứu Hình 1 .
Kho dữ liệu nguồn nhân lực bao gồm một bảng thông tin khá bình thường với ba thứ nguyên: giao dịch của nhân viên, tháng và tổ chức. Chúng tôi hiển thị tất cả ba kích thước, mặc dù chúng tôi chỉ trình bày chi tiết bảng giao dịch của nhân viên vì đó là phần thú vị của thiết kế. Bảng tháng chứa các ký hiệu mô tả thông thường cho lịch công ty, ở cấp độ của từng tháng. Thứ nguyên tổ chức chứa mô tả về tổ chức mà nhân viên thuộc về vào cuối tháng liên quan.
Bảng thứ nguyên giao dịch nhân viên chứa toàn bộ hồ sơ nhân viên cho từng giao dịch nhân viên riêng lẻ. Khóa giao dịch của nhân viên là khóa nhân tạo được tạo trong quá trình trích xuất và phải là một số nguyên được gán liên tiếp, bắt đầu bằng 1. Không muốn đặt khóa này thành khóa thông minh bao gồm ID nhân viên, mã giao dịch và ngày / giờ có hiệu lực. Tất cả các thuộc tính này đều có giá trị, nhưng chúng chỉ đơn giản là các thuộc tính trong bản ghi giao dịch của nhân viên, nơi chúng tham gia vào các truy vấn và ràng buộc giống như tất cả các thuộc tính khác.
ID nhân viên là “EMP ID” nguồn nhân lực bình thường được sử dụng trong hệ thống sản xuất. Mô tả giao dịch đề cập đến giao dịch đã tạo ra bản ghi cụ thể này, chẳng hạn như Khuyến mại hoặc Thay đổi địa chỉ. Ngày / giờ giao dịch là ngày và giờ chính xác của giao dịch. Chúng tôi giả định rằng những ngày / giờ này đủ chi tiết để đảm bảo tính duy nhất của hồ sơ giao dịch cho một nhân viên nhất định. Do đó, khóa cơ bản thực sự cho bảng thứ nguyên này là ID nhân viên cộng với ngày / giờ giao dịch.
Một phần quan trọng của thiết kế là mục ngày / giờ thứ hai: ngày / giờ kết thúc giao dịch. Ngày / giờ này chính xác bằng ngày / giờ của giao dịch tiếp theo xảy ra trên hồ sơ nhân viên này, bất cứ khi nào có thể. Bằng cách này, hai ngày / giờ này trong mỗi bản ghi xác định một khoảng thời gian mà trong đó mô tả nhân viên là chính xác. Hai ngày / giờ có thể cách nhau một giây (nếu một chuỗi giao dịch nhanh đang được xử lý dựa trên hồ sơ nhân viên) hoặc hai ngày / giờ có thể cách nhau nhiều tháng.
Giao dịch cuối cùng hiện tại được thực hiện dựa trên hồ sơ nhân viên được xác định bằng Cờ giao dịch cuối cùng được đặt thành Đúng. Cách tiếp cận này cho phép nhanh chóng truy xuất trạng thái hiện tại hoặc cuối cùng của bất kỳ nhân viên nào. Nếu một giao dịch mới cho nhân viên đó cần được nhập, cờ trong bản ghi cụ thể này cần được đặt thành Sai. Tôi chưa bao giờ nói rằng chúng tôi không cập nhật hồ sơ trong kho dữ liệu. Ngày / giờ kết thúc giao dịch trong bản ghi giao dịch hiện tại nhất có thể được đặt thành thời gian tùy ý trong tương lai.
Một số bạn có thể phản đối chi phí lưu trữ của thiết kế này. Ngay cả trong một tổ chức khá lớn, cách tiếp cận này không dẫn đến nhu cầu lưu trữ vô lý. Giả sử chúng tôi có 100.000 nhân viên và chúng tôi thực hiện 10 giao dịch nhân sự với họ mỗi năm. Giả sử thêm rằng chúng ta có một hồ sơ nhân viên dài 2.000 byte tương đối dài trong hồ sơ giao dịch của nhân viên. Dữ liệu có giá trị trong 5 năm thêm lên đến 5 X 100.000 X 10 X 2.000 byte hoặc chỉ 10GB dữ liệu thô. Nếu định nghĩa của bạn về giao dịch với nhân viên chi tiết hơn nhiều để việc thăng chức đòi hỏi hàng chục giao dịch cấp thấp nhỏ, thì bạn có thể cân nhắc tạo một nhóm nhỏ các giao dịch siêu nhỏ như Xúc tiến việc làm để làm cho kích thước dữ liệu trở nên thực tế. Phải thừa nhận rằng điều này làm cho nhiệm vụ trích xuất phức tạp hơn.
Thiết kế nhỏ gọn này đáp ứng tốt ba loại truy vấn của chúng tôi. Loại truy vấn đầu tiên để đếm nhanh cấp cao và tổng số sử dụng bảng dữ kiện. Tất cả các dữ kiện trong bảng dữ kiện là cộng theo tất cả các thứ nguyên ngoại trừ các dữ kiện được dán nhãn là số dư. Các số dư này, giống như tất cả các số dư, là bán cộng gộp và phải được tính trung bình trên thứ nguyên thời gian sau khi cộng trên các thứ nguyên khác. Bảng dữ kiện cũng cần thiết để trình bày các tổng cộng như tiền lương kiếm được và số ngày nghỉ phép.
Khóa giao dịch nhân viên cụ thể được sử dụng trong bản ghi bảng dữ kiện là khóa giao dịch nhân viên chính xác được liên kết với khoảng thời gian nửa đêm của ngày cuối cùng của tháng báo cáo. Điều này đảm bảo rằng báo cáo cuối tháng là bản mô tả chính xác về tất cả các hồ sơ nhân viên.
Truy vấn thứ hai được giải quyết bằng bảng thứ nguyên giao dịch của nhân viên. Bạn có thể thực hiện cắt giảm dựa trên thời gian thông qua cơ sở dữ liệu nhân viên bằng cách chọn một ngày và giờ cụ thể và giới hạn ngày và giờ này bằng ngày / giờ giao dịch và nhỏ hơn ngày / giờ kết thúc giao dịch. Điều này được đảm bảo trả về chính xác một hồ sơ nhân viên cho mỗi nhân viên có hồ sơ có hiệu lực vào thời điểm được yêu cầu. Truy vấn có thể thực hiện đếm và ràng buộc đối với tất cả các bản ghi được trả về từ các ràng buộc thời gian này.
Loại truy vấn thứ ba có thể sử dụng cùng một bảng thứ nguyên giao dịch của nhân viên để xem xét chi tiết chuỗi giao dịch với bất kỳ nhân viên nhất định nào.
Một số bạn có thể tự hỏi liệu bảng thứ nguyên giao dịch nhân viên có thực sự không phải là một loại bảng dữ kiện hay không vì nó dường như có thứ nguyên thời gian. Mặc dù về mặt kỹ thuật, điều này có thể đúng, bảng giao dịch nhân viên này chủ yếu chứa các giá trị văn bản và chắc chắn là nguồn chính của các ràng buộc và tiêu đề hàng cho các công cụ truy vấn và viết báo cáo. Vì vậy, thật đúng đắn nếu coi bảng này như một bảng thứ nguyên đóng vai trò là điểm nhập vào kho dữ liệu nguồn nhân lực. Bảng giao dịch nhân viên có thể được sử dụng với bất kỳ bảng dữ kiện nào trong bất kỳ kho dữ liệu nào yêu cầu kích thước nhân viên miễn là khái niệm khóa nhân viên được mở rộng thành khóa giao dịch nhân viên. Thiết kế này thực sự là sự bổ sung của kích thước thay đổi từ từ tiêu chuẩn mà chúng tôi thường sử dụng khi các kích thước như Sản phẩm thay đổi theo những khoảng thời gian không mong muốn.
Hình 1.
Mô hình chiều của Human Resources Data Mart. Bảng dữ kiện là một ảnh chụp nhanưh chứa các tóm tắt số hàng tháng mà rất khó tính toán từ các giao dịch cơ bản. Bảng thứ nguyên giao dịch nhân viên chứa bản ghi cho mọi giao dịch được thực hiện trên mỗi bản ghi nhân viên. Tất cả các thuộc tính nhân viên bắt đầu bằng Tên thực sự bao gồm nhiều trường, được biểu thị bằng dấu cộng.
Ralph Kimball là người phát minh ra máy trạm Xerox Star, sản phẩm thương mại đầu tiên sử dụng chuột, biểu tượng và cửa sổ. Ông từng là phó chủ tịch phụ trách ứng dụng của Metaphor Computer Systems, đồng thời là người sáng lập và cựu giám đốc điều hành của Red Brick Systems. Giờ đây, anh ấy làm tư vấn độc lập thiết kế kho dữ liệu lớn. Cuốn sách của ông Bộ công cụ Kho Dữ liệu: Cách Thiết kế Kho Dữ liệu Thứ nguyên (Wiley, 1996) hiện đã có sẵn.
