Arquivos de Categoria: Modelo Entidade Relacionamento

Banco de Dados I – Aula 10B

Criando um banco de dados no Microsoft-Access

 

Para ilustrar a criação simples de banco de dados, iremos utilizar os exemplos normalizados:

Primeiramente, crie um banco de dados vazio no Microsoft Access;

Untitled

Dê um nome ao banco de dados:

Untitled2

Como criamos um banco de dados vazio, o MS-Access irá pedir os dados para a nova tabela;

Classificando o tipo de dados

 

Usaremos os tipos básicos de dados que o MS-Access oferece. Os tipos de dados servem para classificarmos os mesmos. Determinado dado tem certa característica(s). Por exemplo: “DQF-2134”, “15/07/2000”, “16”, “Ana Cristina da Silva”, “13.200-015”, “São Paulo”. Podemos observar que os dados possuem caracteres numéricos e alfanuméricos.  Observando os valores dos dados, podemos classificar o seu tipo.

O MS-Access possui alguns outros tipos de dados:

Untitled3

Iremos criar as tabelas abaixo, conforme exercício passado:

ESTOQUE_ITENS(NR_CONTROLE,ITEM, COD_PECA, QUANTIDADE, TIPO_MOVIMENTACAO, COD_SETOR)

PECA(COD_PECA, DESCRICAO_PECA)

SETOR(COD_SETOR, DESC_SETOR)

ESTOQUE(NR_CONTROLE, DATA, COD_FUNC_REP, COD_FUNC_RESP)

FUNCIONARIO(COD_FUNC, NOME_FUNC)

Criando tabelas no MS-ACCESS

Tabelas a serem criadas:

Untitled4

Untitled5

Untitled6

Untitled7

Realize após a construção das tabelas testes de inserção de dados. Perceba que ainda não haverá nada que impeça o usuário colocar um dado que não exista nas tabelas bases.

Relacionamento entre tabelas

Para fazer o relacionamento no ACCESS, vá no menu “Ferramentas de Banco de Dados” / Relações

Untitled8

Selecione todas as tabelas e pressione “Adicionar”

Untitled9

Após a inclusão de todas as tabelas, aparecerá as tabelas “não-relacionadas”, conforme figura abaixo:

Untitled10

Arraste o campo “NR_CONTROLE” da tabela “ESTOQUE” para o campo “NR_CONTROLE” da tabela “ESTOQUE_ITENS”. A seguinte tela aparecerá:

Untitled11

Faça o mesmo processo para os demais itens do banco de dados, deixando igual a figura abaixo:

Untitled12

Teste novamente a inserção de dados;

Vídeo

Anúncios

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 – Aula 08A

ASPÉCTO TEMPORAL

 

Modelo deve refletir o aspecto temporal

  • Certas aplicações exigem que o BD guarde o histórico de alterações de informações. Por exemplo, um BD de uma seguradora.
  • Pode ser necessário conhecer não só o segurado atual de uma apólice, mas também os do passado.
  • O modelo de um BD que armazena somente os valores atuais de uma informação é diferente do modelo do BD que armazena o histórico da informação. Portanto, é necessário considerar o aspecto temporal na modelagem de dados.
  • Não há regras gerais de como proceder neste caso, mas é possível identificar alguns padrões que se repetem frequentemente na prática.

 

Atributos cujos valores modificam ao longo do tempo

  • Alguns atributos de uma entidade, normalmente aqueles que não são identificadores da entidade, podem ter seus valores alterados ao longo do tempo (por exemplo, o endereço de um cliente pode ser modificado).
  • Algumas vezes, por necessidades futuras de informações, ou até mesmo por questões legais, o banco de dados deve manter um registro histórico das informações.
  • Um exemplo é o valor do salário do empregado.
  • Num sistema de pagamento, não interessa saber apenas o estado atual, mas também o salário durante os últimos meses, por exemplo, para emitir uma declaração anual de rendimentos de cada empregado.
  • Assim, o salário não pode ser modelado como atributo, mas sim como uma entidade.
  • Exemplo

ScreenHunter_229 Sep. 26 20.32

 

ScreenHunter_231 Sep. 26 20.53

 

Relacionamentos que modificam ao longo do tempo

  • Assim como atributos podem ter seus valores modificados ao longo do tempo, também relacionamentos podem ser modificados (instâncias dos relacionamentos podem ser modificados, adicionadas/removidas) e também neste caso pode ser requerido que o banco de dados mantenha um registro histórico das alterações.
  • Quando é considerada a história de suas alterações, relacionamentos 1:1 ou 1:n são transformados n:n.

ScreenHunter_232 Sep. 26 21.05

ScreenHunter_233 Sep. 26 21.06

 

Modelando a dimensão temporal de relacionamentos 1:1

  • Para exemplificar, consideramos o relacionamento LOCAÇÃO (a). Este relacionamento possui cardinalidade 1:1, ou seja, cada empregado está alocado a no máximo uma mesa e cada mesa tem ela alocado no máximo um empregado.
  • Este modela está correto, caso deseje-se armazenar no banco de dados apenas a alocação atual de cada mesa. Entretanto, caso deseje-se armazenar também a história das alocações, isto é, que empregados estiveram alocados a que mesas ao longo do tempo, é necessário modificar o modelo para (b).
  • O relacionamento para a ter cardinalidade N:N, já que, ao longo do tempo um empregado pode ter sido alocado a diversas mesas e uma mesa pode ter sido a ela alocados a muitos empregados.
  • Como um mesmo empregado pode ter sido alocado a mesma mesa múltiplas vezes, torna-se necessário um atributo identificador do relacionamento, a fim de distinguir uma alocação de um determinado empregado a uma mesa, das demais alocações deste emprega à mesma mesa. Com isso surge o atributo identificador data.

ScreenHunter_234 Sep. 26 21.07

ScreenHunter_235 Sep. 26 21.08

  • A figura anterior apresenta uma situação semelhante agora considerando um relacionamento de cardinalidade 1:N. Se quisermos considerar a história das lotações de empregados ao longo do tempo, é necessário transformar o relacionamento para a cardinalidade N:N, já que ao longo do tempo um empregado pode ter atuado em diferentes departamentos.
  • Neste caso pode ocorrer também que atributos da entidade EMPREGADO migrem para o relacionamento. No caso do exemplo, isso ocorrer com o atributo nr doc lotação. Este atributo, que, na primeira versão, migra, na nova versão, para o relacionamento, já que na nova versão um empregado pode estar relacionado com múltiplos departamentos.

 

Modelando a dimensão temporal de relacionamentos N:N

  • Na figura seguinte apresenta mais outro exemplo relacionamento temporal, agora um relacionamento de cardinalidade N:N. Modela-se a inscrição de participantes nos cursos oferecidos por uma empresa de treinamento.
  • Na primeira versão, considera-se apenas os cursos nos quais uma pessoa está inscrita em um determinado instante no tempo. Na segunda versão, considera-se todas as inscrições, inclusive as do passado.
  • A modificação de uma versão para a outra consta da transformação do atrubuto data em atributo identificador. Isso ocorre porque, na segunda versão, um participante pode aparecer relacionamento múltiplas vezes a um determinado curso (caso ele tenha se inscrito múltiplas vezes no curso).
  • O atributo para a distinguir uma inscrição de uma pessoa em um curso, das demais inscrições desta pessoa no mesmo curso.

ScreenHunter_236 Sep. 26 21.10

ScreenHunter_237 Sep. 26 21.10

 

Consultas a dados referentes ao passado

  • Muitas vezes, para evitar o crescimento desmedido do banco de dados, informações referentes ao passado são eliminadas.
  • Entretanto, estas informações podem ser necessárias no futuro, por exemplo, por motivos legais, para realização de auditorias ou para tomada de decisões. Portanto, é necessário planejar, desde a modelagem, por quanto tempo as informações ficarão armazenadas no banco de dados.
  • Caso informações antigas fiquem no banco de dados, podem ser necessários atributos para indicar o status da informação, se atual ou antiga.

 

Planejar o arquivamento de informações antigas

  • Para as informações que serão retiradas do banco de dados e armazenadas em arquivos convencionais, é necessário fazer um planejamento de como estas informações serão acessadas no futuro, caso venham a ser necessárias.
  • Uma solução que poderia ser considerada, é a de reincluir as informações no banco de dados, quando elas forem necessárias no futuro. Isso permite que, para buscar as informações passadas, sejam usados os mesmos procedimentos que são usados para acessar as informações atuais.
  • Entretanto, é necessário considerar que as informações em um banco de dados estão normalmente relacionadas a outras. Casos as ocorrências de entidade que se deseja devolver à base de dados estejam relacionadas a outras ocorrências, é necessário que estas estejam presentes.
  • Se elas também tiverem sido excluídas, deverão ser igualmente devolvidas à base de dados. Essa inclusão pode ser propagada em cascata para outras entidades.

 

Planejar informações estatísticas

  • Em alguns casos, informações antigas são necessárias apenas para tomada de decições. Neste caso, muitas vezes deseja-se apenas dados resultantes de cálculos ou estatísticas sobre as informações, como totais, contagens, médias, etc.
  • Assim pode ser conveniente manter o banco de dados estas informações compiladas e eliminar as informações usadas na compilação.

GitHub

Banco de Dados I – Aula 06E

A partir da tabela abaixo, faça a transformação dos dados para o Modelo Relacional (MR)

ScreenHunter_113 Sep. 19 00.20

 

Resposta do exercicio em:

https://github.com/rodrigoksaito/anchieta/tree/master/BancoDados_I/Aula06

 

Banco de Dados I – Aula 06D

Considere o seguinte esquema relacional de Projetos

Empregado (Ident, Nome, Salario, Endereco, Sexo, DataNasc, DepNum, SuperIdent)

Departamento (Num, Nome, IdentGer)

Projeto (Num, Nome, Local, DepNum)

TrabalhaNo (IdentEmp, ProjNum, Horas)

Dependente (Nome, Sexo, DataNasc, Parentesco, IdentEmp)

DepLoc (DepNum, Local)

Desenhe o diagrama Entidade-Relacionamento correspondente, indicando as cardinalidades. Adicione as hipóteses que julgar necessárias.

Exercício adaptado e retirado do Prof. Ricardo da Silva Torres – UNICAMP (arquivo exec04.pdf)

Referêcias

[1] C. A. Heuser. Projeto de Banco de Dados. Editora Sagra Luzzato, Porto Alegre, RS, 2004.

 

Video de correção

Arquivo para download no github

https://github.com/rodrigoksaito/anchieta/tree/master/BancoDados_I/Aula06

 

learningdatabase.com.br

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

Aprendendo Programação

Algorítmos, 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