Fundamentos de Bases de Dados by Grupo Lidel

9cm x 24cm

???mm

16,7cm x 24cm

9cm x 24cm

Feliz Gouveia de Bases de Dados FELIZ GOUVEIA Este livro tem por objetivo, com base em princípios fundamentais da Engenharia de Software, apresentar regras e boas práticas na análise, conceção e desenvolvimento (projeto) de aplicações orientadas pelos objetos em geral, neste caso usando as construções da linguagem Java. O livro centra-se à volta da noção de projeto de software, sendo apresentados projetos sobre todos os assuntos essenciais à Programação Orientada pelos Objetos (POO), designadamente (além dos básicos):

Dirigido aos estudantes de programação; aprofunda o estudo dos vários tipos de algoritmos expondo a análise experimental e formal da sua complexidade. Pseudocódigo compatível com C e Java.

.. .. .

Classes e Instâncias; Encapsulamento, Modularidade e Reutilização; Todas as Coleções de Java (JCF); Hierarquia de Classes, Classes Abstratas, Herança, Interfaces e Polimorfismo; Streams de I/O.

Em cada capítulo apresenta-se uma síntese teórica dos assuntos abordados, as construções de Java necessárias ao projeto exemplo e, em seguida, vários exercícios que são analisados e completamente implementados em Java. Este livro tem como principais destinatários estudantes de nível secundário e universitário e profissionais de informática em geral.

Principais temas abordados no livro:

. . . . . . .

Tipos Primitivos e Estruturas de Controlo; Arrays; Classes; Coleções de Java: ArrayList<E>, HashSet<E> e TreeSet<E>; Hierarquia de Classes, Herança, Classes Abstratas e Polimorfismo; Coleções de Java: HashMap<K,V> e TreeMap<K,V>; Streams de I/O.

Bases de Dados Bases de Dados

Este livro, com múltiplos exemplos práticos, apresenta as bases e os conceitos que permitem compreender e aplicar as várias fases do desenvolvimento iterativo de uma boa interface utilizador.

Pela sua estrutura, pode ser usado quer como livro de base para as aulas práticas de laboratório, quer como livro de texto no caso de disciplinas com uma abordagem de ensino essencialmente prática.

Este livro disponibiliza ainda a correspondência dos principais termos técnicos para o português do Brasil.

Código fonte de todos os exercícios e projetos do livro disponível em www.fca.pt, até este se esgotar ou ser publicada nova edição atualizada ou com alterações.

ISBN 978‐972‐722‐799‐0

9 789727 227990

Feliz Gouveia

Livro indispensável na criação e desenvolvimento de jogos digitais: programação de jogos para web, dispositivos móveis e Windows 8. Com Python, Pygame, HTML5 e outros. Para estudantes e profissionais.

Professor Associado do Departamento de Informática da Universidade do Minho. É responsável por disciplinas de licenciatura e de mestrado nas áreas de Paradigmas e Metodologias da Programação, Metodologias e Tecnologias de Objetos e Arquiteturas de Software. Os Modelos de Componentes e as Arquiteturas de Software Multicamada e Multifuncionais são as suas atuais áreas de interesse. Autor dos livros JAVA6 e Programação Orientada pelos Objectos, JAVA5 e Programação por Objectos e Programação Orientada aos Objectos em JAVA2, também publicados pela FCA.

Índice Geral

1 Introdução

1.1 As Bases de Dados

1.2 Cenários de utilização

1.3 Os SGBD

1.4 Transações

1.5 Arquitetura de um SGBD

1.6 O Modelo Relacional

1.7 Níveis ANSI/SPARC

1.8 Projeto de Bases de Dados

1.9 Vantagens de um SGBD

1.10 Breve histórico

1.11 Aplicações

1.12 Organização do livro

EXERCÍCIOS

2 O Modelo Relacional

2.1 Introdução

2.2 O Modelo Relacional de Dados

2.3 Restrições de integridade

2.3.1 Noção de chave

2.3.2 Outras restrições

2.4 Vistas

2.5 A Álgebra Relacional

2.5.1 Operadores

2.5.1.1 Operadores sobre conjuntos

2.5.1.2 Seleção

2.5.1.3 Projeção

2.5.1.4 Produto

2.5.2 Extensões aos operadores

2.5.2.1 Renomear

2.5.2.2 Junção

2.5.2.3 Eliminar duplicados

37 © FCA – Editora de Informática

FUNDAMENTOS DE BASES DE DADOS

2.5.2.4 Ordenar

2.5.2.5 Agrupar e agregar

2.5.2.6 Junções externas

2.5.2.7 Semi-junção

2.5.2.8 Anti-junção

2.5.2.9 Auto-junção

2.5.3 Leis algébricas

2.5.4 Tratamento de valores nulos

2.5.5 Consultas

2.5.6 Consultas monotónicas e não-monotónicas

2.6 Cálculo Relacional

2.6.1

Fórmulas, quantificadores e variáveis

2.6.2 Tradução dos operadores da Álgebra

2.6.3 Consultas

2.7 Requisitos de um sistema relacional

EXERCÍCIOS

3 Projeto de Bases de Dados

3.1 Introdução

3.2 Modelos concetuais

3.3 O Modelo Entidade-Relacionamento

3.3.1 Diagrama E-R

3.3.2 Multiplicidade de relacionamentos

3.3.3 Entidades fracas

3.3.4 Entidades associativas

3.3.5 Generalização e especialização

3.3.6 Relacionamentos n-ários

3.3.6.1 Análise de relacionamentos de grau 3

3.3.6.2 Decomposição em relacionamentos binários

3.3.7 Mapeamento E-R em Relacional

3.4 Escolha das Relações

3.4.1 Dependências Funcionais

Índice Geral

3.4.1.1 Determinação de dependências

3.4.1.2 Cálculo do fecho de F

3.4.1.3 Cálculo do fecho de um atributo

3.4.1.4 Equivalência de conjuntos de DF

3.4.1.5 Cobertura de F

3.4.2 Dependências de inclusão

3.4.3 Chaves e Superchaves

3.4.4 Definição do esquema

3.5 Normalização

3.5.1 Decomposição sem perdas

3.5.2 Preservação de dependências

3.6 Formas normais

3.6.1

Primeira Forma Normal

3.6.2 Segunda Forma Normal

3.6.3 Terceira Forma Normal

3.6.4 Forma Normal de Boyce-Codd

3.6.5 Dependência funcional multivalor

3.6.6 Quarta Forma Normal

3.6.7 Dependências de junção

3.6.8 Algoritmos de perseguição

3.6.9 Quinta Forma Normal

3.6.10 Sexta forma normal

3.6.11 Resumo das formas normais

EXERCÍCIOS

100

103

4 SQL

4.1 Introdução

103

4.2 Linguagem de definição de dados

104

4.2.1 Esquemas

104

4.2.2 Criação de tabelas

105

4.2.2.1 Tipos de dados

105

4.2.2.2 Restrições de integridade

106 © FCA – Editora de Informática

VII

FUNDAMENTOS DE BASES DE DADOS

4.2.3 Restrições

107

4.2.4 Criação de domínios

108

4.2.5 Criação de Tipos de Dados

108

4.2.6 Remoção e Alteração de tabelas

109

4.2.7 Vistas

110

4.2.8 Índices

110

4.2.9 Triggers

111

4.2.10 Asserções

112

4.3 Linguagem de manipulação de dados

112

4.3.1 Seleções e projeções

113

4.3.1.1 Valores nulos

114

4.3.2 Ordenação

114

4.3.3 Agrupamentos

114

4.3.4 Agregações

115

4.3.5 Junções

116

4.3.5.1 Junções internas

116

4.3.5.2 Junções externas

117

4.3.6 Consultas imbricadas

117

4.3.6.1 Consultas não-correlacionadas

118

4.3.6.2 Consultas correlacionadas

118

4.3.6.3 Semi-junções

119

4.3.6.4 Anti-junções

119

4.3.7 Operadores existenciais e Universais

120

4.3.8 Divisão

120

4.3.8.1 Tradução da consulta algébrica

121

4.3.8.2 Com quantificação

121

4.3.8.3 Com comparação de cardinalidades

121

4.3.8.4 Com inclusão de conjuntos

122

4.3.9 Operadores sobre conjuntos

122

4.3.10 Inserção

122

4.3.11 Atualização

123

VIII

Índice Geral 4.3.12 Remoção

123

4.4 Linguagem de Controlo de Dados

124

EXERCÍCIOS

126

129

5 Armazenamento e Indexação

5.1 Introdução

129

5.2 Gestor de Armazenamento

130

5.3 Registos

130

5.3.1 Registos de comprimento fixo

130

5.3.2 Registos de comprimento variável

131

5.4 Organização de ficheiros

132

5.4.1

132

Ficheiros Heap

5.4.2 Ficheiros sequenciais

133

5.4.3 Ficheiros Hashing

134

5.4.4 Ficheiros cluster

134

5.5 Armazenamento

135

5.5.1 Discos

135

5.5.2 Modelo N-ário

137

5.5.3 DSM

138

5.5.4 PAX

139

5.5.5 Clotho

141

5.5.6 Outros modelos

142

5.6 Índices

142

5.7 Índices arborescentes

144

5.7.1

Índices agrupados

145

5.7.2

Índices não-agrupados

146

5.7.3

Índices densos

147

5.7.4

Índices esparsos

147

5.7.5

Índices compostos

148

5.7.5.1 Combinação de índices

148

5.7.6

Índices com funções

149

5.7.7

Índices parciais

149 © FCA – Editora de Informática

FUNDAMENTOS DE BASES DE DADOS

5.7.8

Índices multinível

150

5.7.9

B-Trees

150

5.7.9.1 Inserção e remoção

152

5.7.10 B+-Trees

153

5.7.11

157

Variantes da B+-Tree

5.7.12 Consultas com ordenação

158

5.8 Hashing

159

5.8.1 Hashing extensível

160

5.8.2 Hashing linear

162

5.9 Índices Bitmap

163

5.10 GiST

164

5.11 Índices multidimensionais

165

5.11.1 Consultas multidimensionais

166

5.11.2

166

Índices multidimensionais arborescentes

5.11.3 Índices multidimensionais de Grelha

168

5.12 Índices e desempenho

169

5.13 Criação de índices em SQL

170

EXERCÍCIOS

173

175

6 Consultas

6.1 Introdução

175

6.2 Catálogo da base de dados

177

6.3 Processamento de consultas

178

6.3.1

178

Fases do processamento

6.3.2 Análise Sintática

179

6.3.2.1 Forma canónica SPJ

180

6.3.3 Plano Lógico

180

6.3.3.1 Fusão de vistas

181

6.3.3.2 Transformação de subconsultas

182

6.3.3.3 Forma Normal Conjuntiva

183

6.3.3.4 Transformações de planos

184

6.3.3.5 Regras de equivalência

186

Índice Geral 6.3.4 Plano Físico

188

6.4 Operadores físicos

189

6.4.1 Noção de custo

189

6.4.2 Seleção

192

6.4.2.1 Varrimento sequencial

192

6.4.2.2 Seleção com índices

193

6.4.2.3 Seleção com comparações

195

6.4.2.4 Seleção complexa

195

6.4.2.5 Seleção com variáveis

196

6.4.3 Projeção

196

6.4.3.1 Projeção com ordenação

197

6.4.3.2 Projeção com hashing

198

6.4.3.3 Projeção com índices

199

6.4.4 Junção

199

6.4.4.1 Junção em ciclo

200

6.4.4.2 Junção de Blocos em ciclo

200

6.4.4.3 Junção com ordenação por fusão

204

6.4.4.4 Junção com Hashing

206

6.4.4.5 O algoritmo GRACE

208

6.4.4.6 Junção com Hashing Híbrido

209

6.4.4.7 Comportamento dos algoritmos

210

6.4.4.8 Outros algoritmos de junção

212

6.4.5 Junções externas

214

6.4.6 Semi e anti-junções

214

6.4.7 Eliminar duplicados

215

6.4.8 Operações sobre conjuntos

215

6.4.9 Agregações e agrupamentos

215

6.5 Fase de execução

216

6.5.1 Execução sequenciada

217

6.6 Transformações adicionais

218

6.6.1 Transformação de subconsultas

218 © FCA – Editora de Informática

FUNDAMENTOS DE BASES DE DADOS

6.6.1.1 Subconsultas tipo N

219

6.6.1.2 Subconsultas tipo A

221

6.6.1.3 Subconsultas tipo J

221

6.6.1.4 Subconsultas tipo JA

222

6.6.2 Redução com semi-junções

223

6.6.3 Transformações com conjuntos mágicos

224

EXERCÍCIOS

229

7 Otimização de Consultas

7.1 Introdução

231 231

7.2 Tipos de otimização

233

7.2.1 Otimização heurística

233

7.2.2 Otimização baseada em custos

235

7.2.3 Otimização no tempo

236

7.3 Otimização baseada em custos

237

7.3.1 Otimização por blocos

237

7.3.2 Otimização paramétrica

237

7.3.3 Otimização com N relações

238

7.3.4 Enumeração de planos

239

7.3.4.1 Programação dinâmica

239

7.3.5 Estatísticas utilizadas

241

7.3.5.1 Estimativa de seleção simples

242

7.3.5.2 Estimativa de seleção conjuntiva

243

7.3.5.3 Estimativa de seleção com negação

244

7.3.5.4 Estimativa de seleção disjuntiva

244

7.3.5.5 Estimativa de junções

244

7.3.5.6 Estimativa de projeções

245

7.3.5.7 Estimativa de agregações

245

7.3.5.8 Estimativas de operações sobre conjuntos

245

7.3.5.9 Estimativas de valores únicos

245

7.4 Técnicas para estimação

246

7.5 Histogramas

247

XII

Índice Geral 7.5.1 Tipos de histogramas mais comuns

248

7.5.1.1 Histograma equi-largo

248

7.5.1.2 Histograma equi-profundo

249

7.5.2 Taxonomia de histogramas

250

7.5.3 Histogramas multi-dimensionais

252

7.5.4 Histogramas baseados em Wavelets

252

7.5.5 Histogramas na prática

252

7.6 Otimização na prática

253

7.7 Ferramentas da otimização

256

7.7.1 Análise de planos

256

7.7.2 Sintonização de consultas

258

7.7.3 Utilização de índices

258

7.7.4

259

Parâmetros físicos

7.7.5 Sugestões de otimização

259

EXERCÍCIOS

264

265

8 Gestão de Transações

8.1 Introdução 8.1.1 Escalonamentos

265 267

8.2 Transações

268

8.2.1 Execução de uma transação

268

8.2.2 Definição formal

269

8.2.3 Acesso aos elementos

270

8.2.4 Pontos de restauro

271

8.2.5 Conflitos

272

8.2.6 Problemas de concorrência

273

8.3 Serialização

275

8.3.1 Serialização de conflitos

276

8.3.2 Serialização de vistas

280

8.4 Algoritmos de controlo de concorrência

281

8.5 Recuperação de dados

283

8.6 Granularidade dos dados

286 © FCA – Editora de Informática

XIII

FUNDAMENTOS DE BASES DE DADOS

8.7 Transações imbricadas

287

8.8 Transações encadeadas

288

EXERCÍCIOS

290

293

9 Controlo de concorrência

9.1 Introdução

293

9.2 Algoritmos de fecho

294

9.2.1 Deteção de esperas circulares

298

9.2.2 Interrupção de transações

300

9.2.3 Promoção de fechos

301

9.2.4 Variantes de 2PL

302

9.2.5 Recuperação e 2PL

303

9.2.6 Fechos de granularidade múltipla

305

9.2.6.1 Escalada de fechos

307

9.2.7

Fechos de Predicados

308

9.2.8 Fechos Next-key

309

9.2.9 Concorrência em índices

310

9.3 Algoritmos de ordenação temporal

310

9.4 Validação na confirmação

314

9.4.1

315

Fases do controlo otimista

9.4.2 Formas de validação

317

9.4.3 Variantes do algoritmo

318

Outros algoritmos

320

9.5.1 Ordered Sharing

321

9.5.2 Altruistic locking

321

9.5.3 Algoritmo Five-color

322

324

9.5.4 Serialization Graph Testing

9.6 Controlo de Concorrência Multiversão

324

9.6.1 Serialização multiversão

326

9.6.2 Ordenação Temporal Multiversão

327

9.6.3 2PL Multiversão

329

9.6.4 Leitura Consistente Multiversão

330

XIV

Índice Geral 9.6.5 Snapshot Isolation

331

9.6.5.1 Anomalias de Snaphost Isolation

332

9.6.5.2 Serializable Snapshot Isolation

334

9.6.6 Implementação de MVCC

335

EXERCÍCIOS

342

10 Níveis de isolamento

345

10.1 Introdução

345

10.2 Níveis de isolamento

346

10.3 Níveis SQL

348

10.3.1 Anomalias de concorrência

349

10.3.2 Interpretação dos níveis

351

10.3.3 Outros níveis de isolamento

353

10.3.4 Escolher um nível

355

10.4 Escolhas dos SGBD

357

10.4.1 Oracle

357

10.4.2 MS SQL Server

358

10.4.3 DB2

359

10.4.4 PostgreSQL

359

10.4.5 MySQL

360

10.5 Transações e SQL

361

10.5.1 START TRANSACTION

361

10.5.2 START TRANSACTION ISOLATION LEVEL nível

361

10.5.3 SET TRANSACTION ISOLATION LEVEL nível

362

10.5.4 LOCK TABLE tabela IN MODE modo

362

10.5.5 UNLOCK TABLE tabela

362

10.5.6 SAVEPOINT nome

362

10.5.7 RELEASE SAVEPOINT nome

362

10.5.8 COMMIT

363

10.5.9 ROLLBACK [nome]

363

EXERCÍCIOS

364 © FCA – Editora de Informática

FUNDAMENTOS DE BASES DE DADOS

11 Recuperação

365

11.1 Introdução

365

11.2 Tipos de armazenamento

367

11.3 Tipos de falhas

369

11.4 Organização da memória

370

11.4.1 O Gestor de Memória

371

11.4.2 Trincos

373

11.4.3 Estratégias de Paginação

374

11.4.3.1 O algoritmo CLOCK

375

11.4.3.2 O algoritmo LRU-K

376

11.4.3.3 O algoritmo 2Q

377

11.4.3.4 O algoritmo ARC

378

11.4.3.5 O algoritmo LIRS

379

11.4.4 Paginação no Sistema Operativo

380

11.5 Gestão da memória

381

11.5.1

382

Propagação

11.5.2 Políticas de substituição de páginas

383

11.5.3 Processamento da operação de confirmação

383

11.5.4 Escolha das políticas

385

11.6 Técnicas de recuperação

385

11.6.1 Logging

386

11.6.1.1 Estratégias de Logging

387

11.6.2

Write-Ahead Logging

388

11.6.3 Páginas sombra

389

11.7 O protocolo ARIES

391

11.7.1

392

Princípio geral

11.7.2 O algoritmo

393

11.7.3 As estruturas de dados

394

11.7.4

Pontos de Controlo

396

11.7.5

Funcionamento normal

397

11.7.5.1 Interrupção de transações

397

XVI

Índice Geral 11.7.6

Fases do protocolo

398

11.7.7

Fase de Análise

399

11.7.8

Fase de “REDO”

400

11.7.9

Fase de “UNDO”

401

11.7.10 Exemplo de recuperação

402

11.7.11

405

EXERCÍCIOS

Variantes do protocolo

408

XVII

1 Introdução “We find countless examples of programmers who have moved on, leaving programs that are undecipherable for maintenance or modification. Had they been written in COBOL, they would have had more than zero salvage value.” Bemmer, R.W., A view of the history of COBOL (1971)

Sumário Este capítulo apresenta o tema do livro e as definições iniciais necessárias ao desenvolvimento dos capítulos seguintes. É introduzido o conceito de bases de dados e apresentada a sua arquitetura, bem como as características essenciais da sua utilização, tal como o conceito de transação e de controlo de concorrência. O capítulo inclui ainda um breve histórico do aparecimento e da evolução da tecnologia dos sistemas de gestão de bases de dados. No final, descrevem-se os diferentes capítulos do livro, permitindo ao leitor definir o seu percurso de leitura.

1.1 Bases de Dados Em 2009, festejou-se o 40.º aniversário da definição do Modelo Relacional de Dados, considerado o marco do nascimento das bases de dados modernas (Codd, 1969). Na realidade, o Modelo Relacional é hoje utilizado praticamente em todos os sistemas de gestão de bases de dados existentes, os (SGBD), embora existam outros modelos de dados desenvolvidos para aplicações específicas, mas que não tiveram, até ao momento, o sucesso e a divulgação do Modelo Relacional. A indústria baseada no Modelo Relacional de Dados vale atualmente dezenas de milhares de milhões de euros, e a tendência é para continuar a crescer. Como veremos, as bases de dados relacionais não têm o exclusivo do armazenamento da enorme quantidade de dados gerada em todas as aplicações e sistemas, contudo, apresentam uma percentagem elevada de adoção, que é reveladora da adequação da sua arquitetura e funcionalidades às necessidades atuais. Praticamente todas as aplicações informáticas gerem os seus dados com um SGBD, independentemente da quantidade de dados ou do número de pessoas que utiliza a aplicação. Alguns SGBD gerem milhares de acessos simultâneos e enormes quantidades de informação, por exemplo: aplicações de reserva de bilhetes de avião, sistemas de informação empresariais, lojas em linha, etc. © FCA – Editora de Informática

FUNDAMENTOS DE BASES DE DADOS

1.2 Cenários de utilização Atualmente, as bases de dados estão omnipresentes na vida das pessoas e das organizações, constituindo o núcleo a partir do qual os sistemas de informação são construídos e operam. Dos telemóveis aos cartões bancários, passando por todo um conjunto de serviços que o cidadão tem à sua disposição na Web, encontram-se bases de dados de dimensão e complexidade variáveis. A sua utilização passou do ambiente puramente organizacional, onde se armazenavam dados de recursos humanos, produtos, vendas, clientes, para aspetos que têm um impacto direto e importante na vida das pessoas. As bases de dados com informação de saúde, genética e financeira são hoje comuns, aumentando a responsabilidade de todos os que direta ou indiretamente estão envolvidos, e aumentando consideravelmente o impacto da sua utilização incorreta. Com efeito, o aumento exponencial do número e diversidade de serviços disponíveis em linha só foi possível com a entrada em produção de bases de dados com uma capacidade cada vez maior de gerir volumes consideráveis de dados e de gerir corretamente centenas ou milhares de acessos simultâneos. Uma base de dados pode caracterizar-se pelo número de utilizadores simultâneos que podem ter acesso à mesma, bem como pela quantidade de dados que armazena. Quando instalada num dispositivo portátil, tem características de utilização muito diferentes das da base de dados de um banco, por exemplo. No entanto, em qualquer das situações, espera-se que os dados não desapareçam nem sejam modificados de forma não desejada, que possam resistir a incidentes, físicos e lógicos, que afetem a base de dados, e que não sejam necessários conhecimentos especializados de utilização. Mesmo um utilizador especializado, regra geral, não necessita de otimizar a sua interação com a base de dados, existindo componentes que se encarregam de encontrar a melhor forma de processar os comandos, escondendo assim do utilizador os detalhes técnicos da estruturação e armazenamento dos dados.

1.3 SGBD Existem várias definições de base de dados, mas nesta fase inicial podemos utilizar a seguinte: Uma

base de dados é uma coleção organizada de informação estruturada relacionada

entre si que persiste durante um determinado período de tempo.

Dados (SGBD), modifica e elimina informação. de

Gestão

Bases

É gerida por um Sistema

que condiciona a forma como se cria, acede,

Os aspetos principais desta definição incluem a noção de informação estruturada, de persistência e de 1 programa de gestão responsável por toda a interação dos utilizadores ou de programas com os dados guardados em memória permanente. O programa de gestão da base de dados, o SGBD, serve de interface com o utilizador e gere toda a interação deste com os dados. 2

Introdução

Independentemente da base de dados utilizada e da estruturação dos seus dados, um SGBD deve possuir as seguintes características: ■■

Permitir a um utilizador autorizado definir a estrutura dos dados mais adaptada ao problema que tem em mãos. Um utilizador autorizado deve também poder definir permissões de acesso aos dados, o que inclui a sua criação, leitura, modificação e eliminação;

■■

Permitir a consulta eficiente dos dados, independentemente da forma como estes estiverem armazenados no suporte físico. Como consequência, compete ao SGBD escolher a forma mais eficiente de executar a consulta e de devolver o resultado ao utilizador. O SGBD deve dispor de uma linguagem de alto nível que permita ao utilizador especificar o que quer obter como resultado;

■■

Permitir que a base de dados possa ser recuperada, com o mínimo de perda de informação possível, quando ocorrem incidentes lógicos ou físicos. Neste caso, a recuperação significa poder reverter o estado da base de dados para um estado, anterior no tempo, que seja correto. Assim, a recuperação não implica que não se perca informação, mas antes que a base de dados não fique num estado incorreto;

■■

Permitir operações simultâneas sobre os dados por parte de vários utilizadores, isolando mutuamente os seus efeitos e garantindo que, em caso de erro, não se registem definitivamente os resultados de operações sem sucesso ou não terminadas.

Estas características de utilização do SGBD introduzem essencialmente três perfis de utilizador: ■■

O administrador da base de dados, que é responsável pela definição da estrutura dos dados (veremos mais adiante outras funções que o administrador deve desempenhar);

■■

O programador de aplicações, que utiliza as interfaces programáticas de linguagens disponíveis para consultar os dados;

■■

O utilizador final, que acede à base de dados da forma mais abstrata possível, sem conhecimento da sua estrutura ou tecnologia, e sem ter de se preocupar se as suas ações podem interferir com outros utilizadores.

Veremos mais à frente uma definição mais completa de SGBD. Por enquanto, estas características devem permitir-nos distinguir um SGBD de qualquer outro conjunto organizado de informação, como, por exemplo, uma folha de cálculo ou um conjunto de ficheiros com informação organizada.

1.4 Transações Uma outra definição é necessária antes de introduzirmos a arquitetura de um SGBD: a noção de transação (Eswaran, Gray et al., 1976). Uma transação é um conjunto atómico de comandos, na medida em que esta é indivisível e só termina com sucesso se todos os © FCA – Editora de Informática

FUNDAMENTOS DE BASES DE DADOS comandos que a constituem tiverem terminado igualmente com sucesso; caso contrário, a transação deve ser anulada e os seus efeitos até ao momento retirados da base de dados, devendo ser executada pelo SGBD exatamente uma vez. Uma transação pode corresponder a uma sequência de comandos que um utilizador autorizado a entrar num terminal executa, ou a um programa que executa um algoritmo com acesso à base de dados. Regra geral, uma transação é percebida pelo SGBD como uma sequência de leituras e de escritas. Por exemplo, uma transação que corresponda a um levantamento de dinheiro pode ter os seguintes comandos: a) iniciar transação; b) verificar o saldo; c) disponibilizar o montante se o saldo o permitir; d) registar movimento; e e) fechar a transação. Se qualquer uma das operações falhar por algum motivo, nenhuma das outras operações deve ter efeitos na base de dados e a transação deve ser terminada com uma mensagem de erro que informe o utilizador. Pelo contrário, se todas as operações forem bem sucedidas, o seu resultado deve ser registado de forma permanente na base de dados. Claro que se o dinheiro já tiver sido disponibilizado, não há forma (infelizmente para o banco) de desfazer essa operação, exceto com ações de compensação. Por outro lado, o banco estará igualmente interessado em não permitir que, se dois utilizadores efetuarem levantamentos ao mesmo tempo na mesma conta, existam interações indesejáveis entre os movimentos de ambos, como mostra a Figura 1.1. utilizador A utilizador B

Saldo = 100

escreve saldo

subtrai 20

lê saldo Saldo = 100

escreve saldo

soma 10

lê saldo

Saldo = 110

Saldo = 80

Saldo = 110

Saldo = 80

Figura 1.1 – Interação entre transações concorrentes

Assim podemos ver duas transações a decorrer em simultâneo, sendo que ambas leem o mesmo valor do mesmo elemento (neste caso um saldo) e utilizam-no para efetuar uma determinada operação. Quando terminam, escrevem o novo valor, mas como não consideraram o facto de estarem a operar sobre o mesmo valor, ou seja, poder existir interferência entre as operações de ambas, o resultado final não é o que resultaria se uma transação fosse efetuada após a outra, em série (execução essa que daria um saldo final de 90, independentemente da transação que fosse executada em primeiro lugar). Quando uma transação termina com sucesso, espera-se que os resultados na base de dados sejam corretos, isto é, os esperados; no entanto, e durante a sua execução, o estado da base de dados pode ficar temporariamente incorreto. Deste modo uma transação tem de possuir duas propriedades essenciais: ■■

Não pode ter qualquer interferência noutras transações que possam estar a decorrer concorrencialmente, garantindo que o utilizador está isolado das transações de outros utilizadores. Do ponto de vista do utilizador, a base de dados está disponível apenas para si; não é preciso incluir comandos que protejam especificamente os dados das ações de outros utilizadores; © FCA – Editora de Informática

Introdução ■■

Os seus efeitos são permanentes, ou seja, as consequências dos comandos que foram executados, nomeadamente a modificação, a inserção, a criação e a remoção de elementos da base de dados, ficam sempre registadas após a transação ser concluída com sucesso, mesmo se ocorrerem falhas depois desse ponto. Se o utilizador receber uma confirmação de que a transação teve sucesso, pode ter a certeza de que o seu trabalho não irá desaparecer.

É também possível que uma transação termine antes de ser concluída, devido a conflitos com outras transações ou a falhas lógicas ou físicas. Nesse caso, nenhum dos seus efeitos deverá ficar registado na base de dados e dizemos que a transação foi interrompida e que o SGBD deve iniciar um processo de recuperação do estado da base de dados para um estado consistente. Dada a importância deste tema, dedicámos o Capítulo 11 às diferentes técnicas de recuperação e aos problemas que lhes estão associados. A noção de transação é assim uma das noções fundamentais de um SGBD. Sem um mecanismo que garantisse o isolamento e a perenidade dos resultados dos comandos executados, não seria possível garantir um correto funcionamento de uma base de dados em ambiente multiutilizador. Uma transação deve ainda respeitar as seguintes características, conhecidas no seu conjunto por ACID (Härder e Reuter, 1983): ■■

Atomicidade: Uma transação pode ser composta por várias operações, mas o seu resultado deve ser tudo ou nada, ou seja, uma transação é atómica. Não é possível considerar apenas partes de uma transação como válidas e descartar outras. O utilizador que submeteu a transação deve ser sempre informado do resultado da sua execução, seja ele de sucesso ou insucesso;

■■

Consistência: Uma transação que termine de uma forma normal garante que a base de dados fica num estado consistente, ou seja, por definição, uma transação só confirma dados que respeitem a consistência da base de dados. Esta propriedade é necessária para garantir a quarta característica, durabilidade;

■■

Isolamento: Quaisquer operações dentro de uma transação não são afetadas por operações de outras transações a decorrer concorrencialmente. Do ponto de vista de cada transação, a base de dados está disponível apenas para si. Não respeitar esta característica leva ao problema mostrado anteriormente, na medida em que podem acontecer interferências indesejáveis entre operações de transações concorrentes diferentes;

■■

Durabilidade: Após uma transação terminar e confirmar os seus resultados na base de dados, o SGBD deve garantir que esses dados são persistentes. A durabilidade destes deve ser garantida mesmo na presença de falhas que ocorram após o fim da transação. Se o utilizador foi informado do sucesso da transação, esperará sempre que os dados tenham ficado registados de forma persistente na base de dados.

É possível ainda ter transações imbricadas, em que uma transação pode ter várias subtransações, sendo que estas, em caso de interrupção, podem ser desfeitas sem implicar que se deva terminar a transação principal. As transações imbricadas podem ser úteis em procedimentos longos ou nos quais existem naturalmente decomposições de tarefas em subtarefas, por exemplo: as reservas de um voo e de um hotel podem constituir subtran© FCA – Editora de Informática

FUNDAMENTOS DE BASES DE DADOS sações da transação de compra de uma viagem, e qualquer uma delas pode ser concluída independentemente da outra. Um dos primeiros SGBD relacionais, o protótipo System R, da IBM, introduziu transações imbricadas a dois níveis, através da utilização de pontos de restauro, como veremos mais à frente (Härder e Rothermel, 1993).

1.5 Arquitetura de um SGBD A Figura 1.2 mostra a arquitetura genérica de um SGBD, com os seus componentes principais representados por retângulos. As setas entre os componentes denotam ligações de dados e de controlo. Esta arquitetura é comum, nos seus aspetos essenciais, a todos os SGBD, e é apresentada e estudada em detalhe em todos os textos sobre o tema (por exemplo, Garcia-Molina, Ullman et al., 2000). É a arquitetura clássica introduzida pelos primeiros protótipos de SGBD relacionais e que se mantém, praticamente sem alterações, até hoje. utilizadores, programas

compilador de interrogações

gestor de transações

execução de interrogações

logs e recuperação

controlo de concorrência

gestor de índices

gestor de memória tampão

gestor de armazenamento

disco

Figura 1.2 – Arquitetura de um SGBD

Introdução

De uma forma genérica, o SGBD tem uma interface para permitir a interação com utilizadores e com aplicações variadas. A interação com os utilizadores faz-se normalmente através da linha de comando ou de uma interface gráfica, enquanto as aplicações utilizam as interfaces de programação disponibilizadas pelo SGBD. Em qualquer dos casos, é utilizada uma linguagem de comandos que permite criar, consultar, modificar e apagar dados (ou a sua estrutura, no caso de um utilizador com permissões para o efeito) na base de dados. Num cenário de utilização normal, várias dezenas, centenas ou mesmo milhares de utilizadores e aplicações poderão estar a aceder simultaneamente à mesma base de dados. Os comandos resultantes dessa interação são verificados pelo primeiro componente, começando pela sintaxe, prosseguindo para a geração de um plano de execução e sua posterior otimização. Como referimos, uma das funções do SGBD consiste em fornecer uma interface que seja independente dos aspetos físicos de armazenamento dos dados, pelo que o próprio SGBD deve tratar dos aspetos de otimização de acesso aos mesmos. A otimização de consultas é um dos componentes que mais influencia o desempenho do SGBD, pois sem este a eficiência de uma consulta dependeria sempre da forma como esta foi especificada pelo utilizador, o que, na maioria dos casos, resultaria em maus desempenhos. Deste modo, é geralmente admitido que o desenvolvimento do componente de otimização de consultas levou os SGBD para fora dos laboratórios, para a utilização real, em organizações reais. Ao mesmo tempo, o gestor de transações assegura que vários utilizadores podem aceder aos mesmos dados sem interferências indesejáveis entre si. Este tem essencialmente dois componentes, que asseguram o controlo de concorrência e que mantêm registos das operações efetuadas, bem como outras informações necessárias em caso de recuperação dos dados após interrupção das transações ou acidente. As interrogações podem então ser executadas de forma concorrente, se existirem vários utilizadores, garantindo que não há efeitos indesejáveis (função assumida pelo componente de controlo de concorrência) e que será possível recuperar o estado da base de dados em caso de acidentes que impeçam a normal conclusão das interrogações (função assumida pelo componente de logs e recuperação). O componente de logs e recuperação regista listas de modificações feitas aos dados e sincroniza a sua atividade com outros componentes, como o gestor de memória tampão e o controlo de concorrência. A atividade de registo de logs e gestão de recuperação pode penalizar o desempenho dos SGBD, sendo essencial parametrizar corretamente o funcionamento deste componente. A execução de interrogações deve ser feita de forma eficaz e eficiente do ponto de vista de utilização de recursos e dados, o que é assegurado pelo componente de gestão de índices. Os índices permitem minimizar o número de acessos aos dados, fazendo acessos o mais localizados possível e evitando longas pesquisas em memória secundária. Embora o tamanho disponível da memória primária tenha vindo a aumentar todos os anos, na maioria dos casos, esta ainda é insuficiente para conter partes importantes da base de dados, pelo que o efeito da paginação no desempenho dos SGBD ainda é muito significativo. A pagi© FCA – Editora de Informática

FUNDAMENTOS DE BASES DE DADOS nação, que consiste em acessos aos discos para ler os dados necessários em memória, representa a maior percentagem de tempo de execução de uma interrogação. O gestor de memória tampão, à semelhança dos mecanismos de gestão de memória nos sistemas operativos, permite manter a localização de referência a um nível aceitável para o desempenho pretendido, aumentando a probabilidade de o gestor de índices encontrar em memória primária os dados de que necessita. Este componente trabalha assim em conjunto com o gestor de índices. Por último, o gestor de armazenamento é responsável pela representação física dos dados no suporte utilizado, bem como pela leitura e escrita dos mesmos. Dependendo do SGBD, são utilizadas várias formas de armazenamento dos dados, sendo que podem ser considerados vários tipos de dispositivos de armazenamento. Existem alguns SGBD, como o MySQL, que permitem trocar o gestor de armazenamento, existindo vários disponíveis com características de desempenho diferentes. Alguns componentes asseguram diretamente as características ACID. O componente de recuperação garante que as transações são atómicas (A) e duráveis (D). Se algo acontecer, o componente é responsável por colocar a base de dados num estado anterior em que estas duas características são respeitadas. O componente de controlo de concorrência fornece o isolamento (I) necessário entre transações, e a consistência (C) é assegurada pela correta definição dos elementos da base de dados, como veremos nos Capítulos 2 e 3. A arquitetura aqui apresentada pode considerar-se clássica e está relacionada com os primeiros SGBD, havendo, por isso, quem defenda que está ultrapassada para fazer face a novas formas de utilização da informação. Na realidade, arquiteturas de bases de dados especializadas têm surgido recentemente e têm sido utilizadas com sucesso em áreas com grande volume de transações e com características de dados e de interrogações diferentes das dos sistemas tradicionais. Por exemplo, muitas aplicações lidam com estruturas em forma de grafos, ou com estruturas com informação incompleta; nesses casos, o Modelo Relacional tem-se revelado uma aplicação complexa e outras arquiteturas foram sendo propostas. Noutras aplicações, pretende-se obter respostas aproximadas a consultas e não resultados exatos; noutros casos ainda, apenas 10% das respostas são relevantes, mas o SGBD calcula todas as respostas. Neste sentido vários autores têm discutido a adequação das arquiteturas de SGBD às necessidades que vão surgindo (Gray, 2004; Stonebraker e Cetintemel, 2005), nomeadamente as que estão ligadas à utilização em larga escala de redes sociais, à geração de dados científicos em grandes quantidades ou a motores de pesquisa. No entanto, o estudo e a compreensão da arquitetura atual dos SGBD e das funções de cada um dos seus componentes são essenciais não só porque estes ainda constituem a arquitetura dominante (uma situação que previsivelmente se manterá nos próximos anos), mas também porque nos permitem analisar as novas propostas com conhecimento do comportamento e das limitações destas arquiteturas. 8

Introdução

1.6 Modelo Relacional Nesta secção, fazemos uma breve introdução ao Modelo Relacional de Dados, que iremos analisar em detalhe mais à frente. O Modelo Relacional, proposto pelo matemático Edgar Codd, da IBM, em 1969, num relatório da IBM de divulgação reduzida (Codd, 1969) e, no ano seguinte, numa revista científica (Codd, 1970), alterou a forma como se utilizavam as bases de dados, que consistia essencialmente na manipulação de estruturas físicas, muito próximas da representação informática em suporte físico. Ao permitir a utilização de uma linguagem de mais alto nível e abstração, independente da representação física dos dados, o Modelo Relacional contribuiu para a vulgarização desta tecnologia, melhorando a produtividade dos utilizadores das bases de dados. Assim, os utilizadores e os programadores já não tinham de se preocupar com estruturas de apontadores físicos, nem em modificar os seus programas sempre que a estrutura dos dados sofria uma alteração. O Modelo Relacional permite a utilização de uma única estrutura de dados, chamada tabela, que implementa o conceito de relação, sendo que uma base de dados é uma coleção de tabelas. Observe-se a representação da Tabela DISCIPLINA: Nome

Sigla

ECTS

Bases de Dados

Programação

As colunas identificam as características de uma disciplina, e cada coluna é encabeçada por um título. As linhas, ou tuplos, representam as diferentes disciplinas que existem na base de dados. Adicionalmente, cada coluna tem um determinado tipo de dados; por exemplo, a coluna ECTS é do tipo inteiro, a coluna NOME é do tipo texto. Uma tabela é definida pelas suas colunas, cujo conjunto representa o seu esquema. Esta representação visual de uma tabela é uma forma conveniente e simples de compreender a base de dados e esconde os aspetos técnicos da representação informática desta estrutura. Para um utilizador não técnico, assemelha-se a uma folha de cálculo; para um programador, assemelha-se a uma estrutura do tipo record (registo). Para manipular as tabelas, foi definida uma linguagem, a álgebra relacional que permite, com base num pequeno conjunto de operadores, construir consultas que podem ser executadas pelo SGBD. Na realidade, as tabelas são manipuladas com a linguagem Structured Query Language (SQL), que implementa muitos aspetos da álgebra relacional. Para permitir a utilização das tabelas da forma que fosse mais adequada a cada tipo de utilizador, foram definidos níveis de abstração, possibilitando assim uma perspetiva diferente consoante as necessidades dos tipos de utilizador, como veremos na secção seguinte.

FUNDAMENTOS DE BASES DE DADOS

1.7 Níveis ANSI/SPARC O grupo de trabalho ANSI/SPARC1 definiu três níveis de abstração num SGBD, para manter a independência entre a utilização dos dados e a sua representação interna. Os níveis correspondem a diferentes perspetivas sobre os dados, e permitem agrupar as ferramentas que o SGBD disponibiliza segundo as necessidades dos diferentes tipos de utilizador. Os níveis definidos são os seguintes: ■■

Externo;

■■

Concetual;

■■

Físico.

O nível externo corresponde à forma como diferentes utilizadores, com diferentes requisitos de utilização, se apercebem dos dados. Cada utilizador poderá ter uma visão completamente distinta da de outros utilizadores, dependendo das suas necessidades ou permissões. Por vezes, a mesma informação é apresentada a diversos utilizadores, mas com formas distintas, incluindo, por exemplo, ordenações diferentes ou agregações de atributos diferentes. Deste modo, existem tantas visões do nível externo como as diferentes necessidades de diferentes utilizadores. Por exemplo, diferentes utilizadores podem ter acesso a apenas algumas colunas da tabela DISCIPLINA, anteriormente mostrada. Outros poderão ainda ter uma visão mais completa, com informação sobre os docentes que lecionam cada disciplina. Num SGBD relacional, o nível externo pode ser implementado através da definição de vistas que suportem as necessidades de informação dos utilizadores, sendo que este nível não está diretamente acessível ao utilizador final, alimentando as interfaces gráficas das aplicações que usam a base de dados. O nível concetual, também chamado nível lógico, corresponde à forma como um administrador de base de dados se apercebe dos mesmos, podendo manipular este nível para otimizar acessos, implementar políticas de segurança e, de forma geral, garantir um desempenho aceitável da base de dados. Neste nível, são definidas permissões por utilizador ou grupo de utilizadores para o conjunto de tabelas da base de dados. Só existe uma visão do nível concetual, igual para todos os administradores. Este nível é utilizado também por programadores que necessitam de uma interface de acesso aos dados em termos de estruturas informáticas comuns. Num SGBD relacional, o nível concetual é constituído por tabelas. O nível físico, ou interno, corresponde à forma como os dados são representados fisicamente, bem como às estruturas utilizadas para os representar e manipular. Define a forma de representação em disco, em termos de blocos, dependendo da forma como os dados são utilizados. Este nível está dependente do sistema operativo utilizado e não se destina a ser acedido diretamente. À semelhança do nível conceptual, existe apenas uma visão do nível físico. A Figura 1.3 seguinte mostra os níveis de abstração de dados num SGBD. 1

American National Standards Institute/Standard Planning and Requirements Committee.

Introdução esquema externo

esquema externo

esquema concetual

esquema físico

disco

Figura 1.3 – Níveis de abstração de dados num SGBD

Os níveis de abstração de dados não têm qualquer tradução direta em componentes ou funções do SGBD e destinam-se apenas a permitir a definição de perspetivas da informação do ponto de vista dos diferentes utilizadores. O SGBD fornece uma linguagem (SQL) para trabalhar nos níveis externo e concetual. A maioria dos SGBD fornece algumas extensões à linguagem SQL para trabalhar no nível físico.

1.8 Projeto de Bases de Dados As bases de dados são utilizadas em muitos tipos de sistemas de informação, constituindo um dos seus componentes principais. Assim, a conceção de uma base de dados requer uma metodologia formal que preveja as etapas principais do projeto e que possa ser utilizada por diferentes tipos de intervenientes no projeto, satisfazendo os requisitos de facilidade de documentação, independência de ferramentas e técnicas específicas, eliminação de ambiguidades, e capacidade de inclusão e de representação dos requisitos iniciais. A Figura 1.4 seguinte apresenta as principais etapas de um projeto de base de dados completo, desde a fase inicial de levantamento de requisitos até à fase de projeto físico. O projeto concetual produz o esquema conceptual, expresso numa linguagem que é independente da base de dados que irá ser usada. Este esquema utiliza noções abstratas que permitem capturar os requisitos do problema, sem tomar decisões dependentes de quaisquer sistemas ou tecnologias. Nesta fase do projeto, utilizam-se modelos ditos semânticos, que tentam capturar o significado dos dados que serão necessários. Por ser um modelo semântico, é fácil envolver utilizadores com perfis de conhecimento diferentes, uma vez que só estamos preocupados com a forma como os utilizadores se apercebem dos dados e os querem utilizar. Um dos modelos mais utilizados nesta fase é o Modelo Entidade-Relacionamento (Modelo E-R), que veremos no Capítulo 2.

FUNDAMENTOS DE BASES DE DADOS

requisitos, análise

requisitos da base de dados

projeto concetual

independente da base de dados

esquema concetual

projeto lógico específico de uma base de dados

esquema lógico

projeto físico

esquema interno

Figura 1.4 – Etapas do projeto de uma base de dados

O projeto lógico traduz o Modelo Concetual no Modelo Relacional de Dados. O resultado é o conjunto de tabelas ou esquema da base de dados. Dependendo do SGBD a utilizar, o Modelo Lógico pode ser ligeiramente diferente, porque pode haver, por exemplo, variações nos tipos de dados, restrições no uso de nomes, tipos de índices diferentes e funcionalidades diferentes para valores por defeito ou valores automáticos. O projeto lógico permite envolver utilizadores que não sejam técnicos e que possam desta forma contribuir com especificações relativas ao problema em si, sem a necessidade de compreenderem os aspetos técnicos das bases de dados. Este projeto pode sofrer alterações para ser transformado numa versão melhorada, através de um processo chamado normalização. O projeto físico envolve a parametrização do Modelo Relacional em função do que se espera ser a sua utilização. Desta forma, tenta-se otimizar e melhorar o desempenho da base de dados. Podem ser tomadas decisões em termos de estratégias de armazenamento, estruturas de acesso rápido aos dados, como os índices, ou mesmo de redesenho de tabelas, para tirar partido das características de utilização previstas. O projeto físico deve tirar partido das características do SGBD e, por isso, depende fortemente do produto utilizado. Como veremos no Capítulo 5, diferentes SGBD oferecem diferentes possibilidades de afinação, pelo que uma estratégia única para todos poderia não funcionar. Com efeito existem regras gerais sobre como desenvolver o projeto físico, e são essas que veremos. A previsão da carga de utilização da base de dados é essencial no projeto físico. É comum considerar que existem, de um modo geral, dois cenários: cargas transacionais, com muitos utilizadores a lerem e a escreverem em simultâneo a base de dados (cenário geralmente designado por Online Transaction Processing, OLTP), e cargas essencialmente de 12

Introdução

leitura e de cruzamento de grandes quantidades de dados para análise (cenário geralmente designado por Online Analytical Processing, OLAP). Ambos os cenários têm hoje uma expressão significativa, embora, em termos históricos, a arquitetura clássica do SGBD tenha sido mais orientada para os cenários OLTP. Podemos considerar outras fases do projeto de uma base de dados, sobretudo a definição de aspetos de segurança dos dados e a otimização do Modelo Concetual. A segurança é geralmente abordada do ponto de vista da aplicação, exceto em aplicações especializadas que envolvam a confidencialidade dos dados armazenados. A otimização do Modelo Concetual permite detetar eventuais problemas na interpretação dos requisitos, evitando a posterior definição de esquemas errados e que não se comportem devidamente face à utilização real. Nesta situação, é pouco provável que otimizações ao nível físico possam surtir efeito, uma vez que a conceção, à partida, está errada.

1.9 Vantagens de um SGBD A utilização de um SGBD apresenta várias vantagens relativamente a outra solução de gestão de dados (Ramakrishnan e Gehrke, 2003), algumas das quais já foram abordadas nas secções anteriores: ■■

Independência dos dados: Esta característica evita que as aplicações que acedem à base de dados tenham de ser modificadas se a estrutura física dos dados mudar. Ou seja, mudanças no esquema físico, por exemplo, não implicam mudanças nos outros níveis da base de dados. Modificar estruturas de acesso ou tamanhos de página não implica alterações nas consultas, por exemplo;

■■

Verificação de regras de integridade e de segurança: É possível especificar regras de integridade, como, por exemplo, um preço ser sempre número positivo, no esquema da base de dados, em vez de ter de se colocar essa regra em todas as aplicações que manipulam os preços. Da mesma forma, políticas de segurança podem ser implementadas no esquema e não nas aplicações, facilitando a sua imediata aplicação;

■■

Acesso eficiente aos dados: O acesso aos dados é decidido pelo SGBD, permitindo assim escolher as estratégias mais eficientes, não sendo necessário o utilizador ter de escolher a forma de acesso, ou seja, este vê os dados como uma tabela e não precisa de se preocupar com a sua representação interna, nem com a forma mais eficaz de aceder aos tuplos;

■■

Gestão da concorrência e recuperação: Vários utilizadores podem aceder em simultâneo aos dados sem terem de se preocupar em sincronizar as suas ações. Por outro lado, o SGBD fica encarregado de garantir que, em caso de falha, é sempre possível colocar a base de dados num estado estável, com todas as restrições de integridade respeitadas;

■■

Gestão de dados: Várias aplicações podem partilhar os mesmos dados, com as vantagens de eliminação de redundância, reforço de coerência e integridade, que daí © FCA – Editora de Informática

FUNDAMENTOS DE BASES DE DADOS advêm. A utilização de uma base comum para os dados facilita a aplicação de normas e diretivas; ■■

Redução do tempo de desenvolvimento: Ao aliviar o programador de ter de tomar decisões relativas à forma de armazenamento e acesso aos dados, diminui o tempo de desenvolvimento e reduz a probabilidade de erros. Ao permitir a manipulação de um modelo independente da máquina e do sistema operativo, permite que o programador se concentre no essencial e na lógica de negócio, deixando as decisões de baixo nível para o SGBD.

Embora estas vantagens possam constituir motivos suficientes para escolher um SGBD em detrimento de outra solução, por vezes não se justifica a sua complexidade, principalmente quando algumas das vantagens não são essenciais. Nesse caso, pode optar-se por escolher aplicações ou ambientes mais especializados.

1.10 Breve histórico A necessidade de utilização de bases de dados nasce com os computadores e com a manipulação de grandes quantidades de dados que estes começaram a permitir. O que pode ser considerado como o primeiro SGBD utilizado em situação real, o Integrated Data Store (IDS), foi desenvolvido, entre 1961 e 1964, para a General Electric por Charles Bachman (Bachman e Williams, 1964), e estava integrado num complexo sistema de controlo de produção. O IDS distinguia-se dos outros sistemas de processamento de dados da época por aceder aos dados em disco, ao invés de banda magnética ou cartões perfurados, e por disponibilizar várias das funções que hoje associamos aos SGBD. O IDS introduziu também o precursor do chamado Modelo em Rede e várias das características dos SGBD modernos. Em 1959, foi criado pelo Departamento de Defesa americano um consórcio que envolvia universidades, empresas, fabricantes de computadores, organismos de investigação e desenvolvimento, e entidades governamentais, designado por Conference on Data Systems Languages (CODASYL). Este consórcio tinha por missão definir uma linguagem de programação que pudesse ser executada em vários computadores, independentemente do equipamento ou do fabricante. O CODASYL estava organizado em três comités técnicos, sendo que um deles, o Programming Language Committee, propôs, em 1960, a linguagem COBOL e, em 1969, através do seu grupo de trabalho Data Base Task Group (DBTG), uma extensão de COBOL para trabalhar com bases de dados que ficou conhecida como o Modelo em Rede ou Modelo CODASYL. O Modelo em Rede utilizava os conceitos introduzidos pelo SGBD IDS da General Electric, que constituiu a sua principal inspiração. Outro comité, o Systems Committee, começou a interessar-se por bases de dados e iniciou um projeto que identificou praticamente 50 sistemas diferentes em utilização em 1968 (CODASYL, 1969), quase todos com modelos próprios. 14

Introdução

Devido à grande pressão da indústria, incluindo dos fabricantes de computadores e de grandes organizações com complexos problemas de gestão da informação, procuravam ‑se linguagens e modelos que fossem independentes dos computadores e que pudessem ser facilmente adaptados ou modificados se os requisitos iniciais mudassem. Os sistemas existentes estavam muito dependentes da estrutura de armazenamento e das máquinas utilizadas, pelo que qualquer alteração no tipo de informação e na utilização pretendida poderia obrigar a grandes alterações nos programas informáticos que acediam às bases de dados. Em 1968, a IBM introduziu o seu primeiro SGBD, o Information Management System (IMS)2, destinado a gerir o inventário de material da missão lunar Apolo. O IMS, que utilizava o que mais tarde ficou conhecido por Modelo Hierárquico (Tsichritzis e Lochovsky, 1976), começou a ser desenvolvido em 1965 com a colaboração da Caterpillar e da North American Rockwell, tendo resultado no Information Control System (ICS) e na Data Language/I (DL/I). O IMS deveria gerir os cerca de dois milhões de componentes da nave espacial e funcionar num computador IBM System/360 com 256 K de memória. Segundo a própria IBM, o IMS é ainda hoje o seu SGBD mais utilizado, com 95% das empresas da lista Fortune 500 a utilizá-lo. O IMS continuou a acompanhar os avanços da tecnologia e do conhecimento no domínio dos SGBD e adapta-se perfeitamente aos ambientes informacionais das grandes organizações. Os modelos de dados usados na altura, em Rede e Hierárquico, não estavam formalmente definidos como tal, o que só aconteceu anos mais tarde, mas guiavam o desenvolvimento técnico dos SGBD. Em 1969, Edgar Codd publicou as bases do Modelo Relacional de Dados e alguém vaticinou que seriam necessários 10 anos até que um produto baseado nesse modelo surgisse, o que realmente aconteceu. A IBM iniciou o projeto do protótipo System R em 1973. A partir dos resultados deste projeto, surge, em 1978, o primeiro SGBD relacional comercial, Oracle, que começou a ser vendido em 1979 e antecipou a entrada comercial da IBM nesta área. A IBM só começou a disponibilizar em 1981 a versão comercial do System R, SQL/DS e, pouco depois, em 1983, o DB2 para o sistema operativo MVS da IBM. Outro protótipo relacional da IBM, Query By Example (QBE), começou a ser desenvolvido na mesma altura do System R e chegou a ser instalado em mais de uma centena de clientes, mas foi abandonado. Outros protótipos de SGBD relacionais foram sendo desenvolvidos e disponibilizados, e alguns tiverem uma difusão alargada como o Ingres3, da Universidade da Califórnia (UC), em Berkeley. O Ingres foi iniciado ao mesmo tempo do que o System R e teve um grande impacto, auxiliado pelo facto de ser escrito para Unix, um sistema operativo gratuito, aberto e muito utilizado nas universidades americanas, produzindo um protótipo e uma linguagem de interrogação, QUEL. Em 1982, o projeto termina, mas os seus resultados são aproveitados pelo projeto Postgres, iniciado, em 1985, pela UC. Este projeto por sua vez dará origem ao SGBD Postgre95, em 1995, com a introdução de uma linguagem de interrogação relacional, e, mais tarde, o PostgreSQL (Stonebraker e Kemnitz, 1991). Em 2 3

Também designado como DB1. O Interactive Graphics and Retrieval System foi um projeto financiado pelo Governo americano ao mesmo tempo que a IBM iniciava o projeto System R. © FCA – Editora de Informática

FUNDAMENTOS DE BASES DE DADOS 1987, a Sybase disponibiliza o SGBD SQL Server para plataformas Linux e, mais tarde, para plataformas Windows, em conjunto com a Microsoft, parceria que manteve até 1994. A Microsoft introduziu o SQL Server 7 em 1998 com mudanças significativas relativamente ao código base da Sybase. A Sybase continuou a oferecer o SQL Server sob a designação Adaptive Server Enterprise (ASE), sendo atualmente um dos SGBD com maior quota de mercado, atrás dos três grandes: Oracle, IBM e Microsoft. Recentemente, surgiram modelos especializados, não relacionais, que são adaptados a aplicações específicas: modelos orientados a objetos (Gouveia, 1993), modelos baseados em tuplos Resource Description Framework (RDF) (Dittrich e Quiane-Ruiz, 2012), modelos temporais (Snodgrass, 2000), modelos lógico-dedutivos (Gallaire, Minker e Nicolas, 1984) e modelos chamados verticais ou em colunas (Abadi, 2007). Cada um dos modelos responde a características particulares do domínio em que é usado, e é geralmente otimizado para nichos de aplicações.

1.11 Aplicações Os SGBD invadiram todos os setores das organizações, constituindo o núcleo de sistemas de informação cada vez mais versáteis, abrangentes e poderosos. As aplicações clássicas de bases de dados encontram-se na faturação, gestão de clientes, de fornecedores, de vendas, de produtos, de armazém, em domínios que são bem conhecidos e onde a informação tem uma estrutura quase rígida, por força de normas, práticas ou exigências de corpos reguladores, como o Estado. Existem, no entanto, vários domínios com restrições próprias e requisitos de informação que necessitam de modelos ou arquiteturas de bases de dados diferentes das apresentadas neste livro, por exemplo, as bases de dados em memória principal. Em algumas situações, pode justificar-se ter a base de dados ou uma grande parte dela sempre em memória, como nas aplicações de portabilidade de números antigos para os números de telefone reais, ou para aplicações financeiras em tempo real. Noutras situações, pode recorrer-se a modelos especializados, como o modelo orientado por objetos, o modelo temporal, ou o modelo geométrico. Em aplicações analíticas com grandes quantidades de dados, começam a ser aplicados modelos alternativos, implicando, por vezes, arquiteturas diferentes das estudadas neste livro. Em aplicações complexas de engenharia, podem ter-se relações entre peças de informação que são demasiado variadas e complexas para poder ser representadas eficazmente num SGBD, por exemplo: relações de composição (peças que fazem parte, de diferentes formas, de outras peças), de estrutura (representações em grafo ou árvore) e generalização. A Web semântica implica gerir enormes quantidades de dados, pouco estruturados, geralmente em modelos de grafos ou com forte conetividade entre si. O modelo mais utilizado de bases de dados, o Modelo Relacional, prevê dados com estrutura uniforme, conhecida e pouco variável no tempo. A representação de dados incompletos e com estrutura variável, produzidos em grande escala, coloca grandes desafios aos SGBD. No extremo oposto, temos pequenas aplicações, móveis ou embebidas, que registam dados de forma estru16

Introdução

turada e querem tirar partido da utilização de um SGBD, mesmo que este não tenha todas as características de um SGBD; por exemplo, o controlo de concorrência pode não ser necessário, porque a aplicação é do tipo monoutilizador, ou o SGBD pode não necessitar de possibilidades de recuperação. O aparecimento das aplicações móveis traz novos desafios, como a gestão de transações distribuídas, a gestão de recuperação em ambientes com interrupções de conetividade, e o processamento de dados distribuídos com padrões diferentes de acesso segundo o utilizador ou a sua localização. Nestas situações, aparecem novos conceitos como a “quase consistência”, sugerindo que pode ser preferível trabalhar com uma base de dados que não seja 100% ACID, mas que permita mesmo assim um nível de serviço aceitável em determinadas situações.

1.12 Organização do livro O livro está organizado em 11 capítulos, que podem ser divididos em três grandes partes: ■■

Os Capítulos 1, 2, 3 e 4 abordam camadas que estão diretamente expostas à interação com o utilizador e cujo conhecimento é essencial para a utilização de um SGBD;

■■

Os Capítulos 5, 6, 7, 8 estão relacionados com as camadas internas de um SGBD que não estão diretamente acessíveis ao utilizador, mas cujo conhecimento é indispensável para uma eficiente utilização e administração de um SGBD;

■■

Os Capítulos 9, 10 e 11 dizem respeito ao funcionamento de camadas internas do SGBD que podem ser controladas, de uma forma ou de outra, pelo utilizador ou pelo administrador, e que podem ter um impacto direto na consistência e na disponibilidade da base de dados.

Embora a ordem recomendada de leitura seja pela numeração dos capítulos, é possível lê ‑los em qualquer ordem, principalmente se o leitor estiver interessado em tópicos de apenas uma das três partes referidas. A primeira parte é geralmente abordada numa disciplina de introdução a bases de dados, que pode incluir também a parte inicial dos Capítulos 5, 6, 8, 9 e 10. Os Capítulos 5, 6, 7, 8, 9 e 10 podem fazer parte de uma disciplina de Bases de dados avançadas ou de arquitetura de bases de dados. É ainda possível usar os Capítulos 8 e 9 num curso avançado de sistemas de informação. A seguir, apresenta-se brevemente o conteúdo de cada capítulo: ■■

Capítulo 1: Introduz os conceitos de bases de dados, enquadrando o seu aparecimento histórico na indústria de computadores e de sistemas de informação. Este capítulo apresenta as características principais e a arquitetura genérica de um SGBD, cujos componentes serão estudados noutros capítulos deste livro;

■■

Capítulo 2: Introduz o Modelo Relacional de Dados e a álgebra relacional. São apresentados os seus conceitos fundamentais, como relações, atributos, chaves e dependências funcionais, e é descrito brevemente o cálculo relacional como linguagem equivalente à álgebra relacional; © FCA – Editora de Informática

FUNDAMENTOS DE BASES DE DADOS

■■

Capítulo 3: Aborda o projeto lógico de bases de dados, introduzindo o Modelo Entidade-Relacionamento na sua variante mais utilizada. São apresentadas extensões do Modelo citado, nomeadamente a especialização. São introduzidas a normalização e as formas normais mais comuns, baseadas nas noções de dependência como técnica para definir um esquema de base de dados sem anomalias. São introduzidos vários tipos de dependências, bem como as noções de fecho e de cobertura de um conjunto de dependências;

■■

Capítulo 4: Introduz a linguagem SQL, a sua sintaxe, os seus principais operadores e os principais componentes de um SGBD envolvidos na análise e no processamento de interrogações. São abordadas questões como a utilização de mecanismos de indexação e a otimização de interrogações;

■■

Capítulo 5: Aborda os aspetos de armazenamento e indexação, com destaque para os aspetos práticos do armazenamento físico dos dados e das suas implicações nos algoritmos de indexação. São apresentadas várias técnicas de indexação, as variantes usadas nos SGBD e o seu impacto no desempenho;

■■

Capítulo 6: Introduz a execução de consultas e o componente responsável por interpretar os comandos SQL recebidos. São detalhadas as fases iniciais do processamento, bem como a análise da escolha de operadores e algoritmos de acesso. É detalhada a construção de planos lógicos e as transformações geralmente utilizadas a partir de um ponto de vista heurístico;

■■

Capítulo 7: Dedica-se a questões de otimização de consultas, tanto do ponto de vista do utilizador como do SGBD. Retoma o processamento de consultas abordado no capítulo anterior, a partir da construção de planos lógicos, e detalha a construção de planos físicos e respetiva otimização. É introduzida a noção de custo de um operador e são descritos os operadores físicos disponíveis num SGBD, sendo calculado o seu custo em diferentes cenários. São introduzidas estruturas de estimação como os histogramas e o seu uso pelo otimizador;

■■

Capítulo 8: Aborda as questões de gestão de transações e dos critérios para assegurar a correção de uma execução concorrente de transações. É introduzida a noção de escalonamento e definidas as anomalias de concorrência mais comuns. Define-se serialização, de conflitos e de vistas, e relaciona-se o conceito com as questões de recuperação. Apresentam-se brevemente as técnicas de controlo de concorrência, que serão detalhadas no capítulo seguinte;

■■

Capítulo 9: Apresenta o controlo de concorrência, com destaque para os principais algoritmos utilizados e para questões práticas de desempenho. São apresentados e descritos os mecanismos de controlo de concorrência utilizados por alguns produtos disponíveis;

■■

Capítulo 10: Introduz os níveis de isolamento e define-os em termos das anomalias de concorrência. Mostra-se que os níveis de isolamento permitem gerir o grau de consistência requerido numa transação, permitindo uma maior ou menor interferência entre transações;

Introdução ■■

Capítulo 11: Aborda a recuperação, o componente do gestor de transações responsável por garantir que a base de dados pode ser colocada num estado consistente, quer após interrupção de transações, quer após falhas diversas. É detalhado o funcionamento do gestor de memória, os seus algoritmos mais utilizados e o seu relacionamento com a recuperação da base de dados. É apresentado em detalhe o algoritmo ARIES devido à sua importância nos SGBD.

Em cada capítulo, é reunida a bibliografia relevante para as matérias tratadas, permitindo ao leitor encontrar material com informação mais detalhada ou complementar, muitas vezes do âmbito de investigação e experimental, outras vezes sobre técnicas, modelos e algoritmos utilizados em aplicações reais. A bibliografia é, na sua maioria, recolhida de revistas científicas da especialidade (com destaque para publicações da Association for Computing Machinery – ACM – e do Institute of Electrical and Electronics Engineers – IEEE), existindo também muitas referências a conferências (com destaque para a Very Large Databases – VLDB –, e International Conference on Management of Data SIGMOD) e a publicações universitárias. Evitaram-se referências a documentos que fossem difíceis de encontrar ou a documentos de carácter puramente comercial, encontrando-se grande parte das referências em bibliotecas digitais. Incluíram-se também os livros geralmente adotados em cadeiras de bases de dados ou de matérias relacionadas com bases de dados.

Leituras Recomendadas Bachman e Williams (1964), por um lado e CODASYL (1969), por outro, permitem compreender o início das bases de dados, e os modelos e a tecnologia em uso nos anos 60. Kim (1979) faz uma análise dos sistemas relacionais existentes no final dos anos 70. O trabalho precursor das bases de dados modernas é o de Edgar Codd da IBM, publicado em 1969 e posteriormente em 1970 (Codd, 1969, 1970). Astrahan et al. (1976) e Chamberlin et al. (1981) descrevem o System R. Existem várias obras com capítulos introdutórios aos SGBD, entre as quais as de Date (2003), Ramakrishnan e Gehrke (2003), Silberschatz, Korth et al. (2010), Garcia-Molina, Ullman et al. (2008) e Elmasri e Navathe (2010). A obra de Garcia-Molina, Ullman et al. (2000) é inteiramente dedicada a questões de implementação de SGBD. Hellerstein e Stonebraker (2005) apresentam uma compilação dos trabalhos mais importantes na área, reunidos quer pelo interesse histórico, quer pela sua contribuição teórica e prática para o domínio. McGee (1981) faz uma compilação dos primeiros 25 anos da tecnologia de bases de dados. Um grupo de investigadores de bases de dados e membros da indústria juntou-se pela primeira vez em Laguna Beach, Califórnia, em 1989, e reúne-se regularmente desde então para refletir sobre os avanços na área e para identificar problemas e projetar a evolução no domínio (Silberschatz et al., 1996 e Bernstein et al., 1998). Autores como Stonebraker e Cetintemel (2005) refletem sobre o estado da arte dos SGBD e sobre os novos cenários da sua utilização.

FUNDAMENTOS DE BASES DE DADOS

Bibliografia Abadi, D. (2007). ColumnStores For Wide and Sparse Data. Proceedings of 3rd Biennial Conference on Innovative Data Systems Research (CIDR). Abiteboul, S., Hull, R., Vianu, V. (1995). Foundations of databases. Addison-Wesley. Astrahan, M., Blasgen, M. et al. (1976). System R: Relational Approach to Database Management. ACM Transactions on Database Systems, 1(2). Bachman, C., Williams, S. (1964). A general purpose programming system for random access memories. Proceedings of AFIPS’64. Bernstein et al. (1998). The Asilomar Report on Database Research. ACM SIGMOD Record, 27(4). Chamberlin, D., Astrahan, M. et al. (1981). A history and evaluation of System R. Communications of the ACM, 24(10). CODASYL (1969). A Survey of Generalized Data Base Management Systems. CODASYL System Committee Technical Report, Nova Iorque. Codd. E. F. (1969). Derivability, Redundancy and Consistency of Relations in Large Data Banks. IBM Research Report RJ 599. Publicado como SIGMOD Record, 38(1), 2009. Codd, E. F. (1970). A Relational Model of Data for Large Shared Data Banks. Communications of the ACM, 13(6). Date, C. (2003). An Introduction to Database Systems. Addison-Wesley. Dittrich, J., Quiane-Ruiz, J.-A. (2012). Efficient Big Data Processing in Hadoop MapReduce. Proceedings of the VLDB Endowment VLDB Endowment, 5(12). Elmasri, R., Navathe, S. B. (2010). Fundamentals of Database Systems. 6.ª ed., Addison ‑Wesley. Eswaran, K., Gray, J. et al. (1976). The Notions of Consistency and Predicate Locks in a Database System. Communications of the ACM, 19(11). Gallaire, H., Minker, J., Nicolas, J.-M. (1984). Logic and Databases: A Deductive Approach. ACM Computing Surveys, 16(2). Garcia-Molina, H., Ullman, J. et al. (2000). Database System Implementation. Prentice Hall. Garcia-Molina, H., Ullman, J. et al. (2008). Database Systems: The Complete Book. Prentice Hall. Gouveia, F. (1993). Survey and Selection of OODB for Object-Oriented Simulation Environments. Institut Internationale pour l’Intelligence Artificielle, Relatório IIIA-OOSE-93-03-24. Gray, J. (2004). The Revolution in Database Architecture. Relatório Técnico MSR-TR-2004-31, Microsoft Research. 20

Introdução

Härder, T., Reuter, A. (1983). Principles of Transaction-Oriented Database Recovery. ACM Computing Surveys, 15(4). Härder, T., Rothermel, K. (1993). Concurrency Control Issues in Nested Transactions. VLDB Journal, 2(1). Hellerstein, J. Stonebraker, M. (2005). Readings in Database Systems. MIT Press. Kim, W. (1979). Relational Database Systems. ACM Computing Surveys, 11(3). McGee, W (1981). Data Base Technology. IBM Journal of Research and Development, 25(5). Michaels, A., Mittman, B., Carlson, C. (1971). A Comparison of the Relational and CODASYL Approaches to Data-Base Management. ACM Computing Surveys, 8(1). Navathe, S. (1992). Evolution of Data Modeling for Databases. Communications of the ACM, 35(9). Ramakrishnan R., Gehrke, J. (2003). Database Management Systems. 3.ª ed., McGraw-Hill. Silberschatz, A. Zdonik, S. et al. (1996). Strategic directions in database systems – breaking out of the box. ACM Computing Surveys, 28(4). Silberschatz, A., Korth, H. et al. (2010). Database Systems Concepts. 6.ª ed., McGraw-Hill. Snodgrass, R. (2000). Developing Time-Oriented Database Applications in SQL. Morgan Kauf mann Publishers. Stonebraker, M., Kemnitz, G. (1991). The Postgres Next Generation Database Management System. Communications of the ACM, 34(10). Stonebraker, M., Cetintemel, U. (2005). One Size Fits All: An Idea Whose Time Has Come and Gone. Proceedings of the 21st International Conference on Data Engineering (ICDE ‘05). Tsichritzis, D., Lochovsky, F. (1976). Hierarchical Data-Base Management: A Survey. ACM Computing Surveys, 8(1).

EXERCÍCIOS 1 .1 Identifique algumas razões para utilizar um SGBD em vez de ficheiros simples ou de uma aplicação do tipo folha de cálculo. 1 .2

Quais os tipos principais de utilizadores que um SGBD deve suportar?

1 .3

Quais são as principais funções de um administrador de bases de dados?

1 .4 Defina independência dos dados, e explique a importância desta característica. 1 .5 Descreva os principais componentes da arquitetura de um SGBD.

FUNDAMENTOS DE BASES DE DADOS

1 .6

Quais os componentes que garantem as características ACID?

1 .7

Que aspetos podem influenciar o desempenho de um SGBD?

1 .8

Enuncie algumas diferenças entre uma transação e um programa.

1 .9 Descreva as principais características que uma transação deve exibir. 1 .10 O que são as características ACID? 1 .11

Enuncie alguns problemas que poderiam acontecer se as transações não respeitassem as características ACID.

1 .12

Quais são os níveis ANSI/SPARC e o que significam?

1 .13

Quais são as principais características do Modelo Relacional?

1 .14

Quais são as principais etapas de projeto de uma base de dados?

1 .15

Quais dessas etapas dependem de um SGBD em particular?

1 .16

Quais são os modelos de dados mais utilizados nas diferentes etapas de projeto de uma base de dados?

1 .17 Identifique algumas aplicações que utilizam bases de dados.