Thiết kế cơ sở dữ liệu - Nhân viên Hệ thống đồng hồ vào và ra

Question

Tôi muốn phát triển Hệ thống vào và ra nhân viên (trang web).

Tôi lo ngại hai điều:

• Nếu nhân viên quên 'Clock Out' từ ngày hôm qua và họ có 'Clock Trong' ngày hôm nay, nó nên lá cờ cho người quản lý.

• Nhân viên có thể làm việc theo thời gian, ví dụ: Đồng hồ Thứ Hai 11:00 SA tới Thứ Ba 01:30 SA (sau nửa đêm). Tôi không muốn hệ thống nghĩ rằng nhân viên đã quên đồng hồ ..

  • Nhân viên có thể đồng hồ Vào và ra ngoài nhiều lần trong ngày.

Cách giải quyết vấn đề này và những gì có thể được cải thiện trên thiết kế cơ sở dữ liệu?

bảng nhân viên:

+-------------+--------------+------+-----+---------+----------------+ 
| Field  | Type   | Null | Key | Default | Extra   | 
+-------------+--------------+------+-----+---------+----------------+ 
| id   | int(11)  | NO | PRI | NULL | auto_increment | 
| name  | varchar(50) | NO |  | NULL |    | 
| password | varchar(50) | NO |  | NULL |    | 
| hourly_rate | decimal(6,2) | NO |  | NULL |    | 
+-------------+--------------+------+-----+---------+----------------+ 

clocking bảng:

+----------------+----------+------+-----+---------+----------------+ 
| Field   | Type  | Null | Key | Default | Extra   | 
+----------------+----------+------+-----+---------+----------------+ 
| id    | int(11) | NO | PRI | NULL | auto_increment | 
| staff_id  | int(11) | NO |  | NULL |    | 
| clock_in_date | datetime | NO |  | NULL |    | 
| clock_out_date | datetime | NO |  | NULL |    | 
+----------------+----------+------+-----+---------+----------------+ 

Answer 1

thiết kế cơ sở dữ liệu của bạn có vẻ tốt. Nó chỉ nên ghi lại trong và ngoài lần. Một nơi nào khác trong ứng dụng của bạn, bạn nên lập trình quy tắc kinh doanh của bạn. You may read this article on wikipedia về việc tách mối quan tâm.

Answer 2

Điều này không hoàn toàn chính xác từ quan điểm tên miền.

Cần nhập hoặc tắt đồng hồ để thực hiện kiểm tra hoặc khắc phục sự cố. Vì vậy, bạn cần phải lưu trữ lịch sử đấm cá nhân cho tất cả nhân viên.

Bảng xung nhịp trong trường hợp của bạn có thể là dữ liệu có nguồn gốc.

Bảng clocking nên

+----------------+----------+------+-----+---------+----------------+ 
| Field   | Type  | Null | Key | Default | Extra   | 
+----------------+----------+------+-----+---------+----------------+ 
| id    | int(11) | NO | PRI | NULL | auto_increment | 
| staff_id  | int(11) | NO |  | NULL |    | 
| clock_type  | int(1) | NO |  | 0  | 0-in, 1-out | 
| clock   | datetime | NO |  | NULL |    | 
+----------------+----------+------+-----+---------+----------------+ 

Answer 3

Bạn sẽ cần phải cho phép NULL trên clock_out_date. Bằng cách đó, bạn có thể ghi lại séc tại thời điểm xảy ra và chỉ cần rời khỏi clock_out_dateNULL để cho biết rằng người dùng chưa đăng xuất.

Nếu bạn có kế hoạch hỗ trợ đăng nhập nhiều lần/ngày cho mỗi sự kiện/ngày, bạn cũng sẽ cần cột ID sự kiện/ngày trong bảng xung nhịp để bạn có thể nhóm các đăng ký theo sự kiện/ngày. Như bạn đã lưu ý, không thể sử dụng ngày để nhóm các lần kiểm tra kéo dài nửa đêm. Chúng tôi sử dụng một event_id, nhưng có lẽ bạn muốn có một payroll_date.

Tôi đang sử dụng cùng một cấu trúc bảng xung nhịp cho một hệ thống tương tự. Nó được sản xuất trong một năm, và tôi sẽ không thay đổi gì cả. Chúng tôi lưu trữ tất cả các lần trong UTC.

Lưu ý rằng chúng tôi KHÔNG sử dụng hệ thống này cho bảng lương và có thể có các yêu cầu kiểm toán đáng kể đối với hệ thống bảng lương.

Answer 4

Tôi thực sự không gặp vấn đề gì với thiết kế của bạn nhiều như tôi thấy có vấn đề với các yêu cầu kém phát triển.Bạn cần một định nghĩa tốt hơn về thời điểm người quản lý bị thay đổi để giải thích những thay đổi diễn ra trong nhiều ngày. Có lẽ quy tắc tốt nhất sẽ là nếu ai đó đã không hết giờ trong 24 giờ hoặc nếu họ cố gắng đồng hồ trong lần thứ hai, người giám sát sẽ được thông báo. Bạn cũng có thể cần một kích hoạt trên cơ sở dữ liệu mà sẽ không cho phép một đồng hồ trong nếu có một đồng hồ mất tích. Hoặc bạn có thể cho phép đồng hồ vào và gửi đồng hồ bị thiếu cho người giám sát hành động.

Một điều bạn đặc biệt cần là kiểm tra (một bảng riêng) để bạn có thể xem ai đã thay đổi bản ghi khi nào. YOu awnt để có thể nói với ai đã thay đổi hồ sơ và những gì giá trị cũ là trong trường hợp các câu hỏi về thời gian của ai đó.

Đồng hồ thời gian (và tôi giả định rằng chúng sẽ được thanh toán dựa trên giờ được tính giờ) là hoạt động cần kiểm soát nội bộ nghiêm trọng (ở cấp cơ sở dữ liệu không có ứng dụng! ngăn chặn gian lận.) Không ai có quyền truy cập trực tiếp vào bảng. Họ chỉ có thể thay đổi thông qua một thủ tục lưu trữ mà ra lệnh chính xác những gì họ có thể làm.

Bạn có thể muốn có quy tắc cụ thể cho người giám sát không phải là người giám sát. Nói chung bất cứ điều gì liên quan đến thời gian chỉ nên được phép thay đổi bởi người giám sát của người đó sau khi thực tế. Tôi sẽ có một kích hoạt thực thi điều này, người vào bảng chấm công chỉ nên được phép thay đổi đồng hồ trong dữ liệu và sau đó chỉ khi nó là null. Tất cả các thay đổi khác phải từ người giám sát của người đó. Vì vậy, bạn có thể cần một bảng để lưu trữ cấu trúc tổ chức hoặc ít nhất là một lĩnh vực cho thấy người giám sát của nhân viên là ai.

Nếu mọi người sẽ được đăng ký dựa trên đồng hồ và oputs, thì bạn có thể muốn kiểm tra với người kế toán của bạn và kiểm toán viên của họ hoàn thành các quy tắc kinh doanh. Nội bộ controal cho loại điều có thể rất phức tạp và phức tạp để có được chính xác.

Một vấn đề thiết kế mà tôi thấy là cột tỷ lệ theo giờ, điều này thay đổi theo thời gian và bạn sẽ muốn có thể nói điều đó (đặc biệt nếu tỷ lệ thay đổi giữa chu kỳ trả tiền vì lý do nào đó), vì vậy tôi sẽ phá vỡ này ra một bảng liên quan. Một lần nữa, các quyền đối với bảng này cần phải được thực thi nghiêm ngặt. Không ai lấy một nhân sự có thể nhập dữ liệu vào trường tỷ lệ hàng giờ.

Answer 5

Thật là một con giun khổng lồ mà bạn đang mở ở đây. Sau khi làm việc cho một công ty mà chỉ có hệ thống clocking nó là cái gì tôi sẽ không bao giờ muốn làm một lần nữa!

Tôi nhận thấy câu trả lời của tôi rất quan trọng và giải quyết một vài vấn đề ngoài phạm vi bình thường của câu hỏi nhưng đây là để phác thảo thiết kế cơ sở dữ liệu và khái niệm cấu trúc trong loại ứng dụng này. Thông tin này đến từ sự phát triển chuyên môn gần đây tôi đã làm trong lĩnh vực này cũng vì vậy nó không chỉ là giả thuyết mà còn được chứng minh trong thực tế.

Khi bạn đang xem loại hệ thống này, tốt nhất bạn nên sử dụng các chỉ số ban đầu là cờ, đây thường là số lượng cú đấm so với mỗi bản ghi. Để so sánh mọi hồ sơ cho 1.000 nhân viên không phải là điều tốt nhất!

Ví dụ: nếu người dùng có trong 24 giờ 8 lần đột xuất (bắt đầu một ngày, bắt đầu nghỉ buổi sáng, kết thúc buổi sáng, bắt đầu ăn trưa, ăn trưa, bắt đầu buổi chiều, cuối giờ nghỉ và cuối ngày) có thể xác định rằng nó không chắc không có cú đấm nào trong thời gian và giờ làm thêm đã xảy ra, tuy nhiên nếu có 7 cú đấm trong khoảng thời gian 24 giờ (bắt đầu một ngày, bắt đầu nghỉ sáng, kết thúc buổi sáng, bắt đầu ăn trưa, ăn trưa, chiều break bắt đầu và kết thúc trong ngày) bạn biết rằng một cú đấm là mất tích và người đó quên đồng hồ trong ngày. Hãy chú ý đến giờ nghỉ cuối tuần không có ở đó.

Tuy nhiên điều này không được minh chứng đầy đủ và chỉ cung cấp một tham chiếu mang tính chỉ dẫn, bạn sẽ cần phải so sánh lịch biểu thay đổi với các cú đấm để đảm bảo không có gì thực sự bị bỏ qua. Bởi vì có thể cả hai bữa ăn trưa cuối và cuối giờ nghỉ đều bị bỏ lỡ để lại 6 cú đấm bạn có thể thiết lập mã của bạn để gắn cờ bất cứ điều gì mà không phải là X số cú đấm cho nhân viên đó. Khi gắn cờ bạn sau đó chạy so sánh thực tế của bạn trên nhân viên đó trong khoảng thời gian đó để tìm ra những gì đã thực sự xảy ra và những gì đã bị bỏ qua. Điều này không có nghĩa là bạn không so sánh tất cả hồ sơ, điều này phụ thuộc vào số lượng nhân viên có thể gây ra một số vấn đề lớn khi so sánh chính xác trên mọi bản ghi, đây là nơi tốt hơn cho số lớn hơn của nhân viên sử dụng 2 máy chủ, 1 để thu thập dữ liệu và chỉ giao diện, thứ hai để chạy các quy trình so sánh. Như tôi đã đề cập, đối với loại ứng dụng này và để làm việc với các lịch biểu khác nhau, bạn cũng cần phải xem xét lịch trình giữ phím shift để so sánh với. Bạn sẽ muốn giữ một bản ghi đệm cho mỗi nhân viên sẽ cho thời gian bằng nhau trước khi bắt đầu thay đổi và sau khi kết thúc thay đổi. Điều này có nghĩa là khả năng làm thêm giờ kéo dài quá 1 khoảng thời gian sẽ là tối thiểu. Công thức cơ bản thực sự đơn giản: số giờ trong ca làm việc - 24 giờ/2 = khoảng thời gian

Bây giờ bạn đặt khoảng thời gian trước và sau lịch trình thay đổi cho người dùng đó. Nhưng bạn vẫn cần phải xử lý một sự hoán đổi thay đổi, thay đổi hoặc nhiều hơn một sự thay đổi 24 giờ. Đây là nơi nó thực sự trở nên phức tạp. Bạn sẽ muốn xem xét việc nắm giữ một bảng thời gian chồng chéo (padding, shift và punches) mà sau đó có thể được đối chiếu với bất kỳ điều chỉnh nào trong tương lai đối với lịch biểu như sau khi thay đổi thực tế không phải là hiếm khi tham dự.

Bây giờ bạn cũng sẽ muốn giữ một bảng thời gian vắng mặt để nghỉ ốm và nghỉ lễ, dữ liệu này sau đó sẽ cần phải được gắn cờ thường trong bảng đục lỗ/đục lỗ vì đây là những gì bạn so sánh. Khi cờ được đặt trong một khoảng thời gian, bản ghi có thể bị bỏ qua so với một ghi chú còn lại trên báo cáo mà không cần chạy các hoạt động bổ sung để kiểm tra nó.

Gần như cuối cùng, hãy chú ý đến cách bạn cần quên các quy ước ngày/giờ bình thường để đo lường điều này cho một loạt các biến? Chưa kể đến hoạt động hiệu quả và hiệu quả trong nhiều ngày? Bởi vì điều này, bạn nói chung là tốt nhất để chỉ làm việc với thời gian bắt đầu và kết thúc bằng dd/mm/YYYY hh: mm: ss, cho các phép đo sử dụng thời gian UNIX để tính toán thời gian đã trôi qua. Trong khi nói rằng để kiểm toán có thể hầu hết các hệ thống cần một bản ghi "tem ngày" để xử lý phía máy chủ của điều này có thể được yêu cầu khi đưa ra các báo cáo. Cuối cùng, tôi cũng khuyên bạn nên giữ bảng kết quả, điều này sẽ cung cấp kết quả báo cáo cho từng người dùng, theo cách này khi bạn muốn cung cấp hồ sơ lịch sử, bạn có thể tự động tạo tài liệu. so sánh hồ sơ mỗi lần báo cáo được yêu cầu.

Tôi hy vọng điều này sẽ hữu ích!