Baixe o app para aproveitar ainda mais
Prévia do material em texto
Princípios Fundamentais de Banco de Dados Introdução a Banco de Dados Diretor Executivo DAVID LIRA STEPHEN BARROS Gerente Editorial CRISTIANE SILVEIRA CESAR DE OLIVEIRA Projeto Gráfico TIAGO DA ROCHA Autoria LEANDRO C. CARDOSO AUTORIA Leandro C. Cardoso Olá. Sou formado em Comunicação Social com habilitação em Design Digital e mestrado em Tecnologias da Inteligência e Design Digital pela PUC-SP, com uma experiência de 20 anos em direção de arte e criação na área. Passei por empresas como a Laureate International Universities — FMU | Fiam-Faam, a Universidade Anhembi Morumbi e o Centro Paula Souza (Fatec-Etec), como analista de Desenvolvimento Pedagógico, coordenador de curso técnico de Comunicação Visual no Centro Paula Souza; e revisor técnico e validador para curso EAD para clientes Laureate International Universities, DeVry Brasil, Unef, Faesf, Faculdade Positivo, Uninter, Platos Soluções Educacionais S.A. (Krotonn — Universidade Anhanguera). Além disso, sou autor de mais de 10 livros didáticos e um dos organizadores da Maratona de Criação e Design do curso de Comunicação Visual da Etec Albert Einstein. Sou apaixonado pelo que faço e adoro transmitir minha experiência de vida àqueles que estão iniciando em suas profissões. Por isso fui convidado pela Editora Telesapiens a integrar seu elenco de autores independentes. Estou muito feliz em poder ajudar você nesta fase de muito estudo e trabalho. Conte comigo! ICONOGRÁFICOS Olá. Esses ícones irão aparecer em sua trilha de aprendizagem toda vez que: OBJETIVO: para o início do desenvolvimento de uma nova compe- tência; DEFINIÇÃO: houver necessidade de se apresentar um novo conceito; NOTA: quando forem necessários obser- vações ou comple- mentações para o seu conhecimento; IMPORTANTE: as observações escritas tiveram que ser priorizadas para você; EXPLICANDO MELHOR: algo precisa ser melhor explicado ou detalhado; VOCÊ SABIA? curiosidades e indagações lúdicas sobre o tema em estudo, se forem necessárias; SAIBA MAIS: textos, referências bibliográficas e links para aprofundamen- to do seu conheci- mento; REFLITA: se houver a neces- sidade de chamar a atenção sobre algo a ser refletido ou dis- cutido sobre; ACESSE: se for preciso aces- sar um ou mais sites para fazer download, assistir vídeos, ler textos, ouvir podcast; RESUMINDO: quando for preciso se fazer um resumo acumulativo das últi- mas abordagens; ATIVIDADES: quando alguma atividade de au- toaprendizagem for aplicada; TESTANDO: quando o desen- volvimento de uma competência for concluído e questões forem explicadas; SUMÁRIO Normalização de Dados ........................................................................... 10 As Formas Normais........................................................................................................................ 10 Modelo Entidade-Relacionamento ..................................................... 18 Conceitos e Definições sobre Modelos Entidade-Relacionamento .......... 18 Modelo Lógico de Dados .........................................................................30 A Importância do Modelo Lógico de Dados .............................................................. 30 Classes e Especializações de Dados ..................................................36 Especializações de Dados ....................................................................................................... 36 7 UNIDADE 03 Introdução a Banco de Dados 8 INTRODUÇÃO Você sabia que é importante o conhecimento dos Princípios Fundamentais de Banco de Dados, sendo uma das demandas da área de Banco de Dados, responsável por viabilizar projetos de banco de dados complexos e robustos? Isso mesmo. Para isso, é importante o conhecimento de normalização de dados, as formas normais, .......modelo entidade-relacionamento, modelo lógico de dados, além de compreender a importância do modelo lógico de dados e as classes e especializações de dados. Isso tudo aliada à compreensão de uma linguagem de programação com estrutura de consulta capaz de orquestrar todas as informações. Entendeu? Ao longo desta unidade letiva você vai mergulhar neste universo! Introdução a Banco de Dados 9 OBJETIVOS Olá. Seja muito bem-vindo à Unidade 3 – Modelando dados. Nosso objetivo é auxiliar você no desenvolvimento das seguintes competências profissionais até o término desta etapa de estudos: 1. Normalizar os dados em uma base de informações. 2. Entender os modelos entidade-relacionamento e aplicar as técnicas de modelagem conceitual de dados. 3. Transformar um modelo entidade-relacionamento em um modelo lógico de dados. 4. Lidar com situações em que seja necessário aplicar técnicas mais aprimoradas de modelagem de dados, como especializações e classes de dados. Introdução a Banco de Dados 10 Normalização de Dados OBJETIVO: Ao término deste capítulo, você será capaz de entender como funcionam os aspectos fundamentais de um banco de dados. Isso será fundamental para o exercício de sua profissão. As pessoas que tentaram desenvolver banco de dados sem a devida instrução tiveram problemas ao normalizar dados, entre outras dificuldades. E então? Motivado para desenvolver esta competência? Então, vamos lá. Avante!. As Formas Normais Antes de utilizar a ferramenta propriamente dita, é necessário realizar a modelagem dos dados, para que seja definida uma estrutura adequada e que o banco de dados seja eficiente (ELMASRI; NAVATHE, 2005). Dessa forma, o nosso próximo passo é entender como podemos realizar a modelagem de dados. Concorda com o que foi dito? O que é um modelo de dados? Existem algumas categorias de modelos de dados. Veja a seguir. 1. De implementação ou representativo: são caracterizados por dispor princípios nos quais podem ser entendidos pelos usuários, porém não se distancia da maneira que os dados são armazenados e organizados no computador. 2. Físicos ou de baixo nível: permite um olhar com mais detalhes sobre a maneira que os dados estão realmente armazenados no computador. 3. Conceituais ou de alto nível: São caracterizados como os usuários que entendem os dados. Introdução a Banco de Dados 11 Podemos entender a normalização de dados como um processo a partir do qual algumas regras são aplicadas para reduzir o número de falhas em um projeto de banco de dados. Entre essas falhas, é comum existir problemas como a redundância de dados em diferentes tabelas, assim como dados que não estão diretamente relacionados à sua tabela. A técnica de normalização de dados tem origem no levantamento de informações do mundo real: esse é o primeiro passo quando se deseja informatizar um negócio. Imagine a seguinte situação: você foi contratado para informatizar o setor comercial de uma empresa varejista. O primeiro procedimento que deve ser executado é levantar os formulários de preenchimento dos processos internos. Normalmente, esses formulários informam a respeito do negócio do cliente, pois é base de origem dos dados que serão cadastrados no futuro banco de dados. Figura 1 -‒ As soluções de banco de dados, como das formas normais, têm aplicações práticas, por exemplo, em lojas de varejo Fonte: Freepik. Introdução a Banco de Dados 12 Para solucionar possíveis problemas com o universo de dados dessa empresa, pode-se aplicar o que chamamos de “formas normais”. Existem três delas, mas algumas literaturas defendem a existência de quatro ou cinco formas normais. (KENT, 2011). Podemos afirmar que uma tabela está na primeira forma normal quando não existem tabelas aninhadas dentro dela. Para descobrir isso, basta se fazer a seguinte pergunta para cada um de seus campos: Este campo depende de qual outro campo? Para estar nesta forma normal, todos os campos só podem depender da própria tabela. DEFINIÇÃO: Para entender melhor esta teoria, deve-se imaginaruma tabela, resultante de um formulário de lançamento de vendas de uma empresa de varejo. A tabela “Vendas” dessa empresa poderia ter, por exemplo, a seguinte estrutura de campos de dados: Vendas {Código da Venda, Nome do Cliente, Endereço, CEP, Cidade, Estado, Telefone, Descrição do Produto, Quantidade, Valor Unitário, Valor Total} (DUARTE, 2016). Por armazenar as vendas que a empresa realizou, não pode haver dependência de um campo com outra tabela. E isso é facilmente identificado quando vemos que nessa tabela existem dados como “Endereço” do cliente, que não depende da venda realizada, pois duas vendas poderão ter sido realizadas para um mesmo cliente, e o endereço dele ficaria repetido em várias linhas da tabela, causando uma redundância desnecessária de informações. Introdução a Banco de Dados 13 Figura 2 -‒ Vários dados dos clientes são armazenados nos bancos de dados de uma loja de varejo Fonte: Freepik. O mesmo ocorre com outros dados do cliente, como “CEP”, “Telefone”, “Estado” etc. Nesse caso, a técnica de normalização recomenda extrair todo e qualquer campo que não dependa da tabela “Vendas” e adicioná-los a tabelas específicas. Assim, a normalização dessa tabela fará com que uma nova tabela seja criada: a tabela “Clientes”. Figura 3 -‒ As informações das vendas precisam fazer parte das informações coletadas nos bancos de dados Fonte: Freepik. Introdução a Banco de Dados 14 No lugar de todos esses dados relacionados ao cliente desta venda, apenas o código do cliente permanecerá na tabela “Vendas”, que, como vimos, será a chave estrangeira da tabela “Clientes” dentro da tabela “Vendas”. Veja como ficarão essas tabelas após a aplicação da primeira forma normal: Vendas {Código da Venda, Código do Cliente, Descrição do Produto, Quantidade, Cidade, Estado, Valor Unitário, Valor Total}. Clientes {Código do Cliente, Nome do Cliente, Endereço, CEP, Telefone}. A normalização segue adiante, analisando outras dependências, não só na tabela “Vendas”, como nas outras tabelas que serão geradas a partir de sua normalização. Por exemplo, o que ocorreu com o cliente, ocorre também com os produtos, dados como “Descrição do Produto” e “Valor Unitário” não dependem da venda, mas sim do produto, o que faz surgir uma nova tabela: “Produtos”. Figura 4 -‒ Os dados dos produtos são de extrema importância e devem ser armazenados nos bancos de dados, em uma loja de varejo, por exemplo Fonte: Freepik. Veja a seguir uma esquematização de normalização objetivando os produtos: Vendas {Código da Venda, Código do Cliente, Código do Produto, Quantidade, Cidade, Estado, Valor Total}. Produtos {Código do Produto, Descrição do Produto, Valor Unitário}. Clientes {Código do Cliente, Nome do Cliente, Endereço, CEP, Telefone}. Introdução a Banco de Dados 15 Prosseguindo, vemos que, na tabela “Vendas”, a cidade depende do estado, pois uma cidade só pode pertencer a um estado. Por sua vez, o estado também depende da cidade, pois há cidades que não poderiam estar associadas a ele. No entanto, mais de uma cidade pode pertencer a um mesmo estado. Observamos, portanto, uma dependência entre dois campos não chaves de uma tabela, o que caracteriza uma dependência funcional. Nessa situação, são removidos os dois campos da tabela “Vendas”, deixando apenas uma chave estrangeira denominada “Código da Cidade”, que faz surgir uma nova tabela denominada “Cidades”. Vendas {Código da Venda, Código do Cliente, Código do Produto, Código da Cidade, Quantidade, Valor Total}. Cidades {Código da Cidade, Cidade, Estado}. Produtos {Código do Produto, Descrição do Produto, Valor Unitário}. Clientes {Código do Cliente, Nome do Cliente, Endereço, CEP, Telefone}. Em relação a uma tabela que está na segunda forma normal, é quando não existem dependências parciais entre os campos, isto é, quando, em uma tabela que contém uma chave composta, ou seja, uma sequência de campos-chaves, cada dado depende, simultaneamente, de todas essas chaves. No caso da tabela “Vendas”, veremos que, depois de todas as normalizações, ou seja, quando ela estiver inteiramente dentro da primeira forma normal, restarão várias chaves estrangeiras que comporão a sua própria chave primária. Nesse caso, os campos que não forem chave dessa tabela terão que depende, exclusivamente, de todo o conjunto de chaves. • Vendas {Código da Venda, Código do Cliente, Código do Produto, Quantidade, Valor Total}. • Cidades (Código da Cidade, Cidade, Estado). • Produtos {Código do Produto, Descrição do Produto, Valor Unitário}. • Clientes {Código do Cliente, Nome do Cliente, Endereço, CEP, Código da Cidade, Telefone}. Introdução a Banco de Dados 16 Caso o campo “Quantidade” da tabela “Vendas” seja analisado, veremos que ele depende de parte das chaves dessa tabela, como “Código da Venda”, “Código do Cliente” e “Código do Produto”. Mas o campo “Quantidade” não depende do “Código da Cidade”, quem depende deste é o cliente. Figura 5 -‒ O campo “Quantidade” da tabela só pode estar relacionado a campos específicos, que estão relacionados a quantias ou valores Fonte: Freepik. Temos aqui uma dependência parcial, ou seja, o campo “Quantidade” depende de três das quatro chaves que definem a tabela “Vendas”. Nesse caso, elimina-se o campo “Código da Cidade” da tabela “Vendas”, transferindo-o para a tabela “Clientes”. Por fim, temos a terceira forma normal, que pretende eliminar qualquer possibilidade de dependência transitiva. A pergunta crucial que se deve fazer à tabela para testar se ela já se encontra na terceira forma normal é a seguinte: Todos os campos da tabela dependem única e exclusivamente da chave da própria tabela? Caso não, temos dependências transitivas nessa tabela: esse é o caso do campo “Valor Total”. Este não depende da chave da tabela “Vendas”, mas de uma multiplicação entre dois outros campos: o “Valor Unitário” e a “Quantidade”. Logo, podemos eliminar esse campo de nossa tabela, pois a qualquer momento poderemos montar uma consulta, como Introdução a Banco de Dados 17 vimos anteriormente, calculando o resultado deste valor total. Concluindo as três formas normais, ficaremos com a seguinte configuração das tabelas: Vendas {Código da Venda, Código do Cliente, Código do Produto, Quantidade}. Cidades (Código da Cidade, Cidade, Estado). Produtos {Código do Produto, Descrição do Produto, Valor Unitário}. Clientes {Código do Cliente, Nome do Cliente, Endereço, CEP, Código da Cidade, Telefone}. O resultado da normalização é fazer com que uma única tabela, que pode ser o retrato de um formulário identificado na fase de levantamento de informações sobre o mundo real do cliente, seja derivada de uma ou mais tabelas, todas elas livres de redundâncias e inconsistências. RESUMINDO: E então? Gostou do que lhe mostramos? Aprendeu mesmo tudinho? Agora, só para termos certeza de que você realmente entendeu o tema de estudo deste Capítulo, vamos resumir tudo o que vimos. Você deve ter aprendido que antes de se aprofundar na normalização de dados é importante compreender como os bancos de dados funcionam, seus conceitos fundamentais e as técnicas mais rudimentares de criarmos tabelas, formulários e consultas. Assim, temos uma visão muito acurada sobre o que é essa tecnologia, suas ferramentas e o modo como esses grupamentos de dados são atualizados e consultados, além do conhecimento de uma linguagem estruturada de consulta capaz de orquestrar tudo isso, ou seja, a Structured Query Language, ou Linguagem de Consulta Estruturada (SQL). Com esse conhecimento, podemos avançar, saindo, momentaneamente, do mundo dos bits e bytes, e abstrair um pouco os conceitos de banco de dados. Para tanto, é importante o entendimento de como os dados do mundo real vão parar nas tabelas e consultas do mundo digital, além de como podem ser modelados os dados desse mundo real, de forma que elescaibam, na medida exata, dentro de um banco de dados. Introdução a Banco de Dados 18 Modelo Entidade-Relacionamento OBJETIVO: Ao término deste capítulo, você será capaz de entender o modelo entidade-relacionamento. Isso será fundamental para o exercício de sua profissão. E então? Motivado para desenvolver esta competência? Então, vamos lá. Avante! Conceitos e Definições sobre Modelos Entidade-Relacionamento O modelo que iremos estudar é o modelo conceitual, chamado modelo entidade relacionamento (MER), pelo fato de ser um modelo de dados conceitual de alto nível, também muito popular. Antes de iniciar, vamos contextualizar o que significa o MER. Em 1976, Peter Chen, publicou um trabalho intitulado The Entity-Relationship Model: Toward the unified view of data, no qual definia o processo de modelagem de dados. Esse trabalho foi publicado e amplamente aceito. Após a divulgação, passou a ser considerado o referencial definitivo para o processo de modelagem de dados (COUGO, 1997). O MER é composto por uma técnica de diagramação e um conjunto de conceitos simples, servindo como meio de representação dos próprios conceitos por ela manipulados (RAMAKRISHNAN; GEHRKE, 2002) O MER é, na realidade, um modelo conceitual de dados, cujo objetivo é descrever as entidades (ou objetos) envolvidos em um negócio ou sistema. Cada uma dessas entidades tem atributos e relacionamentos estabelecidos com outras entidades. Quando pensamos em um MER, pensamos nos dados que possam ser consideradas fontes de informações para o negócio do nosso cliente. Esses dados são as entidades, como “Funcionários”, “Produtos”, “Clientes” etc. Você deve estar se perguntando: mas esses dados não são tabelas? A resposta é: não necessariamente. Introdução a Banco de Dados 19 Figura 6 -‒ Os dados dos funcionários de uma empresa podem ser considerados como uma entidade, sendo uma fonte de informações para o MER Fonte: Freepik As entidades poderão se transformar em uma ou mais tabelas relacionadas entre si. Mas, e os atributos? Não são os campos de dados? Da mesma forma, a resposta é: não necessariamente. Digamos que, ao passar por um processo de transformação de modelo de dados para banco de dados, outros campos que não aparecem como atributos do modelo poderão ser criados. Ao construir um modelo conceitual de dados, temos que focar no desenho das principais fontes de informações. Para exemplificar, vamos imaginar que estamos modelando dados para um representante comercial que precisa informatizar a sua cadeia de vendas. A primeira pergunta a fazer para esse cliente é: Quais são as suas principais fontes de informação? Ele, provavelmente, irá responder que são seus clientes, vendedores, produtos e fornecedores. Desenhando essas entidades em forma de “caixinhas”, vamos espalhá-las tanto quanto possível no papel, conforme exemplificado na Figura 7. Introdução a Banco de Dados 20 Figura 7 -‒ Principais entidades do exemplo Clientes Produtos Vendedores Fornecedores Fonte: Duarte (2016). Analisando o que foi apresentado até o momento, podemos questionar, por exemplo: qual é a relação entre clientes e produtos? Para responder a essa pergunta, vamos dividi-la em partes. Primeiramente, um cliente pode pedir um ou mais produtos? Se sim, a relação de um para o outro será de um cliente para “N” produtos. Depois, invertemos a pergunta: um produto pode ser pedido por um ou mais clientes? Claro que a resposta é sim. Nesse caso, a relação de produto para cliente também é de um para “N”. Ou seja, a relação entre produtos e clientes se transformou em um relacionamento de “N” para “N”, de muitos para muitos. Como podemos ver no diagrama a seguir, o relacionamento entre “Clientes” e “Produtos” é, justamente, a relação de consumo, logo, pela técnica de modelagem conceitual de dados, deve-se diagramar as duas entidades e seu relacionamento. Veja a Figura 8 Figura 8 ‒- O relacionamento entre clientes e produtos é a relação de compra ou consumo Clientes ProdutosPEDE N N Fonte: Duarte (2016). Introdução a Banco de Dados 21 É importante, também, outros conhecimentos, por exemplo, de acordo com a técnica de modelagem conceitual de dados, toda vez que existir uma relação de “N” para “N”, uma nova entidade será interposta no meio dessa relação. A essa entidade damos o nome de “entidade de ligação”. DEFINIÇÃO: Entende-se por entidade de ligação o resultado do relacionamento de muitos para muitos (ou “N” para “N”) entre duas outras entidades (DUARTE, 2016).. No caso específico da relação clientes-produtos, essa entidade de ligação, certamente, será o pedido de cada cliente. Logo, em vez de duas entidades relacionadas, teremos três. Figura 9 -‒ Nos bancos de dados é coletado o relacionamento entre clientes e produtos Fonte: Freepik, De um lado, “Clientes”, em uma relação de um para “N” com a entidade de ligação “Pedidos”; do outro, teremos “Produtos”, em uma Introdução a Banco de Dados 22 ligação também de um para “N” com “Pedidos”. O diagrama ilustrado na Figura 10 representa bem essa situação. Figura 10 ‒- O relacionamento entre clientes e produtos é a relação que resulta nos pedidos Clientes Produtos N1 Fonte: Duarte (2016). É importante que os profissionais de banco de dados conheçam os atributos das entidades que, sendo neste nível de abstração, como já apresentado anteriormente, os dados que compõem as entidades recebem o nome de “atributo”. Veja a seguir: • Chaves primárias. • Chaves secundárias. • Chaves alternativas ou candidatas. • Chaves estrangeiras. A chave primária de uma entidade é o atributo, ou o conjunto deles, que identifica uma única informação, sem repetição, fazendo uma analogia com uma tabela. Um conjunto de colunas que identificam uma única linha, sem repetição. As chaves primárias podem ser as seguintes: • Simples: quando representadas por um único atributo. • Compostas: quando reúnem um conjunto de atributos. Nesse caso, a concatenação entre esses atributos é o que define uma única informação da entidade, sem repetição. No exemplo do diagrama ilustrado anteriormente, percebemos que, para identificar um pedido de um cliente, precisamos do código deste e do produto. Dizemos, então, que a chave primária da entidade “Pedidos” é composta por, entre outros atributos, “Código do Cliente” e “Código do Produto”. Introdução a Banco de Dados 23 Figura 11 ‒- O pedido de um cliente são informações importantes que devem constar nos bancos de dados Fonte: Freepik. Entende-se por chave secundária de uma entidade, aquele atributo que, mesmo não identificando uma única informação dentro da entidade, pode ser utilizado para indexá-la de acordo com alguma necessidade de ordenamento, classificação ou agrupamento. No caso da entidade “Vendas”, vista no diagrama MER apresentado anteriormente, poderíamos ter um atributo intitulado “Categoria”, que tipificaria a venda entre vários níveis de importância para a empresa. Embora esse atributo não identifique uma única informação na entidade, ele pode ser encarado como uma chave secundária para várias buscas, classificações e ordenamentos, que podem ser realizados sobre essa entidade. Já a chave alternativa (ou candidata) de uma entidade é o atributo, ou o conjunto deles, que também identifica uma única informação, sem repetição, mesmo sem ser a chave primária da entidade. Um bom exemplo disso é se tivéssemos um atributo chamado “CNPJ” dentro da entidade “Clientes”. Dois clientes jamais poderão ter um mesmo CNPJ, não é verdade? Nesse caso, o campo “CNPJ” seria um candidato à chave primária da entidade “Clientes”, logo, esse atributo é denominado “chave alternativa” ou “chave candidata” dessa entidade. A chave estrangeira é um atributo que, embora não seja chave em uma entidade, é em outra, representando um elo de ligação entre elas. No caso da entidade de ligação “Vendas”,as chaves primárias de Introdução a Banco de Dados 24 “Clientes” e “Produtos” deverão compor a sua estrutura de atributos. Assim, dentro da entidade “Vendas”, essas chaves serão consideradas estrangeiras. Podemos entender a chave estrangeira como sendo um atributo obrigatório em todo e qualquer relacionamento de 1:N. Nesse tipo de relacionamento, a chave primária da entidade “1” estará na entidade “N” como uma chave estrangeira. Figura 12 -‒ Entidades com seus respectivos atributos, nos quais os atributos-chaves estão em maiúsculo e negrito Clientes Produtos N1 Pedidos 1N CODPROD • Descrição • Preço • Peso • Volume • Qtd-Estoque •... • CODPED • CODCLI • CODPROD • Data-Pedido • Qtd-Pedida • ... • CODCLI • Nome • Endereço • CEP • Cidade • Estado • ... Fonte: Duarte (2016). Considerando o último diagrama MER, vamos fazer algumas análises? Por exemplo: perceba que “Clientes.CODCLI” e “Produtos. CODPROD” são as chaves primárias das entidades “Clientes” e “Produtos”, respectivamente. Por isso, vamos tratá-las com essa nomenclatura, ou seja, o nome da tabela seguida de um ponto “.”, e o nome do campo logo em seguida. Perceba que esses mesmos atributos aparecem na entidade de ligação “Pedidos”. Nessa entidade, nós os trataremos como “Pedidos. CODCLI” e “Pedidos.CODPROD”. As múltiplas ligações também são importantes de serem analisadas, veja este questionamento: uma entidade de ligação pode ligar apenas duas entidades? A resposta é não. Ela pode ligar três entidades que, nesse caso, estaríamos falando de uma tríplice ligação, ou mais de três. Introdução a Banco de Dados 25 REFLITA: Se a entidade “Pedidos” representa uma entidade de ligação entre “Clientes” e “Produtos”, por que a chave primária adotada não foi uma chave composta de “Pedidos. CODCLI” e “Pedidos.CODPROD”? A resposta é simples. Considerando que um cliente pode efetuar o pedido de um mesmo produto diversas vezes, esses dois atributos concatenados não conseguiriam identificar uma única informação na entidade, concorda? Desse modo, existiam duas maneiras de solucionar esse problema. Uma delas foi adotada no diagrama ilustrado anteriormente, ou seja, foi criada uma nova chave primária intitulada “CODPED”. Essa chave nunca poderá ser repetida. No entanto, poderíamos ter adotado uma chave primária composta para essa entidade. Para que não houvesse redundância, ou seja, para que ela pudesse recuperar uma única informação de “Pedidos”, teríamos que ter os seguintes atributos formando essa chave: “CODCLI”, “CODPROD” e “Data-Pedido”. Mas, e se um mesmo cliente pedisse um mesmo produto mais de uma vez em um mesmo dia? Nesse contexto, ainda estaríamos experimentando um problema de redundância. E como resolver isso? Ou adotamos uma chave primária simples e independente, como foi o caso de “CODPED”, ou teríamos que adicionar um atributo “Hora-Pedido” na entidade “Pedidos”. Inclusive, mesmo assim, teríamos que adicionar um atributo de hora completa, com minutos e segundos, pois em uma mesma hora o cliente poderia emitir dois pedidos. Nada como um exemplo para entender melhor, então vamos retomar nosso estudo de caso anterior, tentando entender como as outras duas entidades se relacionam com clientes e pedidos. Vamos começar pelos vendedores e como eles se relacionam com os produtos vendidos pela empresa. Faremos duas perguntas ao nosso modelo: 1. Um vendedor vende um ou mais produtos? .............( ) Um ( ) Mais 2. Um produto é vendido por um ou mais vendedores? ( ) Um ( ) Mais Introdução a Banco de Dados 26 Claro que a resposta a essas duas perguntas é só uma: “mais”, um vendedor pode vender “N” produtos, e um mesmo produto pode ser vendido por “N” vendedores. Figura 13 ‒- As relações de compra e venda entre o vendedor e cliente também são consideradas no banco de dados Fonte: Freepik. Veja como está ficando o MER: Figura 14 ‒- Relacionamento entre vendedores e produtos Clientes Produtos Vendedores Fornecedores PEDE N N VENDE N N Fonte: Duarte (2016). Introdução a Banco de Dados 27 É importante analisar que a venda é decorrente de um pedido, então, o relacionamento entre “Vendedores” e “Produtos” não faz sentido sem indicarmos para quais clientes eles estão vendendo os produtos pedidos. SAIBA MAIS: Para se aprofundar no tema sobre MER, recomendamos o acesso da seguinte fonte de consulta e conhecimento. Para acessar, clique aqui. Logo, uma venda está associada a um produto, pedido por um cliente. Implementando esse conceito no MER, resultará no exemplo a seguir. Figura 15 ‒- Entidade de tríplice ligação Clientes Produtos Vendedores Fornecedores PEDE N N VENDE N N Fonte: Duarte (2016). Entendemos uma tríplice ligação como o relacionamento entre três entidades. Esse é o caso que acabamos de analisar. Da relação entre “Clientes”, “Produtos” e “Vendedores” teremos o surgimento de uma nova entidade de ligação, ou melhor, de tríplice ligação: “Vendas”. Introdução a Banco de Dados http://revistas.faa.edu.br/https://scorm.onilearning.com.br/scorm.php?scorm=db9f7de7dd804e5d653c156c0ab327f6&estudante=0&nome=&licao=&sessao=v7tg9ssq49e2d1kpsak7h01r2q/SaberDigital/article/view/1029 28 Figura 16 -‒ MER com uma entidade de tríplice ligação Clientes Produtos N1 Pedidos 1N CODPROD • Descrição • Preço • Peso • Volume • Qtd-Estoque •... • CODPED • CODCLI • CODPROD • Data-Pedido • Qtd-Pedida • ... • CODCLI • Nome • Endereço • CEP • Cidade • Estado • ... Vendas Vendedores N N N • CODVENDA • CODCLI • CODPROD • CODVEND • Data-Venda • Qtd-Vendida • Val-Desconto • Num-Nota-Fiscal • ... • CODVEND • Nome • Endereço • CEP • Cidade • Estado • Perc-Comissão • ... Fonte: Duarte (2016). O diagrama anterior ilustra como ficaria o MER com uma entidade de tríplice ligação, unindo as entidades “Produtos”, “Clientes” e “Vendedores”. EXPLICANDO MELHOR: Pesquise sobre programas para a construção de diagramas entidade-relacionamento. Introdução a Banco de Dados 29 RESUMINDO: E então? Gostou do que lhe mostramos? Aprendeu mesmo tudinho? Agora, só para termos certeza de que você realmente entendeu o tema de estudo deste Capítulo, vamos resumir tudo o que vimos. Você deve ter aprendido que a modelagem conceitual de dados é uma alternativa de se chegar a um projeto de banco de dados diferente da normalização. Enquanto na normalização partimos dos dados reais do negócio, na modelagem conceitual o foco é o entendimento do negócio como um todo. Para entender bem este método, é importante usar o poder de abstração e, principalmente, conhecer o negócio do cliente. O MER é, na realidade, um modelo conceitual de dados, cujo objetivo é descrever as entidades (ou objetos) envolvidos em um negócio ou sistema. Entende-se por entidade de ligação o resultado do relacionamento de muitos para muitos (ou “N” para “N”) entre duas outras entidades. Uma entidade de ligação pode ligar três entidades. Nesse caso, estaríamos falando de uma tríplice ligação, ou mais de três. Introdução a Banco de Dados 30 Modelo Lógico de Dados OBJETIVO: Ao término deste capítulo, você será capaz de entender o modelo lógico de dados. Isso será fundamental para o exercício de sua profissão. E então? Motivado para desenvolver esta competência? Então, vamos lá. Avante!. A Importância do Modelo Lógico de Dados Modelagem de dados é um processo que começa no nível abstrativo e criativo, quando do desenho dos primeiros MERs, e termina no dicionário de dados, que determina como cada campo de cada tabela irá ser definido. Podemos dizer que tudo inicia no mundo do usuário e termina no mundo dos bits e bytes. É na transição entre o mundo real e o digital que começam os problemas. Estes podem ser divididos em dois grupos: incompatibilidade entre o desenho do MER e os recursos do sistema de gerenciamento de banco de dados (SGBD); dificuldade de performance relacionada ao desempenho dos servidores que hospedam obanco de dados. Alguns SGBDs, como Oracle, PostgreSQL e SQL Server conseguem processar bem as chaves compostas, ou seja, um grupo de campos considerados chaves primárias de uma tabela. Já o Access, entre outros gerenciadores, não consegue extrair muito desse tipo de arranjo. Para essas ferramentas, independentemente de haver grupos de chaves estrangeiras em uma tabela de ligação, em vez de defini-los como chaves primárias, é melhor criar chaves simples do tipo autoincremento. IMPORTANTE: As chaves de autoincremento são capazes de somar “um” ao seu próprio valor automaticamente quando uma nova linha é adicionada à tabela. O Access trabalha bem com esse conceito de chave primária. Introdução a Banco de Dados 31 Embora a redundância de dados seja considerada não indicada ao considerarmos os preceitos das formas normais, ela é tolerada em alguns casos. Por exemplo, o uso de um campo calculado em uma tabela Access, embora seja considerado uma dependência transitiva, pode ser aceito em um modelo lógico por questões de otimização de performance. Em alguns casos, em vez de um cálculo ser processado toda vez que for gerada uma consulta em um banco de dados com bilhões de registros, talvez seja melhor manter uma redundância controlada em uma tabela em prol da velocidade de processamento. É importante desenhar um modelo lógico de dados que não se distancia muito do modelo conceitual. A diferença se dá no detalhamento de certos aspectos, como a presença de todos os atributos de cada tabela, o detalhamento dos campos chaves e não chaves e a ausência completa dos relacionamentos conceituais. Ou seja, aqueles losangos que indicavam a ação associativa de uma tabela para a outra, como “Clientes” ‒ “Compram” ‒ “Produtos”. O modelo lógico de dados pode ser melhor compreendido com um exemplo. Se abrirmos um banco de dados Access e clicarmos na ferramenta “Relações”, que pode ser encontrada no grupo “Ferramentas de Banco de Dados” da barra de ferramentas, veremos um bom exemplo do que estamos falando. Figura 17 ‒- Exemplificação de relações no Access Fonte: Duarte (2016). Introdução a Banco de Dados 32 Perceba nessa figura os atributos das entidades, que agora passam a se chamar: “os campos (ou colunas) das tabelas”; aparecem dentro dos blocos representativos de cada tabela. Os campos-chaves aparecem com um ícone em formato de “chave” em sua lateral esquerda; os relacionamentos, que sempre são de 1:N, recebem outra nomenclatura, ou seja, de 1 para infinito. Existem algumas ferramentas no mercado de softwares (CASE) que servem para auxiliar o projetista a desenhar o seu modelo de dados e, a partir dele, detalhar, miniespecificar e criar bancos de dados. O princípio de funcionamento de uma ferramenta CASE se assemelha bastante com o que o Access faz, com as seguintes diferenças, conforme apontado no Quadro 1. Quadro 1 ‒ Modelo lógico de um banco de dados Access SGBD Ferramenta CASE Parte da definição das tabelas. Parte do desenho do MER. Chega até a criação e o gerenciamento do banco de dados. Chega apenas até a miniespecificação do banco de dados. Só geram bancos de dados para a sua própria estrutura e linguagem. Gera bancos de dados em qualquer formato e para qualquer SGBD. Fonte: Duarte (2016). O termo CASE significa “Computer-Aided Software Engineering”, que pode ser traduzido como “engenharia de software auxiliada por computador”. Existem três classes de ferramentas CASE disponíveis no mercado: 1. Lower CASE: servem para gerar a codificação para aplicações front-end, minimizando o trabalho de programação por parte do desenvolvedor de sistemas. 2. Upper CASE: auxiliam o projetista de software (ou analista de sistemas) na concepção e modelagem do sistema como um todo, oferecendo recursos de diagramação de modelos de dados e processos, chegando até a miniespecificação desses dados e processos. Introdução a Banco de Dados 33 3. Integrated CASE: são ferramentas que desempenham todo o trabalho de desenvolvimento, programação e implantação de sistemas, ou seja, é a união do Lower com o Upper CASE. Ferramentas CASE são softwares que auxiliam profissionais de Tecnologia da Informação (TI) que trabalham com projetos de desenvolvimento de sistemas de informações, gerando documentação e, em alguns casos, códigos-fontes em vária linguagens de programação. SAIBA MAIS: Para se aprofundar no tema modelo lógico de dados é recomendo o acesso à seguinte fontes de consulta e conhecimento. Para acessar, clique aqui. O próximo passo depois de desenhar um modelo lógico de dados é construir o seu dicionário de dados. No caso específico da modelagem de dados, esse dicionário contém todas as informações acerca dos dados que compõem cada tabela do modelo. Figura 18 ‒- Exemplificação de CASE Fonte: Wikimedia Commons. No caso específico do Access, esse dicionário de dados pode ser extraído do próprio modelo lógico, bastando clicar em cima do bloco Introdução a Banco de Dados https://goo.gl/5Nirzn 34 representativo da tabela com o botão direito do mouse e escolher a opção “Design da Tabela”. Figura 19 ‒- Exemplificação de atributos e propriedade do campo Fonte: Duarte (2016). Introdução a Banco de Dados 35 O Access é um SGBD não muito robusto, por isto não há uma funcionalidade para imprimir ou gerar um dicionário de dados. Mas outros SGBDs e, principalmente as ferramentas CASE, conseguem gerar uma vasta documentação, incluindo o dicionário de dados de um projeto de banco de dados. RESUMINDO: E então? Gostou do que lhe mostramos? Aprendeu mesmo tudinho? Agora, só para termos certeza de que você realmente entendeu o tema de estudo deste Capítulo, vamos resumir tudo o que vimos. Você deve ter aprendido que a diferença entre modelo conceitual e modelo lógico de dados está na aderência do modelo à tecnologia que será aplicada quanto ao projeto de banco de dados. Em outras palavras, enquanto no modelo conceitual a preocupação é tão somente com o negócio do cliente e o seu mundo real, a preocupação do modelo lógico é a adequação desse mundo real às limitações e características do SGBD que será utilizado mais adiante. A modelagem de dados é uma etapa que inicia no nível abstrativo e criativo, quando do desenho dos primeiros MERs, e termina no dicionário de dados, que determina como cada campo de cada tabela irá ser definido. Embora a redundância de dados seja considerada uma heresia pelos preceitos das formas normais, ela é tolerada em alguns casos. Introdução a Banco de Dados 36 Classes e Especializações de Dados OBJETIVO: Ao término deste capítulo, você será capaz de compreender sobre classes e especializações de dados. Isso será fundamental para o exercício de sua profissão. E então? Motivado para desenvolver esta competência? Então, vamos lá. Avante!. Especializações de Dados Muitas vezes, nos projetos de bancos de dados se faz necessário inserir mais de uma entidade que contém os mesmos dados, porém para propósitos diferentes. Dessa maneira, é destacada a importância do conhecimento de classes e especializações de dados. Imagine que em uma faculdade, os campos de endereço, telefone, bairro, cidade, e-mail, entre outros dados pessoais, são utilizados em várias entidades, como alunos, professores, funcionários e contatos. Embora não possa ser considerado redundância, pois se trata de entidades distintas, termina que, em alguns casos, um aluno pode se tornar um professor, futuramente. E, nesse caso, o que fazer com o cadastro desse aluno? Repetir a digitação de todos esses dados no cadastro de professores? Importar esses dados para tornar mais rápido o processo? Mas e quanto à redundância de informações? A técnica da especialização de dados veio para resolver esse problema, em vez de criar essas quatro entidades no modelo de dados, cria-se uma única entidade intitulada: “Pessoas”. Introdução a Banco deDados 37 Figura 20 - Aglutinação dos dados comuns em uma grande entidade intitulada “Pessoas” Alunos Professores Contatos Funcionários Pessoas Fonte: Duarte (2016). Nessa entidade são colocados os atributos comuns a toda e qualquer pessoa que possa se relacionar com a faculdade, como alunos, pais ou responsáveis, professores, contatos de fornecedores, funcionários, interessados ou alunos em potencial etc. Estamos falando justamente de dados como “Nome”, “Endereço”, “Cidade”, “Estado”, “CEP”, “Telefones de contato”, “E-mail” etc. Esses atributos são comuns a qualquer entidade sobre as quais falamos anteriormente, pelo menos até determinado nível. IMPORTANTE: Claro que existem dados específicos, como o número da carteira profissional, que não faria sentido algum constar da entidade “Alunos”, mas faz todo o sentido constar “Funcionários”. Como você pode visualizar neste diagrama, derivando da entidade “Pessoas”, podemos construir as demais entidades como sendo especializações de “Pessoas”. Na prática, é como se tivéssemos várias entidades ligadas a “Pessoas” com um relacionamento de um para um, a essas outras entidades derivadas damos o nome de “classes”. Por exemplo, a entidade “Alunos” deixa de ser uma entidade independente Introdução a Banco de Dados 38 para ser uma classe da entidade “Pessoas”, e assim por diante, como mostra a Figura 21. Figura 21 ‒- MER envolvendo várias classes de uma entidade Pessoas Alunos Clientes Professores Fornecedores Contatos Produtos Funcionários Vendedores 1 1 1 1 1 1 1 1 Fonte: Duarte (2016). Mas qual é a real vantagem disso? Uma vez cadastrada na empresa, uma pessoa jamais terá que ser novamente cadastrada, ela, no máximo, receberá uma atualização cadastral e uma mudança de status, como no caso do aluno que virou professor. O autorrelacionamento é muito importante, pois, muitas vezes, uma entidade se relaciona com ela mesmo. Estranho? Como assim? Simples. Imagine uma entidade denominada “Disciplinas”, que contém todas as disciplinas que uma faculdade ministra para os seus alunos. Sabemos que algumas disciplinas têm pré-requisitos, ou seja, para cursar determinada disciplina, o aluno terá que ter cursado outra ou outras disciplinas de seu curso. Esse é um caso típico de autorrelacionamento, e pode ser representado na Figura 22. Introdução a Banco de Dados 39 Figura 22 ‒ Exemplo de autorrelacionamento de 1:N Disciplinas N 1 Depende Fonte: Duarte (2016). Você pode observar, pela ilustração em tela, que o relacionamento de 1:N enseja a seguinte reflexão: uma disciplina pode ser pré-requisito de “N” outras, mas essa disciplina só pode ter apenas um pré-requisito. É isso que está diagramado nesse MER. Mas será que isso é verdade mesmo? Se pensarmos melhor, há casos em que uma disciplina é pré-requisito para várias outras e, ao mesmo tempo, tem mais de um pré-requisito. Figura 23 ‒ Exemplo de autorrelacionamento de N:N Disciplinas Pedidos N N Depende Fonte: Duarte (2016). Como vimos anteriormente, um relacionamento de muitos para muitos faz surgir uma entidade de ligação no meio desse relacionamento. SAIBA MAIS: Para se aprofundar no tema classes e especializações de dados, é recomendo o acesso à seguinte fonte de consulta e conhecimento. Para acessar, clique aqui. Introdução a Banco de Dados http://www.unilivros.com.br/pdf/dbmod.pdf 40 Essa entidade de ligação é, nesse caso, a malha de pré-requisitos da faculdade, ou seja, uma entidade que contém que disciplinas são pré-requisito de quais outras, e assim por diante. Esse novo contexto é ilustrado na Figura 24. Figura 24 ‒ Exemplo de autorrelacionamento de 1:N1 Disciplinas 1 1 Pré-requisitos N N Fonte: Duarte (2016). Desse modo, o modelo ilustrado não reflete a verdade do mundo real, a ilustração do MER correta seria, portanto, a que foi representada na Figura 23. RESUMINDO: E então? Gostou do que lhe mostramos? Aprendeu mesmo tudinho? Agora, só para termos certeza de que você realmente entendeu o tema de estudo deste Capítulo, vamos resumir tudo o que vimos. Você deve ter aprendido que classes e especializações de dados podem ser consideradas como a “reta final” em relação à modelagem de dados. É importante aprimorarmos nossos conhecimentos sobre modelagem de dados, estudando alguns relacionamentos mais complexos, como o autorrelacionamento e s especializações ou classes de entidades. Muitas vezes, precisamos inserir mais de uma entidade que contém os mesmos dados, porém para propósitos diferentes, as técnicas da especialização de dados são indicadas para resolver esse problema. Um relacionamento de muitos para muitos faz surgir uma entidade de ligação no meio de relacionamentos. Introdução a Banco de Dados 41 REFERÊNCIAS ALEXANDRUK, M. Modelagem de banco de dados. Unilivros, 2011. Disponível em: www.unilivros.com.br/pdf/dbmod.pdf. Acesso em: 14 jan. 2022. ARAÚJO, M. A. Modelagem de dados: teoria e prática. Revista Saber Digital, Valença, v. 1, n. 1, p. 33-39, 2008. CINDRA, J. D.; BARCELOS, M. R.; LISBÔA, J. C. Uma pesquisa sobre ferramentas case para engenharia reversa estática. Perspectivas On-line, Campos dos Goytacazes, v. 1, n. 2, p. 45-52, 2011. COUGO, P. Modelagem conceitual e projeto de bancos de dados. Rio de Janeiro: Elsevier, 1997. DUARTE, A. L. Introdução a banco de dados. Recife: Uninassau, 2016. ELMASRI, R.; NAVATHE, S. B. Sistemas de bancos de dados. 4. ed. São Paulo: Pearson Addison-Wesley, 2005. KENT, W. Guia simplificado para as 5 formas normais. Revista SQL Magazine. Devmedia, 2011. Disponível em: http://www.devmedia.com. br/guia-simplificado-para-as-5-formas-normais-artigo-revista-sql- magazine-87/21043. Acesso em: 14 jan. 20. RAMAKIRISHNAN, R.; GEHRKE, J. Database Management Systems. 3. ed. New York: McGraw-Hill, 2002. Introdução a Banco de Dados Normalização de Dados As Formas Normais Modelo Entidade-Relacionamento Conceitos e Definições sobre Modelos Entidade-Relacionamento Modelo Lógico de Dados A Importância do Modelo Lógico de Dados Classes e Especializações de Dados Especializações de Dados
Compartilhar