MODELO LÓGICO
DE BANCO DE
DADOS
Este texto-base aborda os seguintes temas. Clique para navegar.
MODELO LÓGICO
DE BANCO DE
DADOS
Este texto-base aborda os seguintes temas. Clique para navegar.
Modelo lógico de Banco de Dados
Adriano é um rapaz empreendedor e está abrindo um minimercado em seu bairro. Para permitir um bom gerenciamento, contratou o desenvolvedor Ferrari para criar o sistema informatizado do estabelecimento.
Ferrari levantou os dados e necessidades do pequeno negócio de Adriano, classificou e organizou os requisitos em um modelo conceitual. Depois, em conjunto definiram o SGBD a ser utilizado no minimercado: o MySQL. Com essa informação em mãos, o desenvolvedor partiu para o modelo lógico, criando um diagrama entidade-relacionamento.
Apesar de Ferrari ser um desenvolvedor, ele explicou a Adriano que não trabalha sozinho, mas com uma equipe dedicada à construção de bancos de dados. Assim, ele precisa garantir que as informações contidas no modelo lógico sejam representadas de acordo com o modelo relacional. Para restringir as opções dos desenvolvedores, ele detalhará o modelo lógico, que atualmente é um diagrama, em uma outra forma de representação. Essa etapa é chamada mapeamento, consiste em um conjunto efetivo de regras e permite que, posteriormente, Ferrari possa construir seu modelo físico.
Você já sabe que, para selecionar SGBD, é necessário fazer uma descrição dos tipos de informações que serão armazenadas em um banco de dados, e para isso são utilizados diferentes tipos de modelos. Após selecionar o SGBD, o projetista deverá relacionar as características e restrições do modelo conceitual (MER) com os requisitos e conjuntos de regras do SGBD selecionado para implementação. Assim, o modelo lógico, que é uma representação do funcionamento do banco de dados, utilizará as estruturas suportadas pelo banco escolhido. Perceba que o modelo lógico depende do software que será utilizado. Qualquer alteração feita no SGBD exige que a estrutura interna do futuro banco seja alterada para adequar-se às características e exigências de implementação do modelo de BD selecionado.
É importante que você também note que o diagrama entidade relacionamento permite registrar quais dados podem aparecer no banco, mas não registra como estes dados serão armazenados no SGBD, ou seja, como se organizam nas tabelas existentes no banco de dados. Para esse detalhamento, é necessário desenvolver o modelo físico. Em um Banco de Dados Relacional (BDR), que é o tipo de BD que será trabalhado neste curso, o esquema interno é expresso utilizando linguagem SQL, por padrão.
Conheça agora alguns conceitos fundamentais para o detalhamento do modelo lógico, uma etapa conhecida como mapeamento.
Chave primária e chave estrangeira
Antes de continuar a construção do Diagrama ER para o minimercado do Adriano, vamos entender quais os elementos necessários para montar o modelo lógico.
Você já sabe que o modelo lógico parte para a construção de uma estrutura em formato adequado ao Sistema Gerenciador de Banco de Dados escolhido, onde o banco de dados será implementado. Sendo assim, os modelos são bastante dependentes da tecnologia a ser adotada. Essa tecnologia pode ser relacional, em redes ou orientada a objetos, e neste material iremos trabalhar com a relacional.
Para o processo de detalhamento de um modelo lógico a partir de um modelo conceitual, é preciso aplicar determinadas regras de derivação. Como nosso objetivo é explorar a derivação de modelos relacionais, trabalharemos com as regras para o modelo relacional, segundo Elmasri e Navathe (2011).
No modelo lógico, além de definir as entidades, atributos e relacionamentos, temos também que identificar as chaves primárias, chaves estrangeiras e tratar os relacionamentos entre as entidades.
Então, veja agora com maiores detalhes esses conceitos.
Chave primária
Na unidade anterior você conheceu o conceito de Chave Primária. Vamos retomá-lo e aprofundá-lo:
Uma chave primária é um atributo que possui um valor único para cada entidade individual. Em outras palavras, Chaves Primárias (Primary Keys ou “PK”), sob o ponto de vista de um banco de dados são representadas por palavras que garantem a unicidade de uma entidade e nunca podem ser nulas. Esta é uma restrição que proíbe que duas entidades possuam o mesmo valor para um determinado atributo ao mesmo tempo, ou seja, elas nunca se repetem.
Alguns tipos de entidades podem ter mais que um atributo formando uma chave ou mais que um atributo chave. São as chamadas chaves compostas.
Para compreender bem o que é uma chave primária, vamos para um exemplo: pense num cadastro que você faz numa loja, solicitando o seu nome, endereço, telefone e CPF. Você consegue identificar quais desses dados (atributos) podem garantir que durante uma consulta no banco de dados da loja o resultado traga somente o seu cadastro?
Reflita e busque resolver essa questão antes de visualizar a solução.
Na unidade anterior você viu que a chave primária pode ser representa pelo nome do campo sublinhado, certo? Você também pode representá-la por um círculo preenchido, veja:
O que é chave estrangeira?
E o conceito de Chave Estrangeira. Você imagina o que é?
Quando uma entidade apresenta um atributo importado de outra entidade, esse atributo é denominado chave estrangeira. As chaves estrangeiras são o resultado de associações entre entidades.
Imagine que Adriano queira cadastrar vários produtos que sejam de uma determinada categoria, por exemplo, vários chocolates que serão vendidos em seu mercado. Essa lista de produtos com seus atributos, no banco de dados, dá origem a uma tabela “Produtos” (tbl_produtos). Cada entidade resulta em uma tabela própria e, como a lista de categoria dos produtos também é uma entidade, tem seus próprios atributos e está organizada em outra tabela (tbl_categorias). Toda vez que Adriano for cadastrar um produto de chocolate, precisará indicar a chave primária da tabela categoria que indique a categoria a que o produto pertence (chocolates).
Ou seja, quando inserirmos um registro na tabela de produtos com o “id_categoria”, essa chave primária da tabela “categorias” será uma chave estrangeira (FK) dentro da tabela “produtos”. É uma chave que vem de fora, de outra tabela, por isso o nome “estrangeira”1.
Mas... porque é importante utilizar chaves estrangeiras?
Com a chave estrangeira, podemos facilitar as consultas e fazer cruzamentos de dados por meio destas referências. Dessa forma, uma chave estrangeira sempre será necessária quando houver o relacionamento entre duas tabelas.
Você verá exemplos de chave estrangeira nas regras de mapeamento!
Regras de Derivação–MapeamentoO mapeamento é um detalhamento do modelo lógico, feito a partir do Diagrama Entidade Relacionamento. Orientando-se pelas seis regras indicadas a seguir, você fará a leitura do DER e registrará as informações nele contidas em um outro formato, que já indica a quantidade e estrutura das tabelas do BD.
Uma vez que se consegue representar a semântica de uma aplicação por meio de modelos de dados, em especial pelo Modelo Entidade Relacionamento, é importante garantir que as informações contidas no MER sejam representadas corretamente no Modelo Relacional. Para garantir uma representação fiel das informações no Modelo Relacional é preciso seguir algumas diretrizes, com objetivo de restringir as opções dos desenvolvedores em um conjunto efetivo de regras.
Vamos ao mapeamento:
#0 | Algumas informações importantes para o mapeamento
Como você já sabe, o mapeamento é um detalhamento do modelo lógico, feito a partir do Diagrama Entidade Relacionamento. Isso quer dizer que você traduzirá o seu diagrama em outro formato, textual, mais próximo do que será utilizado no modelo físico.
No mapeamento, cada linha representa uma tabela. A sintaxe do modelo é grafada da seguinte maneira:
Entidade1 = {chave_primaria, demais_atributos, relacionamentos}
Entidade2 = {chave_primaria, demais_atributos, relacionamentos}
Você pode utilizar qualquer editor de texto para fazer o mapeamento.
No exemplo deste material, o diagrama representa o modelo lógico de um banco de dados que organiza as informações de pessoal, departamento e projeto de uma empresa.
Regra #1 | Mapear Conjuntos de Entidades Regulares
Identificar todas as entidades regulares (não fracas) e seus atributos:
Primeiro, você deverá localizar todas as entidades regulares. Cada uma dará origem a uma linha nova. Depois, escreverá seus atributos, com a nomenclatura devidamente padronizada.
Você se lembra que, na unidade 1, falou-se sobre a importância dessa normalização? Por padrão, adotamos um prefixo no nome dos atributos para identificar a qual entidade esse atributo pertence. Por isso, os atributos da entidade Funcionário iniciam-se sempre com a letra “f”, da entidade; os atributos de Departamento se iniciam com a letra “d”, da entidade; e os de Projeto iniciam com a letra “p”.
Funcionário = {fnúmero, fnome, fendereço, fsalário}
Departamento = {dnúmero, dnome}
Projeto = {pnúmero, pnome}
Você percebeu que o atributo localização, da entidade Departamento, não foi representado no mapeamento acima? Isso porque é um atributo multivalorado e será tratado na 6ª Regra.
A entidade Dependente também não está no nosso mapeamento: por ser uma entidade fraca, o caso será tratado na regra 2, a seguir.
Regra #2 | Mapear Conjuntos de Entidades Fracas
Relacionar todos os atributos da entidade fraca, acrescentando também o atributo chave da entidade da qual ela depende.
Agora, acrescente ao seu mapeamento a entidade fraca. Observe que o atributo chave da entidade Funcionário (fnumero), vai para a entidade Dependentes como um atributo chave! Portanto, a entidade Dependente terá uma chave composta pelos atributos nome do dependente e número do funcionário do qual depende.
Funcionário = {fnúmero, fnome, fendereço, fsalário}
Departamento = {dnúmero, dnome}
Projeto = {pnúmero, pnome}
Dependente = {dependnome, fnúmero, dependdataniver, dependparentesco}
Regra #3 | Mapear Conjuntos de Relacionamentos Binários 1:1
No mapeamento dos relacionamentos 1:1, deve-se escolher uma entidade para receber o atributo chave da outra entidade relacionada.
Mas como escolher a entidade que receberá o atributo? Você sempre deve fazer um pergunta envolvendo essas duas entidades relacionadas:
Todo funcionário gerencia um departamento?
Resposta: Não necessariamente!
Sabemos que nem todo o funcionário é gerente de um departamento, não é? Então, não é interessante que a entidade Funcionário receba a chave primária do departamento gerenciado.
Agora fazemos a pergunta ao contrário:
Todo o departamento é gerenciado por um funcionário?
Resposta: Sim, todo o departamento deve ter alguém responsável por ele.
Sendo assim, departamento receberá a chave primária do funcionário gerente.
Você percebeu que existe um atributo no relacionamento? O atributo dataini é a data em que o funcionário começou a gerenciar o departamento. Ele está representado no relacionamento porque não pertence apenas à entidade funcionário e nem somente à entidade departamento; mas, sim, ao relacionamento. Ou seja, ele existirá na relação funcionário gerencia departamento, indicando quando isso começou a acontecer. Neste caso, o mapeamento do relacionamento entre essas duas entidades ficará assim:
Funcionário = {fnúmero, fnome, fendereço, fsalário}
Departamento = {dnúmero, dnome, fnumerogerente, gerenciadataini}
Projeto = {pnúmero, pnome}
Dependente = {dependnome, fnúmero, dependdataniver, dependparentesco}
Voce se lembra que todo atributo recebido por outra entidade é chamado de Chave Estrangeira? Portanto, fnumerogerente do empregado é a chave estrangeira da entidade Departamento.
Note que o atributo chave da uma entidade Funcionário vai para a entidade Departamento como um atributo simples!
Regra #4 | Mapear Conjuntos de Relacionamento Binário Regular 1:N
No mapeamento dos relacionamentos 1:N, deve-se acrescentar à entidade de lado N, o atributo chave da entidade de lado 1.
Neste passo, mapearemos os relacionamentos: supervisionar, trabalhar e controlar.
Avaliando o relacionamento supervisionar;
Esse relacionamento é um caso especial em que uma entidade se relaciona com si própria.
É chamado de relacionamento recursivo ou auto-relacionamento. É raro de ocorrer, mas sua utilização tem grande importância em alguns casos. No exemplo, na classe funcionário existe um único funcionário que é supervisor dos demais funcionários. Assim temos uma relação 1:N.
Um funcionário supervisiona vários funcionários e os funcionários são
supervisionados por um único supervisor.
Sendo assim, o atributo SuperNúmero é adicionado na entidade Funcionário:
Funcionário = {fnúmero, fnome, fendereço, fsalário, supernumero}
Departamento = {dnúmero, dnome, fnumerogerente, gerenciadataini}
Projeto = {pnúmero, pnome}
Dependente = {dependnome, fnúmero, dependdataniver, dependparentesco}
Avaliando o relacionamento trabalhar;
O mesmo acontece com o relacionamento trabalhar: a entidade de lado N da relação recebe a chave primária do atributo chave da entidade de lado 1. Sendo assim, o atributo DNumero deve ser adicionado à entidade Funcionário. Ficando representado dessa forma:
Funcionário = {fnúmero, fnome, fendereço, fsalário, supernumero, dnumero}
Departamento = {dnúmero, dnome, fnumerogerente, gerenciadataini}
Projeto = {pnúmero, pnome}
Dependente = {dependnome, fnúmero, dependdataniver, dependparentesco}
Avaliando o relacionamento controlar.
Da mesma forma, no relacionamento controlar, das entidades Departamento e Projeto, o lado N da relação (a entidade Projeto) recebe a chave primária do lado 1 do relacionamento, no caso (ou seja, da entidade Departamento):
Funcionário = {fnúmero, fnome, fendereço, fsalário, supernumero, dnumero}
Departamento = {dnúmero, dnome, fnumerogerente, gerenciadataini}
Projeto = {pnúmero, pnome, dnumero}
Dependente = {dependnome, fnúmero, dependdataniver, dependparentesco}
Note que os atributos chave das entidades do lado 1 foram para as entidades chave do lado N como atributos simples!
Regra #5 | Mapear Relacionamento Binário M:N
O relacionamento binário envolve dois conjuntos de entidades. A maior parte dos conjuntos de relacionamentos modelados em um BD é do tipo binário. Para cada relacionamento binário M:N cria-se uma relação. Os atributos da relação são os atributos do conjunto de relacionamento, juntamente com os atributos chave das relações que mapeiam os conjuntos de entidades envolvidas. A chave da relação é a concatenação dos atributos chave das relações que mapeiam os conjuntos de entidades envolvidos.
Observe o relacionamento Funcionário “participa” de Projeto. Nesse caso, um funcionário pode participar de vários projetos e um projeto pode ter a participação de vários funcionários, portanto, dizemos que o relacionamento é N:M.
Assim, devemos criar uma nova entidade, a partir do relacionamento Participar, adotando como chave primária a concatenação da chave primária de Funcionário e da chave primária de Projeto, acrescentando-se o(s) atributo(s) que existir(em) no relacionamento:
Funcionário = {fnúmero, fnome, fendereço, fsalário, supernumero, dnumero}
Departamento = {dnúmero, dnome, fnumerogerente, gerenciadataini}
Projeto = {pnúmero, pnome, dnumero}
Dependente = {dependnome, fnúmero, dependdataniver, dependparentesco}
Participar = {fnum, pnum, horas}
Por que isso? Porque para você conseguir cadastrar um mesmo funcionário em vários projetos, deverá fazer um registro para cada projeto do qual o funcionário participa, vinculando o número de horas a serem trabalhadas. Veja o exemplo:
MARIA trabalha no projeto de desenvolvimento do sistema MAP com carga horária de 20 horas semanais.
MARIA trabalha no projeto de desenvolvimento do sistema GIGA com carga horária de 10 horas semanais.
MARIA trabalha no projeto de desenvolvimento do sistema EMPLACAR com carga horária de 14 horas semanais.
Da mesma forma:
JOÃO trabalha no projeto de desenvolvimento do sistema MAP com carga horária de 20 horas.
JOÃO trabalha no projeto de desenvolvimento do sistema EMPLACAR com carga horária de 22 horas.
Perceba que você poderá repetir o número da matrícula da Maria para vários números de projetos diferentes e poderá repetir os números de projetos para vários funcionários diferentes. A única coisa que você não poderá fazer é cadastrar duas vezes o mesmo funcionário para o mesmo projeto, não é? Ora, e como você poderá fazer para que isso não aconteça? A única forma é colocar os dois atributos como chave primária (número da matrícula do funcionário e número do projeto).
Regra #6 | Mapear Atributos Multivalorados
A 6ª regra identifica os atributos multivalorados, ou seja, aqueles que possuem um ou mais valores para o mesmo atributo.
Para este caso, deve-se criar uma nova entidade, inserindo o atributo multivalorado e o atributo chave da entidade a qual ele pertence. Ambos os atributos devem ser chaves primárias, compondo uma chave concatenada.
Funcionário = {fnúmero, fnome, fendereço, fsalário, supernumero, dnumero}
Departamento = {dnúmero, dnome, fnumerogerente, gerenciadataini}
Projeto = {pnúmero, pnome, dnumero}
Dependente = {dependnome, fnúmero, dependdataniver, dependparentesco}
Participar = {fnum, pnum, horas}
LocalDep = {dnúmero, localização}
Entendeu o motivo?
Imagine que um departamento de uma universidade, por exemplo, esteja localizado em vários polos, em cidades diferentes. Para que não tenha o problema de cadastrar o mesmo polo, em uma mesma localização, mais de uma vez, definimos os dois atributos como chave. Veja um exemplo:
LocalDep: (dnúmero, dlocalização)
Na tabela LocalDep, poderiam constar os seguintes dados:
Departamento número 10, local São Paulo.
Departamento número 10, local Campinas.
Departamento número 10, local Jundiaí.
Departamento número 20, local São Paulo.
Departamento número 20, local Curitiba.
Perceba que apenas podemos dizer que um mesmo departamento tem polos em localidades diferentes se o número do departamento e o local forem definidos como chave. Observe que dessa forma não é permitido cadastrar um mesmo departamento em um mesmo local mais de uma vez, evitando duplicidade de registros.
Entendeu agora o porquê temos que definir o número do departamento e a sua localização como chave?
Mapeamento feito!
Sendo assim, o mapeamento do Modelo ER representado ficou dessa forma:
Com esse detalhamento em mãos, você conseguirá partir para o modelo físico!
Praticando o mapeamento do diagrama ER
Agora que você já conhece as seis regras do mapeamento, é hora de praticá-las.
Procure fazer o mapeamento dos três diagramas ER a seguir, cada qual pensado para um BD diferente.
Situação A
Situação B
Situação C
Ferramenta Case BR Modelo para modelo lógico
Até agora você utilizou softwares editores de texto para preparar seus diagramas ER, correto? Saiba que existem ferramentas que podem auxiliar na construção desse tipo de representação gráfica, caso do Case BR Modelo. O tutorial a seguir pode ser de grande ajuda, caso você deseje utilizá-la:
No video a seguir, você irá retormar alguns conceitos importantes já estudados.
O próximo passo é implementar o banco de dados, ou seja, desenvolver o modelo físico, também conhecido como projeto físico. Neste curso, trabalharemos com o modelo relacional e o SGBD será o MySQL. O importante agora é instalarmos o Sistema Gerenciador de Banco de Dados. Vamos lá?
Recapitulando...Esta foi uma unidade intensa, com diversos conceitos novos! Para sintetizar e retomar os conceitos estudados, assista à videoaula do professor Sandro Valérius.
1 Adaptado de: https://www.diegomacedo.com.br/entendendo-as-chaves-dos-bancos-de-dados/
Acessado em 05.abr.2019.