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

Uma grande variedade de outros modelos de banco de dados foram ou ainda são usados hoje.

Modelo de arquivo invertido

Um banco de dados construído com a estrutura de arquivo invertido foi projetado para facilitar pesquisas rápidas de texto completo. Neste modelo, o conteúdo dos dados é indexado como uma série de chaves em uma tabela de pesquisa, com os valores apontando para o local dos arquivos associados. Esta estrutura pode fornecer relatórios quase instantâneos em big data e análises, por exemplo.

Este modelo tem sido usado pelo sistema de gestão de banco de dados ADABAS da Software AG desde 1970, e ainda é suportado hoje em dia.

Modelo plano

O modelo plano é o modelo de dados mais antigo e mais simples. Ele simplesmente lista todos os dados em uma única tabela, que consiste em colunas e linhas. Para acessar ou manipular os dados, o computador tem de ler todo o arquivo plano na memória, o que torna este modelo ineficiente para todos, exceto para os menores conjuntos de dados.

Modelo multidimensional

Esta é uma variação do modelo relacional projetado para facilitar o processamento analítico melhorado. Enquanto o modelo relacional é otimizado para o processamento de transações on-line (OLTP), este modelo foi projetado para o processamento analítico on-line (OLAP).

Cada célula em um banco de dados dimensional contém dados sobre as dimensões monitoradas pelo banco de dados. Visualmente, é como uma coleção de cubos, em vez de tabelas bidimensionais.

Modelo semiestruturado

Neste modelo, os dados estruturais normalmente contidos no esquema do banco de dados são incorporados com os próprios dados. Aqui a distinção entre dados e esquema é vaga, na melhor das hipóteses. Esse modelo é útil para descrever sistemas, como certas fontes de dados baseadas na web, que tratamos como bancos de dados, mas que não podemos restringir com um esquema. Ele também é útil para descrever interações entre bancos de dados que não aderem ao mesmo esquema.

Modelo de contexto

Este modelo pode incorporar elementos de outros modelos de banco de dados, conforme necessário. Ele junta elementos de modelos orientados a objetos, semiestruturados e de rede.

Modelo associativo

Este modelo divide todos os pontos de dados com base em se eles descrevem uma entidade ou uma associação. Neste modelo, uma entidade é qualquer coisa que existe de forma independente, enquanto uma associação é algo que só existe em relação a outra coisa.

O modelo associativo estrutura os dados em dois conjuntos:

  • Um conjunto de itens, cada um com um identificador exclusivo, um nome e um tipo
  • Um conjunto de links, cada um com um identificador exclusivo e os identificadores exclusivos de uma fonte, verbo e destino. O fato armazenado tem a ver com a fonte, e cada um dos três identificadores pode se referir a um link ou a um item.

Outros modelos de bancos de dados menos comuns incluem:

  • Modelo semântico, que inclui informações sobre como os dados armazenados se relacionam com o mundo real
  • Banco de dados XML, que permite que os dados sejam especificados e até armazenados em formato XML
  • Gráfico nomeado
  • Três andares

TIPOS DE RELACIONAMENTO

De acordo com a cardinalidade existem 3 tipos básicos de relacionamentos entre as entidades.

  • RELACIONAMENTOS UM PARA MUITOS
  • RELACIONAMENTOS MUITOS PARA MUITOS
  • RELACIONAMENTOS UM PARA MUITOS

RELACIONAMENTO UM PARA MUITOS (U:M)

Um relacionamento 1:m ocorre com freqüência em situações de negócio. Às vezes ocorre em forma de árvore ou em forma hierárquica. No exemplo abaixo, temos a seguinte representação: Cada curso cadastrado possui vários alunos ligados a ele, pois cada aluno, ao ser cadastrado, deverá ser ligado a um curso obrigatóriamente. O campo codigocurso foi escolhido como chave primária na entidade CURSO, ou seja, ela não poderá se repetir. Já na tabela ALUNO, a chave primária é matricula e o codigocurso é chave estrangeira. A representação ficaria assim:

Como lemos este relacionamento:

UM CURSO MATRICULA MUITOS ALUNOS

UM ALUNO SE MATRICULA EM UM CURSO

RELACIONAMENTOS MUITOS PARA MUITOS (M:M)

Uma ocorrencia de uma entidade em A está associada a qualquer número de ocorrencias na entidade B, e cada ocorrencia da entidade em B está associada a qualquer número de ocorrencias na entidade A.

Considere o caso em que itens são vendidos. Podemos identificar imediatamente duas entidades: VENDA e ITEM. Uma venda pode consistir em muitos itens de mercadorias e um item de mercadoria pode aparecer em muitas vendas. Não estamos dizendo que um mesmo item possa ser vendido muitas vezes, mas que o tipo específico de item (por exemplo, um livro ) pode ser vendido muitas vezes; temos, portanto, um relacionamento de muitos-para-muitos (m:m) entre VENDA e ITEM. Em um relacionamento m:m, criamos uma terceira entidade, chamada entidade associativa que é usada para associar as entidades por meio de dois relacionamentos 1:m. De maneira geral, é razoavelmente fácil nomear essa terceira entidade. Nesse exemplo, essa terceira entidade, geralmente conhecida como entidade associativa, é chamada de VENDA_MERCADORIA.

Observe a ficha abaixo. Observe a representação do relacionamento. Cada uma das linhas que aparece no formulário do pedido de vendas é, em geral, conhecida no varejo como um item de linha, onde o código da mercadoria é ligado a uma venda.

A representação desse relacionamento m:m é mostrada na figura acima. Dizemos muitos para muitos porque há dois relacionamentos: CODIGO DA MERCADORIA está relacionado com muitas VENDAS e VENDA está relacionada com muitos CÓDIGOS DE MERCADORIA.

No caso do nosso exemplo, a entidade associativa é a VENDA_MERCADORIA. Podemos fazer a leitura do relacionamento acima da seguinte forma:

UMA VENDA POSSUI VÁRIOS ITENS DE MERCADORIA

CADA MERCADORIA PODERÁ ESTAR LIGADO À VÁRIAS VENDAS

Por que criamos uma terceira entidade ?

Quando temos um relacionamento m:m e precisamos manter informações sobre este relacionamento, criamos uma entidade associativa para armazenar informações sobre o relacionamento. Neste caso, armazenamos dados sobre as mercadorias vendidas. Não podemos armazenar estes dados em VENDAS, pois uma venda pode ter muitos itens e uma entidade só armazena ocorrências de valores simples. Da mesma maneira, não podemos armazenar esses dados em MERCADORIAS, porque um código de mercadoria pode aparecer em muitas vendas.

RELACIONAMENTO UM PARA UM (1:1)

São relacionamentos em que uma ocorrencia de uma entidade em A está associada no máximo a uma ocorrencia em uma entidade B e uma ocorrencia na entidade B está associada no máximo a uma ocorrencia na entidade A.

Neste relacionamento, escolhemos qual tabela irá receber a chave estrangeira, e para cada valor do campo na tabela A, há no máximo um valor na tabela B.

No exemplo mostrado na Figura abaixo podemos entender melhor este tipo de relacionamento, onde estaremos definindo que um Gerente (e somente um) gerencia um (e somente um) Departamento. Ou seja, o mesmo Gerente não pode gerenciar mais de um Departamento e um Departamento não poderá ser gerenciado por mais de um Gerente.

RELACIONAMENTOS RECURSIVOS OU AUTO-RELACIONAMENTOS

Os relacionamentos recursivos (também chamados de auto-relacionamentos) são casos especiais onde uma entidade se relaciona com si própria. Apesar de serem relacionamentos muito raros, a sua utilização é muito importante em alguns casos.

Os auto-relacionamentos podem ser do tipo 1:1 (um-para-um), 1:N (um-para-muitos) ou N:M (muitosparamuitos), dependendo da política de negócio que estiver envolvida.

Exemplos deste relacionamento podem ser encontrados na chamada “explosão de materiais”, onde itens compostos são formados por muitos itens componentes; por sua vez, estes itens compostos podem ser componentes de outros itens maiores. Exemplificando, temos um automóvel, que é composto pelo chassiz, motor, direção, câmbio etc.; O motor, por sua vez, é formado pelo carburador, velas, platinado etc. Esta explosão pode ser representada pelo seguinte relacionamento:

ITEM (N) compõe (M) ITEM

sendo que o papel do ITEM é ora de componente e ora de composto.

Um outro exemplo de auto-relacionamento é o gerenciamento de funcionários,

onde o gerente é um funcionário que possui um relacionamento com outros funcionários que lhe são subordinados. Este relacionamento pode ser representado da seguinte forma:

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

FUNCIONÁRIO (1) gerencia (N) FUNCIONÁRIO

sendo que o papel do FUNCIONÁRIO é ora de gerente e ora de subordinado.

EXERCÍCIOS

Elabore o diagrama de relacionamentos e o dicionário de dados para cada caso abaixo:

  1. Uma universidade tem muitos estudantes e um estudante pode se dedicar a no máximo uma universidade.

  1. Uma aeronave pode ter muitos passageiros, mas um passageiro só pode estar em um vôo de cada vez.

  1. Uma nação possui vários estados, e um estado, muitas cidades. Um estado só poderá estar vinculado a uma nação e uma cidade só poderá estar vinculado a um estado.

  1. Um encontro de eventos esportivos pode ter muitos competidores e um competidor pode participar de mais de um evento.

  1. Um paciente pode ter muitos médicos e um médico muitos pacientes.

  1. Um aluno pode freqüentar mais mais de uma disciplina e uma mesma disciplina pode ter muitos alunos.

O que não representa um relacionamento em um BD relacional?

Um banco de dados não relacional é um banco de dados que não usa o esquema de tabela de linhas e colunas encontrado na maioria dos sistemas de banco de dados tradicionais.

Quais os tipos de relacionamento em um BD relacional?

Os relacionamentos entre dados de diferentes tabelas podem ser de três tipos:.
- 1 – 1 (um para um);.
- 1 – N (um para vários) ;.
- N – N (vários para vários);.
RELACIONAMENTO DO TIPO UM PARA UM..
RELACIONAMENTO DO TIPO UM PARA VÁRIOS..
RELACIONAMENTO DO TIPO VÁRIOS PARA VÁRIOS..

O que são relacionamentos em um banco de dados relacional?

Os relacionamentos de banco de dados são associações entre tabelas que são criadas usando instruções de junção para recuperar dados. A tabela a seguir descreve os relacionamentos do banco de dados. Ambas tabelas podem ter somente um registro de cada lado do relacionamento.