CONTEÚDO
C O L E Ç Ã O I N F O>5 CONTEÚDO
BANCO DE DADOS
EQUIPE
EDIÇÃOLucia Reggiani
EDITORA DE ARTE Iara Spina
CAPACrystian Cruz (arte) e Cellus (ilustração)
COLABORADORESCarlos Chernij,
Fred Carbonare, Helio Silva, Nivaldo Foresti (texto) e Rita Del Monaco (revisão)
4<C O L E Ç Ã O I N F O
31
Linguagens: SQL é alíngua oficial
08
Evolução: o banco vai domainframe ao cluster
38
Teste: reviramos o DB2Express-C, da IBM
108
Certificação: laboratóriopara especialistas
89
Tutorial: dados Exif dasfotos para o SQL Express
42
Teste: o MySQL 5.0vem reforçado
BANCO DE DADOS
08
>
A aventura dos dados15
>
Sabe o que é tupla?24
>
Planeje bemo seu banco
31
>
O banco fala SQLquêsTESTES
34
>
Um SQL Server fácil de usar36
>
Oracle em versão light38
>
DB2 grátis comtudo dentro
42
>
O MySQL ganha músculos47
>
Missão crítica é para Postgre50
>
Firebird poupa a máquina54
>
O Access entra em reforma57
>
Administração é tudoTUTORIAIS
62
>
Tabelas sem mistério71
>
Relatório feito com views75
>
Crie pesquisas comcritérios
78
>
O phpMyAdmindoma o MySQL
83
>
Atualização é com o Ajax86
>
Pesquise bem no Access89
>
O Exif vai para o banco97
>
E-mail falso não entra100
>
O Rails faz mais rápido105
>
Controle os seus livrosCERTIFICAÇÕES
108
>
Especialistas em dados109
>
Todo mundo quer um OCP111
>
Domine o DB2 em seis etapas113
>
Craques em SQL Server 004_CONTEUDO1.qxd 25/02/2006 20:53 Page 4CONTEÚDO
C O L E Ç Ã O I N F O>5 CONTEÚDO
BANCO DE DADOS
EQUIPE
EDIÇÃOLucia Reggiani
EDITORA DE ARTE Iara Spina
CAPACrystian Cruz (arte) e Cellus (ilustração)
COLABORADORESCarlos Chernij,
Fred Carbonare, Helio Silva, Nivaldo Foresti (texto) e Rita Del Monaco (revisão)
4<C O L E Ç Ã O I N F O
31
Linguagens: SQL é alíngua oficial
08
Evolução: o banco vai domainframe ao cluster
38
Teste: reviramos o DB2Express-C, da IBM
108
Certificação: laboratóriopara especialistas
89
Tutorial: dados Exif dasfotos para o SQL Express
42
Teste: o MySQL 5.0vem reforçado
BANCO DE DADOS
08
>
A aventura dos dados15
>
Sabe o que é tupla?24
>
Planeje bemo seu banco
31
>
O banco fala SQLquêsTESTES
34
>
Um SQL Server fácil de usar36
>
Oracle em versão light38
>
DB2 grátis comtudo dentro
42
>
O MySQL ganha músculos47
>
Missão crítica é para Postgre50
>
Firebird poupa a máquina54
>
O Access entra em reforma57
>
Administração é tudoTUTORIAIS
62
>
Tabelas sem mistério71
>
Relatório feito com views75
>
Crie pesquisas comcritérios
78
>
O phpMyAdmindoma o MySQL
83
>
Atualização é com o Ajax86
>
Pesquise bem no Access89
>
O Exif vai para o banco97
>
E-mail falso não entra100
>
O Rails faz mais rápido105
>
Controle os seus livrosCERTIFICAÇÕES
108
>
Especialistas em dados109
>
Todo mundo quer um OCP111
>
Domine o DB2 em seis etapas113
>
Craques em SQL Server 004_CONTEUDO1.qxd 25/02/2006 20:53 Page 4Fundador: VICTOR CIVITA
(1907-1990)
Diretora de Redação:Sandra Carvalho
Redatora-chefe: Débora Fortes Diretor de Arte: Crystian Cruz Editores Seniores: Carlos Machado, Lucia Reggiani e Maurício Grego
Editores: Airton Lopes, André Cardozo e Eric Costa
Repórter: Silvia Balieiro Estagiários: Danilo Gregório e Paulo de Alencar Revisora: Marta Magnani Editor de Arte: Jefferson Barbato Designers: Catia Herreiro e Wagner Rodrigues Colaborador: Dagomir Marquezi Infolab: Osmar Lazarini (consultor de sistemas) Colaborador: Eduardo Kalnaitis Estagiários: Bruno Roberti, Celso Rodrigues e Valdir Fumene Junior
Info Online: Cristian Medeiros e Renata Verdasca (webmasteres) Atendimento ao leitor: Virgílio Sousa
www.info.abril.com.br
Apoio Editorial: Beatriz de Cássia Mendes, Carlos Grassetti Serviços Editoriais: Wagner Barreira Depto. de Documentação e Abril Press: Grace de Souza Correspodente Internacional: Ruth de Aquino
PUBLICIDADE CENTRALIZADA Diretores: Mariane Ortiz, Sandra Sampaio, Sérgio R. Amaral
Executivos de Negócio: Eliane Pinho, Letícia Di Lallo, Maria Luiza Marot, Marcelo Cavalheiro, Marcelo Dória,
Nilo Bastos, Pedro Bonaldi, Robson Monte, Rodrigo Toledo, Sueli Cozza, Vlamir Aderaldo, Wlamir Lino
Publicidade Regional Diretor Jacques Baisi Ricardo Publicidade Rio de Janeiro: Diretor Paulo Renato Simões Gerente de Publicidade núcleo Tecnologia: Marcos Peregrina Gomez Executivos de Negócio: Andréia Balsi,
Emiliano Hansenn, Marcello Almeida e Renata Mioli
MARKETING E CIRCULAÇÃO:
Gerente de Produto: Ricardo Fernandes, Coordenadora de eventos: Carol Fioresi, Estágiario de marketing: Maurício Simões Rodrigues Gerente de Circulação Avulsas: Maria Helena Couto Gerente de Circulação Assinaturas: Euvaldo Nadir Lima Junior
Planejamento, Controle e Operações: Diretor: Auro Iasi Gerente: Fábio Luis dos Santos Analista: Tales Bombicini Processos: Ricardo Carvalho
ASSINATURAS:
Diretora de Operações de Atendimento ao Consumidor: Ana Dávalos Diretor de Vendas: Fernando Costa Editor: Roberto Civita
Conselho Editorial:Roberto Civita (Presidente), Thomaz Souto Corrêa (Vice-Presidente), Jose Roberto Guzzo, Maurizio Mauro
Presidente Executivo: Maurizio Mauro Diretor Secretário Editorial e de Relações Institucionais: Sidnei Basile
Vice-Presidente Comercial: Deborah Wright Diretora de Publicidade Corporativa: Thais Chede Soares B. Barreto
Diretor-Geral:Jairo Mendes Leal
Diretor de Núcleo:Alexandre Caldini
INTERNATIONAL ADVERTISING SALES REPRESENTATIVES Coordinator for International Advertising: Global Advertising, Inc., 218 Olive Hill Lane, Woodside,
California 94062. UNITED STATES: CMP Worldwide Media Networks, 2800 Campus Drive, San Mateo, California 94403, tel. (650) 513 4200, fax (650) 513 4482. EUROPE: HZI International,Africa House, 64-78 Kingsway, London WC2B 6AH, tel. (20) 7242-6346, fax (20) 7404-4376. JAPAN: IMI Corporation, Matsuoka Bldg. 303, 18-25, Naka 1- chome, Kunitachi, Tokyo 186-0004, tel. (03) 3225-6866, fax (03) 3225-6877. TAIWAN: Lewis Int’l Media Services Co. Ltd., Floor 11-14 no 46, Sec 2, Tun Hua South Road, Taipei, tel. (02) 707-5519, fax (02) 709-8348
COLEÇÃO BANCO DE DADOS, edição 27, é uma publicação da Editora Abril S.A. Distribuída em todo o país pela Dinap S.A. Distribuidora Nacional de Publicações, São Paulo.
Presidente do Conselho de Administração: Roberto Civita Presidente Executivo: Maurizio Mauro
Vice-Presidentes: Deborah Wright, Eliane Lustosa, Marcio Ogliara, Valter Pasquini www.abril.com.br
IMPRESSA NA DIVISÃO GRÁFICA DA EDITORA ABRIL S.A.
Av. Otaviano Alves de Lima, 4400, CEP 02909-900 - Freguesia do Ó - São Paulo - SP
Publicações da Editora Abril: Veja: Veja, Veja São Paulo, Veja Rio, Vejas Regionais Negócios: Exame, Você S/A A Consumo/Comportamento: Núcleo Consumo: Boa Forma, Elle, Estilo, Manequim Núcleo Comportamento: Claudia, Nova Núcleo Bem-Estar: : Bons Fluidos, Saúde!, Vida Simples Turismo/Tecnologia: Núcleo Turismo: Guias Quatro Rodas, National Geographic, Viagem e Turismo Núcleo Homem: : Placar, Playboy, Quatro Rodas, Vip Núcleo Tecnologia: Info, Info Canal, Info Corporate Cultura/Jovem: Núcleo Jovem: Bizz, Capricho, Flashback, Mundo Estranho, Superinteressante, Supersurf Núcleo Infantil: Atividades, Disney, Recreio Núcleo Cultura: : Almanaque Abril, Guia do Estudante, Aventuras na História, Revista das Religiões Casa/Semanais: Núcleo Casa e Construção: Arquitetura e Construção, Casa Claudia, Claudia Cozinha Núcleo Celebridades: Contigo! Núcleo Semanais: Ana Maria, Faça e Venda, Minha Novela, Tititi, Viva! Mais Fundação Victor Civita: Nova Escola
Publicidade São Paulo www.publiabril.com.br, Classificados tel.0800-7012066, Grande São Paulo tel. 3037-2700 ESCRITÓRIOS E REPRESENTANTES DE PUBLI-CIDADE NO BRASIL: Central-SP tel. (11) 3037-6564 Bauru Gnottos Mídia Representações Comerciais, tel. (14) 3227-0378, e-mail: gnottos@gnottosmidia.com.br Belém SRS Propaganda e Representações Ltda, tel (91) 3272-8195, e-mail: tania.alves@veloxmail.com.br Belo Horizonte tel. (31) 3282-0630, fax (31) 3282-0632 Blumenau M. Marchi Representações, tel. (47) 3329-3820, fax (47) 3329-6191 Brasília Escritório: tels. (61) 3315-7554/55/56/57, fax (61) 3315-7558; Representante:
Carvalhaw Marketing Ltda., tels (61) 3426-7342/ 3223-0736/ 3225-2946/ 3223-7778, fax (61) 3321-1943, e-mail: starmkt@uol.com.br Campinas CZ Press Com. e Representações, telefax (19) 3233-7175, e-mail: czpress@czpress.com.br Campo Grande Josimar Promoções Artísticas Ltda. tel. (67) 3382-2139 e-mail: jairo_gal-vao@hotmail.com Cuiabá Fênix Propaganda Ltda., tels. (65) 9235-7446/9602-3419, e-mail: lucianooliveir@uol.com.br Curitiba Escritório: tel. (41) 3250-8000/8030/8040/8050/8080, fax (41) 3252-7110; Representante: Via Mídia Projetos Editoriais Mkt. e Repres. Ltda., telefax (41) 3234-1224, e-mail: viamidia@viamidi-apr.com.br Florianópolis Interação Publicidade Ltda. tel. (48) 3232-1617, fax (48) 3232-1782, e-mail: fgorgonio@interacaoabril.com.br Fortaleza Midiasolution Repres. e Negoc. em Meios de Comunicação, telefax (85) 3264-3939, e-mail: midiasolution@midiasolution.net Goiânia Middle West Representações Ltda., tels.(62) 3215-5158, fax (62) 3215-9007, e-mail: publicidade@middlewest.com.br Joinville Via Mídia Projetos Editoriais Mkt. e Repres. Ltda., telefax (47) 3433-2725, e-mail: viamidiajoinvil-lle@viamidiapr.com.br Manaus Paper Comunicações, telefax (92) 3656-7588, e-mail: paper@internext.com.br Maringá Atitude de Comunicação e Representação, tele-fax (44) 3028-6969, e-mail: m.atitude@uol.com.br Porto Alegre Escritório: tel. (51) 3327-2850, tele-fax (51) 3227-2855; Representante: Print Sul Veículos de Comunicação Ltda., telefax (51) 3328-1344/3823/4954, e-mail: ricardo@printsul.com.br ; Multimeios Representações Comerciais, tel.(51) 3328-1271, e-mail: multimeiosrepco@uol.com.br
Recife MultiRevistas Publicidade Ltda., telefax (81) 3327-1597, e-mail: multirevistas@uol.com.br Ribeirão Preto tel. (16) 3964-5516, fax (16) 632-0660, e-mail:
achrisos-tomo@abril.com.br Rio de Janeiro pabx: (21) 2546-8282, fax (21) 2546-8253 Salvador AGMN Consultoria Public. e Representação, tel.(71) 3341-4992/1765/9824/9827, fax: (71) 3341-4996, e-mail: abrilagm@uol.com.br Vitória ZMR - Zambra Marketing Representações, tel. (27) 3315-6952, e-mail: samuelzambrano@intervip.com.br BANCO DE DADOS_006.qxd 25/02/2006 21:02 Page 6
RECADO DA REDAÇÃO
DÁ-LHE
INFORMAÇÃO!
universo do software é grande e abriga mundos muito peculiares, como o dos bancos de dados. De obscuros repositórios dos main-frames, esses programas passaram a estrelas de todo porte, organizan-do a explosão de informações gera-das pela vida digital de pessoas e empresas. Neles, tabelas são mais que colunas e linhas, os dados se agrupam em entidades e se relacio-nam abertamente, transaciorelacio-nam, disparam gatilhos e administram res-trições. Nesse mundinho, o e/AND não soma, diminui. E quem não sabe dessa e outras pegadinhas lógicas, perde tempo fazendo besteira. É aqui que se encaixa este especial. Aos novatos, contamos a história gloriosa dos bancos de dados e des-trinchamos seus conceitos. De ban-deja, vai um roteiro para escolher o sistema gerenciador, planejar e exe-cutar o banco da melhor forma
pos-sível. Testamos as novíssimas ver-sões gratuitas dos poderosos Oracle, DB2 e SQL Server 2005, dos livres MySQL, PostgreSQL e Firebird e do beta repaginado do Access 12. Entre-gamos o jeito profissional de mon-tar tabelas e consultas, os segredos das interfaces de administração e uma porção de tutoriais com os variados bancos. Você vai saber como extrair as informações Exif das fotos digitais para o banco, criar rela-tórios com views, controlar os livros emprestados, cadastrar e-mails váli-dos e muito mais. E se a animação chegar ao ponto de devotar a carrei-ra à administcarrei-ração dos bancos de dados, estão aqui
os caminhos para as especializações mais valorizadas da área. Aproveite. LUCIA REGGIANI EDITORA DE BANCO DE DADOS
O
INFO COLEÇÃOUma publicação mensal da Editora Abril
Para contatar a redação:
atleitorinfo@abril.com.br
Para assinar a Coleção:
(11) 3347.2121 — Grande São Paulo 0800-701-2828 — Demais localidades abril.assinaturas@abril.com.br
C O L E Ç Ã O I N F O>7
HISTÓRIA
C O L E Ç Ã O I N F O>9
A AVENTURA
DOS DADOS
DO MAINFRAME À INTERNET, OS BANCOS
DE DADOS TÊM MUITO PARA CONTAR
POR TAGIL OLIVEIRA RAMOS HISTÓRIA
8<C O L E Ç Ã O I N F O
rmazenar informações organizadas e recupe-rá-las sem faltar peda-ço sempre que neces-sário. Dita assim, a missão dos
ban-cos de dados parece simples, trivial. Não deixa de ser verdade para as tecnologias atuais, que disfarçam a complexidade do processamento e do gerenciamento de dados com
in-A
terfaces gráficas e assistentes. Mas, no princípio, lidar com bases de da-dos era coisa cabeluda, encarada por mainframes.
A história dos modernos bancos de dados começa na década de 60, quando os computadores amplia-ram a capacidade de armazenamen-to e se transformaram em possibi-lidade real para as empresas. Não havia ainda o conceito elaborado de banco de dados — o armazena-mento de informação digital basea-va-se em modelos de organização do mundo físico. No início, dois
mo-delos de bancos de dados foram de-senvolvidos: o de rede (Codasyl) e o hierárquico (IMS). O acesso à ba-se de dados era complicadíssimo, e os detalhes do armazenamento de-pendiam do tipo de dado a ser ar-quivado. Acrescentar um campo ex-tra à base requeria, muitas vezes, reescrever todo o esquema que sus-tentava a aplicação. A ênfase, nes-se caso, estava nos registros a nes- se-rem processados, e não na estrutu-ra do sistema. Paestrutu-ra fazer qualquer modificação, um usuário precisaria conhecer a estrutura física da base de dados. Sistemas comerciais bem-sucedidos, como o Sabre, da IBM e da American Airlines, utilizaram por muitos anos esse tipo de modelo.
O MODELO DE CODD
No início dos anos 70, as coisas co-meçam a mudar. O pesquisador da IBM Edgar Frank Codd (1923-2003) propõe o modelo relacional para a base de dados. Mais do que isso, ele introduz uma nova maneira de pen-sar a informação digital a ser gra-vada, recuperada e gerenciada, es-tabelecendo um jeito mais compu-tacional de tratar o relacionamen-to entre os dados. Esse sistema vi-rou padrão e é usado até hoje. O modelo abstrato de Codd é a pri-meira abordagem completa para uma base de dados, o resgate das informações, manipulação, integri-dade lógica, visualização, atualiza-ção e gerenciamento. Foi concebi-do para armazenar registros de da-© ILUSTRAÇÃO PEPE CASALS
HISTÓRIA
C O L E Ç Ã O I N F O>9
A AVENTURA
DOS DADOS
DO MAINFRAME À INTERNET, OS BANCOS
DE DADOS TÊM MUITO PARA CONTAR
POR TAGIL OLIVEIRA RAMOS HISTÓRIA
8<C O L E Ç Ã O I N F O
rmazenar informações organizadas e recupe-rá-las sem faltar peda-ço sempre que neces-sário. Dita assim, a missão dos
ban-cos de dados parece simples, trivial. Não deixa de ser verdade para as tecnologias atuais, que disfarçam a complexidade do processamento e do gerenciamento de dados com
in-A
terfaces gráficas e assistentes. Mas, no princípio, lidar com bases de da-dos era coisa cabeluda, encarada por mainframes.
A história dos modernos bancos de dados começa na década de 60, quando os computadores amplia-ram a capacidade de armazenamen-to e se transformaram em possibi-lidade real para as empresas. Não havia ainda o conceito elaborado de banco de dados — o armazena-mento de informação digital basea-va-se em modelos de organização do mundo físico. No início, dois
mo-delos de bancos de dados foram de-senvolvidos: o de rede (Codasyl) e o hierárquico (IMS). O acesso à ba-se de dados era complicadíssimo, e os detalhes do armazenamento de-pendiam do tipo de dado a ser ar-quivado. Acrescentar um campo ex-tra à base requeria, muitas vezes, reescrever todo o esquema que sus-tentava a aplicação. A ênfase, nes-se caso, estava nos registros a nes- se-rem processados, e não na estrutu-ra do sistema. Paestrutu-ra fazer qualquer modificação, um usuário precisaria conhecer a estrutura física da base de dados. Sistemas comerciais bem-sucedidos, como o Sabre, da IBM e da American Airlines, utilizaram por muitos anos esse tipo de modelo.
O MODELO DE CODD
No início dos anos 70, as coisas co-meçam a mudar. O pesquisador da IBM Edgar Frank Codd (1923-2003) propõe o modelo relacional para a base de dados. Mais do que isso, ele introduz uma nova maneira de pen-sar a informação digital a ser gra-vada, recuperada e gerenciada, es-tabelecendo um jeito mais compu-tacional de tratar o relacionamen-to entre os dados. Esse sistema vi-rou padrão e é usado até hoje. O modelo abstrato de Codd é a pri-meira abordagem completa para uma base de dados, o resgate das informações, manipulação, integri-dade lógica, visualização, atualiza-ção e gerenciamento. Foi concebi-do para armazenar registros de da-© ILUSTRAÇÃO PEPE CASALS
HISTÓRIA
C O L E Ç Ã O I N F O>11
deira. A primeira de-las, conhecida como “Lei da Informação”, dizia simplesmente que todo dado deve ser apresentado ao usuário na forma de tabela. A segunda, ou “Regra do Acesso Ga-rantido”, exige que todo dado seja
aces-sível sem ambigüidade e aconselha que cada informação seja descrita por uma combinação de nome da tabela, chave primária e o nome do campo. E assim por diante.
O mesmo Codd cunharia o nome OLAP (On-Line Analytical Proces-sing) para descrever uma ampla ca-tegoria de produtos de software que tinham as características de acesso aos dados propostas por ele. As 12 Regras de seu padrão foram adota-das pela indústria de TI, forçando muitas empresas a revisar seus pro-dutos para melhor se adequar aos critérios OLAP de Codd.
Em 1976, outro avanço viria das pes-quisas de Peter P. Chen. Ele propõe o modelo
Entidade-Relacio-namento (ER) para o design de banco de dados, dando um importante passo para a modelagem de alto nível e permitindo ao desenvol-vedor concentrar-se mais no uso das informações do que propriamente na estru-tura lógica que há por trás da tabela.
SURGE O DBASE
A evolução natural dos bancos de dados passaria pelo estabelecimen-to de um padrão não-teórico: o dBa-se, ao ser lançado no final dos anos 70, tornou-se uma referência. Sua origem encontra-se em meados dos anos 60. Seu antecessor era um sis-tema chamado Retrieve, vendido pe-la Tymshare Corporation. Naquepe-la época, os computadores só eram encontrados em grandes gabinetes, no ambiente do trabalho.
O Retrieve era usado no Jet Pro-pulsion Laboratory (JPL), em Pasa-dena, na Califórnia. Nos anos 60, Jeb Long, um programador desse laboratório, recebeu a tarefa de es-crever um programa que desempenhasse as mes-mas funções que o Retrie-ve. Em 1973, ele se tornou engenheiro de software do JPL. Ali ele desenvol-veu um programa de ge-renciamento de arquivos chamado JPLDIS (Jet Pro-pulsion Laboratory Dis-play Information System), HISTÓRIA
10<C O L E Ç Ã O I N F O dos com estruturas relati-vamente simples e proces-sar transações simples.
A idéia começou a ser desenvolvida por Codd du-rante seu doutorado na Universidade de Michigan. Em sua tese, ele apresen-tava uma espécie de “au-to-reprodução” feita em programas de
computa-dores. O trabalho foi publicado em 1967 no livro Cellular Automata, pu-blicado pela Academic Press. A idéia era tão avançada que levou uma dé-cada para ser digerida.
Pelo menos dois protótipos prin-cipais de sistemas relacionais foram desenvolvidos entre 1974 e 1977, mostrando aplicações práticas do que só existia na teoria.
Um dos protótipos era o Ingres, desenvolvido na Universidade Berkeley, que seria seguido pela In-gres Corporation, Sybase, MS SQL Server e Britton-Lee, dentre outras.
Esse tipo de sistema usa QUEL como linguagem de pesquisa das bases de da-dos. O segundo protótipo, conhecido como System R, foi desenvolvido pela IBM em San Jose, Califór-nia, e levou ao SQL/DS & DB2, da própria empresa, seguido por Oracle e HP. Nesse sistema, é utiliza-da a SEQUEL como linguagem de pesquisa de dados. Originalmente, as aplicações foram desenvolvidas para os enormes mainframes.
AS DOZE REGRAS
O termo “relação” era usado por Codd de maneira estritamente ma-temática, dentro de uma tabela com linhas e colunas que trabalhavam com propriedades especiais. Embo-ra isso pareça óbvio atualmente, não era nada elementar nos anos 70. Tanto que Codd sentiu a necessida-de necessida-de estabelecer as 12 regras necessida-de uma base de dados relacional, uma re-ceita para extrair do modelo algo que funcionasse mesmo. Isso aconteceu em 1974 e foi expandido ao longo das déca-das. Em 1990, a lista cresceu para 333 re-querimentos.
Vistas com os olhos de hoje, as 12 leis parecem
brinca-Mapa de relacionamento: a teoria de Codd na prática
dBase III: padrão de banco de dados para PCs nos anos 80 Edgar Codd: pai do
modelo relacional
Peter Chen: novo
modelo de design
© FOTO DIVULGAÇÃO IBM © FOTO DIVULGAÇÃO 08_14_BANCO_HISTORIA1 25/02/2006 21:15 Page 10
HISTÓRIA
C O L E Ç Ã O I N F O>11
deira. A primeira de-las, conhecida como “Lei da Informação”, dizia simplesmente que todo dado deve ser apresentado ao usuário na forma de tabela. A segunda, ou “Regra do Acesso Ga-rantido”, exige que todo dado seja
aces-sível sem ambigüidade e aconselha que cada informação seja descrita por uma combinação de nome da tabela, chave primária e o nome do campo. E assim por diante.
O mesmo Codd cunharia o nome OLAP (On-Line Analytical Proces-sing) para descrever uma ampla ca-tegoria de produtos de software que tinham as características de acesso aos dados propostas por ele. As 12 Regras de seu padrão foram adota-das pela indústria de TI, forçando muitas empresas a revisar seus pro-dutos para melhor se adequar aos critérios OLAP de Codd.
Em 1976, outro avanço viria das pes-quisas de Peter P. Chen. Ele propõe o modelo
Entidade-Relacio-namento (ER) para o design de banco de dados, dando um importante passo para a modelagem de alto nível e permitindo ao desenvol-vedor concentrar-se mais no uso das informações do que propriamente na estru-tura lógica que há por trás da tabela.
SURGE O DBASE
A evolução natural dos bancos de dados passaria pelo estabelecimen-to de um padrão não-teórico: o dBa-se, ao ser lançado no final dos anos 70, tornou-se uma referência. Sua origem encontra-se em meados dos anos 60. Seu antecessor era um sis-tema chamado Retrieve, vendido pe-la Tymshare Corporation. Naquepe-la época, os computadores só eram encontrados em grandes gabinetes, no ambiente do trabalho.
O Retrieve era usado no Jet Pro-pulsion Laboratory (JPL), em Pasa-dena, na Califórnia. Nos anos 60, Jeb Long, um programador desse laboratório, recebeu a tarefa de es-crever um programa que desempenhasse as mes-mas funções que o Retrie-ve. Em 1973, ele se tornou engenheiro de software do JPL. Ali ele desenvol-veu um programa de ge-renciamento de arquivos chamado JPLDIS (Jet Pro-pulsion Laboratory Dis-play Information System), HISTÓRIA
10<C O L E Ç Ã O I N F O dos com estruturas relati-vamente simples e proces-sar transações simples.
A idéia começou a ser desenvolvida por Codd du-rante seu doutorado na Universidade de Michigan. Em sua tese, ele apresen-tava uma espécie de “au-to-reprodução” feita em programas de
computa-dores. O trabalho foi publicado em 1967 no livro Cellular Automata, pu-blicado pela Academic Press. A idéia era tão avançada que levou uma dé-cada para ser digerida.
Pelo menos dois protótipos prin-cipais de sistemas relacionais foram desenvolvidos entre 1974 e 1977, mostrando aplicações práticas do que só existia na teoria.
Um dos protótipos era o Ingres, desenvolvido na Universidade Berkeley, que seria seguido pela In-gres Corporation, Sybase, MS SQL Server e Britton-Lee, dentre outras.
Esse tipo de sistema usa QUEL como linguagem de pesquisa das bases de da-dos. O segundo protótipo, conhecido como System R, foi desenvolvido pela IBM em San Jose, Califór-nia, e levou ao SQL/DS & DB2, da própria empresa, seguido por Oracle e HP. Nesse sistema, é utiliza-da a SEQUEL como linguagem de pesquisa de dados. Originalmente, as aplicações foram desenvolvidas para os enormes mainframes.
AS DOZE REGRAS
O termo “relação” era usado por Codd de maneira estritamente ma-temática, dentro de uma tabela com linhas e colunas que trabalhavam com propriedades especiais. Embo-ra isso pareça óbvio atualmente, não era nada elementar nos anos 70. Tanto que Codd sentiu a necessida-de necessida-de estabelecer as 12 regras necessida-de uma base de dados relacional, uma re-ceita para extrair do modelo algo que funcionasse mesmo. Isso aconteceu em 1974 e foi expandido ao longo das déca-das. Em 1990, a lista cresceu para 333 re-querimentos.
Vistas com os olhos de hoje, as 12 leis parecem
brinca-Mapa de relacionamento: a teoria de Codd na prática
dBase III: padrão de banco de dados para PCs nos anos 80 Edgar Codd: pai do
modelo relacional
Peter Chen: novo
modelo de design
© FOTO DIVULGAÇÃO IBM © FOTO DIVULGAÇÃO 08_14_BANCO_HISTORIA1 25/02/2006 21:15 Page 10
HISTÓRIA
C O L E Ç Ã O I N F O>13
HISTÓRIA
12<C O L E Ç Ã O I N F O © FOTO DIVULGAÇÃO RATLIFF SOFTWARE PRODUCTIONS escrito na linguagem
For-tran para rodar num main-frame Univac 1108.
O JPLDIS foi, assim, a mãe da linguagem dBase, que passou a rodar em mi-crocomputadores com o sistema CP/M. Criada por um jovem programador do JPL, Wayne Ratliff, seu grande sucesso baseava-se na simplicidade. Os
co-mandos seguiam a lógica das pala-vras inglesas: use, find, list etc. No dBase, Ratliff partia de uma idéia também simples: desenvolver um programa de banco de dados para desktop baseado naquele que roda-va nos mainframes de seu trabalho. Fez tudo isso num computador mon-tado em sua casa.
Foi um grande progresso para a época. Não somente o programa criava tabelas e guardava dados, mas tinha a capacidade de criar pro-gramas ASCII (como arquivos batch do DOS), que podiam então exibir e imprimir as informações requisi-tadas. Ratliff batizou seu software de Vulcan (em homenagem ao Sr.
Spock, do filme Jornada nas Estrelas) e começou a vendê-lo por reembol-so postal.
Mais tarde, Long asso-ciou-se a Ratliff e traduziu aquela versão original do dBase II para rodar no IBM PC. Todo o trabalho foi fei-to em linguagem As-sembly. Jeb Long foi um dos fundadores da empre-sa Ashton-Tate, ficou conhecido com um dos gurus do dBase e como res-ponsável também pelas versões dBase III e dBase IV.
AS LINGUAGENS
Em 1984 surgiu o Clipper, linguagem de programação compatível com o dBase III Plus, com desempenho de-zenas de vezes mais rápido que o dBase original. Até meados da dé-cada de 90, o Clipper era o líder do mercado de linguagens de desen-volvimento para micros. A partir daí, as linguagens visuais, criadas para rodar no ambiente Windows, começam a ganhar terreno.
Quando os bancos de dados rela-cionais estavam sen-do desenvolvisen-dos, fo-ram criadas lingua-gens destinadas à sua manipulação. O de-partamento de pes-quisa da IBM desen-volveu a linguagem SQL (Structured Query Language) nos
anos 70. Somente em 1986 o American National Standards Institute (ANSI) pu-blicou o SQL como um padrão. A partir daí, o SQL passou a ser usado pela maio-ria das empresas.
Ao longo dos anos 80, a linguagem SQL torna-se praticamen-te universal. Por sua
vez, o DB2, da IBM, passou a ser o car-ro-chefe da empresa nesse segmen-to, que começa a experimentar ex-pressivo crescimento. Ao mesmo tem-po, as redes locais ganham espaço nas empresas, e o DB2 se mantém co-mo uma das fortes referências em bancos de dados corporativos.
CHEGAM OS PCS
Com a entrada dos PCs em cena, as companhias de banco de dados têm um crescimento notável. Novos no-mes dominam o cenário do software, como RIM, RBase 5000, Paradox, dBase, FoxBase e FoxPro. A transi-ção para a década de 90 deixa pou-cas empresas da geração anterior como sobreviventes. O modelo clien-te-servidor torna-se a norma para as futuras decisões de negócio, ao mesmo tempo em que se verifica o estabelecimento das ferramentas de produtividade pessoal, como Excel e Access. É também um marco ini-cial para os protótipos dos bancos de dados orientados a objeto, ou
Objec t Database Management Systems (ODBMS).
O fenômeno da internet vem sacu-dir o ambiente de TI em meados dos anos 90. Começa-se a exigir de ma-neira frenética o acesso de compu-tadores remotos aos dados guarda-dos nos sistemas legaguarda-dos. Na outra ponta, os bancos de dados se adap-tam para servir às demandas da web — o que significa acesso às informa-ções, de qualquer lugar, via browser.
No final dos anos 90, o intenso in-vestimento das empresas na inter-net abastece o mercado com cente-nas de ferramentas para conectar os bancos de dados à web. Crescem as ofertas de novos produtos e no-vas tecnologias. Com o passar do tempo, destacam-se duas áreas bá-sicas: de um lado, as soluções ba-seadas na plataforma Java, da Sun. Empresas como a própria Sun, além de IBM e Oracle, têm bancos de da-dos ou ferramentas para desenvol-vimento nessa área. Do outro lado, estão as empresas que oferecem
FoxPro para DOS: gerenciador baseado em dBase
DB2, da IBM: referência em banco de dados corporativo Wayne Ratliff:
criador do Vulcan 08_14_BANCO_HISTORIA1 25/02/2006 21:26 Page 12
HISTÓRIA
C O L E Ç Ã O I N F O>13
HISTÓRIA
12<C O L E Ç Ã O I N F O © FOTO DIVULGAÇÃO RATLIFF SOFTWARE PRODUCTIONS escrito na linguagem
For-tran para rodar num main-frame Univac 1108.
O JPLDIS foi, assim, a mãe da linguagem dBase, que passou a rodar em mi-crocomputadores com o sistema CP/M. Criada por um jovem programador do JPL, Wayne Ratliff, seu grande sucesso baseava-se na simplicidade. Os
co-mandos seguiam a lógica das pala-vras inglesas: use, find, list etc. No dBase, Ratliff partia de uma idéia também simples: desenvolver um programa de banco de dados para desktop baseado naquele que roda-va nos mainframes de seu trabalho. Fez tudo isso num computador mon-tado em sua casa.
Foi um grande progresso para a época. Não somente o programa criava tabelas e guardava dados, mas tinha a capacidade de criar pro-gramas ASCII (como arquivos batch do DOS), que podiam então exibir e imprimir as informações requisi-tadas. Ratliff batizou seu software de Vulcan (em homenagem ao Sr.
Spock, do filme Jornada nas Estrelas) e começou a vendê-lo por reembol-so postal.
Mais tarde, Long asso-ciou-se a Ratliff e traduziu aquela versão original do dBase II para rodar no IBM PC. Todo o trabalho foi fei-to em linguagem As-sembly. Jeb Long foi um dos fundadores da empre-sa Ashton-Tate, ficou conhecido com um dos gurus do dBase e como res-ponsável também pelas versões dBase III e dBase IV.
AS LINGUAGENS
Em 1984 surgiu o Clipper, linguagem de programação compatível com o dBase III Plus, com desempenho de-zenas de vezes mais rápido que o dBase original. Até meados da dé-cada de 90, o Clipper era o líder do mercado de linguagens de desen-volvimento para micros. A partir daí, as linguagens visuais, criadas para rodar no ambiente Windows, começam a ganhar terreno.
Quando os bancos de dados rela-cionais estavam sen-do desenvolvisen-dos, fo-ram criadas lingua-gens destinadas à sua manipulação. O de-partamento de pes-quisa da IBM desen-volveu a linguagem SQL (Structured Query Language) nos
anos 70. Somente em 1986 o American National Standards Institute (ANSI) pu-blicou o SQL como um padrão. A partir daí, o SQL passou a ser usado pela maio-ria das empresas.
Ao longo dos anos 80, a linguagem SQL torna-se praticamen-te universal. Por sua
vez, o DB2, da IBM, passou a ser o car-ro-chefe da empresa nesse segmen-to, que começa a experimentar ex-pressivo crescimento. Ao mesmo tem-po, as redes locais ganham espaço nas empresas, e o DB2 se mantém co-mo uma das fortes referências em bancos de dados corporativos.
CHEGAM OS PCS
Com a entrada dos PCs em cena, as companhias de banco de dados têm um crescimento notável. Novos no-mes dominam o cenário do software, como RIM, RBase 5000, Paradox, dBase, FoxBase e FoxPro. A transi-ção para a década de 90 deixa pou-cas empresas da geração anterior como sobreviventes. O modelo clien-te-servidor torna-se a norma para as futuras decisões de negócio, ao mesmo tempo em que se verifica o estabelecimento das ferramentas de produtividade pessoal, como Excel e Access. É também um marco ini-cial para os protótipos dos bancos de dados orientados a objeto, ou
Objec t Database Management Systems (ODBMS).
O fenômeno da internet vem sacu-dir o ambiente de TI em meados dos anos 90. Começa-se a exigir de ma-neira frenética o acesso de compu-tadores remotos aos dados guarda-dos nos sistemas legaguarda-dos. Na outra ponta, os bancos de dados se adap-tam para servir às demandas da web — o que significa acesso às informa-ções, de qualquer lugar, via browser.
No final dos anos 90, o intenso in-vestimento das empresas na inter-net abastece o mercado com cente-nas de ferramentas para conectar os bancos de dados à web. Crescem as ofertas de novos produtos e no-vas tecnologias. Com o passar do tempo, destacam-se duas áreas bá-sicas: de um lado, as soluções ba-seadas na plataforma Java, da Sun. Empresas como a própria Sun, além de IBM e Oracle, têm bancos de da-dos ou ferramentas para desenvol-vimento nessa área. Do outro lado, estão as empresas que oferecem
FoxPro para DOS: gerenciador baseado em dBase
DB2, da IBM: referência em banco de dados corporativo Wayne Ratliff:
criador do Vulcan 08_14_BANCO_HISTORIA1 25/02/2006 21:26 Page 12
HISTÓRIA
14<C O L E Ç Ã O I N F O
produtos fundamentados nas tec-nologias ASP e, mais recentemen-te, .Net, da Microsoft. No item es-pecífico dos gerenciadores de ban-cos de dados, os grandes nomes são IBM, Oracle e Microsoft. Com a ex-pansão da conectividade, os ban-cos de dados estendem as possibi-lidades de acesso até aos PDAs.
AOS TERABYTES
Mas as tendências apontam para sistemas de alto nível de armaze-namento (da ordem de terabytes) que exigem rapidez e confiabili-dade de processamento, manuseio e análise dos dados. Projetos gran-diosos, como o Genoma, apontam para esse tipo de demanda. Ao mesmo tempo, bases de dados geológicos, meteorológicos e es-paciais requerem mais velocida-de e segurança. Também se tor-nam comuns as aplicações empre-sariais de data mining, data ware-house e data marts. Esses usos do
banco de dados exigem gerencia-dores capazes de dar respostas rá-pidas às empresas.
Nessa área, a Oracle se destaca como o maior fornecedor de ban-cos de dados corporativos. Desde 1985, o produto passou a tirar pro-veito da disseminação das redes lo-cais, dando suporte ao modelo clien-te-servidor. O Oracle 5, dessa épo-ca, suportava consultas distribuí-das. Em 1988, surgiu a versão 8, com suporte ao desenvolvimento orien-tado a objeto e aplicações multimí-dia. Em 1999, sai a versão 8i — i de internet. O número atual é 10g, sen-do o g indicativo da capacidade de funcionar num grid de servidores. O Oracle também foi o primeiro ban-co de dados ban-comercial a oferecer uma versão para Linux.
Finalmente, deve-se prestar atenção ao crescimento das plata-formas de código aberto, notada-mente o Linux. Junto com ele, des-pontam bancos de dados como o MySQL, utilizado em aplicações web. Es-sa mudança em di-reção ao software li-vre pode redefinir o perfil do mercado de banco de dados, em especial na fai-xa das aplicações médias e pequenas, a curto prazo, mas abarcando as gran-des aplicações, a longo prazo.
Oracle 10g: gerenciador de bancos de dados para clusters
SABE O QUE
É TUPLA?
ENTENDA OS CONCEITOS QUE FAZEM DO BANCO DE DADOS
UM MUNDO À PARTE NO UNIVERSO DO SOFTWARE
POR CELSO HENRIQUE PODEROSO DE OLIVEIRA
CONCEITOS
C O L E Ç Ã O I N F O>15
odo mundo que usa te-lefone possui uma agen-da. Nela, cada amigo tem nome, endereço, número da linha, data de aniversá-rio e e-mail, cada dado anotado num espaço especial. Quando precisa-mos ligar para algum contato, va-mos à letra inicial do nome e bus-camos o número do telefone. Essa agendinha quase banal expressa
bem o que é um banco de dados — um armazém de informações rele-vantes, organizadas de maneira coe-rente e lógica, que precisam ser re-cuperadas com freqüência.
No universo dos bits e bytes, o banco de dados envolve conceitos importantes, que precisamos enten-der bem para torná-lo útil e eficien-te. É disso que trataremos aqui, co-meçando pelo próprio.
T
Sistema gerenciador: coleção de programas que mantêm as estruturas do banco
CONCEITOS
C O L E Ç Ã O I N F O>17
CONCEITOS
16<C O L E Ç Ã O I N F O
acesso, redundância e integridade, o compartilhamento de dados e o me-canismo de cópias de segurança.
MODELAGEM DE DADOS
Processo pelo qual trabalham-se os dados de uma empresa ou sistema para se obter estruturas de armaze-namento estáveis. O processo de aná-lise pode se dar por meio da criação do Modelo de Entidade X Relaciona-mento ou pela Normalização de Da-dos. O objetivo da modelagem é fa-zer com que as estruturas possam evoluir no tempo, sem prejudicar o desenvolvimento de sistemas.
MODELO DE ENTIDADE X RELACIONAMENTO
Modelo que contém as entidades de um sistema e o relacionamento en-tre elas. Deve ser entendido como uma representação da realidade. Co-mo sempre é possível Co-modificar a realidade de um sistema, deve ser prevista a evolução do modelo.
ENTIDADE
Entende-se como um grupo de coi-sas semelhantes. Escoi-sas coicoi-sas podem ter uma existência física (pessoa, car-ro, imóvel), ser um documento
(no-ta fiscal, pedido de compra, ordem de serviço), um local (armazém, se-de, filial) ou qualquer outro objeto do mundo real. Cada entidade deve pos-suir diversas instâncias do objeto que representa. Vamos exemplificar com os automóveis. A entidade é o gru-po carro. A instância é o objeto Hon-da Civic, Peugeot 206, VW Gol.
Quando se transpõe a entidade pa-ra um modelo físico, tem-se a tabe-la (no modelo retabe-lacional) ou a ctabe-lasse (no modelo orientado a objeto). Uma entidade é representada por um re-tângulo com o respectivo nome.
ATRIBUTO
Qualificador lógico de um objeto, ser-ve para descreser-ver ou caracterizar os elementos de uma entidade. Cada atri-buto deve conter apenas uma carac-terística do objeto. Esse ponto é im-portante para não confundirmos atri-buto com entidade.
Um objeto deve ter algumas carac-terísticas específicas. Cada uma delas será um atributo do objeto. O inver-so é também verdadeiro: um atribu-to não pode ter subdivisões. Se utili-zar o exemplo da entidade carro, po-demos ter atributos como nome, mon-tadora, modelo etc.
Quando se transpõe para o mode-lo físico, os atributos se transformam em colunas ou campos no modelo
re-lacional e em atributos ou proprieda-des no modelo orientado a objetos. Os atributos são colocados dentro do retângulo que representa a entidade e abaixo do nome da própria.
TUPLA
Nada mais é do que o conjunto de ca-racterísticas do objeto que se quer presentar, a estrutura de atributos re-lacionados e interdependentes. A tu-pla seria a linha ou o registro de uma tabela no modelo relacional e a ins-tância no modelo orientado a objetos.
TABELA
Estrutura composta por linhas e co-lunas que serve para armazenar os dados em um banco de dados rela-cional. A linha indica uma ocorrên-cia do objeto do mundo real, e a co-luna serve para qualificar o objeto. Dessa forma, se imaginarmos uma tabela PESSOA, ela teria em cada li-nha uma pessoa e em cada coluna as informações relevantes dessa pes-soa, como nome, peso, altura, data de nascimento, documento de iden-tificação, cor dos olhos, cor dos
ca-Interface DB2: administração gráfica
Modelo: entidade x relacionamento
Entidade: grupo de coisas semelhantes
Tabela: estrutura com linhas e colunas
BANCO DE DADOS
Defini-lo como uma ou mais tabelas de dados relacionadas ou não é pos-sível. Mas podemos acrescentar à lis-ta de componentes os índices, visões (views), procedimentos (procedures), funções, gatilhos (triggers) etc. Tudo depende do tipo de banco de dados e do que se quer fazer com ele. Par-tindo-se desse princípio, podem ser considerados banco de dados os ar-quivos DBF que foram muito popu-lares na década de 80 com a lingua-gem Clipper, um arquivo MDB do MS Access ou mesmo arquivos DAT, pro-prietários de linguagens de terceira geração como Pascal e Cobol.
SISTEMA GERENCIADOR
É uma coleção de programas rponsáveis pela manutenção das es-truturas e objetos de um banco de dados. Há diversos produtos comer-ciais e de uso livre. Entre os pagos destacam-se Oracle, IBM DB2 e MS SQL Server. Entre os livres, MySQL, Firebird e PostgreSQL.
Os gerenciadores têm como carac-terísticas principais os controles de 015_CONCEITOS 25/02/2006 21:32 Page 16
CONCEITOS
C O L E Ç Ã O I N F O>17
CONCEITOS
16<C O L E Ç Ã O I N F O
acesso, redundância e integridade, o compartilhamento de dados e o me-canismo de cópias de segurança.
MODELAGEM DE DADOS
Processo pelo qual trabalham-se os dados de uma empresa ou sistema para se obter estruturas de armaze-namento estáveis. O processo de aná-lise pode se dar por meio da criação do Modelo de Entidade X Relaciona-mento ou pela Normalização de Da-dos. O objetivo da modelagem é fa-zer com que as estruturas possam evoluir no tempo, sem prejudicar o desenvolvimento de sistemas.
MODELO DE ENTIDADE X RELACIONAMENTO
Modelo que contém as entidades de um sistema e o relacionamento en-tre elas. Deve ser entendido como uma representação da realidade. Co-mo sempre é possível Co-modificar a realidade de um sistema, deve ser prevista a evolução do modelo.
ENTIDADE
Entende-se como um grupo de coi-sas semelhantes. Escoi-sas coicoi-sas podem ter uma existência física (pessoa, car-ro, imóvel), ser um documento
(no-ta fiscal, pedido de compra, ordem de serviço), um local (armazém, se-de, filial) ou qualquer outro objeto do mundo real. Cada entidade deve pos-suir diversas instâncias do objeto que representa. Vamos exemplificar com os automóveis. A entidade é o gru-po carro. A instância é o objeto Hon-da Civic, Peugeot 206, VW Gol.
Quando se transpõe a entidade pa-ra um modelo físico, tem-se a tabe-la (no modelo retabe-lacional) ou a ctabe-lasse (no modelo orientado a objeto). Uma entidade é representada por um re-tângulo com o respectivo nome.
ATRIBUTO
Qualificador lógico de um objeto, ser-ve para descreser-ver ou caracterizar os elementos de uma entidade. Cada atri-buto deve conter apenas uma carac-terística do objeto. Esse ponto é im-portante para não confundirmos atri-buto com entidade.
Um objeto deve ter algumas carac-terísticas específicas. Cada uma delas será um atributo do objeto. O inver-so é também verdadeiro: um atribu-to não pode ter subdivisões. Se utili-zar o exemplo da entidade carro, po-demos ter atributos como nome, mon-tadora, modelo etc.
Quando se transpõe para o mode-lo físico, os atributos se transformam em colunas ou campos no modelo
re-lacional e em atributos ou proprieda-des no modelo orientado a objetos. Os atributos são colocados dentro do retângulo que representa a entidade e abaixo do nome da própria.
TUPLA
Nada mais é do que o conjunto de ca-racterísticas do objeto que se quer presentar, a estrutura de atributos re-lacionados e interdependentes. A tu-pla seria a linha ou o registro de uma tabela no modelo relacional e a ins-tância no modelo orientado a objetos.
TABELA
Estrutura composta por linhas e co-lunas que serve para armazenar os dados em um banco de dados rela-cional. A linha indica uma ocorrên-cia do objeto do mundo real, e a co-luna serve para qualificar o objeto. Dessa forma, se imaginarmos uma tabela PESSOA, ela teria em cada li-nha uma pessoa e em cada coluna as informações relevantes dessa pes-soa, como nome, peso, altura, data de nascimento, documento de iden-tificação, cor dos olhos, cor dos
ca-Interface DB2: administração gráfica
Modelo: entidade x relacionamento
Entidade: grupo de coisas semelhantes
Tabela: estrutura com linhas e colunas
BANCO DE DADOS
Defini-lo como uma ou mais tabelas de dados relacionadas ou não é pos-sível. Mas podemos acrescentar à lis-ta de componentes os índices, visões (views), procedimentos (procedures), funções, gatilhos (triggers) etc. Tudo depende do tipo de banco de dados e do que se quer fazer com ele. Par-tindo-se desse princípio, podem ser considerados banco de dados os ar-quivos DBF que foram muito popu-lares na década de 80 com a lingua-gem Clipper, um arquivo MDB do MS Access ou mesmo arquivos DAT, pro-prietários de linguagens de terceira geração como Pascal e Cobol.
SISTEMA GERENCIADOR
É uma coleção de programas rponsáveis pela manutenção das es-truturas e objetos de um banco de dados. Há diversos produtos comer-ciais e de uso livre. Entre os pagos destacam-se Oracle, IBM DB2 e MS SQL Server. Entre os livres, MySQL, Firebird e PostgreSQL.
Os gerenciadores têm como carac-terísticas principais os controles de 015_CONCEITOS 25/02/2006 21:32 Page 16
CONCEITOS
18<C O L E Ç Ã O I N F O
cal, por exemplo, o número da no-ta não se repete e é obrigatório. Por isso poderá ser candidato para a co-luna chave. Uma chave geralmente está destacada por um símbolo (as-terisco ou uma pequena chave) ao lado do atributo correspondente.
Quando se analisa o modelo físi-co, uma chave pode ser classifica-da como:
■PRIMÁRIA: qualificador único e obrigatório. Deve haver uma única chave primária em cada tabela.
■ESTRANGEIRA: serve para rela-cionar duas tabelas. Vamos voltar ao exemplo da Nota Fiscal. Cada no-ta está relacionada a um cliente. No-ta Fiscal é uma No-tabela e cliente ou-tra. Cada tabela tem a sua própria chave primária. Para relacionar o cliente com a nota fiscal, deixamos uma referência à coluna chave do cliente na tabela nota fiscal (chave estrangeira).
■SECUNDÁRIA classifica os dados nas tabelas. Geralmente, os índices têm o objetivo de agilizar o proces-so de busca.
RELACIONAMENTO
Se uma entidade é um conjunto de coisas semelhantes, é natural que essas coisas guardem algum tipo de relacionamento que seja impor-tante recuperar em algum momen-to. Quando dizemos que uma nota fiscal é emitida contra um cliente, podemos entender que estamos tra-tando de duas entidades diferen-tes: Nota Fiscal e Cliente. Há, entre
Chaves: qualificadores das entidades
belos etc. A idéia central é que as ca-racterísticas do objeto permitam iden-tificar uma única pessoa em cada li-nha da tabela.
CHAVE
Um ou mais atributos que permi-tem identificar uma única ocorrên-cia na entidade. É um qualificador único. No modelo físico, a chave é o campo ou a coluna que contém um valor exclusivo e com preenchi-mento obrigatório. Assim, não po-derá haver o mesmo conteúdo da coluna em duas linhas diferentes.
Imagine uma chave para PESSOA. Nome seria uma boa coluna para chave? Naturalmente não, pois há pessoas que têm nomes iguais. CPF seria uma boa chave? Em alguns ca-sos sim, pois embora não tenha re-petição e seja um documento obri-gatório para os adultos, não é para os bebês. O que normalmente acon-tece em casos como esse é criar-mos uma coluna.
Em alguns outros exemplos, a cha-ve seria localizada com mais facili-dade. Se analisarmos uma Nota Fis-015_CONCEITOS 25/02/2006 21:33 Page 18
CONCEITOS
C O L E Ç Ã O I N F O>19
essas duas entidades, uma relação de interdependência, ou seja, para se emitir uma Nota Fiscal, é neces-sário que haja um Cliente. A essa interdependência damos o nome de relacionamento. Na prática, sem-pre que uma ou mais tuplas de uma entidade guardarem alguma rela-ção com uma ou mais tuplas de ou-tra entidade teremos um relaciona-mento entre as entidades.
Um relacionamento pode ser clas-sificado de duas formas: opcionali-dade e cardinaliopcionali-dade.
A opcionalidade indica se é obri-gatória ou não a ocorrência ou in-dicação de uma tupla de uma en-tidade na outra. Dessa forma, po-demos dizer que é obrigatória a presença de um Cliente em uma Nota Fiscal, mas é opcional a exis-tência de uma Transportadora, por exemplo. De outro lado, o Cliente pode ou não estar vinculado a uma Nota Fiscal. O mesmo acontece com a Transportadora.
A cardinalidade indica quantas ocorrências de uma tupla se rela-cionam com a outra tupla. Sabemos que cada Cliente pode estar vincu-lado a zero, uma ou muitas Notas Fiscais, enquanto cada Nota Fiscal está relacionada a um único Clien-te. Como você pode notar, a cardi-nalidade e a opciocardi-nalidade são sem-pre exsem-pressas de um e de outro la-do la-do relacionamento.
A cardinalidade pode ser:
■UM PARA UM (1:1): quando cada tupla de uma entidade está
relacio-nada apenas a zero ou a uma tupla da outra entidade (lembre-se que ze-ro ou um é a opcionalidade). Esse ti-po de relacionamento não é o mais comum, pois sempre se deve ques-tionar a vantagem de manter os da-dos separada-dos em duas entidades. Note que sempre há um custo vincu-lado à criação e manutenção de uma tabela. Se o custo compensar, deve-se manter deve-separado. Do contrário, é melhor unir as duas entidades.
■UM PARA MUITOS (1:M): quan-do cada tupla de uma entidade es-tá relacionada a zero, uma ou mais tuplas da outra entidade (não es-queça que o zero ou um é a opcio-nalidade). Este é o relacionamento mais comum.
■MUITOS PARA MUITOS (M:M): quando há ocorrências de múltiplos relacionamentos entre as tuplas de duas entidades. Esse relacionamen-to, apesar de existir, não é passível de implementação em um banco de
Relacionamento: muitos para muitos
(acima); um para muitos (abaixo) 015_CONCEITOS 25/02/2006 21:34 Page 19
CONCEITOS
C O L E Ç Ã O I N F O>21
CONCEITOS
20<C O L E Ç Ã O I N F O
dados relacional. Sempre que se identificar essa situação, deve-se criar uma entidade entre as duas entidades, classificadas como fun-damentais. Essa nova entidade, clas-sificada como entidade associativa, deve conter, pelo menos, as chaves das duas entidades fundamentais. Uma das formas de representar o relacionamento é o “pé-de-gali-nha” para indicar a cardinalidade muitos, um pequeno traço para in-dicar a cardinalidade um, o trace-jado para indicar opcionalidade e o segmento de reta contínuo para in-dicar obrigatoriedade. Uma outra forma é indicar a opcionalidade com um pequeno círculo antes do um ou muitos da cardinalidade. Lem-bre-se: são apenas convenções. O importante é que o relacionamen-to esteja claro e esteja representa-do no modelo de darepresenta-dos.
INTEGRIDADE REFERENCIAL
Mecanismo utilizado pelos gerencia-dores de bancos de dados para man-ter a consistência das informações armazenadas. Suponha que estamos cadastrando uma Nota Fiscal e indi-camos um código de cliente (que re-laciona com a tabela Cliente) inexis-tente. Outra situação é tentar excluir um Cliente que tenha diversas No-tas Fiscais emitidas. Como iríamos recuperar a informação, caso o ban-co de dados permitisse a exclusão do Cliente? Simplesmente perdería-mos o elo entre as tabelas, e a infor-mação armazenada estaria inválida.
A principal forma de garantir a integridade entre tabelas se dá por meio do vínculo entre a chave pri-mária de uma tabela com a chave estrangeira da outra tabela. As co-lunas das duas tabelas armazenam as informações que permitem es-tabelecer o relacionamento entre as linhas das tabelas. Assim, o có-digo de cliente 1 da tabela Clien-te, cujo nome é João, será arma-zenado na coluna código do clien-te da tabela Nota Fiscal sempre que se quiser indicar que o João comprou determinados produtos. Não será possível excluir João (có-digo do cliente 1) enquanto hou-ver Notas Fiscais emitidas contra esse cliente.
RESTRIÇÕES
Utilizam-se as restrições (constraints) para melhorar a qualidade da infor-mação guardada nas tabelas do ban-co. As restrições mais comuns são a chave primária e a estrangeira. Mas há outras restrições bastante importantes:
■NULOS: uma coluna que não te-nha valor inicializado é considera-da uma coluna nula. Nem sempre é adequado permitir que uma co-luna não tenha valores atribuídos. Imagine uma linha na tabela Clien-te cujo nome seja nulo. Como po-demos identificar o cliente?
■EXCLUSIVOS: suponha que se te-nha criado uma tabela Cliente cujo código do cliente não seja um do-cumento, como CPF ou RG. Mesmo
não sendo uma coluna chave, es-ses valores não podem ser duplica-dos em clientes (linhas) diferentes. Para isso definimos que sejam ad-mitidos somente valores exclusivos. O que a difere de uma chave pri-mária é que esta última não pode assumir valores nulos.
■PADRÃO: É muito comum que, quando um valor não é informado, o sistema assuma um valor-padrão para a coluna (como data de emis-são de uma Nota Fiscal ou quanti-dade de um determinado produto em uma Nota Fiscal).
■DOMÍNIO: as vezes é necessário determinar um intervalo de valores possíveis para uma determinada co-luna. É o caso do sexo, por
exem-Restrições: melhoram a qualidade da informação armazenada nas tabelas do banco
plo, que pode assumir apenas os valores Masculino ou Feminino.
TRANSAÇÃO
Ocorre sempre que houver uma mo-dificação no conteúdo das tabelas de um banco de dados. Dessa for-ma, uma inclusão, alteração ou ex-clusão geram uma transação. Em gerenciadores de banco de dados, o controle sobre o momento da efe-tiva gravação (COMMIT) dos dados ou abandono da operação (ROLL-BACK) é realizado pelo usuário do banco de dados ou pelo sistema. A transação representa um conjunto de operações que são realizados na base de dados para produzir um re-sultado final.
CONCEITOS
C O L E Ç Ã O I N F O>21
CONCEITOS
20<C O L E Ç Ã O I N F O
dados relacional. Sempre que se identificar essa situação, deve-se criar uma entidade entre as duas entidades, classificadas como fun-damentais. Essa nova entidade, clas-sificada como entidade associativa, deve conter, pelo menos, as chaves das duas entidades fundamentais. Uma das formas de representar o relacionamento é o “pé-de-gali-nha” para indicar a cardinalidade muitos, um pequeno traço para in-dicar a cardinalidade um, o trace-jado para indicar opcionalidade e o segmento de reta contínuo para in-dicar obrigatoriedade. Uma outra forma é indicar a opcionalidade com um pequeno círculo antes do um ou muitos da cardinalidade. Lem-bre-se: são apenas convenções. O importante é que o relacionamen-to esteja claro e esteja representa-do no modelo de darepresenta-dos.
INTEGRIDADE REFERENCIAL
Mecanismo utilizado pelos gerencia-dores de bancos de dados para man-ter a consistência das informações armazenadas. Suponha que estamos cadastrando uma Nota Fiscal e indi-camos um código de cliente (que re-laciona com a tabela Cliente) inexis-tente. Outra situação é tentar excluir um Cliente que tenha diversas No-tas Fiscais emitidas. Como iríamos recuperar a informação, caso o ban-co de dados permitisse a exclusão do Cliente? Simplesmente perdería-mos o elo entre as tabelas, e a infor-mação armazenada estaria inválida.
A principal forma de garantir a integridade entre tabelas se dá por meio do vínculo entre a chave pri-mária de uma tabela com a chave estrangeira da outra tabela. As co-lunas das duas tabelas armazenam as informações que permitem es-tabelecer o relacionamento entre as linhas das tabelas. Assim, o có-digo de cliente 1 da tabela Clien-te, cujo nome é João, será arma-zenado na coluna código do clien-te da tabela Nota Fiscal sempre que se quiser indicar que o João comprou determinados produtos. Não será possível excluir João (có-digo do cliente 1) enquanto hou-ver Notas Fiscais emitidas contra esse cliente.
RESTRIÇÕES
Utilizam-se as restrições (constraints) para melhorar a qualidade da infor-mação guardada nas tabelas do ban-co. As restrições mais comuns são a chave primária e a estrangeira. Mas há outras restrições bastante importantes:
■NULOS: uma coluna que não te-nha valor inicializado é considera-da uma coluna nula. Nem sempre é adequado permitir que uma co-luna não tenha valores atribuídos. Imagine uma linha na tabela Clien-te cujo nome seja nulo. Como po-demos identificar o cliente?
■EXCLUSIVOS: suponha que se te-nha criado uma tabela Cliente cujo código do cliente não seja um do-cumento, como CPF ou RG. Mesmo
não sendo uma coluna chave, es-ses valores não podem ser duplica-dos em clientes (linhas) diferentes. Para isso definimos que sejam ad-mitidos somente valores exclusivos. O que a difere de uma chave pri-mária é que esta última não pode assumir valores nulos.
■PADRÃO: É muito comum que, quando um valor não é informado, o sistema assuma um valor-padrão para a coluna (como data de emis-são de uma Nota Fiscal ou quanti-dade de um determinado produto em uma Nota Fiscal).
■DOMÍNIO: as vezes é necessário determinar um intervalo de valores possíveis para uma determinada co-luna. É o caso do sexo, por
exem-Restrições: melhoram a qualidade da informação armazenada nas tabelas do banco
plo, que pode assumir apenas os valores Masculino ou Feminino.
TRANSAÇÃO
Ocorre sempre que houver uma mo-dificação no conteúdo das tabelas de um banco de dados. Dessa for-ma, uma inclusão, alteração ou ex-clusão geram uma transação. Em gerenciadores de banco de dados, o controle sobre o momento da efe-tiva gravação (COMMIT) dos dados ou abandono da operação (ROLL-BACK) é realizado pelo usuário do banco de dados ou pelo sistema. A transação representa um conjunto de operações que são realizados na base de dados para produzir um re-sultado final.
CONCEITOS
C O L E Ç Ã O I N F O>23
CONCEITOS
22<C O L E Ç Ã O I N F O
NORMALIZAÇÃO DE DADOS
Processo pelo qual são aplicadas regras a um conjunto de dados e, no final, obtém-se uma base quase livre de redundâncias. Ao atingir es-se objetivo, é possível recuperar o dado em um único lugar (tabela). Isso fará, com certeza, que haja um aumento na quantidade de tabelas criadas no sistema, mas ajudará a aumentar a confiabilidade dos da-dos armazenada-dos. Ao final do pro-cesso de normalização, deve-se va-lidá-lo com o Modelo de Entidade x Relacionamento.
Esse processo pode ser feito em até seis fases, mas, geralmente, ao se che-gar na terceira etapa (conhecida co-mo 3ª- Forma Normal), já é possível obter um modelo de dados estável.
Antes de iniciar o processo de nor-malização, é importante identificar o grupo de dados que se quer analisar. Esse grupo pode estar representado por um formulário, um relatório ou até mesmo uma tela do sistema. Po-de também ser resultado Po-de um le-vantamento sistemático das neces-sidades de informação dos usuários. Com o grupo de dados definido, de-ve-se listar todos os dados disponí-veis, sem desprezar nenhum. Em se-guida, deve-se dar um nome a esse grupo de dados. Após o nome, esta-belece-se um identificador único (cha-ve). Cumprida essa etapa, deve-se proceder ao processo de normaliza-ção. Para explicar melhor, vamos ado-tar um formulário de Nota Fiscal co-mo exemplo.
As três fases da Normalização de Dados são:
■1ª- FORMA NORMAL (1FN): elimi-nar grupos de dados repetitivos da estrutura. Para isso, deve-se locali-zar os atributos multivalorados, os que têm mais de uma ocorrência no formulário. No caso da Nota Fiscal, temos produto, quantidade, valor unitário e total como grupo de da-dos multivalorado. Deve-se separar esse grupo em uma nova entidade, dar um nome ao grupo, levar a cha-ve da Nota Fiscal (para manter a re-lação entre as entidades) e estabe-lecer uma chave para o novo gru-po. Essa chave pode ser composta pela chave da Nota Fiscal e por mais de um atributo existente. É possível, quando não se localizar um atribu-to adequado, criá-la.
■2ª- FORMA NORMAL (2FN): quan-do somente houver grupos de da-dos na 1ª- Forma Normal (e jamais antes disso), deve-se localizar da-dos que não dependam única e ex-clusivamente da chave da entida-de. Veja: o Cliente está relacionado à Nota Fiscal, mas não depende de-la. O Cliente existe, mesmo que não exista a Nota Fiscal. Por esse moti-vo dizemos que o Cliente não pende da Nota Fiscal e, por isso, de-ve ter os dados separados em uma nova entidade. Ao se identificar o(s) grupo(s) independente(s), deve-se separá-los em uma nova entidade (uma para cada grupo independte). Feito isso, dá-se um nome à
en-tidade e estabelece-se uma chave Procedimentos armazenados: códigos que ficam armazenados para usar depois para o novo grupo. Caso não haja
um bom atributo para ser a chave, deve-se criá-lo. É isso que foi feito com o Cliente e Produto.
■3ª- FORMA NORMAL (3FN): depois que os grupos de dados estiverem na 2ª-Forma Normal (e jamais antes dis-so), localizam-se atributos com de-pendência transitiva. Calma! Não é tão complicado. Dependência transi-tiva ocorre quando um dado pode ser obtido por meio de outro, exceto a chave. Isso porque os atributos de-pendem da chave. Até que você se habitue, tente localizar campos que possam ser substituídos por fórmu-las matemáticas. No exemplo, temos o atributo Valor Total no Item da No-ta e o Valor ToNo-tal da NoNo-ta Fiscal. Es-ses atributos devem ser excluídos, pois podem ser obtidos por meio de um cálculo realizado com outros atri-butos. Com os dados normalizados, é possível criar as tabelas.
PROCEDIMENTOS ARMAZENADOS
São pequenos códigos executados em um banco de dados que ficam guardados para posterior utiliza-ção. Podem ser stored procedures (procedimentos armazenados), stored functions (funções armaze-nadas), trigger (gatilho) e package (pacote). Um procedimento é um conjunto de comandos dentro de uma estrutura lógica, com o obje-tivo de realizar uma ação no ban-co de dados. A diferença entre pro-cedimento e função é que esta úl-tima retorna valor.
Gatilhos são procedimentos dispa-rados por eventos do banco de da-dos (inclusão, alteração ou exclusão). Por fim, um pacote é um conjunto de funções, procedimentos e outras es-truturas que são armazenados em conjunto para facilitar a manutenção e a segurança da informação. 015_CONCEITOS 25/02/2006 21:54 Page 22
CONCEITOS
C O L E Ç Ã O I N F O>23
CONCEITOS
22<C O L E Ç Ã O I N F O
NORMALIZAÇÃO DE DADOS
Processo pelo qual são aplicadas regras a um conjunto de dados e, no final, obtém-se uma base quase livre de redundâncias. Ao atingir es-se objetivo, é possível recuperar o dado em um único lugar (tabela). Isso fará, com certeza, que haja um aumento na quantidade de tabelas criadas no sistema, mas ajudará a aumentar a confiabilidade dos da-dos armazenada-dos. Ao final do pro-cesso de normalização, deve-se va-lidá-lo com o Modelo de Entidade x Relacionamento.
Esse processo pode ser feito em até seis fases, mas, geralmente, ao se che-gar na terceira etapa (conhecida co-mo 3ª- Forma Normal), já é possível obter um modelo de dados estável.
Antes de iniciar o processo de nor-malização, é importante identificar o grupo de dados que se quer analisar. Esse grupo pode estar representado por um formulário, um relatório ou até mesmo uma tela do sistema. Po-de também ser resultado Po-de um le-vantamento sistemático das neces-sidades de informação dos usuários. Com o grupo de dados definido, de-ve-se listar todos os dados disponí-veis, sem desprezar nenhum. Em se-guida, deve-se dar um nome a esse grupo de dados. Após o nome, esta-belece-se um identificador único (cha-ve). Cumprida essa etapa, deve-se proceder ao processo de normaliza-ção. Para explicar melhor, vamos ado-tar um formulário de Nota Fiscal co-mo exemplo.
As três fases da Normalização de Dados são:
■1ª- FORMA NORMAL (1FN): elimi-nar grupos de dados repetitivos da estrutura. Para isso, deve-se locali-zar os atributos multivalorados, os que têm mais de uma ocorrência no formulário. No caso da Nota Fiscal, temos produto, quantidade, valor unitário e total como grupo de da-dos multivalorado. Deve-se separar esse grupo em uma nova entidade, dar um nome ao grupo, levar a cha-ve da Nota Fiscal (para manter a re-lação entre as entidades) e estabe-lecer uma chave para o novo gru-po. Essa chave pode ser composta pela chave da Nota Fiscal e por mais de um atributo existente. É possível, quando não se localizar um atribu-to adequado, criá-la.
■2ª- FORMA NORMAL (2FN): quan-do somente houver grupos de da-dos na 1ª- Forma Normal (e jamais antes disso), deve-se localizar da-dos que não dependam única e ex-clusivamente da chave da entida-de. Veja: o Cliente está relacionado à Nota Fiscal, mas não depende de-la. O Cliente existe, mesmo que não exista a Nota Fiscal. Por esse moti-vo dizemos que o Cliente não pende da Nota Fiscal e, por isso, de-ve ter os dados separados em uma nova entidade. Ao se identificar o(s) grupo(s) independente(s), deve-se separá-los em uma nova entidade (uma para cada grupo independte). Feito isso, dá-se um nome à
en-tidade e estabelece-se uma chave Procedimentos armazenados: códigos que ficam armazenados para usar depois para o novo grupo. Caso não haja
um bom atributo para ser a chave, deve-se criá-lo. É isso que foi feito com o Cliente e Produto.
■3ª- FORMA NORMAL (3FN): depois que os grupos de dados estiverem na 2ª-Forma Normal (e jamais antes dis-so), localizam-se atributos com de-pendência transitiva. Calma! Não é tão complicado. Dependência transi-tiva ocorre quando um dado pode ser obtido por meio de outro, exceto a chave. Isso porque os atributos de-pendem da chave. Até que você se habitue, tente localizar campos que possam ser substituídos por fórmu-las matemáticas. No exemplo, temos o atributo Valor Total no Item da No-ta e o Valor ToNo-tal da NoNo-ta Fiscal. Es-ses atributos devem ser excluídos, pois podem ser obtidos por meio de um cálculo realizado com outros atri-butos. Com os dados normalizados, é possível criar as tabelas.
PROCEDIMENTOS ARMAZENADOS
São pequenos códigos executados em um banco de dados que ficam guardados para posterior utiliza-ção. Podem ser stored procedures (procedimentos armazenados), stored functions (funções armaze-nadas), trigger (gatilho) e package (pacote). Um procedimento é um conjunto de comandos dentro de uma estrutura lógica, com o obje-tivo de realizar uma ação no ban-co de dados. A diferença entre pro-cedimento e função é que esta úl-tima retorna valor.
Gatilhos são procedimentos dispa-rados por eventos do banco de da-dos (inclusão, alteração ou exclusão). Por fim, um pacote é um conjunto de funções, procedimentos e outras es-truturas que são armazenados em conjunto para facilitar a manutenção e a segurança da informação. 015_CONCEITOS 25/02/2006 21:54 Page 22
