A Manipulação de Strings (cadeias de caracteres) é uma tarefa trivial em bancos de dados e programação em geral. Tarefas como contar caracteres de uma string, converter letras de maiúsculas para minúsculas e vice-versa, obter partes de uma palavra ou frase, limpar caracteres indesejados e diversas outras são realizadas de forma corriqueira para tratar os dados que são armazenados e consultados em bancos de dados.

Os SGBDs possuem, normalmente, diversas funções internas que permitem realizar essas tarefas, e o Microsoft SQL Server possui um bom conjunto de funções de manipulação de strings disponível.

Neste artigo, veremos algumas das funções para manipular caracteres mais comuns presentes no SQL Server, com suas sintaxes, aplicações e exemplos práticos de uso.

Funções de Manipulação de Strings no SQL Server

As funções que serão vistas nesse artigo são as seguintes:

• Função LEN
• Função LOWER
• Função UPPER
• Função LTRIM
• Função RTRIM
• Função TRIM
• Função LEFT
• Função RIGHT
• Função REPLACE
• Função SUBSTRING
• Função CONCAT

Função LEN

LEN(expressão)

SELECT NomeLivro, LEN(NomeLivro) 'Tamanho do Título'
FROM Livro;

SELECT NomeLivro, ISBN13, LEN(ISBN13) AS 'Tamanho do ISBN'
FROM Livro
WHERE LEN(ISBN13) <> 13;

SELECT Nome_Livro, LEN(Nome_Livro)  'Tamanho do Título'
FROM tbl_Livro
WHERE LEN(Nome_Livro) = (
    SELECT MIN(LEN(Nome_Livro))
    FROM tbl_Livro
);

SELECT NomeLivro
FROM Livro
ORDER BY LEN(NomeLivro) ASC;

SELECT NomeEditora, LEN(NomeEditora) AS Tamanho_Nome
FROM Editora
WHERE LEN(NomeEditora) = 10;

SELECT NomeAutor, SobrenomeAutor, LEN(NomeAutor) + LEN(SobrenomeAutor) AS 'Tamanho do Nome Completo'
FROM Autor
WHERE (LEN(NomeAutor) + LEN(SobrenomeAutor)) > 20;

Funções LOWER e UPPER

LOWER(expressão)
UPPER(expressão)

SELECT NomeLivro, LOWER(NomeLivro) AS 'Nome Minúsculo'
FROM Livro;

SELECT NomeLivro
FROM Livro
WHERE LOWER(NomeLivro) = 'a arte da eletrônica';

SELECT UPPER(NomeAssunto) AS Assunto
FROM Assunto;

INSERT INTO Autor (NomeAutor, SobrenomeAutor)
VALUES (UPPER('Fábio'), UPPER('dos Reis'));

SELECT NomeAutor, SobrenomeAutor,
    UPPER(NomeAutor) AS NomeMaiusculo,
    UPPER(SobrenomeAutor) AS SobrenomeMaiusculo
FROM Autor;

Funções LTRIM, RTRIM e TRIM

LTRIM(expressão)
RTRIM(expressão)
TRIM([caracteres FROM] expressão)

• expressão: string que será modificada.
• caracteres: Caracteres que se deseja remover. Se omitido, remove espaços em branco.

SELECT NomeLivro, LTRIM(NomeLivro) 'Nome Ajustado'
FROM Livro;

SELECT NomeEditora, RTRIM(NomeEditora) AS 'Nome da Editora Ajustado'
FROM Editora;

SELECT NomeLivro, TRIM(NomeLivro) AS NomeLivroAjustado
FROM Livro;

SELECT NomeLivro, TRIM('*' FROM NomeLivro) AS NomeLivroLimpo
FROM Livro;

UPDATE Editora
SET NomeEditora = TRIM(NomeEditora);

INSERT INTO Autor (NomeAutor, SobrenomeAutor)
VALUES (TRIM(' Fábio '), TRIM(' dos Reis '));

Funções LEFT e RIGHT

LEFT(string, número_de_caracteres)

• string: A string original da qual se deseja extrair os caracteres.
• número_de_caracteres: O número de caracteres a ser extraído, começando pela esquerda.

RIGHT(string, número_de_caracteres)

SELECT ISBN13,
    RIGHT(ISBN13, 4) AS 'Título e DV'
FROM Livro;

SELECT NomeAutor,
    LEFT(NomeAutor, 2) AS 'Iniciais Autor'
FROM Autor;

SELECT NomeLivro,
    LEFT(CAST(DataPub AS VARCHAR), 4) AS AnoPublicacao
FROM Livro;

Função REPLACE

REPLACE(string_original, substring_antiga, substring_nova)

• string_original: A string na qual a substituição será realizada.
• substring_antiga: O texto que será substituído.
• substring_nova: O novo texto que substituirá a substring antiga.

UPDATE Livro
SET NomeLivro = REPLACE(NomeLivro, '2010', '2020')
WHERE NomeLivro LIKE '%Server 2010%';
-- Teste:
SELECT * FROM Livro;

UPDATE Livro
SET ISBN13 = REPLACE(ISBN13, '-', '')
WHERE ISBN13 LIKE '%-%';

Função SUBSTRING

SUBSTRING(expressão, início, comprimento)

• expressão: A expressão de string ou a coluna da qual se deseja extrair uma parte.
• início: A posição inicial (1 baseada) da extração.
• comprimento: O número de caracteres a serem extraídos.

SELECT NomeLivro, SUBSTRING(NomeLivro, 1, 3) AS SiglaLivro
FROM Livro;

UPDATE Editora
SET NomeEditora = UPPER(NomeEditora);

SELECT * FROM Editora;

UPDATE Editora
SET NomeEditora = UPPER(LEFT(NomeEditora, 1)) + LOWER(SUBSTRING(NomeEditora, 2, LEN(NomeEditora)))
WHERE NomeEditora IS NOT NULL;

SELECT NomeLivro, DataPub, SUBSTRING(DataPub, 1, 4) AS AnoPublicacao
FROM Livro;

Função CONCAT

CONCAT(valor1, valor2, valor3, ...)

• valor1, valor2, …: Valores que serão concatenados. Podem ser colunas, literais ou expressões.

SELECT CONCAT('Fábio ', 'dos Reis') AS 'Nome Cliente';

SELECT CONCAT(NomeAutor, ' ', SobrenomeAutor) AS 'Nome Completo do Autor'
FROM Autor;

SELECT NomeLivro,
    ISBN13,
    CONCAT(NomeLivro, ' (ISBN: ', ISBN13, ')') AS LivroComISBN
FROM Livro;

SELECT NomeLivro,
    DataPub,
    CONCAT('O livro "', NomeLivro, '" foi publicado em ', DataPub) AS DescricaoPublicacao
FROM Livro;

Conclusão

O post Funções de Manipulação de Strings no SQL Server apareceu primeiro em Bóson Treinamentos em Ciência e Tecnologia.

Procedimentos armazenados são uma forma de armazenar a lógica do banco de dados no lado do servidor e podem ser executados por vários clientes. Eles são uma ferramenta muito útil para administradores e programadores de banco de dados, pois permitem encapsular a lógica complexa em uma única unidade chamável, reduzindo o código duplicado, aumentando a segurança e melhorando o desempenho.

Um procedimento armazenado no PostgreSQL é um bloco nomeado de instruções PL/pgSQL que podem ser executadas com um único comando. A sintaxe para criar um procedimento armazenado no PostgreSQL é a seguinte:

CREATE [OR REPLACE PROCEDURE] nome_procedimento(arg1 tipo_dado1, arg2 tipo_dado2, ...)
RETURNS tipo_dado_retorno
LANGUAGE plpgsql
AS $$
DECLARE
-- declaração de variáveis locais, se houver
BEGIN
-- declarações PL/pgSQL
END;
$$;

Onde:

• nome_procedimento é o nome do procedimento armazenado
• arg1, arg2, etc. são os parâmetros do procedimento armazenado
• tipo_dado1, tipo_dado2, etc. são os tipos de dados dos parâmetros
• tipo_dado_retorno é o tipo de dados do valor de retorno

e a seção DECLARE é usada para declarar variáveis locais, se necessário. A lógica real do procedimento armazenado é escrita dentro de blocos BEGIN e END, usando instruções da linguagem PL/pgSQL.

A cláusula LANGUAGE especifica o idioma do procedimento armazenado, que é plpgsql neste caso.

O símbolo $$

O símbolo $$ usado na última linha de um procedimento PL/pgSQL é usado para definir o início e o fim do corpo do procedimento. É uma sintaxe especial usada para definir uma string literal que abrange várias linhas. Na prática, é possível usar qualquer string com essa finalidade, desde que não seja uma palavra reservada da linguagem.

Em um procedimento PL/pgSQL, o $$ é usado para envolver todo o corpo do procedimento, que inclui a declaração de variáveis, a definição de estruturas de controle e qualquer outra lógica que você queira implementar. O primeiro $$ marca o início do corpo do procedimento e o segundo $$ marca o fim do corpo do procedimento.

Outra opção é usar a estrutura “BEGIN ATOMIC” … “END” no lugar de “AS $$“.

O que é PL/pgSQL?

PL/pgSQL é uma linguagem procedural usada no PostgreSQL para escrever stored procedures, triggers e funções. É uma linguagem estruturada em blocos semelhante a outras linguagens procedurais, como PL/SQL no Oracle e T-SQL no Microsoft SQL Server. Essa linguagem fornece estruturas de controle, como instruções IF-THEN-ELSE, LOOP e EXIT, bem como a capacidade de declarar variáveis, realizar tratamento de exceções e usar cursores.

O PL/pgSQL oferece uma interface procedural de alto nível para o banco de dados que permite criar lógica de negócios complexa e automatizar as operações do banco de dados. Por exemplo, podemos usar PL/pgSQL para implementar regras de negócios, validar dados ou realizar cálculos complexos em dados armazenados no banco de dados.

Assim, podemos escrever lógica que pode ser facilmente testada e reutilizada, tornando-a uma maneira eficiente de gerenciar operações de banco de dados.

Trata-se de uma linguagem do lado do servidor, o que significa que o código é executado no servidor de banco de dados, e não no cliente. Isso o torna mais rápido e eficiente do que executar o script do lado do cliente, dentro de uma aplicação de usuário, além de fornecer melhor segurança para seus dados.

Outras opções de linguagens suportadas pelo Postgres incluem SQL padrão e linguagem C, além da possibilidade de trabalhar com extensões para outras linguagens como PL/Python, PL/Perl, etc.

A instrução LANGUAGE plpgsql é necessária ao criar procedimentos armazenados no PostgreSQL porque define a linguagem de programação que será usada para escrever o corpo do procedimento.

Como executar o procedimento armazenado

Podemos chamar um procedimento armazenado no PostgreSQL usando a seguinte sintaxe:

CALL nome_procedimento(arg1_valor, arg2_valor, ...);

Aqui, arg1_valor, arg2_valor, etc. são os valores dos parâmetros passados para o procedimento armazenado. O resultado do procedimento armazenado será retornado na forma de uma tabela.

Vejamos agora alguns exemplos de criação e execução de procedimentos armazenados em PostgreSQL.

Exemplo 01 – Inserir uma linha em uma tabela

Procedimento armazenado em PostgreSQL (somente SQL) que insere uma nova linha em uma tabela, composta por três colunas: nome, sobrenome e idade:

Criar a tabela de teste:

CREATE TABLE pessoas (
    nome varchar(20),
    sobrenome varchar(40),
    idade smallint
);

Vamos a um exemplo de procedimento armazenado em PL/pgSQL que insere uma nova linha em uma tabela com três colunas: nome, sobrenome e idade. O procedimento armazenado usa três parâmetros: p_nome, p_sobrenome e p_idade e insere esses valores na tabela.

CREATE OR REPLACE PROCEDURE cadastra_pessoa(p_nome varchar(20), p_sobrenome varchar(40), p_idade smallint)
  LANGUAGE plpgsql
AS $$
BEGIN
    INSERT INTO pessoas (nome, sobrenome, idade)
    VALUES (p_nome, p_sobrenome, p_idade);
END
$$

Teste

Para executar o procedimento armazenado, basta chamá-lo com os valores desejados como parâmetros, assim:

CALL cadastra_pessoa('Fábio'::varchar, 'dos Reis'::varchar, 48::smallint);

E verificar se a tabela foi atualizada com o novo registro:

SELECT * FROM pessoas;

Especificar tipos de dados na chamada do procedimento

Ao chamar um procedimento armazenado no PostgreSQL, a necessidade de especificar explicitamente os tipos de dados para os argumentos (por exemplo, ‘Fábio’::varchar) geralmente surge devido a questões de desambiguação e coerção de tipos.

Os principais motivos para especificar tipos de dados ao chamar um procedimento armazenado no PostgreSQL são os seguntes:

1. Desambiguação: Quando o PostgreSQL possui múltiplos procedimentos com o mesmo nome, mas com assinaturas diferentes (ou seja, com diferentes tipos de parâmetros ou números de parâmetros), ele precisa saber exatamente qual procedimento deve ser chamado. Especificar o tipo de dado ajuda o PostgreSQL a escolher a versão correta do procedimento.
2. Coerção de Tipos: O PostgreSQL é uma linguagem fortemente tipada, o que significa que cada valor tem um tipo de dado associado, e algumas operações requerem tipos específicos. Quando se passa um literal (como ‘Fábio‘), ele é inicialmente interpretado como um text, a menos que se indique explicitamente um tipo diferente, como o varchar.
3. Prevenção de Erros de Tipagem: Quando o tipo de dado esperado pelo procedimento não corresponde ao tipo inferido pelo PostgreSQL, o banco de dados pode não ser capaz de fazer a coerção automaticamente, resultando em erros. Especificar o tipo assegura que o valor será tratado corretamente.

Exemplo 02 – Inserir um novo produto na tabela

Vamos criar um procedimento armazenado que permita inserir um novo produto na tabela de produtos de nosso banco de dados.

CREATE OR REPLACE PROCEDURE inserir_produto (
    p_cod_produto INT,
    p_nome_produto VARCHAR(30),
    p_descricao TEXT,
    p_preco NUMERIC,
    p_qtde_estoque SMALLINT
)
language plpgsql
AS $$
BEGIN
    INSERT INTO Produtos(cod_produto, nome_produto, descricao, preco, qtde_estoque)
    VALUES (p_cod_produto, p_nome_produto, p_descricao, p_preco, p_qtde_estoque);
    RAISE NOTICE 'Produto % cadastrado com sucesso.', p_nome_produto;
END;
$$;

A instrução RAISE NOTICE emite uma mensagem para o console confirmando a inserção do registro.

Para executar o procedimento:

CALL inserir_produto(4,'Detergente'::varchar,'Detergente neutro 500 ml'::text, 2.35, 2::smallint);

E então podemos verificar se produto foi inserido corretamente realizando uma consulta simples ao banco de dados:

SELECT * FROM Produtos;

Exemplo 03 – Atualizar o preço de um produto.

Este procedimento atualiza o preço de um produto específico, identificado pelo seu código de produto:

CREATE OR REPLACE PROCEDURE atualizar_preco(
    p_cod_produto INT,
    p_novo_preco NUMERIC
)
LANGUAGE plpgsql
AS $$
BEGIN
    UPDATE Produtos
    SET preco = p_novo_preco
    WHERE cod_produto = p_cod_produto;
    RAISE NOTICE 'Preço do produto % atualizado para %', p_cod_produto, p_novo_preco;
END;
$$;

Para executar o procedimento:

CALL atualizar_preco(1, 3.80);

E então podemos verificar se produto teve seu preço corretamente atualizado realizando novamente uma consulta ao banco de dados:

SELECT * FROM Produtos;

Exemplo 04 – Procedimento para consultar produtos com estoque baixo

Este procedimento retorna todos os produtos com quantidade em estoque abaixo de um valor especificado na chamada da procedure.

CREATE OR REPLACE PROCEDURE consultar_estoque_baixo (
    p_limite_estoque INTEGER
)
LANGUAGE plpgsql
AS $$
DECLARE resultado RECORD;
BEGIN
    FOR resultado in
        SELECT cod_produto, nome_produto, qtde_estoque
        FROM Produtos
        WHERE qtde_estoque < p_limite_estoque
    LOOP
        RAISE NOTICE 'Produto: %, Estoque: % ', resultado.nome_produto, resultado.qtde_estoque;
    END LOOP;
END;
$$;

Para executar o procedimento:

CALL consultar_estoque_baixo(3);

Aqui, consultamos todos os produtos cujo estoque está abaixo de 3 unidades.

Devemos notar alguns detalhes interessantes sobre a consulta realizada pelo procedimento armazenado deste exemplo:

Destino dos dados

Quando se usa a instrução SELECT em um procedimento armazenado no PostgreSQL, o resultado deve ser direcionado para algum lugar, como uma variável, uma tabela temporária, ou ser retornado ao chamador da função ou procedimento.

Caso contrário, o PostgreSQL gera a mensagem “consulta não tem destino para os dados resultantes” (no inglês: “query has no destination for result data“).

Se for necessário apenas exibir os resultados no console em um procedimento armazenado, sem retorná-los em uma consulta, podemos usar um loop para iterar sobre os resultados e então exibi-los com RAISE NOTICE.

O tipo RECORD

O tipo RECORD é um tipo de dado genérico no PL/pgSQL que pode acomodar uma linha de dados com colunas de diferentes tipos. Ao contrário de outros tipos de variáveis, que têm um tipo de dado específico (como INTEGER, VARCHAR, etc.), o RECORD pode armazenar qualquer linha inteira de resultado, independentemente de quantas colunas ou de quais tipos de dados essas colunas têm.

A instrução DECLARE r RECORD; em PL/pgSQL é usada para declarar uma variável de tipo RECORD.

Quando usamos o RECORD dentro de um loop FOR IN que itera sobre os resultados de uma consulta, o RECORD é automaticamente “preenchido” com os valores das colunas para cada linha retornada. Isso permite acessar os valores dessas colunas dentro do corpo do loop.

Além disso, uma vez que a linha é armazenada no RECORD, podemos acessar as colunas individuais usando a notação r.coluna, onde r é o nome da variável RECORD e coluna é o nome da coluna que desejamos acessar.

Exemplo 05 – Inserir e atualizar valores no mesmo procedimento.

Exemplo: criar um procedimento armazenado que insira um novo produto na tabela de produtos, ao mesmo tempo em que aplica um desconto percentual especificado a todos os produtos logo após.

CREATE OR REPLACE PROCEDURE insere_atualiza (cod int, prod varchar(30), descr text, valor numeric, qtde smallint, desc_perc numeric)
LANGUAGE plpgsql
AS $$
BEGIN
    INSERT INTO produtos(cod_produto, nome_produto, descricao, preco, qtde_estoque)
    VALUES (cod, prod, descr, valor, qtde);
    UPDATE produtos SET preco = preco * (100 - desc_perc) / 100;
END;
$$;

Executar o procedimento:

CALL insere_atualiza(6,'Alvejante'::varchar(30),'Alvejante de roupas'::text, 12.30, 12::smallint, 10);

Obs.: O tipo numeric geralmente não precisa ser informado (cast) na chamada do procedimento.

Como excluir um procedimento armazenado

Para excluir um procedimento armazenado no PostgreSQL devemos usar a declaração DROP PROCEDURE, como segue:

DROP PROCEDURE nome_procedimento;

Por exemplo, para excluir o procedimento consultar_estoque_baixo:

DROP PROCEDURE consultar_estoque_baixo;

Se houver mais de um procedimento armazenado como mesmo nome, mas com quantidade e tipos de parâmetros distintos (polimorfismo), devemos indicar os tipos de dados dos argumentos ao exclui-lo:

DROP PROCEDURE insere_atualiza(int,varchar,text,numeric,smallint,numeric);

Conclusão

Neste artigo vimos como começar a trabalhar com procedimentos armazenados no PostgreSQL. com alguns exemplos simples de criação de procedures simples. O recurso é muito útil para simplificar código e facilitar a programação de tarefas no banco de dados, principalmente quando as declarações SQL precisam ser executadas a partir de uma aplicação escrita em alguma linguagem de programação para acesso direto dos usuários.

Estudaremos recursos mais avançados de procedimentos armazenados nos próximos artigos, assim como outras formas de programação existentes para bancos de dados PostgreSQL, como Funções e Triggers.

Para saber mais sobre Procedimentos Armazenados no PostgreSQL, assista ao vídeo a seguir da Bóson Treinamentos no YouTube:

O post Procedimentos Armazenados em PostgreSQL (Stored Procedures) apareceu primeiro em Bóson Treinamentos em Ciência e Tecnologia.

A cláusula DELETE FROM em SQL é usada para remover registros de uma tabela. Esta cláusula permite apagar uma ou mais linhas de uma tabela com base em uma condição especificada na cláusula WHERE. Se a cláusula WHERE não for usada, todos os registros da tabela serão removidos (cuidado!!!).

Sintaxe Básica

DELETE FROM nome_da_tabela
WHERE condição;

Exemplos

1. Apagar registros específicos

Se quisermos remover todos os livros da tabela Livro cujo preço é maior que R$ 100,00:

DELETE FROM Livro
WHERE PrecoLivro > 100.00;

2. Apagar todas as linhas de uma tabela

Podemos remover todos os registros da tabela Autor, deixando a tabela vazia:

DELETE FROM Autor;

Observações importantes

Integridade Referencial: Ao excluir registros que são referenciados por chaves estrangeiras em outras tabelas, é importante considerar as restrições de integridade referencial para evitar a violação dessas restrições.
Backups: Antes de executar operações de exclusão em massa, é altamente recomendável fazer backup dos dados, pois a operação de DELETE é irreversível (não tem Ctrl+Z!!!).
Performance: Para limpar totalmente tabelas grandes, operações de DELETE podem ser lentas e consumir muitos recursos. Em alguns casos, pode ser mais eficiente truncar a tabela (usando TRUNCATE TABLE) ou recriá-la.

Para saber mais sobre SQL DELETE, assista a um vídeo 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 Como apagar linhas de uma tabela com DELETE FROM – SQL Server apareceu primeiro em Bóson Treinamentos em Ciência e Tecnologia.

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.

Em um artigo anterior mostrei como carregar um arquivo CSV em uma tabela no MySQL. Agora vou mostrar como realizar o processo inverso – como exportar os dados de uma tabela de um banco de dados MySQL para um arquivo CSV, usando declarações SQL.

Para tal usaremos a declaração SQL INTO OUTFILE (literalmente, “dentro de um arquivo externo“), cuja sintaxe básica é a seguinte:

SELECT colunas
FROM tabela
INTO OUTFILE 'caminho/arquivo.csv'
FIELDS TERMINATED BY 'delimitador'
ENCLOSED BY 'caractere'
LINES TERMINATED BY 'tipo_quebra';

Onde temos que:

• SELECT – Aqui informamos os nomes das colunas que farão parte do arquivo CSV
• FROM – Especificamos a tabela a ser consultada (para incluir dados de mais de uma tabela, podemos usar INNER JOIN)
• INTO OUTFILE – Determina o nome do arquivo e local onde o conteúdo da tabela será exportado no formato CSV.
• FIELDS TERMINATED BY – Aqui devemos informar qual delimitador (separador de campos) é desejado no arquivo CSV.
• ENCLOSED BY – Usado para especificar que aspas duplas “” englobam valores de dados
• LINES TERMINATED BY – Especifica o código ou caractere usado para indicar quebra de linha.

Vamos a alguns exemplos de exportação de arquivos CSV no MySQL.

Exemplo 01

Vejamos um exemplo, usando a tabela de autores que importamos na lição passada. Vamos exportar o conteúdo dessa tabela para um arquivo CSV de nome autores_bkp.csv:

SELECT ID_autor, Nome_Autor, Sobrenome_Autor
FROM tbl_autores
INTO OUTFILE 'C:/SQL/autores_bkp.csv';

Tabela exportada como CSV

Se nenhuma opção for informada, será empregado o caractere de tabulação como delimitador, por padrão.

Exemplo 02

Podemos especificar um delimitador diferente e outras configurações da seguinte forma:

SELECT ID_autor, Nome_Autor, Sobrenome_Autor
FROM tbl_autores
INTO OUTFILE 'C:/SQL/autores_bkp.csv'
FIELDS TERMINATED BY ','
ENCLOSED BY '"'
LINES TERMINATED BY '\n';

Tabela exportada com opções diferentes

Neste caso usamos a vírgula como delimitador, e as aspas duplas “” para englobar os valores de dados.

Exemplo 03

E se quisermos incluir também os nomes das colunas como títulos? Neste caso, podemos usar a declaração UNION, como segue:

(SELECT 'ID_autor', 'Nome_Autor', 'Sobrenome_Autor')
UNION
SELECT ID_autor, Nome_Autor, Sobrenome_Autor
FROM tbl_autores
INTO OUTFILE 'C:/SQL/autores_bkp.csv'
FIELDS TERMINATED BY ','
LINES TERMINATED BY '\n';

Tabela exportada com CSV com cabeçalhos de colunas

Note agora que a primeira linha do arquivo contém nomes de colunas, conforme informado na primeira declaração SELECT, antes da palavra-chave UNION. Não usei nesse caso as aspas duplas para englobar os dados (opção ENCLOSED BY).

É isso aí! Mostrei um processo simples para salvar os dados de tabelas do MySQL em um arquivo separado por vírgulas (CSV), com alguns exemplos de codificação, que pode ser aberto em editores de planilhas ou ainda importado em outros bancos de dados.

Prefere assistir a uma aula? Então assista ao vídeo da Bóson Treinamentos no YouTube sobre Arquivos CSV no MySQL:

Leia Também: Definir privilégios de acesso a bancos de dados MySQL

Perguntas Frequentes (FAQ)

1. Como eu exporto uma tabela inteira do MySQL  para CSV usando SQL?

Para isso podemos usar a instrução SQL a seguir:

SELECT * 
FROM nome_da_tabela 
INTO OUTFILE '/caminho/arquivo.csv' 
FIELDS TERMINATED BY ',' 
OPTIONALLY ENCLOSED BY '"' 
LINES TERMINATED BY '\n';

Isso exporta todas as linhas e colunas para o arquivo especificado.

2. Posso customizar o formato do CSV, como separador ou delimitação de texto?

Sim, você pode, usando por exemplo as seguintes opções:

• TERMINATED BY ‘,’ para definir o separador de campos (como vírgula ou ponto e vírgula),
• OPTIONALLY ENCLOSED BY ‘”‘ para envolver campos de texto com aspas,
• LINES TERMINATED BY ‘\n’ (ou ‘\r\n’) para controlar a quebra de linha

3. Onde o arquivo CSV é criado após a exportação?

Se não for empregado um caminho absoluto, o arquivo será salvo no diretório de dados do servidor MySQL.
Mas se você deseja salvá-lo outro local, use o caminho completo no INTO OUTFILE e tenha a permissão adequada.

4. Preciso de permissões especiais para usar INTO OUTFILE?

Sim, a conta do MySQL precisa da permissão FILE, e o diretório de saída deve permitir que o servidor grave.
Caso contrário, ocorrerá erro de acesso ou de permissão negada .

5. Como garantir que o arquivo CSV tenha cabeçalho com nomes de colunas?

O INTO OUTFILE só exporta dados, sem cabeçalhos.
Para incluir nomes de colunas, pode-se usar uma cláusula UNION ou aplicar um SELECT ‘col1’, ‘col2’, … UNION ALL SELECT * … antes do INTO OUTFILE.

6. INTO OUTFILE sobrescreve arquivos existentes?

Não. Se o arquivo já existir, o MySQL retorna um erro.
Você deve removê-lo manualmente antes de executar novamente o comando.

7. Há limitações para exportar via SELECT INTO OUTFILE em conjuntos Unix ou combinados UNION?

Sim, INTO OUTFILE deve vir no final da instrução SELECT.
Evite colocá-lo dentro de subconsultas ou antes de cláusulas UNION para evitar erros

8. Posso usar INTO DUMPFILE em vez de OUTFILE para CSV?

Não. A opção INTO DUMPFILE gera um único registro bruto sem delimitadores, sendo útil apenas para binários. Para arquivos CSV, devemos usar a opção INTO OUTFILE.

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 Exportar Tabela MySQL para CSV – Tutorial Prático apareceu primeiro em Bóson Treinamentos em Ciência e Tecnologia.

Neste artigo vamos discutir brevemente os tipos de dados disponíveis no SQLite, juntamente com os tipos de dados correspondentes no Python.

O que são Tipos de Dados?

Os tipos de dados representam os diferentes formatos e faixas de valores que podem ser armazenados em um banco de dados. Eles definem o tipo de informação que pode ser armazenado em uma coluna de uma tabela, e seu domínio (faixa de valores válidos).

Também determinam como os dados serão armazenados em disco, como serão manipulados e quais operações podem (ou não) ser realizadas sobre eles.

Os tipos em um banco de dados são importantes porque garantem a integridade dos dados e ajudam a otimizar o armazenamento e a recuperação de informações. Cada um tem suas próprias características e restrições, e é importante escolher o tipo mais apropriado para cada coluna com base no tipo de informação que será armazenada.

Classificação dos tipos de dados

Podemos classificar os tipos de dados em bancos de dados da seguinte forma:

• Tipos numéricos: Armazenam valores numéricos, como valores inteiros, números de ponto flutuante e números decimais.
• Tipos de caracteres: Armazenam strings de caracteres, como nomes, endereços e descrições. Podem incluir tipos de caracteres fixos (char) e variáveis (varchar).
• Tipos de data e hora: Armazenam datas, horas ou data e hora combinadas. Isso pode incluir tipos como DATE, TIME, DATETIME e TIMESTAMP.
• Tipos booleanos: Armazenam valores booleanos, como verdadeiro (true) ou falso (false).
• Tipos de sequência: Armazenam sequências de bytes, como imagens, arquivos de áudio ou arquivos binários.
• Tipos de coleção: Permitem armazenar coleções de valores, como listas, conjuntos e dicionários.
• Tipos especiais: Alguns bancos de dados oferecem tipos de dados especiais para armazenar dados geoespaciais, JSON, endereços de rede, XML, etc.

Vejamos agora como são classificados os tipos de dados no SQLite.

Classe de Armazenamento em SQLite

Uma classe de armazenamento é, basicamente, uma coleção de tipos de dados similares, como tipos inteiros, de ponto flutuante ou de strings. Em SQLite existem as seguintes cinco classes de armazenamento (tipos de dados) disponíveis:

E o tipo booleano (lógico)?

O SQLite não possui uma classe de armazenamento separada para dados booleanos. Em vez disso, valores booleanos são armazenados na forma de números inteiros 0 (equivalente a falso) e 1 (equivalente a verdadeiro).

O sistema também reconhece as palavras-chave “TRUE” e “FALSE”, a partir da versão 3.23.0, sendo, na verdade, apenas grafias alternativas para os literais inteiros 1 e 0, respectivamente.

Na tabela a seguir comparamos os tipos de dados em SQLite e seus tipos correspondentes em Python:

É importante lembrar que o SQLite é um banco de dados de tipagem dinâmica, ou ainda tipagem flexível, o que significa que ele é flexível em relação aos tipos de dados e pode converter automaticamente entre tipos, se for necessário, em vez de usar tipos rígidos por padrão (que também estão disponíveis). Mas o que significa isso? Significa que:

No SQLite, o tipo de dados de um valor está associado ao próprio valor, não ao seu contêiner (no caso, uma coluna de tabela).

Além disso, o sistema de tipos dinâmicos do SQLite é compatível com versões anteriores dos sistemas de tipos estáticos mais comuns de outros mecanismos de banco de dados, no sentido de que as instruções SQL que funcionam em bancos de dados de tipo estaticamente funcionam da mesma maneira no SQLite.

O tipo de dados ANY

Quando o tipo de dados de uma coluna é “ANY“, significa que qualquer tipo de dados – números inteiros, de ponto flutuante, strings ou blobs binários – pode ser inserido nessa tabela e seu valor e tipo de dados serão preservados exatamente como foram inseridos. Atualmente, o SQLite é o único mecanismo de banco de dados SQL que suporta esse recurso.

O comportamento de ANY é ligeiramente diferente em uma tabela STRICT (de tipagem rígida) e em uma tabela comum. Em uma tabela STRICT, uma coluna do tipo ANY sempre preserva os dados exatamente como eles são recebidos. Já em uma tabela comum não estrita, uma coluna do tipo ANY tentará converter strings que se parecem com números em um valor numérico e, se não ocorrerem erros, armazenará o valor numérico em vez da string original.

O que é Afinidade de Tipos

Afinidade de Tipos é um conceito no SQLite de como são associados os tipos de dados de colunas a uma das cinco categorias de tipos que ele suporta internamente, explicadas acima.

Apesar do SQLite ser um banco de dados de tipo dinâmico e permitir a inserção de qualquer tipo de dado em qualquer coluna, ele ainda possui esse sistema de afinidade de tipos que ajuda a interpretar e armazenar os dados de maneira eficiente e consistente.

Para isso algumas regras são definidas, descritas na sequência.

Regras de Afinidade de Tipos no SQLite

Quando uma tabela é criada no SQLite e especificamos os tipos de dados para as colunas, são aplicadas regras de afinidade de tipos para determinar a categoria interna mais adequada. Essas regras são baseadas nos nomes dos tipos de dados fornecidos.

Vejamos algumas regras gerais.

• INTEGER: Qualquer coluna com “INT” no tipo terá afinidade INTEGER.
• TEXT: Qualquer coluna com “CHAR”, “VARCHAR”, “CLOB”, ou “TEXT” no tipo terá afinidade TEXT.
• BLOB: Qualquer coluna com o tipo “BLOB” terá afinidade BLOB.
• REAL: Qualquer coluna com “REAL”, “FLOAT”, ou “DOUBLE” no tipo terá afinidade REAL.
• NUMERIC: Qualquer coluna que não se encaixe nas regras acima terá afinidade NUMERIC.

Ao inserir dados em uma coluna, o SQLite tentará converter o valor para o tipo de afinidade da coluna.

Para saber mais e se aprofundar em tipos de dados no SQLite, visite a página da documentação oficial: Tipos de Dados no SQLite.

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 Tipos de Dados no SQLite e tipos correspondentes em Python apareceu primeiro em Bóson Treinamentos em Ciência e Tecnologia.

Consultar os nomes de tabelas e colunas em um banco de dados MySQL é uma tarefa importante para entender a estrutura e o conteúdo dos dados armazenados, principalmente quando trabalhamos em um banco que não conhecemos muito bem.

Desta forma, podemos obter uma visão abrangente da organização dos dados e identificar os elementos essenciais para  a execução de consultas subsequentes e operações variadas de manipulação de dados.

Neste artigo abordo dois métodos que podem ser empregados para consultar nomes de tabelas e colunas em bancos MySQL, auxiliando a compreensão da estrutura de seus bancos de dados.

1. Mostrar os nomes das tabelas de um banco de dados específico

SELECT TABLE NAME FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = 'db_biblioteca';

Neste exemplo:

• SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES: Aqui especificamos que queremos selecionar a coluna TABLE_NAME, que contém os nomes das tabelas em um banco de dados.
  Essa coluna pertence à tabela interna INFORMATION_SCHEMA.TABLES, que é uma tabela especial no MySQL que contém informações sobre as tabelas em um banco de dados
• WHERE TABLE_SCHEMA = ‘db_biblioteca’;: Esta parte da declaração filtra os resultados para incluir apenas as tabelas que pertencem ao banco de dados especificado, de nome db_biblioteca no exemplo.
  TABLE_SCHEMA é uma coluna na tabela INFORMATION_SCHEMA.TABLES que contém os nomes dos bancos de dados aos quais as tabelas pertencem.

Resultado:

2. Mostrar os nomes das colunas de uma tabela específica no banco

SELECT COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA='db_biblioteca' AND TABLE_NAME='tbl_autores';

Neste exemplo temos que:

SELECT COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS: Vamos consultar os nomes das colunas da tabela INFORMATION_SCHEMA.COLUMNS, que é uma tabela especial no MySQL que contém informações sobre as colunas em todas as tabelas de todos os bancos de dados. 

WHERE TABLE_SCHEMA=’db_biblioteca AND TABLE_NAME=’tbl_autores”: Aqui filtramos os resultados para incluir apenas as tabelas que pertencem ao banco de dados db_biblioteca,combinado com nome da tabela do banco de dados desejada (no caso, tbl_autores) por meio de um operador lógico AND. 

Resultado:

É isso aí! Com essas técnicas podemos verificar rapidamente a estrutura de um banco de dados, descobrindo os nomes de suas tabelas e respectivas colunas no MySQL.

Referências

• INFORMATION_SCHEMA Tables. https://dev.mysql.com/doc/refman/8.0/en/information-schema.html

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 consultar nomes de tabelas e de colunas no MySQL apareceu primeiro em Bóson Treinamentos em Ciência e Tecnologia.

Neste tutorial veremos como criar um banco de dados usando o SGBD SQLite e como acessá-lo para realizar tarefas variadas a partir de um script em Python. Para tal, faremos uso da biblioteca built-in sqlite3, explorando sua funcionalidade básica na criação e acesso a dados armazenados em um banco de dados.

Primeiramente, vamos conceituar o que é o SQLite.

O que é o SQLite

O SQLite é uma biblioteca de software que fornece um sistema de gerenciamento de bancos de dados relacional (SGBDR). Trata-se de uma biblioteca muito leve (daí o termo “lite“) em termos de configuração, administração do BD e recursos necessários.

Presente em todos os smartphones e na maioria dos computadores e outros equipamentos, é software livre e de código aberto.

Site oficial: https://www.sqlite.org/

Características principais do SQLite

• Autocontido: O SQLite é independente, o que significa que requer suporte mínimo do sistema operacional ou biblioteca externa. Isso o torna utilizável em qualquer ambiente, especialmente em dispositivos incorporados como iPhones, telefones Android, consoles de jogos, reprodutores de mídia portáteis, etc.
  É desenvolvido usando ANSI-C. O código-fonte está disponível nos arquivos sqlite3.c e seu arquivo de cabeçalho sqlite3.h. Se precisarmos desenvolver uma aplicação que utilize SQLite, basta colocar esses arquivos no projeto e compilá-lo com seu código.
• Sem servidor (serverless): Normalmente, um SGBDR como MySQL, PostgreSQL, etc., requer um processo de servidor separado para operar. As aplicações que desejam acessar o servidor de banco de dados utilizam o protocolo TCP/IP para enviar e receber solicitações. Isso é chamado de arquitetura cliente/servidor.
  Já o SQLite NÃO requer um servidor para funcionar.
  O banco de dados SQLite é integrado à aplicação que acessa o banco de dados. Os aplicativos interagem com o banco de dados SQLite lendo e escrevendo diretamente dos arquivos do banco de dados armazenados no disco.
• Configuração zero: Devido à arquitetura serverless, não precisamos “instalar” o SQLite antes de usá-lo. Não há nenhum processo do servidor que precise ser configurado, iniciado e interrompido.
  Além disso, o SQLite não usa nenhum arquivo de configuração específico.
• Transacional: Todas as transações no SQLite são totalmente compatíveis com as propriedades ACID. Isso significa que todas as consultas e alterações são atômicas, consistentes, isoladas e duráveis.
  Em outras palavras, todas as alterações em uma transação ocorrem completamente ou não ocorrem, mesmo quando ocorre uma situação inesperada, como falha de aplicativo, falha de energia ou falha do sistema operacional.

O SQLite também tem suporte a subconsultas, transações, junções, pesquisa em texto (full text search), restrições de chave estrangeira, entre outras funcionalidades.

Outros Recursos do SQLite

• O SQLite usa tipos dinâmicos para tabelas. Isso significa podemos armazenar qualquer valor em qualquer coluna, independentemente do tipo de dados.
• Permite que uma única conexão de banco de dados acesse vários arquivos de banco de dados simultaneamente. Isso fornece muitos recursos interessantes, como unir tabelas em bancos de dados diferentes ou copiar dados entre bancos de dados em um único comando.
• O SQLite é capaz de criar bancos de dados na memória de acesso muito rápido.

Observações sobre o SQLite

É importante notar que, por não ter um servidor para seu gerenciamento, o SQLite não provê um acesso direto pela rede. As soluções existentes para acesso remoto são no geral “caras” e ineficientes.

Além disso, o SQLite não possui suporte à autenticação, com usuários e permissões definidas. Estamos falando aqui sobre usuários do banco de dados, que têm permissão para criar tabela, inserir registros etc.

Porém, apesar do SQLite não ter suporte à autenticação, é claro que podemos e devemos implementar nosso próprio controle de acesso para nossa aplicação.

Finalmente, O SQLite é case-insensitive, ou seja, não diferencia letras maiúsculas de minúsculas.

Ferramentas GUI para gerenciamento do SQLite

Diversas ferramentas gráficas existem para auxiliar no gerenciamento de bancos de dados criados com SQLite, disponíveis em várias plataformas e sob vários tipos de licenciamento. Algumas das mais populares incluem o SQLiteStudio, DBeaver e o DB Browser for SQLite, citadas a seguir:

• SQLiteStudio
  O SQLiteStudio é uma ferramenta GUI gratuita para gerenciar bancos de dados SQLite.
  É gratuito, portátil, intuitivo e multiplataforma.
  A ferramenta também fornece alguns dos recursos mais importantes para trabalhar com bancos de dados SQLite, como importação e exportação de dados em vários formatos, incluindo CSV, XML e JSON.
  Download: https://github.com/pawelsalawa/sqlitestudio/releases

Além do SQLite Studio, também temos disponíveis as seguintes ferramentas GUI gratuitas para SQLite: 

• DBeaver: Ferramenta gratuita de banco de dados multiplataforma. Suporta todos os principais sistemas de banco de dados relacionais populares como MySQL, PostgreSQL, Oracle Database, IBM DB2, Microsoft SQL Server, Sybase, Firebird, além é claro do SQLite.
  Download: https://dbeaver.io/download/
• DB Browser for SQLite: Ferramenta de código aberto para gerenciar arquivos de banco de dados compatíveis com SQLite.
  Download: https://sqlitebrowser.org/

Módulo sqlite3

O módulo SQLite3 é uma biblioteca embutida em Python, compatível com a especificação DB-API 2.0 (descrita pelo PEP 249), que permite a interação com bancos de dados SQLite. Esse módulo fornece uma API simples mas bastante eficaz para realizar operações variadas de consulta, atualização e gerenciamento em bancos de dados SQLite diretamente a partir de scripts Python.

O SQLite3 é amplamente utilizado devido à sua natureza leve, rápida e autônoma. Ele não requer um servidor separado para funcionar, pois todo o banco de dados é armazenado em um único arquivo, o que facilita a distribuição e o compartilhamento de aplicativos.

Além disso, essa biblioteca suporta a maioria das funcionalidades comuns de bancos de dados relacionais, incluindo tipos de dados, consultas SQL complexas, transações ACID (Atomicidade, Consistência, Isolamento e Durabilidade) e outras. Fornece classes e métodos para executar consultas SQL, inserir dados, atualizar registros, excluir dados, gerenciar transações e manipular exceções de maneira eficiente.

Apesar de não ser necessário instalá-lo (por se tratar de um módulo built-in), o módulo sqlite3 requer a versão SQLite 3.7.15 ou mais recente para funcionar.

Como criar um banco de dados SQLite com sqlite3

Para criar um novo banco de dados, ou abrir um banco de dados já existente, o primeiro passo é importar a biblioteca sqlite3 com a declaração import no script Python:

import sqlite3 as s

Logo após, criamos / conectamos um banco de dados usando o método connect() do sqlite3 para criar um objeto de conexão:

conexao = s.connect(banco_teste.db')

Nesta instrução, passamos o nome do banco entre aspas como argumento para o método connect, atribuindo seu retorno a uma variável objeto que batizamos aqui de conexao. Caso o banco de dados não exista, será criado no mesmo diretório onde reside o script python; se já existir, o banco será aberto para acesso. Usaremos o nome banco_teste como nome do banco de dados, com a extensão .db.

Na sequência, criaremos um cursor que nos permitirá executar as declarações SQL no banco de dados em si, como comandos para criar tabelas, inserir registros, atualizar linha e excluir elementos, entre outros. Para isso usamos o método cursor() do objeto conexao criado:

cursor = conexao.cursor()

Agora podemos escrever uma declaração SQL a ser executada no banco. Por exemplo, vamos criar uma tabela usando a declaração CREATE TABLE, e então executar essa declaraçãop no banco de dados usando o método execute() do cursor criado:

sql = "CREATE TABLE teste(coluna1, coluna2, coluna3);"
cursor.execute(sql)

Como estamos executando um comando que realiza alterações no banco de dados, precisamos efetuar um commit logo após para efetivar a transação, caso contrário as alterações requisitadas não serão tornadas permanentes no arquivo do banco. Para isso, executamos o método commit() da conexão:

conexao.commit()

Finalmente, verificamos se a tabela foi criada efetuando uma consulta na tabela mestra do sqlite, que se chama sqlite-master. Usamos na sequência o método fetchall() para acessar todos os registros retornados pela consulta a um objeto batizado de res ( de “resultado”):

res = cursor.execute("SELECT name FROM sqlite_master")
print(res.fetchall())

Código completo:

import sqlite3 as s

# Criar objeto de conexão e conectar ao banco
conexao = s.connect('banco_teste.db')

# Criar cursor
cursor = conexao.cursor()

# Determinar declarações SQL a serem executadas e executá-las no banco
sql = "CREATE TABLE teste(coluna1, coluna2, coluna3);"
cursor.execute(sql)

# Efetivar a transação (comitar)
conexao.commit()

# Verificar se tabelas foram criadas
res = cursor.execute("SELECT name FROM sqlite_master")
print(res.fetchall())

Resultado:

[('teste',)]

Note que foi retornada uma lista de tuplas, com um único elemento, que representa o nome da tabela de teste criada.

É isso aí! Criamos um banco de dados com SQLite e Python, além de uma tabela simples, e testamos a existência da tabela por meio de instruções no script. Na próxima lição veremos como inserir dados nesta tabela (criar registros) e testar essa inserção.

Case prefira, assista a um vídeo da Bóson Treinamentos sobre Python com SQLite:

O post Criar banco de dados SQLite em Python com sqlite3 apareceu primeiro em Bóson Treinamentos em Ciência e Tecnologia.

Neste tutorial mostro como importar um arquivo no formato CSV para uma tabela de um banco de dados SQL Server, de modo a realizar a inserção de múltiplos registros de uma só vez, por meio de uma operação INSERT INTO.

Para tal vamos usar dois arquivos: o arquivo CSV propriamente dito, contendo os dados a serem inseridos na tabela, e um arquivo especificador de formatos para ajustar os dados do arquivo CSV com as colunas específicas da tabela, além é claro do código SQL que executará a tarefa de inserção dos registros em bulk (vários de uma vez).

O que é um arquivo CSV?

Um arquivo CSV (Comma-Separated Values / Valores Separados por Vírgulas) é um tipo de arquivo de texto simples que armazena dados tabulares de forma estruturada, empregado com frequência para importar e exportar dados entre diferentes programas, sistemas e plataformas.

Neste tipo de arquivo, cada linha representa uma entrada de dados (um registro) e cada campo (coluna) é separado por um caractere delimitador, geralmente uma vírgula (“,”), ponto e vírgula (“;”) ou tabulação (“tab”). O mais comum é usar a vírgula, daí o nome do formato.

Cada linha no arquivo representa um registro e os campos podem conter texto, números, datas ou outros tipos de dados quaisquer. Usamos arquivos csv em aplicativos de planilhas, bancos de dados, programas para análise de dados e diversas outras aplicações, pois são bastante simples e fáceis de manipular.

Vamos usar neste tutorial um arquivo CSV de nome Livros.csv, que conterá dados a serem inseridos em uma tabela de nome Livro, e com ele vamos cadastrar vários registros de forma rápida e simples.

Arquivo CSV de exemplo: Livros.csv

A seguir temos o conteúdo do arquivo a ser usado no exemplo de inserção de linhas na tabela. Neste arquivo, a primeira linha é uma linha de cabeçalho, contendo os nomes das colunas da tabela que receberá os dados (tabela de nome Livro), separados por vírgulas. Você deve alterar o conteúdo desse arquivo de acordo com a tabela do banco que está usando, seguindo as instruções na sequência.

As linhas subsequentes contém os dados em si, sendo que cada linha do arquivo corresponde a uma linha a ser inserida na tabela (um registro), também separadas por vírgulas, seguindo a mesma ordem das colunas descritas no cabeçalho:

NomeLivro,ISBN13,DataPub,PreçoLivro,NumeroPaginas,IdEditora,IdAssunto
2001 - Um Odisséia no Espaço,9788576571551,20200930,55.86,336,3,1
Fahrenheit 451,9788525052247,20120601,43.56,216,3,1
Admirável mundo novo,9788525056009,20140101,50.32,312,3,1
1984,9788535914849,20090721,29.67,416,14,1
A volta ao mundo em 80 dias,9788537816134,18730101,59.41,256,11,5
O Nome da Rosa,9788501115829,20191216,51.99,592,18,5
Memórias Póstumas de Brás Cubas,9788525433131,18810101,34.90,240,14,6
O Evangelho Segundo Jesus Cristo,9788535905595,19910101,49.90,512,14,6
Cidades Invisíveis,9788535907445,19720101,42.80,176,14,6
Windows Server 2016: Installing & Configuring,9781535074094,20160712,432.00,436,4,11
Ensaio Sobre a Cegueira,9788571645118,19950101,39.90,312,14,6
Ulisses,9780141184432,19220202,78.90,450,16,6
Practical Electronics for Inventors,9781259587542,20160711,212.58,1056,9,3
Eu Robô,9788576571667,19501202,35.00,300,3,1
Dom Casmurro,9788525404186,19000101,19.90,256,14,6

Insira esse conteúdo em um arquivo de texto simples vazio, como um arquivo do bloco de notas no Windows, e salve com o nome de Livros.csv. Caso queira, acrescente mais livros à listagem. Não é necessário usar aspas para delimitar os dados do tipo VARCHAR ou DATE.

Obs.: Tome cuidado ao salvar o arquivo para não salvá-lo com a extensão .txt!!! Para evitar esse problema, selecione “Todos os arquivos” em “Tipo” na caixa de diálogo Salvar, e certifique-se de usar a codificação UTF-8, como segue:

A seguir criaremos o arquivo de formato XML a ser usado com esse csv.

Arquivo de Formato XML

Um arquivo de formato é um arquivo do tipo XML (eXtensible Markup Language) que descreve a estrutura dos dados contidos no arquivo CSV, especificando como os campos são delimitados, o comprimento máximo de cada campo e como esses campos são mapeados para as colunas da tabela do banco de dados durante o processo de importação de dados em massa..

O arquivo que usaremos possui o nome formato.xml. Crie-o com um editor de textos, usando o conteúdo a seguir, e salve-o no mesmo diretório do arquivo Livros.CSV:

<?xml version="1.0" encoding="UTF-8"?>
<BCPFORMAT xmlns="http://schemas.microsoft.com/sqlserver/2004/bulkload/format" 
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <RECORD>
    <FIELD ID="1" xsi:type="CharTerm" TERMINATOR="," MAX_LENGTH="100"/>
    <FIELD ID="2" xsi:type="CharTerm" TERMINATOR="," MAX_LENGTH="13"/>
    <FIELD ID="3" xsi:type="CharTerm" TERMINATOR="," MAX_LENGTH="8"/>
    <FIELD ID="4" xsi:type="CharTerm" TERMINATOR="," MAX_LENGTH="19"/>
    <FIELD ID="5" xsi:type="CharTerm" TERMINATOR="," MAX_LENGTH="10"/>
    <FIELD ID="6" xsi:type="CharTerm" TERMINATOR="," MAX_LENGTH="5"/>
    <FIELD ID="7" xsi:type="CharTerm" TERMINATOR="\r\n" MAX_LENGTH="5"/>
  </RECORD>
  <ROW>
    <COLUMN SOURCE="1" NAME="NomeLivro" xsi:type="SQLVARYCHAR"/>
    <COLUMN SOURCE="2" NAME="ISBN13" xsi:type="SQLVARYCHAR"/>
    <COLUMN SOURCE="3" NAME="DataPub" xsi:type="SQLDATE"/>
    <COLUMN SOURCE="4" NAME="PrecoLivro" xsi:type="SQLMONEY"/>
    <COLUMN SOURCE="5" NAME="NumeroPaginas" xsi:type="SQLSMALLINT"/>
    <COLUMN SOURCE="6" NAME="IdEditora" xsi:type="SQLSMALLINT"/>
    <COLUMN SOURCE="7" NAME="IdAssunto" xsi:type="SQLTINYINT"/>
  </ROW>
</BCPFORMAT>

O funcionamento deste arquivo é o seguinte:

• <BCPFORMAT>: Elemento raiz do arquivo XML que define o formato do arquivo de dados.
• <RECORD>: Define a estrutura de cada registro (linha) no arquivo CSV.
• <FIELD>: Define os campos (colunas) do registro. Cada tag <FIELD> especifica o identificador do campo (ID), o tipo de terminador que separa os campos (TERMINATOR), e o comprimento máximo (MAX_LENGTH) do campo.
• <ROW>: Define a correspondência entre os campos do arquivo CSV e as colunas da tabela do banco de dados.
• <COLUMN>: Especifica como cada campo do arquivo CSV (SOURCE) é mapeado para uma coluna na tabela do banco de dados (NAME). Além disso, define o tipo de dados da coluna (xsi:type), que pode ser:
  • SQLVARYCHAR para strings
  • SQLDATE para datas
  • SQLMONEY para valores monetários
  • SQLSMALLINT para números inteiros pequenos
  • SQLTINYINT para números inteiros muito pequenos.

Código SQL

E a seguir temos o código SQL que deverá ser executado no SQL Server, por exemplo usando o SSMS (SQL Server Management Studio):

INSERT INTO Livro (NomeLivro, ISBN13, DataPub, PrecoLivro, NumeroPaginas, IdEditora, IdAssunto)
SELECT 
    NomeLivro, ISBN13, DataPub, PrecoLivro, NumeroPaginas, IdEditora, IdAssunto
FROM OPENROWSET(
    BULK 'C:\SQL\Livros.CSV',
    FORMATFILE = 'C:\SQL\Formato.xml',
CODEPAGE = '65001',  -- UTF-8
FIRSTROW = 2
) AS LivrosCSV;

SELECT * FROM Livro;

Conclusão

Inserir alguns poucos registros em uma tabela de banco de dados é uma tarefa simples e rápida. Porém, cadastrar muitos registros – centenas, milhares ou até mesmo milhões – pode se tornar extremamente trabalhoso e demorado, e neste caso podemos recorrer à importação em massa dos dados. Neste tutorial vimos uma forma simples de fazer isso no SQL Server: usando arquivos de texto do tipo CSV.

Nos próximos tutoriais veremos outras formas de importação (e também exportação) de dados em bancos de dados.

Prefere assistir a uma aula? Então assista ao vídeo da Bóson Treinamentos no YouTube sobre Arquivos CSV no MySQL:

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 Importar arquivo CSV no SQL Server para inserir registros em uma tabela 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.