Este comando permite a criação de tabelas no banco de dados ou mesmo de sua criação.
Sintaxe:
CREATE DATABASE < nome_db >;
onde:
nome_db - indica o nome do Banco de Dados a ser criado.
Sintaxe:
CREATE TABLE < nome_tabela >
( nome_atributo1 < tipo > [ NOT NULL ],
nome_atributo2 < tipo > [ NOT NULL ],
......
nome_atributoN < tipo > [ NOT NULL ] ) ;
onde:
nome_table - indica o nome da tabela a ser criada.
nome_atributo - indica o nome do campo a ser criado na tabela.
tipo - indica a definição do tipo de atributo ( integer(n), char(n), real(n,m), date... ).
n- número de dígitos ou de caracteres
m- número de casas decimais
Para criar uma tabela. Use o editor e digite na linha de comando do SQL (DB2).
CREATE DATABASE TRABALHO;
O comando acima criou um Banco de Dados, porém este na verdade não passa de uma abertura no diretório, pois não conta com nenhuma tabela.
Para criar as tabelas que estarão contidas no Banco de Dados TRABALHO.
A primeira Tabela será a de Departamentos (DEPT). Esta tabela conterá além dos campos também sua chave primária, suas chaves estrangeiras e também seus índices. A segunda tabela será a de Empregados (EMP), que também será criada.
Não devemos esquecer de primeiramente abrirmos o Banco de Dados. Diferentemente do que ocorre em alguns aplicativos, em SQL o fato de criarmos um Banco de Dados, não significa que o banco recém criado já está preparado para utilização. A instrução a seguir, providencia a abertura do Banco de Dados criado.
OPEN DATABASE TRABALHO;
Agora estamos prontos para criarmos as tabelas necessárias. Lembramos aos Estudantes, que o Arquivo TABS.SQL, contém todas as instruções necessárias para criação do Banco de Dados Trabalho e de suas tabelas. Já o Arquivo DADOS.SQL irá popular estas tabelas. Para efeitos didáticos, criamos as tabelas de forma que sua população, em outras palavras os dados, sejam facilmente referenciáveis pelos estudantes. Assim sendo, na tabela de departamentos, contamos com 5 departamentos, cada um deles tendo seu gerente. Todos os “gerentes” tem nomes de cantoras brasileiras (Gal Costa, Marina Lima, etc), todos os “operários” tem nomes de jogadores de futebol, todas as vendedoras tem nomes de jogadoras de volei, todas as balconistas tem nome de jogadoras de basquete e o presidente da empresa exemplo, tem o mesmo nome do presidente do Brasil. Desta forma os testes devem resultar em grupos bastante definidos. Assim se você estiver listando Gerentes e aparecer um homônimo da Ana Paula (jogadora de volei), verifique sua query atentamente, pois muito provavelmente a mesma estará errada.
A seguir código necessário a criação da tabela Departamento e seu índice:
create table Dept
(DepNume integer(4) not null,
DepNome char(20) not null,
DepLoca char(20) not null,
DepOrca integer(12,2),
primary key (DepNume)
);
create unique index DepNum on Dept (DepNume asc);
Note-se que a chave primária já está definida juntamente com o registro da tabela. A criação do índice, que por razões óbvias deve ser criado após a tabela, naturalmente é um comando totalmente independente do primeiro create, que serviu para criar a tabela e suas característica básicas.
Vamos analisar o código necessário para a criação da tabela de empregados, apresentado a seguir:
create table Emp
(EmpNume integer(5) not null,
EmpNome char(30) not null,
EmpGere integer(5) ,
EmpServ char(20) ,
DepNume integer(4) not null,
EmpAdmi date not null,
EmpSala integer(10,2),
EmpComi integer(10,2),
primary key (EmpNume),
foreign key has (DepNume)
references Dept
on delete restrict
on update cascade
);
create unique index EmpNum on Emp (EmpNume asc);
create index EmpDep on Emp (DepNume asc);
A Tabela de Empregados não poderia ter sido criada antes da Tabela de Departamento, pois contém uma referência direta àquela tabela. Quando declaramos que DepNume é chave estrangeira, promovemos de fato a ligação do cadastro de empregados como o cadastro de departamentos. Ao restringirmos as exclusões, permitimos a existência de funcionários não alocados a nenhum departamento. Apesar desta prática ser contrária a tese de que devemos possuir apenas tuplas perfeitamente relacionáveis em nossas tabelas, podemos deixar esta pequena abertura, pois um usuário que excluisse inadivertidamente determinado departamento, acabaria por excluir também uma grande quantidade de funcionários, que estivessem ligados a este departamento.
Já a atualização em cascata dos códigos de departamento é uma boa providência, na medida em que teremos, uma vez alterado algum código de departamento, a atualização imediata de todos os funcionários pertencentes ao departamento cujo código foi modificado.
Observações:
- Observar que os índices são parte intrínseca das tabelas.
- A integridade relacional é garantida pelo Banco de Dados e não pelo aplicativo.
- Exclusões ou Alterações em Chaves Primárias, podem acarretar exclusões, anulações ou até mesmo perda de integridade nas tabelas onde esta chave primária existir como chave estrangeira. Portanto é imprescindível muito cuidado quando da elaboração do Banco de Dados. Uma tentação muito comum ao estudante é começar criando as tabelas do Banco de Dados sem prévia Normalização. Este talvez seja o melhor caminho para perder-se tempo em vão, pois quando você terminar de projetar suas telas de entrada de dados, notará "que nada funciona!". Esta será a senha para usar o velho comando DEL do DOS e depois começar tudo de novo ...