Prévia do material em texto
MODELAGEM E DESENVOLVIMENTO DE BANCO DE DADOS Fabrício Felipe Meleto Barboza Evolução dos bancos de dados Objetivos de aprendizagem Ao final deste texto, você deve apresentar os seguintes aprendizados: � Identificar a evolução dos bancos de dados. � Reconhecer a ordem cronológica dos bancos de dados. � Explicar as origens dos bancos de dados. Introdução Um banco de dados é um conjunto de valores e arquivos que se relacio- nam entre si e demonstram um cadastro de pessoas, vendas, produtos, agendas, etc. Por exemplo, uma planilha ou uma ficha cadastral podem ser exemplos de cadastros. O banco de dados guarda todos esses cadastros em formato virtual e os disponibiliza para as aplicações consultarem e emitirem relatórios, realizarem vendas, etc. Neste capítulo, você vai estudar sobre a evolução dos bancos de dados decorrente das necessidades impostas por seus utilizadores e para solucionar problemas da sociedade. Adicionalmente, você verá, em uma escala de tempo, os principais marcos da história dos bancos de dados com suas características e particularidades. Por fim, irá conhecer o início de tudo, isto é, o que deu origem aos bancos de dados como são conhecidos hoje em dia. A evolução dos bancos de dados A evolução dos bancos de dados foi e continua sendo de constante melhoria, trazendo mais segurança e rapidez para as informações ou dados nele salvas. Para Korth, Silberschatz e Sudarshan (2012), um banco de dados “[...] é uma coleção de dados inter-relacionados, representando informações sobre um domínio específico”. Identificação interna do documento ITB70PPNV5-KNEPN9F2 Pense em uma situação hipotética em que você tenha uma loja de sapatos em um shopping. Você está verificando a implantação de um sistema para controlar todas as suas vendas e também as compras de reposição de estoque, de maneira que todas as informações da sua loja estarão salvas em um sistema no computador da loja que, obviamente, utiliza um banco de dados. Agora imagine se o vendedor do sistema pedisse pra você escolher entre 1) um sistema rápido, que tira relatórios gigantescos em menos de um segundo, processa vendas também em menos de um segundo do relógio, mas, por outro lado, não garante que a informação está íntegra e consistente, e 2) um banco de dados que garante a integridade e a consistência das informações, mas demora dez segundos para processar alguma venda ou um minuto para criar o relatório complexo solicitado. Qual você, dono da loja, escolheria? Lembre-se de que a evolução em sistemas de tecnologia da informação é importante, mas a segurança sempre deve vir em primeiro lugar para que, depois, possamos pensar em estabilidade, funcionalidade e velocidade. Uma tendência da evolução comum é sempre mirar e colocar o foco e as metas em realizar a ação com mais e mais rapidez, cada vez provendo maior velocidade e resultados instantâneos para o usuário do sistema. Porém, ao decidir pela evolução de um sistema de banco de dados, é necessário pensar em outros fatores além da velocidade. Com toda a certeza, a velocidade é importante e sempre levada em consideração, mas os outros pilares precisam ser garantidos para toda transação de um banco de dados. Esses pilares são: � Atomicidade; � Isolamento; � Consistência; � Durabilidade. Essas quatro características são garantidas para cada transação realizada no banco de dados, independentemente de quem realizou o comando: o próprio sistema, o usuário final ou ainda alguma rotina automática. Evolução dos bancos de dados2 Identificação interna do documento ITB70PPNV5-KNEPN9F2 Mas o que seria uma transação em um sistema de banco de dados? Uma transação para um sistema de gerenciamento de banco de dados (SGBD) é toda e qualquer atividade que o próprio sistema de gerenciamento de banco de dados executa após o usuário ter uma interação com o banco. Assim, qualquer atividade provocada pelo usuário via interface do sistema dispara uma transação ou uma cadeia de transações no banco de dados que precisam estar garantidas e ter aderência a esses pilares. Consequentemente, essa é a regra de ouro dos bancos de dados. A regra de ouro dos sistemas de gerenciamento de bancos de dados é a garantia de que todos os pilares das transações sejam assegurados e respeitados em cada uma de suas transações internas. Sabendo disso, agora, é necessário entender o que cada um desses pilares representa, defende e significa para os bancos de dados. Atomicidade Para entender o pilar da atomicidade, fazemos uma analogia à expressão “08 ou 80”, ou seja, ou finaliza com sucesso ou tudo é abortado. Portanto, ou o SGBD conclui todas as ações em cascata para uma transação (commit) ou ele retorna ao estado anterior da transação (rollback). Assim, a atomicidade é a responsável por garantir que ou uma transação é gravada com sucesso e garantida ou é realizado o rollback de toda a transa- ção para que o banco de dados retorne ao estado anterior daquela transação. Nunca um sistema de gerenciamento de banco de dados pode permitir que uma transação seja executada pela metade e fique sem rollback, pois isso faz a consistência do banco de dados ficar quebrada. Atomicidade é a regra do “ou tudo ou nada”. Ou toda a transação é salva com sucesso no banco ou toda a transação é descartada. 3Evolução dos bancos de dados Identificação interna do documento ITB70PPNV5-KNEPN9F2 Isolamento Este pilar representa a independência de cada transação no sistema de gerencia- mento de banco de dados. Cada transação é única e independente, o que faz com que duas transações que alterem o mesmo valor de uma tabela não entrem em conflito. Toda transação é uma engrenagem no sistema maior, que seria o SGBD. Conforme o sistema tem mais usuários trabalhando nele, mais esta regra se torna verdadeira e necessária. Imagine um e-commerce que realiza venda de enfeites natalinos. Quando chegar a época de procura por esses enfeites, o fluxo de pessoas utilizando o sistema irá aumentar consideravelmente. Agora imagine que existe apenas um item de Papai Noel em estoque e dois clientes realizam a compra desse item no mesmo segundo; como resolver? O pilar de isolamento garante que a transação que for processada em primeiro lugar pelo sistema de gerenciamento de banco de dados leve a compra e que a segunda pessoa receba um alerta de que o produto ficou fora de estoque. No exemplo, duas transações estavam tentando inserir dados referentes ao mesmo valor único, que seria a quantidade de estoque do produto. Por tratar-se de duas transações isoladas e independentes, o sistema de gerenciamento de banco de dados rapidamente resolve essa questão, de modo que tal responsa- bilidade não fica para a equipe de desenvolvimento. Isolamento é a garantia de que as transações não terão disputa para edição ou escrita em um determinado dado ou valor. Consistência As regras, em sua totalidade, sempre devem ser respeitadas para que o sistema de gerenciamento de banco de dados tenha atendido suas características de base. Isso inclui, por exemplo, que o tipo de valor inserido seja correto em relação ao tipo do seu atributo (VARCHAR, INT, DATE, etc.). Assim, em face da consistência, um campo do tipo Integer nunca poderá receber caracteres alfabéticos. Essa separação se dá para a criação de buscas e resultados mais rápidos em campos do tipo numérico. Computadores só sabem interpretar números, de modo que campos não numéricos por natureza exigem Evolução dos bancos de dados4 Identificação interna do documento ITB70PPNV5-KNEPN9F2 mais processamento do computador, que precisa transformar a informação alfabética salva em códigos e linguagem de máquinas que são representados por números para conseguir trabalhar. Consistência é ter o dado certo no local esperado. Um campo do tipo Integer sempre deverá conter um valor de número inteiro. Durabilidade Quando uma transação é finalizada, seus dados estão a salvo de qualquer modificação. Somente outra transação podemodificar os dados. Assim, os dados ficam protegidos! Imagine que a sua compra foi finalizada com sucesso e, quando você vai buscar seu histórico de compras, ela não aparece. Ruim, correto? A durabilidade garante que a informação de sua compra só seja modificada por outra transação e, dessa forma, consegue-se rastrear as requisições e buscar o que ou quem fez tal atividade. O próprio sistema de gerenciamento de banco de dados não realiza nenhuma modificação após a conclusão de todas as transações pendentes. Portanto, qualquer modificação de um valor do banco de dados será de origem do usuário ou do sistema. Durabilidade é a proteção dos dados contra qualquer coisa que não seja uma nova transação do banco de dados. Cronologia dos bancos de dados Há divergência na ordem cronológica do surgimento das versões dos bancos de dados, exceto as versões mais comumente utilizadas. Observe a Figura 1, que representa as etapas mais importantes da evolução dos bancos de dados. 5Evolução dos bancos de dados Identificação interna do documento ITB70PPNV5-KNEPN9F2 Figura 1. Cronograma de evolução dos BDs. Fonte: Adaptado de Castelano [200--]; Rezende (2006). Utilização de modelos em rede e hierárquico diminui A IBM utiliza o DB2 Primeiros bancos orientados a Objeto: O2 [1988], Exodus [1986], ORION [1986] O desenvolvimento do IBM PC ocasiona o surgimento de muitos produtos em BD Há a padronização do SQL pelo American National Standards Institute (ANSI) [1986, 1989] Década de 80 Com base na Figura 1, percebe-se grande concentração de lançamentos e popularização dos bancos de dados no período compreendido entre os anos 1980 até os 2000. Essa intensa movimentação se deu em virtude da infor- matização das empresas, que aconteceu ao longo desses anos. Cada empresa precisou incrementar seu parque tecnológico para que atendesse seus objetivos internos, como redução de custo, melhora do valor da entrega ao cliente, ou também objetivos externos, como estar de acordo com uma nova lei, receber auditoria de órgãos competentes ou, ainda, pela concorrência, que está em franca evolução e em busca por melhores resultados a todo custo. Antes da década de 1980, temos o estágio embrionário dos bancos de dados. Sua evolução estava ocorrendo, mas era centralizada em forma de pesquisas Evolução dos bancos de dados6 Identificação interna do documento ITB70PPNV5-KNEPN9F2 e experimentos. Até porque, quando fossem apresentados para as empresas e para o público geral, era necessário confiar no produto oferecido ao custo de milhões de dólares em pesquisas. Após os anos 2000, a evolução continua até os dias atuais, mas de forma menos acelerada, já que o foco, atualmente, é em estabilidade e segurança cada vez maiores. Partindo desse princípio, temos o surgimento de bancos de dados NoSQL, que fazem frente aos tradicionais bancos de dados rela- cionais SQL. Retome a Figura 1 e atente-se para o quadrante “Anos 2000”, no qual você verá que foi nesse período que surgiu o MongoDB, banco de dados NoSQL (Not only SQL) e com grande poder de processamento. Aí você pode se perguntar: “mas se ele é melhor, por que todos não migram pra ele?”. A resposta é direta: custo e foco do projeto. O banco de dados NoSQL não veio para matar os bancos de dados relacio- nais como muitos imaginavam em seu lançamento, mas para complementar e oferecer uma opção a mais para as empresas e desenvolvedores segundo Guedes (2017). Dessa forma, podemos exemplificar o uso de cada um dos tipos de bancos de dados de forma mais didática: caso a aplicação tenha relacionamentos entre as entidades e o volume de informações não for gigantesco, os bancos de dados relacionais tradicionais atenderão muito bem a sua demanda por um sistema. Agora, caso você tenha um sistema de bancos de dados grandioso, com muitos valores sendo escritos e lidos ao mesmo tempo, a indicação é um banco de dados do tipo NoSQL para que o seu sistema ganhe em desempenho e não frustre os usuários com telas de “carregando”, erros de timeout de conexão ou ainda a negação de serviço por falta de recursos ao processar uma consulta gigante do gerente que trabalha remoto, impedindo de abrir a agenda de reuniões de outro funcionário. Lembre-se também de que, por ser uma tecnologia mais nova, o custo para manter um banco de dados NoSQL é grande, até pela escassez de mão de obra qualificada no mercado de trabalho. Portanto, mensure esse custo ao tomar uma decisão sobre qual tipo de sistema de gerenciamento de bancos de dados utilizar no projeto. Origens dos bancos de dados Antigamente, as empresas produziam e mantinham cadastros de tudo que fosse necessário em fichas e papéis armazenados em um ou vários arquivos 7Evolução dos bancos de dados Identificação interna do documento ITB70PPNV5-KNEPN9F2 dentro de uma ou várias salas. Portanto, cliente, fornecedor, colabora- dor, agendas de compromisso, agendas telefônicas, inventário, controle de estoque, etc. estavam em um papel, em algum lugar dentro de algum arquivo. Obviamente, organizar e manter tudo atualizado era uma tarefa complexa demais, pois envolvia um esforço muito grande para buscar informações básicas e que deveriam estar acessíveis para qualquer colaborador de forma instantânea. Imagine que é necessário buscar todos os registros de ponto de entrada e saída de um colaborador que ficou durante vinte anos na empresa pois ele entrou com uma ação trabalhista, por exemplo. Agora imagine essa mesma situação e com um prazo de cinco dias para entregar toda essa informação ao Ministério do Trabalho. Impossível, certo? Além disso, as informações contidas nesses papéis ficavam facilmente ob- soletas em virtude da demora em atualizar o registro. Portanto, nada confiável. Imagine a probabilidade de um desastre na sala de arquivos, como um cano de água rompido que encharque todos os registros da empresa. Com certeza, a empresa em questão teria sérios problemas ou, em um caso mais extremo, mas não descartado, até mesmo fecharia as portas se algo dessa magnitude acontecesse. Pode-se ir mais a fundo e imaginar que algum funcionário espião ou insa- tisfeito com a empresa roube a informação de um projeto que iria ser lançado no próximo ano e a venda para a concorrência. Todo o esforço empregado na pesquisa e no desenvolvimento daquele projeto foi praticamente em vão, pois o elemento surpresa, para pegar o mercado no ponto certo e os concorrentes ficarem desequilibrados, foi perdido. Sempre que um problema é detectado, ele deve ser resolvido logo por meio do fomento de ideias para o seu contorno ou para a criação de solução definitiva. Pense que os bancos de dados só foram inventados porque existiu uma necessidade latente de diminuir despesas e melhorar a confiança nas informações salvas pela empresa com o passar dos anos. Evolução dos bancos de dados8 Identificação interna do documento ITB70PPNV5-KNEPN9F2 Dessa forma, havia um problema grande e generalizado em todas as cor- porações em que registros eram feitos em papéis e armazenados em um lugar qualquer, muitas vezes sem a devida importância para o dado, para o registro ali contido. Como grandes problemas sugerem soluções altamente lucrativas, iniciou-se pesquisas que apresentassem uma solução para todo esse caos vi- venciado em cada pequeno, médio ou grande escritório ou empresa no mundo. Na década de 1960, surge uma solução para esse caos: o banco de dados. Vários modelos foram apresentados à IBM, financiadora do projeto, e, entre os modelos propostos, estavam o hierárquico e o de rede. Apesar disso, nada muito usual ou com uma viabilidade de escala foi apresentado, o que fez os projetos serem engavetados. Segundo Alves (2013), já na década de 1970, mais precisamente no mês de junho, o então pesquisador da IBM Edgar Frank “Ted” Codd apresentou um artigo que mudaria a história dos modelos de bancos de dados para sempre – ele estava propondo o modelo relacional de bancos de dados. Em seu artigo RelationalModel of Data for Large Shared Data Banks, Ted descrevia como usuários leigos conseguiriam extrair os dados que lhes eram importantes. No raciocínio de Alves (2013), vemos que, já no fim da década de 1970, surge o Sistema R, um sistema baseado nas ideias de Ted. Junto ao lançamento do Sistema R, veio a linguagem SQL, acrônimo para Structured Query Language, a linguagem que dominou o mercado. O Sistema R não foi bem comercialmente e acabou sendo abandonado, mas serviu, com toda a certeza, de inspiração e base para muitos dos bancos de dados que temos nos dias de hoje. Finalizando seu pensamento, Alves (2013) diz que, na década de 1980, ocorrem dois marcos importantes na linha cronológica dos bancos de dados: o lançamento do Oracle 2 pela própria Oracle e, também, o lançamento do SQL/DS pela IBM, conhecido por DB2 atualmente. Portanto, temos aí a origem dos bancos de dados. Com o passar de mais anos e décadas, os sistemas de gerenciamento de bancos de dados foram evoluindo segundo a necessidade dos clientes, no caso de sistemas pagos, ou pela produção da comunidade, no caso de sistemas opensource. Aliás, uma curiosidade que também permeia este cenário de evolução: sempre que a comunidade dos sistemas de bancos de dados opensource lança algo inovador, as empresas que têm bancos de dados licenciados correm atrás e vice-versa. Com isso, muitas funcionalidades que estão presentes em sistemas de bancos de dados opensource também se tornam presentes nos sistemas proprietários, assim como o inverso. 9Evolução dos bancos de dados Identificação interna do documento ITB70PPNV5-KNEPN9F2 A aplicação de cada sistema de banco de dados se dará pela escolha cru- cial de quem irá desenvolver baseado no orçamento e conhecimento daquela tecnologia de banco de dados específica para otimizar o tempo do projeto e também o seu custo. Lembre-se de quem fez a pesquisa para obter os bancos de dados relacionais que conhecemos hoje: Edgar Frank “Ted” Codd, pesquisador da IBM na época e que lançou o artigo intitulado Relational Model of Data for Large Shared Data Banks. Ted é considerado o pai dos bancos de dados relacionais. ALVES, G. F. O. A história dos bancos de dados. 01 abr. 2013. Disponível em: <https://dicas- deprogramacao.com.br/a-historia-dos-bancos-de-dados/>. Acesso em: 21 maio 2018. CASTELANO, C. R. História dos bancos de dados. [20--] Disponível em: http://castelano. com.br/site/aulas/bd/Aula%2001%20-%20Introdu%C3%A7%C3%A3o.pdf. Acesso em: 23 jun. 2021. GUEDES, M. SQL vs NoSQL, qual usar? 19 jul. 2017. Disponível em: <https://www.treina- web.com.br/blog/sql-vs-nosql-qual-usar/>. Acesso em: 21 maio 2018. KORTH, H. F.; SILBERSCHATZ, A.; SUDARSHAN, S. Sistema de banco de dados. 6. ed. Rio de Janeiro: Campus, 2012.Leituras recomendadas CODD, E. F. A Relational Model of Data for Large Shared Data Banks. Communications of the ACM, v. 13, n. 06, June 1970. REZENDE, R. A história dos bancos de dados. 2006. Disponível em: https://www.dev- media.com.br/a-historia-dos-banco-de-dados/1678. Acesso em: 23 jun. 2021. REZENDE, R. Conceitos fundamentais de banco de dados. 2017. Disponível em: <https:// www.devmedia.com.br/conceitos-fundamentais-de-banco-de-dados/1649>. Acesso em: 21 maio 2018. Evolução dos bancos de dados10 Identificação interna do documento ITB70PPNV5-KNEPN9F2 Sistemas de Gerenciamento Sistemas de Gerenciamento de Banco de Dadosde Banco de Dados Ramakrishnan • Gehrke Tradução daTradução da Terceira EdiçãoTerceira Edição SISTEMAS DE GERENCIAMENTO DE BANCO DE DADOS 2011 Versão impressa desta obra: 2008 Raghu Ramakrishnan University of Wisconsin Madison, Wisconsin, USA Tradução da Terceira Edição Johannes Gehrke Cornell University Ithaca, New York, USA Tradução Célia Taniwake João Eduardo Nóbrega Tortello Revisão Técnica Elaine Parros Machado de Sousa Professora Doutora do Departamento de Ciências de Computação — Instituto de Ciências Matemáticas e de Computação da Universidade de São Paulo 2 Reparou que todas as letras da palavra database (banco de dados, em inglês) são digitadas com a mão esquerda? Sabemos que a disposição do teclado da máquina de escrever (QWERTY) foi projetada, entre outras coisas, para facilitar o uso uniforme de ambas as mãos. Conclui-se, então, que escrever sobre bancos de dados, além de ser algo não natural, é bem mais difícil do que parece. — Anônimo A quantidade de informações que nos são disponíveis está literalmente explodindo, e o valor dos dados como um ativo organizacional é amplamente reconhecido. Para obter a maior parte de seus grandes e complexos conjuntos de dados, os usuários necessitam de ferramentas que simplifiquem as tarefas de gerenciamento dos dados e a extração de informações úteis de forma oportuna. Caso contrário, os dados podem se tornar 1 VISÃO GERAL SOBREVISÃO GERAL SOBRE SISTEMAS DE BANCO DE DADOSSISTEMAS DE BANCO DE DADOS O que é um SGBD, em particular, um SGBD relacional? Por que devemos utilizar um SGBD para gerenciar dados? Como os dados da aplicação são representados em um SGBD? Como os dados em um SGBD são recuperados e manipulados? Como um SGBD suporta o acesso concorrente e protege os dados na ocorrência de falhas no sistema? Quais são os principais componentes de um SGBD? Quem está envolvido com bancos de dados na vida real? Conceitos-chave: gerenciamento de banco de dados, independência de dados, pro- jeto de banco de dados, modelo de dados; bancos de dados e consultas relacionais; esquemas, níveis de abstração; transações, concorrência e bloqueio, recuperação e registro em log; arquitetura de um SGBD; administrador de um banco de dados, programador do aplicativo, usuário final. ☛ ☛ ☛ ☛ ☛ ☛ ☛ ➽ Visão Geral sobre Sistemas de Banco de Dados 3 um passivo, cujo custo de aquisição e gerenciamento excede em muito o valor por ele produzido. Um banco de dados é uma coleção de dados que, tipicamente, descreve as ativida- des de uma ou mais organizações relacionadas. Por exemplo, um banco de dados de uma universidade poderia conter informações sobre: Entidades como alunos, professores, cursos e turmas. Relacionamentos entre as entidades, como a matrícula dos alunos nos cursos, cur- sos ministrados pelos professores, e o uso de salas por cursos. Um sistema de gerenciamento de banco de dados, ou SGBD, é um software proje- tado para auxiliar a manutenção e utilização de vastos conjuntos de dados. A neces- sidade de tais sistemas, assim como seu uso, tem crescido rapidamente. A alternativa para não se usar um SGBD é armazenar os dados em arquivos e escrever código es- pecífico do aplicativo para gerenciá-los. O uso de um SGBD tem diversas vantagens importantes, como veremos na Seção 1.4. 1.1 GERENCIANDO DADOS O objetivo deste livro é apresentar uma introdução detalhada dos sistemas de geren- ciamento de banco de dados, com ênfase em como projetar um banco de dados e como usar efetivamente um SGBD. Naturalmente, várias decisões sobre como utilizar um SGBD para um determinado aplicativo dependem de quais recursos o SGBD suporta de forma eficiente. Assim, para aproveitar bem um SGBD, é necessário compreender também como ele funciona. Diversos tipos de sistemas de gerenciamento de banco de dados estão em uso, mas este livro concentra-se nos sistemas de banco de dados relacionais (SGBDRs), que com certeza constituem o tipo dominante de SGBD nos dias atuais. As seguintes questões são tratadas nos capítulos principais deste livro: 1. Projeto de Banco de Dados e Desenvolvimento de Aplicativo: Como um usuário pode descrever uma empresa do mundo real (por exemplo, uma universidade) em termos dos dados armazenados em um SGBD? Que fatores devem ser con- siderados ao decidir sobre a forma de organização dos dados armazenados? Como podemos desenvolver aplicativos que dependem de um SGBD? (Capítulos 2, 3, 6, 7, 19, 20 e 21.) ■ ■ A área de sistemas de gerenciamento de dados é um microcosmo da Ciên- cia da Computação em geral. Os aspectos tratadose as técnicas utilizadas abrangem um amplo espectro, incluindo linguagens, orientação a objeto e ou- tros paradigmas de programação, compilação, sistemas operacionais, progra- mação concorrente, estruturas de dados, algoritmos, teoria, sistemas distri- buídos e paralelos, interfaces do usuário, sistemas especialistas e inteligência artificial, técnicas estatísticas e programação dinâmica. Não podemos tratar todos esses aspectos de gerenciamento de banco de dados em um livro, mas esperamos prover ao leitor um sentido de investigação nesta disciplina rica e vibrante. 4 CAPÍTULO 1 2. Análise dos Dados: Como um usuário pode responder a dúvidas sobre a empresa formulando consultas sobre os dados do SGBD? (Capítulos 4 e 5.)1 3. Concorrência e Robustez: Como um SGBD permite que vários usuários acessem os dados de forma concorrente, e como ele protege os dados na ocorrência de falhas do sistema? (Capítulos 16, 17 e 18.) 4. Eficiência e Escalabilidade: Como um SGBD armazena grandes conjuntos de dados e responde a questões sobre esses dados de forma eficiente? (Capítulos 8, 9, 10, 11, 12, 13, 14 e 15.) Os capítulos posteriores abrangem tópicos importantes que estão evoluindo rapida- mente, como o gerenciamento de banco de dados distribuído e paralelo, armazenagem de dados e consultas complexas para apoio à decisão, mineração de dados, recuperação de banco de dados e informações, repositórios XML, banco de dados orientado a obje- tos, gerenciamento de dados espaciais, e extensões de SGBD orientado a regras. No restante deste capítulo, introduziremos estes tópicos. Na Seção 1.2, começamos com uma breve história da área e uma discussão do papel do gerenciamento de banco de dados nos sistemas de informações modernos. Identificaremos, então, os benefícios de armazenar os dados em um SGBD em vez de em um sistema de arquivos, na Se- ção 1.3, e, na Seção 1.4, discutiremos as vantagens de usar um SGBD para gerenciar dados. Na Seção 1.5, apresentaremos como as informações sobre uma empresa devem ser organizadas e armazenadas em um SGBD. Um usuário provavelmente pensa sobre as informações num alto nível, que corresponde às entidades da organização e seus rela- cionamentos, enquanto o SGBD basicamente armazena os dados na forma de (vários e vários) bits. A lacuna existente entre como os usuários pensam sobre seus dados e como os dados são definitivamente armazenados é preenchida através de diversos níveis de abstração suportados pelo SGBD. Intuitivamente, um usuário pode começar descreven- do os dados em termos totalmente de alto nível, e depois melhorar a descrição conside- rando o armazenamento adicional e detalhes de representação conforme necessário. Na Seção 1.6, consideraremos como os usuários podem recuperar os dados armaze- nados em um SGBD e a necessidade de técnicas para processar eficientemente respos- tas às consultas envolvendo tais dados. Na Seção 1.7, forneceremos uma visão geral sobre como um SGBD suporta o acesso concorrente aos dados por diversos usuários e como ele protege os dados na ocorrência de falhas do sistema. Descreveremos, então, brevemente, a estrutura interna de um SGBD na Seção 1.8, e, na Seção 1.9, mencionaremos vários grupos de pessoas associadas com o desenvolvi- mento e uso de um SGBD. 1.2 UMA PERSPECTIVA HISTÓRICA Desde os primeiros computadores, armazenar e manipular dados têm sido o principal foco dos aplicativos. O primeiro SGBD de propósito geral, projetado por Charles Ba- chman, na General Electric, no início da década de 1960, foi chamado Depósito de Da- dos Integrados (Integrated Data Store). Ele constituiu a base do modelo de dados de rede, que foi padronizado pela Conference on Data Systems Languages (CODASYL) e influenciou bastante os sistemas de banco de dados na década de 1960. Bachman foi o primeiro a ser contemplado pelo Prêmio Turing da ACM (o equivalente ao Prêmio Nobel na Ciência da Computação) pelo trabalho na área de banco de dados; ele rece- beu o prêmio em 1973. 1 Um capítulo on-line sobre Consulta por Exemplo (QBE — Query-by-Example) também está disponível. Veja mais informações no Prefácio. Visão Geral sobre Sistemas de Banco de Dados 5 No final da década de 1960, a IBM desenvolveu o SGBD Sistema de Gerenciamento de Informação (IMS — Information Management System), ainda usado atualmente em diversas instalações. O IMS constituiu a base da estrutura de representação al- ternativa de dados, chamada modelo de dados hierárquico. O sistema SABRE para reservas de passagens aéreas foi desenvolvido em conjunto pela American Airlines e pela IBM nessa mesma época, e permitiu que diversas pessoas acessassem os mesmos dados através de uma rede de computadores. Interessante observar que, atualmente, o mesmo sistema SABRE é utilizado para fornecer serviços populares de viagens basea- dos na Web, tais como o Travelocity. Em 1970, Edgar Codd, do Laboratório de Pesquisa de San Jose, da IBM, propôs uma nova estrutura de representação de dados chamada modelo de dados relacional, que veio a ser um marco histórico no desenvolvimento de sistemas de banco de da- dos. Ele impulsionou o rápido desenvolvimento de vários SGBDs baseados no modelo relacional, juntamente com um rico conjunto de resultados teóricos que consolidaram firmemente a área. Codd ganhou o Prêmio Turing de 1981 pelo seu trabalho original. Os sistemas de banco de dados amadureceram como uma disciplina acadêmica, e a popularidade dos SGBDs relacionais alterou o cenário comercial. Seus benefícios fo- ram amplamente reconhecidos, e o uso de SGBDs para gerenciar dados corporativos tornou-se uma prática padrão. Na década de 1980, o modelo relacional consolidou sua posição como o paradigma dominante de SGBD, e o uso dos sistemas de banco de dados continuou a se difundir cada vez mais. A linguagem de consulta SQL para banco de dados relacional, desen- volvida como parte do projeto System R, da IBM, passou a ser a linguagem de consul- ta padrão. A SQL foi padronizada no final dos anos 80, e o padrão atual, SQL:1999 foi adotado pelo American National Standards Institute (ANSI) e pela International Or- ganization for Standardization (ISO). É possível argumentar que a forma mais ampla- mente utilizada de programação concorrente é a execução concorrente de programas de banco de dados (chamados transações). Os usuários escrevem os programas como se eles fossem executar isoladamente, e a responsabilidade de executá-los de forma concorrente é atribuída ao SGBD. James Gray ganhou o Prêmio Turing de 1999 pelas suas contribuições ao gerenciamento de transações de banco de dados. No final da década de 1980 e na década de 1990, houve avanços em diversas áreas dos sistemas de banco de dados. Pesquisas consideráveis foram conduzidas para desen- volver linguagens de consulta mais poderosas e modelos de dados mais ricos, com ênfa- se no suporte à análise complexa de dados provenientes de todas as áreas da empresa. Diversos fabricantes (como o DB2 da IBM, Oracle 8, Informix2 UDS) estenderam seus sistemas com a capacidade de armazenar novos tipos de dados, como imagens e texto, e a possibilidade de consultas mais complexas. Sistemas especializados têm sido desen- volvidos por inúmeros fabricantes para criação de data warehouses, consolidando os dados de diversos bancos de dados, com o intuito de conduzir análise especializada. Um fenômeno interessante é a emergência de diversos pacotes de planejamento de recurso empresarial (ERP — enterprise resource planning) e de planejamento de re- curso de gerenciamento (MRP — management resource planning), que acrescentaram uma camada substancial de recursos orientados a aplicativos acima de um SGBD. Os pacotes largamente utilizados incluem sistemas da Baan, Oracle, PeopleSoft, SAP e Siebel. Esses pacotes identificam um conjunto de tarefas comuns (por exemplo, gerenciamento de inventário, planejamento de recursos humanos, análise financeira) desempenhadas por um grande número de organizações e fornecem uma camada de aplicativogenérica para realizar essas tarefas. O dado é armazenado em um SGBD 2 A Informix foi recentemente adquirida pela IBM. 6 CAPÍTULO 1 relacional, e a camada de aplicativo pode ser customizada para empresas diferentes, diminuindo os custos totais para as organizações, comparados ao custo de criar uma camada de aplicativo a partir do zero. O fato histórico mais significativo, talvez, seja a entrada dos SGBDs na Era Inter- net. Enquanto a primeira geração de web sites armazenava seus dados exclusivamente em arquivos dos sistemas operacionais, o uso de um SGBD para armazenar dados acessados através de um navegador Web tem se difundido cada vez mais. As consultas são geradas através de formulários acessíveis na Web e as respostas são formatadas usando uma linguagem de marcação como o HTML para serem facilmente exibidas em um navegador. Todos os fabricantes de banco de dados estão acrescentando recursos aos seus SGBDs com o objetivo de torná-los mais adequados para desenvolvimento para Internet. O gerenciamento de banco de dados continua a ganhar importância conforme mais e mais dados tornam-se disponíveis on-line e ainda ma is acessíveis através da rede de computadores. Atualmente, a área está sendo impulsionada por ideais excitantes. Entre eles temos: banco de dados multimídia, vídeo interativo, fluxos de dados, biblio- tecas digitais, um hospedeiro de projetos científicos, como o esforço de mapeamento do genoma humano, e o projeto de Sistema de Observação Terrestre da NASA, além do desejo das empresas de consolidar seus processos de tomada de decisão e minerar seus repositórios de dados por informações úteis sobre seus negócios. Comercialmente, os sistemas de gerenciamento de banco de dados representam um dos maiores e mais ativos segmentos de mercado. Assim, o estudo de sistemas de banco de dados pode vir a ser ricamente gratificante e não apenas de uma maneira, mas de várias! 1.3 ARQUIVOS DE SISTEMAS VERSUS UM SGBD Para compreendermos a necessidade de um SGBD, consideremos um cenário motiva- dor: uma empresa tem uma grande coleção (digamos 500 GB3) de dados sobre os fun- cionários, departamentos, produtos, vendas e assim por diante. Esse dado é acessado concorrentemente por diversos funcionários. As consultas sobre os dados devem ser respondidas rapidamente, as alterações realizadas nos dados pelos diferentes usuários devem ser aplicadas consistentemente, e o acesso a determinadas partes dos dados (por exemplo, salários) deve ser restrito. Podemos experimentar gerenciar os dados armazenando-os em arquivos do sistema operacional. Essa abordagem tem várias desvantagens, que incluem: Provavelmente, não teremos 500 GB de memória principal para armazenar todos os dados. Devemos, então, armazenar os dados em um dispositivo de armazenamento, como disco ou fita, e carregar partes relevantes dos dados na memória principal conforme necessário. Mesmo que tivéssemos 500 GB de memória principal, num sistema computacional de 32 bits de endereçamento, não podemos nos referir diretamente a mais do que aproximadamente 4 GB de dados. Temos que programar algum método de identi- ficação de todos os itens de dados. Devemos escrever programas especiais para responder a cada pergunta que um usuário pode desejar fazer sobre os dados. Esses programas provavelmente serão complexos em razão do grande volume de dados a ser pesquisado. 3 Um kilobyte (KB) são 1024 bytes, um megabyte (MB) são 1024 KBs, um gigabyte (GB) são 1024 MBs, um terabyte (TB) são 1024 GBs, e um petabyte (PB) são 1024 terabytes. ■ ■ ■ Visão Geral sobre Sistemas de Banco de Dados 7 Devemos proteger os dados de alterações inconsistentes realizadas por usuários diferentes acessando os dados de forma concorrente. Se os aplicativos devem tratar dos detalhes desse acesso concorrente, isto aumenta significativamente a sua com- plexidade. Devemos assegurar que os dados sejam restaurados a um estado consistente se o sistema falhar enquanto as alterações estão sendo realizadas. Os sistemas operacionais provêm apenas um mecanismo de senha para segurança. Isso não é suficientemente flexível para reforçar as políticas de segurança nas quais usuários diferentes têm permissão de acessar subconjuntos diferentes dos dados. Um SGBD é um pacote de software projetado para executar mais facilmente as tarefas mencionadas anteriormente. Armazenando-se dados em um SGBD em vez de em uma coleção de arquivos do sistema operacional, é possível utilizar os recursos do SGBD para gerenciar os dados de uma forma robusta e eficiente. À medida que cresce o volume de dados e o número de usuários — centenas de gigabytes de dados e milha- res de usuários são comuns nos bancos de dados corporativos atuais —, o suporte de um SGBD torna-se indispensável. 1.4 VANTAGENS DE UM SGBD Usar um SGBD para gerenciar dados tem várias vantagens: Independência de Dados: Os programas aplicativos não devem, idealmente, ser expostos aos detalhes de representação e armazenamento de dados. O SGBD provê uma visão abstrata dos dados que oculta tais detalhes. Acesso Eficiente aos Dados: Um SGBD utiliza uma variedade de técnicas sofisti- cadas para armazenar e recuperar dados eficientemente. Este recurso é especial- mente importante se os dados são armazenados em dispositivos de armazenamen- to externos. Integridade e Segurança dos Dados: Se os dados são sempre acessados através do SGBD, ele pode forçar restrições de integridade. Por exemplo, antes de in- serir informações sobre o salário de um funcionário, o SGBD pode verificar se o orçamento do departamento não está se excedendo. Além disso, ele pode forçar controles de acesso que governam quais dados estão visíveis a diferentes classes de usuários. Administração de Dados: Quando diversos usuários compartilham dados, cen- tralizar a administração dos dados pode oferecer melhorias significativas. Profis- sionais experientes que compreendem a natureza dos dados sendo gerenciados, e como os diferentes grupos de usuários os utilizam, podem ser responsáveis por organizar a representação dos dados para minimizar a redundância e para realizar as sintonizações finas do armazenamento dos dados para garantir uma eficiente recuperação. Acesso Concorrente e Recuperação de Falha: Um SGBD planeja o acesso concor- rente aos dados de maneira tal que os usuários podem achar que os dados estão sendo acessados por apenas um único usuário de cada vez. Além disso, o SGBD protege os usuários dos efeitos de falhas de sistema. Tempo Reduzido de Desenvolvimento de Aplicativo: Obviamente, o SGBD supor- ta funções importantes que são comuns a vários aplicativos que acessam os dados no SGBD. Isso, em conjunto com uma interface de alto nível aos dados, facilita o desenvolvimento rápido de aplicativos. Os aplicativos de SGBD tendem a ser ■ ■ ■ ■ ■ ■ ■ ■ ■ 8 CAPÍTULO 1 mais robustos do que os aplicativos similares independentes porque muitas tarefas importantes são tratadas pelo SGBD (e não precisam ser depuradas e testadas no aplicativo). Dadas todas essas vantagens, há alguma razão para não se utilizar um SGBD? Al- gumas vezes, sim. Um SGBD é um software complexo, otimizado para alguns tipos de processamento (por exemplo, responder a consultas complexas ou tratar várias requisi- ções concorrentes), e seu desempenho pode não ser adequado para determinados apli- cativos especializados. Exemplos incluem aplicativos com restrições rígidas de tempo real ou algumas operações críticas bem definidas para as quais um código customizado eficiente deve ser escrito. Uma outra razão para não se utilizar um SGBD é que o apli- cativo pode precisar manipular os dados de maneiras não suportadas pela linguagem de consulta. Em tais casos, a visualização abstrata dos dados apresentada pelo SGBD pode não corresponder às necessidades do aplicativo e realmente impossibilitar o seu uso. Como um exemplo, os bancos de dados relacionais não suportam a análise flexível de dados textuais (embora os fabricantes estejamatualmente estendendo seus produtos nesta direção). Se o desempenho especializado ou solicitações de manipulação de dados são essen- ciais num aplicativo, pode-se optar por não utilizar um SGBD, especialmente se os benefícios de um SGBD (por exemplo, consulta flexível, segurança, acesso concorrente e recuperação de falha) não forem exigidos. Entretanto, na maioria das situações em que é necessário gerenciamento de dados em grande escala, os SGBDs têm se tornado uma ferramenta indispensável. Encerra aqui o trecho do livro disponibilizado para esta Unidade de Aprendizagem. Na Biblioteca Virtual da Instituição, você encontra a obra na íntegra. ADMINISTRAÇÃO DE BANCO DE DADOS Márcio Motta 4 OBJETIVOS DE APRENDIZAGEM Ao final deste texto, você deve apresentar os seguintes aprendizados: • Identificar os desafios da administração de banco de dados. • Conhecer comandos que auxiliam na administração do banco de dados. • Reconhecer as técnicas de administração de banco de dados. INTRODUÇÃO O banco de dados é um dos elementos da administração de um ambiente de informação. Para um usuário final a organização do banco de dados é invisível, apenas aparecendo os seus resultados quando este é bem formatado e executado. No caso de problemas, o usuário final identificará dados inconsistentes ou problemas com a sua performance, mas não visualizando o banco de dados em si. Três áreas continuam a ser os maiores desafios de gerenciamento para os administradores de banco de dados. São elas. TECNOLOGIAS Nos últimos anos, o surgimento de forças, como a TI híbrida, virtualização, computação em nuvem, convergência continuada de infraestrutura e BYOD (traga seu próprio dispositivo) ofereceram aos profissionais de tecnologia novas formas de trabalhar, revolucionando o modelo tradicional até então praticado na área. A expectativa é de que as pessoas que trabalham nessa área consigam colocar em prática conceitos e tendências tecnológicas, como bancos de dados embutidos, Internet das Coisas (IoT) e Cloud Computing, mas sem deixar de lado as habilidades de gerenciar tecnologias e infraestruturas tradicionais. Cabe ao Administrador de Banco de Dados e sua equipe considerarem as possibilidades para então definir o uso de SGBD físico ou a utilização de um serviço na nuvem, sobre essa decisão pesarão diversos fatores que deverão ser analisados antes de tomar uma decisão final. O mesmo vale para o tipo de SGBD escolhido de acordo com as suas características, funções, desempenho e custos. 5 Com sua promessa de economia de custos e maior flexibilidade e agilidade, a Nuvem está atraindo muitas organizações como uma alternativa para a implantação de novos aplicativos, incluindo aqueles com altos requisitos de desempenho de banco de dados. Entretanto, essa transição cria novas complexidades e desafios para os DBAs, especialmente porque os DBAs ainda são, em última análise, os responsáveis tanto pelo desempenho dos bancos de dados quanto pela segurança dos dados, independentemente de eles estarem nas próprias instalações ou na nuvem. São algumas considerações para o gerenciamento dos dados na nuvem que os DBAs devem ponderar antes de sua escolha: • Ao considerar quais bancos de dados são migrados para a nuvem, levar em conta o processo de transferência de dados e a latência, além de como manter os bancos de dados em sincronia, se necessário, especialmente se for preciso integrar os aplicativos com outros que não residam na mesma implantação na nuvem. • Um banco de dados com desempenho insatisfatório nas instalações também apresentará um mau desempenho na nuvem. Mudar o problema de lugar não é solução. O escalonamento na nuvem para compensar um mau desempenho pode sair caro rapidamente, além de ser a abordagem incorreta. • Entender os serviços e as capacidades do provedor de serviços, avaliar a arquitetura recomendada e estar atento à manutenção programada. • Refletir, planejar e gerencar o backup e recuperação para garantir que dados importantes não sejam perdidos caso ocorra uma falha ou interrupção no fornecedor. • Mantenha-se à frente da segurança, percebendo que a criptografia é apenas a ponta do iceberg – considere quem monitorará o acesso ao banco de dados impedindo o acesso mal-intencionado ou não autorizado, prepare- se para o pior e tenha um plano de ação documentado para o caso de violação da segurança ou perda de dados. • Se é importante monitorar e otimizar as implantações nas instalações, isso é ainda mais importante na nuvem, dada sua natureza dinâmica, sendo ideal usar um conjunto de ferramentas consistente em ambos os lados dos ambientes de TI híbrida. 6 A Figura 1 a seguir procura relatar o ranking dos SGBDs mais utilizados e traçar uma relação entre as suas tecnologias: Figura nº 1 – Ranking dos SGBDs Fonte: Austrian IT Consulting, disponível em: http://db-engines.com/en/ Acesso em: 28/05/2017 Nas 4 primeiras posições desse ranking são vistos 2 modelos de SGBDs de licença proprietária (Oracle e SQL Server) e 2 de licença Open Source (Livre, de código aberto, MySQL e MondoDB). O MondoDB vem em forte crescimento no mercado mundial, ocupando já a quarta posição superando o também bastante utilizado PostreSQL. Um dos motivos dessa ascensão é o fato do MongoDB não trabalhar com o modo Relacional de tabelas como os outros SGBDs, mas com um sistema de Índices também conhecido como NO-SQL. PERFORMANCE A performance do banco de dados é um fator de grandes desafios para o BDA. O conjunto que envolve Hardware+Sistema+SGBD deve estar equacionado para uma performance satisfatória. Porém, conforme o crescimento e a demanda das informações armazenadas essa tarefa torna-se cadê vez mais complexa. Muitas vezes a escolha inicial de infraestrutura pode não ser mais suficiente, não atendendo as demandas necessárias necessitando de migração ou atualização, ou a sua manutenção e configuração não 7 estão ocorrendo de forma organizada e coerente com as necessidades da plataforma, causando transtornos e inconsistências. A modelagem dos dados e a construção de consultas otimizadas são extremamente importantes no desempenho do banco de dados. Campos mal definidos, com tamanhos de dados equivocados tanto para textos quanto para números são determinantes para a performance, toda a definição dos dados (DDL) deve ser dimensionada para o tipo de dado que cada registro receberá. O mesmo vale para a organização das consultas. Índices e constraints (restrições) já devem ser criados na etapa de definição para que possam ser utilizadas de forma ágil durante a manipulação dos dados(DML) com consultas simplificadas e de resultados diretos. Muitas vezes uma base possui milhares ou até milhões de registros, se uma consulta não for restrita ao que se deseja, o tempo de espera poderá ser bastante demorado, prejudicando todo o sistema. Uma das formas de monitorar o desempenho de um SGBD (MySQL neste exemplo) é através da ferramenta MYTOP (Linux/Open Source). Para usá-la é necessário executar o comando: mytop -u <usuario> -p <senha> -h <host> Ao executá-lo, serão mostradas todas as informações dos bancos de dados armazenados assim como os tempos de acesso e possíveis problemas, como são apresentados na Figura 2 abaixo: Figura nº 2 – Tela do MyTOP no Linux Fonte: autor 8 Um erro bastante comum é se preocupar com segurança e desempenho apenas diante da reclamação dos usuários de um dado alterado indevidamente ou lentidão na utilização do sistema, pois um monitoramento pontual não terá fundamento para mostrar que o banco de dados não é o culpado. É necessário monitoramento e relatórios constantes que auxiliem o DBA a identificar gargalos, tomando as ações necessárias preventivamente, ou mesmo comprovando que o problema não está no banco de dados, podendo direcionar o tratamento do problema para o local correto. SEGURANÇA A preocupação com a criação e manutenção de ambientes seguros se tornou a ocupação principalde administradores de redes, de sistemas operacionais e de bancos de dados. Pesquisas mostram que a maioria dos ataques, roubos de informações e acessos não- autorizados são feitos por pessoas que pertencentes à organização alvo. De modo geral, os mecanismos de segurança referem-se às regras impostas pelo subsistema de segurança do SGBD, que verifica todas as solicitações de acesso, comparando-as com as restrições de segurança armazenadas no catálogo do sistema. Entretanto existem brechas no sistema e ameaças externas que podem resultar em um servidor de banco de dados comprometido ou na possibilidade de destruição ou no roubo de dados confidenciais. As ameaças aos bancos de dados podem resultar na perda ou degradação de alguns ou de todos os objetivos de segurança aceitos, são eles: integridade, disponibilidade, confidencialidade. A integridade do banco de dados se refere ao requisito de que a informação seja protegida contra modificação imprópria. Os bancos de dados SQL implementam mecanismos que restringem ou permitem acessos aos dados de acordo com papeis ou roles fornecidos pelo administrador. O comando GRANT concede privilégios específicos para um objeto (tabela, visão, seqüência, banco de dados, função, linguagem procedural, esquema ou espaço de tabelas) para um ou mais usuários ou grupos de usuários. São tipos de controles que podem ser implementados para garantir maior segurança nos bancos de dados: 9 Controle de Acesso É todo controle feito quanto ao acesso ao BD, impondo regras de restrição, através das contas dos usuários. O DBA é o responsável superior por declarar as regras dentro do SGBD. Ele é o responsável por conceder ou remover privilégios, criar ou excluir usuários, e atribuição de um nível de segurança aos usuários do sistema, de acordo com a política da empresa. Controle de Inferência É um mecanismo de segurança para banco de dados estatísticos que atua protegendo informações estatísticas de um individuo ou de um grupo. Bancos de dados estatísticos são usados principalmente para produzir estatísticas sobre várias populações. O banco de dados pode conter informações confidenciais sobre indivíduos. Os usuários têm permissão apenas para recuperar informações estatísticas sobre populações e não para recuperar dados individuais, como, por exemplo, a renda de uma pessoa específica. Controle de Fluxo É um mecanismo que previne que as informações fluam por canais secretos e violem a política de segurança ao alcançarem usuários não autorizados. Ele regula a distribuição ou fluxo de informação entre objetos acessíveis. Um fluxo entre o objeto A e o objeto B ocorre quando um programa lê valores de A e escreve valores em B. Os controles de fluxo têm a finalidade de verificar se informações contidas em alguns objetos não fluem explicita ou implicitamente para objetos de menor proteção. Dessa maneira, um usuário não pode obter indiretamente em B aquilo que ele ou ela não puder obter diretamente de A. Criptografia de Dados Você pode ler aqui um pouco mais sobre criptografia. É uma medida de controle final, utilizada para proteger dados sigilosos que são transmitidos por meio de algum tipo de rede de comunicação. Ela também pode ser usada para oferecer proteção adicional para que partes confidenciais de um banco de dados não sejam acessadas por usuários não autorizados. Para isso, os dados são codificados através da utilização de algum algoritmo de codificação. Assim, um usuário não autorizado terá dificuldade para decifrá- los, mas os usuários autorizados receberão chaves para decifrar esses dados. A criptografia permite o disfarceda mensagem para que, mesmo com o desvio da transmissão, a mensagem não seja revelada. 10 Privilégios Os privilégios são permissões únicas dadas a cada usuário ou grupo. Eles definem permissões para tipos de autorização. Pelos privilégios é possível autorizar o usuário a modificar ou alcançar determinado recurso do Banco de Dados. O SGBD deve oferecer acesso seletivo a cada relação do banco de dados baseando-se em contas específicas. As operações também podem ser controladas; assim, possuir uma conta não necessariamente habilita o possuidor a todas as funcionalidades oferecidas pelo SGBD. Informalmente existem dois níveis para a atribuição de privilégios para o uso do sistema de banco de dados: • Nível de conta: Nesse nível, o DBA estabelece os privilégios específicos que cada conta tem, independente das relações no banco de dados. • Nível de relação (ou tabela): Nesse nível, o DBA pode controlar o privilégio para acessar cada relação ou visão individual no banco de dados. Em alguns casos, interessa conceder um privilégio temporário a um usuário. Por exemplo, o proprietário de uma relação pode querer conceder o privilégio SELECT a um usuário para uma tarefa específica e depois revogar aquele privilégio quando a tarefa estiver completada. Por isso, é necessário um mecanismo para a revogação de privilégios. Em SQL, um comando REVOKE é introduzido com o intento de cancelar privilégios. 11 REFERÊNCIAS Embarcadero - Database Trends Survey Report. Disponível em: http://www. embarcadero.com/images/dm/technical-papers/database-survey-report. pdf. Acessado em: 28 de maio de 2017. PFLEEGER, Charles P.; PFLEEGER, Shari L. - Security in computing. 4ª ed. Massachusetts: Editora Prentice Hall, 2012. SHASHA, DENNIS, BONNET, PHILIPPE - Database Tuning, Morgan Kaufmann Publishers, 2003. FUNDAMENTOS COMPUTACIONAIS Ramiro Córdova Júnior Banco de dados Objetivos de aprendizagem Ao final deste texto, você deve apresentar os seguintes aprendizados: � Conceituar banco de dados. � Identificar os tipos de banco de dados. � Classificar os tipos de linguagens de bancos de dados. Introdução Atualmente, os sistemas de informação são desenvolvidos juntamente com uma base de dados. Essa base é responsável por gerenciar a manipu- lação dos dados utilizados. Por isso, é fundamental que os profissionais da área de desenvolvimento de sistemas tenham o conhecimento adequado sobre os bancos de dados. Assim, esses profissionais podem integrar sistemas e bancos de dados de maneira conveniente. Neste capítulo, você vai conhecer a definição de banco de dados, associando-a a exemplos. Além disso, vai ver os diferentes tipos de banco de dados e a linguagem utilizada neles. Conceito de banco de dados Um banco de dados é uma coleção de informações organizadas para que possam ser facilmente acessadas, gerenciadas e atualizadas. Os dados são organizados em linhas, colunas e tabelas e são indexados para facilitar a localização de informações relevantes. Os dados são atualizados e excluídos à medida que novas informações são adicionadas. Os bancos de dados pro- cessam informações e permitem a consulta dos dados armazenados. Além disso, permitem a execução de aplicações na base de dados. Os bancos de dados computacionais geralmente contêm registros agrega- dos ou arquivos de dados, que representam transações de vendas, catálogos de produtos, inventários, perfis de clientes, etc. Normalmente, um sistema gerenciador de banco de dados (SGBD) fornece aos usuários a capacidade de controlar o acesso de leitura/gravação, definir a geração de relatórios e realizar procedimentos de análise dos dados. Bancos de dados são predomi- nantes em grandes sistemas de mainframe, mas também estão presentes em estações de trabalho distribuídas menores e sistemas de médio porte, como em computadores pessoais. Um banco de dados pode ser considerado um software estruturado para coletar e armazenar informações que possam ser recuperadas, adicionadas, atualizadas ou removidas de maneira automática. Os programas de banco de dados são aplicativos projetados para que os usuários criem bancos de dados e toda a programação necessária para preenchê-los ou excluí-los, conforme necessário. A estrutura de um banco de dados (Figura 1) é baseada em tabelas, que consistem em linhas e colunas de informações.As colunas identificam os dados (atributos) na tabela e as linhas são os registros de informações. As tabelas se parecem com uma planilha, mas podem ser manipuladas e atuali- zadas de uma forma que as planilhas não podem. Como você pode imaginar, isso torna um banco de dados uma ferramenta muito valiosa. Figura 1. Estrutura do banco de dados. NumEmp NomeEmp Salário Dept 032 074 089 092 112 121 130 J Silva M Reis C Melo R Silva R Pinto V Simão J Neves 380 400 520 480 390 905 640 21 25 28 25 21 28 28 Linhas Colunas Uma estrutura de banco de dados é definida pelo modelo de banco de dados. O modelo mais usado é o modelo de banco de dados relacional. Nesse modelo, as tabelas devem relacionar-se ou vincular-se umas às outras. Cada tabela contém informações específicas ou atributos (colunas) para cada registro (linha). Por exemplo, um banco de dados de uma clínica veterinária pode ter uma tabela Pacientes — com colunas intituladas Nome do paciente, Tipo de paciente e Banco de dados174 Número de ID — e uma segunda tabela chamada Proprietário do paciente — com as colunas intituladas Número de identificação, Nome do proprietário, Endereço do proprietário e Número de telefone do proprietário. A primeira tabela é vinculada à segunda tabela pelo número de ID. O relacionamento do número de ID permite a localização de registros dos pacientes vinculando com seus proprietários, retornando uma resposta precisa na realização de consultas no banco de dados. O projeto de um banco de dados deve ser baseado nos requisitos de negócio. Os requisitos de negócio, por sua vez, devem ser perfeitamente compreendidos antes que um banco de dados seja projetado. Os requisitos de negócio também podem ser chamados de regras de negócios. As tabelas devem conter no máximo um conjunto de informações. No caso do exemplo anterior, a tabela Paciente não deve conter informações sobre as visitas dos pacientes. Em vez disso, uma tabela separada manteria um número de ID de visita e a data e a hora da visita, juntamente com o número de ID do paciente, para vincular os dois. Uma quarta tabela, intitulada Faturamento, seria criada para identificar o valor do pagamento, o tipo de pagamento e o ID da visita, que está sendo pago juntamente com o ID do paciente. As tabelas Faturamento e Visitas fazem parte da regra de negócio. A inserção de registros preenche um banco de dados com dados. Depois que o banco de dados é estruturado corretamente, uma interface é construí da. Essa interface é colocada entre as tabelas e o usuário. A interface dá ao usuário uma visão diferente do banco de dados. Usando o exemplo da clínica veterinária, uma interface pode fornecer ao usuário uma página de entrada chamada Novo usuário. Nessa página, o usuário pode inserir o nome e o tipo do animal de estimação, as informações do proprietário e a data e o tipo da primeira visita. Todas essas informações estão contidas em três tabelas diferentes localizadas atrás da interface, mas o usuário só precisa interagir com a página de entrada (um único formulário), enquanto os dados são armazenados nas tabelas corretas. Isso é conseguido conectando as tabelas por meio de recursos de programação. Acesse o link a seguir e leia mais sobre conceitos de banco de dados. https://goo.gl/faJXMp 175Banco de dados Tipos de banco de dados Segundo Geremia (2010), são quatro os tipos de banco de dados existentes: (1) banco de dados relacional; (2) banco de dados hierárquico; (3) banco de dados em rede; e (4) banco de dados objeto-relacional. A seguir, você vai conhecer melhor cada um deles. Banco de dados relacional O banco de dados do tipo relacional funciona como uma coleção de relações, em que cada linha representa um conjunto de dados relacionados entre si. Os dados contidos em uma linha do banco de dados representam fatos do mundo real. Um banco de dados relacional é uma coleção de itens de dados organizados como um conjunto de tabelas formalmente descritas. A partir desse conjunto, os dados podem ser acessados ou remontados de muitas maneiras diferentes sem a necessidade de se reorganizarem as tabelas do banco de dados. Além de ser relativamente fácil de se criar e acessar, um banco de dados relacional tem a importante vantagem de ser fácil de estender. Após a criação do banco de dados original, uma nova categoria de dados pode ser adicionada sem a exigência de que todos os aplicativos existentes sejam modificados. Um banco de dados relacional é um conjunto de tabelas contendo dados ajustados em categorias predefinidas. Cada tabela contém uma ou mais ca- tegorias de dados nas colunas. Cada linha contém uma instância única de dados para as categorias definidas pelas colunas. Por exemplo, um banco de dados de entrada de pedidos comerciais típico incluiria uma tabela que descreve um cliente com colunas para nome, endereço, número de telefone e assim por diante. Outra tabela descreveria um pedido: produto, cliente, data, preço de venda e assim por diante. Um usuário do banco de dados poderia obter uma visão do banco de dados que atendesse às suas necessidades. Por exemplo, um gerente da filial poderia gostar de visualizar ou relatar todos os clientes que compraram produtos após determinada data. Já um gerente de serviços financeiros da mesma empresa poderia, nas mesmas tabelas, obter um relatório sobre as contas que precisam ser pagas. Banco de dados hierárquico Um banco de dados hierárquico usa diferentes níveis de dados que seguem um padrão semelhante a uma hierarquia. Em outras palavras, você começa Banco de dados176 em uma tabela e, dependendo do registro consultado, obtém acesso a outras tabelas de informações. No entanto, essas tabelas são vinculadas apenas à tabela acima ou à tabela abaixo. Isso as torna incrivelmente úteis para coletar informações que seguem uma ordem específica. Bancos de dados hierárquicos são úteis quando duas condições são aten- didas. Em primeiro lugar, os dados devem seguir um padrão hierárquico (Figura 2). Isso significa que deve haver relacionamentos entre os dados que poderiam estar “empilhados”, como em uma árvore genealógica. Em segundo lugar, os dados que estão sendo empilhados devem estar acessíveis apenas por meio de um único caminho. Figura 2. Hierarquia em bancos de dados. Fábrica Financeiro Comercial Injeção Extrusão Pagar Receber Contábil Vendas Marketing Paulo Vinícius Vilma Sílvia João Pedro Carlos Banco de dados em rede O banco de dados em rede (Figura 3) é um modelo de banco de dados que permite que vários registros sejam vinculados ao mesmo arquivo de proprietário. O modelo pode ser visto como uma árvore invertida, onde os ramos são as informações do membro ligadas ao proprietário, que é a parte inferior da árvore. As múltiplas conexões permitem que o banco de dados de rede seja muito flexível. Além disso, a relação que a informação tem com o banco de dados de rede é definida como relação muitos para muitos, porque um arquivo proprietário pode ser vinculado a vários arquivos de membros e vice-versa. 177Banco de dados Figura 3. Rede de banco de dados. Departamento Empregado 032 J Silva 380 074 M Reis 400 089 C Melo 520 092 R Silva 480 112 R Pinto 390 121 V Simão 905 130 J Neves 640 21 Pessoal 142 25 Financeiro 143 28 Técnico 144 Banco de dados objeto-relacional O modelo relacional de objeto é projetado para fornecer um gerenciamento de banco de dados relacional que permite aos desenvolvedores integrar bancos de dados com seus tipos e métodos de dados. É essencialmente um modelo relacional que permite aos usuários integrarem nele recursos de programação orientada a objetos. A principal função desse tipo de banco de dados é dar maior flexibilidade, melhor desempenho e maior integridade de dados que os demais tipos de bancode dados. A seguir, você pode ver alguns dos benefícios proporcionados pelo banco de dados objeto-relacional. � Expansibilidade: é possível ampliar a capacidade do servidor de banco de dados. Isso pode ser feito definindo novos tipos de dados, bem como por meio de padrões definidos pelo usuário. Esse recurso permite que o usuário armazene e gerencie dados. � Tipos de dados complexos: os usuários podem definir novos tipos de dados que combinam um ou mais tipos de dados existentes no momento. Os tipos complexos garantem melhor flexibilidade na organização dos dados em uma estrutura composta de colunas e tabelas. � Herança: os usuários podem definir objetos ou tipos e tabelas que adquirem as propriedades de outros objetos, além de adicionar novas propriedades específicas ao objeto que foi definido. Banco de dados178 Leia mais sobre sistemas de banco de dados na obra “Sistemas de banco de dados” (ELMASRI, R.; NAVATHE, S. B., 2005). Linguagens de banco de dados Um sistema gerenciador de banco de dados deve prover linguagens e inter- faces apropriadas para que cada categoria de usuários realize consultas e atualizações no banco de dados. As linguagens de banco de dados são usadas para a criação e a manutenção do banco de dados. Há um grande número de linguagens de banco de dados, como Oracle, MySQL, MS Access, dBase, FoxPro, etc. As instruções SQL usadas em um banco de dados podem ser categorizadas como linguagem de definição de dados (DDL), linguagem de controle de dados (DCL) e linguagem de manipulação de dados (DML). Você vai conhecer melhor cada uma delas a seguir. Linguagem de definição de dados (DDL) É uma linguagem que permite aos usuários definir dados e sua relação com outros tipos de dados. É usada principalmente para criar arquivos, bancos de dados, dicio- nário de dados e tabelas dentro de bancos de dados. Também serve para especificar a estrutura de cada tabela, o conjunto de valores associados a cada atributo, as restrições de integridade, as informações de segurança e autorização para cada tabela e o armazenamento físico da estrutura de cada tabela no disco. A seguir, você pode ver uma lista de instruções SQL que são categorizadas como DDL. � Para criar a instância do banco de dados — CREATE � Para alterar a estrutura do banco de dados — ALTER � Para descartar instâncias do banco de dados — DROP � Para excluir tabelas em uma instância de banco de dados — TRUNCATE � Para renomear instâncias do banco de dados — RENAME Linguagem de manipulação de dados (DML) É uma linguagem que fornece um conjunto de operações para suportar as operações básicas de manipulação nos dados mantidos nos bancos de dados. 179Banco de dados As instruções DML permitem que os usuários insiram, atualizem, excluam e recuperem dados do banco de dados. A parte do DML que envolve a recu- peração de dados é chamada de linguagem de consulta. A seguir, você pode ver algumas instruções SQL que são do tipo DML. � Para buscar registros da(s) tabela(s) — SELECT � Para inserir registros na(s) tabela(s) — INSERT � Para atualizar os dados na(s) tabela(s) — UPDATE � Para excluir os registros da tabela — DELETE Linguagem de controle de dados (DCL) As instruções do tipo DCL controlam o acesso aos dados e ao banco de dados usando instruções SQL como GRANT e REVOKE. Um privilégio pode ser concedido a um usuário com a ajuda da instrução GRANT. Os privilégios atribuídos podem ser instruções do tipo SELECT, ALTER, DELETE, EXE- CUTE, INSERT, INDEX, etc. Além da concessão de privilégios, também é possível revogar usando o comando REVOKE. Na prática, as linguagens de definição de dados e de manipulação de dados não são separadas. Em vez disso, elas formam partes de uma única linguagem de banco de dados, como SQL (Structured Query Language). O SQL representa uma combinação de DDL e DML, além de instruções para especificação de restrições e avaliação de esquemas. GEREMIA, J. Tutorial de introdução a banco de dados. 2010. Disponível em: <http:// www.telecom.uff.br/pet/petws/downloads/tutoriais/db/Tut_DB.pdf>. Acesso em; 22 abr. 2018. Leituras recomendadas ELMASRI, R.; NAVATHE, S. B. Sistemas de banco de dados. São Paulo: Pearson, 2005. REZENDE, R. Conceitos fundamentais de banco de dados. [201-?]. Disponível em: <ht- tps://www.devmedia.com.br/conceitos-fundamentais-de-banco-de-dados/1649>. Acesso em; 22 abr. 2018. SANTANCHÈ, A.; CAVOTO, P. Banco de dados. Campinas: [S.n.], (2013). Referência Banco de dados180 MODELAGEM E DESENVOLVIMENTO DE BANCO DE DADOS Fabrício Felipe Meleto Barboza Conceitos de banco de dados Objetivos de aprendizagem Ao final deste texto, você deve apresentar os seguintes aprendizados: � Identificar a importância da utilização do banco de dados no contexto organizacional. � Reconhecer as principais ferramentas de administração de banco de dados. � Relacionar os principais ambientes de banco de dados. Introdução Neste capítulo, você vai estudar a necessidade do uso de banco de dados no lugar de outra forma de guardar as informações, como, por exemplo, planilhas eletrônicas ou documentos de textos. Adicionalmente, você também conseguirá vislumbrar a diferença entre os sistemas de bancos de dados existentes atualmente, suas apli- cações mais comumente utilizadas nas corporações em geral e, também, os aspectos positivos e negativos de cada opção de uso dos sistemas abordados. Necessidade de uso dos bancos de dados Imagine que você trabalha em uma pequena loja que tem como principal fonte de receita a comercialização de capinhas de celulares. A cada entrada de mercadoria no estoque ou baixa ao realizar uma venda, é registrada a respectiva ação em um caderno de registros. Tome por base que essa lojinha venda uma capinha de celular por dia: ao longo de um mês, haverá 30 registros de venda e de 2 a 3 registros de entrada de mercadoria. Bem fácil controlar na caderneta, certo? Mas então o dono da lojinha recebeu uma herança e resolveu comprar um espaço no shopping mais movimentado da cidade para expandir os negócios. De 30 capinhas ao mês, agora a venda aumentou para três mil capinhas. O seu trabalho de registro na caderneta começou a ficar complexo e a tomar cada vez mais tempo do seu dia. Para resolver o problema, um sobrinho do dono da loja fez uma planilha eletrônica linda, cheia de fórmulas e que resolve mais rapidamente seu problema de cadastro. Como um excelente homem de negócios, seu chefe resolveu abrir 20 filiais novas. Temos, então, 60 mil registros de venda de capinhas mais os registros de entrada de estoque por mês. Se colocarmos que a quantidade de linhas que uma planilha eletrônica suporta atualmente é cerca de um milhão, você iria enchê-la em menos de 18 meses (ou um ano e meio). Além disso, essa planilha ocuparia muito espaço no computador e você levaria muito tempo para recuperar as informações inseridas ali em cada momento de venda. Então você se cansa de trabalhar nessa loja, entra em uma empresa de tele- fonia multinacional e se pega imaginando quantas planilhas eles possuem para controlar todas as ligações que seus clientes fazem a cada minuto. Segundo a ANATEL (BRASIL, 2018), a quantidade de linhas telefônicas fixas no Brasil já passou a marca de 40 milhões e meio. Coloque nessa equação a quantidade de linhas telefônicas móveis (celulares) e temos o caos das planilhas eletrônicas. A solução para qualquer um dos casos apresentados, desde a lojinha que vendia 30 capinhas de celular por mês até a grande companhia telefônica com milhões de novos registros que precisam ser processados a cada segundo, é uma só: banco de dados. Acesse o link a seguir e leia a notícia da ANATEL, que apresenta a enorme quantidade de linhas fixas existentes em todos os estados brasileiros. https://goo.gl/6wcb8D Da mesma forma, a atividade pertinente a qualquer área de uma organização requer um poder grande de armazenamento de informações, ordenação, busca e edição. Pense em um sistema on-linepopular qualquer, como, por exemplo, o Conceitos de banco de dados2 Facebook. Inúmeros bancos de dados são utilizados para prover a plataforma da rede social, cada qual com seu objetivo: um banco de dados somente para o cadastro dos usuários, outro banco de dados para as postagens dos usuários, um terceiro banco de dados para armazenar as fotos dos usuários, mais outro banco de dados para o feed de notícias, um quinto banco de dados para o chat da plataforma, etc. Cada sistema tem sua própria divisão de banco de dados, mas você pode ter certeza de que é necessário um ou mais banco de dados para suportar um blog, por mais simplista que possa parecer — até mesmo para grandes plata- formas, como Facebook, LinkedIn, Instagram, WhatsApp, Twitter, sistemas bancários e demais sistemas. Quando você efetua a compra de um produto qualquer para o qual é emitida uma nota fiscal eletrônica, o fluxo de funcionamento daquele ponto de venda (PDV) com a ação do colaborador do estabelecimento ao registrar seu CPF na nota, por exemplo, seria o que está visualmente representado na Figura 1. Figura 1. Fluxo de relações entre banco de dados. Vendedor realiza a venda e insere o CPF do comprador no sistema da loja O sistema de banco de dados da loja: 1. Baixa a quantidade vendida 2. Veri�ca se atingiu o limite mínimo de estoque e alerta o gerente 3. Conclui a venda e envia sinal para emissão da nota �scal O banco de dados da Receita Estadual ou Federal recebe a solicitação de emissão de nota e: 1. Confere se o sistema da loja está apto a realizar a venda 2. Pega a informação do CPF informado e consulta se é válido 3. Realiza os cálculos de impostos em cima da venda para a exibição no cupom �scal 4. Cadastra a nota/cupom �scal na base de dados 5. Informa o sistema CPF na nota desta nova compra daquele CPF O banco de dados do sistema de CPF na nota: 1. Recebe a emissão da nova nota e grava no banco de dados 2. Calcula o valor de retorno de crédito para o consumidor 3. Disponibiliza a consulta desse crédito no seu sistema on-line 4. Caso tenha, insere cupons para participar de sorteios de prêmios Sendo assim, com a utilização de banco de dados, tanto o cadastro de novos registros, como a venda de uma capinha de celular do exemplo anterior, quanto 3Conceitos de banco de dados uma nova ligação por parte do cliente da grande companhia telefônica resulta em um novo registro no próprio banco de dados — portanto, uma nova linha da “planilha”. Como os bancos de dados, em sua maioria, estão conectados aos sistemas, esse registro é feito de forma automática e é garantida a integridade da informação. Imagine o sistema de uma loja virtual ou sites de compra e venda. O relacionamento entre bancos de dados ocorre por segundo, muitas vezes, para o envio, troca, edição, exclusão e informe de operações. Sites como o do Mercado Livre, por exemplo, precisam de um banco de dados robusto e confiável. Como administrar um banco de dados A questão da administração de um banco de dados é ampla e complexa, sendo debatida por diversos autores. Em resumo, você deve ter conhecimento de que tipo de informação está alocada nas tabelas do seu banco de dados e, principalmente, como manipular as informações que ali estão inseridas da forma que necessita. Um sistema de banco de dados é formado pelo software de banco de dados, o repositório de tabelas denominado database e as próprias tabelas em si ou tables. Dessa forma, um banco de dados para um sistema de agenda telefônica teria o serviço do banco de dados executado, uma database e, dentro desta, estariam as tabelas para gravar as informações de nome, endereço, contato telefônico, e-mail, aniversário, foto, etc. Portanto, para você conseguir realizar uma boa administração do banco de dados, é necessário conhecer o negócio ou o projeto ao qual ele servirá. De nada adianta ter tabelas que não são necessárias, pois isso impacta na performance do serviço. No exemplo da agenda telefônica, se não existisse o campo “contato telefônico”, o sistema ficaria inútil, pois uma agenda tele- fônica precisa, obrigatoriamente, conter o campo para cadastro do telefone do contato. Conceitos de banco de dados4 No exemplo da agenda telefônica, existem campos obrigatórios e campos opcionais. Os campos “nome” e “contato telefônico” são obrigatórios. Já os campos “endereço”, “e-mail”, “aniversário” e “foto” são opcionais. Essa diferenciação se deve ao fato de que uma agenda telefônica precisa, no mínimo, gravar o nome e o telefone de contato da pessoa. Portanto, o banco deve respeitar essa regra para ser bem construído. Como passo fundamental na administração correta de um banco de dados, é essencial que você tenha a documentação base do sistema que utilizará do banco de dados sob sua administração. Esse documento contemplará a modelagem do banco de dados, os relacionamentos entre tabelas, como será gravada cada informação, quais campos são obrigatórios e quais são opcionais, a necessidade de indexação para melhorar a velocidade de consulta, etc. A seguir, na Figura 2, você verá um exemplo simples de uma modelagem de banco de dados, na forma de entidade-relacionamento, para compreensão. Essa forma de ilustração do banco de dados é a mais comumente utilizada em documentações e projetos. Nela, cada retângulo representa uma tabela, cujo título é o seu nome. Para cada tabela, há uma relação de atributos (linhas abaixo do título) e linhas ligando essas tabelas, que representam os relacionamentos entre elas. Por ora, você precisa atentar para o nome e cada atributo das tabelas a seguir, pois iremos estudar esse e outros modelos de banco de dados mais adiante. Figura 2. Exemplo de banco de dados. Cliente Nome Telefone Endereço Cidade Estado CPF Código Nome Preço Qtd Estoque Produto Venda Código CPF_Cliente Código_produto Data Valor Código_nfe 5Conceitos de banco de dados Note que existem três tabelas ou tables no banco de dados da Figura 2: tabela “Cliente”, tabela “Produto” e tabela “Venda”. O relacionamento entre elas é executado quando o colaborador registra uma venda; então, o banco de dados cria um registro na tabela “venda” contendo os dados do produto comprado e os do cliente que comprou. Cada tabela tem atributos próprios, que seriam suas colunas, nas quais ficam as informações correspondentes. Ou seja, pela tabela “Cliente” foi mapeado que o cadastro de cliente terá os campos “Nome”, “Telefone”, “Endereço”, “Cidade”, “Estado” e “CPF”. Já na tabela “Produto”, os atributos (colunas) são “Código”, “Nome”, “Preço” e “Quantidade Estoque”. Por fim, temos a tabela “Venda” com os atributos (colunas) “Código”, “CPF_cliente”, “Código_produto”, “Data”, “Valor” e “Código_nfe”. Para otimizar a quantidade de registros no banco de dados, existe a chave primária e a chave estrangeira. A chave primária é um campo que é definido como único e não pode repetir-se naquela tabela. Como exemplo de chave primária para a tabela “Cliente”, pode-se utilizar o CPF, que é um número único por pessoa (ninguém no Brasil tem o mesmo CPF que o seu). Para a tabela “Produto”, foi criado um atributo chamado “Código”. Já a tabela “Venda” pode usar o seu campo “Código”. A chave estrangeira ocorre quando pegamos um atributo de outra tabela que é chave primária nela. Veja novamente a Figura 2 e observe que, na tabela “Venda”, existem duas possíveis chaves estrangeiras: “CPF_cliente”, que vem da tabela “Cliente”, e “Código_produto”, que vem da tabela “Produto”. Isso se dá para que, quando alguém pedir relatório de vendas, ao consultar a tabela “Venda”, o sistema consiga buscar, por meio do campo “CPF_cliente”, os dados do cliente na tabela “Cliente” e os dados do produto por meio do campo “Código_produto” na tabela “Produto”. A dúvida que surge é a de por que realizar esses relacionamentos e não simplesmente criar mais atributos na tabela “Venda” para comportar os dados do cliente e dos produtos nessa própria tabela. A resposta é bem simples: