Para quem estava com saudades, vamos voltar a falar de Banco de Dados hoje, uma das disciplinas mais cobradas na área de Tecnologia da Informação (TI). Neste artigo, você terá a oportunidade de aprender ou revisar (se já conhece o assunto) modelagem de dados.
O tópico é bem antigo, mas nunca sai de moda. Resolvemos abordar o tema porque as bancas continuam cobrando nas provas e os concurseiros ainda têm muitas dúvidas a respeito do tema. Veja o nosso roteiro:
Não deixe de ler o artigo caso esteja estudando para concursos específicos de TI ou concursos gerais que cobrem a disciplina de Banco de Dados. Para entender o conteúdo, será importante ter noções básicas da disciplina.
Preparamos um artigo objetivo, a fim de que você consiga ter acesso ao conteúdo necessário em poucos minutos. Hoje será um desafio porque temos muita coisa importante para falar. Aliás, já vamos começar.
Tempo de leitura aproximada: 5 a 10 minutos
Quando você pensa em criar um sistema, é importante planejar como seus dados serão armazenados. Não basta simplesmente criar uma tabela no banco de dados com um monte de campos e cadastrar os registros lá. Os objetos precisam ter uma relação semântica e estrutural. Ou seja, precisam estar organizados e ter significado, de acordo com o contexto do sistema.
Como o próprio nome diz, a modelagem de banco de dados irá criar modelos, que são representações de como a base foi projetada. Os modelos irão descrever a relação entre os objetos do banco de dados, de uma maneira clara e elucidativa.
Existem diversos tipos de objetos de banco, tais como views, triggers etc. Normalmente, quando falamos em modelagem de banco de dados, é comum representar apenas o universo de tabelas e campos (vamos explicar mais adiante).
Os tipos de modelagem são conceitual, lógica e física. Nas próximas seções, vamos falar um pouco sobre cada uma delas. Continue conosco porque ainda temos muito conteúdo pela frente.
A modelagem conceitual fornece uma visão mais geral, focada no negócio. Neste tipo de modelagem, os detalhes técnicos são abstraídos. Porém, é possível representar as entidades e os atributos, que darão origem futuramente às tabelas e aos campos do banco de dados, respectivamente.
Existem muitas formas de representar as saídas da modelagem conceitual. A principal delas é o modelo entidade-relacionamento (MER). Dê uma olhada atentamente no exemplo abaixo, porque faremos alguns comentários a respeito dele.
Cliente, Venda e Produto são as entidades. Cliente e Produto são chamadas de entidades fortes, pois elas não dependem de outras para existirem (se dependessem, seriam entidades fracas). Por outro lado, Venda é uma entidade associativa, pois relaciona as entidades Cliente e Produto.
As bolinhas ligadas a cada uma das entidades são os atributos. Os atributos chave permitem a identificação da entidade e estão sendo representados na figura com a bolinha fechada preta. Os atributos que não são chave estão sendo representados com a bolinha branca.
Você Sabia? Existem muitas variantes das notações para representar os atributos no modelo entidade-relacionamento. Uma variante do atributo chave consiste em exibi-lo de maneira sublinhada (por exemplo, Identificador). Fique atento porque costuma cair bastante em provas.
Você Sabia? ++ Atributos multivalorados podem assumir diversos valores. Por outro lado, atributos derivados, como o próprio nome diz, são decorrentes de outro atributo (geralmente por meio de cálculo). Já os atributos compostos são uma junção de diversos atributos.
Reparou que as entidades possuem dois números ao lado, entre parênteses? O número da esquerda representa a quantidade mínima de ocorrências, enquanto o número da direita representa a quantidade máxima. Isso é chamado de cardinalidade.
Um cliente pode ter 0 ou n vendas. Ou seja, ele pode não comprar nada ou comprar várias vezes. Por outro lado, uma venda precisa ter um e somente um cliente (não dá para fazer venda sem cliente).
Você Sabia? Uma variante importante da notação que apresentamos para a cardinalidade é conhecida como “pé-de-galinha”. O zero é representado como uma bolinha, o um é representado com um “pauzinho”, enquanto o n é representado como um “pé-de-galinha”.
A modelagem lógica é uma espécie de evolução da modelagem conceitual. Ela possui alguns detalhes técnicos, que fazem com que você se lembre de um banco de dados. Ao invés de entidades e atributos, vamos trabalhar agora com tabelas e campos.
A saída mais comum da modelagem lógica é o modelo relacional. Lembra do exemplo anterior? Agora dê uma olhada atentamente no exemplo abaixo e veja se não lhe parece familiar. Ele é o modelo entidade-relacionamento anterior convertido em modelo relacional.
Observe que o tipo aparece ao lado de cada campo (por exemplo, INTEIRO, DATA etc.), determinando como ele será armazenado no banco de dados. Isso é razoável, pois não podemos armazenar um texto da mesma forma que um valor.
Vamos deixar os atributos chave de lado. No modelo relacional, chamamos simplesmente de chaves. Porém, existem algumas classificações. As principais são chaves primárias e chaves estrangeiras.
Você Sabia? Chave primária (primary key – PK) é um campo (ou conjunto de campos) que faz a identificação de um registro em uma tabela. Por outro lado, chave estrangeira (foreign key – FK) é um campo vindo de outra tabela, que faz o papel de chave primária por lá.
No exemplo acima, IdCliente, IdVenda e IdProduto são chaves primárias das tabelas Cliente, Venda e Produto, respectivamente. Além disso, IdCliente e IdProduto são chaves estrangeiras na tabela Venda, vindas das tabelas Cliente e Produto. São elas que fazem os relacionamentos.
A modelagem física é uma espécie de evolução da modelagem lógica. Ela contém vários detalhes técnicos, que permitem identificar com qual Sistema Gerenciador de Banco de Dados (SGBD) estamos trabalhando (por exemplo, Oracle, SQL Server, MySQL etc.).
Embora existam diversas abordagens, normalmente a saída da modelagem física não é um diagrama esquematizado, como vimos nas situações anteriores. A saída mais comum é um script implementado para um determinado SGBD, que deverá ser executado diretamente na base.
Momento Curiosidade: Se tivermos que fazer um comparativo entre as etapas, temos que a modelagem conceitual é feita para o cliente, a modelagem lógica é feita para os desenvolvedores e a modelagem física é desenvolvida para o Administrador de Banco de Dados (DBA).
Em relação às três modelagens, esta é a menos cobrada pelas bancas. Geralmente, exigem que o candidato conheça os conceitos. Não podemos garantir que não vá cair um script complexo para você fazer, mas é raro. Na verdade, as bancas exploram mesmo as modelagens conceitual e lógica.
Estamos quase acabando o artigo de hoje, mas não podemos “deixá-lo na mão”. Afinal, há muita coisa para memorizar e sabemos que você curte um atalho. Baseado nisso, preparamos com carinho o mapa mental abaixo, para você não esquecer mais os conceitos. Esperamos que ajude.
Uma última dica: se você achou que o mapa mental ficou muito pequeno, dificultando a leitura, experimente baixar a imagem ou dar um zoom diretamente no seu navegador.
Em suma, hoje falamos sobre modelagens de dados, de uma maneira objetiva. Se você achou o tema simples, muito fácil, então tenha atenção redobrada. Muitos concurseiros desperdiçam pontos preciosos em tópicos considerados garantidos. Não deixe de estudar o assunto.
Por outro lado, se está com dificuldades, é importante que busque outros materiais na plataforma para estudar, além deste artigo. O Estratégia oferece diversos cursos em pdf, videoaulas e áudios para você ouvir onde quiser. Descubra tudo no link http://www.estrategiaconcursos.com.br/cursos/.
Por fim, não deixe também de praticar o aprendizado por meio de questões. Alunos aprovados realizam centenas ou até milhares de exercícios para atingir seu objetivo. O acesso ao Sistema de Questões do Estratégia é feito pelo link: https://concursos.estrategia.com/.
Bons estudos e até a próxima!
Cristiane Selem Ferreira Neves é Bacharel em Ciência da Computação e Mestre em Sistemas de Informação pela Universidade Federal do Rio de Janeiro (UFRJ), além de possuir a certificação Project Management Professional pelo Project Management Institute (PMI). Já foi aprovada nos seguintes concursos: ITERJ (2012), DATAPREV (2012), VALEC (2012), Rioprevidência (2012/2013), TJ-RJ (2022), TCE-RJ (2022) e CGE-SC (2022/2023). Atualmente exerce o cargo efetivo de Auditora de Controle Externo – Tecnologia da Informação e integra o corpo docente da Escola de Contas e Gestão do TCE-RJ, além de ser produtora de conteúdo dos Blogs do Estratégia Concursos, OAB e Carreiras Jurídicas.