unidade1_arquitetura-de-dados

Prévia do material em texto

ARQUITETURA DE DADOSARQUITETURA DE DADOS
UNIDADE 1 - MAPEAMENTO EUNIDADE 1 - MAPEAMENTO E
MODELAGEM DE DADOS ER E UMLMODELAGEM DE DADOS ER E UML
Autor: Juracy Araujo de Almeida JuniorAutor: Juracy Araujo de Almeida Junior
Revisor: Rodrigo Ramos NogueiraRevisor: Rodrigo Ramos Nogueira
INICIAR
Introdução
A partir do momento em que existe a necessidade do armazenamento de dados, motivado pela construção ou
evolução de um sistema, surge, no ciclo do desenvolvimento, o mapeamento e modelagem dos dados. O
mapeamento e a modelagem permitem a adequada construção, esquema e documentação do repositório de
dados em sinergia com as regras que a aplicação exige.
Conhecer os elementos e critérios para o desenho da estrutura que formará o banco de dados é fundamental
para um projeto e manutenção sem surpresas. Afinal, quem já precisou dar suporte a alguma aplicação e não
encontrou modelo ou dicionário de dados sabe o quanto faz a diferença. Essa necessidade também é sentida
na construção do projeto, visto que eventualmente requisitos são revistos, e sem esse mapeamento de dados,
o esforço e custo tendem a ser maiores.
Assim, caro(a) estudante, nesta unidade será apresentado o conteúdo para o entendimento essencial de banco
de dados e modelos de dados relacionais fundamentando aspectos que serão vistos em modelos de entidades
e relacionamentos e a modelagem de dados. Também será apresentada a modelagem de dados a partir do
UML (Linguagem Unificada de Modelagem). Bons estudos!
1.1 Fundamentos de banco de dados e modelos de dados relacional
Autor:
Juracy Araujo de Almeida Junior
Revisor:
Rodrigo Ramos Nogueira
ARQUITETURA DE DADOS
UNIDADE 1. MAPEAMENTO E MODELAGEM DE 
DADOS ER E UML
INTRODUÇÃO 01
1.1 FUNDAMENTOS DE BANCO DE DADOS E MODELOS DE DADOS RELACIONAL 02
1.2 MODELO DE ENTIDADES E RELACIONAMENTOS 13
1.3 MODELAGEM DE DADOS 16
1.4 MODELAGEM DE DADOS COM A UML 23
SÍNTESE 26
REFERÊNCIAS BIBLIOGRÁFICAS 27
UNIDADE 1. ARQUITETURA DE DADOS 1
Para que se possa elaborar um desenho de um Banco de dados, mapeamento e modelagem em conformidade
com os requisitos de negócios para uma aplicação, é necessário ter bem claro o valor que os dados que serão
ali armazenados entregarão, bem como entender das propriedades e recursos de um banco de dados, afinal,
ali serão guardados e mantidos.
Ao longo desta unidade serão apresentadas ideias e conceitos essenciais sobre esses temas, que darão
suporte a mapeamento e modelagem de dados.
1.1.1 Papel dos dados
Até alguns anos atrás, os dados armazenados e gerados pelas entradas nas diversas aplicações existentes em
uma organização tinham, como propósito maior, servir de insumo para impressão de relatórios e listas para
conferências e reuniões.
O foco maior para uma empresa com o advento do sistema era automatizar processos repetitivos ou atividades
que poderiam ser orientadas por aplicações, e, assim, maximizar o uso dos recursos, principalmente humanos,
em tarefas que rendessem maiores resultados.
Isso não quer dizer que os dados não eram valorizados. Eles eram considerados importantes, principalmente
para retratar os parâmetros utilizados na realização dos processos, sejam eles de compras, vendas,
informações de clientes, entre outros.
Com o passar do tempo e o surgimento de novas tecnologias, os dados passaram a ter um grau de importância
mais elevado. Isso foi reforçado principalmente com a ascensão da Internet e a chegada de soluções e
dispositivos “hiperconectados” que, para entregar os resultados, necessitavam tanto da coleta de dados quanto
da análise desses para assim o transformá-lo em um ativo de grande valor.
Essa nova realidade fez com que os dados assumissem um papel fundamental e estratégico em diversos
setores. Na saúde, os dados são fontes para a execução e aprimoramento de aplicações capazes de realizar
diagnósticos e predições de doenças em pacientes. Na área financeira, com cálculos matemáticos, os dados
auxiliam investidores nas melhores opções para inserção de capital. Na política, com a captura dos dados de
comportamento de usuários nas redes sociais, empresas do ramo oferecem pacotes de campanhas
publicitárias direcionadas ao público-alvo com mensagens personalizadas, capazes de influenciar no voto.
Rogers (2017), destaca que “para muitos dos titãs do mundo dos negócios de hoje, parece claro que os dados
que captam referente a seus clientes são um de seus mais valiosos ativos”.
VOCÊ QUER LER?
ARQUITETURA DE DADOSARQUITETURA DE DADOS
UNIDADE 1 - MAPEAMENTO EUNIDADE 1 - MAPEAMENTO E
MODELAGEM DE DADOS ER E UMLMODELAGEM DE DADOS ER E UML
Autor: Juracy Araujo de Almeida JuniorAutor: Juracy Araujo de Almeida Junior
Revisor: Rodrigo Ramos NogueiraRevisor: Rodrigo Ramos Nogueira
INICIAR
Introdução
A partir do momento em que existe a necessidade do armazenamento de dados, motivado pela construção ou
evolução de um sistema, surge, no ciclo do desenvolvimento, o mapeamento e modelagem dos dados. O
mapeamento e a modelagem permitem a adequada construção, esquema e documentação do repositório de
dados em sinergia com as regras que a aplicação exige.
Conhecer os elementos e critérios para o desenho da estrutura que formará o banco de dados é fundamental
para um projeto e manutenção sem surpresas. Afinal, quem já precisou dar suporte a alguma aplicação e não
encontrou modelo ou dicionário de dados sabe o quanto faz a diferença. Essa necessidade também é sentida
na construção do projeto, visto que eventualmente requisitos são revistos, e sem esse mapeamento de dados,
o esforço e custo tendem a ser maiores.
Assim, caro(a) estudante, nesta unidade será apresentado o conteúdo para o entendimento essencial de banco
de dados e modelos de dados relacionais fundamentando aspectos que serão vistos em modelos de entidades
e relacionamentos e a modelagem de dados. Também será apresentada a modelagem de dados a partir do
UML (Linguagem Unificada de Modelagem). Bons estudos!
1.1 Fundamentos de banco de dados e modelos de dados relacional
UNIDADE 1. ARQUITETURA DE DADOS 2
Outros exemplos de uso e aplicação inteligente dos dados podem ser obtidos no livro de Rosângela
Marquesone, Big Data - Técnicas e Tecnologias para Extração de Valor dos Dados, que mostra como
ocorre desde o processo de extração até o consumo e a visualização de dados sob a nova realidade
conhecida como Big Data.
Enfim, a percepção do valor que os dados têm só aumenta com o passar do tempo e, por isso, faz-se
necessário aplicar o conhecimento para melhor explorá-lo, buscando um retorno cada vez mais positivo.
1.1.2 Banco de dados e sistemas de gerenciamento de banco de dados
Segundo Elmasri e Navathe (2016), “banco de dados e sistemas de banco de dados são um componente
essencial na vida da sociedade moderna”. Já Setzer e Silva (2005) dizem que um “banco de dados é um
conjunto de dados integrados que tem por objetivos atender a uma comunidade de usuários”.
Essas afirmações permitem inferir que em diversos momentos do cotidiano os bancos de dados estão
presentes, mesmo que não sejam percebidos. Por exemplo, ao realizar um saque no caixa eletrônico, os dados
que representam o saldo de quanto dinheiro esse cliente tem, e suas movimentações são mantidas em uma
estrutura de banco de dados. Ao contratar um serviço de telefonia ou TV, os dados para emissão de faturas e
consultas pelo cliente também utilizarão um banco de dados.
Elmasri e Navathe (2016), ainda apresentam outra definição adaptada de banco de dados como uma coleção
de dados relacionados que registram fatos conhecidos, que possuem um significado implícito construído com
um objetivo bem definido. Por exemplo, um arquivo físico, um livro, um arquivo de computador, um sistema de
banco de dados, enfim, todos esses guardam fatos primários, os dados, que possuem relação e atendem um
objetivo ou finalidade.
Enquanto a demanda é simplesmente organizar as contas de consumo ou documentos em arquivo físico, ou
catalogar por meio de uma planilha os títulos de DVDs da coleção, a tarefa desses bancos de dados é atender
às necessidadesdo usuário sem maiores preocupações extras. Contudo, quando necessitamos tratar de
grandes volumes de dados e inúmeros assuntos de uma empresa, a tarefa se torna muito mais complexa,
exigindo a atenção em aspectos adicionais como:
Recursos dos bancos de dados
» Clique nas abas para saber mais sobre o assunto
Disponibilidade Desempenho Manipulação dos dados Segurança
O acesso rápido aos dados, mesmo em estruturas com milhares de dados ou acessos
simultâneos de outros usuários.
Para que se possa elaborar um desenho de um Banco de dados, mapeamento e modelagem em conformidade
com os requisitos de negócios para uma aplicação, é necessário ter bem claro o valor que os dados que serão
ali armazenados entregarão, bem como entender das propriedades e recursos de um banco de dados, afinal,
ali serão guardados e mantidos.
Ao longo desta unidade serão apresentadas ideias e conceitos essenciais sobre esses temas, que darão
suporte a mapeamento e modelagem de dados.
1.1.1 Papel dos dados
Até alguns anos atrás, os dados armazenados e gerados pelas entradas nas diversas aplicações existentes em
uma organização tinham, como propósito maior, servir de insumo para impressão de relatórios e listas para
conferências e reuniões.
O foco maior para uma empresa com o advento do sistema era automatizar processos repetitivos ou atividades
que poderiam ser orientadas por aplicações, e, assim, maximizar o uso dos recursos, principalmente humanos,
em tarefas que rendessem maiores resultados.
Isso não quer dizer que os dados não eram valorizados. Eles eram considerados importantes, principalmente
para retratar os parâmetros utilizados na realização dos processos, sejam eles de compras, vendas,
informações de clientes, entre outros.
Com o passar do tempo e o surgimento de novas tecnologias, os dados passaram a ter um grau de importância
mais elevado. Isso foi reforçado principalmente com a ascensão da Internet e a chegada de soluções e
dispositivos “hiperconectados” que, para entregar os resultados, necessitavam tanto da coleta de dados quanto
da análise desses para assim o transformá-lo em um ativo de grande valor.
Essa nova realidade fez com que os dados assumissem um papel fundamental e estratégico em diversos
setores. Na saúde, os dados são fontes para a execução e aprimoramento de aplicações capazes de realizar
diagnósticos e predições de doenças em pacientes. Na área financeira, com cálculos matemáticos, os dados
auxiliam investidores nas melhores opções para inserção de capital. Na política, com a captura dos dados de
comportamento de usuários nas redes sociais, empresas do ramo oferecem pacotes de campanhas
publicitárias direcionadas ao público-alvo com mensagens personalizadas, capazes de influenciar no voto.
Rogers (2017), destaca que “para muitos dos titãs do mundo dos negócios de hoje, parece claro que os dados
que captam referente a seus clientes são um de seus mais valiosos ativos”.
VOCÊ QUER LER?
UNIDADE 1. ARQUITETURA DE DADOS 3
Essas são algumas características que podem ser atendidas com o suporte de um Sistema de Gerenciamento
de Banco de Dados, ou SGBD. Um SGBD, como a própria descrição coloca, é um sistema ou solução que
entrega diversos recursos voltados para o armazenamento e manipulação dos dados ali inseridos.
O SGBD entrega um conjunto de aplicações modularizadas que irá utilizar o banco de dados e realizar as
tarefas de definição, manutenção e consumo dos dados armazenados.
A modularização irá separar o banco de dados, ou seja, estrutura de arquivos onde realmente os dados e
estruturas estão contidos, e outras partes do sistema responsáveis pela realização de consultas, segurança,
desempenho e outros. A Figura 1 representa essa modularização e arquitetura de um SGBD.
Figura 1 – Arquitetura geral de um SGBD. 
Fonte: Elaborado pelo autor.
Conforme apresenta a Figura 1, a arquitetura do SGBD é composta por estruturas de arquivos e áreas de
processos e memória. Os arquivos representam o banco de dados, nos quais os dados e definições destes
estão guardados de forma física no sistema operacional. Na área de processos e memória são executados
softwares que se encarregam de forma ordenada por processar as consultas SQL (Select Query Language, em
português, Linguagem de Consulta Estruturada), gerenciar a performance e consumo de recursos, cuidar para
que os dados sejam persistidos e não perdidos, controlar os acessos e inúmeras outras funções iniciadas por
entradas dos usuários, aplicações ou pelo próprio sistema.
Outras funções operacionais e administrativas podem ser realizadas pelos programas no SGBD, como backup,
Essa modularização de programas tem várias vantagens. A manutenção de programas
torna-se mais simples, pois uma separação clara de funções facilita a compreensão dos
programas. A produtividade dos programadores também aumenta, já que os programas
ficam menores, pois usam funções já construídas. (SETZER; SILVA, 2005, p. 23)
Outros exemplos de uso e aplicação inteligente dos dados podem ser obtidos no livro de Rosângela
Marquesone, Big Data - Técnicas e Tecnologias para Extração de Valor dos Dados, que mostra como
ocorre desde o processo de extração até o consumo e a visualização de dados sob a nova realidade
conhecida como Big Data.
Enfim, a percepção do valor que os dados têm só aumenta com o passar do tempo e, por isso, faz-se
necessário aplicar o conhecimento para melhor explorá-lo, buscando um retorno cada vez mais positivo.
1.1.2 Banco de dados e sistemas de gerenciamento de banco de dados
Segundo Elmasri e Navathe (2016), “banco de dados e sistemas de banco de dados são um componente
essencial na vida da sociedade moderna”. Já Setzer e Silva (2005) dizem que um “banco de dados é um
conjunto de dados integrados que tem por objetivos atender a uma comunidade de usuários”.
Essas afirmações permitem inferir que em diversos momentos do cotidiano os bancos de dados estão
presentes, mesmo que não sejam percebidos. Por exemplo, ao realizar um saque no caixa eletrônico, os dados
que representam o saldo de quanto dinheiro esse cliente tem, e suas movimentações são mantidas em uma
estrutura de banco de dados. Ao contratar um serviço de telefonia ou TV, os dados para emissão de faturas e
consultas pelo cliente também utilizarão um banco de dados.
Elmasri e Navathe (2016), ainda apresentam outra definição adaptada de banco de dados como uma coleção
de dados relacionados que registram fatos conhecidos, que possuem um significado implícito construído com
um objetivo bem definido. Por exemplo, um arquivo físico, um livro, um arquivo de computador, um sistema de
banco de dados, enfim, todos esses guardam fatos primários, os dados, que possuem relação e atendem um
objetivo ou finalidade.
Enquanto a demanda é simplesmente organizar as contas de consumo ou documentos em arquivo físico, ou
catalogar por meio de uma planilha os títulos de DVDs da coleção, a tarefa desses bancos de dados é atender
às necessidades do usuário sem maiores preocupações extras. Contudo, quando necessitamos tratar de
grandes volumes de dados e inúmeros assuntos de uma empresa, a tarefa se torna muito mais complexa,
exigindo a atenção em aspectos adicionais como:
Recursos dos bancos de dados
» Clique nas abas para saber mais sobre o assunto
Disponibilidade Desempenho Manipulação dos dados Segurança
O acesso rápido aos dados, mesmo em estruturas com milhares de dados ou acessos
simultâneos de outros usuários.
UNIDADE 1. ARQUITETURA DE DADOS 4
Disponibilidade
O banco de dados 
deve estar disponível 
e acessível no 
momento em que o 
usuário necessitar 
acessar aos dados.
Desempenho
O acesso rápido 
aos dados, mesmo 
em estruturas com 
milhares de dados ou 
acessos simultâneos 
de outros usuários.
Manipulação 
dos dados
Possibilidade de 
realizar inserção ou 
edição dos dados.
Segurança
Só deverá acessar 
os dados aquele 
que possuir a devida 
permissão, um 
controle de acesso.
atualização das versões, utilitários de sincronização e exportação de dados.
Dentre outras classificações existentespara SGBD, quanto ao modelo podem ser relacional, objeto ou
objeto-relacional.
O modelo classificado como relacional é comercialmente muito utilizada, principalmente pela forte presença no
mercado de inúmeros SGBDR (Sistema de Gerenciamento de Bancos de Dados Relacional). As características
desse modelo estão na simplicidade e facilidade com as quais o banco de dados pode ser implementado e
manipulado, abstraindo a complexidade incorporada em funções pré-existentes, acelerando e aumentando a
produtividade da equipe de desenvolvimento.
VOCÊ SABIA?
Outra razão do modelo relacional se manter ainda mais forte no mercado é sua integração com a
principal linguagem de consulta e manipulação de dados, o SQL (Structured Query Language).
Já o modelo objeto é atendido pelos Sistemas de Gerenciamento de Banco de Dados Orientado a Objetos
(SGBDOO), que trazem características do paradigma Orientado a Objeto (OO) para dentro de soluções de
SGBD. Nesses, os métodos e objetos podem ser invocados conforme o paradigma OO. Limitações
encontradas no modelo relacional são resolvidas a partir de características e extensões que podem ser
incorporadas na aplicação junto com o SGBDOO.
O modelo objeto-relacional entrega SGBDs que buscam o melhor dos dois mundos, como, por exemplo, uso
do SQL para consultas e paradigmas do Orientado a Objeto como reutilização, encapsulamento, interfaces e
outras características.
1.1.3 Modelo de banco de dados
No livro de Setzer e Silva (2005), um modelo de banco de dados é definido como uma descrição dos tipos de
informações que estão armazenadas em um banco de dados. Ou seja, a preocupação no modelo é descrever
os objetivos dos dados e não necessariamente os valores que assumirão.
A construção do modelo de banco de dados compõe uma das etapas do projeto do banco de dados.
Cada modelo será denominado como esquema de banco de dados.
O projeto do banco de dados deve atender aos requisitos levantados considerando os processos e regras que
serão acolhidos no sistema. Por exemplo, em uma aplicação para o varejo, que tem como um dos requisitos
cadastrar produtos de parceiros, as estruturas que comportem os dados dos produtos, dos parceiros, assim
como uma relação entre elas, deverão ser pensadas no projeto do banco de dados.
É uma sequência de atividades que mapeiam e definem as estruturas no banco de dados para garantir um
atualização das versões, utilitários de sincronização e exportação de dados.
Dentre outras classificações existentes para SGBD, quanto ao modelo podem ser relacional, objeto ou
objeto-relacional.
O modelo classificado como relacional é comercialmente muito utilizada, principalmente pela forte presença no
mercado de inúmeros SGBDR (Sistema de Gerenciamento de Bancos de Dados Relacional). As características
desse modelo estão na simplicidade e facilidade com as quais o banco de dados pode ser implementado e
manipulado, abstraindo a complexidade incorporada em funções pré-existentes, acelerando e aumentando a
produtividade da equipe de desenvolvimento.
VOCÊ SABIA?
Outra razão do modelo relacional se manter ainda mais forte no mercado é sua integração com a
principal linguagem de consulta e manipulação de dados, o SQL (Structured Query Language).
Já o modelo objeto é atendido pelos Sistemas de Gerenciamento de Banco de Dados Orientado a Objetos
(SGBDOO), que trazem características do paradigma Orientado a Objeto (OO) para dentro de soluções de
SGBD. Nesses, os métodos e objetos podem ser invocados conforme o paradigma OO. Limitações
encontradas no modelo relacional são resolvidas a partir de características e extensões que podem ser
incorporadas na aplicação junto com o SGBDOO.
O modelo objeto-relacional entrega SGBDs que buscam o melhor dos dois mundos, como, por exemplo, uso
do SQL para consultas e paradigmas do Orientado a Objeto como reutilização, encapsulamento, interfaces e
outras características.
1.1.3 Modelo de banco de dados
No livro de Setzer e Silva (2005), um modelo de banco de dados é definido como uma descrição dos tipos de
informações que estão armazenadas em um banco de dados. Ou seja, a preocupação no modelo é descrever
os objetivos dos dados e não necessariamente os valores que assumirão.
A construção do modelo de banco de dados compõe uma das etapas do projeto do banco de dados.
Cada modelo será denominado como esquema de banco de dados.
O projeto do banco de dados deve atender aos requisitos levantados considerando os processos e regras que
serão acolhidos no sistema. Por exemplo, em uma aplicação para o varejo, que tem como um dos requisitos
cadastrar produtos de parceiros, as estruturas que comportem os dados dos produtos, dos parceiros, assim
como uma relação entre elas, deverão ser pensadas no projeto do banco de dados.
É uma sequência de atividades que mapeiam e definem as estruturas no banco de dados para garantir um
atualização das versões, utilitários de sincronização e exportação de dados.
Dentre outras classificações existentes para SGBD, quanto ao modelo podem ser relacional, objeto ou
objeto-relacional.
O modelo classificado como relacional é comercialmente muito utilizada, principalmente pela forte presença no
mercado de inúmeros SGBDR (Sistema de Gerenciamento de Bancos de Dados Relacional). As características
desse modelo estão na simplicidade e facilidade com as quais o banco de dados pode ser implementado e
manipulado, abstraindo a complexidade incorporada em funções pré-existentes, acelerando e aumentando a
produtividade da equipe de desenvolvimento.
VOCÊ SABIA?
Outra razão do modelo relacional se manter ainda mais forte no mercado é sua integração com a
principal linguagem de consulta e manipulação de dados, o SQL (Structured Query Language).
Já o modelo objeto é atendido pelos Sistemas de Gerenciamento de Banco de Dados Orientado a Objetos
(SGBDOO), que trazem características do paradigma Orientado a Objeto (OO) para dentro de soluções de
SGBD. Nesses, os métodos e objetos podem ser invocados conforme o paradigma OO. Limitações
encontradas no modelo relacional são resolvidas a partir de características e extensões que podem ser
incorporadas na aplicação junto com o SGBDOO.
O modelo objeto-relacional entrega SGBDs que buscam o melhor dos dois mundos, como, por exemplo, uso
do SQL para consultas e paradigmas do Orientado a Objeto como reutilização, encapsulamento, interfaces e
outras características.
1.1.3 Modelo de banco de dados
No livro de Setzer e Silva (2005), um modelo de banco de dados é definido como uma descrição dos tipos de
informações que estão armazenadas em um banco de dados. Ou seja, a preocupação no modelo é descrever
os objetivos dos dados e não necessariamente os valores que assumirão.
A construção do modelo de banco de dados compõe uma das etapas do projeto do banco de dados.
Cada modelo será denominado como esquema de banco de dados.
O projeto do banco de dados deve atender aos requisitos levantados considerando os processos e regras que
serão acolhidos no sistema. Por exemplo, em uma aplicação para o varejo, que tem como um dos requisitos
cadastrar produtos de parceiros, as estruturas que comportem os dados dos produtos, dos parceiros, assim
como uma relação entre elas, deverão ser pensadas no projeto do banco de dados.
É uma sequência de atividades que mapeiam e definem as estruturas no banco de dados para garantir um
Essas são algumas características que podem ser atendidas com o suporte de um Sistema de Gerenciamento
de Banco de Dados, ou SGBD. Um SGBD, como a própria descrição coloca, é um sistema ou solução que
entrega diversos recursos voltados para o armazenamento e manipulação dos dados ali inseridos.
O SGBD entrega um conjunto de aplicações modularizadas que irá utilizar o banco de dados e realizar as
tarefas de definição, manutenção e consumo dos dados armazenados.
A modularização irá separar o banco de dados, ou seja, estrutura de arquivos onde realmente os dados e
estruturas estão contidos, e outras partes do sistema responsáveis pela realização de consultas, segurança,
desempenhoe outros. A Figura 1 representa essa modularização e arquitetura de um SGBD.
Figura 1 – Arquitetura geral de um SGBD. 
Fonte: Elaborado pelo autor.
Conforme apresenta a Figura 1, a arquitetura do SGBD é composta por estruturas de arquivos e áreas de
processos e memória. Os arquivos representam o banco de dados, nos quais os dados e definições destes
estão guardados de forma física no sistema operacional. Na área de processos e memória são executados
softwares que se encarregam de forma ordenada por processar as consultas SQL (Select Query Language, em
português, Linguagem de Consulta Estruturada), gerenciar a performance e consumo de recursos, cuidar para
que os dados sejam persistidos e não perdidos, controlar os acessos e inúmeras outras funções iniciadas por
entradas dos usuários, aplicações ou pelo próprio sistema.
Outras funções operacionais e administrativas podem ser realizadas pelos programas no SGBD, como backup,
Essa modularização de programas tem várias vantagens. A manutenção de programas
torna-se mais simples, pois uma separação clara de funções facilita a compreensão dos
programas. A produtividade dos programadores também aumenta, já que os programas
ficam menores, pois usam funções já construídas. (SETZER; SILVA, 2005, p. 23)
UNIDADE 1. ARQUITETURA DE DADOS 5
repositório compatível com o negócio. Essas atividades são formadas pelo mapeamento e modelagem de
dados.
Todo esse fluxo do projeto do banco de dados, desde o levantamento de requisitos, passando para o
mapeamento e modelagem com os modelos conceitual, lógico e físico é representado no Diagrama 1:
Diagrama 1 – Fluxo do projeto do banco de dados
Fonte: ELMASRI E NAVATHE, 2011. p. 37. (Adaptado).
O mapeamento desses dados é realizado com base nas informações obtidas na etapa de levantamento de
requisitos, que fornece subsídios para a identificação de quais relações deverão ser coletadas para o banco de
dados.
repositório compatível com o negócio. Essas atividades são formadas pelo mapeamento e modelagem de
dados.
Todo esse fluxo do projeto do banco de dados, desde o levantamento de requisitos, passando para o
mapeamento e modelagem com os modelos conceitual, lógico e físico é representado no Diagrama 1:
Diagrama 1 – Fluxo do projeto do banco de dados
Fonte: ELMASRI E NAVATHE, 2011. p. 37. (Adaptado).
O mapeamento desses dados é realizado com base nas informações obtidas na etapa de levantamento de
requisitos, que fornece subsídios para a identificação de quais relações deverão ser coletadas para o banco de
dados.
atualização das versões, utilitários de sincronização e exportação de dados.
Dentre outras classificações existentes para SGBD, quanto ao modelo podem ser relacional, objeto ou
objeto-relacional.
O modelo classificado como relacional é comercialmente muito utilizada, principalmente pela forte presença no
mercado de inúmeros SGBDR (Sistema de Gerenciamento de Bancos de Dados Relacional). As características
desse modelo estão na simplicidade e facilidade com as quais o banco de dados pode ser implementado e
manipulado, abstraindo a complexidade incorporada em funções pré-existentes, acelerando e aumentando a
produtividade da equipe de desenvolvimento.
VOCÊ SABIA?
Outra razão do modelo relacional se manter ainda mais forte no mercado é sua integração com a
principal linguagem de consulta e manipulação de dados, o SQL (Structured Query Language).
Já o modelo objeto é atendido pelos Sistemas de Gerenciamento de Banco de Dados Orientado a Objetos
(SGBDOO), que trazem características do paradigma Orientado a Objeto (OO) para dentro de soluções de
SGBD. Nesses, os métodos e objetos podem ser invocados conforme o paradigma OO. Limitações
encontradas no modelo relacional são resolvidas a partir de características e extensões que podem ser
incorporadas na aplicação junto com o SGBDOO.
O modelo objeto-relacional entrega SGBDs que buscam o melhor dos dois mundos, como, por exemplo, uso
do SQL para consultas e paradigmas do Orientado a Objeto como reutilização, encapsulamento, interfaces e
outras características.
1.1.3 Modelo de banco de dados
No livro de Setzer e Silva (2005), um modelo de banco de dados é definido como uma descrição dos tipos de
informações que estão armazenadas em um banco de dados. Ou seja, a preocupação no modelo é descrever
os objetivos dos dados e não necessariamente os valores que assumirão.
A construção do modelo de banco de dados compõe uma das etapas do projeto do banco de dados.
Cada modelo será denominado como esquema de banco de dados.
O projeto do banco de dados deve atender aos requisitos levantados considerando os processos e regras que
serão acolhidos no sistema. Por exemplo, em uma aplicação para o varejo, que tem como um dos requisitos
cadastrar produtos de parceiros, as estruturas que comportem os dados dos produtos, dos parceiros, assim
como uma relação entre elas, deverão ser pensadas no projeto do banco de dados.
É uma sequência de atividades que mapeiam e definem as estruturas no banco de dados para garantir um
UNIDADE 1. ARQUITETURA DE DADOS 6
VOCÊ QUER LER?
Para um aprofundamento melhor sobre levantamento de requisitos, suas práticas e atividades, sugere-
se a leitura do capítulo “Requisitos” do livro Engenharia de software, do autor Ian Sommerville.
Com o mapeamento identificado, o chamado modelo conceitual é desenvolvido para explicitar as estruturas
de dados em um nível de abstração mais alto, permitindo aos envolvidos de negócio perceberem quais tipos de
informações serão armazenados e poderão ser manipulados. O Diagrama 2 representa um exemplo do modelo
conceitual.
Diagrama 2 – Exemplo de Modelo Conceitual
Fonte: Elaborado pelo autor.
Após essa definição, com intuito de deixar mais claro o fluxo dos dados tanto para a equipe técnica como para
os envolvidos no negócio, deve ser demonstrado graficamente objetos e seus descritores, bem como eles se
relacionam. Esse modelo denominamos de modelo lógico. É possível ver um exemplo na Diagrama 3.
Diagrama 3 – Exemplo de Modelo Lógico
Fonte: Elaborado pelo autor.
Alguns itens de detalhamento do modelo lógico, como atributos ou relações, já podem ser encontrados
previamente também no modelo conceitual. Esse detalhamento maior ou menor fica a cargo da equipe e dos
envolvidos.Por fim, já considerando os detalhes do SGDBR que suportará a aplicação, é desenvolvido o
modelo físico traduzindo seus tipos de dados, relacionamentos, arquivos e restrições específicos daquele
SGBD escolhido.
VOCÊ QUER LER?
Para um aprofundamento melhor sobre levantamento de requisitos, suas práticas e atividades, sugere-
se a leitura do capítulo “Requisitos” do livro Engenharia de software, do autor Ian Sommerville.
Com o mapeamento identificado, o chamado modelo conceitual é desenvolvido para explicitar as estruturas
de dados em um nível de abstração mais alto, permitindo aos envolvidos de negócio perceberem quais tipos de
informações serão armazenados e poderão ser manipulados. O Diagrama 2 representa um exemplo do modelo
conceitual.
Diagrama 2 – Exemplo de Modelo Conceitual
Fonte: Elaborado pelo autor.
Após essa definição, com intuito de deixar mais claro o fluxo dos dados tanto para a equipe técnica como para
os envolvidos no negócio, deve ser demonstrado graficamente objetos e seus descritores, bem como eles se
relacionam. Esse modelo denominamos de modelo lógico. É possível ver um exemplo na Diagrama 3.
Diagrama 3 – Exemplo de Modelo Lógico
Fonte: Elaborado pelo autor.
Alguns itens de detalhamento do modelo lógico, como atributos ou relações, já podem ser encontrados
previamente também no modelo conceitual. Esse detalhamento maior ou menor fica a cargo da equipe e dos
envolvidos.Por fim, já considerando os detalhes do SGDBR que suportará a aplicação, é desenvolvido o
modelo físico traduzindo seus tipos de dados, relacionamentos, arquivos e restrições específicos daquele
SGBD escolhido.
repositório compatível com o negócio. Essas atividades são formadas pelo mapeamento e modelagem de
dados.
Todo esse fluxo do projetodo banco de dados, desde o levantamento de requisitos, passando para o
mapeamento e modelagem com os modelos conceitual, lógico e físico é representado no Diagrama 1:
Diagrama 1 – Fluxo do projeto do banco de dados
Fonte: ELMASRI E NAVATHE, 2011. p. 37. (Adaptado).
O mapeamento desses dados é realizado com base nas informações obtidas na etapa de levantamento de
requisitos, que fornece subsídios para a identificação de quais relações deverão ser coletadas para o banco de
dados.
UNIDADE 1. ARQUITETURA DE DADOS 7
1.1.4 Modelo de dados relacional
Apresentado pelo pesquisador da IBM, Codd (1970), o modelo de dados relacional descreve uma nova forma
de disposição das estruturas existentes no banco de dados, prezando pela independência de dados e regras
para garantir a consistência e evitar redundâncias. O modelo apresentado por Codd é baseado na teoria dos
conjuntos herdando suas propriedades.
No modelo de dados relacional, os dados são estruturados em tabelas, compostas por uma série de linhas ou
tuplas, que representam os dados. Cada tabela também é constituída por campos ou atributos, que
caracterizam cada valor na linha. Como exemplo, a Tabela 1 representa os dados de clientes pela tabela
cliente, que por sua vez contém campos nome, idade, endereço e telefone e possuem cinco linhas ou tuplas.
Tabela 1 – Representação de uma tabela, com os atributos e linhas
TABELA: CLIENTE
NOME IDADE ENDEREÇO TELEFONE
Maria do Rosário 43
A. 7 de Setembro,
n. 
100
98276-3433
João Carlos e Silva 54 Rua Dom João 93683-3398
Aparecida Santos 
Lopes
22
Estrada São Luis, n.
114
3268-4633
Inês de Castro 29
Rua do Nordeste,
255
98635-3522
Willian Bernardes 
Souza
15
Estrada das
Barreiras
3218-4433
Linhas 
ou 
Tuplas
Campos ou Atributos
1.1.4 Modelo de dados relacional
Apresentado pelo pesquisador da IBM, Codd (1970), o modelo de dados relacional descreve uma nova forma
de disposição das estruturas existentes no banco de dados, prezando pela independência de dados e regras
para garantir a consistência e evitar redundâncias. O modelo apresentado por Codd é baseado na teoria dos
conjuntos herdando suas propriedades.
No modelo de dados relacional, os dados são estruturados em tabelas, compostas por uma série de linhas ou
tuplas, que representam os dados. Cada tabela também é constituída por campos ou atributos, que
caracterizam cada valor na linha. Como exemplo, a Tabela 1 representa os dados de clientes pela tabela
cliente, que por sua vez contém campos nome, idade, endereço e telefone e possuem cinco linhas ou tuplas.
Tabela 1 – Representação de uma tabela, com os atributos e linhas
TABELA: CLIENTE
NOME IDADE ENDEREÇO TELEFONE
Maria do Rosário 43
A. 7 de Setembro,
n. 
100
98276-3433
João Carlos e Silva 54 Rua Dom João 93683-3398
Aparecida Santos 
Lopes
22
Estrada São Luis, n.
114
3268-4633
Inês de Castro 29
Rua do Nordeste,
255
98635-3522
Willian Bernardes 
Souza
15
Estrada das
Barreiras
3218-4433
Linhas 
ou 
Tuplas
Campos ou Atributos
Fonte: Elaborado pelo autor.
Em um banco de dados relacional, as tabelas também podem ser conhecidas como relações, os atributos
como colunas, e o número de campos que uma relação possui, como grau de uma relação. Domínio é o
conjunto de valores existentes ou possíveis em um atributo.
O SGBDR segue as propriedades do modelo relacional, possibilitando a construção de inúmeras tabelas,
atributos e permitindo que centenas ou milhares de linhas sejam inseridas e manipuladas. Além disso, também
estarão presentes as seguintes características do modelo:
Características do modelo
» Clique nas setas ou arraste para visualizar o conteúdo
Assim, o SGBDR consegue representar fisicamente a proposta e os critérios do modelo relacional.
Regras de construção do modelo relacional. 
1.1.5 Introdução a álgebra relacional
Com o intuito de consultas dentro da abordagem adotada pelo modelo relacional, Codd (1970) propôs a
álgebra relacional para operar as relações e assim obter novas relações como resultados.
Segundo Elmasri e Navathe (2016), uma sequência de operações da álgebra relacional forma uma expressão
cujo resultado será uma relação que representa o resultado de uma consulta de banco de dados (ou consulta
de recuperação). Assim, veremos como a utilização de expressões simples representam formalmente um
pedido de recuperação de dados e estruturas das relações envolvidas.
A álgebra relacional é utilizada por operadores da teoria de conjuntos como União e Intersecção, e
operadores adicionais como Projeção, Seleção e Junção.
Na Tabela 2 é possível identificar as relações FORNECEDOR e SOCIOFORN representando dados de
fornecedores e seus sócios. Cada uma das relações possui atributos e dados que os qualificam.
Tabela 2 – Tabela FORNECEDOR e SOCIOFORN
RELAÇÃO/TABELA: FORNECEDOR
UNIDADE 1. ARQUITETURA DE DADOS 8
Fonte: Elaborado pelo autor.
Em um banco de dados relacional, as tabelas também podem ser conhecidas como relações, os atributos
como colunas, e o número de campos que uma relação possui, como grau de uma relação. Domínio é o
conjunto de valores existentes ou possíveis em um atributo.
O SGBDR segue as propriedades do modelo relacional, possibilitando a construção de inúmeras tabelas,
atributos e permitindo que centenas ou milhares de linhas sejam inseridas e manipuladas. Além disso, também
estarão presentes as seguintes características do modelo:
Características do modelo
» Clique nas setas ou arraste para visualizar o conteúdo
Assim, o SGBDR consegue representar fisicamente a proposta e os critérios do modelo relacional.
Regras de construção do modelo relacional. 
1.1.5 Introdução a álgebra relacional
Com o intuito de consultas dentro da abordagem adotada pelo modelo relacional, Codd (1970) propôs a
álgebra relacional para operar as relações e assim obter novas relações como resultados.
Segundo Elmasri e Navathe (2016), uma sequência de operações da álgebra relacional forma uma expressão
cujo resultado será uma relação que representa o resultado de uma consulta de banco de dados (ou consulta
de recuperação). Assim, veremos como a utilização de expressões simples representam formalmente um
pedido de recuperação de dados e estruturas das relações envolvidas.
A álgebra relacional é utilizada por operadores da teoria de conjuntos como União e Intersecção, e
operadores adicionais como Projeção, Seleção e Junção.
Na Tabela 2 é possível identificar as relações FORNECEDOR e SOCIOFORN representando dados de
fornecedores e seus sócios. Cada uma das relações possui atributos e dados que os qualificam.
Tabela 2 – Tabela FORNECEDOR e SOCIOFORN
RELAÇÃO/TABELA: FORNECEDOR
Fonte: Elaborado pelo autor.
Em um banco de dados relacional, as tabelas também podem ser conhecidas como relações, os atributos
como colunas, e o número de campos que uma relação possui, como grau de uma relação. Domínio é o
conjunto de valores existentes ou possíveis em um atributo.
O SGBDR segue as propriedades do modelo relacional, possibilitando a construção de inúmeras tabelas,
atributos e permitindo que centenas ou milhares de linhas sejam inseridas e manipuladas. Além disso, também
estarão presentes as seguintes características do modelo:
Características do modelo
» Clique nas setas ou arraste para visualizar o conteúdo
Assim, o SGBDR consegue representar fisicamente a proposta e os critérios do modelo relacional.
Regras de construção do modelo relacional. 
1.1.5 Introdução a álgebra relacional
Com o intuito de consultas dentro da abordagem adotada pelo modelo relacional, Codd (1970) propôs a
álgebra relacional para operar as relações e assim obter novas relações como resultados.
Segundo Elmasri e Navathe (2016), uma sequência de operações da álgebra relacional forma uma expressão
cujo resultado será uma relação que representa o resultado de uma consulta de banco de dados (ou consulta
de recuperação). Assim, veremos como a utilização de expressões simples representam formalmente um
pedido de recuperação de dados e estruturas das relações envolvidas.
Aálgebra relacional é utilizada por operadores da teoria de conjuntos como União e Intersecção, e
operadores adicionais como Projeção, Seleção e Junção.
Na Tabela 2 é possível identificar as relações FORNECEDOR e SOCIOFORN representando dados de
fornecedores e seus sócios. Cada uma das relações possui atributos e dados que os qualificam.
Tabela 2 – Tabela FORNECEDOR e SOCIOFORN
RELAÇÃO/TABELA: FORNECEDOR
Regras de construção do modelo relacional.
Critérios para eliminar redundâncias nas estruturas de dados.
Linguagem de alto nível para consulta e manipulação das 
estruturas e dados (SQL).
UNIDADE 1. ARQUITETURA DE DADOS 9
NOMEFORN ENDERECO BAIRRO ESTADO TIPOFORN
BOMPRECO AV. BRASIL N22 SÃO GONCALO RJ PJ
FERREIRASA
RUA SÃO PEDRO
N10
PITUBA BA PJ
BRASILCAFE
RUA CARLOS
COSTA
BARRA BA PF
RELAÇÃO/TABELA: SOCIOFORN
NOMESOCIO NOMEFORN PERC_CAPITAL
BOMPRECO
100
JOAO
FERREIRASA
100
JOSE BRASILCAFE
CARLOS 50
MARIA FERREIRASA 50
Fonte: Elaborado pelo autor.
Na Tabela 3, as operações de Projeção, Seleção, Junção, União e Intersecção são demonstradas,
representando seus símbolos na Álgebra Relacional, a sintaxe e objetivo, bem como exemplos e a explicação
do exemplo consumindo as relações FORNECEDOR e SOCIOFORNEC.
Tabela 3 – Tabela de operações e exemplos da álgebra relacional
Fonte: Elaborado pelo autor.
Em um banco de dados relacional, as tabelas também podem ser conhecidas como relações, os atributos
como colunas, e o número de campos que uma relação possui, como grau de uma relação. Domínio é o
conjunto de valores existentes ou possíveis em um atributo.
O SGBDR segue as propriedades do modelo relacional, possibilitando a construção de inúmeras tabelas,
atributos e permitindo que centenas ou milhares de linhas sejam inseridas e manipuladas. Além disso, também
estarão presentes as seguintes características do modelo:
Características do modelo
» Clique nas setas ou arraste para visualizar o conteúdo
Assim, o SGBDR consegue representar fisicamente a proposta e os critérios do modelo relacional.
Regras de construção do modelo relacional. 
1.1.5 Introdução a álgebra relacional
Com o intuito de consultas dentro da abordagem adotada pelo modelo relacional, Codd (1970) propôs a
álgebra relacional para operar as relações e assim obter novas relações como resultados.
Segundo Elmasri e Navathe (2016), uma sequência de operações da álgebra relacional forma uma expressão
cujo resultado será uma relação que representa o resultado de uma consulta de banco de dados (ou consulta
de recuperação). Assim, veremos como a utilização de expressões simples representam formalmente um
pedido de recuperação de dados e estruturas das relações envolvidas.
A álgebra relacional é utilizada por operadores da teoria de conjuntos como União e Intersecção, e
operadores adicionais como Projeção, Seleção e Junção.
Na Tabela 2 é possível identificar as relações FORNECEDOR e SOCIOFORN representando dados de
fornecedores e seus sócios. Cada uma das relações possui atributos e dados que os qualificam.
Tabela 2 – Tabela FORNECEDOR e SOCIOFORN
RELAÇÃO/TABELA: FORNECEDOR
UNIDADE 1. ARQUITETURA DE DADOS 10
NOMEFORN ENDERECO BAIRRO ESTADO TIPOFORN
BOMPRECO AV. BRASIL N22 SÃO GONCALO RJ PJ
FERREIRASA
RUA SÃO PEDRO
N10
PITUBA BA PJ
BRASILCAFE
RUA CARLOS
COSTA
BARRA BA PF
RELAÇÃO/TABELA: SOCIOFORN
NOMESOCIO NOMEFORN PERC_CAPITAL
BOMPRECO
100
JOAO
FERREIRASA
100
JOSE BRASILCAFE
CARLOS 50
MARIA FERREIRASA 50
Fonte: Elaborado pelo autor.
Na Tabela 3, as operações de Projeção, Seleção, Junção, União e Intersecção são demonstradas,
representando seus símbolos na Álgebra Relacional, a sintaxe e objetivo, bem como exemplos e a explicação
do exemplo consumindo as relações FORNECEDOR e SOCIOFORNEC.
Tabela 3 – Tabela de operações e exemplos da álgebra relacional
UNIDADE 1. ARQUITETURA DE DADOS 11
SÍMBOLO OPERAÇÃO SINTAXE OBJETIVO EXEMPLOS
EXPLICANDO O 
EXEMPLO
π Projeção
π 
expressão 
(Relação)
Selecionar um 
subconjunto 
de campos da 
relação.
π NOMEFORN, 
ESTADO 
(FORNECEDOR)
Retorna 
uma relação 
demonstrando 
o nome do 
fornecedor e o 
estado a partir 
da relação 
FORNECEDOR.
σ Seleção
σ condição 
(Relação)
Selecionar 
um conjunto 
de dados a 
partir de uma 
restrição.
σ ESTADO=’BA’
(FORNECEDOR)
Retorna 
uma relação 
demonstrando 
os dados de 
fornecedores 
do ESTADO 
igual BA.
|x| Junção
Relação A 
|x| Relação 
B
Relacionar 
a Relação 
A com a 
Relação B a 
partir de uma 
equivalência 
de valores.
π NOMEFORN, 
ESTADO, 
NOMESOCIO (σ 
FORNECEDOR.
NOMEFORN=
SOCIOFORN.
NOMEFORN
(FORNECEDOR |x| 
SOCIOFORN))
Retornando uma 
relação com o 
NOMEFORNE-
CEDOR,
ESTADO e 
NOMESOCIO, 
onde o 
NOMEFORN tem 
valores iguais/ 
equivalentes 
pela JUNÇÃO de 
FORNECEDOR e 
SOCIOFORN.
fornecedores, p
esse exemplo.
Intersecção
Relação A
∩
Relação B
Intersecção
das linhas
de Relação
A com
Relação B.
RELACAO1 σ
TIPOFORN=’PJ’(FORNECEDOR)
RELACAO2 σ
ESTADO=’BA’(FORNECEDOR)
RELACAO1 ∩ RELACAO2
uma relação co
INTERSECÇÃO
linhas de forne
onde o TIPOFO
PJ com as linha
os fornecedore
com ESTADO i
BA. Ao final, te
somente uma l
com o forneced
FERREIRASA.
Fonte: Elaborado pelo autor.
Vimos nesses exemplos apenas uma introdução do funcionamento prático de algumas das operações
possíveis com álgebra relacional. Existem diversas outras possibilidades que nos permitem consultar e extrair
novas relações, realizando uma combinação dessas ou utilizando outras como divisão, renomeação, atribuição,
produto cartesiano e mais.
VOCÊ SABIA?
A álgebra relacional é conhecida como o modo teórico da realização de consultas de banco de dados. A
linguagem SQL tem em sua base a álgebra relacional, sendo esta a representação prática dessa
estrutura nas consultas em SGBDR.
1.2 Modelo de entidades e relacionamentos
Desenvolvido para descrever graficamente a semântica dos dados, o modelo de entidades e relacionamentos
(MER ou ER) dá suporte aos modelos conceituais e lógicos na compreensão das estruturas que posteriormente
poderão ser criadas no banco de dados.
Ao longo desta unidade, conheceremos as principais estruturas de um modelo ER e falaremos sobre entidade
e suas definições, relacionamentos e representações no modelo.
UNIDADE 1. ARQUITETURA DE DADOS 12
U União
Relação A 
U Relação 
B
União das 
linhas da 
Relação A 
com Relação 
B.
RELACAO1 
σ TIPOFORN=’PJ’
(FORNECEDOR)
RELACAO2
σ ESTADO=’BA’
(FORNECEDOR)
RELACAO1 U 
RELACAO 2
Uma relação 
com as linhas 
de fornecedores 
onde o 
TIPOFORN é 
PJ unindo com 
as linhas onde 
os fornecedores 
estão com 
ESTADO igual 
a BA. Ao final, 
teremos a mesma 
quantidade de 
linhas da relação 
fornecedores, 
para 
esse exemplo.
∩ Intersecção
Relação A 
∩ Relação 
B
Intersecção 
das linhas de 
Relação A 
com Relação 
B.
RELACAO1 
σ TIPOFORN=’PJ’
(FORNECEDOR)
RELACAO2
σ ESTADO=’BA’
(FORNECEDOR)
RELACAO1 ∩ 
RELACAO2
Uma relação 
com a 
INTERSECÇÃO 
das linhas de 
fornecedores 
onde o 
TIPOFORN 
é PJ com as 
linhas onde os 
fornecedores 
estão com 
ESTADO igual 
a BA. Ao final, 
teremos somente 
uma linha com 
o fornecedor 
FERREIRASA.
fornecedores, p
esse exemplo.
Intersecção
Relação A
∩
Relação B
Intersecção
das linhas
de Relação
A com
Relação B.
RELACAO1 σ
TIPOFORN=’PJ’(FORNECEDOR)
RELACAO2 σ
ESTADO=’BA’(FORNECEDOR)
RELACAO1 ∩ RELACAO2
uma relação co
INTERSECÇÃO
linhas de forne
onde o TIPOFO
PJ com as linha
os fornecedore
com ESTADO i
BA. Ao final, te
somente uma l
com o forneced
FERREIRASA.
Fonte: Elaborado pelo autor.
Vimos nesses exemplos apenas uma introdução do funcionamento prático de algumas das operações
possíveis com álgebra relacional. Existem diversas outras possibilidades que nos permitem consultar e extrair
novas relações, realizando uma combinação dessas ou utilizando outras como divisão, renomeação, atribuição,
produto cartesiano e mais.
VOCÊ SABIA?
A álgebra relacional é conhecida como o modo teórico da realização de consultas de banco de dados. A
linguagem SQL tem em sua base a álgebra relacional, sendoesta a representação prática dessa
estrutura nas consultas em SGBDR.
1.2 Modelo de entidades e relacionamentos
Desenvolvido para descrever graficamente a semântica dos dados, o modelo de entidades e relacionamentos
(MER ou ER) dá suporte aos modelos conceituais e lógicos na compreensão das estruturas que posteriormente
poderão ser criadas no banco de dados.
Ao longo desta unidade, conheceremos as principais estruturas de um modelo ER e falaremos sobre entidade
e suas definições, relacionamentos e representações no modelo.
1.2.1 Entidade
Elemento essencial de um modelo de entidade e relacionamentos, a entidade pode ser definida como a
representação mais próxima da realidade descrita sobre forma de um objeto que armazenará dados em banco
de dados.
Setzer e Silva (2005) definem que “uma entidade representa um conjunto de objetos da realidade modelada”.
Esses objetos podem representar coisas concretas, como pessoas, veículos, estabelecimentos ou coisas
abstratas, como promoções, relacionamentos, períodos e outros.
A representação gráfica no modelo ER de uma entidade é através de um retângulo, conforme o Diagrama 4,
onde são visualizadas as entidades de CLIENTE, PRODUTO, FERIADOS.
Diagrama 4 – Representação no ER das entidades CLIENTE, PRODUTO e FERIADO
Fonte: Elaborado pelo autor.
A entidade CLIENTE representa que serão guardados o conjunto de dados de diversos clientes e suas
características. Isso vale para as outras entidades exemplificadas.
No modelo ER, as linhas ou tuplas de cada entidade serão denominadas de instâncias. Assim, cada linha é
uma instância na entidade.
Uma entidade pode ser classificada como dependente ou fraca. Isso quer dizer que sua relevância dos dados
depende de outra entidade. Por exemplo, uma entidade TRANSAÇÃO depende da identificação do cliente e
produto para que seu dado tenha significado, por isso se classifica como dependente ou fraca. Já para uma
entidade forte, não existe dependência, como, por exemplo, a entidade CLIENTE e PRODUTO, em que seus
dados por si só já os representam.
» Atributos
Outro elemento que faz parte da construção de uma entidade é o atributo. O conjunto de atributos irá qualificar
ou caracterizar a entidade. Cada entidade terá um ou mais atributos, caracterizando cada valor ali armazenado.
Na entidade CLIENTE, podemos ter os atributos Nome do Cliente, Idade, Endereço e Cidade. Já na entidade
PRODUTO, os atributos Nome do Produto e Categoria. Observe que os atributos descrevem ainda mais o que
a entidade deseja representar.
A representação gráfica do atributo é através de uma elipse. O Diagrama 5 representa os atributos das
entidades CLIENTE e PRODUTO:
UNIDADE 1. ARQUITETURA DE DADOS 13
1.2.1 Entidade
Elemento essencial de um modelo de entidade e relacionamentos, a entidade pode ser definida como a
representação mais próxima da realidade descrita sobre forma de um objeto que armazenará dados em banco
de dados.
Setzer e Silva (2005) definem que “uma entidade representa um conjunto de objetos da realidade modelada”.
Esses objetos podem representar coisas concretas, como pessoas, veículos, estabelecimentos ou coisas
abstratas, como promoções, relacionamentos, períodos e outros.
A representação gráfica no modelo ER de uma entidade é através de um retângulo, conforme o Diagrama 4,
onde são visualizadas as entidades de CLIENTE, PRODUTO, FERIADOS.
Diagrama 4 – Representação no ER das entidades CLIENTE, PRODUTO e FERIADO
Fonte: Elaborado pelo autor.
A entidade CLIENTE representa que serão guardados o conjunto de dados de diversos clientes e suas
características. Isso vale para as outras entidades exemplificadas.
No modelo ER, as linhas ou tuplas de cada entidade serão denominadas de instâncias. Assim, cada linha é
uma instância na entidade.
Uma entidade pode ser classificada como dependente ou fraca. Isso quer dizer que sua relevância dos dados
depende de outra entidade. Por exemplo, uma entidade TRANSAÇÃO depende da identificação do cliente e
produto para que seu dado tenha significado, por isso se classifica como dependente ou fraca. Já para uma
entidade forte, não existe dependência, como, por exemplo, a entidade CLIENTE e PRODUTO, em que seus
dados por si só já os representam.
» Atributos
Outro elemento que faz parte da construção de uma entidade é o atributo. O conjunto de atributos irá qualificar
ou caracterizar a entidade. Cada entidade terá um ou mais atributos, caracterizando cada valor ali armazenado.
Na entidade CLIENTE, podemos ter os atributos Nome do Cliente, Idade, Endereço e Cidade. Já na entidade
PRODUTO, os atributos Nome do Produto e Categoria. Observe que os atributos descrevem ainda mais o que
a entidade deseja representar.
A representação gráfica do atributo é através de uma elipse. O Diagrama 5 representa os atributos das
entidades CLIENTE e PRODUTO:
Diagrama 5 – Representação no ER das entidades e atributos (CLIENTE, PRODUTO)
Fonte: Elaborada pelo autor.
Na representação do atributo, quando a elipse está preenchida, qualificamos como atributo chave ou
identificador. Essa tipificação deve ser direcionada ao atributo que permitirá identificar unicamente cada
instância naquela entidade. No exemplo do Diagrama 5, é possível identificar que o atributo cod_cliente da
entidade CLIENTE é a chave e seus valores não se repetirão, sendo únicos. O mesmo vale para cod_produto
na entidade PRODUTO.
Outro conceito importante do atributo é o domínio. O domínio de um atributo é o conjunto de valores que ele
pode assumir, e isso dependerá do tipo de dado que receberá.
Por exemplo, se for texto em um atributo como Nome Cliente, o domínio será textual. Agora, mesmo o atributo
Turno sendo textual, podemos qualificar o domínio como textual e de valores como “Noturno”, “Matutino” e
“Vespertino”. Para outros tipos de dados, o raciocínio é o mesmo. O Diagrama 6 representa o domínio.
Diagrama 6 – Exemplo do domínio
UNIDADE 1. ARQUITETURA DE DADOS 14
Diagrama 5 – Representação no ER das entidades e atributos (CLIENTE, PRODUTO)
Fonte: Elaborada pelo autor.
Na representação do atributo, quando a elipse está preenchida, qualificamos como atributo chave ou
identificador. Essa tipificação deve ser direcionada ao atributo que permitirá identificar unicamente cada
instância naquela entidade. No exemplo do Diagrama 5, é possível identificar que o atributo cod_cliente da
entidade CLIENTE é a chave e seus valores não se repetirão, sendo únicos. O mesmo vale para cod_produto
na entidade PRODUTO.
Outro conceito importante do atributo é o domínio. O domínio de um atributo é o conjunto de valores que ele
pode assumir, e isso dependerá do tipo de dado que receberá.
Por exemplo, se for texto em um atributo como Nome Cliente, o domínio será textual. Agora, mesmo o atributo
Turno sendo textual, podemos qualificar o domínio como textual e de valores como “Noturno”, “Matutino” e
“Vespertino”. Para outros tipos de dados, o raciocínio é o mesmo. O Diagrama 6 representa o domínio.
Diagrama 6 – Exemplo do domínio
Fonte: Elaborada pelo autor.
A construção do atributo pode ser do tipo simples ou composta. Em um exemplo em que existe a
necessidade de armazenar o logradouro do cliente, composto pelo endereço, bairro, cep e cidade, a decisão da
construção do atributo pode ser tipificada como simples, definindo apenas o atributo Endereço e neste
armazenar de uma só vez os valores sequenciados de endereço, bairro, cep e cidade. Ou, se a decisão for
criar de forma Composta, será definido um atributo para armazenar o valor de endereço e outros três atributos
ligados a este, bairro, cep e cidade.
Diagrama 7 – Exemplo de atributo composto endereço
Fonte: Elaborada pelo autor.
Outra tipificação para atributo é se será de valor único ou multivalorado. No exemplo da entidade CLIENTE,
o atributo nome_cliente é de valor único, pois cada cliente tem apenas um nome. Entretanto, se nesta mesma
entidade for criado o atributo num_telefone e neste for armazenar diversos telefones do mesmo cliente, então o
atributo num_telefone será multivalorado.
E, porfim, o atributo pode ser do tipo de valor armazenado ou derivado. Ainda no exemplo da entidade
CLIENTE, suponhamos que existam os atributos data_nascimento e num_idade. Então, caso os valores do
atributo num_idade sejam obtidos a partir do cálculo da diferença da data atual pela data de nascimento, então
o atributo será qualificado como derivado. Caso esse cálculo não seja realizado e o valor seja guardado
diretamente, então é qualificado como armazenado.
1.3 Modelagem de dados
O relacionamento entre as entidades representa o cerne fundamental para modelagem de dados. É o
elemento que permite representar associações de entidades e dados do mundo real.
1.3.1 Relacionamento
Medeiros (2007) define “um relacionamento como uma associação entre entidades, em que as pertencentes a
um relacionamento se dizem participantes do mesmo”. É uma propriedade que a entidade possui, a de se
Fonte: Elaborada pelo autor.
A construção do atributo pode ser do tipo simples ou composta. Em um exemplo em que existe a
necessidade de armazenar o logradouro do cliente, composto pelo endereço, bairro, cep e cidade, a decisão da
construção do atributo pode ser tipificada como simples, definindo apenas o atributo Endereço e neste
armazenar de uma só vez os valores sequenciados de endereço, bairro, cep e cidade. Ou, se a decisão for
criar de forma Composta, será definido um atributo para armazenar o valor de endereço e outros três atributos
ligados a este, bairro, cep e cidade.
Diagrama 7 – Exemplo de atributo composto endereço
Fonte: Elaborada pelo autor.
Outra tipificação para atributo é se será de valor único ou multivalorado. No exemplo da entidade CLIENTE,
o atributo nome_cliente é de valor único, pois cada cliente tem apenas um nome. Entretanto, se nesta mesma
entidade for criado o atributo num_telefone e neste for armazenar diversos telefones do mesmo cliente, então o
atributo num_telefone será multivalorado.
E, por fim, o atributo pode ser do tipo de valor armazenado ou derivado. Ainda no exemplo da entidade
CLIENTE, suponhamos que existam os atributos data_nascimento e num_idade. Então, caso os valores do
atributo num_idade sejam obtidos a partir do cálculo da diferença da data atual pela data de nascimento, então
o atributo será qualificado como derivado. Caso esse cálculo não seja realizado e o valor seja guardado
diretamente, então é qualificado como armazenado.
1.3 Modelagem de dados
O relacionamento entre as entidades representa o cerne fundamental para modelagem de dados. É o
elemento que permite representar associações de entidades e dados do mundo real.
1.3.1 Relacionamento
Medeiros (2007) define “um relacionamento como uma associação entre entidades, em que as pertencentes a
um relacionamento se dizem participantes do mesmo”. É uma propriedade que a entidade possui, a de se
UNIDADE 1. ARQUITETURA DE DADOS 15
relacionar, e que no modelo de dados é fundamental para que se possa retratar as relações existentes entre os
fatos e os dados.
Para representar como os dados e conjuntos desses se relacionam, considere o caso em que um cliente pode
comprar um ou mais produtos, assim como um produto pode ser adquirido por um ou mais clientes. O
Diagrama 8 demonstra um diagrama de ocorrências para esse cenário:
Diagrama 8 – Representação de ocorrências
Fonte: Elaborada pelo autor.
Pode-se ver no Diagrama 8 que o cliente João comprou os produtos macarrão e feijão, já o produto macarrão
foi comprado pelos clientes João e Carlos. Assim, o conjunto COMPRA está representando o relacionamento
entre os conjuntos CLIENTE e PRODUTO, formando uma associação entre estes e seus elementos.
A representação gráfica do relacionamento no modelo ER é um losango, ligado por linhas que associam as
entidades envolvidas. No Diagrama 9, é demonstrado o caso no modelo entidade-relacionamento.
Diagrama 9 – Representação do relacionamento COMPRA entre CLIENTE e PRODUTO no modelo ER
Fonte: Elaborada pelo autor.
Na representação do Diagrama 9, as entidades CLIENTE e PRODUTO estão dispostas nos retângulos
conectados através do relacionamento descrito como COMPRA no losango. Vale frisar que a nomenclatura
para o relacionamento deve estar em conformidade com a associação representada entre as entidades, não
Fonte: Elaborada pelo autor.
A construção do atributo pode ser do tipo simples ou composta. Em um exemplo em que existe a
necessidade de armazenar o logradouro do cliente, composto pelo endereço, bairro, cep e cidade, a decisão da
construção do atributo pode ser tipificada como simples, definindo apenas o atributo Endereço e neste
armazenar de uma só vez os valores sequenciados de endereço, bairro, cep e cidade. Ou, se a decisão for
criar de forma Composta, será definido um atributo para armazenar o valor de endereço e outros três atributos
ligados a este, bairro, cep e cidade.
Diagrama 7 – Exemplo de atributo composto endereço
Fonte: Elaborada pelo autor.
Outra tipificação para atributo é se será de valor único ou multivalorado. No exemplo da entidade CLIENTE,
o atributo nome_cliente é de valor único, pois cada cliente tem apenas um nome. Entretanto, se nesta mesma
entidade for criado o atributo num_telefone e neste for armazenar diversos telefones do mesmo cliente, então o
atributo num_telefone será multivalorado.
E, por fim, o atributo pode ser do tipo de valor armazenado ou derivado. Ainda no exemplo da entidade
CLIENTE, suponhamos que existam os atributos data_nascimento e num_idade. Então, caso os valores do
atributo num_idade sejam obtidos a partir do cálculo da diferença da data atual pela data de nascimento, então
o atributo será qualificado como derivado. Caso esse cálculo não seja realizado e o valor seja guardado
diretamente, então é qualificado como armazenado.
1.3 Modelagem de dados
O relacionamento entre as entidades representa o cerne fundamental para modelagem de dados. É o
elemento que permite representar associações de entidades e dados do mundo real.
1.3.1 Relacionamento
Medeiros (2007) define “um relacionamento como uma associação entre entidades, em que as pertencentes a
um relacionamento se dizem participantes do mesmo”. É uma propriedade que a entidade possui, a de se
UNIDADE 1. ARQUITETURA DE DADOS 16
relacionar, e que no modelo de dados é fundamental para que se possa retratar as relações existentes entre os
fatos e os dados.
Para representar como os dados e conjuntos desses se relacionam, considere o caso em que um cliente pode
comprar um ou mais produtos, assim como um produto pode ser adquirido por um ou mais clientes. O
Diagrama 8 demonstra um diagrama de ocorrências para esse cenário:
Diagrama 8 – Representação de ocorrências
Fonte: Elaborada pelo autor.
Pode-se ver no Diagrama 8 que o cliente João comprou os produtos macarrão e feijão, já o produto macarrão
foi comprado pelos clientes João e Carlos. Assim, o conjunto COMPRA está representando o relacionamento
entre os conjuntos CLIENTE e PRODUTO, formando uma associação entre estes e seus elementos.
A representação gráfica do relacionamento no modelo ER é um losango, ligado por linhas que associam as
entidades envolvidas. No Diagrama 9, é demonstrado o caso no modelo entidade-relacionamento.
Diagrama 9 – Representação do relacionamento COMPRA entre CLIENTE e PRODUTO no modelo ER
Fonte: Elaborada pelo autor.
Na representação do Diagrama 9, as entidades CLIENTE e PRODUTO estão dispostas nos retângulos
conectados através do relacionamento descrito como COMPRA no losango. Vale frisar que a nomenclatura
para o relacionamento deve estar em conformidade com a associação representada entre as entidades, não
Para identificar um relacionamento, devemos visualizar se a associação entre as entidades pode ser realizada
diretamente ou se requer um intermediador que realize essa conexão. Por exemplo, não é possível na
representação da entidade ALUNO identificar as suas DISCIPLINAS. Similarmente não é possível identificar
em uma DISCIPLINA todos os ALUNOS que a cursam. Assim, percebe-se que um relacionamento
GRADE_CURSO conectando ALUNOSe DISCIPLINA se faz necessário.
» Tipos de relacionamentos
Relacionamentos que envolvem duas entidades são qualificados como do tipo binário. Entretanto, existem
outros tipos de relacionamentos envolvendo quantidades diferentes de entidades, são eles: unário e ternário.
O tipo unário ou autorrelacionamento representa um relacionamento em que uma entidade estabelece a
relação com si própria. Por exemplo, uma entidade que representa FUNCIONARIO e tem o atributo que indica
quem é o gerente. Assim, para identificar um gerente e seus funcionários, é necessário identificar os papéis na
própria entidade e realizar o autorrelacionamento para buscar o funcionário gerente, baseando neste os seus
comandados.
Outro tipo é o ternário, demonstrado quando o relacionamento envolve três entidades. Como exemplo,
podemos citar as entidades CLIENTE, PRODUTO e LOJA. O relacionamento COMPRA continua existindo,
porém, agora associando três entidades.
No Diagrama 10, é demonstrado tanto o desenho do tipo de relacionamento unário, quanto o ternário.
Diagrama 10 – Relacionamentos dos tipos unário (A) e ternário (B)
havendo regra para sua denominação. Neste exemplo, poderia ser AQUISIÇÃO, CLIENTE_PRODUTO,
VENDA etc.
VOCÊ SABIA?
Pelas definições do modelo ER, não é possível estabelecer uma associação entre relacionamentos. Um
relacionamento é sempre entre entidades.
atualização das versões, utilitários de sincronização e exportação de dados.
Dentre outras classificações existentes para SGBD, quanto ao modelo podem ser relacional, objeto ou
objeto-relacional.
O modelo classificado como relacional é comercialmente muito utilizada, principalmente pela forte presença no
mercado de inúmeros SGBDR (Sistema de Gerenciamento de Bancos de Dados Relacional). As características
desse modelo estão na simplicidade e facilidade com as quais o banco de dados pode ser implementado e
manipulado, abstraindo a complexidade incorporada em funções pré-existentes, acelerando e aumentando a
produtividade da equipe de desenvolvimento.
VOCÊ SABIA?
Outra razão do modelo relacional se manter ainda mais forte no mercado é sua integração com a
principal linguagem de consulta e manipulação de dados, o SQL (Structured Query Language).
Já o modelo objeto é atendido pelos Sistemas de Gerenciamento de Banco de Dados Orientado a Objetos
(SGBDOO), que trazem características do paradigma Orientado a Objeto (OO) para dentro de soluções de
SGBD. Nesses, os métodos e objetos podem ser invocados conforme o paradigma OO. Limitações
encontradas no modelo relacional são resolvidas a partir de características e extensões que podem ser
incorporadas na aplicação junto com o SGBDOO.
O modelo objeto-relacional entrega SGBDs que buscam o melhor dos dois mundos, como, por exemplo, uso
do SQL para consultas e paradigmas do Orientado a Objeto como reutilização, encapsulamento, interfaces e
outras características.
1.1.3 Modelo de banco de dados
No livro de Setzer e Silva (2005), um modelo de banco de dados é definido como uma descrição dos tipos de
informações que estão armazenadas em um banco de dados. Ou seja, a preocupação no modelo é descrever
os objetivos dos dados e não necessariamente os valores que assumirão.
A construção do modelo de banco de dados compõe uma das etapas do projeto do banco de dados.
Cada modelo será denominado como esquema de banco de dados.
O projeto do banco de dados deve atender aos requisitos levantados considerando os processos e regras que
serão acolhidos no sistema. Por exemplo, em uma aplicação para o varejo, que tem como um dos requisitos
cadastrar produtos de parceiros, as estruturas que comportem os dados dos produtos, dos parceiros, assim
como uma relação entre elas, deverão ser pensadas no projeto do banco de dados.
É uma sequência de atividades que mapeiam e definem as estruturas no banco de dados para garantir um
UNIDADE 1. ARQUITETURA DE DADOS 17
Para identificar um relacionamento, devemos visualizar se a associação entre as entidades pode ser realizada
diretamente ou se requer um intermediador que realize essa conexão. Por exemplo, não é possível na
representação da entidade ALUNO identificar as suas DISCIPLINAS. Similarmente não é possível identificar
em uma DISCIPLINA todos os ALUNOS que a cursam. Assim, percebe-se que um relacionamento
GRADE_CURSO conectando ALUNOS e DISCIPLINA se faz necessário.
» Tipos de relacionamentos
Relacionamentos que envolvem duas entidades são qualificados como do tipo binário. Entretanto, existem
outros tipos de relacionamentos envolvendo quantidades diferentes de entidades, são eles: unário e ternário.
O tipo unário ou autorrelacionamento representa um relacionamento em que uma entidade estabelece a
relação com si própria. Por exemplo, uma entidade que representa FUNCIONARIO e tem o atributo que indica
quem é o gerente. Assim, para identificar um gerente e seus funcionários, é necessário identificar os papéis na
própria entidade e realizar o autorrelacionamento para buscar o funcionário gerente, baseando neste os seus
comandados.
Outro tipo é o ternário, demonstrado quando o relacionamento envolve três entidades. Como exemplo,
podemos citar as entidades CLIENTE, PRODUTO e LOJA. O relacionamento COMPRA continua existindo,
porém, agora associando três entidades.
No Diagrama 10, é demonstrado tanto o desenho do tipo de relacionamento unário, quanto o ternário.
Diagrama 10 – Relacionamentos dos tipos unário (A) e ternário (B)
havendo regra para sua denominação. Neste exemplo, poderia ser AQUISIÇÃO, CLIENTE_PRODUTO,
VENDA etc.
VOCÊ SABIA?
Pelas definições do modelo ER, não é possível estabelecer uma associação entre relacionamentos. Um
relacionamento é sempre entre entidades.
Fonte: Elaborado pelo autor.
No Diagrama 10, especificamente do tipo unário, percebemos os papéis quando a entidade está como papel
de gerente, ou seja, “faz a gerência” de funcionários e quando a visão é pelo colaborador, o funcionário “é
gerenciado” pelo gerente.
1.3.2 Mais elementos
Além desses conceitos apresentados anteriormente, o relacionamento no modelo ER é constituído por alguns
outros elementos que completam as suas definições. Nos próximos tópicos conheceremos mais cardinalidade
e generalização/especialização aplicado na modelagem do relacionamento.
Cardinalidade
O relacionamento entre as entidades deve considerar uma propriedade chamada de cardinalidade. A
cardinalidade demonstra, no modelo ER, o número mínimo e máximo de relações que cada elemento de uma
entidade pode estabelecer com os elementos da outra associada.
Por exemplo, no caso das entidades ALUNO e ESCOLA, considerando uma demanda para um sistema
escolar, se entende que cada instância de ALUNO no máximo poderá estar relacionada a uma instância de
ESCOLA, pois cada aluno está ligado a apenas uma escola. No entanto, uma instância de ESCOLA pode ser
ligada a N instâncias de ALUNO, pois uma escola possui no mínimo um a N alunos matriculados.
Cardinalidade
» Clique nas setas ou arraste para visualizar o conteúdo
UNIDADE 1. ARQUITETURA DE DADOS 18
Fonte: Elaborado pelo autor.
No Diagrama 10, especificamente do tipo unário, percebemos os papéis quando a entidade está como papel
de gerente, ou seja, “faz a gerência” de funcionários e quando a visão é pelo colaborador, o funcionário “é
gerenciado” pelo gerente.
1.3.2 Mais elementos
Além desses conceitos apresentados anteriormente, o relacionamento no modelo ER é constituído por alguns
outros elementos que completam as suas definições. Nos próximos tópicos conheceremos mais cardinalidade
e generalização/especialização aplicado na modelagem do relacionamento.
Cardinalidade
O relacionamento entre as entidades deve considerar uma propriedade chamada de cardinalidade. A
cardinalidade demonstra, no modelo ER, o número mínimo e máximo de relações que cada elemento de uma
entidade pode estabelecer com os elementos da outra associada.
Por exemplo, no caso das entidades ALUNO e ESCOLA, considerando uma demanda para um sistema
escolar, se entende que cada instância de ALUNO no máximopoderá estar relacionada a uma instância de
ESCOLA, pois cada aluno está ligado a apenas uma escola. No entanto, uma instância de ESCOLA pode ser
ligada a N instâncias de ALUNO, pois uma escola possui no mínimo um a N alunos matriculados.
Cardinalidade
» Clique nas setas ou arraste para visualizar o conteúdo
O grau da cardinalidade representa a cardinalidade mínima e a cardinalidade máxima.
No exemplo das entidades ALUNO e ESCOLA, podemos considerar a cardinalidade de (1:N). Já no exemplo
do relacionamento entre CLIENTE e PRODUTO, a cardinalidade será de (N:N), já que um cliente pode comprar
vários produtos e um produto pode ser comprado por vários clientes. O Diagrama 11 representa graficamente a
cardinalidade no modelo ER para esses dois exemplos. Na linha próxima a cada entidade e entre o
relacionamento, adicionamos o grau da cardinalidade.
Diagrama 11 – Cardinalidade do relacionamento no modelo ER
Fonte: Elaborado pelo autor.
O entendimento de qual cardinalidade deve ser aplicada precisa estar baseada nos requisitos e movimentação
dos dados entre as entidades.
» Generalização/Especialização
 (1:1) Relação de um para um. 
UNIDADE 1. ARQUITETURA DE DADOS 19
(1:N)
Relação de
um para muitos.
(1:1)
Relação de 
um para um.
(N:N)
 Relação de 
muitos para muitos.
O grau da cardinalidade representa a cardinalidade mínima e a cardinalidade máxima.
No exemplo das entidades ALUNO e ESCOLA, podemos considerar a cardinalidade de (1:N). Já no exemplo
do relacionamento entre CLIENTE e PRODUTO, a cardinalidade será de (N:N), já que um cliente pode comprar
vários produtos e um produto pode ser comprado por vários clientes. O Diagrama 11 representa graficamente a
cardinalidade no modelo ER para esses dois exemplos. Na linha próxima a cada entidade e entre o
relacionamento, adicionamos o grau da cardinalidade.
Diagrama 11 – Cardinalidade do relacionamento no modelo ER
Fonte: Elaborado pelo autor.
O entendimento de qual cardinalidade deve ser aplicada precisa estar baseada nos requisitos e movimentação
dos dados entre as entidades.
» Generalização/Especialização
 (1:1) Relação de um para um. 
Mais um elemento participante da representação de relacionamentos no modelo ER, a
generalização/especialização possibilita definir um subconjunto de instâncias em um objeto a partir da
associação.
Por exemplo, a entidade PRODUTO pode ser segmentada em subconjuntos, representados entidades
NACIONAL e IMPORTADO. Ao realizar essa especialização, características próprias das entidades são
introduzidas, assim como as vindas da entidade-pai serão propagadas para cada uma das novas. A entidade-
pai é conhecida como supertipo e as especializadas como subtipo, ou filha.
A representação gráfica da especialização/generalização é realizada através de um triângulo invertido. No
Diagrama 12, temos um exemplo para melhor entendimento:
Diagrama 12 – Exemplo de modelo ER com generalização/especialização
Fonte: Elaborado pelo autor.
No Diagrama 12, podemos observar que os atributos nas entidades especializadas, NACIONAL e
IMPORTADO, são independentes, porém herdam os atributos e as propriedades da entidade genérica
PRODUTO. Isso significa que todo PRODUTO NACIONAL tem como atributos tipo, des_prod_nac,
cod_produto e nom_produto. Destaca-se que o atributo identificador das entidades especializadas será o da
entidade genérica.
A generalização/especialização pode ter níveis diferentes e não necessariamente apenas um. Nesse mesmo
exemplo, poderíamos adicionar mais um nível, caso as regras de negócio demandassem, adicionando
entidades CERVEJA e VINHO, ambas como especializações da entidade IMPORTADO.
Entidade associativa
Já foi visto que relacionamentos devem ser sempre entre entidades e nunca entre relacionamentos. Entretanto,
surgem situações em que essa necessidade se apresenta como uma condição que deverá ser atendida no
modelo ER.
Exemplo:
UNIDADE 1. ARQUITETURA DE DADOS 20
Mais um elemento participante da representação de relacionamentos no modelo ER, a
generalização/especialização possibilita definir um subconjunto de instâncias em um objeto a partir da
associação.
Por exemplo, a entidade PRODUTO pode ser segmentada em subconjuntos, representados entidades
NACIONAL e IMPORTADO. Ao realizar essa especialização, características próprias das entidades são
introduzidas, assim como as vindas da entidade-pai serão propagadas para cada uma das novas. A entidade-
pai é conhecida como supertipo e as especializadas como subtipo, ou filha.
A representação gráfica da especialização/generalização é realizada através de um triângulo invertido. No
Diagrama 12, temos um exemplo para melhor entendimento:
Diagrama 12 – Exemplo de modelo ER com generalização/especialização
Fonte: Elaborado pelo autor.
No Diagrama 12, podemos observar que os atributos nas entidades especializadas, NACIONAL e
IMPORTADO, são independentes, porém herdam os atributos e as propriedades da entidade genérica
PRODUTO. Isso significa que todo PRODUTO NACIONAL tem como atributos tipo, des_prod_nac,
cod_produto e nom_produto. Destaca-se que o atributo identificador das entidades especializadas será o da
entidade genérica.
A generalização/especialização pode ter níveis diferentes e não necessariamente apenas um. Nesse mesmo
exemplo, poderíamos adicionar mais um nível, caso as regras de negócio demandassem, adicionando
entidades CERVEJA e VINHO, ambas como especializações da entidade IMPORTADO.
Entidade associativa
Já foi visto que relacionamentos devem ser sempre entre entidades e nunca entre relacionamentos. Entretanto,
surgem situações em que essa necessidade se apresenta como uma condição que deverá ser atendida no
modelo ER.
Exemplo:
Mais um elemento participante da representação de relacionamentos no modelo ER, a
generalização/especialização possibilita definir um subconjunto de instâncias em um objeto a partir da
associação.
Por exemplo, a entidade PRODUTO pode ser segmentada em subconjuntos, representados entidades
NACIONAL e IMPORTADO. Ao realizar essa especialização, características próprias das entidades são
introduzidas, assim como as vindas da entidade-pai serão propagadas para cada uma das novas. A entidade-
pai é conhecida como supertipo e as especializadas como subtipo, ou filha.
A representação gráfica da especialização/generalização é realizada através de um triângulo invertido. No
Diagrama 12, temos um exemplo para melhor entendimento:
Diagrama 12 – Exemplo de modelo ER com generalização/especialização
Fonte: Elaborado pelo autor.
No Diagrama 12, podemos observar que os atributos nas entidades especializadas, NACIONAL e
IMPORTADO, são independentes, porém herdam os atributos e as propriedades da entidade genérica
PRODUTO. Isso significa que todo PRODUTO NACIONAL tem como atributos tipo, des_prod_nac,
cod_produto e nom_produto. Destaca-se que o atributo identificador das entidades especializadas será o da
entidade genérica.
A generalização/especialização pode ter níveis diferentes e não necessariamente apenas um. Nesse mesmo
exemplo, poderíamos adicionar mais um nível, caso as regras de negócio demandassem, adicionando
entidades CERVEJA e VINHO, ambas como especializações da entidade IMPORTADO.
Entidade associativa
Já foi visto que relacionamentos devem ser sempre entre entidades e nunca entre relacionamentos. Entretanto,
surgem situações em que essa necessidade se apresenta como uma condição que deverá ser atendida no
modelo ER.
Exemplo:
Voltando ao nosso modelo com as entidades CLIENTE, PRODUTO e LOJA, dentre as regras deste
negócio, surge a necessidade do mapeamento de DESCONTOS disponibilizados para cada LOJA e
CLIENTE, e verificados no momento na COMPRA. Assim, é necessário verificar quais LOJAS estão
ASSOCIADAS ao DESCONTO e a quais deles o CLIENTE está associado quando a compra foi realizada.
Por exemplo, supondo que o CLIENTE João vai até a LOJA 01 realizar compras, após a seleção dos
produtos, ao chegar ao caixa, sabendo que existe um programa de DESCONTOS, pede para se associar.
Nesse instante dacompra, essa associação deve ser realizada ou consultada para verificar se o cliente
já é associado e se a LOJA participa desse clube para dar o desconto na COMPRA.
Nesse cenário, não podemos apenas criar uma entidade CLUBE para associar ao CLIENTE, pois assim
não saberemos de qual LOJA se refere e tão pouco associar CLUBE à LOJA, pois da mesma forma não
teremos os clientes associados. A solução é então adicionar essa consulta/associação no
relacionamento COMPRA.
Diante desse cenário, surge o elemento da entidade associativa, que possibilitará que um relacionamento
passe a ser tratado como uma entidade que então possa estabelecer um novo relacionamento. A
representação gráfica é feita adicionando-se um retângulo ao relacionamento, transformando-o em entidade
associativa.
No nosso exemplo, o relacionamento COMPRA se tornará uma entidade associativa, permitindo registrar qual
CLIENTE, LOJA, PRODUTO e se este está ASSOCIADO a algum DESCONTO a partir do novo relacionamento
ASSOCIAR. No Diagrama 13, está representado esse cenário para melhor entendimento da entidade
associativa.
Diagrama 13 – Entidade associativa
UNIDADE 1. ARQUITETURA DE DADOS 21
Voltando ao nosso modelo com as entidades CLIENTE, PRODUTO e LOJA, dentre as regras deste
negócio, surge a necessidade do mapeamento de DESCONTOS disponibilizados para cada LOJA e
CLIENTE, e verificados no momento na COMPRA. Assim, é necessário verificar quais LOJAS estão
ASSOCIADAS ao DESCONTO e a quais deles o CLIENTE está associado quando a compra foi realizada.
Por exemplo, supondo que o CLIENTE João vai até a LOJA 01 realizar compras, após a seleção dos
produtos, ao chegar ao caixa, sabendo que existe um programa de DESCONTOS, pede para se associar.
Nesse instante da compra, essa associação deve ser realizada ou consultada para verificar se o cliente
já é associado e se a LOJA participa desse clube para dar o desconto na COMPRA.
Nesse cenário, não podemos apenas criar uma entidade CLUBE para associar ao CLIENTE, pois assim
não saberemos de qual LOJA se refere e tão pouco associar CLUBE à LOJA, pois da mesma forma não
teremos os clientes associados. A solução é então adicionar essa consulta/associação no
relacionamento COMPRA.
Diante desse cenário, surge o elemento da entidade associativa, que possibilitará que um relacionamento
passe a ser tratado como uma entidade que então possa estabelecer um novo relacionamento. A
representação gráfica é feita adicionando-se um retângulo ao relacionamento, transformando-o em entidade
associativa.
No nosso exemplo, o relacionamento COMPRA se tornará uma entidade associativa, permitindo registrar qual
CLIENTE, LOJA, PRODUTO e se este está ASSOCIADO a algum DESCONTO a partir do novo relacionamento
ASSOCIAR. No Diagrama 13, está representado esse cenário para melhor entendimento da entidade
associativa.
Diagrama 13 – Entidade associativa
Fonte: Elaborado pelo autor.
De forma alternativa à entidade associativa, pode-se utilizar dos conceitos tradicionais do modelo ER e
transformar o relacionamento COMPRA em uma entidade, e esta se relacionar com CLIENTE, PRODUTO e
LOJA através de relacionamentos, conforme a Diagrama 14.
Diagrama 14 – Alternativa para entidade associativa
Fonte: Elaborado pelo autor.
1.4 Modelagem de dados com a UML
Até aqui aprendemos bastante sobre a modelagem de dados na abordagem dos modelos ER. Neste tópico,
iremos conhecer como a Linguagem Unificada de Modelagem (tradução de Unified Modeling Language – UML)
apresenta um conjunto de conceitos e desenhos que podem ser uma alternativa útil na modelagem de dados.
Desenvolvida para suporte e apoio no desenvolvimento de soluções que aplicam o paradigma orientado a
objeto, a UML surgiu depois de diversas tentativas de adaptar os artefatos e diagramas existentes da análise
estruturada.
A UML consegue capturar a estrutura de sistemas orientados a objeto em um nível
acima das linhas individuais de código, e pode ser expressa em diagramas que
englobam a gama de construções que aparecem em sistemas típicos orientados a objeto
(PAGE-JONES, 2002, p. 80).
UNIDADE 1. ARQUITETURA DE DADOS 22
Fonte: Elaborado pelo autor.
De forma alternativa à entidade associativa, pode-se utilizar dos conceitos tradicionais do modelo ER e
transformar o relacionamento COMPRA em uma entidade, e esta se relacionar com CLIENTE, PRODUTO e
LOJA através de relacionamentos, conforme a Diagrama 14.
Diagrama 14 – Alternativa para entidade associativa
Fonte: Elaborado pelo autor.
1.4 Modelagem de dados com a UML
Até aqui aprendemos bastante sobre a modelagem de dados na abordagem dos modelos ER. Neste tópico,
iremos conhecer como a Linguagem Unificada de Modelagem (tradução de Unified Modeling Language – UML)
apresenta um conjunto de conceitos e desenhos que podem ser uma alternativa útil na modelagem de dados.
Desenvolvida para suporte e apoio no desenvolvimento de soluções que aplicam o paradigma orientado a
objeto, a UML surgiu depois de diversas tentativas de adaptar os artefatos e diagramas existentes da análise
estruturada.
A UML consegue capturar a estrutura de sistemas orientados a objeto em um nível
acima das linhas individuais de código, e pode ser expressa em diagramas que
englobam a gama de construções que aparecem em sistemas típicos orientados a objeto
(PAGE-JONES, 2002, p. 80).
UNIDADE 1. ARQUITETURA DE DADOS 23
Por essa definição, percebe-se que a UML é uma linguagem destinada a estruturação e o desenvolvimento de
software. Apesar disto, alguns de seus diagramas, em destaque diagrama de classes, podem ser utilizados na
modelagem conceitual dos dados.
O diagrama de classes traz características muito pertinentes e usuais para o mapeamento e modelagem de
dados, auxiliando na construção não só das classes, mas também nos objetos de banco de dados.
Uma classe pode ser considerada como um template para criação de objetos no UML. Um objeto nasce a
partir de uma classe, assumindo seus atributos e executando seus métodos, então podemos associar a classe
a uma entidade do modelo ER, lembrando que a entidade possui um padrão definido com seus atributos, da
mesma forma que a classe.
A representação de uma classe é através de uma caixa, composta pelo nome seguido pelos atributos. O
Diagrama 15 demonstra uma classe:
Diagrama 15 – Representação da classe PESSOA
Fonte: Elaborado pelo autor.
Os relacionamentos de classes são representados por associações dispostas como linhas no diagrama,
podendo ser nomeadas ou não.
Compondo a associação, temos a multiplicidade. A multiplicidade equivale à cardinalidade, sendo anotados o
mínimo e o máximo de participações entre objetos no relacionamento. Vejamos sua notação:
Notação de multiplicidade
» Clique nas setas ou arraste para visualizar o conteúdo
(0..1) - Expressa que pode existir zero ou um relacionamento com outro objeto.  

Por essa definição, percebe-se que a UML é uma linguagem destinada a estruturação e o desenvolvimento de
software. Apesar disto, alguns de seus diagramas, em destaque diagrama de classes, podem ser utilizados na
modelagem conceitual dos dados.
O diagrama de classes traz características muito pertinentes e usuais para o mapeamento e modelagem de
dados, auxiliando na construção não só das classes, mas também nos objetos de banco de dados.
Uma classe pode ser considerada como um template para criação de objetos no UML. Um objeto nasce a
partir de uma classe, assumindo seus atributos e executando seus métodos, então podemos associar a classe
a uma entidade do modelo ER, lembrando que a entidade possui um padrão definido com seus atributos, da
mesma forma que a classe.
A representação de uma classe é através de uma caixa, composta pelo nome seguido pelos atributos. O
Diagrama 15 demonstra uma classe:
Diagrama 15 – Representação da classe PESSOA
Fonte: Elaborado pelo autor.
Os relacionamentos de classes são representados por associações dispostas como linhas no diagrama,
podendo ser nomeadas ou não.
Compondo a associação, temos a multiplicidade. A multiplicidade equivaleà cardinalidade, sendo anotados o
mínimo e o máximo de participações entre objetos no relacionamento. Vejamos sua notação:
Notação de multiplicidade
» Clique nas setas ou arraste para visualizar o conteúdo
(0..1) - Expressa que pode existir zero ou um relacionamento com outro objeto.  

UNIDADE 1. ARQUITETURA DE DADOS 24
(1..1)
 Expressa que um 
relacionamento com 
outro objeto deve 
ser realizado.
(0..1)
Expressa que pode 
existir zero ou um 
relacionamento com 
outro objeto.
(1..*)
Expressa que ao 
menos com um ou 
muitos objetos serão 
estabelecidas
as relações.
(N..M)
O N e M são os 
valores mínimo e 
máximo nos quais o 
relacionamento do 
objeto poderá 
ser estabelecido.
Notação de multiplicidade
Trazendo esses conceitos para modelagem, percebemos que a associação com a multiplicidade representa o
relacionamento dos dados.
No Diagrama 16, é possível visualizar o diagrama de classes com as classes PESSOA e PRODUTO e uma
associação nomeada como ADQUIRIR.
Diagrama 16 – Diagrama de classes
Fonte: Elaborado pelo autor.
Essa representação nos diz que uma pessoa pode adquirir zero ou muitos produtos, e que o produto pode ser
adquirido por zero ou uma pessoa. Nesse caso, tivemos a nomeação do relacionamento, ADQUIRIR, que é
opcional, mas apoia no entendimento.
O exemplo do Diagrama 16 é uma representação de relacionamento com a cardinalidade um-para-muitos.
Utilizando a multiplicidade, outros tipos de relacionamentos equivalentes à cardinalidade vistos no modelo ER
podem ser alcançados.
Ainda dentro dos conceitos de UML aplicáveis à modelagem de dados, temos a generalização, com a
proposta bem similar à generalização/especialização existente na modelagem de entidade-relacionamento.
A generalização define que existirá uma classe mais genérica, que chamaremos de superclasse e outras
classes denominadas como subclasses, que herdam os atributos e métodos da superclasse, além de
possuírem estruturas próprias. Por exemplo, no caso da classe PESSOA, podemos generalizar criando
subclasses PESSOAFISICA e PESSOAJURIDICA, conforme o Diagrama 17.
Diagrama 17 – Representação da generalização
Trazendo esses conceitos para modelagem, percebemos que a associação com a multiplicidade representa o
relacionamento dos dados.
No Diagrama 16, é possível visualizar o diagrama de classes com as classes PESSOA e PRODUTO e uma
associação nomeada como ADQUIRIR.
Diagrama 16 – Diagrama de classes
Fonte: Elaborado pelo autor.
Essa representação nos diz que uma pessoa pode adquirir zero ou muitos produtos, e que o produto pode ser
adquirido por zero ou uma pessoa. Nesse caso, tivemos a nomeação do relacionamento, ADQUIRIR, que é
opcional, mas apoia no entendimento.
O exemplo do Diagrama 16 é uma representação de relacionamento com a cardinalidade um-para-muitos.
Utilizando a multiplicidade, outros tipos de relacionamentos equivalentes à cardinalidade vistos no modelo ER
podem ser alcançados.
Ainda dentro dos conceitos de UML aplicáveis à modelagem de dados, temos a generalização, com a
proposta bem similar à generalização/especialização existente na modelagem de entidade-relacionamento.
A generalização define que existirá uma classe mais genérica, que chamaremos de superclasse e outras
classes denominadas como subclasses, que herdam os atributos e métodos da superclasse, além de
possuírem estruturas próprias. Por exemplo, no caso da classe PESSOA, podemos generalizar criando
subclasses PESSOAFISICA e PESSOAJURIDICA, conforme o Diagrama 17.
Diagrama 17 – Representação da generalização
Fonte: Elaborado pelo autor.
Pelo que vimos aqui sobre o diagrama de classes, foi possível perceber que as classes, associações,
multiplicidade e generalização são estruturas que conseguem representar bem os requisitos e processos
envolvidos no desenho de uma solução, bem como mapear o comportamento dos dados e suas relações.
Síntese
Os dados já não estão mais como coadjuvantes na construção de uma solução; eles assumiram um papel
fundamental visto o resultado que podem entregar. Para o consumo melhor desses, soluções de banco de
dados vêm cada vez mais oferecendo tecnologias para aumentar o desempenho, segurança e disponibilidade
destes ativos.
Para um consumo mais eficiente dessas estruturas, a modelagem relacional e os bancos de dados relacionais
disponibilizam estruturas para extrair o máximo das expectativas do negócio mapeado. Isto tudo por meio do
mapeamento e modelagem, em que são desenhadas as entidades ou tabelas, estruturas que armazenam os
dados caracterizados pelos atributos. As entidades se relacionam entre elas por meio de relacionamentos que
são orientados pela cardinalidade e explicitam as possibilidades de relações refletidas do mundo real.
Alternativamente, a Linguagem Unificada de Modelagem (UML) visa, por meio do diagrama de classes,
representar a estrutura e comportamento real dos processos e dados pela da construção de classes e seus
atributos. Com o uso de associações, podemos demonstrar como se relacionam e como o dado é transitado
entre as classes.
Referências bibliográficas
UNIDADE 1. ARQUITETURA DE DADOS 25
Fonte: Elaborado pelo autor.
Pelo que vimos aqui sobre o diagrama de classes, foi possível perceber que as classes, associações,
multiplicidade e generalização são estruturas que conseguem representar bem os requisitos e processos
envolvidos no desenho de uma solução, bem como mapear o comportamento dos dados e suas relações.
Síntese
Os dados já não estão mais como coadjuvantes na construção de uma solução; eles assumiram um papel
fundamental visto o resultado que podem entregar. Para o consumo melhor desses, soluções de banco de
dados vêm cada vez mais oferecendo tecnologias para aumentar o desempenho, segurança e disponibilidade
destes ativos.
Para um consumo mais eficiente dessas estruturas, a modelagem relacional e os bancos de dados relacionais
disponibilizam estruturas para extrair o máximo das expectativas do negócio mapeado. Isto tudo por meio do
mapeamento e modelagem, em que são desenhadas as entidades ou tabelas, estruturas que armazenam os
dados caracterizados pelos atributos. As entidades se relacionam entre elas por meio de relacionamentos que
são orientados pela cardinalidade e explicitam as possibilidades de relações refletidas do mundo real.
Alternativamente, a Linguagem Unificada de Modelagem (UML) visa, por meio do diagrama de classes,
representar a estrutura e comportamento real dos processos e dados pela da construção de classes e seus
atributos. Com o uso de associações, podemos demonstrar como se relacionam e como o dado é transitado
entre as classes.
Referências bibliográficas
UNIDADE 1. ARQUITETURA DE DADOS 26
CODD, E. F. A relational model of data for large shared data banks. Commun. ACM, New York, NY, USA, v. 13,
n. 6, p. 377–387, jun. 1970. Disponível em: <https://dl.acm.org/doi/10.1145/362384.362685>. Acesso em:
18/07/2020.
ELMASRI, R.; NAVATHE, S; Sistemas de Bancos de Dados. 7. ed. São Paulo: Editora Pearson, 2016.
BURCH, N. Práxis do Cinema. São Paulo: Perspectiva, 1992.
MARQUESONE, R. Big Data - Técnicas e Tecnologias para Extração de Valor dos Dados. São Paulo: Casa
do Código, 2016.
MEDEIROS, L. F. Banco de Dados - Princípios e Prática. 1. ed. Curitiba: IBPEX, 2007.
PAGE-JONES, M. Fundamentos de desenho orientado a objeto com UML. São Paulo: Editora Pearson,
2002.
ROGERS, D. L. Transformação digital: Repensando o seu negócio para a era digital. São Paulo: Autêntica
Business, 2017.
SETZER, V. W.; SILVA, F. S. C. Bancos de Dados. São Paulo: Ed. Edgard Blücher, 2005.
SOMMERVILLE, I. Engenharia de software. 8. ed. Trad.: Selma Shin Shimizu Melnikoff, Reginaldo Arakaki,
Edilson de Andrade Barbosa. São Paulo: Person Addison-Wesley, 2011.
VICCI, C. Banco de Dados. São Paulo: Editora Pearson, 2015.
Fonte: Elaborado pelo autor.
Pelo que vimos aqui sobre o diagrama de classes, foi possível perceber que as classes, associações,
multiplicidade e generalização são estruturas que conseguem representar bem os requisitos e processosenvolvidos no desenho de uma solução, bem como mapear o comportamento dos dados e suas relações.
Síntese
Os dados já não estão mais como coadjuvantes na construção de uma solução; eles assumiram um papel
fundamental visto o resultado que podem entregar. Para o consumo melhor desses, soluções de banco de
dados vêm cada vez mais oferecendo tecnologias para aumentar o desempenho, segurança e disponibilidade
destes ativos.
Para um consumo mais eficiente dessas estruturas, a modelagem relacional e os bancos de dados relacionais
disponibilizam estruturas para extrair o máximo das expectativas do negócio mapeado. Isto tudo por meio do
mapeamento e modelagem, em que são desenhadas as entidades ou tabelas, estruturas que armazenam os
dados caracterizados pelos atributos. As entidades se relacionam entre elas por meio de relacionamentos que
são orientados pela cardinalidade e explicitam as possibilidades de relações refletidas do mundo real.
Alternativamente, a Linguagem Unificada de Modelagem (UML) visa, por meio do diagrama de classes,
representar a estrutura e comportamento real dos processos e dados pela da construção de classes e seus
atributos. Com o uso de associações, podemos demonstrar como se relacionam e como o dado é transitado
entre as classes.
Referências bibliográficas
UNIDADE 1. ARQUITETURA DE DADOS 27