3.2.1 - Conflitos de chave primária e Identificador de campo único

O identificador de campo único (Unique Identifier – UID) é um tipo de dado gerado aleatoriamente pelo SGBD onde não é possível gerar dois valores idênticos de nenhuma forma.

Esse tipo de dados é composto por letras e números, como você pode ver neste exemplo: E75B92A3-3299-4407-A913-C5CA196B3CAB.

Os identificadores de campo único são necessários para montar sites SGBDDs onde há vários sites publicadores para se evitar conflitos de chave primária. Vamos entender o porquê disso vendo um exemplo.

Suponha que você tenha uma tabela chamada VENDA, com os campos ID_Venda (Inteiro), ValorVenda (Dinheiro), DataVenda (Data) e ID_Cliente (Inteiro). Essa tabela VENDA tem, associada a ela, uma outra tabela denominada ITENS_DE_VENDA que corresponde aos produtos vendidos e que para nosso exemplo não necessita de detalhamento.

Vamos imaginar que há um SGBDD montado com um replicador mestre e cinco replicadores escravos semelhantes ao exemplo que passamos na seção anterior. Imagine que seja feita uma venda em São Paulo. A tabela de VENDA do SGBDD de São Paulo receberá um registro de ID_Venda = 1, ValorVenda = R$ 100, DataVenda = 10/12/2015 e ID_Cliente = 8. Esse registro será enviado para o replicador mestre e lá será armazenado da mesma forma.

Imagine agora que a filial do Rio de Janeiro faça uma venda também. A tabela de VENDA do SGBDD do Rio de Janiero receberá um registro de ID_Venda = 1, ValorVenda = R$ 80, DataVenda = 10/12/2015 e ID_Cliente = 3. Esse registro será enviado para o replicador mestre e lá chegando entrará em conflito com a venda feita em São Paulo, já que ambos possuem o mesmo ID_Venda.

Para resolver esse conflito, modelos de dados SGBDD podem criar chaves primárias compostas (por exemplo, usando o ID_Venda + ID_Regiao, para identificar de qual região veio a venda), ou usando um identificador único para o registro, ao invés do tipo INTEIRO, utiliza-se o tipo UID.

Ao usar o tipo UID garante-se que NUNCA haverá conflito de chave primária, pois nunca haverá dois registros com mesmo identificador. O mesmo conceito poderia ser implementado também para identificar clientes, evitando conflito de ID de clientes. Saiba+

Saiba+

Expandindo essa ideia, você perceberá que praticamente todas as tabelas que podem possuir conteúdo diferenciado em uma arquitetura de SGBDD poderiam se beneficiar do tipo UID para identificar esses registros. Tabelas que têm conteúdo idêntico, por exemplo, tabelas de Unidades da Federação, não precisam desse recurso, pois não haverá conflito. Exemplo: a UF RJ receberá o ID_UF = 3 em todos os sites.