Banco de Dados Pt 2

FUNDAÇÃO UNIVERSIDADE FEDERAL DA GRANDE DOURADOS Disciplina BANCO DE DADOS I Professor Vanderson Hafemann Fragal Trabalho 2 parte 6 Entrega via classroom arquivo PDF Data de entrega 11062025 1 Escrever um relatório com a Identificação da equipe b O tema do projeto de banco de dados c Os requisitos textuais do projeto d Parte 1 O modelo EntidadeRelacionamento ER desenvolvido no trabalho 1 na parte 1 print da tela e Parte 2 O modelo relacional print da tela mapeado a partir do ER do item b f Parte 3 Um print da tela para cada tabela com a base de dados já gerada a partir do modelo relacional e preenchida com pelo menos 10 tuplas para cada tabela g Parte 4 Um print da tela com uma junção de tabelas para correlacionar informações Ex informações dos funcionários Nome com o nome das empresasdepartamentos que eles trabalham h Parte 5 Adicionar ao projeto uma visão um gatilho e uma funçãoprocedimento para atender uma situação Cada projeto precisa identificar sua necessidade i Novo Identificar as dependências funcionais das relações e criar um diagrama ilustrando elas e conferir se o projeto está pelo menos na 3FN se não estiver corrigir para que fique Universidade Federal da Grande Dourados Engenharia da computação Mateus Borges Lemos Dami TRABALHO I BANCO DE DADOS Gestão de dispensação em farmácia DOURADOS 2025 SUMÁRIO 1 INTRODUÇÃO3 2 DESENVOLVIMENTO4 21 Temática do Projeto4 22 Modelo Entidade Relacionamento MER5 23 Diagrama Entidade Relacionamento DER6 24 Scripts SQL7 3 RESULTADOS14 31 Consultas14 32 Dependência Funcional17 1 INTRODUÇÃO Um sistema de gerenciamento de banco de dados SGBD é um software que incorpora funções de definição recuperação e alteração de dados de um banco de dados Um banco de dados por sua vez se trata de um conjunto de dados integrados que tem como objetivo atender a uma comunidade de usuários HEUSER 2004 Assim geralmente por uma interface amigável e clicável é possível realizar a administração de um banco de dados por um SGBD Um modelo de banco de dados é uma descrição formal da estrutura de um banco de dados apresentando que tipo de informações sobre determinado sistema serão apresentadas no banco de dados HEUSER 2004 Uma entidade para um banco de dados corresponde a um objeto do mundo real ELMASRI NAVATHE 2005 como por exemplo um cliente ou um produto Na modelagem estas entidades são representadas como tabelas ou retângulos Estas entidades possuem informações chamadas na modelagem de dados como atributos Um atributo corresponde a uma propriedade que ajude a descrever uma entidade ELMASRI NAVATHE 2005 como por exemplo o nome de um cliente Já um relacionamento para a modelagem de dados é o conjunto de associações entre entidades e cada relacionamento tem uma cardinalidade mínima e máxima que se trata do número de ocorrências de entidade associadas a uma ocorrência da entidade oposta HEUSER 2004 O Workbench MySQL é um software para modelagem de banco de dados sendo o tipo relacional o mais utilizado A Oracle é a empresa proprietária e disponibiliza a ferramenta gratuitamente para fins de estudos pesquisas e uso particular 2 DESENVOLVIMENTO 21 Temática do Projeto Em uma farmácia municipal diariamente são dispensados medicamentos a pacientes que se consultaram em um posto de saúde ou pronto socorro A fim de facilitar o registro dos dados de dispensação de medicamentos foi proposta a modelagem de dados para um sistema de gestão farmacêutica Para garantir que os medicamentos comprados com dinheiro público estão sendo entregues corretamente para a população é necessário que todo medicamento seja liberado a partir de orientação médica prescrita em uma receita Ao chegar na farmácia municipal o paciente deve portar a receita e se identificar com documento a partir daí será verificado se o mesmo possui cadastro ou esta é a primeira vez em que necessita dos serviços da farmácia Dados como seu CPF nome número do cartão do SUS data de nascimento endereço e sexo devem ser armazenados para fins de identificação Após isso o farmacêutico que a atende deverá identificar os dados da receita e verificar se está em conformidade contendo nome do paciente CRM nome do médico nome do medicamento concentração e quantidade Caso os dados da receita estejam corretos é realizada a dispensação do medicamento e então é registrado a data da entrega nome e documento de quem retirou o medicamento há casos em que um terceiro retire para o paciente portando documento dele e do paciente e os dados do farmacêutico que realizou 22 Modelo Entidade Relacionamento MER Figura 1 Modelo entidade relacionamento proposto 23 Diagrama Entidade Relacionamento DER Figura 2 Diagrama entidade relacionamento proposto 24 Scripts SQL Figura 3 Criação da base de dados e seleção dela para uso Figura 4 Criação da tabela endereço Figura 5 Criação da tabela médico Figura 6 Criação da tabela paciente Figura 7 Criação da tabela medicamento Figura 8 Criação da tabela farmacêutico Figura 9 Criação da tabela receita Figura 10 Criação da tabela de dispensação Figura 11 Criação da tabela receptor Figura 12 Criação da tabela Lote Figura 13 Inserção de dados na tabela Endereço Figura 14 Inserção de dados na tabela Paciente Figura 15 Inserção de dados na tabela Medico Figura 16 Inserção de dados na tabela Medicamento Figura 17 Inserção de dados na tabela Receita Figura 18 Inserção de dados na tabela Farmaceutico Figura 19 Inserção de dados na tabela Dispensação Figura 20 Inserção de dados na tabela receptor Figura 21 Inserção de dados na tabela Lote 3 RESULTADOS 31 Consultas Figura 22 Consulta e resposta de paciente farmacêutico e data da dispensação de Losartana Figura 23 Consulta e resposta de quantas dispensações foram feitas por cada farmacêutico Figura 24 View de dados de dispensação Figura 25 Trigger para alertar e impedir registro de paciente duplicado Figura 26 Criação da Stored Procedure que retorna a quantidade de dispensação para um paciente Figura 27 Chamada e resultado da stored procedure passando o cpf de um paciente 32 Dependência Funcional Figura 28 Diagrama de Dependência Funcional do projeto normalizado Uma forma normal é uma regra a ser atendida para otimizar a construção da tabela Uma tabela está na 1FN quando ela não contém tabelas aninhadas Assim os valores dos atributos se tornam atômicos e não se repetem diversas vezes Um exemplo disso seria no registro do endereço dentro da tabela paciente sendo elas tabelas aninhadas Para uma família de 5 pessoas em que as 5 procurassem a farmácia para retirada de medicamento seriam 5 registros de pacientes com seus atributos de endereço repetidos Neste caso é possível ter uma tabela de endereço e associar as 5 pessoas a um único registro de endereço Analisando as tabelas criadas foi observado que somente a tabela Medicamento não atende a primeira forma normal Isso porque um mesmo medicamento pode ter diversos lotes e validades gerando duplicidade de registros de um medicamento com mesmo nome Neste caso realizamos a criação da tabela Lote contendo o código do lote a validade e o medicamento associado A tabela Receita também estaria fora da 1FN mas para este trabalho nós consideramos que uma receita pode dispensar apenas um medicamento Se não fosse o caso teríamos que criar uma tabela adicional para relacionar o medicamento com sua quantidade e dosagem Já para uma tabela encontrarse na segunda forma normal 2FN além de estar na primeira forma normal cada coluna não chave deve depender da chave primária por completo Neste projeto foi verificado que as tabelas estão na 1FN e que possuem apenas uma coluna como chave primária então elas não contêm dependências parciais visto que nestas tabelas será impossível uma coluna depender de parte da chave primária se ela é única e não possui partes Uma tabela encontrase na 3FN quando além de estar na 2FN toda coluna não chave depende diretamente de chave primária Neste quesito analisando as tabelas foi possível identificar que a tabela Dispensação possuía atributos que não dependia diretamente da chave primária no caso receptor e seu documento Assim a opção escolhida foi criar uma tabela para armazenar o nome e documento do receptor do medicamento e acrescentar o atributo Parentesco para relacionar o receptor ao paciente Nos casos em que o próprio paciente consegue retirar seu medicamento este caso estará vazio então foi colocado como opcional Por fim observamos que a tabela Prontuário guardava registros que já eram existentes nas demais tabelas não tendo atributos diferentes do que já era cadastrado então foi optado por remover esta tabela Assim foi possível afirmar que o modelo de dados está consistente e na 3FN e os artefatos do projeto como o DER foram atualizados