Qual dos itens abaixo não representa um tipo de relacionamento em um BD relacional

Quando se inicia o desenvolvimento de um novo sistema, ou mesmo de uma nova funcionalidade para um sistema existente, um dos primeiros passos a ser executado � o estudo e levantamento dos requisitos necess�rios para a constru��o do produto final. Durante essa an�lise, identifica-se as principais partes e objetos envolvidos, suas poss�veis a��es e responsabilidades, suas caracter�sticas e como elas interagem entre si.

A partir das informa��es obtidas, pode-se desenvolver um modelo conceitual que ser� utilizado para orientar o desenvolvimento propriamente dito, fornecendo informa��es sobre os aspectos relacionados ao dom�nio do projeto em quest�o.

Saiba mais sobre levantamento de requisitos na Engenharia de Software.

Modelo Entidade Relacionamento

O Modelo Entidade Relacionamento (tamb�m chamado Modelo ER, ou simplesmente MER), como o nome sugere, � um modelo conceitual utilizado na Engenharia de Software para descrever os objetos (entidades) envolvidos em um dom�nio de neg�cios, com suas caracter�sticas (atributos) e como elas se relacionam entre si (relacionamentos).

Em geral, este modelo representa de forma abstrata a estrutura que possuir� o banco de dados da aplica��o. Obviamente, o banco de dados poder� conter v�rias outras entidades, tais como chaves e tabelas intermedi�rias, que podem s� fazer sentido no contexto de bases de dados relacionais.

Observa��o: Nem sempre criaremos modelos para um sistema completo, pois isso poderia resultar em um modelo muito extenso e dif�cil de interpretar. Dependendo da magnitude do que estaremos desenvolvendo, podemos criar modelos apenas para uma parte do sistema, um m�dulo, ou mesmo uma funcionalidade. Imagine, por exemplo, um sistema ERP de grande porte que contemple vendas, finan�as, recursos humanos, etc. V�rias entidades est�o presentes em mais de uma parte do sistema, mas n�o seria muito interessante, e provavelmente nem mesmo necess�rio, criar um �nico modelo para todo o sistema, por isso pode-se dividir a modelagem em v�rias partes menores.

Entidades

Os objetos ou partes envolvidas um dom�nio, tamb�m chamados de entidades, podem ser classificados como f�sicos ou l�gicos, de acordo sua exist�ncia no mundo real. Entidades f�sicas: s�o aquelas realmente tang�veis, existentes e vis�veis no mundo real, como um cliente (uma pessoa, uma empresa) ou um produto (um carro, um computador, uma roupa). J� as entidades l�gicas s�o aquelas que existem geralmente em decorr�ncia da intera��o entre ou com entidades f�sicas, que fazem sentido dentro de um certo dom�nio de neg�cios, mas que no mundo externo/real n�o s�o objetos f�sicos (que ocupam lugar no espa�o). S�o exemplos disso uma venda ou uma classifica��o de um objeto (modelo, esp�cie, fun��o de um usu�rio do sistema).

S�rie: Levantamento de Requisitos

As entidades s�o nomeadas com substantivos concretos ou abstratos que representem de forma clara sua fun��o dentro do dom�nio. Exemplos pr�ticos de entidades comuns em v�rios sistemas s�o Cliente, Produto, Venda, Turma, Fun��o, entre outros.

Podemos classificar as entidades segundo o motivo de sua exist�ncia:

• Entidades fortes: s�o aquelas cuja exist�ncia independe de outras entidades, ou seja, por si s� elas j� possuem total sentido de existir. Em um sistema de vendas, a entidade produto, por exemplo, independe de quaisquer outras para existir.
• Entidades fracas: ao contr�rio das entidades fortes, as fracas s�o aquelas que dependem de outras entidades para existirem, pois individualmente elas n�o fazem sentido. Mantendo o mesmo exemplo, a entidade venda depende da entidade produto, pois uma venda sem itens n�o tem sentido.
• Entidades associativas: esse tipo de entidade surge quando h� a necessidade de associar uma entidade a um relacionamento existente. Na modelagem Entidade-Relacionamento n�o � poss�vel que um relacionamento seja associado a uma entidade, ent�o tornamos esse relacionamento uma entidade associativa, que a partir da� poder� se relacionar com outras entidades. Para melhor compreender esse conceito, tomemos como exemplo uma aplica��o de vendas em que existem as entidades Produto e Venda, que se relacionam na forma muitos-para-muitos, uma vez que em uma venda pode haver v�rios produtos e um produto pode ser vendido v�rias vezes (no caso, unidades diferentes do mesmo produto). Em determinado momento, a empresa passou a entregar brindes para os clientes que comprassem um determinado produto. A entidade Brinde, ent�o, est� relacionada n�o apenas com a Venda, nem com o Produto, mas sim com o item da venda, ou seja, com o relacionamento entre as duas entidades citadas anteriormente. Como n�o podemos associar a entidade Brinde com um relacionamento, criamos ent�o a entidade associativa "Item da Venda", que cont�m os atributos identificadores das entidades Venda e Produto, al�m de informa��es como quantidade e n�mero de s�rie, para casos espec�ficos. A partir da�, podemos relacionar o Brinde com o Item da Venda, indicando que aquele pr�mio foi dado ao cliente por comprar aquele produto especificamente.

Mais adiante veremos um exemplo pr�tico onde poderemos observar a exist�ncia dessas entidades de forma mais clara.

Relacionamentos

Uma vez que as entidades s�o identificadas, deve-se ent�o definir como se d� o relacionamento entre elas. De acordo com a quantidade de objetos envolvidos em cada lado do relacionamento, podemos classifica-los de tr�s formas:

• Relacionamento 1..1 (um para um): cada uma das duas entidades envolvidas referenciam obrigatoriamente apenas uma unidade da outra. Por exemplo, em um banco de dados de curr�culos, cada usu�rio cadastrado pode possuir apenas um curr�culo na base, ao mesmo tempo em que cada curr�culo s� pertence a um �nico usu�rio cadastrado.
• Relacionamento 1..n ou 1..* (um para muitos): uma das entidades envolvidas pode referenciar v�rias unidades da outra, por�m, do outro lado cada uma das v�rias unidades referenciadas s� pode estar ligada uma unidade da outra entidade. Por exemplo, em um sistema de plano de sa�de, um usu�rio pode ter v�rios dependentes, mas cada dependente s� pode estar ligado a um usu�rio principal. Note que temos apenas duas entidades envolvidas: usu�rio e dependente. O que muda � a quantidade de unidades/exemplares envolvidas de cada lado.
• Relacionamento n..n ou *..* (muitos para muitos): neste tipo de relacionamento cada entidade, de ambos os lados, podem referenciar m�ltiplas unidades da outra. Por exemplo, em um sistema de biblioteca, um t�tulo pode ser escrito por v�rios autores, ao mesmo tempo em que um autor pode escrever v�rios t�tulos. Assim, um objeto do tipo autor pode referenciar m�ltiplos objetos do tipo t�tulo, e vice versa.

Os relacionamentos em geral s�o nomeados com verbos ou express�es que representam a forma como as entidades interagem, ou a a��o que uma exerce sobre a outra. Essa nomenclatura pode variar de acordo com a dire��o em que se l� o relacionamento. Por exemplo: um autor escreve v�rios livros, enquanto um livro � escrito por v�rios autores.

Atributos

Atributos s�o as caracter�sticas que descrevem cada entidade dentro do dom�nio. Por exemplo, um cliente possui nome, endere�o e telefone. Durante a an�lise de requisitos, s�o identificados os atributos relevantes de cada entidade naquele contexto, de forma a manter o modelo o mais simples poss�vel e consequentemente armazenar apenas as informa��es que ser�o �teis futuramente. Uma pessoa possui atributos pessoais como cor dos olhos, altura e peso, mas para um sistema que funcionar� em um supermercado, por exemplo, estas informa��es dificilmente ser�o relevantes.

Os atributos podem ser classificados quanto � sua fun��o da seguinte forma:

• Descritivos: representam caracter�stica intr�nsecas de uma entidade, tais como nome ou cor.
• Nominativos: al�m de serem tamb�m descritivos, estes t�m a fun��o de definir e identificar um objeto. Nome, c�digo, n�mero s�o exemplos de atributos nominativos.
• Referenciais: representam a liga��o de uma entidade com outra em um relacionamento. Por exemplo, uma venda possui o CPF do cliente, que a relaciona com a entidade cliente.

Quanto � sua estrutura, podemos ainda classific�-los como:

• Simples: um �nico atributo define uma caracter�stica da entidade. Exemplos: nome, peso.
• Compostos: para definir uma informa��o da entidade, s�o usados v�rios atributos. Por exemplo, o endere�o pode ser composto por rua, n�mero, bairro, etc.

Alguns atributos representam valores �nicos que identificam a entidade dentro do dom�nio e n�o podem se repetir. Em um cadastro de clientes, por exemplo, esse atributo poderia ser o CPF. A estes chamamos de Chave Prim�ria.

S�rie: MVC e Regras de neg�cio.

J� os atributos referenciais s�o chamados de Chave Estrangeira e geralmente est�o ligados � chave prim�ria da outra entidade. Estes termos s�o bastante comuns no contexto de bancos de dados. Mantendo o exemplo anterior, a entidade cliente tem como chave prim�ria seu CPF, assim, a venda possui tamb�m um campo �CPF do cliente� que se relaciona com o campo CPF da entidade cliente.

Diagrama Entidade Relacionamento

Enquanto o MER � um modelo conceitual, o Diagrama Entidade Relacionamento (Diagrama ER ou ainda DER) � a sua representa��o gr�fica e principal ferramenta. Em situa��es pr�ticas, o diagrama � tido muitas vezes como sin�nimo de modelo, uma vez que sem uma forma de visualizar as informa��es, o modelo pode ficar abstrato demais para auxiliar no desenvolvimento do sistema. Dessa forma, quando se est� modelando um dom�nio, o mais comum � j� criar sua representa��o gr�fica, seguindo algumas regras.

O diagrama facilita ainda a comunica��o entre os integrantes da equipe, pois oferece uma linguagem comum utilizada tanto pelo analista, respons�vel por levantar os requisitos, e os desenvolvedores, respons�veis por implementar aquilo que foi modelado.

Em sua nota��o original, proposta por Peter Chen (idealizador do modelo e do diagrama), as entidades deveriam ser representadas por ret�ngulos, seus atributos por elipses e os relacionamentos por losangos, ligados �s entidades por linhas, contendo tamb�m sua cardinalidade (1..1, 1..n ou n..n). Por�m, nota��es mais modernas abandonaram o uso de elipses para atributos e passaram a utilizar o formato mais utilizado na UML, em que os atributos j� aparecem listados na pr�pria entidade. Essa forma torna o diagrama mais limpo e f�cil de ser lido.

Observe na Figura 1 um exemplo simples de um diagrama para um sistema de imobili�rias.

No dom�nio representado pelo diagrama acima temos as seguintes entidades e relacionamentos:

• Propriet�rio contata Corretor (um propriet�rio pode contatar v�rios corretores e um corretor pode ser contatado por v�rios propriet�rios).
• Corretor atende Inquilino (um corretor pode atender v�rios inquilinos e um inquilino pode ser atendido por v�rios corretores).
• Inquilino aluga Im�vel (um inquilino aluga um im�vel e um im�vel pode ser alugado por v�rios inquilinos).
• Propriet�rio possui Im�vel (um propriet�rio possui v�rios im�veis e um im�vel pertence a apenas um propriet�rio).

Uma variante da Figura 1 pode ser vista na Figura 2, onde a cardinalidade do relacionamento � exibida junto do losango.

Uma outra varia��o j� mostra a cardinalidade de uma forma mais completa, deixando claro as possibilidades de n�meros de objetos envolvidos em cada relacionamento. Nesse modelo, em cada lado do relacionamento os n�meros aparecem no formato (X,Y) ao inv�s de um �nico n�mero como vemos nas figuras anteriores. A Figura 3 ilustra um exemplo desse tipo.

Saiba mais sobre Cardinalidade

Neste diagrama, lemos os relacionamentos da seguinte forma:

• 1 ou 1 grupo possui 0 ou muitos produtos. Como de um lado temos �1 ou 1�, isso equivale a apenas �1�, pois n�o temos v�rias possibilidades. J� do lado do produto, indicamos que um grupo pode possuir nenhum produto, mas tamb�m pode possuir v�rios.
• 0 ou v�rias vendas cont�m 1 ou muitos produtos. Ou seja, um produto pode nunca ser vendido (0 vendas) como tamb�m pode ser vendido v�rias vezes (n vendas). J� uma venda deve conter 1 ou v�rios produtos, pois uma venda n�o pode estar vazia (0 produtos).

Os atributos, como j� foi dito, podem aparecer no diagrama na forma de elipses ligadas �s entidades. Essa foi a nota��o original proposta, mas como podemos ver na Figura 4, ela deixa o diagrama com muitos itens e pode atrapalhar um pouco a organiza��o destes.

Em uma nota��o mais atual, comumente utilizada na UML, os atributos aparecem listados dentro do pr�prio ret�ngulo da entidade, enquanto o nome da entidade aparece no topo na forma de t�tulo. Na Figura 5 temos um exemplo.

Ferramentas CASE

Do ingl�s Computer-Aided Software Engineering, as chamadas ferramentas CASE s�o aquelas baseadas em computadores (softwares) utilizadas na Engenharia de Software para aux�lio nas atividades desde an�lise de requisitos at�, modelagem de dados.

Voc� tamb�m pode gostar: React Native: do Hello World ao CRUD

No contexto desse artigo, as ferramentas CASE permitem a cria��o de diagramas de forma simples em um ambiente de f�cil utiliza��o e com recursos para incluir as principais regras de composi��o dos diagramas. Exemplos comuns desse tipo de ferramenta s�o: Star UML, Astah e ERwin Data Modeler. Na Figura 6 vemos um exemplo de diagrama sendo constru�do no Astah.

Al�m dessas ferramentas espec�ficas, alguns IDEs (Integrated Development Environment ou Ambiente de Desenvolvimento Integrado) como o Visual Studio e ferramentas de gerenciamento de bancos de dados como SQL Server Management Studio possuem funcionalidades para criar diagramas facilmente e j� gerar o c�digo equivalente (SQL para cria��o das tabelas, chaves e relacionamentos, por exemplo).

Saiba mais sobre como criar diagramas com o Astah

Exemplo pr�tico

Para fixar tudo que foi visto ao longo deste artigo, vamos agora desenvolver um pequeno exemplo pr�tico em que modelaremos um sistema de bibliotecas, focando especificamente no empr�stimo de livros.

Primeiramente precisamos identificar as entidades envolvidas nesse contexto. Sabemos que as entidades f�sicas existentes s�o o Usu�rio da biblioteca e o Livro que ser� emprestado. Al�m disso, consideraremos aqui que o livro pertence a uma Sess�o, que ajuda na organiza��o das obras do acervo. Em um sistema real pode haver outras informa��es sobre o livro, mas para esse exemplo a sess�o � o bastante. Por fim, temos a entidade l�gica Empr�stimo, que tanto est� relacionada com o usu�rio, quanto com o livro.

Assim j� podemos esbo�ar nosso primeiro diagrama, simples, contendo as principais entidades e o relacionamento entre elas (Figura 7).

Neste primeiro diagrama podemos identificar alguns dos conceitos vistos:

• Entidades fortes: Usu�rio, Livro e Sess�o;
• Entidades fracas: Empr�stimo;
• Relacionamentos: um Usu�rio efetua v�rios Empr�stimos, v�rios Empr�stimos cont�m v�rios Livros, v�rios Livros pertencem a uma Sess�o.

Agora que visualizamos o dom�nio no diagrama, podemos adicionar os atributos e outras entidades que se fa�am necess�rias. Assim, passamos � Figura 8,

Neste ponto cabe fazer algumas observa��es importantes:

Especificamos os atributos de cada entidade e marcamos algumas elas com um asterisco, indicando que aquela � a chave prim�ria da tabela, ou seja, um atributo �nico, que nunca poder� se repetir entre as entidades do mesmo tipo. Note que neste momento ainda n�o � necess�rio especificar o tipo de cada atributo (texto, n�mero, data, etc.), isso s� ser� necess�rio mais adiante, quando j� estivermos planejando o banco de dados da aplica��o.

Surgiu a entidade associativa Livro_Empr�stimo, que representa os livros contidos em um empr�stimo (considerando um empr�stimo cont�m v�rios livros e um livro pode estar contido em v�rios empr�stimos). Esta entidade � composta pelas chaves das duas entidades principais. Se fosse necess�rio, nesta entidade tamb�m poder�amos adicionar informa��es complementares como quantidade (n�o se aplica neste caso, mas caberia em um sistema de vendas, por exemplo) e observa��es sobre o item.

Na entidade associativa, o relacionamento n..n foi dividido em dois relacionamentos do tipo 1..n, agora lidos da seguinte forma: um empr�stimo cont�m v�rios itens, mas um item s� pode estar contido em um �nico empr�stimo (restrito pelas chaves prim�rias); um livro pode estar contido em v�rios itens de empr�stimo (ser emprestado v�rias vezes), mas cada item refere-se a um �nico livro.

O Modelo Entidade Relacionamento (e principalmente o diagrama) � uma importante ferramenta durante o desenvolvimento de sistemas, principalmente aqueles mais complexos e dif�ceis de visualizar sem uma an�lise mais aprofundada.

A correta modelagem auxilia no correto desenvolvimento da base de dados e evita que v�rias altera��es sejam necess�rias para corrigir erros de concep��o provenientes de falhas durante a an�lise, ou ainda por problemas de comunica��o entre os membros da equipe.

• Banco de Dados
• Engenharia de Software
• Levantamento de Requisitos
• Modelagem
• UML

Confira outros conte�dos: