Editor VI - Guia do Usuário

Achei esse texto no site do Aurélio Marinho Jargas (http://aurelio.net) e pensei que seria útil replicá-lo aqui:

Entrar e Sair vi arquivo.txt :q Entrar, Inserir Texto, Salvar e Sair vi arquivo.txt i Minha primeira frase no VI. :wq Entrar, Alterar Texto e Sair sem Salvar vi arquivo.txt dd :q! Entrar, Alterar Texto, Salvar em Outro Arquivo e Sair vi arquivo.txt yy p :w arquivo-novo.txt :q Configurar o VI vi ~/.vimrc i set vb ru nu set ic is hls scs :wq Repetir a Primeira Linha 2 Vezes e Apagar a Última vi arquivo.txt gg yy p p G dd Repetir Comandos vi arquivo.txt A FIM j . j . Abrir Dois Arquivos Simultaneamente vi arquivo.txt :split ~/.vimrc Ctrl+W Ctrl+W :q :q Obter Ajuda vi arquivo.txt :help

Comandos de Arquivo :q Sai do VI :w Salva alteraçoes feitas :wq Salva aterações e sai do VI :q! Sai sem salvar :w abc Grava arquivo com o nome 'abc' :r abc Insere o conteúdo do arquivo 'abc' :e abc Edita o arquivo 'abc' Modo de Inserção i Entra no modo de Inserção a Entra no modo de Inserção, após o cursor o Entra no modo de Inserção, em uma nova linha Sai do modo de Inserção Copiar, Cortar e Colar yy Copia a linha inteira 5yy Copia as 5 próximas linhas dd Apaga a linha 5dd Apaga 5 linhas x Apaga uma letra 5x Apaga 5 letras p Cola o trecho copiado ou apagado V Seleção visual de linhas Pulos gg Pula para a primeira linha G Pula para a última linha 44G Pula para a linha número 44 w Pula para a próxima palavra b Pula para a palavra anterior { Pula para o parágrafo anterior } Pula para o próximo parágrafo ( Pula para a frase anterior ) Pula para a próxima frase f. Pula até o próximo ponto (.), na mesma linha `` Desfaz o pulo, volta Apagando com esperteza dgg Apaga até o início do arquivo d0 Apaga até o início da linha atual dw Apaga a palavra d4b Apaga as quatro palavras anteriores df. Apaga até o próximo ponto d) Apaga até o fim da frase Outros J Junta a próxima linha com a atual u Desfaz o último comando Ctrl+R Refaz o último comando desfeito . Repete o comando anterior hjkl Movimenta o cursor / Pesquisa um texto n Vai para o próximo resultado da pesquisa :%s/a/b/g Troca 'a' por 'b' em todo o texto :!cmd Executa o comando externo 'cmd' :r!cmd Insere o resultado do comando externo 'cmd'

Mais informações em http://aurelio.net/doc/vim

Recuperar senha de root no Slackware

Como alterar a senha de root no Slackware, caso você a tenha perdido:

1. Iniciar o sistema "bootando" pelo CD/DVD do Slackware
2. Criar um diretório qualquer (/temp, por exemplo)
3. Montar a raiz do sistema no diretório criado (mount /dev/hdn /temp, onde hdn é a partição Linux)
4. Executar o comando chroot /temp, considerando /temp é o diretório que você criou
5. Agora é só alterar a senha com o comando passwd

Normalização de banco de dados

Segundo Heuser (2001), uma forma normal (FN) é uma regra que deve ser obedecida por uma tabela para que ela seja considerada “bem projetada”. Existem inúmeras formas normais, ou seja, diversas regras, cada vez mais rígidas, para verificar tabelas em banco de dados relacionais. No entanto, pelo menos 3 FNs são consideradas essenciais para a construção de um bom projeto de banco de dados.

1FN (Primeira Forma Normal)

Primeira forma normal (1FN) = diz
que uma tabela está na primeira forma normal quando ela não contém tabelas aninhadas

Considere a planilha a seguir:

A planilha acima representada em um modelo relacional não normalizado (ÑN) ficaria assim:

Segundo a definição da 1FN, para normalizar a tabela acima, é necessário decompô-la em duas:

Proj(CodProj, Tipo, Descr);
Emp(CodProj, CodEmp, Nome, Cat, Sal, DataIni, TempAl);

Ou seja:
* As colunas destacadas em cinza compõem as chaves primárias.
** Vale ressaltar que se houvesse a restrição de que um funcionário só pudesse participar de exatamente 1 projeto, a chave-primária da tabela ProjEmp poderia ser composta unicamente de CodEmp.

2FN (Segunda Forma Normal)

Observando a tabela ProjEmp acima, é possível identificar que os dados do funcionário Mário se repetem em duas tuplas. É esse tipo de redundância que a 2FN visa eliminar.

Segunda Forma Normal (2FN) = uma tabela encontra-se na segunda forma normal, quando, além de estar na 1FN, não contem dependências parciais.

Dependência parcial = uma dependência parcial ocorre quando uma coluna depende apenas de parte de uma chave primária composta.

A partir das definições acima, podemos concluir que a tabela Proj já se encontra na 2FN, pois todos seus atributos dependem exclusivamente de sua chave primária, já a tabela ProjEmp não. Verifique, em ProjEmp, que atributos como Nome, Cat, Sal dependem somente de CodEmp, enquanto que DataIni, TempAl dependem da chave primária composta por inteiro (tal fato se justifica porque pode ser necessário identificar a data em que determinado usuário ingressou em um projeto). Sendo assim, para que a tabela ProjEmp fique de acordo com a 2FN, é necessário decompô-la em duas outras (ProjEmp e Emp). O projeto então fica como segue:

3FN (Terceira Forma Normal)

Observando o modelo gerado aplicando-se as regras da 2FN e supondo que o salário de um empregado é determinado por sua categoria funcional (Cat), podemos notar que ainda restam dados redundantes na tabela Emp; todos os empregados da categoria A1 e A2 possuem salário 4 e B1 possuem salário 9. A 3FN visa eliminar esse tipo de redundância.

Terceira Forma Normal (3FN) = uma tabela encontra-se na terceira forma normal, quando, além de estar na 2FN, não contém dependências transitivas

Dependência transitiva = uma dependência funcional transitiva ocorre quando uma coluna, além de depender da chave primária da tabela, depende de outra coluna ou conjunto de colunas da tabela

Sendo assim, a tabela Emp obtida pela aplicação da 2FN, que contém os dados redundantes, pode ser decomposta em outras duas (Emp e Cat). O modelo fica como segue:

Resumo

1FN

1. Cria-se uma tabela na 1FN referente à tabela ÑN e que contém apenas colunas com valores atômicos, isto é, sem as tabelas aninhadas;
2. Para cada tabela aninhada, cria-se uma tabela na 1FN compostas pelas seguintes colunas:
1. A chave primária de uma das tabelas na qual a tabela em questão está aninhada
2. As colunas da própria tabela
3. São definidas as chaves primárias das tabelas na 1FN que correspondem a tabelas aninhadas

2FN

1. Copiar para a 2FN cada tabela que tenha chave primária simples ou que não tenha colunas além da chave. No caso do exemplo, é o que acontece com a tabela Proj.
2. Para cada tabela com chave primária composta e com pelo menos uma coluna não chave (no exemplo, a tabela ProjEmp):
1. Criar na 2FN uma tabela com as chaves primárias da tabela na 1FN
2. Para cada coluna não chave fazer a seguinte pergunta:
   ”a coluna depende de toda a chave ou de apenas parte dela”
3. Caso a coluna dependa de toda a chave
   i. Criar a coluna correspondente na tabela com a chave completa na 2FN

4. Caso a coluna não dependa apenas de parte da chave
   i. Criar, caso ainda não existir, uma tabela na 2FN que tenha como chave primária a parte da chave que é determinante da coluna em questão
   ii. Criar a coluna dependente dentro da tabela na 2FN

3FN

Copiar para o esquema da 3FN cada tabela que tenha menos de duas colunas não chave, pois neste caso não há como haver dependências transitivas

1. Para tabelas com duas ou mais colunas não chaves, fazer a seguinte pergunta:
   ”a coluna depende de alguma outra coluna não chave?”
1. Caso dependa apenas da chave
   i. Copiar a coluna para a tabela na 3FN

2. Caso a coluna depender de outra coluna
   i. Criar, caso ainda não exista, uma tabela no esquema na 3FN que tenha como chave primária a coluna na qual há a dependência indireta
   ii. Copiar a coluna dependente para a tabela criada
   iii. A coluna determinante deve permanecer também na tabela original

Conclusão

Quem já trabalhou com banco de dados, acaba percebendo que utilizava as FNs mesmo sem conhecê-las. Para desenvolvedores mais experientes, a eliminação de redundâncias em bancos de dados se configura uma prática essencial para o sucesso do projeto. O material utilizado para a criação deste texto menciona a 4FN, porém, para a maioria dos projetos, a 3FN é suficiente.

Bibliografia

HEUSER, Carlos Alberto. Projeto de Banco de Dados. Porto Alegre, RS: Editora Sagra Luzzatto, 2001.