Modelos de Dados

Modelagem de dados com o modelo entidade-relacionamento (ER)

Estudante, esta videoaula foi preparada especialmente para você. Nela, você irá aprender conteúdos importantes para a sua formação profissional. Vamos assisti-la? 
Bons estudos!

Ponto de Partida

Olá, estudante! Nesta aula, estudaremos conceitos muito importantes em modelagem de dados. A modelagem de dados é uma metodologia utilizada para a especificar os requisitos que um determinado software deverá possuir. Ela faz parte, portanto, do processo desenvolvimento de um software. Modelar dados envolve uma série de aplicações teóricas e práticas visando construir um esquema banco de dados que possa ser utilizado em qualquer sistema gerenciador de banco de dados (SGBD). Para tanto, nesta unidade você aprenderá as diferenças entre os modelos conceitual, lógico e físico, além de conhecer com detalhes os elementos usados na construção da modelagem como o modelo ER (entidade-relacionamento). Fique atento aos conceitos que serão apresentados, pois eles serão essenciais para a compreensão da disciplina. Assim, convidamos você, caro estudante, a prestar muita atenção nesta parte inicial; você perceberá que precisará dela para se aprofundar mais no tema. Bons estudos!

Vamos Começar!

De acordo com Sordi (2019), a modelagem de dados é um processo que se repetirá de forma gradual, começando com a compreensão inicial de um problema. À medida que este problema for  mais bem compreendido, o nível de detalhes do modelo também aumentará. Uma das etapas mais importantes no desenvolvimento de um software, assim, é a elaboração de um projeto de banco de dados.

Criar um banco de dados sem um estudo e de forma apressada pode causar diversos problemas, como um desempenho abaixo do esperado, consultas difíceis e, ainda, resultados equivocados, o que afeta negativamente a performance do software. Um modelo de dados é um detalhamento dos tipos de dados que serão armazenados em um banco de dados. Em sua futura elaboração, as linguagens utilizadas serão qualificadas, de acordo com a forma de apresentar modelos, em textual ou gráfica. Esta forma de representação de um modelo de dados, por meio de uma linguagem de modelagem de dados, é conhecida como esquema de banco de dados, segundo Silberschatz, Korth e Sudarshan (2020).

Quando pretendemos fazer uma viagem, a primeira preocupação é planejá-la cuidadosamente e escolher o que vamos levar nas malas, o roteiro a ser feito e o meio de transporte a ser utilizado (carro, avião, ônibus etc.). Da mesma forma, quando estamos empenhados no desenvolvimento de um sistema para computador (seja de grande ou pequeno porte), devemos planejar todas as suas etapas e dedicar atenção especial ao projeto e estruturação do banco de dados. Para isso, utilizamos uma técnica chamada modelagem de dados, cujo objetivo é transformar uma ideia conceitual em algo que possa ser traduzido em termos computacionais. Para Alves (2020), com a modelagem de dados podemos refinar um modelo conceitual durante as fases que compõem o projeto, eliminando redundâncias ou incoerências que possam inevitavelmente surgir.

Sem esse planejamento prévio, a manutenção do sistema certamente se tornará uma tarefa mais complexa e frequente. Não podemos, no entanto, acreditar que todo o projeto de banco de dados deva ser realizado apenas pela equipe de TI. Os próprios utilizadores devem também participar de sua elaboração nas fases mais críticas, como recolha de dados, testes de usabilidade e validação. Não há dúvida de que até os profissionais precisam saber como funciona um negócio, caso contrário, as consequências podem ser desastrosas.

De acordo com Alves (2020), durante a fase inicial de modelagem conceitual dos dados, o profissional precisa observar atentamente tudo o que for relevante no mundo real e que deva ser “transportado” para o sistema que está sendo projetado. Com essas informações, ele já pode criar um esboço, representando de forma gráfica o processo. A esse esboço damos o nome de abstração ou modelo abstrato. Nele, podemos encontrar três componentes muito importantes: o modelo conceitual, o modelo lógico e o modelo físico.

Siga em Frente...

O modelo conceitual é a primeira etapa do projeto, na qual se representa a realidade mediante uma visão global e genérica dos dados e de seus relacionamentos. Seu objetivo é conter todas as informações dessa realidade que serão armazenadas, sem que se retratem aspectos relativos ao banco de dados que será utilizado. Para Alves (2020), essas informações podem aparecer no formato de uma lista descritiva das operações executadas pelos usuários e dos dados que eles devem manipular.

O modelo lógico é a segunda etapa e compreende a descrição das estruturas que serão armazenadas no banco de dados. Resulta em uma representação gráfica dos dados de maneira lógica, inclusive já nomeando os componentes e as ações que exercem um sobre o outro, como vemos na Figura 1. Nesse momento também se define a abordagem de banco de dados que será utilizada: hierárquica, de rede ou relacional.

Do modelo lógico, podemos derivar o modelo físico, no qual se encontram detalhados os componentes de estrutura física do banco de dados, como tabelas, campos, tipos de valores, índices etc. Quando chegarmos a esse ponto, estaremos prontos para a criação propriamente dita do banco de dados utilizando o sistema gerenciador que mais se adequar às nossas necessidades.

Uma vez que a realidade muda de uma empresa para outra, é preciso estabelecer uma forma padrão para se estruturar um banco de dados, independentemente do tipo de ambiente ou negócio. Assim, definiu-se o que normalmente conhecemos como metamodelo, sendo o mais utilizado o tipo entidade-relacionamento (ER). Um modelo de dados ER é composto de três classes de objetos: entidades, relacionamentos e atributos. Segundo Silberschatz, Korth e Sudarshan (2020), o modelo ER também tem associada a ele uma representação esquemática, o diagrama de ER. Um diagrama ER pode expressar, de forma gráfica, a estrutura lógica geral de um banco de dados. Os diagramas ER são simples e claros – qualidades que podem ser responsáveis, em grande parte, pelo uso generalizado do modelo ER.

Objetos ou eventos do mundo real, isto é, atividades que geram atributos que precisam ser mantidos, podem ser modelados e convertidos em entidades (tabelas), como clientes, empresas, funcionários, produtos, reservas, serviços, aluguéis etc.

Vamos Exercitar?

Nesta aula, estudamos alguns conceitos relacionados à definição de modelagem de dados e os tipos de modelagem mais utilizados, como o modelo conceitual, cujo alvo é a definição do problema, e não a sua solução, que mostra o que precisará existir no banco de dados de uma forma geral, sem se preocupar de que forma isso será realizado no SGBD; o modelo lógico, que, por sua vez, é mais complexo que o modelo conceitual, necessita de mais detalhes de como os dados se relacionam; e o modelo físico, que se preocupa em implementar os modelos descritos anteriormente em algum SGBD. Também vimos que, para um problema que desejamos resolver, o passo inicial é criar um modelo conceitual e observar os requisitos levantados, por meio dos quais poderemos retirar várias informações. Assim, de forma visual e prática, conseguiremos avançar ainda mais a solução do problema com ajuda do modelo lógico e, por fim, implementar nosso banco modelado em algum SGBD apropriado.

Saiba Mais

 Para uma melhor compreensão dos assuntos abordados em aula, recomendamos que você visite a seguinte página na web:

MODELAGEM de dados: modelo conceitual, modelo lógico e físico. Blog Utilidade Pública: Tecnologia, Educação e Cidadania.

Referências Bibliográficas

ALVES, W. P. Banco de dados: teoria e desenvolvimento. 2. ed. São Paulo: Érica, 2020.

ELMASRI, R.; NAVATHE, S. B. Sistemas de banco de dados. 7. ed. São Paulo: Pearson Education do Brasil, 2018.

MACHADO, F. N. R. Banco de dados: projeto e implementação. 4. ed. São Paulo: Érica, 2020.

SILBERSCHATZ, A.; KORTH, H.; SUDARSHAN, S. Sistema de banco de dados. 7. ed. Rio de Janeiro: LTC, 2020.

SORDI, J. O. de. Modelagem de dados: estudos de casos abrangentes da concepção lógica à implementação. 1. ed. São Paulo: Érica, 2019.

Elementos do modelo entidade-relacionamento (ER) - I

Estudante, esta videoaula foi preparada especialmente para você. Nela, você irá aprender conteúdos importantes para a sua formação profissional. Vamos assisti-la? 
Bons estudos!

Ponto de Partida

Olá, estudante! Nesta aula, avançaremos ainda mais sobre o tema modelagem entidade-relacionamento (MER). A base do modelo relacional é um conceito matemático denominado relação, no qual dois conjuntos de números possuem termos relacionados entre si. No modelo conceitual, um conjunto é chamado de entidade; já no modelo lógico, é chamado de tabela. Cada tabela é definida por um conjunto de atributos, também conhecidos como campos, que descrevem suas características particulares. A representação gráfica da modelagem relacional é a forma de representação dos componentes do modelo lógico de um banco de dados. Essa representação é uma parte muito importante da compreensão do esquema do banco de dados. É preciso, então, estudar mais a fundo as entidades, os relacionamentos e os atributos dentro da MER, dado que esta é a seção primordial para continuarmos nossos estudos em modelagem de dados. Bons estudos!

Vamos Começar!

Para Sordi (2019), entidade pode ser conceituada como algo que existe física ou virtualmente, identificável unicamente por intermédio de suas características (seus atributos). Um sistema de informação pode manipular dados de diversas entidades. Imaginemos um sistema educacional que monitore o desempenho dos alunos em cada disciplina. Há muitos alunos em instituições e eles podem ser representados por um tipo de entidade que chamamos de Aluno. Da mesma forma, muitas disciplinas podem ser representadas por um tipo e uma entidade (tipo entidade) denominada Disciplina. Um registro contendo vários dados (atributos) de um estudante é uma instância da entidade Aluno. Uma entidade (tipo entidade), assim, pode armazenar dados de vários alunos, ou seja, de múltiplas instâncias.

Ainda segundo Sordi (2019), as entidades (entity types) podem ser de três tipos: forte (ou fundamental), fraca (ou atributiva) e associativa. A entidade forte é a mais comum; existe independentemente de qualquer outra entidade, e por essa razão geralmente a chamamos apenas de entidade. Já uma entidade fraca depende de outra entidade (forte). Por exemplo, a entidade dependente de funcionários só existirá se houver instâncias de funcionários que declarem filhos ou outros entes como dependentes. Portanto, a entidade dependente é fraca por depender da entidade Colaborador. Observe que, por padrão, os nomes das entidades são usados sempre no singular: Colaborador, Dependente, Cliente. Por fim, temos, ainda, a entidade associativa, que caracteriza o relacionamento entre duas ou mais entidades.

De acordo com Silberschatz, Korth e Sudarshan (2020), um relacionamento é uma associação entre várias entidades. Podemos, a título de exemplo, definir um relacionamento mentor que associa o instrutor Katz ao aluno Shankar. Esse relacionamento especifica que Katz é o mentor do aluno Shankar. Um conjunto de relacionamento é, pois, um conjunto de relacionamentos do mesmo tipo.

Considere os dois conjuntos de entidades, Instrutor e Aluno. Definimos o conjunto de relacionamentos mentor para indicar a associação entre os instrutores e os alunos que atuam como seus mentoreados. A Figura 3 ilustra essa associação, porém, para simplificar, somente alguns atributos dos dois conjuntos de entidades foram mostrados.

Uma instância de relacionamento em um esquema ER representa uma associação entre as entidades nomeadas nas empresas reais que estão sendo modeladas. Como ilustração, a entidade individual instrutor Katz, que possui o ID de instrutor 45565, e a entidade aluno Shankar, que possui o ID de aluno 12345, participam de uma instância de relacionamento de mentor. Ela representa que, na universidade, o instrutor Katz está aconselhando o aluno Shankar.

Um conjunto de relacionamento é representado em um diagrama ER por um losango, que é ligado por meio de linhas a uma série de conjuntos de entidades (retângulos) diferentes. O diagrama ER da Figura 4 mostra os dois conjuntos de entidades, Instrutor e Aluno, relacionados por meio de um conjunto de relacionamento binário mentor.

Siga em Frente...

Como outro exemplo, considere os dois conjuntos de entidades Aluno e Seção, em que seção indica a oferta de um curso. Podemos definir o conjunto de relacionamento para indicar a associação entre o aluno e o curso no qual ele está matriculado.

Embora, nos casos anteriores, cada conjunto de relacionamento fosse uma associação entre dois conjuntos de entidades, em geral, um conjunto de relacionamento pode indicar a associação de mais de dois conjuntos de entidades.

Para Sordi (2019), pela análise da definição de entidade, podemos inferir que atributo é sinônimo de característica da entidade. De fato, muitos autores o definem como uma característica ou propriedade desta. Por exemplo, a entidade Aluno pode ser descrita pelos atributos número da Matrícula (ID), nome, data de nascimento, sexo, endereço, telefone e e-mail. O termo ID, nesse contexto, significa identificador, ou seja, atributo único e diferenciador de uma instância perante todas as demais instâncias da entidade.

Já para Silberschatz, Korth e Sudarshan (2020), o atributo de um conjunto de relacionamento é representado em um diagrama ER por um retângulo não dividido. Ligamos o retângulo por uma linha tracejada até o losango que representa esse conjunto de relacionamento. A Figura 5 mostra, de maneira exemplar, o conjunto de relacionamento “realiza” entre os conjuntos de entidades Seção e Aluno. O atributo descritivo “nota” é ligado ao conjunto de relacionamento “realiza”. Um conjunto de relacionamento, vale dizer, pode ter vários atributos descritivos; por exemplo, também podemos armazenar um atributo para crédito com o conjunto de relacionamento “realiza” a fim de registrar se um aluno realizou a seção para crédito ou se está auditando (ou apenas assistindo) o curso.

Vamos Exercitar?

Nesta aula, aprendemos mais alguns conceitos relacionados à modelagem de dados. Com a introdução dos temas entidades, relacionamentos e atributos, temos, agora, mais alguns subsídios para o início do processo de modelagem de dados. Entender suas diferenças e como identificá-los é muito importante, pois através deles é que conseguimos construir um banco de dados e deixá-lo funcional e pronto para uso. Como vimos, com ajuda dos diagramas de entidade-relacionamento (DER) é possível visualizar as entidades, os relacionamentos entre elas e os atributos ligados.

Para a continuação dos estudos sobre MER, caro estudante, sugerimos que comece a praticar. Na literatura, podemos encontrar várias bibliografias com exemplos e exercícios relacionados ao tema. Ponha a mão na massa e avance ainda mais seus estudos teóricos aliados à prática.

Saiba Mais

Para uma melhor compreensão dos assuntos abordados em aula, recomendamos que você visite a seguinte página na web:

MODELAGEM de dados: modelo conceitual, modelo lógico e físico. Blog Utilidade Pública: Tecnologia, Educação e Cidadania.

Referências Bibliográficas

ALVES, W. P. Banco de dados: teoria e desenvolvimento. 2. ed. São Paulo: Érica, 2020.

ELMASRI, R.; NAVATHE, S. B. Sistemas de banco de dados. 7. ed. São Paulo: Pearson Education do Brasil, 2018.

MACHADO, F. N. R. Banco de dados: projeto e implementação. 4. ed. São Paulo: Érica, 2020.

SILBERSCHATZ, A.; KORTH, H.; SUDARSHAN, S. Sistema de banco de dados. 7. ed. Rio de Janeiro: LTC, 2020.

 

Elementos do modelo entidade-relacionamento (ER) - II

Estudante, esta videoaula foi preparada especialmente para você. Nela, você irá aprender conteúdos importantes para a sua formação profissional. Vamos assisti-la? 
Bons estudos!

Ponto de Partida

Olá, estudante! Nesta aula, estudaremos conceitos avançados sobre entidades, atributos e relacionamentos do MER (modelagem entidade-relacionamento). O modelo entidade-relacionamento (MER) foi desenvolvido para melhorar o design do banco de dados e permitir a especificação de um modelo conceitual, segundo Silberschatz, Korth e Sudarshan (2020). Este é o modelo mais comumente usados em sistemas de gerenciamento de banco de dados. Foi desenvolvido por Edgar F. Codd em 1970, mas somente em 1987 é que as empresas de software começaram a usá-lo.

É preciso destacar, nesse contexto, que a generalização e a especialização são conceitos empregados na representação de objetos do mundo real que compartilham atributos semelhantes e podem ser classificados em uma hierarquia, exibindo as relações de dependência entre as entidades de uma categoria específica. Considere, pois, uma companhia de seguros que comercializa apólices para uma clientela composta por indivíduos e empresas. Neste exemplo, podemos observar que a entidade Cliente pode ser subdividida em duas outras entidades que compartilham atributos em comum, como Pessoa Física e Pessoa Jurídica.

Logo, convidamos você, caro estudante, para refletirmos sobre os conceitos de especialização/generalização em modelagem de dados bem como sobre outros tópicos pertinentes ao tema. Bons estudos!

Vamos Começar!

O modelo de dados entidade-relacionamento, concebido por Peter Chen, tem sido aplicado para a comunicação com os utilizadores finais, mostrando entidades e relacionamentos. No entanto, quando empregado para unir múltiplos modelos conceituais, cada um com diferentes utilizadores finais, ele enfrenta restrições significativas até que se recorra a um conceito de abstração de dados chamado generalização.

Segundo Machado (2020), a generalização ocorre quando se define um subconjunto de relacionamentos entre duas ou mais classes de dados.

Ainda para o autor (2020), quando examinamos a entidade Funcionário sob a perspectiva de diferentes grupos de utilizadores finais, é notório que a classe de dados que identificamos como funcionários representa uma abstração que engloba outras classes, tais como gerentes, engenheiros, secretárias, técnicos de sistemas e assim por diante.

Em geral, a generalização ocorre quando entidades que possuem atributos em comum são generalizadas em alto nível como uma entidade só, como uma entidade genérica ou uma superclasse de dados. De acordo com Machado (2020), as entidades de nível mais baixo que fazem parte desse supertipo são denominadas subtipos e refletem a especialização de partes da entidade supertipo.

A simbologia para representar o relacionamento entre a entidade supertipo e a entidade subtipo é muito variada. Em geral, utilizamos um pequeno círculo na intersecção das linhas que levam o supertipo até os subtipos, com uma indicação em seu interior.

Entidades associativas são aquelas que surgem devido ao tipo de conexão que existe entre as tabelas. O nome desse tipo de tabela deve ser descritivo, como Contrato ou Histórico, e é comum que seja uma combinação dos nomes das tabelas envolvidas. Em termos de requisitos de banco de dados, esse tipo de tabela geralmente se relaciona a ações ou eventos, como atender, contratar ou prescrever. Quando ocorre uma relação entre duas entidades, o número de vezes que uma se associa à outra define a intensidade do relacionamento ou cardinalidade entre as tabelas.

Para Sordi (2019), a cardinalidade de uma instância de relação é uma maneira aproximada de medir quantas instâncias de uma ou mais entidades estão conectadas à própria instância ou a outra(s) entidade(s). No modelo de dados, usamos dois símbolos para representar essa cardinalidade: o valor mínimo e o valor máximo. Para o valor mínimo da cardinalidade, temos duas escolhas: zero (0) ou um (1). O valor zero indica que a conexão é opcional, enquanto o valor um implica que a conexão é obrigatória, o que é fundamental na modelagem das regras de negócios. Quanto ao valor máximo da cardinalidade, também temos duas opções: um (1) ou muitos (M). Na representação gráfica, qualquer valor maior que um é o que importa, indicando que existem várias conexões, embora não forneça um número exato.

Siga em Frente...

Segundo Silberschatz, Korth e Sudarshan (2020), na notação do diagrama ER, indicamos as restrições de cardinalidade em um relacionamento que pode ser representado por um desenho de uma linha direcionada (→) ou uma linha não direcionada (–) entre o conjunto de relacionamentos e o conjunto de entidades em questão. Especificamente, para o exemplo da universidade, tem-se:

Ainda de acordo com Sordi (2019), a presença de um grupo de entidades E em um conjunto de relacionamentos R é denominada participação total quando todas as entidades em E estão envolvidas em pelo menos um relacionamento em R. Se apenas algumas das entidades em E participam dos relacionamentos em R, então a presença do grupo de entidades E no relacionamento R é considerada parcial.

Em uma universidade, assim, pode ser necessário que cada aluno tenha pelo menos um orientador; na modelagem ER, isso implica que cada entidade aluno deve estar ligada a pelo menos um instrutor por meio do relacionamento de orientação. Portanto, a participação dos alunos no conjunto de relacionamentos de orientação é total. No entanto, um instrutor não necessariamente precisa orientar um aluno. Assim, é possível que apenas algumas das entidades instrutor estejam relacionadas com o grupo de entidades aluno por meio do relacionamento de orientação, tornando a participação dos instrutores no conjunto parcial.

Para determinar a cardinalidade entre as tabelas, é necessária muita atenção. Perguntamos sempre se existe a possibilidade de repetição, e se existir, será N; mas não havendo essa possibilidade, será 1. Por exemplo, um médico pode atender mais de um paciente? Claro que sim! E o paciente? Pode ser atendido por mais de um médico? Sim, e em várias ocasiões. Fica claro que o relacionamento entre as tabelas Médico e Paciente terá a cardinalidade de N para N. Agora, se o paciente precisar informar o seu tipo sanguíneo? Ele não poderá informar mais de um tipo, mas esse mesmo tipo sanguíneo pode se repetir em outros pacientes? Com certeza! Pronto! Teremos um relacionamento N para 1 entre as tabelas Paciente e Tipo Sanguíneo. Observe, na Figura 3, como fica o diagrama de entidade-relacionamentos (DER) dessa situação descrita: Médico, Paciente e Tipo Sanguíneo.

A determinação da cardinalidade é um aspecto crítico para a eficácia de um banco de dados. Após concluir a modelagem desse banco, é aconselhável compartilhar o diagrama com outras pessoas, uma vez que suas opiniões podem identificar questões que foram inadvertidamente negligenciadas durante o processo. Além disso, em situações em que a cardinalidade não está claramente definida, é essencial consultar o cliente para obter mais esclarecimentos.

Vamos Exercitar?

Com os conhecimentos adquiridos nesta aula, você, estudante, poderá detalhar ainda mais suas modelagens utilizando-se de cardinalidades nos relacionamentos, bem como do conceito de entidades associativas e de generalização/especialização. Com ajuda dos diagramas de entidade-relacionamento (DER), é possível visualizar as entidades, os relacionamentos entre elas e as cardinalidades, além das generalizações, como citado anteriormente no exemplo da entidade Cliente. Uma sugestão para a continuação dos estudos sobre MER é começar a praticar. Na literatura, podemos encontrar várias bibliografias com exemplos e exercícios relacionados ao tema. Coloque a mão na massa e avance ainda mais seus estudos teóricos aliados à prática.

Saiba Mais

Para uma melhor compreensão dos assuntos abordados em aula, recomendamos a leitura das referências bibliográficas e a visita à seguinte página na web:

PRATA, J. F. Um roteiro para facilitar o ensino e o aprendizado na elaboração de projetos conceituais de bancos de dados. Exacta, São Paulo, v. 4, n. 1, p. 113-121, jan./jun. 2006.

Referências Bibliográficas

ALVES, W. P. Banco de dados: teoria e desenvolvimento. 2. ed. São Paulo: Érica, 2020.

ELMASRI, R.; NAVATHE, S. B. Sistemas de banco de dados. 7. ed. São Paulo: Pearson Education do Brasil, 2018.

MACHADO, F. N. R. Banco de dados: projeto e implementação. 4. ed. São Paulo: Érica, 2020.

SILBERSCHATZ, A.; KORTH, H.; SUDARSHAN, S. Sistema de banco de dados. 7. ed. Rio de Janeiro: LTC, 2020.

SORDI, J. O. de. Modelagem de dados: estudos de casos abrangentes da concepção lógica à implementação. 1. ed. São Paulo: Érica, 2019.

Elementos do modelo entidade-relacionamento (ER) - III

Estudante, esta videoaula foi preparada especialmente para você. Nela, você irá aprender conteúdos importantes para a sua formação profissional. Vamos assisti-la? 
Bons estudos!

Ponto de Partida

Olá, estudante! Nesta aula nos debruçaremos sobre mais alguns componentes importantes de entidades e cardinalidade na modelagem MER e iremos introduzir o conceito de chave. Um banco de dados consiste em múltiplas tabelas que estão conectadas entre si. É fundamental que cada uma delas possua um nome único e representativo. Por exemplo, uma tabela destinada a armazenar informações sobre carros pode ser nomeada Garagem, em vez de usar um nome genérico como Tabela_A. Além disso, tabelas possuem certas características distintas. Uma tabela é percebida como uma estrutura composta por filas e colunas (bidimensional). Cada fila ou registro representa uma única instância da entidade no conjunto de entidades. Cada coluna representa um atributo distinto e tem um nome único em relação aos outros. Cada ponto de interseção entre uma fila e uma coluna contém um valor singular que corresponde aos dados da tabela. Todos os valores em uma coluna devem seguir o mesmo formato. Vale dizer que a ordem das colunas e filas não tem relevância para um sistema de gerenciamento de banco de dados (SGBD). E cada tabela deve representar um atributo (também conhecido como chave, como discutiremos melhor posteriormente) ou uma combinação de atributos que identifique de maneira única cada fila.

Assim, para lidar com essas características, acompanhe esta aula que lidará com esses e outros assuntos pertinentes ao MER. Bons estudos!

Vamos Começar!

Alves, em seu livro Banco de dados: teoria e desenvolvimento (2020), ressalta que pode existir uma categoria de entidades desprovida de atributos-chave, o que implica que não é possível distinguir uma entidade individual dentro desse conjunto, uma vez que entidades idênticas podem existir. Essas entidades são chamadas de entidades fracas. Já as entidades que possuem atributos-chave são conhecidas como entidades fortes.

Em outras palavras, para Silberschatz, Korth e Sudarshan (2020), cada tabela que representa uma entidade no modelo conceitual pode ser categorizada como uma entidade forte ou uma entidade fraca. Essa diferenciação é estabelecida com base na análise de duas condições fundamentais: a dependência de existência e a dependência de identificador. Uma entidade é considerada fraca se pelo menos uma dessas formas de dependência estiver presente no relacionamento entre duas entidades. Conforme Elmasri e Navathe (2018) explicam, uma entidade fraca sempre implica em uma restrição de participação total e uma dependência de existência em relação a uma entidade específica. Os autores classificam os tipos de entidades da seguinte maneira:

• Entidades fortes: tabelas independentes que não requerem outras para a sua existência. Exemplos incluem as entidades Aluno, Curso, Cliente, Empresa e Paciente. Na análise de requisitos, essas entidades são facilmente identificadas, pois são substantivos robustos e de significado claro.
• Entidades fracas ou dependentes: tabelas que dependem de outras entidades para existir e só são viáveis devido à presença de uma entidade forte. Entidades fracas são frequentemente representadas por retângulos com bordas duplas (embora, em muitos modelos atuais, sejam representadas apenas por retângulos). Por exemplo, a tabela Dependente só existe porque a tabela Funcionário está presente; para cada dependente registrado, deve haver um funcionário que esteja vinculado a ele. Sem a existência da tabela Funcionário, a tabela Dependente não teria razão de existir.

Entidades fortes e fracas podem ter um relacionamento. Por exemplo, a entidade Aluno pode estar relacionada à entidade Curso. Desta forma, é preciso entender também as variações do número de relacionamentos, ou melhor, a cardinalidade pelas quais as entidades se relacionam, pois, como vimos no exemplo anterior, a entidade Curso pode estar relacionada a várias entidades Aluno ao mesmo tempo, porém, nem sempre a entidade Aluno pode estar relacionada a várias entidades Curso.

Assim, segundo Sordi (2019), há na literatura menções a quatro tipos de variações de cardinalidades pelas quais as entidades se relacionam: um para um (1:1), um para muitos (1:M); muitos para um (M:1) e muitos para muitos (M:N). Como a relação muitos para um é a leitura inversa da relação um para muitos, a maioria dos autores acaba por excluí-la da tipologia. Essas designações têm um caráter mais geral, sendo menos detalhadas e precisas. Elas se referem aos valores máximos das cardinalidades em ambos os sentidos da relação. Por exemplo, a relação um para muitos (1:M) indica que a instância de uma entidade está relacionada a várias instâncias de outra entidade, sem entrar em pormenores sobre as cardinalidades mínimas de ambas no que diz respeito ao relacionamento. A seguir, descrevemos cada uma das quatro variações em mais detalhes.

Um para um (1:1): na relação de cardinalidade um para um, cada instância de uma entidade está ligada a uma única instância de outra entidade. Para ilustrar o cenário, considere uma empresa que fornece um dispositivo de comunicação (um celular) a cada um de seus funcionários de vendas. A Figura 1 mostra um extrato do modelo de entidade-relacionamento (MER) relacionado ao sistema de alocação de ativos dessa empresa. Neste caso, cada vendedor possui exatamente um telefone celular, e cada celular está atribuído a um único vendedor. Assim, a relação de um para um é válida nos dois sentidos, indicando a quantidade máxima de relações permitidas em ambos os lados da interligação.

Um para muitos (1:M): Na relação de cardinalidade um para muitos, a instância de uma entidade está associada a várias instâncias de outra entidade. Por exemplo, consideremos o caso de uma escola em que cada criança deve ter o nome e o número de telefone de um adulto responsável. Dado que um pai ou mãe pode ter mais de uma criança matriculada na mesma escola, é possível que um responsável cuide de várias crianças na instituição. Dessa forma, uma única instância da entidade Responsável pode estar relacionada com várias instâncias da entidade Aluno. No sistema de gerenciamento de matrículas da escola, o modelo de entidade-relacionamento (MER) pode ser representado como na Figura 2, o que permite que cada responsável esteja vinculado a mais de um aluno no sistema de registro da escola.

Muitos para um (M:1): a relação muitos para um é a inversa da relação um para muitos. Conforme ilustrado na Figura 2, na parte superior, a leitura ocorre da esquerda para a direita, o que significa que vários alunos podem ter o mesmo responsável, mas cada um deles possui, no máximo, um responsável. Ao ler o modelo de entidade e relacionamento (MER) da esquerda para a direita, ou seja, no contexto de muitos para um, observamos que um Aluno está associado a um único Responsável.

Muitos para muitos (M:N): na relação muitos para muitos, a instância de uma entidade pode estar relacionada com várias instâncias de outra entidade, e vice-versa. Na Figura 3, apresenta-se um cenário típico, no qual uma instância da entidade Aluno está matriculada em várias disciplinas, estabelecendo relacionamentos com diversas instâncias da entidade Disciplina.

Siga em Frente...

Para Silberschatz, Korth e Sudarshan (2020), é preciso haver uma maneira de especificar as entidades dentro de determinado conjunto de entidades e relacionamentos. Para tanto, se faz necessário o uso de chaves. Segundo Alves (2020), chave é o componente de uma relação que pode ser formada por um ou mais atributos, cuja função é permitir identificar uma linha na relação ou registro em uma tabela. Uma chave pode ser classificada como superchave, chave primária e chave estrangeira.

Uma superchave é uma restrição que impede a ocorrência de valores idênticos em atributos de duas ou mais entidades distintas. Em termos simples, isso possibilita a identificação única de uma linha dentro de uma relação. Em algumas situações, é possível que uma superchave contenha atributos que não sejam necessários para essa identificação única da linha. Por exemplo, em uma tabela de registros de clientes, a combinação do código e do número de CPF pode formar uma superchave. No entanto, dado que o código é exclusivo para cada cliente, o CPF não se faz necessário para identificá-lo de forma única.

Já uma chave primária é um atributo ou conjunto de atributos em uma tabela que serve para identificar exclusivamente seus registros. Além disso, desempenha um papel semelhante ao de um índice, automaticamente ordenando os registros, o que determina a ordem de exibição. As chaves primárias podem ser formadas por um ou mais campos, e, neste último caso, são conhecidas como chaves compostas. Uma chave primária garante que não haja registros duplicados, ou seja, nenhum valor pode se repetir nos campos que a compõem, o que otimiza a velocidade de pesquisa. Por exemplo, ao procurar um registro em um banco de dados de clientes com base no número de CPF, se esse campo for uma chave primária, a busca será mais rápida.

Ao escolher os campos para definir uma chave primária, dois critérios principais devem ser considerados. Em primeiro lugar, deve-se optar por campos de tamanho reduzido para acelerar as atualizações e consultas da chave primária. Da mesma forma, quando se trata de uma chave composta, deve-se minimizar o número de campos incluídos. O segundo critério diz respeito à estabilidade do valor armazenado no campo da chave primária. Esse valor deve ser constante, ou seja, não deve ser alterado frequentemente, porque os bancos de dados usam a chave primária para estabelecer relações entre tabelas.

No entanto, em algumas situações, um campo que faz parte da chave primária pode precisar ser atualizado. Por exemplo, em uma tabela de cadastro de produtos na qual o campo de código do produto contém o código de barras da embalagem, pode ser necessário alterá-lo. Nesse caso, o procedimento correto seria adicionar um novo registro e desabilitar o antigo para não perder o histórico do produto. Os sistemas de bancos de dados relacionais também oferecem a opção de atualização em cascata, que atualiza automaticamente os valores nas tabelas relacionadas quando um campo de chave primária é alterado. No entanto, isso pode afetar o desempenho, especialmente com um grande número de registros para atualizar.

Idealmente, os campos de chaves primárias devem ser compostos por valores sequenciais, calculados pelo sistema, seja por meio do SGBD ou por rotinas do aplicativo que utiliza o banco de dados. É importante notar que os campos que compõem chaves primárias devem ser obrigatoriamente preenchidos.

Quanto às chaves estrangeiras, elas têm a função de estabelecer relações entre os registros de uma tabela com os registros de outra por meio da chave primária desta última. Para ilustrar esse conceito, considere duas tabelas com as seguintes características:

1. Uma tabela de registro de áreas de livros, na qual há um campo de código de área (Codigo_Area) designado como chave primária.
2. Uma tabela de registro de livros que inclui um campo de código de área ao qual o livro pertence (Codigo_Area).

É notável que o campo chamado Codigo_Area está presente nas duas tabelas, mas na tabela de registro de livros, ele não é a chave primária. No entanto, é utilizado para estabelecer uma relação com a tabela de áreas, na qual o campo Codigo_Area é a chave primária. Esse campo, nesse contexto, é conhecido como chave estrangeira.

Ainda segundo Alves (2020), além da função principal de estabelecer relações entre tabelas, as chaves estrangeiras também são amplamente utilizadas para fornecer valores de outra tabela, a qual contém a chave primária. Por exemplo, podemos incorporar uma caixa de seleção na tela de cadastro de um aplicativo de gerenciamento, permitindo aos usuários escolher a área de um livro, em vez de digitarem manualmente o código da área. Isso não apenas simplifica a entrada de informações, como também reduz a probabilidade de erros nos dados inseridos. Embora seja comum que o nome do campo (ou conjunto de campos) que define a chave primária seja o mesmo da chave estrangeira, não há impedimento para que eles sejam diferentes.

Vamos Exercitar?

Com toda bagagem adquirida até aqui, já possível construir nossas próprias modelagens através do MER. Com os aprendizados de hoje, você, caro estudante, saberá diferenciar entidades fracas e fortes, os tipos de cardinalidades em relacionamentos entre entidades bem como os tipos de chaves. Continue avançando seus estudos sobre MER e revise o conteúdo visto até aqui, procurando colocá-lo em prática. Lembre-se de que participar do processo de modelagem de dados visando, no futuro, a concepção de um banco de dados é muito enriquecedor, pois agrega experiência à vida profissional.

Saiba Mais

Para uma melhor compreensão dos assuntos abordados em aula, recomendamos a leitura das referências e, como complemento, do artigo Um roteiro para facilitar o ensino e o aprendizado na elaboração de projetos conceituais de bancos de dados, de José Ferreira Prata, que propõe um roteiro para a elaboração de modelos conceituais de banco de dados, abordando a busca por tabelas e estabelecendo relacionamentos entre elas.

PRATA, J. F. Um roteiro para facilitar o ensino e o aprendizado na elaboração de projetos conceituais de bancos de dados. Exacta, São Paulo, v. 4, n. 1, p. 113-121, jan./jun. 2006.

Referências Bibliográficas

ALVES, W. P. Banco de dados: teoria e desenvolvimento. 2. ed. São Paulo: Érica, 2020.

ELMASRI, R.; NAVATHE, S. B. Sistemas de banco de dados. 7. ed. São Paulo: Pearson Education do Brasil, 2018.

MACHADO, F. N. R. Banco de dados: projeto e implementação. 4. ed. São Paulo: Érica, 2020.

SILBERSCHATZ, A.; KORTH, H.; SUDARSHAN, S. Sistema de banco de dados. 7. ed. Rio de Janeiro: LTC, 2020.

SORDI, J. O. de. Modelagem de dados: estudos de casos abrangentes da concepção lógica à implementação. 1. ed. São Paulo: Érica, 2019.

Videoaula de Encerramento

Estudante, esta videoaula foi preparada especialmente para você. Nela, você irá aprender conteúdos importantes para a sua formação profissional. Vamos assisti-la? 
Bons estudos!

Ponto de Chegada

Olá, estudante! Para desenvolver a competência desta unidade, isto é, compreender e ser capaz de elaborar uma modelagem de dados utilizando a modelagem entidade-relacionamento (MER) e seus elementos, é necessário que você pratique a leitura de vários conteúdos relacionados ao tema em paralelo a este material. Estudamos, nesta unidade, um conteúdo rico em teoria que foi tratado cuidadosamente para que pudesse ser consultado na hora de praticar as modelagens e de resolver os exercícios. Para um maior aprofundamento dos estudos neste tema, você deverá, primeiramente, ter claras as diferenciações de alguns conceitos, como de entidade fraca, forte e associativa, de generalizações/especializações de entidades, seus atributos e relacionamentos, bem como de sua cardinalidade, dentre outros tópicos que foram abordados ao decorrer da unidade. É de suma importância estar ciente de em qual contexto se está inserido para posteriormente saber identificar oportunidades de melhorias em modelagem de dados.

É Hora de Praticar!

Flores Brasil é uma floricultura que trabalha com entregas de flores e presentes. Em datas especiais, o volume de pedidos aumenta consideravelmente. Para otimizar esse processo, será desenvolvido um software baseado na web. Sua tarefa, então, consistirá em criar um modelo conceitual para o banco de dados da floricultura.

Aqui estão os requisitos essenciais já identificados:

• É necessário registrar informações de clientes, pedidos, locais de entrega e produtos.
• Um cliente pode fazer vários pedidos, mas cada pedido está vinculado a um único cliente.
• Cada pedido pode conter diversos produtos.
• Os produtos são categorizados por tipo, como flores, chocolates, presentes, cartões etc.
• Cada pedido deve estar associado a um local de entrega.
• O controle de pagamento não é necessário, pois será tratado via cartão de crédito. 

Com base nos requisitos mencionados, você deve criar um modelo conceitual visual e responder às seguintes perguntas: 

• Quais tabelas farão parte do modelo conceitual?

Como será representado graficamente o relacionamento entre essas tabelas no modelo conceitual?

Reflita

Algumas perguntas para reflexão:

• Na sua opinião, é possível criar o modelo lógico sem ter criado o modelo conceitual antes?
• O que significa, na prática, um relacionamento um para muitos? E muitos para muitos?
• Qual é a diferença principal entre chave primária e chave estrangeira?

Resolução do estudo de caso

Uma possível representação de um modelo conceitual pode ser visualizada na figura a seguir, na qual se tem uma visão geral do funcionamento da floricultura com base nos requisitos fornecidos. Esse modelo servirá como ponto de partida para a próxima fase de desenvolvimento, que é a criação do modelo lógico.

Dê o play!

Assimile

Caro estudante, a seguir apresentamos um resumo dos principais temas abordados nesta unidade de forma simples e objetiva. Reserve um tempo para leitura desse material e reflita.

Referências

ALVES, W. P. Banco de dados: teoria e desenvolvimento. 2. ed. São Paulo: Érica, 2020.

ELMASRI, R.; NAVATHE, S. B. Sistemas de banco de dados. 7. ed. São Paulo: Pearson Education do Brasil, 2018.

MACHADO, F. N. R. Banco de dados: projeto e implementação. 4. ed. São Paulo: Érica, 2020.

SILBERSCHATZ, A.; KORTH, H.; SUDARSHAN, S. Sistema de banco de dados. 7. ed. Rio de Janeiro: LTC, 2020.

SORDI, J. O. de. Modelagem de dados: estudos de casos abrangentes da concepção lógica à implementação. 1. ed. São Paulo: Érica, 2019.