O Banco de Dados

...

- Código da empresa (pois cada empresa que é atendida pela EJ possui uma codificação única).

Monovalorado: atributos que assumem um valor único dentro do domínio.

- Datas de início e fim dos projetos e das consultorias; data de realização e duração dos treinamentos; data de nascimento e idade dos membros (pois são valores particulares de cada entidade);

Composto: atributos que são compostos por mais de um atributo.

- Endereço da cidade natal e endereço de Sorocaba dos membros, endereço da empresa atendida (pois podem possuem outros campos, como CEP e bairro, que podem ser decompostos em outros atributos).

Simples: atributos que não possuem características especiais, não são atributos chave e nem compostos.

- Nome dos cargos;

- Turma, telefone (só um telefone será cadastrado por pessoa) e nome dos membros;

- Ementa, descrição e nome dos treinamentos;

- Descrição dos projetos;

- Nome das áreas;

- Descrição e nome das consultorias;

- Nome, nome de contato e telefone de contato (apenas um) da empresa.

Todos os atributos acima são nominais e apenas de identificação.

- Modelo Entidade-Relacionamento (MER)

[pic 1]O BDLider, acima descrito, pode ser representado com o uso de ferramentas específicas de banco de dados, abaixo é apresentado o BDLider de acordo com o “Modelo de Entidade Relacionamento (MER), com cardinalidade”

Figura 1 - BDLider: Modelo de Entidade Relacionamento (MER), com cardinalidade

- Modelo Lógico Normalizado

Primeira Forma Normal (1FN)

A primeira forma normal das tabelas encontra-se mostradas abaixo (Os atributos sublinhados representam a chave primária de cada tabela). Para cada tabela, de cada atributo, não existem tabelas aninhadas.

Area (A_Codigo; A_Nome)

Cargos (C_Codigo; C_Nome)

Consultorias (Cons_Codigo; Emp_Codigo; Cons_Nome; Cons_Desc; Cons_Inicio; Cons_Final)

Empresas (Emp_Codigo; Emp_Nome; Emp_NomeContato; Emp_TelContato; Emp_Endereço)

Membro (Mem_Codigo; C_Codigo; A_Codigo; Mem_Nome; Mem_Nasc; Mem_Tel; Mem_Email; Mem_Skype; Mem_Turma; Mem_Endereco; Mem_EndSorocaba)

Projetos (Pro_Codigo; Pro_Descricao; Pro_Inicio; Pro_Final)

Treinamento (Trn_Codigo; Trn_Nome; Trn_Descrição; Trn_Data; Trn_Duração; Trn_Ementa)

Segunda Forma Normal (2FN)

Para uma tabela encontrar-se na segunda forma normal, ela precisa estar na sua primeira forma normal e não conter dependências parciais. Ou seja, todos os campos não-chaves da tabela devem depender do campo chave.

Dessa forma, analisando as tabelas, foram elaboradas as segundas formas normais das tabelas, mostradas abaixo. Em relação à primeira forma normal, as únicas modificações foram em relação à tabela consultorias, onde foi retirada a chave primária Emp_Codigo, já que esse atributo não depende da entidade consultoria, mas, sim, da entidade empresas. Assim, criou-se uma tabela denominada Consultoria_Empresa para relacionar o código da consultoria com o código da empresa onde está sendo realizada a consultoria. O mesmo raciocínio foi utilizado para as chaves primárias C_Codigo e A_Codigo, da tabela Membro. Esses dois atributos não dependem da entidade membro, mas da entidade cargo e área, respectivamente. Logo, criou-se duas tabelas, uma para relacionar membros com cargos (tabela Membro_Cargo) e outra para relacionar membros com áreas (tabela Membro_Area).

Area (A_Codigo; A_Nome)

Cargos (C_Codigo; C_Nome)

Consultorias (Cons_Codigo; Cons_Nome; Cons_Desc; Cons_Inicio; Cons_Final)

Consultoria_Empresa (Cons_Codigo; Emp_Codigo)

Empresas (Emp_Codigo; Emp_Nome; Emp_NomeContato; Emp_TelContato; Emp_Endereço)

Membro (Mem_Codigo; Mem_Nome; Mem_Nasc; Mem_Tel; Mem_Email; Mem_Skype; Mem_Turma; Mem_Endereco; Mem_EndSorocaba)

Membro_Cargo (Mem_Codigo; C_Codigo)

Membro_Area (Mem_Codigo; A_Codigo)

Projetos (Pro_Codigo; Pro_Descricao; Pro_Inicio; Pro_Final)

Treinamento (Trn_Codigo; Trn_Nome; Trn_Descrição; Trn_Data; Trn_Duração; Trn_Ementa)

Terceira Forma Normal (3FN)

Para uma tabela estar na terceira forma normal, além de estar na segunda forma normal, ela não deve conter dependências transitivas. Ou seja, em uma tabela, um campo depende de outro que não seja a chave primária da tabela.

Analisando as tabelas, percebe-se que na tabela Treinamento, encontra-se um exemplo de dependência transitiva em relação aos campos Trn_Duração e Trn_Ementa. A duração de um treinamento depende da sua ementa, que contém todo o planejamento desse treinamento. Então, criou-se uma tabela denominada Trn_Ementa_Duração para relacionar esses dois campos, eliminando, desta forma, a dependência transitiva existente no modelo.

Area (A_Codigo; A_Nome)

Cargos (C_Codigo; C_Nome)

Consultorias (Cons_Codigo; Cons_Nome; Cons_Desc; Cons_Inicio; Cons_Final)

Consultoria_Empresa