Criar regras de qualidade de dados

A qualidade dos dados mede a integridade dos dados numa organização. Pode avaliar a qualidade dos dados através da utilização de classificações de qualidade de dados. Catálogo unificado do Microsoft Purview gera pontuações com base na avaliação dos dados em relação às regras que definir.

As regras de qualidade dos dados são diretrizes essenciais que as organizações estabelecem para garantir a exatidão, consistência e integridade dos dados. Estas regras ajudam a manter a integridade e fiabilidade dos dados.

Seguem-se alguns aspetos fundamentais das regras de qualidade dos dados:

• Precisão: os dados devem representar com precisão entidades do mundo real. O contexto é importante! Por exemplo, se estiver a armazenar endereços de clientes, certifique-se de que correspondem às localizações reais.

• Conclusão: esta regra identifica dados vazios, nulos ou em falta. Valida que todos os valores estão presentes, embora não necessariamente corretos.

• Conformidade: esta regra garante que os dados seguem padrões de formatação de dados, como a representação de datas, endereços e valores permitidos.

• Consistência: esta regra verifica se valores diferentes do mesmo registo estão em conformidade com uma determinada regra e que não existem contradições. A consistência dos dados garante que as mesmas informações são representadas uniformemente em registos diferentes. Por exemplo, se tiver um catálogo de produtos, os nomes e descrições de produtos consistentes são cruciais.

• Linha cronológica: esta regra tem como objetivo garantir que os dados estão acessíveis no mais curto espaço de tempo possível. Garante que os dados estão atualizados.

• Exclusividade: esta regra verifica se os valores não estão duplicados. Por exemplo, se for suposto existir apenas um registo por cliente, não existem vários registos para o mesmo cliente. Cada cliente, produto ou transação deve ter um identificador exclusivo.

Ciclo de vida da qualidade de dados

A criação de regras de qualidade de dados é o sexto passo no ciclo de vida da qualidade de dados. Os passos anteriores são:

1. Atribua permissões de administrador de qualidade de dados aos utilizadores no Catálogo unificado para utilizar todas as funcionalidades de qualidade de dados.
2. Registe e analise uma origem de dados no Mapa de Dados do Microsoft Purview.
3. Adicione o recurso de dados a um produto de dados.
4. Configure uma ligação de origem de dados para preparar a sua origem para a avaliação da qualidade dos dados.
5. Configure e execute a criação de perfis de dados para um recurso na sua origem de dados.

Funções necessárias

• Para criar e gerir regras de qualidade de dados, os utilizadores precisam da função de responsável pela qualidade dos dados.
• Para ver as regras de qualidade existentes, os utilizadores precisam da função de leitor de qualidade de dados.

Ver regras de qualidade de dados existentes

1. Em Catálogo unificado, selecione Gestão do Estado de Funcionamento e, em seguida, selecione Qualidade dos dados.

2. Selecione um domínio de governação e, em seguida, selecione um produto de dados.

3. Selecione um recurso de dados na lista Recursos de dados.

4. Selecione o separador Regras para ver as regras existentes aplicadas ao recurso.

5. Selecione uma regra para navegar no histórico de desempenho da regra aplicada para o recurso de dados selecionado.

   

Regras de qualidade de dados disponíveis

Qualidade de Dados do Microsoft Purview ativa a configuração das seguintes regras. Estas regras estão disponíveis de forma inicial e oferecem uma forma de baixo código para não utilizar código para medir a qualidade dos seus dados.

Atualização

A regra de atualização verifica se o recurso é atualizado dentro do tempo esperado. A atualização é determinada pela seleção das datas da última modificação.

Valores exclusivos

A regra Valores exclusivos indica que todos os valores na coluna especificada têm de ser exclusivos. Todos os valores exclusivos são tratados como pass e os valores que não são exclusivos são tratados como falha. Se a regra Campos vazios/em branco não estiver definida na coluna, os valores nulos ou vazios serão ignorados para efeitos desta regra.

Correspondência de formato de cadeia

A regra De correspondência de formato verifica se todos os valores na coluna são válidos. Se não definir a regra Campos vazios/em branco numa coluna, a regra ignora valores nulos ou vazios.

Esta regra pode validar cada valor na coluna ao utilizar três abordagens diferentes:

1. Enumeração: esta abordagem utiliza uma lista de valores separada por vírgulas. Se o valor avaliado não corresponder a um dos valores listados, o marcar falha. Pode escapar de vírgulas e barras invertidas com uma barra invertida (\). Portanto, a \, b, c contém dois valores: o primeiro é a , b e o segundo é c.

1. Como Padrão: like(<i>&lt;string&gt;</i> : string, <i>&lt;pattern match&gt;</i> : string) => boolean o padrão é uma cadeia que a regra corresponde literalmente. As exceções são os seguintes símbolos especiais: _ corresponde a qualquer caráter na entrada (semelhante a em posix expressões regulares) % corresponde a . zero ou mais carateres na entrada (semelhante a . em posix expressões regulares). O caráter de escape é . Se um caráter de escape preceder um símbolo especial ou outro caráter de escape, o caráter seguinte é correspondido literalmente. É inválido escapar a qualquer outro caráter.

   • like('icecream', 'ice%') -> true

   

2. Expressão Regular: regexMatch(<i>&lt;string&gt;</i> : string, <i>&lt;regex to match&gt;</i> : string) => boolean

   Verifica se a cadeia corresponde ao padrão regex especificado. Utilize <regex>(aspas anteriores) para corresponder a uma cadeia sem escapar.

   • regexMatch('200.50', '(\\d+).(\\d+)') -> true
   • regexMatch('200.50', `(\d+).(\d+)`) -> true

   

Correspondência do tipo de dados

A regra De tipo de dados corresponde especifica o tipo de dados esperado para a coluna associada. Uma vez que o motor de regra é executado em várias origens de dados diferentes, não pode utilizar tipos nativos como BIGINT ou VARCHAR. Em vez disso, utiliza o seu próprio sistema de tipo e traduz tipos nativos para este sistema. Esta regra indica ao motor de análise de qualidade qual dos tipos incorporados deve utilizar para o tipo nativo. O sistema de tipo de dados provém do sistema de tipo microsoft Azure Fluxo de Dados utilizado no Azure Data Factory.

Durante uma análise de qualidade, o motor testa todos os tipos nativos em relação ao tipo de correspondência de tipo de dados. Se não conseguir traduzir o tipo nativo para o tipo de correspondência do tipo de dados, trata essa linha como um erro.

Duplicar linhas

A regra Linhas duplicadas verifica se a combinação dos valores na coluna é exclusiva para cada linha na tabela.

No exemplo seguinte, a expectativa é que a concatenação de CompanyName, CustomerID, EmailAddress, FirstName e LastName produza um valor exclusivo para todas as linhas na tabela.

Cada recurso pode ter zero ou uma instância desta regra.

Campos vazios/em branco

A regra Campos vazios/em branco afirma que as colunas identificadas não devem conter valores nulos. Para cadeias, a regra também não permite valores vazios ou apenas de espaço em branco. Durante uma análise da qualidade dos dados, o motor trata qualquer valor nesta coluna que não seja nulo como correto. Esta regra afeta outras regras, como valores exclusivos ou Regras de correspondência de formato . Se não definir esta regra numa coluna, essas regras ignoram automaticamente quaisquer valores nulos quando são executados nessa coluna. Se definir esta regra numa coluna, essas regras examinam valores nulos ou vazios nessa coluna e consideram-nos para efeitos de classificação.

Pesquisa de tabelas

A regra de pesquisa tabela examina cada valor na coluna onde define a regra e compara-a com uma tabela de referência. Por exemplo, uma tabela primária tem uma coluna denominada "localização" que contém cidades, estados e códigos postais na forma "cidade, distrito zip". Uma tabela de referência denominada "citystate" contém todas as combinações legais de cidades, estados e códigos postais suportados no Estados Unidos. O objetivo é comparar todas as localizações na coluna atual com essa lista de referência para garantir que apenas são utilizadas combinações legais.

Para configurar esta regra, introduza o nome "citystatezip" na caixa de diálogo de recursos de pesquisa. Em seguida, selecione o elemento pretendido e a coluna com a qual pretende comparar.

Regras personalizadas

A regra Personalizada permite-lhe especificar regras que validam linhas com base num ou mais valores nessa linha. Pode utilizar linguagem de expressão regular, expressão Azure Data Factory e linguagem de expressão SQL para criar regras personalizadas.

Uma regra personalizada tem três partes:

1. Expressão de linha: esta expressão booleana aplica-se a cada linha aprovada pela expressão de filtro. Se esta expressão devolver verdadeiro, a linha passa. Se devolver false, a linha falhará.

2. Expressão de filtro: esta condição opcional restringe o conjunto de dados no qual a condição de linha é avaliada. Para a ativar, selecione a caixa de verificação Utilizar expressão de filtro . Esta expressão devolve um valor Booleano. A expressão de filtro aplica-se a uma linha e, se devolver verdadeiro, essa linha é considerada para a regra. Se a expressão de filtro devolver falso para essa linha, significa que a linha é ignorada para efeitos desta regra. O comportamento predefinido da expressão de filtro é transmitir todas as linhas, pelo que, se não especificar uma expressão de filtro, todas as linhas são consideradas.

3. Expressão nula: verifica a forma como os valores NULL devem ser processados. Esta expressão devolve um Booleano que processa casos em que os dados estão em falta. Se a expressão devolver verdadeiro, a expressão de linha não é aplicada.

Cada parte da regra funciona de forma semelhante às condições de Qualidade de Dados do Microsoft Purview existentes. Uma regra só é aprovada se a expressão de linha for avaliada como VERDADEIRO para o conjunto de dados que corresponde à expressão de filtro e processar valores em falta, conforme especificado na expressão nula.

Exemplo: uma regra para garantir que "fareAmount" é positivo e que "tripDistance" é válido:

• Expressão de linha: tripDistance > 0 AND fareAmount > 0
• Expressão de filtro: paymentType = "CRD"
• Expressão nula: tripDistance IS NULL

Criar uma regra personalizada

1. No Catálogo unificado, aceda a Gestão> de estado de funcionamentoQualidade dos dados.
2. Selecione um domínio de governação, selecione um produto de dados e, em seguida, selecione um recurso de dados.
3. No separador Regras , selecione Nova regra.

Criar uma regra personalizada com Azure Data Factory expressão (ADF)

1. Para criar a regra com expressão regular ou expressão do ADF, selecione Personalizar na lista de opções da regra e, em seguida, selecione Seguinte.

2. Adicione Nome da regra e Descrição e, em seguida, selecione Criar.

   

Exemplos de regras personalizadas

A expressão de filtro e a expressão de linha são definidas com a linguagem de expressão Azure Data Factory, com o idioma definido aqui. No entanto, nem todas as funções definidas para a linguagem de expressão genérica do ADF estão disponíveis. A lista completa de funções disponíveis está na lista Funções disponível na caixa de diálogo de expressão. As seguintes funções definidas aqui não são suportadas: isDelete, isError, isIgnore, isInsert, isMatch, isUpdate, isUpsert, partitionId, pesquisa em cache e funções window.

Criar uma regra personalizada com a expressão SQL

As regras SQL personalizadas no Qualidade de Dados do Microsoft Purview fornecem uma forma flexível de definir verificações de qualidade de dados com predicados do Spark SQL. Esta funcionalidade permite que os utilizadores criem regras diretamente no Spark SQL para cenários de validação avançados. Só é necessária uma expressão de linha; as expressões filter e null são opcionais para personalização adicional. Utilize regras SQL personalizadas para abordar requisitos empresariais complexos e melhorar a qualidade dos dados, tirando partido de todas as capacidades do Spark SQL. As regras SQL personalizadas permitem uma validação de dados complexa que pode não ser possível apenas com expressões do ADF. Ao escrever predicados do Spark SQL, pode satisfazer necessidades empresariais exclusivas e manter padrões de qualidade de dados elevados.

1. Para criar a regra com a linguagem de expressão SQL, selecione Personalizado (SQL) na lista de opções da regra e, em seguida, selecione Seguinte.

2. Adicione Nome da regra e Descrição e, em seguida, selecione Criar.

   Cenário	Expressões
   Valida padrões de cadeia corretos (por exemplo, rateCodeId começando com "1" e numérico) e filtra por tipos de pagamento válidos.	Row: rateCodeId RLIKE '^1[0-9]+$' Filter: paymentType IN ('CRD', 'CSH') Null: rateCodeId IS NULL
   Garante comparações de colunas corretas entre puLocationId e doLocationId e tarifa em comparação com a distância da viagem.	Row: puLocationId > doLocationId AND fareAmount > tripDistance * 10' Filter: paymentType <> 'CSH'' Null: tripDistance IS NULL
   Verifica se o paymentType está numa determinada lista (Cartão, Dinheiro), filtrando linhas com base em montantes de tarifas.	Row: paymentType IN ('CRD', 'CSH')' Filter: fareAmount >= 50 Null: paymentType IS NULL
   Garante que a distância está dentro de um intervalo inclusivo (5-10 milhas) ao processar NULL e filtrar tipos de pagamento válidos.	Row: tripDistance BETWEEN 5 AND 10 Filter: paymentType <> 'CRD' Null: tripDistance IS NULL
   Garante que o conjunto de dados não excede um valor NULL de 20% para fareAmount.	Row: (SELECT avg(CASE WHEN fareAmount IS NULL THEN 1 ELSE 0 END) FROM nycyellowtaxidelta1BillionPartitioned) < 0.20' Filter: vendorID IN ('VTS', 'CMT')
   Verifica se existem, pelo menos, 2 valores paymentType distintos no conjunto de dados.	Row: (SELECT count(DISTINCT paymentType) FROM nycyellowtaxidelta1BillionPartitioned) >= 2 Filter: vendorID IN ('1', '2')
   Garante que a quantidade média de tarifas do conjunto de dados está dentro de um intervalo especificado (80 <= média <= 140).	Row: (SELECT avg(fareAmount) FROM nycyellowtaxidelta1BillionPartitioned) BETWEEN 80 AND 140 ' Filter: paymentType IN ('CRD', 'CSH')
   Garante que a função tripDistance máxima no conjunto de dados é <= 10 milhas.	Row: (SELECT max(tripDistance) FROM nycyellowtaxidelta1BillionPartitioned) <= 10.0 Filter: vendorID IN ('VTS', 'CMT')
   Garante que o desvio-padrão de fareAmount é inferior a um determinado limiar (< 30).	Row: (SELECT stddev_samp(fareAmount) FROM nycyellowtaxidelta1BillionPartitioned) < 30.0 Filter: vendorID IN ('VTS', 'CMT')
   Garante que o valor mediano da tarifa do conjunto de dados está dentro do limiar especificado (<= 15).	Row: (SELECT percentile_approx(fareAmount, 0.5) FROM nycyellowtaxidelta1BillionPartitioned) <= 15.0 Filter: vendorID IN ('VTS', 'CMT')
   Garante que vendorId é exclusivo no conjunto de dados dentro de paymentType específico.	Row: COUNT(1) OVER (PARTITION BY vendorID) = 1 Filter: paymentType IN ('CRD', 'CSH','1', '2') Null: vendorID IS NULL
   Garante que a combinação de puLocationId e doLocationId é exclusiva no conjunto de dados.	Row: COUNT(1) OVER (PARTITION BY puLocationId, doLocationId) = 1 Filter: paymentType IN ('CRD', 'CSH') Null: puLocationId IS NULL OR doLocationId IS NULL
   Garante que vendorId é exclusivo por paymentType.	Row: COUNT(1) OVER (PARTITION BY paymentType, vendorID) = 1 ,Filter: rateCodeId < 25, Null: vendorID IS NULL
   Garante que tpepPickupDateTime da linha é maior do que um determinado carimbo de data/hora de limite.	Row: tpepPickupDateTime >= TIMESTAMP '2014-01-03 00:00:00' Filter: paymentType IN ('CRD', 'CSG', '1', '2') Null: tpepPickupDateTime IS NULL
   Cada viagem tem de estar concluída no prazo de 1 hora	Row: (unix_timestamp(tpepDropoffDateTime) - unix_timestamp(tpepPickupDateTime)) <= 3600 Filter: paymentType IN ('CRD', 'CSH', '1', '2') Null: tpepPickupDateTime IS NULL OR tpepDropoffDateTime IS NULL
   Mantém apenas a viagem de tarifa mais alta por localização de recolha.	Row: row_number() OVER (PARTITION BY puLocationId ORDER BY fareAmount DESC) = 1, Filter: paymentType IN ('CRD', 'CSH','1','2') AND tripDistance > 0, Null: fareAmount IS NULL OR puLocationId IS NULL
   Todas as tarifas mais altas atadas por passe de localização de recolha (não apenas primeiro por row_number).	Row: rank() OVER (PARTITION BY puLocationId ORDER BY fareAmount DESC) = 1 Filter: paymentType IN ('CRD', 'CSH','1','2') AND tripDistance > 0 Null: fareAmount IS NULL OR puLocationId IS NULL
   A tarifa não pode diminuir ao longo do tempo para cada tipo de pagamento.	Row: fareAmount >= lag(fareAmount) OVER (PARTITION BY paymentType ORDER BY tpepPickupDateTime) Null: tpepPickupDateTime IS NULL OR fareAmount IS NULL
   Tarifa de cada linha dentro de 10 da média do grupo por tipo de pagamento.	Row: abs(fareAmount - avg(fareAmount) OVER (PARTITION BY paymentType)) <= 10 Filter: paymentType IN ('CRD', 'CSH','1','2') Null: fareAmount IS NULL
   O total de distâncias de viagem não pode exceder os 30 km.	Row: sum(tripDistance) OVER (ORDER BY tpepPickupDateTime ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) <= 20 Filter: paymentType = '1' Null: tripDistance IS NULL
   Verifica se a tarifa de cada viagem está acima da média global dos fornecedores elegíveis.	Row: fareAmount > (SELECT avg(fareAmount) FROM nycyellowtaxidelta1BillionPartitioned) Filter: vendorID IN ('VTS', 'CMT') Null: fareAmount IS NULL
   Verifica se a tripDistância de cada linha é maior do que o mínimo para o respetivo paymentType (Cartão/Dinheiro).	Row: tripDistance > (SELECT min(u.tripDistance) FROM (SELECT tripDistance, paymentType AS pt FROM nycyellowtaxidelta1BillionPartitioned) u WHERE u.pt = paymentType) Filter: paymentType IN ('CRD', 'CSH') Null: tripDistance IS NULL
   Para cada viagem, verifica se a tarifa está acima da média do seu tipo de pagamento	Row: fareAmount > (SELECT avg(u.fareAmount) FROM (SELECT fareAmount, paymentType AS pt FROM nycyellowtaxidelta1BillionPartitioned) u WHERE u.pt = paymentType) Filter: paymentType IN ('CRD','CSH','1','2') AND vendorID IN ('VTS','CMT') Null: fareAmount IS NULL
   Valida se a coluna fareAmount (numérica) pode ser representada corretamente como uma cadeia que corresponde ao padrão numérico (números positivos com decimal opcional). Esta ação utiliza a função cast como fareAmount é uma coluna numérica.	Row: CAST(fareAmount AS STRING) RLIKE '^[0-9]+(\.[0-9]+)?$' Filter: paymentType IN ('CRD', 'CSH') Null: fareAmount IS NULL
   Garante que tpepPickupDateTime é um carimbo de data/hora válido no formato yyyy-MM-dd HH:mm:ss. Esta coluna já está no formato DATETIME	Row: to_timestamp(tpepPickupDateTime, 'yyyy-MM-dd HH:mm:ss') IS NOT NULL Filter: paymentType IN ('CRD', 'CSH') Null: tpepPickupDateTime IS NULL
   Garante que os valores paymentType são normalizados para minúsculas e não têm espaços à esquerda ou à direita.	Row: lower(trim(paymentType)) IN ('card','cash') AND length(trim(paymentType)) > 0 Null: paymentType IS NULL OR trim(paymentType) = ''
   Calcula com segurança a proporção de fareAmount para tripDistance, garantindo que a divisão por zero não ocorre ao verificar primeiro se tripDistance > 0.	Row: CASE WHEN tripDistance > 0 THEN fareAmount / tripDistance ELSE NULL END >= 10 Filter: tripDistance > 0 AND vendorID IN ('VTS', 'CMT')
   Demonstra como a coalesce pode substituir valores nulos por valores predefinidos (por exemplo, 0,0) e garante que apenas são devolvidas linhas válidas.	Row: coalesce(fareAmount, 0.0) >= 5 Filter: paymentType IN ('CRD','CSH')

Melhores práticas para escrever regras SQL personalizadas

• Mantenha as expressões simples. Tem como objetivo escrever expressões claras e simples que são fáceis de manter.
• Utilize funções SQL do Spark incorporadas. Utilize a biblioteca avançada de funções do SQL do Spark para manipulação de cadeias, processamento de datas e operações numéricas para minimizar erros e melhorar o desempenho.
• Teste primeiro com um pequeno conjunto de dados. Valide regras num pequeno conjunto de dados antes de as aplicar em escala para identificar potenciais problemas mais cedo.

Limitações conhecidas e considerações para regras de expressões SQL

Referências de colunas ambíguas e sombra de colunas

• Problema: quando uma coluna aparece na consulta externa e na subconsulta (ou em diferentes partes da consulta) com o mesmo nome, o Spark SQL poderá não conseguir resolve que coluna utilizar. Este problema resulta em erros lógicos ou na execução incorreta de consultas. Este problema pode surgir em consultas aninhadas, subconsultas ou associações, levando à ambiguidade ou à sombra.

• Ambiguidade: ocorre quando um nome de coluna está presente na consulta externa e na subconsulta sem qualificação clara, o que faz com que o Spark SQL não tenha a certeza sobre a coluna a referenciar.

• Sombra: refere-se a quando uma coluna na consulta externa é "substituída" ou "sombreada" pela mesma coluna na subconsulta, fazendo com que a referência externa seja ignorada.

  Expressão de Exemplo:

  distance_km > 
  ( 
  SELECT min(distance_km) 
  FROM Tripdata t  
  WHERE t.payment_type = payment_type -- ambiguous outer reference  
  )
  

• Problema: as payment_type não qualificadas são resolvidas para o âmbito mais próximo que tem uma coluna desse nome, ou seja, a t.payment_type interna e não a payment_type da linha externa. Isto transforma o predicado em t.payment_type = t.payment_type (sempre VERDADEIRO), para que a sua subconsulta se torne um mínimo global em vez de um min de grupo.

• Solução: para resolve esta ambiguidade e evitar a sombra de colunas, mude o nome da coluna interna na subconsulta, garantindo que a payment_type da consulta externa permanece inequívoca.

Expressão Corrigida:

  distance_km > 
  ( 
  SELECT min(u.distance_km) 
  FROM ( 
  SELECT distance_km, payment_type AS pt 
  FROM Tripdata 
  ) u 
   WHERE u.pt = payment_type   -- this `payment_type` now binds to OUTER row 
  )

• Na subconsulta, a coluna payment_type é aliasada como pt (ou seja, payment_type AS pt) e you.pt é utilizada na condição.
• Na consulta externa, a payment_type original pode agora ser claramente referenciada e o Spark SQL resolve-a corretamente como a payment_type externa.

Operações de janela (consideração de desempenho)

• As operações de janela, como ROW_NUMBER() e RANK() podem ser dispendiosas, especialmente para grandes conjuntos de dados. Utilize-os criteriosamente e teste o desempenho em conjuntos de dados mais pequenos antes de os aplicar em escala. Considere utilizar PARTIÇÃO POR para reduzir o âmbito de dados.

O nome da coluna está a escapar no SPARK SQL

• Se os nomes das colunas contiverem carateres especiais (por exemplo, espaços, hífenes ou outros carateres não alfanuméricos), estes têm de ser escapados através de acentos anteriores.
• Exemplo se o nome da coluna for order-id e a regra tiver de ser superior a 10.
• Expressão incorreta: order-id > 10
• Expressão correta: `order-id`> 10

Referência do nome do recurso de dados em expressões

Ao referenciar o recurso de dados em expressões SQL, tem de seguir regras de limpeza específicas. O nome do recurso de dados original não precisa de ser atualizado, mas o nome do recurso de dados referenciado nas expressões SQL tem de ser limpa para cumprir os seguintes critérios:

Se o nome do recurso de dados já seguir estas diretrizes (ou seja, não contiver carateres especiais, carateres de sublinhado à esquerda/à direita e estiver dentro do limite de 64 carateres), pode ser utilizado tal como está nas expressões SQL sem qualquer modificação.

Como limpar um nome de conjunto de dados

Siga estes passos para garantir que o nome do conjunto de dados é válido para expressões SQL:

1. Remover carateres especiais: remova todos os carateres exceto letras, números e carateres de sublinhado.
2. Cortar carateres de sublinhado: remova os carateres de sublinhado à esquerda ou à direita.
3. Truncar: se o nome resultante exceder 64 carateres, trunque-o para se ajustar ao limite de 64 carateres.

Exemplo: Nome do recurso de dados f07d724d-82c9-4c75-97c4-c5baf2cd12a4.parquet

1. Remover carateres especiais: f07d724d82c94c7597c4c5baf2cd12a4parquet
2. Cortar carateres de sublinhado: (N/D neste caso, uma vez que não existem carateres de sublinhado à esquerda ou à direita.)
3. Truncar: o nome resultante tem 54 carateres de comprimento, o que está abaixo do limite de 64 carateres.

Nome de referência final do SQL: f07d724d82c94c7597c4c5baf2cd12a4parquet

As associações não são suportadas

As regras SQL personalizadas no Qualidade de Dados do Microsoft Purview não suportam associações. As regras têm de funcionar num único conjunto de dados. Não pode associar várias tabelas ou conjuntos de dados ao escrever estas regras personalizadas.

Operações SQL não suportadas (DML, DCL e SQL prejudicial)

As regras SQL personalizadas não suportam operações DML (Data Manipulation Language) ou Data Control Language (DCL), tais como INSERT, UPDATE, DELETE, GRANT e outras operações de SQL prejudiciais, como TRUNCATE, DROP e ALTER. Estas operações não são suportadas porque modificam os dados ou o estado da base de dados.

Regras geradas automaticamente assistidas por IA

A geração de regras automatizadas assistidas por IA para medição da qualidade dos dados utiliza técnicas de inteligência artificial (IA) para criar automaticamente regras para avaliar e melhorar a qualidade dos dados. As regras geradas automaticamente são específicas do conteúdo. A maioria das regras comuns são geradas automaticamente para que não tenha de se esforçar muito para criar regras personalizadas.

Para navegar e aplicar regras geradas automaticamente:

1. No separador Regras de um recurso de dados, selecione Sugerir regras.

2. Navegue na lista de regras sugeridas.

   

3. Selecione regras na lista de regras sugeridas para aplicar ao recurso de dados.

   

Próximas etapas

1. Configure e execute uma análise de qualidade de dados num produto de dados para avaliar a qualidade de todos os recursos suportados no produto de dados.
2. Reveja os resultados da análise para avaliar a qualidade atual dos dados do produto de dados.