unidade2_arquitetura-de-dados

Prévia do material em texto

ARQUITETURA DEARQUITETURA DE
DADOSDADOS
UNIDADE 2 -UNIDADE 2 -
IMPLEMENTAÇÃO DOIMPLEMENTAÇÃO DO
MODELO DE ENTIDADES EMODELO DE ENTIDADES E
RELACIONAMENTOS NORELACIONAMENTOS NO
MODELO RELACIONAL E NOMODELO RELACIONAL E NO
BANCO NOSQLBANCO NOSQL
Autor: Juracy Araujo de Almeida JuniorAutor: Juracy Araujo de Almeida Junior
Revisor: Rodrigo Ramos NogueiraRevisor: Rodrigo Ramos Nogueira
INICIAR
Introdução
Após um projeto de banco de dados ter sido iniciado pelo modelo conceitual, com
elementos mais preocupados em representar o negócio, e chegado ao modelo lógico, em
que alguns aspectos mais técnicos são inseridos, como atributos e relacionamentos, é
chegado o momento de transformar para um modelo relacional, ou seja, fazer o desenho
e a construção das tabelas, atributos e seus relacionamentos para um banco de dados.
Nessa fase, ainda utilizaremos como base as diretrizes dos modelos de dados
conceituais e lógicos construídos. Também devemos avaliar uma tecnologia de banco de
dados para implementação do modelo em um repositório físico.

Autor:
Juracy Araujo de Almeida Junior
Revisor:
Rodrigo Ramos Nogueira
ARQUITETURA DE DADOS
UNIDADE 2. IMPLEMENTAÇÃO DO MODELO DE 
ENTIDADES E RELACIONAMENTOS NO MODELO 
RELACIONAL E NO BANCO NOSQL
INTRODUÇÃO 01
2.1 IMPLEMENTAÇÃO DO MODELO DE ENTIDADES E RELACIONAMENTOS NO 
MODELO RELACIONAL 02
2.2 LINGUAGEM SQL 17
2.3 IMPLEMENTAÇÃO DO MODELO DE ENTIDADES E RELACIONAMENTOS EM UM 
BANCO DE DADOS NOSQL 19
SÍNTESE 28
REFERÊNCIAS BIBLIOGRÁFICAS 29
UNIDADE 2. ARQUITETURA DE DADOS 1
Dessa forma, caro estudante, nesta unidade você irá aprender como realizar a
implementação do modelo de entidades e relacionamentos no modelo relacional, bem
como conhecer a principal linguagem de consulta a dados em um SGBD, a SQL.
Ademais, conhecer o propósito e características de um banco de dados NoSQL e como
podemos implementar um modelo de dados nesta arquitetura.
2.1 Implementação do modelo de entidades e
relacionamentos no modelo relacional
O projeto de um banco de dados é orientado pelos requisitos de negócios, que são
“traduzidos” inicialmente na modelagem conceitual. Esta apresenta o modelo conceitual,
refletindo os dados em um nível mais alto, de forma que os envolvidos no negócio
também os compreendam.
A partir disso, é desenvolvido o modelo lógico, descrevendo, com maiores detalhes, os
objetos e associações ou relacionamentos. Ambos são representados graficamente
como diagrama de entidade-relacionamento ou modelo entidade-relacionamento
(MER).
Com o MER construído, a transformação mais próxima do SGBD (Sistema de
Gerenciamento de Banco de Dados) pode ser realizada implementando as entidades, os
atributos e os relacionamentos para em um modelo relacional.
Os principais conceitos da abordagem entidade-relacionamento (ER) e modelo relacional
já foram vistos em unidades anteriores, porém é necessário complementar com outros
conteúdos importantes ao estudo em questão.
2.1.1 Conceitos complementares de entidade-relacionamento(ER)
Na abordagem entidade-relacionamento(ER), serão apresentadas as definições sobre
esquemas, estado do banco de dados e atributos no relacionamento.
Esquema é a estrutura no banco de dados que representa todas unidades lógicas, ou
seja, as entidades e atributos que estarão dentro de um esquema. A tendência é que ele
UNIDADE 2. ARQUITETURA DE DADOS 2
não sofra alterações com frequência, por isso a importância de desenvolver um bom
modelo de dados. Elmasri e Navathe explicam que “especificar um esquema correto para
o sistema de gerenciamento de banco de dados (SGBD) é extremamente importante, e o
esquema deve ser projetado com extremo cuidado” (ELMASRI; NAVATHE, 2016, p. 33).
Na Figura 1, visualizamos um exemplo de esquema com as entidades aluno e professor
e suas instâncias:
Figura 1 – Exemplo de ESQUEMA e INSTÂNCIAS. 
Fonte: Elaborada pelo autor, 2020.
Outro conceito relevante é o de estado do banco de dados, o qual podemos qualificar
como momentos das instâncias e do banco de dados. Assim, quando é criado um
esquema, o estado do banco é considerado vazio. Ao ocorrer alterações, o estado é
modificado.
Muitos estados de banco de dados podem ser construídos para
corresponder a um esquema de banco de dados em particular. Toda
vez que inserimos ou excluímos um registro ou alteramos o valor
de um item de dados com um registro, mudamos de um estado do
banco de dados para outro (ELMASRI; NAVATHE, 2016, p. 33).
UNIDADE 2. ARQUITETURA DE DADOS 3
Continuando os conceitos, temos os atributos dos relacionamentos. Além dos atributos
fazerem parte da composição das entidades, eles também podem fazer parte da
composição de um relacionamento. Quando isso ocorre, o qualificamos como atributos
dos relacionamentos. Esta representação é necessária devido a situações nas quais
um dado caracteriza a relação e precisa ser adicionado ali. Um exemplo pode ser visto
na relação entre as entidades consulta, médico e paciente, bem como na relação
podemos adicionar o atributo data_consulta. Um exemplo do atributo no relacionamento
pode ser visto no Diagrama 1.
Diagrama 1 – Atributo no relacionamento
Fonte: Elaborado pelo autor, 2020.
2.1.2 Conceitos complementares de modelagem relacional
A respeito da modelagem relacional, temos as seguintes formalizações necessárias
para sua implementação:
esquema relacional R (A1, A2, ...., An), em que R é a relação e A1...An é a lista de
atributos;
cada atributo A é o nome desempenhado por um domínio D no esquema da relação
R. Representamos dom(An) como domínio do atributo;
a relação possui o grau, que determina o número de atributos.
Complementando essa formalização:
Uma relação (ou estado de relação) r do esquema de relação R(Ap
A2, ..., An), também indicada por r(R), é um conjunto de n tuplas r =
{tp t2, ..., ím}. Cada n tuplas t é uma lista ordenada de n valores t =
UNIDADE 2. ARQUITETURA DE DADOS 4
Essa formalização é materializada na Tabela 1, em que é demonstrada a relação
fornecedor, formado pelo conjunto de três tuplas, sendo cada tupla uma lista de atributos
e valores. Ainda na Tabela 1, é demonstrada a referência o valor da segunda tupla do
atributo, endereço que possui o valor de “Rua São Pedro n. 10”.
Tabela 1 – Relação fornecedor
<v1, v2, ..., vn>, em que cada valor v., 1 <i < n, é um elemento de
dom (Ai) ou é um valor especial NULL. O valor i-ésimo na tupla t,
que corresponde ao atributo Ai, é referenciado como t[Ai] ou t.Ai
(ou t[i] na notação posicional) (VICCI, 2015, p. 74).
RELAÇÃO/TABELA: FORNECEDOR
NOMEFORN ENDERECO
BOMPRECO
RUA SÃO 
PEDRO
N10
RUA
CARLOS 
COSTA
FERREIRASA
BAIRRO ESTADO
AV. BRASIL
N22
BRASILCAFE
SÃO
GONCALO
PITUBA
RJ
3 tuplas
BARRA
BA
RUA
CARLOS 
COSTA
t2[ENDERECO] = RUA SÃO
PEDRO N10
Essa formalização é materializada na Tabela 1, em que é demonstrada a relação
fornecedor, formado pelo conjunto de três tuplas, sendo cada tupla uma lista de atributos
e valores. Ainda na Tabela 1, é demonstrada a referência o valor da segunda tupla do
atributo, endereço que possui o valor de “Rua São Pedro n. 10”.
Tabela 1 – Relação fornecedor
<v1, v2, ..., vn>, em que cada valor v., 1 <i < n, é um elemento de
dom (Ai) ou é um valor especial NULL. O valor i-ésimo na tupla t,
que corresponde ao atributo Ai, é referenciado como t[Ai] ou t.Ai
(ou t[i] na notação posicional) (VICCI, 2015, p. 74).
RELAÇÃO/TABELA: FORNECEDOR
NOMEFORN ENDERECO
BOMPRECO
RUA SÃO 
PEDRO
N10
RUA
CARLOS 
COSTA
FERREIRASA
BAIRRO ESTADO
AV. BRASIL
N22
BRASILCAFE
SÃO
GONCALO
PITUBA
RJ
3 tuplas
BARRA
BA
RUA
CARLOS 
COSTA
t2[ENDERECO] = RUA SÃO
PEDRO N10
Essa formalização é materializada na Tabela 1, em que é demonstrada a relação
fornecedor, formado pelo conjunto de três tuplas, sendo cada tupla uma lista de atributos
e valores. Ainda na Tabela 1, é demonstrada a referência o valor da segunda tupla do
atributo, endereço que possui o valor de “Rua São Pedro n. 10”.
Tabela 1 – Relação fornecedor
<v1, v2, ..., vn>, em que cada valor v., 1 <i < n, é um elemento de
dom (Ai)ou é um valor especial NULL. O valor i-ésimo na tupla t,
que corresponde ao atributo Ai, é referenciado como t[Ai] ou t.Ai
(ou t[i] na notação posicional) (VICCI, 2015, p. 74).
RELAÇÃO/TABELA: FORNECEDOR
NOMEFORN ENDERECO
BOMPRECO
RUA SÃO 
PEDRO
N10
RUA
CARLOS 
COSTA
FERREIRASA
BAIRRO ESTADO
AV. BRASIL
N22
BRASILCAFE
SÃO
GONCALO
PITUBA
RJ
3 tuplas
BARRA
BA
RUA
CARLOS 
COSTA
t2[ENDERECO] = RUA SÃO
PEDRO N10
Essa formalização é materializada na Tabela 1, em que é demonstrada a relação
fornecedor, formado pelo conjunto de três tuplas, sendo cada tupla uma lista de atributos
e valores. Ainda na Tabela 1, é demonstrada a referência o valor da segunda tupla do
atributo, endereço que possui o valor de “Rua São Pedro n. 10”.
Tabela 1 – Relação fornecedor
<v1, v2, ..., vn>, em que cada valor v., 1 <i < n, é um elemento de
dom (Ai) ou é um valor especial NULL. O valor i-ésimo na tupla t,
que corresponde ao atributo Ai, é referenciado como t[Ai] ou t.Ai
(ou t[i] na notação posicional) (VICCI, 2015, p. 74).
RELAÇÃO/TABELA: FORNECEDOR
NOMEFORN ENDERECO
BOMPRECO
RUA SÃO 
PEDRO
N10
RUA
CARLOS 
COSTA
FERREIRASA
BAIRRO ESTADO
AV. BRASIL
N22
BRASILCAFE
SÃO
GONCALO
PITUBA
RJ
3 tuplas
BARRA
BA
RUA
CARLOS 
COSTA
t2[ENDERECO] = RUA SÃO
PEDRO N10
Essa formalização é materializada na Tabela 1, em que é demonstrada a relação
fornecedor, formado pelo conjunto de três tuplas, sendo cada tupla uma lista de atributos
e valores. Ainda na Tabela 1, é demonstrada a referência o valor da segunda tupla do
atributo, endereço que possui o valor de “Rua São Pedro n. 10”.
Tabela 1 – Relação fornecedor
<v1, v2, ..., vn>, em que cada valor v., 1 <i < n, é um elemento de
dom (Ai) ou é um valor especial NULL. O valor i-ésimo na tupla t,
que corresponde ao atributo Ai, é referenciado como t[Ai] ou t.Ai
(ou t[i] na notação posicional) (VICCI, 2015, p. 74).
RELAÇÃO/TABELA: FORNECEDOR
NOMEFORN ENDERECO
BOMPRECO
RUA SÃO 
PEDRO
N10
RUA
CARLOS 
COSTA
FERREIRASA
BAIRRO ESTADO
AV. BRASIL
N22
BRASILCAFE
SÃO
GONCALO
PITUBA
RJ
3 tuplas
BARRA
BA
RUA
CARLOS 
COSTA
t2[ENDERECO] = RUA SÃO
PEDRO N10
Fonte: Elaborado pelo autor, 2020.
Outro ponto essencial do modelo relacional diz respeito às restrições de integridade.
Essas restrições são derivadas de regras estabelecidas nos requisitos de negócio ou
existentes no mundo real e que devem ser atendidas no modelo e no SGBD. Elmasri e
Navathe (2016) destacam a existência das seguintes restrições: restrições de domínio,
chave, valores NULL, integridade de entidade e integridade referencial.
As restrições de domínio tratam da atomicidade de valores em cada tupla, devendo
estar dentro de um domínio dom(A). Essa atomicidade visa evitar a repetição de valores.
O domínio pode ser definido pelos tipos de dados, como texto, data, valores numéricos
ou por intervalo de valores definidos para o atributo.
Para as restrições de chave, temos que considerar que em uma relação não se deve ter
duas ou mais tuplas com a mesma combinação de valores em todos seus atributos.
Normalmente, deve existir um subconjunto de atributos que identifique unicamente cada
tupla, denominado superchave na relação. Desse modo, o conjunto de todos os
atributos deverão representar uma superchave na relação. Ainda dentro dessa definição,
temos a chave. Uma chave é uma superchave, com a diferença que a remoção de
qualquer atributo que forme a chave a deixa sem a propriedade de identificação exclusiva
na relação.
Por exemplo, na relação PRODUTO, com a superchave cod_produto, cod_categoria,
nom_produto, podemos extrair a chave cod_produto, cod_categoria. Ou seja, essa
combinação evita que mais de uma tupla tenha o mesmo conjunto de valores. Entretanto,
se retirarmos da chave qualquer um dos atributos, ela perderá a propriedade da
exclusividade e a restrição de chave não será mais alcançada.As restrições de valores
NULL visa especificar se um atributo permite ou não valores nulos (NULL).
Setzer (2005) escreve que integridade referencial é “a restrição que define que os
valores dos campos que aparecem em uma chave estrangeira devem aparecer na chave
primária da tabela referenciada.” A chave primária é o conjunto de atributos definidos
como chave definida na relação e estabelecido no SGBD. A chave estrangeira é o
conjunto de atributos de uma relação R2 que terão o mesmo domínio da chave primária
UNIDADE 2. ARQUITETURA DE DADOS 5
Fonte: Elaborado pelo autor, 2020.
Outro ponto essencial do modelo relacional diz respeito às restrições de integridade.
Essas restrições são derivadas de regras estabelecidas nos requisitos de negócio ou
existentes no mundo real e que devem ser atendidas no modelo e no SGBD. Elmasri e
Navathe (2016) destacam a existência das seguintes restrições: restrições de domínio,
chave, valores NULL, integridade de entidade e integridade referencial.
As restrições de domínio tratam da atomicidade de valores em cada tupla, devendo
estar dentro de um domínio dom(A). Essa atomicidade visa evitar a repetição de valores.
O domínio pode ser definido pelos tipos de dados, como texto, data, valores numéricos
ou por intervalo de valores definidos para o atributo.
Para as restrições de chave, temos que considerar que em uma relação não se deve ter
duas ou mais tuplas com a mesma combinação de valores em todos seus atributos.
Normalmente, deve existir um subconjunto de atributos que identifique unicamente cada
tupla, denominado superchave na relação. Desse modo, o conjunto de todos os
atributos deverão representar uma superchave na relação. Ainda dentro dessa definição,
temos a chave. Uma chave é uma superchave, com a diferença que a remoção de
qualquer atributo que forme a chave a deixa sem a propriedade de identificação exclusiva
na relação.
Por exemplo, na relação PRODUTO, com a superchave cod_produto, cod_categoria,
nom_produto, podemos extrair a chave cod_produto, cod_categoria. Ou seja, essa
combinação evita que mais de uma tupla tenha o mesmo conjunto de valores. Entretanto,
se retirarmos da chave qualquer um dos atributos, ela perderá a propriedade da
exclusividade e a restrição de chave não será mais alcançada.As restrições de valores
NULL visa especificar se um atributo permite ou não valores nulos (NULL).
Setzer (2005) escreve que integridade referencial é “a restrição que define que os
valores dos campos que aparecem em uma chave estrangeira devem aparecer na chave
primária da tabela referenciada.” A chave primária é o conjunto de atributos definidos
como chave definida na relação e estabelecido no SGBD. A chave estrangeira é o
conjunto de atributos de uma relação R2 que terão o mesmo domínio da chave primária
estabelecida em outra relação R1. Como exemplo, a Tabela 2 representa as relações
ALUNO e SITUACAO_MATRICULA. Na relação ALUNO, o atributo cod_sit_matricula é
uma chave estrangeira que referencia a chave primária cod_sit_matricula em
SITUACAO_MATRICULA. Assim, os valores desse atributo em ALUNO devem
acompanhar o domínio do atributo na relação SITUACAO_MATRICULA.
Tabela 2 – Representação da restrição integridade referencial
Fonte: Elaborado pelo autor, 2020.
Por fim, em relação à integridade de entidade, Elmasri e Navathe (2016) explicam que
a restrição de integridade de entidade afirma que nenhum valor de chave primária pode
ser null. Isso porque o valor da chave primária é usado para identificar tuplas individuais
com uma relação.
2.1.3 Etapas e implementação da entidade-relacionamento para modelo
relacional
Neste momento, estamos na fase em que o projeto/modelo lógico está desenvolvido no
formato de modelo ER. Sendo assim, devemos iniciar o mapeamento para o modelo
relacional. Essa fase pode ser visualizada no Diagrama 2, com destaque para área
hachurada em amarelo.
Diagrama 2 – Etapas do projeto de banco de dados
UNIDADE 2. ARQUITETURA DE DADOS 6
estabelecida em outra relação R1. Como exemplo, a Tabela 2 representa as relações
ALUNO e SITUACAO_MATRICULA. Na relação ALUNO, o atributo cod_sit_matricula é
uma chave estrangeira que referenciaa chave primária cod_sit_matricula em
SITUACAO_MATRICULA. Assim, os valores desse atributo em ALUNO devem
acompanhar o domínio do atributo na relação SITUACAO_MATRICULA.
Tabela 2 – Representação da restrição integridade referencial
Fonte: Elaborado pelo autor, 2020.
Por fim, em relação à integridade de entidade, Elmasri e Navathe (2016) explicam que
a restrição de integridade de entidade afirma que nenhum valor de chave primária pode
ser null. Isso porque o valor da chave primária é usado para identificar tuplas individuais
com uma relação.
2.1.3 Etapas e implementação da entidade-relacionamento para modelo
relacional
Neste momento, estamos na fase em que o projeto/modelo lógico está desenvolvido no
formato de modelo ER. Sendo assim, devemos iniciar o mapeamento para o modelo
relacional. Essa fase pode ser visualizada no Diagrama 2, com destaque para área
hachurada em amarelo.
Diagrama 2 – Etapas do projeto de banco de dados
estabelecida em outra relação R1. Como exemplo, a Tabela 2 representa as relações
ALUNO e SITUACAO_MATRICULA. Na relação ALUNO, o atributo cod_sit_matricula é
uma chave estrangeira que referencia a chave primária cod_sit_matricula em
SITUACAO_MATRICULA. Assim, os valores desse atributo em ALUNO devem
acompanhar o domínio do atributo na relação SITUACAO_MATRICULA.
Tabela 2 – Representação da restrição integridade referencial
Fonte: Elaborado pelo autor, 2020.
Por fim, em relação à integridade de entidade, Elmasri e Navathe (2016) explicam que
a restrição de integridade de entidade afirma que nenhum valor de chave primária pode
ser null. Isso porque o valor da chave primária é usado para identificar tuplas individuais
com uma relação.
2.1.3 Etapas e implementação da entidade-relacionamento para modelo
relacional
Neste momento, estamos na fase em que o projeto/modelo lógico está desenvolvido no
formato de modelo ER. Sendo assim, devemos iniciar o mapeamento para o modelo
relacional. Essa fase pode ser visualizada no Diagrama 2, com destaque para área
hachurada em amarelo.
Diagrama 2 – Etapas do projeto de banco de dados
estabelecida em outra relação R1. Como exemplo, a Tabela 2 representa as relações
ALUNO e SITUACAO_MATRICULA. Na relação ALUNO, o atributo cod_sit_matricula é
uma chave estrangeira que referencia a chave primária cod_sit_matricula em
SITUACAO_MATRICULA. Assim, os valores desse atributo em ALUNO devem
acompanhar o domínio do atributo na relação SITUACAO_MATRICULA.
Tabela 2 – Representação da restrição integridade referencial
Fonte: Elaborado pelo autor, 2020.
Por fim, em relação à integridade de entidade, Elmasri e Navathe (2016) explicam que
a restrição de integridade de entidade afirma que nenhum valor de chave primária pode
ser null. Isso porque o valor da chave primária é usado para identificar tuplas individuais
com uma relação.
2.1.3 Etapas e implementação da entidade-relacionamento para modelo
relacional
Neste momento, estamos na fase em que o projeto/modelo lógico está desenvolvido no
formato de modelo ER. Sendo assim, devemos iniciar o mapeamento para o modelo
relacional. Essa fase pode ser visualizada no Diagrama 2, com destaque para área
hachurada em amarelo.
Diagrama 2 – Etapas do projeto de banco de dados
Fonte: Elaborado pelo autor, 2020.
Para a implementação, definimos que o mapeamento criará tabelas com atributos
simples de valor único e que no resultado teremos as restrições do modelo
relacional aplicadas, incluindo chaves primárias, únicas e de integridade referencial.
Para a implementação do modelo relacional iremos seguir e explanar sobre as nove
etapas definidas em Elmasri e Navathe (2016).
A etapa 1 trata do mapeamento de tipos de entidade regular ou forte. Neste tipo, para
cada tipo de entidade forte no ER, deve ser criada uma relação no modelo relacional.
Além disso, serão incluídos os atributos simples e os atributos compostos serão
extraídos como simples. Por fim, o atributo chave será definido como chave primária.
Existindo mais de uma chave, elas poderão ser transformadas em únicas e até apoiar
índices futuros no SGBD. A Figura 2 representa um exemplo no qual a entidade regular
ALUNO é mapeada para o modelo relacional, trazendo seus atributos e a chave como
chave primária. Apenas o atributo multivalorado telefone não foi criado, pois será tratado
em uma etapa posterior.
UNIDADE 2. ARQUITETURA DE DADOS 7
Fonte: Elaborado pelo autor, 2020.
Para a implementação, definimos que o mapeamento criará tabelas com atributos
simples de valor único e que no resultado teremos as restrições do modelo
relacional aplicadas, incluindo chaves primárias, únicas e de integridade referencial.
Para a implementação do modelo relacional iremos seguir e explanar sobre as nove
etapas definidas em Elmasri e Navathe (2016).
A etapa 1 trata do mapeamento de tipos de entidade regular ou forte. Neste tipo, para
cada tipo de entidade forte no ER, deve ser criada uma relação no modelo relacional.
Além disso, serão incluídos os atributos simples e os atributos compostos serão
extraídos como simples. Por fim, o atributo chave será definido como chave primária.
Existindo mais de uma chave, elas poderão ser transformadas em únicas e até apoiar
índices futuros no SGBD. A Figura 2 representa um exemplo no qual a entidade regular
ALUNO é mapeada para o modelo relacional, trazendo seus atributos e a chave como
chave primária. Apenas o atributo multivalorado telefone não foi criado, pois será tratado
em uma etapa posterior.
Figura 2 – Exemplo de implementação da relação ALUNO. Fonte: Elaborado pelo autor, 2020.
Na etapa 2, denominada mapeamento de tipos de entidade fraca, para cada tipo de
entidade fraca f no esquema ER, crie uma relação R e inclua todos os atributos simples,
ou componentes simples extraídos dos atributos compostos, de f como atributos de R.
Além disso, inclua como atributos de chave estrangeira em R os atributos de chave
primária da entidade forte. A chave primária será a combinação da chave estrangeira
com a chave (parcial ou atributo que não identifica sozinho a tupla) da relação R. Na
Figura 3, a entidade fraca TRANSPORTE ESCOLAR é mapeada para o modelo
relacional em uma nova relação UTILIZA_TRANSPORTE, trazendo seus atributos e a
chave primária da entidade forte, além de uma chave parcial para formar a chave
primária.
Figura 3 – Exemplo da implementação de entidades fracas TRANSPORTE _ESCOLAR para
UTILIZA_TRANSPORTE. 
Fonte: Elaborado pelo autor, 2020.
UNIDADE 2. ARQUITETURA DE DADOS 8
Figura 2 – Exemplo de implementação da relação ALUNO. Fonte: Elaborado pelo autor, 2020.
Na etapa 2, denominada mapeamento de tipos de entidade fraca, para cada tipo de
entidade fraca f no esquema ER, crie uma relação R e inclua todos os atributos simples,
ou componentes simples extraídos dos atributos compostos, de f como atributos de R.
Além disso, inclua como atributos de chave estrangeira em R os atributos de chave
primária da entidade forte. A chave primária será a combinação da chave estrangeira
com a chave (parcial ou atributo que não identifica sozinho a tupla) da relação R. Na
Figura 3, a entidade fraca TRANSPORTE ESCOLAR é mapeada para o modelo
relacional em uma nova relação UTILIZA_TRANSPORTE, trazendo seus atributos e a
chave primária da entidade forte, além de uma chave parcial para formar a chave
primária.
Figura 3 – Exemplo da implementação de entidades fracas TRANSPORTE _ESCOLAR para
UTILIZA_TRANSPORTE. 
Fonte: Elaborado pelo autor, 2020.
A etapa 3 deve realizar o mapeamento dos tipos de relacionamento binários 1:1.
Existem três técnicas que podem ser utilizadas e que podem ser vistas no Card 1.
Técnicas para mapeamento dos tipos de relacionamento binários 1:1
» Clique nas setas ou arraste para visualizar o conteúdo
Na Figura 4, por meio da técnica de chave estrangeira, é possível ver o mapeamento na
tabela CARTEIRA_ESTUDANTE, que recebeu a chave estrangeira oriunda da chave
primária em ALUNO e o atributo data_inscricao do relacionamento.
TÉCNICA DE CHAVE ESTRANGEIRA
Consideramos duas relações, S e T, e escolhemosaquela que tem
participação total, ou seja, aquela que necessariamente ocorre na
relação. Digamos que seja selecionada a relação S. Sendo assim,
colocamos todos os atributos simples (ou extraídos dos compostos)
do relacionamento em S e adicionamos a chave primária de T como
chave estrangeira em S.
 
A etapa 3 deve realizar o mapeamento dos tipos de relacionamento binários 1:1.
Existem três técnicas que podem ser utilizadas e que podem ser vistas no Card 1.
Técnicas para mapeamento dos tipos de relacionamento binários 1:1
» Clique nas setas ou arraste para visualizar o conteúdo
Na Figura 4, por meio da técnica de chave estrangeira, é possível ver o mapeamento na
tabela CARTEIRA_ESTUDANTE, que recebeu a chave estrangeira oriunda da chave
primária em ALUNO e o atributo data_inscricao do relacionamento.
TÉCNICA DE CHAVE ESTRANGEIRA
Consideramos duas relações, S e T, e escolhemos aquela que tem
participação total, ou seja, aquela que necessariamente ocorre na
relação. Digamos que seja selecionada a relação S. Sendo assim,
colocamos todos os atributos simples (ou extraídos dos compostos)
do relacionamento em S e adicionamos a chave primária de T como
chave estrangeira em S.
 
UNIDADE 2. ARQUITETURA DE DADOS 9
Técnica de
referência cruzada
ou relacionamento
Diz para construir uma 
terceira relação para ser 
o resultado da referência 
cruzada das chaves 
primárias das duas 
relações existentes.
Técnica de
chave estrangeira
Consideramos duas 
relações, S e T, e 
escolhemos aquela que tem 
participação total, ou seja, 
aquela que necessariamente 
ocorre na relação. Digamos 
que seja selecionada a 
relação S. Sendo assim, 
colocamos todos os 
atributos simples (ou 
extraídos dos compostos) 
do relacionamento em S 
e adicionamos a chave 
primária de T como chave 
estrangeira em S.
Técnica de
relação combinada
Combina dois tipos de 
entidade e relacionamento 
em uma relação, isso 
quando ambas relações 
possuem participação total.
A etapa 3 deve realizar o mapeamento dos tipos de relacionamento binários 1:1.
Existem três técnicas que podem ser utilizadas e que podem ser vistas no Card 1.
Técnicas para mapeamento dos tipos de relacionamento binários 1:1
» Clique nas setas ou arraste para visualizar o conteúdo
Na Figura 4, por meio da técnica de chave estrangeira, é possível ver o mapeamento na
tabela CARTEIRA_ESTUDANTE, que recebeu a chave estrangeira oriunda da chave
primária em ALUNO e o atributo data_inscricao do relacionamento.
TÉCNICA DE CHAVE ESTRANGEIRA
Consideramos duas relações, S e T, e escolhemos aquela que tem
participação total, ou seja, aquela que necessariamente ocorre na
relação. Digamos que seja selecionada a relação S. Sendo assim,
colocamos todos os atributos simples (ou extraídos dos compostos)
do relacionamento em S e adicionamos a chave primária de T como
chave estrangeira em S.
 
Figura 4 – Mapeamento para o tipo binário 1:1. 
Fonte: Elaborado pelo autor, 2020.
A etapa 4 deve realizar o mapeamento dos tipos de relacionamento binários 1:N.
Nesta etapa, é selecionada a relação S participante do lado N no relacionamento. Então,
devemos alocar todos os atributos simples (ou extraídos dos compostos) do
relacionamento em S e adicionar a chave primária de T como chave estrangeira em S.
Observe que se o inverso for feito, a relação T terá seus valores repetidos, de acordo
com as ocorrências de S. Outro detalhe é que essa estrutura também deve ser aplicada
em caso de autorrelacionamento.
A Figura 5 representa o mapeamento 1:N, em que a tabela ESCOLA exporta sua chave
primária cod_escola como chave estrangeira para tabela ALUNO.
UNIDADE 2. ARQUITETURA DE DADOS 10
Figura 4 – Mapeamento para o tipo binário 1:1. 
Fonte: Elaborado pelo autor, 2020.
A etapa 4 deve realizar o mapeamento dos tipos de relacionamento binários 1:N.
Nesta etapa, é selecionada a relação S participante do lado N no relacionamento. Então,
devemos alocar todos os atributos simples (ou extraídos dos compostos) do
relacionamento em S e adicionar a chave primária de T como chave estrangeira em S.
Observe que se o inverso for feito, a relação T terá seus valores repetidos, de acordo
com as ocorrências de S. Outro detalhe é que essa estrutura também deve ser aplicada
em caso de autorrelacionamento.
A Figura 5 representa o mapeamento 1:N, em que a tabela ESCOLA exporta sua chave
primária cod_escola como chave estrangeira para tabela ALUNO.
Figura 5 – Representação da restrição integridade referencial. 
Fonte: Elaborado pelo autor, 2020.
A etapa 5 deve realizar o mapeamento dos tipos de relacionamento binários N:N.
Para relacionamentos N:N, deve-se criar uma relação S para representar o
relacionamento R. Inclua todos os atributos simples (ou extraídos dos compostos) do
relacionamento e adicione as chaves primária das relações como chave estrangeira na
relação S, sendo que sua combinação formará a chave primária em S. Na Figura 6,
verifica-se que a tabela ALUNO_DISCIPLINA foi criada a partir da união das chaves
primárias de ALUNO e DISCIPLINA mais o atributo do relacionamento, representando,
assim, a implementação para relações dos tipos de relacionamento binários N:N.
UNIDADE 2. ARQUITETURA DE DADOS 11
Figura 6 – Representação do mapeamento dos tipos de relacionamento binários N:N. 
Fonte: Elaborado pelo autor, 2020.
Na etapa 6, denominada mapeamento de atributos multivalorados, os atributos
multivalorados serão tratados com a criação de uma nova relação para cada um desses
atributos. Para cada atributo multivalorado na relação F, crie uma relação R, que será
formada pelo atributo correspondente ao atributo multivalorado mais o atributo chave
primária da relação F. Este último será uma chave estrangeira em R. A chave primária da
relação R será a combinação desses dois atributos. A Figura 7 representa um exemplo
com a criação da tabela ALUNO_TELEFONE, tratando o atributo multivalorado telefone.
UNIDADE 2. ARQUITETURA DE DADOS 12
Figura 7 – Representação do mapeamento de atributos multivalorados. 
Fonte: Elaborado pelo autor, 2020.
A próxima é a etapa 7, que define o mapeamento de tipos de relacionamento n-ário.
Essa definição deve ser aplicada a relacionamentos envolvendo mais de duas relações.
O primeiro passo é criar uma relação S contendo todos os atributos simples (ou extraídos
dos compostos) do relacionamento e adicionar as chaves primárias das relações como
chave estrangeira. Usualmente, a chave primária de S será a combinação das chaves
estrangeiras, entretanto, se alguma das relações tiver cardinalidade 1, a chave
estrangeira não participará como chave primária. Adicionalmente, temos a etapa 8,
UNIDADE 2. ARQUITETURA DE DADOS 13
chamada de opções para mapeamento da especialização ou generalização, e a
etapa 9, conhecida como mapeamento de categorias.
Na etapa 8, a proposta é converter cada especialização a subclasses {S,, S,, ..., SJ} e à
superclasse (generalizada) C, em que os atributos (at, ...aj e ch) e a chave (primária)
estão relacionados a partir das opções elencadas no Card 2.
Técnicas para mapeamento dos tipos de relacionamento binários 1:1
» Clique nas setas ou arraste para visualizar o conteúdo
A etapa 9, a última para a implementação para o modelo relacional, trata do
mapeamento de categorias. Vicci (2015) define que uma categoria (tipo de união) é
uma subclasse da união de duas ou mais superclasses, que são capazes de terem
diferentes chaves. Assim, ao criar uma relação relativa a uma categoria, especificamos
um novo atributo chave, chamado chave substituta. Essa será a chave primária na
relação e estrangeira nas relações correspondentes à superclasse.
2.1.4 Ferramenta case e conversão para modelo físico
Após essas definições para implementação do modelo relacional, é possível, então, partir
para construção dos objetos físicos no banco de dados.
O desenho e implementação dos modelos no projeto de banco de dados, desde o
MÚLTIPLAS RELAÇÕES –
SUPERCLASSES E SUBCLASSES
Criar uma relação L1 para a superclasse C com sua chave primária e
uma relaçãoLn para cada subclasse. Os atributos da relação L1
serão os atributos da superclasse e das relações Ln serão os
atributos de cada subclasse, unindo a chave primária de L1. Essa
opção funciona em qualquer especialização.
 
chamada de opções para mapeamento da especialização ou generalização, e a
etapa 9, conhecida como mapeamento de categorias.
Na etapa 8, a proposta é converter cada especialização a subclasses {S,, S,, ..., SJ} e à
superclasse (generalizada) C, em que os atributos (at, ...aj e ch) e a chave (primária)
estão relacionados a partir das opções elencadas no Card 2.
Técnicas para mapeamento dos tipos de relacionamento binários 1:1
» Clique nas setas ou arraste para visualizar o conteúdo
A etapa 9, a última para a implementação para o modelo relacional, trata do
mapeamento de categorias. Vicci (2015) define que uma categoria (tipo de união) é
uma subclasse da união de duas ou mais superclasses, que são capazes de terem
diferentes chaves. Assim, ao criar uma relação relativa a uma categoria, especificamos
um novo atributo chave, chamado chave substituta. Essa será a chave primária na
relação e estrangeira nas relações correspondentes à superclasse.
2.1.4 Ferramenta case e conversão para modelo físico
Após essas definições para implementação do modelo relacional, é possível, então, partir
para construção dos objetos físicos no banco de dados.
O desenho e implementação dos modelos no projeto de banco de dados, desde o
MÚLTIPLAS RELAÇÕES –
SUPERCLASSES E SUBCLASSES
Criar uma relação L1 para a superclasse C com sua chave primária e
uma relação Ln para cada subclasse. Os atributos da relação L1
serão os atributos da superclasse e das relações Ln serão os
atributos de cada subclasse, unindo a chave primária de L1. Essa
opção funciona em qualquer especialização.
 
UNIDADE 2. ARQUITETURA DE DADOS 14
Criar uma relação L1 para a superclasse C com sua chave primária 
e uma relação Ln para cada subclasse. Os atributos da relação 
L1 serão os atributos da superclasse e das relações Ln serão os 
atributos de cada subclasse, unindo a chave primária de L1. Essa 
opção funciona em qualquer especialização.
Múltiplas relações 
– superclasses 
e subclasses
Criar uma única relação L com os atributos da superclasse unidos 
aos atributos das subclasses mais um atributo t, chamado de tipo, 
para identificar a qual subclasse aquela tupla pertence. A chave 
primária será a mesma superclasse. Essa opção poderá gerar 
muitos atributos nulos.
Relação única 
com um atributos 
de tipos
Criar uma relação L para cada subclasse, com seus atributos 
unidos com os da superclasse. Essa opção funciona apenas em 
especializações com participação total, em que cada entidade na 
superclasse deve pertencer, pelo menos, a uma das subclasses. 
Trata-se de uma opção recomendada caso a entidade esteja com 
restrição de disjunção, ou seja, a superclasse pode ser membro de 
somente uma das subclasses.
Múltiplas 
relações – Apenas 
subclasses
Criar uma única relação L com os atributos da superclasse unidos 
aos atributos das subclasses mais um conjunto de atributos t1..
tn para identificar a subclasse preenchida naquela tupla. Esses 
atributos t1..tn serão do tipo booleanos.
Relação única 
com atributos de 
múltiplos tipos
conceitual até o projeto físico, podem ser facilitadas com o suporte de ferramentas
denominadas como ferramentas CASE (Computer Aided Software Engineering).
VOCÊ SABIA?
As ferramentas CASE foram desenvolvidas, principalmente, para atividades de
engenharia de software, apoiando a análise, modelagem, programação e os
testes. Além disso, a abordagem entidade-relacionamento e a UML podem ser
atendidas com a construção de modelos e diagramas pelas ferramentas CASE.
Existem inúmeras ferramentas CASE, pagas e gratuitas. Nesta unidade, vamos citar
alguns recursos de uma ferramenta que irá possibilitar a implementação do modelo
relacional, geração do modelo físico e script SQL para o SGBD. A ferramenta em
questão é chamada de DB-Main.
DB-Main é uma ferramenta CASE para modelagem de dados e arquitetura de software.
Neste software, é possível mapear os dados no modelo conceitual, lógico e físico.
Após realizar o download e acessar, podemos visualizar um projeto de demonstração do
modelo lógico-conceitual e convertê-lo para o relacional. Para isso, na janela de abertura
do DB-Main, devemos clicar no botão Demo Project. Em seguida, é preciso clicar duas
vezes em LIBRARY/Conceptual. Esses passos podem ser vistos na Figura 8.
chamada de opções para mapeamento da especialização ou generalização, e a
etapa 9, conhecida como mapeamento de categorias.
Na etapa 8, a proposta é converter cada especialização a subclasses {S,, S,, ..., SJ} e à
superclasse (generalizada) C, em que os atributos (at, ...aj e ch) e a chave (primária)
estão relacionados a partir das opções elencadas no Card 2.
Técnicas para mapeamento dos tipos de relacionamento binários 1:1
» Clique nas setas ou arraste para visualizar o conteúdo
A etapa 9, a última para a implementação para o modelo relacional, trata do
mapeamento de categorias. Vicci (2015) define que uma categoria (tipo de união) é
uma subclasse da união de duas ou mais superclasses, que são capazes de terem
diferentes chaves. Assim, ao criar uma relação relativa a uma categoria, especificamos
um novo atributo chave, chamado chave substituta. Essa será a chave primária na
relação e estrangeira nas relações correspondentes à superclasse.
2.1.4 Ferramenta case e conversão para modelo físico
Após essas definições para implementação do modelo relacional, é possível, então, partir
para construção dos objetos físicos no banco de dados.
O desenho e implementação dos modelos no projeto de banco de dados, desde o
MÚLTIPLAS RELAÇÕES –
SUPERCLASSES E SUBCLASSES
Criar uma relação L1 para a superclasse C com sua chave primária e
uma relação Ln para cada subclasse. Os atributos da relação L1
serão os atributos da superclasse e das relações Ln serão os
atributos de cada subclasse, unindo a chave primária de L1. Essa
opção funciona em qualquer especialização.
 
UNIDADE 2. ARQUITETURA DE DADOS 15
Figura 8 – Captura de tela da ferramenta CASE DB-Main com demonstração do modelo conceitual.
Após seguir esse passo, aparecerá, conforme mostrado na Figura 9, uma demonstração
das entidades e relacionamentos do modelo lógico-conceitual. É possível visualizar a
entidade book (livro) relacionado a author (autor) por meio do relacionamento written
(escrito) com tipo <0-N>:<1-N>, demonstrando que um livro pode ter sido escrito por um
ou muitos autores, assim como um autor pode ter escrito de zero a muitos livros. Da
mesma maneira, visualizamos o autorrelacionamento na entidade book com o
relacionamento reference (referência).
Figura 9 – Captura de tela representando o modelo lógico-conceitual (A) e o modelo implementado para o
relacional (B).
Ainda na Figura 9, é possível verificar que podemos converter para o modelo relacional.
Para isso, é necessário ir ao menu Transform e clicar em Relational Model. Para
UNIDADE 2. ARQUITETURA DE DADOS 16
construção do modelo físico, clique novamente em Transform e, em seguida, Quick
SQL. Dessa forma, o modelo será gerado, assim como o arquivo com o script SQL para
execução no banco de dados.
2.2 Linguagem SQL
Para o banco de dados relacional, a SQL (linguagem de consulta estruturada) deve ser
utilizado para criação das tabelas, atributos, chaves primárias, estrangeiras e outras
restrições no SGBD.
A linguagem SQL (Structured Query Language), linguagem de consulta estruturada, fez
parte da definição do modelo relacional lançado pelo pesquisador da IBM, Edgar F. Codd,
em 1970. É a linguagem mais utilizada no mercado para consultas a banco de dados
relacionais. Em 1986, a SQL foi padronizada pela ANSI (American National Standards
Institute). Os grandes SGBDs do mercado, dentre eles Oracle Database, Microsoft SQL
Server, PostgreSQL e MySQL, adotam a linguagem SQL padrão ANSI para consultas e
manipulação dos dados e estruturas.
A linguagem SQLse divide em dois grupos: linguagem de manipulação de dados ou
DML (Data Manipulation Language) e linguagem de definição de dados ou DDL
(Data Definition Language).
O conjunto de instruções DML possibilita a consulta, inserção, alteração e exclusão dos
dados. Já no DDL, representam as instruções para definição das estruturas, tabelas e
atributos. Também é possível criar ou excluir esses objetos. O SQL extraído da
ferramenta CASE é formado por instruções SQL da categoria DDL. Já os dados são
inseridos nesses objetos por instruções DML.
Dentre as instruções DML, temos:
SELECT para realizar a seleção de um conjunto de dados nas tabelas do SGBD;
INSERT para realizar a inserção de dados nas tabelas do SGBD;
UPDATE para realizar a atualização de dados nas tabelas do SGBD;
DELETE para realizar a exclusão de dados nas tabelas do SGBD.
UNIDADE 2. ARQUITETURA DE DADOS 17
MEDEIROS (2007) explica que a sintaxe geral possui as palavras-chave, que são:
SELECT para selecionar os campos; FROM, que se refere às tabelas envolvidas na
consulta; e WHERE, que encerra a condição da consulta. A seguir, veja um exemplo de
consulta para selecionar o nome do aluno e sua idade: SELECT nom_aluno, idade
FROM ALUNO. Outro exemplo para selecionar funcionários que trabalham no
departamento 10: SELECT nom_func, data_admissao FROM FUNCIONÁRIO WHERE
cod_departamento=10.
Na categoria DDL, temos as instruções SQL:
CREATE para a criação de uma tabela, visão ou outros objetos no SGBD, incluindo
os atributos chaves;
ALTER para alterar uma tabela, visão ou modificar atributos;
DROP para apagar um objeto no SGBD.
A seguir, veja exemplos de instrução DDL para criação da tabela AUTHOR e WRITTEN,
bem como seus atributos com a SQL gerada pela ferramenta DB-Main:
create table AUTHOR
ID_AUT -- Sequence attribute not implemented -- not null,
Name char(30) not null,     
First_Name char(30),     
Origin char(30),     
constraint ID_ID primary key (ID_AUT));
create table written (
ID_AUT numeric(10) not null,
Book_id numeric(6) not null,
constraint ID_written_ID primary key (ID_AUT, Book_id));
VOCÊ QUER LER?
UNIDADE 2. ARQUITETURA DE DADOS 18
Para maiores detalhes dos principais recursos da linguagem SQL, faça a leitura
do livro que trata do assunto de maneira prática, Introdução à linguagem SQL:
abordagem prática para iniciantes, do autor Thomas Nield.
2.3 Implementação do modelo de entidades e
relacionamentos em um banco de dados NoSQL
Para demandas que envolvam dados estruturados, os bancos de dados relacionais ditos
tradicionais atendem sem a necessidade de adaptações e maiores esforços pelas
equipes de desenvolvimento. Entretanto, quando a questão demanda grandes volumes
de dados, processamento distribuído para melhor desempenho e o armazenamento e
manipulação de dados sem estrutura definida ou semiestruturados, o trabalho exige um
conceito de banco de dados mais flexível quanto sua organização e propriedades. Esse
banco é conhecido como NoSQL.
NoSQL significa not only SQL (não apenas SQL) e o seu objetivo é entregar soluções de
banco que tenham a capacidade de processar e manipular grandes volumes de dados,
com alto desempenho e preparados para recepcionar diferentes estruturas, não se
prendendo a um layout fixo de linha e coluna.
Elmasri e Navathe colocam que o NoSQL “tem por finalidade transmitir a ideia de que
muitas aplicações precisam de sistemas diferentes dos sistemas SQL relacionais
tradicionais para ampliar suas necessidades de gerenciamento de dados” (ELMASRI;
NAVATHE, 2016, p. 795). Ainda no mesmo texto, os autores complementam que:
A maioria dos sistemas NoSQL são bancos de dados distribuídos
ou sistemas de armazenamento distribuído, com foco no
armazenamento de dados semiestruturados, alto desempenho,
disponibilidade, replicação de dados e escalabilidade, ao contrário
da ênfase em consistência imediata de dados, linguagens de
MEDEIROS (2007) explica que a sintaxe geral possui as palavras-chave, que são:
SELECT para selecionar os campos; FROM, que se refere às tabelas envolvidas na
consulta; e WHERE, que encerra a condição da consulta. A seguir, veja um exemplo de
consulta para selecionar o nome do aluno e sua idade: SELECT nom_aluno, idade
FROM ALUNO. Outro exemplo para selecionar funcionários que trabalham no
departamento 10: SELECT nom_func, data_admissao FROM FUNCIONÁRIO WHERE
cod_departamento=10.
Na categoria DDL, temos as instruções SQL:
CREATE para a criação de uma tabela, visão ou outros objetos no SGBD, incluindo
os atributos chaves;
ALTER para alterar uma tabela, visão ou modificar atributos;
DROP para apagar um objeto no SGBD.
A seguir, veja exemplos de instrução DDL para criação da tabela AUTHOR e WRITTEN,
bem como seus atributos com a SQL gerada pela ferramenta DB-Main:
create table AUTHOR
ID_AUT -- Sequence attribute not implemented -- not null,
Name char(30) not null,     
First_Name char(30),     
Origin char(30),     
constraint ID_ID primary key (ID_AUT));
create table written (
ID_AUT numeric(10) not null,
Book_id numeric(6) not null,
constraint ID_written_ID primary key (ID_AUT, Book_id));
VOCÊ QUER LER?
Para maiores detalhes dos principais recursos da linguagem SQL, faça a leitura
do livro que trata do assunto de maneira prática, Introdução à linguagem SQL:
abordagem prática para iniciantes, do autor Thomas Nield.
2.3 Implementação do modelo de entidades e
relacionamentos em um banco de dados NoSQL
Para demandas que envolvam dados estruturados, os bancos de dados relacionais ditos
tradicionais atendem sem a necessidade de adaptações e maiores esforços pelas
equipes de desenvolvimento. Entretanto, quando a questão demanda grandes volumes
de dados, processamento distribuído para melhor desempenho e o armazenamento e
manipulação de dados sem estrutura definida ou semiestruturados, o trabalho exige um
conceito de banco de dados mais flexível quanto sua organização e propriedades. Esse
banco é conhecido como NoSQL.
NoSQL significa not only SQL (não apenas SQL) e o seu objetivo é entregar soluções de
banco que tenham a capacidade de processar e manipular grandes volumes de dados,
com alto desempenho e preparados para recepcionar diferentes estruturas, não se
prendendo a um layout fixo de linha e coluna.
Elmasri e Navathe colocam que o NoSQL “tem por finalidade transmitir a ideia de que
muitas aplicações precisam de sistemas diferentes dos sistemas SQL relacionais
tradicionais para ampliar suas necessidades de gerenciamento de dados” (ELMASRI;
NAVATHE, 2016, p. 795). Ainda no mesmo texto, os autores complementam que:
A maioria dos sistemas NoSQL são bancos de dados distribuídos
ou sistemas de armazenamento distribuído, com foco no
armazenamento de dados semiestruturados, alto desempenho,
disponibilidade, replicação de dados e escalabilidade, ao contrário
da ênfase em consistência imediata de dados, linguagens deUNIDADE 2. ARQUITETURA DE DADOS 19
Dentre as características dos sistemas NoSQL, podemos destacar:
Escalabilidade: normalmente, em sistemas NoSQL, a capacidade de incremento de
equipamentos ou recursos é horizontal, considerando a inserção de mais nós para
aumento do processamento e armazenamento distribuído.
Disponibilidade: nos bancos de dados NoSQL, são encontrados sistemas de
replicação para manter os dados disponíveis no caso de falha de um nó.
Modelos de replicação: oferta nos bancos de dados NoSQL de modelo de
replicação mestre-escravo, em que a cópia dos dados, gravada no principal, é
replicada para nós escravos. Além deste, há também o modelo mestre-mestre, no
qual leitura e escrita são realizadas em qualquer uma das cópias, podendo haver
diferenças entre elas.
Sharding de arquivos: particionamento horizontal para que os dados sejam
fragmentados e acessados de forma simultânea em vários nós, distribuindo a carga
do acesso.
Acesso a dados de alto desempenho: utilização de técnicas de hashing ou
particionamento por intervalo para possibilitar a eficiente busca aos milhões de
registros.
No banco de dados NoSQL, para o trabalho eficientecom grandes volumes de dados e
desempenho, a garantia de consistência, disponibilidade e tolerância à partição são
balanceadas e, com isso, em alguns momentos, são até abdicadas em prol do
processamento.
A respeito do modelo de dados, podemos citar a não exigência de um esquema. No
modelo relacional, existe a necessidade de um esquema para que as estruturas e
restrições dos dados sejam construídas. No NoSQL, devido à flexibilidade das estruturas,
esquemas ainda que parciais podem existir ou não. Isso porque as restrições não serão
especificadas no banco, e sim via aplicações que acessarão os dados.
consulta poderosas e armazenamento de dados estruturados
(ELMASRI; NAVATHE, 2016, p. 795).
UNIDADE 2. ARQUITETURA DE DADOS 20
Os sistemas NoSQL podem ter o armazenamento dos dados orientados como baseados
em documentos, armazenamento chave-valor, baseado em colunas e baseado em
grafos.
Os baseados em documentos se caracterizam primariamente por armazenar dados na
forma de documentos JSON (Javascript Object Notation) acessíveis por um _id. A Figura
10 representa um exemplo de documento JSON. Neste banco, teremos coleções no
lugar de tabelas e documentos no lugar de tuplas. Nas tuplas, os dados estão em
diversas estruturas.
Figura 10 – Captura de tela com exemplo de documento JSON.
Uma das soluções NoSQL orientadas a documentos existentes é o banco de dados
MongoDB. Por trabalhar com documentos JSON, precisamos criar, no MongoDB, uma
Os sistemas NoSQL podem ter o armazenamento dos dados orientados como baseados
em documentos, armazenamento chave-valor, baseado em colunas e baseado em
grafos.
Os baseados em documentos se caracterizam primariamente por armazenar dados na
forma de documentos JSON (Javascript Object Notation) acessíveis por um _id. A Figura
10 representa um exemplo de documento JSON. Neste banco, teremos coleções no
lugar de tabelas e documentos no lugar de tuplas. Nas tuplas, os dados estão em
diversas estruturas.
Figura 10 – Captura de tela com exemplo de documento JSON.
Uma das soluções NoSQL orientadas a documentos existentes é o banco de dados
MongoDB. Por trabalhar com documentos JSON, precisamos criar, no MongoDB, uma
coleção contendo os documentos, que serão identificados unicamente por meio de um
_id.
VOCÊ SABIA?
O JSON é uma notação de objetos bem simples e leve muito utilizada para troca
de dados. Dessa forma, diversos sites e organizações disponibilizam seus dados
para análises no formato JSON justamente pela facilidade com a qual diversas
aplicações realizam a leitura desse formato.
Para perceber como é simples o trabalho com documentos, no código-fonte a seguir, é
possível visualizar a criação da coleção ALUNO, a inserção de dois documentos com
estruturas diferentes e, por fim, uma consulta ao documento pelo campo “telefone”:
//CRIANDO COLEÇÃO
use local
db.createCollection("ALUNO")
//INSERINDO DOCUMENTO ALUNO_ID 1 e 2
db.ALUNO.insert{_id:"1", nome_aluno: "João Apolinário", idade:
"12"})
db.ALUNO.insert{_id:"2", nome_aluno: "João Apolinário2", idade:
"13",
endereco: [{rua: 'Paulo IV',bairro:'Pituba'}],
telefone:['71-8373-833','74-7770-8778']})
//PESQUISANDO DOCUMENTOS NA COLECAO
db.ALUNO.find()
_id:"1", nome_aluno: "João Apolinário", idade: "12"}
_id:"2", nome_aluno: "João Apolinário2", idade: "13", endereco:
[{rua: 'Paulo IV',bairro:'Pituba'}], telefone:['71-8373-833','74-
7770-8778']}
UNIDADE 2. ARQUITETURA DE DADOS 21
coleção contendo os documentos, que serão identificados unicamente por meio de um
_id.
VOCÊ SABIA?
O JSON é uma notação de objetos bem simples e leve muito utilizada para troca
de dados. Dessa forma, diversos sites e organizações disponibilizam seus dados
para análises no formato JSON justamente pela facilidade com a qual diversas
aplicações realizam a leitura desse formato.
Para perceber como é simples o trabalho com documentos, no código-fonte a seguir, é
possível visualizar a criação da coleção ALUNO, a inserção de dois documentos com
estruturas diferentes e, por fim, uma consulta ao documento pelo campo “telefone”:
//CRIANDO COLEÇÃO
use local
db.createCollection("ALUNO")
//INSERINDO DOCUMENTO ALUNO_ID 1 e 2
db.ALUNO.insert{_id:"1", nome_aluno: "João Apolinário", idade:
"12"})
db.ALUNO.insert{_id:"2", nome_aluno: "João Apolinário2", idade:
"13",
endereco: [{rua: 'Paulo IV',bairro:'Pituba'}],
telefone:['71-8373-833','74-7770-8778']})
//PESQUISANDO DOCUMENTOS NA COLECAO
db.ALUNO.find()
_id:"1", nome_aluno: "João Apolinário", idade: "12"}
_id:"2", nome_aluno: "João Apolinário2", idade: "13", endereco:
[{rua: 'Paulo IV',bairro:'Pituba'}], telefone:['71-8373-833','74-
7770-8778']}
coleção contendo os documentos, que serão identificados unicamente por meio de um
_id.
VOCÊ SABIA?
O JSON é uma notação de objetos bem simples e leve muito utilizada para troca
de dados. Dessa forma, diversos sites e organizações disponibilizam seus dados
para análises no formato JSON justamente pela facilidade com a qual diversas
aplicações realizam a leitura desse formato.
Para perceber como é simples o trabalho com documentos, no código-fonte a seguir, é
possível visualizar a criação da coleção ALUNO, a inserção de dois documentos com
estruturas diferentes e, por fim, uma consulta ao documento pelo campo “telefone”:
//CRIANDO COLEÇÃO
use local
db.createCollection("ALUNO")
//INSERINDO DOCUMENTO ALUNO_ID 1 e 2
db.ALUNO.insert{_id:"1", nome_aluno: "João Apolinário", idade:
"12"})
db.ALUNO.insert{_id:"2", nome_aluno: "João Apolinário2", idade:
"13",
endereco: [{rua: 'Paulo IV',bairro:'Pituba'}],
telefone:['71-8373-833','74-7770-8778']})
//PESQUISANDO DOCUMENTOS NA COLECAO
db.ALUNO.find()
_id:"1", nome_aluno: "João Apolinário", idade: "12"}
_id:"2", nome_aluno: "João Apolinário2", idade: "13", endereco:
[{rua: 'Paulo IV',bairro:'Pituba'}], telefone:['71-8373-833','74-
7770-8778']}
//FILTRANDO PELO CAMPO TELEFONE
db.ALUNO.find({"telefone":"71-8373-833"})
_id:"2", nome_aluno: "João Apolinário2", idade: "13", endereco:
[{rua: 'Paulo IV',bairro:'Pituba'}], telefone:['71-8373-833','74-
7770-8778']}
A categoria NoSQL de armazenamento chave-valor armazena os dados constituídos
por uma chave associada a um valor, podendo ser qualquer estrutura de dado, lista,
documento, objeto etc. Um exemplo de solução de mercado dessa categoria é o
Amazon DynamoDB.
O armazenamento baseado em colunas se caracteriza por retorno rápido das colunas
por meio do particionamento das tabelas e as chaves que apontam para colunas,
montando, assim, as linhas. O Cassandra é um exemplo de banco NoSQL orientado a
colunas.
Por fim, o armazenamento baseado em grafos representa os dados em nós e grafos
relacionados. Trata-se de uma base formada por grafo de informações e
relacionamentos. Neste, temos o banco de dados Neo4j.
Pelo que foi visto sobre NoSQL, suas características e categorias de banco de dados,
deduzimos que a implementação do modelo nessa solução não segue as mesmas
diretrizes já vistas no modelo relacional.
O modelo de dados para o NoSQL apresenta novos desafios. Sendo assim, temos que
levar em conta a diversidade de soluções NoSQL, avaliar que os dados manipulados
muitas vezes são semiestruturados e que os bancos NoSQL não defendem a
normalização dos dados, pois a preocupação é armazenar sem um desenho tão rígido
dos objetos.
VOCÊ SABIA?
UNIDADE 2. ARQUITETURA DE DADOS 22
//FILTRANDO PELO CAMPO TELEFONE
db.ALUNO.find({"telefone":"71-8373-833"})
_id:"2", nome_aluno: "João Apolinário2", idade: "13", endereco:
[{rua: 'Paulo IV',bairro:'Pituba'}], telefone:['71-8373-833','74-
7770-8778']}
A categoria NoSQL de armazenamento chave-valor armazena os dados constituídos
por uma chave associada a um valor, podendo ser qualquer estrutura de dado, lista,
documento, objeto etc. Um exemplo de solução de mercado dessa categoria é o
Amazon DynamoDB.
O armazenamento baseado em colunas se caracteriza por retorno rápido das colunas
por meio do particionamento das tabelas e as chaves que apontam para colunas,
montando, assim, as linhas. OCassandra é um exemplo de banco NoSQL orientado a
colunas.
Por fim, o armazenamento baseado em grafos representa os dados em nós e grafos
relacionados. Trata-se de uma base formada por grafo de informações e
relacionamentos. Neste, temos o banco de dados Neo4j.
Pelo que foi visto sobre NoSQL, suas características e categorias de banco de dados,
deduzimos que a implementação do modelo nessa solução não segue as mesmas
diretrizes já vistas no modelo relacional.
O modelo de dados para o NoSQL apresenta novos desafios. Sendo assim, temos que
levar em conta a diversidade de soluções NoSQL, avaliar que os dados manipulados
muitas vezes são semiestruturados e que os bancos NoSQL não defendem a
normalização dos dados, pois a preocupação é armazenar sem um desenho tão rígido
dos objetos.
VOCÊ SABIA?
A normalização de um banco de dados possibilita a definição de um conjunto de
regras que, quando aplicados as tabelas e atributos, tem o propósito de evitar a
redundância dos dados, garantindo sua integridade. Normalmente, no projeto de
banco de dados relacional, a normalização é um item que deve ser definido para
garantir essas propriedades.
A variedade de dados exige flexibilidade nas soluções de banco de dados NoSQL desde
sua modelagem. Bugiotti et al, em tradução livre, cita que a “heterogeneidade é
altamente problemática para os desenvolvedores de aplicativos, mesmo dentro de cada
categoria” (BUGIOTTI et al, 2014, p. 1, traduzido pelo autor). Em outras palavras, a
organização dos dados fica a cargo da aplicação e, assim, a percepção de necessidade
da definição e existência de um esquema com objetos pouco mutáveis, muito presente
no modelo de dados, se perde.
Em consideração a esses fatos, para nosso estudo de implementação do modelo,
estudaremos um modelo de alto nível, denominado NoAM (No SQL Abstract Model),
apresentado no artigo de Bugiotti et al (2014). Essa proposta continua contando com as
primeiras etapas do projeto de banco de dados. Entretanto, a implementação para o
NoSQL segue com algumas características específicas para sistemas baseado em
documentos, armazenamento chave-valor, baseado em colunas e baseado em grafos.
A proposta do NoAM é aproveitar as semelhanças entre as categorias NoSQL e
introduzir elementos que permitam a generalização entre as categorias. Para esse
estudo, vamos considerar a Diagrama 3, que representa o diagrama de objetos de um
aplicativo de jogos on-line, no qual temos os jogadores (players), jogos (games) e
rodadas (rounds). O diagrama de objetos representa os objetos que instanciaram ou
estão “consumindo” as classes.
Na primeira etapa do NoAM, temos a modelagem conceitual dos dados e a identificação
de agregados. A modelagem conceitual visa encontrar as entidades, relacionamentos e
atributos. Já a fase dos agregados objetiva representar agrupamento de dados com
alguma relação. As entidades encontradas e os seus dados serão identificados como
coleção contendo os documentos, que serão identificados unicamente por meio de um
_id.
VOCÊ SABIA?
O JSON é uma notação de objetos bem simples e leve muito utilizada para troca
de dados. Dessa forma, diversos sites e organizações disponibilizam seus dados
para análises no formato JSON justamente pela facilidade com a qual diversas
aplicações realizam a leitura desse formato.
Para perceber como é simples o trabalho com documentos, no código-fonte a seguir, é
possível visualizar a criação da coleção ALUNO, a inserção de dois documentos com
estruturas diferentes e, por fim, uma consulta ao documento pelo campo “telefone”:
//CRIANDO COLEÇÃO
use local
db.createCollection("ALUNO")
//INSERINDO DOCUMENTO ALUNO_ID 1 e 2
db.ALUNO.insert{_id:"1", nome_aluno: "João Apolinário", idade:
"12"})
db.ALUNO.insert{_id:"2", nome_aluno: "João Apolinário2", idade:
"13",
endereco: [{rua: 'Paulo IV',bairro:'Pituba'}],
telefone:['71-8373-833','74-7770-8778']})
//PESQUISANDO DOCUMENTOS NA COLECAO
db.ALUNO.find()
_id:"1", nome_aluno: "João Apolinário", idade: "12"}
_id:"2", nome_aluno: "João Apolinário2", idade: "13", endereco:
[{rua: 'Paulo IV',bairro:'Pituba'}], telefone:['71-8373-833','74-
7770-8778']}
UNIDADE 2. ARQUITETURA DE DADOS 23
A normalização de um banco de dados possibilita a definição de um conjunto de
regras que, quando aplicados as tabelas e atributos, tem o propósito de evitar a
redundância dos dados, garantindo sua integridade. Normalmente, no projeto de
banco de dados relacional, a normalização é um item que deve ser definido para
garantir essas propriedades.
A variedade de dados exige flexibilidade nas soluções de banco de dados NoSQL desde
sua modelagem. Bugiotti et al, em tradução livre, cita que a “heterogeneidade é
altamente problemática para os desenvolvedores de aplicativos, mesmo dentro de cada
categoria” (BUGIOTTI et al, 2014, p. 1, traduzido pelo autor). Em outras palavras, a
organização dos dados fica a cargo da aplicação e, assim, a percepção de necessidade
da definição e existência de um esquema com objetos pouco mutáveis, muito presente
no modelo de dados, se perde.
Em consideração a esses fatos, para nosso estudo de implementação do modelo,
estudaremos um modelo de alto nível, denominado NoAM (No SQL Abstract Model),
apresentado no artigo de Bugiotti et al (2014). Essa proposta continua contando com as
primeiras etapas do projeto de banco de dados. Entretanto, a implementação para o
NoSQL segue com algumas características específicas para sistemas baseado em
documentos, armazenamento chave-valor, baseado em colunas e baseado em grafos.
A proposta do NoAM é aproveitar as semelhanças entre as categorias NoSQL e
introduzir elementos que permitam a generalização entre as categorias. Para esse
estudo, vamos considerar a Diagrama 3, que representa o diagrama de objetos de um
aplicativo de jogos on-line, no qual temos os jogadores (players), jogos (games) e
rodadas (rounds). O diagrama de objetos representa os objetos que instanciaram ou
estão “consumindo” as classes.
Na primeira etapa do NoAM, temos a modelagem conceitual dos dados e a identificação
de agregados. A modelagem conceitual visa encontrar as entidades, relacionamentos e
atributos. Já a fase dos agregados objetiva representar agrupamento de dados com
alguma relação. As entidades encontradas e os seus dados serão identificados como
agregados. No Diagrama 3, os agregados estão em destaque por meio das linhas
pontilhadas.
Diagrama 3 – Objetos de um aplicativo de jogo on-line
Fonte: BUGIOTTI et al, 2014, p. 5.
No modelo de dados NoAM, temos um banco de dados formado por um conjunto de
coleções (mesmo sentido do MongoDB) e constituído por um conjunto de blocos, que
por sua vez possuem entradas.
O bloco é formado pelo conceito de unidade de acesso a dados, significando que
existem operações que acessam e manipulam uma unidade individual por vez. Ainda no
conceito de bloco, por unidade de distribuição entende-se que as unidades são
armazenadas completas em um cluster e diferentes unidades distribuídas estão em
vários servidores. Além disso, um bloco é formado por um conjunto de entradas, ou
seja, um componente da unidade de acesso.
A segunda fase do NoAM é construída pela representação dos dados, em que cada
agregado será uma coleção distinta e cada unidade será um bloco. O nome da classe
é utilizado para nomear a coleção e o identificador do agregado para chave do bloco. O
valor de cada agregado será o conjunto de entradas. Essa representação dos dados
pode ser visualizada na Figura 11, juntamente com a coleção Player, o bloco mary e rick
e as suas entradas.
UNIDADE 2. ARQUITETURA DE DADOS 24
agregados. No Diagrama 3, os agregados estão em destaque por meio das linhas
pontilhadas.
Diagrama 3 – Objetos de um aplicativo de jogo on-line
Fonte: BUGIOTTI et al, 2014, p. 5.
No modelo de dados NoAM, temos um banco de dados formado por um conjunto de
coleções (mesmo sentido do MongoDB) e constituído por um conjunto de blocos, que
por sua vez possuem entradas.
O bloco é formado pelo conceito de unidade de acesso a dados, significandoque
existem operações que acessam e manipulam uma unidade individual por vez. Ainda no
conceito de bloco, por unidade de distribuição entende-se que as unidades são
armazenadas completas em um cluster e diferentes unidades distribuídas estão em
vários servidores. Além disso, um bloco é formado por um conjunto de entradas, ou
seja, um componente da unidade de acesso.
A segunda fase do NoAM é construída pela representação dos dados, em que cada
agregado será uma coleção distinta e cada unidade será um bloco. O nome da classe
é utilizado para nomear a coleção e o identificador do agregado para chave do bloco. O
valor de cada agregado será o conjunto de entradas. Essa representação dos dados
pode ser visualizada na Figura 11, juntamente com a coleção Player, o bloco mary e rick
e as suas entradas.
UNIDADE 2. ARQUITETURA DE DADOS 25
Figura 11 – Representação dos dados no NoAM. 
Fonte: BUGIOTTI et al, 2014, p. 7. (Adaptado).
Como última fase, após construída a representação dos dados, pode-se converter para a
categoria NoSQL que se deseja implementar o modelo. Como exemplo, vamos ver o
resultado da implementação no banco orientado a documento, MongoDB, e no chave-
valor, Oracle NoSQL.
Devido ao MongoDB ser orientado a documento e já ter o conceito natural de coleções,
fica mais simples representar a implementação. Basicamente, cada bloco representa um
documento, e as entradas podem ser mapeadas como campos. O Quadro 1
representa o resultado da implementação no MongoDB. Veja que o bloco mary se
transformou no _id e no documento, suas entradas se transformaram nos campos e
valores e a coleção Player foi implementada.
Quadro 1 – Implementação no MONGODB
collection Player
UNIDADE 2. ARQUITETURA DE DADOS 26
id
mary
document
{ 
_id:”mary”, 
username:”mary”, 
firstName:”Mary”, 
lastName:”Wilson”, 
games:
[{ game:”Game:2345”, opponent:”Player:rick”}, 
{ game:”Game:2611”, opponent:”Player:ann”}
}
Fonte: BUGIOTTI et al, 2014, p. 5. (Adaptado).
No Oracle NoSQL, banco NoSQL baseado em chave-valor, a chave será o nome da
coleção com o id da chave do bloco e o valor será representado pela entrada. A Tabela 2
representa essa implementação.
Tabela 3 – Implementação no Oracle NoSQL
key (/major/key/-) value
/Player/mary/-
/Player/rick/-
/Game/2345/-
{username: “mary”, firstName: “Mary”, … }
{username: “rick”, firstName: “Rick”, …}
{id: “2345”, firstPlayer: “Player:mary”, …}
Fonte: BUGIOTTI et al, 2014, p. 4. (Adaptado).
id
mary
document
{ 
_id:”mary”, 
username:”mary”, 
firstName:”Mary”, 
lastName:”Wilson”, 
games:
[{ game:”Game:2345”, opponent:”Player:rick”}, 
{ game:”Game:2611”, opponent:”Player:ann”}
}
Fonte: BUGIOTTI et al, 2014, p. 5. (Adaptado).
No Oracle NoSQL, banco NoSQL baseado em chave-valor, a chave será o nome da
coleção com o id da chave do bloco e o valor será representado pela entrada. A Tabela 2
representa essa implementação.
Tabela 3 – Implementação no Oracle NoSQL
key (/major/key/-) value
/Player/mary/-
/Player/rick/-
/Game/2345/-
{username: “mary”, firstName: “Mary”, … }
{username: “rick”, firstName: “Rick”, …}
{id: “2345”, firstPlayer: “Player:mary”, …}
Fonte: BUGIOTTI et al, 2014, p. 4. (Adaptado).
Figura 11 – Representação dos dados no NoAM. 
Fonte: BUGIOTTI et al, 2014, p. 7. (Adaptado).
Como última fase, após construída a representação dos dados, pode-se converter para a
categoria NoSQL que se deseja implementar o modelo. Como exemplo, vamos ver o
resultado da implementação no banco orientado a documento, MongoDB, e no chave-
valor, Oracle NoSQL.
Devido ao MongoDB ser orientado a documento e já ter o conceito natural de coleções,
fica mais simples representar a implementação. Basicamente, cada bloco representa um
documento, e as entradas podem ser mapeadas como campos. O Quadro 1
representa o resultado da implementação no MongoDB. Veja que o bloco mary se
transformou no _id e no documento, suas entradas se transformaram nos campos e
valores e a coleção Player foi implementada.
Quadro 1 – Implementação no MONGODB
collection Player
UNIDADE 2. ARQUITETURA DE DADOS 27
id
mary
document
{ 
_id:”mary”, 
username:”mary”, 
firstName:”Mary”, 
lastName:”Wilson”, 
games:
[{ game:”Game:2345”, opponent:”Player:rick”}, 
{ game:”Game:2611”, opponent:”Player:ann”}
}
Fonte: BUGIOTTI et al, 2014, p. 5. (Adaptado).
No Oracle NoSQL, banco NoSQL baseado em chave-valor, a chave será o nome da
coleção com o id da chave do bloco e o valor será representado pela entrada. A Tabela 2
representa essa implementação.
Tabela 3 – Implementação no Oracle NoSQL
key (/major/key/-) value
/Player/mary/-
/Player/rick/-
/Game/2345/-
{username: “mary”, firstName: “Mary”, … }
{username: “rick”, firstName: “Rick”, …}
{id: “2345”, firstPlayer: “Player:mary”, …}
Fonte: BUGIOTTI et al, 2014, p. 4. (Adaptado).
id
mary
document
{ 
_id:”mary”, 
username:”mary”, 
firstName:”Mary”, 
lastName:”Wilson”, 
games:
[{ game:”Game:2345”, opponent:”Player:rick”}, 
{ game:”Game:2611”, opponent:”Player:ann”}
}
Fonte: BUGIOTTI et al, 2014, p. 5. (Adaptado).
No Oracle NoSQL, banco NoSQL baseado em chave-valor, a chave será o nome da
coleção com o id da chave do bloco e o valor será representado pela entrada. A Tabela 2
representa essa implementação.
Tabela 3 – Implementação no Oracle NoSQL
key (/major/key/-) value
/Player/mary/-
/Player/rick/-
/Game/2345/-
{username: “mary”, firstName: “Mary”, … }
{username: “rick”, firstName: “Rick”, …}
{id: “2345”, firstPlayer: “Player:mary”, …}
Fonte: BUGIOTTI et al, 2014, p. 4. (Adaptado).
Figura 11 – Representação dos dados no NoAM. 
Fonte: BUGIOTTI et al, 2014, p. 7. (Adaptado).
Como última fase, após construída a representação dos dados, pode-se converter para a
categoria NoSQL que se deseja implementar o modelo. Como exemplo, vamos ver o
resultado da implementação no banco orientado a documento, MongoDB, e no chave-
valor, Oracle NoSQL.
Devido ao MongoDB ser orientado a documento e já ter o conceito natural de coleções,
fica mais simples representar a implementação. Basicamente, cada bloco representa um
documento, e as entradas podem ser mapeadas como campos. O Quadro 1
representa o resultado da implementação no MongoDB. Veja que o bloco mary se
transformou no _id e no documento, suas entradas se transformaram nos campos e
valores e a coleção Player foi implementada.
Quadro 1 – Implementação no MONGODB
collection Player
id
mary
document
{ 
_id:”mary”, 
username:”mary”, 
firstName:”Mary”, 
lastName:”Wilson”, 
games:
[{ game:”Game:2345”, opponent:”Player:rick”}, 
{ game:”Game:2611”, opponent:”Player:ann”}
}
Fonte: BUGIOTTI et al, 2014, p. 5. (Adaptado).
No Oracle NoSQL, banco NoSQL baseado em chave-valor, a chave será o nome da
coleção com o id da chave do bloco e o valor será representado pela entrada. A Tabela 2
representa essa implementação.
Tabela 3 – Implementação no Oracle NoSQL
key (/major/key/-) value
/Player/mary/-
/Player/rick/-
/Game/2345/-
{username: “mary”, firstName: “Mary”, … }
{username: “rick”, firstName: “Rick”, …}
{id: “2345”, firstPlayer: “Player:mary”, …}
Fonte: BUGIOTTI et al, 2014, p. 4. (Adaptado).
id
mary
document
{ 
_id:”mary”, 
username:”mary”, 
firstName:”Mary”, 
lastName:”Wilson”, 
games:
[{ game:”Game:2345”, opponent:”Player:rick”}, 
{ game:”Game:2611”, opponent:”Player:ann”}
}
Fonte: BUGIOTTI et al, 2014, p. 5. (Adaptado).
No Oracle NoSQL, banco NoSQL baseado em chave-valor, a chave será o nome da
coleção com o id da chave do bloco e o valor será representado pela entrada. A Tabela 2
representa essa implementação.
Tabela 3 – Implementação no Oracle NoSQL
key (/major/key/-) value
/Player/mary/-
/Player/rick/-
/Game/2345/-
{username: “mary”, firstName: “Mary”, … }
{username: “rick”, firstName: “Rick”, …}
{id: “2345”, firstPlayer: “Player:mary”, …}
Fonte: BUGIOTTI et al, 2014, p. 4. (Adaptado).
id
mary
document
{ 
_id:”mary”, 
username:”mary”, 
firstName:”Mary”, 
lastName:”Wilson”, 
games:
[{ game:”Game:2345”, opponent:”Player:rick”},{ game:”Game:2611”, opponent:”Player:ann”}
}
Fonte: BUGIOTTI et al, 2014, p. 5. (Adaptado).
No Oracle NoSQL, banco NoSQL baseado em chave-valor, a chave será o nome da
coleção com o id da chave do bloco e o valor será representado pela entrada. A Tabela 2
representa essa implementação.
Tabela 3 – Implementação no Oracle NoSQL
key (/major/key/-) value
/Player/mary/-
/Player/rick/-
/Game/2345/-
{username: “mary”, firstName: “Mary”, … }
{username: “rick”, firstName: “Rick”, …}
{id: “2345”, firstPlayer: “Player:mary”, …}
Fonte: BUGIOTTI et al, 2014, p. 4. (Adaptado).
id
mary
document
{ 
_id:”mary”, 
username:”mary”, 
firstName:”Mary”, 
lastName:”Wilson”, 
games:
[{ game:”Game:2345”, opponent:”Player:rick”}, 
{ game:”Game:2611”, opponent:”Player:ann”}
}
Fonte: BUGIOTTI et al, 2014, p. 5. (Adaptado).
No Oracle NoSQL, banco NoSQL baseado em chave-valor, a chave será o nome da
coleção com o id da chave do bloco e o valor será representado pela entrada. A Tabela 2
representa essa implementação.
Tabela 3 – Implementação no Oracle NoSQL
key (/major/key/-) value
/Player/mary/-
/Player/rick/-
/Game/2345/-
{username: “mary”, firstName: “Mary”, … }
{username: “rick”, firstName: “Rick”, …}
{id: “2345”, firstPlayer: “Player:mary”, …}
Fonte: BUGIOTTI et al, 2014, p. 4. (Adaptado).
Síntese
Caro estudante,
Nesta unidade, vimos que um projeto de banco de dados tem diversas etapas compostas
por atividades distintas, mas com um propósito final de representar o modelo de negócios
e as estruturas físicas num banco de dados. Para isso, vimos que precisamos
transformar o modelo entidade-relacionamento em modelo relacional, com destaque
para o papel das entidades participantes, visto que podem ser regulares ou fracas.
Além disso, vimos que é preciso atenção no tipo de relacionamento existente, se de 1:1,
1:N ou N:N, se os atributos são multivalorados e se seguem um protocolo de, no
mínimo, sete etapas para que possam ser implementados corretamente no SGBD.
O modelo relacional pode ser desenhado utilizando algumas ferramentas CASE que dão
suporte, dentre outras ações, a essa etapa do projeto de banco de dados, possibilitando
a transformação em modelo físico.
Os bancos de dados NoSQL se apresentam como alternativa para atender um cenário
mais dinâmico de dados e estruturas. Além disso, implementações de modelo como o
NoAM possibilitam a transformação do modelo lógico-conceitual para o NoSQL.
Referências bibliográficas
UNIDADE 2. ARQUITETURA DE DADOS 28
BUGIOTTI, F. et al. Database Design for NoSQL Systems. In: International Conference
on Conceptual Modeling, 2014, Atlanta, United States. Anais… Atlanta: Springer
International Publishing, 2014, pp. 223-231.
ELMASRI, R.; NAVATHE, S. Sistemas de bancos de dados. 7. ed. São Paulo: Pearson,
2016.
MEDEIROS, L. F. Banco de dados - princípios e prática. 1. ed. Curitiba: IBPEX, 2007.
NIELD, T. Introdução à linguagem SQL: abordagem prática para iniciantes. São Paulo:
Editora Novatec, 2016.
SETZER, V. W.; SILVA, F. S. C. Bancos de dados. São Paulo: Ed. Edgard Blücher, 2005.
VICCI, C. Banco de dados. São Paulo: Editora Pearson, 2015.BUGIOTTI, F. et al.
Database Design for NoSQL Systems. In: International Conference on Conceptual
Modeling, 2014, Atlanta, United States.
Síntese
Caro estudante,
Nesta unidade, vimos que um projeto de banco de dados tem diversas etapas compostas
por atividades distintas, mas com um propósito final de representar o modelo de negócios
e as estruturas físicas num banco de dados. Para isso, vimos que precisamos
transformar o modelo entidade-relacionamento em modelo relacional, com destaque
para o papel das entidades participantes, visto que podem ser regulares ou fracas.
Além disso, vimos que é preciso atenção no tipo de relacionamento existente, se de 1:1,
1:N ou N:N, se os atributos são multivalorados e se seguem um protocolo de, no
mínimo, sete etapas para que possam ser implementados corretamente no SGBD.
O modelo relacional pode ser desenhado utilizando algumas ferramentas CASE que dão
suporte, dentre outras ações, a essa etapa do projeto de banco de dados, possibilitando
a transformação em modelo físico.
Os bancos de dados NoSQL se apresentam como alternativa para atender um cenário
mais dinâmico de dados e estruturas. Além disso, implementações de modelo como o
NoAM possibilitam a transformação do modelo lógico-conceitual para o NoSQL.
Referências bibliográficas
UNIDADE 2. ARQUITETURA DE DADOS 29