Modelagem De Dados
entidade produto, pois uma venda sem itens não
A modelagem de dados é uma técnica usada
para a especificação das regras de negócios e as
estruturas de dados de um banco de dados. Ela
faz parte do ciclo de desenvolvimento de um sis-
tema de informação e é de vital importância para
o bom resultado do projeto. Modelar dados con-
siste em desenhar o sistema de informações,
concentrando-se nas entidades lógicas e nas
dependências lógicas entre essas entidades.
Modelagem de dados ou modelagem de banco de
dados envolve uma série de aplicações teóricas e
práticas, visando construir um modelo de dados
consistente, não redundante e perfeitamente apli-
cável em qualquer SGBD moderno.
A modelagem de dados está dividida em: Modelo
conceitual, Modelo lógico, Modelo físico
Entidades
Os objetos ou partes envolvidas um domínio,
também chamados de entidades, podem ser
classificados como físicos ou lógicos, de acordo
sua existência no mundo real. Entidades físicas:
são aquelas realmente tangíveis, existentes e
visíveis no mundo real, como um cliente (uma
pessoa, uma empresa) ou um produto (um carro,
um computador, uma roupa). Já as entidades
lógicas são aquelas que existem geralmente em
decorrência da interação entre ou com entidades
físicas, que fazem sentido dentro de um certo
domínio de negócios, mas que no mundo exter-
no/real não são objetos físicos (que ocupam lugar
no espaço). São exemplos disso uma venda ou
uma classificação de um objeto (modelo, espécie,
função de um usuário do sistema).
As entidades são nomeadas com substantivos
concretos ou abstratos que representem de forma
clara sua função dentro do domínio. Exemplos
práticos de entidades comuns em vários sistemas
são Cliente, Produto, Venda, Turma, Função,
entre outros.
Podemos classificar as entidades segundo o mo-
tivo de sua existência:
 Entidades fortes: são aquelas cuja existên-
cia independe de outras entidades, ou seja, por si
só elas já possuem total sentido de existir. Em um
sistema de vendas, a entidade produto, por
exemplo, independe de quaisquer outras para
existir.
 Entidades fracas: ao contrário das entida-
des fortes, as fracas são aquelas que dependem
de outras entidades para existirem, pois individu-
almente elas não fazem sentido. Mantendo o
mesmo exemplo, a entidade venda depende da
tem sentido.
 Entidades associativas: esse tipo de enti-
dade surge quando há um relacionamento do tipo
muitos para muitos (explicado a seguir). Nestes
casos, é necessária a criação de uma entidade
intermediária cuja identificação é formada pelas
chaves primárias (explicado mais adiante) das
outras duas entidades. No contexto de uma apli-
cação de vendas, como precisamos relacionar
vendas e produtos numa relação muitos para
muitos, a entidade produto não pode referenciar
diretamente a venda, nem o inverso, pois isso
caracterizaria um relacionamento um para um, ou
um para muitos. Sendo assim, criamos uma enti-
dade intermediária para representar os itens da
venda, que tanto possuem a identificação do pro-
duto, quando da venda em que estão contidos.
Neste caso específico, também caberiam a esta
entidade informações como quantidade de itens e
desconto unitário, por exemplo.
Mais adiante veremos um exemplo prático onde
poderemos observar a existência dessas entida-
des de forma mais clara.
Relacionamentos
Uma vez que as entidades são identificadas, de-
ve-se então definir como se dá o relacionamento
entre elas. De acordo com a quantidade de obje-
tos envolvidos em cada lado do relacionamento,
podemos classifica-los de três formas:
 Relacionamento 1..1 (um para um): cada
uma das duas entidades envolvidas referenciam
obrigatoriamente apenas uma unidade da outra.
Por exemplo, em um banco de dados de currícu-
los, cada usuário cadastrado pode possuir ape-
nas um currículo na base, ao mesmo tempo em
que cada currículo só pertence a um único usuá-
rio cadastrado.
 Relacionamento 1..n ou 1..* (um para
muitos): uma das entidades envolvidas pode
referenciar várias unidades da outra, porém, do
outro lado cada uma das várias unidades referen-
ciadas só pode estar ligada uma unidade da outra
entidade. Por exemplo, em um sistema de plano
de saúde, um usuário pode ter vários dependen-
tes, mas cada dependente só pode estar ligado a
um usuário principal. Note que temos apenas
duas entidades envolvidas: usuário e dependente.
O que muda é a quantidade de unida-
des/exemplares envolvidas de cada lado.
 Relacionamento n..n ou *..* (muitos para
muitos): neste tipo de relacionamento cada enti-
dade, de ambos os lados, podem referenciar múl-
1
tiplas unidades da outra. Por exemplo, em um
sistema de biblioteca, um título pode ser escrito
por vários autores, ao mesmo tempo em que um
autor pode escrever vários títulos. Assim, um
objeto do tipo autor pode referenciar múltiplos
objetos do tipo título, e vice versa.
Os relacionamentos em geral são nomeados com
verbos ou expressões que representam a forma
como as entidades interagem, ou a ação que uma
exerce sobre a outra. Essa nomenclatura pode
variar de acordo com a direção em que se lê o
relacionamento. Por exemplo: um autor escreve
vários livros, enquanto um livro é escrito por vá-
rios autores.
Atributos
Atributos são as características que descrevem
cada entidade dentro do domínio. Por exemplo,
um cliente possui nome, endereço e telefone.
Durante a análise de requisitos, são identificados
os atributos relevantes de cada entidade naquele
contexto, de forma a manter o modelo o mais
simples possível e consequentemente armazenar
apenas as informações que serão úteis futura-
mente. Uma pessoa possui atributos pessoais
como cor dos olhos, altura e peso, mas para um
sistema que funcionará em um supermercado,
por exemplo, estas informações dificilmente serão
relevantes.
Os atributos podem ser classificados quanto à
sua função da seguinte forma:
 Descritivos: representam característica
intrínsecas de uma entidade, tais como nome ou
cor.
 Nominativos: além de serem também des-
critivos, estes têm a função de definir e identificar
um objeto. Nome, código, número são exemplos
de atributos nominativos.
 Referenciais: representam a ligação de
uma entidade com outra em um relacionamento.
Por exemplo, uma venda possui o CPF do cliente,
que a relaciona com a entidade cliente.
Quanto à sua estrutura, podemos ainda classificá-
los como:
 Simples: um único atributo define uma ca-
racterística da entidade. Exemplos: nome, peso.
 Compostos: para definir uma informação da
entidade, são usados vários atributos. Por exem-
plo, o endereço pode ser composto por rua, nú-
mero, bairro, etc.
Alguns atributos representam valores únicos que
identificam a entidade dentro do domínio e não
podem se repetir. Em um cadastro de clientes,
por exemplo, esse atributo poderia ser o CPF. A
estes chamamos de Chave Primária.
Já os atributos referenciais são chamados de
Chave Estrangeira e geralmente estão ligados à
chave primária da outra entidade. Estes termos
são bastante comuns no contexto de bancos de
dados. Mantendo o exemplo anterior, a entidade
cliente tem como chave primária seu CPF, assim,
a venda possui também um campo “CPF do clien-
te” que se relaciona com o campo CPF da entida-
de cliente.
Normalização de Dados
Normalização de dados é o processo formal e
passo a passo que examina os atributos de uma
entidade, com o objetivo de evitar anomalias ob-
servadas na inclusão, exclusão e alteração de
registros.
O conceito de entidade é muito importante neste
processo, ou seja, devemos identificar quais são
as entidades que farão parte do projeto de banco
de dados. Entidade é qualquer coisa, pessoa ou
objeto que abstraído do mundo real torna-se uma
tabela para armazenamento de dados. Normal-
mente usa-se o Modelo de Entidade e Relacio-
namento para criar o modelo do banco.
Veja um exemplo de várias entidades já normali-
zadas:
A regra de ouro que devemos observar no projeto
de um banco de dados baseado no Modelo Rela-
cional de Dados é a de "não misturar assuntos
em uma mesma Tabela". Por exemplo: na Tabela
Clientes devemos colocar somente campos rela-
cionados com o assunto Clientes. Não devemos
2
misturar campos relacionados com outros assun-
tos, tais como Pedidos, Produtos, etc. Essa "Mis-
tura de Assuntos" em uma mesma tabela acaba
por gerar repetição desnecessária dos dados bem
como inconsistência dos dados.
Veja Outro Exemplo Com Uma Tabela Não
Normalizada
Normalmente após a aplicação das regras de
normalização de dados, algumas tabelas acabam
sendo divididas em duas ou mais tabelas, o que
no final gera um número maior de tabelas do que
o originalmente previsto. Este processo causa a
simplificação dos atributos de uma tabela, colabo-
rando significativamente para a estabilidade do
modelo de dados, reduzindo-se consideravelmen-
te as necessidades de manutenção.
Veja a tabela acima após a aplicação da normali-
zação.
Tabela normalizada
Os objetivos da normalização são muitos, entre
eles destaco:
 Minimização de redundâncias e inconsis-
tências;
 Facilidade de manipulações do banco de
dados;
 Ganho de performance no SGBD;
 Facilidade de manutenção do sistema de
Informação;
 Entre outros.
As formas normais
O Processo de normalização aplica uma série de
regras sobre as tabelas de um banco de dados,
para verificar se estas estão corretamente proje-
tadas. Embora existam cinco formas normais (ou
regras de normalização), na prática usamos um
conjunto de três Formas Normais.
Vejamos as três primeiras formas normais do
processo de normalização de dados.
 Primeira Forma Normal (1FN)
 Segunda Forma Normal (2FN)
 Terceira Forma Normal (3FN)
Apesar de existir outras formas normais como a
quarta forma normal e quinta forma normal, ape-
nas as três primeiras têm sido consideradas atu-
almente. As formas normais são importantes ins-
trumentos para resolver antecipadamente pro-
blemas na estrutura do banco de dados.
Para aplicar a normalização de dados é necessá-
rio considerar a sequência das formas normais,
isto é, para aplicar a segunda forma normal por
exemplo, é necessário que seja aplicado a primei-
ra forma normal. Da mesma forma, para aplicar a
terceira forma normal é necessário que já tenha
sido feita a normalização na segunda forma nor-
mal.
Primeira Forma Normal (1FN)
A normalização de dados é um processo impor-
tante no processo de modelagem de dados. A
primeira parte da normalização é chamada de
1FN ou primeira forma normal, em uma escala
que vai até cinco. Uma relação estará na primeira
forma normal 1FN, se não houver grupo de dados
repetidos, isto é, se todos os valores forem úni-
cos. Em outras palavras podemos definir que a
primeira forma normal não admite repetições ou
campos que tenha mais que um valor.
Os procedimentos mais recomendados para apli-
car a 1FN são os seguintes:
 Identificar a chave primária da entidade;
 Identificar o grupo repetitivo e removê-lo da
entidade;
 Criar uma nova entidade com a chave pri-
mária da entidade anterior e o grupo repetitivo.
3
A chave primária da nova entidade será obtida
pela concatenação da chave primária da entidade
inicial e a do grupo repetitivo.
Exemplo de normalização de dados. Primeira
forma normal
Considere a tabela cliente abaixo:
Cliente
Código_cliente
Nome
* Telefone
Endereço
Agora a tabela com os dados:
Tabela desnormalizada, ou seja, não está na 1ª
forma normal
Analisando teremos:
Todos os clientes possuem Rua, CEP e Bairro, e
essas informações estão na mesma célula da
tabela, logo ela não está na primeira forma nor-
mal. Para normalizar, deveremos colocar cada
informação em uma coluna diferente, como no
exemplo a seguir:
Tabela ainda não está na primeira forma normal
Mesmo com o ajuste acima, a tabela ainda não
está na primeira forma normal, pois há clientes
com mais de um telefone e os valores estão em
uma mesma célula. Para normalizar será neces-
sário criar uma nova tabela para armazenar os
números dos telefones e o campo-chave da tabe-
la cliente. Veja o resultado a seguir:
Tabela na primeira forma normal
Tabela na 1ª forma normal
Na segunda tabela a chave primária está implíci-
ta, isto voe poderá encontrar algumas literaturas
especializadas, onde nem sempre ela é especifi-
cada, mas ela deverá existir.
No exemplo acima foi gerado uma segunda enti-
dade para que a primeira forma normal fosse
satisfeita, contudo é importante ressaltar que nem
sempre encontramos banco de dados com tabe-
las normalizadas. Existem casos onde as repeti-
ções são poucas ou o cenário permite administrar
as repetições sem trazer grandes consequências.
Segunda Forma Normal (2FN)
Uma tabela está na Segunda Forma Normal 2FN
se ela estiver na 1FN e todos os atributos não
chave forem totalmente dependentes da chave
primária (dependente de toda a chave e não ape-
nas de parte dela).
Se o nome do produto já existe na tabela produ-
tos, então não é necessário que ele exista na
tabela de produtos. A segunda forma normal trata
destas anomalias e evita que valores fiquem em
redundância no banco de dados.
Procedimentos:
 Identificar os atributos que não são funcio-
nalmente dependentes de toda a chave primária;
 Remover da entidade todos esses atributos
identificados e criar uma nova entidade com eles.
A chave primária da nova entidade será o atributo
do qual os atributos do qual os atributos removi-
dos são funcionalmente dependentes.
Exemplo de segunda forma normal
Considere a tabela vendas abaixo:
Vendas
N_pedido
Código_produto
Produto
Quant
4
Valor_unit
Subtotal
Agora a tabela com os dados:
Tabela não está na segunda forma normal
Analisando teremos:
O nome do produto depende do código do produ-
to, porém não depende de N_pedido que é a cha-
ve primária da tabela, portanto não está
na segunda forma normal. Isto gera problemas
com a manutenção dos dados, pois se houver
alteração no nome do produto teremos que alterar
em todos os registros da tabela venda.
Para normalizar esta tabela teremos de criar a
tabela Produto que ficará com os atributos Códi-
go_produto e produto e na tabela Venda mante-
remos somente os atributos N_pedido, códi-
go_produto, quant, valor_unit e subtotal. Veja o
resultado abaixo:
Tabela na segunda forma normal
Tabela na 2ª forma normal
Conforme visto na Primeira forma normal, quando
aplicamos normalização é comum gerar novas
tabelas a fim de satisfazer as formas normais que
estão sendo aplicadas.
Terceira Forma Normal (3FN)
Uma tabela está na Terceira Forma Normal 3FN
se ela estiver na 2FN e se nenhuma coluna não-
chave depender de outra coluna não-chave.
Na terceira forma normal temos de eliminar aque-
les campos que podem ser obtidos pela equação
de outros campos da mesma tabela.
Procedimentos:
 Identificar todos os atributos que são funci-
onalmente dependentes de outros atributos não
chave;
 Removê-los.
A chave primária da nova entidade será o atributo
do qual os atributos removidos são funcionalmen-
te dependentes.
Exemplo de normalização na terceira forma nor-
mal
Considere a tabela abaixo:
Tabela não está na terceira forma normal
Considerando ainda a nossa tabela Venda, vere-
mos que a mesma não está na terceira forma
normal, pois o subtotal é o resultado da multipli-
cação Quant X Valor_unit, desta forma a coluna
subtotal depende de outras colunas não-chave.
Para normalizar esta tabela na terceira forma
normal teremos de eliminar a coluna subtotal,
como no exemplo a seguir:
Tabela na terceira forma normal
Conforme visto na primeira forma normal e se-
gunda forma normal, a normalização torna a tabe-
la mais otimizada e sem anomalias.
Modelo Entidade Relacionamento
O Modelo Entidade Relacionamento (também
chamado Modelo ER, ou simplesmente MER),
como o nome sugere, é um modelo conceitual
utilizado na Engenharia de Software para descre-
ver os objetos (entidades) envolvidos em um do-
mínio de negócios, com suas características (atri-
butos) e como elas se relacionam entre si (relaci-
onamentos).
Em geral, este modelo representa de forma abs-
trata a estrutura que possuirá o banco de dados
da aplicação. Obviamente, o banco de dados
poderá conter várias outras entidades, tais como
chaves e tabelas intermediárias, que podem só
fazer sentido no contexto de bases de dados re-
lacionais.
5
Diagrama Entidade Relacionamento
Enquanto o MER é um modelo conceitual,
o Diagrama Entidade Relacionamento (Diagrama
ER ou ainda DER) é a sua representação gráfica
e principal ferramenta. Em situações práticas, o
diagrama é tido muitas vezes como sinônimo de
modelo, uma vez que sem uma forma de visuali-
zar as informações, o modelo pode ficar abstrato
demais para auxiliar no desenvolvimento do sis-
tema. Dessa forma, quando se está modelando
um domínio, o mais comum é já criar sua repre-
sentação gráfica, seguindo algumas regras.
O diagrama facilita ainda a comunicação entre os
integrantes da equipe, pois oferece uma lingua-
gem comum utilizada tanto pelo analista, respon-
sável por levantar os requisitos, e os desenvolve-
dores, responsáveis por implementar aquilo que
foi modelado.
Em sua notação original, proposta por Peter Chen
(idealizador do modelo e do diagrama), as entida-
des deveriam ser representadas por retângulos,
seus atributos por elipses e os relacionamentos
por losangos, ligados às entidades por linhas,
contendo também sua cardinalidade (1..1, 1..n ou
n..n). Porém, notações mais modernas abandona-
ram o uso de elipses para atributos e passaram a
utilizar o formato mais utilizado na UML, em que
os atributos já aparecem listados na própria enti-
dade. Essa forma torna o diagrama mais limpo e
fácil de ser lido.
Observe na figura um exemplo simples de um
diagrama para um sistema de imobiliárias.
Diagrama Entidade Relacionamento de sistema
de imobiliária
No domínio representado pelo diagrama acima
temos as seguintes entidades e relacionamentos:
 Proprietário contata Corretor (um proprietá-
rio pode contatar vários corretores e um corretor
pode ser contatado por vários proprietários).
 Corretor atende Inquilino (um corretor pode
atender vários inquilinos e um inquilino pode ser
atendido por vários corretores).
 Inquilino aluga Imóvel (um inquilino aluga
um imóvel e um imóvel pode ser alugado por
vários inquilinos).
 Proprietário possui Imóvel (um proprietário
possui vários imóveis e um imóvel pertence a
apenas um proprietário).
Uma variante da 1 Figura pode ser vista na 2
Figura, onde a cardinalidade do relacionamento é
exibida junto do losango.
Figura 2. Diagrama de Entidade Relacionamento
(variação)
Uma outra variação já mostra a cardinalidade de
uma forma mais completa, deixando claro as pos-
sibilidades de números de objetos envolvidos em
cada relacionamento. Nesse modelo, em cada
lado do relacionamento os números aparecem no
formato (X,Y) ao invés de um único número como
vemos nas figuras anteriores. A Figura ilustra um
exemplo desse tipo.
Diagrama Entidade Relacionamento (variação 2)
Neste diagrama, lemos os relacionamentos da
seguinte forma:
 1 ou 1 grupo possui 0 ou muitos produtos.
Como de um lado temos “1 ou 1”, isso equivale a
apenas “1”, pois não temos várias possibilidades.
Já do lado do produto, indicamos que um grupo
pode possuir nenhum produto, mas também pode
possuir vários.
 0 ou várias vendas contém 1 ou muitos
produtos. Ou seja, um produto pode nunca ser
vendido (0 vendas) como também pode ser ven-
dido várias vezes (n vendas). Já uma venda deve
6
conter 1 ou vários produtos, pois uma venda não
pode estar vazia (0 produtos).
Os atributos, como já foi dito, podem aparecer no
diagrama na forma de elipses ligadas às entida-
des. Essa foi a notação original proposta, mas
como podemos ver na Figura, ela deixa o dia-
grama com muitos itens e pode atrapalhar um
pouco a organização destes.
Atributos apresentados como elipses
Em uma notação mais atual, comumente utilizada
na UML, os atributos aparecem listados dentro do
próprio retângulo da entidade, enquanto o nome
da entidade aparece no topo na forma de título.
Na Figura 5 temos um exemplo.
Diagrama com atributos nas entidades
O Modelagem Conceitual é o primeiro modelo a
ser desenvolvido e é ele que deve ser usado para
envolver o cliente.
Este modelo é muito fácil de compreender, não
há limitações ou uma aplicação de tecnologia
específica.
Neste modelo já pode ser utilizado o diagrama de
Entidade e Relacionamento (DER), onde é identi-
ficado todas as entidades (tabelas) e os relacio-
namentos entre elas.
Com o diagrama fica compreendido o modelo
conceitual de dados.
Diferentemente do modelo conceitual.
Modelo Lógico leva em conta regras e algumas
limitações, implementando recursos padroniza-
dos.
Neste modelo, já é possível definir os atributos
que serão chaves primárias e chaves estrangei-
ras, tomando como base a estrutura que foi defi-
nida anteriormente no modelo conceitual.
Ainda referente ao modelo lógico, é opcional utili-
zar nomenclaturas “amigáveis” para os atributos
(há controvérsias), mas desde que seja obedeci-
do um padrão.
Mas ainda neste momento, não se está sendo
levado em conta limitações impostas por um ban-
co de dados específico, ou seja, atende a um
banco de dados supostamente “genérico”.
Na Modelagem Física, deve-se levar em conta
todas as regras e todas as limitações impostas
pelo banco de dados escolhido.
Deve ser levado como base o modelo criado an-
teriormente, o modelo lógico, obedecendo pa-
drões, regras e todas as validações possíveis.
É a partir deste modelo que fisicamente deve
estar espelhado o seu banco de dados final.
Pode-se dizer que é uma documentação mais
técnica e é específica para um determinado ban-
co de dados.
Bancos de Dados
Bancos de dados é um conjunto de arquivos rela-
cionados entre si com registros sobre pessoas,
lugares ou coisas. São coleções organizadas de
dados que se relacionam de forma a criar algum
sentido (Informação) e dar mais eficiência durante
uma pesquisa ou estudo, São de vital importância
para empresas e há duas décadas se tornaram a
principal peça dos sistemas de informação.
Normalmente existem por vários anos sem altera-
ções em sua estrutura. São operados pelos Sis-
temas Gerenciadores de Bancos de Dados
(SGBD), que surgiram na década de 70.
Antes destes, as aplicações usavam sistemas de
arquivos do sistema operacional para armazenar
suas informações. Na década de 80, a tecnologia
de SGBD relacional passou a dominar o mercado,
e atualmente utiliza-se praticamente apenas ela.
Outro tipo notável é o SGBD Orientado a Objetos,
para quando sua estrutura ou as aplicações que o
utilizam mudam constantemente.
A principal aplicação de Banco de Dados é con-
trole de operações empresariais. Outra aplicação
também importante é gerenciamento de informa-
ções de estudos, como fazem os Bancos de Da-
dos Geográficos, que unem informações conven-
cionais com espaciais.
7
Os bancos de dados são utilizados para armaze-
nar diversos tipos de informações, des-
de dados sobre uma conta de e-mail até dados
importantes da Receita Federal. A segurança do
banco de dados herda as mesmas dificuldades
que a segurança da informação enfrenta, que é
garantir a integridade, a disponibilidade e a confi-
dencialidade. Um Sistema gerenciador de banco
de dados deve fornecer mecanismos que auxiliem
nesta tarefa.
Uma forma comum de ataque à segurança do
banco de dados, é a injeção de SQL, em bancos
de dados que façam uso desta linguagem, mas
bancos de dados NoSQLtambém podem ser víti-
mas. Para evitar estes ataques, o desenvolvedor
de aplicações deve garantir que nenhuma entrada
possa alterar a estrutura da consulta enviada ao
sistema.
Os bancos de dados SQL implementam meca-
nismos que restringem ou permitem acessos aos
dados de acordo com papeis ou roles fornecidos
pelo administrador. O comando GRANT concede
privilégios específicos para um objeto (tabela,
visão, banco de dados, função, linguagem proce-
dural, esquema ou espaço de tabelas) para um
ou mais usuários ou grupos de usuários.
Transação
É um conjunto de procedimentos que é executado
num banco de dados, que para o usuário é visto
como uma única ação.
A integridade de uma transação depende de 4
propriedades, conhecidas como ACID.
 Atomicidade
 Todas as ações que compõem a unidade
de trabalho da transação devem ser concluídas
com sucesso, para que seja efetivada. Se durante
a transação qualquer ação que constitui unidade
de trabalho falhar, a transação inteira deve ser
desfeita (rollback). Quando todas as ações são
efetuadas com sucesso, a transação pode ser
efetivada e persistida em banco (commit).
 Consistência
 Todas as regras e restrições definidas no
banco de dados devem ser obedecidas. Relacio-
namentos por chaves estrangeiras, checagem de
valores para campos restritos ou únicos devem
ser obedecidos para que uma transação possa
ser completada com sucesso.
 Isolamento
 Cada transação funciona completamente à
parte de outras estações. Todas as operações
são parte de uma transação única. O principio é
que nenhuma outra transação, operando no
mesmo sistema, possa interferir no funcionamen-
to da transação corrente (é um mecanismo de
controle). Outras transações não podem visuali-
zar os resultados parciais das operações de uma
transação em andamento (ainda em respeito à
propriedade da atomicidade).
 Durabilidade
 Significa que os resultados de uma transa-
ção são permanentes e podem ser desfeitos so-
mente por uma transação subseqüente. Por
exemplo: todos os dados e status relativos a uma
transação devem ser armazenados num repositó-
rio permanente, não sendo passíveis de falha por
uma falha de hardware.
ANOTAÇÕES
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________