Os tipos de dados CHAR, NCHAR, VARCHAR e NVARCHAR são usados para armazenar dados de texto no SQL Server. Cada um é empregado em uma situação distinta, e saber escolher o tipo de dados adequado pode afetar a performance e o uso de espaço no banco de dados.

Neste tutorial vou mostrar cada um desses tipos, suas diferenças e quando usá-los.

Tipos de Texto no SQL Server

Os tipos nchar e nvarchar permitem armazenar caracteres Unicode, ao passo que char e varchar não o permitem – é até possível armazenar Unicode com esses tipos, mas por meio de alguns “truques” no código. Porém, os tipos nchar e nvarchar ocupam o dobro de espaço de armazenamento. Desta forma, recomenda-se utilizá-los apenas caso seja necessário suporte a Unicode na tabela – o que é bastante comum.

Os tipos char e nchar são tipos de tamanho fixo, o que significa que eles reservam espaço de armazenamento para a quantidade de caracteres que foi especificada em suas declarações, mesmo que o espaço não seja totalmente utilizado. Por exemplo, podemos criar um campo char ou nchar para 20 caracteres mas armazenar apenas 15 – os outros 5 que ficaram vagos irão ocupar espaço da mesma maneira.

Recomenda-se usar esses tipos caso os dados armazenados sempre ocupem o tamanho máximo especificado na declaração da coluna.

Já os tipos varchar e nvarchar são tipos de tamanho variável, de modo que o espaço ocupado corresponderá à quantidade de caracteres que efetivamente são armazenados + 2 (2 bytes de registro do comprimento – overhead), independente do tamanho máximo declarado.

Características dos tipos CHAR, NCHAR, VARCHAR e NVARCHAR

CHAR

• Descrição: Armazena dados de texto com comprimento fixo.
• Tamanho: O comprimento é definido ao criar a coluna e todos os valores terão exatamente esse tamanho – ou seja, o comprimento é fixo. Espaços em branco são adicionados para preencher o comprimento se necessário.
• Uso: Dados de tamanho fixo, como códigos de produtos ou identificadores.

NCHAR

• Descrição: Similar ao CHAR (também comprimento fixo), mas armazena dados de texto em formato Unicode.
• Tamanho: Cada caractere ocupa 2 bytes, permitindo armazenar caracteres de múltiplos idiomas.
• Uso: Usado para dados de texto internacionalizados ou quando é necessário suportar vários idiomas.

VARCHAR

• Descrição: Armazena dados de texto com comprimento variável.
• Tamanho: O comprimento máximo é definido ao criar a coluna, mas apenas o espaço necessário para armazenar o valor real é utilizado. Ou seja, ocupa espaço de acordo com o valor armazenado na coluna.
• Uso: Ideal para colunas onde os tamanhos dos valores podem variar significativamente, como nomes, descrições ou endereços.

NVARCHAR

• Descrição: Similar ao VARCHAR, mas armazena dados de texto em formato Unicode.
• Tamanho: Cada caractere ocupa 2 bytes, semelhante ao NCHAR, mas o espaço é utilizado de forma mais eficiente para comprimentos variáveis.
• Uso: Usado para dados de texto internacionalizados ou quando é necessário suportar vários idiomas, com comprimentos variáveis.

Performance dos tipos de texto

Com relação à performance desses tipos de texto no SQL Server, temos que:

• CHAR e NCHAR podem ser mais rápidos para acesso em colunas onde todos os valores têm tamanho fixo.
• Já os tipos VARCHAR e NVARCHAR são mais eficientes em termos de espaço para colunas onde os tamanhos dos valores variam.

Exemplos de uso

1. Tipos CHAR e NCHAR

Criamos uma tabela com dois campos, um do tipo CHAR e outro do tipo NCHAR

CREATE TABLE ExemploCharNChar (
Codigo CHAR(5),
Item NCHAR(10)
);

Inserimos uma linha de teste nessa tabela. Para o campo “Item” usarei um dado em outro idioma, inclusive com outro conjunto de caracteres – no caso, caracteres japoneses.

Note o caractere ‘N’ que precede o valor a ser armazenado, para indicar ao SQL Server que se trata de um valor Unicode.

INSERT INTO ExemploCharNChar (Codigo, Item)
VALUES ('012', N'ピザ');

Consegue descobrir que item foi inserido?

E realizamos uma consulta para ver o dado inserido.

SELECT * FROM ExemploCharNChar;

Resultado:

Codigo  Item
012     ピザ 

2. Tipos VARCHAR e NVARCHAR

Agora vamos criar outra tabela também com dois campos, um do tipo VARCHAR e outro do tipo NVARCHAR

CREATE TABLE ExemploVarcharNVarchar (
Descricao VARCHAR(50),
Pedido NVARCHAR(100)
);

Inserimos uma linha de teste nessa tabela. Para o campo “Pedido” usarei novamente um dado em idioma japonês, desta vez com mais caracteres.

INSERT INTO ExemploVarcharNVarchar (Descricao, Pedido)
VALUES ('Prato Típico Italiano', N'ピザが食べたい.');

E realizamos a consulta para ver o dado inserido.

SELECT * FROM ExemploVarcharNVarchar;

Resultado:

Descricao             Pedido
Prato Típico Italiano ピザが食べたい.

Importante

Uma dica importante é a seguinte: Hoje em dia, os sistemas operacionais e plataformas de desenvolvimento usam internamente o sistema Unicode.

Sendo assim, se usarmos os tipos nvarchar em vez de varchar, e nchar em vez de char, evitamos que ocorram conversões de codificação sempre que operaçoes de leitura ou escrita forem realizadas no banco de dados.

Essas conversões consomem recursos do servidor e podem ocasionar erros, ainda que raramente, além do que não é fácil recuperar de erros de conversão em uma tabela.

Conclusão

Neste tutorial estudamos os tipos de dados CHAR, NCHAR, VARCHAR e NVARCHAR no SQL Server, suas diferenças e exemplos de uso.

Ao escolher o tipo de dados para colunas de texto, considere o tamanho dos dados que você espera armazenar, a necessidade de suporte a múltiplos idiomas e a eficiência de armazenamento. Para texto que precisa ser armazenado em múltiplos idiomas, use os tipos NCHAR ou NVARCHAR. Para texto de tamanho fixo, use CHAR, e para tamanho variável, use VARCHAR.

Lembre-se:

• Usamos CHAR e NCHAR quando o comprimento dos dados for fixo.
• Usamos VARCHAR e NVARCHAR quando o comprimento dos dados for variável.
• A letra ‘N’ antes dos tipos Unicode (NCHAR e NVARCHAR) indica que eles suportam caracteres Unicode.

* ピザ significa “pizza” e ピザが食べたい significa “quero comer pizza” (“piza ga tabetai”).

Colabore com a Bóson Treinamentos

Ajude o canal adquirindo meus cursos na Udemy:

• Bancos de Dados com MySQL Básico: https://bit.ly/35QdWE4
• Lógica de Programação com Português Estruturado: https://bit.ly/3QKPn22
• Programação em Python do Zero: https://bit.ly/python-boson

Adquira também livros e outros itens na loja da Bóson Treinamentos na Amazon e ajude o canal a se manter e crescer: https://www.amazon.com.br/shop/bosontreinamentos

O post Como usar os tipos de dados char, nchar, varchar e nvarchar no SQL Server apareceu primeiro em Bóson Treinamentos em Ciência e Tecnologia.

As Doze Regras de Codd são um conjunto de (na verdade) treze regras (enumeradas de zero a doze) publicadas pelo cientista da computação Edgar F. Codd em outubro de 1985, com o intuito de definir o que é necessário para que um sistema de gerenciamento de banco de dados possa ser considerado realmente um sistema relacional, ou seja, um SGBDR.

Edgar Frank “Ted” Codd (19 de agosto de 1923 – 18 de abril de 2003) foi um cientista da computação inglês que, enquanto trabalhava para a IBM, inventou o modelo relacional para gerenciamento de banco de dados, a base teórica para bancos de dados relacionais e sistemas de gerenciamento de banco de dados relacionais.

À medida que o modelo relacional de bancos de dados se popularizou no início dos anos 1980, Codd travou uma campanha por vezes complicada para evitar que o termo fosse mal utilizado por fornecedores de bancos de dados que apenas acrescentaram um verniz relacional à tecnologias mais antigas.

Como parte desta campanha, ele publicou suas 12 regras para definir o que constituía um banco de dados relacional. Isso tornou sua posição na IBM cada vez mais difícil, e então ele saiu para formar uma empresa de consultoria com Christopher J. Date e outros.

Edgar Frank Codd

A seguir trago o texto integral traduzido para o português com as 12 regras mais a regra 0, de acordo como publicado em duas matérias na revista Computerworld no mês de outubro de 1985: “Is your DBMS really relational?“, Computerworld. 14/10/1985, Vol. 19, e “Does your DBMS run by the rules?“, Computerworld. 21/10/1985, Vol. 19.

Texto integral traduzido das 12 Regras de Codd

As 12 regras
Por E. F. Codd
Outubro 1985

Doze regras são citadas abaixo como parte de um teste para determinar se um produto que se afirma ser totalmente relacional o é realmente. O emprego do termo “totalmente relacional” neste relatório é ligeiramente mais rigoroso do que no meu artigo de Turing (escrito em 1981). Isso ocorre em parte porque os fornecedores em seus anúncios e manuais traduziram o termo “minimamente relacional” para “totalmente relacional” e em parte porque neste relatório estamos lidando com SGBDs relacionais e não com sistemas relacionais em geral, o que incluiria meros sistemas de relatórios de consultas.

No entanto, as 12 regras tendem a explicar porque é que o suporte total ao modelo relacional é do interesse dos usuários. Nenhum novo requisito é adicionado ao modelo relacional. Posteriormente, um esquema de notas é definido e utilizado para medir o grau de fidelidade ao modelo relacional.

Primeiro, defino essas regras. Embora eu tenha definido cada regra em artigos anteriores, acredito que esta seja a primeira ocorrência de todas as 12 juntas.

Nas regras de oito a 11, especifico e exijo quatro tipos diferentes de independência destinados a proteger os investimentos dos clientes em programas de aplicação, atividades de terminal e treinamento. As regras oito e nove — independência física e lógica dos dados — têm sido amplamente discutidas há muitos anos.

As regras 10 e 11 — independência de integridade e independência de distribuição — são aspectos da abordagem relacional que não receberam atenção adequada até à data, mas que provavelmente se tornarão tão importantes quanto a oito e a nove.

Estas regras se baseiam em uma única regra fundamental, que chamarei de Regra Zero:

Regra Zero.
Regra 0: Para qualquer sistema anunciado como, ou que se alega ser, um sistema de gerenciamento de banco de dados relacional, esse sistema deve ser capaz de gerenciar bancos de dados inteiramente por meio de suas capacidades relacionais.

Esta regra deve ser válida quer o sistema suporte ou não quaisquer capacidades não relacionais de gerenciamento de dados. Qualquer SGBD que não satisfaça esta Regra Zero não vale a pena ser classificado como um SGBD relacional.

Uma consequência desta regra: qualquer sistema que se alega ser um SGBD relacional deve suportar inserção, atualização e exclusão em banco de dados no nível relacional (múltiplos registros por vez). Outra consequência é a necessidade de dar suporte à regra da informação e à regra do acesso garantido.

“Múltiplos registros por vez” inclui como casos especiais aquelas situações em que zero ou um registro é recuperado, inserido, atualizado ou excluído. Em outras palavras, uma relação (tabela) pode ter zero tuplas (linhas) ou uma tupla e ainda assim ser uma relação válida.

Qualquer declaração nos manuais de um sistema alegado ser um SGBD relacional que aconselhe os usuários a reverter para algumas capacidades não relacionais “para alcançar um desempenho aceitável” – ou por qualquer razão que não seja a compatibilidade com programas escritos no passado em sistemas de banco de dados não relacionais – deve ser interpretado como uma desculpa do fornecedor. Tal afirmação indica que o fornecedor não realizou o trabalho necessário para alcançar um bom desempenho com a abordagem relacional.

Qual é o perigo para compradores e usuários de um sistema que é considerado um SGBD relacional e que falha na Regra Zero?

Compradores e usuários esperarão todas as vantagens de um SGBD verdadeiramente relacional e não conseguirão obter essas vantagens. Agora descreverei as 12 regras que, juntamente com os nove recursos estruturais, 18 manipulativos e três de integridade do modelo relacional, determinam em detalhes específicos a extensão da validade da reivindicação de um fornecedor de ter um “SGBD totalmente relacional”.

Todas as 12 regras são motivadas pela Regra Zero definida acima, mas um SGBD pode ser verificado mais facilmente quanto à conformidade com essas 12 do que com a Regra Zero.

A regra da informação.
Regra 1: Todas as informações em um banco de dados relacional são representadas explicitamente no nível lógico e exatamente de uma maneira — por valores em tabelas.

Até mesmo nomes de tabelas, nomes de colunas e nomes de domínio são representados como cadeias de caracteres em algumas tabelas. As tabelas que contêm esses nomes normalmente fazem parte do catálogo interno do sistema. O catálogo é, portanto, uma base de dados relacional em si – dinâmica e ativa e que representa os metadados (dados que descrevem o restante dos dados no sistema). A regra de informação é aplicada não apenas para a produtividade do usuário, mas também para tornar um trabalho razoavelmente simples para os fornecedores de software definir pacotes de software adicionais (como auxílios ao desenvolvimento de aplicativos, sistemas especialistas e assim por diante) que fazem interface com SGBD relacionais e, por definição, estão bem integrados ao SGBD.

Ou seja, esses pacotes recuperam informações já existentes no catálogo e, conforme a necessidade, colocam novas informações no catálogo pelo próprio ato de utilizar o SGBD.

Uma razão adicional para aplicar esta regra é tornar a tarefa do administrador da base de dados de manter a base de dados num estado de integridade geral mais simples e mais eficaz. Não há nada mais embaraçoso para um administrador de base de dados do que ser questionado se a sua base de dados contém certas informações específicas e ele responder, após uma semana de exame da base de dados, que ele não sabe.

Regra de acesso garantido.
Regra 2: É garantido que todo e qualquer dado (valor atômico) em um banco de dados relacional seja logicamente acessível recorrendo a uma combinação de nome de tabela, valor de chave primária e nome de coluna.

Claramente, cada dado em um banco de dados relacional pode ser acessado em uma rica variedade – possivelmente milhares – de maneiras logicamente distintas. No entanto, é importante ter pelo menos uma forma, independente da base de dados relacional específica, que seja garantida, porque a maioria dos conceitos orientados para o computador (como a varredura de endereços sucessivos) foram deliberadamente omitidos do modelo relacional.

Observe que a regra de acesso garantido representa um esquema de endereçamento associativo exclusivo do modelo relacional. A regra não depende em nada do endereçamento usual orientado por computador. No entanto, o conceito de chave primária é uma parte essencial dele.

Tratamento sistemático de valores nulos.
Regra 3: Valores nulos (distintos da sequência de caracteres vazia ou de uma sequência de caracteres em branco e distintos de zero ou qualquer outro número) são suportados em SGBDs totalmente relacionais para representar informações ausentes e informações inaplicáveis de forma sistemática, independente do tipo de dados.

Para suportar integridade do banco de dados, deve ser possível especificar “nulos não permitidos” para cada coluna de chave primária e para quaisquer outras colunas onde o administrador do banco de dados considere uma restrição de integridade apropriada (por exemplo, certas colunas de chave estrangeira).

As técnicas anteriores envolviam a definição de um valor especial (peculiar a cada coluna ou campo) para representar a informação faltante. Isto seria muito assistemático em um banco de dados relacional porque os usuários teriam que empregar técnicas diferentes para cada coluna ou domínio — uma tarefa difícil devido ao alto nível de linguagem em uso (e uma tarefa que acredito que diminuiria a produtividade do usuário).

Catálogo on-line dinâmico baseado no modelo relacional.
Regra 4: A descrição do banco de dados é representada no nível lógico da mesma forma que os dados comuns, de modo que os usuários autorizados possam aplicar à sua interrogação a mesma linguagem relacional que aplicam aos dados regulares.

Uma consequência disso é que cada usuário (seja um programador de aplicação ou um usuário final) precisa aprender apenas um modelo de dados – uma vantagem que os sistemas não relacionais geralmente não oferecem (o IMS da IBM, juntamente com seu dicionário, exige que o usuário aprenda dois modelos de dados distintos).

Outra consequência é que os usuários autorizados podem facilmente estender o catálogo para se tornar um dicionário de dados relacional ativo e completo sempre que o fornecedor não o fizer.

Regra abrangente de sublinguagem de dados.
Regra 5: Um sistema relacional pode suportar diversas linguagens e vários modos de uso de terminal (por exemplo, o modo de preencher as lacunas). No entanto, deve haver pelo menos uma linguagem cujas instruções sejam expressáveis, de acordo com alguma sintaxe bem definida, como cadeias de caracteres e que seja abrangente no suporte a todos os itens a seguir:

• Definição de dados.
• Definição de Views.
• Manipulação de dados (interativa e por programa).
• Restrições de integridade.
• Autorização.
• Limites de transação (início, confirmação e reversão).

A abordagem relacional é altamente dinâmica de forma intencional — ou seja, raramente será necessário interromper a atividade do banco de dados (em contraste com um SGBD não relacional). Portanto, não faz sentido separar os serviços listados acima em linguagens distintas.

Em meados dos anos 70, o Comitê de Planejamento e Requisitos de Padrões Ansi gerou um documento defendendo 42 interfaces distintas e (potencialmente) 42 linguagens distintas para SGBD. Felizmente, essa ideia aparentemente foi abandonada.

Regra de atualização de visões
Regra 6: Todas as visões que são teoricamente atualizáveis também são atualizáveis pelo sistema.

Observe que uma visão é teoricamente atualizável se existir um algoritmo independente de tempo para determinar inequivocamente uma única série de mudanças nas relações de base que terão como efeito precisamente as mudanças solicitadas na visão. A este respeito, “atualização” pretende incluir inserção e exclusão, bem como modificação.

Inserção, atualização e exclusão de alto nível.
Regra 7: A capacidade de tratar uma relação base ou uma relação derivada como um único operando aplica-se não apenas à recuperação de dados, mas também à inserção, atualização e exclusão de dados.

Este requisito dá ao sistema muito mais espaço para otimizar a eficiência de suas ações em tempo de execução. Ele permite que o sistema determine quais caminhos de acesso explorar para obter o código mais eficiente. Também pode ser extremamente importante para obter um tratamento eficiente de transações em um banco de dados distribuído. Neste caso, os usuários prefeririam que os custos de comunicação fossem poupados, evitando a necessidade de transmitir um pedido separado para cada registro obtido de locais remotos.

Independência física de dados.
Regra 8: Os programas aplicativos e as atividades do terminal permanecem logicamente inalterados sempre que qualquer alteração é feita nas representações de armazenamento ou nos métodos de acesso.

Para lidar com isso, o SGBD deve suportar uma fronteira clara e nítida entre os aspectos lógicos e semânticos, por um lado, e os aspectos físicos e de desempenho das tabelas base, por outro; os programas aplicativos devem lidar apenas com os aspectos lógicos.

SGBDs não relacionais raramente fornecem suporte completo para esta regra – na verdade, não conheço nenhum que o faça.

Independência lógica de dados.
Regra 9: Os programas aplicativos e as atividades de terminal permanecem logicamente intactos quando alterações de qualquer tipo que preservem informações e que teoricamente permitam a integridade são feitas nas tabelas base.

Tomemos os dois exemplos a seguir: dividir uma tabela em duas tabelas, seja por linhas usando conteúdo de linha ou por colunas usando nomes de coluna, se as chaves primárias forem preservadas em cada resultado; ou combinar duas tabelas em uma por meio de uma junção sem perdas (os autores da Universidade de Stanford e do MIT chamam essas junções de “sem perdas”). Para fornecer este serviço sempre que possível, o SGBD deve ser capaz de lidar com inserções, atualizações e exclusões em todas as visões que são teoricamente atualizáveis. Esta regra permite que o design do banco de dados lógico seja alterado dinamicamente se, por exemplo, tal alteração melhorar o desempenho.

As regras de independência de dados físicos e lógicos permitem que os projetistas de bancos de dados para SGBDs relacionais cometam erros em seus projetos sem as pesadas penalidades impostas pelos SGBDs não relacionais. Isso, por sua vez, significa que é muito mais fácil começar com um SGBD relacional porque não é necessário tanto planejamento orientado ao desempenho antes da “decolagem”.

Independência de integridade.
Regra 10: As restrições de integridade específicas de um banco de dados relacional em particular devem ser definíveis na sublinguagem de dados relacionais e armazenáveis no catálogo, e não nos programas aplicativos.

Além das duas regras de integridade (integridade de entidade e integridade referencial) que se aplicam a todos os bancos de dados relacionais, há uma necessidade clara de poder especificar restrições de integridade adicionais que reflitam políticas de negócios ou regulamentações governamentais.

Suponha que o modelo relacional seja refletido fielmente. Então, as restrições de integridade adicionais são definidas em termos da sublinguagem de dados de alto nível e das definições armazenadas no catálogo, não nos programas aplicativos. Informações sobre objetos identificados inadequadamente nunca são registradas em um banco de dados relacional. Para ser mais específico, as duas regras de integridade a seguir se aplicam a todos os bancos de dados relacionais:

• Integridade da entidade. Nenhum componente de uma chave primária pode ter um valor nulo.
• Integridade referencial. Para cada valor de chave estrangeira não nulo distinto em um banco de dados relacional, deve existir um valor de chave primária correspondente do mesmo domínio.

Se, como às vezes acontece, as políticas empresariais ou as regulamentações governamentais mudarem, provavelmente será necessário alterar as restrições de integridade. Normalmente, isso pode ser feito em um SGBD totalmente relacional, alterando uma ou mais instruções de integridade armazenadas no catálogo.

Em muitos casos, nem os programas aplicativos nem as atividades do terminal são prejudicadas logicamente.

SGBDs não relacionais raramente suportam esta regra como parte do mecanismo do SGBD, ao qual ela pertence. Em vez disso, eles dependem de um pacote de dicionário, que pode ou não estar presente e pode ser facilmente ignorado.

Independência de distribuição.
Regra 11: Um SGBD relacional possui independência de distribuição.

Por independência de distribuição, quero dizer que o SGBD possui uma sublinguagem de dados que permite que programas aplicativos e atividades de terminal permaneçam logicamente intactos:

• Quando a distribuição de dados é introduzida pela primeira vez (se o SGBD instalado originalmente gerencia apenas dados não distribuídos);
• Quando os dados são redistribuídos (se o SGBD gerencia dados distribuídos).

Note que a definição é cuidadosamente redigida para que tanto o SGBD distribuído quanto o não distribuído possam suportar totalmente a Regra 11. O SQL/DS e DB2 da IBM, Oracle Corp. da Oracle e Ingres da Relational Technology, Inc. (todos não distribuídos nos releases atuais) suportam totalmente esta regra.

Isso foi demonstrado da seguinte forma: programas SQL foram escritos para operar em dados não distribuídos (usando o System R), rodam corretamente em versões distribuídas desses dados (usando System R*, o protótipo do IBM San Jose Research Laboratory), e o projeto distribuído Ingres na Universidade da Califórnia em Berkeley mostrou a mesma capacidade para a linguagem Quel de Ingres.

É importante distinguir o processamento distribuído dos dados distribuídos. No primeiro caso, o trabalho (por exemplo, programas) é transmitido aos dados; neste último caso, os dados são transmitidos para o trabalho. Muitos DBMS não relacionais suportam processamento distribuído, mas não dados distribuídos. Os únicos sistemas que suportam o conceito de fazer com que todos os dados distribuídos pareçam locais são SGBDs relacionais – estes são protótipos no momento.

No caso de um SGBD relacional distribuído, uma única transação pode abranger vários locais remotos. Isso é gerenciado inteiramente nos bastidores – o sistema pode ter que executar a recuperação em vários locais. Cada programa ou atividade de terminal trata a totalidade dos dados como se fossem todos locais do site onde o programa aplicativo ou atividade de terminal está sendo executado.

Um SGBD totalmente relacional que não suporta bancos de dados distribuídos tem a capacidade de ser estendido para fornecer esse suporte, deixando os programas aplicativos e as atividades do terminal logicamente intactos, tanto no momento da distribuição inicial quanto sempre que a redistribuição posterior for feita.

Existem quatro razões importantes pelas quais um SGBD relacional desfruta desta vantagem:

• Flexibilidade de decomposição na decisão de como implantar os dados.
• Poder de recomposição dos operadores relacionais ao combinar os resultados de subtransações executadas em diferentes sites.
• Economia de transmissão resultante do fato de não ser necessário enviar uma mensagem de solicitação para cada registro a ser recuperado de qualquer site remoto.
• Analisabilidade da intenção (devido ao nível muito alto das linguagens relacionais) para uma otimização de execução amplamente melhorada.

Regra de não subversão.
Regra 12: Se um sistema relacional tiver uma linguagem de baixo nível (registro único por vez), esse baixo nível não pode ser usado para subverter ou contornar as regras e restrições de integridade expressas na linguagem relacional de nível superior (múltiplos registros por vez).

Na abordagem relacional, a preservação da integridade é independente da estrutura lógica de dados para alcançar a independência da integridade. Esta regra é extremamente difícil para um sistema “nascido de novo” obedecer porque tal sistema já suporta uma interface abaixo da interface de restrição relacional. Os fornecedores de sistemas “nascidos de novo” não parecem ter dado a devida atenção a este problema.

Essas foram as 12 regras de Codd para sistemas de bancos de dados relacionais. Note que, embora essas regras fossem bastante válidas para a época da publicação dos artigos, sua intenção e seu público, hoje em dia é mais apropriado levar em consideração os artigos batizados de “O Terceiro Manifesto”, escritos por Christopher J. Date e Hugh Darwen sobre o modelo relacional, que podem ser acessados em http://thethirdmanifesto.com.

Fonte do texto e referências: https://reldb.org/c/index.php/twelve-rules/

Aproveite e assista a um vídeo sobre as 12 Regras de Codd no canal da Bóson Treinamentos no YouTube:

Colabore com a Bóson Treinamentos

Ajude o canal adquirindo meus cursos na Udemy:

• Bancos de Dados com MySQL Básico: https://bit.ly/35QdWE4
• Lógica de Programação com Português Estruturado: https://bit.ly/3QKPn22
• Programação em Python do Zero: https://bit.ly/python-boson

Adquira também livros e outros itens na loja da Bóson Treinamentos na Amazon e ajude o canal a se manter e crescer: https://www.amazon.com.br/shop/bosontreinamentos

O post As 12 Regras de Codd para Sistemas de Bancos de Dados Relacionais apareceu primeiro em Bóson Treinamentos em Ciência e Tecnologia.

A sigla OLTP (Online Transaction Processing / Processamento de Transações Online) se refere a um tipo de aplicação de banco de dados que é projetada para processar transações em tempo real.Essas transações geralmente envolvem operações de inserção, atualização ou exclusão de pequenas quantidades de dados em um banco de dados.

As aplicações OLTP geralmente são usadas em ambientes comerciais para executar transações de negócios diárias, como processamento de pedidos, gerenciamento de estoque, gerenciamento de contas e processamento de pagamentos.

Essas transações geralmente envolvem interações entre muitos usuários simultaneamente e, portanto, devem ser processadas de maneira rápida e confiável.

Os bancos de dados OLTP são projetados para suportar altas taxas de transações e muitas vezes incluem recursos como indexação, particionamento de tabelas e controle de concorrência para garantir que as transações sejam processadas com eficiência e precisão.

Online Transaction Processing – OLTP

Esses bancos de dados também são frequentemente otimizados para leitura/gravação e normalização de dados para minimizar o espaço de armazenamento e reduzir a redundância de dados.

Exemplos de sistema OLTP

Exemplos de sistemas que usam OLTP incluem:

• Bancos de dados de processamento de pedidos: Os varejistas on-line e as empresas que vendem produtos ou serviços on-line usam bancos de dados OLTP para processar pedidos em tempo real. Esses bancos de dados são usados para gerenciar o estoque de produtos, registrar as informações do cliente, processar transações de pagamento e rastrear o envio dos pedidos.
• Bancos de dados de gerenciamento de contas: Bancos, empresas financeiras e outras organizações que gerenciam contas de clientes usam bancos de dados OLTP para registrar e processar transações financeiras em tempo real. Esses bancos de dados são usados para gerenciar o saldo da conta, registrar depósitos e retiradas, gerar extratos de conta e fornecer serviços on-line para os clientes.
• Bancos de dados de reservas de viagens: Companhias aéreas, hotéis e outras empresas de viagens usam bancos de dados OLTP para gerenciar reservas em tempo real. Esses bancos de dados são usados para armazenar informações sobre voos, quartos de hotel e outros serviços de viagens, bem como para processar reservas, atualizar disponibilidade e confirmar reservas de clientes.
• Bancos de dados de atendimento ao cliente: Empresas de serviços ao cliente, como telecomunicações, empresas de serviços públicos e seguradoras, usam bancos de dados OLTP para gerenciar interações com os clientes em tempo real. Esses bancos de dados são usados para armazenar informações sobre os clientes, registrar reclamações, gerenciar solicitações de serviço e fornecer suporte técnico.

Existem muitos outros exemplos de bancos de dados OLTP. Na prática, qualquer aplicação que envolva processamento de transações em tempo real e requer alta disponibilidade e confiabilidade pode usar um banco de dados OLTP.

SGBDs com suporte a OLTP

Existem muitos SGBDs (Sistemas de Gerenciamento de Bancos de Dados) que suportam OLTP. Aqui estão alguns exemplos:

• MySQL: O MySQL é um sistema de gerenciamento de bancos de dados relacionais de código aberto que é frequentemente usado para aplicativos OLTP, como sistemas de comércio eletrônico, bancos de dados de gerenciamento de pedidos e aplicativos financeiros.
• Microsoft SQL Server: SQL Server é um SGBD relacional proprietário que é frequentemente usado para aplicativos OLTP, como bancos de dados de gerenciamento de pedidos, bancos de dados de gerenciamento de contas e sistemas de reservas de viagens.
• Oracle Database: O Oracle Database é outro SGBD relacional proprietário que é usado para uma ampla variedade de aplicativos OLTP, como bancos de dados de gerenciamento de contas, bancos de dados de gerenciamento de pedidos e sistemas de reservas de viagens.
• PostgreSQL: SGBD de código aberto que é frequentemente usado para aplicativos OLTP, como bancos de dados de gerenciamento de pedidos, sistemas de reservas de viagens e sistemas de gerenciamento de estoque.
• MongoDB: O MongoDB é um SGBD NoSQL de código aberto que é frequentemente usado para aplicativos OLTP, como sistemas de gerenciamento de usuários e bancos de dados de gerenciamento de pedidos.

Na verdade, a maioria dos SGBDs modernos suporta OLTP, pois é uma necessidade comum para aplicativos empresariais e de comércio eletrônico em tempo real.

Conclusão

Resumindo, OLTP é um tipo de aplicação de banco de dados que lida com transações em tempo real e é projetada para suportar altas taxas de transações em ambientes comerciais.

O post Conceitos de Bancos de Dados – O que é OLTP apareceu primeiro em Bóson Treinamentos em Ciência e Tecnologia.

Artigo complementar do Curso Completo de Modelagem de Dados da Bóson Treinamentos no YouTube.

As dependências, em bancos de dados relacionais, são restrições aplicadas sobre atributos, ou que definem a relação entre dois ou mais atributos em uma tabela. As dependências ocorrem quando uma coluna em uma tabela é determinada por outra coluna, ou seja, quando uma coluna depende de outra para fazer sentido.

Um exemplo clássico seria uma tabela de produtos, com campos como Código do Produto, Preço do Produto e Data de Validade. Para saber o preço de um determinado produto é bem evidente que precisamos saber de que produto se trata e, para tal, usamos o código do produto para identificá-lo. Neste caso, dizemos que o preço do produto depende do código do produto armazenado.

Esta é uma forma de dependência, que chamamos de dependência funcional, mas existem outras, que passaremos a estudar a seguir.

Tipos de Dependências entre Atributos

Os tipos de dependências que podem ocorrer em uma tabela de banco de dados são os seguintes:

• Dependência Funcional
• Dependência Funcional Total
• Dependência Funcional Parcial
• Dependência Funcional Transitiva
• Dependência Multivalorada

Vamos explicar cada um deles a partir de agora.

Dependência Funcional

Seja E uma entidade, e X e Y dois atributos quaisquer de E. Dizemos que Y é funcionalmente dependente de X se e somente se cada valor de X tiver associado a ele exatamente um valor de Y.

Simbolicamente:

X → Y

Que lemos como “X determina funcionalmente Y”.

Exemplo

Ex.: Pensando em uma tabela de pedidos; O prazo de entrega de um pedido depende do número do pedido considerado:

Num_Pedido  →  Prazo_Entr_Pedido

O atributo que determina o valor é chamado de Determinante. O outro atributo é chamado de Dependente.

Uma chave primária em uma relação determina funcionalmente todos os outros atributos não-chave na linha.

Dependência Funcional Total

Em uma relação com uma PK composta, um atributo não-chave que dependa dessa PK como um todo, e não somente de parte dela, é dito como possuindo Dependência Funcional Total.

Exemplo

Veja o exemplo a seguir:

Aqui, Quant_produto depende tanto de Num_Pedido quanto de Cod_Produto, ao mesmo tempo.

Obs.: A dependência funcional total só pode ocorrer em tabela com chave primária composta.

Dependência Funcional Parcial

Uma dependência funcional é parcial quando os atributos não-chave não dependem funcionalmente de toda a PK quando esta for composta.

Ou seja, existe uma dependência funcional, mas somente de uma parte da chave primária.

Exemplo

Campo Nome_Disciplina é dependente de Cod_Disciplina, mas não do ID_Aluno.

Dependência Funcional Transitiva

Este tipo de dependência ocorre quando um campo não-chave não depende diretamente da chave primária da tabela (nem mesmo parcialmente), mas depende de um outro campo não-chave na tabela.

Exemplo

No exemplo, o atributo Nome_Vendedor depende funcionalmente do Cód_Vendedor, que não é chave primária na tabela. Já o campo Prazo_Entrega depende da PK, Num_Pedido

Dependência Multivalorada

Ocorre quando, para cada valor de um atributo A, existe um conjunto de valores para outros atributos B e C que estão associados a ele, mas que são independentes entre si.

Representamos a dependência multivalorada assim:

A —>> B

Onde B é a coluna que depende da coluna A.

Exemplo

Neste exemplo, os atributos Ano e Cor são independentes entre si e dependem do modelo do carro. Essas duas colunas são dependentes multivaloradas do atributo Modelo.

Conclusão

Entender as dependências é fundamental durante o processo de modelagem de dados, pois, dependendo do tipo de dependência encontrada será necessário tomar determinadas decisões, como eliminar atributos, criar novas tabelas ou mover atributos entre tabelas, o que ficará bem evidente quando estudarmos os processos de Normalização de Bancos de Dados.

Anterior: O que são Restrições de Integridade em Bancos de Dados
Próximo: O que é um Dicionário de Dados

O post Modelagem de Dados – O que são Dependências em Bancos de Dados apareceu primeiro em Bóson Treinamentos em Ciência e Tecnologia.

O Modelo Entidade-Relacionamento, também conhecido pela sigla MER, é um modelo conceitual amplamente empregado para descrever objetos envolvidos no domínio de um sistema de bancos de dados a ser construído, incluindo seus atributos e relacionamentos.

Um MER permite representar de forma abstrata a estrutura que irá constituir o banco de dados, sendo composto pelos seguintes objetos:

• Entidades
• Atributos
• Relacionamentos

Um modelo entidade relacionamento é uma maneira sistemática de descrever e definir um processo de negócio, o qual é modelado como componentes (entidades) que são ligadas umas às outras por relacionamentos que indicam as dependências entre elas.

As entidades podem ter várias propriedades (atributos) que as caracterizam. Diagramas são criados para representar graficamente as entidades, atributos e relacionamentos, denominados Diagramas Entidade-Relacionamento (DER).

Modelo e Diagrama (MER x DER)

Um Modelo Entidade-Relacionamento, ou MER, é uma lista de entidades, seus atributos e relacionamentos, que traz informações sobre tipos de dados, restrições, descrições de entidades e outras. É comumente representado em forma textual, como uma lista de itens ou conjuntos de valores entre chaves ou parênteses. Por exemplo, uma entidade com seus atributos poderia ser representada em um MER da seguinte forma:

Produtos(IdProduto, NomeProduto, PrecoProduto, QtdeEstoque)

O MER foi desenvolvido pelo cientista da computação Peter Chen e publicado em um artigo em 1976.

Já um Diagrama Entidade-Relacionamento, abreviado como DER, é uma representação gráfica associada a um MER (ou à uma parte dele), permitindo expressar graficamente a estrutura lógica de um banco de dados.

Dr. Peter Chen, criador do Modelo ER

Representação dos Componentes em um DER

Os objetos componentes de um diagrama entidade-relacionamento são graficamente representados por figuras geométricas simples, conectadas por linhas. São elas:

• Retângulos: Representam entidades
• Elipses: Representam atributos
• Losangos: Representam relacionamentos
• Linhas: Conectam os atributos às entidades e as entidades aos relacionamentos

Além disso também podemos representar a Cardinalidade dos relacionamentos em um DER por meio de valores escritos entre parênteses, como por exemplo (1,1) (relacionamento um-para-um). Mais sobre isso na aula específica sobre cardinalidades.

Exemplo de DER

A figura a seguir mostra um Diagrama Entidade-Relacionamento de exemplo, criado com o software brModelo, que representa um sistema de banco de dados criado para gerenciar cursos, alunos e professores em uma faculdade.

Podemos identificar neste DER diversas entidades, como Turma, Curso, Disciplina e Aluno, com seus atributos, e os relacionamentos existentes entre essas entidades, além de suas cardinalidades.

Este DER foi utilizado no pr0jeto prático do curso de Modelagem de Dados disponível no canal do YouTube da Bóson Treinamentos.

O post O Modelo Entidade-Relacionamento: Introdução apareceu primeiro em Bóson Treinamentos em Ciência e Tecnologia.

Artigo complementar do Curso Completo de Modelagem de Dados da Bóson Treinamentos no YouTube.

Neste artigo vamos explorar um tópico de elevada importância em modelagem de dados: o conceito de chaves e seus tipos, com algumas dicas de como determinar chaves primárias e estrangeiras em uma tabela, e exemplos.

O que são Chaves em Bancos de Dados

Uma chave consiste em uma ou mais colunas combinadas de uma relação (tabela) cujos valores são usados para identificar de forma exclusiva uma linha ou um conjunto de linhas relacionadas.

Uma chave pode ser única, ou seja, identifica uma única linha em uma tabela, ou ainda não-única, permitindo identificar um conjunto de linhas (registros). A seguir listamos as chaves de acordo com essa classificação:

• Chaves Únicas: Chave Candidata, Chave Composta, Chave Primária, Chave Surrogada (ou ChaveSubstituta), Chave Alternativa
• Chave Não-Única (Non-Unique): Chave Estrangeira

Vamos detalhar um pouco mais cada tipo de chave a partir de agora.

Chave Candidata

• Atributo ou grupo de atributos com o potencial para se tornarem uma chave primária.
• Uma chave candidata que não seja usada como chave primária será conhecida como Chave Alternativa.

Exemplos: Os campos Num_Matrícula e CPF em uma tabela de registro de alunos são chaves candidatas, pois podem ser usados como chave primária.

Chave Primária

• É achave candidata escolhida para ser a chave principal na relação.
• A chave primária identifica de forma exclusiva os registros em uma tabela, não podendo haver repetição de valores nem tampouco valor nulo neste campo.
• Em inglês Primary Key / PK

Podemos indicar uma chave primária em um modelo de dados com um #, por exemplo #Cod_Livro, ou ainda sublinhando o nome do campo, como Cod_Livro.

Chave Estrangeira

• Uma chave estrangeira é uma coluna de uma tabela que estabelece um Relacionamento com a Chave Primária (PK) ou coluna unique de outra tabela relacionada.
• É a partir da chave estrangeira (Inglês: Foreign key / FK) que sabemos com qual registro em uma tabela B um registro em uma tabela A está relacionado. Assim, por exemplo, é possível saber qual livro foi vendido, em um sistema de uma livraria, pois o campo Cod_Livro (chave primária em uma tabela de cadastro de livros) estará presente em uma tabela de registro de vendas como chave estrangeira, apontando para o registro do livro especificado.

Chave Composta

• Trata-se de uma chave que é composta de dois ou mais atributos (colunas) combinados, formando uma combinação única, cujos valores nunca se repetem (mas podem se repetir isoladamente).
• Uma chave composta geralmente é empregada quando não é possível utilizar uma única coluna de uma tabela para identificar de forma exclusiva seus registros.

Chave Surrogada ou Chave Substituta

• Uma chave surrogada é um valor numérico, único, adicionado a uma relação para servir como chave primária, quando nenhuma chave candidata for identificada.
• Não possui significado para os usuários e geralmente fica escondida nas aplicações.
• As chaves substitutas são frequentemente usadas no lugar de uma chave primária composta, para simplificação dos relacionamentos.

Instruções para criação de chaves primárias e estrangeiras

Podemos seguir algumas recomendações simples para identificar e criar chaves primárias e chaves estrangeiras em uma tabela, como por eexmplo:

• Não é possível haver valores duplicados em uma chave primária
• No geral, não é possível alterar o valor de uma chave primária
• Chaves estrangeiras são baseadas em valores de dados, classificadas como ponteiros lógicos
• Um valor de uma chave estrangeira deve corresponder a um valor existente em uma chave primária associada (ou valor de chave única). Caso contrário, deve ser nulo (NULL)
• Uma chave estrangeira deve referenciar uma chave primária ou uma coluna de chave única.

Exemplo de chave primária e chave estrangeira

No exemplo a seguir temos três tabelas relacionadas: tbl_Clientes, tbl_Vendas e tbl_Produtos. A tabela de vendas possui duas chaves estrangeiras, que a relacionam com as tabelas de clientes e de produtos, permitindo assim saber qual produto está incluído na venda, e para qual cliente esse produto foi vendido.

O conceito de Domínio

• O conceito de Domínio em bancos de dados nos permite definir os tipos de dados usados em cada campo de uma tabela ou relação.
• Também permitem especificar valores que são válidos em um campo, de acordo com o tipo de dado e intervalo de valores possível para o tipo.

Conclusão

O conceito de chaves e seus tipos é de crucial importância no desenvolvimento de bancos de dados, pois a partir da determinação do campos que serão chaves primárias e estrangeiras é que poderemos estabelecer os relacionamentos entre as tabelas, em um modelo relacional.

Próximo: Cardinalidades em Relacionamentos

O post Modelagem de Dados – Tipos de Chaves apareceu primeiro em Bóson Treinamentos em Ciência e Tecnologia.

Artigo complementar do Curso Completo de Modelagem de Dados da Bóson Treinamentos no YouTube.

A integridade de dados se refere á acurácia, completude e consistência dos dados armazenados em um sistema de banco de dados relacional (ou outro sistema). Isso garante que os dados armazenados possam ser armazenados, consultados e utilizados com confiabilidade, sendo assim dados íntegros – daí o nome integridade de dados.

Trata-se, portanto, da manutenção e garantia da consistência e precisão dos dados, sendo um aspecto crítico no design, implementação e uso de sistemas de armazenamento de dados.

Para que seja possível garantir a integridade dos dados, é necessário conhecer e aplicar determinadas restrições de armazenamento, que chamamos de Restrições de Integridade, que dizem respeito a aspectos como tipos dos dados armazenados, relacionamentos entre colunas de chave primária e estrangeira, possibilidade de haver valores nulos ou não, e regras de negócio específicas importantes requisitadas pelo cliente, por exemplo.

Tipos de Restrições de Integridade

Os tipos de restrições de integridade que estudaremos neste artigo são os seguintes:

• Integridade Referencial
• Integridade de Domínio
• Integridade de Vazio
• Integridade de Chave
• Integridade Definida pelo Usuário

Vamos detalhar cada um deles a partir de agora.

Integridade de Domínio

Valores inseridos em uma coluna devem sempre obedecer à definição dos valores que são permitidos para essa coluna – os valores do domínio.

Ex.: em uma coluna que armazena preços de mercadorias, os valores admitidos são do domínio numérico – ou seja, apenas números. Não há preços usando letras para sua representação.

Integridade de Domínio: Fatores

Os seguintes fatores impactam a integridade de domínio:

• Tipo de Dado do campo
• Representação interna do tipo de dado
• Presença ou não do dado
• Intervalos de valores no domínio
• Conjuntos de valores discretos

Exemplo

Suponha um atributo Preço do Produto: Valor Monetário

• Valor permitido:
  • 25,33
• Valores não permitidos:
  • 25 Reais e 33 centavos
  • -32,33

Neste exemplo, não há preços usando letras ou valores negativos, e o valor 25,33 atende à integridade de domínio (numérico e positivo).

Integridade Referencial

Uma restrição de Integridade Referencial assegura que valores de uma coluna em uma tabela são válidos baseados nos valores em uma outra tabela relacionada.

Ex.: Se um produto de ID 523 foi cadastrado em uma tabela de Vendas, então um produto com ID 523 deve existir na tabela de Produtos relacionada.

Em resumo: cada valor de uma chave estrangeira deve corresponder a um valor de uma chave primária existente. Serve para manter a consistência entre tuplas de duas relações; Aparecem devido aos relacionamentos entre entidades

Exemplo

Atributo Nome_Produto: Caracteres

• Valores permitidos (produtos cadastrados):
  • Água
  • Refrigerante
  • Suco
• Valores não permitidos para venda (não existentes na tabela de produtos):
  • Cerveja

Neste exemplo, há um problema na Tabela de Bebidas: o item Cerveja viola a integridade referencial. Não é possível cadastrar uma venda com esse produto, pois ele não existe na tabela de produtos.

Integridade Referencial: Atualização e Exclusão de Registros

Se um registro for excluído em uma tabela (operações DELETE e TRUNCATE), então os registros relacionados em outras tabelas que o referenciam talvez precisem ser excluídos.

Caso contrário ocorrerá erro. O mesmo se dá com a atualização de registros (operação UPDATE).

Integridade de Vazio

Este tipo de integridade informa se a coluna é obrigatória ou opcional – ou seja, se é possível não inserir um valor na coluna.

Uma coluna de chave primária, por exemplo, sempre deve ter dados inseridos, e nunca pode estar vazia, para nenhum registro.

Valores Nulos – NULL

Um valor NULL significa que não existem dados disponíveis para o campo em particular. É diferente de zero, espaço, string vazia ou tabulação, que consistem em algo armazenado.

Os nulos podem ser problemáticos, pois indicam:

• O valor da coluna não é apropriado;
• O valor não foi inserido;
• O valor é desconhecido.

Exemplos de valores NULL

Suponha uma tabela de cadastro de alunos. Nesta tabela todo aluno deverá ter um nome cadastrado, de modo que esse campo é obrigatório (atributo não-nulo – NOT NULL)

Nem todo aluno possui telefone, portanto esse campo não é obrigatório (atributo nulo)

Valor nulo em uma tabela

Integridade de Chave

Os valores inseridos na coluna de chave primária (PK) devem ser sempre únicos, não admitindo-se repetições nesses valores. Desta forma, as tuplas (registros) serão sempre distintas.

Os valores de chave primária também não podem ser nulos.

Integridade Definida pelo Usuário

Diz respeito a regras de negócio específicas que são definidas pelo usuário do banco de dados. Por exemplo, pode-se definir que uma coluna somente aceitará um conjunto restrito de valores, como por exemplo apenas as siglas dos estados da federação, e mais nenhum outro valor diferente.

Conclusão

Conhecer as formas de integridade de dados é muito importante durante o processo de modelagem de dados, pois, é de crucial importância garantir de forma adequada que os dados armazenados sejam confiáveis e que possam ser utilizados com tranquilidade, senado sempre associados a outros dados, além de estarem sempre disponíveis.

Próximo: Dependências em Bancos de Dados

O post Modelagem de Dados – Restrições de Integridade em Bancos de Dados apareceu primeiro em Bóson Treinamentos em Ciência e Tecnologia.

As restrições de chave estrangeira em tabelas de bancos de dados relacionais são um tipo especial de restrições (constraints) definidas e empregadas para excluir ou atualizar linhas em uma tabela referenciada, quando uma operação de um desses tipos ocorre em uma tabela relacionada.

As ações de exclusão e atualização são as seguintes:

• ON DELETE CASCADE – Uma operação de exclusão em uma tabela referenciada se propaga (cascade = em cascata) para as chaves estrangeiras correspondentes. Ou seja, ao excluir um registro em uma tabela, um registro relacionado em outra tabela é automaticamente excluído. Por exemplo, se uma editora de uma tabela de editoras for excluída, os livros da tabela de livros relacionados com esta editora também serão excluídos automaticamente.
• ON DELETE SET NULL – Quando ocorre uma operação de exclusão em uma tabela referenciada, as chaves estrangeiras relacionadas são definidas com valor NULL. Note que os campos de chave estrangeira precisam estar definidos como NULL (aceitar nulos) para que essa operação tenha sucesso.
• ON DELETE SET DEFAULT – Ao ocorrer uma operação de exclusão em uma tabela referenciada, as chaves estrangeiras relacionadas em outras tabelas são definidas com um valor padrão (default).
• ON UPDATE CASCADE – Uma operação de atualização em uma tabela referenciada se propaga para as chaves estrangeiras correspondentes. Ou seja, ao modificar um registro em uma tabela, um registro relacionado em uma coluna de chave estrangeira em outra tabela tem seu valor automaticamente atualizado.
• ON UPDATE SET NULL – Quando uma operação de atualização em uma tabela referenciada é realizada, as chaves estrangeiras relacionadas são definidas com valor NULL. Novamente, os campos de chave estrangeira precisam estar definidos como NULL (aceitar nulos) para que a operação tenha sucesso.
• ON UPDATE SET DEFAULT – Ao ocorrer uma operação de atualização em uma tabela referenciada, as chaves estrangeiras relacionadas em outras tabelas serão definidas com um valor padrão.

Portanto, usamos a opção CASCADE quando há uma restrição de existência obrigatória para um campo de chave estrangeira de uma tabela. Já as opções SET NULL e DEFAULT se aplicam quando a existência de um valor é opcional no campo de chave estrangeira.

DELETE RESTRICTED e UPDATE RESTRICTED

Alguns sistemas de bancos de dados, como o IBM DB2, possuem restrições de chave estrangeira adicionais, como explicado a seguir:

• DELETE RESTRICTED – Linhas na tabela referenciada (com a chave primária) somente podem ser excluídas se não houver valores de chave estrangeira correspondentes na tabela relacionada. Ou seja, só podemos excluir uma linha na tabela se ainda não existir nenhum registro relacionado com um valor de chave primária da tabela. Por exemplo, somente é possível excluir um autor da tabela de autores se ainda não houver nenhum livro daquele autor cadastrado na tabela de livros (onde o ID do autor é a chave estrangeira do relacionamento).
• UPDATE RESTRICTED – Idem ao anterior, porém para a operação de atualização de registros na tabela.

Veja exemplos da aplicação dessas restrições em um banco de dados MySQL aqui.

O post Restrições de Chave Estrangeira – ON DELETE CASCADE e outras em Bancos de Dados apareceu primeiro em Bóson Treinamentos em Ciência e Tecnologia.

Grande parte das consultas a um banco de dados se referem a somente uma pequena parcela dos registros armazenados nas tabelas. Por exemplo, uma consulta do tipo “retorne todos os livros do autor C.J. Date” se refere a apenas uma ínfima parte do total de registros de livros em uma biblioteca ou livraria. É altamente ineficiente para o SGBD ter de ler cada registro na tabela para verificar se o autor é o Date; de forma ideal, o sistema deveria conseguir localizar esses registros diretamente. Para isso, criamos estruturas especiais nas tabelas, chamadas de Índices.

Os índices são uma das ferramentas de otimização mais conhecidas e utilizadas pelos desenvolvedores de bancos de dados.

O emprego de indexação em tabelas pode aumentar significativamente a performance em consultas ao banco de dados, porém pode diminuir a velocidade de transações como inserts e updates. Portanto, saber quais tarefas são mais importantes no sistema em questão – se de leitura ou de escrita – nos dá um ponto de partida para saber como lidar com a indexação.

No geral, é interessante termos mais de um índice em uma tabela. O atributo (ou conjunto de atributos) usado para procurar registros em uma tabela é chamado de chave de procura.

Por padrão, os SGBDs criam índices automaticamente para campos de:

• Chave Primária
• Chave Estrangeira
• Constraint UNIQUE

Além disso, podemos criar índices para outras colunas usadas com frequência em buscas ou junções.

Classificamos os índices em duas grandes categorias:

• Índices Clusterizados (primários)
• Índices Não-Clusterizados (secundários).

Índice Clusterizado

Os Índices clusterizados alteram a forma como os dados são armazenados em um banco de dados, pois ele classifica as linhas de acordo com a coluna que possui o índice. Uma tabela só pode ter um índice clusterizado. Geralmente ele está na coluna que é chave primária da tabela ou, em sua ausência, em uma coluna UNIQUE.
Caso uma tabela não possua um índice clusterizado, suas linhas são armazenadas em uma estrutura não-ordenada chamada de heap.

Normalmente, a chave de busca de um índice primário é a chave primária da tabela (mas nem sempre).

Índice Não-Clusterizado

Em um índice não-clusterizado a forma como os dados são armazenados em disco não é alterada, e um objeto separado é criado na tabela, apontando para as linhas da tabela original após a busca. Este tipo de índice se baseia em valores-chave.

Uma tabela pode ter vários índices não-clusterizados.

Os índices secundários melhoram o desempenho das consultas que usam chaves diferentes da chave de procura do índice primário. O projetista do banco de dados deve decidir quais índices não-clusterizados devem ser criados com base na estimativa da frequência de consultas e atualizações dos registros.

Tipos de índices

Existem vários tipos de índices que podem ser criados em tabelas, de acordo com técnicas variadas. Os mais comuns são:

• Índice em Árvore B (B-Tree): Um índice de árvore balanceada possui acesso eficiente para consultas de intervalos. A atualização de uma árvore b é relativamente eficiente, porém seu desempenho pode se degradar conforme o arquivo aumenta de tamanho. É a mais utilizada das estruturas de índices, geralmente sendo o padrão ao criar um novo índice. Uma árvore balanceada significa que todos os caminhos a partir da raiz da árvore até uma de suas folhas são do mesmo comprimento. Colunas com muitos poucos valores (em termos de variedade) – baixa cardinalidade, como valores do tipo sim/não, masculino/feminino/neutro, conjuntos de cores e outros, não se beneficiam de índices do tipo b-tree.
• Índice de Bitmap: Eficientes para consultas que envolvam conjuntos de valores ou baixa cardinalidade, porém se torna menos eficiente se o conjunto se tornar demasiado grande. A atualização de um índice de bitmap é relativamente ineficiente. Esse tipo de índice emprega arrays de bits para verificar se um valor em particular está ou não presente em uma linha, e responde às consultas efetuando operações lógicas bitwise nesses arrays.
• Índice de Hashing: Organiza as chaves de procura, com seus ponteiros associados, em uma estrutura de arquivo de hash. Eficientes para acesso a linhas especificas (não intervalos). Pode ser usado para implementar junções (joins) de modo eficiente.
• Índice de Várias Tabelas (Multi-Table): ou índices de junção. Contém ponteiros para linhas de diversas tabelas. Pode melhorar o desempenho de junções e da verificação de restrições de integridade de banco de dados.
• Índice Booleano: Muito úteis quando uma expressão booleana relevante é componente de condições de restrição.
• Índice Funcional: Executa a indexação das linhas de uma tabela com base no resultado da chamada de alguma função especificada sobre os valores das linhas, em vez de indexar com base nos valores em si.

A figura a seguir ilustra a estrutura de um índice não-clusterizado do tipo árvore balanceada (b-tree):

Árvore Balanceada – Índice B-Tree

No exemplo da figura, o algoritmo de árvore balanceada aumenta o desempenho de consultas que tenham seu resultado filtrado pelo nome da pessoa, que é a coluna com valor-chave indexado. Por exemplo, se for realizada uma consulta que precise retornar dados da pessoa de nome “Barbara”, usando essa coluna como critério de filtragem na cláusula WHERE, o processo será realizado acessando o nó raiz, determinando o próximo nó a acessar –  que é o nó intermediário A-G, onde se encontra a inicial “B” do nome buscado – e então acessando diretamente o registro desejado no nó-folha cuja chave possui dados iniciados com a letra “B”.

Recomenda-se não indexar tabelas pequenas (que possuam poucos registros); um escaneamento completo da tabela (full table scan) acaba por ser a alternativa mais rápida para obter o resultado de uma consulta neste caso.

E como criamos índices em uma tabela? Confira exemplos nesta lição sobre índices em MySQL.

O post O que são Índices em Bancos de Dados – Indexação em Tabelas apareceu primeiro em Bóson Treinamentos em Ciência e Tecnologia.

Um Banco de Dados (BD) é uma coleção organizada de dados. Esses dados são organizados de modo a modelar aspectos do mundo real, para que seja possível efetuar processamento que gere informações relevantes para os usuários a partir desses dados.

Existem vários modelos de bancos de dados, desenvolvidos ao longo do tempo, e o mais utilizado atualmente é o Modelo Relacional, que apresentamos nesta lição.

Os princípios do modelo relacional foram esboçados pelo matemático britânico E. F. Codd (na IBM) em um artigo publicado em junho de 1970, intitulado “A Relational Model of Data for Large Shared Data Banks“, no qual o Dr. Codd propôs o modelo relacional para sistemas de bancos de dados.

Antes disso eram usados outros modelos como o modelo de dados hierárquico e o modelo em rede.

No modelo relacional os dados são organizados em coleções de tabelas bidimensionais. Essas tabelas são também chamadas de “Relações”.
Desta forma, uma Relação é uma forma de se organizar os dados em linhas e colunas.
O modelo relacional é baseado em lógica e na teoria de conjuntos da matemática.

Composição do Modelo Relacional

O modelo relacional é composto, basicamente, pelos seguintes elementos:

• Coleções de objetos ou relações que armazenam os dados
• Um conjunto de operadores que agem nas relações, produzindo outras relações
• Integridade de dados, para precisão e consistência.

Banco de Dados Relacional

Um Banco de dados relacional é uma coleção de relações, que são tabelas bidimensionais, onde os dados são armazenados.
Como exemplo, podemos querer armazenar dados sobre os clientes de uma loja. Para isso, criamos tabelas para guardar diferentes conjuntos de dados relacionados a esses clientes, como dados pessoais, dados de compras, crédito, e outras. Cada uma dessas tabelas é uma relação do banco.

Obs.: Não confunda o termo Relação com Relacionamento, que também faz parte do modelo relacional, porém são conceitos distintos e que serão explicados em detalhes neste e nos próximos artigos.

Componentes de um Banco de Dados Relacional

Diversos tipos de objetos fazem parte de um banco de dados relacional. Listamos os mais importantes a seguir:

• Tabela: estrutura básica de armazenamento no SGBDR. Armazena todos os dados necessários sobre algo do mundo real, como clientes, pedidos ou produtos. também chamada de Relação. Um banco de dados relacional pode conter uma ou mais Tabelas
• Tupla: ou Linha / Registro, representa todos os dados requeridos por uma determinada ocorrência de entidade em particular. Por exemplo, os dados de um cliente específico. Cada linha em uma tabela deve ser identificada por uma chave primária, de modo a não haver duplicação de registros.
• Coluna ou Campo: Unidade que armazena um tipo específico de dado (valor) – ou não armazena nada, com valor nulo. Esta é uma coluna não-chave, significando que seu valor pode se repetir em outras linhas da tabela.
• Relacionamento: Associação entre as entidades (tabelas), conectadas por chaves primárias e chaves estrangeiras.
• Chave Primária (Primary Key  / PK) :coluna (atributo) que identifica um registro de forma exclusiva na tabela. Por exemplo, o CPF de um cliente, contendo um valor que não se repete na relação.
• Chave Estrangeira (Foreign Key / FK): coluna que define como as tabelas se relacionam umas com as outras. Uma FK se refere a uma PK ou a uma chave única em outra tabela (ou na mesma tabela!). Por exemplo, na tabela de pedidos podemos ter uma chave estrangeira efetuando o relacionamento com a chave primária na tabela de clientes.
• Restrições (Constraints): Propriedades específicas de determinadas colunas de uma relação, como por exemplo se a coluna pode aceitar valores nulos ou não.
• Outros: Índices, Stored Procedures, Triggers, etc.

Elementos de um Banco de Dados Relacional

Nas próximas lições vamos explorar os conceitos de banco de dados relacional apresentados de forma aprofundada, além de introduzir o processo de Modelagem de Dados.

O post O que é um Banco de Dados Relacional apareceu primeiro em Bóson Treinamentos em Ciência e Tecnologia.