modelo_prj_bd

Projeto de Banco de Dados
NOME DO PROJETO
Fulano de Tal
Beltrano de Tal
Professor: Ricardo Rodrigues Barcelar
Atenção!
Este modelo deve ser alterado de acordo com a estratégia de projeto de banco de
dados adotada.
Dessa forma, vide apostila que trata de estratégia de projeto de banco de dados antes
de começar o trabalho.
Cuiabá/MT
Novembro – 2009
1
ÍNDICE
1
1. INTRODUÇÃO
O presente relatório tem como finalidade apresentar todas as fases de
desenvolvimento de um banco de dados realizado durante a disciplina de Banco de
Dados. Esse é um banco de dados hipotético criado para verificar os conceitos vistos
em sala de aula.
O banco de dados final foi resultado da integração de sistemas encontrados
em uma empresa de manufatura, sendo eles Sistema de Compras e Pessoal, Sistema
de Manutenção e Sistema de Produção (Colocar qual é a situação do seu projeto).
Para tanto utilizou-se a estratégia de projeto de banco de dados ... (Top-
Down/Bottom-Up)
A fases do projeto foram as seguintes:
1.
2.
3.
4.
Ver conforme estratégia.
Nas seções seguintes, serão descritas com detalhes as etapas citadas acima.
2
2. ETAPAS (Descrever etapa por etapa. Aqui é somente o exemplo. Deve
conter todas as etapas que você desenvolveu bem especificada)
2.1. LEVANTAMENTO DE REQUISITOS E MODELAGEM (exemplo)
Inicialmente, o projeto foi dividido em três sistemas:

Sistema de compras e gerência de pessoal;

Sistema de manutenção;

Sistema de produção.
Desses sistemas, foram observadas as principais funcionalidades e ações
realizadas, para então, se determinar quais seriam as entidades e os seus atributos
relevantes. Em seguida, foram determinadas as relações entre essas entidades e os
atributos dessas relações.
De posse desses elementos, foi efetuada uma normalização dos mesmos de
forma a evitar redundâncias e problemas semânticos no banco de dados. A partir
dessa normalização, foram criados os dicionários de dados para cada um desses
sistemas, separadamente.
Em seguida, foram determinadas quais seriam as restrições de integridade e as
prováveis consultas que poderiam ser feitas a esses sistemas com uma maior
freqüência, definido-se, assim, um conjunto de consultas para o banco de dados.
Finalizando essa etapa, foi feita a modelagem dos sistemas, separadamente,
utilizando-se o software DBDesign. Foi utilizado o método semântico para a
modelagem de banco de dados denominado MER – Modelo Entidade-Relacionamento.
Nessa fase, foram detectados os problemas ainda existentes relativos à semântica,
melhorando-se assim, o dicionário de dados anteriormente descritos.
3
2.2. CRIAÇÃO DO DIAGRAMA LÓGICO COM O DBDESIGN (Exemplo)
Inicialmente, foram integrados os sistemas de produção e manutenção
propostos, tomando-se o cuidado para eliminar as redundâncias e otimizando-se as
entidades e seus atributos. Algumas entidades foram fundidas, outras, eliminadas, a
partir de discussões a respeito dos modelos e suas funcionalidades.
Posteriormente, foi integrado a esse módulo o sistema de compras e gerência
de pessoal, que apresentava algumas características bem diferentes das encontradas
nos outros dois sistemas.
A partir de discussões e sugestões propostas, definiu-se então, um modelo
otimizado para essa integração, considerando-se as funções desejadas para cada
sistema e seus respectivos resultados.
Com essa integração concluída, foi definido um novo dicionário de dados, no
qual foi considerado o sistema como um todo. Foram revistas as restrições de
integridade e as consultas mais freqüentes, tornando-as compatíveis para o sistema
integrado. Esse dicionário de dados, as restrições de integridade, as consultas, alguns
exemplos de consultas e o modelo final obtido são encontrados em anexo no fim desse
relatório.
4
2.3. IMPLEMENTAÇÃO DO PROJETO Exemplo
Com o modelo do banco de dados integrado e concluído, foi feita a migração
deste para o gerenciador de banco de dados xxxx, onde se observou a criação de
todas
as
entidades,
atributos,
chaves
estrangeiras,
chaves
primárias
e
relacionamentos. Essa migração ocorreu mediante a geração de um esquema feito
pelo DBDesign.
Com a intervenção do usuário, através de comandos SQL, foram feitas
operações de banco de dados, tais como:

Inserção;

Alteração;

Consultas e

Deleção dos dados.
5
3. CONCLUSÕES
De acordo com os objetivos propostos para esse projeto, todos os passos foram
concluídos com êxito para a modelagem de um banco de dados.
Entretanto, alguns problemas comuns a sistemas de banco de dados foram
detectados no decorrer das etapas do projeto. Na fase de integração detectamos
diversas entidades sinônimas (com nomes diferentes e mesma função) e homônimas
(com nomes iguais e funções diferentes). Durante a modelagem, precisamos definir
novas entidades que representassem relações visando atender os critérios de
normalização.
Quanto à utilização da ferramenta, não encontramos manuais explicativos
referentes a seu uso, o que dificultou bastante no momento em que precisamos utilizála. Favoravelmente, a partir de discussões e esforços múltiplos conseguimos obter
sucesso em sua utilização, bem como a geração de esquemas e integração com
diversos bancos de dados, tais como SQLServer 7.0, Oracle 7.0, Access e vários outros.
OS ANEXOS ABAIXO SÃO APENAS EXEMPLIFICATIVOS, DEVENDO CADA PROJETO
IMPLEMENTAR OS DE ACORDO COM A NECESSIDADE DO PROJETO, CONFORME
DESCRITO NAS ORIENTAÇÕES DO TRABALHO
6
Anexo A – Dicionário de Dados
Entidade: ESTOQUE
Atributo: Tipo_Esto
Descrição: Tipo do material presente no estoque. Domínio: Ferramenta, Peça, Insumo,
Matéria Prima.
Atributo: Qtde_Esto
Descrição: Quantidade do material presente no estoque. Domínio: 0 a infinito
Atributo: Qtde_Min_Esto
Descrição: Quantidade mínima do material presente no estoque.
Domínio: 1 a infinito
Atributo: Id_Esto
Descrição: Número de identificação do estoque.
Domínio: Ferramenta, Peça, Insumo, Matéria Prima.
Entidade: EXTERNO
Atributo: CGC_ClientExt
Descrição: Número do CGC do cliente externo. Domínio: 000.000.000-00 a 999.999.99999.
Atributo: Nome_ClientExt
Descrição: Nome do Cliente Externo.
Atributo: Endereco_ClientExt
Descrição: Endereço do cliente externo.
Atributo: Fone_ClientExt
Descrição: Telefone do cliente externo.
Entidade: FERRAMENTA
Atributo: Id_ferr
Descrição: Código da Ferramenta.
Domínio: 000.000 a 999.999.
Atributo: Nome_Ferr
Descrição: Nome da Ferramenta.
Atributo: Disponibilidade_Ferr
Descrição: Se há disponível ou não
Atributo: Aquisicao_Ferr
Descrição:Data de aquisição da ferramenta
Atributo: VidaUtil_Ferr
Descrição: até 10 anos
Anexo B – Restrições de Integridade
Sistema de Manutenção
-
Uma peça, insumo ou ferramenta não pode existir sem a existência de
um fornecedor e de um estoque específico.
-
Uma máquina não pode ter mais de quinze anos.
-
Um plano de manutenção não pode existir sem a existência de um
responsável pelo mesmo e de uma máquina na qual o plano será realizado.
-
Uma máquina não pode existir sem um fabricante relacionado a
mesma.
-
Um fornecedor deve necessariamente ter um CGC.
-
Um técnico não pode existir sem uma matrícula e sua função definida.
Sistema de Produção
-
O mesmo operador não pode estar em duas máquinas diferentes no
mesmo tempo
-
Não existe pedido sem produto
-
Uma máquina não deve ficar mais de dois anos sem revisão
-
Não pode haver apenas um fornecedor de um determinado material
-
Não pode existir matéria prima sem fornecedor
-
A quantidade mínima para venda, de um mesmo produto, não pode
ser inferior a 100
-
Não pode haver máquina sem operador
-
Um funcionário só muda de função após treinamento
ii
Anexo C – Consultas mais Freqüentes
Sistema de Manutenção
-
Qual a quantidade em estoque?
-
Quais os tipos de peças no estoque?
-
Qual o tempo médio de vida da peça?
-
Qual máquina a utiliza?
-
Qual a quantidade em estoque?
-
Quais os tipos de insumos no estoque?
-
Qual a quantidade em estoque?
-
Quais os tipos de ferramentas no estoque?
-
Qual a disponibilidade da ferramenta?
-
Qual a sua data de compra?
-
Quando foi realizada a sua última manutenção?
-
Quem é o operador da máquina em cada turno?
-
Qual é o seu plano de manutenção?
-
Qual é o status da máquina?
-
Existe outra máquina equivalente?
-
Qual é o seu horário de trabalho?
-
Qual é o seu tipo de treinamento?
-
Qual a sua função?
-
É responsável por quais planos de manutenção?
-
Qual é o plano?
-
É o plano de qual máquina?
-
Previsão da realização?
-
Qual o tempo de realização estimado?
-
Qual a peridiocidade do plano?
-
Qual o tipo de plano?
-
Qual o material necessário (peças, ferramentas e/ou insumos)?
-
Qual o material fornecido (peças, ferramentas e/ou insumos)?
-
Qual a disponibilidade do material?
-
Como entrar em contato?
-
Qual o preço do material?
iii
Anexo D – Modelo Implementado no (Erwin/DBDesign ou qualquer outra ferramenta
que queiram)
iv
Anexo E – Script SQL
CREATE TABLE al_tur (
at_id integer NOT NULL,
tur_id integer NOT NULL,
al_id bigint NOT NULL
);
ALTER TABLE public.al_tur OWNER TO postgres;
--- Name: aluno; Type: TABLE; Schema: public; Owner: postgres; Tablespace:
-CREATE TABLE aluno (
al_id integer NOT NULL,
al_nome character varying(200),
al_matr character varying(15),
al_sexo character(1),
al_nacionalidade character varying(50),
al_naturalidade character varying(50),
al_dt_nascimento date,
al_pai character varying(150),
al_mae character varying(150),
al_pne_descricao character varying(150),
al_sangue character(3),
ec_id smallint,
esc_id smallint,
end_id smallint,
ativo_id smallint,
al_cpf character(11),
al_rg character varying(20),
al_funcional character varying(30),
al_classe character(25),
al_fone character(10),
al_celular character(10),
del_id integer,
car_id smallint,
al_pne character(4),
al_email character varying(100),
al_naturalidade_uf character(2),
sa_id integer,
al_lot_por_direito integer
);
ALTER TABLE public.aluno OWNER TO postgres;
--- Name: turma; Type: TABLE; Schema: public; Owner: postgres; Tablespace:
-CREATE TABLE turma (
tur_id integer NOT NULL,
tur_nome character varying(200),
tur_qtd_alunos integer,
cur_id smallint,
ativo_id smallint,
tur_dt_ini date,
v
);
turno_id smallint,
tur_dt_fim date,
tur_local character varying(100)
ALTER TABLE public.turma OWNER TO postgres;
--- Name: alunos_turma; Type: VIEW; Schema: public; Owner: postgres
-CREATE VIEW alunos_turma AS
SELECT a.al_id, a.al_nome, t.tur_id, a.ativo_id FROM ((turma t JOIN al_tur ta ON ((ta.tur_id =
t.tur_id))) JOIN aluno a ON ((ta.al_id = a.al_id)));
ALTER TABLE public.alunos_turma OWNER TO postgres;
--- Name: area_conhecimento; Type: TABLE; Schema: public; Owner: postgres; Tablespace:
-CREATE TABLE area_conhecimento (
ac_id integer NOT NULL,
ac_descricao character varying(200)
);
ALTER TABLE public.area_conhecimento OWNER TO postgres;
--- Name: ativo; Type: TABLE; Schema: public; Owner: postgres; Tablespace:
-CREATE TABLE ativo (
ativo_id integer NOT NULL,
ativo_status character(4) NOT NULL
);
vi