Objetivos da Modelagem de Dados

 Modelar implica em construir modelos

 Semântica de dados
 Regras de consistência
 Representar o ambiente observado
 Documentar e normalizar
 Fornecer processos de validação
 Observar processos de relacionamentos entre objetos

Etapas envolvidas na construção de modelos:

1 - Modelo conceitual - Representa as regras de negócio sem limitações tecnológicas ou de
implementação por isto é a etapa mais adequada para o envolvimento do usuário que não precisa ter
conhecimentos técnicos. Neste modelo temos:
 Visão Geral do negócio
 Facilitação do entendimento entre usuários e desenvolvedores.
 Possui somente as entidades e atributos principais
 Pode conter relacionamentos n para m.
2 - Modelos de dados - Um conjunto de ferramentas conceituais usadas para descrição de dados,
relacionamento entre dados, semântica e regras de consistência. São classificados em três diferentes
grupos:
2.1 Modelos Semânticos ou conceituais (Alto nível) - São usados na descrição de dados no nível
lógico e de visões. São caracterizados por dispor de recursos de estruturação bem mais flexíveis e por
viabilizar a especificação explícita das restrições de dados.
 Modelo entidade relacionamento (E-R) – tem por base a percepção do mundo real como um
conjunto de objetos, chamados entidades e do relacionamento entre eles. Apresenta certas
regras, uma delas é o mapeamento das cardinalidades, as quais expressam o número de
entidades às quais a outra entidade se relaciona por meio daquele conjunto de relacionamentos.
 Modelo Orientado a Objetos – tem por base um conjunto de objetos
 Modelo funcional de dados - Especifica os resultados de um processamento sem especificar
como ou quando eles serão processados. Ele especifica o significado das operações do modelo
de objetos e as ações do modelo dinâmico. Este modelo descreve como os dados são
transformados, mas não quem ou quando isto ocorrerá.

O modelo funcional é composto por múltiplos DFD's (Diagramas de Fluxo de Dados), que
especificam o significado das operações e restrições. Um DFD contém processos que
transformam dados, fluxos de dados que movimentam os dados, objetos atores que produzem e
consomem dados e objetos depósitos, que armazenam dados passivamente.

A modelagem dinâmica consiste na construção de modelos que representam o comportamento

dinâmico da interação dos objetos em termos de estados, transições, eventos e ações. Os
passos para esta modelagem são:
o Preparar Cenários;
o Identificar Eventos entre Objetos;
o Preparar um Diagrama de Fluxo de Eventos para cada Cenário;
o Construir um Diagrama de Estado para cada Classe.

 Modelo Dinâmico - Representa a parte dinâmica do sistema. Este modelo tem como elementos
básicos:
o Evento: transmissão de informações entre objetos;
o Estado: abstração de um objeto (atributo + ligações).

Quando um evento ocorre estimulando um objeto pode ocorrer uma resposta a este estímulo
e/ou, eventualmente, a geração de um outro evento. Um evento separa dois estados e um
estado separa dois eventos.
O modelo dinâmico é composto, basicamente, por dois tipos de diagramas:
o Diagramas de Eventos: representam os eventos entre objetos do sistema;
o Diagramas de Estados: representam os estados e os eventos ocorridos em uma classe,
isto é, descreve o comportamento de uma classe de objetos.
Página 1 de 40
 Em suma, o modelo dinâmico é uma coleção de diagramas de estados que interagem uns com
os outros através de eventos compartilhados.

2.2 Modelos lógicos ou de implementação (nível intermediário) - O modelo lógico já leva em conta
algumas limitações e implementa recursos como adequação de padrão e nomenclatura. Define as
chaves primárias e estrangeiras. Deve ser criado levando em conta os exemplos de modelagem de
dados criados no modelo conceitual.
 Regras de Derivação:

o Normalização das estruturas de dados

o Derivação de estruturas de agregação e generalização-especialização

o Derivação de relacionamentos

 Regras de Restrição:

o Restrição de domínio

o Restrição de Integridade

o Restrição de Implementação

2.3 Modelo Físico (baixo nível) – Inclui a análise das características e recursos necessários para
armazenamento e manipulação das estruturas de dados (estrutura de armazenamento, endereçamento,
acesso e alocação física).
 Modelo de partição de memória (frame-memory model).

Linguagem de banco de dados

 DDL (Data Definition Language) – Cria os objetos do BD (tabelas, procedures, triggers, etc.) e
seus Metadados.
 DML (Data Manipulation Language) – é a linguagem de manipulação de dados, que permite
especificar operações de recuperação e alterações dos dados do BD. A DML pode ser de alto
nível (declarativa ou nãoprocedimental), que pode ser utilizada sozinha para especificar
operações complexas de dados; ou de baixo nível (procedimental), que é embutida em uma
linguagem de programação de uso geral (linguagem hospedeira).
 DCL (Data Control Language) – é a linguagem de controle de dados, usada pelo DBA para
controlar o acesso aos dados pelos usuários. Possui comandos de atribuição e remoção de
privilégios.
 SCL – Storage Control Language
 VCL – View Control Language
 OQL – Object Query Language
 ODL – Object Definition Language

Página 2 de 40
Projeto e implementação de Banco de Dados

Fase 1: Levantamento e Análise de Requisitos

 Conhecer e analisar as expectativas dos usuários
 Escolha das pessoas chaves
 Estudo da documentação existente
 Analisar tipos de transações e sua freqüência
 Nessa fase usam-se DFDs e outros diagramas

Fase 2: Projeto Conceitual do Banco de Dados

Aproveitando as informações da fase 1, essas informações são consolidadas.
 Projeto do esquema conceitual: Examina os requisitos de dados
Características dos dados conceituais:
1. Expressividade: deve distinguir dados, relacionamentos e restrições.
2. Simplicidade e inteligibilidade: qualquer um consegue entender
3. Sintético: Mostrar apenas conceitos básicos.
4. Representação diagramática: de fácil compreensão.
5. Formalismo: sem ambigüidades.
Estratégias para projeto de esquemas:
1. Top-down
2. Bottom-down
3. Inside-down
4. Mista
Página 3 de 40
  Projeto das transações e das aplicações: Avalia o fluxo das informações
1. Transações de entrada
2. Transações de atualização
3. Transações mistas

Fase 3: Escolha de um SGBD

Onde se avalia sobre as características desde valores às ferramentas disponíveis

Fase 4: Mapeamento do Modelo de Dados (Projeto Lógico de Banco de Dados)

Mapeamento de sistema independente, ou seja, independente de estrutura física, criação de visões.

Fase 5: Projeto físico do Banco de Dados

 Criação de DDL
 Preocupação com desempenho, throughput
 Preocupação com espaço

Fase 6: Implementação e Sintonização

 Cargas
 Rotinas de conversão
 Monitoramento de desempenho, uso de índices.

Página 4 de 40
Alguns Conceitos básicos
 Asserções => Constrains com condições semelhantes a clausula where
 Atributos: propriedades da entidade. (coluna , campo , etc,..).
 Conjunto de entidades: conjunto que abrange entidades de mesmo tipo, que compartilham os
mesmos atributos.
 Conjunto de entidades Fracas: Atributos insuficientes para formar uma chave primária. Para
solucionar cria-se um identificador.
 Derivado – resultados calculados.

 Integralidade:
 Disjunção: uma entidade generalizada, derivando várias subclasses especializadas.
 Disjunção Parcial: Somente algumas especializações são mostradas
 Disjunção Total: Todas as especializações são mostradas
 Over-lap: tipo de disjunção em que uma super classe pode ter mais que uma especialização
dentro das disjunções disponíveis.

 Entidade: pode ser definida como qualquer coisa do mundo real, abstrata ou concreta.
Exemplos: Cliente, Produto, Contrato, Vendas, etc.
 Entidade Fraca: Entidade que não possui identificador próprio, dependente de uma super-
classe.
 Especialização => Top-down “contrário de” Generalização => Botton-up
 Funções agregadas => tomam um conjunto de valores e retornam um valor simples (sum,
count,etc).
 Heap file ou pile file => registros gravados na ordem de entrada, arquivos desordenados.
 Junção Externa => outer join
 Monovalorados ou multivalorados – Ex: nº empréstimo ou dependentes.
 Nota:  Chama-se Domínio o conjunto de valores possíveis do atributo.
 Nulos – tipo Null.
 Projeção => em vez do * lista-se apenas as colunas desejadas.
 Projeção generalizada => Projeção + fórmulas
 Reticulado de especialização: Hierarquia, subclasse da subclasse.
 Simples ou compostos – Ex: nome ou nome e sobrenome.
 Spanned => split de um bloco de registro (não spanned é quando não existe a quebra de um
registro ao meio entre um bloco e outro, como ocorre no Spanned.
 Subclasse compartilhada: herança múltipla.

Página 5 de 40
Álgebra Relacional
Simbologia:
 <condição de seleção>(R) Ex: id=26 (Empregado)
<lista de atributos ou projeção>(R) Ex: pnome, sal, nfone (Empregado)

Resultado de uma consulta: Temp id=26 (Empregado)

Renomeando Colunas: R(Nome,Salário,Telefone)  pnome, sal, nfone (Temp)

: União
: interseção
-: minus
: junção Ex: Dept_TempDepartamento id_dpto=id_emp Empregado
: natural join Ex: Dpto_projProjeto * (nome,idproj,data)(Departamento)

Página 6 de 40
Cardinalidade.
A Cardinalidade indica quantas ocorrências de uma Entidade participam no mínimo e no máximo do
relacionamento.
Cardinalidade Mínima - define se o relacionamento entre duas entidades é obrigatório ou não.
Ex: Abaixo temos a entidade Pais e a Entidade UF.
Um país possui no mínimo ZERO UF
(Existem paises que não possuem
Estados . Ex: Vaticano)
Uma UF pertence pelo menos a UM País.
Nota: O nome UF talvez não seja mais
apropriado. A entidade representa um
estado ou subdivisão equivalente em um
País

Cardinalidade Máxima - define a quantidade máxima de ocorrências da Entidade que pode

participar do Relacionamento. Deve ser maior que zero.
Ex: Abaixo temos a entidade Pais e a Entidade UF novamente.

País possui no máximo Várias (mais de

uma) UF

Juntando as duas cardinalidade temos o modelo lógico abaixo:

País pertence no mínimo a ZERO UF e

no máximo a VÀRIOS UF
UF pertence no máximo e no mínimo a
UM País.

Agora vamos definir os tipos de cardinalidade quanto ao relacionamento:

Cardinalidade UM para UM:

 PESSOA pode ser no mínimo um

CLIENTE. (opcional)
 CLIENTE É uma PESSOA.
(Obrigatório)

Nota: No relacionamento Um para Um temos o lado opcional e o lado obrigatório . A chave

primária se desloca em direção ao lado opcional. No exemplo acima o descolamento seria da
entidade CLIENTE para a entidade PESSOA.

Cardinalidade UM para N.
PRODUTO possui nenhum ou muitas
modalidade de produto
MODALIDADE DE PRODUTO pertence a um
produto.
Nota: A cardinalidade UM para N leva a chave primária do lado UM para o lado N. Neste caso o
atributo recebe o nome de chave estrangeira ou Foreign Key ( FK ).  Chave Estrangeira é a chave
primária de uma entidade que aparece em outra entidade em virtude do relacionamento.

Página 7 de 40
Cardinalidade N para N.

CLIENTE celebra um ou vários Contratos

CONTRATO é celebrado por um ou
vários clientes

A cardinalidade N para N leva para o modelo lógico a necessidade de definição de mais um entidade.
Chamamos isto de ASSOCIATIVA. Para o exemplo acima teríamos:

A Entidade CLIENTE DO CONTRATO

é necessária para que possamos
identificar o contrato de um
determinado cliente.
Em toda Cardinalidade N para N
temos a ASSOCIATIVA.

Página 8 de 40
Anomalias de Modificações
Quando o banco de dados é mal projetado ocorrem Anomalias:
 Anomalia de Inserção: Quando deve-se preencher colunas com Null por falta de informação.
 Anomalias de Exclusão: Elimina-se informações de um setor ao excluir funcionários, por
exemplo.
 Anomalias de Alteração: Ao alterar um setor deve-se alterar a tabela de funcionários inteira por
ex.

Dependência Funcional
Uma dependência funcional é uma restrição entre dois conjuntos de atributos de uma base de dados.

Dependência Funcional Total

Dados os atributos “A” e “B” de uma entidade, diz-se que “B” é funcionalmente dependente de “A” se e
somente se, a cada valor de “A” está associado um único valor de “B”.
Ex.:

Dependência Funcional Transitiva

Dados os atributos “A”, “B” e “C” de uma entidade, sendo “A” a chave, diz-se que “B” e “C” são
dependentes transitivos se e somente se, forem funcionalmente dependentes de “A” além de existir uma
dependência funcional entre eles.
Ex.:

O reconhecimento das dependências funcionais das relações que representam as informações de um

BD é possível através do entendimento do significado destas informações. As dependências funcionais
representam restrições de integridade do mundo real que devem ser representadas no projeto lógico do
BD.

Obs: Nenhum modelo é suficientemente claro se não for acompanhado de uma definição formal
dos elementos, fazemos isto através do Dicionário de Dados. Os conceitos que podem ser triviais
a quem esta modelando podem não ser para pessoas leigas no assunto. Assim o dicionário de
dados tem o objetivo de deixar claro qualquer informação que seja de valia para o processo de
compreensão e unificação de conceitos.

Normalização: é o conjunto de regras que visa minimizar as anomalias de modificação dos dados e dar
maior flexibilidade em sua utilização.
Finalidades:
 Minimização de redundâncias e inconsistências;

 Facilidade de manipulações do Banco de Dados;

 Facilidade de manutenção do Sistema de Informações

Formas Normais

Página 9 de 40
Realizar o projeto lógico de um BD usando o modelo relacional consiste em escolher o conjunto de
relações mais apropriado para representar as informações daquele BD, isto é, determinar que relações
serão necessárias e quais atributos cada relação terá.
A teoria da normalização permite reconhecermos os casos em que algumas relações possuem
propriedades indesejáveis, e mostra como essas relações podem ser convertidas para uma forma mais
desejável.
A teoria da normalização é baseada no conceito de formas normais. Uma relação é dita estar em uma
determinada forma normal, se ela satisfaz a um conjunto específico de restrições.
Existem vária formas normais, primeira forma normal (1FN), segunda forma normal (2FN), terceira forma
normal (3FN),... Relações na 1FN são mais desejáveis do que relações não normalizadas.
Relações na 2FN são mais desejáveis do que relações apenas na 1FN,... Ao realizar o projeto lógico de
um BD, escolhe-se em geral relações na FNBC.
Inicialmente Codd criou as três primeiras formas de normalização chamando-as de: primeira forma
normal (1NF), segunda forma normal (2NF) e terceira forma normal (3NF). Uma definição mais forte da
3NF foi proposta depois por Boyce-Codd, e é conhecida como forma normal de Boyce-Codd (FNBC)

Para determinar em que forma normal uma determinada relação está, é preciso considerar o significado
das informações que aquela relação representa no BD.

Primeira Forma Normal (1FN)

Uma relação está na 1FN se os domínios de todos os seus atributos são atômicos, isto é, o valor de
cada atributo em cada tupla não pode ser decomposto. Uma relação na 1FN é dita normalizada.
Uma relação que não está na 1FN, pode sempre ser transformada em uma relação que esteja na 1FN.
Exemplo:
· Relação Aluno:

O atributo disciplinas cursadas não é atômico. Logo a relação Aluno não está na 1FN.
Transformando a relação Aluno para o formato abaixo, ela fica na 1FN.

No modelo relacional escolhemos trabalhar com relações normalizadas, pois isto não traz restrição ao
que pode ser representado e traz uma simplicidade nas estruturas de dados e em conseqüência na
manipulação dos dados.

Segunda Forma Normal (2FN)

Uma relação está na 2FN, se e somente se, ela está na 1FN, e cada atributo não pertencente à chave
primária é dependente funcionai total da chave primária.
Uma relação que está na 1FN e não está na 2FN, pode sempre ser transformada em um conjunto de
relações que estejam na 2FN, através de uma decomposição sem perdas.
Exemplo:

Página 10 de 40
Chave primária: CPF cliente, no. conta
CPF cliente, no. conta -> senha
CPF cliente, no. conta -> nome cliente
CPF cliente, no. conta -> telefone
CPF cliente -> nome cliente
CPF cliente -> telefone

Os atributos nome cliente e telefone não são dependentes funcionais totais da chave primária.
(Intuitivamente observamos que eles não descrevem a informação identificada pela chave primária.) A
relação está na 1FN, mas não está na 2FN. Realizando uma decomposição sem perdas, obtém-se:

Estas duas relações estão na 2FN. Com isso, eliminamos redundância, pois da maneira anterior, os
atributos nome cliente e telefone apareceriam repetidos para cada conta de um mesmo cliente.

Terceira Forma Normal (3FN)

Uma relação está na 3FN se ela está na 2FN, e cada atributo não pertencente à chave primária não é
dependente transitivo da chave primária.
Uma relação que está na 2FN e não está na 3FN, pode sempre ser transformada em um conjunto de
relações que estejam na 3FN, através de uma decomposição sem perdas.
Exemplo:

Chave primária: no. reg. aluno

no. reg. aluno -> nome aluno
no. reg. aluno -> cód. curso
no. reg. aluno -> nome curso
cód. curso -> nome curso
O atributo nome curso é dependente transitivo da chave primária. (Intuitivamente observamos que ele
não descreve a informação identificada pela chave primária.) A relação está na 2FN, mas não está na
3FN. Realizando uma decomposição sem perdas, obtém-se:

Estas duas relações estão na 3FN. Com isso, eliminamos redundância, pois da maneira anterior, o
atributo nome curso apareceria repetido para cada aluno de um mesmo curso.

Determinante Funcional
Um determinante funcional é um atributo ou conjunto de atributos, do qual algum outro atributo é
dependente funcional.
Exemplos:
· Na relação Aluno da seção anterior, os atributos no. reg. aluno e cód. curso são determinantes
funcionais.
· Na relação Aluno¢ da seção anterior, o atributo no. reg. aluno é um determinante funcional.
Na relação Curso da seção anterior, o atributo cód. curso é um determinante funcional.

Página 11 de 40
Forma Normal de Boyce e Codd (FNBC)

Página 12 de 40
Quarta forma normal

Quinta forma normal

Um relacionamento triplo está em 5FN se não pode ser decomposto em relacionamentos duplos.

Quando Não Normalizar

Em algumas situações específicas, pode-se optar por não normalizar completamente uma relação,
deixando-a, por exemplo, na 2FN e não na FNBC. Neste caso estaremos optando por ter uma relação
com alguma redundância.
Exemplo:

Página 13 de 40
A relação está na 2FN, mas não está na FNBC.

Página 14 de 40
Projeto Lógico de Bancos de Dados
O projeto lógico de um BD utilizando o modelo relacional é iniciado a partir de um conjunto inicial de
relações, obtidas com a transformação do projeto conceitual em relações. Com a identificação das
dependências funcionais entre os atributos das relações, realiza-se a normalização das relações, que,
através de idéia de decomposição sem perdas, são transformadas em um conjunto de relações
equivalente ao original, porém em um formato mais correto.

De maneira simplificada, a realização do projeto lógico de um BD segue as seguintes etapas:

 Transformação do projeto conceitual em relações;
 Transformação das relações que não estão na 1FN em relações equivalentes que estejam na
1FN;
 Identificação das chaves candidatas e chave primária das relações;
 Identificação das dependências funcionais entre os atributos das relações;
 Transformação das relações que não estão na FNBC em relações equivalentes que estejam na
FNBC.

O objetivo geral do processo de normalização é obter relações em uma forma mais desejável, reduzindo
a redundância e evitando problemas nas manipulações dos dados. Quando realizamos o projeto
conceitual do BD (usando o modelo entidade-relacionamento), antes de realizarmos o projeto lógico do
BD (usando o modelo relacional), as relações já ficam em geral bem organizadas, reduzindo as
normalizações necessárias.

Teoria sobre dependências funcionais

a) Fechamento de um conjunto de dependências funcionais
Em geral, não é suficiente considerar apenas o conjunto de dependências funcionais dado, mas
precisamos considerar todas as dependências funcionais que são válidas. Suponha que seja dada a
relação r = (A, B, C, G, H, I) e o seguinte conjunto de dependências funcionais:

Página 15 de 40
Página 16 de 40
Separação
A -> BC então A -> B e A -> C

Exemplo:
CPF -> nome, endereço então CPF -> nome e CPF -> endereço
Leia o exemplo acima da seguinte maneira:
Se com um número de CPF eu encontro o nome e o endereço de uma pessoa, então com este mesmo
número eu posso encontrar apenas o nome e com este mesmo número eu posso encontrar apenas o
endereço.
 
Acumulação
A -> B então AC -> B
Exemplo:
CPF -> endereço então CPF, idade -> endereço
Leia o exemplo acima da seguinte maneira:
Se com um número de CPF eu encontro o endereço de uma pessoa, então com este mesmo número
mais a idade da pessoa eu posso encontrar o endereço também.
Transitividade
A -> B e B -> C então A -> C
Exemplo:
CPF -> código-cidade e código-cidade -> nome-cidade então CPF -> nome-cidade
Leia o exemplo acima da seguinte maneira:
Se com um número de CPF eu encontro o código da cidade de uma pessoa, e com o código da cidade
eu encontro o nome da cidade, então com o número do CPF eu posso encontrar o nome da cidade.
Pseudo-Transitividade
A -> B e BC -> D então AC -> D
Exemplo:
CPF -> código-funcionário e código-funcionário, mês -> salário-funcionário então CPF, mês -> salário-
funcionário.
Leia o exemplo acima da seguinte maneira:
Se com um número de CPF eu encontro o código do funcionário, e com o código do funcionário mais um
certo mês eu encontro o salário que ele recebeu naquele mês, então com o número do CPF mais um
certo mês eu posso encontrar o salário que ele recebeu naquele mês.

Persistência de objetos
 Persistência por classe – classe é criada default como persistente.
 Persistência por criação – depende de como foi criado.
 Persistência por marcação – marcado como persistente após criação.

Página 17 de 40
 Persistência por referência – Um ou mais objetos são explicitamente declarados como objetos
persistentes (raiz). Todos os outros objetos são persistentes se (e somente se) forem
referenciados diretamente, ou indiretamente, a partir do objeto persistente raiz.

Página 18 de 40
Prototipação

Finalidade da Prototipação
"Prototipação é o processo de construção de um modelo de um sistema. No processo de
desenvolvimento de sistemas de informação, os protótipos são utilizados para auxiliar os projetistas e
desenvolvedores de sistemas a construir aplicações que sejam intuitivas e de fácil utilização por parte de
seus usuários”.
Protótipos são uma valiosa ferramenta no projeto de aplicações. Eles podem ajudar na avaliação de
alternativas de design a qualquer estágio do processo de desenvolvimento. Durante a fase conceitual os
elementos básicos do design podem ser explorados e testados junto com os usuários. Ao serem
projetadas as telas, menus, relatórios e levantadas as formas de interação em maior detalhe, estas
questões podem ser discutidas, avaliadas e testadas. Mais adiante modelos mais elaborados podem ser
utilizados para dar uma visão antecipada da aplicação final. Adicionalmente "storyboards" podem ser
adotados para verificação básica de sua utilização.

Durante a fase de análise de um sistema, quando são definidos os requisitos básicos, os analistas de
sistemas coletam informações sobre os procedimentos atuais do cliente e os processos de negócio
relativos ao sistema proposto. Adicionalmente eles estudam o sistema atual, se houver, conduzem
entrevistas e coletam documentação. Isto ajuda aos analistas na elaboração de um conjunto inicial de
especificações.

O emprego da prototipação ajuda a melhorar este processo, pois possibilita a conversão das
especificações básicas, ainda que algumas vezes intangíveis, em um modelo operacional tangível, ainda
que limitado, do sistema desejado. O feedback recebido dos usuários, obtido a partir da utilização de um
modelo do sistema com o qual eles podem interagir, facilita a obtenção de respostas e avaliação dos
usuários, feedback este que o analista irá utilizar para, eventualmente, modificar os requisitos originais
bem como elaborar novas especificações.

Prototipação se apresenta sob muitas formas - desde esquemas simples em papel ou softwares onde os
usuários podem colar controles e objetos (disponíveis em ferramentas RAD - Rapid Application
Development), utilização de ferramentas CASE (Computer Aided Software Engineering), linguagens de
quarta geração etc. Muitas empresas utilizam várias ferramentas durante o processo de prototipação.
Por exemplo, uns utilizarão esquemas em papel na análise inicial para facilitar um feedback concreto dos
usuários e depois desenvolvem um protótipo operacional utilizando linguagens de quarta geração, tais
como Visual FoxPro, durante a fase de projeto.

Algumas Vantagens da Utilização de Técnicas de Prototipação:

 Viabiliza um maior envolvimento dos usuários, promovendo a interação entre os usuários e a
equipe de desenvolvimento.
 Usuários e equipe de desenvolvimento estabelecem uma linguagem comum de comunicação
sobre as características que serão implementadas no sistema final.
 O nível de comunicação, quantitativamente e qualitativamente, entre os usuários e os
desenvolvedores aumenta, diminuindo os "ruídos" de comunicação (aumentando o "signal to
noise ratio”)
 Os desenvolvedores recebem feedback, em quantidade e de qualidade, dos usuários.
 Os desenvolvedores tomam conhecimento de futuras melhorias, em potencial, do sistema.
 Viabiliza um maior envolvimento dos usuários, promovendo a interação entre os usuários e a
equipe de desenvolvimento.
 Usuários e equipe de desenvolvimento estabelecem uma linguagem comum de comunicação
sobre as características que serão implementadas no sistema final
 O nível de comunicação, quantitativamente e qualitativamente, entre os usuários e os
desenvolvedores aumenta, dimínuindo os "ruídos" de comunicação (aumentando o "signal to
noise ratio”)
 Os desenvolvedores recebem feedback, em quantidade e de qualidade, dos usuários.
 Os desenvolvedores tomam conhecimento de futuras melhorias, em potencial, do sistema.
 Os usuários terão uma visão mais concreta do que será desenvolvido
 Os usuários passam a ter um maior conhecimento sobre o sistema a ser desenvolvido
 Facilita a implementação do sistema, pois os usuários sabem o que esperar.
 Minimiza o surgimento das "surpresas" por parte dos usuários quando estes forem apresentados
ao sistema final
Página 19 de 40
  Protótipos são criados rapidamente e alterações são feitas em menos de uma hora ou de
algumas horas
 Os protótipos são criados por um grupo - isto ajuda a estabelecer um entendimento comum em
torno do design
 Minimiza o surgimento das "surpresas" por parte dos usuários quando estes forem apresentados
ao sistema final
 Protótipos são criados rapidamente e alterações são feitas em menos de uma hora ou de
algumas horas
 Os protótipos são criados por um grupo - isto ajuda a estabelecer um entendimento comum em
torno do design
 Qualquer um pode participar do design de protótipos em papel - não há a necessidade de
conhecimento de nenhuma "ferramenta" especial
 O foco das discussões de protótipos em papel com os usuários é a estrutura da aplicação e da
sua adequação às tarefas a serem implementadas
 Discussões sobre preferências de interface ou de como será o comportamento das
funcionalidades a serem implementadas podem ser evitadas
 Menos tempo é gasto com argumentações
 A barreira da tecnologia é eliminada
 Não existem barreiras impostas aos usuários quanto à fazerem críticas ao protótipo porque,
obviamente, ele é de natureza temporária
 Menos esforço investido a ser defendido
 Melhorias são feitas mais rapidamente antes de investir esforço em codificação de programas
 Redução do tempo de desenvolvimento
 Redução dos custos de desenvolvimento
 Resulta na implementação de um sistema que, efetivamente, atinge os objetivos estabelecidos
pelos usuários.
 Resulta em grande satisfação por parte dos usuários

Questões a Serem Consideradas:

 Prototipação deve ser utilizada apenas quando os usuários podem participar ativamente no
projeto
 Não descuidar de uma boa análise que deve ser conduzida durante todo o processo de
prototipação
 Esclarecer aos usuários que o desempenho apresentado pelo protótipo não necessariamente
será o mesmo do sistema final
 Evitar que o sistema final seja um protótipo em que foram implementados todos os requisitos
especificados, pois se corre o risco de ter-se um sistema mal implementado, uma vez que as
técnicas utilizadas para desenvolver um protótipo são diferentes daquelas utilizadas na
implementação de um sistema (relaxamento de regras de negócio, manipulação de exceções
etc).
 Durante a etapa de prototipação, documentar todos os pontos levantados e implementados no
protótipo, que não constavam dos requisitos iniciais, para incluí-los na documentação final.

Devido à utilização de prototipação conduzir a um incremento substancial na qualidade e na quantidade

de comunicação entre os desenvolvedores/analistas e os usuários finais, seu emprego tem se tornado
bastante difundido. No início da década de 80, as empresas utilizavam aproximadamente 30% do tempo
total dos projetos de desenvolvimento em prototipação. No início da década de 90, sua utilização dobrou
para 60%.

Apesar de haverem algumas diretrizes para determinar quando utilizar prototipação de software, dois
especialistas acreditaram que algumas regras estabelecidas eram nada mais do que conjecturas. No
artigo "An Investigation of Guidelines for Selecting a Prototyping Strategy", Bill C. Hardgrave e Rick L.
Wilson comparam as diretrizes para prototipação que constam na literatura sobre sistemas de
informação com seu uso efetivo por empresas que desenvolveram protótipos.

Hardgrave e Wilson enviaram 500 pesquisas sobre utilização de prototipação para gerentes de sistemas
de todos os Estados Unidos (EUA). As empresas representadas pertenciam a várias industrias,
Página 20 de 40
segmentos de mercado e ramos - educação, serviços de saúde, instituições financeiras, transporte,
varejo, seguradoras, governamentais, manufatureiras e serviços.

Resultados utilizáveis da pesquisa foram recebidos de 88 empresas, representando 118 projetos

diferentes. Hardgrave e Wilson queriam descobrir quantas das diretrizes mais populares descritas na
literatura especializada foram efetivamente usadas pelas empresas, e se isto afetou o sucesso na
implementação dos sistemas (medido pelo nível de satisfação apresentado pelos usuários). Deve ser
notado que, apesar de não ter sido especificamente colocado, o estudo se baseou na utilização de
modelos feitos com software "high tech", e não protótipos "low tech" esquemáticos em papel.

Baseado nos resultados de sua pesquisa, Hardgrave e Wilson descobriram que as empresas seguiam
apenas seis das dezesseis diretrizes recomendadas na literatura sobre sistemas de informação.
As diretrizes seguidas pelas empresas cujo emprego foi determinante como tendo um efeito estatístico
no sucesso dos sistemas foram:
Prototipação deve ser utilizada apenas quando os usuários podem participar ativamente no projeto Os
desenvolvedores devem ter experiência em prototipação ou treinamento adequado
Os usuários envolvidos no projeto devem ter experiência em prototipação ou serem educados no seu
uso e finalidade
Os protótipos devem se tornar parte integrante do sistema final apenas se os desenvolvedores tiverem
acesso às ferramentas de suporte à prototipação
Se os processos de experimentação e aprendizado são necessários, antes que exista um compromisso
completo com um projeto, a prototipação pode ser utilizada com sucesso.
A prototipação não é necessária se o desenvolvedor já está familiarizado com a linguagem a ser utilizada
no projeto do sistema

Ao invés de prototipação com a utilização de softwares especializados, vários consultores de sistemas

de informação e pesquisadores recomendam ferramentas de prototipação "low tech" (esquemas simples
em papel ou softwares onde os usuários podem colar controles e objetos - tipo ferramentas RAD),
especificamente para a análise e projeto iniciais do sistema. A abordagem dos esquemas em papel
possibilita a ambos os projetistas e usuários a, literalmente, cortar e colar a interface do sistema.
Controles e objetos de comando podem ser facilmente e rapidamente movidos para adequar-se às
necessidades dos usuários.

Dentre os seus muitos benefícios, esta abordagem reduz o custo e o tempo envolvidos no processo de
prototipação, permitindo mais iterações, dando aos desenvolvedores a oportunidade de obter feedback
imediato dos usuários no refinamento do design. Isto elimina definitivamente muitas das desvantagens
da prototipação, pois os protótipos em papel são baratos de criar, diminuindo a probabilidade dos
desenvolvedores se tornarem dependentes de seu trabalho e dos usuários alimentarem expectativas
quanto ao desempenho do sistema.

Deve ser ressaltado que os maiores benefícios da utilização de prototipação é dar aos usuários e
desenvolvedores a noção exata do sistema que deverá ser desenvolvido, estabelecer uma linguagem
comum a ser utilizada na comunicação entre eles, incentivar a interação durante todo o processo, desde
a elaboração inicial do protótipo até o desenvolvimento final do sistema, decorrendo daí um sistema
completo, útil, de fácil utilização, indo de encontro às espectativas dos usuários que, portanto,
apresentarão grande satisfação com o resultado final.
James Martin, pai do "Computer Aided Software Engineering" (CASE), e o cérebro por trás do "Rapid
Application Development (RAD)", escreveu:
"Rapid Application Development (RAD) is a development lifecycle designed to give much faster
development and higher-quality results than those achieved with the traditional lifecycle. It is designed to
take the maximum advantage of powerful development software that has evolved recently."

"Desenvolvimento Rápido de Aplicações (RAD) é um ciclo de desenvolvimento projetado para dar

resultados de desenvolvimento muito mais rápido e de alta qualidade que aqueles obtidos através dos
ciclos tradicionais. Ele é projetado para tirar o máximo proveito dos poderosos softwares de
desenvolvimento que evoluíram recentemente”.

Página 21 de 40
Indexação:

 Organização heap File (ou Pipe file): Utilizado em arquivos de registro desordenados.
Funciona como pilha, necessita reorganização devido às exclusões de registros e necessita de
classificação externa.
 Arquivos de registros ordenados: Possui um campo de classificação (campo-chave). Uma
pesquisa binária pode ser feita com base em blocos em vez de registros. A pesquisa vai ao meio
da lista de busca e vai quebrando ao meio, busca pra cima ou pra baixo dependendo do valor, e
assim vai quebrando ao meio até achar o registro procurado.
 Técnicas de Hashing: Necessita campo único (chave)
o Hashing Interno: Normalmente implementado por uma tabela hash, por meio de um
vetor de registros.
o Hashing Externo: Hashing para arquivos em disco é constituído de buckets (baldes),
onde existe uma tabela com os endereços de blocos de disco.

 Técnicas hashing com expansão de arquivos dinâmicos:

o Hashing extensível: Onde os buckeds são espécies de diretórios onde os índices são
separados pelos primeiros dígitos binários de seu número inteiro positivo.
o Hashing Linear: não usa diretório.

Os tipos de índice mais predominantes são baseados em arquivos ordenados (índices em nível
único) e estruturas de dados de árvores (índices multiníveis, árvores –B). Eles também podem ser
construídos em hashing ou em outras estruturas de busca de dados.

Tipos de índices:
 Primário – Arquivo ordenado, possui um espelho do campo chave (chamado Chave primária) e
um ponteiro para o bloco do registro.
o Registro âncora – Primeiro registro do bloco
o Índice denso – Possui ponteiro para cada registro
o Índice esparso – Ponteiros apenas para os registros âncoras

 Clustering (Agrupamento) – Não possui campo chave, nem valor distinto para os registros.
Funciona como um índice esparso, apontando para cada agrupamento de registros
semelhantes.
 Secundário – Contém ponteiros para outros registros, únicos ou não. Utiliza índice denso e com
pesquisa binária nas entradas.
 Multiníveis – Seu objetivo é o de reduzir o tempo em relação à busca binária. Funciona com um
primeiro nível de blocos de índices ordenados, e um segundo nível (índice primário para o
primeiro nível) que aponta para as ancoras do primeiro nível. Se a tabela for muito grande pode-
se gerar um terceiro nível para controlar os segundos níveis, e assim sucessivamente. O número
de ponteiros em um nó é chamado de fanout do nó, e vão de n/2 a n.
 Arvores-B – Uma extensão dos múltiníveis, onde os nós sofrem balanceamento, de forma a
garantir que os registros procurados passarão sempre pelo mesmo número de níveis. Os
ponteiros para os registros originais podem estar em qualquer nó, em qualquer nível.
 Arvores-B+ - Os ponteiros para os registros originais só se encontram nos nós folhas no último
nível da árvore. Por isso a estrutura deles difere dos nós internos.
 Bitmap – Semelhante ao B-tree, porém em cada folha ele contém uma seqüência de bits. Ele é
ideal para situações de baixa cardinalidade em grandes tabelas.

Página 22 de 40
Processamento de transações

O controle de concorrência é necessário para evitar problemas como: Atualização perdida, Atualização
temporária (Dirty read), sumário incorreto e leitura sem repetição.
Estados da transação e operações adicionais:
 Begin_transaction: Inicio da execução da transação.
 Read ou Write: Operações de leitura e escrita em itens de banco de dados, que são executadas
como parte da transação, são registrados no log.
 End_transaction: Estado de efetivação parcial, fim da execução de transação checa se a
transação pode ser aplicada ao banco de dados. O log é gravado em disco, para garantir
recuperação em caso de falha.
 Commit_transaction: Afirma que as alterações podem ser seguramente efetivadas e não
desfeitas. Ocorre a gravação em disco. Grava um registro de efetivação no log.
 Rollback: Término sem sucesso.

Propriedades ACID

 Atomicidade: Ou ela é executada inteira ou não será de modo algum.

 Consistência: Manter o Banco de dados em estado consistente.
 Isolamento: Deve ser executada isolada das demais, sem interferências.
 Durabilidade ou permanência: As mudanças não devem ser perdidas em razão de falhas.

Características das transações SQL (SET TRANSACTION)

 Modo de acesso: Read Only, Read Write (Padrão);
 Tamanho da área de isolamento: DIAGNOSTIC SIZE n – nº de condições que podem ser
manipuladas simultaneamente na área de diagnóstico;
 Nível de isolamento (ISOLATION LEVEL): READ UNCOMMITED (leitura não efetiva), READ
COMMITED (leitura efetiva), REPEATABLE READ (leitura repetível) ou SERIALIZABLE
(serializável) (padrão).

Tipos de Bloqueios
 Binários – Pode ter dois estados ou valores: bloqueado ou desbloqueado.
 Compartilhados/Exclusivos (Leitura/Escrita) – Também chamado de bloqueio de múltiplo-
modo, há três operações de bloqueio:
o read_locked(X) – Bloqueado-compartilhado (shared-locked) – permite que outras
transações leiam o item.
o write_locked(X) – bloqueado-exclusivo (exclusive-locked) – totalmente bloqueado para
leitura e escrita
o unlocked(X) - Desbloqueado

Cada registro na tabela de bloqueio terá quatro campos: <nome do item de dado,
LOCK,num_de_leituras, transações_bloqueio>.
Conversão de bloqueio – Promoção quando gera uma operação write_lock(X) ou
rebaixamento de bloqueio para uma operação read_lock(X).
 Protocolo de bloqueio em duas fases (2PL) – básico,estrito, conservador e rigoroso, sendo que
estrita e rigorosa são as mais comuns por causa de suas propriedades de recuperação, que são
melhores.

Técnicas para tratar o problema de deadlock

 Timeouts (limites de tempo)
 Detecção de deadlock (grafos espera-por)

Bloqueios de intenção
Granularidade do item de dados:
 Fina – para tamanhos pequenos de item.
 Grossa – para tamanhos grandes de item.
Página 23 de 40
A idéia subjacente nos bloqueios de intenção é que a transação indique, ao longo do caminho da raiz ao
nó desejado, qual o tipo de bloqueio (compartilhado ou exclusivo) ela irá solicitar de um dos
descendentes do nó. Há três tipos de bloqueio de intenção:
1. Intenção compartilhada (IS) indica que bloqueio(s) compartilhado(s) será(ao) solicitados em
algum nó descendente.
2. Intenção exclusiva (IX) indica que bloqueio exclusivo será solicitado em algum nó descendente.
3. Intenção compartilhada exclusiva (SIX) indica que o nó corrente está bloqueado em modo
compartilhado, mas bloqueio exclusivo será solicitado em algum nó descendente.

Matriz de compatibilidade de bloqueio para bloqueio de granularidade múltipla.

Travas DML e DDL

Todas as instruções DML requerem pelo menos duas travas: uma exclusiva sobre cada linha afetada e
uma compartilhada sobre a tabela que contém a linha. A trava exclusiva impede que outra sessão
interfira com a linha, e a trava compartilhada impede que outra sessão modifique a definição da tabela
com uma instrução DDL. Essas travas são requisitadas automaticamente. Se uma instrução DML não
puder adquirir as travas exclusivas sobre as linhas de que precisa, então a instrução esperará até que as
obtenha.
A execução de comandos DDL requer uma trava exclusiva sobre o objeto em questão. Ela não pode ser
obtida até que todas as transações DML na tabela tenham finalizado, liberando assim tanto as suas
travas exclusivas sobre linhas quanto as suas travas compartilhadas sobre tabelas. A trava exclusiva
requerida por qualquer instrução DDL é requisitada automaticamente, mas, se não puder ser obtida –
normalmente devido a uma outra sessão já ter a trava compartilhada concedida para a DML - , então a
instrução terminará imediatamente com um erro.
A trava é mantida até que a transação se complete, ou com um COMMIT ou com um ROLLBACK.

Mecanismo de enfileiramento
Os pedidos por travas são postos em fila, quando a sessão que tem a trava libera-la, a sessão seguinte
a receberá e assim por diante.

Disputa por travas

Um problema comum é o das leituras repetíveis. Quando a tabela é lida duas vezes na mesma
transação e entre uma e outra houve alterações de registros. Uma forma mais sofisticada seria usar a
instrução SET TRANSACTION READ ONLY. Ela garantirá (sem impor travas) que a sessão não veja
nenhum DML executado em nenhuma tabela, escritos ou não em disco, até terminar a transação de
somente leitura com um COMMIT ou ROLLBACK.

Página 24 de 40
Página 25 de 40
Técnicas de recuperação de banco de dados
A bufferização consiste em controlar a troca de páginas entre a memória e o disco, a isso se chama
“flush” ou substituição, com exceção das páginas com flag pi-unpin setado para 1(pinned).

Terminologia
 Entrada de log do tipo REDO inclui o novo valor (AFIM).
 Entrada de log do tipo UNDO incluem o valor antigo (BFIM).
 Se uma página em cache atualizada por uma transação não puder ser gravada antes que a
transação se efetive, ela será chamada de abordagem não-roubada (no-steal). O bit de pin-
unpin indicará se a página não puder ser escrita de volta no disco. Do contrário, se o protocolo
permitir o buffer atualizado antes que a transação se efetive, ele será chamado roubado (steal).
Steal será usado quando o gerenciador do cachê (buffer) do SGBD necessitar de um frame de
buffer para outra transação, e o gerenciador do buffer substituir uma página existente que tenha
sido atualizada, mas cuja transação não tenha se efetivado.
 Se todas as páginas atualizadas por uma transação forem imediatamente escritas no disco
quando a transação se efetivar, ela será chamada abordagem forçada (force). Do contrário,
será chamada não- forçada (no-force).

Protocolo de registro adiantado (write-ahead logging – WAL)

 A imagem anterior de um item não pode ser sobrescrita por sua imagem posterior no banco de
dados do disco; até que se registre todo log de tipo UNDO para transações atualizadas – acima
desse ponto - , seria uma gravação forçada (force-written) no disco.
 A operação de efetivação (commit) de uma transação não poderá ser completada até que se
registre todo log de tipo REDO e UNDO para que essa transação seja de gravação forçada
(force-written) no disco.

Um registro [checkpoint] é escrito periodicamente dentro do log, no ponto em que o sistema grava no
banco de dados no disco todos os buffers do SGBD que tiverem sido modificados.
Fuzzy checkipointing – Nesta técnica, o sistema poderá reassumir o processamento das transações
depois que o registro [checkpoint] for escrito no log, sem ter de esperar a gravação do buffer em disco.
Entretanto, até que ocorra essa gravação, o registro [checkpoint] anterior permanecerá válido.

Se algum valor de item de dados tiver sido alterado pela transação e gravado no banco de dados, ele
deverá ser restaurado aos seus valores anteriores (BFIM). As entradas de log do tipo desfazer (UNDO)
são usadas para restaurar os valores antigos dos itens de dado que deverão ser revertidos. Esse
fenômeno é chamado reversão em cascata (cascading rollback).

Atualização Adiada
Protocolo típico de atualização adiada pode ser caracterizado como uma abordagem não-roubada (no-
steal):
1. Uma transação não pode mudar o banco de dados em disco até que ela alcance seu ponto de
efetivação.
2. Uma transação não alcança seu ponto de efetivação até que todas as suas operações de
atualização sejam registradas no log e até que seja forçada a gravação do log no disco.

Atualização Imediata
Nessas técnicas, quando uma transação emite um comando de atualização, o banco de dados pode ser
imediatamente atualizado, sem nenhuma necessidade de esperar que a transação alcance seu ponto de
efetivação. Entretanto, uma operação de atualização deve, ainda assim, ser registrada no log (em disco)
antes de sua aplicação no banco de dados – usando o protocolo registro adiantado em log (write-ahead
logging) -, de tal forma que possamos recuperá-los em caso de falha.

Se as técnicas de recuperação garantirem que todas as atualizações de uma transação sejam

registradas no banco de dados em disco antes de a transação se efetivar, nunca haverá necessidade de
REFAZER quaisquer operações das transações efetivas. Este é chamado algoritmo de recuperação
UNDO/NO-REDO. Por outro lado, se for permitido à transação se efetivar antes que todas as suas
mudanças sejam escritas no banco de dados, temos o caso mais geral, conhecido por algoritmo de
recuperação UNDO/REDO.

Página 26 de 40
Paginação Shadow (Sombra)
Considera que o banco de dados é composto por um número de páginas de tamanho fixo (ou blocos de
disco). Quando se inicia uma transação, o catálogo corrente é copiado em um catálogo shadow. O
catálogo shadow é, então, salvo em disco, enquanto o catálogo corrente é usado pela transação.

Algoritmo de recuperação ARIES

ARIES usa uma abordagem roubada/não forçada (steal/no-force) para gravação e está baseado em três
conceitos:
1. Registro adiantado de log (write-ahead logging)
2. Repetição de histórico durante o refazer – significa que ele relê todas as ações tomadas pelo
sistema de banco de dados antes da queda para reconstruir seu estado quando a queda
ocorreu. Transações que não foram efetivadas em tempo de queda (transações ativas) são
desfeitas.
3. Mudanças do log durante o desfazer – evitará que o ARIES torne a desfazer operações já
desfeitas, caso ocorra uma falha durante a recuperação, com conseqüente reinício do processo
de recuperação.

O procedimento de recuperação ARIES consiste em três passos principais:

1. Análise – Identifica as páginas lixo (atualizadas) no buffer e o conjunto das transações ativas no
momento da queda.
2. REDO – Geralmente, a operação de REDO é aplicada apenas às transações efetivadas.
Entretanto, no ARIES, esse não é o caso. Informações armazenadas pelo ARIES e pelas
páginas de dados permitirão ao ARIES determinar se a operação a ser refeita foi, de fato,
aplicada ao banco de dados, assim, não precisará ser reaplicada.
3. UNDO – o log será seguido de trás para frente, e as operações das transações que foram
ativadas em tempo de queda serão desfeitas na seqüência contrária. As informações
necessárias para que o ARIES execute seu procedimento de recuperação compreendem o log, a
Tabela de Transações e a Tabela de Páginas Lixo.

Página 27 de 40
Banco de dados de objetos

Identidade de Objeto
Um sistema de banco de dados OO fornece uma identidade única para cada objeto independente
armazenado no banco de dados. Essa identidade única é geralmente implementada por meio de um
identificador de objeto único gerado pelo sistema (OID).

Estrutura de Objeto (Tipo)

Construtores  Atom (atômico) – Inteiros, cadeias de caracteres...

básicos  Tuple (tupla) – Conhecido como tipo Estruturado (struct)
 Set (conjunto) – Elementos distintos
Tipos coleção  Bag – Elementos Não distintos
(Tipos  List – Tamanho infinito
empilhados)  Array – Tamanho limitadoContagem finita

Encapsulamento de operações, Métodos e persistência.

O conceito de encapsulamento é uma das principais características das linguagens e dos sistemas OO.
Ele está relacionado também com os conceitos de tipos abstratos de dados e ocultar a informação nas
linguagens de programação. A idéia principal é definir o comportamento de um tipo de objeto com base
nas operações que podem ser externamente aplicadas aos objetos daquele tipo.
Na terminologia OO, a parte de interface de cada operação é chamada assinatura, enquanto a
implementação da operação é chamada método.

Na figura a seguir, é mostrado como podem ser declarados os tipos Empregado e Departamento, e
como as definições de tipos podem ser estendidas com as operações para definir as classes.

Os objetos transientes existem na execução do programa e desaparecem quando o programa termina.

Os objetos persistentes são armazenados no banco de dados e persistem após o término do
programa.Os mecanismos usuais para tornar um objeto persistente são a nomeação e a alcançabilidade
 O mecanismo de nomeação consiste em dar a um objeto um nome persistente único pelo qual
ele possa ser recuperado pelo programa em execução e outros programas.
 Alcançabilidade – Este mecanismo torna o objeto alcançável a partir de algum objeto persistente.
Um objeto B é dito alcançável a partir de um objeto A se uma seqüência de referências no grafo
conduz, a partir do objeto A, ao objeto B.
Página 28 de 40
Objetos complexos não estruturados e extensibilidade de tipo
 Objetos complexos não estruturados são conhecidos como binary large objects (objetos binários
extensos) ou BLOBs. Cadeias de caracteres também são conhecidas como objetos de textos
extensos (character large objects) ou CLOBs.
 Tipos extensíveis – tipos criados a partir de definições de estruturas e operações.
 Objeto complexo estruturado – a estrutura do objeto é definida e conhecida pelo SGBDOO.

Conceitos orientados a objetos

 Polimorfismo – Conhecido como sobrecarga de operador. Este conceito permite que o mesmo
nome de operador ou símbolo seja associado a duas ou mais implementações diferentes para o
operador, dependendo do tipo de objetos aos quais o operador é aplicado.
 Herança múltipla – ocorre quando um subtipo T é subtipo de dois (ou mais) tipos e, assim, herda
as funções (atributos e métodos) de ambos os supertipos. Na herança seletiva (clausula
EXCEPT) apenas algumas funções são herdadas.

Visão geral do modelo de objetos ODMG

É um modelo de dados no qual se baseiam a linguagem de definição de objetos (ODL) e a linguagem de

consulta a objetos (OQL).

Objetos e literais são os blocos de construção básicos do modelo de objetos. A principal diferença entre
os dois é que um objeto possui um identificador do objeto e um estado (ou valor atual), enquanto um
literal possui somente um valor, mas não identificador do objeto.

Um objeto é descrito por quatro características:

1. Identificador – ou Object_Id
2. Nome – alguns objetos podem opcionalmente receber um nome único.
3. Tempo de vida – especifica se ele é persistente ou transiente.
4. Estrutura – como ele é construído pelos construtores de tipos.

Um Literal existem três tipos:

1. Atômico – valores básicos
2. Coleção – Set <T>, Bag <T>, List <T>e Array <T>, em que T é o tipo de objetosou valores de
coleção.
3. Estruturado – valores construídos (struct) e estruturas embutidas (Date, Interval, Time,
timestamp)

Página 29 de 40
Bancos de dados distribuídos e arquiteturas Cliente-Servidor

Banco de dados distribuído (BDD) – Coleção de múltiplos banco de dados logicamente inter-
relacionados distribuídos por uma rede de computadores.

Sistema de gerenciamento de banco de dados distribuído (SGBDD) – Sistema de software que

gerencia um banco de dados distribuído enquanto torna a distribuição transparente para o usuário.

Tecnologias Paralela e Distribuída

Para arquiteturas de sistema paralelo, existem dois tipos principais de arquiteturas de sistema multi-
processador que são comuns:
 Arquitetura de memória compartilhada (fortemente acoplada): Múltiplos processadores
compartilham armazenamento secundário (disco) e também memória primária.
 Arquitetura de disco compartilhada (fracamente acoplada): Os múltiplos processadores
compartilham armazenamento secundário (disco), mas cada um possui sua própria memória
primária.

Os sistemas de gerenciamento de banco de dados desenvolvidos utilizando esses tipos de arquiteturas

são chamados sistemas paralelos de gerenciamento de banco de dados em vez de SGBDD, uma
vez que utilizam a tecnologia de processador paralelo.

Na Arquitetura nada compartilhada, não existe memória comum, e os processadores se comunicam

por meio de uma rede de interconexão de alta velocidade.
Nos sistemas multiprocessadores nada compartilhados, há simetria e homogeneidade de nodos; isso
não é verdade no ambiente de banco de dados distribuído, no qual a heterogeneidade de hardware e de
sistema operacional em cada nodo é muito comum. A arquitetura nada compartilhada também é
considerada como um ambiente para bancos de dados paralelos.

Vantagens dos bancos de dados distribuídos

1. Gerenciamento de dados distribuídos com níveis diferentes de transparência:
 Transparência de distribuição ou de rede
 Transparência de replicação
 Transparência de fragmentação:
o Fragmentação horizontal – Linhas
o Fragmentação vertical - Colunas
2. Melhoria na confiabilidade e na disponibilidade
3. Melhoria de desempenho
4. Expansão mais fácil

Tipos de sistemas de banco de dados distribuídos

Grau de homogeneidade do software do SGBDD:
 Homogêneo – Todos os servidores (ou SGBDs locais individuais) usam um software idêntico e
todos os usuários (clientes) usam um software idêntico.
 Heterogêneo – caso contrário

Grau de autonomia local – Se não há nenhuma provisão para o site local funcionar como um SGBD
stand-alone, então o sistema não possui autonomia local. Por outro lado, se for permitido o acesso direto
ao servidor para transações locais, o sistema possui algum grau de autonomia local.

Sistema de banco de dados federado (SBDF) – Nesse tipo de sistema, cada servidor é um SGBD
centralizado independente e autônomo que tem seus próprios usuários locais, transações locais e DBA
e, conseqüentemente, possui um grau muito alto de autonomia local.

Principais tipos de heterogeneidade em SBDF:

 Diferenças nos modelos de dados
 Diferenças em restrições
 Diferenças nas linguagens de consulta: SQL89, SQL92 e o SQL99.
 Heterogeneidade Semântica: Nomenclaturas, restrições, derivação de sumários, etc.

Página 30 de 40
Processamento de consulta distribuída usando semijunção (semijoin)
A idéia oculta no processamento de consulta distribuída utilizando a operação semijunção é reduzir o
número de tuplas em uma relação antes de transferi-la para outro site. Ou seja, em vez de transferir uma
tabela inteira para outro site, o SGBDD transfere apenas as colunas contidas nas operações join para
um dos sites, faz o processamento e retorna apenas os resultados para o site que solicitou a busca.

Controle de concorrência distribuída com base em uma cópia distinta de um item de dados
Técnicas no contexto de estender o bloqueio centralizado
 Técnica de Site primário – Nesse método um único site primário é designado para ser o site
coordenador para todos os itens do banco de dados. Conseqüentemente, todos os bloqueios
são mantidos naquele site, e todos os pedidos de bloqueio e desbloqueio são enviados para lá.
Assim, esse método é uma extensão da abordagem de bloqueio centralizado.
 Site Primário com site de backup – designa um segundo site para ser um site de backup, no
caso de falha do site primário, o site de backup assume como site primário.
 Técnica da cópia primária – Esse método tenta distribuir a carga de coordenação de bloqueio
entre vários sites tendo cópias distintas de diferentes itens de dados armazenados em sites
diferentes. A falha de um site afeta todas as transações que estão acessando bloqueios para
itens cujas cópias primárias residam naquele site, mas outras transações não são afetadas.
 Escolha de um novo site coordenador em caso de falha – Sempre que um site coordenador
falhar em quaisquer das técnicas anteriores, os sites que ainda estão em operação precisam
escolher um novo coordenador.
 Método de votação – não há cópia distinta; em vez disso, uma solicitação de bloqueio é enviada
para todos os sites que possuem uma cópia do item de dados. Cada cópia mantém seu próprio
bloqueio e pode conceder ou negar a solicitação para bloqueios. Se para uma transação que
solicitar um bloqueio for concedido o bloqueio pela maioria das cópias, ela mantém o bloqueio e
informa a todas as cópias que lhe foi concedido o bloqueio. Se uma transação não receber a
maioria dos votos que lhe concedam um bloqueio dentro de um certo período de time-out, ela
cancela sua solicitação e informa a todos os sites do cancelamento.
O método de votação é considerado um método de controle de concorrência verdadeiramente
distribuído, pois a responsabilidade por uma decisão reside em todos os sites envolvidos.
Estudos de simulação têm mostrado que a votação tem um tráfego maior de mensagens entre os
sites que os métodos de cópia distinta. Se o algoritmo levar em consideração as possíveis falhas
de sites durante o processo de votação, ele se torna extremamente complexo.

Recuperação distribuída
O protocolo commit de duas fases freqüentemente é usado para assegurar a correção do commit
distribuído. Utilizado no Oracle.
Protocolo de efetivação em duas fases:
 Fase 1: Quando todos os bancos de dados participantes sinalizarem ao coordenador que sua
parte da transação multibanco foi concluída, o coordenador envia uma mensagem ‘preparar para
efetivar’ a fim de preparar cada participante para efetivação da transação. Cada banco de dados
participante que receber essa mensagem forçará a gravação de todos os registros em log, bem
como informações necessárias para a recuperação local para o disco e, então, enviará um sinal
de ‘pronto para efetivar’ ou ‘Ok’ ao coordenador. Se a gravação forçada no disco falhar, ou se a
transação local não puder ser efetivada por alguma razão, o banco de dados participante envia
um sinal ‘não pode efetivar’ ou ‘não Ok’ ao coordenador. Se o coordenador não receber uma
resposta de um dos bancos de dados dentro de um certo intervalo de tempo, ele assumirá um
‘não Ok’ como resposta.
 Fase 2: Se todos os bancos de dados participantes responderem ‘Ok’ e o voto do coordenador
também for um ‘Ok’, a transação será bem sucedida, e o coordenador envia um sinal ‘efetivar’
para a transação dos bancos de dados participantes. Como todos os efeitos locais da transação
e as informações necessárias para recuperação local foram registrados nos logs dos bancos de
dados participantes, a recuperação a falhas é possível. Cada banco de dados participante
completa a efetivação da transação escrevendo uma entrada [efetivar] para a transação no log e,
se necessário, atualizando permanentemente o banco de dados. De outro modo, se um ou mais
dos bancos de dados participantes, ou se o coordenador optar por um ‘não Ok’ como resposta, a
transação falhará e o coordenador enviará uma mensagem para ‘reverter’ ou desfazer o efeito

Página 31 de 40
 local da transação para cada banco de dados participante. Esse procedimento é feito
desfazendo as operações de transação por meio do log.

Arquitetura cliente servidor three-tier (três camadas)

1. Camada de apresentação (cliente): Esta provê a interface do usuário e interage com ele.
2. Camada de aplicação (lógica empresarial): Essa camada programa a lógica de aplicação, pode
interagir com um ou mais bancos de dados por meio de conexão utilizando ODBC, JDBC,
SQL/CLI ou outras técnicas de acesso a banco de dados. É responsável pela geração de um
plano de execução distribuído para uma consulta ou transação de múltiplos sites e pela
supervisão da execução distribuída por meio do envio de comandos para os servidores. Outra
função é a de assegurar a consistência das cópias replicadas de um item de dados por meio do
emprego de técnicas de controle de concorrência distribuída (ou global). Também precisa
assegurar a atomicidade das transações globais por meio da execução da recuperação global
quando certos sites falharem.
3. Servidor de banco de dados: Essa camada manipula as solicitações de consulta e de
atualização na camada de aplicação, processa as solicitações e envia os resultados.

Banco de dados distribuídos no Oracle

O Oracle provê suporte a links de banco de dados que definem um caminho de comunicação de uma só
via de um banco de dados Oracle para um outro.
Por exemplo: CREATE DATABASE LINK vendas.us.américas;

Os dados em um SBDD Oracle podem ser replicados usando snapshots (instantâneos) ou tabelas
mestras replicadas. A replicação é proporcionada nos seguintes níveis:
 Replicação básica: Réplicas das tabelas são gerenciadas para acesso somente de leitura. Para
as atualizações, os dados precisam ser acessados em um único site primário.
 Replicação avançada (simétrica): estende-se para além da replicação básica permitindo que as
aplicações atualizem réplicas de tabelas ao longo de um SBDD replicado. Os dados podem ser
lidos e atualizados em qualquer site. Isso exige um software adicional chamado opção de
replicação avançada do Oracle. Um snapshot (instantâneo) gera uma cópia de uma parte da
tabela por meio de uma consulta chamada consulta de definição de snapshot. Uma definição
simples de snapshot se parece com isto:
CREATE SNAPSOT vendas.pedidos AS
SELECT * FROM vendas.pedidos@sd.us.americas;

O Oracle agrupa os snapshots em grupos de refresh (atualização). Por meio da especificação de um

intervalo de refresh, o snapshot é atualizado de maneira automática periodicamente, naquele intervalo,
por até dez snapshot refresh processes (SNPs – processos de atualização de snapshot). Se a consulta
que define um snapshot contém uma função distinta ou de agregação, uma cláusula GROUP BY ou
CONNECT BY, ou operações de junção ou de conjuntos, o snapshot é chamado snapshot complexo e
requer processamento adicional.
Bancos de dados Heterogêneos em Oracle – Em um SBDD heterogêneo, pelo menos um banco de
dados é um sistema que não é Oracle (não Oracle).

Página 32 de 40
XML e banco de dados na Internet
XML (Extended Markup Language – Linguagem estendida de marcação)

E dados semi-estruturados, a informação de esquema está misturada com valores dos dados, uma vez
que cada objeto de dados pode ter atributos diferentes que não são conhecidos com antecedência. Por
isso, esse tipo de dados às vezes é chamado dado autodescritivo. Considere o seguinte exemplo.
Queremos coletar uma lista de referências bibliográficas referentes a um certo projeto de pesquisa.
Algumas dessas referências podem ser livros ou relatórios técnicos, outras podem ser artigos de
pesquisa em revistas científicas ou em anais de conferências, outras ainda podem referir-se a edições
completas de revistas científicas ou de anais de conferências. A imagem a seguir mostra dados semi-
estruturados como um grafo direcionado.

Existem duas diferenças principais entre o modelo semi-estruturado e o modelo de objetos

1. A informação do esquema – nomes de atributos, relacionamentos e classes (tipos de objetos) no
modelo semi-estruturado é misturada com os objetos e seus valores de dados na mesma
estrutura de dados.
2. No modelo semi-estruturado, não há nenhuma exigência de um esquema predefinido para o qual
os objetos de dados precisam estar em conformidade.

O Modelo de dados Hierárquico (árvore) XML

Dois conceitos principais de estruturação são usados para construir um documento XML:
 Elementos – são identificados em um documento por seus tag de início e tag de fim.
o Elementos complexos são construídos hierarquicamente a partir de outros elementos.
o Elementos simples contêm valores de dados.
 Atributos – O s atributos em XML fornecem informações adicionais que descrevem elementos.

Página 33 de 40
O modelo XML é chamado modelo de árvore ou modelo hierárquico.

Normalmente, é possível caracterizar três tipos principais de documentos XML:

 Documentos XML centrados em dados (data-centric): Esses documentos possuem muitos itens
de dados pequenos que seguem uma estrutura específica e conseqüentemente podem ser
extraidos a partir de um banco de dados estruturado.
 Documentos XML centrados em documentos (document-centric): Estes são documentos com
grandes quantidades de texto, como artigos de jornais ou livros. Existem poucos, ou nenhum,
elementos de dados estruturados nesses documentos.
 Documentos XML híbridos: Esses documentos podem possuir partes que contêm dados
estruturados e outras partes que são predominantemente textuais ou não estruturados. São
conhecidos por documentos XML sem esquema (schemalles). Quando o valor do atributo
STANDALONE em um documento XML for ‘yes’, como na primeira linha da imagem anterior, o
documento é standalone (sozinho) e sem esquema.

Documentos XML bem formados e válidos e XML DTD

 Bem formado – deve começar com uma declaração XML para indicar a versão de XML utilizada
assim como quaisquer outros atributos pertinentes. Também deve seguir as diretrizes sintáticas
do modelo de árvore.

Página 34 de 40
  Válido – Nesse caso, o documento deve ser bem formado e, além disso, os nomes de elementos
usados nos pares de tags de iniício e de fim precisam seguir a estrutura especificada em um
arquivo XML DTD (Definição de Tipo de Documento) separado ou em um arquivo de esquema
XML como o da imagem a seguir.

Quando o valor do atributo standalone em um documento XML for ‘no’, o documento necessita
ser verificado em relação a um documento DTD separado. O problema é que muitos
processadores XML têm dificuldade de interpreta-lo.

 Esquema XML – A linguagem de esquema XML é um padrão para especificar a estrutura de

documentos XML. Ela usa as mesmas regras de sintaxe de documentos XML comuns, de forma
que os mesmos processadores podem ser usados para ambos.

Assim como o XML DTD, o esquema XML está baseado no modelo de dados de árvore, com elementos
e atributos como os conceitos principais de estruturação. Porém, ele toma emprestado alguns conceitos
adicionais de banco de dados e de modelos de objeto, tais como chaves, referências e identificadores.

Página 35 de 40
Página 36 de 40
Data Mining

O resultado da mineração visa informações novas:

 Regras de associação – por exemplo, se um cliente compra equipamentos de vídeo, ele pode
também comprar outros componentes eletrônicos.
 Padrões seqüenciais – por exemplo, suponha que um cliente compre uma câmera, e que dentro
de três meses ele compre materiais fotográficos, de forma que, dentro dos próximos seis meses,
ele deverá comprar um acessório.
 Árvores de classificação – por exemplo, clientes podem ser classificados por freqüência de
visitas, por tipo de financiamento utilizado, por quantidade comprada, ou por afinidade com
algum tipo de item, e algumas estatísticas reveladoras podem ser geradas para cada classe de
cliente.
 Padrões com séries temporais – Similaridades podem ser encontradas em posições de uma
série temporal de dados, que é uma seqüência de dados tomada a intervalor regulares, como
vendas diárias ou preço diário de fechamento de ações.
 Clustering (Agrupamento) – Uma dada população de eventos ou novos itens podem ser
particionados (segmentados) em conjunto de elementos ‘similares’.

Regras de Associação
Uma regra de associação é da forma X=>Y, essa associação estabelece que, se um cliente comprar X,
ele também estará propenso a comprar Y. LME (lado da mão esquerda) => LMD (lado da mão direita), é
chamado conjunto-item.

Para que uma regra de associação seja do interesse de um pesquisador de dados, a regra precisa
satisfazer algumas medidas. Duas medidas de interesse comuns fornecem suporte e confiança.
 Suporte – para uma regra LME=>LMD é com relação a ela própria. È o percentual de transações
que contém todos os itens na própria relação LME U LMD. Se o suporte é baixo, isso implica que
não existe nenhuma evidência significativa que os itens em LME U LMD ocorram juntos, dado
que o conjunto de itens ocorre em apenas uma pequena fração de transações.
 Confiança (força da regra) – da regra LME=>LMD é calculada como o suporte (LME U
LMD/suporte (LMD)).

Como um exemplo de suporte e confiança, considere as duas regras: Leite=>Suco e pão=>Suco.

Observando os quatro exemplos de transação na figura, vemos que o suporte de {Leite,Suco} é 50%, e o
suporte {Pão,Suco} é de somente 25%. A confiança de Leite=>Suco é 66,7% (significando que das
transações nas quais leite ocorre, duas contêm suco), e a confiança de Pão=>Suco é 50% (significando
que uma de cada duas transações contendo pão também contém suco).

Para reduzir o espaço de busca combinatória, os algoritmos para encontrar as regras de associação
utilizam as seguintes propriedades:
 Fechamento por baixo - Um subconjunto de um conjunto de itens grandes precisa também ser
grande (isto é, cada subconjunto de um conjunto de itens grande excede o suporte mínimo
exigido).
 Antimonotonicidade - Por reciprocidade, um superconjunto de um conjunto de itens pequeno é
também pequeno (implicando que ele não tem suporte suficiente).

Página 37 de 40
 Algoritmo Apriori
Foi o primeiro a usar as propriedades de fechamento por baixo e antimonotonicidade, possui três fases
principais:
1. Fase da geração dos candidatos
2. Fase da poda dos candidatos
3. Fase do cálculo do suporte (validação).

Página 38 de 40
Glossário

Fecho transitivo: significa que se existe uma linha em que A referencia B e uma linha em que B
referencia C, deve haver uma linha em que A referencia C. Em outros termos, a tabela deve conter, para
cada artigo, seu código seguido do código de cada um de seus artigos referenciados, seguido do código
de cada artigo referenciado pelos artigos referenciados e assim recursivamente.

Linguagem Procedural: A linguagem PL/SQL utiliza o conceito de bloco estruturado. Esses blocos são
compostos por procedures e funções. Um bloco tem a estrutura básica, como descrito na imagem logo
abaixo e ele é composto por três partes:
Declare - Seção opcional, em que todos
os objetos são declarados.
Begin - Em que os comandos PL/SQL
são colocados.
Exception - Em que os erros são tratados

Semântica x Sintaxe: A semântica (do grego σημαντικός, derivado de sema, sinal) refere-se ao estudo
do significado, em todos os sentidos do termo. A semântica opõe-se com freqüência à sintaxe, caso
em que a primeira se ocupa do que algo significa, enquanto a segunda se debruça sobre as estruturas
ou padrões formais do modo como esse algo é expresso (por exemplo, escritos ou falados).
Dependendo da concepção de significado que se tenha, tem-se diferentes semânticas. A semântica
formal, a semântica da enunciação ou argumentativa e a semântica cognitiva, por exemplo, estudam o
mesmo fenômeno, mas com conceitos e enfoques diferentes.

Sistema Gerenciador de Banco de Dados é o conjunto de programas de computador (softwares)

responsáveis pelo gerenciamento de uma base de dados. O principal objetivo é retirar da aplicação
cliente a responsabilidade de gerenciar o acesso, manipulação e organização dos dados. O SGBD
disponibiliza uma interface para que os seus clientes possam incluir alterar ou consultar dados. Em
bancos de dados relacionais a interface é constituída pelas APIs ou drivers do SGBD, que executam
comandos na linguagem SQL.

Algumas funções extremamente relevantes do SGBD

são:
 Interação com o sistema de arquivos do
sistema operacional.
 Cumprimento da integridade.
 Cumprimento da segurança.
 Cópias de segurança (“backup”) e
recuperação.
 Controle de concorrência.
 Otimização e execução dos comandos DML.
 Dicionário de Dados.
 Desempenho.

SQL Dinâmico: Um SQL Dinâmico é um comando SQL ou um bloco PL/SQL válido, codificado
dentro de uma string (populada em tempo de execução) e pode ser executado através do uso do
comando EXECUTE IMMEDIATE, a partir da versão 8i do banco de dados Oracle. Esse tipo de
comando SQL pode conter placeholders para bind (host) arguments. Um placeholder é um

Página 39 de 40
identificador não declarado, então o valor que lhe é atribuído substitui uma variável da
composição da sintaxe do comando, sendo que é preciso prefixar tal coluna com o símbolo: (dois
pontos).

Referências:

http://www.dct.ufms.br/~nalvo/teaching/modelagem/material/Cap4.pdf

http://pt.wikipedia.org/wiki/Sistema_de_gerenciamento_de_banco_de_dados

Sistemas de Banco de Dados – Abraham Silberschatz, Henry F. Korth, S. Sudarshan – Editora Makron
Books

Sistemas de Banco de Dados – Ramez Elmasri, Shamkant B. Navathe – Editora Pearson

Página 40 de 40