Introdução aos Bancos de Dados

INTRODUO A SISTEMAS DE BANCO DE DADOS
2012
BANCO DE DADOS
Introduo ao estudo de bancos de dados
Este e-book visa elucidar conceitos iniciais para o entendimento dos
Bancos de Dados, desde o aspecto conceitual, passando pela modelagem
de dados e estruturao de um projeto fsico.
Ricardo R. Barcelar
http://www.ricardobarcelar.com.br
ricardobarcelar@email.com.br
APRESENTAO
APRESENTAO
objetivo deste material nortear o estudo de banco de dados em um curso

introdutrio, voltado para acadmicos dos cursos de computao. Os bancos de
dados, nesta fase, so estudados tomando-se por base a importncia dos Sistemas
Gerenciadores de Bancos de Dados (SGBD), os conceitos de Peter Chen acerca da
modelagem de dados e da estruturao de um projeto de banco de dados.
ELMASRI e NAVATE so referncias no estudo de bancos de dados, e aliado a forma

clara e concisa de explicar de HEUSER, este e-book pretende descortinar os conceitos
necessrios para a estruturao de um banco de dados, partindo do princpio que sem um
projeto adequado de banco de dados no h armazenamento de dados eficiente.
Ricardo R. Barcelar
HISTRIA DOS BANCOS DE DADOS
Parte
1
m uma primeira abordagem sobre o assunto, muito importante conhecer como

comeou toda essa histria Bancos de Dados e discutirmos como ser o futuro dessa
ferramenta to importante nas empresas e em nossas vidas. Aqui conheceremos os
primrdios dos bancos de dados, sua evoluo e as perspectivas de futuro.
1.1 DCADA DE 60 PRIMRDIOS

Como muitas tecnologias na computao industrial, os fundamentos de bancos de
dados surgiram na empresa IBM na dcada de 1960 atravs de pesquisas de funes de
automao de escritrio. Foi um perodo da histria na qual as empresas descobriram que
estava muito custoso empregar um nmero grande de pessoas para fazer trabalhos como
armazenar e indexar (organizar) arquivos. Por este motivo, valia a pena os esforos e
investimentos em pesquisar um meio mais barato e ter uma soluo mecnica eficiente.
Nestes primrdios os dados eram armazenados diretamente em arquivos, os quais
implementavam alguns inconvenientes na armazenagem de dados, como:
- redundncias e inconsistncias
- dificuldade de acesso
- falta de integridade lgica
- falta de atomicidade nas transaes
- insegurana
Os computadores se tornam parte efetiva do custo das empresas juntamente com o

crescimento da capacidade de armazenamento. Foram desenvolvidos dois principais modelos
de dados: modelo em rede (CODASYL - Comitee for Data Systems Language) e o modelo
hierrquico (IMS Information Management System). O acesso ao BD feito atravs de
operaes de ponteiros de baixo nvel que unem (link) os registros. Detalhes de
armazenamento dependiam do tipo de informao a ser armazenada, desta forma, a adio de
um campo extra necessitava de uma reescrita dos fundamentos de acesso/modificao do
esquema. Os usurios precisavam conhecer a estrutura fsica do BD para poder realizar uma
consulta.
Um dos primeiros sistemas de banco de dados foi o IMS (Information Management
System) da IBM lanado no final da dcada de 60.
1.2 DCADA DE 70 GNESIS

Na dcada de 1970 o pesquisador da IBM - Edgar Frank Ted Codd - publicou o
primeiro artigo sobre bancos de dados relacionais. Este artigo tratava sobre o uso de clculo e
lgebra relacional para permitir que usurios no tcnicos armazenassem e recuperassem uma
grande quantidade informaes. Codd visionava um sistema onde o usurio seria capaz de
acessar as informaes atravs de comandos, nas qual as informaes estariam armazenadas
em tabelas. Este modelo de dados relacional tornou-se um marco em como pensar em banco
de dados. Ele desconectou a estrutura lgica do banco de dados do mtodo de
armazenamento fsico. Este sistema se tornou padro desde ento.
Devido natureza tcnica deste artigo e a relativa complicao matemtica, o
significado e proposio do artigo no foram prontamente realizados. Entretanto ele levou a
IBM a montar um grupo de pesquisa conhecido como System R (Sistema R), que deu origem a
um sistema de banco de dados relacional com o mesmo nome.
O Sistema R evoluiu para SQL/DS, que posteriormente passou a chamar o DB2, o mais
conhecido sistema gerenciador de banco dos dados da IBM. O Sistema R utilizava uma
linguagem chamada Structured Query Language (SQL) - Linguagem de Consulta Estruturada.
Linguagem esta que se tornou um padro na indstria para bancos de dados relacionais e hoje
em dia um padro ISO (International Organization for Standardization - Organizao
Internacional de Padronizao.
Figura 1 - Dr. Edgar Frank Codd, o pai do modelo relacional.
O Dr. Peter Chen tambm foi ofereceu grande contribuio

contribuio ao propor o modelo
Entidade-Relacionamento
Relacionamento (ER) para projetos de banco de dados dando uma nova e importante
percepo dos conceitos de modelos de dados. Assim como as linguagens de alto nvel, a
modelagem ER possibilita ao projetista concentrar-se
concentrar e apenas na utilizao dos dados, sem se
preocupar com estrutura lgica de tabelas.
Figura 2 - Dr. Peter Chen, criador do modelo ER
Mesmo a IBM sendo a companhia que inventou o conceito original e o padro SQL, eles
no produziram
am o primeiro sistema comercial de banco de dados. O feito foi realizado pela
Honeywell Information Systems Inc.,
Inc., cujo sistema foi lanado em junho de 1976. O sistema era
baseado em muitos princpios do sistema que a IBM concebeu, mas foi modelado e
implementado fora da IBM.
1.3 DCADA DE 80 DESENVOLVIMENTO

Nesta dcada surgiu o primeiro sistema de banco de dados construdo baseado nos
padres SQL com a empresa Oracle atravs do Oracle 2 e depois com a IBM atravs do
SQL/DS, servindo como sistema e repositrio
repositrio de informaes de outras empresas.
Neste perodo tornou-se
tornou se bvio que existiam vrias reas onde bancos de dados
relacionais no eram aplicveis, por causa dos tipos de dados envolvidos. Estas reas incluam
medicina, multimdia e fsica de energia elevada, todas com necessidades de flexibilidade em
como os dados seriam representados e acessados. Este fato levou ao incio de pesquisas em
bancos de dados orientados a objetos, os quais os usurios poderiam definir seus prprios
mtodos de acesso aos dados
dos e como estes seriam representados e acessados. Ao mesmo
tempo, linguagens
guagens de programao orientadas a objetos (Object
(Object Oriented Programming - POO)
tais como C++ comearam a surgir na indstria. Isso permitiu com que usurios criassem
sistemas de banco de
e dados para armazenar resultados de pesquisas como o CERN (maior
laboratrio que trabalha com partculas fsicas em pesquisas nucleares europeu) e SLAC
(Centro de Acelerao Nuclear Norte-Americano),
Americano), para mapeamento de rede de provedores de
telecomunicaes
es e para armazenar registros mdicos de pacientes em hospitais, consultrios
e laboratrios.
Foi neste perodo que os softwares de
e banco de dados relacionais foram sendo
refinados graas ao feedback (retorno) que os usurios destes sistemas faziam, devido ao
desenvolvimento de sistemas para novas indstrias e ao aumento do uso de computadores

pessoais e sistemas distribudos.
Os pioneiros a implementarem orientao a objeto foram:
- O2 [1988]
- Exodus [1986]
- ORION [1986]
Na Metade da dcada, os bancos de dados passaram a combinar caractersticas de
orientao a objeto com o modelo relacional, expandindo a arquitetura com novas
possibilidades, como otimizao de consultas configurveis. Por exemplo:
- POSTGRES [1986]
- STARBURST
No final da dcada h a maturidade da tecnologia, onde os sistemas relacionais
passaram a apresentar um desempenho aceitvel. So exemplos dessa maturidade:
- DB2
- Ingres
- Oracle
- Sybase
- Informix
Alm disso, h a padronizao de uma linguagem para manipulao de bancos de
dados, o SQL ANSI - American National Standards Institute [1986, 1989].
A IBM transforma o DB2 como carro chefe da empresa em produtos para BD. Os
modelos em rede e hierrquico passam a ficar em segundo plano praticamente sem
desenvolvimentos utilizando seus conceitos, porm vrios sistemas legados continuam em uso.
1.4 DCADA DE 90 MATURIDADE

No incio da dcada nota-se a maturidade que os bancos de dados atingiram com o
surgimento dos primeiros Sistemas Gerenciadores de Banco de Dados SGDB Orientados a
Objeto comerciais, SGDB's paralelos, tempo real, etc, alm de avanos na avanos na
padronizao de interfaces e interoperabilidade.
O modelo cliente-servidor (client-server) passa a ser uma regra para futuras decises de
negcio e vemos o desenvolvimento de ferramentas de produtividade como Excel/Access
(Microsoft) e ODBC, tambm marcado como o incio dos prottipos de Object Database
Management Systems (ODBMS).
Na metade da dcada surgem novas classes de aplicao:
- Data Mining;
- Bibliotecas Digitais (Vdeo sob-demanda, Animao);
- Hipermdia e Multimdia em geral;
- GIS (Sistemas de Informaes Geogrficas), Meteorologia, Fsica de Alta Energia

(HEP).
Nos idos da dcada surgem novas abordagens:

- WIIS - Web Information Integration System: sistema para tratar dados oriundos de
vrios websites. Lidam com um grande nmero de websites, possui maior autonomia dos
componentes e dados semi-estruturados.
- Enfoque de Data Warehouse (armazm de dados): dados so extrados das fontes e
armazenados em uma warehouse(Armazm).
- Enfoque de Multi-SGBD: os dados so mantidos nos Web sites, na qual as consultas
so decompostas e enviadas aos vrios websites.
Processos de transao em tempo real (OLTP - On-Line Transaction Process) e
processos analticos em tempo real (OLAP On-Line Analitical Process) atingem maturidade
atravs de muitos negcios utilizando os PDVs (Ponto de Venda)
1.5 ONDE ESTAMOS?

Desde sua chegada, os bancos de dados tem tido aumento nos dados de
armazenamento, desde os 8 MB (Megabytes) at centenas de petabytes de dados em listas de
e-mail, informaes sobre consumidores, sobre produtos, vdeos, informaes geogrficas, etc.
Com este aumento de volume de dados, os sistemas de bancos de dados em operao
tambm sofreram aumento em seu tamanho.
Um dos projetos mais ambiciosos de banco de dados j visto est no CERN (Conselho
Europeu para Pesquisa Nuclear) que consiste em um banco de dados distribudo com a
capacidade de armazenamento na casa dos Hexabytes (1 Hexabyte = 1,000 Petabytes = 1 *
1018 Bytes) de dados.
Atualmente, possvel afirmar que a informao gira em torno dos bancos de dados.
O site Business Intelligence Lowdown publicou uma matria em 2007, onde lista os 10
maiores bancos de dados do mundo e nos mostra o porqu desta afirmao:
a) GOOGLE
Ainda no h muito conhecimento sobre a verdadeira dimenso do banco de dados do
Google, mas basta considerar que a empresa mantm em cache quase todas as pginas da
Internet, tem mais de 51 milhes de usurios no Gmail, armazena imagens do mundo todo
para o Google Earth e para o Google Maps, tem milhes de cadastrados no Orkut, entre
outros. Isso tudo sem contar que o YouTube faz parte de seu leque de servios. No se sabe o
quanto de informaes o Google armazena, mas estima-se que a empresa ultrapassa
tranqilamente a casa dos petabytes (1 petabyte = 1024 terabytes);
Nmeros: 91 milhes de pesquisas por dia representa 50% de todas as buscas Internet
Virtual perfis de inmeros nmero de usurios.
b) AT & T
Semelhante a Sprint, os Estados Unidos mais antiga empresa de telecomunicaes AT
& T mantm um dos maiores bancos de dados. Arquitetonicamente falando, a AT & T a maior
base de dados a nata da cultura, uma vez que ostenta ttulos, incluindo o maior volume de
dados em uma nica base (312 terabytes), o segundo maior nmero de linhas em uma nica
base (1,9 trilho), que inclui a AT & Ts extensa chamada de registros.
Nmeros: 323 terabytes de informao 1,9 trilhes telefonemas em registros.
c) World Data Centre for Climate
Acondicionado em um supercomputador de 35 milhes de euros usado para
investigao extensa sobre o clima, capaz de dar a resposta para o aquecimento global. O
World Data Centre for Climate (WDCC) como o nome indica, o WDCC uma entidade que faz
pesquisas climticas no mundo todo. Essa uma das reas que mais exigem processamento e
capacidade de armazenamento de dados. O WDCC possui 220 terabytes de dados facilmente
acessveis na Internet, bem como seus 110 terabytes (ou 24.500 DVDs) usados para
simulao de dados, e seis PETABYTES de dados internos da empresa.
Nmeros: 6 PETABYTES igual aproximadamente 1.343.296 DVDs.
O que podemos concluir com isso:
- Trivializao do uso da tecnologia de banco de dados?
- Proliferao de produtores e consumidores de dados?
- Aplicaes armazenando da ordem de petabytes ou mais?
1.6 E O FUTURO?
O uso de BD mveis so os novos produtos que vem surgindo para comercializao em
vrios segmentos. Processos de transaes distribudas comeam a se tornar uma regra em
vrias reas de planejamento de negcios.
Fica a indagao para a quantidade de dados existente no mundo. sabido que
necessrio um novo modelo de armazenamento dados sob pena da escassez de meios para
guarda de dados. Sobretudo, v-se o surgimento de novos modelos de armazenamento de
dados que no futuro podem tornar obsoletos os atuais arqutipos de banco de dados.
Seremos alm do mais fica a pergunta se seremos capazes de consultar um Banco de
Dados de registros mdicos/genticos de um futuro empregado de nossa empresa?
SISTEMAS DE GERNCIA DE BANCO DE DADOS
Parte
2
ara entender os Sistemas Gerenciadores de Banco de Dados importante conhecer

alguns conceitos bsicos. A primeira definio relativa aos conceitos de dados e
informao. Dados so fatos em sua forma primria, os quais podem ser armazenados,
como, por exemplo: nome, telefone e endereo. Estes dados ou fatos organizados de
maneira significativa e relacionados formam uma informao, como por exemplo: os
dados das peas em estoque. Assim, possvel obter uma lista de peas em falta.
Sabendo o que so dados e informaes possvel definir os Bancos de Dados como

um conjunto de dados devidamente relacionados capazes de apresentar uma informao.
Os bancos de dados so utilizados em muitas aplicaes, abrangendo praticamente
todo o campo de programas de computador. Os bancos de dados so mecanismos de
armazenamento preferencial para aplicaes multiusurio, nas quais necessrio haver
coordenao entre vrios usurios. Dessa forma, outra definio para banco de dados que
um conjunto de informaes com uma estrutura regular, normalmente, mas no
necessariamente, armazenado em algum formato de mquina legvel para um computador.
H uma grande variedade de bancos de dados, desde simples tabelas armazenadas
em um nico arquivo at um conjunto com milhes de registros armazenados em salas cheias
de discos rgidos gerenciados por uma determinada aplicao.
Os dados armazenados em bancos de dados geralmente so apresentados em forma
semelhante uma planilha eletrnica, porm existem sistemas de gesto responsveis por
gerir o armazenamento, classificao, gesto da integridade e recuperao dos dados.
2.1 CARACTERSTICAS DE UM BANCO DE DADOS

Como vimos, um banco de dados uma coleo lgica coerente de dados com um
significado inerente. Assim, uma disposio desordenada dos dados no pode ser referenciada
como um banco de dados;
Um banco de dados deve ser projetado, construdo e populado com dados para um
propsito especfico;
Deve possuir um conjunto pr-definido de usurios e aplicaes;
Representar algum aspecto do mundo real, o qual chamado de mini-mundo.

Qualquer alterao efetuada no mini-mundo automaticamente refletida no banco de dados.
2.2 MODELOS DE BANCO DE DADOS
2.2.1 Modelo Hierrquico ou de rvore
aquele no qual os dados esto organizados de cima para baixo ou estrutura de rvore
invertida. Por exemplo, os dados sobre um projeto para uma empresa podem seguir este tipo
de modelo. Este mtodo de ligao semelhante relao entre pais e filhos: a criana no
existir sem os pais. o que mais bem se adapta a situaes nas quais as relaes lgicas
entre os dados podem ser representadas com a abordagem (um-para-muitos).
Projet
Departamento
Empregado 1
Empregado 2
Departament
Empregado
Empregad
Figura 3 - Modelo Hierrquico
2.2.2 Modelo em Rede
Um modelo em rede uma extenso do modelo hierrquico. Em vez de se terem

apenas vrios nveis de relaes um-para-muitos, o modelo em rede uma relao membroproprietrio, na qual um membro pode ter muitos proprietrios. Nesse modelo, h
freqentemente mais de um caminho pelo qual um determinado elemento de dado pode ser
acessado.
Projeto 1
Departamento
A
Projeto 2
Departamento
B
Figura 4 - Modelo em Rede
10
2.2.3 Modelo Relacional
Os modelos relacionais se tornaram os mais populares. A finalidade global deste

modelo descrever o dado usando um formato tabular padro (todos os elementos so
localizados em tabelas bidimensionais). As tabelas organizam os dados em linhas e colunas,
simplificando o acesso e a manipulao dos dados.
Uma vez colocados os dados no Banco de Dados Relacional, pode-se fazer perguntas
e manipular dados utilizando as operaes da lgebra relacional. As manipulaes bsicas de
dados incluem a sua seleo, projeo e agrupamento. Outros aspectos deste modelo sero
abordados nos captulos seguintes.
2.3 SISTEMA DE GERENCIADOR DE BANCO DE DADOS (SGBD)

Um banco de dados pode ser criado e mantido por um conjunto de aplicaes
desenvolvidas especialmente para esta tarefa ou por um Sistema Gerenciador de Banco de
Dados. Este um software com recursos especficos para facilitar a manipulao das
informaes dos bancos de dados e o desenvolvimento de programas aplicativos.
Outro conceito interessante sobre SGBD pode ser encontrado no Wikipdia:
...o conjunto de programas de computador
(softwares) responsveis pelo gerenciamento de
uma base de dados.
Os Sistemas Gerenciadores de Bancos de Dados surgiram para atender necessidade

de armazenamento e de recuperao de grandes volumes de informaes, propiciando um
ambiente seguro e adequado.
Seu principal objetivo retirar da aplicao cliente a responsabilidade de gerenciar o
acesso, manipulao e organizao dos dados. Estes sistemas disponibilizam uma interface
para que os seus clientes possam incluir, alterar ou consultar dados.
2.3.1 Funes Bsicas de um Sistema Gerenciador de Banco de Dados

Como todo e qualquer aplicativo os sistemas gerenciadores de bancos de dados dispe
de funes que so compartilhadas por qualquer tipo de sistema gerenciador de banco de
dados, independente de seu fabricante. Dentre elas, destacam-se:
- Proporcionar maior abstrao, isolando o usurio dos pormenores internos de como os
dados esto armazenados;
- Rapidez no acesso s informaes;
- Proporcionar independncia dos dados em relao aos programas de recuperao,
cuja estrutura fsica de armazenamento independe da estratgia de acesso;
- Compartilhar a base de dados entre vrios aplicativos, em que diferentes tipos de
interfaces atendem s necessidades de distintos usurios;
11
- Maior facilidade de realizar cpias de segurana;

- Proporcionar a comunicao diretamente com um software ou servidor;
- Proporcionar integridade dos dados.
2.3.2 Arquitetura de um Sistema Gerenciador de Banco de Dados

Atualmente, existem vrias tendncias para arquitetura de Banco de Dados. A
arquitetura mais conhecida a ANSI/SPARC. Esta arquitetura apresenta-se fundamentada em
trs nveis onde cada um desses nveis corresponde s abstraes dos dados armazenados no
banco de dados.
Os esquemas so definidos como:
a) Nvel externo: ou esquema de viso, o qual descreve o modo pelo qual os dados
so vistos pelos usurios do sistema gerenciador de banco de dados. Cada viso descreve
quais pores do banco de dados um usurio ou grupo de usurios ter acesso.
b) Nvel conceitual: ou esquema conceitual, o qual descreve a estrutura do banco de
dados como um todo, inclusive como os dados se relacionam. uma descrio global do
banco de dados que no fornece detalhes do modo como os dados esto fisicamente
armazenados.
c) Nvel interno ou fsico: ou esquema interno, o qual descreve a estrutura de
armazenamento fsico do banco de dados. Utiliza um modelo de dados e descreve
detalhadamente os dados armazenados e os caminhos de acesso ao banco de dados. a
descrio mais prxima de como os dados sero armazenados.
Figura 5 - Arquitetura de SGBD
12
Partindo da arquitetura proposta importante conhecer alguns conceitos diretamente

relacionados:
a) Abstrao de Dados: Um Sistema Gerenciador de Banco de Dados composto de
uma coleo de arquivos inter-relacionados e de um conjunto de programas que permitem aos
usurios realizarem acesso aos arquivos e modific-los. O grande objetivo de um sistema de
banco de dados prover aos usurios uma viso abstrata dos dados. Isto , o sistema
omite certos detalhes de como os dados so armazenados e mantidos. No entanto, para
que o sistema possa ser utilizado, os dados devem ser buscados de forma eficiente. Este
conceito tem direcionado o projeto de estrutura de dados complexas para a representao de
dados em um banco de dados. Uma vez que muitos dos usurios de banco de dados no so
treinados para computao, a complexidade est escondida desses usurios atravs de
diversos nveis de abstrao que simplificam a interao do usurio com o sistema.
b) Nvel de Vises: O mais alto nvel de abstrao descreve apenas parte do banco de
dados. Apesar do uso de estruturas mais simples do que no nvel conceitual, alguma
complexidade perdura devido ao grande tamanho do banco de dados. Muitos usurios do
sistema de banco de dados no estaro interessados em todas as informaes. Em vez disso
precisam de apenas uma parte do banco de dados. O nvel de abstrao das vises de dados
definido para simplificar esta interao com o sistema, que pode fornecer muitas vises para
o mesmo banco de dados.
Dentro deste conceito, no nvel fsico um registro cliente, conta ou funcionrio pode ser
descrito como um bloco de posies de armazenamento consecutivo (por exemplo, palavras ou
bytes). No nvel conceitual, cada registro destes descrito por uma definio de tipo e pelo
inter-relacionamento entre esses tipos de registros. No nvel de vises, diversas vises do
banco de dados so definidas, por exemplo: os contadores de um banco vem apenas a parte
do banco de dados que possui informaes sobre contas dos clientes. Eles no podem ter
acesso a informaes que se referem a salrio dos funcionrios.
c) Independncia de Dados: Conhecemos trs nveis de abstrao pelos quais o
banco de dados pode ser visto. A habilidade de modificar a definio de um esquema em um
nvel sem afetar a definio de esquema num nvel mais alto chamada de independncia de
dados.
Figura 6 Independncia de dados
13
Existem dois nveis de independncia dos dados:

- Independncia Fsica de Dados: a habilidade de modificar o esquema fsico sem a
necessidade de reescrever os programas aplicativos. As modificaes no nvel fsico so
ocasionalmente necessrias para melhorar o desempenho;
- Independncia Lgica de Dados: a habilidade de modificar o esquema conceitual
sem a necessidade de reescrever os programas aplicativos. As modificaes no nvel
conceitual so necessrias quando a estrutura lgica do banco de dados alterada (por
exemplo, a adio de contas de bolsas de mercado num sistema bancrio).
A independncia lgica dos dados mais difcil de ser alcanada do que a
independncia fsica, porm os programas so bastante dependentes da estrutura lgica dos
dados que eles acessam.
Este conceito de independncia dos dados similar em muitos aspectos ao conceito
de tipos abstratos de dados em modernas linguagens de programao. Ambos escondem
detalhes de implementao do usurio. Isto permite ao usurio concentrar-se na estrutura geral
em vez de detalhes de baixo nvel de implementao.
d) Dicionrio de Dados: Um dicionrio de dados uma coleo de metadados que
contm definies e representaes de elementos de dados. Dentro do contexto de sistemas
gerenciadores de bancos de dados, um dicionrio de dados um grupo de tabelas, habilitadas
apenas para leitura ou consulta, ou seja, uma base de dados, propriamente dita, que entre
outras coisas, mantm as seguintes informaes:
- Definio precisa sobre elementos de dados
- Perfis de usurios, papis e privilgios
- Descrio de objetos
- Integridade de restries
- Stored procedures1 e gatilhos
- Estrutura geral da base de dados
- Informao de verificao
- Alocaes de espao
Um dos benefcios de um dicionrio de dados bem preparado a consistncia entre
itens de dados atravs de diferentes tabelas. Por exemplo, diversas tabelas podem conter
nmeros de telefones. Utilizando uma definio de um dicionrio de dados bem feito, o formato
do campo 'nmero de telefone' definido com "(99)9999-9999" dever ser obedecido em todas
as tabelas que utilizarem esta informao.
1 pequeno trecho de programa de computador, armazenado em um SGBD, que pode ser chamado freqentemente
por um programa principal.
14
Os dicionrios de dados so gerados, normalmente, separados do Modelo de

Dados visto que estes ltimos costumam incluir complexos relacionamentos entre elementos
de dados.
e) Modelo de Dados: Uma das principais caractersticas da abordagem de banco de
dados que fornece alguns nveis de abstrao de dados omitindo ao usurio final detalhes de
como estes dados so armazenados. Um modelo de dados um conjunto de conceitos que
podem ser utilizados para descrever a estrutura lgica e fsica de um banco de dados. Por
estrutura podemos compreender o tipo dos dados, os relacionamentos e as restries que
podem recair sobre os dados.
Figura 7 - Modelo Entidade-Relacionamento
Os modelos de dados podem ser basicamente de dois tipos:

- Alto nvel: ou modelo de dados conceitual, que fornece uma viso mais prxima do
modo como os usurios visualizam os dados realmente;
- Baixo nvel: ou modelo de dados lgico ou fsico, que fornece uma viso mais
detalhada do modo como os dados esto realmente armazenados no computador.
f) Esquemas e Instncias: Em qualquer modelo de dados utilizado, importante
distinguir a descrio do banco de dados do banco de dados por si prprio.
A descrio de
um banco de dados chamada de esquema de um banco de dados e especificada durante
o projeto do banco de dados. Geralmente, poucas mudanas ocorrem no esquema do banco
de dados. Os dados armazenados em um determinado instante do tempo formam um conjunto
chamado de instncia do banco de dados. A instncia altera toda vez que uma alterao no
banco de dados feita.
O Sistema Gerenciador de Banco de Dados responsvel por garantir que toda
instncia do banco de dados satisfaa ao esquema do banco de dados, respeitando sua
estrutura e suas restries. O esquema de um banco de dados tambm pode ser chamado de
intenso de um banco de dados e a instncia de extenso de um banco de dados.
g) As Linguagens para Manipulao de Dados: Para a definio dos esquemas
conceitual e interno pode-se utilizar uma linguagem chamada DDL (Data Definition Language -
15
Linguagem de Definio de Dados). O Sistema Gerenciador de Banco de Dados possui um

compilador DDL que permite a execuo das declaraes para identificar as descries dos
esquemas e para armazen-las no catlogo do Sistema Gerenciador. A DDL utilizada onde a
separao entre os nveis interno e conceitual no muito clara. Onde a separao entre os
nveis conceitual e interno so bem claras, utilizada outra linguagem, a SDL (Storage
Definition Language - Linguagem de Definio de Armazenamento) para a especificao do
esquema interno. A especificao do esquema conceitual fica por conta da DDL.
Em Sistemas Gerenciadores de Bancos de Dados que utilizam a arquitetura de trs
esquemas ou nvel, necessria a utilizao de mais uma linguagem para a definio de
vises, a VDL (Vision Definition Language - Linguagem de Definio de Vises).
Uma vez que o esquema esteja compilado e o banco de dados esteja populado,
utiliza-se uma linguagem para fazer a manipulao dos dados, a DML (Data Manipulation
Language - Linguagem de Manipulao de Dados).
2.3.3 Vantagens do uso de um Sistema Gerenciador de Banco de Dados

A utilizao de Sistemas de Bancos de Dados tornou-se um padro desde quando na
dcada de 60 percebeu-se a inviabilidade de gerenciar um volume muito grande de informao
sem um sistema de computador. A utilizao de Sistemas Gerenciadores de Bancos de Dados
trouxe vrias vantagens, dentre elas:
a) Controle de Redundncia: No processamento tradicional de arquivos, cada grupo de
usurios deve manter seu prprio conjunto de arquivos e dados. Desta forma, acaba ocorrendo
redundncias que prejudicam o sistema com problemas como:
- Toda vez que for necessrio atualizar um arquivo de um grupo, ento todos os grupos
devem ser atualizados para manter a integridade dos dados no ambiente como um todo;
- A redundncia desnecessria de dados leva ao armazenamento excessivo de
informaes, ocupando espao que poderia ser utilizado com outras informaes.
b) Compartilhamento de Dados: Um Sistema Gerenciador de Banco de Dados
multiusurio deve permitir que usurios distintos acessem o banco de dados ao mesmo tempo.
Este fator essencial para que mltiplas aplicaes integradas possam manipular seus dados.
Dessa forma necessrio manter o controle da concorrncia para assegurar que o resultado
de atualizaes sejam corretos. Um banco de dados multiusurios deve fornecer recursos para
a construo de mltiplas vises.
c) Restrio a Acesso no Autorizado: Um Sistema Gerenciador de Banco de Dados
deve fornecer um subsistema de autorizao e segurana, o qual utilizado pelo DBA para
criar contas e especificar as restries destas contas. O controle de restries se aplica tanto
ao acesso aos dados quanto ao uso de softwares inerentes ao Sistema Gerenciador de Banco
de Dados.
d) Representao de Relacionamentos Complexos entre Dados: Um banco de dados
pode incluir uma variedade de dados que esto interrelacionados de vrias formas. O Sistema
Gerenciador de Banco de Dados deve fornecer recursos para se representar uma grande
variedade de relacionamentos entre os dados, bem como recuperar e atualizar os dados de
maneira prtica e eficiente.
16
e) Tolerncia a Falhas: Um Sistema Gerenciador de Banco de Dados deve fornecer

recursos para recuperao de falhas tanto de software quanto de hardware.
Por fim e para melhor compreenso interessante analisar e compreender a estrutura de
um Sistema Gerenciador de Banco de Dados conforme figura 8 e 9.
Esta figura, de forma simplificada, mostra os componentes tpicos de um SGBD. O banco
de dados e o catlogo de dados so normalmente armazenados no disco. O acesso ao disco
controlado principalmente pelo sistema operacional, que organiza as entradas e as sadas. Um
mdulo de gerenciamento dos dados armazenados de alto nvel do SGBD controla o acesso
informao do SGBD que est armazenada no disco, se for parte do banco de dados ou do
catlogo.
Figura 8 Mdulos de um SGBD
A figura 9, logo abaixo apresenta outra viso, desta vez da arquitetura interna de um
SGBD centralizado.
17
Figura 9 - Arquitetura de SGBD
18
MODELAGEM DE DADOS
Parte
3
MODELAGEM DE DADOS
ma das principais caractersticas da abordagem de banco de dados que ela fornece

alguns nveis de abstrao de dados omitindo ao usurio final detalhes de como os
dados so armazenados.
Define-se como modelo de dados um conjunto de conceitos que podem ser utilizados
para descrever a estrutura lgica e fsica de um banco de dados.
3.1 ETAPAS DA MODELAGEM DE DADOS

Trs so as etapas da modelagem de banco de dados:
- Projeto Conceitual
- Projeto Lgico
- Projeto Fsico
Contudo, uma etapa no descrita, mas de suma importncia para qualquer etapa da
modelagem de dados a anlise de requisitos que representa uma etapa onde sero
coletadas as informaes de uma abstrao do mundo real o minimundo.
19
MODELAGEM DE DADOS
Figura 10 - Etapas da modelagem de dados
3.1.1 Projeto Conceitual

a descrio de mais alto nvel da estrutura do BD, no contendo detalhes de
implementao; Nesta etapa no necessrio se preocupar com o tipo de SGBD a ser usado,
ou seja o projeto independente do tipo de SGBD usado;
o ponto de partida do projeto de Banco de Dados e seu objetivo representar a
semntica da informao, independente de consideraes de eficincia.
O objetivo a representao dos requisitos de dados do domnio.
Requisitos: Clareza (facilidade de compreenso) e exatido (formal).
3.1.2 Projeto Lgico

No modelo lgico existe a descrio da estrutura do BD que pode ser processada pelo
SGBD. Em poucas palavras o modelo conceitual mapeado para um modelo lgico de dados;
Nesta etapa h a dependncia da classe de modelos de dados utilizada pelo SGBD, mas no
do SGBD.
A nfase do modelo lgico est na eficincia de armazenamento, ou seja, em evitar
muitas tabelas (e junes); tabelas subutilizadas, etc.
Futuras alteraes no modelo lgico devem ser primeiro efetuadas no Modelo
Conceitual.
3.1.3. Projeto Fsico

Nesta etapa ocorre o mapeamento do modelo lgico em um esquema fsico de acordo
com o SGBD especfico, ou seja, o modelo criado est diretamente ligado ao SGBD escolhido.
No modelo fsico contm a descrio da implementao da base de dados na qual descreve as
estruturas de armazenamento e os mtodos de acesso. Caracteriza-se pela criao do
20
MODELAGEM DE DADOS
esquema SQL da modelagem lgica. Sua nfase na eficincia de acesso como na

implementao de consultas, ndices, etc.
Exemplos: alocao dinmica de espaos, clusterizao, particionamento fsico das tabelas,
etc.
3.2 ABORDAGEM ENTIDADE-RELACIONAMENTO (ER)

A abordagem entidade-relacionamento um padro para a modelagem conceitual. Foi
criada em 1976 por Peter Chen que junto com alguns conceitos apresenta uma notao
grfica para diagramas que tem por caractersticas:
- Ser um modelo simples, com poucos conceitos;
- Representao grfica de fcil compreenso.
Um esquema conceitual de dados tambm chamado de esquema ER, diagrama ER,
ou modelo ER.
um modelo conceitual que representa os elementos do domnio do problema e,
consequentemente, no considera questes tecnolgicas. Assim, alguns dos elementos
descritos neste modelo no possuem correspondncia com os recursos oferecidos pelos
bancos de dados relacionais, tornando necessrio transformar o Modelo EntidadeRelacionamento em uma notao que possa ser implementada neste tipo de banco de dados.
3.2.1 Abordagem Relacional

A abordagem relacional a utilizao de conceitos de entidade e relacionamento para
criar as estruturas que iro compor o BD. Partindo da necessidade do usurio ou grupo de
usurios do sistema, iniciamos a pesquisa das necessidades de informao desses usurios, o
que chamamos de levantamento de requisitos. A definio do escopo do sistema
importante para o incio do trabalho de anlise de dados.
comum no incio do desenvolvimento de um sistema no termos a noo exata da
tarefa a ser realizada. O maior erro nesta fase admitir que j sabemos o que deve ser
feito.
Para minimizar esse problema, devemos criar uma estrutura grfica que permita
identificar as entidades de um sistema e como estas se relacionam.
O modelo de dados dar suporte a empresa, incorporando as informaes necessrias
para o andamento dos negcios. Ele ser composto, basicamente, de Entidades e
Relacionamentos da ser conhecido como Modelo Entidade-Relacionamento (MER).
3.2.2 Vantagens na utilizao do MER

Sintaxe Robusta: o modelo documenta as necessidades de informao da empresa de
maneira precisa e clara.
21
MODELAGEM DE DADOS
Comunicao com o usurio: os usurios podem, com pouco esforo, entender o

modelo.
Facilidade de criao: pode-se
pode se criar e manter o modelo com facilidade.
Integrao com vrias aplicaes: diversos projetos podem ser inter-relacionados.
inter
Utilizao
ao universal: o modelo no est vinculado a um BD, garantindo independncia
de implementao.
3.2.3 Objetivo da Modelagem de dados

Desenvolver um modelo que, contendo entidades e relacionamentos, seja capaz de
representar os requerimentos das informaes
informaes do negcio, evitando redundncias,
inconsistncias e economia de espao.
Figura 11 - Representao de dados
3.2.4 Objetos Conceituais

A Abordagem Entidade-Relacionamento
Entidade Relacionamento (ER) a tcnica mais utilizada e difundida que
existe.
O modelo de dados representado atravs de um modelo entidade-relacionamento
entidade
(MER), que graficamente chamado de Diagrama entidade-relacionamento
entidade relacionamento (DER). Chen
destaca a importncia de reconhecer objetos do negcio e os classificou em dois grupos:
Entidades
s e Relacionamentos.
Relacionamentos
22
MODELAGEM DE DADOS
Figura 12 Entidade/Relacionamento
3.2.4.1 Entidades
Entidades so objetoss que existem no mundo real com uma identificao distinta e com
um significado prprio. Tambm so descritas como objetos da realidade
ade na qual se deseja
manter informaes no banco de dados. Normalmente representado por um substantivo na
descrio do negcio.
Figura 13 - Exemplos de entidades
Em outras palavras so as coisas que existem no negcio.

importante
ortante ressaltar que uma entidade no caracterizada somente por objetos
fsicos, podendo existir objetos abstratos neste conceito. Observe esta pequena estria:
O Sr. Joaquim sente fortes dores no peito e procura um consultrio mdico para se
consultar. Chegando ao consultrio ele se apresenta e a secretria faz um pequeno cadastro
com seus dados e sem seguida o encaminha para ser atendido por um mdico. Depois de
realizada a consulta, o mdico receita-lhe
receita
alguns medicamentos.
Pergunta: Qual objeto abstrato
ato possvel
possvel armazenar alguma informao?
23
MODELAGEM DE DADOS
Figura 14 - Entidades
Analisando o minimundo descrito acima possvel identificar objetos abstratos e

concretos: Mdico e paciente so caracterizados como objetos
o
concreto mais fceis de
concretos,
serem identificados. Um
m fato que se deseja registrar que possua caractersticas prprias como
a consulta mdica so caracterizados como objetos abstratos.
NOTAO:
iagrama Entidade-Relacionamento
Entidade
uma entidade representada atravs de
Em um Diagrama
retngulo contendo o nome da entidade, como no exemplo abaixo:
Figura 15 - Notao de entidade
3.2.4.2 Atributos
So informaes que qualificam uma entidade e descrevem seus elementos ou
caractersticas. Quanto transpostos para o modelo
modelo fsico so chamados de colunas ou campos.
Um atributo uma caracterstica, logo no contm um grupo de informaes.
importante utilizar sempre uma viso espacial de dados, a fim de enxergar o todo e
no uma nica ocorrncia. Existem diversos tipos de
de atributo, dentre eles:
- Atributos simples
- Compostos
- Multivalorados
- Especiais
24
MODELAGEM DE DADOS
Os atributos compostos podem ser divididos em subpartes menores que representam

outros atributos bsicos com significados diferentes. Por exemplo, o atributo Endereo, que
pode ser subdividido em nmero, logradouro, cidade, estado e CEP. Os atributos que no so
divisveis so chamados atributos simples.
simples
A maioria dos atributos possui um nico valor. Em alguns casos, um atributo pode ter
um conjunto de valores para a mesma
mesma entidade, como por exemplo, o atributo cores ou o
atributo formao. Esses atributos so chamados de multivalorados.
Figura 16 - Atributo
Normalmente existem atributos que tem funes especiais em uma entidade. Dessas
algumas
mas servem como identificadores, a saber:
- Chave primria: o atributo ou grupamento de atributos cujo valor identifica
unicamente uma entidade dentre todas as outras. Deve ter contedo reduzido e valor constante
no tempo. Pode ser natural ou artificial.
- Chave candidata: o atributo ou grupamento de atributos que tem a propriedade de
identificao nica. Pode vir a ser a chave primria.
- Chave estrangeira: quando um atributo de uma entidade a chave primria de
outra entidade com a qual ela se relaciona.
rela
- Chave composta: formada pelo grupamento de mais de um atributo.
NOTAO:
Figura 17 - Notao de atributo
25
MODELAGEM DE DADOS
Ainda em relao ao atributo,

atributo este pode ser classificado como multivalorado quando,
este tipo possui mais de um
m valor para cada atributo a partir dele prprio.
prprio Um tipo de atributo
multivalorado pode ser organizado na prtica como uma lista, conjunto
onjunto ou coleo de
elementos.
3.2.4.3 Tuplas
Os atributos e seu valores descrevem as instncias de uma entidade, formando o que
chamamos
hamamos de tuplas ou registros.
Figura 18 - Tuplas
No devemos considerar como entidade um objeto, se no conseguirmos ter a viso de

seu contedo em instncias
ncias com valores de atributos Tuplas.
3.2.4.4 Relacionamentos
o fato ou acontecimento que liga dois objetos existentes no mundo real, ou seja, o
fato que efetua a juno de duas ou mais tabelas.
NOTAO:
Figura 19 - Notao de relacionamento
Vrias so as possibilidades
possibilidade de relacionamentos,
s, como sero vistos a frente.
frente Um
relacionamento caracterizado por um verbo, como: Pessoas moram em Apartamentos.
26
MODELAGEM DE DADOS
Figura 20 - Exemplo de relacionamento
3.2.4.5 Classificao dos Relacionamentos

a) Quanto a Cardinalidade ou grau dos relacionamentos:
- 1:1 (Um para um)
- 1:N (Um para muitos)
- N:N (muitos para muitos)
- Relacionamento um-para-um:
um
cada elemento de uma entidade relaciona-se
relaciona
com um
e somente um elemento de outra entidade.
Figura 21 - Relacionamento 1:1
- Relacionamento um-para-muitos:
um
cada elemento de uma entidade relaciona-se
relaciona
com
muitos elementos de outra entidade. o mais comum no mundo real.
Figura 22 - Relacionamento 1:N
- Relacionamento muitos-para-muitos:
muitos
caracteriza-se
se pelo relacionamento possuir
dados que so inerentes ao fato e no s entidades.
27
MODELAGEM DE DADOS
Figura 23 - Relacionamento N:N
Em suma, na figura 18 esto representados os tipos de relacionamentos com sua

representao baseada na teoria dos conjuntos.
Figura 24 - Relacionamentos quanto a cardinalidade
Todos os relacionamentos vistos at agora se referem a relacionamentos binrios,

binrios ou
seja, representam
m relacionamentos entre duas entidades, conforme
conforme figura 19.
28
MODELAGEM DE DADOS
Figura 25 - Relacionamento binrio
A cardinalidade pode tambm ser representada de acordo com a cardinalidade mxima

ou mnima conforme figuras 20 e 21.
21
Figura 26 - Cardinalidade Mxima
Figura 27 - Cardinalidade Mnima
b) Quanto a natureza
Indica se as ocorrncias de uma entidade participam de forma Opcional ou
Compulsria.
29
MODELAGEM DE DADOS
- Compulsria
- Opcional
NOTAO:
Figura 28 - Notao de relacionamento quanto a natureza
Figura 29 - Exemplo de classificao quanto a natureza
3.4.4.6. Auto-Relacionamento
Relacionamento
Cada
ada elemento de uma entidade relaciona-se
relaciona se com um ou mais elementos da mesma
entidade, ou seja, demonstra o relacionamento de ocorrncias de uma entidade com outras
ocorrncias da mesma entidade. So definidos papeis de cada lado do relacionamento.
Exemplos: Pea, Pessoa, Funcionrio, etc.
Figura 30 - Auto-relacionamento
3.4.4.7. Relacionamento Ternrio

Embora a maioria dos relacionamentos ocorra entre duas entidades (relacionamentos
binrios) podem ser definidos relacionamentos entre qualquer nmero de entidades.
30
MODELAGEM DE DADOS
Figura 31 - Relacionamento ternrio
Os Relacionamentos
cionamentos ternrios devem ser utilizados com muito cuidado,
cuidado pois muitas
vezes induzem a criao de bancos de dados no normalizados.. Como regra geral deve-se
deve
criar um relacionamento ternrio apenas quando no for possvel representar a regra de
negcio desejada
esejada em um ou mais relacionamentos binrios.
3.2.4.8. Entidade Forte e Entidade Fraca

possvel que um conjunto de entidades no tenha atributos suficientes para formar
uma chave primria. Tal conjunto de entidades nomeado como conjunto de entidades
fracas.. Um conjunto de entidades que possui uma chave primria definido como conjunto de
entidades fortes.
Considere o exemplo abaixo:
a
Figura 32 - Entidade Fraca
Neste exemplo fica cllara a situao de modelagem chamada entidade fraca, onde a
chave primria da entidade fraca (neste caso, a entidade Exemplar) formada pela chave
primria da entidade forte (no caso, a entidade Obra), mais algum atributo que diferencie seus
registros (como o nmero do exemplar).
Nota-se assim que a entidade fraca estar sempre carregando o relacionamento com
sua entidade forte, sugerindo sempre uma leitura como um exemplar de uma determinada
obra, neste caso.
31
MODELAGEM DE DADOS
Os conceitos de conjuntos
conj
de entidades fortes e fracas esto relacionados s
dependncias de existncia introduzidas anteriormente. Um membro
membro de um conjunto de
entidade forte por definio uma entidade dominante, enquanto um membro
me
de um conjunto
de entidade fraca uma entidade
dade subordinada.
Embora
a um conjunto de entidades fracas no tenha uma chave primria, necessria
uma forma de distino entre todas essas entidades no conjunto de entidades que dependa de
uma entidade forte particular. O discriminador (ou chave parcial)
parc
de um conjunto de entidade
fraca um conjunto de atributos que permite que esta distino seja feita,
feita por exemplo, o
discriminadorr do conjunto de entidades fracas transao o atributo nmero-transao,
nmero
uma
vez que para cada conta um nmero de transao univocamente identifica uma nica
transao.
A chave primria de
e um conjunto de entidades fracas formada pela chave primria do
conjunto de entidades fortes
forte do qual ele dependente de existncia (ou dependncia
existencial), mais seu discriminador. No caso do conjunto de entidades transao, sua chave
primria {nmero-conta,
conta, nmero-transao},
nmero
}, onde nmero conta identifica a entidade
dominante de uma transao e nmero-transao
nmero transao distinguem entidades de transao dentro da
mesma conta.
As entidades fracas
as so representadas por um retngulo duplicado. O conjunto de
relaes que identificam as entidades
e
fracas so representadass por losngulos duplicados. Os
atributos que constituem a chave parcial (ou discriminadores) so sublinhados de forma
tracejada.
NOTAO:
Figura 33 - Entidade Fraca
3.4.4.8. Especializao/Generalizao
A generalizao trata-se
trata
de uma abstrao na qual um conjunto de entidades
semelhantes, possivelmente
ssivelmente com alguns atributos comuns e outros diferentes e com a mesma
chave primria, vistos como uma nica entidade.
A especializao possui o mesmo conceito. A diferena est na origem das entidades.
NOTAO:
Figura 34 - Notao de Especializao /Generalizao
32
MODELAGEM DE DADOS
Figura 35 - Exemplo de Especializao/Generalizao
Nas figuras a seguir podemos identificar com mais facilidade a diferena entre
especializao e generalizao. Assim, na figura 28 observa-se
obs
se que a anlise da
representao parte do geral para o especfico. Neste caso, secretria, engenheiro e motorista
possuem especificaes prprias, contudo todos eles so funcionrio. Simplesmente foram
especializados como funcionrios.
Figura 36 Generalizao
Na figura 29, observa-se

observa se a anlise inversa da representao acima. Partimos do
especfico para o geral. Neste caso, os funcionrios foram especializados em secretria,
engenheiro e motorista, no perdendo suas caractersticas
caractersticas de funcionrio, simplesmente
recebendo as caractersticas peculiares de cada forma especializada
33
MODELAGEM DE DADOS
Figura 37 - Especializao
- Quando utilizar uma especializao/generalizao?

Se as ocorrncias de uma entidade tiverem
tiverem relacionamentos ou atributos adicionais em
relao s demais. O exemplo bem claro com relao a isso: Engenheiro e Motorista podem
apresentar atributos distintos como CREA e CNH, respectivamente. No entanto, ambos no
deixaram de ser funcionrios, somente
somente possuem caractersticas que o outro no possui.
Uma vez descrita as estruturas bsicas de um modelo entidade-relacionamento
entidade relacionamento (MER)
possvel compreender com facilidade um diagrama entidade-relacionamento
entidade relacionamento (DER).
Figura 38 - Diagrama Entidade-Relacionamento
34
REGRAS DO MODELO CONCEITUAL
Parte
4
s regras do modelo conceitual visam contextualizar a utilizao de recursos da

Modelagem Entidade-Relacionamento ora utilizada no Modelo Conceitual. Em funo
do contexto importante aplicar cada tipo de estrutura de acordo com a regra de
negcio para no incorrer em inconsistncias quando da utilizao de uma instncia do
banco de dados.
4.1 MODELO CONCEITUAL COMO MODELO DE ORGANIZAO

O modelo conceitual surgiu das idias fundamentais do projeto de banco de dados: a de
que atravs da identificao das entidades que tero informaes representadas no banco de
dados possvel identificar os arquivos que comporo o banco de dados.
Na prtica, convencionou-se iniciar o processo de construo de um novo banco de
dados com a construo de um modelo dos objetos da organizao que ser atendida pelo
banco de dados, ao invs de partir diretamente para o projeto do banco de dados.
Esta forma de proceder permite envolver o usurio na especificao do banco de
dados. Sabe-se da prtica da engenharia de software que o envolvimento do usurio na
especificao do software aumenta a qualidade do software produzido. A idia que o usurio
aquele que melhor conhece a organizao e, portanto, aquele que melhor conhece os
requisitos que o software deve preencher.
Modelos conceituais so modelos que descrevem a organizao e, portanto, so mais

simples de compreender por usurios leigos em Informtica que modelos que envolvem
detalhes de implementao.
4.2 DIFERENTES MODELOS PODEM SER EQUIVALENTES

Na prtica, muitas vezes observam-se analistas em acirradas discusses a fim de
decidir como um determinado objeto da realidade modelada deve aparecer no modelo. s
vezes, tais discusses so absolutamente suprfluas, pois os diferentes Modelos Entidade-
35
Relacionamento em qualquer das opes defendidas pelos diferentes analistas geram o

mesmo banco de dados. H um conceito de equivalncia entre Modelos EntidadeRelacionamento. De maneira informal, dois modelos so equivalentes quando expressam o
mesmo problema, ou seja, quando modelam a mesma realidade.
Para definir o conceito de equivalncia de forma mais precisa, necessrio considerar
o Banco de Dados que projetado a partir do Modelo Entidade-Relacionamento. Para fins de
projeto de Banco de Dados, dois Modelos Entidade-Relacionamento so equivalentes, quando
ambos geram o mesmo esquema de Banco de Dados. Assim, para analisar se dois modelos
so equivalentes, necessrio considerar um conjunto de regras de traduo de Modelos
Entidade-Relacionamento para modelos lgicos de banco de dados. Quando falamos o
mesmo modelo de Banco de Dados Relacional estamos falando de bancos de dados que,
abstraindo de diferenas de nomes de estruturas (tabelas, atributos, ) tenham a mesma
estrutura. Um caso o da equivalncia entre um modelo que representa um conceito atravs
de um relacionamento n:n e outro modelo que representa o mesmo conceito atravs de uma
entidade. Um exemplo o relacionamento CONSULTA que foi transformado em uma entidade.
Os dois modelos so equivalentes, pois expressam o mesmo e geram o mesmo banco de
dados.
a) A consulta como relacionamento n:n
Figura 39 - Relacionamento n:n
b) A consulta como entidade
Figura 40 - Relacionamento 1:n
36
4.3 ATRIBUTO VERSUS ENTIDADE RELACIONADA

Uma questo que s vezes surge na modelagem de um sistema entre modelar um
objeto como sendo um atributo de uma entidade ou como sendo uma entidade autnoma
relacionada a essa entidade.
Exemplificando, no caso de uma indstria de automvel, como devemos registrar a cor
de cada automvel que sai da linha de produo? Caso considerarmos que cada automvel
possui uma nica cor predominante, pode-se pensar em modelar a cor como um atributo da
entidade AUTOMVEL ou modelar a cor como uma entidade autnoma, que est relacionada
entidade AUTOMVEL.
Figura 41 - Atributo X Entidade Relacionada
Alguns critrios para esta deciso so:

- Caso o objeto cuja modelagem est em discusso esteja vinculado a outros objetos
(atributos, relacionamentos, entidades genricas ou especializadas), o objeto deve ser
modelado como entidade, j que um atributo no pode ter atributos, nem estar relacionado a
outras entidades, nem ser generalizado ou especializado. Caso contrrio, o objeto pode ser
modelado como atributo. Assim, no caso do exemplo das cores dos automveis, poder-se-ia
optar por modelar a cor como uma entidade, caso se tivesse que registrar no banco de dados
os possveis fabricantes da tinta da referida cor (entidades relacionadas cor), ou caso se
quisesse registrar as datas de incio e fim (atributos) do uso de uma determinada cor. Caso no
houvesse nenhum objeto relacionado cor do automvel, poder-se-ia model-la como atributo
da entidade automvel.
- Quando o conjunto de valores de um determinado objeto fixo durante toda a vida do
sistema ele pode ser modelado como atributo, visto que o domnio de valores de um atributo
imutvel. Quando existem transaes no sistema que alteram o conjunto de valores do objeto,
o mesmo no deve ser modelado como atributo. Assim, retomando o exemplo das cores dos
automveis, caso existissem transaes de criao/eliminao de cores, seria prefervel a
modelagem de cor como entidade relacionada entidade automvel.
4.4 ATRIBUTO VERSUS GENERALIZAO/ESPECIALIZAO

Outro conflito de modelagem para o qual h algumas regras de cunho prtico entre
modelar um determinado objeto (por exemplo, a categoria funcional de cada empregado de
37
uma empresa) como atributo (categoria funcional como atributo da entidade EMPREGADO) ou
atravs de uma especializao (cada categoria funcional corresponde a uma especializao de
entidade empregado).
Uma especializao deve ser usada quando se sabe que as classes especializadas de
entidades possuem propriedades (atributos, relacionamentos, generalizaes, especializaes)
particulares. Assim, no caso do exemplo acima, faz sentido especializar a entidade empregado
de acordo com a categoria funcional, no caso de as classes particulares possurem atributos ou
relacionamentos prprios.
Ainda no exemplo dos empregados, o sexo do empregado mais bem modelado como
atributo de empregado, caso no existam propriedades particulares de homens e mulheres a
modelar na realidade considerada.
a) Modelando categoria funcional como atributo:
Figura 42 - Modelagem com o atributo
b) Modelando categoria funcional como especializao:
Figura 43 - Modelagem como Generalizao/ Especializao
38
4.5 VERIFICAO DO MODELO

Uma vez confeccionado, um modelo ER deve ser validado e verificado. A verificao o
controle de qualidade que procura garantir que o modelo usado para a construo do banco de
dados gerar um bom produto. Um modelo, para ser considerado bom, deve preencher uma
srie de requisitos, como ser completo, ser correto e no conter redundncias.
4.5.1 O Modelo deve ser Correto

Um modelo est correto quando no contm erros de modelagem, isto , quando os
conceitos de Modelagem Entidade-Relacionamento so corretamente empregados para
modelar a realidade em questo. Podem-se distinguir entre dois tipos de erros:
- Erros sintticos
- Erros semnticos
Os erros sintticos ocorrem quando o modelo no respeita as regras de construo de
um Modelo Entidade-Relacionamento. Por exemplo: associar atributos a atributos; associar
relacionamentos a atributos; associar relacionamentos atravs de outros relacionamentos ou
de especializar relacionamentos ou atributos.
Os erros semnticos ocorrem quando o modelo, apesar de obedecer s regras de
construo de Modelos Entidade-Relacionamento (estar sintaticamente correto) reflete a
realidade de forma inconsistente. Por exemplo: Estabelecer associaes incorretas, como
associar a uma entidade um atributo que na realidade pertence outra entidade. Isso acontece
quando em um modelo com entidades CLIENTE e FILIAL, associa-se a CLIENTE o nome da
FILIAL.
4.5.2 O Modelo deve ser Completo

Um modelo completo deve fixar todas as propriedades desejveis do banco de dados.
Isso obviamente somente pode ser verificado por algum que conhece profundamente o
sistema a ser implementado. Uma boa forma de verificar se o modelo completo verificar se
todos os dados que devem ser obtidos do banco de dados esto presentes e se todas as
transaes de modificao do banco de dados podem ser executadas sobre o modelo.
Este requisito aparentemente conflitante com a falta de poder de expresso de
Modelos Entidade-Relacionamento. Quando dizemos que um modelo deve ser completo,
estamos exigindo que todas as propriedades expressveis no modelo conceitual apaream no
modelo.
4.5.3 Modelo Deve ser Livre de Redundncias

Um modelo deve ser mnimo, isto no deve conter conceitos redundantes. Um tipo de
redundncia que pode aparecer a de relacionamentos redundantes. Relacionamentos
39
redundantes so relacionamentos que so resultado da combinao de outros relacionamentos

entre as mesmas entidades.
Figura 44 - Modelo Redundante
4.5.4 Modelo Deve Refletir o Aspecto Temporal

Usualmente, ao iniciar a modelagem Entidade-Relacionamento, a preocupao obter
um modelo que descreva os estados vlidos e corretos do banco de dados. O primeiro modelo
tende a refletir um estado momentneo do banco de dados. Entretanto, necessrio lembrar
que assim como informaes so includas no banco de dados, elas tambm podem ter que
ser eliminadas do banco de dados.
Um banco de dados no pode crescer indefinidamente. Informaes ultrapassadas ou
desnecessrias podem ser eliminadas. Portanto, necessrio considerar o aspecto temporal
na modelagem de dados. No h regras gerais como proceder neste caso, mas possvel
identificar alguns padres que se repetem freqentemente na prtica.
a) Manter ou no um histrico de salrios?
Figura 45 - Manuteno de histrico de salrio
40
b) Manter ou no o histrico de alocao de mesas?
Figura 46 - Manuteno de histrico de empregado-mesa
c) Manter ou no o histrico de lotao do empregado?
Figura 47 - Manuteno de histrico de empregado-departamento
d) Manter somente a inscrio atual ou o histrico de todas as inscries nos cursos?
Figura 48 - Manuteno de histrico de participante
41
ABORDAGEM RELACIONAL
Parte
5
abordagem relacional muito prxima do modelo lgico, uma descrio de um banco

de dados no nvel de abstrao visto pelo usurio do Sistema Gerenciador de Banco de
Dados - SGBD. Assim, o modelo lgico dependente do tipo particular de SGBD que
est sendo usado.
Observe o modelo conceitual abaixo:
Figura 49 - Modelo Conceitual
A prxima figura mostra um exemplo de Banco de Dados relacional projetado a partir do

modelo conceitual mostrado na figura acima.
Figura 50 - Modelo Lgico
42
Assim sendo, podemos concluir que um modelo lgico para o Banco de Dados acima
deve definir quais as tabelas que o banco contm e, para cada tabela, quais os nomes das
colunas.
Essa estrutura tambm pode ser representada da seguinte forma:
TipoDeProduto(CodTipoProd,DescrTipoProd)
Produto(CodProd,DescrProd,PrecoProd,CodTipoProd)
CodTipoProd referencia TipoDeProduto
5.1 COMPOSIO DE UM MODELO CONCEITUAL

Um banco de dados relacional composto de tabelas ou relaes.
5.1.1 Tabela
Uma tabela um conjunto no ordenado de linhas (tuplas, na terminologia acadmica).
Cada linha composta por uma srie de campos (valor de atributo, na terminologia
acadmica). Cada campo identificado por nome de campo (nome de atributo, na terminologia
acadmica). O conjunto de campos das linhas de uma tabela que possuem o mesmo nome
formam uma coluna.
Figura 51 - Tabela
5.1.2 Chaves
O conceito bsico para estabelecer relaes entre linhas de tabelas de um banco de
dados relacional o da chave. Em um banco de dados relacional, h ao menos dois tipos de
chaves a considerar: a chave primria e a chave estrangeira.
a) Chave Primria: uma coluna ou uma combinao de colunas cujos valores
distinguem uma linha das demais dentro de uma tabela.
43
Figura 52 - Chave Primria
b) Chave Estrangeira: uma coluna ou uma combinao de colunas, cujos valores

aparecem necessariamente na chave primria de uma tabela. A chave estrangeira o
mecanismo que permite a implementao de relacionamentos em um banco de dados
relacional.
Figura 53 - Chave Estrangeira
A existncia de uma chave estrangeira impe restries que devem ser garantidas em
diversas situaes de alterao do banco de dados:
- Quando da incluso de uma linha na tabela que contm a chave estrangeira, deve ser
garantido que o valor da chave estrangeira aparea na coluna da chave primria referenciada.
No exemplo acima, isso significa que um novo empregado deve atuar em um departamento j
existente no banco de dados.
- Quando da alterao do valor da chave estrangeira deve ser garantido que o novo
valor de uma chave estrangeira aparea na coluna da chave primria referenciada.
- Quando da excluso de uma linha da tabela que contm a chave primria referenciada
pela chave estrangeira deve ser garantido que na coluna chave estrangeira no aparea o
valor da chave primria que est sendo excluda. No exemplo acima, isso significa que um
departamento no pode ser excludo, caso nele ainda existirem empregados.
44
5.1.3 Domnios e valores vazios

Quando uma tabela do banco de dados definida, para cada coluna da tabela, deve ser
especificado um conjunto de valores (alfanumrico, numrico,) que os campos da respectiva
coluna podem assumir. Este conjunto de valores chamado de domnio da coluna ou domnio
do campo.
Alm disso, devem ser especificados se os campos das colunas podem estar vazios
(null em ingls) ou no. Estar vazio indica que o campo no recebeu nenhum valor de seu
domnio.
As colunas nas quais no so admitidos valores vazios so chamadas de colunas
obrigatrias (not null). As colunas nas quais podem aparecer campos vazios so chamadas
de colunas opcionais(null).
Normalmente, os SGBD relacionais exigem que toda a coluna que compem a chave
primria seja obrigatria. A mesma exigncia no feita para as demais chaves.
5.1.4 Restries de Integridade

Um dos objetivos primordiais de um SGBD a integridade de dados. Dizer que os
dados de um banco de dados esto ntegros significa dizer que eles refletem corretamente a
realidade representada pelo banco de dados e que so consistentes entre si. Para tentar
garantir a integridade de um banco de dados os SGBD oferecem o mecanismo de restries de
integridade. Uma restrio de integridade uma regra de consistncia de dados que
garantida pelo prprio SGBD. As restries de integridade classificam-se em:
- Integridade de domnio: Restries deste tipo especificam que o valor de um campo
deve obedecer a definio de valores admitidos para a coluna (o domnio da coluna). Nos
SGBD relacionais comerciais, possvel usar apenas domnios pr-definidos (nmero inteiro,
nmero real, alfanumrico de tamanho definido, data, ). O usurio do SGBD no pode definir
domnios prprios de sua aplicao (por exemplo, o domnio dos dias da semana ou das
unidades da federao).
- Integridade de vazio: Atravs deste tipo de restrio de integridade especificado se
os campos de uma coluna podem ou no ser vazios (se a coluna obrigatria ou opcional).
Como visto, os campos que compem a chave primria sempre devem ser diferentes de vazio.
- Integridade de chave: Trata-se da restrio que define que os valores da chave
primria e alternativa devem ser nicos.
- Integridade referencial: a restrio que define que os valores dos campos que
aparecem em uma chave estrangeira devem aparecer na chave primria da tabela
referenciada.
As restries dos tipos acima especificados devem ser garantidas automaticamente por
um SGBD relacional.
45
5.2 ESPECIFICAO DE BANCO DE DADOS RELACIONAIS

A especificao de um banco de dados relacional (chamada de esquema do banco de
dados) deve conter no mnimo a definio do seguinte:
- Tabelas que formam o banco de dados
- Colunas que as tabelas possuem
- Restries de integridade
Na prtica, na definio de esquemas relacionais so usadas diversas notaes, que
variam de um SGBD para o outro.
46
TRANSFORMAO ENTRE MODELOS
Parte
6
t aqui foram vistas duas formas de modelagem de dados: a Abordagem EntidadeRelacionamento e a Abordagem Relacional. Estas abordagens propem modelar os
dados em diferentes nveis de abstrao. A Abordagem Entidade-Relacionamento
voltada modelagem de dados de forma independente do SGBD considerado.
adequada para construo do modelo conceitual. J a Abordagem Relacional modela os dados
em nvel de SGBD relacional. Um modelo neste nvel de abstrao chamado de Modelo
Lgico.
A figura abaixo d uma viso geral dos processos de transformao entre modelos.
Figura 54 - Transformao entre Modelos
6.1 TRANSFORMAO ENTIDADE-RELACIONAMENTO PARA RELACIONAL

As regras foram definidas tendo em vista dois objetivos bsicos:
- Obter um banco de dados que permita boa performance de instrues de consulta e
alterao do banco de dados. Obter boa performance significa basicamente diminuir o nmero
47
de acessos a disco, j que estes consomem o maior tempo na execuo de uma instruo de
banco de dados.
- Obter um banco de dados que simplifique o desenvolvimento e a manuteno de
aplicaes.
A fim de alcanar estes objetivos, as regras de traduo foram definidas tendo por base,
entre outros, os seguintes princpios:
- Evitar junes
- Diminuir o nmero de Chaves Primrias
- Evitar campos opcionais (campos null)
Observe o modelo abaixo:
Figura 55 - Modelo Conceitual
6.1.1 Implementao de Relacionamentos

Na converso dos relacionamentos do Modelo Entidade-Relacionamento para o Modelo
Lgico importante observar o lado que recebe o relacionamento o N, visto que ele
determinar em que tabela/entidade ficar a chave estrangeira. A representao da relao
Empregado e Dependente no modelo lgico usando a ferramenta DBDesign ficaria da seguinte
forma:
48
Figura 56 Representao 1:n no DBDesign
Caso o relacionamento seja N:N como acontece na relao Engenheiro e Projeto a

representao no modelo conceitual seria da seguinte forma:
Figura 57 - Representao Conceitual
No modelo lgico a representao atravs da ferramenta DBDesign seria da seguinte

forma:
Figura 58 - Representao n:n no DBDesign
Observa-se que para uma relao N:N, h a necessidade de se criar uma nova tabela
que conter as chaves estrangeiras de Engenheiro e de Projeto, podendo, neste caso, conter
outros atributos como o caso do atributo funo.
Alm desses casos existem outros onde h a necessidade da criao de uma nova
tabela, contudo depender da anlise realizada sobre o problema. Para isso, conveniente
conhecer as regras expressas no quadro abaixo:
49
Para relacionamentos especializados/generalizados importante notar que mantida a

mesma chave para as tabelas envolvidas no relacionamento em relao a tabela principal.
Observe a figura a seguir:
Figura 59 - Relacionamento de Especializao/Generalizao
50
NORMALIZAO
Parte
7
NORMALIZAO
as sesses anteriores foi possvel compreender como se d a analise

anali de requisitos de
um negcio, a conseqente formatao de um banco de dados usando a abordagem
entidade-relacionamento
relacionamento e sua transformao para Modelo Lgico.
Ainda dentro do Modelo Lgico de dados importante saber que a criao de um banco
de dados no advm somente da anlise de requisitos,
requisitos, podendo se formar a partir de uma
coleo de dados armazenados de forma organizada, porm no informatizado. Assim sendo,
importante para o analista ou DBA saber aproveitar esta organizao e construir modelo de
dados baseado no que j existe.
Dentro deste novo conceito de modelagem dos dados importante rever nas sees
anteriores os conceitos de independncia de dados e de consistncia de dados. Neste ltimo,
destaca-se
se o fato da consistncia de dados poder ser obtida de diversas formas, a saber:
s
- Pelo Sistema Gerenciador de Banco de Dados;
Dados
- Pelos aplicativos; e
- Pela prpria construo do sistema.
Pelo prprio Sistema Gerenciador de Banco de Dados oferecida consistncia

atravs de algumas regras de integridade que ele mesmo implementa, garantindo, por
exemplo, validade e completeza das informaes.
As regras mais importantes oferecidas pelo Sistema Gerenciador de Banco de Dados
so:
- Integridade de domnio;
- Integridade de Chave;
- Integridade de Vazio;
- Integridade referencial.
51
NORMALIZAO
Pelos aplicativos,, consideramos que nada foi implementado no Sistema Gerenciador

de Banco de Dados.. Assim sendo, indispensvel que sejam criadas rotinas para garantia de
uma consistncia mnima dos dados, como por exemplo, o respeito a domnios de chave
estrangeira.
Pela prpria construo do sistema,
sistema que o que nos
os interessa neste momento. Por
este mtodo necessrio controlar a construo do sistema atravs da criao de tabelas
segundo regras que garantam a manuteno de certas propriedades. Assim,
Assim as tabelas que
atendem a um determinado conjunto de regras, diz-se
diz se estarem em uma determinada forma
normal.
7.1 DEPENDNCIA FUNCIONAL

O conceito de dependncia funcional muito importante para o entendimento da
normalizao. Uma dependncia funcional uma restrio entre dois conjuntos de atributos de
uma base de dados.
Se o valor de um atributo ou conjunto de atributos A permite descobrir o valor de outro
atributo ou conjunto de atributos B, dizemos que A determina funcionalmente B, ou que B
depende de A, e denotamos:
Figura 60 - Representao da Dependncia Funcional
Exemplos:
RG
{ Nome, CIC, Depto., RG_Supervisor, Salrio }
Nmero_Projeto
{ Nome_Projeto, Localizao }
{ RG_Empregado, Nmero_Projeto }
Horas
Observe as tabelas abaixo:
52
NORMALIZAO
Matrcula
Nome
Endereo
85001
Pedro
Av. D1, 25
85001
Pedro
Av. D1, 25
85001
Pedro
Av. D1, 25
86005
Ana
Av. C-4, 35
...
...
...
...
...
Dependncia funcional de matrcula
...
...
...
Disciplina
Descrio
Instrutor
CP302
Banco de Dados
Nestor
CP303
Comunicaes
Ana
CP304
Eng. Software
Jorge
CP302
Banco de Dados
Nestor
Dependncia funcional de disciplina
...
...
...
...
...
Instrutor
Sala
Nestor
102
Ana
500
Jorge
102
Nestor
1024
Dependncia funcional de instrutor
7.2 NORMALIZAO
O processo de normalizao pode ser visto como o processo no qual so eliminados
esquemas de relaes (tabelas) no satisfatrias, decompondo-as, atravs da separao de
seus atributos em esquemas de relaes menos complexas, mas que satisfaam as
propriedades desejadas.
O processo de normalizao como foi proposto inicialmente por Codd. Esse processo
conduz um esquema de relao atravs de uma bateria de testes para certificar se o mesmo
53
NORMALIZAO
encontra-se na 1, 2 e 3 Formas Normais. Essas trs Formas Normais so baseadas nas

dependncias funcionais dos atributos da relao.
7.2.1 Objetivo da Normalizao

- Evitar problemas provocados por falhas no projeto, bem como eliminar a "mistura de
assuntos" e repeties desnecessrias de dados.
- Uma Regra de Ouro que devemos observar quando do Projeto de um Banco de Dados
baseado no Modelo Relacional de dados a de "no misturar assuntos em uma mesma
tabela".
O Processo de Normalizao aplica uma srie de Regras sobre as Tabelas de um
Banco de Dados, para verificar se estas esto corretamente projetadas. Embora existam cinco
formas normais (ou regras de Normalizao), na prtica usamos um conjunto de trs Formas
Normais.
Normalmente aps a aplicao das Regras de Normalizao, algumas tabelas acabam
sendo divididas em duas ou mais tabelas, o que no final gera um nmero maior de tabelas do
que o originalmente existente.
Este processo causa a simplificao dos atributos de uma tabela, colaborando
significativamente para a estabilidade do modelo de dados, reduzindo-se consideravelmente as
necessidades de manuteno.
7.2.2 Vantagens da Normalizao

- Otimiza o desempenho das atualizaes;
- Agrupa dados de tal forma que numa Relao cada dado torna-se um dado
dependente da Chave, de toda a Chave e nada mais que a Chave primria da Relao;
- Prov um meio formal de se estruturar a informao, de tal forma, que fica claro, que
tipos de dados existem e que dependncias funcionais so satisfeitas.
- Ajuda a dirimir dvidas de Projeto, pois por vezes, com a finalidade de melhorar o
desempenho das funes de acesso, o projetista do Banco de Dados pode tomar decises que
comprometam as funes de atualizao. Ao seguir estritamente o processo de normalizao
isso seria evitado;
7.2 FORMAS NORMAIS

7.2.1 Primeira Forma Normal (1 FN)
- Uma Tabela est na Primeira Forma Normal quando seus atributos no contm grupos
de repetio;
- Todos os atributos de uma tabela devem ser atmicos (indivisveis), ou seja, no so
permitidos atributos multivalorados, atributos compostos ou atributos multivalorados
compostos.
54
NORMALIZAO
- Tem por objetivo corrigir registros em que, para a chave primria, ocorrem "grupos de
repetio", ou seja, atributos que possam assumir mltiplos valores.
Regra:
Se um depsito de dados apresentar grupos de repetio, desmembr-lo, criando
depsitos menores e sem grupo de repetio, ou separar tabelas aninhadas.
Exemplo:
Figura 61 - 1 Forma Normal
7.2.1 Segunda Forma Normal (2 FN)

- Uma Tabela est na Segunda Forma Normal quando, alm de encontrar-se na
primeira forma normal, cada coluna no chave depende da chave primria completa.
- Tem por objetivo corrigir registros de chave composta que tenham atributos
dependentes apenas de uma parte da chave.
Regra:
Se um depsito de dados apresentar atributos dependentes apenas de uma parte da
chave composta, desmembr-lo, criando depsitos menores em que os atributos sejam
dependentes de toda a chave.
Obs.:
Se na 1 Forma Normal a tabela possuir apenas uma coluna como chave primria,
ento ela j est na 2 Forma Normal.
Exemplo:
55
NORMALIZAO
7.2.3 Terceira Forma Normal (3 FN)

- Encontra-se na segunda forma normal; e
- Na definio dos campos de uma entidade podem ocorrer casos em que um campo
no seja dependente diretamente da chave primria ou de parte dela, mas sim dependente de
outro campo da tabela, campo este que no seja a Chave Primria.
- Tem por objetivo corrigir registros que apresentem atributos dependentes de um
atributo no chave.
- Uma coluna no chave primria depende funcionalmente de outra coluna ou
combinao de colunas no chave primria.
- Eliminam-se campos calculados.
Regra:
Se um depsito de dados tiver atributo dependente de um atributo no chave,
desmembr-lo, criando depsitos menores em que os atributos s dependam da chave
primria.
Exemplo:
56
NORMALIZAO
7.2.4 Demais Formas Normais

Para a maioria dos documentos
documentos e arquivos, a decomposio at a 3 Forma Normal
suficiente para obter o esquema de um banco de dados correspondente ao documento. Na
literatura encontram-se outras formas normais, como a forma normal de Boyce/Codd, a 4
Forma Normal e a 5 Forma Normal.
N
A Quarta Forma Normal empregada se ainda existir alguma redundncia na 3
Forma Normal.. Isso acontecer quando um atributo no chave contiver valores mltiplos para
uma mesma chave.
A Quinta Forma Normal um caso muito raro de ocorrer. como se tivssemos na 4
Forma Normal trs campos em uma tabela e esses campos tivessem valores multivalorados.
A Forma Normal Boyce/Codd um aperfeioamento da 3 Forma
orma Normal e serve para
impor a condio de que uma tabela contenha dependncia apenas em funo de chave(s)
candidata(s). Qualquer outra dependncia deve ser eliminada e transferida para outra tabela
onde o determinante seja chave candidata.
57
ESTRATGIAS DE PROJETO DE BANCO DE DADOS
Parte
8
ma vez conhecedores dos conceitos do modelo conceitual e das duas estratgias do

modelo lgico, possvel traar um projeto de banco de dados alicerado nos conceitos
aprendidos. O projeto de banco de dados parte integrante do desenvolvimento de um
sistema de informao. Nesta fase, uma das preocupaes com a correta
representao dos dados operacionais. A atividade de projetar banco de dados envolve a
definio de esquemas de dados em diferentes nveis de abstrao: Nvel Conceitual, Lgico e
Fsico.
Projetar um banco de dados envolve basicamente duas metodologias principais: TopDown e Bottom-Up. A primeira, parte da representao de mais alto nvel de abstrao para a
de mais baixo nvel de abstrao, e a segunda parte da representao de mais baixo nvel de
abstrao para a mais alta.
8.1 PROJETO TOP-DOWN DE BANCO DE DADOS

Nesta metodologia a nfase est nos requisitos da aplicao que so obtidos com o
usurio e atravs da compreenso dos dados operacionais relevantes para a aplicao.
Este o processo mais usual, pois aplicado onde no existe sistema informatizado ou
banco de dados anterior.
Envolve quatro etapas:
1.
2.
3.
4.
Levantamento de requisitos
Projeto Conceitual
Projeto lgico
Projeto fsico ou implementao
8.1.1 Levantamento de Requisitos

Envolve a coleta de informaes sobre os dados, suas restries e seus
relacionamentos na organizao.
58
Sua forma de realizao contempla reunies com os usurios e observao do

funcionamento da organizao.
O resultado um documento com a especificao dos requisitos que podem ser
realizados de forma narrativa ou itemizado.
Exemplo:
LEVANTAMENTO NARRATIVO
... Todo servidor possui uma identificao nica na universidade e est lotado em um
departamento onde exerce uma determinada funo.
LEVANTAMENTO ITEMIZADO
a) Servidor:
- Possui uma identificao nica na faculdade;
- Est lotado em um departamento;
- Exerce uma funo no departamento.
8.1.2 Projeto Conceitual

O Projeto conceitual contempla a Modelagem dos dados e seus relacionamentos
independentes da estrutura de representao do Sistema Gerenciador de Banco de Dados.
Sua forma de realizao se d atravs da anlise da especificao de requisitos.
O resultado um esquema conceitual, proporcionando a abstrao de dados de alto
nvel, uma fcil compreenso pelo usurio leigo, fcil manuteno dos dados possibilitando a
traduo para qualquer Sistema Gerenciador de Banco de Dados;
8.1.3 Projeto Lgico

O Projeto Lgico a converso do esquema conceitual para um esquema de
representao de um Sistema Gerenciador de Banco de Dados (esquema lgico).
Sua forma de realizao pela aplicao de regras de converso entre modelos.
O resultado o diagrama lgico (tabelas, restries, etc). Nesta etapa recomendvel
utilizar-se de uma ferramenta case para modelagem do diagrama.
8.1.4 Projeto Fsico

O projeto fsico a definio do esquema lgico em um Sistema Gerenciador de Banco
de Dados adequado ao modelo.
Sua forma de realizao a criao do script SQL. Esse script pode ser gerado a partir
de uma ferramenta case, a mesma usada na etapa anterior.
59
O Resultado um esquema fsico ou script SQL pronto para ser aplicado no Sistema
Gerenciador de Banco de Dados.
8.1.5 Objetivos do Projeto Top-Down

- Projeto Conceitual: Correta abstrao do mundo real (captura correta da semntica da
aplicao)
- Projeto Lgico e Fsico: Escolhas corretas na converso para o esquema do SGBD
(relacional) para maximizar a performance de acesso (distribuio adequada dos dados na
tabela)
8.2 PROJETO BOTTOM-UP DE BANCO DE DADOS

Esta estratgia tem nfase nas descries de dados j existentes na organizao, como
arquivos eletrnicos, fichrios, pedidos, Notas Fiscais, etc.
tambm chamado de um processo de engenharia reversa e aplicado em casos em
que existem fontes de dados ou sistemas informatizados (legados) sem Banco de Dados.
Envolve cinco etapas:
1.
2.
3.
4.
5.
Coleta da fonte de dados;

Representao em uma tabela no normalizada;
Normalizao;
Integrao de esquemas relacionais/Projeto Lgico;
Engenharia Reversa/Projeto fsico ou implementao
8.2.1 Coleta da Fonte de Dados

Esta fase busca por fontes que organizam dados operacionais de alguma maneira, como
arquivos, fichrios, relatrios, etc.
Exemplo:
Um relatrio de alocao de projeto
60
Figura 64 - Coleta de Fontes
8.2.2 Representao em uma Tabela no Normalizada

a padronizao da representao das fontes de dados no formato de tabela aninhada.
Neste caso a tabela deve conter valores atmicos e grupos de repetio.
Exemplo:
Figura 65 - Tabela no normalizada
61
8.2.3 Normalizao
a decomposio sistemtica da tabela no normalizada em vrias tabelas relacionais.
um processo baseado na aplicao de regras (formas normais).
O objetivo a eliminao de redundncia no armazenamento e organizao dos dados
em entidades lgicas.
8.2.4 Integrao de Esquemas Relacionais/Projeto Lgico

a obteno do esquema relacional unificado para todas as fontes de dados
normalizadas.
O objetivo a integrao de tabelas que mantm as mesmas entidades e
relacionamentos com eliminao de tabelas redundantes.
8.2.5 Engenharia Reversa/Projeto fsico ou implementao

Esta fase depende do modelo no qual se est trabalhando. Caso o modelo seja o de um
banco de dados implementado ser empregada a tcnica de engenharia reversa.
Caso seja somente de dados organizados, baseado no projeto lgico gerar o projeto
fsico. Esta etapa pode ser realizada com o apoio de ferramentas case.
8.3 COMPARATIVO BSICO ENTRE AS ESTRATGIAS

Top-Down: Gera esquemas de banco de dados baseados nos requisitos da
organizao obtidos atravs de contatos com os usurios.
Bottom-Up: Gera esquemas de banco de dados baseados nas fontes de dados da
organizao.
Uma completa a outra.
62
LINGUAGEM DE INTERROGAO
Parte
9
t ento foram estudados conceitos relacionados a projeto de banco de dados. Este

captulo ser destinado aos conceitos da lgebra e clculo relacional aplicados como
linguagem de interrogao a banco de dados, o que ser muito til na realizao de
consultas em uma prxima etapa da disciplina de Banco de Dados.
Aspecto importante a ressaltar sobre a lgebra relacional que ela uma rea da
Matemtica que inspirou o modelo relacional.
9.1 LINGUAGENS DE CONSULTAS FORMAIS

Uma linguagem de consulta (Query Language) uma linguagem com a qual o usurio
pode requisitar ao Sistema de Gerncia de Banco de Dados (SGBD) informaes
armazenadas no Banco de Dados (BD).
As linguagens de consulta so classificadas em dois tipos:
a) Procedurais: O usurio descreve o algoritmo de acesso aos dados atravs de uma
seqncia de instrues (COMO)
b) No procedurais: O usurio descreve a informao que deseja obter sem
descrever como obt-la (O QU)
As linguagens de consulta e atualizao comerciais para sistemas relacionais baseiamse na lgebra Relacional (procedural) e no Clculo Relacional (no procedural).
As operaes da lgebra e do clculo exprimem o conjunto de consultas e
manipulaes possveis sobre uma base de dados relacional qualquer.
A lgebra apresenta o conjunto mnimo de operadores relacionais que podem ser
combinados para extrair da base de dados, praticamente, todas as informaes ali
armazenadas (dados e seus relacionamentos) .
O clculo estende (e completa) a potencialidade da lgebra relacional com a introduo
dos quantificadores universal () e existencial ().
63
9.2 CONCEITOS
- Relao: representada por uma tabela de duas dimenses (linhas e colunas);
- Tupla: corresponde a uma linha da relao;
- Atributo: corresponde s colunas da relao;
- Chave primria: conjunto de atributos que identificam univocamente cada tupla da
relao;
- Chave estrangeira: atributo de uma relao que chave primria de outra relao.
Figura 66 - Tabela no normalizada
9.2.1. lgebra Relacional
A lgebra Relacional um conjunto de operaes sobre modelos relacionais de dados.

Podem ser agrupadas em duas categorias:
- Operadores Tradicionais:
Unio (union):
Interseo:
difference): Diferena (set-difference):
Produto Cartesiano (cartesian product): x
- Operadores Relacionais:
Restrio/Seleo (select):
Projeo (project):
Juno Theta:
. Juno Natural:
Diviso:
A Seleo e Projeo so operaes UNRIAS.
64
As outras trs operaes (Produto Cartesiano, Unio e Diferena) operam, cada uma,
sobre um par de relaes.
As operaes da lgebra Relacional sempre operam sobre relaes e devolvem como
resultado uma relao.
9.2.2. Representao Grfica
9.2.2.1. OPERADORES TRADICIONAIS

Unio
Interseco
Diferena
Produto Cartesiano
9.2.2.2. OPERADORES RELACIONAIS

Seleo
Projeo
Juno
Diviso
65
9.2.2.3. SIMBOLOGIA
9.2.2.4. EXEMPLIFICAO
Para entender os conceitos da lgebra

lgebra Relacional observe as relaes abaixo:
a. Unio - R S
A unio de duas relaes A e B o conjunto de todas as tuplas pertencentes a relao
A ou pertencentes a relao B.
Exemplo:
A = conjunto de tuplas de forncedores de Joinville
B = conjunto de tuplas de fornecedores que fornecem P1
C = A unio B
66
#F
F1
F2
F4
Nome Condio Cidade

Pedro
20 Joinville
Joo
10 Florianpolis
Carlos
20 Joinville
b. Interseco - R S
A interseco de duas relaes A e B o conjunto de todas as tuplas pertencentes a
relao A e pertencentes a relao B.
Exemplo:
A = conjunto de tuplas de fornecedores de Joinville
C = A interseco B
#F Nome Condio Cidade

F1 Pedro
20 Joinville
c. Diferena - R S
A diferena de duas relaes A e B o conjunto de todas as tuplas pertencentes a
relao A e no pertencentes a relao B.
Exemplo:
A = conjunto de tuplas de fornecedores de Joinville
C = A diferena B

F4 Carlos
20 Joinville
d. Produto Cartesiano - R x S
O produto cartesiano de duas relaes A e B o conjunto de todas as tuplas t
originadas da concatenao das tuplas a pertencentes a A e das tuplas b pertencentes a B.
Exemplo:
A = conjunto de todos os cdigos de fornecedores de Joinville
B = conjunto de todos os cdigos de produtos de cor azul
C = A produto B
67
#F
F1
F1
F4
F4
#P
P3
P5
P3
P5
e. Seleo - F (R)
a operao usada para construir um subconjunto horizontal de uma relao, cujas
tuplas satisfaam uma determinada condio.
Exemplo:
C = SELEO(fornecedor, (cidade = Joinville))
Cidade=Joinville (Fornecedor)
F1 Pedro
20 Joinville
F4 Carlos
20 Joinville
f. Projeo - i1, i2, ..., im(R)
a operao usada para construir um subconjunto vertical de uma relao, cujas tuplas
satisfaam uma determinada condio.
Exemplo:
C = PROJEO(fornecedor, (#F, denominao, cidade))
#F,denominao, cidade, (Fornecedor)

#F
F1
F2
F3
F4
Denominao
Pedro
Joo
Marcos
Carlos
Cidade
Joinville
Florianpolis
Florianpolis
Joinville
g. Juno - R S
De duas relaes R1 e R2, que possuem um atributo em comum D, o subconjunto do
produto cartesiano das duas relaes, cujos valores dos elementos do atributo comum sejam
iguais nas duas relaes.
Na relao resultante elimina-se a repetio da coluna D.
Exemplo:
C = JUNO(fornecedor, pedido(#F))
68
Fornecedor Pedido
#F
F1
F1
F1
F1
F1
F1
F2
Denominao Condio Cidade

Pedro
20 Joinville
Pedro
20 Joinville
Pedro
20 Joinville
Pedro
20 Joinville
Pedro
20 Joinville
Pedro
20 Joinville
Joo
10 Florianpolis
h. Diviso - R / S
Seja A uma relao binria com atributos x e y e B uma relao unria com atributo z,
com y e z definidos sobre o mesmo domnio. Definimos a operao diviso, como sendo o
conjunto dos elementos x com os pares (x,y) pertencentes a A para todos os valores y
pertencentes a B.
Exemplo:
C = DIVISO(A, B ((#P))
9.3 LINGUAGENS DE INTERROGAO

lgebra Relacional pode ser usada como linguagem de interrogao Banco de Dados.
Exemplos:
- Quais os nomes dos professores do curso de Cincia da Computao?
nome [ curso = 104 ( Professor ) ]
69
- Quais os nomes e datas de nascimento dos alunos do curso SI nascidos antes de

1983?
nome, data_nasc [ codcurso = 104 data_nasc < 1983-01-01 ( Aluno ) ]
Considere agora as relaes abaixo: Clientes,, Depsitos e Emprstimos,

Empr
respectivamente.
70
- Selecione as tuplas da relao EMPRSTIMOS para qual o nome da agncia

Perryridge:
R = e-agncia=Perryridge (EMPRSTIMOS)
Em geral, os predicados permitem expressar comparaes do tipo (<, , >, , = e ).

Alm disso, pode-se relacional com operadores lgicos (and, or, not).
- Selecione tuplas da relao EMPRSTIMOS para as quais o valor do emprstimo

maior que 1200:
R = e-valor>1200 (EMPRSTIMOS)
- Selecione as tuplas da relao EMPRSTIMOS para as quais o nome da agncia

Perryridge e o valor do emprstimo excede 1200:
R = e-valor > 1200 and e-agencia = Perryridge(EMPRSTIMOS)
71

Introdução aos Bancos de Dados

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Introdução aos Bancos de Dados

Hochgeladen von

Copyright:

Verfügbare Formate

INTRODUO A SISTEMAS DE BANCO DE DADOS

objetivo deste material nortear o estudo de banco de dados em um curso

ELMASRI e NAVATE so referncias no estudo de bancos de dados, e aliado a forma

HISTRIA DOS BANCOS DE DADOS

m uma primeira abordagem sobre o assunto, muito importante conhecer como

1.1 DCADA DE 60 PRIMRDIOS

Os computadores se tornam parte efetiva do custo das empresas juntamente com o

HISTRIA DOS BANCOS DE DADOS

1.2 DCADA DE 70 GNESIS

Figura 1 - Dr. Edgar Frank Codd, o pai do modelo relacional.

HISTRIA DOS BANCOS DE DADOS

O Dr. Peter Chen tambm foi ofereceu grande contribuio

Figura 2 - Dr. Peter Chen, criador do modelo ER

1.3 DCADA DE 80 DESENVOLVIMENTO

HISTRIA DOS BANCOS DE DADOS

desenvolvimento de sistemas para novas indstrias e ao aumento do uso de computadores

1.4 DCADA DE 90 MATURIDADE

HISTRIA DOS BANCOS DE DADOS

- GIS (Sistemas de Informaes Geogrficas), Meteorologia, Fsica de Alta Energia

Nos idos da dcada surgem novas abordagens:

1.5 ONDE ESTAMOS?

HISTRIA DOS BANCOS DE DADOS

SISTEMAS DE GERNCIA DE BANCO DE DADOS

ara entender os Sistemas Gerenciadores de Banco de Dados importante conhecer

Sabendo o que so dados e informaes possvel definir os Bancos de Dados como

2.1 CARACTERSTICAS DE UM BANCO DE DADOS

SISTEMAS DE GERNCIA DE BANCO DE DADOS

Representar algum aspecto do mundo real, o qual chamado de mini-mundo.

2.2 MODELOS DE BANCO DE DADOS

2.2.1 Modelo Hierrquico ou de rvore

Figura 3 - Modelo Hierrquico

2.2.2 Modelo em Rede

Um modelo em rede uma extenso do modelo hierrquico. Em vez de se terem

Figura 4 - Modelo em Rede

SISTEMAS DE GERNCIA DE BANCO DE DADOS

2.2.3 Modelo Relacional

Os modelos relacionais se tornaram os mais populares. A finalidade global deste

2.3 SISTEMA DE GERENCIADOR DE BANCO DE DADOS (SGBD)

Os Sistemas Gerenciadores de Bancos de Dados surgiram para atender necessidade

2.3.1 Funes Bsicas de um Sistema Gerenciador de Banco de Dados

SISTEMAS DE GERNCIA DE BANCO DE DADOS

- Maior facilidade de realizar cpias de segurana;

2.3.2 Arquitetura de um Sistema Gerenciador de Banco de Dados

Figura 5 - Arquitetura de SGBD

SISTEMAS DE GERNCIA DE BANCO DE DADOS

Partindo da arquitetura proposta importante conhecer alguns conceitos diretamente

Figura 6 Independncia de dados

SISTEMAS DE GERNCIA DE BANCO DE DADOS

Existem dois nveis de independncia dos dados:

SISTEMAS DE GERNCIA DE BANCO DE DADOS

Os dicionrios de dados so gerados, normalmente, separados do Modelo de

Figura 7 - Modelo Entidade-Relacionamento

Os modelos de dados podem ser basicamente de dois tipos:

SISTEMAS DE GERNCIA DE BANCO DE DADOS

Linguagem de Definio de Dados). O Sistema Gerenciador de Banco de Dados possui um

2.3.3 Vantagens do uso de um Sistema Gerenciador de Banco de Dados

SISTEMAS DE GERNCIA DE BANCO DE DADOS

e) Tolerncia a Falhas: Um Sistema Gerenciador de Banco de Dados deve fornecer

Figura 8 Mdulos de um SGBD

SISTEMAS DE GERNCIA DE BANCO DE DADOS

Figura 9 - Arquitetura de SGBD

ma das principais caractersticas da abordagem de banco de dados que ela fornece

3.1 ETAPAS DA MODELAGEM DE DADOS