Por favor, RFC 1855!
Em Sex, 2007-08-10 às 13:53 -0300, Josir Gomes escreveu:
> Quando eu falei em mudanças Leandro, eu não quis falar no conteúdo da
> chave mas no próprio conceito, isto é,
> quando o ambiente nos diz que a chave não representa mais unicamente
> um registro. Nesse caso, temos que alterar a modelagem. Quer um
> exemplo:
>
> Uma empresa sempre trabalhou com NFs com a chave (FILIAL SERIE
> NUMERO). Entretanto, com o advento das NF eletrônicas, a numeração foi
> alterada e não existe mais o conceito de série e além disso o número
> passou de 6 para 10 algorismos. Sem falar que a numeração vai começar
> de novo do zero ! Já pensou no transtorno?
Já pensou que o modelo está errado?
Obviamente, você tem duas entidades aí diferentes: a NF e a NFe.
Você pode até criar uma visão que seja uma união das duas relações.
> Achei o exemplo do site bem inocente. Ora, e se for obrigatório ter 2
> Joshua Drakes no banco??? Como resolver?
Obviamente o exemplo é inocente. É apenas um exemplo.
Você resolve adicionando atributos identificadores. Tem de haver
algum, no caso obviamente não será prático em SQL: nascimento, filiação
&c.
A solução correta aí não é viável em SQL: a chave artificial deveria
ser ocultada do usuário no modelo lógico, sendo visível somente ao DBA
no modelo físico.
De qualquer maneira, o essencial permanece: num caso desses, é
recomendável uma chave artificial em SQL — *mas nunca à exclusão das
chaves candidatas*!
> No caso da exclusão, vc tem que dar recursos visuais para que o
> usuário possa selecionar qual a pessoa que ele quer. Na verdade, no
> mundo real, nunca se iria excluir uma pessoa do banco. O correto seria
> atribuir um status de Inativo para ele para preservar todo o histórico
> transacional dessa pessoa. Por isso achei um exemplo muito simplista.
Em primeiro lugar, muitas vezes percebem-se problemas desses só quando
a quantidade de dados já é muito grande para pedir ação de usuário. E
muitas vezes o usuário não conhece os dados suficientemente, caso em que
o pessoal técnico tem de sujar as mãos, mesmo incorrendo a ira dos
usuários.
Segundo, o caso não é de ‘qual a pessoa que ele quer’, mas que pode ser
a _mesma pessoa_ cadastrada n vezes.
Terceiro, sendo um erro de entrada de dados, não existe histórico a
preservar ou eliminar, mas consolidar.
> Se existem dados duplicados, então a modelagem foi mal feita. A chave
> candidata tem que permanecer apenas na tabela que é identificada por
> ela. Mesmo quando ela caducar, ou seja, quando ela deixar de dar
> unicidade ao registro, ela deve permanecer apenas na tabela de origem.
Por que tem? Não faz sentido.
> > 1) A chave artificial será a primária, o que vai obscurecer a
> >informação semântica do modelo e forçar mais junções. Definir a
> >artificial como alternativa faz pouco sentido, a menos que não haja
> >absolutamente chave candidata simples.
>
> 1. Opa! Informações semanticas devem ser mantidas no modelo lógico,
> não no físico!!!
Errado… informações semânticas têm que ir para o modelo lógico, ou
serão perdidas na implementação, que é necessariamente exclusivamente
física.
O contrário é verdadeiro: detalhes físicos (escolha de chave primária
entre as candidatas) é que não devem contaminar o modelo lógico.
Infelizmente o SQL e as ferramentas de DER não ajudam nisso.
> 2. Concordo entretanto que as surrogate keys forçam mais junções mas o
> custo delas é muito menor que o custo de alterações no modelo.
Só se a modelagem foi mal feita de início, como mostrei acima.
O custo não é só das junções, lembre-se… modelo, armazenamento de maßa
e volátil, E/S.
> > 2) A chave artificial engordará o modelo, tornando-o mais complexo e
> >indireto, o armazenamento em disco, a atividade de E/S e o consumo de
> >cache, tanto pela existência de um atributo a mais na tabela quanto de
> >um índice a mais, o qual tem de ser não apenas lido como também escrito
> >? e isso não substituindo as chaves candidatas, mas suplementando-as.
>
> Concordo. Mas é um preço bem barato a ser pago pela maior reusabilidade do
> modelo.
Essa ‘maior reusabilidade’ é somente por ocultar problemas de
modelagem, que são necessariamente sérios!
> > Existe apenas uma vantagem real:
> >
> > a) Por causa de uma restrição arbitrária do SQL, no caso de uma tabela
> >relativamente menor que é mãe de uma ou mais tabelas significativamente
> >maiores, e realmente enormes (coisa de GiB ou TiB), a exportação de uma
> >chave estrangeira artificial simples pode ser mais econômica em
> >armazenamento, cache e E/S que o de chaves candidatas, *se* não houver
> >absolutamente chave candidata simples.
>
> Não acho que essa seja uma vantagem significativa. Nas máquinas
> atuais, esse custo é ínfimo.
Depende da maßa de dados. Mas é a única vantagem real.
> De qq forma, em modelos reais complexos, é difícil encontrar chaves
> candidatas com um único atributo.
E daí? Qual o problema de chaves compostas, fora o descrito em (a)
acima?
> Vc não pode comparar a modelagem do dicionário de dados com a de um
> ERP. São objetivos diferentes.
Mas ambas são ruins.
> A modelagem do dicionário de dados do Oracle, por exemplo, visa máxima
> performance em detrimento de um melhor entendimento. Agora dizer que
> os ERPs mais utilizados no mundo não são parametros para modelagem,
> acho um pouco exagerado.
Você já trabalhou com algum? Eu já.
> > Conheço os argumentos, e já vi problemas dos dois lados? mas me assusta
> >recorrer a referências ?pragmáticas?, que tendem a se limitar a
> >problemáticas geradas pelo padrão SQL que é ruim ou mesmo por suas
> >implementações que são piores ainda. Melhor recorrer a textos mais
> >conceituais, como os do Date, do Darwen, do McGoveran e do Pascal que
> >sempre cito.
>
> Não entendi: quem cita SQL em todo a teoria relacional não é o
> Date ???
Eu é que não entendi o que você quis dizer.
O Date é justamente (um dos) quem demonstra que o SQL não é relacional.
> Inclusive, em artigos posteriores ao livro, Date citou positivamente
> inúmeras vezes as surrogate keys (sem dar preferência para elas). Mas
> concordo com vc, sou pragmático. Muito pragmático.
Vide que o conceito dele de chaves artificiais é físico. Desapareceria
muito da problemática descrita se o SQL permitisse a ocultação do modelo
físico. No conceito original toda tabela poderia ter chave artificial,
sem alterar o modelo lógico.
> > Por exemplo, os conceitos centrais são de normalização, não de
> >refatoração. Refatoração tem a ver apenas com problemas físicos, de
> >implementação; não deveria dizer nada contra a normalização.
>
> Peraí, em nenhum momento falei que não tinha que ter normalização!
Uma chave artificial no modelo lógico, como é obrigatório em SQL, cria
dependência funcional e, portanto, viola a normalização.
Ou estou enganado? De qualquer maneira, mesmo que esteja, é feio…
--
Leandro Guimarães Faria Corcete DUTRA <[EMAIL PROTECTED]>
Atech Fundação Aplicação de Tecnologias Críticas SP, BR
msnim:[EMAIL PROTECTED]
xmpp:[EMAIL PROTECTED] +55 (11) 3040 7300 r151
- - - - -
Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou
privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber
esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas
ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta
mensagem por engano, por favor avise imediatamente o remetente, respondendo o
e-mail e em seguida apague-o. Agradecemos sua cooperacao.
Privacy Policy: This message may contain confidential and/or privileged
information. If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose or take any action based on this
message or any information herein. If you have received this message in error,
please advise the sender immediately by reply e-mail and delete this message.
Thank you for your cooperation.
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
