Um só formulario com campos de outras tabelas

Ola galera !

Sou novo no scriptcase, estou com uma dúvida cruel sobre esse assunto, vou colocar de uma forma mais simples.

Supundo que tenho as tabelas abaixo:

pessoa (id_pessoa, nome)
pessoa_fisica (id_pessoa_fisica, cpf )
professor (id_professor, id_professor_pessoa_fisica, matricula )

Onde: professor.id_professor_pessoa_fisica = pessoa_fisica.id_pessoa_fisica = pessoa.id_pessoa

Como criar um formulário que comporte os campos abaixo:

=============================
Cadastro de Professor
Nome: …
Cpf: …
Matricula: …

Alguma sugestão ?

Desde já agradeço a atenção de todos.

Cledson,

É rígida essa modelagem?

Pois a meu ver ela é muito estranha.

Vejo um problema sério na sua modelagem dos dados.
O correto não seria vc ter somente 2 tabelas, sendo uma com os dados de uma pessoa, seja física ou jurídica, sendo que o scriptcase já trata para vc campos tipo CPF/CNPJ, não precisando criar 2 campos, e a outra tabela somente com os dados relevantes a pessoa que é professor? Lembrando que na tabela de professores vc terá que ter o id chave e também o id da pessoa, para ser feita a referência.

[ul]Depente da estratégia a ser usada:

Só para lembra-los …

Em se tratando de modelagem para herança em um banco de dados, existem as seguintes abordagens:

  1. Tabela por hierarquia
  2. Tabela por classe concreta
  3. Tabela por classe

Herança – Tabela por hierarquia
Todos os atributos são colocados em uma única tabela
Necessita uma coluna para identificar o tipo

Herança – Tabela por classe concreta
cada classe concreta é mapeada para uma tabela diferente no banco de dados.
Em cada classe são definidas colunas para todas as propriedades da classe, inclusive as propriedades herdadas.

Herança – Tabela por Sub-classe / classe
Uma tabela por classe

No meu caso, optei em trabalhar com a terceira opção, ou seja. Uma tabela por classe.

fiz uma busca rápida na internet e achei esse link: http://www.agiledata.org/essays/mappingObjects.html
Mais se procurarem … acham mais documentação sobre o assunto melhor.

Obrigado pelas respostas … e contribuição.[/ul]

Cledson, acho que vc não entendeu o que eu falei. Não estou falando da sua modelagem de código, onde há a definição de classes, heranças, polimorfismos, etc… Só citei a sua estrutura física para que vc consiga fazer a sua modelagem das classes, vc pode estar tomando um caminho que na verdade não vai te trazer benefício algum. Mas, faça da maneira que lhe convier, mas sua modelagem continua errada para existir uma referência entre as três tabelas, espero que tenha entendido.

Classes Hibernate utilizam esse tipo de mapeamento.
Acho um pouco exagerado.
Deve haver bom senso na modelagem e pensar sempre na programação também.

http://www.macoratti.net/cbmd1.htm

http://pt.wikipedia.org/wiki/Modelagem_de_dados

http://www.eteavare.com.br/apostilas/modelagem.pdf

http://www.devmedia.com.br/introducao-a-modelagem-de-dados-artigo-revista-sql-magazine-86/20398

http://www.sis4.com/brmodelo/monografia/monografia.htm

O Atributo CPF pertence a entidade Pessoas_Fisicas assim como o atributo Nome.

Porque complicar?

O Atributo pertence a pesso física Sim, mais nome não… ele pertence a Pessoa

Pois pode representar o nome de uma pessoa física ou representar nome fantasia de uma pessoa juridica.

Gente isso só foi uma tentativa de um exemplo …

TOMANDO COMO BASE essa estrutura ou OUTRA parecida.

Bem galera … a questão é, dar pra se feito ou não no scriptcase … alguém pode me dar uma ideia por favor ?

Valeu gente !

Eu gosto de passar longe desse negócio e modelagem de dados, herança, etc. hehehehehe

Já pensou em usar um cursor (view)?

Da sim par azer no scriptcase, mas as ações serão manuais.

Use um aplicação controle trate tudo no evento OnBeforeInsert e grave tudo no OnafterInsert na tabela que você quiser.
Mas que seu esquema tá um tanto complicado esta, se for pra trabalhar assim melhor nem usar SC… vai ter que tratar tudo e fazer os insert´s manuais!!

Saulo ta sumido cara rsrs…
Apenas para te lembrar, porque você sabe claro, apenas deve ter sido um mal entendido. Aplicação controle não tem onBefore e nem onAfter :wink:

kkkkkkkkk… tem razão irmão!!! É OnValidate né…? Foi mal… apaga essa parte do que eu falei!! É a hora!!

Cara tô por aí… eu sempre to online e no forum… mas tenho me limitado um pouco a ler … dou meus pitacos só de vez em quando!!

É só criar os campos manuais no formulário e na before insert e update executar o insert e update nos campos manuais e na onload faz a carga via sc select e na ondelete executa o delete na tabela secundaria.

Opa … valeu Galera pelas respostas …

Outra dúvida … que é um pouco parecida

Qual seria a melhor saída/solução para se cadastrar ENDERECOS, para um formulário de Fornecedor, Cliente, Loja, Funcionario etc … Onde todos os tipos de pessoas que eu vier precisar vão ter endereço ?

Crio repetidamente os campos comuns de endereco em todas essas tabelas ou crio uma tabela só para endereco e nela colocaria uma chave para associar a essas pessoas ?
Tipo assim: endereco(id, logradouro, cep, numero, id_owner)

Pra mim, a melhor saida seria criar a tabela de endereço, pois assim não teria que repetir os dados de endereco todas vez que for cadastrar uma pessoa …

O que vcs acham ?

Porque não cria o endereço em cada tabela?

Você nunca vai ter um mesmo endereço para pessoas diferentes.

Porque criar mais trabalho no desenvolvimento?

Caros colegas …

Só uma breve explicação sobre minha pessoa para entendimento de tantas dúvidas relativas a modelagem aqui.

Sou desenvolveddor java a quase 10 anos, mais um detalhe, Java para Desktop.

Sai da ultima empresa em que trabalhava e hj estou tentando me atualizar na área de web que é o futuro.

Achei o Scriptcase, apesar de ser em php, pra mim vai ser um pouco mais trabalhoso, mais nada que não possa aprender …

Pelo que to vendo, Não sei se é só o caso do Scriptcase ou qualquer linguagem para web mesmo … a galera tem dificuldade em se trabalhar com tabelas normalizadas … O scriptcase que o diga, nele pelo que eu to vendo, quase sempre a melhor saída “menos trabalho” a qual sempre me falam aqui no forum é fazer um tabelão com tudo dentro … não sei em outras linguagens web …

Bem, estou testando o sc, Adorei muitos recurso que ele tem … são muitos bons mesmo. Mais qt a isso fica a desejar.

Obrigado a todos pelas suas opiniões, críticas positivas ou não …

c.s.

Cledson bom dia,

Acho legal que você demonstre a tua expertise na área, legal mesmo. O que eu posso te dizer é que sempre normalizo meus bancos de dados, inclusive adicionando regras de negócio nele e não tive problemas em usar o Scriptcase para usar estes bancos. Pode ser que em um primeiro momento haja alguma dificuldade em se usar o SC, o que é natural, mas com pouco tempo você vai ver que o SC nada mais faz do que ler a estrutura do banco de dados montado e gerar códigos-fonte sobre cada tabela, inclusive respeitando as regras de chaves primárias, chaves estrangeiras, etc. Lógico que o SC (assim como qualquer outra ferramenta geradora de código) tem suas limitações, bugs, etc. Mas nada que não se possa contornar.

Todas as minhas sugestões quanto a modelagem, não envolvem a linguagem, e sim, o bom senso em criar tabelas utilizando conceitos de normatização conhecidos e aprendidos na universidade.

Se deseja seguir rigidamente o seu conceito de normatização (gostaria de conhecer documentação séria a respeito desse conceito que utiliza) é uma questão sua pessoal que todos devemos respeitar, só que acredito encontrar menos respostas a seus tópicos em função disso.

O Scriptcase (PHP) não tem nada a ver com a modelagem, pode utilizar seus modelos sem problema.

Tentarei sempre mostrar os caminhos na programação utilizando seus modelos.

Supondo:

Tabela Fornecedores
Tabela Clientes
Tabela Funcionários
Tabela Endereços

  • Entende-se que a relação seja 1 x 1 em fornecedores,clientes e funcionarios com endereços.

Aplicação Fornecedores
Aplicação Clientes
Aplicação Funcionarios

Montando esquema para gravação alteração e exclusão do endereço para o cadastro de fornecedores (as demais aplicações o trabalho será o repetido)

Na aplicação criar campos virtuais (manuais) para endereço.

Situação novo registro:

na onafterinsert:

verificar se campos do endereço possuem dados, se sim, pegar o id do fornecedor gerado:

  • Sugestão para sistema multi-usuário (ter um campo em fornecedor com a sessão do php, e usar um select max(id) from fornecedor qhere sessao_php=’$_sessao’

Com o id do fornecedor inserir os dados na tabela de endereço tipificando o endereço como sendo de fornecedor.

Situação Edição de registro.

No evento onload:

Ler o endereço do fornecedor em questão e alimentar manualmente todos os campos virtuais.
Guardar o id do endereço em global (vai precisar mais tarde)

No evento onafterupdate:

  • Testar se houve alguma alteração nos campos virtuais, se sim proceder o update na tabela de endereços

Situação Deleção de registro:

OnBeforeDelete:
Com o id do endereço proceder a deleção na tabela de endereços.

*Ufa, cansei de escrever, imagino ao programar como vai ser.

Mas aí está solução programando em SC.

Diz-se que uma tabela num banco de dados relacional está numa certa forma normal se satisfaz certas condições. O trabalho original de Edgar F. Codd definiu três dessas formas, mas existem hoje outras formas normais geralmente aceitas. Damos aqui uma curta panorâmica informal das mais comuns. Cada forma normal listada abaixo representa uma condição mais forte que a precede na lista. Para a maioria dos efeitos práticos, considera-se que as bases de dados estão normalizadas se aderirem à terceira forma normal.

Primeira Forma Normal (ou 1FN) requer que todos os valores de colunas em uma tabela sejam atômicos (ex., um número é um átomo, enquanto uma lista ou um conjunto não o são). A normalização para a primeira forma normal elimina grupos repetidos, pondo-os cada um em uma tabela separada, conectando-os com uma chave primária ou estrangeira.

Segunda Forma Normal (ou 2FN) requer que não haja dependência funcional não-trivial de um atributo que não seja a chave, em parte da chave candidata.

Terceira Forma Normal (ou 3FN) requer não haver dependências funcionais não-triviais de atributos que não sejam chave, em qualquer coisa exceto um superconjunto de uma chave candidata.
Forma Normal de Boyce-Codd (ou BCNF) requer que não exista nenhuma dependência funcional não-trivial de atributos em algo mais do que um superconjunto de uma chave candidata. Neste estágio, todos os atributos são dependentes de uma chave, de uma chave inteira e de nada mais que uma chave (excluindo dependências triviais, como A→A).

Quarta Forma Normal (ou 4FN) requer que não exista nenhuma dependência multi-valorada não-trivial de conjuntos de atributo em algo mais de que um superconjunto de uma chave candidata.

Quinta Forma Normal (ou 5FN ou PJ/NF) requer que não exista dependências de joins não triviais que não venham de restrições chave.
Domain-Key Normal Form (ou DK/NF) requer que todas as restrições sigam os domínios e restrições chave.

Não estou discordando da sua forma. Apenas estou aproveitando o contexto do tópico para mostrar algo que recentemente aprendi.

Eu adoro esse assunto, particularmente gosto de usar o brModelo para meus projetos de modelagem:

http://chcandido.tripod.com/

http://www.sis4.com/brModelo/