Boa noite pessoal,
Alguém já precisou implementar generalização/especialização no scriptcase?
Estou com um caso em que uma especialização é a melhor saída para o banco de dados, mas não sei muito bem o que fazer com o SC. Nunca precisei usar antes.
O caso é de Pessoa - Professor - Funcionário (caso clássico).
Alguma dica (mestre detalhe num relacionamento 1:1 ?? ou faz um form na mão??)?
[]s
Olá, Allan.
Explica melhor a tua dúvida.
Você quer criar um cadastro de pessoa e essa pessoa pode ser funcionário ou professor?
O SC não tem nada a ver com o peixe.
Tem que lembrar que o SC é apenas um gerador de código PHP.
O que sugere generalização/especialização? Toda tabela deve ter um identificador único e exclusivo, sendo assim crie sempre a coluna Id (autoincremente e Chave Primária) em todas suas tabelas. E toda tabela filho deve ter a coluna do identificador de seu pai.
Fom/Detalhe padrão do sc pode ser usado normalmente com essa estrutura de banco de dados.
Relacionamento 1x1: Não é mestre/detalhe. Quando se há necessidade de em um mesmo formulário inserir registro em ambas as tabelas (caso raro de se acontecer) Você deve controlar as janelas manualmente, ou seja criando uma app de controle e fazendo os devidos ‘inserts’ manualmente.
No caso de Professor/ Funcionário. Veja que professor é uma atribuição de pessoa, e funcionário também. Então um formulário padrão para cadastrar pessoas (com seu respectivo ID) e uma tabela de atribuições já alimentada (Mult CheckBox nesse formulário) para que você possa atribuir as funções dessa pessoa. Uma tabela de campos adicionais pode ser filho de pessoas onde se adicionam dinamicamente campos específicos a cada função, ou criar todos os campos em pessoas e habilita-los conforme as a funções habilitadas (particularmente não gosto dessa opção).
Nada impede de ter uma tabela professor e outra funcionário cada um com seus devidos campos e nelas o identificador de pessoa.
Para tal é preciso formulário de pessoa, formulário de professor, formulário de funcionário, e o cadastro de pessoa deve ser realizado primeiro, aí depois os cadastros de professores e funcionários,que podem ser em momentos diferentes. Isso é uma generalização. Veja bem, que faz sentido, pois no menu do sistema funcionário deve fazer parte do módulo de RH, e professor do módulo acadêmico, que são localizações diferentes dentro do sistema, mas pessoas a qual se refere? A ambos se pensar bem, mas pode ficar no módulo cadastros. Nesse caso é uma generalização parcial § pois nem toda pessoa deve ser professor, nem funcionário, pode ser um aluno, um fornecedor. Nesse caso nem toda entidade especial corresponde a uma entidade genérica.
Modele sua base sempre pensando no impacto da programação, na facilidade de operação (User-Friendly), mas sem deixar de se preocupar com a integridade, padronização e menor redundância possível nos dados.
Muito bom Haroldo!!
É isso aí, mestre Haroldo.
Excelente aula, Haroldo.
Seguindo em parte o que já foi explicado pelo Haroldo, um exemplo, cadastro Único de pessoas, com ID Único, ai temos as tabelas 1:N separadas:
Endereços, Doctos, Emails e outras que precisar, relacionadas ao ID Único da ‘Pessoa’ uma pessoa pode ser várias coisas, exemplo: Cliente, Fornecedor, Funcionário, etc.
- Padronização e menor redundância possível nos dados.
Olha ai o G5! Bom exemplo Jailton.
Haroldo é professornato!
Jailton,
Esse form é do SC?
Não é tela de um ERP desktop que eu peguei como exemplo ‘educativo para o caso’. hehe
Ufa…
Me assustei vendo a tela. Pensei: estou muito atrasado em termos de layout no SC.
[]s