1
resposta

MINHA RESOLUÇÃO

Boa noite a todos,

Primeiramente criei a TABELA_EMPRESA

CREATE TABLE TABELA_EMPRESA
(CODIGO_EMPRESA VARCHAR2(5) NOT NULL
,NOME_EMPRESA VARCHAR2(50) NULL,
CONSTRAINT PK_EMPRESA PRIMARY KEY (CODIGO_EMPRESA));

Após criar a primeira tabela, fiz a segunda tabela TABELA_DEPARTAMENTO

CREATE TABLE TABELA_DEPARTAMENTO
(CODIGO_DEPARTAMENTO VARCHAR2(5) NOT NULL
,NOME_DEPARTAMENTO VARCHAR2(50) NULL
,CIDADE_DEPARTAMENTO VARCHAR2(50) NULL
,CODIGO_EMPRESA VARCHAR2(5) NOT NULL,
CONSTRAINT PK_DEPARTAMENTO PRIMARY KEY (CODIGO_DEPARTAMENTO),
CONSTRAINT FK_TABELA_EMPRESA FOREIGN KEY (CODIGO_EMPRESA) REFERENCES TABELA_EMPRESA (CODIGO_EMPRESA));

E por fim a terceira tabela, Tabela_Projetos

CREATE TABLE TABELA_PROJETO
(CODIGO_PROJETO VARCHAR2(5) NOT NULL
,NOME_PROJETO VARCHAR2(50) NULL
,ORCAMENTO_PROJETO FLOAT NULL
,DATA_INICIO_PROJETO DATE NULL
,CODIGO_DEPARTAMENTO VARCHAR2(5) NOT NULL,
CONSTRAINT PK_PROJETO PRIMARY KEY (CODIGO_PROJETO),
CONSTRAINT FK_TABELA_DEPARTAMENTO FOREIGN KEY (CODIGO_DEPARTAMENTO) REFERENCES TABELA_DEPARTAMENTO (CODIGO_DEPARTAMENTO)); 
1 resposta

Olá, Adriano! Tudo bem?

Parabéns pela excelente resolução! Você demonstrou um domínio muito seguro sobre a criação de estruturas de banco de dados, utilizando conceitos fundamentais do Oracle Database e da linguagem SQL.

Sua abordagem para criar as tabelas seguiu uma ordem lógica perfeita, o que é essencial quando trabalhamos com integridade referencial.

Pontos de Destaque na sua Resolução:

  • Hierarquia de Criação: Você criou primeiro a TABELA_EMPRESA, depois a TABELA_DEPARTAMENTO e, por fim, a TABELA_PROJETO. Isso está correto pois, em um banco de dados relacional, não podemos criar uma chave estrangeira (FK) que aponta para uma tabela que ainda não existe.
  • Integridade Referencial (FK): O uso de CONSTRAINT ... FOREIGN KEY ... REFERENCES garante que nenhum departamento seja vinculado a uma empresa inexistente e nenhum projeto fique "órfão" de um departamento.
  • Chaves Primárias (PK): A definição das chaves primárias em todas as tabelas assegura que cada registro seja único e facilita a indexação dos dados para consultas futuras.
  • Tipagem de Dados: Você utilizou corretamente o VARCHAR2, que é otimizado para o Oracle, e o tipo DATE para o início dos projetos, permitindo cálculos temporais precisos posteriormente.

Uma Pequena Dica de Modelagem:

Notei que você usou VARCHAR2(5) para os códigos de identificação. Isso é ótimo para economizar espaço se os códigos forem curtos. No entanto, se a empresa crescer muito, 5 caracteres podem se tornar um limite rápido. Em grandes sistemas, muitos desenvolvedores optam pelo tipo NUMBER com sequenciadores automáticos (IDENTITY no Oracle 12c+), o que facilita a escalabilidade.

Excelente trabalho mantendo a organização do código e o padrão de nomenclatura das Constraints!

Espero que possa ter lhe ajudado!

Agora que as tabelas estão prontas, qual será o seu próximo passo: inserir dados de teste com o comando INSERT ou aplicar alguma alteração na estrutura com o ALTER TABLE?