Banco_de_Dados_-_Livro

Prévia do material em texto

Programa de Mestrado em Ciência da Computação
Faculdade de Ciências Matemática, da Natureza e Tecnologia da Informação
Sistemas de
Banco de Dados
NOTAS DIDÁTICAS
PÓS-GRADUAÇÃO
Copyright © - Versão Ano 2003
Prof. Dr. Luiz Camolesi Jr.
Apresentação
Estas Notas Didáticas têm o objetivo de registrar alguns pontos importantes
na área de Banco de Dados e apresenta-los de forma clara e didática neste curso.
Existem dificuldades específicas quando se tenta abordar o tema, uma vez
que em informática nada é permanente ou imutável, estando sujeito a críticas e
alterações. Além disso, especificamente Banco de Dados é por si mesmo um campo
polêmico e controvertido em vários conceitos. Existem diversos grupos de
pesquisadores em todo o mundo (inclusive no Brasil) voltados a estudos sobre esta
área buscando inovações tecnológicas que tornem o armazenamento de informações
um valioso instrumento para auxiliar no crescimento dos indivíduos, das empresas e
da sociedade moderna.
Os complementos básicos desta notas didáticas são as anotações em aula, os
exercícios e as bibliografias adicionais (livros a artigos). Através destes, procuro
estimular o interesse, o acompanhamento evolutivo e a pesquisa desta importante e
primordial área da computação.
Finalmente, quero sugerir que você mantenha estas notas didáticas sempre
atualizadas, a fim de que elas se tornem, na medida do possível, uma referência mais
completa sobre o assunto, progressiva e permanentemente útil .
 Prof. Dr. Luiz Camolesi Jr.
Email: lcamoles@unimep.br
Site: www.unimep.br/~lcamoles
Bacharel em Ciência da Computação – ICMC / USP São Carlos
Mestre em Ciências [Área de Banco de Dados] – ICMC / USP São Carlos
Especialização em Eng. da Qualidade Industrial – FEM / UNICAMP Campinas
Doutor em Ciências [Área de Banco de Dados] – IFSC / USP São Carlos
Membro da SBC e ACM SIGMOD
Bibliografia
de Referência
Livros
“GENÉRICOS”
Fundamentals of Database Systems (ISBN 0-8053-1748-1)
Ramez Elmasri , Shamkant Navathe - Editora Benjamin/Cummings, - 1994 – 2ª Edição
 Sistemas de Bancos de Dados (ISBN 0-07-044754-3 - www.bell-labs.com/topic/books/db-book/ )
Henry F. Korth , Abraham Silberschatz– Editora Makron – 1997 – 3ª Edição
Database Management Systems ( www.cs.wisc.edu/coral/~dbbook )
Raghu Ramakrishnan – Editora MCB McGraw-Hill - 1998
! Introdução a Sistemas de Banco de Dados
C. J. Date – Editora Campus – 1990
! Banco de Dados
Chu Shao Yong – Editora Atlas – 1983
! Banco de Dados: Tópicos Avançados
C. J. Date – Editora Campus – 1989
! Database Design
Gio Wiederhold - Makron Books – 1983
! PeopleWare : Como Gerenciar Equipes e Projetos ....
Tom DeMarco , Timothy Lister – Editora Makron – 1987
! Information Systems Developement : A Database Approach
David Avison , Paul Golder , Hanifa Shah – Editora MacGraw-Hill – 1998 – 3ª Edição
PROJETO CONCEITUAL DE BANCOS DE DADOS
! A Abordagem do Modelo Entidade-Relacionamento
Peter Chen – Editora Makron - 1990
! DataBase Modeling & Design – The Fundamental Principles
Toby J. Teorey – Editora Morgan Kaufmann – 1994 – 2ª Edição
Conceptual Database Design: Na Entity-Relationship Approach (ISBN 0-8053-0244-1)
C. Batini , S. Ceri , S. H. Navathe – Editora Benjamin/Cummings – 1992
PROJETO LÓGICO DE BANCOS DE DADOS
! Relational Database Theory
Paolo Atzeni , Valeria Antonellis – Editora Benjamin/Cummings – 1993
! Fundamentals of Data Normalization
Alan F. Dutka , Howard H. Hanson – Editora Addison-Wesley – 1989
PROJETO FÍSICO DE BANCOS DE DADOS
! Organização de Banco de Dados
A . L. Furtado , C. S. dos Santos - Campus – 1987
! Design of Database Structures
Toby J. Teorey , James P. Fly – Editora Prentice-Hall – 1982
! File Structures: Theory and Practice
Panos E. Livadas – Editora Prentice-Hall – 1990
! File Structures: A conceptual Toolkits
Michael J. Folk , Bill Zoellick – Editora Benjamin/Cummings – 1992 – 2ª Edição
! Indexing Techniques for Advanced Database Systems (ISBN 0-7923-9985-4)
 Elisa Bertino, Beng Chin Ooi, et alli - Editora Kluwer Academic Publishers – 1997
! Indexing Data Structures in Object-Oriented Database (ISBN 0-7923-9971-4)
 Thomas A. Mueck, Martin L. Polaschek - Editora Kluwer Academic Publishers – 1997
! Advanced Database Indexing (ISBN 0-7923-7716-8)
 Yannis Manolopoulos, Yannis Theodoridis et alli - Editora Kluwer Academic Publishers – 1999
ORIENTAÇÃO A OBJETOS
! Bancos de Dados Orientado a Objetos
Setrag Khoshafian – Editora Wiley / Infobook – 1994
! Object Data Management
R. G. G. Catell – Editora Addison Wesley – 1994
! A First Course in Database Systems (ISBN 0-13-861337-0)
Jeffrey D. Ullman , Jennifer Widow – Editora Prentice Hall – 1997
! Object Databases: An Introduction
Barry Eaglestone , Mick Ridley – Editora MacGraw-Hill – 1997
! Object Databases in Practice www.prenhall.com/books/ptr_013899725x.html
Akmal B. Chaudhri , Mary Loomis – Editora Prentice-Hall – 1998
! Object-Oriented Database Design Clearly Explained (ISBN 0-12-326428-6)
Jan L. Harrington – Editora Morgan Kaufmann – 2000
CLIENTE-SERVIDOR
! Bancos de Dados Cliente/Servidor
Joe Salemiz – Editora Infobook – 1993
! Conectividade de Bancos de Dados Empresariais
Richard D. Hackathorn – Editora Infobook – 1993
! Bancos de Dados Cliente/Servidor
Joe Salemi – Editora Infobook – 1993
! Introdução aos Sistemas Cliente/Servidor
Paul E. Renaud – Editora Infobook – 1994
! Cliente/Servidor: Guia Essencial de Sobrevivência
Robert Orfali ¨Dan Harkey , Jeri Edwards – Editora Infobook – 1996
BANCOS DE DADOS DISTRIBUIDOS
! Distributed Database Systems
David Bell, Jane Grimson – Editora Addison Wesley – 1992
DATA WAREHOUSE
! Data Warehouse Toolkit
Ralph Kimball – Editora Makron - 1998
Como Construir o Data Warehouse
W. H. Inmon – Editora Campus – 1997
! Como Usar o Data Warehouse
W. H. Inmon , Richard D. Hackatorn – Editora Infobook – 1997
BANCOS DE DADOS NA INTERNET
! Construindo Servidores de Banco de Dados Internet com CGI
Jeff Rowe – Editora Makron – 1998
BANCOS DE DADOS TEMPORAIS
! Temporal Databases : Theory, Design and Implementation
A . Tansel , J. Clifford et alli – Editora Benjamin/Cummings – 1993
APLICAÇÕES DE BANCOS DE DADOS
! Database Marketing Estratégico
Arthur M. Hughes – Editora Makron – 1998
GERENCIA DA INFORMAÇÃO
! Manual de planejamento de Informática Empresarial
Norberto Torres – Editora Makron – 1994
! Sistemas de Informações Gerenciais: Estratégica, Tática e Operacional
Djalma P. R. Oliveira – Editora Atlas – 1992
! Sistemas de Informação Executiva- EIS (Executive Information Systems)
José D. Furlan, Ivonildo M. Ivo, Franciso P. Amaral – Editora Makron – 1994
IBM- DB2
! DB2 : Universal Database
Don Chamberlinl – Editora Morgan Kaufmann – 1998
SYBASE
! Sybase Systems Management
Karen Hogoboom – Editora Prentice Hall – 1997
JASMINE
! The Jasmine Object Database (ISBN 1-55-860494-4)
Setrag Khoshafian, Norayr Minassian – Editora Morgan Kaufmann – 1998
INFORMIX
! The Informix DBA Survival Guide
Joe Lumbley – Editora Prentice Hall – 1999- 2ª Edição
ORACLE
Oracle 8 : The Complete Reference
Kevin Loney, George Koch – Editora Oracle Press – 1997
! Oracle 8 : Administration and Management
Michael R. Ault – Editora John Wiley Computer – 1997
! Oracle 8i – Série Ramalho (ISBN 85-7251-523-2)
José Antonio Ramalho – Editora Berkeley – 1999
SQL
! Guide of SQL
John Viescas – Editora Microsoft Press – 1989
! A Guide to The SQL Standard
C. J. Date , Hugh Darwen – Editora Addison Wesley – 1997 – 4ª Edição
! The Practical SQL Handbook
J. Bowman , S. Emerson & M. Darmovshy – Editora Addison-Wesley – 1993 - 2ª Edição
! SQL : Guia de Referencia do Programador
Wayne S. Freeze – EditoraCiência Moderna – 1998
! SQL: A Linguagem dos Bancos de Dados (ISBN 8572515011)
José Antônio Ramalho – Editora Berkeley – 1999
! SQL: The Complete Reference
James R. Groff, Paul N. Weinberg – Editora McGraw-Hill – 1999
Hands-On SQL: The Language, Querying, Report and the Marketplace
Robert Groth, David Gerber – Editora Prentice Hall – 1999
! SQL for Smarties : Advanced SQL Programming (ISBN 1-55860-576-2)
Joe Celko – Editora Morgan Kaufmann – 1999 - 2ª Edição
CORBA
! Inside Corba
Thomas J. Mowbray , William A Ruth – Editora Addison-Wesley – 1997
! CORBA: Design Patterns
Thomas J. MowBlay, Raphael C. Malveau – Editora John Wiley and Sons – 1997
! The Object Data Standard: ODMG 3.0 (ISBN 1-55860-647-5)
R. G. G. Cattel, Douglas K. Barry, et alli – Editora Morgan Kaufmann – 2000
ENGENHARIA DE BANCO DE DADOS
! The Object Constraint Language
Jos Warner , Anneke Kleppe – Editora Addison-Wesley – 1999
Internet
Revistas
Developers Magazine DB2 Magazine Oracle Magazine
www.axcelbooks.com.br www.db2mag.com www.oramag.com
Oracle View Database Summit Series TeraData Review
www.oreview.com www.dbsummit.com www.teradatareview.com
SAP Technical Journal Intelligent Enterprise IEEE Software
www.saptechjournal.com www.intelligententerprise.com www.computer.org/software/
Computer World Datamation Database Programming & Design
www.computerworld.com www.datamation.com www.dppd.com
Editoras
Makron Miller Freeman - MD Ziff Davis – ZD
www.makron.com.br www.mfi.com www.zd.com
Wiley Computer - WCP SIGS Publishing Prentice Hall PTR
www.wiley.com\compbooks www.sigs.com www.phptr.com
Osborne Media Group Benjamin / Cummings Morgan Kaufmann – MK
www.osborne.com heg-school.awl.com/bc/ www.mkp.com
Atlas McGraw-Hill Addison Wesley Longman
www.editora-atlas.com.br www.mcgraw-hill.com www.awl.com
Ática Berkeley Kluwer Academic Publishers
www.atica.com.br www.berkeley.com.br www.kap.nl
Livrarias
Livraria Cultura Science Springer Amazon
www.livcultura.com.br www.science.springer.de www.amazon.com
Livraria Siciliano
www.siciliano.com.br
Empresas
Oracle IBM Sybase
www.oracle.com (.br) www.ibm.com (.br) www.sybase.com (.br)
Microsoft Computer Associates Informix
www.microsoft.com www.cai.com www.informix.com
Consist Rational Software Platinum Technology
www.consist.com.br www.rational.com www.platinum.com
Lotus SAP Inprise
www.lotus.com/home.nsf www.sap.com www.inprise.com.br
Universidades
University of Wisconsin – CS Universidade de São Paulo - SC Stanford University
www.cs.wisc.edu/exodus www.icmc.sc.usp.br www-db.stanford.edu
University of California, Berk. University of Arizona Univ. Federal de São Carlos
s2k-ftp.cs.berkeley.edu:8000 www.cs.arizona.edu www.ufscar.br
Universidade de Campinas Univ. Federal do Rio de Janeiro Univ. Federal do Rio G. do Sul
www.unicamp.br www.ufrj.br www.ufrgs.br
Associações, Orgãos e Grupos
Sociedade Brasileira de Computação - SBC Associação das Empresas Brasileiras de Software e
Serviços de Informática - ASSESPRO
www.sbc.org.br www.assespro.org.br
SUCESU Association for Computing Machinery - ACM
www.sucesu.org.br www.acm.org
Institute of Electrical and Electronics Engineers
IEEE
International Organization for Stardardization
ISO
www.ieee.org www.iso.ch
Object Management Group – OMG
Object Data Management Group - ODMG
Ministério da Ciência e Tecnologia – MCT
Ministério da Educação e Cultura – MEC
www.omg.org www.odmg.org www.mct.gov.br www.mec.gov.br
OLAP Council Data Mining Institute
www.olapcouncil.org www.datamining.org 
The Meta Data Coalition Association for Information and Image Management
www.he.net/~metadata www.aiim.org
Transation Processing Performance Council Fundação Biblioteca Nacional
www.tpc.org www.bn.br
Grupo de Banco de Dados e Imagens - GBDi Pacific Northwest National Laboratory
www.gbdi.icmc.sc.usp.br www.pnl.gov
Associação Brasileira de Normas Técnicas - ABNT
www.abnt.org.br
Estrutura
Programática
Conceitos Fundamentais .................................................................................................... Parte I
Engenharia de Banco de Dados........................................................................................... Parte II
Projeto Conceitual de Banco de Dados .............................................................................. Parte III
Projeto Lógico de Banco de Dados Relacional .................................................................. Parte IV
Programação: Linguagem SQL ........................................................................................... Parte V
Projeto Físico de Banco de Dados ...................................................................................... Parte VI
Projeto de BD Orientado a Objetos..................................................................................... Parte VII
Projeto Arquitetônico de Sistemas de BD........................................................................... Parte VIII
Data Warehouse .................................................................................................................. Parte IX
“Por mares nunca dantes
navegados/.....Em perigos e guerra
esforçados, mais do que prometia a força
humana/ E entre gente remota edificaram/
Novo reino, que tanto sublimaram”
Luís de Camões
Os Lusíadas, Canto I, 1572
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 1 – Parte I (Conceitos Fundamentais)
Conceitos
Fundamentais
11 páginas
♦♦ IINNTTRROODDUUÇÇÃÃOO
♦♦ HHIISSTTÓÓRRIIAA
♦♦ UUSSUUÁÁRRIIOOSS
♦♦ AARRQQUUIITTEETTUURRAA AANNSSII//SSPPAARRCC ((Tsichritzis & Klug)
♦♦ EESSQQUUEEMMAA DDEE DDAADDOOSS
♦♦ VVIISSÕÕEESS
♦♦ SSIISSTTEEMMAA DDEE GGEERREENNCCIIAAMMEENNTTOO DDEE BBAANNCCOOSS DDEE DDAADDOOSS ((SSGGBBDD))
♦♦ DDIICCIIOONNÁÁRRIIOO DDEE DDAADDOOSS
♦♦ LLIINNGGUUAAGGEENNSS EE IINNTTEERRFFAACCEESS
♦♦ AARRQQUUIIVVOOSS DDEE DDAADDOOSS
♦♦ PPRROOCCEESSSSAAMMEENNTTOO DDEE AARRQQUUIIVVOOSS XX SSBBDD
♦♦ OOBBSSEERRVVAAÇÇÕÕEESS
"Não basta ensinar ao homem uma
especialidade, porque se tornará assim uma máquina
utilizável e não uma personalidade. É necessário que
adquira um sentimento, um senso daquilo que vale a pena
ser empreendido, daquilo que é belo, do que é
moralmente correto."
Albert Einstein
I
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 2 – Parte I (Conceitos Fundamentais)
1 - INTRODUÇÃO
Há uma grande necessidade em se realizar o armazenamento de informações que não se
encontram isoladas umas das outras. Além de uma forma adequada para definir o armazenamento
destas informações, os usuários desejam realizar operações sobre esta coleção de dados, tais como,
adicionar (inserir) novos dados, recuperar (consultar) um determinado subconjunto de dados,
atualizar ou modificar a estrutura dos dados e eliminar informações não mais necessárias.
Uma solução para este problema foi apresentada com o advento da tecnologia em Bancos
de Dados (Bases de Dados, BD, Database em Inglês, Bases de Données em Francês, Bases de Datos
em Espanhol, Databaser em Russo). Uma definição mais precisa de Banco de Dados não existe
formalmente contudo pode-se dizer que:
a). Um Banco de Dados é uma coleção logicamente coerente de dados com um
determinado significado inerente. Isto significa que um conjunto aleatório de dados não pode ser
considerada um Banco de Dados.
b). Um Banco de Dados é projetado, construído e composto por um conjunto de dados
para um propósito específico. Existe um grupo de usuários ou algumas aplicações pré-concebidas
onde estes dados serão utilizados.
c). Um Banco de Dados representa aspectos de uma parte restrita do mundo real,
denominado de mini-mundo. Alterações que ocorra no mini-mundo são refletidas no Banco de
Dados.
Resumindo, um BD representa
uma fontede onde informações são
derivadas, possui um nível de interação
com eventos que ocorrem no mundo real, e
uma audiência que está interessada em seu
conteúdo.
Além do conceito de BD, outros
estão são necessários para se compreender
o ambiente de um BD . Um Sistema de
Gerenciamento de Bancos de Dados
(SGBD) é uma coleção de programas que
permite ao usuário definir, construir e
manipular Bancos de Dados para as mais
diversas aplicações.
Definir um BD envolve a especificação e a descrição detalhada dos tipos de dados a serem
armazenados.
Construir um BD é o processo de armazenamento dos dados em si em um determinado
meio físico que é controlado pelo SGBD.
Manipular um BD inclui uma série de funções para se realizar operações de consulta,
atualizações e remoções de dados do BD.
O Banco de Dados e seu software são juntos denominados de Sistema de Bancos de
Dados (SBD).
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 3 – Parte I (Conceitos Fundamentais)
2 – HISTÓRIA
Os primeiros SBD’s foram implantados no mercado no final da
década de 60 e eram conceitualmente muito simples (não possuindo todos
os conceitos anteriores), de acordo com as necessidades das aplicações da
época. Inicialmente os grandes impulsionadores deste segmento foram a
IBM, ORACLE e SYBASE.
3 - USUÁRIOS
Um Banco de Dados pode apresentar diversos usuários cada qual com
uma necessidade em particular, e com um envolvimento diferente com os
dados do BD. Os usuários podem ser classificados nas
seguintes categorias:
 Administradores de Bancos de Dados (DBA): : em
qualquer organização onde muitas pessoas compartilham
muitos recursos, existe a necessidade de um
administrador chefe para supervisionar e gerenciar estes
recursos. Num ambiente de base de dados, o recurso
primário é a própria base de dados e os recursos
secundários são o próprio SGBD e software relacionados. A
administração desses recursos são de responsabilidade do DBA
(“Database Administrator”). O DBA é responsável por autorizar
acesso à base de dados e coordenar e monitorar seu uso. O DBA é
responsável por problemas, tais como, quebra de segurança ou baixo desempenho. Em grandes
organizações, existe uma equipe de DBA´s;
Analistas de Bancos de Dados (Projetistas): possuem a responsabilidade de identificar os
dados a serem armazenados no BD e pela escolha da estrutura apropriada utilizada para armazená-
los. Eles devem se comunicar com os possíveis usuários do BD, obter a visão dos dados que cada
um possui, integrando-as de forma a se obter uma representação adequada de todos os dados. Estas
visões são então analisadas e, posteriormente, integradas para que, ao final, o projeto da base de
dados possa ser capaz de dar suporte aos requisitos de todos os grupos de usuários;
Usuários Finais: existem profissionais que precisam ter acesso à base de dados para
consultar, modificar e gerar relatórios. A base de dados existe para estes usuários. Existem algumas
categorias de usuários finais:
♦ usuários ocasionais: ocasionalmente fazem acesso à base de dados, mas eles podem
necessitar de diferentes informações a cada vez que fazem acesso. Eles podem usar uma
linguagem de consulta sofisticada para especificar suas requisições e são, tipicamente,
gerentes de médio ou alto-nível;
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 4 – Parte I (Conceitos Fundamentais)
♦ usuários comuns ou paramétricos: estes usuários realizam operações padrões de consultas
e atualizações, chamadas TRANSAÇÕES PERMITIDAS, que foram cuidadosamente
programadas e testadas. Estes usuários constantemente realizam recuperações e
modificações na base de dados;
♦ usuários sofisticados: incluem engenheiros, analistas de negócios e outros que
procuraram familiarizar-se com as facilidades de um SGBD para atender aos seus
complexos requisitos;
♦ Analistas de Sistemas e Programadores de Aplicações: analistas de sistemas determinam
os requisitos dos usuários finais, especialmente de usuários que necessitam de maior
interação com o BD, enquanto que os programadores de aplicações utilizam-se destas
especificações para desenvolver uma aplicação.
4 - ARQUITETURA ANSI/SPARC (TSICHRITZIS & KLUG)
Um SBD se divide em geral em três níveis :
! Nível Interno: descreve a estrutura de armazenamento físico dos dados do BD,
fornecendo um modelo físico dos dados que inclui detalhes sobre os caminhos de acesso
aos dados internamente;
! Nível Conceitual: descreve a estrutura de todo o BD para uma determinada comunidade
de usuários, ocultando detalhes sobre a organização física dos dados e apresentando a
descrição lógica dos dados e das ligações existentes entre eles.
! Nível Externo: possui as diversas descrições do BD de acordo com os grupos de usuários.
BASE DE DADOS ARMAZENADA
ESQUEMA INTERNO
ESQUEMA CONCEITUAL
VISÃO
EXTERNA 1
VISÃO
EXTERNA N
USUÁRIOS FINAIS
NÍVEL EXTERNO
NÍVEL CONCEITUAL
NÍVEL INTERNO
mapeamento externo/conceitual
mapeamento conceitual/interno
 Figura I.1 - Níveis de Esquema
Observe que os três níveis apresentados anteriormente apresentam apenas descrições dos
dados. Como os três níveis apresentam descrições diferentes para os mesmos dados, torna-se
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 5 – Parte I (Conceitos Fundamentais)
necessário converter uma representação em outra, ou seja, definir mapeamentos de dados entre os
níveis.
5 - ESQUEMA DE DADOS
O Esquema de Dados é uma parte do BD que contem informações sobre os próprios
dados do BD, entre elas inclui a estrutura do BD.
6 - VISÕES
Uma Visão consiste de um subconjunto de dados do BD, ou pode conter
dados "virtuais" que são derivados dos existentes no BD, mas que não estão
explicitamente armazenados. As Visões existem para satisfazer as necessidades dos
usuários na apresentação apenas das informações importantes e ocultando aquelas
desnecessárias.
7 - SGBD
O Sistema de Gerenciamento de Bancos de Dados tem como principais funções:
♦ Controle de Redundância: Em um sistema tradicional de controle de arquivos
cada usuário normalmente apresenta seus próprios arquivos armazenando o
conjunto de dados que é de seu interesse, e nestes casos é comum ocorrer
redundância de dados. Esta redundância consiste no armazenamento de uma
mesma informação em locais diferentes, o que pode provocar sérios
problemas. Alguns destes problemas consiste inicialmente no aumento de
esforço computacional para realizar a atualização destes dados; aumento do espaço
necessário para o armazenamento dos dados. Mas o problema mais sério é que a representação
dos dados desta forma pode tornar-se inconsistente, pois duas informações podem aparecer em
locais distintos, mas apresentando valores diferentes. Em um sistema de BD as informações só
se encontram armazenadas em um único local ou estão existindo duplicação controlada dos
dados.
♦ Compartilhamento dos Dados: O SGBD deve incluir um software para o controle de
concorrência ao acesso dos dados em um ambiente multi-usuário, de forma a possibilitar o
compartilhamento dos dados, garantindo que se vários usuários tentar realizar operações de
atualização sobre um mesmo conjunto de dados, o resultado destas operações possa ser correto.
Outro mecanismo que suporta a noção de compartilhamento de dados consiste na facilidade para
definir visões de usuário, o qual torna disponível uma porção específica dos dados do BD de
acordo com o seu interesse.
♦ Controle de Acesso: Quando vários usuários compartilham os dados, é comum
que alguns não apresentem autorização para acesso a todo o BD. Por exemplo,
os dados financeiros são freqüentemente considerados confidenciais e, desse
modo, somente pessoas autorizadas devem ter acesso. Além disso, pode ser
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 6 – Parte I (Conceitos Fundamentais)
permitido, a alguns usuários, apenas a recuperação dos dados. Já, para outros,são permitidas a
recuperação e a modificação. Assim, o tipo de operação de acesso - recuperação ou modificação
- pode também ser controlado. Tipicamente, usuários e grupos de usuários recebem uma conta
protegida por palavras-chaves, que é usada para se obter acesso à base de dados, o que significa
dizer que contas diferentes possuem restrições de acesso diferentes. Um SGBD deve fornecer um
subsistema de
autorização e
segurança, que é
usado pelo DBA,
para criar contas e
especificar
restrições nas
contas. O SGBD
deve então obrigar
estas restrições
automaticamente.
♦ Controle de
Transações: Uma
Transação é um
conjunto de
operações sobre o
BD que devem ser
executados
integralmente e sem falhas ou interrupções. O SGBD deve realizar o controle das Transações
para que sejam executadas com segurança.
♦ Possibilidade de Múltiplas Interfaces: Vários usuários representam também necessidades
diversas no que refere aos tipos de interfaces fornecidas pelo SGBD. Interfaces para consultas de
dados, programação, e interfaces baseadas em menus ou em linguagem natural são exemplos de
alguns tipos que podem estar disponíveis.
♦ Representação de Relacionamento Complexo entre Dados: uma base de dados pode possuir uma
variedade de dados que estão inter-relacionados de muitas maneiras. Um SGBD deve ter a
capacidade de representar uma variedade de relacionamentos complexos entre dados, bem como
recuperar e modificar dados relacionados de maneira fácil e eficiente
♦ Reforçar Restrições de Integridade: A maioria dos aplicativos apresentam serviços que
possibilitam garantir a integridade dos dados no BD. A restrição de integridade mais simples
consiste na especificação do padrão de formato para os dados ou valores assumidos como
“default”.
♦ Providenciar "Backup" e Restauração de Dados: Um SGBD deve fornecer recursos para
restauração caso ocorra falhas de hardware ou software. O subsistema de backup e restauração
do SGBD é o responsável pela restauração. Por exemplo, se o sistema de computador falhar no
meio da execução de um programa que esteja realizando uma alteração complexa na base de
dados, o subsistema de restauração é responsável em assegurar que a base de dados seja
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 7 – Parte I (Conceitos Fundamentais)
restaurada no estado anterior ao início da execução do programa. Alternativamente, o subsistema
de restauração poderia assegurar que o programa seja re-executado a partir do ponto em que
havia sido interrompido.
Sistema de Base de Dados
Usuários/Programadores
Consultas/Programas de Aplicações
SGBD
Software p/ processar consultas/programas
Software p/ acessar a Base de Dados
BaseBase
Meta
Figura I.2 – Arquitetura Simplificada
♦ Independências de Dados: O SGBD possibilita o desenvolvimento de programas aplicativos que
não possuem a descrição real de como os dados (arquivos) estão fisicamente armazenados. Desta
forma, alteração nas estruturas dos arquivos do BD não afetam os programas aplicativos. Os três
níveis podem ser utilizados para melhor compreender o conceito de independência de dados.
Pode-se apresentar dois tipos de independência de dados:
♦ Independência Lógica dos Dados: consiste na capacidade de alterar o esquema conceitual
sem provocar modificações nos esquemas externos ou nos programas aplicativos.
♦ Independência Física dos Dados: consiste na capacidade de alterar o esquema interno sem
provocar modificações no esquema conceitual.
Apesar de todas as vantagens citadas anteriormente sobre um SGBD, há situações em que
deve-se ponderar sobre sua utilização, como por exemplo, o alto investimento inicial e possibilidade
de compra de um novo hardware; ou a possibilidade de insatisfação no desempenho geral do sistema
que pode ser provocado pelas funções de segurança, controle de concorrência, recuperação e
manutenção de integridade dos dados.
Para que um SGBD possa fornecer as características de independência de dados, suporte a
múltiplas visões de vários usuários, entre outras, torna-se necessário a existência de
uma organização no sistema para que isto seja possível.
8 - DICIONÁRIO DE DADOS
Bons SGBD’s normalmente apoiam a inclusão de descrições
textuais sobre cada um dos arquivos do BD, como também de cada usuário e
programas aplicativos que são utilizados. Estas informações são incluídas no Dicionário de Dados
para servirem de apoio aos novos projetistas ou programadores que possam ser colocados no grupo
de trabalho, e deste modo, facilitar o entendimento dos ambiente que está sendo utilizado.
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 8 – Parte I (Conceitos Fundamentais)
Outros documentos de apoio, como por exemplo, os textos sobre a especificação e a
análise das necessidades dos usuários são valiosos e devem ser guardados contudo são informações
externas ao BD.
Exemplo de Dicionário de Dados para uma tabela denominada Cliente:
Cliente
Campo Descrição Tipo Máscara Tamanho Restrições
Nome Nome do cliente char - 55 Não Nulo
Idade Quantidade de anos
desde nascimento
int 99 - >0
Nascimento Dia e mês de nascim. char dd-mm 5 -
Endereço Localização de
moradia
char 120 Não Nulo
Profissão Ocupação profissional
principal
char 60 -
Es_Civil Estado Civil char 15 Solteiro /
Casado /
Divorciado /
Separado
9 - LINGUAGENS E INTERFACES
Uma vez que o projeto do BD tenha se completado e um
determinado SGBD tenha sido escolhido para a sua
implementação, a primeira "ordem do dia" consiste em realizar
uma especificação dos esquemas conceituais e internos, e os
respectivos mapeamentos entre eles. Para estas etapas o SGBD
oferece uma série de linguagens. A primeira delas consiste da
Linguagem de Definição de Dados (DDL), a qual é utilizada
pelos analistas e projetistas do BD para a definição dos esquemas.
O SGBD também apresentará um interpretador para a DDL, o qual será
responsável pelo processamento dos comandos da DDL, e realiza o
armazenamento do esquema definido em estruturas internas do BD.
Uma vez definido e preenchido o BD com os seus dados, estes normalmente sofrerão uma
série de operações de acesso às informações nele armazenado. O SGBD fornece a Linguagem de
Manipulação de Dados (DML) para a especificação destas operações. Os comandos da DML
podem aparecer embutidos em uma outra linguagem (geralmente uma linguagem de programação de
alto nível), e neste caso esta é denominada de Linguagem hospedeira, e DML é denominada de
Sublinguagem de dados. De outra forma se DML for utilizada isoladamente de uma forma
interativa, possa a ser denominada de Linguagem de consulta (ou "query language").
Para interagir com o SGBD além das linguagens descritas anteriormente, o sistema deve
apresentar interfaces que sejam amigáveis. Estas interfaces podem ser diversas formas:
a). Interfaces baseadas em Menus: permite ao usuário selecionar o trabalho a ser
realizado através de uma lista de opções apresentada na forma de Menus. Neste tipo de interface
uma consulta pode ser construída através da escolha apropriada de um conjunto de opções;
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 9 – Parte I (Conceitos Fundamentais)
b). Interfaces Gráficas: apresenta ao usuário o esquema de Base em uma forma de
diagrama, e a criação de consultas é realizada através da manipulação deste diagrama. Normalmente
se apresenta associada a um conjunto de menus;
c). Interface Baseadas em Formulários: o sistema apresenta ao usuário um formulário,
através do qual pode ser preenchido certas entradas. Através destes formulários pode ser realizadas
operações de consultas, inserções e remoções de dados;
d). Interface em Linguagem Natural: aceita comandos ou requisições escritas em uma
linguagem natural ou em alguma outra linguagem de consulta, sendo capaz de "compreender" o que
está sendo pedido;
e). Interface para usuários comuns: normalmente estes usuários, como o de um
terminal bancário,pode realizar apenas um conjunto limitado de operações e de forma repetitiva.
Sendo assim, é oferecida uma interface que seja fácil de compreender e com um número reduzido de
informações a serem manipuladas e poucas opções disponíveis.
No controle de acesso e transações dos dados utiliza-se uma Linguagem de Controle de
Dados, que inclusive possibilita estabelecer os diversos níveis de segurança de cada usuário.
10 - ARQUIVOS DE DADOS
Os Bancos de Dados são organizados em arquivos de dados que são estruturados
dependendo do pacote SGBD adquirido, assim sendo, o relacionamento entre registros de um
mesmo arquivo ou de arquivos diferentes depende do gerenciador.
Internamente, as estruturas de arquivo são criadas de modo a tornar rápido e flexível o
armazenamento e busca de informações, para isso são normalmente utilizados técnicas de indexação
dos arquivos como por exemplo Árvore B, Árvore TRIE e etc.
O extravio de algum ponteiro em arquivo pode significar a perda de valiosas informações
ou o atraso no trabalho. Desta forma, alguns SGBD’s incorporam o conceito de estruturas robustas,
ou seja, duplicações de ponteiro para evitar perdas desastrosas.
11 - PROCESSAMENTO DE ARQUIVOS X SBD
Algumas características tornam distintas as duas abordagens (Sistemas de Processamento
de Dados e o Sistema de Banco de Dados) para o armazenamento de informações, tais como:
A). Característica auto-contida do Sistema de BD: o sistema de BD não apresenta
apenas os dados em si, mas também o Esquema de Dados que armazena uma completa descrição ou
definição das estruturas das informações armazenadas. Em um sistema de arquivos, a definição dos
dados faz parte dos programas aplicativos, que são construídos para manipularem especificamente
um conjunto de informações.
B). Isolamento entre dados e programas: Em um sistema tradicional de arquivos os
dados e suas definições se encontram embutidos no interior dos programas. Qualquer alteração na
estrutura dos dados significa em alteração no código de todos os programas que manipulam estes
dados. Um SGBD consiste de um programa que já apresenta funções próprias para manipular
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 10 – Parte I (Conceitos Fundamentais)
qualquer conjunto de dados definidos pelo usuário. Além disso, estas definições são armazenadas
separadamente dos dados, ou seja, apresenta a característica de independência de dados.
C). Abstrações de Dados: Um BD fornece ao usuário uma representação conceitual
dos dados que não inclui muitos detalhes sobre a sua forma de armazenamento, ou como será a
organização física destes.
D). Suporte a várias visões dos dados: Um BD geralmente apresentam uma série de
usuários com diferentes perspectivas ou visões dos dados existentes
Processamento
Tradicional de Arquivos
Processamento
Base de Dados
Definição dos dados é parte do código de
programas de aplicação
Meta Dados eliminação de
redundâncias
Dependência entre aplicação específica e
dados
Capaz de suportar diversas
aplicações
eliminação de
redundâncias
Independência entre dados e
programas
facilidade de
manutenção
Representação de dados ao nível físico Representação conceitual através de
dados e programas
facilidade de
manutenção
Cada visão é implementada por módulos
específicos
Suporte a múltiplas visões facilidade de
consultas
Tabela I.1 – Tipos de Processamento
12 - OBSERVAÇÕES
A escolha da tecnologia adequada de Banco de Dados e sua correta utilização trazem
algumas vantagens adicionais:
♦ Potencial para obrigar a Padronização: a abordagem de base de dados permite que o DBA defina
e obrigue a padronização entre os usuários da base de dados em grandes organizações. Isso
facilita a comunicação e a cooperação entre vários departamentos, projetos e usuários. Padrões
podem ser definidos para formatos de nomes, elementos de dados, telas, relatórios,
terminologias, etc. O DBA pode obrigar a padronização em um ambiente de base de dados
centralizado, muito mais facilmente que em um ambiente onde cada usuário ou grupo tem o
controle de seus próprios arquivos e software;
♦ Flexibilidade: mudanças na estrutura de uma base de dados podem ser necessárias devido a
mudanças nos requisitos. Por exemplo, um novo grupo de usuários pode surgir com necessidade
de informações adicionais, não disponíveis atualmente na base de dados. Alguns SGBD’s
permitem que tais mudanças na estrutura da base de dados sejam realizadas sem afetar a maioria
dos programas de aplicações existentes;
♦ Redução do Tempo de Desenvolvimento de Aplicações: uma das principais características de
venda da abordagem de base de dados é o tempo reduzido para o desenvolvimento de novas
aplicações, tal como a recuperação de certos dados da base de dados para a impressão de novos
relatórios. Projetar e implementar uma nova base de dados pode tomar mais tempo do que
escrever uma simples aplicação de arquivos especializada. Porém, uma vez que a base de dados
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 11 – Parte I (Conceitos Fundamentais)
esteja em uso, geralmente o tempo para se criar novas aplicações, usando-se os recursos de um
SGBD, é bastante reduzido. O tempo para se desenvolver uma nova aplicação em um SGBD é
estimado em 1/4 a 1/6 do que o tempo de desenvolvimento, usando-se apenas o sistema de
arquivos tradicional, devido as facilidades de interfaces disponíveis em um SGBD;
♦ Disponibilidade de Informações Atualizadas: tão logo um usuário modifique uma base de dados,
todos os outros usuários “sentem” imediatamente esta modificação. Esta disponibilidade de
informações atualizadas é essencial para muitas aplicações, tais como sistemas de reservas de
passagens aéreas ou bases de dados bancárias. Isso somente é possível devido ao subsistema de
controle de concorrência e restauração do SGBD;
♦ Economia de Escala: a abordagem de SGBD’s permite a consolidação de dados e de aplicações
reduzindo-se, desse modo, o desperdício em atividades redundantes de processamento em
diferentes projetos ou departamentos. Isto possibilita à organização como um todo investir em
processadores mais poderosos, e periféricos de armazenamento e de comunicação mais
eficientes.
❋
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 1 - Parte II (Engenharia de Banco de Dados)
Engenharia de
Banco de Dados
29 páginas
♦♦ IINNTTRROODDUUÇÇÃÃOO
♦♦ EETTAAPPAASS
♦♦ MMOODDEELLOOSS DDEE DDAADDOOSS
♦♦ MMOODDEELLAAGGEEMM DDEE DDAADDOOSS
♦♦ MMAAPPEEAAMMEENNTTOO
♦♦ NNOORRMMAALLIIZZAAÇÇÃÃOO
♦♦ EEVVOOLLUUÇÇÃÃOO DDOO EESSQQUUEEMMAA DDEE DDAADDOOSS
♦♦ TTEEMMAASS RREELLAACCIIOONNAADDOOSS
♦♦ MMOOTTIIVVAAÇÇÃÃOO
♦♦ CCLLAASSSSIIFFIICCAAÇÇÃÃOO
♦♦ EEVVOOLLUUÇÇÃÃOO DDEE PPRROOJJEETTOO
♦♦ EEVVOOLLUUÇÇÃÃOO DDAA FFOORRMMAA
♦♦ EEVVOOLLUUÇÇÃÃOO DDAA LLÓÓGGIICCAA
♦♦ EESSQQUUEEMMAA FFÍÍSSIICCOO
♦♦ EESSQQUUEEMMAA EEXXTTEERRNNOO ((VVIISSÃÃOO))
♦♦ PPAADDRRÕÕEESS EE NNOORRMMAASS
♦♦ HHIISSTTÓÓRRIICCOO
♦♦ SSIISSTTEEMMAASS AABBEERRTTOOSS
♦♦ FFRROONNTTEEIIRRAASS
♦♦ BBEENNEEFFÍÍCCIIOOSS UUTTÓÓPPIICCOOSS
♦♦ OOSS PPAADDRRÕÕEESS
♦♦ OOMMGG
♦♦ OODDMMGG
♦♦ AANNSSII//XX33
♦♦ PPCCTTEE++
♦♦ IISSOO//SSTTEEPP
♦♦ AANNÁÁLLIISSEE GGEERRAALL
“A vida é como o equilibrismo
simultâneo de 5 bolas: o corpo; a mente; a alma; a
família e o trabalho. Dependendo de cada pessoa,
algumas destas bolas podem ser feitas de um vidro
muito frágil e outras de aço.”
“Desconhecido”
II
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 2 - Parte II (Engenharia de Banco de Dados)
1 - INTRODUÇÃO
Na informatização de um mini-mundo com a utilização de um BD, deve-se primeiramente
preocupar-se com a escolha do SBGD que será utilizado. De nada servirá uma Engenharia de BD
bem realizada se o gerenciador oferecer restrições inaceitáveis, como por exemplo, baixa capacidade
de armazenamento. As máquinas utilizadas e a arquitetura do Sistemade Informações (Centralizada,
Distribuída ou Cliente/Servidor) também são elementos de igual importância.
A Engenharia de Banco de Dados (ou Projeto de Banco de Dados, como é mais
conhecido) é um dos temas mais discutidos e estudados nesta área. A razão é forte, uma engenharia
incorreta pode resultar em um SBD que não atende as necessidades dos seus usuários, pedindo
frequentes e custosos reparos ou mesmo uma completa reengenharia. O tempo gasto em estudos e na
aplicação de princípios de uma boa engenharia de BD é sempre um tempo bem empregado.
A maior habilidade exigida para os especialistas em Engenharia de BD é saber recolher
informações a partir da vivência com o mini-mundo, é também extrair dos usuários por meio de
entrevistas e reuniões o que desejam do BD e é estruturar todas estas informações de modo a se
tornarem concretamente um BD. A grande valorização deste tipo de profissional ocorre devido a
dificuldade em se encontrar pessoas experientes tanto na área técnica quanto no tratamento com o
usuários, que na verdade são os clientes.
A grande maioria dos Bancos de Dados
existentes foram projetados manualmente por
especialistas que usaram seus conhecimentos e
experiências no processo. Todavia, com o crescimento da
complexidade dos BD’s (“Very Large Databases”) e o
estabelecimento de regras bem definidas para algumas
fases da Engenharia de BD, sugiram ferramentas de apoio
(“Automated Design Tools”) que auxiliam nas diversas
etapas do processo. Entre as vantagens podemos citar a
rapidez na realização da Engenharia, uma vez que estas
ferramentas oferecem um interface amigável que orienta
os projetistas nas decisões mais difíceis e realiza verificações seguras dos resultados intermediários.
A tecnologia dos Sistemas Especialistas (SE) em conjunto com as ferramentas CASE
(“Computer-Assisted Software Engineering”) tem colaborado nesta atividade, evitando-se
desperdícios de tempo, frustrações e melhorando os resultados de um processo extremamente crítico
e delicado tanto para os projetistas quanto para os usuários.
2 - ETAPAS
Uma boa engenharia de BD compreende resumidamente os seguintes passos:
Estabelecer o Objetivo : Buscar definir
o objetivo do sistema, benefícios que o sistema trará para
o mini-mundo, estabelecer restrições gerais de
desempenho, custos e restrições técnicas;
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 3 - Parte II (Engenharia de Banco de Dados)
Organização p/ o Trabalho: Definir a(s) equipe(s) de trabalho e sua estrutura
levando-se em consideração as habilidades de cada indivíduo e sua disponibilidade, recursos
necessários (descrição e disponibilidades), cronograma de atividades de acordo com as
disponibilidades estabelecidas.
Uma equipe pode ser estruturada em :
♦ Convencional : composta pelo pessoal disponível; entre estas pessoas é designado um
gerente do projeto; o trabalho é dividido entre os componentes da equipe; cada pessoa
é responsável pelo seu sub-projeto e respectiva implementação;
♦ Não-Egocêntrica : Organização de estilo democrático, descentralizado; Relações e
comunicações informais entre os seus componentes; A liderança não é exercida por
uma determinada pessoa de forma permanente; A liderança fica com o indivíduo que
tiver maior capacitação para resolver o problema em pauta; Todos os sub-projetos são
examinados pelos outros projetistas;
♦ Projetista-Chefe : Pequeno
número de integrantes;
Comunicações centralizadas
no projetista chefe; Decisões
tomadas nos níveis mais
elevados; O chefe tem que
ser muito experiente e
capacitado para a função;
♦ Hierárquica: líder de projeto
dirige analistas experientes; cada um desses analistas dirige um grupo de analistas
menos experientes; comunicação descentralizada nos subgrupos e centralizada nos
níveis superiores; o chefe de subgrupo transmite informações para seu subgrupo
(elemento de ligação com os outros subgrupos)
É importante notar
que as participações das
pessoas em uma engenharia
pode variar com o seu grau
de comprometimento e
conhecimento, como mostra
o gráfico abaixo.
É importante que
exista um cronograma geral
de atividades e um
cronograma de cada
indivíduo, que pode ser
apresentado de várias
formas, como mostrado abaixo.
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 4 - Parte II (Engenharia de Banco de Dados)
Coleta de Dados: Coletar todos os tipos de informação que são precisos armazenar.
Pensar sobre os relatórios e/ou formulários que possam ser desejados. Para
esta fase é necessário conhecer profundamente o mini-mundo
e isto pode requerer algum tempo e a experiência (sabedoria)
nesta etapa é fundamental. Não deve ser realizada por uma
única pessoa, mas por um grupos de projetistas;
O levantamento dos dados necessários é,
basicamente, feito através da observação e das entrevistas.
Por meio da observações o analista utiliza sua habilidade
e sua sensibilidade na constatação de ocorrências que
devam ser computadas na análise, como também
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 5 - Parte II (Engenharia de Banco de Dados)
verifica a veracidade ou não dos dados fornecidos pelos entrevistados. Nas entrevistas o analista
aplica os questionários, anotando as respostas obtidas para posterior análise.
Técnica de entrevista : Importante fase do levantamento de dados, a entrevista é o meio
utilizado para o recolhimento das informações que compõem o questionário analítico. Merece pois,
que lhe seja dada especial atenção, a fim de que a mesma seja realizada segundo o adequado
embasamento técnico.
Escolha do entrevistado : O analista deve ter o máximo cuidado quando da escolha do
elemento a ser entrevistado, de modo que a entrevista seja realizada com a pessoa mais capacitada a
responder os quesitos constantes do questionário. De um modo geral, o elemento a ser inicialmente
entrevistado deve ser o chefe do setor em estudo, para que posteriormente se sucedam as entrevistas
com os encarregados das seções componentes do setor, caso se façam necessárias.
Marcação da entrevista : Para a marcação da entrevista, o analista deve fazer uma pré-
abordagem, contactando um subordinado da pessoa a entrevistar, a fim de conhecer a sua maneira de
agir, sua personalidade e a precisa posição hierárquica. A data, hora e local da entrevista devem ser
de inteira conveniência do entrevistado, pois a experiência nos mostrou que uma entrevista
freqüentemente interrompida por contingência do serviço, perde quase que totalmente sua finalidade
inicial.
Precauções do analista : Confirmar com antecedência, a validade do local e a hora
anteriormente combinados. Tomar o cuidado de ser pontual ao compromisso.
Tempo de duração da entrevista : O tempo de duração dependerá das características de
cada entrevista. O tirocínio do analista garantirá o tempo razoável para cada uma, com o cuidado
para que não se torne fatigante e que quaisquer ocorrências não venham a apressá-la.
O analista não deve se furtar a efetuar o número de entrevistas que se fizer necessário ao
levantamento.
Apresentação : Um dos primeiros passos para uma entrevista é a apresentação do analista
ao entrevistado, que deverá ser feita de preferência pelo superior imediato do entrevistado, o qual
aproveitará a ocasião para explicar os objetivos da análise e as vantagens que representa para a
empresa e, também, para o próprio entrevistado.
Postura correta, simpatia, boa apresentação pessoal, simplicidade, etc., são qualidades
essenciais ao entrevistador. Não devemos esquecer que todo homem dá uma idéia de si mesmo pelo
seu porte, pelo seu olhar, pela sua apresentação, pelo seu aperto de mão. É de utilidade para o
analista o uso de cartões de visita.
Atitude do analista : O analista deve procurar manter uma atitude sincera, amável e atenta,
pois a precisão do levantamento depende das informações do entrevistado. Deve evitar julgamentos
precipitados de valores. Nunca esquecer que o objetode análise faz parte da vida do entrevistado,
que, em muitos casos, foi ele próprio quem imaginou os instrumentos e os métodos de execução. É
difícil para um indivíduo que conhece seu trabalho a muito tempo admitir que alguém, que nunca o
fez, possa introduzir alguma melhoria ou romper um paradigma.
Deixar o entrevistado falar e tentar entendê-lo são condições básicas para o sucesso da
entrevista, principalmente porque aprende mais quem sabe ouvir. Adaptar o nível de linguagem ao
entrevistado torna-se fundamental, não se pode usar os mesmos termos, fazer as mesmas perguntas e
ter as mesmas atitudes com um operário e com um diretor.
A entrevista deve ser realizada em clima de informalidade, procurando o analista ser
comedido no emprego de termos técnicos. Os bons aspectos do trabalho do entrevistado devem ser
valorizados e elogiados. Segundo Maslow, classificado como uma das necessidades, o
reconhecimento enriquece o ego do ser humano.
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 6 - Parte II (Engenharia de Banco de Dados)
Técnica de levantamento : Esta fase consiste na aplicação do questionário e obtenção dos
dados para a análise quantitativa. O levantamento exige muita atenção e cuidado, pois envolve
também problemas de relações humanas. Nem sempre será fácil obter as informações, sobretudo se
o analista não desenvolver sua habilidade para entrevistar dentro da técnica acima apresentada. É
importante ter sempre em mente que de um levantamento incorreto resultará numa análise
deformada da empresa.
Perguntas : As perguntas do questionário poderão ser lidas, com a maior clareza possível,
ou feitas com palavras que o analista considere como mais à altura da compreensão do entrevistado.
O entrevistador deve ser claro, procurando explicar o que deseja e, se necessário, repetir as
perguntas de vária maneiras, até estar seguro de que as mesmas foram perfeitamente compreendidas.
Anotação das respostas : As respostas deverão ser anotadas imediatamente após sua
formulação pelo entrevistado. O analista deve procurar ser sucinto na redação, sem no entanto
permitir que a simplificação prejudique a compreensão posterior das respostas. Pode ser
conveniente, em reforço às anotações, o uso de um pequeno gravador de áudio durante a entrevista.
Caso seja necessário, ao fazer a revisão das anotações, o analista deverá voltar ao
entrevistado para dirimir as dúvidas que porventura surjam.
As anotações devem, preferencialmente, ser feitas na própria cópia do questionário e nos
espaços logo após as respectivas perguntas.
Material utilizado : Durante o levantamento, o analista deve estar equipado com o seguinte
material:
♦ Uma cópia do questionário a se utilizar
♦ Uma cópia dos quadros estatísticos
♦ lápis ou caneta esferográfica
♦ Prancheta para anotações
♦ Bloco para anotações complementares
É obvio que muitas são as variantes, dependendo dos recursos disponíveis, pode se lançar
mão do uso de gravadores, laptops (questionário e respostas em arquivos), etc.
Cuidados durante o levantamento :
♦ Procurar interpretar bem a resposta antes de registrá-la.
♦ Cuidar para que o tom de voz ou o modo de fazer a pergunta não influam na
resposta do entrevistado.
♦ Nas perguntas cujas respostas envolvam opiniões, procurar auxiliar na objetividade
de sua expressão.
♦ Nas perguntas cujas respostas envolvam dados exatos, insistir na exatidão
necessária à analise.
♦ Permitir liberdade de expressão ao entrevistado, sem contudo permitir que fuja ao
assunto da entrevista.
♦ Suspender o levantamento para um coffe break ou similar (em companhia ao
entrevistado) quando sentir queda do ritmo ou da qualidade do mesmo.
Análise e Especificação: O grupo de projetistas deve
ponderar sobre todas as informações obtidas e gerar documentos que
especifiquem as necessidades dos usuários. Caso perceba-se a falta de
alguma informação deve retornar a fase anterior (coleta);
A análise dos dados levantados, por meio dos
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 7 - Parte II (Engenharia de Banco de Dados)
questionários e da observação do analista, é a fase mais importante de todo o processo para se chegar
ao diagnóstico propriamente dito. É quando o analista utiliza realmente todo o seu conhecimento e
sua habilidade.
Quem deve analisar : A análise deve ser realizada pela mesma pessoa que levantou os
dados, pois, como dissemos acima, além das respostas dadas pelos entrevistados e anotadas, também
forma feitas observações que são necessárias à análise. Na realidade a análise de determinados
métodos se inicia, ou mesmo é feita totalmente, na própria fase de levantamento.
Método de análise : Não se pode, evidentemente, estabelecer regras precisas para este tipo
de trabalho, que vai depender da capacidade e experiência do(s) analista(s).
Assim, ao passo que durante o levantamento devemos partir do geral para o particular, na
fase de análise o mais correto é primeiro analisar os detalhes e daí tirar conclusões sobre o todo.
Quanto à prioridade a ser estabelecida para o estudo dos detalhes, estará sujeita ao bom senso do
analista, como de resto grande parte de suas decisões nesta fase de análise.
Projeto Conceitual: Através de uma ferramenta
conceitual (modelo de dados a nível conceitual) um grupo de
especialistas repassa a especificação textual em um diagrama ou
outras forma de linguagem que descreve com clareza as
necessidades dos usuários, isto é chamado modelagem. O
objetivo desta fase é organizar melhor as idéias passadas pela fase
anterior (Análise e Especificação) e perceber alguma falta de
informações e neste caso é necessário retornar;
Projeto Lógico: Através de uma ferramenta
lógica (modelo de dados a nível lógico) um grupo de
especialistas repassa a especificação conceitual em lógica
através de um diagrama ou outra linguagem, isto é chamado
mapeamento. Com esta fase obtém-se a definição lógica dos
arquivos de dados. Especificação lógica depende do SGBD que
será utilizado pois as estruturas dos arquivos devem ser
compatíveis com o gerenciador utilizado;
Projeto Físico : Através de conhecimentos
coletados no requisitos, com relação a freqüência e forma de
utilização dos dados, estabelece-se a organização mais adequada
para os arquivos e os métodos de indexação mais eficientes.
Tipos de Organização de Arquivos:
Heap File (Serial) Sorted File (Seqüencial) 
Hashed File
Métodos de Indexação:
ISAM B Tree B* Tree
B++++ Tree Trie Multilist Inverted File
Double Chained Tree
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 8 - Parte II (Engenharia de Banco de Dados)
Implantação: Tendo a especificação dos arquivos
pode-se implanta-los, através da linguagem DDL para formarem
um BD;
Verificação e Validação: Os testes são
realizados medindo a satisfação dos usuários em
termos de velocidade e o padrão com que os dados
são apresentados;
Acompanhamento da Qualidade: o DBA
deve permanecer atendo a mudanças de requisitos de modo a
perceber alterações nas especificações anteriormente corretas;
Manutenção: A insatisfação de um usuário ou mesmo
modificação no mini-mundo (expansão da empresa, etc.) pode exigir
pequenas alterações na estrutura do BD. Mudanças drásticas como por
exemplo modificações no organograma de uma empresa podem
exigir um trabalho maior na restruturação do BD (reengenharia).
A similaridade do processo de Engenharia de BD com a
Engenharia de Software não é coincidência. Na verdade pode-se
dizer que ambas são complementares, uma vez que na Engenharia
de Software é necessário a criação dos arquivos de dados (BD) e na Engenharia de BD é necessário a
criação dos programas aplicativos (software) que irão operar o Banco de Dados.
3. MODELOS DE DADOS
Um Modelo de Dados é um conjunto de conceitos utilizados para descrever a estrutura de
um BD a nível conceitual, lógico ou físico. Os modelos apresentam um conjunto de operações para a
especificaçãoe manipulações dos dados do BD. Os tipos de modelos existentes na literatura se
classificam em:
A). Modelos Baseados em Registros: são modelos que fornecem conceitos de modelagem
a nível lógico utilizando-se da representação de registros. Comercialmente, os modelos mais
encontrados são o Rede, Hierárquico e Relacional;
B). Modelo Semânticos: são modelos conceituais que apresentam uma capacidade maior
de representação fiel de um problema, pela simples razão de possuir conceitos mais elaborados.
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 9 - Parte II (Engenharia de Banco de Dados)
Exemplos de modelos desta categoria são o Modelo Entidade-Relacionamento (MER) e o Modelo
Funcional;
C). Modelos Orientados a Objetos: são modelos conceituais que procuram representar e
estruturar Bancos de Dados através
do paradigma de “Orientação a
Objetos”. Este tipo de modelo esta
em grande destaque mundial
(inclusive no Brasil) nas pesquisas
atuais. Alguns dos modelos em
pesquisa são: O2 (França); PCTE
(Comunidade Européia) ;Orion
(EUA) e o Modelo de Representação
de Objetos - MRO (Brasil -
USP/São Carlos).
O reflexo das
necessidades evolutivas do mercado pode ser cronologicamente visualizado através dos diversos
Modelos de Dados desenvolvido, desde os Modelos Baseados em Registros passando pelos
Semânticos até os recentes Modelos Orientados a Objetos, como pode ser visualizado pela figura
abaixo.
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 10 - Parte II (Engenharia de Banco de Dados)
4 - MODELAGEM DE DADOS
Atualmente o Modelo de Dados Conceitual mais difundido e utilizado para a modelagem
de dados é o MER criado por Peter Chen. O resultado da modelagem utilizando o MER é um
diagrama (DER)
bastante simples porém
de grande utilidade.
Tendo
exatamente definido
qual o problema ser
resolvido, ou seja,
tendo determinado as
fronteiras que
delimitam e restringem
o mini-mundo a ser
modelado e realizado a
especificação, utiliza-se
um roteiro a ser
seguido para se
determinar uma
primeira versão do
DER.
Após criada a
primeira versão do
DER deve-se
apresentar aos usuários
para que sejam
verificados a corretude
e completude do diagrama. Sucessivas apresentação do DER devem ser realizadas enquanto foram
detectados falhas na representação.
À primeira vista pode-se pressupor que esta rotina de trabalho trará atrasos na construção
do Banco de Dados, porém os especialistas em engenharia (software, mecânica e etc) sabem da
extrema importância da fase de projeto. Erros ocorridos nesta fase acarretam graves atrasos e
aumento no custo de realização do produto. Por esse motivo, o MER se tornou uma ferramenta de
modelagem entre as mais difundidas, estimadas e utilizadas no mercado de informática.
5 - MAPEAMENTO
O Modelo Entidade Relacionamento é responsável por realizar uma representação dos
dados de uma determinada aplicação a um nível mais conceitual, um pouco distante da forma como
os seus elementos serão efetivamente implementados. Os modelos de registros, dentre eles Modelo
Relacional (mais usado), fornece uma representação dos dados de forma mais próxima como estes se
encontrarão quando forem definidos os arquivos para o BD.
A passagem do diagrama do MER para a representação do Modelo Relacional é
denominado Mapeamento do MER para o Relacional e é uma das técnicas mais utilizadas por ser
uma ligação entre os modelos de dados mais utilizados.
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 11 - Parte II (Engenharia de Banco de Dados)
Existem outros mapeamentos estabelecidos como :
- MER para o Modelo Rede; e
- MER para o Modelo Hierárquico,
contudo não serão abordados nestas notas por serem pouco utilizados.
6 - NORMALIZAÇÃO
O processo de Normalização é uma etapa complementar ao Mapeamento e consiste da
aplicação de uma série de regras (Formas Normais). Estas regras irão provocar algumas
modificações na especificação lógica. A Normalização permite ao projetista definir quanto da
consistência é garantida pela estrutura dos arquivos e quanto deve ser responsabilidade dos
aplicativos e/ou do SGBD. Deve ser realizada alguma ponderação: normalizar demais diminui a
eficiência dos aplicativos e de menos abre flancos para inconsistências.
7 – EVOLUÇÃO DO ESQUEMA DE DADOS
O ciclo de vida de um Sistema de Informações típico pode ser especializado para Sistemas
de Bases de Dados (“Micro Life Cycle”) cujas fases teriam as seguintes denominações: Definição,
Projeto Conceitual, Lógico e Físico (“Design”), Implementação, Implantação de dados e aplicativos,
Teste/Validação, Operação, Monitoramento e Manutenção. Particularmente, as fases de Operação e
Monitoramento são permanentes e, em respostas as suas execuções, podem necessitar da ativação da
Manutenção.
A Manutenção de um SBD pode envolver a troca e/ou reciclagem de qualquer de seus
componentes: “hardware” (computadores e equipamentos); “software” (ambientes, aplicativos,
SGBD, componentes e estruturas da BD); “peopleware” (usuários comuns, programadores e
DBA’s); e até mesmo das técnicas empregadas (modelagem e linguagem).
Em termos de componentes da Bases de Dados, BD Intencional (Esquema de Dados1) e
BD Extensional (Instâncias), a flexibilidade para a Manutenção é determinada pela adequação de
seu projeto e pela capacidade funcional de seus respectivos SGBD’s. Essa habilidade, que pode-se
denominar Evolução2, é atualmente um fator diferenciador entre as BD’s existentes, e pode depender
tanto do Modelo quanto de sua implementação.
Para outros componentes e aspectos de um Sistema de Bases de Dados, a Evolução recebe
diversas denominações e/ou variações. No entanto, no que se refere particularmente à Manutenção
da Base de Dados Intencional, a denominação técnica predominante na literatura atualmente é
“Evolução do Esquema de Dados”, em gradativa substituição ou incorporação de semântica com o
antigo termo Reorganização.
Apesar de ser um tema ha muito discutido, não existe nenhuma norma ou padrão que
regularize a Evolução do Esquema de Dados como um processo de trabalho. Isso possibilita sua
abrangência e desdobramento para inúmeras situações, e desta forma, as variações entre as diversas
 
1 Esquema de Dados: repositório de conhecimento sobre as estruturas da Base de Dados. Em alguns
paradigmas, o Esquema dificilmente pode ser separado do Modelo de Dados. (definição segundo RODDICK).
2 Evolução, em um sentido amplo, pode ser definida como uma habilidade ou um processo de adaptação a
novas situações (internas ou externas), de modo a manter uma estabilidade relativa ou para melhorá-la, determinada e em
conformidade com os requisitos relacionados ao meio (ou ambiente).
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 12 - Parte II (Engenharia de Banco de Dados)
pesquisas existentes sobre este tema permite abordar a Evolução do Esquema de Dados sobre
diversos enfoques.
7.1 - TEMAS RELACIONADOS
7.1.1 - TEMPO 3
O Tempo é uma parte essencial e determinante dos dados em função da constante mutação
envolvendo o mundo real. Os Eventos (fatos ou acontecimentos) e dados precisam ser interpretados
no contexto do Tempo; baseado neles são criadas Transações, ou operações sobre as informações do
Esquema de Dados, cujos valores anteriores podem ser retidos historicamente em uma Base de
Dados Temporal (BDT), de acordo com um parâmetro temporal mensurável (Tempo da Transação,
Tempo Válido, Tempo Real).
O controle de parâmetros temporais apresenta-se envolvido com o tema “Evolução do
Esquema de Dados”. Contudo, não se deve relacioná-los em uma associação de interdependência de
“serviços”, pois a representação de aspectos temporais das informações está intimamente ligada ao
registro histórico de alteração de valores, que por sua vez, é uma alternativa entre os procedimentos
que envolvem a Evolução do Esquema.
7.1.2 - REGRAS 4
A capacidadede expressar a Evolução, na sua forma mais simples/primitiva, pode ser
encontrada em Regras para a manutenção da consistência do Esquema de Dados. Para esse fim,
existem Sist. de Gerenciamento de Regras (SGBD/SGR) que controlam a disponibilidade e
veracidade lógica dos dados, e que tornam a Evolução de informações uma tarefa involuntária, que
não depende de avaliações ou comandos do usuário.
7.1.3 - VERSÕES 5
Versões são normalmente utilizadas para apoiar a recuperação de dados, para o controle de
concorrências de curta ou longa duração utilizando-se de operações de “check-in” para gerar Versões
e posteriormente “check-out” para integrá-las, ou para a realização de distribuição dinâmica da Base
de Dados. Apesar dessas funções e de outras bastante consolidadas, é cada vez mais freqüente a
colocação de Versões como sendo individualmente importantes, porém não necessariamente
obrigatórias, em aplicações que realizam atividades relacionadas a Evolução de Esquemas.
 
3 Tempo pode ser definido como um parâmetro de variação continua da caractéristica de qualquer objeto, e
que pode ser simbolizado por números reais ou inteiros, extraídos de uma seqüência equidistante de valores
representativos da unidade de tempo escolhida.
4 Regras são formadas pelos conjuntos {Evento, Condição, Ação} e representam o “Conhecimento
Procedural” que retrata a definição e forma de atuação de mecanismos internos de controle, como por exemplo,
restrições de integridade.
5 Versão é uma descrição do aspecto de um objeto e que se estabelece no contexto da aplicação de modo a
definir um marco delimitador do trabalho realizado ou a realizar-se. Sua utilização é bastante flexível, ou seja, sobre as
Versões pode-se realizar quaisquer operações (leitura/escrita, remoção, atualização e criação) desde que definidas pelo
Modelo de Versões seguido.
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 13 - Parte II (Engenharia de Banco de Dados)
7.2 - MOTIVAÇÃO
A Manutenção da Base de Dados, com relação ao Esquema e sempre sob a supervisão da
Administração (DBA), era motivada apenas pela deterioração da performance causada pelas
constantes atualizações (restruturações) do Esquema. Se não fosse evitada, esta deterioração elevava
os custos de acesso às informações e consequentemente inviabilizava a utilização de uma Base de
Dados.
Atualmente, o reconheci-
mento das necessidades de Evolução
do Esquema de Dados é uma tarefa
mais complexa, e dela surgem diversas
questões tais como: O que deve ser
alterado? Quando deve ser realizado?
Como realizar? Quais os benefícios?
Qual o custo desse processo? Quem
será afetado? e outras interrogações
que devem fazer parte da política de
Manutenção do SBD.
Mesmo com a complexidade
desse tema, o seu elevado grau de
aplicabilidade torna-o funcionalmente
necessário em várias situações e por diferentes motivos, dentre os quais cita-se:
• Correção do Esquema de Dados diante de problemas encontrados durante a Fase de
Operação com a Base de Dados.
• Adaptação do Esquema de Dados aos novos componentes e/ou circunstâncias que
envolvem o Sistema de Base de Dados e seu ambiente de utilização.
• Refinamento de componentes do Esquema que foram pouco detalhados durante a fase de
projeto e portanto estavam semanticamente pobres.
• Atualização de componentes do Esquema de modo a acompanharem as constantes
modificação de requisitos dos usuários e a evolução do empreendimento.
• Experimentação de novas concepções do Esquema de Dados em momentos quando
buscam-se alternativas para a modelagem da Base de Dados.
• Incorporação de novos elementos ao Esquema de Dados.
• Integração de Bases de Dados completas na forma de: “Federated Database” (FDB)
através de uma metodologia “Bottom-up” que integra várias BD para a criação da FDB ou em uma
metodologia “Top-Down” para incorporação de uma BD à uma FBD existente; “SuperViews” - uma
virtual integração de múltiplas BD’s; ou “MultiDatabases Systems” (MDBS) - confederação de
preexistentes, autônomos e possivelmente heterogêneos SBD’s.
7.3 - CLASSIFICAÇÃO
Uma classificação dos trabalhos de pesquisa sobre o tema “Evolução de Esquemas de
Dados” pode ser muito útil para aqueles que se propõem a desenvolver um Modelo de Dados e/ou
Deterioração da BD
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 14 - Parte II (Engenharia de Banco de Dados)
um SGBD com capacidade de Manutenção da Base Intencional. Neste sentido, pode-se relacionar
três linhas de trabalho para a Evolução6:
• Projeto: voltada ao problema de Evolução do Esquema ao nível de técnicas de Projeto da
Base de Dados e de gerência de grupos de DBA’s;
• Forma (Física): voltada ao problema de Evolução do Esquema Físico e de suas
conseqüências (Restruturação/Reformatação) para a Base de Dados;
• Lógica: voltada ao problema de Evolução do Esquema Físico/Conceitual e do Esquema
Externo (Visões do usuário). Estuda especialmente as operações de alteração do Esquema lógico, as
Técnicas de Evolução de Esquemas empregadas e as Estratégias de Propagação das atualizações na
BD Intencional.
Em um nível Físico ou Lógico, a Administração (DBA) do Sistema de Bases de Dados
pode optar por duas estratégias básicas, em um processo de Evolução do Esquema de Dados que
envolve alterações reais na BD. Dependendo do grau de complexidade e abrangência, estas
alterações são realizadas:
- Off-line: esta estratégia interrompe todos os processos em andamento enquanto a BD está
sendo reorganizada. É
executada em um período
de pouca requisição de
dados, pois os usuários
comuns têm seus pedidos
de acesso negados durante
o período em que as
alterações na BD estão
sendo realizadas;
- On-line: esta estratégia
mantém o SBD em
operação enquanto se
realiza a Evolução do
Esquema. É recomendada
para aqueles SBD’s que
são “críticos” para seus
usuários; ou para BD que
envolvem grande volume
de dados. A reorganização
e utilização da BD são
processos concorrentes,
controlados de forma que o
usuário comum possa ter
suas requisições atendidas enquanto uma porção da BD é atualizada.
 
6 O interrelacionamento entre as três linhas de Evolução do Esquema é bastante significativo para tratá-los
separadamente.
Usuário
Evolução da BD
Evolução "Off-line"
Usuário
Evolução da BD
leitura
escrita
Evolução "On-line"
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 15 - Parte II (Engenharia de Banco de Dados)
7.4 - EVOLUÇÃO DO PROJETO
Para o Projeto, a Evolução do Esquema de Dados envolve o retorno às fases de Definição
e “Design”, e consequentemente implica em nova Implementação, Implantação, Teste/Validação e
Operação, dependendo do grau de Manutenção realizada. Para isso, foram criadas técnicas
específicas no que se refere ao SBD e outras genéricas envolvendo Sistemas de Informação como
um todo.
7.4.1 - PROJETO DE SISTEMAS DE BASE DE DADOS
A Evolução do Esquema de Dados pode ser tratada em técnicas que enquadram-se dentro
do ciclo de vida de Sistemas de BD (“Micro Life Cycle”):
• “Schema Integration”: metodologias para a divisão do processo de Projeto em diversos
Esquemas de Dados que representam partes de uma aplicação. Subseqüentemente, estas partes são
integradas em um Esquema unificado.
• “Translation of Schemes”: metodologias para a “tradução” do Esquema representado em
um “Modelo de Dados origem” para um “Modelo de Dados destino”, utilizando-se da representação
do Esquema de Dados em um Modelo de Dados “intermediário” com grande capacidade de
abstração.
• “Schema Reuse” : metodologias de representação, armazenamento e reutilização de
componentes de um Esquema de Dados.
A Reutilização de componentes de um Esquema exige cooperação entre os projetista,
padronização de conceitos e terminologias, além obviamente de uma “biblioteca” para o
armazenamentodos componentes reutilizáveis. Apesar destas e de outras dificuldades, o objetivo a
ser atingido é o incremento da produtividade e qualidade de desenvolvimento e mesmo de
manutenção.
7.4.2 - PROJETO DE SISTEMAS DE INFORMAÇÃO
Em um contexto mais amplo, a Evolução do Esquema de Dados pode ser enquadrada em
técnicas de engenharia e/ou de desenvolvimento de um Sistemas de Informação (“Macro Life
Cicle”):
• “Reverse Engineering”: metodologias para o reconhecimento e representação dos
aspectos estruturais, funcionais e comportamentais de um Sistema de Informações já implantado.
• “Reengineering”: metodologias para a conversão de Sistemas de Informação apoiados
em ambientes ultrapassados/obsoletas para tecnologias mais modernas. Especificamente em
Engenharia de Sistemas, a Reengenharia introduz técnicas para o reestudo e conversão de sistemas
ultrapassados para novas realidades e o conseqüente reprojeto de Bases de Dados.A Reengenharia
pode ser composta por três fases: Engenharia Reversa, Delta (∆) e Engenharia Avante. A Engenharia
Reversa realiza um definição abstrata e clara de representação do Sistema. Na fase Delta estabelece-
se as modificações no Sistema, que pode incorporar novas funcionalidades (∆ positivo) ou pode
reduzi-las (∆ negativo), e exigir uma completa ou parcial implementação. A terceira e última fase,
Engenharia Avante, refere-se ao desenvolvimento normal do Sistema seguindo-se as etapas naturais.
• “Concurrent Engineering” : metodologias criadas inicialmente para as áreas de
engenharia convencionais (mecânica e elétrica) e que estabelecem o desenvolvimento simultâneo de
um “produto” através da cooperação de grupos de projetistas trabalhando separadamente porém em
constante comunicação e troca de informações. A Engenharia Concorrente adapta-se
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 16 - Parte II (Engenharia de Banco de Dados)
consideravelmente ao processo de engenharia de Sistemas de Informação grande e complexos, mas
para isso devem existir sistemas de apoio ao trabalho cooperativo entre os grupos de projeto,
denominados “Groupware”, que são abordados na área de CSCW (“Computer Support Cooperative
Work”).
7.5 - EVOLUÇÃO DA FORMA
Alterações dos requisitos de desempenho, mudanças no Modelo de Dados, no SGBD ou
na arquitetura do SBD (ex. distribuição), por exemplo, podem provocar profundas reformas na BD
como um todo. Estas reformas iniciam-se no contexto organizacional do empreendimento e podem
atingir vários processos e sistemas. Particularmente em SBD’s, a Administração (DBA) fica
obrigada a um criterioso processo de Restruturação da composição física da BD (ou Reformatação
de seus arquivos de dados).
7.6 - EVOLUÇÃO DA LÓGICA
A Evolução, em um nível lógico, pode ocorrer sobre o Esquema Físico/Conceitual ou
sobre o Esquema Externo (Visões) em dois níveis de granularidade:
• Domínios/Tipos: são alterações de tamanho, de valores ou de nomes dos Domínios/Tipos
de Atributos e apesar de representarem modificações muito simples em termos de modelagem,
podem refletir em violações de restrições semânticas nas Instâncias, caso não sejam fortemente
controladas.
• Conjuntos (Relações e Classes): são modificações mais complexas nas definições dos
conjuntos e que incluem alterações estruturais, funcionais e comportamentais nos Esquemas de
Dados.
7.6.1 - ESQUEMA FÍSICO
A Evolução do Esquema Físico/Conceitual envolve operadores e operações críticas sobre
aspectos estruturais e comportamentais dos elementos do Esquema que podem implicar em
alterações das Instâncias (Evolução de Instâncias7) envolvidas e modificações nos programas
aplicativos que utilizam estas Instâncias (Adaptação dos Aplicativos). Essa estreita relação entre
Instância e Esquema, e mesmo a associação lógica entre os elementos alterados e inalterados de um
Esquema gera a necessidade de Técnicas de Evolução de Esquema e de Estratégias de Propagação
nas Instâncias.
Cada Modelo de Dados define os elementos existentes em seu Esquema, uma taxonomia
de operações de alterações de Esquemas e as regras semânticas para a execução das ações evolutivas
que geram um “novo” Esquema. Toda ação de alteração do Esquema deve passar por filtros de
integridade, nos quais a consistência do “novo” Esquema é verificada com base nas invariantes do
Modelo de Dados, ou seja, em um conjunto de condições, restrições e/ou recomendações para cada
uma das operações de alteração permitidas.
 
7 A Evolução de Instâncias em uma BD não é fundamentalmente motivada pela Evolução do Esquema desta
BD, ou seja, mesmo não havendo alterações no Esquema de Dados pode ser necessária modificações em Instâncias, por
exemplo, migrar um Objeto para uma outra Classe ou especializar um Objeto.
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 17 - Parte II (Engenharia de Banco de Dados)
7.6.1.1 - TÉCNICAS DE EVOLUÇÃO DE ESQUEMA
As Técnicas de Evolução de Esquema não possuem denominações usuais, mesmo porque
não foram classificadas. A “operação básica”, nas quais as técnicas fundamentam-se, pode ser usada
como critério para uma classificação, mas nenhuma dessas técnicas é detalhada ao ponto ter sua
aplicabilidade diminuída. Deste modo, todas são capacitadas para o uso nas mais diferentes
aplicações, mesmo porque cada técnica foi aprimorada ou estendida buscando uma compreensão
genérica dos problemas.
- “CREATING/MODIFICATION”
Esta técnica se baseia na modificação do Esquema de Dados em uso. Para isso, é criado
um “novo” Esquema utilizando-se ou não uma cópia do Esquema já implantado. As modificações no
“novo” Esquema devem ser de pequena grandeza, ou seja, poucas e pequenas alterações em relação
ao Esquema implantado, mesmo que tenham grande influência sobre as Instâncias.
Normalmente, as modificações do Esquema comportam operações simples (ex. “create”,
“delete” e “change”) descritas em comandos contidos na DDL (“Data Definition Language) e
geralmente, o Esquema de Dados “abandonado” é eliminado da BD, contudo, opcionalmente,
permite-se mantê-lo armazenado somente para revisões, dependendo do Modelo de Dados utilizado
e do suporte às “antigas” instâncias.
- “ADDITIONAL”
Esta técnica de Evolução do Esquema tem como característica a adição de novos
elementos ao Esquema de Dados implantado, ou seja, a motivação desta técnica é acrescentar uma
quantidade significativa de novos componentes de representação ao Esquema de Dados. A adição de
uma grande quantidade de componentes ao Esquema de Dados caracteriza sua extensão para novos
contextos de representação do empreendimento.
Aliada a uma abordagem própria para a realização do Projeto da Base de Dados, esta
técnica pode oferecer meios para a adição de sub-esquemas (ex. Esquemas Suplementares) ou
mesmo de incorporação gradativa do Esquema de Dados em relação às Instâncias que já encontram-
se armazenadas na Base de Dados (ex. “approach bottom-up”, “Incomplete Information”). Para isso,
requerem-se controles especiais que permitam a adição de novos elementos ao Esquema e que não
comprometam nenhum aspecto do processo de manipulação de Instâncias.
- “SCHEMA VERSIONING”
Esta técnica propõe a criação de Versões do Esquema como uma forma de realizar sua
Evolução. Sua implantação no SGBD deve permitir uma navegação retroativa ou proativa entre as
Versões tanto para a realização de operações lógicas quanto físicas nas Versões.
Dependendo da implementação e Modelo de Dados, as Versões “antigas” do Esquema de
Dados podem ficar inativas indefinida ou momentaneamente, ou podem ter iguais condições de uso,
ou seja, a instanciação pode ser realizada em qualquer Versão do Esquema, e neste caso, passa a
existir o conceito de Esquema Corrente (ou Esquema Ativo, formado pelas Versões de Esquema
requisitadas) com as Instâncias sendo reconhecidas pelo SGBD somente quando sua definição está
no Esquema em uso corrente.
As Versões