Arquivos de Categoria: FN

Banco de Dados I – Aula 10E

Crie no Microsoft Access para cada exercício um banco de dados dos exercícios resolvidos

Formas Normais – Formulário de manutenção técnica 

1FN (ITENS DE REPETICAO, OU MULTIVALORADOS TRANSFORMAR EM OUTRA TABELA)

EMPRESA (COD_EMP, RAZAO, ENDERECO, CIDADE, UF, CEP, FONE)

FUNCIONARIO (COD_FUN, NOME, …)

SITUACAO_SERV (TIPO)

FUNCIONARIO_CLI (RG_FUN_CLI, NOME_FUN_CLI, COD_EMP)

OBS (FUNCIONARIO_CLI. COD_EMP à CLIENTE.COD_EMP)

ACAO_SERV (TIPO, RG_FUN_CLI)

OBS (ACAO_SERV.TIPO à SITUACAO_SERV.TIPO)

OBS (ACAO_SERV.RG_FUN_CLI à FUNCIONARIO_CLI.RG_FUN_CLI)

CLIENTE (COD_EMP_CLI, RAZAO, ENDERECO, BAIRRO, COMPLEMENTO, CIDADE, UF, CEP)

TELEFONE_CLI (COD_EMP_CLI, TELEFONE)

OBS (TELEFONE_CLI.COD_EMP_CLI à CLIENTE.COD_EMP_CLI)

SOLUCAO (COD_SOL, DESC_SOL)

SERVICO (COD_SERV, DESC_SERV)

ATENDIMENTO (NR_ORDEM, DATA_ABERTURA, HORA_ABERTURA, DATA_PREVISTA, HORA_PREVISTA, DATA_SOL, HORA_SOL, COD_EMP_CLI, COD_EMP, COD_FUN)

OBS (ATENDIMENTO.COD_EMP_CLI à CLIENTE.COD_EMP_CLI)

OBS (ATENDIMENTO.COD_EMP à EMPRESA.COD_EMP)

OBS (ATENDIMENTO.COD_FUN à FUNCIONARIO.COD_FUN)

SOL_PRESTADA (NR_ORDEM, COD_SOL)

OBS (SOL_PRESTADA.NR_ORDEM à ATENDIMENTO.NR_ORDEM)

OBS (SOL_PRESTADA.COD_SOL à SOLUCAO.COD_SOL)

SERV_PRESTADO (NR_ORDEM, COD_SERV)

OBS (SERV_PRESTADO.NR_ORDEM à ATENDIMENTO.NR_ORDEM)

OBS (SERV_PRESTADO.COD_SERV à SERVICO.COD_SERV)

 

Anúncios

Banco de Dados I – Aula 10D

Crie no Microsoft Access para cada exercício um banco de dados dos exercícios resolvidos

 

Formas Normais – Pedido de Compras 

PEDIDO (NR_PEDIDO, DATA, DEPTO_ORIGEM, FUNC_SOLICITANTE, DEPTO_DESTINO, FUNC_RESPONSAVEL, TOTAL_QTD)

 ITEM_PEDIDO (NR_PEDIDO, ITEM, MATERIAL, QUANTIDADE)

 

2NF (DEPENDENCIA PARCIAL DOS CAMPOS NÃO CHAVE, TRANSFORMAR EM OUTRA TABELA)

PEDIDO (NR_PEDIDO, DATA, DEPTO_ORIGEM, FUNC_SOLICITANTE, DEPTO_DESTINO, FUNC_RESPONSAVEL, TOTAL_QTD)

ITEM_PEDIDO (NR_PEDIDO, ITEM, MATERIAL, QUANTIDADE)

OBS: ITEM_PEDIDO.COD_MATERIAL à MATERIAL.COD_MATERIAL)

 

3FN (ANALISAR OS CAMPOS NÃO CHAVES SE SÃO DEPENDENTES DE OUTROS CAMPOS NÃO CHAVE. CASO SIM, TRANSFORMAR EM OUTRA TABELA)

PEDIDO (NR_PEDIDO, DATA, COD_DEPTO_ORIGEM, COD_FUNC_SOL, COD_DEPTO_DESTINO, COD_FUNC_RESP)

OBS: PEDIDO.COD_DEPTO_ORIGEM à DEPARTAMENTO.COD_DEPTO)

OBS: PEDIDO.COD_FUNC_SOL à FUNCIONARIO.COD_FUNC)

OBS: PEDIDO.COD_DEPTO_DESTINO à DEPARTAMENTO.COD_DEPTO)

OBS: PEDIDO.COD_FUNC_RESP à FUNCIONARIO.COD_FUNC)

DEPARTAMENTO (COD_DEPTO, DEPARTAMENTO)

 FUNCIONARIO (COD_FUNC, FUNCIONARIO)

 ITEM_PEDIDO (NR_PEDIDO, ITEM, COD_MATERIAL, QUANTIDADE)

OBS: ITEM_PEDIDO.COD_MATERIAL à MATERIAL.COD_MATERIAL)

 MATERIAL (COD_MATERIAL, MATERIAL)

Video

Banco de Dados I – Aula 10C

Crie no Microsoft Access para cada exercício um banco de dados dos exercícios resolvidos

Estudo de Caso 2 – Gerência Acadêmica de uma Universidade 

PROFESSOR (COD_PROF, NOME, INSCRICAO_GA, COD_DEPTO)

OBS: PROFESSOR.COD_DEPTO à DEPARTAMENTO.COD_DEPTO

PROFESSOR_HABILITADO (COD_PROF, CFE)

DEPARTAMENTO (COD_DEPTO, NOME_DEPTO)

CURSO (COD_CURSO, NOME, NR_TOTAL_HORAS, COD_DEPTO)

OBS (CURSO.COD_DEPTO à DEPARTAMENTO.COD_DEPTO)

DISCIPLINA (COD_DISC, DESCRICAO, DESC_CURRICULAR, PRE_REQUISITO, COD_DEPTO, COD_PROF)

OBS (PRE_REQUISITO à COD_DISC)

OBS (DISCIPLINA.COD_DEPTO à DEPARTAMENTO.COD_DEPTO)

OBS (DISCIPLINA.COD_PROF à PROFESSOR_HABILITADO.COD_PROF)

DISCIPLINA_OBRIGATORIA (COD_DISC, HORA_OBRIGATORIA)

COMPOR (COD_CURSO, COD_DISC, TIPO_DISCIPLINA)

ALUNO (NR_MATRICULA, TIPO_ADMISSAO, NOME, ENDERECO, COD_CURSO)

OBS (ALUNO.COD_CURSO à CURSO.COD_CURSO)

HISTORICO (NR_MATRICULA, COD_DISC, DATA_DISC_CURSADA, NOTA)

OBS (HISTORICO.NR_MATRICULA à ALUNO.NR_MATRICULA)

OBS (HISTORICO.COD_DISC à DISCIPLINA.COD_DISC)

Video

Banco de Dados I – Aula 10A

PROJETANDO BANCO DE DADOS

  • Segundo OLIVEIRA, (2002, p.21), antes de utilizarmos os comandos SQL, vamos identificar a forma de planejar a criação do banco de dados. Esse planejamento é extremamente importante para a estabilidade de todo o sistema. Estudos indicam que quanto maior o tempo despendido no projeto do banco de dados, menor será o tempo despendido na manutenção do modelo.
  • OLIVEIRA (2002, p.21) explica ainda que podemos comparar a criação de um sistema com a construção de um edifício. O projeto de banco de dado está para o sistema da mesma forma que a estrutura do prédio está para o edifício. Se não for dada a devida atenção ao desenho do banco de dados, pode-se comprometer todo o desenvolvimento do sistema.
  • É como construir um edifício utilizando uma base inadequada: um dia o edifício cairá. De outra forma, quanto maior for o tempo dedicado ao estudo das necessidades de informação do sistema em desenvolvimento, maior será o tempo economizado no desenvolvimento do sistema.
  • O sistema terá melhor qualidade, e será mais fácil, no futuro, implementar novas rotinas, procedimentos e agregar novas informações necessárias.
  • O processo de análise dos dados pressupõe três fases distintas e integradas, como apresenta a figura a seguir

ScreenHunter_249 Oct. 16 19.54

  • Segundo o autor e colunista Ricardo Rezende, da revista especializada em desenvolvimento da Devmedia, o sistema de banco de dados deve garantir uma visão totalmente abstrata do banco de dados para o usuário.
  • Para o usuário do banco de dados pouco importa qual unidade de armazenamento está sendo usada para guardar seus dados, contanto que os mesmos estejam disponíveis no momento necessário.

 

  • Esta abstração se dá em três níveis–Nível de visão do usuário: as partes do banco de dados que o usuário tem acesso de acordo com a necessidade individual de cada usuário ou grupo de usuários;–Nível conceitual: define quais os dados que estão armazenados e qual o relacionamento entre eles;–Nível físico: é o nível mais baixo de abstração, em que define efetivamente de que maneira os dados estão armazenados

ScreenHunter_250 Oct. 16 19.59

  • Todo bom sistema de banco de dados deve apresentar um projeto, que visa a organização das informações e utilização de técnicas para que o futuro sistema obtenha boa performance e também facilite infinitamente as manutenções que venham a acontecer.
  • O projeto de banco de dados se dá em duas fases:
    • Modelagem conceitual;
    • Projeto lógico.
  • Estas duas etapas se referem a um sistema de banco de dados ainda não implementado, ou seja, que ainda não exista, um novo projeto. Para os casos em que o banco de dados já exista, mas é um sistema legado, por exemplo, ou um sistema muito antigo sem documentação, o processo de projeto de banco de dados se dará através da utilização de uma técnica chamada de Engenharia Reversa, que será visto em outra oportunidade.

 

Modelo Conceitual

  • É a descrição do BD de maneira independente ao SGBD, ou seja, define quais os dados que aparecerão no BD, mas sem se importar com a implementação que se dará ao BD. Desta forma, há uma abstração em nível de SGBD.
  • Uma das técnicas mais utilizadas dentre os profissionais da área é a abordagem entidade-relacionamento (ER), onde o modelo é representado graficamente através do diagrama entidade-relacionamento (DER)

Exemplo 01

ScreenHunter_251 Oct. 16 20.15

O modelo acima, entre outras coisas, nos traz informações sobre Alunos e Turmas. Para cada Aluno, será armazenado seu número de matrícula, seu nome e endereço, enquanto para cada turma, teremos a informação de seu código, a sala utilizada e o período.

Já no modelo abaixo, exemplo de MER contendo assunto referente a locadora.

Exemplo 02

Untitled

Modelo Lógico

  • Descreve o BD no nível do SGBD, ou seja, depende do tipo particular de SGBD que será usado. Não podemos confundir com o Software que será usado. O tipo de SGBD que o modelo lógico trata é se o mesmo é relacional, orientado a objetos, hierárquico, etc.
  • Abordaremos o SGBD relacional, por serem os mais difundidos. Nele, os dados são organizados em tabelas

Untitled2

  • O modelo lógico do BD relacional deve definir quais as tabelas e o nome das colunas que compõem estas tabelas.

 

  • Para o nosso exemplo, poderíamos definir nosso modelo lógico conforme o seguinte:

Aluno(mat_aluno, nome, endereco)
Turma (cod_turma, sala, periodo)

  • É importante salientar que os detalhes internos de armazenamento, por exemplo, não são descritos no modelo lógico, pois estas informações fazem parte do modelo físico, que nada mais é que a tradução do modelo lógico para a linguagem do software escolhido para implementar o sistema.
  • GUIMARÃES (2003, p.32) defende que como muitas aplicações de engenharia, o projeto de uma base de dados através da técnica top down ou de refinamento sucessivos é largamente utilizado. Ele começa pela análise dos requisitos dos usuários finais da BD e da visão externa que eles têm sobre os dados.
  • Esta visão e requisitos dependem da aplicação pretendida da BD, variam de um usuário para outro dentro da organização, e refletem suas necessidades para o trabalho diário. Ela é comumente informal e incompleta, em graus que variam com o nível de informatização da aplicação (ou da organização).
  • Os objetivos finais dessa análise são: (i) obter uma visão unificada de todos os dados da aplicação, e (ii) definir os procedimentos funcionais para operar com os dados.
  • É portanto, uma sistemática similar à análise de sistemas convencional.
  • Esta visão unificada dos dados é comumente chamada de modelagem de dados e corresponde a uma abstração do mundo real contendo o conjunto de informações sobre o mesmo que julgamos importante armazenar e manipular.
  • O projeto top down da BD através de modelagem de dados consiste em especificar os dados através de refinamento sucessivos, mapeando os dados definidos num nível mais alto e abstrato para o nível seguinte, menos abstrato e mais detalhado.
  • No nível mais alto a visão e requisitos da BD ainda é informal e é normalmente apresentada sob a forma de documentos textuais. Vamos denominá-la de visão externa de dados.
  • O próximo nível consiste na especificação lógica dos dados num formato de projeto lógico de dados e, dependendo do SGBD escolhido, pode ser de nível suficientemente alto para esconder a maioria dos detalhes de implementação.
  • O último nível é denominado de projeto físico dos dados e corresponde à organização interna do armazenamento dos dados pelo SGBD e à definição de estruturas de dados auxiliares visando uma maior eficiência na recuperação e manipulação dos dados. Dependendo do SGBD uma parte considerável do nível físico fica escondida das aplicações.

ScreenHunter_252 Oct. 16 21.10

A linguagem SQL

  • Segundo GUIMARÃES (2003, p.99), o modelo relacional desenvolvido por [Codd70] definiu as metalinguagens álgebra relacional e cálculo relacional, que implementam os conceitos básicos do modelo. Elas tiveram grande influencia no desenvolvimento subseqüente de propótipos do modelo relacional.
  • SQL (Structured Query Language) é uma linguagem de definição e de manipulação de dados relacionais, desenvolvida nos laboratórios da IBM nos anos 70 e hoje padronizada pelos comitês ISO/ANSI.
  • OLIVEIRA (2002, p.18), complementa que SQL é um conjunto de comandos de manipulação de banco de dados utilizado para criar e manter a estrutura desse banco de dados, além de incluir, excluir, modificar e pesquisar informações nas tabelas dele. A linguagem SQL não é uma linguagem de programação autônoma; poderia ser chamada de “sublinguagem”.
  • A linguagem SQL não é procedural, logo é possível especificar o que deve ser feito, e não como deve ser feito. Dessa forma, um conjunto de linhas (set) será atingido pelo comando e não cada uma das linhas, como é feito no ambiente procedural. Portanto, não é necessário entender o funcionamento interno do banco de dados e como e onde estão armazenados fisicamente os dados.
  • Teoricamente deveria ser possível transferir facilmente os comandos SQL de um banco de dados para outro. Contudo, isso não é possível. Naturalmente, boa parte do trabalho poderá ser aproveitado, mas deve-se fazer adaptações em função do banco de dados que está sendo utilizado.

 

Divisão da linguagem SQL

  • DDL (Data Definition Language): permite a criação dos componentes do banco de dados, como tabelas, indicies, etc. Os principais comandos são: CREATE TABLE, ALTER TABLE, DROP TABLE, CREATE INDEX, ALTER INDEX, DROP INDEX;
  • DML (Data Manipulation Language): permite a manipulação dos dados armazenados no banco de dados. Comandos DML: INSERT, DELETE, UPDATE;
  • DQL (Data Query Language): permite extrair dados do banco de dados. Comando: SELECT
  • DCL (Data Control Language): provê segurança interna do banco de dados: Comandos: CREATE USER, ALTER USER, GRANT, REVOKE, CREATE SCHEMA;
  • Com o advento da SQL-99, a linguagem SQL passou a incorporar comandos procedurais (Begin, IF, funções, procedimentos) que, na prática, já existiam como extensões da linguagem.
  • Essas extensões, até hoje, são específicas de cada banco de dados e, portanto, a Oracle tem a sua própria linguagem procedural que estende a SQL, que é a PL/SQL.
  • A Microsoft incorporou no SQLServer o Transact-SQL com o mesmo objetivo. A idéia é que, num futuro próximo, exista um padrão de programação em todos os banco de dados.

Vídeo

Banco de Dados I – A08F

A empresa “C” é uma empresa que comercializa produtos e assessórios de informática e está automatizando seu sistema de emissão de nota fiscal. Baseado na nota fiscal abaixo, que atualmente é preenchida manualmente. Definir formas normais.

ScreenHunter_374 Oct. 03 16.46

 

learningdatabase.com.br

Tecnologias em Banco de Dados Relacionais, Modelagem de dados dimencionais, tecnologias SQL Servere e Oracle

Aprendendo Programação

Algorítmos, Linguagem C, C++,Pascal, Python, R

WikiDBA

by Virendra Yaduvanshi - Microsoft SQL Server Database Architect | Consultant | Blogger | Specialist | DBA | Speaker

Blog - Fabiano Neves Amorim

SELECT * FROM [Coisas Da Minha Cabeça] WHERE dbo.fn_TempoParaPost() < dbo.fn_TempoLivre()

ROMANO DBA

Administração de Bancos de Dados

Tércio Costa, Oracle Developer, OCE SQL, ACE Associate

Guia de estudos para certificação ORACLE SQL(1Z0-047, 1Z0-051, 1Z0-061 e 1Z0-071) e PL/SQL(1Z0-144, 1Z0-146 e 1Z0-148)

Strate SQL

Data Adventures with an Architect