Banco de dados para um ponto eletronico

Programação Java
#1

galera to precisando de uma ajuda a dias, estou tentando desenvolver um aplicativo para ponto eletronico, e estou com dificuldades para a criação do modelo er (estrutura de banco de dados). se alguem poder me da uma mao.
falta apenas a parte do ponto, restrições de horarios

CREATE TABLE empresa (
  idempresa INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  nome VARCHAR NULL,
  cnpj VARCHAR NULL,
  telefone VARCHAR NULL,
  nomeDono VARCHAR NULL,
  celular VARCHAR NULL,
  PRIMARY KEY(idempresa)
);

CREATE TABLE feriados (
  idferiados INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  empresa_idempresa INTEGER UNSIGNED NOT NULL,
  descricao VARCHAR(75) NULL,
  dia DATE NULL,
  PRIMARY KEY(idferiados),
  INDEX feriados_FKIndex1(empresa_idempresa)
);

CREATE TABLE funcionario (
  idfuncionario INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  empresa_idempresa INTEGER UNSIGNED NOT NULL,
  Nome VARCHAR NULL,
  cpf VARCHAR NULL,
  aniversario DATE NULL,
  email VARCHAR NULL,
  celular VARCHAR NULL,
  setor VARCHAR NULL,
  statu BOOL NULL,
  PRIMARY KEY(idfuncionario),
  INDEX funcionario_FKIndex1(empresa_idempresa)
);

CREATE TABLE usuarioAdmin (
  idusuarioAdmin INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  empresa_idempresa INTEGER UNSIGNED NOT NULL,
  nomeAdmin VARCHAR NULL,
  senhaAdmin VARCHAR NULL,
  dataAlteracao TIMESTAMP NULL,
  PRIMARY KEY(idusuarioAdmin),
  INDEX usuarioAdmin_FKIndex1(empresa_idempresa)
);
#2

E o que não está conseguindo fazer?
Qual a dificuldade? Dúvidas?

#3

a parte do ponto, regras de horarios… aquilo ali é apenas a parte administrativa…

#4

Desde quando regras de negócio se aplicam a modelo entidade relacionamento?
O banco tem como função ser, apenas, um repositório.
No meu caso eu criaria uma tabela responsável por armazenar o registro de entradas/saídas do funcionário. Como um funcionário pode ter vários registros (em dias e horários diferentes), o relacionamento, a princípio, me parece ser 1 : N. Portanto, a tabela que armazena estes dados deve ter uma FK referenciando a tabela que armazena os funcionários.

Funcionario
cod integer...
nome varchar(200)...
--demais colunas
#####
Registro_Ponto
cod integer...
cod_funcionario integer...
dt_data date
tm_registro time
tp_registro integer --este campo identifica se é entrada, saída, almoço, etc.

Agora, só conhecendo a fundo as regras negociais para saber se isto se adequa ao que você necessita.

#5

as regras de negócio você executa na aplicação amigo, no seu bd, apenas crie os campos onde serão guardadas as informações, o resto os selects cuidam

#6

cada funcionario tem um tempo de trabalho em variados dias;
o funcionario pode nao vir trabalhar por atestados ou ferias;
os domingos e feriados não serão validos;

#7

Mas isso é o básico.
Qual a idéia, ao gerar um relatório ou fechar o mês, você faz um select por funcionário e, então, verifica se o total de horas trabalhadas em um dia é igual, maior ou menor ao total de horas que ele deve trabalhar.
Ex. Se o funcionário deve trabalhar 8 horas por dia e ele trabalha:
a) 8 horas: Dia ok, calcula pagamento normal.
b) < 8 horas: Dia não ok. Aí entra tolerância a atrasos/saídas antecipadas.
c) > 8 horas: Calcula como hora extra e, age de acordo com a política da empresa (pagamento ou banco de horas).
Sábados e domingos: hora extra e age de acordo com a política da empresa.
Atestados: Você pode incluir uma coluna no banco de dados para abonar o dia integral, parcialmente ou algumas horas, aí vai de você. O ideal é cria uma tabela diferente, que permitirá associar funcionário e data a ser abonada.
Férias, no meu ponto de vista, devem ser controladas em uma coluna, que pode estar na tabela ponto ou em funcionario (uma simples flag 0 está trabalhando, 1 está em férias).

#8

Sou totalmente contra, a não ser que seja extremamente necessário (e vale estudos caso digam que é), aplicar regras de negócios em banco de dados.
As famosas procedures e triggers, por exemplo. O banco, no meu ponto de vista, deve ser exclusivamente como um “armazenador de informações”. Obviamente, tu precisa criar as tabelas e relacionamentos de acordo com a necessidade do sistema, mas para por ai.

É pensando assim que existe o modelo MVC, por exemplo. O DAO você vai apenas trabalhar com os dados, persistir, consultar, editar, remover…enquanto tu terá tua camada de serviço que será responsável por aplicar toda a lógica de negócio, caso seja um feriado, soma-se mais um dia, por exemplo. Pense nas informações, relacionamentos e afins que precisa quando criares teu banco de dados, mas não pense em como fará os “if´s e elses” na parte do banco.

É opinião minha, apenas.

#9

[quote=nel]Sou totalmente contra, a não ser que seja extremamente necessário (e vale estudos caso digam que é), aplicar regras de negócios em banco de dados.
As famosas procedures e triggers, por exemplo. O banco, no meu ponto de vista, deve ser exclusivamente como um “armazenador de informações”. Obviamente, tu precisa criar as tabelas e relacionamentos de acordo com a necessidade do sistema, mas para por ai.

É pensando assim que existe o modelo MVC, por exemplo. O DAO você vai apenas trabalhar com os dados, persistir, consultar, editar, remover…enquanto tu terá tua camada de serviço que será responsável por aplicar toda a lógica de negócio, caso seja um feriado, soma-se mais um dia, por exemplo. Pense nas informações, relacionamentos e afins que precisa quando criares teu banco de dados, mas não pense em como fará os “if´s e elses” na parte do banco.

É opinião minha, apenas.[/quote]
Concordo plenamente.
A partir do momento que delegamos a função de inibidor, restritor ou mesmo de regulador das regras de negócios ao banco de dados, acabamos nos livrando da responsabilidade de pensar e trabalhar a lógica.
Digo isso com toda a propriedade do mundo, por ter desenvolvido meu TCC em um modelo orientado a banco de dados (foram mais de 20 procedures, 40 funcions e uma porrada de cursores).
Não se pode negar que o desempenho é maior, mas a manutenção, é extremamente difícil.

#10

[quote=drsmachado][quote=nel]Sou totalmente contra, a não ser que seja extremamente necessário (e vale estudos caso digam que é), aplicar regras de negócios em banco de dados.
As famosas procedures e triggers, por exemplo. O banco, no meu ponto de vista, deve ser exclusivamente como um “armazenador de informações”. Obviamente, tu precisa criar as tabelas e relacionamentos de acordo com a necessidade do sistema, mas para por ai.

É pensando assim que existe o modelo MVC, por exemplo. O DAO você vai apenas trabalhar com os dados, persistir, consultar, editar, remover…enquanto tu terá tua camada de serviço que será responsável por aplicar toda a lógica de negócio, caso seja um feriado, soma-se mais um dia, por exemplo. Pense nas informações, relacionamentos e afins que precisa quando criares teu banco de dados, mas não pense em como fará os “if´s e elses” na parte do banco.

É opinião minha, apenas.[/quote]
Concordo plenamente.
A partir do momento que delegamos a função de inibidor, restritor ou mesmo de regulador das regras de negócios ao banco de dados, acabamos nos livrando da responsabilidade de pensar e trabalhar a lógica.
Digo isso com toda a propriedade do mundo, por ter desenvolvido meu TCC em um modelo orientado a banco de dados (foram mais de 20 procedures, 40 funcions e uma porrada de cursores).
Não se pode negar que o desempenho é maior, mas a manutenção, é extremamente difícil.[/quote]

Difícil, complexa e trabalhosa. Um “DAOException” ou “BussinessException” pode ser tão mais simples de identificar do que um SQLException. Só imagina…
Eu trabalhei um pouco com isso, então imagino o trabalho que teve machado rs.

#11

criei mais assim

CREATE TABLE dia (
  iddia INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  permições_idpermições INTEGER UNSIGNED NOT NULL,
  diapermitido DATE NULL,
  PRIMARY KEY(iddia),
  INDEX dia_FKIndex1(permições_idpermições)
);

CREATE TABLE empresa (
  idempresa INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  nome VARCHAR NULL,
  cnpj VARCHAR NULL,
  telefone VARCHAR NULL,
  nomeDono VARCHAR NULL,
  celular VARCHAR NULL,
  PRIMARY KEY(idempresa)
);

CREATE TABLE feriados (
  idferiados INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  empresa_idempresa INTEGER UNSIGNED NOT NULL,
  descricao VARCHAR(75) NULL,
  dia DATE NULL,
  PRIMARY KEY(idferiados),
  INDEX feriados_FKIndex1(empresa_idempresa)
);

CREATE TABLE funcionario (
  idfuncionario INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  empresa_idempresa INTEGER UNSIGNED NOT NULL,
  Nome VARCHAR NULL,
  cpf VARCHAR NULL,
  aniversario DATE NULL,
  email VARCHAR NULL,
  celular VARCHAR NULL,
  setor VARCHAR NULL,
  statu BOOL NULL,
  PRIMARY KEY(idfuncionario),
  INDEX funcionario_FKIndex1(empresa_idempresa)
);

CREATE TABLE hora (
  idhora INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  dia_iddia INTEGER UNSIGNED NOT NULL,
  horapermitida TIME NULL,
  PRIMARY KEY(idhora),
  INDEX hora_FKIndex1(dia_iddia)
);

CREATE TABLE permições (
  idpermições INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  funcionario_idfuncionario INTEGER UNSIGNED NOT NULL,
  descricao VARCHAR(75) NULL,
  PRIMARY KEY(idpermições),
  INDEX permições_FKIndex1(funcionario_idfuncionario)
);

CREATE TABLE ponto (
  idponto INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  funcionario_idfuncionario INTEGER UNSIGNED NOT NULL,
  diahora DATETIME NULL,
  tipoRegistro VARCHAR(2) NULL,
  PRIMARY KEY(idponto),
  INDEX ponto_FKIndex1(funcionario_idfuncionario)
);

CREATE TABLE usuarioAdmin (
  idusuarioAdmin INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  empresa_idempresa INTEGER UNSIGNED NOT NULL,
  nomeAdmin VARCHAR NULL,
  senhaAdmin VARCHAR NULL,
  dataAlteracao TIMESTAMP NULL,
  PRIMARY KEY(idusuarioAdmin),
  INDEX usuarioAdmin_FKIndex1(empresa_idempresa)
);

dentro de permições vou conseguir colocar os dias dentro dos dias as horas, assim posso fazer com que eu faça um select para ver se é permitido de segunda a sexta da 8:30 às 12:00 e das 13:30 às 19:00 é permitido lah no ponto dar entradas e saidas. e nos dias que faltarem o administrador pode inserir permição de atestado na data X para o funcionario X;

alguem pode me dizer se esta correto?

#12

Camarada, não existe uma verdade absoluta.
O modelo que está desenhando deve atender aos requisitos descritos para a resolução/suprimento do problema/necessidade.
Portanto, se o banco de dados permitirá armazenar as informações geradas pelo e para o sistema, sim, está correto.

#13