LabMM4 (T05 - 12/13) - Relações 1:1

474 visualizações

Publicada em

Publicada em: Educação
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
474
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
56
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

LabMM4 (T05 - 12/13) - Relações 1:1

  1. 1. Bases de dados: Propriedades da relação erelações [1:1]Carlos SantosLabMM 4 - NTC - DeCA - UAAula 05, 28-02-2013
  2. 2. Muitos para muitos [M:M] Encomendas Encomendas_has_Produtos ProdutosnrEncomenda DataEncom Encomendas_nrEncomenda Produtos_idProduto idProduto nomeProd 1 2008-­‐01-­‐16 1 2 1 Cadeira 2 2008-­‐02-­‐02 1 3 2 Mesa  de  Sala 3 2008-­‐03-­‐09 2 2 3 Aparador 4 2008-­‐04-­‐12 4 Sofá 3 1 5 2008-­‐05-­‐26 3 2 3 3 5 2 5 3 PROBLEMA: Como podemos adicionar uma “Cadeira” à encomenda 3?
  3. 3. Propriedades de uma relação Clientes idCliente NomeCliente ApelidoCliente MoradaCliente Vendedores Encomendas ContactoCliente Tipo (priv/empr)idVend nrEncomendaNomeVend DataEncomendaApelidoVend DataPagamentoMoradaVendSexoContatoVendDataNascimentoDataEntradaEmpresa Produtos idProduto NomeProd Quantidade DescricaoProd Preco Peso Dimensoes
  4. 4. Muitos para muitos [M:M] + prop. de relação Encomendas Encomendas_has_Produtos ProdutosnrEncomenda DataEncom Encomendas_nrEncomenda Produtos_idProduto quanFdade idProduto nomeProd 1 2008-­‐01-­‐16 1 2 1 1 Cadeira 2 2008-­‐02-­‐02 1 3 3 2 Mesa  de  Sala 3 2008-­‐03-­‐09 2 2 4 3 Aparador 4 2008-­‐04-­‐12 4 Sofá 3 1 5 5 2008-­‐05-­‐26 3 2 1 3 3 2 5 2 5 5 3 4
  5. 5. Quanto custa? Encomendas_has_Produtos ProdutosEncomendas_nrEncomenda Produtos_idProduto quanFdade idProduto nomeProd preco 1 2 1 1 Cadeira €50 1 3 3 2 Mesa  de  Sala €800 2 2 4 3 Aparador €3000 3 1 5 4 Sofá €1200 3 2 1 Encomendas 3 3 2 nrEncomenda DataEncom 5 2 5 1 2008-­‐01-­‐16 5 3 4 2 2008-­‐02-­‐02 3 2008-­‐03-­‐09 4 2008-­‐04-­‐12 5 2008-­‐05-­‐26
  6. 6. Um para um [1:1]Novo cenário: uma empresa tem necessidade de gerir a ocupação degabinetes por administradores, sendo que: • Cada administrador possui apenas um gabinete • Cada gabinete está atribuído apenas a um administrador Administradores Gabinetes idAdmin idGabinete NomeAdmin Localizacao ApelidoAdmin
  7. 7. Um para um [1:1] • Cada administrador possui apenas um gabinete • Cada gabinete está atribuído apenas a um administrador FK que também é PK!1:1 Identifying Relationship ________ • Pode existir um administrador sem um gabinete • PK IdAdministrador pode conter valores que não existem ainda na FK Administradores_idAdministrador • Não pode existir um gabinete sem um administrador • FK idGabinete não pode conter nulos pois também é PKExiste dependência entre os administradores e os gabinetes!
  8. 8. Um para um [1:1] • Cada administrador possui apenas um gabinete • Cada gabinete está atribuído apenas a um administrador FK que também é PK!Problema: O que acontece se existirem gabinetes vazios?
  9. 9. Um para um [1:1]Solução: Criar uma tabela de relação que torne as entidades independentes.Pode existir um administrador sem um gabinete • PK IdAdministrador pode conter valores que não existem ainda na FK Administradores_idAdministradorPode existir um gabinete sem um administrador • PK IdGabinete pode conter valores que não existem ainda na FK Gabinetes_idGabineteA tabela de relação Administradores_has_Gabinetes conterá apenas assituações em que a um administrador foi atribuído um gabinete
  10. 10. Um para um [1:1]Para evitar valores repetidos nas FK que constituem a PK composta databela de relação, as FK são configuradas com o parâmetro UNIQUE Administradores Gabinetes idAdministrador NomeAdmin idGabinete Localizacao 1 João 1 101 2 Maria 2 102 3 Manuel 3 103 Administradores_Gabinetes Administradores_idAdministrador Gabinetes_idGabinete 1 2 2 3
  11. 11. QuestãoComo podemos evitar a criação de nulos numa relação de 1:M? • numa situação: 1 ou muitos • numa situação: 0 ou muitosPor vezes pode não ser admissível implementar relações 1:M sem utilizaruma tabela de relação!
  12. 12. MySQL WorkbenchMais importante que tudo... o MySQL Workbench não é um SGBDR! • É uma aplicação com várias ferramentas que facilitam algumas tarefas inerentes ao desenvolvimento e manutenção de BDs e SGBRs • O MySQL Server é que é um SGBDRFerramentas • Server Administration • Data Modeling • SQL Development
  13. 13. MySQL Workbench: Data modelingDiagrama Enhanced Entity-Relationship (EER) • Modelação da BD: entidades, propriedades e suas relaçõesPhysical Schemata • Schema: conjunto de objetos e regras que estruturam a BD • A ter em atenção: • Verificar se a Collation de todas as tabelas está definida como utf8 - utf8_general_ci (suporte caracteres PT) • Nome do schema deve ser igual ao nome da BD destino • Verificar se o Engine de todas as tabelas está definido como InnoDBExportar o schema da BD • File -> Export -> Forward Engineer SQL CREATE Script… • Gera um ficheiro SQL com o código necessário para a criação da BD
  14. 14. MySQL Workbench: Data modeling: Export Antes de criar, apaga objetos que já existam com o mesmo nome Mostra eventuais mensagens de erro/ alerta durante o processo de criação Permite inserir dados na BD no momento da sua criação
  15. 15. MySQL Workbench: Data modeling: Export O que é? Para que serve?
  16. 16. MySQL Workbench: SQL DevelopmentPara que serve? • Ligação a uma base de dados • Executar SQL Queries • Executar SQL Scripts • Editar dados de tabelas • alternativa: phpMyAdmin

×