Encontrar programaticamente o conjunto mínimo de campos necessários para criar uma chave composta exclusiva

Embora comentários e srutzky ofereçam ótimos conselhos, existe uma ferramenta feita exatamente para a sua situação. O SSIS Data Profiling Taskdestina-se à identificação de chaves primárias em potencial (para várias colunas), além de fornecer muitos outros insights úteis sobre seus dados.

Basta criar um novo pacote SSIS, adicionar a tarefa e usar a interface semelhante a um assistente para criar o perfil de seus dados. Crie um novo arquivo de saída em algum lugar onde você possa acessá-lo, selecione Quick Profile...e crie o perfil das informações apropriadas do banco de dados e da tabela desejada.

Depois de terminar, execute o pacote e retorne ao componente para selecionar Open Profile Viwer...e observar todos os dados interessantes! A ferramenta me deu uma correspondência de 96% para uma das minhas tabelas de fatos para um PK de três colunas quando até 7 colunas foram solicitadas para a consideração de chave candidata (não mostrada).

Só para deixar claro, eu definitivamente concordo que as regras de negócios devem determinar a exclusividade dos dados... só porque você encontra uma combinação de colunas que se ajusta aos seus dados para exclusividade não significa necessariamente que faça algum sentido. =)

Estou criando uma chave primária composta usando uma combinação de campos das extrações que me fornecerão uma chave exclusiva para cada linha.

Hum, não é exatamente para isso que serve uma chave primária. Sim, eles identificam exclusivamente cada linha, mas também são a base dos relacionamentos de suporte para tabelas irmãs e filhas.

Existe algum tipo de script SQL que eu possa executar em uma tabela que me forneça o número mínimo de campos (nomes) que eu precisaria concatenar para obter uma chave exclusiva?

Não fora do que você já está fazendo, embora talvez de formas ligeiramente diferentes, como possivelmente carregar os dados em uma tabela sem chaves ou índices exclusivos ou restrições exclusivas definidas e, em seguida, tentar criar o PK ou Unique (Index | Constraint) em várias combinações de campos. Em ambos os casos, você provavelmente não deveria estar fazendo isso em primeiro lugar.

Existem alguns problemas com essa abordagem em geral:

• E se houver várias opções de exclusividade? Qualquer combinação de um ou mais campos individuais e/ou um ou mais conjuntos de campos múltiplos? FieldApode ser único e FieldD+ FieldHpode ser único. O que então?
• E se nenhum campo individual ou combinação de campos for exclusivo? Qual é o plano se o uso de todos os campos ainda não resultar em exclusividade?
• E quanto a dados inválidos e/ou erros em seu processo de importação? A varredura dos dados recebidos é altamente propensa a erros devido a não saber o quanto você pode confiar nos dados para começar. Seu sistema precisa entender se os dados recebidos são bons ou ruins, não apenas assumir que são bons e basear as regras de negócios em torno do que poderia facilmente ser um bug no processo de exportação do sistema externo (porque isso nunca acontece ;-) .
• Alguma dessas tabelas de importação deve estar relacionada entre si? Em caso afirmativo, tentar encontrar exclusividade programaticamente pode escolher campos diferentes para tabelas que devem se relacionar, mas agora não podem devido à exclusividade encontrada em várias combinações de campos em pelo menos uma das tabelas e o processo encontrando uma combinação incompatível antes do combinação relacionável.
• Como você está decidindo quais são os tipos? E sobre 0x02FB4C97? Isso é um VARBINARYou uma string de bytes hexadecimais? E sobre 123456? Isso é um INT, BIGINT, VARCHAR, DATETIME(no formato juliano), VARBINARY(sem a liderança , 0xmas não A- Fpara ajudar a decidir)?
• O que acontece quando os "dados" em uma ou mais colunas mudam radicalmente, mas por razões boas/naturais? E se houver um campo vazio no momento e você achar que é uma string, mas na verdade é um campo de data que ainda não foi usado ou, naturalmente, é NULLpara a exportação específica que você está procurando? Ou que tal comprimentos máximos para colunas de comprimento variável? Que tal um campo de "comentários" que eles estão usando atualmente apenas para um número de 5 dígitos, mas depois começam a usá-lo para comentários reais?
• Como @MaxVernon mencionou em um comentário sobre a pergunta, a exclusividade dos campos pode mudar à medida que novos dados chegam mais tarde, pois você realmente não conhece as regras que governam como os dados realmente existem.

Então, isso se resume a: qual é o objetivo real de definir os PKs para começar? O que você está tentando realizar fazendo isso? Existe uma razão pela qual você não apenas adiciona um IDENTITYcampo e remove duplicatas em todos os campos importados (todos menos o IDENTITYcampo)?

Você realmente precisa descobrir mais sobre a verdadeira natureza dos dados primeiro e, em seguida, criar uma tabela para armazenar os dados com chaves e restrições que correspondam a como os dados devem existir, não necessariamente como eles existem.

Não pense que existe um script para isso. Ele precisa ser decidido/definido antes que os dados sejam inseridos. Caso contrário, pode bloquear o funcionamento do seu aplicativo.

Normalmente uma tabela precisa de 1 campo para ser única. Somente se você criar uma tabela para vincular 2 tabelas diferentes (para uma relação N-para-M), precisará das chaves M e N para torná-la única. Há exceções, mas cabe ao designer decidir quais campos compõem a chave exclusiva. Os dados podem crescer e a exclusividade também.

Embora eu concorde com algumas postagens de que as chaves devem ser definidas pelo caso de negócios, isso me parece ser a visão da perspectiva de um administrador de banco de dados.

Do ponto de vista da análise de dados, onde você pode enfrentar um conjunto de dados estáticos que deseja analisar, essas combinações de teclas podem ser interessantes e úteis. Imagine uma situação em que você encontrou um subconjunto de dados e está se perguntando quais são os campos-chave que o determinam. Por exemplo, vamos supor que você encontrou um subconjunto de pedidos para alguma combinação de produtos e se pergunta quais são os parâmetros que melhor definem esses pedidos.
Claro que você pode defini-los por seus IDs de pedido, mas pode haver uma combinação de teclas menor e mais interessante, como a idade do cliente e a hora em que o pedido foi feito.

Esse é um problema típico de agrupamento/classificação.