Denis Courcy

Oi,'buthy' Uma pequena lição. Vou explicar usando o relacionamento 1:N que é mais fácil.Relacionamento não identificado: quando a chave foreign key não pertence a chave primaria da tabela filha. Diz-se que é um relacionamento fraco. Pois a existencia de registro na tabela "filha"(a que é ligada pelo lado muitos da relação) não depende da chave estrangeura(foreign key) vinda da tabela "pai"(o lado 1 da relação) . Relacionamento não identificado:quando a chave foreign key pertence a chave primaria da tabela filha. Diz-se que é um relacionamento forte. Pois a existencia de registro na tabela "filha"(a que é ligada pelo lado muitos da relação) depende da chave estrangeura(foreign key) vinda da tabela "pai"(o lado 1 da relação) . Fisicamente não existe relacionamento N:M (muitos para muitos). O que existe é 1:N ou 1:1. Conforme a pergunta acima o relacionamento indicado é 1:N identificado. As chaves primarias estão descritas no desenho que passei anexo a um post anterior e devem seguir o descrito abaixo: Tabela Chave primária Nivel CodigoNivel; Usuario CodigoUsuario, CodigoNivel; Pergunta CodigoPergunta, CodigoNivel; Pergunta_Has_Usuario CodigoUsuario, CodigoPergunta, CodigoNivel; Resposta CodigoResposta; Multipla_escolha CodigoResposta; Dissertativa CodigoResposta;A ligação entre resposta e pergunta é um relacionamenro 1:N não identificado (nesta ordem).

Geomar Aproveitei uma calmaria aqui no trabalho e fiz o modelo em anexo. Espero que ajude. Estoque.pdf

Desculpe o mico. a pressa é uma porcaria. Assim que tiver tempo analisarei seu código.

Sim. com isto você saberá que este serviço veio da agenda(marcador) e deu entrada como prometido. Isto abre possibilidade (ou não) de você criar registro na agenda para emergências ou outros serviços que possam ser iniciados sem estar no marcador(agenda).

Oi, 'Leonardo Viana' Olhe os trechos de seu código, abaixo: ... CREATE TEMPORARY TABLE IF NOT EXISTS TmpNivelAcids ... DELETE FROM TmpNivelAcids; ... INSERT INTO TmpNivelAcids como se insere dados em uma tabela que não existe?

Oi, 'Alex Mauricio' Este erro está dizendo que a tabela não existe. A mensagem é clara. Então ele não está acontecendo quando você gera o codigo descrito no primeiro post. Algo você está executando para que esta mensagem ocorra. A ordem de criação desta tabela está errada em algum ponto de seu script.

'Geomar Canjundo' Já que você não entendeu vamos tentar denovo. Imagine os lançamentos via papel. Você tem um bloco de marcações e cada folha do bloco pode entrar somente um carro. No bloco de marcações entram dados relativos somente as marcações, certo? Até porque~se o carro não vier, o cliente pode remarcar. Então você deve ter, neste bloco um marcador dizendo se o cliente compareceu ou não. Certo? Não há mais o que fazer aqui. Agora o carro chegou. O que você usará como referência para esta ordem de serviço que está iniciando? Os dados aqui devem ser pertinentes somente a este tipo de trabalho, certo? (outro bloco, ou seja, outro formulário, o que implica em outra tabela) Pelo que você descreveu até aqui eu vejo Uma tabela para clientes uma tabela para veiculos já que um cliente pode ter mais de um veículo. Uma tabela para marcador (agenda) cada marcador pode ter um veículo Uma tabela para serviço (check list e outros atributos) cada serviço deve vir de um marcador.

Oi,'Alex Mauricio' A mesagem está te falando que a tabela prjdelphi.itempedido Não existe.

Oi, 'Geomar Canjundo' Vou faze-lom pensar para achar a solução. Imagine que cada tabela é um BLOCO de formulários. Cada registro é uma folha deste bloco. Você está criando mais TRES BLOCOS ou mais UM BLOCO?

Oi, 'victor_' Procure usar JOINS para relacionar as tabelas. é mais didático e é o recomendado por SQL ANSI (o padrão para SQL) SELECT produtos.descricao FROM produtos p INNER JOIN Pedidositens pdi ON pdi.numprod = p.numprod INNER JOIN Pedidos pd ON pd.numped = pdi.numped INNER JOIN funcionarios f ON f.CPF = pd.cpf_func WHERE f.nome='MARIA'; Ligamos primeiro Produtos a itens de pedidos (PedidosItens). Depois ligamos PedidosItens a Pedidos e, por último, ligamos Pedidos a Funcionarios.

Oi, 'wilfrank' Não sei nada de PHP. Mas a instrução SQL é assim: $sql = "INSERT INTO Financeiro ( dataVencimento, desconto, valorPagar, cliente_idCliente, servicos_idServicos ) VALUES ( STR_TO_DATE(''".$this->dataVencimento."', '%d/%m/%Y'), '".$this->desconto."', '".$this->valorPagar."', '".$this->cliente_idCliente."', '".$this->servicos_idServicos."' )"; Quem tem que ser convertido é sua variável e não o campo da tabela como você estava fazendo antes.

Oi, 'buthy', Ainda não está correto. Vamos as correções: Vamos pensar um pouco:(eheh, uma analogia ao telecurso exibido pelo MEC) A)Responda as perguntas: 1) Um usuário pertence a um único nível? Pode um usuário pertencer a mais de um nível? Se a resposta for SIM para a primeira pergunta e NÃO para a segunda pergunta, então a resposta é a chave primária de usuario é composta do usr_codigo + nvl_codigo. Se não a ligação atual está correta. 2) Novamente, pergunta está ligada a um único nível? Pode uma pergunta estar ligada a mais de um nível? Se a resposta for SIM para a primeira pergunta e NÃO para a segunda pergunta, então a resposta é a chave primária de pergunta é composta do pgt_codigo + nvl_codigo. Se não a ligação atual também está correta. Qualquer que seja a resposta acima está faltando uma ligação entre nivel e pergunta_has_usuario B)As chaves primárias de dissertativa e multipla_escolha são res_codigo. A ligação entre resposta e dissertativa é um relacionamento 1:1. Neste tipo de relacionamento a a chave primaria da tabela pai é a mesma da tabela filha. Ou seja, a tabela filha dissertativa deverá possuir como chave primária res_codigo. O mesmo acontecerá no relacioamento entre resposta e multipla_escolha.

Oi, 'buthy' Não há o que desculpar. Vi de inicio que você é novato. E é assim que se aprende. Perguntando. Desse jeito o meu sistema vai ter um campo para cadastro, por exempo: Sim. Mas não entendo nada de PHP. Duvidas sobre isso pergunte na seção PHP deste forum. Eu uso uma ferramenta chamada ERWin. Ela é melhor que a DBDesigner que você está usando pois trabalho com outros tipos de banco e com modelos conceituais e logicos, também, alé do modelo físico que você está representando em seu desenho. O desenho que fiz usei uma notação para modelo lógico. No seu caso basta colocar na tabela filha a chave primaria da tabela pai. o controle de que resposta vai para qual tabela passa pelo atributo TIPO_RESPOSTA que indicará se a resposta é disseertativa ou multipla escolha. Verifique que há mais uma novidade para seu conhecimento que é a tabela RELACIONAMENTO PERGUNTA USUARIO. Esta é uma tabela ternaria que realiza o relacionamento M:N:O Muitos para muitos entre as tres tabelas USUARIO PERGUNTA e NIVEL.

Oi, 'buthy' Já percebi que você ainda está fraquinho. então vamos aos ajustes: É uma das formas de indicar um relacionamento muitos para muitos. Neste caso, haverá, fisicamente, uma tabela intermediária, com dois atributos(campos) a chave primária da tabela USUARIO e a chave primaria da tabela PERGUNTA. O relacionamento é montado na forma de 1:N entre USUARIO e RELACIONAMENTO_USUARIO_PERGUNTA e o outro relacionamento é de 1:N entre PERGUNTA e RELACIONAMENTO_USUARIO_PERGUNTA. Com isto você obtem o relacionamento N:M (muitos para muitos) entre PERGUNTA e USUARIO. Se você está dizendo que RESPOSTAS está normalizada e que há várias (N) respostas cadastradas, então a resposta é sim. pois a ligação se dará de RESPOSTA (1) para PERGUNTA (n). Ou seja, uma RESPOSTA pode estar em várias PERGUNTAS. não entendi direito essa parte... e não seria relacionamento 1:n entre resposta e multipla_escolha? porque uma pergunta pode ter várias opções. Generalização/especialização é um conceito de objeto. Indica que existe uma tabela PAI, neste caso representado por RESPOSTA e tabelas FILHAS, neste caso, representadas por DISSERTATIVA e MULTIPLA_ESCOLHA. A ligação destas tabelas filhas com a tabela pai é um relacionamento 1:1. A tabela RESPOSTA (PAI) possui a chave primária, um atributo para indicar o tipo de resposta (se dissertativa ou multipla escolha) e demais atributos que sejam comuns as tabelas filhas devem ficar aqui; Na tabela filha DISSERTATIVA você deve colocar a chave primária = a chave primaria daa tabela pai e demais atributos exclusivos desta tabela. O mesmo serve para a tabela filha MULTIPLA_ESCOLHA. Como falei antes quase certo. algumas ligações estão erradas e precisam ser reconfiguradas Por último a tabela NIVEL é uma tabela de DOMINIO que possui somente a chave primaria e a descrição do tipo de nivel veja o desenho em anexo. Modelo_1.pdf

Oi, 'buthy' Seu modelo está quse certo. Analise o que foi pedido. Um USUARIO possui um NIVEL. Logo, um NIVEL está em vários USUARIOS. (Relacionamento 1:N entre NIVEL e USUARIO) Uma pergunta possui um NIVEL. Logo, um NIVEL está em várias PERGUNTAS. (Relacionamento 1:N entre NIVEL e PERGUNTA) Um USUARIO pde responder a várias PERGUNTAS e uma PERGUNTA é dirigida a vários USUARIOS. (Relacionamento N:M entre PERGUNTA e USUARIO) Uma PERGUNTA possui uma RESPOSTA e uma RESPOSTA pode estar em várias PERGUNTAS. ((Relacionamento 1:N entre PERGUNTA e RESPOSTA) Uma RESPOSTA pode ser DISSERTATIVA ou MULTIPLA ESCOLHA. Então RESPOSTA é generalização de DISSERTATIVA e MULTIPLA ESCOLHA. DISSERTATIVA e MULTIPLA ESCOLHA são especializações de RESPOSTA (Relacionamento 1:1 entre RESPOSTA e MULTIPLA_ESCOLHA e relacionamento 1:1 entre RESPOSTA e DISSERTATIVA). Agora, corrija seu desenho.

Se você vai fazer uma atualização use o mesmo trigger que já está destinado a este fim. Caso vá fazer inclusão e/ou exclusão pode gerar os triggers pertinentes a estas instruções.

Oi, 'Leob' São dois os erros que você está cometendo. Primeiro erro: Você está tentando usar um UPDATE dentro do trigger, para a tabela que está disparando o trigger. O MySQL não permite os comandos de INSER, UPDATE e DELETE dentro do trigger, quando estes comandos se referenciam a propria tabela. Veja como você disparou um DEAD LOCK: Você acionou um update, que acionou o trigger, que acionou o update, que aciona o trigger, ..., infinitamente. Segundo erro: Você está usando o trigger como AFTER UPDATE e está tentando comparar OLD com NEW. Esta comparação não é possivel pois o OLD virou NEW após o UPDATE. Neste caso o resultado da comparação sempre será uma igualdade. O codigo correto: Antes de fazer, verifique se os atributos lim_disp e lim_utilizado são NÃO NULOS e possuem VALOR DEFAULT. É importante que seja assim. create trigger limite before Update on limite FOR EACH ROW Begin If New.lim_utilizado <> Old.lim_utilizado then SET NEW.lim_disp = OLD.lim_disp - NEW.lim_utilizado; End If; End; Tenta ai e ve se o reultado é o desejado.

Você colocou o ponto e virgula no final da instrução para avisar o mysql eu a instrução acabou? Você já testou se existe o banco criado com o comando SHOW DATABASES <nome de seu banco>;?

Oi 'btolinux' Uma instrução IF, dentro de uma storage procedure, trigger ou função, termina sempre com um END IF. Em seu caso a instução corereta seria: IF @aluno IS NULL THEN INSERT INTO alunos VALUES(null, des_aluno); SELECT MAX(pk_aluno) INTO @aluno FROM alunos; END IF;

Oi. 'Geomar Canjundo' Mostre a estrutura da tabela VIATURAS, por favor.

No momento creio que não seja necessário nehuma alteração na configuração do MySQL. Existe um tópico (que não estou conseguindo localizar agora) aqui no forum, onde eu converso com um cara de Portugal (Pedro, se não me falha a memória). Naquele tópico há várias dicas de otimização mexendo nas variáveis do MySQL. Vou procurar mais assim que tiver tempo e postarei o link aqui.

Você fará uma carga completa conforme o que você estipulou inicialmente. As próximas cargas serão baseadas em DtCorte. Com valor acima último DtCorte carregado anteriormente. Dicas para que tudo de certo. Transforme os campos DECIMAL para DOUBLE. DECIMAL é tratado como caracter e não é muito aceito pelo MySQL 4.1 ou superior. Use DtCorte como numerico. Dê preferência ao uso de uma tabela de dimensão tempo, para controlar o tempo e não a uma data colocada em sua tabela fato.

Se você está carregando estes dados em um data mart, então, presumo que esta seja a tabela "fato". Neste caso, você não pode avaliar a dimensão tempo e realizar um ETL incremental em vez de fazer nova carga do zero?

Pergunta: Se na instrução anterior eu passei as tabelas temporárias para tabelas permanentes, então por que perder tempo carregando os dados destas tabelas em outra tabela?. Você não poderia simplesmente usar este join em suas consultas?

Oi Marcelo Pelo que vejo você não vai escapar de um scantable. Pois a tarefa principal deste select é dar carga na tabela Modelagem.TbNovaModelo1 e não há nenhuma restrição de pesquisa (where) em seu select que impeça isso. Veja o código acima. Será o mesmo que:Create Table Modelagem.TbNovaModelo1 ( Select * From TbBehavior_Resume a STRAIGHT_JOIN TbCalculadas_Resume b On a.Chave = b.Chaves );