Modelos de Dados e Níveis de Projeto de Banco de Dados

Prévia do material em texto

3ºAula
Modelos de dados
Objetivos de aprendizagem
Ao término desta aula, vocês serão capazes de:
•	 entender os diferentes modelos de dados existentes;
•	 conhecer os diferentes níveis de projeto para o Banco de Dados.
Olá, 
Bem-vindos(as) novamente à matéria Banco de Dados 
I. Prosseguindo os nossos estudos, vamos abordar nesta aula 
os diferentes modelos de dados existentes na Informática, que 
servem como maneiras de organizar os dados. Em seguida, 
veremos os diferentes níveis de projeto de banco de dados.
Lembrem-se de que se tiverem dúvidas, usem os recursos 
disponíveis na sua área do aluno.
Bons estudos!
Banco de Dados I 18
1 – Modelos de Dados
2 – Níveis de Projeto de Banco de Dados
1 - Modelos de Dados
Um modelo de dados é uma definição abstrata dos 
objetos representados por esses dados, dos relacionamentos 
desses objetos entre si e de um conjunto de operadores e 
regras que os usuários finais utilizam para interagir com o BD 
(O’BRIEN, 2004).
Como a definição de como dados estarão dispostos 
não importam aos usuários finais. Utiliza-se, então, o termo 
“Definição Abstrata”.
Esses modelos se subdividem em duas partes: os Modelos 
Lógicos Baseados em Objetos e Baseados em Registros.
1.1 - Modelos Lógicos Baseados em 
Objetos
Os modelos lógicos baseados em objetos são utilizados 
na descrição de dados nos níveis conceituais e de visões. 
Esses tipos de modelos podem se caracterizar pelo fato 
de oferecerem, de modo conveniente, capacidades de 
estruturação flexíveis e aderirem restrições de dados que serão 
explicitamente especificados (MACHADO; ABREU, 2009).
Modelo Entidade-Relacionamento (ER)
O ER tem referência em uma percepção de um mundo 
real que possui uma coleção de objetos básicos conhecidos 
como entidades, e em relacionamentos entre esses objetos.
Nesse sentido, Machado e Abreu (2009) nos ensinam que 
a entidade é um objeto que é distinguível por um conjunto 
específico de atributos. Podemos citar como exemplo os 
atributos “número” e “saldo”, que demonstram uma conta 
particular em um banco.
O relacionamento é uma combinação entre várias 
entidades como, por exemplo, um relacionamento conta com 
cliente, que relaciona um cliente a cada conta que ele tem no 
banco.
Assim, a união de todas as entidades e o conjunto de 
relacionamentos de uma mesma maneira é chamada de 
conjuntos de entidades e de conjuntos de relacionamentos, 
respectivamente.
Na imagem a seguir, vemos um exemplo de Modelo 
Entidade-Relacionamento. Estudaremos sobre eles na aula 04.
Figura 1 – Exemplo de Modelo Entidade-Relacionamento
Fonte: MACHADO; ABREU, 2009
Seções de estudo
Modelo orientado a objetos
Tanto quanto o modelo entidade-relacionamento, o 
modelo orientado a objetos é relacionado a um conjunto de 
objetos. Esse objeto tem valores armazenados em variáveis 
de instância dentro do objeto. Em contrapartida ao modelo 
orientado a registros, os valores são os mesmos objetos.
Dessa forma, os objetos têm objetos para um nível 
arbitrário de encaixamento. Um objeto também contém 
trechos de código que operam sobre o objeto. Tais trechos de 
código são conhecidos como métodos.
No modelo orientado a objetos, o código executável 
é parte integrante do modelo de dados. Uma notação que 
podemos usar para especificar modelos orientados a objetos é 
a UML. Vejam o exemplo a seguir:
Figura 2 – Exemplo de Modelo Orientado a Objetos, 
representado na notação UML
Fonte: MACHADO; ABREU, 2009
1.2 - Modelos lógicos baseados em 
registros
Os modelos lógicos são baseados em registro, e são 
usados nas classificações de dados em níveis conceitual e 
visual. Podem ser comparados com os modelos de dados de 
acordo com os objetos. Ambos são utilizados para especificar 
a estrutura lógica geral do banco de dados e para oferecer uma 
descrição de alto nível da programação.
Modelo Hierárquico
No modelo hierárquico, os dados são demonstrados 
como coleções de registros e ligações entre eles. Essas 
ligações seguem uma hierarquia, criando uma estrutura como 
a de uma árvore.
Nesse sentido, os operadores fornecidos ao usuário são 
ponteiros que possibilitam seu deslocamento na árvore. Esse 
modelo é mais indicado para apresentar estruturas hierárquicas 
como relacionamentos “um para um (1:1)” e “um para muitos 
(1:N)”. No entanto, demonstra alto nível de redundância de 
informações e ineficiência em estruturas com alto grau de 
complexidade.
A figura a seguir mostra um exemplo de modelo 
hierárquico.
Figura 3 – Exemplo de Modelo Hierárquico
Fonte: MACHADO; ABREU, 2009
19
Modelo em Rede
No modelo em rede os dados são demonstrados como 
coleções de registros e ligações entre eles, porém, não há 
uma definida relação hierárquica. No entanto, esse tipo de 
registro pode ter uma variedade em quantidade de superiores 
e dependentes imediatos, assim, apresenta relacionamentos de 
“Muitos para muitos (N:M)”. A abordagem hierárquica, no 
entanto, é mais direta. Mesmo assim, seu esquema de definição 
pode se transformar em algo extremamente complexo. Nesse 
modelo, os operadores oferecidos são ponteiros e possibilitam 
o deslocamento na rede.
Figura 4 – Exemplo de Modelo em Rede
Fonte: MACHADO; ABREU, 2009
Modelo Relacional
No modelo relacional, devemos considerar que o mundo 
real é o único que demonstra, matematicamente, ser completo 
e consistente. Nos demais casos, acontece o contrário: a 
definição é feita para explicar o sistema de banco de dados já 
estabelecido (MACHADO; ABREU, 2009).
Dessa forma, vários dos sistemas não relacionais usam 
artifícios de programação como ponteiros para funcionar. 
No caso do relacional não se usa esses artifícios, porém, é 
funcional no âmbito teórico.
A figura abaixo mostra um exemplo de modelo relacional. 
Veremos mais acerca desse modelo na aula 05.
Figura 5 – Exemplo de Modelo Relacional
Fonte: MACHADO; ABREU, 2009
2 - Níveis de Projeto de Banco de 
Dados
Para que possamos extrair a realidade dos fatos em 
um negócio, devemos observá-lo e fazer com que ele seja 
modelado. Nesse sentido, é necessário, então, registrá-los, para 
que possamos retratar esses fatos em futuras decisões e ações. 
Esse registro é feito por meio da criação de um modelo!
Ademais, é lógico que os fatos acontecem a todo 
o momento dentro de uma empresa e, normalmente, 
ficam registrados em documentos formais, como: fichas, 
memorandos, requerimentos, leis etc. Em geral, na criação e 
utilização de tais documentos não há preocupação quanto à 
utilização, no futuro, de um ambiente automatizado.
O analista, durante a modelagem conceitual 
dos dados, deve se concentrar na observação 
dos fatos relevantes que ocorrem na realidade, 
com	 a	 finalidade	 de	 construir	 um	 sistema	
que possa automatizar as necessidades de 
informação da mesma. Neste momento, 
os documentos que registram estes fatos 
só devem ser utilizados como apoio ao 
entendimento, e não como base para o 
desenvolvimento do sistema de informações, 
ou seja, não devemos ter a preocupação em 
simular o ambiente atual, seja ele manual ou 
automatizado (MACHADO; ABREU, 2009).
Note que o analista deve se preocupar em retratar as 
necessidades de informação que as pessoas (que agem sobre 
essa realidade) devem ter para alcançar os objetivos dessa 
mesma realidade.
Segundo Machado e Abreu (2009), para formalizarmos 
as necessidades de informação de uma realidade, é necessário 
utilizar um modelo, ou seja, algo que nos aponte como as 
informações estão relacionadas (fatos). Assim, com base no 
modelo elaborado, os analistas podem se relacionar com os 
usuários validando seus objetivos e metas, possibilitando 
a elaboração de um sistema de informações cada vez mais 
próximo da realidade do usuário.
Assim, segundo os mesmos autores, um projeto de 
banco de dados se concentra nos seguintes níveis:
Figura 6 – Projeto de um banco de dados
Fonte: MACHADO; ABREU, 2009
Minimundo
O minimundo é uma parte da realidade, reconhecida 
pelo analista, na qual a função gerencial tem grande interesse 
Banco de Dados I 20em observar.
Desse modo, a complexidade de se gerenciar até mesmo 
um minimundo pode fazer com que o analista subdivida-o em 
partes menores, que são as visões.
Projeto Conceitual
Representa e/ou descreve a realidade do ambiente 
do problema, constituindo em uma visão global dos 
principais dados e relacionamentos de um minimundo, 
independentemente de como será programado.
Projeto Lógico
Inicia-se com base em um modelo conceitual, de acordo 
com três abordagens atualmente possíveis: Relacional, 
Hierárquica e Rede.
Nesse sentido, o modelo lógico determina as estruturas 
que estarão no banco de dados, segundo as possibilidades 
possíveis de correspondentes pela abordagem, porém, não 
considerando ainda nenhuma característica específica de um 
SGBD, totalizando um esquema lógico de dados com base na 
ótica de uma das abordagens já mencionadas anteriormente 
(MACHADO; ABREU, 2009).
Projeto Físico
O projeto físico é parte do modelo lógico e demonstra as 
estruturas físicas do armazenamento de dados, como: tabelas, 
tamanho dos campos, índices, tipo de relacionamento, tipo de 
preenchimento desses campos, nomenclaturas projetadas com 
base em requisitos de processamento e uso mais econômico 
dos recursos computacionais.
Banco de Dados x Realidade
Retomando, como vimos no decorrer desta disciplina, 
o BD é visto como uma coleção de dados registrados que 
apresentam o estado de alguns aspectos de interesse do 
mundo real (MACHADO; ABREU, 2009).
Para tanto, o tempo todo o conteúdo do BD demonstra 
uma visão atual do estado do mundo real. Com isso, toda 
modificação em algum item do banco de dados reflete em 
uma mudança que acontece atualmente na realidade.
Retomando a aula
Chegamos	 ao	 final	 da	 nossa	 terceira	 aula.	 Vamos	
recordar?
1 – Modelos de Dados
Um modelo de dados é uma definição abstrata dos 
objetos representados por esses dados, dos relacionamentos 
desses objetos entre si e de um conjunto de operadores e 
regras que os usuários finais utilizam para interagir com o BD. 
Esses modelos se subdividem em duas partes: os Modelos 
Lógicos Baseados em Objetos e Baseados em Registros.
2 – Níveis de Projeto de Banco de Dados
Para que possamos extrair a realidade dos fatos em um 
negócio, devemos observá-los e fazer com que eles sejam 
modelados. Nesse sentido, é necessário registrá-los para que 
possamos retratar esses fatos em futuras decisões e ações. 
Esse registro é feito por meio da criação de um modelo. O 
projeto de banco de dados se divide em Minimundo, Projeto 
Conceitual, Projeto Lógico e Projeto Físico.
CARVALHO, I. C. L.; KANISKI, A. L. A sociedade 
do conhecimento e o acesso à informação: para que e para quem? 
Revista Ciência da Informação, Brasília, v. 29, n. 3, p. 33-39, 
set./dez. 2000.
CASTELLS, M. A sociedade em rede:	a	era	informação	−	
economia, sociedade e cultura. São Paulo: Paz e Terra, 2007.
DAVENPORT, T. H. Ecologia da informação. São Paulo: 
Futura, 2001. 
HEUSER, Carlos Alberto. Projeto de Banco de dados. 
Porto Alegre: Bookman, 2009. ELMASRI, R.; NAVATHE, 
S. B. Sistema de Banco de Dados. Tradução de Marília 
Guimarães Pinheiro et al. São Paulo: Pearson Education, 
2005.
O’BRIEN, J. A. Sistemas de informação e as decisões 
gerenciais na era da Internet. São Paulo: Saraiva, 2004.
TURBAN, E.; WETHERBE, J. C. MCLEAN, 
E. Tecnologia da informação para gestão: transformando os 
negócios na economia digital. 3. ed. São Paulo: Bookman, 
2004.
Vale	a	pena ler
Vale a pena
Minhas anotações