wiki

FACOM39501 - Aula 14 - 2021-2

DFD


  • Abaixo, a versão 2 do Diagrama de Fluxo de Dados para o LibraryFree:



  • A partir dos depósitos definidos no DFD, podemos gerar um DER:


DER - Diagrama Entidade-Relacionamento


  • Quando pensamos em criar o projeto de um sistema, devemos pensar em como os dados serão armazenados e podemos fazer isso a partir dos depósitos desenhados no DFD.
  • Devemos começar imaginando como será a estrutura desses dados, ou melhor, como eles ficarão armazenados de uma forma consistente e segura,. Sendo assim, próximo passo é definir a representação diagramática do problema.
  • Na evolução da Ciência da Computação, foram feitos estudos e pesquisas e dentre muitas propostas, destacam-se métodos que nos auxiliam a prover uma estrutura concisa, com maior correção e facilidade no tratamento dos dados. Para a representação formal, dentre os modelos propostos, destaca-se o MER - Modelo Entidade-Relacionamento, um padrão de modelagem de objetos, como a UML - Unified Modeling Language.
  • MER, DER - Diagrama Entidade-Relacionamento ou ERA - Entidade-Relacionamento e Atributo foi criado por Peter Chen em 1976 e desde então tem servido aos profissionais que lidam com informação como um método eficiente para representar graficamente a estrutura de armazenamento. Atualmente, ele é bastante usado como primeiro passo na representação da estrutura de um Banco de Dados.
  • Projetos que excluem esse processo podem apresentar erros e falhas, facilmente identificáveis no início, e ao longo do desenvolvimento podem causar inúmeros problemas. Sua estrutura é desenhada de forma clara e simples, possibilitando representar os dados do mundo real como objetos denominado Entidades ou Conunto de Entidades.


  • Modelo Relacional
    • O modelo relacional usa um conjunto de tabelas para representar os dados e as relações entre eles. Cada tabela possui diversas colunas e cada coluna possui um nome único. O modelo relacional é um exemplo de modelo baseado em registros e recebem esse nome porque o banco de dados é estruturado em registros de formato fixo de vários tipos. Cada tabela contém registros de tipo específico. Cada tipo de registro define um número fixo de campos ou atributos. As colunas da tabela correspondem aos atributos do tipo de registro.
    • O modelo de dados relacional é o modelo de dados mais usado e está presente na grande maioria dos bancos de dados do mundo.


  • Tabelas
    • Cada tabela possui várias colunas e cada uma tem um único nome. Cada linha da tabela é denominada de atributo e deve ter um nome começando com uma letra maíúscula e as demais minúsculas. Se for um nome composto, a segunda palavra tem a letra inicial maiúscula e deve ser escrita junto com a primeira. Cada atributo tem um tipo de dado a ser considerado e teremos a seguinte regra:
    • Valor texto: String, S ou VarChar
    • Valor de um caracter: C ou Char
    • Valor numérico inteiro: Int ou I
    • Valor numérico fracionário: Float ou F
    • Valor booleano: B ou Bool
    • Mídia (Vídeo, Imagem, etc): M ou Media


  • Exemplo:


Erro ao criar miniatura: Arquivo não encontrado


  • Considerações:
    • Cada tabela tem um nome que tenta mostrar claramente seu conteúdo
    • Sugere-se não colocar acentuação como no exemplo
    • Quando o atributo for data, pode-se designar o tipo como Date
    • Quando o atributo for data e hora, pode-se designar o tipo como Timestamp
    • Quando for texto, pode-se delimitar o tamanho da palavra
    • Campos obrigatórios podem ter a informação Not Null


  • Chaves:
    • São as chaves para o relacionamento entre entidades, ou tabelas. Assim, haverá, na tabela relacionada, uma referência a uma chave primária (que será, na tabela relacionada, a chave estrangeira).
    • PK - Chave primária, ou primary key:
      • É o conceito mais básico relacionado à organização em um banco de dados. A chave primária é um atributo ou conjunto de atributos que identificam unicamente uma instância em uma entidade, e que não podem receber um valor nulo)
    • FK - Chave estrangeira ou foreign key:
      • Atributo correspondente à chave primária de outra relação, base para a integridade referencial
    • Integridade referencial:
      • PK (Primary Key) representa a chave primária de uma tabela (obrigatória) e FK (Foreign Key) representa uma chave estrangeira, onde o valor do atributo deve ser correspondente a uma chave primária da tabela a qual está referenciando, ou ser nulo, quando não for obrigatório.


DER - LibraryFree


Erro ao criar miniatura: Arquivo não encontrado


Relacionamento



  • Um relacionamento ou associação representa um conjunto de ligações entre entidades que necessitam ser guardadas pelo sistema



  • A associação é caracterizada pela conjunção dos atributos identificadores das entidades envolvidas



  • Cada relacionamento é definida por:
    • Substantivo + relação + Substantivo



Chaves



Chave Primária


  • Atributo usado como identificador do item da entidade, como por exemplo um produto que possui um código de barras que o difere dos demais produtos
  • Esse código de identificação deve ser único
  • Exemplos:
    • matricula
    • placa
    • cpf
    • email




Chave Estrangeira


  • Responsável pelo relacionamento entre duas entidades, como por exemplo, um produto que se relaciona com categoria deve conter como chave estrangeira o código (chave primária) da categoria a qual ele pertence
  • Permite que a partir dela se chegue na chave primária de outra entidade.
  • Exemplos:
    • cidade na Entidade Pessoa
    • professor na Entidade Disciplina
    • medico na Entidade Consulta
    • banco na Entidade movimento-conta




Cardinalidade


  • No DER podemos completar as associações com a sua cardinalidade.
  • A cardinalidade define os graus de uma associação:





Relacionamento um-para-um (1:1)



  • Indica que uma única ocorrência de uma entidade pode se relacionar com apenas uma única ocorrência de outra entidade.



  • Este tipo de relacionamento é raro (no mundo cotidiano)



  • Exemplo: MARIDO (1) possui (1) ESPOSA







  • Exemplos de Maridos e suas respectivas Esposas







  • Uma forma interessante de armazenar:




  • Cada linha de uma tabela se relaciona facilmente com a linha de outra





Relacionamento um-para-muitos (1:N ou 1:M)



  • Indica que uma ocorrência de uma entidade pode se relacionar com muitas ocorrências de outra entidade


  • No entanto, a recíproca não é verdadeira


  • Este tipo de relacionamento é o mais encontrado








  • Uma situação comum: Um pai tem vários filhos







Relacionamento muitos-para-muitos (N:M)



  • Indica que várias ocorrências de uma entidade podem se relacionar com muitas ocorrências de outra entidade



  • Geralmente, um relacionamento desse tipo pode ser convertido e simplificado pela criação de uma entidade intermediária (do tipo associativa) e de dois relacionamentos do tipo 1:N (um-para-muitos)



  • Exemplo:
    • Sistema de compras: Um cliente pode comprar vários produtos, e um produto pode ser comprado por vários clientes
    • Nesse caso, existe a necessidade da implementação de uma entidade fraca entre as duas entidades



  • Essa entidade é chamada de entidade fraca pois sua chave primária é formada por duas chaves estrangeiras



  • Nesse caso, as chaves estrangeiras poderão se repetir, mas o conjunto delas duas nunca irá se repetir, formando a chave primária








  • Outra situação comum: Armazenar informações sobre professores e suas disciplinas.
  • Temos que levar em consideração duas premissas:
    • Um professor pode ministrar mais de uma disciplina
    • Uma disciplina pode ter mais de um professor







  • Essas condições forçam a ter uma segunda tabela para manter os relacionamentos acima.






Exercícios



  • Descrever cada Depósito de Dados com os principais atributos envolvidos e escolher atributo chave para cada conjunto de entidades abaixo:
  1. Funcionário = {Nome + Endereço + Salário + Data-ingresso}
  2. Cliente = {Nro-CPF + Nome + Endereço + Data-Nasc}
  3. Aluno = {Matrícula + Nome + Sexo + Data-nasc.}
  4. Dependente-Funcionário = {Matrícula-Func + Nome-dep + Data-nasc }
  5. Benefícios = {Matrícula-Func + CodBeneficio + Data-benef}
  6. Notas = {Matrícula + Disciplina + Sem + Notas}
  7. Pedido = {NroPedido + Cliente + DataPed + Produto}
  8. Conta = {nro-conta + saldo + juro + período}


Respostas - DER LibraryFree


A. Este DER precisa de tabelas adicionais? Quais?
  1. Poderia ter tabela ou campo chave dentro do usuário, a instituição de ensino se tiver vínculo
  2. Ao meu ver, o DER está bem completo mas para satisfazer algumas demandas de separação de dados dentro das tabelas. Recomendaria uma tabela nova de endereço que poderá ter ligação tanto com a transportadora quanto para o próprio usuário em seu cadastro.
  3. Eu adicionaria uma tabela de updateLog
  4. Acervo Especial (ex. multimidia), Acessibilidade ( tem alguma Deficiencia), Comunicação (ex. Biblioteca Fechada)
  5. Sim, precisa. Podemos colocar a tabela de ADMIN.
  6. Prateleira
  7. Sim, precisa do quadro de fornecedores, para quando for necessário repor ou adicionar novos livros à biblioteca.
  8. Tabela que guarda requisições e sugestões de novos livros.
  9. Sugiro adicionar a tabela funcionários para melhor controle do processo
  10. Renovação de livro
  11. Sim precisa, funcionários (para registrar as pessoas que ali trabalham, entre outras informações). Além disso, empréstimos e devoluções poderia ser uma única tabela, que conversa de N para N com Livros, já que cada livro tem mais de um exemplar.
  12. Poderia tem uma tabela pra incluir livros não encontrados na biblioteca.
  13. Pode-se criar a tabela lingua vindo dos livros, assim como foi feito com assunto.
  14. "Sim. Ao começar pela tabela Livraria, que vem nos acompanhando desde o nosso DFD, uma das tabelas principais. Que vai ter conexão, relação com outras tabelas, como usuário, livro ... Colocaria mais uma tabela de gênero de Livros, ex: Romance, Comédia... E faria relações dela com livros, assuntos e autores, teria campos como codgenero, generoprincipal e genero secundário."
  15. "Eu colocaria um campo de consulta, onde o usuário poderia verificar os livros que ele pegou emprestado, poder ver quando vai vencer o empréstimo, consultar o histórico etc. Também poderia ser colocado algo de local onde o livro esta tipo, bloco ou prateleira"
  16. Tabela Caminhão com placa, modelo, capacidade.


B. Alguma tabela precisa ser modificada no seu campo chave? Qual? Por quê?
  1. Toda tabela necessita ter sua chave primaria, em minha opinião a tabela de usuário deveria ser alterada para abrir um novo campo dentro dela o CodUsuário, para identificação única dentro do próprio sistema sem ter que pegar um dado pessoal igual cpf.
  2. Tabela usuário poderia ser modificado para ser email. Tabela autores pode ser modificada para PK ser email ou cpf. Tabela livros pode ser modificada para que a PK seja o ISBN do livro facilitando encontra-lo no banco de dados.
  3. A tabela assunto deveria ter uma chave exclusiva (um campo) na tabela livros e ser ligado como chave.
  4. Livro - incluir campo chave : Genero, restante ok
  5. Sim, na tabela devolucoes o CodLivro também é código chave.
  6. "Reservas não precisa ter DataReserva, CodUsuario e CodLivro como campo chave. Uma reserva pode ser identificada pelo seu código correspondente (CodReserva que deve ser acrescentado). Em usuarios, trocar o CPF como campo chave para CodUsuario, pois o que identifica o usuario no restante das tabelas é o código dele, não o seu CPF, facilitando a identificação e construção de relacionamentos. Em PalavrasChave, Assunto e Autores, CodLivro não entra como campo chave, mas sim como FK durante a construção do relacionamento."
  7. "deve ser gerado um campo codigo usuario, ja que outras tabelas identificam o usuario pelo codigo e não pelo cpf. o campo CPF deve mudar para string, pois o cpf pode ter zeros a esquerda e o campo deve receber um tratamento pra que digitações diferentes sejam validas. o campo DataReserva da tabela reserva não deve ser usado como chave primaria. o campo codTransportadora na tabela remessa deve ser not null"
  8. Sim, na reserva, para CodReserva, o CodLivro deve ser complementar, pois o CodLivro é o campo chave da tabela Livros.
  9. Tabela empréstimos: codUsuario e CodLivro tbm deveriam ser chaves principais e Tabela devoluções: codlivro e codUsuario também deveriam ser chaves principais.
  10. Na tabela usuário seria melhor criarmos um "CodUsuario" para se tornar mais fácil e mais "barato" o relacionamento do banco. Trabalhando com um id próprio.
  11. Na tabela empréstimo poderia mudar a chave pra cod. do livro
  12. Eu adicionaria um cadastro para os usuários como chave primaria que seria relacionado apenas com o nome de cada usuário pois não são todas as pessoas que possuem um CPF e isso poderia causar alguma dificuldade em alguns casos específicos porem existentes
  13. "Sobre alterações no campo chave, as seguintes tabelas Emprestimos, Devoluções, Transportadoras, Remessas e Editoras, eu mudaria a chave primária, campo chave, para Str, para deixar padrão, assim como as outras tabelas, pois um código pode ser formado tanto de números quanto de letras. Fora isso, a única coisa que consigo ver é a implementação, que não é necessária mas pode ser feita, na tabela usuários, colocar codusuario para substituir o campo chave CPF."
  14. "DataReserva, pois podem acontecer várias reservas no mesmo dia, logo não pode ser atribuída como chave. A chave primária da tabela Usuário deve ser CodUsuário pois está assim como chave estrangeira nas outras tabelas e o CPF já é um atributo. A chave estrangeira CodTransportadora na tabela Remessas deve ser NotNull"
  15. "Tabela Emprestimo - chave composta: CodEmprestimo - CodLivro - CodUsuario. Tabela Devoluções - chave composta: CodDevolucao - CodLivro - CodUsuario. Tabela Livros - chave composta: CodLivro - CodEditora - CodAutor. A tabela Autores pode ser uma só"
  16. A tabela reserva poderia ter o campo codReserva assim como as tabelas Empréstimos e Devoluções possuem.
  17. Sim, algumas tabelas poderiam colocar Str na chave primária para ficar padrão. Tais como as tabelas: Emprestimos , devoluções , transportadoras, remessas e editoras
  18. As chaves das tabelas foram bem construídas e acredito que identificadas da forma correta com os nomes que oram atribuídos a cada chave, não existe a necessidade de modificar a chave de nenhuma delas, apenas mudar o tipo de alguns campos como será explicado na última questão.


C. Alguma tabela precisa ter campos adicionais? Qual tabela? Quais campos?
  1. Usuario poderia ter a instituição de ensino, se tivesse foco de estudo. Assunto poderia ter o ano de edição
  2. Por mim na tabela de usuário, adicionando o id ou código primário como um novo campo identificador único para o mesmo.
  3. Empréstimo deveria ter o campo DATA_FIM. Devolução deve ter o campo data_marcada
  4. A tabela Livros deveria ter uma chave e campo exclusiva para palavraschave, assunto e autores.
  5. 1 - Deposito Usuários - porque tem 02 CPF? não esta em duplicidade. 2- Deposito Usuário - Acessibilidade ( tem alguma deficiencia ex.: Cego) . 3 - Deposito Usuário - Deveria ter um CodUsuario - Int. 4 - Deposito Reserva - Ter CodReserva - Int. 5 - Deposito Livros - Autor - Int. 6 - Deposito Palavra Chave - CodAutor. 7 - Deposito Reserva - Cancelamento
  6. Na tabela autores podemos adicionar Edição. Na tabela transportadora podemos adicionar CNPJ.
  7. "- Tabela usuário precisa ter CodUsuario; - Reservas precisa ter CodReservas."
  8. Na tabela livro, seria interessante ter um campo de avaliação, que estaria uma media de avaliação do livro feita por usuários
  9. Tabela usuários, adicionar o número de empréstimo.
  10. Acredito que os atributos já estão descrevendo bem suas entidades.
  11. Tabela empréstimo poderia vir com o codDevolucao para melhorar o controle
  12. Na tabela usuario colocar país, estado
  13. Sim. Tabela transportadora - campo CNPJ. Tabela livro - Numero de exemplares.
  14. Na tabela usuario poderia conter número de matrícula, curso, tempo pretendido do empréstimo.
  15. A tabela Autores, está muito enxuta, eu colocaria, idade, gênero, fazendo uma relação com a tabela que recomendei para ser criada gênero. Na tabela Livros, concordo com a posição do professor em fazer o campo Status.
  16. Um campo de Avaliações na Tabela Livros, uma média de estrelas que o livro ganha. Campo do tipo Float.
  17. Na tabela Emprestimo acho que pode constar o cod da devolução
  18. A tabela livro pode ter o campo AnoDePublicacao.
  19. Sim. Na tabela Livros, concordo com o professor a necessidade do campo status.
  20. Na tabela Editoras pode adicionar o campo DataFundacao, identificando a data em que a editora foi fundada. Na tabela Livros pode adicionar o campo QtdeCapitulos, identificando a quantidade de capítulos que cada livro possui.


D. Algum campo deve mudar o tipo? Para qual?
  1. Telefone eu colocaria string, para poder colocar pontuação
  2. Codigo de usuario, empréstimo e livro, deveria ser todos varchar, usando de exemplo nossa matrícula 11722GIN014
  3. Por mim o campo cpf poderia ser mudado para string, pois o cpf pode apresentar caracteres diferentes do próprio número além de que o int não suporta um tamanho tão grande de número do cpf.
  4. Campo fone em transportadoras deveria ser String. Devoluções, Campo multa poderia ser double que é comumente utilizado para tratar com dinheiro.
  5. Sim. O CodAutor deve ser Int; CodLivro deve ser Int;
  6. Em usuário: - Tabela de usuários possui 2 campos CPF. - Trocar o CPF para str, para se caso o CPF começar com 0, ele ser armazenado também. Em reservas: - cod usuario para str. Em emprestimos: - Cod usuario para str. Em devoluções: - Cod usuario para str". # "cpf para string. cep para string. fone para string. por mim todos os campos da tabela usuários e livros devem ser notnull. não vejo necessidade de ter cep e numero da editora.
  7. Sim, no campo de usuários, o CPF deve ter o formato CHAR, já que se trata de uma identificação e não de um número. O mesmo se aplica ao CodDevolucao, CodTransportadora, CodRemessa e CodEditora.
  8. CPF, Cep e Fone mudado de Int para BigInt
  9. Eu mudaria o sexo para String, visto que há mudanças constantes em algumas denominações sobre o assunto, deixaria o banco mais inclusivo
  10. Contato para int
  11. CPF para VARCHAR (string), torna mais fácil a modelagem do banco, pois seria necessário um bigint. CodLivro e CodAutor para inteiro.
  12. CPF. Creio que o INT não seria ideal pois o cpf não representa uma quantidade (temos o problema do zero a esquerda também), eu trocaria por varchar.
  13. "Além do já descrito na pergunta do campo chave acima. Alteraria os campos descritos como Situação para Boolean, True or False, acompanhando o verbo das tabelas, ex: Emprestimo, se a situação = True , está emprestado. Devolução, se a situação = True, está devolvido. para ficar mais fácil para o administrador ter esse controle, se deixar a opção aberta para ser digitada uma string, cada vez que for inserir dados, pode entrar alguma coisa diferente etc..."
  14. "CPF para String. CEP para String. Telefone para String. Edição para String. Excluir campo Contato da tabela Transportadora"
  15. Campos CodLivro e CodAutor - mudar para int
  16. O campo Contato da tabela Transportadora pode mudar do tipo String para o tipo int, caso estivermos tratando de um número adicional de telefone. Para as Datas de Devolução podemos colocar o tipo DateTime para especificar a hora da devolução.
  17. Uma única alteração possivel que vejo é alterar os campos descritos como situação para Boolean, True or false, de forma que acompanhe as tabelas , exemplo : se reservas = True, significa que está reservado .
  18. Nas tabelas Emprestimos, Remessas, Devolucoes, Transportadoras e Editoras, os campos referentes aos códigos de cada uma dessas tabelas podem ser modificados para os tipos Str, pois existe a possibilidade que os códigos apresentem letras e números, não apenas números como é o estado atual do int.
Disponível em “http://3.143.69.156/wiki/index.php?title=FACOM39501_-_Aula_14_-_2021-2&oldid=84794”