Júlio Battisti Livros e Cursosa sua sala de aula na internet

Vamos ver algumas considerações que podem nos ajudar na escolha do tipo de dados mais adequado para cada coluna.

O fator determinante na escolha do tipo de dados de uma coluna são os próprios dados a serem armazenados na coluna. Por exemplo, se a coluna for armazenar a data de aniversário do cliente, na tabela Clientes é obvio que o campo deve ser do tipo datetime, a menos que haja algum outro motivo. Campos que irão conter valores devem ser do tipo respectivo, isto é, se o campo irá conter somente números inteiros, podemos utilizar os tipos integer, smallint ou tinyint, dependendo da faixa de valores esperados para o respectivo campo. Já se o campo contiver valores com decimais devemos optar pelos tipos real, float ou money, dependendo da faixa de valores.

Embora pareçam considerações óbvias, muitas vezes são esquecidas na hora de projetar um Banco de Dados. Vamos considerar um campo que deva armazenar valores de CPF, tendo o seguinte formato:

111.111.111-11

Se quisermos armazenar no Banco de Dados os pontos e o traço, não poderemos definir o campo CPF como sendo do tipo integer, ao invés disso devemos defini-lo como sendo do tipo texto. Porém se quisermos armazenar apenas os números podemos defini-lo como sendo do tipo integer. Outra questão que surge é se podemos armazenar, no nosso exemplo, o campo CPF como do tipo texto e mesmo assim fazer cálculos com este campo, como por exemplo, calcular o DV – Dígito Verificador (dois últimos dígitos) do CPF. Tecnicamente isto é possível, pois podemos utilizar funções que retornam cada um dos caracteres do CPF e depois convertê-los para números de tal forma que possamos fazer os cálculos necessários, usando programação (que seja programação T-SQL ou usando as linguagens do Framework .NET, tais como VB.NET e C#, uma vez que o SQL Server 2005 é completamente integrado com o Framework .NET). Porém este procedimento pode ocasionar processamento adicional o que prejudica o desempenho das aplicações que estão acessando o Banco de Dados.

Estas pequenas questões reforçam a idéia de que devemos fazer uma análise criteriosa na fase de projeto do Banco de Dados.

Outro fator que devemos levar em consideração é se vamos utilizar campos de tamanho fixo ou campos de tamanho variável.

De uma maneira geral devemos utilizar campos de tamanho fixo se os dados de uma coluna tiverem um tamanho que não varia muito. Quando os dados de uma coluna sofrem grandes variações de tamanho, a utilização de um tipo de dados de tamanho fixo pode causar um desperdício de espaço em disco. Vamos considerar o seguinte exemplo:

• Uma coluna do tipo texto.

• Definida com um tamanho fixo de 250 caracteres.

• A tabela possui 200.000 registros.

• Em média 80% dos registros armazenam apenas 50 caracteres neste campo, o qual foi definido como tamanho de 250 por causa de alguns poucos registros em que o campo atinge este tamanho.

Vamos calcular o desperdício:

• 80% de 200.000 registros = 160.000 registros

• 160.000 registros vezes um desperdício de 200 bytes por registro

• Desperdício total = 30,5 MB

Mantidas as mesmas proporções, se esta tabela tiver 1.000.000 de registros, teríamos um desperdício de 152,5 MB. Multiplique isso por diversas tabelas e diversos bancos de dados, poderemos chegar a desperdícios gigantescos em um único servidor SQL Server 2005.

Nestas situações pode ser justificável a utilização, por exemplo, de um campo de texto de tamanho variável, com tamanho máximo definido em 250 – char(250). Nesta situação o espaço ocupado não seria 250 bytes para todos os campos, mas somente o tamanho real dos dados digitados no campo, conforme descrito na Tabela 4.1.

Mas, então, por que não utilizamos sempre campos de tamanho variável? A resposta é simples: porque campos de tamanho variável acarretam processamento adicional para o Banco de Dados, sendo que estes somente devem ser utilizados em situações onde realmente sejam necessários. Estas situações tipicamente ocorrem quando não sabemos com precisão a variação do tamanho dos dados em um determinado campo, e a utilização de um tamanho fixo acarretaria muito desperdício de espaço em disco.

Agora vamos aprender a criar tabelas no SQL Server 2005.

Fundamentos em: Criação de Tabelas com o Enterprise Manager

Pré-Requisitos

• Noções dos conceitos básicos sobre Bancos de Dados Relacionais.
• Conhecer os tipos básicos de dados do SQL Server 2005.
• Saber utilizar o Enterprise Manager.

Metodologia

• Utilização do Enterprise Manager para a criação de tabelas.

Técnica

Criação de tabelas nos Bancos de Dados criados no Capítulo 3.

Agora vamos aprender a criar tabelas utilizando o Enterprise Manager. Mais uma vez a melhor maneira de aprendermos é através de um exemplo prático. Vamos criar a tabela Clientes com os campos indicados na Tabela 4.2.

Tabela 4.2 A tabela Clientes.

<Tab s/fio>DataCadastro datetime

Vamos criar esta tabela no Banco de Dados Exemplo1. Lembrando que este banco de dados foi criado na instância SERVIDOR\SRVINST01. Iremos inicialmente criar a tabela Clientes definindo apenas características básicas: nome, tamanho máximo, tipo e se o campo pode conter valores nulos ou não. Na seqüência, apresentaremos mais um exemplo, onde estaremos trabalhando com mais propriedades de cada campo.

Exemplo:

Criando a tabela Clientes com o Enterprise Manager.

Passo 1. Se você não estiver com o Enterprise Manager aberto, abra-o (Iniciar -> Programas -> Microsoft SQL Server -> Enterprise Manager).

Passo 2. Clique no sinal de mais ao lado da instância SERVIDOR\SRVINST01 para expandi-la.

Passo 3. Nas opções que surgem abaixo desta instância, clique no sinal de mais ao lado da opção Databases para expandi-la. Abaixo de Databases é exibida uma lista com os bancos de dados disponíveis na instância SERVIDOR\SRVINST01.

Passo 4. Dê um clique na opção Databases. No painel da direita, serão exibido os Bancos de Dados disponíveis. Localize o Banco de Dados Exemplo1, criado no capítulo anterior.

Passo 5. Dê um clique com o botão direito do mouse no banco de dados Exemplo1. No menu de opções que surge, dê um clique na opção New Table. Surge a janela para a criação de uma nova tabela, conforme indicado na Figura 4.1.

<Figura>Figura 4.1 A janela para criação de uma nova tabela.

Abaixo da barra de botões, temos um espaço para a criação dos campos. Cada campo é criado em uma nova linha. Neste espaço temos quatro colunas, conforme descrito a seguir:

• Column Name: Nesta coluna definimos o nome do campo.

• Data Type: Aqui podemos definir o tipo de dados para o campo que está sendo criado. Podemos selecionar em uma lista de tipos predefinidos. Caso o usuário tenha definido algum tipo personalizado, o mesmo também irá aparecer nesta lista. Veremos como criar tipos personalizados ainda neste capítulo.

• Length: Nesta coluna vamos especificar o tamanho máximo para o campo.

• Allow Nulls: Serve para definir se o campo que está sendo criado irá ou não, aceitar valores nulos. Valor Null é diferente de valor em branco. Uma valor Null é de tipo desconhecido e ao ser utilizado em funções retorna um erro. Já valores em branco não retornam erros ao serem utilizados como parâmetros de função. Por exemplo, ao usuário entrar em um campo do tipo texto e pressionar Enter, ele estará criando uma string de comprimento zero, a qual é um valor em branco, diferente de um valor Null.

Na parte de cima desta janela definimos os campos, um por linha. À medida que estamos definindo um determinado campo, podemos definir propriedades adicionais para o mesmo. Estas propriedades aparecem na parte inferior da janela. O conjunto de propriedades é diferente para diversos tipos de campo, isto é, as propriedades para um campo do tipo integer são diferentes das propriedades para um campo do tipo datetime. Um detalhe importante a ser observado é que as propriedades da parte de baixo da janela são referentes ao campo da linha onde está o cursor, na parte de cima da janela. É importante estarmos cientes deste detalhe, para não alterarmos as propriedades de um campo quando na verdade estamos querendo alterar as propriedades de um outro campo. No próximo exercício aprenderemos sobre estas diversas propriedades.

Passo 6. Vamos começar criando o campo CódigoCliente. Para isso preencha a primeira linha com as seguintes informações:

Column Name -> CódigoCliente

Data Type -> int

Size -> 4 (este é preenchido automaticamente no caso de campos com tamanho já definidos, como no caso de int, real, etc.)

Allow Null -> Não (caixinha desmarcada).

Sua janela deve estar conforme indicado na Figura 4.2.

<Figura>Figura 4.2 Definindo o campo CódigoCliente.

Passo 7. Defina os demais campos, conforme as seguintes orientações:

Column Name -> NomeEmpresa

Data Type -> char

Size -> 50 (basta digitar o valor nesta coluna).

Allow Null -> Não (caixinha desmarcada).

Column Name -> Rua

Data Type -> char

Size -> 50 (basta digitar o valor nesta coluna).

Allow Null -> Não (caixinha desmarcada).

Column Name -> Bairro

Data Type -> char

Size -> 20 (basta digitar o valor nesta coluna).

Allow Null -> Não (caixinha desmarcada).

Column Name -> Cidade

Data Type -> char

Size -> 25 (basta digitar o valor nesta coluna).

Allow Null -> Não (caixinha desmarcada).

Column Name -> CEP

Data Type -> int (vamos digitar o CEP sem o tracinho, por exemplo: 97070888).

Size -> 4 (predefinido).

Allow Null -> Não (caixinha desmarcada).

Column Name -> DataCadastro

Data Type -> datetime

Size -> 8 (predefinido)

Allow Null -> Não (caixinha desmarcada).

Sua janela deve estar conforme indicado na Figura 4.3.

<Figura>Figura 4.3 Demais campos da tabela Clientes.

Agora é hora de salvarmos a tabela no Banco de Dados Exemplo1.

Passo 8. Dê um clique no botão Save (primeiro botão da barra de ferramentas, com o desenho de um disquete).

Passo 9. Surge uma janela pedindo o nome da tabela. Digite Clientes e dê um clique no botão OK.

Passo 10.   Você estará de volta a janela para definição dos campos. Feche-a.

Passo 11.   Você estará de volta ao Enterprise Manager. Dê um clique no botão com o sinal de mais ao lado do Banco de Dados Exemplo1 para expandi-lo.

Passo 12.   Dê um clique na opção Tables. A tabela Clientes já deve estar aparecendo na listagem de tabelas do Banco de Dados exemplo, conforme indicado na Figura 4.4.

<Figura>Figura 4.4 A tabela Clientes recém criada.

Observe que aparecem uma série de outras tabelas, a maioria com o nome iniciado por sys. Estas tabelas são criadas pelo SQL Server 2005 quando criamos o Banco de Dados. Elas contém uma série de informações sobre o próprio Banco de Dados. Vamos considerar, por exemplo, a tabela sysfiles. Esta tabela contém informações sobre os arquivos – primário, secundário(s) e arquivo(s) de log – que fazem parte do Banco de Dados. Podemos facilmente conferir esta informação, simplesmente acessando os dados desta tabela. Para isso faça o seguinte: Clique com o botão direito do mouse na tabela sysfiles, no menu que surge aponte para a opção Open Table. No menu de opções que surge dê um clique em Return all rows. Com isso serão exibidos os dados desta tabela, que conforme podemos ver contém informações sobre os diversos arquivos que compõem o Banco de Dados Exemplo1, conforme indicado na Figura 4.5.

<Figura>Figura 4.5 Os dados da tabela sysfiles.

Passo 13.   Clique com o botão direito do mouse na tabela Clientes, aponte para Open Table e selecione a opção Return all rows. Irá receber uma tabela sem nenhum registro. Isso acontece porque acabamos de criar a estrutura da tabela e não existe nenhuma aplicação que utiliza a tabela Clientes e que tenha inserido dados na mesma.

Passo 14.   Feche o Enterprise Manager.

Conforme descrito no exemplo anterior, as tabelas criadas pelo próprio SQL Server 2005, iniciam com sys. Esta é uma convenção que facilita a identificação das tabelas com informações sobre o próprio Banco de Dados.

Quando criamos nossas tabelas também podemos utilizar uma convenção de nomes, o que pode vir a facilitar a identificação e o desenvolvimento de aplicativos. Por exemplo, poderíamos iniciar todas as tabelas criadas pelo DBA por usr, como um prefixo que identifica as tabelas dos usuários.

Você também pode, a qualquer momento, alterar a definição da estrutura de uma tabela. Por exemplo, podemos inserir novos campos, renomear campos ou alterar as características de um ou mais campos. Porém devemos ter muito cuidado com estes procedimentos. Se você, por exemplo, renomear uma tabela, todos os aplicativos que acessam dados desta tabela precisarão ser alterados e o nome da tabela atualizado no código destes aplicativos. Por isso que é de grande importância o cuidadoso planejamento do Banco de Dados antes da sua implementação efetiva. Um bom planejamento minimiza ou até mesmo elimina alterações deste tipo, as quais irão impactar os aplicativos que acessam dados no Banco de Dados.

Para alterar as propriedades de uma tabela basta localizá-la no Enterprise Manager, clicar com o botão direito do mouse na tabela e no menu de opções que surge, clicar na opção Design Table. Será aberta a janela com a definição de todos os campos, onde você poderá alterar os campos existentes ou adicionar novos campos.

Agora vamos a um exemplo mais detalhado. Vamos criar a tabela Funcionários com os campos descritos na Tabela 4.3. Além disso vamos aprender sobre as diversas propriedades que cada campo pode apresentar.

Tabela 4.3 A tabela Funcionários.

<Tab s/fio>Foto                        image

Vamos criar esta tabela no Banco de Dados Exemplo1, criado no capítulo anterior, na instância SERVIDOR\SRVINST01. Neste exemplo além das propriedades básicas de cada campo, aprenderemos a definir uma série de outras propriedades.

Exemplo:

Criando a tabela Funcionários com o Enterprise Manager.

Passo 1. Abra o Enterprise Manager (Iniciar -> Programas -> Microsoft SQL Server -> Enterprise Manager).

Passo 2. Clique no sinal de mais ao lado da instância SERVIDOR\SRVINST01 para expandi-la.

Passo 3. Nas opções que surgem abaixo desta instância, clique no sinal de mais ao lado da opção Databases para expandi-la. Abaixo de Databases é exibida uma lista com os Bancos de Dados disponíveis na instância SERVIDOR\SRVINST01.

Passo 4. Dê um clique na opção Databases. No painel da direita, serão exibido os Bancos de Dados disponíveis. Localize Exemplo1.

Passo 5. Dê um clique com o botão direito do mouse em Exemplo1. No menu de opções que surge, dê um clique na opção New Table. Surge a janela para a criação de uma nova tabela, conforme indicado na Figura 4.2.

Passo 6. Vamos começar criando o campo CódigoFuncionário. Para isso preencha a primeira linha com as seguintes informações:

Column Name -> CódigoFuncionário

Data Type -> int

Size -> 4 (este é preenchido automaticamente no caso de campos com tamanho já definidos, como no caso de int, real, etc.)

Allow Null -> Não (caixinha desmarcada).

Na parte de baixo da janela temos as seguintes propriedades adicionais:

• Description: Esta propriedade define o texto que será exibido na coluna quando a tabela for aberta com a opção Return all rows. Se esta propriedade não estiver definida, o texto a ser exibido é o próprio nome do campo. Para o campo CódigoFuncionário digite Código do Funcionário para esta propriedade.

• Default Value: Nesta propriedade aparece uma lista com todas as “global constraints” já definidas no Banco de Dados. O valor default é um valor que será atribuído ao campo caso o usuário não insira nenhum valor neste campo. Por exemplo, vamos supor que 99% dos funcionários sejam da cidade de São Paulo. Podemos definir São Paulo como valor default para o campo Cidade. Desta maneira sempre que uma aplicação for inserir dados na tabela Funcionários, o campo Cidade já aparece com o valor São Paulo preenchido. Caso o funcionário que está sendo cadastrado seja de uma outra cidade é só colocar o cursor no campo Cidade e digitar o nome da cidade. Com isso podemos ver que a definição de um valor padrão não impede que valores diferentes sejam digitados no campo. Para o campo CódigoFuncionário não existe valor padrão, pois cada funcionário possui um código diferente. Neste caso deixe esta propriedade em branco. Aprenderemos a criar Constraints na parte sobre desenvolvimento.

• Precision: Determina o número de dígitos a ser considerados para valores no campo que está sendo definido. No nosso exemplo como o campo CódigoFuncionário é do tipo int, esta propriedade está desabilitada. No caso de campos do tipo float ou real, esta propriedade estaria habilitada e poderíamos alterá-la.

• Scale: Define o número máximo de dígitos após a vírgula no caso de valores com decimais. No nosso exemplo está desabilitada, pois o campo CódigoFuncionário é do tipo int.

• Identity: Define se a coluna será utilizada pelo SQL Server como uma coluna de identificação. Veremos a função deste tipo de coluna no capítulo sobre Replicação. Os valores possíveis são: No, Yes e Yes (Not For Replication). Não altere esta propriedade.

• Identity Seed: Define o valor inicial para colunas do tipo Identity. Somente está habilitada quando a propriedade Identity estiver definida em Yes ou Yes (Not For Replication). Não altere esta propriedade.

• Identity Increment: Define o valor do incremento para colunas do tipo Identity. Somente está habilitada quando a propriedade Identity estiver definida em Yes ou Yes (Not For Replication). Não altere esta propriedade.

• Is RowGuid: Define se esta coluna será utilizada pelo SQL Server como uma coluna do tipo GUID. Somente pode ser definida em Yes para colunas em que Identity foi definida em Yes. Não altere esta propriedade.

• Formula: Exibe a fórmula para o caso de colunas calculadas. Lembrando do Capítulo 1, sempre que possível devemos evitar a presença de colunas calculadas. Não altere esta propriedade.

• Collation: Exibe o valor de Collation definido para a coluna. Para maiores informações sobre Collation consulte os Capítulos 2 e 3, bem como o Books OnLine. Não altere esta propriedade.

• Indexed: Esta propriedade somente aparece se houver um índice definido para o campo. Como estamos criando uma nova tabela, ainda não temos índices definidos. Os valores possíveis são: No (Não existe índice para esta coluna); Yes (duplicates OK) existe índice e o mesmo aceita valores repetidos, e Yes (no duplicates) existe índice e o mesmo não aceita valores duplicados, o qual é utilizado para campos do tipo Chave Primária. Para maiores informações sobre campos que são Chave Primária, consulte o Capítulo 1.

No nosso exemplo alteramos apenas a propriedade Description, conforme indicado na Figura 4.6.

Passo 7. Defina os demais campos da tabela Funcionários, e suas propriedades, conforme as orientações a seguir:

Campo NomeCompleto

Column Name -> NomeCompleto

Data Type -> Char

Size -> 50

Allow Null -> Não (caixinha desmarcada).

Figura 4.6 Propriedades do campo CódigoFuncionário.

Passo    Propriedades:

Description: Nome do Funcionário.

Default Value: Em branco.

Precision: Não altere.

Scale: Não altere.

Identity: Não altere.

Identity Seed: Não altere.

Identity Increment: Não altere.

Is RowGuid: Não altere.

Formula: Não altere.

Collation: Não altere.

Campo Cargo

Column Name -> Cargo

Data Type -> Char

Size -> 30

Allow Null -> Não (caixinha desmarcada).

Passo    Propriedades:

Description: Cargo do Funcionário.

Default Value: Em branco.

Não altere as demais propriedades.

Campo DataNascimento

Column Name -> DataNascimento

Data Type -> datetime

Size -> 8 (definido pelo próprio SQL Server).

Allow Null -> Não (caixinha desmarcada).

Passo    Propriedades:

Description: Data de Nascimento.

Default Value: Em branco.

Não altere as demais propriedades.

Campo DataContrato

Column Name -> DataContrato

Data Type -> datetime

Size -> 8 (definido pelo próprio SQL Server).

Allow Null -> Não (caixinha desmarcada).

Passo    Propriedades:

Description: Data de Contratação

Default Value: Em branco.

Não altere as demais propriedades.

Campo Rua

Column Name -> Rua

Data Type -> char

Size -> 50

Allow Null -> Não (caixinha desmarcada).

Passo    Propriedades:

Description: Rua do Funcionário.

Default Value: Em branco.

Não altere as demais propriedades.

Campo Bairro

Column Name -> Bairro

Data Type -> char

Size -> 20

Allow Null -> Não (caixinha desmarcada).

Passo    Propriedades:

Description: Bairro do Funcionário.

Default Value: Em branco.

Não altere as demais propriedades.

Campo Cidade

Column Name -> Cidade

Data Type -> char

Size -> 25

Allow Null -> Não (caixinha desmarcada).

Passo    Propriedades:

Description: Cidade do Funcionário.

Default Value: São Paulo (estamos definindo o valor padrão como São Paulo, pois a maioria dos funcionários são da Cidade de São Paulo). Observe que após definirmos o valor padrão, o SQL Server coloca o mesmo entre apóstrofes: ‘São Paulo’.

Não altere as demais propriedades.

Campo CEP

Column Name -> CEP

Data Type -> int

Size -> 4

Allow Null -> Não (caixinha desmarcada).

Passo    Propriedades:

Description: CEP

Default Value: Em branco.

Não altere as demais propriedades.

Campo FoneResidencial

Column Name -> FoneResidencial

Data Type -> char

Size -> 25

Allow Null -> Não (caixinha desmarcada).

Passo    Propriedades:

Description: Telefone Residencial.

Default Value: Em branco.

Não altere as demais propriedades.

Campo Foto

Column Name -> Foto

Data Type -> image

Size -> 16 (definido automaticamente pelo SQL Server. Conforme descrito anteriormente este tamanho de 16 bytes é simplesmente um ponteiro que aponta para o arquivo com a imagem. O arquivo com a imagem pode conter até cerca de 2 GB).

Allow Null -> Não (caixinha desmarcada).

Passo    Propriedades:

Description: Foto do Funcionário.

Default Value: Em branco.

Não altere as demais propriedades.

Agora é hora de salvarmos a tabela no Banco de Dados Exemplo1.

Passo 8. Dê um clique no botão Save. Surge uma janela pedindo o nome da tabela. Digite Funcionários e dê um clique no botão OK.

Passo 9. Você estará de volta a janela para definição dos campos. Feche-a.

Passo 10.   Você estará de volta ao Enterprise Manager. Dê um clique no botão com o sinal de mais ao lado do Banco de Dados Exemplo1 para expandi-lo.

Passo 11.   Dê um clique na opção Tables. A tabela Clientes já deve estar aparecendo na listagem de tabelas do Banco de Dados Exemplo1, conforme indicado na Figura 4.7. Caso a tabela ainda não esteja aparecendo pressione a tecla F5 (Refresh) para atualizar a visão Tables do Banco de Dados Exemplo1.

Passo 12.   Com isso criamos a tabela Funcionários no banco de dados Exemplo1. Se você clicar com o botão direito do mouse na tabela Funcionários, apontar para Open Table e selecionar a opção Return all rows, irá receber uma tabela sem nenhum registro. Isso acontece porque acabamos de criar a estrutura da tabela e não existe nenhuma aplicação que utiliza a tabela Funcionários e que tenha inserido dados na mesma.

Figura 4.7 A tabela Funcionários recém criada.

Passo 13.   Feche o Enterprise Manager.

Olhe na Figura 4.7, na coluna “Create Date”, onde aparece o valor: 25/2/2001 20:50:19. É isto mesmo meu amigo, domingo, 25 de fevereiro, quase 11 horas da noite. Domingo de Carnaval e este amigo de vocês firme escrevendo mais um capítulo deste livro. É claro que de vez em quando dou uma escapada para a frente da televisão. Este ano é sem Carnaval, mas no ano que vem..., a no ano que vem só Deus sabe. Carnaval ou um livro de Windows XP? Bem voltemos ao nosso SQL Server 2005.

Agora já estamos “craques” na criação de tabelas com o Enterprise Manager. O próximo passo será aprendermos a criar tabelas utilizando o comando CREATE TABLE no Query Analyzer.

Mas antes disso vamos a um exercício para que o leitor possa fixar os conceitos apresentados.

Exercício: Crie a tabela Fornecedores, utilizando o Enterprise Manager, com os campos indicados na Tabela 4.4.

Tabela 4.4 A tabela Fornecedores.

<Tab s/fio>Bairro                     Texto de, no máximo, 20 caracteres.

<Tab s/fio>WebSite                Texto de, no máximo, 100 caracteres.

Estamos criando um Banco de Dados com uma estrutura semelhante ao Northwind. Nos exercícios para criação de índices e views utilizaremos o Banco de Dados Northwind, pois este já possui diversos registros em suas tabelas, o que facilita a visualização dos resultados de nossos exercícios.

Fundamentos em: Criação de Tabelas com o Query Analyzer

Pré-Requisitos

Noções dos conceitos básicos sobre Bancos de Dados Relacionais.

Saber utilizar o Query Analyzer para executar comandos.

Noções sobre os tipos básicos de dados do SQL Server 2005.

Metodologia

Apresentação dos comandos T-SQL para criação de tabelas.

Técnica

Criação de tabelas utilizando os comandos apresentados.

Para criarmos uma tabela utilizamos o comando CREATE TABLE no Query Analyzer. A seguir temos a sintaxe deste comando, conforme descrito no Books Online:

Sintaxe completa - Books OnLine - Transact SQL Reference:

CREATE TABLE

[ database_name.[ owner ] . | owner. ] table_name

( { < column_definition >

| column_name AS computed_column_expression

| < table_constraint > ::= [ CONSTRAINT constraint_name ] }

| [ { PRIMARY KEY | UNIQUE } [ ,...n ]

)

[ ON { filegroup | DEFAULT } ]

[ TEXTIMAGE_ON { filegroup | DEFAULT } ]

< column_definition > ::= { column_name data_type }

[ COLLATE < collation_name > ]

[ [ DEFAULT constant_expression ]

| [ IDENTITY [ ( seed , increment ) [ NOT FOR REPLICATION ] ] ]

]

[ ROWGUIDCOL]

[ < column_constraint > ] [ ...n ]

< column_constraint > ::= [ CONSTRAINT constraint_name ]

{ [ NULL | NOT NULL ]

| [ { PRIMARY KEY | UNIQUE }

[ CLUSTERED | NONCLUSTERED ]

[ WITH FILLFACTOR = fillfactor]

[ON {filegroup | DEFAULT} ] ]

]

| [ [ FOREIGN KEY ]

REFERENCES ref_table [ ( ref_column) ]

[ ON DELETE { CASCADE | NO ACTION } ]

[ ON UPDATE { CASCADE | NO ACTION } ]

[ NOT FOR REPLICATION ]

]

| CHECK [ NOT FOR REPLICATION ]

( logical_expression )

}

< table_constraint > ::= [ CONSTRAINT constraint_name ]

{ [ { PRIMARY KEY | UNIQUE }

[ CLUSTERED | NONCLUSTERED ]

{ ( column [ ASC | DESC ] [ ,...n ] ) }

[ WITH FILLFACTOR = fillfactor ]

[ ON { filegroup | DEFAULT } ]

]

| FOREIGN KEY

[ ( column [ ,...n ] ) ]

REFERENCES ref_table [ ( ref_column [ ,...n ] ) ]

[ ON DELETE { CASCADE | NO ACTION } ]

[ ON UPDATE { CASCADE | NO ACTION } ]

[ NOT FOR REPLICATION ]

| CHECK [ NOT FOR REPLICATION ]

( search_conditions )

}

Este formato genérico não é muito intuitivo, ou melhor, não é nada intuitivo. Vamos simplificar um pouco. A seguir apresento uma sintaxe simplificada, somente com as principais opções para criar uma tabela com alguns campos.

CREATE TABLE Nome_da_tabela

— Agora inicio a definição básica dos campos da tabela

(

Campo1 tipo_do_Campo1      NULL ou NOT NULL

Campo2 tipo_do_Campo2      NULL ou NOT NULL

Campo3 tipo_do_Campo3      NULL ou NOT NULL

Campo4 tipo_do_Campo4      NULL ou NOT NULL

Campo5 tipo_do_Campo5      NULL ou NOT NULL

Campon tipo_do_Campon      NULL ou NOT NULL

)

A título de exemplo, vamos criar a tabela Produtos com os campos indicados na Tabela 4.5.

Tabela 4.5 A tabela Produtos.

<Tab s/fio>PreçoUnitário       Money

<Tab s/fio>Descontinuado    bit (0=sim, 1=não)

Agora vamos criar esta tabela no Banco de Dados Exemplo1 da instância SRVIDOR\SRVINST01. Vamos utilizar, para isso, o comando CREATE TABLE, no Query Analyzer.

Exemplo:

Utilizando o Query Analyzer, criar a tabela Produtos, conforme descrito na Tabela 4.5.

Passo 1. Abra o Query Analyzer (Iniciar -> Programas -> Microsoft SQL Server -> Query Analyzer).

Passo 2. Na janela de conexão, selecione Windows Authentication, e no campo SQL Server digite SERVIDOR\SRVINST01. Clique em OK para fazer a conexão. Será aberto o Query Analyzer com o Banco de Dados master como sendo o Banco de Dados atual.

Passo 3. Alterne para Exemplo1, utilizando a lista com os nomes dos Bancos de Dados, na Barra de Ferramentas e digite o seguinte comando:

— Definição do nome da tabela.
CREATE TABLE Produtos
— Inicio a definição dos campos.
(
CódigoProduto       int,
NomeProduto         char(50),
CódigoFornecedor    int,
CódigoCategoria     int,
PreçoUnitário       money,
UnidadesEstoque     int,
EstoqueMínimo       int,
Descontinuado       bit
)

Certifique-se de ter alternado para o Banco de Dados Exemplo1, utilizando a lista com os nomes dos Bancos de dados na Barra de Ferramentas ou o comando Use Exemplo1 no Query Analyzer.

Ao executar este comando, se você não tiver cometido nenhum erro de digitação, a tabela Produtos terá sido criada no Banco de Dados Exemplo1 e a seguinte mensagem é exibida no painel inferior do Query Analyzer:

The command(s) completed successfully.

Com isso, vemos que a tabela Produtos foi criada.

Passo 4. Mantenha o Query Analyzer aberto, pois vamos utilizá-lo para mais alguns exemplos neste capítulo. Apenas minimize-o.

Agora vamos utilizar o Enterprise Manager para verificar se a tabela Produtos foi realmente criada.

Exemplo:

Verificando se a tabela Produtos foi realmente criada:

Passo 1. Abra o Enterprise Manager.

Passo 2. Clique no sinal de mais ao lado de SQL Server Group para abri-lo.

Passo 3. Clique no sinal de mais ao lado da instância SERVIDOR\SRVINST01 para expandi-la.

Passo 4. Clique no sinal de mais ao lado de Databases para expandi-la.

Passo 5. Clique no sinal de mais ao lado do Banco de Dados Exemplo1 para exibir as suas opções.

Passo 6. Nas opções que surgem dê um clique em Tables para exibir as tabelas do Banco de Dados Exemplo1. Observe que a tabela Produtos já deve aparecer na listagem de tabelas.

Passo 7. Feche o Enterprise Manager.

Se a tabela Produtos ainda não aparecer na listagem de tabelas, clique na opção Tables do Banco de Dados Exemplo1 e pressione F5 para atualizar a listagem.

No exemplo anterior criamos uma tabela utilizando as opções básicas do comando CREATE TABLE. Vamos ver mais alguns exemplos deste comando, utilizando opções mais avançadas do CREATE TABLE. Mas antes disso vamos ver alguns “limites” do SQL Server 2005.

• Podemos ter até dois bilhões de tabelas por Banco de Dados.

• O número máximo de colunas por tabela é 1024.

• Os números máximos de linhas e do tamanho de uma tabela são limitados apenas pelo espaço disponível em disco.

• O número máximo de bytes por linha é de 8060. Se criarmos tabelas com colunas do tipo varchar, nvarchar ou varbinary, nas quais o total de bytes do registro excede 8060 bytes, a tabela será criada, porém uma mensagem de aviso será emitida. Ao efetuarmos alguma operação de alteração ou inserção em que um determinado registro fique com mais do que 8600 bytes, receberemos uma mensagem de erro e o comando não será executado.

Um comando CREATE TABLE que inclui colunas do tipo sql_variant poderão gerar o seguinte aviso:

“The total row size (xx) for table ‘yy’ exceeds the maximum number of bytes per row (8060). Rows that exceed the maximum number of bytes will not be added.”

Algumas das opções do comando CREATE TABLE somente serão utilizadas no Capítulo 9, onde aprenderemos a criar Constraints, Defaults e Rules.

Conforme visto na seção anterior, podemos definir uma série de propriedades para cada campo de uma tabela, utilizando o Enterprise Manager. A pergunta que fica é: “Também podemos definir estas opções utilizando o comando CREATE TABLE?” E a resposta é sim.

Exemplo:

Como faço para definir que um campo não deve aceitar valores NULL?

Vamos alterar um pouco o comando do exemplo anterior, conforme indicado a seguir:

— Definição do nome da tabela.

CREATE TABLE Produtos

— Inicio a definição dos campos.

(

CódigoProduto int          NOT NULL,

NomeProduto          char(50)     NOT NULL,

CódigoFornecedor     int          NOT NULL,

CódigoCategoria      int          NOT NULL,

PreçoUnitário money        NOT NULL,

UnidadesEstoque      int          NOT NULL,

EstoqueMínimo int          NOT NULL,

Descontinuado bit          NOT NULL

)

Este comando criaria a mesma tabela Produtos do exemplo anterior, porém sem permitir valores nulos em qualquer campo.

Para permitir NULL em algum campo, bastaria trocar NOT NULL por NULL.

Assim como devemos criar uma padronização para o nome dos Bancos de Dados e tabelas, também devemos ter um certo padrão para a nomeação dos campos de uma tabela. Consulte a documentação da sua empresa para saber se já existe um documento definindo o padrão para a nomeação de Bancos de Dados, tabelas e campos.

Nomes de colunas, tabelas, campos ou qualquer objeto no SQL Server 2005 podem ter um tamanho máximo de 128 caracteres. Podemos incluir letras, dígitos e os símbolos: #, $, @ e _ nos nomes de objetos do SQL Server 2005.

Exercício: Para fixar a sintaxe do comando CREATE TABLE, crie a tabela Produtos Especiais, com os campos conforme descrito na Tabela 4.6.

Tabela 4.6 A tabela Produtos Especiais.

<Tab s/fio>PreçoUnitário                                                            money  Não

<Tab s/fio>Descontinuado                                                         bit (0=sim, 1=não)             Não

Fundamentos em: Alterar a Estrutura de uma Tabela com o Enterprise Manager

Pré-Requisitos

Noções dos conceitos básicos sobre Bancos de Dados Relacionais.

Saber utilizar o Enterprise Manager.

Metodologia

Utilização do Enterprise Manager para alterar a estrutura de uma tabela.

Embora não seja recomendado, podemos alterar a estrutura de uma tabela. Não é uma prática recomendada, pois se o Banco de Dados for bem projetado (conforme venho insistindo e repetindo diversas vezes), não haverá necessidade de alterações na estrutura das tabelas. Mas caso seja necessária tal alteração, podemos procedê-la utilizando o Enterprise Manager, conforme aprenderemos neste item, ou comandos T-SQL, conforme aprenderemos em seguida.

Para alterar uma tabela, basta localizá-la no Enterprise Manager, clicar com o botão direito do mouse no nome da tabela e no menu que surge, clicar na opção Design Table. Será exibida a janela com a estrutura da tabela. Nesta janela podemos fazer as seguintes alterações, dentre outras:

• Excluir um campo: Para isso basta selecionar a linha que define o campo e pressionar a tecla Delete. Para selecionar uma linha, basta clicar no botão cinza, bem a esquerda da linha, conforme indicado na Figura 4.8.

• Alterar as propriedades de um campo, simplesmente editando as informações para este campo.

• Incluir novos campos.

Feitas as alterações é só clicar no botão Save, para salvar as alterações efetuadas.

Muitas vezes, devido a prazos apertados, o cuidadoso projeto do Banco de Dados é encarado como uma “perda de tempo” e deixado em segundo plano. Isso acaba por trazer uma série de problemas que poderiam ser evitados com um cuidadoso projeto do Banco de Dados. Lembre que é muito mais complicado remendar do que fazer bem feito da primeira vez.

Figura 4.8 Selecionando o campo a ser excluído.

Fundamentos em: Alterar a Estrutura de uma Tabela com Comandos T-SQL

Pré-Requisitos

Noções dos conceitos básicos sobre Bancos de Dados Relacionais.

Saber utilizar o Query Analyzer para executar comandos.

Metodologia

Apresentação dos comandos T-SQL para alteração de tabelas.

Técnica

Alterar tabelas, utilizando os comandos apresentados.

Existem alguns comandos T-SQL que permitem que sejam feitas alterações em uma tabela. Vamos aprender a utilizá-los.

Para adicionar uma coluna em uma tabela, utilizamos o seguinte comando:

ALTER TABLE nome_da_tabela

ADD nome_do_campo  tipo_dado

Vamos tentar o seguinte exemplo:

ALTER TABLE CLIENTES

ADD Campo1       Char(25)     Not Null

Este exemplo irá gerar a seguinte mensagem de erro:

Server: Msg 4901, Level 16, State 1, Line 1

ALTER TABLE only allows columns to be added that can contain nulls or have a DEFAULT definition specified. Column ‘Campo1’ cannot be added to table ‘CLIENTES’ because it does not allow nulls and does not specify a DEFAULT definition.

Sem subestimar o conhecimento de Inglês do amigo leitor, esta mensagem está nos dizendo que o comando ALTER TABLE somente permite que sejam adicionadas colunas que permitem valores Nulos ou que possuem um valor padrão definido para a coluna. Como não podemos “brigar” com o SQL Server 2005, vamos alterar um pouco o comando para que a coluna Campo1 que está sendo adicionada permita valores Nulos. Nosso comando fica assim:

ALTER TABLE CLIENTES

ADD Campo1       Char(25)

Agora nosso comando executa sem maiores problemas e recebemos a seguinte mensagem:

The command(s) completed successfully.

Exercício: Utilize o Enterprise Manager e verifique se a coluna Campo1 realmente foi adicionada à tabela Clientes, conforme indicado na Figura 4.9.

Figura 4.9 A coluna Campo1 recém adicionada.

Observe que a coluna Campo1 admite valores Nulos.

Para excluir uma coluna em uma tabela, utilizamos o seguinte comando:

ALTER TABLE nome_da_tabela

DROP COLUMN nome_do_campo

Vamos excluir a coluna Campo1 adicionada no exemplo anterior.

ALTER TABLE Clientes

DROP COLUMN Campo1

Este comando executa com sucesso e retorna a mensagem:

The command(s) completed successfully.

Exercício: Utilize o Enterprise Manager e verifique se a coluna Campo1 realmente foi excluída da tabela Clientes.

Também podemos fazer alterações em uma coluna já existente, utilizando o comando ALTER COLUMN. No exemplo a seguir, vamos adicionar um campo chamado teste, o qual é do tipo smallint. Depois vamos alterá-lo para o tipo int e finalmente vamos excluí-lo da tabela Clientes.

— Adicionando o campo teste do tipo smallint

ALTER TABLE Clientes

ADD teste smallint

GO

—Alterando o tipo do campo para int

ALTER TABLE Clientes

ALTER COLUMN teste int

GO

—Excluindo o campo teste

ALTER TABLE Clientes

DROP COLUMN teste

Ao executarmos este comando recebemos a seguinte mensagem:

(0 row(s) affected)

Fundamentos em: Tipos de Dados Definidos Pelo Usuário

Pré-Requisitos

Noções dos conceitos básicos sobre Bancos de Dados Relacionais.

Saber Utilizar o Enterprise Manager e o Query Analyzer.

Conhecer os tipos básicos de dados do SQL Server 2005.

Metodologia

Utilizar o Enterprise Manager e o Query Analyzer para criar tipos de dados personalizados.

No início do capítulo vimos os diversos tipos de dados disponibilizados pelo SQL Server 2005. São os chamados “Tipos de dados do sistema” (System data types). Com o SQL Server 2005, o usuário pode criar seus próprios tipos de dados.

Por exemplo, vamos supor que o usuário queira padronizar que todos os campos com nomes próprios, quer seja de funcionários, clientes ou fornecedores, devam ser do tipo char com tamanho máximo de 50 caracteres. O usuário poderia criar um novo tipo chamado nome_próprio e definir este tipo como sendo char(50). Desta maneira quando for criar as suas tabelas, o usuário pode definir os campos como sendo do tipo nome_próprio, que automaticamente será assumido char(50). Uma das vantagens evidentes é a facilidade de manutenção. Vamos supor que após algum tempo de utilização do Banco de Dados, chegou-se a conclusão que char(40) é suficiente para os campos com nomes próprios. Para alterar a definição de todos os campos, bastaria alterar o tipo nome_próprio definido pelo usuário. Se não estivéssemos utilizando um tipo definido pelo usuário, teríamos que ir de tabela em tabela alterando char(50) para char(40).

Ao criar tipos definidos pelo usuário (User data types), devemos utilizar um padrão de nomes consistente, de tal forma que, seja um indicativo das características do mesmo.

Ao criarmos um tipo definido pelo usuário, o mesmo somente estará disponível no Banco de Dados onde o tipo tiver sido criado. Se criarmos um tipo definido pelo usuário no Banco de Dados Model, este tipo passará a fazer parte de todos os novos Bancos de Dados que forem criados.

Agora vamos aprender a criar User data types. Inicialmente vamos criá-los utilizando o Enterprise Manager e, na seqüência, o Query Analyzer.