데이터베이스 설계 - 직원 클럭 인 및 아웃 시스템

Question

직원 클럭 인 및 아웃 시스템 (웹 사이트)을 개발하고 싶습니다.

• 직원이 어제 '시계 아웃'에 잊어 버린 경우 그들은 매니저에게 '시계에서'오늘, 그것은해야 플래그를 가지고 :

  내가 관심을 두 가지입니다.

• 직원이 시간이 지남에 따라 작동 할 수 있습니다. 시계 월요일 11:00 AM - 화요일 01:30 AM (자정 이후). 나는 시스템이 thay 직원이 시계를 깜박 잊어 버렸다고 생각하고 싶지 않다. ...

  • 직원이 하루에 여러 번 시계와 시간 제한을 설정할 수 있습니다.

어떻게이 문제를 해결하기 위해 및 데이터베이스 설계에 무엇을 개선 할 수 있습니까?

직원 테이블 :

+-------------+--------------+------+-----+---------+----------------+ 
| 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 |    | 
+-------------+--------------+------+-----+---------+----------------+ 

클러킹 테이블 :

+----------------+----------+------+-----+---------+----------------+ 
| 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

데이터베이스 설계가 잘 보인다. 그것은 단지 시간을 기록해야합니다. 응용 프로그램의 다른 곳에서 비즈니스 규칙을 프로그래밍해야합니다. 우려의 분리에 You may read this article on wikipedia.

Answer 2

도메인의 관점에서 완전히 정확하지는 않습니다.

감사 용도 또는 문제 해결을 위해 시계 또는 아웃/펀치가 필요합니다. 그래서 모든 직원에 대해 개별 펀치 기록을 저장해야합니다.

귀하의 경우 클럭 킹 테이블은 파생 데이터 일 수 있습니다.

클록 킹 테이블은

+----------------+----------+------+-----+---------+----------------+ 
| 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

당신은 clock_out_date에 NULL을 허용 할 필요가 있어야한다. 그렇게하면 체크인이 발생했을 때이를 기록 할 수 있으며 사용자가 아직 체크 아웃하지 않았 음을 나타 내기 위해 clock_out_dateNULL을 그냥 둡니다.

이벤트/일당 다중 체크 인/아웃을 지원하려는 경우 클럭링 테이블에 이벤트/요일 ID 열이 있어야 이벤트/일별로 체크 인을 그룹화 할 수 있습니다. 언급했듯이 자정에 해당하는 체크인을 그룹화하는 데는 날짜를 사용할 수 없습니다. 우리는 event_id를 사용하지만 아마도 payroll_date를 원할 것입니다.

비슷한 시스템에 동일한 클로킹 테이블 구조를 사용하고 있습니다. 1 년 동안 생산 중이었고 나는 물건을 바꾸지 않을 것입니다. 우리는 모든 시간을 UTC로 저장합니다.

우리는 급여 시스템에이 시스템을 사용하지 않으며 급여 시스템에 대한 중요한 감사 요구 사항이있을 수 있습니다.

Answer 4

불충분하게 설계된 요구 사항에 문제가있는만큼 실제로 디자인에 문제가 나타나지 않습니다.관리자가 여러 날이 지나는 교대조를 설명하기 위해 관리자가 언제 변경되는지 더 잘 정의해야합니다. 아마도 가장 좋은 규칙은 누군가가 24 시간 동안 시계 아웃하지 않거나 두 번째 시계를하려고하면 감독자에게 알림이 전송되는 것입니다. 클럭이 누락 된 경우 클럭을 허용하지 않는 트리거가 데이터베이스에 필요할 수도 있습니다. 아니면 시계를 허용하고 실종 된 시계 아웃을 감독자에게 보낼 수도 있습니다.

감사 기록 ​​(별도의 테이블)을 사용하면 누가 언제 레코드를 변경했는지 확인할 수 있습니다. 기록을 변경 한 사람과 누군가의 시간에 대해 질문 할 때 오래된 값이 무엇인지 말할 수있을 것입니다.

시간 클럭킹 (계시 된 시간을 기준으로 돈을받는 것으로 가정)은 심각한 내부 통제가 필요한 활동입니다 (응용 프로그램이 아닌 데이터베이스 수준에서 수행해야 함). 내부 컨트롤은 응용 프로그램 수준에 있지 않아야합니다. 사기 방지.) 아무도 테이블에 직접 액세스 할 수 없어야합니다. 그들은 할 수있는 일을 정확하게 지시하는 저장 프로 시저를 통해서만 변경할 수 있어야합니다.

감독자가 아닌 감독자에 대한 특정 규칙이 필요할 수 있습니다. 일반적으로 시간과 관련된 것은 사실 이후에 사람의 관리자가 변경할 수 있어야합니다. 나는 이것을 시행하는 방아쇠를 당할 것이고, 작업 표를 입력하는 사람은 데이터의 시계를 변경하도록 허용되어야하며, 단지 그것이 null 인 경우에만 허용되어야합니다. 다른 모든 변경은 그 사람의 관리자가해야합니다. 따라서 조직 구조를 저장하기위한 테이블이 필요하거나 직원의 감독자가 누구인지 보여주는 필드가 필요할 수 있습니다.

사람들이 시계 기능과 oputs를 기반으로하여 돈을 지불하게 될 경우 회계 담당자와 감사원이 비즈니스 규칙을 완결 할 수 있는지 확인하는 것이 좋습니다. 이런 종류의 일에 대한 내부 통제는 매우 복잡하고 까다로워 질 수 있습니다.

내가 보는 한 가지 디자인 문제는 시간별 열로, 시간이 지남에 따라 변경되며 (어떤 이유로 인해 요금이 도중에서 변경되는 경우) 말할 수 있기를 원할 것입니다. 이건 관련 테이블에. 다시 말하지만,이 테이블에 대한 권리는 엄격하게 집행되어야합니다. HR 담당자가 시간당 요율 필드에 데이터를 입력 할 수 있어야합니다.

Answer 5

당신이 여기에 열리는 거대한 벌레는 얼마나 될까요? 시스템 클럭킹 만하는 회사에서 일한 후에는 다시는하고 싶지 않을 것입니다.

필자의 답장은 개념적이며 질문의 일반적인 범위를 벗어나는 몇 가지 문제를 해결하지만 이는 데이터베이스 디자인과 이러한 유형의 응용 프로그램의 구조적 개념을 설명하기위한 것입니다. 이 정보는이 분야에서 최근 수행 한 최근의 전문가 개발에서 비롯된 것이므로 전적으로 가설은 아니지만 실제로 입증 된 것입니다.

이 유형의 시스템을 살펴볼 때 처음에는 표시기를 플래그로 사용하는 것이 가장 좋습니다. 일반적으로 펀치의 양과 모든 레코드를 비교하는 것입니다. 1,000 명의 직원에 대한 모든 기록을 비교하는 것이 최선의 방법은 아닙니다!

예를 들어, 사용자가 24 시간 동안 8 펀치 (시작, 아침 휴식 시작, 아침 휴식 끝, 점심 시작, 점심 종료, 오후 휴식 시작, 오후 휴식 끝, 하루 끝) 그 기간에 놓친 펀치가 없었고 초과 근무가 발생하지 않았다고 결정할 수 있지만, 24 시간 기간 (시작, 아침 휴식 시작, 아침 휴식 끝, 점심 시작, 점심 식사 종료, 오후 오후에 7 펀치가있는 경우 휴식 시작과 하루의 끝) 당신은 펀치가 누락되어 그 사람은 그날을 조심하지 못한다는 것을 알고 있습니다. 오후 휴식 종결은 거기 있지 않은 방법에 유의하십시오.

그러나 이것은 완전한 증거는 아니며 참고 용으로 만 제공됩니다. 실제로 누락 된 사항이 없는지 확인하려면 교대 근무 일정을 펀치와 비교해야합니다. 점심 엔드와 오후 휴식 엔드 모두가 6 개의 펀치를 벗어난 채로있을 수 있기 때문에 해당 직원의 펀치 수가 X가 아닌 것을 플래그하도록 코드를 설정할 수 있습니다. 그런 다음 해당 기간에 해당 직원에 대한 실제 비교를 실행하여 실제로 발생한 상황과 누락 된 사항을 해결하십시오.

이것은 모든 레코드를 비교하지 않는다는 것을 의미하지는 않지만 모든 레코드에 대해 정확한 비교를 수행하는 데 큰 문제가 발생할 수있는 직원 수에 따라 다르지만 큰 숫자 일수록 일반적으로 더 좋습니다 2 개의 서버를 사용하는 직원의 수는 데이터 수집 및 인터페이스 전용이고 1 개는 비교 프로세스 실행 용입니다.

앞서 언급했듯이,이 유형의 응용 프로그램과 다양한 일정으로 작업하려면 비교할 일정을 잡고 있어야합니다. 근무 시작 전과 근무 종료 후에 동일한 시간을 제공하는 각 직원에 대한 패딩 기록을 보유해야합니다. 이는 지난 1 기간 동안 연장 된 초과 근무 가능성이 미미하다는 것을 의미합니다. 기본 공식은 매우 간단합니다. 근무 시간 수 - 24 시간/2 = 시간 패딩

이제 해당 사용자의 근무 일정 전후에 시간 패딩을 배치합니다. 그러나 당신은 여전히 ​​교대 교환, 변경 또는 24 시간 교대 이상을 처리해야합니다. 이것은 정말로 까다로워집니다. 사실 변경이 시간 출석에서 드물지 않은 이후 일정에 대한 향후 조정에 대해 조정될 수있는 중복 시간 (패딩, 이동 및 펀치) 테이블을 보유하는 것이 좋습니다.

병가와 공휴일에 대한 부재 테이블 테이블을 보유하고 있으므로이 데이터는 일반적으로 펀치 인/펀치 아웃 테이블에서 플래그가 지정되어야합니다. 일정 기간 동안 플래그가 설정되면 레코드를 비교할 때 건너 뛸 수 있고 추가 작업을 실행하지 않고보고 할 때 메모를 남길 수 있습니다.

끝까지 거의 모든 변수에 대해 이것을 측정하기 위해 일반적인 날짜/시간 규칙을 잊어 버릴 필요가 있습니다. 여러 날짜에 효과적이고 효율적으로 작업하는 것은 말할 것도없이? 이 때문에 일반적으로 dd/mm/YYYY hh : mm : ss로 시작 및 종료 시간으로 작업하는 것이 가장 좋습니다. 측정을 위해 UNIX 시간을 사용하여 얼마나 많은 시간이 경과했는지 계산합니다. 감사 할 수있는 시스템이라면 대부분의 시스템에는 "날짜 스탬프"레코드가 필요하므로 보고서를 내보낼 때 서버 쪽 처리가 필요할 수 있습니다.

마지막으로, 결과 테이블을 보유하는 것이 좋습니다. 이렇게하면 각 사용자에 대한보고 결과를 얻을 수 있습니다.이 방법을 사용하면 동적으로 문서를 생성 할 수있는 기록 레코드를 제공하지만 처리 능력을 낭비하지 않아도됩니다. 보고서가 요청 될 때마다 기록을 비교합니다.

도움이 되었기를 바랍니다.